Closed jasonpstokes closed 2 years ago
blakeblackshear
commented
2 years ago I'm trying to switch to the jellyfin ffmpeg maintained build. See if their docs are helpful: https://jellyfin.org/docs/general/administration/hardware-acceleration.html
NickM-27
commented
2 years ago For a couple of my cameras on startup I will see av_interleaved_write_frame(): Invalid argument but it will go away and startup correctly after 30 - 60 seconds. Then it will be fine.
Minglarn
commented
2 years ago Having similar issues with my ReoLink cams. My ffmpeg settings:
ffmpeg:
hwaccel_args:
- -hwaccel
- vaapi
- -hwaccel_device
- /dev/dri/renderD128
- -hwaccel_output_format
- yuv420p
global_args:
- -hide_banner
- -loglevel
- debug
output_args:
# Optional: output args for detect streams (default: shown below)
detect: -f rawvideo -pix_fmt yuv420p -filter:v fps=fps=5With 0.10.1 it works flawless. But the same config with 0.11.0-beta2 is throwing ffmpeg errors.
This line kills my ffmpeg:
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c:v copy -c:a aac
When I remove it from my config all my cams work, but without sound. Even tried without "c:v copy -c:a aac" .... i just wont work. So something is not working well with this record settings ... at least for audio..
jasonpstokes
commented
2 years ago There's likely two different issues here: hardware acceleration for Intel QSV with Jellyfin FFmpeg using VAAPI, and then finding the new correct arguments to get a stable stream with audio for the (troublesome) Reolink cameras.
The latest camera firmware lists updates to RTSP and stream fixes, so I'll try it and different protocols/arguments over the weekend. (Hopefully it's raining...!)
Really like the direction of 11 and especially the UI improvements.
jasonpstokes
commented
2 years ago Turns out hardware acceleration AND audio both work for RTSP and RTMP streams, but not for HTTP streams. 🤷♂️ (see updated config here ) At least with my Reolink RLC-520A cameras - anyone else seeing this?
e.g. working RTSP stream config:
detect:
width: 640
height: 480
fps: 5
ffmpeg:
hwaccel_args: -hwaccel_output_format qsv -c:v h264_qsv
output_args: # record audio
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copy # -an
cameras:
Balcony:
ffmpeg:
inputs:
- path: rtsp://{FRIGATE_USER}:{FRIGATE_PASSWORD}@192.168.1.76:554//h264Preview_01_sub
roles:
- detect
- path: rtsp://{FRIGATE_USER}:{FRIGATE_PASSWORD}@192.168.1.76:554
roles:
- recorde.g. working RTMP stream config (RTMP has the advantage of a 'Balanced' stream option for better detect/live view resolution and, for me at least, less delay when viewing a live stream, vs. RTSP)
detect:
width: 896
height: 672
fps: 5
ffmpeg:
hwaccel_args: -hwaccel_output_format qsv -c:v h264_qsv
input_args: -avoid_negative_ts make_zero -flags low_delay -fflags discardcorrupt -strict experimental -rw_timeout 5000000 -use_wallclock_as_timestamps 1 -f live_flv
output_args:
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copy # -an
cameras:
Balcony:
ffmpeg:
inputs:
- path: rtmp://192.168.1.76/bcs/channel0_ext.bcs?channel=0&stream=2&user={FRIGATE_USER}&password={FRIGATE_PASSWORD}
roles:
- detect
- path: rtmp://192.168.1.76/bcs/channel0_main.bcs?channel=0&stream=0&user={FRIGATE_USER}&password={FRIGATE_PASSWORD}
roles:
- recordGPU working again:
EDIT: updated input_args to closer match the recommended ones in the docs.
Minglarn
commented
2 years ago Can confirm that THIS works with ReoLink rtmp streams. Nice! Thanks for finding out the right settings.. Edit: Works with both 510A, 520A and 410 models.. 👍
bm55
commented
2 years ago I can also confirm this works with Reolink 410. What is the command that shows if the GPU is working? I use docker on Ubuntu host
NickM-27
commented
2 years ago I can also confirm this works with Reolink 410.
What is the command that shows if the GPU is working? I use docker on Ubuntu host
What type of gpu do you have?
bm55
commented
2 years ago Intel Corporation UHD Graphics 620 and Matrox Electronics Systems Ltd. G200eR2
NickM-27
commented
2 years ago Intel Corporation UHD Graphics 620 and Matrox Electronics Systems Ltd. G200eR2
sudo intel_gpu_top (may need to install inside the container to use)
bm55
commented
2 years ago Following worked with frigate 10.1 but not with 11 Beta hwaccel_args:
NickM-27
commented
2 years ago Following worked with frigate 10.1 but not with 11 Beta hwaccel_args: - -hwaccel - qsv - -qsv_device - /dev/dri/renderD128
By not works you mean the gpu isn't being utilized, or there are camera crashes?
bm55
commented
2 years ago yes, crashes
[2022-05-23 09:25:13] watchdog.garage ERROR : Ffmpeg process crashed unexpectedly for garage. [2022-05-23 09:25:13] watchdog.garage ERROR : The following ffmpeg logs include the last 100 lines prior to exit. [2022-05-23 09:25:13] ffmpeg.garage.detect ERROR : [AVHWDeviceContext @ 0x55ce65e7b980] No VA display found for device /dev/dri/renderD128. [2022-05-23 09:25:13] ffmpeg.garage.detect ERROR : Device creation failed: -22. [2022-05-23 09:25:13] ffmpeg.garage.detect ERROR : Failed to set value '/dev/dri/renderD128' for option 'qsv_device': Invalid argument [2022-05-23 09:25:13] ffmpeg.garage.detect ERROR : Error parsing global options: Invalid argument [2022-05-23 09:25:13] ffmpeg.garage.record ERROR : [AVHWDeviceContext @ 0x55835aa418c0] No VA display found for device /dev/dri/renderD128. [2022-05-23 09:25:13] ffmpeg.garage.record ERROR : Device creation failed: -22. [2022-05-23 09:25:13] ffmpeg.garage.record ERROR : Failed to set value '/dev/dri/renderD128' for option 'qsv_device': Invalid argument [2022-05-23 09:25:13] ffmpeg.garage.record ERROR : Error parsing global options: Invalid argument [2022-05-23 09:25:13] watchdog.garage INFO : Terminating the existing ffmpeg process... [2022-05-23 09:25:13] watchdog.garage INFO : Waiting for ffmpeg to exit gracefully... [2022-05-23 09:25:13] frigate.video ERROR : garage: Unable to read frames from ffmpeg process. [2022-05-23 09:25:13] frigate.video ERROR : garage: ffmpeg process is not running. exiting capture thread... [2022-05-23 09:25:13] watchdog.back ERROR : Ffmpeg process crashed unexpectedly for back. [2022-05-23 09:25:13] watchdog.back ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
bm55
commented
2 years ago No errors with 10.1 Frigate
[2022-05-23 09:27:20] ws4py INFO : Managing websocket [Local => 127.0.0.1:8082 | Remote => 127.0.0.1:49240] [2022-05-23 09:27:22] ws4py INFO : Terminating websocket [Local => 127.0.0.1:8082 | Remote => 127.0.0.1:49240] [2022-05-23 09:27:25] frigate.record DEBUG : Copied /media/frigate/recordings/2022-05/23/09/back/27.12.mp4 in 0.005068063735961914 seconds. [2022-05-23 09:27:25] frigate.record DEBUG : Copied /media/frigate/recordings/2022-05/23/09/garage/27.12.mp4 in 0.005110979080200195 seconds. [2022-05-23 09:27:35] frigate.record DEBUG : Copied /media/frigate/recordings/2022-05/23/09/back/27.23.mp4 in 0.0038661956787109375 seconds. [2022-05-23 09:27:35] frigate.record DEBUG : Copied /media/frigate/recordings/2022-05/23/09/garage/27.22.mp4 in 0.004332065582275391 seconds.
NickM-27
commented
2 years ago @blakeblackshear This may explain some things: https://github.com/jellyfin/jellyfin-ffmpeg/issues/62
bm55
commented
2 years ago @jasonpstokes have you noticed any difference between your Reolink camera recording with Frigate 10.1 vs 11 Beta? I have 2 Reolink 410 and the recording playback is bit choppy with 11 beta (both http and rtmp) compared to 10.1
Minglarn
commented
2 years ago Following worked with frigate 10.1 but not with 11 Beta hwaccel_args: - -hwaccel - qsv - -qsv_device - /dev/dri/renderD128
By not works you mean the gpu isn't being utilized, or there are camera crashes?
This was the the settings I did have before changing to the qsv variant.
ffmpeg:
# hwaccel_args:
# - -hwaccel
# - vaapi
# - -hwaccel_device
# - /dev/dri/renderD128
# - -hwaccel_output_format
# - yuv420pHowever, my CPU usage is about 10-20% higher with the QSV enabled. At least audio works.
Minglarn
commented
2 years ago Did just manage to get audio working with vaapi.. My CPU went down to reasonable 30-40% usage again...
ffmpeg:
hwaccel_args: -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format yuv420p
input_args: -avoid_negative_ts make_zero -flags low_delay -strict experimental -rw_timeout 5000000 -f live_flv
output_args:
detect: -f rawvideo -pix_fmt yuv420p -filter:v fps=fps=5
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c:a copy -c:v copyyes, crashes
@bm55 For me, QSV kept crashing until my FFmpeg input arguments were "correct" to get a steady/stable FFMPEG input stream. For RTMP this was trial and error, but once there were no errors being logged QSV and audio then also worked.
have you noticed any difference
It's maybe a little worse? Need to do some proper comparisons. For the day or so I ran HTTP (with no QSV or audio) it seemed web playback was better, with less pauses and loading circles than I'd get prior to 0.11, but using RTMP streams now every clip suffers from this again. (The changelog suggests this is being worked on though)
Just noticed I haven't had any detection crashes in the two days I've been running this though, whereas I'd see fairly regularly prior to 0.11.
jasonpstokes
commented
2 years ago @Minglarn yes they work better! I get the Render/3D pipe being used now. Well done, thanks. 👍
jasonpstokes
commented
2 years ago @Minglarn you may have a typo in your detect args: fps=fps=5
jasonpstokes
commented
2 years ago HTTP streams with hwaccel and audio are working with this Frigate 0.11-beta2 config :
detect:
width: 896
height: 672
fps: 5
ffmpeg:
hwaccel_args: -hwaccel qsv -hwaccel_output_format nv12 -c:v h264_qsv
input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -flags low_delay -strict experimental -analyzeduration 1000M -probesize 1000M -rw_timeout 5000000
output_args:
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copy
cameras:
Balcony:
ffmpeg:
inputs:
- path: http://192.168.1.76/flv?port=1935&app=bcs&stream=channel0_ext.bcs&user={FRIGATE_USER}&password={FRIGATE_PASSWORD}
roles:
- detect
- path: http://192.168.1.76/flv?port=1935&app=bcs&stream=channel0_main.bcs&user={FRIGATE_USER}&password={FRIGATE_PASSWORD}
roles:
- recordEDIT2: Updated ffmpeg block as below, for a complete working config.
jasonpstokes
commented
2 years ago One more update for smoother clips; similar/same as they were in 0.10, vs the above configs that produced clips full of stutter.
ffmpeg:
hwaccel_args: -hwaccel qsv -hwaccel_output_format nv12 -c:v h264_qsv
input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -flags low_delay -strict experimental -analyzeduration 1000M -probesize 1000M -rw_timeout 5000000
output_args:
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copyThree differences from my 0.10 config, but multiple hours of trying arguments to work that out. 🤦♂️
Or, as per @minglarn's post above, use this for hardware accel using VAAPI:
hwaccel_args: -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format yuv420p
Minglarn
commented
2 years ago @Minglarn you may have a typo in your detect args:
fps=fps=5I hope not. :) It's not complaining and if I recall this was used when Linus made their AI/Object detection video.
NickM-27
commented
2 years ago Just as another note, just saw this video which shows new reolink rtsp version / settings that may give another option and hopefully fix some issues with reolink cams in general
rhatguy
commented
2 years ago Unfortunately it seems this only applies to their newer cameras. A lot of people I've seen on here have the RLC-410 or something from that era, which Reolink has now end of lifed and has said they will not fix the issues with it (even though the issues were apparent while they were still selling them a few months ago).
I just bit the bullet on 4 new Loryta 5442s and will be putting all of my reolinks on ebay if anyone is interested. I'm done with that company.
bm55
commented
2 years ago hwaccel_args: -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format yuv420p
Th
One more update for smoother clips; similar/same as they were in 0.10, vs the above configs that produced clips full of stutter.
ffmpeg: hwaccel_args: -hwaccel qsv -hwaccel_output_format nv12 -c:v h264_qsv input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -flags low_delay -strict experimental -analyzeduration 1000M -probesize 1000M -rw_timeout 5000000 output_args: record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copyThree differences from my 0.10 config, but multiple hours of trying arguments to work that out. 🤦♂️
Or, as per @Minglarn's post above, use this for hardware accel using VAAPI:
hwaccel_args: -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format yuv420p
Thanks @jasonpstokes This does improve the recording from Reolink 410 playback even without hardware accel which doesn't work on my system with the beta version and I don't notice much cpu utilization difference.
NickM-27
commented
2 years ago @jasonpstokes May be worth creating a PR with these new args in the docs: https://github.com/blakeblackshear/frigate/blob/release-0.11.0/docs/docs/configuration/camera_specific.md?plain=1#L59
targeted at the release branch, since it seems the old recommended ones don't work as well
jasonpstokes
commented
2 years ago Thanks @NickM-27 will do - will learn how! - after running it for a few days to confirm, plus to see what feedback others have.
DrSpaldo
commented
2 years ago @jasonpstokes > Or, as per @Minglarn's post above, use this for hardware accel using VAAPI: hwaccel_args: -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format yuv420p
Did you stick with the http stream or change it to something else? I am also having issues with my Reolink cameras since the new beta.
Do you mind posting a full config for the camera?
Minglarn
commented
2 years ago Im using the RTMP streams... And this is my config:
cameras:
#############################
# PARKERING #
#############################
frigate_parkering:
ffmpeg:
hwaccel_args: -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format yuv420p
input_args: -avoid_negative_ts make_zero -flags low_delay -strict experimental -rw_timeout 5000000 -f live_flv
output_args:
detect: -f rawvideo -pix_fmt yuv420p -filter:v frps=fps=5
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c:a copy -c:v copy
inputs:
- path: rtmp://192.168.1.216/bcs/channel0_main.bcs?channel=0&stream=1&user=admin&password=xxx
roles:
- record
- detect
- path: rtmp://192.168.1.216/bcs/channel0_sub.bcs?channel=0&stream=1&user=admin&password=xxx
roles:
- rtmp
@DrSpaldo see my (now updated) config above for my running config using http streams, which (appears to) give me the same recordings as 0.10. Let me know how it works for you?
@Minglarn what are your recordings like using RTMP? frps=fps=5 ? And my guess is that fps=fps=5 is a copy and paste error in ffmpeg's docs, as every other example only has fps=x??? But as Frigate's command contains -r x to force the frame rate based on the detect config block, this may be redundant anyway?
DrSpaldo
commented
2 years ago Thanks @Minglarn & @jasonpstokes for posting the configs. I’ve got the RLC-410 & RLC-511. So I’ll have a look today and see what difference using your config/s goes. Once that’s up & running then I’ll also try to get my nvidia acceleration working as well :)
Minglarn
commented
2 years ago @DrSpaldo see my (now updated) config above for my running config using http streams, which (appears to) give me the same recordings as 0.10. Let me know how it works for you?
@Minglarn what are your recordings like using RTMP?
frps=fps=5? And my guess is thatfps=fps=5is a copy and paste error in ffmpeg's docs, as every other example only hasfps=x??? But as Frigate's command contains-r xto force the frame rate based on the detect config block, this may be redundant anyway?
frps is a typo... It should be: fps=fps=5
Edit: found the video where Linus is showing his config for Frigate.
https://www.youtube.com/watch?v=B635wcdr6-w
It's about 7:20 into the video.
DrSpaldo
commented
2 years ago Getting green box with those configs :(
[2022-05-28 17:09:29] ws4py INFO : Terminating websocket [Local => 127.0.0.1:5002 | Remote => 127.0.0.1:58178]
[2022-05-28 17:09:29] ws4py INFO : Managing websocket [Local => 127.0.0.1:5002 | Remote => 127.0.0.1:58214]
[2022-05-28 17:09:31] ws4py INFO : Terminating websocket [Local => 127.0.0.1:5002 | Remote => 127.0.0.1:58214]
[2022-05-28 17:09:31] ws4py INFO : Managing websocket [Local => 127.0.0.1:5002 | Remote => 127.0.0.1:58248]
[2022-05-28 17:09:31] frigate.record WARNING : Discarding a corrupt recording segment: garage-20220528170928.mp4
[2022-05-28 17:09:31] frigate.record WARNING : Discarding a corrupt recording segment: garage-20220528170928.mp4
[2022-05-28 17:09:31] frigate.record WARNING : Discarding a corrupt recording segment: garage-20220528170928.mp4
[2022-05-28 17:09:31] frigate.record WARNING : Discarding a corrupt recording segment: garage-20220528170928.mp4
[2022-05-28 17:09:33] frigate.video ERROR : frontroad: Unable to read frames from ffmpeg process.
[2022-05-28 17:09:33] frigate.video ERROR : frontroad: ffmpeg process is not running. exiting capture thread...
[2022-05-28 17:09:45] watchdog.sidegarage ERROR : Ffmpeg process crashed unexpectedly for sidegarage.
[2022-05-28 17:09:45] watchdog.sidegarage ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
[2022-05-28 17:09:45] ffmpeg.sidegarage.detect ERROR : Device creation failed: -542398533.
[2022-05-28 17:09:45] ffmpeg.sidegarage.detect ERROR : [h264_qsv @ 0x55e394176780] No device available for decoder: device type qsv needed for codec h264_qsv.
[2022-05-28 17:09:45] ffmpeg.sidegarage.detect ERROR : Device setup failed for decoder on input stream #0:0 : Generic error in an external library
[2022-05-28 17:09:45] watchdog.frontroad ERROR : Ffmpeg process crashed unexpectedly for frontroad.
[2022-05-28 17:09:45] watchdog.frontroad ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
[2022-05-28 17:09:45] ffmpeg.frontroad.detect ERROR : Device creation failed: -542398533.
[2022-05-28 17:09:45] ffmpeg.frontroad.detect ERROR : [h264_qsv @ 0x55fe70046fc0] No device available for decoder: device type qsv needed for codec h264_qsv.
[2022-05-28 17:09:45] ffmpeg.frontroad.detect ERROR : Device setup failed for decoder on input stream #0:0 : Generic error in an external library
[2022-05-28 17:09:45] watchdog.backyard ERROR : Ffmpeg process crashed unexpectedly for backyard.
[2022-05-28 17:09:45] watchdog.backyard ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
[2022-05-28 17:09:45] ffmpeg.backyard.detect ERROR : Device creation failed: -542398533.
[2022-05-28 17:09:45] ffmpeg.backyard.detect ERROR : [h264_qsv @ 0x55ab5a1d8600] No device available for decoder: device type qsv needed for codec h264_qsv.
[2022-05-28 17:09:45] ffmpeg.backyard.detect ERROR : Device setup failed for decoder on input stream #0:0 : Generic error in an external library
[2022-05-28 17:09:47] frigate.video ERROR : frontroad: Unable to read frames from ffmpeg process.
[2022-05-28 17:09:47] frigate.video ERROR : frontroad: ffmpeg process is not running. exiting capture thread...
[2022-05-28 17:09:47] frigate.video ERROR : sidegarage: Unable to read frames from ffmpeg process.
[2022-05-28 17:09:47] frigate.video ERROR : sidegarage: ffmpeg process is not running. exiting capture thread...
[2022-05-28 17:09:48] frigate.video ERROR : backyard: Unable to read frames from ffmpeg process.No device available for decoder: device type qsv needed for codec h264_qsv.
Try it without the hwaccel_args: line? It reads like it's the wrong args for your video card - what do you have?
DrSpaldo
commented
2 years ago Yeah, I got distracted with dinner. I have tried a few different ones, I've tried yours as well as @Minglarn's vaapi option. I get similar errors. Then I just started playing around with the cuda & cuvid options as well. Nothing is working yet, I had to walk away for a little bit before my head exploded ;)
The system is running Unraid and Frigate is running via the docker/app. CPU is Intel i5-10400 & GPU is NVIDIA GTX 1050.
I have added --gpus all to the docker
DrSpaldo
commented
2 years ago Seems to be working now without the hwaccel_args line. So I guess I just need to work out the best one to use
NickM-27
commented
2 years ago Seems to be working now without the hwaccel_args line. So I guess I just need to work out the best one to use
Have you downloaded the nvidia drivers from the community store?
DrSpaldo
commented
2 years ago Yep, I have the drivers installed. Looks like I may have just had too many args in the hwaccel_args line.
Fingers crossed, this is what appears to be working for now:
GARAGE:
ffmpeg:
hwaccel_args: -c:v h264_cuvid
input_args: -avoid_negative_ts make_zero -fflags +genpts+discardcorrupt -flags low_delay -strict experimental -analyzeduration 1000M -probesize 1000M -rw_timeout 5000000
output_args:
record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c copy
inputs:
- path: rtmp://192.168.1.105/bcs/channel0_sub.bcs?channel=0&stream=1&user=USER&password=PASS
roles:
- rtmp
- path: rtmp://192.168.1.105/bcs/channel0_main.bcs?channel=0&stream=1&user=USER&password=PASS
roles:
- detect
- recordOriginally I had quite a few things and now it is just stripped back to one for the hwaccel_args
jasonpstokes
commented
2 years ago Linking pull for docs update and closing. https://github.com/blakeblackshear/frigate/pull/3292
Redsandro
commented
1 year ago This is very helpful. rtsp can be very stable one day, and totally smearing the next. I really don't understand the technical logistics as to why rtsp is smearing so much and why http has such a big delay, but http is indeed more reliable.
Unfortunately in higher resolutions, http has quite a big delay (8-12s) compared to rtsp (2-4s). Also, the high resolution delay is closer to the low resolution delay in rtsp recordings compared to http, so if you're using the low resolution for detection and the high resolution for recording, you are going to have a bad time in http where objects just left the recording. These observations were made with a couple of Reolink E1 Zoom PTZ ONVIF cameras.
So it looks like you can't go right. For live security monitoring rtsp is better. For reliable non-corrupted visuals, http is better. It's disappointing, because a 12 second delay really isn't very useful if you want an MQTT alert that a mailman is approaching before he rings the doorbell.
Are these delays and smears common properties of video feeds, or is this typical of Reolink?
Does anyone have any new insights as to what is the best approach?
For reverence, the Reolink Z1 Zoom has 3 streams; main, ext and sub. They support http, rtmp and rtsp:
http://{CAM_IP}/flv?port=1935&app=bcs&stream=channel0_sub.bcs&user={FRIGATE_USER}&password={FRIGATE_PASS}
rtmp://{CAM_IP}/bcs/channel0_sub.bcs?token=sdasdasd&channel=0&stream=0&user={FRIGATE_USER}&password={FRIGATE_PASS}
rtsp://{FRIGATE_USER}:{FRIGATE_PASS}@{CAM_IP}:554/h264Preview_01_subPS flv has nothing to do with the ice age, mammoths or flash video. It outputs h264.
NickM-27
commented
1 year ago Unfortunately in higher resolutions, http has quite a big delay (8-12s) compared to rtsp (2-4s). Also, the high resolution delay is closer to the low resolution delay in rtsp recordings compared to http, so if you're using the low resolution for detection and the high resolution for recording, you are going to have a bad time in http where objects just left the recording. These observations were made with a couple of Reolink E1 Zoom PTZ ONVIF cameras.
How are you measuring that delay?
That's an older camera with old firmware. Their newer cameras have more options like setting iframe interval and CBR.
I have been using reolinks new doorbell as well as the 511wa and on both of them rtsp or http has virtually no delay. I have their http streams setup in go2rtc and can watch via WebRTC while looking out my window and things are the same as real time.
Are these delays and smears common properties of video feeds, or is this typical of Reolink?
I've never heard of delay being an issue. The smearing on rtsp is typical reolink due to their bad rtsp engine that they use, though cameras with newer firmware have improved on this front too.
Does anyone have any new insights as to what is the best approach?
Like I said above I've had great results with http on these two newer reolinks.
Redsandro
commented
1 year ago How are you measuring that delay?
I'm standing in front of the camera while looking at my phone as I raise my hand and count the seconds. :smile:
I have to amend this by saying that the camera catches up after a minute or two after restarting frigate. So the delay is less, but still more if you use the bigger stream compared to the smaller stream, and definitely more using http than using rtsp. There's not really a choice though, because the rtsp garbling and smearing causes false zone positives. I just use the small stream for detection and set a bit longer pre-roll.
Keep in mind that the 511wa costs roughly 3 times the E1, so perhaps the delay is more prevalent with super weak hardware inside the E1.
I have been using reolinks new doorbell as well as the 511wa and on both of them rtsp or http has virtually no delay. I have their http streams setup in go2rtc and can watch via WebRTC while looking out my window and things are the same as real time.
This is interesting. I may want to look into this 511wa for better feeds, although others recommend that if you're going to invest in better cameras anyway, you may as well go for Dahua directly. For example, @rhatguy commented:
I can say I have had good luck with the Loryta cams recommended by frigate after having horrible luck with Reolinks previously. I run one T2431and 4 other T5442 (recommended cam). I can say its night and day different having used the reolinks before. These Loryta (rebranded Dahua) cams streams are SOLID and quick. I'd HIGHLY recommend these cams myself.
NickM-27
commented
1 year ago 'm standing in front of the camera while looking at my phone as I raise my hand and count the seconds. 😄
Yeah but what are you using to view? If you are using frigate live view then it isn't really true comparison because that's counting decoding the stream, motion & object detection latency. Viewing directly from the camera will be different (like in my using webrtc example)
This is interesting. I may want to look into this 511wa for better feeds, although others recommend that if you're going to invest in better cameras anyway, you may as well go for Dahua directly.
I got the 511wa due to it's specific focal length and aspect ratio which was very specific for my use case and I did not find other cameras that fit my needs in that way.
Also to be clear that user was talking about using 8MP reolinks which is a different story entirely.
NickM-27
commented
1 year ago it's also worth noting that if you are using frigate to compare the latency, hardware accelerated decoding will also improve that latency. When using my CPU it is ~ 2 seconds delay in Frigate jsmpeg (the live view in 0.11) and when using my nvidia gpu it is sub 1 second in Frigate with jsmpeg.
Redsandro
commented
1 year ago Interesting observations. Yes I did use frigate live view so I guess it's not entirely fair, although I can clearly see a latency difference where rtsp is faster. I also tried mpv from a laptop computer to open the streams directly, and here the difference is even bigger. rtsp is 5 seconds ahead of http when opened at the same time. I couldn't say to what degree that is because of mpv and to what degree that's because of the Reolink E1.
NickM-27
commented
1 year ago Interesting, that camera must really be rough then 😲 Watching my reolinks live view via Frigate webrtc in 0.12 or VLC player rstp and http are both very close to real time
mrplow
commented
1 year ago I found something interesting related to iframes aka keyframes and http vs rtsp.
I have a reolink duo gen1 and an 810A and this thread was invaluable to getting things working great.
The newer firmware versions for these cameras have the option to set the "Interframe Space" value from 1x to 4x. I understand keyframes and fps and all that, but I wasn't exactly sure what "Interframe Space" meant in reolink's setting.
I used ffprobe to see how changing that value would affect the keyframe interval using:
ffprobe -loglevel error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=print_section=0 "http://192.168.1.150/flv?port=1935&app=bcs&stream=channel0_ext.bcs&user=[redacted]&password=[redacted]"
But, I found that changing "Interframe Space" made no difference to the keyframe interval. With my fps set to 15 the keyframes were occuring once every other second, and then I noticed that it was actually outputting at 20 fps, not 15. After trying a few other settings the fps and keyframe interval didn't change.
I tried the same ffprobe command but pointed it to my rtsp url.
ffprobe -loglevel error -select_streams v:0 -show_entries packet=pts_time,flags -of csv=print_section=0 "rtsp://[redacted]:[redacted]@192.168.1.150:554/h264Preview_01_sub"
Using rtsp, the keyframes are once per second and the fps was what I actually set it to.
So, I set my conf to use the http url for recording and the rtsp stream for detect. We'll see how it goes but it seems fine so far.
In the end, I think their "Interframe Space" setting really means number of seconds per keyframe. So, 1x would be 1 keyframe/sec, 4x would be 1 keyframe/4sec. Also, the http url doesn't seem to adhere to the fps/keyframe settings, at least for the substream. This issue does only seem to be on the substream as the main stream was recorded via http and my videos have their keyframes 1/sec and recording at 15fps.
DrSpaldo
commented
1 year ago Has anyone used any of the Reolink camera's for the go2rtc in the new betas? I have started getting all the old errors again now since switching over and was wondering how anyone else may have got it working...
2023-02-12 14:55:58.376464857 [2023-02-12 14:55:58] watchdog.sidegarage ERROR : Ffmpeg process crashed unexpectedly for sidegarage.
2023-02-12 14:55:58.376494923 [2023-02-12 14:55:58] watchdog.sidegarage ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
2023-02-12 14:55:58.413668639 [2023-02-12 14:55:58] watchdog.frontroad ERROR : Ffmpeg process crashed unexpectedly for frontroad.
2023-02-12 14:55:58.413700492 [2023-02-12 14:55:58] watchdog.frontroad ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
2023-02-12 14:55:58.708388730 [2023-02-12 14:55:58] watchdog.backyard ERROR : Ffmpeg process crashed unexpectedly for backyard.
2023-02-12 14:55:58.708444622 [2023-02-12 14:55:58] watchdog.backyard ERROR : The following ffmpeg logs include the last 100 lines prior to exit.
2023-02-12 15:09:58.425161190 [2023-02-12 15:09:58] watchdog.sidegarage ERROR : No new recording segments were created for sidegarage in the last 120s. restarting the ffmpeg record process...
2023-02-12 15:09:58.425225011 [2023-02-12 15:09:58] watchdog.sidegarage INFO : Terminating the existing ffmpeg process...
2023-02-12 15:09:58.425284593 [2023-02-12 15:09:58] watchdog.sidegarage INFO : Waiting for ffmpeg to exit gracefully...
2023-02-12 15:09:58.439140113 [2023-02-12 15:09:58] watchdog.frontroad ERROR : No new recording segments were created for frontroad in the last 120s. restarting the ffmpeg record process...
2023-02-12 15:09:58.439211354 [2023-02-12 15:09:58] watchdog.frontroad INFO : Terminating the existing ffmpeg process...
2023-02-12 15:09:58.439263185 [2023-02-12 15:09:58] watchdog.frontroad INFO : Waiting for ffmpeg to exit gracefully...
2023-02-12 15:09:58.737639221 [2023-02-12 15:09:58] watchdog.backyard ERROR : No new recording segments were created for backyard in the last 120s. restarting the ffmpeg record process...
2023-02-12 15:09:58.737700121 [2023-02-12 15:09:58] watchdog.backyard INFO : Terminating the existing ffmpeg process...
2023-02-12 15:09:58.737742116 [2023-02-12 15:09:58] watchdog.backyard INFO : Waiting for ffmpeg to exit gracefully...
Describe the problem you are having
Green screens and errors (with Reolink cameras) if using FFmpeg
hwaccel_argsfor QSV, plus previousdetectandrecordargs also throw errors.Intel 11th Gen NUC running Clear Linux + Docker.
This FFmpeg config works without errors:
EDIT: note
- hwaccel qsvhas been deprecated according to logged output, thus my new argument in config.(Trying to find the new record args to get audio now...)
Version
0.11.0-D2C3CDC
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
Reolink RLC-520A
Any other information that may be helpful
docker-compose