zoukankan      html  css  js  c++  java
  • (转)I 帧和 IDR 帧的区别

    帧和 IDR 帧的区别:http://blog.csdn.net/skygray/article/details/6223358

        IDR 帧属于 I 帧。解码器收到 IDR frame  时,将所有的参考帧队列丢弃 (用x264_reference_reset 函数实现——在 encoder.c 文件中) 。这点是所有 I 帧共有的特性,但是收到IDR 帧时,解码器另外需要做的工作就是:把所有的 PPS 和 SPS 参数进行更新。由此可见,在编码器端,每发一个 IDR ,就相应地发一个  PPS&SPS_nal_unit

         这是网上搜索到的一个答案,有一定参考价值吧。

    先说明:所有的 IDR 帧都是 I 帧,但是并不是所有 I 帧都是 IDR 帧。就是说, IDR 帧是 I 帧的子集。 (我们程序中设定的是每250帧出现一个 IDR 帧)

    我们用的程序是这样的:

          /* ------------------- Setup frame context ----------------------------- */

         /* 5: Init da ta dependant of frame type */

         if ( h->fenc->i_type ==  X264_TYPE_IDR  )

         {

              /* reset ref pictures */

               x264_reference_reset ( h );

             i_nal_type      =  NAL_SLICE_IDR ;

             i_nal_ref_idc = NAL_PRIORITY_ HIGHEST ;

             i_slice_type = SLICE_TYPE_ ;

         }

          else if ( h->fenc->i_type ==  X264_TYPE_I  )

         {

             i_nal_type      =  NAL_SLICE ;

             i_nal_ref_idc = NAL_PRIORITY_ HIGH ;  /* Not completely true but for now it is (as all I/P are kept as ref)*/

             i_slice_type = SLICE_TYPE_ ;

         }

         else if ( h->fenc->i_type ==  X264_TYPE_P  )

         {

             i_nal_type      = NAL_SLICE;

             i_nal_ref_idc = NAL_PRIORITY_HIGH;  /* Not completely true but for now it is (as all I/P are kept as ref)*/

             i_slice_type = SLICE_TYPE_P;

         }

         else if ( h->fenc->i_type ==  X264_TYPE_BREF  )

         {

             i_nal_type      = NAL_SLICE;

             i_nal_ref_idc = NAL_PRIORITY_HIGH;  /* maybe add MMCO to forget it? -> low */

             i_slice_type = SLICE_TYPE_B;

         }

         else       /*  B  frame */

         {

             i_nal_type      = NAL_SLICE;

             i_nal_ref_idc = NAL_PRIORITY_DISPOSABLE;

             i_slice_type = SLICE_TYPE_B;

    }

        x264_reference_reset 函数的定义如下: (其实,因为这个代码是通用的,所以应该是参考帧队列。但是,我们只用一个参考帧,“队列”并没有意义。)

    static inline void  x264_reference_reset( x264_t *h )

    {

         int i;

         /* reset ref pictures */

         for ( i = 1; i < h->frames.i_max_dpb; i++ )

         {

             h->frames.reference[i]->i_poc = -1;

         }

         h->frames.reference[0]->i_poc = 0;

    }

         看来,好像是遇到 IDR 帧时才会 将所有的参考帧队列丢弃( x264_reference_reset ( h ); ) 。其实,我们的程序默认只用一个参考帧,这个问题就不是十分有意义了。

        多参考帧情况下。

        举个例子 :有如下帧序列: IPPPP PPP ……(我们程序没有 B 帧,所以帧序列简单些,但道理是一样的)。按照 3 个参考帧编码。

         因为“按照 3 个参考帧编码”,所以参考帧队列长度为 3 。

        遇到绿色的 时,并不清空参考帧队列,把这个 I 帧加入参考帧队列(当然 I 编码时不用参考帧。)。再检测到红色的 帧时,用到的就是 PPI 三帧做参考了。

         不怕自己罗嗦(好记性不如烂笔头),再强调一个: 一个参考帧,就是参考当前帧的前面的那帧(因为没涉及到 B 帧,所以“前面的那帧”既是播放顺序的,也是编码顺序的)。多个参考帧是一个道理 。 ( 我以前一直误解为从前面的几帧中找到最合适的一个参考帧)

         最后,“ 但是收到 IDR 帧时,解码器另外需要做的工作就是:把所有的 PPS 和 SPS 参数进行更新。由此可见,在编码器端,每发一个 IDR ,就相应地发一个  PPS&SPS_nal_unit ”应该是对的吧。先这样认为:)

    偶然机会,查到: IDR-instantaneous decoding refresh (IDR)picture 
          A coded picture in which all slices are I or SI slices that causes the decoding process to mark all reference pictures as "unused for reference" immediately after decoding the IDR picture. After the decoding of an IDR picture all following coded pictures in decoding order can be decoded without inter prediction from any picture decoded prior to the IDR picture. The first picture of each coded video sequence is an IDR picture. 

         “也就是说 ,IDR 的出现其实是相当于向解码器发出了一个清理 reference buffer 的信号吧,上面说前于这一帧的所有已编码帧不能为 inter 做参考帧了。”  

    还有:“ 因为 264 采用了多帧预测,就有可能在 display order 下 I 帧后的 P 会参考 I 帧前的帧,这样在 random access 时如果只找 I 帧,随后的帧的参考帧可能 unavailable , IDR 就是这样一种特殊的I 帧,把它定义为确保后面的 P 一定不参考其前面的帧,可以放心地 random access 。

  • 相关阅读:
    Java中NIO和IO区别和适用场景
    JDK和CGLIB动态代理原理
    java中的Serializable接口的作用
    redis采用序列化方案存对象
    在时间复杂度为O(n)且空间复杂度为O(1)的情况下翻转链表
    给定一个排好序的数组,然后求出丢失的数字
    求字符串里超过字符长度一半的元素
    求你给定两字符串包含的字母数是否完全一致
    动态规划,求数组不相邻数字的最大子串值
    JWT 工具
  • 原文地址:https://www.cnblogs.com/lihaiping/p/4167930.html
Copyright © 2011-2022 走看看