GNOME Bugzilla – Bug 534491
caps changed checks only compare pointers
Last modified: 2008-05-29 08:40:32 UTC
I currently track down a problem and noticed these messages in my log. gstpad.c:2769:gst_pad_alloc_buffer_full:<output_level_0x83ae650:src> caps changed from (NULL) to 0x92bca40 audio/x-raw-float, ... There are three places in gstpad.c where they are emitted. The code just compares the caps pointers and not the content. Imho this triggers renegotiation too often. Using gst_caps_is_equal() would address this better. It has quick return path for common cases.
Created attachment 111411 [details] [review] use gst_caps_is_equal
This looks bad to me. It changes behaviour in undesireable 2 ways: 1) Pushing a buffer with NULL caps is now going to flag that the caps have changed and cause re-negotiation to a NULL caps. 2) Buffers can now pass around where the caps stored on the buffer are not the same caps instance as what's been configured on the pad, which has never been allowed before.
Thanks for the feedback, thats why I was posting a patch. I get your point, I will try to figure what went wrong as I have the scenario, where pad and buffer have the same caps-format, but no the same caps object. actualy basetransform uses gst_caps_is_equal() already - that should be rethough maybe...
In other places I remember to see things like caps && (GST_PAD_CAPS (pad) == caps || gst_caps_is_equal (GST_PAD_CAPS (pad), caps))
We should probably define when we want to use caps_changed = caps && caps != GST_PAD_CAPS (pad); and when caps_changed = !gst_caps_is_equal (caps, GST_PAD_CAPS (pad)); The code in comment #4 is kind of superfluous, as includes cehcks for NULL and direct equivalence.