Media Foundation H264编码器的CLSID在哪里？ [英] Where is the CLSID for Media Foundation H264 Encoder?
问题描述
媒体基金会H264编码器MFT 文档未提及编码器的CLSID。其他编码器类ID和H264解码器MFT类ID在以下位置定义
The Media Foundation H264 Encoder MFT documentation does not mention a CLSID for the encoder. Other Encoder class IDs, and the H264 Decoder MFT class ID are defined at
\Program Files (x86)\Microsoft SDKs\7.1\Include\wmcodecdsp.h or
\Program Files (x86)\Windows Kits\8.x\Include\am\wmcodecdsp.h
我在枚举设备时看到此编解码器，并且可以获得CLSID，即{6ca50344-051a-4ded-9779-a43305165e35 }，但从枚举列表中找不到，但是我希望找到一个命名的GUID，如下所示：CLSID_CH264MediaEncObject
I see this codec when I enumerate the devices, and can obtain the CLSID, which is {6ca50344-051a-4ded-9779-a43305165e35}, from the enumerated list, but I cannot find a named GUID, which I would expect to be something like: CLSID_CH264MediaEncObject
我想使用GUID（而不是枚举名称），以便在构建拓扑时根据用户选择的编码器来做出决策。我可以定义它，但似乎有点奇怪。
I would like to use the GUID (rather than the enumerated name) to make decisions when building my topology based on which encoder the user has selected. I can define_guid this, but it just seems odd.
因此：
为什么没有为H264编码器MFT命名的guid？
So: Why is there not a named guid for the H264 Encoder MFT?
推荐答案
这似乎是有意的，因为Media Foundation API建议您让该API为您选择合适的编码器。您的角色是建立一个合适的配置文件，并让转码API使用请求的参数来创建拓扑。
This looks intentional as Media Foundation API suggests that you let the API choose appropriate encoder for you. Your role there is to build a suitable profile and let transcoding API to create the topology using requested parameters.
我想您知道MSDN的领导者，但是为了记录： a href = http://msdn.microsoft.com/zh-cn/library/windows/desktop/ff819476%28v=vs.85%29.aspx#create_the_transcode_profile rel = nofollow>教程：编码MP4文件-创建转码配置文件。
I suppose you know the MSDN leads, but for the record: Tutorial: Encoding an MP4 File - Create the Transcode Profile.
尤其是，他们似乎希望保留对编码器选择的控制权，以便在适用的情况下自动使用硬件编码器：
In particular, they seem to want to retain control over encoder choice in order to use hardware encoder automatically where applicable:
如果存在经过认证的硬件编码器，则通常将其用于代替与Media Foundation相关的方案的收件箱系统编码器。
If a certified hardware encoder is present, it will generally be used instead of the inbox system encoder for Media Foundation related scenarios.
DirectShow中压缩器的问题之一是常见的列表和竞争压缩机之间的位置。由于许多原因，应用程序宁愿对特定的压缩器进行硬编码，也不愿使用给定格式的最佳选择。在MF中，方法有所不同：配置文件定义了最终要在输出中获取的内容，然后API负责提供编码器。
One of the problems with compressors in DirectShow was the common list and competition between compressors. For many reasons, an application would rather hardcode specific compressor rather than use the best choice for given format. Here in MF the approach is different: a profile defines what you want to eventually get on the output, then API takes responsibility to supply the encoder.
这篇关于Media Foundation H264编码器的CLSID在哪里？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
