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

GStreamer (GNOME Bugzilla) bugzilla at gnome.org
Tue Aug 15 23:14:05 UTC 2017


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

--- Comment #5 from sreerenj <bsreerenj at gmail.com> ---
(In reply to Orestis Floros from comment #4)
> (In reply to sreerenj from comment #3)
> > (In reply to Orestis Floros from comment #1)
> > > SVC streams proved to be a bit tricky. Following the same method I used in
> > > bug 732265 doesn't work and so I try to flag NAL units 14, 15 and 20 with
> > > GST_VAAPI_DECODER_UNIT_FLAG_SKIP in gst_vaapi_decoder_h264_parse().
> > > The problem I am facing right now is with the
> > > GST_VAAPI_DECODER_UNIT_FLAG_FRAME_END flag.
> > > h264parse uses the whole stream and doesn't "detect" AU start and end
> > > correctly, this means that at_au_end is not reliable. 
> > 
> > If there is an issue with h264parse to correctly detect the AU, why can't we
> > try to fix that issue first(in h264parse)? 
> > IIUC from your comments, fixing h264parse to make the AU detection correct
> > for SVC will help to make the vaapih264dec patch simple enough like what you
> > did for #732265, right?
> 
> Are we actually sure that h264parse is wrong here? I assumed it was because
> of the extra units but never thought it could be this. For example, in the
> sequence 14 05 20 20 20 where AU END is set on the last NAL the detection
> could be correct for an SVC stream but there is no way for h264parse to know
> that the downstream element doesn't want the non-Annex-A NALUs.

There could be errors in h264parse too. Even for MVC there were few
misinterpretations in frame boundary detection(not sure it is fixed now).
For SVC, there are many missing points. First of all, we haven't added svc
parsing support in codecparser library(gst-libs/gst/codecparsers) yet. So what
ever header parsing you do in gst/videoparsers/gsth264parse.c is going to fail
most likely.

But before going into those, I recommend you to enable the "pass-through" mode
in h264parse (so that it won't do any parsing or skipping) and add the
base-only support in vaapih264dec(why can't it work like your mvc patch?).

"Sequence 14 05 20 20 20 where the AU END set on last nal" means: A multi-slice
encoded stream with different nal types which is wrong I believe. Because if
there an IDR slice, all other slices in the same picture should be also IDR.

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


More information about the gstreamer-bugs mailing list