... | @@ -3,4 +3,20 @@ Adaptive RGB-Depth streaming both for inputs to reconstruction and for virtual c |
... | @@ -3,4 +3,20 @@ Adaptive RGB-Depth streaming both for inputs to reconstruction and for virtual c |
|
1. Synchronised feeds from all sources.
|
|
1. Synchronised feeds from all sources.
|
|
2. Adaptive bitrate to maintain real-time frame rates.
|
|
2. Adaptive bitrate to maintain real-time frame rates.
|
|
|
|
|
|
Streaming must support new connections and disconnections reliably, along with feedback for changing configurations. |
|
Streaming must support new connections and disconnections reliably, along with feedback for changing configurations. Further, threads must be used to grab and compress streams separately since the grab process can be resource intensive from some sources (disparity calculation), as can compression. A thread pool will be used along with double buffering of each source.
|
|
\ No newline at end of file |
|
|
|
|
|
Each source can:
|
|
|
|
1. Have its transmission clock synchronised using an adaptive delta.
|
|
|
|
2. Provides a mechanism for negotiating the time delta that includes network latency.
|
|
|
|
3. Receives feedback every N frames to assess bandwidth, feedback should be received within a specific period or it means data transmission took too much time to complete.
|
|
|
|
|
|
|
|
So the protocol for a normal client is:
|
|
|
|
1. Client sends batch request (for N frames) to URI with return URI given
|
|
|
|
2. Streamer sends N frames to URI at fixed frame rate
|
|
|
|
3. Client receives each frame, after N it repeats 1 but with adjusted compression number
|
|
|
|
|
|
|
|
The protocol for a sync client is:
|
|
|
|
1. Client pings server M times to obtain latency.
|
|
|
|
2. Client sends latency adjusted timestamp to each streamer to sync local clocks
|
|
|
|
3. Follow same protocol as normal client.
|
|
|
|
4. Repeat ping and sync process periodically. |