Results 1 to 7 of 7

Thread: Content Served dynamically from Object File System ?

Hybrid View

Previous Post Previous Post   Next Post Next Post
  1. #1
    Join Date
    Jan 2014

    Question Content Served dynamically from Object File System ?

    I have a scenario where I would like Wowza to provide VOD access to video located in an external object file system.

    The key here is that the video files location will not be in <wowza>/content directory, in fact each video could be on different mounts in the a file system (without a common root folder). The file system where the physical files are located can additional abstracted a reference to each file to a unique numeric ID.

    Assuming one of the likely thousands of media files was location at the following path on the Wowza Server /mnt/nas23/media/projects/alpha/experiment-12.mp4 my options are:

    • Option 1 - Present the URL to the consumer with the full path to the file which may be from the root of the host machine (i.e. mp4:/mnt/nas23/media/projects/alpha/experiment-12.mp4).
    • Option 2 - Develop a plugin that would allow to provide the numerical ID of the content file (mp4:12345) which the plugin Java code could then convert to /mnt/nas23/media/projects/alpha/experiment-12.mp4 internally.

    So my questions are:

    • If I went with Option 1 how do I tell Wowza to assume the path to the file is from the machines root and not some local content or application folder ?
    • If I went with Option 2 (my preference) what are the relevant API interfaces for me to interpret and remap the path to the file from 12345 to /mnt/nas23/media/projects/alpha/experiment-12.mp4

    Any advice would be gratefully received.

  2. #2
    Join Date
    Dec 2007


    You can do this with MediaCache, which allows you to serve content stored on a web server, a NAS drive or any local drive.


  3. #3
    Join Date
    Jan 2014


    Thanks for the pointer. I have downloaded the MediaCache Addon as well as the StreamNameAlias Addon and am currently reading through the documentation.

    I may be wrong but so far It seems like a rather heavyweight solution to a simple problem.

    All I want to do is intercept the incoming stream name and internally get a file from somewhere (undetermined until execution) based on that. I am very happy to use the Wowza API to create a Java plugin to do this which will internally include the API calls to the object file system to get the hook to the file at the end returning either Path, FileInputStream or similar.

    The StreamNameAlias Addon source looked pretty hopeful until I noted that it is just performing translation of the name and not intercepting and returning the physical file reference, which is what I would like to do. All I really need is a pointer to which API I should use to intercept the incoming request to Wowza and return the current file path or file stream, etc?

    Any advice would be gratefully received.

  4. #4



    The StreamNameAlias AddOn uses the IMediaStreamNameAliasProvider interface to resolve the playback names. In the default implementation, it does just resolve the name however, you could use your own implementation and use the resolvePlayAlias method as a point to get the file information you need before returning the full path.

    There are a few thing to note.
    1. The path returned must be relative to the Streams/StorageDir set in the Application.xml. You should set your StorageDir to point to where the Nas storage is mounted (/mnt/). You would then return something like
    2. ../ is not allowed and will be removed.
    3. Any network lookups should be cached locally to avoid performance problems.
    4. If null is returned from the resolvePlayAlias methods, the player will receive an error. You can use this method to prevent playback.
    5. If doing ABR streaming (smil file), the resolvePlayAlias method will be called for the smil file and for each of the video files listed in the smil file. You should be sure to handle this.
    6. resolveStreamAlias is not needed in this case as it is only used for live mediaCaster connections.

    Streaming directly from a network location such as Nas storage is not recommended as the network connection may cause a performance problem. Every play request for a file will open a separate connection to that file. For this reason, we recommend using the Mediacache AddOn which caches a local copy of the content that is requested. Multiple players will use the cached copy instead of hitting the storage directly.

    With MediaCache, you can still use the aliasing to resolve the name and you are not restricted to where the StorageDir is pointing as it is not used. Instead, you would return the MediaCacheSource prefix followed by the asset path.
    You can have a separate store listed for each Nas location or just have the top level folder as the store location.

    From the resolvePlayAlias method, you would return something like this:

    Separate Sources. Source path is /mnt/nas23/media/ and prefix is nas23/:
    Single Source. Source path is /mnt/ and prefix is content1/:
    Local storage for the MediaCache just needs to be large enough to handle the currently cached content and a small ssd drive would work fine in this case. You can adjust the TTL's to control how long content remains cached.


  5. #5
    Join Date
    Jan 2014


    Interesting. Thanks Roger.

    There are multiple possible "Source" roots and these can be (re)configured without our knowledge, but they are abstracted by the object file system. Additionally caching is performed automatically by the object file system if required so the caching in MediaCache would potentially double-cache the resource.

    I am working on the assumption that I need to create a custom implementation of IRandomAccessReader that simply returns the chunks from the object file system as required. This is probably the cleanest way to do this at the moment. I'll report back and share any conclusions I find.

    Thanks for your help.

  6. #6



    I'm not sure that you will need to go as far as a custom IRandomAccessReader implementation. The default implementation will read from a nas partition, it just wont be as efficient as reading from a local disk.

    Take a look at the IMediaStreamFileMapper interface in the package. You can implement your own FileMapper to map to anywhere in the file system when the stream is requested. This is called by the default reader and will get you around the limitation of the StreamStorageDir location.

    Even though the storage is caching the content, I would be careful that the network connection between Wowza and the storage doesn't become a bottleneck.


Similar Threads

  1. Dynamically generate smil file for multibitrate.
    By sharmi in forum General Forum
    Replies: 8
    Last Post: 03-07-2013, 05:08 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts