mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-06 09:29:42 +00:00
49 lines
1.6 KiB
Text
49 lines
1.6 KiB
Text
|
Network Transparent elements
|
||
|
----------------------------
|
||
|
|
||
|
1) netbin
|
||
|
|
||
|
- exposes local shims and remote real elements.
|
||
|
- all shim pads can be connected to other shim
|
||
|
pads and operations are proxied to real elements.
|
||
|
- when the pads are not part of the same bin, network
|
||
|
transparent ghostpads are created to connect them.
|
||
|
- bin has host property to indicate where it should
|
||
|
run.
|
||
|
|
||
|
2) netpipeline
|
||
|
|
||
|
- synchronizes different netbins, this means distributing
|
||
|
the same element base time to the remote bins.
|
||
|
- clocks master/slave is set up.
|
||
|
|
||
|
3) netpad
|
||
|
|
||
|
- all pad operations are proxied to peer pad using
|
||
|
a network protocol, possibly selectable from RTP/TCP/....
|
||
|
Serialisation of buffers and events are to be considered
|
||
|
but also methods with their arguments. A generator would
|
||
|
not be too bad to automate this.
|
||
|
- the implementation would be fairly similar to the
|
||
|
ghostpad implementation.
|
||
|
- This includes event passing (bidirectional) and
|
||
|
data passing (unidirectional). Some events have to pass
|
||
|
in parallel with the datastream so the event path should
|
||
|
use a different connection.
|
||
|
|
||
|
4) GStreamer deamon
|
||
|
|
||
|
- each host has to run a deamon that listens for
|
||
|
commands and creates elements/pipelines and performs all
|
||
|
operations on the real pipeline.
|
||
|
|
||
|
Other stuff
|
||
|
-----------
|
||
|
|
||
|
- what about migrating elements from one host to another. This
|
||
|
would happen when an element is removed form a bin into another
|
||
|
bin.
|
||
|
|
||
|
- do we have/need a fast protocol for stuff on the same machine or
|
||
|
will regular network connections work fine?
|