00:03 <cone-797> ffmpeg James Almer master:8a4c9d6bd31f: swscale/x86/range_convert: reduce amount of xmm regs clobbered in luma functions

00:03 <cone-797> ffmpeg James Almer master:fa325379c9d0: fate/checkasm: run the sw_range_convert test

07:24 <Lynne> is there a way to force asan to check for overwrites everywhere where it can?

07:25 <Lynne> even with -O0 it still fails for trivial loops and arrays with no funny stuff

07:30 <elenril> ugh, wtf is https://trac.ffmpeg.org/ticket/11055

07:30 <elenril> is that three balling clones arguing with each other?

07:32 <galad> oh, it's markfilipak

07:32 <galad> that will ensure lengthly discussions about nothing

07:37 <j-b> 88 comments in 2 days.

07:42 <elenril> ban everyone involved & salt the earth?

07:44 <j-b> and burn the ground

07:47 <mkver> Lynne: Doesn't it already do so?

07:50 <Lynne> nope

07:51 <mkver> Show the code.

07:55 <Lynne> aacsbr_template.c, SBRData->bs_freq_res, bs_df_env et al.

07:56 <Lynne> usac extended the array size to 8

07:56 <Lynne> but because there are multiple arrays deriving multiple arrays deriving multiple arrays, I was hoping asan would detangle the sphagetti if something overflowed

07:57 <mkver> Lynne: UBSan would check for this.

07:59 <Lynne> thanks, that worked

11:34 <cone-960> ffmpeg Andreas Rheinhardt master:7c95c7de4ae2: avcodec/libx265: Don't copy A53 closed captions by default

12:00 <mkver> frankplow: /usr/bin/ld: removing unused section '.text.ff_h2656_put_8tap_hv64_8_avx2' in file 'libavcodec/x86/h26x/h2656dsp.o'

12:02 <mkver> The same is true for several other functions (ff_h2656_put_{uni_8tap_hv64_8_avx2,8tap_hv128_8_avx2,uni_8tap_hv128_8_avx2,4tap_hv64_8_avx2,uni_4tap_hv64_8_avx2,4tap_hv128_8_avx2,uni_4tap_hv128_8_avx2})

12:08 <mkver> Removal of the alpha code now makes the alpha linker segfault: https://fate.ffmpeg.org/log.cgi?slot=alpha-uubuntu-qemu-gcc-shared&log=compile&time=20240613220959

13:03 <mkver> jamrial: https://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-oldyasm&time=20240616060905

13:10 <cone-960> ffmpeg James Almer master:fcf72966a5f2: swscale/x86/range_convert: add missing AVX2 preprocessor wrapper

14:48 <Sean_McG> mkver: I suspect it will need to flush it's ccache -- I didn't see any linker crashes locally when I did it.

15:58 <ramiro> jamrial: thank you for the fixes

17:21 <pal_> if anyone has a few mins, I would be great if you could try `./configure --toolchain=valgrind-memcheck; make fate-lavf-asf`

17:21 <pal_> ... I am apparently the only one getting an error

17:23 <frankplow> mkver: http://0x0.st/XckL.patch should be what's required to use those functions but it seems they don't pass checkasm and are slower to boot. I've asked Wu Jianhua.

17:23 <mkver> Then why are they even built?

17:24 <frankplow> I think they probably shouldn't be

17:40 <Lynne> IndecisiveTurtle: sup

17:49 <pengvado> pal_: is your error specific to asf? because I have problems with toolchain=valgrind-memcheck in general, but affectinge *every* fate test, not just that one.

17:50 <pal_> it is specific to that specific test

17:51 <pal_> ... I get a false positive (Conditional jump or move depends on uninitialised value(s))

17:52 <pal_> ... which is cured by `--expensive-definedness-checks=yes`

17:53 <pal_> ... as suggested by mkver and proposed at https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240609005936.5662-1-pal@sandflow.com/

17:53 <pal_> ... maybe it is an issue with my version of valgrind? (valgrind-3.15.0)

17:54 <pal_> (it is super annoying not being able to do full regression testing)

17:55 <kurosu> frankplow: I can't really answer your question about whether the stream is legal. I just know 1) SPS/PPS are resent without an EOS, on "IDRs" (don't ask me their full qualified names), eg that's what happens in broadcasting 2) I recall very careful designs, at least from HEVC on, in SPS/PPS so that parsing of one does not depend on the parsing of the other (so there can be duplicated elements like bitdepth)

17:56 <kurosu> that an incompatible SPS appears without better warning sounds strange. But then your example has NoOutputBeforeRecoveryFlag=1

17:58 <kurosu> anyway, my conclusion is that I'm no expert, and a proper/better review would ideally come from someone that knows better HLS

18:09 <frankplow> kurosu: Yeah you can tell the spec. has been written so parsing is always independent of any other NAL unit, it's FFmpeg's implementation which introduces dependencies in the CBS.

18:10 <kurosu> that check should probably done at the slice level ? but maybe that's costly

18:11 <kurosu> ideally (easy to say from my spot...), you would receive a corrupt PPS and still catch the issue at that level

18:11 <kurosu> eg, without the decoder crashing

18:12 <kurosu> ("should probably done" <- a bit strong, more of a hunch)

18:12 <frankplow> Yeah if we want to remove any dependency on the SPS from the PPS parsing we will have to move all checks + also all values inferred from values absent in the PPS to the slice level.

18:45 <IndecisiveTurtle> Lynne: Heya, switched my install back to EndeavorOS this weekend. Everything works so much better now xD

18:47 <IndecisiveTurtle> Also want to apologize for a bit slow progress, had to study for statistics and calculus for uni exams. Expect some more rapid progress from this week on

18:53 <Lynne> sure, looking forward to it

20:03 <kasper93> Any news about https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=12028 ?

20:05 <kasper93> https://gitlab.archlinux.org/archlinux/packaging/packages/ffmpeg/-/issues/10 is this enough to make it worth reviewing?

20:08 <sfan5> elenril had a concern with the last patch in that series so it wasn't pushed

20:09 <sfan5> it would unbreak mbedtls 3.6.0 entirely if merged

21:46 <Lynne> it just ocurred to me that a gpu ffv1 encode/decode implementation would make lossless video editing possible on consumer systems

21:51 <compnn> yep

22:03 <jkqxz> Except ffv1 has no local parallelism, so GPUs are pretty useless for it.

22:14 <Lynne> I think its possible

22:14 <thardin> j2k wins again

22:15 <Lynne> with potato lossless compression, I don't think so

22:16 <Lynne> (I assume you mean -hc, the old EC system is something that history itself wants to forget)

22:20 <jkqxz> How would you do GPU ffv1?

22:22 <jkqxz> You basically can't use the SIMT inside a slice because there is nothing for it to do, but if you try to cross slices with it then it is painful because of all the branches and loops which every thread is going to have to go through mostly doing nothing on.

22:23 <jkqxz> Not to mention that the entropy context for each slice is huuuge and you really want to keep it in cache.

22:28 <Lynne> "cross slices with it"?

22:29 <Lynne> the only issue is the entropy decoding context, and when I looked at it, it looked possible due to constraints I noticed on which context gets picked

22:32 <thardin> htj2k is what j2k should have been all along, yes

22:32 <thardin> doing CABAC on every single bit as Part 1 j2k does is excessive

22:35 <jkqxz> A single GPU core with N SIMT threads can work on either 1 slice (and fail at parallelism) or N slices (and have most of them doing nothing most of the time as it takes both branches and all loop iterations in each pixel).

22:37 <jkqxz> (Also you probably don't want to have streams with the thousands of slices required for that, nor do you have the cache to do context lookups at any reasonable speed.)

22:39 <pal_> htj2k makes lossless editing possible on desktop systems

22:39 <Lynne> not enough compression, and vc-2 is a better codec :-P

22:40 <Lynne> its possible to avoid branches

22:41 <Lynne> tricks exist for this

22:41 <Lynne> bwdif was full of branches, but I made bwdif_vulkan completely branch-free

22:41 <pal_> i am not saying that you *should* do lossless editing, but that you can.

22:46 <Lynne> you can do lossless editing with snow too, but you definitely shouldn't

22:57 <thardin> lossless j2k and ffv1 appear similar compressionwise. at least with the sample I have

22:58 <thardin> both handily beat png

23:49 <pal_> lynne: with j2k lossless you can get a low rez or quality version if the bandwidth is not available for full frame transfer, e.g., snow

23:50 <Lynne> editing is not a place to compromise on quality

23:51 <Lynne> if I had to use a jpeg codec, I'd just use jpeg-xl and make it fast