[Mesa-dev] [PATCH v4 0/6] nouveau: add support for vaapi

[Julien Isorce]

Hi,

I found some difference in the content of dec->bsp_bo[i], for h264 when
using st/vdpau (ok) and st/vaapi (ko).

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:

@@ -193,7 +194,23 @@ handlePictureParameterBuffer(vlVaDriver *drv,
vlVaContext *context, vlVaBuffer *
       context->desc.h264.pps->redundant_pic_cnt_present_flag =
          h264->pic_fields.bits.redundant_pic_cnt_present_flag;
       /*reference_pic_flag*/
+      context->desc.h264.is_reference =
h264->pic_fields.bits.reference_pic_flag;
       context->desc.h264.frame_num = h264->frame_num;
+
+      for (i = 0; i < 16; ++i) {
+         if ((h264->ReferenceFrames[i].flags & VA_PICTURE_H264_INVALID) ||
+             (h264->ReferenceFrames[i].picture_id == VA_INVALID_SURFACE))
+            break;
+
+         getReferenceFrame(drv, h264->ReferenceFrames[i].picture_id,
&context->desc.h264.ref[i]);
+
+         context->desc.h264.field_order_cnt_list[i][0] =
h264->ReferenceFrames[i].TopFieldOrderCnt;
+         context->desc.h264.field_order_cnt_list[i][1] =
h264->ReferenceFrames[i].BottomFieldOrderCnt;
+         context->desc.h264.frame_num_list[i] =
h264->ReferenceFrames[i].frame_idx;
+      }

I am surprised that "getReferenceFrame" is not called at all in the h264
case.

Cheers
Julien


On 16 October 2015 at 23:18, Ilia Mirkin <imirkin at alum.mit.edu> wrote:

> On Fri, Oct 16, 2015 at 6:13 PM, Julien Isorce <julien.isorce at gmail.com>
> wrote:
> >
> >
> > On 18 September 2015 at 21:34, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> >>
> >> On Fri, Sep 18, 2015 at 4:29 PM, Julien Isorce <julien.isorce at gmail.com
> >
> >> wrote:
> >> >
> >> >
> >> > On 17 September 2015 at 17:52, Ilia Mirkin <imirkin at alum.mit.edu>
> wrote:
> >> >>
> >> >> On Wed, Sep 16, 2015 at 8:22 AM, Julien Isorce <j.isorce at samsung.com
> >
> >> >> wrote:
> >> >> > I added below version4 updates. It works for all codecs expect
> h264.
> >> >> > Video is visible but lot of blockiness.
> >> >> > Can someone with a Radeon confirm that "LIBVA_DRIVER_NAME=gallium
> mpv
> >> >> > --hwdec=vaapi"
> >> >> > is working on h264 videos ?
> >> >> > I want to make sure it is not a bug in st/va.
> >> >>
> >> >> The sad reality is that h264 is the only thing that matters (at least
> >> >> from this list of supported codecs). My concern is that this series
> >> >> will regress the situation for people who want to use VA-API -- right
> >> >> now they can use the vdpau <-> vaapi adapter, whereas with this patch
> >> >> series, they will end up with a va-api driver that doesn't work. So I
> >> >> can't merge this as-is.
> >> >
> >> >
> >> > Make perfectly sense.
> >> >
> >> >>
> >> >>
> >> >> Are the various lengths (for inter-bo size/etc) being computed
> >> >> properly
> >> >
> >> >
> >> > In the past I compared the final content of the nouveau_bo buffer at
> >> > each
> >> > endFrame step , with the content using vdpau. There were the same.
> >> > I will re-check.
> >> > Does it make sense to do that actually ?
> >> > Is there anything else I could compare with vdpau ?
> >>
> >> If you're feeding the exact same stuff and everything is exactly the
> >> same, then the results would also be the same. Clearly there's SOME
> >> difference SOMEWHERE :)
> >
> >
> > Indeed I compared only dec->bsp_bo, not dec->inter_bo :) I'll check that.
> > But in the first place I do not see where dec->inter_bo is filled. Could
> you
> > point out where this is done ?
>
> nouveau doesn't fill inter_bo -- it's a bo shared between the VLD and
> VDEC engines iirc.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20151110/b08589fd/attachment.html>