gliese1337
commented
9 years ago Having done some initial work on the problem, I've now got a pretty good overview of how the whole thing ought to work:
The M3U8 module should expose a single factory function that take in a manifest URL and returns a list of M3U8Manifest objects. If the given manifest file is already a Media Playlist, the factory will return a single-element list with an M3UManifest object derived from that single manifest. Otherwise, if the given file is a Master Playlist, URLs for Media Playlists are extracted, and an M3U8Manifest object is constructed from each one.
Clients are not required to reload Master Playlists, so there is no need to create special Master Playlist objects distinct from the M3U8Manifests managing the Media Playlists, and the URL for and data in the Master Playlist can be discarded.
The player is then in charge of selecting which version to use out of the returned list of M3U8Manifests, and an individual M3U8Manifest object is responsible for handling its own reloading logic whenever activated by the player.
donato
At the moment, the only interface to the M3U8 implementation is a single parseHLS function which takes the text of an m3u8 file and returns a promise for a list of segments. This makes it very difficult to handle live streams, which requires re-requesting the manifest file at regular intervals to get the updated segment lists.
Ideally, we'd instead have an M3U8 object that knows the URL to the manifest file and fires events to notify the player when new segments are available. This will, of course, also require refactoring in the player to handle the changed interface.