H.264 encoder produces invalid motion vectors with certain inputs #4
Description
migrated from Bugzilla #97070
status ASSIGNED severity major in component intel for ---
Reported in version unspecified on platform x86-64 (AMD64)
Assigned to: haihao
On 2016-07-25 09:20:14 +0000, Steinar H. Gunderson wrote:
Hi,
This is moved over from https://trac.ffmpeg.org/ticket/5732, which contains somewhat more discussions and info. Long story short, when encoding H.264 video on a Haswell (with a specific, very challenging input), the hardware or driver produces a bitstream that's not spec-compliant and does not play well in libavcodec. However, it is somehow consistently wrong, because libva itself decodes it right.
You can find an example stream (big; 5.1 GB) at http://storage.sesse.net/through-the-cracks.mp4; the first instance corruption happens at 13:50. This is encoded at constant qp 15. There is a smaller, cut-out section (with audio removed) at http://storage.sesse.net/through-the-cracks-cut.mp4 if you just want to see that part.
The original encode was done using my live video mixer, Nageru, which contains a VA-API-based encoder derived from Intel's example H.264 code, running against version 0.7.0 of the Intel VA driver on a desktop Haswell. I can also reproduce this reliably with ffmpeg(1) against version 0.7.1, on my Haswell laptop, so I don't think it's an error of the driving application. I don't have access to Broadwell or Skylake to test.
To reproduce, you can use the uncut .mp4 and reencode it with ffmpeg(1) as follows:
ffmpeg -hwaccel vaapi -ss 12:00 -vaapi_device :0 -i through-the-cracks.mp4 -vf 'format=nv12,hwupload' -c:v h264_vaapi test.mp4 -qp 20
Note the use of -hwaccel vaapi to get VA-API decode instead of libavcodec, so that the encoder has a correct bitstream to work with (as VA-API decodes its own stream correctly).