How can I use remote smil files for multi bit rate playlist (m3u8) for hls playout?

I have a web app that has all the info about the videos stored for a given media.

I am able to create smil file on the fly based on the device type. Url looks something like this

http://{mywebsite}/ws/vod_smil/type/{iPad}/media/{mediaId}.smil

Actual s3 videos are stored on s3 bucket and smil has appropriate path for s3 bucket. Is there a way to use this remote smil file instead of creating on in wowza.

Hello!

Thanks for contacting Wowza Forums!

Here are some instructions on how to stream a remote smil file.

Use the MediaCacheLocalContent module instead, as this may be better suited for you.

https://www.wowza.com/docs/media-cache-implementation-that-will-first-try-to-access-content-locally-before-getting-it-from-a-remote-source-mediacachelocalcontent

Once you have copied over the module’s jar file to your Wowza server’s lib folder, perform these steps:

  1. Remove ModuleMediaListPathSelector from your list of modules for your vods3 application.

  2. Add the following as a Custom Property to your vods3 application in the /Root/Application/MediaReader properties container. Ensure that you are adding it to the correct container. Do note this is a custom property, and not a module. You are instructing the Wowza software to load this new module as the MediaReader.

randomAccessReaderClass

com.wowza.wms.plugin.RandomAccessReaderMediaCacheLocalContent

String

  1. Create a directory tree in your local content/ folder that mirrors your mediacache path. Copy your SMIL file to this directory. For example, you should have the following SMIL file location: /content/amazons3/your_path/file_name.smil

Your SMIL file should have the following src:

Can this module work with the amlst module described in this article? I have that functionality (a modified version of the amlst module) working perfectly for both VOD and live, now I want to move lesser-used files to S3. This plugin appears to be what I need to do that, but I want to keep the dynamic SMIL/m3u8 generation too.

Thanks ~

Yes, the AMLST module shouldn’t interfere with the MediaCacheLocalContent module. The amlst: and smil: prefixes are distinct from one another.

Understood. I think I poorly described my intentions, though… Here’s the behavior I have now, which is a lightly modified version of the AMLST module:

- receive amlst: request (ex. amlst:foo)
- iterate through possible renditions (ex. foo-1, foo-2...foo-5) to see if they exist in the storage directory, and generate the manifest accordingly (only containing the renditions that exist)
- return the manifest to the client

Here’s the behavior I need:

- receive amlst: request (ex. amlst:foo)
- iterate through possible renditions (ex. foo-1, foo-2...foo-5) to see if they exist in the storage directory, and generate the manifest accordingly (only containing the renditions that exist)
[b]- if nothing exists on the local server, then iterate through the renditions again, checking if they exist in the S3 bucket, and generate the manifest accordingly (only containing the renditions that exist)[/b]
- return the manifest to the client

It seems like it should be possible without too much difficulty, by combining some of the functions from AMLST some from the MediaCacheLocalContent module. I haven’t sat down to poke at it yet, but will take any advice/pointers/better ways you have.

Hi,

Yes, the AMLST module shouldn’t interfere with the MediaCacheLocalContent module. The amlst: and smil: prefixes are distinct from one another.

Regards,

Paul