Transkodowanie zgodnych multimediów

Zgodny z standardem kodowanie multimediów, wprowadzone w Androidzie 12, to funkcja, która umożliwia urządzeniom korzystanie z nowocześniejszych formatów multimediów, takich jak HEVC, do rejestrowania filmów, przy jednoczesnym 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 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 będą działać nawet wtedy, gdy filmy są rejestrowane w nowszych formatach na urządzeniu.

Funkcja transkodowania zgodnych multimediów jest domyślnie wyłączona. Aby żądać transkodowania multimediów, aplikacje muszą zadeklarować swoje możliwości multimedialne. Więcej informacji o deklarowaniu obsługi multimediów znajdziesz na stronie dla deweloperów aplikacji na Androida w sekcji Zgodny z transkodowaniem multimediów.

Jak to działa

Funkcja transkodowania zgodnych 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óźnienia 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.
  • Obsługa konwersji kodowania multimediów w dostawcach multimediów: ten komponent w dostawcach multimediów przechwytuje aplikacje uzyskujące dostęp do plików multimedialnych i przekazuje albo oryginalny plik, albo plik przekonwertowany na podstawie 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.

Rysunek 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 formaty konwersji:

  • HEVC (8-bit) na AVC: konwersje kodeków są wykonywane przez połączenie jednego dekodera mediacodec i jednego enkodera mediacode.
  • HDR10+ (10-bit) na AVC (SDR): konwersje HDR na SDR są wykonywane za pomocą instancji mediacodec i wtyczki dostawcy wbudowanej w dekoder. Więcej informacji znajdziesz w artykule Kodowanie HDR na SDR.

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

Obsługiwana funkcja transkodowania multimediów obsługuje multimedia na urządzeniu wygenerowane przez natywną aplikację OEM do obsługi aparatu, która jest przechowywana 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 plików. Poniżej opisaliśmy ścieżki plików, w przypadku których transkodowanie jest włączone lub pomijane:

  • Transkodowanie włączone:

    • Dostęp aplikacji przez interfejsy MediaStore API
    • Dostęp aplikacji przez interfejsy API bezpośrednich ścieżek plików, w tym Java i kod natywny
    • Dostęp aplikacji za pomocą interfejsu Storage Access Framework (SAF)
    • Dostęp aplikacji przez intencje arkusza 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 do transkodowania

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

Aby dodać ścieżkę do pliku, użyj ścieżki transkodowania nakładki zasobów w czasie wykonywania (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.

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 umożliwiający klientowi komunikację z usługą MediaTranscoding. Ten interfejs API jest używany przez moduł MediaProvider.
  • MediaTranscodingService: usługa natywnych funkcji, która zarządza połączeniami klienta, planuje prośby o transkodowanie i zarządza księgowością w TranscodingSessions.
  • MediaTranscoder: natywna biblioteka, która przeprowadza transkodowanie. Ta biblioteka została zbudowana na podstawie NDK frameworku multimedialnego, aby była zgodna z modułami.

Funkcja zgodnego transkodowania multimediów rejestruje dane dotyczące transkodowania zarówno w usłudze, jak i w transkodowanym pliku. Kod po stronie klienta i po stronie usługi znajduje się w module MediaProvider, aby umożliwić terminowe naprawi i aktualizacje błędów.

Dostęp do plików

Obsługa kodowania multimediów jest zgodna z systemem plików FUSE, który jest używany do ograniczonego przechowywania. 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 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 przekodowany na starszy format (np. AVC) lub zwrócony z pamięci podręcznej, jeśli dostępna jest przetranskodowana wersja.

Prośba o pliki potranskodowane

Funkcja zgodnego transkodowania 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ą żądać transkodowanych komponentów za pomocą tych opcji:

  • deklarowanie nieobsługiwanych formatów w pliku manifestu, Więcej informacji znajdziesz w artykułach Oświadczenie o możliwościach w zasobach i Oświadczenie o możliwościach w kodzie.
  • Dodaj aplikacje do listy wymuszania transkodowania, która jest zawarta w module MediaProvider. Umożliwia to transkodowanie w przypadku aplikacji, które nie zaktualizowały pliku manifestu. Gdy aplikacja zaktualizuje plik manifestu, dodając do niego nieobsługiwane formaty, musi zostać usunięta z listy wymuszania transkodowania. Producenci urządzeń mogą zgłaszać aplikacje do dodania lub usunięcia z listy wymuszania transkodowania, przesyłając poprawkę lub zgłaszając 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ą MediaStore, wyraźnie 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 plików z transkodowaniem

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 treści wynoszący 3 minuty.

Jeśli aplikacja przekracza wszystkie te ograniczenia, framework zwraca pierwotny deskryptor pliku.

Wymagania dotyczące urządzeń

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

  • Kodowanie HEVC jest domyślnie włączone w natywnej aplikacji aparatu
  • (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 do obsługi wideo i pamięci. Gdy kodery multimediów są skonfigurowane z priorytetem 1, muszą działać z najwyższą możliwą przepustowością. Zalecamy, aby wydajność kodowania osiągała co najmniej 200 fps. Aby przetestować wydajność sprzętu, uruchom test porównawczy przetwornika mediów na stronie frameworks/av/media/libmediatranscoding/transcoder/benchmark.

Weryfikacja

Aby zweryfikować kompatybilną funkcję transkodowania multimediów, uruchom te testy CTS:

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

Włączanie globalnego transkodowania multimediów

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

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 limitu 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 znajduje się kod źródłowy AOSP dotyczący zgodnego transkodowania multimediów.

Kodowanie HDR na SDR

Aby obsługiwać kodowanie HDR na SDR, producenci urządzeń mogą korzystać z próbnego filtra Codec 2.0 w AOSP, który znajduje się w folderze /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 zawiera wtyczki obsługującej kodowanie HDR na SDR, aplikacja uzyskująca dostęp do filmu HDR otrzymuje pierwotny opis pliku niezależnie od możliwości multimediów 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 implementację warstwy adaptacji między interfejsem Codec 2.0 a interfejsem android.hardware.media.c2 HAL w 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 przyjmuje kodeki dostawcy i zwraca zapakowane kodeki z powrotem do warstwy adaptacji media.c2. Klasa FilterWrapper wczytuje libc2filterplugin.so za pomocą interfejsu API FilterWrapper::Plugin i zapisuje dostępne filtry z plugina. Podczas tworzenia FilterWrapper instancjował 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, 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. Zazwyczaj ten magazyn zawiera tylko filtry używane przez klasę FilterWrapper.

  • bool describe(C2String name, Descriptor *desc)

    Opisuje filtry dostępne oprócz tych dostępnych w C2ComponentStore. Definiowane są następujące 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 wpływają operacje filtrowania. Na przykład w przypadku przekształcenia tonalnego HDR na SDR parametry, których dotyczy zmiana, to aspekty koloru.

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

    Zwraca true, jeśli element filtra zmienia bufor. Na przykład filtr mapowania odcieni zwraca true, jeśli docelową funkcją transferu jest SDR, a funkcja transferu wejściowego to HDR (HLG lub PQ).

Szczegóły obiektu FilterWrapper

Sekcja zawiera szczegółowe informacje o klasie 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 sterowania filtrem jest kierowana do odpowiedniego filtra, a parametry, na które ma wpływ, są obecne w zapytaniach (zamiast odczytywania z dekodera, który ma nieuwzględnione parametry).

Zapytanie i konfiguracja

Rysunek 5. Zapytanie i konfiguracja.

Rozpocznij

Na początku opakowany komponent uruchamia dekoder i wszystkie filtry, które zmieniają 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 6. Obsługa bufora.

Bufory umieszczone w kolejce do zawiniętego dekodera trafiają do podstawowego dekodera. Owinięty komponent pobiera bufor wyjściowy z dekodera za pomocą wywołania zwrotnego 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 frameworku mogły korzystać z buforów z oczekiwanego puli bloków.

Zatrzymywanie, resetowanie i zwalnianie

Podczas zatrzymania owiniętego komponentu dekoder i wszystkie włączone filtry, które zostały uruchomione, są zatrzymywane. Podczas resetowania i odblokowywania wszystkie komponenty są resetowane lub odblokowywane niezależnie od tego, czy są włączone.

Implementacja przykładowej wtyczki filtra

Aby włączyć wtyczkę:

  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 skompiluj usługę media.c2.

Testowanie wtyczki

Aby przetestować przykładowy wtyczkę:

  1. Odbuduj i sflashuj urządzenie.

  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