[Bug 697177] New: decodebin2: caps are considered final too often when optional fields are present in raw caps

GStreamer (bugzilla.gnome.org) bugzilla at gnome.org
Wed Apr 3 07:18:24 PDT 2013


https://bugzilla.gnome.org/show_bug.cgi?id=697177
  GStreamer | gst-plugins-base | unspecified

           Summary: decodebin2: caps are considered final too often when
                    optional fields are present in raw caps
    Classification: Platform
           Product: GStreamer
           Version: unspecified
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-base
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: vincent.penquerch at collabora.co.uk
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=240481)
 View: https://bugzilla.gnome.org/attachment.cgi?id=240481
 Review: https://bugzilla.gnome.org/review?bug=697177&attachment=240481

Potential patch - fixes my issue, but may break others

decodebin2 will consider some caps as final, though it should not, in the
following case:

- Set the "caps" property on decodebin2 to something including fields, eg:
video/x-h264,width=854,height=480;audio/x-vorbis
- Set the source to a MP4 file which will go through qtdemux, this file having
a different size that the above caps

qtdemux will output caps without width/height set. decodebin2 will try to
intersect the caps, and succeed, and thus consider the caps from qtdemux as
final, and will not attempt to plug a decoder in.

This becomes important when there is an encodebin later (ie, source !
decodebin2 ! encodebin ! sink), where this encodebin is instructed to perform
some scaling via caps restrictions on its profile. If the input has the same
encoded format as what is requested on the output of encodebin, decodebin2 will
not decode, and encodebin will be unable to resize encoded video, passing it
through unscaled.

A patch attached fixes the issue, but is not quite right. Testing for caps
subset does not work either, as gst_caps_is_subset will happily lie about
video/x-h264, parsed=(boolean)true, stream-format=(string){ avc, byte-stream },
alignment=(string){ au, nal } being a subset of video/x-h264, width=(int)854,
height=(int)48.

This could be argued to be a bug in _is_subset, but this has been known for a
while as a known limitation I think.

Sample file that shows the issue:
http://people.collabora.com/~vincent/big_buck_bunny_1080p_h264_hbh_20MB.m4v

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- 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