Controlling cast stream reproduction fails when using widevine.

[sergioavazquez]

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: Yes

Are 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 shaka-player-issues@google.com 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:

// var video_ = castProxy_.getVideo();
    if(video_.paused){
      video_.play();
    }else{
      video_.pause();
    }

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.

[theodab]

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.

[joeyparrish]

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 video_ isn't the proxied video, is it the local video element?

[sergioavazquez]

It's just to let you know what that variable is in my code. In the actual code that line's not commented.

[joeyparrish]

Ah, okay. Thanks for the clarification.

[theodab]

Reproduced.
I'm seeing it happen on Angel One (multicodec, multilingual, Widevine), and on Angel One (multicodec, multilingual, Clearkey server), but not with any of the other assets I tried. This means that it isn't Widevine-specific, but also doesn't happen on all encrypted content. Perhaps it has something to do with the particular feature set of the Angel One asset. Notably it doesn't happen with the encrypted HLS Angel One, so it might have to do with the DASH parser.

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?

[sergioavazquez]

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...

[joeyparrish]

The bug was in Player and triggered only on the receiver side. We have fixed this in the master branch, and the fix will be released in v2.2.7. We will close this issue as soon as the receiver has been updated as part of the v2.2.7 push.

[joeyparrish]

Fix cherry-picked for v2.2.7.

[joeyparrish]

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!

[theodab]

Ok, that commit didn't fully fix the issue.
To be specific, it looks like when we updated the receiver it exposed a new, different null exception that is causing the cast receiver to not send out messages.
I'll prepare a fix for 2.2.8.

[theodab]

You naughty build bot, I'm not done with this issue yet.

[joeyparrish]

All fixes for this have been cherry-picked for v2.2.9.