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

[Gwenole Beauchesne]

2014-06-11 11:58 GMT+02:00 Gwenole Beauchesne <gb.devel at gmail.com>:
> Hi,
>
> 2014-06-11 11:51 GMT+02:00 Sam Jansen <sam.jansen at starleaf.com>:
>> 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!
>
> I have just tried your clip against our internal tools. I can confirm
> that gstreamer-vaapi decodes your file correctly on Ivybridge and
> produces bitexact output, as compared against JM. Likewise for
> FFmpeg/vaapi.
>
> I am afraid, that might be an issue in your code then. :)

Some common errors that could produce what you experience are: issues
related to loop filters, issues decoding the scaling lists correctly.

[since you use vaDeriveImage(), we can definitely exclude the
inacuracies produced by vaGetImage()]

HTH,
Gwenole.

>
>>> > 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.
>>
>>
>
>
> Regards,
> --
> Gwenole Beauchesne
> Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
> Registration Number (RCS): Nanterre B 302 456 199



-- 
Gwenole Beauchesne
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France
Registration Number (RCS): Nanterre B 302 456 199