segment_time too low for producing high quality recordings #3406
Replies: 2 comments 1 reply
-
|
The other issue with large segment times that you seem to have not considered is that when an event is saved, the entire segment must be saved. As such with a segment time of 600, even a 10 second event would maintain that entire 600 seconds. Same thing with 24/7 recordings that are set to only save segments with motion, now these segments are much larger and must maintain 600 seconds of footage even if just 5 seconds of motion occurred in that segment. The segment time is customizable and I think 10 seconds is a good default amount for a majority of usecases.
I have not seen any stuttering in live view, do you use the same or separate streams for detect and record? #2497 If this occurs in downloaded video then that would change things, but I don't see how that would happen unless there are ffmpeg errors about bad stream, I would think the stream would still be written to the disk even if it was slow.
Yes, frigate already does this.
In what way do you see this? The |
Beta Was this translation helpful? Give feedback.
-
|
To be clear I am not meaning to dismiss the high load problem, I know your particular setup is quite large, just wanting to cover some basis. Personally (not speaking for anyone else), I think 10 seconds is a good default segment time for most users and the size of their setups and increasing the segment time is the right solution for this problem. Also I just loaded up with a higher segment time and it worked without issue |
Beta Was this translation helpful? Give feedback.
-
|
likely my original experience with 11 beta 4 was based on not waiting long enough for streamed data to be written to disk while event snapshots appear in the recordings page that are not clickable due to missing video files few of my hikvision cameras are nearly 10 years old and slow. I've wondered what would happen if since they are streaming tcp, if the receiver i/o doesn't ack fast enough, could client responsiveness cause the camera to internally glitch and feed a bad frame forward? maybe. once real-time is lost, there is no making up for it, corruption on some level is the only option will do some more experimentation, and see if I can pull down a glitchy clip over the next few days |
Beta Was this translation helpful? Give feedback.
-
In the last major revision of frigate, event clips and recordings were stored independently, resulting in video duplicated into separate storage paths. This method wasted precious storage space. Event clips were stored at their exact length, and recordings where flushed out every 60 seconds with an ffmpeg segment_time=60.
In the current version, frigate is able to use video segments for dual purpose; both recordings and event clips are pointed at the same set of files. this solved a major issue with wasted storage space. however, as a consequence, the ffmpeg segment_time is lower from 60 seconds to 10 seconds.
It took me a while to understand why the 10-second interval was chosen, but I think I've got it now... The segment_time affects when video is first flushed to disk, and an event clip isn't available for viewing until the file is flushed to disk. In practice, this means that a segement_time of 10 results in up-to-10-second-delay before the event clip is available for viewing.
Decreasing the segment_time from 60-seconds to 10-seconds has had some unfortunate deleterious effects. Namely stuttering - others have noticed too, and I've proven this to be true. When comparing frigate 0.10 performance with segment_time=600 vs segment_time=1, few intervals in between, video from 1-second intervals is very choppy, and video from 10-minute intervals is flawless.
I believe the problems stem from the following:
--
the 10-second file segment overhead is loading the system and creating stuttering. while I haven't pinpointed the exact cause, I am confident that the frigate 10-second flush interval is resulting in choppiness in both live and recorded camera streams. I can see 10-second interval chops in both live webrtc views from a simple-rtsp-server camera stream proxy hosted on the same server, and stuttering is permanently present in recorded video.
in order to create a quality recording, video must be split on a keyframe. Does frigate ensure that video segments are split and recombined only on key frames?
Video stuttering is eliminated when I reset the database and set output_args: record: segment_time=600. In some cases, I would rather wait a minute or two for an event clip to be viewable rather than store corrupted video. frigate 0.11 beta 4 does not appear to support any segment_time other than 10-seconds.
Beta Was this translation helpful? Give feedback.
All reactions