我正在尝试解析基于 ISO/IEC 14496-12 的文件(本质上是 MPEG-4 电影)。有一些框不在标准中(或在 MP4 注册机构列表中),但在实际文件中。它们大多很容易追溯到 QuickTime 或类似的,只是实现没有更新。
我正在努力使用 GPS 定位框 (
©xyz
)。
这是一个例子:
0x00, 0x00, 0x00, 0x1e, 0xa9, 0x78, 0x79, 0x7a,
0x00, 0x12, 0x15, 0xc7, 0x2b, 0x34, 0x31, 0x2e,
0x33, 0x37, 0x35, 0x38, 0x2b, 0x30, 0x30, 0x32,
0x2e, 0x31, 0x34, 0x39, 0x32, 0x2f
前八个字节是盒子长度和盒子名称。没问题。
接下来的四个字节是未知数:
0x00, 0x12, 0x15, 0xc7
。
剩余字节是文本“+41.3758+002.1492/”,这是预期的 根据 ISO 6709(尽管不是 2023 版本)的纬度和经度(巴塞罗那)。
对于未知数,我可以将前两个字节解释为 16 位(无符号)整数,它与文本中的字符数匹配。但这只是猜测。
接下来的两个是个谜 - 可能是常数,因为我在澳大利亚的不同设备生成时看到相同的
0x15 0xc7
值。
这个盒子的定义结构是什么,是否有定义该结构的已发布规范?
两个神秘字节
0x15 0xc7
是基于MPEG4Extractor.cpp的语言代码en
但这只是推断 - 最终,如果没有发布的规范(或对多个样本进行更深入的逆向工程和分析),准确确定字节的含义实际上是不可能的。制造商/设备特定编码不存在这样的公共规范是完全可行的。
顺便说一句,我个人会尝试生成具有不同区域设置、语言等的多个文件,以了解这可能如何影响元数据编码。
正如@Fraser 指出的,
0x15 0xc7
确实代表语言代码“英语”。然而,它实际上是有记录的。这些 16 位属于 Quicktime 的 Language List Atom,查看该表您会发现 5575 (0x15 0xc7)
等于“‘eng’(英语)的打包 ISO 代码”。