n3.3 corrupts when remuxing mp4->mp4 or mp4->mkv

[carstenmattner]

Steps to reproduce:

1. copy ffmpeg n3.3 version to ./ffmpeg33
2. remux mp4 -> mkv or mp4 -> mp4 while recoding the audio track
3. play back and notice visible corruption and error messages like:

[ffmpeg/video] h264: co located POCs unavailable
or
WARNING: Invalid RefPicListX[] entry!!! It is not included in DPB

If we assume there's ./ffmpeg33 and system-wide ffmpeg is n2.8.11, then this repros the regression:

youtube-dl -f 18 --restrict-filenames https://www.youtube.com/watch?v=jNQXAC9IVRw
ffmpeg -i Me_at_the_zoo-jNQXAC9IVRw.mp4 -c:a libopus -c:v copy Me_at_the_zoo-jNQXAC9IVRw.ffmpeg28.mkv
./ffmpeg33 -i Me_at_the_zoo-jNQXAC9IVRw.mp4 -c:a libopus -c:v copy Me_at_the_zoo-jNQXAC9IVRw.ffmpeg33.mkv
ffmpeg -i Me_at_the_zoo-jNQXAC9IVRw.mp4 -strict -2 -c:a aac -c:v copy Me_at_the_zoo-jNQXAC9IVRw.ffmpeg28.mp4
./ffmpeg33 -i Me_at_the_zoo-jNQXAC9IVRw.mp4 -strict -2 -c:a aac -c:v copy Me_at_the_zoo-jNQXAC9IVRw.ffmpeg33.mp4

I initially noticed this with -c:a libfdk_aac -vbr 3, but the corruption happens with opus and built-in aac too.

The files ending in .ffmpeg28.m?? will play fine and provoke zero errors, while the other two ending in .ffmpeg33.m?? will print at least the RefPicListX error and also show visible corruption in the form of either green blocks with mpv vaapi hw-accel or grey/transparent corruption blocks in mpv software decoding mode.

[carstenmattner]

n3.2.4 IIRC didn't have this regression but I'm back at n2.8.11 since I had the pleasure of recoding a sizable number of videos that got corrupted during recoding the audio track. I haven't run the same repro steps with n3.2.4. This was unfortunate since I had to run video recoding as well from pristine high bitrate sources, in addition to the audio track. It took more or less two days of CPU.

[carstenmattner]

I would consider this bug critical since it silently corrupts and doesn't noticeably crash, but I didn't know if you consider this critical as well so important is what I chose as severity.

[carstenmattner]

I've also noticed that some streaming sites have already updated to the new ffmpeg version since I see the same corruption and RefPicListX and co located POCs error in pristine mp4 files downloaded from the HTML5 media element's link. I didn't touch the downloaded file and tested with a 2nd download to be sure.

It's up to ffmpeg devs how to prioritize this but I think it's a serious regression. The n3.3 release announcement says

We strongly recommend users, distributors, and system integrators to upgrade unless they use current git master.

so it's normal that distros and admins have already updated.

[James]

Regression since af1761f7b5b1b72197dc40934953b775c2d951cc. A bunch of frames at the beginning are not being copied to the output file.

$ youtube-dl -f 18 --restrict-filenames https://www.youtube.com/watch?v=jNQXAC9IVRw

$ ./ffmpeg -i Me_at_the_zoo-jNQXAC9IVRw.mp4 -vframes 9 -c:v copy -an -f framecrc -
#extradata 0:       37, 0xd9bf0acd
#software: Lavf57.72.101
#tb 0: 1/15
#media_type 0: video
#codec_id 0: h264
#dimensions 0: 320x240
#sar 0: 1/1
0,          0,          0,        1,    12783, 0xdea0e2ed
0,          1,          1,        1,      758, 0x464e901e, F=0x0
0,          2,          2,        1,     1333, 0xed209cf2, F=0x0
0,          3,          3,        1,     1578, 0xe3d6363c, F=0x0
0,          4,          4,        1,     1056, 0xd32e2f83, F=0x0
0,          5,          5,        1,     1855, 0xf37fc03e, F=0x0
0,          6,          6,        1,     1773, 0xfe439ac6, F=0x0
0,          7,          7,        1,     1806, 0x8da5a08c, F=0x0
0,          8,          8,        1,     2306, 0xdd7e8f1a, F=0x0

$ ./ffmpeg -i Me_at_the_zoo-jNQXAC9IVRw.mp4 -c:a aac -c:v copy out.mp4

$ ./ffmpeg -i out.mp4 -vframes 2 -c:v copy -an -f framecrc -
#extradata 0:       37, 0xd9bf0acd
#software: Lavf57.72.101
#tb 0: 1/15360
#media_type 0: video
#codec_id 0: h264
#dimensions 0: 320x240
#sar 0: 1/1
0,          0,          0,     8192,    12783, 0xdea0e2ed
0,       8192,       8192,     1024,     2306, 0xdd7e8f1a, F=0x0

$ ./ffmpeg_ref -i Me_at_the_zoo-jNQXAC9IVRw.mp4 -c:a aac -c:v copy out_ref.mp4

$ ./ffmpeg -i out_ref.mp4 -vframes 9 -c:v copy -an -f framecrc -
#extradata 0:       37, 0xd9bf0acd
#software: Lavf57.72.101
#tb 0: 1/15360
#media_type 0: video
#codec_id 0: h264
#dimensions 0: 320x240
#sar 0: 1/1
0,          0,          0,     1024,    12783, 0xdea0e2ed
0,       1024,       1024,     1024,      758, 0x464e901e, F=0x0
0,       2048,       2048,     1024,     1333, 0xed209cf2, F=0x0
0,       3072,       3072,     1024,     1578, 0xe3d6363c, F=0x0
0,       4096,       4096,     1024,     1056, 0xd32e2f83, F=0x0
0,       5120,       5120,     1024,     1855, 0xf37fc03e, F=0x0
0,       6144,       6144,     1024,     1773, 0xfe439ac6, F=0x0
0,       7168,       7168,     1024,     1806, 0x8da5a08c, F=0x0
0,       8192,       8192,     1024,     2306, 0xdd7e8f1a, F=0x0

Replying to carstenmattner:

I would consider this bug critical since it silently corrupts and doesn't noticeably crash, but I didn't know if you consider this critical as well so important is what I chose as severity.

"critical" is reserved for data loss, AKA, ffmpeg overwriting input files, configure script deleting things outside the build directory, etc.

Regressions in transcoding and such are "important".

[Carl Eugen Hoyos]

Duplicate of ticket #6275 which has a bad title, sorry.

[Carl Eugen Hoyos]

And / or #6227.

[James]

Should be fixed in c4be288fdbe1993110f1abd28ea57587cb2bc221 (git master) and 58a8e4733ae0b597aa0c92bdc73462a9fe8114cc (release/3.3).