Reprise du message précédent :
merci. Disons que ça a le mérite de la simplification (Theora ou Vorbis selon qu'il s'agit de vidéo ou de son)

Simplification pour qui ? Si c'est pour l'utilisateur, ça ne change rien du tout qu'il y ait 1 ou 50 décodeurs intégrés.
Si c'est pour le webdev, il doit connaître ou se renseigner sur les formats existants et supportés par tous les navigateurs de toute façon.

pour les pour le webdev et aussi pour mozilla (débogage, failles...)

 
Et donc pour les utilisateurs.

voilà

 
mouais, la base du h264, c'est un type d'algo qui existait déjà pour le mpeg1, c'est pas pour ça qu'on a la même qualité.

Mike Shaver, Mozilla's vice president of engineering : HTML5 video and codecs (via osnews)
 

http://weblogs.mozillazine.org/roc [...] dom_a.html
Why not H264

Donc l'argument principal c'est : dans les pays où les brevets logiciels sont valables on ne peut pas distribuer un logiciel qui décode h264 sans payer la licence.
Ça revient à dire qu'on accepte le concept de brevet logiciel, et que même si ils ne sont pas valables en Europe, on fait comme si ils l'étaient
On peut préférer theora ou dirac à h264 comme on préfère du ogg à du mp3 (quoique dans le cas du ogg il y a aussi une supériorité technique), mais je ne vois pas pourquoi on devrait le refuser. Il est bien documenté et utilisable librement presque partout dans le monde non?
 
C'est surtout un argument contre les brevets logiciels plutôt que contre le format lui-même.

ça veut dire que les brevets sont une réalité dans certains pays, point
 

ça serait égoiste de dire : nous les français on s'en fout des autres, servez-nous du h264 pliz. Ou alors on balkanise le Web.  
 
En même temps si les utilisateurs choisissent des formats non brevetés ça réduit l'intéret des brevets et ça diminue le risque que ça arrive chez nous (moins d'intérets financiers=>moins de lobbies). Tout se tient
(celle là vous pouvez l'encadrer)

Finalement je suis plutôt d'accord là-dessus  

Mieux vaut se sécuriser en refusant tout élément pouvant générer un quelconque soupçon d'illégalité dans un logiciel libre plutôt que de passer en force pour être le plus compatible possible.

sur l'accélération matérielle du rendu par Firefox qui pourrait booster un certain de nb de techno concurrente de flash (je pense au svg notamment) :
Layers: Cross-Platform Acceleration par un des dev qui s'occupe de ça (ils sont essentiellement deux on dirait : Bas Schouten et Robert O'Callahan) :

J'ai pas bien compris ce qui sera exactement accéléré sur Linux (apparemment tout sera accéléré sous windows) ni si ça dépend du site ou de Firefox. SVG est concerné dans le principe ?
 

J'en déduis :
- qu'à l'encodage on peut choisir le type de couleurs primaires pour accélérer le rendu (en uploadant des vidéos directement en RGB) ?
- qu'au final ça pourrait accélérer la vidéo (theora ou autre) quand bien même theora ne serait pas spécifiquement accéléré par la carte graphique... utile pour les appareils mobiles

Sinon : http://www.pcinpact.com/actu/news/ [...] theora.htm

 
Le dernier point est l'une des raisons pour lesquelles flash et la balise vidéo actuelle sont à la rue en terme de perf. Les vidéos sont en YUV, pour les afficher, on les convertit en RGB.
Sous Linux, avec un lecteur vidéo normal qui utiliserait xvideo (sortie Xv), c'est la carte graphique qui s'occupe de ça, elle prend de l'YUV en entrée (dans un format donné, YV12 souvent) et le converti en interne dans le format qui lui convient le plus. Ça se fait soit par un circuit dédié (overlay) soit par le moteur 3D de la carte (adaptateur texturé)
Par exemple, là, mon adaptateur texturé accepte uniquement de l'YUV au format YV12 ou I420 :

 
Pour différentes raisons, firefox (et flash) ne peuvent pas utiliser le YUV pour afficher quelque chose, ils sont donc obligé de fait eux même la conversion YUV vers RGB en utilisant le CPU. Et ça, ça mange un maximum de CPU (il faut convertir chaque image en temps réel).
 
 
Il y a plusieurs solutions possibles mais elles ne sont pas simples. Celle donnée dans le lien en est une. Une autre, actuellement développée, consiste à faire accepter le YUV tout au long de la chaîne c'est à dire cairo, gstreamer, pixman et X via l'extension Render. Ce qui permettra d'éviter la conversion YUV->RGB par la CPU, on donnera le tout à manger à la carte graphique à la fin comme dans le cas de Xvidéo (mais via Render ou OpenGL dans le cas présent).

Ahh mais c'est diablement interessant ca ! Donc la piste que tu donnes (YUV pour toute la chaine) permettrait peut etre meme d'avoir du flash en plein ecran sous linux ??    
Est-ce que les travaux sur pixman rapportes par phoronix sont en rapport avec ce support ?

Ué, mais d'après ce que j'ai compris, il faudrais qu'adobe s'intéresse 5 minutes à autre chose que le plugin ActiveX pour Microsoft Windows Internet Explorer.
Donc bon, ça m'a l'air perdu d'avance

 
Pour flash, il faudrait qu'il utilise la chaîne en question, je ne sais pas comment il s'intègre dans tout ça.
 
Sinon, je ne sais pas de quel article tu parles mais je suppute que oui.  
Plus d'infos par là :
http://blogs.gnome.org/otte/2009/10/
http://lists.cairographics.org/arc [...] o-is-slow/
http://lists.cairographics.org/arc [...] 18221.html
http://gstreamer.freedesktop.org/w [...] fest/Notes

et la techno de Firefox concernerait quoi d'autre que la vidéo ?
au final on a intérêt à uploader des vidéos en RGB ? c'est possible ? Quelles sources sont en YUV ou RGB dès le départ (camescope, screencast...) et avec quoi convertir : VLC ou via une appli GStreamer ?

Tiens, on en parle dans les journaux grand-public : http://www.lemonde.fr/technologies [...] 51865.html

 
Sauf qu'on a aps choisis de YUV par hazard : il permet des taux de compression bien plus important que le RGB car tire partie du fonctionnement de l'œil, et non de l'écran.

ok je comprends mieux !

Je teste un peu pour voir comment fonctionnent les balises audio et video sous Firefox
Autant la balise video me permet, comme pour une image, de spécifier la taille pour éviter que la mise en page ne saute lors de la construction de la page, autant la balise audio vit sa vie et s'agrandit pour afficher un throbber géant avant de reprendre sa taille normale (insupportable). Sans compter que le compteur dépasse du lecteur audio et empiète sur le texte de la ligne du dessus. Enfin le son est réglable pour le player video mais pas pour la player audio (qui n'a que 2 positions : on/off). Bref, le player audio fait un peu bâclé sur Firefox.
http://libre-ouvert.toile-libre.or [...] o-et-video

Le réglage du volume semble avoir un bug, dans certains cas, par exemple lorsque le throbber est affiché, on peut apparemment régler le volume ... Bref, c'est simplement un bug.

L'icône de chargement "throbber", ok (géant, un bien grand mot), à la limite, bien que tu puisses probablement tout configurer comme tu le souhaites ... C'est loin d'être "insupportable" comme tu le dis exagérément.

Pour le texte ... C'est à toi de régler l'espacement du texte en fonction de ton design ... Dans la situation inverse, si Mozilla avait mis un espace supplémentaire sur le haut du lecteur, tu aurais râlé parce que ça ne collait pas avec ton design ...

Tout ceci pose une grande question, tu effectues des tests des balises "video" et "audio" le 27 janvier 2010 alors que la version finale de Mozilla Firefox 3.6 date du 21 janvier 2010 et 6 mois après la sortie de la 3.0 qui les prenaient déjà en charge. Ne crois-tu pas que ce genre d'essai aurait aussi pu servir au développement de Mozilla Firefox, et pas seulement pour le "plaisir personnel" ?

bien vu, je vais regarder si ça a été rapporté
 

j'ai peur que ce ne soit pas configurable dans le lecteur par défaut, sinon il faut en créer un. Mon souci est que ça fait sauter la mise en page quand il se pointe
 

Je me demande si le compteur a besoin de dépasser en fait
 

Je vois que je ne suis pas le seul à pratiquer l'exagération ;-) En fait j'étais sous blogger et j'apprends le (x)html que depuis une semaine, voilà la raison de mon impuissance à tester plus tôt  

j'ai contrôlé c'est déjà fixé dans les dernières version pour windows et linux

Petite idée pour relancer le débat, l'iPad marque un point en banissant le Flash, certains sites sont carrément inutilisables, ce qui reflètent bien le manque d'alternatives utilisées par les développeurs de ces sites.  
http://www.generation-nt.com/ipda- [...] 53181.html

ce soir vers 23h40 sur lcp un "journaliste expert en nouvelles technlologies" expliquait que l'ipad supportait pas le flash parceque c'était propriétaire et que ça boguait alors qu'apple était pour un web ouvert on croit réver
(edit : sans doute dans l'émission "Agora 2.0" )

surtout à l'heure là oui, beaucoup commencent à rêver

Autant je vois ce que tu veux dire par là, autant pour 99% des gens, cette limitation n'est pas une prise de position courageuse dans le grand combat qui mènera à la liberté des octets (et venant d'Apple je ne pense pas que ce soit le cas en plus) mais une décision stupide qui empêche de se servir de sa tablette complètement correctement. Ce que je veux dire, c'est que pour que Flash soit définitvement abandonné au profit d'une technologie libre (ou vraiment dans le pire des cas non libre mais universelle et compatible avec tous les types d'appareil et tous les OS), il faudra que la solution soit compatible avec l'actuel Flash afin de créer une transition transparente pour tous les non intéressés par l'informatique et ses problématiques, de manière à ce que cet appareil qui les énervent bien assez souvent ne leur pose pas une fois de plus des soucis pour un combat d'arrière garde dont ils n'ont rien à faire.
Même si tous les fabricants venaient du jour au lendemain à ne plus supporter Flash dans leurs appareils/systèmes, je ne pense pas que la situation changerait radicelement, le cout pour mettre à jour les sites Internet utilisant Flash qui se comptent par millions étant extrêmement élevé. Il faut apporter quelque chose supportant l'existant, apportant une valeur ajoutée à migrer vers la nouveauté et qui n'empêche personne, dès aujourd'hui, de consulter le Web sans se poser de question.
Quand au motivation d'Apple...

D'accord avec toi, la migration prend du temps. Ici même on a quelques règles pour respecter le développement de nos applis, et ne pas s'y restreindre pourrait être couteux lors de l'abandon de support de ces morceaux de codes belliqueux.
Donc le premier reproche est à faire au niveaux des dev qui ont foncés sur le flash sans prévoir une alternative pour utiliser leur site.

Clair qu'abandonner la peste pour le cholera, c'est pas une solution non plus.

Le pire pour moi étant les sites qui utilisent Flash et qui pourraient très bien s'en passer avec les formats actuels des recommandations W3C.
Dans le domaine de la publicité, Flash est malheureusement bien intégré, par contre, s'il n'y avait plus que ça en Flash sur le web, c'est sûr que si tout le monde virait Flash Player, la publicité Flash crèverait bien vite.
Quand à Silverlight, c'est clair que remplacer le mal par le mal, ça change pas grand chose en finalité.
Je tente d'ailleurs de ne pas aller sur les sites utilisant cette technologie pour ne pas ressentir en le besoin. Il faut avouer que la propagation de cette technologie reste plutôt limitée actuellement, certains sites font même marche arrière car ils doivent probablement perdre des visiteurs.

Surtout que d'après la présentation que l'on a eu, ca n'apporterait que des trucs/infos/données qui bougent, supaÿr (sans parler du rammage de la présentation en elle même).
J'espère au moins que l'alternative sera toujours au menu, rien que pour les utilisateurs/clients/tati danielle ayant un pc à la ramasse.

Ceci dit, je suis actuellement sur un projet ou le full standard web n'est pas possible. Dans un premier temps, afin de faire les choses bien, j'ai réduit la partie non faisable via les techno standards au minimum. Les parties faites via plug-in sont non visibles, et appelées par le javascript au travers d'un interface tout ce qu'il y a de plus standard. Du coup, ça fonctionne vraiment comme une extension maison de javascript.
 
Pour ce faire, j'ai pensé à silverligth, qui était technologiquement parfait pour mon projet. (même avec moonlight). Mais par craintes des réactions comme la tienne, je me suis rabattu sur java. C'est nettement plus agaçant sur bien des points.
 
Il est clair que si un jour, cette partie la est supprimable, pour faire place à une techno standard, cela se fera rapidement, mais ce n'est pour l'instant pas le cas.

Par curiosité, quels étaient les parties non réalisable dans les formats recommandés ?

Récupération de données par des moyens autres qu'HTTP .

Perso, mais je suis un brin biaise...., je pense que Silverlight de part MoonLight est mieux que Flash!

http://www.clubic.com/actualite-32 [...] aille.html

 
Ne serait-ce que d'un point de vue technique, il est loin devant flash et java.
 
EDIT: ouais, IE7 devait être conforme au standards du web. IE8 devait aussi l'être. Pour IE9, moi je n'y crois plus tant que j'ai pas vu de mes yeux.