search

brutella / hkcam

Open-Source HomeKit Surveillance Camera
https://hochgatterer.me/hkcam/
Apache License 2.0
922 stars 141 forks source link

A few questions about prorting your software if you have time. #63

Closed kenthinson closed 2 years ago

kenthinson commented 4 years ago

Hello. I am interested in porting your software to the wyze cam (running the Dafang-Hacks custom linux firmware) as it's a very capable little camera for less money then the raspberry pi + camera. I have a few questions about your software if you have the time.

  1. What is the reason for ffmpeg? Is the camera not providing h264 data off of /dev/video? It looks like you are using ffmpeg to make a rtp stream. But I want to make sure that's the only reason?

  2. Related to 1. The wyze cam already has v4l2rtspserver running. I'm assuming that I can use that somehow as rtsp creates a rtp transport already. Not 100% sure on this. However any feedback about this idea you might have would be great.

  3. Did you write and debug your code directly on the pi or did you do cross compile? If cross compile can you give me any insight into your testing procedures. Eg did you just scp the files over after compile? ect.

  4. Any other advice you might have about this project. Thanks!

mgoeller commented 4 years ago

I would also be interested to know if the Raspberry Pi has actually to convert something (e.g. uses a lot of cpu load) if the camera already provides multicast rtsp streams by itself? Especially regarding that HomeKit requests a secure rtp stream. If one just defines the rtsp stream from the camera as source, and provides the same resolution to whatever the iOS device requests (that works, I tested already), does it still need conversion?

kenthinson commented 4 years ago

@mgoeller the camera will not provide rtp for sure. rtp is a network protocol. What the camera might be providing is h264. Then ffmpeg would be able to use the copy flag to not re-encode the stream and wrap it in the rtp transport. However it's also possible the data from /dev/video is something else like raw bits. I haven't explored into it yet.

EDIT: According to the spec sheet https://www.raspberrypi.org/documentation/hardware/camera/ the camera should be able to provide raw or accelerated h264. If hkcam isn't using the copy flag then that should be looked into. I see another issue open for 100% cpu usage https://github.com/brutella/hkcam/issues/54. The copy flag could help.

mgoeller commented 4 years ago

Yes, the copy flag would definitely help but then forwarding the full resolution stream to the iOS / watchOS client instead of the requested resolution / bitrate...

hazcod commented 3 years ago

Wouldn't it actually forward the full stream to the Hub instead of the client?

brutella commented 2 years ago
  1. What is the reason for ffmpeg? Is the camera not providing h264 data off of /dev/video? It looks like you are using ffmpeg to make a rtp stream. But I want to make sure that's the only reason?

The reason why this project uses ffmpeg is that ffmpeg makes it easy to create an rtp stream from a connected camera on different platforms. It works on macOS and Linux.

I would prefer to access the camera stream directly and create an rtp stream. But ffmpeg works good enough for now.

  1. Did you write and debug your code directly on the pi or did you do cross compile? If cross compile can you give me any insight into your testing procedures. Eg did you just scp the files over after compile? ect.

I mostly do testing on macOS (streaming also works with the built-in iSight camera). Then I cross compile for a Raspberry Pi and run it there. In the version 0.1.0, I've switched from Make to Task to build for different platforms. I run task pack to create packages for the different platforms and cpu architectures.