MXF文件结构浅析

MXF是英文Material eXchange Format(素材交换格式)的缩语。MXF是SMPTE(美国电影与电视工程师学会)组织定义的一种专业音视频媒体文件格式。MXF主要应用于影视行业媒体制作、编辑、发行和存储等环节。SMPTE为其定义的标准包括:SMPTE - 377M、SMPTE - EG41、SMPTE - EG42等,并不断进行更新和完善。它是一个外壳格式 而不是压缩格式, 所以并不能保证每一款MXF文件 都能被任何一种解码器识别。

MXF标准并非一成不变,一直在发展。SMPTE中MXF相关标准已经有几十个文档,并且仍然在补充增加,SMPTE定义的只是MXF框架和一般原则,具体实现由各厂商自行完成,各大厂商自己实现的MXF,往往在新产品中也会发生一些变化。

1.MXF文件基本结构

MXF文件包括三个主体部分:文件头、文件体和文件尾。

文件头提供文件的整体信息,包括用于解码文件中所有视音频数据的解码器列表等。文件体由存储在要素容器中的视音频数据组成,来自不同数据轨(如视频、音频和时码)的要素容器可能交错和分离地存储在文件体中。文件尾用以结束一个MXF文件,包括一些在产生文件头时还不确定的信息,如文件的视音频长度等,文件尾的信息在某些场景中常常被忽略。

MXF文件也可包含一个可选的索引表(Index Table),该索引表可用于将基于采样的索引(如时码)快速换算到对应的要素容器在<spanlang="en-us>">MXF文件中的偏移地址,以实现视音频的快速预览和定位。该索引表可分段存储,可位于基本数据段之前或之后,也可分插到基本数据段中间。

2.MXF底层数据结构

MXF文件的所有数据都采用Key-Length-Value(KLV)进行编码以获得格式的灵活性和可扩展性,KLV编码标准定义在SMPTE 336M中。实际上MXF文件就是若干连续KLV数据包的序列(除了可选的RUN-IN包)。

the key identifies the data, the length specifies the length of the data, and the value is the data itself

  • Key:16字节的标识符。
  • Length:数据(Value域)长度。BER(basic encoding rules )编码方式,如83 00 00 88。

    它使用可变长的字节来表示非常宽的长度范围,该域总是按MSB(高字节优先)编码,如果第一个字节的bit7为0,那么低7位代表了0~127范围的长度,如果bit7为1,那么低7位代表长度域的字节个数。
  • Value:KLV单元中包含的数据

3.MXF的逻辑结构

MXF文件的逻辑模型是一种基于对象的数据结构,主要由头部元数据中的结构元数据定义。结构元数据主要分为两类,一类是与实践特性有关的结构结构元数据包(Structural Metadata Package),一类是与素材或素材容器的特征参数相关的描述符(Descriptors)。每个结构元数据包有1个或多个轨迹(Track)组成,每个轨迹是一段具有起始时间点、编辑速率的时间线,由一个具有一定持续时间的序列(Squence)组成,每个序列又由1个或多个源片段(SourceClip)组成。包(Package)、轨迹(Track)、序列(Squence)、源片段(SourceClip)通过UUID相互引用。

顶层文件包中的每一个轨迹分别对应内容容器中不同的类型并有相应的描述符描述素材的特征信息,如像素、采样率、画幅比、声道数、比特数等。素材包通常为文件的输出时间线,确定在播放或使用时文件中哪个内容容器中的哪些内容被播放,以及这些内容如何同步。素材包中的源片段通过UUID引用,链接到顶层文件包中的某个轨迹。而素材元素元数据(EssenceContainerData)将顶层文件包和具体的素材容器及相应的索引表相互关联起来。

4.MXF文件分析

我们可以通过 MXFExpressAndMXFDesktop_120 和 MXFInspect工具来帮助我们分析MXF文件,这里以op1A 文件为例。

4.1.首先是文件header分区的partition信息。

4.2.字典,指明了16字节Key到2字节Tag的映射关系

4.3.preface:相当于MXF文件的序言,指明了Source Package 和Material Package的UID(通过ContentStorage包含)

4.4.contentstorage :指明了 SourcePackage(FilePackage)和MaterialPackage以及EssenceContainerData的UID

4.5.EssenceContainerData:将素材容器的BodySID和相应索引表的IndexSID关联起来,并指明了FilePackage的UID

4.5. MaterialPackage:素材包,它里面的SourceClip通过UUID引用到了SourcePackage里的某个Track

链接的SourceTrack

BodyPartition里的Essence

4.6.EssenceDescriptor:描述了SourceTrack里面的Essence的信息

4.7.IndexTab:记录每帧在自己所属的Essence中的偏移

其结构可以简单的用下图来粗略的描述

时间: 2024-10-09 03:32:25

MXF文件结构浅析的相关文章

class文件结构浅析(2)

欢迎转载,转载需声明出处 ------------------ 请先看上一篇:Class类文件结构浅析 上一篇讲的都是理论,下面我们亲自实践一下. 首先编写一个简单的java类: public class Test { private int m; private String str; public int func(int m,String str) { str += "OK"; m = 10; return -1; } public static void main(String

Class类文件结构浅析

欢迎转载,转载需注明出处! ------------- 前言 class文件时java虚拟机执行引擎的数据入口,也是java技术体系的基础支柱之一,了解class文件的结构对后面进一步了解虚拟机执行引擎有很重要的意义. 概要: class文件是一组以八位字节为基础单位的二进制流,各个数据项目严格按照顺序紧凑地排列在class文件中,中间没有添加任何分隔符,这使得整个class文件中存储的内容几乎全部都是程序运行的必要数据,没有空隙存在.当需要占用8位字节以上的空间数据时,则会按照高位在前的方式分

android学习笔记--android启动过程之init.rc文件浅析

1.  init.rc文件结构文件位置:init.c  : /system/core/initinit.rc  : /system/core/rootdir 首先init.rc文件是以模块为单位的,每个模块里的内容都是一起执行的,模块分为3种类型:on.service.import.我们可以看下init.rc文件是怎么写的:1.import import /init.usb.rc import /init.${ro.hardware}.rc import /init.trace.rc 上面的内容

java语言安全机制浅析

java通过所谓的沙箱安全模型保证了其安全性,下面我们就来看看java提供的安全沙箱机制. 组成沙箱的基本组件如下: 1.类装载器结构: 2.class文件检验器: 3.内置于java虚拟机(及语言)的安全特性: 4.安全管理器及java API. 一.类装载器体系结构 1.防止恶意代码去干涉善意的代码. 这是通过为不同类加载器提供不同的命名空间来实现的,在java虚拟机中,在同一个命名空间内的类可以直接进行交互,而不同的命名空间中类甚至不能觉察彼此的存在,除非显式地提供允许它们交互的机制. 2

浅析MSIL中间语言——基础篇

一.开篇 研究MSIL纯属于个人喜好,说在前面MSIL应用于开发的地方很少,但是很大程度上能够帮着我们理解底层的原理,这是我了解MSIL的主要原因.托管代码表示应用程序的方法的功能,它们以微软的中间语言(Microsoft intermediate language,MSIL)或公共语言运行(common intermediate language,CIL)的抽象二进制形式进行编码. MSIL代码由CLR“托管”.CLR托管至少包括三个主要的活动:类型控制,结构化异常和垃圾收集.类型控制设计在执

MySQL redo log及recover过程浅析

写在前面:作者水平有限,欢迎不吝赐教,一切以最新源码为准. InnoDB redo log 首先介绍下Innodb redo log是什么,为什么需要记录redo log,以及redo log的作用都有哪些.这些作为常识,只是为了本文完整. InnoDB有buffer pool(简称bp).bp是数据库页面的缓存,对InnoDB的任何修改操作都会首先在bp的page上进行,然后这样的页面将被标记为dirty并被放到专门的flush list上,后续将由master thread或专门的刷脏线程阶

松下p2卡MXF恢复过程与思路

太原某电视台松下机器拍摄的P2卡,误操作导致数据全部丢失,因为拍摄的节目需要播出,只能加班至此恢复数据,一般松下的格式化话或许删除之后数据直接清零的居多,客户运气还算较好,底层数据没被清除! P2卡的音频以及视频是分别存储在不同目录的,但是在物理层面是连续存储在一个未分段的数据块内,因此统一对这些数据块进行提取,算是完成第一阶段的工作,然后,我们根据客户提供的样本进行了存储结构分析,发现存储有一定的存储规律,但是遗憾的是根据规律恢复的数据是失败的,因为提取出来的数据100%全部存在问题,出现花屏

Java网络编程和NIO详解8:浅析mmap和Direct Buffer

Java网络编程与NIO详解8:浅析mmap和Direct Buffer 本系列文章首发于我的个人博客:https://h2pl.github.io/ 欢迎阅览我的CSDN专栏:Java网络编程和NIO https://blog.csdn.net/column/details/21963.html 部分代码会放在我的的Github:https://github.com/h2pl/ Java网络编程与NIO详解8:浅析mmap和Direct Buffer 之前看到一篇文章说epoll中在维护epo

MXF视频文件损坏的修复方法

MXF是SMPTE(美国电影与电视工程师学会)组织定义的一种专业音视频媒体文件格式.MXF主要应用于影视行业媒体制作.编辑.发行和存储等环节,由此可见MXF文件的重要性. MXF文件在拍摄中意外断电.关机等误操作会导致MXF文件无法播放(或者仅生成RSV文件),此时就需要修复文件就可以还原原始素材. 再优秀的文件结构也会出现意外,MXF也不例外,通过对已处理的恢复案例进行总结发现,MXF也存在和MOV一样的断电"封装"问题.什么是封装呢?简单的说就是摄像机首先是按照MXF要求的标准采集