Hi james On Sun, May 31, 2026 at 03:47:53PM -0300, James Almer via ffmpeg-devel wrote: > On 5/30/2026 11:33 PM, Michael Niedermayer wrote: > > Hi > > > > this leads to corruption at the end of mp2 and ac3 > > > > huffyuv_mp2.mkv > > 221184 tmpvid.raw > > -32016 tmpaud.raw > > - 0 0 3999# 0 0 3999# 0 0 > > +31760 tmpaud.raw > > + 0 0 3999# 0 0 3999# 0 1 A > > ------ > > huffyuv_libmp3lame.mkv > > 221184 tmpvid.raw > > @@ -146,8 +146,8 @@ > > ------ > > huffyuv_ac3.mkv > > 221184 tmpvid.raw > > -32192 tmpaud.raw > > - 0 0 3999# 0 0 3999# 0 0 > > +31936 tmpaud.raw > > + 0 0 3999# 0 0 3999# 0 1 A > > > > the A at the end means the audio and video tracks differ in length > > The only part of the process that ever handles packet and/or frame skip > samples side data in this scenario is the matroska demuxer, meaning mp2.mkv > and libmp3lame.mkv have a DISCARD_PADDING element in the last packet. Also, > is this huffyuv program setting the AV_CODEC_FLAG2_SKIP_MANUAL flag on the > decoders? > > > > > > > If you look at framecrc you see this: > > before: > > 0, 7, 7, 1, 110592, 0x3e9a9a45 > > 1, 113408, 113408, 1536, 3072, 0x00000000 > > 1, 114944, 114944, 1536, 3072, 0x00000000 > > 1, 116480, 116480, 1536, 3072, 0x00000000 > > 1, 118016, 118016, 1536, 3072, 0x00000000 > > 1, 119552, 119552, 1536, 3072, 0x00000000 > > 1, 121088, 121088, 1536, 3072, 0x00000000 > > 1, 122624, 122624, 1536, 3072, 0x00000000 > > 1, 124160, 124160, 1536, 3072, 0x00000000 > > 1, 125696, 125696, 1536, 3072, 0x00000000 > > 1, 127232, 127232, 1536, 3072, 0x00000000 > > > > > > after: > > 0, 7, 7, 1, 110592, 0x3e9a9a45 > > 1, 113408, 113408, 1536, 3072, 0x00000000 > > 1, 114944, 114944, 1536, 3072, 0x00000000 > > 1, 116480, 116480, 1536, 3072, 0x00000000 > > 1, 118016, 118016, 1536, 3072, 0x00000000 > > 1, 119552, 119552, 1536, 3072, 0x00000000 > > 1, 121088, 121088, 1536, 3072, 0x00000000 > > 1, 122624, 122624, 1536, 3072, 0x00000000 > > 1, 124160, 124160, 1536, 3072, 0x00000000 > > 1, 125696, 125696, 1536, 3072, 0x00000000 > > 1, 127232, 127232, 512, 1024, 0x00000000 > > This is the output of what? If i do a simple "ffmpeg -i > sample_with_discard_padding.mkv -f framecrc -" i get something like the > latter, given the decoder dropped the padding samples. If i add "-flags2 > skip_manual" as input arguments, i get the former (with the skip_samples > side data presence being listed next to the hash). > > Namely: > > 0, 45768, 45768, 960, 3840, 0x98058c39 > 0, 46728, 46728, 960, 3840, 0xef789935 > 0, 47688, 47688, 312, 1248, 0x977b74f2 > > vs > > 0, 45792, 45792, 960, 3840, 0x98058c39 > 0, 46752, 46752, 960, 3840, 0xef789935 > 0, 47712, 47712, 960, 3840, 0xafadd1ec, S=1, Skip > Samples, 10, 0x033a008a > > > > > this is a encoder side issue > > > > basically before this commit audio+video with identical length stay > > identical > > after thue > > audio+video with identical length are not identical length after encoding > > > > you should be abel to replicate that with any rawvideo + rawaudio input > > of same length > > I need more information about this. The generic encoding code is propagating > the skip_samples side data in the input frame to the encoded packet instead > of dropping it. In a normal transcoding scenario, this would only happen if > you request "-flags2 skip_manual" so the samples are not discarded at the > end of the decoding process and the side data is therefore left in place.
Sorry for the incomplete informnation what generates the files is this: FFMPEG -f u8 -ar 8000 -ac 1 -i sync_audio.raw -f rawvideo -framerate 2 -s 192x144 -pix_fmt gray -i sync_video.raw -vcodec $VCODEC -acodec $ACODEC -y -strict -2 -r 2 $* $FILE FFMPEG -nostats -debug_ts -i $FILE -y -s 192x144 -pix_fmt gray -f rawvideo -vsync passthrough -enc_time_base 1/51200 tmpvid.raw -ac 1 -ar 8000 -f u8 tmpaud.raw the relevant parameters for these should be 2 of these 3 check huffyuv ac3 huffyuv_ac3.mov check huffyuv ac3 huffyuv_ac3.mov -use_editlist 0 check huffyuv mp2 huffyuv_mp2.mkv if this doesnt replicate then dont waste your time, just tell me and ill build a proper testcase thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
