WebRTC：通道、轨道和流与 RTP s-s-rC 和 RTP 会话之间的关系

Posted 2023-02-19

【中文标题】WebRTC：通道、轨道和流与 RTP s-s-rC 和 RTP 会话之间的关系

【英文标题】：WebRTC: Relationship between Channels, Tracks & Streams vis-a-vis RTP s-s-rC and RTP Sessions

【发布时间】：2019-05-09 11:08:55

【问题描述】：

来自 Mozilla 网站：https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API

“一个 MediaStream 由零个或多个 MediaStreamTrack 对象组成，代表各种音频或视频轨道。每个 MediaStreamTrack 可能有一个或多个通道。通道代表媒体流的最小单元，例如与给定关联的音频信号扬声器，例如立体声音轨中的左声道或右声道。”

这阐明了频道是什么。

最近的几个 RFC（例如 8108）提到需要在一个 RTP 会话中发送多个流。每个流在 RTP 级别都有自己的 s-s-rC。 在统一计划的 RFC 中，也始终引用作为最低级别的流（不是轨道或通道）。在基本 RTP RFC RFC 3550 中，没有对通道的引用。

这些 RFC 中提到的 RTP 流是否建议将流作为媒体的最低来源，是否与 WebRTC 中使用的频道相同，并且如上所述？ 轨道通道 (WebRTC) 和带有 s-s-rC 的 RTP 流之间是否存在一对一映射？

例如，一个网络摄像头生成一个媒体流，它可以有一个音频媒体轨道和一个视频媒体轨道，每个轨道使用单独的 s-s-rC 在 RTP 数据包中传输，从而产生两个 s-s-rC。那是对的吗？现在，如果有一个立体声网络摄像头（或者一些这样的设备，比如说两个麦克风 - 通道？）。这会生成三个具有三个不同唯一 s-s-rC 的 RTP 流吗？

在成功测试 ICE 候选人后，是否有用于建立五元组连接的单个 RTP 会话？还是可以在对等点之间的同一组 port-ip-UDP 连接上存在多个 RTP 会话？

任何澄清这一点的文件将不胜感激。

【参考方案1】：

这阐明了频道是什么。

不完全是。只有 audio 曲目有频道。除非您将web audio 到split up 和音频MediaStreamTrack 用于各个通道，否则轨道是对等连接的最低级别。 *

这是因为多个音频通道（就像视频的多个帧一样）是由编解码器进行编码和解码的有效负载的一部分。实际上，您可以在接收器的 MedaiStreamTrack 上使用网络音频拆分器来拆分音频通道，前提是它们幸存下来。

*) 还有data channels，但它们是不同的，与媒体流和轨道无关。

RTP 流...是否与 WebRTC 中使用的频道相同，并且如上所述？

没有。粗略地说，你可以说：

RTP 流 == MediaStreamTrack。

但这并不是故事的全部，因为sender.replaceTrack(withTrack)。简而言之，您可以随时在实时通话期间将正在发送的曲目替换为不同的曲目，而无需重新协商您的连接。重要的是，在这种情况下，对方的receiver.track 不会改变，只有它的输出会改变。这将管道与通过它的内容分开。

所以在发送方，更公平的说法是：

RTP 流 == 当前输出一个发送者（来自pc.getSenders()）

...而在接收端，它更简单，而且总是这样说：

RTP 流 == receiver.track

有道理吗？

MediaStream 呢？

在modern WebRTC 中，MediaStreams 是哑容器——您可以使用stream.addTrack(track) 和stream.removeTrack(track) 随意添加或删除其中的曲目——此外，RTCPeerConnection 仅处理 曲目。例如：

for (const track of stream.getTracks()) 
  pc.addTrack(track, stream);

channels of track 和带有 s-s-rC 的 RTP 流之间是否存在一对一的映射关系？

在MediaStreamTrack 和 s-s-rC 之间，是的。

一个网络摄像头，[...] 可以有一个音频媒体轨道和一个视频媒体轨道，每个轨道使用单独的 s-s-rC 在 RTP 数据包中传输，从而产生两个 s-s-rC。对吗？

在这种情况下是的，因为音频永远不能捆绑与视频，反之亦然。

如果有立体声网络摄像头会怎样

没有区别。立体声音频轨道仍然是单个音频轨道（和单个 RTP 流）。

或者在对等点之间的同一组 port-ip-UDP 连接上是否可以有多个 RTP 会话？

不是同时。但是多个轨道可以共享同一个会话，除非您使用非默认：

new RTCPeerConnection(bundlePolicy: 'max-compat');

如果您不这样做，或者使用any other mode，则可能会将同类曲目捆绑到单个 RTP 会话中。

【讨论】：

所以一个“音频”通道（例如来自放置在不同位置的麦克风的输入）只是另一个 mediaStreamTrack = rtp 流。由于可以在 RTP 会话中同步多个 RTP 流，这有意义吗？关于你的陈述：“如果你不这样做，或者使用任何其他模式，那么同类曲目可能会捆绑在同一个 s-s-rC 上。”我认为捆绑流会为每个 RTP 流产生不同的 s-s-rC（m = SDP 中的条目）。这些流只共享相同的 ICE 候选和相同的 RTP 会话？ RFC

@RTC 不，立体声音频轨道仍然只是一个轨道，即一个 RTP 流。

可能是我对立体声音轨的理解或定义错误。据我了解，立体声音轨由多个音频源（例如左右麦克风）组成。如果它们是一个 RTP 流的一部分，因此共享相同的 s-s-rC，如何在接收端拆分它们（例如，在左扬声器和右扬声器上播放）？如果通过立体声音轨你的意思是来自一个麦克风的特定流，那么我明白了。要了解不同的 RFC，我需要弄清楚这些基础知识。再次感谢...

@RTC 在接收端分割视频帧的方式相同。此信息是由编解码器编码和解码的有效负载的一部分。实际上，您可以在接收者的MedaiStreamTrack 到split up the audio-channels 上使用网络音频splitter，前提是他们幸存下来。

我想我现在明白了。因此，channelSplitter API（可能与其他 API 结合使用）是一种能够将一个多通道 mediaStreamTrack 拆分为多个 mediaStreamTrack 的 API，每个通道一个。必须阅读有关采样、立体声采样甚至立体声麦克风的知识！认为立体声输入总是需要多个设备，每个通道一个。难怪，所有 RFC 都将设备称为 RTP 流的唯一 s-s-rC 的来源，而从未提及通道。感谢您的详细回复。