CN102084338A

CN102084338A - 用于多平台非线性视频编辑系统的新型媒体文件

Info

Publication number: CN102084338A
Application number: CN2009801223432A
Authority: CN
Inventors: 安德鲁·利布曼
Original assignee: Individual
Current assignee: Individual
Priority date: 2008-04-14
Filing date: 2009-04-14
Publication date: 2011-06-01
Anticipated expiration: 2029-04-14
Also published as: EP2266024A4; WO2009129252A3; CN102084338B; EP2266024A2; WO2009129252A2; US9076488B2; US20110125818A1

Abstract

一种用于摄入(捕捉)数字视频媒体文件以便存储在在Linux^环境中创建Quicktime参考兼容文件的基于Linux^平台的计算环境上的系统和方法。Quicktime参考兼容文件被创建为使得其被标记为不是由Avid的编解码器创建，而是由本地Quicktime编解码器创建。然后，经由本发明的系统和方法，当在Linux^环境中创建Quicktime参考兼容文件时，所述系统和方法自动地捕捉Avid文件并自动地创建到那些文件的硬链接，以便QuickTime参考兼容文件参考硬链接而不是原始Avid文件。也就是说，不是使用对媒体文件的直接参考，而是创建硬链接以提供对它们的第二参考。以这种方式，经由所述硬链接(例如，对象参考)，允许用户对被存储在存储设备上的目录中的所有数字音频和视频数据进行间接访问，同时不要求访问原始Avid媒体文件。有利地，不需要将Avid格式文件转换成Quicktime格式。

Description

用于多平台非线性视频编辑系统的新型媒体文件

相关申请的交叉引用

本申请与2006年4月12日提交的美国专利申请No.11/403,036相关，该美国专利申请是2005年3月18日提交的共同待决PCT专利申请No.PCT/US05/08968、且题为“Novel Media File Access and Storage Solution For Multi-Workstation/Multi-Platform Non-Linear Video Editing Systems”(其要求于2004年3月18日提交的且题为“MEDIA FILE ACCESS AND STORAGE SOLUTION FOR MULTI-WORKSTATION/MULTI-PLATFORM NON-LINEAR VIDEO EDITING SYSTEMS”的美国临时专利申请序号60/554,272的优先权)的部分继续申请。美国专利申请No.11/403,036的全部内容和公开通过引用被结合进来，如同其在本文中完全阐述一样。

技术领域

本发明一般涉及媒体文件，并且更具体而言涉及通用数字视频媒体文件格式。

背景技术

通常在具有用于输入数字或模拟音频和视频的装置以及用于编辑输入的音频和视频的软件的独立计算机工作站上设置能够对源材料执行随机访问的非线性视频和音频编辑系统(NLE的)。

在非线性数字视频编辑领域中，采用来自竞争供应商(诸如Avid、Apple、Sony、Thomson-Grass Valley、和Adobe)的视频编辑产品的混合物的制作设备一直面对的问题之一是：许多视频编辑应用程序使用专用且不兼容的文件格式这一事实。例如，两个现在最流行的视频编辑应用程序-Avid和Final Cut Pro-前者捕捉视频文件或将其导入“omf”或“mxf”格式，而后者以Quicktime格式捕捉视频。两个应用程序都不能本地地播放或操作由另一个创建的文件。

另外，不同的供应商常常具有其自己的专用视频CODECS(压缩/解压缩算法)，其能够减小视频文件的尺寸，从而使得其占用较少的空间并仍保持可用的质量。

存在得到数字视频编辑应用程序的所有供应商支持的某些标准化或可公开获得的CODECS这一点略有帮助。此类CODECS的示例包括但不限于“DV-25”(25兆位标准清晰度数字视频)、“DV-50”(50兆位标准清晰度数字视频)、“DV-100”(100兆位高清晰度数字视频)、和索尼的IMX格式(MPEG-2的变体)。

然而，尽管事实是竞争供应商几乎始终支持这些标准化CODECS，但NLE应用程序的主要供应商之一-Avid-在以那些格式捕捉文件时向这些标准化codecs添加了专有包装(wrapper)，并且可以在音频最初被与视频一起嵌入单个数据流中时将该音频分裂成离散文件。Avid本质上改变了标准化数字数据的呈现，有效地使被存储在磁盘上时的文件的格式与其它竞争应用程序不兼容。可能存在做类似事情的其他供应商，虽然大多数供应商看起来允许以跨越几乎所有应用程序兼容的标准化方式存储被以标准化格式编码的视频。

举例来说，如果电视台以Avid的DV-50格式捕捉文件，则在每秒视频留出约8MB的空间以存储文件之后，诸如Apple的Final Cut Pro或Adobe Premiere的其它竞争应用程序或许多第三方索引和数据库工具不能使用同一文件，即使数字数据的本质是它们所支持的某些东西。通常，如果将由Avid以及其它应用程序来操作视频剪辑，则必须多次捕捉重复的视频数据并将其以多个格式存储，以便其可以被竞争应用程序使用。

为了避免不得不对同一视频和音频数据的多个版本进行捕捉或代码转换和存储、以便其可以被Avid及其它竞争非线性视频编辑应用程序使用的麻烦，将期望具有允许单组视频和音频文件被所有应用程序使用并自动地启用此功能的系统。

当前的现有技术解决方案包括被构建成其Quicktime格式的Apple的“Quicktime参考文件”。Quicktime参考文件是能够参考非Quicktime媒体文件且使得那些媒体文件作为Quicktime文件呈现于能够读取Quicktime文件的应用程序的小型文件(通常约1至2千字节)。因此，例如，可以在Windows或Macintosh OS计算机上创建Quicktime参考文件，使得Avid的“mxf”或“omf”文件看起来是有效的“Quicktime文件”。

通常，Quicktime参考文件是具有到该音频和视频媒体文件的链接的文件，其不处于Quicktime格式，并且其使得那些文件看起来是处于Quicktime格式，从而使得它们可以被任何服从Quicktime的应用程序播放。

所有当前的Avid NLE应用程序包括制作Quicktime参考文件的能力。即使Avid以专有格式存储其所有文件，Avid也提供允许经由基于Windows或Mac的服从Quicktime的视频应用程序(诸如另一NLE或编码程序)观看剪辑或已编辑电影的有限特征-条件是可自由分发的Avid CODECS被安装在将播放Quicktime参考文件的计算机上，并且条件是该计算机已安装有Avid媒体文件。因此，Quicktime参考文件在视频编辑和后期制作领域中众所周知。

然而，在Avid等创建Quicktime参考文件的方式方面存在某些明显的缺陷，使得结果得到的Quicktime参考文件特别难以在视频编辑应用程序中使用。

首先，虽然大多数专业视频应用程序提供在与所捕捉的视频剪辑相关联的元数据中嵌入“源名”和“源时间码”的手段-这对制作过程的许多步骤(例如重新捕捉、存档、在高分辨率下“适应”最初在“草图分辨率”下编辑的视频)而言是关键的，但Avid的创建Quicktime参考文件的过程不将“源名”和“实际源时间码”放在参考文件中。因此，例如，当你在Final Cut Pro中打开Avid制作的Quicktime参考文件时，对于每个剪辑而言，起始时间码始终是00:00:00:00，并且不存在用于该材料的是什么原始来源的指示。可以将正确且准确的信息源名和时间码放在Quicktime参考文件中。Avid恰好选择不这样做。

在被放入Quicktime参考文件中的“编解码器”信息中出现另一缺陷。具体而言，即使可能已经以“Avid DV25”格式捕捉了原始剪辑，如果Quicktime参考文件将该剪辑视为被以“Avid DV25”编解码器(Avid的包装标准化DV25文件的专用方式)、而不仅仅是标准的“DV25”编码，则尝试播放Quicktime参考文件的应用程序将使用Avid的编解码器而不是标准化编解码器对该文件进行解码。当未被从Avid应用程序内使用时，Avid的编解码器表现非常差-通常不能在没有卡顿的情况下实时地播放视频，或者实时地播放视频导致过大的CPU利用率。简单地将Quicktime参考文件修改为表达用标准“DV25”编解码器而不是“Avid DV25”编码的剪辑将允许在非Avid NLE应用程序中完美地重放文件。然而，产生Quicktime参考文件的许多程序将数据标记为采取Avid专有格式而不是采取标准化格式。该情况不仅对于DV25、而且对于DV50和DV100(也称为DVC Pro HD)均是相同的。

第三个缺陷是从Avid媒体剪辑产生Quicktime参考文件的大多数程序是不方便的，并且需要许多步骤。繁琐的程序明显妨碍许多制作设备使用Quicktime参考文件。

第四个缺陷尤其影响具有中央存储器的协作工作环境。由于Quicktime参考文件通常参考被Avid用户而不是被Quicktime参考文件用户使用的文件，所以存在下述风险：即如果它们所参考的原始文件被意外删除、或者如果原始文件被结束使用原始文件且不知道仍有某人经由Quicktime参考文件使用它们的Avid编辑者故意删除，则Quicktime参考文件可能变得无用。

第五个缺陷是到目前为止还没有在Linux

平台上产生Quicktime参考文件的方法，部分地因为Quicktime的发明人(Apple)不具有或尚未分发可以在Linux

上创建Quicktime参考文件的工具包。因此，对于基于Linux的存储系统而言，目前在该系统上制作Quicktime

参考文件的唯一方法是经由连接到基于Linux的中央存储器的基于Windows或Mac的应用程序。

提供一种用于通过允许单组的视频和音频文件自动地被所有非线性视频编辑应用程序使用来修正这些缺陷的系统和方法将是非常期望的。

发明内容

本发明意在针对视频和音频非线性编辑系统及其它设备(例如，能够记录、重放、和/或通过网络访问数字媒体文件的软件或硬件和编码器)的改进，以及使得能够经由在除Windows和Mac OS平台之外的基于Linux的操作系统的控制下操作的设备播放某些视频文件格式的方法和计算机程序产品。

本发明包括被开发为在Linux、Windows和Mac OS平台上运行的“摄入(ingest)应用程序”。在一个实施例中，“摄入应用程序”允许经由Firewire高速通信通信链路(即IEEE 1394接口)在设备上捕捉DV25、DV50和DV100视频和音频。根据摄入应用程序，可以将所捕捉的视频和音频媒体文件保存在Avid的专有编解码器中，并且以基于标准的Windows AVI和Apple Quicktime格式保存。该摄入应用程序还允许经由数字或模拟视频信号来捕捉那三个DV格式以及许多其它格式，所述数字或模拟视频信号经由可以包括SDI、HD-SDI及其它数字和模拟输入的可选“捕捉卡”进入计算机中。

替代地称为“通用媒体文件”，本发明包括用于Linux

平台的新型摄入应用程序的附件(Linux是Linus Torvald的注册商标)。然而，可以将“通用文件”用作其它竞争摄入/捕捉应用程序的附件，并将其用来处理由NLE应用程序本身捕捉且被存储在中央服务器上的文件，或者对先前由摄入应用程序捕捉并被存储在服务器上的文件进行“后处理”。

用于Linux平台的新型摄入应用程序是包括用于在Linux

环境中创建Quicktime参考文件的附加功能的一般“工具包”应用程序的一部分。本发明是足够通用的，如果所使用的服务器正在运行Windows，则其将在Windows中创建Quick Time参考文件。这种情况下的差别是可以将Apple的现有工具包用于Windows并修改结果。然而，在Windows中，可能无法如在本发明的基于Linux的实现中那样实现某些保护。例如，实际上不可能在Windows中创建硬链接。

因此，依照本发明，提供了一种用于摄入(捕捉)数字视频媒体文件以便存储在在Linux环境中创建Quicktime参考兼容文件的基于Linux

平台的计算环境上的系统和方法。Quicktime参考兼容文件被创建，从而使得其被标记为不是由Avid的编解码器创建，而是由本地Quicktime编解码器创建。然后，经由本发明的系统和方法，当在Linux

环境中创建Quicktime参考兼容文件时，所述系统和方法自动地捕捉Avid文件并自动地创建到那些文件的硬链接，以便QuickTime参考兼容文件参考硬链接而不是原始Avid文件。也就是说，不是使用对媒体文件的直接引用，而是创建硬链接以提供对它们的第二引用。以这种方式，经由所述硬链接(例如，对象引用)，允许用户对存储在存储设备上的目录中的所有数字音频和视频数据进行间接访问，同时不要求访问原始Avid媒体文件。有利地，不需要将Avid格式化文件转换成Quicktime格式。

在替换实施例中，用于同时捕捉Avid文件的方案包括在可以被所有应用程序(例如，FinalCutPro或其它Quicktime应用程序)访问的媒体空间中创建到该被捕捉文件的硬链接。因此，有利地，这些文件和非AVID应用程序不一定必须侵入AVID的媒体(文件)空间。因此，在本替换实施例中，用户参考到原始文件(用于AVID和非Avid应用程序用户两者)的链接(硬链接)并将其置于公共目录中。

此外，可以通过定义仅看见QuickTime参考目录及其子目录(从而排除看见Avid媒体文件目录结构)的网络共享来提供对QuickTime参考文件的用户访问。或者，可以包括沿着(alongside)Avid目录结构对QuickTime参考文件的访问-以便用户可以看见QuickTime参考文件和Avid目录结构两者。

附图说明

鉴于结合附图进行的以下详细说明，本发明的对象、特征和优点将变得对于本领域的技术人员来说显而易见，在附图中：

图1描绘讨论本发明的方法步骤的示例性流程图；

图2描绘从图1中描绘的功能的操作步骤得到的示例性目录结构；

图3描绘根据本发明的一个实施例的用于实现服务器侧摄入和文件存储特征的架构和示例性计算机环境；

图4描绘与图3的服务器设备通信的典型非线性视频编辑(NLE)系统工作站的配置；

图5描绘依照本发明的一个实施例的示例性图形用户界面(GUI)300，人们可以经由该图形用户界面来创建具有通用媒体文件的新的媒体空间(虚拟卷)；

图6描绘在摄入服务器处提供的允许用户执行“摄入”一个或多个“通用媒体文件”格式的摄入操作的示例性GUI 400；

图7A描绘当以通用媒体文件格式摄入并将Avid媒体文件放置到正常Avid目录中时得到的示例性目录结构500，并且

图7B描绘示例性目录结构150，其显示当剪辑的摄入已完成时，系统创建到Avid MXF文件的“硬链接”并将其保存在同一“媒体空间”中，但在不同的目录中；

图8描绘提供被启动用于删除相应的硬链接和QuickTime参考电影以“清理”该媒体空间名称的媒体空间的功能的示例性生成的图形用户界面(GUI)350；以及

图9从存储服务器的角度描绘示例性目录结构，其示出Avid MXF文件的位置(在目录andy_Univ12_1/Avid MediaFiles/MXF/1中)。

具体实施方式

Quicktime参考文件可以参考单个文件、意图被同时播放的一组音频和视频文件，或构成序列的音频和视频文件的长列表。也就是说，QuickTime文件格式充当包含或包装一个或多个轨道的多媒体容器文件或包装器，每个所述轨道存储特定类型的数据：音频、视频、时间码等。轨道被保持在由对象调用原子(objects called atoms)组成的分级数据结构中。每个轨道或者包含经数字编码的媒体流(使用特定编译码器)，或者在QuickTime参考电影的情况下，轨道大部分参考位于一个或多个其它文件中的媒体流。采用Quicktime参考概念，可以创建参考作为整个电影的一部分的全部数千个单独音频和视频剪辑的单个小文件，并将所有参考折叠成一个文件，从而使得当你播放“参考文件”时，你对电影的所有零碎东西进行定位和调用，从而使得电影作为一个连贯整体进行播放。

出于说明和非限制性目的，假设实现参考单独剪辑的音频和视频部分的Quicktime参考文件。该系统使得能够实现以下各项：

摄入和捕捉DV25、DV50和DV100视频和音频剪辑并将数字媒体文件保存在专有Avid

编解码器中，并在基于Linux的存储设备上同时且自动地创建Quicktime参考兼容文件，从而使得一组数字媒体文件(专有Avid编解码器中的那些)还将作为Quicktime文件出现且可以被非Avid应用程序播放。

基本原理是本地地在Linux中产生Quicktime参考文件的能力，包括：针对Linux支持的应用程序中的操作创建不能与由Apple自己的Mac和Windows Quicktime工具产生的Quicktime参考文件区别开的Quicktime参考文件。其通过自动地搜索并检查存储在专有Avid

编解码器中的数字媒体文件的位置并将该位置嵌入Quicktime参考兼容文件中，并且通过从存储在专有Avid

编解码器中的数字媒体文件搜索并检查“源名”和“时间码”信息并将该信息嵌入Quicktime参考兼容文件来实现这一点。

本发明的基本原理是提供在任何通用计算设备上、并且最有利地在基于Linux的计算平台中本地地产生Quicktime参考文件的能力。该技术通过诸如图4中所示的计算处理器或类似计算机单元来执行软件指令，该软件指令使得用户能够：打开Avid MXF文件，从该文件提取关于源带和时间码的相关元数据，并将该相关元数据写入所创建的所得到的QuickTime参考电影文件中。用“流摄入”服务器来创建AvidMXF文件，但是软件还可以处理由Avid自己的摄入软件或硬件制作的文件以从Avid自己的MXF文件创建QuickTime参考电影。

因此，在一个实施例中，本发明的系统和方法包括：

1.在Linux中创建不能与由Apple自己的Mac和WindowsQuicktime工具产生的Quicktime参考文件区别开的Quicktime参考文件；

2.检查存储在专有Avid

编解码器中的数字媒体文件的位置并将该位置信息嵌入到新创建的Quicktime参考文件中。由于Avid是使用Avid编解码器的唯一非线性视频编辑软件公司，所以Avid使得这些编解码器可公开用于解码目的。仅解码版本未被最优化以实时地进行工作，并因此不适合于实时编辑。包装或包含当代编码的Avid文件的MXF包装器已被充分地描述且遵循Avid提出的称为“OP原子”的特定SMPTE(电影与电视工程师学会)标准(www.smpte.org/standards)。在Avid的DV25、DV50、和DVC Pro HD-或者称为DV 100-编解码器的情况下，编解码器本身不是专有的。这些是开放公布标准。因此，本发明使得将被作为Avid OP原子文件以及还作为QuickTime文件呈现的一组“精髓数据(essence data)”可用而不必复制该“精髓数据”；

3.从存储在专有Avid

编解码器中的数字媒体文件检查“源名”和“时间码”信息并将该信息嵌入新创建的Quicktime参考文件中。此外，元数据是可定位的，因为MXF OP原子格式指定如何对元数据进行编码和将把其放置在何处。例如，MXF格式允许各种类型的元数据在文件中的各位置处(通常是开头或结尾)。此外，元数据的类型可以包括信息，诸如：“剪辑名称”、“卷名称”、“时间码起始”，并且还必须包括关于已经使用什么编解码器来对视频和音频轨道进行编码的信息；此外，元数据还必须包括关于音频和视频数据从某已知参考点起在文件中的什么位置开始(偏移值)的信息。

因此，总而言之，从MXF文件提取被放入QuickTime参考电影中的信息，以便当QuickTime遵循该参考时，其找到MXF文件的精髓或数据部分的开头。因此，例如，在示例性应用中，已知的是，视频磁轨(video track)在距MXF视频文件的起点1400字节处开始，并且每个音频的精髓在距MXF音频文件的开头600字节处开始。该同样的信息被放置到QuickTime文件中-差别是用于精髓开始的位置的“偏移”不是从QuickTime文件的开头而是从其它文件的开头起。

应当理解的是，用于元数据的时隙(slot)被针对MXF文件相当严格地加以定义。MXF文件使用很像QuickTime文件的分级树。存在用于关于时间码、卷名称、剪辑名称等的信息的时隙。关于“精髓”(即视频和音频数据)位于文件中的何处的信息被放入位于文件的结尾处的“偏移表”中。因此，通过从文件结尾处的偏移表提取偏移信息，QuickTime将知道查看至文件的多远处来找到所述视频数据。此外，为(和由)Avid创建的OP原子文件具有分别的视频和音频文件-因此，必须对QuickTime提供那些文件中的每一个的名称和位置，以及关于视频或音频数据在那些文件中的每一个文件中在何处开始的“偏移”。MXF文件中的偏移的尺寸包括可能选择，诸如：0x40000、0x60000或0x80000字节。用MXF文件进行工作的技术人员可以从此类文件读出元数据，并检查该文件以查看偏移是什么，以便知晓视频和/或音频精髓在何处开始。

如图1中所示，现在解释本发明如何工作的逐步过程100。在第一步骤103处，在诸如图4中所示的计算设备处接收或提供数字或模拟视频和音频流，并通过在Linux机器上执行的摄入应用程序(或者在本文中称为“流摄入器”)输入所述数字或模拟视频和音频流。然后，在步骤109处，在一个实施例中，摄入应用程序将Avid

兼容数字视频和音频流编码成如Avid

一样使用标准化编解码器。或者，该数字或模拟视频和音频流可以被某其它方的应用程序摄入。在任一实施例中，媒体文件被以Avid兼容格式包装。然后，在步骤122处，Avid

兼容文件随后被存储在“中央存储设备”上的仅为Avid

文件保留的文件系统目录中。

当期望使该同样的数字文件可经由Quicktime参考文件被非Avid用户访问时，如在图1的步骤125处所示，在同一文件系统上的单独目录中，创建到被存储在专有Avid

编解码器中的那些数字媒体文件中的每一个文件的“硬链接”。该硬链接随后被存储在与将可用于用户访问Quicktime参考文件的特定网络卷相关联的特定目录中。

然后，如在步骤128处所示，创建参考硬链接的位置而不是原始Avid文件的位置的Quicktime参考文件。

图2描绘例如这如何在图3所示的计算和存储器存储系统的目录结构布局150中出现的简化视图。通常，在系统级根目录152下面，存储服务器软件创建用于存储本地Avid文件的子目录154。在该同一文件系统上，本发明的方法创建另一子目录文件夹QuickTime参考兼容文件155。在所创建的Avid文件子目录文件夹154中，创建另一“用于Avid文件的子目录1”158，其是Avid用户直接访问的最高层级的目录，并且原始Avid兼容数字媒体文件定位于该目录，例如“原始avid文件1”和“原始avid文件2”。在QuickTime参考兼容文件子目录目录155中，创建另一“.essence”子目录160，其用于存储到被定位的原始AVID兼容文件的自动创建的硬链接161(对象参考)，即.essence子目录包括到“原始avid文件1”和到“原始avid文件2”的硬链接。QuickTime参考兼容文件159被直接存储在.essence子目录160之上，并指向.essence子目录160中的硬链接161，.essence子目录160又指向“原始avid文件1”和“原始avid文件2”。子目录Quicktime参考兼容文件155可以是用于非Avid用户的网络卷(network volume)的一个可能的根级别，并将提供仅对QuickTime参考兼容文件和硬链接的访问。可替换地，如果期望允许非Avid用户除看见QuickTime参考文件之外还看见Avid目录结构，则非Avid用户可以经由位于Avid文件158的子目录1内部的目录符号链接QuickTime参考兼容文件156来访问QuickTime参考文件。

此外，依照本发明，提供了一种用于使得能够实现用于提供Quicktime参考兼容文件的功能的新型GUI，然而，采用本发明，创建硬链接和Quicktime参考文件的过程完全是自动的。用户简单地经由“摄入应用程序”指示他/她想要创建可被Avid和非Avid应用程序两者访问的文件，即通用媒体文件。当指示“是”时，产生Avid兼容文件以及Quicktime兼容(即“硬链接/Quicktime参考”组合文件)两者。在下文中提供关于新型GUI的更详细说明。

生成到文件的硬链接(给予单个数据片的一个或多个有效名)而不是参考原始Avid兼容文件，因为硬链接解决了“被Quicktime参考文件参考的文件被无意中删除”的问题。在Linux

平台上以及在其它类似Unix的操作系统上，“硬链接”本质上是用于给定文件的附加“名称”。不同于本身是文件且使对原始文件的位置的访问改向的“软链接”或“符号链接”，硬链接是用于同一文件的附加目录列表。删除原始文件将不影响硬链接。即使在删除原始文件之后，打开硬链接仍将把你带到该数据。一旦已创建硬链接，则必须在数据将消失之前删除该硬链接和原始文件两者。另一方面，符号链接可能不保护非Avid用户免于Avid用户无意中删除Avid兼容文件。如果将使用符号链接而不是硬链接，则系统将变得易受攻击，就如同基于原始Avid兼容文件的位置来创建Quicktime参考文件一样。

在一个示例性实施例中，因此可以实现新的目录空间以用于采用位于文件夹中的硬链接(例如称为“精髓”)对所有用户直接从其工作站可观看的所有Quicktime参考文件进行定位。被参考文件参考的事物处于固定关系。也就是说，两个文件夹共存于同一目录中；即，一个具有Quicktime参考兼容文件；并且一个具有参考文件正在参考的所述文件(参见图2)。

现在参照附图，并且特别是参照图3和4，其中示出了其中可以实现本发明的示例性计算环境。

如图3中所示，其中可以实现本发明的总体计算环境包括经由高速网络连接(例如千兆位以太网或10千兆位以太网)来连接多个视频编辑客户端工作站30a、30b、…、30n的服务器设备20。媒体数据可以通过服务器与工作站之间的直接以太网连接或其它连接、或通过无线连接经由交换机设备25在服务器20与工作站之间流动。服务器设备20优选地包括一个或多个处理器设备，例如Intel Pentium4或Xeon或AMD Opteron，在Pentium4和Xeon的情况下支持超过2.4GHz的处理器速度，在Opteron的情况下为1.8Ghz。此外，服务器设备20优选地包括1千兆字节或以上的RAM。另外，服务器20包括至少一个高速以太网端口(优选地1千兆位或更高)。服务器20还包括用于存储数字媒体文件及其它数据并优选地提供百万兆字节的存储容量的装置，例如由硬件RAID卡(其附着于主板上的32位PCI或64位PCI/PCI-X/PCI-Express槽和大容量内置硬盘驱动器(例如，串行ATA驱动器)二者)组成的数据存储子系统50，和/或由外部RAID阵列组成的数据存储子系统52，所述外部RAID阵列连接到光纤信道或SCSI适配器，其还附着于服务器主板上的32位PCI或64位PCI/PCI-X或PCI-Express槽。更具体而言，数据存储子系统50可以包括存储介质，该存储介质包括但不限于磁性硬盘、光学存储驱动器、以及乃至固态盘和存储卡等。如普通技术人员所已知的，硬件体系结构可以替换地包括被配置为支持IDE、SCSI、SAS、光纤信道、Firewire、和USB设备、协议和拓扑结构的媒体接入控制设备。不管预期的存储介质控制器(例如，SATA、SAS、IDE、或SCSI)怎样，其将控制在服务器中配置和/或连接到服务器的多个存储介质驱动器52。

出于讨论的目的，在一个实施例中，用于数字视频和音频文件的协作非线性编辑和操作的集中式共享存储系统由两个3ware(加利福尼亚州圣地亚哥市AMCC的单元)9000S-8硬件RAID卡配置而成，每个卡附着于八个250GB SATA硬盘驱动器。服务器及其存储子系统被连接到以太网络。使得能够与每个工作站30a、30b、…、30n通信的交换机设备25可以包括诸如由SMC Networks

(加利福尼亚州欧文市)提供的千兆位工作组交换机，使得工作站能够用具有集成的千兆位以太网MAC和PHY层功能的千兆位以太网适配器29在全千兆位速度下运行。

具有其存储子系统50、52和到以太网络的连接的服务器20优选地运行Linux操作系统(或者，等效地运行Unix或类似Unix的变体操作系统-包括Apple的OS X-其可以如下所述地运行软件和硬件)。使得服务器能够与每个工作站30a、30b、…、30n通信的交换机设备25可以包括诸如由SMC

(加利福尼亚州欧文市)提供的千兆位网络交换机设备，其支持“千兆铜缆(Gigabit over Copper)”以太网以及“巨型帧”(由9000的分组尺寸或最大传输单元-MTU-定义)。其使得工作站30a、30b、…、30n能够通过允许网络上的最大数据吞吐量及服务器和工作站两者进行的CPU资源的最少使用的以太网电缆60以全千兆位速度运行，以便支持网络交易。假设服务器设备20包括具有集成的千兆位以太网MAC和PHY层功能的至少两个千兆位以太网网络适配器22。此类系统-连同图示的存储子系统一起-允许服务器与工作站之间的充分数据传输以支持至少10NLE的工作站或其它具备能力的硬件，诸如但不限于编码器、播出服务器、以及从诸如硬盘驱动器的设备播放和向该设备记录的录像机，所述硬盘驱动器同时访问存储子系统上的媒体文件。

在本发明的一个实施例中，附加服务器设备20′被配置为anlngest服务器计算机，其包括在基于Linux的高端双四核Xeon(或被同样供电的)计算机上运行的视频捕捉设备。摄入服务器接受标准数字和模拟视频和音频输入(SDI、HD-SDI、组件、复合件、嵌入式音频、AES/EBU音频等)并将原始视频和音频数据流编码成各种编解码器。

在图_中所示的附加配置中，摄入服务器20′的配置之一是其直接向存储服务器设备20进行捕捉，所述存储服务器设备20例如是经由标准千兆位和10千兆位以太网连接51连接到摄入服务器20′的存储器系列和XStream服务器基于Linux的存储服务器。本发明的创建通用媒体文件的基本部分是控制如何将文件放置在储存器上以及将文件放置在存储器上的什么位置，以便可以将其以各种第三方编辑和观看应用程序需要查看该文件的方式呈现给那些应用程序。

作为控制文件放置的一部分，存储服务器软件在附着的存储子系统上创建“通用媒体空间”，在那里，多个Avid用户能够如申请人共同所有的美国专利申请No.11/403,036和12/102,563中所述的那样协作地一起工作，所述美国专利申请的全部内容和公开通过应用结合到本文中。标准EditShare Avid MXF“媒体空间”和“通用媒体空间”之间的差别在于：通用媒体空间包括用于QuickTime文件的若干额外目录和子目录的添加。例如，在如图3中所示的计算环境中，典型的AvidMXF空间将具有以下目录结构：

/MediaSpaceName

/user1_MediaSpaceName *

/Avid MediaFiles

/MXF

/1

files.mxf

/user2_1 {symlink to user2′s ″1″directory}

/user3_1 {symlink to user3′s″1″directory}

/OMFI MediaFiles {legacy directory required to be present}

/user2_MediaSpaceName *

/Avid MediaFiles

/MXF

/1

files.mxf

/user1_1 {symlink to user1′s″1″directory}

/user3_1 {symlink to user3′s″1″directory}

/OMFI MediaFiles {legacy directory required to be present}

/user3_MediaSpaceName *

/Avid MediaFiles

/MXF

/1

files.mxf

/user2_1 {symlink to user2′s″1″directory}

/user3_1 {symlink to user3′s″1″directory}

/OMFI MediaFiles {legacy directory required to be present}

标记*的目录与为了作为每个媒体空间的成员的相应用户导出的“网络共享”相对应。然而，应当理解的是这里所提出的准确目录和文件布局是出于说明的目的而提供的，并且存在可以实现相同目的的其它可能变化。

在给定工作站上运行的Avid应用程序必须在MXF目录内部具有其自己的唯一“编号目录”(即“1”和“2”)。至少，所有工作站需要仅可被该工作站写入的“1”目录。在正常情况下，在同一MXF目录内部具有多个“1”子目录将是不可能的。然而，由EditShare(结合在本文中的美国专利申请序号12/102,563的主题)开发的Avid MXF媒体空间目录结构为每个用户提供他/她自己的“编号子目录”，同时symlink方案通过具有在开头处预先添加用户帐户名的名称的链接暴露其它工作站的“1”目录(或“2”目录)。

在诸如可能在图3中所描绘的存储服务器处创建的通用空间中，以下附加目录被添加到目录结构：

\QuickTime

\.essence

因此，EditShare通用媒体空间的FULL目录结构看起来是这样：

/MediaSpaceName

/QuickTime **

QuickTimeRefMovies.mov {referring to hard links in.essence}

./essence

hard links to various user′s MXF files

/user1_MediaSpaceName

/Avid MediaFiles

/MXF

/1

files.mxf

/user2_1 {symlink to user2′s ″1″ directory}

/user3_1 {symlink to user3′s ″1″ directory}

/OMFI MediaFiles {legacy directory required to be present}

/QuickTime {symlink to the common QuickTime folder}

/user2_MediaSpaceName

/Avid MediaFiles

/MXF

/1

files.mxf

/user1_1 {symlink to user1′s ″1″ directory}

/user3_1 {symlink to user3′s ″1″ directory}

/0MFI MediaFiles {legacy directory required to be present}

/QuickTime {symlink to the common QuickTime folder}

/user3_MediaSpaceName

/Avid MediaFiles

/MXF

/1

files.mxf

/user2_1 {symlink to user2′s ″1″directory}

/user3_1 {symlink to user3′s ″1″directory}

/OMFI MediaFiles {legacy directory required to be present}

/QuickTime {symlink to the common QuickTime folder}

重要的是请注意，在包括图3的存储服务器20的计算环境中，QuickTime目录对于所有用户而言是“只读的”，并且因此，硬链接或QuickTime参考文件都不能被普通用户删除、重命名、移动或以其他方式修改。

当在通用媒体文件的上下文中工作时，摄入服务器20在DV2S、DV50、DV100编解码器(或其它“基于标准的编解码器”)中将视频和音频数据流编码，并以Avid MXF OP原予格式-由每个“剪辑”1个单独视频文件和多达8个单独音频文件组成-包装已编码数据。根据MXF文件的SMPTE规范，包括在Avid MXF文件的“标题”中的是关于“剪辑名称”、“源带”或“卷(reel)”、“SMPTE时间码起始”的元数据信息。

已编码MXF文件固有地与Avid非线性编辑应用程序兼容。然而，“按照现状”，其不与非Avid应用程序兼容。

为了使已编码视频和音频数据可用于非Avid应用程序，而不必复制视频和音频数据，采用通用媒体文件软件来产生QuickTime参考电影，即小QuickTime文件，其包含相同基本元数据作为原始AvidMXF文件(即“源带”或“卷”名称、SMPTE时间码起始等)，但是随后指向Avid MXF文件的“精髓”部分。

当摄入服务器完成将变得“通用”的新剪辑的捕捉时，摄入服务器例如经由加密http:messaging system来通知存储服务器已经创建了一组新的Avid MXF文件(一个视频文件加一定数目的音频文件)。该通知包括文件的名称和已存储该文件的路径。

当接收到此消息时，在存储服务器上运行的通用媒体文件软件执行以下功能：

对于每个新Avid视频和音频文件而言，EditShare创建到文件的Linux“硬链接”并将其放置在与新Avid媒体文件相同的“媒体空间”中，但是在与原始Avid文件不同的目录中。

每个新Avid视频和音频文件被打开并检查以从文件标题检索元数据信息。

使用来自Avid文件的元数据来填充新的QuickTime参考电影文件，其包括关于文件的“分辨率”(即720×480)、用来对文件进行编码的编解码器(即DV25)、作为记录的源的“卷”或“磁带名”、开始时间码、剪辑的运行长度、以及关于如何找到视频和音频“精髓”(包括实际视频和音频数据流的那部分Avid音频和视频文件)的指令的信息。

使得QuickTime参考文件与“硬链接”而不是原始Avid文件相关。这具有多个好处：

在图3中描绘的计算环境中，为了允许多个Avid编辑用同一媒体文件库协作地工作，不同的编辑将看到具有明显不同的名称的目录中的相同Avid MXF文件(即，如上文举例说明的，一个用户可以看到“1”目录中的文件，而另一个可以看到“user2_1”中的完全相同的文件)。目录名的差别对于Avid应用程序而言不重要，因为Avid应用程序在每个目录中保持磁盘上数据库，其描述什么文件处于该位置中。然而，如果被参考的文件的位置对于不同的用户不是一致的，那么实现能够被多个不同用户访问的单组QuickTime参考电影实际上是不可能的。

通过创建其中针对每个Avid视频和音频文件存储硬链接-与其中存储原始文件的目录名无关-的单个目录，本发明提供QuickTime参考电影将基于的一致位置。

创建硬链接的另一好处是该硬链接是原始Avid视频和音频文件的“第二名称”。仍存在数据的仅一个副本，但是只要一个名称或另一个尚未被从存储系统删除，视频和音频文件就仍将是可访问的。这意味着，如果Avid用户删除其媒体文件的名称，则文件对于QuickTime用户而言将不会消失-并且反之亦然。

图9从存储服务器20的角度描绘了示例性目录结构600，其示出Avid MXF文件的位置，例如在目录位置603中(andy_Univ12_1/AvidMediaFiles/MXF/1)。

如图4中所示，关于将被连接到集中式共享存储系统以进行数字视频和音频文件的协作非线性编辑和操作的工作站30a、30b、…、30n，每个工作站均包括计算机系统200，其包括一个或多个处理器或处理单元110、系统存储器250、和将各种系统组件连接在一起的总线101。例如，总线101将处理器110连接到系统存储器250。可以使用任何种类的总线结构或总线结构的组合来实现总线101，其包括存储器总线或存储器控制器、外围总线、加速图形端口、以及处理器或本地总线(其使用诸如ISA总线、增强型ISA(EISA)总线、以及外围组件互连(PCI)总线或类似总线设备的多种总线架构中的任何一种)。另外，计算机系统200包括：一个或多个监视器19，以及操作员输入设备诸如键盘，和定位设备(例如“鼠标”)(其用于输入命令和信息到计算机中)、数据存储设备，并且所述计算机系统200实现诸如Linux、各种Unix、Macintosh、MS Windows OS等的操作系统。

计算系统200另外包括：计算机可读介质，其包括多种类型的易失性和非易失性介质，其中的每个可以是可移动或不可移动的。例如，系统存储器250包括采取诸如随机存取存储器(RAM)的易失性存储器和诸如只读存储器(ROM)的非易失性存储器的形式的计算机可读介质。ROM可以包括包含基本例行程序的输入/输出系统(BIOS)，所述基本例行程序诸如在启动期间帮助在计算机设备200内的多个元件之间传输信息。RAM组件通常包含采取可以被处理单元快速地访问的形式的数据和/或程序模块。其它种类的计算机存储介质包括用于从不可移动、非易失性磁介质读取和向其写入的硬盘驱动器(未示出)、用于从可移动、非易失性磁盘(例如“软盘”)读取和向其写入的磁盘驱动器、以及用于从诸如CD-ROM、DVD-ROM、或其它光学介质的可移动、非易失性光盘读取和/或向其写入的光盘驱动器。任何硬盘驱动器、磁盘驱动器、和光盘驱动器将通过一个或多个数据介质接口(未示出)连接到系统总线101。可替换地，硬盘驱动器、磁盘驱动器、和光盘驱动器可以通过SCSI接口(未示出)或其它耦合机构连接到系统总线101。虽然未示出，但计算机200可以包括其它类型的计算机可读介质。通常，以上标识的计算机可读介质提供计算机可读指令、数据结构、程序模块、及其它数据的非易失性存储以供计算机200使用。例如，可读介质可以存储操作系统(O/S)、一个或多个应用程序，诸如视频编辑客户端软件应用程序、和/或用于使得能够经由图形用户界面(GUI)进行视频编辑操作的其它程序模块和程序数据。

提供了将输入设备耦合到处理单元110的输入/输出接口145。更一般地，输入设备可以通过任何种类的接口和总线结构(诸如并行端口、串行端口、通用串行总线(USB)端口等)耦合到计算机200。计算机环境100还包括显示设备19和将显示设备19耦合到总线101的视频适配器卡135。除显示设备19之外，计算机环境200可以包括其它输出外围设备，诸如扬声器(未示出)、打印机等。I/O接口145用来将这些其它输出设备耦合到计算机200。

如所述，计算机系统200适合于使用到一个或多个计算机的逻辑连接在联网环境中操作，所述逻辑连接诸如为可以包括上文针对计算机设备200所述的所有特征或其某子集的服务器设备20。应理解的是，可以使用任何类型的网络来将计算机系统200与服务器设备20耦合，诸如局域网(LAN)、或广域网(WAN)99a(诸如因特网)。当在LAN联网环境中实现时，计算机200经由支持上述千兆铜缆以太网以及巨型帧的网络接口或适配器29连接到本地网络99a。当在WAN联网环境中实现时，计算机200经由高速电缆/dsl调制解调器180或某些其它连接装置连接到WAN 300。电缆/dsl调制解调器180可以位于计算机200的内部或外部，并且可以经由I/O接口145或其它适当的耦合机构连接到总线101。虽然未示出，但计算环境200可以提供用于将计算机200与例如应用服务器20的远程计算设备相连(例如，经由已调制无线电信号、已调制红外信号等)的无线通信功能。

在联网环境中，应理解的是，计算机系统200可以从以分布式配置存储在远程存储器存储设备(未示出)中的程序模块得到。然而，无论实际上被存储在哪里，执行本发明的非线性视频编辑系统的应用程序中的一个或多个可以包括用于执行主要任务的各种模块。例如，应用程序可以提供视频源数据的逻辑启用输入以便作为媒体文件存储在集中式数据存储系统中和/或对其执行视频编辑技术。可以使用其它程序模块来实现在这里未具体标识的附加功能。

应理解的是，可以预期其它种类的计算机和网络架构。例如，虽然未示出，但计算机系统200可以包括手持式或膝上型电脑设备、机顶盒、可编程消费电子装置、播出服务器、视频编码器、从诸如硬盘驱动器、大型计算机等设备播放和向其记录的录像机。然而，应理解的是，计算环境200可以采用分布式处理配置。在分布式计算环境中，可以在物理上分散计算资源。

如图5中所示，其中描绘了如由图3的计算系统生成的示例性图形用户界面(GUI)300并特别地描绘了管理员GUI，经由该管理员GUI，人们可以创建新媒体空间(虚拟卷)，该新媒体空间具有典型“Avid MXF媒体空间”的目录结构加额外的“QuickTime”目录和QuickTime目录的“.essence”子目录的添加。创建目录结构的过程完全是自动化的。诸如管理员之类的经授权用户经由输入字段303提供媒体空间的名称作为输入，经由输入字段306来选择什么文件系统要添上媒体空间(例如RAID_1阵列)，并经由输入字段309来选择要实现虚拟卷的尺寸，并且然后，管理员软件在新空间内创建目录结构。

如图6中所示，其中描绘了在摄入服务器处提供的示例性GUI 400，其允许用户例如通过“摄入”一个或多个“通用媒体文件”格式来在摄入服务器(图3的服务器20′)处执行摄入操作。授权用户经由下拉框403选择视频源。经由下拉框406，使得用户能够选择将在其中包装数字媒体文件或剪辑的编解码器。当选择通用DV25时，例如，在摄入服务器处执行的应用程序将以Avid MXF DV25格式对视频和音频进行编码。当剪辑已完成捕捉时，摄入服务器将用信号通知存储服务器(图3的服务器20)以“使文件变得通用”，其意味着存储服务器将1)实现到新Avid文件的硬链接，和2)创建参考如本文所述的那些硬链接的QuickTime参考电影。

如图7A中所示，其中描绘了在以通用媒体文件格式摄入时得到的示例性目录结构500，Avid媒体文件被放入正常Avid目录中-例如在“//UnivApril12_l/Avid MediaFiles/MXF/1”中。

如图7B中所示，其中描绘了示例性目录结构510，其显示当剪辑的摄入已完成时，软件管理员-在得到来自流摄入服务器的信号时-自动地创建到Avid MXF文件的“硬链接”并将其存储在同一“媒体空间”中，但在不同的目录中，在本示例中为在“//UnivApril12_1/QuickTime/.essence/”中。

如图7C中所示，其中描绘了示例性目录结构510，其显示一旦已实现硬链接，管理员软件如何执行自动地从新文件提取元数据并将该数据写入参考“硬链接”的QuickTime参考电影中的代码。在本示例中，QuickTime参考文件位于“//UnivApril12_1/QuickTime/”中。

如图8中所示，其中描绘了如由图3的计算系统生成的示例性图形用户界面(GUI)350，并特别地描绘了系统如何预期这样的情况：即Avid用户可能已删除位于Avid MXF存储位置中的文件(和文件名)，以及管理员如何能够经由已通过选择维护TAB键发起的功能来自动地删除相应的硬链接和QuickTime参考电影以“清理”经由下拉框353指定的媒体空间名的媒体空间。Avid用户可以删除MXF文件，但留下硬链接和QuickTime参考电影-在这种情况下，被删除的所摄入剪辑对于Avid用户而言将不再是可见的，但是对于QuickTime用户而言仍将是可见的。

应理解的是，根据本发明，可以通过摄入服务器的流应用程序从未被摄入的剪辑创建通用媒体文件(即QuickTime参考电影)。例如，本发明将可以扫描所有用户的Avid文件并实现用于尚且不是“通用的”的任何剪辑的硬链接(和相应的QuickTime参考电影)。通过摄入服务器的摄入允许用户预先指定文件是“通用的”。

虽然已示出并描述了被视为本发明的优选实施例的内容，但当然应理解的是，在不脱离本发明的精神的情况下，可以很容易地进行形式或细节方面的各种修改和变更。因此，意图在于本发明不限于所述和所示的精确形式，而应被构造为覆盖可以落在随附权利要求范围内的所有修改。