GNOME Bugzilla – Bug 697177
decodebin2: caps are considered final too often when optional fields are present in raw caps
Last modified: 2013-04-03 14:54:31 UTC
Created attachment 240481 [details] [review] 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
This sounds very much like a case of "known issue, fixed in 1.0" :) I think the best solution for you is to do whatever you need to do in an "autoplug-continue" callback instead of using the "caps" property. I'm not sure it's fixable in 0.10.
Hmm, I see. Closing, then, thanks.