0
开发接近尾声,困扰了很长时间得一个问题,竟然是自己得失误,很惭愧,本来早几天就可以交公得,由于自己得误解,导致要推迟几天了,不过还好,总算要差不多结束了!
下面是Delphi得代码
下面是初始化得一些信息
解压函数翻译说明:
ICDecompress
函数ICDecompress解压一个单独视频帧数据
参数如下:
hic
前面已经获得得解压得句柄
dwFlags
Applicable decompression flags. The following values are defined.
应用解压参数,可以选择下面的参数
Value Meaning
ICDECOMPRESS_HURRYUP
试着使用一个快速得压缩速率,当应用程序使用这个参数,驱动器应该缓冲待解压缩得数据但是不画出图象
ICDECOMPRESS_NOTKEYFRAME
当前帧不是关键帧
ICDECOMPRESS_NULLFRAME
当前帧没有数据,缓冲区继续使用前面得数据
ICDECOMPRESS_PREROLL Current frame precedes the point in the movie where playback starts and, therefore, will not be drawn.
ICDECOMPRESS_UPDATE
正在刷新屏幕
lpbiFormat
指向 BITMAPINFO结构得指针,包含了压缩数据得格式
lpData
包含了输入数据
lpbi
指向BITMAPINFO结构得指针,包含了输出数据得格式
lpBits
一个足够大得缓冲区包含了被解压缩得数据
Return Values
返回值,如果返回ICERR_OK表示成功,否则失败
另外由于我采用了多线程得解压方法,所以考虑到解码器得多线程处理得问题:
开发得最后关键代码我下面得帖子回写出来,这个帖子对开发过程会很有帮助,是我翻看了很多资料,并从中总结出来得,希望对大家有帮助!
引用
你的这段代码我了解了,其实你只需要把pDIB拷到biEncIn的相应位置就可以了,我这里没有装MSDN,
不过biEncIn应该是bitmapinfo的机构把,所以你在这个结构中,把相应数据的地址赋进去就可以了。
关键你要把StretchDIBits这个函数要搞清楚。其实你这样做最好了,生成一个bitmapinfo指针,
内存预先计算好,根据宽度高度和调色板,然后把你现在的biEncIn拷到相应位置,然后令地址偏移到相应位置,
在令其等于pDIB就可以了。
现在可以了么?
to wqyuwss()兄:
BITMAPINFO biEncIn,biEncOut;
现在我的情况是这样的,StretchDIBits出来的全部是花花的色快,
根本不是我捕获的画象,因为我还不知道是编码部分还是解码部分使用不对,或者其它什么地方的。
DivX根CPU、主芯片有关吗?
如果你定义是ICCOMPRESS icd的话,请定义为ICDECOMPRESS icd;
to mzm100()、wqyuwss()、chenm001(CM):
我的一些参数定义如下:
BITMAPINFO biEncIn,biEncOut;
ICCOMPRESS icc;
ICDECOMPRESS icd;
BYTE *pDIBBuf,*pEncBuf,*pDecBuf;
nVideoW=352; nVideoH=288;
我现在的情况是刷新出来的图象全是花花的色快,如果是编码没有问题,那么解码部分有问题吗?刷新部分呢?
不过biEncIn应该是bitmapinfo的机构把,所以你在这个结构中,把相应数据的地址赋进去就可以了。
关键你要把StretchDIBits这个函数要搞清楚。其实你这样做最好了,生成一个bitmapinfo指针,
内存预先计算好,根据宽度高度和调色板,然后把你现在的biEncIn拷到相应位置,然后令地址偏移到相应位置,
在令其等于pDIB就可以了。
现在可以了么?
to wqyuwss()兄:
BITMAPINFO biEncIn,biEncOut;
现在我的情况是这样的,StretchDIBits出来的全部是花花的色快,
根本不是我捕获的画象,因为我还不知道是编码部分还是解码部分使用不对,或者其它什么地方的。
DivX根CPU、主芯片有关吗?
如果你定义是ICCOMPRESS icd的话,请定义为ICDECOMPRESS icd;
to mzm100()、wqyuwss()、chenm001(CM):
我的一些参数定义如下:
BITMAPINFO biEncIn,biEncOut;
ICCOMPRESS icc;
ICDECOMPRESS icd;
BYTE *pDIBBuf,*pEncBuf,*pDecBuf;
nVideoW=352; nVideoH=288;
我现在的情况是刷新出来的图象全是花花的色快,如果是编码没有问题,那么解码部分有问题吗?刷新部分呢?
下面是Delphi得代码
下面是初始化得一些信息
解压函数翻译说明:
ICDecompress
函数ICDecompress解压一个单独视频帧数据
引用
DWORD ICDecompress(
HIC hic,
DWORD dwFlags,
LPBITMAPINFOHEADER lpbiFormat,
LPVOID lpData,
LPBITMAPINFOHEADER lpbi,
LPVOID lpBits
);
HIC hic,
DWORD dwFlags,
LPBITMAPINFOHEADER lpbiFormat,
LPVOID lpData,
LPBITMAPINFOHEADER lpbi,
LPVOID lpBits
);
参数如下:
hic
前面已经获得得解压得句柄
dwFlags
Applicable decompression flags. The following values are defined.
应用解压参数,可以选择下面的参数
Value Meaning
ICDECOMPRESS_HURRYUP
试着使用一个快速得压缩速率,当应用程序使用这个参数,驱动器应该缓冲待解压缩得数据但是不画出图象
ICDECOMPRESS_NOTKEYFRAME
当前帧不是关键帧
ICDECOMPRESS_NULLFRAME
当前帧没有数据,缓冲区继续使用前面得数据
ICDECOMPRESS_PREROLL Current frame precedes the point in the movie where playback starts and, therefore, will not be drawn.
ICDECOMPRESS_UPDATE
正在刷新屏幕
lpbiFormat
指向 BITMAPINFO结构得指针,包含了压缩数据得格式
lpData
包含了输入数据
lpbi
指向BITMAPINFO结构得指针,包含了输出数据得格式
lpBits
一个足够大得缓冲区包含了被解压缩得数据
Return Values
返回值,如果返回ICERR_OK表示成功,否则失败
另外由于我采用了多线程得解压方法,所以考虑到解码器得多线程处理得问题:
引用
vcforever(累):
多线程能否同时调用ICDecompress函数进行解压?
可以!这个问题就像多个线程共用一个线程函数一样!
我做的视频解压,接收多路。第一路解压时完全可以,成功的进行了传输,
但当第二路调用此函数时,反回却不等于ICERR_OK?第二次调用此函数时的数据和第一次一样
你能否给我举个例子,在此先谢了
如果这个函数中用到了共享资源,那么最好同步一下!
jiangsheng(蒋晟.Net[MVP])
ICDecompress是调用Fourc对应的DLL中的函数来完成工作,
所以这个问题和编码器有关。但是编码器未必是线程安全的,所以你还是不要这么作为好。
多线程能否同时调用ICDecompress函数进行解压?
可以!这个问题就像多个线程共用一个线程函数一样!
我做的视频解压,接收多路。第一路解压时完全可以,成功的进行了传输,
但当第二路调用此函数时,反回却不等于ICERR_OK?第二次调用此函数时的数据和第一次一样
你能否给我举个例子,在此先谢了
如果这个函数中用到了共享资源,那么最好同步一下!
jiangsheng(蒋晟.Net[MVP])
ICDecompress是调用Fourc对应的DLL中的函数来完成工作,
所以这个问题和编码器有关。但是编码器未必是线程安全的,所以你还是不要这么作为好。
开发得最后关键代码我下面得帖子回写出来,这个帖子对开发过程会很有帮助,是我翻看了很多资料,并从中总结出来得,希望对大家有帮助!
JRTPLib下载以及代码参考!
Reverse-engineering MSN Messenger's Video Conversation Formats[Ramiro Polla]


2007/03/24
15:58
4221



