通过

Progressive download and streaming differences with Azure Media Services

  • 项目

<note: I plan on occasionally editing this page with updated information. I may not document the changes made as they happen.>

Azure Media Services gives you two different ways of delivering video content.  You can either progressively download content from Azure Storage or stream the content from Azure Media Services.  This article discusses these two options with the pros and cons of each. The tl;dr is that progressive download is more simple, but streaming provides a better client playback experience.

Progressive Download
The term 'progressive download' is more commonly used when comparing it as a delivery mechanism for video versus streaming.  At first glance, progressive download is really simple. It is essentially just downloading a file from a web server over HTTP. There is a little more to it than that, but that’s the core of it. This method supports any file type and codec since the web server doesn’t really care about any of that. With Azure, blob storage acts as the web server that you access through a SAS (Shared Access Signature) URL. Azure Media Services allows you to create container based SAS URLs when you publish locators. These URLs look like https://<accountname>.blob.core.windows.net/asset-5310435d-1500-80c6-743b-f1e515255692/video.mp4?sv=2012-02-12&sr=c&si=2ef045bc-bd32-46e0-9ece-01cb8ea1d414&sig=W95c%2Fc%2FGi0cmikscbkI27jDt%2FTXHpkVm0Z1MJsUJzDA%3D&se=2115-08-12T19%3A21%3A27Z. There are a couple of things that make it obvious that this is a SAS URL. First is that the domain name contains blob.core.windows.net. The ‘blob’ part of this is blob storage. Second is the inclusion of the query string at the end that contains the ‘sv’, ‘sr’, etc. parameters that describe things like the expiration of the URL and signatures.

As I mentioned before, progressive download supports any video file type. There are a ton of different formats out there that you to can choose from. But keep in mind that whatever player you are using to point to the SAS URL must be able to play the file. Since it currently has the widest possible adoption I’d recommend creating a MP4 file that uses the H.264 video codec and the AAC audio codec. Another advantage to this format is that it works with the HTML5 <video> tag. There are two main disadvantages that I see with using progressive download. They are that with progressive download whatever bitrate you have chosen to encode the video is the only bitrate it can be played. So if you encode at 1 Mbps, then a client must maintain that speed to play the video. If the video is only a few seconds long that may not be a problem, but if it is an hour the client could experience a lot of buffering/playing/buffering/playing/buffering if it was connected to the Internet on a 900 Kbps connection.  If you choose a low bitrate for your video then you are sacrificing quality for the lowest common denominator of internet bandwidth. Second is that the player you are targeting may not be available on all platforms. For example, if you use the HTML5 <video> tag, that is not available on machines that have older browsers.

These are some fairly technical details about progressive download / Azure Storage that most people don't need to know:

  • Not all clients / web servers are able to seek within the video.  Some may have to wait until the video is fully downloaded before they seek.  To support the seeking of video with progressive download both the client and server must support byte range offsets.  This is using the HTTP 'Accept-Ranges' server response and the client's 'Content-Range' request as per RFC 2616.
  • Azure Media Services creates SAS URLs for links to blob storage as container based URLs, not blob URLs directly.  You can certainly link to a blob within the container though using the base URL of the container + the blob file name.
  • Azure Media Services uses a signed identifier, the 'si' value, as the container policy ID so that the SAS URL can be revoked.
  • There is a Storage limit of 5 policies per container.  This is why Azure Media Services is limited to 5 SAS URLs.
  • The video that was progressively downloaded will be stored in client's browser cache (assuming it will fit).
  • If you want to use a CDN for distributing SAS URL based videos you setup the CDN on the Blob Storage account.

 

Streaming
There are a couple of different ways of doing streaming, but I will focus on adaptive streaming here since that is what Azure Media Services uses with the different protocols it has available. Adaptive streaming is a bit more complex to setup but generally allows for a better client playback experience. This is because you typically encode the video in a way such that you have multiple different bitrates to choose from. You may have bitrates as low as 300 Kbps and all of the way up to 3.5 Mbps (this is customizable) with a number of bitrates between those. Clients can then choose the most appropriate bitrate as they are streaming. The way this works is that the client downloads the lowest bitrate first chunk of video. This chunk of video is 2 – 10 seconds long. The client determines the bandwidth between the client and the Azure Media Services origin based on that first chunk and then adjusts the bandwidth accordingly. If it is determined that the client has quite a bit of bandwidth then the bitrate is increased. If over time the client bandwidth degrades then the client can lower the bitrate that it requests from the origin. One side effect of this is that there is essentially no initial buffering necessary, so playback begins almost instantly. Technically there is buffering, but it is only the time it takes to buffer the initial chunk. An example streaming URL is https://<accountname>.streaming.mediaservices.windows.net/e8927280-0d3b-4c19-8eb0-4c56cb0bf1f0/video.ism/Manifest. You can tell it is streaming from Azure Media Services since the domain name contains the streaming.mediaservices.windows.net as well as the file name ends with .ism with the /manifest REST parameter.

Azure Media Services is capable of streaming Smooth Streaming to Silverlight and Flash clients, HLS to iOS clients, and MPEG-DASH to browsers that support Media Source Extensions. Streaming with MPEG-DASH allows clients to avoid using browser plugins like Flash or Silverlight to play content. To create content that is streamable from Azure Media Services you can create content in two different ways. You can either encode it to the target format, such as an ISMV for Smooth Streaming, or encode into an adaptive bitrate MP4 set. If you choose to target one protocol, like Smooth Streaming, then the video can only stream with that protocol. However, if you use the adaptive bitrate MP4 set the Azure Media Services origin can transmux the file on the fly to any of the protocols that the service supports. This way you only have one asset. The way you reference the different protocols is by adding a parameter on the manifest request. To get HLS, instead of the above URL for the manifest, you would use https://.streaming.mediaservices.windows.net/e8927280-0d3b-4c19-8eb0-4c56cb0bf1f0/video.ism/Manifest(format=m3u8-aapl). And to get MPEG-DASH you would use (format=mpd-time-csf).  This is discussed in more depth in the Dynamic Packaging overview.

With Azure Media Services you have a couple of different playback options.  You can use the HTML5 <video> tag with dash.js, or Silverlight to play Smooth Streaming directly, or a number of other options.  But one of the easiest things to use is the Azure Media Player.  There's an example page at https://ampdemo.azureedge.net that lets you paste in your streaming locator and uses a collection of players (HTML5 MSE, HTML5, Flash, and Silverlight) to find the best playback option automatically for the client you're playing the video on.  The player documentation explains how to embed the player in your own web page.

These are some fairly technical details about streaming from Azure Media Services that most people don't need to know:

  • Video chunks, or sometimes called fragments, are sized to be the same as the GOP (Group of Pictures).
  • When clients request video fragments the client makes a REST call for that specific fragment.  This includes details about the timestamp of the fragment as well as the bitrate.
  • Because REST calls are used for fragments the response is easily cached on proxies or CDNs.
  • Live streaming uses the same REST format as on demand streaming.
  • To use dynamic packaging you must use at least one streaming unit on your Azure Media Services origin.
  • If you want to use a CDN for distributing streaming URL based videos you setup the CDN on the Azure Media Services streaming endpoint.