Silly Noob Question apparently about VOD File Location Change

Okay. I have done searching for about the past hour and am at a loss on this one.

I am getting ready to offer VOD from our storage location to our downstream clients. Each client will have their own cloud container file (Rackspace) and I will want to pull content for them from that, not from some central store. I am tracking file storage usage for billing, so really central store is a non-starter.

I am using this cloud container as a record location, so I know that Wowza sees it fine. I can VOD using HLS from the content folder without a hitch, but I can’t figure out the right syntax for the cloud container.

Here is the file hierarchy:

Cloud Containers are in:

/media/cloud

with each account folder having syntax account_xxx, where xxx is the unique client identifier.

I have tried to set the VOD folder to:

/media/cloud

and then access the file with:

http://{IP ADDRESS OF SERVER}:1935/vod/mp4:Account_772/sample.mp4/playlist.m3u8

have also tried:

http://{IP ADDRESS OF SERVER}:1935/vod/Account_772/mp4:sample.mp4/playlist.m3u8

The mount is made via Cloudfuse, which should be agnostic in this deployment, but I include for completeness. In essence it is part of my file hierarchy, just in a totally different place.

I could conceivably create a symbolic link in the content/vod folder, but consider that to be a hack not a solution. If my streaming applications can access the cloud folder, the VOD instance must be able to as well. I just can’t figure it out.

There has to be one or two out there that have reconfigured this to work with other directories on your install instance. How did you do it?

Quite frankly, I am more and more impressed as I start to see what I can do with Wowza and if I can figure this out, I just saved enough money to move my Wowza server to co-located bare metal. If I can’t figure this out, I am looking at other solutions for this which would be duct-taped on top of what I already have.

Thanks for anyone’s help.

Cheers,

Bob

Hi Bob.

This is just a hunch, but you might try adding “definst” to the playback url:

http://{IP ADDRESS OF SERVER}:1935/vod/_definst_/mp4:Account_772/mp4:sample.mp4/playlist.m3u8

When content is outside the [wowza-install-dir]/content folder, or in a sub-folder of /content you need to add definst after the application name in the playback url.

I sure hope this helps.

Regards,

Salvadore

My take: If you can access /media/cloud via shell, it should work.

Change your VOD content location to /media/cloud first, copy the sample file there and use it directly (without subfolders). If it does not work that means the systems cannot access your folder /media/cloud (I’d try making a symlink too). If it works, then use the syntax you have used above:

http://{IP ADDRESS OF SERVER}:1935/vod/_definst_/mp4:Account_772/sample.mp4/playlist.m3u8

try rtmp first just to test/rule out the http access issue.

hope that helps…

Best wishes

Inderjeet

Hi,

Firstly, I don’t have experience with rackspace cloud for such a requirement.

outside of its install location for recording of incoming live streams to a Rackspace Cloud Container, it is not possible to do so for VOD content. I can set an absolute path in the application.xml, but once I go to a cloud container, it goes pffffttt.

After reading this I was a little confused, so read your opening post again. If I am correct, you have two objectives:

  1. Record stream to cloud container location

  2. Serve recorded vod content from that location

Are you able to at least read VoD content from the cloud storage (objective2) or not? You are trying to record to a cloud location directly? Regardless of whether you can or not, I would try to avoid that approach for various reasons, one being Wowza unable to access it properly (it is not a real filesystem, so being accessed over network) and another being error handling and connectivity problems. I would use a conventional approach instead - record here then move and serve from there.

Please excuse if I am found misleading somewhere just trying to help. Still don’t have a proper visualization of the setup in my mind.

I like to think I am a pretty smart guy, but for some reason I am not succeeding on this one.

You’re asking questions, that proves you’re not wrong. And we all get stuck over a minor thing once almost every week. Then Andrew, Charlie, Richard and others come with their expertise and provide directions towards the eureka moment.

Sincerely,

Inderjeet

That’s what I would have thought, but what happens when “Account_772” is down the file hierarchy.

Basically, Account_772 's full address is:

/media/cloud/Account_772

and I have tried the following:

http://{IP ADDRESS OF SERVER}:1935/vod/definst/mp4:/media/cloud/Account_772/mp4:sample.mp4/playlist.m3u8

failure

http://{IP ADDRESS OF SERVER}:1935/vod/definst/mp4:media/cloud/Account_772/mp4:sample.mp4/playlist.m3u8

failure

http://{IP ADDRESS OF SERVER}:1935/vod/definst/media/cloud/Account_772/mp4:sample.mp4/playlist.m3u8

failure

Symbolic links seem to confuse the Wowza vod instance.

I know I am missing something fundamentally obvious once I do it, but I am at a loss. I did try working with symbolic links, but it looks like the Streaming Engine has issues with it.

Salvadore - thanks for the hunch, though. The definst confuses me a little, and am trying to figure out why I can’t just drop a fill path for the content directory.

I haven’t yet gotten into the Media Caching portion of WMS, but I am also wondering if my solution is there.

Bob

I think what I have found is that while Wowza can traverse the file hierarchy outside of its install location for recording of incoming live streams to a Rackspace Cloud Container, it is not possible to do so for VOD content. I can set an absolute path in the application.xml, but once I go to a cloud container, it goes pffffttt.

I think the answer is the MediaCache, and is probably the more scalable solution for my deployment as I need to redirect into individual client folders as I can not pull from a central location, and need the cloud container for scalability into the future.

So, been working with MediaCache and a vod_edge application and am a bit frustrated. All the documentation seems to be something I am not understanding for my implementation. It looks like a File Source will not work with Rackspace’s cloud containers, and I haven’t spent anytime with http as I think that will be where I am at for this and just symbolic link to my cloud containers.

My question now becomes I am looking for anyone who has scaled this particular hill before me that can point me in the right direction. Someone who is doing either Rackspace cloud containers and VOD, or MediaCache with the source being those cloud containers, or more preferably both.

I like to think I am a pretty smart guy, but for some reason I am not succeeding on this one.

Thanks for all the thoughts, and thanks for any assistance in the future.

You can also reach me at my email below.

Thanks,

Bob

bob.bohanek@uroomtech.com

You have my objectives right. I haven’t moved recording to cloud container yet, but plan on doing that this week. I have tested it on our dev server and it works from a single use case. The write speeds should be good (that is my assumption), and with cloudfuse (kindof a variant of sshfs as I see it) it just mounts as a file directory like any other. Wowza Live applications record to it fine. So objective 1, while possibly flawed architecturally, is met. As to the architecture, once we work on event end detection and script execution, I may go back to a local store for video files, but I am looking for some scale on the record side, so cloud is the answer right now.

As to objective 2, it is failing. At least in the VOD single server instance. The more I look at MediaCache, the more I think that is where I am going. Again, cloud containers for read access are failing in this instance as well (using file as the MediaCache source). I am looking into the http strings of our files and think that http as the media cache source is the answer. My frustration is that the documentation is a bit lacking and I would like to see a sample deployment so I can deconstruct what the pointers are and all that. It’s my learning style possibly that is getting in the way. I think Media Cache is the way to go, though. I will do what I can to document my solution and architecture so that I give back a little.

Working towards the solution. Thanks for the thoughts and support.

Cheers,

Bob

Hi,

After reading this I was a little confused, so read your opening post again. If I am correct, you have two objectives:

  1. Record stream to cloud container location

  2. Serve recorded vod content from that location

Are you able to at least read VoD content from the cloud storage (objective2) or not? You are trying to record to a cloud location directly? Regardless of whether you can or not, I would try to avoid that approach for various reasons, one being Wowza unable to access it properly (it is not a real filesystem, so being accessed over network) and another being error handling and connectivity problems. I would use a conventional approach instead - record here then move and serve from there.

Please excuse if I am found misleading somewhere just trying to help. Still don’t have a proper visualization of the setup in my mind.

I like to think I am a pretty smart guy, but for some reason I am not succeeding on this one.

You’re asking questions, that proves you’re not wrong. And we all get stuck over a minor thing once almost every week. Then Andrew, Charlie, Richard and others come with their expertise and provide directions towards the eureka moment.

Sincerely,

Inderjeet

Okay,

With some help from Wowza support I figured it out. The problem for me was how I was setting my base path. When I read “base path is the HTTP URL where the content can be found” I assume it was a more fully qualified URL, it is in fact not. It is nothing more than “http://” and that’s it.

so, for HLS my full URL to access the video file through the Mediacache looks like this:

http://{ADDRESS OF SERVER}:1935/vod_edge/definst/mp4:http/{HTTP LINK PULLED FROM RACKSPACE}/playlist.m3u8

You can access the HTTP link either through the GUI for your cloud files or through API. We will be storing it when the client uploads the file through our interface.

Media Cache will give us some scale, though JW Player can play the files right from Rackspace in some limited manner. JW Player and Media Cache gives us the ability to support different downstream clients, which I like.

Thanks for everyone’s help on this.

Cheers,

Bob