线性提示视频流

摘要

用文件标题部分、提示索引部分和数据部分来构建流文件。该文件标题部分包括文件标题对象、媒体数据文件描述符和索引描述符。提示索引部分包括第一级提示索引，所述第一级提示索引具有与时间标记键值对应的线性组织结构；及第二级提示索引，所述第二级提示索引具有与这种时间标记键值对应的非连续组织结构。在第二级提示索引中的专用标志指示出，对于下一时间标记键值，必须查阅该第一级提示索引。这种标志被放置在与其条目相关联的一连串时间标记键值的最后。数据部分可以放在单独的文件中，并且它接受在与连串的时间标记键值中相关联的媒体数据块来作为其条目。由此，为非连续媒体数据文件提供提示。

权利要求

1.一种用于流媒体数据文件中的线性提示的方法，包括：配置带有指向第二级非连续提示索引的指针的第一级线性提示索引；

给所述第二级非连续提示索引提供指向非连续媒体数据文件的指针；以及通过访问所述第一级线性提示索引以获得指向所述第二级非连续提示索引的指针，来搜索在所述非连续媒体数据文件中的媒体数据块，其中所述指向第二级非连续提示索引的指针进而提供了指向在所述非连续媒体数据文件中的特定媒体数据块的最终指针。

2.如权利要求1所述的方法，还包括：

对于下一访问，不优先查阅所述第一级线性提示索引；以及通过仅访问在所述第二级非连续提示索引中的下一条目以取得指向在所述非连续媒体数据文件中的下一媒体数据块的相应指针，来获得在所述非连续媒体数据文件中的所述下一媒体数据块。

3.如权利要求1所述的方法，还包括：

用特殊字符按所述媒体数据块在所述非连续媒体数据文件中的次序来标记间断，其中所述特殊字符被放置在指向在所述第二级非连续提示索引中的最后一个连续媒体数据块的相应指针中。

4.如权利要求3所述的方法，还包括：

如果在最后的访问中没有获得所述特殊字符，则通过仅访问在所述第二级非连续提示索引中的下一条目以取得指向在所述非连续媒体数据文件中的下一媒体数据块的相应指针，来获得在所述非连续媒体数据文件中的所述下一媒体数据块，并且不优先查阅所述第一级线性提示索引；

否则，返回以通过访问所述第一级线性提示索引以获得指向所述第二级非连续提示索引的指针来搜索在所述非连续媒体数据文件中的媒体数据块，其中所述指向第二级非连续提示索引的指针进而提供了指向在所述非连续媒体数据文件中的特定媒体数据块的最终指针。

5.如权利要求1所述的方法，还包括：

将所述第一级线性提示索引和所述第二级非连续提示索引共同打包在具有媒体文件描述符的单个文件中；以及关联至少一个单独的媒体数据文件。

6.如权利要求1所述的方法，还包括：

将所述第一级线性提示索引和所述第二级非连续提示索引共同打包在具有媒体文件描述符的单个文件，以及至少一个非连续媒体数据文件中。

7.如权利要求1所述的方法，还包括：

组织索引部分，使得所述第一级线性提示索引具有与时间标记键值对应的线性组织结构。

8.如权利要求1所述的方法，还包括：

组织索引部分，使得所述第二级提示索引具有与时间标记键值对应的非连续组织结构。

9.如权利要求1所述的方法，还包括：

组织索引部分，使得所述第二级提示索引在与其条目相关联的一连串时间标记键值的最后包括专用标志。

10.如权利要求1所述的方法，还包括：

组织数据部分，使得它接受在连串的时间标记键值中相关联的媒体数据块来作为其条目。

说明书

线性提示视频流

技术领域

[0001] 本公开涉及视频流，尤其涉及提供线性提示信息以改进缓存性能的文件格式。

背景技术

[0002] 在任何媒体数据可以通过实时传输协议(RTP)被传送之前，这些数据必须依照某些规则被打包。例如，RFC 2250描述了用于MPEG-1和MPEG-2数据的规则。为了避免文件分析的重复工作，这些数据可被仅打包一次，并且被存储以供将来使用。为了这个目的QuickTime文件格式使用“提示”轨道。

[0003] QuickTime文件格式的构造是为了本地重放，而在流应用中其未能被很好地执行。QuickTime文件格式是非线性的，因此收集数据以建立单个RTP包需要每个文件内的多个查询操作。在可以读取实际的媒体数据之前，元数据内的时间到样本(time-to-sample)表、样本到块(sample-to-chunk)表、块到偏移量(chunk-to-offset)表、样本到大小(sample-to-size)表以及提示样本偏移量(hint sample offset)表都必须被查阅。这些操作导致了系统缓存的使用效率非常低。例如，随着缓存文件的增加，必须不断地更新元数据内的各种表。该元数据结构需要被保持在存储器中，并且直到每个缓存会话结束才能被保存在磁盘上。这种元数据的大小通常是媒体数据的1-2％，因此缓存多个大的文件可以很快地导致RAM本身成为瓶颈。

[0004] QuickTime文件格式的复杂性也阻止了为高性能流建立轻量级核心模块。需要的是一种对于流和缓存应用都可以用作普通容器的文件格式。

发明内容

[0005] 容易分析到，普通媒体流文件格式适合于高性能RTP流和缓存。媒体文件的提示信息和元数据被包括，从而改进了流请求的实时性能。提示文件具有文件标题部分，文件标题部分具有文件标题对象、媒体数据文件描述符和索引描述符。提示索引部分包括第一级提示索引，第一级提示索引具有与时间标记键值对应的线性组织结构。第二级提示索引具有与时间标记键值对应的非连续组织结构。在第二级提示索引中布置专用标志以向流引擎指示出：对于下一个时间标记键值，必须查阅第一级提示索引。该专用标志被放置在与其条目相关联的一连串时间标记键值的最后。

[0006] 本发明的上述概述并不打算代表每个公开的实施例。在随后的附图和详细描述中提供了其它方面以及具体实施例。

附图说明

[0007] 图1是流格式文件的结构图。

[0008] 图2是例如可用于图1的流格式文件中的、表示单个密集提示索引如何提供指向带有时间标记0T-11T的连续媒体数据文件的指针的数据图。

[0009] 图3是例如可用于图1的流格式文件中的、表示带有一些不用位置的第一级密集提示索引如何提供指向第二级密集索引的指针的数据图，其中第二级密集索引进而提供指向带有时间标记0T-11T的连续媒体数据文件的指针。

[0010] 图4是例如可用于图1的流格式文件中的、表示第一级线性提示索引如何提供指向带有专用标志($)的第二级非连续提示索引的指针的数据图，其中带有专用标志($)的第二级非连续提示索引进而提供指向带有时间标记0T-11T的非连续媒体数据文件的指针。

具体实施方式

[0011] 图1描述了用于存储媒体文件的提示信息和元数据的流格式文件100，其是可扩展且灵活的文件。该流格式文件帮助服务器以较少的实时性能影响来处理流请求。流格式文件100包括文件标题部分102、提示索引部分104以及数据部分106。文件标题部分102包括文件标题对象108、媒体数据文件描述符110和索引描述符112。索引部分包括第一级提示索引114和第二级提示索引116。数据部分106携带实际的媒体数据，并且作为代替，可以被完全包含于单独的文件中。

[0012] 流格式文件100支持带有多级稀疏索引的提示信息的有效查找，该多级稀疏索引是独立于任何一种特定数字媒体容器格式或者传输格式的。对于存储在流格式文件中的数据，支持文件内的提示。对于存储在与线性提示格式(LHF)文件分开的文件中的数据，提供文件外提示查找。多级线性索引(MLI)可以帮助流引擎(SE)有效地定位这些数据。

[0013] 典型的提示处理通过该提示信息来工作以获得同一文件或者单独的媒体数据文件中所期望的数据块的偏移量。这就使流引擎以更多有效的方式取出即将被发出的数据，而不用首先必须知道该流媒体的容器格式或有效载荷。

[0014] 密集索引是组织提示信息的常规方式。在密集索引中，数据块的序号、调整的RTP时间戳或者正常播放时间(NPT)被用作键。

[0015] 图2举例说明了密集索引的例子。密集提示索引202提供指向连续媒体文件204的指针。该包的调整的RTP时间戳被用作索引键。例如，在媒体包中的序列{0T，1T，2T，3T，3T，5T，7T，8T，8T，10T，11T}具有值为3003的标记时间(T)。在单独的文件中顺序地存储该媒体数据，并且连续地打包带有相同调整的RTP时间戳的媒体数据块(RTP包)。通常，并不是连续地存储带有调整的RTP时间戳的媒体数据。但是，有了密集索引中用于每个包的偏移量指针，可以定位每块媒体数据。

[0016] 当在请求范围(0T，～)内的播放请求到达时，流引擎检查密集提示索引202，对键“0T”进行定位，并且跟随偏移量指针来定位连续媒体数据文件204中的媒体数据块的起点，同时从那儿开始流动一个数据块。

[0017] 当具有不是以0T开始的请求范围的请求到达时，例如假象播放模式，(5T，～)，流引擎必须穿过密集提示索引来定位键值＝5的索引，然后跟随偏移量指针。如果使用二进制搜索，则该密集提示索引的扫描大约为O(log(n))。如果数据元素数目巨大，则使用这个方法会对性能造成不利影响。

[0018] 如图3中所述，该缺点例如通过多级线性索引来克服。在第一级中，使用线性表来索引调整的RTP时间戳。例如，这种索引计算为，

[0019] 索引＝(请求的正常播放时间)/标记

[0020] 其中，标记＝1/采样率。例如，对于90kHz采样率，标记＝3003。

[0021] 在一个实施例中，假定所有的调整的RTP时间戳是标记值的倍数。如果一些调整的RTP时间戳不是标记值的整数倍，则在线性提示处理期间，该标记值被向上进位为标记值最接近的倍数。由此引入了时间上的非传播进位误差，但是这无关紧要。

[0022] 可能遇到一种情况，其中在第一级线性提示索引302中将存在不使用的位置，例如，如图3所示例的4T，6T和9T。第一级索引302中的每个条目仅需要少许字节。因此，该调整的RTP时间戳应该继续保持线性增加，这是因为浪费在空位置上的空间是可以忽略的。

[0023] 在如前所述的相同例子中，当该请求是(5T，～)时，流引擎计算该5T条目的偏移量，并且跟随它的偏移量指针来到第二级索引304。该操作可以在O(1)时间常量内完成，并且索引304提供在连续媒体数据文件306中所期望的媒体数据块的实际偏移量的起点。

[0024] 对于预先定位的媒体文件，该媒体文件在其线性提示文件104生成时被顺序地放置于文件中。在缓存代理情形中，将电影的后面部分存储在媒体数据文件106的前面附近。

[0025] 该缓存代理情形可以向原始服务器发起具有如下请求范围的请求，所述请求范围不从电影的开头处开始。例如，在时长60分钟的电影中，可能存在三个时间段的请求，例如，0-20分钟[0m，20m]，40-60分钟[40m，60m]以及20-40分钟[20m，40m]。当缓存代理往媒体数据文件中写入数据时，产生的媒体数据文件将是非连续的。第一个二十分钟[0，20m]请求的数据将去往文件的第一部分，后面是[40m，60m]请求的数据，并且该文件的最后部分是[20m，40m]请求的。可以以上述顺序将第二级索引的三个片段存储在线性提示文件中。

[0026] 需要多级线性索引的扩展以准许非连续媒体数据文件索引。图4举例说明了以非连续方式组织起来的、使得例如7T～11T的数据在3T～5T的数据之前到来的媒体数据文件402。

[0027] 可以将非连续媒体数据文件402分成几个片段。在每个片段内，数据可以按顺序地存在。该数据文件包括三个片段404，406以及408，即[0T，2T]，[7T，11T]和[3T，5T]。由美元标记符号($)表示的扩展告诉流引擎何时希望跳跃，以及何时回到第一级线性提示索引410以获得用于下一时间戳的索引。用第二级非连续提示索引412中的专用标志或者标记($)来实现对何时希望跳跃或者何时回到第一级提示索引的指示。

[0028] 在一个实施例中，当播放请求[0，～]到达时，流引擎检查第一级线性提示索引410和[0T]，以获得指向第二级非连续提示索引412的指针。该流引擎跟随该指针来定位在第二级非连续提示索引412中的相应的0T条目，并且获得指向第一媒体数据404的偏移量地址指针，第一媒体数据404具有在非连续媒体文件402中的时间标记0T。然后，该流引擎可以在第二级非连续提示索引412的条目中重复，以跟随偏移量地址指针来到媒体文件
404。即，直到命中2T中的、类似于文件结束(EOF)标记的专用标志($)。该专用标志指示流引擎应该回到第一级提示索引410以定位用于下一调整的RTP时间戳的第二级索引偏移量。

[0029] 在图4所举例说明的例子中，流引擎回到第一级410并且获得3T在第二级非连续提示索引412中的偏移量。该偏移量指向非连续媒体数据文件402的另一部分408。该流引擎将继续取得在第二级非连续提示索引412中的下一个条目，直到遇到5T中的专用标志($)。

[0030] 多个包可以共享相同的实时协议(RTP)时间戳。该接收器时间戳(RTS)没有单调地增加。在一个实施例中，更好地是使用DTS、包发送时间或者包编号作为到每个包的索引，所述DTS、包发送时间或者包编号来自RTP扩展标题或者来自承诺访问速率(CAR)算法的输出。可以将媒体文件/缓存文件中的包以解码/编码的顺序进行存储以加速打包。

[0031] RTP播放请求中的时间范围是表示时间戳(PTS)，但是当定位要发送的包的范围时，其可以被当做解码时间戳(DTS)。为了精确，包的元信息中的实际PTS还与所请求的PTS范围进行比较。

[0032] 多个包可以共享相同的RTS，只要用该RTS来定位第一个包即可。在缓存文件中，以这种方式存储数据，但是不能对其它媒体文件格式(如.mov和.mp4)使用相同的假定。

[0033] 可以将附加字段包含于文件格式中以传达在提示索引中使用哪种类型的键(例如，RTS，PTS，DTS或者包编号)，以便具有更多的灵活性。

[0034] 如果将密集提示索引文件与原始媒体数据分开并且将单个的大索引文件用于存储大数组，则使用密集提示索引的复杂性可以是O(1)。以T为单位的播放时间被直接用作到数组的索引。基本上，索引[t]是指向数据文件中的包的指针。

[0035] 在一个实施例中，为在提示/索引文件中的所有时间戳保留空间。在相应的偏移量被写入之前，文件系统实际上不会分配磁盘空间。

[0036] 再次参考图1，流格式文件100可以定义多个流或者轨道，例如与多个音频流/轨道相关联的一个视频流/轨道。可以进一步将一个轨道/流分割成多个剪辑，其中每个剪辑都包含一段流数据。每个剪辑都具有它自己的指向实际媒体数据的第一级提示索引114和第二级提示索引116。

[0037] 在一个实施例中，如同表-I所详细描述的，流格式文件100从强制的文件标题对象108开始。可以通过扩展偏移量和标题长度利用文件标题对象来定位标题扩展部分。

[0038] 表-I

[0039]

[0040] 在文件标题对象108之后，可以存在类型、长度、值(TLV)的形式的多个文件标题描述符对象。定义两个文件标题描述符对象：媒体数据文件描述符110和索引描述符112。参见表-II。

[0041] 表-II

[0042]字段名 描述 字段类型 大小(比特)
对象类型 文件标题描述符类型 字节 8
对象长度 文件标题描述符长度 字 16
对象值 对象的内容 空 可变长度

[0043] 媒体数据文件描述符携带关于该提示索引部分将指向的连续的或者非连续的数据文件的信息。为了灵活，例如，在单个流格式文件100内可能存在多个媒体数据文件描述符，以提示带有单个提示索引的多个数据文件。带有单个提示索引的多个数据文件可被用来处理一部电影中的多个剪辑(其中这些剪辑被存储在不同的媒体数据文件中)并且使得部分高速缓存文件的处理更加灵活。

[0044] 媒体文件ID被用在提示索引部分104中以向流引擎提示在该索引中的偏移量是用于特定媒体数据文件的。参见表-III。

[0045] 表-III

[0046]

[0047] 表-IV描述了索引描述符的一种格式。

[0048] 表-IV

[0049]

[0050] 会话描述协议(SDP)数据是基于每个电影的，为了方便，该SDP数据被打包在每个线性提示文件中。该SDP数据以文本格式被打包在标题部分102中，并且在表-V中被描述。

[0051] 表-V

[0052]

[0053]

[0054] 第一级索引部分114具有表-VI中的以下标题。该第一级索引部分是稀疏类型。

[0055] 表-VI

[0056]

[0057] 在第一级索引部分标题中的条目类型确定将哪种类型的数据结构用作索引数据。例如，两种条目类型，类型1：第一级线性索引，以及类型2：第二级密集索引。

[0058] 在表-VII中指定类型1索引数据格式。

[0059] 表-VII

[0060]

[0061] 表-VIII详细描述了第二级索引部分标题。

[0062] 表-VIII

[0063]

[0064]

[0065] 第二级密集索引被用作唯一的第二级索引。在流格式文件100中可能存在多个第二级密集索引部分。对于该部分，类型2被用作数据格式。类型2索引数据格式如表-IX中所示。

[0066] 表-IX

[0067]

[0068]

[0069] 实际的包数据可以跟着标题对象和表，如果该数据被存储在同一流格式文件100中的话。当包数据被存储在单独的文件中时，该数据可以以其原始文件格式(像QT mov文件)被存储，或者该数据可以被存储在包数据转储(dump)文件中。

[0070] 虽然已经描述了多个特定示例实施例，但是本领域技术人员可以认识到，可以在不脱离本发明的精神和范围的情况下对其进行多个改变，本发明的精神和范围将在随后的权利要求书中阐明。