Closed atv2016 closed 1 year ago
Frigate is not looking to support battery / momentarily streaming cameras. This behavior makes sense because frigate sees the object and then the frame dies so it continues to go off of the last known frame while it tries to reconnect to the camera.
You most likely want to set
detect:
stationary:
max_frames: 300
for any battery cameras so the event does not continue.
As far as the recordings go, it is very difficult to follow this because there is no distinction being made between eufy recordings and frigate recordings. However, Frigate in no way affects how Eufy records and Frigate only recordings in 10 second segments. If a recording segment is discarded then it was invalid and not saved.
Fair enough about not supporting them.
And thanks, i'll try that. Maybe that will fix it. I have also updated the comment to make it more clearer.
Ofcourse Frigate doesn't affect how the eufy records, that seems clear.
But i'm thinking here if Frigate keeps looking for the object while the camera is off, would that cause this kind of behaviour of long recordings and stitching them together? The eufy obviously does not have the rtsp stream open for 5hours (as evidenced from the stitching of different recordings) and Frigate is responsible for the recording on the Frigate side.
So to me that kinda seems to be on the Frigate side?
It might be that that discarding corrupt message from Frigate is not related to how it stores a recording, maybe it is in regards to the Eufy rtsp stream being invalid.
Anyway, let's see if the config fixes this behaviour, would certainly be a fix for me.
Fair enough about not supporting them.
And thanks, i'll try that. Maybe that will fix it. I have also updated the comment to make it more clearer.
Ofcourse Frigate doesn't affect how the eufy records, that seems clear.
But i'm thinking here if Frigate keeps looking for the object while the camera is off, would that cause this kind of behaviour of long recordings and stitching them together? The eufy obviously does not have the rtsp stream open for 5hours (as evidenced from the stitching of different recordings) and Frigate is responsible for the recording on the Frigate side.
Frigate is just trying to reconnect to the stream and remains in its current state (object detected) until it can get the stream back and start processing more frames. So of course that part makes sense. As far as recordings go, if the rtsp stream stops then there's no way something is still being recorded to disk because there is nothing to record (and that is why the stream is coming back as corrupt). Just because the event is 3 hours does not mean there are 3 hours of recordings files there.
It might be that that discarding corrupt message from Frigate is not related to how it stores a recording, maybe it is in regards to the Eufy rtsp stream being invalid.
It is complaining because the recordings are invalid... because there is no data being sent
detect:
stationary:
max_frames: 300
Doesn't seem to like this, do i need to put it under a object? Or under default: maybe? I'm getting:
cameras -> doorbell -> detect -> stationary -> max_frames
value is not a valid dict (type=type_error.dict)
cameras -> side_porch -> detect -> stationary -> max_frames
value is not a valid dict (type=type_error.dict)
cameras -> backyard -> detect -> stationary -> max_frames
value is not a valid dict (type=type_error.dict)
cameras -> kitchen_back_door -> detect -> stationary -> max_frames
value is not a valid dict (type=type_error.dict)
Also, what's the difference between max_disappeared and max_frames?
My bad it is actually
detect:
stationary:
max_frames:
default: 300
This is from the docs:
# Optional: Number of frames without a detection before Frigate considers an object to be gone. (default: 5x the frame rate)
max_disappeared: 25
# Optional: Define a maximum number of frames for tracking a stationary object (default: not set, track forever)
# This can help with false positives for objects that should only be stationary for a limited amount of time.
# It can also be used to disable stationary object tracking. For example, you may want to set a value for person, but leave
# car at the default.
# WARNING: Setting these values overrides default behavior and disables stationary object tracking.
# There are very few situations where you would want it disabled. It is NOT recommended to
# copy these values from the example config into your config unless you know they are needed.
max_frames:
Thanks, I'll try it out and report back. I'm a little worried it says frames, which would suggest that it still receives a video feed. Does it still count frames even when the eufy has closed the connection ?
This probably is a thing when a connected camera looses connection as well, would max_frames still work ?
I'm not 100% sure, perhaps @blakeblackshear can provide more context on this edge case
I don't think that will work because the frames end and it won't ever hit the frame count.
Thanks both. Hmmm.
Any way of considering a 'loss of video signal' feature if it doesn't receive video for maybe x amount of minutes? This happens sometimes with my other cabled cams as well (faulty BNC cable, connector, etc) so even if supporting battery powered camera's is not on the roadmap, this would seem like a good feature to have.
I'm not sure what you are requesting exactly. We already set the preview of the stream on the cameras page to say that no frames have been received.
I am talking about the recordings. These keep going as it's still looking for a frame but the RTSP connection is closed as the camera turned off. As a result i get super long recordings that are stitched together.
I would expect ffmpeg to eventually timeout when the connection stops. Are you using go2rtc with these cameras? You could try connecting directly instead of using go2rtc's restream if so.
Otherwise you will need to play with ffmpeg args to find something that stops gracefully when the stream ends. You should only lose a max of 10 seconds if the segment is discarded.
This is the preset i'm using and it should disconnect after 5 seconds or so:
"preset-rtsp-restream-low-latency": _user_agent_args
+ [
"-rtsp_transport",
"tcp",
TIMEOUT_PARAM,
"5000000",
"-fflags",
"nobuffer",
"-flags",
"low_delay",
],
So that should already be covered. I see some ffmpeg/git issues on ffmpeg RTSP timeout options not working correctly with the stream dies though, and hanging. I will try the -stimeout and the -timeout options.
So it's definitely the ffmpeg process that is running as part of the frigate that is keeping this connection open then and responsible for the 'stitching' ?
Note that the main cameras page does go to black and says 'no frames received' when the Eufy stops sending data, it's just that the recording seems to stay open.
Ffmpeg reads from the camera and writes directly to disk in 10 second segments. If you go to /api/config
you can see the exact ffmpeg command that does this.
I don't know what you mean by 'stitching'.
I think based on the error log included (would be nice to have more)
2023-03-20 12:27:03.670644764 [2023-03-20 12:27:03] frigate.record WARNING : Discarding a corrupt recording segment: /tmp/cache/kitchen_back_door-20230320122648.mp4
the ffmpeg process is receiving some data that it is trying to write to a segment otherwise it would be restarted due to the timeout or no segments being written
Ffmpeg reads from the camera and writes directly to disk in 10 second segments. If you go to
/api/config
you can see the exact ffmpeg command that does this.I don't know what you mean by 'stitching'.
It (either Frigate or ffmpeg) is concatenating the recordings together. This is all mentioned in this form previously.
Ffmpeg reads from the camera and writes directly to disk in 10 second segments. If you go to
/api/config
you can see the exact ffmpeg command that does this. I don't know what you mean by 'stitching'.It (either Frigate or ffmpeg) is concatenating the recordings together. This is all mentioned in this form previously.
The recordings are not physically stitched together. They are just played back together, they still exist as separate 10 second segments
We are going in circles here. I am not talking about a regular recording, I understand how ffmpeg puts it into 10 second files and displaying it as one recording, we are talking about multiple recordings made by the eufy with seemingly (sometimes it is) hours between them AND showing up as one recording in frigate, whilst it should be showing up as separate recordings in frigate. And yes it might not actually be hours, but that’s how it is shown.
This is not a normal recording in frigate as it would show up for a wired camera, only the eufy (and I imagine other battery powered cameras cause this behaviour.
I will play around with ffmpeg options.
From: Nicolas Mowen @.> Sent: 21 March 2023 13:54 To: blakeblackshear/frigate @.> Cc: atv2016 @.>; Author @.> Subject: Re: [blakeblackshear/frigate] [Camera Support]: Eufy 2C battery camera and stitching together of recordings (Issue #5779)
Ffmpeg reads from the camera and writes directly to disk in 10 second segments. If you go to /api/config you can see the exact ffmpeg command that does this. I don't know what you mean by 'stitching'.
It (either Frigate or ffmpeg) is concatenating the recordings together. This is all mentioned in this form previously.
The recordings are not physically stitched together. They are just played back together, they still exist as separate 10 second segments
— Reply to this email directly, view it on GitHubhttps://github.com/blakeblackshear/frigate/issues/5779#issuecomment-1477880109, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEBCFU4JTJV7LO6UDTDQADDW5GXJ5ANCNFSM6AAAAAAWBCZZLM. You are receiving this because you authored the thread.Message ID: @.***>
We are going in circles here. I am not talking about a regular recording, I understand how ffmpeg puts it into 10 second files and displaying it as one recording, we are talking about multiple recordings made by the eufy with seemingly (sometimes it is) hours between them AND showing up as one recording in frigate
We are not concerned with how the eufy app shows the recordings and that is causing a lot of confusion here. You also say "showing up as one recording in frigate" which I think you actually mean showing up as one event in the frigate event list
this is of course expected because the eufy camera never sends frigate frames without the object in them, so frigate receives more frames in the future of another person and is forced to assume it is the same person
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Describe the problem you are having
Resulting from a previous ticket: Frigate shows "discarding corrupt segments in logs" and combines multiple recordings in the same recording.
It seems this is happening (in my view at least) that Frigate keeps on saying in progress for the object for a long time, longer after the eufy camera stopped recording. Because of this I see multiple detections from the Eufy camera in the same frigate recording as well (even though the eufy camera itself was not recording anymore, and the times in frigate are wildly off (3h recordings, and it orders them in the wrong way (i guess because it has different eufy recordings in the same frigate recording).
Maybe the eufy is not sending a stream stop properly or something, i dunno. But if it really was on all the time it would be out of battery :-). Also, the frigate recordings clearly show it is stitching them together, and possibly corrupting them for some reason.
I'm exploring the option in the Eufy app to set the recording to 20seconds max or so.
But i think this is at least why we are seeing the "discarding corrupt segments" in the frigate log files for Eufy camera's, possibly other battery based cams as well. At first i thought i missed recordings, but they all seem to be bunched up in a single (seemingly 3h) long recording.
If the option in the app does not fix it, maybe there's the possibility of adding a max object/in progress time for battery powered cameras? I know eufy's implementation of RTSP is buggy junk, but i have seen this on other battery camera's as well so it's seems a 'thing'.
Thanks!
Version
Beta-9
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
Eufy 2c
Any other information that may be helpful
No response