[gst-devel] more caps

[David Schleef]

On Wed, Dec 24, 2003 at 05:40:47PM +0100, Ronald Bultje wrote:
> Hi,
> 
> Now, while we're at it, I'd like to add something to Benjamin's email
> with questions:
> 
> - is gst_pad_get_allowed_caps() broken? Is it intended to return the
> currently allowed caps given by the intersection of both getcaps()
> functions of the two pads in a link or something else? I mentioned this
> on IRC already but it's no obvious to me.

No, it's not broken.  get_allowed_caps() is the view (from the element)
about what the element can set its own pad's caps to.  It is absolutely
critical that get_allowed_caps() doesn't call the getcaps() function on
the element's own pad.  The element presumably already knows that
information, and moreover, is allowed to ignore its own getcaps function
whenever it wants to.  (It shouldn't be ignoring its pad template,
however.)

> - I actually like Benjamin's idea of deprecating try_set_caps(). Not for
> 0.8.0, but still, we can make a start for 0.8 (simply allowing it, but
> not recommending it) and complete it in 0.10. It forces correct element
> writing which is a good thing.

As I stated in the other email, try_set_caps() serves a different
purpose, and decreases element code considerably.

> - How is ownership of caps done? I see a lot of gst_caps_copy() around
> in various places (e.g. try_set_caps(pad, caps) copies the caps before
> using it), has anyone valgrind'ed this yet or ensured that this works
> correctly? Was there a strong reason to remove caps ref()'ing or is this
> just "part of the job" (in which case I think it's a bad idea)?

It theoretically works correctly, although there are a lot of leaks
currently.  Ignore them for now; we have more important things to
worry about.  In my observation, caps are only duplicated needlessly
in about 2 places.  In other cases, the caps are typically immediately
modified which negates the usefulness of refcounting.

"theoretically" == "strictly follows well-established rules"

> - is fixate() supposed to be used by the application instead of 'plain
> simple' filtered caps in a pad link? This is lovely (really!). I also
> think the function is broken:
> 
> while (!gst_caps_is_fixed (caps)) {
> 
> This will loop endlessly if the app fixate function doesn't fixate it
> fully.

Fixate functions are supposed to return NULL if the function didn't
make the caps closer to fixed.

Btw, there's no function to add a application fixate function (yet).

> - Why is GstPadLink private? (It seems like link->caps is what
> GST_PAD_CAPS() should use?)

It's intended to be an internal structure which is there only because
I thought it was stupid to have two copies of everything in the pads.
It also makes it possible to renegotiate without losing the filter
caps.  (This was one of the cases where caps were needlessly duplicated.)



dave...