feat: hls-parser from service locator #50
Conversation
|
Note Urls will be available only after netlify deploy. PreviewApi Reference
Demo |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #50 +/- ##
==========================================
+ Coverage 63.95% 64.28% +0.33%
==========================================
Files 114 114
Lines 4830 4833 +3
Branches 633 635 +2
==========================================
+ Hits 3089 3107 +18
+ Misses 1733 1719 -14
+ Partials 8 7 -1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
✅ Deploy Preview for videojsdev ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
size-limit report 📦
|
| }); | ||
| return new HlsPipeline(dependencies); | ||
| } | ||
| } |
There was a problem hiding this comment.
So, the flow is following:
user registers pipeline-loaders via pipelineLoaderFactory storage, or via separate api for worker-based player (so it is opt-in operation)
user calls load with some payload includeing mimeType
player checks and finds match for loaded mimeType and pipeline-loader-factory
player creates pipeline-loader instace via found factory and injects core deps
player passes loadPlayload to the created loader instance
loader creates parser via registered factory and injects core deps
loader loads manifest/playlist
loader parses received data
loader creates pipeline via registered factories and passes core deps and parser instance and returns this instance back to the player.
so as you can see there is a layer of dependency injections
so, we should have a static members to register hls parser factory (not instance) in the hls-pipeline-loader (not pipeline itself)
anticipated follow-up question:
why do we need pipeline-loader? can’t we just create pipeline directly in the player?
because we want separate classes for live and vod pipelines and we don’t know ahead of time which one to create. We can understand it only once we load and parse playlist/manifest.
There was a problem hiding this comment.
so, we should have a static members to register hls parser factory (not instance) in the hls-pipeline-loader (not pipeline itself)
For clarification, do we want to expose the instance of the parser (this.parser_) from the hls-pipeline-loader via the service-locator or do we want to simply expose the factory? I refactored to expose registered factory, per the feedback above, however the rfc example indicates we would want to expose the current instance of the parser instead:
const hlsParser = serviceLocator.getHlsParser();
hlsParser.parse(playlist);
|
|
||
| public static getHlsParser(): typeof ChunkPlaylistParser | null { | ||
| return HlsPipelineLoader.hlsParserFactory_; | ||
| } |
There was a problem hiding this comment.
Can we rename getters and setter as getHlsParserFactory and setHlsParserFactory?
|
|
||
| public getHlsParser(): typeof ChunkPlaylistParser | null { | ||
| return HlsPipelineLoader.getHlsParser(); | ||
| } |
There was a problem hiding this comment.
lets just remove HLS parser from service locator for now
| const parser = ChunkHlsParser ? ChunkHlsParser.create({}) : null; | ||
| expect(parser).toBeInstanceOf(ChunkPlaylistParser); | ||
| }); | ||
| }); |
There was a problem hiding this comment.
can we remove this test for now?
Description
getHlsParserfunctionality to the service locator.Specific Changes proposed
expose the full HLS parser through the a
getHlsParserfunction and add tests.Requirements Checklist