Which setting to increase m3u8 request timeout

[Jay_Charles]

As part of my live application, the app module needs time to negotiate with http services and connect up to an FMIS origin server to pull down a live stream to serve to clients.

I’m finding that regardless of what I do, I’m having circumstances where m3u8 requests are timing out, and I suspect I’m not changing the appropriate configurations. The process is like so:

1. Client requests m3u8 file from http://[server]/app/instance/stream/playlist.m3u8

2. Wowza serves this file right away

3. Client requests the session m3u8 file from http://[server]/app/instance/stream/playlist.m3u8?wowzasessionid=XXXXXXXXXX

4. If the app instance hasn’t connected up to the origin server and started packetizing the ts files, the request times out after 8 seconds, and Wowza returns 404 headers.

In the configurations, which value controls the timeout for the second m3u8 request? Is it newSessionTimeout, validSessionTimeout, requestTimeout, or another config that I’m missing? I’ve tried increasing all of them as high as 60000 in my application.xml, and none of them seem to have any effect

Thanks,

Jay

[Charlie_Good]

If you are pulling the stream from another source then you need to use the stream manager or conf/StartupStreams.xml to start the stream and keep it running. There is a not a reasonable way to have the stream from the origin to the edge start on demand. It is just to slow and the iOS devices need too much buffered video.

Charlie

[Richard_Lanham]

If you use /conf/StartUpStreams.xml on the edge to start the FMIS stream on a Wowza app edge using MediaCaster “liverepeater”, then packetizing on the edge should start when the server starts, and the iOS request will not timeout or 404. In this case, you want to use the regular LiveStreamPacketizers not the repeater types.

Richard

[Richard_Lanham]

You could have the phone load a HTTProvider which checks the stream, starts it if necessary using MedaCaster API, and returns HTML/video with playlist.m3u8 url in the response, then start streaming.

And you might be able to use javascript to handle video tag errors and retry a couple of times. This looks like a good reference:

http://www.chipwreck.de/blog/2010/03/01/html-5-video-dom-attributes-and-events/

Richard

[Richard_Lanham]

Also see this example for the javascript reloading a video tag

https://www.wowza.com/docs/how-to-do-pre-roll-and-playlist-for-ios-a-client-side-work-around

Richard

[Jay_Charles]

Thanks Charlie.

Looking back at my code, I see that my Stream object (which is what clients subscribe to) doesn’t get created until after the httpservice calls happen. If I’m understanding you correctly, if I create that object while my onappstart is running, that should stop the problem with the 404 being returned?

[Jay_Charles]

Well, ok, that just results in the 404 being returned immediately.

So, what can i do to delay the m3u8 response on the second request while I’m waiting for the data to start coming in from the origin? It seems to me that I just need to buy myself a few more seconds.

[Jay_Charles]

Alright… I think I found what I need. Looks like I can just set up a conditional in the onHTTPCupertinoStreamingSessionCreate method to see if my stream is playing anything. Needs tweaking, but at least I have an in point to deal with it.

[Jay_Charles]

Thanks Richard,

My challenge is that with the CDN I’m working on, the origin stream could be on any of a number of origin servers. That’s why I need the webservice call before I hook up to the origin… need to find out if the origin stream is live, and if so, which origin server it resides on. So, that rules out a StartupStream, as i won’t know if there is an origin stream or where it lives until I have the webservice data.

[Jay_Charles]

I’m now able to wait for the origin stream to come in, but it seems that I also need to wait for the cupertino packetizer to build up the first packet if I am to keep with Apple’s suggested chunk duration of 10 seconds.

I connect to my origin using MediaStreamMap.acquire(), and then playing the resulting MediaCasterStreamItem’s IMediaStream over another Stream object (the stream subscribers connect to). I’m finding that if I use liverepeater or live as the stream type, processor use goes through the roof as soon as the origin stream starts coming in. if I use liverepeater-edge, processor use is nearly zero.

When using liverepeater-edge, and playing over a Stream object at what point does the packetizer start? Does it start as soon as the MediaCasterStreamItem starts, or does it not start until I have accepted the first cupertino session?

[Jay_Charles]

One more question. It seems that overriding the value for an HTTPStreamer in my application.xml does not affect the timeout for a livestream repeater… I have to modify the value in conf/HTTPStreamers.xml to make it work. Do I need to override elsewhere in application.xml to make it work without modifying conf/HTTPStreamers.xml?

[Jay_Charles]

You could have the phone load a HTTProvider which checks the stream, starts it if necessary using MedaCaster API, and returns HTML/video with playlist.m3u8 url in the response, then start streaming.

And you might be able to use javascript to handle video tag errors and retry a couple of times. This looks like a good reference:

http://www.chipwreck.de/blog/2010/03/01/html-5-video-dom-attributes-and-events/

Richard

Yup… tried that. Unfortunately, older versions of iOS don’t dispatch an error event to javascript (I think that was fixed in 4.0… 3.2 just displays the broken play button in the quicktime player and never dispatches the onerror event)