Zgodne transkodowanie multimediów

Zgodne transkodowanie multimediów, wprowadzone w Androidzie 12, to funkcja, która umożliwia urządzeniom używanie nowocześniejszych i 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ć kodeka HEVC zamiast AVC, aby poprawić jakość wideo przy jednoczesnym zmniejszeniu wymagań dotyczących pamięci i przepustowości. Na urządzeniach 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, gdy są one otwierane przez aplikację, która nie obsługuje tego formatu. Dzięki temu aplikacje będą 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 w artykule Transkodowanie zgodnych multimediów na stronie 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, aby zapewnić niskie opóźnienia i wysoką jakość konwersji. Obejmuje to interfejs Transcoding API, usługę transkodowania, wtyczkę OEM do filtrów niestandardowych i sprzęt. Więcej informacji znajdziesz w omówieniu architektury.
  • Funkcja transkodowania zgodnych multimediów w aplikacjach dostawców multimediów: ten komponent w aplikacjach dostawców multimediów 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 mediacodec.
  • 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, które są przechowywane w folderze DCIM/Camera/ na 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, 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
    • przesyłanie plików między urządzeniami 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 dodać ścieżki do plików do transkodowania multimediów w katalogu DCIM/. Wszystkie ścieżki poza katalogiem DCIM/ są odrzucane. Dodanie takich ścieżek plików może być wymagane, aby spełnić wymagania operatora 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:

  • Systemowy interfejs API MediaTranscodingManager: interfejs, który umożliwia klientowi komunikację z usługą MediaTranscoding. Z tego interfejsu API korzysta moduł MediaProvider.
  • 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

Transkodowanie zgodnych multimediów jest oparte na systemie plików FUSE (Filesystem in Userspace), który jest używany w przypadku ograniczonego dostępu do miejsca na dane. 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ą przesyłać prośby o transkodowane komponenty, korzystając z tych opcji:

  • Zadeklaruj nieobsługiwane formaty w pliku manifestu. Więcej informacji znajdziesz w sekcjach Deklarowanie funkcji w zasobie i Deklarowanie funkcji w kodzie.
  • Wyłączanie obsługiwanych formatów za pomocą systemu sprawdzania zgodności aplikacji w czasie działania (użytkownicy mogą też wyłączyć tę funkcję w ustawieniach każdej aplikacji).
  • Otwieranie pliku za pomocą MediaStore z wyraźnym określeniem nieobsługiwanych formatów 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ć za pomocą przełącznika Konwertuj filmy na AVC na ekranie ustawień Ustawienia USB, jak pokazano na ilustracji 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 kolejnych sesji
  • łą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 oraz odczytu i zapisu w pamięci. 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 kl./s. Aby przetestować wydajność sprzętu, uruchom test porównawczy transkodera multimediów na stronie frameworks/av/media/libmediatranscoding/transcoder/benchmark.

Walidacja

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 działanie aplikacji z transkodowaniem, możesz globalnie włączyć lub wyłączyć funkcję transkodowania zgodnych multimediów. 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

Zwiększanie limitu długości wideo

Na potrzeby testów możesz wydłużyć ograniczenie długości wideo 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. MediaCodecrozpoznaje te komponenty jako dekodery z funkcjami filtrowania.

Przegląd

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. Na początku uruchamiane są tylko filtry, które zmieniają bufor.

Architektura wtyczki filtra

Rysunek 4. Architektura wtyczki filtra.

Interfejs wtyczki filtra

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 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 przenoszenia.
    • affectedParams: parametry, na które ma wpływ 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.

Utworzenie

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

Zapytanie i konfiguracja

Komponent opakowujący oddziela przychodzące parametry od zapytań lub żądań konfiguracji zgodnie z opisem filtra. Na przykład konfiguracja parametru kontroli filtra jest kierowana do odpowiedniego filtra, a parametry z filtrów, na które ma wpływ, są obecne w zapytaniach (zamiast odczytywać 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, opakowany komponent 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 zgłaszany końcowy bufor wyjściowy z ostatniego filtra.

Aby to buforowanie działało, opakowany komponent musi skonfigurować C2PortBlockPoolsTuning jako ostatni filtr, tak aby bufor wyjściowy platformy pochodził z oczekiwanego bloku pamięci.

Zatrzymaj, zresetuj i zwolnij

Po zatrzymaniu komponentu opakowanego 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.

Wdrażanie 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. Zbuduj 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