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

[Sam Jansen]

Hi Gwenole, others,


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

> 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()]
>

Thanks a lot for the pointer to gstreamer. I used this, along with
LIBVA_TRACE, to track down my problem. For anyone in the future looking to
debug such problems, I ended up with a command-line something like the
following:

LIBVA_TRACE=va.trace.txt LIBVA_TRACE_BUFDATA=1  gst-launch-1.0 -v
--gst-debug-level=3 filesrc location=paris_cif_intra.264 ! h264parse !
vaapidecode ! videoconvert !
'video/x-raw,format=(string)I420,width=352,height=288' ! filesink
location=paris_cif_intra.yuv

My problem was that I was using the wrong slice_data_size - it was the size
post emulation prevention, not pre emulation prevention. The slice data
buffer I sent was the correct size, and pre emulation prevention. The
reason this bug was so rare was that it required a NAL unit with 2 bytes of
emulation prevention: with one byte, only the last byte of the slice data
buffer was ignored, and this was always a zero anyway, so it did not
matter. Once we hit a NAL unit with multiple bytes missing, then the last
byte or so of data would be missing, resulting in the chroma bitstream data
being wrong (or, very rarely, the luma data being wrong).

Thanks again,
Sam


> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libva/attachments/20140611/65c7a9d5/attachment.html>