Overview
This section provides an overview of WASM Player, a Tizen TV WebAssembly extension allowing for low-level elementary media stream playback. Essential information & guidelines on WASM Player APIs for WebAssembly are included.
Overview
Tizen WASM Player is a Samsung TV extension API which grants a WebAssembly application low level access to a Platform's media player. WASM Player operates on Elementary Stream Packet level, accepting encoded packets that are decoded and rendered by the TV multimedia pipeline. Depending on operation mode, it is fit to be used either as a video on-demand player (normal latency mode, suitable for adaptive streaming scenarios) or as a streaming player (low latency mode).
As a low level media API, WASM Player is responsible only for decoding and rendering media content. Acquiring media content and splitting it into Elementary Media Packets that are passed to the player is entirely dependent on App. This allows for a great flexibility: the application has full control over downloading data, demuxing, either low latency or adaptive streaming protocol implementation, etc. When EMSS is used major part of multimedia pipeline can be implemented as a WebAssembly module and it is platform-independent, allowing for a wide variety of multimedia applications.
This article describes both modes in detail and describes all API components required to use WASM Player in a WebAssembly App.
Modes Of Operation
Normal Latency
WASM Player in normal latency mode can be used to playback typical on-demand media. In this mode Platform maintains both multimedia pipeline clock and synchronization of all running streams (audio and/or video), whereas the WebAssembly application is required to fill WASM Player packet buffer with ES packets to be decoded and rendered by Platform. Normal latency mode supports all playback operations defined by WASM Player components, as well as DRM-protected content playback (see table comparing modes below).
Normal latency mode is the best choice when playback is not optimized for latency.
Pipeline clock & stream sync
When Normal Latency mode is used, Platform runs the multimedia pipeline according to a steady, monotonic internal clock. Rendering of packets sent to WASM Player is synchronized with the clock according to their timestamps. Pipeline time advances only when player's internal buffer allows continuous playback of all streams; if buffer underflow is detected, pipeline pauses.
Low Latency
WASM Player set to Low Latency mode can be used to playback streams which require minimal latency, such as media originating from a live source (e.g. game streams, live camera feeds). In this mode both pipeline clock and synchronization of multimedia pipeline is controlled entirely by the WebAssembly application. Platform renders ES Packets immediately after they are passed to WASM Player. Low latency mode allows playback with minimal latency, however access to some operations and DRMs is limited (see table comparing modes below). Due to a nature of low latency playback, B-frames cannot be used.
Low latency mode is the best choice for playing media from live sources.
Pipeline clock & stream sync
When Low Latency mode is used, Platform advances multimedia pipeline running time according to timestamps of packets passed to EMSS: whenever a packet is sent the pipeline clock is updated immediately based on it's timestamp.
Since Platform renders incoming Elementary Media Packets as they are sent and updates of the pipeline clock are directly dependent on App's actions, track synchronization is App's responsibility.
Mode comparison
Feature | Normal Latency | Low Latency |
---|---|---|
Pipeline clock & stream sync | controlled by Platform | controlled by App |
Runtime configuration change | resolution: yes fps: yes |
resolution: yes fps: N/A* |
Seek | yes | N/A** |
DRM Support | yes | no |
Example usage | VOD solutions; DASH, HLS, etc. | live streaming solutions; RTSP, etc. |
* - FPS rate doesn't apply in low latency mode, as rendering rate is dependent entirely on packet sending frequency (therefore fps is freely and entirely controlled by App).
** - Seek operation doesn't apply in low latency mode, as it implies working with a live, non-seekable source.
API Guide
Architecture overview
WASM Player is meant to be used in Tizen TV widget applications that employ WebAssembly modules. Tizen TV widget applications work in HTML5 environment: WASM Player provides an ElementaryMediaStreamSource
component that is designed to be used as a source object of HTMLMediaElement.

Figure: WASM Player Architecture Overview.
In order to use Media Player with WASM Player, App should use classes it provides (which act as a source of data for playback) and the HTMLMediaElement
class (to control Media Player). Class responsibilities and functions are as follow:
Class | Description |
---|---|
|
This is the main class of Tizen WASM Player. It acts as a source object of HTMLMediaElement .
|
ElementaryMediaTrack |
Each instance of this class represents a single elementary media track (either audio or video). The track object allows sending Elementary Stream Packet data to Platform for a playback. |
HTMLMediaElement |
Relevant part of HTMLMediaElement API is wrapped by a C++ API available alongside WebAssembly EMSS C++ API.
|
Relation between ElementaryMediaStreamSource and HTMLMediaElement
Please note that ElementaryMediaStreamSource
and HTMLMediaElement
serve different purpose in Media Player. As shown above, Elementary Media Stream Source objects act as a mean to deliver media data to HTMLMediaElement
for playback. Controlling playback (e.g. issuing Play, Pause, Seeking, etc.) on Media Player is done via HTMLMediaElement
API. Elementary Media Stream Source allows to deliver media data in form of Elementary Media Packets.
When operating Media Player, App should rely on HTMLMediaElement
events and methods. For example, ElementaryMediaStreamSource
signals when Media Player requires media data. However, the moment Media Player starts reading media data is not always the very same moment a playback can be started. Readiness for playback is signalized by HTMLMediaElement
by the means of HTMLMediaElementListener::OnCanPlay()
event.
ElementaryMediaStreamSource's states

Figure: ElementaryMediaStreamSource state diagram.
Ready State | Description |
---|---|
kDetached |
This is an initial state of |
kClosed |
Tracks are not configured and player is not initialized. Can't play in this state.
This state is entered after |
kOpen |
Media Player is fully initialized and Elementary Media Stream Source is ready to accept Elementary Packet Data from App via When App finishes configuring Tracks, it can request entering this state. Open state is entered when possible. Some operations (like Seek) trigger a temporary transition to |
kOpenPending |
Opening This is a temporary state, entered on several occasions:
|
kEnded |
Stream has ended but multimedia pipeline remains initialized. This state is entered when App marks active |
Important
ElementaryMediaStreamSource
's andHTMLMediaElement
's states should not be confused.ElementaryMediaStreamSource
represents state of a source of data, whileHTMLMediaElement
represents state of a multimedia player. As such,ElementaryMediaStreamSource
signals App whether or not multimedia pipeline needs data and can accept Elementary Media Packets. This is not in sync with multimedia player's state.For example, the
kEnded
state can be associated with a still-playing Media Element. This occurs in Normal Latency mode when App signals end of all tracks but multimedia pipeline has buffered Elementary Media Packets remaining to play.
The kOpen state and Latency Modes
Depending on the Latency Mode the ElementaryMediaStreamSource
's preconditions for entering the kOpen
state are slightly different.
- In Normal Latency mode, requesting
ElementaryMediaStreamSource
to open initializes Media Player and immediately triggers it's data buffering mechanism. Therefore, Elementary Media Stream Source enters thekOpen
state shortly after open is requested (briefly entering thekOpenPending
state during initialization). As soon as thekOpen
state is entered the App is expected to send media data to EMSS. - In Low Latency mode, requesting
ElementaryMediaStreamSource
to open puts it in thekOpenPending
state and initializes Media Player. ThekOpen
state (where App is expected to send media data to EMSS) is entered when Play is issued onHTMLMediaElement
. Source remains open as long as Media Element is in playing state. Media Player renders any Elementary Media Packets immediately after they are sent, with no intermediate buffering.
Note
There is a number of reasons for EMSS to switch between states. Usage Guide provides detailed information on when such a change happens.
ElementaryMediaTrack's states
ElementaryMediaTrack
state reflects that of an associated ElementaryMediaStreamSource
, however in a simplified manner. Track can be either open or closed, represented by a single boolean attribute.
IsOpen | Description |
---|---|
true | Track can accept Elementary Media Packets. Track opens just before Source enters the |
false | Track can't accept Elementary Media Packets. Track closes just after Source leaves the |
Note
When track closes, an event is generated carrying a reason why close occurred. Possible reasons can be checked here.
HTMLMediaElement's states
C++ HTMLMediaElement
class supplied with Elementary Media Stream Source is a wrapper for a HTML5's HTMLMediaElement
. Please refer to HTML Media Element Specification for information on HTMLMediaElement
's states.
WASM Player and App Multitasking
App that targets Tizen Smart TV work in a multitasking environment and must respond to multitasking appropriately. For a multimedia application this often means it have to suspend media playback when the application becomes invisible (e.g. goes into background when user launches another application) and resume playback when the application becomes visible (e.g. goes into foreground when user resumes App).
WASM Player tracks an application's multitasking state and generates appropriate events for App to react to. Specifics of event sequence depends on a selected EMSS mode of operation.
Note
- For more details on supporting Multitasking see Usage Guide.
- For more details on Multitasking on Tizen TV see SmartTV Widget Multitasking Guide.
Supported media formats
Please refer to SmartTV Media Specifications for information on supported codecs and configurations.