-
Notifications
You must be signed in to change notification settings - Fork 425
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: Add a better distinction between master and child dash loaders #992
Conversation
1cdbf5f
to
1ece93f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one question, really
if (typeof srcUrlOrPlaylist === 'string') { | ||
if (this.isMaster_) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we verify that srcUrlOrPlaylist
is a string or is it basically guaranteed to be one if we're a master manifest?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For master it will always be a string, for others it can be a playlist or string. So yes it would seem so.
@@ -528,7 +518,7 @@ export default class DashPlaylistLoader extends EventTarget { | |||
|
|||
// request the specified URL | |||
this.request = this.vhs_.xhr({ | |||
uri: this.srcUrl, | |||
uri: this.masterPlaylistLoader_.srcUrl, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we return early above for non master loaders, would it be clearer to use just this
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we want it to be like this because:
- The distinction will help us migrate master playlist loader code into a new file after these refactors.
- It's much easier to know that you are accessing the correct object if you always access it the same way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Thanks!
this.srcUrl = srcUrlOrPlaylist; | ||
// TODO: reset sidxMapping between period changes | ||
// once multi-period is refactored | ||
this.sidxMapping_ = {}; | ||
return; | ||
this.masterPlaylistLoader_.sidxMapping_ = {}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since we have the conditional above for master loaders, would it be clearer to use just this
?
masterXml: this.masterPlaylistLoader_.masterXml_, | ||
srcUrl: this.masterPlaylistLoader_.srcUrl, | ||
clientOffset: this.masterPlaylistLoader_.clientOffset_, | ||
sidxMapping: this.masterPlaylistLoader_.sidxMapping_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same question re: above
Co-authored-by: Garrett Singer <[email protected]>
Description
I am working on refactoring the parsing logic in dash-playlist-loader. This is difficult because the logic is almost impossible to follow in the current state of the code. I tried a grand over-arching refactor and ultimately wasn't happy with it. Instead I am going to opt for smaller changes to get us towards what we want.
Steps
this.masterPlaylistLoader
tothis
for master so that operations that update master always happen onthis.masterPlaylistLoader
. This simplifies a lot of the code and makes it much easier to understand.filterChangedSidxMappings
use this logic rather than parsing on it's own.