Official support for LG WebOS TV

[kingctan]

Does this player support LG WebOS TV for DASH&playready combination?
Thanks.

[chrisfillmore]

I don't think that Shaka team has investigated this platform specifically. Generally speaking, Shaka supports any platform that is spec-compliant, but in my experience these kinds of smart TV platforms are not very mature and require extensive testing, validation, and workarounds. Things are getting better, though.

We will soon be investigating LG WebOS for DASH-PR, so you may soon see tickets related to this platform, and you'll get a better sense for whether or not Shaka will work on these TV's.

[joeyparrish]

We have never tested Shaka Player on this platform, but you can help by running our support page and sending a screenshot: https://shaka-player-demo.appspot.com/support.html

This will tell us whether or not the platform has the basic capabilities we need, and if so, what specific containers, codecs, and DRM systems it has.

[avelad]

We are using ShakaPlayer with WebOS 3.5 and DASH+Widevine without any problem.

[ismena]

@kingctan Does this answer your question? Is there anything else we can do?

[chrisfillmore]

@ismena I have a question. It seems there are at least 3 projects using Shaka on LG WebOS: @kingctan, @avelad, and me. Would Shaka team be willing to adopt this as an officially supported platform?

[avelad]

@chrisfillmore , What versions of WebOS have you tried? I only tried WebOS 3.5.

[ismena]

Let's get our TL to consider it!
@joeyparrish

[shaka-bot]

@kingctan Does this answer all your questions? Can we close the issue?

[joeyparrish]

If you can send us some documentation on WebOS testing, we could consider adding a WebOS device to our test lab. We can't call it an officially supported platform until we are running tests on it nightly to make sure we don't break it. But in general, expanding our platform coverage is a Good Thing:tm:.

In particular, we would appreciate any tips on how to automate directing the device to an arbitrary URL. That's a key part of the testing process with Karma.

[shaka-bot]

@kingctan Does this answer all your questions? Can we close the issue?

[shaka-bot]

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

[chrisfillmore]

@shaka-bot reopen please

Here is the Shaka support page for the WebOS TV I have:

Mozilla/5.0 (Web0S; Linux/SmartTV) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/38.0.2125.122 Safari/537.36 WebAppManager
v2.3.6

{
  "manifest": {
    "application/dash+xml": true,
    "application/x-mpegurl": true,
    "application/vnd.apple.mpegurl": true,
    "application/x-offline-manifest": true,
    "mpd": true,
    "m3u8": true,
    "application/vnd.ms-sstr+xml": false,
    "ism": false
  },
  "media": {
    "video/mp4; codecs=\"avc1.42E01E\"": true,
    "video/mp4": true,
    "video/mp4; codecs=\"avc3.42E01E\"": true,
    "video/mp4; codecs=\"hev1.1.6.L93.90\"": true,
    "video/mp4; codecs=\"hvc1.1.6.L93.90\"": true,
    "video/mp4; codecs=\"hev1.2.4.L153.B0\"; eotf=\"smpte2084\"": true,
    "video/mp4; codecs=\"hvc1.2.4.L153.B0\"; eotf=\"smpte2084\"": true,
    "video/mp4; codecs=\"vp9\"": false,
    "video/mp4; codecs=\"vp09.00.10.08\"": false,
    "audio/mp4; codecs=\"mp4a.40.2\"": true,
    "audio/mp4": true,
    "audio/mp4; codecs=\"ac-3\"": true,
    "audio/mp4; codecs=\"ec-3\"": true,
    "audio/mp4; codecs=\"opus\"": false,
    "audio/mp4; codecs=\"flac\"": false,
    "video/webm; codecs=\"vp8\"": true,
    "video/webm": true,
    "video/webm; codecs=\"vp9\"": true,
    "video/webm; codecs=\"av1\"": false,
    "audio/webm; codecs=\"vorbis\"": false,
    "audio/webm": false,
    "audio/webm; codecs=\"opus\"": false,
    "video/mp2t; codecs=\"avc1.42E01E\"": false,
    "video/mp2t": false,
    "video/mp2t; codecs=\"avc3.42E01E\"": false,
    "video/mp2t; codecs=\"hvc1.1.6.L93.90\"": false,
    "video/mp2t; codecs=\"mp4a.40.2\"": false,
    "video/mp2t; codecs=\"ac-3\"": false,
    "video/mp2t; codecs=\"ec-3\"": false,
    "text/vtt": true,
    "application/mp4; codecs=\"wvtt\"": true,
    "application/mp4": true,
    "application/ttml+xml": true,
    "application/mp4; codecs=\"stpp\"": true
  },
  "drm": {
    "org.w3.clearkey": {
      "persistentState": false
    },
    "com.widevine.alpha": {
      "persistentState": false
    },
    "com.microsoft.playready": {
      "persistentState": false
    },
    "com.apple.fps.2_0": null,
    "com.apple.fps.1_0": null,
    "com.apple.fps": null,
    "com.adobe.primetime": null
  },
  "offline": true
}

The TV is a UJ6500. In "About This TV" it says Software Version 4.70.10, although I'm not totally clear if this is the WebOS version.

[chrisfillmore]

Could we reopen this as an official WebOS support issue? I have an internal ticket assigned to me to ensure Shaka works out of the box on LG TV's, so I'm happy to help get this resolved.

[joeyparrish]

Sure thing. I've renamed the issue to reflect that.

@chrisfillmore, based on your support report, I see no reason WebOS shouldn't work. If you can confirm what version of WebOS you have, that would be helpful. @avelad reports that WebOS 3.5 works for him.

For this to be an officially supported platform, and not just a platform that happens to work, we will need to add a WebOS device to our lab environment and integrate it with our test automation. None of that work will affect the open-source library unless we need to adjust any of the tests themselves.

The open question is what version of WebOS we should try to put in our lab. Ideally, we would test on the oldest version we intend to support, which may be 3.5. @chrisfillmore, @avelad, we would be happy to have your input on this.

The other issue is that we may be limited in the WebOS version we can actually purchase. For example, when we tried to purchase a Tizen 2016 TV, we could only find 2017 models in stores. It seems that WebOS 3.5 models are still available, but I'm not sure about earlier models.

[avelad]

I'd prefer that Shaka Player supports WebOS 3.5 or above (WebOS 4 is scheduled for the end of year).

The only "strange" thing that i found in some WebOS TV is related to video resolution, eg:
Model: lg-24MT49S-PZ (this is a low end model) with HD ready resolution (1366x768px) is not able to reproduce streams of 1080p, so I need configure setMaxHardwareResolution with 1366x768

[joeyparrish]

Cool, thanks for the feedback, @avelad!

[chrisfillmore]

Ok here's what I've learned so far.

WebOS SDK
http://webostv.developer.lge.com/sdk/download/download-sdk/

Using WebOS CLI
http://webostv.developer.lge.com/sdk/using-webos-tv-cli/

Testing a WebOS app
http://webostv.developer.lge.com/sdk/using-webos-tv-cli/testing-web-app-cli/

WebOS Application Lifecycle
http://webostv.developer.lge.com/develop/app-developer-guide/web-app-lifecycle/

You can launch an app from the command line via something similar to:

ares-launch --device deviceName com.domain.app --params "{'url':'www.foo.com'}"

You can listen for this value in WebOS:

document.addEventListener('webOSLaunch', function (event) {
  console.log(event.detail.url); // www.foo.com
});

Does this help?

[asgvard]

Hi,
Just wanted to report some issue as well, as from what I understood this is the best place to do it.
We have been using Shaka 2.5.17 on WebOS down to 3.5 (TVs from 2016 year) and everything worked fine with Dash + Widevine. However after upgrading to Shaka 3.0.0+ it stopped working. The error we get is:

Failed to execute 'webkitAddKey' on 'HTMLMediaElement': The key system provided ('com.widevine.alpha') is not supported.

And I'm sure Widevine is supported there, it was already working before.
I have tried to find what has changed between 2.5.17 and 3.0.0 and it seems like the changes in the file /polyfills/patchedmediakeys_webkit.js are causing this, but I'm still in the process of finding out which exact change broke this. This whole polyfill was changed quite a lot between those 2 versions as it was migrated to ES6 class, so it makes it a bit hard to find the exact logic changes. If anyone has similar issues and did find a solution, or if anyone has an idea which changes in that file could have break this, please let me know :)

[joeyparrish]

@asgvard, please let us now what you find out about that. We would be very happy to review a PR, but we don't have an LG TV of our own at this time.

[asgvard]

@joeyparrish Thank you for your reply!
We have done some investigation, however, it is a bit difficult to trace back all the changes in the initialization flow. I have compared 2 versions side by side and tried to output additional logs (from Shaka library as well as my own ones) to see which steps are different to find a clue about what could be an issue. The differences start from the player.js where it calls initForPlayback method.
In the 2.5.x version it goes into filterAllPeriods, then the next thing that is happening is onLoad_ callback where it first sets Media Keys, and only then creates the Media Key Session. I can also see that in 2.5.x version the session contains one key that has "usable" status.
In the 3.0.x version it goes into the filterManifest_ method where it already tries to create Media Key Session before the keys were set with setMediaKeys. I've also noticed that the keyStatuses has 0 size in this case. Then it tries to call generateRequest which after few "Ignoring duplicate init data" calls causing the player Error with the message that "com.widevine.alpha" is not supported (this error will be visible on the 2nd screenshot).
Here is the first comparison screenshot of the logs side by side: (left is 2.5.x, right is 3.0.x)

Interesting thing though is that in the 3.0.x player goes into Error state (or at least we interpret it as an Error state since we get it in the onerror callback from the player) while on the 2.5.x version we also get this error, but inside onWebkitKeyMessage_. Somehow on 2.5.x after few messages like this it actually reports that the MediaKeySession is ready and it starts the streaming. SO these errors are kind of ignored and hidden only inside WebkitKeyMessages.

Unfortunately it requires much deeper knowledge of the Shaka player architecture for us in order to understand where the problem originates, so I would appreciate it if you could have a look at these logs and share your thoughts (theoretically) about what do you think can cause such a different behavior?
For now the main 2 differences that we see is that working version has "usable" keys in the Key Session while non-working version doesn't have the key. And the second difference is that the "com.widevine.alpha" error is not impacting the playback in the 2.5.x version, but it is causing player to report an error in 3.0.x version.

Thank you in advance for any suggestions or guidance on where should we continue our investigation!

[kasmihmed]

I wouldn't mind helping

at

i have an lg tv and I wouldn't mind helping out.

[avelad]

Update from @joeyparrish : #3345 (comment)

[joeyparrish]

These are the steps that must be done to add LG as an officially-supported platform:

1. Build an LG TV backend in Generic WebDriver Server (Add support for LG WebOS generic-webdriver-server#18) so that we can automate tests and debug on the platform (can be done by anyone with the hardware and time and energy)
2. Set up the LG TV test infrastructure in our lab (must be done by the Shaka team)
3. Run all Shaka Player tests on LG TV and catalog test failures (can be done by anyone after part 1 is complete)
4. Fix individual test failures, either by updating test cases or fixing Shaka bugs or working around platform bugs, as appropriate (can be done by anyone or many people in parallel after part 2 is complete)
5. Enable nightly testing in the Shaka Player lab (must be done by the Shaka team)
6. Update docs (can be done by anyone)

These are the same steps we went through this year to add official Xbox One support (step 1 PR, step 4 changes 1, 2, 3, and step 6 docs updates). If anyone is interested in helping us expand official support to LG WebOS, please feel free to volunteer!

[gperulliniroque]

Estamos usando ShakaPlayer con WebOS 3.5 y DASH+Widevine sin ningún problema.

Hola buenas noches estimado, podrias ayudarme con la configuracion del player. @avelad

[FelipeAndresLopez]

Estamos usando ShakaPlayer con WebOS 3.5 y DASH+Widevine sin ningún problema.

Hola buenas noches estimado, podrias ayudarme con la configuracion del player. @avelad

@avelad It would be great if you can help us with that configuration that you set, I will appreciate it.

[avelad]

Another WebOS topic: #5479

[stuartflanagan]

@avelad Wanted to let you know the latest update 4.8.0 introduces error code 4032 when playing AES HLS on webOS.
4.7.x did not have this issue but did have the issue with over requesting AES license.
Is there a way around this issue?

[avelad]

@stuartflanagan In 4.8.0 there are the following related changes:

• feat(HLS): Add AES-256 and AES-256-CTR support #6002
• fix(HLS): Avoid duplicate AES request when using the same info #6118
• fix(HLS): Avoid duplicate AES requests #6399
• fix(HLS): Fix bad warning when playing HLS-AES128 #6434
• And: fix: Reject TS content on all platforms and transmux always #6382

Anyway to fix any bug we need a test stream.

Please note that this is an unofficially supported platform, so if you want to submit a PR to fix this, we'd be happy to review it.

[stuartflanagan]

Thanks @avelad.
The issue actually occurs with any HLS stream. not just AES encrypted.
But here is a demo stream from unified that also triggers the 4032 error.
https://demo.unified-streaming.com/k8s/features/stable/video/tears-of-steel/tears-of-steel-aes.ism/.m3u8

The error occurs in thePlayer load sequence. Has there been any change to the isSupported method used?
It seems it is now returning false for webOS this is webOS3 through webOS2024

Happy to have a look at this. Can you please point me to any commits that may have impacted isSupported method?

    this.player
      .load(mediaItem.manifest, startTime)
      .then(() => {
        handlePlayerReady();
      })
      .catch(error => {
        this.error = error;
        this.dispatchEvent(new Event('error'));
      }); 

[avelad]

Are you using fMP4 or TS?

[stuartflanagan]

TS

[avelad]

The commit that may impact is: #6382

[stuartflanagan]

Thank you I will see how I go.

[stuartflanagan]

Seems to be affecting MPEGDASH and DRM as well.
Same error 4032.

[stuartflanagan]

Hi @avelad just wondering if I can get some help contributing for this issue.

I realise this ticket is probably not the place to do it as it is regarding offical support.

At present I have the shaka-player lib forked and it is building.

webOS is returning 4032 for manifest media types
HLS: https://demo.unified-streaming.com/k8s/features/stable/usp-s3-storage/tears-of-steel/tears-of-steel.ism/.m3u8
MPD: https://storage.googleapis.com/shaka-demo-assets/angel-one/dash.mpd

The interesting thing is when I switch to the debug player to investigate the logs playback is fine with no 4032 error code.

[rampratapyadav91]

minimumUpdatePeriod is 30 for live content which is causing delayed playback start if I am keeping rebufferinggoal as 30 and if set ignoreminbuffertime true then seeing a stall during playback, how to configure shaka for lower webos so that there is not any delayed playback start as well as any stall ?