shaka-player icon indicating copy to clipboard operation
shaka-player copied to clipboard

Playback issue on LG webOS 4 with DRMed content

Open massicottem opened this issue 1 year ago • 7 comments

Have you read the FAQ and checked for duplicate open issues?

Yes, there are duplicate issues, but they are closed and unresolved. Related issues: #3707, #4305, and #6321

If the problem is related to FairPlay, have you read the tutorial?

N/A

What version of Shaka Player are you using?

Tested on 4.10.0, 4.12.8 (currently used in prod) and 4.14.5

Can you reproduce the issue with our latest release version?

Yes

Can you reproduce the issue with the latest code from main?

Yes

Are you using the demo app or your own custom app?

Our own custom app.

If custom app, can you reproduce the issue using our demo app?

Yes

What browser and OS are you using?

LG webOS 4 / Chromium 53

For embedded devices (smart TVs, etc.), what model and firmware version are you using?

LG OLED65B9PUA, OS version : 05.40.61. Reproductible on multiple other 2018-2019 webOS 4 TVs.

What are the manifest and license server URIs?

We'll send the URI privately if needed. The issue is reproductible with Sintel.

What configuration are you using? What is the output of player.getNonDefaultConfiguration()?

{
    "drm": {
        "servers": {
            "com.widevine.alpha": "",
            "com.microsoft.playready": "",
            "com.apple.fps.1_0": ""
        }
    },
    "streaming": {
        "retryParameters": {
            "maxAttempts": 5
        }
    },
    "abr": {
        "useNetworkInformation": false,
        "defaultBandwidthEstimate": 900000,
        "minTimeToSwitch": 3
    }
}

What did you do?

Started a VOD or live playback.

What did you expect to happen?

The content plays without any interruptions or issues.

What actually happened?

With Widevine DRM: The content frequently stalls. This occurs by itself after a few minutes but can also be triggered by interacting with the UI, which consumes some of the processing resources.

For live playback, the content eventually falls outside the live window, causing an infinite loop:

  • The player seeks back into the live window.
  • Buffering.
  • Falling out of the live window again due to the stream taking too long to load on slower devices.
  • Repeating the loop.

With PlayReady:

  • VOD: The content plays flawlessly!
  • Live: The content never start...

More details

We've been dealing with a persistent issue in production where users with older LG TVs (2018-2019 models) report constant video buffering when using the app. Here's a breakdown of the investigations and findings so far:

  1. Initial Hypothesis:
    We initially suspected a performance issue with the 1080p 60fps low-latency live stream. As a mitigation, we locked targeted devices to 720p 30fps. While this slightly improved the situation, it did not resolve the problem.

  2. Further Investigations:

    • We reproduced the stuttering issue even at 360p, regardless of whether it was a live stream or VOD.
    • Upon further research, we found related issues (linked above) indicating others are experiencing similar problems on webOS 4. We tried the suggested fixes, such as disabling the stall detector and gap jumping, but these did not help.
  3. Key Findings:

    • The video element consistently fires waiting events, even with 10 seconds of buffered content available.
    • Testing with non-DRM content (e.g., Sintel) worked flawlessly, even in 4K.
    • Testing Sintel with Widevine DRM enabled reproduced the issue, indicating the stuttering might be DRM-related.
    • Switching to PlayReady DRM resolved the issue for VOD playback, but live streaming with PlayReady fails to start. Logs show the license server response is received, but the key status never becomes usable.

live-not-woking.log vod-working.log

  • The same code works without issue on webOS 22+ (we don't have a webOS 5 or 6 to test on) TVs either with Widevine or PlayReady.

Additional Context

We are reaching out to get your input on whether you think these issues are fixable. Before communicating to our client that this can't be resolved on our end, we would like your expertise to determine whether there's a workaround or a deeper issue we might have missed.

Thank you for your assistance.

Are you planning to send a PR to fix it?

If we find the issue, if it's fixable and if we have enough time to do it, maybe.

massicottem avatar Apr 01 '25 20:04 massicottem

Hey @massicottem! Are you able to compare results with other open source players? I've seen similar issues, but mostly on webOS 3, where the workaround was to lower the maximum resolution to less than 720p. If playback works properly on PlayReady, I'm afraid this is some specific device issue. Have you tried reaching to LG?

tykus160 avatar Apr 07 '25 07:04 tykus160

Hey @tykus160 thanks for your answer!

Are you able to compare results with other open source players?

Unfortunately, we haven't been able to get our streams to work in any other web player besides Shaka... 😅 We have tested Dash.js, Video.js (which relies on Dash.js for DASH playback), and Bitmovin, but they all encounter errors, either with Widevine or PlayReady. However, the streams do work in ExoPlayer and AVPlayer. We'll need to follow up with our client's video hosting team to investigate further.

I've seen similar issues, but mostly on webOS 3, where the workaround was to lower the maximum resolution to less than 720p.

We're aware of that workaround and have we tried it, but as mentioned earlier, the issue persists even at 360p in our case... 😕 Additionally, going below 720p isn't a viable option for our client.

If playback works properly on PlayReady, I'm afraid this is some specific device issue.

I suspect the same. If we can get our live streams to work with PlayReady, that might be a possible solution. That said, the fact that it fails on other players as well isn't very encouraging... 😅

Have you tried reaching to LG?

I haven’t reached out directly, but I’ve come across some threads on their forum about this issue. Unfortunately, most are either unanswered or state that it's not their problem since they don’t officially support DASH and that we are relying on third-party players. Even if we manage to highlight a bug on their end, I’m doubtful they’d address it, considering these devices are 6–7 years old... 😅

Here are some relevant threads on LG’s forum: https://forum.webostv.developer.lge.com/t/stuttering-dash-drm-livestreaming-video-on-webos-3-x/6847 https://forum.webostv.developer.lge.com/t/poor-mse-performance-on-webos-4/7852 https://forum.webostv.developer.lge.com/t/the-garbage-collector-runs-every-5-seconds-after-mediasource-is-attached-to-htmlvideoelement/2964 https://forum.webostv.developer.lge.com/t/stall-occurs-in-webos-4-1/18490

massicottem avatar Apr 07 '25 17:04 massicottem

@chornos13, @steve-taylor Were you able to resolve your issue in the end? After rereading your thread with taking our new information at hand, we strongly believe that the issue come from how webOS 3-4 handles Widevine DRM as we can reproduce the issue with multiple player, multiple content types and multiple content providers (including large US ones).

@tykus160

Are you able to compare results with other open source players?

In addition to my previous answers, here's some information from #6321:

By the way, we have investigated the issue further by experimenting with another player (videojs), but it still stutters. we also found that the stuttering disappears when we remove the DRM on the video with the same content and specification (codec).

I'm seeing this on Shaka Player on webOS 4.x. We're actually doing a Shaka POC at the moment and one of the reasons is because we have this exact same issue, but with dash.js.

So it seems that dash.js and video.js have the same behaviour.

I've seen similar issues, but mostly on webOS 3, where the workaround was to lower the maximum resolution to less than 720p.

Also, just like for us, reducing the quality doesn't help...

This issue also occurred even with lower quality (240p)

I'll contact LG now that we have more proof that the issue is not coming from the player. I'll keep the issue opened to keep you updated. My TV received an update last week, so hopefully they will make an update to fix this.🤞 In the meantime, as using PlayReady seems to fix the issue, we would still like to have some help to understand why it's working with VOD but not using live stream please... Let's hope it's not webOS issue as well. 😅

massicottem avatar Apr 10 '25 19:04 massicottem

Here's the LG webOS forum thread: https://forum.webostv.developer.lge.com/t/playback-issues-on-webos-4-with-widevine-drm-protected-content/25043

massicottem avatar Apr 15 '25 12:04 massicottem

@massicottem do you have any update?

avelad avatar May 09 '25 20:05 avelad

@avelad We are currently delayed by some administrative processes with our client, which are preventing us from sending the email requested by LG. I will follow up with them today to see if we can send it now. I'll keep you updated :)

massicottem avatar May 12 '25 12:05 massicottem

The email has been sent, we are waiting to hear back.

massicottem avatar May 22 '25 17:05 massicottem

@massicottem do you have any update?

avelad avatar Jun 23 '25 14:06 avelad

Hey! Sorry for the delay... 😅 We got an answer from LG: it's a known issue on their side which is caused by performance limitation on these old devices, and they have no plan to make an update to fix it. Apparently, several apps are using Widevine on these devices without any issue. Their advices are to either to optimize the app/player performance, to reduce the video resolution or/and frame rate or to use PlayReady.

On our side, we'll try to improve the general app performance to free more memory and CPU for the player, but I doubt that it will help much since we were able to reproduce with the Shaka demo app. Reducing the video resolution/frame rate seems to help a little bit, but it does not completely fix the issue. And using PlayReady is not a solution for our client.

We wanted to challenge the LG team with the fact that the CPU and memory does not seam overloaded when the stuttering happens, but we had other priorities since. I'll keep you updated with the CPU and memory usage comparison and with their answer to that.

massicottem avatar Jul 02 '25 17:07 massicottem

Closing due to inactivity. If this is still an issue for you or if you have further questions, the OP can ask shaka-bot to reopen it by including @shaka-bot reopen in a comment.

shaka-bot avatar Aug 04 '25 12:08 shaka-bot