flash网站效果常州网站建设最易

flash网站效果,常州网站建设最易,做刀网站,房地产中介网站RTCP: 统计、同步与网络自适应 本文是 WebRTC 系列专栏的第十三篇,将深入剖析 RTCP 协议的工作原理,包括 Sender/Receiver Report、网络质量反馈以及音视频同步机制。 目录 RTCP 概述RTCP 包类型Sender Report (SR)Receiver Report (RR)丢包、带宽与延迟分析音视频同步 (Lip-S…RTCP: 统计、同步与网络自适应本文是 WebRTC 系列专栏的第十三篇,将深入剖析 RTCP 协议的工作原理,包括 Sender/Receiver Report、网络质量反馈以及音视频同步机制。目录RTCP 概述RTCP 包类型Sender Report (SR)Receiver Report (RR)丢包、带宽与延迟分析音视频同步 (Lip-Sync)RTCP 反馈消息总结1. RTCP 概述1.1 什么是 RTCPRTCP (RTP Control Protocol) 是 RTP 的伴随协议,定义在 RFC 3550 中。RTCP 提供了带外控制信息,用于:传输统计信息(丢包率、延迟、抖动)同步多个媒体流标识参与者控制 RTP 会话1.2 RTCP 与 RTP 的关系------------------------------------------------------------------- | RTP 会话 | ------------------------------------------------------------------- | | | RTP 流 (媒体数据) | | ------------------------------------------ | | | Pkt 1 | Pkt 2 | Pkt 3 | Pkt 4 | Pkt 5 | Pkt 6 | ... | | ------------------------------------------ | | | | RTCP 流 (控制数据) | | -------- -------- -------- | | | SR | | RR | | SR | ... | | -------- -------- -------- | | | | 特点: | | - RTP 和 RTCP 使用相邻端口 (RTP偶数, RTCP奇数) | | - WebRTC 使用 RTCP-mux,复用同一端口 | | - RTCP 带宽通常限制在总带宽的 5% | | | -------------------------------------------------------------------1.3 RTCP 发送间隔RTCP 发送间隔计算: 基本原则: - RTCP 带宽 总带宽 * 5% - 最小间隔 5 秒 (可配置) - 发送者占 25%,接收者占 75% 计算公式: interval max(min_interval, (avg_rtcp_size * 8 * n) / rtcp_bw) 其中: - avg_rtcp_size: 平均 RTCP 包大小 - n: 参与者数量 - rtcp_bw: RTCP 带宽 WebRTC 优化: - 使用 Reduced-Size RTCP - 更频繁的反馈 (约 100ms)2. RTCP 包类型2.1 标准 RTCP 包类型类型值名称说明SR200Sender Report发送者报告RR201Receiver Report接收者报告SDES202Source Description源描述BYE203Goodbye离开通知APP204Application-defined应用自定义2.2 扩展 RTCP 包类型类型值名称说明RTPFB205Transport Layer FB传输层反馈PSFB206Payload-specific FB负载特定反馈XR207Extended Report扩展报告2.3 RTCP 包通用头部0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- |V2|P| RC | PTSR200 | length | -------------------------------- V: 版本 (2) P: 填充标志 RC: 报告计数 (或子类型) PT: 包类型 length: 长度 (32位字为单位,不含头部)2.4 复合 RTCP 包RTCP 包通常组合发送: ------------------------------------------------------ | SR | SDES | RR | ------------------------------------------------------ 规则: 1. 第一个包必须是 SR 或 RR 2. 必须包含 SDES (至少 CNAME) 3. 可以包含其他类型3. Sender Report (SR)3.1 SR 包结构0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- |V2|P| RC | PTSR200 | length | -------------------------------- | SSRC of sender | | NTP timestamp, most significant word | -------------------------------- | NTP timestamp, least significant word | -------------------------------- | RTP timestamp | -------------------------------- | senders packet count | -------------------------------- | senders octet count | | Report Block(s)... | --------------------------------3.2 SR 字段说明字段大小说明SSRC32 bits发送者的 SSRCNTP timestamp64 bitsNTP 时间戳 (绝对时间)RTP timestamp32 bits对应的 RTP 时间戳Packet count32 bits已发送的 RTP 包数量Octet count32 bits已发送的负载字节数3.3 NTP 时间戳NTP 时间戳格式: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- | Seconds | -------------------------------- | Fraction | -------------------------------- Seconds: 自 1900-01-01 00:00:00 的秒数 Fraction: 秒的小数部分 (2^32 分之一秒) 转换公式: ntp_time (seconds 32) fraction unix_time ntp_time - 2208988800 (1900到1970的秒数)3.4 NTP 与 RTP 时间戳的关系SR 提供了 NTP 和 RTP 时间戳的对应关系: 时间线: NTP: |-------|-------|-------|-------| T1 T2 T3 T4 RTP: |-------|-------|-------|-------| R1 R2 R3 R4 SR 报告: SR1: NTPT1, RTPR1 SR2: NTPT3, RTPR3 用途: 1. 计算 RTP 时间戳对应的绝对时间 2. 音视频同步 3. 延迟测量4. Receiver Report (RR)4.1 RR 包结构0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- |V2|P| RC | PTRR201 | length | -------------------------------- | SSRC of packet sender | | Report Block(s) | --------------------------------4.2 Report Block 结构0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- | SSRC_1 (SSRC of first source) | -------------------------------- | fraction lost | cumulative number of packets lost | -------------------------------- | extended highest sequence number received | -------------------------------- | interarrival jitter | -------------------------------- | last SR (LSR) | -------------------------------- | delay since last SR (DLSR) | --------------------------------4.3 Report Block 字段说明字段大小说明SSRC32 bits被报告的源 SSRCFraction lost8 bits自上次报告以来的丢包率Cumulative lost24 bits累计丢包数Extended highest seq32 bits收到的最高序列号Jitter32 bits到达间隔抖动LSR32 bits最后收到的 SR 时间戳DLSR32 bits收到 SR 后的延迟4.4 丢包率计算Fraction Lost 计算: fraction_lost (lost_interval * 256) / expected_interval 其中: expected_interval ext_max_seq - last_ext_max_seq received_interval received - last_received lost_interval expected_interval - received_interval 示例: 上次报告: ext_max_seq1000, received980 本次报告: ext_max_seq1100, received1070 expected_interval 1100 - 1000 100 received_interval 1070 - 980 90 lost_interval 100 - 90 10 fraction_lost (10 * 256) / 100 25 (约 10% 丢包)4.5 抖动计算Interarrival Jitter 计算: 对于每个收到的包 i: D(i,j) (Rj - Ri) - (Sj - Si) 其中: Ri, Rj: 包 i 和 j 的到达时间 Si, Sj: 包 i 和 j 的 RTP 时间戳 抖动更新: J(i) J(i-1) (|D(i-1,i)| - J(i-1)) / 16 这是一个指数加权移动平均,权重为 1/16// 抖动计算示例classJitterCalculator{constructor(clockRate){this.clockRateclockRate;this.jitter0;this.lastRtpTimestampnull;this.lastArrivalTimenull;}update(rtpTimestamp,arrivalTimeMs){if(this.lastRtpTimestamp!null){// 转换到相同单位 (RTP 时间戳单位)constarrivalDiff(arrivalTimeMs-this.lastArrivalTime)*this.clockRate/1000;constrtpDiffrtpTimestamp-this.lastRtpTimestamp;// 计算 DconstdMath.abs(arrivalDiff-rtpDiff);// 更新抖动 (指数加权)this.jitterthis.jitter(d-this.jitter)/16;}this.lastRtpTimestamprtpTimestamp;this.lastArrivalTimearrivalTimeMs;returnthis.jitter;}getJitterMs(){return(this.jitter/this.clockRate)*1000;}}5. 丢包、带宽与延迟分析5.1 丢包分析丢包类型: 1. 随机丢包 - 网络拥塞 - 无线信号差 2. 突发丢包 - 路由切换 - 缓冲区溢出 3. 周期性丢包 - 带宽竞争 - QoS 策略 丢包影响: - 音频: 卡顿、杂音 - 视频: 马赛克、花屏 - 关键帧丢失: 长时间花屏5.2 从 RTCP 提取丢包信息// 解析 Receiver ReportfunctionparseReceiverReport(data){constreports[];letoffset8;// 跳过头部constrcdata[0]0x1F;// 报告数量for(leti0;irc;i){constreport{ssrc:data.readUInt32BE(offset),fractionLost:data[offset4],packetsLost:(data[offset5]16)|(data[offset6]8)|data[offset7],highestSeq:data.readUInt32BE(offset8),jitter:data.readUInt32BE(offset12),lsr:data.readUInt32BE(offset16),dlsr:data.readUInt32BE(offset20)};// 计算丢包率百分比report.lossRate(report.fractionLost/256)*100;reports.push(report);offset24;}returnreports;}5.3 RTT 计算RTT (Round-Trip Time) 计算: 使用 SR/RR 中的 LSR 和 DLSR: 发送者 接收者 | | | SR (NTPT1) | | -------------------------------------- | | | | | 处理延迟 | | | RR (LSRT1, DLSRD) | | -------------------------------------- | | | | 收到 RR 时间 T2 | | | RTT T2 - LSR - DLSR 注意: - LSR 是 NTP 时间戳的中间 32 位 - DLSR 单位是 1/65536 秒// RTT 计算示例functioncalculateRTT(receivedTime,lsr,dlsr){// 将当前时间转换为 NTP 中间 32 位格式constnowgetNtpMiddle32(receivedTime);// DLSR 单位是 1/65536 秒constdlsrSecondsdlsr/65536;// LSR 是 NTP 中间 32 位constlsrSecondslsr/65536;constnowSecondsnow/65536;// 计算 RTTconstrttnowSeconds-lsrSeconds-dlsrSeconds;returnrtt*1000;// 返回毫秒}functiongetNtpMiddle32(unixTimeMs){// Unix 时间转 NTPconstntpSecondsunixTimeMs/10002208988800;constfraction(unixTimeMs%1000)/1000*0x10000;// 取中间 32 位return((ntpSeconds0xFFFF)16)|(fraction0xFFFF);}5.4 带宽估计基于 RTCP 的带宽估计: 1. 从 SR 获取发送速率 send_rate (octet_count_diff * 8) / time_diff 2. 从 RR 获取丢包率 loss_rate fraction_lost / 256 3. 调整发送码率 if (loss_rate threshold) { reduce_bitrate(); } else if (loss_rate threshold rtt limit) { increase_bitrate(); } WebRTC 使用更复杂的算法: - Google Congestion Control (GCC) - 基于延迟的带宽估计 - Transport-wide CC6. 音视频同步 (Lip-Sync)6.1 同步问题音视频不同步的原因: 1. 采集时间差 - 音频和视频设备独立采集 - 采集延迟不同 2. 编码时间差 - 视频编码比音频慢 - 关键帧编码更慢 3. 网络传输差异 - 不同的丢包和延迟 - 不同的抖动 4. 解码和渲染差异 - 视频解码更复杂 - 缓冲策略不同6.2 同步机制使用 RTCP SR 进行同步: 音频流: SR: NTPT1, RTP_audioA1 NTPT2, RTP_audioA2 视频流: SR: NTPT1, RTP_videoV1 NTPT2, RTP_videoV2 同步计算: 1. 从 SR 建立 NTP-RTP 映射 audio: NTP f(RTP_audio) video: NTP g(RTP_video) 2. 将两个流的 RTP 时间戳转换为 NTP ntp_audio f(rtp_audio) ntp_video g(rtp_video) 3. 计算时间差 diff ntp_video - ntp_audio 4. 调整播放时间 if (diff 0) delay_video(); else delay_audio();6.3 同步实现classLipSync{constructor(){this.audioMappingnull;// {ntp, rtp, clockRate}this.videoMappingnull;}// 收到 SR 时更新映射updateSR(ssrc,ntpTimestamp,rtpTimestamp,isAudio){constmapping{ntp:ntpTimestamp,rtp:rtpTimestamp,clockRate:isAudio?48000:90000};if(isAudio){this.audioMappingmapping;}else{this.videoMappingmapping;}}// 将 RTP 时间戳转换为 NTPrtpToNtp(rtpTimestamp,mapping){if(!mapping)returnnull;constrtpDiffrtpTimestamp-mapping.rtp;constntpDiffrtpDiff/mapping.clockRate;returnmapping.ntpntpDiff;}// 计算音视频偏移calculateOffset(audioRtp,videoRtp){if(!this.audioMapping||!this.videoMapping){return0;}constaudioNtpthis.rtpToNtp(audioRtp,this.audioMapping);constvideoNtpthis.rtpToNtp(videoRtp,this.videoMapping);if(!audioNtp||!videoNtp)return0;// 返回偏移量 (秒)// 正值表示视频超前,需要延迟视频// 负值表示音频超前,需要延迟音频returnvideoNtp-audioNtp;}// 获取播放延迟调整getPlayoutDelay(audioRtp,videoRtp){constoffsetthis.calculateOffset(audioRtp,videoRtp);return{audioDelay:offset0?-offset*1000:0,videoDelay:offset0?offset*1000:0};}}6.4 CNAME 的作用CNAME (Canonical Name) 用于关联同一参与者的多个流: SDES 包中的 CNAME: ------------------ | SSRC 1001 | 音频流 | CNAME userx | ------------------ ------------------ | SSRC 2002 | 视频流 | CNAME userx | ------------------ 同步流程: 1. 收到 RTP 包,记录 SSRC 2. 收到 SDES,获取 CNAME 3. 根据 CNAME 关联音视频流 4. 使用 SR 进行同步7. RTCP 反馈消息7.1 RTCP-FB 类型传输层反馈 (RTPFB, PT205): ---------------------------------------------- | FMT | 名称 | 说明 | ---------------------------------------------- | 1 | NACK | 丢包重传请求 | | 3 | TMMBR| 临时最大媒体码率请求 | | 4 | TMMBN| 临时最大媒体码率通知 | | 15 | TCC | Transport-wide CC | ---------------------------------------------- 负载特定反馈 (PSFB, PT206): ---------------------------------------------- | FMT | 名称 | 说明 | ---------------------------------------------- | 1 | PLI | Picture Loss Indication | | 2 | SLI | Slice Loss Indication | | 3 | RPSI | Reference Picture Selection | | 4 | FIR | Full Intra Request | | 15 | AFB | Application Layer FB | ----------------------------------------------7.2 NACK (Negative Acknowledgement)NACK 用于请求重传丢失的包: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- |V2|P| FMT1 | PT205 | length | -------------------------------- | SSRC of packet sender | -------------------------------- | SSRC of media source | -------------------------------- | PID | BLP | -------------------------------- PID: 丢失的包序列号 BLP: 位图,表示 PID1 到 PID16 的丢包情况 示例: PID 1000, BLP 0x0005 (二进制: 0000000000000101) 表示丢失: 1000, 1001, 10037.3 PLI (Picture Loss Indication)PLI 请求发送关键帧: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- |V2|P| FMT1 | PT206 | length | -------------------------------- | SSRC of packet sender | -------------------------------- | SSRC of media source | -------------------------------- 使用场景: 1. 检测到关键帧丢失 2. 新参与者加入 3. 解码错误7.4 FIR (Full Intra Request)FIR 强制请求关键帧: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- |V2|P| FMT4 | PT206 | length | -------------------------------- | SSRC of packet sender | -------------------------------- | SSRC of media source | -------------------------------- | SSRC | -------------------------------- | Seq nr. | Reserved | -------------------------------- FIR vs PLI: - PLI: 提示性请求,发送者可以忽略 - FIR: 强制请求,发送者必须响应7.5 REMB (Receiver Estimated Maximum Bitrate)REMB 用于接收端带宽估计: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 -------------------------------- |V2|P| FMT15 | PT206 | length | -------------------------------- | SSRC of packet sender | -------------------------------- | SSRC of media source | -------------------------------- | Unique identifier R E M B | -------------------------------- | Num SSRC | BR Exp | BR Mantissa | -------------------------------- | SSRC feedback | -------------------------------- 带宽计算: bitrate mantissa * 2^exp (bps)7.6 Transport-wide CCTransport-wide CC 提供更精确的拥塞控制: 特点: 1. 为每个 RTP 包分配传输序列号 2. 接收端报告每个包的到达时间 3. 发送端计算单向延迟变化 4. 更快速的带宽调整 RTP 扩展头: ------------------ | Transport Seq Nr | 16 bits ------------------ RTCP 反馈: 包含每个传输序列号的到达时间8. 总结8.1 RTCP 核心要点要点说明SR发送者统计和时间戳映射RR接收质量报告丢包率fraction_lost / 256抖动指数加权移动平均RTTT2 - LSR - DLSR同步使用 NTP-RTP 映射8.2 RTCP 反馈机制丢包恢复: NACK - 重传丢失的包 关键帧请求: PLI/FIR - 发送新的关键帧 带宽调整: REMB/TCC - 调整发送码率8.3 下一篇预告在下一篇文章中,我们将深入探讨 SRTP 协议,包括:DTLS 握手过程SRTP 密钥导出加密与解密流程参考资料RFC 3550 - RTP: A Transport Protocol for Real-Time ApplicationsRFC 4585 - Extended RTP Profile for RTCP-Based FeedbackRFC 5104 - Codec Control Messages in AVPFdraft-alvestrand-rmcat-remb - REMB