Zgodne transkodowanie multimediów

Kompatybilne transkodowanie multimediów, wprowadzone w Androidzie 12, to funkcja, która umożliwia urządzeniom używanie nowocześniejszych, bardziej wydajnych formatów multimediów do nagrywania filmów, takich jak 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 przy jednoczesnym zmniejszeniu wymagań dotyczących pamięci i przepustowości. W przypadku urządzeń z włączonym kompatybilnym transkodowaniem multimediów Android może automatycznie konwertować filmy (o długości do minuty) nagrane w formatach takich jak HEVC lub HDR, gdy są one otwierane przez aplikację, która nie obsługuje tego formatu. Dzięki temu aplikacje mogą działać nawet wtedy, gdy filmy są nagrywane na urządzeniu w nowszych formatach.

Funkcja transkodowania zgodnych multimediów jest domyślnie wyłączona. Aby poprosić o transkodowanie multimediów, aplikacje muszą zadeklarować swoje możliwości w zakresie multimediów. Więcej informacji o deklarowaniu możliwości multimedialnych znajdziesz na stronie Zgodne transkodowanie multimediów w witrynie dla deweloperów aplikacji na Androida.

Jak to działa

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

  • Usługi transkodowania w ramach multimediów: te usługi konwertują pliki z jednego formatu na inny za pomocą sprzętu, co zapewnia niskie opóźnienia i wysoką jakość konwersji. Obejmuje to interfejs API transkodowania, usługę transkodowania, wtyczkę OEM do filtrów niestandardowych i sprzęt. Więcej informacji znajdziesz w omówieniu architektury.
  • Funkcja transkodowania multimediów w usługach multimedialnych: ten komponent w usługach multimedialnych przechwytuje aplikacje uzyskujące dostęp do plików multimedialnych i udostępnia oryginalny lub transkodowany plik na podstawie zadeklarowanych możliwości aplikacji. Jeśli aplikacja obsługuje format pliku multimedialnego, nie jest wymagana żadna specjalna obsługa. Jeśli aplikacja nie obsługuje danego formatu, framework przekonwertuje plik na starszy format, np. AVC, gdy aplikacja uzyska do niego dostęp.

Ilustracja 1 przedstawia omówienie procesu 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 konwersje formatów:

  • HEVC (8-bit) na AVC: konwersje kodeków są przeprowadzane przez połączenie jednego dekodera mediacodec i jednego enkodera mediacode.
  • HDR10+ (10-bitowy) do AVC (SDR): konwersje HDR do SDR są przeprowadzane przy użyciu instancji mediacodec i wtyczki dostawcy podłączonej do instancji dekodera. Więcej informacji znajdziesz w artykule Kodowanie HDR do SDR.

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

Funkcja transkodowania zgodnych multimediów obsługuje multimedia wygenerowane na urządzeniu przez natywną aplikację aparatu OEM i przechowywane w folderze DCIM/Camera/ na podstawowym 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, w których transkodowanie jest włączone lub pomijane:

  • Transkodowanie włączone:

    • Dostęp aplikacji za pomocą interfejsów MediaStore API
    • Dostęp do aplikacji za pomocą interfejsów API bezpośredniej ścieżki do pliku, w tym kodu Java i kodu natywnego
    • Dostęp aplikacji za pomocą Storage Access Framework (SAF)
    • Dostęp do aplikacji za pomocą intencji arkusza udostępniania systemu operacyjnego. (Tylko identyfikator URI MediaStore)
    • Przesyłanie plików z telefonu na komputer za pomocą protokołu MTP/PTP

  • Transkodowanie pominięte:

    • Przenoszenie plików 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 do plików na potrzeby transkodowania

Producenci urządzeń mogą opcjonalnie dodawać ścieżki do 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, aby spełnić wymagania przewoźnika lub lokalne przepisy.

Aby dodać ścieżkę pliku, użyj ścieżki transkodowania nakładki zasobu ś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 do plików, użyj tego 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 opisujemy architekturę funkcji transkodowania multimediów.

media-transcoding-architecture

Rysunek 2. Architektura transkodowania multimediów.

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

  • Interfejs API systemu MediaTranscodingManager: interfejs, który umożliwia klientowi komunikację z usługą MediaTranscoding. Moduł MediaProvider korzysta z tego interfejsu API.
  • MediaTranscodingService: natywna usługa, która zarządza połączeniami klientów, planuje żądania transkodowania i prowadzi księgowość dla TranscodingSessions.
  • MediaTranscoder: biblioteka natywna, która wykonuje transkodowanie. Ta biblioteka jest oparta na platformie multimedialnej NDK, dzięki czemu jest zgodna z modułami.

Funkcja transkodowania zgodnych multimediów rejestruje wskaźniki transkodowania zarówno w usłudze, jak i w transkoderze multimediów. Kod po stronie klienta i po stronie usługi znajduje się w module MediaProvider, co umożliwia szybkie wprowadzanie poprawek i aktualizacji.

Dostęp do plików

Zgodne transkodowanie multimediów jest oparte na systemie plików FUSE (Filesystem in Userspace), który jest używany w przypadku pamięci o ograniczonym 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 na dostęp, odmawiających go lub redagujących go.

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

Prośba o przekodowane pliki

Funkcja transkodowania zgodnych multimediów jest domyślnie wyłączona. Aplikacje mogą prosić o transkodowane komponenty, korzystając z tych opcji:

  • Zadeklaruj nieobsługiwane formaty w pliku manifestu. Szczegółowe informacje znajdziesz w sekcjach Deklarowanie funkcji w zasobie i Deklarowanie funkcji w kodzie.
  • Wyłączanie obsługiwanych formatów za pomocą platformy zgodności aplikacji w czasie działania (użytkownicy mogą też wyłączyć tę funkcję w przypadku każdej aplikacji w Ustawieniach).
  • Otwórz plik za pomocą MediaStore, wyraźnie określając nieobsługiwane formaty za pomocą interfejsu openTypedAssetFileDescriptor.

W przypadku przesyłania przez USB (z urządzenia na komputer) transkodowanie jest domyślnie wyłączone, ale użytkownicy mogą je włączyć, korzystając z przełącznika Konwertuj filmy na AVC na ekranie ustawień Ustawienia USB, jak pokazano na rysunku 3.

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

Rysunek 3. Włącz transkodowanie multimediów na ekranie Ustawienia USB.

Ograniczenia dotyczące przesyłania próśb o przekodowane pliki

Aby zapobiec blokowaniu zasobów systemowych przez żądania transkodowania przez dłuższy czas, aplikacje żądające sesji transkodowania są ograniczone do:

  • 10 sesji z rzędu
  • łączny czas trwania 3 minuty,

Jeśli aplikacja przekroczy wszystkie te ograniczenia, platforma zwróci oryginalny deskryptor pliku.

Wymagania dotyczące urządzeń

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

  • Urządzenie ma domyślnie włączone kodowanie HEVC w natywnej aplikacji aparatu.
  • (Urządzenia obsługujące transkodowanie HDR do SDR) Urządzenie obsługuje nagrywanie filmów w HDR

Aby zapewnić wydajność urządzenia podczas transkodowania multimediów, należy zoptymalizować wydajność sprzętu wideo i pamięci w zakresie odczytu i zapisu. Jeśli kodeki multimediów są skonfigurowane z priorytetem równym 1, muszą działać z najwyższą możliwą przepustowością. Zalecamy, aby wydajność transkodowania wynosiła co najmniej 200 klatek na sekundę. Aby przetestować wydajność sprzętu, uruchom test porównawczy transkodera multimediów na stronie frameworks/av/media/libmediatranscoding/transcoder/benchmark.

Weryfikacja

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

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

Włączanie transkodowania multimediów na całym świecie

Aby przetestować platformę transkodowania multimediów lub zachowanie aplikacji z transkodowaniem, możesz włączyć lub wyłączyć funkcję transkodowania zgodnych multimediów globalnie. Na stronie opcji programisty Ustawienia > System > Programista > Transkodowanie multimediów ustaw przełącznik Zastąp domyślne ustawienia transkodowania w pozycji włączony, a następnie ustaw przełącznik Włącz transkodowanie w pozycji włączony lub wyłączony. Jeśli to ustawienie jest włączone, transkodowanie multimediów może odbywać się w tle w przypadku aplikacji innych niż ta, którą tworzysz.

Sprawdzanie stanu transkodowania

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

adb shell dumpsys media.transcoding

Wydłużanie limitu długości filmu

Na potrzeby testów możesz wydłużyć ograniczenie długości filmu do 1 minuty w przypadku transkodowania, używając tego polecenia. Po uruchomieniu 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 odniesienia AOSP

Poniżej znajdziesz kod źródłowy AOSP związany z transkodowaniem zgodnych multimediów.

Kodowanie HDR do SDR

Aby obsługiwać kodowanie HDR do SDR, producenci urządzeń mogą używać przykładowej wtyczki filtra Codec 2.0 AOSP znajdującej się 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 zawiera wtyczki obsługującej kodowanie HDR do SDR, aplikacja uzyskująca dostęp do filmu HDR otrzymuje oryginalny deskryptor pliku niezależnie od możliwości multimedialnych aplikacji zadeklarowanych w pliku manifestu.

Jak to działa

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

Tło

Android udostępnia warstwę adaptacyjną między interfejsem Codec 2.0 a interfejsem android.hardware.media.c2 HAL w android::hardware::media::c2. W przypadku wtyczek filtrów AOSP zawiera mechanizm otoki, który łączy dekodery z wtyczkami filtrów. MediaCodec rozpoznaje te komponenty jako dekodery z funkcjami filtrowania.

Omówienie

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

Architektura wtyczki filtra

Rysunek 4. Architektura wtyczki filtra.

Interfejs wtyczki filtra

Interfejs FilterPlugin.h definiuje te interfejsy API, aby udostępniać filtry:

  • std::shared_ptr<C2ComponentStore>getComponentStore()

    Zwraca obiekt C2ComponentStore zawierający filtry. Jest to niezależne od tego, co udostępnia implementacja Codec 2.0 dostawcy. Zwykle ten magazyn zawiera tylko filtry używane przez klasę FilterWrapper.

  • bool describe(C2String name, Descriptor *desc)

    Opisuje filtry oprócz tych, które są dostępne w C2ComponentStore. Zdefiniowano te opisy:

    • controlParam: parametry, które kontrolują działanie filtrów. Na przykład w przypadku mapowania tonów z HDR na SDR parametrem sterującym jest docelowa funkcja transferu.
    • affectedParams: Parametry, na które wpływa filtrowanie. Na przykład w przypadku mapowania tonów z HDR na SDR parametrami, których dotyczy problem, są aspekty kolorów.

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

    Zwraca wartość true, jeśli komponent filtra zmienia bufor. Na przykład filtr mapowania tonów zwraca true, jeśli docelowa funkcja transferu to SDR, a wejściowa funkcja transferu to HDR (HLG lub PQ).

Szczegóły FilterWrapper

W tej sekcji znajdziesz szczegółowe informacje o klasie FilterWrapper.

na podstawie trendów

Komponent opakowujący tworzy instancję dekodera bazowego i wszystkich zdefiniowanych filtrów podczas tworzenia.

Zapytanie i konfiguracja

Komponent opakowujący oddziela parametry przychodzące od zapytań lub żądań konfiguracji zgodnie z opisem filtra. Na przykład konfiguracja parametru kontroli filtra jest kierowana do odpowiedniego filtra, a parametry, na które filtry mają wpływ, są obecne w zapytaniach (zamiast odczytywać je z dekodera, który ma parametry bez wpływu).

Zapytanie i konfiguracja

Rysunek 5. Zapytanie i konfiguracja.

Rozpocznij

Na początku komponent opakowany uruchamia dekoder i wszystkie filtry, które zmieniają bufory. Jeśli żaden filtr nie jest włączony, komponent opakowany uruchamia dekoder i bufory przesyłania oraz wysyła polecenia do samego dekodera.

Obsługa bufora

Obsługa bufora

Rysunek 6. Obsługa bufora.

Bufory umieszczone w kolejce dekodera opakowującego są przekazywane do dekodera bazowego. Komponent opakowany pobiera bufor wyjściowy z dekodera za pomocą wywołania zwrotnego onWorkDone_nb(), a następnie umieszcza go w kolejce filtrów. Do klienta jest przesyłany końcowy bufor wyjściowy z ostatniego filtra.

Aby to buforowanie działało, komponent opakowany musi skonfigurować C2PortBlockPoolsTuning do ostatniego filtra, tak aby bufor wyjściowy frameworka pochodził z oczekiwanego bloku pamięci.

Zatrzymaj, zresetuj i zwolnij

Po zatrzymaniu komponentu opakowującego dekoder i wszystkie włączone filtry, które zostały uruchomione, zostaną zatrzymane. Podczas resetowania i zwalniania wszystkie komponenty są resetowane lub zwalniane niezależnie od tego, czy są włączone.

Implementowanie przykładowej wtyczki filtra

Aby włączyć wtyczkę:

  1. Zaimplementuj interfejs FilterPlugin w bibliotece i umieść go w /vendor/lib[64]/libc2filterplugin.so..
  2. W razie potrzeby dodaj do mediacodec.te dodatkowe uprawnienia.
  3. Zaktualizuj warstwę adaptacji do Androida 12 i ponownie skompiluj usługę media.c2.

Testowanie wtyczki

Aby przetestować przykładową wtyczkę:

  1. Ponownie skompiluj i wgraj oprogramowanie na urządzenie.

  2. Skompiluj przykładową wtyczkę za pomocą tego polecenia:

    m sample-codec2-filter-plugin

  3. Zamontuj ponownie 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