La plupart des gens connaissent les bases de la théorie des couleurs. En combinant la luminosité de plusieurs couleurs primaires, vous pouvez recréer n'importe quelle couleur visible par une personne. Beaucoup de gens savent que les couleurs individuelles sont simplement les longueurs d'onde du spectre électromagnétique. Mais ce que beaucoup ne réalisent pas, c'est à quel point la situation devient difficile lorsque nous nous efforçons d'enregistrer et de reproduire avec précision les couleurs.
Il existe de nombreux systèmes impliqués dans la conversion d'une valeur de triplet RVB en une longueur d'onde de lumière spécifique. Cette transformation doit être standardisée afin que tous les logiciels, tous les décodeurs vidéo, cartes vidéo et moniteurs (même fabriqués par différents fabricants au cours de différentes décennies) puissent produire les mêmes résultats à partir des mêmes données d'entrée. Pour relever ce défi, des normes de couleurs ont été développées. Cependant, les écrans et autres technologies ont évolué au fil du temps. La télévision est passée au numérique, la compression a commencé et nous avons abandonné les tubes cathodiques au profit des écrans LCD et OLED. Le nouvel équipement était capable d'afficher plus de couleurs avec une luminosité plus élevée, mais les signaux qu'il recevait étaient toujours adaptés aux capacités des écrans plus anciens.
La solution à ce problème était de créer un nouvel "espace colorimétrique". Un nouveau contenu HD peut être produit dans un nouvel espace colorimétrique et de nouveaux écrans HD peuvent l'afficher. Et si l'ancien espace colorimétrique est converti en un nouveau avant d'être affiché, l'ancien contenu ne perdra pas sa compatibilité.
C'est une solution qui fonctionne, mais cela complique le processus de création vidéo. À chaque étape du processus de capture, d'enregistrement, d'édition, d'encodage, de décodage, de composition et d'affichage, vous devez tenir compte de l'espace colorimétrique que vous utilisez. Et si au moins une étape du processus utilise un ancien équipement, ou s'il y a un bogue logiciel en raison duquel l'espace colorimétrique n'est pas pris en compte, le résultat peut être une image incorrecte. La vidéo peut toujours être visionnée, mais les couleurs peuvent apparaître trop sombres ou trop pâles.
Aujourd'hui, les deux espaces colorimétriques les plus populaires sont BT.601 (également appelé smpte170m ; j'utiliserai ces deux noms dans cet article), qui est devenu la norme pour le contenu SD, et BT.709, qui est devenu la norme pour Contenu HD. Il y a aussi BT.2020, qui devient de plus en plus populaire grâce à son contenu HDR et UHD. Il convient de noter que la division HD / SD est un peu imparfaite ici. Il n'y a pas de limitations techniques, c'est juste une approche traditionnelle. Le contenu HD peut être encodé en BT.601 et le contenu SD en BT.709. Si vous prenez un fichier vidéo 1080p et le réduisez à 480p, l'espace colorimétrique ne changera pas automatiquement. La modification de l'espace colorimétrique est une étape supplémentaire effectuée dans le cadre du processus.
Que se passe-t-il si un processus n'est pas exécuté correctement ? Faisons une expérience.
Le programme ffmpeg est un véritable miracle de notre époque. C'est un outil vidéo numérique très populaire, et toute l'industrie doit beaucoup à ses développeurs. Dans mon expérience, j'utiliserai cet outil pour créer et modifier des fichiers vidéo.
Tout d'abord, je vais créer un fichier de test simple à l'aide de ffmpeg :
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -color_range pc -y 601.mp4
Une brève explication de cette commande :
ffmpeg
—
-f rawvideo
— ffmpeg, , .
-s 320x240
— . , . .
-pix_fmt yuv420p
— . Yuv420p — . , yuv(0,0,0) . RGB, , .
-t 1
— 1
-i /dev/zero
— . /dev/zero — , mac. , .
-an
— , .
-vcodec libx264
— libx264.
-profile:v baseline
— h.264. h.264, .
-preset:v placebo
— libx264, . , . , .
-color_range pc
— 0 255. 16-235. - , . ,pc
,tv
.
-crf 18
- l'option de facteur de débit constant indique à libx264 de créer un fichier vidéo de haute qualité et d'utiliser autant de bits que nécessaire pour garantir la qualité18
. Plus le nombre est bas, plus la qualité est élevée. 18 est une très haute qualité.
-y
- donne Ă ffmpeg la permission d'Ă©craser le fichier s'il existe.
601.mp4
- le nom du fichier résultant.
Cette commande crée un fichier 601.mp4 d'une durée de 1 seconde, qui peut être ouvert et lu. Après avoir exécuté cette commande, nous pouvons vérifier que ffmpeg n'a pas déformé les valeurs de pixels en exécutant la commande suivante et en examinant la sortie :
ffmpeg -i 601.mp4 -f rawvideo - | xxd
00000000: 0000 0000 0000 0000 0000 0000 0000 0000
00000010: 0000 0000 0000 0000 0000 0000 0000 0000
00000020: 0000 0000 0000 0000 0000 0000 0000 0000
00000030: 0000 0000 0000 0000 0000 0000 0000 0000
00000040: 0000 0000 0000 0000 0000 0000 0000 0000
00000050: 0000 0000 0000 0000 0000 0000 0000 0000
...
...
Cette donnée en hexadécimal indique que toutes les valeurs de pixels après décodage sont nulles.
Lors du rendu d'une vidéo dans Safari, nous obtenons une capture d'écran comme celle-ci :
La question se pose : quel est cet espace colorimétrique ? J'ai nommé le fichier 601.mp4, mais nulle part dans la commande je n'ai spécifié d'espace colorimétrique, alors comment Safari a-t-il su quelle nuance de vert rendre ? Comment le navigateur sait-il que yuv (0,0,0) doit être égal à rgb (0,135,0) ? Évidemment, il existe un algorithme pour calculer ces valeurs. En fait, il s'agit d'une simple multiplication matricielle. (Remarque : certains formats de pixels, y compris yuv420p, nécessitent une étape de pré- et post-traitement pour la conversion, mais dans cette démo, nous omettrons ces subtilités.) Chaque espace colorimétrique a sa propre matrice. Comme nous n'avons pas spécifié la matrice d'espace colorimétrique lors de l'encodage de la vidéo, Safari fait simplement une hypothèse. On peut itérer sur toutes les matrices, multiplier toutes les valeurs RVB par les matrices inverses et voir à quoi elles correspondent,mais essayons une approche plus visuelle et voyons si nous pouvons comprendre ce que fait Safari.
Pour ce faire, j'insérerai des métadonnées dans le fichier afin que Safari sache quel espace colorimétrique est utilisé et n'ait pas à deviner.
ffmpeg -f rawvideo -s 320x240 -pix_fmt yuv420p -t 1 -i /dev/zero -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -colorspace smpte170m -color_primaries smpte170m -color_trc smpte170m -color_range pc -y 601vui.mp4
La commande ffmpeg reste à peu près la même, mais j'ai ajouté ce qui suit :
-color_trc smpte170m
-colorspace smpte170m
-color_primaries smpte170m
Il s'agit des métadonnées de l'espace colorimétrique dans lequel le fichier sera encodé. Je n'expliquerai pas les différences entre ces options, car cela nécessitera un autre article. Pour l'instant, nous nous contentons de définir tous l'espace colorimétrique dont nous avons besoin. smpte170m est le même que BT.601.
La spécification d'un espace colorimétrique n'affecte pas la façon dont le fichier est encodé, les valeurs de pixels sont toujours encodées en yuv (0,0,0). Pour vérifier cela, nous pouvons exécuter la commande sur le nouveau fichier
ffmpeg -i zero.mp4 -f rawvideo - | xxd
. Les drapeaux de l'espace colorimétrique ne sont pas ignorés, mais simplement écrits en quelques bits à l'intérieur de la section "informations d'utilisation vidéo" (VUI) dans l'en-tête du flux vidéo. Le décodeur va maintenant rechercher le VUI et l'utiliser pour charger la matrice souhaitée.
Et voici le résultat :
Avec et sans VUI, les vidéos sont rendues avec la même couleur. Essayons le fichier BT.709 :
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -y 709.mp4
Nouvelles options :
-i 601vui.mp4
— 601vui.mp4
-vf "colorspace=all=BT.709"
— ffmpeg, . yuv rgb, . «all» — color_primaries, colorspace color_trc.
Ici, nous prenons la vidéo 601vui.mp4 et utilisons un filtre d'espace colorimétrique pour convertir en BT.709. Le filtre d'espace colorimétrique peut lire l'espace colorimétrique des données entrantes à partir du fichier vui 601vui.mp4, il nous suffit donc de spécifier l'espace colorimétrique que nous souhaitons recevoir sur la sortie. En exécutant la
commande pour ce fichier
ffmpeg -i 709.mp4 -f rawvideo - | xxd
, on obtient après la transformation de l'espace colorimétrique les valeurs de pixels yuv (93,67,68). Cependant, lors du rendu du fichier, il doitressemble. Il convient de noter que les résultats finaux peuvent ne pas être identiques car nous continuons à utiliser 24 bits pour encoder chaque pixel, et le BT.709 a une gamme de couleurs légèrement plus large. Par conséquent, certaines couleurs du BT.709 ne correspondent pas exactement au BT.601 et vice versa.
En regardant le résultat, vous pouvez clairement voir que quelque chose ne va pas. Le nouveau fichier est rendu avec des valeurs RVB de 0,157,0 - beaucoup plus lumineuses que le fichier d'entrée.
Examinons de près les propriétés du fichier à l'aide de l'application ffprobe :
ffprobe 601vui.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc, smpte170m), 320x240, 9 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
ET
ffprobe 709.mp4:
Stream #0:0(und): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p(pc), 320x240, 5 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
La plupart des informations ici ne sont pas importantes pour nous, mais nous remarquerons que 601vui.mp4 est au format de pixel "yuvj420p (pc, smpte170m)". C'est ainsi que nous comprenons que le fichier a le bon VUI. Mais 709.mp4 ne contient que "yuvj420p (pc)". Il semble que les métadonnées de l'espace colorimétrique n'aient pas été incluses dans le fichier de sortie. Même si le filtre d'espace colorimétrique a pu lire l'espace colorimétrique d'origine et que nous avons spécifié explicitement le nouvel espace, ffmpeg n'a pas écrit le vui correct dans le fichier final.
C'est mauvais... Ffmpeg est l'outil de conversion vidéo le plus populaire. Et il manque des informations sur les couleurs. C'est probablement la raison pour laquelle de nombreuses vidéos ne contiennent pas de métadonnées d'espace colorimétrique et, par conséquent, de nombreuses vidéos sont rendues avec des couleurs incompatibles. Pour la défense de ffmpeg, c'est un problème délicat. Pour initialiser l'encodeur, vous devez connaître à l'avance l'espace colorimétrique. De plus, l'espace colorimétrique peut être modifié avec un filtre vidéo. C'est un problème délicat à résoudre dans le code, mais il est toujours triste que ce comportement soit standard.
Vous pouvez contourner ce problème en ajoutant manuellement des métadonnées d'espace colorimétrique :
ffmpeg -i 601vui.mp4 -an -vcodec libx264 -profile:v baseline -crf 18 -preset:v placebo -vf "colorspace=range=pc:all=bt709" -colorspace bt709 -color_primaries bt709 -color_trc bt709 -color_range pc -y 709vui.mp4
En conséquence, la valeur de couleur dans 709vui.mp4 sera rgb (0.132.0). La luminosité du canal vert est légèrement inférieure à celle du 601vui.mp4, mais comme la conversion de l'espace colorimétrique se fait avec perte, et que le résultat me convient, nous l'appellerons succès.
De cela, nous pouvons conclure que lorsqu'aucun espace colorimétrique n'est spécifié dans le fichier, Safari suppose qu'il s'agit de BT.601. Et du côté de Safari, c'est une très bonne hypothèse. Mais comme dit ci-dessus, BT.601 est la norme vidéo SD et BT.709 est la norme vidéo HD. Regardons les vidéos HD avec et sans VUI et voyons comment Safari les rend. J'ai utilisé les mêmes commandes ffmpeg, je n'ai changé la résolution qu'en 1920x1080.
En SD et en HD, la couleur est rendue de la même manière. Safari ne prend pas en compte la résolution lorsqu'il fait une hypothèse sur l'espace colorimétrique. Apple est dans le domaine des médias et de l'édition depuis longtemps, donc je m'attendais à ce que le produit de cette société fournisse des résultats décents. Mais même si tout est si intelligent dans Safari, il est intéressant de voir comment la situation est dans d'autres navigateurs.
Chrome:
Chrome rend la vidéo 601 légèrement plus sombre que Safari, mais 709 a la même apparence. Je soupçonne que la différence est due aux optimisations de vitesse dans les calculs en virgule flottante, mais cela n'est pas pertinent pour notre test.
Je sais par expérience que lorsque l'accélération matérielle est désactivée dans les paramètres, Chrome s'affiche différemment :
En examinant ce résultat, nous pouvons voir que les valeurs dans 601 sont rendues très similaires aux précédentes, mais les fichiers 709 sont rendus comme s'ils n'avaient pas de VUI. De là , nous pouvons conclure que Chrome, avec l'accélération matérielle désactivée, ignore simplement le VUI et rend tous les fichiers comme s'ils étaient au format 601. Cela signifie que les 709 fichiers ne seront pas lus correctement.
Enfin, explorons Firefox :
Il y a beaucoup à faire ici. Étant donné que 709.mp4 et 709vui.mp4 se ressemblent, vous pouvez conclure que si VUI n'est pas disponible, Firefox adoptera le format BT.709. Le rendu correct de 601vui.mp4 signifie que pour le contenu BT.601, la section VUI est prise en compte. Cependant, lorsqu'un fichier BT.601 sans VUI est rendu en 709, il devient très sombre. Évidemment, il est impossible de restituer correctement une image sans toutes les informations nécessaires, mais la méthode choisie par Firefox dénature davantage la couleur que celle choisie par les navigateurs Safari et Chrome.
Comme nous pouvons le voir, la situation du rendu des couleurs vidéo est toujours le Far West. Malheureusement, nous n'avons couvert qu'une partie du problème. Nous n'avons pas encore étudié Windows. Faisons cela.
Microsoft Edge :
Il semble que Edge (au moins sur mon ordinateur) ignore simplement VUI et affiche tout en 601.
Chrome (avec l'accélération matérielle activée):
La situation n'est pas très différente de celle du Mac. Si VUI est présent, il est géré correctement, mais s'il n'est pas présent, il est supposé être BT.601 pour le contenu SD et BT.709 pour le contenu HD. C'est le seul navigateur dans lequel j'ai vu cela, mais il y a une certaine logique à cela. Comme le rendu se fait différemment que sur Mac, je soupçonne que le problème vient du système d'exploitation ou, plus probablement, quelque chose au niveau des pilotes de la carte vidéo, et ce choix n'a pas été fait par l'équipe de développement de Chrome.
Firefox se comporte exactement comme sur un Mac.
Pour Linux, iOS, Android, Roku, Fire TV, les téléviseurs intelligents, les consoles de jeux, etc., je laisserai cela en exercice pour le lecteur.
Qu'avons-nous appris ? Le plus important : toujoursincluez des métadonnées d'espace colorimétrique dans vos vidéos. Si vous utilisez ffmpeg et ne définissez pas d'indicateurs de couleur, vous ne travaillez pas correctement. Deuxièmement, bien que ffmpeg soit un programme formidable, sa popularité, sa facilité d'utilisation et ses paramètres par défaut mal choisis ont été un mauvais service. Vous ne devez jamais supposer que le logiciel est suffisamment intelligent pour le comprendre tout seul. Les chefs de projet de Ffmpeg, Google, Mozilla, Microsoft (et probablement Nvidia et AMD) doivent se réunir et travailler ensemble pour trouver un moyen. Je comprends qu'il n'y a pas de bonne solution ici, mais mauvaise et prévisible vaut mieux que mauvaise et aléatoire. Personnellement, je recommande de toujours supposer le format BT.601 si la section VUI est manquante. Cela crée le moins de distorsion. Peut être sélectionné pour aligner cette norme FOMS, voire l' AOM , car ces organisations sont assez bien représentées.
Enfin et surtout, si vous avez une vidéo sans informations de couleur et que vous devez la convertir ou la rendre, alors bonne chance !
Publicité
VDSina propose des serveurs bon marché avec un salaire journalier. Le canal Internet pour chaque serveur est de 500 Mégabits, une protection contre les attaques DDoS est incluse dans le tarif, la possibilité d'installer Windows, Linux ou l'OS en général à partir de votre image, et aussi un panneau de contrôle de serveur propriétaire très pratique . Il est grand temps d'essayer ;)
Rejoignez notre chat sur Telegram .
