音频引脚渲染数据时 DirectShow 视频播放速度太快
我正在为每个引脚开发基于 CSource 和 CSourceStream 的自定义 Windows DirectShow 源过滤器。有两个引脚 - 视频输出和音频输出。当在 graphedit 和类似工具（例如 Graph Studio）中单独渲染并具有正确的时间戳、帧速率和声音时，这两个引脚都可以正常工作。我正在将视频渲染到视频混合渲染器（VMR7 或 VMR9）。
然而，当我渲染两个引脚时，视频播放速度太快，而音频听起来仍然正确。视频播放速度快了大约 50%，但我认为这受到解码速度的限制。
两种情况下样本上的时间戳都是相同的。如果我将音频流渲染到空渲染器（qedit.dll 中的渲染器），则视频流会以正确的帧速率播放。该过滤器是在 Win7 x64 系统上运行的 32 位过滤器。
当我添加对 IMediaSeeking 搜索的支持时，我发现音频流的搜索栏表现得很奇怪。但是，如果没有 IMediaSeeking 支持，就会出现问题。
对于可能导致此问题的原因有什么建议或进一步调查的建议吗？
音频和视频引脚的输出类型粘贴如下：
Mediatyp: Video Subtype: RGB24 Format: Type VideoInfo Video Size: 1024 x 576 Pixel, 24 Bit Image Size: 1769472 Bytes Compression: RGB Source: width 0, height 0 Target:宽度 0，高度 0 比特率：0 位/秒。错误率：0 位/秒。平均。显示时间：41708 微秒。
Mediatyp：视频子类型：RGB32 格式：类型 VideoInfo 视频大小：1024 x 576 像素，32 位图像大小：2359296 字节压缩：RGB 源：宽度 0，高度 0 目标：宽度 0，高度 0 比特率：0 位/秒。错误率：0 位/秒。平均。显示时间：41708 微秒。
主要类型：音频 子类型：PCM 音频 样本数量：3 类型 WaveFormatEx 波形格式：未知 频道：1 样本/秒：48000 平均。字节/秒：144000 块对齐：3 位/样本：24
I'm working on a custom Windows DirectShow source filter based on CSource and CSourceStream for each pin. There are two pins - video output and audio output. Both pins work fine when individually rendered in graphedit and similar tools such as Graph Studio with correct time stamps, frame rates and sound. I'm rendering the video to the Video Mixing Renderer (VMR7 or VMR9).
However when I render both pins the video plays back too fast while the audio still sounds correct. The video plays back approximately 50% too fast but I think this is limited by the speed of decoding.
The timestamps on the samples are the same in both cases. If I render the audio stream to a null renderer (the one in qedit.dll) then the video stream plays back at the correct frame rate. The filter is a 32 bit filter running on a Win7 x64 system.
When I added support for IMediaSeeking seeking I found that the seeking bar for the audio stream behaved quite bizarrely. However the problem happens without IMediaSeeking support.
Any suggestions for what could be causing this or suggestions for further investigation?
The output types from the audio and video pin are pasted below:
Mediatyp: Video Subtype: RGB24 Format: Type VideoInfo Video Size: 1024 x 576 Pixel, 24 Bit Image Size: 1769472 Bytes Compression: RGB Source: width 0, height 0 Target: width 0, height 0 Bitrate: 0 bits/sec. Errorrate: 0 bits/sec. Avg. display time: 41708 µsec.
Mediatyp: Video Subtype: RGB32 Format: Type VideoInfo Video Size: 1024 x 576 Pixel, 32 Bit Image Size: 2359296 Bytes Compression: RGB Source: width 0, height 0 Target: width 0, height 0 Bitrate: 0 bits/sec. Errorrate: 0 bits/sec. Avg. display time: 41708 µsec.
Majortyp: Audio
Subtype: PCM audio
Sample Size: 3
Type WaveFormatEx
Wave Format: Unknown
Channels: 1
Samples/sec.: 48000
Avg. bytes/sec.:144000
Block align: 3
Bits/sample: 24
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我在发布问题后立即意识到了问题。通过正确构建问题进行调试的案例。
音频流的时间戳完全是伪造的。音频和视频流单独播放时效果很好，但一起播放时根本不同步。
I realised the problem straight after posting the question. A case of debugging by framing the question correctly.
The audio stream had completely bogus time stamps. The audio and video streams played back fine individually but did not synch at all with each other when played together.