frigate
frigate copied to clipboard
blakeblackshear
[Support]: frigate.object_processing warning
Describe the problem you are having
I just had some warnings in the log file related to snapshot and . This warnings occured on the very same moment Frigate detect a person in a required zone. I've looked back on the 24/7 recording, and no person was there in that zone (or any other zone). The generated snapshot is a fully black tile (in the event viewer). The generated clip is very long (43 minutes) and not useable when I try to open it with VLC or any other media player. The 24/7 recordings are fine. The warning about the missing jpg in the cache is something I've noticed a couple of times before, but this is something that seems to happen to more users?
I've been running Frigate for quite some time now, I moved to the 0.12 beta on the first day. I did not have any serious problems or issues so far. I realise that based on my information there is not much you can do about it (I guess), but maybe somebody is experiencing the same thing. Any thoughts?
Version
0.12.0 beta 2
Frigate config file
mqtt:
host: addon_core_mosquitto
user: mqtt
password: REDACTED
port: 1883
ffmpeg:
hwaccel_args:
- -hwaccel
- vaapi
- -hwaccel_device
- /dev/dri/renderD128
- -hwaccel_output_format
- yuv420p
cameras:
driveway:
ffmpeg:
output_args:
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copy -tag:v hvc1 -c:a aac
inputs:
- path: rtsp://admin:[email protected]:554/cam/realmonitor?channel=1&subtype=0
roles:
- record
- restream
- path: rtsp://admin:[email protected]:554/cam/realmonitor?channel=1&subtype=2
roles:
- detect
detect:
width: 1920
height: 1080
fps: 10
motion:
mask:
- 1036,106,1119,150,1659,305,1920,417,1920,0,1021,0
mqtt_off_delay: 60
improve_contrast: True
record:
enabled: True
retain:
days: 2
mode: all
events:
required_zones:
- zone_driveway
- zone_porch
pre_capture: 15
post_capture: 15
retain:
default: 21
mode: all
snapshots:
enabled: True
bounding_box: True
quality: 100
required_zones:
- zone_driveway
- zone_porch
retain:
default: 21
best_image_timeout: 0
zones:
zone_street:
coordinates:
#1068,0,1920,0,1920,422,1063,113
1068,0,1920,0,1920,422,1494,224,1063,113
objects:
- car
- bus
filters:
person:
min_score: 0.55
threshold: 0.70
#min_area: 10000
max_area: 400000
zone_driveway:
coordinates:
0,1080,1920,1080,1920,640,1694,516,1472,389,1293,274,1017,369,485,524,157,339,0,355
objects:
- person
- cat
- dog
filters:
person:
min_score: 0.55
threshold: 0.70
min_area: 10000
max_area: 400000
cat:
min_score: 0.55
threshold: 0.70
max_area: 35000
dog:
min_score: 0.55
threshold: 0.70
max_area: 35000
zone_porch:
coordinates:
1041,243,1146,213,1043,167
objects:
- person
- cat
- dog
filters:
person:
min_score: 0.55
threshold: 0.70
max_area: 400000
zone_driveway_parking_1:
coordinates:
1335,966,1920,1043,1793,466,1654,403,1533,367,1147,641
objects:
- car
- bus
filters:
person:
min_score: 0.55
threshold: 0.70
#min_area: 10000
max_area: 400000
zone_driveway_parking_2:
coordinates:
1036,294,1239,307,1431,340,1558,397,1346,476,1146,475,1043,389
objects:
- car
- bus
filters:
person:
min_score: 0.55
threshold: 0.70
#min_area: 10000
max_area: 400000
objects:
track:
- person
- car
- bus
- cat
- dog
filters:
person:
min_score: 0.55
threshold: 0.70
#min_area: 10000
max_area: 400000
cat:
mask:
- 849,420,1365,1080,0,1080,0,0,589,0
dog:
mask:
- 849,420,1365,1080,0,1080,0,0,589,0
detectors:
coral:
type: edgetpu
device: usb
timestamp_style:
format: "%d/%m/%Y %H:%M:%S"
logger:
default: info
logs:
frigate.event: debug
restream:
enabled: True
force_audio: False
birdseye: False
jsmpeg:
height: 720
quality: 16
birdseye:
quality: 16
mode: motion
ui:
use_experimental: False
Relevant log output
2023-01-12 13:28:01.840608950 [2023-01-12 13:28:01] frigate.object_processing WARNING : Unable to create jpg because frame 1673526480.672723 is not in the cache
2023-01-12 13:28:02.017415951 [2023-01-12 13:28:02] frigate.object_processing WARNING : Unable to create jpg because frame 1673526480.672723 is not in the cache
2023-01-12 13:28:09.525372514 [2023-01-12 13:28:09] frigate.object_processing WARNING : Unable to create jpg because frame 1673526480.672723 is not in the cache
2023-01-12 13:28:09.525376756 [2023-01-12 13:28:09] frigate.object_processing WARNING : Unable to save snapshot for 1673523718.366884-gl02of.
2023-01-12 13:28:09.525378719 [2023-01-12 13:28:09] frigate.object_processing WARNING : Unable to create clean png because frame 1673526480.672723 is not in the cache
2023-01-12 13:28:09.525380460 [2023-01-12 13:28:09] frigate.object_processing WARNING : Unable to save clean snapshot for 1673523718.366884-gl02of.
2023-01-12 13:28:09.537355908 [2023-01-12 13:28:09] frigate.object_processing WARNING : Unable to create jpg because frame 1673526480.672723 is not in the cache
FFprobe output from your camera
"[\n {\n \"return_code\": 0,\n \"stderr\": {},\n \"stdout\": {\n \"programs\": [],\n \"streams\": [\n {\n \"avg_frame_rate\": \"25/1\",\n \"codec_long_name\": \"H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10\",\n \"height\": 2160,\n \"width\": 3840\n },\n {\n \"avg_frame_rate\": \"0/0\",\n \"codec_long_name\": \"AAC (Advanced Audio Coding)\"\n }\n ]\n }\n },\n {\n \"return_code\": 0,\n \"stderr\": {},\n \"stdout\": {\n \"programs\": [],\n \"streams\": [\n {\n \"avg_frame_rate\": \"10/1\",\n \"codec_long_name\": \"H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10\",\n \"height\": 1080,\n \"width\": 1920\n }\n ]\n }\n }\n]"
Frigate stats
No response
Operating system
Other Linux
Install method
Docker CLI
Coral version
USB
Network connection
Wired
Camera make and model
Dahua
Any other information that may be helpful
No response
Not sure it will necessary help but I'd highly recommend switching your hwaccel args to use the new presets as it will help frigate work better.
also please share your docker cli command
Hi Nick,
Thanks for the quick reply!
I've updated the hwaccel_args to preset-intel-qsv-h264. My docker CIL command is this:
docker run -d
--privileged
--name frigate
--restart=unless-stopped
--device /dev/bus/usb:/dev/bus/usb
--device /dev/dri/renderD128
--shm-size=64m
--network hassio
-v /storage/frigate/media:/media/frigate
-v /storage/frigate/tmp:/tmp/cache
-v /usr/share/hassio/homeassistant/frigate.yml:/config/config.yml:rw
-v /etc/localtime:/etc/localtime:ro
-e FRIGATE_RTSP_PASSWORD='REDACTED'
-e PLUS_API_KEY='REDACTED'
-p 8554:8554
-p 5000:5000
-p 1935:1935
blakeblackshear/frigate:0.12.0-beta2
Then you should also replace -v /storage/frigate/tmp:/tmp/cache with --mount type=tmpfs,target=/tmp/cache,tmpfs-size=100000000 to your docker run command so frigate can use the RAM as cache instead of storage, that might be what is causing this issue
I've had this in the past, but I had problems when the cache size is not big enough to hold the complete length of the event. Is this handled differently in this version?
Will it make any differnce I/O wise to store the cache on disk instead of RAM? In my case I have 24/7 recording enabled, so all streamed data is saved to disk anyway. I can image that when you move from one segment to another, you do some something like "mv /tmp/cache/clip.mp4 /media/frigate/recordings/
I've had this in the past, but I had problems when the cache size is not big enough to hold the complete length of the event. Is this handled differently in this version?
Not sure what exactly you're referring to being handled, but nothing has changed with the way segments are kept in cache.
Will it make any differnce I/O wise to store the cache on disk instead of RAM? In my case I have 24/7 recording enabled, so all streamed data is saved to disk anyway. I can image that when you move from one segment to another, you do some something like "mv /tmp/cache/clip.mp4 /media/frigate/recordings////xx.xx.mp4 . I would say that doing so will not generate more I/O operations than moving from RAM to disk?
It's not about I/O operations it is about speed. We don't just move the segment from cache to disk we have ffmpeg optimize it for playback. So having it in memory makes this quicker, given the fact that the tmp size can be configured I see absolutely no reason to not have this done in RAM.
Not sure what exactly you're referring to being handled, but nothing has changed with the way segments are kept in cache.
I seem to remeber that running the cache from RAM resulted in trouble when there long lasting events.... Or am I mistaken?
I seem to remeber that running the cache from RAM resulted in trouble when there long lasting events.... Or am I mistaken?
I am not aware of that ever being an issue, the segments are 10 seconds and it is entirely irrelevant how long the event itself lasts
Ok. And when you download clips by means of the API... Is this data also saved in /tmp? I can remember doing that in the beginning I started to use Frigate. I had lots of issues with that back then. I can retest this with memory tmp to verify this.
if you use the clip.mp4 API it will write to /tmp however we don't recommend using that as there are plenty of ways to download a big clip using the HLS playlist API instead.
I will investigate on the HLS playlist API. But isn't better to to create a directory in /media/frigate on disk for this function?
I will investigate on the HLS playlist API. But isn't better to to create a directory in /media/frigate on disk for this function?
It definitely needs to be fixed but writing a big file to the SSD (or HDD) isn't really a better solution. A better solution would be a progressive download that was downloaded straight to the users device.
I use the clip.mp4 a couple of times a day to download clips in a Node-RED flow. If I use HTTP Live Streaming I still have to merge the segments, still resulting in disk writes.
Can you plesae consider using a disk tmp folder for the clip.mp4 function? I can imagine a direct download needs some more effort.
@blakeblackshear how do you think about this?
I loooked into the source, and Frigate also used clip.mp4 API to generate a download. I retested with mem cache, and when downloading an event I get lots errors. Bottom line is this:
2023-01-13 07:10:24.261140499 [2023-01-13 07:10:24] ffmpeg.oprit.record_restream ERROR : [segment @ 0x5614cb179bc0] Failure occurred when ending segment '/tmp/cache/oprit-20230113071014.mp4' 2023-01-13 07:10:24.261142086 [2023-01-13 07:10:24] ffmpeg.oprit.record_restream ERROR : Error writing trailer of /tmp/cache/oprit-%Y%m%d%H%M%S.mp4: No space left on device 2023-01-13 07:10:24.261171331 [2023-01-13 07:10:24] watchdog.oprit INFO : Terminating the existing ffmpeg process... 2023-01-13 07:10:24.261172879 [2023-01-13 07:10:24] watchdog.oprit INFO : Waiting for ffmpeg to exit gracefully...
And during download:
100 MB is very little, why not just increase the amount of RAM that can be used. It's only used when it's actually needed.
I agree. But theoretically it can still go wrong, whatever size you choose. If I have to reserve 1GB for RAM for all of my dockers for something they rarely need, I have to put in 32 GB of RAM. What bothers me most is that the download function can completely shut down and corrupt the recording of the actual life feeds.
What is your biggest objection not the put the clips in a tmp directory on disk? Doing so will make things a lot easier on installations with low RAM.
What bothers me most is that the download function can completely shut down and corrupt the recording of the actual life feeds.
I agree this should be handled, would probably be to compare the size of the segments being concatenated and if there's not enough cache left leave an error instead of writing all the way to 0 bytes.
What is your biggest objection not the put the clips in a tmp directory on disk? Doing so will make things a lot easier on installations with low RAM.
To be clear I never objected to it.
It's bad practice to write to storage directories that aren't mapped in docker. So we'd need to write the file to somewhere in /media/frigate. That means if the frigate container was stopped after the download before deleting the file then the downloaded file would be stuck taking up space and frigate would have no knowledge of it. This makes the whole solution needing to be more complete where frigate has a record of these files and deletes them appropriately. At this point the solution is not a simple change of 1 line at which point I'd rather just solve it correctly with a progressive download approach.
My suggestion would to place the downloads in /media/frigate/tmp. Whenever the docker starts just delete everything that exists within that folder as it is not needed anymore. Or make the path configurable in the config file and make it the responsibility of the user.
I still dont understand why you are using the clip.mp4 endpoint. Are you able to run ffmpeg in your node-red flow?
All you need to do is run a command like the following and ffmpeg will stream it directly to a single file for you.
ffmpeg -i http://192.168.2.4:5000/vod/event/1673568800.499354-mq7hld/master.m3u8 -c copy clip.mp4
You can use the endpoint where you specify a start/end time as well. No need to worry about merging files.
I managed to run ffmpeg in node-red, and I also managed stream to a single file. I used the clip.mp4 endpoint to push the clip to the cloud after it's finished. Now I can use the HTTP live stream for this.
I assume that modifying the internal download function to HLS is also on the road map?
Thank you both for guiding me in the right direction.
Glad that worked. So, are you still getting these warnings in the logs or can this be closed?
Yes, this issue can be closed. However, I'm still curious when and if the internal download function will updated... 😉
However, I'm still curious when and if the internal download function will updated... 😉
Probably around the same time that https://github.com/blakeblackshear/frigate/issues/2369 is worked on