GNOME Bugzilla – Bug 580967
shared memory based sink and source
Last modified: 2010-06-03 20:48:10 UTC
I've written a set of shared memory sink and source for inter-process communication between pipelines. They currently use a single shared memory segment for all communications including the caps and the actual buffer contents. Also EOS events as well as most details from the buffers are transfered. Except for the timestamp, I'm not sure how to properly transfer the timestamps, so I just made the source into a live source. Also, tags are not transfered. I'm attaching it as a patch against gst-p-bad.
Created attachment 133714 [details] [review] actual implementation of the shm sink/src Also, I did some testing on an OMAP3 dev board and even on that relatively slow platform, it takes very little CPU time (unlike, lets say, using gdppay->filesink->fifo->filesrc->gdpdepay).
While I'm at it, a more complete version would also have multiple buffers so we can use buffer_alloc to reduce the overhead even more.
You should check for shmem support in configure and you could also use gst_element_class_set_details_simple() as this is more optimal :) Apart from that, do you want to wait until you have support for multiple buffers until this can be committed or is there anything else blocking it?
Haven't looked at the code, just wondering if you've considered/tried using gdp? Isn't it able to write into/read from the shared buffers directly?
(In reply to comment #4) > Haven't looked at the code, just wondering if you've considered/tried using > gdp? Isn't it able to write into/read from the shared buffers directly? I was under the impression that gdp is geared towards streaming, one of the problems I see with it is that the caps are sent just once. But with the current element, one could start reading at any point. But maybe it could be used (it would be useful to serialise events, etc). (In reply to comment #3) > Apart from that, do you want to wait until you have support for multiple > buffers until this can be committed or is there anything else blocking it? I'll add configure checks and add it to sys/ in gst-p-bad I guess, other improvements can come later. Although I was really careful to use only POSIX stuff, it probably wont work in win32.
Any news on this?
not really, haven't had time to work on it
Comment on attachment 133714 [details] [review] actual implementation of the shm sink/src I completely re-wrote the element to provide pipe-like semantics. There is also more than one buffer and the sink does pad allocation, so true inter-process zero-copy is implemented. The actual shared memory stuff has been split into separate files that have no GLib/GStreamer dependencies and can be integrated easily into other applications. To have gdp like functionality (carrying caps and timing information), one should use gdppay/depay. Left to do (but possibly post-commit), is to add support for stuff like bufferlists. Also possibly use a smarter allocator for the shared memory area The code is at: http://git.collabora.co.uk/?p=user/tester/gst-plugins-bad.git;a=tree;f=gst/shm;hb=shm-pipe
This has been committed now it seems.
Oh yes it has!