New transport protocols for a better user experience

In the 1980s the telecom industry decided they needed a “broadband standards” and started defining some protocols under the project name “Asynchronous Transfer Mode”. Today people know ATM for something completely different because the project, which actually led to significant deployment in the telecom gears of various countries, came to a stop because of a competing technology called Internet Protocol.
A decade later IP, that did not require an access speed of 155 Mbit/s like ATM, started being deployed with a bitrate that on average did not even reach 3 orders of magnitude less the ATM’s. IP seemed to provide the level of speed that could make customers happy keeping the Plain Old Telephone System (POTS) in place while ATM required reaching millions of subscribers homes with optical fibers.

No one can blame telcos for trying to save trillions of dollars of optical fibers for the less costly Asymmetric Digital Subscriber Line (ADSL). The reality, though, is that our society is more and more video dependent but the fixed telecommunication infrastructure cannot provide the bandwidth that its users require. A lot of talk is being made these days around the “Next Generation Network” (NGN) acronym and, in due time, something is bound to come out, but very little prospects exist for the mobile network which is squeezed between a terrestrial broadcasting industry that sticks to its Ultra High Frequency (UHF) legacy while the need to carry video on mobile networks multiplies by the day.

Video is a strange beast. From time to time I regularly receive the question: How many bit/s are required to transmit video? My regular answer is: as many as you want, even no bits at all. I agree that some may see this answer as non-collaborative, but it contains a profound truth, namely that video is a really flexible beast because you can decide how many bit/s you use to transmit video. No matter how few bits you use, your correspondent will always see “something”.

Operators have exploited this feature to cope with the wide dynamics of networks characteristics. If transmitter is informed that receiver is unable to receive all the bits that it needs to decode a video, it can switch to a version of the video encoded at a lower bitrate. The user at the receiving side will see a less crisp picture and he may complain about the shortsightedness of telcos that did not invest in ATM (if they had done it, what would the phone bill be today?), but that is still better than a picture that keeps on freezing.

The problem is that operators has independently decided to use their own transmitter-receiver protocols. This was acceptable at a time when video was a past time of few, but it is no longer a solution today when video is so pervasive.

MPEG has spotted this problem and is close to releasing a new standard called DASH. The acronyms stands for Dynamic Adaptive Streaming over HTTP and is almost self-explanatory. The pervasive HyperText Transport Protocol is used to stream video but the bitrate used is dynamically adapted to network conditions using a standard protocol that any implementer can use to build interoperable solutions.

See a technical explanation at http://mpeg.chiariglione.org/technologies/mpeg-b/mpb-dash/index.htm

Leonardo Chiariglione

How does your pc plays wim.tv videos?

So, when you first come on the wim.tv page was asked you to download a browser plugin, then you're able to watch videos. But what really happens in this process?  What you downoad is a gstreamer-based rtsp player, that receives multimedia contents from the network and allows the browser rendering them within a web page.

Real time streaming protocol and wim.tv

RTSP (http://tools.ietf.org/html/rfc2326) coupled with Real Time Protocol (http://tools.ietf.org/html/rfc3550) is the network protocol used by wim.tv to delivery videos to the end user. RTSP is a real live protocol, that means that the media supplier could create the video at the very same time it streams it. This is implemented by sending a single frame of the video at the time, so in every moment the server could decide what is the next frame to be sent. In the others web-based video streaming platforms each video is an indivisible file, that must be streamed as-is.

Then RTSP allows to insert advertisements within the video in a totally smooth way, without overlaying, switching through different streams or other tricks. In fact, when an adverticement starts, the player just keep on receiving and frames, without ever notice if those frames are part of the video or the adverdicement. Besides improving playback performances, this ensures the advertisers that end users cannot skip the adverticements.

Another thing wim.tv player is able to do is to decrypt encrypted videos. Pay per view premium videos are streamed in an encrypted form, and can be played only by authorized users. If a malevolent user tries to save video data from the network the only thing he could retrieve is video of solid gray frames. But if you're allowed to play the same video, wim.tv browser plugin will decrypt it for you. In that case, each frame of the video is received, decrypted and played. The entire operation is enough fast that you'll never notice that is happening when you watch a video.

Alessio Lagonigro