Feature request: keep HLS stream alive even if source stops updating

[yesthatjwz]

Sometimes my video source is unable to keep streaming to nginx-rtmp due to network errors or other problems. In that case, I would prefer for the stream, as seen by the end users, to continue streaming instead of hanging up.

As it is now, when the source goes away, the number of segments listed in the m3u8 file will begin to decrease, and when they reach zero, the m3u8 file itself goes away and becomes 404. Then the end user's player goes into a "stop" state, and they have to hit "play" again some time later to get it to resume.

What I would like to do, is to be able to configure a single static .ts file containing a looping video of colorbars, and when no "live" upstream segments are available, leave the m3u8 file with one or more copies of that "colorbars" segment in it; and then for it to go back to the normal segments once the real upstream source returns. The trick, of course, is that to make this work, the sequence number has to keep increasing. So trying to fake this out using location / try_files can't work; I think this feature would have to be built into nginx-rtmp itself to work. (I experimented a bit here.)

In this new model, the end user's player would stay in the "play" state the whole time, just with some colorbars in the middle, and they would not have to manually hit "play" again once the source came back online.

I hope you'll consider it. Thanks!

[winkmichael]

You can do this yourself pretty easily without any modifications to nginx-rtmp.

Here are instructions to make a color bar sequence (make sure its the same resolution as the video you are producing). Once you generate the bars file, you are done with ffmpeg. Then just run the bash script forever and it will check if the m3u8 is missing and plop in the sequence file in place. When nginx-rtmp starts up again it will just overwrite the file popped in by the bash script.

Step 1. Generate a color bar sequence
ffmpeg -f lavfi -i smptebars=s=1280x720 -f lavfi -i sine=frequency=1000:duration=90
-c:v libx264 -c:a aac -ar 44100 -ac 2 -t 90 -hls_time 10 -hls_list_size 9 -hls_wrap 9
-start_number 0 -hls_segment_filename "colorbars_%03d.ts" colorbars.m3u8

Step 2. Create a bash script that plops the m3u8 file in place if nginx didn't make it. (This needs to run forever)
#!/bin/bash

LIVE_PATH="/var/www/hls/live"
COLORBARS_PATH="/var/loopfiles"
SEQ_NUM_FILE="$LIVE_PATH/seq_num.txt"
HLS_PLAYLIST="$LIVE_PATH/stream.m3u8"

Initialize the sequence number if it doesn't exist

if [ ! -f "$SEQ_NUM_FILE" ]; then
echo 0 > "$SEQ_NUM_FILE"
fi

while true; do
SEQ_NUM=$(cat $SEQ_NUM_FILE)
LIVE_SEGMENT="$LIVE_PATH/stream${SEQ_NUM}.ts"

if [ ! -f "$LIVE_SEGMENT" ]; then
    # Use the pre-generated colorbars playlist
    ln -sf "$COLORBARS_PATH/colorbars.m3u8" "$HLS_PLAYLIST"
else
    # Use the live stream playlist if available
    rm -f "$HLS_PLAYLIST"
    ln -sf "$LIVE_PATH/live.m3u8" "$HLS_PLAYLIST"
    echo $((SEQ_NUM + 1)) > "$SEQ_NUM_FILE"
fi

sleep 1

done

Step 3. Profit?

[yesthatjwz]

Maybe I'm missing something, but doesn't that mean that on the transition from colorbars back to live video, EXT-X-MEDIA-SEQUENCE as seen by the client will no longer be monotonically increasing, which would stop the video? Once we're using an m3u8 file that was generated by nginx-rtmp itself the sequence number in it will no longer match $SEQ_NUM_FILE. "colorbars.m3u8" can't just be a static file, the EXT-X-MEDIA-SEQUENCE sequence in it has to be dynamically updated, and match any segments that came before/after.