媒体封装和解封装
文献发布时间：2023-06-19 09:54:18
本申请是2016年2月16日提交的申请号为201680084597.X、发明名称为“媒体封装和解封装”的专利申请的分案申请。
技术领域
本发明一般涉及媒体文件格式的使用。更具体地，本发明涉及一种用于将媒体数据信号封装到文件中的方法和一种用于从文件解封装媒体数据的方法。本发明还涉及一种用于将媒体数据封装到文件中的装置和计算机程序产品，以及一种用于从文件解封装媒体数据的装置和计算机程序产品。
背景技术
该部分旨在提供权利要求中所述的本发明的背景或上下文。本文的描述可以包括可以追求的概念，但不一定是先前已经构思或追求的概念。因此，除非本文另有说明，否则本部分中描述的内容不是本申请中的说明书和权利要求的现有技术，并且不因包含在本部分中而被认为是现有技术。
媒体容器文件格式是媒体内容制作、操作、传输和消费链中的一个元素。在这种情况下，编码格式(即基本流格式)涉及将内容信息编码成比特流的特定编码算法的动作。容器文件格式包括用于组织所生成的比特流使得它可以被访问以用于本地解码和回放、作为文件传送或者流传输的机制，所有这些都利用各种存储和传输架构。容器文件格式还可以促进媒体的互换和编辑，以及将接收的实时流记录到文件中。因此，编码格式和容器文件格式之间可能存在实质性差异。
发明内容
各种实施例提供了用于媒体封装和解封装的系统和方法。
在详细描述中提供了本发明的示例的各个方面。
根据第一方面，提供了一种方法，包括：
接收包括媒体数据结构中的至少一个元数据单元的容器文件；
接收偏移数据；
确定所述偏移数据相对于所述容器文件中所述媒体数据结构的位置；以及
使用所述偏移数据作为对所述媒体数据结构的位置的引用以获得所述媒体数据单元。
根据第二方面，提供了一种装置，包括至少一个处理器和至少一个存储器，所述至少一个存储器在其上存储有代码，所述代码当由所述至少一个处理器执行时，使得装置执行至少以下内容：
接收包括媒体数据结构中的至少一个元数据单元的容器文件；
接收偏移数据；
确定所述偏移数据是相对于所述容器文件中所述媒体数据结构的位置；以及
使用所述偏移数据作为对所述媒体数据结构的位置的引用以获得所述媒体数据单元。
根据第三方面，提供了一种在非暂时性计算机可读介质上实现的计算机程序产品，包括计算机程序代码，所述计算机程序代码被配置为当在至少一个处理器上执行时使得装置或系统：
接收包括媒体数据结构中的至少一个元数据单元的容器文件；
接收偏移数据；
确定所述偏移数据相对于容器文件中所述媒体数据结构的位置；以及
使用所述偏移数据作为对所述媒体数据结构的位置的引用以获得所述媒体数据单元。
根据第四方面，提供了一种方法，包括：
形成包括媒体数据结构中的至少一个元数据单元的容器文件；
将偏移数据形成到所述容器文件中，作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用；以及
包括所述偏移数据相对于所述媒体数据结构的位置的指示。
根据第五方面，提供了一种装置，包括至少一个处理器和至少一个存储器，所述至少一个存储器上存储有代码，所述代码当由所述至少一个处理器执行时使得装置执行至少以下内容：
形成包括媒体数据结构中的至少一个元数据单元的容器文件；
将偏移数据形成到所述容器文件中，作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用；以及
包括所述偏移数据相对于所述媒体数据结构的位置的指示。
根据第六方面，提供了一种在非暂时性计算机可读介质上实现的计算机程序产品，包括计算机程序代码，所述计算机程序代码被配置为当在至少一个处理器上执行时使得装置或系统：
形成包括媒体数据结构中的至少一个元数据单元的容器文件；
将偏移数据形成到所述容器文件中，作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用；以及
包括所述偏移数据相对于所述媒体数据结构的位置的指示。
根据第七方面，提供了一种被配置为执行第一方面的方法的装置。
根据第八方面，提供了一种被配置为执行第四方面的方法的装置。
根据第九方面，提供了一种装置，包括：
用于接收包括媒体数据结构中的至少一个元数据单元的容器文件的装置；
用于接收偏移数据的装置；
用于确定所述偏移数据相对于所述容器文件中的所述媒体数据结构的位置的装置；以及
用于使用所述偏移数据作为对所述媒体数据结构的位置的引用以获得所述媒体数据单元的装置。
根据第十方面，提供了一种装置，包括：
用于形成包括媒体数据结构中的至少一个元数据单元的容器文件的装置；
用于将偏移数据形成到所述容器文件中作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用的装置；以及
用于包括所述偏移数据相对于所述媒体数据结构的位置的指示的装置。
根据第十一示例，提供了一种方法，包括：
利用第一请求来请求文件的一部分，所述第一请求包括数据结构的标识，该标识包括类型和标识符，其中该标识符标识相同类型的若干数据结构中的数据结构。
根据第十二示例，提供了一种方法，包括：
接收请求文件的一部分的第一请求，第一请求包括数据结构的标识，该标识包括类型和标识符，其中该标识符标识相同类型的若干数据结构中的数据结构；
总结所述文件的一部分，所述总结包括基于所述类型和所述标识符的数据结构的标识；
通过传输所述文件的一部分来响应第一请求。
附图说明
已经概括地描述了本发明的一些实施例，现在将参考附图，附图不一定按比例绘制，并且其中：
图1示出了国际标准化组织(ISO)基础媒体文件格式盒子结构的示例包含层次结构；
图2示出了根据ISO基础媒体文件格式的简化文件结构；
图3a描绘了适合于构成媒体文件的装置的示例；
图3b描绘了适合于分解容器文件的装置的示例；
图4a描绘了根据实施例的用于构成媒体文件的方法的流程图；
图4b描绘了根据实施例的用于分解媒体文件的方法的流程图；
图5描绘了HTTP流传输系统中包括的一些功能块、格式和接口的示例图示；
图6a示出了作为HTTP流传输服务器操作的常规web服务器的示例；
图6b示出了与动态流传输服务器连接的常规web服务器的示例；
图7示意性地示出了采用本发明的一些实施例的电子设备；
图8示意性地示出了适用于采用本发明的一些实施例的用户设备；
图9还示意性地示出了使用无线和/或有线网络连接所连接的采用本发明实施例的电子设备；以及
图10是可以在其中实现各种实施例的通用媒体通信系统的示例的图形表示。
具体实施方式
现在将在下文中参考附图更全面地描述本发明的一些实施例，附图中示出了本发明的一些但非全部实施例。实际上，本发明的各种实施例可以以许多不同的形式实施，并且不应该被解释为限于本文阐述的实施例；相反，提供这些实施例是为了使本公开满足适用的法律要求。相同的附图标记始终表示相同的元件。如本文所使用的，术语“数据”、“内容”、“信息”和类似术语可以互换使用，以指代能够根据本发明的一些实施例发送、接收和/或存储的数据。因此，不应该使用任何这样的术语来限制本发明的实施例的精神和范围。
另外，如本文所使用的，术语“电路”指的是(a)仅硬件电路实现(例如模拟电路和/或数字电路中的实现)；(b)电路和计算机程序产品的组合，计算机程序产品包括存储在一个或多个计算机可读存储器上一起工作以使装置执行本文所述的一个或多个功能的软件和/或固件指令；以及(c)电路，例如微处理器或微处理器的一部分，其即需要软件或固件进行操作，即使该软件或固件实际上不存在。“电路”的这种定义适用于本术语在此(包括在任何权利要求中)的所有用途。作为另一示例，如本文所使用的，术语“电路”还包括这样的实现，该实现包括一个或多个处理器和/或其一部分以及附带的软件和/或固件。作为另一示例，本文使用的术语“电路”还包括例如用于移动电话的基带集成电路或应用处理器集成电路，或服务器、蜂窝网络设备、其他网络设备、和/或其他计算设备中的类似集成电路。
如本文所定义的，指代非暂时性物理存储介质(例如易失性或非易失性存储器设备)的“计算机可读存储介质”可以与指代电磁信号的“计算机可读传输介质”区分开。
本说明书中使用的一些进一步的定义可以描述如下。编码格式(其也可以称为媒体压缩格式)可以涉及将内容信息编码为比特流的特定编码算法的动作。媒体数据可以被定义为形成多媒体的编码表示的比特序列，所述多媒体的编码表示例如图片的编码表示、图像或多个图像的编码表示、音频或语音的编码表示，图形的编码表示。多媒体的编码表示通常符合编码格式，例如H.264/AVC、H.265/HEVC、AMR等。容器文件格式可以包括用于组织所生成的比特流使得它可以被访问以用于本地解码和回放、作为文件传送或者流传输的工具，所有这些都可能利用各种存储和传输架构。容器文件格式可以促进媒体的互换和编辑，以及将接收的实时流记录到文件中。元数据可以被理解为包括关于媒体数据的结构上的或描述性的信息。
当使用容器文件格式存储媒体数据时，至少部分元数据可以由容器文件格式的文件格式结构来表示。然而，元数据的一部分可以使用与容器文件格式不同的元数据格式来表示。例如元数据格式和容器文件格式可以以不同的规范指定和/或它们可以使用不同的基本单元或元素。例如容器文件格式可以基于包括密钥-长度-值三元组的元素，其中密钥指示信息的类型，长度指示信息的大小，值包括信息本身。ISO基础媒体文件格式中使用的盒子结构(box structure)可以被视为包括密钥-长度-值三元组的容器文件元素的示例。继续相同的示例，元数据格式可以基于XML(可扩展标记语言)模式。
某些媒体文件格式标准包括ISO基础媒体文件格式(ISO/IEC14496-12，可缩写为ISOBMFF)、MPEG-4文件格式(ISO/IEC 14496-14，也称为MP4格式)、ISO/IEC 14496-15(“ISO基础媒体文件格式中的网络抽象层(NAL)单元结构化视频载体(Carriage of networkabstraction layer(NAL)unit structured video in the ISO base media fileformat)”，可用于H.264/AVC和/或H.265/HEVC)、高效率图像文件格式(ISO/IEC23008-12，可以缩写为HEIF)和3GPP(第三代合作伙伴计划)文件格式(3GPP TS 26.244，也称为3GP格式)。用于H.264/AVC的可伸缩视频编码(SVC)和多视图视频编码(MVC)扩展的文件格式以及H.265/HEVC的多层扩展(MV-HEVC、SHVC、3D-HEVC)被指定为ISO/IEC 14496-15的一部分。ISO文件格式是衍生所有上述文件格式的基础，不包括ISO文件格式本身。
下面将ISOBMFF的一些概念、结构和规范描述为容器文件格式的示例，基于该容器文件格式可以实现实施例。本发明的各方面不限于ISOBMFF，而是针对一个可能的基础给出描述，在该基础之上可以部分或完全实现本发明。
ISO基础媒体文件格式中的一个构建块称为盒子。例如MovieBox或MovieFragmentBox涉及的编码样本数据可能总是驻留在MediaDataBox中。每个盒子可以具有头部和有效载荷。盒子头部以字节形式指示盒子的类型和盒子的大小。可以将所有媒体数据及其相关元数据封装到盒子中。盒子可以装入其他盒子，ISO文件格式规定在特定类型的盒子内允许哪些盒子类型。此外，在每个文件中可能必须存在一些盒子，而其他盒子的存在可以是可选的。此外，对于某些盒子类型，可能允许在文件中存在多个盒子。因此，可以考虑ISO基础媒体文件格式来指定盒子的分层结构。ISO基础媒体文件的每个盒子可以由四字符代码(4CC)标识。四字符代码可以互换地由32比特无符号整数表示(假设字符到8比特值的某种转换、某种比特字节顺序和某种字节字节顺序)。头部可以提供有关盒子类型和大小的信息。ISOBMFF盒子结构的示例包含层次结构如图1所示。
ISOBMFF的设计考虑了各种用例；这些用例可以包括(a)内容创建(b)互换(c)通信和(d)本地和流式表示。HTTP上的动态适应流传输(DASH)是使用ISOBMFF实现其目标的通信格式的示例。虽然DASH最初是指通过HTTP(超文本传输协议)传输的格式，但它也在基于3GPP的协议中使用，例如基于MBMS(多媒体广播/多播服务)和DVB(数字视频广播)的IP(因特网协议)广播。虽然这些传输协议中的一些是双向的，但是也有一些是单向的。此外，这些传输协议中的一些在易损环境中操作。
根据ISOBMFF，文件可以包括可以包含在单独的盒子中的媒体数据和元数据。可以在媒体数据(mdat)盒子中提供媒体数据，并且电影(moov)盒子可被用来包含元数据。在某些情况下，要使文件可操作，必须同时存在mdat和moov盒子。电影(moov)盒子可以包括一个或多个轨道，并且每个轨道可以驻留在一个对应的轨道盒子中。轨道可以是例如以下类型之一：媒体、提示、定时元数据。媒体轨道是指根据媒体压缩格式(及其对ISO基础媒体文件格式的封装)格式化的样本(也可以称为媒体样本)。提示轨道指的是提示样本，其包含用于构造分组以用于在指示的通信协议上传输的菜谱指令(cookbook instruction)。菜谱指令可以包括用于分组报头构造的指导，并且可以包括分组有效载荷构造。在分组有效载荷构造中，可以引用驻留在其他轨道或项目中的数据。这样，例如驻留在其他轨道或项目中的数据可以通过引用来指示，所述引用关于特定轨道或项目中的哪条数据被命令要在分组构建过程期间被复制到分组中。定时元数据轨道可以指代描述所引用的媒体的样本和/或提示样本。对于一种媒体类型的呈现，可以选择一个媒体轨道。轨道的样本可以隐含地与样本编号相关联，样本编号可以在指示的样本解码顺序中加1来递增。轨道中的第一样本可能与样本编号1相关联。
'trak'盒子包含一个Sample Table盒子。Sample Table盒包括例如轨道中媒体样本的所有时间和数据索引。要求Sample Table盒子包含Sample Description盒子。SampleDescription盒子包含条目计数字段，指定盒子中包括的样本条目数。要求SampleDescription盒子包含至少一个样本条目。样本条目格式取决于轨道的处理程序类型。样本条目提供有关所用编码类型的详细信息以及该编码所需的任何初始化信息。
图2示出了根据ISO基础媒体文件格式的简化文件结构的示例。如图2所示，文件90可以包括moov盒子92和mdat盒子94，并且moov盒子92可以包括分别对应于视频和音频的轨道(trak 96和trak 98)。
ISO基础媒体文件格式不限制呈现要被包含在一个文件中。因此，呈现可以被包含在若干文件中。作为示例，一个文件可以包括整个呈现的元数据，并且因此可以包括使呈现自包含的所有媒体数据。其他文件(如果使用的话)可以不要求被格式化为ISO基础媒体文件格式，并且可以用于包括媒体数据，并且还可以包括未使用的媒体数据或其他信息。ISO基础媒体文件格式仅涉及呈现文件的结构。媒体数据文件的格式可以由ISO基础媒体文件格式或其衍生格式约束，仅在于媒体文件中的媒体数据被格式化为ISO基础媒体文件格式或其衍生格式中所指定的格式。
引用外部文件的能力可以通过数据引用来实现。在一些示例中，每个轨道中包括的Sample Description盒子可以提供样本条目的列表，每个样本条目提供关于所使用的编码类型的详细信息以及该编码所需的任何初始化信息。块(chunk)的所有样本和轨道段的所有样本可以使用相同的样本条目。块可以被定义为一个轨道的连续样本集。数据引用(dref)盒子也可以被包括在每个轨道中，数据引用(dref)盒子可以定义统一资源定位符(URL)的索引列表、统一资源名称(URN)和/或对包含元数据的文件的自引用。样本条目可以指向数据引用盒子(在语法中，其可以被称为DataReferenceBox)的一个索引，从而指示包含相应的块或轨道段的样本的文件。
DataReferenceBox包含盒子列表，其声明文件引用的媒体数据的潜在位置。DataReferenceBox由DataInformationBox包含，而DataInformationBox又被MediaInformationBox或MetaBox包含。当被包含在MediaInformationBox中时，轨道的每个样本条目都包含数据引用索引，所述数据引用索引引用DataReferenceBox中的盒子列表的列表条目。当被包含在MetaBox中时，ItemLocationBox为每个项目提供引用在DataReferenceBox中的盒子列表的列表条目的数据引用索引。DataReferenceBox中的盒子从FullBox扩展，即包含盒子头部中的版本和flags字段。已规定要包括在DataReferenceBox中的两个盒子类型：DataEntryUrlBox和DataEntryUrnBox，分别提供URL和URN数据引用。当DataEntryUrlBox或DataEntryUrnBox的flags字段的最低有效比特等于1时，相应的数据引用引用包含文件本身，并且DataEntryUrlBox或DataEntryUrnBox中不提供URL或URN字符串。
电影段特征可以使得能够将可能驻留在电影盒子中的元数据分成多个段。每个段可以对应于轨道的特定时间段。换言之，电影段特征可以使能交织文件元数据和媒体数据。因此，可以限制电影盒子的大小并实现上述用例。
在一些示例中，如果电影段的媒体样本与moov盒子在同一文件中，则它们可以驻留在mdat盒子中。然而，对于电影段的元数据，可以提供moof盒子。moof盒子可以包括先前已经在moov盒子中的回放时间的特定持续时间的信息。moov盒子可能仍然代表其自己上的一个有效电影，但另外，它可能包括mvex盒子，mvex盒子指示电影段将跟在同一文件中。电影段可以及时扩展与moov盒相关联的呈现。
在电影段内可以存在轨道段集，包括每个轨道从零到多个的任何地方。轨道段依次可以包括从零到多个轨道运行的任何地方，每个文档是该轨道的连续样本运行。在这些结构中，许多字段是可选的，并且可以是默认的。可以包括在moof盒子中的元数据可以限于可以包括在moov盒子中的元数据的子集，并且在某些情况下可以被不同地编码。可以从ISO基础媒体文件格式规范中找到关于可以在moof盒子中包括的盒子的细节。可以将自包含的电影段定义为由以文件顺序连续的moof盒子和mdat盒子组成，其中mdat盒子包含电影段的样本(moof盒子为其提供元数据)并且不包含任何其他电影段(即任何其他moof盒子)的样本。
ISO基础媒体文件格式包含三种用于可与具体样本相关联的定时元数据的机制：样本组、定时元数据轨道和样本辅助信息。衍生规范可以提供与这三种机制中的一个或多个相似的功能。
可以将基础ISO媒体文件格式的样本分组定义为基于分组标准将轨道中的每个样本分配给一个样本组的成员。样本分组中的样本组不限于连续样本，并且可以包含非相邻样本。由于轨道中的样本可能有多个样本分组，因此每个样本分组可以具有类型字段来指示分组的类型。样本分组可以由两个链接的数据结构表示：(1)SampleToGroup盒子(sbgp盒子)表示将样本分配到样本组；(2)SampleGroupDescription盒子(sgpd盒子)包含描述组属性的对于每个样本组的样本组条目。根据不同的分组标准，SampleToGroup和SampleGroupDescription盒子可能有多个实例。这些可以通过用于指示分组的类型的类型字段来区分。'sbgp'和'sgpd'盒子可以使用grouping_type的值以及在某些版本的盒子中的grouping_type_parameter的值来链接。'sbgp'盒子指示具体样本所属的样本组描述条目的索引。
符合ISOBMFF的文件可以在meta盒子(四字符代码：'meta')中包含任何非定时对象，称为项目、元项目或元数据项目。虽然meta盒子的名称是指元数据，但项目通常可以包含元数据或媒体数据。meta盒子可以位于电影盒子(四字符代码：'moov')内以及轨道盒子内(四字符代码：'trak')文件的顶层，但最多只有一个meta盒子可以出现在文件级别、电影级别或轨道级别的每一个。可以要求meta盒子包含指示'meta'盒子内容的结构或格式的'hdlr'盒子。meta盒子可以列出和表征可以被引用的任何数量的项目，并且它们中的每一个可以与文件名相关联，以及通过项目标识符(item_id)唯一地与文件相联系，该标识符是整数值。元数据项目可以例如存储在meta盒子的“idat”盒子中或“mdat”盒子中或者驻留在单独的文件中。如果元数据位于文件外部，则其位置可以由DataInformationBox(四字符代码：'dinf')声明。在元数据使用XML语法来格式化并且需要直接存储在MetaBox中的特定情况下，元数据可以封装到或者XMLBox(四字符代码：'xml')或者BinaryXMLBox(四字符代码：'bxml')中。项目可以存储为连续的字节范围，或者可以存储在几个延伸区(extent)内，每个延伸区是连续的字节范围。换言之，可以将项目分段存储到延伸区中，例如以使得能够交织。延伸区是资源的字节的连续子集；资源可以通过串接延伸区来形成。
为了在层次结构的任何级别(文件、电影或轨道)支持多个meta盒子，可以使用meta盒子容器盒子('meco')作为一种ISO基础媒体文件格式。meta盒子容器盒子可以在层级的任何级别(文件、电影或轨道)上承载任何数量的附加meta盒子。这可以允许例如相同的元数据正在两个不同的替代元数据系统中呈现。meta盒子关系盒子('mere')可以使得能够描述不同的meta盒子如何彼此相关，例如它们是否包含完全相同的元数据(但用不同的方案描述)或者是否一个表示另一个的超集。
高效图像文件格式(HEIF)是由运动图像专家组(MPEG)开发的用于存储图像和图像序列的标准。该标准有助于根据高效视频编码(HEVC)标准编码的数据的文件封装。HEIF包括在所使用的ISO基础媒体文件格式(ISOBMFF)上建立的丰富特征集。
HEIF支持广泛的用例，范围从静态图片捕获、存储和共享到多图像用例，例如共享图像突发或存储图像集，以便通过计算摄影(computational photography)处理这些用例。计算摄影形成了一种可以从HEIF中受益的新用例。相关图像集可以存储在具有相关联的元数据的单个文件中，所述元数据指示不同图片之间的关系。这种新兴用例的示例包括通过从利用不同焦距捕获的图像集中选择具有期望焦点的图像来重新聚焦镜头、通过将图片与不同曝光组合来进行高动态范围拍摄、以及从具有连接的风景的图片集中构建全方位或全景图像。
ISOBMFF结构和特征在很大程度上用于HEIF的设计，HEIF文件也符合ISOBMFF。HEIF的基本设计包括将静止图像存储为项目，将图像序列存储为轨道。可以将任意数量的图像项目存储在同一文件中。
在HEIF的上下文中，以下盒子可以包含在根级“meta”盒子内，并且可以如下所述使用。在HEIF中，'meta'盒子的Handler盒子的处理程序值为'pict'。通过DataInformation('dinf')盒子解析包含编码媒体数据的资源(无论是在同一文件内，还是在由统一资源标识符标识的外部文件中)，而Item Location('iloc')盒子存储所引用的文件内每个项目的位置和大小。Item Reference('iref')盒子记载使用类型引用的项目之间的关系。如果项目集合中的项目以某种方式被认为是与其他项目相比最重要的项目，那么此项目将通过Primary Item(“pitm”)盒子来用信号通知。除了本文提到的盒子，'meta'盒子也很灵活，可以包括描述项目所需的其他盒子。
各种应用程序使用因特网媒体类型(也称为MIME(多用途因特网邮件扩展)类型)来标识资源或文件的类型。MIME类型由媒体类型、子类型和零个或多个可选参数组成。
如上所述，MIME是电子邮件协议的扩展，它使得有可能在因特网上发送和接收不同种类的数据文件，例如视频和音频、图像、软件等。因特网媒体类型是在因特网上用于指示文件包含的数据的类型的标识符。这种因特网媒体类型也可以称为内容类型。存在几种可以指示不同媒体格式的MIME类型/子类型组合。内容类型信息可以在媒体传输开始时由发送实体包括在MIME头部中。因此，接收实体可能需要检查这种媒体内容的细节以确定在给定可用的编解码器组的情况下是否可以呈现特定元素。特别是，当终端系统具有有限资源时，或者与终端系统的连接具有有限带宽时，仅从内容类型知道是否可以呈现内容可能是有帮助的。
两个参数“编解码器(codec)”和“配置文件(profile)”被规定用于各种MIME类型或类型/子类型组合，以允许对于其中包含的媒体格式使用的编解码器或整个容器格式的配置文件的明确规范。
通过使用为呈现所包含的媒体所指示的特定编解码器来标记内容，接收系统可以确定终端系统(end system)是否支持该编解码器，如果不支持，则可以采取适当的动作(例如拒绝内容、发送情况通知、将内容转码为所支持的类型、获取和安装所需的编解码器、进一步检查以确定是否足以支持所指示的编解码器的子集，等等)。对于从ISOBMFF导出的文件格式，可以认为编解码器参数包括一个或多个列表项目的以逗号分隔的列表。当编解码器参数的列表项目表示符合ISOBMFF的文件的轨道时，列表项目可以包括轨道的样本条目的四字符代码。
配置文件MIME参数可以向接收器提供内容符合的规范的总体指示。这表明容器格式及其内容与某些规范的兼容性。接收器可以有能力通过检查它支持哪些声明的配置文件及其含义来计算出它可以处理和呈现内容的程度。可以指定对于ISOBMFF文件的配置文件参数以包括文件中包括的兼容品牌的列表。
超文本传输协议(HTTP)广泛用于通过因特网传送实时多媒体内容，例如在视频流应用中。与通过用户数据报协议(UDP)使用实时传输协议(RTP)不同，HTTP易于配置，并且通常被允许遍历防火墙和网络地址转换器(NAT)，这使其对多媒体流应用程序具有吸引力。
HTTP的分块传输编码(也称为分块传送)包裹例如HTTP GET响应的有效载荷主体，以便将其作为一系列块传输，每个块都有自己的大小指示符。分块传输编码使得未知大小的内容流能够作为一系列长度界定的缓冲器进行传输，这使得发送器能够保持连接持久性，并且接收器能够知道它何时收到了整个消息。
ISO/IEC国际标准23009-1规定了HTTP(DASH)上的动态适应性流传输。以下将MPEG-DASH的一些概念、格式和操作作为其中可以实现实施例的视频流系统的示例来描述。本发明的各方面不限于MPEG-DASH，而是针对一个可能的基础给出描述，在该基础之上可以部分或完全实现本发明。
在HTTP(DASH)上的动态适应性流传输中，多媒体内容可以被捕获并将存储在HTTP服务器上，并且可以使用HTTP来传递。内容可以以两部分存储在服务器上：MediaPresentation Description(媒体呈现描述)(MPD)，其描述可用内容、其各种替代、它们的URL地址和其他特征的清单；以及段，其包含单个或多个文件中的块形式的实际多媒体比特流。为了播放内容，DASH客户端可以例如通过使用HTTP、电子邮件、拇指驱动器、广播或其他传输方法获得MPD。通过解析MPD，DASH客户端可以知道项目定时、媒体内容可用性、媒体类型、分辨率、最小和最大带宽和多媒体组件，以及多媒体组件的各种编码替代方案的存在、可用性特征和所需的数字版权管理(DRM)、网络上的媒体组件位置以及其他内容特征。使用该信息，DASH客户端可以选择适当的编码替代方案，并通过使用例如HTTP GET请求提取段来开始流传输内容。在适当缓冲以允许网络吞吐量变化之后，客户端可以继续获取后续段并且还监视网络带宽波动。客户端可以通过获取不同替代方案的段(具有更低或更高的比特率)来决定如何适应可用带宽以维持充足的缓冲器。
媒体呈现描述(MPD)可以为客户端提供信息以通过HTTP建立动态适应性流传输。MPD可以包含描述媒体呈现的信息，例如每个Segment(段)的HTTP-统一资源定位符(URL)以进行GET Segment请求。在DASH中，可以如下面总结的那样使用分层数据模型来构造媒体呈现。媒体呈现可以包括一个或多个周期的序列，每个周期可以包含一个或多个Group(组)，每个Group可以包含一个或多个Adaptation Set(适应集)，每个Adaptation Set可以包含一个或多个Representation(表示)，并且每个Representation可以包括一个或多个Segment。Representation是媒体内容或其子集的替代选择之一，其可以根据编码选择而不同，例如通过比特率、分辨率、语言、编解码器等，Segment可以包含特定持续时间的媒体数据，以及用于解码和呈现所包括的媒体内容的元数据。Segment可以通过统一资源指示符(URI)来标识，并且可以由HTTP GET请求来请求。Segment可以被定义为与HTTP-URL相关联的数据单元以及可选地由MPD规定的字节范围。
可以提供DASH服务作为按需服务或直播服务。在前者中，MPD是静态的，并且当内容提供商发布MPD时，Media Presentation(媒体呈现)的所有Segment已经可用。然而，在后者中，MPD可以是静态的或动态的，这取决于MPD采用的Segment URL构造方法，并且当内容由内容提供商产生并发布到DASH客户端时，可以连续地创建Segment。Segment URL构造方法可以是基于模板的Segment URL构造方法或段列表生成方法。在前者中，DASH客户端能够构建Segment URL而不用在请求Segment之前更新MPD。在后者中，DASH客户端可能需要定期下载更新的MPD以获得Segment URL。因此，对于实时服务，基于模板的Segment URL构造方法可以优于Segment列表生成方法。
在DASH的上下文中，可以使用以下定义：媒体内容组件或媒体组件可以被定义为媒体内容的一个连续组件，其具有可以被单独编码到媒体流中的指定的媒体组件类型。媒体内容可以被定义为一个媒体内容时段或媒体内容时段的连续序列。媒体内容组件类型可以被定义为单一类型的媒体内容，例如音频、视频或文本。媒体流可以被定义为媒体内容组件的编码版本。
Initialization Segment(初始化段)可以被定义为包含呈现封装在MediaSegment(媒体段)中的媒体流所必需的元数据的Segment。在基于ISOBMFF的段格式中，Initialization Segment可以包括Movie Box('moov')，其可能不包括任何样本的元数据，即样本的任何元数据在'moof'盒子中提供。
Media Segment可以被定义为符合容器文件格式和/或在用的媒体格式或多个格式的Segment，并且当与零个或多个先前段以及Initialization Segment(如果有的话)组合时使得能够进行回放。Media Segment可以包含特定持续时间的媒体数据用于以正常速度回放，这种持续时间可以被称为Media Segment持续时间或Segment持续时间。内容制作者或服务提供商可以根据服务的期望特征来选择Segment持续时间。例如可以在实时服务中使用相对较短的Segment持续时间来实现短的端到端等待时间。原因是Segment持续时间可以是DASH客户端感知的端到端等待时间的下限，因为Segment是生成对于DASH的媒体数据的离散单元。内容生成可以以使整个媒体数据的Segment可用于服务器的方式完成。此外，许多客户端实现可以使用Segment作为GET请求的单元。因此，在用于直播服务的一些布置中，仅当Media Segment的整个持续时间可用以及被编码和封装到Segment中时，DASH客户端才能请求Segment。对于按需服务，可以使用不同的选择Segment持续时间的策略。
Segment可以进一步划分为Subsegment(子段)，例如使得能够以多个部分下载段。可能需要Subsegment包含完整的访问单元。Subsegment可以由Segment Index(段索引)盒子(其在语法中可以被称为SegmentIndexBox)索引，其包含用于映射每个Subsegment的呈现时间范围和字节范围的信息。Segment Index盒子还可以通过发信号通知其持续时间和字节偏移来描述段中的子段和流接入点。DASH客户端可以使用从Segment Index盒子获得的信息来使用字节范围HTTP请求对特定Subsegment进行HTTP GET请求。如果使用相对长的Segment持续时间，则可以使用Subsegment来保持HTTP响应的大小合理且灵活以用于比特率适应。段的索引信息可以放在该段开始的单个盒子中，或者分布在该段中的许多索引盒子中。不同的传播方法是可能的，例如分层式、菊花链式和混合式。该技术可以避免在段的开始添加大的盒子，因此可以防止可能的初始下载延迟。
可以为每个媒体段分配唯一的URL(可能具有字节范围)、索引以及显式或隐式的开始时间和持续时间。每个媒体段可以包含至少一个流接入点，其是媒体流中的随机接入或切换点，在该随机接入或切换点处可以仅使用从该点向前的数据开始解码。
为了能够在多个部分中下载段，可以利用使用段索引盒子来发信号通知子段的方法。此盒子通过发信号通知其持续时间和字节偏移来描述段中的子段和流接入点。DASH客户端可以使用索引信息来使用部分HTTP GET请求来请求子段。段的索引信息可以放在该段开始的单个盒子中，或者分布在该段中的许多索引盒子中。不同的传播方法是可能的，例如分层式、菊花链式和混合式。该技术可以避免在段的开始添加大的盒子，因此可以防止可能的初始下载延迟。
MPEG-DASH为ISO基础媒体文件格式和MPEG-2传输流定义了段容器格式。其他规范可以基于其他容器格式指定段格式。例如已经提出了一种基于Matroska容器文件格式的段格式，概述如下。当Matroska文件作为DASH段或类似物承载时，DASH单元和Matroska单元的关联可以总结如下。(DASH的)子段可以被定义为Matroska封装内容的一个或多个连续集群。可能需要DASH的Initialization Segment包括EBML头、(Matroska的)Segment头、(Matroska)的Segment信息和轨道，并且可选地可以包括其他级别1元素和填充。DASH的Segment Index可以包括Matroska的Cues Element(提示元素)。
DASH通过动态地请求来自Adaptation Set(适配集)内的不同Representation的Media Segment和/或Subsegment来支持速率适配，以匹配变化的网络带宽。当DASH客户端切换开/关Representation时，可能需要考虑Representation内的编码依赖性。在媒体解码中，Representation开关可以仅发生在可以在诸如H.264/AVC的视频编码技术中使用的随机接入点(RAP)处。为了避免请求和发送将不被解码的媒体数据，可以在Media Segment和/或Subsegment的开始对齐RAP，并且可以使用MPD和/或段索引盒子来指示在Media Segment和/或Subsegment的开始处的RAP对齐。因此，DASH客户端可以有能力推断要请求哪些段Segment/或Subsegment，以便在执行Representation切换时，目的地Representation的第一段Segment和/或Subsegment以RAP开始，源和目的地Representation的段Segment和/或Subsegment是(按时间)对齐的。在DASH中，引入了一个更为通用的概念，即流接入点(SAP)，以提供一种独立于编解码器的解决方案，用于访问Representation和在Representation之间切换。在DASH中，SAP被规定为Representation中的位置，其使得能够仅使用从该位置向前开始(在Initialization Segment中通过初始化数据在前面的，如果有的话)的Representation数据中包含的信息来回放要开始的媒体流。因此，Representation切换可以在SAP中执行。
类似于MPEG-DASH的流式系统包括例如在IETF因特网草案draft-pantos-http-live-streaming-13(以及相同的因特网草案的其他版本)中规定的HTTP Live Streaming(直播流)(又称HLS)。作为对应于MPD的清单格式，HLS使用扩展的M3U格式。M3U是用于多媒体播放列表的文件格式，最初是为音频文件开发的。M3U播放列表是由单独的行组成的文本文件，每行是URI、空白的或以指示标记或注释字符“#”开始。URI行标识媒体段或Playlist(播放列表)文件。标签以#EXT开始。HLS规范规定了许多标签，这些标签可以被视为密钥-值对。标签的值部分可以包括属性列表，其是逗号分隔的属性-值对列表，其中属性-值对可以被认为具有语法AttributeName＝AttributeValue。因此，HLS M3U8文件的标签可以被认为类似于MPD或XML中的Element(元素)，并且HLS M3U8文件的属性可以被认为类似于MPD或XML中的Attribute(属性)。HLS中的媒体段根据MPEG-2Transport Stream(传输流)格式化，并包含单个MPEG-2程序。建议每个媒体段以Program Association Table(节目关联表)(PAT)和Program Map Table(节目映射表)(PMT)开始。
超文本标记语言版本5.1(HTML 5.1)支持许多用例，其中内容作者可以使用多个图像资源，用户代理(例如网络浏览器)可以从该多个图像资源中选择。例如不同的用户可能具有不同的环境特征；作者可能希望显示具有不同渲染尺寸和/或使用不同图像格式的相同图像内容；和/或作者可能想要显示不同的图像内容。
在下文中，将简要讨论环境特征的一些非限制性实例。用户设备的物理屏幕大小可能因设备而异。作为示例，移动电话的屏幕可能小于膝上型计算机的屏幕。仅当图像的渲染尺寸取决于视口(viewport)大小时，此差异才有意义。用户设备的屏幕像素密度在不同设备中也可能不同。不管它们的物理屏幕大小如何，不同的设备可以进一步具有不同的像素密度。例如与另一移动电话的屏幕相比，一个移动电话的屏幕每英寸可能具有更多的物理像素。设备之间的缩放级别(zoom level)也可能存在差异，或者单个用户的缩放级别可能随时间而变化。作为示例，用户可以放大特定图像以能够获得更细节的查看。缩放级别和屏幕像素密度都可能影响每CSS像素的物理屏幕像素数(级联样式表-语言)。该比率可以称为设备像素比。此外，屏幕方向在不同设备中可能不同，或者对于单个用户可能随着时间的推移而改变。例如平板电脑可以直立或旋转90度，因此屏幕可以是“纵向”或“横向”。用户的网络速度、网络延迟和带宽成本也可能存在差异，或者对于单个用户可能会随着时间的推移而改变。用户可能在工作时使用快速的、低延迟的和成本恒定的连接，在家中使用慢速的、低延迟和成本恒定的连接，在其他地方使用速度可变的、高延迟的和成本可变的连接。
在下文中，将提供示出具有不同渲染尺寸和/或使用不同图像格式的相同图像内容的一些非限制性示例。选择渲染尺寸可以取决于例如视口(viewport)的宽度。这可以称为基于视口的选择。
网页顶部可能有横幅(banner)，其可以始终跨越整个视口宽度。在这种情况下，图像的渲染尺寸取决于屏幕的物理尺寸(假设浏览器窗口最大化)。
另一网页可能包含列中的图像，其中单列用于具有较小物理尺寸的屏幕，两列用于具有中等物理尺寸的屏幕，三列用于具有较大物理尺寸的屏幕，其中图像在每种情况下渲染尺寸不同以填充视口。在这种情况下，尽管屏幕较小，但与双列布局相比，一列布局中图像的渲染尺寸可能更大。
网页内容的作者可能希望根据图像的渲染尺寸显示不同的图像内容。这可以称为艺术导向(art direction)。
当在具有大物理尺寸的屏幕上观看网页时(假设浏览器窗口最大化)，作者可能希望在图像的关键部分周围包括一些不太相关的部分。当在具有小物理尺寸的屏幕上观看相同网页时，作者可能希望仅显示图像的关键部分。
网页作者可能希望显示相同的图像内容，但使用不同的图像格式，具体取决于用户代理所支持的图像格式。这通常被称为基于图像格式的选择。
网页可能具有JPEG(联合图像专家组)、WebP和JPEG XR(JPEG扩展范围)图像格式的一些图像，据报道后两者与JPEG相比具有更好的压缩能力。由于不同的用户代理可能支持不同的图像格式，而某些格式提供更好的压缩率，作者可能希望为支持它们的用户代理提供更好的格式，同时为不支持更好格式的用户代理提供JPEG回退。
上述情况并非相互排斥。例如将用于不同设备像素比的不同资源与用于艺术导向的不同资源组合可能是合理的。
HTML 5.1以及HTML的旧版本包括表示图像的img元素。img元素可以包括src属性，引用既不是分页也不是脚本化的非交互式、动画可选的图像资源。由于较旧的HTML版本解析src属性，因此通过src属性提供的图像可以被视为默认图像或回退图像。
img元素也可以包含srcset属性。如果存在，则它包含一个或多个以逗号分隔的图像候选字符串。
图像候选字符串可以按顺序包括以下组件，具有在该列表下描述的进一步限制。首先，候选图像可以包含零个或多个空格字符；然后是不以逗号字符(，)开始或结尾的有效非空统一资源定位符(URL)，引用既不是分页也不是脚本化的非交互式的、可选地动画的图像资源。在统一资源定位符之后，可能存在零个或多个空格字符，后跟零个或一个宽度描述符和像素密度描述符。最后，可能有零个或多个空格字符。
宽度描述符可以包括空格字符、给出表示宽度描述符值的大于零的数字的有效非负整数、以及拉丁文小写字母“w”字符。
像素密度描述符可以包括空格字符、给出表示像素密度描述符值的大于零的数字的有效浮点数、以及拉丁小写字母“x”字符。
描述符可用于表征候选图像，并因此用于选择满足所需特征的适当图像。
HTML 5.1中的图片元素可以包含也可以不包含img元素。
HTML 5.1包括图片(picture)元素，其包含零个或多个源(source)元素，后跟一个img元素。图片元素是容器，它为其包含的img元素提供多个源，以允许作者基于屏幕像素密度、视口尺寸、图像格式和其他因素以声明方式控制或向用户代理提供有关使用哪个图像资源的提示。它代表了其衍生物。
图片元素中的源元素可以允许作者为img元素规定多个替代源集。图片元素内的源元素可以包括srcset属性，当srcset属性包括任何图像候选字符串中的宽度描述符时可以并且有条件地必须包括尺寸属性，可选地包括媒体属性，以及可选地包括类型属性。媒体属性包含有效的媒体查询列表。类型属性包含有效的MIME类型。尺寸、介质和类型属性(如果存在)可以表征源集(即，在相同源元素的srcset属性中标识的图像)，并且因此可以用于选择满足所需应用特征或偏好的适当源集。此外，可以从该源集中选择适当的图像。
链接是由a、区域和链接(a,area,link)元素创建的概念构造，表示两个资源之间的连接，其中之一是当前文档。HTML中可以有两种链接。第一种类型是指向外部资源的链接。可以使用指向外部资源的链接来增强当前文档，通常由用户代理自动处理。第二种类型是超链接。超链接是指向通常由用户代理向用户公开的其他资源的链接，以便用户可以使用户代理导航到那些资源，例如在浏览器中访问它们或下载它们。
对于具有href属性和rel属性的链接元素，应为rel属性的关键字创建链接，如为这些关键字定义的那样。同样，对于具有href属性和rel属性的a和区域元素，应为rel属性的关键字创建链接，如为这些关键字定义的那样。但是，与链接元素不同，对于具有href属性的a和区域元素，其或者不具有rel属性或者其rel属性不具有被定义为指定超链接的关键字，也应该创建超链接。除了将元素的节点文档链接到元素的href属性给出的资源之外，该隐含的超链接可能没有特殊含义(它没有链接类型)。
HTML 5.1以及其他规范中规定了许多链接类型。链接类型被规定为用作rel属性的值的特定字符串。例如，预取链接类型规定应抢先缓存目标资源。
统一资源标识符(URI)可以被定义为用于标识资源的名称的字符串。这种标识使得能够使用特定协议通过网络与资源的表示进行交互。通过规定URI的具体语法和相关协议的方案来定义URI。URI包括方案部分(标识例如URI的协议)和标识资源的分层部分，并且这两部分由冒号字符分隔。URI可选地可以包括查询部分(由字符“？”分隔)和/或段部分(由字符“#”分隔)。统一资源定位符(URL)和统一资源名称(URN)是URI的形式。URL可以被定义为URI，所述URI标识web资源并规定对资源的表示进行操作或获得资源的表示、规定其主要访问机制和网络位置的方式。URN可以定义为在特定名称空间中按名称标识资源的URI。URN可用于标识资源而不暗示其位置或如何访问它。
可以为具体内容类型指定URL碎片标识符(也可以称为URL表单)以访问由URL的基本部分(没有段标识符)指示的资源的一部分，例如文件。URL碎片标识符可以例如通过URL内的散列('#')字符来标识。对于ISOBMFF，可以规定URL碎片“#X”指的是track_ID等于X的轨道，“#item_ID＝”和“#item_name＝”指的是文件级meta盒子，“#/item_ID＝和“#/item_name＝”指的是电影盒子中的meta盒子，“#track_ID＝X/item_ID＝”和“#track_ID＝X/item_name＝”指的是track_ID等于X的轨道中的meta盒子，包括可能在电影段中找到的meta盒子。
在ISOBMFF中，可以使用由(a)DataReferenceBox(b)SampleToChunkBox(c)ChunkOffsetBox和(d)SampleSizesBox提供的信息来计算TrackBox引用的样本(即排除电影段引用的样本)的确切位置。此外，样本的定位涉及使用文件开始的偏移计算。对于电影段引用的样本，可以使用TrackFragmentHeaderBox和TrackFragmentRunBox中提供的信息来计算样本的确切位置，并且样本的定位可以涉及使用或者文件的开始或者MovieFragment Box的开始作为引用来计算偏移。偏移的使用可以使文件对任何编辑都很脆弱。例如，在文件的开始和MediaDataBox之间简单地添加或删除字节就足以毁坏计算的偏移并使文件不可解码。这意味着正在编辑文件的任何实体都应该小心确保文件中计算和设置的所有偏移在它完成编辑后必须有效。
URL碎片允许例如使用HTTP GET请求来请求文件或资源的一部分。但是，如果使用URL碎片进行部分接收的文件使用相对于文件开始的寻址，则服务器返回符合文件格式的有效资源(例如ISOBMFF)可能具有挑战性，或者播放器可能无法解析由已解析的请求产生的资源。
在下文中，将提供导致部分文件接收的用例的两个不同示例。
第一示例涉及有意的部分文件接收。在此示例中，容器文件在服务器中可用。容器文件包含媒体轨道和/或项目，其子集足以用于消费(例如显示或回放)。例如容器文件可以是图像容器文件，包含例如具有不同编解码器和/或不同空间分辨率的多个编码版本中的相同原始图像。获取用于显示的编码图像的子集就足够了，例如缩略图图像，其可以在下载适合显示分辨率的另一图像时显示。因此，客户端单独地或以合适的包从文件请求媒体轨道和/或项目的子集。单个容器文件对于服务器和/或内容传递网络中的内容管理可能是优选的。
第二示例涉及意外的部分文件接收。可以使用例如MBMS文件传递栈(由第三代合作伙伴计划(3GPP)指定的多媒体广播和多播服务)的不可靠协议来传输文件。可以假设可以检测到损失，以便知道盒子是否未被完全接收。但是，所接收的文件的一部分可能会丢失。接收器可能无法轻易得出结论是否部分接收的文件有效或符合要求。以如下方式存储部分接收的文件可能是不合适的：指示文件符合例如ISOBMFF的格式、指示文件或假定文件没有错误。同样，利用分别假定无差错文件和/或无差错媒体比特流的文件解析器和/或媒体解码器来处理部分接收的文件可能是不合适的。
对于某些盒子类型，ISOBMFF允许几个相同的四字符代码的盒子出现在文件层次结构的同一级别中。例如允许在文件的根级别具有多个MediaDataBox。某些盒子可能包含例如使用偏移的对其他盒子的引用或类似的，所述偏移例如相对于文件开始的偏移。例如MovieBox包含可以引用MediaDataBox中的内容的引用，例如块偏移。当文件被部分接收时，需要确保维护此类引用的完整性，以便能够正确地解析文件。
DASH中的传输单元(Segment或Subsegment)可以包括一个或多个自包含的电影碎片，其中自包含的电影碎片可以包括MovieFragmentBox和包含MovieFragmentBox中描述的媒体数据的MediaDataBox。这种设计可能导致实况内容分发的延迟，因为传输单元只能在其所有媒体数据被编码之后才可用。例如1秒的段持续时间可能导致编码和文件封装中的大致相同的延迟(加上编码和封装中引起的处理延迟)以使段可用。
根据实施例，文件级盒子可以是自立的，也可以独立于盒子顺序和其他文件级盒子的存在。这样的文件可以称为可重新排序的文件。在实施例中，在文件和/或文件的描述中指示文件是否是可重新排序的。在实施例中，通过在指示文件可重新排序的FileTypeBox中包括特定品牌来执行所述指示。在实施例中，特定品牌指示所有MediaDataBox包括标识符，并且所有文件内部媒体数据引用都是相对于包含媒体数据的相应MediaDataBox的。在实施例中，符合该品牌的播放器如下操作。当特定id_value的MediaDataBox被引用(例如通过如另一实施例中所述的数据引用)但是文件中不存在mdat_identifier等于id_value的MediaDataBox时，播放器省略相关轨道或项目的处理。此外，播放器根据这样的关联轨道或项目省略任何轨道或项目的处理。播放器例如通过轨道引用或项目引用来推断这种依赖性。
在实施例中，在文件的相同层级(例如根级别)中允许出现不止一次的盒类型的盒子，用将其与相同文件层级中相同类型的其他盒子区分开的标识符来标记，或这种标识符是从盒子的内容衍生的。在实施例中，仅针对可能发生来自其他盒子的引用的那些盒子或盒子类型执行所述标记或衍生。
由于文件或引用文件中可以包含许多MediaDataBox，因此应该有一种方法唯一地识别样本所在的MediaDataBox。在实施例中，通过用标识符标记每个MediaDataBox来实现从许多MediaDataBox中识别MediaDataBox的能力。可以有许多方法来标记MediaDataBox，包括但不限于以下内容。作为第一示例，可以在盒子的盒子头部之后立即附加标识符值，该标识符值例如可以是某个比特计数的无符号整数值。根据另一示例，可以在盒子的盒子头部之后附加通用唯一标识符(UUID)。在另一示例中，诸如MD5校验和之类的标识符是从盒子内容的子集或从整个盒子中衍生的并且用于标识盒子。作为又一选项，可以约束可重新排序性，使得某个类型的一个或多个盒子紧接在MediaDataBox之前(或之后)并包含MediaDataBox的标识符。
根据实施例，在文件中指示的偏移(也可以称为地址或指针)是相对于包含寻址数据的盒子的开始的。在许多情况下，地址可以相对于包含寻址数据的文件级盒子。在实施例中，偏移指示样本是相对于包含样本的MediaDataBox的。
由于偏移可以包括在与偏移正在寻址的数据不同的文件级盒子中，因此包含偏移的盒子可以与包含所寻址数据的盒子相关联。在实施例中，关联可以使用标识符来实现，该标识符可以称为例如mdat_identifier，其被包括被引用的文件中或在文件中包含的每个MediaDataBox中。可以利用来自任何MediaDataBox的数据的轨道可能需要使用其标识符以及使用MediaDataBox的开始作为其引用来计算的偏移，来引用MediaDataBox。可以通过使用具体MediaDataBox标识符和相对于该具体MediaDataBox的开始的偏移来引用该具体MediaDataBox，来提供项目数据在文件内的位置。
可重新排序文件的功能可以使文件编辑更容易。例如在包含第一轨道的文件被添加第二轨道的情况下，当第二轨道的媒体数据被放置在不同于包含第一首轨道的媒体数据的那些的MediaDataBox中时，不需要重新衍生第一轨道的样本的偏移。将轨道或项目添加到可重新排序的文件中时，其媒体数据可以包括在新的MediaDataBox中。MovieBox附加了新TrackBox或项目信息。不必更新已经存在于文件中的轨道或项目的位置偏移信息，因为偏移是相对于携带相应媒体数据的MediaDataBox的。添加的轨道或项目的位置偏移信息是相对于新添加的MediaDataBox的，因此也可以直接计算。很容易将修改后的MovieBox定位到文件的开头，因为没有位置偏移取决于文件顺序中MediaDataBox之前的盒子的大小。当从可重新排序的文件中删除轨道或项目时，可以检查MediaDataBox中是否存在除删除的轨道或项目之外的其他媒体数据。如果是，可以删除MediaDataBox而不影响其余轨道或项目的位置偏移。同样，可以从文件中删除TrackBox或项目信息，而无需重新计算剩余轨道和项目的位置偏移。
在实施例中，引入URL碎片命名方案以标识文件级盒子。使用该标识命名方案的URL被解析为由URL碎片标识的文件级盒子组成的资源。由于文件级别中可以存在多个相同名称或类型的盒子，因此URL碎片命名方案还包括从同一盒子类型或名称的另一文件级盒子中识别文件级盒子的方法。例如上述MediaDataBox的标识符可以包括在URL碎片中。
在实施例中，文件和/或文件的描述或表示包括关于文件级盒子序列的信息。该信息可以被视为文件的内容的目录或表。该信息可用于例如向客户端通知不间断回放所需的下载顺序。该信息可以使得可以基于所述描述生成用于文件级盒子的URL碎片。在实施例中，MediaDataBox的标识符可以包括关于文件级盒子序列的信息的一部分。在实施例中，MediaDataBox的标识符遵循可以例如在标准中预定义或可以在信息中指出的编号方案。当使用MediaDataBox编号方案时，MediaDataBox的标识符可以不存在于每个MediaDataBox，而是可以从每个MediaDataBox的编号方案衍生。
可以进行部分文件接收。在实施例中，接收器可以正在接收或已经接收到文件级盒子。接收器可以具有先验信息，或者接收器可以从文件中的指示和/或文件的描述中得出文件可重新排序的结论。接收器可以将接收器已正确接收的那些文件级盒子写入接收的文件中。接收器可以将接收的文件提供给播放器，和/或播放器可以从存储器检索该文件，所述存储器例如随机存取存储器(RAM)、闪存或固态驱动器(SSD)。在实施例中，播放器具有先验信息或者从文件中的指示和/或文件的描述中得出文件可重新排序的结论。例如播放器可以在媒体呈现描述中接收与Representation相关联的MIME类型，并且当MIME类型包括指示可重新排序的文件或段的品牌时从MIME类型的配置文件参数得出该文件或段是可重新排序的结论。播放器可以解析文件级盒子序列的信息。播放器可以按照文件级盒子序列的信息中指示的顺序解析所接收文件的文件级盒子。播放器可以通过将所接收文件中的可用盒子与文件级盒子序列的信息进行比较来识别所接收文件的丢失盒子。播放器可以例如通过通知用户和/或通过例如使用与丢失的文件级盒子相关联的URL碎片从服务器请求丢失数据，来处理所标识的丢失数据。
根据实施例，可以如下实现低延迟直播流。在实施例中，流传输客户端(streamingclient)可以例如从Representation的描述中推断出这些段使用MediaDataBox相对偏移。例如流传输客户端可以在媒体呈现描述中接收与Representation相关联的MIME类型，并且当MIME类型包括指示使用MediaDataBox相对偏移的品牌时从MIME类型的配置文件参数推断出段使用MediaDataBox相对偏移。流传输客户端可以例如从媒体呈现描述推断出用于接收MovieFragmentBox或段头的URL碎片以及相应的MediaDataBox或段有效载荷。流传输客户端还可以在结论中使用其他文件级盒子，例如SegmentIndexBox。流传输客户端可以例如使用并行HTTP连接，分开请求MovieFragmentBox或段头的URL碎片，以及MediaDataBox或段有效载荷。在实施例中，流传输客户端使用指示具体盒子或多个具体盒子的URL碎片，例如用于指示段的MovieFragmentBox的box_id＝moof和用于指示段的MediaDataBox的box_id＝mdat，以用于使用并行HTTP连接分开请求MovieFragmentBox和MediaDataBox。在实施例中，流传输客户端可以分开地请求(例如使用并行HTTP连接)使用特定URL碎片的段头部(例如如在另一实施例中所描述的seghdr)以及使用另一特定URL碎片的段数据(例如如在另一实施例中描述的segpayload)。在实施例中，流传输客户端可以请求使用特定URL碎片的段头部，例如在另一实施例中描述的seghdr。流传输客户端可以例如从表示的描述中推断出该段的MediaDataBox的URL碎片。然后，流传输客户端可以使用所推断出的URL碎片分开地请求(例如使用并行HTTP连接)该段的媒体数据。
在实施例中，服务器可以利用分块的HTTP传送来响应URL碎片请求。服务器发送MovieFragmentBox或者段头部的第一部分以及相应的MediaDataBox或段有效载荷可以在发送相同的MovieFragmentBox或者段头部(各自的)的第二部分以及相同的MediaDataBox或者段头部(各自的)之前。第一部分可以包含直到实时边缘的数据，即到目前为止可用的数据。第一部分可以限于例如整数个TrackFragmentBox和MediaDataBox中相应的媒体数据，即避免发送部分TrackFragmentBox。因此，可以减少与编码和文件封装相关的固有延迟，并且可以使其与分块HTTP传送中的“块”持续时间一样小。
在实施例中，媒体封装器连接到服务器。媒体封装器可以将至少一个编码媒体流打包到容器文件或段中。媒体封装器将MovieFragmentBox和相应的MediaDataBox的第一部分提供给要发送的服务器可以在完成对相同MovieFragmentBox和相同MediaDataBox的第二部分的封装之前。
在本说明书的前文，曾提出可能有几种标记MediaDataBox的方法。在下文中，将更详细地描述紧接在盒子的盒子头部之后附加无符号整数标识符值的示例。
根据实施例的MediaDataBox的描述、语法和语义根据实施例如下：
Box Type:‘mdat’(盒子类型：'mdat')
Container:File(容器：文件)
Mandatory:No(强制：否)
Quantity:Zero or more(数量：零个或更多个)
根据实施例，MediaDataBox的语义如下。类型指示(Box Type)显示该盒子是MediaDataBox。参数mdat_identifier是不同于文件的其他MediaDataBox的mdat_identifier值并且因此允许标识该mdat盒子的32比特无符号整数。参数data是所包含的媒体数据。
利用这种内容，封装在文件或引用文件中的任何MediaDataBox可以由mdat_identifier唯一地标识。
根据实施例，引用的MediaDataBox在包含在DataReferenceBox中的用于轨道的盒子中标识，并因此与数据引用索引值相关联。当该数据引用索引值由该轨道的样本条目引用时，与指示样本位置相关的偏移是相对于在盒子中标识的要作为数据引用索引值引用的MediaDataBox的。
根据实施例，引用的MediaData Box在包含在DataReferenceBox中用于MetaBox的盒子中标识，并因此与数据引用索引值相关联。当数据引用索引值被引用以例如在ItemLocationBox中指示项目位置时，与指示项目位置相关的偏移是相对于在盒子中标识的要作为数据引用索引值引用的MediaDataBox的。
下面描述关于在DataReferenceBox中包含的盒子中标识MediaDataBox的实施例。
在实施例中，指定了一种例如名为DataEntryIdentifiedMdatBox的新盒子类型和可以包含在DataReferenceBox中的四字符代码'imdt'，。DataEntryIdentifiedMdatBox被指定为包含引用的MediaDataBox的标识符，例如32比特mdat_identifier字段。当文件创建者写入具有相对于具体MediaDataBox的偏移的文件时，文件创建者在DataReferenceBox中包括具有该MediaDataBox的标识符的DataEntryIdentifiedMdatBox。然后，文件创建者创作文件，使得DataEntryIdentifiedMdatBox的数据引用索引与偏移相关联。
在实施例中，规定URL或URN方案以标识在包含文件内的MediaDataBox。在实施例中，如在另一实施例中描述的URL碎片方案(或等效地，URN碎片方案)与指示包含文件的URL或URN一起使用。具有碎片部分的URL或URN(由文件创建者)包括在DataReferenceUrlBox或DataReferenceUrnBox中。
在实施例中，标识包含文件的URL或URN包括在方案部分“file：”，并且分层部分中是空的。空的分层部分可以被视为指示相对于基础URI的相对URL或URN，基础URI在这种情况下(当URL或URN包含在文件中时)可以被解析以指示包含文件本身，并且因此空的分层部分可以被解析以指示包含文件。根据另一实施例，碎片部分可用于标识MediaDataBox。例如碎片部分可以是#box_id＝mdat/mdat_identifier，其中mdat_identifier是MediaDataBox的标识符值。总的来说，要包括在DataReferenceUrlBox或DataReferenceUriBox中的URL或URN语法的示例因此是“file：#box_id＝mdat/mdat_identifier”。
在实施例中，标识包含文件的URL或URN具有空方案部分和空分层部分。它可以例如通过引用包含文件本身的包含盒子(DataReferenceUrlBox或DataReferenceUrnBox)的flags字段的最低有效比特来指示，或者可以例如基于它以指示碎片部分的散列('#')开始从所包含的URL或URN中推断出URL或URN引用包含文件本身。
当文件创建者写入具有相对于具体MediaDataBox的偏移的文件时，文件创建者在DataReferenceBox中包括具有指示包含文件本身的URL和指示DataReferenceBox中的MediaDataBox的URL碎片的DataReferenceUrlBox。然后，文件创建者创作文件，以便DataReferenceUrlBox的数据引用索引与偏移相关联。
在实施例中，DataReferenceBox内的包含盒子的盒子头部的flags中的新比特(例如第二最低有效比特)用于指示相对于具体标识符的MediaDataBox的偏移如下。当flags字段的最低有效比特等于1并且flags字段的新比特等于0时，偏移具有传统的引用点，通常是包含文件的开头。当flags字段的最低有效比特等于1并且flags字段的新比特等于1时，该盒子包括所引用的MediaDataBox的标识，并且偏移相对于所引用的MediaDataBox。在实施例中，当flags字段的最低有效比特等于1并且flags字段的新比特在DataReferenceUrlBox中等于1时，根据另一实施例，包含在盒子中的URL包括标识MediaDataBox的URL碎片。例如碎片部分可以是#box_id＝mdat/mdat_identifier，其中mdat_identifier是MediaDataBox的标识符值。例如盒子中包括的URL可以是“#box_id＝mdat/3456”，其引用标识符等于3456的MediaDataBox。在另一实施例中，当flags字段的最低有效比特等于1并且flags字段的新比特在DataReferenceUrlBox中等于1时，在盒子中包含的URL包括MediaDataBox的标识符(即，不需要遵循URL碎片语法)。
在实施例中，DataReferenceBox中包含的盒子的盒子头部的新版本值(例如等于2)用于指示相对于特定标识符的MediaDataBox的偏移如下所述。当flags字段的最低有效比特等于1并且版本字段具有新值时，该盒子包括所引用的MediaDataBox的标识，并且偏移是相对于所引用的MediaDataBox的。在实施例中，当flags字段的最低有效比特等于1并且版本字段等于DataReferenceUrlBox中的新值(例如2)时，盒子中包括的URL或者是空的或者包括URL碎片。当URL为空时，指示整个包含文件，并且偏移具有常规引用点，通常是包含文件的开头。根据另一实施例，当URL包括URL碎片时，它标识MediaDataBox。例如碎片部分可以是#box_id＝mdat/mdat_identifier，其中mdat_identifier是MediaDataBox的标识符值。例如盒子中包括的URL可以是“#box_id＝mdat/3456”，其引用标识符等于3456的MediaDataBox。在另一实施例中，当flags字段的最低有效比特等于1并且版本字段等于DataReferenceUrlBox中的新值(例如2)时，盒子中包括的URL包括MediaDataBox的标识符(即，不需要遵循URL碎片语法)。
在实施例中，文件解析器解析其中在DataReferenceBox中包含的盒子中标识MediaDataBox的文件，操作如下。文件解析器从文件(例如来自样本条目或来自ItemLocationBox)中推断出哪个数据引用索引与用于指示媒体数据(例如分别用于样本或项目)的位置的偏移相关联。基于数据引用索引，文件解析器从DataReferenceBox中找到正确的包含盒子(例如在不同实施例中的类型DataEntryIdentifiedMdatBox或DataEntryUrlBox)。文件解析器解析在该正确包含盒子中包括的MediaDataBox的标识符。文件解析器找到与标识符关联的MediaDataBox。文件解析器通过将偏移基本上添加到MediaDataBox的有效载荷的开始来找到由偏移引用的数据。例如当在块中使用具有带有碎片为box_id＝mdat/
根据不在DataReferenceBox中使用上述修改的实施例，可以如下指示相对于MediaDataBox的块偏移。在ISOBMFF中，块偏移用于指示MovieBox中描述的连续样本集的(在文件内的)起始位置。在实施例中，可以定义ChunkOffsetBox中的块的偏移计算，使得代替从文件的开始计算偏移，而从包含块的MediaDataBox的开始计算偏移。为了实现这一点，根据实施例，ChunkOffsetBox的语法和语义可以如下所示。
根据实施例，ChunkOffsetBox的语义如下。参数version是规定此盒子的版本的整数，entry_count是给出下表中的条目的数量的整数，mdat_identifier是用于标识该文件或如dref盒子所指示的另一文件中包含的mdat盒子的32比特整数，chunk_offset是32或64比特整数，给出块的开始放入其包含媒体文件中的偏移。
在下文中，提供了当在ISOBMFF文件中使用碎片化时如何指示相对于MediaDataBox的轨道运行偏移的示例。首先，将描述盒子的一些示例。
根据实施例，可以如下描述TrackFragmentBox：
Box Type:‘traf’(盒子类型：“traf”)
Container:Movie Fragment Box('moof')(容器：电影碎片盒(‘moof’))
Mandatory:No(强制：否)
Quantity:Zero or more(数量：零或更多)
在电影碎片中，可以有轨道碎片集，每个轨道零个或更多个。轨道碎片可以包含零个或更多个轨道运行，其可以记录该轨道的连续样本运行。
根据实施例，TrackFragmentBox的语法可以如下：
aligned(8)class TrackFragmentBox extends Box(‘traf’){
}
根据实施例，TrackFragmentHeaderBox可以描述如下：
Box Type:‘tfhd’(盒子类型：‘tfhd’)
Container:Track Fragment Box('traf')(容器：轨道碎片盒(‘traf’))
Mandatory:Yes(强制：是)
Quantity:Exactly one(数量：1个)
每个电影碎片可以向每个轨道添加零个或更多个碎片；并且轨道碎片可以添加零个或更多个连续的样本运行。轨道碎片头部可以设置用于那些样本运行的信息和默认值。
根据实施例，TrackFragmentHeaderBox的语法可以如下：
根据实施例，tf_flags中的比特，诸如第三最低有效比特(例如逐比特逻辑运算的结果(tf_flags&4)非零)可用于通知解析器用于计算偏移的锚点是基于使用mdat_identifier的。例如当tf_flags&0x000004等于0x000004时，它表示没有base_data_offset-present或者如果存在，则应该忽略它，并且默认基本偏移不是moof盒子的开始，即使已信号通知default_base_is_moof标志。
对于TrackRunBox，定义了tr_flags中的比特，其指示使用mdat_identifiers计算偏移。根据实施例，TrackRunBox的语法可以如下：
根据实施例，TrackRunBox的语义如下。参数sample_count指示此运行中添加的样本数以及下表中的行数(行可以为空)，data_offset被添加到轨道碎片头中建立的隐式或显式data_offset，first_sample_flags提供了仅用于此运行的第一样本的标志集，mdat_identifier是用于标识此文件或如dref盒子所指示的另一文件中包含的mdat盒子的32比特整数。
根据实施例，TrackFragmentHeaderBox的语法可以如下：
根据实施例，tf_flags中的比特，例如第三最低有效比特(例如逐比特逻辑运算的结果(tf_flags&4)非零)可用于指示字段mdat_identifier存在于TrackFragmentHeaderBox中，并且偏移，诸如也包含此TrackFragmentHeaderBox的TrackFragmentBox中包含的TrackRunBox中的base_data_offset(如果存在)和data_offset，是相对于所标识的MediaDataBox的数据的第一字节的。例如当tf_flags&0x000004等于0x000004时，它指示存在mdat_identifier，并且偏移是相对于具有标识符等于mdat_identifier的MediaDataBox的数据的开始的。由于在该实施例中TrackRunBox未指示mdat_identifier，因此可能需要该轨道碎片的所有轨道运行驻留在相同的MediaDataBox中。
在下文中，将描述根据实施例可以如何指示相对于所标识的MediaDataBox的项目位置。为了使得能够在MetaBox中进行相同类型的基于MediaDataBox的偏移计算过程，在ItemLocationBox中引入了一种新构造方法。该构造方法例如具有值4并且其语义如下描述。
根据实施例，ItemLocationBox可以描述如下：
Box Type:‘iloc’(盒子类型：‘iloc’)
Container:Meta box(‘meta’)(容器：Meta盒(‘meta’))
Mandatory:No(强制：否)
Quantity:Zero or one(数量：零个或一个)
项目位置盒子可以通过定位其容器、其在该容器内的偏移以及其长度来提供该文件或其他文件中的资源目录。该盒子可以以三个或四个值开始，分别指定在偏移字段、长度字段、base_offset字段和extent_index字段的字节大小。可以从集合{0,4,8}中选择这些值。construction_method字段可以指示项目的“construction method(构造方法)”，如下所示：
i)file_offset：通过通常的绝对文件偏移到在data_reference_index文件中；(construction_method＝＝0)
ii)idat_offset：通过盒子偏移到同一meta盒子中的idat盒子中；既不使用data_reference_index也不使用extent_index字段；(construction_method＝＝1)
iii)item_offset：通过项目偏移到由extent_index字段指示的项目中，该字段仅由该构造方法(当前)使用。(construction_method＝＝2)，
iv)mdat_offset：通过盒子偏移到在相同的或引用的文件中包含的MediaDataBox，(构造方法＝＝4)。
根据实施例，ItemLocationBox的语法可以如下：
然后，ItemLocationBox中的字段extent_index可以保持项目所在的MediaDataBox的唯一mdat_identifier值；extent_offset可用于提供从启动该项目的MediaDataBox的开始的字节偏移。
在下文中，将根据实施例描述URL碎片生成的示例实现。为了便于寻址URL碎片中的盒子，可以实现对ISOBMFF的URL碎片方案的以下添加。#box_id＝<4cc string>是指用4cc(四字符代码)字符串例如“ftyp”标识的唯一盒子。注意，可以等效地使用另一预定义的关键字而不是关键字box_id。#box_id＝<4cc string>/
根据实施例，为了通过一个请求请求若干资源，诸如若干盒子，可以指定URL碎片束。例如通过在URL碎片项目之间包括指定的分隔符(例如逗号)，可以在URL的碎片部分中包括多个URL碎片项目。例如，#box_id＝ftyp,box_id＝meta,box_id＝mdat/398。在另一示例语法中，不需要重复诸如box_id的关键字。例如，#box_id＝ftyp,meta,mdat/398。注意，可以等效地使用另外的分隔符而不是逗号字符(',')。
在实施例中，URL碎片方案被定义为指示段的所有盒子(如动态适应性流传输上下文中所理解的，例如MPEG-DASH)，段的MediaDataBox除外。除MediaDataBox之外的段的盒子可以包括例如'styp'(Segment Type盒子)、SegmentIndexBox('sidx')、SubsegmentIndexBox('ssix')、MovieFragmentBox('moof)、和/或ProducerReferenceTimeBox('prft')。例如可以使用关键字seghdr，但是注意，可以等效地使用另一预定义的关键字而不是关键字seghdr。URL碎片#seghdr解析为由URL(包含URL碎片)的方案名称和层次结构部分标识的段的段相关盒子。
在实施例中，URL碎片方案被定义为指示携带媒体数据的段的所有盒子。例如可以使用关键字segpayload，但是注意，可以等效地使用另一预定义的关键字而不是关键字segpayload。URL碎片#segpayload解析为传送由URL(包含URL碎片)的方案名称和层次部分标识的段的媒体数据的盒子。
根据实施例，服务器解析具有如上所述标识盒子的URL碎片的URL，通过在作为对URL请求的响应而提供的资源或文件中仅包括那些标识的盒子。例如#box_id＝
在实施例中，播放器或类似物获得MovieBox(例如通过HTTP GET请求，该HTTP GET请求具有包含寻址MovieBox的URL碎片)。播放器或类似物解析MovieBox并解析来自DataReferenceBox的外部数据引用以及指向同样包含MovieBox的文件内的MediaDataBox的内部数据引用。播放器可以获得文件级MetaBox，例如当知道或推断出该文件包含图像项目时。播放器或类似物确定其目的所需的媒体数据。例如播放器或类似物可以从文件级MetaBox确定哪个(哪些)图像项目适合于其目的。在另一示例中，播放器或类似物可以从MovieBox确定哪个(哪些)轨道适合于其目的。然后，播放器或类似物确定其目的所需的媒体数据需要哪些外部数据引用和/或MediaDataBox。在实施例中，内容封装器或类似物包括或关联于DataReferenceBox或与媒体数据相关联的URL碎片。在实施例中，播放器或类似物解析与来自DataReferenceBox或相关联的盒子的媒体数据相关联的URL碎片，并使用从DataReferenceBox获得的文件名或URL以及URL碎片。在实施例中，播放器或类似物使用URL(如从DataReferenceBox解析的)获取外部引用而没有碎片部分。
在下文中，根据实施例，将更详细地描述使用具有用于选择性图像提取的图像容器文件的URL碎片。
HTML5.1提供了用于指示图像的不同版本或替代方案的特征，以使网络浏览器能够例如基于其编码格式和/或显示窗口的宽度选择适当的图像。更具体地，图片元素可以囊括相同图像的若干版本，浏览器可以从中选择最适合其需要的版本，例如观看区域的分辨率和所支持的编解码器。根据实施例，内容创作(例如HTML页面创作)以如下方式执行：利用URL碎片宣布相同容器文件的图像项目或图像项目束可用于获取。例如可以使用HTML5.1(或更高版本)的图片元素。下面提供具有可用的相同文件的不同项目的图片元素的HTML5.1代码的一部分的示例。在该示例中，ID为398的MediaDataBox('mdat')包含用于小显示窗口宽度(小于或等于1024像素)的图像，而具有ID 399的MediaDataBox包含用于较大窗口宽度的图像。
在实施例中，浏览器或类似物基于图像的描述(例如上面的代码中的媒体查询部分)从图片元素中选择图像。图像URL可以包括如上所述的碎片部分，例如列出符合HEIF格式所需的盒子。
在下文中，根据实施例，将更详细地描述关于以内容表盒子形式的文件级盒子序列的信息的示例实现。
为了能够在文件的根级别对盒子进行唯一标识，包括下面提议的盒子的每个盒子可以列在具有四字符代码“rbsq”的新指定盒子中。'rbsq'中盒子的列表应与文件中存储的顺序完全相同。在编辑文件时(例如通过删除或添加根级别盒子)，还应修改该盒子以考虑所编辑文件的新布局。
Box Type：‘rbsq’(盒子类型：“rbsq”)
Container:File(容器：文件)
Mandatory:yes for a file branded as reorderable(强制：对标为可重新排序的文件，是)
Quantity:only one(数量：只有一个)
根据实施例，RootBoxSequence的语义如下。box_4cc是放置在文件的根级别的盒子的四字符代码值，ext_flags表示为盒子提供了哪些附加信息，box_id是32比特无符号整数，向盒子提供具有四字符代码值box_4cc的唯一id(在包含文件内)。
在下文中，参考图3a和3b的装置以及图4a和4b的流程图更详细地描述了一些示例实施例。根据示例实施例，装置700可以接收或以其他方式获得媒体数据720，用于从媒体数据生成一个或多个容器文件(图4a中的方框750)。媒体数据可以包括一个或多个媒体数据单元。每个媒体数据单元可以涉及视频、音频、图像或其他媒体数据(例如文本)。装置700可以具有文件编辑器702或用于获得和/或生成容器文件722的其他装置。文件编辑器702可以包括容器文件722中的一个或多个媒体数据单元，或者文件编辑器702可以包括对容器文件722中的一个或多个媒体数据单元的引用。该引用例如可以包括标识包含一个或多个媒体数据单元的文件或资源的URN(统一资源名称)或URL(统一资源定位符)。所述文件或资源可以驻留在与容器文件722相同或不同的存储系统、大容量存储器和/或装置中。
装置700的文件编辑器702或一些其他装置可以进一步检查752是否使用起自MediaDataBox(754)的开头或起自数据源指针(755)的偏移并且包括关于偏移的计算原理的指示758，并且如果偏移是相对于MediaDataBox计算的，则偏移信息也可以包括756到包含ChunkOffsetBox的文件或关于偏移的另一实体中。当相对于MediaDataBox计算偏移时，也可以构造TrackRunBoxes，使得它们包含MediaDataBox的标识符。
上述数据源指针可以是例如文件的开头、MovieFragmentBox的开头、项目数据盒子中的数据的开头、或者起自所引用的项目数据的开头。
容器文件722和其他信息可以存储在存储器706和/或某些其他存储位置中，和/或容器文件722可以被发送到另一设备，例如用于存储、分解和回放。
根据实施例，文件读取器710(图3b)或播放器可以执行以下操作以分解来自容器文件722的媒体数据。文件读取器710可以包括文件分解器712，其可以检查772、774是否已相对于MediaDataBox计算了关于所接收文件的偏移。如果是，则文件分解器712可以读取关于MediaDataBox的标识的信息和偏移信息，以正确地计算777媒体数据的位置，并重构778文件中接收的媒体。如果尚未相对于MediaDataBox计算偏移但是相对于文件的开头计算了偏移，则文件分解器712可以计算776媒体数据相对于文件的开头的位置，并重构778在文件中接收的媒体。
当装置(700、710或类似装置)例如使用URI或URN访问除容器文件之外的文件或资源并且所述文件或资源不与容器文件驻留在相同的装置中时，可以例如使用诸如有线、无线(例如WLAN)和/或移动(例如GSM、3G和/或LTE/4G)连接的网络连接来执行访问。
在图5中，示出了超文本传输协议(HTTP)流传输系统中包括的一些功能块、格式和接口的示例说明。文件封装器100将媒体呈现的媒体比特流作为输入。比特流可能已经被封装在一个或多个容器文件102中。比特流可以在由一个或多个媒体编码器创建时由文件封装器100接收。文件封装器将媒体比特流转换为一个或多个文件104，其可以由诸如HTTP流传输服务器的流传输服务器110处理。根据服务器文件格式来格式化文件封装器的输出106。HTTP流传输服务器110可以从诸如HTTP流传输客户端的流传输客户端120接收请求。根据例如超文本传输协议，所述请求可以包括在一个或多个消息中，例如作为GET请求消息。该请求可以包括指示所请求的媒体流的地址。该地址可以是所谓的统一资源定位符(URL)。HTTP流传输服务器110可以通过将所请求的媒体文件和诸如元数据文件的其他信息发送到HTTP流传输客户端120来响应该请求。在一些情况下，HTTP流传输客户端120然后可以将媒体文件转换为适合于由HTTP流传输客户端和/或媒体播放器130回放的文件格式。在其他情况下，所接收的媒体文件适合于在没有转换的情况下回放，并且HTTP流传输客户端120可以提供媒体文件以进行回放(例如通过媒体播放器130)。所提供的用于回放的媒体数据文件也可以存储在存储器140和/或另一种存储介质中。HTTP流传输客户端和/或媒体播放器可以包括或可操作地连接到一个或多个媒体解码器，其可以将在HTTP响应中包含的比特流解码为可以呈现的格式。
HTTP流传输服务器
HTTP流传输服务器110将媒体呈现的一个或多个文件作为输入。输入文件根据服务器文件格式进行格式化。HTTP流传输服务器110通过将媒体封装在HTTP响应中来响应来自HTTP流传输客户端120的HTTP请求112。HTTP流传输服务器输出并传输根据传输文件格式格式化的并封装在HTTP响应中的媒体呈现的一个文件或多个文件。
根据实施例，HTTP流传输服务器110可以粗略地分类为三个类。第一类是Web服务器，也称为HTTP服务器，处于“静态”模式。在该模式中，HTTP流传输客户端120可以请求要完全或部分地传输可以根据服务器文件格式格式化的呈现的一个或多个文件。服务器不需要以任何方式准备内容。相反，内容准备是由单独的实体可能提前离线完成的。图6a示出了作为HTTP流传输服务器的web服务器的示例。内容提供商300可以向内容准备310提供内容以及向服务/内容通告服务320通告该内容。可以包含HTTP流传输客户端120的用户设备330可以从服务/内容通告服务320接收关于通告的信息，其中用户设备330的用户可以选择用于接收的内容。服务/内容通告服务320可以提供web界面，因此用户设备330可以通过用户设备330中的web浏览器选择用于接收的内容。替代地或另外地，服务/内容通告服务320可以使用其他手段和诸如广播电视系统的服务广告协议(SAP)、真正简单聚合(RSS)协议或电子服务指南(ESG)机制之类的协议。用户设备330可以包含服务/内容发现元件332，以接收与服务/内容有关的信息，并且例如将该信息提供给该用户设备的显示器。然后，流传输客户端120可以与web服务器340通信，以向web服务器340通知用户已选择用于下载的内容。Web服务器340可以从内容准备服务310获取内容并将内容提供给HTTP流传输客户端120。
第二类是与动态流传输服务器可操作地连接的(常规)web服务器，如图6b所示。动态流传输服务器410基于来自客户端420的请求动态地将流传输的内容定制到客户端420。HTTP流传输服务器430解释来自客户端420的HTTP GET请求，并从给定内容中标识所请求的媒体样本。然后，HTTP流传输服务器430定位在内容文件中或来自实况流的所请求的媒体样本。然后，它提取并将所请求的媒体样本包封在容器440中。随后，新形成的具有媒体样本的容器被传递到HTTP GET响应主体中的客户端。
图6a和6b中的第一接口“1”基于HTTP协议并且定义HTTP流传输请求和响应的语法和语义。HTTP流传输请求/响应可以基于HTTP GET请求/响应。
图6b中的第二接口“2”使得能够访问内容传递描述。内容传递描述(也可以称为媒体呈现描述)可以由内容提供商450或服务提供商提供。它给出了关于访问相关内容的装置的信息。特别是，它描述了内容是否经由HTTP Streaming可访问以及如何执行访问。内容传递描述通常经由HTTP GET请求/响应来检索，但也可以通过其他方式传达，例如使用SAP、RSS或ESG。
图6b中的第三接口“3”表示公共网关接口(CGI)，其是Web服务器和动态内容创建服务器之间的标准化的且广泛部署的接口。其他接口(例如代表性状态转移(REST)接口也是可能的，并且可以构建更多缓存友好的资源定位器。
公共网关接口(CGI)定义了Web服务器软件如何将网页的生成委托给控制台应用程序。这些应用程序称为CGI脚本；虽然经常使用脚本语言，但它们可以用任何编程语言编写。Web服务器的一个任务是通过分析请求的内容、确定要响应地发送的适当文档、以及将文档提供给客户端，来响应客户端(通常是Web浏览器)发出的对Web页面的请求。如果请求标识磁盘上的文件，则服务器可以返回文件的内容。替代地，可以动态地组合文档的内容。一种方法是让控制台应用程序计算文档的内容，并通知Web服务器使用该控制台应用程序。CGI指定在Web服务器和这样的控制台应用程序之间传递哪些信息，以及如何传递。
代表性状态转移是一种用于分布式超媒体系统(如万维网(WWW))的软件架构。REST风格的架构由客户端和服务器组成。客户端向服务器发起请求；服务器处理请求并返回适当的响应。请求和响应是围绕“资源”的“表示”的转移而构建的。资源本质上可以是任何可以寻址的相干且有意义的概念。资源的表示可以是捕获资源的当前或预期状态的文档。在任何特定时间，客户端可以在应用程序状态之间或在休息时进行转换。处于休息状态的客户端能够与其用户进行交互，但不会创建任何负载，并且不会在服务器集或网络上消耗每客户端存储设备。客户端可以在准备好转换到新状态时开始发送请求。当一个或多个请求未完成时，客户端被视为处于转换状态。每个应用程序状态的表示包含下次可以使用的客户端选择用以启动新状态转换的链接。
根据该示例分类的第三类HTTP流传输服务器是动态HTTP流传输服务器。否则类似于第二类，HTTP服务器和动态流传输服务器形成单个组件。此外，动态HTTP流传输服务器可以是保持状态。
服务器端解决方案可以在两种操作模式下实现HTTP流传输：静态HTTP流传输和动态HTTP流传输。在静态HTTP流传输的情况下，内容是预先准备的或独立于服务器的。服务器不会修改媒体数据的结构以满足客户的需求。“静态”模式下的常规Web服务器只能在静态HTTP流传输模式下运行。在动态HTTP流传输的情况下，内容准备在接收到非缓存请求时在服务器上动态完成。与动态流传输服务器和动态HTTP流传输服务器可操作地连接的常规web服务器可以在动态HTTP流传输模式下操作。
在示例实施例中，传输文件格式可以粗略地分类为两类。在第一类中，传输的文件与可用于文件回放的现有文件格式兼容。例如传输的文件与ISO基础媒体文件格式或3GPP文件格式的渐进式下载配置文件兼容。
在第二类中，传输的文件类似于根据用于文件回放的现有文件格式格式化的文件。例如传输的文件可以是服务器文件的碎片，其可能不是用于单独播放的自包含的。在另一种方法中，要传输的文件与可用于文件回放的现有文件格式兼容，但是仅部分地传输文件，因此这些文件的回放需要管理部分文件的意识和能力。
通常可以转换传输的文件以符合用于文件回放的现有文件格式。
HTTP缓存
HTTP缓存150(图5)可以是常规的web缓存，其存储HTTP请求和对请求的响应以减少带宽使用、服务器负载和感知的滞后。如果HTTP缓存包含特定的HTTP请求及其响应，则它可以为请求者而不是HTTP流传输服务器提供服务。
HTTP流传输客户端
HTTP流传输客户端120接收媒体呈现的文件。HTTP流传输客户端120可以包含或可以操作地连接到媒体播放器130，媒体播放器130解析文件、解码所包括的媒体流并呈现所解码的媒体流。媒体播放器130还可以存储所接收的文件以供进一步使用。互换文件格式可用于存储。
在一些示例实施例中，HTTP流传输客户端可以粗略地分类为至少以下两类。在第一类中，传统的渐进式下载客户端猜测或推断出用于正在接收的数字媒体文件的合适缓冲时间，并在该缓冲时间之后开始媒体渲染。传统的渐进式下载客户端不创建与媒体呈现的比特率适配有关的请求。
在第二类中，活动HTTP流传输客户端监视HTTP流传输客户端中的呈现的缓冲状态，并且可以创建与比特率适配有关的请求，以便保证呈现的渲染而没有中断。
HTTP流传输客户端120可以将所接收到的根据传输文件格式格式化的HTTP响应有效载荷转换为根据互换文件格式格式化的一个或多个文件。转换可以在接收到HTTP响应时发生，即，一旦接收到HTTP响应，就将HTTP响应写入媒体文件。替代地，当已接收到多个HTTP响应直到针对流会话的所有HTTP响应时，可以发生转换。转换可以例如包括将初始化段放置在互换文件的开头，随后是接收的HTTP响应有效载荷的顺序级联。
互换文件格式
在一些示例实施例中，可以将互换文件格式粗略地分类为至少以下两类。在第一类中，接收的文件根据传输文件格式如此存储。
在第二类中，根据用于文件回放的现有文件格式存储接收的文件。
媒体文件播放器
媒体文件播放器130可以解析、验证、解码和渲染所存储的文件。媒体文件播放器130可以有能力解析、验证、解码和渲染互换文件中的任一类或两类。如果媒体文件播放器130可以解析和播放根据现有文件格式存储的文件但是可能不播放根据传输文件格式存储的文件，则媒体文件播放器130被称为传统播放器。如果媒体文件播放器130可以解析和播放根据传输文件格式存储的文件，则将其称为HTTP流感知播放器。
在一些实现中，HTTP流传输客户端仅接收并存储一个或多个文件但不播放它们。相反，媒体文件播放器在接收和存储这些文件时对其进行解析、验证、解码和渲染。
在一些实现中，HTTP流传输客户端120和媒体文件播放器130是不同设备或驻留在不同设备中。在一些实现中，HTTP流传输客户端120通过网络连接(例如无线局域网(WLAN)连接)将根据互换文件格式格式化的媒体文件发送到播放该媒体文件的媒体文件播放器130。媒体文件可以在将接收的HTTP响应转换为媒体文件的过程中正在创建该媒体文件的同时发送。替代地，媒体文件可以在将接收的HTTP响应转换为媒体文件的过程中完成该媒体文件之后发送。媒体文件播放器130可以在接收媒体文件时对其进行解码和播放。例如媒体文件播放器130可以使用来自HTTP流传输客户端的HTTP GET请求逐步下载媒体文件。替代地，媒体文件播放器130可以在完全接收到媒体文件之后对其进行解码和播放。
HTTP流水线技术是一种其中多个HTTP请求被写入单个套接字而无需等待相应响应的技术。由于可以在诸如传输控制协议(TCP)分组的相同传输分组中容纳若干HTTP请求，因此HTTP流水线技术允许通过网络发送更少的传输分组，这可以减少网络负载。
可以通过服务器IP地址、服务器端口号、客户端IP地址和客户端端口号的四元组来标识连接。从同一客户端到同一服务器的多个同时TCP连接是可能的，因为每个客户端进程被分配了不同的端口号。因此，即使所有TCP连接都访问相同的服务器进程(例如专用于HTTP的端口80处的Web服务器进程)，它们都具有不同的客户端套接字并表示唯一的连接。这使得能够从同一台计算机同时向同一网站发出多个请求。
多媒体格式的分类
多媒体容器文件格式是在多媒体内容产生、操纵、传输和消费链中使用的元素。编码格式(也称为基本流格式)和容器文件格式之间可以有实质性差异。编码格式涉及将内容信息编码成比特流的特定编码算法的动作。容器文件格式包括以如下方式组织所生成的比特流的方式：它可以被访问以进行本地解码和重放、被作为文件传输或流传输，所有这些都利用各种存储和传输架构。此外，文件格式可以促进媒体的互换和编辑以及将接收的实时流记录到文件。
图7是可以在其中实现各种实施例的通用多媒体通信系统的示例的图形表示。如图7所示，数据源1500以模拟、未压缩数字或压缩数字格式或这些格式的任何组合提供源信号。编码器1510将源信号编码为编码媒体比特流。应当注意，可以直接或间接地从位于几乎任何类型的网络内的远程设备接收要解码的比特流。另外，可以从本地硬件或软件接收比特流。编码器1510可以有能力编码多于一种媒体类型，例如音频和视频，或者可能需要不止一个编码器1510来编码不同媒体类型的源信号。编码器1510还可以获得合成产生的输入，例如图形和文本，或者它可以有能力产生合成媒体的编码比特流。在下文中，仅考虑处理一种媒体类型的一个编码媒体比特流以简化描述。然而，应该注意，通常实时广播服务包括若干流(通常至少一个音频、视频和文本子标题流)。还应注意，系统可以包括许多编码器，但在图7中，仅示出一个编码器1510以简化描述而不缺乏一般性。应当进一步理解，尽管本文包含的文本和示例可以具体描述编码过程，但是本领域技术人员将理解，相同的概念和原理也适用于相应的解码过程，反之亦然。
编码媒体比特流被传送到存储器1520。存储器1520可以包括任何类型的大容量存储器以存储编码媒体比特流。存储器1520中的编码媒体比特流的格式可以是基本自包含比特流格式，或者一个或多个编码媒体比特流可以被封装到容器文件中。一些系统“直播(live)”操作，即省略存储并从编码器1510向发送器1530直接传送编码媒体比特流。然后根据需要将编码媒体比特流传送到发送器1530，也称为服务器。传输中使用的格式可以是基本自包含比特流格式、分组流格式，或者一个或多个编码媒体比特流可以封装到容器文件中。编码器1510、存储器1520和发送器1530可以驻留在相同的物理设备中，或者它们可以包括在分开的设备中。编码器1510和发送器1530可以操作直播实时内容，在这种情况下，编码媒体比特流通常不是永久存储的，而是在内容编码器1510和/或发送器1530中缓冲一小段时间以平滑处理延迟、传输延迟和编码媒体比特率的变化。
发送器1530使用通信协议栈发送编码媒体比特流。堆栈可以包括但不限于实时传输协议(RTP)、用户数据报协议(UDP)和因特网协议(IP)。当通信协议栈是面向分组的时，发送器1530将编码媒体比特流封装成分组。例如当使用RTP时，发送器1530根据RTP有效载荷格式将编码媒体比特流封装到RTP分组中。通常，每种媒体类型都具有专用RTP有效载荷格式。应该再次注意，系统可以包含多于一个发送器1530，但是为了简单起见，以下描述仅考虑一个发送器1530。
如果媒体内容被封装在容器文件中用于存储器1520或用于将数据输入到发送器1530，则发送器1530可以包括或可操作地附连到“发送文件解析器”(图中未示出)。特别地，如果容器文件不是这样传输的，但是至少一个所包含的编码媒体比特流被封装以便通过通信协议传输，则发送文件解析器定位编码媒体比特流的适当部分以通过通信协议传送。发送文件解析器还可以帮助创建用于通信协议的正确格式，例如分组报头和有效载荷。多媒体容器文件可以包含封装指令，例如ISO基础媒体文件格式中的提示轨道，用于在通信协议上该至少一个所包含的媒体比特流的封装。
发送器1530可以或可以不通过通信网络连接到网关1540。网关1540可以执行不同类型的功能，例如根据一个通信协议栈将分组流转换到另一通信协议栈、合并和分叉数据流、以及根据下行链路和/或接收器能力操纵数据流，例如根据主要的下行链路网络条件控制所转发的流的比特率。网关1540的示例包括MCU、电路交换和分组交换视频电话之间的网关、无线一键通(PoC)服务器、手数字视频广播持式(DVB-H)系统中的IP封装器或将广播传输本地转发到家庭无线网络的机顶盒。当使用RTP时，网关1540被称为RTP混合器或RTP转换器，并且通常用作RTP连接的端点。
该系统包括一个或多个接收器1550，通常能够接收、解调发送的信号并解封装成编码媒体比特流。编码媒体比特流被传送到记录存储器1555。记录存储器1555可以包括任何类型的大容量存储器以存储编码媒体比特流。记录存储器1555可以替代地或附加地包括计算存储器，例如随机存取存储器。记录存储器1555中的编码媒体比特流的格式可以是基本自包含比特流格式，或者一个或多个编码媒体比特流可以封装到容器文件中。如果有彼此相关联的多个编码媒体比特流，例如音频流和视频流，则通常使用容器文件，并且接收器1550包括或附连到容器文件生成器，该容器文件生成器从输入流产生容器文件。一些系统“直播”操作，即省略记录存储器1555并将编码媒体比特流从接收器1550直接传送到解码器1560。在一些系统中，仅在记录存储器1555中维护所记录的流的最近部分，例如所记录的流的最近的10分钟摘录，而从记录存储器1555中丢弃任何先前记录的数据。
编码媒体比特流从记录存储器1555传送到解码器1560。如果有彼此相关联并封装到容器文件中的许多编码媒体比特流，例如音频流和视频流，文件解析器(图中未示出)用于从容器文件中解封装每个编码媒体比特流。记录存储器1555或解码器1560可以包括文件解析器，或者文件解析器附连到记录存储器1555或者解码器1560。
编码媒体比特流可以由解码器1560进一步处理，解码器1560的输出是一个或多个未压缩媒体流。最后，渲染器1570可以例如利用扬声器或显示器再现未压缩的媒体流。接收器1550、记录存储器1555、解码器1560和渲染器1570可以驻留在相同的物理设备中，或者它们可以被包括在分开的设备中。
图8示出了根据示例实施例的视频编码系统的框图，作为可以并入根据本发明实施例的编解码器的示例性装置或电子设备50的示意性框图。图9示出了根据示例实施例的装置的布局。接下来将说明图8和9中的元件。
电子设备50可以例如是无线通信系统的移动终端或用户设备。然而，应当理解，在可以需要编码和解码、或编码或解码视频图像的任何电子设备或装置内可以实现本发明的实施例。
装置50可以包括用于并入和保护所述设备的壳体30。装置50还可以包括液晶显示器形式的显示器32。在本发明的其他实施例中，显示器可以是适合于显示图像或视频的任何合适的显示技术。装置50还可以包括键区34。在本发明的其他实施例中，可以采用任何合适的数据或用户接口机制。例如用户接口可以实现为虚拟键盘或数据输入系统，作为触敏显示器的一部分。该装置可以包括麦克风36或任何合适的音频输入，其可以是数字或模拟信号输入。装置50还可以包括音频输出设备，在本发明的实施例中，音频输出设备可以是耳机38、扬声器或模拟音频或数字音频输出连接中的任何一个。装置50还可以包括电池40(或者在本发明的其他实施例中，该设备可以由任何合适的移动能量设备供电，例如太阳能电池、燃料电池或发条发电机)。该装置还可以包括能够记录或捕获图像和/或视频的相机42。根据实施例，装置50还可以包括用于与其他设备进行短程视线通信的红外端口。在其他实施例中，装置50还可以包括任何合适的短程通信解决方案，例如蓝牙无线连接或USB/火线有线连接。
装置50可以包括用于控制装置50的控制器56或处理器。控制器56可以连接到存储器58，在本发明的实施例中，存储器58可以以图像和音频数据的形式存储数据和/或可以存储用于在控制器56上实现的指令。控制器56还可以连接到编解码器电路54，编解码器电路54适合于执行音频和/或视频数据的编码和解码，或者协助由控制器56执行的编码和解码。
装置50还可以包括读卡器48和智能卡46，例如UICC和UICC读取器，用于提供用户信息并且适合于提供用于在网络上对用户进行认证和授权的认证信息。
装置50可以包括无线电接口电路52，其连接到控制器并且适合于生成无线通信信号，例如用于与蜂窝通信网络、无线通信系统或无线局域网进行通信。装置50还可以包括连接到无线电接口电路52的天线44，用于将在无线电接口电路52处产生的射频信号发送到其他装置，并用于从其他装置接收射频信号。
根据实施例，装置50包括能够记录或检测各个帧的相机，这些帧然后被传递到编解码器54或控制器以进行处理。根据实施例，该装置可以在传输和/或存储之前从另一设备接收视频图像数据以进行处理。根据实施例，装置50可以无线地或通过有线连接接收用于编码/解码的图像。
图10示出了根据示例实施例的用于视频编码的布置，其包括多个装置、网络和网络元件。关于图10，示出了可以利用本发明的实施例的系统的示例。系统10包括可以通过一个或多个网络进行通信的多个通信设备。系统10可以包括有线或无线网络的任何组合，包括但不限于无线蜂窝电话网络(诸如GSM、UMTS、CDMA网络等)、诸如由任一IEEE 802.x标准定义的无线局域网(WLAN)、蓝牙个人区域网络、以太网局域网、令牌环局域网、广域网和因特网。
系统10可以包括适用于实现本发明实施例的有线和无线通信设备或装置50。例如图10中所示的系统示出了移动电话网络11和因特网28的表示。到因特网28的连接可以包括但不限于远程无线连接、短程无线连接和各种有线连接，包括但不限于电话线、电缆线、电力线和类似通信路径。
系统10中示出的示例通信设备可以包括但不限于电子设备或装置50、个人数字助理(PDA)和移动电话14的组合、PDA 16、集成消息传送设备(IMD)18、台式计算机20、笔记本计算机22。装置50可以是静止的或当由正在移动的个人携带时是移动的。装置50还可以位于运输模式，包括但不限于汽车、卡车、出租车、公共汽车、火车、船、飞机、自行车、摩托车或任何类似的合适运输模式。
一些或另外的装置可以发送和接收呼叫和消息，并通过到基站24的无线连接25与服务提供商通信。基站24可以连接到允许移动电话网络11和因特网28之间的通信的网络服务器26。该系统可以包括附加通信设备和各种类型的通信设备。
通信设备可以使用各种传输技术进行通信，包括但不限于码分多址(CDMA)、全球移动通信系统(GSM)、通用移动电信系统(UMTS)、时分多址(TDMA)、频分多址(FDMA)、传输控制协议-因特网协议(TCP-IP)、短消息服务(SMS)、多媒体消息服务(MMS)、电子邮件、即时消息服务(IMS)、蓝牙、IEEE 802.11和任何类似的无线通信技术。涉及实现本发明的各种实施例的通信设备可以使用各种媒体进行通信，包括但不限于无线电、红外线、激光、电缆连接和任何合适的连接。
在上文中，已经参考ISOBMFF的结构和概念描述了一些实施例。需要理解的是，实施例可以类似地用其他容器文件格式实现，例如Matroska或其衍生物。可以参考类似于ISOBMFF的数据结构(例如盒子)来类似地实现实施例。
在上文中，已经参考相对于特定MediaDataBox的短语偏移或类似短语来描述了一些实施例。另一方面，已经更明确地描述了一些实施例，以通过将偏移添加到MediaDataBox内的媒体有效载荷数据的开头来导出由偏移指向的位置。而且，已经描述了一些其中偏移是相对于MediaDataBox的开始的实施例。需要理解的是，当偏移的引用点是MediaDataBox的开头(MediaDataBox的盒子头部的第一字节)、MediaDataBox的盒子数据的开头(在一些实施例中其可以指向MediaDataBox的标识符)、或MediaDataBox内的媒体数据的开头(在一些实施例中紧接在MediaDataBox的标识符之后的字节)、或者相对于MediaDataBox的位置的任何预定义或指示的位置时，可以类似地实现实施例。
在上文中，已经参考如ISOBMFF中定义的MediaDataBox描述了一些实施例。需要理解的是，一些实施例可以用其他盒子类型类似地实现。例如对于其他盒子类型，可以类似地实现用于或基于MediaDataBox的标识符的实施例。还需要理解的是，可以用用于媒体数据的其他容器结构类似地实现实施例。例如可以规定一种具有与MediaDataBox不同的四字符代码的新盒子类型，以包含mdat_identifier或类似物，然后随有媒体数据。
在上文中，已经关于HTTP和HTTP/1.1描述了一些实施例。需要理解的是，实施例不限于使用HTTP，而是可以替代地或另外地使用其他协议，例如WebSocket、或HTTP的其他版本，例如HTTP/2。
在上文中，已经参考DASH的格式和概念描述了一些实施例。需要理解的是，可以利用其他流传输和传送系统和机制来类似地实现实施例，例如HTTP直播流传输(LiveStreaming)(如IETF Internet Draft draft-pantos-http-live-streaming中所定义的)或MPEG媒体传输(Media Transport)(MMT，作为ISO/IEC 23008的一部分指定)。
在上文中，已经参考文件描述了一些实施例。需要理解的是，同样可以参考文件段来描述实施例，例如DASH中定义的段或子段，或者例如所理解的作为对HTTP GET请求的响应而被接收的资源。
在上文中，已经参考HTML 5.1的特征描述了一些实施例，例如当涉及通过URL碎片方案宣布存储在同一容器文件中的多个替代图像的可用性时。需要理解的是，可以使用其他方案类似地实现实施例，由此使用URL碎片方案或类似方案。例如实施例可以利用同步媒体集成语言(SMIL)。
本发明的实施例可以用软件、硬件、应用逻辑或软件、硬件和应用逻辑的组合来实现。在示例实施例中，应用逻辑、软件或指令集在各种传统计算机可读介质中的任何一个上维护。在本文档的上下文中，“计算机可读介质”可以是能够包含、存储、传递、传播或传输指令以供指令执行系统、装置或设备(例如计算机，图8和9中描述和描绘了计算机的一个示例)使用或与之结合使用的任何介质或装置。计算机可读介质可以包括计算机可读存储介质，其可以是可以包含或存储指令以供指令执行系统、装置或设备(例如计算机)使用或与之结合使用的任何介质或装置。
如果需要，本文讨论的不同功能可以以不同顺序执行和/或彼此同时执行。此外，如果需要，上述功能中的一个或多个可以是可选的或可以组合的。
通常，本发明的各种实施例可以用硬件或专用电路、软件、逻辑或其任何组合来实现。例如一些方面可以用硬件实现，而其他方面可以用固件或可以由控制器、微处理器或其他计算设备执行的软件实现，但是本发明不限于此。虽然本发明的各个方面可以被示出和描述为框图、流程图或使用一些其他图形表示，但是应当充分理解，本文描述的这些方框、装置、系统、技术或方法可以作为非限制性示例在硬件、软件、固件、专用电路或逻辑、通用硬件或控制器或其他计算设备、或其某种组合中实现。
本发明的实施例可以由可由移动设备的数据处理器(例如在处理器实体中)执行的计算机软件或通过硬件或通过软件和硬件的组合实现。此外，在这方面，应该注意，如附图中的逻辑流程的任何方框可以表示程序步骤、或互连的逻辑电路、方框和功能，或程序步骤和逻辑电路、方框和功能的组合。软件可以存储在诸如存储器芯片或者在处理器内实现的存储器块的物理介质、诸如硬盘或软盘之类的磁介质、以及诸如DVD及其数据变体CD的光学介质上。
本发明的各种实施例可以借助于驻留在存储器中并使相关装置执行本发明的计算机程序代码来实现。例如，终端设备可以包括用于处理、接收和发送数据的电路和电子设备、存储器中的计算机程序代码、以及当运行计算机程序代码时使终端设备执行实施例的特征的处理器。此外，网络设备可以包括用于处理、接收和发送数据的电路和电子设备、存储器中的计算机程序代码、以及当运行计算机程序代码时使网络设备执行实施例的特征的处理器。
存储器可以是适合于本地技术环境的任何类型，并且可以使用任何适合的数据存储技术来实现，诸如基于半导体的存储器设备、磁存储器设备和系统、光学存储器设备和系统、固定存储器和可移除存储器。数据处理器可以是适合于本地技术环境的任何类型，并且可以包括通用计算机、专用计算机、微处理器、数字信号处理器(DSP)和基于多核处理器架构的处理器中的一个或多个，作为非限制性例子。
可以在诸如集成电路模块的各种组件中实践本发明的实施例。集成电路的设计基本上是高度自动化的过程。复杂且功能强大的软件工具可用于将逻辑级设计转换为准备在半导体衬底上蚀刻和形成的半导体电路设计。
程序，例如由加利福尼亚州山景城的Synopsys公司和加利福尼亚州圣何塞的Cadence Design公司提供的程序，使用完善的设计规则以及预先存储的设计模块库自动路由导体并在半导体芯片上定位组件。一旦完成半导体电路的设计，就可以将标准化电子格式(例如Opus、GDSII等)的所得设计传输到半导体制造设施或“fab”以进行制造。
前面的描述通过示例性和非限制性示例提供了对本发明示例性实施例的完整的和信息性的描述。然而，当结合附图和所附权利要求阅读时，鉴于前面的描述，各种修改和调整对于相关领域的技术人员而言将变得显而易见。然而，对本发明的教导的所有这些和类似的修改仍将落入本发明的范围内。
下面将提供一些示例。
提供了一种方法，包括：
接收包括媒体数据结构中的至少一个元数据单元的容器文件；
接收偏移数据；
确定所述偏移数据是相对于所述容器文件中所述媒体数据结构的位置的；以及
如果所述检查显示所述偏移数据是相对于所述媒体数据结构的位置的，则使用所述偏移数据作为对所述媒体数据结构的位置的引用以获得所述媒体数据单元。
在实施例中，该方法还包括：
接收所述媒体数据结构的标识符，所述标识符与所述偏移数据相关联；以及
基于所述标识符从所述容器文件中选择所述媒体数据结构。
在实施例中，该方法还包括：
接收所述媒体数据结构内的第二标识符；以及
基于所述标识符等于所述第二标识符，从所述容器文件中选择所述媒体数据结构。
在实施例中，该方法还包括：
将所述偏移数据与到所述容器文件中包括的数据引用列表的数据引用索引相关联；
使用所述数据引用索引从所述数据引用列表中选择数据引用，所选择的数据引用包括所述媒体数据结构的标识符。
在实施例中，该方法还包括：
在包含所述偏移数据的数据结构中接收所述标识符。
在该方法的实施例中，所述至少一个媒体数据单元是轨道的样本，所述轨道包括按解码顺序的样本序列。
在该方法的实施例中，所述至少一个媒体数据单元是不与解码顺序相关联的项目。
在该方法的实施例中，所述偏移数据是相对于所述媒体数据结构的开始的，其中该方法还包括：
使用所述偏移数据和所述媒体数据结构的开头的位置来获得所述媒体数据单元。
在该方法的实施例中，所述容器文件包括所述媒体数据的两个或更多个子集，其中该方法还包括：
向服务器请求所述两个或更多个子集中所述媒体数据的子集。
在实施例中，该方法还包括：
接收包含偏移的第一媒体文件格式盒子，所述第一媒体文件格式盒子与包含寻址数据的第二媒体文件格式盒子相关联；
接收所述第二媒体文件格式盒子；以及
使用来自所述第一媒体文件格式盒子的偏移数据从所述第二媒体文件格式盒子获得所述媒体数据单元。
在第二示例中，提供了一种装置，包括至少一个处理器和至少一个存储器，所述至少一个存储器上存储有代码，所述代码当由所述至少一个处理器执行时使得装置执行至少以下内容：
接收包括媒体数据结构中的至少一个元数据单元的容器文件；
接收偏移数据；
确定所述偏移数据是相对于所述容器文件中所述媒体数据结构的位置的；以及
如果所述检查显示所述偏移数据是相对于所述媒体数据结构的位置的，则使用所述偏移数据作为对所述媒体数据结构的位置的引用，以获得所述媒体数据单元。
在所述装置的实施例中，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使装置至少执行以下操作：
接收所述媒体数据结构的标识符，所述标识符与所述偏移数据相关联；以及
基于所述标识符从所述容器文件中选择所述媒体数据结构。
在所述装置的一个实施例中，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
在媒体数据结构中接收第二标识符；以及
基于所述标识符等于所述第二标识符从所述容器文件中选择所述媒体数据结构。
在所述装置的实施例中，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
将所述偏移数据与到所述容器文件中包括的数据引用列表的数据引用索引相关联；
使用所述数据引用索引从所述数据引用列表中选择数据引用，所选择的数据引用包括所述媒体数据结构的标识符。
在所述装置的实施例中，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
在包含所述偏移数据的数据结构中接收所述标识符。
在所述装置的实施例中，其中所述偏移数据是相对于所述媒体数据结构的开始的，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
使用所述偏移数据和所述媒体数据结构的开头的位置来获得所述媒体数据单元。
在所述装置的实施例中，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
接收包含偏移的第一媒体文件格式盒子，所述第一媒体文件格式盒子与包含寻址数据的第二媒体文件格式盒子相关联；
接收所述第二媒体文件格式盒子；以及
使用来自所述第一媒体文件格式盒子的偏移数据从所述第二媒体文件格式盒子获得所述媒体数据单元。
在第三示例中，提供了一种在非暂时性计算机可读介质上实现的计算机程序产品，包括计算机程序代码，所述计算机程序代码被配置为当在至少一个处理器上执行时，使得装置或系统：
接收包括媒体数据结构中的至少一个元数据单元的容器文件；
接收偏移数据；
确定所述偏移数据是相对于所述容器文件中所述媒体数据结构的位置的；以及
如果所述检查显示所述偏移数据是相对于所述媒体数据结构的位置的，则使用所述偏移数据作为对所述媒体数据结构的位置的引用，以获得所述媒体数据单元。
在第四示例中，提供了一种方法，包括：
形成包括媒体数据结构中的至少一个元数据单元的容器文件；
将偏移数据形成到所述容器文件中，作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用；以及
包括所述偏移数据是相对于所述媒体数据结构的位置的指示。
在实施例中，该方法还包括：
在所述容器文件中包括所述媒体数据结构的第一标识符，所述第一标识符与所述偏移数据相关联。
在实施例中，该方法还包括：
在所述容器文件中包括所述媒体数据结构内的所述媒体数据结构的第二标识符，所述第二标识符等于所述第一标识符。
在实施例中，该方法还包括：
在所述容器文件中包括数据引用列表；
在所述数据引用列表内包括数据引用，所述数据引用包括所述第一标识符；
在所述容器文件中，将所述偏移数据与到所述数据引用列表的数据引用索引相关联，所述数据引用索引引用包括所述第一标识符的所述数据引用；
使用所述数据引用索引从所述数据引用列表中选择数据引用，所选择的数据引用包括所述媒体数据结构的标识符。
在实施例中，该方法还包括：
在包含所述偏移数据的数据结构中包括所述第一标识符。
在第五示例中，提供了一种装置，包括至少一个处理器和至少一个存储器，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
形成包括媒体数据结构中的至少一个元数据单元的容器文件；
将偏移数据形成到所述容器文件中，作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用；以及
包括所述偏移数据是相对于所述媒体数据结构的位置的指示。
在所述装置的实施例中，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
在所述容器文件中包括所述媒体数据结构的第一标识符，所述第一标识符与所述偏移数据相关联。
在所述装置的实施例中，所述至少一个存储器上存储有代码，所述代码在由所述至少一个处理器执行时使得装置至少执行以下操作：
在所述容器文件中包括所述媒体数据结构内的所述媒体数据结构的第二标识符，所述第二标识符等于所述第一标识符。
在第六示例中，提供了一种在非暂时性计算机可读介质上实现的计算机程序产品，包括计算机程序代码，所述计算机程序代码被配置为当在至少一个处理器上执行时使得装置或系统：
形成包括媒体数据结构中的至少一个元数据单元的容器文件；
将偏移数据形成到所述容器文件中，作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用；以及
包括所述偏移数据是相对于所述媒体数据结构的位置的指示。
在第七示例中，提供了一种被配置为执行第一示例的方法的装置。
在第八示例中，提供了一种被配置为执行第四示例的方法的装置。
在第九示例中，提供了一种装置，包括：
用于接收包括媒体数据结构中的至少一个元数据单元的容器文件的装置；
用于接收偏移数据的装置；
用于确定所述偏移数据是相对于所述容器文件中所述媒体数据结构的位置的装置；以及
用于如果所述检查显示所述偏移数据是相对于所述媒体数据结构的位置的，则使用所述偏移数据作为对所述媒体数据结构的位置的引用以获得所述媒体数据单元的装置。
在第十示例中，提供了一种装置，包括：
用于形成包括媒体数据结构中的至少一个元数据单元的容器文件的装置；
用于将偏移数据形成到所述容器文件中作为对所述媒体数据单元相对于所述媒体数据结构的位置的引用的装置；以及
用于包括所述偏移数据是相对于所述媒体数据结构的位置的指示的装置。
在第十一示例中，提供了一种方法，包括：
通过第一请求来请求文件的一部分，所述第一请求包括数据结构的标识，所述标识包括类型和标识符，其中所述标识符在相同类型的若干数据结构中标识所述数据结构。
在第十二示例中，提供了一种方法，包括：
接收请求文件的一部分的第一请求，所述第一请求包括数据结构的标识，所述标识包括类型和标识符，其中所述标识符在相同类型的若干数据结构中标识所述数据结构；
推断所述文件的一部分，所述推断包括基于所述类型和所述标识符标识所述数据结构；
通过传输所述文件的一部分来响应所述第一请求。
在实施例中，该方法还包括：
在多个块中逐步传输所述文件的一部分。
在第十三示例中，提供了一种被配置为执行第十一示例的方法的装置。
在第十四示例中，提供了一种被配置为执行第十二示例的方法的装置。
- 媒体封装和解封装
- 用于对定时媒体数据进行封装和解析的方法、装置和计算机程序