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 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+.
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:
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>
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>
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.
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:
![]()
With the dvrInfo:
![]()
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.
<HLS>
<MediaFileDuration>8000</MediaFileDuration>
<SlidingWindowLength>450</SlidingWindowLength>
</HLS>
<Event> <EventID>myliveevent</EventID> <Recording> <FragmentDuration>4000</FragmentDuration> <SegmentDuration>400000</SegmentDuration> <DiskManagementDuration>1</DiskManagementDuration> </Recording> <HLS> <MediaFileDuration>8000</MediaFileDuration> <SlidingWindowLength>450</SlidingWindowLength> </HLS> </Event>
<Application>
<StreamManager>
<Live>
<AssumeAbsoluteTime>true</AssumeAbsoluteTime>
</Live>
</StreamManager>
<HLS>
<MediaFileDuration>8000</MediaFileDuration>
<SlidingWindowLength>450</SlidingWindowLength>
</HLS>
</Application>
<Location /hls-live> HLSHttpStreamingEnabled true HttpStreamingLiveEventPath "../applications" HttpStreamingContentPath "../applications" HLSMediaFileDuration 8000 HLSSlidingWindowLength 450 HLSFmsDirPath ".." HttpStreamingUnavailableResponseCode 503 ... </Location>
There are quite a few ways to test the HLS content:
6 Responses
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?
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.
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
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. :\
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.
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.