当前位置：首页 > news >正文

音视频中一些常见的知识点

news 2025/7/26 10:41:46

1. GCC是如何进行带宽评估的

GCC（Google Congestion Control）是一种专为实时音视频传输设计的拥塞控制算法，它主要通过发送端和接收端的协同工作来进行带宽评估。具体过程如下：
接收端处理

计算延迟梯度：接收端通过统计数据包到达时间的变化，即 RTT（往返时间）波动，来计算网络中的排队延迟，这个排队延迟的变化率就是延迟梯度。例如，若连续多个数据包的到达时间间隔逐渐增大，说明排队延迟在增加，延迟梯度为正且数值可能逐渐变大。
反馈信息：接收端将计算得到的延迟梯度和丢包信息封装到 ACK（确认）报文中，反馈给发送端。这些信息将作为发送端调整发送速率和进行带宽评估的重要依据。
基于延迟的带宽估计（部分版本）：在 REMB - GCC 版本中，接收端会通过一系列模块进行基于时间延时梯度的带宽评估。其中，Arrival filter 利用卡尔曼滤波器，通过测量得到的相邻两帧接收时间差和发送时间差的间隔（dm_i）以及两相邻包的大小差（dL_i），估算出网络队列延时深度变化估计（m_i）。Adaptive threshold 模块根据 m_i 定时更新阈值 γi，Overuse Detector 模块再根据 m_i 和 γi 评估当前网络是否处于过载状态，最后 Remote Rate Controller 模块根据网络过载状态调整带宽，并通过 REMB RTCP 包反馈到发送端。

发送端处理

基于丢包的带宽估计：发送端根据从接收端反馈的 RTCP 协议的 Receive Report 包中的 lost fraction 字段获取丢包率。当丢包率大于 10% 时，认为网络有拥塞，降低带宽；当丢包率小于 2% 时，认为网络状况好，向上提高 5% 的带宽以探测是否有更多带宽可用；丢包率在 2% 到 10% 之间时，保持当前码率不变。
带宽估计与速率控制：发送端持续测量网络的可用带宽，具体是通过接收端 ACK 的到达速率来维护一个带宽估计值（BtlBw）。结合接收端反馈的延迟梯度信号，发送端动态调整发送速率。若延迟梯度增大，表明网络拥塞，发送端降低发送速率；若带宽估计提升且延迟稳定，发送端则尝试增加速率以充分利用带宽。
带宽探测：发送端会通过发送 probe 数据包来探测网络带宽。发送端发送出 probe cluster（探测包集群），接收端通过 transport - wide congestion control rtcp feedback message（传输层拥塞控制 RTCP 反馈消息）告知发送端每个数据包的到达时间。发送端根据这些反馈，调用 probe bitrate estimator::handle probe and estimate bitrate 函数来计算探测包集群的发送间隔、接收间隔、发送速率和接收速率等。若接收速率明显低于发送速率，说明可能达到了链路的真实容量，此时会将目标比特率设置得稍低一些。

2. udp在什么场景下连不通

UDP（用户数据报协议）是一种无连接、不可靠的传输层协议，其 “连不通” 通常表现为数据包丢失、无法到达目标或通信中断。这种情况可能由多种网络环境、协议特性或配置问题导致，以下是常见的场景及原因分析：

一、网络层或链路层故障
UDP 依赖底层网络（如 IP 层、链路层）的正常工作，底层故障会直接导致通信失败：

路由不可达：目标主机的 IP 地址在网络中没有有效路由（如路由表配置错误、跨网段通信缺少网关），数据包在传输过程中被丢弃，无法到达目标。
链路中断：物理链路（如网线断开、无线信号丢失）或数据链路层协议（如以太网冲突、PPP 链路断开）故障，导致数据包无法在链路上传输。
MTU 不匹配：若 UDP 数据包大小超过路径 MTU（最大传输单元）且未开启分片（或分片后重组失败），数据包会被中间路由器丢弃。例如，发送一个 1500 字节的 UDP 包到 MTU 为 1400 的网络，且未分片时，包会被直接丢弃。

二、防火墙或安全策略拦截
UDP 无连接的特性使其更容易被防火墙拦截，这是实际应用中 “连不通” 的常见原因：

端口过滤：目标主机或中间防火墙（如路由器、企业防火墙）配置了端口封锁策略，拦截了 UDP 目标端口（如未开放 5060 端口导致 SIP 协议通信失败）。
协议禁用：部分严格的安全策略会直接禁用 UDP 协议（如某些内网为防止 DDOS 攻击，禁止所有 UDP 流量），导致所有 UDP 数据包被拦截。
状态检测防火墙的限制：部分状态检测防火墙对 UDP 的 “无状态” 特性不友好，若未配置 UDP 会话超时规则，可能误判 UDP 流量为非法并拦截（如短暂通信后被防火墙切断）。

三、网络拥塞或 QoS 限制

拥塞丢包：UDP 不具备 TCP 的拥塞控制机制，在网络拥塞时，路由器会优先丢弃 UDP 包（因 TCP 会重传，而 UDP 丢包后无补救），导致通信中断。例如，视频会议的 UDP 流在网络繁忙时可能频繁卡顿甚至断开。
QoS（服务质量）优先级低：若网络设备配置了 QoS 策略，UDP 流量可能被分配到低优先级队列，当带宽不足时，低优先级 UDP 包会被优先丢弃，导致 “连不通” 或丢包严重。

四、目标主机问题

端口未监听：目标主机的 UDP 端口未被应用程序监听（如服务未启动、端口被占用），数据包到达后无进程处理，且不会返回任何响应（UDP 无 “连接失败” 通知），表现为 “连不通”。
主机不可达：目标主机断电、崩溃或处于离线状态，数据包无法送达，此时可能收到 ICMP “目标不可达” 消息（但非所有场景都会返回）。

五、NAT 或代理的影响

NAT 会话超时：在私有网络（如家庭 WiFi）通过 NAT 访问公网时，NAT 设备会为 UDP 会话维护临时映射表。若 UDP 通信间隔超过 NAT 超时时间（通常几十秒到几分钟），映射表被删除，后续数据包会被 NAT 丢弃，导致通信中断（如 VoIP 通话长时间静音后断线）。
代理服务器限制：部分代理服务器（如企业内网代理）可能不支持 UDP 转发，或对 UDP 端口、流量大小有限制，导致数据包被代理拦截。

六、协议自身特性导致的 “感知不到的不通”
UDP 无确认机制，即使数据包丢失，发送端也不会收到通知，可能被误认为 “连不通”：
例如，发送端向目标 UDP 端口发送数据，但数据包在传输中丢失，发送端无法得知失败，仅表现为 “没有响应”，类似 “连不通” 的效果。
若目标主机收到数据包但处理出错（如应用程序崩溃），也不会返回错误信息，发送端同样感知不到通信成功。

3. SDP 里面存储了哪些内容

SDP（Session Description Protocol，会话描述协议）是一种用于描述多媒体会话的格式，主要用于协商会话的参数（如媒体类型、编码格式、传输协议、网络地址等），以便不同设备或应用之间建立多媒体通信（如音视频通话、流媒体传输等）。

SDP 存储的核心内容
SDP 由一系列 “键 = 值” 形式的字段组成，按功能可分为会话级描述（整个会话的通用信息）和媒体级描述（每个媒体流的具体信息），核心内容包括：
1. 会话级描述（适用于整个会话）

v=：SDP 版本号（目前固定为 0）。
o=：会话发起者信息，包括用户名、会话 ID、会话版本、网络类型（通常是 IN 表示互联网）、地址类型（IP4 或 IP6）、发起者 IP 地址。
s=：会话名称（如 “视频会议 - 项目组周会”）。
i=：会话描述信息（可选，如会话的详细说明）。
u=：会话相关的 URI（可选，如会议的网页链接）。
e=：会话联系人邮箱（可选）。
p=：会话联系人电话（可选）。
c=：连接信息，包括网络类型、地址类型、连接地址（如 IP 地址），可被媒体级描述覆盖。
b=：带宽限制（可选，如会话的总带宽）。
t=：会话的开始和结束时间（格式为 NTP 时间戳，0 表示永久会话）。
r=：重复会话的规则（可选，如每天 9 点重复）。
z=：时区调整（可选，用于修正开始 / 结束时间的时区偏移）。
k=：加密密钥（可选，用于会话加密）。

2. 媒体级描述（每个媒体流的具体参数）
每个媒体流通过 m= 字段开始，后续字段描述该媒体的细节：

m=：媒体类型（如 audio 音频、video 视频、application 应用数据等）、传输端口、传输协议（如 RTP/AVP 表示 RTP 协议 + AVP 载荷格式）、支持的载荷类型（如 0 表示 PCMU 音频编码）。

例如：
m=audio 5004 RTP/AVP 0 8：表示一个音频流，使用端口 5004，基于 RTP/AVP 协议，支持载荷类型 0（PCMU）和 8（PCMA）。
m=video 5006 RTP/AVP 97 98：表示一个视频流，使用端口 5006，支持载荷类型 97、98（对应具体视频编码，如 H.264）。

i=：媒体的描述信息（可选，如 “麦克风音频”）。
c=：媒体的连接信息（覆盖会话级的 c= 字段）。
b=：媒体的带宽限制（覆盖会话级的 b= 字段）。
k=：媒体的加密密钥（覆盖会话级的 k= 字段）。
a=：属性字段（最关键的扩展字段），用于补充媒体的细节，如：
- 编码格式（如 a=rtpmap:0 PCMU/8000 表示载荷类型 0 对应 PCMU 编码，采样率 8000Hz）。
- 方向控制（如 a=sendrecv 表示发送和接收，a=recvonly 表示仅接收）。
- 带宽约束（如 a=bandwidth:AS=512 表示应用层带宽 512kbps）。

M字段详解：

m=<媒体类型> <端口> <传输协议> <载荷类型列表>

媒体类型（Media Type）
指定媒体流的类型，常见值包括：

audio：音频流（如麦克风输入）
video：视频流（如摄像头输入）
text：文本流（如实时字幕）
application：应用数据（如控制信令）
message：消息流（如即时消息）

端口（Port）
表示接收该媒体流的传输层端口号（通常是 UDP 端口，因多媒体传输常用 UDP）。

若媒体使用 RTP 协议，此端口通常为 RTP 数据端口，对应的 RTCP 控制端口一般为该端口 +1。
示例：m=audio 5004 … 表示音频流通过端口 5004 接收，RTCP 可能使用 5005 端口。

传输协议（Transport Protocol）
指定传输该媒体流使用的协议，常见值包括：

RTP/AVP：基于 UDP 的 RTP 协议（AVP 表示音频 / 视频载荷格式），是实时音视频的主流选择。
RTP/SAVP：带加密的 RTP 协议（用于需要安全传输的场景）。
UDP：直接使用 UDP 传输（较少见，通常用于非 RTP 格式的媒体）

载荷类型列表（Payload Types）
一系列数字，代表该媒体流支持的载荷类型（每个数字对应一种编码格式）。

这些数字需结合 SDP 中的 a=rtpmap: 属性字段，才能映射到具体的编码格式（如音频的 PCMU、视频的 H.264 等）。
示例：m=audio … 0 8 表示支持载荷类型 0 和 8，后续可通过 a=rtpmap:0 PCMU/8000 说明 0 对应 PCMU 编码（8000Hz 采样率）。

一个典型的 m= 字段示例：

m=video 5006 RTP/AVP 97 98
a=rtpmap:97 H264/90000
a=rtpmap:98 VP8/90000

含义：这是一个视频流（video），通过端口 5006 接收，使用 RTP/AVP 协议传输，支持载荷类型 97 和 98。
结合 a=rtpmap 可知：97 对应 H.264 视频编码（90000Hz 时钟频率），98 对应 VP8 视频编码。

总结：m= 字段是 SDP 中描述媒体流的 “入口”，通过它可以快速了解媒体的基本传输属性，后续再结合其他字段（如 a=）获取更详细的编码、带宽等信息。

4. ICE Candidate 里面存储了哪些内容

ICE（Interactive Connectivity Establishment，交互式连接建立）中的 Candidate（候选地址）是用于在 NAT（网络地址转换）环境下建立点对点（P2P）连接的关键信息。每个 ICE Candidate 包含一组描述网络端点的参数，用于协商两端之间的最佳通信路径。
ICE Candidate 存储的核心内容如下：