webrtc
文章平均质量分 66
newrtc
这个作者很懒,什么都没留下…
展开
-
webrtc源码分析 nack详解
Nack详解原创 2022-03-03 15:24:16 · 2325 阅读 · 1 评论 -
webrtc源码分析 pacer代码流程
原创 2022-03-02 18:57:31 · 532 阅读 · 0 评论 -
webrtc 目录
webrtc 学习过程原创 2022-03-02 16:10:36 · 661 阅读 · 0 评论 -
webrtc源码分析 视频采集发送流程
1、简述video_loopback demo演示了怎么从call这一层创建流,接下来看一下视频的采集,编码,发送流程,本文只是粗略的跟踪流程,具体细节知识点后续分析。webrtc的更新太快,模块有些调整,也加了些处理流程,所以得重复的去看流程,也是因为脑子不好使,看完接着忘。2、跟踪代码...原创 2022-03-01 14:38:23 · 1208 阅读 · 0 评论 -
webrtc源码分析 vieo_loopback分析
1 介绍video_loopback demo包含了webrtc 上层网络协议的剩余部分,没有sdp协商,p2p,srtp,实现了从call实现音视频互通的例子。对于动手能力比较强的公司,适合从这层开发,搭建自己的架构模型,实现自由调度,大并发等2 分析源码2.1 demo入口启动入口:src/video/video_loopback_main.cc配置参数:src/video/video_loopback.cc这个文件主要是配置demo的参数,也是我们参考配置的方法简单看几个配置项:AB原创 2022-02-23 17:03:39 · 1843 阅读 · 0 评论 -
WebRTC源码分析——引用计数系统
引言WebRTC中自己实现了一套引用计数系统,在其基础库模块rtc_base/refcount中提供了相关实现,如下图所示:主要由四个类RefCountInterface、RefCounter、RefCountedObject、scoped_refptr一起构建起WebRTC中的引用计数系统。2. RefCountInterface——引用计数抽象接口RefCountInterface是一个抽象接口类,位于rtc_base/ref_count.h目录下。源码如下:enum class RefCo转载 2022-02-18 11:33:28 · 276 阅读 · 0 评论 -
webrtc 状态获取
webrtc状态获取简单调用回调类 class NRPlayerStatsObserver : virtual public webrtc::RTCStatsCollectorCallback { public: NRPlayerStatsObserver(); virtual ~NRPlayerStatsObserver(); virtual void OnStatsDelivered(const rtc::scoped_refptr<const RTCStatsReport&原创 2022-02-18 11:08:28 · 959 阅读 · 0 评论 -
webrtc源码分析 拥塞控制下-码率分配
1、前言本文是webrtc拥塞控制的下文,主要介绍的是从cc-controller获取码率之后,如何将码率设置到PacingController控制发送速率,同时如何将码率分配调整到各个stream,各个stream的layer, simulcast,fec中2、正文2.1 整体码率控制结构webrtc中是会同时存在多个stream,但所有的stream都会共用一个码率预估和平滑发送,这很符合逻辑(虽然gcc保障带宽公平性),发送数据的流程如上图数字所标,不同的stream最终发包的时候都是发送到转载 2022-02-15 15:55:33 · 1380 阅读 · 0 评论 -
webrtc源码分析 拥塞控制上-码率预估
1 前言本文是webrtc中拥塞控制的上文,主要是分析webrtc中的拥塞控制的码率探测,预估和调整的部分,介绍了整体框架和原理以及相关的类;webrtc版本:M912 正文2.1 整体框架webrtc中的部分码控结构如下图所示,从socket层接收到数据后,到transport解析rtcp包处理得到feedback,通过call将feedback转发到对应sendstream上的rtcp处理模块,最终通过RtpTransportControllerSend将feedback转发到GoogCcNe转载 2022-02-15 11:36:30 · 2068 阅读 · 1 评论 -
WebRTC的拥塞控制和带宽策略
介绍在视频通信的技术领域WebRTC已成为主流的技术标准,WebRTC包涵了诸多优秀的技术,譬如:音频数字信号处理技术(AEC, NS, AGC)、编解码技术、实时传输技术、P2P技术等,这些技术目的都是为了实现更好实时音视频方案。但是在高分辨率视频通信过程中,通信时延、图像质量下降和丢包卡顿是经常发生的事,甚至在WiFi环境下,一次视频重发的网络风暴可以引起WiFi网络间歇性中断,通信延迟和图像质量之间存在的排斥关系是实时视频过程中的主要矛盾。分析WebRTC是如何解决这个矛盾之前,先来看看我们在在线转载 2022-01-19 14:59:52 · 993 阅读 · 0 评论 -
webrtc源码分析 pacer一
背景介绍若仅仅发送音频数据,不需要PACER模块:1)一帧音频数据本身不大,不会超过以太网的最大报文长度。一个RTP报文可以搞定,按照打包时长的节奏发送就可以。但视频数据不能按照音频数据的思路发送,一帧视频可能很大,远大于以太网的1500byte,需要分别封装在几个RTP报文中,若这些视频帧RTP报文一起发送到网络上,必然会导致网络瞬间拥塞。产生丢包抖动等异常。2)大多数编解码格式下,一帧音频数据长度固定,音频码率持续平稳。码率不会出现忽高忽低现象。但是一帧视频数据长度受内容影响严重。I、P、B帧间的转载 2022-01-18 10:26:42 · 514 阅读 · 0 评论 -
浅谈WebRTC NetEQ
浅谈WebRTC NetEQWebRTC Native 代码里面有很多值得学习的宝藏,其中一个就是 WebRTC 的 NetEQ 模块。根据 WebRTC 术语表 对 NetEQ 的解释:A dynamic jitter buffer and error concealment algorithm used for concealing the negative effects of network jitter and packet loss. Keeps latency as low as pos转载 2021-12-06 14:00:03 · 622 阅读 · 0 评论 -
webrtc音视频同步详解
https://blog.csdn.net/sonysuqin/article/details/1072971571、webrtc 版本 202108202、时间戳音视频采样后会给每个音频采样、视频帧打一个时间戳,打包成RTP后放在RTP头中,称为RTP时间戳,RTP时间戳的单位依赖于音视频流各自的采样率。RTP Header格式如下:2.1 视频时间戳视频时间戳的单位为1/90000秒,但是90000并不是视频的采样率,而只是一个单位,帧率才是视频的采样率。不同打包方式下的时间戳:转载 2021-12-02 17:29:28 · 981 阅读 · 0 评论 -
webrtc源码分析 渲染延时
1.为了平滑渲染,造成延时FrameBuffer::StartWaitForNextFrameOnQueue() |FrameBuffer::FindNextFrame在FindNextFrame里面有计算渲染时间 if (frame->RenderTime() == -1) { frame->SetRenderTime(timing_->RenderTimeMs(frame->Timestamp(), now_ms)); }原创 2021-11-29 17:09:04 · 2061 阅读 · 0 评论 -
webrtc 视频解码及渲染过程
1 解码解码调用RepeatingTaskHandle::DelayedStartFrameBuffer::StartWaitForNextFrameOnQueue() |VideoReceiveStream2::StartNextDecode |VideoReceiveStream2::HandleEncodedFrame |VideoReceiveStream2::DecodeAndMaybeDispatchEncodedFra原创 2021-11-26 17:12:01 · 3614 阅读 · 0 评论 -
webrtc视频接收过程二
webrtc JitterBuffer1、webrtc版本2021.8.202、概要旧版的视频JitterBuffer实现在VCMJitterBuffer类中,目前已经不用,新版的JitterBuffer的功能被分散到多个模块中,主要包括:PacketBuffer:负责帧的完整性,保证组成帧的每个包序列号连续,并且有一个包标识帧的开始,有一个包标识帧的结束;RtpFrameReferenceFinder:负责给每个帧设置好参考帧,同时兼顾GOP内各帧的连续性;FrameBuffer:负责帧转载 2021-11-26 14:43:45 · 1599 阅读 · 0 评论 -
webrtc 视频接收过程一
视频接收调用1、网络接收线程PhysicalSocketServer::Wait |AsyncUDPSocket::OnReadEvent //windows 通过信号槽的方式发送 |AllocationSequence::OnReadPacket //win 接收槽 |UDPPort::HandleIncomingPacket |UDPPort::OnRead原创 2021-11-23 13:52:32 · 2010 阅读 · 0 评论 -
webrtc替换ffmpeg
webrtc替换ffmpeg,解决微软编译器开启h264编译不过问题win10+vs2019webrtc 默认是clang编译器,编译出来的库,在vs下不能用,出现各种各样的错误。如果设置了use_lld=false is_clang=false,开启h264,ffmpeg又编译不过。尝试替换掉ffmpeg,解决问题下载编译好的ffmpeg下载好ffmpeg,并且放在third_party下编辑\src\modules\video_coding下的BUILD.gn修改rtc_library原创 2021-07-29 15:50:49 · 1320 阅读 · 5 评论 -
webrt分析六(nack)
nack是什么丢包重传(NACK)是抵抗网络错误的重要手段。NACK在接收端检测到数据丢包后,发送NACK报文到发送端;发送端根据NACK报文中的序列号,在发送缓冲区找到对应的数据包,重新发送到接收端。NACK需要发送端,发送缓冲区的支持。nack流程发送端发送rtp,到达接收端时,发现丢包,接收端发送nack请求,发送端会从历史队列中取出数据重发。nack协议在rfc4585协议中定义可重传未到达数据的类型有二种:1 RTPFB:rtp报文丢失重传(丢包重传)。2 PSFB:指定净荷重传,原创 2021-07-07 15:08:32 · 880 阅读 · 0 评论 -
webrtc分析五(rtt计算)
rtt是什么rtt:往返时延(round-trip time,RTT) 是网络请求从起点到目的地然后再回到起点所花费的时长(不包括接收端的处理时间)。RTT是分析网络性能的一个重要指标,我们通常使用RTT来诊断网络连接的速度,可靠性以及拥塞程度。rtt计算webrtc的rtt计算分两种情况存在发送流,发送端估计。通过Sender Report(SR) 和Receiver Report(RR)计算只存在接收流,接收端估计。通过RTCP Extended ReportRTCP(XR)计算发送端RTT原创 2021-07-06 11:42:49 · 2561 阅读 · 0 评论 -
webrtc分析四(关键帧请求,FIR /PLI区别)
webrtc 关键帧请求分PLI,SLI,FIR。但是有何区别?PLI 是Picture Loss Indication图片丢失提示消息表明突发性的丢包影响到了一个或多个帧中的多个包。发送方可以通过重传这些包或者生成一个新的I帧以作出回应。但一般来说,PLI同时表现得像一个NACK和一个FIR,因此,通过使用PLI,接收端为发送端如何对该请求作出响应提供了更大的灵活度SLI 是Slice Loss Indication。切片丢失提示消息表明该包丢失影响到单个帧的部分(即,多个macroblock)。原创 2021-07-05 17:45:04 · 3879 阅读 · 6 评论 -
webrtc分析三(关键帧请求)
webrtc 采用rtp/rtcp传送音视频,网络存在丢包。采用fec和nack对抗丢包。但是并不是所有情况都能通过丢包重传解决。有些情况是在规定的时间内没有补上,再等就延时过大,失去补报的意义了。所以会采用请求关键帧的方式快速刷新。请求关键帧的场景1、新加入请求播放,无法初始化解码器2、丢包过多,jitterbuffer过大3、nack list过大4、获取帧数据超时5、解码出错需要初始化解码器,sps,ppsH264SpsPpsTracker::FixedBitstream H264Sp原创 2021-07-05 16:47:23 · 1778 阅读 · 0 评论 -
H.264中I帧和IDR帧的区别
IDR(Instantaneous Decoding Refresh)–即时解码刷新。转自:https://www.cnblogs.com/yinxiangpei/articles/3889865.html I和IDR帧都是使用帧内预测的。它们都是同一个东西而已,在编码和解码中为了方便,要首个I帧和其他I帧区别开,所以才把第一个首个I帧叫IDR,这样就方便控制编码和解码流程。IDR帧的作用是立刻刷新,使错误不致传播,从IDR帧开始,重新算一个新的序列开始编码。而I帧不具有随机访问的能力,这个功能是由I原创 2021-07-05 13:38:43 · 174 阅读 · 0 评论 -
webrtc分析二(video loopback)
webrtc 自带了好多测试用例看整体流程的有:peerconnection_client 和 peerconnection_server如果只看音视频互通流程的还是:video_llopback但是不巧的是,这个demo跑不起来,一跑就崩溃,分析一下原因,改造一下。原因:原因是 底层的消息循环接收到了不应该出现的消息,崩溃了为什么呢?原因是 demo把render的创建放到了task_queue里面了,而render是win32创建的窗口,这个窗口的消息循环就跟着在线程里面了,窗口原创 2021-07-01 10:14:08 · 465 阅读 · 3 评论 -
webrtc 分析一(windows编译)
webrtc 更新速度太快了,再一次分析一下源码吧。基于4484版本环境:windows10vs2019环境配置如官网变量设置set DEPOT_TOOLS_UPDATE=0set DEPOT_TOOLS_WIN_TOOLCHAIN=0set GYP_MSVS_VERSION=2019set GYP_MSVS_OVERRIDE_PATH =C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterpriseset GYP_GEN原创 2021-07-01 09:48:23 · 278 阅读 · 0 评论 -
webrtc的音视频同步处理二
webrtc音视频同步处理二主要代码在src/webrtc/video下video_receive_stream.ccrtp_streams_synchronizer.ccstream_synchronization.ccsyncable_video_ 同步的视频syncable_audio_ 同步的音频audio_measurement_ 存放音频timestamp和ntp对应关系video_measurement_ 存放视频timestamp和ntp对应关系sync_ 处理计算相对原创 2021-03-30 10:55:47 · 245 阅读 · 0 评论 -
webrtc的音视频同步处理一
webrtc的音视频同步处理一webrtc内部的音视频同步是怎么处理的?几个主要词:capture time,render time,rtp的 timestamp,sr,计算ntp先看视频的采集过程1、调用堆栈2、采集video_capture_impl.cc的 VideoCaptureImpl::IncomingFrame中调用set_timestamp_ms() 设置时间rtc::TimeMillis() 这个时间获取CLOCK_MONOTONIC:从系统启动这一刻起开始计原创 2021-03-29 16:14:26 · 656 阅读 · 0 评论 -
WebRTC使用H264编码,FEC状态
WebRTC 自诞生之日起, 就代表了实时通信领域的最好的技术. 不过很长时间里, 它所支持的视频编码器只有VP8, 后来随着H265/VP9为代表的下一代视频编码器的诞生, WebRTC里出现了VP9 Codec. 而当前应用最广泛的H264 却一直不受待见. 一直到Cisco 宣布旗下的H264 Codec开源为OpenH264, 并且替所有OpenH264的使用者支付了H264的专利费, 以次为契机, 在IETF的WebRTC会议中, 把H264和VP8都列入了WebRTC所必需要支持的视频编码器。转载 2020-09-25 17:36:34 · 2225 阅读 · 0 评论 -
webrtc 研究-音频编码
opus 编码参数src\webrtc_src\webrtc\modules\audio_coding\acm2 acm_codec_datebase.cc#ifdef WEBRTC_CODEC_OPUS // Opus internally supports 48, 24, 16, 12, 8 kHz. // Mono and stereo. { 120, "opus", 4800,原创 2016-12-08 13:45:14 · 2405 阅读 · 0 评论 -
webrtc 研究-带宽控制
带宽控制上行带宽控制 webrtc/modules/bitrate_controller 下行带宽估计 remote_bitrate_estimator原创 2016-12-06 18:34:48 · 2566 阅读 · 1 评论 -
webrtc研究-视频接收端处理
在call.h 里面有定义,我们把接收到的数据调用 DeliverPacket 即可class PacketReceiver { public: enum DeliveryStatus { DELIVERY_OK, DELIVERY_UNKNOWN_SSRC, DELIVERY_PACKET_ERROR, }; virtual DeliveryStatus Del原创 2016-12-12 11:48:18 · 3025 阅读 · 1 评论 -
WebRTC的拥塞控制技术(Congestion Control
http://www.jianshu.com/p/9061b6d0a9011. 概述对于共享网络资源的各类应用来说,拥塞控制技术的使用有利于提高带宽利用率,同时也使得终端用户在使用网络时能够获得更好的体验。在协议层面上拥塞控制是TCP的一个总要的组成部分;但是对于非面向链接的传输层协议,如UDP,其在协议层面上并没有对拥塞控制进行强制性的要求,这样做保证了最优的传输性能,且转载 2016-12-03 18:59:25 · 2150 阅读 · 0 评论 -
iOS 程序引入framework 类别报错unrecognized selector sent to class
背景在ios开发过程中,有时候会用到第三方的静态库(.a文件),然后导入后发现编译正常但运行时会出现selector not recognized的错误,从而导致app闪退。接着仔细阅读库文件的说明文档,你可能会在文档中发现诸如在Other Linker Flags中加入-ObjC或者-all_load这样的解决方法。 那么,Other Linker Flags到底是用来干什么的呢?还有-ObjC转载 2016-12-14 19:42:42 · 1087 阅读 · 0 评论 -
ios webrtc 编译 xcode7
export GYP_DEFINES="OS=ios target_arch=arm"export GYP_GENERATOR_FLAGS="output_dir=out_ios"webrtc/build/gyp_webrtc -Dclang_xcode=1ninja -C out_ios/Debug-iphoneos AppRTCDemo付:转载 2016-04-15 18:41:23 · 1490 阅读 · 0 评论 -
WebRTC VideoEngine超详细教程(二)——集成OPENH264编解码器
http://blog.csdn.net/nonmarking/article/details/47910043本系列目前共三篇文章,后续还会更新WebRTC VideoEngine超详细教程(一)——视频通话的基本流程WebRTC VideoEngine超详细教程(二)——集成OPENH264编解码器WebRTC VideoEngine超详细教转载 2015-09-17 16:48:58 · 8031 阅读 · 0 评论 -
WebRTC VideoEngine超详细教程(三)——集成X264编码和ffmpeg解码
http://blog.csdn.net/nonmarking/article/details/47958395本系列目前共三篇文章,后续还会更新WebRTC VideoEngine超详细教程(一)——视频通话的基本流程WebRTC VideoEngine超详细教程(二)——集成OPENH264编解码器WebRTC VideoEngine超详细教程(三)转载 2015-09-17 16:50:40 · 4718 阅读 · 0 评论 -
WebRTC VideoEngine超详细教程(一)——视频通话的基本流程
转自:http://blog.csdn.net/nonmarking/article/details/47375849本系列目前共三篇文章,后续还会更新WebRTC VideoEngine超详细教程(一)——视频通话的基本流程WebRTC VideoEngine超详细教程(二)——集成OPENH264编解码器WebRTC VideoEngine超详细教程(三转载 2015-09-17 16:46:23 · 14439 阅读 · 2 评论 -
Android之WebRTC介绍
Android之WebRTC介绍原文链接 : Introduction to WebRTC on Android原文作者 : Dag-Inge Aas译文出自 : appear.in译者 : DorisMinmin状态 :完成WebRTC被誉为是web长期开源开发的一个新启元,是近年来web开发的最重要创新。WebRTC允许Web开发者在其web应用中添加视频聊天或转载 2015-06-23 15:56:11 · 4393 阅读 · 1 评论 -
WebRTC中丢包重传NACK实现分析
http://www.jianshu.com/p/a7f6ec0c9273在WebRTC中,前向纠错(FEC)和丢包重传(NACK)是抵抗网络错误的重要手段。FEC在发送端将数据包添加冗余纠错码,纠错码连同数据包一起发送到接收端;接收端根据纠错码对数据进行检查和纠正。RFC5109[1]定义FEC数据包的格式。NACK则在接收端检测到数据丢包后,发送NACK报文到发送端;发送端根据NACK转载 2016-12-08 16:39:55 · 5158 阅读 · 0 评论 -
[webrtc] rtcp模块中rtt时间计算
RTT指 round-trip time,即计算AB两端的往返时延这里可以分成两个问题:如何在A端估算A和B之间的RTT时间?如何在B端估算A和B之间的RTT时间?本文参考资料: rfc 3550 rfc 3611 webrtc issue https://code.google.com/p/webrtc/issues/detail?id=1613 以及解决版本 https://code.转载 2016-12-09 19:53:49 · 2417 阅读 · 0 评论