Decodierung in mobilen Apps: Was ist das, grundlegende Konzepte und Funktionsweise

Was ist Decodierung?

Decodierung ist der Prozess der Umwandlung komprimierter digitaler Daten zurück in ihr ursprüngliches unkomprimiertes Format. Im Kontext von Medien stellt die Decodierung Videoframes aus einem komprimierten Bitstrom wieder her, der von einem Encoder erzeugt wurde. Ohne Decodierung können Benutzer kein Video sehen oder Audio hören, da alle modernen Medienformate Kompression verwenden, um Bandbreite und Speicherplatz zu sparen.

Ein typischer Videostrom im H.264-Format mit 5 Mbit/s benötigt 100-mal weniger Platz als ein unkomprimierter RGB-Strom mit derselben Auflösung. Der Decodierungsalgorithmus muss jedes Frame wieder in seine ursprüngliche Auflösung und seinen ursprünglichen Farbraum zurückversetzen, wobei er der Codec-Spezifikation in umgekehrter Reihenfolge zur Codierung folgt. Dazu verarbeitet der Decoder Intra-Frame- (I-Frame) und Inter-Frame-Daten (P-Frame, B-Frame).

Bei mobilen Geräten kann die Decodierung entweder auf der CPU oder auf dedizierten Hardware-Blöcken erfolgen. Moderne SoCs von Apple (A-Serie), Qualcomm (Snapdragon) und MediaTek (Dimensity) enthalten integrierte Decoder für alle gängigen Formate. Der Videoprozessor übernimmt die schwere Arbeit der inversen diskreten Kosinustransformation und Bewegungskompensation und entlastet so die CPU für andere Aufgaben.

Wie funktioniert Decodierung?

Der Decodierungsprozess besteht aus mehreren aufeinanderfolgenden Phasen, die die Codierungsschritte umkehren. Zunächst werden aus dem Bitstrom Header und Kompressionsparameter extrahiert — Profil, Stufe, Auflösung, Farbraum. Anschließend verarbeitet der Decoder sequenziell die komprimierten Makroblöcke und wendet inverse Transformationen auf sie an.

Phasen der Videostrom-Decodierung

Die erste Phase ist die Extraktion des Entropiecodes. Die Entropie-Decodierung verwendet CABAC- oder CAVLC-Algorithmen, um die Koeffizienten der diskreten Kosinustransformation wiederherzustellen. Diese Phase hängt nicht von der Videoauflösung ab — sie verarbeitet einen Bitstrom, keine Pixel, und ihre Komplexität wird durch die Bitrate bestimmt, nicht durch die Frame-Abmessungen.

Die zweite Phase ist die inverse Quantisierung und inverse DCT. Der Decoder multipliziert die quantisierten Koeffizienten mit der Quantisierungsstufe, stellt die ungefähren DCT-Koeffizientenwerte wieder her und wendet dann die inverse DCT-Transformation an. Die inverse DCT stellt räumliche Daten aus dem Frequenzbereich wieder her und bildet einen Makroblock von Pixeln. Die Transformation wird für Chroma und Luma unabhängig durchgeführt.

Die dritte Phase ist die Bewegungskompensation. Für P- und B-Frames verwendet der Decoder aus dem Bitstrom extrahierte Bewegungsvektoren und referenziert zuvor decodierte Referenzframes. Die Bewegungskompensation erzeugt einen Prädiktor für den aktuellen Makroblock, zu dem das Restsignal nach der inversen DCT addiert wird. Das Ergebnis ist ein vollständig wiederhergestelltes Frame, das für die Ausgabe bereit ist.

// Pseudocode für grundlegende Videoframe-Decodierung
struct DecodedFrame {
    uint8_t* y_plane;
    uint8_t* u_plane;
    uint8_t* v_plane;
    int width, height;
};

class Decoder {
public:
    bool decodeNALUnit(const uint8_t* nalUnit, size_t size) {
        if (!parseNALUHeader(nalUnit, size))
            return false;
        
        int sliceType = parseSliceType(nalUnit);
        entropyDecode(nalUnit);
        inverseQuantize();
        inverseDCT();
        
        if (sliceType != I_SLICE)
            motionCompensation();
        
        return true;
    }
};

Das obige Beispiel zeigt die grundlegende Struktur eines H.264-Decoders. Die Funktion decodeNALUnit empfängt eine NAL-Einheit — den grundlegenden Block des komprimierten H.264-Stroms. Der Decoder parst sequenziell den Header, extrahiert den Slice-Typ, wendet Entropie-Decodierung, inverse Quantisierung und inverse DCT an. Für P- und B-Slices wird zusätzlich eine Bewegungskompensation unter Verwendung von Referenzframes aus dem DPB-Puffer durchgeführt.

Kompressionsformate und Codecs

Moderne Video-Codecs unterscheiden sich in Kompressionsalgorithmen, Effizienz und Anforderungen an Rechenressourcen. Die Wahl des Formats wirkt sich direkt auf Dateigröße, Bildqualität und Stromverbrauch bei der Decodierung auf einem mobilen Gerät aus.

H.264 ist der am weitesten verbreitete Video-Codec, der von allen mobilen Geräten unterstützt wird. Sein Hauptvorteil ist die Universalität: Jedes Android-Smartphone und iPhone kann H.264 hardwaredecodieren. Bei gleicher Bitrate verliert H.264 jedoch an Qualität gegenüber moderneren Codecs wie H.265 und AV1 und benötigt 30–50 % mehr Bitrate für eine ähnliche visuelle Qualität.

H.265 bietet die doppelte Kompression im Vergleich zu H.264 bei gleicher Qualität. Die H.265-Decodierung erfordert einen leistungsstärkeren Hardware-Block: VideoToolbox auf iOS unterstützt H.265 ab dem iPhone 6 (A8) und Android-Geräte ab Snapdragon 805. Bei der Wahl von H.265 für eine mobile App ist zu beachten, dass ältere Geräte möglicherweise keine Hardware-Unterstützung haben und dieses Format softwaredecodieren, was den Stromverbrauch drastisch erhöht.

AV1 ist ein offener Codec der Alliance for Open Media, der die beste Kompression unter allen modernen Formaten bietet. AV1 ist 30 % effizienter als H.265 und 50 % effizienter als H.264 bei gleicher visueller Qualität. Hardware-AV1-Decodierung erschien erst in SoCs ab 2023: Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 und neuer. Bei älteren Geräten ist die AV1-Decodierung nur softwarebasiert über die dav1d-Bibliothek möglich, was eine erhebliche CPU-Last verursacht.

Software- vs Hardware-Decodierung

Die Wahl zwischen Software- und Hardware-Decodierung ist eine zentrale architektonische Entscheidung bei der Entwicklung eines mobilen Mediaplayers. Jeder Ansatz hat seine Vor- und Nachteile, die bei der Anwendungsentwicklung berücksichtigt werden müssen.

Leistung und Stromverbrauch

Die Hardware-Decodierung wird auf spezialisierten Videoverarbeitungsblöcken durchgeführt, die bei gleicher Aufgabe deutlich weniger Energie verbrauchen als die CPU. Laut Qualcomm verbraucht ein Hardware-H.265-Decoder 5–10 mal weniger Energie als die Software-Decodierung auf einer Snapdragon 8 Gen 1 CPU bei der Wiedergabe von 4K-Video. Dies ist für mobile Geräte entscheidend, da jedes Milliwatt die Akkulaufzeit beeinflusst.

Die Software-Decodierung bietet hingegen maximale Flexibilität. FFmpeg mit der Bibliothek libavcodec unterstützt Dutzende von Codecs und Containern, einschließlich seltener und veralteter Formate ohne Hardware-Unterstützung. Der Entwickler kann die Decodierungspipeline modifizieren, Nachbearbeitung und Filter in Echtzeit hinzufügen, was bei Verwendung geschlossener Hardware-Blöcke unmöglich ist.

Wann Software-Decodierung wählen

Software-Decodierung ist in mehreren Szenarien gerechtfertigt: bei der Wiedergabe seltener Formate (ProRes, DNxHD, Motion JPEG), wenn eine präzise Kontrolle über jede Stufe der Frame-Verarbeitung erforderlich ist, und bei der Decodierung von AV1 auf Geräten ohne Hardware-Unterstützung. libavcodec von FFmpeg kann praktisch jedes bekannte Format decodieren, was es zum De-facto-Standard für universelle Mediaplayer macht.

Die Einschränkung der Software-Decodierung ist die Wärmeentwicklung. Kontinuierliche 4K-Video-Decodierung auf der CPU kann das Gerät innerhalb von 10–15 Minuten auf 45–50 Grad erhitzen, was zu Drosselung und einer Reduzierung der Bildrate führt. Bei Geräten ohne aktive Kühlung (Tablets, Telefone) ist dies besonders spürbar. Der CPU-Stromverbrauch bei Software-Decodierung kann 3–5 W erreichen, verglichen mit 0,3–0,5 W bei Hardware-Decodierung desselben Stroms.

Wann Hardware-Decodierung wählen

Hardware-Decodierung ist die Standardwahl für jeden Produktions-Mediaplayer. Sie bietet stabile 60 fps für 4K-Video bei minimalem Stromverbrauch. VideoToolbox auf iOS und MediaCodec auf Android bieten native APIs für Hardware-Decodierung, die automatisch den optimalen Verarbeitungsblock in Abhängigkeit von Codec und Auflösung auswählen.

Die Plattform-APIs übernehmen die Frame-Puffer-Verwaltung (Surface Pool auf Android, CVPixelBufferPool auf iOS), die Synchronisation mit dem Display und die Speicheroptimierung. Der Entwickler muss nur einen Decoder mit den erforderlichen Parametern öffnen und fertige Frames empfangen. Die Hardware-Decodierung unterstützt eine Ende-zu-Ende-Pipeline mit minimaler Latenz: Vom Empfang des Bitstroms bis zur Anzeige auf dem Bildschirm vergehen 5–15 ms gegenüber 30–80 ms bei der Software-Decodierung.

Decodierungs-Codebeispiele

Betrachten wir eine praktische Implementierung der Decodierung auf beiden mobilen Plattformen. Auf iOS erfolgt die Hardware-Decodierung über VideoToolbox und die Software-Decodierung über FFmpeg. Auf Android wird MediaCodec für die Hardware-Decodierung verwendet.

Hardware-Decodierung auf iOS mit VideoToolbox

@interface VideoDecoder ()
@property (nonatomic) VTDecompressionSessionRef session;
@end

@implementation VideoDecoder

- (void)setupDecoder {
    CMVideoFormatDescriptionRef formatDesc;
    CMVideoCodecType codecType = kCMVideoCodecType_H264;
    
    OSStatus status = CMVideoFormatDescriptionCreate(
        NULL, codecType, 1920, 1080, NULL, &formatDesc
    );
    
    VTDecompressionOutputCallbackRecord callback;
    callback.decompressionOutputCallback = &decodingCallback;
    
    VTDecompressionSessionCreate(NULL, formatDesc, NULL,
        NULL, &callback, &_session);
}

- (void)decodeFrame: (uint8_t*)nalData length:(size_t)size {
    CMBlockBufferRef blockBuffer;
    CMBlockBufferCreateWithMemoryBlock(NULL, nalData,
        size, NULL, NULL, 0, size, 0, &blockBuffer);
    
    CMSampleBufferRef sampleBuffer;
    CMSampleBufferCreate(NULL, blockBuffer, true, NULL,
        NULL, NULL, 1, 0, NULL, 0, NULL, &sampleBuffer);
    
    VTDecompressionSessionDecodeFrame(_session,
        sampleBuffer, 0, NULL, 0);
}

@end

Der Code zeigt die Initialisierung eines H.264-Hardware-Decoders auf iOS. VTDecompressionSessionCreate erstellt eine Decodierungssitzung, und VTCreate ruft einen Callback auf, wenn ein fertiges Frame erscheint. Die Sitzung verwendet automatisch den Hardware-Block, falls er für den angegebenen Codec verfügbar ist. Um decodierte Frames im CVPixelBuffer-Format zu erhalten, wird ein Callback verwendet, der jedes fertige Frame mit minimaler Verzögerung übergibt.

Hardware-Decodierung auf Android mit MediaCodec

MediaCodec decoder = MediaCodec.createDecoderByType("video/avc");
MediaFormat format = MediaFormat.createVideoFormat(
    "video/avc", 1920, 1080
);
format.setInteger(MediaFormat.KEY_FRAME_RATE, 30);

decoder.configure(format, surface, null, 0);
decoder.start();

ByteBuffer[] inputBuffers = decoder.getInputBuffers();
int inputIndex = decoder.dequeueInputBuffer(10000);

if (inputIndex >= 0) {
    ByteBuffer buffer = inputBuffers[inputIndex];
    buffer.clear();
    buffer.put(nalData);
    decoder.queueInputBuffer(inputIndex, 0, nalData.length, pts, 0);
}

Unter Android verwendet MediaCodec für die Ausgabe ein Surface anstelle eines Pixel-Puffers, was das Kopieren von Daten zwischen GPU und CPU minimiert. Der Decoder wählt automatisch den Hardware-Block (OMX-Komponente) basierend auf dem Codec-Typ aus. Für H.264 wird OMX.google.h264.decoder verwendet, der je nach Herstellerimplementierung Hardware oder Software sein kann.

So wählen Sie einen Decoder für eine mobile App

Die Wahl der Decodierungsstrategie hängt von der Zielgruppe der Anwendung, den unterstützten Formaten und den Leistungsanforderungen ab. Die optimale Lösung beinhaltet oft einen hybriden Ansatz: Hardware-Decodierung für Hauptformate (H.264, H.265) mit Software-Fallback für seltene Codecs.

Prioritätsbasierte Auswahlstrategie

Wenn die Anwendung auf maximale Kompatibilität abzielt, verwenden Sie H.264, das auf jedem Gerät garantiert hardwaredecodiert wird. Für Videostreaming-Dienste ist H.265 mit Hardware-Unterstützung auf Geräten nach 2016 gerechtfertigt. AV1 ist die Wahl für Dienste, bei denen Bandbreite wichtig ist: YouTube, Netflix und andere große Plattformen führen AV1 aktiv ein, um CDN-Kosten zu senken und gleichzeitig die Qualität zu erhalten.

Ein kritischer Parameter ist die Puffergröße des Decoders. Hardware-Decoder haben einen festen Pufferpool (normalerweise 4–16 Frames). Bei der Wiedergabe eines hochbitratigen Stroms können die Puffer überlaufen, was zu Framerausfällen führt. MediaCodec bietet die Methode getOutputFrameRate zur Bestimmung der tatsächlichen Decoderleistung auf einem bestimmten Gerät, während VideoToolbox die Echtzeitpriorität über kVTDecodeFrame_EnableAsynchronousDecompression steuern kann.

Thermisches Drosseln ist ein weiterer Faktor. Selbst Hardware-Decodierung kann das Gerät bei längerer 4K-HDR-Videowiedergabe erwärmen. Es wird empfohlen, die Temperatur über ProcessInfo auf iOS und BatteryManager auf Android zu überwachen und bei Überhitzung die Qualität oder Auflösung des Stroms zu reduzieren. Dies ist besonders wichtig für Spiele und Streaming-Anwendungen mit langen Betrachtungssitzungen.