点播影院发行包中MXF 封装器的设计与实现

2024-02-06 05:38王木旺
现代电影技术 2024年1期
关键词:音视频哈希分区

王木旺

中国电影科学技术研究所(中央宣传部电影技术质量检测所),北京 100086

1 引言

近年来,为补充并发展壮大国内电影市场,国家电影局发布了《点播影院、点播院线管理规定》用于促进点播影院发展。同时,为了规范和提高点播影院系统及设备的国产化研制水平,发布《点播影院暂行技术规范》用于引导和规范点播影院系统及设备的研制。在点播影院系统及设备的研制中,点播影院影片发行包的制作是其重要组成部分,它决定了影片的编码方式、加密方式、画面质量、文件大小以及打包格式等。素材交换格式(Material eXchange Format,MXF)封装又是点播影院影片发行包制作中的一个重要环节,它需要根据影片所采用的编码方式、加密方式等来采用不同的封装规则进行封装。

但由于目前能够适用于电影发行包制作的MXF封装工具和软件并不多,且多是针对专业影院影片发行包制作的,尤其是由DCI 官方认可测试机构Cinecert 提供的Asdcp 开源软件只有针对JPEG 2000编码的MXF 封装库,并不能完全适用于点播影院发行包的MXF 封装制作。为降低放映设备成本,目前点播影院多采用市场上稳定且价格较低的AVC 和HEVC 解码芯片,并且近年来,在鼓励国家商用密码技术开发和推广应用的背景下,有厂商也开始采用SM4 等国密算法进行影片加密。这些新的需求也要求必须设计相应的MXF 封装器来满足未来的技术发展需要。

本文根据《点播影院暂行技术规范》中对点播影院的影片打包技术要求,并结合相关研究课题,设计和实现了一种MXF 封装器。

2 MXF 数据映射

点播影院电影发行包的制作需要经过音视频编码、加密(可选)、MXF 封装、打包等步骤。其中MXF封装就是将音视频文件根据所采用素材容器(Es‐sence Container)的不同,按照相应规则将数据映射到MXF 文件中的过程。MXF 是美国电影电视工程师协会(SMPTE)组织定义的一种专业音视频媒体文件格式,主要应用于影视行业媒体制作、编辑、发行和存储等环节,点播影院发行包中音视频的存储就采用该格式。

作为一种“容器”文件格式,MXF 文件格式与内容数据的格式无关,其底层使用了键‐长度‐值(KLV)三元组编码方式。其中键(K)是16 字节的标识符;长度(Length)是数据长度,采用基本编码规则(Basic Encoding Rules,BER)编码方式,它使用可变长的字节来表示非常宽的长度范围,按高字节优先(MSB)编码,如果第一个字节的bit7 为0,那么低7 位代表了数据的长度,如果bit7 为1,那么低7 位代表长度域的字节个数;值(Value)是要存储的具体数据。

MXF 文件分为文件头(File Header)、文件体(File Body)和文件脚(File Footer)三部分。但从数据存储逻辑上,又分为头分区(Header Partition)、体分区(Body Partition)、脚分区(Footer Partition)和随机索引(Random Index)四部分。头分区、体分区和脚分区中都是以分区包开始,后接该区存放的数据(图1)。

图1 MXF 数据分区

其中MXF 封装时,可对音视频数据直接封装,也可以先对音视频数据加密,再对加密后的数据进行封装,其封装的数据存放于体分区的素材容器中。点播影院电影发行包通常是按帧或视频片段进行数据映射,有特殊需求的也可以自定义。

未加密的数据按单元顺序存放于素材容器中的数据存储结构如图2所示。

图2 音视频数据在素材容器中的存储结构

若需要对音视频数据加密,则需要使用不同的键来做标识。为做区分,加密后的键用K´表示;加密信息和加密数据组合的数据作为KLV 三元组的值部分,并用V´表示;最后再将加密后的KLV 三元组映射到素材容器中,其音视频数据加解密关系如图3所示。

图3 加密数据和未加密数据的关系图

对于映射到素材容器中的数据,在MXF 文件中还必须对其进行说明和描述,便于发送者和接收者之间进行数据交互。这类信息都存放于头分区的元数据(Metadata)中,元数据也被称为描述数据的数据,按照功能作用分为结构元数据(Structural Meta‐data)和描述元数据(Descriptive Metadata)两种。结构元数据是MXF 文件的组成部分,用于定义内容实质结构的信息;描述元数据是可选项,用于描述文件中某些内容。

元数据必须以首包(Primer Pack)开始,首包中存储了MXF 文件中用到的所有唯一标识(Unique Identifier,UID)和本地标签(Local Tag)的映射关系,用于MXF 文件中各数据之间的链接、查找和关联。紧接其后的是前言包(Preface Pack),前言包存储了MXF 文件的总括性描述信息,包括音视频数据类型、操作模式、文件结构等。其后则根据业务需要,将各种元数据进行组合和添加,存储结构如图4所示。

图4 元数据存储结构

点播影院电影发行包中MXF 文件中用到的元数据有:标识(Identification)、文件描述(File Descrip‐tor)、内容存储(Content Storage)、源包(Source Pack‐age)、轨迹(Track)、序列(Sequence)、源片段(Source Clip)、素材包(Material Package)、时间线轨迹包(Timeline Track)、素材容器数据(Essence Container Data)。如果数据加密,还需要包括:描述元数据静态轨迹(DM Track)、描述元数据序列(DM Se‐quence)、描述元数据分段(DM Segment)、密码框架(Cryptographic Framework)、密码语境(Cryptographic Context)、加密算法(Cipher Algorithm)、消息完整性校验算法(MIC Algorithm)。MXF 元数据关系结构如图5所示。

图5 MXF 元数据关系结构图

由于映射到素材容器中的数据是由一系列的数据单元组成,在读取该数据时,为能准确快速定位到想要读取的单元,而不用每次从头读起,还需要对素材容器中的数据进行索引,其索引信息存放于文件脚的索引表中(图6)。

图6 索引表与数据单元关系

同样的原理,为了能够快速定位文件的头、体、脚三个区的起始位置,整个文件的最尾端存放随机索引包,随机索引包包含了文件每一分区的ID 号和起始位置,最后四个字节存放了自身的数据长度,便于读取该数据。

3 MXF 封装器设计

3.1 边界

MXF 封装器是点播影院电影发行包制作环节中重要的功能部分,它的核心功能是根据输入的音视频文件和封装、加密参数,按照相应的数据映射规则,将音视频数据处理后,输出到MXF 文件中。故MXF 封装器应该包含三个输入接口:音视频文件输入接口、封装参数接口、加密参数接口;一个输出接口:MXF 文件输出接口;一个交互接口:外部加密、哈希计算功能调用接口(图7)。

图7 点播影院发行包中MXF 封装器的功能接口

3.2 功能模块

为实现MXF 封装器的核心功能,在其内部需要具备如下几个功能模块。

(1)文件解析

MXF 封装器在对音视频文件进行封装之前,必须知道所处理的数据是音频还是视频,如果是音频文件,需要获取该音频的编码类型、采样率、声道数量、帧速率、帧数等;如果是视频文件,需要获取该视频的编码类型、分辨率、帧速率、帧数、宽高比等。其中所获取的编码类型用于MXF 封装在后续选取相应的映射规则,其它参数信息则用于MXF 封装在后期生成相应的元数据。

基于AVC 或HEVC 编码的视频数据,通常可以采用MOV 格式文件,无损压缩的音频数据通常采用WAV 格式文件,故本功能模块需要具有支持MOV 格式的视频文件和WAV 格式的音频文件解析能力。

(2)文件读取

MXF 封装器对音视频文件的读取要求比较特殊,由于电影对声画质量的要求比较高,点播影院发行包使用的音视频文件普遍较大,视频文件通常在几GB 到几十GB,封装器不能对该文件一次性全部读取,必须能够按照数据流的方式循环读取。这要求文件读取模块能够与后续的MXF 数据封装模块共享数据队列,文件读取模块能够将数据按块读入队列,MXF 封装模块按照先进先出原则,依次读出数据。当队列满时,文件读入模块等待;当文件队列空时,MXF 封装模块等待。

(3)信息参数设置

(4)MXF 数据封装

MXF 数据封装中又分为元数据封装、内容数据封装和其它数据封装。

元数据的封装比较复杂,首先元数据数量比较多且数据结构都不相同;其次是各个元数据之间有相互依赖关系;最后是每一个元数据中数据项中的数据还有不同的编码规则,如自定义的Rational 和Position 类型。

内容数据封装需要根据音视频的编码类型,采用不同的素材映射方式进行封装,AVC 有相关规范可以参考,HEVC 则需要参照其它规范来设计映射规则。对于采用AES‐128 加密、SHA‐1 计算哈希的音视频数据,可参照数字电影相关的素材加密规范;对于采用SM4 加密、SM3 计算哈希的音视频数据,则需要设计相关加密规则。

除了元数据和内容数据外,像图1 中描述到的文件头分区包、文件体分区包、文件脚分区包、索引表和随机索引表,这些统称为其它数据,它们主要用于对文件中各个区域或内容数据的位置标定,方便数据的快速查找和定位。

(5)MXF 输出

MXF 输出模块和文件读取模块类似,在对内容数据封装过程中,需要一边封装一边输出。该模块需要和前序的MXF 数据封装模块配合,共享数据队列,按照数据流的方式依次读取并输出。

(6)加密模块

式中:h热、h冷分别为试件的热面、冷面对流换热系数,W/(m2·K);δ为试件厚度,m;λ为填充板热导率W/(m·K).

该模块的功能实现是在MXF 封装器之外,但由于它和封装器关系紧密,并且会被封装器调用,这里也一并列出。加密模块中包含了对称加密和哈希计算,其中对称加密包含AES‐128 和SM4 算法;哈希计算包含SHA‐1和SM3算法。

4 MXF 封装器实现

根据上述章节的功能设计,MXF 封装器实现了用于参数设置的MxfSetter 类,用于音视频解析的FileParser 类,用于文件循环读取的FileReader 类,以及最重要的用于MXF 数据生成的MxfMaker 类和用于循环写出MXF 文件的FileWriter 类。各类之间的调用时序如图8所示。

图8 功能类时序图

MXF 封装器最重要的功能是MXF 数据生成类(MxfMaker)的实现,根据上述章节的设计,该类包含了生成MXF 头分区(WriterPartitionHeader)、MXF 体分区(WriterPartitionBody)、MXF 脚分区(WriterParti‐tionFooter)和随机索引包(WriteRandomIndexPack)四个主要函数方法。其中头分区函数WritePartition‐Header 通过对分区包类(HeaderPartitionPack)和元数据类(Metadata)的调用,实现对MXF 头分区的封装;体分区函数WritePartitionBody 通过对分区包类和素材容器类(EssenceContainer)的调用,实现对MXF 体分区的封装;脚分区函数WriterPartitionFooter 通过对分区包类和索引表类(IndexTable)的调用,实现对MXF 脚分区的封装;随机索引包函数WriteRando‐mIndexPack 通过对随机索引包类(RandomIndex‐Pack)的调用,实现对MXF 随机索引表的封装。Mxf‐Maker类与其它类的调用关系如图9所示。

图9 各类之间的关系示意图

HeaderPartitionPack 类在生成数据时,需要根据调用的函数来生成不同的分区包,其键值为固定值,MXF 文件在使用时也会根据该键值来判断是否为标准的MXF 文件。另外还需要初始化分区包起始位置、前一个分区位置、元数据的大小、索引包的大小、素材容器的ID 和位置、素材容器的标签、操作模式等。在点播影院发行包中规定了不加密时分区包中的操作模式有两种,一种是符合SMPTE 规范,该值为:0x06 0e 2b 34 04 01 01 02 0d 01 02 01 10 00 00 00;另外一种符合Interop 规范,该值为:0x06 0e 2b 34 04 01 01 01 0d 01 02 01 10 00 00 00。在点播影院发行包中也规定了素材容器的标签,当素材为加密数据时,该值为:0x06 0e 2b 34 04 01 01 07 0d 01 03 01 02 0b 01 00,如果为不加密数据,需要根据使用的素材容器来决定标签,当映射AVC 时,该标签为:0x06 0e 2b 34 04 01 01 0a 0d 01 03 01 02 10 60 04,当映射音频数据时,该标签为:0x06 0e 2b 34 04 01 01 01 0d 01 03 01 02 06 01 00。

Metadata 类在生成数据时,则需要将用到的所有元数据都进行赋值。为节省空间,每个元数据的标签在MXF 文件中采用2 个字节的Local 标签代替16个字节的唯一标识(Unique Identifier,UID),但为了在解析各元数据的时候能够准确知道Local 标签的含义,则需要在Primer 包中对这两种标签一一对应,其对应关系的数据结构如表1所示。

表1 Local标签与唯一标识对应的数据结构

IndexTable 类在生成数据时,需要标记出素材容器中每一个数据单元相对字节偏移量,由于点播影院发行包中规定,MXF 文件中只能有一个素材容器,索引表也不能进行分割,并且只能存储在MXF 脚分区中,因此该类数据在生成时相对简单。但需要注意的是在对加密的数据进行索引时,还需要考虑加密过程中增加的加密信息和填充字节,从而引发原偏移量改变。

RandomIndexPack 类所生成的数据,在MXF 的相关规范中规定必须存放于MXF 文件结尾部分,并且通过它能够从整个MXF 文件中快速扫描到需要访问的数据区域,所以该数据必须包含多个分区数据ID值和相对偏移位置的数据集合,其数据结构如表2所示。

表2 随机索引包数据结构

5 测试及应用

5.1 功能测试

按照上述设计,通过编程实现MXF 封装器后,为验证该封装器对采用AES‐128 或SM4 加密,以及采用SHA‐1 或SM3 哈希算法校验后的数据能否在元数据中准确描述,本文采用了第三方的MXF 分析工具对其封装完成的MXF 文件进行了解析。

其中采用AES‐128 加密和SHA‐1 哈希算法的MXF 文件解析后,Cryptographic Context 元数据中的Cipher Algorithm 字段UniversalLabel 值为:0x06 0e 2b 34 04 01 01 07 02 09 02 01 01 00 00 00;数据加密算法标示符识别为:AES‐128 CBC Identifier。Crypto‐graphic Context 元数据中的MIC Algorithm 字段Uni‐versalLabel 值为:0x06 0e 2b 34 04 01 01 07 02 09 02 02 01 00 00 00;哈希算法标识符识别为:HMAC‐SHA1 128‐bit Identifier。可以看出,第三方MXF 解析器能够准确识别出该加密算法和哈希算法。

采用SM4 加密和SM3 哈希算法的MXF 文件解析后,Cryptographic Context 元数据中的Cipher Algo‐rithm 字段UniversalLabel 值为:0x06 0e 2b 34 04 01 01 07 02 09 02 01 10 00 00 00;数据加密算法标示符识别为:Unknown RP 224.9 sub‐node of "Data Encryp‐tion Algorithm Identifiers";Cryptographic Context 元数据中的MIC Algorithm 字段UniversalLabel 值为:0x06 0e 2b 34 04 01 01 07 02 09 02 02 10 00 00 00;哈希算法标识符识别为:Unknown RP 224.9 sub‐node of"Data Hashing Algorithms"。可以看出,第三方MXF解析器并未能识别出该加密方式,仅列出了该加密算法和哈希算法的UUID 值。这是由于SM4 和SM3的算法并未列入到SMPTE 相关标准中,而第三方MXF 解析器是基于SMPTE 相关标准研制,所以未能正确检出,但根据本文的设计和对比,能够确认该UUID 正确。并且在后期的应用中,相应的点播影院播放系统会对该加密算法做兼容处理,故该功能合格。

5.2 封装器在发行包制作系统中的应用

本文通过编程实现后的MXF 封装器,结合编转码、DCP 打包和KDM 制作功能模块,最终集成了一套可应用于点播影院电影的发行包制作系统。该系统包含了编码/转码模块、MXF 封装模块、DCP 打包模块、KDM 制作模块以及系统设置模块。通过该系统,可实现音视频文件的编转码;可对音视频文件进行AES‐128 加密或SM4 加密,并对加密后的数据分别封装生成MXF 文件;可通过DCP 打包功能模块,选择封装完成的MXF 文件,制作点播影院影片发行包;还可以通过KDM 制作功能,选择采用RSA‐2048非对称加密算法、SHA‐1 哈希校验算法,或采用SM2非对称加密算法、SM3 哈希校验算法,来制作相应播放终端设备的KDM 授权密钥。

本文通过该点播影院电影的发行包制作系统,选择了一组影片分别采用国密和非国密两种方式进行了点播影院影片发行包的制作,并对制作完成的发行包进行了文件解析和分析,均达到功能设计要求。进而又制作了多部影片的电影发行包和授权密钥,并在本文配套的其它研究成果——点播影院激光放映一体机上进行了放映实验,均能正常流畅放映。

6 结语

MXF 封装是数字电影发行包制作中的重要一环,本文研究的一种适用于点播影院影片发行包制作的MXF 封装器,可以适用于采用AVC 和HEVC 编码的影片,未来还可以进一步拓展应用于采用AVS3和VVC 编码的影片。另外该封装器也可以适用国外和国家密码算法,能够为国家商用密码在国内电影市场的推广应用起到一定的探索作用,期望文中的论述能够对研制点播影院相关系统和设备的人员有所参考。

猜你喜欢
音视频哈希分区
上海实施“分区封控”
3KB深圳市一禾音视频科技有限公司
WIFI音视频信号传输的关键问题探究
浪莎 分区而治
高速公路整合移动音视频系统应用
基于OpenCV与均值哈希算法的人脸相似识别系统
基于维度分解的哈希多维快速流分类算法
基于SAGA聚类分析的无功电压控制分区
基于多种群遗传改进FCM的无功/电压控制分区
Roland专业音视频新技术研讨会在上海召开