06:52 <nevcairiel> whats up with fate ffmpeg-error-rate-fail? it seems to randomly fail

07:02 <llyyr> nevcairiel: did you have the chance to test it? I tested it on my end and it doesn't regress anything for me

07:02 <llyyr> (the m2ts patch)

07:18 <nevcairiel> like I said in the mail i'll try to get to it this week, but the pre-holiday time is always a bit of a scramble to some projects into this year

07:19 <nevcairiel> the problem i'm suspecting isnt one with well-formed samples, but with one that isnt, so that may need some tinkering

07:20 <llyyr> ah ok

07:20 <llyyr> I'll try to see if I have any weird samples

07:22 <nevcairiel> quickly summarized, the problem that I'm seeing (just from code so far) is that mpegts_resync will look for 0x47 and position the bitstream on that. So assume a sample is damaged and resync is triggered, now the bytestream points at 0x47. With your change, the next read will take off 4 bytes, deleting the 0x47, triggering another resync, and we're in never succeeding again hell.

07:23 <nevcairiel> but for that to happen of course the file needs to be damaged slightly

07:24 <llyyr> it'll only take 4 bytes off if a packet is 192 bytes, the entire file relies on packets being either 188 or 192 bytes, if we cant rely on that then things will explode much before it gets to my change I think

07:25 <nevcairiel> but thats irrelevant to the problem

07:26 <nevcairiel> because of how mpegts_resync works, it always tries to position the bytestream so that "packets" start at 0x47, and the "header" of the next packet essentially becomes the trailer of the current one

07:26 <nevcairiel> so if that happens once, for whatever reason, the assumption of 4 bytes extra infront is thrown off

07:27 <nevcairiel> in theory it should be reproducable by just changing one bit in such a file, i'll try to see later if that actually happens

07:30 <llyyr> that's the exact behavior that causes the first packet to be skipped fwiw, because there's no current_packet-1 to add current_packet's headers to

07:32 <llyyr> if you can make a sample that breaks it lmk so I can adjust the patch, I don't really know much about mpegts this patch started by mirroring mkvtoolnix logic

07:41 <nevcairiel> the patch is probably fine for perfectly well formed files

07:42 <nevcairiel> but as soon as it wants to resync once, it seems like it'll fall apart

07:46 <nevcairiel> (and worse then before)

07:59 <JEEB> the MPEG-TS patch was on my list of checking things, esp. since now IIRC it has a sample that drops first packet?

08:03 <nevcairiel> actually i was just re-thinking how the data flow works with and without the patch, and the way the resync is positioned it may just work, i'll go test my concern of a broken sample case regardless soon just to be sure

08:05 <llyyr> JEEB: yeah, the sample was always there but I didn't know how to actually reproduce the issue with just ffmpeg without using BestSource or something like that

08:05 <llyyr> thankfully the issue can be reproduced with just ffmpeg -c copy

08:06 <JEEB> :)

09:05 <cone-347> ffmpeg Frank Plowman master:9221cb0443ac: lavc/vvc: Use second definition of MinQtLog2SizeIntraC if relevant

09:05 <cone-347> ffmpeg Alexander Strasser master:a280e2e646a2: avcodec/cbs_h266: Fix typo

09:05 <cone-347> ffmpeg Frank Plowman master:7399d9f374db: lavc/vvc: Don't check motion estimation region for IBC

09:05 <cone-347> ffmpeg Frank Plowman master:699322519c9d: lavc/vvc: Store MIP information over entire CU area

09:05 <cone-347> ffmpeg Frank Plowman master:56419fd096c5: lavc/vvc: Fix overflow in MVD derivation

09:05 <cone-347> ffmpeg Frank Plowman master:499896ca2f36: lavc/vvc: Fix derivation of LmcsMaxBinIdx

10:28 <thardin> I appear to be alive again. been sick for the last few days

14:28 <DEATH> Bug report: avcodec_free_context() now frees extradata, which is probably intended, but that's not what the documentation says (extradata allocated/freed by user if decoding)

14:29 <elenril> >now

14:29 <elenril> it always did that

14:29 <elenril> it's a documentation bug

14:29 <elenril> avcodec_close() did not free extradata, but avcodec_free_context() does and always did

14:29 <DEATH> Right. I only noticed when my stuff started crashing after replacing avcodec_close() with avcodec_free_context()

14:38 <DEATH> Anyway, thanks for confirming.

15:21 <Marth64> "it's always DNS", they say

15:21 <Marth64> and indeed DNS strikes again

15:22 <Marth64> </ramble about some unrelated troubleshooting>

16:10 <Compn> dang korea

22:02 <fflogger> [newticket] chuckwoodchuck: Ticket #11330 ([ffmpeg] -f pulse cuts last 2 secodns of audio) created https://trac.ffmpeg.org/ticket/11330

22:07 <Traneptora> if I'm writing an encoder, what constants are assumed by default? i.e. is it assumed that it only supports constant width/height? constant linesize? etc.

22:15 <cone-288> ffmpeg Scott Theisen master:1259760825ac: avformat/mpegts*: reduce use of magic numbers

22:15 <cone-288> ffmpeg Scott Theisen master:5ba63f0ef1ea: avformat/mpegts: is_pes_stream() use switch case

23:26 <pross> Traneptora: you need to check for these assumption in your encode_init() function

23:27 <Traneptora> pross: how do I check for that? i.e. constant linesize