我需要开发一个自定义的'包装'视频编解码器并将其集成到android（现在的JB，ICS以后）。我们想要使用SIM中的一些自定义解密密钥（不要问！）。最好的方法（允许它与其他非加密媒体一起工作并使用标准媒体播放器或其他）似乎是定义我们自己的mime类型，并将其链接到可以执行自定义的自定义包装编解码器解密，然后将数据传递给真正的编解码器。 （现在假设文件类型为.mp4。）
（另一种选择可能是编写我们自己的媒体播放器，但我们宁愿不去那条路，因为我们真的希望媒体与其他媒体一起无缝地出现）
我一直在尝试遵循本指南： how to integrate a decoder into multimedia framework
我在使用OMX Core注册时遇到问题 - 我可以通过键入libstagefright.so从Android源代码构建make stagefright，但在指南中他说要使用libstagefrighthw.so这似乎适合JB，但我不知道如何构建它，它似乎不是使用make stagefright构建的，除非我做错了什么？
另一个问题是，即使我注册了自定义包装编解码器，我也不确定如何将数据传递给真正的编解码器。
如果有人有任何建议（或者可以给一些宝宝一步一步的指示！），我真的很感激 - 截止日期对于概念验证而言非常紧张，而且我对编解码器或媒体框架知之甚少。 ..
非常感谢。 （p.s.我不想陷入关于drm和模拟孔等的泥泞斗争..，谢谢）
答案 0 :(得分：9)
在这篇文章中，我使用H.264作为示例，但解决方案可以扩展为支持其他编解码器，如MPEG-4，VC-1，VP8有两种可能的解决方案可以解决您的问题，我将在下面列出，每种解决方案各有利弊，帮助您做出明智的决定。
解决方案1：扩展编解码器以支持新模式
在JellyBean中，可以注册与OMX类型相同的MIME组件，其中包含2个不同的组件名称，OMX.ABC.XYZ和OMX.ABC.XYZ.secure。前者用于正常播放，是更常用的组件。当解析器即MediaExtractor表示存在安全内容时，使用后者。在OMXCodec::Create中，在findMatchingCodecs返回编解码器列表后，我们可以选择将.secure组件选为here。
要遵循的步骤：
在您的平台中，使用OMX.H264.DECODER.decrypt或类似的新扩展名注册另一个组件。仅在media_codecs.xml中需要更改。您可以选择是否注册新工厂方法或采用通用工厂方法。
在您的解析器中，遇到特定用例时，请设置一个新的标记，如kKeyDecryptionRequired。为此，您必须在Metadata.h中定义新标记，并在OMXCodec.h中定义相应的怪癖。
修改OMXCodec::create方法，以附加类似于.decrypt后缀的.secure后缀，如上所示。
对OMXCodec，Metadata，MediaExtractor模块中的所有更改，您只需重建libstagefright.so并在您的平台上替换相同内容。
瞧!!你的整合应该是完整的。现在是组件内部的主要挑战。作为组件实现的一部分，您应该能够区分普通组件创建和.decrypt组件创建。
从运行时的角度来看，假设您的组件知道它是.decrypt组件的事实，您可以在decryption调用中处理OMX_EmptyThisBuffer，您可以在哪里解密数据，然后将其传递给底层编解码器。
优点：易于集成，Android框架中的微小更改，可扩展到其他编解码器，无需新的MIME类型注册。
缺点：您需要跟踪android的未来修订版，特别是新的怪癖，标记和.decrypt扩展名的选择。如果Google决定采用类似的东西，您必须相应地调整/修改您的解决方案。
解决方案2：注册新的MIME类型
根据您的问题，目前尚不清楚您是否能够定义MIME类型，因此，为了清晰起见，我正在捕捉这些步骤。
要遵循的步骤：
在MIME注册一个新的MediaDefs类型，如图here所示。例如，您可以使用新的MIME类型作为const char *MEDIA_MIMETYPE_VIDEO_AVC_ENCRYPT = "video/avc-encrypt";
在MIME中使用此更新后的media_codecs.xml类型注册新组件。请注意，您必须确保相应处理组件怪癖。
在OMXCodec::setVideoOutputFormat方法实施中，您必须引入处理新MIME类型的支持，如H.264 here所示。请注意，您必须在OMXCodec处理类似的更改才能支持新的MIME类型。
在MediaExtractor中，您必须使用新定义的类型发出MIME曲目的video类型信号。通过这些更改，将选择并创建组件。
然而，仍然存在挑战：在哪里执行解密？为此，您也可以使用与上一节中描述的相同的解决方案，即处理与OMX_EmptyThisBuffer调用的一部分相同的解决方案。
优点：我无法想到......
缺点：首先，解决方案无法扩展。您必须不断添加较新的MIME类型并继续修改Stagefright框架。接下来，OMXCodec中的更改将需要MediaExtractor中的相应更改。因此，即使您最初关注的是MP4提取器，如果您希望将解决方案扩展到其他容器格式，例如AVI，MKV，您也必须包含对新MIME的支持。 {1}}这些提取器中的类型。
最后，一些说明。
作为首选解决方案，我会推荐解决方案1，因为它简单易用。
我没有涉及基于ACodec的编解码器实现。但是，我确实认为解决方案1将是一个更容易实现的解决方案，即使将来需要这样的支持。
如果您不修改OMX核心，则不应要求修改libstagefrighthw.so。仅供参考，这通常由供应商实施，作为其供应商特定模块的一部分，如vendor/<xyz>/hardware/...。您需要向您的平台提供商咨询libstagefrighthw.so。