EdgeCast RTMP Repeater

Greetings,

I am practically new to wowza, but I have read several tutorials that got me started on the right track.

I have purchased Wowza on EC2 and have set up an application which I will be using to repeat RTMP streams from my EdgeCast account. This application would enable me to deliver the stream to mobile devices (iOS, android, blackberry, etc...).

It seems I'm not getting the hang of the format that should be passed in the ".stream" file.

This brings me to the second point:

Am I able to get the application to repeat rtmp streams without hardcoding the links into a .stream file? Is there a way I could dynamically pass these links? (such as with stream alias or something like that?)

I appreciate your help as I have been searching around for several hours only to bump into dead ends.

EDIT 2: Just in case it makes any difference, I am obviously trying to set up a repeater for live RTMP streams, not VOD.

I will try messing around just in case I had some misconfiguration in my encoder or in the stream file or something.

Second, what do you think about the other question

Am I able to get the application to repeat rtmp streams without hardcoding the links into a .stream file? Is there a way I could dynamically pass these links? (such as with stream alias or something like that?)

The reason I have folders in a live stream is because of the way the server-side archiving works in EdgeCast.

Assume I set the FMS URL in the Flash Media Live Encoder to
rtmp://fso.ams.xxxx.edgecastcdn.net/20xxxx/firstfolder/secondfolder and the Stream to 'mystreamname', at the end of the streaming event an archived copy of the stream would be saved to that directory (/firstfolder/secondfolder). Therefore, having folders in the FMS URL facilitates the structure of the archived files by placing them into certain folders.

In order to play the live event, I set the following variables in JWPlayer:

I have purchased Wowza on EC2 and have set up an application which I will be using to repeat RTMP streams from my EdgeCast account.

I am trying to pull the RTMP stream from Edgecast's FMS and repeat it using Wowza (in order to serve the stream to mobile devices).

It appears to me now (correct me if I'm wrong) that the structure of the link in EdgeCast's FMS is different from that of Wowza.

Edgecast expects that the 'streamname' be only the filename, and the 'streamer' to be the rtmp link including the folders,

whereas Wowza is attempting to connect to the RTMP url, and provides the filename as the streamname and the folders. (as wowza follows the url/applicationinstance/streamname structure)

And that is why Wowza is unable to connect to the stream when the url contains a list of subfolders but is able to do so when the structure contains only one folder (eg:
rtmp://server.com:1935/folder/streamname).

Again, thank you a lot for your prompt responses Richard. I appreciate that.

The original poster is correct and the provided solution will not work. In this particular case this is exactly what is happening:

Assuming edgecast live stream is:

rtmp://domain/accountid/path1/path2/mystream

specifically, this actually means:

fms server: rtmp://domain/accountid/path1/path2

stream name: mystream

However using the *.stream file or the stream name alias system, Wowza will send the stream to edgecast incorrectly as follows:

fms server: rtmp://domain/accountid/path1

stream name: path2/mystream

So the question really is, how can we have greater control over how Wowza parses a complete rtmp url so that is sends the correct server and stream name values?

note that we have confirmed this by examining logs on both sides. _definst_ was added at each position to no avail, and edgecast urls limited to rtmp://domain/accountid/path1/streamname will work. The issue is when more than one path segment is included in the live url.

I am also looking for the same solution. Our problem stems from the fact that it appears that Wowza can't handle deep linked app instances. It assumes one instance level which will not work for my company.