-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Controlling cast stream reproduction fails when using widevine. #1128
Comments
When casting, video and player properties such as paused have their states slaved to the cast receiver in periodic status updates. If video_.paused is always returning true, even when the video is playing, that sounds like there might be some problem with this process. If it's happening with some types of content but not others, it seems more likely to be a problem on the receiver end. I'll look into it tomorrow. |
In your sample code, I noticed that it looks like an important line is commented out: // var video_ = castProxy_.getVideo();
if(video_.paused){
video_.play();
}else{
video_.pause();
} If |
It's just to let you know what that variable is in my code. In the actual code that line's not commented. |
Ah, okay. Thanks for the clarification. |
Reproduced. From initial testing, it looks like the sender is indeed not receiving any more update messages, which means it is probably a problem with the receiver and not the sender. An uncaught error, perhaps, while it is composing the update message? |
The problem is not caused by Widevine. I tested it with a different dash stream, using widevine and it worked as expected. There could be something going on with those demo streams... |
getVariantTracks and getTextTracks both check values on player.playhead_, but don't check if the playhead exists beforehand. This leads to problems when casting an encrypted asset; the cast status update will check getVariantTracks and getTextTracks before the playhead exists, and the error will make the status updates stop coming. Issue #1128 Change-Id: If38e586b1ea3006c01d3556216f5333d9eaf6e17
The bug was in Player and triggered only on the receiver side. We have fixed this in the |
Fix cherry-picked for v2.2.7. |
getVariantTracks and getTextTracks both check values on player.playhead_, but don't check if the playhead exists beforehand. This leads to problems when casting an encrypted asset; the cast status update will check getVariantTracks and getTextTracks before the playhead exists, and the error will make the status updates stop coming. Issue #1128 Change-Id: If38e586b1ea3006c01d3556216f5333d9eaf6e17
The receiver URL has been updated. I don't know how long it takes for that to propagate to Chromecast devices. My guess is that you should be able to verify the fix in a few hours. Thanks! |
Ok, that commit didn't fully fix the issue. |
You naughty build bot, I'm not done with this issue yet. |
When calling getStats, if there is no active stream but there is a playhead and manifest, the player experiences a null exception. This does not fully fix #1128, however, as there seems to be more than a null exception at work there at the moment. Issue #1128 Change-Id: Ic9d318a037157c2a8e28a54a857ec3a1e5797aae
getManifest() hugely increased the message size when casting, to the point where we were having message size problems. This CL stops that property from being proxied. This also adds an integration test that makes sure update messages do not get too large. Closes #1128 Change-Id: I3c4bfabb4d35ee870a603c38f784cb226366a28b
All fixes for this have been cherry-picked for v2.2.9. |
Have you read the FAQ and checked for duplicate issues: Yes
What version of Shaka Player are you using: 2.2.6 - compiled
Can you reproduce the issue with our latest release version: Yes
Can you reproduce the issue with the latest code from
master
: YesAre you using the demo app or your own custom app: Custom based on demo app.
If custom app, can you reproduce the issue using our demo app: Yes.
What browser and OS are you using: Ubuntu 16.04 - Chrome 62.0.3202.94 (Official Build) (64-bit)
What are the manifest and license server URIs: shakaAssets used in demo.
(you can send the URIs to [email protected] instead, but please use GitHub and the template for the rest)
What did you do?
Casted contents being reproduced on shaka player. Contents tested where all shakaAssets.
Pressed play/pause several times to check if I could still control the stream being casted from the player's UI.
What did you expect to happen?
Being able to control the stream being casted, using shaka-player's UI. Be able to load different streams while casting, play and pause content, change volume, move forward and backwards in the timeline.
My ultimate goal is to fully control the cast from the player as if it was a remote control. Ideally delivering a TV like experience, robust and reliable.
What actually happened?
When testing with Angel One (Multicodec, Multilingual) everything works as expected except for a few quirks. Sometimes while content casted is being played, player UI states is paused and the other way around. Clicking play/pause doesn't always work, but generally speaking it works fine, although I wouldn't say it's very robust. When I repeat the test with any widevine asset, play / pause doesn't work at all. Moving forward and backwards in the timeline works sometimes.
I was able to reproduce this behavior with your demo app too: https://shaka-player-demo.appspot.com/demo/
In my implementation, I tracked the problem down to:
While casting widevine assets,
video_.paused
always returns true.I tested forcing play() and pause() methods while casting widevine and they do work.
If not casting, everything works as expected.
The text was updated successfully, but these errors were encountered: