Tu pourrais quand même lire l'article avant d'en faire un journal, il y a tout un paragrpahe intitulé "Distinguishing SaaS from Other Network Services" qui explique pourquoi il ne considère pas les gestionnaires de projet comme du SaaS. Tu peux ne pas être d'accord avec cette façon de penser, mais tu ne peux pas dire que c'est incohérent.
D'après leur site, mplayer2 implémente les precise seeks, ce que ne fait pas mplayer.
Et ça doit plutôt être une anti-feature à mon avis: si la vidéo que tu veux lire a un écart de 10s entre chaque keyframe, soit tu as un énorme lag à chaque fois que tu veux faire un seek, soit tu obtiens une image très crade...
Les onglets ne sont pas la solution universelle. Perso, j'ai pleins de fenêtres : terminaux (séparés par tag awesome selon le but, ie irssi, dével (un par tag), musique), le browser web, le client mail, et des evince (et là, pas encore d'onglets si je ne m'abuse). Au final, j'ai souvent mes 9 tags de remplis, avec de 1 à 4 fenêtres dessus, de préférence 2. Et c'est très pratique à l'usage, c'est comme une map, accès en temps log à chacune de mes fenêtres.
Annoter les pdfs, ça peut quand même être vachement utile, par exemple quand on est étudiant. Bon, pour l'instant j'ai jamais vraiment eu besoin de plus que xournal ou les fonctionnalités d'okular, mais ça me fera quand même vachement plaisir le jour où je pourrai annoter mes pdfs en utilisant une solution plus "propre".
J'avais déja -O3 et -march=native, je ne crois pas avoir le support du sse sur mon proco (mais je sais pas vraiment comment tester ça) (et c'est dommage, parce que j'en profiterais grandement). Le -fomit-frame-pointer est sensé être activé par -O3 (et même avant), le -funsafe-math est activé par -ffast-math.
Je crains que -funroll-loops n'ait pas d'effet sur mon code, la plupart de boucles sont des boucles while (et l'arrêt se fait sur une condition aléatoire).
-fwhole-program et -fsingle-precision-constant ça a l'air cool, faut que je teste :)
Je crois que la principale raison pour la lenteur de mon code, c'est que l'architecture est tout sauf optimisée (même pas de multithreading alors que c'est très facile à paralléliser, naive sur certains points).
Testé sur mon raytrcer joujou (donc avec pleins de cacluls en flottant, pour lesquels on n'a pas besoin de respecter les normes IEEE):
sans -ffsat-math : 117.68 sec
avec -ffast-math : 115.57 sec
Donc effectivement, pas mieux que du 2%, mais y a pas vraiment d'inconvénient en l'occurence, donc c'est toujours ça de pris (surtout que vu la lenteur de mon raytracer en l'état, pour des vrais rendus 2% ça peut me faire gagner beaucoup de temps. Et c'est même vrai pour les raytracers utilisés professionellement : quand ton film prend plusieurs jours à rendre, 2% de perfs c'est plusieurs heures de temps d'artiste passées à peaufiner des détails).
Et pour OpenGL, je crois bien que c'est plutôt un avantage je crois : on a pas envie que le driver crash parce que la matrice fournie par l'utilisateur était la matrice nulle.
L'option -ffsat-math va vraiment enlever pleins de règle de calcul en flottant:
On suppose que les nombres ne seront jamais NaN, ou infini
Plus d'exceptions divide by zero et autres
L'associativité du code peut-être revue pour chercher à optimiser.
Et d'autres que je ne connais pas. C'est une option qui est souvent mise quand on fait des calculs graphiques je crois. Par exemple, OpenGL précise qu'il ne doit jamais y avoir de crash en cas d'erreur de calcul en flottant, mais que le résultat affiché a le droit d'être faux auquel cas.
Posté par Shuba .
En réponse au journal SSL ....
Évalué à 3.
Cool, une bonne proportion de 4 millions d'habitants ça fait... Ah pas pas beaucoup au final. En France, c'est une bonne partie d'une population bien plus importante qui emprunte les routes de montagne chaque année pour aller skier. Et je suis bien content qu'il n'y en ait pas trop qui cassent leurs freins en descente parce qu'ils ont une boite auto et ne savent pa ce qu'est un frein à moteur.
J'ai deux reproches assez distincts à faire à la boite automatique:
Lorsque les utilisateurs sont mal éduqués, pas de frein à moteur, donc risque de sur-usure des freins en descente (il y a malheureusement eu pas mal d'accidents liés à ce problème).
Fondamentalement, c'est moins efficace qu'une boite manuelle, parce qu'adapter le régime du moteur est fortement lié à la connaissance de la route, ce qu'à ma connaissance une voiture n'a pas. Ou alors il va falloir me donner un exemple d'un pilote qui conduit mieux en montagne avec une boite automatique.
Posté par Shuba .
En réponse au journal SSL ....
Évalué à 5.
La voiture avec boite de vitesse manuelle
Mouais, le comportement des boites automatiques c'est quand même de paser à la vitesse supérieure quand ça accélère, ce qui est quand même le contraire de ce qu'il faut faire en descente en montagne. alors ça marche aux USA, où t'as tellement peu de gens qui prennent des routes montagneuses que c'est pas grave s'ils savent pas qu'il y a un réglage frein à moteur sur leurs boites, mais ça parche pas en france, où une grande partie de la popoulation fait de la route de montagne au moins une fois par an.
Et c'est valable aussi en montée, j'ai pas encore vu une boite automatique qui sache mieux préparer un virage que moi (il faudrait qu'elle sache qu'un virage approche...).
Maintenant quand il parle de nouvelles fonctionnalités, cela implique surtout que l'API Direct3D a intégré des facilités dans son interface. Supposons qu'aucune des API ne savait faire des boules. Puis notre bonne API se dit: tiens, je vais intégrer un algorithme pour faire une boule et j'encapsule ça dans une fonction que j'appelerai ball(r). On peut maintenant faire des boules en une ligne de code. De son côté la mauvaise API n'a pas la fonction encore. Cela ne signifie pas que les développeurs ne peuvent pas faire de boule. Simplement ils sont obligés de calculer eux même ses limites, puis les remplir (avec d'autres types d'objets que l'API sait faire). C'est donc chiant. C'est en gros, ce qu'ils disent dans l'article là:
While newer versions of OpenGL have kept up-to-date with some of the features found in DirectX, including DirectX 10's geometry shader, they usually have to be implemented via extensions, rather than the main API.
Désolé mais tu ne peux pas affirmer que l'on peut contourner l'absence d'un certain type de shader. Les shader représentent la capacité de progerammer certaines parties du pipeline de la carte graphique, et si tu n'en disposes pas, la seule chose que tu puisses faire pour les remplacer, c'est coder leur effet sur le CPU, ce qui va vraiment impacter tes performances. En l'occurence là, les geometry shaders permettent de re-tesseler un mesh à la volée, ie d'augmenter de façon contrôlée et performante le niveau de détails. Sans ça tu es obligé de stocker/charger/envoyer à la CG des meshs bien plus gros (et vu qu'un des bottlenecks typique c'est le transfert de données entre la mémoirex hoost et celle de la CG, bah tu perds vraiment en perfs pour la même qualité visuelle.
Et quand on parle de pouvoir implémenter quelquechose via les extensions, généralement ça veut dire que ça va pas passer dans toutes les cartes graphiques. Alors c'est très cool si tu développes en interne, parce que tu sais exactement quelles extensions tu peux utiliser, mais pour distribuer, bah tu peux pas te rendre incompatible avec une trop grande partie du marché.
Je suis sûr qu'il y a un marché pour ça, c'est particulièrement intéressant pour les majors qui veulent pouvoir détecter si les clips de leurs artistes ont été uploadés sur Youtube.
Oui, le fait qu'ils aient Goggles implique qu'ils ont déja la base de données pour reconnaitre ce genre d'images, mais après, est-ce qu'ils ont vraiment envie de divertir une grosse puissance de calcul à faire des matching tout le temps?
C'est sans doute parce que le programme de maths au lycée est epsilonesque par rapport à ce qui est étudié en prépa, et qu'on demande beaucoup moins des élèves.
Dans l'enseignement supérieur, dire que quelquechose est calculatoire implique qu'il va falloir bien chercher des astuces de calcul poour finir dans les temps, mais sans une compréhension des maths en dessous je vois pas comment on peut faire. D'où l'idée que ça doit quand même être assez corrélé.
La plupart des X qui deviennent chefs d'entreprise ont fait le corps des Mines ou le corps des Pont (15% d'une promo), c'est surtout le réseau qui fait qu'ils parviennent à ces postes.
Ensuite, ceux qui rentrent dans les corps sont ceux qui obtiennent le meilleur classement de sortie, sur des examens réputés assez calculatoires (pas forcément super théoriques donc, mais être meilleur sur des épreuves calculatoires, je pense qu'on peut dire que c'est corrélé avec le niveau en maths).
Mais n'empêche que j'ai eu énormément de mal, en thèse, et encore aujourd'hui, avec certains des concepts les plus théoriques (je n'ai jamais eu de formation sérieuse en théorie des graphes, par exemple, et j'ai beaucoup de mal à écrire ou comprendre des preuves).
Sauf qu'à l'avenir ça arrivera de moins en moins aux étudiants de prépa qui auront pris l'option info, parce que cette option est justement fortement axée sur les graphes, la logique, les langages rationnels,...
Mais la prépa est quand même en train de prendre un sacré retard en ne proposant ce genre de formation qu'en option.
De mon expérience, une formation d'ingénieur, c'est plutôt technique + management, pas particulièrement de la théorie.
C'est bien beau de généraliser à partir de ton expérience personnelle, mais des écoles d'ingénieurs, il y en a des tas, et elles diffèrent vraiment sur le type de formation qui y est dispensé. Pour ma part j'ai tout sauf l'impression d'avoir eu une formation tournée vers le management, ni si technique que ça. C'est d'ailleurs le reproche souvent fait à l'X, d'avoir des formations trop tournées vers la théorie.
Oui en effet, ffmpeg implémente un décodeur très rapide. Pour l'encodeur, l'un des dev de ffmpeg avait commencé à en écrire un (http://multimedia.cx/eggs/the-worst-vp8-encoder/), mais apparemment plus dans le but de s'amuser qu'avec la volonté de créer une alternative à la libvpx.
Pour l'instant la seule alternative à H264 est Theora. Les deux codecs progressent de concert, et même si la qualité de Theora (implémentation ffmpeg) est desormais au niveau de H264 http://people.xiph.org/~greg/video/ytcompare/comparison.htmlhttp://people.xiph.org/~maikmerten/youtube/ il a encore du mal sur les images les plus complexes à encoder (pluie violente, pan scan avec un ciel étoilé, ressac des vagues sur la plage etc.)
Theora est tout sauf au niveau de h264 hein, cette comparaison elle dit que theora, sur un fichier donné, avec des options choisies aux petits oigons par le dév, et une keyframe toutes les 10 secondes, arrive à rivaliser avec h264 Baseline, avec les paramètres d'encodage de youtube ie pas adaptés à cette vidéo en particulier, et une keyframe toutes les secondes.
C'est pas vraiment une comparaison honnête. Pour les biais dans les comparaisons de codecs, http://x264dev.multimedia.cx/archives/472 en liste un bon nombre. Theora est bien trop loin derrière, et il vaut mieux compter sur vp8 à l'avenir.
Maintenant il semblerait (je ne suis pas en position pour juger) que Theora soit plus complexe à encoder/decoder que H264. Donc, même pour une petite boite, il faut que cette puissance de calcul supplémentaire nécessaire lui coute moins de 0,20cts par client pour que Theora devienne plus interressant que H264.
Apparemment, c'est surtout vp8 qui, actuellement, est affreusement long à encoder par rapport à h264. Vu qu'H264 est une norme et pas une implémentation, cela a permis une saine compétition entre les encodeurs qui a permis d'aboutir à des codecs très optimisés, alors que du côté de vp8, où seule le code de Google fait référence, il n'existe pas ou peu d'encodeurs alternatifs.
# RTFA
Posté par Shuba . En réponse au journal Mais pourquoi le projet GNU fait-il tout pour priver le monde de liberté ?. Évalué à 8.
Tu pourrais quand même lire l'article avant d'en faire un journal, il y a tout un paragrpahe intitulé "Distinguishing SaaS from Other Network Services" qui explique pourquoi il ne considère pas les gestionnaires de projet comme du SaaS. Tu peux ne pas être d'accord avec cette façon de penser, mais tu ne peux pas dire que c'est incohérent.
[^] # Re: Pareil
Posté par Shuba . En réponse au journal Suis-je le seul à ne pas utiliser VLC ?. Évalué à 1.
D'après leur site, mplayer2 implémente les precise seeks, ce que ne fait pas mplayer.
Et ça doit plutôt être une anti-feature à mon avis: si la vidéo que tu veux lire a un écart de 10s entre chaque keyframe, soit tu as un énorme lag à chaque fois que tu veux faire un seek, soit tu obtiens une image très crade...
# Framebuffer
Posté par Shuba . En réponse au journal Suis-je le seul à ne pas utiliser VLC ?. Évalué à 2.
De mémoire, vlc aussi peut lire des vidéos dans le framebuffer, après je me souviens plus comment on fait ça.
[^] # Re: La question de la limite des algorithmes
Posté par Shuba . En réponse à la dépêche GPG - les concepts en clair et pédagogiquement. Évalué à 4.
Moui, enfin tant que le contraire n'a pas été prouvé, ie qu'on n'a pas d'algo rapide pour résoudre ces problèmes, ça marche.
[^] # Re: Xmonad plussun
Posté par Shuba . En réponse à la dépêche WMFS, Window Manager From Scratch. Évalué à 2.
Sous awesome, il y a les modes max et floating pour ne pas être en tiling.
[^] # Re: Liste des fenêtres actives ?
Posté par Shuba . En réponse à la dépêche GNOME 3.0 : le grand saut !. Évalué à 3.
Les onglets ne sont pas la solution universelle. Perso, j'ai pleins de fenêtres : terminaux (séparés par tag awesome selon le but, ie irssi, dével (un par tag), musique), le browser web, le client mail, et des evince (et là, pas encore d'onglets si je ne m'abuse). Au final, j'ai souvent mes 9 tags de remplis, avec de 1 à 4 fenêtres dessus, de préférence 2. Et c'est très pratique à l'usage, c'est comme une map, accès en temps log à chacune de mes fenêtres.
[^] # Re: oui mais...
Posté par Shuba . En réponse au journal Asus EEE transformer. Évalué à 2.
Annoter les pdfs, ça peut quand même être vachement utile, par exemple quand on est étudiant. Bon, pour l'instant j'ai jamais vraiment eu besoin de plus que xournal ou les fonctionnalités d'okular, mais ça me fera quand même vachement plaisir le jour où je pourrai annoter mes pdfs en utilisant une solution plus "propre".
[^] # Re: Qui a dit que l'informatique était réservée aux hommes ?
Posté par Shuba . En réponse au journal Asus EEE transformer. Évalué à 8.
Il faudra bien que quelqu'un s'intéresse à ce genre d'engins pour qu'on puisse installer une distro GNU/Linux sans problèmes.
[^] # Re: option -Ofast
Posté par Shuba . En réponse à la dépêche La version 4.6 du compilateur GCC est disponible. Évalué à 1.
J'avais déja -O3 et -march=native, je ne crois pas avoir le support du sse sur mon proco (mais je sais pas vraiment comment tester ça) (et c'est dommage, parce que j'en profiterais grandement). Le -fomit-frame-pointer est sensé être activé par -O3 (et même avant), le -funsafe-math est activé par -ffast-math.
Je crains que -funroll-loops n'ait pas d'effet sur mon code, la plupart de boucles sont des boucles while (et l'arrêt se fait sur une condition aléatoire).
-fwhole-program et -fsingle-precision-constant ça a l'air cool, faut que je teste :)
Je crois que la principale raison pour la lenteur de mon code, c'est que l'architecture est tout sauf optimisée (même pas de multithreading alors que c'est très facile à paralléliser, naive sur certains points).
[^] # Re: option -Ofast
Posté par Shuba . En réponse à la dépêche La version 4.6 du compilateur GCC est disponible. Évalué à 3.
Testé sur mon raytrcer joujou (donc avec pleins de cacluls en flottant, pour lesquels on n'a pas besoin de respecter les normes IEEE):
Donc effectivement, pas mieux que du 2%, mais y a pas vraiment d'inconvénient en l'occurence, donc c'est toujours ça de pris (surtout que vu la lenteur de mon raytracer en l'état, pour des vrais rendus 2% ça peut me faire gagner beaucoup de temps. Et c'est même vrai pour les raytracers utilisés professionellement : quand ton film prend plusieurs jours à rendre, 2% de perfs c'est plusieurs heures de temps d'artiste passées à peaufiner des détails).
Et pour OpenGL, je crois bien que c'est plutôt un avantage je crois : on a pas envie que le driver crash parce que la matrice fournie par l'utilisateur était la matrice nulle.
[^] # Re: option -Ofast
Posté par Shuba . En réponse à la dépêche La version 4.6 du compilateur GCC est disponible. Évalué à 5.
L'option -ffsat-math va vraiment enlever pleins de règle de calcul en flottant:
Et d'autres que je ne connais pas. C'est une option qui est souvent mise quand on fait des calculs graphiques je crois. Par exemple, OpenGL précise qu'il ne doit jamais y avoir de crash en cas d'erreur de calcul en flottant, mais que le résultat affiché a le droit d'être faux auquel cas.
[^] # Re: Bis repetita
Posté par Shuba . En réponse au journal SSL .... Évalué à 3.
Cool, une bonne proportion de 4 millions d'habitants ça fait... Ah pas pas beaucoup au final. En France, c'est une bonne partie d'une population bien plus importante qui emprunte les routes de montagne chaque année pour aller skier. Et je suis bien content qu'il n'y en ait pas trop qui cassent leurs freins en descente parce qu'ils ont une boite auto et ne savent pa ce qu'est un frein à moteur.
J'ai deux reproches assez distincts à faire à la boite automatique:
Lorsque les utilisateurs sont mal éduqués, pas de frein à moteur, donc risque de sur-usure des freins en descente (il y a malheureusement eu pas mal d'accidents liés à ce problème).
Fondamentalement, c'est moins efficace qu'une boite manuelle, parce qu'adapter le régime du moteur est fortement lié à la connaissance de la route, ce qu'à ma connaissance une voiture n'a pas. Ou alors il va falloir me donner un exemple d'un pilote qui conduit mieux en montagne avec une boite automatique.
[^] # Re: Bis repetita
Posté par Shuba . En réponse au journal SSL .... Évalué à 5.
Mouais, le comportement des boites automatiques c'est quand même de paser à la vitesse supérieure quand ça accélère, ce qui est quand même le contraire de ce qu'il faut faire en descente en montagne. alors ça marche aux USA, où t'as tellement peu de gens qui prennent des routes montagneuses que c'est pas grave s'ils savent pas qu'il y a un réglage frein à moteur sur leurs boites, mais ça parche pas en france, où une grande partie de la popoulation fait de la route de montagne au moins une fois par an.
Et c'est valable aussi en montée, j'ai pas encore vu une boite automatique qui sache mieux préparer un virage que moi (il faudrait qu'elle sache qu'un virage approche...).
[^] # Re: Meilleure interface de développement, pas forcément meilleure 3D
Posté par Shuba . En réponse au journal Direct3D vs OpenGL. Évalué à 2.
Désolé mais tu ne peux pas affirmer que l'on peut contourner l'absence d'un certain type de shader. Les shader représentent la capacité de progerammer certaines parties du pipeline de la carte graphique, et si tu n'en disposes pas, la seule chose que tu puisses faire pour les remplacer, c'est coder leur effet sur le CPU, ce qui va vraiment impacter tes performances. En l'occurence là, les geometry shaders permettent de re-tesseler un mesh à la volée, ie d'augmenter de façon contrôlée et performante le niveau de détails. Sans ça tu es obligé de stocker/charger/envoyer à la CG des meshs bien plus gros (et vu qu'un des bottlenecks typique c'est le transfert de données entre la mémoirex hoost et celle de la CG, bah tu perds vraiment en perfs pour la même qualité visuelle.
Et quand on parle de pouvoir implémenter quelquechose via les extensions, généralement ça veut dire que ça va pas passer dans toutes les cartes graphiques. Alors c'est très cool si tu développes en interne, parce que tu sais exactement quelles extensions tu peux utiliser, mais pour distribuer, bah tu peux pas te rendre incompatible avec une trop grande partie du marché.
[^] # Re: Goggles
Posté par Shuba . En réponse au journal Des juges croient à la magie. Évalué à 1.
Je suis sûr qu'il y a un marché pour ça, c'est particulièrement intéressant pour les majors qui veulent pouvoir détecter si les clips de leurs artistes ont été uploadés sur Youtube.
[^] # Re: Goggles
Posté par Shuba . En réponse au journal Des juges croient à la magie. Évalué à 3.
Oui, le fait qu'ils aient Goggles implique qu'ils ont déja la base de données pour reconnaitre ce genre d'images, mais après, est-ce qu'ils ont vraiment envie de divertir une grosse puissance de calcul à faire des matching tout le temps?
[^] # Re: Les jeunes fuient les filières scientifiques ?
Posté par Shuba . En réponse au journal Populariser la science informatique. Évalué à 1.
C'est sans doute parce que le programme de maths au lycée est epsilonesque par rapport à ce qui est étudié en prépa, et qu'on demande beaucoup moins des élèves.
Dans l'enseignement supérieur, dire que quelquechose est calculatoire implique qu'il va falloir bien chercher des astuces de calcul poour finir dans les temps, mais sans une compréhension des maths en dessous je vois pas comment on peut faire. D'où l'idée que ça doit quand même être assez corrélé.
[^] # Re: Les jeunes fuient les filières scientifiques ?
Posté par Shuba . En réponse au journal Populariser la science informatique. Évalué à 2.
La plupart des X qui deviennent chefs d'entreprise ont fait le corps des Mines ou le corps des Pont (15% d'une promo), c'est surtout le réseau qui fait qu'ils parviennent à ces postes.
Ensuite, ceux qui rentrent dans les corps sont ceux qui obtiennent le meilleur classement de sortie, sur des examens réputés assez calculatoires (pas forcément super théoriques donc, mais être meilleur sur des épreuves calculatoires, je pense qu'on peut dire que c'est corrélé avec le niveau en maths).
[^] # Re: Les jeunes fuient les filières scientifiques ?
Posté par Shuba . En réponse au journal Populariser la science informatique. Évalué à 1.
Sauf qu'à l'avenir ça arrivera de moins en moins aux étudiants de prépa qui auront pris l'option info, parce que cette option est justement fortement axée sur les graphes, la logique, les langages rationnels,...
Mais la prépa est quand même en train de prendre un sacré retard en ne proposant ce genre de formation qu'en option.
[^] # Re: Les jeunes fuient les filières scientifiques ?
Posté par Shuba . En réponse au journal Populariser la science informatique. Évalué à 2.
C'est bien beau de généraliser à partir de ton expérience personnelle, mais des écoles d'ingénieurs, il y en a des tas, et elles diffèrent vraiment sur le type de formation qui y est dispensé. Pour ma part j'ai tout sauf l'impression d'avoir eu une formation tournée vers le management, ni si technique que ça. C'est d'ailleurs le reproche souvent fait à l'X, d'avoir des formations trop tournées vers la théorie.
[^] # Re: meuh....
Posté par Shuba . En réponse au journal Nouvelle version et nombres d'avis. Évalué à 10.
Paradoxe, non?
[^] # Re: .264
Posté par Shuba . En réponse au journal Firefox 7 avant la fin de l'année ?. Évalué à 2.
[^] # Re: .264
Posté par Shuba . En réponse au journal Firefox 7 avant la fin de l'année ?. Évalué à 4.
Pour l'instant la seule alternative à H264 est Theora. Les deux codecs progressent de concert, et même si la qualité de Theora (implémentation ffmpeg) est desormais au niveau de H264 http://people.xiph.org/~greg/video/ytcompare/comparison.html http://people.xiph.org/~maikmerten/youtube/ il a encore du mal sur les images les plus complexes à encoder (pluie violente, pan scan avec un ciel étoilé, ressac des vagues sur la plage etc.)
Theora est tout sauf au niveau de h264 hein, cette comparaison elle dit que theora, sur un fichier donné, avec des options choisies aux petits oigons par le dév, et une keyframe toutes les 10 secondes, arrive à rivaliser avec h264 Baseline, avec les paramètres d'encodage de youtube ie pas adaptés à cette vidéo en particulier, et une keyframe toutes les secondes.
C'est pas vraiment une comparaison honnête. Pour les biais dans les comparaisons de codecs, http://x264dev.multimedia.cx/archives/472 en liste un bon nombre. Theora est bien trop loin derrière, et il vaut mieux compter sur vp8 à l'avenir.
Maintenant il semblerait (je ne suis pas en position pour juger) que Theora soit plus complexe à encoder/decoder que H264. Donc, même pour une petite boite, il faut que cette puissance de calcul supplémentaire nécessaire lui coute moins de 0,20cts par client pour que Theora devienne plus interressant que H264.
Apparemment, c'est surtout vp8 qui, actuellement, est affreusement long à encoder par rapport à h264. Vu qu'H264 est une norme et pas une implémentation, cela a permis une saine compétition entre les encodeurs qui a permis d'aboutir à des codecs très optimisés, alors que du côté de vp8, où seule le code de Google fait référence, il n'existe pas ou peu d'encodeurs alternatifs.
[^] # Re: O Canada !
Posté par Shuba . En réponse au journal Neutralité d'internet, téléscopage. Évalué à 1.
[^] # Re: Pourquoi je n'aime pas Debian
Posté par Shuba . En réponse à la dépêche Debian 6.0 Squeeze est sortie. Évalué à 7.
Paquet : openssh-client
État: installé
Automatiquement installé: non
Version : 1:5.5p1-6
Priorité : standard
Section : net
Responsable : Debian OpenSSH Maintainers <debian-ssh@lists.debian.org>
Taille décompressée : 2 142 k
Dépend: libc6 (>= 2.11), libedit2 (>= 2.11-20080614-1), libgssapi-krb5-2 (>= 1.7+dfsg), libssl0.9.8 (>= 0.9.8m-1), zlib1g (>= 1:1.1.4), debconf (>= 1.2.0) | debconf-2.0, adduser (>= 3.10),
dpkg (>= 1.7.0), passwd
Recommande: xauth, openssh-blacklist, openssh-blacklist-extra