对等连接级框架夹具体系结构

PeerConnection level framework fixture architecture

对等连接级框架夹具体系结构

Overview

概述

The main implementation of webrtc::webrtc_pc_e2e::PeerConnectionE2EQualityTestFixture is webrtc::webrtc_pc_e2e::PeerConnectionE2EQualityTest. Internally it owns the next main pieces:

​webrtc::webrtc_pc_e2e::PeerConnectionE2EQualityTestFixture的主要实现是webrtc::webrtc_pc_e2e::PeerConnectionE2EQualityTest。在内部，它拥有以下主要部分：

• MediaHelper - responsible for adding audio and video tracks to the peers.
• MediaHelper-负责向对等设备添加音频和视频曲目。
• VideoQualityAnalyzerInjectionHelper and SingleProcessEncodedImageDataInjector - used to inject video quality analysis and properly match captured and rendered video frames. You can read more about it in DefaultVideoQualityAnalyzer section.
• VideoQualityAnalyzerInjectionHelper和SingleProcessEncodedImageDataInjector-用于注入视频质量分析，并正确匹配捕获和渲染的视频帧。可以在DefaultVideoQualityAnalyzer部分阅读更多关于它的信息。
• AudioQualityAnalyzerInterface - used to measure audio quality metrics
• AudioQualityAnalyzerInterface-用于测量音频质量指标
• TestActivitiesExecutor - used to support ExecuteAt(...) and ExecuteEvery(...) API of PeerConnectionE2EQualityTestFixture to run any arbitrary action during test execution timely synchronized with a test call.
• TestActivitiesExecutor-用于支持PeerConnectionE2EQualityTestFixture的ExecuteAt（…）和ExecuteEvery（…）API，以便在测试执行期间运行任何与测试调用及时同步的任意操作。
• A vector of QualityMetricsReporter added by the PeerConnectionE2EQualityTestFixture user.
• ​PeerConnectionE2EQualityTestFixture用户添加的QualityMetricsReporter向量。
• Two peers: Alice and Bob represented by instances of TestPeer object.
• ​两个对等端：Alice和Bob，由TestPeer对象的实例表示。

Also it keeps a reference to webrtc::TimeController, which is used to create all required threads, task queues, task queue factories and time related objects.

​此外，它还保留了对webrtc::TimeController的引用，用于创建所有必需的线程、任务队列、任务队列工厂和与时间相关的对象。

TestPeer

测试对等端

Call participants are represented by instances of TestPeer object. TestPeerFactory is used to create them. TestPeer owns all instances related to the webrtc::PeerConnection, including required listeners and callbacks. Also it provides an API to do offer/answer exchange and ICE candidate exchange. For this purposes internally it uses an instance of webrtc::PeerConnectionWrapper.

​调用参与者由TestPeer对象的实例表示。TestPeerFactory用于创建它们。TestPeer拥有与webrtc::PeerConnection相关的所有实例，包括所需的侦听器和回调。此外，它还提供了一个API来进行offer/answer交换和ICE候选人交换。为此，它在内部使用了一个webrtc::PeerConnectionWrapper实例。

The TestPeer also owns the PeerConnection worker thread. The signaling thread for all PeerConnection's is owned by PeerConnectionE2EQualityTestFixture and shared between all participants in the call. The network thread is owned by the network layer (it maybe either emulated network provided by Network Emulation Framework or network thread and rtc::NetworkManager provided by user) and provided when peer is added to the fixture via AddPeer(...) API.

​TestPeer还拥有PeerConnection工作线程。所有对等连接的信令线程由对等连接E2EQualityTestFixture所有，并在呼叫的所有参与者之间共享。网络线程由网络层拥有（它可能是由网络仿真框架提供的仿真网络，也可能是由用户提供的网络线程和rtc::NetworkManager），并在通过AddPeer（…）API将对等添加到设备时提供。

GetStats API based metrics reporters

GetStats基于API的度量报告器

PeerConnectionE2EQualityTestFixture gives the user ability to provide different QualityMetricsReporters which will listen for PeerConnection GetStats API. Then such reporters will be able to report various metrics that user wants to measure.

​PeerConnectionE2EQualityTestFixture让用户能够提供不同的QualityMetricsReporters，这些Reporters将监听PeerConnection GetStats API。然后，这样的报告器将能够报告用户想要测量的各种度量。

PeerConnectionE2EQualityTestFixture itself also uses this mechanism to measure:

PeerConnectionE2EQualityTestFixture本身也使用此机制来测量：

• Audio quality metrics
• 音频质量指标
• Audio/Video sync metrics (with help of CrossMediaMetricsReporter)
• ​音频/视频同步指标（借助CrossMediaMetricsReporter）

Also framework provides a StatsBasedNetworkQualityMetricsReporter to measure network related WebRTC metrics and print debug raw emulated network statistic. This reporter should be added by user via AddQualityMetricsReporter(...) API if requried.

​该框架还提供了一个StatsBasedNetworkQualityMetricsReporter来测量网络相关的WebRTC指标，并打印调试原始模拟网络统计数据。如果需要，用户应通过AddQualityMetricsReporter（…）API添加此报告程序。

Internally stats gathering is done by StatsPoller. Stats are requested once per second for each PeerConnection and then resulted object is provided into each stats listener.

​内部统计数据收集由StatsPoller完成。每秒为每个PeerConnection请求一次统计信息，然后将生成的对象提供给每个统计信息侦听器。

Offer/Answer exchange

Offer/Answer交换

PeerConnectionE2EQualityTest provides ability to test Simulcast and SVC for video. These features aren't supported by P2P call and in general requires a Selective Forwarding Unit (SFU). So special logic is applied to mimic SFU behavior in P2P call. This logic is located inside SignalingInterceptor, QualityAnalyzingVideoEncoder and QualityAnalyzingVideoDecoder and consist of SDP modification during offer/answer exchange and special handling of video frames from unrelated Simulcast/SVC streams during decoding.

​对等连接E2EQualityTest提供了对视频进行Simulcast和SVC测试的能力。P2P呼叫不支持这些功能，并且通常需要选择性转发单元（SFU）。因此，在P2P呼叫中应用了特殊的逻辑来模拟SFU的行为。该逻辑位于SignalingInterceptor、QualityAnalyzingVideoEncoder和QualityAnalyyingVideoDecoder内部，包括在报价/应答交换期间修改SDP，以及在解码期间对来自不相关的Simulcast/SVC流的视频帧进行特殊处理。

Simulcast

联播

In case of Simulcast we have a video track, which internally contains multiple video streams, for example low resolution, medium resolution and high resolution. WebRTC client doesn't support receiving an offer with multiple streams in it, because usually SFU will keep only single stream for the client. To bypass it framework will modify offer by converting a single track with three video streams into three independent video tracks. Then sender will think that it send simulcast, but receiver will think that it receives 3 independent tracks.

在Simulcast的情况下，我们有一个视频轨道，它内部包含多个视频流，例如低分辨率、中等分辨率和高分辨率。WebRTC客户端不支持接收包含多个流的offer，因为通常SFU只为客户端保留单个流。为了绕过它，框架将通过将具有三个视频流的单个音轨转换为三个独立的视频音轨来修改offer。然后发送器会认为它发送了联播，但接收器会认为它接收了3个独立的音轨。

To achieve such behavior some extra tweaks are required:

为了实现这种行为，需要进行一些额外的调整：

• MID RTP header extension from original offer have to be removed
• 必须删除原始offer中的MID RTP头扩展
• RID RTP header extension from original offer is replaced with MID RTP header extension, so the ID that sender uses for RID on receiver will be parsed as MID.
• 原始offer的RID RTP头扩展被MID RTP头延伸所取代，因此发送方在接收方上用于RID的ID将被解析为MID。
• Answer have to be modified in the opposite way.
• Answer必须以相反的方式修改。

Described modifications are illustrated on the picture below.

所描述的修改如下图所示。

The exchange will look like this:

交换将如下所示：

1.Alice creates an offer

1.Alice创建一个offer

2.Alice sets offer as local description

2.Alice将offer设置为本地描述

3.Do described offer modification

3.offer描述修改

4.Alice sends modified offer to Bob

4.Alice向Bob发送修改后的offer

5.Bob sets modified offer as remote description

5.Bob将修改后的offer设置为远程描述

6.Bob creates answer

6.Bob创建一个answer

7.Bob sets answer as local description

7.Bob将answer设置为本地描述

8.Do reverse modifications on answer

8.对answer进行反向修改

9.Bob sends modified answer to Alice

9.Bob将修改后的answer发送给Alice

10.Alice sets modified answer as remote description

10.Alice将修改后的answer设置为远程描述

Such mechanism put a constraint that RTX streams are not supported, because they don't have RID RTP header extension in their packets.

这种机制限制了RTX流不受支持，因为它们的数据包中没有RID-RTP报头扩展。

SVC

In case of SVC the framework will update the sender's offer before even setting it as local description on the sender side. Then no changes to answer will be required.

在SVC的情况下，框架将更新发送方的offer，甚至在发送方将其设置为本地描述之前。那么就不需要对答案进行任何更改。

ssrc is a 32 bit random value that is generated in RTP to denote a specific source used to send media in an RTP connection. In original offer video track section will look like this:

ssrc是在RTP中生成的32位随机值，用于表示用于在RTP连接中发送媒体的特定源。在原始offer中，视频轨道部分将如下所示：

m=video 9 UDP/TLS/RTP/SAVPF 98 100 99 101
...
a=ssrc-group:FID <primary ssrc> <retransmission ssrc>
a=ssrc:<primary ssrc> cname:...
....
a=ssrc:<retransmission ssrc> cname:...
....

To enable SVC for such video track framework will add extra ssrcs for each SVC stream that is required like this:

为了为这样的视频轨道框架启用SVC，将为每个SVC流添加额外的ssrcs，如下所需：

a=ssrc-group:FID <Low resolution primary ssrc> <Low resolution retransmission ssrc>
a=ssrc:<Low resolution primary ssrc> cname:...
....
a=ssrc:<Low resolution retransmission ssrc> cname:....
...
a=ssrc-group:FID <Medium resolution primary ssrc> <Medium resolution retransmission ssrc>
a=ssrc:<Medium resolution primary ssrc> cname:...
....
a=ssrc:<Medium resolution retransmission ssrc> cname:....
...
a=ssrc-group:FID <High resolution primary ssrc> <High resolution retransmission ssrc>
a=ssrc:<High resolution primary ssrc> cname:...
....
a=ssrc:<High resolution retransmission ssrc> cname:....
...

The next line will also be added to the video track section of the offer:

下一行也将添加到offer的视频轨道部分：

a=ssrc-group:SIM <Low resolution primary ssrc> <Medium resolution primary ssrc> <High resolution primary ssrc>

It will tell PeerConnection that this track should be configured as SVC. It utilize WebRTC Plan B offer structure to achieve SVC behavior, also it modifies offer before setting it as local description which violates WebRTC standard. Also it adds limitations that on lossy networks only top resolution streams can be analyzed, because WebRTC won't try to restore low resolution streams in case of loss, because it still receives higher stream.

将告诉PeerConnection，该轨道应配置为SVC。利用WebRTC Plan B要约结构来实现SVC行为，并且在将要约设置为违反WebRTC标准的本地描述之前对其进行修改。此外，还增加了限制，即在有损网络上，只能分析最高分辨率的流，因为WebRTC不会在丢失的情况下尝试恢复低分辨率的流。因为它仍然接收更高的流。

Handling in encoder/decoder

编码器/解码器中的处理

In the encoder, the framework for each encoded video frame will propagate information requried for the fake SFU to know if it belongs to an interesting simulcast stream/spatial layer of if it should be “discarded”.

在编码器中，每个编码视频帧的框架将传播伪SFU所需的信息，以知道它是否属于一个有趣的联播流/空间层，以及它是否应该被“丢弃”。

On the decoder side frames that should be “discarded” by fake SFU will be auto decoded into single pixel images and only the interesting simulcast stream/spatial layer will go into real decoder and then will be analyzed.

 在解码器端，应该被伪SFU“丢弃”的帧将被自动解码为单像素图像，只有有趣的联播流/空间层将进入真正的解码器，然后进行分析。