0

Long story short, I am building a sensor that uses 2 pi's and each of them have a camera attached to it. I would like 1 pi to record and store the video and the other pi to access that video to process it, so is this possible and how would I go about doing it?

An acceptable alternative would be if I can have the second pi save the video directly onto the first pi so that the first pi can just access its own memory.

edit: The processing will not happen in real time.

Improve this question
2
  • Could you clarify whether you need to process the video in real time, i.e. as it's being recorded? – goobering Jul 27 '16 at 16:30
  • As goobering points out the context of exactly what you mean by "process" is significant here. You can access RAM contents by various methods but there is not much point since there's no way to do it between pi's at a rate anywhere near what the RAM operates at, i.e., it would amount to some conventional data transfer method. – goldilocks♦ Jul 27 '16 at 17:22
2

You could possible create a RAM disk on one Raspberry Pi and share it with NFS. The other Pi could access the disk. See this for how to do it on Ubuntu. I see no reason why it wouldn't work on Raspberry Pi too. If you bring down the size of the disk a little ;)

Improve this answer
1

Assuming your video files are saved on One Pi you can use WiFi or Ethernet to send the file over the other Pi via scp

For instance on Pi-1 if your file is saved as video.mp4 you can retreive the file to Pi-2 using the following:

scp video.mp4 pi@IP_Address_of_Pi-2:/specific/folder/on/Pi-2

The caveat is you might need to setup the Pis with some network settings. This would hardly take any time given the fact that lot of users use Pi over the Internet. You can set both your Pis in headless mode in order to access data without having to keep typing the Passwords again and again.

Links

Official Raspberry-Pi Documentation on Secure Copy(scp)

SSH Access to Pi via a connected Network

How to setup Headless-Pi in order to avoid typing passwords everytime

Improve this answer
3
  • Although I've never noticed it (perhaps because I almost never use it and prefer sshfs), people have made a convincing case that scp is significantly slower than sftp/sshfs. I don't think any of the above will keep up with the camera if it reaches 8-12 MB/s, at which point you might want to just stream it unencrypted. – goldilocks♦ Jul 27 '16 at 17:18
  • @goldilocks You are absolutely right. This is inherent to any TCP based protocols because of 3 way handshake. I am working with Fountain Coding Schemes which is Forward Error Correction method which significantly fast! but this is of course self made, no ready made application. – Shan-Desai Jul 27 '16 at 17:22
  • 1
    "This is inherent to any TCP based protocols because of 3 way handshake." -> is a misconception. First, the handshake is only performed when first establishing a connection; after that you can transfer gigabytes without having to repeat it. TCP has a bit (as in, <1%) of overhead vs. UDP, and the handicap of implementing congestion control, which UDP ignores (but this is really only significant over the internet, and ultimately UDP can't circumvent the consequences of congestion), and guaranteed delivery (which again won't matter much on a small LAN). – goldilocks♦ Jul 27 '16 at 17:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.