八 WebRTC 关键帧请求PLI与FIR

本文介绍了WebRTC中关键帧请求的场景,包括H264解码无sps,pps信息、丢包过多、获取帧数据超时和解码出错。重点讲解了PLI和FIR的区别,PLI用于通知编码端数据丢失,而FIR则用于刷新解码端,例如在切换视频或新用户加入视频会议时。" 108029463,9800833,理解交换机配置与路由技术,"['网络', '交换机', '路由技术']
摘要由CSDN通过智能技术生成

目录

一 关键帧请求场景

二 PLI与FIR


前言: IDR Request

 关键帧也叫做即时刷新帧,简称IDR帧。对视频来说,IDR帧的解码无需参考之前的帧,因此在丢包严重时可以通过发送关键帧请求进行画面的恢复。关键帧的请求方式分为三种:RTCP FIR反馈(Full intra frame request)、RTCP PLI 反馈(Picture Loss Indictor)或SIP Info消息,具体使用哪种可通过协商确定.


一 关键帧请求场景

1.1 H264解码无sps,pps信息

H264SpsPpsTracker::PacketAction H264SpsPpsTracker::CopyAndFixBitstream()


2.1 丢失包过多

在非常高的丢包率情况下,丢失的包太多,若都一一重传,将造成延时增大(等帧数据完整了才会去解码渲染),此时新来的数据也只能一直缓存,所以jitterbuffer大小也会不断增大,此时不如直接请求发送一个关键帧来得实际,以前丢的那些包都不管了,由于关键帧可以单独解码,所以不会造成解码端花屏马赛克现象。但是由于前面那些视频帧都丢弃了,此时生成的关键帧会与之前播放的视频存在不连贯性,所以画面变化大时会有轻微卡顿现象,相当于跳帧了。NackModule中相关处理代码如下:

void NackModule::AddPacketsToNack


3

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值