How to: Dynamic Packaging
Note that WSE lists the streams in the master playlist file according to the order in the SMIL file, and that in most ABR technologies, the top file is retrieved first by the player. For the smoothest startup and initial quality of experience, you should start with the highest quality stream that your viewers can sustain for an extended period. That’s why I topped the SMIL file with the 720p@3Mbps file, rather than the 1080p@5Mbps.
If my audience was mostly mobile, I would lead with the 700Kbps 640x360 stream, which should look good on most tablets and smartphones while starting quickly and smoothly. To create different master manifest files for different targets, say to present a different starting stream for mobile than to OTT viewers, you’ll have to create multiple SMIL files. WSE simplifies this by providing the ability to copy any existing SMIL file, rename it, and quickly change the order in the WSE GUI.
Creating the ABR Links
Once you’ve got the files uploaded, application configured, and SMIL file created, it’s time to create the links to the different ABR formats. The easiest way to get this right is to use the Test Players shown in Figure 1. To load the player, click Test Players shown on the upper right in Figure 2, but before you do, write down the name of the SMIL file you’ll be testing. In my case, it was TOS_ABR.smil.
Once the Test Players dialogue appears, make sure that the correct application is showing in the Application box on the upper right (e.g., Tutorial). Then, insert the name of the SMIL file in the Media File Name box, preceded by smil: (smil:TOS_ABR.smil). This calls the SMIL file rather than any of the specific MP4 files that you’ve loaded.
Then, click the tab for the ABR format you’re targeting, and then Start on the upper right side of the playback window (shown as Stop in Figure 1, which it toggles to once playback starts). The top line above the playback window contains the URL you’ll likely link to. Note that unless you’re testing with a browser that can play back HLS (Safari on the Mac, or Edge), you’ll see an error message in the Apple HLS tab (HTML5 or HLS is not supported in this browser). If you get this, and you need the HLS link, click the Mobile tab and you’ll see an iOS link for Apple and an RTSP link for Android.
Note that the Test Player isn’t fully functional for all formats, so don’t use it for debugging. Rather, use it to generate the URL you’ll paste into your actual player. Once you enter the filename specified previously, you should be able to get one or more of the players working. This tells you that the URL should be correct, which you can take to your actual player for testing and debugging. For example, I copied and pasted the MPD URL from Figure 1 into the Bitmovin test player and was immediately rewarded with the results shown in Figure 4.
Mission accomplished; the successful DASH ABR presentation in the Bitmovin test player
That’s VOD—now let’s take a look at live.
Going Live With WSE
As an overview, for this live application, we’re sending a single stream into WSE, transcoding that into multiple ABR streams, and making those streams available via the same formats deployed for VOD previously. Rather than creating a SMIL file, you’ll configure the streams in the Wowza Transcoder and then create Stream Name Groups, which WSE will use to create the master manifest files.
The relevant tutorial for this part of the exercise is “How to Set Up and Run Wowza Transcoder for Live Streaming.”
Enable Transcoder
The tutorial starts by walking you through how to enable the Transcoder and configure presets, which is straightforward. If you’re using an existing template, edit all presets to remove the WowzaLogo overlay image, and substitute your own, if desired. Note that you can use the same preset for all incoming live streams, or create different presets for different events selected by the incoming stream name.
The key point with the Transcoder is to make sure that the selected presets don’t swamp the available CPU resources. You see this in Figure 5, where the top of the figure shows the enabled presets, while the bottom shows the CPU usage graph snipped in from the Server Monitoring page. When building your encoding ladder in the Transcoder, be sure to gauge the CPU required to support those transcoding efforts, along with other functions of the server. Once you get beyond 80 percent or so, you’re risking overall stability and should transition to a more powerful computer.
Transcoder settings and CPU consumption on a C3.2xLarge
As with all ABR transmissions, keyframe interval and segment size are critical configuration options, and keyframe interval should divide evenly into segment size. The default segment size for HLS streaming was 10 seconds, which you configure in the Properties tab of your live application by editing the cupertinoChunkDurationTarget property. If you use 10 seconds, you should set the keyframe interval for each rendition in your live application Transcoder > Transcode (Default) template equal to either 2 or 5 seconds. I changed the default segment size to 6, both to remain consistent with Apple’s recommendations in TN2224 (as of August 2016) and to reduce startup latency. I used a keyframe interval of 2 in my live encoder, which was the Open Broadcaster Software (OBS).
Creating Stream Groups
In the Server > Transcoder > Transcoder Template > Transcode (Default) settings, click the third tab on the upper right to view the Stream Name Groups (Figure 6). The two shown in the Figure were preconfigured by Wowza. Essentially, these groups allow you to create different groups that you can deliver to different targets. As you can see, the “all” group contains all the streams, while the “mobile” group excludes the 720p stream. These groups serve the same function as the SMIL files produced above for VOD distribution, as WSE creates the manifest files from these groupings. As with the SMIL files, you link your player to the URL of the specific grouping, which I’ll show you how to do later after we get the encoder up and running.
Again, positioning in the group sets the order in the manifest file, with the first stream retrieved initially by the player. I’ve got the 720p stream first in the “all” manifest, which is a 2Mbps stream that should look good and play smoothly on broadband-connected devices. For “mobile,” I’ll start with the 850Kbps 360p stream, which should provide a good experience on most newer cellular devices with 4G connections.
Configuring Your Encoder
You configure your encoder as shown in Figure 7. The server URL is rtmp://[wowza-ip-address]/live, and the Stream key (usually called Stream Name) is myStream unless you opt to change it. You can elect to not require RTMP security in the WSE Source Security settings of your live application. If you opt for security, you add sources and their passwords in the WSE Server > Source Authentication settings. As shown in Figure 7, the username I selected was livestream, and the password was stream.
Pointing your encoder at WSE
After configuring your address and credentials, press Start Streaming or the equivalent in your application. Typically, if there’s a problem, your encoder will immediately display a failure to connect error message. If none appears, you should be good to go.
Stream Groups
In the live application, click Incoming Streams, and then below Active Streams, click View by Group (Figure 8). This shows the stream groups created by the transcoder presented alphabetically by stream name, not by the order in the manifest file. Note the group names, because they are critical to creating the URL to link to the streams.
The incoming stream groups
To create those URLs and test the streams, click Test Players on the upper right in Figure 8. In the Test Player Stream field, be sure to insert the correct target screen group (e.g., myStream_all) and precede that name with ngrp:, which is the stream name prefix for adaptive delivery. As you can see in Figure 9, the full Stream name is ngrp:myStream_all, while you would use ngrp:myStream_mobile to test the mobile adaptive group. The address shown just above the video playback window is the URL for DASH playback that you would plug into your player. Click the other tabs to view the URL for the other formats.
Testing the “all” adaptive group in the MPEG-DASH player
I tested both the HLS and DASH formats in the Bitmovin player for both VOD and live, and both products worked as advertised. While I certainly would allow for a couple of days of testing and debugging before going live, most reasonably technical users should be able to get either live or VOD up and running and ready for testing within a couple of hours.
This article was published in the Spring 2017 European edition of Streaming Media magazine.
Related Articles
Use a single adaptive group, packaged differently for different targets, to keep encoding and storage costs down.
13 Apr 2016
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.
17 Jan 2013
Modifications to the server also include HTTP origin delivery of ABR content into caching networks
12 Nov 2012