00:33 <cone-156> ffmpeg James Almer master:72ac49596060: avutil/tests/opt: test negative values for INT and INT64 types

00:33 <cone-156> ffmpeg James Almer master:d6e877bbcde2: avutil/iamf: fix offsets for mix_gain options

00:33 <cone-156> ffmpeg James Almer master:088bf6e8c1ca: avutil/iamf: use AV_OPT_TYPE_UINT

00:33 <cone-156> ffmpeg James Almer master:9902fc550aec: avutil/tests/opt: test values > INT_MAX for INT64 type

00:33 <cone-156> ffmpeg James Almer master:d053290d8dd4: avutil/opt: add an unsigned option type

00:33 <cone-156> ffmpeg James Almer release/7.0:a51c06b42c7b: avutil/iamf: fix offsets for mix_gain options

10:57 <cone-700> ffmpeg Derek Buitenhuis master:f8a613d6a86f: fftools/ffprobe: Avoid overflow when calculating DAR

12:28 <BBB> michaelni: I don't think anyone is intending to switch to gitlab this week, so we can simply have the discussion and nicolas can participate when he is ready and able to

12:33 <Lynne> nicolas isn't able to?

12:34 <Lynne> we must proceed with the discussions at once, with haste

13:45 <jamrial> haasn: your vf_scale framesync change introduced leaks

14:00 <michaelni> Lynne, this would be a bit unfair toward nicolas. I also wait for anton to come back from vaccation and reject my framecrcenc patch :)

14:03 <courmisch> why there are two different functions to find start codes in lavc?

14:04 <michaelni> so they arent lonely

14:10 <Lynne> courmisch: which ones? avpriv_find_start_code and?

14:15 <courmisch> Lynne: and {h264,vc1}dsp.startcode_find_candidate

14:15 <courmisch> so there is a non-optimisable one that is stateful and exact, and an optimisable one that is stateless and allowed spurious matches

14:16 <courmisch> not ideal

14:16 <mkver> courmisch: They do different things: startcode_find_candidate only searches for candidates (currently it searches for 0x00 bytes), the other one only wants exact matches.

14:16 <mkver> I once sent a patchset to optimize the former.

14:18 <courmisch> the DSP one is just reinventing strnlen, yes, at least the C version

14:45 <jamrial> haasn: i fixed it, hopefully. see ml

15:29 <Lynne> JEEB: hey, I don't think the USAC spec I've got is complete

15:30 <Lynne> AccessUnit() is not defined, and I can't find it being referenced in other specs, because of obvious name overlap

15:30 <Lynne> its for preroll

15:32 <Lynne> exhale writes something that more than made me raise an eyebrow - entropy coding state

15:48 <haasn> jamrial: thanks

15:59 <JEEB> Lynne: it should be complete. it can be that it refers to yet another spec o' course

16:14 <Lynne> I think its a macro

16:15 <Lynne> like Config() being defined as being UsacConfig()

16:15 <Lynne> and used only in a few places

16:15 <Lynne> of course a specification needs indirection

17:38 <courmisch> mkver: and why was it not merged?

17:41 <mkver> Because a) I saw slightly positive changes if GCC were told about what is the likely branch, but I did not want to go through the hassle of adding a macro for this. b) When investigating benchmarks on (IIRC) an arm, it turned out that GCC recreated the constants involved in every loop, leading to only a slight performance improvement on this platform. I was curious about whether something better was possible, but never came to

17:41 <mkver> it.

17:44 <fennewald> hey! I had some questions about the implementation of `ff_h2645_extract_rbsp`

17:46 <Lynne> JEEB: nope, definitely not in the spec

17:47 <Lynne> I'll ask the exhale author

17:47 <fennewald> The comment on line 102 (by Anton Khirnov, in 2015), notes that emulation prevention bytes are expected to be rare, on the order of 1:2^22. I cannot find any information that seems to confirm this. Additionally, a scan of a few random hevc files seems to put this occurrence at around 1/2^16, several orders of magnitude more common. Does anyone know the source of the original rate, or where I might find more information about this?

17:48 <mkver> fennewald: An emulation prevention 0x03 needs to be inserted if you have 22 zero bits in a row starting at a byte aligned position.

17:48 <mkver> That's where the 2^22 comes from.

17:49 <jkqxz> That's for the block layer, which is arithmetic coded.

17:49 <jkqxz> There are some fixed places where they can happen in headers, which end up being much more likely for a random sample.

17:50 <mkver> And then there are cabac_zero_words (a form of stuffing) which also lead to 0x03.

17:51 <fennewald> ahh, that makes a lot of sense -- thank you.

17:52 <fennewald> I'm also a little confused by the start code detection logic -- it seems to treat 0x000002 as a start code sequence, but I can't find reference to this sequence in the decoder. Is it just a side effect of emulation prevention that this sequence should never appear in the bitstream?

17:53 <fennewald> *decoder -> spec, sorry

17:53 <mkver> A byte aligned 0x000002 must not happen at all in H.26x, so our decoder can do with it as it wants to.

17:57 <fennewald> understood -- again, thank you for the information.

19:03 <jkqxz> Lynne: Ping for force_integer_mv set.

19:04 <jkqxz> BtbN: You might want to look at it too for the nvidia parts.

19:05 <BtbN> Which set exactly?

19:05 <BtbN> ah, found it

19:06 <jkqxz> Starting <https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2024-April/326288.html>. It modifies nvdec/vdpau, but I can't test them.

19:06 <jkqxz> Should be no change, but seems worth quickly checking if possible.

19:07 <BtbN> The code looks like it comes straight from nvdec, so I doubt that'd break.

19:07 <BtbN> vdpau I can't test either, I think

19:07 <BtbN> since it needs X, and none of my nvidia machines got X

19:08 <BtbN> Will give it a go later. What exactly would break with that field being wrong? Visual Artifacts?

19:10 <jkqxz> Entropy desync, so complete decode failure.

19:11 <jkqxz> Thank you.

19:17 <Lynne> jkqxz: I lgtm'd it on IRC last week, guess you missed that

19:18 <Lynne> do you think it should be backported to 7.0 as well?

19:23 <jkqxz> 1 and 6 maybe? I'd wait for confirmation from the vulkan side about any more mismatches, though.

19:29 <Lynne> the vulkan side, as in the vendors?

19:29 <Lynne> JEEB: no way

19:30 <Lynne> it turns out that instead of sending a given amount of samples to skip, usac just ships ENTIRE FRAMES OF AUDIO to decode and setup state

19:31 <Lynne> and moreover, it does entropy encoding on the **actual frame data**, which has already had entropy encoding, to save fractions of a bit every few hundred bits

19:32 <jkqxz> I'm still confused by the loop filter levels thing. Otherwise it would be nice to hear that it now satisfies the nvidia driver for all the fields noone else cares about.

19:34 <Lynne> jkqxz: I think the entire patchset is fine, not just 1 and 6

21:56 <Lynne> jkqxz: know if you'll have time to look into the AV1/HEVC luma/chroma 8to10 bit conversion triggering spuriously on amd soon?

22:32 <jkqxz> Have you properly tried the answer I suggested? I am pretty sure it is correct.

22:33 <Lynne> if you point me to code to change, I can test

22:34 <jkqxz> (Like, actually made sure that the buffer is as you expect in GPU memory, and can't have been messed up by some intermediate layer thinking (incorrectly) that it knows how big it should be.)

22:34 <Lynne> but we did try zeroing everything

22:34 <jkqxz> I have no idea what the code is. Make sure there are zeroes in the ten bytes or so following the AV1/HEVC decode structure in GPU memory.

22:39 <Lynne> but airlied is pretty sure those fields are present in the headers and set to 0