With adaptive bitrate streaming becoming the emerging standard in video delivery, Encoding.com wanted to give developers an overview of each protocol to highlight key differences. With this guide, we will dive into the architecture of Adobe’s approach to adaptive bitrate delivery, HTTP Dynamic Streaming.
HDS, or HTTP Dynamic Streaming, is Adobe’s method for adaptive bitrate streaming for Flash Video. This method of streaming enables on-demand and live adaptive bitrate video delivery of MP4 media over regular HTTP connections. Adaptive bitrate works by detecting a client’s bandwidth capacity and adjusts the quality of the video stream between multiple bitrates and/or resolutions in real-time. The adaptive bitrate video experience is superior to delivering a static video file at a single bitrate, because the video stream can be switched midstream to be as good or bad as the client’s available network speed (as opposed to the buffering or interruption in playback that can happen when client’s network speed can’t support the quality of video). Previously video content delivery over HTTP was delivered in a progressive manner, meaning to view part of or seek to a specific location in the video you had to wait for that part to download.
If you are working on or looking to do any of the above, you should become acquainted with Adobe’s HTTP Dynamic Streaming. We’ve got all the information you’ll need to help you get started.
There are several advantages of using Adobe HTTP Dynamic Streaming over HTTP progressive downloads , some of which include:
|wdt_ID||HTTP Dynamic Streaming||RTMP Dynamic Streaming with Adobe Flash Media Server|
|1||Flash Player||Reduced reach until Flash Player 10.1 is widely adopted||Flash Player 10 or later support (99% of all connected PCs)|
|2||File Format||F4F format compatible only with HDS – same files cannot yet be delivered using RTMP streaming. Note: Progressive download is supported but requires additional development.||Support for all Flash formats, including FLV and F4V. Note: F4F is not supported by Flash Media Server|
|3||Publishing Workflow||Additional workflow steps required to prepare content; special origin server required.||Simple publishing workflow|
|4||Content Workflow||Requires Flash Access 2||RTMPe/SWF file verification for simple workflow; Flash Access 2 supported|
|5||Live Latency||Increased latency on live streams due to media fragmentation/encryption process before delivery||Low latency depending on deployment and buffer settings|
HDS provides midstream quality adjustments for variable mobile bandwidth speeds
HTTP Dynamic Streaming extends the F4V format using an additional standards-based MP4 fragment format (ISO/IEC 14496-12:2008) with the extension .f4f. This format allows HTTP “gets” to fetch and cache smaller portions of the media. Adobe has published the complete F4F format specification inside the F4V specification on Adobe Developer Connection.
The below image demonstrates how to prepare, deliver, consume, and protect video on demand (VOD) and live content using Adobe HTTP Dynamic Streaming.
There are a of couple things that you’ll need to consider when getting started with HTTP Dynamic Streaming.
HTTP Origin Module Installation
First, a media server to stream the content is not required, but the Apache Web server with the HTTP Origin Module installed is. The HTTP Origin Module is a free to use Apache module provided by Adobe, and comes pre-installed and configured with the Flash Media Server when you install the bundled web server, although FMS is not required. Download the HTTP Origin Module.
Video in F4F format
Second, the video content will need to be ‘prepared’ for HTTP Dynamic Streaming before being deployed to your server. This means the workflow for content creation will need to be adjusted to accommodate the packaging of your video content into the F4F file format.
|wdt_ID||RTMP Dynamic Streaming||HTTP Progressive Download||HTTP Dynamic Streaming|
|1||Flash Player Version||Flash Player 6 or later||Flash Player 7 or later||Flash Player 10.1 or later|
|2||Quality of Service||Measured on bandwidth and performance||N/A – often resulting in poor user experience||Measured on bandwidth plus performance|
|4||Publishing Workflow||Simple||Simple||Packaging plus manifest file required|
|5||Content Protection||Real time (RTMPe), SWF file verification, Flash Access DRM||Flash Access DRM for VOD only||Flash Access DRM for both live and VOD|
|7||Live Latency||Less than 1 second*||N/A||Less than 30 seconds**|
We at Encoding.com make it very easy to work with HDS. There are a few options for streaming this type of content:
*HDS will work on AWS CloudFront only via their special Flash Media Server subscription.
To stream on-demand media using Adobe’s HTTP Dynamic Streaming (HDS) protocol choose the preset “Dynamic Streaming" from the encoding.com client interface/watch folder, or the parameter “HDS" from the Encoding.com API.
Note: To use Adobe’s HDS, the source media must be in MP4, FV4, or FLV compatible formats. Please transcode your video into one of this formats before using the HDS preset.
Special Note: Because the HDS output creates multiple files from a single source file you have the option to tar the output output tar = yes. If you chose to tar your HDS output the file extension of your output video should be set to .tar. For example in the destination field of your request you would specify: ftp://username:firstname.lastname@example.org/hds/myhdsvideo.tar In this case all multiple outputs will be combined in a single tar ball for you to unpack on your own at a later day. Set tar file = no to send all the files unpacked to the directory specified in your destination path.
Most Important Note: The extension of your output video name should be set to .f4m. For example in the destination feild of your request you would specify ftp://username:email@example.com/hds/myhdsvideo.f4m In this example all of the HDS compatible files will be sent to the root directory /hds so it is advised you create a separate directory for the HDS output.
The HDS preset will create the following outputs and send them to your specified destination:
Assuming source file name was myhdsvideo, you would receive the following .4f4 files:
Contains information about codec, resolution, and the availability of multi-bitrate files. In this case your would receive the following .4fm files:
Assuming source file name was myhdsvideo, you would receive the following .4fm files:
Contains the location of specific fragments within a stream.
Assuming source file name was myhdsvideo, you would receive the following .4fx files:
HDS Output from Encoding.com can be used on any Flash Media Server or as as extension to any web server running Apache HTTP Server version 2.2 with the Adobe HTTP Origin Module Installed. Read more from Adobe on the HTTP Origin Module. Adobe’s HDS is also supported by many popular Flash players, for example Flowplayer supports of http streaming.
For more information on Adobe’s HTTP Streaming technology visit Adobe product page on the topic.
Below is a complete example of a multibitrate Adobe HDS API request:
Example XML of a HDS API request:
Encoding.com continues its quest to migrate large-scale video pipelines to the Cloud.
Joint Solution Features Viaccess-Orca’s Cloud-Based TVaaS, With Cloud Media Processing From Encoding.com
RT @OpineMediaGroup : OpinePR 🗣 RT OpinePR: OpinePR 🗣️ https://t.co/rlwV1ApTvZ announcing the launch of the first Video QC Service in t… htt…4 hours ago
Video QC in the Cloud is here https://t.co/uueIFbcXzz #VideoQC #Cloud #Encoding https://t.co/qh3jt02oWP8 hours ago