summaryrefslogtreecommitdiff
path: root/docs/random/wtay
diff options
context:
space:
mode:
authorWim Taymans <wim.taymans@gmail.com>2005-07-27 20:22:48 +0000
committerWim Taymans <wim.taymans@gmail.com>2005-07-27 20:22:48 +0000
commit475ff86c53b2ac36a3eae38476f2eff1e15a4f5e (patch)
treee9a1beb8cf3e03e25f817cbe1f5c8422d580d81c /docs/random/wtay
parent540d6342e9234af4dc8944d8c34c40da8dcf800c (diff)
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.
Diffstat (limited to 'docs/random/wtay')
-rw-r--r--docs/random/wtay/network-transp48
1 files changed, 48 insertions, 0 deletions
diff --git a/docs/random/wtay/network-transp b/docs/random/wtay/network-transp
new file mode 100644
index 0000000000..6f209c4e28
--- /dev/null
+++ b/docs/random/wtay/network-transp
@@ -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?