Transkodowanie zgodnych multimediów

Zgodne transkodowanie multimediów wprowadzone w Androidzie 12 to funkcja, która pozwala urządzeniom na korzystanie z nowoczesnych i wydajniejszych formatów multimediów do nagrywania filmów (np. HEVC) przy zachowaniu zgodności z aplikacjami. Dzięki tej funkcji producenci urządzeń mogą domyślnie używać HEVC zamiast AVC, aby poprawić jakość wideo, a jednocześnie ograniczyć wymagania dotyczące miejsca na dane i przepustowości. W przypadku urządzeń z włączonym transkodowaniem zgodnych multimediów Android może automatycznie konwertować filmy (o długości do minuty) nagrane w formatach takich jak HEVC lub HDR, jeśli są one otwierane w aplikacji, która nie obsługuje tego formatu. Dzięki temu aplikacje mogą działać nawet wtedy, gdy urządzenie jest nagrywane w nowszym formacie.

Funkcja transkodowania zgodnych multimediów jest domyślnie wyłączona. Aby zażądać transkodowania multimediów, aplikacje muszą zadeklarować swoje możliwości związane z multimediami. Więcej informacji o deklarowaniu możliwości multimediów znajdziesz w artykule Transkodowanie zgodnych multimediów na stronie dla deweloperów aplikacji na Androida.

Jak to działa

Funkcja transkodowania multimediów składa się z 2 głównych części:

  • Usługi transkodowania w ramach platformy multimedialnej: te usługi konwertują pliki z jednego formatu na inny za pomocą sprzętu, aby zapewnić krótki czas oczekiwania i wysoką jakość konwersji. Obejmuje to interfejs API transkodowania, usługę transkodowania, wtyczkę OEM do filtrów niestandardowych oraz sprzęt. Więcej informacji znajdziesz w artykule Omówienie architektury.
  • Funkcja transkodowania multimediów u dostawców multimediów: ten komponent przechwytywany przez dostawców multimediów przechwytuje aplikacje uzyskujące dostęp do plików multimedialnych i wyświetla oryginalny lub transkodowany plik zależnie od zadeklarowanych możliwości aplikacji. Jeśli aplikacja obsługuje format pliku multimedialnego, nie wymaga to specjalnej obsługi. Jeśli aplikacja nie obsługuje tego formatu, platforma konwertuje plik na starszy format, na przykład AVC, gdy aplikacja uzyska do niego dostęp.

Ilustracja 1 przedstawia proces transkodowania multimediów.

Zgodny proces transkodowania multimediów

Rysunek 1. Omówienie transkodowania zgodnych multimediów.

Obsługiwane formaty

Zgodna funkcja transkodowania multimediów obsługuje konwersje w tych formatach:

  • HEVC (8-bitowe) na AVC: konwersje kodeków są wykonywane przez połączenie 1 dekodera Mediacodec i 1 kodera Mediacode.
  • HDR10+ (10-bitowy) na AVC (SDR): konwersje z HDR na SDR są wykonywane za pomocą instancji Mediacodec i wtyczki dostawcy łączącej się z instancjami dekodera. Więcej informacji znajdziesz w artykule o kodowaniu HDR na SDR.

Obsługiwane źródła treści

Zgodna funkcja transkodowania multimediów obsługuje multimedia na urządzeniu generowane przez natywną aplikację aparatu OEM i przechowywane w folderze DCIM/Camera/ w głównym woluminie zewnętrznym. Funkcja nie obsługuje multimediów w pamięci dodatkowej. Treści przekazywane na urządzenia e-mailem lub na kartach SD nie są obsługiwane.

Aplikacje uzyskują dostęp do plików na podstawie różnych ścieżek. Poniżej znajdziesz opis ścieżek plików, w których transkodowanie jest włączone lub pomijane:

  • Transkodowanie włączone:

    • Dostęp do aplikacji przez interfejsy MediaStore API
    • Dostęp do aplikacji za pomocą bezpośrednich interfejsów API ścieżek plików, w tym Javy i kodu natywnego
    • Dostęp do aplikacji za pomocą platformy Storage Access Framework (SAF)
    • Dostęp aplikacji przez intencje arkusza udostępniania systemu operacyjnego. (tylko identyfikator URI MediaStore)
    • Przesyłanie plików MTP/PTP z telefonu na komputer

  • Pominięto transkodowanie:

    • Przenoszenie pliku z urządzenia przez wyjęcie karty SD
    • przenoszenia plików z urządzenia na urządzenie za pomocą takich opcji jak Udostępnianie w pobliżu czy przesyłanie przez Bluetooth.

Dodawanie niestandardowych ścieżek plików na potrzeby transkodowania

Producenci urządzeń mogą opcjonalnie dodać ścieżki plików do transkodowania multimediów w katalogu DCIM/. Wszystkie ścieżki spoza katalogu DCIM/ są odrzucane. Dodanie takich ścieżek plików może być wymagane ze względu na wymagania operatora lub lokalne przepisy.

Aby dodać ścieżkę pliku, użyj ścieżki transkodowania Nakładka zasobów środowiska wykonawczego (RRO), config_supported_transcoding_relative_paths. Oto przykład dodawania ścieżki pliku:

<string-array name="config_supported_transcoding_relative_paths" translatable="false">
    <item>DCIM/JCF/</item>
</string-array>

Aby sprawdzić skonfigurowane ścieżki plików, użyj polecenia:

adb shell dumpsys activity provider com.google.android.providers.media.module/com.android.providers.media.MediaProvider | head -n 20

Omówienie architektury

W tej sekcji opisano architekturę funkcji transkodowania multimediów.

architektura transkodowania multimediów

Rysunek 2. Architektura transkodowania multimediów.

Architektura transkodowania multimediów składa się z tych komponentów:

  • System API MediaTranscodingManager: interfejs, który umożliwia klientowi komunikację z usługą MediaTranscoding. Z tego interfejsu API korzysta moduł MediaProvider.
  • MediaTranscodingService: usługa natywna, która zarządza połączeniami z klientami, planuje żądania transkodowania i zarządza księgowością w TranscodingSessions.
  • MediaTranscoder: natywna biblioteka obsługująca transkodowanie. Ta biblioteka opiera się na platformie medialnej NDK i jest zgodna z modułami.

Zgodna funkcja transkodowania multimediów rejestruje wskaźniki transkodowania zarówno w usłudze, jak i w transkoderze multimediów. Kod po stronie klienta i kod po stronie usługi znajdują się w module MediaProvider, co umożliwia szybkie poprawki błędów i aktualizacje.

Dostęp do plików

Zgodne transkodowanie multimediów jest wbudowane w system plików w systemie plików Userspace (FUSE), który jest używany do przechowywania danych o określonym zakresie. FUSE umożliwia modułowi MediaProvider badanie operacji na plikach w obszarze użytkownika i blokowanie dostępu do plików na podstawie zasady zezwalającej na dostęp, odmowy lub usunięcia.

Gdy aplikacja próbuje uzyskać dostęp do pliku, demon FUSE przechwytuje dostęp do pliku z uprawnieniami do odczytu. Jeśli aplikacja obsługuje nowszy format (np. HEVC), zwracany jest oryginalny plik. Jeśli aplikacja nie obsługuje tego formatu, plik zostanie transkodowany na starszy format (np. AVC) lub zostanie zwrócony z pamięci podręcznej, jeśli dostępna jest transkodowana wersja.

Poproś o transkodowane pliki

Funkcja transkodowania zgodnych multimediów jest domyślnie wyłączona, co oznacza, że jeśli urządzenie obsługuje HEVC, Android nie transkoduje plików, chyba że aplikacja wskaże to w pliku manifestu lub na liście wymuszania transkodowania.

Aplikacje mogą wysyłać żądania transkodowanych zasobów za pomocą tych opcji:

  • Zadeklaruj nieobsługiwane formaty w pliku manifestu. Więcej informacji znajdziesz w artykułach Deklarowanie możliwości w zasobie i Deklarowanie możliwości w kodzie.
  • Dodaj aplikacje do listy wymuszania transkodowania znajdującej się w module MediaProvider. Umożliwia to transkodowanie aplikacji, które nie zaktualizowały pliku manifestu. Gdy aplikacja zaktualizuje plik manifestu w nieobsługiwanych formatach, należy usunąć ją z listy wymuszonych transkodowania. Producenci urządzeń mogą zgłaszać swoje aplikacje do dodania do listy wymuszonych transkodowania lub z niej usuniętych. W tym celu przesyłają poprawkę lub zgłaszają błąd. Zespół Androida okresowo ją sprawdza i może usuwać z niej aplikacje.
  • Wyłącz obsługiwane formaty za pomocą platformy zgodności aplikacji w czasie działania (użytkownicy mogą też wyłączyć tę opcję w przypadku każdej aplikacji w Ustawieniach).
  • Otwórz plik za pomocą funkcji MediaStore, jednoznacznie określając nieobsługiwane formaty za pomocą interfejsu API openTypedAssetFileDescriptor.

W przypadku transferów USB (z urządzenia na komputer) transkodowanie jest domyślnie wyłączone, ale użytkownicy mogą je włączyć, klikając przełącznik Konwertuj filmy na AVC na ekranie ustawień USB, jak widać na ilustracji 3.

Przełącz, aby włączyć transkodowanie multimediów

Rysunek 3. Przełącz, aby włączyć transkodowanie multimediów na ekranie Ustawienia USB.

Ograniczenia dotyczące żądania transkodowanych plików

Aby żądania transkodowania nie blokowały zasobów systemowych na dłuższy czas, aplikacje żądające sesji transkodowania są ograniczone do:

  • 10 kolejnych sesji
  • całkowity czas trwania to 3 minuty

Jeśli aplikacja przekracza wszystkie te ograniczenia, platforma zwraca deskryptor oryginalnego pliku.

Wymagania dotyczące urządzeń

Aby obsługiwać kompatybilną funkcję transkodowania multimediów, urządzenia muszą spełniać te wymagania:

  • Na urządzeniu w rodzimej aplikacji aparatu domyślnie włączone jest kodowanie HEVC
  • (Urządzenia obsługujące transkodowanie HDR na SDR) Urządzenie obsługuje nagrywanie filmów HDR

Aby zapewnić wydajność urządzenia w przypadku transkodowania multimediów, należy zoptymalizować sprzęt wideo oraz uprawnienia do odczytu i zapisu w pamięci masowej. Gdy skonfigurujesz kodeki multimediów z priorytetem równym 1, kodeki muszą działać z największą możliwą przepustowością. Zalecamy, by szybkość transkodowania wynosiła co najmniej 200 kl./s. Aby sprawdzić wydajność sprzętu, użyj testu porównawczego transkodera multimediów na frameworks/av/media/libmediatranscoding/transcoder/benchmark.

Weryfikacja

Aby sprawdzić zgodną funkcję transkodowania multimediów, uruchom te testy CTS:

  • android.media.mediatranscoding.cts
  • android.mediaprovidertranscode.cts

Włącz transkodowanie multimediów globalnie

Aby przetestować działanie platformy transkodowania multimediów lub działania aplikacji za pomocą transkodowania, możesz włączyć lub wyłączyć kompatybilną funkcję transkodowania na całym świecie. Na stronie opcji programisty Ustawienia > System > Programista > Transkodowanie multimediów ustaw przełącznik Zastąp domyślne ustawienia transkodowania w pozycji włączonej, a następnie włącz lub wyłącz przełącznik Włącz transkodowanie. Gdy to ustawienie jest włączone, transkodowanie multimediów może odbywać się w tle w aplikacjach innych niż te, które tworzysz.

Sprawdzanie stanu transkodowania

Podczas testowania możesz użyć tego polecenia powłoki ADB, aby sprawdzić stan transkodowania, w tym bieżące i wcześniejsze sesje:

adb shell dumpsys media.transcoding

Przedłużenie ograniczenia długości filmu

Do celów testowych możesz skorzystać z poniższego polecenia, aby zwiększyć limit długości transkodowania wynoszący 1 minutę na potrzeby transkodowania. Po uruchomieniu tego polecenia może być wymagane ponowne uruchomienie.

adb shell device_config put storage_native_boot transcode_max_duration_ms <LARGE_NUMBER_IN_MS>

Źródło AOSP i odwołania

Poniżej znajduje się kod źródłowy AOSP powiązany z transkodowaniem zgodnych multimediów.

Kodowanie HDR na SDR

Aby obsługiwać kodowanie z HDR na SDR, producenci urządzeń mogą użyć przykładowej wtyczki filtra AOSP do kodeka 2.0 dostępnej w /platform/frameworks/av/media/codec2/hidl/plugin/. W tej sekcji opisujemy, jak działa wtyczka filtra, jak ją wdrożyć i jak ją przetestować.

Jeśli urządzenie nie ma wtyczki, która obsługuje kodowanie HDR do SDR, aplikacja uzyskująca dostęp do filmu HDR otrzymuje deskryptor oryginalnego pliku niezależnie od zadeklarowanych w pliku manifestu funkcji multimedialnych aplikacji.

Jak to działa

W tej sekcji opisano ogólne działanie wtyczki filtra Kodek 2.0.

Tło

Android udostępnia implementację warstwy adaptacji między interfejsem Codec 2.0 a interfejsem HAL android.hardware.media.c2 dostępnym na stronie android::hardware::media::c2. W przypadku wtyczek filtra AOSP obejmuje mechanizm opakowywania dekoderów razem z wtyczkami filtra. MediaCodec rozpoznaje te opakowane komponenty jako dekodery z funkcjami filtrowania.

Przegląd

Klasa FilterWrapper pobiera kodeki dostawcy i zwraca opakowane kodeki z powrotem do warstwy adaptacyjnej media.c2. Klasa FilterWrapper wczytuje libc2filterplugin.so za pomocą interfejsu API FilterWrapper::Plugin i rejestruje dostępne filtry z wtyczki. Podczas tworzenia FilterWrapper inicjuje wszystkie dostępne filtry. Tylko filtry, które zmieniają bufor, są uruchamiane na początku.

Filtruj architekturę wtyczki

Rysunek 1. Filtruj architekturę wtyczek.

Filtruj interfejs wtyczki

Interfejs FilterPlugin.h definiuje te interfejsy API do udostępniania filtrów:

  • std::shared_ptr<C2ComponentStore>getComponentStore()

    Zwraca obiekt C2ComponentStore zawierający filtry. Jest to coś innego niż informacje udostępniane przez implementację Kodeka 2.0 dostawcy. Zwykle ten magazyn zawiera tylko filtry używane przez klasę FilterWrapper.

  • bool describe(C2String name, Descriptor *desc)

    Opisuje filtry oraz dane dostępne w usłudze C2ComponentStore. Zdefiniowano te opisy:

    • controlParam: parametry sterujące działaniem filtrów. Na przykład w przypadku mapowania tonów z HDR na SDR parametr kontrolny jest docelową funkcją transferu.
    • affectedParams: parametry, na które mają wpływ operacje filtrowania. Na przykład w przypadku mapowania tonalnego z HDR na SDR dotyczą to aspektów kolorystycznych.

  • bool isFilteringEnabled(const std::shared_ptr<C2ComponentInterface> &intf)

    Zwraca true, jeśli komponent filtra zmienia bufor. Na przykład filtr mapowania tonów zwraca true, jeśli docelową funkcją transferu jest SDR, a wejściowa funkcja przenoszenia danych to HDR (HLG lub PQ).

Szczegóły filtra filtra

W tej sekcji znajdziesz szczegółowe informacje na temat klasy FilterWrapper.

na podstawie trendów

Opakowany komponent tworzy instancję bazowego dekodera i wszystkich zdefiniowanych filtrów podczas tworzenia.

Zapytanie i konfiguracja

Opakowany komponent oddziela parametry przychodzące od zapytań lub żądań konfiguracji zgodnie z opisem filtra. Na przykład konfiguracja parametru sterującego filtra jest kierowana do odpowiedniego filtra, a w zapytaniach są obecne odpowiednie parametry (zamiast odczytywać z dekodera, który ma takie parametry).

Zapytanie i konfiguracja

Rysunek 2. Zapytanie i konfiguracja.

Początek

Na początku opakowany komponent uruchamia dekoder i wszystkie filtry, które modyfikują bufory. Jeśli filtr nie jest włączony, opakowany komponent uruchamia dekoder i buforuje dane przekazujące, a następnie wysyła polecenia do samego dekodera.

Obsługa bufora

Obsługa bufora

Rysunek 3. Obsługa bufora.

Bufory umieszczone w kolejce do opakowanego dekodera trafiają do dekodera. Opakowany komponent pobiera bufor wyjściowy z dekodera przez wywołanie zwrotne onWorkDone_nb(), a następnie umieszcza go w kolejce do filtrów. Klient otrzymuje końcowy bufor wyjściowy z ostatniego filtra.

Aby ta obsługa bufora działała, opakowany komponent musi skonfigurować C2PortBlockPoolsTuning pod kątem ostatniego filtra, tak aby dane wyjściowe platformy były buforowane z oczekiwanej puli blokowej.

Zatrzymaj, zresetuj i puść

W momencie zakończenia opakowany komponent zatrzymuje dekoder i wszystkie włączone filtry, które zostały uruchomione. Przy resetowaniu i zwalnianiu wszystkie komponenty są resetowane lub zwalniane niezależnie od tego, czy są włączone.

Implementacja przykładowej wtyczki filtra

Aby włączyć wtyczkę, wykonaj te czynności:

  1. Zaimplementuj interfejs FilterPlugin w bibliotece i upuść go na stronie /vendor/lib[64]/libc2filterplugin.so.
  2. W razie potrzeby przyznaj uprawnienia mediacodec.te.
  3. Zaktualizuj warstwę adaptacji do Androida 12 i ponownie utwórz usługę media.c2.

Testowanie wtyczki

Aby przetestować przykładową wtyczkę, wykonaj te czynności:

  1. Odbuduj urządzenie i zainstaluj na nim aktualizację.

  2. Utwórz przykładową wtyczkę za pomocą tego polecenia:

    m sample-codec2-filter-plugin

  3. Podłącz ponownie urządzenie i zmień nazwę wtyczki dostawcy tak, aby była rozpoznawana przez usługę kodeków.

    adb root
adb remount
adb reboot
adb wait-for-device
adb root
adb remount
adb
push /out/target/<...>/lib64/sample-codec2-filter-plugin.so \

/vendor/lib64/libc2filterplugin.so
adb push
/out/target/<...>/lib/sample-codec2-filter-plugin.so \

/vendor/lib/libc2filterplugin.so
adb reboot