Probably yes.
If you’ve followed the tech news in recent months, then you probably noticed the buzz around Meerkat and Periscope. Both offer live streaming broadcast of events by people using the app. What makes it a great story is the acquisition of Periscope by Twitter, and then the barring of Meerkat from Twitter. The two are duking it out for the control of live media broadcasting.
If you look at streaming today, it makes use of 2 dominant technologies: Flash and HLS.
On Flash and HLS
Flash is old and dying. That said, it is popular and widespread.
HLS comes from Apple, so on iOS it’s the only thing that works – Apple being Apple.
There’s also this small nagging issue with these technologies – they aren’t really real time. Most times, they add 5 to 30 seconds of latency to the video stream, which isn’t much, but it matters.
That added latency is due to the way these technologies work. The assumption is that you get perfect video – all bits of the stream arrive and get decoded. So if the network loses some of the packets, they need to be re-transmitted, which is why oftentimes, TCP and HTTP are used to send these live media streams. TCP (and HTTP on top of it), offer retransmission capabilities.
On the receiving end, the device needs to make sure it has flawless video. Otherwise, the nagging “buffering” message appear which acts as a turn off for users. To reduce on buffering, the device loads some of the media before it starts playing it back. That way, it has a buffer of media available for network hiccups or when a change in stream is required (acquiring a stream of a higher or lower bitrate in HLS for example).
To sum things up, we try to stream media to clients and the clients add a bit of delay to deal with network issues.
Enter WebRTC
What would happen if we use something like WebRTC instead?
WebRTC is a real time communication technology. The concept behind it is to reduce latency to the bare minimum, which needs to be below a single second.
The difference here is that there is no retransmission (or at least not in the same sense). If a packet of media isn’t received, the device needs to manage things without it. This is done either by using Forward Error Correction or simply by Packet Loss Concealment – estimating to some extent what should have been in the missing packet.
If there’s not enough bandwidth available, or there’s more – WebRTC simply increases or decreases it to match, encoding the video stream in real time to fit to the available bandwidth.
The end result? We’re down from 5 to 30 seconds of latency to a few hundred milliseconds only.
To sum things up, we make do with what we receive and try to optimize how we send it dynamically.
What are a few seconds among friends? (or why is this important?)
- Real time is becoming more and more important. Be it analytics or streaming
- Meerkat and Periscope are interesting because of their real time nature. Will cutting out the latency from 5-30 seconds down to less than a second worth more? Maybe
- WebRTC is suitable for more than just voice and video chat
two issues here:
First, for such use-cases a 1-second latency is often “good enough” — you can tune things differently then. Asking for a frame to be resent is getting more useful and you can do some lookahead for PLC.
Second, adapting the stream works for a single receiver. If you have multiple receivers, you can’t adapt to all of them. Simulcast is one possible answer here obviously.
Philipp,
Thanks. Getting HLS to work in anything below 20 seconds is challenging. Really challenging. I am not sure you can tweak it further easily.
Simulcast is a possibility, scalable video conding and managing transcoding intelligently at the infrastructure side are others. I agree with Tsahi that latency is quite relevant here and that low latency opens many additional use cases enabling viewer interaction and participation.
Thanks.
Using WebRTC in streaming isn’t the natural use case for WebRTC, but it should be doable. My guess is that it requires some creativity to get it right.
Tsahi,
This is the first article I read on your blog about the rivals of WebRTC: HLS and Flash since last August.
Can you please talk about more about Flash and HLS, and their current dominance and how business build upon them?
I believe such analysis could lead to reasonable thinking on how WebRTC could disrupt Flash/HLS.
Thanks!
Roger
Roger,
I’ll consider this request and try to fit it into my publication schedule.
Hi Tsahi,
First of all, many thanks for all your work on helping guys like us learn WebRTC. This is the single best source for all things WebRTC!
wouldn’t this (building meerkat like app) be possible using TokBox WebRTC APIs and validate it? BTW, what technologies these applications are using?
Thanks
Apurva
Apurva,
Thanks for the kind words.
TokBox can be used to develop such services, though the scale will be rather limited as far as I understand.
I know of vendors who are implementing such solutions on their own and others who are using TokBox to build similar offerings. Both alternatives have merit, depending on the use case and the nature of the company in question.