Cleaning Up After Adobe Media Server Live HDS Events

After broadcasting a live event using using Adobe Media Server (AMS 5) you’re left with a bunch of files (.control, .meta, .bootstrap, .f4f .f4x). When you start the live event back up, things can get wonky and you won’t be able to use that live event again. This can be problematic if you have a regular live event that you want to broadcast and don’t feel like setting up a live event or don’t want to have a bunch of live events hanging around on your server all the time.

Telling AMS to Clean Up

There is an easy solution – you can tell AMS to clean up after it’s self when the application is terminated. Meaning that the files that are deposited in the /streams directory are removed and ready for another live event. This saves space on your server and it saves you the headache of having to manually clean up the files.

The Clean-up Command

To get AMS to clean up the live event files, add the following directive to the application’s Application.xml file:

<ScriptEngine> 
 <ApplicationObject> 
 <config> 
 <clearOnAppStop>true</clearOnAppStop> 
 </config> 
 </ApplicationObject> 
</ScriptEngine>

After you restart the application, broadcast a live event, then stop the live event and then unload the application, you should see that the files have been cleared from the stream directory.

NOTE: You can add this directive to the server level Application.xml, but I would suggest keeping it on the application level.

Configuring AMS for Real

For a default install of AMS using the “livepkgr” application, open the Application.xml file in the {AMS_INSTALL}/applications/livepkgr directory.

Add the following xml as a child of the <application> node:

<ScriptEngine> 
 <ApplicationObject> 
 <config> 
 <clearOnAppStop>true</clearOnAppStop> 
 </config> 
 </ApplicationObject> 
</ScriptEngine>

Save and close the file.

Do a little live streaming and notice the files being created in the {AMS_INSTALL}/applications/livepkgr/streams/_definst_/livestream directory.

Before Clean Up

Stop broadcasting your live stream and either wait for the livepkgr application to unload or use the admin concole to unload the application. As soon as the application is unloaded, the livestream directory should be removed from {AMS_INSTALL}/applications/livepkgr/streams/_definst_ effectivley cleaning up your server for you.

Clean Up After

I thought this was a nice little find, what do you think?

Let me know in the comments.

What is HTTP Dynamic Streaming?

HTTP Dynamic Streaming FlowUntil now video content delivery over HTTP has been delivered in a progressive manner, meaning to view part of or seek to a specific location in the video you have to wait for that part to download. RTMP allows for the ability to seek to any point in the video content via streaming, but requires a server technology such as the Flash Media Server to do this. HTTP Dynamic Streaming or HDS combines HTTP (progressive download) and RTMP (streaming download) allow for the ability to deliver video content in a steaming manner over HTTP. This means:

  • A streaming server technology is not required
  • Clients can access and begin playing content ‘instantly’
  • Clients can seek to points in the video content that have not yet downloaded.

…and all the above over the HTTP protocol.

There are a of couple things that you’ll need to consider when getting started with HTTP Dynamic Streaming.

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. We’ll cover the installation, set up and data flow for the HTTP Origin Module in a subsequent post.

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. There is a tool, the f4fpackager, that Adobe has created to do this for you and we will discuss the details of this tools and how you can use it later as well.

F4Fragment ExtractorAt Realeyes, we’ve done some some work with AIR and the F4F file format spec to create the The F4Fragment Extractor.  The F4FragmentExtractor is a utility for extracting the F4V fragments from the F4F files created by Adobe’s file packager for HTTP streaming. This means that you can deploy the fragments produced by this tool  to any Web server or cloud services like Amazon S3 and reap the benefits of HDS even without the HTTP Origin Module.

In the next few articles, we’ll look at:

  • Getting Started with HDS
  • Use cases for HDS
  • Integrating HDS into your content creation workflow

Between now and when I get to the next post let me know if you have any questions or would like to see something specific about HTTP Dynamic Streaming in the comments.