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
