Live, Uncompressed Video in the Cloud at VidTrans 21
Channel: VSF
Date: 17/03/2021

Evan Statton, AWS and Thomas Edwards, AWS

Media companies working with live uncompressed video over IP have been very successful with on-premises ST 2110 solutions interoperating between many vendors. However, the cloud is a very different environment than a single-tenant, private broadcast plant. The lack of available solutions led AMWA to issue its “User Requirements for High Value, Low Latency, Live Video Production on Public Cloud”. The Cloud Digital Interface (CDI) SDK has been developed to provide reliable, low-latency, uncompressed video frame sharing as well as audio and metadata between services in the cloud. This session takes a look at CDI’s technical approach and API, as well as how it facilitates multi-vendor interoperable transport of uncompressed video in real time (or faster than real time). We then discuss the open source nature of the technology, which allows for additional implementations & extensions to be developed.

Recorded on March 2, 2021 during the first virtual edition of VidTrans, an annual conference produced by the VSF.

Selected Comments from the Zoom chat log:

Wes Simpson (LearnIPvideo.com): What is the typical BW of a flowlet?
Adi Rozenberg (Video-Flow.Ltd): So it is like RIST load share; splitting the streams
Ciro Noronha (Cobalt): Who handles the retransmission?  Endpoints or the network?
Francesco Meo: how does sender knows flowlet is losing packets?
c ostrom: Is this like a RAID array?
Michael Firth (Nevion): Does the way the sender is routing the flowlets means it needs to have a detailed knowledge of the switch hashing algorithms?
Kieran Kunhya (Open Broadcast Systems Ltd): As I understand it CDI sits on top SRD which uses standard RDMA primitives? Is it possible to implement CDI at a lower layer by using RDMA directly. This would allow vendors to have a combined 2110/CDI stack and not have a new stack for CDI alone.
Andy Rayner (Nevion): Is it worth explaining the AVM media layer vs the lower bits?
Karl Paulsen (Diversified): using JPEG-XS as the GCCG link, are there reasons/possibilities to use this in a compressed format, in the cloud?
Kieran Kunhya (Open Broadcast Systems Ltd): Yes, we have a software 2110 sender
Wes Simpson: We need a public glossary of all the AWS abbreviations
Kieran Kunhya (Open Broadcast Systems Ltd): The answer to that question Adi is an uncompressed UDP stack is a hard problem.
Evan Statton: @Mike Firth’s question re: knowing about the network.  No, the sender needn’t know anything about the network. It will create flowlets with unique 5-tuples and then the network will hash it
Evan Statton: think of it like rolling a 1000 sided dice or something, every 5-tuple rolls again
Evan Statton: so it’s possible that two flowlets will share the same path through the network, but at scale, that becomes a very slim probability, probably statistically irrelevant
Thomas Edwards: Francesco Meo asked "hi Thomas, how does sender knows flowlet is losing packets? " The receiver provides receive reports back to the sender, which allows RTT to be determined for a flowlet.
Evan Statton: The objective of SRD congestion control is to get a fair share of the bandwidth with minimum in-flight bytes, preventing queue buildup and preventing packet drops (rather than relying on them for congestion detection). SRD congestion control is somewhat similar to BBR,[8] with additional datacenter multipath considerations. It is based on a per-connection dynamic rate limit, combined with an inflight limit. The sender adjusts its per-connection transmission rate according to rate estimation as indicated by the timing of incoming acknowledge packets, taking into account also the recent transmit rate and RTT changes. Congestion is detected if the RTT goes up on the majority of paths, or if the estimated rate becomes lower than the transmit rate. This method allows detection of connection-wide congestion affecting all paths, e.g., in case of incast. Congestion on an individual path is handled independently by rerouting.
Evan Statton: i recommend everyone read the article in IEEE: https://ieeexplore.ieee.org/document/9167399
Wes Simpson: @ Evan and Thomas - Is there an optimum number of flows that scales with signal bandwidth? For example, it could make sense to have 1000 flows for a million packet per second stream, but not for a thousand packet per second stream.
Evan Statton: @Wes - Very true! SRD’s efficiency gets better the bigger the payload is. If the payload is small, and you have 1000 flowlets, it will take longer to detect issues because each flowlet would have a rate that’s too low
Evan Statton: It would be a good experiment to run SRD with small flows too and capture the data
Kieran Kunhya : How is a client requesting the missing data if TS packets are not easily identifiable?
Evan Statton: yeah this is NACK based retransmission where the retransmission path happens to be IP
Marco Slik (Nevion): What is the extra delay introduced for this recovery approach?