自定義包裝編解碼器集成到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的來源。