Welcome to the new Mux Docs (currently in beta). The old version is still available here
- Introduction to Data
- Track your video performance
- Setup alerts
- Make your data actionable with Metadata
- Track autoplaying videos
- Track CDN for request metrics
- Build a custom integration
- Understand metric definitions
- Export raw video view data
- Mux Data FAQs
Build a Custom Integration
If Mux does not have an SDK specific to your player, you may want to build a custom integration.
Mux Data SDKs operate by tracking the playback events that occur through the idea of a
Player. To Mux, a
Player is an object that encapsulates the playback of videos, exposing APIs for playback events and retrieving playback state information.
In most cases, the
Player is a single object exposed by the player technology. For instance, for our Video.js integration (videojs-mux), the
Player is just the Video.js Player object. However, in some scenarios, there may be one or more underlying player instances that are unified through a single composite API/object. In these cases, the
Player would be that higher-level object.
There are three major steps for building an integration for a
- Initialize a monitor for the
Playerthat is being tracked.
- Provide a set of callbacks for the core SDK to retrieve player/device information
- Emit events for each of the important playback events.
The core SDKs share the above common architecture, but there are differences driven primarily by each programming language. The individual documentation for each will describe the exact steps for integration:
- Java - Building a custom Integration
- Objective-C - Building a custom Integration
Read on for an overview of each of these steps.
Because each core SDK supports the idea of tracking multiple
Players (for instance, if more than one video is being played in the same view/web page), each each
Player must be identifiable with a unique ID. This ID is used when initializing the monitor, as well as when emitting events to the core SDK.
The first step that a custom integration must do is initialize a monitor for the
Player. This is done differently for each core SDK, but the goal is just to allow the core library to prepare the state necessary for tracking a
In this step, some information must be provided:
- some integration-specific metadata
- methods to retrieve information from the
Player(more on this in a later section)
When initializing a monitor for a
Player, metadata about the integration itself should be passed. The possible fields that should be passed are the following (all are strings):
player_software: the name of the underlying player software (i.e. 'Video.js')
player_software_version: the version of this player software
player_mux_plugin_name: the name of the plugin
player_mux_plugin_version: the version of the plugin
To ease the burden of sending a lot of data with each event that is emitted, the Mux core SDKs accept callbacks that allow the core to retrieve information from the player when necessary. The callbacks required differ by core SDK, so read the appropriate section for the core SDK that you are developing with:
The majority of the work in an integration is creating and emitting the specific playback events as playback occurs. Most players have a concept of
events such as
error, and others, but these events are often named differently depending on the player in use. The Mux core SDKs expect events named in a consistent manner, as defined in Mux Playback Events.
Each core SDK has a different mechanism for emitting these events, so read the appropriate section for the core SDKK that you are developing with: