Décodage dans les applications mobiles : définition, concepts de base et principe de fonctionnement

Qu'est-ce que le décodage ?

Le décodage est le processus de conversion de données numériques compressées vers leur format non compressé d'origine. Dans le contexte multimédia, le décodage restaure les images vidéo à partir d'un flux binaire compressé créé par un encodeur. Sans décodage, les utilisateurs ne peuvent pas voir la vidéo ni entendre l'audio, car tous les formats multimédias modernes utilisent la compression pour économiser la bande passante et l'espace disque.

Un flux vidéo typique au format H.264 à 5 Mbps occupe 100 fois moins d'espace qu'un flux RVB non compressé avec la même résolution. L'algorithme de décodage doit restaurer chaque image à sa résolution et son espace colorimétrique d'origine, en suivant la spécification du codec dans l'ordre inverse par rapport au codage. Pour ce faire, le décodeur traite les données intra-image (image I) et inter-images (images P et B).

Sur les appareils mobiles, le décodage peut s'effectuer soit sur le CPU, soit sur des blocs matériels dédiés. Les SoC modernes d'Apple (série A), Qualcomm (Snapdragon) et MediaTek (Dimensity) contiennent des décodeurs intégrés pour tous les formats populaires. Le processeur vidéo prend en charge le travail lourd de la transformée en cosinus discrète inverse et de la compensation de mouvement, libérant le CPU pour d'autres tâches.

Comment fonctionne le décodage ?

Le processus de décodage comprend plusieurs étapes séquentielles qui inversent les étapes de codage. D'abord, les en-têtes et paramètres de compression (profil, niveau, résolution, espace colorimétrique) sont extraits du flux binaire. Ensuite, le décodeur traite séquentiellement les macroblocs compressés en leur appliquant des transformations inverses.

Étapes du décodage d'un flux vidéo

La première étape est l'extraction du code d'entropie. Le décodage entropique utilise les algorithmes CABAC ou CAVLC pour restaurer les coefficients de la transformée en cosinus discrète. Cette étape ne dépend pas de la résolution vidéo — elle traite un flux de bits, pas de pixels, et sa complexité est déterminée par le débit binaire, pas par les dimensions de l'image.

La deuxième étape est la quantification inverse et la DCT inverse. Le décodeur multiplie les coefficients quantifiés par le pas de quantification, restaure les valeurs approximatives des coefficients DCT, puis applique la transformée DCT inverse. La DCT inverse restaure les données spatiales du domaine fréquentiel, formant un macrobloc de pixels. La transformée est effectuée indépendamment pour la chrominance et la luminance.

La troisième étape est la compensation de mouvement. Pour les images P et B, le décodeur utilise des vecteurs de mouvement extraits du flux binaire et référence des images de référence précédemment décodées. La compensation de mouvement crée un prédicteur pour le macrobloc courant, auquel le signal résiduel après la DCT inverse est ajouté. Le résultat est une image entièrement restaurée prête pour la sortie.

// Pseudo-code de base du décodage d'image vidéo
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;
    }
};

L'exemple ci-dessus montre la structure de base d'un décodeur H.264. La fonction decodeNALUnit reçoit une unité NAL — le bloc de base du flux H.264 compressé. Le décodeur analyse séquentiellement l'en-tête, extrait le type de tranche, applique le décodage entropique, la quantification inverse et la DCT inverse. Pour les tranches P et B, une compensation de mouvement est en outre effectuée en utilisant des images de référence du tampon DPB.

Formats de compression et codecs

Les codecs vidéo modernes diffèrent par leurs algorithmes de compression, leur efficacité et leurs exigences en ressources de calcul. Le choix du format affecte directement la taille du fichier, la qualité d'image et la consommation d'énergie lors du décodage sur un appareil mobile.

H.264 est le codec vidéo le plus répandu, pris en charge par tous les appareils mobiles. Son principal avantage est l'universalité : tout smartphone Android et iPhone peut décoder H.264 par matériel. Cependant, au même débit binaire, H.264 perd en qualité face aux codecs plus modernes comme H.265 et AV1, nécessitant 30 à 50 % de débit binaire supplémentaire pour une qualité visuelle similaire.

H.265 offre deux fois plus de compression que H.264 à qualité égale. Le décodage H.265 nécessite un bloc matériel plus puissant : VideoToolbox sur iOS prend en charge H.265 à partir de l'iPhone 6 (A8), et les appareils Android à partir du Snapdragon 805. Lors du choix de H.265 pour une application mobile, il faut tenir compte du fait que les appareils plus anciens peuvent ne pas avoir de support matériel et décoderont ce format par logiciel, augmentant considérablement la consommation d'énergie.

AV1 est un codec ouvert de l'Alliance for Open Media, offrant la meilleure compression parmi tous les formats modernes. AV1 est 30 % plus efficace que H.265 et 50 % plus efficace que H.264 à qualité visuelle égale. Le décodage matériel AV1 n'est apparu que dans les SoC à partir de 2023 : Apple A17 Pro, Qualcomm Snapdragon 8 Gen 2 et plus récents. Pour les appareils plus anciens, le décodage AV1 n'est possible que par logiciel via la bibliothèque dav1d, créant une charge importante sur le CPU.

Décodage logiciel vs matériel

Le choix entre le décodage logiciel et matériel est une décision architecturale clé lors du développement d'un lecteur multimédia mobile. Chaque approche a ses avantages et ses limites qui doivent être pris en compte lors de la conception de l'application.

Performances et consommation d'énergie

Le décodage matériel est effectué sur des blocs de traitement vidéo spécialisés qui consomment beaucoup moins d'énergie que le CPU pour effectuer la même tâche. Selon Qualcomm, un décodeur H.265 matériel consomme 5 à 10 fois moins d'énergie que le décodage logiciel sur un CPU Snapdragon 8 Gen 1 lors de la lecture de vidéo 4K. C'est crucial pour les appareils mobiles où chaque milliwatt affecte l'autonomie de la batterie.

Le décodage logiciel, en revanche, offre une flexibilité maximale. FFmpeg avec la bibliothèque libavcodec prend en charge des dizaines de codecs et conteneurs, y compris les formats rares et obsolètes qui n'ont pas de support matériel. Le développeur peut modifier le pipeline de décodage, ajouter du post-traitement et des filtres à la volée, ce qui est impossible lors de l'utilisation de blocs matériels fermés.

Quand choisir le décodage logiciel

Le décodage logiciel est justifié dans plusieurs scénarios : lors de la lecture de formats rares (ProRes, DNxHD, Motion JPEG), lorsqu'un contrôle précis de chaque étape du traitement d'image est nécessaire, et lors du décodage d'AV1 sur des appareils sans support matériel. libavcodec de FFmpeg peut décoder pratiquement n'importe quel format connu, ce qui en fait le standard de facto pour les lecteurs multimédias universels.

La limitation du décodage logiciel est la dissipation thermique. Le décodage continu de vidéo 4K sur le CPU peut chauffer l'appareil à 45–50 degrés en 10–15 minutes, entraînant un étranglement thermique et une réduction du taux d'images. Sur les appareils sans refroidissement actif (tablettes, téléphones), c'est particulièrement notable. La consommation d'énergie du CPU lors du décodage logiciel peut atteindre 3–5 W contre 0,3–0,5 W lors du décodage matériel du même flux.

Quand choisir le décodage matériel

Le décodage matériel est le choix par défaut pour tout lecteur multimédia de production. Il fournit 60 images par seconde stables pour la vidéo 4K avec une consommation d'énergie minimale. VideoToolbox sur iOS et MediaCodec sur Android fournissent des API natives pour le décodage matériel qui sélectionnent automatiquement le bloc de traitement optimal en fonction du codec et de la résolution.

Les API de plateforme gèrent les tampons d'images (surface pool sur Android, CVPixelBufferPool sur iOS), la synchronisation avec l'écran et l'optimisation de la mémoire. Le développeur n'a qu'à ouvrir un décodeur avec les paramètres requis et recevoir des images prêtes. Le décodage matériel prend en charge un pipeline de bout en bout à faible latence : de la réception du flux binaire à l'affichage à l'écran, il faut 5–15 ms contre 30–80 ms pour le décodage logiciel.

Exemples de code de décodage

Examinons une implémentation pratique du décodage sur les deux plateformes mobiles. Sur iOS, le décodage matériel s'effectue via VideoToolbox et le décodage logiciel via FFmpeg. Sur Android, MediaCodec est utilisé pour le décodage matériel.

Décodage matériel sur iOS avec 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

Le code montre l'initialisation d'un décodeur H.264 matériel sur iOS. VTDecompressionSessionCreate crée une session de décodage, et VTCreate appelle un callback lorsqu'une image prête apparaît. La session utilise automatiquement le bloc matériel s'il est disponible pour le codec spécifié. Pour obtenir des images décodées au format CVPixelBuffer, un callback est utilisé qui transmet chaque image prête avec un délai minimal.

Décodage matériel sur Android avec 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);
}

Sur Android, MediaCodec utilise une Surface pour la sortie plutôt qu'un tampon de pixels, minimisant la copie de données entre le GPU et le CPU. Le décodeur sélectionne automatiquement le bloc matériel (composant OMX) en fonction du type de codec. Pour H.264, OMX.google.h264.decoder est utilisé, qui peut être matériel ou logiciel selon l'implémentation du fabricant.

Comment choisir un décodeur pour une application mobile

Le choix de la stratégie de décodage dépend du public cible de l'application, des formats pris en charge et des exigences de performance. La solution optimale implique souvent une approche hybride : décodage matériel pour les formats principaux (H.264, H.265) avec un repli logiciel pour les codecs rares.

Stratégie de sélection par priorités

Si l'application vise une compatibilité maximale, utilisez H.264, qui est garanti d'être décodé par matériel sur n'importe quel appareil. Pour les services de streaming vidéo, H.265 avec support matériel sur les appareils après 2016 est justifié. AV1 est le choix pour les services où l'économie de bande passante est importante : YouTube, Netflix et d'autres grandes plateformes adoptent activement AV1 pour réduire les coûts CDN tout en maintenant la qualité.

Un paramètre critique est la taille du tampon du décodeur. Les décodeurs matériels ont un pool de tampons fixe (généralement 4 à 16 images). Lors de la lecture d'un flux à haut débit binaire, les tampons peuvent déborder, entraînant une perte d'images. MediaCodec fournit la méthode getOutputFrameRate pour déterminer les performances réelles du décodeur sur un appareil spécifique, tandis que VideoToolbox permet de contrôler la priorité en temps réel via kVTDecodeFrame_EnableAsynchronousDecompression.

L'étranglement thermique est un autre facteur. Même le décodage matériel peut chauffer l'appareil lors d'une lecture prolongée de vidéo 4K HDR. Il est recommandé de surveiller la température via ProcessInfo sur iOS et BatteryManager sur Android, en réduisant la qualité ou la résolution du flux en cas de surchauffe. C'est particulièrement critique pour les jeux et les applications de streaming avec de longues sessions de visualisation.