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. Na urządzeniach z obsługiwaną konwersją multimediów Android może automatycznie przekształcać filmy (o długości do 1 minuty) nagrane w formatach takich jak HEVC czy HDR, gdy są otwierane przez aplikację, która nie obsługuje danego 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 frameworku multimediów: te usługi konwertują pliki z jednego formatu na inny, korzystając z komponentów sprzętowych, aby zapewnić niskie opóźnienie i wysoką jakość konwersji. Obejmuje to interfejs API do transkodowania, usługę transkodowania, wtyczkę OEM do filtrów niestandardowych i 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 jest wymagane specjalne działanie. Jeśli aplikacja nie obsługuje formatu, framework konwertuje plik na starszy format, np. AVC, gdy aplikacja uzyska do niego dostęp.

Ilustracja 1 przedstawia proces transkodowania multimediów.

Proces transkodowania zgodnych multimediów

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

Obsługiwane formaty

Funkcja transkodowania zgodnych multimediów obsługuje te formaty konwersji:

  • HEVC (8-bit) na AVC: konwersje kodeków są wykonywane przez połączenie jednego dekodera mediacodec i jednego 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. Ta funkcja nie obsługuje multimediów na pamięci dodatkowej. Treści przekazywane na urządzenia za pomocą poczty e-mail lub kart 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 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 w arkuszu udostępniania systemu operacyjnego. (tylko identyfikator URI MediaStore)
    • Przenoszenie plików MTP/PTP z telefonu na komputer

  • Transkodowanie pomijane:

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

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

Producenci urządzeń mogą opcjonalnie dodawać ścieżki plików do transkodowania multimediów w katalogu DCIM/. Wszystkie ścieżki spoza katalogu DCIM/ są odrzucane. Dodanie takich ścieżek 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 do 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:

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

Przegląd architektury

W tej sekcji opisaliśmy 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:

  • Systemowy interfejs MediaTranscodingManager API: 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 została zbudowana na podstawie frameworku multimedialnego NDK, aby była 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 sprawdzanie operacji na plikach w przestrzeni użytkownika i ograniczanie dostępu do plików na podstawie zasad zezwalających, odmawiających lub ograniczających dostęp.

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 formatu, plik jest przekodowany na starszy format (np. AVC) lub zwrócony z pamięci podręcznej, jeśli dostępna jest przekodowana 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 określi 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 Oświadczenie możliwości w zasobie i Oświadczenie możliwości w kodzie.
  • Dodaj aplikacje do listy wymuszania transkodowania, która jest zawarta 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 lub usunięcia z listy wymuszonych transkodowania. W tym celu przesyłają poprawkę lub zgłaszają błąd. Zespół Androida okresowo sprawdza listę i może usuwać z niej aplikacje.
  • Wyłączanie obsługiwanych formatów za pomocą ramy zgodności aplikacji w czasie wykonywania (użytkownicy mogą też wyłączyć to 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 przez USB (z urządzenia na komputer) kodowanie jest domyślnie wyłączone, ale użytkownicy mogą je włączyć, przełączając przełącznik Konwertuj filmy na AVC na ekranie ustawień Ustawienia USB, jak pokazano na rysunku 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 zapobiec blokowaniu zasobów systemowych przez żądania transkodowania przez dłuższy czas, aplikacje proszące o sesje transkodowania są ograniczone do:

  • 10 kolejnych sesji
  • łączny czas trwania reklamy wynoszący 3 minuty.

Jeśli aplikacja przekracza wszystkie te ograniczenia, platforma zwraca pierwotny opis pliku.

Wymagania dotyczące urządzeń

Aby obsługiwać funkcję transkodowania zgodnych 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 konwersję HDR na SDR) urządzenie obsługuje nagrywanie wideo HDR

Aby zapewnić wydajność urządzenia w przypadku transkodowania multimediów, należy zoptymalizować wydajność odczytu/zapisu sprzętu i pamięci wideo. Gdy skonfigurujesz kodeki multimediów z priorytetem równym 1, kodeki muszą działać z największą możliwą przepustowością. Zalecamy, aby wydajność transkodowania osiągała co najmniej 200 fps. 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łączanie globalnego transkodowania multimediów

Aby przetestować działanie platformy transkodowania multimediów lub działania aplikacji za pomocą transkodowania, możesz włączyć lub wyłączyć zgodne funkcje 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 ADB w powłoce, aby sprawdzić stan transkodowania, w tym bieżące i przeszłe sesje transkodowania:

adb shell dumpsys media.transcoding

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

W celu przetestowania możesz wydłużyć limit długości transkodowania do 1 minuty, używając tego polecenia. Po wykonaniu tego polecenia może być konieczne ponowne uruchomienie.

adb shell device_config put storage_native_boot transcode_max_duration_ms <LARGE_NUMBER_IN_MS>

Źródło i odwołania do AOSP

Poniżej znajdziesz kod źródłowy AOSP dotyczący zgodnego transkodowania 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 opisaliśmy, jak działa wtyczka filtra, jak ją zaimplementować 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 Codec 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 zawiera mechanizm opakowywania, który łączy dekodery z wtyczkami filtra. MediaCodecrozpoznaje te spakowane komponenty jako dekodery z funkcjami filtrowania.

Omówienie

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 zapisuje dostępne filtry z plugina. Podczas tworzenia FilterWrapper inicjuje wszystkie dostępne filtry. Tylko filtry, które zmieniają bufor, są uruchamiane na początku.

Filtruj architekturę wtyczki

Rysunek 1. Architektura wtyczki filtra.

Filtruj interfejs wtyczki

Interfejs FilterPlugin.h definiuje te interfejsy API, które udostępniają filtry:

  • std::shared_ptr<C2ComponentStore>getComponentStore()

    Zwraca obiekt C2ComponentStore zawierający filtry. Jest to osobna implementacja niż ta, którą udostępnia dostawca w ramach Codec 2.0. 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, które kontrolują działanie filtrów. Na przykład w przypadku przekształcenia tonalnego HDR na SDR parametrem kontrolnym jest docelowa funkcja transferu.
    • affectedParams: parametry, na które mają wpływ operacje filtrowania. Na przykład w przypadku mapowania tonów 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

Zawiniowany komponent instancjuje podstawowy dekoder i wszystkie zdefiniowane filtry podczas tworzenia.

Zapytanie i konfiguracja

Owinięty komponent oddziela przychodzące parametry 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.

Rozpocznij

Na początku opakowany komponent uruchamia dekoder i wszystkie filtry, które modyfikują bufory. Jeśli nie ma włączonego filtra, opakowany komponent uruchamia dekoder i bufory przekazu dalej oraz wysyła polecenia do samego dekodera.

Obsługa bufora

Obsługa bufora

Rysunek 3. Obsługa bufora.

Bufory umieszczone w kolejce do zawiniętego dekodera trafiają do podstawowego 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. Ostatni bufor wyjściowy z ostatniego filtra jest przekazywany do klienta.

Aby ta obsługa bufora działała, opakowany komponent musi skonfigurować C2PortBlockPoolsTuning do ostatniego filtra, aby dane wyjściowe frameworka mogły korzystać z buforów z oczekiwanego puli bloków.

Zatrzymywanie, resetowanie i zwalnianie

Po zatrzymaniu opakowany komponent zatrzymuje dekoder i wszystkie włączone filtry, które zostały uruchomione. Podczas resetowania i zwalniania 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. W bibliotece zaimplementuj interfejs FilterPlugin i umieść go w miejscu /vendor/lib[64]/libc2filterplugin.so..
  2. W razie potrzeby dodaj do mediacodec.te dodatkowe uprawnienia.
  3. Zaktualizuj warstwę adaptacji do Androida 12 i ponownie utwórz usługę media.c2.

Testowanie wtyczki

Aby przetestować przykładowy wtyczkę:

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

  2. Utwórz kompilację przykładowego wtyczka za pomocą tego polecenia:

    m sample-codec2-filter-plugin

  3. Ponownie zamontuj urządzenie i zmień nazwę wtyczki dostawcy, aby była rozpoznawana przez usługę kodeka.

    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