WebRTC-Internals工具初探

工具：chrome://webrtc-internals/

工具说明

RTCPeerConnection（通道）

以4个通道为例：第一个通道为 主流发送，第二个通道为 主流接收，第三个通道为 辅流发送，第四个通道为 辅流接收。

每个通道的信息

事件信息（Event）：信令状态、ICE状态、收发器变化、Offer/Answer过程(SDP)信息
统计信息（Stats Tables）：统计数据、统计图表（Stats Graphs For）
核心指标
带宽占用
Bitrate (比特率)
Bitrate 表示单位时间内传输的数据量，通常以每秒的比特数（bps）表示，对于音频和视频流，比特率指的是每秒传输的音频或视频数据量
Available Send Bandwidth (可用发送带宽)
可用发送带宽表示发送数据的网络带宽，当前可供 WebRTC 应用程序使用的网络带宽，影响音频和视频质量
Available Receive Bandwidth (可用接收带宽)

可用接收数据的网络带宽
Total Send Bitrate (总发送比特率)
总发送比特率表示当前从本地端发送到远程端的音频和视频数据的总比特率
Total Receive Bitrate (总接收比特率)
总接收比特率表示当前从远程端接收到本地端的音频和视频数据的总比特率
Estimation of Available Bandwidth (可用带宽估算)
对当前可用的音频和视频带宽的估算，有助于应用程序自适应性，根据可用带宽调整音频和视频质量
BWE (Bandwidth Estimation, 带宽估算)
用于估算可用带宽的算法和机制，有助于 WebRTC 应用程序在动态网络条件下适应不断变化的带宽
Target Video Bitrate (目标视频比特率)
为视频流设置的目标传输比特率，通常用于确定视频质量级别
Actual Encoding Bitrate (实际编码比特率)
实际编码比特率表示当前用于编码视频的比特率，这是编码器实际使用的比特率，可能会根据网络条件和目标视频比特率而变化
Codec Bitrate (编解码器比特率)
编解码器比特率是编解码器使用的比特率，通常根据编码器设置和压缩算法而变化
网络时延
RTT (Round-Trip Time)
RTT（往返时延）表示从发送信号到接收确认信号所需的时间，是衡量网络延迟的指标，能够显示从发送数据到接收数据的总延迟时间，通常以毫秒（ms）为单位
Jitter Buffer Delays (抖动缓冲时延)
表示数据包到达时间的变化，在实时通信中，为了减小抖动，数据包会被缓冲，以便在播放时适应数据包到达时间的变化，抖动缓冲时延反映了这种数据包缓冲的延迟
Packet Delay Variation (PDV, 数据包时延变化)
数据包时延变化衡量了数据包到达时间的方差，高 PDV 可能导致数据包丢失和抖动，会影响实时通信的质量
Audio and Video Frame Delays (音频和视频帧时延)
音频和视频帧到达的延迟时间，音频或视频帧的延迟可能导致实时通信中音频和视频不同步
Render Delay (渲染时延)
渲染时延表示音频和视频帧到达后，在屏幕上渲染或显示所需的时间，较高的渲染时延可能导致同步问题，影响用户体验
Playout Delay (播放时延)
播放时延测量了音频和视频帧在接收后、播放之前的延迟时间，播放时延对于维护同步和实时通信的质量至关重要
图像质量
Frame Width and Height (帧宽度和高度)
帧宽度和高度表示视频帧的分辨率，通常以像素为单位，更高的分辨率通常对图像质量有积极影响，但也需要更多的带宽和计算资源
Frames Per Second (FPS, 每秒帧数)
FPS 衡量每秒显示的视频帧数，较高的 FPS 通常会提供更流畅的视频，但也可能需要更多的计算资源
Video Bitrate (视频比特率)
视频比特率表示视频流传输的数据速率，通常以比特每秒（bps）为单位，较高的视频比特率通常对图像质量有积极影响，但也需要更多的带宽
Frames Dropped (丢帧数)
丢帧数表示由于网络或计算资源限制而被丢弃的视频帧数量，较少的丢帧通常对图像质量有积极影响
Frames Decoded (解码帧数)
解码帧数表示已成功解码并准备好显示的视频帧数量，较多的解码帧数通常意味着更好的图像质量
Frames Received (接收帧数)
接收帧数表示已从对方端接收到的视频帧数量，较多的接收帧数通常有助于提供更好的图像质量
Video Freeze (视频冻结)
冻结现象即图像不再更新，视频冻结会降低图像质量和用户体验
Key Frames (关键帧)
关键帧是视频编码中的重要帧，可用于还原视频流，它们对于维护图像质量和恢复丢失的帧至关重要
基础概念
ICE（Interactive Connectivity Establishment）
用于建立对等连接的协议，允许WebRTC应用程序在不同网络环境中找到合适的通信路径，帮助解决NAT（网络地址转换）和防火墙等网络障碍，确保数据可以在对等方之间安全传输
流
流代表WebRTC中的媒体流，通常包括音频和视频，每个流可以是音频流、视频流或两者的组合。流可以通过WebRTC进行捕捉、传输和渲染，用于实时通信
帧（Frame）
帧是视频流中的基本单位，代表视频的一帧静止图像，视频通常由一系列连续的帧组成，以创建流畅的视频，帧也可以是关键帧，用于恢复丢失的视频数据

编解码
编码是将原始音频和视频数据转换为数字格式的过程，以减小文件大小和带宽占用，解码是将数字数据重新转换为可播放或显示的原始数据的过程，WebRTC使用编码器和解码器来处理音频和视频数据，以在网络上传输和接收数据
渲染（Rendering）
渲染是指将音频和视频帧显示在用户界面上的过，在WebRTC中，音频和视频数据必须通过渲染引擎显示在浏览器或应用程序的界面上，以供用户查看和听取
metrics（指标）
指标是用于监测WebRTC连接和通信质量的度量标准，包括往返时延、丢包率、带宽使用、音频和视频质量等，开发人员可以使用指标来监测和优化实时通信的性能

其他方式：

除了 网络抓包后分析媒体流 的方法外，可以选择 度量metrics

Q&A：

1、关键帧起什么作用？

Key-Frame也称为I帧，作用包含几个方面：（1）恢复点：I帧是视频序列中的恢复点，即使在传输中丢失了某些帧，接收端仍然可以使用I帧来恢复视频序列，如果没有I帧，视频丢失帧可能会导致质量下降或者花屏。（2）帧间压缩：I帧通常包含完整的图像信息，不依赖于前一帧，有助于降低压缩帧之间的依赖性，使视频编码更加鲁棒。（3）切换场景：切换场景时通常会插入一个I帧，以确保接收端正确解释新场景的内容。（4）图像质量控制：I帧间隔可以调整，以影响视频的质量和网络带宽的使用，较少的I帧会减小带宽要求，但在帧丢失时恢复效果较差。

2、渲染过程包含哪些步骤？

渲染是将视频和音频数据显示在用户界面的过程，一般情况包含的步骤：（1）接收媒体数据：从网络中接收音频和视频数据，数据通过WebRTC连接从远程对等方传输。（2）解码：接收的音频和视频数据通常以压缩格式（H.264、VP8、Opus等）传输，在渲染之前，必须将这些数据解码为原始音频和视频帧。（3）音频/视频帧处理：解码后的音频和视频帧可以进行额外处理，如声音增强、噪声降低、滤波或视频特效应用等。（4）同步和时序控制：音频和视频帧需要根据时间戳进行同步，以确保它们以正确的时序呈现。（5）渲染：对于视频，包括将图像渲染到屏幕上，对于音频，包括将声音输出到扬声器。（6）同步和播放控制：渲染后的音频和视频需要根据时间戳同步和播放，以确保它们按照正确的时间呈现。

参考资料：

W3C标准文档：https://www.w3.org/TR/webrtc-stats/
调试工具介绍：https://blog.csdn.net/cgs1999/article/details/110084983
简单实践：https://www.jianshu.com/p/239cd5b56975