Built-in vs in-app DASH players

HbbTV applications can deliver MPEG-DASH content using either the television’s built-in DASH player or a JavaScript player embedded within the application. Both approaches are widely used across the HbbTV ecosystem and each offers different advantages in terms of compatibility, performance, flexibility and ease of deployment.

This guide explains how the two approaches work, compares their strengths and limitations, and provides guidance on selecting the most appropriate implementation for your deployment.

At a glance

Feature	Built-in (Native) Player	In-App JavaScript Player
Implemented by	Television manufacturer	HbbTV application
Playback API	OIPF media APIs or HTML5 <video>	HTML5 <video> with Media Source Extensions (MSE)
Updates	Television firmware	Application release
Performance	Typically highly optimised	Depends on browser and JavaScript engine
Feature rollout	Follows television lifecycle	Controlled by application developer
Best suited for	Maximum compatibility	Rapid feature development and cross-platform consistency

Built-in (native) DASH player

Every HbbTV receiver since HbbTV 1.5 (ETSI TS 102 796 V1.2.1) has been required to include a native MPEG-DASH player. Rather than embedding a player within the application, developers use the playback functionality provided by the television itself.

Historically, DASH playback has been controlled using the OIPF media APIs through an HTML <object> element with a MIME type of application/dash+xml.

Since HbbTV 2.0.1 (ETSI TS 102 796 V1.4.1), applications can also use the standard HTML5 media APIs by playing DASH content through the <video> element and its associated JavaScript methods such as play() and pause().

In both cases the television is responsible for:

• downloading media segments
• buffering
• adaptive bitrate selection
• decoding
• rendering the video

The application simply controls playback through the available media APIs.

Because the player is supplied by the television manufacturer (or one of its software suppliers), application developers have little visibility into its internal implementation. Native players are generally tightly integrated with the television hardware and operating environment.

Advantages

Native players offer several important benefits.

Excellent compatibility

Native DASH playback has existed throughout the HbbTV ecosystem for many years and has been validated across a very large installed receiver base. It is also extensively covered by the HbbTV Test Suite, providing confidence that compliant implementations behave consistently.

High performance

Because the player is integrated into the television platform, playback is often highly optimised. Benefits commonly include:

• lower CPU utilisation
• lower memory consumption
• faster start-up
• improved playback stability
• efficient hardware decoder utilisation

Manufacturer optimisation

Manufacturers can optimise native players for their own hardware, including decoder pipelines, memory management, hardware acceleration and operating system integration.

DVB-I integration

Where a television already includes a suitable native DASH player, DVB-I services can often begin playback without requiring an HbbTV application. If an application is unavailable or fails to launch, playback can still continue using the television’s built-in capabilities.

In-app JavaScript DASH player

Instead of using the television’s built-in player, applications can implement DASH playback entirely in JavaScript.

The two most widely used open-source players are:

• dash.js – the reference implementation of MPEG-DASH, developed by the Dash Industry Forum (DASH-IF)(now part of the Streaming Video Technology Alliance (SVTA)).
• Shaka Player – an open-source player developed and maintained by Google, supporting both MPEG-DASH and Apple HLS.

Both players run entirely within the HbbTV application.

They use:

• Media Source Extensions (MSE) to download, buffer and present media through the HTML5 <video> element.
• Encrypted Media Extensions (EME) to interface with platform DRM implementations such as PlayReady or Widevine, where supported by the device.

Since the player forms part of the application, it can be updated whenever the application is updated. New features, bug fixes and performance improvements therefore become available independently of television firmware updates.

Media Source Extensions became mandatory in HbbTV 2.0.3 (ETSI TS 102 796 V1.6.1), although many receivers implemented MSE before it became mandatory. Support for Encrypted Media Extensions depends on the capabilities of the target receiver.

Alongside these open-source players, several commercial JavaScript players are available, often providing additional capabilities such as advanced analytics, advertising integration, enhanced DRM support, low-latency streaming and commercial support.

Advantages

Rapid feature deployment

Perhaps the greatest advantage of an in-app player is that new capabilities can be deployed as part of the application release process rather than waiting for television firmware updates.

This allows developers to adopt:

• new DASH features
• Common Media Client Data (CMCD)
• improved adaptive bitrate algorithms
• analytics enhancements
• new codecs (where platform capabilities permit)

much more quickly than would typically be possible using native players.

Consistent behaviour

Instead of supporting many different manufacturer implementations, developers work with a single player implementation that they configure and maintain themselves. This generally produces more consistent behaviour across devices.

Simplified debugging

Modern JavaScript players provide extensive logging, metrics and diagnostic information, making it easier to investigate issues involving:

• packagers
• encoders
• CDNs
• DRM systems
• adaptive bitrate behaviour

Cross-platform reuse

The same JavaScript player can often be shared across:

• HbbTV applications
• web browsers
• mobile applications
• other connected TV platforms

This reduces development effort while improving behavioural consistency across multiple platforms.

Limitations of native players

The principal limitation of native players is that developers have relatively little control over how they behave.

Unlike JavaScript players, where playback behaviour forms part of the application, native player capabilities are determined by the television manufacturer and the installed firmware version.

Developers cannot generally customise:

• adaptive bitrate algorithms
• buffering strategies
• start-up behaviour
• error recovery
• feature implementation

Support for newer DASH capabilities also varies across the installed receiver base. Differences may include:

• supported DASH profiles
• DRM integration
• adaptive bitrate implementation
• low-latency streaming

When a required capability is unavailable, developers have few options beyond application-level workarounds or waiting for manufacturers to implement the functionality.

Television software also evolves relatively slowly. Even after a manufacturer develops support for a new capability, widespread deployment depends on several factors, including:

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

As a result, new streaming technologies may take several years before becoming widely available across the installed receiver base.

Limitations of in-app players

Running an entire DASH player inside a web application also introduces trade-offs.

Compared with native implementations, JavaScript players typically require:

• greater CPU resources
• additional memory
• JavaScript execution
• browser support for MSE and related APIs

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

Although MSE support is now widespread, HbbTV Test Suite coverage for MSE-based playback remains less comprehensive than native playback, and successful operation also depends on browser functionality beyond MSE, including XML parsing and JavaScript performance.

Hardware decoder integration may also vary between browser implementations, particularly on non-television platforms.

Selecting a playback strategy

The appropriate playback strategy depends primarily on the capabilities of the receivers you need to support.

Where MSE support is limited

If a significant proportion of the installed receiver base does not support Media Source Extensions, native playback remains the most practical approach. It provides the broadest compatibility and ensures services reach the widest possible audience.

Where the market is transitioning

Many deployments support both older and newer HbbTV receivers.

In these cases, applications may support both playback approaches. The application detects receiver capabilities during start-up and selects either the native player or a JavaScript player accordingly.

This hybrid approach offers:

• maximum audience reach
• access to newer capabilities on modern receivers
• gradual migration as the installed base evolves
• lower commercial risk

The trade-off is increased development, testing and maintenance effort.

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 deployed

Where the overwhelming majority of target receivers support MSE, developers may choose to standardise on an in-app player.

This provides a consistent playback implementation across supported devices while allowing new capabilities to be introduced through normal application releases rather than television firmware updates.

For organisations operating across web browsers, mobile applications and connected TV platforms, a shared JavaScript player can also simplify long-term maintenance.

Best practice recommendations

When selecting a playback strategy, consider:

• the capabilities of your target receiver population
• the importance of maximum audience reach
• performance requirements
• the rate at which new streaming features are likely to be adopted
• long-term maintenance costs
• cross-platform development requirements

Many services will follow a phased migration:

1. Native playback for maximum compatibility.
2. Hybrid support during market transition.
3. JavaScript-only playback once MSE support is sufficiently widespread.

Further reading

• HbbTV Specification (ETSI TS 102 796): https://www.hbbtv.org/resource-library/specifications/
• Dash Industry Forum (DASH-IF): https://dashif.org/
• dash.js: https://github.com/Dash-Industry-Forum/dash.js
• Shaka Player: https://github.com/shaka-project/shaka-player
• Streaming Video Technology Alliance (SVTA): https://www.svta.org/
• Media Source Extensions (W3C): https://www.w3.org/TR/media-source-2/
• Encrypted Media Extensions (W3C): https://www.w3.org/TR/encrypted-media/