On 5/31/2026 8:39 PM, Michael Niedermayer wrote:
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 lengthThe 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, 0x00000000This 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, 0x033a008athis 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 lengthI 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
Ok, i see what's happening. ac3 and mp2 both define an initial_padding (thus pts starts at -initial_padding) allegedly because those samples are not meant to be part of the eventual decoder output, but then never outputs an extra initial_padding amount of samples on any packet. Commit 355d05a78442c42112186e389efddf811be02262 marked the silence samples added in pad_last_frame() for non variable frame size encoders as to be discarded, and 53d46a51fab73d2aa980c675f4ccb613cde4e7c4 made sure this is propagated to the muxer.
Are the ac3 and mp2 encoders meant to define those priming samples but then never outputting valid ones to compensate for them, like opus, libopus, and libvorbis do?
thx [...]
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
