如何分析网络摄像头的实时数据？
我将为我的大学网络课程自主选择项目，我只是有几个问题可以帮助我朝着正确的方向开始。
我的项目将涉及创建一个新的“物理”链接，通过该链接，数据以文本形式从一台计算机传输到另一台计算机。该链接将涉及一台带有网络摄像头的计算机，该计算机将一系列闪烁的颜色（黑/白）读取为二进制并将其转换为文本。每一系列的闪烁都会模拟一个数据包。我将在 Macbook 中使用 OSX 和集成网络摄像头，闪烁的计算机将是 Windows 或 OSX。
所以我的问题是：哪种编程语言或 API 最适合读取实时网络摄像头数据、分析特定区域的颜色以及对闪烁进行编程和计时？另外，我是否需要担心“写入”计算机的闪存速率和“读取”计算机的帧捕获速率的匹配？
感谢您能够提供的任何帮助。
I am going to be working on self-chosen project for my college networking class and I just had a couple questions to help get me started in the right direction.
My project will involve creating a new "physical" link over which data, in the form of text, will be transmitted from one computer to another. This link will involve one computer with a webcam that reads a series of flashing colors (black/white) as binary and converts it to text. Each series of flashes will simulate a packet of data. I will be using OSX an the integrated webcam in a Macbook, the flashing computer will either be windows or osx.
So my questions are: which programming languages or API's would be best for reading live webcam data and analyzing the color of a certain area as well as programming and timing the flashes? Also, would I need to worry about matching the flash rate of the "writing" computer and the frame capture rate of the "reading" computer?
Thank you for any help you might be able to provide.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
关于帧捕获率，香农采样定理说“完美重建当采样频率大于被采样信号的最大频率的两倍时，信号是可能的”。换句话说，如果您的闪光灯每秒切换 10 次，则您需要每秒 20 帧以上的相机才能正确捕捉到这一情况。所以基本上检查你的相机规格，除以 2，稍微降低结果，你就得到了最大闪烁率。
任何能得到框架的东西都可以。如果相机工作的光照条件是稳定的，并且图像上的光位置是静态的，那么检查某个区域的平均像素值将非常容易。
如果您需要额外的图像处理，您可能还应该了解 OpenCV（它与每种编程语言都有绑定）。
Regarding the frame capture rate, Shannon sampling theorem says that "perfect reconstruction of a signal is possible when the sampling frequency is greater than twice the maximum frequency of the signal being sampled". In other words if your flashing light switches 10 times per second, you need a camera of more than 20fps to properly capture that. So basically check your camera specs, divide by 2, lower the resulting a little and you have your maximum flashing rate.
Whatever can get the frames will work. If the light conditions in which the camera works are gonna be stable, and the position of the light on images is gonna be static then it is gonna be very very easy with checking the average pixel values of a certain area.
If you need additional image processing you should probably also find out about OpenCV (it has bindings to every programming language).
为了回答你关于语言选择的问题，我推荐java。 Java 媒体框架非常棒并且易于使用。我过去曾用它从网络摄像头捕获视频。但请注意，您询问的每个人都会推荐不同的语言 - 每个人都有自己的偏好！
你用什么作为闪光设备？您想要达到什么样的距离？值得思考的是，如何让接收器识别捕获图像中的位置来寻找闪光。可能需要某种基准标记。更长的射程将使这个问题更难解决。
如果您正在考虑更短的范围，您是否考虑过使用二维发射器？ （假设您使用的是二维接收器，这是有道理的）并且可能有一个发射器可以在监视器上显示一系列 QR 码（或类似的编码）？
您将不得不考虑某种纠错编码，例如汉明码。虽然编码会增加数据占用空间，但它可能会为您提供更好的整体带宽，因为您可以将速度提高得更高，而不必担心奇怪的损坏位。
一些“评估”类型的材料可能包括您讨论使用此类通道的明显安全风险 - 任何在发射器视线范围内的人都可以窃听！您可以建议在您的文章中使用某种加密，CBC 中的分组密码就可以，但需要在传输之前进行密钥交换，因此您可以考虑公钥加密。
To answer your question about language choice, I would recommend java. The Java Media Framework is great and easy to use. I have used it for capturing video from webcams in the past. Be warned, however, that everyone you ask will recommend a different language - everyone has their preferences!
What are you using as the flashing device? What kind of distance are you trying to achieve? Something worth thinking about is how are you going to get the receiver to recognise where within the captured image to look for the flashes. Some kind of fiducial marker might be necessary. Longer ranges will make this problem harder to resolve.
If you're thinking about shorter ranges, have you considered using a two-dimensional transmitter? (given that you're using a two-dimensional receiver, it makes sense) and maybe have a transmitter that shows a sequence of QR codes (or similar encodings) on a monitor?
You will have to consider some kind of error-correction encoding, such as a hamming code. While encoding would increase the data footprint, it might give you overall better bandwidth given that you can crank up the speed much higher without having to worry about the odd corrupt bit.
Some 'evaluation' type material might include you discussing the obvious security risks in using such a channel - anyone with line of sight to the transmitter can eavesdrop! You could suggest in your writeup using some kind of encryption, a block cipher in CBC would do, but would require a key-exchange prior to transmission, so you could think about public key encryption.