Azure Media Services Part 2: Streaming an Asset with Dynamic Packaging

So you’ve uploaded your media asset. Great! Now, how are we going to go about getting that media asset to others? Well, luckily for all of us, Media Services gives us a plethora of options. Using media services, you can deliver your assets via:

  • Download
  • Progressive Download
  • Streaming

In this post, we’ll be covering streaming (like the title says…just look up)! We won’t be learning about just any method of streaming though; we’ll specifically cover streaming with dynamic packaging. For further reference, feel free to hit up the Azure Media Services Documentation  as well as Nick Drouin’s Introduction to Dynamic Packaging.

But Gavin, What is Dynamic Packaging?

I’m glad you asked! In this wonderful world of device selection, there are plenty of different protocols that these devices understand. For instance, iOS devices require HLS V4 (HTTP Live Streaming) format whereas Xbox adheres to Smooth Streaming. If your goal is to provide media to as large an audience as you can, dynamic packaging within Media Services is definitely a tool you should take advantage of. You can deliver your source files to a client that understands MPEG DASH, HLS, or Smooth Streaming. You just have to be sure that your origin files are either Smooth Streaming or multi-bitrate MP4 files.

How’s it different from the traditional Encode and Package technique?

Another great question from the reader! Dynamic packaging is awesome in that it saves space which, in turn, saves cash. Instead of having to encode your asset into multiple assets for multiple protocols, dynamic packaging allows you to encode your asset into one multi-bitrate MP4 asset. From there, the On-Demand Streaming server handles the hard work and will encode the stream in the protocol you established “on-the-fly”. This means you’ll have the same reach as traditional encoding and packaging, but you’ll only have to pay for the files in single storage format. To better visualize the method employed, check out the illustrations below:

The Old Way

 

 

 

 

 

 

 

 

With Dynamic Packaging!

 

 

 

 

 

 

 

 

Alright, I’m interested! Where do I start?

Glad to see hear you’re excited, reader! There are some steps we have to follow in order to take advantage of dynamic packaging:

  1. Reserve at least one On-demand Streaming reserved units
  2. Prepare your asset for dynamic packaging
  3. Receive your streaming URL’s!

1. Reserving an On-Demand Streaming Unit

Reserving an On-demand Streaming Units is a part of scaling your media service. You can specify both the number of On-demand Streaming Reserved Units as well as Encoding Reserved all through the portal. For the sake of this walk-through, we’re only concerned about specifying the number of On-Demand Streaming Reserved Units. Being able to manage the number of reserved units allows you to control the price of your Media Services subscription by only using what you’ll need.

If you haven’t used this feature, by default, you won’t have any reserved units. To reserve a unit, click the Media Services tab in the Management Portal:

pic1

Select your Media Service:

Capture

Select the “Origins” page and select the origin you wish to modify. If you haven’t done this, then you’ll only be greeted with a “default” origin. click that one.

Capture2

 

Select the “Scale” Page, and slide the “On-Demand Streaming” to 1 unit as shown below. Be sure to save your changes:

Capture3

 

Once you’ve provisioned your On-Demand Streaming unit, the next thing we’ll need is the content to provide. We can do this by adding to the console application we wrote in Part 1 of this series. We’re going to upload the same file again, just to keep things simple, be sure to delete the “Big Buck Bunny” file in your Media Services account.

 

2. Prepare your asset for dynamic packaging

Now, go ahead and open the project we wrote in Visual Studio!

We’ve already covered some of the basic necessities like creating a CloudMediaContext object and providing the credentials (account name and key) for your Media Services account. We’ve got a base for our program, but more must be done. We still have to:

  • Edit the CreateAssetAndUploadSingleFile function to return an ID
  • Create an IJob to encode the video to a multi-bitrate mp4
  • Get and Display the Dynamic Streaming URL’s

The first thing we need to do is declare an assetID string in Main and set it equal to asset.Id. This will be passed into our IJob’s function to encode our asset. It should look like this:

Easy enough, right? We’ll stay in the Main method for a while now and set the foundation for the rest of this program. The next thing we’ll have to do is create an IJob object and instruct it to encode our asset to the multi-bitrate MP4 file we’ll need. We can do this in main by stating:

We’ll create the EncodeToMultiBitrateMp4 method soon, but for now, we’ll continue setting our declarations in Main. The next thing we’ll need is a means to access our multi-bitrate MP4 file, and we can do that by creating a var type and setting that equal to the IJob’s output. This is done here:

Accessing the mp4Asset is very important as we’ll need to pass it in the method we’ll use to get the different streaming URLs for our different formats. We’ll be using our multi-bitrate MP4 file to get a Smooth Streaming URL, an MP4 Streaming URL, and an HLS Streaming URL. We’ll do that simply by creating strings for the URLs and displaying them in the console this way:

Awesome! We’re done laying the foundation in our Main method, and now it’s time to move on to our previously referenced methods. Lets start with the EncodeToMultiRateMp4 method:

There’s a good bit going on in this method, so let’s break it down. The first thing to be done was to locate the inputAsset. This is done by passing in the inputAssetID to the method, and in case the ID did not lead us to the asset, the throw new ArgumentException statement is instead presented. This is shown here:

The next thing to be done was to state the encoding preset. As stated earlier, our goal was to encode to a multi-bitrate MP4 file. Specifically, this is an “H264 Adaptive Bitrate MP4 Set 16×9”. These presets can be found on MSDN from the link in the code.

Next, we create a job. For organizational purposes, it’s explicitly stated what asset is being encoded and to what preset.

Within that job, we have to create a task. In order to create a task, we must first create a MediaProcessor. This statement ensure that we get the latest WameMediaProcessor.

We then use our MediaProcessor and our encodingPreset to a create a new task. We then add our inputAsset to create a new outputAsset. This will be our new multi-bitrate MP4 file.

Now, we add an event handler to determine when the job’s state has changed. Finally, we submit the job and wait for the job to finish.

 

 3. Receive Your Streaming URL

Awesome! We’re almost to the finish line. We’ll use the output asset from our newly converted output in the function GetDynamicStreamingUrl. This function allows us to take the different URLs from one output asset to be displayed in Main based on its protocol. The entire function is below:

The first thing to be noted here is the time limit set on the access policy here. We’ve set it at 1 year (365 days, of course) in order to display that it can be done. This is important in the event that there is a contract being carried out with a partner of sorts or if there is just a reason to keep a time limit on how long we can access the streaming URL. This is seen here:

The next important piece is the fact that the asset files of the output asset we created in the last function is being placed in a list. This way, once the locator type is determined, we will proceed to create the url based on the locator type.

There are two Locator types in Media Services: SAS and Origin. SAS locators are pretty much used to download and playback media wheras Origin locators are primarily used to dynamically package from MP4 to HLS or Smooth Streaming as well as a means to progressively download MP4 files.

In the case of the Origin type, the program will look for an “ism” file, and that path is concatenated with the asset file’s name and the word “manifest. This creates a smooth streaming ur:

In the case of a SAS locator type, the program searches for MP4 files, orders them by their sizes where the last one is the biggest, and finally builds a locator.

And that’s the code! Go ahead and run the program. You should see in the Management Portal that you have a job in progress. After a little while, you will be presented with the three different URLs. The first is the SAS URL, followed by the Smooth Streaming URL, and finally the HLS URL, which is really just the SAS URL formatted to Apple’s requirements. You can test the Smooth Streaming URL here. You can just copy and paste the HLS URL into your browser to view the Apple manifest file. Finally, you can use the SAS URL to just download the file by placing it in your browser.

Be First to Comment

Leave a Reply

Your email address will not be published. Required fields are marked *