[gstreamer-bugs] [Bug 502891] deterministic realtime behaviour

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=502891

  GStreamer | gstreamer (core) | Ver: HEAD CVS

Wim Taymans changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim.taymans at gmail.com




------- Comment #1 from Wim Taymans  2007-12-10 18:20 UTC -------
Maybe you should state first what kind of pipelines you want to support. 
Realtime behaviour will only work in a very specific set of pipelines where
nothing dynamic happens from the streaming threads after negotiation of caps
and buffers. This likely means no signal emisions, no messages or tags etc..
position/duration queries and object properties need a different kind of
locking. 

Also you could likely improve GSlice to use a lockfree stack when releasing
memory from the threadlocal pool back to the global pool. You would also
require that you can prealloc a fixed number of slices of a size and that
memory is not freed while streaming.

We maybe also need something like GstBufferPool (from back in the 0.6 days). It
would allow elements to negotiate a set of buffers of a certain size that will
be used during streaming and would avoid dynamic allocations along with a way
to block when out of buffers and cancel when shutting down (much harder or
impossible with current _pad_alloc).


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=502891.