具体实施方式
本发明提供用于允许通过通信介质(比如在计算机网络中)的媒体数据的时间相关序列的传输,特别是分组化传输的方法和设备,所述媒体数据包括,例如,视频、音频、视频和音频等等。
在发明的一个实施例,数字处理系统创建一组数据,所述一组数据指示如何按照传输协议发送媒体数据的时间相关序列。通常,该组数据存储在与数字处理系统连接的存储装置上。此外,该组数据是与媒体数据的时间相关序列有关的数据的时间相关序列。
本发明可以完全由保存在计算机可读介质上的可执行计算机程序指令实现,或者由软件和硬件的组合实现,或者在某些实施例中,可以完全用硬件实现。通常,连接到网络的服务器计算机系统将创建该组数据,该组数据可被称为提示轨道,并且把提示轨道保存与服务器计算机系统连接的存储装置上。当客户机计算机系统要求媒体数据文件的表现(例如,浏览或收听或者浏览和收听)时,服务器系统使用提示轨道来确定如何对传给客户机计算机系统的媒体数据分组化。要认识到本发明一般适用于媒体数据的时间相关序列,并且QuickTime这里被表示成这种普遍适用性的一个例子。从而,本发明不应被局限于QuickTime。
图3表示按照本发明的方法的一个例子。图3中所示的方法300始于步骤301,在该步骤中,确定希望传送的特定媒体数据的媒体文件格式。在步骤303,还确定希望使用的一个或多个特定传输协议。但是,例如,在总是利用相同的传输协议传送相同的媒体文件格式的情况下,步骤301和303是可选步骤。
在步骤305,诸如服务器计算机系统之类的数字处理系统创建和存储用于对媒体文件中的媒体数据的时间相关序列分组化的提示。另一方面,一个计算机系统可以创建所述提示,并将其提供给另一系统,比如保存这些提示以便稍后供传输处理之用的服务器计算机系统。所述分组化还允许按照在步骤303中确定的所需传输协议经网络或通信介质的传输。在本发明的一个实施例中,提示被保存为提示的时间相关序列的轨道,所述轨道引用媒体数据的其它轨道,但是在一个实施例中与媒体数据的其它轨道分开。在本发明的一个实施例中,可独立于它所引用的媒体数据保存提示轨道。同样地,提示轨道可被保存在与包含该提示轨道所引用的媒体数据的另一个文件不同的文件中,或者提示轨道可被保存在包含媒体数据的文件中的提示区中,该提示区与包含实际媒体数据的数据区分开且不同。在本发明的一个实施例中,提示轨道或一部分可被解释成服务器可执行指令,所述可执行指令使服务器对数据的时间相关序列进行分组化,所述数据通常是(但并非必定是)时基媒体数据。在本发明的一个实施例中,提示被保存在连接到传送数字处理系统的存储装置上。
在步骤307,按照提示分组化的数据从诸如服务器计算机系统之类的传送系统被传送到接收系统。通过按照提示对媒体数据进行分组化,传送该媒体数据。在本发明的一个备选实施例中,服务器计算机系统可以决定不使用所述提示,并借助备选的分组化处理来发送媒体数据。
在步骤309,接收系统表现媒体数据所表示的媒体对象。通常,当在接收系统收到分组数据时,进行这种表现(所述表现可以是媒体对象的浏览和收听,或者只是媒体对象的浏览或只是媒体对象的收听)。在本发明的一个实施例中,分组数据可以(不过并不需要)被保存在接收系统。从而,在一旦表现结束时,在接收系统不存在任何本地副本的意义上,该数据的表现是短暂的。在另一个实施例中,媒体对象的表现可以在创建表示该媒体对象的媒体数据的提示之后,在服务器系统上进行。在本发明的一个实施例中,媒体数据不一定要(重新)格式化、复制等以按照提示进行分组化。
在步骤311,如果接收的媒体文件已存储在接收系统上,那么接收系统可以可选重新汇编媒体文件。要认识到可以按照与上面所述不同的顺序执行图3中所示方法的各个步骤和/或可以同时执行其中的一些步骤。例如,在一个实施例中,步骤309和311被并行执行。
现在详细描述按照本发明一个实施例的关于QuickTime的特定实现。在本发明的一个实施例中,提供既可相对于文件本地浏览(例如,在服务器,发生器等),而且又可在QuickTime电影内通过网络流式传输的表现。通常,流媒体服务器(或另一个系统)应具有与要流式传输的数据单元有关的信息,它们的组成和定时。由于这种信息一般与时间有关,因此可以用轨道来描述。例如,通过使用与用于浏览表现相同的索引操作,服务器可以执行分组化并确定协议信息。
包含给服务器的指令的轨道有时被称为“提示”轨道,因为这种轨道表示在形成和传送分组的处理中指挥服务器的一组数据。QuickTime文件格式支持通过网络的媒体流式传输以及本地重放。发送协议数据单元的处理是基于时间的,就象时基数据的显示一样,于是适合于用时基格式描述。支持流式传输的QuickTime文件或‘电影’包括与要流式传输的数据单元有关的信息。所述信息被包括在该文件的称为“提示”轨道的附加轨道内。
提示轨道包含给流媒体服务器(或者其它数字处理系统)的帮助分组的形成的指令。这些指令可包含服务器要发送的即时(immediate)数据(例如,首标信息)或者媒体数据的引用段。在本发明的一个实施例中,按照与在QuickTime文件内编码编辑或表现信息以供本地重放的相同方式,在QuickTime文件内编码指令。代替编辑或表现信息,可以提供允许服务器按照适合于使用特定网络传输的流式传输的方式分组化媒体数据的信息。
在本发明的一个实施例中,在包含提示的QuickTime文件内使用相同的媒体数据,无论该媒体数据是用于本地重放,还是通过多个不同传输类型进行流式传输。用于不同传输类型的独立”提示”轨道可被包括在相同的文件内,并且该媒体可通过所有这样的传输类型播放,而不产生媒体自身的任何额外副本。另外,通过为特定的传输增加适当的提示轨道,可使现有媒体是可流式传输的。按照本发明的一个方面,媒体数据本身不必被改写或重新格式化。
于是,提示轨道内的样本一般包括形成分组的指令。这些指令可把服务器要发送的即时数据(例如,首标信息)或者媒体数据的引用段包含在另一轨道中。
在本发明的一个实施例中,使用三层设计以便:
1)将媒体数据表示为一组独立于网络的轨道,这些轨道可被正常播放,编辑等等;
2)存在用于服务器提示轨道的公共说明以及基本结构;该公共格式与协议无关,但是包含在服务器轨道中描述哪些协议的声明;
3)存在用于可被传送的每种协议的服务器提示轨道的特定设计;所有这些设计使用相同的基本结构。例如,存在用于RTP(用于因特网)以及MPEG-2传输(用于广播),或者用于新的标准或者厂家特有协议的设计。
在本发明的一个实施例中,在提示轨道的指示下由服务器发送而产生的数据流为正常数据流,并且不必包括极少量的QuickTime信息。本发明的实施例不要求QuickTime,或其结构或声明形式必须在传输媒体(例如网络电缆)上的数据内或者在解码站中。例如,在本发明的一个实施例中,利用按照RTP流式传输的H.261视频和DVI音频的文件可导致完全服从IETF规范的分组流,IETF规范把这些H.261视频和DVI音频打包成RTP。
在本发明的一个实施例中,可以构建并标记提示轨道,以便当本地浏览表现(presentation)时,接收系统基本忽略提示轨道。
在一个实施例中,可包括视频、音频等的媒体数据的时间相关序列可由数字处理系统分组,随后在相同的数字处理系统上表现。此外,分组可以是瞬息的,以致正被表现、存储、读取等的时间相关序列“在传输中(on the fly)”也被分组化。在一个实施例k,提示可以引用还未被复制、格式化等的媒体数据;例如,提示引用的媒体数据可以按照原始格式保存在只读存储器等中。
在一个实施例中,当进行分组化时,提供分组化的相同提示例程也表现该媒体。在本发明的备选实施例中,时间相关媒体数据的分组文件可按照提示轨道产生并被保存供稍后传输之用。
图4图解说明按照本发明的一个实施例,传送媒体数据的提示轨道的使用。在图4中,对于媒体轨道403示出提示轨道401。每个提示轨道样本,例如描述如何形成RTP分组的提示轨道样本405,可以包含一个首标,并且可以从相关媒体轨道—这种情况下视频轨道403引用某些数据。在图4中所示的实施例中,可以交织媒体数据(视频帧)和RTP提示,以便可以相当容易地读出相关媒体文件。在该例子中,每一帧被表示成装入单一的RTP分组中。当然,当需要时,也可以将帧分成几个分组。相反,如果需要的话,多个帧也可以被放入单独的分组中,该分组通常和音频数据一起被执行。
如上所述,上述的逻辑结构不必暗示物理结构。元数据可被高速缓存在存储器内,提示轨道样本与其引用的媒体样本物理交织(如图4中所示)。
另一方面,可以写入包含提示轨道的一组新的元数据和媒体数据,所述提示轨道引用并增加现有表现中的元数据和媒体数据。图5图解说明按照本发明一个实施例,使用提示轨道引用独立文件中的媒体数据。在图5中,表示了两个电影文件502和504,每个电影文件具有它们自己的元数据。第一个电影文件502包括一个视频轨道。第二个电影文件504既包含视频轨道,又包含提示轨道,但是元数据声明视频轨道的媒体数据在第一电影502内。这样,与电影文件504相关的提示也指向第一电影502中的媒体数据。
在本发明的一个实施例中,媒体文件可以包含用于多种协议的分组化提示轨道。因而,每个轨道可以包含该提示轨道所适合的协议(以及协议参数,如果合适的话)的声明。当然,这些轨道可以全部引用出自文件中的基本媒体轨道的媒体数据。按照所述方式可以满足对协议无关性和扩展性的要求。
在本发明的一个实施例中,提示轨道不必使用媒体轨道中的所有数据。为了达到带宽阈值,或者由于其他原因,提示轨道可以使用该数据的子集(例如,通过省略某些视频帧)。由于可为相同的协议提供多个提示轨道,因此可以提供不同比率下的相同基本媒体数据信息的不同子集。因而,本发明可以提供较已有方法和设备改进的可缩放性。
应该强调的是,在一个实施例中,尽管提示轨道本身,以及QuickTime元数据应在QuickTime文件中,但是基本媒体可以保留在QuickTime能够输入并且原地引用的任何文件类型中。在本发明的一个实施例中,电影文件中的元数据可包括声明媒体数据在另一文件中的数据引用。样本表偏移量和指针从而可以指向该“外部”文件中的数据。从而,按照本发明的一个实施例,在不需要基本媒体数据的复制或重新格式化的情况下,能够流式传输诸如“au”音频文件,“AVI”音/视频文件和MIDI文件之类的现有遗留格式。由于基本媒体数据不被写入,而是仅仅由独立文件中的QuickTime声明和提示信息增加,因此也可以在诸如CDROM之类的只读机器可读介质上提供基本媒体信息。
在本发明的一个实施例中,提示轨道体现离线计算的结果,并且一般被优化以便向服务器提供支持分组、并且如果需要的话支持多路复用的信息。
在附录A-C中示出用于RTP(IETF标准实时协议)以及MPEG-2传输的例证提示。
在本发明的一个实施例中,单一的文件可以支持用于多种协议的提示轨道,或者相同协议的多个不同参数化,而不存在过度的空间开销。在不影响依赖于现有协议的系统的情况下,可以设计新的协议,及其相关的提示轨道。从而,至少在一个实施例中,本发明是协议中性的。
在QuickTime文件格式中,通过更新或者复制并增加元数据,可以向电影中增加一个轨道。如果媒体数据位于与元数据分开的文件内,或不需要优化的交织,那么这是相对简单和有效的操作。
在本发明的一个实施例中,通过建立只包含一个轨道的一组新的电影元数据,可以提取轨道,如果需要的话,所述轨道可引用原始文件中的媒体数据。
例如,在本发明的一个实施例中,可以增加一个新的音频轨道,该音频轨道被标记为一组其它音频轨道的替换物。如果还用语言代码(例如,法语,或Tagalog)标记该新的音频轨道,那么在表现时可以选择适当的轨道。
按照本发明的一个实施例,SMPTE时间码轨道是当需要时,可被表现、增加或者除去的基本数据流的一个例子。
按照本发明的一个方面,提示轨道允许开发用于新协议的新格式,而不会对现有服务器或者本地重放引起兼容性问题。另外,可以在文件格式的生存期内增加新的媒体轨道,同时保持向后兼容性。
在本发明的一个实施例中,可扩展性领域包括:
a)可为未被当前的QuickTime文件格式覆盖的媒体类型(例如,实验室仪器读数)定义的新的轨道类型。
b)可定义的用于现有轨道的新的编码类型(例如,视频或音频编解码器)。存在用于其编解码器特有的初始化信息的明确规定。
c)可为新的协议定义的新的提示轨道类型,和可包含用于一种以上协议的提示信息的文件,而不会招致用于媒体数据本身的空间开销。
只读介质上的现有内容可以和本发明一起使用(例如,CDROM,DVD等上的预分组电影)。
另外,按照本发明的一个方面,可以使用各种“外部”文件格式。例如,在本发明的一个实施例中,如果现有内容是QuickTime格式,或者可被输入,那么现有内容可被编码和流式传输,而不需要复制或重新格式化。
在本发明的一个实施例中,如果编解码器支持媒体数据的条带化,以实现带宽的可缩放性,那么可以使用多个流轨道表示这些分带带宽。每个轨道可以表示一个不同的带宽。轨道可被归入选择的基本媒体的子集中。
在本发明的一个实施例中,如果协议支持带宽可缩放性,那么提示轨道本身可以包含每个协议数据单元(提示轨道内的样本)的信息。信息可以包括带宽阈值,高于该带宽阈值,协议数据单元应被传给网络。从而,提示轨道可以指示较高,较低等的可用带宽,和/或与数据传输带宽有关的其他信息。
在本发明的一个实施例中,如果协议为多路复用协议(例如,MPEC-2传输),那么可以建立使用基本流轨道的不同子组来实现不同数据率的不同提示轨道。从而,对于低位速率传输来说,可以完全忽略某些轨道。
在本发明的一个实施例中,如果要求利用不同的编解码器记录基本数据,那么这些轨道可以形成为一组替换物,并且仅选择一个用于表现。选择使用哪个轨道用于表现一般与协议有关,并且可以利用这里描述的提示轨道方法来实现。
在本发明的一个实施例中,也可以对媒体文件预先应用加密。这种情况下,加密数据可被保存在(a)与原始媒体数据链接的一个新的基本流(新的轨道)(或者原始媒体数据可被除去,如果不再需要它的话),或者(b)提示轨道本身。在情况(b)下,提示轨道可能未从传输中的基本未加密流中提取任何数据。从而,所有媒体数据可能在提示轨道以及流式传输分组协议数据单元信息中,因为可以通过加密转换媒体数据。
作为嵌入对象内容信息的例子,用于整个电影,以及用于各个轨道的IETF会话描述信息可被保存在RTP提示轨道的元数据内,作为用户基本单元。
在本发明的一个实施例中,文件格式一般既包括可播放格式的媒体数据,又包括流式传输信息。在一个实施例中,能够以较低的开销直接从该格式进行流式传输,同时保持媒体独立性,协议独立性,以及本地表现媒体的能力。
按照本发明的一个方面,提示轨道可以将编解码器、定时和分组化的详细知识概括成离线准备过程。从而,按照提示轨道产生数据流可能相对简单,并且不需要正在流式传输的媒体的专门知识。从而,按照本发明的一个方面,可以提供服务器与数据内容的细节的去耦。
在本发明的一个实施例中,一组提示轨道可被用于构成一个被直接优化以用于流式传输的文件--例如,通过按照应发送网络PDU的时间顺序,把磁盘上的网络PDU布置在逻辑磁盘边界。这样的文件可能不再是一般的表现,而是可被流式传输。在一个实施例中,利用提示轨道创建的分组文件可被保存,并且稍后被优化以便用于流式传输。
在本发明的一个实施例中,通过封装外部文件格式,在仍用QulckTime公布的同时,媒体数据可按照其它格式被保留。例如,通过应用适当的包装程序,现有格式可被直接封装到新的媒体数据文件中,或者现有格式可以保持原样,并由提示轨道分段或者整个引用,从而允许在不进行复制的情况下,流式传输传统格式。一个电影可以包含从多个传统格式选择的片段(pieces)。本发明并不限制基本媒体格式。
通常,跨越捕获、创作和编辑,下载和流式传输的普通格式一般提供灵活性。材料可在使用之后被修改,或者按照多种方式使用,而不被复制或重新格式化。在本发明的一个实施例中,通过利用标准编辑器剥离提示轨道,随后在完成编辑之后重新提示,有可能改写和重新使用已被提示的材料。
如果希望下载媒体文件以便本地浏览,那么可以利用引用相同的基本媒体数据的独立声明文件中的流式元数据,为此构建一个优化的交织文件。于是,下载可以不包括流式信息,然而媒体数据只在流式传输服务器上被表现一次。
通过将逻辑结构和物理结构分开,可根据应用(例如,编辑、本地浏览、流式传输)不同地优化文件的物理结构。
在本发明的一个实施例中,通过允许对每个媒体轨道存在多个提示轨道,可以通过经多种协议的流式传输公布该文件,而不需要媒体的多次复制。
图6是按照本发明的一个实施例的可以处理媒体数据的计算机系统的网络图。如图6所示,多个客户机计算机系统(其中的一个或多个表示上面参考图3说明的接收系统的实现)通过因特网622耦合在一起。要认识到术语“因特网”指的是多个网络的网络。这样的网络可以使用多种协议来交换信息,例如TCP/IP、ATM、SNA、SDI等。因特网的物理连接以及因特网的协议和通信程序对本领域技术人员来说是公知的。对因特网103的接入一般由因特网业务提供者(ISP),比如ISP 624以及ISP 626提供。客户机系统,比如客户机计算机系统602、604、618和620的用户一般通过因特网业务提供者,比如ISP624和ISP 626接入因特网。接入因特网可以方便两个或更多数字处理系统,比如客户机计算机系统602、604、618和620和/或Web服务器系统628之间的信息(例如,电子邮件、文本文件、媒体文件等)的传送。例如,一个或多个客户机计算机系统602、604、618和620和/或Web服务器系统628可以将媒体数据(例如,视频和音频,或视频,或音频)提供给另外的一个或多个客户机计算机系统602、604、618和620和/或Web服务器系统628。这可响应请求而提供。如这里所述,这样的媒体数据可以根据提示在系统600内传送。在本发明的一个实施例中,可以根据媒体数据的特定格式和/或特定的数据通信(例如网络)协议创建这样的提示。
Web服务器628一般由按照一种或多种数据通信协议,例知万维网协议操作的至少一个计算机系统组成,因而,一般与因特网622耦接。可选的是,Web服务器628可以是向客户机计算机系统提供对因特网和/或其它网络的接入的ISP的一部分。客户机计算机系统602、604、618和620都可借助适当的web浏览软件,访问由Web服务器628提供的数据,例知HIML文件(例知,web网页)。这样的数据可以提供可由客户机计算机系统602、604、618和620表现的媒体,比如QulckTime电影。
ISP 624通过调制解调器接口606为客户机计算机系统620提供因特网连通性,调制解调器接口606可被看作客户机计算机系统602的一部分。客户机计算机系统可以是一个常规的计算机系统,例如Macintosh计算机,“网络”计算机,手持/便携式计算机,Web TV系统,或者其它类型的数字处理系统(例知,具有数字处理能力的蜂窝电话)。类似地,ISP 626为客户机计算机系统604、618和620提供因特网连通性,尽管如图6所示,这样的连通性在各个客户机计算机系统,例如客户机计算机系统602、604、618和620之间可能会变化。例如,如图6中所示,客户机计算机系统604通过调制解调器接口608耦接到ISP 626,而客户机计算机系统618和620产局域网(LAN)的一部分。在图6中,分别表示成调制解调器606和608的接口606和608可以是模拟调制解调器,ISDN调制解调器,线缆调制解调器,卫星传输接口(例如,“直接PC”),无线接口,或者将数字处理系统,比如客户机计算机系统耦接到另一数字处理系统的其它接口。客户机计算机系统618和620分别通过网络接口614和616与LAN总线612耦接。网络接口614和616可以是以太网接口,异步传输模式(ATM)接口,或者其它类型的网络接口。LAN总线还与网关数字处理系统610耦接,网关数字处理系统610可向LAN提供防火墙以及其它因特网相关业务。网关数字处理系统610再与ISP 626耦接,以便向客户机计算机系统618和620提供因特网连通性。网关数字处理系统610可以包括,例如常规的服务器计算机系统。类似地,Web服务器628可以包括,例如常规的服务器计算机系统。
系统600可以允许一个或多个客户机计算机系统602、604、618及620和/或Web服务器628向另外的一个或多个客户机计算机系统602、604、618、及620和/或Web服务器628提供媒体数据(例如,视频和音频,或视频,或音频)。例如,可以响应接收系统的请求提供这样的数据,所述接收系统可以是例如客户机计算机系统602、604、618和620中的一个或多个。如这里所述,可以按照提示或提示轨道在系统600内传送这样的媒体数据。在本发明的一个实施例中,可以按照媒体数据的特定格式和/或特定的数据通信(例如,网络)协议创建这样的提示,以便按照本发明的一个方面,允许媒体数据的分组化。
图7是按照本发明一个实施例可以使用的数字处理系统的方框图。例如,图7中所示的数字处理系统650可用作客户机计算机系统,Web服务器系统,常规服务器系统等。另外,数字处理系统650可被用于执行因特网业务提供者,比如ISP 624或626的一个或多个功能。数字处理系统650可以通过调制解调器或网络接口668与外部系统连接。要认识到调制解调器或网络接口668可被视为数字处理系统650的一部分。调制解调器或网络接口668可以是模拟调制解调器,ISDN调制解调器,线缆调制解调器,令牌网接口,卫星传输接口,无线接口,或者在两个或多个数字处理系统之间提供数据通信链路的其它接口。
数字处理系统650包括处理器652,处理器652可以代表一个或多个处理器,并且可以包括一个或多个这种处理器的常规类型,例知Motorola PowerPC处理器,Intel Pentium(或x86)处理器等。存储器155通过总线656耦合到处理器652。存储器155可以是动态随机存取存储器(DRAM)和/或可以包括静态RAM(SRAM)。处理器还可以耦合到其它类型的存储区/存储器(例知,高速缓存存储器,闪速存储器,磁盘等),所述其它类型的存储区域/存储器可被认为是存储器155的一部分或者与存储器155分开。
总线656还使处理器652与显示控制器658,海量存储器662,调制解调器或网络接口668,和输入/输出(I/O)控制器664耦接。海量存储器662可以代表磁、光、磁-光、磁带和/或用于保存信息的其它类型的机器可读介质/装置。例如,海量存储器662可以代表硬盘,只读或可写光盘CD等。显示控制器658按照常规方式控制显示器660,显示器660代表阴极射线管(CRT)显示器,液晶显示器(LCD),等离子显示器,或者其它类型的显示装置。I/O控制器664控制I/O装置666,I/O装置666可以包括一个或多个健盘,鼠标/跟踪球或者其它指向装置,磁和/或光盘驱动器,打印机,扫描器,数字照相机,麦克风等。
要认识到数字处理系统650仅仅表示可以具有多个不同的配置和结构,并且可以和本发明一起使用的系统的一个例子。例如,Macintosh和Intel系统通常具有多个总线,例如外围总线,专用高速缓存总线等。另一方面,可用作本发明的数字处理设备的网络计算机可以不包括,例如,硬盘或者其它海量存储装置,但是可以从网络连接,例如调制解调器或接口668接收将由处理器652处理的例程和/或数据。类似地,本领域公知的Web TV系统可被视为本发明的数字处理系统,但是这样的系统可以不包括一个或多个I/O装置,例如关于I/O装置666所描述的那些装置。另外,可以采用蜂窝电话和/或寻呼功能的便携式通信和数据处理系统可被视为可和本发明一起使用的数字处理系统。
在图7中示出的系统650中,海量存储器662(和/或存储器654)可以存储按照本发明处理(例如,借助提示)的媒体(例如,视频,音频,电影等)。另一方面,媒体数据可以通过调制解调器或网络接口668被数字处理系统650接收,被保存和/或由显示器660和/或I/O装置666表现。在一个实施例中,可以按照提示轨道,通过数据通信网络,比如LAN和/或因特网传送分组媒体数据。另一方面,处理器652可以执行一个或多个例程,以使用具有一个或多个提示轨道的文件,或者另一方面,创建一个或多个提示轨道,以便按照提示轨道处理媒体(例如,分组电影,音频文件,视频文件等)以便表现或分组。这样的例程可被保存在海量存储器662,存储器664,和/或数字处理系统650可访问的另一个机器可读介质中。在一个实施例中,数字处理系统650可以处理其内嵌有提示轨道的媒体数据。类似地,这样的嵌入媒体数据可被保存在海量存储器662,存储器664,和/或数字处理系统650可访问的另一个机器可读介质中。
图8是按照本发明一个实施例,利用提示传送媒体数据的系统的方框图。图8中所示的系统680包括接收系统,所述接收系统被表示成通过数据通信链路686与服务器694耦接的客户机数据处理系统682。服务器694和/或客户机数据处理系统可以代表,例如参照图6和7描述的设备/系统或其组合。
服务器694包括都可包括硬布线电路或机器可执行指令或者它们的组合的提示生成和处理单元688,媒体处理单元690和数据通信单元692。另外,这种硬布线电路和/或机器可执行指令的至少一部分可以在提示生成和处理单元688,媒体处理单元690和数据通信单元692的组合之间共享。在一个实施例中,至少部分使用与至少一个处理器耦接的保存有适当例程和/或数据的至少一个存储区域/存储器(例如,机器可读介质)来实现提示生成和处理单元688,媒体处理单元690和数据通信单元692之一或其组合。
在一个实施例中,提示生成和处理单元688创建并存储用于媒体处理单元690处理的媒体数据的分组的提示。如上所述,可以生成媒体文件,并相对于媒体文件将其保存为独立的文件,或者可以将其嵌入媒体数据中。如果要处理一种以上的媒体格式,那么提示生成和处理单元688可考虑一种适当的格式来产生该提示。与媒体格式有关的信息可由媒体处理单元690提供,媒体处理单元690还可以提供媒体数据(例如,视频,音频,或视频和音频等的媒体文件)。类似地,数据通信单元692可以提供用于通过数据通信链路686交换按照提示分组的这种媒体数据的一种或多种数据通信(例如,网络)协议。因而,提示生成和处理单元可根据媒体处理单元690提供的媒体格式信息,以及数据通信单元692提供的数据通信协议信息,确定适当的提示以及媒体和/或提示的分组化,以便传给接收数字处理系统,比如客户机数据处理系统682。在一个实施例中,按照QulckTime格式进行媒体和提示的流式传输。
响应通过数据通信链路686接收的媒体数据和提示分组,客户机数据处理系统682可以表现由媒体数据代表的媒体对象。如上所述,可以瞬息进行这样的表现。在本发明的一个实施例中,媒体数据可以可选地由客户机数据处理系统682保存,并且稍后被重新汇编,以便由客户机数据处理系统682表现和/或传输。
图9是按照本发明的一个实施例,利用提示来传送媒体数据的系统的方框图。特别地,图9表示本发明的一个实施例,其中称为发生器的独立数字处理系统可以产生提示(或提示轨道)以提供给另一个系统,例如服务器,所述另一系统利用该提示对媒体数据进行分组化,以便传给另一个系统,比如客户机计算机系统。图9中表示了系统696,系统696包括服务器700,服务器700可以通过数据通信链路686,与客户机数据处理系统682交换数据。然而,在图9中所示的实施例中,服务器700不产生提示。相反,通过数据通信链路708与服务器700耦接的发生器710包括产生用于对媒体数据进行分组化的提示的提示生成单元712。
在一个实施例中,系统696的操作如下所述:服务器700请求发生器710产生包含媒体数据的一个或多个媒体文件的提示。例如,媒体文件可被保存在服务器700内的机器可读介质上。该请求可以包括指示媒体文件的格式和/或媒体数据传输的数据通信协议的信息和/或其他数据。所述数据通信协议可以与数据通信链路686相关,在本发明的一个实施例中,数据通信链路686可以与具有特定物理和逻辑特征,以便于服务器700和客户机数据处理系统682间的媒体和/或其他数据的交换的网络连接相关。响应该请求,提示生成单元712产生与时间相关提示轨道关联的适当提示,并将该提示提供给服务器700。响应通过数据通信链路708从发生器710接收的提示,服务器700,具体地说,提示处理单元702使用该提示对媒体数据进行分组化,以便传给客户机数据处理系统682。
响应通过数据通信链路686接收的媒体数据和提示分组,客户机数据处理系统682可以表现该媒体数据代表的媒体对象。如上所述,可以瞬时地进行这样的表现。在本发明的一个实施例中,该媒体数据可以可选地由客户机数据处理系统682保存,并且稍后被重新汇编,以便客户机数据处理系统682表现和/或传输。
图10是按照本发明的一个实施例,图解说明产生用于提供媒体数据传输的提示的方法的流程图。在步骤720,如果将使用一种以上的格式,那么为待传输的媒体数据确定媒体格式。如果仅使用一种格式,那么不执行步骤720。在步骤722,再次假定可以使用一种以上的协议,那么确定适当的数据通信协议。在步骤724,根据媒体格式和数据通信协议(它们中的一个或者两者已被选择/配置),创建并保存与媒体数据传输相关的提示(例如,提示轨道)。
在步骤726(可选),将提示传给另一个数字处理系统。在本发明的一个实施例中,例如,图10的方法,至少部分可以由一个数字处理系统(例如,一个服务器)专门执行。在一个备选实施例中,图10的方法,至少部分可由两个或多个数字处理系统执行。例如,媒体数据的属性可由服务器或者其他系统提供给另一个数字处理系统,比如发生器。作为响应,发生器可根据所述属性确定适当的媒体格式,数据通信协议,和用于可保存在服务器的媒体数据的分组的提示。另一方面,服务器可以把适当的媒体格式和协议提供给发生器,发生器随后产生提示。发生器可以把该提示传给服务器或其他数据处理系统,所述服务器或其他数据处理系统按照该提示对媒体数据进行分组化。
图11是按照本发明的一个实施例,图解说明处理接收系统按照提示接收的媒体数据的方法的流程图。在步骤730,按照提示或提示轨道传给接收系统的媒体数据由接收系统接收。在一个实施例中,接收系统可接收分组的媒体数据,以及分组的提示轨道。在本发明的一个实施例中,提示轨道可以至少与媒体数据的多个部分相关。可响应接收系统产生的请求,由接收系统接收这样的数据。例如,在一个实施例中,接收系统可以是客户机计算机系统,并且可以向服务器或其他数字系统发出对媒体数据的请求。作为响应,服务器可以产生(或者已由独立的数字处理系统为其产生)用于对媒体数据进行分组化的提示,并将包括所述提示的分组媒体数据传给接收系统。
在步骤732,由接收系统接收的媒体数据代表的媒体对象由接收系统表现。例如,媒体数据可以包括由接收系统在,例如显示器和扬声器上“表现”的视频,音频或者它们的组合。如上所述,该媒体数据可以与QuickTime电影关联。
可选的是,在步骤734,包括提示的媒体数据可由接收系统保存为媒体文件。从而,在本发明的备选实施例中,当接收媒体数据时可不执行步骤732,或者可在步骤734之前,之后,或者并行于步骤734执行步骤732。
在步骤734,保存的媒体文件可以可选地被重新汇编和/或表现。因而,可在步骤734之后执行步骤732。
图12是按照本发明的一个实施例,可由数字处理系统,比如发生器访问的机器可读存储介质的例子。要认识到保存图12中所示和下面参照图12描述的各个元素的实际存储器可以是一个或几个元件,比如一个或多个磁盘(例如,可以是磁盘,光盘,磁-光盘等),上面参照图7所述的存储器654和/或海量存储器662。另外,在其中图12中所示的机器可读存储介质与之关联的发生器是网络计算机的实施例中,机器可读存储介质的一个或多个元素可被保存在另一个数字处理系统并下载到发生器。另外,在某一时间,参照机器可读存储介质描述的元素可被保存在非易失性海量存储器(例如,硬盘)中。相反,在其他时间,机器存储介质的各个元素可分散在不同的存储区,比如DRAM,SRAM,磁盘等之间。
图12表示机器可读存储介质740。在一个实施例中,机器可读存储介质至少部分被按照本发明的一种或多种方法,产生提示或提示轨道的数字处理系统,即发生器使用。如同参照图8所述,发生器可被集成到按照提示轨道传送媒体数据的数字处理系统中,或者如同参照图9所述,可以是创建提示并将其提供给另一个数字处理系统,比如服务器的数字处理系统,所述另一个数字处理系统利用该提示分组并传送媒体数据。
如图12中所示,机器可读存储介质740一般包括多个元素。例如,机器可读存储介质740包括向发生器提供操作系统功能的软件,如发生器操作系统(OS)742所示。网络传输例程748提供数据通信功能,例如例程,协议等,以允许发生器通过数据通信链路传送和接收数据。
另外,机器可读存储介质740包括创建与媒体传输关联的提示的例程和数据。因而,机器可读存储介质740可以可选地包括信息750,信息750提供与提示创建例程744创建提示所必需的一种或多种数据通信协议和媒体格式相关的信息。例如,信息750包括与QulckTime电影,RTP,MPEG等有关的信息。然而,这种信息至少可以部分地集成到提示创建例程744中和/或由远程数字处理系统提供给发生器。
提示创建例程744创建的提示可被保存为创建的提示746,和/或在其他地方保存/发送(例如,在可以是服务器的远程数字处理设备)。该提示是用于媒体数据的分组和传输的时间相关提示轨道,该媒体数据也是时间相关的(例如,视频,音频,视频和音频等)。
尽管关于发生器描述了机器可读存储介质740,不过介质740至少可以部分是多种类型的数字处理系统,数据存储介质等的一部分。例如,机器可读存储介质740至少可以部分被包括为服务器或其他数字处理系统的一部分。另外,机器可读介质740至少可以部分被包括为一个或多个磁盘或其他机器可读介质上的应用软件的一部分。
图13是按照本发明的一个实施例,可由数字处理系统,比如服务器访问的机器可读介质的例子。要认识到保存图13中所示和下面参照图13描述的元素的实际存储器可以是一个或几个元件,比如一个或多个磁盘(比如,可以是磁盘,光盘,磁-光盘等),上面参照图7所述的存储器654和/或海量存储器662。另外,在其中图13中所示的机器可读存储介质与之相关的服务器是网络计算机的实施例中,机器可读存储介质的一个或多个元素可被保存在另一个数字处理系统并下载到服务器。另外,在某一时间,参照机器可读存储介质描述的元素可被保存在非易失性海量存储器(例如,硬盘)中。相反,在其他时间,机器存储介质的元素可分散在不同的存储区域,比如DRAM,SRAM,磁盘等之间。
图13表示机器可读存储介质760。在一个实施例中,机器可读存储介质至少部分被用于按照本发明的一种或多种方法对供在数据通信链路上传输的媒体数据打包。机器可读存储介质760可以与服务器,比如参照图8所述的服务器694关联,以便包括创建提示轨道并按照提示轨道传送媒体数据的例程。在另一个实施例中,机器可读存储介质760可以与数字处理系统,比如参照图9所述的服务器700相关,其中诸如发生器之类的数字处理系统包括创建提示的例程,通过利用由机器可读存储介质760提供的例程处理的提示,服务器可以分组和传送媒体数据。
机器可读存储介质760包括多个元素。例如,机器可读存储介质760包括向服务器提供操作系统功能的软件,如服务器操作系统(OS)762所示。网络传输例程768提供数据通信功能,例如例程,协议等,以允许服务器通过数据通信链路传送和接收数据。
另外,机器可读存储介质760包括根据提示对时间相关的媒体数据分组的媒体分组例程770,所述提示也可被分组。因此,机器可读存储介质760包括分别保存媒体数据(例如,可以是QuickTime电影或其他媒体轨道)和提示(例如,提示轨道)的媒体数据存储区764和提示存储区766。所述提示可以包括用于媒体数据的分组和传输的时间相关的提示轨道,所述媒体数据一般也是时间相关的(例如,视频,音频和音频)。在一个实施例中,提示轨道与媒体数据分开地被分组。在一个实施例中,提示包括识别可能位于独立媒体文件中的媒体数据(例如,特定分组)的指针信息。
图14是按照本发明的一个实施例,可由数字处理系统,比如接收系统或者其他数字处理系统访问的机器可读介质的例子。要认识到保存示于图14中并且下面参照图14描述的元素的实际存储器可以是一个或几个单元,比如一个或多个磁盘(例如,可以是磁盘,光盘,磁-光盘等),上面参照图7说明的存储器654和/或海量存储器662。另外,在其中图14中所示的机器可读存储介质与之相关的接收系统是网络计算机的实施例中,机器可读存储介质的一个或多个元素可被保存在另一个数字处理系统并下载到接收系统。另外,在某一时间,关于机器可读存储介质描述的元素可被保存在非易失性海量存储器(例知,硬盘)中。相反,在其他时间,机器存储介质的元素可分散在不同的存储区,比如DRAM,SRAM,磁盘等之间。
图14表示机器可读存储介质780。在一个实施例中,机器可读存储介质至少部分被用于处理按照本发明的一种或多种方法分组的媒体数据。机器可读存储介质780可以与接收系统,比如参照图8和9描述的客户机数据处理系统682关联,以便包括表现按照提示传送/接收的媒体数据的例程。另一方面,机器可读存储介质780可以包括其中嵌入提示(例如,提示轨道)的媒体数据。这种嵌入媒体数据可由保存在机器可读存储介质,比如机器可读存储介质780上的例程预分组或产生。
机器可读存储介质780可包括多个元素。例如,机器可读存储介质780包括向接收系统提供操作系统功能的软件,如服务器操作系统(OS)772所示。网络传输例程782提供数据通信功能,例如例程,协议等,以允许服务器通过数据通信链路传送和接收数据。
另外,机器可读存储介质780包括用于表现按照提示分组的媒体数据的媒体表现例程778。从而,机器可读存储介质780,具体地说,媒体表现例程778可以包括用于音频和/或视频数据的解压缩,视频的显示,和/或重放音频等的例程。另外,媒体表现例程778一般提供与媒体数据相关的提示的处理。在一个实施例中,当表现媒体时可简单地忽略提示。
可选的是,机器可读存储介质780可把已按照提示分组的媒体数据保存为媒体数据774,并包括可重新汇编保存的媒体数据(例如,以便被表现,传送等)的媒体数据重新汇编例程776。
图15是按照本发明的一个实施例,在其上保存/传送媒体和提示信息的数据存储和/或通信介质的示图。图15表示数据存储和/或通信介质(介质)800,该数据存储和/或通信介质(介质)800代表其中可以保存或传送按照本发明分组的媒体数据分组804和提示分组806的各类传输和/或存储介质。例如,介质800可以代表上面参照图7描述的海量存储器662和/或存储器654。介质800还可以代表通信介质,比如图6中所示的LAN总线612,或者用于传送代表媒体的数据/信号和/或其他信息的数据通信链路686。
如图15中所示,提示分组806和媒体分组804可以集成为一个分组,或者被单独保存和/或传输。另外,提示分组806和媒体分组804可以包含几种格式,比如这里描述的格式,或者与其他媒体格式,网络协议,和/或数字处理设备结构相关的格式。
提取器轨道
除了包含分组构建指令之外,提示轨道可被用于指示存在于可缩放编码媒体中的多个媒体流。可缩放编码媒体保存相同视频内容的多个版本。例如,可缩放编码媒体可保存适合于手持设备,计算机,标清设备,高清设备等的视频流。可缩放编码媒体的一个例子是和H.264/MPEG-4 AVC视频编译码器一起使用的可缩放视频编码,如图16A中所示。SVC(可缩放视频内容)被用于指示编码成单一SVC基本视频轨道的多个视频流。这里,SVC用于表示可缩放媒体内容或可缩放内容,并且是可缩放媒体内容或可缩放内容的一个例子。可从SVC基本视频轨道得到的每个视频流对应于一个视频操作点。尽管在一个实施例中,视频操作点对应于时间(例如每秒的帧数(fps)),空间(例如,水平方向和垂直方向的像素数目)和质量视频属性(例如,不同的信噪比),不过视频操作点的备选实施例可具有更多、更少和/或不同的视频属性(例如,位深度、色度二次抽样频率等等)。时间视频属性包括视频帧频(例如,15帧/秒(fps)、24fps、30fps等等)。另一方面,空间视频属性描述视频流的视频分辨率。例如,视频流可以是子1/4公用中分辨率格式(SQCIF,分辨率128×96像素),1/4CIF(QCIF,分辨率176×144像素),CIF(分辨率352×288像素)等等。下面在图16B中进一步说明空间视频属性。另外,视频质量属性把质量属性描述成信噪比。例如,可以与不同的信噪比对应的变化位速率(例如,128、192kbps等)发送指定分辨率和帧频的视频。
图16A图解说明SVC编码视频基本轨道的一个实施例。在图16A中,SVC基本轨道1600被分成单独的帧1602A-D。每个帧1602A-D包含一个或多个网络抽象层(NAL)单元1604A-D、1606A-D、1608A-D。NAL单元是视频基本轨道被分成适合于各种通信通道和/或存储介质的单元所得到的分块。每组NAL单元1604A-D、1606A-D、1608A-D可被用于不同分辨率视频格式。例如,NAL单元1604A-D包括低分辨率媒体流,比如SQCIF。低分辨率视频流是用于具有小屏幕和/或有限资源(存储器等)的设备的视频流,如图16B中所示。图16B是图解说明变化的视频分辨率的一个实施例的方框图。在图16B中,图解说明三个视频分辨率:第一视频分辨率1650,第二视频分辨率1652和第三视频分辨率1654。例如,低分辨率视频流是第一视频分辨率视频1650。
返回图16A,组合NAL单元1604A-D和1606A-D得到一个不同的视频流,该视频流是第二分辨率视频(例如,QCIF视频流)。如图16B中所示,第二分辨率视频1652是分辨率较高的视频流,即,适合于更大屏幕的显示器或者具有更多资源的设备的视频。
返回图16A,利用三组NAL单元1604A-D、1606A-D、1608A-D产生第三个更高分辨率的视频流(例如,全CIF视频流)。如图16B中所示,出自NAL单元1604A-D、1606A-D、1608A-D的视频流产生第三分辨率视频1654。与第一分辨率视频1650和第二分辨率视频1652相比,第三分辨率视频1654具有更高的分辨率。例如,第三分辨率视频是CIF格式的视频(352×288像素)。
从而,SVC基本轨道1600由单一视频基本轨道至少产生三个独立的视频流。这允许一个基本编码视频轨道被用于不同的目标设备,或者操作点。例如,第一分辨率视频1650可被用于向蜂窝电话机流式传输视频,第二分辨率视频1652可被用于向便携式浏览器流式传输视频,而第三分辨率视频1654可被用于向标准电视机流式传输视频。
由于SVC编码基本轨道包含用于时间、空间和质量视频质量的多种组合的视频流,因此每个视频流的轨道可被保存为一个轨道或者独立的多个轨道。就独立的多个轨道来说,管理数目可能极大的独立轨道的开销变得难以处理。例如,如果存在L个不同时间视频属性,M个不同空间视频属性和N个不同质量视频属性,那么在单一SVC基本轨道中可能存在高达L*M*N个不同的视频流。汇编视频流以供给视频解码器意味着每个样本L*M*N次逻辑追加操作。另一方面,如果多个视频流被保持在单一基本轨道中,如图16A中所示,为了提取视频流的子集,必须走遍SVC编码基本轨道中的每个视频流,以找出特定视频流子集的相关数据。这意味着必须访问L*M*N个不同视频流的所有数据,以确定所述特定视频流子集。此外,由于SVC编码基本轨道一般被保存在ISO文件中,因此一个视频SVC基本轨道的数据被连续保存在帧中。从而,SVC基本轨道的帧包含所有数据,解码器必须读取所有数据,并丢弃它不使用的数据。
总而言之,最好使用单一SVC基本轨道(或者至少一组SVC基本轨道,每个SVC基本轨道包含可缩放内容),因为视频解码器不必处理L*M*N个视频流。但是,有时候把可用视频流之一作为独立的邻接视频流会是有用的。所需的是一种从SVC基本轨道提取可用视频流,而不走遍整个SVC基本轨道的机制。一种形式的提示轨道(例如,提取器轨道(extractor track))可被用于提取存在于单一SVC基本轨道中的多个视频流。每个提取器轨道代表一个建议的操作点(例如,质量,时标和/或空间大小的唯一组合),并且包含如何汇编出自SVC基本轨道的该操作点所需的数据(例如,所得到的视频流),同时忽略SVC基本轨道中的其它数据。特别地,提取器轨道可被用于两个或更多的质量、时标和/或空间大小视频属性的唯一组合。尽管在一个实施例中,提取器轨道被用于可缩放的编码视频(例如,在一段时间内的预定时刻,按照预定次序表现的一系列的相关图像),不过备选实施例可把提取器轨道用于其它形式的可缩放媒体(例如,音频,场景等)。在一些实施例中,提取器轨道可以是独立于并且不同于提取器轨道所引用的基本轨道的数据结构;在其它实施例中,提取器轨道可交织在基本轨道内,或者甚至可包含出自基本轨道的媒体数据的多个样本。
图16C图解说明利用聚合器NAL单元1660A-B的SVC编码视频基本轨道的一个实施例。在图16C中并且类似于图16A,SVC基本轨道1660被分成独立的帧1602A-D。每个帧1602A-D包含一个或多个NAL单元1604A-D,1606A-D,1608A-D。NAL单元是把视频基本轨道分成适合于各种通信通道和/或存储介质而产生的分块。每组NAL单元1604A-D,1606A-D,1608A-D可被用于不同的视频流。视频流可在分辨率、质量、位速率(例如,数据传输的位速率)等方面不同。例如,NAL单元1604A-D包含低分辨率媒体流,比如SQCIF、QCIF、CIF等等。但是,不同于图16A,在图16C中,利用聚合器NAL单元1662A-B组织NAL单元1604A-D,1606A-D,1608A-D中的一些。聚合器NAL单元1662A-B被用于把NAL单元组织成多组NAL单元。
在一个实施例中,聚合器NAL单元包含一个或多个NAL单元,长度,类型和额外字节。所述长度是初始NAL单元的长度。类型表示NAL单元的类型。额外字节表示初始NAL单元之后的额外字节,并被用作到聚合的NAL单元中的附加NAL单元的偏移量。
在一个实施例中,聚合器NAL单元1662A包含NAL单元1604A和1606A。在该实施例中,聚合器包含部分的视频帧1602A,并且支持第一分辨率视频和第二分辨率视频的提取。另一方面,在另一实施例中,聚合器NAL单元1662B包含用于整个帧的NAL单元,即NAL单元1604B、1606B和1608B。在该备选实施例中,聚合器NAL单元运动第一分辨率数据、第二分辨率数据和第三分辨率数据的提取。
图17A是图解说明用于从SVC编码基本轨道提取视频流的提取器轨道的一个实施例的方框图。在图17A中,SVC基本轨道1600包含视频帧1602A-B,每个视频帧1602A-B包含可用于不同视频流的NAL单元1604A-B、1606A-B、1608A-B。类似于图16A,第一视频流汇编自NAL单元1604A-B(例如,SQCIF视频流),第二分辨率视频流汇编自NAL单元1604A-B和1606A-B(例如,QCIF视频流),而第三视频流可汇编自NAL单元1604A-B、1606A-B、1608A-B(例如,CIF视频流)。不同于图16A,提取轨道1700和1710被用于提取存在于SVC基本轨道1600中的不同视频流。类似于AVC和SVC基本轨道构成提取器轨道1700,因为提取器轨道1700是一系列的NAL单元。提取器轨道NAL单元可以与其它NAL单元混合。此外,提取器轨道1700具有链接提取器轨道1700和SVC基本轨道1600的‘scal’轨道引用。另外,提取器轨道具有和SVC基本轨道1600相同的轨道类型。
例如,提取轨道1700包含分别引用SVC基本轨道1600中NAL单元1604A-B,1606A-B的NAL单元1704A-B,1706A-B。NAL单元1704A-B,1706A-B指令视频解码器找出SVC基本轨道1600中时间上对准的NAL单元,并提取该NAL单元的全部或者部分,例如细粒度可缩放性(FGS)NAL单元的一部分。例如,NAL单元1704A指令解码器找出NAL单元1604A,并提取一些或者全部NAL单元1604A。如果NAL单元1704A指令解码器提取部分的NAL单元1604A,那么NAL单元1704A包含关于要取回的字节数和到NAL单元1604A的偏移量的指示。仅仅取回部分的SVC基本轨道NAL单元是从SVC基本轨道1600提取变化的视频质量水平的一个实施例。在一个实施例中,利用包含累进的细化切片(refinement slice),例如FGS切片的NAL单元进行部分NAL单元的提取。
此外,为了保持恒定的质量水平,提取器轨道1700 NAL单元可提取不同数量的基本轨道NAL单元。在一个例证实施例中,提取器轨道计算正确的切割点,以保持恒定的视频质量。例如,NAL单元1704A可指示解码器从NAL单元1604A提取更多,而NAL单元1704B可指示从NAL单元1604B的较少提取,以保持总的视频质量。由于提取轨道1700引用NAL单元1604A-B、1606A-B,因此提示轨道1700代表第二分辨率视频流。从而,通过读取提取轨道1700,视频解码器能够提取第二分辨率流,而不必处理整个SVC基本轨道1600。
类似于提取轨道1700,提取轨道1710包含NAL单元1714A-B。但是,代替引用SVC基本轨道1600中的对应NAL单元的NAL单元1714A-B,NAL单元1714A-B是NAL单元1604A-B的至少多个部分的副本。从而,通过包含第一分辨率视频流所需的NAL单元,提取轨道1710代表第一分辨率视频流。此外,正如视频文件中的其它轨道一样,提取器轨道200、210可被提示。但是,包含引用提取器NAL单元的提示轨道应提取包含在引用NAL单元中的字节。例如,包括引用提取器NAL单元1704A-B的提示轨道应从引用的基本NAL单元1604A-B提取字节。
此外,在一个实施例中,提取轨道1700、1710还能够包含既不是NAL引用单元,又不是出自基本轨道的NAL单元的副本的NAL单元。在该实施例中,这些NAL单元是不同于SVC基本轨道1600的视频基本轨道的分块。本实施例可被用于组合出自SVC基本轨道1600的提取NAL单元和不同的NAL单元,以形成第二视频流。例如,一个提取轨道组合出自15帧/秒(fps)的低分辨率SVC基本轨道的提取轨道和另外的NAL单元,以表示15fps高分辨率视频流。从而,提取轨道可被用于根据低质量视频流构建高质量视频流。另外,另一提取轨道组合出自15fps低分辨率SVC基本轨道的提取轨道和另外的NAL单元,以表示30fps高分辨率视频流。本例示范利用提取器轨道从低帧频视频流构建高帧频视频流。从而,提取器轨道可被用于从高质量视频流提取低质量视频流,或者由低质量视频充构建高质量视频流。使用提取器轨道或者其它各组数据来创建低质量视频特别有益于在一段时间之后细化保存的视频(例如在一段时间之后,细化保存的监视视频)。这种情况下,把视频数据包括在提取器轨道自身内是有益的。
图17B是图解说明用于从包含聚合器网络抽象层单元的SVC编码基本轨道提取视频流的提取器轨道的一个实施例的方框图。类似于图17A,SVC基本轨道1660包含视频帧1602A-B,每个视频帧1602A-B包括可用于不同视频流的NAL单元1604A-B、1606A-B、1608A-B。SVC基本轨道1660还包括聚合器NAL单元1660A-B。聚合器NAL单元1660A聚合NAL单元1604A,1606A,聚合器NAL单元1660B聚合NAL单元1604B,1606B。类似于图16A,第一分辨率视频流汇编自NAL单元1604A-B(例如,SQCIF视频流),第二分辨率视频流汇编自NAL单元1604A-B和1606A-B(例如,QCIF视频流),而第三视频流可汇编自NAL单元1604A-B、1606A-B、1608A-B(例如,CIF视频流)。如图17A中所示,提取轨道1700和1760被用于提取存在于SVC基本轨道1660中的不同视频流。类似于AVC和SVC基本轨道构成提取器轨道1750,因为提取器轨道1750是一系列的NAL单元。提取器轨道NAL单元可以和其它NAL单元混合。此外,提取器轨道1750具有连接提取器轨道1750与SVC基本轨道1660的‘scal’轨道引用。另外,提取器轨道具有和SVC基本轨道1600相同的轨道类型。另外,提取器轨道可以引用或者复制自聚合器NAL单元。
在一个实施例中,提取轨道1750利用NAL单元1754A-B、1756A-B引用聚合器NAL单元1660A-B。通过引用聚合器NAL单元1660A-B,提取轨道1750引用包含聚合器NAL单元的所有NAL单元。在另一实施例(未示出)中,作为提取轨道1750一部分的NAL单元可以引用聚合NAL单元内的特定NAL单元。通过引用特定单元,引用NAL单元引用该特定NAL单元,而不引用作为聚合器NAL单元一部分的其它NAL单元。类似于图17A,NAL单元1754A-B具有和引用单一NAL单元的NAL单元类似的性质。例如,提取轨道1750包括引用SVC基本轨道1600中的聚合器NAL单元1660A-B的NAL单元1754A-B、1756A-B。NAL单元1754A-B指示视频解码器找出SVC基本轨道1660中的时间对准的NAL单元,并提取聚合的NAL单元的全部或者部分。例如,NAL单元1754A指示解码器找出聚合器NAL单元1660A,并提取包含聚合器NAL单元1660A的一些或全部NAL单元。如果NAL单元1754A指示解码器提取聚合器NAL单元1660A的一部分,那么NAL单元1754A包含关于待取回的字节数和到聚合器NAL单元1660A的偏移量的信息。仅仅取回SVC基本轨道NAL单元的一部分是从SVC基本轨道1600提取变化的视频质量水平的一个实施例。此外,为了保持恒定的质量水平,提取器轨道1750 NAL单元可提取不同数量的基本轨道NAL单元。在一个例证实施例中,提取器轨道计算正确的切割点,以保持恒定的视频质量。
类似于提取轨道1750,提取轨道1760包含NAL单元1764A-B。但是,代替引用SVC基本轨道1600中的对应聚合器NAL单元的NAL单元1764A-B,NAL单元1764A-B是NAL单元1604A-B的至少多个部分的副本。此外,正如视频文件中的其它轨道一样,提取器轨道1750、1760可被提示。
图18是图解说明包含提取器轨道的视频文件的一个实施例的方框图。在图18中,视频文件1800包含电影首标1802,视频元数据1804-1810和数据1812。视频元数据1804-1810包含音频轨道1804和视频轨道1806-1810。每个轨道1804-1810描述哪些视频/音频轨道存在于视频文件1800中。例如,三种视频存在于视频文件1800中:SQCIF AVC视频轨道1806,QCIF SVC视频轨道1808和SQCIF SVC视频轨道1810。视频解码器能够询问元数据1804-1810,以确定在视频文件1800内,什么类型的视频/音频流可用。数据1812包含视频帧(例如,如图16A中所示的NAL单元1604A-D),音频帧和提取器轨道。
图19是图解说明利用SVC基本轨道产生并使用提取器轨道的系统的一个实施例的方框图。在图19中,基本轨道创建器1902创建包含SVC基本轨道的媒体。基本轨道被保存在存储器1910中。另外,SVC提取器轨道创建器1916使用来自基本轨道创建器1902的基本轨道,并创建每个操作点的提取器轨道。每个操作点的提取器轨道一般来源于其对应的基本轨道。操作点是关于时间、空间和质量视频属性的视频可缩放性的唯一组合。例如,SVC提取器轨道创建器1916可为视频流创建提取器轨道,所述视频流是低质量的8fps SQCIF视频流;中等质量的24fps QCIF视频流;高质量的30fps CIF视频流等。通常,SVC提取器轨道创建器1916能够为输入的SVC基本轨道支持的任何视频流创建提取器轨道。尽管在一个实施例中,创建的SVC提取器轨道被保存在存储器1910中,不过在备选实施例中,可独立于对应的SVC基本轨道保存提取器轨道。要认识到可能仅仅对于操作点的合理子集,而不是对于所有可能的操作点存在提取器轨道,用户(例如客户机系统)从该子集中选择可用的操作点。另一方面,SVC提取器轨道1916能够由两个或者更多的视频流形成单一的SVC轨道,同时除去视频流的不必要或者冗余部分。例如,SVC提取器轨道1916可由中等质量的24fps QCIF视频流和高质量的30fps的CIF视频流创建包含SVC基本轨道的SVC媒体。SVC提取器轨道1916把这两个视频流处理成CIF基本轨道和用于QCIF视频流的提取器轨道。
创建的SVC基本轨道和提取器轨道可按照各种方式使用。在一个实施例中,本地客户机1904从存储器1910读取SVC基本轨道和提取器轨道,以确定在SVC基本轨道和提取器轨道中哪些视频流是可用的。根据可用的视频流,本地客户机利用对应的提取器轨道从SVC基本轨道提取所需的视频流。尽管在一个实施例中,本地客户机是在存储器1910本地的机器上运行的程序的单一实例,所述单一程序能够读取并处理基本轨道和提取器轨道,不过在备选实施例中,本地客户机可以是相同类型的程序的一个以上实例。下面在图21中进一步说明由本地客户机进行的SVC基本轨道和提取器轨道的处理。
在一个备选实施例中,传输服务器1906为远程客户机1908A-B处理SVC基本轨道和提取器轨道。在这种客户机-服务器安排中,远程客户机1908A-B向传输服务器1906传送对可从SVC基本轨道和提取器轨道得到的视频的请求。在客户机-服务器实施例之一中,远程客户机1908A-B通过直接向传输服务器1906请求视频流,请求视频。作为响应,传输服务器1906访问对应的提取器轨道,并使用提取器轨道从SVC基本轨道取回所请求的视频流。传输服务器1906组装该视频流,并把该视频流发回给发出请求的远程客户机。下面在图22中进一步说明这种客户机-服务器实施例。在该方法中,传输服务器1906利用提取器轨道仅仅取回和传送基本轨道的多个部分,基本轨道的所述多个部分是正被发出请求的远程客户机408A-B使用的操作点的一部分。
在备选的客户机-服务器实施例中,远程客户机1908A-B向传输服务器1906请求可能的可用视频流。作为响应,传输服务器1906向发出请求的远程客户机1906A-B返回可用视频流的列表。尽管在一个实施例中,传输服务器1906向远程客户机1908A-B返回元数据1804-1810,不过在备选实施例中,传输服务器1906采用其它手段(例如,简单列表,包含该列表的公共网关接口(CGI)表格等等)返回可用视频流的列表。远程客户机1908A-B向传输服务器1906请求所需的视频流,传输服务器发送所请求的视频流。在一个备选实施例中,远程客户机1908A-B向传输服务器1906请求与所需的视频流对应的提取器轨道。响应收到提取器轨道,远程客户机1908A-B通过向传输服务器1906发送适当的命令,请求该视频流(例如,远程客户机1908A-B利用HTTP字节-请求等,向SVC基本轨道1600请求视频帧1602A-B)。下面在图23中进一步说明这种客户机-服务器实施例。
除了由本地客户机1904和远程客户机1908A-B使用之外,SVC基本轨道和提取器轨道可由AVC专用内容创建器1912处理。AVC专用内容创建器1912通过访问SVC提取器轨道,并使用提取器轨道汇编出自对应SVC基本轨道的AVC专用内容,创建AVC专用内容(例如,在特定操作点的H.264/AVC视频内容)。AVC专用内容创建器1912把AVC专用内容保存在存储器1914中。远程客户机1908A-B能够从存储器1914访问AVC专用内容(例如,在特定操作点的H.264/AVC视频内容)。
图20是根据SVC基本轨道产生SVC提取器轨道的方法2000的一个实施例的流程图。在方框2002,方法2000确定要产生的操作点的数目。如上所述,每个操作点根据与该操作点关联的视频属性描述一个视频流。尽管在一个实施例中,每个操作点是时间、空间和质量视频属性的唯一组合,不过备选实施例可具有包括更多、更少和/或不同视频属性(例如,位深度,色度二次抽取频率等)的操作点。例如,时间视频属性描述视频流帧频(例如8、15、30fps等等),空间视频属性描述视频流分辨率(例如,SQCIF、QCIF、CIF等等),质量视频属性描述视频流质量,通常用信噪比度量来描述。
在方框2004,至少对于操作点的一个子集,方法2000对与SVC基本轨道对应的提取器轨道编码。方法2000为该子集中的操作点创建一个提取器轨道。如上所述,提取器轨道包括NAL单元,NAL单元或者引用SVC基本轨道中的NAL单元,或者是基本轨道中的NAL单元的副本。在方框2006,方法2000保存提取器轨道。另外,通过重新布置视频文件300,方法2000可优化包含保存的提取器轨道的视频文件300中的一些。这特别适合于包含NAL的副本的提取器轨道。
图21是利用对应的提取器轨道,从SVC基本轨道取回视频流的方法2100的一个实施例的流程图。在方框2102,方法2100确定客户机能力。客户机能力取决于(但不限于)显示器尺寸、显示器图形处理能力、存储器、视频缓冲器、处理能力等等。例如,具有小型显示器和低能CPU的手持式设备能够处理15fps SQCIF视频流,而具有更好CPU和图形处理能力的桌上型计算机可以处理30fps CIF视频流。
在方框2104,方法2100通过询问媒体提取器轨道(或者其它数据),确定可用的媒体流,所述媒体提取器轨道(或者其它数据)指示哪个操作点与确定的客户机能力和可用的提取器轨道匹配。尽管在一个实施例中,方法2100询问可用的媒体提取器轨道以确定所述匹配,不过在备选实施例中,方法2100可借助不同的手段(例如询问媒体元数据1804-1810等)确定所述匹配。例如,如果目标设备是手持式设备,那么方法2100确定是否存在低分辨率低位速率的媒体流(例如15fpsSQCIF视频流)。
在方框216,方法2100选择与客户机能力匹配的适当提取器轨道。例如,如果客户机是桌上型计算机,那么方法2100优先于低分辨率或者fps的视频流选择30fps CIF视频流。在方框2108,方法2100访问与选择的媒体流关联的提取器轨道。
在方框2110,方法2100利用提取器轨道取回与提取器轨道关联的视频流。通过(i)如果提取器轨道把视频数据从基本轨道NAL单元复制到提取器NAL单元中,那么读取NAL单元中的数据;或者(ii)使用提取器轨道NAL单元作为对包含在SVC基本轨道中的视频流的数据的引用,方法2100使用提取器轨道取回视频流。这两种类型的提取器轨道都允许方法2100从SVC编码基本轨道取回视频流。引用提取器轨道NAL单元包含供方法2100确定:(i)SVC基本轨道中适当NAL单元的位置,(ii)离引用的NAL单元的偏移量,和(iii)将从引用的NAL单元复制的字节的数目的信息。
图22是传输服务器为远程客户机从SVC基本轨道取回媒体流的方法2200的一个实施例的流程图。在方框2202,方法2200接收媒体流请求。尽管在一个实施例中,媒体流请求可依据HTTP协议,不过备选实施例可使用本领域已知的不同协议(例如RTP、RTSP等等)。在方框2204,方法2200选择与请求的媒体流对应的提取轨道。例如,如果远程客户机请求30fps CIF视频流,那么方法2200选择与该媒体流对应的提取器轨道。
在方框2206,方法2200传送基于所选提取器轨道的媒体流。例如,方法2200如在方框2110所述利用提取器组装媒体流,并传送所得到的视频流。
图23是在远程客户机利用提取器轨道请求媒体流的情况下,传输服务器为远程客户机从SVC基本轨道取回媒体流的方法2300的一个实施例的流程图。方法2300和方法2200的不同在于描述视频流的详细信息由远程客户机处理,而不是由传输服务器处理。在图23中,远程客户机利用提取器轨道从SVC基本轨道提取视频流。在方框2302,方法2300从SVC基本轨道接收对可用视频流的请求。作为响应,方法2300在方框2304传送SVC基本轨道视频元数据。尽管在一个实施例中,方法2300传送如图18中图解说明的视频元数据1804-1810,不过备选实施例可传送描述在SVC基本轨道内编码的可用视频流的其它数据(例如,发送视频流的简单列表等等)。
在方框2306,方法2300接收对提取器轨道的请求。作为响应,在方框2308,方法2300把请求的提取器轨道传给发出请求的远程客户机。远程客户机将使用该提取器轨道提取视频帧(例如,从基本轨道提取NAL单元),如果提取器轨道包含引用NAL单元的话。否则,如果提取器轨道包含NAL单元的副本,那么远程客户机具有该视频流,并且能够根据需要处理该视频流。
在方框2310,方法2300根据传送的提取器轨道接收视频流帧请求。作为响应,在方框2312,方法2300传送请求的视频帧。
图24是保存从SVC基本轨道提取的SVC特有内容的方法2400的一个实施例的流程图。SVC特有内容与SVC基本轨道的不同在于SVC特有内容包含一个视频流,而SVC基本轨道可包含多个视频流。在方框2402,方法2400确定可用视频流中的哪个视频流应被保存为SVC特有内容。根据选择的视频流,方法2400确定与选择的视频流关联的提取器。在方框2406,方法2400利用关联的提取器轨道提取视频流。例如,方法2400如方框2110中那样提取视频流。在提取视频流之后,方法2400把该视频流保存为SVC特有内容。
下面提供的是提示的一些例子格式。但是,要认识到本发明可以和各种网络协议,数字处理系统体系结构,媒体格式一起用于提供时基数据的传输。
备选实施例
虽然用几个实施例和说明性附图说明了本发明,不过本领域的技术人员会认识到本发明并不局限于所描述的实施例或附图。特别地,可在提供时间相关媒体数据的分组的几个备选实施例中实践本发明。
于是,应明白在附加权利要求的精神和范围内,可通过修改和变更实践本发明的方法和设备。从而,上面的说明应被看作地本发明的例证说明,而不是对本发明的限制。
附录A-分组提示样本描述
在本发明的一个实施例中,每个提示轨道具有一个样本描述表。提示轨道一般具有一个样本描述。按照本发明的一个实施例,提示轨道的每个样本描述项的格式在下面的表1中描述。
表1:提示轨道样本描述格式
提示轨道样本描述 |
字节 |
样本描述大小 |
4 |
数据格式 |
4 |
保留 |
6 |
数据引用索引 |
2 |
最大分组大小 |
4 |
附加数据表 |
可变 |
分组提示首标基本单元包含下述数据元素:
字段描述:
样本描述大小 规定样本描述中的字节数的32-位整数。
数据格式 指示保存在样本数据内的提示的格式的32-位整数。可为不同的提示类型定义不同的格式。下表列出定义的格式。
保留 被设定为0的6个字节。
数据引用 包含与使用该样本描述的样本关联的数据索引的索引的16-位整数。数据引用被保存在数据引用基本单元中。
最大分组大小 指示该轨道内计算的分组的最大尺寸的32-位整数。
附加数据表 包含每个轨道所需的附加信息的表。该值为标记项。存在不需要的项。如果某一项不存在于该表内,则可使用适当的缺省值。
表2中示出附加数据表项的结构
表2:附加数据表格式
附加数据表 |
字节 |
项长度 |
4 |
数据类型 |
4 |
数据 |
项长度-8 |
附加数据表项包含下面的数据元素
字段描述:
项长度 用字节表示整个项的长度的32位整数(包括长度字段和类型字段的8个字节)。
数据类型 指示项内的数据的含义的32位整数。
数据 该项的数据。数据长度由表的数据长度字段指示。
可以为几种数据格式类似定义下述的数据标记。可酌情创建其他标记。
长度 类型 数据描述
9 ′rely′ 指示是否应通过可靠的传输发送该轨道的1字节整数。定义为0和1的值。如果该标记不存在,那么假定使值为0,表示该轨道可通过不可靠的传输,例如UDP发送。
定义下面的数据格式类型。可酌情定义新的类型。
数据格式 描述
‘rtp’ 用于通过特定媒体类型的RTP发送媒体,并如音频-视频传输(AVT)工作组的各种IETF草案所述那样编码的分组提示。
在关于‘rtp’数据的一个实施例使用下面的数据标记
长度 类型 数据描述
12 ‘tims’ 指示RTP时标的32位数字。该标记出现在关于RTP数据的一个实施例中。
对于‘rtP’数据,下面的数据标记是可选的。
长度 类型 数据描述
12 ‘tsro’ 指示当发送RTP分组时,增加到保存的时间戳记中的随机偏移量的32位数。如果该字段不存在,那么按照RTP规定,应使用真正的随机数。该字段的值可以为零,以指示不增加任何随机偏移量。
10 ‘snro’ 指示当发送RTP分组时,增加到序列号中的随机偏移量的16位数。如果该字段不存在,那么按照RTP规定,应使用真正的随机数。该字段的值可以为零,以指示不增加任何随机偏移量。
附录B-关于RTP的例证提示轨道
本节提供一个用于流式传输来自QulckTime电影的RTP的提示轨道格式的例子。
在标准RTP中,每个媒体流一般作为一个独立RTP流被发送。一般通过使用IP的端口层多路复用,而不是通过将来自多个流的数据交织成单一的RTP会话来实现多路复用。于是,电影中的每个媒体轨道应具有相关的RTP提示轨道。在本发明的一个实施例中,每个提示轨道包括一个回到正在流式传输的媒体轨道的轨道引用。
在该例子中,在创建提示轨道的时候,确定分组大小。于是,在关于提示轨道的样本描述中(可包含特定于‘编码’-这种情况下,所述‘编码’是协议-的字段的数据结构),指示选择的分组大小。在本发明的一个例子中,为每个媒体轨道提供几个RTP提示轨道,以提供不同的分组大小选择。其它协议也可被参数化。类似地,在下面的样本描述中提供用于RTP时钟的适当时标。
通过单一的轨道引用说明使提示轨道与其基本媒体轨道联系起来。(RTP不允许单一RTP流内的媒体的多路复用)。关于RTP的样本描述说明该提示轨道将产生的最大分组大小。会话描述(SAP/SDP)信息被保存在轨道中的用户-数据基本单元中。
RTP提示轨道中的每个样本包含发出必须在指定时间发出的一组分组的指令。提示轨道中的时间是发射时间,不一定是相关媒体的媒体时间。
在下面的描述中,样本的内部结构不一定被构成为对象,在本例的内的术语学中,所述样本是媒体数据,而不是元数据。
在该例子中,每个样本包含两个区域:组成分组的指令,和当发送这些分组时所需的任何额外数据(例如,加密形式的媒体数据)。
struct RTPsample {
int(16) packetcount;
RTPpacket packets[packetcount];
byte[] extradata;
}
每个RTP提示分组包含发送单一分组的信息。在一个实施例中,为了使媒体时间与发射时间分开,连同形成RTP首标所需的数据一起,专门包括一个RTP时间标记。不过,在备选实施例中,情况并不是这样。一般提供其他首标信息。如下构成结构项的表:
struct RTPpacket {
int(32) RTPtime;
int(16) partialRTPheader;
int(16) RTPsequenceseed;
int(16) entrycount;
dataentry constructors[entrycount];
}
存在各种形式的构造器。每个构造器为16字节,这使得迭代相对简单。第一字节是一个联合鉴别器。
struct dataentry {
int(8) entrytype;
switch entrytype {
case immediate:
int(8) bytecount;
int(8) bytestocopy[bytecount];
case mediasample:
int(8) reserved[5];
int(16) length;
int(32) mediasamplenumber;
int(32) mediasampleoffset;
case hintsample:
int(8) reserved[5];
int(16) length;
int(32) hintsamplenumber;
int(32) hintsampleoffset;
}
}
即时模式允许有效负荷特有首标(例如,RTP H.261首标)的插入。对于其中‘畅行无阻地’发送媒体的提示轨道,通过给出样本号,数据偏移量和要复制的长度,媒体样本项可规定要从媒体轨道复制的字节。对于相对复杂的情况(例如,加密或前向纠错),可以将转换数据置于提示样本中,随后使用提示样本模式,可从RTP样本自身的额外数据字段提供该模式。
在本发明的一个例子中,不需要连续分组发送来自媒体流的连续字节。例如,为了符合H.261的RTP标准封装,在本发明的一个例子中,可在一个分组的结尾发送字节,也可在下一个分组的开始(当宏模块边界落入一个字节内时)发送字节。
附录C-用于数据格式‘rtp’的分组化提示样本数据
按照本发明的一个实施例,本附录提供用于‘rtP’格式的样本数据的描述。‘rtP’格式假定服务器正在使用实时传输协议(RTP)发送数据。该格式假定服务器了解RTP首标,但是不要求服务器知道和特定媒体首标有关的一切信息,包括在各种IETF草案定义的媒体首标。
在本发明的一个实施例中,提示轨道中的每个样本将产生一个或多个RTP分组。提示轨道样本中的样本数据表内的每项对应于单一的RTP分组。提示轨道中的样本可以或者也可不准确对应于媒体轨道内的样本。在本发明的一个实施例中,提示轨道样本中的数据是按字节对准的,但不是32位对准的。
字段描述
项计数 表示表中的分组项数的16位无符号整数。表中的每一项对应于一个分组。单一样本中的多个项指示媒体样本必须分为多个分组。项计数为零的样本被保留,如果遇到该样本,则应跳过该样本。
分组项表 包含分组项的变长表。下面定义分组项。
附加数据 包含下面由表3所示的数据表中的项所指向的数据的变长字段:
表3-附加数据
分组项 |
字节 |
相对分组传输时间 |
4 |
标记 |
4 |
RTP首标信息 |
2 |
RTP序列号 |
2 |
项计数 |
2 |
数据表 |
可变 |
在一个实施例中,分组项包含下面的数据元素:
字段描述:
相对分组 一个32位的有符号整数值,以提示轨道时标表示相对于提传输时间 示样本的实际时间,发送该分组的时间。负值表示该分
组将早于实际时间被发送,这有益平滑数据率。正值有益于稍后重复分组。在每个提示样本轨道中,每个分组时间标记是不减少的。
标记 指示该分组的某些属性的32位字段。
RTP首标信息字段包含下面的元素:
字段 位# 描述
R 31 指示这是一个重复分组-在前面的分组已定义了该数据的1位数字。当服务器落后于其分组的传输时,服务器可以选择跳过重复分组来帮助追上分组传输。指定分组的所有重复分组关注相同的提示样本。
保留所有未被定义的位(0-30)并将其设为零。
RTP 首标信息 规定将在RTP首标内设置的各种值的16位整数。
RTP 首标信息字段包含下面的元素:
字段 位# 描述
P 2 对应于RTP首标内的填充(P)位的1位数字。该位可以不被设定,因为需要不同分组填充的服务器一般需要不填充和重复填充分组本身。
X 3 对应于RTP首标内的扩展(X)位的1位数字
该位可以不被设定,因为需要发送它自己的RTP扩展的服务器可能不能,或者被迫替换来自提示轨道的任何扩展。
M 8 对应于RTP首标内的标记(M)位的1位数字。
有效负荷类型 9-15 对应于RTP首标的有效负荷类型(PT)字段的7-位数字。
保留所有未定义的位(0-1和4-7)并将其设为零。定义的位的位置与与RTP首标内的位位置相同。
RTP 序列号 规定分组的RTP序列号的16位整数。在发送分组之前,RTP服务器将一个随机偏移量增加到该序列号中。该字段允许分组的重复发送,例如,可以用相同的序列号和不同(后面)的分组传输时间汇编相同的分组。例如,可以每10秒重复发送持续5分钟的文本样本,以致错过初始样本发送的客户机(或许他们从中间开始播放电影)最多在10秒之后将被“刷新”。
项计数 规定数据表内的项数的16-位无符号整数。
数据表 定义将被放入RTP分组的有效负荷部分的数据的表。该表定义可以取回数据的各个位置,如表4所示。
表4-数据表
该项表的数据源字段指示将如何解释该项的其他15个字节。定义值0到4。下面定义各种数据表格式。尽管存在各种方案,不过各个方案中的项一般为16字节长。
No-Op数据模式
数据表项具有用于No-Op模式的下述格式:
字段描述
数据源=0 零值指示该数据表项将被忽略。
即时数据模式
数据表项具有用于即时模式的下述格式:
字段描述:
数据源=1 值1表示将立即从跟随的数据的字节中取出数据。
即时长度 表示将从跟随的数据中取出的字节数的8位整数。合法的值从0到14变化。
即时数据 将置于分组的有效负荷部分中的14字节数据。仅使使用由即时长度字段表示的第一字节数。
样本模式
该数据表项具有用于样本模式的下述格式:
字段描述:
数据源=2 值2表示将从轨道的样本数据取出数据。
道引用索引 指示样本数据来自于哪个轨道的值。0值表示正好存在一个要使用的引用媒体轨道。值1~127是提示轨道引用基本单元项的索引,指示将从哪个初始媒体轨道读取该样本。值-1表示提示轨道本身,即,使用来自与当前正被解析的提示样本相同的轨道的样本。
字节/压缩块 规定从压缩样本/压缩块字段中的样本数产生的字节数的16位无符号整数。值0等同于值1。
样本/压缩块 规定未压缩样本/压缩块的16-位无符号整数。值0等同相当于值1
长度 规定要复制的样本中的字节数的16-位整数。
样本号 规定该轨道的样本号的32-位整数。
偏移量 规定到从其开始复制的样本的起点的偏移量的32位整数。如果引用提示轨道内的样本,那么一般将指向附加数据区。
如果字节/压缩块和/或样本/压缩块大于1,那么使用该比值将样本号转换成实际的字节偏移量。这种比值模式一般用于QulckTime电影内的压缩音频轨道,以致:
CB=NS*BPCB/SPCB
其中,
CB=压缩字节
NS=样本数
BPCB=字节/压缩块
SPCB=样本/压缩块
例如,一个GSM压缩块一般是封装到33个字节中的160个样本。于是,BPCB=33,SPCB=160。提示样本请求在第161个媒体样本开始的33字节数据。假定第一个QuickTime组块包含至少320个样本,这样在确定该数据将来自于组块1,并且组块1始于何处之后,使用该比值把偏移量调整到找到所请求样本的文件中:
Chunk_number=l;/*通过遍历样本-组块基本单元进行计算*/
First_sample_in_his_chunk=1;/*也计算自该基本单元*/Chunk_offset=chunk_offsets[chunk_number];/*来自stco基本单元*/
Data_offset=(sample_number-first_sample_in_this_chunk)*BPP/SPP
Read_from_file(chunk_offset+data_offset,Length);/*读出数据*/
样本描述模式
该数据表项具有用于样本描述模式的下述格式:
字段描述:
数据源=3 值3指示数据将取自媒体轨道的样本描述表。
轨道引用索引 该值指示样本数据将出自的轨道。值0表示正好存在将使用的一个提示轨道引用。从1到127的值是提示轨道引用基本单元项的索引,指示将从哪个初始媒体轨道读取该样本。值-1表示提示轨道本身,即,使用来自与当前正被解析的提示样本相同的轨道的样本。
保留 设为零的四个字节。
长度 规定要复制的样本内的字节数的16位整数。
样本描述索引 规定到媒体样本描述表的索引的32位整数。
偏移量 规定到从其开始复制的样本的起点的偏移量的32位整数。
附加数据 包含数据表中的提示轨道样本模式项所指向的数据的变长字段。
附录D-用于MPEG-2传输的提示轨道格式实例
本节给出一个用于从QulckTime电影保持基本数据流流式传输MPEG-2传输的简单轨道格式的例子。
MPEG-2传输流与一个或多个基本流的多路复用有关。由于这个原因,MPEG-2传输提示轨道描述如何由一个或更多的媒体轨道构成这样的多路复用。在媒体轨道和MPEG-2传输提示轨道之间不一定存在一对一的关系。每个提示轨道包含对它所表示的基本流的引用。在本发明的一个例子中,QulckTime文件可以包含多个这样的提示轨道以描述不同的多路复用。
分组大小一般不是问题,因为所有的MPEG-2传输分组的大小为188字节。在本发明的一个例子中,每个传输分组(按照MPEG-2传输协议)包含来自一个媒体轨道的有效负荷数据。这便于每个传输分组的相对简单的提示描述。在本发明的一个例子中,每个这样的提示描述哪个首标数据出现在每个传输分组,从而指向传输分组的适当媒体轨道中的有效负荷。对于不对应媒体轨道的分组,例如PSI分组,提示可描述188字节的首标数据,并且任何媒体轨道引用可被认为是不相关的。对于对应于媒体轨道的分组,该首标数据说明诸如传输首标,可能的适应首标,以及开始PES分组的传输分组的PES首标之类的信息。
产生对(stsd’类型的)样本描述基本单元中的MPEG-2传输提示轨道的引用。该基本单元包括一个样本描述表,该表中的项目根据媒体类型而不同。在本发明的一个例子中,提示轨道始于表1中所示的结构。附加数据表可以借助表2中所示的结构保持各个项目。
在本发明的一个例子中,如果提示轨道是MPEG-2传输提示轨道,那么提示轨道样本描述项中的数据格式将是‘m2t’,并且最大分组大小将始终是188。在这样的描述项中,在附加数据表中可以找到下面在表5-7中示出的类型:
表5-附加数据表项
项长度 |
数据类型 |
数据描述 |
8 |
0X0000 0000 |
指示表内不存在更多的项 |
9 |
‘otyp’ |
描述在提示内如何描述偏移量。数据的一个字节具有下面在图B.4中描述的值。该项在附加数据表内是强制性的。 |
9 |
‘msns’ |
描述媒体样本号的大小。数据的一个字节表示使用多少个字节来规定媒体样本号。如果该项不存在,并且媒体样本号存在于样本数据中,那么缺省值为4字节 |
9 |
‘msos’ |
描述媒体样本偏移量的大小。数据的一个字节表示多少个字节被用于规定媒体样本偏移量。如果该项不存在,并且在样本数据中存在媒体样本偏移量,那么缺省值为4字节 |
9 |
‘fosz’ |
描述文件偏移量的大小。数据的一个字节表示多少个字节被用于规定样本内的文件偏移量。如果该项不存在,并且在样本数据中存在文件偏移量,那么缺省值为4字节 |
可变 |
‘tmap’ |
描述媒体轨道的缩写映象。每个5字节项目将4字节轨道ID映象到1字节轨道引用号。这限制任何指定的传输mux包含不大于256个媒体轨道,但是这不应是一个限制因素,并且压缩有助于限制提示轨道的大小。下面在图B.5中规定这些5字节项目的格式。该项在附加数据表中是强制性的。 |
表6-附加数据表中的‘otyP’值
值 |
描述 |
0 |
按照媒体样本描述样本 |
1 |
按照文件偏移量描述样本 |
表7-‘tmap’附加数据中的各项的格式
长度 |
描述 |
4 |
初始轨道ID |
1 |
样本中使用的缩写轨道引用号 |
在本发明的一个例子中,每个提示样本描述一个传输分组。每个传输分组可被描述成一定量的首标数据,后面是出自一个媒体轨道的一定量的有效负荷。由于MPEG-2传输分组相对较小,可以产生大量的提示样本,从而,这些样本最好应尽可能地小。上面的附加数据表内的几个项目可被用于使样本大小最小化,不过这样的因素会使样本项内的一些字段的大小可变。
如果数据表中的‘otyp’项的值为0,表示按照媒体样本描述有效负荷数据,那么提示样本可以是表8中所示的下述形式:
表8-使用媒体样本引用的提示样本格式
长度 |
描述 |
1 |
保持分组的有效负荷数据的媒体轨道的轨道引用号。利用附加数据表中的‘tmap’项,轨道引用号可被映象成轨道ID。如果该提示指定188字节的即时数据,那么该字段是不相关的。 |
1 |
分组的即时数据的长度。注意这必须为188或更小,因为传输分组的长度为188字节。 |
可变 |
用作传输分组的首标的即时数据的字节。字节数由前一字段描述。 |
可变 |
用于有效负荷数据的媒体样本数。该字段的缺省大小是4个字节,不过附加数据表中‘mans’项的存在可修改该缺省大小。 |
可变 |
用于有效负荷数据的媒体样本偏移量。该字段的缺省大小是4个字节,不过附加数据表中‘msos’项的存在可修改该缺省大小。 |
在本发明的一个例子中,不必指示分组的有效负荷数据的长度,因为在MPEG-2中,该长度等于188减去分组的首标数据的大小。
如果数据表中的‘otyp’项的值为1,指示按照文件偏移量描述有效负荷数据,那么提示样本可以是表9中所示的下述形式:
表9
长度 |
描述 |
1 |
保持分组的有效负荷数据的媒体轨道的轨道引用号。利用附加数据表中的‘tmap’项,这可被映象成轨道ID。如果该提示指定188字节的即时数据,那么该字段是不相关的。 |
1 |
分组的即时数据的长度。注意它必须为188或更小,因为传输分组长度为188字节。 |
可变 |
用作传输分组的首标的即时数据的字节。该字节数由前一字段描述。 |
可变 |
有效负荷数据所位于的文件偏移量。该偏移量位于媒体轨道的数据所处的文件中。该字段的缺省大小是4个字节,不过附加数据表中‘fosz’项的存在可以修改该缺省大小。 |
在本发明的一个例子中,提示样本可以按照媒体样本或按照文件偏移量描述其偏移量。两种方法都有优点和缺点。如果提示样本按照媒体样本指定有效负荷,那么它更适应包含媒体轨道的文件的附加编辑,但是需要另外的传送处理。如果提示样本按照文件偏移量指定有效负荷,那么可以相对较快地访问有效负荷数据,但是包含媒体轨道的文件的任何编辑将使该提示无效。
附录E-示例文件
下面按照本发明的一个实施例,提供一个相对较短(6帧)的样本文件,一些不太重要的字段和对象被省去(这里用省略号“…”标记),一些假想数字用于举例说明准备通过RTP流式传输的文件的整体结构。媒体数据已被省去;只示出元数据。
moov--the entire movie meta-data
mvhd--overall movie information
…
TIME-SCALE 600
DURATION 2792
PREFERRED-RATE 1
VOLUME 255
MATRIX [[1 0 0][0 1 0][0 0 1]]
…
NEXT-TRACK-ID 5--tracks 1 to 4 are here
trak--this is the video track
tkhd
…
TRACK-ID 1
DURATION 2792
LAYER 0
…
MATRIX [[1 0 0][0 1 0][0 0 1]]
WIDTH 176
HEIGHT 144
mdia
mdhd
…
TIME-SCALE 600
DURATION 2722
…
hdlr--we use the basic video media handler
…
TYPE mhlr
SUBTYPE vide
MANUFACT appl
…
NAME Apple Video Media Handler
minf
vmhd
…
hdlr--basic ′alias′disk data handler gets the data
…
TYPE dhlr
SUBTYPE alis
MANUFACT appl
…
NAME Apple Alias Data Handler
dinf
dref
…
ENTRY-COUNT 1
REFS [Pointer to this file]
stbl--the complete sample table
stsd--the sample description(s)
…
ENTRY-COUNT 1
DESCRIPTIONS [video sample description]
stts--convert time to sample
…
ENTRY-COUNT 6
TIMETOSAMPLE ((1 200)--count,duration
(1 251)
(1 479)
(1 531)
(1 1022)
(1 239))
stss--′sync′or key sample numbers
…
ENTRY-COUNT 1
SYNCSAMPLES (1)
stsc--sample to chunk
…
ENTRY-COUNT 1
SAMPLETOCHUNK ((1 1 1))
--1st chunk,samples/chunk,desc.number
stsz--sample sizes
…
DEFSAMPLESIZE 0--no default size,all different
ENTRY-COUNT 6
SAMPLESIZES (664
616
1176
1304
2508
588)
stco--chunk offsets into file
…
ENTRY-COUNT 6
CHUNKOFFSETS (4743
5407
8010
12592
17302
25268)
trak--this is the sound track
tkhd
…
TRACK-ID 2
DURATION 2792
…
VOLUME 1
…
mdia
mdhd
…
TIME-SCALE 8000
DURATION 37280
LANGUAGE US English
…
hdlr --handled by the basic sound handler
…
TYPE mhlr
SUBTYPE soun
MANUFACT appl
…
NAME Apple Sound Media Handler
minf
smhd
…
BALANCE 0
hdlr--data fetched by usual disc data handler
…
TYPE dhlr
SUBTYPE alis
MANUFACT appl
…
NAME Apple Alias Data Handler
dinf
dref
…
ENTRY-COUNT 1
REFS [Pointer to this file]
stbl--sample table for the sound
stsd--sample descriptions
…
ENTRY-COUNT 1
DESCRIPTIONS [Sound sample description,ind
GSM]
stts--time to sample table
…--sound is measured by uncompressed samples
ENTRY-COUNT 1
TIMETOSAMPLE ((37280 1))
stsc
…
ENTRY-COUNT 2
SAMPLETOCHUNK ((1 4000 1)
(10 1280 1))
--first chunk,samples/chunk,desc.number
stsz
…
DEFSAMPLESIZE 1--all samples same size
ENTRY-COUNT 37280
stco--chunk offset table
…
ENTRY-COUNT 10
CHUNKOFFSETS (3093
3918
6023
9186
10915
13896…)
trak--the RTP hints for the video track
tkhd
…
TRACK-ID 3
DURATION 2792
…
tref
hint--references the video track
TRACKIDS (1)
mdia
mdhd
…
TIME-SCALE 600
DURATION 2792
…
hdlr--is′played′by the hint media handler
…
TYPE mhlr
SUBTYPE hint
MANUFACT appl
…
NAME hint media handler
minf
gmhd
…
hdlr--if played,the regular disc handler would fetch
data
…
TYPE dhlr
SUBTYPE alis
MANUFACT appl
…
NAME Apple Alias Data Handler
dinf
dref
…
ENTRY-COUNT 1
REFS [Pointer to this file]
stbl--samples describe packets
stsd
…
ENTRY-COUNT 1
DESCRIPTIONS [hint sample description]
stts--one packet per frame for video
…
ENTRY-COUNT 6
TIMETOSAMPLE ((1 270)
(1 251)
(1 479)
(1 531)
(1 1022)
(1 239))
stss--key sample derive from video
…
ENTRY-COUNT 1
SYNCSAMPLES (1)
stsc--sample to chunk table
…
ENTRY-COUNT 1
SAMPLETOCHUNK ((1 1 1))
stsz--sample sizes (packet instructions)
…
DEFSAMPLESIZE 0
ENTRY-COUNT 6
SAMPLESIZES (52
52
52
52
102
52)
stco--chunk offsets
…
ENTRY-COUNT 6
CHUNKOFFSETS (6848
6900
10011
14721
20635
25856)
udta--track is named for ease of idientification
name
NAME Hinted Video Track
trak--the RTP hints for the sound track
tkhd
…
TRACK-ID 4
…
tref--references the sound track
hint
TRACKIDS (2)
mdia
mdhd
…
TIME-SCALE 8000
DURATION 37120
…
hdlr
…
TYPE mhlr
SUBTYPE hint
MANUFACT appl
…
NAME hint media handler
minf
gmhd
…
hdlr
…
TYPE dhlr
SUBTYPE alis
MANUFACT appl
…
NAME Apple Alias Data Handler
dinf
dref
…
ENTRY-COUNT 1
REFS [Pointer to this file]
stbl
stsd
…
ENTRY-COUNT 1
DESCRIPTIONS [hint sample description]
stts--time to sample
…
ENTRY-COUNT 4
TIMETOSAMPLE ((1 960)
(7 4000)
(1 1120)
(1 7040))
stsc
…
ENTRY-COUNT 1
SAMPLETOCHUNK ((1 1 1))
stsz
…
DEFSAMPLESIZE 0
ENTRY-COUNT 10
SAMPLESIZES (206
852
852
852
852
852…)
stco
…
ENTRY-COUNT 10
CHUNKOFFSETS (6952
7158
10063
11740
14773
16450…)
udta
NAME Hinted Sound Track