Open jplwoodward opened 1 year ago
It should work with any camera. Do you have devices mapped in your docker-compose?
devices:
- /dev:/dev
Intel/QSV support is in the works but requires additional drivers and ffmpeg build so it will be a different docker image.
I do not use compose...I just use docker run with arguments...what would that be for mapping dev:? Thanks for your help!
You could probably add something like this to your run command for the pi4:
--device=/dev/video10:/dev/video10 --device=/dev/video11:/dev/video11 --device=/dev/video12:/dev/video12 -e H264_ENC=h264_v4l2m2m
and if you want to force encode without rotation, you can add -e FORCE_ENCODE=true
Thanks. I tried that. Your logs imply it worked:
[WyzeBridge] 🎉 Connecting to WyzeCam Doorbell - Mudroom on 192.168.101.144 [mudroom] 📡 Getting 60kb/s SD stream (H264/20fps) via LAN mode (WiFi: 99%) FW: 4.25.1.314 🔒 (DTLS) (2/3) [mudroom] Re-encoding using h264_v4l2m2m [transpose='clock'] [WyzeBridge] ✅ '/mudroom stream is UP! (3/3) [WyzeBridge] 📖 New client reading from mudroom
However, the resulting image if just wavy green lines...not actual image. Also, the h264_v4l2m2m was used only for my doorbell camera, not my V3's.
Does the video clear up after a while? Hardware encoding can be a little wonky compared to software encoding.
I let it run overnight (it is rotated). It got a bit redder, which I think is the image trying to show up. It still tries to use the HW acceleration only for the doorbell camera. The other cameras are fine. I will just turn off the HW acceleration.
Should /dev/video10, /dev/video11, and /dev/video12 exist by default on a RPi 4 B? I don't see them, I'm also using the lastest version of dietpi, if that matters.
Does this work only for Doorbells?
I get errors and ffmpeg shutdown when I try it. Here are the logs (mudroom is my doorbell camera): [mudroom] Re-encoding using h264_v4l2m2m [transpose='clock'] [mudroom] FFMPEG stopped
Can you add support for OpenCL for Intel Integrated Graphics GPUs (not on a Pi!, but an Intel i5,e.g.)?