GNOME Bugzilla – Bug 502891
deterministic realtime behaviour
Last modified: 2011-03-11 08:17:33 UTC
This is a tracker bug to design what it need to make gstreamer behave deterministicly during GST_STATE_PLAYING. This is especially important when assigning realtime privileges to threads (see Bug 501239). Right now gstreamer is e.g. allocating and freeing memory at playing time. The libc allocator is not suited for realtime criteria. Smaller allocation are done from pools and releasing them can cause trimming pools. The later can cause significant delays. GSlice is not an option as it uses thread local pools that require locking when freeing buffers allocated from different threads. What options are there: 1.) switching off trimming using mallopt() http://www.zeroc.com/faq/largeRequests.html http://www.linuxjournal.com/article/6390 2.) reuse objects example in Bug 500653 3.) use a different allocator http://rtportal.upv.es/rtmalloc/ http://goog-perftools.sourceforge.net/doc/tcmalloc.html Some further links: http://en.wikipedia.org/wiki/Malloc#External_links
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).
Its not for hard-realtime use. One issue we noticed it that on arm libc2.5 we several time miss scheduling targets because a free takes 30 ms. I am far from expert on the matters, I basically try to collect what can be done to avoid that problem or even lessen the likelyhood. The above case was in the audio-part of an rtp pipeline. Similar use case would be audio rendering like in buzztard (no disk access involved).
I am closing this. We're having the buffer pools comming. Lots of locking has been removed. The stream status parts are in place.