视频推流或拉流WebRTC视频流接收统计报告
WebRTC 视频流接收统计报告
在每次视频推流或拉流结束后，WebRTC都会输出本次视频推拉流的统计报告。其中包含了关于评价本次推拉流质量相关的若干参数。本文的主要目的是介绍视频拉流相关的统计指标含义。
关于推流相关的统计指标，另外的文章进行单独描述。
本文源码基于 WebRTC M94 编写。后续 WebRTC 版本可能有所变化（如 receive_statistics_proxy 已被移除，改为 receive_statistics_proxy2），细节可能不同，但基本原理应该适用。相关源码 videoreceive_statistics_proxy.cc callvideo_receive_stream.h统计指标ReceiveStreamLifetimeInSeconds
含义如字面意思。表示从视频拉流对象创建，到结束的总时长，单位是秒。
计算的起始时间是 ReceiveStatisticsProxy 类构造的时候，在 ReceiveStatisticsProxy::UpdateHistograms() 中，当前时间减去起始时间，得到耗时。VideoReceiveStream 的构造函数，同时构造了 ReceiveStatisticsProxy。 VideoReceiveStream::Stop() 的时候，会调用 ReceiveStatisticsProxy::UpdateHistograms() 完成各种度量指标计算。
Frames decoded
顾名思义，表示解码总帧数。对应 VideoReceiveStream::Stats 的成员变量 frames_decoded。 视频帧解码通知时序：@startuml Actor Decoder Decoder -> VCMDecodedFrameCallback : Decoded VCMDecodedFrameCallback -> VideoStreamDecoder : FrameToRender VideoStreamDecoder -> ReceiveStatisticsProxy : OnDecodedFrame @enduml
解码器解码一帧后，会通知到 ReceiveStatisticsProxy::OnDecodedFrame() 中对解码帧数增加计数。
【更多音视频学习资料，点击下方链接免费领取 ，先码住不迷路~】
音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）DroppedFrames.Receiver
当 VideoReceiveStream::Stop() 执行的时候，会调用 RtpVideoStreamReceiver::GetUniqueFramesSeen() 获取一个视频帧计数器 frame_counter_，它的值是在 RtpVideoStreamReceiver::OnReceivedPayloadData() 中根据收包时间戳来增加，具体见源码 videortp_video_stream_receiver.cc。frame_counter_.Add(packet->timestamp);
这个视频帧计数器可以理解为从收到的视频帧总数，然后用这个总数减去解码帧数Frames decoded，就得到了丢掉的总帧数：int num_dropped_frames = *num_unique_frames_ - stats_.frames_decoded;ReceivedPacketsLostInPercent
顾名思义，丢包率（百分比）。当 ReceiveStreamLifetimeInSeconds大于10秒时才可能输出这个数值。这个数值实际的计算位置来自 StreamStatisticianImpl::GetFractionLostInPercent()。丢包率的分子和分母不在本文介绍范围内，感兴趣的读者自行阅读源码。DecodedFramesPerSecond
平均解码帧率。以当前时间减去解码第一帧开始时间得到的差值做为分母，解码总帧数做为分子，计算得出的整型数值。RenderFramesPerSecond
平均渲染帧率。数值来自于 ReceiveStatisticsProxy的成员变量 render_fps_tracker_，变量类型是rtc::RateTracker。
在ReceiveStatisticsProxy::OnRenderedFrame中会调用 AddSamples增加一个采样计数。最后调用 RateTracker::ComputeTotalRate 返回值并对其四舍五入获得渲染帧率。例如渲染帧数总共是 545，总时长是 60000 毫秒，得到的帧率就是 545 x 1000 ÷ 60000 = 9.08 ≈ 9 帧/秒。
代码中对采样计数有最少200个的约束，即少于200帧是不会输出渲染帧率的。
渲染帧通知时序大概如下：@startuml Actor Decoder Decoder -> VideoStreamDecoder : FrameToRender VideoStreamDecoder -> IncomingVideoStream : OnFrame note right 如果 VideoReceiveStream::Config 的 enable_prerenderer_smoothing 是 false，则会直接送给 VideoReceiveStream end note IncomingVideoStream -> VideoReceiveStream : OnFrame note right onFrame 是实现 rtc::VideoSinkInterface 的虚函数 end note VideoReceiveStream -> ReceiveStatisticsProxy : OnRenderedFrame @enduml
KeyFramesReceivedInPermille
permille是＂千分率＂的意思，因此，这个数值是表示接收关键帧的千分率。计算公式在代码中如下：(关键帧总数 x 1000 + 总帧数 / 2) / 总帧数 （1）
其中总帧数是关键帧和非关键帧的总和。注意计算的结果会被强转成整型。
其实我看到这个公式是有点不太理解的。如果只是计算千分率，为何不直接就使用(关键帧总数 ÷ 总帧数) x 1000 （2）
就行了？如果按照上面的公式（1）计算，意味着计算出来的结果始终是会比公式（2）要大一些的（约等于0.5）。不知道作者是出于什么考虑。DecodeTimeInMs
平均解码耗时。数值来自于 ReceiveStatisticsProxy的成员变量 decode_time_counter_，变量类型是rtc::SampleCounter（源码：rtc_base umericssample_counter.cc）。rtc::SampleCounter的源码可以阅读一下，比较简单，ReceiveStatisticsProxy有很多变量类型都是它。
在ReceiveStatisticsProxy::OnDecodedFrame被调用的时候，会将当前帧的解码耗时decode_time_ms追加到decode_time_counter_中记录下来，并增加一个采样计数。最终计算的平均解码耗时，就是调用rtc::SampleCounter的Avg方法计算得到的，其原理比较简单：全部帧的解码耗时总时长÷采样计数。与 RenderFramesPerSecond一样，对采样计数目前有最小200的要求，即小于200个采样计数不输出此项数据。JitterBufferDelayInMs, TargetDelayInMs, CurrentDelayInMs
这三个数值具有强相关性，因此放到一起描述。它们分别对应 ReceiveStatisticsProxy的成员变量 jitter_buffer_delay_counter_，target_delay_counter_和current_delay_counter_，变量类型是rtc::SampleCounter。
在ReceiveStatisticsProxy::OnFrameBufferTimingsUpdated被调用的时候，会传入jitter_buffer_ms，target_delay_ms以及current_delay_ms，累加到对应的采样计数器变量中。最终用于计算平均值：分子是每次传入的数值总和，分母是次数。
【更多音视频学习资料，点击下方链接免费领取 ，先码住不迷路~】
音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）
ReceiveStatisticsProxy::OnFrameBufferTimingsUpdated由 FrameBuffer调用，源码：modulesvideo_codingframe_buffer2.cc：@startuml Actor jitter_buffer jitter_buffer -> FrameBuffer : IntersetFrame/NextFrame FrameBuffer -> FrameBuffer : StartWaitForNextFrameOnQueue FrameBuffer -> FrameBuffer : GetNextFrame FrameBuffer -> FrameBuffer : UpdateJitterDelay FrameBuffer -> ReceiveStatisticsProxy : OnFrameBufferTimingsUpdated @enduml
FrameBuffer 和 JitterBuffer 的实现原理不在本文介绍范围之内，感兴趣的读者自行研读源码。EndToEndDelayInMs
端到端平均延时。对应 VideoReceiveStream::Stats 的成员变量 e2e_delay_counter。 它的类型是rtc::SampleCounter。在ReceiveStatisticsProxy::OnRenderedFrame中会计算单帧的延时，累加到e2e_delay_counter。单次的延时数值是当前 ntp_time（webrtc::Clock::CurrentNtpInMilliseconds())减去webrtc::VideoFrame的ntp_time_ms_得到的。EndToEndDelayMaxInMs
端到端最大延时。它是 VideoReceiveStream::Stats 的成员变量 e2e_delay_counter记录的所有单帧延时的最大值。InterframeDelayInMs
解码帧间隔平均值。对应 VideoReceiveStream::Stats 的成员变量 interframe_delay_counter。 它的类型是rtc::SampleCounter。在ReceiveStatisticsProxy::OnDecodedFrame中会计算单帧的解码时间间隔（即ReceiveStatisticsProxy::OnDecodedFrame被调用的两次间隔），累加到interframe_delay_counter。InterframeDelayMaxInMs
最大解码帧间隔。它是 VideoReceiveStream::Stats 的成员变量 interframe_delay_counter记录的所有单帧解码帧间隔数值的最大者。InterframeDelay95PercentileInMs
这个数值代表：超过95%帧间隔数值里的最小值，或者理解为 95%的帧间隔都小于多少。对应 VideoReceiveStream::Stats 的成员变量 interframe_delay_percentiles。它的类型是rtc::HistogramPercentileCounter。这个数值乍一看不太容易理解，这里简单介绍一下。
要理解这个数值，需要先理解rtc::HistogramPercentileCounter。它与 rtc::SampleCounter有类似之处，但本质上还是有很多不同。它存在几个关键的成员变量：std::vector histogram_low_; std::map histogram_high_; const uint32_t long_tail_boundary_; size_t total_elements_; size_t total_elements_low_;
以long_tail_boundary_作为分界点，小于long_tail_boundary_的值，记录到histogram_low_，否则记录到histogram_high_。目前就InterframeDelay95PercentileInMs来说，这个分界点是500（kMaxCommonInterframeDelayMs）。histogram_low_的每个元素索引序号代表具体的一个帧间隔数值，值表示此帧间隔的次数。分界点是500的话，histogram_low_所代表的帧间隔数值范围就是0~499。
histogram_high_与histogram_low_的作用类似，但它的类型是 std::map，key表示帧间隔数值，value表示次数。
InterframeDelay95PercentileInMs调用的是rtc::HistogramPercentileCounter的GetPercentile()方法，传入参数0.95f。它的目的是跳过全部计数 total_elements_的 95% 减 1 以后，寻找剩余部分里最小的帧间隔数值。注意这里的 95% 是帧间隔的发生总次数，不是帧间隔数值。
下面举个例子：测试帧间隔数值：{ 10, 20, 10, 30, 10, 50, 30, 70, 225, 10, 110, 120, 530, 145, 15, 560, 127, 138, 15, 200 }; 全部添加到 rtc::HistogramPercentileCounter 后的排列： ---------- histogram_low_: [10] = 4 [15] = 2 [20] = 1 [30] = 2 [50] = 1 [70] = 1 [110] = 1 [120] = 1 [127] = 1 [138] = 1 [145] = 1 [200] = 1 [225] = 1 ---------- long_tail_boundary_:500 ---------- histogram_high_: <530, 1> <560, 1> 按照上面测试序列，(20 x 0.95) - 1 = 18，跳过18个以后，首个帧间隔是 530， 所以 InterframeDelay95PercentileInMs 的结果就是 530。表示 95% 的帧间隔都小于 530。 ReceivedWidthInPixels
拉取的视频流分辨率的平均宽度。由于远程视频流推流分辨率可能产生变化，这里输出的是平均值，而非其中的某一次。它的类型是rtc::SampleCounter。
【更多音视频学习资料，点击下方链接免费领取 ，先码住不迷路~】
音视频开发（资料文档+视频教程+面试题）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）ReceivedHeightInPixels
拉取的视频流分辨率的平均高度。其他与ReceivedWidthInPixels相同，不再赘述。MediaBitrateReceivedInKbps
平均接收码率。接收的字节数来自 VideoReceiveStream::Stats 的成员变量 total_media_bytes。在ReceiveStatisticsProxy::OnCompleteFrame会对接收字节数进行累加，最后作为计算平均接收码率的分子。
如果你对音视频开发感兴趣，觉得文章对您有帮助，别忘了点赞、收藏哦！或者对本文的一些阐述有自己的看法，有任何问题，欢迎在下方评论区讨论！
