WEBRTC 实时视频传输中的RTCP协议码率控制报文
来源:互联网 发布:c类网络借3位子网划分 编辑:程序博客网 时间:2024/06/17 09:17
流媒体传输中常用的RTCP包主要有SR/RR/SDES/BYE/APP/XR,主要由RFC 3611和RFC 3550定义。
而WEBRTC视频中常用的RTCP包比语音要多很多,语音的RTCP主要用于状态传递,统计数据。而视频中的RTCP更多赋予了控制功能,比如关键帧请求,码率控制等等。
本文不介绍语音中的RTCP,只介绍视频中的RTCP包。
这些报文遵守RFC4585和RFC5104协议。
第一类:关键帧请求
主要包括SLI/PLI/FIR,作用是在关键帧丢失无法解码时,请求发送方重新生成并发送一个关键帧。
这本质是一种重传,但是跟传输层的重传的区别是,它重传是最新生成的帧。
PLI 是Picture Loss Indication,SLI 是Slice Loss Indication。
发送方接收到接收方反馈的PLI或SLI需要重新让编码器生成关键帧并发送给接收端。
FIR 是Full Intra Request,这里面Intra的含义可能很多人不知道。
Intra的含义是图像内编码,不需要其他图像信息即可解码;Inter指图像间编码,解码需要参考帧。
故Intra Frame其实就是指I帧,Inter Frame指P帧或B帧。
那么为什么在PLI和SLI之外还需要一个FIR呢?
原因是使用场景不同,FIR更多是在一个中心化的Video Conference中,新的参与者加入,就需要发送一个FIR,其他的参与者给他发送一个关键帧这样才能解码,
而PLI和SLI的含义更多是在发生丢包或解码错误时使用。
第二类:重传请求
主要包括RTX/NACK/RPSI
这个重传跟关键帧请求的区别是它可以要求任意帧进行重传
第三类:码率控制
主要包括REMB/TMMBR/TMMBN
TMMBR是Temporal Max Media Bitrate Request,表示临时最大码率请求。表明接收端当前带宽受限,告诉发送端控制码率。
REMB是ReceiverEstimated Max Bitrate,接收端估计的最大码率。TMMBN是Temporal Max Media Bitrate Notification
- WEBRTC 实时视频传输中的RTCP协议码率控制报文
- Webrtc(7) 实时视频传输中的RTCP协议
- 实时传输协议 [RTP] 和 实时控制协议 [RTCP]
- 实时传输协议 RTCP
- [zz]实时传输协议 RTCP
- RTP/RTCP(实时传输协议/实时传输控制协议)自定义的相关C结构(参考)
- RTP/RTCP(实时传输协议/实时传输控制协议)自定义的相关C结构(参考)
- RTP/RTCP(实时传输协议/实时传输控制协议)自定义的相关C结构(参考)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 【转】实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- 实时传输协议(RTP)和实时控制协议(RTCP)
- css3
- nuitka用法
- POJ 2247 Humble Numbers 笔记
- Swift之自定义UICollectionViewCell
- jquery
- WEBRTC 实时视频传输中的RTCP协议码率控制报文
- Android Studio中导出数据库文件的方法以及出现Failed to pull selection: open failed: Permission denied的解决思路
- bzoj1811: [Ioi2005]mea
- 最小费用最大流算法(SPFA邻接矩阵)
- 【题解】洛谷P2740 poj1273 [USACO4.2]草地排水Drainage Ditches
- 通用Excel导出Demo
- CentOS7.3编译安装Nginx1.10.1
- 二级连动
- PHP图片水印类(GD库)