Nous, mais tu as raison (voir ton commentaire plus bas).
Plus de release, mais les releases "perturbantes" ne vont arriver qu'une fois par an (environ).
WebSockets, voyez ça comme de l'IP over HTTP (persistent, bi-directionnel), typiquement, comment faire un chat sans avoir à utiliser un vieux hack pourri avec XHR.
WebSockets, c'est 2 choses:
* une API
* un protocole
L'API, rien de plus simple. Le protocole, c'est compliqué.
Protocol qui au début (v0.75) a été spécifié par le W3C. Là, on a trouvé une faille de sécu inhérent au protocole. La version suivant (v0.76) a fixé ça. Chrome et Safari ont shippé.
L'IETF récupère le bébé (c'est un protocole, donc bon), et était sensé avoir une nouvelle version en très peu de temps. Comme d'hab, ça n'a pas marché (toujours en court de spécification).
Découvert d'une (très sérieuse) faille de sécu dans le protocole v0.76.
Fx4 et Opera décident de pas shippé (ils ne l'avaient pas encore fait).
Chrome & Safari, on attend leur réaction.
> Ou qu'est-ce qui fait que Mozilla néglige tant le portage Linux?
On ne néglige pas le portage Linux. Par contre on a un problème sérieux sous Linux: pas de béta testeurs, très peu de remonté de bugs (comparé à Windows & Mac). Ça s'explique, mais ça reste assez décevant. Le nombre de fois que j'entend les utilisateurs Linux se plaindre sans avoir ouvert de bugs, c'est triste.
> Comment vous gérez les priorités? La répartition temps alloué au paquet Linux et Windows, elle est comment et pourquoi?
Il n'y a a pas vraiment de question de priorité. Juste ça doit marcher sous Linux, Mac et Windows. Après, y'a tout un tas de cas particulier...
> J'ai regardé ta chouette video avec la demo tactile, c'est sympa, c'est fluide... mais ça tourne sur Vista/7 :). Oui, c'est une techno web, donc à priori l'OS n'a pas une grande importance mais quelque chose me dit que la demo n'auraît pas eu le même effet.
... comme le multi-touch. Windows Vista/7 expose une API qu'un contributeur à exposé dans le web content. Sous Linux, le multi-touch est un monde absolument pas stable et homogène. Et puis tout bêtement, le contributeur à l'époque ne connaissait que Windows.
Bref, c'est une longue histoire.
Si il y a 2 chose à retenir:
* Mozilla ne délaisse pas et ne délaissera jamais Linux
* L'intégration à Linux est 10 fois plus compliqué que celle de Mac ou Windows (à cause de son potentiel de customisation), ça aide pas.
* Au lieu de balancer des bétises sur Internet à propos de Linux et Firefox, faites un truc utile, ouvrez des bugs (mettez moi en CC :paul)
Je vois pas le "truc". J'ai un peu la même attitude (mon blog, c'est du Vim + shell script + Makefile + gcc preproc), mais bon, je vais pas venir me la péter parce que j'ai coller trois bouts de trucs ensemble.
En attendant, t'utilises jQuery (T'as vraiment besoin de ça???) et Facebook. Ça c'est peut-être le truc à revoir.
Et puis je pense pas que tu traines avec les bonnes personnes :)
C'est une vraie bonne question. D'ailleurs, même nos devs se la pose.
Par exemple, pour avoir un meilleur résultat sur SunSpider, on a du se prendre la tete sur la gestion des dates et sa gestion du daylight (rien de critique niveau perf ici).
Donc la compétition, c'est bien, mais de temps en temps, ça a des conséquences absurdes.
> il a quand même fallu un sacre bout de temps avant qu'ils n'y pensent.
Oui, on est trop bête :) On avait oublié.
1. les gens qui font JS ne sont pas les mêmes qui font GFX
2. utilisé XRender sous Linux, c'est arrivé bien avant la versoin 4 (Fx 2 je crois)
3. OpenGL c'est juste le compositing, ça ne rendra pas rapide ce qui est lent aujourd'hui. C'est plutôt aux drivers de s'améliorer (ou alors on fait comme Chrome, on utilise pas les libs du systems, et on fait tout à la main)
Vous autorisez des plugins non libre, c'est la même logique que d'autoriser des codecs non libres : une interface avec un autre fournisseur.
Vous faites patent free? Alors interdisez Flash qui a plein de patents (dont ceux de H.264)
L'excuse de l'attaque possible par MPEG ne tient pas : vous n'êtes pas attaqués parce que vous pouvez lire du H.264 (puisque FF le peux par le biais de Flash...) par un plugin x, vous ne serez pas attaqué parce que vous pouvez le faire par un plugin y. Une interface avec le backend de l'OS (Windows ou Mac ou Linux) ne contiendrait aucun patent MPEG.
De plus, la MoFo date de 2003 si j'en crois Wikipedia, et le dernier patent JPEG a expiré en 2006 si j'en crois http://en.wikipedia.org/wiki/JPEG#Patent_issues , pourquoi ça n'a pas dérangé la MoFo entre 2003 et 2006?
Il y a une différence fondamentale entre les plugins et la vidéo: pour les plugins, on n'a jamais eu le choix! Ici, pour la vidéo, la technologie est à créer. On est maintenant en position plus ou moins dominante pour imposer nos choix (ce que l'on ne pouvait pas faire avant). C'est pour ça qu'on devient paranos sur SSL et sur les formats, parce que maintenant on peut.
Si il y a 10 ans (ça fait 10 ans qu'on a commencé Gecko, la nouvelle version) on avait supprimer plugins et JPEG, aujourd'hui on existerait tout simplement pas. Maintenant, on a 30% des utilisateurs. On a un poids important. On en profite pour pousser les bons formats.
Je comprends que ça fasse chier pas mal de gens, mais bon, ici on a la possibilité et l'occasion d'imposer un format ouvert et patent free tout en bloquant un format que l'on considère mauvais pour le web.
On espère que ça marchera et quand dans 10 ans on ne se pose plus la question et que la vidéo sera ouverte pour de vrai.
Format standard de vidéo Compte tenu du nombre important de vidéos déposées par les utilisateurs (plus de 24 heures de vidéo chaque minute), il est nécessaire de limiter le nombre de formats vidéo, surtout lorsque l'on propose différentes tailles de la vidéo (360p, 480p, 720p, 1080p). Depuis 2007, toutes les vidéos de YouTube sont codées avec le codec H.264. Le lecteur Flash, ainsi que les terminaux mobiles tels qu'Android ou iPhone supportent ce format. John Harding pense que le web se doit d'avoir un standard vidéo libre et ouvert. Le projet WebM pourrait être une alternative intéressante.
De notre côté (Mozilla), WebM et ogg/theora sont les seules options (logiciel libre + patent free).
Un standard robuste Étroitement liée à la nécessité d'un format ouvert, l'un des besoins de YouTube est d'offrir la capacité à ses utilisateurs d'être redirigé directement sur une séquence précise de la vidéo. Le lecteur Flash permet ceci via Actionscript en conjonction des protocoles HTTP et RTMP (Real Time Messaging Protocol). HTML5 ne propose pas encore ce genre de fonctionnalité, même si un certain nombre d'institutions et organisations travaillent sur ce point.
Le W3C et nous-même y travaillons (ainsi que sur de l'adaptative streaming).
Vidéo plein écran Bien que les navigateurs proposent un mode plein écran, ce mode ne peut être initialisé via JavaScript, ni même permettre le plein écran d'une seule partie du contenu web (par exemple le lecteur vidéo). Seul Flash permet cette fonctionnalité, même si des initiatives existent avec les avancés de WebKit.
Accès à la caméra et au microphone Chaque jour, des milliers d'utilisateurs enregistrent des vidéos directement sur YouTube à partir de leur navigateur à l'aide de leurs webcams. La technologie Flash est éprouvée sur ce point alors qu'HTML5 n'en est qu'aux balbutiements (Spécifications HTML5).
C'est les specs DAP plutot (il y a le tag "device" d'HTML5, mais bof bof). On y travaille (pas pour la vidéo, mais pour prendre des photos à partir de la webcam).
Sinon, clairement Flash est plus avancé. Mais bon, faut bien commencer et on peut pas avoir tout du jour au lendemain :)
- Tir à peine caché sur Firefox incapable d'afficher du H.264 pour au moins gérer le passé (ré-encoder toutes les vidéos depuis 2007? hum...). C'est ce que je craignais avec l'annonce de Mozilla de refuser H.264 : en voulant virer H.264, ils arrivent juste à ralentir/virer la balise vidéo HTML5, bravo.
Bah on fait du logiciel libre et patent free. Après, chacun ses priorités.
- Vidéo plein écran impossible, oui c'est n'importe quoi de permettre la lecture vidéo sans pour autant autoriser la lecture plein écran!
- Aucune gestion de la bufferisation ou de la gestion dynamique de la qualité dans HTML5 (à croire que la balise a été crée par des non expert en vidéo, la gestion fine de la bufferisation, c'est important pour beaucoup de monde!)
- Pas facile d'aller à un endroit précis de la vidéo (j'ai pas regardé de ce côté, on ne peut vraiment pas faire ça en HTML 5? Vous rigolez la?)
Ca dépend de ce que tu appelles précis. A un timecode précis, oui, on peut. A une frame precise, pas vraiment.
- C'est la merde pour mettre des sous-titre ou pub par dessus la vidéo (je suis toutefois surpris sur ce propos, je pensais qu'on pouvait utiliser une couche "texte" par dessus une couche "vidéo" comme on fait pour des images par exemple)
Ca c'est juste qu'ils sont mauvais.
- C'est limité à l'affichage, pas de gestion de la capture webcam/microphone (bon, après, le navigateur va devenir un fourre-tout ingérable, pas sûr que ce soit bien d'intégrer ça dans un navigateur, mais bon, vu que la mode est à tout mettre dans un navigateur web...)
Il y a des standards pour ça. DAP & Device API. Nous on bosse sur l'intégration de la caméra en ce moment.
Et la conclusion fait mal : HTML 5 c'est peut-être bien pour le futur, il faut y travailler (car aujourd'hui ça répond à un besoin très limité), en attendant Flash répond au besoin aujourd'hui, et cette caractéristique est très importante.
99% de ce que tu veux faire avec la video (la visualiser) ça marche très bien.
Mais on peut clairement faire mieux, et on y travaille \o/
Pourquoi on est plus lent que Chrome (je ne suis pas expert, je fais juste passer le message):
En partie parce que Firefox essaye d'utiltiliser X, en particulier XRender, pour dessiner. C'est intelligent en théorie car on profite de l'accélération des drivers. Dans la vraie vie, les drivers ne sont pas parfait, donc ça galère pas mal. Chrome utilise ça propre lib (Skia) pour le rendering, et donc évite les soucis avec les mauvais drivers X.
En partie aussi parce qu'on utilise le thème GTK (donc utilise X) pour afficher certain widgets (meilleure intégration). Chrome non.
Aussi parce qu'on utilise Pango et fontconfig, qui est assez lent (Chrome, encore une fois, fait tout à ça manière).
Bref, le fait d'essayer de s'intégrer au mieux à Linux n'aide pas toujours.
Et aussi, on est plus lent parce que Chrome fait mieux les choses que nous à beaucoup d'endroits :) Mais on y travaille :)
Niveau Standards:
* on a un vrai parseur HTML5 (je crois que pour le moment on est les seuls) http://hacks.mozilla.org/2010/05/firefox-4-the-html5-parser-(...)
* on a les webforms qui avancent sérieusement https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms
* vous avez entendu parlé de webm (vp8)
* CSS3 toujours (transitions)
* JS largement accéléré
* WebGL (OpenGL en javascript)
* SVG/SMIL
* Indexed Database API (concurrent de sqlite database, que l'on aime pas)
* Encore des trucs que j'oublie
Niveau mobile:
* on a un version 1.1 pour Fennec (que Maemo) sur les rails, ça devrait pas tarder.
* pour la fin de l'année, une version 2.0 (Maemo + Android).
Dirac is great. At some point we'll probably add Dirac support.
However, at typical Web bit rates, Dirac doesn't currently perform
as well as Theora. The patent situation with Dirac is also currently
less clear than with Theora. We'll keep an eye on it.
# Pour info...
Posté par Paul Rouget . En réponse au journal Dépouillement de Firefox. Évalué à 3.
Bon, après, je ne suis pas spécialiste de l'UX & UI :)
[^] # Re: Vive Firefox
Posté par Paul Rouget . En réponse à la dépêche Des nouvelles de Mozilla. Évalué à 1.
Plus de release, mais les releases "perturbantes" ne vont arriver qu'une fois par an (environ).
[^] # Re: Vive Firefox
Posté par Paul Rouget . En réponse à la dépêche Des nouvelles de Mozilla. Évalué à 4.
# plus d'infos
Posté par Paul Rouget . En réponse au journal Les websockets sont pas secioures. Évalué à 4.
WebSockets, c'est 2 choses:
* une API
* un protocole
L'API, rien de plus simple. Le protocole, c'est compliqué.
Protocol qui au début (v0.75) a été spécifié par le W3C. Là, on a trouvé une faille de sécu inhérent au protocole. La version suivant (v0.76) a fixé ça. Chrome et Safari ont shippé.
L'IETF récupère le bébé (c'est un protocole, donc bon), et était sensé avoir une nouvelle version en très peu de temps. Comme d'hab, ça n'a pas marché (toujours en court de spécification).
Découvert d'une (très sérieuse) faille de sécu dans le protocole v0.76.
Fx4 et Opera décident de pas shippé (ils ne l'avaient pas encore fait).
Chrome & Safari, on attend leur réaction.
On attend la version de l'IEFT avec impatience :)
[^] # Re: IHM pas d'accord
Posté par Paul Rouget . En réponse au journal Firefox me gave!. Évalué à 2.
[^] # Re: Tu as ouvert un bug?
Posté par Paul Rouget . En réponse au journal Firefox me gave!. Évalué à 4.
Les différents thèmes possibles, le fait que les widgets n'aient pas une forme prédictible simplement.
Voilà le genre de tests que l'on doit faire sous Linux: https://bug593823.bugzilla.mozilla.org/attachment.cgi?id=473(...)
> Ou qu'est-ce qui fait que Mozilla néglige tant le portage Linux?
On ne néglige pas le portage Linux. Par contre on a un problème sérieux sous Linux: pas de béta testeurs, très peu de remonté de bugs (comparé à Windows & Mac). Ça s'explique, mais ça reste assez décevant. Le nombre de fois que j'entend les utilisateurs Linux se plaindre sans avoir ouvert de bugs, c'est triste.
> Comment vous gérez les priorités? La répartition temps alloué au paquet Linux et Windows, elle est comment et pourquoi?
Il n'y a a pas vraiment de question de priorité. Juste ça doit marcher sous Linux, Mac et Windows. Après, y'a tout un tas de cas particulier...
> J'ai regardé ta chouette video avec la demo tactile, c'est sympa, c'est fluide... mais ça tourne sur Vista/7 :). Oui, c'est une techno web, donc à priori l'OS n'a pas une grande importance mais quelque chose me dit que la demo n'auraît pas eu le même effet.
... comme le multi-touch. Windows Vista/7 expose une API qu'un contributeur à exposé dans le web content. Sous Linux, le multi-touch est un monde absolument pas stable et homogène. Et puis tout bêtement, le contributeur à l'époque ne connaissait que Windows.
Bref, c'est une longue histoire.
Si il y a 2 chose à retenir:
* Mozilla ne délaisse pas et ne délaissera jamais Linux
* L'intégration à Linux est 10 fois plus compliqué que celle de Mac ou Windows (à cause de son potentiel de customisation), ça aide pas.
* Au lieu de balancer des bétises sur Internet à propos de Linux et Firefox, faites un truc utile, ouvrez des bugs (mettez moi en CC :paul)
[^] # Re: IHM pas d'accord
Posté par Paul Rouget . En réponse au journal Firefox me gave!. Évalué à 1.
[^] # Re: IHM pas d'accord
Posté par Paul Rouget . En réponse au journal Firefox me gave!. Évalué à 4.
Si tu parles des lenteurs graphiques avec une ATI ou une intel, c'est très probablement XRender.
Ce qui veut dire que Firefox est plus rapide que Chrome si XRender est correctement supporté (nVidia), plus lent sinon (ATI).
[^] # Re: IHM pas d'accord
Posté par Paul Rouget . En réponse au journal Firefox me gave!. Évalué à 2.
# Tu as ouvert un bug?
Posté par Paul Rouget . En réponse au journal Firefox me gave!. Évalué à 4.
https://bugzilla.mozilla.org/show_bug.cgi?id=585370
https://bugzilla.mozilla.org/show_bug.cgi?id=593823
https://bugzilla.mozilla.org/show_bug.cgi?id=422179
https://bugzilla.mozilla.org/show_bug.cgi?id=572482
https://bugzilla.mozilla.org/show_bug.cgi?id=572484
https://bugzilla.mozilla.org/show_bug.cgi?id=598293
https://bugzilla.mozilla.org/show_bug.cgi?id=572485
Et:
https://bugzilla.mozilla.org/show_bug.cgi?id=555935
C'est une beta, et on bosse sur l'intégration Linux en ce moment.
Merci encore de ton soutien.
[^] # Re: des milliers de ligne de code de framework
Posté par Paul Rouget . En réponse au journal Marre du dévelopement bloatware moderne ! Appel aux armes !. Évalué à 10.
# bof
Posté par Paul Rouget . En réponse au journal Marre du dévelopement bloatware moderne ! Appel aux armes !. Évalué à 10.
En attendant, t'utilises jQuery (T'as vraiment besoin de ça???) et Facebook. Ça c'est peut-être le truc à revoir.
Et puis je pense pas que tu traines avec les bonnes personnes :)
[^] # Re: performances légèrement inférieures à la version stable
Posté par Paul Rouget . En réponse au journal Comparons les performances Javascript de Firefox et Chrome. Évalué à 5.
[^] # Re: Trop cool... Mais quel intérêt ?
Posté par Paul Rouget . En réponse au journal Comparons les performances Javascript de Firefox et Chrome. Évalué à 10.
Par exemple, pour avoir un meilleur résultat sur SunSpider, on a du se prendre la tete sur la gestion des dates et sa gestion du daylight (rien de critique niveau perf ici).
Donc la compétition, c'est bien, mais de temps en temps, ça a des conséquences absurdes.
> il a quand même fallu un sacre bout de temps avant qu'ils n'y pensent.
Oui, on est trop bête :) On avait oublié.
1. les gens qui font JS ne sont pas les mêmes qui font GFX
2. utilisé XRender sous Linux, c'est arrivé bien avant la versoin 4 (Fx 2 je crois)
3. OpenGL c'est juste le compositing, ça ne rendra pas rapide ce qui est lent aujourd'hui. C'est plutôt aux drivers de s'améliorer (ou alors on fait comme Chrome, on utilise pas les libs du systems, et on fait tout à la main)
[^] # Re: Extensions firefox ?
Posté par Paul Rouget . En réponse au journal Firefox et les addons payants : bientôt un dénouement ?. Évalué à 9.
Michel (le dévelopeur) a créé une entreprise juste pour déveloper cet addon.
# J'adore.
Posté par Paul Rouget . En réponse à la dépêche WebOOB: voir les sites web différemment. Évalué à 5.
Je préfère ça à un truc comme Prism (même si Prism reste utile pour les gens normaux).
[^] # Re: mop mopi
Posté par Paul Rouget . En réponse au journal HTML 5 et vidéo : peux me faire. Évalué à 6.
Vous autorisez des plugins non libre, c'est la même logique que d'autoriser des codecs non libres : une interface avec un autre fournisseur.
Vous faites patent free? Alors interdisez Flash qui a plein de patents (dont ceux de H.264)
L'excuse de l'attaque possible par MPEG ne tient pas : vous n'êtes pas attaqués parce que vous pouvez lire du H.264 (puisque FF le peux par le biais de Flash...) par un plugin x, vous ne serez pas attaqué parce que vous pouvez le faire par un plugin y. Une interface avec le backend de l'OS (Windows ou Mac ou Linux) ne contiendrait aucun patent MPEG.
De plus, la MoFo date de 2003 si j'en crois Wikipedia, et le dernier patent JPEG a expiré en 2006 si j'en crois http://en.wikipedia.org/wiki/JPEG#Patent_issues , pourquoi ça n'a pas dérangé la MoFo entre 2003 et 2006?
Il y a une différence fondamentale entre les plugins et la vidéo: pour les plugins, on n'a jamais eu le choix! Ici, pour la vidéo, la technologie est à créer. On est maintenant en position plus ou moins dominante pour imposer nos choix (ce que l'on ne pouvait pas faire avant). C'est pour ça qu'on devient paranos sur SSL et sur les formats, parce que maintenant on peut.
Si il y a 10 ans (ça fait 10 ans qu'on a commencé Gecko, la nouvelle version) on avait supprimer plugins et JPEG, aujourd'hui on existerait tout simplement pas. Maintenant, on a 30% des utilisateurs. On a un poids important. On en profite pour pousser les bons formats.
Je comprends que ça fasse chier pas mal de gens, mais bon, ici on a la possibilité et l'occasion d'imposer un format ouvert et patent free tout en bloquant un format que l'on considère mauvais pour le web.
On espère que ça marchera et quand dans 10 ans on ne se pose plus la question et que la vidéo sera ouverte pour de vrai.
# pom pom
Posté par Paul Rouget . En réponse à la dépêche YouTube et les technologies Flash et HTML5. Évalué à 7.
Quelques infos en plus:
Format standard de vidéo
Compte tenu du nombre important de vidéos déposées par les utilisateurs (plus de 24 heures de vidéo chaque minute), il est nécessaire de limiter le nombre de formats vidéo, surtout lorsque l'on propose différentes tailles de la vidéo (360p, 480p, 720p, 1080p). Depuis 2007, toutes les vidéos de YouTube sont codées avec le codec H.264. Le lecteur Flash, ainsi que les terminaux mobiles tels qu'Android ou iPhone supportent ce format. John Harding pense que le web se doit d'avoir un standard vidéo libre et ouvert. Le projet WebM pourrait être une alternative intéressante.
De notre côté (Mozilla), WebM et ogg/theora sont les seules options (logiciel libre + patent free).
Un standard robuste
Étroitement liée à la nécessité d'un format ouvert, l'un des besoins de YouTube est d'offrir la capacité à ses utilisateurs d'être redirigé directement sur une séquence précise de la vidéo. Le lecteur Flash permet ceci via Actionscript en conjonction des protocoles HTTP et RTMP (Real Time Messaging Protocol). HTML5 ne propose pas encore ce genre de fonctionnalité, même si un certain nombre d'institutions et organisations travaillent sur ce point.
Le W3C et nous-même y travaillons (ainsi que sur de l'adaptative streaming).
Vidéo plein écran
Bien que les navigateurs proposent un mode plein écran, ce mode ne peut être initialisé via JavaScript, ni même permettre le plein écran d'une seule partie du contenu web (par exemple le lecteur vidéo). Seul Flash permet cette fonctionnalité, même si des initiatives existent avec les avancés de WebKit.
L'idée c'est de n'autoriser le fullscreen que sur l'intervention de l'utilisateur.
On y travaille aussi: https://bugzilla.mozilla.org/show_bug.cgi?id=545812
Accès à la caméra et au microphone
Chaque jour, des milliers d'utilisateurs enregistrent des vidéos directement sur YouTube à partir de leur navigateur à l'aide de leurs webcams. La technologie Flash est éprouvée sur ce point alors qu'HTML5 n'en est qu'aux balbutiements (Spécifications HTML5).
C'est les specs DAP plutot (il y a le tag "device" d'HTML5, mais bof bof). On y travaille (pas pour la vidéo, mais pour prendre des photos à partir de la webcam).
Sinon, clairement Flash est plus avancé. Mais bon, faut bien commencer et on peut pas avoir tout du jour au lendemain :)
# mop mopi
Posté par Paul Rouget . En réponse au journal HTML 5 et vidéo : peux me faire. Évalué à 7.
Bah on fait du logiciel libre et patent free. Après, chacun ses priorités.
- Vidéo plein écran impossible, oui c'est n'importe quoi de permettre la lecture vidéo sans pour autant autoriser la lecture plein écran!
https://bugzilla.mozilla.org/show_bug.cgi?id=545812
(prévu pour Firefox 4)
- Aucune gestion de la bufferisation ou de la gestion dynamique de la qualité dans HTML5 (à croire que la balise a été crée par des non expert en vidéo, la gestion fine de la bufferisation, c'est important pour beaucoup de monde!)
https://bugzilla.mozilla.org/show_bug.cgi?id=462957
(prévu pour Firefox 4)
- Pas facile d'aller à un endroit précis de la vidéo (j'ai pas regardé de ce côté, on ne peut vraiment pas faire ça en HTML 5? Vous rigolez la?)
Ca dépend de ce que tu appelles précis. A un timecode précis, oui, on peut. A une frame precise, pas vraiment.
- C'est la merde pour mettre des sous-titre ou pub par dessus la vidéo (je suis toutefois surpris sur ce propos, je pensais qu'on pouvait utiliser une couche "texte" par dessus une couche "vidéo" comme on fait pour des images par exemple)
Ca c'est juste qu'ils sont mauvais.
- C'est limité à l'affichage, pas de gestion de la capture webcam/microphone (bon, après, le navigateur va devenir un fourre-tout ingérable, pas sûr que ce soit bien d'intégrer ça dans un navigateur, mais bon, vu que la mode est à tout mettre dans un navigateur web...)
Il y a des standards pour ça. DAP & Device API. Nous on bosse sur l'intégration de la caméra en ce moment.
Et la conclusion fait mal : HTML 5 c'est peut-être bien pour le futur, il faut y travailler (car aujourd'hui ça répond à un besoin très limité), en attendant Flash répond au besoin aujourd'hui, et cette caractéristique est très importante.
99% de ce que tu veux faire avec la video (la visualiser) ça marche très bien.
Mais on peut clairement faire mieux, et on y travaille \o/
[^] # Re: J'en rajoute une couche
Posté par Paul Rouget . En réponse à la dépêche Mozilla continue d'avancer !. Évalué à 2.
Done: http://linuxfr.org/interviews/26.html
# J'en rajoute une couche
Posté par Paul Rouget . En réponse à la dépêche Mozilla continue d'avancer !. Évalué à 10.
Pour ce qui est lié à Linux:
* Debian et nous, essayons de réintégrer Firefox dans Debian https://bugzilla.mozilla.org/show_bug.cgi?id=555935
* Nightly builds 64bits dispo http://nightly.mozilla.org/
* On bosse sur le startup aussi http://blog.mozilla.com/tglek/2010/04/05/linux-how-to-make-s(...)
* On bosse sur les ProfileOptimized builds https://bugzilla.mozilla.org/show_bug.cgi?id=418866
* D'autres trucs que j'oublie
Pourquoi on est plus lent que Chrome (je ne suis pas expert, je fais juste passer le message):
En partie parce que Firefox essaye d'utiltiliser X, en particulier XRender, pour dessiner. C'est intelligent en théorie car on profite de l'accélération des drivers. Dans la vraie vie, les drivers ne sont pas parfait, donc ça galère pas mal. Chrome utilise ça propre lib (Skia) pour le rendering, et donc évite les soucis avec les mauvais drivers X.
En partie aussi parce qu'on utilise le thème GTK (donc utilise X) pour afficher certain widgets (meilleure intégration). Chrome non.
Aussi parce qu'on utilise Pango et fontconfig, qui est assez lent (Chrome, encore une fois, fait tout à ça manière).
Bref, le fait d'essayer de s'intégrer au mieux à Linux n'aide pas toujours.
Et aussi, on est plus lent parce que Chrome fait mieux les choses que nous à beaucoup d'endroits :) Mais on y travaille :)
Niveau Standards:
* on a un vrai parseur HTML5 (je crois que pour le moment on est les seuls) http://hacks.mozilla.org/2010/05/firefox-4-the-html5-parser-(...)
* on a les webforms qui avancent sérieusement https://wiki.mozilla.org/User:Mounir.lamouri/HTML5_Forms
* vous avez entendu parlé de webm (vp8)
* CSS3 toujours (transitions)
* JS largement accéléré
* WebGL (OpenGL en javascript)
* SVG/SMIL
* Indexed Database API (concurrent de sqlite database, que l'on aime pas)
* Encore des trucs que j'oublie
Niveau mobile:
* on a un version 1.1 pour Fennec (que Maemo) sur les rails, ça devrait pas tarder.
* pour la fin de l'année, une version 2.0 (Maemo + Android).
[^] # Re: HTML5 & Canvas
Posté par Paul Rouget . En réponse à la dépêche Les technos web cools du moment. Évalué à 3.
En fait, il faudrait un équivalent slideshare en HTML/CSS.
# HTML5 & Canvas
Posté par Paul Rouget . En réponse à la dépêche Les technos web cools du moment. Évalué à 7.
# un n900
Posté par Paul Rouget . En réponse au journal Cet ordinateur de poche existe-t-il ?. Évalué à 10.
[^] # Re: Theora
Posté par Paul Rouget . En réponse au journal De youtube, html5, H264 et ubuntu. Évalué à 7.
Dirac is great. At some point we'll probably add Dirac support.
However, at typical Web bit rates, Dirac doesn't currently perform
as well as Theora. The patent situation with Dirac is also currently
less clear than with Theora. We'll keep an eye on it.