WebRTC 视频流接纳核算陈述

在每次视频推流或拉流结束后,WebRTC都会输出本次视频推拉流的核算陈述。其中包含了关于评价本次推拉流质量相关的若干参数。本文的首要意图是介绍视频拉流相关的核算目标意义。

关于推流相关的核算目标,别的的文章进行独自描绘。

本文源码基于 WebRTC M94 编写。后续 WebRTC 版本或许有所变化(如 receive_statistics_proxy 已被移除,改为 receive_statistics_proxy2),细节或许不同,但基本原理应该适用。

相关源码

  • video\receive_statistics_proxy.cc
  • call\video_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

WebRTC 视频流接收统计报告

解码器解码一帧后,会告诉到 ReceiveStatisticsProxy::OnDecodedFrame() 中对解码帧数添加计数。

DroppedFrames.Receiver

VideoReceiveStream::Stop() 执行的时分,会调用 RtpVideoStreamReceiver::GetUniqueFramesSeen() 获取一个视频帧计数器 frame_counter_,它的值是在 RtpVideoStreamReceiver::OnReceivedPayloadData() 中依据收包时刻戳来添加,详细见源码 video\rtp_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。关于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

WebRTC 视频流接收统计报告

KeyFramesReceivedInPermille

permille是“千分率”的意思,因此,这个数值是表明接纳要害帧的千分率。核算公式在代码中如下:

(要害帧总数 x 1000 + 总帧数 / 2) / 总帧数    (1

其中总帧数是要害帧和非要害帧的总和。留意核算的结果会被强转成整型。

其实我看到这个公式是有点不太了解的。如果只是核算千分率,为何不直接就使用

(要害帧总数  总帧数) x 10002

就行了?如果依照上面的公式(1)核算,意味着核算出来的结果始终是会比公式(2)要大一些的(约等于0.5)。不知道作者是出于什么考虑。

DecodeTimeInMs

均匀解码耗时。数值来自于 ReceiveStatisticsProxy的成员变量 decode_time_counter_,变量类型是rtc::SampleCounter(源码:rtc_base\numerics\sample_counter.cc)。rtc::SampleCounter的源码能够阅览一下,比较简略,ReceiveStatisticsProxy有许多变量类型都是它。

ReceiveStatisticsProxy::OnDecodedFrame被调用的时分,会将当时帧的解码耗时decode_time_ms追加到decode_time_counter_中记载下来,并添加一个采样计数。终究核算的均匀解码耗时,便是调用rtc::SampleCounterAvg方法核算得到的,其原理比较简略:悉数帧的解码耗时总时长采样计数。与 RenderFramesPerSecond一样,对采样计数现在有最小200的要求,即小于200个采样计数不输出此项数据。

JitterBufferDelayInMs, TargetDelayInMs, CurrentDelayInMs

这三个数值具有强相关性,因此放到一起描绘。它们别离对应 ReceiveStatisticsProxy的成员变量 jitter_buffer_delay_counter_target_delay_counter_current_delay_counter_,变量类型是rtc::SampleCounter

ReceiveStatisticsProxy::OnFrameBufferTimingsUpdated被调用的时分,会传入jitter_buffer_mstarget_delay_ms以及current_delay_ms,累加到对应的采样计数器变量中。终究用于核算均匀值:分子是每次传入的数值总和,分母是次数

ReceiveStatisticsProxy::OnFrameBufferTimingsUpdatedFrameBuffer调用,源码:modules\video_coding\frame_buffer2.cc

@startuml
Actor jitter_buffer
jitter_buffer -> FrameBuffer : IntersetFrame/NextFrame
FrameBuffer -> FrameBuffer : StartWaitForNextFrameOnQueue
FrameBuffer -> FrameBuffer : GetNextFrame
FrameBuffer -> FrameBuffer : UpdateJitterDelay
FrameBuffer -> ReceiveStatisticsProxy : OnFrameBufferTimingsUpdated
@enduml

WebRTC 视频流接收统计报告

FrameBuffer 和 JitterBuffer 的完成原理不在本文介绍规模之内,感兴趣的读者自行研读源码。

EndToEndDelayInMs

端到端均匀延时。对应 VideoReceiveStream::Stats 的成员变量 e2e_delay_counter。 它的类型是rtc::SampleCounter。在ReceiveStatisticsProxy::OnRenderedFrame中会核算单帧的延时,累加到e2e_delay_counter。单次的延时数值是当时 ntp_time(webrtc::Clock::CurrentNtpInMilliseconds())减去webrtc::VideoFramentp_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<size_t> histogram_low_;
std::map<uint32_t, size_t> 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来说,这个分界点是500kMaxCommonInterframeDelayMs)。

histogram_low_的每个元素索引序号代表详细的一个帧距离数值,值表明此帧距离的次数。分界点是500的话,histogram_low_所代表的帧距离数值规模便是0~499。

histogram_high_histogram_low_的效果类似,但它的类型是 std::map,key表明帧距离数值,value表明次数。

InterframeDelay95PercentileInMs调用的是rtc::HistogramPercentileCounterGetPercentile()方法,传入参数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

ReceivedHeightInPixels

拉取的视频流分辨率的均匀高度。其他与ReceivedWidthInPixels相同,不再赘述。

MediaBitrateReceivedInKbps

均匀接纳码率。接纳的字节数来自 VideoReceiveStream::Stats 的成员变量 total_media_bytes。在ReceiveStatisticsProxy::OnCompleteFrame会对接纳字节数进行累加,终究作为核算均匀接纳码率的分子。