Skip to content

Unifi G3 Flex picture tearing

2»

Comments

  • edited July 2020
    I received a single email today about excessive packet loss from the G3 Dome that had been the worst culprit of phantom motion events. I'm pretty sure I'd get the odd email like that before 5.2.2 as well, but so infrequent it's not a huge issue.

    I've been running at full HD, 15fps and (I assume default) 3000Kbps. Just for fun I set all cameras to 30fps and 6000Kbps just now to see how that goes.
  • Thanks - I cannot run 30FPS above 1.4Mbs on this release. has me beat.
  • edited July 2020
    So the update is that I'm seeing no difference having upped the camera settings to 30fps and 6000Kbps - everything is back the way I remember it pre-5.2.2. In other words I'm pretty happy again.

    I'm doing that on the individual camera settings, which are managed by Protect, and then SS picks up an RTSP feed from Protect. There is no way to set fps for that configuration in the SS camera settings
  • Would you try a G3 in standalone mode (removed from Unifi Protect) and try at full throttle (30FPS and 6Mb). Thanks in advance. As i suspect the RSTP feed is manipulated within protect and a much lower rate. I am trying to retire Unifi Protect as they are retiring and switching off ALL web based hosting for CCTV in a couple of months.
  • I'll give a spare G3 a go later and report back, I just need to find a POE injector or a spare POE switch port I can easily access.

    What I have spotted is that at 30fps I'm seeing moving objects smear across the image. Even the seconds part of the overlay corrupts (I use Protect to stamp the image). I backed it down to 15fps at 6000Kbps and that looks stable, but any faster smears a bit, the higher the fps the worse the smearing is.
  • I've just finished setting up a G3 in standalone mode, using the Ubiquiti UniFi profile. That forces RTSP and I've left it in the default (I assume) TCP "RTSP Video and Audio" setting for now.

    The camera settings are se to 30FPR and 6000kbps. It's early days but no error messages yet except when it was rebooting. I'll leave it running as I wanted it set it up to watch my 3D printer anyhow and being in standalone mode for that is fine.

    It's not been used for over 18 months so I'll manually upgrade from 4.4.8 to 4.23.8 now. It's 7 pm here, so I'll report back tomorrow if there are any issues.
  • edited July 2020
    I switched to UDP as there was a lot of screen corruption - interestingly I didn't notice any before the FW upgrade. Perhaps it's a combo of the newer UniFi FW and the SS update that has triggered the issues.

    I'm seeing an odd graininess develop in the image, gradually worsening over a period of a few seconds then and then clearing. I am not seeing the same corruption of the seconds digit I saw with 30fps and 6000kbps from the cameras on Protect.
  • Thats the exact senario I have - I am going to try and roll back 1 camera to 4.4.8 and see how that affects compared to the latest release.
  • edited July 2020
    I can confirm rollback to camera firmware 4.4.8 and returning to 6Mb and 30Fps with SSpy set to "RTSP Video and Audio" NO errors recored ! I am shocked but happy. Would love to understand how the streams have been manipulated/corrupted on later releases. As this is a step backwards .....but it works! It would be great if Ben could replicate and shed some light on why?

  • These results are all very interesting, this does suggest that newer camera firmware versions are less stable. This doesn't explain the difference being reported between SecuritySpy v5.2.2 and v5.2.3, though we haven't been able to replicate this here nor find any problems with the RTSP/RTP parser in v5.2.3, so that's a bit of a mystery at this point.

    Any kind of smearing/corruption is most likely the result of lost video packets. When a packet is lost, SecuritySpy has to drop the frame that contains that packet, and with temporarily-compressed video data (like H.264, which is what the UniFi cameras provide), where most frames depend on the previous frames, this can produce noticeable corruption.
  • Still 100% error free for me. Not ideal but its working and can live with it! Happy for all the pointers and especially BEN for taking the effort to purchase and investigate.
  • Update: in some further testing, we found that if data backs up in the network buffers for any reason (i.e. if SecuritySpy doesn't read it fast enough), the camera dumps packets and produces corrupt video. There are far better ways for cameras to gracefully deal with such situations without producing corrupt video data, but unfortunately this kind of thing is something we have seen from time to time. Apparently, from the above reports, their older firmware handled this situation better than the newer firmware.

    So, we have made some further changes in the latest 5.2.4b16 beta version of SecuritySpy that should improve the stability here with the standard RTSP TCP format (increasing network buffer sizes, making sure to read all data from the network as soon as it becomes available etc.). So please try this new update, and switch back from RTSP UDP to the standard RTSP option, and report back.
  • Have updated to 5.2.4b16 and RTSP TCP running 4.4.8.67 unifi firmware - will run overnight then upgrade to latest release firmware 4.26.12.67 and report results
  • First overnight run5.2.4b16 and RTSP TCP running 4.4.8.67 unifi firmware RTSP TCP loss.

    Upgraded all now to 4.23.8.67 (latest public stable release from unifi) will run overnight and update results.
  • edited July 2020
    Well looks like its 100% error free! Run overnight on latest camera release. Well done Ben. Looks like you have fixed it!. You still get some image tearing as people /vehicles pass, but no where near the point it was. Its worth noting this is running over cat6e rather than wifi.
  • Hi Jeff, many thanks for the quick testing. I've been running our UniFi camera continuously for 2 days now, with 100% uptime and zero packet loss, so for me it's totally fixed. If you are still getting some tearing on moving objects, this could still be a bit of packet loss (in which case you might like to go back to the previous firmware), or it could simply be some compression artefacts, in which case you could try increasing the compression quality/bitrate in the camera's settings. Check the Dashboard feature in SecuritySpy to check for packet loss for this camera over the last couple of days - any level of packet loss can result in corrupt video.
  • Checked as suggested - 100% error free. Yup I would say WELL FIXED! Thanks. The tearing I can live with as 99% time does not appear on the recorded steam.
  • looking good here too - thanks
  • Great to hear that.

    @jeff444 - if it's not packet loss, and doesn't appear on the recorded stream, this may be an artefact of the video decoding. In the Camera Info window, click the header bar (where you see the column names) and enable the "Hardware Video Decode Status" column. You should see a "HW" indicator, showing that the camera is being decoded in hardware. Click the indicator and you can force software decode instead. Does this have any bearing on the problem?
  • Will adjust and report back
  • Sorry, I've not been checking back here for a little while - looks like some interesting progress.

    For my part I have been seeing increasing numbers of phantom alerts of vehicles in a garage where nothing is moving in particular. I also see smearing of moving objects with cameras set to 15fps and 3000Kbps as I was at 30fps / 6000Kbps previously.

    I noticed earlier today that when the garage camera that has been alerting badly records (which it doesn't always as I have my alert trigger slightly more sensitive than my record trigger) there is consistently a 5 second gap in the time-stamp.

    I have SS record 5 seconds before the motion trigger, and I, let UniFi put the camera name and time stamp on the video, so if the motion capture starts at 10:10:23 the timer will stop at 10:10:28 and then 5 seconds later will jump to 10:10:33. I'm guessing the alert / motion capture is because there is a significant change when frames drop entirely for longer than the 1 or 1.5 second trigger time I have set.

    One the past few days I have seen the smearing much more often and have dropped my cameras down to 10fps and 1500Kbps to try to reduce that - with some success, but not 100%.

    Yesterday I upgraded to 5.2.4 release and that did not help things for me compared with 5.2.4b12, using UDP. It looks like there is no current beta version available for download, but in case that is because 5.2.4b16 has been promoted to 5.2.4 full release I'll go back to TCP for the feeds and see what that does.

    What seems really bizarre to me is that I was pretty happy with 5.2.4b12 when I first started with it and things seem to have got worse over the intervening 3 weeks or so.

    The G3 I have running direct to SS at 15fps and 1506Kbps has actually worked better for me than some of the cameras coming via Protect, but I'd rather use Protect as it is a second source of recording - which has about 36 hours of continuous footage if I need it - and also it enables features of the cameras to be accessed that aren't available in standalone mode such as widening the field of view at the expense of some barrel distortion or turning off the IR emitter but switching to IR mode when dark.
  • Hi @FenC please try SecuritySpy v5.2.4 with the Format setting set back to normal RTSP (not RTSP UDP). Other users are reporting this as the most stable setup. Can you confirm?

    If you are seeing any problems with frame timings (e.g. pauses or weird speed video playback), go to Preferences -> Cameras -> Device -> Advanced Device Settings, and enable the "Generate frame timestamps in software" option. One user has reported that this was necessary to prevent such problems with their G3 camera.
  • Hi Ben, thanks for the follow-up and an very sincere thanks for fixing the issue.

    I was already running 5.2.4 and did as you suggested and went back to RTSP as opposed to RTSP UDP at the time of writing my previous post, and as happened with Phil all my problems have cleared up. I get no phantom triggers and can run the cameras at 30fps / 6000Kbps with perfect recordings. I also checked just now and looking at the Dashboard graph of Packet Loss / All Cameras (sum) with 0 smoothing I have had a total of 0 dropped packets in close to 48 hours since making the switch whereas the graph was very spikey before then.

    I do still have quite bad smearing of moving objects in live view if I push the settings beyond 15fps / 3000Kbps, but again as reported by Phil that isn’t in recordings. To that end I did try switching one camera from hardware to software decode, but it didn’t make any noticeable difference.

    Part of my current use case is to keep an eye on things manually while some building work is going on during the day with motion detection disabled, so I’m running at 15fps / 3000Kbps again now and there is almost no smearing. Once the builders have finished my use case will be back to a much more “normal” where the cameras will be purely for motion detection and I can turn the quality and speed back up at that time.

    Thanks again for taking the time to fix this - I genuinely don’t think I have ever had better support with any product than you have provided on two separate occasions now.
  • An update for anyone reading through this thread in the future:

    I had been using a Unifi Cloud Key Gen2+ as a Unifi controller and NVR. Last week the UDM Pro that I preordered in February finally made it through (I expect) regional testing and then Covid disrupted shipping to New Zealand.

    I have moved the Unifi controller and gateway / router / firewall functions to the UDMP, but left the UCKG2+ as my NVR. That has enabled me to move the NVR to the dedicated camera VLAN I have been running that includes my cameras and the Mac mini that runs SS for me, and that has cleared up the last bit of smearing I was seeing in live feeds, even at 30fps and 6000Kbps.

    I was tipped off by a Youtube video I was watching around securing smart home networks with Unifi (on The Hook Up channel) where Rob had identified RTSP stream corruption across VLANs in his setup.

    Looking back I think in fact that the small amount of smearing I still had in live view at 15fps and 3000Kbps disappeared just in implementing the UDMP - so it is probably due to the limited power the USG 3P has to manage routing of live video across VLANs.

    Regardless, the remaining issues I was seeing after Ben's fix in v5.2.4 was down to passing the RTSP stream between VLANs.

    I was never a fan of the single box doing everything approach of the UCKG2+, and in hindsight I should have stuck with a standalone controller after I bought it and just let it run NVR from day 1 (I only bought it as Protect was receiving new camera features the old NVR wasn't getting, the killer for me being enabling night mode without having to turn on the in-camera IR emitter).

    I haven't looked into the NVR option in the UDMP and whether it can be hosted in a different VLAN to the controller part as I am not interested in doing that. I am leaning toward buying the dedicated Unifi Protect NVR when it becomes available, and also likely selling the UDMP and replacing it with the UXG Pro dedicated gateway when that hit's NZ release. I think components rather than all in one boxes are the way to go - which is what got me onto the Unifi platform for my home network in the first place.
Sign In or Register to comment.