Transcodierung in kompatibles Medienformat

Die in Android 12 eingeführte kompatible Medientranscodierung ist eine Funktion, mit der Geräte modernere, speichereffizientere Medienformate für die Videoaufnahme verwenden können, z. B. HEVC, ohne die Kompatibilität mit Apps zu beeinträchtigen. Mit dieser Funktion können Gerätehersteller HEVC anstelle von AVC als Standard verwenden, um die Videoqualität zu verbessern und gleichzeitig die Speicher- und Bandbreitenanforderungen zu senken. Auf Geräten, auf denen die Media-Transcodierung aktiviert ist, kann Android Videos (bis zu einer Minute Länge), die in Formaten wie HEVC oder HDR aufgenommen wurden, automatisch konvertieren, wenn sie von einer App geöffnet werden, die das Format nicht unterstützt. So können Apps auch dann funktionieren, wenn Videos auf dem Gerät in neueren Formaten aufgenommen werden.

Die Funktion zur Transcodierung in kompatibles Medienformat ist standardmäßig deaktiviert. Wenn Apps eine Media-Transcodierung anfordern möchten, müssen sie ihre Media-Funktionen deklarieren. Weitere Informationen zum Deklarieren von Media-Funktionen finden Sie auf der Website für Android-Entwickler unter Kompatible Media-Transcodierung.

Funktionsweise

Die Funktion zum Transcodieren kompatibler Medien besteht aus zwei Hauptteilen:

  • Transcodierungsdienste im Media Framework:Mit diesen Diensten werden Dateien mithilfe von Hardware in ein anderes Format konvertiert. Das Ergebnis ist eine geringe Latenz und eine hohe Qualität. Dazu gehören die Transcoding API, der Transcoding-Dienst, ein OEM-Plug-in für benutzerdefinierte Filter und Hardware. Weitere Informationen finden Sie unter Architekturübersicht.
  • Funktion zum Transcodieren kompatibler Medien in Media-Providern:Diese Komponente in Media-Providern fängt Apps ab, die auf Mediendateien zugreifen, und stellt entweder die Originaldatei oder eine transcodierte Datei bereit, je nachdem, welche Funktionen die App deklariert hat. Wenn eine App das Format der Mediendatei unterstützt, ist keine spezielle Verarbeitung erforderlich. Wenn eine App das Format nicht unterstützt, konvertiert das Framework die Datei in ein älteres Format wie AVC, wenn die App auf die Datei zugreift.

Abbildung 1 zeigt eine Übersicht über den Medientranscodierungsprozess.

Transcodierung in kompatibles Medienformat

Abbildung 1: Übersicht über die Transcodierung in kompatibles Medienformat.

Unterstützte Formate

Die Funktion zur kompatiblen Media-Transcodierung unterstützt die folgenden Formatkonvertierungen:

  • HEVC (8 Bit) zu AVC:Codec-Konvertierungen werden durch Verbinden eines MediaCodec-Decoders und eines MediaCodec-Encoders durchgeführt.
  • HDR10+ (10‑Bit) zu AVC (SDR): HDR‑zu‑SDR-Konvertierungen werden mit mediacodec-Instanzen und einem Anbieter-Plugin-Hook in den Decoder-Instanzen durchgeführt. Weitere Informationen finden Sie unter HDR-zu-SDR-Codierung.

Unterstützte Inhaltsquellen

Die Funktion zum Transkodieren kompatibler Medien unterstützt Medien, die auf dem Gerät von der nativen OEM-Kamera-App generiert und im Ordner DCIM/Camera/ auf dem primären externen Volume gespeichert werden. Die Funktion unterstützt keine Medien auf sekundärem Speicher. Inhalte, die per E-Mail oder SD-Karte an Geräte gesendet werden, werden nicht unterstützt.

Apps greifen über verschiedene Dateipfade auf die Dateien zu. Im Folgenden werden die Dateipfade beschrieben, in denen das Transcodieren aktiviert oder umgangen wird:

  • Transcodierung aktiviert:

    • App-Zugriff über MediaStore APIs
    • App-Zugriff über APIs für direkte Dateipfade, einschließlich Java- und nativem Code
    • App-Zugriff über das Storage Access Framework (SAF)
    • App-Zugriff über die Intents des Betriebssystem-Share-Sheets. (nur MediaStore-URI)
    • MTP-/PTP-Dateiübertragung vom Smartphone auf den PC

  • Transcodierung umgangen:

    • Dateien von einem Gerät übertragen, indem die SD-Karte ausgeworfen wird
    • Dateien mit Optionen wie Nearby Share oder Bluetooth-Übertragung von Gerät zu Gerät übertragen.

Benutzerdefinierte Dateipfade für die Transcodierung hinzufügen

Gerätehersteller können optional Dateipfade für die Media-Transcodierung im Verzeichnis DCIM/ hinzufügen. Alle Pfade außerhalb des Verzeichnisses DCIM/ werden abgelehnt. Das Hinzufügen solcher Dateipfade kann erforderlich sein, um die Anforderungen von Mobilfunkanbietern oder lokale Vorschriften zu erfüllen.

Wenn Sie einen Dateipfad hinzufügen möchten, verwenden Sie das RRO (Runtime Resource Overlay) für den Transcodierungspfad: config_supported_transcoding_relative_paths. Hier ein Beispiel für das Hinzufügen eines Dateipfads:

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

So prüfen Sie die konfigurierten Dateipfade:

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

Architekturübersicht

In diesem Abschnitt wird die Architektur der Funktion zur Medientranskodierung beschrieben.

media-transcoding-architecture

Abbildung 2: Architektur für die Medientranscodierung.

Die Architektur für die Medien-Transcodierung besteht aus den folgenden Komponenten:

  • System-API „MediaTranscodingManager“:Schnittstelle, über die der Client mit dem MediaTranscoding-Dienst kommunizieren kann. Das Modul MediaProvider verwendet diese API.
  • MediaTranscodingService:Nativer Dienst, der Clientverbindungen verwaltet, Transcodierungsanfragen plant und die Buchhaltung für TranscodingSessions verwaltet.
  • MediaTranscoder:Native Bibliothek, die die Transcodierung ausführt. Diese Bibliothek basiert auf dem Media Framework NDK, um mit Modulen kompatibel zu sein.

Bei der Transcodierung in kompatibles Medienformat werden Transcodierungsstatistiken sowohl im Dienst als auch im Medientranscoder protokolliert. Der clientseitige und der dienstseitige Code befinden sich im MediaProvider-Modul, um zeitnahe Fehlerkorrekturen und Updates zu ermöglichen.

Dateizugriff

Die kompatible Medientranscodierung basiert auf dem FUSE-Dateisystem (Filesystem in Userspace), das für den eingeschränkten Speicher verwendet wird. FUSE ermöglicht es dem MediaProvider-Modul, Dateivorgänge im Nutzerbereich zu untersuchen und den Zugriff auf Dateien basierend auf der Richtlinie zu steuern, um den Zugriff zuzulassen, zu verweigern oder zu entfernen.

Wenn eine App versucht, auf eine Datei zuzugreifen, fängt der FUSE-Daemon den Lesezugriff der App auf die Datei ab. Wenn die App ein neueres Format (z. B. HEVC) unterstützt, wird die Originaldatei zurückgegeben. Wenn die App das Format nicht unterstützt, wird die Datei in ein älteres Format (z. B. AVC) transcodiert oder aus dem Cache zurückgegeben, falls eine transcodierte Version verfügbar ist.

Transcodierte Dateien anfordern

Die Funktion zur Transcodierung in kompatibles Medienformat ist standardmäßig deaktiviert. Apps können transkodierte Assets mit den folgenden Optionen anfordern:

Bei USB-Übertragungen (Gerät zu PC) ist die Transcodierung standardmäßig deaktiviert. Nutzer können sie jedoch auf dem Einstellungsbildschirm USB-Einstellungen über den Schalter Videos in AVC konvertieren aktivieren (siehe Abbildung 3).

Ein/Aus-Schaltfläche zum Aktivieren der Medientranscodierung

Abbildung 3: Aktiviere die Option „Medientranscodierung“ auf dem Bildschirm „USB-Einstellungen“.

Einschränkungen beim Anfordern von transcodierten Dateien

Damit Transcodierungsanfragen Systemressourcen nicht über einen längeren Zeitraum blockieren, gelten für Apps, die Transcodierungssitzungen anfordern, folgende Einschränkungen:

  • 10 aufeinanderfolgende Sitzungen
  • eine Gesamtlaufzeit von drei Minuten

Wenn eine App alle diese Einschränkungen überschreitet, gibt das Framework den ursprünglichen Dateideskriptor zurück.

Geräteanforderungen

Damit die Funktion zur Transcodierung kompatibler Medien unterstützt wird, müssen Geräte die folgenden Anforderungen erfüllen:

  • Auf dem Gerät ist die HEVC-Codierung standardmäßig in der nativen Kamera-App aktiviert.
  • (Geräte, die HDR-zu-SDR-Transcodierung unterstützen) Gerät unterstützt HDR-Videoaufnahmen

Damit die Geräte beim Transcodieren von Media eine gute Leistung erbringen, müssen die Leistung der Videohardware und die Lese-/Schreibzugriffsleistung des Speichers optimiert werden. Wenn Media-Codecs mit der Priorität 1 konfiguriert sind, müssen sie mit dem höchstmöglichen Durchsatz arbeiten. Wir empfehlen, dass die Transcodierungsleistung mindestens 200 fps erreicht. Wenn Sie die Hardwareleistung testen möchten, führen Sie den Media Transcoder-Benchmark unter frameworks/av/media/libmediatranscoding/transcoder/benchmark aus.

Zertifizierungsstufe

Führen Sie die folgenden CTS-Tests aus, um die Funktion für das Transkodieren kompatibler Medien zu validieren:

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

Globale Medien-Transcodierung aktivieren

Wenn Sie das Media Transcoding Framework oder das Verhalten von Apps mit Transcodierung testen möchten, können Sie die Funktion „Transcodierung in kompatibles Medienformat“ global aktivieren oder deaktivieren. Stelle auf der Seite mit den Entwickleroptionen Einstellungen > System > Entwickler > Media-Transcodierung den Schalter Standardeinstellungen für die Transcodierung überschreiben auf Ein und den Schalter Transcodierung aktivieren auf Ein oder Aus. Wenn diese Einstellung aktiviert ist, kann die Media-Transcodierung im Hintergrund für andere Apps als die von dir entwickelte App erfolgen.

Transcodierungsstatus prüfen

Während des Tests können Sie den folgenden ADB-Shell-Befehl verwenden, um den Transcodierungsstatus zu prüfen, einschließlich aktueller und vergangener Transcodierungssitzungen:

adb shell dumpsys media.transcoding

Limit für die Videolänge erhöhen

Zu Testzwecken können Sie die Beschränkung der Videolänge von einer Minute für die Transcodierung mit dem folgenden Befehl aufheben. Nach dem Ausführen dieses Befehls ist möglicherweise ein Neustart erforderlich.

adb shell device_config put storage_native_boot transcode_max_duration_ms <LARGE_NUMBER_IN_MS>

AOSP-Quellcode und ‑Referenzen

Im Folgenden finden Sie AOSP-Quellcode, der sich auf die Transcodierung in kompatibles Medienformat bezieht.

HDR-zu-SDR-Codierung

Um die HDR-zu-SDR-Codierung zu unterstützen, können Gerätehersteller das AOSP-Beispiel-Codec 2.0-Filter-Plug-in verwenden, das sich unter /platform/frameworks/av/media/codec2/hidl/plugin/ befindet. In diesem Abschnitt wird beschrieben, wie das Filter-Plug-in funktioniert, wie Sie es implementieren und wie Sie es testen.

Wenn ein Gerät kein Plug-in enthält, das die HDR-zu-SDR-Codierung unterstützt, erhält eine App, die auf ein HDR-Video zugreift, den ursprünglichen Dateideskriptor, unabhängig von den im Manifest deklarierten Media-Funktionen der App.

Funktionsweise

In diesem Abschnitt wird das allgemeine Verhalten des Codec 2.0-Filter-Plug-ins beschrieben.

Hintergrund

Android bietet eine Implementierung der Anpassungsschicht zwischen der Codec 2.0-Schnittstelle und der android.hardware.media.c2-HAL-Schnittstelle unter android::hardware::media::c2. Für Filter-Plug-ins enthält AOSP einen Wrapper-Mechanismus, der Decoder zusammen mit Filter-Plug-ins umschließt. MediaCodec erkennt diese umschlossenen Komponenten als Decoder mit Filterfunktionen.

Übersicht

Die FilterWrapper-Klasse verwendet Anbieter-Codecs und gibt umschlossene Codecs an die media.c2-Anpassungsebene zurück. Die Klasse FilterWrapper lädt libc2filterplugin.so über die FilterWrapper::Plugin API und erfasst verfügbare Filter aus dem Plug-in. Bei der Erstellung werden alle verfügbaren Filter in FilterWrapper instanziiert. Nur Filter, die den Puffer ändern, werden beim Start ausgeführt.

Architektur von Filter-Plug-ins

Abbildung 4: Architektur von Filter-Plug-ins

Filterschnittstelle für Plug-ins

Die Schnittstelle FilterPlugin.h definiert die folgenden APIs zum Bereitstellen der Filter:

  • std::shared_ptr<C2ComponentStore>getComponentStore()

    Gibt ein C2ComponentStore-Objekt mit Filtern zurück. Dies ist unabhängig davon, was die Codec 2.0-Implementierung des Anbieters bereitstellt. Normalerweise enthält dieser Speicher nur die Filter, die von der Klasse FilterWrapper verwendet werden.

  • bool describe(C2String name, Descriptor *desc)

    Beschreibt die Filter zusätzlich zu den Informationen unter C2ComponentStore. Die folgenden Beschreibungen sind definiert:

    • controlParam: Parameter, die das Verhalten der Filter steuern. Für den HDR-zu-SDR-Tone-Mapper ist der Steuerparameter beispielsweise die Zielübertragungsfunktion.
    • affectedParams: Parameter, die von den Filtervorgängen betroffen sind. Beim HDR-zu-SDR-Tone-Mapper sind beispielsweise die Farbparameter betroffen.

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

    Gibt true zurück, wenn die Filterkomponente den Puffer ändert. Der Filter für das Tone-Mapping gibt beispielsweise true zurück, wenn die Ziel-Transferfunktion SDR und die Eingabe-Transferfunktion HDR (HLG oder PQ) ist.

FilterWrapper-Details

In diesem Abschnitt werden Details zur Klasse FilterWrapper beschrieben.

Erstellung

Die umschlossene Komponente instanziiert den zugrunde liegenden Decoder und alle definierten Filter bei der Erstellung.

Abfrage und Konfiguration

Die umschlossene Komponente trennt eingehende Parameter anhand der Filterbeschreibung von Anfragen oder Konfigurationsanfragen. Die Konfiguration des Filtersteuerungsparameters wird beispielsweise an den entsprechenden Filter weitergeleitet und die betroffenen Parameter aus den Filtern sind in den Anfragen vorhanden (anstatt aus dem Decoder mit nicht betroffenen Parametern gelesen zu werden).

Abfrage und Konfiguration

Abbildung 5: Abfrage und Konfiguration.

Starten

Zu Beginn startet die umschlossene Komponente den Decoder und alle Filter, die die Puffer ändern. Wenn kein Filter aktiviert ist, startet die umschlossene Komponente den Decoder und die Pass-Through-Puffer und sendet Befehle an den Decoder selbst.

Pufferverwaltung

Pufferverwaltung

Abbildung 6 Pufferverwaltung

Gepufferte Daten, die in die Warteschlange des umschlossenen Decoders gestellt werden, werden an den zugrunde liegenden Decoder weitergeleitet. Die umschlossene Komponente ruft den Ausgabepuffer vom Decoder über einen onWorkDone_nb()-Callback ab und stellt ihn dann in die Warteschlange der Filter. Der endgültige Ausgabepuffer des letzten Filters wird an den Client gemeldet.

Damit diese Pufferverarbeitung funktioniert, muss die umschlossene Komponente C2PortBlockPoolsTuning für den letzten Filter konfigurieren, damit die Framework-Ausgabepuffer aus dem erwarteten Blockpool stammen.

Stoppen, zurücksetzen und freigeben

Beim Stoppen beendet die umschlossene Komponente den Decoder und alle aktivierten Filter, die gestartet wurden. Beim Zurücksetzen und Freigeben werden alle Komponenten zurückgesetzt oder freigegeben, unabhängig davon, ob sie aktiviert sind oder nicht.

Beispielfilter-Plug-in implementieren

So aktivieren Sie das Plug-in:

  1. Implementieren Sie die FilterPlugin-Schnittstelle in einer Bibliothek und legen Sie sie unter /vendor/lib[64]/libc2filterplugin.so. ab.
  2. Fügen Sie bei Bedarf weitere Berechtigungen für mediacodec.te hinzu.
  3. Aktualisieren Sie die Anpassungsebene auf Android 12 und erstellen Sie den media.c2-Dienst neu.

Plug-in testen

So testen Sie das Beispiel-Plug-in:

  1. Erstellen Sie das Gerät neu und flashen Sie es.

  2. Erstellen Sie das Beispiel-Plug-in mit dem folgenden Befehl:

    m sample-codec2-filter-plugin

  3. Bringen Sie das Gerät wieder an der Halterung an und benennen Sie das Anbieter-Plug-in um, damit es vom Codec-Dienst erkannt wird.

    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