mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-11-27 04:01:08 +00:00
48 lines
1.6 KiB
Text
48 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?
|