Thanks for checking us back again! As a short recap on our Streaming
Mini-Series so far, we’ve started by analyzing the overall difference
between Streaming Technologies and Progressive Downloads (something we
still owe a proper introduction to, and we’ll cover as we move forward),
and then started our journey through Streaming Proprietary
Technologies.
Adobe was the first proprietary brand we’ve been introducing through our past three articles on RTMP, HLS and HDS, and today’s article completes our introduction to Apple/Adobe by questioning something rhetorical – “which is better, HDS or HLS?”.
Before getting technical with the article, let us kindly remind you we’re barely halfway through our Streaming Mini-Series journey: we have yet several Streaming and so-called “Pseudostreaming” technologies or “methodologies” to cover, not to even mention security considerations which are an additional layer of complexity when it comes to Securing assets.
Let us now start speculating around our rhetorical question , and let us bring you by the hand as we put forth some – just some , really – considerations over the last two different formats’ differences. There is a lot of dedicated literature and debate over prevailing streaming formats, by no means limitedly to HDS and HLS, so we encourage you to draw your own conclusions at the end of this Article and start searching for more if you also are in a streaming business. Today’s article intends to only spray some notions from a technological point of view and in no way could extensively touch our subject, just like a whole dedicated book would not either.
In the previous two posts we discussed two streaming formats – HLS and HDS. Now that we’ve introduced you to these two formats, it’s obvious that comparing HDS with HLS is like comparing apples with oranges. However, we need to ask ourselves – as many did already, I promise you – an important question here: “Why should we have two, three or more competing Streaming formats? Is it possible to manage all your delivery issues with a single format?”
To answer this question we have to first understand business dynamics. From time immemorial, companies have been trying to gain pole position by creating their own proprietary systems and processes. The intention is to grab the entire market share, as always. We recall (just to mention one amongst all too many) a similar war of Formats/Protocols for the HD Optical Disc Market. Sony first developed the Blu-Ray HD Format. Toshiba, another electronic giant supported HD DVD. The battle was over (after quite a lot of bloodletting) when Toshiba conceded and accepted the Blu-Ray format. In the present HDS vs HLS Streaming, there is a difference (and again, we’re limitedly exposing about these two Formats: there are many more about to overtake the market, as you’ll see in the next coming articles): both formats have been accepted and work parallel but for different environments.
Apple has created HLS for its own devices, while HDS is from Adobe stable. Ideally, as professionals, we could have avoided a lot of headache, if we had a single cross platform Streaming Format (does “reinventing the wheel” ring any bell to you?); but Businesses and technologists don’t think on similar lines. So we have to live with different Streaming Technologies and get used to working with multiple formats. Here we are using format and protocol to mean the same thing, although purists will not agree with us.
Adobe, on the other hand developed the Flash Player which is used to stream media to any device using a Flash Player. This Player is widely used and there will hardly be anyone who is unaware of Flash. Incidentally Adobe purchased Flash technology from Macromedia. The Flash Player can be embedded into almost any device (alas, except Apple) and is therefore robust and versatile.
In HLS, M2TS or MPEG-2, transport streams are used which multiplexes the metadata and media files, thus missing the flexibility afforded by HDS.
In HDS, an XML-based Manifest File contains the location information about video and audio files along with segments. Once a Manifest File is downloaded at the player end, it can call relevant video and audio segments, depending upon the demands of local Player, like video quality, language tracks and captioning. The key element which has to be noticed here is that multiplexing of video and audio segments occurs at the player end. This is made possible because in HDS, every media segment – whether video or audio – can be accessed separately as single fragments or bytes. These fragments are decrypted and the original media track reconstructed at the player end using the metadata and media information present in the fragments.
Compare this to HLS, where the Manifest File contains information on all the combinations and variations of multiplexed files necessary to stream media to the Player. Multiplexing has immediate fallout – you cannot stream different audio for the same video. For example, what will happen if you are streaming a movie in Spanish with English subtitles and at the same time the same video is required to be with English audio and Spanish subtitles?
HLS format would require different files for each requirement. When you consider that End Users will demand media at different Bitrates, the number of files required for a single movie does become unmanageable. In fact, this is the reason why HLS can hardly conform to DRM Requirements (if not in a pre-chunked fashion). In HDS, the problem of multiple files with different audio and subtitles is handled gracefully because video and audio files are stored separately and not multiplexed. If you consider the Live Streaming of a football match with commentary in hundreds of languages and subtitles, with multiple camera angles, you will certainly confront an impossible situation if you work with HLS.
Another factor which affects overall streaming performance is the segment length. Due to various reasons and constraints, Apple recommends a segment length of 10 seconds. In case of changed Bitrate, two overlapping segments, each of 10 seconds, have to be simultaneously downloaded. This puts additional load on the Network which is already experiencing stress. Needless to say, this results in higher latency and degrades Streaming performance. In case of HDS there is no such requirement. The segment length in HDS is restricted to 2 seconds which reduces latency and improves Streaming.
Let us, however, add our own , Market based , consideration before closing (and given that we’re halfway through our Streaming MiniSeries): for although from a Technology point of view HDS is a much more robust one than HLS , the End User is King (always was). What does this mean?
First of all, that – as mentioned – HLS will die hard. HDS instead has to fight against many other non-Apple compliant Streaming Technologies, such as all the ones we’ll explore. Microsoft – as we’ll see into our next Article – and his SmoothStreaming – or “Silverlight” – Technology has pretty much given up the fight as of date, and Progressive Downloads will always be around as it’s not a Streaming Technology – strictly speaking : it is MPEG-DASH, in our humble opinion, and as we’ll see in its dedicated Article soon , that will overtake the Market in the next two years from now. We’re happy to put a bet on it.
Adobe was the first proprietary brand we’ve been introducing through our past three articles on RTMP, HLS and HDS, and today’s article completes our introduction to Apple/Adobe by questioning something rhetorical – “which is better, HDS or HLS?”.
Before getting technical with the article, let us kindly remind you we’re barely halfway through our Streaming Mini-Series journey: we have yet several Streaming and so-called “Pseudostreaming” technologies or “methodologies” to cover, not to even mention security considerations which are an additional layer of complexity when it comes to Securing assets.
Let us now start speculating around our rhetorical question , and let us bring you by the hand as we put forth some – just some , really – considerations over the last two different formats’ differences. There is a lot of dedicated literature and debate over prevailing streaming formats, by no means limitedly to HDS and HLS, so we encourage you to draw your own conclusions at the end of this Article and start searching for more if you also are in a streaming business. Today’s article intends to only spray some notions from a technological point of view and in no way could extensively touch our subject, just like a whole dedicated book would not either.
In the previous two posts we discussed two streaming formats – HLS and HDS. Now that we’ve introduced you to these two formats, it’s obvious that comparing HDS with HLS is like comparing apples with oranges. However, we need to ask ourselves – as many did already, I promise you – an important question here: “Why should we have two, three or more competing Streaming formats? Is it possible to manage all your delivery issues with a single format?”
To answer this question we have to first understand business dynamics. From time immemorial, companies have been trying to gain pole position by creating their own proprietary systems and processes. The intention is to grab the entire market share, as always. We recall (just to mention one amongst all too many) a similar war of Formats/Protocols for the HD Optical Disc Market. Sony first developed the Blu-Ray HD Format. Toshiba, another electronic giant supported HD DVD. The battle was over (after quite a lot of bloodletting) when Toshiba conceded and accepted the Blu-Ray format. In the present HDS vs HLS Streaming, there is a difference (and again, we’re limitedly exposing about these two Formats: there are many more about to overtake the market, as you’ll see in the next coming articles): both formats have been accepted and work parallel but for different environments.
Apple has created HLS for its own devices, while HDS is from Adobe stable. Ideally, as professionals, we could have avoided a lot of headache, if we had a single cross platform Streaming Format (does “reinventing the wheel” ring any bell to you?); but Businesses and technologists don’t think on similar lines. So we have to live with different Streaming Technologies and get used to working with multiple formats. Here we are using format and protocol to mean the same thing, although purists will not agree with us.
Apple and Adobe
Apple is known to create its own hardware and Operating System. Mac has been competing with Windows desktop for ages. iOS has been in existence for decades. Both Mac and Desktops have lived along nicely without getting into each other’s way. Things then changed when Apple brought out the iPhone. You must remember that there has been a silent convergence of media and interoperability of files between desktops and mobiles has become imperative. Realizing the importance of streaming media, Apple came up with its own format which is the HLS or HTTP Live Streaming. This format has to be used if you want to stream media to an Apple gadget or mobile. iPhones are a big force in the mobile sector and cannot be ignored, therefore using HLS is unavoidable. Period.Adobe, on the other hand developed the Flash Player which is used to stream media to any device using a Flash Player. This Player is widely used and there will hardly be anyone who is unaware of Flash. Incidentally Adobe purchased Flash technology from Macromedia. The Flash Player can be embedded into almost any device (alas, except Apple) and is therefore robust and versatile.
Transporting media streams: HDS VS HLS
HDS uses fragmented MP4 files or fMP4. This has several benefits. The first is that the metadata, audio and video files can be stored separately. The advantage of such a system is apparent. You can store video and audio streams in any location, independently. The metadata does automatically detect the end user environment (like bandwidth and player resources) and streams the appropriate media file with matched Bitrate. This adaptive switching is possible because of the separation of metadata from media files.In HLS, M2TS or MPEG-2, transport streams are used which multiplexes the metadata and media files, thus missing the flexibility afforded by HDS.
In HDS, an XML-based Manifest File contains the location information about video and audio files along with segments. Once a Manifest File is downloaded at the player end, it can call relevant video and audio segments, depending upon the demands of local Player, like video quality, language tracks and captioning. The key element which has to be noticed here is that multiplexing of video and audio segments occurs at the player end. This is made possible because in HDS, every media segment – whether video or audio – can be accessed separately as single fragments or bytes. These fragments are decrypted and the original media track reconstructed at the player end using the metadata and media information present in the fragments.
Compare this to HLS, where the Manifest File contains information on all the combinations and variations of multiplexed files necessary to stream media to the Player. Multiplexing has immediate fallout – you cannot stream different audio for the same video. For example, what will happen if you are streaming a movie in Spanish with English subtitles and at the same time the same video is required to be with English audio and Spanish subtitles?
HLS format would require different files for each requirement. When you consider that End Users will demand media at different Bitrates, the number of files required for a single movie does become unmanageable. In fact, this is the reason why HLS can hardly conform to DRM Requirements (if not in a pre-chunked fashion). In HDS, the problem of multiple files with different audio and subtitles is handled gracefully because video and audio files are stored separately and not multiplexed. If you consider the Live Streaming of a football match with commentary in hundreds of languages and subtitles, with multiple camera angles, you will certainly confront an impossible situation if you work with HLS.
Impact on Networks and QoS
In HLS, the Edge Cache has to hold various combinations of Bitrate and track, which may not be possible at all times. This means that the required information has to be fetched from the Server (a CDN server ideally! ) which would result in lowering the efficiency. In the case of HDS, the same Stream holds all the streaming information and therefore leads to better efficacy.Another factor which affects overall streaming performance is the segment length. Due to various reasons and constraints, Apple recommends a segment length of 10 seconds. In case of changed Bitrate, two overlapping segments, each of 10 seconds, have to be simultaneously downloaded. This puts additional load on the Network which is already experiencing stress. Needless to say, this results in higher latency and degrades Streaming performance. In case of HDS there is no such requirement. The segment length in HDS is restricted to 2 seconds which reduces latency and improves Streaming.
Conclusion
There can be no two opinions that HDS – as a Streaming Technology – is superior to HLS. However, Apple devices are extremely popular and use of HLS is unavoidable. Moreover, the Apple Marketplace can be a lucrative proposition for many Media Agencies since you can charge for every single Streaming request. Both HLS and HLS will continue to be used in the foreseeable future.Let us, however, add our own , Market based , consideration before closing (and given that we’re halfway through our Streaming MiniSeries): for although from a Technology point of view HDS is a much more robust one than HLS , the End User is King (always was). What does this mean?
First of all, that – as mentioned – HLS will die hard. HDS instead has to fight against many other non-Apple compliant Streaming Technologies, such as all the ones we’ll explore. Microsoft – as we’ll see into our next Article – and his SmoothStreaming – or “Silverlight” – Technology has pretty much given up the fight as of date, and Progressive Downloads will always be around as it’s not a Streaming Technology – strictly speaking : it is MPEG-DASH, in our humble opinion, and as we’ll see in its dedicated Article soon , that will overtake the Market in the next two years from now. We’re happy to put a bet on it.
Comments
Post a Comment