Hls.js: how make video straming real-time without delays, because of some buffers in hls.js and nginx-rtmp-module

[proxy-m]

Environment

• [x] The stream has correct Access-Control-Allow-Origin headers (CORS)
• [x] There are no network errors such as 404s in the browser console when trying to play the stream
• [x] The issue observed is not already reported by searching on Github under https://github.com/dailymotion/hls.js/issues
• [x] The issue occurs in the latest reference client on http://dailymotion.github.io/hls.js/demo and not just on my page
• Link to playable M3U8 file:
• Hls.js version: v0.6.3
• Browser name/version: ANY
• OS name/version: ANY

Steps to reproduce

1. Use nginx + nginx-rtmp-module for streaming as HLS.
2. Use ffmpeg to move online video stream from RTSP camera to nginx.
3. Use hls.js to get HLS stream from nginx in browser JavaScript.

Expected behavior

No some seconds video delay from real time video.

Actual behavior

Delay near 15 or even more seconds, because of video buffering.

Question:

How to make buffers minimum as possible (e.g. something like 1 second or even less)?
I need real-time online streaming.

[chjcken]

I think it is impossible to make someone watch your live stream without any second delay

I assume your fragment target duration is 2 second. It means ffmpeg need 2 second buffer to make a new fragment ready to download (2 sec delay on server). Then your hls config liveSyncDurationCount = 1, it means hls.js will seek to the last fragment of your playlist (2 sec delay on client) and browser need to buffer a little bit more to be able to play
=> delay is now at least 4 second ignore network delay

I tried this approach and the actual delay is about 5-7 sec and will increase if up stream or down stream network congests

ps: if you need your stream really real time, you may try udp protocol for up stream (webrtc maybe) to be able to drop old data when network is unstable and another player than video tag and MSE to ignore bufferring and play the newest data (h264 live player I suggest). Certainly you have to do everthing by yourself :D good luck

[proxy-m]

Looks like after changing liveSyncDurationCount from 3 to 1, video delay is changed from 10-15 to 4-5 seconds. Thank you.
It's better, but not the best.
Do you suggest to see this: https://github.com/131/h264-live-player ?

[chjcken]

yes that's what I suggest,
you should take a look at it if you want more real time, but there will be a lot of things to do if you follow that approach

ps: with hls.js, 4s delay is my best record

[campones]

simple.. use rtmp, I don't think real time is possible with hls streaming

[matansagee]

@campones but how do you play RTMP in chrome?

[dhassoun]

Flash

[hoodsy]

@proxy-m mind sharing your nginx config for 4-5s delay?

[proxy-m]

@hoodsy

user nginx nginx;
 events {
     worker_connections  1024;
 }
 rtmp {
     server {
          listen 1935;
          chunk_size 3000;
          buflen 1s;
          application hls {
              live on;
              hls on;
              hls_path /home/cameras/hls_online;
              hls_fragment 600ms;
              hls_playlist_length 5s;
          }
      }
  }
http {
 ...........................
}

Lesser values may cause bufferisation problem.

[campones]

that will make a lots of request imagine if you have 1000 watchers on a small server.. in my case i m using php to create a unique token and that takes a lot of ressource itself so I had to setup a 20s fragment

[proxy-m]

@campones, I have not 1000 watchers. I have 3 watchers maximum.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[fcheong3b]

If you are looking for real-time streaming and 0 delays you should use WEBRTC instead of using HLS or RTMP that by default have a delay time.

[johnBartos]

@fcheong3b LHLS will be contributed to Hls.js by JW in Q4 (it's on our roadmap). But it's an HTTP implementation so WebRTC will still be faster.