Camera live view lag

Discussion in 'Troubleshooting' started by nethfel, Sep 4, 2019.

Share This Page

  1. nethfel

    nethfel Young grasshopper

    Joined:
    Nov 4, 2015
    Messages:
    30
    Likes Received:
    1
    Hi all,
    I brought a thread about this a while back that while viewing the web interface, it was a few seconds behind real time. Right now, it's almost 5 seconds behind real time.

    CPU usage is total system ~32%, BI CPU ~29%
    Memory: total usage 72%, BI using 3.3 GB out of 8 total

    currently the new file storage drive (4TB 5400 Seagate Skyhawk Surveillance drive) is at 2.21T out of 3.14T (limited max usage of the drive to 3.2TB out of 3.63 available, OS drive is a separate drive); I changed the amount of days to store as it was at one point at 100% usage (full 3.2TB) and I was wondering at first if it was a matter of amount of time it was taking to delete files causing some latency? Storage is set to Delete.

    Total network traffic for the cameras is ~8MB/s on a 1g network that is isolated for just the cameras, ~838MP/s

    I have streaming set to profile 0:
    Quality 50%
    Limit Bitrate Max Bitrate 8192kbps
    Max GOP 300

    Advanced
    Preset superfast HLS 3
    Zero Frame Latency checked

    When I first fired up the server when the clip drive was new, the latency was about 1-1.5 seconds at most - wish it was lower, but Ok. But now it's way too much of a lag from reality to be used as a live monitor. Any thoughts on how I might improve this feed?
     
  2. TonyR

    TonyR IPCT Contributor

    Joined:
    Jul 15, 2014
    Messages:
    4,021
    Likes Received:
    3,864
    Location:
    Alabama
    • A screenshot of BI's camera config page(s) that includes video path and camera selection drop-down would help immensely.
    • Is this lag when viewing on BI console or via local UI3 or remotely?
     
    looney2ns likes this.
  3. nethfel

    nethfel Young grasshopper

    Joined:
    Nov 4, 2015
    Messages:
    30
    Likes Received:
    1
    Local UI3 (well, local on same premises, but a different VLAN since it is punched through to the internet for remote access). The machine is in a rack in our server closet so we never look at the actual console unless using RDP to reconfigure something.

    We currently have 21 cameras split into 3 types, 12, 7, 2

    Sample config from 1 of the 12 cameras:

    Sample config from 1 of the 7 cameras:

    Sample config from 1 of the 2 cameras:

    We have tried both Javascript and HTML5. I tried the activeX plugin on the windows box, but IE on that one didn't seem to want to acknowledge the existence of the plugin.
     
  4. bp2008

    bp2008 Staff Member

    Joined:
    Mar 10, 2014
    Messages:
    8,909
    Likes Received:
    6,040
    Hi @nethfel

    If the delay is present in Blue Iris's local console, then the problem is between the camera and Blue Iris. There always is some delay, but usually only a second or two here. Turning hardware acceleration on or off can affect it a little bit, if your needs are particularly latency-sensitive.

    If the delay is only present when using UI3 (the web interface), then there are several possibilities. It would be very helpful to right click on the video stream and choose "Stats for nerds". Near the bottom of this panel, you will find graphs of "Network Delay" and "Player Delay".

    Network Delay is a measurement of the real time that has passed since the start of your current video stream, versus the current timestamp of that video stream. This is normally at 0ms, or close to it. Elevated values suggest network problems.

    Player Delay tells you how much video UI3 has buffered (received, but not yet shown). If you are using the HTML5 player, which is the default in most browsers, it is not uncommon to see values of 200-2000ms in here. This is because the browser's HTML5 player naturally wants to buffer some video to ensure smoother playback. If this is a problem, you can go to the main menu > UI Settings > Video Player and change the H.264 player from HTML5 to JavaScript. The JavaScript player uses much more CPU time, but it gives UI3 complete control over the frame timing, which allows UI3 to minimize the video delay. If your CPU is fast enough, it is normal to see only 0-1 frames of delay when using this player.

    Delayed Frames is basically the same thing as Player Delay, except it shows the actual number of buffered frames instead of the amount of time they represent.
     
    SouthernYankee and mat200 like this.
  5. nethfel

    nethfel Young grasshopper

    Joined:
    Nov 4, 2015
    Messages:
    30
    Likes Received:
    1
    Here are some captures:

    HTML5:

    Javascript:

    Remote Desktop FPS unrestrained (normally we set it to restrain to update every 5 seconds)

    At this moment in time, the delay doesn't look bad, but it seems to creep up. I don't know what would have changed it just now off hand (the for nerds there was only a couple seconds latency vs the 5 seconds we were experiencing earlier). I'll have to wait until it happens again and get some more nerd info to see if I can track it down some more - at least now I know some places to look. :)
     
  6. JNDATHP

    JNDATHP Pulling my weight

    Joined:
    Oct 16, 2018
    Messages:
    259
    Likes Received:
    179
    Location:
    USA
    Maybe way off base here but what is the interval in each of your cameras to update its time by NTP? Could it be that the cameras’ internal clocks aren’t accurate and when they request an update from an NTP server that they and your Blue Iris machine are now in sync?
     
    SouthernYankee and looney2ns like this.
  7. nethfel

    nethfel Young grasshopper

    Joined:
    Nov 4, 2015
    Messages:
    30
    Likes Received:
    1
    No, because it’s more than just local clock offness.

    For one thing the bi server is the ntp server for the cameras, so drift is fairly minimal.

    The delay is most noticeable like when watching the camera feed and watching someone move - there is a delay, it’s not a time offset where the movement would be accurate but the time recorded wrong. The worst of the offset was this morning at between 5 and 7 seconds. Someone would walk in and be in front of you and ~6 seconds later real time the camera would show that person at the desk.