Encodage de vidéo WebM en ligne de commande

Date: 28/05/2010 | Catégories: Gstreamer,Open-source,Planet-libre,Video,Web | Tags: ,,,,,

Le format multimédia WebM fait beaucoup parler de lui ces derniers temps. Sous l'impulsion de Google, il a pour objectif de devenir le standard libre pour la diffusion de fichier vidéo sur Internet. Sans entrer dans les polémiques de qualité et des problèmes de licence, nous allons dans ce billet voir comment encoder un vidéo dans un format WebM en ligne de commande en utilisant le framework GStreamer, fourni en standard sous GNU/Linux.

WebM, c'est quoi donc ?

En fait WebM est un conteneur multimédia, une enveloppe au même titre que OGG, MP4  ou AVI. Quand on parle de fichiers au "format WebM", cela sous entant l'utilisation des codecs audio Vorbis et vidéo VP8 (racheté il y a quelques mois par Google à la societé On2).

Avant de tester l'encodage d'un fichier WebM sur votre distribution GNU/Linux. Sous Ubuntu, il faut d'abord vérifier que vous disposez de la dernière version PPA de GStreamer:

sudo add-apt-repository ppa:gstreamer-developers

sudo aptitude update

sudo aptitude upgrade

sudo aptitude install gstreamer0.10-x gstreamer-tools gstreamer0.10-plugins-base gstreamer0.10-plugins-good gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer0.10-plugins-ugly gstreamer0.10-plugins-ugly-multiverse gstreamer0.10-ffmpeg gstreamer0.10-alsa gstreamer0.10-sdl

Enfin on vérifie que l'on a les bons plugins:

# gst-inspect | grep webmmux

matroska: webmmux: WebM muxer

 

# gst-inspect | grep vp8enc

vp8: vp8enc: On2 VP8 Encoder

 

gst-inspect | grep vorbisenc

vorbis: vorbisenc: Vorbis audio encoder

Passons maintenant aux choses sérieurses...

Encodage au format WebM

Pour mes test j'ai utilisé une bande annonce du film "Prince of persia" en qualité HD 1080p récupérée sur le site HDTrailers.

J'utilise ensuite la pipeline (ligne de commande) suivante pour effectuer l'encodage:

gst-launch -t filesrc location=pp_rltA_1080.mov ! progressreport \

! decodebin name=decoder decoder. \

! queue ! audioconvert ! vorbisenc quality=0.5 \

! queue ! webmmux name=muxer decoder. \

! queue ! ffmpegcolorspace ! vp8enc quality=5 speed=2 \

! queue ! muxer. muxer. ! queue ! filesink location=pp_rltA_1080-Q5.webm

La qualité vidéo par défaut (option quality=5) n'est pas terrible, on obtient de meilleurs résultats en l'augmentent. Voici un tableau comparatif:

FormatCodecsTailleAperçu (clique pour agrandir)
Source HQ .movAudio: AAC 48 Khz
Video: H.264
126 Mo
WebMAudio: Vorbis 

Video: VP8 "Quality 5"

24 Mo
WebMAudio: Vorbis 

Video: VP8 "Quality 6"

30 Mo
WebMAudio: Vorbis 

Video: VP8 "Quality 7"

40 Mo
WebMAudio: Vorbis 

Video: VP8 "Quality 8"

61 Mo
WebMAudio: Vorbis 

Video: VP8 "Quality 9"

73 Mo
WebMAudio: Vorbis 

Video: VP8 "Quality 10"

92 Mo

Je trouve que la paramètre quality=7 est un bon compromis taille/qualité. Il faut noter que la source est d'un  qualité nettement supérieure (je ne connais pas les paramètre H.264 utilisés).

Comparaison avec les codecs Theora et H.264

Pour compléter ce petit test de WebM, nous allons comparer maintenant le résultat obtenu avec le paramètre quality=7 et les codecs Theora (avec une qualité égale à 7) et X.264 (avec une qualité de 23 équivalente).

Voici les lignes de commandes utilisées, pour l'encodage en WebM (VP8/Vorbis):

gst-launch -t filesrc location=pp_rltA_1080.mov ! progressreport \

! decodebin name=decoder decoder. \

! queue ! audioconvert ! vorbisenc quality=0.5 \

! queue ! webmmux name=muxer decoder. \

! queue ! ffmpegcolorspace ! vp8enc quality=7 speed=2 \

! queue ! muxer. muxer. ! queue ! filesink location=pp_rltA_1080-Q7.webm

puis en OGG (Theora/Vorbis):

ffmpeg2theora -v 7 --optimize pp_rltA_1080.mov -o pp_rltA-1080-Q7.ogg

et enfin en MP4 (X.264/FAAC):

x264 --tune animation --crf 23 -o pp_rltA-1080-Q7.mp4 pp_rltA_1080.mov

On obtient les résultats suivants:

FormatCodecsTailleAperçu (clique pour agrandir)
WebMAudio: Vorbis 

Video: VP8 "Quality 7"

40 Mo
OGGAudio: Vorbis 

Video: Theora "-v 7"

57 Mo
MP4Audio: AAC 

Video: X.264 "CRF 23"

56 Mo

Que peut on en déduire ? Niveau qualité, le format H.264 garde une longueur d'avance (mais pour combien de temps). Theora est en dessous. Par contre le taux de compression est bien meilleur avec le codec VP8 mais encore faut il être sur que l'on peut comparer les paramètres utilisés...

A vous de vous faire une idée !

Conclusion

Bien que "jeune" ce format de fichier semble avoir un bel avenir. Surtout si Google arrive à l'imposer comme un "standard industriel" (sic). Avec des leviers comme YouTube et Google Chrome, j'ai peu de doute sur le résultat des courses qui ne se fera pas sur un plan technique mais sur la capacité de chacun de défendre son format.

  • Bon article, mais pas de VP8ENC disponible pour moi.

  • Pingback: Tweets that mention Encodage de vidéo WebM en ligne de commande -- Topsy.com()

  • Génial, merci !!
    Ça fonctionne parfaitement (à l’inverse de la solution avec ffmpeg que tu avais filé).
    Au passage, un petit « sudo apt-get upgrade » après le update m’a été nécessaire.
    Moi qui héberge beaucoup de vidéos sur mon site, j’ai la banane depuis que le webm est sorti et opensource.

  • @loo: l’encodeur vp8enc est pourtant disponible, il faut penser à faire un « sudo aptitude upgrade », je le rajoute de ce pas dans l’article.

  • Nikos

    Salut,

    personnellement, je ne trouve pas que tes tests soient très…parlants.
    Je pense qu’il aurait fallu aussi faire des tests avec qpsnr pour voir la différence de qualité, mais aussi voir la différence de qualité en image sur des moments où la vidéo implique du mouvement !
    En effet, là où la vidéo est de la pire qualité c’est lorsqu’il y a du mouvement, ainsi que des changements de plans…ça provoque parfois (MPEG avec ffmpeg) du macroblocking ! cela donne ce genre de problème:
    http://forum.ubuntu-fr.org/viewtopic.php?id=349379

  • Emeric

    Humm ces tests ne me paraissent pas pertinents. Quelques pistes :

    Déjà il ne me semble pas que tu compare exactement les mêmes frames, ensuite il faudrait comme dit plus haut comparer par exemple une idr et une image non idr (b ?) au hasard, pour voir le boulot sur le mouvement.

    Ensuite tu compare un h264 de 56mo à un vp8 de 40mo, ce qui ne les placent pas (du tout du tout) sur un même pied d’égalité !
    En compression vidéo on peut établir une corrélation plus ou moins directe entre la taille et le débit. 40% de taille en plus, c’est une vidéo encodée avec un débit potentiellement 40% supérieur. Loin d’être négligeable si tu veux faire une comparaison entre 2 images, même si « à l’oeil » ça peut sembler sans grande importance.

    Pense à enlever le son aussi, si il n’est pas dans le même format ça implique taille variable dans les fichiers, donc taille reversée pour la vidéo légèrement faussée entre les deux codecs.

  • @Nikos et @Emeric: effectivement, la comparaison n’est pas des plus rigoureuse mais le but de ce billet est plus de donner les outils pour pouvoir se faire une idée par soit même.

    @Emeric: Vu que ce sont des algos différents, est il valable d’encoder en H.264 et VP8 avec des paramètres donnant une même taille de fichier ? A ton avis, quel est l’équivalent d’une qualité 7 de VP8 en H.264 ?

  • Emeric

    @NicoLargo A ton avis, quel est l’équivalent d’une qualité 7 de VP8 en H.264 ?
    Franchement aucune idée, j’ai pas pu touché à vp8 encore.

    Pour comparé des encodeurs différents, il faut le faire sois au même débit pour comparer la compression, soit à la même taille de fichier pour comparer la qualité d’image.
    Après h264 par exemple fonctionne bien mieux en débit variable, donc tu lui donne la taille de fichier voulue ou le débit moyen (encore une fois ça devrait revenir globalement au même) et il se débrouille pour gérer dynamiquement le débit. Je ne sais pas comment ce comporte vp8 à ce niveau.
    A noter que la comparaison avec psnr entre deux algos différents est très peu fiable. Et globalement pas fiable.

  • G-rom

    Idem je ne trouve pas les comparaisons très pertinentes. VP8, H.264 et x.264 étant très similaire il aurait fallu partir d’une base MPG2 compressée dans ces différents formats pour les comparer sur un semi pied d’égalité, et non partir d’une base H.264

    Tu compares ensuite les seuls images, en évoquant le gain en taille, alors qu’on ne sait pas si ce gain est du à la parti vidéo ou audio ou les deux.

    Le plus intéressant aurait été de comparer une vidéo sans son en MPG2 avec une taille conséquente, compressée avec les même paramètres (dans la mesure du possible) en H.264, x264 et VP8 suivi d’un autre comparo pour le son. (plus dur là pour offrir de prévisu sur un blog :p)
    Sachant qu’enfin le conteneur du WebM étant une base de MKV à de gros avantages sur le MP4 la comparaison est plus facile 🙂

  • Pingback: Nicolargo : Installation et test de Flumotion 0.8 | Le Techno Mag()

  • Et ben… Je viens de découvrir sous Debian flumotion 0.4.xxx, qui ne fonctionne pas et je tombe sur votre tuto! Génial!
    Je suis entrain de monter un cine-club, et je vais tester de suite le flumotion 0.8.0.
    Mais que me conseillez-vous comme codecs pour avoir une bonne image et son, et que cela ne pèse pas 3Gb par film?
    Actuellement les films sont en MP4, afin qu’ils puissent être vus sur iPhone,iPade, etc…
    Le site ci-dessus est en phase de test!
    Au plaisir de vous lire.

    • En terme de qualité, le codec MPEG4 (ou H.264) garde pour moi une petite longeur d’avance sur les codecs vidéo libre que sont VP8 (WebM) et Theora (OGG). L’encodeur X.264, qui produit des fichiers vidéos au format H.264 est vraiment très performant.

      Une question sur ton projet de cine-club, vas tu encoder tes films en HD ?

      • En réponse pour le HD: oui, j’aimerais bien.
        Maintenant, j’ai eu un problème à l’installation de flumotion 0.8! En effet, il me fixe des ports automatiquement 7531 pour le SSL et 8642 pour le port normal. Le seul problème, c’est qu’il me dit que les ports n’existent pas!!
        De plus, il m’a complètement empêcher d’aller sur mon Panel d’administration des serveurs…
        Si tu as une idée, je suis preneur!
        D’avance merci et Bonne Année 2011.
        LG

        • Pour la HD, il ne faut pas espérer obtenir des fichiers de moins de 3 GB surtout si ta piste audio doit rester multi channel.

          Pour l’installation de Flumotion, as tu suivi ce tuto:

          http://blog.nicolargo.com/2010/11/installation-et-test-de-flumotion-0-8.html

          Il semble que tes processus ne soient pas bien lancés. Regardes du coté des logs.

          • Bonsoir,
            Oui, j’ai suivi le tuto à la lettre! Je l’ai même imprimer!
            Mais quand je lance le processus
            flumotion-manager ~/flumotion/conf/planet.xml &
            Il me marque ceci:
            debian:~# Traceback (most recent call last): File « /usr/local/bin/flumotion-manager »,line 46, inboot.boot (PROGRAM_PATH,gst=False,gtk=False,installReactor=False)
            file « /usr/local/lib/flumotion/python/flumotion/common/boot,py », line 216, in boot from twisted.copyright import version
            ImportError:No module named twisted.copyright.
            Fin…
            Si tu comprends quelque chose là, dis-le moi, je n’y comprend rien!!!

            Merci

          • Essayes la commande suivante:

            sudo aptitude install python-twisted

            Puis relance Flumotion, cela devrait résoudre ton problème.

  • Et bien non!
    le seul résultat que j’ai c’est:
    [1] 17818 et il retourne en ligne de commande!

  • encore une question:
    Quand tu lances flumotion-worker -v -u user -p test
    Est-ce juste ou bien faut-il rentrer le user et le passwd que l’on a mis dans planet.xml?
    Parce que si je rentre avec flumotion-worker user et test, il marque WARN access denied
    et si je rentre avec le user et le passwd mis dans planet.xml, il me met une page d’INFO!

  • ben tu vas dire que j’abuse… Mais à 60 ans, je n’aime pas me laisser embêter par une machine!
    Le tuto que tu as fait, il concerne uniquement Ubuntu Desktop, ou bien tu peux l’installer sous Ubuntu Server 10.10? Sous Debian, impossible…
    C’est soit il manque des dépendances ou alors…Je suis nul!!!

    • Tu n’abuses pas 🙂

      Je n’ai jamais fait l’installation sous Ubuntu Server. Le seul problème est que, par défaut, Ubuntu Server n’a pas d’interface graphique (X) dont pas possible de lancer flumotion-admin…

      Si tu as le choix je te conseille de partir sur un Ubuntu Server 10.04 (c’est une version LTS) et de spécifier que tu veux installer le serveur X pendant l’installation.

      PS: peux tu poster tes commentaires dans le billets sur Flumotion, histoire que d’autres lecteurs puissent profiter de ton expérience ?

  • Pingback: WebM: prêts pour l’encodage :D | Fansub Streaming - Actu numérique, Japon et streaming de fansubs()

  • jeffnerohardy

    COMMENT ENCODE DU WEBM EN XVID