Issue with DRM playback on Tizen 3 (2017)

[stuartflanagan]

I am trying to get a video to playback on a test tizen 3 TV.

I have tested the Sintel Widevine protected video on your site loading into Tizen3 as a custom URL and it plays back without issue.

I am including the HTML I am using to test on the Tizen3 and wondering if you might be able to help work out why it is not playing.
I will email through a copy of the file with the Authkey included.

FYI: If I tinker via the console and set currentTime a few seconds into the video and pause play a couple of times it actually starts playing without issue.

Any help greatly appreciated.

Kind regards,

Stuart

[stuartflanagan]

I see this in the logs:

buffering shaka.util.FakeEvent
streaming_engine.js:1586 (video:5) looking up segment: presentationTime=6 currentPeriod.startTime=0
playhead.js:501 Stall detected at 2 for 1.0439999103546143 seconds. Seeking forward 0.1 seconds.
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=2.1
playhead.js:501 Stall detected at 2.1 for 1.0529999732971191 seconds. Seeking forward 0.1 seconds.
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=2.2
playhead.js:501 Stall detected at 2.2 for 1.000999927520752 seconds. Seeking forward 0.1 seconds.
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=2.3
playhead.js:501 Stall detected at 2.3 for 1.003000020980835 seconds. Seeking forward 0.1 seconds.
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=2.4
playhead.js:501 Stall detected at 2.4 for 1.003000020980835 seconds. Seeking forward 0.1 seconds.
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=2.5
playhead.js:501 Stall detected at 2.5 for 1.000999927520752 seconds. Seeking forward 0.1 seconds.
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=2.6
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=3.6
streaming_engine.js:935 (all): seeked: buffered seek: presentationTime=4.6
simple_abr_manager.js:254 Calling switch_(), bandwidth=16297 kbps

[stuartflanagan]

I have emailed a test file to you.
Kind regards,

Stuart

[predikament]

Hello @stuartflanagan,

From the best of my knowledge the EME version has so far not been updated to support playback of encrypted contents using the Shaka player for Tizen devices older than Tizen 4, i.e. Tizen devices from 2015/2016 do not support this.

Not sure if or when Samsung is intending to update the EME version for these devices, unfortunately.

You can check out https://developer.samsung.com/tv/develop/specifications/media-specifications from time to time to see if there are any updates there I guess.

Best of luck to you 😄

[joeyparrish]

We have a Tizen 3 device in our lab, and we do support Tizen 3, both for clear and encrypted content.

What I'm seeing from the logs you added is that the device is seeking forward by 0.1, which is what happens when we detect a stall. So I don't think this is necessarily related to encryption.

Changing the labels to put this in the bug cop's queue. @TheModMaker, can you take a look?

[chrisfillmore]

2016 model TV's are not the same as 2017 models. 2016 is WebKit-based and implements EME v0.1b. My understanding is protected playback will not work with Shaka out of the box (see #813).

[stuartflanagan]

The example Sintel video on the Shaka demo page Plays without issue. This has Widevine encryption and does require EME to play. Just wondering if there is an issue in our manifest. After many minutes waiting the videos do start playing occasionally.

[TheModMaker]

Could you send us another auth token or update the one you sent us; I am getting a 403 from the license server saying it has expired.

If I run the asset in Chrome, from chrome://media-internals I get logs saying ISO-BMFF container metadata for video frame indicates that the frame is not a keyframe, but the video frame contents indicate the opposite. What may be happening is the first few seconds have invalid keyframe signaling and Tizen is getting confused.

You could also try changing the streaming.stallEnabled configuration to false. That disables the stall detection and may allow the asset to play. We've seen Chromecast take a while to start after a seek, so it may be that your TV is just taking a while to start playing and we interpret that as a stall.

[riksagar]

We had to make a couple of changes to the 01b calls to make it work on Tizen. Those would have been for 2016 TV.

The changes are in our dash-js fork, you can take a look at those and see if they'd help:

• vuduDASH/dash.js@98df85a

[stuartflanagan]

Hi @TheModMaker I did email the shaka email address with a set up file including authkey

I might need to reset the authkey.

Is this the right address to use?
shaka-player-issues@google.com shaka-player-issues@google.com

[stuartflanagan]

thank you @riksagar ! I will give that a go.

Kind regards,

Stuart

[stuartflanagan]

@TheModMaker & @joeyparrish ,
I have updated the authkey in the link I sent via email.
please download again from the dropbox link.

Let me know if you have any issues accessing the file.

Thanks again for looking at this.

Kind regards,

Stuart

[TheModMaker]

The asset plays fine if I start playing at 2 seconds. With 2 second segments, my guess is that something about your content causes the TV to ignore the first segment or rejects it. Maybe the warning I mentioned above is causing the TV to drop the first segment due to lack of keyframes.

[stuartflanagan]

Thank you @TheModMaker. Can you let me know how you set playback to be 2 second segments?
I am aware of how to start at 2 seconds.

Are you suggesting there is an issue with the manifest or the transcoding? Is there a way to determine what in the manifest is causing the stall?

This is happening with pretty much all of our content at present.

Thank you for your help.

Kind regards,

Stuart

[stuartflanagan]

Hi @TheModMaker Just wondering if you might have any extra advice I can pass on to our encoding team.

They have stated the first keyframe is an i frame.

Let me know if you need any further information.

Kind regards,

Stuart

[stuartflanagan]

Hi @TheModMaker and @joeyparrish Just wondering if you might be able to assist any more with this?

The transcoding team seem to think everything is fine but I actually cannot get content to play at all now whether we start 2 seconds in or not.

I can set up another example when you are ready?

Kind regards,

Stuart

[stuartflanagan]

In my current build I am getting these reported by Shaka:

(video:6) failed fetch and append: code=3015
(audio:1) failed fetch and append: code=3015

[mishazawa]

@stuartflanagan Take a look to #1839.
According to messages from @kevinscroggins-youi, he had similar bug on Tizen platform and fix it by pause-play on stall events.

I have same issue on Tizen (UE40MU6100U) and I fix it like this:

shakaInstance.playhead_.gapController_.stallDetector_.onStall_ = () => {
  video.pause();
  video.play();
}

On another Tizen (f.e. QE55Q80R) or WebOS this bug don't reproduce.

It would be nice if shaka.media.StallDetector will provide API for custom behavior on stall events.

[stuartflanagan]

This did not work sorry. @mishazawa

[joeyparrish]

I believe this may have been fixed in recent v2.5 and v3.0 releases. Can someone please try to reproduce the issue on v2.5.15 or v3.0.3? Thanks!

[mishazawa]

@joeyparrish currently I use v3.0.3 on Tizen 2017(and newer) platforms and issue was gone. Message "Pausing and unpausing to break stall." appears sometimes, but playback is OK.

[joeyparrish]

That's wonderful news. Thank you! I'm sorry it took so long to find the solution, but I'm glad it's working for you now.

Though this issue predates #2620, I'm going to close this and label it as a duplicate of #2620, since that's where we did the work that solved this issue.