[Camera Support]: Bird cams juddery and corrupted #10526
Replies: 3 comments 13 replies
-
Sorry, just realised I am still using the restreams for recording. I thought I'd changed it back, but they're not giving more errors than using the original streams directly. |
Beta Was this translation helpful? Give feedback.
-
Can you try adjusting down framerate or resolution on the cameras perhaps? I have a couple of the GreenFeathers PoE Gen2s, they are equally flakey, I believe because they are under-specced. I have had better luck buying Revotech i706 cameras which look identical to the GreenFeather Gen2s - but I don't think Revotech are the OEM either. |
Beta Was this translation helpful? Give feedback.
-
Off the record but I am amazed to find the substream information about Greenfeathers camera right here: I'm just here to say many thanks! |
Beta Was this translation helpful? Give feedback.
-
Describe the problem you are having
I have so many problems with Frigate, it's hard to know where to start, but here's one. I have 6 RTSP streams. 3 are identical birdbox IP cams from Green Feathers (https://www.green-feathers.co.uk/collections/bird-box-cameras/products/bird-box-camera-hd-with-network-connection-3rd-gen-poe-version), and 3 are streams from a 4-way Axis video server. This is about the bird cams.
Green Feathers don't reveal the manufacturer. My Unifi network controller identifies them as Foscam G4s. They could be Foscams; definitely not G4s. Some of the details from their specs:
Main Stream Resolution: 1920x1080 @ 20fps
Sub Stream Resolution: 640x480 @ 20fps
Video Compression: H.264
Their specs don't say, but ffprobe reveals the audio is pcm-alaw.
The streams look fine (e.g. direct connection with VLC, or on Green Feathers' app). I can't see the main stream at intended quality through Frigate's Live View because I haven't been able to get MSE (reliably) or WebRTC (at all) working, so I'm stuck with jsmpeg. [I think the former is because of the corruption problem, because it usually plays for a second before failing, and sometimes longer. The latter is probably because it's not configured correctly yet.]
The recordings are juddery and corrupted. Most of the time, I can't view them through Frigate's interface (whether through Events or Recordings), because it complains the files are too corrupted within a few seconds of going to the Recordings page, or fails when clicking on the Event clip. But I can get the 10-second chunks directly from the store and play them with VLC or Quicktime. I have uploaded a representative one.
52.24.mp4
The cameras timestamp the video, and it's particularly easy to spot the problem in the timestamp. If you look carefully, you can see the video jump and freeze to match. I have occasionally even seen the timestamp jump backwards a second or two.
From googling how to diagnose video file corruption, I saw a suggestion to use something like:
ffmpeg -v error -i FILENAME_OR_STREAM_URL -f null - 2> errors.log
Besides varying numbers of errors like the ones dominating Frigate's log, e.g.
[h264 @ 0x7393c817d600] error while decoding MB 37 66, bytestream -6
There were also quite a lot of things like this:
[null @ 0x5f9a73767f40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 6 >= 1
I think that's a different problem, but I mention it for completeness.
One of the cameras (barn_birdbox_r) has materially fewer errors than the other two, and consequently has a slightly higher chance of being able to view the recordings through Frigate's interface. But still in the minority, and the other two barely ever.
Unlike the Axis system (which is ancient), these are new cameras. Two are connected via one switch, and the third via a different switch to the network hub, where the NUC (10th gen, i7, 32G RAM) that Frigate is running on is connected. It's all wired, not wifi. According to my Unifi UDM Pro, latency between each of the cameras and the hub is 0.2-0.3 ms. I doubt it's network problems.
The base OS on the NUC is Ubuntu 22.04. Besides Frigate, the NUC is running Mosquitto, Plex Media Server, a KVM VM for Home Assistant, and occasionally another VM for Windows 11 (no correlation with this problem). Docker's default firewall rules conflicted on install with the VMs, resolved by allowing packets to be forwarded to/from the bridge created for the VMs. Other than that, it's a vanilla install. I ought to try network:host, given the intended use (mainly for integration with HASS), but haven't yet.
I have played with all sorts of config settings, and ffmpeg options (running it directly from the command line with output to null, to try to isolate the problem). I don't have a clear grasp of how to choose which options. There are probably configuration errors, but I couldn't find anything in the documentation or google that connected this problem with a particular config snafu. The simple config below gave me fewer problems than most (e.g. I had tried using the go2rtc localhost restreams instead of the original streams in the cameras section, but that produced more errors, and likewise for different presets). I have disabled most of the cameras to try to get just one working, but it didn't make any difference, and at least this way, I am getting something I can use while I try to make it work better.
Is it hardware issues (3 new units similarly failed?!), am I doing something wrong, or is ffmpeg flawed? Why do the streams work viewed directly or via the manufacturer's app, but not via frigate?
Version
0.13.2-6476f8a
Frigate config file
Relevant log output
FFprobe output from your camera
Frigate stats
Operating system
Other Linux
Install method
Docker Compose
Coral version
USB
Network connection
Wired
Camera make and model
Foscam?
Any other information that may be helpful
No response
Beta Was this translation helpful? Give feedback.
All reactions