shaka-project
Stop setting playbackRate to 0 to control buffering state
Have you read the FAQ and checked for duplicate open issues? yes.
What version of Shaka Player are you using? 2.5.4
Can you reproduce the issue with our latest release version? yes.
Can you reproduce the issue with the latest code from master?
haven't tried.
Are you using the demo app or your own custom app?
custom app.
If custom app, can you reproduce the issue using our demo app?
I can simulate the same network state but cant tell if the events are being fired. When audio stops with your "dig the uke" song I see the pause button show up with a circular animation indicating that you are aware that playback has stopped.
What browser and OS are you using? MacOS 10.14.5. Chrome 76.0.3809.100 and Safari 12.1.1 .
For embedded devices (smart TVs, etc.), what model and firmware version are you using? NA (for now)
What are the manifest and license server URIs?
Will send in mail. I dont think it has to do with the stream - other than the fact that it is an audio only stream.
What did you do?
-
get Shaka player ready to play audio only stream. Register for the 'waiting' event on the audio object.
-
Start playback. Throttle down internet in chrome to 50Kbps (or something low) - observe that audio will stutter but no waiting event is thrown.
Note: also listening for 'buffering' event on the Shaka player and its not coming through. I do receive the canplay, canplaythrough and progress events on the audio object. I am also getting an adaptation event even through the dash stream is fixed at 128Kbps.
What did you expect to happen?
the waiting event to fire when the audio is auto paused. And then the canplay or canplaythrough events to be fired when playback is resumed.
NOTE when we use Safari to play HLS - the expected events are fired. When we use safari to play dash (via Shaka) the expected events are not fired.
What actually happened?
Waiting is not fired.
This is probably user error on my part but ive looked and looked for my mistake and I am not seeing it.
_audioElement = document.createElement( 'audio' ); //'video' doesnt change anything
document.body.appendChild(_audioElement);
_shakaPlayer = new shaka.Player(_audioElement);
_audioElement.addEventListener('waiting', function(event){
console.log("IS: audio waiting");
//do stuff
});
Below is a simple log of the playback with expected time (ET) and actual time (AT) of the audio element. It is updating every half second. you can see at ET 14.08 the AT doesnt change for a whole second. and at ET 17.04 AT stays 15.55 for a while. I would expect to see the waiting event fired during those times.
ET: 0.51 --- AT 0.43 ET: 1.02 --- AT 0.95 ET: 1.54 --- AT 1.46 ET: 2.05 --- AT 1.98 ET: 2.57 --- AT 2.50 ET: 3.09 --- AT 3.02 ET: 3.51 --- AT 3.43 ET: 4.02 --- AT 3.94 ET: 4.53 --- AT 4.46 IS: audio progress ET: 5.04 --- AT 4.97 ET: 5.55 --- AT 5.48 ET: 6.07 --- AT 5.99 ET: 6.57 --- AT 6.50 ET: 7.08 --- AT 7.00 ET: 7.49 --- AT 7.42 ET: 8.01 --- AT 7.94 ET: 8.52 --- AT 8.45 ET: 9.04 --- AT 8.96 ET: 9.55 --- AT 9.48 IS: audio progress ET: 10.07 --- AT 10.00 ET: 10.59 --- AT 10.51 ET: 11.00 --- AT 10.93 ET: 11.51 --- AT 11.44 ET: 12.02 --- AT 11.95 ET: 12.54 --- AT 12.46 ET: 13.05 --- AT 12.98 ET: 13.57 --- AT 13.49 ET: 14.08 --- AT 13.54 ET: 14.59 --- AT 13.54 IS: audio progress ET: 15.00 --- AT 13.65 ET: 15.51 --- AT 14.16 ET: 16.02 --- AT 14.67 ET: 16.53 --- AT 15.18 ET: 17.04 --- AT 15.55 ET: 17.55 --- AT 15.55 ET: 18.06 --- AT 15.55 ET: 18.58 --- AT 15.55 ET: 19.09 --- AT 15.55 ET: 19.50 --- AT 15.55 ET: 20.02 --- AT 15.65 IS: audio progress ET: 20.53 --- AT 16.16 ET: 21.05 --- AT 16.68 ET: 21.56 --- AT 17.19 ET: 22.08 --- AT 17.32 ET: 22.59 --- AT 17.32 ET: 23.00 --- AT 17.32 ET: 23.51 --- AT 17.32 ET: 24.02 --- AT 17.32 ET: 24.54 --- AT 17.32 ET: 25.05 --- AT 17.32 IS: audio progress ET: 25.55 --- AT 17.65 ET: 26.06 --- AT 18.16 ET: 26.57 --- AT 18.68 ET: 27.08 --- AT 19.18 ET: 27.49 --- AT 19.34 ET: 28.01 --- AT 19.34 ET: 28.52 --- AT 19.34 ET: 29.03 --- AT 19.34 ET: 29.55 --- AT 19.34 ET: 30.07 --- AT 19.34 IS: audio progress ET: 30.57 --- AT 19.66 ET: 31.09 --- AT 20.17 ET: 31.50 --- AT 20.58 ET: 32.00 --- AT 21.09 ET: 32.51 --- AT 21.37 ET: 33.03 --- AT 21.37 ET: 33.54 --- AT 21.37 ET: 34.06 --- AT 21.37 ET: 34.57 --- AT 21.37 ET: 35.08 --- AT 21.37 ET: 35.49 --- AT 21.37 IS: audio progress ET: 36.00 --- AT 21.79 ET: 36.52 --- AT 22.30 ET: 37.03 --- AT 22.81 ET: 37.53 --- AT 23.32 ET: 38.04 --- AT 23.37 ET: 38.55 --- AT 23.37 ET: 39.05 --- AT 23.37 ET: 39.55 --- AT 23.37 ET: 40.06 --- AT 23.37 ET: 40.58 --- AT 23.37
This is because of how we handle buffering. We have our own buffering state at a higher level. You can use the buffering event from the Player object, as well as the player.isBuffering() to check the buffering state.
I'll mark it as an enhancement to remove this logic and let the browser buffer state take effect instead. This does not seem necessary any more.
Thanks Joey. I now have a better sense of it. I also had a bug where I was trying to stringify the buffering event in console.log and no error was being thrown and nothing was being printed so I figured no event was being fired. But I changed how I was printing state and its now working as I would expect. Thanks for confirming.
You're welcome. But I'm going to reopen this as an enhancement to remove our buffering logic and let the browser control buffering state and signal through waiting and stalled events. This was a reasonable expectation, and I've been in internal discussions about changing this behavior anyway.
I'm not sure yet when we'll have time to work on it, but I'll keep this open to track that work. Thanks!
Since this has been reverted, and a multitude of problems have been seen, I don't think we want to implement this. Because the alternative may be to use play/pause but it is worse....
@avelad @joeyparrish Is there a summary of issues that caused this change to be reverted? My assumption would have been that it'd work fine given enough consideration, since it works for other media players (e.g. hlsjs)
@martinstark, I think it definitely could work, but after nearly 10 years of building on top of that system, there may be assumptions all over the place that we don't know we're making. The simple removal of it caused a cascade of other issues in systems that depended on it in some explicit or subtle way.