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 732278 - gstvaapidecoder_h264.c: unsupported profile_idc 66
gstvaapidecoder_h264.c: unsupported profile_idc 66
Status: RESOLVED DUPLICATE of bug 732213
Product: gstreamer-vaapi
Classification: Other
Component: general
0.5.8
Other Linux
: Normal normal
: ---
Assigned To: gstreamer-vaapi maintainer(s)
gstreamer-vaapi maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-06-26 12:00 UTC by Stuart
Modified: 2014-06-26 12:06 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Stuart 2014-06-26 12:00:14 UTC
Hi, currently getting the above error when decoding with vaapidecode. Googling what the profile_idc 66 means comes back that it is a baseline profile. Looking through the source seems to then link back to gstvaapiutils_h264.c line 195-197 with the following:

   switch (profile) {
     case GST_VAAPI_PROFILE_H264_BASELINE:
     case GST_VAAPI_PROFILE_H264_CONSTRAINED_BASELINE:
       profile_idc = GST_H264_PROFILE_BASELINE;

Should the GST_VAAPI_PROFILE_H264_BASELINE case do nothing? Also should the constrained baseline be going to normal baseline? i.e. does VAAPI support baseline or is it leaving this to be sorted in software?

Opened a bug as unsure if this is correct or not!

Best Regards,
Stuart
Comment 1 Gwenole Beauchesne 2014-06-26 12:06:38 UTC
Plain baseline profile streams cannot be supported in the general case. I am not aware of any HW decoder that fully support this anyway. That's probably why the constrained baseline profile was introduced. So, profile_idc = 66 but constraint_set0_flag = 1 would indicate that no FMO/ASO is used.

You could resort to some workarounds, but this would be very limited. The plan is to let decoders be auto-plugged and delegate "baseline" profile clips to SW decoding.

*** This bug has been marked as a duplicate of bug 732213 ***