Configuring content storage

Setting the location of application files
Mapping directories to network drives
Setting the location of recorded streams and shared objects
Mapping virtual directories to physical directories

Setting the location of application files

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 fms.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.

Stop Flash Media Server and Flash Media Administration Server.
Make the changes to the configuration.
Check that the server user has appropriate access rights to map to the network drive (system account rights are usually not sufficient.)
Restart Flash Media Server and Flash Media Administration Server.

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.

Note: Adobe strongly recommends that folders that store streams always contain only streams and no other application files.

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. Flash 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:

<storageDir>C:\Content</storageDir>

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

Flash 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 Flash 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.

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

Virtual directory (as specified in <VirtualDirectory>)
Storage directory (as specified in <storageDir>)
Default location (the streams folder in the application directory)

Note: Adobe strongly recommends that folders that store streams always contain only streams and no other application files.

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:

<Application> 
    <StreamManager> 
        <VirtualDirectory> 
            <!-- Specifies application specific virtual directory mapping for recorded 
            streams.   --> 
            <Streams>/;C:\my_videos</Streams> 
        </VirtualDirectory> 
    </StreamManager> 
</Application>

This code overrides the VHost.xml file’s mapping of '/' (if it exists) for this application only. A connecting client will be able to play a file in the virtual directory, such as C:\my_videos\sample.flv, by connecting to the vod application and issuing a NetStream play() call:

ns.play("sample");

or by passing "rtmp://myDomain/VOD/sample.flv" to the source property of a call to FLVPlayback.play().

The <VirtualDirectory> element in the application-specific Application.xml file affects only that particular application, protecting your streams from being accessed by other applications on the same virtual host. It has a higher precedence than the virtual directory mapping in the Vhost.xml file, so it will always be checked first.

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:

<VirtualDirectory> 
    <Streams>low;c:\low_bandwidth</Streams> 
    <Streams>low;c:\low_bandwidth2</Streams> 
    <Streams>high;c:\high_bandwidth</Streams> 
</VirtualDirectory>

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.

A client connects to the sample.flv file in the low-bandwidth storage area on the server, which is mapped in Application.xml.

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 (as specified in <VirtualDirectory>)
Storage directory (as specified in <storageDir>)
Default location (the streams folder in the application directory)

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.

Mapping in Vhost.xml

<VirtualDirectory><Streams> tag

URI in NetStream call

Location of published stream

low;e:\fmsstreams

"myStream"

c:\...\RootInstall\applications\yourApp\streams\_definst_\myStream.flv

low;e:\fmsstreams

"low/myStream"

e:\fmsstreams\myStream.flv

low;\\mynetworkDrive\share\fmsstreams

"low/myStream"

\\mynetworkDrive\share\fmsstreams\myStream.flv