Hulu’s Move to DASH
When it comes to DASH conformance, Hulu didn’t experience too many problems either: “Most of the DASH conformance testing occurs during the development phase,” Coudurier says. “We had a few issues with the manifests, like lowercase problems and noncompliant xml mime-types, but nothing really blocking. Once it’s done, you can trust repetition, and verify your packaged files only when problems occur in production. What we systematically verify in production is rather the MP4 files that we package afterwards; we decode the file with FFmpeg, including the audio track. If the source MP4 file is well-formed, there is a negligible chance that the DASH packaging fails.”
What’s the secret with a successful DASH implementation, then? “Just stick to the standards!” Coudurier says. “During the development phase, you can be tempted to craft your slightly custom implementation, compared to the DASH standard. Don’t do it. Stay in the boundaries of what is specified in terms of manifest construction, and use the DASH-IF manifest validator—it’s your safeguard. Verifying the video format is a bit more complex, but if you take the Smooth format as a start, that’s not a too risky move, as Microsoft explains quite clearly what you have to change to be compliant with ISO-BMFF. So, starting from Smooth and the PIFF documentation is the safest option.”
Migration Benefits
What do you gain from your migration to DASH? Control, flexibility, simplicity—and performance, of course. Coudurier starts with the control benefits: “We shifted from proprietary tools to open source tools or tools that we have been able to build ourselves. It’s a major advantage in a workflow, as it provides more control. It allowed us to totally eliminate Smooth Streaming proprietary video fragments and concentrate on the Smooth manifest generation issues, as well as on variations of the DASH manifest in segment-timeline flavor, for devices that don’t support SegmentBase packaging. Overall we have less user support to provide with DASH, as we have more control on the players. We exited the black box players from the proprietary ABR technologies.”
When it comes to flexibility, Coudurier also has a solid benefit list: “Another great advantage of migrating is that you benefit from a greater flexibility in terms of where you can deploy your manifests,” he says. “With Smooth Streaming you had to deploy it alongside your fragments on the CDN.
With DASH you can put it everywhere you want, as long as your <baseURL> tags are included in the DASH manifest. When you are using multiple CDN, like we do, this is a definitely killer feature: No caching issue, no purge problems, and you can regenerate your entire library when you want so easily. If you want to activate new bitrates or to deactivate others, it’s a piece of cake, really. [That’s] not even talking of the cases where you want to upgrade the codecs you use.”
Coudurier says the workflow is much simpler now as well. “In terms of monitoring the content preparation workflow, you can divide the complexity by the number of formats that you are taking out of the game,” he says. “You also save money on the workflow as you need fewer servers to package the files, less storage obviously, less production problems. Worst case, it cost you the same; best case, you save 30% of your workflow costs. And you don’t have to use a specific module on the origin, as you had to do in Smooth—you can use standard Nginx servers instead. Compared to Smooth, we are reaching the pinnacle of simplicity and flexibility.”
The performance gains brought both by the format change and the player upgrade are significant. “The results of our performance evaluations after the migration to DASH showed that we lowered by 15% the number of sessions suffering from rebuffering, [which was] our main concern,” Coudurier says. “This is a huge improvement as it lowers down the abandonment rate significantly. The time to playback start is roughly the same as previously, because of the MOOV header and the SIDX information still take some time to be processed. But the average bitrate is a bit higher than before, as the users who were at the bandwidth limit between two bitrates are now sticking to the highest one.”
Room for Improvement
“DASH makes a lot of sense for someone already doing Smooth: It’s compatible with Silverlight 4 with very little effort,” Coudurier says, referring to the previous ABR technology, which he calls less than perfect. “The Smooth manifest paradigm was really too complex, with its multiple client and server manifests. It was a questionable implementation, as the server manifest is only used to do quality lookups. We used Smooth custom attributes to trigger memory lookups instead of ISM lookups on the Smooth origin server, and it’s far more efficient.” Does that mean DASH is perfect? Probably not, in Coudurier’s opinion. “In Smooth, only the byte range support was missing to make Microsoft’s implementation complete,” he says. “With DASH and byte range, the manifests are a bit more verbose. Putting the DRM header in the manifest as we did in Smooth was smart, as this provides the private data needed to bootstrap the DRM component. And actually we do it for specific DASH clients, as we found the MOOV [movie atom] header a bit of overkill. Generally speaking, DASH could be lighter if we could put more information like SIDX in the manifest. We would have a better time to playback start because we would avoid a TCP connection to get the bootstrap information.”
Coudurier then provides more insights on other points that need to improve. “At the manifest level, we need more flexibility with segments’ URLs,” he says. “When you use segment timeline, your choice of variables is fixed and limited. We would need a more flexible and dynamic system where we could use freely the XML attributes that are present in the manifest. This flexibility is needed at the <Template> tag level, where we could inject as the custom attributes that we use in Smooth, like the fileID that is so useful to reference the files coming out of the MAM [media asset management]. Those limitations regarding the URL pattern make it difficult to be stricto sensu compatible with Smooth Streaming.”
These limitations can be circumvented, he adds: “Although this is difficult, we manage to create segment timeline manifests reusing the segments cached on the CDNs.”
Coming Soon: Better Ads
Ad insertion has been a headache in the previous ABR technologies, especially in Smooth. How does this change with DASH?
“With DASH and multiple periods, you can easily construct your manifests and you can switch to a simpler one-player approach for both content and ads, versus the old two-player approach where you need to synchronize one player for the content and the other one for the ads, a touchy operation as you need to control tightly the buffering of the ads so that it doesn’t cannibalize the bandwidth used for streaming the contents,” he says. “In DASH multiperiod, when you start to use Xlink (go2sm.com/xlink) to reference your ads, you can take all ad decisions at the last second before the ad is supposed to be triggered, [and] this is really powerful. That’s the next step for us, starting on the Roku platform where we already implemented the multiple periods feature.”
No doubt, the migration to DASH has been a major evolution for Hulu, and it’s a long-term advantage as well. “DASH already brought us a lot of benefits on the workflow and player levels,” Coudurier says. “It’s a central part of our engineering strategy and we are confident that it will allow us to evolve our service with maximum flexibility in the coming years. This is why we plan to join the DASH Industry Forum and contribute to its technical working groups: It’s the place where crucial aspects of DASH like ad insertion or DRM interoperability on the backend are shaping up. And it’s our common interest to contribute to the DASH-IF Guidelines and ensure they are always in sync with the OTT services requirements.”
GLOSSARY
AES: Advanced Encryption Standard, also known as the encryption algorithm, widely used to secure video contents
ATOM: Basic data unit inside a MP4 video file that contains a header and a data field that can contain various metadata or information
CENC: Common Encryption (ISO/IEC 23001-7:2012) standardizes the way encryption is applied on video contents. MPEG-DASH specifications are referencing CENC.
CTR: Short name for Counter Mode, the most popular variant of AES encryption
ISO-BMFF: ISO Base Media File Format (ISO/IEC 14496-12:2012) is the newest generation specification of the MP4 container.
MDAT: The atom where MP4’s actual raw information is stored
MFRA: Movie Fragment Random Access atom
MOOV: Short for “Movie Atom,” defining the timescale, duration, and display characteristics of the movie, as well as subatoms containing information for each track in the movie
PIFF: Protected Interoperable File Format, a Microsoft specification for a file container able to support several encryptions and DRM systems
PSSH: The Protection System-Specific Header box contains metadata needed by a specific Content Protection system to decrypt the media content.
SAIO: Sample Auxiliary Information Offsets
SAIZ: Sample Auxiliary Information Sizes
SENC: Sample Specific ENCryption data
SID: SystemID, identifier of the DRM technology used
SIDX: Segment Index BoxTFDT: Track Fragment Decode Time
XLINK: XML Linking Language specification from the W3C
Related Articles
Standardization fosters innovation, and MPEG-DASH is making huge strides. Learn the rapid steps DASH took in the past 12 months, and why nothing can stop its future.
22 Feb 2017
The next version of HbbTV is bringing a much more powerful toolset with it, and has the potential to change the current worldwide television landscape.
20 Nov 2015