HLS streaming via HTTPS: how to avoid timeouts - caused by poor HTTPS handling in Wowza

Greetings!

We’re using Wowza 3.6.4.

We use a HLS VOD streaming application, streaming audio (m4a/mp3). We have a problem with timeouts occurring while accessing the chunks, which happens in this scenario:

The client (player) requests the m3u8 playlist, then the chunklist, then the AES key, and then starts sequentially requesting the audio chunks.

On the client we set it up to pre-buffer about 90 seconds ahead, so the client quickly requests about 9-10 chunks at the beginning of the stream (each chunk is 10 seconds long). Then the player may be playing for about 15-20 seconds before it requests a couple more chunks, etc.

Often, when the delay between chunk requests is bigger than 15 seconds, we see on the client side that the chunk request times out (timeout on the client side is set to 4 seconds), and the player retries the chunk request, and usually succeeds.

On the wowza server side, I always see the seek event logged in the access log in this scenario. The timestamp of the seek in wowza access log is the time when client retried the request (not of the original request which timed out). There are no stop and destroy events logged (I’ve changed newSessionTimeout from 8000 to 60000, and validSessionTimeout from 25000 to 1800000). I.e. in the access log, I see the play event, and then seek events occur when the client keeps a pause of 15-20 seconds between chunk requests.

Questions:

  1. Is there a parameter which could be used to avoid timeouts when requesting chunks?
  2. Why/when does wowza treat a request to a chunk as a seek event?
    (Note, as I’ve mentioned above, that the player makes sequential requests to the chunks, there is no real seeking occurring in the player).

I’d like to add, that we had annoying problems with timeouts when accessing not only the chunks, but also the HLS playlists (m3u8). This was happening not for everybody, but the severity of the problem was differing between clients.

Some of our clients were virtually unable to receive the content from Wowza: the requests to playlists and to chunks were timing out. Setting the timeout on the player side and retrying the request to playlist did not help at all: most of the requests were timing out.

For other clients the situation was better, with occasional timeouts, and after a few retries the player was usually able to receive the content.

Now it seems that this turned out to be caused by Wowza’s handling of HTTPS: our wowza server serves HLS over HTTPS, and it was configured via VHost.xml.

It seems that the problem was solved after installing haproxy behind wowza to handle HTTPS.

I’ll need to get confirmation from some of our users that the problem is solved, but from what I’m seeing from the logs, it looks like it is solved. It is very frustrating that there was such a nasty problem in HTTPS handling which created so many problems.

So I’m letting others know that if they will have problems with timeouts, and they’re using HLS over HTTPS, they could try to solve this problem by using haproxy or a similar reverse HTTPS proxy.