Pour un site owncloud familial, j'héberge des vidéos ogg/theora qui sont affichées dans un lecteur html5 des navigateurs. J'ai donc besoin de codecs lisibles directement par le navigateur. J'utilise theora mais j'aimerais passer à webm, dont on dit beaucoup plus de bien.
Pour ogg/theora, j'utilise les commandes suivantes (trouvées sur stackoverflow) :
-
ffmpeg -i FICHIER -b 1500k -vcodec libtheora -acodec libvorbis -ab 160000 -g 30 sortie.ogv
, ou bien -
ffmpeg2theora FICHIER
(au choix avec la précédente)
Pour matroska/webm, la commande équivalente est :
ffmpeg -i FICHIER -b 1500k -vcodec libvpx -acodec libvorbis -ab 160000 -f webm -g 30 intermediaire.webm
mkvmerge -o sortie.webm -w intermediaire.webm
Remarques concernant la commande mkvmerge (paquet mkvtoolnix) : il s'agit de mettre dans un conteneur Matroska. En fonction du codage utilisé par l'appareil qui a produit l'original, firefox n'arrive pas toujours à lire si on ne fait pas mkvmerge (alors que chromium et opera s'en sortent bien avec tous mes appareils). Utiliser mkvmerge impose le conteneur matroska ce qui résout le problème. ffmpeg supporte aussi -f matroska
sans passer par mkvmerge mais firefox trouve que le fichier est corrompu (encore une fois, les autres navigateurs s'en sortent). Enfin, bien que le suffixe canonique du conteneur soit .mkv, les navigateurs ne comprennent pas qu'il s'agit d'une vidéo si on l'appelle .mkv, d'où le nom .webm.
Or d'après mes essais, les fichiers matroska/webm sont plus gros que les fichiers ogg/theora, tous les paramètres d'encodage étant égaux, et sans différence de qualité en première impression visuelle. Voici des exemples de tailles en octets :
- Vidéo.mp4 : 1 985 618 (original compressé produit par un ordiphone) .
- Vidéo.webm : 3 912 334 (ffmpeg 1.0.2) / 3 910 532 (ffmpeg 1.2.3)
- Vidéo.ogv : 3 865 656 (ffmpeg 1.0.2) / 3 864 127 (ffmpeg 1.2.3)
- Vidéo.ogv : 1 933 461 (ffmpeg2theora)
Ma commande ffmpeg conduit dans ce cas à un fichier plus gros que l'original (ça dépend des réglages de compression de l'appareil qui a produit le fichier, ce n'est pas le plus important ici), alors que ffmpeg2theora (sans argument) utilise des valeurs par défaut plus faibles et conduit à un fichier plus petit. Mais surtout, on remarque que .webm est 1,2 % plus gros que le fichier .ogv, alors que le niveau de qualité défini par le débit (bitrate) est le même.
Une augmentation de 1,2 % en taille ce n'est pas la mort (je suis encore loin de la limite en trafic consommé fixée pour l'hébergement de ce site), mais puisqu'on dit que webm est meilleur que theora, c'est bien qu'il est censé produire des fichiers plus petits à qualité égale. Est-ce que j'utilise des paramètres incorrects, avez-vous des conseils pour les arguments à passer pour tirer le meilleur parti de webm ?
2013-09-04 Remarques postérieures
Les fichiers plus haut ne montraient aucune différence de qualité entre theora et webm parce que codés à 1500k, ce qui est dans tous les cas une très très bonne qualité. La différence de qualité entre les deux codecs apparait clairement lorsqu'on réduit le débit par exemple 500k ; la taille est toujours à peu près la même (à quelques pourcents près) mais webm est clairement plus agréable à regarder.
Finalement j'ai choisi les paramètres suivants : ffmpeg -i FICHIER -b:v 750k -crf 10 -vcodec libvpx -acodec libvorbis -ab 160000 -f webm -g 30 intermediaire.webm
La paramètre crf est un paramètre de qualité complémentaire au débit et qu'il vaut mieux donner. Une bonne valeur de départ est 10 ; on peut mettre n'importe quel entier entre 4 (meilleure qualité) et 63 (plus mauvaise qualité).
# L'erreur est dans la qualité par bitrate
Posté par ʭ ☯ . Évalué à 7.
La vidéo, c'est des images parfois très différentes qui se succèdent. En imposant un bitrate, tu refuses aux encodeurs modernes leur capacité à garder une qualité constante.
J'ai pas encore fouillé sur webm, mais en tout cas pour le format breveté h264 il faut indiquer un niveau de qualité QP qui reste dans tes contraintes de débit.
Sinon, en plus simple, demande donc 1000 kbits au lieu de 1500 à webm pour voir si la qualité se dégrade.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: L'erreur est dans la qualité par bitrate
Posté par JGO . Évalué à 5.
J'ai enlevé le paramètre de bitrate. Les fichiers sont bien plus petits que les tailles plus haut : ogv 793 106 ; webm 820 505. Le fichier ogv est toujours un peu plus petit (4 %) que le fichier webm mais cette fois-ci la différence de qualité est visible et nettement en faveur de webm.
[^] # Re: L'erreur est dans la qualité par bitrate
Posté par JGO . Évalué à 3. Dernière modification le 01 septembre 2013 à 16:15.
Après avoir vérifié dans le manuel de ffmpeg pour libvpx, l'indication du bitrate est très fortement recommandée. Il s'agit d'une valeur moyenne (VBR) qui permet à l'encodeur de choisir le débit instantané tant qu'il marche en moyenne. L'erreur est de ne pas avor indiqué le paramètre -crf qui définit la qualité moyenne , en plus du birate.
« Important: If neither -b:v nor -crf are set, the encoder will use a low default bitrate and your result will probably look very bad. Always supply one of these options—ideally both. » — http://trac.ffmpeg.org/wiki/vpxEncodingGuide
# Document généraliste sur les vidéos en HTML5
Posté par jihele . Évalué à 4.
Je ne sais pas si ça va aider, mais quand j'ai voulu publier des vidéos, ce guide m'a rendu service :
http://diveintohtml5.info/video.html
[^] # Re: Document généraliste sur les vidéos en HTML5
Posté par fravashyo . Évalué à 2.
pour résumer ce qui est dit, et aussi d'après ma propre expérience, si vous encodez et diffusez en webm et en h264, vous toucherez la plupart des navigateurs modernes. Theora ne me semble pas avoir beaucoup d'intérêt, la qualité est moindre par rapport à webm et ça pourrait être seulement utile pour les très vieilles versions de firefox.
« I approve of any development that makes it more difficult for governments and criminals to monopolize the use of force. » Eric Raymond
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.