本申请涉及支持场景部分或感兴趣区域的特殊处理的视频流传输构思。
背景技术
在使用例如dash(通过http的动态自适应流传输)(http＝超文本传输协议)的视频流传输中，如下情况的数量增加：有利地能够将视频媒体限制到某个场景部分或者优先考虑某个感兴趣的区域。例如，不需要在头戴式显示器应用中发送整个全景视频。相反，仅需要发送与用户所看到的部分有关的场景部分。离开视频流的部分难以形成有效的视频数据流。允许移除视频数据流的某些部分的情况主要限于某些情况，例如移除分层视频流的增强层。然而，这种情况主要涉及由视频数据流所传送的、在比特深度、空间分辨率、时间分辨率等方面的信息量的可缩放性，而不是在场景部分方面的信息量的可缩放性。
此外，能够提供流传输目标(即，客户端)以及在特定视频图像内的感兴趣区域上的提示将是有利的，以便有利地例如预先设置这样的感兴趣区域优先于视频图像中的其它部分。到目前为止，存在执行这种感兴趣区域信令的可能性，但是这些能力受到限制并且对服务器和客户端之间的通信造成压力。
技术实现要素：
因此，本发明的目的是提供一种视频流传输构思，其允许在维持减少的流和原始流之间的一致性的同时流传输特定于场景部分的减少的数据流，并且提供允许发信号通知感兴趣区域的更有效方式的视频流传输构思。
该目的是通过独立权利要求的主题来实现的。
本申请的发明人的发现是：特定于部分的视频数据流可以通过使用文件格式减少与整个场景有关的视频数据流且保存一致性并且包含切片而得到的，其中所述切片中编码了形成所述部分的拼块集合中的拼块，并且被包含到一个或多个源轨道的集合中，使用包括构造指令在内的一个或多个收集轨道的集合，以便通过发信号通知切片的某些部分的替代和/或指示复制切片的某些部分来指示特定于部分的视频数据流的合成。通过这种措施，减少视频数据流以便仅涉及某个场景部分是可行的，然而，通过按照构造指令的指示执行合成，使接收者(即，客户端侧)有机会获得符合特定于部分的视频数据流。
本申请的另一个发现涉及由从视频流传输服务器到客户端的视频流所表示的场景内的感兴趣区域的位置的指示。已经认识到，感兴趣区域的固定位置大多不足以在大多数应用中有利地引导预取或其它优先化构思。因此，视频流伴随有以使得位置在时间上变化的方式指示感兴趣区域的位置的信息。为了保持对服务器/客户端通信的低限制，可以在视频流的五个格式框内传送信息，即在视频流本身内通过sand(服务器和网络辅助的dash)消息来传送，和/或通过以使得信息调度感兴趣区域的位置的即将到来的改变的方式在流传输会话的开始处发起信息的传送来传送。
上述构思的组合是可行的，并且也是随后的描述和从属权利要求的主题。
附图说明
上述构思的有利实施是从属权利要求的主题。下面参考附图描述本申请的优选实施例，在附图中：
图1示意性地示出了根据实施例的服务器、服务器10访问的视频数据流、以及服务器10能够呈现给客户端的流；
图2示意性地示出了适合于图1的服务器的客户端、以及客户端基于其进行合成的入站流和特定于部分的视频数据流的示意图、以及可选地存在的从特定部分的视频数据流中重新构造特定于部分的视频的视频解码器72的示意图；
图3示出了根据实施例的关于某一切片的合成的子处理的示意图；
图4示出了视频解码器的示意图，该视频解码器能够处理图1的服务器可以访问的视频数据流以及由图2的客户端合成的特定于视频的视频数据流，以便说明一致性维持；
图5a至图5b示出了构造指令的示例，该构造指令由指示构造指令的类型的构造函数标签、随后的数据字段长度指示dfl、随后数据字段长度的数据字段组成，从而在图7a的情况下表示例如将替代插入到合成的流中的插入指令的示例，而图7b示出了具有另一构造函数标签的复制指令的示例，构造指令的数据长度具有也由数据字段长度指示符指示的长度，但是构造指令包括参考轨道tri的索引、指令所指的样本或图像或访问单元的指示符(即so)、在由起始点复制的部分的指示中的数据偏移和长度、数据长度；
图5c示意性地示出了图7b的指令的备选方案；
图5e示出了根据第一实施例的构造指令阵列或序列的示意图；
图5d示意性地示出了构造函数阵列的备选方案；
图6示出了视频数据的示意图，该视频数据被概念化以有利地用作关于图1至图4概述的流传输构思的基础；
图7示意性地示出了将场景细分为4×3拼块的示例，其中向客户端提供的部分具有每个拼块均为共同大小的3×2拼块，并且示出了每个拼块源轨道和收集轨道与对应的个体表示的关联，从而以十二个拼块表示和四个收集表示结束；
图8示出了清单或媒体呈现描述文件的示例，媒体呈现描述文件可以用于通过发信号通知公共url模板来减少清单的大小；
图9示出了说明根据实施例的由客户端发起的各个片段取回引导的从服务器到客户端的片段业务的示意图，其中一方面为源轨道提供单独的表示，另一方面为收集轨道提供单独的表示；
图10示出了说明与图9相比的备选方案的示意图，其中收集轨道信息在源轨道的片段内传送；
图11示出了根据传送根据图10的收集轨道的实施例而传送的收集轨道以便说明所得到的冗余；
图12示出了说明在关于对应部分的左上拼块的源轨道表示的片段内传送收集轨道的示意图，以便在考虑图6的示例作为基础时说明所得到的冗余；
图13示出了说明被修改的构造指令的示例的示意图，该构造指令被修改以便包括附加索引字段cidx，该附加索引字段cidx允许包括所示构造指令在内的对应收集轨道是可参数化的，因为构造指令仅在构造指令的cidx与用于为参数化设置的索引相对应的情况下才被执行；
图14示意性地示出了使用如图13所示的可索引构造指令的可参数化收集轨道的示例，其中图14示出了不同参数化设置下的相同可参数化收集轨道，其中，通过环绕，指示可索引构造指令中实际执行的构造指令；
图15示出了显示根据实现时变感兴趣区域指示的实施例的服务器和客户机的示意图；
图16示出了细分为拼块的视频的示意图，以便示出到客户端的特定于部分的视频数据流传输将是有利的示例性使用情况。
具体实施方式
以下关于附图提出的本申请的实施例的描述首先集中于与视频流传输相关的实施例，该视频流传输支持在一致性保存的情况下对特定于部分的视频数据流进行流传输。此后，描述了与roi位置指示相关的实施例。在应用中，两种类型的实施例可以一起使用，以便利用这两个构思。
为了激励和简化对与特定于部分的视频数据流传输相关的实施例的理解，描述了应用场景的示例，其示出了仅希望流传输由视频数据流表示的主场景的一部分的源。关于作为基础视频编解码器的hevc提供该示例，但是关于hevc提供该示例的事实不应被视为暗示本申请和随后说明的实施例将限于hevc。而是，可以使用任何其它视频编解码器作为基础。
可以使用“拼块”构思产生hevc比特流，其破坏图像内预测依赖性(包括熵解码依赖性)。每个拼块可以单独处理，例如，可以由一个处理器/核处理。如果每个拼块包括在不同的切片中，则不同拼块之间没有共享的信息，并且如果接通了则可能仅需要对重新构造的样本进行环路过滤。如果使用拼块，则整个视频以n×m个拼块的矩形图案构造。对于某些使用情况，例如取自大型全景的较小窗口(也称为rol)的呈现，仅需要解码一部分拼块。然而，首先必须以这样的方式对hevc比特流进行编码：以使得图像的拼块不是根据先前图像的不同拼块预测而来的这样的方式，来约束帧间预测。即使满足这些约束，如果比特流中的与拼块的选择相对应的那些部分被连接，而比特流的不需要的部分被移除，则得到的比特流可能不再是符合的hevc比特流。
在图16所示的示例中，示出了对于所选择的rol(如图中的矩形960所示的宽度)，拼块子集是通过由九个拼块组成来提取的(hevc规范方面的拼块集合)。在图16中，九个拼块是指示cu地址100、110、120、200、210、220、300、310和320的那些拼块。提取的hevc比特流无效，因为提取的部分的cuaddr不从0开始(这意味着提取的部分不包含等于1的first_slice_segment_in_pic_flag的切片)，并且一些cuaddr和对应的数据现在丢失，即cu地址从一个拼块行到另一拼块行时不是从拼块接拼块地连续的。显然，这取决于选择哪些拼块，例如，如果省略最左边的顶部拼块，则其余的拼块不能形成符合的hevc比特流。
除了关于cu地址空间的所述问题之外，还需要产生附加的参数(例如pps、sps、vps)或sei消息以匹配所提取的比特流的特性(即，rol包括比整个hevc比特流少的拼块)。
也就是说，关于图16的上述描述清楚地表明，在移除视频数据流的部分以便获得特定于部分的减少的视频数据流的情况下的一致性保存不是简单的任务。下面描述的实施例允许在保存一致性的情况下传输视频数据流的特定于部分的区段。
图1示出了根据本申请的实施例的视频流传输服务器10，并且为了便于理解服务器10的操作模式的描述，示意性地示出了视频12、视频12被编码成的并且服务器10至少部分地访问了的视频数据流14、以及流16，服务器10向客户提供流传输以便通过下面更详细描述的合成从流传输中获得特定于部分的视频数据流。注意，存在实现服务器10的若干可能性。例如，服务器10可以用硬件(例如，电子电路、诸如现场可编程阵列的固件)或者用软件(例如，通过使用适当编程的计算机)实现。
如下面更详细描述的，视频流传输服务器10被配置为呈现客户端可用的流16的流传输。在后一流的基础上，客户端以下面更详细描述的方式能够合成特定于部分的视频数据流。有利地，与数据或视频数据流14的量相比，流16中的数据量减少。为了理解这些原理，首先描述视频数据流14和视频12已被编码成视频数据流14的方式。服务器10至少关于视频数据流14中的服务器10为移除以用于基于其构造流16的那部分访问视频数据流14。
如图1所示，视频12由一系列图像18组成。在图1中示出视频12中的示例性三个连续图像18的顺序次序20可以与输出或呈现时间顺序相对应。因此，每个图像18表示场景的空间采样，即，由样本阵列组成，因此，视频12表示场景的空间时间采样。每个图像18完全示出场景。术语“完全”应表示这样的事实：编码到数据流14中的每个图像18示出场景，而稍后描述的被编码成基于流16可合成的特定于部分的视频数据流仅示出了场景的一部分22。
图像在空间上被细分为拼块。将图像18细分成拼块可以使得拼块按行和列规则地布置。例如，在图1的示例中，图像18被示出为被细分为3×3的拼块阵列，其中拼块通常使用附图标记24来指示，并且通过使用a到i标记一个图像18内的拼块来彼此区分。然而，每个图像的拼块数量不限于此拼块数量。相反，而是可以将图像18切割成包含n×m个拼块的任何阵列，例如n×m＞2。然而，应该注意，拼块24可以具有除矩形形状之外的形状。此外，将图像18细分成按行和列布置的拼块24的阵列也不应被视为是限制性的。而是，可以使用其它种类的拼块分割法。还应注意，拼块24不应限于与hevc的拼块构思相关的hevc标准中所示的“拼块”。本文在图1中提到的拼块24将表示图像18被细分成的子区域的任何子区域。如图1所示，如果图像细分而成的拼块24在图像18之间相等会是有利的，使得在比较图像18的拼块边界26时拼块之间的拼块边界重合。
尽管关于如何将图像18编码成数据流14的详细方式是多方面的，但编码应至少以视频数据流14由一系列切片26组成的方式进行。
例如，切片26是可以发送数据流14的单元。例如，切片26可以形成数据流14可以单独地或以连续切片集合的方式分别被打包成nal单元或变换分组的单元。如下面更详细描述的，每个切片26可以由切片首部和有效载荷部分组成。就目前而言，足以说图像18被编码到数据流14的切片26中，使得每个切片编码有不多于一个拼块24。在图1中，例如，示出了每个拼块24被精确地编码到一个切片26中，但是这仅仅是示例，并且不应该被视为限制图1的实施例的范围。在图1中，使用大写字母a到i和从图像18到数据流14的虚线以分别说明切片26和拼块24之间的关联。如图1所示，数据流14可以包括以某种方式排序的切片26，所述方式为使得：与某一图像18的拼块24相关联的切片以使得在这些切片之间没有、其中编码有任何其它图像的拼块在内的切片、的方式布置在数据流14中。也就是说，携带不同图像18的拼块24的切片26不是交错的。然而，这也仅仅是示例，不应该被视为限制进一步的描述。为了完整起见，图1还示出了数据流14内可以存在、不能归属于图像18的任何特定拼块24的切片28。例如，这样的切片28可以携带编码参数，编码参数的有效性或范围涉及多于一个拼块、整个图像18或甚至图像18序列。尽管下面提出的描述集中于切片26，但显然可以以与关于切片26所描述的方式类似方式来处理切片28，以便获得基于本实施例的积极效果的优点。
如上所述，服务器10可以访问视频数据流14的切片26。例如，视频数据流14可以原样存储在数字存储介质上，并且服务器10从中读取视频数据流14或相关部分，以便形成流16。然而，如下面将更详细说明的，根据备选实施例，服务器10可以直接访问以服务器10可以直接读取流16以便流传输到客户端的方式概念化的预先处理的视频数据。在关于服务器10呈现客户端可用的的流16进一步详细描述之后，后以方面将变得更加清楚。
特别地，服务器10呈现客户端可用的流16，以便向客户端提供仅涉及场景的部分22的、减少量的数据。例如，在图1的示例中，部分22被描绘为仅覆盖由拼块d、e、g和h组成的2×2子矩阵或者由该2×2子矩阵形成。因此，拼块a、b、c、f和i不属于部分22(即，在部分22外部)，因此，编码有图像18中的部分22外部的部分。因此，服务器10被配置为使得流16仅包含切片26的一部分或子集。特别地，服务器10被配置为使得流16以文件格式被格式化，并且包括一个或多个源轨道30d、30e、30g和30h的集合30以及一个或多个收集轨道的集合32。集合30中包含了切片26，部分22内的拼块(即，拼块d、e、g和h)被编码到切片26中。在图1中，已经选择并描绘了这样的实施例：集合30中的每个源轨道与部分22内的一个拼块相关联，二者之间的关联通过在附图标记30的低阶索引处使用相应大写字母来指示。也就是说，在该实施例的情况下，每个源轨道包含切片26，相关联的拼块24被编码在切片26中。如果存在诸如切片28的其它切片，则可以使用预定规则，以便将所述其它切片分配到集合30上。这样做的方式并不重要。此外，根据备选实施例，源轨道与部分22内的拼块之间不存在一对一关联。而是，集合30内可能只有一个源轨道。
图1示出了集合32仅包括一个收集轨道321的情况。然而，如稍后所说明的，与部分22有关的收集轨道的集合32可以超过一个。例如，集合32内的收集轨道的数量可以等于部分22内的拼块24的数量。
一个或多个收集轨道的集合32包括构造指令，该构造指令指示上述特定于部分的视频数据流的合成，其中仅示出场景的部分22的图像被编码到该特定于部分的视频数据流中。构造指令在图1中通过一系列矩形34示出。
根据以下对与图1的视频流传输服务器10通信的客户端的描述将变得清楚的是，构造指令34指示或定义特定于部分的视频数据流的合成，以便例如通过客户端通过发信号通知包含到源轨道集合30中的切片26的某些部分的替代、并指示对源轨道集合30内的切片26的某些部分进行复制来执行。
图2示出了适合于图1的视频流传输服务器10的客户端50，其中客户端被配置为通过从视频流传输服务器10获取流16、并执行如由构造指令34所规定的特定于部分的视频数据流的合成，来从视频流传输服务器10获取关于部分22的视频。为了便于理解客户端50的操作模式的后续描述，图2示意性地还描绘了客户端50从视频流传输服务器10获取的流16、以及客户端50按照指令34所指示的那样通过合成构建的特定于部分的视频数据流52。
尽管稍后关于图5a至图5e描述构造指令34的示例的细节、以及这些指令34的序列可以定义特定于区段的视频数据流52的合适合成的方式，现在提出简要描述。如上面参考图1所描述的，数据流一致性的一个要求是不同图像的切片26不相互交错。因此，指令34的序列以合适的顺序将属于一个图像的拼块的某些部分复制到数据流52中，之后，后续指令发信号通知对与后续图像18的拼块有关的切片26进行合成。因此，在图2的特定于部分的视频数据流52中，合成的切片54被示出为按顺序存在于数据流52中，使得在流顺序中，与一个图像有关的切片不与关于另一个图像的切片交错。切片54表示切片26的修改版本。修改的切片54与部分22内的拼块之间的关联在图2中通过相应拼块24的大写字母示出。为了说明切片54相对于切片26的这种“修改”，参考图3，其示出了切片26。在图3中，切片26被示为由语法元素编码部分56和其之后的非语法元素编码部分58组成。需要强调的是，部分56和58之间的顺序被选择成这样仅是用于说明的目的。此外，部分58甚至可以丢失，而切片26可以不被二分为部分56和58，但是可以具有多于一个的部分56和/或58。术语“语法元素编码”可以表示这样的事实：以对于部分56内的数据流中的每个比特而言、恰好有该相应的比特所属的一个语法元素60的方式，将数据流的语法元素60编码到数据流内的这样的部分56中，并且反之亦然。换句话说，以连续语法元素60之间的结点被保留在比特流域中、使得每个语法元素60可唯一地与部分56内的一个或多个比特的对应连续行程(run)相关联的方式，将被编码到相应部分56内的语法元素60的序列编码到部分56中。例如，在这样的部分56内，可以在没有压缩或通过使用可变长度代码的情况下对语法元素60进行编码。与此相比，“非语法元素编码”应表示部分58，其中被编码到相应部分58中的语法元素序列之间的结点在比特流域中被抹掉，使得部分58内的比特不再是恰好可归属于一个语法元素。例如，这种部分58可以是例如算术压缩部分。
例如，部分56可以是或包括切片26的切片首部，而部分58可以是或包括切片26的有效负载部分。例如，用于编码数据流14的视频编解码器可以例如是预测编解码器。被编码到部分56中的语法元素60可以例如包括标记60a和/或语法元素60b，标记60a指示相应切片26是否是被编码到相应数据流14中的相应图像的第一切片，语法元素60b指示被编码到切片26中的图像的切片部分的位置或切片地址。例如，语法元素60可以被编码到切片26的切片首部中。被编码到有效载荷部分和/或非语法元素编码部分58中的的语法元素可以是诸如如下项之类的语法元素：编码模式、块细分信息、诸如运动向量分量的预测参数、图像参考索引和/或残差样本值、和/或发信号通知预测残差的变换系数级别。
在形成切片26的修改的切片52时，作为由客户端50执行的合成62的一部分，在收集轨道集合32内的一个或多个指令34可以从数据流26中复制某个部分。这些指令34在图3中通过使用阴影线示出。切片26和52内的被复制部分66和70也以阴影方式示出。复制是在比特流域中执行的，即不执行代码转换。复制在压缩或比特域中执行，而不是在语法级别上执行。可以在图3中阴影线所示的复制指令内散布或交错的一个或多个其它指令34可以发信号通知将替代插入修改的切片52中，而不是将切片26中的未复制的部分插入修改的切片52中。切片26的未复制部分在图3中以非阴影方式示出，并且替代也在切片52内以非阴影方式示出。如图3所示，被替代或未复制部分64可以包括语法元素60，其中这些语法元素的修改值由相应的替代指令发信号通知，替代指令的一个示例在图3中通过未画阴影线的矩形34示出。在修改的切片54内的被插入到数据流52内的替代(而不是流16的切片26内的未复制部分64)的内容可以在指令34的操作符字段内用信号通知，或者可以由替代操作符34通过一些其它手段(例如，通过指向收集轨道集合32内的相应字段)来信号通知。因此，指令34的序列产生修改的切片54：在图3的示例中，复制指令34对复制部分66进行复制，于是替代指令将替代未复制部分64的替代68插入到切片54中，于是复制指令34将切片26中的另一复制部分70复制到切片54中。由此获得的修改切片54涉及与部分66、64和70的序列相对应的、与原始切片26相比修改后的部分66、68和70的序列。然而，应该注意，图3的示例仅被选择用于说明目的，并且例如关于切片26的合成62内的修改处理可以开始于替代指令。因此，第一复制指令可以例如不存在。此外，从以下描述中可以清楚地看出，可能还存在执行或参与合成的其它构造指令类型，其可以例如取决于指令中的某一索引字段，使得在与可以用作一种参数化设置的“选择”索引相对应的字段中的索引的情况下，执行相应的指令。因此，所得到的收集轨道在合成中根据索引而变化。此外，尽管图3中没有具体指出，但是合成参考(即，源轨道的切片)中可能存在既不被复制也不被替代(即，简单地丢弃/跳过)的部分，并且可能存在用于简单丢弃/跳过64的不必要部分的机制。
以关于图3概述的方式，与数据流14和16中的对应切片26相比，可以修改数据流52内的切片54，使得语法元素60被正确地登记到部分22的周围(即，指代部分22的左上角，而不是图像18的左上角)。
因此，如果该特定于动作的视频数据流52被馈送到视频解码器72(如图2中的虚线框所示)，则视频解码器输出视频74，视频74中的图像76仅示出场景的部分22，并且因此图像76仅由拼块d、e、g和h组成。
以类似于图1的描述的方式，客户端50可以用硬件、软件固件实现。也就是说，客户端50可以是电子电路、现场可编程阵列，或者可以包括适当编程的处理器，并且这同样适用于视频解码器72。关于视频解码器72，可以注意到它可以包括在客户端50内或者可以在客户端50外部。
以到目前为止所描述的方式，应该清楚的是，合成62以保持与数据流14的一致性的方式产生视频数据流52。例如，如上所述，视频一致性可能例如要求数据流中属于被编码到相应视频数据流中的视频的一个图像的切片沿着某一拼块顺序排序，该某一拼块顺序例如以光栅扫描顺序、逐行、从顶部到底部等方式遍历图像的拼块24。在视频数据流14中，例如，属于某个图像的拼块以abc的顺序从a到i遍历，并且在数据流52中，修改的切片54以使得切片属于视频74中的一个图像24的顺序为d、e、g、h的拼块、该切片之后是关于下一图像的拼块的切片(以此类推)的方式排序。在每个修改的切片54内，语法元素(例如，语法元素60)可能已经关于它们的值进行了校正，而切片的其它部分可能已经在数据流52中没有任何修改地被采用了，即复制的部分(例如，复制部分70)。也可以在数据流52内修改诸如切片28的其它切片。例如，在图2中将切片78示例性地描绘为表示切片28的修改版本。因此，数据流52内的切片54的序列是由于执行收集轨道的集合32中的指令34的对应顺序而产生的。可以通过考虑能够解码视频数据流14以重新构造视频12的视频解码器交替地由视频数据流52馈送的情况来说明一致性保存。由于一致性保存，作为解码视频数据流52的结果，视频解码器将获得视频74。应注意，例如，图4的视频解码器可以是图2的视频解码器72，因此，在图4中选择了相同的附图标记。然而，应注意，根据备选方案，由于视频解码器72的复杂性水平降低，视频解码器72可能无法解码原始视频数据流14。例如，使用mpeg标准的术语，视频解码器72可以例如是根据不足以解码原始视频数据流14足以解码减少的视频数据流52的简档、级别或层的视频解码器。然而，数据流14和52都符合一个视频编解码器，例如hevc。
在提供用于实现到目前为止所描述的实施例的进一步细节之前，为了便于理解，应提交一些注释。例如，以上描述集中于服务器10能够向客户端提供特定于部分的流16，流16是特定于图像18的场景的某一部分22的。当然，服务器10能够提供相对于由图1中的划线80描绘的该场景的某个其它部分(其示例性地包括b、c、e和f或者由b、c、e和f形成)的对应输出流形式的、对应的源轨道集合30和收集轨道集合32。也就是说，部分22和80都是由图像18的对应的n×m拼块子矩阵组成的场景的矩形部分。然后，源轨道集合30将传送关于拼块b、c、e和f的切片，并且一个或多个收集轨道(即32)的集合对减少的特定于部分的视频数据流执行对应的合成，对这样的视频数据流进行解码产生与场景部分24相对应的图像。“支持”部分的数量甚至可能大于2。除此之外，支持部分流传输的任何部分(例如，22和80)不限于覆盖或者与连续拼块集合一样宽。而是，形成部分的集合可以由非连续的拼块集合组成。想象一下，例如，图像18所示的场景是360°全景视图。在这种情况下，有意义的部分也可以由从场景的一个边缘延伸到相对边缘的部分(例如，覆盖拼块c、a、f、d的部分)形成。在独立编码的拼块的情况下，对应的收集轨道仍然可以将对应的源轨道合成到符合特定于部分的视频数据流，从而得到部分特定图像，该图像示出子部分cf与子部分ad并排缝合。根据应用，即使对在图像76的部分中的、相对于图像18中的相对位置处的拼块进行重新布置也是可行和有意义的。
此外，以上描述对于分别将图像编码到数据流14和52中的方式而言是相当普遍的。根据示例，图像18被编码到视频数据流14的切片26中，其中拼块24的拼块边界之间的编码相互依赖性中断。可以将图像18编码到视频数据流14的切片26中，甚至使得每个切片24编码有不多于一个拼块24，被编码的拼块独立于覆盖相同图像的空间不同部分(即，图像包括该相应部分)的任何其它拼块24，或者独立于覆盖来自于任何其它图像的空间上不同部分的任何其它拼块。例如，某个图像的拼块e将被编码到对应的切片26中，而对任何拼块a、b、c、d、f、g、h、i没有任何编码相互依赖性，而不管是在相同图像中还是任何其它图像中。这样的限制可能要求基于视频12形成数据流14的编码器限制当前拼块的拼块边界附近的可用运动向量，以便不指向需要用于形成运动补偿预测的、与拼块e不同的拼块的样本的参考图像的部分。然而，应该注意的是，没有义务使用诸如混合视频编码编解码器之类的预测编解码器。例如，备选地，可以使用具有或不具有运动补偿的小波编码、无损编码技术等来对图像18进行编码。此外，由于在编码图像18中利用的空间相互依赖性主要限于相对小的距离，因此图像18甚至可以被编码到视频数据流14的切片26中，而不会中断拼块边界25之间的编码相互依赖性。在重新构造减少的视频数据流52时，通过切掉部分22并将其周围处理为不在视频74的图像76内而丢失对应信息将导致重新构造失真，但是由于沿着图像76的周围的有限区域，根据应用，所得到的图像76的质量会是足够的。关于下面列出的细节，还应该注意，这些细节具体地参考iso基础媒体文件格式作为流52的文件格式的示例。然而，流52不限于使用该文件格式进行格式化。而是，也可以使用任何其它文件格式。如图1所示，根据所使用的文件格式，流16可以包括文件首部90，文件首部90定义由流16表示的文件中包含的源轨道集合30和收集轨道集合30、以及轨道30和32之间的相互依赖性(比如，收集轨道集合32对源轨道集合30的依赖性)。此外，根据文件格式，指针可以包含在文件头90中，用于指向集合30和32内的各个轨道。为此，流16可以被细分为访问单元或样本，每个访问单元或样本与图像76中的一个图像时刻相对应。
使用诸如is0基础媒体文件格式之类的文件格式，可以在文件16中存储允许读取拼块24的某个子集的辅助信息，并且产生可以由任何标准符合解码器72解码的符合(例如hevc)比特流52。
这种解码器72的输出74可以是完整视频格式的矩形子集22。
应注意，可能针对不同的拼块子集22、80需要不同的切片首部。为了确保切片首部对于每个拼块子集22、80来说具有正确的cuaddr60b，可以产生多个版本的数据。因此，有可能针对每个拼块子集22、80产生专用收集轨道32，指向文件16中的不同位置，其中正确的nal单元与正确的cuaddr60b一起存储。然而，这会导致复制所有比特流并进行一些特定于拼块子集的调整，从而导致以下几个缺点：
-文件大小会增加(在许多情况下：成倍增加)
-同时传输不同的拼块子集会增加(在许多情况下：乘以传输数据速率)
-对于高速缓存的不利影响，因为不同子集的相同拼块将与不同的轨道和视频数据相对应。
因此，到目前为止所描述的实施例选择了另一种方式：
1.原始比特流的拼块24的切片26存储在单独的轨道30a至30i中。每个完整图像18与按照由也存储在文件16中(例如，在首部90中)的一些元数据给出的预定义顺序的轨道30a至30i中的每个轨道中的一个样本的连接相对应。
2.对于某一拼块子集22，创建附加轨道32，该附加轨道32收集从形成原始比特流的轨道组30所选信息。
3.可以产生多个“收集”轨道，通常每个拼块子集22或80有一个这样的轨道。
4.“收集”轨道的每个样本由一个或多个构造函数(constructor)34阵列组成(参见图5d)。
5.每个构造函数阵列的解译形成nal单元或切片54。
6.可以使用三种类型的构造函数：
-立即数据构造函数，其保存针对拼块子集专门产生的数据100，参见图5a。这可以用于例如包括针对拼块子集22的样本中的每个切片的有效的切片_首部(slice_header)。
-样本构造函数，每个构造函数指向另一个轨道，选择从参考轨道30d...30h的样本中获取的信息，参见图5b。这可以用于指向有效的切片_首部(slice_header)或切片有效载荷(通过使用偏移跳过与有效载荷相邻的slice_header)。复制部分的偏移102和长度104可以是运算符。
-样本条目构造函数，每个构造函数指向参考轨道的样本条目并选择信息(例如参数集)，参见图5c。
注释：与文件格式标准中已经指定的结构相比，本文中所描述的方法可以连接样本的任意部分，并将这些部分与样本中给出的任意数据相连以形成输出样本。之前指定的结构可以引用另一个轨道中的数据，但会产生一些特定于其设计目的的首部数据，例如rtp提示样本，它们只能产生rtp数据包，尽管它们可以从其它轨道收集数据并且可以包括任意数据；或者提取器nal单元，它们只能产生一个或多个nal单元，但这可以通过指示从另一个轨道收集的数据块的长度来截断。
●可以指定新品牌，表示需要支持新的语法元素。
●如果收集轨道的样本使用兼容语法(参见图5e)，其允许由传统读取器50解析，忽略新样本，则现有代码点可以用于这种“收集”轨道的样本条目。
使用等式1计算切割成n×m个拼块24c的图像18的所有可能的矩形(连续)拼块子集22(80)的数量。表1中示出了n≤8且m≤8的c的结果值。
等式1
表1-n×m布置的可能的连续矩形拼块子集的数量
使用等式2(图像大小n×m，如上所述)计算某一大小n×m的可能矩形拼块子集22的数量。对于3≤n≤8且2≤m≤8，表2中示出了来自n×m的图像的3×2的拼块子集的结果值c3，2。
等式2
表2-n×m布置的可能3×2的拼块子集的数量
以上关于图2至图5提出的描述不仅揭示了关于可能的构造指令的详细示例，而且还揭示了部分22可能首先仅仅是一个拼块宽而不是n×m拼块宽的阵列、其次服务器10和客户端50以上述方式操作的可能性，但是关于选择若干部分之一的可能性，该数量不限于一个(22)或两个(22/80)。根据服务器10呈现的部分的大小可用于获取特定于部分的视频数据流以及这些部分的位置，可能并非所有的拼块边界25也形成由服务器10支持的任何部分的周围。反过来，这意味着根据本申请的实施例，可以将图像18编码到视频数据流14的切片26中，其中仅拼块边界25之间的、共同定位到由服务器支持的任何部分的周围的编码相互依赖性中断。在仅支持部分22和80的情况下，例如，通过中断与部分22和80的周围共同定位的编码相互依赖性，将图像18编码到切片26中将仅考虑例如那些拼块边界25，即，仅考虑拼块对ad、be、ef、hi、ar、de、eh和fi之间的拼块边界25。然而，在较高密度的部分的情况下，例如，根据实施例，所有拼块边界25将使得编码相互依赖性中断。在这方面，再次注意到，刚刚关于相同图像的拼块之间的编码相互依赖性中断做出的相同陈述也可以应用于如上所述的也限制对先前图像的依赖性的可能性，即，以使得任何部分周围之间没有对时间参考图像的部分的依赖性的方式来限制运动预测。
以下实施例提供了关于服务器10如何呈现可用的关于某一部分的某一流(例如关于部分22的流16)的可能细节。为了便于理解随后的细节，参考图6，图6再次示出了视频12和对应的源轨道30a至30i。这里，已经选择了图1的示例，根据该示例，每个源轨道包含恰好属于对应图像(目前就一个图像而言)的一个拼块的切片以及在其它图像中共位的拼块的切片。因此，源轨道30a包含关于图像18的拼块a的所有切片26。同样地，源轨道30b携带与所有图像18的拼块b有关的所有切片26。在每个源轨道30a至30i中，属于一个时刻或图像18的切片26在稍后流传输到客户端的文件格式流中形成一个“样本”。样本(图像)序列(即，关于图像的特定序列120的切片的连续行程)形成片段122，片段122可由客户端经由对应的url单独获取。在图6中，例如，其中编码有图像18的序列120的拼块a的切片26的序列形成片段122，片段122之后是其中编码有图像18的后续序列124的拼块a的切片26，这些切片26形成源轨道30a的后续片段126，以此类推。以相同的方式，其它源轨道30b至30i也在时间上细分为样本(图像)120和124以及片段122和126。
在下面描述的实施例中，以类似的方式使针对每个部分的收集轨道的集合32可用。在图6中，例如，示出了服务器使得能够呈现获取场景的四个不同部分221至224，即每个部分是2×2宽的部分，这些部分之间仅部分位置是不同的。对于这些部分221至224中的每一个，能够在服务器处呈现一个收集轨道321至324。每个收集轨道321至324也在时间上构造成样本和片段。对于每个样本128，诸如收集轨道321之类的收集轨道包括构造指令34，构造指令34的顺序执行使得合成仅显示对应部分221的减少的特定于部分的视频数据流的对应访问单元，即，使得合成重新构造显示部分221的图像的对应切片。为了合成，收集轨道321仅需要源轨道30a、30b、30d和30e。以类似的方式，收集轨道322至324包含关于对应部分222至224的每个样本/图像128的构造指令34。正如源轨道30a至30i一样，收集轨道321至324可由客户端以片段122和126为单位单独获取，每个片段携带对应的收集轨道321至324的对应的样本128的序列。因此，在图6的示例中，客户端需要获取收集轨道321以及参考的源轨道30a、30b、30d和30e，以便获得关于部分221的特定于部分的视频数据流。
因此，根据图6的实施例，客户端10将源轨道30a至30i和收集轨道321至324中的每一个视为单独的表示，并且在诸如媒体呈现描述之类的清单(其是描述服务器10上的可用媒体数据的文件)中，根据客户端52到服务器10的对应请求，将该情况通知给客户端。然而，这意味着由服务器10向客户端50提供的媒体呈现描述需要包括相当大量信息。例如，对于每个表示，即对于30a至30i和321至324(所有13个表示)中的每一个，媒体呈现描述可以包括基本url或url基础的指示、图像大小的指示(即，在源轨道30a至30i的情况下的拼块大小的指示以及在收集轨道321至324的情况下的部分大小的指示)、定义用于确定相对于基本url或与基本url组合的对应表示的片段的url的计算规则的片段或url模板、和/或表示对应表示所依赖的表示的指示(比如，表示30a、30b、30d和30e作为表示321所依赖的参考表示的指示)。这是相当大量的数据。
这参考图7进行说明，图7示出了4×3拼块划分以及对应的大小为3×2的四个部分的说明性情况。注意，在随后的描述中，部分221至224有时被称为感兴趣区域roi。此外，关于收集轨道的表示被称为收集表示，而对应于源轨道的表示被称为拼块表示。
尽管可以通过选择减少数量的可能提供的roi尺寸(例如，仅限于2×2、3×2或3×3拼块roi)来减少可能的组合的数量，媒体呈现描述(mpd)中dash中描述的附加轨道或表示的数量仍然非常高。图7概念性地示出了所描述的解决方案将如何用于将提供3×2个roi的4×3拼块的全景视频。
每个收集表示将使用@dependencyid来指示它们将依赖于原始表示拼块表示表示.拼块1(rep.tile1)至表示.拼块12(rep.tile12)之中的那些表示。
下面描述的实施例试图通过将片段模板构思扩展到表示集合(即，关于收集轨道的表示集合)来克服具有携带有关于收集轨道的大量冗余信息的巨大媒体呈现描述的问题。替代分别描述每个收集表示的媒体呈现描述，根据下一实施例的媒体呈现描述向媒体呈现描述或清单提供定义用于根据部分的空间位置来确定收集表示的片段的url的计算规则的url模板。计算规则将使得所计算的url在所有收集轨道321至324的片段之间是相互不同的。如果部分221至224的大小相同，则可以使用该构思，使得清单或媒体呈现描述可以描述收集表示的特性，所述特性通常用于所有收集表示(部分221至224)。例如，媒体呈现描述或清单可以仅一次指示所有收集表示的图像大小、编码简档和/或基本url。也将在仅一次用于收集表示的清单或媒体呈现描述中用信号通知url或片段模板。当前获取的收集表示的对应源轨道的集合可以由客户端基于所获取的收集表示本身所属的相应部分所覆盖的拼块的知识来确定。
换句话说，后一实施例允许使用针对url的片段模板来获取收集表示。它由gatheringrepresentation(收集表示)使用模板的构思组成。由于上面图7中描述的所有收集表示应该具有相同的特性(例如，图像尺寸、图像纵横比、轮廓、水平等)，但它们在高分辨率视频中对其它表示和右上位置的依赖性不同，可以提供具有url的单个表示，该单个表示将基于模板并且基于高分辨率视频中的右上位置，可以导出属于期望的收集表示的每个片段的特定url。
信令方面的实例化可以如图8所示，图8示出了用于收集表示的url模板的示例。
所描述的信令将允许构建url并基于roi的位置导出必要的拼块。更具体地，为了使用该收集轨道模板基础解决方案，将不同的元素和属性添加到mpd。首先，可以将拼块表示分成不同的adaptationset(自适应集)，并且可以使用现有的空间关系描述符(srd)。然后可以提供另外的adaptationset，其中嵌入了gatheringrepresentation。如果收集表示包含在adaptationset中，则不能同时提供其它表示(“正常表示”)。gatheringrepresentation的存在可以由称为@gatheringrepresentationspresent的新属性指示(或者备选地使用描述符，例如通过添加urn(统一资源名称的essentialproperty(基本属性)描述符，urn允许指示存在这种特殊表示)。包含可以下载以与gatheringrepresentation一起使用的拼块表示的adaptationset由属性@baseadaptationsetid指示。用于gatheringrepresentation的representsenationbasetype中的现有@width和@height属性以及正常表示中的属性可用于导出使用给定gatheringrepresentation所需的拼块表示的数量。此外，属性@samequalityranking可用于指示具有不同质量的不同拼块的表示不应与gatheringrepresentation一起使用。由于模板url用于导出gatheringrepresentation的片段的url，因此需要一种机制来导出可以放置在这种url模板中的参数。在dash4中，标识符用于模板url替代。
url模板的标识符
$编号$和$时间$用于标识表示中的给定片段并产生其url。$表示id$和$带宽$可以用于标识表示。第一个与唯一标识符相对应，而第二个可以在多于一个的表示之间共享。因此，需要一个规则来基于包含实际拼块的常规表示来导出gatheringrepresentation的$表示id$。这意味着与gatheringreptesentation一起使用时segmenttemplate元素必须包含此标识符，并且需要添加新构造函数(或现有构造函数的扩展，例如essentialproperty描述符)，以提供产生$表示id$的机制。这通过元素idderivationmechanism添加到上面显示的xml语法中。一个示例是例如当@schemeiduri等于“urn：mpeg：dash：gatheringrepresentationidderivation：2015”width@value等于1时，意味着连接拼块表示的@id属性以产生对应gatheringrepresentation的$表示id$。
所描述的方法将有助于通过使用基于模板的表示来减小mpd的大小。然而，这种方法仍然需要客户端侧针对收集表示片段发出附加的httpget，并且会使得需要从服务器侧提供大量小文件，这对于服务器和缓存来说已知是不利的。然而，这将使“moov”框中的轨道数保持较低，因为每次只下载一个gatheringrep.，因此具有相同分辨率的所有gatheringrep可以具有相同的轨道，这将允许保持“moov”框小。
由于轨道依赖性在“moov”框中描述并且在“trak”框中更明确地描述，因此moov框应该包含所有依赖性的超集，@dependencyid将在mpeg-dash中给出正确的依赖性。这将导致在“tref”框内发信号通知的所有相关轨道在每次都不存在，这意味着au重新构造将仅可能使用具有多个构造函数的显式重新构造来引用不同轨道，并且从不同的轨道(属于期望的roi)收集不同构造函数的隐式重新构造将不是可能的。这一事实将使得多个收集轨道之间的某种“重复”信令的一些开销。
图9示出了在服务器侧将存在许多用于收集片段的小文件。
因此，尽管上面的描述提供了如何减小媒体呈现描述140(图8)的大小的可能性，以便允许单独处理源轨道和收集轨道作为单独的表示(即，拼块表示和收集表示)，图9显示针对与一段表示相对应的每个时间间隔，客户端50从服务器10获取的片段的数量是相当大的。图9通过使用阴影线示出收集表示的片段来区分一方面的任何拼块表示的片段和另一方面的收集表示的片段。如图9所示，客户端50需要为当前下载的收集表示的每个片段142获取n个拼块片段144，其中n是当前下载的收集表示与空间覆盖相关联的拼块的数量。例如，在图6的示例中，客户端50必须为当前下载的视频部分221至224获取四个片段。然而，由于每个片段获取需要从客户端50向服务器10发送对应的请求，因此避免附加地发送收集片段152会是有利的，尤其是当考虑到这些片段与拼块片段144相比小的事实时。
为了避免对服务器和cdn有害的许多小文件的问题，因此另一个实施例包括在每个表示处有(子)段2轨道，如下所示。第一个将与典型的视频轨道相对应，该视频轨道仅描述了当独立于其它拼块播放时恢复每个拼块(或当更多拼块被封装在相同轨道中时的拼块组)的样本的方式。参见图10，并将情况与图9进行比较。
对于收集轨道，有若干种选择。
第一个包括使用上述技术，这意味着所需roi的左上方拼块的附加轨道(收集轨道)将仅指示所需的轨道依赖性，并且显式au重新构造将遵循先前定义的构造函数的指令来执行。用户将根据哪个是左上方的拼块来播放一个或另一个收集轨道(在附图中的示例中，它将是第一轨道n+1和稍后的轨道m)。当查看下载的收集轨道并假设每个样本单个切片时，存在的构造函数将在图11中描绘。
为了再次参考图6说明该情况，参考图12，其关于图6的示例示出了客户端50在对部分221感兴趣时将关于时刻/图像/样本获取的四个片段，但是这里使用针对收集轨道不花费额外表示的构思。相反，收集轨道321至324被“隐藏”或“包含”在源轨道本身的片段内。图12示出了客户端50在某一时刻获取的四个片段，每个源轨道30a、30b、30d和30e一个片段。如上所述，收集轨道321至324将包括在那些源轨道的片段内，这些源轨道与形成与相应收集轨道相对应的部分的左上拼块的拼块相对应。例如，收集轨道321在源轨道30a的片段内传送，收集轨道322在源轨道30b的片段内传送，收集轨道323在源轨道30d的片段内传送，并且收集轨道324在源轨道30e的片段内传送。图12示出了客户端50从源轨道30a、30b、30d和30e中获取的一个样本，以便获取在源轨道30a中包括的收集轨道321所依赖的源轨道。收集轨道321的样本128的构造操作34的序列顺序地执行关于拼块a、b、d和e的合成。因此，构造操作的序列被细分为四个部分1501至1504。以相同的方式，收集轨道322至324的对应构造指令包含在其它源轨道30b、30d和30e内。客户端不需要后者，但是对于对任何其它部分222至224感兴趣的客户端包括它们。从图12中可以看出，在构造指令的各部分中，在每个收集轨道321至324中存在属于拼块e的一个部分。然而，这些部分非常相似并且例如相对于通过使用花括号152示出的子部分是相同的。属于拼块e的那些部分中的未被部分152覆盖的其余部分可以例如涉及使用附图标记60a和60b在上面参考图3讨论的第一切片和切片地址指示。为了消除冗余，可以使用随后解释的构思。这之前描述了，然而，请注意，在源轨道30a(仅关于对应部分的221左上拼块的源轨道)内传送收集轨道321也是变化的，即例如部分151至154分布在由对应部分221覆盖的拼块上。在那种情况下，例如，收集轨道321将分布在源轨道30a、30b、30d和30e上。
如上面关于图11和图12所讨论的那样，将存在大量冗余信息。此外，如果对于将对不同量的拼块进行分组的roi将存在多于一种可能的分辨率，则将需要更多的收集轨道，每个可能的分辨率一个收集轨道，其中图中的标记数据在任何地方都是冗余的。
另一个实施例涉及前面描述的关于冗余信息的问题。为此目的，考虑隐式重新构造，其中每个收集轨道由具有构造函数索引的构造函数的阵列组成。取决于视频内对应轨道的位置(或遵循“tref”依赖顺序)，将确定索引(i)，并且仅执行具有cidx＝i的构造函数。因此，将允许共享公共信息(例如，nalu有效载荷大小)，并且仅发信号通知不同的首部可能性，从而节省一些开销。在图13中，示出了针对前述直接构造函数的这种构造函数的结构(可以以类似的方式扩展其它提取器)。
在图14中，示出了使用该技术时样本的构造函数(constructor)。
因此，需要较少的冗余数据，如图14所示。
也就是说，关于图12讨论的避免冗余的可能性将如下实现：不是传送收集轨道(比如，完全在关于对应部分221内的左上(或任何其它)拼块的源轨道内的收集轨道321)，而是在每个源轨道30a至30i内传送可参数化的收集轨道。“参数化”的数量将与对应源轨道所属的拼块重叠的部分的数量相对应。例如，源轨道30e属于拼块e，拼块e是每个部分221至224的成员。因此，在源轨道30e内传送的可参数化收集轨道将具有四个可用参数化。针对在拼块b、f、d和h的源轨道内传送的可参数化收集轨道仅需要呈现两个参数化，针对拼块a、c、g和i的源轨道不需要呈现参数化或仅需要呈现一个参数化。“参数化”将相应可参数化收集轨道变换到实际收集轨道321至324的相应部分。例如，如果使用第一值参数化的，则在源轨道30e内传送的可参数化收集轨道产生部分1504。客户端50将相应地获取源轨道30a、30b、30d和30e以用于下载场景的部分221，并且针对每个图像或样本(参数化或非参数化的)执行在源轨道30a内传送的收集轨道，针对后面的样本或图像相应地参数化源轨道30b和30d的收集轨道、并且适当地参数化源轨道30e的收集轨道等等。使用另一参数化，源轨道30e的相同可参数化收集轨道可以针对任何非参数化的收集轨道322至324形成部分152。如关于图13和图14所示，可以使用“可索引构造指令”以便形成可参数化收集轨道的不相同部分或可适应部分。根据所应用的索引，仅那些可索引指令将参与合成，其索引字段对应于所应用的索引。然而，重复的是，该支持部分的集合可以相对于图12中所示的那些放大，以便还包括从一个场景边缘延伸到另一个场景边缘的部分，例如如果场景是360°全景则这是有意义的。具有对应收集轨道的附加部分可以是例如覆盖拼块集{c，a，d，f}和{d，f，g，i}的部分。在这种情况下，所有拼块a到i的源轨道的片段将包含可参数化的收集轨道，对于轨道30d、30e、30f的片段，参数设置的数量是3，对于轨道30a、30b、30c、30g、30h、30i来说，参数设置的数量是2。
为了重新构造与所选择的roi相对应的访问单元(au)，显然需要使用多于一个片段的这些收集轨道中的若干个收集轨道。在这种情况下，重要的是要知道收集轨道之间的需要被遵循的依赖性是哪个。一种选择是遵循左上位置处的拼块的“tref”依赖性，忽略其它收集轨道的依赖性。
此外，如果允许多于一个的roi尺寸(每个图像n×m个拼块，n是沿水平方向的拼块的数量，m是沿垂直方向的拼块数量)，如果不使用该技术，则轨道的数量将非常快地增加。这将使得需要下载大量“moov”框或下载具有所有定义的轨道的非常大的“moov”框。每个表示多个轨道的隐式重新构造将允许摆脱必须下载非常小的片段(这对缓存和cdn性能有害)，但是与以上所述的针对收集轨道提供单独的表示的第一种方法相比，需要下载大的“moov”框或大量的“moov”框。
利用隐式au重新构造，可以扩展上述技术，使得通过添加附加的cidx可以将相同的轨道用于不同的roi尺寸。构造函数的用法与上面描述的相同，其中只有具有给定索引的那些构造函数将被执行。
然而，在这种情况下，不可能使用“tref”框导出依赖性，因为不可能描述不同的依赖性。类似地，描述简档、级别等的样本条目不能像它们当前那样使用，因为相同的轨道将用于不同的最终roi分辨率。
每个收集轨道将使用“tref”来指示这些收集轨道应用于哪个拼块轨道。将添加一个新框以实现关联若干个收集轨道以提取给定roi的功能。该轨道应该是中心的，并且描述所有可能的roi(例如，通过“moov”框中的某种备选分组)。将有多种备选方案来播放给定尺寸的roi，但是这些备选方案中的每一个将与全景视频中的给定位置相对应。
当前实施例包括描述可能操作点、并且允许关联需要同时用于au重新构造的不同轨道的备选样本组的定义，并且包括需要在构造函数阵列中使用以获得正确nalu的cidx。
然后，备选样本组可以描述简档、级别，即备选样本组应该包括与样本条目相同的信息。
在实施例2中，收集轨道被认为是作为单独的表示提供的。在非外部表示用于收集轨道的情况下(即，收集轨道包含在与拼块本身相同的片段中)，有必要在mpd中发信号通知可以一起解码不同的拼块。这可以通过添加元素或修改现有的子集元素来完成。使用收集轨道可获得的roi的尺寸以及共同下载的数据的mimetype将包括在这样的元素中。
因此，简要总结有关经由自适应流向客户端传送源轨道和收集轨道的最新描述，以下应该变得清楚：源轨道和收集轨道可以在单独的片段(即，单独的表示的片段)内传送，每个片段与单独的url源轨道表示相关联，并且因此可以区分收集轨道表示。对于所得到的减少的特定于部分的视频数据流52的某个片段，客户端50因此必须取回传送想要部分内的拼块的每个源轨道的对应片段、以及属于想要部分的收集轨道的对应片段。媒体呈现描述或清单可以包括用于收集表示的相互不同的url基础的显式信令，这些收集表示的特性(比如，图像大小、片段模板等)被分开描述。为了减少清单文件大小，可以对于所有收集表示来说共同的清单内提交url模板。计算规则将根据该部分的空间位置定义收集轨道的片段的url的计算，根据该清单减少构思，url具有相同的大小并且仅在场景位置中彼此不同。因此，清单可以描述收集表示中的共同关于这些收集表示的许多或全部其余表示特性(例如，图像大小等)。在其它实施例中，仅源轨道的片段与相互不同的url相关联，因此形成对应源轨道表示的片段。根据该实施例，客户端针对某个想要部分取回那些在想要场景部分内传送切片的源轨道表示的片段，并且这些片段同时传送或包括与想要部分相关联的收集轨道，该收集轨道包含构造指令，以根据所取回的片段内传送的切片来合成特定于部分的视频数据流。针对某个想要部分的收集轨道可以仅在与想要部分内的拼块有关的一个预定源轨道的片段内传送，比如，传送与想要部分内的预定拼块位置内的拼块(比如，想要部分的左上拼块)有关的切片的片段。在另一实施例中，每个源轨道表示在其片段内包括特定于源轨道的可参数化收集轨道。这里，客户端仍然仅通过适当地参数化在片段内传送的可参数化的收集轨道、并且基于按照在部分内的拼块之间定义的拼块顺序的参数化收集轨道执行特定于部分的视频数据流的合成，来取回属于与想要部分内的拼块的切片有关的源轨道的那些片段：参数化的收集轨道的样本(即，与预定图像有关的部分)以拼块顺序执行，然后以拼块顺序执行之后的参数化收集轨道的样本。可以通过选择预定索引来执行参数化，以便跳过包括另一索引在内的可参数化收集轨道内的构造指令。然而，如上所述，即使在将收集轨道塞入源轨道的片段中的情况下，也可以向客户端提供关于所包含的收集轨道的信息，该信息类似于如在将收集轨道视为单独表示的情况下的在mpd内传送的信息。例如，可以向清单或mpd提供多个拼块(即，特定部分)可以一起回放的承诺(即，通过指示对应的收集轨道的存在)，并且该信息可以附加地包含部分相关信息，例如，描述对通过使用相应的收集轨道进行合成得到的特定于部分的视频数据流进行解码所需的简档、级别和层的信息。在这个意义上，清单还指示对哪些拼块集可以一起播放(即，形成一个允许的部分)、哪些拼块集不能一起播放的限制。
以上构思和实施例可以具体体现如下，以便对应地扩展is0基础媒体文件格式。这里，可选地，可独立解码的hevc拼块可以携带在称为拼块轨道的不同轨道中。拼块轨道是视频轨道，视频轨道具有对携带拼块所属的相关联的hevc层的nal单元的hevc轨道的“tbas”参考。这种拼块轨道中的样本和样本描述框都不包含vps、sps或ppsnal单元。相反，这些nal单元将位于包含相关联层在内的轨道的样本或样本描述框中，如由相应拼块轨道的“tbas”轨道参考所标识的。如“tbas”轨道参考所指示的，拼块轨道和包含相关联层在内的轨道都可以使用如下文所定义的提取器来指示如何构造想要的比特流。拼块轨道中的样本是针对一个或多个拼块的切片的完整集合。无论使用拼块轨道还是包含整个视频在内的轨道，它都可以用作参考或源轨道，根据需要通过使用上面提出的、并且现在进一步说明的示例中的提取器从所述参考或源轨道提取片。特别地，针对iso基础媒体文件格式的hevc和l-hevc轨道的提取器可以实现通过参考(即，收集轨道)提取nal单元数据的轨道的紧凑形成。提取器可以包含一个或多个构造函数：
a)样本构造函数，通过参考从另一个轨道的样本中提取nal单元数据。
b)样本描述构造函数，通过参考从样本描述中提取nal单元数据。
c)内联构造函数，包括nal单元数据。
因此，这样的提取器可以如图5e或图5d那样构成，其中阵列长度指示可以保持不变。样本构造函数和样本描述构造函数可以如图5a至图5c那样体现。
聚合器可以包括或参考提取器。提取器可以参考聚合器。当提取器由需要它的文件读取器处理时，提取器在逻辑上被在按所包含的构造函数的外观顺序对所包含的构造函数进行解析时产生的字节替代。除聚合器外，样本构造函数引用的字节不应包含提取器；提取器不应直接或间接参考另一提取器。当然，所参考的轨道(源轨道)可以包含提取器，即使提取器参考的数据不能这样。
提取器可以包含一个或多个构造函数，以用于借助于类型为“scal”的轨道参考从当前轨道或从与提取器所在轨道相链接的另一轨道提取数据。已解析的提取器的字节应为以下之一：
a)一整个nal单元；请注意，当参考聚合器时，将复制所包括的和所参考的字节
b)多于一个的整个nal单元
在这两种情况下，已解析的提取器的字节都以有效长度字段和nal单元首部开始。
样本构造函数的字节仅从通过指示的“scal”轨道参考而被参考的轨道中的单个标识样本中复制。对齐是关于解码时间，即仅使用时间到样本表，然后是样本数的计数偏移。提取器是媒体级概念，因此在考虑任何编辑列表之前应用于目标轨道。当然，可以将两个轨道中的编辑列表选择为是相同的。
下面给出了针对提取器的语法示例：
至于上述语法示例的语义，同样可以是：
nalunitheader()可以表示iso/iec23008-2nal单元的前两个字节。对于iso/iec23008-2视频，nal_unit_type可以设置为49。forbidden_zero_bit可以按照iso/iec23008-2中规定的那样进行设置。其它字段可以涉及nuh_layer_id和nuh_temporalid_plus1，可以如稍后指定的那样设置。constructor_type指定稍后的构造函数。sampleconstructor、sampledescriptionconstructor和inlineconstructor与constructor_type相对应，分别等于0、1和2。可能会针对其它构造函数保留或不保留constructor_type的其它值。endofnalunit()是一个函数，当在这个提取器中跟随更多数据时该函数返回0(假)；否则返回1(真)。
有关样本构造函数语法，请参阅以下示例：
针对上面的样本构造函数语法的语义可以如下：
track_ref_index：指示参考轨道，如图5b和图5c中的tri。
sample_offset：索引具有参考轨道的“样本”，即参考轨道中的与想要图像id相对应的部分的开始。也就是说，sample_offset对应于图5b中的so；
data_offset：要复制的参考样本中的第一字节的偏移。如果提取以该样本中的数据的第一字节开始，则偏移取值0。也就是说，data_offset对应于图5b和图5c中的数据偏移；
data_length：要复制的字节的个数。如果此字段取值为0，则data_offset应引用nal单元长度字段的开头，并复制整个单个参考的nal单元(即，要复制的长度取自data_offset参考的长度字段，并在聚合器的情况下由additional_bytes字段扩增)。例如，比较图5b和图5c中的数据长度。
请注意，如果两个轨道使用不同的lengthsizeminusone值，则提取的数据将需要重新格式化以符合目标轨道的长度字段大小。
有关样本描述构造函数语法，请参阅以下示例：
针对上面的样本描述构造函数语法的语义可以如下：
length：属于此字段后面的sampledescriptionconstructor的字节数。长度值应为偶数，大于或等于4，且小于或等于10。它对应于图5b和图5c中的字段dfl；
track_ref_index标识“tref”框中枚举的“scal”类型的轨道参考的索引。值0指示当前轨道，其中找到此构造函数。值1指示第一轨道参考。track_ref_index的值不应超过轨道参考的数量。它对应于图5b和图5c中的字段tri；
sample_description_index标识“stsd”框中枚举的样本描述的索引。sample_description_index的值既不应为零，也不应超过样本条目的数量。它对应于图5c中的字段so；
data_offset是无符号偏移，用于寻址要从样本描述中复制的块的第一数据字节。值0意味着从参考的样本描述的第一字节开始复制。它对应于图5b和图5c中的字段数据offxet；
data_length指定要从参考轨道中的样本描述中复制的数据块的长度。值0意味着不会从参考的样本描述中复制任何字节。data_length不得超过参考的样本描述的大小。它对应于图5b和图5c中的字段数据长度；
至于内联构造函数语法，请参阅以下示例：
针对上面的内联构造函数语法的语义可以如下：
length：属于此字段后面的inlineconstructor的字节数。长度值应大于0。保留等于0的长度值。它对应于图5a中的字段dfl；
inline_data：当解析内联构造函数时要返回的数据字节。它对应于图5a中的字段数据字段
聚合器和提取器都可以使用如iso/iec23008-2中规定的nal单元首部。由提取器提取或由聚合器聚合的nal单元是通过递归地检查聚合器或提取器的内容而参考或包括的那些nal单元。字段nuh_layer_id和nuh_temporalid_plus1可以设置如下：nuh_layer_id可以被设置为所有聚合或提取的nal单元中的字段的最低值。huh_temporal_id_plus1可以被设置为所有聚合或提取的nal单元中的字段的最低值。
也就是说，视频数据可以被概念化，用于以任何上述方式将场景的空间可变部分流传输到客户端。视频数据被格式化为文件格式，并且包括一个或多个源轨道，每个源轨道与完全捕获场景的视频的图像在空间上被细分而成的相应拼块中的一个拼块相关联，其中源轨道上分布有其中编码有视频的图像的视频数据流的切片，使得每个切片中编码有多于一个的拼块；以及一个或多个收集轨道集合，每个收集轨道与由对应的拼块子集形成的部分的多个位置中的相应一个位置相关联，并且包括指示特定于部分位置的视频数据流的合成的构造指令，其中在相应位置处的示出场景部分的图像被编码到特定于部分位置的视频数据流中。可以从图5a至图5c、或图5a至图5e的示例中或从刚刚呈现的示例中选择构造指令。
以下实施例涉及用于向客户端提供用于roi预取的提示的构思。
目前，高分辨率和广角视频正变得越来越流行。它们包括180°至360°全景或球形视频。随着这些视频的大小不断增加，以高分辨率发送整个视频变得不切实际。例如，不同的流传输方法探索将视频分割成多个拼块，并且仅发送覆盖用户感兴趣区域(roi)的那些拼块。其它可能涉及发送视频中的要以诸如质量、分辨率之类的不同特性编码的区域，以优化向用户发送的视频比特率。
在任何这些方法中(例如，上面提到的)，想法是基于用户偏好完成视频传输优化，其中向用户显示的视频部分以高质量下载，而因用户交互而可能向用户显示的一些其它部分(不被视为roi)可以以相同或其它质量的预取方式下载。
dash标准允许通过使用空间关系描述符来发信号通知那些提供的视频部分的空间关系。尽管，该描述符允许用户根据它们所覆盖的视频的空间区域来理解所提供的内容的关系，但是关于roi信令存在间隙。用户没有关于例如视频内的时空活动的详细信息。一些著作(如[1])表明知道视频的roi的时空特性可以实现更高效的发送方案，其中视频中的覆盖对于大多数用户来说感兴趣的主要活动的重要空间区域可以以与无视roi特性的发送方案相比的更高的质量下载。
此外，作为实际考虑，可以分析这种服务中的流传输会话启动。在做出有关下载实际媒体数据的决定之前，客户必须了解roi特性。因此，在vod会话启动或实时调入时，roi以最优质量请求，并且实际上正在向用户显示。
使用role-main信令的基于mpd的解决方案具有不成比例地增加mpd大小的缺点，并且不能以有效方式用于实时流传输服务，因为这将需要过于频繁的mpd牵引或来自某种指示的附加延迟(必须请求新的mpd才能在客户端触发mpd更新)。
下面描述的实施例提出了用于发信号通知一个或多个roi的位置及其移动(即，随时间映射到表示或拼块)的机制：
-使用“emsg”文件格式框的带内解决方案：适用于vod。携带该框的每个片段将指示即将到来的片段中的roi的空间位置，以便客户端可以例如通过使用更多的可用带宽来预取对应的表示来充分地使用它。适用于预取提示，不适用于启动roi。
-使用sand消息的带外解决方案：适用于实时服务。在这样的环境中，“emsg”可能不是最优解决方案，因为内容产生部分会增加延迟，因为需要等待下一个片段被处理才能添加“emsg”框。此外，该信息可以用于在vod上下文中的回放启动(或搜索)。适用于预取提示和启动roi。
-另一个选项是在文件开头处的框，该文件描述了通过声明位置(x，y)和尺寸(宽度，高度)来描述一个或多个roi的不同时间间隔。
使用“emsg”的构思可以如下。
dash事件消息框在mpegdash中定义为：
然后，所提出的roi信令将添加用于发信号通知主要roi坐标的scheme_id_uri。可以定义urn“urn：mpeg：dash：roichangeevent：2016”以标识roi特性。备选地，现有方案“urn：mpeg：dash：event：2012”可以扩展，并且可以添加新值。
对于使用此方案的事件，“emsg”.“message_data[]”字段将包含下面定义的dashroichangeevent结构：
该信息将与要被下载的下一片段相关。备选地，可以开发另一个版本，其通过添加更多的emsg.value来指示针对多于一个片段的roi。
使用sand的构思可以如下。
将定义新的参数增强接收(per，即从dash感知网元(dane)发送到dash客户端的消息)，其指示给定时间的roi。该消息将与之前针对“emsg”情况定义的消息类似：
例如在描述roi的时间改变的“moov”中使用中心框的构思可以描述如下。
类似地，可以通过添加参数来改变消息以包含多个roi，如下所不：
为了说明根据刚刚概述的构思的实施例，参考以下附图。图15示出了视频流传输服务器200和客户端250。仅作为选项，服务器200和客户端250可以以符合图1至图15的任何上述实施例的方式实现。在任何情况下，视频流传输服务器200被配置为将视频流216伴随信息260，视频流216表示场景，信息260以使得位置在时间上变化的方式指示感兴趣区域270的位置。也就是说，视频流传输服务器200可以访问表示特定场景的视频数据。例如，视频数据可以在其中编码视频280，视频280的每个图像290显示场景。关于视频280的视频数据可以以上面关于图1至图15概述的方式概念化。也就是说，服务器200可以以这样的方式配置：允许客户端250以使得获取的视频流216仅涉及感兴趣区域270这样的方式，从服务器200获取视频流216，其中所述感兴趣区域270将表示使用图1至图15的术语“部分”。备选地，服务器200仅呈现能够以视频数据流216完全传送关于场景的信息来获取视频数据流216。然而，在后一种情况下，例如，允许客户端250以不同的顺序获取或取回视频流216的片段。例如，可以向客户端250提供机会来取回关于视频280的某个时间部分、并且关于紧接在获取相同时间部分但关于另一空间区域的片段之前的场景的某一空间区域的片段。通过提及服务器200和客户端250可以以符合图1和图2的服务器10和客户端50的方式实现的可能性而变得清楚的是，图15中的视频流260可以是与图1的流16相对应的流。
图15示出了信息260及时改变感兴趣区域270的位置。在没有这样的信息260的情况下，客户端250不能取回该场景中的、最可能包括当前时间片段内该场景的最感兴趣部分在内的某一当前时间片段。然而，为了预取目的并且为了适当地开始获取视频流216，将有利于客户端250尽可能早地具有信息260，以便呈现由客户端用户引起的关于视频280的空间上不同的区域、但是尽可能不涉及已经取回的视频280的时间片段的、取回请求。
根据实施例，视频流传输服务器10被配置为在视频流的文件格式框内传送信息260。也就是说，视频流216将根据文件格式从服务器200传送到客户端250，并且信息260将嵌入在如此格式化的视频流216中。当然，客户端250必须“盲目地”开始获取视频流216，即没有关于感兴趣区域270的位置的任何信息260。备选地，当有从客户端250到服务器200的适当请求时，服务器200可以将关于感兴趣区域270(即，关于在开始获取视频时感兴趣区域的位置)的另一信息包括在从服务器200发送的视频流216的媒体呈现描述或初始片段中。以这种方式，客户端250将有机会从媒体呈现描述中的适当信息获得关于感兴趣区域270的位置的第一提示，然后使用信息260以便调度预取视频280的未来时间片段。
根据上面已经描述的备选方案，视频流传输服务器200可以是dash服务器，并且被配置为借助于sand消息而不是在视频流216的文件格式框内传送带外信息260。使用这两个构思，视频流传输服务器200能够间歇地更新信息260，以便更新感兴趣区域270的位置。特别地，视频流传输服务器能够在独立于客户端请求的时间实例处调度信息270的间歇更新。也就是说，客户端250不需要向服务器200发送对信息260的更新的请求。而是，服务器200自己发起对信息260的更新或重新发送。
附加地或备选地，服务器200甚至可以被配置为：以信息260还调度感兴趣区域270的位置的即将到来的改变的方式在流传输开始时传送信息260。例如，视频280的视频内容可以在服务器侧是已知的，并且因此服务器200可以例如以信息260以时间变化的方式指示感兴趣区域270的位置的方式(即，以在视频280的时间长度期间位置在调度时间实例处改变的方式指示感兴趣区域270的位置)，提供具有信息260的清单或媒体呈现描述。备选地，例如，服务器200可以以信息260以时间变化方式指示感兴趣区域270的位置的方式，来提供在请求和检查了mpd之后通常由客户端取回的初始片段以及信息260。在后一种情况下，可以使用上述中心框或roidescriptionbox。
可以以mpd向客户端指示信息260的存在或可用性的指示。可以根据客户端的对应请求来呈现信息260的存在或视频流216伴随有信息260的事实。因此，如果客户端没有如此请求，则服务器200可以跳过伴随。在信息260是带内信息(比如，mpd中包括的信息(emsg)、或者初始片段中包括的信息“roid”变量)的情况下，该过程可以以客户端请求包括可用性的相应指示在内的mpd开始，之后是客户端请求新的mpd以及信息260的请求，或者之后是客户端向服务器请求初始片段以及请求信息260的存在。以类似的方式，带外信息260的存在可以取决于来自客户端的对应请求。根据客户的意愿，服务器将会或不会经由sand消息向客户端发送roi信息260。
类似于以上描述，其中已经注意到服务器10和客户端50可以以硬件、固件或软件来体现，服务器200和客户端250可以以相同的方式实现，即以硬件、固件或软件的形式实现。
尽管已经在装置的上下文中描述了一些方面，但是将清楚的是，这些方面还表示对应方法的描述，其中，块或设备对应于方法步骤或方法步骤的特征。类似地，在方法步骤的上下文中描述的方面也表示对对应块或者对应装置的项或特征的描述。可以由(或使用)硬件装置(比如，微处理器、可编程计算机或电子电路)来执行一些或全部方法步骤。在一些实施例中，可以由这种装置来执行最重要方法步骤中的一个或多个方法步骤。
本发明的编码数据流或信号可以存储在数字存储介质上，或者可以在诸如无线传输介质或有线传输介质(例如，互联网)等的传输介质上传输。已经描述了将某些信息插入或编码到数据流中，同时将该描述理解为以下公开：所得到的数据流包括相应信息、标志的语法元素等。
取决于某些实现要求，可以在硬件中或在软件中实现本发明的实施例。可以使用其上存储有电子可读控制信号的数字存储介质(例如，软盘、dvd、蓝光、cd、rom、prom、eprom、eeprom或闪存)来执行实现，该电子可读控制信号与可编程计算机系统协作(或者能够与之协作)从而执行相应方法。因此，数字存储介质可以是计算机可读的。
根据本发明的一些实施例包括具有电子可读控制信号的数据载体，该电子可读控制信号能够与可编程计算机系统协作从而执行本文所述的方法之一。
通常，本发明的实施例可以被实现为具有程序代码的计算机程序产品，程序代码可操作用于在计算机程序产品在计算机上运行时执行方法之一。程序代码可以例如存储在机器可读载体上。
其他实施例包括存储在机器可读载体上的计算机程序，该计算机程序用于执行本文所述的方法之一。
换言之，本发明方法的实施例因此是具有程序代码的计算机程序，该程序代码用于在计算机程序在计算机上运行时执行本文所述的方法之一。
因此，本发明方法的另一实施例是其上记录有计算机程序的数据载体(或者数字存储介质或计算机可读介质)，该计算机程序用于执行本文所述的方法之一。数据载体、数字存储介质或记录介质通常是有形的和/或非瞬时性的。
因此，本发明方法的另一实施例是表示计算机程序的数据流或信号序列，所述计算机程序用于执行本文所述的方法之一。数据流或信号序列可以例如被配置为经由数据通信连接(例如，经由互联网)传送。
另一实施例包括处理装置，例如，计算机或可编程逻辑器件，所述处理装置被配置为或适于执行本文所述的方法之一。
另一实施例包括其上安装有计算机程序的计算机，该计算机程序用于执行本文所述的方法之一。
根据本发明的另一实施例包括被配置为向接收机(例如，以电子方式或以光学方式)传输计算机程序的装置或系统，该计算机程序用于执行本文所述的方法之一。接收机可以是例如计算机、移动设备、存储设备等。装置或系统可以例如包括用于向接收机传送计算机程序的文件服务器。
在一些实施例中，可编程逻辑器件(例如，现场可编程门阵列)可以用于执行本文所述的方法的功能中的一些或全部功能。在一些实施例中，现场可编程门阵列可以与微处理器协作以执行本文所述的方法之一。通常，方法优选地由任意硬件装置来执行。
本文描述的装置可以使用硬件装置、或者使用计算机、或者使用硬件装置和计算机的组合来实现。
本文描述的装置或本文描述的装置的任何组件可以至少部分地在硬件和/或软件中实现。
本文描述的方法可以使用硬件装置、或者使用计算机、或者使用硬件装置和计算机的组合来执行。
本文描述的方法或本文描述的装置的任何组件可以至少部分地由硬件和/或由软件执行。
上述实施例对于本发明的原理仅是说明性的。应当理解的是：本文所述的布置和细节的修改和变形对于本领域其他技术人员将是显而易见的。因此，旨在仅由所附专利权利要求的范围来限制而不是由借助对本文实施例的描述和解释所给出的具体细节来限制。
参考文献
[1]mavlankar，aditya，davidvarodayan，andberndgirod.″region-of-interestpredictionforinteractivelystreamingregionsofhighresolutionvideo.″packetvideo2007.ieee，2007。