<div dir="ltr">Hi Gwenole, others,<div class="gmail_extra"><br><br><div class="gmail_quote">On 11 June 2014 11:00, Gwenole Beauchesne <span dir="ltr"><<a href="mailto:gb.devel@gmail.com" target="_blank">gb.devel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2014-06-11 11:58 GMT+02:00 Gwenole Beauchesne <<a href="mailto:gb.devel@gmail.com">gb.devel@gmail.com</a>>:<br>
<div><div class="h5">> Hi,<br>
><br>
> 2014-06-11 11:51 GMT+02:00 Sam Jansen <<a href="mailto:sam.jansen@starleaf.com">sam.jansen@starleaf.com</a>>:<br>
>> Hi all,<br>
>><br>
>> Thanks for the quick replies!<br>
>><br>
>><br>
>> On 11 June 2014 05:54, Gwenole Beauchesne <<a href="mailto:gb.devel@gmail.com">gb.devel@gmail.com</a>> wrote:<br>
>>><br>
>>> Hi,<br>
>>><br>
>>> 2014-06-10 20:33 GMT+02:00 Sam Jansen <<a href="mailto:sam.jansen@starleaf.com">sam.jansen@starleaf.com</a>>:<br>
>>><br>
>>> > I've been working on H264 encode, decode, and JPEG decode VA-API<br>
>>> > programs<br>
>>> > recently, using the Intel va-driver on Sandy Bridge and Bay Trail.<br>
>>> ><br>
>>> > This has gone well, but I've hit a problem with the H264 decoder in some<br>
>>> > situations where I believe it is producing incorrect output. In some<br>
>>> > cases<br>
>>> > chroma, and less often luma, data does not agree with the reference<br>
>>> > decoder<br>
>>> > [1], often in Intra frames (but sometimes P frames too), always baseline<br>
>>> > profile. I have an intra-encoded test stream where the 389th frame of a<br>
>>> > stream encoded from the standard "paris (cif)" test stream is incorrect<br>
>>> > on<br>
>>> > both Sandy Bridge and Bay Trail. Many other test streams pass fine,<br>
>>> > leaving<br>
>>> > me to believe our decoder implementation is largely correct.<br>
>>> ><br>
>>> > I've also implemented a mode where I am able to get the current encoded<br>
>>> > picture out of the VA-API encoder. I can then compare this,<br>
>>> > byte-for-byte,<br>
>>> > against a decode of the frame just encoded. I use this with out software<br>
>>> > codecs to ensure our encode and decode match exactly. Using this<br>
>>> > technique I<br>
>>> > can easily compare our software codec, and the VA-API H264 codecs in any<br>
>>> > combination. I've found the VA-API encode always agrees with our<br>
>>> > decoder,<br>
>>> > but the VA-API decoder does not always agree with the encode - either<br>
>>> > our<br>
>>> > software encoder or the VA-API encoder (this testing just on Bay Trail).<br>
>>> ><br>
>>> > I'd like to get to the bottom of this. The first step is removing our<br>
>>> > decode<br>
>>> > implementation from the test, and using one you believe to be good. What<br>
>>> > tools do you use for regression testing? Is this perhaps ffmpeg invoked<br>
>>> > in<br>
>>> > some way? Is your test setup open source, such that I can modify it to<br>
>>> > include my new test stream?<br>
>>><br>
>>> The supported HW decoders that use VA-API and can be serve as<br>
>>> reference are either GStreamer/vaapi, or FFmpeg/vaapi (for H.264).<br>
>>> <<a href="http://gitorious.org/vaapi/gstreamer-vaapi/" target="_blank">http://gitorious.org/vaapi/gstreamer-vaapi/</a>><br>
>>><br>
>>> Please provide me with a sample. We also have other tools, which I<br>
>>> will publish later on.<br>
>>><br>
>><br>
>> I've made it temporarily available at:<br>
>> <a href="http://cam.starleaf.com/paris_cif_intra.264" target="_blank">http://cam.starleaf.com/paris_cif_intra.264</a><br>
>><br>
>> Feel free to have a look at it. You're welcome to add it to whatever test<br>
>> suite you have as well. However, I'm happy right now that I should first use<br>
>> your gstreamer-vaapi to decode it, and check I get the same result there. I<br>
>> would have thought the most likely explanation at this point in time is that<br>
>> I have a bug in my VA-API H264 decoder -- I'd rather you didn't waste your<br>
>> time on my bugs!<br>
><br>
> I have just tried your clip against our internal tools. I can confirm<br>
> that gstreamer-vaapi decodes your file correctly on Ivybridge and<br>
> produces bitexact output, as compared against JM. Likewise for<br>
> FFmpeg/vaapi.<br>
><br>
> I am afraid, that might be an issue in your code then. :)<br>
<br>
</div></div>Some common errors that could produce what you experience are: issues<br>
related to loop filters, issues decoding the scaling lists correctly.<br>
<br>
[since you use vaDeriveImage(), we can definitely exclude the<br>
inacuracies produced by vaGetImage()]<br></blockquote><div><br></div><div>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:</div>
<div><br></div><div>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<br>
</div><div><br></div><div>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).</div>
<div><br></div><div>Thanks again,</div><div>Sam</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
HTH,<br>
Gwenole.<br>
<div class=""><div class="h5"><br>
><br>
>>> > PS: here's an extract of some of the chroma bytes where it has gone<br>
>>> > right.<br>
>>> > On the top, some bytes of reference decoder output, on the bottom, bytes<br>
>>> > of<br>
>>> > VA-API H264 decoder output. Note the 0x8f83 becomes 0x908f, then 0x8e8e<br>
>>> > becomes 0x8d8d, the 0x8e8e becomes 0x8d8e.<br>
>>><br>
>>> Note: how do you retrieve the bytes for comparison? If this is through<br>
>>> vaGetImage(), the result of the conversion is generally not bitexact.<br>
>>><br>
>><br>
>> I use vaDeriveImage(), which gives me a VA_FOURCC_NV12 image. I then<br>
>> vaMapBuffer() it to get at the image data.<br>
>><br>
>>><br>
>>> Regards,<br>
>>> Gwenole.<br>
>><br>
>><br>
><br>
><br>
> Regards,<br>
> --<br>
> Gwenole Beauchesne<br>
> Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France<br>
> Registration Number (RCS): Nanterre B 302 456 199<br>
<br>
<br>
<br>
--<br>
Gwenole Beauchesne<br>
Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France<br>
Registration Number (RCS): Nanterre B 302 456 199<br>
</div></div></blockquote></div><br></div></div>