h.263视频编码标准学习笔记（一）

 

 

   很高兴，终于可以抽出时间来具体剖析263和264的源码了。这件事情一直想做，却一方面由于事情缠身，另一方面也犹豫自己偶尔的踌躇不定，拖到了今天。

   前几天花时间好好剖析了2维DCT算法，最快的Leoffler算法，只需XX次乘法，XX次加法。然后分别找到了3个版本的2维图像DCT源码，编程比较各自的时间消耗。最终发现，导师给的DEMO效率是最高的，这在一定程度上摧毁了我的一些信心，因为这样我在这个项目上能上升的空间就更小了。自己必须破釜沉舟，积极寻找新思路，开疆辟土。

一 学习DCT：

 

二 学习263源码：

   263源码帧内编码框图如下图所示：

 

   本项目暂时只做I帧编码，即只涉及帧内编码。（帧间编码框图在相应论文里面也可以找到。）

 

 

    今天主要进行了几个方向的改进，可以从软件更新版本上来分析：

test263_Oct12_10_35 最初的版本  PC平台上编码50帧QCIF,平均每帧耗时0.0128s
test263_Oct12_10_36 去除编码端重建帧模块  PC平台上编码50帧QCIF,平均每帧耗时0.00812s  相比最初版本速度提高1.57倍
test263_Oct12_10_42 在DCT中，DCT系数采用整型，计算采用移位策略。 PC平台上编码50帧QCIF,平均每帧耗时0.00688s  相比最初版本速度提高1.86倍
test263_Oct12_21_34 增加解码端写YUV模块，以便进行解码后的主观评测。

  今天遇到的主要问题有：

  1.263编码后所写的编码文件，每帧的“分界线”是字符串“000080”，由于每帧图片压缩率不一样，所以每个“分界线”之间的字符的多少是不定的（但是我发现它们都比第一帧的压缩数据大小略大一些，这个问题不知道为什么，明天向导师求疑）。于是，在解码端需要搜索这样一个字符串。所以自己编写了一段代码，来“分割”这些待解码的“帧”。

   这部分代码如下：

 

size_t frames=50;

  unsigned char *p=data+3;

  for(i=0;i<frames;i++)
  {
   
    printf("/ndecompressing frame...%d",i);
   
   // int ret=DecompressFrame(data+i*size,size,rgbdata,80000);
 int ret;
 {
  int psize=0;
  for(;;)
  {
   if(*p==0x00 && *(p+1)==0x00 && *(p+2)==0x80)
   {
    if(i==0)
     psize+=3;
    else
     psize+=1;
    //printf("psize=%d/n",psize);
    break;
   }
   else
   {
    ++p;
    ++psize;
   }
  }

  ret=DecompressFrame(p,psize,rgbdata,80000);
  ++p;
 }
   
    if(ret)
      printf("/n success");
    else
    {
      printf("/n failure");
      continue;
    }

｝

 

    最后，结果成功。缺憾就是：偶尔有几帧图片解码有极小部分的乱码。明天还要好好分析一下。

 

 

 

 

 

 

by jack_incredible