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.

Sign up for GitHub

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

Jump to bottom

Demo: HLS Live seek is not possible #1307

Closed
avelad opened this issue Feb 15, 2018 · 18 comments
Closed

Demo: HLS Live seek is not possible #1307

avelad opened this issue Feb 15, 2018 · 18 comments
Assignees
@theodab
Labels
component: HLS The issue involves Apple's HLS manifest format status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
Tracks & manifest refactor
Milestone
v2.5

Comments

@avelad
Copy link
Collaborator

avelad commented Feb 15, 2018

Using https://shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-live-assets/player-source.m3u8;lang=es-419;build=uncompiled

Seek is not possible with HLS Live

Shaka Player Demo.zip
@joeyparrish
Copy link
Member

This is intended, and is consistent with built-in HLS support in Safari.

Can you give us some details on how you expected it to work?

@joeyparrish joeyparrish added the status: working as intended The behavior is intended; this is not a bug label Feb 15, 2018
@avelad
Copy link
Collaborator Author

avelad commented Feb 15, 2018

I expect that works the same way that DASH.
We want offer to the user the same experiencie with DASH and HLS. We offer to the users a n-timeshift over live stream ( the same as Youtube, eg: https://www.youtube.com/watch?v=0tek2aa8hAQ)

https://shaka-player-demo.appspot.com/demo/#asset=//storage.googleapis.com/shaka-live-assets/player-source.mpd;lang=es-419;build=uncompiled

Shaka Player Demo.zip

@joeyparrish joeyparrish added type: enhancement New feature or request component: HLS The issue involves Apple's HLS manifest format and removed status: working as intended The behavior is intended; this is not a bug labels Mar 2, 2018
@joeyparrish joeyparrish added this to the Backlog milestone Mar 2, 2018
@joeyparrish
Copy link
Member

We can probably make this configurable, and make it apply to all live streams (DASH & HLS). By default, we would allow seeking to any segment we know about. The other option would be to disallow live stream seeking, as we do today for HLS live.

@joeyparrish joeyparrish mentioned this issue Mar 2, 2018
Closed
@joeyparrish joeyparrish modified the milestones: Backlog, v2.5 Mar 4, 2018
@joeyparrish joeyparrish mentioned this issue Mar 6, 2018
Closed
@theodab theodab self-assigned this Mar 28, 2018
@theodab theodab mentioned this issue Apr 17, 2018
Closed
@theodab theodab moved this from Actionable to Blocked in Tracks & manifest refactor Jul 3, 2018
@theodab theodab moved this from Blocked to Actionable in Tracks & manifest refactor Jul 11, 2018
@theodab theodab moved this from Actionable to In progress in Tracks & manifest refactor Jul 11, 2018
Tracks & manifest refactor automation moved this from In progress to Done Jul 16, 2018
@theodab
Copy link
Collaborator

theodab commented Jul 16, 2018

You should be able to seek in HLS live streams now. Just set the manifest.availabilityWindowOverride configuration to an appropriate value before loading the stream.

@avelad
Copy link
Collaborator Author

avelad commented Jul 17, 2018

hi @theodab

it's not working as expected, how can you knowWindow by default in HLS? with the new configuration I can only set a value if the value it's know by the application, but the real availabilityWindow is already included in the stream

By default the behavior it's the same as in previous releases (eg 2.4.2) and the default behavior is different to DASH.

@theodab
Copy link
Collaborator

theodab commented Jul 17, 2018

Well, in that case, you should wait on #999.
That issue is currently blocked, awaiting other refactors, but it's also in the 2.5 milestone so you won't be waiting forever.

@joeyparrish
Copy link
Member

Yes, the default behavior is intentionally the same as in 2.4.2. This change gives you an explicit override, for both DASH & HLS.

@avelad, try setting the override to Infinity. Does that get you the full seek range you want?

@avelad
Copy link
Collaborator Author

avelad commented Jul 18, 2018

Hi @joeyparrish,

I just tested with Infinity and I get more range than declared in the playlist. This does not work for an EVENT playlist (startover funcionality) because the start is a known value, but the duration change in each update.

I attach a video with the test.
Issue-1307.zip

@joeyparrish
Copy link
Member

I think this feature is not working correctly. I will reopen and investigate.

@joeyparrish joeyparrish reopened this Jul 20, 2018
Tracks & manifest refactor automation moved this from Done to In progress Jul 20, 2018
@joeyparrish
Copy link
Member

The override set by the player after the initial manifest is parsed is wiped when a live manifest is updated.

Tracks & manifest refactor automation moved this from In progress to Done Jul 20, 2018
@joeyparrish
Copy link
Member

@avelad, can you please try again with the latest code? I believe we have fixed the issue.

@joeyparrish
Copy link
Member

Actually, we've just discovered what appears to be a related bug in the HLS parser. Setting availabilityWindowOverride to Infinity does what I would expect in DASH: the segments that appear in the manifest can all be seeked to. This is not the case for HLS. Right now, with the same setting and an HLS live stream, the seek range includes all segments that have ever existed, including ones that don't appear in the playlist any longer. We should be able to fix this. @theodab will investigate.

Sorry for the inconvenience. I think (hope?) this should be the last change required for this.

@joeyparrish joeyparrish reopened this Jul 20, 2018
Tracks & manifest refactor automation moved this from Done to In progress Jul 20, 2018
@avelad
Copy link
Collaborator Author

avelad commented Jul 23, 2018

I found thaht it's not possible configure availabilityWindowOverride = Infinity in Demo page, is it possible add Infinity value?

@joeyparrish
Copy link
Member

That's a limitation of <input type=number>. You could use a sufficiently large number in the demo, such as 9999999999 (larger than the current Unix time in seconds).

@TheModMaker
Copy link
Contributor

@joeyparrish I would think there would be three distinct use cases for this setting:

  1. Not setting anything: Non-seekable HLS and using timeShiftBufferDepth for DASH.
  2. Setting availabilityWindowOverride: Using that value to indicate the time that segments remain alive for and determining the seek range.
  3. Using Refactor to derive live edge from list of segments #999: The segments that appear in the latest manifest determine the seek range.

So setting to Infinity would mean (to me) to be all segments are available forever, similar to not having a timeShiftBufferDepth in DASH. If I am wrong, how do you see setting to Infinity being different than #999?

@joeyparrish
Copy link
Member

@TheModMaker, you are right. For HLS, there is no difference between a window override of Infinity and my plans for #999. For DASH, it is a bit different. Until #999 is solved, the DASH live edge is based on availabilityStartTime, not the segment list. For HLS, it is already based on the segment list.

Tracks & manifest refactor automation moved this from In progress to Done Jul 27, 2018
@theodab
Copy link
Collaborator

theodab commented Jul 27, 2018

Okay, with that change, setting availabilityWindowOverride to Infinity (or some other arbitrary large value) should now properly set the start time on an HLS livestream.

@avelad
Copy link
Collaborator Author

avelad commented Jul 30, 2018

I just tested and everything works as expected. Thanks!!

joeyparrish pushed a commit that referenced this issue Aug 6, 2018
@theodab @joeyparrish
Add availabilityWindowOverride configuration.
b0d05e4 
This config lets you override the availability window of a live stream.
It is in config.manifest, and passed along on start.
This will let users configure the parser so that they can seek with HLS
live streams, for example.

Closes #1177
Closes #1307

Change-Id: Icd3c1d81c6b52ebdbb72137df42fc91cd73a0207
joeyparrish added a commit that referenced this issue Aug 6, 2018
@joeyparrish
Move availabilityWindowOverride to manifest parsers
ec33137 
This reverts the implementation to an earlier draft state.  During
review of the first version, I recommended moving the implementation
to Player so that it would be independent of the manifest parsers.
That was bad advice on my part, because this overlooked updates made
by the parsers when live manifests are updated later.

Closes #1177
Closes #1307

Change-Id: I4611e00824dead83c6467da04a2a11afa892ace7
joeyparrish pushed a commit that referenced this issue Aug 6, 2018
@theodab @joeyparrish
Notify segments on HLS manifests
c23725f 
Beforehand, we would call presentationTimeline.notifyMaxSegmentDuration,
which effectively does half of what presentationTimeline.notifySegments
does. At the time, we only thought that that was only what we had to do.
However, it did mean that we were never setting the
maxFirstSegmentStartTime_, which was causing HLS livestreams with
overridden segment availability times to have incorrect seek ranges.

Closes #1307

Change-Id: I3a9385eb522579156e088f298e404063bf9542dd
@shaka-project shaka-project locked and limited conversation to collaborators Sep 25, 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.
Assignees

@theodab theodab

Labels
component: HLS The issue involves Apple's HLS manifest format status: archived Archived and locked; will not be updated type: enhancement New feature or request
Projects
No open projects
Tracks & manifest refactor
  
Done
Milestone
v2.5
Development

No branches or pull requests
5 participants
@TheModMaker @joeyparrish @avelad @shaka-bot @theodab