POC,和frame_num的概念(转)

注意，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个月了，我希望自己越来越接近目标,