Smooth Streaming support
Created by: bbert
We, at Orange Labs (me and my colleague @nicosang), started integration of smooth streaming support into dash.js, as we proposed last year during dash.js f2f meeting. For the time being, we have achieved to extend dash.js in order to support smooth streaming static streams, clear and encrypted (with PlayReady).
What we have done:
- Add of ‘src/mss’ source package.
- Add of smooth streaming parser MssParser, that parses smooth streaming manifest and converts it into dash manifest object: mapping from smooth streaming nodes to dash nodes including creation of SegmentTimelines
- Add of MssHandler that hands processing of initialization and media segments. This class is registered on INIT_REQUESTED and FRAGMENT_LOADING_COMPLETED in order to trigger these segments processing. We took benefit of events priority and propagation system in order to generate initialization segments without sending http requests, and to process media segments before being appended into the buffers
- Integration of protocol detection and appropriate parser instantiation in the ManifestLoader
- Integration of the MssFragmentProcessor that is used to generate initialization segments (based on manifest information) and process media segments in order to convert them into MSE compliant media segments (for example transform tfxd box into tfdt box)
- Add of some more attributes (codecs, codecPrivateData) to Dash manifest model’s Representation object that are required to generate initialization segments
- Integration of a new version if codem-isoboxer library which is now capable of generating/writing mp4 files. We have contributed to this library to add these new functionalities with reduced overhead. The version used is the 0.3.0.
All these additional stuff have no impact on dash contents processing. Also the mss package is not included by default in the core MediaPlayer build file since we have integrated the mss package as it has been done for protection and metrics packages.
Finally, we had to modify some part of the core streaming as we already proposed in #1669. This is required for smooth streaming use case so that an event for generating initialization segment is also sent at startup, which is actually not the case. This PR has not been accepted because it was introducing some regression with some streams, but by reading the last comments this is not the reason.