Hi Ilia,
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:
https://github.com/CapOM/mesa/commits/st_va_nouveau_chunk_decoding (there
was no conflict during rebase)
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)
Let me know if you see anything wrong when playing video compared to vdpau.
Cheers
Julien
On 10 November 2015 at 09:28, Ilia Mirkin <imir...@alum.mit.edu> wrote:
> On Tue, Nov 10, 2015 at 4:09 AM, Julien Isorce <julien.iso...@gmail.com>
> wrote:
> > 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.
>
> Reference frames are a huge part of h264 (all the MPEG codecs in
> fact), so I'm guessing there's some different way we're supposed to be
> retrieving the information. Perhaps look at where uvd gets it from?
>
> -ilia
>
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
