Mediabunny μ-law(G.711)PCM 音频编解码器注册规范:codec 字符串、EncodedPacket 数据格式与实现原理

发布时间:2026/9/29 6:35:19
Mediabunny μ-law(G.711)PCM 音频编解码器注册规范:codec 字符串、EncodedPacket 数据格式与实现原理
音视频视频处理音频处理【免费下载链接】mediabunnyPure TypeScript media toolkit for reading, writing, and converting video and audio files, directly in the browser.项目地址https://gitcode.com/gh_mirrors/me/mediabunny点击查看免费下载本篇文章基于 Mediabunny Codec Registry 中 μ-law PCM 编解码器注册条目 展开完整定义 μ-lawμ 律即 G.711 压缩 PCM在 Mediabunny 中的合法 codec 字符串、EncodedPacket数据格式、AudioDecoderConfig配置约定并结合 src/codec.ts、src/pcm.ts 等源码与 test/node/pcm.test.ts 测试用例讲解其底层压缩原理、WAVE/MP4 容器映射及实用编解码示例。读完本文你将掌握如何在浏览器环境中用 Mediabunny 正确声明、编解码与封装 μ-law 音频流。背景Mediabunny Codec Registry 与 μ-lawMediabunny 是一个纯 TypeScript 实现的媒体工具库可直接在浏览器中完成视频/音频文件的读取、写入与格式转换。为了保证所有出入库的媒体数据行为一致docs/codec-registry/overview.md 建立了一套 Codec Registry编解码器注册表对每个受支持的编解码器它精确规定EncodedPacket、VideoDecoderConfig、AudioDecoderConfig必须遵循的数据格式且作为 WebCodecs Codec Registry 的扩展凡双方共同支持的编解码器其注册定义保持一致。μ-lawμ 律与 A-lawA 律同属 ITU-T G.711 标准定义的压扩compandingPCM 音频编解码器以 8 bit 码字表示原本需要更高位深表达的线性采样值在语音通信、电话网络与 VoIP 场景中应用极为广泛。在 Mediabunny 的 Codec Registry 中μ-law 与线性 PCM、A-law 一起被归入未压缩 PCM 编解码器家族见 docs/codec-registry/overview.md 的音频编解码器列表注册条目为 μ-law PCM。Codec ID唯一的合法 codec 字符串μ-law 在 Mediabunny 中的 Codec ID 只有一个合法取值ulaw该字符串即 WebCodecs 体系中 μ-law 的标准 codec 字符串。在 src/codec.ts 的PCM_AUDIO_CODECS常量数组中ulaw与alaw、pcm-s16、pcm-u8等线性 PCM codec 并列被整体归类为已知的未压缩音频编解码器注释明确说明不添加le前缀是为了兼容 WebCodecs 注册的 PCM codec 字符串。AUDIO_CODECS则由NON_PCM_AUDIO_CODECSAAC、Opus、MP3 等压缩 codec与PCM_AUDIO_CODECS共同拼接而成μ-law 因此同时出现在支持写入的 codec 白名单中。与之配套的字符串解析函数inferCodecFromCodecString见 src/codec.ts中codecString ulaw被显式映射回ulaw而在校验音频 chunk 元数据时VALID_AUDIO_CODEC_STRING_PREFIXES见 src/codec.ts将ulaw、alaw与pcm、mp4a等前缀并列说明以 ulaw 开头是 Mediabunny 认可的合法音频 codec 字符串前缀之一。后续针对 PCM 家族的专项校验见 src/codec.ts则要求 codec 字符串必须精确命中PCM_AUDIO_CODECS中的某一项否则抛出TypeError。EncodedPacket数据格式逐字节的 μ-law 采样流数据组织规则EncodedPacket的 data 必须是一串任意长度的字节序列并满足两个硬性约束总字节数必须能被声道数整除divisible by the channel count——即每个声道在每个采样时刻都贡献恰好一个字节每个字节就是一个 μ-law 编码的 PCM 采样值8 bit 码字多声道时不同声道的采样按帧交错排列interleaved——与线性 PCM 的交错布局一致。以双声道为例data 的字节序列应为L0 R0 L1 R1 L2 R2 ...其中L、R分别代表左右声道在同一采样时刻的 μ-law 码字。由于单个码字只有 8 bit、正好一个字节因此任意合法的音频帧在字节长度上天然满足可被声道数整除的要求这也是 μ-law 与 A-law 编解码器在本仓库中sampleSize恒为 1 的原因详见后文。与采样转换管道的衔接Mediabunny 的音频处理核心位于 src/media-sink.ts 与 src/media-source.ts 两处解码方向sink在 src/media-sink.ts 中当dataType ulaw || dataType alaw时输入的 8 bit μ-law 码字会被fromUlaw解码为16 bit 有符号整数s16输出outputSampleSize由 1 提升为 2。其读取逻辑src/media-sink.ts正是fromUlaw(view.getUint8(byteOffset))——即每个字节 一个 μ-law 采样的直接体现。编码方向source在 src/media-source.ts 中浮点采样先被钳位放大为 16 bit 整数clamp(Math.round(value * 32768), -32768, 32767)再经toUlaw(int16)压缩为单字节码字写入目标缓冲区。可见注册表所定义的1 字节 1 采样格式在编解码两端都由parsePcmCodec的返回结构src/codec.ts显式保障{ dataType: ulaw, sampleSize: 1, littleEndian: true, silentValue: 255 }。其中silentValue: 255值得注意——G.711 μ-law 中码字0xFF即线性值 0 的编码结果见测试断言被用作静音填充值这与线性 PCM 以 0 为静音的约定不同。EncodedPacket类型恒为关键帧μ-law 是无帧内预测、无跨包依赖的逐采样压缩格式因此每个EncodedPacket的 type恒为key关键帧。这意味着任何单个包都可以独立解码无需参照前后包媒体管道的丢包容错、随机访问seek逻辑可以简化——解码器可以从任意包位置直接切入。这一特性与 Mediabunny 中其他逐采样格式如 A-law、线性 PCM保持一致也是 WebCodecs 体系对这类 codec 的通行约定。AudioDecoderConfigcodec 字符串与 description 约定codec 字符串AudioDecoderConfig中的 codec 字段合法取值同样是ulaw配置时需同时提供有效的sampleRate正整数与numberOfChannels正整数validateAudioChunkMetadata见 src/codec.ts会强制校验这两个字段任一缺失或非正整数都会抛出TypeError。description不使用μ-law 的全部解码参数压扩曲线、位深、字节布局都由 G.711 标准与 codec 字符串本身确定description字段不被使用。这与需要携带description如内含编码器配置的 AAC、FLAC 等的 codec 形成鲜明对比对ulaw前缀的 codec校验逻辑不要求description从 src/codec.ts 的分支结构看description仅对需要额外配置的 codec如 FLAC 等生成引用描述其他 codec 一律允许undefined。因此创建 μ-law 解码器配置时只需三要素codec: ulaw、sampleRate、numberOfChannels。源码级原理G.711 μ-law 压扩算法实现编解码核心 src/pcm.tssrc/pcm.ts 提供了 μ-law 的完整编码/解码实现注明原始来源为 pcm-g711 项目编码toUlaw(s16)的要点采用 μ-law 编码偏置MULAW_BIAS 33G.711 标准规定偏置用于消除编码误差下限输入 16 bit 有符号值右移 2 位相当于预先除以 4加上偏置后以MULAW_MAX 0x1FFF钳位通过位扫描确定量化段position 从 12 递减拼装符号位、段位与 4 bit 尾数lsb最终按 μ-law 规则取反~(…) 0xFF得到 8 bit 码字。解码fromUlaw(u8)的要点对码字取反后分离符号位从段位 尾数中还原 13 bit 幅值减去偏置后左移 2 位回到 16 bit 有符号范围。整个曲线是近对数的小信号量化步长小保真度高、大信号量化步长大从而在 8 bit 码字下获得约 12~13 bit 的动态范围这也是电话语音场景选用 G.711 的根本原因。测试用例的权威验证 test/node/pcm.test.ts测试文件明确注明期望值来自 ITU-T G.711 解码表以 s16 PCM 表示解码锚点L127-L135fromUlaw(0x00) -32124、fromUlaw(0x80) 32124、fromUlaw(0xFF) 0、fromUlaw(0xFE) 8、fromUlaw(0x55) -716——这些值直接对应 G.711 标准查表结果编码锚点L146-L154toUlaw(0) 0xFF、toUlaw(32124) 0x80、toUlaw(-32768) 0x00验证了全幅值与静音值的编码映射往返误差L166-L179对 12 组正负采样值做fromUlaw(toUlaw(v))往返断言解码误差|decoded - v| max(16, |v| 3)定量刻画了 μ-law 压扩的量化误差特征相对误差约 1/8绝对误差下限 16文件级往返L181-L236构造包含全部 256 个可用码字的Int16Array经WavOutputFormat写出、再经Input读回断言 codec 为ulaw且解码后数据逐字节一致无损往返完整验证了编码 → WAVE 容器 → 解码整条链路。容器映射WAVE 与 ISO-BMFFMP4中的 μ-lawWAVE.wavformat tag 0x0007WAVE 通过fmtchunk 的 format tag 标识编码。在 src/wave/wave-demuxer.ts 中WaveFormat.MULAW 0x0007。关键行为解析fmt时若 format tag 为 μ-law/A-lawsrc/wave/wave-demuxer.tsbitsPerSample 被强制置为 8以规范 WAVE 头即使文件中写的是 0 或其他值支持WAVEFORMATEXTENSIBLEformat tag 0xFFFE会从 subFormat GUID 前 2 字节还原真实 format tagsrc/wave/wave-demuxer.ts兼容现代编码器产出的 WAVE 文件识别后getCodec()返回ulawsrc/wave/wave-demuxer.tsMIME 类型为audio/wav。写入侧在 src/wave/wave-muxer.ts 中通过parsePcmCodec(codec)判断dataType ulaw时写WaveFormat.MULAW由于 μ-law 的sampleSize为 1blockSize sampleSize * channels恰好等于声道数。WAVE 输出格式WavOutputFormat的支持 codec 列表明确包含ulaw、alaw见 src/output-format.ts而 MatroskaMKV输出格式则将 μ-law/A-law 排除在支持列表之外见 src/output-format.ts——这是容器能力差异的如实体现选型时应以目标容器的getSupportedCodecs()为准。ISO-BMFFMP4 / MOVulawsample entry在 src/isobmff/isobmff-boxes.ts 的audioCodecToBoxName映射中ulaw对应名为ulaw的 sample entry boxQuickTime 风格大小写形式即ulaw。解封装侧在解析stsd内的声音 sample description 时src/isobmff/isobmff-demuxer.ts识别到codecName ulaw后直接将轨道 codec 置为ulaw——因此带 μ-law 音轨的 MP4/MOV 文件可被 Mediabunny 正常读取。实用示例在浏览器中编码与解码 μ-law 音频基于上文规范给出可直接运行的 Mediabunny 用法示例。编码s16 → ulaw并写入 WAVE 文件参考 test/node/pcm.test.ts 的往返流程import { Output, WavOutputFormat, BufferTarget, AudioSampleSource, AudioSample } from mediabunny; const data new Int16Array(8000); // 1 秒、8 kHz 的单声道 s16 PCM for (let i 0; i data.length; i) data[i] ...; // 填充采样 const output new Output({ format: new WavOutputFormat(), target: new BufferTarget(), }); // codec 字符串必须严格使用 ulaw const audioSource new AudioSampleSource({ codec: ulaw }); output.addAudioTrack(audioSource); await output.start(); const sample new AudioSample({ data, format: s16, numberOfChannels: 1, sampleRate: 8000, timestamp: 0, }); await audioSource.add(sample); sample.close(); audioSource.close(); await output.finalize(); // output.target.buffer 即为携带 μ-law 音轨format tag 0x0007的 WAVE 文件解码ulaw → s16 PCM并读取采样import { Input, BufferSource, AudioSampleSink } from mediabunny; using input new Input({ source: new BufferSource(wavBuffer), formats: [wav], }); const track (await input.getPrimaryAudioTrack())!; console.log(await track.getCodec()); // ulaw const sink new AudioSampleSink(track); for await (using sample of sink.samples()) { const decoded new Int16Array(sample.numberOfFrames * sample.numberOfChannels); sample.copyTo(decoded, { format: s16, planeIndex: 0 }); // decoded 即解码后的 16 bit 线性 PCM 采样 }要点回顾codec 字符串一律写作ulaw同时必须提供sampleRate与numberOfChannels输入AudioSampleSource的 codec 决定写出格式输出WavOutputFormat会据此写出0x0007format tag解码侧AudioSampleSink自动执行fromUlaw产出 s16 格式的AudioSample底层AudioDecoderConfig不需要descriptionEncodedPacket的 type 恒为keydata 中每个字节为一个 μ-law 码字、多声道按帧交错。与 A-law 的对照及选型建议μ-law 与 A-lawdocs/codec-registry/alaw.md在 Mediabunny 中的注册结构几乎完全对称同样为单字节采样、type 恒为key、AudioDecoderConfig不使用description差异主要体现在两处维度μ-lawA-lawCodec ID / codec 字符串ulawalaw标准依据ITU-T G.711 Tables 2a/2bITU-T G.711 Tables 1a/1bWAVE format tag0x0007WaveFormat.MULAW0x0006WaveFormat.ALAW编码偏置/取反规则偏置 33、码字取反码字异或0x55静音码字silentValue2550xFF2130xD5silentValue的差异来自 src/codec.tsμ-law 静音码字为255A-law 为213。选择建议遵循 G.711 的通行地域惯例——北美/日本为主的系统使用 μ-law欧洲与我国电话网络使用 A-law若面对未知来源的语音文件可依据容器内的 format tag 或 codec 字符串自动识别Mediabunny 的解封装器已具备此能力。总结μ-law 是 Mediabunny Codec Registry 中结构最简洁的编解码器之一Codec ID 与AudioDecoderConfigcodec 字符串均为ulawdescription不使用EncodedPackettype 恒为keydata 为每声道每帧 1 字节、多声道交错的 μ-law 码字序列。理解这些约定即可通过AudioSampleSource/AudioSampleSink与WavOutputFormat/ISO-BMFF 容器完成 μ-law 音频的编解码与封装其 G.711 压扩曲线、静音码字与 16 bit 解码输出的每个细节均有 src/pcm.ts 与 test/node/pcm.test.ts 中的锚点值可查可验。赞分享音视频视频处理音频处理【免费下载链接】mediabunnyPure TypeScript media toolkit for reading, writing, and converting video and audio files, directly in the browser.项目地址https://gitcode.com/gh_mirrors/me/mediabunny点击查看免费下载相关推荐MediaBunny 的 VP9 编解码器注册规范codec 字符串、EncodedPacket 格式与量化器范围解析MediaBunny 的 VP9 编解码器注册规范codec 字符串、EncodedPacket 格式与量化器范围解析 导读 本文基于 MediaBunny音视频视频处理音频处理portless 非服务脚本检测机制为什么 test、build 命令不会被分配代理路由portless 非服务脚本检测机制为什么 test、build 命令不会被分配代理路由 portless 是一个用稳定的命名本地域名替换端口号的本地音视频视频处理音频处理Mediabunny AAC 编解码器注册规范codec 字符串、解码配置与数据包格式详解Mediabunny AAC 编解码器注册规范codec 字符串、解码配置与数据包格式详解 导读 AACAdvanced Audio CodingISO/音视频视频处理音频处理上一篇Pie语言入门指南从安装到编写第一个依赖类型程序的完整教程下一篇知识图谱嵌入从未如此简单PromptKG助力研究者快速实现SOTA模型创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考