4

I have researched a lot regarding the current state of Video streaming and playing on the web. I am posting the things i have summarized and the strategy i think i should follow to support adaptive streaming across majority devices and browsers. I just wanted a feedback from the community if the strategy i am working on has any major loopholes/improvements in it.

SUMMARY

  • In order to support most browsers out there today to play a video in html's <video> element we need to encode our videos in atleast 3 formats WEBM, OGG and MP4
  • To have adaptive streaming in place for video on demand services the options available are MPEG-DASH, Apple's HLS, Microsoft's Smooth Streaming and Adobe's HDS
  • Initially i preferred to go with MPEG-DASH as it a open standard which is similiar to HDS, HLS and Smooth Streaming and was invented to provide a common platform to serve audio/video content on any browser and OS.
  • But as of now Apple devices running Safari on iOS and Safari on Mac do not completely support MPEG-DASH standard because Apple has not yet supported the Media Source Extensions API of html5 upon which MPEG-DASH is based.
  • So i am going with implementation of MPEG-DASH (for non apple devices) + HLS (for apple devices)
  • This would mean i will have to generate both .mpd(used by mpeg-dash) and .m3u8(used by HLS) files on server side which will then be served to clients. I am using Node.js on server side for encoding purposes.

Now as far as i know when using mpeg-dash what it does basically is that it creates various different media files with different bit-rates from the source file and a configuration file which contains descriptions/rules regarding which stream is to be sent to client depending upon the bandwidth.

Same logic applies to HLS with the the exception that it creates a configuration file with different extensions then that of mpeg-dash.

If i plan to support 3 bit rates with 3 different resolutions such as 1020*720, 800*600, 400*300 for a video then i need to generate such videos for each of the 3 formats i am going to support (i.e WEBM, OGG, MP4)

So for any one video uploaded by client i need to generate 3*3 = 9 videos in total along with generating a .mpd and .m3u8 file to support non-Apple and Apple devices.

Does this seem to be a good practice ? Or is there something big that i am missing to have a Cross Browser Adaptive Streaming Solution ?

Tips/Recommendation/Suggestions are welcome.

Thanks !

Vinay
  • 723
  • 9
  • 32

2 Answers2

1

Your approach sounds about rite. Safari on Mac does now support media source extensions, so thats one more for DASH. But HLS is still needed for iOS. I was hoping that iOS9 would include it, But so far, no luck. It is theoretically possible to do DASH in an iOS app using VideoToolkit, But it remains to be seen if apple would allow such a thing into the app store. Personally, I would forget webm, and only support h264/aac. Silverlight and HDS should be ignored completely. Both Adobe and Microsoft are moving to DASH. It is also possible to play HLS in MSE via a converter written in javascript. Its a bit more complicated, but there are a few players out there that can do it.

szatmary
  • 29,969
  • 8
  • 44
  • 57
  • why not use HLS, and my answer below explains how to accomplish secure HLS adaptive bitrates, on Chrome or Safari, mobile or desktop – Rob Little Dec 09 '20 at 13:51
1

Here you can see an overview of the different browsers and platforms in terms of MPEG-DASH and/or HLS support: http://www.dash-player.com/blog/2015/06/replacing-flash-adaptive-streaming-and-drm-in-html5/

We typically generate MPEG-DASH + HLS content in parallel, and serve about 80 to 90 % of all users with MPEG-DASH (in HTML5 or Flash using e.g. http://www.dash-player.com) and 10 to 20 % with HLS.

Stefan Lederer
  • 453
  • 2
  • 2