流媒体相关

int Pcm16_2_Mp3()

玻璃小屋 — Fri, 22 Jan 2010 10:23:00 GMT

int Pcm16_2_Mp3()
{
int     iRet = 0;
int     i  = 0;
lame_global_flags* gf  = NULL;

    unsigned char  mp3buffer[LAME_MAXMP3BUFFER];
    int     Buffer[2][1152];
    int     iread = 0, imp3;

if (NULL == (gf = lame_init())) {
return 1;
}

/* turn off automatic writing of ID3 tag data into mp3 stream
* we have to call it before 'lame_init_params', because that
* function would spit out ID3v2 tag data.
*/
lame_set_write_id3tag_automatic(gf, 0);
lame_set_in_samplerate(gf,8000);   // 8kHz
lame_set_num_channels(gf,1);    // Mono
//gf->pcmbitwidth     = 8;
//gf->pcm_is_unsigned_8bit  = 1;

/* Now that all the options are set, lame needs to analyze them and
* set some more internal options and check for problems
*/
i = lame_init_params(gf);

/* encode */
imp3 = lame_encode_buffer_int(gf, Buffer[0], Buffer[1], iread,mp3buffer, sizeof(mp3buffer));

/* was our output buffer big enough? */
if (imp3 < 0) {
  if (imp3 == -1)
   assert(0);
  else
   assert(0);
  return 1;
}

imp3 = lame_encode_flush(gf, mp3buffer, sizeof(mp3buffer)); /* may return one more mp3 frame */

if (imp3 < 0) {
  if (imp3 == -1)
   assert(0);
  else
   assert(0);
  return 1;

}

return iRet;
}

speex压缩之后就不用再使用LZW压缩了。。

玻璃小屋 — Mon, 28 Dec 2009 06:11:00 GMT

测试了一下，speex压缩之后，用lzw也起不到压缩效果了。。speex算法中已经包含了类似于 lzw的算法了？

(zt) speex带宽占用~

玻璃小屋 — Mon, 28 Dec 2009 05:27:00 GMT

Speex Actual Bandwidth Calculation

We have finally almost finished Speex coding on AR1688 DSP. This open source voice codec turned out to be much more complicated than we expected. There are 8 different bitrate with 8k sampling, from 2.15kpbs to 24.6kpbs. I am writing this article to answer a question of how much bandwidth this codec actually use during a call.

Let us calculate based on 802.3 ethernet, using SIP protocol:

Ethernet CRC: 4 bytes

MAC header: 14 bytes

IP header: 20 bytes

UDP header: 8 bytes

RTP header: 12 bytes

Speex data: x bytes, x depends on bitrate used and number of frames packed in an ethernet packet ("Voice Frames per TX" option in AR1688)

Total: (58 + x) bytes

Speex uses 20ms as a frame, the size of compressed data in a frame with different bitrate are:

2.15kbps: 6 bytes

3.95kbps: 10 bytes

5.95kbps: 15 bytes

8kbps: 20 bytes

11kbps: 28 bytes

15kbps: 38 bytes

18.2kbps: 46 bytes

24.6kbps: 62 bytes

When only 1 frame is included in an ethernet frame, the actually used bandwidth are:

2.15k: 25.6k

3.95k: 27.2k

5.95k: 29.2k

8k: 31.2k

11k: 34.4k

15k: 38.4k

18.2k: 41.6k

24.6k: 48k

When 2 frames are included in an ethernet frame, the actually used bandwidth are:

2.15k: 14k

3.95k: 15.6k

5.95k: 17.6k

8k: 19.6k

11k: 22.8k

15k: 26.8k

18.2k: 30k

24.6k: 36.4k

When 3 frames are included in an ethernet frame, the actually used bandwidth are:

2.15k: 10.1k

3.95k: 11.7k

5.95k: 13.7k

8k: 15.7k

11k: 18.9k

15k: 22.9k

18.2k: 26.1k

24.6k: 32.5k

When 4 frames are included in an ethernet frame, the actually used bandwidth are:

2.15k: 8.2k

3.95k: 9.8k

5.95k: 11.8k

8k: 13.8k

11k: 17k

15k: 21k

18.2k: 24.2k

24.6k: 30.6k

为啥SpeeX也是把8kHz 8bit 的raw PCM数据转成 8kHz 16bit呢？？

玻璃小屋 — Wed, 23 Dec 2009 05:05:00 GMT

在 SpeeX的
/* Convert input audio bits, endians and channels */
static int read_samples(FILE *fin,int frame_size, int bits, int channels, int lsb, short * input, char *buff, spx_int32_t *size)

中有如下代码，目的是把   8kHz 8bit 的PCM数据转成 8kHz 16bit的PCM数据。好象mp3算法，g729算法，都没有直接转8kHz 8bit 的PCM数据的方法，都是转成 16bit，不知道为什么？转成 16bit的话，PCM数据不是多了一倍么？？对以后的压缩不会产生影响？？

if(bits==8)
   {
      /* Convert 8->16 bits */
      for(i=frame_size*channels-1;i>=0;i--)
      {
         s[i]=(in[i]<<8)^0x8000;
      }
   } else
   {
      /* convert to our endian format */
      for(i=0;i<frame_size*channels;i++)
      {
         if(lsb)
            s[i]=le_short(s[i]);
         else
            s[i]=be_short(s[i]);
      }
   }

枚举 CLSID_AudioCompressorCategory 时遇到中断错误！

玻璃小屋 — Wed, 16 Dec 2009 06:11:00 GMT

HRESULT GetACMFilterByName(wchar_t* pwcFilterName)
{
// Create the System Device Enumerator.
HRESULT hr;
ICreateDevEnum *pSysDevEnum = NULL;
JIF(CoCreateInstance(CLSID_SystemDeviceEnum, NULL, CLSCTX_INPROC_SERVER,IID_ICreateDevEnum, (void **)&pSysDevEnum));

// Obtain a class enumerator for the video compressor category.
IEnumMoniker *pEnumCat = NULL;

// 如果应用程序以调试模式启动的话，下面这句会错误中断。。如果直接运行，不启动调试，就可以正常不知道为什么。。。没办法了。。只有后面加一句 assert(0); 然后直接运行。。到assert(0);时用重试进入调试模式。。。
JIF(pSysDevEnum->CreateClassEnumerator(CLSID_AudioCompressorCategory, &pEnumCat, 0));

assert(0);

IPropertyBag* pPropBag;
IMoniker*  pMoniker = NULL;
ULONG   cFetched;
VARIANT   varName;
IBaseFilter* pFilter;
LRESULT   lrId;

while(pEnumCat->Next(1, &pMoniker, &cFetched) == S_OK)
{
  hr = pMoniker->BindToStorage(0, 0, IID_IPropertyBag, (void **)&pPropBag);
  if (SUCCEEDED(hr))
  {
   VariantInit(&varName);
   hr = pPropBag->Read(L"FriendlyName", &varName, 0);
   if (SUCCEEDED(hr))
   {
    hr = pMoniker->BindToObject(NULL, NULL, IID_IBaseFilter,(void**)&pFilter);
    {
     assert(pFilter != 0);
     //EnumSoundInputPinToCommbo(pFilter,varName.bstrVal,IDC_COMBO_SOUND);
    }

    //if(SupportsPropertyPage(pFilter))
    //{
    // hr = ShowFilterPropertyPage(pFilter,hDlg);
    //}
   }
   VariantClear(&varName);

   SAFE_RELEASE(pPropBag);
  }
  SAFE_RELEASE(pMoniker);
}

SAFE_RELEASE(pEnumCat);
SAFE_RELEASE(pSysDevEnum);
}

异常时的堆栈信息：

> ntdll.dll!_DbgBreakPoint@0()
  ntdll.dll!_RtlpBreakPointHeap@4() + 0x28 字节
  ntdll.dll!_RtlpValidateHeapEntry@12() + 0x514ef 字节
  ntdll.dll!_RtlDebugFreeHeap@12() + 0x97 字节
  ntdll.dll!_RtlFreeHeapSlowly@12() + 0x15340 字节
  ntdll.dll!_RtlFreeHeap@12() + 0x147b9 字节
  msms001.vwp!04947b68()
  [下面的框架可能不正确和/或缺失，没有为 msms001.vwp 加载符号]
  msms001.vwp!04932483()
  msms001.vwp!04947539()
  msms001.vwp!0493fcf7()
  vct3216.dll!048d4326()
  vct3216.dll!048d7102()
  vct3216.dll!048d4699()
  vct3216.dll!048c5b1e()
  vct3216.dll!048c4bb0()
  vct3216.dll!048c46d7()
  vct3216.dll!048ca646()
  vct3216.dll!048ca261()
  vct3216.acm!048a2e04()
  kernel32.dll!_IsProcessorFeaturePresent@4()

dshow用avi mux filter 和 file writer filter 写AVI文件的问题？难道是bug?

玻璃小屋 — Thu, 03 Dec 2009 01:30:00 GMT

这几天用自己写了个源filter，推rgb或是yv12数据给下级的filter。后来想把这些数据写到avi文件中，自然就想到了 avi mux filter + file writer filter来写了。但是遇到一个问题。但每秒帧数设置的大于等于3时，右键盘查看avi文件的属性显示的是正常的。但是当每秒帧数设置为2时，AVI文件属性确显示 14帧/秒，当设置为1时，属性显示7帧/秒，不过播放时，貌似是正常的，我的系统是win2003 sp2，后来在winxp sp2上试，也是这样(另外从暴风中查看属性帧数也不对，用一个叫做 avi mux GUI的软件查看，是正常的)。但是vista中是正常的(不管是系统的AVI文件属性，还是暴风的)。。奇怪死了。难道是系统计算属性时溢出了？？留带以后详细测试吧。。。这次凑合着用吧。

哎。。带preview的写2路文件的dshow录制filter 链...

玻璃小屋 — Fri, 27 Nov 2009 08:40:00 GMT

视频预览必须用smart tee分出的preview 脚。。用infinine tee filter的话。。。会停住。。。
http://blog.vckbase.com//images/vckbase_com/zaboli/352/o_graph_2file_1preview.GIF

RGB24转YV12(按公式转，没有任何优化)

玻璃小屋 — Thu, 12 Nov 2009 07:52:00 GMT

// 最直接的(没有任何优化，直接按公式转换！)把RGB24转成YV12的算法
// 参数：宽(w) 和高(h) 必须是 4对齐的！不然会有错误！
// 输出结果 YV12 格式：
// y01 y02 y03 y04 -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// v01 v02 -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -
// u01 u02 -   -   -   -   -   -   -   -   -   -
// -   -   -   -   -   -   -   -   -   -   -   -

typedef struct tagRGB24{
        unsigned char    b;
        unsigned char    g;
        unsigned char    r;
} RGB24;

void HotRGB24_2_YV12(unsigned char* yv12,unsigned char* rgb24,int w,int h)
{
    int iBufLen = w * h;
    int i,j,vay,vau,vav;
    unsigned char* cv;        // 当前坐标的v(current v);
    unsigned char* nv;        // 在cv下一行的对应位置的 v;
    unsigned char* cu;        // 当前坐标的u(current u);
    unsigned char* nu;        // 在cu下一行的对应位置的 u;
    unsigned char v01,v02,v11,v12,u01,u02,u11,u12;            // 需要整合的相邻的4个象素如下
    /*
    v01 v02 - - - -
    v11 v12 - - - -
    -   -   - - - -
    u01 u02
    u11 u12
    */
    unsigned char* vv = new unsigned char[iBufLen];            // 每个RGB单位对应的V!
    unsigned char* uu = new unsigned char[iBufLen];            // 每个RGB单位对应的U!

    // 按标准算法从RGB24计算出所有YUV

    RGB24 * pRGB = (RGB24*)rgb24;
    unsigned char* y = yv12;                                // 这里直接用 yuv 缓冲。。省了copy了。
    unsigned char* v = vv;
    unsigned char* u = uu;

    for(i = 0; i < h; i++)
    {
        for(j = 0; j < w; j++)
        {

            //Y =   0.299R + 0.587G + 0.114B
            //U =  -0.147R - 0.289G + 0.436B
            //V =   0.615R - 0.515G - 0.100B

            // 这个算法颜色不正啊。。
            //vay =  pRGB->r *  0.299 + pRGB->g *  0.587 + pRGB->b *  0.114;    // 根据公式计算出Y
            //vav =  pRGB->r *  0.615 + pRGB->g * -0.515 + pRGB->b * -0.100;    // 根据公式计算出V
            //vau =  pRGB->r * -0.147 + pRGB->g * -0.289 + pRGB->b *  0.436;    // 根据公式计算出U

            //Y = round( 0.256788 * R + 0.504129 * G + 0.097906 * B) +  16
            //U = round(-0.148223 * R - 0.290993 * G + 0.439216 * B) + 128
            //V = round( 0.439216 * R - 0.367788 * G - 0.071427 * B) + 128

            // 好象这个算法颜色正，而且是MSDN中列出的算法
            vay =  0.256788 * pRGB->r + 0.504129 * pRGB->g + 0.097906 * pRGB->b +  16;
            vau = -0.148223 * pRGB->r - 0.290993 * pRGB->g + 0.439216 * pRGB->b + 128;
            vav =  0.439216 * pRGB->r - 0.367788 * pRGB->g - 0.071427 * pRGB->b + 128;

            *y =  vay < 0 ? 0 : (vay > 255 ? 255: vay);                        // 如果Y小于0置换成0，如果Y大于255就置换成255
            *v =  vav < 0 ? 0 : (vav > 255 ? 255: vav);                        // 如果V小于0置换成0，如果V大于255就置换成255
            *u =  vau < 0 ? 0 : (vau > 255 ? 255: vau);                        // 如果U小于0置换成0，如果U大于255就置换成255

            y++;    // 移动到下一位！
            v++;
            u++;
            pRGB++;
        }
    }

    v = yv12 + iBufLen;                                // 记录成品YV12的V的位置
    u = v    + (iBufLen >> 2);                        // 记录成品YV12的U的位置

    for(i = 0; i < h; i+=2)                            // 由于 V 和 U 只记录隔行的，所以 += 2;
    {
        cv = vv + i * w;                            // 取得第i     行的v;
        nv = vv + (i + 1) * w;                        // 取得第i + 1 行的v

        cu = uu + i * w;                            // 取得第i     行的u;
        nu = uu + (i + 1) * w;                        // 取得第i + 1 行的u

        for(j = 0; j < w; j+=2)                        // 由于一躺循环我们访问两个 uu 或 vv 所以 += 2;
        {
            v01 = *(cv + j);                        // 取得第i     行的第j     个v的具体的值
            v02 = *(cv + j + 1);                    // 取得第i     行的第j + 1 个v的具体的值
            v11 = *(nv + j);                        // 取得第i + 1 行的第j     个v的具体的值
            v12 = *(nv + j + 1);                    // 取得第i + 1 行的第j + 1 个v的具体的值

            *v = (v01 + v02 + v11 + v12) / 4;        // 取v01,v02,v11,v12的平均值给v

            u01 = *(cu + j);                        // 取得第i     行的第j     个u的具体的值
            u02 = *(cu + j + 1);                    // 取得第i     行的第j + 1 个u的具体的值
            u11 = *(nu + j);                        // 取得第i + 1 行的第j     个u的具体的值
            u12 = *(nu + j + 1);                    // 取得第i + 1 行的第j + 1 个u的具体的值

            *u = (u01 + u02 + u11 + u12) / 4;        // 取u01,u02,u11,u12的平均值给u

            v++;    // 移动到下一位！
            u++;

        }
    }

    delete [] vv;
    delete [] uu;

}

RGB模式下，alpha原理公式(转贴)

玻璃小屋 — Mon, 09 Nov 2009 03:45:00 GMT

先简单说一下图像alpha的原理。在RGB模式下，alpha原理公式很简单:

displayColor = sourceColor × alpha / 255 + backgroundColor × (255 – alpha) / 255.

alaph取值范围是0-255.

那么，如果将此公式放在YV12下，又会如何呢？YV12是在一个平面中排列，先是Y, 然后是U, 后是V, 如下表述：Y的区域大小 = Width * Height, U的区域大小=Width/2 * Height/2, V的区域大小=Width/2*Height/2, 4个Y值共享一个U和V. 所以，如果我们将所有的YUV都通过alpha公式运算后，与 RGBF运算后的效果应该是相同的。试验结果会证明这点吗？看下图就知道了.

原贴：http://hi.baidu.com/zwshare/blog/item/97213bdc0d269cabcd116629.html

YV12和I420的区别(转)

玻璃小屋 — Thu, 05 Nov 2009 06:15:00 GMT

2007年12月15日星期六 22:39

一般来说，直接采集到的视频数据是RGB24的格式，RGB24一帧的大小size＝width×heigth×3 Bit，RGB32的size＝width×heigth×4，如果是I420（即YUV标准格式4：2：0）的数据量是 size＝width×heigth×1.5 Bit。

在采集到RGB24数据后，需要对这个格式的数据进行第一次压缩。即将图像的颜色空间由RGB2YUV。因为，X264在进行编码的时候需要标准的YUV（4：2：0）。但是这里需要注意的是，虽然YV12也是（4：2：0），但是YV12和I420的却是不同的，在存储空间上面有些区别。如下：

YV12 ：亮度（行×列）＋ U（行×列/4) + V（行×列/4）

I420 ：亮度（行×列）＋ V（行×列/4) + U（行×列/4）

可以看出，YV12和I420基本上是一样的，就是UV的顺序不同。

继续我们的话题，经过第一次数据压缩后RGB24－>YUV（I420）。这样，数据量将减少一半，为什么呢？呵呵，这个就太基础了，我就不多写了。同样，如果是RGB24－>YUV（YV12），也是减少一半。但是，虽然都是一半，如果是YV12的话效果就有很大损失。然后，经过X264编码后，数据量将大大减少。将编码后的数据打包，通过RTP实时传送。到达目的地后，将数据取出，进行解码。完成解码后，数据仍然是YUV格式的，所以，还需要一次转换，这样windows的驱动才可以处理，就是YUV2RGB24。