H.264 et HEVC entrelacés : ce que vos flux 1080i contiennent vraiment
Pourquoi vous recevez encore du 1080i
La vidéo entrelacée devait disparaître il y a dix ans. Elle n’a pas disparu, et elle ne disparaîtra pas avant dix ans de plus.
La raison n’est pas l’inertie, c’est l’amortissement. Une infrastructure de diffusion construite autour du 1080i50 ou du 1080i59.94, ce sont des caméras, des grilles, du SDI, des habillages et des serveurs de diffusion spécifiés, achetés et amortis sur vingt ou trente ans. Les cahiers des charges de diffusion nationaux, en Europe comme en Amérique du Nord, nomment encore des formats entrelacés. Les liaisons de contribution sportive arrivent encore entrelacées, parce que c’est ce que le car régie produit et ce que l’ayant droit a inscrit au contrat.
Ainsi, pendant que les plateformes web, les applications mobiles et les codecs modernes passaient au progressif, les flux qui arrivent à votre passerelle restent, très souvent, du 1080i. Votre travail n’est pas d’avoir un avis là-dessus. Votre travail est de les traiter sans les dégrader.
Et cela commence par savoir ce que vous avez réellement reçu — là où la plupart des opérateurs travaillent avec un modèle mental trop simple.
« 1080i H.264 » désigne trois choses différentes
Quand votre supervision annonce un flux 1080i H.264, elle vous a donné le format de présentation. Elle ne vous a pas dit comment l’encodeur a structuré la vidéo — et H.264 offre trois façons légitimes de le faire.
Codage de trame à structure adaptative (MBAFF)
Le Macroblock-Adaptive Frame/Field coding garde les deux champs dans une seule image codée, puis décide région par région si cette zone est mieux codée comme une trame ou comme une paire de champs. Les zones statiques reçoivent un codage trame, plus efficace. Les zones en mouvement reçoivent un codage champ, qui évite de gaspiller des bits sur les artefacts de peigne.
C’est le mode entrelacé le plus efficace et le plus courant dans les encodeurs de contribution professionnels. C’est aussi le plus exigeant pour les décodeurs, puisque la structure change à travers l’image.
Codage adaptatif par image (PAFF)
Le Picture-Adaptive Frame/Field coding fait le même choix, mais une fois par image plutôt que par région. Chaque image est codée soit comme une trame complète portant les deux champs, soit comme deux images de champ séparées, et l’encodeur bascule selon le contenu. Plus simple que le MBAFF, légèrement moins efficace, très largement supporté.
Codage par champs purs
Chaque champ est codé comme sa propre image, à mi-hauteur, à la cadence des champs. Un flux 1080i50 devient une séquence d’images 1920×540, cinquante par seconde. Moins courant en H.264, où MBAFF et PAFF font généralement mieux — mais parfaitement valide et, comme on va le voir, l’unique option que HEVC vous laisse.
Pourquoi c’est important : ces trois structures sont toutes correctement décrites comme du « 1080i H.264 », toutes décodent vers les mêmes images, et elles ne sont pas également supportées par tous les décodeurs de votre chaîne. Quand un récepteur matériel se comporte mal sur un flux et pas sur un autre pourtant identique sur le papier, la structure de codage est l’une des premières choses à vérifier — avant le débit.
HEVC entrelacé : un seul chemin, et il surprend tout le monde
HEVC a été normalisé au moment où l’industrie avait décidé que l’avenir était progressif. Le comité a fait un choix délibéré : HEVC n’a aucun outil de codage entrelacé. Pas de MBAFF, pas de PAFF, pas d’équivalent.
Ce que HEVC possède, ce sont des métadonnées. Un encodeur peut coder chaque champ comme une image séparée et signaler, dans le flux, que ces images sont des champs — avec leur parité et leur appariement d’affichage.
La conséquence est directe, et elle piège presque tout le monde la première fois :
Un flux HEVC « 1080i50 » est une séquence d’images 1920×540 à 50 images par seconde.
Pas du 1920×1080. Pas 25 images par seconde. Tous les outils d’analyse que vous pointerez dessus afficheront 540 lignes, et le réflexe naturel est de croire à une panne, ou à un flux demi-résolution envoyé par erreur. Rien n’est cassé. C’est cela, le HEVC entrelacé.
Deux conséquences pratiques en découlent.
Le format d’image doit être signalé explicitement. Une image de 1920×540 en pixels carrés décrit une image 32:9. Le HEVC entrelacé transporte donc un rapport d’aspect de pixel déclarant que chaque pixel est deux fois plus haut que large, pour que la trame reconstruite soit du 16:9. Perdez cette signalisation quelque part dans la chaîne — et elle se perd facilement — et l’image arrive étirée, pendant que tous les contrôles de débit et de continuité restent au vert.
Votre supervision doit comprendre ce qu’elle regarde. Un système qui classe les flux par leur seule résolution rangera le HEVC entrelacé en « 540p50 progressif » et prendra toutes ses décisions aval sur cette prémisse fausse. Le traitement correct commence par la reconnaissance correcte.
La falaise du support matériel
C’est ici que les deux codecs divergent brutalement, et qu’un plan raisonnable sur le papier rencontre la réalité.
L’encodage H.264 entrelacé existe dans certains encodeurs matériels, généralement par un chemin dédié avec ses propres contraintes. Disponible, mais ni par défaut ni universel.
L’encodage HEVC entrelacé est une autre affaire. La norme n’ayant pas d’outils entrelacés, les constructeurs n’avaient guère de raison d’implémenter le chemin par séquence de champs, et la plupart ne l’ont jamais fait. Les encodeurs NVIDIA n’encodent pas l’entrelacé du tout — une limite qui nourrit depuis des années des fils de discussion sans réponse sur leurs propres forums développeurs. Le chemin HEVC matériel d’Intel n’encode pas les champs non plus.
Conséquence pratique pour un opérateur : produire du HEVC entrelacé est un travail d’encodage logiciel. Il n’existe pas de raccourci matériel. Ce seul fait redessine tout plan de capacité bâti sur le transcodage accéléré par GPU, car le nombre de canaux par serveur est désormais fixé par le CPU, pas par le silicium.
Personne ne vous le dit à l’avance. Vous le découvrez quand l’encodeur refuse la configuration — ou pire, quand il produit silencieusement un flux progressif que toute la chaîne aval étiquette poliment de travers.
Trois décisions, dont deux seulement sont réversibles
Face à une entrée entrelacée, un opérateur a trois options. Elles ne sont pas équivalentes, et leur différence est largement incomprise.
Préserver les champs
Entrelacé en entrée, entrelacé en sortie, les champs traversant la chaîne intacts dans leur ordre temporel. Rien n’est inventé, rien n’est jeté. C’est le bon choix chaque fois que la destination est un récepteur broadcast, une conversion SDI ou une liaison de contribution.
C’est aussi la seule option temporellement sans perte : chacun des cinquante échantillons de mouvement par seconde capturés par la caméra est encore là à l’autre bout.
Convertir en progressif
Les champs sont combinés en trames complètes — le bon choix quand la destination est une plateforme web, une application mobile ou tout workflow de distribution moderne.
Bien menée, cette conversion ne perd rien dans le temps : un flux 1080i50 désentrelacé à la cadence des champs devient du vrai 1080p50 — une trame par champ, les cinquante échantillons de mouvement par seconde intacts. Désentrelacer vers 25 images par seconde, ce que beaucoup de systèmes font par défaut, jette la moitié du mouvement et rend le sport injouable à l’écran. La cadence du résultat est un choix, et la bonne réponse pour du direct est presque toujours la cadence des champs.
Cette décision est irréversible. Le désentrelacement invente de l’information : il reconstruit par interpolation les lignes manquantes de chaque champ. Ré-entrelacer ensuite ne restitue pas ce qui a été jeté — cela produit un flux structurellement entrelacé mais bâti sur du contenu interpolé. Deux conversions dans une chaîne coûtent deux fois, et aucune étape ultérieure ne les annule.
La fréquence à laquelle cela arrive par accident est le premier problème de qualité des chaînes live. Un système qui désentrelace par défaut, parce que le progressif est plus simple à traiter en interne, dégrade silencieusement chaque flux entrelacé qui le traverse — et la perte n’apparaît sur aucun graphe de débit.
Convertir du progressif vers l’entrelacé
Une source progressive doit alimenter une destination entrelacée — du 1080p50 vers un cahier des charges 1080i50 étant le cas quotidien. Bien menée, la fluidité est intégralement préservée : chaque champ est prélevé dans une trame source distincte, les cinquante échantillons de mouvement par seconde survivent donc à la conversion. Ce qui est cédé, c’est la résolution verticale de chaque instant — ce qui est la définition même de l’entrelacé, pas un défaut de la conversion.
L’opération porte une exigence peu évidente : le détail vertical de l’image progressive doit être filtré avant la construction des champs. Sans cela, les détails horizontaux fins scintillent entre les champs — le fameux twitter d’entrelacement, douloureusement visible sur les habillages et les synthés. Omettre ce filtrage est l’erreur la plus courante de la conversion progressif→entrelacé.
Ce qu’un système live doit faire correctement
Rien de tout cela n’est exotique. C’est la condition ordinaire de la contribution live en 2026, et elle définit ce qu’une passerelle doit faire proprement plutôt qu’approximativement.
Reconnaître la structure, pas seulement la résolution. Savoir qu’un flux est en 1080i ne suffit pas. Un système doit distinguer un flux H.264 entrelacé codé en trames d’une séquence de champs HEVC native, car c’est le même programme sous deux formes radicalement différentes, exigeant des traitements différents en aval.
Préserver par défaut, convertir à dessein. Le désentrelacement doit être une décision prise par l’opérateur, visible dans la configuration — pas l’effet de bord d’une simplification interne.
Ne jamais désentrelacer pour ré-entrelacer. Quand l’entrée et la sortie sont toutes deux entrelacées, les champs doivent traverser intacts. Un cycle désentrelacement-réentrelacement dépense de la qualité et du CPU pour ne rien obtenir, et c’est un schéma étonnamment courant dans les systèmes conçus d’abord pour le progressif.
Signaler correctement en sortie. L’ordre des champs, les métadonnées de séquence de champs et le rapport d’aspect de pixel ne sont pas décoratifs. C’est ce qui dit au récepteur comment réassembler l’image. Un flux portant les bons pixels avec la mauvaise signalisation est un flux cassé pour chaque équipement qui le lit.
Vérifier la sortie, jamais la supposer. La documentation des encodeurs et leur comportement réel ne concordent pas toujours — surtout sur les chemins entrelacés, les moins fréquentés et les moins testés de toute base de code. La seule preuve fiable qu’une chaîne produit de l’entrelacé correctement signalé : encoder, analyser le résultat, et le confirmer.
Où Vajracast se situe
Vajracast traite le H.264 entrelacé et le HEVC entrelacé comme des formats de premier rang, pas comme des cas particuliers à normaliser.
Les entrées entrelacées sont identifiées par leur structure codée réelle — y compris les séquences de champs HEVC natives que d’autres systèmes prennent pour du progressif à mi-hauteur. Le routage entrelacé vers entrelacé préserve les champs de bout en bout, sans cycle de désentrelacement caché au milieu. Le désentrelacement vers le progressif est disponible quand la destination l’exige — y compris du 1080i50 vers du vrai 1080p50 à pleine cadence de mouvement — comme un choix explicite de l’opérateur et non un défaut silencieux. La conversion inverse, du 1080p50 vers une sortie 1080i50 pleinement signalée, est également supportée pour les sources progressives alimentant des cahiers des charges entrelacés. Et chaque chemin de sortie entrelacé est qualifié contre les binaires d’encodage réellement livrés avec la plateforme, car sur les chemins entrelacés, la spécification et l’implémentation ne sont pas toujours la même chose.
Si vos liaisons de contribution sont entrelacées et vos destinations mixtes, ce n’est pas un problème à contourner. C’est l’état normal du broadcast live — et c’est ce que la plateforme est construite pour traiter.
À lire aussi : Transcodage matériel avec Intel Quick Sync · Compatibilité décodeurs SRT et transcodage
Plateforme cloud managée avec serveurs dédiés, failover N+1, transcodage matériel et diffusion mondiale. Gratuit pendant 30 jours.
30 jours gratuits · Sans carte bancaire · Accès direct à l'équipe