GNOME Bugzilla – Bug 590856
[decodebin2] triggers assertion failure on NULL caps
Last modified: 2009-08-12 11:41:49 UTC
When analyzing new pads, NULL or empty caps are treated as unknown/unhandled caps. However, gst_pb_utils_get_decoder_description does not appreciate NULL caps, and the corresponding missing decoder message for NULL caps may also be a bit off.
Created attachment 139943 [details] [review] Possible fix Avoid assertion failure on NULL caps, and provide alternative message. [Do not know if there is a case where NULL or empty should be considered as "not yet known" and therefore sent down the delayed path, though probably not]
IMHO that patch is correct but OTOH pads here should not have empty caps either. I guess the patch can be committed but what elements provided pads with empty caps here?
This can happen if a _get_caps tries to provide caps that are a not a subset of template caps (e.g. width or height out or template range). That is pretty unusual in itself, but this already has warnings of its own (and there may be other cases).
Also (nitpicking), shouldn't the ("Stream caps %" GST_PTR_FORMAT, caps) in the else case where we know caps is NULL read something else?
GST_PTR_FORMAT should properly handle a NULL pointer, with a sufficiently meaningful message as a result, though taste may vary here (or maybe more can/should be said?)
commit 188d69844911491323385a7d5b1833778286aac0 Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk> Date: Wed Aug 5 15:36:30 2009 +0200 decodebin2: avoid assertion failure on empty/NULL caps