Problem reproducing live stream


I am doing tests reproducing a live video. I have used my own web page and also the “Live” page in dashboard and in both this problem occurs.

By using developer tools of Chrome, I realized that from time to time, a 404 error is produced. Here an example of a normal video chunk, that returns 200 status code:

In that case, the content type returned is application/ which is right. It also has an ETAG as 5f7cc3a4-130a

Following to the above chunk, the exact same link returns a 404 error:

In this case, the content type returned is text/html which is clearly wrong. And it also does not have an ETAG header.

And following above, other links returned 404 error also. For example, this:

Look at the name. It contains 1080p instead of 480p as before.

that behaviour persists some other chunks, then, other kind of links are retrieved:

After other several links, again m3u8 files are received. The most strange thing is that the streaming never got interrupted.

What is going on with that?


Now we dig into the weeds a bit Jaime :smiley:

The m3u8 file is a manifest file, it lists the next segments or chunks for the player to download and play. Here is an example (that I just streamed):


There are 3 segments listed here. Let’s look at the first one:
EXTINF is saying the next chunk is 2 seconds long. The next line is the file to download to play those 2 seconds of video.

The manifest above has 3 chunks listed. That’s 6 seconds of video that that player “knows what to do with.”

If the next m3u8 fails, its ok, the player still has a few seconds of video before it needs the next…

The 480p to 1080p - These are the different encodings we are creating for you. In this case, the player is jumping from 480p to 1080p.

The other files - those are analytics firing in the player so that the results can be reported back to

Summary: the manifest file tells the player about the next 3 chunks of video. That means there is 6 seconds of video that is playable. The next manifest should arrive before the last chunk finishes playing (so that chunks 4, 5, 6, etc. can be identified), but a small hiccup does not affect playback.