简介围绕G.711音频编码在RTP实时传输中的封装实现这份资料面向学习VoIP、实时音频流与网络协议栈的开发者及通信方向学生帮助理解G.711的μ-law/A-law编码数据如何按RTP头结构打包并通过UDP发送后由VLC接收播放。压缩包共4个文件以1个C语言源码、1个SDP会话描述文件、1个G.711音频样本和1个说明文本组成整体约2.16MB便于从代码、会话描述到测试素材对照理解封装链路。已有1486人学习说明该主题在实时音频传输入门中具有一定关注度。读者可重点参考源码中的RTP序列号、时间戳与载荷组织方式结合SDP描述建立接收端连接并用样本音频验证播放效果从而把编码格式、传输协议与播放器支持串成一条可复现的学习线索。1. 64 kbps 的语音为什么只装 160 字节G711 与 RTP 的接缝在哪G711 是语音编码里最没有「协议感」的一种一个采样点就是 8 个比特采样率 8000 Hz 固定下来没有帧头、没有同步字、没有编码参数协商编码器本身甚至没有状态。也正因如此把它封装进 RTP 传输时真正决定通话好不好听的从来不是编码器而是那 12 个字节的 RTP 头和一个抖动缓冲——编码端把复杂度压到了极致剩下的复杂度全部被推给了传输层。20 ms 的语音负载是 160 字节配上 RTP、UDP、IP 头一共 200 字节开销 20%看着还算划算代价是 G711 对丢包和时钟漂移零容忍任何一个字节的错位都会直接变成耳朵里的噪声不像带帧同步的编码那样能悄悄自愈。搞清这条接缝在哪绝大多数「能通但不好听」的故障都能被解释。2. G.711 的对数压缩8 bit 凭什么装下 13 bit 的动态范围2.1 折线量化不是线性也不是真正的对数要理解 G711 为什么长这样得先看语音信号的幅度分布。人耳对响度的感知近似对数关系而语音能量高度集中在低电平区间——一个人说话的峰值因数常在 12 dB 以上大量时间信号都趴在满量程以下二三十分贝的位置。如果直接用 8 bit 做线性量化理论信噪比只有 48 dB 左右小音量段的量化噪声会直接盖过语音听感上就是「沙沙」的底噪压不住。解决办法是把量化做成非均匀的小信号步长细大信号步长粗用 8 bit 去承载大约 13 到 14 bit 的有效动态范围。理想情况当然是用一条真正的对数曲线但那个年代的硬件做一次对数运算要动用乘法器和查表成本和延迟都不划算于是工程上退了一步用 8 段折线去逼近对数曲线每一段内部步长恒定段与段之间步长翻倍。μ-law 的第一段步长是 2以 14 bit 输入计算到最后一段变成 256每段内部再切 16 个量化级加上 1 位符号位正好凑满 8 bit。A-law 的结构相同只是输入按 13 bit 处理折线斜率序列不一样。这样一压8 bit 对数 PCM 的信噪比能到 35 到 38 dB主观 MOS 在 4.1 上下勉强够电话用。特性μ-lawPCMUA-lawPCMARTP 静态载荷类型08有效输入位宽14 bit13 bit折线段数8 段段内 16 级8 段段内 16 级静音码字0xFF0xD5编码后处理按位取反与 0x55 异或两套律互不兼容这是血泪经验里最容易被忽略的一条SDP 里协商成 PCMU实际发的是 PCMA 码流接收端解出来就是满耳噪声而且音量还不小很容易被误判成「网络丢包」。谁也别猜靠信令说清楚。2.2 从公式到查表一次编码只有移位和加法折线量化最大的好处是可实现性。编码路径上不需要浮点不需要除法核心动作只有三个取绝对值拿到符号位、找最高有效位确定段号、在段内取 4 位尾数。解码更简单直接查一张 256 项的 16 bit 表一个字节进、两个字节出。下面这段 Python 是 μ-law 编码和解码的完整实现逻辑和嵌入式里的 C 版本一一对应BIAS 0x84 # 132保证段 0 内有正确的量化偏移 CLIP 32635 # 超过这个值直接饱和避免移位溢出 def linear_to_ulaw(sample: int) - int: 16bit 有符号线性 PCM - 8bit μ-law sign 0x80 if sample 0 else 0x00 sample -sample if sample 0 else sample sample 32767 if sample 32767 else sample # -32768 取反后越界 sample CLIP if sample CLIP else sample sample BIAS # 段号 最高有效位位置 - 8值域恰好落在 0..7 exponent sample.bit_length() - 8 # 段内 4 位尾数右移到该段最低位再截低 4 位 mantissa (sample (exponent 3)) 0x0F # 取反是为了消灭长连 0同时让静音有确定码字 0xFF return ~(sign | (exponent 4) | mantissa) 0xFF def ulaw_to_linear(u: int) - int: 8bit μ-law - 16bit 有符号线性 PCM u ~u 0xFF sign u 0x80 exponent (u 4) 0x07 mantissa u 0x0F sample ((mantissa 3) BIAS) exponent sample - BIAS return -sample if sign else sampleBIAS的作用常被误解成「加个直流」实际上它是为了让段 0 的量化台阶对齐不加偏置时0 附近的编码会出现两次相邻输入映射到同一码字、而 0 和 1 又跳到不同码字的情况解码回来的波形在过零点附近会有台阶感听感上是轻微的「毛刺」。加上 132 之后台阶分布均匀了代价是最大可表示幅度被压掉一点点所以需要CLIP兜底。A-law 的编码多两步输入先右移 3 位压到 13 bit负数按反码处理-sample - 1最后异或0x55。这个0x55是交替位翻转目的是让数字链路上不出现长连 0有利于对端时钟恢复副作用是静音码字从0x00变成了0xD5。解码时先异或回来再按段展开def linear_to_alaw(sample: int) - int: 16bit 有符号线性 PCM - 8bit A-law sample 3 # 16bit 有效位压到 13bit if sample 0: mask 0xD5 # 符号位 0 交替翻转 0x55 else: mask 0x55 sample -sample - 1 # A-law 负数按反码规则处理 sample 0x0FFF if sample 0x0FFF else sample # 段 0 覆盖 0..31步长 2段 1..7 从 32 起每段翻倍 seg 0 if sample 32 else min(sample.bit_length() - 5, 7) offset (sample (seg 1)) 0x0F return ((seg 4) | offset) ^ mask def alaw_to_linear(a: int) - int: a ^ 0x55 seg (a 4) 0x07 mant a 0x0F if seg 0: val (mant 1) | 1 # 段 0 只有 16 级步长 2 else: val ((mant 1) | 0x21) (seg - 1) return -val if (a 0x80) else val这两段代码里没有一次乘除全部是移位、掩码和加法这就是它能跑在 8 位单片机上的原因。真实产品里通常把解码改成一张 256 项的静态表运行时只做一次数组索引编码侧如果 MCU 连bit_length这类指令都没有就用一张 256 项的exp_lut把「找最高有效位」这一步也查表化。这是典型的用 256 字节 ROM 换几十个时钟周期的交易。2.3 字节序与位宽RTP 负载里根本没有「字节序」这回事G711 的负载是一字节一个采样不存在多字节样本所以 RTP 层面完全没有大小端问题。但采集侧几乎总是 16 bit 小端 PCM中间隔着一层转换这里翻车的人特别多。第一种翻车是把 16 bit 线性 PCM 原样塞进负载。带宽从 64 kbps 直接翻到 128 kbps接收端把每个 16 bit 样本拆成两个 8 bit 码字去解解出来的波形是原信号的「噪声化」版本听感上像尖锐的啸叫混着白噪声。判断方法很简单抓包看负载长度20 ms 的包应该是 160 字节如果是 320 字节基本可以确定漏了编码这一步。第二种翻车是解码后没补齐位宽。μ-law 解出来是 14 bit 量级的值A-law 解出来是 13 bit 量级直接当 16 bit 送去播放音量会小 12 到 18 dB。很多开发者第一反应是「加个增益」结果在响度大的片段上削顶失真。正确做法是在解码表里就把值左移到位μ-law 左移 2A-law 左移 3并且用饱和加法而不是回绕。第三种更隐蔽负数取反溢出。-(-32768)在 16 bit 有符号里还是-32768如果不做钳位编码结果会在最大负幅度处突然跳变听感上是很轻的一声「啪」单次通话里可能只出现几次极难复现。上面代码里那句sample 32767 if sample 32767 else sample就是给这个坑打的补丁。3. RTP 头的十二个字节语音场景里每个字段该填什么3.1 版本、填充、扩展、CSRC 计数四个平时是常量的字段RTP 固定头 12 字节前两个字节被切得很碎2 位版本、1 位填充标志、1 位扩展标志、4 位 CSRC 计数然后是 1 位标记位加 7 位载荷类型。单路 G711 通话里版本恒为 2填充为 0扩展为 0CSRC 计数为 0第一字节就是0x80。这四个字段平时是常量一旦被打破就容易出问题。扩展位设成 1 却没有正确填写扩展头的长度字段解析方会按错误的偏移去读负载整包错位解出来是纯噪声。CSRC 计数在会议混音场景会变成非零——混音服务器把多路源混合后用 CSRC 列表告诉接收端「这一包里混了哪些源」接收端靠它做语音活动显示或者 selective forwarding。如果混音侧填了 CSRC 但没同步调整头长度同样整包错位。写解析器时有个习惯值得养成先把CC字段读出来把头长度算成12 4 * CC再去取负载。不要假设头永远是 12 字节这个假设在纯点对点场景能跑一年接到第一个混音环境就崩。3.2 序列号与时间戳两个计数器分别回答「丢了没」和「什么时候播」序列号是 16 位每发一个包加一回绕到 0 再继续。它的唯一职责是让接收端检测丢包和重排序。这里有个细节比较两个序列号不能直接用大小于必须用 16 位有符号差值。比如65535和0直接比大小会得出「倒退了 65535」的错误结论而(int16)(0 - 65535) 1才是对的。这个错误在长时间通话里必然出现因为 20 ms 一个包65536 个包大约 22 分钟就绕一圈。时间戳是 32 位单位是采样数G711 的时钟频率就是 8000 Hz。20 ms 一个包时间戳每次加 160。序列号回答「这个包在序列里的位置」时间戳回答「这个包里的第一个采样对应哪个播放时刻」。两者职责分离是 RTP 能在丢包后继续正确播放的关键丢了一个包序列号断了但下一个包的时间戳依然按采样数递增接收端据此知道「中间空了 160 个采样」而不是「时间倒退了」。标记位在 G711 里语义很弱规范里把它定义为「重要事件边界」语音场景通常用来标记一段话的开头talk spurt 起点。实际互通中把这个位一直置 0 也没问题但如果你做的是带静音抑制的系统置位能让对端更快进入播放状态。3.3 载荷类型与打包间隔160 字节是怎么定下来的载荷类型 0 和 8 是静态映射意思是无论有没有 SDP 协商这两个数字就代表 PCMU 和 PCMA。这是 G711 相对动态载荷类型的巨大便利SDP 里甚至可以省略rtpmap行对端也能正确解码。很多私有协议栈就是利用这一点在极简信令里只交换 IP 和端口编码格式靠约定。打包间隔决定了负载长度也就决定了带宽和延迟的平衡点。G711 一个采样 125 微秒20 ms 对应 160 个采样这是最常用的配置。把头开销算进去RTP 12 字节、UDP 8 字节、IP 20 字节合计 40 字节加 160 字节负载是 200 字节每 20 ms 一发带宽正好 80 kbps。如果算到以太网帧还要再加 14 字节帧头、4 字节校验、8 字节前导和 12 字节帧间隙总共 238 字节折合 95.2 kbps。ptime负载字节每秒包数含 IP 带宽是否需要分片10 ms8010096 kbps否20 ms1605080 kbps否30 ms24033.374.7 kbps否40 ms3202572 kbps否100 ms8001068.8 kbps否200 ms1600565.6 kbps是这张表说明一个反直觉的事实打包间隔越大头部开销占比越低带宽越省但延迟越高、丢一个包的损失也越大。20 ms 到 30 ms 是语音的常用区间延迟可接受开销也不算离谱。超过 160 ms 就要小心了1600 字节负载加 40 字节头已经超过常见的 1500 字节 MTUIP 层会分片而分片的特点是「丢一片等于丢整包」链路稍微有点丢包率语音就会成段地断。下面是一个最小的 RTP 打包器!BBHII里的感叹号表示网络字节序这是 RTP 头的硬性要求import struct def build_rtp_packet(payload: bytes, seq: int, ts: int, ssrc: int, pt: int 0, marker: bool False) - bytes: payload: 160 字节的 G711 码流20ms 8kHz seq: 16 位序列号每包 1允许回绕 ts: 32 位时间戳每包 160单位是采样数 ssrc: 32 位同步源标识一次会话内保持不变 pt: 0 PCMU8 PCMA b0 0x80 # V2, P0, X0, CC0 b1 (0x80 if marker else 0x00) | (pt 0x7F) header struct.pack(!BBHII, b0, b1, seq 0xFFFF, ts 0xFFFFFFFF, ssrc) return header payloadseq 0xFFFF和ts 0xFFFFFFFF这两处掩码不能省。Python 的整数是无界的序列号累加到 65536 时如果不截断struct.pack会直接抛异常时间戳在 8000 Hz 下大约 6.2 天绕一圈长期运行的服务必然会遇到。3.4 SSRC为什么每次通话都要随机一个SSRC 是 32 位同步源标识作用是让接收端区分「这是同一路流的延续」还是「换了一路源」。单路通话里它看起来很多余但一旦涉及转发、混音、旁路监听它就是命脉。SSRC 冲突的表现很怪两路独立的流碰巧用了同一个 SSRC接收端会把它们当成一路按序列号和时间戳混在一起播放听感上是两段语音交替出现、断断续续而且抖动缓冲的水位会疯狂震荡。规范里定义了冲突检测流程——收到和自己 SSRC 相同的包时发一个 BYE 然后换一个新的随机值——但很多简易实现根本没做。随机源也要注意。用rand()不加种子每次进程启动的第一个 SSRC 都一样用一个自增计数器当 SSRC在多进程部署时会撞车。常见的做法是拿启动时间、进程号、随机数混一下反正只要 32 位空间里碰撞概率足够低就行。4. 二十毫秒的流水线采集、编码、发送、抖缓怎么对齐时钟4.1 发送侧的时钟时间戳绝不能从系统时间算这是我认为整个 G711 over RTP 里最容易埋雷、也最难排查的一处。声卡有它自己的晶振系统时钟有另一个晶振两者之间的偏差在消费级硬件上做到 50 到 200 ppm 是常态也就是每秒钟差几十到两百微秒。听起来微不足道但通话是长时间运行的100 ppm 的偏差一小时就是 0.36 秒。如果时间戳按系统时间换算——比如ts (now - start_time) * 8000——那么声卡实际产出的采样数和时间戳声明的采样数会缓慢背离。接收端的抖动缓冲水位会单调爬升或者单调下降十分钟后开始周期性丢音或者卡顿。重启一下又好了因为计数器归零了这种「重启能治百病」的现象最迷惑人。正确的做法是让时间戳跟着采样计数走采集回调实际交付了多少个采样计数器就加多少def send_loop(capture, sock, peer, ssrc): seq 0 ts 0 while running: pcm capture.read(160) # 阻塞到凑够 20ms返回 16bit 小端 n len(pcm) // 2 # 实际拿到的采样数可能不是 160 if n 0: continue payload g711_encode(pcm) # 16bit - 8bit长度等于 n pkt build_rtp_packet(payload, seq, ts, ssrc, pt0) sock.sendto(pkt, peer) seq (seq 1) 0xFFFF ts (ts n) 0xFFFFFFFF # 只跟采样数走不碰墙钟这段代码的关键在n上。声卡驱动不一定每次都精确给你 160 个采样可能 158可能 162取决于缓冲区对齐和重采样。如果代码里写死ts 160长期运行同样会漂移。用实际采样数累加漂移就被自然吸收了。还有一个变体做静音抑制时静音期间不发包但静音本文还有配套的精品资源点击获取