Nicolas Weil, Digital Media Solutions Architect (France, World), provides a nice blog post about the post-IBC'13 MPEG-DASH ecosystem status which highlights also the DASH timeline referred to as "The ABR Esperanto: On the road to standardization..." (ABR stands for adaptive bit rate)
The former provides not only an excellent overview about the status quo but also an implementation directory of products and services supporting DASH (incl. our award-winning bitdash & bitcodin). The latter shows the history of MPEG-DASH from back in 2010 - when standardization started - until now ... but
I'm asked very often what is the (big) next step in ABR (to keep the terminology as used in Nicolas' timeline) and - as you all know - it's always difficult to predict the future. Still, I'm trying to highlight some of these aspects...
Further reading
The former provides not only an excellent overview about the status quo but also an implementation directory of products and services supporting DASH (incl. our award-winning bitdash & bitcodin). The latter shows the history of MPEG-DASH from back in 2010 - when standardization started - until now ... but
what's next?
I'm asked very often what is the (big) next step in ABR (to keep the terminology as used in Nicolas' timeline) and - as you all know - it's always difficult to predict the future. Still, I'm trying to highlight some of these aspects...
- Multi-path delivery, e.g., Multipath TCP (MPTCP) which is actually transparent to the application layer and, thus, the application logic inside the DASH client. Transport folks are promoting this as a feature but DASH evangelists might have a different opinion as the adaptation logic is influenced by the throughput provided from the transport layer and unaware of the bandwidth of the different paths.
- DASH over HTTP/2.0 [1], CCN [2], and - in general - protocols 'other' than HTTP. Yes, this is not a mistake and please let me explain. It is true that the 'H' in DASH stands for HTTP but the standard mandates that the usage of HTTP-URLs (i.e., URI schemes http and https) within the MPD. How one delivers the segments to the HTTP client is not specified and one might simply use a proxy (could be located at the client or elsewhere) that translates everything that comes from (or goes to) the transport layer into HTTP request/response messages. However, there are also proponents that advocate to allow an explicit usage of protocols other than HTTP.
- Hybrid delivery in different ways, like broadband/broadcast which is used very often as the most prominent representative, use cases requiring inter-destination media synchronization, and the combination of DASH with conversational services.
I agree that these aspects do not describe the big next step but will be most likely important steps towards achieving the goal of universal media experience. Comments are more than welcome...
PS: Of course, I'm working on the next big step (as probably many others) but this will still take some time... stay tuned!
Further reading
References
[1] Christopher Mueller, Stefan Lederer, Christian Timmerer, Hermann Hellwagner, Dynamic Adaptive Streaming over HTTP/2.0, In In Proceedings of the IEEE International Conference on Multimedia and Expo (ICME) 2013, IEEE, San Jose, USA, pp. 1-6, 2013.
[2] Stefan Lederer, Christopher Mueller, Benjamin Rainer, Christian Timmerer, Hermann Hellwagner, An Experimental Analysis of Dynamic Adaptive Streaming over HTTP in Content Centric Networks, In Proceedings of the IEEE International Conference on Multimedia and Expo (ICME) 2013, IEEE, San Jose, USA, pp. 1-6, 2013.
No comments:
Post a Comment