[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