中中央电视台_MXF技术研讨.ppt_第1页
中中央电视台_MXF技术研讨.ppt_第2页
中中央电视台_MXF技术研讨.ppt_第3页
中中央电视台_MXF技术研讨.ppt_第4页
中中央电视台_MXF技术研讨.ppt_第5页
已阅读5页,还剩24页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、MXF技术研讨,陈述主题,MXF概述 CCTV使用MXF业务范围研讨 MXF的相关技术问题研讨 操作模式( Operational Pattern) 流方式和文件方式 MXF元数据的考虑 视音频文件绑定/分离 MXF内的索引表信息 视频和音频数据的编码格式 Clip Wrapping方式和Frame Wrapping方式,MXF产生的背景,MXF文件格式于1999年7月在Pro-MPEG论坛的技术会议上被首次提出; 在Pro-MPEG论坛中完成其技术工作后,MXF已被提交给SMPTE进行进一步的标准化; 目前主要由Pro-MPEG论坛,AAF协会,EBU,Sony,INESC进行MXF标准化的

2、促进工作以及MXF SDK的开发; MXF有望成为电视行业中一种最重要的元数据和视、音频数据的交换格式。,MXF的基本思想,MXF(Material eXchange Format) 如同带有内容简介和产品说明的光盘一样, MXF文件实质上就是带有对视音频信息说明的 视音频文件。 MXF文件内可存放各种压缩和非压缩格式 的视、音频数据,并且由于考虑到了对未来压 缩方案的支持,MXF文件格式具有相当的灵活 性和可扩展性。,MXF的特点,开放的,标准化的; 压缩无关(可封装各种压缩格式的视、音频数据),平台无关(适用于各种主流的操作系统和网络平台); 灵活的,可扩展的; 既能以流,也能以文件的方式

3、进行传递和存取,并可在中断后恢复; 封装了丰富的元数据;,MXF标准希望实现如下目标,将现有的众多难以相互兼容和交换的视音频数据格式, 统一打包成MXF数据格式, 实现视音频素材在不同软、硬件平台之间的无缝可交换, 使得素材从采、编、播到制作发行的整个工作流程更加顺畅, 每个工作模块只需专注于自己的核心业务, 不用再考虑具体的视音频格式, 从而大大的提高生产效率. 但现实的情况比较复杂, 这使得MXF标准不得不针对许多不同的情况制定特殊的子标准, 于是逐渐形成了一个比较庞大的体系结构:目前是7大类和32个子标准. 具体来讲, 这7大类分别是工程指南性质的标准(Engineering Guide

4、lines), 文件格式和编码标准(Format and Encoding), 操作模式标准(Operational Pattern), 基本数据容器标准(Essence Container), 描述性元数据标准(Descriptive Metadata), 字典和注册标识标准(Dictionaries and Registries), 特殊注册产品封闭兼容性标准(Product-specific Registered Disclosure Documents).,什么是Operational Pattern?,MXF文件结构,MXF文件中的元数据,Structural Metadata De

5、scriptive Metadata 产品信息 素材信息 和场景信息,MXF文件通常以两种方式打包,Clip Wrapping,Frame Wrapping,MXF应用中的相关技术,UMID(Unique Material Identifier); XML(eXtensible Markup Language); KLV(Key-Length-Value)编码方式;,MXF文件的元数据解析,第一步, 一般先要判断所读取的文件是否为MXF文件, 这可以通过读取文件头, 看其是否为Header Partition Pack来判断, 需要注意的是, MXF标准允许最大65536个字节的任意数据的Ru

6、n-In存在, 因此, MXF解码器应该有相应的容错机制; 第二步, 对于有多个Body Partition的MXF文件, 首先要到文件尾读取Random Index Pack, 由其中的信息得到每个Partition Pack的起始位置; 对于只有一个Body Partition的MXF文件, 从Header Partition开始, 顺次解析即可; 第三步, 从Header Partition开始, 依次解析每个Partition中的可能含有的Header Metadata, Index Table, 如果Partition中含有Essence Container, 还要确定Essence

7、 Container在文件中的偏移位置; 第四步, 根据Header Metadata中的信息, 确定视音频数据的格式, 生成方式以及素材输出时间线的信息;,MXF视频帧定位,Frame Wrapping方式,MXF视频帧定位,Clip Wrapping方式,MXF音频采样定位,音频数据都放在Sound Item中, 读取的方式与视频数据类似. 不同之处在于, 读取音频数据时, 往往需要一次性读入1秒或数秒的采样数据, 因此对以Frame Wrapping方式打包的音频数据, 一个Sound Item中的数据量往往不够(比如25frame/s的情况, 一个Sound Item中只有1920个采

8、样的音频数据), 这时, 需要多次定位并读取多个Sound Item中的音频数据, 拼接成一个大的数据缓冲. 另外, 对于多个Body Partition的情况, 出于同样的原因, 如果某个Body Partition中存储的音频数据不足, 可能需要把若干Partition中的音频数据做一次拼接,MXF文件写入,初始化Header Partition Pack并写入文件; 初始化Header Metadata并写入文件; 初始化并写入Body Partition Pack; 以Clip Wrapping方式或Frame Wrapping方式打包视音频数据, 同时在缓存中建立Index Tabl

9、e, 如果要写多个Body Partition, 则在下一个Body Partition Pack之后写入Index Table, 并在Random Index Pack中记录每一个Body Partition的起始位置; 在所有的视音频数据都打包完之后, 写入Footer Partition Pack和最后一个Body Partition的Index Table; 写入Random Index Pack; 修改每个Partition Pack的状态为“Closed and Complete”, 同时修改每个Partition Pack中Footer Partition的位置.,陈述主题,MX

10、F概述 CCTV使用MXF业务范围研讨 MXF的相关技术问题研讨 操作模式( Operational Pattern) 流方式和文件方式 MXF元数据的考虑 视音频文件绑定/分离 MXF内的索引表信息 视频和音频数据的编码格式 Clip Wrapping方式和Frame Wrapping方式,CCTV使用MXF业务范围研讨,成品节目或素材在业务子系统间的交互 成品节目或素材在媒资子系统的保存和整体播放 成品节目或素材的打点播放,搜索,审核 成品节目或素材参与到编辑流程 成品节目的流发布 编辑列表单的保存和利用,陈述主题,MXF概述 CCTV使用MXF业务范围研讨 MXF的相关技术问题研讨 操作

11、模式( Operational Pattern) 流方式和文件方式 MXF元数据的考虑 视音频文件绑定/分离 MXF内的索引表信息 视频和音频数据的编码格式 Clip Wrapping方式和Frame Wrapping方式,操作模式,MXF和AAF相同之处: MXF和AAF都使用相同的数据模型, 也就是说, 它们用同样的数据结构表示时间线(Timelines), 实体数据描述(Descriptions of Essence)和其它元数据信息1. 理论上, 能够解析AAF文件的应用程序应该也能够解析MXF文件. 因此我们可以认为MXF和AAF包含了相同的EDL信息, 对视音频数据的描述信息(包括

12、压缩格式, 帧数据索引)以及其它的一些必要的元数据信息. MXF和AAF的不同之处: MXF不包括transition和layering functionality1, 也就是没有特技信息. 这使得AAF主要用于后期制作过程中的交换, 而MXF主要用于前期素材的采集和最终素材的发布.,操作模式,初始阶段建设选择OP1A 无Sony,Panasonic,Seachange的其它样例文件 可实现性和可交互性,流方式和文件方式,文件方式的应用: 最重要的无疑是可以随机定位视、音频数据的Index Table了. MXF标准提供了比较完备的Index Table数据结构, 不仅可以定位视频帧数据、音频

13、采样数据、字幕数据、控制数据等, 还可保存每个视频帧的关键帧偏移(Key-Frame Offset), 显示顺序到编码顺序的偏移(Temporal Offset)等, 非常方便应用程序的Play, Seek操作; 流方式的应用: MXF数据全部以KLV(Key-Length-Value)方式打包, 各种元数据以及视、音频数据等全被切分成相对独立的小块, 打包在KLV包中. 这使得MXF数据在以流方式传输时, 如果应用程序不能识别Key, 仍然可以通过Length知道Value的长度, 从而忽略整个KLV包, 而不影响后面数据的读取. 当中间有损坏的KLV包时, 应用程序也可以等待接收到新的Ke

14、y开始新一轮的KLV解析.,流方式和文件方式,MXF文件支持两种方式 CCTV的前端应用仅用到文件方式 初始阶段建议选择文件方式,MXF元数据的考虑,MXF元数据起标签作用 编目信息利用DB来管理,交换采取MXF+XML方法,MXF的Metadata到底有哪些?,输出的时码信息: 在MXF的Material Package中, 分别按照时码轨, 视频轨, 音频轨, 数据轨和描述性元数据信息(Descriptive Metadata, 简称DM):描述了最终输出的素材时码信息. 上述轨道的数据结构基本相同, 主要包含了轨道ID, 轨道名称, Edit Rate, Duration, 对源素材的引

15、用信息等. 其中的DM专用于描述上述的视音频轨道, 可描述视频轨上的静止图像信息, 轨道事件信息等; 素材源信息: 在MXF的Source Package中描述了Material Package中输出所需要的素材源的信息, 也是按轨道分别描述, Source Package和Material Package的数据结构相同; Descriptive Metadata Plug-ins: 以插件的方式提供进一步的元数据信息扩展, 目前形成标准的为DMS-1(Descriptive Metadata Scheme 1), 里面描述的信息分为三类: 产品信息, 素材信息和场景信息. 产品信息对MXF文

16、件做整体性描述, 包括Primary Spoken Language Code, Secondary Spoken Language Code, Original Spoken Language Code, URL to additional Metadata Server, Identification Sets, Title Sets, Event Sets, Episode Sets, Branding Sets, Annotation Sets, Contracts Sets, Awards Sets, Participant Sets, Organization Sets等; 素材信

17、息描述来自素材采集和创建的信息, 包括Clip Kind(静止图像, 图形, 视频, 声音等), Clip Number, Project Number, Track IDs, Basic UMID, Logo Flag, Process Steps, Copy Number, Clone Number, Location Sets, Device Parameters Sets等; 场景信息描述场景的情节, 事件等信息, 包括Language Code, Scene Number, Title Sets, Location Sets, Annotations Sets等. 上述的每一种子信息

18、又分别有更详细的数据结构描述. 由于Descriptive Metadata很难描述, 不同的厂家也很难达成一致, 所以目前还在不断的磋商和补充中.,视音频文件绑定/分离,视音频数据组合在一起成为一个文件有利于管理 视音频数据分离保存为不同文件有利于复杂编辑 Sony MXF视音频数据都在同一个MXF流或者MXF文件中, 这使得它可以非常方便的以流的方式在网络上传输和交换. 而Panasonic MXF则将视频数据和音频数据分在不同的文件中, 这种方式非常适用于素材的快速Seek和编辑.,MXF内的索引表信息,索引表信息的最大意义就是有利益视音频数据帧的快速定位 MXF的索引信息分类 Rand

19、om Index Pack(Optional) Body的Index Table(Optional) MXF的索引信息结构是非常复杂的 DV等固定帧长的MXF结构可忽略许多索引信息,仅保留第一个Body的Index Table 应该支持多个Body Partintion,视频和音频数据的编码格式,视频有:MPEG,DIO,DV 音频有:PCM,MP2 Sony MXF使用的是SMPTE 386M2, 387M3和382M4, 而Panasonic使用的是SMPTE383M5和382M4, 也就是它们的音频部分都用的是MXF系列标准中对AES3音频的定义, 而视频部分Sony用的是对D-10和D-11的定义, Panasonic用的

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论