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

## Hierarchy

    GObject
        ╰──GInitiallyUnowned
            ╰──GstObject
                ╰──GstElement
                    ╰──ipcpipelinesink

## Factory details

Authors: – Vincent Penquerc'h

Classification: – `Sink`

Rank – none

Plugin – ipcpipeline

Package – GStreamer Bad Plug-ins

## Pad Templates

### `sink`

    ANY

Presence – always

Direction – sink

Object type – GstPad

## Action Signals

### disconnect

    g_signal_emit_by_name (param_0, "disconnect");

    ret = param_0.emit ("disconnect")

    let ret = param_0.emit ("disconnect");

Parameters:

`param_0` (GstElement *) –
No description available

Flags: Run Last / Action

## Properties

### ack-time

    “ack-time” guint64

Maximum time to wait for a response to a message

Flags : Read / Write

Default value : 10000000

### fdin

    “fdin” gint

File descriptor to received data from

Flags : Read / Write

Default value : -1

### fdout

    “fdout” gint

File descriptor to send data through

Flags : Read / Write

Default value : -1

### read-chunk-size

    “read-chunk-size” guint

Read chunk size

Flags : Read / Write

Default value : 4096

The results of the search are