We’ve been working on the video transcoding pipeline and have made some big improvements.
The first improvement we made was to prioritise DASH ahead of HLS. If you are not familiar with these acronyms, DASH and HLS are the most common formats for adaptive video streaming. We support both. HLS using fMP4 is a new addition to the mix which we have been experimenting with.
Adaptive streaming allows the quality of the video to be adjusted dynamically during playback depending on the available connection speed. This is far better for mobile than using a simple MP4 video, since that will be much more likely to pause for the dreaded “buffering” as the connection fluctuates.
If you would like to find out more about the technical details concerning the differences between DASH and HLS you might like to read our short guide: HLS vs DASH.
As we describe in that post, we previously favoured HLS since it had the most widespread support. However with DASH now being supported in the majority of browsers, either natively, or by using additional code, this is no longer the case. DASH is in many ways a better approach. It is more future-proof as it supports not only the current H264 codec, but also newer codecs such as H265 which provides much better compression for UHD (4K) content. For DRM (Digital Rights Management) protection, you need DASH to support Widevine (Google’s Chrome, the most popular browser). HLS also adds more overhead. Its fragments must use the MPEG-2 Transport Stream (MPEG2-TS, M2TS or TS) container format, so there can be up to 15% more overhead due to the packaging.
However iOS does not support DASH - either natively, or by using browser extensions known as MSE. If only there was a way to bridge the gap. Which brings us to …
HLS using fragmented MP4 (fMP4) attempts to bridge the gap between DASH and HLS. The key problem is that HLS and DASH use different manifest files (the text files that describe where to find the individual segments, essentially like metadata for the stream) and also different segment files. DASH tends to use .m4s (although there are other approaches). HLS uses .ts. That is a problem since it means you need to package content twice: once for DASH (a .mpd manifest combined with the .m4s segments) and once for HLS (a .m3u8 manifest combined with the .ts segments). That is not ideal because it doubles the storage required.
Handily at WWDC 2016 Apple announced HLS support for fragmented MP4. That means that just one set of segments can be generated and be re-used by both HLS and DASH manifests, as DASH uses fragmented MP4 files too. Awkwardly, two separate manifest files are still required (a .m3u8 file for HLS, and a .mpd file for DASH), but these take up minimal space. The actual video segments can be used by both manifests.
We have been experimenting with fMP4 files in a HLS manifest. This was prompted by the increasing adoption of iOS 10, which is required for fMP4 support. Earlier versions of iOS do not support it.
Currently it is not production-ready however. We found issues, such as that if a video had no audio track (which is possible, though rare), the HLS manifest would not be correctly built. So for the time being, we continue to produce both formats until such time they reliably converge to an agreed standard or HLS can be more reliably generated in conjunction with fMP4.
Neither HLS or DASH specifies a duration for its segments. For HLS, Apple used to recommend 10 seconds, however they have since reduced this. Segments can be as low as 1 second (Facebook use around this duration for their live streaming service). A shorter duration means more files and so more HTTP requests, however it also reduces latency as the initial segment that needs to download before the video begins to play is smaller. Also, if the segments are shorter, more adaptive switching can be done. We have reduced our segment duration to less than half what it was meaning videos should play quicker and smoother.
You can try our professional video hosting for free: simply click the link on the home page. If you have any other questions about our online video platform, contact us at email@example.com.
Return to the Vidbeo homepage?