Discussion :

[GCSX_]

Je pense que Google à pris cette décision trop tôt.

C'est à cause de décisions aussi radicale que l'on à aujourd'hui autant de problèmes de conpatibilité : Microsoft en à fait les frais avec IE6.

En voulant prendre de l'avance sur les normes, ils ont implémenté un certain nombre de balises (nouvelles à l'époque) dans IE6. Malheureusement pour eux, celles-ci n'ont pas été normalisés. On en ressent encore les conséquences de nos jours.

Aujourd'hui Google prend le même chemin en voulant imposer son format vidéo. Mais en plus du risque concernant les normes, Google favorise ses conccurents :

Regardons de plus près :

WebM | H.264
FireFox : natif | via plugin (dispo)
Safari : via plugin | natif
IE9 : via plugin | natif
Chrome: natif |non supporté

Donc si on considère ces 4 navigateurs (les plus répendus), Chrome est le seul à ne pas supporter H.264, ce qui fait que ses utilisateurs seront les seuls à être pénalisé sur un site qui ne propose pas WebM. Alors que tous les autre n'aurons même pas à se poser la question, étant de donné que les 2 formats seront pris en charge.

Si j'avais dû prendre la décision, j'aurai attendu que WebM se répende avant de prendre cette décision.
Surtout que mon choix personnel se portant actuellement sur H.264 qui, à volume égal, propose encore une qualité supérieure, et qui est beaucoup plus répendu, et plus facile à streamer (via VLC par exemple).

[Uther]

WebM | H.264
FireFox : natif | via plugin (dispo)
Safari : via plugin | natif
IE9 : via plugin | natif
Chrome: natif |non supporté

Cette comparaison est incomplète et trompeuse. Pour un tableau précis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
         ------------------------------------------------
         |         WebM         |        H.264          |
---------------------------------------------------------
|IE9     | via codec Directshow |        natif          |
|FireFox |        natif         |    non supporté*      |
|Chrome  |        natif         |    non supporté       |
|Safari  | via codec QuickTime  |        natif          |
|Opera   |        natif         |    non supporté       |
----------------------------------------------------------

* il existe une extension de Microsoft, mais elle n'apporte pas un support du H.264 à la balise <video>. Elle fait seulement un remplacement de cette balise par un objet Windows MepiaPlayer. Bref c'est un très mauvais hack qui pose plein de problèmes.

On a donc 3 navigateurs qui ne supporteront jamais vraiment le H.264 dans la balise video, alors que les 2 autres navigateurs supportent WebM de manière tout a fait transparente si les codec sont installés.

[GCSX_]

Autant pour moi ^^
Je n'avait pas toutes les précisions par rapport au plug-in pour FF, et je ne savais pas ce qu'il en était pour Opéra.

Quoi qu'il en soit, on à tout de même 3 navigateurs permettant de lire les 2 formats de façon transparente ou presque (FF uniquement sous Windows).

Ce qui est un avantage pour ces derniers je trouve.

[pseudocode]

Si on va par là...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
         ------------------------------------------------------------------------
         |         WebM         |        H.264          |        Flash          |
---------------------------------------------------------------------------------
|IE9     | via codec Directshow |        natif          |     via plugin        |
|FireFox |        natif         |    non supporté*      |     via plugin*       |
|Chrome  |        natif         |    non supporté       |     via plugin/natif  |
|Safari  | via codec QuickTime  |        natif          |     via plugin        |
|Opera   |        natif         |    non supporté       |     via plugin        |
---------------------------------------------------------------------------------

Malgré les évolutions prévues de HTML5, je pense qu'il y aura toujours une nécessité d'avoir une techno du genre Flash/Silverlight.

Hors ces deux technos permettent également la diffusion de contenu multimedia... Et elles permettent notamment de protéger (un minimum) les contenus (DRM, chiffrage, ...), ou d'y ajouter de la pub, de l'interactivité. Des choses que ne permet évidemment pas la balise vidéo.

Je vois donc un potentiel intérêt à la fois fonctionnel et commercial pour ces technos dites "fermées".

[Neko]

Ne voyez pas tout en statique! Les choses changent.
Si H.264 prend le pas sur WebM les navigateurs seront forcés de le prendre en charge ( que ce soit en natif, via plugin ou tout simplement via les Codec installés sur le système ) et si WebM prend le pas sur H.264 même chose.

Ce n'est de toutes façons pas aux clients/navigateurs de décider ça, c'est aux fournisseurs de contenu. Les navigateurs seront obligés de suivre.

[GCSX_]

Malgré les évolutions prévues de HTML5, je pense qu'il y aura toujours une nécessité d'avoir une techno du genre Flash/Silverlight.

Hors ces deux technos permettent également la diffusion de contenu multimedia... Et elles permettent notamment de protéger (un minimum) les contenus (DRM, chiffrage, ...), ou d'y ajouter de la pub, de l'interactivité. Des choses que ne permet évidemment pas la balise vidéo.

Je vois donc un potentiel intérêt à la fois fonctionnel et commercial pour ces technos dites "fermées".

Je suis tout à fait de cet avis ^^

Ayant une bonne experience en .NET, je me suis mis récemment à Silverlight (j'ai commencé avec le 2, mais je ne m'y suis vraiment mis que peut avant la sortie du 4), et je vois très bien son utilité aux côtés de l'HTML5, tout comme le Flash, mais je n'en ai fait que très peu.

Pour ce qui est du codec de la balise video, pour le moment je pense que le mieux est de supporter les 2, et de normer par la suite le plus plébicité, comme le suggère Neko. Mais de toute manière, c'est le W3C qui tranchera.

[thelvin]

Je vois donc un potentiel intérêt à la fois fonctionnel et commercial pour ces technos dites "fermées".

Ben oui, principalement grâce au fait que c'est fermé. Mais ça on a pas dit le contraire.

Je vois pas pourquoi on remet sans arrêt Flash dans cette discussion. Flash n'est pas un prototype. Flash est là, fonctionnel, non seulement dès maintenant, mais en plus ça fait un fameux moment. Et Silverlight n'en est plus au prototype non plus, bien qu'il puisse vaguement être considéré comme tel point de vue adoption... Pas autant que <video> quand même.

[pseudocode]

Ben oui, principalement grâce au fait que c'est fermé. Mais ça on a pas dit le contraire.

Ce ne pas tant le fait que ca soit "fermé" (il existe de spécifications ouvertes de DRM).

C'est surtout que HTML5 en lui même ne spécifie pas de mécanismes "standards" permettant de protéger/monétiser les contenus ( encore heureux me direz-vous ). Hors il y a fort à parier que certains sites webs construiront leur business-model sur une protection des contenus (genre la catch-up TV, ou la VOD).

Ca ouvre donc la question de la protection des contenus audio/video encodées avec un codec qui assure le libre accès à tout le monde.

[Camille_B]

Il est clair que Flash/Sylverlight proposent des fonctionnalités qui dépassent de loin <video>.

Mais flash/sylverlight sont des pièces rapportées, sont des machins qui se greffent à une page html plus ou moins harmonieusement.

<video> c'est une balise html avec tout ce que cela suppose d'intégration au DOM.

Bref, <video>, <canva>, Javascript, SVG, MathML, tout cela permet de faire des choses extraordinaires.

Mais il manque des outils aussi simples que Flash CS5, et, surtout, des navigateurs qui ne soient pas trop en retard sur des standards qui prennent déjà trop de temps à pointer le bout de leur nez.

À mon avis le meilleur du html/Javascript/SVG (etc.) commence tout juste à arriver. C'est le début, un long début, mais un début

[thelvin]

Ce ne pas tant le fait que ca soit "fermé" (il existe de spécifications ouvertes de DRM).

Si si. Il existe des specs ouvertes de DRM, oui... Mais les intégrer au web de sorte qu'elles gardent une efficacité quelconque, c'est une gageure. Les navigateurs ne joueront pas le jeu.
De ce côté-là, des specs fermées, ou au moins des produits très monolithiques et antonymes à la décentralisation web, et qui ont un long historique de fermeture, ça élude pas mal le problème.

C'est surtout que HTML5 en lui même ne spécifie pas de mécanismes "standards" permettant de protéger/monétiser les contenus

S'il le faisait, les navigateurs donneraient tous les droits aux utilisateurs, sans vérifier qu'ils les aient. C'est normal, mon navigateur me sert moi, et il ne servira quelqu'un d'autre que si je le veux bien.

( encore heureux me direz-vous ).

Pas forcément... Disons que le DRM efficace étant un doux rêve, j'aime autant qu'on n'aille pas s'encombrer avec le résultat d'une poursuite de chimères, en effet.
Mais si c'était quelque chose de réaliste et de propre, je pourrais comprendre que des fournisseurs de contenu s'en servent pour assurer leur paiement en bonne et due forme, même si les conséquences réelles en pratique ne m'arrangent pas.
Seulement, les DRMs sont une chimère et les navigateurs ne joueront pas le jeu.

Hors il y a fort à parier que certains sites webs construiront leur business-model sur une protection des contenus (genre la catch-up TV, ou la VOD).

Ca ouvre donc la question de la protection des contenus audio/video encodées avec un codec qui assure le libre accès à tout le monde.

Aucun codec ouvert respectant <video> n'a bien le choix, je pense.
Mais c'est vrai, oui.

[pseudocode]

Ah... Google a entendu les critiques sur le qualité rédactionnelle de sa spécification :

Google has submitted a draft covering the bitstream format and decoding of VP8 video to the Internet Engineering Task Force.

The IETF document could help allay one concern VP8 critics have raised: that VP8 is defined not by documentation of the bitstream but rather by the source code of the software Google released to implement VP8.

[Katleen Erna]

Le H.264 est de retour sur Chrome, qui pourra lire les vidéos dans ce format grâce à une extension de Microsoft
Mise à jour du 03.02.2011 par Katleen

Il y a un petit peu moins d'un mois, Google annonçait la fin du support du codec H.264 par son navigateur Chrome, ce qui en enchantait certains et en gênait d'autres.

Aujourd'hui, une alternative est possible, grâce à Microsoft (qui s'était déjà occupé du problème sous Firefox).

L'éditeur de Redmond vient ainsi de dévoiler son "Windows Media Player HTML5 Extension for Chrome", qui, comme son nom l'indique, est une extension pour Chrome qui permettra la lecture de vidéos au format H.264 par les utilisateurs du navigateur de Mountain View.

"Nous respectons le fait que les utilisateurs de Windows veulent avoir la meilleure expérience du Web possible, ce qui inclut la possibilité de profiter de la plus grande diversité de contenus disponibles sur l'Internet au format H.264", a déclaré Microsoft.

Internet Explorer 9 supportera ce format, en plus du WebM de Google (si le codec correspondant est installé).

Tout cela, dans une politique d'interopérabilité clairement affichée.

Source : Blog de Claudio Caldato (programmeur principal de l'équipe intéropérabilité de Microsoft)

Que pensez-vous de cette solution ? Qu'est-ce qui, selon vous, à motivé Microsoft à la concevoir ?

Avez-vous déjà testé l'extension H.264 pour Firefox, fournie par Microsoft ?

[benjaminjc]

Google entube pour son produit.

Je dirais plutôt Google youtube pour son produit

[trenton]

Tout cela, dans une politique d'interopérabilité clairement affichée.

Ce n'est pas de l'interopérabilité puisque ça concerne que Windows. Faut arrêter de dire n'importe quoi et de pas utiliser le mot interopérabilité si on ne le comprend pas.

[Stephiloups]

Ce n'est pas de l'interopérabilité puisque ça concerne que Windows. Faut arrêter de dire n'importe quoi et de pas utiliser le mot interopérabilité si on ne le comprend pas.

Tout a fait d'accord avec toi, il faut se garder de parler de ce que l'on ne comprend pas ...
L'interopérabilité ne concerne pas les OS, il s'agit d'interfaces ...

[Uther]

Que pensez-vous de cette solution ?

La même solution bancale que Microsoft avait déjà utilisé pour son plugin Firefox.

Qu'est-ce qui, selon vous, à motivé Microsoft à la concevoir?

La motivation est claire : emmerder Google et promouvoir H.264 sur lequel Microsoft possède des brevets.

[trenton]

Tout a fait d'accord avec toi, il faut se garder de parler de ce que l'on ne comprend pas ...
L'interopérabilité ne concerne pas les OS, il s'agit d'interfaces ...

Je me suis sans doute mal exprimé, mais NON, le H264 ne permet pas l'interopérabilité car soumis à des royaltees, et en pratique, seuls les utilisateurs de Chrome sur Windows pourront l'utiliser.

Donc soutenir le H264 ce n'est pas soutenir l’interopérabilité mais tout l'inverse.

Si ils veulent soutenir l’interopérabilité, ils peuvent implémenter WebM et Theora sur leur systèmes.

[FailMan]

en pratique, seuls les utilisateurs de Chrome sur Windows pourront l'utiliser.

Je ne comprends pas, cela veut dire que seuls WebM et Theora seront déclarés comme standard par le W3C ? Comment le sais-tu à l'avance ?

[thelvin]

en pratique, seuls les utilisateurs de Chrome sur Windows pourront l'utiliser.

Je ne comprends pas, cela veut dire que seuls WebM et Theora seront déclarés comme standard par le W3C ? Comment le sais-tu à l'avance ?

Sans être d'accord avec l'un ou l'autre, je pige pas ton raisonnement. Quel rapport entre qui peut utiliser le plug-in de Microsoft, et qu'est-ce qui figurera dans les spécifications W3C ?

[FailMan]

Sans être d'accord avec l'un ou l'autre, je pige pas ton raisonnement. Quel rapport entre qui peut utiliser le plug-in de Microsoft, et qu'est-ce qui figurera dans les spécifications W3C ?

Je cite :

Je me suis sans doute mal exprimé, mais NON, le H264 ne permet pas l'interopérabilité car soumis à des royaltees, et en pratique, seuls les utilisateurs de Chrome sur Windows pourront l'utiliser.

Je me pose donc des questions, c'est tout. Je ne vois pas en quoi le fait qu'on puisse utiliser un plug-in pour Chrome sous Windows ferait que seul Chrome pour Windows soit apte à décoder le H.264, qui selon trenton, ne sera pas le codec choisi par le W3C.