On 5/30/2026 11:33 PM, Michael Niedermayer wrote:
Hithis 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, 0xef7899350, 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.
if people want i can look into adding this test to fate, but my todo is long so might take some time thx [...]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
