<div dir="ltr"><div>Hi,<br><br></div>I found some difference in the content of dec->bsp_bo[i], for h264 when using st/vdpau (ok) and st/vaapi (ko).<br><div><div><div><div><div><br>In src/gallium/state_trackers/va/picture.c, at least the reference frames are not set. At minimum it is missing something like the following though still not enough:<br><br>@@ -193,7 +194,23 @@ handlePictureParameterBuffer(vlVaDriver *drv, vlVaContext *context, vlVaBuffer *<br>       context->desc.h264.pps->redundant_pic_cnt_present_flag =<br>          h264->pic_fields.bits.redundant_pic_cnt_present_flag;<br>       /*reference_pic_flag*/<br>+      context->desc.h264.is_reference = h264->pic_fields.bits.reference_pic_flag;<br>       context->desc.h264.frame_num = h264->frame_num;<br>+<br>+      for (i = 0; i < 16; ++i) {<br>+         if ((h264->ReferenceFrames[i].flags & VA_PICTURE_H264_INVALID) ||<br>+             (h264->ReferenceFrames[i].picture_id == VA_INVALID_SURFACE))<br>+            break;<br>+<br>+         getReferenceFrame(drv, h264->ReferenceFrames[i].picture_id, &context->desc.h264.ref[i]);<br>+<br>+         context->desc.h264.field_order_cnt_list[i][0] = h264->ReferenceFrames[i].TopFieldOrderCnt;<br>+         context->desc.h264.field_order_cnt_list[i][1] = h264->ReferenceFrames[i].BottomFieldOrderCnt;<br>+         context->desc.h264.frame_num_list[i] = h264->ReferenceFrames[i].frame_idx;<br>+      }<br><br></div><div>I am surprised that "getReferenceFrame" is not called at all in the h264 case. <br><br></div><div>Cheers<br></div><div>Julien<br></div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 October 2015 at 23:18, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Oct 16, 2015 at 6:13 PM, Julien Isorce <<a href="mailto:julien.isorce@gmail.com">julien.isorce@gmail.com</a>> wrote:<br>
><br>
><br>
> On 18 September 2015 at 21:34, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br>
>><br>
>> On Fri, Sep 18, 2015 at 4:29 PM, Julien Isorce <<a href="mailto:julien.isorce@gmail.com">julien.isorce@gmail.com</a>><br>
>> wrote:<br>
>> ><br>
>> ><br>
>> > On 17 September 2015 at 17:52, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br>
>> >><br>
>> >> On Wed, Sep 16, 2015 at 8:22 AM, Julien Isorce <<a href="mailto:j.isorce@samsung.com">j.isorce@samsung.com</a>><br>
>> >> wrote:<br>
>> >> > I added below version4 updates. It works for all codecs expect h264.<br>
>> >> > Video is visible but lot of blockiness.<br>
>> >> > Can someone with a Radeon confirm that "LIBVA_DRIVER_NAME=gallium mpv<br>
>> >> > --hwdec=vaapi"<br>
>> >> > is working on h264 videos ?<br>
>> >> > I want to make sure it is not a bug in st/va.<br>
>> >><br>
>> >> The sad reality is that h264 is the only thing that matters (at least<br>
>> >> from this list of supported codecs). My concern is that this series<br>
>> >> will regress the situation for people who want to use VA-API -- right<br>
>> >> now they can use the vdpau <-> vaapi adapter, whereas with this patch<br>
>> >> series, they will end up with a va-api driver that doesn't work. So I<br>
>> >> can't merge this as-is.<br>
>> ><br>
>> ><br>
>> > Make perfectly sense.<br>
>> ><br>
>> >><br>
>> >><br>
>> >> Are the various lengths (for inter-bo size/etc) being computed<br>
>> >> properly<br>
>> ><br>
>> ><br>
>> > In the past I compared the final content of the nouveau_bo buffer at<br>
>> > each<br>
>> > endFrame step , with the content using vdpau. There were the same.<br>
>> > I will re-check.<br>
>> > Does it make sense to do that actually ?<br>
>> > Is there anything else I could compare with vdpau ?<br>
>><br>
>> If you're feeding the exact same stuff and everything is exactly the<br>
>> same, then the results would also be the same. Clearly there's SOME<br>
>> difference SOMEWHERE :)<br>
><br>
><br>
> Indeed I compared only dec->bsp_bo, not dec->inter_bo :) I'll check that.<br>
> But in the first place I do not see where dec->inter_bo is filled. Could you<br>
> point out where this is done ?<br>
<br>
</div></div>nouveau doesn't fill inter_bo -- it's a bo shared between the VLD and<br>
VDEC engines iirc.<br>
</blockquote></div><br></div>