我正在尝试构建一款移动应用程序，可以从两个方向流式传输视频（即类似于视频通话）。
我研究了webrtc，但是它还没有为移动本地应用程序做好准备，而且无论如何，webrtc都可以直接捕获相机和音频，而不需要插件等。但在本机移动应用程序中，捕获相机和音频并不是问题，基本上需要一个非常低的延迟和双重传输层。在许多文章和地方中，我阅读到使用websockets上的webrtc。
所以我想我可以使用websockets来流式传输视频。这是正确的吗？还是我错过了什么？
我明白还有一个区别，就是webrtc是直接客户端对客户端……而websocket将是客户端-服务器-客户端，有没有任何避免它的方法。这意味着延迟会怎样。
在移动端，webRTC 的表现非常出色。webrtc.org 的参考代码（appRTCDEMO）中有iOS和android的示例/白名单客户端，以及多个应用程序。最近宣布的是 appear.in。
从流中获取视频和音频流是媒体API的一部分，而不是webRTC API本身（getusermedia）。
webRTC实际上是方程式的点对点连接（RTCPeerConnection：传输和防火墙穿越）和媒体引擎（编码、打包、加密），正是您所寻找的。
webSockets只是一种传输机制。它不处理防火墙/NAT穿越、媒体处理和数据包/分块，这些都需要在应用级别实现。
就“信令”而言，webRTC没有指定/强制任何协议，看起来通常的做法是设置一个信令服务器。应用程序通常使用web socket或XHR连接到该服务器，或者使用其他方法进行初始握手/呼叫设置。许多应用程序通过使用像socket.io这样的库来抽象化此过程。
注意：此解决方案可用于移动浏览器，但我不知道在Android / IOS环境中是否存在所有所需的软件（即使使用类似React Native的东西）。
但是，这个解决方案可以运行。事实上，我已经在树莓派上完成了这个。
我基本上只需从USB相机直播一个FFMPEG管道，将其导入UDP源，有一个“中继”服务，它基本上将UDP数据包转换并使用来自JavaScript的engine.io将其传输到客户端，然后在Web端使用这个非常棒的mpeg1编码器将web socket数据包解码成mpeg1视频。
因此，我大致执行以下ffmpeg流程：https://github.com/freefarmdata/auto_farm_recorder/blob/master/recorder/src/controllers/streams.py#L13
然后读取UDP流并将其中继到Node应用程序中，如： https://github.com/freefarmdata/auto_farm_recorder/blob/master/relay/src/socket.js#L97
然后我使用类似以下的方式解码流： https://github.com/freefarmdata/auto_farm_recorder/blob/master/web/src/app/widgets/LiveStream.js 请记住，这是使用TCP而不是UDP进行数据传输。这意味着为了保持流畅运行，我必须确保我的客户端具有足够的带宽以进行实时流媒体。如果他们没有，我不能使用RTP或其他东西来对我的流进行QOS以降低质量级别。我基本上只能丢弃数据包，这反过来会丢弃帧并导致mpeg1解码器中出现奇怪的损坏问题。