#6350 closed defect (duplicate)
n3.3 corrupts when remuxing mp4->mp4 or mp4->mkv
Reported by: | carstenmattner | Owned by: | |
---|---|---|---|
Priority: | important | Component: | ffmpeg |
Version: | git-master | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
Steps to reproduce:
- copy ffmpeg
n3.3
version to./ffmpeg33
- remux mp4 -> mkv or mp4 -> mp4 while recoding the audio track
- 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.
Change History (7)
follow-up: 4 comment:2 by , 6 years ago
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.
comment:3 by , 6 years ago
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.
comment:4 by , 6 years ago
Reproduced by developer: | set |
---|---|
Status: | new → open |
Version: | unspecified → git-master |
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".
comment:5 by , 6 years ago
Resolution: | → duplicate |
---|---|
Status: | open → closed |
Duplicate of ticket #6275 which has a bad title, sorry.
comment:7 by , 6 years ago
Should be fixed in c4be288fdbe1993110f1abd28ea57587cb2bc221 (git master) and 58a8e4733ae0b597aa0c92bdc73462a9fe8114cc (release/3.3).
n3.2.4
IIRC didn't have this regression but I'm back atn2.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 withn3.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.