How to modify M3U8 URLs?

I’ve got Wowza streaming HLS/M3U8 streams perfectly. However, I’m now trying to run them through my CDN (EdgeCast). The initial playlist comes through fine on the CDN. But the contents of the playlist point directly to my origin Wowza server, which obviously can’t handle thousands of connections. I need the URLs inside the playlist to point back to the CDN so that it will pull the .ts files from Wowza and then cache and deliver them.

This seems like a simple thing…how do I tell Wowza to use different URLs in the M3U8 file?

Try adding this poperty to both the LiveStreamPacketizers/Properties and HTTPStreamers/Properties containers in [install-dir]/conf/[application]/Applicaiton.xml:

<Property>
	<Name>cupertinoRelativePlaylistPlaylists</Name>
	<Value>true</Value>
	<Type>Boolean</Type>
</Property>

Charlie

First, we really don’t support being an HTTP origin for a CDN. It is a feature we plan on adding sometime in the future but it is not a use case we have designed for or tested.

That being said, it is most likely possible to make it work. For San Jose and Smooth streaming the playlist and chunk URLs are already relative. It is only Cupertino streaming that by default has absolute playlists.

Charlie

Adding support to be a proper HTTP cache origin for HTTP streaming is a feature we are investigating for a future release of Wowza.

Charlie

We really do not currently support being a caching origin. We do not have instructions for how to make this work. Folks have used us in this scenario but I am not sure how they accomplished it.

Charlie

There is not an equivalent for Smooth (or Sanjose) streaming. Ref

Richard

You will have to ask Edgecast for more info on how they have this working.

The load test tool uses rtmp vod or live streaming for testing.

Richard

You can see connection counts in a browser at:

http://[wowza-address]:8086/connectioncounts

More info:

https://www.wowza.com/docs/how-to-monitor-server-connections-load-and-application-statistics

Load test tool works with RTMP only but is a re estimation of capacity for mixed clients.

Richard

Edgecast might have some way of doing this but it is not directly supported in Wowza. Chunks are not cached in Wowza. So you have to ask Edgecast support how to go about this, this is the wrong place to ask.

Richard

I’m not sure, I don’t think so.

Richard

It is still not supported at present, but still a possible future feature, but no set timeframe

Richard

Mike,

Using Wowza as a HTTP origin is a near-future feature, but not quite yet. I do not have an exact time frame but it is on deck. At present you can push RTMP to a CDN.

Richard

PlanetIx,

Did you get this working with Edgecast? If so, can you say if it required a fancy http rules config on the Edgecast side or did you guys figure out hot to manipulate the Wowza-side of the configuration?

We too are stuck with Wowza’s changing SessionIds and inability (afaik) to set the max-age values on the playlist and chunks.

We’re still working on it. Edgecast’s support and dev team are great. I’m setting up test streams for them and they are figuring out how to use a cache rule that ignores the session id part of the filename. If they get it working I’ll post how.

I understand you don’t officially support this, and I’m not knocking you for it, but if possible it would be great if you guys would take a look at adding even an unsupported way to do it, as it seems like a fairly simple thing to do from your end, and would greatly boost the value of Wowza.

Hey Guys- did anyone have any joywith this?

Thanks for this! I was going to ask the same question.

How can I do the same for SmoothStream streams as well? Would this work?:

cupertinoRelativePlaylistPlaylists

true

Boolean

smoothRelativePlaylistPlaylists

true

Boolean

Wait, does this mean then that only the playlist itself will be ingested by my CDN, and the actual contents will still be pulled from the local Wowza server? Or are things handled differently with Smooth Streams and Wowza?

First, we really don’t support being an HTTP origin for a CDN. It is a feature we plan on adding sometime in the future but it is not a use case we have designed for or tested.

That being said, it is most likely possible to make it work. For San Jose and Smooth streaming the playlist and chunk URLs are already relative. It is only Cupertino streaming that by default has absolute playlists.

Charlie

Is it a feature being considered for Wowza 3? It seems to be more or less working as is so I am curious as to what additional stuff you are planning on adding.

I tested my connections and you are right, it does appear the chunks themselves are being pulled and distributed through Edgecast. Connection-wise I don’t appear to be seeing multiple connections - is there a specific log file/way I can check this in Wowza? I am using the AWS version.

As for working, I’ve had a live test stream running off a camera in my building for 4 days straight now and it hasn’t dropped, not for Silverlight or Apple. I even have a flash client (JW Player) connected to the Cupertino stream using JW Player’s alpha AdaptiveStream module (testing it with them) which allows Flash to connect to m3u8 playlists, and even it’s working well. I plan on doing heavier testing with multiple streams later but thought you guys would like to know so far, so good.

Let me know if there’s an easy way to see how many connections are being made to the Smooth Streaming manifest.

Update: I figured out the log part; when I initiate a connection on multiple remote clients, the only connection I see in the Wowza access log for the Smooth stream is from Edgecast’s pull source, which is as it should be. Is there somewhere else to check or is that more or less it?

Does the load test work with HTTP live streams or just RTMP live streams? The response above is unclear on that point.

Thanks!

Is this for live? Are you seeing any caching on edgecast. I am attempting to do the same thing but for purposes of only having to maintain one set of tokens for token authentication (using edgecast’s token authentication). I set the Wowza up as my origin and wrote a server side module to append the tokens to the playlist segments to handle geofencing and leach prevention. However, since each playlist entry has a “sessionid” that is unique to the connection I am wondering how much caching actually occurs. I know wowza has a load testing tool, does it test HLS or only rtmp?

I am not seeing caching; for example on the live test stream I have running now, that I am using Edgecast to pull from Wowza I have 12 connections; in my Edgecast control panel under real time stats/HTTP Large I see the connections, and at the bottom they report as “uncachable”. Which, for a live stream is a good thing unless I am badly mistaken about how Edgecast and live streams work. I haven’t checked VOD yet because I already have my VOD files stored in Edgecast’s cloud and I just stream direct from them, though I am considering doing some Wowza integration to take advantage of the packetization stuff it does for different devices.

Strange, at the moment it does appear that HTTP origin isn’t being cached for Smooth Stream or Cupertino - every connection I initiate on Edgecast creates it’s own connection back to Wowza. I did the url fix for Cupertino streams mentioned in this thread - with relative paths, shouldn’t it be caching the stream? Is there any other setting I can look at that might be causing this?

Thanks, I’ve engaged their support on this issue. Maybe there is some setting they have that is telling them not to cache the stream. I will update the thread if I find an answer for the benefit of anyone else having this problem.