H263关于ICSeqCompressFrame、ICDecompress的变态问题，和我的变态解决方法。无语了。。。来者有分！

[clovefjp]

LPVOID ICSeqCompressFrame(
PCOMPVARS pc,
UINT uiFlags,
LPVOID lpBits,
BOOL * pfKey,
LONG * plSize
);
DWORD ICDecompress(
HIC hic,
DWORD dwFlags,
LPBITMAPINFOHEADER lpbiFormat,
LPVOID lpData,
LPBITMAPINFOHEADER lpbi,
LPVOID lpBits
);
MSDN上解释ICSeqCompressFrame的plSize参数返回后的数据是编码后的数据大小，编码后，我按plSize的大小拷贝保存到编码数据EN_DATA里，但在ICDecompress的时候把编码数据传入时差不多有30%的几率总是会出现ICDecompress函数访问EN_DATA越界的情况，我真TMD的郁闷，连续搞了好几天，突然想到一个办法，既然它会访问越界那我干脆把传入的数据空间扩大，准备了一个char temp[8192]（原始图象大小为176*144*(24/3)编码后的数据最大的也只有4K左右，大部分都很小，但也得要有8192的空间才不会发生越界的情况。）,在每次编码前把EN_DATA数据拷进去，然后再把temp传进ICDecompress，就这样世界一片清净。。。

虽然暂时把问题解决了，但这就象是个不定时的炸弹，不知道什么时候又会发作，实在另人心慌。所以想请教一下，这到底是什么原因？？？同时我有几个疑问：
一：ICSeqCompressFrame后的数据里面有没有包含类似数据终止标识？
二：plSize返回的是精确的数据长度么？如果不是的话，有没有精确计算出编码后数据大小的方法？
三：如果编码数据里没有终止标识的话，ICDecompress如何才能防止访问越界？
四：COMPVARS里面有几个成员变量看MSDN后感觉也还不是很明白，有谁能详细的解释一下各变量的意思？

下面的是我用的代码。
bool CCodecMgr::CodecVInit()
{
m_hIC=NULL;

ZeroMemory(&m_cv,sizeof(m_cv));
m_cv.cbSize = sizeof(m_cv);
m_cv.dwFlags = ICMF_COMPVARS_VALID ;
m_cv.hic = m_hIC;
m_cv.fccType = ICTYPE_VIDEO ;
m_cv.fccHandler = 859189837;
m_cv.lpbiOut = 0;
m_cv.lKey = 10;
m_cv.lDataRate = 6;
m_cv.lQ = ICQUALITY_HIGH;

ZeroMemory(&m_BmpU,sizeof(m_BmpU));
m_BmpU.bmiHeader.biSize = sizeof(BITMAPINFOHEADER);
m_BmpU.bmiHeader.biWidth = 176;
m_BmpU.bmiHeader.biHeight = 144;
m_BmpU.bmiHeader.biPlanes = 1;
m_BmpU.bmiHeader.biBitCount = 24;
m_BmpU.bmiHeader.biSizeImage = 76032;


m_hIC=ICOpen(ICTYPE_VIDEO,m_cv.fccHandler,ICMODE_COMPRESS|ICMODE_DECOMPRESS);
if(!m_hIC)
{
CodecVDestroy();
return false;
}

ICCompressGetFormat(m_hIC,&m_BmpU,&m_BmpC);
ICSendMessage(m_hIC,0x60c9,0xf7329ace,0xacdeaea2);

m_cv.hic = m_hIC;
m_cv.dwFlags = ICMF_COMPVARS_VALID;

if(!ICSeqCompressFrameStart(&m_cv,&m_BmpU))
{
CodecVDestroy();
return false;
}
if(ICDecompressBegin(m_hIC,&m_BmpC,&m_BmpU)!=ICERR_OK)
{
CodecVDestroy();
return false;
}
return true;
}

char* CCodecMgr::EncodeVideoData(char* pin, int* lenr)
{
BOOL bKey;
long Size = 0;
char* pResult = NULL;
char* pTemp = NULL;

if(!pin || !m_hIC )
return NULL;
if((pTemp = (char*)ICSeqCompressFrame(&m_cv, 0, pin, &bKey, &Size)) == NULL)
return NULL;

if(lenr) *lenr = Size;

pResult = new char[Size];
CopyMemory(pResult, pTemp, Size);
return pResult;
}

bool CCodecMgr::DecodeVideoData(char *pin, char* pout)
{
if(!pin || !pout || !m_hIC)
return false;

if(ICDecompress(m_hIC, 0, &m_BmpC.bmiHeader, pin, &m_BmpU.bmiHeader, pout) != ICERR_OK)
return false;
return true;
}

[legendhui]

xx

[clovefjp]

晕，一看有两个回复，心里偷笑，没想到一进来竟然是这样的东东。。。。

[xqk]

up

[sodangerous]

你问的问题有点困难，我提点建议，1、有的时候LONG 与 int之间转化会出现这个问题，2、考虑动态分配大小

[NOMADBLUE]

嗯

[NOMADBLUE]

要注意一下类型

[clovefjp]

to sodangerous(机器人)
1、有的时候LONG 与 int之间转化会出现这个问题，
分配空间的时候没有类型转换，直接就是plSize的值赋进去的。
2、考虑动态分配大小
至于动态大小都是有经过计算得出，应该也不会出现这样的问题。

哪位有做过H263编码的。。。天哪

[clovefjp]

分不是问题啊。。。。。。。。。。。

[haode]

晕了

[clovefjp]

等待高手出现。

[jerrywh]

接分
接分
接分
接分

[DentistryDoctor]

DivX

[clovefjp]

楼上的兄弟，说详细点OK？