我正在尝试使用我这里已有的 RPI 和相机模块制作一个完美的移动网络摄像头，以满足我的需求。我在 RPI 和我打算作为“客户端”的笔记本电脑上运行 Arch。我让摄像头正在运行，并且可以从raspivid某个地方通过管道传输其数据，并且我能够来回进行 ssh。
现在我正在尝试通过本地网络进行传输。理想情况下，我会在 RPI 上启动“服务器”脚本，并且能够根据需要连接任意数量的客户端，直到我决定再次关闭服务器。而且，理想情况下，拥有单独的设备和无线传输的延迟几乎是不可察觉的，因此我不必补偿并尝试同步视频和音频。所以根据我的了解，使用 VLC 是不可能的。另外，理想情况下，“客户端”将使流可用/dev/video1或以其他方式提供 - 尽管目前我只想将其放入 OBS不知何故。
到目前为止，我尝试遵循一些教程，特别是涉及netcat，但该过程立即停止或一旦发生断开连接，因为我无法在客户端上播放流。
关于去哪里寻找或如何计划的任何提示？我考虑过使用类似媒体服务器之类的东西来实现动态客户端（断开）连接，但它需要超轻量级。
答案1
如果您想流式传输视频，请使用专为视频流式传输而设计的协议。这意味着 UDP 和多播，因此您可以连接任意数量的客户端。因为对于 TCP 和单播，正如您发现的那样，一旦断开连接，它就会停止。
存在这样的协议，例如实时传输协议，并且存在服务器实现，例如冰播。它不是“超轻量级”，但应该可以在 RaspPi 上正常工作。
不，您不想让流以/dev/video1.相反，您应该使用能够正确连接到多播组的客户端，然后从网络读取流。
我不太确定您对 VLC 的了解以及为什么它是不可能的，但是 VLC（以及大多数其他视频播放器）作为 RTSP 流的客户端应该可以正常工作，并且同步视频和音频应该不会有问题如果同步流式传输（其中可以是否会出现问题取决于硬件如何连接到 RaspPi，但您一开始并没有提及您的音频源）。
编辑
如果你坚持极简主义，你也可以ffmpeg用溪流有多种方式，但您需要花一些时间来了解所涉及的协议、它们的差异以及它们所需的命令行选项。
编辑
好吧，我看了视频（至少一开始有VLC和延迟，我不是特别喜欢看视频）。
当然如果您使用任何像样的编码方法，都会有很大的延迟 - 需要相当多的帧才能有效编码（然后需要相同数量的帧才能解码）。最重要的是，它会缓冲很多以确保不会丢失任何东西。
只是为了好玩，我ffmpeg在多播组上尝试使用 RTP，并且也遇到了很多延迟（使用 H264 时大约为 1-2 秒，加上额外的延迟ffplay）。减少延迟本身就是一门科学，需要大量摆弄选项（并阅读相关内容）。但出现延迟并不表示出现问题，相反。
因此，如果您有绝对的低延迟要求，则需要权衡压缩、图像大小、编码质量和带宽。如果没有其他帮助，请删除编码步骤。