This guide walks through integration with Chromecast to collect video performance metrics with Mux data.
Mux Data is the best way to monitor video streaming performance.
Integration is easy - just initialize the Mux SDK, pass in some metadata, and you're up and running in minutes.
This documents integration instructions for Chromecast. For other players, see the additional Integration Guides.
The following data can be collected by the Mux Data SDK when you use the Chromecast SDK, as described below.
Supported Features:
renditionchange
eventsAverage Bitrate metrics available in v4.2.11 and newer.
Mux supports Chromecast applications that are built on top of the Cast Application Framework CAF Receiver SDK. The CAF Receiver SDK supports the following streaming protocols.
A Chromecast application contains two main components: a sender and a receiver. The Mux Data SDK is integrated at the receiver side; include the chromecast-mux.js
JavaScript file within your custom receiver application. You can use the Mux-hosted version of the script to receive automatic updates. (The API will not change within major versions, as in chromecast/MAJOR_VERSION/chromecast-mux.js
).
npm install --save @mux/mux-data-chromecast
Get your ENV_KEY
from the Mux environments dashboard.
Env Key is different than your API token
ENV_KEY
is a client-side key used for Mux Data monitoring. These are not to be confused with API tokens which are created in the admin settings dashboard and meant to access the Mux API from a trusted server.
To monitor video playback within your Chromecast application, pass the PlayerManager
instance to initChromecastMux
along with SDK options and metadata.
You can initialize within a message interceptor for the LOAD
event, or immediately on app load as before. This suggestion changed in version 4.0.0 and newer.
import initChromecastMux from '@mux/mux-data-chromecast';
var app = {
init: function () {
const context = cast.framework.CastReceiverContext.getInstance();
const playerManager = context.getPlayerManager();
let firstPlay = true;
let playerInitTime = initChromecastMux.utils.now();
playerManager.setMessageInterceptor(cast.framework.messages.MessageType.LOAD, loadRequestData => {
if (firstPlay) {
initChromecastMux(playerManager, {
debug: false,
data : {
env_key: 'ENV_KEY', // required
// Metadata
player_name: 'Custom Player', // ex: 'My Main Player'
player_init_time: playerInitTime,
// ... additional metadata
}
});
}
return loadRequestData;
});
context.start();
}
};
$(document).ready(function () {
app.init();
});
After you've finished integration, the quickest way to see that the SDK is loaded is to pass debug: true
in the options passed to the SDK. With this flag enabled, you can open the debug console, and you should start seeing debug statements from [mux] when you click play on the video.
After playing a video, a few minutes after you stop watching, you'll see the results in your Mux account. We'll also email you when your first video view has been recorded. Log in to the dashboard and find the environment that corresponds to your env_key and look for video views.
Note that it may take a few minutes for views to show up in the Mux Data dashboard.
Options are provided via the data
object passed in the call to initChromecastMux
.
All metadata details except for env_key
are optional, however you'll be able to compare and see more interesting results as you include more details. This gives you more metrics and metadata about video streaming, and allows you to search and filter on important fields like the player version, CDN, and video title.
For more information, see the Metadata Guide.
If your application plays multiple videos back-to-back in the same video player, you need to signal when a new video starts to the Mux SDK. Examples of when this is needed are:
In order to signal the Mux SDK that a new view is starting, you will need to emit a videochange
event through the player, along with new metadata about the video (i.e. any of the [For more information, see the Metadata that starts with video_
).
This should be done by intercepting the cast.framework.messages.MessageType.LOAD
message and doing the following:
playerManager.setMessageInterceptor(cast.framework.messages.MessageType.LOAD, loadRequestData => {
// It's important to only call this on subsequent videos being loaded, not
// the first playback (where you call `initChromecastMux`).
if (!firstVideo) {
playerManager.mux.emit('videochange', { ... });
}
return loadRequestData;
});
It's best to change the video info immediately after telling the player which new source to play.
Errors are fatal
Errors tracked by mux are considered fatal meaning that they are the result of playback failures. If errors are non-fatal they should not be captured.
By default, @mux/mux-data-chromecast
will track errors emitted from the video element as fatal errors. If a fatal error happens outside of the context of the player, you can emit a custom error to the mux monitor.
playerManager.mux.emit('error', {
player_error_code: 100,
player_error_message: 'Description of error',
player_error_context: 'Additional context for the error'
});
When triggering an error event, it is important to provide values for player_error_code
and player_error_message
. The player_error_message
should provide a generalized description of the error as it happened. The player_error_code
must be an integer, and should provide a category of the error. If the errors match up with the HTML Media Element Error, you can use the same codes as the corresponding HTML errors. However, for custom errors, you should choose a number greater than or equal to 100
.
In general you should not send a distinct code for each possible error message, but rather group similar errors under the same code. For instance, if your library has two different conditions for network errors, both should have the same player_error_code
but different messages.
The error message and code are combined together and aggregated with all errors that occur in your environment in order to find the most common errors that occur. To make error aggregation as useful as possible, these values should be general enough to provide useful information but not specific to each individual error (such as stack trace).
You can use player_error_context
to provide instance-specific information derived from the error such as stack trace or segment-ids where an error occurred. This value is not aggregated with other errors and can be used to provide detailed information. Note: Please do not include any personally identifiable information from the viewer in this data.
If your player emits error events that are not fatal to playback or the errors are unclear and/or do not have helpful information in the default error message and codes you might find it helpful to use an error translator or disable automatic error tracking all together.
function errorTranslator (error) {
return {
player_error_code: translateCode(error.player_error_code),
player_error_message: translateMessage(error.player_error_message),
player_error_context: translateContext(error.player_error_context)
};
}
initChromecastMux(playerManager, {
debug: false,
errorTranslator: errorTranslator,
data : {
env_key: 'ENV_KEY', // required
// Metadata
player_name: 'Custom Player', // ex: 'My Main Player'
// ... additional metadata
}
});
If you return false
from your errorTranslator
function then the error will not be tracked. Do this for non-fatal errors that you want to ignore. If your errorTranslator
function itself raises an error, then it will be silenced and the player's original error will be used.
In the case that you want full control over what errors are counted as fatal or not, you may want to consider turning off Mux's automatic error tracking completely. This can be done by passing automaticErrorTracking: false
in the configuration object.
initChromecastMux(playerManager, {
debug: false,
automaticErrorTracking: false,
data : {
env_key: 'ENV_KEY', // required
// Metadata
player_name: 'Custom Player', // ex: 'My Main Player'
// ... additional metadata
}
});
If you have integrated a custom domain for Data collection, specify your custom domain by setting beaconCollectionDomain
.
initChromecastMux(playerManager, {
debug: false,
beaconCollectionDomain: 'CUSTOM_DOMAIN', // ex: 'foo.bar.com'
data: {
env_key: "ENV_KEY",
// ...
}
});
There are certain use cases where you want to stop monitoring playback within a player (for instance if the player is no longer being used, you are recycling players, or you are shutting down the application). In this case, you should make sure to destroy the monitor. This can be done by simply calling playerManager.mux.destroy()
.
mux-embed
to v5.3.0mux-embed
to v5.2.1mux-embed
to v5.2.0Target ES5 for bundles and validate bundles are ES5
Update mux-embed
to v5.1.0
TypeScript type changes only.
Update mux-embed
to v5.0.0
mux-embed
to v4.30.0mux-embed
to v4.29.0mux-embed
to v4.28.1mux-embed
to v4.28.0fix an issue where seek latency could be unexpectedly large
fix an issue where seek latency does not include time at end of a view
Update mux-embed
to v4.27.0
mux-embed
to v4.26.0mux-embed
to v4.25.1mux-embed
to v4.25.0Fix an issue where beacons over a certain size could get hung and not be sent
Update mux-embed
to v4.24.0
Fix an issue where tracking rebuffering can get into an infinite loop
Update mux-embed
to v4.23.0
fix an issue where retrieving ad information on chromecast can throw an exception
Update mux-embed
to v4.22.0
Include Ad metadata in ad events
Update mux-embed
to v4.21.0
Update mux-embed
to v4.20.0
mux-embed
to v4.19.0mux-embed
to v4.18.0Support player_error_context
in errorTranslator
Update mux-embed
to v4.17.0
Adds support for new and updated fields: renditionchange
, error, DRM type, dropped frames, and new custom fields
Update mux-embed
to v4.16.0
Expose utils
on SDK initialization function to expose utils.now()
for player_init_time
Update mux-embed
to v4.15.0
mux-embed
to v4.14.0mux-embed
to v4.13.4mux-embed
to v4.13.3mux-embed
to v4.13.2mux-embed
to v4.13.1Upgraded internal webpack version
Improve Chromecast rebuffering metrics
Update mux-embed
to v4.13.0
mux-embed
to v4.12.1mux-embed
to v4.12.0mux-embed
to v4.11.0renditionchange
with the new bitratemux-embed
to v4.10.0mux-embed
to v4.9.4mux-embed
to v4.9.3mux-embed
to v4.9.2mux-embed
to v4.9.1mux-embed
to v4.9.0mux-embed
to v4.8.0mux-embed
to v4.7.0mux-embed
to v4.6.2mux-embed
to v4.6.1player.mux.destroy()
would raise an exception if called without any parameters.mux-embed
to v4.2.0programchange
may not have been tracked correctlydestroy
was called multiple times, it would raise an exceptionvideochange
events to signal a change. This should be done inside an interceptor for the LOAD
event.ended
events were sent at the wrong time.STOPPED
event.player_remote_played
was not functioning. This value defaults to true
if not setvideo_source_url
is detectedvideochange
detection to false - this can still be enabled if requiredplayerManager.mux.destroy()
to stop monitoring the player instance.