Pieter-Jan: I see we're at 5 past the hour, so I propose we get started.

Hello, everybody. Welcome, I would say! Today is going to be a very interesting topic. We're going to be talking about WebOS. As with all of our webinars, after the actual presentation, there will be a Q&A session, you can already start asking your questions - just use the chat box in the corner of the screen, and then we will answer the questions once we get to the Q&A. We have two very fun speakers today, one being myself: CTO of THEO Technologies, and next to me, I have, of course, Michel.

Michel: Yes, absolutely. I'm Michel, VP of Engineering at THEO. Happy to participate in the webinar today. Doing in the last months a lot of work on Tizen and WebOS, so pretty exciting to share a bit of our experiences with all of you today. So WebOS: powerful devices capable of doing 8K, 4K, even with the 2016 models already. Also, a platform that is continuously evolving, you see lots of minor version updates, you also see regular innovations on the platform. Pretty easy, accessible platform also, just like Tizen, it's a web platform. So, making it not that big of a hurdle to get your app there. And if you know what you're doing, even on these older TVs - 2016, you're able to build a killer OTT experience like Netflix.

What will we discuss today? Maybe a brief overview. We'll zoom into LG's WebOS position on the market, some insights on the different versions, models, hardware differences, the common features you need in an OTT use case, how you develop on WebOS, so how you bring your application there, but also what are your options to do media playback. Then we'll zoom into a bit of our story on WebOS, so we'll elaborate on some of the more common challenges you can face with the platform. Also zoom into the playback and content protection quirks we've seen. Very relevant for a big part of the OTT apps, monetization also brings some challenges on the platform. And we're also happy to elaborate a bit on the approach we took at THEO to support smart TVs.

Pieter-Jan: Let's maybe start first with zooming into webOS's position in the market. Once known as Open webOS, HP webOS or even Palm webOS, a Linux based operating system for smart devices such as smart TVs. Since 2014, most of the patents are owned by Qualcomm and LG licenses it for their devices.

If we look at the position in the market, it's the second biggest platform in smart TVs, if you look at viewing time after Samsung with their Tizen platform. I think in a previous webinar, we also used that word, it's a pretty big growth hack for everybody working in OTT, compared to last year, viewing times almost doubled on the smart TV front. So absolutely your platform to go to. Important to also note, we'll zoom into it a bit later, is that webOS is also being licensed to other parties, to third party devices: Sharp, Hisense, Toshiba, Devo, even Sling and much more. So just saying that webOS is not only LG, it's also present on many more TVs. One thing I want to underpin here is an example of River OS as one of the innovations, it's a recent announcement made by LG, which shows the continuous evolution of the webOS platform. So, it's in essence, LG ads, so the advertisement division of LG that will bring their own Smart TV operating system. Our knowledge of it right now is also mostly the public available information, but we are closely following it. And we heavily believe that, of course, webOS will be one of the cornerstones for this new track that LG is going into, more focusing on advertisement, on like you see with other operating systems in idle time or in the different menus.

Michel: Let's maybe zoom a little bit further into the differences, into the versioning, the models and the hardware:

So, I think you all heard about 3.0, 3.5, 4.0, here in the table, you see the different versions. So, what you probably already noticed immediately is that each of the major versions is bound to the release date, so to the manufacturing date. Like some of you who will maybe already see that, that brings the first challenges with it because only the major version updates, they come basically with the manufacturing date of the defence. What I also want to highlight here in the table is - you see that most of the platforms or all of the platforms use Chromium as their web engine. But you see, for example, for the 3.0, 3.5, we're talking about the Chromium 38 that's engineered in 2014, so even though the manufacturing date is 2017, it's engineered in 2014. So that brings some things with it, of course. Also means that if you take an average lifespan of your main screen TV at home is seven years. So that means the 3.5 version TVs are still in your living room until 2024. By then you're talking about 10-year-old technology in other words, so, that's interesting to see. 

Also right now, if you look at the market share - about 36 percent of the market share is still LG WebOS  3.5, 3.0., so, 2016, 2017 models. So still very relevant to keep in mind in your OTT strategy. You also see in the table the different models, that's also something we want to highlight, because for every manufacturing year, basically LG brings out different models: Full HD, UHD, which is 4K or 8K UHD since 2020. We'll come a bit later back to it, but that has some interesting things. Certainly, if you look at the Full HD models that were sold in 2017 and 2016, It's pretty interesting to zoom into, Pieter-Jan.

Pieter-Jan:  Yeah, I think we're actually very lucky because only about, let's say 3% of the 3.0, 3.5 LG versions are actually the Full HD versions. So, it's about, I think 1% of the total webOS population. But there is a very big difference there. When you hear Full HD, you're always thinking: ah, that's great, these devices can play at least 1080i, so traditional broadcast, full HD, very nice. But once you start going into streaming, and once you start looking at how do these kinds of devices perform with 1080p streams, with DRM enabled, because usually it's premium content on these big screen devices, then you do start seeing that the performance of these devices is actually quite limited, especially if you start stretching towards 50 frames per second streams. That's quite demanding, especially for these kinds of old devices. But it is a use case that, of course, we see more and more, given that more publishers want to really offer that premium experience. It's also very clear when you look at the actual services that support these devices. We have a few of them here at the bottom of the slide: there's Netflix, there's Disney+, they don't support these full HD models, simply because that performance isn't good enough. There are ways, luckily, to get around this. We've actually gotten them to work with 50 frames per second with the full shebang, so to say. But definitely, it wasn't easy to do this.

So, let's dive a little bit deeper. And of course, the first question that a lot of people probably have is, how do you get started on webOS? What do you need to do? How do you build these apps?

And actually, well, that’s not that difficult, but let's first see what kind of features do we really need: that's a long list, there's a long list of features that most popular services need - there's, of course, just standard playback, live, video on demand, high quality, as I already mentioned, definitely a thing; HDR, a lot more popular across our customer base these days; Same with multiple audio tracks, Dolby is popping up quite a lot; Subtitles, basically the must-have checkbox for every streaming service; And as I already mentioned, usually there is DRM involved, it's premium content in most of the cases. So, PlayReady and WideVine, that's usually the go-to, especially for the WebOS platform; And Michel already mentioned it as well: server-side ad insertion and client-side ad insertion, they're actually quite important, even for the big services with premium content, we're seeing a lot more demand there.

So that's quite a long and a big shopping list, to be honest. These kinds of things can be challenging even for recent devices. But for embedded devices like LG TVs, it's especially the case. And I already mentioned it - how do you get your app on these platforms? It's webOS. It's in the name web, all of it is basically HTML5. That does make some things easy, it's very similar in this sense also to what Tizen does, of course, if you've seen the Tizen webinar. It is an app store, there's a review process by LG, like we also know from the mobile platforms, you can go for hybrid apps, you can go for packaged apps, you can go for hosted apps. We wrote some blog posts on that, if you're interested, go ahead and read them. But it is quite simple: if you set this up correctly, you can reuse perfectly fine your Tizen app that you've built, or even your web app, your website, if you use the correct polyfills, then getting that experience out to your TV, it won't be that hard.

Pieter-Jan: The tricky thing that comes when you, of course, try to play media. And well, these are big TVs, so you will usually want to play some video on them, and there you bump into a problem - it's the same problem that we had with Tizen. There are two options: you either use whatever is natively available on the platform and you use the native player, or you bring your own and you go for an MSE, EME-based approach. Very interesting, but as we also mentioned during the Tizen webinar, there are quite a lot of limitations that we bump into with the native player: with the native player, it is actually very limited -  officially, there's not even MPEG-DASH support. Unofficially, it actually does work. In my opinion, it works better than the HLS support that's there. But if you go through the documentation, webOS officially does not support MPEG-DASH. That's a quite big problem, I think. Michel already mentioned it, these devices, they're old, they're old tech, there's no such thing as HLS CMAF on these devices, there are actually very limited subtitle capabilities, not that many formats are supported. But also, there's no things that you would expect from modern streaming use cases like metadata, even to use it, for example, for SSAI. SSAI is a very big problem on these devices. Don't even get me started on toggling the DRM on and off, the native player here, it is really not up for the task.

The other option is actually bringing your own player. So going for the MSE EME-based approach. There it does become very interesting. So, you can use your other players like Dash.js, HLS.js, ShakaPlayer, or, of course, THEOplayer version, but the big problem that you will see is that these are very old MSE EME implementations. That's thanks to the fact that these Chromium engines are so old.

But it also brings a lot of quirks. On Dash.js, Shaka Player, playback usually does work. But once you start going into DRM, that's when it becomes a lot trickier. For Dash.js and Shaka Player, DRM actually doesn't really work in all cases. For example, once you start pushing that device, playing something more than 25 frames per second, it becomes tricky, on some models, WideVine actually runs fine with 50 frames per second, but on other models, you have to use PlayReady because otherwise that 50 frames per second is just unachievable. The same actually goes for client-side ad insertion and server-side ad insertion, a lot of the common libraries do not work. They don't officially support these kinds of things. And the experience just becomes, really bad, I mean, we've seen quite a lot of different challenges here.

Michel: Yes, absolutely. I think you see it already a bit in the table here. So, we highlighted earlier the web engine being used, so, you see on a 3.0, 3.5, so 2016, 2017; Chromium 38, it's engineered in 2014, I don't think any of us is looking forward to using the tooling from 2014; but this is what you're encountering when you're building a webOS application where you want to serve all of these different versions, that's something to take into account.

What Pieter-Jan already mentioned -  the big differences in hardware models are striking, even small to big TV makes a difference within the same version when it comes to performance. And it's really knowing, testing the best combinations to make it work. Certainly, when you go into the more higher demanding streams, which are becoming more and more the normal thing in the industry right now, like a 50 FPS stream. Earlier said, you don't get access to the cool new stuff, so, the major versions are bound to the manufacturing year. So, you do get minor security updates etc but no major updates. And although the documentation online is pretty okay, if you're stuck there, who are you going to call so that's the same that we encountered - who are you going to call if you're stuck?

Michel: So, what did we do to to circumvent this? Because we, of course, faced the same challenges. So, our efforts were high, so it took a lot of efforts, it was high demanding, but it also pays off right now. So we approached it by via an in-house developed test automation, but to be honest, more of a tooling framework that removes the dependencies on the platform tools for for debugging and for investigation. Also, might sound very normal, but we also had a pretty long scavenger hunt to get all the TVs, so the different hardware models, but also the different versions into our office. So, we built basically a TV wall, which is pretty impressive, that allows us to quickly validate the same stream across all different devices. But of course, the previous framework with test automation comes into play.

We even went a bit further because we saw that even in some cases getting access to devices that are sold in Eastern Europe, for example, is not that simple here in Leuven, in Belgium, where we are based. So, we couldn't access also all of the different devices. So, we went a step further to even do testing on partners or customers' devices very far away from us, so do the remote validation, just to find what are the combinations that work, what are the quirks of each of these different models.

Michel: When it comes to regular playback and content protection, there are some more of these challenges to take into account. Challenges that make even a very simple use case pretty tricky on webOS. So, we'll go a little bit more technical right now, but one of the things that is interesting the first time you see it is - you try to seek, you go forward in your stream somewhere to the future and all of a sudden you notice: hey, I went back in time. This is because these devices only are able to seek to a keyframe, so, depending on your gob size and where you seek to, you can end up in the past. So, you can on one hand reason - okay, that's a user experience thing etc but it's also for a player pretty tricky - if you have gaps in your stream, you typically try to jump the gaps so do small seeks into the future. But with these kinds of things, if you do that, you start playing over the same part of the stream over and over again. Interesting things.

Never trust a smart TV, also not webOS, certainly not when it comes to Dolby support. So, these devices typically support Dolby, but mostly through an external device like a soundbar. These devices also have an optical out which allows you to have this digital interface, but in 2016, 2017, for example, these interfaces were not an active interface. So, the device can't detect - hey, there is a device connected. So, guess what it does? It just always says I can play Dolby. So, if you then try to play Dolby, it of course fails with all bells and whistles. So not very pleasant!

Widevine, PlayReady, you can do both on this platform, but depending on the version and on the model, it's a better choice to go for Widevine or to go for PlayReady. You really have some parts where it's better to use PlayReady for your high demanding streams. In some cases, it's Widevine. And then it becomes even nicer because if you're using PlayReady, you need a persistent PlayReady license for 3.0, 3.5 and 4.0. So also, something you need to know.

And to add in, on top of that we sometimes have DRM streams in our lab that weren't playing, we couldn't figure out what - it appears to be the TLS version. So, the TLS 1.3, for example, is only supported in very recent versions of webOS, meaning that you can't get your certificate downloaded, for example. So that is some of the interesting quirks around playback and content protection.

Michel: Monetization maybe one of the things we can discuss next. So about 67% of the OTT providers make use of advertisement for their content. So, it's pretty important! If you want to bring it to this platform, you need to have the right user experience. And I think a lot of you will question what is the right user experience? Well, if you look at Conviva reports that were reported earlier, there is stated that five seconds of buffering detract viewers, I think we can speak from own experience that that's the case.  And, 54% of the viewers abandon your stream when ads fail to load or take too long to load. So, challenges with this experience, Pieter-Jan!

Pieter-Jan: Definitely, because it's actually something that we see on these kinds of devices quite often. These devices, they were set up to play one single video at a time, so, if you start using, it's not really supporting webOS, but if you would try, for example, to load Google IMA, client-side ad insertion library - normally, what do those libraries do? They spin up a second video element, they try to load the app there upfront so that when you want to switch or when you want to make the switch that it's preloaded, that it can automatically start. But that kind of things don't work on webOS.

And as a result, it actually gives you horrible experiences. So, what you have is you have your content playing and then you need to switch to an ad - you completely go black screen. You switch, you load your new video in a new source, it has to load for a few seconds, and only then it starts. It's a horrible experience on video on demand, but it's even worse, of course, on live, because, you start building up additional latency. It actually becomes worse even if you try to do it with server-side ad insertion, because there, usually, your ads are in clear, you don't need to protect them. I mean, if people copy them, the advertiser is probably very happy. But for the content, you really want your DRM on there. And webOS doesn't really like it when it has to start reinitializing decoders, setting up that secure pipeline. It doesn't go seamlessly out of the box. And as a result, what will happen there? It will be a horrible experience: there will be a three, four, five seconds waiting time. And well, as Michel already mentioned, that will not go down well with most viewers.

So what did we actually do? Because of course, we faced all of these things as well when we started all of this off. Well, we actually built our own ad system as well for client-side ad insertion. We actually expanded it specifically for webOS, but also for Tizen and for a number of other platforms to do preloading in a different way - so that we can actually start up those client-side ads immediately. It is a world of difference compared to what you see with all kinds of other libraries. So, if you want to do client-side ad insertion on these platforms, make sure that you go outside of what the normal approach is. You really have to optimize for these things. The same actually for server-side ad insertion - we actually built in our player special, well, let's say a trickery, but we make sure that we can very swiftly upgrade that decoding pipeline. Why? Well, it's server-side ad insertion, you want that broadcast experience, you want the last frame of your content, and you want the first frame of the ad to be exactly after it, you don't want any blackouts. And the real tricky thing is all of the testing. We already mentioned it a few times: there are a lot of different devices here, there's a lot of differences between the models. And well, testing really is the key, if you ask me.

Michel: It's absolutely the key. I think we were building up this story already a bit in the narrative in the previous slides.

Michel: So, what approach did we take? We took a black box approach. So, we really treated the TVs like: Who are you going to call? You can take it literally, you can't find all of this different information, you can't find it out there. So, you really need to dive into it, you need to go hands on.

So, we treat it like box: we isolate the TV completely. So, we make sure we build tooling in-house fully for the debugging, for changing configurations, changing content and doing automated testing. To elaborate a little bit on that: so, we made tooling that we can create our own streams where we control the encoding completely. And even the DRM both for VOD and for live that we're able to generate any different combination possible. On the other side, we put the same tests with the same timing with exactly the same actions against that so that we're able to tweak it left and right and see where it starts working, and where it goes wrong.

Even because I earlier said what we built is test automation, which is not fully true, because it's more like a tooling suite that we built: because in some cases what we also encountered is it us that's not able to do it or is it the platform? So, we build in tooling where we go directly to the decoder pipeline to be able to directly see - is the device able to do this? So that brought us a very far end, to be honest.

The second thing, which is the scavenger hunt that I mentioned earlier, you need to have the devices and you really need to have the real devices - so, you can't get it done with one or two or with the devices you find at home. You will be able to get it to work on one or two of them. But once it goes into the wild and you go into all of these different versions, I can guarantee you it's going to go wrong. So, we build our TV wall that I mentioned earlier, we went to our customers and partners to test on their end to extend the test approach or the test devices in our scope as much as possible. Pretty cool stuff, to be honest!

What helped us a lot in that? So, all of this is built from the ground up. On one hand, I think we're rightfully saying industry expertise: we have that a lot in-house, we have great people that not only built this framework and this tooling ground up, but also built the player ground up. So, we're able to control it fully: if we see something, we're able to interact, put hooks into the player or into our test system where needed to find what is it. We're able to build workarounds in the player for things that you saw that we mentioned earlier, like the keyframe problem. We're able to adjust any part of the playback pipeline, basically. So that helps us greatly to overcome all of these challenges.

Michel: Maybe it's good that we look at some key takeaways.

Pieter-Jan: Yeah, I think there's a lot of course that we've said. Probably you're wondering now, what should I really try to learn? Well, we've summed it all up for you on a nice slide. But the real key takeaways are that these are really capable devices, at least in quality of experience that they can bring: they can do 4K, even the very old ones, they can do HDR, they can play Dolby, they can really get you a very good experience as a viewer. But they are still very limited: they are not very capable in terms of compute, and that's a big problem. They are also very similar to what Samsung Tizen is, the same as a lot of other smart TV platforms. If you build it right and if you approach all of these smart TVs in the right way, then you can really go and do it at a very low cost - it's all HTML5. It's very similar on all of the different platforms.

Another very important thing is: because they're so similar, you can reuse the business logic. You don't have to rebuild your app. But, well, I think that's something that we did express now - for media playback, you cannot use the same approach everywhere, if you watched the Tizen webinar, you will know, there we recommended some other things as well, but these are still limited devices. Really getting across all of the platforms with a media experience, that remains a challenge, especially with all of the different models: really going out there testing it, it is a problem we faced it, we know that some of our customers used to face it. We have this amazing tool suite, if you're ever interested, let us know, as Michel mentioned, we can actually test things on our customers devices, those kinds of capabilities, so really testing a lot. It is very crucial, not just for LG, I know we're talking about webOS today, but also on all of those other platforms. It remains, for me at least, one of the key things that you really have to do it. Don't assume that something works on one model, that it will work on all of them. Because, well, I think we have been bitten by that assumption a few times. But that's how we learned.

Pieter-Jan: And that's actually about it. So, what I propose, because I see a lot of good questions coming in already, let's dive into the Q&A aspect of this. And let's see what kind of fun questions we have. And we'll start with some of the questions that people submitted during the registration.

“So how did you implement this with the very limited EME/MSE support on these devices?”

That's a very good question. Actually, we've been doing players for quite a long time, so, we actually were building players before MSE and EME were a thing. So, we've actually done this  full history ourselves as well with our normal web player. So, we had already some capabilities built-in to work on those very old Chromium versions because while our web player was originally built for those versions, we re-enabled some of those workarounds. We really started optimizing: the key is actually in not just developing for the old spec, but the key is finding which quirks matter on which platforms. That's where the testing comes in, unfortunately, it is really a trial-and-error kind of thing. But well how did we implement it? It was very hard work, I fear.

Michel: It's also our experience in our history that came back here. It's like you say it's we went through the journey earlier already and just going to this device, it's a lot what was done before, but it's adjusting it to the quirks and then the trickeries on that device testing, finding it out.

Pieter-Jan: The Darren back again story. But then in the video player world.

Michel: Yes, did we dream this, or did it really happen? And let's try it again and that's a bit of the journey in the last month.

Pieter-Jan: So, let's see, what is the next question:

“How different is the integration with Tizen?”

That's an interesting question. From an app perspective and from a tooling perspective, of course, the tooling is completely different, if you really look at it from a player perspective, well, I think it's fairly fair to say that the native capabilities are completely different across these devices as well. There are a lot of commonalities, DRM always is an issue, decoder resets is always an issue. But if you really look at business logic or how do you build your HTML5-app that's fairly similar, I think.

Michel: From an application point of view, it's very similar, certainly if you have a video player underneath which handles all of the challenges that you had here, then it's pretty similar to Tizen. You, of course, need to know the quirks, you need to know the trickeries. But in essence, from an application, it's not that different. But if you take into account the different quirks and things to take it's very much different.

Pieter-Jan: Yeah, but that's, of course, a difference that we usually tackle. So if you're building your own player, there are going to be differences. If you're using THEOplayer, that might be a lot easier. Let's hope that other players pick up on that as well, or not, could go both ways for us.

So next question, “Which DRM systems are supported on the most recent LG TVs?” Well, that's easy.

Michel: Yeah. PlayReady, Widevine are the commonly supported DRM systems on the recent. If you look at, let's take 5, 5.6 models, I think Widevine is completely a part of PlayReady. Maybe on the older ones, we sometimes do recommend, that's what we said earlier, to use PlayReady for some of the performance things. But you can use both, there's not really a big of a deal to it.

Pieter-Jan: I think for recent devices, it probably makes sense to use Widevine a bit more. The thing where it gets really interesting is that 2021 models, if you ask me, they actually also support CBCs. So both for PlayReady and for Widevine, that's a good evolution, seven more years is the average lifetime of a smart TV, so only seven more years and we can all use CBCs across the board even on those smart TVs.

Michel: “Do the recent LG TV’s support hardware based DRM-security?”

Pieter-Jan: Yes. Been a thing for a while already.

Michel: Yes and it also influences because the question is about the reason, but let's also answer the old a little bit: on the old ones that's not always the case, that's one of the links with performance, of course. But the recent ones it's almost all hardware accelerated. So, it's again, pretty powerful devices. So, yes!

Pieter-Jan: Yeah, and especially the 4k devices, they usually do have hardware-based DRM in there. So from content rights perspective, you're usually good to go.

“Can you elaborate a bit more on low latency on WebOS?”

That's actually a very interesting question. Old Chromium versions, what does that tell us? It tells us that there are no popular APIs that normally you would use for low latency use cases. For example, the fetch API, it's not available on old WebOS models. You need the fetch API to do anything like low latency DASH. For low latency HLS, there is actually an opportunity to run this on the old devices if you run it in the right mode. If you try to run it in a byte range mode, that will not work. If you run it in part mode, that will work. So, it is definitely feasible to go low latency on webOS, even on the old devices. On the new ones there's no problem at all. You can run LL-DASH, you can run LL-HLS with a custom player, not with native players. But if you really want to go across the board, I would say, come and talk with us, we're very happy to give you some more insights there. But the big lines will be, you'll need to go LL-HLS for the really old ones, unfortunately. Not one protocol that can serve them all or that you can reuse across all platforms.

Michel: Absolutely. Next question:

“How to leverage webOS native environment for video playback (and manipulation)?”

Didn't you write a blog article about that?

Pieter-Jan: We did write a blog about that. The real native environment, there are a few possibilities there because you can actually also implement some stuff and see if you would really want to. All in all, if you want to do playback on WebOS and you don't want to burn yourself, my advice would actually be to use the HTML5 approach. From a performance perspective, there isn't really a big difference. Of course, all of the webOS MSE-EME calls, they also go directly into the native libraries. So that's probably the approach that I would recommend there.

Michel:

“Is Chrome available on WebOS?”

If the question is, is it Chromium based? Yes, it's Chromium based. You don't have like with Tizen, that the older models are still WebKit-based, but it's all Chromium, starting from Chromium 38, 3.0 and 3.5. So, I presume that was the answer to the question.

Pieter-Jan: And there is also a browser. I think it's only if you go to WebOS 1.0 and 2.0, for which you cannot build apps anymore, I think, in the LG content store. So, becoming quite irrelevant. Those were WebKit-based, but all of the new ones, they're Chrome-based. So that's good.

Michel:

“We've seen poor performance in browser-based apps compared to native WebOS apps, also new to 2020.”

Yeah, that's an interesting question. To be honest, on the newer models, we mostly don't see performance problems, or it's not that big of a deal. There are, of course, some things that we do recommend to our customers if they report these things. It's not a browser environment. So, your heavy app, which does preloading and caching and refreshing of data, keeping stuff in memory, typically the React things. Don't do those things while you're playing video.

Pieter-Jan: So,if I remember correctly, you can correct me if I'm wrong, but webOS has like 128 megabytes of RAM available for every app, you can actually increase that. But we've seen React apps that, just go way out of line there. So, is it a problem to push a high bitrate through an app? No, definitely not. Is it very difficult to push a high bitrate through an app while you are loading your entire EPG through your app in the background, which is a huge XML that you're trying to parse or a huge JSON file or your own custom format that you're trying to parse and render nicely underneath your video? Yes, then you will bump into issues. And of course, as we also mentioned the high frame rates, there you do need to pick your DRM correctly. There you do need to watch out because otherwise you will see stutters and that will be a horrible experience.

Michel: But you can build an application in the web environment, which is where you can't see the difference with the native app for sure. Even on the 2017, 26 models for sure.

Pieter-Jan: And it's, of course, the approach that most of the big people also use. If you really need to support a lot of these platforms, then having some commonality between them really helps.

Michel: Yeah, absolutely. 

Pieter-Jan:

“Did you try working with Shaka Player on WebOS?”

Of course. Very interestingly, we actually have this in our automation suite. We actually run with Shaka Player, DASH.JS, and all of the others. We compare them in our test automation. That's why we can usually make those nice tables like: does it work? yes, or no? Usually, the answer is no. As I mentioned earlier, it's not officially supported. Unofficially, there are some community people working on it. So, in most cases it does actually work, but it is once you start trying to squeeze out the most of it, really high frame rate streams with DRM, especially once you start going into server-side ad insertion, then it unfortunately breaks apart, I think.

Michel: Yeah, they do great stuff with Shaka Player, and the common things, they do work. It's a neat part of our tooling to compare against. But when you go into the typical OTT features, the more killer things, then you will run into some limitations or have to do much more yourself.

Pieter-Jan: You mentioned it: you start noticing it's not optimized for it - these are great players, but they're built to work on the web. Unfortunately, on these old Chromium versions, there are a lot of quirks, they're tricky to anticipate. If you're not focused on it, I think any player would struggle with it.

“Can you share some tips or things you should be aware of when working with 50 FPS content?” I think we already mentioned a few. I think the most important tip to mention or to repeat again is probably pick your DRM wisely and watch out for the full HD models.

Michel: Yeah, and our typical question is if a customer would ask this to us or to me, the first thing I would ask is which models are you trying to support? And then referring back to the hardware models, the full HD ones, which year, where are you starting from? And then we would start looking at what you use best for each of the models and each of the versions, trying to ensure you always try to use the hardware accelerated optimizations where possible, and then you can get this to work. It's been in the last weeks, even one of our challenges but yes talk to us, I would say.

Pieter-Jan:

“SSAI live ads and webOS?”

That's always a fun one and I think, the biggest challenge here isn't SSAI live ads in webOS per se. I think the real big problem is SSAI live ads in webOS, where the ads are in the clear and the content is DRM encrypted. We have a lot of experience with this at this point. As I mentioned, the trick is really in enabling that secure pipeline when you're trying to do the DRM encryption or at least DRM decryption. And that's where things usually fall apart. But it is perfectly possible to do this in a completely seamless way. Broadcast-like experiences, that's definitely something that you can do on webOS. Is it easy? Well, we worked quite a lot on it to actually get it implemented. We were very happy once we got it running in a very stable way. We do know that most other players don't support it, especially the native player, it will just chicken out once that happens, but it is possible. So I think that's the good news! If you want to try something, as we mentioned, we can even run your streams on your own device.

Michel: Yeah, we can even generate or replicate your content so even this use case was one of the most interesting in the tooling build up to make it possible to make a live SSAI stream with all different settings, policies and codings. So what do we have next?

Pieter-Jan: So following the question on SSAI and ads: 

"When switching between protected segments and the clear segments. How smooth is the switching?”

So, I think we just answered that, it can be 100% smooth.

Michel: Yeah, it’s seamless, absolutely.

Pieter-Jan:

“Are you using internal storage for pre-loading?”

Actually, using internal storage for pre-loading is one of the options that we looked at. We aren't using it right now. Well, just imagine a standard multi-period approach for server-side ad insertion. There, what you do is you actually start loading the first part of the content that's coming up, and you normally add it in your buffer immediately. That's actually the approach that we're using for client-side ad insertion as well. So, we start preloading that content, we actually keep it in memory. We have some trickery, sometimes there are ways to add it in the buffer, sometimes there aren't. It's not internal storage per se, it's more in memory storage. But of course, keeping in mind the limited memory, but that's the way how we actually are doing it.

Michel:

“Is it possible to modify the design of the playback control panel?”

Pieter-Jan: Absolutely! It's what usually all of our customers have. They always have custom UIs. I don't know how easy it is, of course, to do it with a native player, I actually think you can run it in chromeless mode as well, so that should not be a problem. The one thing you can’t do is remap your remote. So, your remote will still look the same, but everything else, as long as it's shown on the screen, you can change it.

Michel: It's also typically something that we bring the APIs and the events for in our players to allow you to build any playback control that you want, certainly on the big screen, spatial navigation things that's sometimes pretty a custom approach. So, yes, it's possible.

Pieter-Jan: Yeah, let's see. I think we have one more question, if I'm seeing that correctly:

“Have you encountered issues with playback of HEVC in large resolutions for 4K, given that it's not always possible with GPU encoders? And how do you solve that in your player implementation?”

We have tried it with all kinds of different resolutions at this point in time. Of course, there are a few limitations on webOS devices - one of those are resolutions and other of those are usually bitrates,  because usually, let's be honest, the bitrates that LG has on their website, it's not really what you can achieve. It's what you can achieve with clear content, it's usually not what you can achieve with DRM encrypted content. So, is it possible to play back these kind of streams? Well, we haven't seen any issues specifically on these resolutions, but I can imagine that you can bump into issues if you would have the full shebang 60 frames per second, DRM. Best way, I would say we've said it a few times: testing.

Michel: Yeah, test it even on your device. No problem. And a typical question on these kind of things is - which models are you trying to support, as of which year what encryption are you using? Those kind of things, but let's test it. 

Pieter-Jan: Yeah, that should be feasible, my expectation would be that older models, as usual, will bump into some issues, but the newer ones we should probably be okay.

Michel: And it's also typically something where what we have seen with our player and which we can guarantee is we are hitting the platform limits or we are close to the platform limit. So, with our tooling, we're able to verify it directly, excluding any other overhead. And what we see is what we can do with the player is that the best platform can offer.

But again, these things we need to test.

Pieter-Jan: Especially on the latest versions the webOS 6 ones which can also do 8k for some devices will all be fine. It's probably going to be on the older 4k devices, that might be a challenge.

Michel: Yeah, indeed!

Pieter-Jan: Okay, so I see that we've completed the list.

So, we have a few questions still: let us know how relevant this webinar was for you, if you think it was fun, let us know. If you think it was less fun, let us know. Then we can try to do better next time.

But I hope that you all learned something. I hope we had an interesting conversation. And if there are any questions that we didn't answer, you know where to find us. Just reach out to our teams and we'll be more than happy to assist.

Michel: Yeah, absolutely.

Pieter-Jan: Take care. Thanks a lot for joining. And well, we hope to see you soon!