[gstreamer-bugs] [Bug 621299] simple thread barrier element

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #8 from Stefan Kost (gstreamer, gtkdoc dev) <ensonic at sonicpulse.de> 2010-06-12 20:23:55 UTC ---
(In reply to comment #6)
> queue doesn't use gobject signaling internally anymore.

Sure it does. It provides 4 signals - underrun, running, overrun and pushing.

> The size calculation
> routines could also be shunted if in the max-size-buffers==1 case.
> 
> I'd much prefer optimizing the hell out of queue in that case than having
> another element which is so similar to queue.

That would be okay for me as well. I was mainly doing the elements also to see
what potential gains we can get still.

(In reply to comment #7)

> Not sure this is correct to assume in general. It may be true for some very
> specific use cases, but very often you will still want queues which can hold
> more than 1 buffer after demuxers and tee.

The element in the patch is not limmited to 1 buffer.

> I'd rather improve queue/multiqueue etc. than introduce yet another element
> that can only be used in very specific circumstances (as if this stuff wasn't
> hard enough already).

I actualy belive tee should just start new tasks for each pad and use queues
internaly (we could have a queue helper like adapter). If we would have a
demuxer baseclas then this could have the multi-queue functuality. But this is
maybe something for 0.11.

> Regarding the playbin2 case, where there is a very small queue in front of the
> sinks, we could just add another flag to make playbin2 not plug these, for
> sinks that have internal queues.

The flag in playbin2 would be not so nice, as it pushes the decision to the
application (of course this is not anyhow better if we have a queue that can be
deactivated). Now I am thinking that ideally we have some query (?) / flag on
elements to be able to figure whether the have a linear output behaviour or
not.

I'll try to see if I can easily achieve the same performance improvement in
regular queue (e.g. by adding a "no-signals" / "silent" property).

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