How to reduce latency

[xiliu]

1.there have 3 seconds delay when play local rtmp stream in vlc the local rtmp stream url like this:rtmp://127.0.0.1/live/123.flv. nging.conf is like this: application live { live on; play /usr/nginx/html/flv_file; } 2.there have 4 seconds delay when live local hls streaming video in vlc l the rtmp stream url like this:rtmp://127.0.0.1/hls/mystream. nging.conf is like this: application hls { live on; interleave on; exec_pull ffmpeg -re -i /usr/nginx/html/flv_file/123.flv -vcodec libx264 -vprofile baseline -g 1 -s 320x240 -ar 44100 -ac 1 -f flv rtmp://localhost/hls/mystream 2>>/var/log/11112qscallive2gs.log;

        hls on;
        hls_path /usr/nginx/html/hls;
        hls_fragment 2s;
    }

3.there have 7 seconds delay when live remote hls streaming video in vlc the rtmp stream url like this:rtmp://222.174.255.26/hls/mystream. nging.conf is like this: application hls { exec_pull /root/bin/ffmpeg -re -i /usr/local/nginx/vod/flvs/gs.flv -vcodec libx264 -vprofile baseline -g 1 -s 320x240 -ar 44100 -ac 1 -f flv rtmp://localhost/hls/mystream; live on; hls on; hls_path /tmp/app; } i using ffmpeg simulation real-time video streaming. i want to know how to reduce latency.

[arut]

RTMP latency is introduced by client. Please reduce client buffering time. The module does not introduce any latency.

[xiliu]

Thanks for your reply,

[andrenatal]

DASH and HLS introduces latency? I am having more than 20s of delay using dash.js and regular quicktime playing with hls on the mac. There is some directive I can use in .conf to reduce both latency?

[izemize]

Hi!

You using ffmpeg converting (rtmp to hls or dash), this causes latency. ᐧ

2014-12-09 5:24 GMT+01:00 Andre Natal notifications@github.com:

DASH and HLS introduces latency? I am having more than 20s of delay using dash.js and regular quicktime playing with hls on the mac. There is some directive I can use in .conf to reduce both latency?

— Reply to this email directly or view it on GitHub https://github.com/arut/nginx-rtmp-module/issues/378#issuecomment-66233102 .

[narlex]

I had the exact same delay you've described in VLC. As Arut said, it's the client introducing a buffer by default. To get around this, try running ffplay (should be in your ffmpeg directory) with:

ffplay -fflags nobuffer rtmp://222.174.255.26/hls/mystream -loglevel verbose

I've managed a 184ms latency this way with a 1080p stream. That's the furthest I've gotten so far, but keep in mind I'm using windows so my results may be very different.

[ubuntuaddicted]

That's insane, are we talking over WAN or in a LAN? I'd be happy to have around a 5 second delay similar to how hitbox does it now. The reason I want to not use hitbox is because I want h265 for 1080p streaming. Out of curiousity. What Type of bandwidth plan would I need if I were to host my livestream on a linode server and stream 720p using ffmpeg and h265, would probably be 1,000Kbps or even lower based on the compression I'm seeing with ffmpeg.

[narlex]

LAN, technically, though it wasn't even that. The stream was encoded and sent to a virtual machine, pushed back, and played in an embedded video player (Flowplayer because JWPlayer wouldn't get past some built-in buffer) on a webpage from the web server that I have the virtual machine setup as. As far as the encode goes, my aim was the lowest latency possible, so it absolutely eats at my processor. https://www.dropbox.com/s/x88jjjp6tzpg7ga/latency.png?dl=0 There's a screenshot of the actual time/method I used to find that latency. I just subtracted the times in the picture. To be honest though, I should have much lower latencies (under 50ms at least, given they expect 10ms from an 800x600 stream - http://x264dev.multimedia.cx/archives/249) so I'm still working on my setup. The big latency crushers for me were -intra-refresh 1, -tune zerolatency, and -pix_fmt yuv420p. It's been a fight with FFMPEG along the way with ~weird~ issues, but I've been trucking along somehow. It's all self-taught with virtually no media background though, so I'm very glad I've gotten as far as I have.

Here's my running config with FFMPEG if you'd like to compare: http://pastebin.com/6CZc9E8T

But really, if you want to get the lowest latencies, look into intra-refresh (http://x264dev.multimedia.cx/archives/249). I don't believe x265 has intra-refresh yet, so you may want to take a look at x264 again.

As for a bandwidth plan, I only ever stream for 1 or 2 buds to show them a game or something. Depending on your expected pool of viewers, find out where your encoding peaks bit-wise, and try to divide that fairly evenly from your potential bandwidth. Even though I target 6.5mbps for my bitrate, I often see it peak at up to 9mbps during heavy camera movement in my games so just remember to leave some room for those times.

[ubuntuaddicted]

with h265 being about double the compression why would you not choose it if you're in control of the end video player? wouldn't you just place video.js or any html5 video player on a webpage? thanks for sharing your ffmpeg encode line, i'm currently only using nginx for pushing a 2,000Kbps to both twitch and hitbox but i have big plans for my website. i believe i'll be able to stream 720p around 500Kbps using h265, i think.......... ;)

[narlex]

Ah. Truth be told, I'd wanted to try out h265 but heard it wasn't really finalized yet, and with the goal of the lowest latency possible, I was pretty biased on using intra-refresh so I went with h264. As for that bit rate, that's pretty crazy! I'll definitely check out h265 again if you're really able to get those kinds of numbers. I just hope the encoding process isn't that much more intensive.

[ubuntuaddicted]

This is a very interesting thread and I'm currently in the process of eliminating twitch, hitbox and all other services that force adds on my viewers and I can control the stream.

If it's just to show your buds a stream arent you aware of steam broadcasting? Not sure if the quality is the same but it completely simplifies your use case if all that has to occur is your friends be able to view your live stream. You can make your stream private AFAIK

[narlex]

@ubuntuaddicted Yeah, it just came out and while I'm glad it's as easy as right-clicking your friend and requesting to watch their stream, I've definitely had some issues with it, and I'm not really a fan of the 3500 kbps cap and lack of control. I'm definitely psyched though because it's so easy to find footage of more niche titles now as well as how Steam won't have you encode and push the frames until you actually have a viewer (this is my favorite part!). I'm looking forward to how they push this, but really hoping it's something that isn't forced in your face without an option to disable for those who aren't interested (I'm tired of seeing certain curators opinions on game pages).

As for Valve's In-Home Stream feature... That's a totally different beast. I couldn't get decent latencies from it until the latest update allowing you to enable hardware accelerated encoding and decoding as well as that gorgeous real-time stats graph. Though it pretty much stomped on all my efforts for my own solution, I can't wait to see the In-Home Streaming progress even further as it may potentially allow me to do "local coop" gaming with buds far easier than my current methods, but I'm totally glad for everything I was able to learn when pursuing that project on my own.

I've got tons of questions you may be able to answer, so I'll throw you a private message (so this thread doesn't keep pestering others with updates) some time when I get back into my streaming project. Your experience would be pretty great to learn from, and maybe you'll have some opinions on improvements I could make, which would be great to hear!

[psfabio]

"RTMP latency is introduced by client. Please reduce client buffering time. The module does not introduce any latency."

And about the buflen?

Thanks

[godivyam]

there is a latency between the rtmp published to hls app and the m3u8 generated by nginx-rtmp-module. Around 5 secs. I am using hls_fragment 2s; hls_playlist_length 6s. In the ffmpeg process publishing to hls app I am forcing key frames every 2.2 secs (here I tried different values e.g.:1s,5s 2.2 secs gave me the best results). Any hints as to what is introducing this delay and how I can reduce it ?

[ls0f]

@izemize You using ffmpeg converting (rtmp to hls or dash), this causes latency. how reduce the latency when using ffmpeg forward stream.

[ls0f]

exec /usr/bin/ffmpeg -re -i rtmp://localhost/src/$name -acodec copy -vcodec copy -f flv rtmp://localhost/hls/$name; using ffmpeg forward stream have 3 seconds delay @xiliu @izemize You have solved?

[matansag]

@narlex can you please share your ffmpeg command? Thanks

[matansag]

@narlex Also if you can share with us how did you measure the latency. 10x!

[fredleger]

@narlex your links are down. i know it's 2014 old but it still have some value to understand the ffmpeg flags. Can you push your ffmepg setup in this thread ?

[narlex]

@matansag @fredleger Sorry for the delay, I've fixed the https://www.dropbox.com/s/x88jjjp6tzpg7ga/latency.png?dl=0 link.

For measuring latency, just open a window with http://www.lagom.nl/lcd-test/response_time.php#response_time_gif (scroll down for the clock that says "Ready...") and have another window on the side with your videoplayer playing your video stream. Once you run that timer, just take a screenshot and subtract the numbers.

As for my running-config, I'm not sure what I used at the time, but it was likely this. ffmpeg -f dshow -i video="screen-capture-recorder" -pix_fmt yuv420p -vcodec libx264 -b:v 500k -crf 30 -intra-refresh 1 -g 1 -preset veryfast -tune zerolatency -f flv rtmp://192.168.1.201/live/livestream (I'm using screen-capture-recorder as my virtual recording device)

For bonus points, throw in -loglevel verbose at the end if you really want to learn what's going on

In all honesty, I could probably get far lower latency by skipping the attempt to utilize intra-refresh and just using a small frame buffer(?) of 1-2 frames and encoding on the fly, but I was trying to reach sub-frame latencies. Also, keep in mind your video player has its own buffer if low latency is what you're after.

I hope this helps.

[brealisty]

@narlex have you met this problem: local machine test, when use usb_camera push stream, then cv2 play stream, which will get the first frame data after 8-15s (cv2.VideoCapture(rtmp_url)). but if push video stream, and doesn't use arg "-re", which whill get the first frame data at once. Why the camera or video with arg "-re" stream will wait so long?

[narlex]

@brealisty I have not played around with the -re flag before, so I'm not sure.