android - 自定义包装器编解码器集成到Android中

Question

我需要开发一个自定义的“包装器”视频编解码器，并将其集成到android中（目前是jb，稍后是ics）。我们想使用一些来自SIM卡的自定义解密密钥（不要问！）。最好的方法（这将允许它与其他非加密媒体一起工作，并使用标准媒体播放器或其他）似乎是定义我们自己的mime类型，并将其链接到可以进行自定义解密的自定义包装编解码器，然后将数据传给真正的编解码器。（假设现在文件类型是.mp4。）
（另一种选择可能是编写自己的媒体播放器，但我们不想走这条路，因为我们真的希望媒体与其他媒体无缝地共存）
我一直在试着遵循这个指南：
how to integrate a decoder into multimedia framework
我在OMX核心注册方面遇到了问题-我可以通过键入libstagefright.so从Android源代码构建make stagefright，但在指南中他说使用libstagefrighthw.so似乎适合JB，但我不确定如何构建它，除非我做错了什么，否则它似乎不是通过使用make stagefright构建的？
另一个问题是，即使我注册了自定义包装编解码器，我也不知道如何将数据传递给真正的编解码器。
如果有人有任何建议（或者可以给宝宝一步一步的指导！），我真的很感激它-最后期限很紧的概念证明，我知道很少关于编解码器或媒体框架…
非常感谢。
（P.S.我不想在数字版权管理和模拟漏洞等问题上陷入泥潭，谢谢）

Answer 1

在这篇文章中，我以H.264为例，但是这个解决方案可以扩展到支持其他编解码器，如MPEG-4，VC-1，VP8等。有两种可能的解决方案可以解决您的问题，我在下面列出，每种方案都有各自的优缺点，以帮助您做出明智的决定。
解决方案1：扩展编解码器以支持新模式
在JellyBean中，可以将具有相同OMX类型的相同MIME组件注册为两个不同的组件名，即，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扩展的选择。如果谷歌决定采用类似的方法，你必须相应地修改你的解决方案。
解决方案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.264here所示。请注意，您必须处理OMXCodec中的类似更改，才能支持新的MIME类型。
在MediaExtractor中，您将必须使用新定义的类型为MIME轨迹发出video类型的信号。通过这些更改，将选择并创建组件。
然而，挑战仍然存在：在哪里执行解密？为此，您也可以采用与前一节中描述的相同的解决方案，即处理与OMX_EmptyThisBuffer调用相同的部分。
优点：我想不出。
缺点：首先，解决方案不可扩展。您必须不断添加新的MIME类型，并不断修改Stagefright框架。接下来，OMXCodec中的更改将需要MediaExtractor中的相应更改。因此，即使您最初的重点是MP4提取器，如果您希望将解决方案扩展到其他容器格式，如AVI，MKV，您也必须在这些提取器中包含对新MIME类型的支持。
最后是一些注意事项。
作为首选解决方案，我建议使用解决方案1，因为它简单易行。
我还没有提到基于ACodec的编解码器实现。不过，我确实觉得解决方案1是一个更容易实现的解决方案，即使将来需要这样的支持。
如果不修改OMX核心，则不需要修改libstagefrighthw.so。仅供参考，这通常由供应商作为其特定于供应商的模块的一部分实现，如vendor/<xyz>/hardware/...。您需要向平台提供商查询libstagefrighthw.so的源代码。