Video streaming in the Internet started with very little bandwidth and with very weak computers that required hardware extensions even for decoding a video conferencing video. So researchers invented multicast and developed protocols to hold distributed conferences where they discussed how to develop the Internet itself. Of all their protocols, RTP and RSVP were used longest of all (and RTP is actually used for 4G telephony).
When the Internet became dominated by commercial players, they really hated IP multicast because it makes it nearly impossible to figure out who has to pay whom.
So today, we have the standard MPEG DASH, Dynamic Adaptive Streaming over HTTP, for sending video from a server to a viewer, one separate copy of the stream for every viewer, and to reduce the load on servers and networks, we use web caches.
We are even streaming DASH to mobile phone users inside a football stadium who want to watch what’s going on in another stadium or what the camera is seeing in the same stadium, or “scroll back” and see what happened just a few seconds ago. Tiled streaming adds to this the ability to move your view sideways or up-and-down, and receive only the relevant pixels of a larger video in high quality.
But: if this service succeeds and more visitors in the stadium use the service, we do no longer have sufficient bandwidth. We have to think like those early researchers who worried about bandwidth more than anything, and use multicast.
In this thesis, you will explore options for turning unicast pull-based DASH streams into multicast push-based RTP streams. We will concern us with WiFi networks. How to do it with high compute performance? How to do it with low latency? How to support that people want to watch the same content at slightly different times?
We draw inspiration from our earlier work, like Lambda-patching, Pull-patching and real-time transcoding, and forward error correction.