🎅🏻 😺 🧑🏿‍🤝‍🧑🏽 WebRTC unter Android: Aktivieren der Hardware-Codierung auf mehreren Geräten 🚖 🐏 ♌️

Für Videoanrufe in Badoo verwenden wir den WebRTC-Standard und den H.264-Codec. Wenn Sie der Dokumentation glauben, sollte dieser Codec auf jedem Android-Gerät seit Android 5.0 problemlos funktionieren. In der Praxis stellte sich jedoch heraus, dass nicht alles so war. In diesem Artikel werde ich über die Funktionen zum Implementieren der Hardware-Codierung für den H.264-Codec in WebRTC und darüber sprechen, wie er auf mehr Geräten funktioniert.

Warum H.264?

Bei einer Verbindung über WebRTC übertragen alle an der Sitzung teilnehmenden Geräte verschiedene Kommunikationsparameter, einschließlich Video- und Audio-Codecs. Wenn Geräte mehrere Codecs unterstützen (z. B. VP8 und H.264), werden zuerst Prioritätscodecs für die Plattform aufgelistet. Diese Daten werden in der Abstimmungsphase in WebRTC verwendet. Danach verbleiben nur noch Codecs, die von allen Geräten unterstützt werden. Ein Beispiel für solche Daten mit Entschlüsselung finden Sie in diesem Dokument .

Wenn bei Videoanrufen eines der Geräte den H.264-Codec nicht unterstützt, können beide Geräte beispielsweise auf den VP8-Codec umschalten, der nicht von der Hardware-Implementierung auf dem Gerät abhängt. Unsere Anwendung ist jedoch auf einer Vielzahl von Geräten verfügbar, einschließlich Smartphones früherer Generationen. Daher wollten wir für die Videokommunikation nach Möglichkeit die Hardware-Codierung verwenden: Sie entlastet den Prozessor und verbraucht den Akku nicht so stark, was für veraltete Geräte von entscheidender Bedeutung ist. Die Unterstützung der H.264-Hardwarecodierung ist im Gegensatz zum gleichen VP8 auf einer großen Anzahl von Geräten implementiert .

H.264-Unterstützung für Android

Wenn Sie der Meinung sind, dass die Beschreibung der Unterstützung für Multimedia-Formate die Dekodierung des H.264-Basisprofils auf allen Android-Geräten und die Codierung - beginnend mit Android 3.0 - funktionieren sollte. In Badoo unterstützen wir Geräte ab Android 5.0, daher sollten wir keine Probleme haben. Aber es war nicht so einfach: Selbst in Gadgets mit der fünften Version fanden wir eine große Anzahl von Funktionen.

Womit kann es verbunden werden?

Wie Sie wissen, muss jeder Hersteller bei der Entwicklung eines neuen Geräts unter Android die Compatibility Test Suite bestehen. Es wird auf einem mit dem Gerät verbundenen PC ausgeführt. Die Ergebnisse müssen an Google gesendet werden, um zu bestätigen, dass das Gerät die Anforderungen des Android-Betriebssystems der angegebenen Version erfüllt. Erst danach kann das Gadget auf den Markt gebracht werden.

Wir sind an Multimedia-Tests in dieser Testsuite interessiert, insbesondere an Videokodierungs- und -decodierungstests. Ich habe beschlossen, die Tests EncodeDecodeTest , MediaCodecTest , DecoderTest und EncoderTest zu beenden , da sie seit 4.3 auf allen Android-Versionen vorhanden sind. Das Diagramm der Anzahl der Codezeilen in diesen Tests sieht folgendermaßen aus:

Vor Version 4.3 existierten die meisten dieser Tests einfach nicht und ihr signifikanter Anstieg fiel auf die Versionen 5 und 7. Daher können wir sagen, dass Google vor der Version Android 4.3 nicht die Konformität der Geräte mit den Spezifikationen für das Codieren und Decodieren von Videos überprüft hat, sondern in der Version 5.0 hat diese Prüfung erheblich verbessert.

Es scheint, dass dies darauf hinweist, dass ab Version 5.0 mit Codierung alles in Ordnung sein sollte. Aufgrund meiner früheren Erfahrungen mit dem Dekodieren von Streaming-Videos auf Android war ich mir jedoch sicher, dass dies nicht der Fall war. Es genügte, die Anzahl der Themen zum Thema Codierung in der Google-Gruppe " Diskussion-Webrtc" zu betrachten .

WebRTC-Quelldateien, die gemeinfrei sind, haben uns bei der Suche nach Fallstricken geholfen. Betrachten wir sie genauer.

H.264-Unterstützung in WebRTC

Beginnen wir mit der HardwareVideoEncoderFactory .

Es gibt eine Methode mit dem sprechenden Namen isHardwareSupportedInCurrentSdkH264:

private boolean isHardwareSupportedInCurrentSdkH264(MediaCodecInfo info) {
  // First, H264 hardware might perform poorly on this model.
  if (H264_HW_EXCEPTION_MODELS.contains(Build.MODEL)) {
    return false;
  }
  String name = info.getName();
  // QCOM H264 encoder is supported in KITKAT or later.
  return (name.startsWith(QCOM_PREFIX) && Build.VERSION.SDK_INT >= Build.VERSION_CODES.KITKAT)
      // Exynos H264 encoder is supported in LOLLIPOP or later.
      || (name.startsWith(EXYNOS_PREFIX)
             && Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP);
}

Wie wir sehen können, wird die Unterstützung für die Hardware-Codierung unter Android nur für Qualcomm- und Exynos-Chipsätze implementiert. Warum werden andere Chipsätze in der Standard-WebRTC-Implementierung nicht unterstützt? Dies ist höchstwahrscheinlich auf die Besonderheiten der Implementierung von Hardware-Codec-Herstellern zurückzuführen. Und es ist oft möglich, diese Merkmale nur in der Produktion zu identifizieren, da es nicht immer möglich ist, bestimmte Geräte zu finden.

Alle Codec-Beschreibungen auf dem Gerät werden in der Datei media_codecs.xml gespeichert. Hier ist zum Beispiel diese Datei für das Pixel XL und für das HUAWEI P8 lite . Wenn Sie eine Liste von Codecs mit der Methode getCodecInfos () des MediaCodecList-Objekts erhalten, wird diese Datei analysiert - und die darin gespeicherten Codecs werden zurückgegeben. Dieser Vorgang und das korrekte Ausfüllen dieser Datei durch den Hersteller werden im CTS-Test behandelt.MediaCodecListTest , die auch aus 160 Zeilen Code in Android 4,3 bis 740 Linien in Android 10 erhöht

In Badoo, änderten wir den isHardwareSupportedInCurrentSdkH264 Methodencode, die „weiße“ Codec - Liste zurückgewiesen und es mit einer „schwarzen“ Liste des Programms ersetzen Codec Präfixen, sind aufgelistet in WebRTC:

static final String[] SOFTWARE_IMPLEMENTATION_PREFIXES = {"OMX.google.", "OMX.SEC."};

Sie können jedoch nicht einfach alle Codecs unterstützen und implementieren, ohne auf die Funktionen der Hersteller zu achten. Anhand der Namen der Themen, die der Hardware-Codierung unter Android in der Diskussion-webrtc-Gruppe gewidmet sind , können wir verstehen, dass in diesem Fall definitiv Fehler auftreten werden. Grundsätzlich werden sie in der Codec-Konfigurationsphase angezeigt.

Codec-Konfigurationsoptionen

Die Initialisierung des Codecs für die Codierung lautet wie folgt:

MediaCodec mediaCodec = createByCodecName(codecName);
MediaFormat format = MediaFormat.createVideoFormat(mime, width, height);
format.setInteger(MediaFormat.KEY_BIT_RATE, targetBitrateBps);
format.setInteger(MediaFormat.KEY_BITRATE_MODE, VIDEO_ControlRateConstant);
format.setInteger(MediaFormat.KEY_COLOR_FORMAT, colorFormat);
format.setInteger(MediaFormat.KEY_FRAME_RATE, targetFps);
format.setInteger(MediaFormat.KEY_I_FRAME_INTERVAL, keyFrameIntervalSec);
mediaCodec.configure(format, null, null, MediaCodec.CONFIGURE_FLAG_ENCODE);

Bei einigen dieser Parameter kann es leicht zu Fehlern kommen, die beim Konfigurieren des Codecs eine Ausnahme auslösen und die Anwendung stören. Wenn Sie mit einem Codec arbeiten, müssen Sie möglicherweise die Bitrate in Abhängigkeit von verschiedenen Faktoren anpassen, da der Codec selbst dies falsch macht. Dafür ist in WebRTC die BaseBitrateAdjuster- Klasse verantwortlich , die zwei Nachkommen hat:

DynamicBitrateAdjuster - Passt die Bitrate abhängig von der Datenmenge an
FramerateBitrateAdjuster - Passt die Bitrate abhängig von der Bildrate an.

Dementsprechend müssen Sie für jeden Codec Ihren eigenen Bitratenanpassungsmechanismus auswählen. Lassen Sie uns die Funktionen zum Festlegen der Initialisierungsparameter für Hardware-Codecs genauer betrachten.

Stream-Auflösung

Nachdem Sie das MediaCodecInfo- Objekt für den Codec erhalten haben, können Sie den Codec genauer untersuchen, indem Sie seine Funktionen in der CodecCapabilities- Klasse abrufen . Anhand dieser Informationen können Sie herausfinden, ob der Codec die ausgewählte Auflösung und Bildrate unterstützt. Wenn diese Parameter unterstützt werden, können sie sicher eingestellt werden.

Manchmal funktioniert diese Regel jedoch nicht. Wir sind mit der Tatsache konfrontiert, dass Codecs mit dem Präfix "OMX.MARVELL". falsch codiert, zeigt grüne Streifen an den Rändern des Bildschirms, wenn die Auflösung des Streams von 4: 3 abweicht. Gleichzeitig behauptete der Codec selbst, dass die ausgewählte Auflösung und Bildrate unterstützt werden.

Bitratenmodus

Der Standardmodus für alle Video-Codecs ist eine konstante Bitrate. Einmal mussten wir jedoch eine variable Bitrate verwenden:

format.setInteger(MediaFormat.KEY_BITRATE_MODE, VIDEO_ControlRateVariable);

Dies geschah auf einem Lenovo A1000-Gerät mit dem Spreadtrum-Chipsatz (jetzt Unisoc), beginnend mit dem Präfix „OMX.sprd.“. Eine Suche im Internet führte uns zu einem sechs Jahre alten Beitrag über Firefox OS, in dem dieses Problem und seine Lösung beschrieben werden.

Farbformat

Wenn Sie den Codec im Byte-Puffer-Modus verwenden, müssen Sie das richtige Format auswählen. Dies erfolgt normalerweise mit einer Funktion der folgenden Form:

@Nullable
static Integer selectColorFormat(int[] supportedColorFormats, CodecCapabilities capabilities) {
  for (int supportedColorFormat : supportedColorFormats) {
    for (int codecColorFormat : capabilities.colorFormats) {
      if (codecColorFormat == supportedColorFormat) {
        return codecColorFormat;
      }
    }
  }
  return null;
}

Grob gesagt wird immer das erste der unterstützten Farbformate ausgewählt.

Bei HUAWEI-Codecs, die mit den Präfixen "OMX.IMG.TOPAZ.", "OMX.hisi" beginnen. und "OMX.k3." funktionierte nicht und nach langer Suche fanden wir eine Lösung: Unabhängig davon, welches Format diese Codecs zurückgeben, müssen Sie das Format COLOR_FormatYUV420SemiPlanar verwenden . Der Thread hat uns geholfen, dies in einem chinesischen Forum herauszufinden .

Bitrate-Einstellung

Der Standard-WebRTC-Code enthält Folgendes :

private BitrateAdjuster createBitrateAdjuster(VideoCodecMimeType type, String codecName) {
  if (codecName.startsWith(EXYNOS_PREFIX)) {
    if (type == VideoCodecMimeType.VP8) {
        // Exynos VP8 encoders need dynamic bitrate adjustment.
        return new DynamicBitrateAdjuster();
      } else {
        // Exynos VP9 and H264 encoders need framerate-based bitrate adjustment.
        return new FramerateBitrateAdjuster();
    }
  }
  // Other codecs don't need bitrate adjustment.
  return new BaseBitrateAdjuster();
}

Wie Sie diesem Code entnehmen können, ist die Bitratenanpassung für alle Chipsätze außer Exynos deaktiviert. Dies gilt jedoch nur für Qualcomm, da im Standardcode nur Exynos und Qualcomm unterstützt werden. Beim Experimentieren mit verschiedenen Werten dieser Einstellung sowie beim Durchsuchen des Internets haben wir festgestellt, dass Codecs mit den Präfixen „OMX.MTK“ verwendet werden. es muss auch eingeschaltet sein. Dies ist auch für HUAWEI-Codecs erforderlich, die mit dem Präfix "OMX.IMG.TOPAZ.", "OMX.hisi" beginnen. oder "OMX.k3.". Dies liegt an der Tatsache, dass diese Codecs keine Zeitstempel von Frames verwenden, um die Bitrate anzupassen, vorausgesetzt, dass alle Frames bei der Konfiguration des Codecs dieselbe Frequenz haben.

Abschließend werde ich eine Liste der Codecs geben, die wir für Geräte unter Android 5.0 und 5.1 erhalten haben. Sie waren für uns vor allem deshalb von Interesse, weil sich die Situation bei neueren Android-Versionen verbessert und nicht standardmäßige Codecs kleiner werden.

Dies ist in der folgenden Grafik zu sehen. Die logarithmische Skala zur besseren Darstellung seltener Fälle.

Wie wir sehen können, hatten die meisten Geräte Spreadtrum-, MediaTek-, HUAWEI- und MARVELL-Chipsätze. Daher haben unsere Änderungen dazu beigetragen, die Hardware-Codierung für diese Geräte zu ermöglichen.

Ergebnis

Obwohl wir davon ausgegangen sind, dass einige Geräte Probleme mit H.264 haben würden, konnte uns Android erneut überraschen. Wie aus den Badoo-Benutzerstatistiken hervorgeht, befinden sich 2014-2016 noch einige Geräte in den Händen der Benutzer, die sie nicht aktualisieren möchten oder können. Und obwohl die Situation mit der Veröffentlichung von Android-Updates für neue Geräte bereits viel besser ist als vor einigen Jahren, nimmt der Anteil der Gadgets der vorherigen Generation nur langsam ab und muss noch einige Zeit beibehalten werden.

Jetzt wird WebRTC aufgrund seiner Verwendung im Stadia-Projekt von Google aktiv entwickelt (hier das Video)mit Details zu diesem Thema), so dass es immer besser wird und höchstwahrscheinlich zum Standard für die Implementierung von Videokommunikation wird. Ich hoffe, dass dieser Artikel Ihnen hilft, die Funktionen der Arbeit mit H.264 in WebRTC zu verstehen und in Ihren Projekten zu verwenden.

WebRTC unter Android: Aktivieren der Hardware-Codierung auf mehreren Geräten