How to: Dynamic Packaging
Need to reach the widest possible audience with the fewest encoding steps? Here's how nonprogrammers can use Wowza Streaming Engine to serve both live and on-demand video.
Learn more about the companies mentioned in this article in the Sourcebook:
Our goal as streaming producers is to reach the widest possible range of viewers. To accomplish this, you’ll need to support multiple adaptive bitrate (ABR) packaging formats, like DASH (Dynamic Adaptive Streaming Over HTTP), HLS (HTTP Live Streaming), and/or Smooth Streaming. One of the fastest, simplest, and most affordable ways to accomplish this is via dynamic packaging with Wowza Streaming Engine software, which works for both live and VOD. In this tutorial, I’ll cover both. I chose Wowza because it’s one of the leading tools for performing dynamic packaging, and because it’s one of the few with a GUI that enables nonprogrammers to perform these types of operations with no coding or scripting. Other services that can perform this service include Microsoft Azure and CDN Akamai.
I’ll start with a brief statement of what I hope to accomplish. Wowza does a fabulous job documenting how to use its products, with highly detailed, step-by-step tutorials available on-site. What value do I hope to provide? First, while the Wowza tutorials necessarily focus on the individual trees in the forest, I’ll start with a look at the entire forest, which should provide context for what you’re trying to accomplish. In addition, having worked through the Wowza tutorials, I can help you focus on the truly important steps and the potholes to avoid. All this should make your initial forays into live and on-demand streaming with the Wowza Streaming Engine faster and more efficient.
Before we get started, let’s talk pricing and deployment options. You can purchase a lifetime version of Wowza Streaming Engine software for $1,995, lease and pay by the month for $95/month, or pay $780 annually to lease for $65/month. You can deploy Wowza Streaming Engine on-premises or in the cloud, with Wowza providing how-to instructions for deploying on cloud services from Amazon, Microsoft, Google, Rackspace, Docker, and Alibaba. In all these cloud deployments, you pay for machine time directly to the cloud provider; with Azure and Amazon, you also have the option to lease Wowza Streaming Engine software directly from them on a per-minute or per-hour basis, respectively.
Let’s discuss dynamic packaging before diving into the process. To distribute adaptively, you have to transcode your source video into an “adaptive group” of multiple renditions, each with different resolutions and data rates, which allow distribution to multiple devices over a range of connection speeds. Then you have to package each group of streams into the adaptive formats suitable for your multiple player targets, which typically involves chunking each iteration into shorter segments and creating manifest files that tell the player which streams to retrieve and where to locate them.
Let’s assume that you needed to support three ABR formats: HLS for mobile, DASH for desktop, and Smooth Streaming for gaming consoles. With static packaging, you would create three separate groups of these packaged assets and upload them to the origin server, which triples your storage charge, and in some cases also triples your encoding charge.
To dynamically package VOD files, you output the files in your adaptive group in MP4 format and upload them to your origin server. Wowza Streaming Engine (WSE) software then dynamically packages the files for the various devices that request them, a process also called transmuxing. This saves storage and often encoding costs, though this will be partially offset by the costs of WSE and associated computing costs. Wowza also makes it fast and easy to support additional formats when it makes sense to do so. WSE isn’t the only solution for this, but it is one of the most prominent. With Live streaming, you send a single stream to WSE, which it transcodes to multiple MP4 streams and then packages into one or more ABR formats as necessary.
At the end of the day, what you end up with is what’s shown in Figure 1—different URLs for the different output formats. In most cases, this is the URL you use to connect from your playback device. To continue with our example, you might use the MPEG DASH stream to deliver to your desktop player, while sending the Apple HLS streams to iOS and Android mobile devices, and the Smooth Streaming (MS Smooth) output to Xbox and other consoles. In all cases, Wowza takes in the MP4 files and outputs the necessary adaptive bitrate formats, complete with manifest files.
Wowza Streaming Engine supplying the multiple formats
How you get to this endpoint varies for VOD and live streams, as you’ll learn later. For both, the final step is creating the URL that you’ll use to link from your various players or clients. The easiest way to accomplish this and test your work is to use the test player shown in Figure 1, which I’ll cover in more detail later.
Let’s start our tutorial with VOD. If you want to follow along with the Wowza tutorial, you can find “How to Stream Adaptive Bitrate Content” on the Wowza site.
Setting up dynamic packaging for VOD delivery takes four steps, as follows:
- Encoding the various renditions to MP4 format
- Configuring the WSE software
- Creating a SMIL (synchronised multimedia integration language) file with file-related data that WSE uses to create the manifest files
- Creating the ABR links, which I tested by embedding them in the Bitmovin HTML5 Player— if you don’t have a free account, you can also test on the Bitmovin free player test page.
Encoding the MP4 Files
The golden rule of adaptive streaming is that all files in an adaptive group must have aligned keyframes. This is simple to accomplish in most on-premises or cloud encoders. Once you’ve encoded your files, you drop them into the /content folder in your Wowza Streaming Engine installation. Note that WSE supports file locations in S3 buckets and elsewhere, which I didn’t test.
Configuring the Wowza Server
WSE uses what it calls applications to drive separate processes in the server. Roughly, an application is a bucket of settings that you may want to vary for certain workflows. For example, in a live environment, you may want to record or use the DVR function for some broadcasts, but not others, which the use of different applications will allow you to do. For simple workflows, you can opt for the default applications that are available when you install WSE.
Once WSE is up and running, and you’ve logged in, click the Server tab in the top menu bar, and then click Users in the content panel at the left. On the Users page, click the Edit icon for the administrator account. Select the Allow access to advanced properties and features checkbox. Click Save. Wowza Streaming Engine Manager signs you out, and you must sign in to the manager again. You’ll need to see the advanced properties later.
Once signed back in, click the Applications tab in the top menu bar to view your applications—you can see them all listed on the left in Figure 2. For this article, I created the Tutorial VOD application by clicking the Add Application button on the extreme upper left.
Top-level configuration options for this VOD application
Click the Properties tab to edit the properties for the various ABR formats you plan to support. You see the top-level configuration options for the application in Figure 2; you can control which playback types the server supports, plus the closed caption sources, and several other options. I used the default setting shown. You can change any of these when you create the application or return to it later by clicking the Edit button. Once you save your changes, you’ll have to restart the application, which disconnects any users, but it only takes a few seconds.
In the version I reviewed, I could adjust common options such as segment duration for live applications in the GUI, but I had to manually adjust XML files to change these same settings in VOD. When I asked about this, Wowza related that its development priority was typically live streaming. While the company was working toward interface parity between live and VOD, it couldn’t guarantee that it would be in place by the time you read this article. So, as an example, while it’s simple to set segment duration for all formats when working with live video, you’ll have to hunt around and find different XML files to do the same for VOD.
Creating the SMIL File
After uploading the files and creating and configuring your application, it’s time to create a SMIL file that WSE will use to create the manifest files for the various formats. You create the SMIL file using a simple wizard in the WSE UI.
On the left in Figure 2, you see the SMIL Files menu item beneath the selected application (in this case, the Tutorial application). Click SMIL files and the interface will prompt you to Add SMIL File or Copy SMIL File, once you’ve created your first file. When you click Add SMIL File, you’ll be prompted to add a title and description, and then to start adding SMIL streams.
You can see the files that I added to the TOS_ABR SMIL file in Figure 3. Operation is simple; you click Add SMIL Stream and you’re prompted to choose the type of file (audio, video, or text), and then characteristics like video bitrate, resolution, and audio bitrate. I ran through this process eight times to add the seven video files and single audio-only stream shown in Figure 3.
Adding streams to the SMIL file
Modifications to the server also include HTTP origin delivery of ABR content into caching networks
How do these three media servers differ in iOS delivery, MPEG DASH, DRM, and other hot button issues? A Streaming Media Europe presentation had the answers.
Use a single adaptive group, packaged differently for different targets, to keep encoding and storage costs down.