我们目前正在使用Silverlight VideoSink从用户的本地网络摄像头捕获视频,有点像:
protected override void OnSample(long sampleTime, long frameDuration, byte[] sampleData)
{
if (FrameShouldBeSubmitted())
{
byte[] resampledData = ResizeFrame(sampleData);
mediaController.SetVideoFrame(resampledData);
}
}
现在,在我们测试的大多数机器上,byte [] sampleData参数中提供的视频样本是颠倒的,即,如果您尝试获取RGBA数据并将其转换为,例如, WriteableBitmap,位图将颠倒。这很奇怪,但当然很容易纠正 - 你只需要在编码时反转数组。
问题在于,至少在某些机器上(例如,我们测试环境中的单个Macintosh),提供的视频样本不再是颠倒的,而是正面向上,因此,翻转图像实际上会导致在远处收到倒挂的图像。
我向MS报告这是一个错误,但他们(简洁)的反应是它是“As Designed”。到目前为止,进一步的澄清尝试都被忽略了。
现在,我认为想象这个设计决策背后的讨论是有趣的:“好吧,只是为了让它变得有趣,让我们在Mac上播放视频,但让我们把它颠倒过来用于Windows! “ “很好的主意!” “是的,这会让那些开发人员猜测!”但除此之外,我无法找到这个,嗯,“功能”记录在任何地方,我也找不到任何关于如何能够判断给定视频样本是颠倒还是正面的文档。有关如何辨别的想法吗?
编辑3/29/10 4:50 pm - 我收到了来自MS的回复说,通过VideoFormat对象的Stride属性判断是否合适,即如果步幅值为负,则图像将为颠倒了。但是,我自己的测试表明,除非我做错了,否则情况并非如此。至少在我自己的机器上,无论步幅值是零还是负(我看到的唯一选项),采样图像仍然是颠倒的。
答案 0 :(得分:2)
我打算建议查看 VideoSink.OnFormatChange 提供的 VideoFormat.Stride ,但后来我注意到了你的编辑。我继续在我的开发机器上测试它,图像是颠倒的,并且步幅是负面的,如预期的那样。你最近再次检查过吗?
尽管步幅对于本机应用程序(使用指针操作的步幅)非常有意义,但我同意当前行为不是您对现代API的期望。无论性能如何,最好不要对从本机API接收的数据进行更改。
在这一点上,虽然我们在谈论性能,但为什么不提供 PixelFormatType.Format32bppArgb 以外的格式的样本,以便我们可以避免色彩空间转换?顺便说一句,有一个 VideoCaptureDevice.DesiredFormat 属性,它只适用于分辨率,因为除了PixelFormatType.Format32bppArgb之外别无选择。