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 <imir...@alum.mit.edu> wrote:
> On Fri, Oct 16, 2015 at 6:13 PM, Julien Isorce <julien.iso...@gmail.com>
> wrote:
> >
> >
> > On 18 September 2015 at 21:34, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> >>
> >> On Fri, Sep 18, 2015 at 4:29 PM, Julien Isorce <julien.iso...@gmail.com
> >
> >> wrote:
> >> >
> >> >
> >> > On 17 September 2015 at 17:52, Ilia Mirkin <imir...@alum.mit.edu>
> wrote:
> >> >>
> >> >> On Wed, Sep 16, 2015 at 8:22 AM, Julien Isorce <j.iso...@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.
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
