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

HLS Live stream - Chromecast reproduction fails #1411

Closed
sergioavazquez opened this issue Apr 17, 2018 · 11 comments
Closed

HLS Live stream - Chromecast reproduction fails #1411

sergioavazquez opened this issue Apr 17, 2018 · 11 comments
Assignees
@theodab
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone
v2.5

Comments

@sergioavazquez
Copy link

Have you read the FAQ and checked for duplicate open issues?:
Yes
What version of Shaka Player are you using?:
v2.3.6
Can you reproduce the issue with our latest release version?:
Yes
Can you reproduce the issue with the latest code from master?:
Yes
Are you using the demo app or your own custom app?:
Demo app

What browser and OS are you using?:
Chrome 64 - Ubuntu
What are the manifest and license server URIs?:
Shaka demo asset: Shaka Player History (Live, HLS)
Also tested with a custom stream, same result.
(NOTE: a copy of the manifest text or an attached manifest will not be enough to reproduce your issue, and we will ask you to send a URI instead)

What did you do?
Start playing stream, initialize cast from player's controls.
What did you expect to happen?
Content being casted.
What actually happened?
Cast reproduction fails.
@theodab
Copy link
Collaborator

theodab commented Apr 17, 2018

When you say that "cast reproduction fails", do you mean that the receiver app fails to load, or that it loads but fails to play the stream?

I tried casting that sample from our Ubuntu lab machine, and it launched the receiver app but failed to play there. I tried other computers to cast from and other Chromecasts to cast to, and they failed to play Shaka Player History (Live, HLS) also.
Looking at VV output, the cast sender is receiving 'seeking' events, so it might be that the Chromecast is stuck trying to get into the seek window.

@sergioavazquez
Copy link
Author

It's the same behavior you experienced, it launches the receiver app but fails to play the stream.

@theodab theodab added status: waiting on response Waiting on a response from the reporter(s) of the issue and removed needs triage status: waiting on response Waiting on a response from the reporter(s) of the issue labels Apr 17, 2018
@theodab
Copy link
Collaborator

theodab commented Apr 17, 2018

Alright. I'll look into it. Thanks for the report.

@theodab theodab added the type: bug Something isn't working correctly label Apr 17, 2018
@theodab theodab self-assigned this Apr 17, 2018
@shaka-bot shaka-bot added this to the v2.4 milestone Apr 17, 2018
@theodab
Copy link
Collaborator

theodab commented Apr 17, 2018 •
edited

I tried using my WIP change for #1307, and the asset played correctly. So it definitely looks like this is a problem with the narrow seek window on HLS livestreams.
I think that it is seeking ahead to the start of the window and buffering, but by the time it is done buffering the start of the window has slipped ahead of the buffered range. So it seeks ahead again, and so on and so forth, in a loop.
I suppose you could just wait on the change for #1307, which will hopefully be out sometime this week, but requiring users to turn on an optional configuration option just for one of our sample assets to work seems non-ideal. Perhaps it'd be better to make the seek range on live HLS a little bit wider than 0s. Investigation will be required.

@theodab theodab modified the milestones: v2.4, v2.5 Apr 17, 2018
@joeyparrish joeyparrish modified the milestones: v2.5, v2.4 Apr 18, 2018
@joeyparrish
Copy link
Member

@theodab, how much wider does the seek range need to be to avoid this? Take a look at 7edb11b and see if MIN_SEEK_RANGE needs to be increased.

@theodab
Copy link
Collaborator

theodab commented Apr 19, 2018

Ok, I've tried a few values for MIN_SEEK_RANGE. 1s played, but was a bit choppy; it periodically had to pause and seek forward. Of the values I tried, 3s was the smallest that didn't have any choppiness.

@joeyparrish
Copy link
Member

Can you please test one more time on the V1 Chromecast? I want to be sure we are picking values that work on the slowest hardware we have.

Whatever works for the V1 Chromecast, let's choose that for MIN_SEEK_RANGE and leave comments explaining how we arrived at that value experimentally.

shaka-bot pushed a commit that referenced this issue Apr 19, 2018
@theodab
Increase MIN_SEEK_RANGE to 3s
a039c66 
On Chromecast, some streams were unable to keep up with the narrow
seek window, and got stuck perpetually seeking forward.
This change increases the seek window to 3 seconds long, which some
initial testing has shown to be the shortest value to play without
uncomfortable choppiness.
Unfortunately, v1 Chromecasts still have issues, even with this.
It seems like they have a separate issue.

Issue #1411

Change-Id: I597315cd418861b18e63a859197a8c2585cb4fd0
@theodab
Copy link
Collaborator

theodab commented Apr 19, 2018

This change is for the sake of the cast receiver, so you won't be able to see it in effect until we update the cast receiver.
It also doesn't fix things for v1 Chromecasts; no matter how much longer I made MIN_SEEK_RANGE, our test v1 Chromecast was unable to play that livestream reliably. I'll have to look into what additional problem is plaguing our playback on v1 Chromecasts, and address it in a followup CL.

joeyparrish pushed a commit that referenced this issue Apr 23, 2018
@theodab @joeyparrish
Increase MIN_SEEK_RANGE to 3s
4f09a24 
On Chromecast, some streams were unable to keep up with the narrow
seek window, and got stuck perpetually seeking forward.
This change increases the seek window to 3 seconds long, which some
initial testing has shown to be the shortest value to play without
uncomfortable choppiness.
Unfortunately, v1 Chromecasts still have issues, even with this.
It seems like they have a separate issue.

Issue #1411

Change-Id: I597315cd418861b18e63a859197a8c2585cb4fd0
joeyparrish pushed a commit that referenced this issue Apr 23, 2018
@theodab @joeyparrish
Increase MIN_SEEK_RANGE to 3s
d49e009 
On Chromecast, some streams were unable to keep up with the narrow
seek window, and got stuck perpetually seeking forward.
This change increases the seek window to 3 seconds long, which some
initial testing has shown to be the shortest value to play without
uncomfortable choppiness.
Unfortunately, v1 Chromecasts still have issues, even with this.
It seems like they have a separate issue.

Issue #1411

Change-Id: I597315cd418861b18e63a859197a8c2585cb4fd0
@joeyparrish
Copy link
Member

The changes that have been made so far are in v2.3.7 and will also be in our upcoming v2.4.0 release. I'm going to bump this to v2.5 for any additional investigation that is needed.

@joeyparrish joeyparrish modified the milestones: v2.4, v2.5 May 10, 2018
joeyparrish pushed a commit that referenced this issue Jun 29, 2018
@theodab @joeyparrish
Stop Playhead.onSeeking_ from infinitely recursing
25a32ea 
Playhead.onSeeking_ assumes that seeking is nearly instant;
thus, it has 0.001s tolerance. That works fine on most platforms, but
on some slow platforms (e.g. v1 Chromecasts), this can actually be a
problem. Specifically, it can cause them to get stuck in a loop of
repeatedly seeking, when playing HLS livestreams.
This changes Playhead.onSeeking_ so that it will only attempt to undo
a seek once every second. This way, if running on a slow platform, it
won't get stuck trying to seek to start time.

Closes #1411

Change-Id: Ia4fa6da8bcd90eb04b80d80c3f793bba2a7f382d
@joeyparrish
Copy link
Member

Cherry-picked for v2.4.2.

joeyparrish pushed a commit that referenced this issue Jun 29, 2018
@theodab @joeyparrish
Stop Playhead.onSeeking_ from infinitely recursing
31378a4 
Playhead.onSeeking_ assumes that seeking is nearly instant;
thus, it has 0.001s tolerance. That works fine on most platforms, but
on some slow platforms (e.g. v1 Chromecasts), this can actually be a
problem. Specifically, it can cause them to get stuck in a loop of
repeatedly seeking, when playing HLS livestreams.
This changes Playhead.onSeeking_ so that it will only attempt to undo
a seek once every second. This way, if running on a slow platform, it
won't get stuck trying to seek to start time.

Closes #1411

Change-Id: Ia4fa6da8bcd90eb04b80d80c3f793bba2a7f382d
@joeyparrish
Copy link
Member

Cherry-picked for v2.3.10.

@shaka-project shaka-project locked and limited conversation to collaborators Aug 21, 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
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Projects
None yet
Milestone
v2.5
Development

No branches or pull requests
4 participants
@joeyparrish @shaka-bot @theodab @sergioavazquez