Search code examples
node.jsamazon-s3live-streaminghttp-live-streamingm3u8

HLS Live streaming with S3 - are these assumptions correct?


I want to make a live stream. And, I want to use HLS.

I understand that a HLS live stream is just a main playlist file with '.m3u8' extension that lists all the files to be played.

But, for live stream, since all the files are not available readily, they are added as they come in.

I want to use S3 for now to host these files and the playlist file.

Now, I want to update the playlist file in S3. But it's actually going to replace the existing playlist file instead of just updating it (according to this answer).

So, I'm assuming that there will be no dead-time during the file replace. If there is a dead-time, how do I overcome it? Is this the way to do it or is there some other better way to do this.

I'm using a NodeJS server, just FYI.

*dead-time time when there is no file.


Solution

  • I want to make a live stream. And, I want to use HLS.

    Why HLS? Why not DASH? DASH is also segmented and implemented almost exactly as HLS, but has more flexibility as far as codec choice and what not. Either is fine, but if you're starting from scratch today, I recommend DASH, and the DASH.js reference player code, which uses Media Source Extensions.

    I understand that a HLS live stream is just a main playlist file with '.m3u8' extension that lists all the files to be played.

    Correct.

    But, for live stream, since all the files are not available readily, they are added as they come in.

    Correct.

    Now, I want to update the playlist file in S3. But it's actually going to replace the existing playlist file instead of just updating it

    Yes, and as the other answer noted, there's no difference. The playlist file will be overwritten with the new full copy. The S3 API doesn't allow appending to a file, unless doing a multi-part upload which really isn't the same thing. In any case, your playlist file for a live stream isn't going to contain each and every segment anyway. Usually you only keep the last handful of segments in the playlist, but this is up to you to decide how far back to go.

    So, I'm assuming that there will be no dead-time during the file replace.

    S3 doesn't replace that object until the full new object is uploaded and stored. There will never be a case where a partial file is there. S3 isn't like a regular file system. Additionally, if a subsequent upload fails, the old object is still going to remain.

    HLS and DASH players read the playlist and buffer a ton of data before beginning playback. (This is why they notoriously have high latency.) It will be several seconds before the new segment is uploaded and added to the playlist, so it's important that they already have data in the buffer to play. This is why you don't have to worry about any drop-out, unless there is a failure to upload in time.

    I'm using a NodeJS server, just FYI.

    Is that so? Sounds like you're using S3 to me... not sure what Node.js has to do with any of this.