01:04 <SuperFashi> jamrial: do you remember the reason you made this change in the first place?

01:11 <jamrial> SuperFashi: yeah, because it was resuting in merged information when src had no extradata

01:12 <jamrial> SuperFashi: try the patchset i just sent

01:34 <SuperFashi> jamrial: It kinda works? for some reason the first few samples are still reporting errors

01:40 <SuperFashi> oh i don't think it works, it still clears the data needed if i play with `-probesize`

01:49 <jamrial> can you share the samples?

02:01 <SuperFashi> the commit https://github.com/superfashi/FFmpeg/commit/b5816cfeb3cba7ecd230d18192ac1cb401e22a54 (includes revert of d383ae43c266b160348db04f2fd17ccf30286784). Sample https://files.catbox.moe/5caifg.mmts

07:47 <cone-275> ffmpeg Matthieu Bouron master:8cdf1bae942c: avcodec/jni: fix mixed declaration and code

11:42 <cone-623> ffmpeg Andreas Rheinhardt master:277f051ff6a9: avcodec/pthread_frame: Fix leak of coded side data

12:13 <sfan5> by chance has anyone used mbedtls 3.6.0 with ffmpeg and can confirm that it works?

12:25 <sfan5> because after upgrading from 3.5.2 all I get is "[tls @ 0xb4000071387ab310] mbedtls_ssl_handshake returned -0x6c00", and I couldn't reproduce this error outside of ffmpeg

13:08 <cone-623> ffmpeg Jun Zhao master:d9f72eb107da: lavc/vvc_parser: Remove max_b_frames setting

13:08 <cone-623> ffmpeg Jun Zhao master:50b8666dc695: lavc/vvc_parser: Fixed the has_b_frames setting

13:08 <cone-623> ffmpeg Jun Zhao master:822e2843ca1c: lavc/vvc/refs: Use dpb_max_num_reorder_pics to control output

13:33 <BtbN> The mbedtls implementation is known to be wonky

13:33 <BtbN> people also reported rtmps plain not working with it

13:40 <frankplow> Is there a reason behind the oss-fuzz crashes not being made public? Would it be bad if I were to release crash bitstreams from my own fuzz server (all for the VVC decoder, to provide a roadmap towards removing the experimental flag)?

13:45 <mindfreeze> frankplow: i suspect it might be due to security reasons, some crashes can be non-trivial and can be huge security flaw. I do notknow the reasoning in ffmpeg use-case

13:45 <mindfreeze> I seen some other projects making it public after it getting patched, some others doing it post-release cut

13:50 <mkver> BtbN: Coverity needs a kick again.

13:50 <Lynne> frankplow: no, go ahead

13:50 <frankplow> mindfreeze: Yeah it makes sense you want to give developers some time to patch an issue before releasing it publicly, else you might have nefarious characters developing exploits for the issue. I suppose more my question is would anybody be opposed to me releasing these bitstreams for the particular case of the VVC decoder, given it is marked as experimental?

13:50 <Lynne> the decoder is experimental after all, though that doesn't affect it in my opinion

13:52 <BtbN> mkver: hm, it seems to have failed on something

13:52 <BtbN> needs more than a kick this time

15:18 <cone-623> ffmpeg Andreas Rheinhardt master:1d17d84b7d56: avcodec/progressframe: Explain how unnamed union can simplify accesses

15:18 <cone-623> ffmpeg Andreas Rheinhardt master:0ec886ddc79c: avcodec/hevcdec: Use union for AVFrame* and ProgressFrame

15:18 <cone-623> ffmpeg Andreas Rheinhardt master:0f8763fbea4e: avcodec/av1dec: Use ProgressFrames

15:18 <cone-623> ffmpeg Andreas Rheinhardt master:20206e14d748: avcodec/av1dec: Make av1_frame_replace() out of av1_frame_ref()

21:23 <BtbN> Sometimes I really lose faith... "You can see there is --enable-fontconfig but not --enable-libfontconfig. Do you know how can I enable it?"