高效的沉浸式流传输的制作方法

本申请涉及用于或适合于沉浸式视频流传输的概念。

背景技术：

近年来，从许多行业的参与可以看到，围绕虚拟现实(vr)的活动已非常活跃。动态http自适应流传输(dash)有望成为360视频的主要服务之一。

有将360°视频发送到客户端的多种流传输方法。一种简单的方法是与视口无关的解决方案。通过这种方法，整个360°视频都以视口不可知的方式传输，即不考虑当前用户的观看方向或视口。这种方法的问题在于，在用户视口之外而最终没有呈现给用户的像素占用了带宽和解码器资源。

通过使用视口相关的解决方案，可以提供更高效的解决方案。在这种情况下，发送给用户的比特流将针对呈现给用户的图片范围(即，视口)包含更高的像素密度和比特率。

当前，有两种典型方法用于视口相关的解决方案。从流传输的角度来看，例如在基于dash的系统中，用户在两种视口相关方法中都基于当前观看方向选择适配集。

两种视口相关的方法在视频内容准备方面有所不同。一种方法是通过使用将焦点放在给定方向上的投影(例如，图1的左侧，摄像机中心/投影表面已移动的erp)或通过在视口不可知投影上使按某种区域打包(rwp)并且(例如，基于常规erp的图1的右侧)从而定义比其他非优选视口具有更高分辨率的投影或优选视口的图片区域，来对不同视口的不同流进行编码。

视口相关的另一种方法是以多个比特流的形式提供内容，这是将整个内容拆分为多个图块的结果。然后，客户端可以下载与完整的360度视频内容相对应的一组图块，其中每个图块的保真度(例如，在质量或分辨率方面)都不同。这种基于图块的方法可产生图片区域的质量高于其他区域的优选视口视频。

为了简单起见，下面的描述假定非图块的解决方案适用，但是下面进一步描述的问题、效果和实施例也适用于图块的流传输解决方案。

对于任何一个视口，我们都可以得到一个流，其解码后的图片如图2所示。图2在左侧显示了全景视频，并在其中描绘有两个不同的视口vp1和vp2作为不同视口的示例。对于两个视口位置，准备了相应的流。如图2的上半部分所示，视口vp1的流的已解码图片包括将vp1编码到其中的一个较大的部分，而在图片范围左侧显示的另一部分则包含了在这里是经过旋转和缩小的整个全景视频内容。视口vp2的其他流具有以基本相同的方式组成的已解码的图片，即，相对较大的右侧部分已将vp2编码到其中，而其余部分在其中编码了全景视频的旋转和缩小版本。

图片是如何由原始完整内容组成的，通常由元数据定义，例如按区域打包的详细信息，它们以视频基本流中的sei消息的形式或以iso基本媒体文件格式的框的形式存在。以omaf环境为例，图3示出了通常在客户端侧的沉浸式视频流环境中进行协作的实体的示例。图3示出了沉浸式视频流客户端装置，在此示例性地描绘为与omaf-dash客户端模型相对应。dash检索到的媒体段和清单文件或媒体呈现描述进入由虚拟现实应用程序形成的客户端基本组件，该虚拟现实应用程序经由元数据从传感器接收传感器数据(该传感器数据涉及头部和/或用户的眼睛移动以移动视口)，并控制媒体相关组件并与之交互，媒体相关组件包括负责获取媒体段的dash访问引擎、负责对作为由dash访问引擎转发的检索到的媒体段的串联产生的结果的文件格式流中包含的编码视频流进行解包和碎片整理的dash媒体引擎、以及最终经由例如平视显示器等将视频渲染给用户的渲染器。

如上所述，图3展示了全方位media格式(omaf)标准中设想的dash流服务的高级客户端模型。omaf(及其他)描述了360视频和传输相关的元数据，以及如何将其封装到iso基本媒体文件格式(isobmff)或视频比特流(例如hevc比特流)中。在这种流传输方案中，通常使用dash，然后在那里将下载的基本流封装到初始化片段和媒体段中的isobmff中。每个表示(对应于优选观看方向比特流和给定的比特率)由初始化片段和一个或多个媒体段(即由一个或多个isobmff媒体片段组成，其中封装了给定时间间隔的nal单元)组成。通常，客户端下载给定的初始化片段并解析每个头部(电影框，也称为“moov”框)。当图3中的isobmff解析器解析“moov”框时，它将提取有关比特流和解码器功能的相关信息，并初始化解码器。它与渲染相关信息相同，并初始化渲染器。这意味着isobmff解析器(或其至少负责解析“moov”框的模块)具有api(应用程序编程接口)，能够在流播放开始时使用给定的配置来初始化解码器和渲染器。

在omaf标准中，将按区域打包框('rwpk')封装在样本条目中(也在'moov'框中)，以描述整个基本流的比特流属性。这种形式的信令向客户端(ff多路分解器+解码器+渲染器)保证媒体流将坚持给定的rwp配置，例如图2中的vp1或vp2。

但是，在上述视口相关的解决方案中，通常，对于任何潜在的视口，整个内容的分辨率都较低，如图2中的浅蓝色阴影框所示。使用这种方法更改视口(从vp1到vp2)意味着dash客户端需要下载另一个带有新的相应“rwpk”框的初始化片段。因此，在解析新的“moov”框时，由于文件格式轨道已切换，因此isobmff会对解码器和渲染器进行重新初始化。这导致以下事实情况：视口切换需要使用全图片rap，这对编码效率是有害的。实际上，没有rap的解码器的重新初始化将导致不可解码的比特流。视口切换如图4所示。

即，图4在vp2的流的顶部示出了vp1的流。时间访问范围从左到右。图4示出，周期性地，两个流中都存在rap(随机访问点)，它们在时间上彼此相互调整，使得客户端可以在流传输期间从一个流切换到另一流。图4在第三rap中示出了这种切换。如图4所示，由于上述事实情况，在这种切换时需要文件格式多路分解和解码器重新初始化。

如果可以更高效地渲染沉浸式视频流，则将是优选的。

技术实现要素：

因此，本发明的目的是提供实现这种更高效的沉浸式视频流的概念。

该任务通过本申请的独立权利要求的主题来解决。

本发明所基于的思想是，通过将切换点和/或部分随机访问点或传达指示帧到场景映射相对于第一组一个或多个区域保持恒定同时对另一组一个或多个区域变化的映射信息元数据的点概念引入到沉浸式视频环境中，可以使沉浸式视频流更加高效。特别地，本申请的思想是向沉浸式视频流中涉及的实体提供利用沉浸式视频材料经常相对于帧中的第一组一个或多个区域示出恒定的帧到场景映射，但是在仅相对于另一组一个或多个区域的帧到场景映射方面有所不同的情况的能力。事先被告知这种情况的实体可能会压制它们通常会采取的某些措施，而这将变得更加麻烦，好像这些措施被完全放弃或仅限于帧到场景映射是可能会有所变化的一个或多个区域。例如，通常与随机访问点相关联的压缩效率损失，例如不允许在随机访问点之前或之后的任何帧使用随机访问点之前的帧，可能会限于帧到场景的映射变化的一个或多个区域。同样地，渲染器可以在执行再现时利用对于特定组一个或多个区域的帧到场景映射的恒定性质的知识。

附图说明

现在，本申请的这些和其他方面是所附权利要求的主题。下面结合附图描述本申请的优选实施例，其中：

图1示出了说明视口相关的360视频方案的示意图，其中，在左侧示出可以移动摄像机中心以改变场景中的区域，例如，通过使用帧到场景的映射将帧的样本投影到场景上所生成的样本密度大于其他区域，而右侧则说明了使用按区域打包(rwp)来生成全景视频素材的不同表示，每个表示专用于某个优选的观看方向，其中本申请随后解释的实施例涉及的是后一种个性化表示；

图2示出了说明关于两个示例性示出的优选视口和对应表示的视口相关或按区域打包流方法的示意图；图2按区域定义分别与视口位置vp1和视口位置vp2相关联的表示的帧，其中两个帧，或更确切地说，两个表示的帧都具有位于同一位置的包含缩减的完整内容区域(以阴影线示出)的区域，其中，图2仅用作示例，以更容易理解随后说明的实施例；

图3示出了可以实现本申请的实施例的客户端装置的框图，其中，图3示出了客户端装置对应于omaf-dash流客户端模型的特定示例，并且示出了其中所包含的各个实体之间的对应接口；

图4示出了仅使用静态rwp的两种表示的示意图，客户端出于视口切换目的在rap处从vp1切换到vp2；

图5示出了根据本发明的使用动态rwp的实施例，客户端出于视口切换目的在切换点处从vp1切换到vp2而在其间切换的两种表示的示意图；

图6示出了用于分别映射区分静态和动态区域的信息的语法示例；

图7示出了说明沉浸式视频流中所涉及的实体的示意框图，这些实体可以被实施为根据本申请的实施例进行操作；

图8示出了说明根据本申请的实施例的在服务器处提供的数据的示意图；

图9示出了根据本申请的实施例的切换点附近的下载流从一个视口(vp)到另一视口的部分的示意图；

图10示出了根据本发明实施例的清单文件的内容和结构的示意图；以及

图11示出了说明根据图10的清单文件将表示可能分组为适配集的示意图。

具体实施方式

在描述本申请的某些实施例之前，应重新开始本申请说明书的介绍部分中的描述。特别地，描述止于图4，描述了与从一个表示切换到另一表示的相关联的低效率，但是表示的性质针对一个或多个帧区域的特定集合而言(此处是图2中描绘的左手)，实际上在表示之间是一致的。

特别地，由于某些图片部分，例如低分辨率的整个内容(图2中的阴影部分)可能在所有比特流中都可用，对该范围进行解码将不需要重新初始化解码器，并且允许非rap解码开始(对于此阴影线图片范围)，这对提高编码效率将是有利的。根据下面描述的一些实施例，允许关于rwp配置的动态性的图片区域特定保证，这可以在编码预测链的重置中得到促进。这种情况在图5中用完整和部分rap进行了说明，其中完整rap对应于图4中的rap(示出为完整高度的块)，而部分rap(示出为半高的块)对应于以下事实：仅图片的一部分，即非静态和vp特定范围被编码(例如，图2中的帧区域的右侧)，而不依赖于按比特流顺序在部分rap之前的图像，而图片的静态部分(即整个360度视频内容的低分辨率变型例(在图2中以阴影线示出))则使用按比特流顺序在部分rap之前的图片以预测方式进行编码。

随着rwp信息的扩展(其中提供了rwp的动态性指示及其区域描述)，isobmff解析器可以在初始化片段以动态模式初始化渲染器。isobmff解析器(或用于解析“moov”框的相应模块)将初始化解码器并初始化渲染器。这次，渲染器将以静态模式、完全动态模式或部分动态模式初始化，如下所述。渲染器的api将允许以不同的方式初始化，并且如果以动态模式和/或部分动态模式进行配置，则将允许对rwp中描述的区域进行比特流内重新配置。

实施例可以如图6所示。这里，如果对于基本流内的所有图片，按区域打包是恒定/静态的，则regions_type等于0。如果为1，则允许每个图片的按区域打包都可以改变。如果等于2，按区域打包将定义对于整个基本流是静态的一组区域，以及允许改变的一些区域。如果使用模式2，则在初始化片段中解析“rwpk”框。可以通过以下方式来初始化渲染器：为整个服务映射部分解码后的图片的一部分，以将其映射到360视频的一部分或全部；而解码图片的其他部分则是动态配置的，并且可以使用渲染器api进行更新。

因此，可以约束内容以静态方式针对整个视频流包含整个360视频的低分辨率版本。

由于在dash场景中，下载通常发生在(子)段边界(对应于一个或多个isobmff片段)，因此在非引导视图中，对于dash客户端确保按动态区域方式不在比(子)段更细的粒度上变化是有益的。因此，客户端知道在下载(子)段时，该(子)段中的所有图片都具有相同的按区域打包的描述。因此，另一实施例是限制按区域打包的动态性来仅以片段为基础进行变化(如果区域类型等于2)。即，再次描述动态区域或强制在片段开始处存在sei。然后，将比特流中的所有sei被约束为在isobmff片段处具有按区域打包描述的相同值。

另一个实施例基于以上任何一个，但是具有以下约束：样本条目中的regionwisepackingstruct中指示的动态区域的数量以及它们的尺寸保持恒定。唯一可以改变的是被打包的区域和/或被投影的区域的位置。显然，在静态或动态区域上的多个区域中可能具有很大的灵活性，并且只要覆盖相同的内容(例如，相同的覆盖范围)，就可以灵活选择，以实现每个时刻和每个视口最高效的传输。但是，这将需要能够处理变化很大的渲染器，这通常会导致复杂性。渲染器初始化完成后，如果可以承诺保持静态的区域数量和动态区域的数量；以及尺寸如何；这样的渲染器的实现和操作就可以简单得多，并且可以容易地执行。从而促进了isobmff解析器(或对应模块)中的api的运行和配置。

尽管如此，在这样的服务中；如果没有设置特定的约束并承诺给用户，则可能是无法提供有效的流服务。例如，想象一下，有n个视口的服务：vp1，vp2...vpn。如果vp1至vp4具有相同的静态区域，并且vp5至vpn也具有相同的静态区域；但是这两个集合的静态区域不同，由于只能在完整的rap处执行从视口vp1...vp4之一切换到视口vp5...vpn之一，客户端操作会变得更加复杂，这将需要具有更复杂操作的dash客户端来检查完整rap的可用性，并可能导致等待完整rap可用性的某些延迟。因此，另一个实施例基于以上任何一个，但是受到以下约束：以例如在清单(例如媒体演示说明-mpd)中用信号发送的媒体/表示简档，强制要求所有具有相同覆盖范围和/或视点的适配集具有相同的静态区域的静态配置。

在当前的dash标准中，有两种类型的信令可用于切换。一种是randomaccess@interval，它描述表示中随机访问点(rap)的间隔。显然，由于rap可以用于开始解码并呈现表示的内容，因此可以使用这样的点从一个表示切换到另一种表示。dash中定义的另一个属性是switchingpoint@interval。此属性可用于定位给定表示的切换点。这些切换点与rap的不同之处在于，它们不能用于从此点开始解码，但是可以用于从此点开始继续处理和解码该表示的比特流(如果已经对同一适配集的另一个表示进行了解码的话)。但是，客户端无法知道在切换点处从一个适配集中的一个表示切换到另一个适配集的另一个表示是否可以得到正确解码和呈现。另一个实施例是作为mpd的新元素或描述符的新信令，例如crossadaptationswitchingpoints是一个表示可以跨适配集使用切换点的真(true)或假(false)的元素。或者甚至crossadaptationswitchingpoints在适配集内被用新号通知并且是整数，这意味着具有相同整数值的适配集属于一组适配集，对于这些适配集，跨不同的适配集进行切换会导致可以得到正确处理和解码的有效比特流。具有相同覆盖范围和/或视点的所有适配集具有静态区域的相同静态配置的先前实施例也可以扩展为，当在mpd中指示给定的媒体/表示简档时，crossadaptationswitchingpoints被解释为真或具有相同覆盖范围和/或视点的所有适配集具有相同的整数值。或者仅仅是满足了相应的约束，而没有除了简档指示之外的其他必要指示。

另一个实施例处理参考先前片段的图片的isobmff片段中的编码图片。其中参考图片只能在当前图片的静态部分和以前图片的静态部分使用参考。来自动态部分的样本和/或任何其他元素(例如，运动矢量)不能用于解码。对于动态部分，强制使用rap或切换点信令。

因此，综上所述，作为上述实施例的基础的思想之一是可以以诸如在带宽消耗方面或者在相等带宽消耗下的视频质量方面以改善的特性来建立沉浸式视频流。如图7所示，沉浸式视频流环境可以包括：服务器10，其中存储了在其中编码有场景的数据12；以及客户端装置14，其经由诸如互联网和/或移动网络等的网络16连接到服务器10。客户端装置14包括几个组件，其中有文件片段检索器18(例如仪表盘客户端引擎)、媒体文件到视频比特流转换器20、解码器22、渲染器24和控制器26，例如，在指示当前用户的观看方向的入站传感器数据28的基础上控制检索器18和渲染器24。客户端装置14可以根据图3构造。

上述实施例所基于的思想之一是，如果以特殊方式设计表示场景的数据12，则可以实现更高效的沉浸式视频流，即在所有表示中，视频帧在第一组一个或多个区域中相对于视频帧和场景之间的映射一致，但是它们还包括第二组一个或多个区域，其中映射在各个表示之间有所不同，从而使它们成为视口特定的。下文描述细节。如图所示，贡献者400可能已经生成或准备了数据12，然后将其提供给服务器10处的客户端14。它形成了一种用于生成对场景进行编码以进行沉浸式视频流传输的数据12的装置。在每个表示中，第一组区域和第二组区域之间是清晰区分的，使得通过在各种表示之间切换来从数据12导出的最终下载的连接片段保持该特性，即相对于第一组区域的连续性，而相对于第二组区域是动态的。但是，在不进行切换的情况下，映射将是恒定的。然而，由于视口位置的改变，客户端装置试图从一种表示切换到另一种表示。每次更改表示时，都不需要重新初始化或重新打开新的媒体文件，因为基本配置保持不变，即，相对于第一组区域的映射保持恒定，而相对于第二组区域映射是动态的。

为此，数据12包括如图8所示的一组40表示42，其中每个表示包括视频44，其视频帧被细分为多个区域46。特别地，存在第一组一个或多个区域46a是所有表示42所共有的，即所有表示42的视频44的视频帧48的空间细分相对于其一致。尽管在本申请中示出了空间上一致的情况，但是所有表示42的视频44的视频帧48的其余部分可以以表示42之间不同的方式细分为一个或多个区域46b。类型46a和46b的区域之间的差异如下：一方面视频帧48和另一方面场景52之间的映射50对于所有表示42保持恒定或相同。为此，例如，以全景球表示的场景52以表示42之间一致的方式映射或部分映射到视频帧44的区域46a上。然而，在表示42之间，就区域46b而言，映射50是不同的。映射50中的一致例如涉及视频帧的范围内的各个区域的位置和大小，场景52内该区域的映射图像的(例如图8的中间表示42的图片48的区域46b的图像49)的位置和大小，以及该区域与其图像之间的投影或变换类型或样本映射。映射的差异又涉及这些参数中的任何一个的偏差。对于区域46a，所有这些特征在表示24之间是相同的，即，区域46a具有相同的大小并且位于所有表示的视频帧48内的相同位置。例如，在具有区域46b的所有表示42之间，视频帧48具有相同的大小，但是，例如，尽管它们在视频帧的范围内位于同一位置并且具有相同的大小，但是通过映射50与场景52中不同的图像相关。因此，与另一表示的视频帧48的区域46b相比，一种表示的视频帧48的区域56b例如示出了场景52的另一部分。换句话说，在区域46a内，各个表示的视频帧与场景之间的映射50保持恒定，而在区域46b内的各个表示之间，视频帧与场景之间的映射50可以在以下方面有所不同：1)根据映射50，场景中视频帧的区域46b的图像的位置，和/或2)一组动态区域(例如区域46b)的周边，和/或3)场景52中动态区域及其图像之间的样本映射。上面参考图2中的vp1和vp2的示例描述了详细示例。如后一示例所示，与将场景或其一部分编码为静态区域46a的分辨率相比，将场景的一部分编码为区域46b的空间分辨率可以提高。同样，场景52内区域46b的映射图像可能比区域46a的图像更大。

如图5所示，每个表示42被分成片段54，片段54分别覆盖场景52的相应视频44的时间上连续的时间间隔56。每个片段54包括关于映射50的映射信息58，该映射信息至少关于片段54所属的相应表示42内的视频帧48的第二组一个或多个区域46b。如上所述，该映射信息58可以例如包含在媒体文件头部中。它可以附加地包括关于涉及相应片段54内的视频帧48的第一组一个或多个区域46a的映射50的信息，尽管这与视频帧的恒定部分有关。附加地或可替代地，映射信息58例如通过sei消息被包含在每个片段54所包括的视频比特流中。这意味着以下含义：每个表示42实际上可以是由一系列片段54组成的媒体文件，每个片段54可以包括媒体文件头部60和一个或多个有效载荷部分62，或者换句话说-媒体文件片段，形成一系列此类媒体文件片段。有效载荷部分62承载视频比特流的片段，具有在其内编码的时间间隔56内的视频帧48，片段54属于该视频帧。该视频比特流片段64在例如sei消息内包含映射信息58′。片段54是文件片段检索器18能够以其为单位从服务器10检索表示42的那些片段。为此，例如，文件片段检索器18基于清单文件或从服务器10获得的媒体表示描述计算相应的地址，例如http地址。图10中说明了此类文件的示例。映射信息58可以根据以下一项或多项来定义预定区域46a/b的映射50：

-预定区域的视频帧内位置，例如在图8的示例中所做的，对任何区域46a，经由在202语法部分rectregionpacking处调用的静态类型i；以及对任何区域46b，经由在206语法部分rectregionpacking处在204处分别调用的动态类型i；在204处的语法通过定义拐角之一的位置以及宽度和高度来定义区域的准周长；或者，可以为每个区域定义两个对角相对的拐角；

-预定区域的场景位置，例如在图8的示例中所做的，对任何区域46a，经由在202语法部分rectregionpacking调用的静态类型i；以及对任何区域46b，经由在206语法部分rectregionpacking处在208处分别调用的动态类型i；在204处的语法通过定义拐角之一的位置(或两个相交的边，例如由纬度和经度定义)以及图像的宽度和高度(例如由经纬度偏移量定义)来根据映射50定义场景中每个区域的图像49的准位置；或者，可以为每个区域定义两个对角相对的拐角(例如由两个纬度和两个经度定义)；

-预定区域的视频帧到场景的投影，即在内部将相应区域46a/b映射到球体52的确切方式的指示；例如在图8的示例中所做的，对任何区域46a，经由在202语法部分rectregionpacking处调用的静态类型i；以及对任何区域46b，经由在206语法部分rectregionpacking处在210处分别调用的动态类型i，即在此通过索引一些预定义的变换/映射类型来示例；换句话说，此处定义了第二组一个或多个区域与其在场景中的图像之间的样本映射。

此外，表示42具有以某种方式编码的视频帧48，即，它们包括随机访问点66和切换点68。随机访问点可以在表示之间对准。可以相对于两种类型的区域46a和46b都独立于相应表示的先前片段来编码某个随机访问点的片段。例如，因为该片段544与随机访问点66相关联或在时间上对准该随机访问点66，所以区域544被编码为与两个区域类型46a和46b内的任何先前的片段541至543无关。与切换点68相关联或在时间上对准的片段仅相对于第二类型的区域(即区域46b)，独立于相应表示42的先前片段而被编码(如122所示)，但是可预测地依赖于区域46a内的先前片段(如124所示)。例如，区域545是就区域46a而言，对任何先前片段541至544具有预测依赖性的片段，从而与rap片段相比，降低了这些片段的必要比特率。

由于以上述方式设计了数据10，因此由客户端装置14下载的媒体流保持有效，因为关于该数据10的表示42中的每个，恒定特性保持相同。为了对此进行说明，假定上述情况是从表示421切换到422的情况。数据12例如包括每个表示42的初始化片段70，该初始化片段包括相应表示42的文件头部。初始化片段70或片段70内的头部(有时会将附图标记重复用于其中的头部)包括映射信息58，或换句话说，包括其另一实例，至少就恒定区域46a而言。然而，它可替代地包括相对于完整映射50(即相对于区域46a和46b对两者不加区分，即指示一个区域为恒定(即区域46a)并另一个为动态(即区域46b))的映射信息58。有趣的是，当将表示42视为单独地驻留在服务器10上时，这种区分还没有意义。然而，当观看最终由客户端装置14下载的媒体文件时，其含义和意义变得清楚。还要注意，映射信息的附图标记58现在已经在语义上用于其在不同的位置处的实际不同的实例：在片段和初始化片段。重复附图标记的原因是信息的语义一致。

特别地，在下载时，文件片段检索器18开始于检索首次下载的表示的初始化片段70以及该表示的首次检索的片段。在上面的示例中，第一个表示是421。然后，在某个切换点68处，文件片段检索器18从表示421切换到表示422。图9示出了围绕这样的切换120从一个表示到另一表示检索的片段的这种下载流19中的各个部分。但是，文件片段检索器18不需要检索表示422的初始化片段。不需要开始新文件。而是，文件片段检索器18直接继续检索与切换点68相关联或时间上对准的表示422的片段543，如上所述，在其片段头部60中具有映射信息58。客户端装置14或更准确地说，客户端装置14所包括的文件片段检索器18形成了一种用于通过沉浸式视频流从服务器10流传输场景内容的装置，并且被配置为在另一种表示的切换点之一处从一种表示切换到另一种表示。

媒体文件到比特流转换器20从文件片段检索器18接收下载的片段的序列，即表示421的片段541和542，其后是表示422的片段543，依此类推，并且看不到要重新初始化解码器22的任何冲突或动机：媒体文件头部仅已被媒体文件到比特流转换器20接收一次，即在开始时，即在表示421的片段541之前。此外，常量参数保持恒定，即相对于区域46a的映射信息。变化的信息不会丢失，并且仍然留在其接收者(即渲染器24)中。

首先，媒体文件到比特流转换器20接收下载的媒体比特流，该媒体比特流是由来自不同表示文件42的一系列片段组成的媒体文件，剥离片段头部60，并通过连接片段64转发片段视频比特流的包。解码器22将由比特流片段64的序列形成的视频比特流内的映射信息58′转换为元数据，解码器22将元数据转发给渲染器24，以伴随解码器22从视频比特流解码的视频。渲染器24又能够渲染来自解码器22已经从入站下载视频比特流中解码的视频的输出帧。输出帧示出当前视口。

因此，解码器从转换器20接收视频比特流，视频帧的视频被编码到视频比特流中。视频比特流本身可以包括诸如sei消息形式的映射信息50。可替代地，解码器以元数据的形式接收该信息。映射信息将视频帧和场景之间的映射50通知解码器，其中视频比特流包含相对于第二组一个或多个区域的映射信息的更新。

解码器22可以利用以下事实情况：存在不同类型的区域46a和46b，即恒定区域和动态区域。

举例来说，视频解码器22可仅一次将映射50通知渲染器24，或者以相对于区域46a的第一更新速率且以相对于区域46b的第二更新速率将映射50通知渲染器24，其中第二更新速率高于第一更新速率，从而与在每次相对于动态区域46b改变映射50的情况下更新完整映射50的情况相比，减少了从解码器22到渲染器24的元数据量。解码器可以通过伴随解码器输出的视频的映射信息元数据，将视频帧与场景之间的映射通知渲染器，其中，映射信息元数据可以指示一次视频帧与场景之间的映射，即针对该时刻，然后通过相应的元数据更新进行更新。映射信息元数据可以具有与到目前为止讨论的映射信息实例相似或甚至相同的语法。

附加地或可替代地，视频解码器可以将视频帧的细分解释为恒定区域和动态区域，以保证视频比特流使用运动补偿预测来对视频帧进行编码，从完全驻留于参考视频帧的第一组一个或多个区域中的参考视频帧内的参考部分预测区域46a内的视频帧。换句话说，可以将区域46a的运动补偿保持在相应区域的边界内，以便仅从参考图片内的相同位置的区域46a预测一幅图片内的区域46a，即，不涉及运动预测，或者运动预测不会超出该区域的边界延伸到任何其他区域，或者至少没有动态类型的区域(例如区域46b)。解码器可以使用该承诺来将静态区域46a分配给与动态区域的解码并行的解码，而不必在时间上将区域46a的解码与相同图片中的区域46b的解码的当前进度对准。解码器甚至可以利用承诺，以便在解码运动补偿参考视频帧的任何动态区域46b的相邻部分之前开始解码当前视频帧的静态区域46a的边缘部分。

此外，附加地或可替代地，视频解码器可以利用以下事实情况：切换点是一种部分随机访问点，即为了相对于切换点之前的片段的视频帧的不再需要的区域46b在其解码图像缓冲器(dpb)中重新分配当前消耗的存储空间。换句话说，解码器可以调查由信息58在检索到的片段中传递的映射信息更新，其更新了视频比特流中第二组一个或多个区域的映射50，以便识别发生映射50相对于一第二组个或多个区域的变化的场合，例如在片段120处。然后，这种情况可由解码器22解释为部分随机访问点，即相对于区域46b的部分rap，结果，对于参考图片的区域46b执行刚刚概述的dpb存储容量的取消分配，保证不再使用。如图6的示例中所示，可以以如下方式设计映射信息58：解码器可以通过语法顺序将静态区域与动态区域区分开，在该语法顺序下，映射信息依次与一个或多个静态区域以及一个或多个动态区域相关。例如，解码器读取第一数量的静态区域，即static_num_regions，以及第二数量的动态区域，即dynamic_num_regions(参见图6)，然后从区域上的映射信息中读取区域特定信息(例如204、210和208)的频率与两个数量的总和相同，并将第一数量解释为静态区域，将第二数量解释为动态区域。静态和动态区域之间的顺序自然可以切换。可替代地，可以对应于静态和动态区域的总数读取多次这样的区域特定信息的实例，其中每个区域特定信息包括指示或标志，即关联语法元素，指示相应区域特定信息所涉及的相应区域是静态的还是动态的。

进而，渲染器24还可利用以下知识，即一些区域(即区域46a)具有恒定的性质：对于这些区域，渲染器24可以使用从入站解码视频到输出视频的恒定映射，同时对动态区域(例如区域46b)使用更复杂的逐步转换。

可由检索器18用来顺序检索片段的上述清单文件或mpd可以是数据10的一部分。这里也以图10中的附图标记100示出了其示例。文件100可以例如是xml文件。作为示例，对于先前示出的每个表示42，它可以具有定义了语法的语法部分102。在此，每个语法部分都定义了一适配集表示。参见图11所示的示例。因此，每个适配集分别收集具有分别不同质量q#和比特率的表示42。质量差异可以涉及snr和/或空间分辨率等。就映射50而言，一个适配集43内的表示42可以彼此对应。也就是说，映射50甚至对于区域46a和46b是相等的，并且视频帧大小一致，或者映射50对于区域46a和46b除尺寸外相等，并且视频帧的大小根据一个适配集43中的表示之间的空间分辨率差异相对于彼此缩放。

语法部分102可以针对每个适配集指示相应适配集合内的表示的高分辨率区域(例如，46b)的映射50或视口方向104。此外，每个语法部分102可以为由相应语法部分102定义的适配集合内的每个表示，指示用于获取相应表示的片段64的获取地址106，例如经由计算规则的指示。除此之外，每个语法部分102可以包括在相应表示内的rap66的位置的指示108和sp68的位置的指示110。rap可以在适配集之间一致。sp可以在适配集合之间一致。另外，清单文件100可以可选地包括关于sp是否另外可用于从适配集的任何表示切换到其他适配应集的任何表示的信息112。信息112可以以许多不同的形式体现。信息可以针对所有适配集全局地发信令，sp可以被用来在相等质量等级(对于其映射50是相同的)但具有不同适配集的表示之间进行切换。在图11中的300处通过虚线示出了该切换限制，该虚线互连了可以允许进行切换的不同适配集的相等质量等级q#的表示。可替代地，如在304处所描绘的，信息112可以由为每个适配集43的每个表示42所分配的索引302来体现，其约定是在sp处允许在相等索引的表示之间进行切换。因此，在允许的情况下，检索器18不需要检索其切换到的表现形式的初始化片段70，并且有效地避免了解码器的重新初始化。甚至可替代地，可以为每个适配分配集id，即，全局地用于每个适配集内的所有表示，从而指示可以将具有相同id的适配集的所有表示的sp用于不同的适配集之间的切换。甚至可替代地，可以通过能够将清单文件与不同简档相关联的简档指示符来共同标记(即指示)信息112。一个可能是omaf简档，它暗示某些约束适用，例如a)允许在一适配集的所有表示之间，在质量水平上一致的不同适配集的表示之间或在质量水平等方面的差异小于一定量的不同适配集的表示之间进行切换。后者的一定量也可以作为信息112的一部分发出信令。简档指示符可以是，例如，m元语法元素，通过假设一个特定状态，该语法元素强制转换omaf简档。它将由信息112组成。检索器在确定不同视口方向的表示(即，属于不同适配集的表示)之间可能的切换点时做出相应的动作，或者换句话说，在搜索属于与所需的视口方向相关联的适配集的表示的sp中做出相应的动作。

可以注意到，以上概念还可以在面向实时通信的场景(例如，经由rtp或webrtc的低延迟流传输)中的会话协商的上下文中体现出来。在这种场景下，拥有所需媒体的服务器充当会话系统中的一个通信端点，而需要所需媒体数据的客户端充当另一通信端点。通常，在建立通信会话(即流传输会话)期间，交换或协商某些媒体特性和需求，这与基于http的媒体流传输中的媒体表示描述的目标非常相似，其告知一个端点所提供的媒体特性和需求，例如编解码器级别或rwp详细信息。

在这种场景下，其例如可以是会话描述协议(sdp)交换的一部分，用于交换或协商关于媒体数据的rwp的特性，例如服务器通知客户端有关以下内容的可用性：a)没有rwp(按比特率低效率)的媒体数据，b)经典rwp(全图片rap，比a)更有效)，或c)根据上述描述的动态rwp(具有最高比特率效率的部分图片rap)。结果所得的场景将对应于图7的描述，并进行以下修改：

服务器10和客户端14将表示要从端点10(可能仍称为服务器)到14(可能仍称为客户端)建立视频流传输之间的通信端点或通信设备。客户端可以包括组件20和22以及可选地包括组件24和26，并且检索器将由执行谈判的谈判器代替。服务器不必访问如上所述视频的各种表示。将要流传输的视频可以在运行中或通过准备进行渲染，并且在相应的提议消息中提供彼此区分的版本，在某种程度上对应于到目前为止针对图7所述的流传输环境中的清单，并且从服务器10发送到客户端14，区别仅在于：a)不使用按区域打包，b)仅对静态区域使用按区域打包，以及c)使用包括至少一个动态区域的按区域打包。选项a是可选的，可以省略。客户端将应答消息发送到服务器，该应答消息选择提供的媒体版本之一。选项c导致从服务器10发送到客户端14的视频比特流可能符合上述描述，即，选项c中可能包含rwp消息58。如果解码器22和/或媒体转换器20能够处理动态区域，则该选项可以仅由客户端14选择或允许由客户端14选择。在使用选项b的情况下，每次映射50随着一个动态区域改变时，服务器10可以发送初始化头部。即，服务器10将以至少两种版本向客户端提供视频：一种版本是将视频编码为连续的视频比特流，然后从服务器发送到客户端，其方式是将视频的视频帧细分为第一组一个或多个区域和第二组一个或多个区域，其中视频帧和场景之间的映射在第一组一个或多个区域内保持恒定，而在第二组一个或多个区域内是动态的或变化的；另一版本是将视频编码为覆盖视频的时间连续间隔的视频比特流的连接，然后从服务器发送到客户端，其方式是在连接的每个视频比特流中，将视频的视频帧细分为一组区域，其中视频帧与场景之间的映射在该组区域内保持恒定，而在所有视频比特流的连接中，该组区域包括第一组一个或多个区域和第二组一个或多个区域，其中视频帧和场景之间的映射相对于连接在第一组一个或多个区域内保持恒定，同时在第二组一个或多个区域中是动态的或变化的。如所讨论的，服务器可以在第二选项中在视频比特流的连接之间插入初始化头部。这些初始化头部可能具有与其相关(以及分别在其之前)的相应视频比特流的映射信息。在第一种选项中，视频比特流可以如上所述被解释。片段化成片段可以适用也可以不适用。因此，服务器将被配置为在实际将视频流传输到客户端之前的协商阶段，将提供两种版本的视频的提议消息发送给客户端，并从客户端接收选择一个或多个所提供选项的相应应答消息。取决于所提供的选项，服务器将以讨论的方式提供视频。客户端将被配置为接收提议消息并通过选择所提供版本之一的相应应答消息来应答。如果选择第一选项，则客户端内的解码器和/或媒体转换器将以上述方式操作以处理动态rwp。

在另一种场景下，客户端使用以上概念来向服务器通知他期望的动态rwp配置，例如期望静态区域、静态概览图片部分的分辨率为多少，或者覆盖视口的动态图片部分、动态区域应包含哪些视野。经过这样的协商交流和确认，客户端将只需要在要包含在动态区域中的当前查看方向上更新另一个端点(即服务器)，而相应的端点(即服务器)将知道如何更新动态部分，从而正确示出了新的观看方向。即，在此，服务器10可能不提供刚刚提到的选项b和c的版本，而仅提供选项c。另一方面，虽然在上一段中，映射的变化可能起源于服务器侧，但此处，映射改变是在客户端侧发起的，例如经由图7中讨论的传感器信号，由客户端14向服务器10发送相应的控制消息。结果所得的场景将与上段中描述的图7的变型例相对应，但提议消息和应答消息是可选的。客户端14期望根据选项c从服务器14接收视频比特流。为了控制关于动态区域的映射，客户端向服务器发送指示映射50的变化的控制信号。这样流传输的视频比特流可以对应于上述结果，即，其中包含映射信息58。片段化成片段可以适用也可以不适用。这里，可以将指示对动态区域的映射改变的中间控制消息与从客户端发送到服务器的协商控制消息区分开，该协商控制消息指示关于静态区域的映射，以及可选地，关于动态区域的映射的第一设置。因此，服务器将被配置为按照以上根据选项c所讨论的方式提供视频，并且响应于来自客户端的中间控制消息以改变对视频比特流的后续帧的动态区域的映射50。可选地，服务器将响应协商控制消息以最初建立到静态区域的映射50。结合上述选项b和c之间的协商，在选择了选项b的情况下，服务器可以通过如当前中间控制消息所示停止流传输当前静态rwp的当前视频比特流并开始流传输不同的静态rwp的后续视频比特流来响应中间控制消息。客户端将被配置为通过选择所提供版本之一的相应应答消息来接收提议消息并应答。如果选择选项c，则客户端内部的解码器和/或媒体转换器将以上述方式操作以处理动态rwp。

尽管已经在装置的上下文中描述了一些方面，但是很明显，这些方面也代表了对相应方法的描述，其中框或设备对应于方法步骤或方法步骤的特征。类似地，在方法步骤的上下文中描述的方面也表示对相应装置的相应框或项目或特征的描述。方法步骤中的一些或全部可以由(或使用)硬件装置(例如，微处理器、可编程计算机或电子电路)执行。在一些实施例中，最重要的方法步骤中的一个或多个可以由这样的装置执行。

上面讨论的本发明的信令，例如媒体文件、视频比特流、日期集合和清单文件，可以存储在数字存储介质上，或者可以在诸如无线传输介质的传输介质或诸如互联网的有线传输介质上传输。

取决于某些实现方式要求，本发明的实施例可以以硬件或软件来实施。可以使用数字存储介质来执行该实现方式，例如，软盘、dvd、蓝光、cd、rom、prom、eprom、eeprom或flash存储器，其中存储了电子可读控制信号，与可编程计算机系统协作(或能够协作)，从而执行相应的方法。因此，数字存储介质可以是计算机可读的。

根据本发明的一些实施例包括具有电子可读控制信号的数据载体，该电子可读控制信号能够与可编程计算机系统协作，从而执行本文描述的方法之一。

通常，本发明的实施例可以被实现为具有程序代码的计算机程序产品，当计算机程序产品在计算机上运行时，该程序代码可用于执行上述方法之一。程序代码可以例如被存储在机器可读载体上。

其他实施例包括存储在机器可读载体上的，用于执行本文描述的方法之一的计算机程序。

换句话说，因此，本发明方法的实施例是一种计算机程序，所述计算机程序具有当计算机程序在计算机上运行时用于执行本文描述的方法之一的程序代码。

因此，本发明方法的另一实施例是一种数据载体(或数字存储介质，或计算机可读介质)，包括记录在其上的、用于执行本文描述的方法之一的程序代码的计算机程序。数据载体、数字存储介质或记录介质通常是有形的和/或非暂态的。

因此，本发明方法的另一实施例是表示用于执行本文描述的方法之一的计算机程序的数据流或信号序列。数据流或信号序列可以例如被配置为经由数据通信连接，例如经由互联网来传输。

另一实施例包括处理装置，例如计算机或可编程逻辑器件，其被配置为或适于执行本文描述的方法之一。

另一实施例包括一种计算机，所述计算机上安装了用于执行本文描述的方法之一的计算机程序。

根据本发明的另一实施例包括一种装置或系统，所述装置或系统被配置为(例如，以电子方式或光学方式)将用于执行本文描述的方法之一的计算机程序传输给接收器。接收器可以是例如计算机、移动设备、存储设备等。所述装置或系统可以例如包括用于将计算机程序传输到接收器的文件服务器。

在一些实施例中，可编程逻辑器件(例如现场可编程门阵列)可以用于执行本文描述的方法的一些或全部功能。在一些实施例中，现场可编程门阵列可以与微处理器协作以便执行本文描述的方法之一。通常，所述方法优选地由任何硬件装置执行。

可以使用硬件装置，或使用计算机、或使用硬件装置和计算机的组合来实现本文描述的装置。

本文描述的装置或本文描述的装置的任何组件可以至少部分地以硬件和/或软件来实现。

可以使用硬件装置，或使用计算机，或使用硬件装置和计算机的组合来执行本文描述的方法。

本文描述的方法或本文描述的装置的任何组件可以至少部分地由硬件和/或软件执行。

上述实施例仅用于说明本发明的原理。应当理解，本文描述的布置和细节的修改和变化对于本领域的其他技术人员将是清楚的。因此，本发明的意图仅由待审的专利权利要求的范围限制，而不受通过本文的实施例的描述和解释而给出的具体细节的限制。