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

Question

我需要开发一个自定义'包装'视频编解码器并将其集成到Android（JB现在，ICS以后）。我们想使用SIM卡上的一些定制解密密钥（不要问！）。最好的方法（这将允许它与其他非加密媒体一起工作并使用标准媒体播放器或其他）似乎是定义我们自己的mime类型，并将其链接到可以执行定制的自定义包装器编解码器解密，然后将数据传递给真正的编解码器。 （假设目前的文件类型为.mp4）。

（另一种方法可能是编写我们自己的媒体播放器，但我们宁愿不沿着这条路线走，因为我们真的希望媒体与其他媒体一起无缝地出现）

我一直在试图按照本指南： how to integrate a decoder into multimedia framework

1. 我在与OMX核心登记的麻烦 - 通过键入make stagefright但指南中，我可以从Android源码构建libstagefright.so他说使用libstagefrighthw.so这似乎适用于JB，但我不知道如何建立这个，它似乎并没有建立使用make stagefright，除非我做错了什么？

2. 另一个问题是，即使我得到了自定义包装器编解码器注册，我不知道如何去传递数据关闭到一个真正的编解码器。

如果任何人有任何建议（！或者可以给一步的指示，一些婴儿步骤），我会很感激 - 截止日期是概念的证明很紧，我所知甚少编解码器或媒体框架...

非常感谢。 （ps我不想陷入一场关于DRM和模拟孔等的泥巴战斗，谢谢）

Answer 1

在这篇文章中，我以H.264为例，但解决方案（s）可以扩展以支持其他编解码器，如MPEG-4,VC-1,VP8等。有两种可能的解决方案来解决您的问题，我在下面列出，每个都有自己的优点和缺点，以帮助您做出明智的决定。

解决方案1：扩展编解码器，以支持新的模式

在JellyBean，人们可以作为2点不同的部件的名称即，OMX.ABC.XYZ和OMX.ABC.XYZ.secure与相同类型MIME注册相同OMX部件。前者用于正常播放，是更常用的组件。当解析器即MediaExtractor指示存在安全内容时使用后者。在OMXCodec::Create中，在findMatchingCodecs返回编解码器列表之后，我们可以观察选择.secure组件作为here的选择。

遵循的步骤：

1. 在你的平台上，有了一些新的扩展像OMX.H264.DECODER.decrypt或类似的注册另一个组件。仅在media_codecs.xml中需要更改。选择是注册新工厂方法还是采用通用工厂方法是您的选择。

2. 从您的解析器中，当您遇到特定用例时，请设置一个新标志，如kKeyDecryptionRequired。为此，您必须在中定义一个新的标志，并在OMXCodec.h中定义一个相应的标志。

3. 修改OMXCodec::create方法以追加.decrypt后缀，类似于.secure后缀，如上所示。

4. 随着OMXCodec，Metadata，MediaExtractor模块的所有变化，你将只有libstagefright.so重建和更换相同的平台上。

Voila !!你的整合应该是完整的。现在是组件内部的主要挑战。作为组件实现的一部分，您应该能够区分普通组件创建和组件创建。

从运行的角度看，假设你的组件是知道的事实，这是一个.decrypt组件或没有，你可以处理decryption为OMX_EmptyThisBuffer电话，在那里你可以对数据进行解密，然后将它传递给一部分底层编解码器。

优点：易于集成，Android框架中的最小变化，可扩展到其他编解码器，没有新的需要MIME类型注册。

缺点：您需要跟踪android的未来版本，特别是新的怪癖，旗帜和.decrypt扩展的选择。如果谷歌决定采用类似的东西，你将不得不相应地修改/修改你的解决方案。

解决方案2：新的MIME类型

登记从你的问题，目前尚不清楚，如果你能定义MIME型与否，因此，我捕捉为了清晰的步骤。

遵循的步骤：

1. 在MediaDefs注册新MIME类型，如图here。例如，你可以使用一个新的MIME类型const char *MEDIA_MIMETYPE_VIDEO_AVC_ENCRYPT = "video/avc-encrypt";

2. 与media_codecs.xml此更新MIME类型注册新组件。请注意，您必须确保相应地处理组件怪癖。

3. 在OMXCodec::setVideoOutputFormat方法实现，你将不得不引进了如图所示的H.264here处理新MIME类型的支持。请注意，您将不得不在OMXCodec中处理类似的更改以支持新的MIME类型。

4. 在MediaExtractor中，您将不得不使用新定义的类型来为video音轨发出MIME类型的信号。通过这些更改，您的组件将被选中并创建。

然而，挑战依然存在：凡执行解密？为此，您可以采用与前一节中所述相同的解决方案，即与OMX_EmptyThisBuffer调用的一部分相同。

优点：没有，我能想到的..

缺点：首先，解决方法是不可扩展的。您将不得不不断添加更新的MIME类型并不断修改Stagefright框架。接下来，OMXCodec中的更改将需要MediaExtractor的相应更改。因此，即使您最初的注意力集中在MP4提取器上，如果您希望将解决方案扩展到其他容器格式，如AVI,MKV，您将不得不在这些提取器中包含对新MIME类型的支持。

最后，一些注意事项。

1. 作为首选的解决方案，我会推荐解决方案1，因为它很容易和简单。

2. 我还没有谈及基于ACodec的编解码器的实现。但是，我确实认为解决方案1将是一种更简单的解决方案，即使未来需要这种支持也是如此。

3. 如果您未修改OMX核心，则不应要求修改libstagefrighthw.so。仅供参考，这通常由供应商实施，作为供应商特定模块的一部分，如vendor/<xyz>/hardware/...。您需要与您的平台提供商联系libstagefrighthw.so的来源。