Display corruption on very high-bitrate H.264 files
|Reported by:||Sesse||Owned by:|
|Blocking:||Reproduced by developer:||yes|
|Analyzed by developer:||no|
I've discovered what I believe is a bug in the H.264 decoder of libavcodec. It concerns the following file, where the video is encoded using Intel Quick Sync Video (on a Haswell, via VA-API) at constant quantizer:
Unfortunately, the file is very big (~5.1GB), and attempts to cut it using ffmpeg(1) resulted in something VLC wouldn't play, so I've left it alone save for remuxing (it was originally in NUT) and audio reencoding.
The corruption happens around 13:50, in the right-hand side of the picture. You can see it by decoding using ffmpeg(1):
ffmpeg -ss 13:50 -i /srv/storage.sesse.net/through-the-cracks.mp4 -vframes 50 out-%03d.png
and then looking at out-*.png. The errors persist from out-001.png to out-019.png; they disappear at out-020.png (perhaps new keyframe?) and come back at out-045.png. It looks like some kind of overflow to me, probably due to the extreme bitrate chosen (around 170 Mbit/sec; this content is super-hard to encode!).
The file plays perfectly in VLC if and only if I enable VA-API hardware acceleration, so that it's decoded in hardware instead of by libavcodec's H.264 decoder.
Change History (22)
comment:11 by , 5 years ago
|Priority:||normal → minor|
|Reproduced by developer:||set|
|Status:||new → open|