我写的基于DirectShow的摄像头应用程序（后称为FO程序）在AnnaYu的机器上居然运行出错，而在所有其它人的机器上都没有遇到这样的事情，这使我确信问题不应该在程序上。
AnnaYu调试后发现，问题出在这里：
memcpy(pCurrFrame,pBuffer,3*Height*Width);
这句话出现在下面这个函数中：
函数是DirectShow中的SampleGrabberCB提供的，作用是把让开发人员有机会修改得到每一帧并修改。参数中的pBuffer就是指向帧数据的指针而BufferSize则是帧的大小（按Byte记）。
而
memcpy(pCurrFrame,pBuffer,3*Height*Width);
的本意是将本帧数据copy至另一处内存以供别处使用。
现在AnnaYu调试后发现，3*Height*Width的大小正好和BufferSize是2:1的关系，而正常情况下，应该两者相等。
在RGB24的数据格式下，3*Height*Width的确应该和BufferSize相等，我开始怀疑是摄像头的数据格式设置错误，但是在初始化整个Graph时，我对数据格式做过设置，所以无论运行程序以前是什么数据格式（AnnaYu用的摄像头默认的确使用I420而不是RGB24），如果设置成功，肯定应该会使摄像头使用RGB24的。我找到了设置的代码：
在这段代码中，我先声明了一个CMediaType对象，将它设置成我要的格式后（包括设置MEDIASUBTYPE_RGB24），利用SetMediaType将它赋给摄像头Filter（mGrabber）。
在后面的代码中，我又通过GetConnectedMediaType取出了格式（pbFormat），当我进行步进调试到vih赋值这一步时，我发现vih->bmiHeader中有一个字段：biBitCount，这个字段表示的是每个像素的大小，我这里正确的值是24，那么...AnnaYu的机器的问题是不是就是出在这里呢？
可是什么会阻止用户将位图位数设置成24呢？我的脑中闪过一种情况：桌面不支持24位真彩色。我马上让AnnaYu看她的系统桌面是什么颜色，果然，是16位增强色，改成32为真彩色后，问题解决。
不过我还是有些疑问，为什么16位增强色下每帧大小不是24位色的2/3，而是1/2？难道真的是按32位色算的？但是3*Heigtht*Width为什么又会和32位色下的BufferSize相等？
我自己实验了一下，发现16位色下，biBitCount的值是12，而不是16，这样就合理的解释了为什么是1/2，而且这样看来，16位色和32位色一样，除了RGB，还有其他信息（也许是alpha？）
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。