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

No bitrate adaptation with recent Shaka Player v2.0.0-beta2 and manifests from Wowza #367

Closed
BucherTomas opened this issue May 5, 2016 · 4 comments
Assignees
Labels
status: archived Archived and locked; will not be updated type: bug Something isn't working correctly
Milestone

Comments

@BucherTomas
Copy link
Contributor

One of the recent commits, sometime between Shaka Player v2.0.0-beta and Shaka Player v2.0.0-beta2, seems to have disabled bitrate adaptation with manifests provided by Wowza. Should be reproducible with http://w01.quickmedia.tv/mbr/x/manbeast/manbeast.smil/manifest.mpd .

With enabled logging by using the 'vv' URL parameter, the console log in Chrome keeps repeating "Still within switch interval..." and no bitrate adaptation takes place. On the other hand, default multi bitrate content such as "Car" properly reports in console debug log

Calling switch_()... bandwidth=9571 kbps
switch_
switch: Stream (audio:8) already active
switch: switching to Stream (video:1)

and the player switches to higher video bitrate.

Multi bitrate content from Wowza used to work fine until Shaka Player v2.0.0-beta, still can be confirmed when using http://v1-6-5.shaka-player-demo.appspot.com/

@BucherTomas
Copy link
Contributor Author

Actually, after some further testing, this appears to be caused by bandwidth estimation.

If I have ample bandwith available and the chunks are delivered very quickly, the bitrate adaption event is not even triggered and the playback is stuck on the first video track with the lowest quality. However, if I saturate my download speed to the max with some bandwidth-hungry connection like downloading a big file, bitrate adaptation suddenly starts working.

That is also possibly why the bitrate adaptation works for me with default content from Shaka demo as the delivery is a bit slower due to geographical distance to my location, but the connection between our local Wowza server and me is fast and this leads to some likely faulty bandwidth estimation. This also means that my manifest example will not likely exhibit the same behavior, say, in the US, and it might not be reproducible there.

Still, this needs to be influenced by a recent commit, as older Shaka versions behave properly in this regard.

@joeyparrish joeyparrish self-assigned this May 5, 2016
@joeyparrish joeyparrish added the type: bug Something isn't working correctly label May 5, 2016
@joeyparrish
Copy link
Member

Can you try reverting a commit for me locally to see what happens? I'm suspicious of 60d2944.

@BucherTomas
Copy link
Contributor Author

Yes, that was exactly it. After I reverted the commit, bitrate adaptation started to work from our server as usual. Good call, Joey.

@joeyparrish
Copy link
Member

Okay, then I'll go ahead and revert that commit and reopen the bug it was supposed to fix. Thanks for testing!

@joeyparrish joeyparrish added this to the v2.0.0 milestone May 5, 2016
@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: bug Something isn't working correctly
Projects
None yet
Development

No branches or pull requests

3 participants