Nest camera video corruption only when go2rtc and camera on same network

[clasoncj]

Video corruption is occurring on all of my Nest camera feeds but only if the system running go2rtc is on the same network as the Nest cameras. Issue occurs on multiple hosts running go2rtc (Mac laptop, 2 x RPis with Ubuntu and Linux VM) and with all of the Nest camera feeds.

The video corruption issue goes away if running go2rtc on a machine that is not on the same network as the cameras. Have tested with a GCP VM and my laptop. Debug logs from go2rtc are identical in both passing and failing case. No issues with RTSP streams from standard IP cameras and no issues with displaying the camera feeds through Google Home app when on the local network.

Fails every time, happy to collect additional logs or provide remote access to debug. Fails on v1.8.5 and master branch.

log:
  level: debug
  streams: debug
  webrtc: debug

webrtc:
  listen: ":8555"

streams:
nest-doorbell:
    - nest:?<redacted> 

[clasoncj]

Update I'm able to reproduce the issue using: ffplay -fflags nobuffer -flags low_delay -rtsp_transport tcp "rtsp://localhost:8554/nest-backyard"

Enabling the reorder queue makes the issue go away: ffplay -flags low_delay -rtsp_transport tcp -reorder_queue_size 10 "rtsp://localhost:8554/nest-backyard"

Is there a similar setting that can be used for the RTC streams?

[peterguy04]

I am experiencing the same thing with nest cameras, the cameras are on a separate VLAN to my frigate server and configured in go2rtc with drive_camera: hass://supervisor?entity_id=camera.driveway_camera

did you manage to find a way to resolve this @clasoncj ? i am running 1.8.4 as part of the Frigate package, i wasnt sure where you put -reorder_queue_size 10 as mentioned in your second post

Thanks

[clasoncj]

@peterguy04 unfortunately we decided to focus on the commercial space and abandoned working with Nest cameras for the foreseable future. I'm happy to test potential fixes though since it's easy to reproduce the issue on our end.

[AlexxIT]

Unfortunately I don't use Nest and can't fix this issue

[clasoncj]

I was able to reproduce running the go2rtc binary natively on the host (not even using docker), our use case didn't involve Frigate. No other video sinks were active when the issue was reproduced on our machines.

My hypothesis is the sink is reading from the queue before the data is ready which is why setting the reorder_queue_buffer fixed the issue. I wouldn't be surprised if system load impacting other timing could cause different behavior.

I also had the idea to try and request a new keyframe but unfortunately abandoned our efforts before I was able to code a patch to test.

On Thu, Apr 25, 2024 at 12:15 PM peterguy04 @.***> wrote:

@AlexxIT https://github.com/AlexxIT i arnt sure if it helps or even makes any sense but I've figured out that this is only happening when frigate is running. This can be on a different device anywhere on the network or on the same device as each other. They dont even have to be linked in the frigate config

i am testing now with frigate and the separate go2rtc container and if i stop frigate, the streams are good, start frigate and its bad.

@clasoncj https://github.com/clasoncj were you running frigate by any chance aswell ?

— Reply to this email directly, view it on GitHub https://github.com/AlexxIT/go2rtc/issues/937#issuecomment-2077779865, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWGZCHTRPTVL7QTAGQAXWDY7E24JAVCNFSM6AAAAABDC3YXLWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDANZXG43TSOBWGU . You are receiving this because you were mentioned.Message ID: @.***>

[clasoncj]

Unfortunately I don't use Nest and can't fix this issue

@AlexxIT I can give you wireguard access to a RPi4 host running Ubuntu configured to use one of my Nest cameras if you're interested in debugging. Issue shows up consistently.

[peterguy04]

I deleted my original post because after further testing ,I still had issues, the image did appear cleaner but did freeze alot which also caused a few artifacts.

[AlexxIT]

Remote debugging of such problems is very time consuming. Because it depends on the network environment only.