mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2025-04-10 01:54:11 +00:00
docs/random/wtay/network-transp: Some old doc I had.
Original commit message from CVS: * docs/random/wtay/network-transp: Some old doc I had.
This commit is contained in:
parent
540d6342e9
commit
475ff86c53
2 changed files with 53 additions and 0 deletions
|
@ -1,3 +1,8 @@
|
|||
2005-07-27 Wim Taymans <wim@fluendo.com>
|
||||
|
||||
* docs/random/wtay/network-transp:
|
||||
Some old doc I had.
|
||||
|
||||
2005-07-27 Wim Taymans <wim@fluendo.com>
|
||||
|
||||
* libs/gst/dataprotocol/dataprotocol.c: (gst_dp_packet_from_event),
|
||||
|
|
48
docs/random/wtay/network-transp
Normal file
48
docs/random/wtay/network-transp
Normal file
|
@ -0,0 +1,48 @@
|
|||
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?
|
Loading…
Reference in a new issue