Bisect Information:

b58bdd1a1239c2996c42b417db31632d596de9c4 is the first bad commit
commit b58bdd1a1239c2996c42b417db31632d596de9c4
Author: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
Date:   Wed Oct 29 15:46:47 2014 +0200

    vaapidecode: Expose the supported profiles as caps to upstream

    This will allows the playbin to fallback to Software Decoder
    if the Hardware Decoder does not support a particular profile.

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

this issue also can be reproduced when testing MVC decoding.
TEST COMMAND:
gst-launch-1.0 -q filesrc location=/media/mvc/MVCDS-1.264 '!' vaapiparse_h264 '!' video/x-h264,stream-format=byte-stream,alignment=au '!' vaapidecode '!' vaapisink sync=false

LOG:
[root@x-ivb3 opt]# gst-launch-1.0 -q filesrc location=/media/mvc/MVCDS-1.264 '!' vaapiparse_h264 '!' video/x-h264,stream-format=byte-stream,alignment=au '!' vaapidecode '!' vaapisink sync=false
(gst-plugin-scanner:7527): GStreamer-WARNING **: Failed to load plugin '/opt/X11R7/gstreamer10/lib/gstreamer-1.0/libgstx264.so': libx264.so.142: cannot open shared object file: No such file or directory
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_36
libva info: va_openDriver() returns 0
ERROR: from element /GstPipeline:pipeline0/GstVaapiH264Parse:vaapih264parse0: GStreamer encountered a general stream error.
Additional debug info:
gstbaseparse.c(3249): gst_base_parse_loop (): /GstPipeline:pipeline0/GstVaapiH264Parse:vaapih264parse0:
streaming stopped, reason not-negotiated
ERROR: pipeline doesn't want to preroll

The h264parse element reports "extended" profile for this stream (BA3_SVA_C), which is supposedly not supported. However, the h264parse element should also report alternate profiles that are compatible, e.g. "main" profile.

Likewise, for MVCDS-1, the Ivybridge platform does not fully support the whole MultiView High profile set. However, a subset of it could still be supported. i.e. the h264parse element should also expose "stereo-high" in this case.

PS: when I say "h264parse", this also includes "vaapiparse_h264" since that corresponds to the upstream h264parse element.

(In reply to comment #3)
> The h264parse element reports "extended" profile for this stream (BA3_SVA_C),
> which is supposedly not supported. However, the h264parse element should also
> report alternate profiles that are compatible, e.g. "main" profile.
>

The parser element is providing a fixed caps dynamically which is the exact profile indicated in the coded header. Do you mean that the parser should provide the subset profiles (constrained base line & baseline) too?

> Likewise, for MVCDS-1, the Ivybridge platform does not fully support the whole
> MultiView High profile set. However, a subset of it could still be supported.
> i.e. the h264parse element should also expose "stereo-high" in this case.
> 
> PS: when I say "h264parse", this also includes "vaapiparse_h264" since that
> corresponds to the upstream h264parse element.

(In reply to comment #4)
> (In reply to comment #3)
> > The h264parse element reports "extended" profile for this stream (BA3_SVA_C),
> > which is supposedly not supported. However, the h264parse element should also
> > report alternate profiles that are compatible, e.g. "main" profile.
> >
> 
> The parser element is providing a fixed caps dynamically which is the exact
> profile indicated in the coded header. Do you mean that the parser should
> provide the subset profiles (constrained base line & baseline) too?

Yes, for negotiation purposes, and also further helping fallbacks. e.g. for MVC cases, we could have { multiview-high, stereo-high, high }; For AVC high, this implies generating a valid substream for an AVC decoder.

Changed to High priority, because it caused many test cases failed and big pass rate drop.

Are we talking about multiple issues here? I can't reproduce the issue with the stream MVCDS-1.264 , which is running fine in my HSW machine. There is no reason to fail the mvc streams. The first sps will advertise the high profile and the second sps(ssps) will advertise the multiview-high profile, there is no negotiation problem!

(In reply to comment #7)
> Are we talking about multiple issues here? I can't reproduce the issue with the
> stream MVCDS-1.264 , which is running fine in my HSW machine. There is no
> reason to fail the mvc streams. The first sps will advertise the high profile
> and the second sps(ssps) will advertise the multiview-high profile, there is no
> negotiation problem!

sorry, maybe it's mutiple issues. only IVB/SNB/BYT can reproduce this issue. and HSW/BDW cannot reproduce it.

(In reply to comment #8)
> (In reply to comment #7)
> > Are we talking about multiple issues here? I can't reproduce the issue with the
> > stream MVCDS-1.264 , which is running fine in my HSW machine. There is no
> > reason to fail the mvc streams. The first sps will advertise the high profile
> > and the second sps(ssps) will advertise the multiview-high profile, there is no
> > negotiation problem!
> 
sorry, maybe it's mutiple issues. For mvc decoding test. only IVB/SNB/BYT can reproduce the "general stream error"issue. and HSW/BDW cannot reproduce it.

(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > Are we talking about multiple issues here? I can't reproduce the issue with the
> > > stream MVCDS-1.264 , which is running fine in my HSW machine. There is no
> > > reason to fail the mvc streams. The first sps will advertise the high profile
> > > and the second sps(ssps) will advertise the multiview-high profile, there is no
> > > negotiation problem!
> > 
> sorry, maybe it's mutiple issues. For mvc decoding test. only IVB/SNB/BYT can
> reproduce the "general stream error"issue. and HSW/BDW cannot reproduce it.

Okay, comment 3 is the explanation for that anyway..

(In reply to comment #6)
> Changed to High priority, because it caused many test cases failed and big pass
> rate drop.

Please mention all of them, because we can still pass 168/168 tests here from the conformance test suite for H.264 AVC.

Are we supposed to support the streams under extended profile (even though they have constraint_set1_flag==1) ? I mean, did we include those streams in test suite? Then I afraid that the h264parser needs to be changed to advertise a single profile which is equal to main for this type of streams.

Download the priority to Normal because 739713/739714 issues were fixed and total pass rate of all the media features came back to the acceptable value for QA. 
1), currently just 1 failed case for H264 decoding
2), currently 45 failed MVC decoding cases just happened on IVB/SNB/BYT platformas, but all passed on BSW/BDW/HSW.

(In reply to comment #13)
> Download the priority to Normal because 739713/739714 issues were fixed and
> total pass rate of all the media features came back to the acceptable value for
> QA. 
> 1), currently just 1 failed case for H264 decoding
> 2), currently 45 failed MVC decoding cases just happened on IVB/SNB/BYT
> platformas, but all passed on BSW/BDW/HSW.
Correct the typo as below
Download the priority--> Degrade the priority

Created attachment 291702 [details] [review]
patches/videoparsers: h264: expose compatible profiles to downstream

(In reply to comment #13)
> Download the priority to Normal because 739713/739714 issues were fixed and
> total pass rate of all the media features came back to the acceptable value for
> QA. 
> 1), currently just 1 failed case for H264 decoding
> 2), currently 45 failed MVC decoding cases just happened on IVB/SNB/BYT
> platformas, but all passed on BSW/BDW/HSW.

Could you please have a try with the attached patch?

(In reply to comment #16)
> (In reply to comment #13)
> > Download the priority to Normal because 739713/739714 issues were fixed and
> > total pass rate of all the media features came back to the acceptable value for
> > QA. 
> > 1), currently just 1 failed case for H264 decoding
> > 2), currently 45 failed MVC decoding cases just happened on IVB/SNB/BYT
> > platformas, but all passed on BSW/BDW/HSW.
> 
> Could you please have a try with the attached patch?

With your patch, 
    1), currently just 1 failed case for H264 decodin
    ===》 Verified and Passed.
    2), currently 45 failed MVC decoding cases just happened on IVB/SNB/BYT
platformas, but all passed on BSW/BDW/HSW.
   ====》 Also Can reproduce this issue.

Error Log:
[root@x-sgbmedia opt]# gst-launch-1.0 -q filesrc location=/media/mvc/MVCDS-1.264 ! vaapiparse_h264 '!' video/x-h264,stream-format=byte-stream,alignment=au '!' vaapidecode '!' vaapisink sync=false
libva info: VA-API version 0.36.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /opt/X11R7/lib/dri/i965_drv_video.so
libva info: Found init function __vaDriverInit_0_36
libva info: va_openDriver() returns 0
ERROR: from element /GstPipeline:pipeline0/GstVaapiH264Parse:vaapih264parse0: GStreamer encountered a general stream error.
Additional debug info:
gstbaseparse.c(3249): gst_base_parse_loop (): /GstPipeline:pipeline0/GstVaapiH264Parse:vaapih264parse0:
streaming stopped, reason not-negotiated
ERROR: pipeline doesn't want to preroll.

Aha, vaapiparse_h264 is not parsing/storing the subset_sps, which requires another patch and that should fix your issue :)

BTW, the correct patch to fix this will be based on the patch acceptance of https://bugzilla.gnome.org/show_bug.cgi?id=739992 . So we should wait a bit more..

file another bug to track MVC decoding issue.
Bug 741631 - [SNB|IVB|BYT][Media][Decode]GStreamer encountered a general stream error when doing MVC decoding test
(https://bugzilla.gnome.org/show_bug.cgi?id=741631)

Please test the gstreamer-vaapi from master branch now..
Note: The mvc stream issue is not yet fixed(#741631)...

After a clean build I could execute both pipelines without any issues in my hardware:

$ jhbuild run gst-launch-1.0 filesrc location= ~/patterns/BA3_SVA_C.264  ! vaapiparse_h264 ! vaapidecode ! vaapisink sync=false -v

$ jhbuild run gst-launch-1.0 filesrc location=~/patterns/MVCDS-1.264  ! vaapiparse_h264 ! vaapidecode ! vaapisink sync=false -v

And, obviously, using h264parse instead of vaapiparse_h264, the same results are shown.

I wonder if we should close this bug or, if I am missing something regarding the different hardware setups.

(In reply to comment #21)
> After a clean build I could execute both pipelines without any issues in my
> hardware:
> 
> $ jhbuild run gst-launch-1.0 filesrc location= ~/patterns/BA3_SVA_C.264  !
> vaapiparse_h264 ! vaapidecode ! vaapisink sync=false -v
> 
> $ jhbuild run gst-launch-1.0 filesrc location=~/patterns/MVCDS-1.264  !
> vaapiparse_h264 ! vaapidecode ! vaapisink sync=false -v
> 
> And, obviously, using h264parse instead of vaapiparse_h264, the same results
> are shown.
> 
> I wonder if we should close this bug or, if I am missing something regarding
> the different hardware setups.

This got fixed by the commit http://cgit.freedesktop.org/gstreamer/gst-plugins-bad/commit/?id=542c77ab3831388f162a78878ba8902cd5c4d9f9 (6 days ago) in upstream. so h264parse will work fine

The same patch has merged to internal gstreamer-codecparsers on yesterday, so vaapiparse_h264 will also work fine :) 

Let's wait for QA to confirm before closing...

Verified and Passed. So Close it.

Verified ENV:
Gstreamer10:(1.4)ae4c70813b936c5c507a8f47d0532612f1419e50
Gst_plugins_base10:(1.4)094f90c4c55da9017decb80b922e48cda77a93c6
Gst_plugins_good10:(1.4)ab60576c97d200cfac626e3f6e5d5efa440939ef
Gst_plugins_ugly10:(1.4)e94ce59c72961cc5e94adb19525f49a92e88636c
Gst_plugins_vaapi10:(master)6e395c60acd604055f37af2b4cba82c03e1acb10