Sur Fansub Streaming, il y a des streams 
Autour de 1000 streams WebM, intégrés en HTML 5.
Dans cet article, nous allons apprendre la théorie sur le format WebM, ainsi que l’intégration de streams WebM dans les pages web La création de ces fichiers WebM ça sera pour un article ultérieur.
HTML 5: la guerre des formats
| Container | Format typique du flux vidéo | Format typique du flux audio | Soumis à payement de royalities |
| OGG | Theora | Vorbis | non |
| MP4 | MPEG-4 AVC « H.264″ | AAC | oui (au MPEG-LA) |
| WEBM | VP8 | Vorbis | non |
Support des formats dans les navigateurs et version minimale:
| Internet Explorer | Mozilla Firefox | Google Chrome | Apple Safari | Opera Software | |
| OGG | non | oui (3.5) | oui (3) | non | oui (10.50) |
| MP4 | oui (9) | non | non | oui (3.1) | non |
| WEBM | non | oui (4) | oui (6) | non | oui (10.60) |
Contexte: le web s’est depuis toujours développé autour de formats exempts de tout payement de royalities: vous pouvez utiliser ces formats sans vous acquitter d’une licence d’utilisation auprès de son ayant-droit. Mais coup de théâtre lors de la normalisation HTML 5 portant sur les éléments multimédia (vidéo et audio): le W3C n’exige pas de la part des navigateurs qu’ils n’utilisent pas de formats soumis à royalities. Deux intervenants ont immédiatement pris position, l’un contre l’autre: Apple et Mozilla. Le premier, qui possède des droits sur le format MPEG-4 AVC, poussa ce format dans son navigateur Safari. Le second, qui défend l’ouverture du web, s’appuya sur le seul format libre de tout royalities ayant été suffisamment développé alors: Theora.
Problème: si MPEG-4 AVC est unanimement reconnu comme le format vidéo à compression DCT le plus puissant du moment, Theora accuse un sérieux retard technologique, qui le place à peine mieux que MPEG-4 ASP, très connu sous l’appellation « DivX » .
La situation aurait pu durer si entre temps un nouveau mastodonte n’entra pas dans l’arène: Google inclua à Chrome à la fois des décodeurs MPEG-4 AVC et Theora. Et puis ils rachetèrent On2, l’entreprise qui créa le format VP3 dont est dérivé Theora: entre temps ils avaient développé de nouveaux formats, dont leur plus récent: VP8. Ce dernier, Google le plaça sous une licence spécifique « royality-free » , ce qui autorisa les autres défenseurs du web ouvert de supporter le format. VP8 est l’un des formats les plus proches de MPEG-4 AVC, réduisant drastiquement la différence qualitative entre MPEG-4 AVC et les formats « royality-free » .
Si Google, Mozilla et Opera Software se sont clairement positionnés en faveur des formats « royality-free » , Microsoft ne soutient que mollement MPEG-4 AVC (support à partir de Internet Explorer 9 seulement, parts de marché faibles) et Apple se retrouve isolé. Surtout que Google, avec sa plateforme Youtube, a le rôle de chef d’orchestre en la matière (et ce d’autant plus que les iPhone et iPad ne supportent pas Flash).
Les meilleurs encodeurs à l’heure actuelle
Un format peut avoir une qualité médiocre comme excellente, tout dépend de la puissance de l’outil utilisé pour générer ce format. On ne peut que difficilement comparer des formats entre eux, par contre on peut bien comparer les encodeurs. Dont voici quelques uns les plus efficaces actuellement (meilleure qualité pour un poids équivalent)
| Encodeur | Éditeur | Format | Licence |
| libtheora | Xiph | Theora | BSD |
| x264 | VideoLAN | MPEG-4 AVC | GNU GPL |
| Squeeze | Sorenson | MPEG-4 AVC | propriétaire |
| libvpx | VP8 | BSD renforcé |
libtheora est notamment présent dans l’encodeur ffmpeg2theora (édité par v2v.cc), outil simple d’usage et qui tire le meilleur pour le format Theora. Développement faible, progrès faible.
x264 est un projet parallèle chapeauté par la fondation VideoLAN, est un encodeur extrêmement puissant et complet, très souvent utilisé. Développement soutenu, progrès faible.
Squeeze est un logiciel d’encodage multiformats qui arrive à de très bons résultats, tout particulièrement avec MPEG-4 AVC. Développement moyen, progrès moyen.
libvpx peut être utilisé en indépendant (vpxenc) ou couplé à la suite libre ffmpeg. Seul encodeur réellement fonctionnel pour le format VP8, il lui manque encore pas mal d’optimisations psychovisuelles et processeur, développement très soutenu, progrès rapide.
Intégration de streams WebM
En HTML, quand vous voulez intégrer une image, voici la syntaxe telle que recommandée par le W3C pour les normes HTML 4.01 et 5:
<img width="x" height="y" alt="z" src="image.png">
L’ordre des paramètres n’est pas important. L’intégration de streams WebM est similaire:
<video src="video.webm"></video>
Ça c’est le code minimal. On va ajouter les contrôles (lecture/pause, volume,..) et un avertissement qui sera affiché si le navigateur ne sait pas traiter la balise <video> du HTML 5:
<video src="video.webm" controls>Attention, votre navigateur ne sait pas traiter des vidéos HTML 5 !</video>
On va faire afficher la vidéo sur 250 pixels de largeur, et on va afficher une image tant que la vidéo n’est pas démarrée:
<video width="250px" poster="image.png" src="video.webm" controls></video>
Démarrer automatiquement la lecture de la vidéo ?:
<video src="video.webm" controls autoplay></video>
Intégrer à la fois du WebM et du MPEG-4 AVC:
<video controls>
<source src="video.webm" type='video/webm; codecs="vp8, vorbis"'>
<source src="video.mp4" type='video/mp4; codecs="avc1.42E01E, mp4a.40.2"'>
</video>
Faire un fallback vers un stream Flash Megavideo:
<video controls>
<source src="video.webm" type="video/webm" onerror="fallback(this.parentNode)">
<object width="640" height="344">
<param name="movie" value="http://www.megavideo.com/v/poueeeeet"></param><param name="allowFullScreen" value="true"></param>
<embed src="http://www.megavideo.com/v/poueeeet" type="application/x-shockwave-flash" allowfullscreen="true" width="640" height="344"></embed></object>
</video>
<script type="text/javascript">function fallback(video) {
while (video.firstChild) {
if (video.firstChild instanceof HTMLSourceElement) {
video.removeChild(video.firstChild);
} else {
video.parentNode.insertBefore(video.firstChild, video);
}
}
video.parentNode.removeChild(video);
}
var video = document.getElementsByTagName('video')[0];
if (video.canPlayType) {
if (video.canPlayType("video/webm")) {
} else {
fallback(video);
}
}
</script>
Les développeurs en herbe pourront pousser plus loin en intégrant des événements javascript, des contrôles personnalisés, etc. Opera Software a publié un guide très complet
Vous pouvez bien sûr intégrer du code HTML 5 dans une page qui n’est pas entièrement en HTML 5 (par exemple sur Fansub Streaming, les streams sont intégrés en HTML 5 mais le reste de la page est en XHTML 1.0).
Sur Fansub Streaming, le code HTML 5 des streams HD est de ce type:
<video poster="http://www.fansub-streaming.eu/blog/wp-content/posterHD.svg" src="http://www.fansub-streaming.eu/stream/?v=/amv/VIDOK-Resistance.webm" controls></video>
Vous savez donc à présent comment intégrer des streams WebM sur votre site. Il ne vous reste plus qu’à savoir comment créer des streams WebM, et ça, ça sera le sujet d’un article ultérieur
(voir page ressources pour l’arborescence des articles)
Juste pour signaler que n’importe quel navigateur peut prendre en charge le container MP4 du moment que QuickTime est installé (oui, je sais, c’est propriétaire, mais il fallais que je le souligne).
Faux.
Parce que c’est pas le navigateur qui prend en charge, mais QuickTime.
Même remarque avec Windows Media Player, VLC, Mplayer, Gstreamer, Totem, RealPlayer, DivX Web Player, Flash, Silverlight, Java,…
L’intérêt du HTML 5, c’est justement de s’affranchir de tout décodeur tiers.
Petite rectification :
« du moment que QuickTime est installé » « n’importe quel navigateur »
Sous linux, j’ai pas Quicktime.
On pourrait aussi dire que IE prend en charge le WebM via le plugin de Google et que Chrome prend en charge le MP4 via le plugin de Microsoft.
Ce qu’il aurait fallu, c’est montrer le support des différents codecs par par utilisateurs, et non par navigateur (si on veut faire du prosélytisme, bien sûr). À l’heure actuelle, si on fait la somme des parts d’utilisateurs, on a (à la louche, hein) 44% qui peuvent lire le WebM, 18% qui peuvent lire le MP4 et 40% qui ne peuvent lire ni WebM, ni MP4 (ça ne fait pas 100% parce qu’il faut compter les vielles versions de Chrome, qui lisaient à la fois le WebM et le MP4).
Conclusion : actuellement, le WebM poutre largement le MP4.
Les 40% qui sont à la ramasse sont bien évidemment les utilisateurs d’IE < 9 (34%) et de Firefox < 4 (6%). Les Madame Michu sous Windows, quoi.
@Mitsukarenai
"L’intérêt du HTML 5, c’est justement de s’affranchir de tout décodeur tiers."
Ça, ça dépend plus de la philosophie des navigateurs, si je ne m'abuse. Les navigateurs WebKit comme Safari ou Epiphany peuvent utiliser les codecs du système pour lire les vidéos. Sur firefox, on peut aussi simuler un tel comportement via des extensions (il y avait le projet WildFox à un moment, mais d’autres addons comme FlashVideoReplacer lisent les vidéos en streaming via les plugins Mplayer, VLC, GStreamer…) et c’est plutôt agréable. Je veux dire, va sur la version HTML5 de Youtube avec 300 onglets d’ouverts : ça rame. Va sur la version Flash avec FlashVideoReplacer + le plugin Mplayer : c’est fluide. Du coup, paradoxalement, la version Flash de Youtube devient la plus agréable à visiter.
Je dois reconnaître (même si c’est un constat déplorable que j’ai surtout fait à l’époque de Firefox) que bien souvent les alternatives Flash au HTML5 sont les plus légères, tant niveau memory footprint que CPU overhead. Ce qui est quand même le comble, car si je me souviens bien Flash c’est interprété ou presque, ça suppose donc une grosse VM et/ou du JIT, et HTML5 c’est supposément compilé dans le navigateur (ou le moteur d’affichage) donc ça devrait tracer (surtout que j’compile mon navigateur à la patte (et c’est pas la joie
)).
C’est encore en plein développement, les interpréteurs HTML 5
Mais j’aimerais bien connaitre ta méthodologie de comparaison Flash vs HTML 5
Je suis pas expert en la matière mais il me semble que le flash, c’est bel et bien un code source ActionScript compilé pour donner le fameux .swf Pour les applications embarquées dans le navigateur, c’est sûr, le flash est bien plus rapide. Mais en même temps le web n’est pas fait pour lancer des applications…
Par contre pour la lecture de vidéos il me semble que les balises
etsont bien moins consommatrices de ressources que n’importe quel player en flash.Là encore, je ne suis pas expert, mais il me semble que ce n’est pas HTML5 qui est contestable, mais ses implémentations. Quand tu utilises Epiphany, c’est GStreamer qui décode les vidéos, il n’y a pas ces ralentissements au niveau du navigateur qu’on ressent avec firefox.
Je ne vais pas dire que c’est représentatif du web, m’enfin sur Fansub Streaming pour septembre, on en est à 3% d’Internet Explorer 9
~10% MP4-only, si on compte ceux perdus avec Safari et leurs iMachins. Et un écrasant 80% capable de lire du WebM.
Mais comme dit, Google mène la danse: ils possèdent la plateforme de vidéos la plus populaire et leur navigateur a acquis une popularité fulgurante. On ne peut pas parler de « victoire », mais le format WebM est là et pour longtemps
Le format MP4 sur Google Chrome marche, non?
Non, le support a été supprimé à partir de la version 11.
Encore un excellent article très bien détaillé allant à l’essentiel.
, continue comme ça tu fais un travail remarquable.
Même si je ne comprends pas tout
Tu t’intéresses beaucoup à tout cela ou tu en fais ton métier ?
Les deux
À oui j’oubliais de dire, ce site est l’un des seul à être disponible sur l’internet du CROUS.
Ne me demande pas pourquoi, je n’en sais vraiment rien mais en tout cas ça fait plaisir de recevoir quotidiennement sa dose de Bloody Monday et d’autres trouvailles tout aussi rafraîchissantes.
L’internet filtre (censuré pour les intimes) les autres sites de fansubs, ce qui est vraiment dommage bien que les animés ne sont pas encore licenciés en France.
Rrrrrrgggrraaahhhh c’était mon coup de gueule de 22h00.
http://lagazette-blog.fr/informatique/monde-virtuel/la-liberte-du-net-dans-les-crous/
Oui tu as raison, c’est inacceptable.
Voici quelques articles qui devraient t’intéresser:
http://www.fansub-streaming.eu/blog/creer-son-propre-reseau-openvpn.html
http://www.fansub-streaming.eu/blog/installer-trouver-un-proxy-php.html
http://www.fansub-streaming.eu/blog/tor.html
http://www.fansub-streaming.eu/blog/freenet.html
http://www.fansub-streaming.eu/blog/i2p.html
Chez TonBNC on peut avoir un shell gratos. De là tu fais passer les ports que tu veux et (si la protection CROUS est weak ce qui est très probable) tu peux simplement faire les requêtes sur un serveur DNS alternatif via ce shell (requêtes DNS encapsulées en SSH) et accéder aux IP reçues toi-même, a priori ça passera. Si ça passe, tu pourrais même essayer en ICMP avec ton outil ping local. À toi les animes pas durs
PS: Si la protection n’est pas weak, il suffit d’encapsuler tout ce qui part vers le port 80 d’une autre machine (le site visé) dans du SSH et le tour est joué. Inconvénient, il faut faire une redirection par port et par site, sauf si tu passes SSH en mode proxy mais j’ai jamais trop joué avec ça (je tiens souvent à garder un max de connexions en local pour des raisons évidentes de réactivité).
PPS: Mitsu concernant le Flash, c’est un constat vieux comme (insérez ici la date à partir de laquelle j’ai commencé à utiliser Chromium), et fait sur un navigateur qui était fort peu optimisé (et l’est encore bien peu). Le constat c’était par exemple un framerate qui drop quand on passe simplement une vidéo en fullscreen, et vu mon hardware ça faisait chier. J’en ai profité pour benchmarker et valgrinder l’app : HTML5 bouffait massivement plus de ressources que flash, en particulier niveau overhead CPU (pour le décodage j’imagine, ou alors ça affichait en software et ça explique tout, mais ça me ferait tellement pitié…) ; cependant ce dernier avait droit à une implémentation propre et donc exempte de memory leak (rien de comparable aux 500ko/s voire 1M/s que Flash peut leaker sur un simple lecteur YT). Voilà pour ma méthode de benchmarking, rien de bien avancé mais ça permet de se choisir un browser à la hauteur de la demande (et j’en ai toujours beaucoup trop demandé au panda roux, qui se traînait les fesses comme un escargot par rapport à ma machine de guerre en lame de scie circulaire bleue
).
Chromium -> vidéo en fullscreen
M’enfin on va pas flooder les commentaires de cet article. Je ferai (à l’occasion) un petit comparatif de décodage Firefox vs Chromium vs Opera avec un WebM de la mort qui tue (genre 120 FPS) et un soigneux monitoring de l’activité CPU + RAM + GPU.
Le hack « width:100% » marche très bien avec l’éditeur HTML wysiwyg, mais je vais développer un genre d’extension (ou un hack « permanent », à voir) pour le HTML5. Hier j’ai pu profiter d’une vidéo HTML5 en fullscreen avec ce hack, juste les bandes grises au lieu de noires mais ça peut sûrement aussi se régler avec l’éditeur wysiwyg.
Ni barre de titre, ni reste de l’interface: du vrai plein écran ?
Et puis madame Michu n’est pas censée hacker dynamiquement le CSS pour en profiter..
Tiens:
http://identi.ca/notice/83679591
http://static.fansub-streaming.eu/2011/09/test.html
Chromium bouffe plus de CPU, Firefox et Opera c’est équivalent, mais Opera a du mal à faire durer la fluidité.
Oui oui du vrai de vrai, juste des bandes grises au lieu du noir qu’on aurait avec mplayer ou vlc. Concernant ton benchmark, je te prierai de retenter ça avec un stream moins hardcore (25-29.90FPS!!!), et d’inclure les memory footprint des processus concernés
.
Charge mémoire (en Mo) maximale constatée:
Icecat: 152,3
Opera: 123,4
Chromium: 109,5
Et tu sais bien qu’on ne peut juger un encodeur/décodeur que quand on pousse à l’extrême
Bien on ferme la parenthèse. D’ici quelques mois tout ça sera déjà obsolète..
Oh oui j’aime !
Merci, je vais feuilleter tout ça demain.
Du beau boulot comme toujours.
Merci
Super article merci,
Je suis interessé par l’encapsulation des videos en .webm. Avoir un genre de ffmpeg fastoche a scripter pour faire un genre de youtube privé.
Et protéger un minimum le download d’une video streamé sous ce format.
J’attends la suite de l’article alors
Bonne continuation