H264 MVC（multiple view coding)标准

原文地址：http://blog.sina.com.cn/s/blog_80ce3a550100ycc3.html

在H264的附录ANNEX H中定义了MVC扩展，用于支持3D视频和FTV多视点编码。

1.历史
  在双目3D视频中，通常需要提供left/right view两个视点的图像，这两个视点的图像是有相关性的，同样，
  对于多view视图之间也是有一定相关性的，因此很自然的想法就是要利用view之间的相关性来提高压缩效率，
  这就是MVC的目的。
  如果没有MVC扩展标准，只是使用H264之前的标准来进行压缩，那么一个可选的方法就是把left/right view
  作为串行来进行参考，比如：
   L1 R1 L2 R2 L3 R3 L4 R4 L5 R5
  将左右视点图像看成普通的连续图像进行参考，这种方法也能利用视点间的相关性，但是由于参考帧数目的限制会使得参考的效率不高(假设8 VIEW图像进行压缩，那么除了view间的参考外，在时间上的参考只能有2帧,这
  对不同时刻的帧间预测带来了影响，如下图：
   V11 V12 V13 V14 V15 V16 V17 V18 V21 V22 V23 V24 V25 V26 V27 V28 V31.....
  参考帧最大为16，因此V31只能参考前面的2个时刻的16个view；而在单view中可以参考前面16个时刻的图像。

 为了平衡这种view间参考和时间上的参考的效率，因此提出了MVC算法来解决这些问题。
 在MVC设计中，预测参考的结构是最为关键的。
 下面是一个典型的MVC参考结构：
      
上图是一个8 view的参考结构，每个view可以参考同一个时刻的其它view，也可以参考同该视点相同位置的其它时刻的view，但是不允许参考不同时刻的其它位置的view(tradeoff的要求).
I帧只是出现在view0中，其它view不出现I帧。
总结下来：
   inter-view参考只能出现在同一个access unit中。

2. 术语
   anchor picture：不做inter prediction的(可以做inter—view prediction)图像，所有的参考只在同一个
                   access unit中。
   access unit: 同一个时刻的多个view的集合
   anchor access unit:包含anchor picture的access unit
   base view:  首先这是一个view，但是这个view不参考其它的view，也就是不做inter-view prediction。
   target output view: 会被输出的view，在实际的应用中，比如多视点电视可以根据用户的位置来输出当前
                       位置的view，而不是把所有的view都输出，这些需要输出的view就是目标输出view。
   target temporal level: operation point中temporal id的最大值。
   operation point: target ouput view和解码这些target output view需要的参考view的集合，通过
                    预先定义几个operation point，解码端可以只解码同该operation point相关的view。
   inter-view only reference component: 只作为inter-view的参考帧而不作为inter-prediction的参考帧
                                         nalu->nal_ref_idc = 0 & nalu->inter_view_flag=1
                                         上图中的绿色的b的图像都是这种性质.

 在上图中，S0，S2，S4，S6是base view，这几个view不参考其它的view。
 T0/T8时刻的access unit是anchor access unit，这几个AU只做inter-view参考，而不做Inter-prediction。
 
 在很多的应用中不需要解码所有的MVC码流，而是根据应用场景来选择解码同某operation point相关的substream。 
    
3.标准语法相关
  profile & level:
     MVC提供了2种profile：
          multiple view high profile：超过2个view， profile_idc = 118
          stereo high profile：只处理2-view视频,    profile_idc=128
    首先上面这两个profile都符合H264中的high profile的限制(首先是一个high profile)
    只支持YUV420/YUV400，8bit数据,详细的限制如下：
               frame_mbs_only_flag = 1
               num_slice_groups_minus1 = 0
               chroma_format_idc = 0/1
               bit_depth_luma_minus8 = 0
               high profile限制

   level由sps->level提供，另外，sps_mvc->level[i]中也定义了多个同OP数目相关的level。

  NAL header扩展：
     

在MVC的扩展中，引入了几个新的语法：
    non_idr_flag:表示当前access unit是否是IDR access unit
    priority_id: 表示该NALU的优先级，值越小，优先级越高。
    view_id:  表示该NALU是属于哪一个view
    temporal_id: 表示该NALU的temporal id。由于采用了hierarchy B的temporal（inter-prediction)分层编
                 码方式，因此需要 temporal id来表示该NALU属于temporal分层的哪一个层。在temporal 分
                 层编码中，不能参考比自己的temporal_id大的图像(不能参考更高temporal分层的图像)。
    anchor_pic_flag:当前access unit是否是一个anchor access unit
    inter_view_flag: 表示当前view是否可以被其它的view来参考(是否可以做inter view reference)


  SPS扩展语法：
 NALU_UNIT_TYPE = 15：
     

 

 num_views_minus1: 在图像序列中最大的view的数目，取值为[0,1023]
 view_id[i]:   表示的是view的解码顺序，比如下面的例子：(VOIdx = i)
         VOIdx:     0         1        2         3           4
         view_id:   0         2        1         4           3
             
            在上面的例子中，view的解码顺序是view 0,2,1,4,3.
            那么语法view_id[0] = 0, view_id[1]=2,.....
            在参考代码JMVC中有下面的config文件，其中的vieworder就是描述的这个语法：
                 
 num_anchor_refs_l0[ i ]
 anchor_ref_l0[ i ][ j ]
 num_anchor_refs_l1[ i ]
 anchor_ref_l0[ i ][ j ] ：如果当前view是anchor view，那么使用这个语法表示在inter-view参考中的前向
                          /后向参考view的个数和对于的view_id。

 num_non_anchor_refs_l0[ i ]
 non_anchor_ref_l0[ i ][ j ]
 num_non_anchor_refs_l1[ i ]
 non_anchor_ref_l0[ i ][ j ] ：如果当前view不是anchor view，那么使用这个语法表示在inter-view参考中
                               的前向/后向参考view的个数和对于的view_id。

这几个num最大的取值为  Min( 15, num_views_minus1 )

在JMVC的config中:
  Fwd_AnchorRefs 0  2
有2个值：第一个值表示的是ref_id,第二个值为view_id

通过这些语法完整的描述了inter-view参考的结构。比如在上面的config中，可以知道
view 1 参考了view0和view2（inter-view参考中)


num_level_values_signalled_minus1
level_idc[ i ]
num_applicable_ops_minus1[ i ]  : 描述定义了多少个level，每一个level的取值，以及同该level相关的
                                  operation point的定义(op数目为[0,1023])。

每个operation point的信息：
applicable_op_temporal_id[ i ][ j ] ：同该op相关的temporal_id
applicable_op_num_target_views_minus1[ i ][ j ] ：target ouput view的个数
applicable_op_target_view_id[ i ][ j ][ k ] ：target output view的id
applicable_op_num_views_minus1[ i ][ j ]：解码该OP会涉及到多少个view(包括target output view和这些
                                          target output view的参考view的数目).

在JMVC的config中：
         

                          
sliceHeader语法：
   

  下面是原来H264的参考帧重排的语法：
     

从对比可以知道，多了2种命令4,5.这是因为MVC中引入了inter-view参考帧，因此需要提供专门的命令来
对这些Inter-view reference来进行操作:
   

  MVC SEI语法：
   MVC中增加了很多的SEI定义：
        parallel_decoding_info
        mvc_scalable_nesting
        view_scalability_info
        multiview_scene_info：最大视差信息
        multiview_acquisition_info：描述相机的参数
        non_required_view_component
        view_dependency_change
        operation_point_not_present
        base_view_temporal_hrd


4. 编码和解码流程
   H264 MVC和H264相比，只不过是多了一个inter-view 参考，只是影响DPB管理部分，对编码和解码流程没有
   什么影响。
   编码顺序：目前主流的有2种编码的顺序 view-first order 和 time-first order
         

在view-first order中，在一个GOP内对anchor AU先全部编码，对其它的AU，先对一个view全部编码，再编码下一个view.考虑到上面的参考结构，view-first order的编码顺序需要的frame buffer非常的多。

在time-first order中，在一个GOP内对anchor AU先全部编码，对其它的AU，先对一个time中的全部view编码，再编码下一个time中的全部view.(一个AU一个AU的编)

frame Buffer大小评估：（不考虑H264中的多参考帧(max = 16),不考虑output delay)
     time-first order:
             

需要了解的是，预测结构没有规定，有很多种预测结构都是可以接受的，因此评估时需要根据某一个预测结构来进行估算。
根据基本预测结构来计算需要的帧buffer的数目：
   (1) 首先偶数时刻T的view在hierarchy B中作为参考帧，因此这些时刻的所有的view都会作为其它奇数时刻T
       的view的参考，因此都要存储到DPB中。
   (2) T1时刻的view中，偶数view作为参考view，奇数view不做参考，因此需要存储2个相邻的view作为view间
       参考。（2）
  根据上面的描述,time-first的DPB buffer数目为：
      （1） buffer = nv * (TL + 1) ,  TL= log2(GOP)
       (2)  buffer = buffer + 2
  
  因此最大的DPB BUFFER = nv(TL + 1） + 2.

   在上图中，DPB buffer = 8 * 4 + 2= 34   （GOP = 8）
  

 view-first order:
    

在view-first order顺序中，除了anchor AU以外，其余时刻按照view来编码。
   (1) anchor AU：
       T0时刻的anchor view全部存储到DPB。
   (2) 由于是view-first，而偶数view都作为参考view，因此view S0/S2全部存储(为view S1）。
           
   (3) 在奇数view中，hierarchy B预测被使用，因此偶数T时刻的被存储
 
   最大DPB BUFFER计算：
     (1)  buffer = nv
     (2)  buffer = buffer + 2* GOP
     (3)  buffer = buffer + log2(GOP)

    sum　= nv + 2*GOP + log2(GOP)


如果考虑上面的预测结构(没有多参考帧)，但是考虑output delay：
   在3D TV中，在某一个时刻需要同时输出该时刻的所有的view，因此前面在view-first order中，前面的view
   被解码后也不能立刻去显示，而是必须等到该时刻的最后一个view也解码完成后才能一起输出到显示端。这
   种3D TV的应用中，需要的DPB buffer更多。

   在FTV（free viewpoint)应用中，显示端根据用户的位置显示当前时刻同该位置相关的view(不像3D TV那样
   需要输出当前时刻的所有的view)，因此相比3D TV的应用，FTV的输出delay没有这么大。
        

从上面的分析可以看到，time-first order需要的DPB buffer比较少，而且效率上没有损失。因此
推荐使用time-first order。
 
正如前面所说，预测结果不仅仅只有基本预测结构这一种，其它的预测结构也是可以的。
    


参考文件：
   1. Overview of Multi-view Video Coding. Yo-Sung Ho and Kwan-Jung Oh 
   2. BUFFER REQUIREMENT ANALYSES FOR MULTIVIEW VIDEO CODING,Ying Chen1
                                                             , Ye-Kui Wang
                                                             , Moncef Gabbouj
   3. The EmergingMVC Standard for 3D Video Services。 Ying Chen