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

[Sam Jansen]

Hi all,

Thanks for the quick replies!


On 11 June 2014 05:54, Gwenole Beauchesne <gb.devel at gmail.com> wrote:

> 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.
>
>
I've made it temporarily available at:
http://cam.starleaf.com/paris_cif_intra.264

Feel free to have a look at it. You're welcome to add it to whatever test
suite you have as well. However, I'm happy right now that I should first
use your gstreamer-vaapi to decode it, and check I get the same result
there. I would have thought the most likely explanation at this point in
time is that I have a bug in my VA-API H264 decoder -- I'd rather you
didn't waste your time on my bugs!


> > 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.
>
>
I use vaDeriveImage(), which gives me a VA_FOURCC_NV12 image. I then
vaMapBuffer() it to get at the image data.


> Regards,
> Gwenole.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20140611/052b4954/attachment.html>