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

专利名称：用于多平台非线性视频编辑系统的新型媒体文件的制作方法
技术领域：
本发明一般涉及媒体文件，并且更具体而言涉及通用数字视频媒体文件格式。
背景技术：
通常在具有用于输入数字或模拟音频和视频的装置以及用于编辑输入的音频和 视频的软件的独立计算机工作站上设置能够对源材料执行随机访问的非线性视频和音频 编辑系统(NLE的)。在非线性数字视频编辑领域中，采用来自竞争供应商(诸如Avid、Apple、Sony、 Thomson-Grass Valley、和Adobe)的视频编辑产品的混合物的制作设备一直面对的问题之 一是许多视频编辑应用程序使用专用且不兼容的文件格式这一事实。例如，两个现在最流 行的视频编辑应用程序-Avid和Final Cut ftx)-前者捕捉视频文件或将其导入“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 I^remiere的其它竞争应用 程序或许多第三方索引和数据库工具不能使用同一文件，即使数字数据的本质是它们所支 持的某些东西。通常，如果将由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描绘依照本发明的一个实施例的示例性图形用户界面(⑶1)300，人们可以经 由该图形用户界面来创建具有通用媒体文件的新的媒体空间(虚拟卷)；图6描绘在摄入服务器处提供的允许用户执行“摄入”一个或多个“通用媒体文 件”格式的摄入操作的示例性⑶I 400;图7A描绘当以通用媒体文件格式摄入并将Avid媒体文件放置到正常Avid目录 中时得到的示例性目录结构500，并且图7B描绘示例性目录结构150，其显示当剪辑的摄入已完成时，系统创建到Avid MXF文件的“硬链接”并将其保存在同一“媒体空间”中，但在不同的目录中；图8描绘提供被启动用于删除相应的硬链接和QuickTime参考电影以“清理”该 媒体空间名称的媒体空间的功能的示例性生成的图形用户界面(⑶1)350 ；以及图9从存储服务器的角度描绘示例性目录结构，其示出Avid MXF文件的位置(在目录 andy_Univl2_l/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提出的称为“0P原子”的特定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参考文件的特定网络卷相关联的特定目录中。
然后，如在步骤1 处所示，创建参考硬链接的位置而不是原始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 (对象参考)，S卩.essence子目录包括到“原始 avid文件1”和到“原始avid文件2”的硬链接。QuickTime参考兼容文件159被直接存储 在.essence子目录160之上，并指向.essence子目录160中的硬链接161，. essence子目 录160又指向“原始avid文件1”和“原始avid文件2”。子目录Quicktime参考兼容文件 巧5可以是用于非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、…、30η 的服务器设备20。媒体数据可以通过服务器与工作站之间的直接以太网连接或其它连接、 或通过无线连接经由交换机设备25在服务器20与工作站之间流动。服务器设备20优选 地包括一个或多个处理器设备，例如Intel Pentium4或Xeon或AMD Opteron，在Pentium4 和Xeon的情况下支持超过2. 4GHz的处理器速度，在Opteron的情况下为1. 8Ghz0此外，服 务器设备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、光纤 信道、FirewireJP USB设备、协议和拓扑结构的媒体接入控制设备。不管预期的存储介质 控制器(例如，SATA、SAS、IDE、或SCSI)怎样，其将控制在服务器中配置和/或连接到服务 器的多个存储介质驱动器52。出于讨论的目的，在一个实施例中，用于数字视频和音频文件的协作非线性编 辑和操作的集中式共享存储系统由两个3ware (加利福尼亚州圣地亚哥市AMCC的单 元)9000S-8硬件RAID卡配置而成，每个卡附着于八个250GB SATA硬盘驱动器。服务器及 其存储子系统被连接到以太网络。使得能够与每个工作站30a、30b、…、30η通信的交换机 设备25可以包括诸如由SMC Networks (加利福尼亚州欧文市)提供的千兆位工作组交 换机，使得工作站能够用具有集成的千兆位以太网MAC和PHY层功能的千兆位以太网适配 器四在全千兆位速度下运行。具有其存储子系统50、52和到以太网络的连接的服务器20优选地运行Linux操 作系统(或者，等效地运行Unix或类似Unix的变体操作系统-包括Apple的OS X-其可 以如下所述地运行软件和硬件)。使得服务器能够与每个工作站30a、30b、…、30η通信的 交换机设备25可以包括诸如由SMCi (加利福尼亚州欧文市)提供的千兆位网络交换机 设备，其支持“千兆铜缆(Gigabit over Copper) ”以太网以及“巨型帧”(由9000的分组 尺寸或最大传输单元-MTU-定义)。其使得工作站30a、30b、…、30η能够通过允许网络上 的最大数据吞吐量及服务器和工作站两者进行的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中所述的那样协作地一起工作，所述美国专利申请的全部内容和公开通过 应用结合到本文中。标准Editaiare Avid MXF “媒体空间”和“通用媒体空间”之间的差 别在于通用媒体空间包括用于QuickTime文件的若干额外目录和子目录的添加。例如，在 如图3中所示的计算环境中，典型的AvidMXF空间将具有以下目录结构/MediaSpaceName/userl_MediaSpaceName */Avid MediaFiles/MXF/1files, mxf/user2_l {symlink to user2' s " 1〃 directory}/user3_l {symlink to user3' s" 1〃 directory}/OMFI MediaFiles {legacy directory required to be present}/user2_MediaSpaceName */Avid MediaFiles/MXF/1files, mxf/userl_l {symlink to userl' s" 1〃 directory}/user3_l {symlink to user3' s" 1〃 directory}/OMFI MediaFiles {legacy directory required to be present}/user3_MediaSpaceName */Avid MediaFiles/MXF/1files, mxf/user2_l {symlink to user2' s" 1〃 directory}/user3_l {symlink to user3' s" 1〃 directory}
/OMFI MediaFiles {legacy directory required to be present}标记*的目录与为了作为每个媒体空间的成员的相应用户导出的“网络共享，，相 对应。然而，应当理解的是这里所提出的准确目录和文件布局是出于说明的目的而提供的， 并且存在可以实现相同目的的其它可能变化。在给定工作站上运行的Avid应用程序必须在MXF目录内部具有其自己的唯一“编 号目录”(即“1”和“2”)。至少，所有工作站需要仅可被该工作站写入的“1”目录。在正常 情况下，在同一 MXF目录内部具有多个“1”子目录将是不可能的。然而，由Editaiare (结 合在本文中的美国专利申请序号12/102，563的主题)开发的Avid MXF媒体空间目录结构 为每个用户提供他/她自己的“编号子目录”，同时symlink方案通过具有在开头处预先添 加用户帐户名的名称的链接暴露其它工作站的“1”目录(或“2”目录)。在诸如可能在图3中所描绘的存储服务器处创建的通用空间中，以下附加目录被 添加到目录结构\ QuickTime\. essence因此，EditShare通用媒体空间的FULL目录结构看起来是这样/MediaSpaceName/QuickTime **QuickTimeRefMovies. mov {referring to hard links in.essence}. /essencehard links to various user' s MXF files/userl_MediaSpaceName/Avid MediaFiles/MXF/1files, mxf/user2_l{symlink to user2' s " 1〃 directory}/user3_l{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/1files, mxf/userl_l {symlink to userl' s " 1〃 directory}/user3_l {symlink to user3' s " 1〃 directory}/OMFI MediaFiles {legacy directory required to be present}/QuickTime{symlink to the common QuickTime folder}/user3_MediaSpaceName
/Avid MediaFiles/MXF/1files, mxf/user2_l {symlink to user2' s 〃 1〃 directory}/user3_l {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参考电影文件，其包括关于文 件的“分辨率”(即720X480)、用来对文件进行编码的编解码器(即DV2Q、作为记录的源的 “卷”或“磁带名”、开始时间码、剪辑的运行长度、以及关于如何找到视频和音频“精髓”(包 括实际视频和音频数据流的那部分Avid音频和视频文件)的指令的信息。使得QuickTime参考文件与“硬链接”而不是原始Avid文件相关。这具有多个好 处在图3中描绘的计算环境中，为了允许多个Avid编辑用同一媒体文件库协作地工 作，不同的编辑将看到具有明显不同的名称的目录中的相同Avid MXF文件(即，如上文举 例说明的，一个用户可以看到“1”目录中的文件，而另一个可以看到“uSer2_l”中的完全相同的文件)。目录名的差别对于Avid应用程序而言不重要，因为Avid应用程序在每个目录 中保持磁盘上数据库，其描述什么文件处于该位置中。然而，如果被参考的文件的位置对于 不同的用户不是一致的，那么实现能够被多个不同用户访问的单组QuickTime参考电影实 际上是不可能的。通过创建其中针对每个Avid视频和音频文件存储硬链接_与其中存储原始文件 的目录名无关-的单个目录，本发明提供QuickTime参考电影将基于的一致位置。创建硬链接的另一好处是该硬链接是原始Avid视频和音频文件的“第二名称”。 仍存在数据的仅一个副本，但是只要一个名称或另一个尚未被从存储系统删除，视频和音 频文件就仍将是可访问的。这意味着，如果Avid用户删除其媒体文件的名称，则文件对于 QuickTime用户而言将不会消失-并且反之亦然。图9从存储服务器20的角度描绘了示例性目录结构600，其示出Avid MXF文件的 位置，例如在目录位置 603 中(andy_Univl2_l/AvidMediaFiles/MXF/l)。如图4中所示，关于将被连接到集中式共享存储系统以进行数字视频和音频文件 的协作非线性编辑和操作的工作站30a、30b、…、30η，每个工作站均包括计算机系统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组件通常包含 采取可以被处理单元快速地访问的形式的数据和/或程序模块。其它种类的计算机存储 介质包括用于从不可移动、非易失性磁介质读取和向其写入的硬盘驱动器(未示出)、用于 从可移动、非易失性磁盘(例如“软盘”)读取和向其写入的磁盘驱动器、以及用于从诸如 ⑶-ROM、DVD-ROM、或其它光学介质的可移动、非易失性光盘读取和/或向其写入的光盘驱 动器。任何硬盘驱动器、磁盘驱动器、和光盘驱动器将通过一个或多个数据介质接口(未示 出)连接到系统总线101。可替换地，硬盘驱动器、磁盘驱动器、和光盘驱动器可以通过SCSI 接口(未示出)或其它耦合机构连接到系统总线101。虽然未示出，但计算机200可以包括 其它类型的计算机可读介质。通常，以上标识的计算机可读介质提供计算机可读指令、数据 结构、程序模块、及其它数据的非易失性存储以供计算机200使用。例如，可读介质可以存 储操作系统(0/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的计算系统生成的示例性图形用户界面 (⑶I) 300并特别地描绘了管理员⑶I，经由该管理员⑶I，人们可以创建新媒体空间(虚拟 卷)，该新媒体空间具有典型“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目录中-例如在“//UnivAprill2_l/Avid MediaFiles/MXF/1” 中。如图7B中所示，其中描绘了示例性目录结构510，其显示当剪辑的摄入已完成时， 软件管理员-在得到来自流摄入服务器的信号时_自动地创建到Avid MXF文件的“硬链接” 并将其存储在同一“媒体空间”中，但在不同的目录中，在本示例中为在“/7UniVAprill2_l/ QuickTime/, essence/，，中。如图7C中所示，其中描绘了示例性目录结构510，其显示一旦已实现硬链接， 管理员软件如何执行自动地从新文件提取元数据并将该数据写入参考“硬链接”的 QuickTime参考电影中的代码。在本示例中，QuickTime参考文件位于“//UnivAprill2_l/ QuickTime/” 中。如图8中所示，其中描绘了如由图3的计算系统生成的示例性图形用户界面 (⑶1)350，并特别地描绘了系统如何预期这样的情况即Avid用户可能已删除位于Avid MXF存储位置中的文件(和文件名)，以及管理员如何能够经由已通过选择维护TAB键发起 的功能来自动地删除相应的硬链接和QuickTime参考电影以“清理”经由下拉框353指定 的媒体空间名的媒体空间。Avid用户可以删除MXF文件，但留下硬链接和QuickTime参考 电影-在这种情况下，被删除的所摄入剪辑对于Avid用户而言将不再是可见的，但是对于 QuickTime用户而言仍将是可见的。应理解的是，根据本发明，可以通过摄入服务器的流应用程序从未被摄入的剪辑 创建通用媒体文件(即QuickTime参考电影)。例如，本发明将可以扫描所有用户的Avid 文件并实现用于尚且不是“通用的”的任何剪辑的硬链接(和相应的QuickTime参考电影)。 通过摄入服务器的摄入允许用户预先指定文件是“通用的”。虽然已示出并描述了被视为本发明的优选实施例的内容，但当然应理解的是，在 不脱离本发明的精神的情况下，可以很容易地进行形式或细节方面的各种修改和变更。因 此，意图在于本发明不限于所述和所示的精确形式，而应被构造为覆盖可以落在随附权利 要求范围内的所有修改。
权利要求
1.一种用于摄入数字视频媒体文件以便存储在基于Linux 平台的计算环境上的计算 机系统，所述系统包括存储器；与计算机存储器通信的处理器，其中，所述计算机系统根据基于Linux 的操作系统进 行操作，所述处理器能够执行下述方法，该方法包括在其中对所述存储器进行组织的目录结构的预定分级结构处存储用于存储具有多媒 体(音频/视频)内容的本地数字媒体文件的第一文件夹，使用专有编码器来包装所述本 地数字媒体文件；在其中对所述存储器进行组织的所述目录结构的所述预定分级结构处创建用于存储 与一个或多个所述本地数字媒体文件相关联的参考文件的第二文件夹；以及 获得被存储且用于定位的数字媒体文件的一个或多个数字媒体文件的位置， 遍历所述文件以从所述数字媒体文件获得进一步的信息；以及 创建参考文件以供在所述第二文件夹中存储；以及，将所获得的位置和进一步的信息 嵌入所创建的参考文件中，其中，所述参考文件使得与本地数字媒体文件的包装格式不兼容的应用程序能够访问 那些本地数字媒体文件中的多媒体数据。
2.如权利要求1中所述的系统，其中，所述专有编码器是AVID 编解码器。
3.如权利要求1中所述的系统，其中，所获得的所述进一步的信息包括来自于所述数 字媒体文件的“源名”和“时间码”信息。
4.如权利要求1中所述的系统，其中，所述创建的参考文件具有Quicktime‘ 格式。
5.如权利要求1中所述的系统，其中，所述处理器能够执行进一步的方法，其包括创 建硬链接以为用户提供对被存储在包括所述创建的参考文件的存储设备上的目录中的所 有数字音频和视频数据的间接访问。
6.一种用于摄入数字视频媒体文件以便存储在基于Linux· ·平台的计算环境上的方 法，所述基于Linux 平台的计算环境具有存储器以及与计算机存储器通信的处理器，其 中，所述计算机系统根据基于Linux· 的操作系统进行操作，所述方法包括在其中对所述存储器进行组织的目录结构的预定分级结构处存储用于存储具有多媒 体(音频/视频)内容的本地数字媒体文件的第一文件夹，使用专有编码器来包装所述本 地数字媒体文件；在其中对所述存储器进行组织的所述目录结构的所述预定分级结构处创建用于存储 与一个或多个所述本地数字媒体文件相关联的参考文件的第二文件夹；以及获得被存储且用于定位的数字媒体文件的所述一个或多个数字媒体文件的位置， 遍历所述文件以从所述数字媒体文件获得进一步的信息；以及 创建用于存储在所述第二文件夹中的参考文件；以及 将所获得的位置和进一步的信息嵌入所创建的参考文件中，其中，所述参考文件使得与所述本地数字媒体文件的包装格式不兼容的应用程序能够 访问那些本地数字媒体文件中的多媒体数据。
7.如权利要求6中所述的方法，还包括创建硬链接以为用户提供对存储在包括所述创建的参考文件的存储设备上的目录中 的所有数字音频和视频数据的间接访问。
8.一种用于摄入数字视频媒体文件以便存储在基于Linux 平台的计算环境上的计算 机程序产品，所述计算机程序产品包括存储介质，其可被处理电路读取并存储用于由处理电路运行以便执行下述方法的指 令，所述方法包括在其中对所述存储器进行组织的目录结构的预定分级结构处存储用于存储具有多媒 体(音频/视频)内容的本地数字媒体文件的第一文件夹，使用专有编码器来包装所述本 地数字媒体文件；在其中对所述存储器进行组织的所述目录结构的所述预定分级结构处创建用于存储 与一个或多个所述本地数字媒体文件相关联的参考文件的第二文件夹；以及获得被存储且用于定位的数字媒体文件的一个或多个数字媒体文件的位置，遍历所述文件以从所述数字媒体文件获得进一步的信息；以及创建用于存储在所述第二文件夹中的参考文件；以及将所获得的位置和进一步的信息嵌入所创建的参考文件中，其中，所述参考文件使得与所述本地数字媒体文件的包装格式不兼容的应用程序能够 访问那些本地数字媒体文件中的多媒体数据。
9.如权利要求7中所述的计算机程序产品，其中，所述方法还包括创建硬链接以为用户提供对存储在包括所述创建的参考文件的存储设备上的目录中 的所有数字音频和视频数据的间接访问。
全文摘要
一种用于摄入(捕捉)数字视频媒体文件以便存储在在Linux环境中创建Quicktime参考兼容文件的基于Linux平台的计算环境上的系统和方法。Quicktime参考兼容文件被创建为使得其被标记为不是由Avid的编解码器创建，而是由本地Quicktime编解码器创建。然后，经由本发明的系统和方法，当在Linux环境中创建Quicktime参考兼容文件时，所述系统和方法自动地捕捉Avid文件并自动地创建到那些文件的硬链接，以便QuickTime参考兼容文件参考硬链接而不是原始Avid文件。也就是说，不是使用对媒体文件的直接参考，而是创建硬链接以提供对它们的第二参考。以这种方式，经由所述硬链接(例如，对象参考)，允许用户对被存储在存储设备上的目录中的所有数字音频和视频数据进行间接访问，同时不要求访问原始Avid媒体文件。有利地，不需要将Avid格式文件转换成Quicktime格式。
文档编号G06F9/44GK102084338SQ200980122343
公开日2011年6月1日 申请日期2009年4月14日 优先权日2008年4月14日
发明者安德鲁·利布曼 申请人:安德鲁·利布曼