Vous souhaitez vous passer de flash et publier des vidéos grâce au standard vidéo HTML5 ? Vous avez trouvé l’article qu’il vous faut !

Le nouveau standard vidéos que nous apporte HTML5 permet aux webmasters et aux internautes de se passer de flash player. Ceci est une très bonne chose pour trois raisons :

• Flash est un format propriétaire – il appartient à Adobe – et son omniprésence sur le web rend ce dernier dépendant d’une entreprise et de son bon vouloir en ce qui concerne les mises à jour, la sécurité etc…
• Le plugin d’Adobe pour navigateur, flash player, consomme beaucoup de ressources processeur, ce qui pose problème sur les terminaux peu puissants et diminue l’autonomie des portables lorsqu’ils sont sur batteries;
• Enfin, certains appareils ne supportent pas la technologie flash (notamment certains smartphones et tablettes, dont tous les iphones et ipad) et il leur est donc impossible de lire ce type de vidéos.

Le format, une question de compatibilité

L’apparition du standard vidéo HTML5 va donc permettre de répondre, dans une certaine mesure, à ces problématiques. Dans une certaine mesure seulement car le standard comprend trois formats différents de vidéos, deux libres, l’OGG Theora et le WebM de Google, et un format propriétaire, le MP4/H264.

Comparés à il y a quelques années (notamment en 2012 quand j’ai initialement écrit cet article), les choses se sont grandement améliorées. La plupart des navigateurs récents acceptent le h264/mp4 et il est aujourd’hui un des meilleurs choix en terme de performance. De plus, bien qu’il ne soit pas libre, ce dernier est sans royalties (même pour les usages commerciaux).

Puisque j’ai rapidement parlé des bonnes performances du h264, sachez qu’une nouvelle générations de codecs commence à émerger… parés pour la 4K. Le h265, successeurs du h264 est directement concurrencé par le webM/VP9. Ce dernier vient corriger le léger manque de performances de la précédente mouture face au h264.

Malheureusement, ces deux formats sont pour l’instant supportés par très peu de navigateurs et le h265 ne sera pas gratuit pour les usages commerciaux. Cependant, la 4K n’est pas encore la première préoccupation du web et le h264 permet très clairement de proposer des contenus en HD voir full HD de tailles très raisonnables. Quand on sait qu’il n’y a pas si longtemps, on regardait des vidéos de seulement 240p, estimons-nous heureux !

Le mp4/264 permet de couvrir l’ensemble des navigateurs récents – sauf Opéra mini qui ne supporte pas la vidéo du tout. Les deux autres concurrents, libres, que sont webm et ogg ont une couverture moins large et des performances inférieures. Le mp4 semble donc être le choix de la raison…

Installer FFMPEG

Alors pour une fois sous Linux, on ne va pas pouvoir se contenter d’un petit sudo apt-get install ffmpeg. En effet, cette commande installerait bien ffmpeg, mais sans les codecs dont nous auront besoin, ce ne sera pas forcement la dernière version etc. Plusieurs choix s’offrent donc à vous.

Il faut ici relativiser, dans les versions récentes de Debian et d’Ubuntu, vous aurez quand même le mp4/h264 et le webm/vp8 ; si c’est donc de cela dont vous avez besoin, vous pouvez vous contenter de la méthode facile. En revanche, pour les toutes dernières avancées du h265 et du vp9, l’une des méthodes d’installation suivante seront un passage obligatoire.

Petit aparté, ffmpeg s’installe aussi très bien sous Mac avec Macports (je n’ai pas testé avec homebrew) : sudo port install ffmpeg.

Installer depuis un dépôt alternatif

Pour plus de détails sur ces commandes, je vous invite à jeter un œil à cet article dédié aux commandes linux. Comme je l’explique d’ailleurs dans l’article en question, FFMPEG avait été supprimé des dépôts officiels d’Ubuntu (réintégré en version 15.04) au profit de Libav, son fork. Pour profiter des dernières versions de FFMPEG sans avoir à compiler manuellement à chaque fois :

sudo add-apt-repository ppa:kirillshkrogalev/ffmpeg-next

# on met notre liste de packets à jour
sudo apt-get update

# s'il est déjà installé,
# un upgrade se chargera de le mettre à jour
sudo apt-get upgrade

Compiler depuis les sources

La procédure dépendra un peu de votre distribution, si vous êtes sous Ubuntu, suivez les instructions d’installation pas à pas pour la dernière version de ffmpeg.

Télécharger les static builds

Tout ça prend quand même pas mal de temps à compiler, il peut y avoir des erreurs etc… Donc la solution alternative – si vous ne comptez pas activer les paramètres spécifiques à la compilation – consiste à utiliser une version déjà compilée. Il vous suffit de la télécharger, de la dézipper, et vous lancerez l’exécutable comme ceci : ./ffmpeg -i …. Consultez les dernières versions pré-compilées en 64 bits ou en 32 bits. Copiez le lien de la version qui vous convient, ensuite, dans votre terminal faites :

# télécharger la version choisie
wget http://ffmpeg.gusari.org/static/64bit/ffmpeg.static.64bit.latest.tar.gz

# dézipper l'archive
tar -zxvf ffmpeg.static.64bit.latest.tar.gz

Vous avez donc ffmpeg et ffprobe, pour lancer ffmpeg, vous n’avez cas faire ./ffmpeg params en étant dans le même répertoire que l’exécutable, sinon il vou faudra fournir le chemin complet :
/home/dupond/ffmpeg params. Enfin, vous pouvez lancer votre exécutable dans un des répertoires du PATH si vous voulez pouvoir l’exécuter depuis n’importe où sans vous soucier du chemin, dans ce cas, déplacez-le dans /usr/local/bin :

sudo mv ffmpeg /usr/local/bin

Objectif de la mission, réaliser un encodage… de qualité

C’est bien le de qualité qui donne toute sa difficulté à cette mission. En effet, l’objectif – on parle bien de vidéos pour HTML5 – est de distribuer ces vidéos sur le web. Il faut donc qu’elles aient une taille raisonnable, sans quoi, à part les chanceux de Paris intramuros reliés en fibre 100Mb/s, personne ne pourra voir vos vidéos sans laisser charger toute une nuit… Autant dire que vos visiteurs seront partis bien avant. Cependant, avoir des vidéos pas trop lourdes, ne veut pas dire qu’il faut qu’elles soient complètement pixellisées. C’est donc une question de compromis.

Le mp4/H264

Il faut savoir ce que l’on veut faire. Pour ma part, je ne veux pas modifier l’aspect (la résolution) de ma vidéo, si elle est en 1080 x 720, je veux conserver cette résolution. Je ne spécifierai donc pas de résolution à l’encodeur. Ensuite, il faut définir le bitrate, l’encodeur x264 gère assez bien les paramètres seuls si on ne lui en spécifie pas. Seulement, si la vidéo que vous lui soumettez a un bitrate de 11mb/s, il conservera un très haut débit, et la vidéo sera lourde. Facile d’avoir une bonne qualité d’image avec une vidéo de 1Go pour 40min ! Voici les paramètres avec lesquels j’obtiens de bons résultats :

ffmpeg -i video-source.mkv -vcodec libx264 -preset slow -crf 24 -ab 192k video-reencodee.mp4

• -i video-source.mkv le i spécifie tout simplement “l’input”, le fichier vidéo en entrée que vous voulez encoder. Je ne dirai pas qu’il peut être dans tous les formats (il doit bien y a voir des formats non pris en charge), mais tous les formats courants fonctionnent
• -vcodec libx264 on précise que l’on veut utiliser l’encodeur x264.
• -crf 24 le crf amène les notions de quantizer, on opte pour une qualité constante en lieu et place d’un bitrate constant. Ce qui est somme toute plutôt logique étant donné que tous les passages d’une vidéo n’ont pas les mêmes besoins en ressources. 24 est un choix intermédiaire entre qualité et taille. On trouvera généralement des réglages allant de 15 (pour la meilleur qualité) mais non adapté à la diffusion sur le réseau, à 30 (qualité médiocre).
• -preset slow charge le preset donnant à ffmpeg les paramètres par défaut. Ici le preset slow spécifie que l’on privilégie la qualité au temps d’encodage. Les arguments vont de ultrafast à veryslow. Slow étant donc un compromis raisonnable pour obtenir une bonne qualité. La doc officielle n’étant pas toujours très complète, le site d’Ubuntu vous en dira plus sur les presets.
• -ab 192k on spécifie ici que l’on veut un débit audio de 192Kb/s.

Cependant, ces réglages ne spécifiant pas de bitrate vidéo maximal, si le fichier d’origine est très volumineux, on se retrouvera avec un fichier encodé très volumineux aussi, voir trop pour le diffuser en streaming sur une page web. Pour remédier à cela, on va spécifier un bitrate maximum. Après quelques heures d’encodage sur divers type de sources (différents formats, conteneurs, codecs et qualités), voici les réglages avec lesquels j’obtiens une bonne qualité, tout en conservant des tailles de fichier raisonnables.

ffmpeg -i video-source.mkv -vcodec libx264 -maxrate 8000k -bufsize 1000K -minrate 10k -crf 24 -preset slow -ab 192k video-reencodee.mp4

Quelques nouveaux paramètres font ici leur apparition :

• -maxrate 8000k et -minrate 10k correspondent aux taux minimum et maximum que l’on veut accepter dans notre vidéo. Le débit étant variable, les passages “pauvres” auront un débit plus faible (ce qui permet d’économiser sur la taille du fichier) tandis que les passages qui boostent auront de forts débits pour restituer tous les détails des scènes. Notez que si vous voulez encoder à bitrate constant, il suffit de mettre le même bitrate à minrate et à maxrate ;)
• -bufsize il s’agit ici de spécifier de combien le bitrate maximal peut être dépassé (de manière très courte pour certains passages intenses).

Voilà, donc en résumé pour l’h264, préférez la deuxième commande si vos vidéos sources ont un bitrate nettement supérieur à 700kbs et qu’il est nécessaire de diminuer leurs tailles. En revanche, si elles ont un bitrate inférieur (ou si vous préférez conserver une qualité proche de l’original, peu importe la taille du fichier de sortie), préférez la première commande. Pour creuser un peu plus, aller faire un tour sur le trac de ffmpeg [en].

WebM/VP8

J’ai bien expliqué au début de l’article que le h264 suffit à couvrir la majorité des navigateurs. Seulement, il n’est pas libre. Restent alors le webM et le ogg. Ce dernier étant vraiment vieux, le ratio qualité poids des fichiers n’est pas au rendez-vous. Je propose donc comme alternative libre le webM et explore un peu les réglages avec vous.

J’ai pu dire de l’encodeur x264 qu’il gérait bien les choses tout seul, ce n’est pas du tout le cas de l’encodeur pour WebM. Si vous ne spécifiez pas trop les paramètres que vous attendez, la qualité de rendu vidéo sera vraiment exécrable. Vous voilà prévenu ! Alors quels que soit la qualité de votre fichier source, il faudra lui spécifier un bitrate. Si celui-ci est inférieur à 700kbs, inutile de mettre autant… Voici la commande magique :

ffmpeg -i video-source.mkv -vcodec libvpx -vb 700k -maxrate 8000k -bufsize 1000K -minrate 10k -qmin 3 -qmax 30 -rc_lookahead 16 -keyint_min 0 -g 360 -skip_threshold 0 -level 116 -preset slow -ab 192k video-reencodee.webm

Alors là aussi on voit apparaitre de nouveaux paramètres. Explications :

• -vcodec libvpx il s’agit tout simplement du codec relatif au VP8
• -rc_lookahead 16 permet au codec de regarder les prochaines images pour adapter ses paramètres en conséquence
• -g 360 demande au codec de créer une image de référence toutes les 360 images
• -level 116 permet de passer en mode “lent”. Cela active des améliorations graphiques mais augmente le temps d’encodage. Vous pouvez la modifier en 216 pour gagner un peu de temps ou 214, mais vous perdrez en qualité
• -skip_threshold, il s’agit de nombre d’images que le codec peut se permettre de sauter, ici 0,

Ces trois derniers paramètres et les explications associées sont tout droit tirées de la page Ubuntu à laquelle je faisais référence plus haut.

Vous êtes maintenant bien armé pour mettre des vidéos au standard HTML5 sur votre site ! Il ne reste plus qu’à intégrer ça proprement et, peut-être, vous trouver un joli player javascript. Heureux ?