ipcpipelinesink

Communicates with an ipcpipelinesrc element in another process via a socket.

This element, together with ipcpipelinesrc and ipcslavepipeline form a mechanism that allows splitting a single pipeline in different processes. The main use-case for it is a playback pipeline split in two parts, where the first part contains the networking, parsing and demuxing and the second part contains the decoding and display. The intention of this split is to improve security of an application, by letting the networking, parsing and demuxing parts run in a less privileged process than the process that accesses the decoder and display.

Once the pipelines in those different processes have been created, the playback can be controlled entirely from the first pipeline, which is the one that contains ipcpipelinesink. We call this pipeline the “master”. All relevant events and queries sent from the application are sent to the master pipeline and messages to the application are sent from the master pipeline. The second pipeline, in the other process, is transparently slaved.

ipcpipelinesink can work only in push mode and does not synchronize buffers to the clock. Synchronization is meant to happen either at the real sink at the end of the remote slave pipeline, or not to happen at all, if the pipeline is live.

A master pipeline may contain more than one ipcpipelinesink elements, which can be connected either to the same slave pipeline or to different ones.

Communication with ipcpipelinesrc on the slave happens via a socket, using a custom protocol. Each buffer, event, query, message or state change is serialized in a "packet" and sent over the socket. The sender then performs a blocking wait for a reply, if a return code is needed.

All objects that contain a GstStructure (messages, queries, events) are serialized by serializing the GstStructure to a string (gst_structure_to_string). This implies some limitations, of course. All fields of this structures that are not serializable to strings (ex. object pointers) are ignored, except for some cases where custom serialization may occur (ex error/warning/info messages that contain a GError are serialized differently).

Buffers are transported by writing their content directly on the socket. More efficient ways for memory sharing could be implemented in the future.