Comment préserver autant que possible les couleurs RVB en convertissant une série de fichiers PNG en un conteneur vidéo avec ffmpeg?

J'ai 950 fichiers PNG qui sont destinés à devenir des images individuelles dans une piste vidéo de 38 secondes à 25 images par seconde. Les noms de fichier sont identiques à l'exception du numéro de séquence, comme il est d'usage dans ce type de cas.

Je souhaite produire un conteneur d'un format largement pris en charge, idéalement WebM si tous les critères sont remplis, ou MPEG-4 par exemple, avec un codec pris en charge par les navigateurs modernes pour la lecture, à partir de cette série d'images PNG I avoir. Le problème est que les couleurs sont décalées et que la couleur d'arrière-plan de la vidéo décodée ne correspond plus au même triplet RVB échantillonné à partir de la couleur d'arrière-plan des images PNG. La vidéo ressort de l'arrière-plan prévu sur la page HTML où la vidéo est incorporée.

J'ai essayé le simple:

ffmpeg -f image2 -i image%03d.png output.webm

ce qui m'a en effet donné une piste vidéo VP9 à 25 fps emballée dans un conteneur WebM.

Les images PNG sont de style animation, avec un arrière-plan solide et des formes simples animées pour le premier plan. Ils semblent être sans étiquette (c'est ce que me dit Adobe Bridge, je suppose que cela signifie qu'aucun profil de couleur n'est incorporé ou qu'une référence à un profil). Le problème de ma tentative ci-dessus est que, même si le conteneur est lu dans Chrome, la couleur d'arrière-plan échantillonnée à partir de l'image PNG, avec triplet RGB #ED4D56, ne correspond pas de manière perceptuelle à la couleur d'arrière-plan qui apparaît dans la vidéo en cours de lecture.

Est-ce un effet secondaire inévitable de la conversion des couleurs RVB à YUV (encodage) à RVB (lecture)? Y at-il un moyen d'atténuer cela? Je n'insiste pas pour que les images de la piste vidéo soient encodées en RVB, je suppose que YUV convient, tant qu'un navigateur moderne lisant ces images produit le même résultat (avec une marge d'erreur négligeable), un triplet RVB lors du décodage et de l'affichage des informations. cadres).

Ma question est la suivante: quelle ligne de commande ffmpegpeut-on utiliser pour atténuer cela? Je suis ouvert à changer le codec vidéo, le format de pixel, activer la gestion des couleurs dans ffmpeg s'il existe, etc.

J'ai eu une tâche très similaire récemment et je dirais qu'il n'y a toujours pas de solution parfaite (à partir d'octobre 2018). C'est l'effet secondaire de la conversion de couleurs RVB à YUV à RVB de faible précision. Même certaines variantes de codecs "sans perte" (par exemple libvpx-vp9 -lossless) produisent des couleurs déformées en raison de l'espace de couleur YUV.

• Si des couleurs non exactes sont acceptables, le codec libvpx peut faire un très bon travail:

  ffmpeg -r 25 -i image%03d.png -c:v libvpx -crf 4 -b:v 0 output.webm
  

  Avec ces paramètres, le décalage de couleur ou même les couleurs exactes de certains jeux de cadres est négligeable. Les codecs VPx sont largement pris en charge (tous les principaux navigateurs sauf IE et Safari) et produisent une taille de fichier raisonnable.

• Si les couleurs exactes sont strictement requises, nous devons éviter la conversion d’espace colorimétrique. La seule solution inter-navigateur que j'ai proposée consiste à utiliser des images png animées. ffmpegn’a qu’un support très basique pour apng, il est donc préférable d’utiliser d’autres outils, par exemple apngasm:

  apngasm output.png image001.png 1 25
  

  cela fonctionnera partout sauf dans IE et Edge (dans ce cas, il retournera à la première image statique). La taille des fichiers est énorme, mais c'est le prix à payer pour le véritable encodage sans perte.

• Le codec libx264rgb doit également être mentionné - son utilisation sera le moyen correct d’encoder les couleurs RVB précises lorsque / si les navigateurs le prennent en charge.