gRPC 可以用于互联网上的音频视频流吗？

Question

据我所知，在客户端-服务器模型中，gRPC 可以进行双向数据流。我还没有尝试过，但想知道是否可以使用 gRPC 将音频和视频数据从源流式传输到云服务器，然后实时广播到多个客户端？

Answer 1

TLDR：我不推荐通过 gRPC 播放视频。主要是因为它不是为此而设计的，所以这样做需要大量的黑客工作。您可能应该看看 WebRTC +特定的视频编解码器。

\n

更多信息如下：

\n

gRPC 没有视频压缩

\n

\n
• 发送视频时，我们希望高效地发送内容，因为发送原始视频可能需要 1GB/s 的连接。
\n
• 所以我们使用视频压缩/视频编码。例如，H.264、VP8 或 AV1。
\n
• 了解视频压缩的工作原理（例如，通过最小化视频中帧之间共享的相似数据来节省带宽）
\n
• protobufs（gRPC 使用的格式）没有视频编码器。
\n
• 然后，您可以尝试图像压缩并将图像保存在字节字段中（例如bytes image_frame = 1;，但这效率较低，并且肯定会占用不必要的视频空间。
\n

\n

可能可以使用视频编码器（例如 H.264）将帧编码到 protobuf 中，然后解码它们以在应用程序中播放。然而，这可能需要大量的黑客/工程工作。此用例不是 gRPC/protobufs 的设计目的，也不常见。如果你一起破解一些东西，请告诉我，我会很好奇。

\n

gRPC 可靠

\n

\n
• gRPC 使用 TCP（而不是 UDP），这是可靠的。
\n
• 乍一看，可靠性可能很方便，可以避免数据损坏或丢失。但是，根据使用情况（实时视频或音频通话），如果帧丢失或延迟，我们可能更愿意跳过帧。对于用户来说，这些损失可能是不明显的或无痛的。\n
  \n
  • 如果数据包延迟，它将等待该数据包然后再播放其余部分。（又名：生命头阻塞/数据包排序延迟）
  \n
  • 如果数据包丢失（又称数据包丢失），它将重新发送
  \n
  \n
\n
• 因此，视频会议应用通常使用WebRTC/RTP（配置为不可靠）
\n
• 话虽如此，Zoom 似乎能够实现 Video-over-WebSockets，这也是一种可靠的传输（通过 TCP）。所以这并不是“游戏结束”，只是强烈不推荐并且需要付出更多的努力。不过他们已经转向 WebRTC。
\n

\n

\n

WebSocket 上接收到的数据进入基于 WebAssembly (WASM) 的解码器。音频被馈送到支持该功能的浏览器中的 AudioWorklet。从那里，使用 WebAudio \xe2\x80\x9cmagic\xe2\x80\x9d 目标节点播放解码的音频。

\n

\n