webrtc 屏幕共享时间性能统计分析

最新推荐文章于 2024-08-10 09:07:08 发布
最新推荐文章于 2024-08-10 09:07:08 发布
阅读量1.9k 收藏 5
点赞数 1
分类专栏： webrtc
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/zhuiyuanqingya/article/details/81668190
版权

webrtc 本身对时间性能参数有比较完备的统计，分析 webrtc 延时性能，直接分析其中关于性能统计的代码，理解其中各个参数的含义基本能够找到自己需要的参数，本文主要关注视频延时，会忽略音频延时。
备注：本文的 webrtc 代码来自 chromium（64）开源代码。

1.发送端时间性能统计

发送端涉及到的文件包括：

src\third_party\webrtc\video\send_statistics_proxy.cc
src\third_party\webrtc\video\send_statistics_proxy.h

统计的是平均性能，只有在在结束桌面共享之后，才可以查看统计结果：

SendStatisticsProxy::~SendStatisticsProxy() {
  rtc::CritScope lock(&crit_);
  RTC_LOG(LS_INFO) << "QingTest ";
  uma_container_->UpdateHistograms(rtp_config_, stats_);

  int64_t elapsed_sec = (clock_->TimeInMilliseconds() - start_ms_) / 1000;
  RTC_HISTOGRAM_COUNTS_100000("WebRTC.Video.SendStreamLifetimeInSeconds",
                              elapsed_sec);

  if (elapsed_sec >= metrics::kMinRunTimeInSeconds)
    UpdateCodecTypeHistogram(payload_name_);
}

在一次屏幕共享之后，查看统计结果如下：

[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(254)] WebRTC.Video.Screenshare.InputWidthInPixels 1280
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(255)] WebRTC.Video.Screenshare.InputHeightInPixels 720
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(261)] WebRTC.Video.Screenshare.InputFramesPerSecond, periodic_samples:17, {min:22, avg:28, max:30}
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(272)] WebRTC.Video.Screenshare.SentWidthInPixels 1280
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(273)] WebRTC.Video.Screenshare.SentHeightInPixels 720
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(279)] WebRTC.Video.Screenshare.SentFramesPerSecond, periodic_samples:17, {min:15, avg:27, max:30}
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(298)] WebRTC.Video.Screenshare.SentToInputFpsRatioPercent 96
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(307)] WebRTC.Video.Screenshare.EncodeTimeInMs 5
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(314)] WebRTC.Video.Screenshare.KeyFramesSentInPermille 1
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(442)] WebRTC.Video.Screenshare.SentPacketsLostInPercent 0
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(490)] WebRTC.Video.Screenshare.NumberOfPauseEvents 0
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(498)] WebRTC.Video.Screenshare.PausedTimeInPercent 0
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(523)] WebRTC.Video.Screenshare.BitrateSentInBps, periodic_samples:17, {min:66152, avg:156096, max:346976}
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(530)] WebRTC.Video.Screenshare.MediaBitrateSentInBps, periodic_samples:17, {min:62968, avg:139328, max:336448}
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(538)] WebRTC.Video.Screenshare.PaddingBitrateSentInBps, periodic_samples:17, {min:0, avg:1528, max:16128}
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(547)] WebRTC.Video.Screenshare.RetransmittedBitrateSentInBps, periodic_samples:17, {min:0, avg:0, max:0}
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(555)] WebRTC.Video.Screenshare.RtxBitrateSentInBps, periodic_samples:8, {min:0, avg:23672, max:100592}
[6596:3116:0815/131345.285:INFO:send_statistics_proxy.cc(571)] WebRTC.Video.Screenshare.FecBitrateSentInBps, periodic_samples:17, {min:0, avg:0, max:0}
[6596:3116:0815/131345.286:INFO:send_statistics_proxy.cc(575)] Frames encoded 931
[6596:3116:0815/131345.286:INFO:send_statistics_proxy.cc(576)] WebRTC.Video.Screenshare.DroppedFrames.Capturer 0
[6596:3116:0815/131345.286:INFO:send_statistics_proxy.cc(580)] WebRTC.Video.Screenshare.DroppedFrames.EncoderQueue 11
[6596:3116:0815/131345.286:INFO:send_statistics_proxy.cc(584)] WebRTC.Video.Screenshare.DroppedFrames.Encoder 0
[6596:3116:0815/131345.286:INFO:send_statistics_proxy.cc(588)] WebRTC.Video.Screenshare.DroppedFrames.Ratelimiter 15

从其中能够看到的有用数据为视频编码延时为 5ms，这基本是一个可以忽略的延时。

2.接收端时间性能统计

接收端统计性能统计分析的代码主要位于文件：

src\third_party\webrtc\video\receive_statistics_proxy.cc
src\third_party\webrtc\video\receive_statistics_proxy.h

在 receive_statistics_proxy.h 文件中，定义了类 ReceiveStatisticsProxy，这个类中包括了视频处理相关的一些参数，部分与时间性能相关的参数如下。

SampleCounter sync_offset_counter_;
SampleCounter decode_time_counter_;
SampleCounter jitter_buffer_delay_counter_;
SampleCounter target_delay_counter_;
SampleCounter current_delay_counter_;
SampleCounter delay_counter_;

其中，SampleCounter 结构体定义如下：

struct SampleCounter {
    SampleCounter() : sum(0), num_samples(0) {}
    void Add(int sample);
    int Avg(int64_t min_required_samples) const;
    int Max() const;
    void Reset();
    void Add(const SampleCounter& other);

   private:
    int64_t sum;
    int64_t num_samples;
    rtc::Optional<int> max;
};

其中， Avg() 函数有最小样本数量限制，如果样本数量小于 kMinRequiredSamples = 200， 将返回 -1，这种情况下就不会有 Avg() 相关参数打印出来。

int ReceiveStatisticsProxy::SampleCounter::Avg(
    int64_t min_required_samples) const {
  if (num_samples < min_required_samples || num_samples == 0)
    return -1;
  return static_cast<int>(sum / num_samples);
}

根据 ReceiveStatisticsProxy 工作的方式，只有在 类析构的时候才会输出统计参数。之前也疑惑为什么在通过 webrtc 共享桌面的时候没有统计参数输出。

ReceiveStatisticsProxy::~ReceiveStatisticsProxy() {
  UpdateHistograms();
}

void ReceiveStatisticsProxy::UpdateHistograms() {
  int stream_duration_sec = (clock_->TimeInMilliseconds() - start_ms_) / 1000;
  if (stats_.frame_counts.key_frames > 0 ||
      stats_.frame_counts.delta_frames > 0) {
    RTC_HISTOGRAM_COUNTS_100000("WebRTC.Video.ReceiveStreamLifetimeInSeconds",
                                stream_duration_sec);
    RTC_LOG(LS_INFO) << "WebRTC.Video.ReceiveStreamLifetimeInSeconds "
                     << stream_duration_sec;
  }
  ...
}

在结束桌面共享之后，查看日志文件，可以看到如下结果：

[9688:12688:0818/100031.401:INFO:video_receive_stream.cc(149)] ~VideoReceiveStream: {decoders: [{decoder: (VideoDecoder), payload_type: 96, payload_name: VP8, codec_params: {}}, {decoder: (VideoDecoder), payload_type: 98, payload_name: VP9, codec_params: {}}, {decoder: (VideoDecoder), payload_type: 100, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 1profile-level-id: 42001f}}, {decoder: (VideoDecoder), payload_type: 102, payload_name: H264, codec_params: {level-asymmetry-allowed: 1packetization-mode: 1profile-level-id: 42e01f}}], rtp: {remote_ssrc: 1426571530, local_ssrc: 1, rtcp_mode: RtcpMode::kReducedSize, rtcp_xr: {receiver_reference_time_report: off}, remb: on, transport_cc: on, nack: {rtp_history_ms: 1000}, ulpfec_payload_type: 125, red_type: 127, rtx_ssrc: 518982694, rtx_payload_types: {97 (pt) -> 96 (apt), 99 (pt) -> 98 (apt), 101 (pt) -> 100 (apt), 123 (pt) -> 127 (apt), 124 (pt) -> 102 (apt), }, extensions: [{uri: http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01, id: 5}, {uri: http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time, id: 3}, {uri: http://www.webrtc.org/experiments/rtp-hdrext/playout-delay, id: 6}, {uri: http://www.webrtc.org/experiments/rtp-hdrext/video-content-type, id: 7}, {uri: http://www.webrtc.org/experiments/rtp-hdrext/video-timing, id: 8}, {uri: urn:3gpp:video-orientation, id: 4}, {uri: urn:ietf:params:rtp-hdrext:toffset, id: 2}]}, renderer: (renderer), render_delay_ms: 10, sync_group: 2znW7AKmGSPRduSc5KrkYVc16yDUzQKHPmKH, pre_decode_callback: nullptr, target_delay_ms: 0}
[9688:12688:0818/100031.404:INFO:receive_statistics_proxy.cc(134)] WebRTC.Video.ReceiveStreamLifetimeInSeconds 927
[9688:12688:0818/100031.404:INFO:receive_statistics_proxy.cc(145)] WebRTC.Video.ReceivedPacketsLostInPercent 0
[9688:12688:0818/100031.404:INFO:receive_statistics_proxy.cc(163)] WebRTC.Video.AVSyncOffsetInMs 65
[9688:12688:0818/100031.404:INFO:receive_statistics_proxy.cc(169)] WebRTC.Video.RtpToNtpFreqOffsetInKhz, periodic_samples:23, {min:0, avg:0, max:0}
[9688:12688:0818/100031.404:INFO:receive_statistics_proxy.cc(181)] WebRTC.Video.KeyFramesReceivedInPermille 0
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(188)] WebRTC.Video.Decoded.Vp8.Qp 2
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(193)] WebRTC.Video.DecodeTimeInMs 1
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(199)] WebRTC.Video.JitterBufferDelayInMs 221
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(205)] WebRTC.Video.TargetDelayInMs 246
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(211)] WebRTC.Video.CurrentDelayInMs 243
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(279)] WebRTC.Video.Screenshare.InterframeDelayInMs 34
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(287)] WebRTC.Video.Screenshare.InterframeDelayMaxInMs 613
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(297)] WebRTC.Video.Screenshare.InterframeDelay95PercentileInMs 37
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(305)] WebRTC.Video.Screenshare.ReceivedWidthInPixels 1280
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(313)] WebRTC.Video.Screenshare.ReceivedHeightInPixels 720
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(327)] WebRTC.Video.Screenshare.MediaBitrateReceivedInKbps 2
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(348)] WebRTC.Video.Screenshare.Decoded.Vp8.Qp 2
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(279)] WebRTC.Video.Screenshare.InterframeDelayInMs.S0 34
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(287)] WebRTC.Video.Screenshare.InterframeDelayMaxInMs.S0 613
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(297)] WebRTC.Video.Screenshare.InterframeDelay95PercentileInMs.S0 37
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(305)] WebRTC.Video.Screenshare.ReceivedWidthInPixels.S0 1280
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(313)] WebRTC.Video.Screenshare.ReceivedHeightInPixels.S0 720
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(327)] WebRTC.Video.Screenshare.MediaBitrateReceivedInKbps.S0 2
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(348)] WebRTC.Video.Screenshare.Decoded.Vp8.Qp.S0 2
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(279)] WebRTC.Video.Screenshare.InterframeDelayInMs.ExperimentGroup3 34
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(287)] WebRTC.Video.Screenshare.InterframeDelayMaxInMs.ExperimentGroup3 613
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(297)] WebRTC.Video.Screenshare.InterframeDelay95PercentileInMs.ExperimentGroup3 37
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(305)] WebRTC.Video.Screenshare.ReceivedWidthInPixels.ExperimentGroup3 1280
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(313)] WebRTC.Video.Screenshare.ReceivedHeightInPixels.ExperimentGroup3 720
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(327)] WebRTC.Video.Screenshare.MediaBitrateReceivedInKbps.ExperimentGroup3 2
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(348)] WebRTC.Video.Screenshare.Decoded.Vp8.Qp.ExperimentGroup3 2
[9688:12688:0818/100031.405:INFO:receive_statistics_proxy.cc(371)] WebRTC.Video.MediaBitrateReceivedInKbps 294

其中，QP 这个参数重点介绍一下，因为之前并没有接触过这个参数，对应到上面的统计结果为 WebRTC.Video.Screenshare.Decoded.Vp8.Qp.S0。
在不抓屏的情况下，例如采集摄像头，webrtc 会开启 QualityScaler 。在编码的时候，计算每幅图像的量化参数(QP,Quantization Parameter)，相当于图像的复杂度。当一系列图像的平均 QP 超过阈值时会调整分辨率（H264 的合法范围是 24~37），超过 37 要降低分辨率，低于 24 要提高分辨率。
但对于抓屏而言这种策略并不合理，因为屏幕图像有很多细节，文字也会提升 QP 值。如果在抓屏时开启分辨率自动调整会造成模糊和不可读文字，因为抓屏和摄像头采集不一样，图像细节更加丰富，并且基本不会切换到细节少的状态。
分析参数JitterBufferDelayInMs，这只是整个屏幕共享过程的平均缓冲延时，从统计数据看出缓冲区延时为 250 ms。要看实时缓冲延时需要查看：

src\third_party\webrtc\modules\video_coding\timing.h

VCMTiming 类的 jitter_delay_ms_ 成员，通过在日志文件中打印整个变量分析，这个值在屏幕共享过程中是动态变化的：

47ms –> 379ms –> 258ms

开始屏幕共享的时候抖动缓冲延时是 47ms，在屏幕共享过程中逐渐增大一直到最大 379ms，之后又慢慢回落到 258ms。

从统计数据可以看到音视频同步(WebRTC.Video.AVSyncOffsetInMs)占用了 65ms ，解码占用了 1ms，抖动缓冲延时(WebRTC.Video.JitterBufferDelayInMs)占据了 221ms。

3. 结论

根据统计结果，可以知道 webrtc 屏幕共享延时主要在接收端，并且主要是缓冲这一块占据了绝对大头。

参考：
WebRTC的QP、分辨率自动调整

zhuiyuanqingya
关注
专栏目录
WebRTC 用例和性能
anyRTC的博客
06-10 350
WebRTC 用例和性能 实现低延迟、点对点传输是一项艰巨的工程挑战：有 NAT 遍历和连接检查、信令、安全、拥塞控制和无数其他细节需要处理。WebRTC 代表我们处理以上所有内容，这就是为什么它可以说是自网络平台成立以来最重要的补充之一。事实上，这不仅仅是 WebRTC 提供的单个部分，而是所有组件协同工作以提供用于在浏览器中构建点对点应用程序的简单统一的 API。 然而，即使有所有内置服务，设计高效和高性能的点对点应用程序仍然需要大量仔细的思考和规划：点对点本身并不意味着高性能。如果有的话，对等点之间带
WebRTC视频编解码器性能评估
LiveVideoStack
03-11 899
正文字数：1628 阅读时长：3 分钟GUSTAVO GARCIA在同一测试环境下，测试得出不同编码器的CPU使用结果。文 /GUSTAVO GARCIA原文链接 /http://...
webrtc优缺点使用场合以及约束以及如何解除这些约束
最新发布
zhangyihu321的专栏
08-10 447
通过实施这些改进，可以大大提高 WebRTC 应用的性能、可靠性和用户体验。然而，需要注意的是，某些改进可能需要大量的开发资源和专业知识。因此，应根据具体项目的需求和资源来选择最适合的优化策略。4. 服务器要求：虽然是P2P，但仍需信令服务器和STUN/TURN服务器。3. NAT穿透问题：在某些网络环境下可能需要额外的TURN服务器。5. 移动设备性能：可能对移动设备的电池寿命和处理能力造成压力。8. 编解码器支持：不同浏览器支持的编解码器可能不同。6. 移动端优化：在移动应用中使用时需特别优化。
Android IOS WebRTC 音视频开发总结（五六）-- 如何测试网络性能？
weixin_33796177的博客
12-24 188
本文主要介绍如何测试网络性能，文章来自博客园RTC.Blacker，欢迎关注微信公众号blacker，更多详见www.rtc.help   网络性能直接决定了视频通话效果，比如qq，很多时候我们我们觉得通话效果不错，但有些时候体验很差，这时候我们怎么判断是网络不好还是产品本身质量问题呢？最好的办法就是有工具能直接测试当前网络质量，这也正是本文的主题，原文最早来自环信音视频专家符宁，由kelly...
WebRTC压力测试实战
伤心的辣条
10-30 352
最近几年WebRTC特别火，但如何对WebRTC服务进行压力测试是一个很有难度和挑战的工作，因为WebRTC客户端实际使用上产生的压力瓶颈主要来源对象是码流而非传统的HTTP并发请求。因为业务要求服务至少能支持提供300路并发，于是准备300路WebRTC连接验证下SFU服务器压力情况，这里分享进行压测的思路及方式和一些的经验，如果在这方面有相关经验的测试技术方案的测试同行，请加评论给予指导帮助。
WebRTC实时通信协议详解
yinshipin007的博客
05-10 5763
基本概念 WebRTC是由Google主导的，由一组标准、协议和JavaScript API组成，用于实现浏览器之间（端到端之间）的音频、视频及数据共享。WebRTC不需要安装任何插件，通过简单的JavaScript API就可以使得实时通信变成一种标准功能。 现在各大浏览器以及终端已经逐渐加大对WebRTC技术的支持。下图是webrtc官网给出的现在已经提供支持了的浏览器和平台。 Android上实现一个WebRTC项目 在深入讲解协议之前，我们先来看实例。我们先来看下在Androi.
iOS WebRTC中的噪声消除技术
WebRTC简介 ### 1.1 什么是WebRTC？ WebRTC（Web Real-Time Communication）是一项用于在浏览器之间实现实时通信的开放标准。它包括一系列的通信协议、API和技术，使开发人员能够在Web应用程序中实现音频、视频和...
WebRTC中的视频编解码详解
# 一、WebRTC简介 ## 1.1 什么是WebRTC WebRTC（Web Real-Time Communication）是一种实时通信技术，它允许浏览器和移动应用程序之间实现点对点的音频、视频和数据传输，无需插件或其他中间件的支持。WebRTC基于W3...
WebRTC音视频媒体处理与编解码
WebRTC简介 ## 1.1 WebRTC的定义与特点 WebRTC（Web Real-Time Communication）是一种基于Web技术的实时通信协议，允许浏览器之间进行音视频传输和数据传输。它的主要特点包括： - **实时性**: WebRTC使用即时...
Android WebRTC实现网络丢包检测和恢复
WebRTC概述 ## 1.1 什么是WebRTC？ WebRTC（Web Real-Time Communication）是一种用于实时音视频通信的开源项目。它由Google主导开发，并得到了许多其他公司和开发者的支持。WebRTC提供了一组标准化的协议和API，...
webrtc 视频编码格式及参数配置
fanhenghui的专栏
11-23 7226
https://blog.csdn.net/CrystalShaw/article/details/80372015 一、视频编码格式初始配置 webrtc\media\engine\internalencoderfactory.cc 按照Push顺序，优先选取第一个编解码格式。   二、视频分辨率初始配置 webrtc\pc\videocapturertracksource.cc 选...
WebRTC传输与服务质量
yinshipin007的博客
03-07 533
本次分享我将从四个方面向大家介绍一下WebRTC传输是如何保证音视频服务质量的。第一，实时通信的目标。我们首先需要确定实时通信的目标，才能够知道要将实时通信做成怎样的系统、保证怎样的实时性；第二，WebRTC如何保障数据传输的实时性；第三，进行实时传输时，想要满足实时性，网络与服务质量之间可能存在的矛盾；最后，就是WebRTC如何解决网络与服务质量之间的矛盾。首先提出两个问题：第一，开会时你是喜欢在办公室里，还是更喜欢在线上开？第二，如果有一场演唱会，你愿意去现场呢？还是愿意在线上听？相信大家更多都会选择线
WebRTC RTCP 分析
aggresss
08-15 1970
参考文档
WebRTC 之度量与统计: 到底出了什么问题
温故而知新
07-14 901
由于新冠疫情，我们待在家中，在网上工作，开会，看电影的时间越来越多了。网络嘛，大家都知道，时常不稳定，网上开会时声音听不清楚，图像模糊，视频有马赛克(不是人为打的)的情况时有发生，这时候，问题出在哪里呢？ 也许是网络的问题，也许不是，即使网络出现问题，只要不是不可忍受的，我们依然需要进行调整，保证基本的功能： 语音通话要保持通畅，这是要首先保证的 共享的桌面或文件内容要能够识别 视频要能看到，哪...
WebRTC Qos优化杂记
sonysuqin的专栏
07-25 5847
本文是笔者对WebRTC Qos性能研究、优化的一些思考，希望对有兴趣的读者有一些启发。
WebRTC 视频流发送统计报告
我的玻璃盒子
10-13 974
在每次视频推流或拉流结束后，WebRTC都会输出本次视频推拉流的统计报告。其中包含了关于评价本次推拉流质量相关的若干参数。本文的主要目的是介绍视频推流相关的统计指标含义。
WebRTC-Internals工具初探
Go Java Python Test
10-26 280
编码是将原始音频和视频数据转换为数字格式的过程，以减小文件大小和带宽占用，解码是将数字数据重新转换为可播放或显示的原始数据的过程，WebRTC使用编码器和解码器来处理音频和视频数据，以在网络上传输和接收数据。渲染是指将音频和视频帧显示在用户界面上的过，在WebRTC中，音频和视频数据必须通过渲染引擎显示在浏览器或应用程序的界面上，以供用户查看和听取。帧是视频流中的基本单位，代表视频的一帧静止图像，视频通常由一系列连续的帧组成，以创建流畅的视频，帧也可以是关键帧，用于恢复丢失的视频数据。
android webrtc屏幕共享
07-27
Android WebRTC（Web Real-Time Communication）是一个用于实时音视频通信的技术栈，它支持屏幕共享功能。在Android上实现屏幕共享通常涉及到以下几个步骤： 1. **集成WebRTC库**：首先需要将WebRTC的SDK集成到你的Android项目中，这包括添加相关的依赖库，如`webrtc.jar`。 2. **设置权限**：为了访问用户的屏幕内容，你需要请求相应的权限，比如`ACCESS_FINE_LOCATION`（如果需要获取位置信息）和`VIEW_SCREEN_USAGE`（允许应用查看屏幕活动）。 3. **创建PeerConnection**：在Android应用中创建一个`PeerConnection`实例，并配置本地和远程的媒体源，其中屏幕共享可以作为`MediaStreamTrack`加入。 4. **屏幕捕获**：通过`SurfaceView`或`TextureView`，捕获设备的屏幕并将其转换成适合WebRTC的`VideoCapturerSource`。 5. **添加到PeerConnection**：将屏幕流加入到` PeerConnection`中，与音频、视频等其他流一起发送给远端。 6. **接收屏幕分享**：在接收方，也需要处理`ScreenCaptureHandler`，从接收到的媒体流中解码屏幕内容并显示出来。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值