[gstreamer-bugs] [Bug 618853] add caps intersection iterators

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=618853
  GStreamer | gstreamer (core) | unspecified

--- Comment #12 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-05-18 06:58:49 UTC ---
(In reply to comment #9)
> Review of attachment 161234 [details]:
> 
> Looks good in general, some comments below. Question is still how we could
> support ANY/EMPTY caps :) From all ideas that were proposed so far, I like
> Edwards idea to use singleton iterators for those and have macros for checking
> against them most.

I am trying that right now.

> 
> ::: gst/gstcaps.c
> @@ +1515,3 @@
> +  /* - we don't need an ItemFunction because we create new items in _next
> +   * - we ref the caps and thus they can't change, we still need a dummy
> cookie
> +   * - we have no lock
> 
> It might be a good idea to allow some kind of cookie for the case when element
> properties change for example. This should then require a resync and getting
> new caps. Same goes for the lock.

Hmm. If you currently run a intersect it would be a sync() call that don't not
take any parallel property changes into account. Do you have a use case in mind
where the iterator is keept and iterated slowly over time? Basically the caps
are reffed and thus immutable during the lifetime of the iterator. The iterator
becomes invalid if the caps change, but the iterator does not know where to get
the new ones from, so it cannot resync itself in that case. 
Also what should the lock protect? The caps that are intersected are usuly from
two different elements, so we'd need to take two locks if at all.

> 
> @@ +1697,3 @@
> + * Since: 0.10.XXX
> + */
> +/* FIXME: should this take ownership of the iterators? */
> 
> Yes, gst_iterator_filter() for example does this too.

Will do that.

> 
> @@ +1707,3 @@
> +  /* - we don't need an ItemFunction because we create new items in _next
> +   * - we ref the caps and thus they can't change, we still need a dummy
> cookie
> +   * - we have no lock
> 
> A lock and cookie might be good to allow for the same reasons as above.
> 
> ::: gst/gstpad.c
> @@ +2395,3 @@
> +    }
> +  }
> +  if ((templ = GST_PAD_PAD_TEMPLATE (pad))) {
> 
> If the pad has no getcapsiterator function you should simply call
> gst_pad_get_caps()

Good idea, done!

-- 
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.