Configuring content storage

The presence of an application folder within the applications folder tells the server that the application exists. By default, the applications folder is located at rootinstall/applications.

Within the applications folder, create subfolders for your applications. Within each individual application folder, create subfolders to create instances of applications. For example, the following path is to an instance of an application called “my_application”:

rootinstall/applications/my_application/first_instance

To change the location of the applications folder and the live and vod applications, edit the locations in the following parameters in the ams.ini file:

• Registered applications folder: VHOST.APPSDIR

• Live application: LIVE_DIR

• Vod application: VOD_DIR

Mapping directories to network drives

By default, the server runs as System Account with no access to network drives. You can change the service user to a user with network access privileges with a UNC path.

A Windows network-mapped drive is not valid when a user is logged out. If the server is running as a service and the user is logged out, the mapped drive is removed as well. To run with the mapped drive, lock the server instead of logging out. Using the UNC path is preferred when the server is running as a service.

Setting the location of recorded streams and shared objects

By default, all recorded streams for an application are stored in a streams folder in the application directory. Shared objects are stored in a shared objects folder in the application directory.

Use the StorageDir tag in the Application.xml file to specify a different location to store streams or shared objects. You could do this for vod applications. For example, if you already have a collection of video files in a directory other than the application directory, you can set the storage directory to that other directory instead of copying content to the application directory.

When you specify a value for the <storageDir> element in the application-specific XML, that value is specific to the application. Otherwise, when you specify a value in the virtual host-level Application.xml, the scope is extended to all the applications on that virtual host.

Within the directory that you specify as the storage directory, you must create physical subdirectories for different application instances. Adobe Media Server sandboxes the content for each instance of an application.

Let’s say, for example, you set the storage directory to C:\Content for the chatApp application:

When a user connects to the firstRoom instance of the chatApp application and tries to play a stream, the server looks for the stream in a subfolder C:\Content\firstRoom. Content for each instance is sandboxed from other instance of the same application; a user who connects to the secondRoom instance would not be able to access the content in C:\Content\firstRoom.

If you do not want resources to be sandboxed by application and application instance, use virtual directories.

Mapping virtual directories to physical directories

Adobe Media Server stores recorded streams and video and audio files in default locations in the application directory. In some scenarios, you might want to specify particular locations for these resources, but without restricting access by application or application instance. By mapping a virtual directory to a physical directory, you do not need to copy resources to Adobe Media Server’s application directory, and you can retain your existing classification and categorization of resources.

To map a virtual directory for an application, you can use the <VirtualDirectory> element in the Vhost.xml or the Application.xml file. This element provides various options:

• You can specify a virtual directory name or not. When a name is specified, the server maps the name to the specified directory and first looks for the stream in the specified directory.

• You can specify multiple physical directories for a single virtual directory. Use multiple <Streams> tags.

• When specified in an application-specific Application.xml file, <VirtualDirectory> controls only the storage location of resources for that application. Any instance of the application can access video files in that location (unlike with <storageDir>), but other applications cannot.

• When specified in the virtual-host Application.xml file or the Vhost.xml file, <VirtualDirectory> controls the storage location of all applications on that virtual host. All applications on the virtual host can access video files in the specified location, although Adobe recommends that if you want control at the virtual host level, you configure the <VirtualDirectory> tag in Vhost.xml file instead of the virtual-host Application.xml file.

If you are creating a new virtual directory for a File object (as opposed to a stream), you must also enable the VirtualDirectoryForFile option in the Server.xml file. For more information, see Enable virtual directory mappings for server-side File objects.

The order in which the server determines the correct directory to use for streams is as follows:

Virtual directory example: vod

One usage scenario for this element is to specify a directory to use for a specific vod application and put video files in this directory to stream them instantly. You would use the <VirtualDirectory> element in the application-specific Application.xml file. To map a directory in this way, edit the application-specific Application.xml file to include the virtual directory, as shown in the following example:

This code overrides the VHost.xml file’s mapping of '/' (if it exists) for this application only. To play a file in the virtual directory, such as C:\my_videos\sample.flv, a client connects to the vod application and calls NetStream.play():

The <VirtualDirectory> element in the application-specific Application.xml file affects only that application, protecting your streams from being accessed by other applications on the same virtual host. It overrides settings in the Vhost.xml file.

Playing streams nested in subfolders

To play a stream, specify the codec before you specify the path to the stream. FLV streams don’t require a codec prefix, but F4V/MP4 files, MP3 files, and RAW files do.

Suppose the virtual directory mapping is <Streams>foo;C:\my_videos</Streams>. The following examples are for the client-side NetStream.play()method:

The following are examples for the Server-Side ActionScript Stream.play() method:

Virtual directory example: Separating high- and low-bandwidth video

One way you can use directory mapping is to separate storage of different kinds of resources. For example, your application could allow users to view either high-bandwidth video or low-bandwidth video, and you might want to store high-bandwidth and low-bandwidth video in separate folders. You can create a mapping wherein all streams that start with low are stored in specific directories, C:\low_bandwidth and C:\low_bandwidth2, and all streams that start with high are stored in a different directory:

When the client wants to access low-bandwidth video, the client calls ns.play("low/sample"). This call tells the server to look for the sample.flv file in the C:\low_bandwidth and C:\low_bandwidth2 folders.

Similarly, a call to ns.play("high/sample") tells the server to look for the sample.flv file in the c:\high_bandwidth folder.

Note that if the client calls ns.play("sample"), the stream name does not match any virtual directory specified, so the server will then look for sample.flv inside the directory specified by the storage directory element (<storageDir>). If no storage directory is specified by <storageDir>, then the server looks in the default location (the streams folder) for the file; that is, the order in which the server looks for files is:

Virtual directory example: Local and network file paths

The following table shows three examples of different virtual directory configurations, including mapping to a network drive, and how the configurations determine the directory to which a recorded stream is published. In the first case, because the URI specified ("myStream") does not match the virtual directory name that is specified ("low"), the server publishes the stream to the default streams directory.