## ipcpipelinesink

ipcpipelinesink

## Properties

guint64 | ack-time | Read / Write
gint | fdin | Read / Write
gint | fdout | Read / Write
guint | read-chunk-size | Read / Write

## Signals

void | disconnect | Action

## Types and Values

struct | GstIpcPipelineSink

## Object Hierarchy

        GObject
        ╰── GInitiallyUnowned
            ╰── GstObject
                ╰── GstElement
                    ╰── GstIpcPipelineSink

## Description

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

## Synopsis

### Element Information

plugin | ipcpipeline
author | Vincent Penquerc'h <vincent.penquerch@collabora.co.uk>
class | Sink

### Element Pads

name | sink
direction | sink
presence | always
details | ANY

## Functions

## Types and Values

### struct GstIpcPipelineSink

    struct GstIpcPipelineSink;

## Property Details

### The `“ack-time”` property

      “ack-time”                 guint64

Maximum time to wait for a response to a message.

Flags: Read / Write

Default value: 10000000

### The `“fdin”` property

      “fdin”                     gint

File descriptor to received data from.

Flags: Read / Write

Allowed values: [G_MAXULONG,65535]

Default value: -1

### The `“fdout”` property

      “fdout”                    gint

File descriptor to send data through.

Flags: Read / Write

Allowed values: [G_MAXULONG,65535]

Default value: -1

### The `“read-chunk-size”` property

      “read-chunk-size”          guint

Read chunk size.

Flags: Read / Write

Allowed values: [1,16777216]

Default value: 4096

## Signal Details

### The `“disconnect”` signal

    void
    user_function (GstIpcPipelineSink *gstipcpipelinesink,
                   gpointer            user_data)

Flags: Action

## See Also

GstIpcPipelineSrc, GstIpcSlavePipeline