Ashley Huynh

Nostalgic beginnings

Growing up, keeping a diary or journal was as necessary to me as breathing air. I felt as though I had to document my life and all of the changes I was experiencing (and as a teenager, it constantly felt like the Worst Thing Ever could happen any given week).

Although Mux has no journals or diaries to capture its teenage angst years, we do have a lot of changes that happen within our products from week to week. Whether it’s adding a parameter to get more specialized information with Mux Data or updating our Ruby SDK to fix a buggy function, we’re always looking for ideas on how to improve our products, and those ideas turn into real-life changes. As such, having a tool that documents changes within our products is imperative to make those changes transparent and easily accessible for anyone who might need them.

We’re excited to announce that we’ve introduced a changelog as a way for you to keep track of changes to Mux’s products, when those changes are made, and how they might affect your user experience. The changelog captures all updates and releases to Mux products from December 1, 2021 onwards. This post will dive into our process and the considerations we took to build an informative and thoughtful changelog experience.

What makes a great changelog?

Have you ever scrolled through a feed trying to track down one post you saw in passing, before finally giving up and closing the app in frustration? Or maybe you’ve read an email with a big announcement in it, but the message was so long that you lost track of what was actually happening?

If you answered yes to any of the above, then you already understand the basics of what makes a great changelog.

In our research on what constitutes a positive and effective changelog experience, we landed on the following areas of focus:

Discoverability: The ability to search and filter posts in the changelog will allow users to access the information they need when they need it. Searching and filtering are especially helpful for users who only use certain Mux products or who want to look at specific types of changes, such as bug fixes or deprecations.

Easy to read: Our changelog will serve as a valuable piece of documentation and a source of truth for everyone who uses our products, whether internally or externally. It needs to be clear and concise, with minimal jargon.

Streamlined internal process for surfacing items on the changelog: One of our company values is “bias for action.” With that in mind, we wanted our changelog to be crowdsourced, where anyone from any team in the company could feel empowered to submit an entry. This accessibility is important to ensure we’re being transparent internally as well as externally. We developed an internal process that provides assistance through reviewing and publishing, so people submitting to the changelog can make sure their entries are successfully shipped.

Keeping users informed through subscriptions: With frequent updates, it’s important to keep users informed early and often. To that end, we’ve also made the changelog available as an RSS feed.

Trackable: Having a changelog that records analytics and insights will allow us to build on previous changes and make sure we continue offering the best experience possible. With all the considerations above, there’s always room for improvement, and metrics will be a valuable gauge of where we can make the changelog better.

To summarize, changelogs are for people. We want to make it as easy as possible for people to contribute to the changelog, read the information, and keep track of updates as they come.

To maximize this ease of use and accessibility, we had to define what types of changes should go into the changelog and what those posts should look like. Setting those guidelines was a priority from early in the project to ensure that the scope of the changelog was understood and clearly defined across the company.

Where should our changelog live?

While hashing out the details for our changelog, one of the first questions that came up was where the changelog should live: Should we put it on our primary site, like the blog? Should we host it in our Docs site, where we put our guide and reference materials?

In the end, we decided it would make the most sense to host it in our Docs; users of our products are more likely to stop by the Docs site to seek out information, and the changelog should be integrated with those resources. The final changelog URL is docs.mux.com/changelog—an intuitive extension of our current navigation structure on the Docs site that’s easy to remember and allows for quick navigation.

To increase discoverability and access, we also considered common URLs that users might attempt when trying to navigate to the changelog. We found that the URLs “changelog.mux.com” and “mux.com/changelog” came up often in our discussions, so we’ve redirected each of those URLs to “docs.mux.com/changelog”.

We’ve also added direct access points to the changelog within our primary site—you can find them within our site header and footer under “Docs & Tools.”

What changes should we address in the changelog?

Another question we needed to answer was what changes we should include in the changelog. We anticipated the changelog would capture a variety of changes across different products, so it was important to establish uniform criteria that internal submitters could follow.

We decided that it was important to include the following:

Major product releases, which normally encompass an update to the API, some new docs or guides, and potentially some SDK version updates

API changes, such as modifying or deprecating parameters, queries, or endpoints

New API and Data SDK version releases

Any limits or rate limit–related changes, for the API or otherwise

Pricing changes

New docs or guides

Bug fixes, especially for bugs that affect the user experience

There will also be changes that fall outside these categories. For those scenarios, we have created an easily discoverable and accessible internal Slack channel where people can bring their questions and get general opinions on whether their change should be included in the changelog.

What information should be in a changelog post?

When considering what changelog posts should look like, we decided to develop a Changelog Style Guide to create some basic standards around voice, writing tenses and point of view, and formatting to make sure all entries are consistent.

Having the style guide is especially useful for our internal mission of making submitting entries to the changelog as accessible as possible: anyone across the company, from product managers to community managers, can access the same set of guidelines and expectations for what a changelog entry should look like.

We’ve also included guidance on organizing entries hierarchically, from most to least important information, with an emphasis on keeping things clear and concise. Each changelog entry should briefly answer the following questions:

What change was made?

What product(s), software, or feature(s) does this change impact? How will this change affect the specified product(s), software, or feature(s)?

What is the severity of this change (if applicable)?

Are there any important dates related to this change (e.g., a deprecation date for a deprecated change)?

Are there any actions a user can take to adapt to the change?

Changelog submitters are also encouraged to utilize links as much as possible to connect users to guides, blog posts, or docs for more in-depth context where necessary.

So log and thanks for all the changes

The changelog is an exciting update to our Docs to capture and raise awareness of changes that happen throughout our products.

We’re always looking for ways to improve the developer experience, and the changelog is a big part of our journey. It’s a valuable tool and resource for our employees and our users that increases transparency and can save hours of development time. Additionally, by highlighting our experiences and our thought process for developing Mux’s changelog, we hope we can help other companies and products looking to build something similar.

We’d love to hear about your experiences with our changelog! Let us know if you have any feedback by sending an email to changelog@mux.com. While we already have some exciting new feature additions planned for the changelog, your insight is invaluable as we shape current and future updates to create the best developer experience possible!

Growing up, keeping a diary or journal was as necessary to me as breathing air. I felt as though I 

to document my life and all of the changes I was experiencing (and as a teenager, it constantly felt like the Worst Thing Ever could happen any given week).

GIF saying "Teen angst - our greatest foe."

Although Mux has no journals or diaries to capture its teenage angst years, we do have a 

of changes that happen within our products from week to week. Whether it’s adding a parameter to get more specialized information with Mux Data or updating our Ruby SDK to fix a buggy function, we’re always looking for ideas on how to improve our products, and those ideas turn into real-life changes. As such, having a tool that documents changes within our products is imperative to make those changes transparent and easily accessible for anyone who might need them.

We’re excited to announce that we’ve introduced a 

 as a way for you to keep track of changes to Mux’s products, when those changes are made, and how they might affect your user experience. The changelog captures all updates and releases to Mux products from December 1, 2021 onwards. This post will dive into our process and the considerations we took to build an informative and thoughtful changelog experience.

Have you ever scrolled through a feed trying to track down one post you saw in passing, before finally giving up and closing the app in frustration? Or maybe you’ve read an email with a big announcement in it, but the message was so long that you lost track of what was actually happening?

If you answered yes to any of the above, then you already understand the basics of what makes a great changelog.

In our research on what constitutes a positive and effective changelog experience, we landed on the following areas of focus:

: The ability to search and filter posts in the changelog will allow users to access the information they need when they need it. Searching and filtering are especially helpful for users who only use certain Mux products or who want to look at specific types of changes, such as bug fixes or deprecations.

Our changelog will serve as a valuable piece of documentation and a source of truth for everyone who uses our products, whether internally or externally. It needs to be clear and concise, with minimal jargon.

Streamlined internal process for surfacing items on the changelog:

 One of our company values is “bias for action.” With that in mind, we wanted our changelog to be crowdsourced, where anyone from any team in the company could feel empowered to submit an entry. This accessibility is important to ensure we’re being transparent internally as well as externally. We developed an internal process that provides assistance through reviewing and publishing, so people submitting to the changelog can make sure their entries are successfully shipped.

Keeping users informed through subscriptions: 

With frequent updates, it’s important to keep users informed early and often. To that end, we’ve also made the changelog available as an RSS feed.

Having a changelog that records analytics and insights will allow us to build on previous changes and make sure we continue offering the best experience possible. With all the considerations above, there’s always room for improvement, and metrics will be a valuable gauge of where we can make the changelog better.

. We want to make it as easy as possible for people to contribute to the changelog, read the information, and keep track of updates as they come.

To maximize this ease of use and accessibility, we had to define what types of changes should go into the changelog and what those posts should look like. Setting those guidelines was a priority from early in the project to ensure that the scope of the changelog was understood and clearly defined across the company.

While hashing out the details for our changelog, one of the first questions that came up was where the changelog should live: Should we put it on our 

, like the blog? Should we host it in our 

, where we put our guide and reference materials?

In the end, we decided it would make the most sense to host it in our Docs; users of our products are more likely to stop by the Docs site to seek out information, and the changelog should be integrated with those resources. The final changelog URL is 

—an intuitive extension of our current navigation structure on the Docs site that’s easy to remember and allows for quick navigation.

To increase discoverability and access, we also considered common URLs that users might attempt when trying to navigate to the changelog. We found that the URLs “changelog.mux.com” and “mux.com/changelog” came up often in our discussions, so we’ve redirected each of those URLs to “docs.mux.com/changelog”.

We’ve also added direct access points to the changelog within our primary site—you can find them within our site header and footer under “Docs & Tools.”

What changes should we address in the changelog?

Another question we needed to answer was what changes we should include in the changelog. We anticipated the changelog would capture a variety of changes across different products, so it was important to establish uniform criteria that internal submitters could follow.

We decided that it was important to include the following:

Major product releases, which normally encompass an update to the API, some new docs or guides, and potentially some SDK version updates

API changes, such as modifying or deprecating parameters, queries, or endpoints

Any limits or rate limit–related changes, for the API or otherwise

Bug fixes, especially for bugs that affect the user experience

There will also be changes that fall outside these categories. For those scenarios, we have created an easily discoverable and accessible internal Slack channel where people can bring their questions and get general opinions on whether their change should be included in the changelog.

What information should be in a changelog post?

When considering what changelog posts should look like, we decided to develop a Changelog Style Guide to create some basic standards around voice, writing tenses and point of view, and formatting to make sure all entries are consistent.

Having the style guide is especially useful for our internal mission of making submitting entries to the changelog as accessible as possible: anyone across the company, from product managers to community managers, can access the same set of guidelines and expectations for what a changelog entry should look like.

We’ve also included guidance on organizing entries hierarchically, from most to least important information, with an emphasis on keeping things clear and concise. Each changelog entry should briefly answer the following questions:

What product(s), software, or feature(s) does this change impact? How will this change affect the specified product(s), software, or feature(s)?

What is the severity of this change (if applicable)?

Are there any important dates related to this change (e.g., a deprecation date for a deprecated change)?

Are there any actions a user can take to adapt to the change?

Changelog submitters are also encouraged to utilize links as much as possible to connect users to guides, blog posts, or docs for more in-depth context where necessary.

 is an exciting update to our Docs to capture and raise awareness of changes that happen throughout our products.

We’re always looking for ways to improve the developer experience, and the changelog is a big part of our journey. It’s a valuable tool and resource for our employees and our users that increases transparency and can save hours of development time. Additionally, by highlighting our experiences and our thought process for developing Mux’s changelog, we hope we can help other companies and products looking to build something similar.

We’d love to hear about your experiences with our changelog! Let us know if you have any feedback by sending an email to 

. While we already have some exciting new feature additions planned for the changelog, your insight is invaluable as we shape current and future updates to create the best developer experience possible!

Open diary with teen angst phrases written in it

We’re excited to announce that we’ve introduced a changelog as a way for you to keep track of changes to Mux’s products, when those changes are made, and how they might affect your user experience.

Introducing the Mux Changelog

In a time of never-ending news feeds and a 24-hour meme cycle, online video is becoming increasingly more collaborative, co-operative, and community-oriented. In this guide, we’ll discuss the power of surfacing real-time views and unique viewer stats in your application using Mux Data’s Real-Time Engagement Counts API, and show how to create a simple React application to accomplish this.

Real-time view and unique viewer counts are the active heartbeat of video performance, and are vital to connecting viewers to video experiences, and ensuring those experiences are delightful and consistent. We recently launched a new API in Mux Data that gives developers access to that real time data, and it’s now available as a public beta to all Mux Data users!

These counts can be used to surface the stats for the audience of a video (e.g., showing live audience counts to enrich the experience for fans during a concert) or to provide internal visibility of metrics (e.g., a live streaming company pushing metrics to an instructor during a live stream so they can better understand audience engagement).

In regards to real-time stats, “views” are defined as the number of views that are currently happening, while “unique viewers” reflects the number of unique viewers across those active views. Each unique viewer is only counted once, even if they are watching from multiple screens at the same time.



Let’s start building!

Let’s get started by building a simple React application to surface real-time view and unique viewer counts! Before getting started, you will need to have the following items set up:

Have yarn installed on your machine--for more information on installing yarn, you can view the Installation Guide

Sign up for a free Mux account here (or log in if you already have one)

Have an example video you’d like to use in your app

Have a hosted link so you can embed the video

If you’re just hacking together something quick, you can also use our sample video: https://muxed.s3.amazonaws.com/leds.mp4

Note: the use of real-time metrics will work with any Mux Data integration and does not require Mux Video or the full setup described for this application. If you already have a video set up with Mux Data in an application, you can skip to step #6 in the guide or check out the See how many people are watching guide.



1. Set up a React application

React is a JavaScript library created by Facebook that enables the creation of interactive UIs. To quickly set up a React application, you’ll utilize create-react-app. Run the following commands to install the package and initialize a React project in a new project directory, then go into the directory and start up the app in development mode (once started up, the app will be able to be viewed at http://localhost:3000):

If you have any issues with these commands, visit the Getting Started guide for help with troubleshooting.



2. Get started with Mux Video

In order to add your video to your application and prepare it for playback, you’ll need to upload it into Mux as an asset. Once you have a hosted URL for a video file and a Mux account, you can get started with the Video API.

Follow steps 1–3 of the Stream Video Files guide, where you’ll cover retrieving an API access token from your Mux account, submitting a POST request to upload the video as an asset, and waiting for the video to download and process. As you follow along, please note the following:

When generating the API access token in step #1, check all permissions provided (Mux Video, Mux Data, and System) to ensure you have the right permissions to generate a signing key using the System API in a later portion of the tutorial:

Due to the nature of this project, it’s recommended to use cURL or a GUI such as Insomnia or Postman to run the API request for step #3.

Hold on to your PLAYBACK_ID, MUX_TOKEN_ID, and MUX_TOKEN_SECRET because you’ll need these later!



3. Create a VideoPlayer component

Once the video has been successfully uploaded as an asset and the status is marked as "ready," you’ll need to embed the video you just uploaded into the React application.

To confirm whether the video is ready, check that the asset appears with the "ready" status in your Mux Account Dashboard > /Video > Assets.

For easy embedding and configuration with Mux Video and Mux Data, you can utilize the mux-video package. Install it by running the following command:

Once installed, create a new file for your VideoPlayer component in src called VideoPlayer.js. Add the following into the file:

The PLAYBACK_ID will be pulled from your video asset from step 2. You can find your ENV_KEY in the Mux Environments dashboard for the environment you generated your access token with:

Please note: The ENV_KEY is different from your API token. The  ENV_KEY is a client-side key used for Mux Data monitoring.

To verify correct setup of Mux Data, watch your video a few times via your app, then check out the Metrics (via Mux Account Dashboard > /Data > Metrics) to see if those new views show up. For Mux Video users, you can also see your views show up in real-time on the Assets page for the video you’re using.



4. Add your VideoPlayer component to your App.js to surface it

Right now, when you navigate to http://localhost:3000/, you’ll see this view:

In order to display the newly created VideoPlayer component, you’ll need to adjust the src/App.js file in your React project to import the VideoPlayer component you created in the previous step, and surface it within the App:

Your video should now surface when you navigate to http://localhost:3000:



5. Keep track of viewers and surface them in the UI

At this point, you have a simple React app with a video displaying alongside Mux Data to keep track of video metrics and performance.

Since the desired goal for the app is to surface real-time views and unique viewers in the video player, the next steps would be to add variables to surface the view and unique viewer counts, and also to adjust the current templating of how the video is surfaced in the VideoPlayer component to accommodate a text overlay which can display the desired metrics.

React's State Hook is a perfect candidate to keep track of real-time views and unique viewers and live update the state variables even when they’re surfaced in the UI. To use the State Hook, adjust the react import statement at the top of VideoPlayer.js to include useState:

Once imported, you can initialize state variables to keep track of view and unique viewer counts. Within the VideoPlayer component, right after the export default function VideoPlayer() { line, initialize two state variables, one for each metric. Since each variable is meant to hold an integer count, each variable can be initialized with an initial value of 0.

For each state variable initialized in the example above, the first parameter will be the actual reference name used to retrieve the current variable value, while the second parameter will be the function used to set or update the value of the variable.

Now that the state variables have been initialized, the work to adjust the templating and add the overlay count can begin.

Adjust the return statement in VideoPlayer so that the video is wrapped in a div with a className called video-container. Then, create a div called video-overlay within the video-container. In video-overlay, two text values will be surfaced: one that shows the viewCount state variable, and another that shows the viewerCount state variable.

After adding in the div containers needed for the overlay effect, create a new file in src called VideoPlayer.css to style the outer video container and position the contents of the video-overlay div over it. The VideoPlayer.css file will look like this:

Lastly, import the CSS styling in for the VideoPlayer component by adding the following as an import statement at the top of the file:

Once that’s been added in, you should see an overlay on your video player when visiting http://localhost:3000:



6. Set up your JSON Web Token

Once everything in the application is ready to surface information, you can work on retrieving information from the Real-time Engagement Counts API to pull the desired views and unique viewers. In order to use this API, you’ll need a JSON Web Token (JWT).

In order to generate the JWT, you’ll need to create a signing key for the Data product. You can do this either in the UI here or through a POST request utilizing your MUX_TOKEN_ID and MUX_TOKEN_SECRET:

Once the POST request has been run, this is the expected response:

For generating your signing key in either the UI or via API request, you’ll receive a base64-encoded private_key and a signing key id. Copy and save both of these somewhere.

Once the keys have been generated, create a JSON Web Token. In order to do this, install the base64url package to decode your private key to successfully pass it in to your JWT, and install jsonwebtoken to be able to create and sign your JWT:

Aside from your private signing key and signing key ID, you’ll also need your playback ID from step #2. Using these items, you can now implement a script to be able to easily generate JWTs and log them to your terminal or console. Create a new file in src within your project called jwt.js, then add in the following code:


To run the above script, run the following command in your project’s root directory:

This will output a JWT that you’ll be able to use to make API calls. Keep this JWT somewhere to be able to reference it for the next step.

For a more in-depth tutorial of using the Real-time Engagement Counts API, if you’d rather use another identifier for your video such as asset_id or live_stream_id, or if you run into any issues with these instructions, please check out the See how many people are watching guide.



7. Test your JWT

With the token ready to go, let’s test out the API! Run the following request and plug in your JWT generated in the previous step:

Since there are currently no views, you can expect to get something back like:

In order to ensure you’re pulling in the right live data, test out live views by opening http://localhost:3000 in several browser windows and emulating live video plays, then running the above command to see if it reports these live views. You can also compare the viewer metrics from the Real-time Dashboard (via Mux Account Dashboard > /Data > Real Time) to verify if you’re getting the correct results and the right view and viewer counts.



8. Set up the useInterval hook to make a recurring API call and update the view and viewer counts

Once you verify that you have access to your real-time view and unique viewer counts via an API call, you can now plug that information into your application. To add in the API call to the VideoPlayer component, create an async function, getData(), which will make the API call and then set the view and unique viewer counts based on the data returned from the request:

Note: the JWT is being embedded directly into the request URL for demo purposes. If you’re looking to use this for a non-demo or client-facing application, please consider making the JWT an environment variable for an additional layer of security.

Since real-time counts happen very quickly and are extremely dynamic, the useInterval hook will come in handy to call getData() at frequently specified intervals (please note: Realtime Data APIs are rate limited to one request per second). You can install the library needed to use this hook by running the following command:

Once installed, import the useInterval hook in VideoPlayer.js:

The useInterval hook requires a function body with code it will execute as its first parameter, and a specified interval of time (in milliseconds) between function calls. A successfully executed useInterval hook that calls getData() every 15 seconds will look like this:

Once the useInterval hook has been implemented, your app is ready to surface real-time view and unique viewer counts in the player!



Conclusion

Data is important for all video pursuits, big and small. However, before you try to use your data to tell a bigger story, you may want to look at whether your videos are gaining traction with your audience by focusing on the basics like real-time view and viewer counts. We hope that providing the ability to easily surface these metrics will improve both viewer and monitoring experiences alike!

If you were able to create something cool from this guide or it helped you, please reach out! We’d love to hear how customers are using these tools and what their experiences are with using Mux.

In a time of never-ending news feeds and a 24-hour meme cycle, online video is becoming increasingly more collaborative, co-operative, and community-oriented. In this guide, we’ll discuss the power of surfacing real-time views and unique viewer stats in your application using Mux Data’s Real-Time Engagement Counts API, and show how to create a simple React application to accomplish this.

Real-time view and unique viewer counts are the active heartbeat of video performance, and are vital to connecting viewers to video experiences, and ensuring those experiences are delightful and consistent. We recently launched 

 that gives developers access to that real time data, and it’s now available as a public beta to all Mux Data users!

These counts can be used to surface the stats for the audience of a video (e.g., showing live audience counts to enrich the experience for fans during a concert) or to provide internal visibility of metrics (e.g., a live streaming company pushing metrics to an instructor during a live stream so they can better understand audience engagement).

In regards to real-time stats, “views” are defined as the number of views that are currently happening, while “unique viewers” reflects the number of unique viewers across those active views. Each unique viewer is only counted once, even if they are watching from multiple screens at the same time.

An animated GIF of a video playing where it shows an increasing and decreasing views and unique viewers count

Let’s get started by building a simple React application to surface real-time view and unique viewer counts! Before getting started, you will need to have the following items set up:

Have yarn installed on your machine--for more information on installing yarn, you can view the 

Have an example video you’d like to use in your app

Have a hosted link so you can embed the video

If you’re just hacking together something quick, you can also use our sample video: 

Note: the use of real-time metrics will work with any Mux Data integration and does not require Mux Video or the full setup described for this application. If you already have a video set up with Mux Data in an application, you can skip to step #6 in the guide or check out the 

React is a JavaScript library created by Facebook that enables the creation of interactive UIs. To quickly set up a React application, you’ll utilize 

. Run the following commands to install the package and initialize a React project in a new project directory, then go into the directory and start up the app in development mode (once started up, the app will be able to be viewed at 

$ yarn add create-react-app
$ yarn create react-app desired-app-name
$ cd desired-app-name
$ yarn start


Setting up React w/ Yarn

If you have any issues with these commands, visit the 

In order to add your video to your application and prepare it for playback, you’ll need to upload it into Mux as an asset. Once you have a hosted URL for a video file and a Mux account, you can get started with the Video API.

 guide, where you’ll cover retrieving an API access token from your Mux account, submitting a POST request to upload the video as an asset, and waiting for the video to download and process. As you follow along, please note the following:

When generating the API access token in step #1, check all permissions provided (Mux Video, Mux Data, and System) to ensure you have the right permissions to generate a signing key using the System API in a later portion of the tutorial:

New access token settings with all permissions - Mux Video, Mux Data, and System checked

Due to the nature of this project, it’s recommended to use cURL or a GUI such as Insomnia or Postman to run the API request for step #3.

Once the video has been successfully uploaded as an asset and the status is marked as "ready," you’ll need to embed the video you just uploaded into the React application.

To confirm whether the video is ready, check that the asset appears with the "ready" status in your 

For easy embedding and configuration with Mux Video and Mux Data, you can utilize the 

 package. Install it by running the following command:

Yarn adding @mux-elements/mux-video

Once installed, create a new file for your VideoPlayer component in 

import React from "react";
import '@mux-elements/mux-video';

export default function VideoPlayer () {
    return (
        <mux-video
             controls
             playback-id="${PLAYBACK_ID}"
             env-key="${ENV_KEY}"
             stream-type="vod"
             style={{ width: "100%", maxWidth: "500px" }}
        />
    );
}


VideoPlayer.js

 will be pulled from your video asset from step 2. You can find your 

 for the environment you generated your access token with:

Screenshot showing the Environments Dashboard highlighting where to find the environment key - under Video Views

 is different from your API token. The  

 is a client-side key used for Mux Data monitoring.

To verify correct setup of Mux Data, watch your video a few times via your app, then check out the Metrics (via 

 > /Data > Metrics) to see if those new views show up. For Mux Video users, you can also see your views show up in real-time on the Assets page for the video you’re using.

4. Add your VideoPlayer component to your App.js to surface it

Plain React starter page with React logo and the text "Edit src/Ap.js and save to reload."

In order to display the newly created VideoPlayer component, you’ll need to adjust the 

 file in your React project to import the VideoPlayer component you created in the previous step, and surface it within the App:

import './App.css';
import VideoPlayer from './VideoPlayer.js';

function App() {
    return (
        <div className="App">
        <VideoPlayer />
        </div>
    );
}

export default App;


App.js updated

Your video should now surface when you navigate to 

Screenshot showing the previewed video is now available in the application

5. Keep track of viewers and surface them in the UI

At this point, you have a simple React app with a video displaying alongside Mux Data to keep track of video metrics and performance.

Since the desired goal for the app is to surface real-time views and unique viewers in the video player, the next steps would be to add variables to surface the view and unique viewer counts, and also to adjust the current templating of how the video is surfaced in the VideoPlayer component to accommodate a text overlay which can display the desired metrics.

 is a perfect candidate to keep track of real-time views and unique viewers and live update the state variables even when they’re surfaced in the UI. To use the State Hook, adjust the 

state hook

Once imported, you can initialize state variables to keep track of view and unique viewer counts. Within the VideoPlayer component, right after the 

 line, initialize two state variables, one for each metric. Since each variable is meant to hold an integer count, each variable can be initialized with an initial value of 

export default function VideoPlayer() {
    const [viewCount, setViewCount] = useState(0);
    const [viewerCount, setViewerCount] = useState(0);
    ...


VideoPlayer() state update

For each state variable initialized in the example above, the first parameter will be the actual reference name used to retrieve the current variable value, while the second parameter will be the function used to set or update the value of the variable.

Now that the state variables have been initialized, the work to adjust the templating and add the overlay count can begin.

, two text values will be surfaced: one that shows the 

 state variable, and another that shows the 

return (
    <div className="video-container">
        <div className="video-overlay">
            {"Views: " + viewCount + ", "}
            {"Unique Viewers: " + viewerCount}
        </div>
        <mux-video
            controls
            playback-id=${PLAYBACK_ID}
            env-key=${ENV_KEY}
            stream-type="vod"
            style={{ width: "100%", maxWidth: "500px" }}
        />
    </div>
);


return() with divs

 containers needed for the overlay effect, create a new file in 

 to style the outer video container and position the contents of the 

.video-container {
    display: inline-block;
    position: relative;
}
.video-overlay {
    position: absolute;
    left: 0px;
    top: 0px;
    margin: 10px;
    padding: 5px 5px;
    font-size: 20px;
    font-family: Helvetica;
    color: #FFF;
    background-color: rgba(50, 50, 50, 0.3);
}


VideoPlayer.css

Lastly, import the CSS styling in for the VideoPlayer component by adding the following as an import statement at the top of the file:

import VideoPlayer.css

Once that’s been added in, you should see an overlay on your video player when visiting 

A screenshot showing the video in-app with an overlay that reads - "Views: 0, Unique Viewers: 0"

Once everything in the application is ready to surface information, you can work on retrieving information from the Real-time Engagement Counts API to pull the desired views and unique viewers. In order to use this API, you’ll need a 

In order to generate the JWT, you’ll need to create a signing key for the Data product. You can do this either in the UI 

 or through a POST request utilizing your 

curl -X POST
-H "Content-Type: application/json"
-u ${MUX_TOKEN_ID}:${MUX_TOKEN_SECRET}
'https://api.mux.com/system/v1/signing-keys?product=data'

Signing Key API request

Once the POST request has been run, this is the expected response:

{
    "data": {
        "private_key": "(base64-encoded PEM file with private key)",
        "id": "(unique signing-key identifier)",
        "created_at": "(UNIX Epoch seconds)”
    }
} 

Expected response for signing key API request

For generating your signing key in either the UI or via API request, you’ll receive a base64-encoded 

Once the keys have been generated, create a JSON Web Token. In order to do this, install the 

 package to decode your private key to successfully pass it in to your JWT, and install 

$ yarn add base64url
$ yarn add jsonwebtoken

Yarn adding base64url and jsonwebtoken

Aside from your private signing key and signing key ID, you’ll also need your playback ID from step #2. Using these items, you can now implement a script to be able to easily generate JWTs and log them to your terminal or console. Create a new file in 

jwt.js

To run the above script, run the following command in your project’s root directory:

run jwt.js script

This will output a JWT that you’ll be able to use to make API calls. Keep this JWT somewhere to be able to reference it for the next step.

For a more in-depth tutorial of using the Real-time Engagement Counts API, if you’d rather use another identifier for your video such as 

, or if you run into any issues with these instructions, please check out the 

With the token ready to go, let’s test out the API! Run the following request and plug in your JWT generated in the previous step:

curl 'https://stats.mux.com/counts?token={JWT}'

curl request to get real-time stats

Since there are currently no views, you can expect to get something back like:

{"data": [{"views": 0, "viewers": 0, "updated_at": "2021-09-28T18:21:19Z"}]} 

expected response for real-time

In order to ensure you’re pulling in the right live data, test out live views by opening 

 in several browser windows and emulating live video plays, then running the above command to see if it reports these live views. You can also compare the viewer metrics from the Real-time Dashboard (via 

 > /Data > Real Time) to verify if you’re getting the correct results and the right view and viewer counts.

8. Set up the useInterval hook to make a recurring API call and update the view and viewer counts

Once you verify that you have access to your real-time view and unique viewer counts via an API call, you can now plug that information into your application. To add in the API call to the VideoPlayer component, create an 

, which will make the API call and then set the view and unique viewer counts based on the data returned from the request:

async function getData() {
    const response = await fetch("https://stats.mux.com/counts?token={JWT}");
    const data = await response.json();

    setViewCount(data.data[0].views);
    setViewerCount(data.data[0].viewers);
}


getData() function

Note: the JWT is being embedded directly into the request URL for demo purposes. If you’re looking to use this for a non-demo or client-facing application, please consider making the JWT an environment variable for an additional layer of security.

Since real-time counts happen very quickly and are extremely dynamic, the 

 at frequently specified intervals (please note: Realtime Data APIs are rate limited to one request per second). You can install the library needed to use this hook by running the following command:

yarn add usehooks-ts 

import { useInterval } from 'usehooks-ts';

import useInterval

 hook requires a function body with code it will execute as its first parameter, and a specified interval of time (in milliseconds) between function calls. A successfully executed 

useInterval(
    () => {
        getData();
     },
    15000 // interval is every 15 seconds (recommended to be 15-30 seconds depending on video length)
)


useInterval

 hook has been implemented, your app is ready to surface real-time view and unique viewer counts in the player!

Dog wearing a sweater and glasses looking at a computer

Learn how to build a simple React app to surface a video's real-time view and unique viewer counts within the video player!

Ashley Huynh

Introducing the Mux Changelog

Surface real-time view and unique viewer counts in your video player

United States

United Kingdom

Products

Mux Video

Mux Data

Docs & Tools

API SDKs

Company

Learn about video