After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 732213 - vaapidecode: h264, add support for constrained baseline profile
vaapidecode: h264, add support for constrained baseline profile
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer-vaapi
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 732278 (view as bug list)
Depends on: 732239
Blocks:
 
 
Reported: 2014-06-25 09:31 UTC by frank.huber
Modified: 2018-05-04 12:44 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description frank.huber 2014-06-25 09:31:05 UTC 
There is a fix for h264 constrained baseline profile.
But only in gst-plugins-vaapi branch.

Is there a reason, why this fix is not merged to the master tree?
Comment 1 Gwenole Beauchesne 2014-06-25 09:37:21 UTC 
CBP is already supported in the master tree.

You are probably talking about trying to support BP streams, even if the HW does not support those? If so, this cannot happen in the general case. If you really want to allow all baseline profile streams on hardware that only support constrained-baseline, you will need a very robust driver to safely recover from an incorrect submission. This currently is not the case in the current VA driver landscape.

If you submit HW commands that are not going to be supported, this will fail, and you basically risk a DoS. On remote transcoding server farms, this is a high risk. So, it's better to simply not try to support baseline profile streams especially since we can know the hardware would not support those.
Comment 2 frank.huber 2014-06-25 11:56:25 UTC 
You are right, I meant the workaround to enable baseline profile, which is available in gst-plugins-vaapi.
BP is used very often in the field.
Only supporting this new CBP means a lot of encoders/cameras (which are in the field) are not supported with vaapi.
Grrrrr.....
Comment 3 Gwenole Beauchesne 2014-06-25 12:03:48 UTC 
(In reply to comment #2)
> You are right, I meant the workaround to enable baseline profile, which is
> available in gst-plugins-vaapi.
> BP is used very often in the field.
> Only supporting this new CBP means a lot of encoders/cameras (which are in the
> field) are not supported with vaapi.
> Grrrrr.....

If you know a decent way to detect baseline profile clips that don't involve ASO and FMO, without the need to parse PPS or slice-header, then I would happily look into it.

Otherwise, the current approach is to let h264parse expose the detected profile in caps, and let autopluging machinery pick up a valid decoder. e.g. SW fallback with libavcodec, or that CISCO baseline profile decoder.

And yes, failing early also has the advantage to allow fallbacks. Otherwise, you'd need to reconfigure the pipeline.
Comment 4 Gwenole Beauchesne 2014-06-25 12:07:06 UTC 
Note: that fallback machinery does not work yet either. That's something to implement, and related to bug #730997 too.
Comment 5 Gwenole Beauchesne 2014-06-26 12:06:38 UTC 
*** Bug 732278 has been marked as a duplicate of this bug. ***
Comment 6 sreerenj 2016-03-24 16:53:51 UTC 
Moving to Product:GStreamer, Component:gstreamer-vaapi
Comment 7 Víctor Manuel Jáquez Leal 2018-05-04 12:44:56 UTC 
baseline profile is deprecated in libva 2.0