[Bug 732266] vaapidecode: h264: add support for decoding SVC base layers only

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=732266

--- Comment #54 from Orestis Floros <orestisf1993 at gmail.com> ---
Created attachment 358456
  --> https://bugzilla.gnome.org/attachment.cgi?id=358456&action=edit
libs: decoder: h264: remove non-Annex-A nals for base-only

(In reply to sreerenj from comment #53)
> (In reply to Orestis Floros from comment #52)
> > (In reply to sreerenj from comment #51)
> > > Review of attachment 358431 [details] [review] [review] [review]:
> > >
> > > ::: gst-libs/gst/vaapi/gstvaapidecoder_h264.c
> > > @@ +4716,3 @@
> > >    pi->flags = flags;
> > > +  if (!priv->base_only || pi->nalu.type != GST_H264_NAL_PREFIX_UNIT)
> > > +    gst_vaapi_parser_info_h264_replace (&priv->prev_pi, pi);
> > >
> > > For a base-only use case, why shouldn't we treat both prefix_nal and
> > > slice_ext in a similar way?
> > > Here both slice_ext and prefix_nal are set for SKIP. But slice_ext still get
> > > stored in prev_pi??
> >
> > The reason for this change is because PREFIX NALs get used in parse_slice()
> > which leads to the MVC freeze issue from comment #42. I didn't see a reason
> > to include slice_ext.
>
> Here the base-only == AnnexA based stream. If so, why we still considering
> slice_extenion for frame/au boundary detection?

I generally tried to not modify the process as much in the spirit of bug
732265. In the end, I believe that actually dropping NALs 14, 15, 20 is more
elegant, less hackish and I think a bit faster too.

This patch here shows the difference in complexity.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.