| 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? |
