How to reduce video monitor lag?

[Doc Jones]

What settings might synchronize a Blue Iris web server client's image with real time? Or is the web client's image likely to lag 0.75 seconds no matter what hardware and configuration are being used?

If an unavoidable lag is introduced by using Blue Iris, I would appreciate knowing this. Otherwise I need to start testing each link in the hardware and software chain to find the source(s).

This is for a camera that views a trailer hitch during hookup. The lag makes it difficult to position the RV without hitting the trailer. The operator complains that it feels like trying to thread a needle, drunk.

The attached photo shows a test setup that includes: a timer (03:53.28), camera's LAN interface (03:52.98), Blue Iris (03:52.68) and Blue Iris web server (03:51.42). Typically the web server lags the timer by 0.5 to 0.75 seconds. Closing Blue Iris and the camera interface produces the same results.

I understand that the lag may be introduced anywhere along the chain: by hardware, camera configuration, Blue Iris configuration or something else. I have a duplicate system with a single camera on a test bench for delightful sport of lag hunting.

Details

• Topology is camera > switch > router > Blue Iris server > WiFi access point > Blue Iris web client
• Blue Iris (licensed not demo) is running as service on Dell Inspiron 3464 AIO, Intel i7-7500U CPU @ 2.70GHz, 2904 Mhz, 12 GB RAM, 240GB SSD, ethernet=100 mbps
• Web server client is Samsung Galaxy View running Blue Iris app. Dslreports speed test shows 15 mbps down and 1.5 mbps up for the Samsung. Ping from Dell to Samsung is
• Camera is Samsung Techwin WiseNet Lite Series 2MP Outdoor Network Camera with 3.6mm Fixed Lens & Night Vision connected via ethernet cat5e to
• Switch is Lorex by FLIR 16+2 Port High-Speed PoE Gigabit Switch
  
• Router is Ubiquiti EdgeMax-ERX version 1.97+hotfix 4
• WiFi access point is Ubiquiti Unifi 802.11ac Dual-Radio PRO Access Point (UAP-AC-PRO-US) Firmware

 

[SyconsciousAu]

IP cameras suffer from a short lag. The image has to be compressed, transmitted, switched, and decompressed for display on your monitor and that takes time. The webserver data also has to be transmitted and switched and transmitted to the app. To be honest I don't know what possessed you to use such a complex setup for a reversing camera. There is a reason they use ordinary analogue cameras for reversing cameras.

 

[Doc Jones]

@SysconsciousAu Thanks for the advice about lag for analogue versus IP. The hitch camera was an add-on to an existing IP system. Replacing the hitch camera with an analog stand-alone system may be the outcome, since your reply suggests the lag is inherent in IP processing.

 

[bp2008]

Based on something the developer said a while ago I think Blue Iris might try to buffer 4 frames ahead so a higher frame rate may help slightly reduce latency. But you're typically looking at about a quarter second minimum for H.264 streaming latency no matter what video player you use. Often it is closer to 1 second or more because these systems are typically engineered for reliability rather than for low latency.

Blue Iris's web server must re-compress every frame, transmit it to the browser/client app (this is where a slow network connection can have a big effect), and then the frame is decompressed and scheduled for display. All this also adds latency, but typically much less than the latency between the camera and Blue Iris. It is also possible that the official android app may introduce a high amount of latency due to a large video buffer (intended to smooth out playback on cellular networks). I have not studied this so I don't know if that is actually what is going on.

The lowest latency streaming method is probably jpeg/mjpeg because these formats don't include timing information; the system just processes frames as quickly as possible. Indeed, older IP cameras that only stream video using jpeg compression tended to have significantly lower latency than modern H.264 models. The same may apply to a modern camera streaming in jpeg mode so it is worth a try. But nothing beats an old-fashioned analog camera when low latency is important. That is why they are still being used today in vehicles.

 

[Doc Jones]

@bp2008 Thanks for the tip about jpeg/mjpeg. The lag on mjpeg is less, at about 0.4 seconds rather than 0.6 to 0.8.

I suspect that is as good as it gets unless the owner wants to install an analog camera and viewer in addition to the IP system.

 

[bp2008]

To further optimize, I would suggest viewing a sub stream (assuming you can set it to mjpeg), since the lower resolution should be a little faster overall. I'd try a couple different players connecting directly to the camera, like IP Camera Viewer or TinyCam Pro. Chances are good that one or both of those would be faster than viewing through Blue Iris's web server. If you could get a web browser to open the stream natively that would probably be the fastest possible option, but a really clunky interface.

Mjpeg streaming typically is a dynamic frame rate, since it is just a stream of jpeg frames one after the other as quickly as the entire system allows, so you'd probably want to make sure the camera was set to encode this stream at its maximum frame rate.

 

[TonyR]

@bp2008 Thanks for the tip about jpeg/mjpeg. The lag on mjpeg is less, at about 0.4 seconds rather than 0.6 to 0.8.

I suspect that is as good as it gets unless the owner wants to install an analog camera and viewer in addition to the IP system.

I used an old iPhone4 with Wi-Fi, a TP-LINK TL-WR702 USB-powered travel router and an iPad with Wi-Fi to set up a closed wireless backup cam for hitching my F-250 Super Duty to our 28ft. travel trailer. Did it for 4 years, after the first couple of uses I may have gotten out of the truck twice to check, from then on it was once and it was spot on (and saved my marriage)!

Installed $3 app on iPhone from SKJM named ipCam.

Put the TP-LINK in AP 'working mode', assigned it a static IP of 192.168.1.88, enabled DHCP, named its SSID "HITCH CAM", plugged it into a USB charger which was then plugged into cigarette lighter in truck cab.

On iPhone, had Wi-Fi locate SSID "HITCH CAM" and lock on. It was assigned an IP by the TP-LINK. Mounted iPhone on gooseneck with suction cup on tailgate below Ford emblem, pointed down at hitch. Opened ipCam app, noted IP address of cam.

On iPad, found and locked onto SSID of "HITCH CAM". It was assigned an IP by the TP-LINK. Opened safari browser and put in IP of the cam found on the ipCam app. Entered ipCam app user/password (if any). Selected 'JPEG Video'.

Used iPad to view and adjust iPhone at hitch ball. When OK, sat iPad on seat in truck and viewed it to back up truck to hitch. There's perhaps a 1/2 second delay.

To be honest, since I had to leave tailgate up, I did use one of those $20 telescoping, magnetic dual yellow tennis ball things to get me close and aligned laterally and NOT bang the trailer tongue on the truck bumper or tailgate. One mounted at hitch ball between the ball and the tailgate, pulled up to a specific height and viewable over the tailgate. The other one mounted on the trailer tongue just behind where the ball will fit. It was pulled up to the same height as the one on the truck. AS I backed up, when The balls were about a foot apart the iPhone could then see the trailer tongue and I was close and would then use the Hitch Cam as viewed on the iPad in truck cab. The iPhone got the truck's hitch ball right under the trailer tongue as desired. It really did help. Cost was about $55 for TP-LINK, app and suction cup, gooseneck iPhone holder (eBay).

Nowhere near as good as the built-in, OEM backup cams from the vehicle manufacturer ( I have a factory-installed one on my 2017 Ford Escape) but it works great, IMO, considering the low price. You can actually put the ipCam app on the phone you use everyday and have with you and I took my iPad camping any way so it was convenient and very easy to set up and use.