【原作者：神武竹 • 未经允许，禁止转载】

「前言」

•请区分Ogg与OGG

* 本文Ogg为一种开源多媒体容器格式，由Xiph.Org基金会开发支持，常见于音视频文件和网络传输。

* Oracle Golden Gate（OGG）一种基于日志的结构化数据复制软件，由Orcale甲骨文公司开发支持。

经典混淆：

（仅指出错误，没有针对性。上两篇文章虽有纰漏，也不乏参考价值。重点：Ogg不是一种压缩格式）

• 本文主要参考文献【Xiph.Org基金会官网Ogg规格文档】

• 辅助资料：2006浙江大学 冯炯硕士论文《Ogg/Vorbis解码器设计实现》

（ 代码实践性很强，只有少量纰漏，致敬前辈！）

• 代码示例均为Java语言。其他语言程序员可跳过示例，了解原理即可。（还没写）

• 本文技术性较强，读者应有 基础计算机知识 和 编程基础 。凡重要、晦涩、存疑处都加【】注释。

• 本文涉及英文资料，无官方中文翻译，因而使用作者翻译，感谢指正。凡重要或易混淆的译名也加【】注释。

        Ogg是Xiph.Org基金会开发的开源流媒体容器格式。适用于Opus、Vorbis、Theora、Kate、PCM等多种音视频编码格式。

        中网有很多Ogg技术文章。但都有通病：

一是翻译混乱，Xiph官方无中文支持，导致一些文章的翻译冗余或用机翻，更有甚者上来就甩你一篇英文；二是胡乱删减，官方英文文档极为详细，有些文章省略过多细节，连“逻辑流”“物理流”的含义都不解释，你压根找不到真正解释清楚了“多路复用”的文章；三是没有实践，要么不上代码空谈连篇，要么直接套其它代码库；四是反复“转载”，层层降值。

        本人第二篇技术性文章，一方面 希望写一篇 可供参考 的文章；另一方面承接第一篇Xiph基金会，提高文章的专业性，顺便练练文笔～

       图片均源自网络，侵删 ｜

       感谢阅读与指正

【原作者：神武竹 • 未经允许，禁止转载】

---

「概述」

        Ogg是一种流媒体容器格式。提供了对流式【连续的按时间排列的数据】数据进行 分割、存储、排序、按时间顺序查找以及寻错保护【数据丢失或错误时进行调整】 的框架，也可以将多个流混合，即多路复用，形成视频或其他复杂文件。

        Ogg 是容器【container】，是个箱子，类似微软的Wav格式。Ogg文件理论上可以装任何数据，而不仅仅是音视频，甚至可以存 pdf 或 jpg （只要有对应的解码器）。Ogg容器和内部存储的数据 / 元数据【metadata，描述数据的数据】本质上是分离的，好比 箱子跟箱子里放的东西 无关，称之为解耦。Ogg可直接作容器，也能作另一个更复杂（可能非线性）容器的组分。

        Ogg同时指Ogg多媒体项目（原名Squish），该项目包括Ogg、Vorbis、Theora（Opus不属于Ogg项目）。参考作者第一篇文章【Xiph基金会】。

【原作者：神武竹 • 未经允许，禁止转载】

---

「设计特点」

        简易。实现容易，无论是分页、分段还是多路复用；不需要重新打包源数据；字节对齐【你就理解为以字节为单位】；编解码复杂度持平；容器结构固定。

        流式。Ogg主要用于流媒体数据【流式传输的多媒体数据，适用网络传输即时播放】传输 / 存储 / 播放。编解码器 能且只能 一次性、不回头地编解码整个Ogg流，不需要也不能 花时间查找数据或使用多余的缓冲区。Ogg适用于面向流的TCP、本地文件；UDP、RTP（面向数据报）不宜搭配Ogg。

        线性。Ogg 摒弃了索引的设计【！！！】，理由是它对流媒体是多余的，Ogg拒绝非线性访问，允许但强烈不推荐 优化编码（如二次编码，分两次扫描数据）或 交互解码。

       绝对颗粒位置【absolute granule position】的设计，具体见 基本概念-页。相当于绝对时间戳【单纯指时间标记】。不同类型数据的颗粒位置有不同的意义，编解码器可以自行定义、使用，非常灵活；在复合流中又可以互相转化，使音频、视频以及字幕/弹幕能统一装在容器里，进行播放和跳转。（而不是把音频、视频分两块）

        空间高效<未必>。每页在65307Bytes约64kB以下，通常一页4～6kB，其中容器数据只有27 ～ 282字节，空间开销0.4 ～ 0.7%。

        捕获/定位【capture，以下用“定位”】。每页大小 < 64kB，所以最多读取128kB（130613Bytes）就能定位Ogg流，因而可以从流的任何一处开始解码。

        查找【seek 】。能相对简单地进行“低精度”或“高精度”查找。参见 高级-查找。

        多路复用【Muxtiplex，简称mux】。将多个基本流交错成复合流，使音频、视频、弹幕/字幕 等混合在一起 ，可以同时解码播放。见 高级-多路复用。

        完全解耦。容器与 数据/元数据 是分离的；容器和编解码器也是分离的；对复合流而言，不同基本流间的关系跟容器本身更是毫无关系的。Ogg只是个箱子，里面装的什么、怎么用、什么关系 跟箱子本身没有一毛钱关系，Ogg只负责把数据按你定好的规则放进去、存好、取出来。所以Ogg可以存放 各种各样 的数据。当然解耦有一定弊端，见 高级-Skeleton。

---

「彩蛋」

        很多人误认为Ogg是音频格式。实际上Ogg容器存储的Vorbis文件才是一种音频格式，Ogg还可以存储FLAC、Opus、PCM音频，以及Theora、Dirac、Daala视频、Kate、XSPF、JSPF文本。只不过最初只有Vorbis装在Ogg里，合称Ogg Vorbis，简称Ogg。后来虽有了其他格式，大家都叫习惯了；于是2007年Xiph将错就错，规定只有Ogg Vorbis文件的拓展名为“.ogg”，而视频换成“.ogv”、音效换成“.oga”等。

        Ogg目前规格版本还是0，只更新了一个可选的Skeleton【见Skeleton】来辅助解码，可选索引还在草案中。（其实Xiph就是懒）收回这句话，Xiph2012年前后提出了Ogg 2 -- TransOgg，针对传输和安全性对Ogg进行了改进。主要改进有：强制性元数据流Skeleton，最大系带值由255降至252，可选的索引Ogg Index，强制编解码器信息写入Skeleton，元数据增强等等。然而和Ogg Index一样，尚在草案中（10年了喂！）。参见【XiphWiki TransOgg】。

        Ogg的名字源于上世纪世界第三款网络游戏 Netrek 里的梗：“Ogging”，不能写成“OGG”，但老有人写错。

        梗百科：Netrek 是一款开源网络游戏，也是世界上第一款网络团队游戏。玩家作为一艘星舰舰长与敌舰干架。游戏分两队，通过消灭敌人而占领所有行星即胜利。

 Netrek 游戏截图

        其中玩家编号是    <队伍首字母> + 十六进制数字（0～9 a～f）   。而观众（观察模式的玩家） 或者 人机 是    <队伍首字母> + g ～ z字母    。

        1990年11月某日，卡内基梅隆大学计算机室里三个玩家Jay Hui，Byron Sinor，Steve Russel正在Netrek开黑。三人都是游戏新手，菜。

        服务器腐竹Terence（就他把游戏带进学校）黑进游戏伪装成人机，编号为“Og”（Orions猎户队）。Terence可是大佬级别，他决定给三个菜鸟“上上课”。他秀出一套高阶操作：自杀性袭击 ---- 即开局 不管资源不发育 直接全买武器 跟正在发育的对面硬刚。

        于是，“机器人” Og 大杀四方，血洗三军，给Steve吓坏了。安静的计算机室里，Steve突然暴喝：“Help！It's 'O' 'g'  ！”（ “救命！Og来了”，念两个字母）然后继续喊“Hellllllllpppp！It's Og！It's Ogggggggg！”（ “救命啊啊啊啊，是Og！”念成“奥格”）。

        Ogg于是乎成了梗，游戏里代指这种自杀性袭击战术“Ogging”；Ogg在生活中可以表示“不考虑退路、强行地做”。

        Ogg 始于1993年Monty开发的大项目，项目目标是开发压缩多媒体格式。其中音频压缩的软件叫做”Squish”。“squish”直译“挤压”引申为“压缩”。Squish网页公布后，Monty得知“Squish”这个名字已经被一家邮递公司使用，为避免侵权，在基友Mike建议下，改成“OggSquish”。

        为什么叫Ogg呢？Monty构思Squish的90年代，美国PC的CPU几乎都是Intel i386芯片，i486才刚刚推出。但Monty开发的压缩算法非常复杂。

        “啊哦，他们（用户）至少需要一个i486芯片” “如果用Squish软件播音乐，半个计算单元都闲不下来。” （monty）这当然是一种“不留退路”，也就是Ogging了。

        后来，Ogg 变成容器格式的名字，而Squish变成了Ogg编解码器的名字（已淘汰）。总之，Ogg不是人名，也不能写成”OGG”。

       至于它的徽标…呃…

早期OggSquish徽标

你看清了吗 ？徽标取材于北欧神话“雷神战蛇”的故事。但这 分辨率 和 配色 真是一言难尽（Squish与Ogg已经无关了；所以封面没用这张图）。寓意嘛……官网说……

       “蛇的身子很像正弦曲线，雷神索尔（Thor）举起雷神之锤（Mjollnir）要 砸扁（compress，双关“压缩”）长的像 周期信号（知道傅立叶变换的话你就懂了）耶梦加得（Jörmungandr蛇名）…… 是不是有感觉了？”

       【此时无声胜有声】

       

---

「基本概念」

<Bitstream>

       指流式数据。常译“位流”，“比特流”或“数据流”，下文统一“比特流”。

<逻辑流>

        Logic Bitstream。“逻辑意义上的数据流”，指编码器创建的比特流。逻辑流的基本单位是包。

        就是分完包的原始数据。逻辑流中的数据应该是同一类型的：比如一首歌（音频）可作一个逻辑流，一部无声电影（视频）可以当一个逻辑流，一篇文章（文本）也能作逻辑流。但一首MV（音频 + 视频）最好分成两个逻辑流；带弹幕的动画（音频 + 视频 + 文本）应分为三个逻辑流。

       逻辑流就是Ogg容器要装的数据。

逻辑流 由（通常）无框架信息的包 组成

<包>

        Packet 或译“数据包”。原始数据像一块蛋糕，被切成若干块，即包（怎么切蛋糕不是Ogg的事）。包的大小理论上从0到无限字节（可以为0！！），不需要框架信息（也就是说把包连起来还是原始数据，相当于蛋糕切了还是蛋糕），框架信息由页提供。不需要，但可以有。

       会写代码的可能更容易理解：包就是一个任意大小的byte数组，是从源数据上分割下来的。0长度的包叫空包【nil】。

       虽然包可以随便分，但更推荐能直接解码的相对独立的数据。一个包可以对应一个视频帧、一个音频帧；虽然大部分包只有50 ～ 200Bytes大小（一帧），但单个包大小在 0.5 ～ 1 KB 时效率最高，还可以直接用于UDP传输（因为UDP数据报限制1024字节内）。（明面上“无限制”，结果还有这么多“建议”，这波上屋抽梯）

       逻辑流第一个包叫BOS包【Beginning Of Stream流的开头】，最后一个包叫EOS包【End Of Stream流的末尾】。

<物理流>

        Physical Bitstream。“物理意义上的流”，指Ogg编码器输出的比特流。物理流的基本单位是页。

        物理流要么是基本流，要么是复合流，但必须是 单个 由页组成的流。物理流相当于装完数据后的整个容器，比如一个“test.ogg”文件就是一个物理流。

        复合流中的每个基本流都有一个唯一 的 流序列号【见 基本概念-页】，标记在页上，按序列号即可把混合的页重新组装成基本流。【见 高级-多路复用】

<基本流>

         Elementary Stream 或 Elementary Physical Bitstream。单个逻辑流分页后形成的新流叫做基本流。它可以单独作物理流，也可以多路复用后变成复合流。

         Logical Ogg Bitstream。“逻辑Ogg流”。根据官网文档，这个单词与“基本流”应该同义。这导致很多文章混用 逻辑流 和 基本流 两个概念。区别可能在于：“基本流” 强调 “一个物理流 / 复合流的一部分”，而“逻辑Ogg流” 强调 “构成复合流的一部分”。

         一个基本流最少只有一页（BOS页）。

<复合流>

         Multiplexed Bitstream【 Multiplexed Physical Bitstream，或“复合物理流”/“混合物理流”；mixed streams，或译“混合流”；又有multiplexed streams，强调“多路复用的流”。以上统一“复合流”】。由多个基本流 多路复用 构成。见 高级-多路复用。

<链>

        Chain【或“链条”】。

        已知  ：

        1 逻辑流 分页 ->  1 基本流      ｜

        N 基本流 混合 -> 1 复合流      ｜

        1 基本流 / 复合流 -> 1 物理流 ｜

        而多个物理流串联【Chaining 意译】成一个新流，即链【chain】。链中的每个物理流叫做节。【link，直译“链条”，强调链中的一环，意译为“节”】

        注意，节与节不能混合、交错，只能串联。前一节没有结束，后一节不能开始。此时每个基本流的流序列号在整个链内都必须是唯一的。链中的每一节都是独立的物理流。如图是两个物理流组成的链：

方块-页    同颜色-同一基本流   右下角数字-页号

initial-BOS页   term-EOS页

        两个节都是复合流。前一节 有 红/蓝/绿 三个逻辑流，后一节有 黄/紫 两个基本流。只有红蓝绿三个基本流的最后一页都出现之后，即三个流都结束之后，黄/紫 基本流才能开始。

<段>

         Segment【或“片”】。要把包封装成页，因为包大小不固定且没有框架信息，所以先把每个包分成更小的数据单元：段。段本质上还是个byte数组，长度在0 ～ 255 之间，段的长度称为 系带值【lacing value】。参见 基础编解码-数据包分割。

复习一下：

|     逻辑流 分页 ->         基本流  

 |    基本流/复合流 ->      物理流  

 |   基本流 多路复用 ->   复合流

*****************敲黑板*****************

<页>

         Page。Ogg物理流的基本单元。页与页是相互独立的。页构成了整个容器，页的结构 和 页与页 / 页与流 的关系是Ogg规格的核心。所有容器功能都集成在页中。页的大小不固定。

页头【Page Header】

        页头是页的功能结构，包含了全部容器信息。页头字段结构如图：

图片来自维基百科

字节1～4（对应图中0 ～ 3）

定位域【capture pattern，或“捕获模式”】：

      “定位Ogg流”指找到Ogg流中某一页的精确位置。Ogg流中页与页首尾相连，故只要找到了一页的准确位置，就可以顺着找到后面所有的页。（但不能直接找前面的页）。

       定位域就是页的标志，四个字节固定为4F 67 67 53 ，ASCII “OggS”，即“Ogg Stream”，注意大小写。

       解析Ogg文件时，定位域可以当幻数【Magic Number，又称“魔数”，在数据首部设置的固定字节，用于标识文件类型】；而在网络传输时，定位域使程序可以在流的任意一处开始解析。见 基础编解码-定位。

字节5

流结构版本【stream_structure_version】：

        即Ogg容器的版本，目前只能为0。

字节6

类型标记【header type flag】：

          标记此页在流中的上下文 关系，主要是和前一页的关系。这个字节（8位）是按位 取值的。目前只使用后3位，剩下的留未来使用。

     （从右向左）

        第一位：Continue位。如果为0，此页以一个新包开始，是新页【Fresh】；如果为1，则此页数据 接着 上一页的最后一个未完成的包，即此页是上一页的续页【Continued】。当然，续页也可能只包含这一个包而且还没续完，则下一页还是续页。

        第二位：BOS位。如果为1，表示此页是其所属基本流的第一页【Beginning Of Stream】。对应它的页号必须为0。见 基础编解码 - 填页头。

        第三位：EOS位。如果为1，表示此页是其所属基本流的最后一页【End Of Stream】。一个基本流理论上可以只有一页，此页同时是BOS和EOS页。

        BOS页是流的第一页，所以一定是新页（前面一定没有其他页）。即如果第二位为1，则第一位一定为0。综上，类型标记有6种有效值：000、001、010、101、100、110。十进制：0 1 2 4 5 6。

字节7～14

绝对颗粒位置：

         8 字节的有符号整数。下面长篇大论解释：

        在流中实现跳转（seek）和多路复用，都需要有时间戳。根据时间标记，程序便可以精确跳转到流的某一处开始解码；根据时间标记，编码器才能把 计时单位不同 的  视频/音频/字幕  按时间顺序排列交错【见 高级-多路复用】。

        但我们又说，Ogg容器和数据是完全分离的：想知道总时间，难道要从头开始解码？

        为了实现 解耦 + 时间戳 ，Ogg采用了绝对颗粒位置的设计。Ogg要求颗粒位置必须是绝对时间戳【如总样本数/总帧数】，故称“绝对颗粒位置”。注意！ “总时间 / 绝对时间” 是指从 <流开始> 到 <这个包> 为止 的时间，所以某个包的 绝对时间 =  前面所有包的时间加上自己的时间 之和。

        颗粒位置只是个数字，它的单位由数据类型决定：对于音频，单位是 个（PCM样本）【关于PCM编码，可参见《PCM数据格式》】；对于视频，单位一般是 帧 ，也可以直接以毫秒为单位。颗粒位置可以和实际时间相互转换，例如音频总时间为 样本数➗样本率，视频总时间是 帧数➗帧率。颗粒位置如何转换，取决于编解码器，与容器无关，不需要修改Ogg的代码，符合开闭原则【修改关闭，拓展开放】。

        颗粒位置的意义完全由编解码器解释，所以除了绝对时间之外，还可以在颗粒位置里附加其他数据（但保证颗粒位置仍然按非递减顺序排列），从而添加新功能。Theora（视频）就是这么做的：

        视频帧分为关键帧和中间帧，中间帧必须依赖关键帧才能解码。所以视频跳转时，必须跳转到关键帧处；但Ogg本身没有标记关键帧的设计。这时候，颗粒位置的灵活性就显现出来了。

        Thoera把这8字节分成 6B<总帧数> + 2B<偏移量>。关键帧 K 的<总帧数> = 包括自己在内的所有帧的总数，中间帧 C 的 <总帧数> 等于 所依赖的关键帧K 的 <总帧数> ，<偏移量>表示C与K的距离（单位帧 也就是包），K 的<偏移量>为0。

        这样，一 保证颗粒位置仍然非递减排序，二 把关键帧位置巧妙嵌入Ogg容器中。跳转时可以根据偏移量往前找到关键帧。

        由于单位不同，不同的颗粒位置可以转换为同一时间：比如 视频 640 帧 =  音频 12800 个样本 =  16 秒。跳转/多路复用Mux 时需要把它们转换成同一单位（建议 秒/毫秒 ）。

        烧脑吗？回归原题。

        每个包都有自己的<时间>和<总时间>，每个包都必须有自己的绝对颗粒位置。包的<总时间> = 上一个包的<总时间> + 本包的<时间>。一个包的<时间>可以为0。见 基础编解码-填页头。下文提到颗粒位置时，请一定注意<总时间>和<时间>的区别。

        页的 绝对颗粒位置 是本页最后一个 <已完成的包> 的颗粒位置，如果最后一个包还没完成（下一页是续页），就取倒数第二个数据包的颗粒位置。如果整整一页只有一个包而且还没完成，颗粒位置取 补码 -1。页的颗粒位置可以为-1，包不可以。

字节15～18

流序列号【stream serial number】：

         页所属逻辑流的序列号。标识不同的逻辑流，仅在多路复用Mux时有用。可以取 -1 外的任何值（-1表示空流）。

字节19～22

页号【page sequence no】：

         页在所属逻辑流中的编号，表示这是逻辑流中的第几页，从0开始。用于检查页是否丢失。

字节23～26

CRC校验和【page checksum】：

        页的校验码【check code，加在数据末尾检查漏误的一串数字】，采用32位CRC算法。CRC是一种优秀的检错码，想学习自行搜索，可参考这里【年代早 无图 细节满满】，精通英语的大佬看这里【专业性极强】。

       如果你已经懂了CRC，请注意：Ogg的CRC采用直接算法（不反转），寄存器初始值为0，余数为0。因为CRC码在页头，计算时先把 CRC 的4个字节全填0，算出校验和 再填到这4个字节里，校验时同理。

字节27

段数【page segments】：

         此页中段的数量，也是段表的长度，大小范围0 ～ 255，一页最多有255段。如果为0，说明此页不含数据，为空页。

字节28 ～ 27 + N

段表【segment table】：

         段的长度表 / 系带值表。表的长度由 段数 决定。段表后面就是原始数据一大串字节。段表中每个字节 都表示数据中一个 段 的长度，即系带值，大小0～255。

        例如，某页段表有四个字节：255 255 255 173

        那么，紧跟段表后面就是按顺序排列的 255、255、255、173 字节的四段。

        由上可算出：一页最大大小是 27 + 255 + 255 * 255  = 65307 B，略小于64KiB（64*1024 = 65536）。最小27字节，即只有页头没有数据，这种页叫“空页”【nil page】，通常充当EOS页。不建议用太大的页：因为一旦数据出错，这么大一页都要丢弃，血亏！页的最佳大小是4 ～ 6KiB。

        注意：上文所有整数的字节按低字节序【Little Endian又译“低位编址”】，即低位字节（字节 不是 位 ！）在前，高位字节在后。比如  0x 00 00 25 9a  四个字节，输出时变成 9a 25 00 00

---

「基础编解码」

        这一节讲述了最基础的Ogg编解码过程，官方libogg 库实现了基础编解码功能，参考gitlab-libogg库。

        解码显然比编码简单。搞懂编码，解码就通了。这里只涉及 单个逻辑流 <—> 基本流的过程，对于 多个基本流 <—> 复合流 的情况，见 高级-多路复用。

壹：数据包分割 【segmentation分段】

        Ogg要存储的数据就是一堆包，大小无限制，但页的大小是有限制的。第一步，将包分成更小的段，使之能组装成页；而段 又要能重组成 包。所以分系带值是有套路的：

        把一个包从前向后，每255字节分为一段。如果分到最后，不够255字节，就把剩下的分成一段；如果刚好255字节，为了区分边界，再加一个长度为0的段。这样系带值 < 255字节的一定是一个包的最后一段。

       例如，一个753字节的包 + 一个255字节的包  会被分成：

       255  255  243  255  0          共 5 段

       分段的设计使 过大/过小 的数据包都不会严重浪费空间。当然最好还是在255 ～ 510字节效率最高。（< 255字节的较小包浪费严重，> 510字节的较大包大约耗费0.5%）。

       段重组成包也简单。每个系带值< 255 的段都是一个包的末尾，把它以及它前面所有255字节的段合起来即可：

       255   255   243       255   0       67

                             ^                  ^        ^

                       753B包       255B包   67B包

贰：数据包分页【pagination】

       现在我们有了一大堆段。接下来组装成页，我们且不管页头其他部分，先把段和段表装起来。

       包的大小不确定，所分出来的 段的数量 也是不确定的。大数据包一页装不下  ；小数据包一页只装一个 又太浪费了；如果一页只装整数个包，页的大小就很可能太参差不齐。综上，我们不能按包来分页，而应该用更小的单位：段。

       按段组装页，就意味着数据包可以跨页。一个包可能前几段在上一页，后几段在下一页；特大包可能跨好几页；小包可能都塞在一页里。如此一来，页大小便可以把控在4 - 6KiB 左右。

       一个包看成一篇文章，页就看作书页。文章有长有短：可能一篇长文占几页；也可能几篇短文放一页；文章还可以跨页；但每页的大小都差不多。（Monty就是这么比喻的，于是起名为“页”）如图：

       

数据包分页（这里没有模拟超大数据包）

        但是，Ogg建议尽量避免跨页的包，因为这变相增加了解码复杂度（特别是增大空间开销）；在libogg的函数中，默认情况 每一页要满足（1）至少有4个包 （2）大小超过4096字节 （3）最后一个包不跨页 才能输出。这是一个对调用者隐藏的低级策略。只有4096这个阈值可手动调整；若上述三个条件一直不满足，页会一直装到满才输出！说实话，这个实现真摆烂。不过官方文档也说：编码器可以有更高级的策略，libogg只是个模板。

叁：填页头【封装】

        我们已经把每个段的系带值写进了段表。我们是按逻辑流的顺序分包，按包的顺序分段，按段的顺序分页，那么页已经是有序的。只要加上页头 ----

        页头可不简单。

        定位域、版本是固定的；页号按顺序标（从0开始）；流序列号找个随机数就行；CRC校验码的话本文不提。只有 类型标识 和 绝对颗粒位置 要费脑筋了。

        BOS页是流的第一页，Ogg要求 BOS页只能有一个包 -- 初始标头【initial header】 ，只用于标识，不含具体数据，通过它必须能得到整个逻辑流的数据类型，从而确定对应解码器（尤其是确定颗粒位置的转换方式）；而且必须能确定流的连续性 （见 高级-缓冲）。所以我们回到第二步分页的时候，把初始标头单独装进首页里，BOS位为 1。

        同时，Ogg规定：逻辑流可以有辅助标头【auxiliary header】，辅助标头可以由若干个包组成，用来提供额外信息或者为后续解码提供初始化参数（例如Vorbis的注释标头和设置标头）。辅助标头必须紧跟初始标头，所以辅助标头的页必须紧跟BOS页，且最后一个包必须恰好在最后一页完成（此操作称为刷新页【Flush page】），真正的数据从新页开始。于是我们又回到第二步，调整辅助标头的页。

        EOS页是流的最后一页，EOS位为 1。一个基本流可以只有一页（奇怪的规范，只有BOS页就只有初始标头；只有标识没有数据有什么意义？），它的BOS  EOS位都为 1。

        如果这一页以一个新包开始，那么Continue位为0；反之为1。这个设计只在查找操作时，正常解码时只要看前一页的最后一段系带值，是255说明数据包还没结束，下一页为续页；反之下一页是新页。Continue位增强了流的检错功能，同时提升了查找操作的效率。【见 高级-查找】

        因为逻辑流通常是多媒体数据，一定是按时间顺序排列的；所以包的绝对颗粒位置必须按照非递减【后 >= 前】排列，相应地，页的颗粒位置也必然非递减排列（ -1 除外）。包的时间可以为0，所以颗粒位置可能 = 前一个包，同理，页的颗粒位置可能 = 前一页。页的颗粒位置是页中最后一个<已完成的包>（包的最后一段在页里，就说包在此页上完成）的颗粒位置，如果没有完成的包就填 -1。总之，后一页的颗粒位置要么为-1，要么大于等于前一页。

        诶不对，如果一页里有多个包，前几个包的颗粒位置不就没了吗？确实，颗粒位置的精度会下降。但Ogg认为只要控制好页的大小即可控制误差在容忍范围内。这一点在 高级-查找 里还要重提。

        上面两段文字其实是Ogg对数据的基本要求，我开头说 “Ogg里可以存任何数据” 不完全对：（闲的发慌的）你还需要把数据 合理地拆成包 并加入 初始标头（+ 辅助标头），还要定义一个非递减的颗粒时间出来。编解码器像你这样将逻辑流完美封装到Ogg流中的过程称作 Ogg 映射【Ogg Mapping】或 编解码器映射【Codec's Mapping】。

        Ogg 映射包括：

1. 将逻辑流分成整数个包；

2. 定义颗粒位置如何转换，颗粒位置必须按非递减排序，必须确保可以用 上一个包的颗粒位置 算出 此包的颗粒位置。

3. 提供初始标头（和辅助标头）放在流开头；

4. 按前文编码。

        到此为止，我们把一个逻辑流 完美地 封装成了一个基本流。接下来，我们来看看解码。

肆：解码问题

        解码当然就是编码的逆过程：读取页，根据段表合成包，然后输出逻辑流。此外多了几步：检查页头、CRC校验等，判断是否有数据丢失。

        》》 页 丢失/错误 怎么办？

        如果丟页，你可以选择 跳过/报错 。一般而言，网络传输时常忽略错误，可能的话要求重传数据；文件解析时 常抛出异常；页头错误建议忽略，但CRC校验错误、段表错误是不应忽略的（说明数据异常），这时又要选择 跳过/报错。

        跳页的方法就是重新定位。如果异常页的 上一页有未完成的包 / 下一页有续包，都要丢弃。丢失的数据 跳过 / 用黑屏、静音等糊弄过去，如果丢失太多，那还是报错吧。

        最恶心的情况：因为段表错误，无法正确读取异常页的数据，也就找不到下一页。这种严重错误十有八九可以被CRC校验出来（这时你已经读完错误的页了）。这就只能回移指针到页头段表处，用重新定位下一页。

        》》关于 捕获/定位

        定位Ogg流时，因为单页最大65307字节，读取65307B后还没找到定位域，可以直接报错 “非法的Ogg流”。

        查找 和 定位 操作在libogg库里都叫seek函数（该死的官方），为了区分我在自己的代码里用capture( )方法指代定位。capture有两种实现：一种是调用capture后指针就位于页头；一种是capture( )返回下一页到指针的偏移量。个人偏爱第一种：不需要把指针移回去。

        如果你已经完全掌握，可以用自己擅长的语言写一个 Ogg 基础解析库了。需要小试牛刀的话，这里有【Vorbis测试音频】，下载后缀.ogg的文件，测试你的程序吧。

        不满足的往下看。

【原作者：神武竹 • 未经允许，禁止转载】

---

「高级」

       这一节讲解在 编解码单个逻辑流 的基础上，Ogg容器的高级功能。Xiph官方liboggz 库在libogg库的基础上实现了这些功能，代码参考gitlab-liboggz。

>> 多路复用

        我也不知道我在前文写了几个“见多路复用”了，Xiph用了整整一篇文档描述它，但千万不要把它想高级了：Ogg追求简单！

        多路复用【Multiplex，或译“多路传输”】，以下简称Mux。指把多个 基本流 按时间顺序混合、交错成为 复合流 的过程。Mux使得视频、音频、字幕、弹幕等可以被混合在同一个传输流中，解码时同时播放。

         Mux时，交错的是页，所以页本身是保持不变的。把页想象成扑克牌，几副 花色不同的牌 混在一起，但牌还是牌。要想把混合的牌还原，只要挨个看牌，把同一花色（流序列号）的牌按数字顺序（颗粒位置）放一起即可。Mux 和 Demux 多路分解【Demultiplex，即multiplex的逆过程，或译“多路分配”】对于计算来说很简单。如图：

        

基本流的Mux   “OggS”表示页    同色表示同一基本流

         综上所述，页是Mux/Demux的最小单位。所以我们要搞懂的，就是不同流的页怎么个交错法儿。

         回到上面的那张图：

       我们可以看到 ：红、蓝、绿 三个基本流的BOS页（图中 initial）被一同放在复合流的最前面，其后的页无规律地排列，三个流的EOS页（图中 term）也不在一起。因此：

       MUX一：基本流的BOS页一同放在复合流最前面。BOS页之间不能插入非BOS页，但顺序无要求。

        MUX二：基本流的EOS页不需要放在一起。因为基本流没有必要同时结束。

       BOS页有初始标头包，标记逻辑流的数据类型。解码时，只需读完所有BOS页，就可推断此流是否是复合流，以及复合流有几个基本流 ，每个流的数据类型和流序列号，从而使解码器调用对应的编解码器。

       

        如果在上图中，去掉其他页，只看红色的页，从左到右是红0、红1、红2、红3 ……红n。基本流的页依然保持原始先后顺序。

       MUX三：同一基本流的页，彼此之间保持原先后顺序。

       逻辑流还可能有辅助标头。

       MUX四：BOS页全部结束后，所有基本流的辅助标头（如果有）的页紧随最后一个BOS页后出现，互相交错无顺序要求。辅助标头页之间不能出现非辅助标头页。辅助标头页全部结束后数据页开始。

        初始标头和辅助标头只提供编解码信息和其他信息，而非原始数据，所以它们的颗粒位置理应为0（非硬性要求，保持非递减即可）。

       MUX五：数据页根据颗粒位置，按时间顺序交错。这是说，把每页的颗粒位置转换为同一单位的绝对时间，按时间顺序依次插入。例如两个流混合：（字母表示页，大小写表示流，数字表示页的颗粒位置）

       视频流｜帧率  60帧/秒       ｜A 0   B 24   C 33   D 60   E 84

       音频流｜样本率  44K个/秒 ｜a 0   b 8800   c 16500  d 26400  e 39600

        把他们的颗粒位置转换为统一单位毫秒：

       A 0ms    B  400ms    C 550ms    D 1000ms    E 1400ms

       a 0ms     b  200ms    c 375ms     d  600ms     e  900ms

       按时间排序：0 - 0 - 200 - 375 - 400 - 550 - 600 - 900 - 1000 - 1400

       混合结果：A a b B c C d e D E

        此外，时间相同的可以任意插入，比如A a亦可以是a A。（我推荐视频帧在音频帧前面，毕竟解码复杂度不一样）颗粒位置为-1的页的最好紧跟同流的前一页，免得解码器用缓冲等。

       如果你需要复合流来测试程序的话，抱歉找不到较小的ogv视频（目前只有Theora视频是复合流），官方提供较小的英文宣传片是《Digital Show & Tell》。包含一个复合流，由十个基本流构成（已知包括视频、音频、字幕、索引）。下载目录在这里，最小的是360P分辨率、117MB大小。

        （2024更新）Xiph基金会的wiki中有专用于Theora的测试短片，大小只有几MB！网址-》https://wiki.xiph.org/TheoraTestsuite

>> 查找

        查找【seek】即跳转功能，转到某个时间重新开始解析，直观感受就是 视频/音乐 跳转到某一秒开始播放。也就是随机访问【Random Access根据具体位置访问数据的任意一部分】。

        查找分为低精度【粗精度】和高精度【细精度】。

        低精度查找：估算大致字节数，将指针向 前/后 移动一段距离，然后重新定位，检查页头的颗粒位置是否和目标位置对应，若相差较大，重复上述过程直至基本符合。（太tm简单粗暴了，翻译时愣是半天没看懂，以为很高级）

        高精度查找：低精度 + 二分查找算法。如果追求更高精度，还可以按包查找。按包查找时，只能使用同一逻辑流的页。（liboggz库没有实现按包查找）

        可见seek的本质就是：乱猜 + 硬找。不骗你，liboggz库里的seek( )主要调用的函数就叫 oggz_seek_guess() ……

        下面解答常见问题：

> FAQ

        Q ：我找到了相邻的两页，前一页的颗粒位置与目标时间误差 -700，后一页误差为 +500 ，是不是该选误差小的那一页？

        A ：官方文档认为总是应该找前一页，主要是保险起见。我认为视情况而定，连续流【见缓冲】可以找后一页（误差为0也应该用下一页）；非连续流找前一页（误差为0可太完美啦）；如果是复合流只能找前一页，参见下文。

        Q ：如何在复合流里查找？

        A ：因为多路复用是通过转换颗粒位置为统一时间单位，按时间顺序混合，查找时显然用不着多路分解。官方解法：

        忽略复用，通过转换颗粒位置为同一单位，正常「查找」到目标页，然后向前扫描，直到复合流中每个基本流都出现了至少一页。然后跳转到最前面（时间最早）的页（如果某页有依赖页（如视频的关键帧）该页的颗粒位置 = 依赖页，但这改变了颗粒位置的读取方式，意味着编解码器要改变Ogg容器代码才能实现，官方承认了这种耦合）。

        由于部分非连续流的页间隙较大，Ogg允许设置一个最大扫描页数。（我觉得直接不管非连续流更好）

        Q：Thoera是视频格式，需要关键帧，如何查找？

        A：好问！: )  目标时间转换为帧数。调用liboggz（或者自己写的代码）seek，如果恰好找到最后是关键帧的页，直接跳转到关键帧处；只找到中间帧则取颗粒位置前6个字节（关键帧的<总帧数>）作为目标再seek，恰好碰到关键帧同上；否则，切换为按包查找，向后搜索找到关键帧。统共需要「查找」两次，即双重查找【double seek】。

        官方：你也可以简单粗暴地查找中间帧，代价是必须等到下一个关键帧才能继续播放。令人惊讶的是，好多人都选择简单粗暴...

        Q：颗粒位置为-1的页怎么办？

        A：无视。

        补充：对于Ogg解码器而言，最理想的数据源是本地Ogg文件；可靠的流媒体传输（基于TCP的Http协议等）次之，注意：网络传输Ogg时不会发送EOS页，且EOS页一定是Nil页；不稳定可靠的流媒体传输（基于UDP的RTP协议等）又次之；无反馈传输（如卫星广播）最次，因为服务端只管发送，不管数据丢失，客户端也不能与服务端通讯。网络传输不一定能够实现seek功能，而本地Ogg文件肯定可以seek。

> 二分查找

        高精度查找使用插值二分查找算法，其实精度并不比低精度高，但是平均速度略胜一筹。

        1：确定流的两端B和E

        2：（指针）跳转到B和E的中间位置

        3：定位，读取页的颗粒位置。

        4：switch

                case 颗粒位置 == -1，  读取下一页；  回到第3步

                case 颗粒位置 < 目标，E = 当前坐标；回到第2步

                case 颗粒位置 > 目标，B = 当前坐标；回到第2步

                case 颗粒位置 == 目标，结束。

        当然算法也可以进一步改进：更高级的算法，即 计算页平均大小 和 页平均颗粒位置 得到平均比特率，就能更加精准地猜测位置，然后再二分查找。

>> 缓冲

连续性

       Ogg将逻辑流分为连续【Continuous】流 和 非连续【Discontinuous】流 两类。

       像音频、视频这样，时间上连续不断的是连续流。连续流的数据必须是不间断的，只要流尚未结束，一定能读取到更多的数据。

       像 字幕/弹幕 这样，时间上不连续的是非连续流。它们有以下特征：

1，不规则性。有时有，有时没有。

2，离散性。弹幕/字幕 是分散、彼此独立的，不像音视频数据一样前后相连。

3，随机性。尤其是弹幕，完全取决于用户操作。

        总之，它们本身不是流式数据，但必须作为流才能放在Ogg容器里，就是非连续流。

        补充：虽然连续流和非连续流组成的复合流中可以直接seek操作，但是如果按包查找，不能使用非连续流的页。

绝对颗粒位置

        前面我们说：页的绝对颗粒位置 是 该页上最后一个已完成的包 的颗粒位置。现在要自我否定一下：这种“末时间【end-time】”是针对连续流的；对于非连续流，页的颗粒位置是 <本页第一个开始的包的之前所有包的总时间>，而不是<总时间> + <此包的时间>，这种颗粒位置叫“初时间【start-time】”。一个包的初时间 = 上一个包的末时间。如果一页没有开始的包（非连续流几乎不可能使用续页，一般不会有这种情况），颗粒位置用 -1。

        多路复用时，忽略 末时间/初时间 的差异，直接按时间顺序混合即可。

        Xiph官网关于缓冲的内容充满歧义，均以下划线标出。如果你对任何一处有异议，一定要自己去看官方Ogg文档（如果你搞懂了，务必评论区指出本人谬误）。

        节选自原文《Ogg多路复用》-缓冲【buffering】：

Ogg缓冲基于一个简单的前提：在解码期间，不允许任何活跃连续流要求得到【stave for。 <编解码器 要求得到 数据>不合理，应为stave（缺乏）之误】数据；缓冲继续进行，直到【proceed ahead until.proceed为“继续进行” ahead可作“提前/向前”，个人倾向“向前”】物理流中的所有连续流一伸手就有准备好的数据以供解码。

非连续流的数据可能会经常出现，例如，在大多数字幕系统中，特定字幕的时间无法确定。因此，缓冲系统应该 到非连续数据来的时候【take ... as it comes还加了引号，意译“随遇而安”，但这里应是直译】 才进行处理，而不是提前（在可能是无限长的时间里）寻找将来的非连续数据。因此缓冲时，不连续流会被忽略；当连续流的页得到正确处理时，非连续流的页只会“掉出”【fall out，什么意思？】流。

缓冲需求 【buffer requirement】对于已编码的流不需要显式声明或管理流；解码器只需读取尽可能多的数据，保证所有连续流类型（也确保不连续流数据及时到达）无间隙 and no more/further【是“连续流数据没有更多的”还是“解码器不再进一步行动（即’罢了‘）”】，从而使缓冲对于给定流是隐式最优的【什么？】。因为所有数据类型的页在流中都被绝对计时信息【指绝对颗粒位置】标记，因此流间同步计时总是显式保持，而无需显式声明的缓冲区。

        这一段很晦涩，官方libogg库里也没有相应的实现。《Ogg比特流概述》的缓冲文段跟《Ogg多路复用》的基本一致，几个单词不同。大致解释一下即可：

        解码复合流时，缓冲区由连续流使用，非连续流没有缓冲区；解码器一旦读取到非连续流数据时，立刻自行处理；缓冲应是隐式的，对调用者透明。

>> Skeleton

        待续

---

「实现细节」

         本节不参考Ogg文档，而是根据 官方代码库 及 个人经验 提出 Ogg编解码器实现 的建议。这不是Ogg规格的要求。

>> Mux表

        mux/demux时，每个逻辑流（基本流）都有对应的序列号。为了更方便的mux和demux，liboggz库实现了一个表【table】。表是给调用者使用的，它把 流序列号 - 数据 以 键值对【key-value】的形式存成一张表，这里的数据可以是页（demux用）、包（mux用）、基本流。liboggz中 表用两个OggVector（Vector向量，自动扩容的集合）实现，显然，哈希表的效率更高。

        如果要实现更简单的API，可以把多路复用的过程也对调用者隐藏，这时候流表就可以派上用场了。

>> Mux层

（待续）

【原作者：神武竹 • 未经允许，禁止转载】

---

「其它」

>> MIME

       Ogg根据其存储的数据分三种：音频、视频、其它（拓展）。

       拓展Ogg文件是指：首先必须是多路复用Ogg流；其次必须包含Skeleton。当程序解码ogx文件时，能解码的流就解码，不能解码的直接忽略。拓展Ogg文件的主要作用是混合数据，例如把多首音乐组成的一首专辑 多路复用 成一个ogx文件。没有官方拓展名的文件也可以加上Skeleton后存储为.ogx文件，比如Ogg Kate。（ogx绝对不是指应用程序）

        与之对应，音频Ogg文件的MIME类型是audio/ogg（Mac文件类型码OggV）；视频Ogg文件是video/ogg（Mac码OggA）；拓展是application/ogg（Mac码OggX）。视频Ogg文件拓展名为.ogv；音频Ogg文件拓展名有.ogg（Vorbis）、.opus（Opus）、.spx（Speex）、.oga（通常指FLAC）、.ogm（已淘汰的MNG）；其它Ogg文件拓展名为.ogx。参见【XiphWiki MIME和拓展名】。

        Ogg Skeleton可以添加在任何一类Ogg文件中，在音频、视频文件中可有可无，但在其它文件中必须存在（因为ogx必然是复杂大文件）。

>> 初始标头规范

        上文：必须能够通过初始标头确定编解码器。所以每个初始标头肯定存在幻数 以确定数据类型。Xiph明确了部分数据类型的初始标头的幻数和版本字段（如果有）。一般来说幻数的长度是8字节（年代早的Vorbis和Theora是7字节，不属于Xiph的Dirac 和 原本不属于Xiph的FLAC是5字节），具体规范本文章不便列出，参见MIME类型和编解码器。

---

「不足」

        作者没有资格来评论Ogg，我不是它的开发者，也还没有亲自测试过。但我应把对Ogg的指责列出来，留给读者评判。

        对Ogg最刺骨的指责莫过于 2010年3月3日，FFmpeg程序员Mans Rullgard在个人博客上发表的《Ogg异议》了。这篇文章从头到脚地痛骂Ogg，最后直言“烂是对Ogg唯一合适的描述”。此前，他还有一篇文章指责Ogg的颗粒位置设计。这两篇文章引起轩然大波（以至于中网居然有此新闻）。

        看看这篇文章的评论区，“虚伪的自由软件倡导者，暗地操纵互联网控制权” “我们为什么要为了开源选择Ogg这样的东西” “以前坚决反对索引，现在又加，呵，真香” “Matroska也开源，不比它好？”“Xiph压根不解决问题，而是高呼专利专利专利”。我觉得咱们的网络环境也不是那么……

        这惹恼了Monty，Monty于4月27日发表了一篇文章“逐字逐句”地反驳（无考）。

        摘录Mans反对的理由如下：

1 浪费空间。32位的流序列号 、 64 位的颗粒位置、 32位页号 简直“不可理喻”，你用得了那么多吗？不用网络传输，强制的32位CRC有用吗？Ogg开销高达1%，MP4才0.05%！（简单的计算可以得出开销至少是0.4%，但官方称平均开销0.25 ~ 0.5%）

2 随机访问。Ogg反对索引，怎么在网络中定位？seek的效率您考虑了么？一个10GB的文件你要二分操作50次！Ogg根本就不是流媒体用的东西！

3 这“映射”麻烦的要死，真的考虑了通用性吗？哪里比得上Matroska的简洁？Ogg里能装什么？还不是你自己那几个破玩意（指Vorbis和Thoera）

4 多路复用是什么玩意？你知道延迟有多大吗？页这么大，活该延迟高。

5 颗粒位置。你设计这么麻烦给谁看？还转换？为什么是结束时间，开始时间不更容易播放吗？Theora的颗粒位置还更复杂！

6 复杂性。把数据包拆成碎片，要耗多少内存？物理流串联成链，这设计根本不会有人用。

        对于以上指责，Monty一一驳斥。说到底Ogg是用来存储文件和流媒体传输的，使得Mans的一些论点显然不成立（比如“Ogg为什么不能用UDP传输”）。Ogg当然不是完美的，单位Mans后来直接针对Xiph基金会进行道德谴责和引战，显然是在给自己挖坑。

---

「没了」

• 写作不易，感谢你的支持与指正。所有图片来源于Xiph官方或维基百科。

• 此篇仓促之中，尚有未完之处，除标注“待续”外，实例代码亦未添加。本人学生党，精力着实有限，偶执闲笔，玩笑之作，不得已随缘更新，烦请谅解。

<更新时间2022-8-22>

【原作者：神武竹 • 未经允许，禁止转载】