POC和frame_num的概念

由于POC对于参考序列的初始化,重排序及标记关系重大,所以做了如下的分析:以下讨论情况是针对帧编 码:pic_order_cnt_type=0的时候poc与frame_num没有直接的关系,是显式地出现在bit流中为 pic_order_cnt_lsb,pic_order_cnt_lsb只是一个低位的poc,对应的高位PicOrderCntMsb不出现在bit 流中,这个需要编码器或者解码器对pic_order_cnt_lsb的情况来进行PicOrderCntMsb的进位。其中 MaxPicOrderCntLsb在SPS中可以得到,用于控制进位的。假定 MaxPicOrderCntLsb=64,prevPicOrderCntMsb=0有如下情况:

 IPB...未出现mmco==5IDR.....P   B   B   P   B    B    P    B   B        

                       062                        60  56  58  2  62    0    6    2   4   

                       062                        60  56  58  66 62    64   70   66  68   

这 里变量prevPicOrderCntLsb应该是以前参考帧的pic_order_cnt_lsb,

对于pic_order_cnt_lsb=2的P, 现在来计算它的poc, 此时prevPicOrderCntLsb=60,很明显满足条件prevPicOrderCntLsb>pic_order_cnt_lsb& amp;&(prevPicOrderCntLsb-pic_order_cnt_lsb)>=64/2,

由于是参考帧所以其 prevPicOrderCntMsb=prevPicOrderCntMsb+64=64,此时TopFiledOrderCnt=64+2=66;

接 着计算pic_order_cnt_lsb=62的B此时prevPicOrderCntMsb=64,而prevPicOrderCntLsb=2,

很 明显满足prevPicOrderCntLsb<pic_order_cnt_lsb&&(pic_order_cnt_lsb- prevPicOrderCntLsb)>=64/2,

此时PicOrderCntMsb=prevPicOrderCntMsb- prevPicOrderCntLsb=64-2=62。

由于不是参考帧所以prevPicOrderCntMsb还是保持为64,很明显 prevPicOrderCntMsb应该是MaxPicOrderCntLsb的倍数。对于pic_order_cnt_lsb=0的B,上述两种情况 都不满足,所以其PicOrderCntMsb=64。prevPicOrderCntMsb和prevPicOrderCntLsb在IDR或者 mmco=5的时候选择性复位。

这里如果考虑要场编码,则有如下情况:                              

IPB...mmco==5IDR.Pt  Pb   Bt   Bb  Bt   Bb   Pt   Pb  Bt   Bb   Bt   Bb        

062              60  61   56   57  58   59   2    3   62   63   0     1 062              60       56       58        66       62       64   

Pt 的poc为60的时候包含了mmco=5,由于他不是一个底场,所以prevPicOrderCntLsb就为60,如果出现在Pt的poc为61的时候 包含了mmco=5,则prevPicOrderCntLsb=0;所以在帧编码的时候mmco=5只是复位prevPicOrderCntMsb,而 prevPicOrderCntLsb应该不复位。而在场编码的时候mmco=5只有出现在底场的时候复位 prevPicOrderCntMsb,prevPicOrderCntLsb为0。保证prevPicOrderCntLsb初始是从顶场开始,且为偶 数开始(应该不是简单如此吧,应该还有深入原因,那位想通透的告诉我一声)pic_order_cnt_type=1的时候考虑如下序列情况SPS中设置 对于帧编码,offset_for_top_to_bottom_field=0;对于场编码 offset_for_top_to_bottom_field=1;

序列1:                         I      P       B   

循环一frame_num:    0      1       2      

poc:                               0      4       2                                                

                                        P       B   

循环二frame_num:     2       3      

poc:                               8       6                                               

                                               P       B  

 循环三frame_num:           3       4      

poc:                                     12       10

此 时对于

 num_ref_frames_in_pic_order_cnt_cycle=1,num_ref_frames_in_pic_order_cnt_cycle 

表示IDR后一个循环内参考帧的总数.

offset_for_ref_frame[0]=4,offset_for_ref_frame表示IDR后参考 帧之间的偏移。

如果要计算poc=12的P帧的POC,如何得到呢?首先已经知道

 frame_num=3,

num_ref_frames_in_pic_order_cnt_cycle=1,

offset_for_ref_frame[0]=4,

 则可以得到

absFrameNum=3,

picOrderCntCycleCnt =(3-1)/1=2;

frameNumInPicOrderCntCycle=(3-1)%1=0;

expectedDeltaPerPicOrderCntCycle = 0

for( i = 0; i < num_ref_frames_in_pic_order_cnt_cycle; i++ )

expectedDeltaPerPicOrderCntCycle += offset_for_ref_frame[ i ]

则expectedDeltaPerPicOrderCntCycle =4;

expectedPicOrderCnt = picOrderCntCycleCnt * expectedDeltaPerPicOrderCntCycle

for( i = 0; i <= frameNumInPicOrderCntCycle; i++ )

expectedPicOrderCnt = expectedPicOrderCnt + offset_for_ref_frame[ i ]

则expectedPicOrderCnt =12;

可以得到由于是P-slice,

此时slice header中

delta_pic_order_cnt[ 0 ]=0;delta_pic_order_cnt[ 1 ]=0;TopFieldOrderCnt = 12;BottomFieldOrderCnt = 12;

序列2:                           I      P       B     B      

循环一frame_num:     0      1       2     2 

poc:                                0      6       2     4                                               

                                               P       B     B      

循环二frame_num:           2       3     3     

poc:                                    12      8     10                        

                                              P       B     B     

 循环三frame_num:          3       4     4 

poc:                                    18      14    16

此 时对于num_ref_frames_in_pic_order_cnt_cycle=1,offset_for_ref_frame[0]=6。如果要 计算poc=16的B帧的POC,如何得到呢?首先已经知道 frame_num=4,num_ref_frames_in_pic_order_cnt_cycle=1,offset_for_ref_frame[0]=6, 则可以得到absFrameNum=4-1(因为是B帧不用于参考),picOrderCntCycleCnt =(3-1)/1=2;frameNumInPicOrderCntCycle=(3-1)%1=0;expectedDeltaPerPicOrderCntCycle =6;由于offset_for_non_ref_pic=-2*(连续B帧的数量);这里应该是-4expectedPicOrderCnt =14;可以得到,此时slice_header中delta_pic_order_cnt[ 0 ]=2,delta_pic_order_cnt[ 1 ]=0;TopFieldOrderCnt = 16;BottomFieldOrderCnt = 16;

序列3:                             I       P       B      P     B    B    P    B   B   B     

 循环一frame_num:       0      1       2     2       3    3    3    4   4   4

                 poc:                 0      4       2     10      6    8    18   12  14 16

 

                                             P       B     P     B    B    P    B   B   B    

  循环二frame_num:        4       5     5     6    6    6    7   7   7     

                 poc:                  22     20    28    24    26   36  30   32   34  

                                             P       B     P     B    B    P    B   B   B      

         循环三frame_num: 7       8     8     9    9    9   10   10  10

                 poc:                   40      38   46    42   44   54    48   50  52

此 时对于num_ref_frames_in_pic_order_cnt_cycle=3,offset_for_ref_frame[3]= {4,6,8}。

如果要计算poc=54的P帧的POC,如何得到呢?

首先已经知道

 frame_num=9,

num_ref_frames_in_pic_order_cnt_cycle=3,

offset_for_ref_frame[3]= {4,6,8}

,则可以得到absFrameNum=9,picOrderCntCycleCnt =(9-1)/3=2;frameNumInPicOrderCntCycle=(9-1)%3=2;

expectedDeltaPerPicOrderCntCycle =18;

expectedPicOrderCnt =18*2+4+6+8=54;

可以得到,此时slice_header中delta_pic_order_cnt[ 0 ]=0,delta_pic_order_cnt[ 1 ]=0;TopFieldOrderCnt = 54;BottomFieldOrderCnt = 54;

如果要计算poc=50的B帧的POC,如何得到呢?

由于是B帧absFrameNum=10-1=9,picOrderCntCycleCnt =(9-1)/3=2;frameNumInPicOrderCntCycle=(9-1)%3=2;由于连续B帧数目是变化的取平均值为2,此时 offset_for_non_ref_pic=-4,expectedPicOrderCnt =18*2+4+6+8-4=50;此时slice_header中delta_pic_order_cnt[ 0 ]=0,delta_pic_order_cnt[ 1 ]=0;pic_order_cnt_type=2的时候poc是由frame_num推导出来的,这个比较简单,但是应该注意,在这种情况下不存在连续 的非参考图象(注释),且解码输出的顺序和显示输出顺序一致(注释),意思就是说不出现B帧,但可以出现非参考的P场,这也是为什么当 nal_ref_idc=0的时候tempPicOrderCnt = 2 * ( FrameNumOffset + frame_num ) – 1的情况。这里保证了参考场的POC始终为偶数,并且大于同帧的另外一个场。     

       综合三种poc的,类型2应该是最省bit的,因为直接从frame_num获得,但是序列方式限制最大;类型1,只需要一定的bit量在sps标志出一 些信息还在slice header中表示poc的变化,但是比类型0要节省bit,但是其序列并不是随意的,要周期变化;对于类型0因为要对poc的 lsb进行编码所以用到的bit最多,优点是序列可以随意。

注意,H264码流的输出顺序是编码顺序,所以在编码B帧的时候,由 于B是双向预测,需要先编码后面编码帧P/I,这时候先输出I/P,后面才有B帧,我们在解码段拿到相应的I/P帧后,不能马上丢到buffer list里面,还需要等待后面的B帧,解码B帧后再reorder.所以相应产生了两个参数。poc,frame_num,这两个元素在slice级输出

 POC,和frame_num的概念:
 POC picture order count,是一个顺序计数器,代表显示顺序,假如是场编码,那么分别要对两场都有不同的值,比如对第一帧的两场top,bottom分别为0,1,所有的帧都包括在里面,包括B帧也需要计数,比如序列IPBPB,假如是帧编码,那么序号分别为0,4,2,8,6,顶底两场分别为0,0,4,4,2,2,8,8,6,6实际上这个并不输出到码流里面,假如是场变码那么是0,1,4,5,2,3,8,9,6,7
frame_num ,是一个顺序计数器,代表帧的编码顺序,由于代表帧,计数器递增基数为2,所以总是偶数,
比如序列IPBPB如果是帧编码,那么0,2,4,6,如果是场编码,那么是0,0,2,2,4,4,4,4,6,6
第一帧I不管top,bottom,都是0,第二帧P,top,bottom都是2,第3帧B,4,第四P也是4,第五B是6
注意B帧不能算编码帧,所以B slice中的frame_num只能等于后向参考帧的frame_num,注意当frame_num达到设定的最大值的时候,
frame_num,将重新归0,POC一般是分为两部分,一部分为高位,一部分为低位,上面说的都是低位pic_order_cnt_lsb,
当pic_order_cnt_lsb达到最大值的时候,将向高位Pic_Order_Cnt_Msb进位,高位加上低位才是该场的POC.
在JM中由几个变量类型是int64,为什么可能会有如此的大数,看函数set_ref_pic_num,由于POC是一个一直递增的数值。
有时候list缓冲里面this_ref如果是帧编码
    enc_picture->top_ref_pic_num    [LIST_0][i] = this_ref->top_poc * 2;
    enc_picture->bottom_ref_pic_num [LIST_0][i] = this_ref->bottom_poc * 2 + 1;
那么top_poc将会等于bottom_poc,为了区分着两个值,因此我们做了扩展,但是这可能导致溢出,所以定义成64位的大数
这些变量似乎是在去块滤波里面有用到,用来计算滤波强度。关于去块滤波的问题,留着下次解决,需要先熟息标准,才能
看源代码....H.264的知识面太宽了,越来越感到它的无边了,作为压缩效率最高,图像质量最好,当然当今最复杂的动态图像压缩标准,
JVT工作组从开始着手准备,到现在通过ISO/ITU标准,也不过短短几年时间.
我觉得一天两天,一个月两个月拿下,那是不可能的事情,至今5个月了,我希望自己越来越接近目标,

  • 1
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值