HLS - Multiple Problems

[djpimp2010]

I am having a few problems with HLS streaming (live stream, not VOD style).

1. I can only watch the HLS stream from the beginning. If a stream has been running for a few minutes, I get nothing. My phone (testing) does not receive any data.
2. There is a 30 second delay on the HLS stream. I am watching the same stream on RTMP, which only has 1-2 second delay.

Config:

worker_processes  1;

error_log  logs/error.log  debug;

rtmp_auto_push on;
rtmp_auto_push_reconnect 1000ms;

events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile        on;
    keepalive_timeout  65;

    server {

        listen      8080;

        # This URL provides RTMP statistics in XML
        location /stat {
            rtmp_stat all;

            # Use this stylesheet to view XML as web page
            # in browser
            rtmp_stat_stylesheet stat.xsl;
        }

        location /stat.xsl {
            # XML stylesheet to view RTMP stats.
            # Copy stat.xsl wherever you want
            # and put the full directory path here
            root /opt/nginx-rtmp-module/stat.xsl/;
        }

        location /hls {
            # Serve HLS fragments
            types {
                application/vnd.apple.mpegurl m3u8;
                video/mp2t ts;
            }
            root /tmp;
            add_header Cache-Control no-cache;
        }

        location /dash {
            # Serve DASH fragments
            root /tmp;
            add_header Cache-Control no-cache;
        }
    }

}

rtmp {
    server {
        listen 1935;
        chunk_size 4086;

        application watch {
            live on;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 2s;
            hls_playlist_length 10s;
        }
    }
}

FFmpeg command:

/opt/FFmpeg/ffmpeg -f video4linux2 -i /dev/video0 -an -vcodec libx264 -crf 1 -maxrate 8000k -bufsize 10000k -preset ultrafast -tune zerolatency -s 768x576 -g 50 -vf "drawtext=fontfile=/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf: text='%{{localtime\:%F %T}}': fontcolor=white@0.5: x=0: y=0 :box=1:boxcolor=0x00000000@1" -f flv rtmp://localhost/watch/VIDEO

[djpimp2010]

I have been debugging all night, and I have found that once a HLS live stream is actually running, if I pause it, it resumes from the same place.
This acts like the directive hls_type is set to event, even though the directive was not set. I have tried setting it to live (default), but it behaves the same.

And it seems like the problem with joining a stream that has been running for a few minutes starts occurring once the first few .ts files are "cleaned up". If the stream is up to chunk 500, but 1,2 and 3 are missing, it won't start the stream at all (like its looking for the first few)

I have inspected the m3u8 file, and it seems to be accurate, with removing earlier chunks that have been deleted, but I can't see the option X-PLAYLIST-TYPE.

Here is a sample:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:70
#EXT-X-TARGETDURATION:6
#EXTINF:6.000,
BACK_ALLEY-70.ts
#EXTINF:6.000,
BACK_ALLEY-71.ts
#EXTINF:6.000,
BACK_ALLEY-72.ts
#EXTINF:6.000,
BACK_ALLEY-73.ts
#EXTINF:6.000,
BACK_ALLEY-74.ts
#EXTINF:6.000,
BACK_ALLEY-75.ts

[djpimp2010]

I would mark this as resolved.

I added the following to the /hls location in the nginx httpd server:

            if_modified_since off;
            add_header Last-Modified "";
            etag off;
            add_header Cache-Control "no-cache";

This allows me to join a stream mid-broadcast, because it always gives me the most recent m3u8 file.

Then I changed my HLS config to the following, which reduced stream latency to 10-12 seconds (which is pretty good - and probably the best I will get) - I also has to force a keyframe every second to be able to achieve such small HLS fragments:

        application watch {
            live on;
            hls on;
            hls_path /tmp/hls;
            hls_fragment 1s;
            hls_playlist_length 10s;
            hls_base_url http://192.168.0.201:8080/hls/;    
        }

I hope this helps other people stuck in this situation.

[djpimp2010]

Note: this config has not solved the stream resuming from the same place if paused, instead of jumping forwards to the current "live" position.

I think I can live with what I have so far though.

[winlinvip]

Need to update both the settings of encoder and media server, see HLS low latency settings