Closed kenjikato closed 9 years ago
You can try setting bufferTime to 0, which is usually recommended for live streams. I see that it's always set to 1:
Adding that in a way that can be used by everyone (setting it to 0 if _isLive is true) would be great.
There will always be some delay from RTMP, if I remember correctly. It's been years since I worked on this, but I do remember it never being exactly right. Trying to change the bufferTime should help a bit though.
@bdeitte thanks for the info. While this did improve the overall latency, it was only marginal. I'm still running at about 1.5 seconds behind the source broadcast. While this might be great for the open internet, I was really hoping to get something much lower latency wise (under a second) given my closed network and hardware setup. If I find a better setting, or can improve the over all latency I will add an update to this thread.
I'd be really interested in seeing the result of this, so please post any updates you come across. I'm going to close this since it's a little out of our wheelhouse (or at the very least, probably a better fit for the SWF repo), but please feel free to update the thread.
@kenjikato Grind Player was one of the only ones I could find that allowed sub 1 second playback from a live RTMP stream. http://osmfhls.kutu.ru/docs/grind/ this sub 1 second was over the internet too.
Edit: And OSMF from Adobe also achieved sub 1 second live streaming in our tests a few years ago https://sourceforge.net/projects/osmf.adobe/files/ but we switched to Grind Player as it had more of an extensive JS API and is still supported.
@alexcroox for some reason I just now noticed your post here. Thank for the info!!! I did not know about the Grind Player, and while it's older it might solve the latency problem I'm still trying to find a good work around for. Hopefully I can test this when I'm back working on my video project in July.
No worries. I'm in a bit of a jam with live video at the moment. With Chrome disabling flash by default any day now I need to find a suitable html5 ultra low latency alternative. WebRTC is promising but very hard to scale to support 1k viewers for example.
I've been working on a specialize live video streaming project (think live screen casts or e-sports screen share) over the past few months. One of the biggest problems I'm having seems to be on the player side of things. I have come to this conclusion after monitoring network traffic and tuning all the other elements of the system.
I have been able to get my latency on the receiving browser side (using video.js on a simple webpage in Chrome) down to the 2 to 4 second range. When I use something like ffplay (part of ffmpeg) I can tune a receiving player latency down to between 200-400ms of delay from initial frame being sent to actual playback (what would be great to have in the browser).
I'm on a high end closed network, and my setup is as follows: I'm using OBS (on Windows and Mac) and a dedicated hardware streaming box (http://epiphan.com) on the capture side to send out 1080p 30fps video, sending RTMP across a dedicated gigabit network, routing through a Nginx based server (128GB RAM, dual 8 core Xenon processors, SSD drives, running CentOS 6) using the nginx-rtmp-module, and then relaying it out to one of twelve Windows 7 computers (dual quad core boxes, 32GB RAM, with K5000 graphics cards) on a different local gigabit network.
So my hardware and network are not an issue here. What I've come to is that my biggest latency roadblock seems to be on the playback end of things. That is unless someone else can enlighten me to where else to look, but my testing to this point squarely points to playback.
Does anyone have recommendations on how to tune video.js (or other browser based players) to achieve better than 2 seconds of latency in live RTMP video streaming?
Thanks!