对与多视图再现设备一起使用的视频数据信号进行编码的方法

摘要

本发明涉及一种对与多视图再现设备一起使用的视频数据信号进行编码的方法，一种对视频数据信号进行解码的方法，该视频数据信号，视频数据信号的编码器，视频数据信号的解码器，一种包括用于对视频数据信号进行编码的指令的计算机程序产品以及一种包括用于对视频数据信号进行解码的指令的计算机程序产品。该编码方法包括提供（401）与第一视点相关联的场景的第一图像（10）、与第一图像相关联的深度图（20）、在深度图处理或通过多视图再现设备针对另外的视点再现一个或多个视图中使用的元数据（30），以及生成（404）视频数据信号。该视频数据信号包括在子图像中分割的视频帧，该子图像包括基于第一图像的第一子图像和基于深度图的深度子图像，以及在深度子图像的颜色分量中编码的元数据。

说明书

技术领域

本发明涉及对与多视图再现设备一起使用的视频数据信号进行编码的方法、解码视频数据信号的方法、视频数据信号、与多视图再现设备一起使用的视频数据信号的编码器、视频数据信号的解码器、包括用于编码视频数据信号的指令的计算机程序产品以及包括用于解码视频数据信号的指令的计算机程序产品。

背景技术

在过去的二十年间，三维显示技术已经成熟。三维（3D）显示设备通过为观看者的每一只眼睛提供正被观看的场景的不同视图来向观看体验添加第三维度（深度）。

作为结果，我们现在具有各种方式来观看三维图像/视频信号。一方面，我们具有基于眼镜的三维显示系统，其中向用户呈现针对她/他的左眼和右眼的不同图像。另一方面，我们具有自动立体三维显示系统，其为观看者的肉眼提供场景的三维视图。

在基于眼镜的系统中，主动/被动眼镜提供过滤器，该过滤器用于分离如在场景上针对观看者的相应眼睛呈现的不同图像。在免戴眼镜或自动立体系统中，设备常常是多视图显示器，其使用（例如障碍物或透镜的形式的）光引导构件来将左图像引导到左眼并且将右图像引导到右眼。

为了提供用于与立体多视图显示设备一起使用的内容，一段时间以来已经设计了各种输入格式，特别地还用于一方面诸如机顶盒、蓝光播放器之类的内容递送设备与另一方面诸如电视之类的显示/再现设备之间的设备接口。

一段时间以来，已经定义了各种各样的格式以用于通过诸如HDMI，DVI或DisplayPort之类的设备接口传送视频数据。随着立体图像再现和自动立体显示器的引入，出现了对于提供用在立体图像再现中的内容的进一步需要。一种这样的格式公开在PCT申请WO2006/137000（A1）中，其涉及描述图像和深度信息以及可选地遮挡图像和遮挡深度可以如何以矩阵形式通过诸如HDMI之类的现有设备接口传送的格式。该方案背后的总体思路是再用现有标准化设备接口以便向新的自动立体显示设备递送内容。

最近，HDMI设备接口格式已经适于还处置在立体图像生成中的使用的视频数据，如在使用以下链接：http://www.hdmi.org/manufacturer/specification.aspx从HDMI网站下载可得到的文献“High-DefinitionMultimediaInterfaceSpecificationVersion1.4aExtractionof3DSignalingPortion”中所公开的那样。

发明目的

发明人观察到，像HDMI那样的现有音频/视频接口格式对于需要图像和深度信息的用于基于图像的再现的格式仅具有有限支持。例如，在HDMI1.4b中，仅存在对于传送左图像和相关联的深度图的基本支持。因此，看起来存在进一步改进的空间。

发明内容

发明人认识到，对人们而言，有利的是，添加例如也提供对于立体图像和相关联的深度信息的传输的支持的另外的格式。而且，如稍后将更加详细讨论的，将会进一步有益的是，还提供对于补充信息（比如SEI）从源设备到接收设备（sinkdevice）的传输的更精细的支持。

根据本发明的第一方面，提供了一种根据权利要求1的对与多视图再现设备一起使用的视频数据信号进行编码的方法。

可选地，视频信号可以具有基于具有相应视点（例如左视点和右视点）的相应图像（例如称为第一图像和第二图像）的两个（或更多）子图像。这些子图像中的一个或二者可以具有相应深度子图像。元数据可以编码在一个或两个相应深度子图像中。可选地，在权利要求限定元数据编码在颜色分量中的情况下，元数据可以编码在两个或更多颜色分量中。

优选地，来自深度图的信息编码在一个或两个另外的子图像的亮度值中并且来自元数据的信息编码在一个或两个另外的子图像的色度值中，从而导致输送视频数据信号的向后兼容的方式。

优选地，包括在视频数据信号中的信息包括基本上未经压缩的二维数据阵列。

优选地，该方法进一步包括使用一个或多个位串行数据线通过接口向多视图再现设备传输视频数据信号。

优选地，元数据插入在用于每一个字段、用于每一帧、用于每一图片组和/或用于每一个场景的视频数据信号中。

优选地，元数据提供有校验和，元数据将被解码器侧处的视图再现或深度图处理所使用。元数据中的错误的影响可能是显著的。在传送诸如RGB像素之类的未经压缩的图像数据的数据接口中，像素值中的错误将不会导致过度感知错误。然而，元数据中的错误可能导致针对帧的再现视图基于错误的深度信息进行计算和/或使用错误的再现设置。这一点的影响可能相当显著并且作为结果，这样的错误的检测是需要的并且冗余和/或纠错码的使用是优选的。

优选地，元数据包括指示所提供的元数据是否为新的新鲜度信息，以便帮助创建用于在解码侧处置元数据处理的更高效的控制过程。

优选地，元数据包括指示元数据自从前一帧以来是否改变的信息。而且，这允许控制过程变得更加高效，因为不需要刷新/更新未改变的设置（即使它们被传输）。

优选地，该方法进一步包括处置编码和传送具有立体深度信息的立体视频数据。

根据本发明的第二方面，提供了一种视频数据信号，如权利要求10中所要求保护的与多视图再现设备一起使用的视频数据信号（50）。

根据本发明的第三方面，提供了一种数据载体，包括非暂时性形式的权利要求10或11中任一项的视频数据信号。该数据载体可以是诸如硬盘驱动器或固态驱动器之类的存储设备的形式，或者光盘形式的数据载体。

根据本发明的第四方面，提供了一种根据权利要求13的对与多视图再现设备一起使用的视频数据信号进行解码的方法。

根据本发明的第五方面，提供了一种根据权利要求15的用于对与多视图再现设备一起使用的视频数据信号进行解码的解码器。

根据本发明的第六方面，提供了一种计算机程序产品，包括用于使处理器系统执行根据权利要求1-9中任一项的方法的指令。

根据本发明的第七方面，提供了一种计算机程序产品，包括用于使处理器系统执行根据权利要求13-14中任一项的方法的指令。

根据本发明的第八方面，提供了一种根据权利要求22的与多视图再现设备一起使用的视频数据信号的编码器。

本发明的这些和其它方面根据以下描述的实施例显而易见并且将参照这些实施例进行阐述。

附图说明

在图中：

图1示出通过HDMI的2D+深度格式的传送的示意性表示，

图2示出通过HDMI的立体+深度格式的传送的示意性表示，

图3示出3D再现链中的根据本发明的编码器和根据本发明的解码器的框图，

图4示出根据本发明的解码方法的流程图，

图5A示出根据本发明的编码方法的流程图，

图5B示出根据本发明的可替换的编码方法的流程图，以及

图5C示出根据本发明的更加可替换的编码方法的流程图。

应当注意的是，在不同图中具有相同参考标号的项具有相同的结构特征和相同的功能，或者是相同的信号。在已经解释了这样的项的功能和/或结构的情况下，没有必要在详细描述中重复其解释。

具体实施方式

发明人观察到，旨在用于多视图3D呈现的视频和相关联的深度信息可以通过将可用视频帧划分成用于视频和深度的子图像来使用像HDMI、DVI和/或DisplayPort那样的标准互连/设备接口格式而被传输到自动立体显示器。

由于典型地用在设备接口上的图像信息被设计成能够承载R，G和B信息的至少8位样本（即每像素25位），并且与像素相关联的深度典型地不要求每像素满24位，因此子图像中的传输带宽未被最优地使用。

出于此原因，发明人宁愿以使得深度信息编码在这些子图像的亮度样本中的这样的方式传输子图像中的深度信息，使得旨在增强和/或指导视图生成过程的元数据可以存储在深度子图像的色度样本中。[也就是说，在其中存储深度子图像的图像信息中]。

本发明适用于从HDMI（或类似的）设备接口接收视频和深度输入信号的自动立体显示器。本发明同样适用于具有HDMI、DVI、DisplayPort或其它设备接口并且提供对于基于视频和深度3D格式的支持的媒体播放器、机顶盒、手持/移动设备、平板电脑、pc等。

HDMI是用于从内容源（媒体播放器、机顶盒和其它内容源）向接收设备（显示器、TV、AV接收器）传输视频和音频的主导设备接口格式。HDMI标准最初被定义成支持高达全HD分辨率（1920x1080和2048x1080）的视频分辨率，已经具有对于2160p（也称为4k）分辨率的有限支持，诸如3840x2160和4096x2160，并且预期在该标准的未来版本中具有对于4K格式的更宽支持。

最新可用的HDMI规范是版本1.4b。显然，版本1.4a已经支持2-视图立体形式的立体视频内容的传输；即使用立体对的左和右图像。而且，存在传输左图像和相关联的深度的选项，也被称为2D+深度或图像+深度。

除了视频和音频之外，HDMI可以借助于所谓的InfoFrames传输有限量的标准化控制和配置数据。显然，存在诸如DVI和DisplayPort之类的可替换的视频（设备）接口，其主要由个人计算机使用。

对于多视图三维（3D）图像再现，设备优选地接收具有相关联的深度信息和元数据的一个或多个视图。

用于视频和深度的各种压缩格式当前处于发展之中，除了ITU-T（VCEG）和ISO/IEC（MPEG）之外。这些压缩格式还支持包含补充增强信息（SEI），其对于解码过程而言是不需要的，但是可能有益于解码的图像的最佳可能呈现。

然而，与常规视频的情形相反，预见到特别是对于自动立体显示设备，基于图像的再现的部分将由自动立体显示设备进行以便能够支持各种专有显示设备实现方式。作为结果，与常规2D视频中的情形相反，存在对于向自动立体显示设备传输再现相关元数据的更大需要。特别地，预见到压缩流中的SEI元素，其可以包含改进自动立体显示设备处的再现过程的信息。

本发明通过利用2160p视频样本以传输高达具有对应深度和补充信息（元数据）的两个全HD视频视图来解决所提到的问题。为了实现该目标，2160p视频帧被细分成4个象限（子图像），每一个包含四个分量之一：左视图视频帧（L）、右视图视频帧（R）、针对L的深度和针对R的深度。在深度子图像中，仅亮度分量用于深度。色度分量用于补充信息。

简而言之，现有技术解决方案典型地提供对于基于图像的再现的贫乏支持；即更特别地，看起来存在对于更高级/精细的深度图数据的不足支持，并且看起来在提供用于增强/改进视图再现过程的元数据方面的存在普遍缺乏。

本发明涉及用于例如在独立媒体播放器（包括广播接收器/解码器和移动设备）与显示设备之间传输视频、深度和元数据的互连格式；即设备接口。这样的互连格式的一个示例是HDMI。其它示例是DVI和DisplayPort。本发明还涉及设备内的视频互连，例如在通过双绞线（LVDS）的子组件之间。

取决于源内容，互连格式可以包含具有相关联的深度或视差图（2D+深度）的单个视图视频分量，或者具有一个或两个附加深度分量（立体+深度）的两个视频视图。

如本领域技术人员将清楚的，深度与视差粗略成反比，然而在显示设备中深度到视差的实际映射经受各种设计选择，诸如可以由显示器生成的视差的总量、向零视差分配特定深度值的选择、所允许的交叉视差的量等。然而，提供有输入数据的深度数据用于以深度相关的方式扭曲图像。因此视差数据在此被定性地解释为深度数据。

如以上针对2D+深度所指示的，已经存在针对HDMI1.4b（和1.4a，部分地通过从www.hdmi.org下载可得到）中的渐进视频（progressivevideo）定义的可选格式。立体+深度由于每秒可以传输的像素数目的限制而不能在HDMI1.4b中传输。对此，需要更高速度，如预期在HDMI的未来修订版本中变成可用的那样，在下文中称为HDMI2.0。

如果通过接口传输2D+深度，纹理和深度属于相同（L或R）视图。在立体情况中，两个纹理视图具有与左眼视图（L）和右眼视图（R）的固定关联。在该情况中，两个深度视图具有与两个纹理视图的固定关系。如果在立体情况中两个深度视图中的一个未呈现在编码位流中，将HDMI格式中的相关深度设置成全部为零并且在补充信息（元数据）中包括适当的信令。如以上所指示的，该元数据包括在深度像素的颜色分量中。

可选的2D+深度格式已经定义在HDMI1.4a规范的附录H中。接收设备可以通过EDID信息中的HDMIVSDB指示对于该格式的支持。对于2D+深度（或“L+深度”），3D_Structure_ALL_4位应当被设置成1。参见“High-DefinitionMultimediaInterfaceSpecificationVersion1.4aExtractionof3DSignalingPortion”的表H-7。从源到接收装置的信令应当通过HDMI厂商特定InfoFrame通过根据表H-2将3D_Structure字段设置成0100（L+深度）来完成。该选项仅可用于渐进视频，优选地具有VIC码16（1080p60）或31（1080p50）。

要注意的是，尽管HDMI将该格式称为L+深度，但是2D视频分量可以取决于包括在元数据中的信息而关联到左或右视图。其之上已经限定在HDMI1.4b中的元数据应当包括在深度像素的颜色分量中以发信号通知用于传输视频+深度和补充信息的特定格式。

HDMI2.0支持比HDMI1.4b更高的像素时钟频率并且包括对于以高达60Hz帧率的2160p格式（3840x2160和4096x2160分辨率）的支持。2D+深度和立体+深度格式可以封装在2160p渐进帧中以跨HDMI2.0接口承载数据。

2160p格式可以与由HDMI定义的RGB或YC_BC_R像素编码模式中的任一个组合。对于较高帧率，YC_BC_R4:2:0像素编码模式是仅有的可用选项。

以下帧封装配置（模式）是HDMI2160p格式可以如何用于传输视频+深度的示例：

A.渐进2D+深度

B.交错2D+深度

C.渐进立体+深度

D.交错立体+深度。

在任何一种模式中，每一个有效行包含其后跟随相等数目的相关联的深度像素的单行视频（纹理）像素，其一起填满有效行。模式在元数据中被指示，其编码在深度像素的颜色分量中，从第一有效行的第一深度像素开始。

在图1和图2中描绘针对四个模式中的每一个的有效HDMI帧内的纹理和深度子图像的封装。

纹理子图像具有两个2160pHDMI视频格式中的一个中的有效行的水平分辨率的一半的水平分辨率，即1920或2048像素。

在渐进模式中，纹理子图像具有1080行的竖直分辨率，即2160pHDMI视频格式的竖直分辨率的一半。

在交错模式中，纹理子图像具有540行的竖直分辨率，即2160pHDMI视频格式的竖直分辨率的四分之一。

在YC_BC_R4:2:2和4:2:0像素编码的情况中的采样位置优选地依照AVC规范（参见ISO/IEC14496-10:2012-Informationtechnology–Codingofaudio-visualobjects–Part10:AdvancedVideoCoding的章节6.2）。深度子图像具有1920或2048像素的水平分辨率，即两个2160pHDMI视频格式中的一个中的有效行的水平分辨率的一半。

在渐进模式中，深度子图像具有1080行的竖直分辨率，即2160pHDMI视频格式的竖直分辨率的一半。

在交错模式中，深度子图像具有540行的竖直分辨率，即2160pHDMI视频格式的竖直分辨率的四分之一。

深度子图像包含从0到255的范围（边界包括在内）中的深度值，其具有由元数据指示的含义。

在YC_BC_R像素编码的情况中，深度值将存储在Y分量中。C分量将被设置成0，除非它们包含元数据。接收设备将仅依赖于用于深度的Y分量值。

在RGB4:4:4像素编码的情况中，深度值将存储在R分量中。G和B分量将被设置成与R分量相同的值，除非它们包含元数据。接收设备将仅依赖于用于深度的R分量值。

可替换地，在RGB4:4:4像素编码的情况中，深度值将存储在G分量中。R和B分量将被设置成零值，除非它们包含元数据。接收设备将仅依赖于用于深度的G分量值。

在使用每个分量多于8位的情况中（如果帧率和HDMITMDS时钟允许的话），深度值存储在Y分量的最高有效位中。

元数据信道包含帧和元数据的格式指示。该信道包括深度像素中包含的字节序列，该字节序列从每一帧中的第一深度行中的第一深度像素开始，继续来自下一行的深度像素直到如传达数据所需要的那么多的行。元数据信道字节当在一个YC_BC_R像素编码模式中时存储在深度子图像的C分量中，并且当在RGB4:4:4像素编码模式中存储在G和B分量中。在每个分量多于8位可用的情况下（如果帧率和HDMITMDS时钟允许的话），元数据信道字节存储在分量的8个最高有效位中。

在下面的表1中示出各种像素编码模式中的元数据字节到分量的映射。

标头字节RGB>YC_BC_R>YC_BC_R>YC_BC_R>1G0C_B0C_B0>C_B002B0C_R0C_R0>C_R003G1C_B1C_B2>C_B024B1C_R1C_R2>C_R025G2C_B2C_B4>C_B046B2C_R2C_R4>C_R04..........

表1，元数据字节到分量的映射。

元数据包括在每一帧中，无论元数据内容中是否存在变化。这样做的优点在于在每一帧的基础上访问元数据成为可能，这允许再现在已经传输了用于该帧的信息时开始。因此可以重复插入元数据，无论元数据中是否存在变化，例如针对每一帧、针对每一个字段、针对每一图片组和/或针对每一个场景。

元数据信道可以组织为分组序列，如表2中所示。

metadata_channel_sequence {# 字节　　　　　　while(next_bits( 8 ) >= 0xF0 ) {　　　　　　　　　metadata_channel_packet( )(64)　　　　　　}}

表2，元数据信道语法。

元数据信道分组语法进而可以如表3中建议的那样。

metadata_channel_packet {# 字节　　　　　　packet_id1　　　　　　packet_subcode1　　　　　　packet_metadata_type1　　　　　　packet_count1　　　　　　packet_payload()(56)　　　　　　packet_edc4}

表3，元数据信道分组语法。

元数据信道包含64字节元数据信道分组的序列。包括在序列中的分组数目取决于要传输的元数据的量。为了改进鲁棒性，传输元数据三次。跟随在最后一个元数据信道分组的元数据信道的所有字节被设置成0。因此在此元数据可以重复地插入，尽管元数据中不存在变化。

每一个64字节分组以4字节标头开始，随后是56字节有效载荷以及4字节错误检测码（EDC）。实际元数据包括在有效载荷字段中。

packet_id标识根据表4的分组的内容。

packet_id描述0xF0包含元数据的分组；不是具有相同packet_metadata_type的序列中的第一分组0xF1包含具有相同packet_metadata_type的序列的元数据的第一分组0xF2保留以供将来使用0xF3包含具有相同packet_metadata_type的序列的元数据的第一分组，包含等同于先前视频帧中的该类型的元数据的数据其它保留以供将来使用

表4，packet_id。

显然，packet_id允许接收视频流的设备以更加高效的方式处置元数据。有效地，packet_id0xF3特别地指示如果该数据在前一帧中被正确接收，则当前元数据可以被忽略。

特别地，由于用在再现中的元数据可以是在一点处精确的帧并且可以针对若干其它帧固定，因此该信息在实现更高效的元数据控制处置中可以特别有利。

packet_subcode指示根据下表的当前帧的帧封装配置，如果packet_id的最低有效位被设置成1的话（即packet_id被设置成0xF1或0F3）。在所有其它情况中，保留packet_subcode以供将来使用并且将其设置成0。

packet_subcode描述注释0x00保留以供将来使用该值将设置在并非具有相同packet_metadata_type的序列的第一分组的分组中0x01帧封装配置为模式A渐进2D + 深度0x02帧封装配置为模式B交错2D + 深度0x03帧封装配置为模式C渐进立体+深度0x04帧封装配置为模式D交错立体+深度其它保留以供将来使用

表4，packet_subcode。

packet_metadata_type标识什么类型的元数据包括在该分组的有效载荷中。元数据类型是指可以源自包括在如由ITU-T或ISO/IEC标准化的编码位流（例如AVC或HEVC位流）中的补充增强信息（SEI）的补充信息的种类，。元数据类型还可以涉及由源设备生成的元数据的类型。

packet_count指示跟随具有相同packet_metadata_type的该分组的分组数目。

注：最后一个分组包含为0的packet_count值。

packet_payload()承载包含在元数据信道中的总分组有效载荷字节流的56字节。

用于一帧的总分组有效载荷字节流包括在分组的不间断流中并且包含例如如表5中呈现的数据序列（在2字节的元数据的情况下）：

表5，packet_payload_byte_stream数据序列。

stuffing_byte被设置成0x00。一个或多个填料（stuffing）字节包括在跟随来自相同类型的最后一个元数据字节之后的字节流中以朝向结尾填满分组有效载荷（如果需要的话）。前述while语句中的关系表达式为真（TRUE），只要分组有效载荷字节流中的字节数目不是56字节的倍数。

reserved_metadata_bytes()表示可以在将来定义的附加元数据。这样的附加数据将包括有metadata_type的增加值和填料字节的可能包括（如果需要以将元数据与元数据信道分组对准的话）。

packet_edc是包含在分组的前60字节之上计算的错误检测码的4字节字段。该EDC使用如IEEE802.3和ITU-TV.42中定义的标准CRC-32多项式。初始值和最终异或（XOR）值二者为0。

元数据的性质

如经由视频数据信号传送的元数据用在深度图处理或用于通过多视图再现设备再现一个或多个视图以用于另外的视点中。这样的元数据是内容相关的。依照实际视频数据提供元数据。因而它可以依照实际视频数据改变，例如每字段、每帧、每图片组和/或每场景。这样的元数据固有地为动态的，而不是像例如仅指示图像或深度数据存在于视频数据的二维矩阵的区段中的标头那样是静态的。可选地，元数据包括下述中至少一个：

-用于编码用于基于图像的再现的优选再现方向的元数据；

-指示图像与深度信息之间的关系的元数据；

-用在深度图或视差图到目标显示的重映射中的元数据。

现在提供这样的元数据的各种示例。

用在基于图像的再现中的元数据可以例如是诸如公开在WO2011039679中的元数据，WO2011039679涉及用于基于图像的再现的信号中的优选再现方向的编码。该文献公开了编码视频数据信号的方法，包括提供如从第一视点看到的场景的第一图像，提供诸如深度图之类的再现信息以用于使得能够生成如从再现视点看到的场景的至少一个再现的图像，以及提供优选方向指示符，其限定再现视点相对于第一视点的优选取向，并且生成包括表示第一图像的编码数据、再现信息和优选方向指示符的视频数据信号。

优选再现方向信息是内容相关的元数据，但是另外还是需要由进行实际视图再现的设备所使用的元数据，该设备在自动立体显示设备的情况中将典型地为显示设备自身以便允许设备制造商创建最佳可能的显示设备。

可替换地，元数据可以指示图像与深度信息之间的关系，诸如在PCT申请WO2010070545（A1）中所公开的那样。再次，编码在流中的信息取决于实际内容并且可以被自动立体显示设备用于进一步改进再现；例如在立体+深度内容的情况中，可能有益的是，知晓深度信息是否从立体内容导出和/或深度信息是否源自人类辅助编写。在后一种情况中，可能更有利的是，使用例如交叉双边尺度扩展过滤器通过图像辅助尺度扩展增加低分辨率深度图的分辨率，而不是基于立体内容的视差估计而组合低分辨率深度图与较高分辨率版本。

更加可替换地，所提供的元数据可以是用在深度图或视差图到目标显示的重映射中的元数据，如例如在PCT申请WO2010041176中所公开的那样。该PCT申请涉及使用视差变换用于重瞄准用于不同目标显示器的内容。

这样的深度/视差重映射是不仅内容相关而且该数据的处理还是显示设备相关的过程。作为结果，该视差变换数据是优选地以压缩格式连同内容自身一起提供的数据。例如，视差变换可以嵌入在如从存储设备或数据载体读取或从有线/无线网络接收的压缩内容中。并且随后添加为元数据并且传送至负责视图再现的设备。

参照图3，图3示出3D再现链中的根据本发明的编码器和根据本发明的解码器的框图。

在图中的左上部，我们可以看到编码器310。编码器310是与多视图再现设备一起使用的视频数据信号50的编码器。编码器310包括布置成获取与第一视点相关联的场景的第一图像10的第一获取单元301、布置成获取与第一图像10相关联的深度图20的第二获取单元302以及布置成获取用在深度图处理或通过多视图再现设备再现一个或多个视图以用于另外的视点中的元数据30的第三获取单元303。编码器310进一步包括布置成生成视频数据信号50的生成器304，视频数据信号50包括：基于第一图像10的一个或两个子图像，基于深度图（20）的一个或两个另外的子图像，以及编码在一个或两个另外的子图像中的元数据（30）。

遍及本申请，通过编码器的数据获取被视为包括从外部源接收数据，通过编码器设备获取数据或者通过编码器设备生成数据。

优选地，来自深度图20的信息被编码在一个或两个另外的子图像的亮度值中并且来自元数据30的信息被编码在一个或两个另外的子图像的色度值中。

更优选地，包括在视频数据信号中的信息包括具有放置在其中的相应子图像的数据的基本上未经压缩的二维阵列。

一旦视频数据信号50被编码，它可以被处置器70处置，处置器70可以可替换地将视频数据信号50存储在存储介质71上，存储介质71可以是硬盘、光盘或非易失性存储器存储装置，诸如固态存储器。然而在实践中更可能的是，数据由处置器70通过有线72或无线网络73或二者的组合（未示出）进行传输。

视频数据信号将随后到达解码器350以用于解码视频数据信号50，解码器包括布置成接收视频数据信号50的接收器351。在该阶段，视频数据信号包括与第一视点相关联的场景的第一图像10、与第一图像10相关联的深度图20和用在深度图处理或再现多个视图中的元数据30。视频数据信号随后传递到解复用器352，解复用器被布置成对视频数据信号50解复用以便获得对各个组件的访问。

解码器350还至少包括布置成依赖于元数据30处理深度图20的深度图处理器353或再现单元354中的一个或二者，该再现单元被布置成再现一个或多个视图。它们中的至少一个将存在以便使本发明能够提供处置元数据方面的优点。

更可选地，解码器350还包括多视图立体显示单元356。该显示单元可以是基于屏障物或基于透镜的多视图显示设备，或者需要针对其再现附加视图的多视图显示设备的另一形式。

在已经使用解复用器352对数据解复用之后，元数据被传递到控制处理器355以用于元数据的进一步处置。

转向图5，图4示出根据本发明的编码方法的流程图。流程图描绘了对与多视图再现设备一起使用的视频数据信号50进行编码的过程，该方法包括提供与第一视点相关联的场景的第一图像10的步骤401，提供与第一图像10相关联的深度图20的步骤402，以及提供403用在深度图处理或通过多视图再现设备再现一个或多个视图以用于另外的视点中的元数据30的步骤403。该方法进一步包括生成404视频数据信号50的步骤404，视频数据信号50包括基于第一图像10的一个或两个子图像、基于深度图20的一个或两个另外的子图像以及编码在一个或两个另外的子图像中的元数据30。

如本文以上所指示的，优选地，来自深度图20的信息被编码在一个或两个另外的子图像的亮度值中并且来自元数据30的信息被编码在一个或两个另外的子图像的色度值中。

更优选地，包括在视频数据信号中的信息包括具有放置在其中的相应子图像的数据的基本上未经压缩的二维阵列。

转向图5，图5示出根据本发明的解码方法的流程图。该流程图示意性地示出解码视频数据信号50的过程，该方法包括用于接收视频数据信号50的步骤501。视频数据信号包括与第一视点相关联的场景的第一图像10、与第一图像10相关联的深度图20以及用在深度图处理或再现多个视图中的元数据30，如本文以上参照图3所描述的那样。

该方法进一步包括对视频数据信号50解复用502的步骤502以便获得对各个组件的访问。在解复用之后，检查元数据以便确定处理应当进行多远。在存在对于依赖于元数据30的深度图处理的需要的情况下，该过程以步骤503继续；即依赖于元数据30的深度图20的深度图处理503。

可替换地，当不需要深度图处理时；过程在步骤504处继续依赖于元数据（30）再现（504）一个或多个视图以用于另外的视点。最后可选地，新再现的视图被用在通过使用多视图立体显示设备实际显示再现的视图的步骤505中。

值得注意地，图5B和5C提供根据本发明的解码方法的另外的实施例，其中图5B示出其中不存在提供用于深度处理的元数据的实施例；即其中元数据仅用于控制再现过程的情境。由于不存在基于元数据的深度处理，因此从流程图去除该步骤。

同样地，图5C示出其中没有提供用于再现过程的元数据但是其中总是存在提供用于深度处理步骤的元数据的实施例。在该情境中，涉及依赖于元数据30的视图再现的步骤504被步骤504’取代，该步骤504’为不使用元数据30的视图再现步骤。

将领会到的是，本发明还扩展到计算机程序，特别是载体上或载体中的计算机程序，其适用于将本发明付诸实践。程序可以是源代码、对象代码、代码中间源和对象代码的形式，诸如部分编译形式，或者适合用在根据本发明的方法的实现方式中的任何其它形式。还将领会到，这样的程序可以具有许多不同的架构设计。例如，实现根据本发明的方法或系统的功能性的程序代码可以被细分成一个或多个子例程。

在这些子例程之中分配功能性的许多不同方式对技术人员而言将是显而易见的。子例程可以一起存储在一个可执行文件中以形成自包含程序。这样的可执行文件可以包括计算机可执行指令，例如处理器指令和/或解释器指令（例如Java解释器指令）。可替换地，子例程中的一个或多个或全部可以存储在至少一个外部库文件中并且静态地或者动态地（例如在运行时间）与主程序链接。主程序包含对至少一个子例程的至少一个调用。而且，子例程可以包括对彼此的功能调用。涉及计算机程序产品的实施例包括对应于所阐述的方法中的至少一个的每一个处理步骤的计算机可执行指令。这些指令可以细分成子例程和/或存储在可以静态或动态链接的一个或多个文件中。

涉及计算机程序产品的另一实施例包括对应于所阐述的系统和/或产品中的至少一个的每一个构件的计算机可执行指令。这些指令可以细分成子例程和/或存储在可以静态或动态链接的一个或多个文件中。

计算机程序的载体可以是能够承载程序的任何实体或设备。例如，载体可以包括存储介质，诸如ROM，例如CDROM或半导体ROM，或者磁记录介质，例如软盘或硬盘。进一步地，载体可以是可传输载体，诸如电信号或光学信号，其可以经由电气或光学线缆或者通过无线电或其它手段传导。当程序体现在这样的信号中时，载体可以由这样的线缆或其它设备或构件构成。可替换地，载体可以是其中嵌入程序的集成电路，集成电路适用于执行相关方法或者用在相关方法的执行中。

应当注意，以上提到的实施例说明而非限制本发明，并且本领域技术人员将能够设计许多可替换实施例而不脱离于随附权利要求的范围。在权利要求中，置于括号之间的任何参考标记不应当解释为限制权利要求。动词“包括”及其词形变化的使用不排除除在权利要求中陈述的那些之外的元件或步骤的存在。在元件之前的冠词“一”不排除多个这样的元件的存在。本发明可以借助于包括若干分立元件的硬件和借助于适当编程的计算机来实现。在枚举若干构件的设备权利要求中，这些构件中的若干个可以通过同一项硬件体现。在相互不同的从属权利要求中记载某些措施的仅有事实并不指示这些措施的组合不能用于获益。