<div dir="ltr"><div><div><div>Hi Ilia,<br><br></div>Please give another try with these patches (i.e. 1, 2, 3 and 5 from this patch series. 4 and 6 are already merged since I have resubmit them afterward and split in several series). I rebased these four patches on top of latest master here: <a href="https://github.com/CapOM/mesa/commits/st_va_nouveau_chunk_decoding" target="_blank">https://github.com/CapOM/mesa/commits/st_va_nouveau_chunk_decoding</a>  (there was no conflict during rebase)<br><br>h264 is now working properly :), problem was not from these patches but from st/va. Fixes been merged recently (see the 2 latest patches in st/va)<br><br></div><div>Let me know if you see anything wrong when playing video compared to vdpau.<br></div><div><br></div>Cheers<br></div>Julien<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 November 2015 at 09:28, 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 Tue, Nov 10, 2015 at 4:09 AM, Julien Isorce <<a href="mailto:julien.isorce@gmail.com">julien.isorce@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> I found some difference in the content of dec->bsp_bo[i], for h264 when<br>
> using st/vdpau (ok) and st/vaapi (ko).<br>
><br>
> In src/gallium/state_trackers/va/picture.c, at least the reference frames<br>
> are not set. At minimum it is missing something like the following though<br>
> still not enough:<br>
><br>
> @@ -193,7 +194,23 @@ handlePictureParameterBuffer(vlVaDriver *drv,<br>
> 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 =<br>
> 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,<br>
> &context->desc.h264.ref[i]);<br>
> +<br>
> +         context->desc.h264.field_order_cnt_list[i][0] =<br>
> h264->ReferenceFrames[i].TopFieldOrderCnt;<br>
> +         context->desc.h264.field_order_cnt_list[i][1] =<br>
> h264->ReferenceFrames[i].BottomFieldOrderCnt;<br>
> +         context->desc.h264.frame_num_list[i] =<br>
> h264->ReferenceFrames[i].frame_idx;<br>
> +      }<br>
><br>
> I am surprised that "getReferenceFrame" is not called at all in the h264<br>
> case.<br>
<br>
</div></div>Reference frames are a huge part of h264 (all the MPEG codecs in<br>
fact), so I'm guessing there's some different way we're supposed to be<br>
retrieving the information. Perhaps look at where uvd gets it from?<br>
<span class="HOEnZb"><font color="#888888"><br>
  -ilia<br>
</font></span></blockquote></div><br></div>