-
Notifications
You must be signed in to change notification settings - Fork 133
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
transports: segment parser now return result synchronously
Every segment parser in `src/transports` (which allows to parse things like data, encryption metadata and time information from loaded segments according to the current streaming protocol) do so synchronously. However, those are typed as Observables. My guess (this was before my time on the project) is that it was mainly for two reasons: 1. Manifest parsing can be asynchronous (for example to fetch MPD xlinks or the clock) and it follows the same pipeline architecture (a loader and a parser) than segments. Letting segment parser be asynchronous thus allows to harmonize all resource-fetching code to a similar interface. 2. Theorically, segment parsing could be asynchronous. As far as I can see for now, this could be because of two reasons: - We need to perform an HTTPS request to fully parse segment information. We already encountered such case when trying to implement the "sidx ref type 1" feature (#754). However we did not merge that work for now due to the complexity and most of all because no real DASH MPD seems to rely on this feature (nor ar we able to envisage a real use-case for it). - segment parsing is performed in a Worker. But We do not feel the need to do that for now as the CPU footprint of parsing segments is really low. So theorically, there's good reasons to make the parsing operation asynchronous, but reastically for now, there's none. Meanwhile, making that operation asynchronous lead to big headaches: - it is one of the main reasons why the PR on making the init and first media segment's requests in parallel [#918] was not merged. Subtle bugs, some that would only be seen in a case where the parsing is asynchronous (so not really existant for now) could arise because of that. - Even if the response of the parser is wrapped in an Observable, it wasn't lazy (the code would be called even if the parser was not subscribed to). We could fix that by wrapping all parsers in a `defer` call from RxJS, but it would complexify even more the code. - Handling Observables is a LOT harder than just using directly a response in general. There's pending work about not depending so much on RxJS in the future [#916] and I think beginning to remove it where it is not even needed is a good first step. If it become needed again in the future (e.g. to support the "sidx ref type 1" feature), we could always revert that work, maybe even with a more Promise-based solution which might be much easier to reason about. Thoughts?
- Loading branch information
1 parent
967df26
commit 7dfd996
Showing
12 changed files
with
307 additions
and
323 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.