3D视频格式

阅读:645发布:2020-06-05

专利汇可以提供3D视频格式专利检索,专利查询,专利分析的服务。并且本 申请 涉及3D视频格式。多种实施方式涉及3D视频格式。一种或多种实施方式涉及为MVC和SVC提供适应性 修改 ,以使3D视频格式被使用。根据一般方面,包括视频和深度的一组图像被编码。该组图像被根据特定的3D视频格式相关联,并且被以利用该组图像之间的冗余的方式编码。编码后的图像被基于与这些图像有关的特定的3D视频格式以特定顺序排列在比特流中。比特流中的该特定顺序被利用信令信息来指示。根据另一方面,包括该组编码后的图像的比特流被 访问 。信令信息也被访问。该组图像被利用信令信息来解码。,下面是3D视频格式专利的具体信息内容。

1.一种用于生成比特流的方法,包括:
对包括二维2D视频图像和与所述2D视频图像相对应的深度图像的一组图像进行编码,其中所述一组图像根据特定的3D视频格式而相关,并且所述一组图像使用视频编码标准的多层视频编码扩展以利用所述一组图像中的图像之间的冗余的方式被编码,其中所述2D视频图像根据所述多层视频编码扩展被作为第一层进行编码,并且所述深度图像根据所述多层视频编码扩展被作为第二层进行编码;
基于与所述一组图像有关的所述特定的3D视频格式,以特定顺序将编码后的图像排列在比特流中,以及
使用信令信息来指示所述特定顺序,
其中所述特定的3D视频格式是多种不同的3D视频格式中的一种,其中所述编码后的图像可以根据所述3D视频格式进行排列,并且所述信令信息指示所述多种不同的3D视频格式中的所述特定的3D视频格式。
2.根据权利要求1所述的方法,其中所述信令信息被包括在SEI消息或者其他高级语法中。
3.根据权利要求1所述的方法,其中所述多种不同的3D视频格式包括2D加深度2D+Z、分层深度视频LDV、多视加深度MVD和视差增强立体图像DES。
4.根据权利要求1所述的方法,其中所述二维视频图像和所述相应的深度图像来自第一视点,并且所述一组图像还包括来自第二视点的另一二维视频图像和另一深度图像,所述另一深度图像与所述另一二维视频图像相对应。
5.根据权利要求1所述的方法,其中所述一组图像还包括遮挡视频图像和遮挡深度图像。
6.根据权利要求5所述的方法,其中所述遮挡视频图像和所述遮挡深度图像来自第一视点,并且所述一组图像还包括来自第二视点的另一遮挡视频图像和另一遮挡深度图像,所述另一遮挡深度图像与所述另一遮挡视频图像相对应。
7.一种用于生成比特流的装置,包括:
被配置成对包括二维2D视频图像和与所述2D视频图像相对应的深度图像的一组图像进行编码的编码器,其中所述一组图像根据特定的3D视频格式而相关,并且所述一组图像使用视频编码标准的多层视频编码扩展以利用所述一组图像中的图像之间的冗余的方式被编码,其中所述2D视频图像根据所述多层视频编码扩展被作为第一层进行编码,并且所述深度图像根据所述多层视频编码扩展被作为第二层进行编码;
被配置成基于与所述一组图像有关的所述特定的3D视频格式,以特定顺序将所述编码后的图像排列在比特流中的比特流复用器,以及
被配置成使用信令信息指示所述特定顺序的消息组成器,
其中所述特定的3D视频格式是多种不同的3D视频格式中的一种,其中所述编码后的图像可以根据所述3D视频格式进行排列,并且所述信令信息指示所述多种不同的3D视频格式中的所述特定的3D视频格式。
8.根据权利要求7所述的装置,其中所述信令信息被包括在SEI消息或者其他高级语法中。
9.根据权利要求7所述的装置,其中所述多种不同的3D视频格式包括2D加深度2D+Z、分层深度视频LDV、多视角加深度MVD和视差增强立体图像DES。
10.根据权利要求7所述的装置,其中所述二维视频图像和所述相应的深度图像来自第一视点,并且所述一组图像还包括来自第二视点的另一二维视频图像和另一深度图像,所述另一深度图像与所述另一二维视频图像相对应。
11.根据权利要求7所述的装置,其中所述一组图像还包括遮挡视频图像和遮挡深度图像。
12.根据权利要求11所述的装置,其中所述遮挡视频图像和所述遮挡深度图像来自第一视点,并且所述一组图像还包括来自第二视点的另一遮挡视频图像和另一遮挡深度图像,所述另一遮挡深度图像与所述另一遮挡视频图像相对应。
13.一种用于视频解码的方法,包括:
访问包括编码后的一组图像的比特流,其中所述一组图像包括二维2D视频图像和与所述2D视频图像相对应的深度图像,所述一组图像根据特定的3D视频格式而相关,所述一组图像使用视频编码标准的多层视频编码扩展以利用所述一组图像中的图像之间的冗余的方式被编码,其中所述2D视频图像根据所述多层视频编码扩展被作为第一层进行编码,并且所述深度图像根据所述多层视频编码扩展被作为第二层进行编码;
访问指示特定顺序的信令信息,其中所述编码后的一组图像以所述特定顺序排列在所述比特流中,所述特定顺序基于与所述一组图像有关的所述特定的3D视频格式,以及其中所述特定的3D视频格式是多种不同的3D视频格式中的一种,其中所述编码后的图像可以根据所述3D视频格式进行排列,并且所述信令信息指示所述多种不同的3D视频格式中的所述特定的3D视频格式。
14.根据权利要求13所述的方法,其中所述信令信息被包括在SEI消息或者其他高级语法中。
15.根据权利要求13所述的方法,其中所述多种不同的3D视频格式包括2D加深度2D+Z、分层深度视频LDV、多视角加深度MVD和视差增强立体图像DES。
16.一种用于视频解码的装置,包括:
被配置成访问包括编码后的一组图像的比特流的比特流解复用器,其中所述一组图像包括二维2D视频图像和与所述2D视频图像相对应的深度图像,所述一组图像根据特定的3D视频格式而相关,并且所述一组图像使用视频编码标准的多层视频编码扩展以利用所述一组图像中的图像之间的冗余的方式被编码,其中所述2D视频图像根据所述多层视频编码扩展被作为第一层进行编码,并且所述深度图像根据所述多层视频编码扩展被作为第二层进行编码;
被配置成访问指示特定顺序的信令信息的消息解析器,其中所述编码后的一组图像以所述特定顺序排列在所述比特流中,所述特定顺序基于与所述一组图像有关的所述特定的
3D视频格式,以及
其中所述特定的3D视频格式是多种不同的3D视频格式中的一种,其中所述编码后的图像可以根据所述3D视频格式进行排列,并且所述信令信息指示所述多种不同的3D视频格式中的所述特定的3D视频格式。
17.根据权利要求16所述的装置,其中所述信令信息被包括在SEI消息或者其他高级语法中。
18.根据权利要求16所述的装置,其中所述多种不同的3D视频格式包括2D加深度2D+Z、分层深度视频LDV、多视角加深度MVD和视差增强立体图像DES。

说明书全文

3D视频格式

[0001] 本申请是申请日为2010年2月19日,申请号为201080008695.8,名称为“3D视频格式”的发明专利申请的分案申请。

技术领域

[0002] 描述了涉及编码系统的实施方式。各种特定的实施方式涉及三维(3D)视频格式。

背景技术

[0003] 为了方便诸如三维电视(3DTV)和自由视点视频(FVV)之类的新的视频应用,可以使用包括传统的二维(2D)视频和深度二者的3D视频(3DV)数据格式,以使额外的视频能够被呈现在用户端。这种3DV格式的示例包括2D加深度(2D+Z)(其包括2D视频和相应的深度贴图)和分层深度视频LDV(其包括2D+Z中的数据和一个遮挡视频(occlusion video)及一个遮挡深度(occlusion depth))。多视加深度(MVD)是2D+Z的扩展,包括来自不同视点的多个2D+Z。视差增强立体图像(DES)是相当于来自不同视角的两个LDV的另一种格式。如何传送(编码并发送)这些数据格式是一个重要问题,因为必须在用户端联合使用不同分量。

发明内容

[0004] 根据一个概括方面,一组图像被编码。该组图像包括视频图像和与该视频图像相对应的深度图像。该组图像中的图像被根据特定的3D视频格式相关联。该组图像被以利用该组图像中的图像之间的冗余的方式编码。编码后的图像被基于与这些图像有关的特定的3D视频格式,以特定次序排列在比特流中。该特定次序在比特流中被使用信令信息指示出来。
[0005] 根据另一概括方面,包括一组编码后的图像的比特流被访问,该组图像包括视频图像和与该视频图像相对应的深度图像。该组图像被根据特定的3D视频格式相关联。该组图像被以利用该组图像中的图像之间的冗余的方式编码。指示特定次序的信令信息被访问,其中该组编码后的图像被以该特定次序排列在比特流中。该特定次序是以与该组图像有关的特定的3D视频格式为基础的。该组图像被使用信令信息解码。
[0006] 根据又一概括方面,视频信号被格式化为包括信息。该视频信号包括信令部分,该信令部分包括信令信息。该信令信息指示特定次序,其中该组编码后的图像被以该特定次序排列在比特流中。该特定次序是以与该组图像有关的特定的3D视频格式为基础的。
[0007] 下面的描述和附图中阐述了一种或多种实施方式的细节。即使仅以一种特定方式进行描述,也应该明白实施方式可以被以各种方式配置或实现。例如,一种实施方式可以被作为一种方法执行,或者被实现为一种装置(诸如,被配置为执行一组操作的装置、或者存储用于执行一组操作的指令的装置)、或者被实现为一种信号。结合附图和权利要求,其他方面和特征将通过下面的详细描述变得显而易见。

附图说明

[0008] 图1是深度贴图(depth map)的示例。
[0009] 图2是示出LDV格式的四个分量的示例。
[0010] 图3是3DV编码器的实施方式的示意图。
[0011] 图4是3DV解码器的实施方式的示意图。
[0012] 图5是视频传输系统的实施方式的示意图。
[0013] 图6是视频接收系统的实施方式的示意图。
[0014] 图7是视频处理设备的实施方式的示意图。
[0015] 图8是示出对MVC结构中的MVD格式进行编码的示例的示意图。
[0016] 图9是示出对MVC结构中的LDV格式进行编码的示例的示意图。
[0017] 图10是示出对MVC结构中的DES格式进行编码的示例的示意图。
[0018] 图11是第一编码处理的实施方式的示意图。
[0019] 图12是第一解码处理的实施方式的示意图。
[0020] 图13是示出对MVC结构中的MVD格式进行编码的另一示例的示意图。
[0021] 图14是示出对MVC结构中的LDV格式进行编码的另一示例的示意图。
[0022] 图15是示出对MVC结构中的DES格式进行编码的另一示例的示意图。
[0023] 图16是第二编码处理的实施方式的示意图。
[0024] 图17是第二解码处理的实施方式的示意图。
[0025] 图18是示出对SVC结构中的LDV格式进行编码的示例的示意图。
[0026] 图19是第三编码处理的实施方式的示意图。
[0027] 图20是第三解码处理的实施方式的示意图。
[0028] 图21是第四编码处理的实施方式的示意图。
[0029] 图22是第四解码处理的实施方式的示意图。

具体实施方式

[0030] 可以利用诸如既包括传统的2D视频又包括深度的数据格式之类的3DV数据格式,来使例如附加的视频视图可以被呈现在用户端。但是,发明人认为缺陷在于,在诸如可分层视频编码(SVC)和多视角视频编码(MVC)之类的当前标准中并不支持3DV格式。多视角视频序列是包括从不同视点捕捉相同场景的两个以上视频序列的一组视频序列。
[0031] 所以,在至少一种实施方式中,我们提出重新使用现有的对于高级视频编码(AVC)的MVC或SVC扩展,在用信号指示如何正确提取3DV内容的帮助下发送3DV内容。可以利用包括但不限于例如,序列参数集(SPS)、画面参数集(PPS)、条带头、辅助增强信息(SEI)消息等的任意高级语法来进行信号指示。在本申请中,其他信令机制也是可能的,并且是可以想到的。
[0032] 在至少一种实施方式中,我们提出使用SVC或MVC的构架来对3DV分量进行编码,而不要求系统级的同步。使用SVC或MVC中的技术,本原理可以更有效地利用分量间(cross-component)冗余。另外,后向兼容性更加灵活,因为可以仅利用整个比特流的一部分来对传统的2D视频进行发送/解码(例如,用于SVC的基本层、或者MVC中的基本视图)。
[0033] 在至少一种实施方式中,我们还提出使用高级语法来用信号指示如何理解3DV背景中的视图(MVC中)或者层(SVC中),从而使得3D显示器可以正确使用信息。
[0034] 在至少一种实施方式中,我们提出了用于用信号指示不同3DV格式的MVC和SVC的构架中的“3DV格式SEI消息”。这种实施方式可能会具有以下优点中的一个以上优点、或者全部优点:
[0035] ·避免了对系统级的不同分量进行同步的需要,因为它们可以被以分层方式(SVC)或者同步视角(MVC)方式相关联。
[0036] ·更好地利用了分量间冗余:通过相对于利用交织法的AVC而言可以潜在地提供更高编码效率的SVC/MVC将使能分量间预测。
[0037] ·更灵活的后向兼容性:在用户端,传统的2D视频应用只需要部分数据。
[0038] 应该明白,尽管至少一种实施方式涉及到SEI消息,但是以上所述的原理不限于使用SEI消息。所以,例如,可以使用包括但不限于SPS、PPS、条带头等的其他高级语法。
[0039] 3D视频(3DV)再现格式包括视频分量和深度分量二者,这些格式诸如是2D+Z(MVD)和LDV(DES)等,并且随着3DV应用吸引了更多的市场关注而变得更加重要。图1示出了根据本原理的实施例的可以应用本原理的与被称为“Leaving_Laptop”的MPEG测试序列相对应的示例性深度贴图100。图2示出了根据本原理的实施例的可以应用本原理的LDV格式中的四种分量。具体地,左上部分201示出了2D视频视图,右上部分202示出了深度,左下部分203示出了遮挡视频层,右下部分204示出了遮挡深度层。以上数据格式的编码和传输对于各种应用来说非常关键,并且是具有挑战性的。包括编码效率在内的诸如同步和后向兼容(对于传统的单视场2D视频)之类的功能应该被考虑,以使老式解码器可以根据比特流示出一些东西。
[0040] 相对简单的解决方案是多播,其中每个分量被独立编码并发送。这种方式的典型实施方式需要多个编码器/解码器、以及系统级或应用级的同步。换言之,多播的代价可以被简单地增加3DV分量的数目倍。另外,由于不同分量被独立编码,所以将无法利用分量之间的任何冗余。
[0041] MPEG-C Part 3(ISO/IEC 23002-3)规定了一种用于2D+Z的系统架构。MPEG-C Part 3还要求视频和深度之间的系统级同步。可以利用任何现有的视频编码标准对视频和深度进行编码,但是视频和深度的编码被拆开进行,从而无法在这两种分量之间获得任何编码好处。MPEG-C Part 3中没有规定LDV(DES)。用于2D+Z(MVD)和LDV(DES)的编码方案还处于例如,MPEG的3DV组的探索阶段。
[0042] 为了将2D+Z(MVD)和LDV(DES)格式结合到诸如SVC和MVC之类的现有的编码机制中,在至少一种实施方式中,我们提出利用一些高级语法来用信号指示如何从SVC或MVC比特流提取3DV分量。这种方法的好处在于,不需要系统级的不同3DV分量之间的同步,因为它们将被结合在编码后的比特流中(诸如,SVC中的基本/增强层或者MVC中的不同视角)。另一个潜在的好处在于,当以这种方式执行编码时可以去除分量间冗余。
[0043] 术语
[0044] “3DV视图”在这里被定义为来自一个视图位置的数据组,其不同于MVC中使用的“视角”。对于2D+Z格式,3DV视图包括两个分量序列,即,2D视图及其深度贴图。对于LDV格式,3DV视图包括四个分量序列,即,2D视图、深度贴图、遮挡视图、以及遮挡深度贴图。
[0045] 当MVC(SVC)解码器接收到包括所提出的SEI消息的比特流时,MVC(SVC)解码器可以通过3D显示器可以输出适当图像的方式来组成3DV数据。
[0046] 图3是根据本原理的实施例的可以应用本原理的3DV编码器300的实施方式的示意图。编码器300包括3D视图分量组成器355,该组成器具有与MVC/SVC编码器305的输入端进行信号通信的第一输出端。MVC/SVC编码器305的输出端以信号通信的方式与比特流复用器360的第一输入端连接。3D视图分量组成器355的第二输出端以信号通信的方式连接SEI消息组成器365的第一输入端。SEI消息组成器365的输出端以信号通信的方式连接比特流复用器360的第二输入端。3D视图分量组成器355的输入端可被用作编码器300的输入端,用于接收3DV内容(例如,一个或多个2D视图、深度、一个或多个遮挡视图、遮挡深度、一个或多个透明贴图等)。比特流复用器360的输出端可被用作编码器300的输出端,用于输出3DV比特流。
[0047] 在这种实施方式中,MVC/SVC编码器305中的每个3DV分量编码器(未示出)是MVC编码器或SVC编码器。在使用MVC编码器的情况中,每个3DV分量编码器是用于一个SVC视图的SVC编码器。3D视图分量组成器355是用于发送SVC层或MVC视图的3DV分量以及发送这样的控制信息给SEI消息组成器365的分配器。SEI消息组成器365将SEI消息组成为比特流中的信号。比特流复用器360将复用该比特流。
[0048] 图4是根据本原理的实施例的可以应用本原理的3DV解码器400的实施方式的示意图。解码器400包括比特流解复用器460,该解复用器具有以信号通信的方式与SEI消息解析器465的输入端和MVC/SVC解码器405的输入端连接的输出端。SEI消息解析器465的输出端以信号通信的方式与3D视图分量分解器455的第一输入端连接。MVC/SVC解码器405的输出端以信号通信的方式与3D视图分量分解器455的第二输入端连接。比特流解复用器460的输入端可以被用作解码器400的输入端,用于接收3DV比特流。3D视图分量分解器455的输出端可以被用作解码器400的输出端,用于输出格式化后的3DV内容(例如,一个或多个2D视图、深度、一个或多个遮挡视图、遮挡深度、一个或多个透明贴图等)。
[0049] 图3和图4示出了特定实施方式,但是可以预见其他实施方式。例如,另一种实施方式不具有图3(或图4)的一个或多个上的独立输入端。相反,单个输入端被用来接收多个信号。作为具体示例,比特流复用器360可以只具有一个输入端。单个输入端接收来自MVC/SVC编码器305的输出以及来自SEI消息组成器365的输出。另外,3D视图分量组成器355的另一种实施方式只具有单个输出端,该输出端既向SEI消息组成器365提供信号又向MVC/SVC编码器305提供信号。可以想到对于图4以及其他附图的实施方式以及贯穿说明书描述的实施方式的类似适应修改
[0050] 图5示出了根据本原理的实施例的可以应用本原理的示例性视频传输系统700。视频传输系统700可以是例如用于使用诸如(例如)卫星、线缆、电话线、或者陆地广播之类的各种媒介中的任意一种来发送信号的头端、或传输系统。可以通过互联网或者一些其他网络来提供传输。
[0051] 视频传输系统700能够生成并递送例如视频内容和深度。这是通过生成一个或多个编码后的信号来实现的,其中编码后的信号包括深度信息或者能够被用来在可能具有例如解码器的接收器端合成深度信息的信息。
[0052] 视频传输系统700包括编码器710和能够发送编码后的信号的发送器720。编码器710接收视频信息,并基于深度信息和/或视频信息生成一个或多个编码后的信号。编码器
710可以是例如以上详细描述的编码器300。编码器710可以包括子模块,这些子模块包括例如用于接收各种信息项并将这些信息项装配为结构化的格式以供存储或传输的装配单元。
各种信息项可以包括例如,编码后或未编码的视频、编码后或未编码的深度信息、以及诸如运动矢量、编码模式指示符、以及语法元素之类的编码后或未编码的元素。
[0053] 发送器720可以被用来例如发送具有代表编码后的画面和/或与其有关的信息的一个或多个比特流的节目信号。一般发送器执行诸如提供误差校正编码、对信号中的数据进行交织、使得信号中的能量随机化、以及将信号调制到一个或多个载波上之类的处理中的一个或多个处理的功能。发送器可以包括天线(未示出),或者可以与天线接口。因此,发送器720的各种实施方式可以包括或者被限制为调制器
[0054] 图6示出了根据本原理的实施例的可以应用本原理的示例性视频接收系统800。视频接收系统800可以被配置为通过诸如(例如)卫星、线缆、电话线、或者陆地广播之类的各种媒介接收信号。这些信号可以通过互联网或者一些其他网络被接收。
[0055] 视频接收系统800可以是例如蜂窝电话、计算机、机顶盒、电视机、或者接收编码后的视频并提供例如解码后的视频以供显示给用户或者以供存储的其他设备。所以,视频接收系统800可以将其输出提供给例如电视机的屏幕、计算机监控器、计算机(用于存储、处理、或显示)、或者一些其他存储、处理、或显示设备。
[0056] 视频接收系统800能够接收并处理包括视频信息的视频内容。视频接收系统800包括能够接收诸如在本申请的实施方式中描述的信号之类的编码后的信号的接收器810、以及能够对所接收的信号进行解码的解码器820。
[0057] 接收器810可以被用于例如接收具有代表编码后的画面的多个比特流的节目信号。一般接收器执行诸如接收调制并编码后的数据信号、从一个或多个载波解调数据信号、使信号中的能量去随机化、对信号中的数据进行解交织、以及对信号进行误差校正解码中的一个或多个处理的功能。接收器810可以包括天线(未示出),或者可以与天线相接口。接收器810的实施方式可以包括或者被限制为解调器。
[0058] 解码器820输出包括视频信息和深度信息的视频信号。解码器820可以是例如以上描述的解码器400。
[0059] 图7示出了根据本原理的实施例的可以利用本原理的示例性视频处理设备900。视频处理设备900可以是例如机顶盒、或者接收编码后的视频并且提供例如解码后的视频以供向用户显示或者以供存储的其他设备。所以,视频处理设备900可以将其输出提供给电视机、计算机监控器、或者计算机或其他处理设备。
[0060] 视频处理设备900包括前端(FE)设备905和解码器910。前端设备905可以是例如被用来接收具有代表编码后的画面的多个比特流的节目信号、以及从多个比特流中选择一个或多个比特流以供解码的接收器。一般接收器执行诸如接收调制并编码后的数据信号、对数据信号进行解调、对数据信号的一个或多个编码(例如,信道编码和/或源编码)进行解码、和/或对数据信号进行误差校正中的一个或多个处理的功能。前端设备905可以从例如天线(未示出)接收节目信号。前端设备905向解码器910提供所接收的数据信号。
[0061] 解码器910接收数据信号920。数据信号920可以包括例如,一个或多个高级视频编码(AVC)、可缩放视频编码(SVC)、或者多视角视频编码(MVC)兼容的流。
[0062] AVC更具体地指现有的国际标准化组织/国际电工委员会(ISO/IEC)移动画面专家组4(MPEG-4),部分10,高级视频编码(AVC)标准/国际电信联盟,电信部(ITU-T)H.264推荐(International Organization for  Standardization/International Electrotechnical Commission(ISO/IEC)Moving Picture Experts Group-4(MPEG-4)Part 10Advanced Video Coding(AVC)standard/International Telecommunication Union,Telecommunication Sector(ITU-T)H.264Recommendation)(下文中,称为“H.264/MPEG-4AVC Standard”或者其变型,诸如“AVC标准”或者简称为“AVC”)。
[0063] MVC更具体地指AVC标准的多视角视频编码(MVC)扩展(附件H),被称为H.264/MPEG-4AVC,MVC扩展(“MVC扩展”或者简称为“MVC”)。
[0064] SVC更具体地指AVC标准的可缩放视频编码(SVC)扩展(附件G),被称为H.264/MPEG-4AVC,SVC扩展(“SVC扩展”或者简称为“SVC”)。
[0065] 解码器910对所接收的信号920的部分或全部进行解码,并提供解码后的视频信号930作为输出。解码后的视频930被提供给选择器950。设备900还包括接收用户输入970的用户接口960。用户接口960基于用户输入970将画面选择信号980提供给选择器950。画面选择信号980和用户输入970指示用户期望显示多个画面、序列、可缩放版本、视图、或者可用的编码后数据的其他选择中的哪一种。选择器950提供所选择的一个或多个画面作为输出
990。选择器950使用画面选择信息980来选择解码后的视频930中的哪些画面作为输出990来提供。
[0066] 在各种实施方式中,选择器950包括用户接口960,并且在其他实施方式中,由于选择器950直接接收用户输入970而不需要单独的接口功能被执行,所以不需要用户接口960。选择器950可以用软件实现,或者可以被实现为例如集成电路。在一种实施方式中,选择器
950被与解码器910结合在一起,并且在另一种实施方式中,解码器910、选择器950、以及用户接口960被全部集成在一起。
[0067] 在一个应用中,前端905接收各种电视节目的广播,并且选择一种进行处理。对一个节目的选择是以收看的期望频道的用户输入为基础的。尽管图7中没有示出对于前端设备905的用户输入,但是前端设备905接收到了用户输入970。前端905接收广播,通过解调广播频谱的相关部分并解码解调后的节目的任意外部编码(outer encoding)来处理期望的节目。前端905将解码后的节目提供给解码器910。解码器910是包括设备960和950的集成单元。所以,解码器910接收用户输入,其中该用户输入是由用户提供的期望收看的节目中的视图的指示。解码器910对所选择的视图以及来自其他视图的任意需要的参考画面进行解码,并且将解码后的视图990提供在电视机(未示出)上进行显示。
[0068] 继续以上应用,用户可能期望切换所显示的视图,然后可以将新的输入提供给解码器910。在接收到来自用户的“视图改变”后,解码器910对旧视图和新视图、以及介于旧视图和新视图之间的任意视图进行解码。即,解码器910对由物理上位于拍摄旧视图的相机和拍摄新视图的相机之间的相机所拍摄的任意视图进行解码。前端设备905还接收标识旧视图、新视图、以及它们之间的视图的信息。这种信息可以由例如,解码器910或者具有关于视图位置的信息的控制器(图7中未示出)提供。其他实施方式可以使用具有与前端设备集成在一起的控制器的前端设备。
[0069] 解码器910提供所有这些解码后的视图作为输出990。后处理器(图7中未示出)在这些视图之间进行内插以提供从旧视图到新视图的平滑过渡,并且将这种过渡显示给用户。在过渡到新视图之后,后处理器(通过一个或多个未示出的通信链路)向解码器910和前端设备905通知只需要新视图。然后,解码器910仅提供新视图作为输出990。
[0070] 系统900还可以被用来接收一系列图像的多个视图,呈现用于显示的单个视图,以及以平滑方式在各种视图之间切换。平滑方式可以包括在视图之间进行内插以移动到另一视图。另外,系统900还允许用户旋转对象或场景,或者观看对象或场景的三维再现。对象的旋转例如可以对应于从视图到视图的移动、在视图之间进行内插以获得视图之间的平滑过渡或者简单地获取三维再现。也就是说,用户可以“选择”内插后的视图作为将要显示的“视图”。
[0071] 应该明白,视频传输系统700、视频接收系统800、以及视频处理设备900全部可以被用来与本申请中描述的各种实施方式一起使用。例如,系统700、800和900可以被用于利用如上所述的3DV格式中的一种格式的数据进行操作,以及利用相关联的信令信息进行操作。
[0072] 实施例1:用于MVC的3DV格式SEI消息
[0073] 在MVC的架构中,3DV分量序列被作为不同的“视图”进行编码。所以,可以通过作为MVC的一个特征的视图间预测(inter-view prediction)来去除分量间冗余。例如,2D视图和遮挡视图之间的冗余可以被有效去除。表1示出了根据实施例1的提议用于MVC的3DV格式SEI消息的语法。注意,在本实施例中MVC比特流可以包括除3DV分量序列以外的更多视图。
[0074] 表1
[0075]
[0076] 表1的语法元素的语义如下。
[0077] three_dv_format_id包括可以被用来标识3DV格式SEI消息的使用的标识号。该值应该被包含在0到232-2的范围中。应该注意,从0到255以及从512到231-2的值可以在被本应用确定之后被使用。从265到511以及从231到232-2的值被保存以供将来使用。解码器应该忽略(从比特流中去除并且丢弃)包括处于从265到511的范围中或者从231到232-2的范围中的three_dv_format_id的值的所有3DV格式SEI消息,并且比特流不应该包括这些值。
[0078] three_dv_format_flag等于1指示3DV格式SEI消息按照输出顺序消除了任意一个先前的3DV格式SEI消息的存留。three_dv_format_cancel_flag等于0指示3DV格式信息跟在后面。
[0079] num_three_dv_view_minus1加1指示具有3DV数据的视图的数目。每个视图在3DV格式的背景中具有唯一ID号,即包括在从0到num_three_dv_view_minus的范围中并在该范围中变化的3dv_view_id。应该注意,3dv_view_id不同于MVC背景中的view_id。对于来自一个视图(例如,2D视图)的3DV数据,其深度贴图等被当作MVC中的不同视图并具有不同view_id,但是因为它们与相同视图位置的不同分量序列相对应所以共享同一个3dv_view_id。
[0080] basic_three_dv_format_type_id指示MVC比特流中包括的基本3D格式类型。3DV格式可以为两种类型:2D+Z或者LDV。2D+Z格式包括来自一个视图位置的2D视图及其深度贴图。LDV格式包括来自一个视图位置的2D视图、其深度贴图、遮挡视图、以及遮挡深度贴图。
[0081] basic_three_dv_format_type_id等于0指示MVC比特流包括(num_three_dv_view_minus1+1)组2D+Z数据。每个数据组对应于一个视图位置。num_three_dv_view_minus1等于0代表2D+Z格式。num_three_dv_view_minus1等于或大于1代表MVD格式。
[0082] basic_three_dv_format_type_id等于1指示MVC比特流包括(num_three_dv_view_minus+1)组LDV数据。每个数据组对应于一个视图位置。num_three_dv_view_minus1等于0代表LDV格式。num_three_dv_view_minus1等于1代表DES格式。应该注意,大于1的值是不允许的。
[0083] video_present_flag[3dv_view_id]指示针对当前的3D视图是否存在2D视频分量。值为1指示存在2D视图分量。值为0指示不存在2D视图分量。
[0084] video_id[3dv_view_id]指示与具有3dv_view_id的3DV视图相对应的MVC比特流中的view_id。值为-1指示不存在用于3DV视图的2D视图分量可用在比特流中。
[0085] depth_present_flag[3dv_view_id]指示针对当前的3D视图是否存在深度贴图分量。值为1指示存在深度贴图分量。值为0指示不存在深度贴图分量。
[0086] depth_id[3dv_view_id]指示与具有3dv_view_id的3DV深度分量相对应的MVC比特流中的view_id。值为-1指示不存在用于3DV视图的深度分量可被用在比特流中。
[0087] occlusion_video_present_flag[3dv_view_id]指示针对当前的3D视图是否存在遮挡视频分量。值为1指示存在遮挡视频分量。值为0指示不存在遮挡视频分量。
[0088] occlusion_video_id[3dv_view_id]指示与具有3dv_view_id的遮挡视频分量相对应的MVC比特流中的view_id。值为-1指示不存在用于3DV视图的遮挡视频分量可用在比特流中。
[0089] occlusion_depth_present_flag[3dv_view_id]指示针对当前的3D视图是否存在遮挡深度分量。值为1指示存在遮挡深度分量。值为0指示不存在遮挡深度分量。
[0090] occlusion_depth_id[3dv_view_id]指示与具有3dv_view_id的遮挡深度分量相对应的MVC比特流中的view_id。值为-1指示不存在用于3DV视图的遮挡深度分量可被用在比特流种。
[0091] three_dv_format_repetition_period规定了3DV格式SEI消息的存留,并且可以规定画面序列号间隔(其中的另一3DV格式SEI具有相同的three_dv_format_id值),或者规定编码后的视频序列的尾部存在于比特流中。所以,该语法指定当SEI有效时的时间范围。一个示例性实施方式包括使用POC(画面序列号)间隔。POC可以被理解为正被编码的的索引,其随着显示时间的增加而上升。three_dv_format_repetition_period的值应该被包括在0到16384的范围中。three_dv_format_repetitioni_period等于0规定3DV格式SEI消息仅应用于当前解码的画面。
[0092] three_dv_format_repetition_period等于1规定,在以下条件中的任意条件为真之前3DV格式SEI消息保持输出顺序:
[0093] -新的编码后的视频序列开始。
[0094] -当PicOrderCnt()大于PicOrderCnt(CurrPic)时,包括具有相同的three_dv_format_id值的3DV格式SEI消息的访问单元中的画面被输出。
[0095] three_dv_format_repetition_period等于0或等于1指示是否存在具有相同的three_dv_format_id值的另一3DV格式SEI消息。three_dv_format_repetition_period大于1规定,在以下条件中的任意条件为真之前,3DV格式SEI消息保持不变:
[0096] -新的编码后的视频序列开始。
[0097] -当PicOrderCnt()大于PicOrderCnt(CurrPic)并且小于或者等于PicOrderCnt(CurrPic)+three_dv_format_repetition_period时,包括具有相同的three_dv_format_id值的3DV格式SEI消息的访问单元中的画面被输出。
[0098] three_dv_format_repetition_period大于1指示针对所输出的访问单元中的画面存在具有相同的three_dv_format_id值的另一3DV格式SEI消息,除非在没有这样的画面输出的情况下比特流结束或者新的编码后的视频序列开始。其中该访问单元是具有大于PicOrderCnt()并且小于或等于PicOrderCnt(CurrPic)+three_dv_format_repetition_period的输出端。
[0099] additional_extension_flag等于0指示在3DV格式SEI消息中随后没有额外的数据。additional_extension_flag的值应该等于0。additional_extension_flag的值1被保留以供ITU-T和ISO/IEC将来使用。遵循H.264标准的解码器将忽略空间交织后的画面SEI消息中的值为1的addtional_extension_flag后的所有数据。
[0100] 下面给出了三个示例。
[0101] 示例1:图8是示出对MVC结构中的MVD格式进行编码的示例1000的示意图。本示例中存在两个3DV视图。左侧视图的3dv_view_id为0,右侧视图的3dv_view_id为1。左侧视图被当作基本视图,其可以被AVC兼容的解码器解码。左侧视图1010的view_id为1。左侧深度1005、右侧视图1015、以及右侧深度1020的view_id分别为0、2、和3。表2示出了与实施例1的示例1相对应的用于MVC的3DV SEI消息的MVD示例。
[0102] 表2
[0103]
[0104] 注意,图8中所示的视图依赖信息被通过用于H.264附件H的SPS扩展(也被称为H.264的MVC扩展或者简称为MVC扩展)用信号指示。
[0105] 示例2:图9是示出对MVC结构中的LDV格式进行编码的示例1100的示意图。该示例中只存在一个3DV视图。2D视图被当作基本视图,其可以被AVC兼容的解码器解码。2D视图1110的view_id为1。深度贴图1105、遮挡视频1115、以及遮挡深度贴图1120的view_id分别为0、2、和3。表3示出了与实施例1中的示例2相对应的用于MVC的3DV SEI消息的LDV示例。
[0106] 表3
[0107]
[0108] 示例3:图10是示出对MVC结构中的DES格式进行编码的示例1200的示意图。在该示例中存在两个3DV视图。来自左侧的2D视图被当作基本视图,其可以被AVC兼容的解码器解码。来自左侧的2D视图1220的view_id为3。来自左侧的深度贴图1215、遮挡视频1210、以及遮挡深度贴图1205的view_id分别为2、1、和0。来自右侧的2D视图1225、深度贴图1230、遮挡视频1235、以及遮挡深度1240的view_id分别为4、5、6、以及7。表4示出了与实施例1的示例3相对应的用于MVC的3DV SEI消息的DES示例。
[0109] 表4
[0110]
[0111] 注意,在以上三个示例中,除了3DV视图以外,只具有2D视频数据的一些其他视图也可以被交织在相同比特流中。解码器仍可以正确地从比特流中提取正确的3DV视图。额外的视图可以被用来例如增强接收器端的渲染质量
[0112] 图11是根据本原理的实施例的用于对3DV格式进行编码的示例性方法1300的流程图。图11针对实施例1,并且统一覆盖与其对应的示例1至示例3。在步骤1305,对语法元素three_dv_format_id进行编码。在步骤1310,对语法元素three_dv_format_cancel_flag进行编码。在步骤1315,确定three_dv_format_cancel_flag是否等于0。如果是,则控制传递到步骤1385。如果不是,则控制传递到步骤1320。在步骤1320,对语法元素num_three_dv_view_minus1进行编码。在步骤1325,对语法元素basic_three_dv_format_type_id进行编码。在步骤1330,对于3dv_view_id=0,3dv_view_id<=num_three_dv_view_minus1,以及3dv_view_id++,开始循环。在步骤1335,如果3dv_view_id!=0,则对语法元素video_present_flag[3dv_view_id]进行编码;否则,假设语法元素3dv_view_id等于1。在步骤
1340,如果video_present_flag[3dv_view_id]==1,则对语法元素video_id[3dv_view_id]进行编码。在步骤1345,对语法元素depth_present_flag[3dv_view_id]进行编码。在步骤1350,如果depth_present_flag[3dv_view_id]==1,则对语法元素depth_id[3dv_view_id]进行编码。在步骤1355,如果basic_three_dv_format_type_id==1,则对语法元素occlusion_video_present_flag[3dv_view_id]进行编码;否则,假设语法元素basic_three_dv_format_type_id等于0。在步骤1360,如果occlusion_video_present_flag[3dv_view_id]!=0,则对语法元素occlusion_video_id[3dv_view_id]进行编码。在步骤1365,如果basic_three_dv_format==1,则对语法元素occluson_depth_present_flag[3dv_view_id]进行编码;否则,假设语法元素basic_three_dv_format等于0。在步骤1370,如果occlusion_depth_present_flag[3dv_view_id]!=0,则对语法元素occlusion_depth_id[3dv_view_id]进行编码。在步骤1375,对于3dv_view_id=0,3dv_view_id<=num_three_dv_view_minus1,以及3dv_view_id++,结束循环。在步骤1380,对语法元素three_dv_format_repetition_period进行编码。在步骤1385,对语法元素additional_extension_flag进行编码。
[0113] 图12是示出根据本原理的实施例的用于对3DV格式进行解码的示例性方法1400的流程图。图12针对实施例1,并且统一覆盖与其对应的示例1至示例3。在步骤1405,对语法元素three_dv_format_id进行解码。在步骤1410,对语法元素three_dv_format_cancel_flag进行解码。在步骤1415,确定three_dv_format_cancel_flag是否等于0。如果是,则控制传递到步骤1485。如果不是,则控制传递到步骤1420。在步骤1420,对语法元素num_three_dv_view_minus1进行解码。在步骤1425,对语法元素basic_three_dv_format_type_id进行解码。在步骤1430,对于3dv_view_id=0,3dv_view_id<=num_three_dv_view_minus1,以及3dv_view_id++,开始循环。在步骤1435,如果3dv_view_id!=0,则对语法元素video_present_flag[3dv_view_id]进行解码;否则假设语法元素3dv_view_id等于1。在步骤
1440,如果video_present_flag[3dv_view_id]==1,则对语法元素video_id[3dv_view_id]进行解码。在步骤1445,对语法元素depth_present_flag[3dv_view_id]进行解码。在步骤1450,如果depth_present_flag[3dv_view_id]==1,则对语法元素depth_id[3dv_view_id]进行编码。在步骤1455,如果basic_three_dv_format_type_id==1,则对语法元素occlusion_video_present_flag[3dv_view_id]进行解码;否则,假设语法元素basic_three_dv_format_type_id等于0。在步骤1460,如果occlusion_video_present_flag[3dv_view_id]!=0,则对语法元素occlusion_video_id[3dv_view_id]进行解码。在步骤1465,如果basic_three_dv_format_type_id==1,则对语法元素occlusion_depth_present_flag[3dv_view_id]进行解码;否则,假设语法元素basic_three_dv_format_type_id等于
0。在步骤1470,如果occlusion_depth_present_flag[3dv_view_id]!=0,则对语法元素occlusion_depth_id[3dv_view_id]进行解码。在步骤1475,对于3dv_view_id=0,3dv_view_id<=num_three_dv_view_minu1,以及3dv_view_id++,结束循环。在步骤1480,对语法元素three_dv_format_repetition_period进行解码。在步骤1485,对语法元素additional_extension_flag进行解码。
[0114] 实施例2:用于MVC的简化后的3DV格式SEI消息
[0115] 注意,在另一实施例中,期望以隐含方式将view_id映射到3dv_view_id,并且语法可以相对于实施例1被简化。表5示出了用于MVC的简化后的3DV格式SEI消息。
[0116] 表5
[0117]
[0118] 利用简化后的SEI消息,view_id被以下面的隐含方式映射到3dv_view_id。当basic_3dv_format_id为0时,如表6中所示,上升顺序的view_id被映射到3dv_view_id。当basic_3dv_format_id为1时,如表7中所示,上升顺序的view_id被映射到3dv_view_id。
[0119] 表6
[0120]按照上升次序分类的view_id 3dv_view_id
view_id(0) 3dv_view_id=0,2D视图
view_id(1) 3dv_view_id=0,深度贴图
view_id(2) 3dv_view_id=1,2D视图
view_id(3) 3dv_view_id=1,深度贴图
… …
… …
[0121] 表7
[0122]
[0123] 示例1:
[0124] 图13是示出对MVC结构中的MVD格式进行编码的另一示例1500的示意图。其中在MVC结构中使用了表6的从view_id到3dv_view_id的映射。框1505、1510、1515、以及1520中分别示出的数字V0、V1、V2、以及V3代表该框的相应view_id。每个框的相应3dv_view_id分别被指示在每个框下面。箭头从参考视图指向将要预测的视图。框1505指示左侧视图的2D视频。框1510指示左侧视图的深度。框1515指示右侧视图的2D视频。框1520指示右侧视图的深度。
[0125] 示例2:
[0126] 图14是示出对MVC结构中的LDV格式进行编码的另一示例1600的示意图。其中,在MVC结构中使用了表7的从view_id到3dv_view_id的映射。框1605、1610、1615、以及1620中分别示出的数字V0、V1、V2、以及V3代表该框的相应view_id。每个框下面是在3DV背景下该框的角色的指示。箭头从参考视图指向将要预测的视图。框1605指示2D视频。框1610指示相应深度。框1615指示相应遮挡视频。框1620指示相应遮挡深度。
[0127] 示例3:
[0128] 图15是示出对MVC结构中的DES格式进行编码的另一示例1700的示意图。其中,在MVC结构中,使用了表7的从view_id到3dv_view_id的映射。框1705、1710、1715、1720、1725、1730、1735、以及1740中分别示出的数字V0、V1、V2、V3、V4、V5、V6、以及V7代表该框的相应view_id。每个框下面是3DV背景中该框的角色的指示。箭头从参考视图指向将要预测的视图。框1705指示左侧视图的2D视频。框1710指示左侧视图的相应深度。框1715指示左侧视图的相应遮挡视频。框1720指示左侧视图的相应遮挡深度。框1725指示右侧视图的2D视频。框
1730指示右侧视图的相应深度。框1735指示右侧视图的相应遮挡视频。框1740指示右侧视图的相应遮挡深度。
[0129] 图16是示出根据本原理的实施例的用于对3DV格式进行编码的示例性方法800的流程图。图16针对实施例2,并且统一覆盖与其对应的示例1至示例3。在步骤1805,对语法元素three_dv_format_id进行编码。在步骤1810,对语法元素three_dv_format_cancel_flag进行编码。在步骤1815,确定three_dv_format_cancel_flag是否等于0。如果是,则控制传递到步骤1835。如果不是,则控制传递到步骤1820。在步骤1820,对语法元素num_three_dv_view_minus1进行编码。在步骤1825,对语法元素basic_three_dv_format_type_id进行编码。在步骤1830,对语法元素three_dv_format_repetition_period进行编码。在步骤1835,对语法元素additional_extension_flag进行编码。
[0130] 图17是示出根据本原理的实施例的用于对3DV格式进行解码的示例性方法1900的流程图。图17针对实施例2,并且统一覆盖与其对应的示例1至示例3。在步骤1905,对语法元素three_dv_format_id进行解码。在步骤1910,对语法元素three_dv_format_cancle_flag进行解码。在步骤1915,确定three_dv_format_cancle_flag是否等于0。如果是,则控制传递到步骤1935。如果不是,则控制传递到1920。在步骤1920,对语法元素num_three_dv_view_minus1进行解码。在步骤1925,对语法元素basic_three_dv_format_type进行解码。在步骤1930,对语法元素three_dv_format_repetition_period进行解码。在步骤1935,对语法元素additonal_extension_flag进行解码。
[0131] 实施例3:用于SVC的3DV格式SEI
[0132] 作为AVC的另一个扩展,SVC支持分层编码结构,以在时域、空间域、或者质量域中提供可缩放性。在该实施例中,我们提出用于SVC的3DV格式SEI消息,以用信号指示3DV格式,如表8中所示。使用SVC的好处之一是可以利用层间预测(cross-layer)来去除分量间冗余(例如,视频中的运动和深度贴图中的运动之间的冗余)。
[0133] 表8
[0134]
[0135] video_present_flag[3dv_view_id]指示是否存在针对当前的3D视图的2D视图分量。值为1指示存在2D视图分量。值为0指示不存在2D视图分量。
[0136] video_dependency_id[3dv_view_id]、video_quality_id[3dv_view_id]、以及video_temporal_id[3dv_view_id]分别指示来自具有特定的3dv_view_id的3DV视图的2D视图分量序列的dependency_id、quality_id、以及temporal_id。在H.264附件G中规定了dependency_id、quality_id、以及temporal_id的各个定义。
[0137] depth_present_flag[3dv_view_id]指示是否存在针对当前的3D视图的深度贴图分量。值为1指示存在深度贴图分量。值为0指示不存在深度贴图分量。
[0138] depth_dependency_id[3dv_view_id]、depth_quality_id[3dv_view_id]、以及depth_temporal_id[3dv_view_id]分别指示来自具有特定的3dv_view_id的3DV视图的dependency_id、quality_id、以及temporal_id。在H.264附件G中规定了dependency_id、quality_id、以及temporal_id的各个定义。
[0139] occlusion_video_present_flag[3dv_view_id]指示是否存在针对当前3D视图的遮挡视频分量。值为1指示存在遮挡视频分量。值为0指示不存在遮挡视频分量。
[0140] occlusion_video_dependency_id[3dv_view_id]、occlusion_video_quality_id[3dv_view_id]、以及occlusion_video_temporal_id[3dy_view_id]分别指示来自具有特定的3dv_view_id的3DV视图的遮挡视图分量序列的dependency_id、quality_id、以及temporal_id。H.264附件G中规定了dependency_id、quality_id、以及temporal_id的各个定义。
[0141] occlusion_depth_present_flag[3dv_view_id]指示是否存在针对当前3D视图的遮挡深度分量。值为1指示存在遮挡深度分量。值为0指示不存在遮挡深度分量。
[0142] occlusion_depth_dependency_id[3dv_view_id]、occlusion_depth_quality_id[3dv_view_id]、以及occlusion_depth_temporal_id[3dv_view_id]分别指示来自具有特定的3dv_view_id的3DV视图的遮挡深度贴图分量序列的dependency_id、quality_id、以及temporal_id。在H.264附件G中规定了dependency_id、quality_id、以及temporal_id的各个定义。
[0143] 应该明白,实施例1中列出的所有三个示例(涉及图8至图10)被映射到SVC架构。例如,LDV格式可以被实现在图18中的SVC中,其对应于实施例1中的图9。框2005、2010、2015、和2020中分别示出的数字L3、L2、L1、和L0代表该框的相应dependency_id。这些框的左侧是3DV背景下的角色的指示。箭头从参考层指向将要预测的层。框2020指示2D视频。框2015指示相应深度。框2010指示相应遮挡视频。框2005指示相应遮挡深度。
[0144] 表9示出了根据本原理的实施例的用于SVC的3DV格式SEI消息的示例。
[0145] 表9
[0146]
[0147] 图19是示出根据本原理的实施例的用于对3DV格式进行编码的示例性方法2100的流程图。在步骤2105,对语法元素three_dv_format_id进行编码。在步骤2110,对语法元素three_dv_format_cancel_flag进行编码。在步骤2115,确定three_dv_format_cancle_flag是否等于0。如果是,则控制传递到步骤2185。如果不是,则控制传递到步骤2120。在步骤2120,对语法元素num_three_dv_view_minus1进行编码。在步骤2125,对语法元素basic_three_dv_format_type_id进行编码。在步骤2130,对于3dv_view_id=0,3DV_view_id<=num_three_dv_view_minus1,以及3dv_view_id++,开始循环。在步骤2135,如果3dv_view_id!=0,则对语法元素video_present_flag[3dv_view_id]进行编码;否则,假设语法元素3dv_view_id等于1。在步骤2140,如果video_present_flag[3dv_view_id]==1,则对语法元素video_dependency_id[3dv_view_id]、video_quality_id[3dv_view_id]、以及video_temporal_id[3dv_view_id]进行编码。在步骤2145,对语法元素depth_present_flag[3dv_view_id]进行编码。在步骤2150,如果depth_present_flag[3dv_view_id]==1,则对语法元素depth_dependency_id[3dv_view_id]、depth_quality_id[3dv_view_id]、以及depth_temporal_id[3dv_view_id]进行编码。在步骤2155,如果basic_three_dv_format_type_id==1,则对语法元素occlusion_video_present_flag[3dv_view_id]进行编码;否则,假设语法元素basic_three_dv_format_type_id等于0。在步骤2160,如果occlusion_video_present_flag[3dv_view_id]==1,则对语法元素occlusion_video_dependency_id[3dv_view_id]、occlusion_video_quality_id[3dv_view_id]、以及occlusion_video_temporal_id[3dv_view_id]进行编码。在步骤2165,如果basic_three_dv_format_type_id==1,则对语法元素occlusion_depth_present_flag[3dv_view_id]进行编码;否则,假设语法元素occlusion_depth_present_flag[3dv_view_id]等于0。在步骤2170,如果occlusion_depth_present_flag[3dv_view_id]==1,则对语法元素occlusion_depth_dependency_id[3d_view_id]、occlusion_depth_quality_id[3dv_view_id]、以及occlusion_depth_temporal_id[3dv_view_id]进行编码。在步骤2175,对于3dv_view_id=
0,3dv_view_id<=num_three_dv_view_minus1,以及3dv_view_id++,结束循环。在步骤
2180,对语法元素three_dv_format_repetition_period进行编码。在步骤2185,对语法元素additional_extension_flag进行编码。
[0148] 图20是示出根据本原理的实施例的用于对3DV格式进行解码的示例性方法2200的流程图。图20针对实施例3。在步骤2205,对语法元素three_dv_format_id进行解码。在步骤2210,对语法元素three_dv_format_cancel_flag进行解码。在步骤2215,确定three_dv_format_cancle_flag是否等于0。如果是,则控制传递到步骤2285。如果不是,则控制传递到步骤2120。在步骤2220,对语法元素num_three_dv_view_minus1进行解码。在步骤2225,对语法元素basic_three_dv_format_type_id进行解码。在步骤2230,针对3dv_view_id=0,
3DV_view_id<=num_three_dv_view_minus1,以及3dv_view_id++,开始循环。在步骤
2235,如果3dv_view_id!=0,则对语法元素video_present_flag[3dv_view_id]进行解码;
否则,假设语法元素3dv_view_id等于1。在步骤2240,如果video_present_flag[3dv_view_id]==1,则对语法元素video_dependency_id[3dv_view_id]、video_quality_id[3dv_view_id]、以及video_temporal_id[3dv_view_id]进行解码。在步骤2245,对语法元素depth_present_flag[3dv_view_id]进行解码。在步骤2250,如果depth_present_flag[3dv_view_id]==1,则对语法元素depth_dependency_id[3dv_view_id]、depth_quality_id[3dv_view_id]、以及depth_temporal_id[3dv_view_id]进行解码。在步骤
2255,如果basic_three_dv_format_type_id==1,则对语法元素occlusion_video_present_flag[3dv_view_id]进行解码;否则假设语法元素basic_three_dv_format_type_id等于0。在步骤2260,如果occlusion_video_present_flag[3dv_view_id]==1,则对语法元素occlusion_video_dependency_id[3dv_view_id]、occlusion_video_quality_id[3dv_view_id]、以及occlusion_video_temporal_id[3dv_view_id]进行解码。在步骤
2265,如果basic_three_dv_format_type_id==1,则对语法元素occlusion_depth_present_flag[3dv_view_id]进行解码,否则假设语法元素occlusion_depth_present_flag[3dv_view_id]等于0。在步骤2270,如果occlusion_depth_present_flag[3dv_view_id]==1,则对语法元素occlusion_depth_dependency_id[3dv_view_id]、occlusion_depth_quality_id[3dv_view_id]、以及occlusion_depth_termporal_id[3dv_view_id]进行解码。在步骤2275,对于3dv_view_id=0,3dv_view_id<==num_three_dv_view_minus1、以及3dv_view_id++,结束循环。在步骤2280,对语法元素three_dv_format_repetition_period进行解码。在步骤2285,对语法元素additional_extension_flag进行解码。
[0149] 实施例4:用于SVC/MVC的3DV格式SEI
[0150] 在先前的三个实施例中,每个3DV分量被独立地当作MVC中的视图或者SVC中的层。在该实施例中,提出首先对一些3DV分量进行空间交织,然后将空间交织后的分量当作MVC中的视图或者SVC中的层。
[0151] 在实施方式中存在很多不同的组合。在MVD再现格式中,一个示例是逐侧放置2D及其深度,然后将每个2D+Z图像序列当作MVC中的一个视图(或者SVC中的一层)。在另一示例中,两个2D图像首先被逐侧排列,然后两个深度贴图被逐侧排列。然后,我们将组合后的2D图像序列当作一个视图(或者一层),并且将组合后的深度贴图当作另一个视图(或者另一层)。
[0152] 应该明白,在这里提出的本原理的教导下,本领域以及相关领域的普通技术人员可以很容易地利用各种相应的实施方式将本原理扩展到LDV情况中。
[0153] 空间交织可以是逐侧的、从上到下的(above-below)、棋盘格式的、行交织的、或者列交织的,等等。
[0154] 先前的实施例的信令方法也可以被应用于或用于这些实施例。
[0155] 图21是示出根据本原理的实施例的用于对3DV格式进行编码的示例性方法2300的流程图。图21针对实施例4。在步骤2305,针对一些3DV分量执行空间交织,该空间交织是例如逐侧的、从上到下的、棋盘格式的、行交织的、或者列交织的。在步骤2310,确定空间交织后的3DV分量是否将被当作MVC下的视图。如果是,则控制传递到步骤2315。如果不是,则控制传递到2320。在步骤2315,利用MVC编码器对交织后的“视图”进行编码。在步骤2320,确定空间交织后的3DV分量是否将被当作SVC下的视图。如果是,则控制传递到步骤块2325。如果不是,则控制传递到步骤2330。在步骤2325,利用SVC编码器对交织后的“层”进行编码。在步骤2330,为其他编码器预留处理。
[0156] 图22是示出根据本原理的实施例的用于对3DV格式进行解码的示例性方法2400的流程图。图22针对实施例4。在步骤2405,确定空间交织的3DV分量是否将被当作MVC下的视图。如果是,则控制传递到步骤2410。如果不是,控制传递到步骤2415。在步骤2410,利用MVC解码器对交织后的“视图”进行解码。在步骤2415,确定空间交织后的3DV分量是否将被当作SVC下的视图。如果是,则控制传递到步骤2420。如果不是,控制传递到步骤2425。在步骤2420,利用SVC解码器对交织后的“层”进行解码。在步骤2425,为其他解码器预留处理。在步骤2430,对一些3DV分量执行空间解交织处理。空间解交织例如是逐侧的、从上到下的、棋盘格式的、行交织的、或者列交织的。
[0157] 所以,我们提供了一种或多种具有特定特征和方面的实施方式。然而,所描述的实施方式的多个特征和方面也可以被用于其他实施方式。
[0158] 另外,所描述的实施方式可以被以各种方式使用。例如,这些实施方式可以增大在各种所描述的实施方式的语法和语义中规定的3DV视图的数目和/或3DV格式类型的数目。另外,这些实施方式可以执行时间上的预测。例如,可以根据相同3DV分量(例如,图8中所示)、不同3DV分量(例如,在图10中,右侧3DV视图中的V4是根据左侧3DV视图中的V3预测出来的)、和/或不同时间点出现的不同3DV分量中的参考预测出3DV分量。例如,可以将来自先前出现的3DV视图的左侧深度图像作为参考预测出图8的左侧深度图像1005。
[0159] 本申请中描述的一些实施方式和特征可以用在H.264/MPEG-4AVC(AVC)标准、或者具有MVC扩展的AVC标准、或者具有SVC扩展的AVC标准的背景中。但是,这些实施方式和特征也可以被用在另一标准(现有或者将来的标准)的背景中,或者被用在不包括标准的背景中。所以,我们提供了一种或多种具有特定特征和方面的实施方式。但是,所描述的实施方式的特征和方面可以被用于其他实施方式。
[0160] 多种实施方式可以使用各种技术来用信号指示信息,这些技术包括但不限于SEI消息、条带头、其他高级语法、非高级语法、带外(out-of-band)信息、数据流数据、以及隐含信令。因此,尽管可以在特定背景下描述这里描述的实施方式,但是这些描述不应该被看作将特征和概念限制到这些实施方式或背景。
[0161] 另外,可以在编码器、解码器、处理来自解码器的输出的后处理器、以及向编码器提供输入的前处理器中实现很多种实施方式。另外,本公开还想到了其他实施方式。
[0162] 说明书中对于本原理的“一个实施例”、或者“实施例”、或者“一种实施方式”、或者“实施方式”及它们其他变型的引用是指结合实施例描述的特定特征、结构、特性等被包括在本原理的至少一个实施例中。所以,短语“在一个实施例中”、或者“在实施例中”、或者“在一种实施方式中”、或者“在实施方式中”、以及任何其他变型贯穿说明书在不同位置的出现不必全部指向同一实施例。
[0163] 应该理解,例如在“A/B”、“A和/或B”、以及“A和B中的至少一个”的情况中对于“/”、“和/或”、以及“其中的至少一个”中任意一个的使用意指覆盖仅选择第一个列出的选项A、或者仅选择第二个列出的选项B、或者选择选项A和B二者。作为进一步的示例,在“A、B、和/或C”、“A、B、以及C中的至少一个”、以及“A、B、或C中的至少一个”的情况中,这种措词意指覆盖仅选择第一个列出的选项A、或者仅选择第二个列出的选项B、或者仅选择第三个列出的选项C、或者仅选择第一个和第二个列出的选项A和B、仅选择第一个和第三个列出的选项A和C、仅选择第二个和第三个列出的选项B和C、或者选择所有三个选项A、B、C。如本领域以及相关领域的普通技术人员显而易见的,这可以延伸到很多条目被列出的情况中。
[0164] 另外,如这里所使用的,词“画面”和“图像”被交换使用,并且指来自视频序列的全部或部分静止图像或全部或部分画面。更一般地,画面是指例如人意一组图像或视频数据。画面还可以是例如像素、宏块、条带、帧、场、全画面、限制画面中的对象的区域、画面的前景、画面的背景、或者画面中的一个特定的坐标组(x,y)。类似地,画面的“部分”可以是例如像素、宏块、条带、帧、场、限制画面中的对象的区域、画面的前景、画面的背景、或者画面中的一个特定的坐标组(x,y)。作为另一示例,深度画面(深度贴图)可以是例如完整的深度贴图或者进包括例如相应的视频帧的单个宏块的深度信息的局部深度贴图。
[0165] 另外,本申请或其权利要求可以指“确定”各种信息项。确定信息可以包括例如估计信息、计算信息、预测信息、或者从存储器检索信息中的一项或多项。
[0166] 类似地,“访问”意指广播术语。访问一个信息项可以包括使用、存储、发送、接收、检索、修改、或者提供信息的任意操作。
[0167] 这里描述的实现可以被实现为例如一种方法或者处理、装置、软件程序、数据流或者数据。即使只以一种形式的实现讨论(例如,只被作为一种方法讨论),所讨论的特征的实现也可以被以其他形式实现(例如,装置或程序)。装置可以被实现在例如适当的硬件、软件、以及固件中。这些方法可以被实现在例如诸如处理器之类的装置中,其中处理器包括例如计算机、微处理器、集成电路、或者可编程逻辑设备等并被统称为处理设备。处理器还包括诸如例如计算机、蜂窝电话、便携式/个人数字助理(PDA)、以及方便中断用户之间的信息通信的其他设备。
[0168] 这里描述的各种处理和特征的实现可以被包含在各种不同装备或应用中,尤其是可以被包含在例如与数据编码和解码相关联的装备或应用中。这种装备的示例包括编码器、解码器、处理来自解码器的输出的后处理器、向编码器提供输入的前处理器、视频编码器、视频解码器、视频编解码器、web服务器、机顶盒、膝上型计算机、个人计算机、蜂窝电话、PDA、以及其他通信设备。应该明白,该装备可以是移动得,甚至被安装在移动车辆中。
[0169] 另外,这些方法可以通过处理器所执行的指令来实现,并且这些指令(和/或通过实现产生的数据值)可以被存储在处理器可读介质上,处理器可读介质例如是集成电路、软件载体、或者诸如例如硬盘、压缩盘、随机存取存储器(RAM)或者只读存储器(ROM)之类的其他存储设备。这些指令可以形成可以有形地实现在处理器可读介质上的应用程序。这些指令可以在硬件、固件、软件、或者组合中。指令可以被建立在例如操作系统、独立应用、或者二者的组合中。处理器可以被特征化为例如被配置为执行处理的设备以及包括具有用于执行处理的指令的处理器可读介质(诸如存储设备)的设备中。另外,处理器可读介质除了可以存储只另外还可以存储由实现产生的数据值,或者可以存储由实现产生的数据值来替代指令。
[0170] 对于本领域技术人员显而易见的是,实现可以产生被格式化为携带可以被例如存储或发送的信息的各种信号。该信息可以包括例如,用于执行一种方法的指令、或者由所描述的实现之一产生的数据。例如,信号可以被格式化为携带作为用于写入或读取所描述的实施例的语法的规则的数据、或者携带由所描述的实施例写入的实际的语法值的数据。这种信号可以被格式化为电磁波(例如,使用频谱的无线电频率部分)或者基带信号。格式化可以包括例如,对数据流进行编码并利用编码后的数据流对载波进行调制。信号携带的信息可以是例如模拟或数字信息。信号可以在已知的各种不同的优先或无线链路上发送。信号可以被存储在处理器可读介质上。
[0171] 描述了大量实现。但是,将会理解可以做出各种变型。例如,不同实现的元素可以被结合、补充、修改、或者去除,以产生其他实现。另外,操作可以在功能块之间相互交换。另外,本领域普通技术人员将理解,其他结构和处理可以替代所公开的这些结构和处理,并且得到的实现将以至少基本相同的方式执行至少基本相同的功能,以实现至少与所公开的实现基本相同的结果。因此,这些其他实现可以被该应用预测,并且落入后面的权利要求的范围中。
[0172] 类似地,应该明白,在以上描述的实现中,为了方便公开并且帮助理解各个方面的一个或多个方面,各种特征有时可以被组合在一个实现、附图、或者描述中。但是,本公开的方法不应该被解释为反映这样的意图:请求保护的发明需要比每个权利要求中清楚陈述的特征更多的特征。相反,如下面的权利要求所反映的,发明方面可以在于少于单个前面公开的实施例的所有特征。所以,应该理解,每个权利要求也提供单独的实现。
高效检索全球专利

专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台,是提供专利分析,专利查询,专利检索等数据服务功能的知识产权数据服务商。

我们的产品包含105个国家的1.26亿组数据,免费查、免费专利分析。

申请试用

分析报告

专利汇分析报告产品可以对行业情报数据进行梳理分析,涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度,系统通过AI智能系统对图表进行解读,只需1分钟,一键生成行业专利分析报告。

申请试用

QQ群二维码
意见反馈