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="http://ns.adobe.com/f4m/2.0"> 
    <baseURL>http://localhost/hds-live/livepkgr/_definst_/liveevent/</baseURL> 
    <media href="livestream1.f4m" bitrate="150"/> 
    <media href="livestream2.f4m" bitrate="500"/> 
    <media href="livestream3.f4m" bitrate="700"/> 
</manifest>

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

<manifest xmlns="http://ns.adobe.com/f4m/2.0"> 
    <dvrInfo windowDuration="30"/>
    <baseURL>http://localhost/hds-live/livepkgr/_definst_/liveevent/</baseURL> 
    <media href="livestream1.f4m" bitrate="150"/> 
    <media href="livestream2.f4m" bitrate="500"/> 
    <media href="livestream3.f4m" bitrate="700"/> 
</manifest>

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 :

<Application> 
    <HDS> 
        <Recording>     
            <FragmentDuration>4000</FragmentDuration> 
            <SegmentDuration>16000</SegmentDuration> 
            <DiskManagementDuration>4.5</DiskManagementDuration> 
        </Recording> 
    </HDS> 
</Application>

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

<Event> 
    <EventID>liveevent</EventID> 
    <Recording>     
        ... 
        <DiskManagementDuration>4.5</DiskManagementDuration> 
    </Recording> 
</Events>

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="http://ns.adobe.com/f4m/2.0"> 
    <dvrInfo windowDuration="30"/>
    <baseURL>http://192.168.1.113/hds-live/livepkgr/_definst_/myliveevent/</baseURL> 
    <media href="mylivestream.f4m" bitrate="300"/>
</manifest>

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 http://thekuroko.com/samples/hds/myliveevent.f4m
  2. Go ahead and start up your live stream.
  3. Then open the following URL: http://www.osmf.org/dev/2.0gm/setup.html
  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:
    <HLS> 
        <MediaFileDuration>8000</MediaFileDuration> 
        <SlidingWindowLength>450</SlidingWindowLength> 
    </HLS>
  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:
    <Event>
      <EventID>myliveevent</EventID>
      <Recording>
        <FragmentDuration>4000</FragmentDuration>
        <SegmentDuration>400000</SegmentDuration>
        <DiskManagementDuration>1</DiskManagementDuration>
      </Recording>
      <HLS>
          <MediaFileDuration>8000</MediaFileDuration>
          <SlidingWindowLength>450</SlidingWindowLength>
      </HLS>
    </Event>

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:
    <Application> 
        <StreamManager> 
            <Live> 
                <AssumeAbsoluteTime>true</AssumeAbsoluteTime> 
            </Live> 
        </StreamManager> 
        <HLS> 
            <MediaFileDuration>8000</MediaFileDuration> 
            <SlidingWindowLength>450</SlidingWindowLength> 
        </HLS> 
    </Application>

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
        ...
    </Location>

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: http://192.168.1.114/hls-live/livepkgr/_definst_/myliveevent/mylivestream.m3u8
  3. VLC
    1. From the main menu choose “File” -> “Open Network”
    2. Then type in the URL to the .M3U8 – Ex: http://192.168.1.114/hls-live/livepkgr/_definst_/myliveevent/mylivestream.m3u8
  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.

Resources

  • Disk management: http://help.adobe.com/en_US/flashmediaserver/devguide/WSeb6b7485f9649bf23d103e5512e08f3a338-8000.html#WSec225f632fa00875-23954b6f1300b641158-8000

13 Replies to “Configuring DVR HTTP Live Streaming”

  1. Can the DVR f4m manifests be tuned for VOD content to restrict skipping ahead? Otherwise I think that http progressive download (HPD) would be the only other way to do this but with all the issues related to it – im not sure what no scrubbing/skip ahead would look like with HDS compared to HPD – basically the same thing in the end (except more buffer space taken up on local disk for the clientside?) And the additional lack of failover to other servers available via manifest tweaking, I guess :/

    Ideas?

    1. Ken – that sounds more like something the player would handle rather than the content. So, the player wouldn’t allow for seeking ahead. Then it wouldn’t matter if the content were HDS or Progressive.

      1. hi John – that would work technically, but wouldnt satisfy the license holder’s requirements for DRM and other motivations for removing skip-ahead – anyother hacked client could then request any Frag/Segment as they want of course. Also requires a customized coded client, I would think? Or is there a way in the F4M manifest to specify no skip ahead that Strobe or other OSMF-compliant players obey if we were to go with player-side limitation?

        Thanks

        1. There isn’t a way to specify that kind fo restriction for HDS content using the F4M.

          One thought – You could “fake” a live stream using the VOD content, but then you’d have the performance hit on the server if there was any kind of load.

          Another thought – Build/Update a HTTP Origin Module that would restrict how fragments are returned to a client, but that is a fairly huge undertaking.

          Securing HDS content can be a headache. :

        2. Another thought is you could use SWF Verification to restrict what player and from what domain can actually play the content back. Then you have some pretty good control.

          I’m not positive, but I think most players only allow you to enable/disable the control bar and not seeking specifically.

  2. Can the DVR f4m manifests be tuned for VOD content to restrict skipping ahead? Otherwise I think that http progressive download (HPD) would be the only other way to do this but with all the issues related to it – im not sure what no scrubbing/skip ahead would look like with HDS compared to HPD – basically the same thing in the end (except more buffer space taken up on local disk for the clientside?) And the additional lack of failover to other servers available via manifest tweaking, I guess :/

    Ideas?

  3. i was thinking php to ensure that you had to download the frag/segs in chunks (say on pre segfrag’d content, using the frag extractor tool), but again, serverload perhaps be high for many clients.

    I’d authenticate the download based on having requested previous chunks at the exact bitrate-based-time-delay would be needed to have downloaded it in the first place, yaddayadda. Bunch of pedantic coding required there :/

    But i dont see what benefits that would give over http progressive anyway. Breaking scrub forward means there’s no benefit over HPD, except perhaps the f4m fallback alt-url/server stuff. Not worth the work in this case, I think. :/ Some round robin DNS and manual failover for now will do us fine.

  4. Can the DVR f4m manifests be tuned for VOD content to restrict skipping ahead? Otherwise I think that http progressive download (HPD) would be the only other way to do this but with all the issues related to it – im not sure what no scrubbing/skip ahead would look like with HDS compared to HPD – basically the same thing in the end (except more buffer space taken up on local disk for the clientside?) And the additional lack of failover to other servers available via manifest tweaking, I guess :/

    Ideas?

    1. Ken – that sounds more like something the player would handle rather than the content. So, the player wouldn’t allow for seeking ahead. Then it wouldn’t matter if the content were HDS or Progressive.

      1. hi John – that would work technically, but wouldnt satisfy the license holder’s requirements for DRM and other motivations for removing skip-ahead – anyother hacked client could then request any Frag/Segment as they want of course. Also requires a customized coded client, I would think? Or is there a way in the F4M manifest to specify no skip ahead that Strobe or other OSMF-compliant players obey if we were to go with player-side limitation?

        Thanks

        1. There isn’t a way to specify that kind fo restriction for HDS content using the F4M.

          One thought – You could “fake” a live stream using the VOD content, but then you’d have the performance hit on the server if there was any kind of load.

          Another thought – Build/Update a HTTP Origin Module that would restrict how fragments are returned to a client, but that is a fairly huge undertaking.

          Securing HDS content can be a headache. :

        2. Another thought is you could use SWF Verification to restrict what player and from what domain can actually play the content back. Then you have some pretty good control.

          I’m not positive, but I think most players only allow you to enable/disable the control bar and not seeking specifically.

  5. i was thinking php to ensure that you had to download the frag/segs in chunks (say on pre segfrag’d content, using the frag extractor tool), but again, serverload perhaps be high for many clients.

    I’d authenticate the download based on having requested previous chunks at the exact bitrate-based-time-delay would be needed to have downloaded it in the first place, yaddayadda. Bunch of pedantic coding required there :/

    But i dont see what benefits that would give over http progressive anyway. Breaking scrub forward means there’s no benefit over HPD, except perhaps the f4m fallback alt-url/server stuff. Not worth the work in this case, I think. :/ Some round robin DNS and manual failover for now will do us fine.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.