Sorry totally missed this reply!
It looks like you are using a camera which doesnt use RTSP, so you have to set stream_format: mjpeg for the camera.
You are correct. That camera doesn’t support RTSP. I already set the stream_format to mjpeg.
After that I got these errors.
Ahh sorry, I see. I need to make sure stimeout is not included in the default command if stream_format: mjpeg.
In the meantime you can override this in the config.
Can you try this config and see if you get any other errors:
cameras:
- name: Voordeur
mqtt_name: viseron_voordeur
host: deurbel.lan
port: 8081
path: /
width: 800
height: 600
stream_format: mjpeg
fps: 6
input_args:
- -avoid_negative_ts
- make_zero
- -fflags
- nobuffer
- -flags
- low_delay
- -strict
- experimental
- -fflags
- +genpts
- -use_wallclock_as_timestamps
- 1
- -vsync
- 0
motion_detection:
interval: 1
trigger_detector: false
object_detection:
interval: 1
labels:
- label: person
confidence: 0.9
- label: pottedplant
confidence: 0.9
I get the following error with this config:
[2020-10-09 06:27:35] [root ] [INFO ] - -------------------------------------------
[2020-10-09 06:27:35] [root ] [INFO ] - Initializing...
[2020-10-09 06:27:35] [root ] [DEBUG ] - Starting cleanup scheduler
[2020-10-09 06:27:35] [root ] [DEBUG ] - Running initial cleanup
[2020-10-09 06:27:35] [lib.cleanup ] [DEBUG ] - Running cleanup
[2020-10-09 06:27:35] [lib.cleanup ] [DEBUG ] - Items in /recordings/2020-10-06: 1
[2020-10-09 06:27:35] [lib.mqtt ] [INFO ] - Initializing MQTT connection
[2020-10-09 06:27:35] [lib.detector ] [DEBUG ] - Initializing object detector
[2020-10-09 06:27:35] [root ] [INFO ] - -------------------------------------------
[2020-10-09 06:27:35] [root ] [INFO ] - Initializing...
[2020-10-09 06:27:35] [root ] [DEBUG ] - Starting cleanup scheduler
[2020-10-09 06:27:35] [root ] [DEBUG ] - Running initial cleanup
[2020-10-09 06:27:35] [lib.cleanup ] [DEBUG ] - Running cleanup
[2020-10-09 06:27:35] [lib.cleanup ] [DEBUG ] - Items in /recordings/2020-10-06: 1
[2020-10-09 06:27:35] [lib.mqtt ] [INFO ] - Initializing MQTT connection
[2020-10-09 06:27:35] [lib.detector ] [DEBUG ] - Initializing object detector
[2020-10-09 06:27:35] [lib.detector ] [DEBUG ] - OpenCL activated
[2020-10-09 06:27:35] [lib.detector ] [DEBUG ] - Object detector initialized
[2020-10-09 06:27:35] [root ] [INFO ] - Initializing NVR threads
[2020-10-09 06:27:35] [lib.nvr.voordeur ] [DEBUG ] - Initializing NVR thread
[2020-10-09 06:27:35] [lib.camera.voordeur ] [DEBUG ] - Initializing ffmpeg RTSP pipe
[2020-10-09 06:27:35] [lib.camera.voordeur ] [DEBUG ] - Resolution: 800x600 @ 6 FPS
Traceback (most recent call last):
File "viseron.py", line 155, in <module>
main()
File "viseron.py", line 47, in main
mqtt_queue=mqtt_queue,
File "/src/viseron/lib/nvr.py", line 137, in __init__
self.camera = FFMPEGCamera(config, frame_buffer)
File "/src/viseron/lib/camera.py", line 126, in __init__
self.start_decoder()
File "/src/viseron/lib/camera.py", line 165, in start_decoder
self._logger.debug(f"FFMPEG decoder command: {' '.join(self.build_command())}")
TypeError: sequence item 15: expected str instance, int found
Ahh all elements in the input_args needs to be strings, so this should do it:
cameras:
- name: Voordeur
mqtt_name: viseron_voordeur
host: deurbel.lan
port: 8081
path: /
width: 800
height: 600
stream_format: mjpeg
fps: 6
input_args:
- -avoid_negative_ts
- make_zero
- -fflags
- nobuffer
- -flags
- low_delay
- -strict
- experimental
- -fflags
- +genpts
- -use_wallclock_as_timestamps
- "1"
- -vsync
- "0"
motion_detection:
interval: 1
trigger_detector: false
object_detection:
interval: 1
labels:
- label: person
confidence: 0.9
- label: pottedplant
confidence: 0.9
It is working! Thank you!
1 Like
Thank You. Will something like this ever be made as a hassio
addon for the techie challenged like me
1 Like
I plan on doing this sometime in the future but i cant promise anything.
I have never made an addon before so if anyone here knows how its done i would appreciate any help!
1 Like
Hello, I have been running this for a month or so now on an rpi3B and it works as wells you can expect on this hardware with one stream. I recently bought a coral TPU to use with this and plugged it in and rebooted everything. Is there any indication that it is using the TPU instead of the CPU in the logs? This is what it looks like upon starting the container. Do I need to add anything to the config to enable the TPU or is it enabled automatically?
pi@viseronpi:~/viseron $ docker run --rm --privileged -v /home/pi/Videos:/recordings -v /home/pi/viseron:/config -v /etc/localtime:/etc/localtime:ro -v /dev/bus/usb:/dev/bus/usb -v /opt/vc/lib:/opt/vc/lib --name viseron --device /dev/vchiq:/dev/vchiq --device /dev/vcsm:/dev/vcsm roflcoopter/viseron-rpi:latest
[2020-11-16 03:25:42] [root ] [INFO ] - -------------------------------------------
[2020-11-16 03:25:42] [root ] [INFO ] - Initializing...
[2020-11-16 03:25:42] [lib.mqtt ] [INFO ] - Initializing MQTT connection
[2020-11-16 03:25:45] [root ] [INFO ] - Initializing NVR threads
[2020-11-16 03:25:51] [lib.camera.driveway ] [WARNING ] - ffprobe failed to get stream information. Using OpenCV instead
[2020-11-16 03:25:59] [root ] [INFO ] - Initialization complete
[2020-11-16 12:53:15] [lib.recorder.driveway ] [INFO ] - Starting recorder
[2020-11-16 12:53:15] [lib.recorder.driveway ] [INFO ] - Creating folder /recordings/2020-11-16/Driveway
[2020-11-16 12:53:24] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 9
[2020-11-16 12:53:26] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 8
[2020-11-16 12:53:28] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 7
[2020-11-16 12:53:31] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 6
[2020-11-16 12:53:33] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 5
[2020-11-16 12:53:35] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 4
[2020-11-16 12:53:37] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 3
[2020-11-16 12:53:39] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 2
[2020-11-16 12:53:42] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 1
[2020-11-16 12:53:44] [lib.nvr.driveway ] [INFO ] - Stopping recording in: 0
[2020-11-16 12:53:44] [lib.recorder.driveway ] [INFO ] - Stopping recorder
[2020-11-16 12:53:44] [lib.nvr.driveway ] [INFO ] - Pausing object detector
[2020-11-16 12:53:44] [lib.recorder.driveway ] [INFO ] - FFMPEG recorder stopped
Thanks!
Clayton
The RPi image defaults to using EdgeTPU, unless you have changed this in your config.
If you enable debug logging for object_detection like so:
object_detection:
logging:
level: debug
It should log something like Using USB EdgeTPU.
Viseron also warns if it cant use the EdgeTPU for some reason.
You should also see the CPU usage go down drastically if its using the EdgeTPU or not.
Thanks! Any idea why this camera config would cause me to get these errors? When I change the path, width, height, & Framerate details to the substream details, it works fine. Is this resolution too much? Is there any benefit to running this on the 640x480 15fps sub stream vs the HD main stream?
cameras:
- name: Driveway
mqtt_name: viseron_driveway
host: 192.168.1.19
port: 554
username: admin
password: XXXXXXXX
path: //h264Preview_01_main
width: 2560
height: 1440
fps: 30
motion_detection:
interval: 1
trigger_detector: true
timeout: true
object_detection:
interval: 1
labels:
- label: person
confidence: 0.5
- label: car
confidence: 0.9
viseronpi:~/viseron $ docker run --rm --privileged -v /home/pi/Videos:/recordings -v /home/pi/viseron:/config -v /etc/localtime:/etc/localtime:ro -v /dev/bus/usb:/dev/bus/usb -v /opt/vc/lib:/opt/vc/lib --name viseron --device /dev/vchiq:/dev/vchiq --device /dev/vcsm:/dev/vcsm roflcoopter/viseron-rpi:latest
[2020-11-16 15:28:57] [root ] [INFO ] - -------------------------------------------
[2020-11-16 15:28:57] [root ] [INFO ] - Initializing...
[2020-11-16 15:28:58] [lib.mqtt ] [INFO ] - Initializing MQTT connection
[2020-11-16 15:29:01] [root ] [INFO ] - Initializing NVR threads
[2020-11-16 15:29:06] [lib.camera.driveway ] [WARNING ] - ffprobe failed to get stream information. Using OpenCV instead
[2020-11-16 15:29:10] [root ] [INFO ] - Initialization complete
[2020-11-16 15:29:13] [lib.camera.driveway ] [ERROR ] - Error starting decoder pipe! mmal: mmal_vc_port_info_set: failed to set port info (2:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0x1acaaa0 (EINVAL)
mmal: mmal_port_disable: port vc.ril.video_decode:in:0(H264)(0x1acaaa0) is not enabled
mmal: mmal_port_disable: port vc.ril.video_decode:out:0(0x1acadc0) is not enabled
mmal: mmal_port_disable: port vc.ril.video_decode:ctr:0(0x1aca790) is not enabled
Retrying in 5 seconds
f[2020-11-16 15:29:22] [lib.camera.driveway ] [ERROR ] - Error starting decoder pipe! mmal: mmal_vc_port_info_set: failed to set port info (2:0): EINVAL
mmal: mmal_vc_port_set_format: mmal_vc_port_info_set failed 0x2323640 (EINVAL)
mmal: mmal_port_disable: port vc.ril.video_decode:in:0(H264)(0x2323640) is not enabled
mmal: mmal_port_disable: port vc.ril.video_decode:out:0(0x2323960) is not enabled
mmal: mmal_port_disable: port vc.ril.video_decode:ctr:0(0x2323330) is not enabled
Retrying in 5 seconds
That happens when the RPI runs out of GPU memory. There is a note in the README about this:
To make use of hardware accelerated decoding/encoding you might have to increase the allocated GPU memory. To do this edit /boot/config.txt and set gpu_mem=256 and then reboot.
Im not sure if increasing the memory will allow that resolution anyways tho.
If you check out the latest beta, you can define a substream which image processing is performed on, and then the recordings will be from your main stream.
Thanks! I had already increased the GPU memory to 256, so I suspect the resolution is just too much for an rpi3B. Any plans to get this working on an rpi4?
Yeah i suspected that…
Actually yes! I have spent a lot of time totally reworking how i build my containers, and 1.8.0 will probably be the release for this. I got all pieces working but need to update my build/release scripts to reflect the changes. The rewrite makes it possible for me to cross-build containers on hardware i dont have.
So sit tight, should be released in the coming days
That is awesome news! I have one last questions! Is there a way to make the timestamps the saved videos are given show the actual local time? As you can see from the screenshot below, the files are named with a time roughly six hours offset from the local time.
Should work if you mount /etc/localtime into the container, like so /etc/localtime:/etc/localtime
localtime is already mounted. Here is the docker command I am using to start the container. Is RO the timezone code?
docker run --rm --privileged -v /home/pi/Videos:/recordings -v /home/pi/viseron:/config -v /etc/localtime:/etc/localtime:ro -v /dev/bus/usb:/dev/bus/usb -v /opt/vc/lib:/opt/vc/lib --name viseron --device /dev/vchiq:/dev/vchiq --device /dev/vcsm:/dev/vcsm roflcoopter/viseron-rpi:1.7.0b3
ro just means readonly.
It might be related to this issue, which is solved in the current beta. If you switch from tag latest to 1.7.0b3 you could try this out. I will release 1.7.0 in a few days however if you dont want to use the beta
I would love to see this as addon as well!
I’m not a programmer, but I did find this tutorial on how to make an addon:
Hope it helps!