August 5, 2026

Built-in vs In-App DASH Players: Which approach is right for HbbTV?

As HbbTV has matured into a comprehensive platform for delivering IP-based television services, one architectural decision has become increasingly important: should applications rely on the television’s built-in DASH player, or include their own JavaScript-based player such as dash.js or Shaka Player?

This question formed the basis of a lively discussion during one of the unconference sessions at the 2025 HbbTV Symposium in Istanbul, where broadcasters, manufacturers and technology providers shared experiences from real-world deployments and debated the long-term direction of DASH playback within HbbTV. Rather than seeking a single “correct” answer, the discussion highlighted that both approaches have important strengths, weaknesses and deployment considerations.

This article summarises the key themes from that unconference session and explores when each approach is most appropriate for HbbTV services.

Two different approaches

Built-in (Native) DASH player

Every HbbTV device since version 1.5 (TS 102 796 V1.2.1) has been required to include a native DASH player. Rather than embedding a media player within the application, developers use the playback capabilities provided by the television itself. Historically, native DASH playback has been accessed using the OIPF audiovisual object APIs by creating an HTML <object> element with a MIME type of application/dash+xml. Since HbbTV 2.0.1 (TS 102 796 V1.4.1), developers can also use the standard HTML5 media APIs, allowing DASH content to be played using the familiar <video> element and its associated JavaScript methods such as play() and pause(). In both cases, the television’s native player is responsible for downloading, buffering, decoding and presenting the DASH stream, while the application controls playback through the relevant media APIs.

Because the implementation is supplied by the television manufacturer (or one of its software suppliers), application developers have little visibility into, or control over, the internal operation of the player. Although implementations differ between manufacturers, native players are generally tightly integrated with the television’s hardware and operating environment.

Their characteristics include: 

• implemented by the TV manufacturer
• accessed through the HbbTV/OIPF media playback APIs or the HTML5 media APIs
• included as part of the device software
• typically not updated after deployment
• required by the HbbTV specification since HbbTV 1.5. 

In-App DASH player

An alternative approach is to embed a DASH player directly within the HbbTV application.

The two best-known open-source players are dash.js and Shaka Player.

dash.js is the reference implementation of the MPEG-DASH standard and is developed as an open-source project under the stewardship of the Dash Industry Forum (DASH-IF), now part of the Steaming Video Technology Alliance (SVTA). It widely used across the streaming industry for both commercial deployments and interoperability testing.

Shaka Player is an open-source JavaScript media player developed and maintained by Google. While it also provides comprehensive support for MPEG-DASH, it additionally supports Apple’s HLS streaming format, making it attractive for services targeting multiple web and connected TV platforms from a single player implementation.

Both players are written in JavaScript and run entirely within the HbbTV application. They use Media Source Extensions (MSE) to download, buffer and present media segments through the HTML5 <video> element, and Encrypted Media Extensions (EME) to interface with platform-provided DRM systems such as PlayReady or Widevine, where these are supported by the device. Since the player forms part of the application, it can be updated whenever the application is updated, allowing new features, bug fixes and performance improvements to be deployed independently of television firmware. MSE became mandatory in HbbTV 2.0.3 (TS 102 796 V1.6.1) and was already widely implemented before then, while support for EME depends on the capabilities of the target devices and DRM implementation.

Alongside these open-source options, a number of commercial JavaScript players are also available. These often build on the same underlying web technologies while adding enterprise features such as advanced analytics, advertising integration, low-latency streaming, enhanced DRM support and commercial support.

Why native players still matter

Native players have several significant technical advantages.

Performance

Because the player is closely integrated with the television platform, playback can often be more efficient.

Benefits can include:

• lower CPU utilisation
• reduced memory consumption
• faster startup
• improved playback stability

One example shared during the unconference discussion described an HD+ OpApp running on an HDMI streaming stick achieved noticeably better performance using the native player than a JavaScript implementation. 

Extensive device support

Native DASH playback has existed throughout the HbbTV ecosystem for many years and has therefore been tested extensively across a very large installed base.

The HbbTV Test Suite also provides substantial coverage of native playback behaviour, giving application developers confidence that compliant implementations behave consistently. 

Manufacturer optimisation

Native implementations also give manufacturers opportunities to differentiate their products.

They can optimise:

• decoder performance
• memory management
• startup times
• hardware acceleration
• platform integration

These optimisations are difficult for JavaScript players to replicate.

Simpler DVB-I deployments

One interesting observation concerns DVB-I services.

Where the television already includes an appropriate native player, services can often be delivered without needing to download and execute an application. If an HbbTV application is unavailable or fails to launch, playback can still continue using the built-in functionality. 

The limitations of native players

Despite these strengths, native implementations also have some important drawbacks. The greatest limitation is that application developers have relatively little control over how they behave or the features they support.

Unlike a JavaScript player, where playback behaviour can be configured and enhanced as part of the application, the capabilities of a native player are determined by the television manufacturer and the version of firmware installed on the device. Developers generally cannot fine-tune key aspects of playback such as adaptive bitrate (ABR) algorithms, buffering strategies, startup behaviour or error recovery to optimise performance for their own streaming infrastructure. This lack of control can make it more difficult to tailor playback for different network conditions, content types or quality-of-service objectives.

Similarly, support for DASH features varies across the installed receiver base. Differences may include:

• supported DASH profiles
• DRM integration and available key systems
• adaptive bitrate behaviour and buffering implementation
• support for low-latency streaming
• newer capabilities such as Common Media Client Data (CMCD)

If a required capability is missing or behaves differently across devices, developers have few options beyond implementing application-level workarounds or waiting for television manufacturers to introduce the functionality. Television software evolves relatively slowly, and even after a manufacturer plans to implement a new capability, widespread deployment depends on a number of factors, including:

• specification stability
• availability of conformance test suites
• new television model release schedules
• firmware release schedules for existing devices
• consumers installing firmware updates
• the natural replacement cycle of televisions

Consequently, new streaming technologies can take many years before becoming established across the installed receiver base. During the unconference session, Common Media Client Data (CMCD) was highlighted as a good example. Support can be introduced into JavaScript players as soon as it is implemented by the player library, allowing developers to deploy the capability simply by updating their application. By contrast, equivalent support in native players depends on manufacturers implementing the feature and rolling it out through new television models and firmware updates, resulting in a much slower adoption cycle.

Why JavaScript players are becoming more attractive

While native DASH players continue to provide excellent performance and broad compatibility across today’s installed HbbTV receiver base, the increasing availability of Media Source Extensions (MSE) on newer televisions has made JavaScript-based players a practical option for many deployments. By implementing the playback engine within the application, developers gain greater control over playback behaviour, can adopt new streaming technologies more quickly and deliver a more consistent experience across multiple platforms.

These advantages have made JavaScript players an increasingly attractive choice for new HbbTV services.

Faster feature deployment

Faster feature development and deployment is perhaps the greatest advantage of an in-app player. When new streaming standards emerge, developers can add support by updating the player library as part of their application release, rather than waiting for television manufacturers to implement the capability and for it to reach households through firmware updates and the natural replacement cycle of televisions.

Examples include:

• CMCD
• new DASH features
• codec support (where platform capabilities allow)
• improved adaptive bitrate algorithms
• analytics enhancements

This rapid innovation is particularly valuable as IP streaming technologies continue to evolve.

Greater consistency

A JavaScript player behaves similarly across many platforms.

Instead of supporting dozens of manufacturer-specific native implementations, application developers work with a single player that they can configure and optimise themselves.

This often makes interoperability problems easier to diagnose because behaviour is more consistent across devices.

Easier Debugging

Modern JavaScript players provide extensive logging, metrics and diagnostic information.

This simplifies investigations involving:

• encoders
• packagers
• CDNs
• DRM systems

compared with diagnosing issues inside native implementations.

Better Alignment with the Wider Web

JavaScript DASH players are already widely used beyond HbbTV.

The same player can often be shared between:

• connected TVs
• desktop browsers
• mobile applications
• other web-based platforms

This can reduce development effort and improves consistency across services.

The challenges of JavaScript players

Running an entire media player inside a web application inevitably introduces trade-offs.

Higher Resource Requirements

JavaScript players typically require:

• more CPU
• more memory
• additional JavaScript execution

This can be particularly noticeable on older televisions with limited processing power.

Performance therefore depends not only on MSE support but also on the quality of the browser’s JavaScript engine and other platform components.

HbbTV test coverage

Although MSE support is now widespread, HbbTV Test Suite coverage for MSE-based playback remains more limited than for native playback.

JavaScript players also depend upon more than MSE alone, including XML parsing and other browser capabilities that may affect interoperability. 

Hardware acceleration

Another consideration is video decoding.

Some browser environments, particularly outside televisions, may decode video in software, potentially limiting support for high-resolution or HDR playback.

Efficient access to hardware decoders therefore remains an important consideration when evaluating JavaScript-based playback. 

Choosing the right approach for your deployment

Although the technical strengths and weaknesses of native and in-app players are important, the decision is often driven by a much simpler question:

What capabilities are available across the televisions you need to support?

The answer will vary significantly between deployments, particularly where services must support a mixture of older and newer HbbTV devices.

Where MSE support is limited

If a significant proportion of the deployed receiver base does not support Media Source Extensions (MSE), developers have little choice but to rely on the television’s native DASH player.

This approach maximises compatibility and ensures the service reaches the widest possible audience. While it may limit access to newer streaming capabilities, broad device support is often the overriding commercial requirement for broadcaster services.

Where the market is in transition

Many deployments sit somewhere between the old and new worlds.

In these cases, developers may choose to support both playback approaches within a single application. The application can detect the capabilities of the receiver during start-up and select either the native player or an in-app JavaScript player accordingly.

This hybrid approach offers several advantages:

• maximum audience reach
• access to newer player capabilities on modern devices
• gradual migration as the installed base evolves
• reduced commercial risk during technology transitions

The trade-off is increased development and testing effort, as both playback paths must be maintained and validated. 

Streaming video is not the only difference between HbbTV versions, and developers may already need to support separate application versions for newer and older devices in their target population.

Where MSE is widely available

Once the overwhelming majority of the target receiver base supports MSE, developers may decide to standardise on a JavaScript player.

Doing so provides a consistent playback implementation across supported devices and allows new features, performance improvements and bug fixes to be deployed as part of the application rather than waiting for television firmware updates.

For organisations operating across multiple platforms, including connected TVs, web browsers and mobile devices, this can also simplify development by allowing much of the playback logic to be shared.

A commercial decision as much as a technical one

Ultimately, the choice between native and in-app playback is rarely made on technical merit alone. Broadcasters must balance innovation against audience reach, development effort and operational risk.

A new service targeting the latest connected televisions may reasonably choose an in-app player from the outset. By contrast, a national free-to-air broadcaster serving millions of existing HbbTV receivers may prioritise compatibility and continue using native playback for some time.

As the installed base continues to evolve, many deployments are likely to follow a phased journey, from native playback today, through hybrid implementations during the transition, and eventually towards predominantly JavaScript-based playback where market conditions make that practical. This gradual evolution reflects one of HbbTV’s core strengths: enabling new capabilities to be introduced while maintaining compatibility with existing receivers.

Which Direction Is HbbTV Taking?

Within the HbbTV community there has been discussion about the future balance between native and in-app players.

One view expressed within the Requirements Group has been that the native player should remain relatively stable, with future innovation increasingly focused on JavaScript-based players. Under this approach, manufacturers remain free to exceed the specification, but HbbTV may gradually reduce investment in adding new native player features and associated conformance testing. 

However, the wider industry has not reached full consensus. Browser developers have been slow to extend MSE for newer features such as advanced Next Generation Audio and object audio, including Dolby AC-4. As a result, advanced capabilities could appear in native DASH players first.

Real-world deployments continue to demonstrate that native players can offer significant performance advantages, particularly for operator-controlled services such as OpApps. At the same time, application developers increasingly value the flexibility and rapid evolution offered by JavaScript players.

The result is not a competition between two mutually exclusive technologies, but an ecosystem in which both approaches continue to play important roles.

What Happens Next?

Several possible areas for future work have already been identified within HbbTV discussions:

• expanding HbbTV Test Suite coverage for MSE-based playback
• considering performance requirements for JavaScript DASH players
• investigating whether JavaScript players could be cached on televisions to improve startup performance
• continuing cross-working-group discussions on the long-term direction of DASH playback in HbbTV. 

As television delivery becomes increasingly IP-based, ensuring robust, interoperable streaming performance across the entire HbbTV ecosystem will remain a priority.

Conclusion

There is no universal winner in the native versus in-app DASH player debate. Native players continue to deliver excellent performance, deep platform integration and broad compatibility across today’s installed base. They are particularly well suited to deployments where stability, efficiency and predictable device behaviour are paramount.

JavaScript-based players, however, offer greater flexibility, faster innovation and much stronger control for application developers. They enable new streaming features to be adopted more quickly, simplify cross-platform development and make interoperability issues easier to diagnose and resolve.

For many HbbTV services, the choice will depend on the balance between performance and agility. As streaming technologies continue to evolve, both approaches are likely to coexist, with native players providing a stable foundation for many devices while in-app players drive the next generation of IP television capabilities.

Matthew Huntington
Manager HbbTV Developer Programme