There are so many ways to stream video, how can you find the one that suits you best? Weighing up the pros and cons in this talk is Robert Reindhardt from videoRx.
Taking each of the main protocols in turn, Robert explains the prevalence of each technology from HLS and DASH through to WebRTC and even Websockets. Commenting on each from his personal experience of implementing each with clients, we build up a picture of when the best situations to use each of them.
Contribution via the internet is tricky but has great promise. With packet loss and jitter all over the place, how can you deliver perfect video?
Ciro Noronha from Cobalt Digital explains the two ways people get around the unreliability of the internet: FEC and retransmission. Forward Error Correction uses some maths to transmit extra data on top of the stream which allows the receiver to correct for any packet losses. This method is standard in satellite transmission where it is always used to add robustness.
Retransmission is different in that it requires a return channel. When a receiver spots a missing packet, it asks for it to be resent. Being that it has to wait for a reply, retransmission protocols like SRT, ARQ and RIST run with a configurable buffer which needs to be big enough for at least one round trip. FEC schemes also require a buffer as it needs to wait for a number of packets before it can complete the maths required.
Ciro introduces FEC and ARQ before presenting work showing experiments he’s run on both FEC and ARQ to see the limits of their signal-correcting capabilities and latency. He finishes explaining what RIST is and its status.
RIST solves a problem by transforming unmanaged networks into reliable paths for video contribution. This comes amidst increasing interest in using the public internet to contribute video and audio. This is partly because it is cheaper than dedicated data circuits, partly that the internet is increasingly accessible from many locations making it convenient, but also when feeding cloud-based streaming platforms, the internet is, by definition, part of the signal path.
Packet loss and packet delay are common on the internet and there are only two ways to compensate for them: One is to use Forward Error Correction (FEC) which will permanently increase your bandwidth by up to 25% so that your receiver can calculate which packets were missing and re-insert them. Or your receiver can ask for the packets to be sent again.
RIST joins a number of other protocols to use the re-request method of adding resilience to streams which has the benefit of only increasing the bandwidth needed when re-requests are needed.
In this talk, Ciro Noronha from Cobalt Digital, explains that RIST is an attempt to create an interoperable protocol for reliable live streaming – which works with any RTP stream. Protocols like SRT and Zixi are, to one extent or another, proprietary – although it should be noted that SRT is an open source protocol and hence should have a base-level of interoperability. RIST takes interoperability one stage further and is seeking to create a specification, the first of which is TR-06-1 also known as ‘Simple Profile’.
We then see the basics of how the protocol works and how it uses RTCP for singling. Further more RIST’s support for bonding is explored and the impact of packet reordering on stream performance.
The talk finishes with a look to what’s to come, in particular encryption, which is an important area that SRT currently offers over and above reliable transport. Watch now!
Delivering low-latency live-video over the public internet, or any network which sees packet loss is ever a challenge, but recently there have been a number of protocols which have been created to allow this to work.
The problem to be fixed is that packets get lost and when you have a video decoder trying to output 50 images every second, there really isn’t time to deal with missing packets. Protocols such as SRT, Zixi and, now, RIST allow a mechanism which adds a small buffer and a mechanism to request missing data.
This isn’t a problem, in general, for live streaming to consumers on devices or computers such as Netflix or iPlayer because they use HLS or similar protocols based on TCP, but for low-latency streams this is not practical.
In this talk Kieran Kunhya explains more about these basics, the challenges to be overcome and the ways of dealing with them.