Smart TV streaming is growing rapidly. To maximize their reach and boost revenue, OTT video distributors need to get into the app stores of all major streaming platforms, including LG’s webOS. Fortunately, there are a couple of approaches you can take with webOS app development.
In this guide, we will break down two popular methods for creating a webOS video player: leveraging the native webOS player and building your own. To wrap things up, we’ll discuss how an advanced video player can help you create a more engaging user experience for your viewers on LG TVs.
The basics of developing a streaming app for webOS
Since 2014, LG has been using webOS as a platform. While the platform has a history with Palm and HP, and an open-source version exists, the main driver behind webOS is LG, which acquired the platform in 2013.
The platform itself is Linux-based, but developing applications for it usually doesn’t involve languages you might expect, like C. Instead, applications tend to run in a web environment.
Same as most other smart TV platforms, bringing your app to LG’s webOS platform goes through a store: the LG Content Store. The LG Content Store follows the same process as most app stores, requiring a review before your app can be published.
As the name suggests, webOS apps are developed entirely in web technology, using HTML5. Traditional app store processes can significantly slow down development, but the web is known for its flexibility. On webOS, the “hosted app” approach is quite common. You create an app that instructs the platform to load the latest and greatest from the web.
While you still have to go through the validation process once to get listed in the LG Content Store, you can easily bypass future reviews for updates. This agility is very valuable in an era where competition in the streaming landscape is growing exponentially.
Building an app for webOS is quite simple since web technology is the main driver. Most APIs used in the process follow W3C specifications, making it similar to developing a website for a standard browser. You can likely reuse most of your website logic, provided you make some tweaks on the UX side to ensure smooth integrations with LG’s Magic Remote.
Two approaches to developing a TV app for webOS
To bring your content to webOS, you’ll need a video player. On webOS, this is quite simple. You either rely on the native player for basic playback or you load up a “bring your own” video player library to power your unique viewer experiences.
Let’s take some time to look at how each of these works.
Approach 1: Using the native webOS player
The first approach is to leverage native playback support on webOS. This approach makes it very easy to build and launch your app. However, the native player is extremely rudimentary, so it comes with some significant limitations.
For starters, there’s no real support for MPEG-DASH. Most content publishers are moving to a setup that combines MPEG-DASH with Common Encryption, but webOS got stuck in the HLS era since it uses Widevine and PlayReady. However, even HLS support is basic. Most modern webOS 5 TVs support HLS version 7, which is Pantos-draft 14, dating back to 2014. The 4.x version of the platform only supports HLS version 5, and older devices are stuck on HLS version
Even with HLS support, the list of unsupported HLS tags is longer than the list of supported tags. Reading through the availability of EXT-X DISCONTINUITY, which is crucial for server-side ad insertion, has several limitations. Metadata is not supported at all, and neither EXT-X-PROGRAM-DATE-TIME, EXT-X-DATERANGE, nor ID3 is handled.
However, on a positive note, DRM is supported. PlayReady and Widevine Modular also work on devices that use webOS 3.0 or newer. For older versions, it’s down to Widevine Classic and, unofficially, PlayReady.
The limitations of this approach seem to outweigh the benefits, so the native player is only suitable for fundamental use cases.
Approach 2: “Bring your own” player to webOS
Another popular approach to developing an app for webOS is the “bring your own” (BYO) player approach. This method provides much more flexibility, which is helpful for creating higher-quality user experiences.
The Media Source Extension (MSE) API and the Encrypted Media Extension (EME) API, which are available on all later webOS models, make this possible. MSE provides access to media decoders, and EME allows access to the Content Decryption Module (or CDM), which enables you to leverage the platform’s DRM capabilities.
As MSE and EME are only APIs, there’s more to it than meets the eye. Development based on these APIs still requires a proper understanding of media and the web, as the entire implementation of the streaming protocols has to happen in dedicated code. In most cases, fully featured media players have to go above and beyond to bring a vibrant viewer experience.
THEOplayer, now known as Dolby OptiView Player, was the first media player to handle complex media in browser environments without using MSE or EME. Even with all of the basics implemented, there is a significant difference between media player options. Some media players only provide basic playback, especially open-source libraries that support the HLS or MPEG-DASH protocol, such as hls.js, dash.js, and Shaka Player.
More advanced players, like OptiView Player, offer even more support, including integrations with various DRM systems, monetization options with CSAI and SSAI, picture-in-picture support, offline downloading support, and more.
Important considerations for the BYO approach
While webOS does support all the required APIs to use any framework, there are some significant differences in implementation. On one end, most open-source playback implementations assume the MSE and EME APIs are entirely up to date. However, this is not the case.
On top of this, webOS also tends to have specific decoder behavior due to its hardware being significantly different from that of standard browser environments on a laptop or mobile device. This can be expressed in things such as seeking only to key frames on specific versions, not allowing changes in playback rate, how the buffer is exposed, and so forth. All of this means your playback library must support all webOS versions where you plan to deploy.
While they usually work on the platform, most common open-source playback software rarely officially supports webOS. This creates a risk because smart TV platforms are often forgotten and do not make it into the testing cycle.
For example, hls.js’s compatibility list does not include webOS. Dash.js does not list any platforms and only claims to rely on MSE being implemented. Shaka Player mentions that webOS is not officially supported but “expected to work.”
Dolby OptiView Player for webOS app development
At Dolby, we actively support the webOS platform and have code in our Dolby OptiView Player SDK to handle differences and quirks compared to standard browser environments. This includes tools for handling limitations such as the number of decoders that can be used in parallel, switching between video codecs, enabling and disabling DRM, handling higher bitrates, alternative codecs, and HDR content on large screens, among others.
With Dolby OptiView Player, we provide the ability to switch to native playback if needed, while still utilizing our universal API. This has the added benefit that integrations with external services such as analytics and DRM only have to be implemented once. It effectively allows you to use a hybrid approach, making use of native playback where it makes sense and leveraging the power of MSE/EME where possible.
Final thoughts
For most use cases, the best approach for webOS is to leverage MSE/EME where available. The native pipeline’s limitations are too significant and prevent delivering a high-quality user experience.
The Dolby OptiView Player is a powerful tool for creating dynamic streaming experiences on LG smart TVs. Contact us to learn how Dolby can support you as you develop your webOS app.
