[Libva] H264 decoder erroneous output, some bytes off-by-one

[Gwenole Beauchesne]

Hi,

2014-06-10 20:33 GMT+02:00 Sam Jansen <sam.jansen at starleaf.com>:

> I've been working on H264 encode, decode, and JPEG decode VA-API programs
> recently, using the Intel va-driver on Sandy Bridge and Bay Trail.
>
> This has gone well, but I've hit a problem with the H264 decoder in some
> situations where I believe it is producing incorrect output. In some cases
> chroma, and less often luma, data does not agree with the reference decoder
> [1], often in Intra frames (but sometimes P frames too), always baseline
> profile. I have an intra-encoded test stream where the 389th frame of a
> stream encoded from the standard "paris (cif)" test stream is incorrect on
> both Sandy Bridge and Bay Trail. Many other test streams pass fine, leaving
> me to believe our decoder implementation is largely correct.
>
> I've also implemented a mode where I am able to get the current encoded
> picture out of the VA-API encoder. I can then compare this, byte-for-byte,
> against a decode of the frame just encoded. I use this with out software
> codecs to ensure our encode and decode match exactly. Using this technique I
> can easily compare our software codec, and the VA-API H264 codecs in any
> combination. I've found the VA-API encode always agrees with our decoder,
> but the VA-API decoder does not always agree with the encode - either our
> software encoder or the VA-API encoder (this testing just on Bay Trail).
>
> I'd like to get to the bottom of this. The first step is removing our decode
> implementation from the test, and using one you believe to be good. What
> tools do you use for regression testing? Is this perhaps ffmpeg invoked in
> some way? Is your test setup open source, such that I can modify it to
> include my new test stream?

The supported HW decoders that use VA-API and can be serve as
reference are either GStreamer/vaapi, or FFmpeg/vaapi (for H.264).
<http://gitorious.org/vaapi/gstreamer-vaapi/>

Please provide me with a sample. We also have other tools, which I
will publish later on.

> PS: here's an extract of some of the chroma bytes where it has gone right.
> On the top, some bytes of reference decoder output, on the bottom, bytes of
> VA-API H264 decoder output. Note the 0x8f83 becomes 0x908f, then 0x8e8e
> becomes 0x8d8d, the 0x8e8e becomes 0x8d8e.

Note: how do you retrieve the bytes for comparison? If this is through
vaGetImage(), the result of the conversion is generally not bitexact.

Regards,
Gwenole.