[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 #24 from Orestis Floros <orestisf1993 at gmail.com> ---
(In reply to sreerenj from comment #23)
> (In reply to Orestis Floros from comment #22)
> > Created attachment 358028 [details] [review] [review]
> > (In reply to sreerenj from comment #21)
> > 
> > > One access unit can have multiple view components, and yes you don't have to
> > > add the slice_ext in the code for checking the complete_au. Sorry about the
> > > confusion.
> > > But ideally, we should add other checkings like "compare the view_ids of
> > > nals" for vcl boundary detection (even though current code can work without
> > > that).
> > 
> > I think this requires the previous slice / vlc nalu right? I think h264parse
> > doesn't keep that.
> 
> Yup, It requires some extra parsing code. But no need to include that one
> here I believe (unless it is necessary to fix any known issue). 
> 
> > 
> > > BTW I hit a segfault issue while testing your branch:
> > > 
> > > Generate an mvc sample like this: 
> > > gst-launch-1.0 -v videotestsrc num-buffers=30 blocksize=115200 !
> > > vaapih264enc num-views=2 ! video/x-h264, profile=stereo-high ! filesink
> > > location=sample.mvc
> > > 
> > > playback the stream with only base view
> > > gst-launch-1.0 filesrc location=sample.mvc ! h264parse ! vaapih264dec
> > > base-only=true ! vaapisink
> > 
> > Thanks, fixed.
> 
> K great.
> So I guess the only know issue is
> https://bugzilla.gnome.org/show_bug.cgi?id=732266#c18 . right?

yes.

The errors:

SVCHS-2.264:
lt-gst-launch-1.0: gen75_mfd.c:556: gen75_mfd_avc_img_state: Assertion
`pic_param->pic_fields.bits.field_pic_flag == 0' failed.

SVCHS-2-L1.264:
lt-gst-launch-1.0: gen75_mfd.c:556: gen75_mfd_avc_img_state: Assertion
`pic_param->pic_fields.bits.field_pic_flag == 0' failed.

SVCHST-3.264:
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0

SVCHST-3-L1.264:
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0
vaapi gstvaapidecoder_h264.c:2752:find_long_term_reference: found no long-term
reference picture with LongTermPicNum = 0

SVCHST-4.264 and SVCHST-4-L1.264 don't have any errors in the log but the video
is still wrong.

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