Skip to content
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

Consider minimum update period to refresh manifest (Simpler alternative) #347

Merged
merged 19 commits into from
Oct 29, 2018

Conversation

grenault73
Copy link
Contributor

No description provided.

@peaBerberian
Copy link
Collaborator

peaBerberian commented Oct 23, 2018

This looks pretty nice 👍 .

I'm thinking about if we can write code even more concize by changing the place where we catch "needs-manifest-refresh" events, to perform all manifest updates in the same place.

@peaBerberian
Copy link
Collaborator

Oh yeah, also run npm run check or check Travis next time :p there is a styling issue here.

@peaBerberian peaBerberian mentioned this pull request Oct 23, 2018
16 tasks
@peaBerberian peaBerberian added enhancement This is a new feature and/or behavior which brings an improvement to the RxPlayer DASH Relative to the DASH streaming protocol labels Oct 24, 2018
Copy link
Collaborator

@peaBerberian peaBerberian left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're quasi done! 👍

return parser({ response: value, url }).pipe(
map(({ manifest: parsedManifest }) => {
const manifest = new Manifest(parsedManifest, warning$, transport.options);
const manifestFetchingDuration = sentTime ?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've two main problems with the fact that we communicate a manifestFetchingDuration:

  • it is not a fetching duration but a fetch + parse one
  • the time between this operation and the usage of it could be extended in future evolutions without us expecting any problem with that

If I understood it correctly this operation should be the closest possible to performance.now at the time the corresponding timeout is started.
Why not just communicating the requestTime. It might even make more sense as a manifestUpdate event, as it can be used to sort chronologically such updates.

const loadStream = StreamLoader({ // Behold!
mediaElement,
manifest,
manifestFetchingDuration,
Copy link
Collaborator

@peaBerberian peaBerberian Oct 29, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not regrouping these two under a manifestInfos name or something?
(With both the manifest and the requestTime)

}),
share() // share the previous side effect
);
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks clean 👍

// the update period has elapsed.
const updateManifest$ = refreshMinimumUpdatePeriod$.pipe(
mergeMap((lastUpdatePeriod) => {
return observableTimer(lastUpdatePeriod * 1000).pipe(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To think of it the performance.now() - requestTime difference might even be calculated here... To see if that makes sense and if it is readable

}
return EMPTY;
case "needs-manifest-refresh":
log.debug("needs manifest to be refreshed");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I prepend now a Stream: namespace in the StreamLoader's logs, to better help us debugging with logs on

case "needs-manifest-refresh":
log.debug("needs manifest to be refreshed");
// out-of-index messages require a complete reloading of the
// manifest to refresh the current index
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this comment makes no sense here (might me mine, but I just realized that)

tap((manifestUpdateEvt: IManifestUpdateEvent) => {
const { minimumUpdatePeriod } = manifestUpdateEvt.value.manifest;
if (minimumUpdatePeriod && minimumUpdatePeriod > 0) {
refreshMinimumUpdatePeriod$.next(minimumUpdatePeriod);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wait, didn't you forget to perform the substraction here?

// Creates an observable which will refresh the manifest after
// the update period has elapsed.
const updateManifest$ = refreshMinimumUpdatePeriod$.pipe(
mergeMap((lastUpdatePeriod) => {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a fan of this variable's name. It's actually the maximum refresh timeout of the manifest right here.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, shouldn't it be a switchMap?

@peaBerberian peaBerberian changed the base branch from master to release/v3.9.0 October 29, 2018 17:47
@peaBerberian peaBerberian merged commit bc7ebfa into release/v3.9.0 Oct 29, 2018
@peaBerberian peaBerberian deleted the feat/minimum-update-period2 branch November 27, 2018 10:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
DASH Relative to the DASH streaming protocol enhancement This is a new feature and/or behavior which brings an improvement to the RxPlayer
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants