有效地将异步IMFSourceReader连接到同步IMFTransform
给定连接到仅同步IMFTransform的异步IMFSourceReader。
那么，对于IMFSourceReaderCallback:: OnReadSample ()回调，最好不要直接在OnReadSample中调用IMFTransform::ProcessInput，而是将生成的样本推送到另一个队列中，以便另一个线程调用转换ProcessInput。
或者我只是复制源代码阅读器通常在内部做的相同的工作？或者换一种方式，OnReadSample中的工作是否存在阻止源代码阅读器中任何进一步的解码工作的风险，否则这些工作可能会更异步地发生？
因此，我建议这样做：
WorkQueue transformInputs;
...
// Called back async
HRESULT OnReadSampleCallback(... IMFSample* sample)
{
// Push sample and return immediately
Push(transformInputs, sample);
}
// Different worker thread awoken for transformInputs queue samples
void OnTransformInputWork()
{
// Transform object is not async capable
transform->TransformInput(0, Pop(transformInputs), 0);
...
}这里提到了这一点，但没有在“实现回调接口”中详细说明：https://docs.microsoft.com/en-us/windows/win32/medfound/using-the-source-reader-in-asynchronous-mode
或者它完全依赖于源代码阅读器内部设置的任何内容，并且不容易确定？
回答 1
Stack Overflow用户
发布于 2020-11-02 00:26:03
在IMFSourceReaderCallback::OnReadSample中执行长阻塞操作不是一个好主意。没有什么是致命的或严重的，但这不是预期的用途。
考虑到你之前关于音频格式转换的问题，音频样本数据转换足够快，可以在这样的回调中发生。
此外，它不清楚或没有文档记录(取决于实际实现)，ProcessInput通常是即时的，并且只引用输入数据。在这种情况下，ProcessOutput的计算代价会很高。如果你不在同一个回调中执行ProcessOutput，你可能会遇到MFT不再接受输入的情况，所以无论如何你都必须实现一个队列。
考虑到所有这些，你只需要在回调中进行处理，而忽略对性能的影响，假设你的处理不是太重，否则你就会开始做队列。
https://stackoverflow.com/questions/64632070
复制相似问题
腾讯云开发者
