2014-06-11 11:58 GMT+02:00 Gwenole Beauchesne <[email protected]>: > Hi, > > 2014-06-11 11:51 GMT+02:00 Sam Jansen <[email protected]>: >> Hi all, >> >> Thanks for the quick replies! >> >> >> On 11 June 2014 05:54, Gwenole Beauchesne <[email protected]> wrote: >>> >>> Hi, >>> >>> 2014-06-10 20:33 GMT+02:00 Sam Jansen <[email protected]>: >>> >>> > 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 _______________________________________________ Libva mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libva
