Configuring DVR HTTP Live Streaming

Previously I showed you how to configure the Adobe Media Server to deliver Live HTTP Dynamic Streaming (HDS). Let’s add on a feature that will allow your users to pause and rewind the live video – DVR.

DVR HTTP Live Streaming

DVR can be (and actually already is) configured for both HTTP Dynamic Streaming (HDS) as well as HTTP Live Streaming (HLS). The configuration for HLS is a bit more involved, so we’ll tackle the configuration for live HDS streams first. I’ll be walking through the configuration of Adobe Media Server (AMS) 5+.

Configuring DVR for HDS

HDS DVR is controlled using a set-level manifest file. A set-level manifest file is an XML file that provides information about where to play media back from as well as other configuration information for the stream. The Set level manifest file contains some or all of the following:

  1. A base URL.
  2. One or more <media> nodes that point to the media to be played.
  3. Information about DVR.

Below is an example of a set level manifest file for a single bitrate:

<manifest xmlns=""> 
    <media href="livestream1.f4m" bitrate="150"/> 
    <media href="livestream2.f4m" bitrate="500"/> 
    <media href="livestream3.f4m" bitrate="700"/> 

To specify dvr information for this live HDS stream, we add a <dvrInfo/> node that contains a windowDuration attribute.

<manifest xmlns=""> 
    <dvrInfo windowDuration="30"/>
    <media href="livestream1.f4m" bitrate="150"/> 
    <media href="livestream2.f4m" bitrate="500"/> 
    <media href="livestream3.f4m" bitrate="700"/> 

Setting the amount of recorded content

The value for windowDuration can be set to -1, meaning all of the recorded content is available, or it can be set to a number greater than zero (don’t set windowDuration to 0, it can cause problems). This number represents the number of minutes of recorded content, in minutes, that is available to the client to seek through. By Default Adobe Media Server keeps 3 hours of content. You can configure the amount of content the server keeps in the Application.xml or the Event.xml files.

To configure the disk management options in the Application.xml file specify a value in hours for the <DiskManagementDuration> node. You can also use decimal values to specify minutes as in the example below :


To specify the disk management options in the Event.xml add the the <DiskManagementDuration> node with the same parameters similar to the example below:


Creating the set-level manifest file

A tool to generate set-level manifest files is installed with AMS. Known as the F4M Configurator, you can find it in the {AMS_INSTALL}/tools/f4mconfig/configurator directory. I’ve written another article on using the F4M Configurator, so I won’t go into that here. But, feel free to review that article – Using Adobe’s F4M Configurator Tool. Using the set-level manifest above we now have a manifest file that we can work with.

<manifest xmlns=""> 
    <dvrInfo windowDuration="30"/>
    <media href="mylivestream.f4m" bitrate="300"/>

Now that we have configured the amount of recorded media and created a set-level manifest file. We can test DVR for our live stream in a player.

  1. Upload the set-level manifest to a web server. I’ve uploaded mine to
  2. Go ahead and start up your live stream.
  3. Then open the following URL:
  4. Enter the path to your set-level manifest as the value for “src” in the “FlashVars” section.
  5. Set the “Stream Type” to “dvr”.
  6. Click the “Preview” button at the bottom of the form.

Your stream should play, but because we’ve added the <dvrInfo> node, the progress bar should reflect that you can now see back into the content.

Without the dvrInfo:

DVR HTTP Live Streaming Control Bar Without DVR Info

With the dvrInfo:

DVR HTTP Live Streaming Control Bar With DVR Info

Configuring DVR for HLS

DVR for HLS is configured in a similar way to HDS. Except you don’t need the set-level manifest.

The DVR or sliding window can be configured at an event level in the Event.xml file, at an application level in the Application.xml file, or at a server level in the Apache httpd.conf file.

Configuring at the event level

  1. Open the Event.xml file in the {AMS_INSTALL}/applications/livepkgr/_definst_/myliveevent to configure the sliding window for the event named myliveevent in the livepkgr application.
  2. Update the Event.xml with the following XML to create a 1 hour sliding window:
  3. The MediaFileDuration sets the length of each .ts segment in milliseconds and the SlidingWindowLength value configures the number of .ts segments to keep around.
  4. The resulting Event.xml file should look like:

Configuring HLS at the application level

  1. Open the Application.xml file in {AMS_INSTALL}/applications/livepkgr
  2. Add the same XML node set as the event level configuration to the Application.xml file.
  3. The resulting file should resemble the following:

Configuring HLS at the server level

  1. Open the httpd.conf file in {AMS_INSTALL}/Apache2.2/conf (If you are using a non-default Apache install, your httpd.conf file will be in a different location)
  2. Find the Location directive for “hls-live” & add/update the value for HLSMediaFileDuration to be 8000 and HLSSlidingWindowLength to be 450. This will set a sliding window duration of 1 hour for all live HLS streams. By default the sliding window is set to 48 seconds (6 * 8 second .ts files).
    <Location /hls-live>
        HLSHttpStreamingEnabled true
        HttpStreamingLiveEventPath "../applications"
        HttpStreamingContentPath "../applications"
        HLSMediaFileDuration 8000
        HLSSlidingWindowLength 450
        HLSFmsDirPath ".."
        HttpStreamingUnavailableResponseCode 503

Playing back the HLS content

There are quite a few ways to test the HLS content:

  1. Safari on a Mac with Flash disabled.
  2. Quicktime Player
    1. From the main menu choose “File” -> “Open Location”
    2. Then type in the URL to the .M3U8 – Ex:
  3. VLC
    1. From the main menu choose “File” -> “Open Network”
    2. Then type in the URL to the .M3U8 – Ex:
  4. Use an iOS device – either setup an HTML player like VideoJS or MediaElementJS or open the .M3U8 UR directly. Currently this is the only way I was able to use the sliding window. The stream will playback in the other players, but the control bar will not reflect the available content to seek through.


  • Disk management:

Creating Set-level Manifest Files Using the F4M Configurator Tool

Here is a quickie on how to use Adobe’s F4M configurator tool to create set level manifest files.

The configurator is installed with AMS 5.0 and can be found in the following directory: {AMS_INSTALL}/tools/f4mconfig/configurator/

  1. Open the f4mconfig.html file in a browser.
    Adobe Media Server - F4M Configurator Tool
  2. Enter the path to your server, application and event. For example for an event named “myliveevent” using the “livepkgr” application the Base URL would look like:
  3. If you are going to use DVR, enter a value for “DVR Window Duration”. A value of -1 configures the DVR window for all of the available content. A value greater than zero configures the amount of time in seconds available before the live point. We’ll set a 30 minute DVR window, so 1800 seconds.
  4. Enter the stream name and bit rate for each bit rate you are encoding. For this example lets say we have a single bit rate of 300 for a stream named “mylivestream”
    Adobe's F4M Configurator - Stream Name and DVR Window
  5. Click the “Save Manifest” button. A file will be created and you will prompted to save the file. Save the file and open it.
  6. The file should look similar to the following:
    <manifest xmlns="">
      <dvrInfo windowDuration="1800"/>
      <media href="mylivestream" bitrate="300"/>
  7. This file can now be used to specify live DVR content. If you add an additional bitrate, you not have a set-level F4M file for multi-bitrate streaming.

Hope this helps and save a bit of time for you.

Configure Adobe Flash Media Server for Live HTTP Dynamic Streaming

How to set up Live HTTP Dynamic Streaming

So you want to stream a live event using HTTP Dynamic Streaming (HDS) and HTTP Live Streaming (HLS)? No problem. Adobe Media Server (AMS) provides a right out-of-the-box solution for you. To do so, you’ll need to:

  1. Download and install Flash Media Live Encoder (FMLE)
  2. Make a small configuration change to the encoder
  3. Setup your live event
  4. Begin streaming
  5. Set up a player

Installing and configuring Flash Media Live Encoder

  1. Download FMLE from
  2. Once it is installed open the config.xml file from
    1. Windows: C:Program FilesAdobeFlash Media Live Encoder 3.2conf
    2. Mac: /Applications/Adobe/Flash Media Live Encoder 3.2/conf/
  3. Locate the “streamsynchronization” tag under flashmedialiveencoder_config -> mbrconfig -> streamsynchronization and set the value for “enable” to “true”. The streamsynchronization node should look similar to the following:
  4. Save and close the file.

Setting up the live event

Streaming a live event involves using the “livepkgr” application that comes installed with AMS. The livepkgr application comes with a preconfigured event named livestream. We’ll use this as a template for our live event.

  1. On your server navigate to the {AMS_INSTALL}/applications/livepkgr/events/_definst_ directory.
  2. We’re going to call our event “myliveevent”. Create a new directory and name it “myliveevent”.
  3. Open the newly create mylivestream directory and create a new XML file named “Event.xml”. This file is used to configure the just-in-time (JIT) packaging settings for your HDS content. Add the following XML to the file. Note: You can also copy the Event.xml file from the liveevent directory that is setup by default. Just update the EventID to match the folder name.

    For more information about the values in the Event.xml  file you can review Adobe’s documentation – link in the resources section below.

  4. Save and close the file.
  5. Your event is now set up. You can reuse this event all you want, or create another one for a different event name.

Begin streaming

Now we can start up FMLE and set it up to connect to our livepkgr application and begin streaming.

  1. In the left panel of FLME make sure the “Video” and “Audio” sections are both checked.
  2. Video
    1. In the video section, set the format to be “H.264” and then click the button with the wrench icon.
    2. In the resulting pop-up window, make sure the settings match the following:
      1. Profile: Main
      2. Level: 3.1
      3. Keyframe Frequency: 4 seconds
        Live HTTP Dynamic Streaming H.264 Settings
    1. Click “OK” to close the pop-up window.
    2. In the “Bit Rate” section make sure you only have one of the bit rates selected. We’re only creating a single stream for now.
      Live HTTP Dynamic Streaming Video Encoder Settings
  3. Audio
    1. In the Audio section, set the format to “AAC”
      Live HTTP Dynamic Streaming Audio Encoder Settings
  4. In the right panel set “FMS URL” to point to your server and the livepkgr application:
    1. Example: rtmp://
  5. Set the “Stream” value to be mylivestream?adbe-live-event=myliveevent
    1. “mylivestream” is the name of the stream and can be anything you’d like. The actual files that AMS creates will be stored in the livepkgr/streams/_definst_/mylivestream directory.
    2. “?adbe-live-event=myliveevent” tells the livepkgr application to use the Event.xml in the livepkgr/events/_definst_/myliveevent directory that we created.
      Live HTTP Dynamic Streaming RTMP Server Settings
  6. Click the “Connect” button. If all goes well, you’ll connect to your server. If not, check to make sure there aren’t any typos in the values for “FMS URL” and “Stream” and that you can connect to your server and it is running.
  7. Click the bug green “Start” button to begin streaming.
    Live HTTP Dynamic Streaming Big Green Start Button
  8. You now have a stream. Let’s see if we can get a player to play it back.

Setting up the player

Getting to the HDS content for your new stream involves requesting a URL that lets Apache (installed with AMS) know what we are looking for. The path will consist of the following parts:

  1. The protocol: http://
  2. The server location: (in my case, yours will be different)
  3. The Location that is configured to deliver live streams. By default these are:
    1. HDS: hds-live/
    2. HLS: hls-live/
  4. The application name: livepkgr/
  5. The instance name (we’ll use the default): _definst_
  6. The event name: myliveevent
  7. The stream name: mylivestream
  8. The F4M file extension for HDS – .f4m or the M3U8 file extension for HLS.

So if we put all of that together we’ll get a URL that looks like:

  • HDS:
  • HLS:

Note: You may need to add the 8134 port to the URL if you didn’t install AMS on port 80:

  1. Open a browser window and navigate to that URL, you should see the F4m’s XML content.
    Live HTTP Streaming F4M XML
  2. Open the following URL:
  3. Set your F4M url as the value for “Video Source”
  4. Select the “Yes” radio button for “Are you using HTTP Streaming or Flash Access 2.0?”
  5. Set “Autoplay Content” to “Yes”
    Live HTTP Dynamic Streaming Player Settings
  6. Click the Preview button at the bottom of the page.
  7. Congratulations. You are now streaming live media over HTTP.

To verify the HTTP Streaming, open a tool that will let you inspect the HTTP traffic (something like Developer Tools or Firebug). You should see requests for resourecs like “mylivestreamSeg1-Frag52” and “mylivestream.bootstrap”. This is the player requesting HDS fragments and Apache and AMS working together to package them just-in-time for the player.
Live HTTP Dynamic Streaming HTTP Traffic

Hopefully this provides you with some good information about Live HTTP Dynamic Streaming and clarifies some of the setup and configuration details. Please, if you have any questions, let me know in the comments or contact me.


Sencha’s EXTJS 4: Getting Started Quickly


Getting started with Sencha’s EXTJS

  1. Download the Library – EXTJS 4.0.7:
  2. Unzip the contents of the download to a folder in root of your web server. I used /extjs. It should look something like the following image where “extjs” is at the root of your web server:

    Screen Shot of Unpacked EXTJS Files
    Screen Shot of Unpacked EXTJS Files
  3. Make sure your web server is running and open http://localhost/extjs/index.html in your browser.
  4. Click the View the Examples button.
  5. This is a good place to start to see what EXTJS is capable of.

At this point your ready to go. The Getting Started Guide has plenty of information to get your rolling and provide you will a decent knowledge set for EXTJS development.

You want to build something though right? So, let’s build.

  1. Create a directory named “extplay” in the root of your web server.
  2. In the extplay directory create a MyApp.html file.
    Usually EXTJS applications are contained in a single HTML file.
  3. Open the MyApp.html file in your text editor.
  4. Add the following HTML template code to your application:
    <!--<!DOCTYPE HTML>
            <title>EXTJS Getting Started: MyApp</title>
            <link rel="stylesheet" type="text/css" href="/extjs/resources/css/ext-all.css">
            <script type="text/javascript" src="/extjs/ext-all.js"></script>
            <script type="text/javascript" src="app.js"></script>
  5. You will notice the app.js file in the HTML above.
  6. Create the app.js file in your extplay directory and open it in your text editor.
  7. Now we can write some code for our simple application.
  8. Add the following code to the app.js file:
    Ext.onReady(function() {
     Ext.Msg.alert('Status', '<h1>Hello World!</h1>');
  9. Open MyApp.html (http://localhost/extplay/MyApp.html) in your browser. You should see something similar to the following image:

    Sencha EXTJS: Message Box
    The EXTJS Message Box
  10. This is not a full-on EXTJS application – this just illustrates how you can use pieces and parts of EXTJS when and how you’d like.
  11. Let’s create a EXTJS application.
  12. Open app.js.
  13. Replace the code in app.js with the following code:
       name: 'MyApp',
       launch: function() {
        Ext.create('Ext.container.Viewport', {
        layout: 'fit',
        items: [
         title: 'EXTJS: MyApp',
         html : 'Hello World!'
  14. Open MyApp.html in a browser or refesh the browser if it is already open.
  15. You should see something similar to the following:

    Sencha EXTJS: EXTJS Barebones Application
    Sencha EXTJS: EXTJS Barebones Application
  16. Here is what is going on in the code example:
    1. Ext.application: Defines the application named “MyApp”
    2. launch: The built in launch event creates a Viewport and sets it’s config object with a layout and items.
    3. layout: Tells the Viewport to fit to the size of its parent (in this case the body of the HTML)
    4. items: defines the children of the viewport. In this case a title and some HTML.

Now you’ve got an EXTJS 4 application up and running. What do you think?

I’ll follow this post up with some more information on what really goes on with the application, creating and managing the “items” or children of your application & how Sencha handles dependancies and deployment.


Take the PIA out of load testing AMF services

Testing service APIs is a big pain. More so when you are using a format that isn’t widely supported by testing tools. Load testing AMF services…ugh.

Recently I was tasked with finding a way to load test some AMF services built using PHP. In the past I had used jMeter for load testing. So, that is where I started. jMeter is a good tool, but not for AMF. A few extensions for jMeter have been built for AMF, but they are a PIA to setup.

I found a couple of tools that have made load testing AMF serivices a snap. Both of the tools are from SmartBear, and both are open source and free to use. Bonus!

  1. Tool one: soapUI
  2. Tool two: loadUI

The following are the basic steps to get a simple load test set up:

Setting up the project

  1. Download and install soapUI (you’ll need Java too).
  2. Start up soapUI.
    soapUI Startup
  3. Create a new soapUI project – File -> ‘New soapUI Project’
  4. Name your project and click ‘OK’.
    soapUI New Project
  5. Add a new TestSuite – right-click your new project -> ‘New TestSuite’
  6. Name your TestSuite and click ‘OK’
    soapUI New TestSuite
  7. Create a new TestCase – right-click the new TestSuite -> ‘New TestCase’
  8. Name your TestCase and click ‘OK’
    soapui New TestCase
  9. Expand the Test Case
  10. Right-click ‘Test Steps’, select ‘Add Step’ -> AMF Request.
    soapui New AMF Request
  11. Your project is set up and ready-to-roll. Save it.

Configuring the AMF Request

Now that we have a request set up we need to specify the arguments for the call. The is where I had troubles with jMeter – setting up the data required proxies and additional tools. There was no where to easily create & edit AMF object to pass along in the AMF request.

Enter soapUI. Lets say we have an API method called getMonkeys(). getMonkeys() requires an array of ids that specifies what monkeys we want in the list. The name of this parameter is ‘monkeyIds’.

  1. In soapUI, right-click the AMF Request object and select ‘Open Editor’. You should see a window similar to the following:
    AMF Request Editor
  2. In the text field for ‘Endpoint’ enter your service end point. For example:
  3. Enter the name of your call in the text field for the AMF Call setting: For example Monkey.getMonkeys
  4. Just under the entry for Endpoint add property to the property list for the call by clicking the ‘Add Property’ button.
    New Property Button
  5. Enter ‘monkeyIds’ as the name of the property. If the value for this property were a simple value we could enter it into the value column. We need an array though.
  6. To set the value for the property we’ll use the script window just under the property list.
  7. In the script window, enter the following to create an Array that contains the id values 1,2 & 3 and assigns that Array to the monkeyIds parameter.
    parameters[“monkeyIds”] = [1,2,3];
  8. That is it. The call for getMonkeys() is set up.
  9. To test the call click the little green arrow in the top left of the AMF Request editor.
  10. If your paths and data are set up correctly, you should see an XML formatted response in the window to the right of the Script editor.
    soapUI AMF Request Result

Creating and Running a Load Test

So now we have a test for a service, but we wanted to get some load testing done. If you’re looking for quick and simple load testing, you don’t have to go much further than soapUI itself. To create a load test in soapUI:

  1. Right-click the ‘Load Tests’ node under ‘Test Steps’ -> ‘New Load Test’
  2. Name the new load test and click ‘OK’
  3. 2 steps. That’s it, the load test is set up. You can run the test “as-is”.

Now, this is a very simple load test and there are a ton of things you can add to the test to improve it to build more useful load tests within soapUI.

Running Load Test with loadUI

The other tool I mentioned, loadUI, is built to integrate with soapUI and make load testing “easier and more efficient”.

Once loadUI is installed can you execute the test case that you set up in soapUI in loadUI.

  1. Right-click the test case, then select ‘Run with loadUI’.
  2. You will be prompted to save the project, do so.
  3. Select ‘Fixed Rate for the ‘Default Generator’ selection – this will determine how “clients” are generated for the load test.
  4. Select ‘Statistics’ for the ‘Default Statistics’ selection – this will display a graph for the load test metrics.
    loadUI Test Settings
  5. Click ‘OK’.
  6. loadUI will launch.
    loadUI Sstartup
  7. Click the ‘Play/Stop’ button to start the load test.
    load Play/Stop Button

You can play around with the Generator settings to change the rate at which clients are created to see changes in the load test results while the load test is running.
loadUI Generator

loadUI Stats

To view a report of the results you can click the ‘Summary Report’ button in the top right of the loadUI interface.
loadUI Summary Report Button

This is just a simple load test and there are plenty of additional settings, assertions and analysis tools that can be added, adjusted and tweaked to improve the validity of the load tests.

Next Steps

Our next step is to integrate the tests into our Continuous Integration (CI) system. We use Jenkins and I saw this post about Automating loadUI and Jenkins (formerly Hudson). So, in theory it can be done. I’ll let you know what we get worked out on that end when we get there.

So far, I’m pretty excited about the two tools. They are very useful, and free to boot. Hey SmartBear – you really are smart, thank you – you rule.


Extra Eclipse Tool Bars?

I finally spent the time to figure out how to remove extraenous buttons in my Eclipse tool bar. The one that annoyed me the most was the CFEclipse toolbar – it is huge!


Don’t get me wrong CFEclipse rocks, but it shows up in every perspective that I use. So here is how to remove it from the Eclipse toolbar.

  1. Right-click on Eclipse’s main tool bar you should see the following menu:
  2. Next select “Customize Perspective”. You’ll get a popup window.
  3. Select the “Commands” tab.
    Commands Tab
  4. In the left column, find CFEclipse and uncheck it.
    Uncheck Eclipse
  5. Click “OK” and check out your uncluttered toolbar!

This will only change the settings for the current perspective, and if you miss your tool bar, just repeat teh steps except check CFEclipse and it is right back where is was.