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

Reimplement in-progress recording support #477

Closed
joeyparrish opened this issue Aug 7, 2016 · 8 comments
Closed

Reimplement in-progress recording support #477

joeyparrish opened this issue Aug 7, 2016 · 8 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Milestone

Comments

@joeyparrish
Copy link
Member

We reverted a mostly-complete in-progress recording (IPR) solution in da03f439 due to #463. I have been working with @baconz to define requirements and will reimplement with a different model for v2.0.0.

@joeyparrish joeyparrish added the type: enhancement New feature or request label Aug 7, 2016
@joeyparrish joeyparrish added this to the v2.0.0 milestone Aug 7, 2016
@joeyparrish joeyparrish self-assigned this Aug 7, 2016
shaka-bot pushed a commit that referenced this issue Aug 29, 2016
This change creates a new model which divides DASH streams into VOD,
IPR, and live.  It is possible to create manifests which do not fit
into any of the three categories according to our model, so we now
assert that our input fits cleanly into one of the three.

Inline manifests used in our tests had to be updated to conform to
the new model.  All external test assets have been verified to fit
into these categories.

This is phase 1 of IPR support.  There should be no behavior change
in this CL.

In phase 2, we will make various other parts of the library aware of
IPR so that IPR-specific behaviors can be achieved.

Issue #477

Change-Id: I395d3a0c8c9825a3cd2efde263b8493ce0920ed9
@joeyparrish
Copy link
Member Author

@baconz, please try the latest from master and let us know how it's working for you.

@baconz
Copy link
Contributor

baconz commented Aug 29, 2016

@joeyparrish lgtm. It works with our content.

The demo player is a bit messed up, though. I think it should either only let you seek to seekRange.end or we should introduce a differentiation between the scrubbable range and the width. Right now it will let you seek into an unbufferable range.

@joeyparrish
Copy link
Member Author

I think as long as we're using <input type="range">, the entire width of the scrubber will always be usable. I don't believe we can say "size as if it's 0-100, but reject 62-100".

Technically speaking, we could render our own scrubber without using <input>, but we are not going to invest a lot into UI changes for the demo right now.

So I think the scrubber's range will just have to grow as the recording progresses, so that the user can't seek to an unavailable position. You can, of course, do something sleeker for your own app.

Sound reasonable?

@joeyparrish joeyparrish reopened this Aug 29, 2016
@baconz
Copy link
Contributor

baconz commented Aug 29, 2016

Yep, sounds perfect.

@joeyparrish
Copy link
Member Author

Better?

@baconz
Copy link
Contributor

baconz commented Aug 29, 2016

Yes, looks good.

One more small issue: I think IPRs should take the presentationDelay into account when calculating the seekRangeEnd.

@joeyparrish
Copy link
Member Author

Okay, should be fixed now.

@baconz
Copy link
Contributor

baconz commented Aug 30, 2016

Sweet, thanks.

@shaka-project shaka-project locked and limited conversation to collaborators Mar 22, 2018
@shaka-bot shaka-bot added the status: archived Archived and locked; will not be updated label Apr 15, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants