高分辨率捕获和编码
Posted
技术标签:
【中文标题】高分辨率捕获和编码【英文标题】:High Resolution Capture and Encoding 【发布时间】:2011-11-11 17:16:35 【问题描述】:我正在使用两个自定义推送过滤器将音频和视频(未压缩的 RGB)注入 DirectShow 图表。我正在制作一个视频捕获应用程序,所以我想在帧进入时对其进行编码并将它们存储在一个文件中。
到目前为止,我一直使用 ASF Writer 将输入编码为 WMV 文件,但渲染器似乎太慢而无法处理高分辨率输入(例如 1920x1200x32)。至少,FillBuffer()
似乎只能处理 6-15 FPS 左右,这显然不够快。
我尝试增加DecideBufferSize()
中的cBuffers
计数,但这当然只会将问题推到后面。
我有哪些加快流程的选择?通过 DirectShow 进行实时高分辨率编码的正确方法是什么?我最终希望得到一个 WMV 视频,但也许这必须是一个后期处理步骤。
【问题讨论】:
【参考方案1】:您的问题在这里发布了很好的答案:High resolution capture and encoding too slow。该任务对于您系统中的 CPU 来说太复杂了,它的速度不足以在您设置的配置中执行实时视频编码。
【讨论】:
是的,MSDN 上的回复碰巧比这里更快(这是第一个 :) 出于好奇,你有没有回答我放在那里的最后一个问题(关于帧率的问题)? CPU密集型部分显然是编码器。编码器可以利用多个 CPU 内核来处理数据并尽可能缩短处理时间 - 如果编码器无法按时为您提供压缩内容,您几乎无法调整软件设置。最明显的可能是较低的编码复杂度 - 这样在所有其他参数保持不变的情况下输出速度更快。 对不起,我指的是我最新帖子中的后续问题,即关于定时捕获单个帧的问题。我应该总是尝试点击视频的目标标记,即从第一帧的时间戳开始每 1/30 秒,还是应该从最后一次捕获一帧开始 1/30 秒(假设我正在以 30 FPS 捕获) ? 鉴于编码器无法实时压缩,您到底想实现什么? (a) 找到另一种计算量较小的模式 (b) 降低帧速率 (c) 累积原始数据并压缩完整片段,比实时慢? 我在您上面链接到的线程末尾提出的问题不是关于快速通过编码器推送帧,而是关于捕获帧。由于我不控制从应用程序中获取帧的速率,因此我尝试在可能的最佳时间间隔内捕获帧,以使编码的视频看起来尽可能流畅。以上是关于高分辨率捕获和编码的主要内容,如果未能解决你的问题,请参考以下文章