为了编写我自己的ogg-container-class(不使用libogg),我尝试了解所需的头格式。根据{{3}},在流的字节27处(开始计数为0)开始“segment_table(包含分组存储值)”。这是红色标记的字节13
。关于我想要包含的Opus数据,Opus数据spec的开头是OpusHead (4F 70 75 73)
。为什么不从位置27开始,红色13
被放置? 13
是“设备控制3”符号,既不出现在Ogg规范中,也不出现在Opus规范中。
编辑:我发现must稍微描述了规范。在那里,13
(字节27)是以下段的大小变得清晰(不是来自第一个链接imho)。
答案 0 :(得分:1)
这似乎是一个单字节,给出了以下segment_table数据的长度。因此,segment_table数据有13个(十六进制)字节(16个十进制)字节。
答案 1 :(得分:0)
RFC 3533是格式标题的详细描述。
字节26表示段表占用了多少字节,因此您读取它,添加27,并告诉您第一个数据包的起始位置(或继续)。
段表告诉您封装数据包的长度。基本上,您通读表,将每个连续字节中的值相加。如果您刚刚添加的值是<然后255标记数据包边界,因此记录累加器的当前值,将其重置为零,然后继续直到到达表的末尾。
在您的示例中,字节26中的段表大小为1,因此数据从27 + 1或字节28开始,这是' OpusHead'串。 1字节段表中的值是0x13,因此数据包长度为19个字节。 28 + 19是47(或0x2f),它是' OggS'的开始。在下一个标题的开头捕获模式。
这个稍微复杂的算法被设计用于存储具有有限开销的许多小数据包的成帧数据,同时仍然允许任意大的数据包。另请注意,数据包可以在页面之间继续,跨越2个或更多段表。