c'est pas de ça que je parle, une harmonique précise, correspondant à l'une des dimensions de notre univers à cordes
Tu parles d'une énergie qui se trouve derrière un horizon quantique (puisque là on ne la voit pas) et qui traverserait cet horizon suite à une synchronisation avec un boson isolé.
Alors juste pour donner un ordre de grandeur (rapide) si on voulait transformer notre bon système solaire en trou noir, il faudrait le compresser à une taille de 20cm de diamètre. Et encore ca serait un micro trou noir d'une durée de vie infinitésimale.
Il faut donc que l'énergie remontée par la vibration soit supérieure à l'ensemble de l'énergie contenue dans notre système solaire qu'elle soit remontée en quelques nanosecondes et qu'elle ne puisse pas se diffuser dans plus de quelques millimètres dans ce laps de temps.
Ici, on parle de plugins, dont personne ne peut avoir un contrôle total à priori.
Il y a deux logiques :
- Le plugin
- L'embeded
Dans le cas du plugin le navigateur ouvre une interface à lui pour un logiciel créé par un autre dev. C'est donc à l'autre dev de respecter les licences. Si demain je fais un plugin Active X qui enfreint des brevets, Microsoft n'a aucun soucis à se faire. Même si techniquement au niveau du runtime il n'y a qu'un seul éxecutable, je suis el seul fautif pour ne pas avoir respecter les licences.
Dans le cas de l'embed, le navigateur ouvre une interface à une Bibliothèque extérieure, puis apelle des composants de cette bibliothèque en leur donnant les droits sur cette interface. Dans ce cas les devs du navigateur doivent valider la licence de la bibliothèque et des composants qu'ils apellent. Mais ce qui se passe après que les composants aient été appelés n'aient plus de leur ressort. Il y a plusieurs exécutables distincts.
Et heureusement que ca se passe comme çà (Note : sinon je dépose un brevet, je fait moult plugins et je commence à attaquer tout le monde, ca peut être un business plan valable.)
tu m'excuseras, mais la phrase suivante est quand meme assez ambigue:
Alors le container MPEG4 part 14 est strictement identique au container mov étendu de 2003. Le truc c'est que la norme MPEG4 est sortie en 1999.
Pas un seul instant. La norme MPEG-4 est bien sortie en 1999. Le container de préférence au format MP4, M4A ou M4V est sorti en 2003 dans le cadre de la part14.
Avant il n'était pas question de container officiel du tout dans la norme MPEG4, simplement de compatibilité avec les containers existant. Mais tout le reste était défini et fonctionnait depuis longtemps quand le container a été choisi.
xvid, real, divx, wmv et autres h264 étaient déjà dans la danse.
Et bien je t'invite bien cordialement a mettre a jour les pages wikipedia en question qui disent explicitement le contraire, sources a l'appui, ainsi qu'a le signaler au service marketing d'apple qu'ils retirent leur blabla publicitaire mensonger. Je t'ai donne les liens plus haut, j'ai meme cite dans le commentaire.
Dans tous les exemples que tu cites, il n'ait question que de la part 14 quand il est question d'Apple. Il n'y avait PAS de containers officiel avant la part 14.
Et une fois de plus la part 15 s'empresse de redéfinir d'autres containers, le format .mov QT5 étant peu adapté au streaming.
J'ai beau relire encore et encore les pages et les citations, il n'est pas question de MPEG4 part 1.
Pour résumer la chronologie :
En 1998 le MPEG Group fini la norme MPEG4 part 1, Apple est moribond, Jobs regarde Next couler.
En 1999 la norme MPEG 4 est validée, Jobs fait des bulles en plastique pour Mac.
En 2000 Explosion du DivX, le format MPEG4 sur AVI hacké d'un codec MPEG 4 Microsoft.
En 2001 Apple sort un nouveau format Quick Time pour les futures versions. Le format est déposé. Le MPEG-Group s'inspire beaucoup de ce format pour leur travaux.Ils travaillent à améliorer le format avec Apple, puis y ajoutent des éléments spécifiques à MPEG
En 2002 Quick Time 6 sort, c'est le premier de la série des quick time qui supporte le MPEG4. H264 étant non supporté, Sorenson et H263 restent les formats les plus efficaces sous QT
En 2003 les formats MPEG sortent officiellement.
En 2005 Apple sort QuickTime 7 qui supporte enfin le H264. Il devient le premier lecteur full Mpeg4 part 10 grand public.
Je pense que ton problème vient du fait que tu ne comprend pas ce que représentent les part pour le MPEG Group.
La part14 ne défini QUE le container, tout le reste a déjà été traité avant.
Dès la part1 on peut faire du MPEG4. En fait on est jamais obligé de respecter TOUTES les parts. (Seule la 1 est obligatoire).
On peut donc continuer à faire du mpeg2, quantizer h263 dans de l'avi et appeler ca du MPEG4 sans que qui que ce soit puisse y trouver à redire.
Non.
Part 14, c'est 2003.
Point.
Je n'ai JAMAIS dit le contraire.
La part 1 c'est 1999. ET Apple n'a pas contribuer à la part 1. C'est tout ce que je dis (et google encore moins)
Deja, t'es au courant que mov a ete cree avant 2003 quand meme?
C'est un format qui a 20 ans!!! J'ai aucun doute qu'apple l'a fait grandement evolue depuis, mais sortir un argument d'anteriorite face au mov, c'est fort de cafe quand meme...
T'es au courant le le .mov ne veut rien dire. Qu'il y a eu une floppée de container tous complètement différents et que c'est le container de 2003 qui a été retenu dans la part 14 ?
C'est meme pas des différences subtiles comme entre avi v1 et avi v2 qui agrandi juste la taille des pointeurs pour passer la limite des 2Go, c'est des formats de fichiers qui n'ont rien à voir.
La base de travail a été la specification publiée en 2001 sur les formats quicktime 5. Mais la finalisation pour quicktime n'a eu lieu qu'en 2002 (Quicktime 6) et le format de fichier n'a été validé qu'en 2003.
Bien que les différence soient faibles le format mov QT5 et QT6 diffèrent, notamment pour des raisons d'informations de synchronisation audio.
Je vais te repondre aussi "gni?" et reiterer.
Le mpeg vend des licences d'exploitation sur ses brevets, celui qui a une licence peut l'implementer. Une licence, c'est une licence, ca te donne le droit d'implementer l'algorithme couvert par le brevet. Que ca soit pour du mpeg, du theora ou ton truc fait maison. C'est le concept meme du brevet.
Cool. C'est juste con que la licence MPEG4 ne soit pas une licence sur l'ensemble des brevets mais une licence d'implémentation du MPEG4 et rien d'autre. Ca a été confirmé plusieurs fois au tribunal. En fait c'est même le but du MPEG Group : mettre tous les brevets en commun pour éviter que chacun ne dévelloppe son propre format dans son coin.
En plus dans le cas très précis du MPEG-4, il y a un brevet de Qualcom qui a été semi-invalidé en cour pour défaut de divulgation et qui n'est pas opposables aux licenciés MPEG-4 qui font des formats compatibles H264. Par contre il est opposable si le format n'est pas compatible.
Ensuite, je veux bien que tu m'expliques la difference entre avoir une licence sur les brevets et avoir une "licence pour faire du mpeg4".
Dans un cas tu as payé pour chaque brevet, éventuellement très cher, et tu fais ce que tu veux. dans l'autre cas tu paies une somme forfaitaire assez ridicule (N.B : Oui 1M$ pour une utilisation illimité en diffusion par exemple, c'est faible) mais tu ne peux utiliser les brevets QUE dans le cadre du MPEG-4. Donc tu te dois de respecter au moins toute la partie 1 du MPEG4.
Les autres membres, quand ils ont rejoint le group mpeg, ils se justement mit d'accord pour ne PAS attaquer les autres membres sur les brevets mit en commun.
Dans le strict cadre du MPEG-4 une fois de plus...
C'est un peu le concept du mpeg, c'est de mettre tout le monde ensemble, pour bosser ensemble, et pour eviter que ca chie dans la colle, on demande a tout le monde de signer un accord de non aggression.
Dans la mesure ou il y en a pas un qui décide de prendre tous els brevets des autres, d'y rajouter sa sauce perso qui améliore tel ou tel truc et de pondre un format incompatible tout seul dans son coin. C'est aussi çà (et même en fait principalement çà) le but du MPEG Group.
Ensuite, empresses toi de modifier les pages wikipedia sur le mpeg4 part 14 et le mov, parce qu'elles precisent bien que mov a donne mpeg4 part 1
Je ne le vois pas (essayé les pages anglaises et francaises)
Je penses que tu confonds MPEG4 part 1 et MPEG4 file format version 1 (qui est inclus dans le part14)
le MPEG4 part 1 ne défini pas de format de fichiers mais défini juste la synchronisation audio/vidéo/image au sein des formats existant validés pour le MPEG4 (ASF, AVI, Bink, Real etc.)
Non, la question ne se pose effectivement pas, vu qu'on voit mal le mpeg group attaquer quelqu'un pour avoir implementé un brevet dont il lui a vendu une licence.
Gni ? Ils ont pas de licence sur le brevet les clients, ils ont une licence pour faire du MPEG4. Ca ne veut absolument pas dire qu'ils peuvent créé un autre format de fichier utilisant les brevets de la licence.
Donc d'un coté le H264+ MPEG4 ne coute rien de plus à Google ou à Apple (qui doivent déjà avoir des licences full), de l'autre, avec le Theora, ils prennent le risque de se prendre tous les autres membres du MPEG-Group sur la gueule voire d'être exclus du groupe.
Le choix est très vite fait...
Deja imaginer apple faire autre chose que du mp4 sachant qu'ils ont fortement contribue au standard (le conteneur est largement base sur le mov)
Alors le container MPEG4 part 14 est strictement identique au container mov étendu de 2003. Le truc c'est que la norme MPEG4 est sortie en 1999.
En fait la plus grosse contribution de Apple au codec (puisque que c'est un peu de çà dont on parle, les brevets sur les containers ca coure pas les rues) c'est le Apple lossless (qui à ma connaissance n'est pas très utilisé).
En plus le container part 14 étant fragile, surtout lors de transmission distante (l'entête est fixe et pointe les codecs en bout de fichier), il a été ajouté six mois après le part 15 qui autorise tout un tas d'autres containers.
Que ce soit pour la télé HD ou les Blu-Ray le part 14 n'est pas utilisé.
Après les formats les plus utilisés (AAC, MPEG-2, ITU-H264 AVC, ALS) Apple n'y est pas pour grand chose. Je doute fort que les autres membres du groupe considère qu'il a fortement contribué à autre chose qu'à populariser le H264 (avec Real)
Je rappelle que le concept du group mpeg, c'est: on se met tous ensemble, chacun met ses brevets dans le pot commun, on donne a TOUS les membres le droit d'implementer lesdits brevets, et en plus on se met d'accord pour pas se taper dessus avec les autres brevets qui sont pas dans le pot.
Le MPEG Group créé une norme que le MPEG LA vend. Ensuite le MPEG LA reverse l'argent aux membres du MPEG Group. Pour être utilisé à des fins de recherches. (En d'autres termes une bonne partie de l'argent sert à financer les labos)
Les membres du groupe payent leur licences comme tout le monde, sauf qu'ils récupèrent une partie de l'argent. Etre membre du MPEG-Group ne veut pas dire pouvoir faire ce que l'on veut avec ses licences.
Ceci étant pour 5M$ on a accès illimité à tout pour l'ensemble de sa companie. Quand on sait que pour être membre du MPEG Group il faut au minimum un petit labo, et qu'un petit labo avec de vraies têtes dedans ca coute minimum 200 ou 300 000$ par mois. On se dit que payer la licence full c'est pas déconnant pour les grosses boites.
Là tu as tout l'historique de la création du MPEG Group. Il se trouve que le créateur du MPEG Group Chiariglione a vidé sa page récemment (Et accessoirement a moins recemment créé une boite spécialisé dans le DRM).
Si tu as le courage d elire tout le texte tu verras que tout le monde s'est couché devant Chiariglione. Y compris AT&T qui avait pourtant les algos sur l'estimation de mouvement, l'interpolation, l'entrelacement etc. "In fact," Haskell continued, "AT&T [had] contributed a lot of technology to MPEG-2, such as motion-compensated interpolation, interlaced motion compensation, [and so on]. Moreover, none of these technologies existed before MPEG. So MPEG is something more than selecting from off the shelf. The researchers involved actually invented new technology."
En fait au départ c'était plutôt collaboratif comme environnement. Le laboratoire originel était à Turin avec de gros liens vers Bell Telecom. Les bons codeurs étaient chez AT&T et les fabriquants de matériel étaient chez C-Cube et IBM. Tout le monde avait intérêt à ce que la télé HD fonctionne. Pour le standard HDTV il y a eu un mini clash entre AT&T et le groupe de Chiariglione. Mais la solution AT&T était très chère. Donc AT&T a décidé de contribuer au MPEG-Group pour profiter du génie de Chiariglione.
C-Cube s'est empressé de fabriquer les premières puces de compression et IBM s'est empressé de faire mieux.
C'est ainsi que le MPEG-2 est né et le que MPEG Group s'est trouvé sur-légitimé. La quantité de propriété intellectuelle transférée vers le MPEG Group est tout simplement colossale.
MPEG-4 a bien failli être boudé à cause de sa licence initiale. Mais en 2002 il a été largement reconnu par les acteurs du monde audio visuel http://www.zdnet.fr/actualites/telecoms/0,39040748,2119318,0(...)
A ce moment là aucune contestation n'a eu lieu.
Depuis on est dans uen situation de lock assez violent. Le MPEG Group possède désormais les brevets sur les conversions d'espace de couleur, la recherche de mouvement, la prédiction de mouvement, l'interpolation bloc à bloc, l'entrelacement bloc à bloc, l'interpolation full frame, moultes techniques de recherches rapides d'ondelettes et j'en passe.
A ma connaissance il ne reste guère que la compression fractale et l'expansion spline( vectorisation de l'image par la technique des moindres carrés) qui ne soient pas bardés de brevets.
A noter que le codec Indeo, très très prometteur à l'époque, a été revendu par Intel à Lingos qui ne semble pas vraiment en faire usage... (15$ la licence, pas encore de versions compatible Vista ou seven en vue). Il est également basé sur les ondelettes, mais il est sorti avant que le travail sur le MPEG4 ne commence réellement.
Chiariglione a également activement participé à la création du layer3 (connu sous le non de MP3) et à la création de puces capables de le lire.
La difference avec n'importe quel autre gros patent troll ?
Même IBM se couche sans moufter devant le MPEG-Group.
Mais quel que soit le resultat, un format non librement accessible n'est pas compatible et ne repond pas au cahier des charges d'un Internet ouvert.
Là je suis entièrement d'accord. Mais je garde mes réserves vis à vis de Theora (à Savoir qualité moyenne, méthode de compression/décompression trop similaire à ce qui a été breveté par le MPEG-Groupe, dialogue avec les différents acteurs du marché nul ou presque.)
Qui sont les prescripteurs ? Madame Michu ou les geeks ?
Madame Michu. Si tu as un doute, regarde la progression de IE 8.0 dans les stats.
Rien n'empeche de l'avoir aussi en h.264 tant qu'il y a a cote de ca un format lisible et accessible.
Sauf que si tous les navigateurs du monde ont accès à Theora mais pas à H264, ca fera un manque à gagner pour le MPEG Group. Donc ils feront un procès.
Doit-on donc rendre les armes et accepter un format non librement accessible pour cause de racket par un patent troll ?
Non je dis juste de ne pas compter sur Google/Nokia/Apple pour la promotion de Theora.
L'EFF, l'OIN, la FSF et autres associations, plus la mauvaise publicite enteraient en jeu.et ca risque de faire mal aussi.
Tu connais les membres du MPEG Group ? Tu penses que madame Michu en a quoi que ce soit à faire ? Si un standard gratuit viens prendre la place du MPEG-4 ils perdent une bonne partie de leur revenus. Ils attaqueront quoi qu'il arrive si Theora passe sur le devant de la scène.
Par ailleurs, Google doit avoir un bon nombre de brevets a sa disposition pour se defendre
Ni Google, ni Apple, ni Nokia n'ont quoi que ce soit pour se défendre contre le MPEG Group. Pour rappel le MPEG Group ne s'interresse qu'aux algorithmes vidéos et à leur implémentation hardware. Ils ne font pas de logiciel, ils ne font pas de matériel, ils ne font pas de réseaux. Il vendent une norme, un code de référence bateau et la possibilité d'utiliser des algos.
De plus quand les travaux sur le MPEG-4 ont commencé, on était en 1996. La norme est sortie en 1999. Apple était dans les choux (et puis bien), Google n'éxistait même pas et l'idée de mettre de la vidéo sur un téléphone portable était tout simplement risible.
Je ne pense pas que ces trois sociétés aient les moyens de faire pression sur le MPEG Group. Et je pense que leur timidité vis à vis de Theora s'explique assez facilement par le fait qu'ils le savent très bien.
Google fait parti de l'OIN, non ?
Et libtheora fait parti des system components de l'OIN, non ?
Cela ne risquerait-il donc pas de declencher une bonne grosse guerre des brevets ?
Peut-être, mais tant que Theora n'est pas un standard, le MPEG Group n'a aucun intéret à attaquer Xiph. Ils ne peuvent pas gagner beaucoup d'argent (du moins pas en regard de ce qu'ils ont l'habitude de gagner) et ils peuvent voir des brevets être invalidés au Tribunal.
Si Google, Apple et Nokia implémentent Théora, le MPEG Group a tout intéret à attaquer Xiph. Ils ne peuvent toujours pas gagner beaucoup d'argent avec Xiph, ils risquent toujours de se faire briser quelques brevets, mais par contre ils peuvent gagner vraiment pas mal d'argent si ils gagnent le procès contre Xiph et qu'ils se retournent alors contre Google, Apple et Nokia.
Et puis quand bien meme mpeg groupe attaque xiph pour violation de brevets, ceux-ci ne se retrouveraient-ils pas corriges dans les heures suivantes ?
Pas si évident que celà. Le MPEG Group possède des brevets sur des pans entiers de mathématiques appliqués à la compression des vidéos. Que ce soit au niveau de la prédiction de mouvement ou de l'utilisation des ondelettes ils ratissent plutôt large.
On pourra éventuellement trouver/écrire un autre codec libre, mais je doute qu'il puisse être compatible avec les vidéos Theora existante.
Mais c'est tout de même un manque de transparence pour le public qui est incité à croire que ces vannes viennent de Roland,
A part Elie Semoun, qui n'a pas hésité à dire qu'un de ses auteurs était Dubosc, je ne connais pas beaucoup de comiques qui livrent le nom de leurs auteurs. Il ne faut pas croire que dans un spectacle complet, tout a été écrit par le comique sur scène, c'est même assez rare.
Quant un chanteur fait une reprise, il indique généralement de qui est l'original; de même pour les dessins "blabla d'après plop de M. Machin".
Au niveau des interprètes ca arrive, même si ça n'est pas forcément le cas. Donc effectivement Bill Cosby étant l'interprète, Magdane aurait pu le mentionner. Par contre au niveau des auteurs, il y a un mépris généralisé à l'exception du monde du livre. Les auteurs de roman et les scénaristes de bande dessinées sont reconnus. Mais alors les paroliers, les dialoguistes, les scénaristes et autres auteurs de billets humoristiques sont royalement méprisés....
T'est-il venu à l'esprit, même une seule seconde, que Roland Magdane s'était acquitté des droits sur cette œuvre ?
Soit lui directement, soit la personne qui a traduit le sketch ?
Surtout que Google a l'air de dire que Magdane considère Bill Cosby comme un de ses modèles.
Pour cela, il faut inciter les diffuseurs à expérimenter (Cf OpenVideo) en Theora, emmerder Google/Apple/Nokia pour supporter Theora dans leur navigateur
A la seconde ou Google/Apple/Nokia décideront de faire du Theora, tu peut être sur que le MPEG Group, et d'autres feront une série de procès à Xiph pour violation de brevets. Après il est plus que probable qu'ils gagnent au moins un de ces procès et qu'ils se retournent alors contre Google/Apple/Nokia en les sommant de se mettre en règle (comprendre payer les licences au prix fort car la marge de négociation sera alors nulle).
Donc casser les pied à Google/Apple/Nokia ne changera pas grand chose. Ils ne prendront pas le risque financièrement.
La seule chose possible serait soit de militer contre les brevets logiciels jusqu'à les faire annuler (mais là je doute que Google/Apple/Nokia qui vivent en partie des royalties sur leurs brevets aident beaucoup), soit d'espérer qu'un jour le MPEG Group commence à intenter des procès contre des petits projets, ou des projets libres de façon à pouvoir tester au tribunal quels sont les brevets qui tiennent et ceux qui sont dénoncés.
Mais pour le deuxième cas, comme le MPEG Group fait très attention à ne pas attaquer les petits projets, c'est pas gagné non plus.
2- Une entreprise arrive avec son codec plein de brevets quelque temps plus tard et m'attaque parce que mon logiciel peut utiliser leur codec et me demande de payer une licence parce que des utilisateurs peuvent utiliser mon logiciel avec leur codec d'installe sur leur machine.
Perdu, ton produit n'utilise pas leur codec, il transmet juste les infos à DirectShow. En tant que dev du programme tu as juste à valider que ton produit a bien le droit d'utiliser DirectShow (ce que tu as déjà du faire avant que le codec machin n'arrive dans DirectShow)
En tant qu'utilisateur tu as juste à valider le fait que tu as le droit d'utiliser DirectShow et le produit. Il suffit (sic) de lire les licences.
La partie utilisation de DirectShow par le produit ne te concerne pas. Elle ne fait pas partie des obligations que tu as. Néamoins si un des ayant droit t'informe que ce produit utilise DirectShow illégalement, tu dois en cesser l'usage (mais il n'y a pas de pénalités)
Ceci étant si tu relis bien mon post, tu verras que je réagissais seulement à la partie "anyone in the product chain has liability". C'est tout simplement absurde. Quel code judiciaire supporterait ça ?
En disant que tous les produits du monde sont soumis à ce type de contraintes dans la majorité des pays du monde. J'ai bien fait attention à utiliser des termes génériques pour que l'on comprenne bien que le sens était général.
"anyone in the product chain has liability". C'est tout simplement absurde. Quel code judiciaire supporterait ça ?
Tous les codes judiciaires au monde ou presque.
C'est à la charge du fabriquant de vérifier qu'il a le droit de faire le produit, c'est à la charge du grossiste de valider qu'il a le droit de revendre, à qui et sous quelles conditions, idem pour le détaillant/distributeur et c'est à la charge du consommateur de vérifier que le produit qu'il achète ne relève ni du recel ni de la contrefaçon.
Et quand tu vois le prix que ces machines coutent, le fait qu'elles sont dediees a une tache bien precises (ce qui rend la gestion du stock plus dure), ca heterogeneise le parc, ben les clients commencent a se dire qu'ils pourraient remplacer tout ca par un bete core2duo avec un carte nvidia qui depote bien, perdre un peu en performance, mais plus s'emmerder avec une palanquee de station esoterique.
Quand je compare le prix d'une station SGI ou Wildcats au prix d'une licence Catia, je me dis que si Dassault System (puisque c'est l'exemple que tu cites) décide de faire un portage de OpenGL à DirectX et de Unix à Windows ca doit pas être seulement pour faire plaisir à un SI qui aimerait bien avoir que du x86 dans son infra....
moi je crois que tu es à la rue...
Le fait que je sois à la rue aujourd'hui, ce que j'admet volontier et répète souvent moi même n'a aucun impact sur ce qui c'est passé à l'époque alors que je n'était pas vraiment à la rue.
Hors ce qui s'est passé à l'époque (ie entre 1997 et 2005) est ce qui a fait qu'OpenGL est passé à la trappe au profit de DirectX dans le cadre strict du jeu video.
A noter que d'après certains commentaires OpenGL semble aussi passer à la trappe dans le cadre des applications pro...
Non, encore une fois c'est faux. Toutes les cartes nvidia depuis la première geforce n'ont pas de quoi gérer les hints dont tu parles, les hint en question n'existent plus et ne servent à rien. Source : je suis le fondateur de nouveau donc je connais le hard nvidia un peu.
Tu me dis trois réponses plus bas que OpenGL est une spec pas une implementation.(Ce qui est parfaitement exact par ailleurs). Or l'interpretation ou non des HINTS peut être fait en hard directement en mettant le bon regsitre à la bonne valeur. En hard indirectement en activant ou en coupant certaines fonctions via d'autres registres ou encore en soft dans le pilote avec des bidouilles qui impliquent plus ou moins var pas du tout des interventions dans le hard.
Maintenant en ce qui concerne les TNT. Je me fous de savoir qu'il y ait un registre GL_HINT dans la carte et que les geforce ne possèdent pas de registre similaire. Quand la TNT est sortie on était au tout début de l'OpenGL , et le pilote de base windows était pur soft. J'ignore complètement si la TNT gérait correctement les HINTS ou pas.
Par contre je peu te dire que la Quadro sortie quelques années après, qui était une super Geforce, elle les gérait de façon tout à fait correcte. Même si il n'y a pas de registres dédiés dans le hard. Ca devait se régler à coup de paramétrage du T&L ou autres gruikeries soft+hard mais là j'ai pas le code des pilotes de l'époque.
Par contre je peux te dire que les HINTS ca comptait pas mal, et à ma connaissance ca compte toujours pas mal dans le monde professionnel. Dans le dernier bouquin papier que j'ai acheté, le Red Book 2004 OpenGL 1.4 page 243 sur le GL_FOG_HINT il est écrit que le GL_Nicest fait un calcul par pixel et que le GL_FASTEST fait un rendu par vertex. Ca change pas mal le rendu pour les pros.
Non. Des instances séparées de libGL sont utilisées pour chaque appli OpenGL que tu lances. Source : je suis dev X.Org et mesa.
Peut être me suis-je mal exprimé sur celle là, parceque j'ai une autre réponse qui va dans le même sens plus haut. La question est : combien de surfaces de rendu OpenGL distinctes (i.e chacune avec son paramétrage et éventuellement sa ) je peux gérer en même temps sur une carte grand public. Et de façon générale combien de surfaces de rendus accélérées 3D je peux gérer simultanément, chacune avec ses propres composantes. Bien que la carte grand public n'est jamais été mon fort, des gros balèzes de Beyond3D répondaient assez souvent "une seule" à cette question.
Non c'est faux. Tu peux très bien utiliser LD_PRELOAD si tu veux un autre implémentation de GL (par exemple du mesa soft dans une certaine appli au lieu d'un driver DRI).
Source : t'as qu'à essayer LD_PRELOAD=/path/to/mesa/libGL.so ./monappli et tu auras du rendu soft. Tout ça sans "recharger ton X.Org"
J'ai essayé des trucs comme çà avec des drivers proprios et libres sur des cartes ATI et ca c'est jamais vraiment bien passé. Ca venait peut être d'ATI ou de mes configs. Là je ne peux rien affirmer il faut que je trouve le temps et que je reteste complètement.
Non, OpenGL est une spec, et une spec n'a pas de mécanismes pour faire des trucs en software. Source : va voir sur opengl.org et tu verras que c'est une spec.
Il y a des pages entières de la spec qui concernent le "software callback", comment il peut être géré par les implémenteurs et comment avoir une path software fallback est une bonne idée au cas ou on viendrait à manquer de ressources, comment gérer les buffers et les OUT OF BOUNDS quand on est amené à faire un software fallback. Comment doubler certaines infos en cas de possibilité de software fallback etc.
J'imagine que ca ne compte pas....
Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.
C'est exactement ce que je dis. Quake2 n'utilisait que du RGB, c'était même pas la peine d'essayer d'utiliser un autre espace de couleur si on voulait de l'acceleration sur les cartes de salon. On repassait en soft direct.
Non, GL_SMOOTH ne s'applique pas aux textures. Source : la doc OpenGL qui explique que GL_SMOOTH s'applique a l'interpolation des couleurs sur les facettes et non pas l'interpolation des textures.
GL_SMOOTH quand il est utilisé dans le cadre de glShadeModel déclenche un rendu de type Gouraud shading pour peu que l'on ait les bon vertex aux bons endroits. C'est très pratique même sur les textures quand ca se mélange à des infos d'éclairage. Par exemple http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=07 qui est très basique et old school, mais qui met bien en exergue entre GL_SMOOTH et GL_FLAT même sur un objet texturé.
Et bien à l'époque Quake2 Avec les pilotes OpenGL de merde qu'on se trimballait à la maison, GL_FLAT + chargement d'une texture => retour en mode soft.
Non, tu n'as pas à valider la texture
Ah bon ? La fonction glGetTexLevelParameteriv est morte ? On fait quoi on part du principe que la texture est forcément compressée comme il faut, qu'elle va tenir en mémoire et que le proxy va accepter son format sans broncher ?
tu n'as pas à explicitement la décompresser (fait par la carte)
Tu sais quoi tu n'as pas non plus explicitement à venir chez l'utilisateur pour tracer tes triangles, c'est aussi fait par la carte. Mais il faut expliquer à la carte en question que c'est une texture compressée, il faut la mettre dans un buffer avec les bons paramètres et si il y a proxy il faut être gentil avec lui aussi. C'est un peu ce que j'apelle "décompresser" la texture.
ni à la transformer en texels 2D (ça veut rien dire)
Je t'accorde l'horrible abus de langage. Mais bon à un moment ou un autre il va bien falloir recouvrir un ensemble de polygones avec une succession de textures, éventuellement shadés. Car c'est bien le shading qui va casser les piedstant au niveau vertex pour le polygone sous-jacent, qu'au niveau pixel pour la texture elle même.
Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0)
Oui, une fois que tu as sorti tes mipmaps, que tu as choisis ceux que tu voulais et que tu les a appliqués comme il faut. Ce qui prend une page.
Enfin bref, encore une fois, j'ai montré point par point que tu dis n'importe quoi et que tu dénigres OpenGL sans fondement.
J'ai peur qu'il ne te faille recommencer depuis le début.
OpenGL est tout a fait capable de supporter plusieurs applications en meme temps et il ne souffrira pas plus que Direct3D dans les meme conditions.
Je me suis mal exprimé, la fauter en revient plus aux cartes graphiques qu'à OpenGL lui même. Une fois de plus j'ai quitté le monde 3D sous la Geforce 8000, la Radeon 9600. Je ne sais pas si le monde a changé depuis, mais à l'époque ouvrir deux contextes de rendus 3D accélérés sous ces cartes était très complexe pour ne pas dire impossible. Je ne sais pas ce qu'il en est aujourd'hui. Bien sur OpenGL peut gérer des centaines de rendu simultanément si la carte et ses pilotes le permettent.
Tu peux tres bien utiliser un driver particulier pour chacune de tes applications (meme avec le compositing active) et ceux sans relancer le serveur X, il existe plusieurs variable d'environnement pour y arriver (je le fais courament pour tester une modif sans casser ma config qui marche et sans relancer X).
Alors là je veux bien que tu m'expliques comment. En ce moment même je suis en train de me dire que Linux n'est plus fait pour moi (après 10 ans sous l'OS sans discontinuer) justement pour des trucs comme çà.
J'ai cherché comment faire des switchs de lin OpenGL à chaud (application OpenGL en train de tourner) ou à froid sans jamais arriver à un autre résultat que le crash de Xorg ou le freeze de la machine (N.B : plusieurs machines, plusieurs cartes graphiques). Ce que tu dis m'interresse donc grandement.
Non c'est faux, ces hints sont optionnels, et en plus au moins 90% des drivers ne les implémentent pas. Et pour cause, le hardware video n'a plus de fonctionnalité pour réaliser ces hints (pour référence le dernier hardware nvidia à implementer ces hints c'est la TNT/TNT2, les générations suivantes ont l'équivalent de GL_NICEST et c'est tout).
Trois petites choses :
Quand la TNT est est sortie, on ne parlait pas vraiment d'OpenGL hardware sur Windows pour Nvidia. Le pilote de base OpenGL sous windows 95 était pur soft.
Et kes drivers qui existait à l'époque s'installait à coup de copie de DLL et d'édition de base de registre.
Les hints sont essentiels dans la plupart des applis professionnelles. Car le rendu diffère vraiment d'un cas à l'autre.
Les denière générations de Cartes 3D sur lesquelles j'ai bossé chez NVidia (à savoir les 8000) font un peu ce qu'elles veulent et ignorent les hints. Certains rendus sont fait en GL_Nicest, les autres sont fait en ce qu'on peut. Et tant pis si il y a des Z aliasing ou des déformations à la con parceque le pilote fait des arrondis un peu cavalier. Certes il s'agit de cartes de desktop, donc ce n'est pas grave techniquement. Mais d'un autre coté ca oblige à tester son rendu carte par carte pour savoir sil il est propre ou pas.
Encore une fois c'est faux. Avoir plusieurs applications OpenGL avec l'acceleration, on y arrive sous X.Org (avec compositing et tout le bordem) et aucune des instances ne tourne en soft. Tu imagines sinon ? Tu tournes compiz (== 1 appli OpenGL) et après tu n'as plus d'accélération 3D
L'architecture Xorg fait que toutes les applis utilisent la même instance avec le composting. L'avantage est que plusieurs applis peuvent faire de l'OpenGL en même temps, l'inconvennient est que toutes les applis sont impactées si il y a un problème. Par exemple si tu charges une vidéo en mode texture dans une appli, tout le monde morfle.
Autre inconvennient tu ne peux pas charger des pilotes spécifiques à ton appli. C'est le même tarif pour tout le monde. Si tu veux faire de l'accéleré Hardware pour un pré-rendu et ensuite du Mesa pour un rendu correct techniquement, tu es bon pour recharger ton Xorg entre les deux.
Si tu parles de drivers miniport, ce n'est pas fait pour quake2. En fait miniport est une couche simplifiée entre OpenGL et le driver windows qui permet de faire un driver OpenGL plus facilement, et laisser miniport implémenter les trucs un peu tordus de manière générique en logiciel. Si tu regardes les cartes de l'époque, elles ne pouvaient pas accélerer tout OpenGL, donc elles auraient de toute façon du implémenter ces fameux fallback en logiciel. Pour résumer, les trucs que miniport faisait en logiciel, tu ne les avais pas dans direct3D.
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware. Les mini ports vont plus loin, ils permettent de faire en rendu hardware certaines fonctions OpenGL sous certaines conditions, mais de retomber en rendu soft si la même fonction est appelée dans d'autres conditions. Historiquement les certaines fonctions en question étaient celles utilisées par Quake 2 et les certaines conditions celles de Quake 2. Déjà toutes les fonctions qui n'utilisaient pas GL_RGB mais un autre espace de couleur (au hasard YUV pour plaquer des vidéo) repassaient en soft immédiatement. Alors que les cartes de l'époque (TNT2, ATI Xpert, Millenium G100, Millenium G200 etc.) savaient convertir le YUV en RGB en Hard.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Ah voilà un exemple intéressant, celui du transform and lightning. Les applications qui étaient écrites en OpenGL 1.0 (ou plus) ont pu exploiter le transform and lighting sans avoir besoin de recompilation/modification d'aucun genre.
Oui OpenGL supportait le T&L depuis longtemps. Mais pas les pilotes de carte graphique (ni les cartes graphiques d'ailleurs). OpenGL gère tout le pipeline de rendu, donc forcément le T&L aussi. Mais il faudra attendre que la Geforce sorte et qu'elle décide de faire un pilote OpenGL 1.3 pour que l'on ait un semblant de T&L OpenGL sous windows. Sous Linux/Unix/autre il faudra attendre 2002, soit la FireGL d'ATI pour avoir un semblant de support T&L sur Radeon 9000. Alors que les shaders sont déjà en train de remplacer le système T&L.
Concrètement, tu voudrais quels changements dans OpenGL
Comme tout le monde ou presque :
- Une vraie rupture de compatibilité, ou à défaut un hint qui permette de dire si l'on veut utiliser les fonctions OpenGL en mode 3.0 ou en mode deprecated. celà permettrait de faire un grand ménage dans tout un tas de fonctions qui ne sont plus utilisées par personne aujourd'hui. C'était la principale promesse d'OpenGL 3.0.
Un exemple tout con : plaquer une texture S3TC/DXTC sur un cube demande une page complète de code, pour charger la texture, la valider, la binder, la décompresser, la transformer en texels 2D, l'appliquer, corriger la perspective, la lisser et enfin l'afficher. Et là je parle même pas de charger plusieurs résolutions de textures pour faire du filtering aniso. En DirectX 8+ ca ne prend que quelques lignes.
- Les shaders OpenGL sont surpuissant. On peu les rentrer à n'importe quel niveau du traitement de rendu pour les repasser dans la moulinette, seulement c'est horriblement complexe. En DirectX il y a pleins de méthode pour réintégrer facilement des shaders au étapes de tesselations ou d'illumanitions pour les vertex, et aux étapes de mapping et d'illumination pour les pixels. Certes c'est plus limité, mais d'un autre coté c'est aussi nettement plus simple à mettre en place. Les ponts Direct3D <-> Shaders tout pret sont plus nombreux en DirectX.
- Les hints OpenGL sont gentils, mais il y en a un peu trop, un peu trop souvent. En Direct3D on décide une fois pour toute ce que l'on veut appliquer comme méthode ou pas. Et normalement c'est bon. En OpenGL il est théoriquement possible de faire de l'aniso pointu sur une texture tout en faisant un plaquage à l'arrache sur une autre texture du même objet. Il serait bon que l'on puisse définir une table des sélections par défaut et que l'on ait pas à repasser 122 000 arguments à chaque fonction de rendu ou de chargement de modèle.
Encore une fois j'ai l'impression que OpenGL a surtout un problème de communication (au point que même les geeks de linuxfr le renient) en face de la machine de communication de Microsoft.
Le DirectX qui a explosé et qui a placé Microsoft en tête des API de jeux vidéos c'est le 5.0. A l'époque tous les gamers avaient des cartes 3DFX, Le dieu du Jeu Vidéo (Carmack) bossait exclusivement en OpenGL et la bibliothèque de rendu finale (msvcrt.dll) était bugguée jusqu'à la moelle. En plus en 1999/2000 toutes les cartes gamers possédaient un OpenGL 1.2 complet et un OpenGL 1.3 bien avancé.
Malgré tout ces défauts DirectX a gagné haut la main, face à Glide et face à OpenGL. C'est pas juste un problème de com, c'est un problème de COM (quel humour). Utiliser OpenGL de façon propre, efficace et sans casser windows était un casse tête sans nom. DirectX plus limité était aussi plus simple et raccourcissait grandement les temps de dev. Par la suite OpenGL a loupé coche sur coche (filtering avancé, compression de texture, antialiasing, shaders tout celà existe sous OpenGL mais est assez complexe a mettre en place) alors que DirectX s'étoffait.
Aujourd'hui OpenGL est toujours aussi complexe à mettre en place, alors que DirectX a su évolué et combler ses lacunes tout en restant assez simple. Bien entendu aucun jeu vidéo professionnel du devant de la scène (les jeux microtruc c'est moins sur) n'utilise les fonctions DirectX brut de décoffrage. Mais DirectX permet d'avoir très vite un truc qui marche complètement. Quand on sait que le temps de dev d'un jeu est de deux à trois ans et qu'il y a un changement majeur de méthodes de programmation tous les 18 mois, c'est pratique.
Il s'agit de la plus belle opération de FUD depuis un bout de temps.
OpenGL a existé des années avant Direct3D, le pendant d'OpenGL sous DirectX, mais il n'a jamais décolé dans l'industrie du jeu video. Les raisons sont multiples :
Tout d'abord OpenGL n'est pas un système qui permet facilement le rendu 3D temps réel, ca n'est pas sa vocation. OpenGL est une bibliothèque graphique de gestion de rendu. La première chose que l'on fait quand on écrit un programme OpenGL est de définir quelle sera la qualité du rendu, en d'autres termes quelle précision de calcul on veut. Cette option va de GL_Default jusqu'à GL_Nicest.
OpenGL es un système ouvert dans tous les sens du terme. Notamment il est très facile d'y ajouter carte par carte des extensions spécifiques. Or très peu de cartes graphiques grand public, et même très peu de consoles de jeux sont exploitable dans le cadre d'un jeu video moderne sans faire appel massivement à ces fonctions étendues. Lesquelles sont évidement non portables, ou tout du mois spécifiques à certaines familles de puces graphiques.
OpenGL gère l'ensemble du pipeline de rendu graphique de la carte vidéo. Ce qui est très bien pour un rendu de précision, mais qui pose un véritable problème dans le cadre d'un PC de bureau. Si vous lancez une application OpenGL, elle va mettre la main sur tout un pipeline de rendu. Donc si vous lancez une seconde application OpenGL, soit vous avez une carte graphique professionnelle avec Autant de pipeline que nécessaire, soit la seconde application ne sera pas accélérée 3D et passera en mode pur soft. Sous Direct3D il est tout à fait possible d'accélerer simultanément plusieurs rendus, car c'est le système et non l'appli qui fait le dispatch des traitements. C'est pour celà que sous Vista et 7 tant que l'on a pas désactivé Aero, les performances OpenGL sont assez limitée. Bon Microsoft a sorti un patch qui fait que si l'appli OpenGL passe en plein écran aero va faire dodo et on a des perfs correctes, mais en fenétré c'est une catastrophe.
OpenGL ne s'occupe que du graphisme, et seulement dans la qualité voulue. Si par hasard vous vouliez vouer du son ou ajouter des éléments de calcul dans votre appli, à vous de vous démerder pour synchroniser tout çà. Dans DirectX ce sont les modules DirectInput et DirectSound qui se démerde à ne pas saturer trop en évènement le processeur pendant les phases de forte charge. Bon on fini souvent par être obligé de tricher un peu. Mais on a pas à tout faire à la main tout le temps
OpenGL comme DirectX ont subis des changements de paradigme important. Tant au niveau interne que vis à vis des langages et des méthodes de programmation. DirectX 5.0; Dirext 7.0 et DirectX 9.0 font appel à des concepts de programmation graphique suffisament différent pour que l'expérience de l'un ne soit pas utile aux autres. Néamoins c'est DirectX qui reste en tête. Tout simplement parcequ'il est nettement plus adapté au jeu vidéo...
Pour finir OpenGL a de nombreuses applications en dehors du jeu video, il ne viendrait à l'idée de personne de faire une imagerie médicale pour irradiation avec Direct3D (encore que...) Mais cette puissance à un prix, les objets OpenGL sont beaucoup plus pointus et beaucoup moins flexibles que leurs contreparties Direct3D. De fait le temps de programmation est rallongé d'autant.
Quand Microsoft a présenté la suite DirectDraw (Qui allait devenir DirectX 1.0) aux devs de jeux, il se sont foutus de leur gueule. Un moteur 3D ou 2D à l'époque ca se codait à la main et ca se lancait en DOS.
Au départ ni DirectX ni OpenGL n'ont décollé. En fait l'élément perturbateur a été 3DFX avec le Glide. API propriétaire tournée exclusivement vers le jeu. C'est là que ca a fait tilt. Microsoft a sorti un set d'instruction d'accellerations 3D sous la forme de DirectX 3 en faisant très attention à s'arranger pour que la plupart des traitements soient faciles à réaliser soit en MMX, soit en utilisant les fonctions de rendus vidéo déjà présente dans certaines cartes haut de gamme, et qui devaient se généraliser avec l'arrivée des DVD. C'est alors que ATI s'est engouffré dans la brêche avec les cartes xpert@work et xpert@play rejoint très peu après par Matrox qui ont fait des cartes de décompression MPEG-2 avec les suppléments nécessaire pour faire tourner en hard DirectX 3.0 et le draft DirectX 4. Sauf que le Glide2 poussait à la porte, DirectX 4 n'a pas duré très longtemps et directX 5 a été créé dans la foulée pour faire front face au Glide 2.
Mais au moment de la conception DirectX 5 un certain Carmack, qui pour ainsi dire avait rendu possible la 3D temps réel sur PC de salon, décidait de sortir Quake2 en OpenGL. Carmak étant le plus gros vendeur de jeux videos du moment, on a eu droit aussi bien coté glide avec des wrappers que coté ATI et Matrox avec des versions réduites à des pilotes OpenGL un peu costaud sur nos machines.
Seulement il s'agissait de Mini-Drivers, c'est à dire de pilote conçus pour faire tourner Quake 2 et rien d'autre. Pas un vrai support OpenGL.
Après quand Half Life a utilisé une version modifiée du quake engine, ca a fonctionné car les fonctions appelées étaient les mêmes. Cependant ca a transmis un vrai message aux fabriquants de cartes graphiques : il fallait faire de vrais pilotes OpenGL complet et tout. C'est le moment ou toutes les cartes graphique sun peu péchue supportaient l'ensemble de l'API OpenGL 1.2. C'est aussi à ce moment que le groupe Lokhi a fait des merveilles en termes de portages de jeux sous Linux. Leur version OpenGL du moteur d'Unreal poussait le vice jusqu'à battre le moteur Glide2 fait par les devs originaux. OpenGL avait le vent en poupe.
Et puis OpenGL 1.3 est sorti. Et là les fabriquants de cartes graphique sont éclatés de rire et se sont tournés vers Directx7 qui était beaucoup plus raisonnable en terme de puissance demandé pour un résultat correct. C'est un petit nouveau : NVidia qui est venu mettre la pagaille dans tout çà, en annonçant coup sur coup le support du transform and Lightning sur Directx7 et le support complet d'openGL 1.3 (Bon complet du tronc principal de l'ARB, toutes les extensions officielles n'étant pas supportée). La geforce va se vendre comme des petits pains. Et les autres constructeurs corrigent leur copie pour utiliser à fond OpenGL 1.3.
Mais aucun jeu majeur utilisant OpenGL 1.3 ne sortira. Les seuls jeux qui sortent et qui utilisent OpenGL sont OpengL 1.2, basé soit sur le moteur de quake 2 soit sur celui d'Half Life. Des jeux qui auraient pu être pris en charge par des mini drivers tout aussi bien (et en fait la guerre des benchs commencant, les différents fabriquants n'hésitent pas à créer des pilotes spécifiques pour tel et tel jeu en OpenGL de façon à bosster artificiellement les perfs, en rennomant l'executable quake2.exe en quack2.exe le site anandtech observe une perte de framerate de 30% sur Geforce). Le thresh Firing Squad s'en mèle pour donner un point de vue Vitesse d'affichage vs Beauté de l'affichage qui n'est pas en faveur de la beauté du tout. OpenGL 1.4 sort dans l'indifférence générale coté fabriquant. Seul les systèmes de compression de texture et l'illumination dynamique seront implémentés.
OpenGL 2.0 est une catastrophe en regard de l'industrie du jeu, seul Carmack s'en sert un peu, mais son temps est passé et Doom 3 et Quake 3 se vendent mal (pour du Carmack). Aujourd'hui encore très peu de cartes sont capables de gérer l'ensemble du tronc ARB d'OpenGL 2.0 en pur hardware.
OpenGL 3.0 qui devait corriger le tir et devenir un direct3D Killer prend un an de retard sans pratiquement aucune communication du groupe Khronos. Finalement loin de la refonte attendue qui aurait permis de rendre OpenGL utile dans uen optique de jeu, c'est une suite logique d'OpenGL 2.0 qui sort avec ses archaisme et ses shaders séparés. La puissance de calcul nécessaire pour faire de l'OpenGL 3.x en hardware, et la complexité de programmation clouent définitvement OpenGL au sol. Son apotre Carmack prend sa retraite et pouf.
Pour l'instant pas grand chose coté OpenGL, et à moins qu'OpenGL 4.0 ne franchisse le pas que 3.0 aurait du franchir, je en vois pas comment OpenGL peut espérer devenir concurentiel un jour.
our faire ça auparavant, il aurait fallu bidouiller je ne sais quoi, ne serait-ce que pour isoler le flux sonore d'une seule application ...
Il aurait fallu créer une carte son virtuelle sous alsa...
Sous oss c'est encore pire, il aurait fallu diriger la sortie son vers le null audio device et rediriger ce device vers un socket (ou la sortie standard)
En d'autres termes faire à la main ce que fait Pulse audio (l'auteur du journal utilise la méthode device null audio, mais la méthode carte virtuelle fonctionne aussi)
Il va falloir que tu ailles botter le cul à Linus Torvalds, parce que de ce que j'ai compris il n'en a rien à faire de la compatibilité par couche, et quand il a un soucis avec une interface, il adapte tous les pilotes à la nouvelles interface et abandonne l'ancienne.
Presque...
Quand Linus a un problème avec une interface, il la change. Ensuite les personnes en charge des pilotes de ceci ou celà essayent d'adapter. Avec plus ou moins de succès.
Pour les trucs vraiment compliqués, comme la gestions des périphériques IDE, des périphs SATA, des ports COM virtuels ou réel ca reste un beau bordel pendant des mois voire des années. Au bout d'un moment Alan COX prend le problème sous son aile et commence à faire le ménage.
Généralement il y a au moins une altercation entre Linus et Alan pendant ce ménage. A la suite de quoi Alan COX décide de prendre un temps de pause pour étudier le Gaellique.
De manière générale une ABI dure moins de deux mois, une API moins de six...
Malheureusement pour nous et pour Linux en général, Alan Cox en a rien à foutre du tout d'Alsa ou de V4L
Plus sérieusement, le problème de ta théorie est la maintenabilité : ce que tu décris est pure théorie, en pratique il est dur et épuisant de tester les régressions avec les anciennes interfaces, et sans personne pour se coltiner le travail, l'ancienne interface est abandonnée.
Ce qu'il décrit existe depuis des années sous BSD. Notamment FreeBSD. J'ai un module de carte réseau Realtek qui a été compilé pour une 4 et qui tourne très bien en 6.2. Près de 5 ans d'ABI sur un module.
Et pourtant les devs FreeBSD sont nettement moins nombreux que les devs Linux.
# Mettons les choses au clair
Posté par Jerome Herman . En réponse au journal L'homme pense et Dieux se marre (scenar Boson de Higgs == fin du monde). Évalué à 9.
Tu parles d'une énergie qui se trouve derrière un horizon quantique (puisque là on ne la voit pas) et qui traverserait cet horizon suite à une synchronisation avec un boson isolé.
Alors juste pour donner un ordre de grandeur (rapide) si on voulait transformer notre bon système solaire en trou noir, il faudrait le compresser à une taille de 20cm de diamètre. Et encore ca serait un micro trou noir d'une durée de vie infinitésimale.
Il faut donc que l'énergie remontée par la vibration soit supérieure à l'ensemble de l'énergie contenue dans notre système solaire qu'elle soit remontée en quelques nanosecondes et qu'elle ne puisse pas se diffuser dans plus de quelques millimètres dans ce laps de temps.
Moi ca va , je dors tranquille.
[^] # Re: M
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 2.
Il y a deux logiques :
- Le plugin
- L'embeded
Dans le cas du plugin le navigateur ouvre une interface à lui pour un logiciel créé par un autre dev. C'est donc à l'autre dev de respecter les licences. Si demain je fais un plugin Active X qui enfreint des brevets, Microsoft n'a aucun soucis à se faire. Même si techniquement au niveau du runtime il n'y a qu'un seul éxecutable, je suis el seul fautif pour ne pas avoir respecter les licences.
Dans le cas de l'embed, le navigateur ouvre une interface à une Bibliothèque extérieure, puis apelle des composants de cette bibliothèque en leur donnant les droits sur cette interface. Dans ce cas les devs du navigateur doivent valider la licence de la bibliothèque et des composants qu'ils apellent. Mais ce qui se passe après que les composants aient été appelés n'aient plus de leur ressort. Il y a plusieurs exécutables distincts.
Et heureusement que ca se passe comme çà (Note : sinon je dépose un brevet, je fait moult plugins et je commence à attaquer tout le monde, ca peut être un business plan valable.)
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 3.
Alors le container MPEG4 part 14 est strictement identique au container mov étendu de 2003. Le truc c'est que la norme MPEG4 est sortie en 1999.
Pas un seul instant. La norme MPEG-4 est bien sortie en 1999. Le container de préférence au format MP4, M4A ou M4V est sorti en 2003 dans le cadre de la part14.
Avant il n'était pas question de container officiel du tout dans la norme MPEG4, simplement de compatibilité avec les containers existant. Mais tout le reste était défini et fonctionnait depuis longtemps quand le container a été choisi.
xvid, real, divx, wmv et autres h264 étaient déjà dans la danse.
Et bien je t'invite bien cordialement a mettre a jour les pages wikipedia en question qui disent explicitement le contraire, sources a l'appui, ainsi qu'a le signaler au service marketing d'apple qu'ils retirent leur blabla publicitaire mensonger. Je t'ai donne les liens plus haut, j'ai meme cite dans le commentaire.
Dans tous les exemples que tu cites, il n'ait question que de la part 14 quand il est question d'Apple. Il n'y avait PAS de containers officiel avant la part 14.
Et une fois de plus la part 15 s'empresse de redéfinir d'autres containers, le format .mov QT5 étant peu adapté au streaming.
J'ai beau relire encore et encore les pages et les citations, il n'est pas question de MPEG4 part 1.
Pour résumer la chronologie :
En 1998 le MPEG Group fini la norme MPEG4 part 1, Apple est moribond, Jobs regarde Next couler.
En 1999 la norme MPEG 4 est validée, Jobs fait des bulles en plastique pour Mac.
En 2000 Explosion du DivX, le format MPEG4 sur AVI hacké d'un codec MPEG 4 Microsoft.
En 2001 Apple sort un nouveau format Quick Time pour les futures versions. Le format est déposé. Le MPEG-Group s'inspire beaucoup de ce format pour leur travaux.Ils travaillent à améliorer le format avec Apple, puis y ajoutent des éléments spécifiques à MPEG
En 2002 Quick Time 6 sort, c'est le premier de la série des quick time qui supporte le MPEG4. H264 étant non supporté, Sorenson et H263 restent les formats les plus efficaces sous QT
En 2003 les formats MPEG sortent officiellement.
En 2005 Apple sort QuickTime 7 qui supporte enfin le H264. Il devient le premier lecteur full Mpeg4 part 10 grand public.
Je pense que ton problème vient du fait que tu ne comprend pas ce que représentent les part pour le MPEG Group.
La part14 ne défini QUE le container, tout le reste a déjà été traité avant.
Dès la part1 on peut faire du MPEG4. En fait on est jamais obligé de respecter TOUTES les parts. (Seule la 1 est obligatoire).
On peut donc continuer à faire du mpeg2, quantizer h263 dans de l'avi et appeler ca du MPEG4 sans que qui que ce soit puisse y trouver à redire.
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 3.
Part 14, c'est 2003.
Point.
Je n'ai JAMAIS dit le contraire.
La part 1 c'est 1999. ET Apple n'a pas contribuer à la part 1. C'est tout ce que je dis (et google encore moins)
Deja, t'es au courant que mov a ete cree avant 2003 quand meme?
C'est un format qui a 20 ans!!! J'ai aucun doute qu'apple l'a fait grandement evolue depuis, mais sortir un argument d'anteriorite face au mov, c'est fort de cafe quand meme...
T'es au courant le le .mov ne veut rien dire. Qu'il y a eu une floppée de container tous complètement différents et que c'est le container de 2003 qui a été retenu dans la part 14 ?
C'est meme pas des différences subtiles comme entre avi v1 et avi v2 qui agrandi juste la taille des pointeurs pour passer la limite des 2Go, c'est des formats de fichiers qui n'ont rien à voir.
La base de travail a été la specification publiée en 2001 sur les formats quicktime 5. Mais la finalisation pour quicktime n'a eu lieu qu'en 2002 (Quicktime 6) et le format de fichier n'a été validé qu'en 2003.
Bien que les différence soient faibles le format mov QT5 et QT6 diffèrent, notamment pour des raisons d'informations de synchronisation audio.
Je vais te repondre aussi "gni?" et reiterer.
Le mpeg vend des licences d'exploitation sur ses brevets, celui qui a une licence peut l'implementer. Une licence, c'est une licence, ca te donne le droit d'implementer l'algorithme couvert par le brevet. Que ca soit pour du mpeg, du theora ou ton truc fait maison. C'est le concept meme du brevet.
Cool. C'est juste con que la licence MPEG4 ne soit pas une licence sur l'ensemble des brevets mais une licence d'implémentation du MPEG4 et rien d'autre. Ca a été confirmé plusieurs fois au tribunal. En fait c'est même le but du MPEG Group : mettre tous les brevets en commun pour éviter que chacun ne dévelloppe son propre format dans son coin.
En plus dans le cas très précis du MPEG-4, il y a un brevet de Qualcom qui a été semi-invalidé en cour pour défaut de divulgation et qui n'est pas opposables aux licenciés MPEG-4 qui font des formats compatibles H264. Par contre il est opposable si le format n'est pas compatible.
Ensuite, je veux bien que tu m'expliques la difference entre avoir une licence sur les brevets et avoir une "licence pour faire du mpeg4".
Dans un cas tu as payé pour chaque brevet, éventuellement très cher, et tu fais ce que tu veux. dans l'autre cas tu paies une somme forfaitaire assez ridicule (N.B : Oui 1M$ pour une utilisation illimité en diffusion par exemple, c'est faible) mais tu ne peux utiliser les brevets QUE dans le cadre du MPEG-4. Donc tu te dois de respecter au moins toute la partie 1 du MPEG4.
Les autres membres, quand ils ont rejoint le group mpeg, ils se justement mit d'accord pour ne PAS attaquer les autres membres sur les brevets mit en commun.
Dans le strict cadre du MPEG-4 une fois de plus...
C'est un peu le concept du mpeg, c'est de mettre tout le monde ensemble, pour bosser ensemble, et pour eviter que ca chie dans la colle, on demande a tout le monde de signer un accord de non aggression.
Dans la mesure ou il y en a pas un qui décide de prendre tous els brevets des autres, d'y rajouter sa sauce perso qui améliore tel ou tel truc et de pondre un format incompatible tout seul dans son coin. C'est aussi çà (et même en fait principalement çà) le but du MPEG Group.
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 2.
Finbalisée en 1998 par le MPEG Group, déposée en 1999
http://www.iso.org/iso/iso_catalogue/catalogue_ics/catalogue(...)
Ensuite, empresses toi de modifier les pages wikipedia sur le mpeg4 part 14 et le mov, parce qu'elles precisent bien que mov a donne mpeg4 part 1
Je ne le vois pas (essayé les pages anglaises et francaises)
Je penses que tu confonds MPEG4 part 1 et MPEG4 file format version 1 (qui est inclus dans le part14)
le MPEG4 part 1 ne défini pas de format de fichiers mais défini juste la synchronisation audio/vidéo/image au sein des formats existant validés pour le MPEG4 (ASF, AVI, Bink, Real etc.)
Non, la question ne se pose effectivement pas, vu qu'on voit mal le mpeg group attaquer quelqu'un pour avoir implementé un brevet dont il lui a vendu une licence.
Gni ? Ils ont pas de licence sur le brevet les clients, ils ont une licence pour faire du MPEG4. Ca ne veut absolument pas dire qu'ils peuvent créé un autre format de fichier utilisant les brevets de la licence.
Donc d'un coté le H264+ MPEG4 ne coute rien de plus à Google ou à Apple (qui doivent déjà avoir des licences full), de l'autre, avec le Theora, ils prennent le risque de se prendre tous les autres membres du MPEG-Group sur la gueule voire d'être exclus du groupe.
Le choix est très vite fait...
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 2.
Alors le container MPEG4 part 14 est strictement identique au container mov étendu de 2003. Le truc c'est que la norme MPEG4 est sortie en 1999.
En fait la plus grosse contribution de Apple au codec (puisque que c'est un peu de çà dont on parle, les brevets sur les containers ca coure pas les rues) c'est le Apple lossless (qui à ma connaissance n'est pas très utilisé).
En plus le container part 14 étant fragile, surtout lors de transmission distante (l'entête est fixe et pointe les codecs en bout de fichier), il a été ajouté six mois après le part 15 qui autorise tout un tas d'autres containers.
Que ce soit pour la télé HD ou les Blu-Ray le part 14 n'est pas utilisé.
Après les formats les plus utilisés (AAC, MPEG-2, ITU-H264 AVC, ALS) Apple n'y est pas pour grand chose. Je doute fort que les autres membres du groupe considère qu'il a fortement contribué à autre chose qu'à populariser le H264 (avec Real)
Je rappelle que le concept du group mpeg, c'est: on se met tous ensemble, chacun met ses brevets dans le pot commun, on donne a TOUS les membres le droit d'implementer lesdits brevets, et en plus on se met d'accord pour pas se taper dessus avec les autres brevets qui sont pas dans le pot.
Le MPEG Group créé une norme que le MPEG LA vend. Ensuite le MPEG LA reverse l'argent aux membres du MPEG Group. Pour être utilisé à des fins de recherches. (En d'autres termes une bonne partie de l'argent sert à financer les labos)
Les membres du groupe payent leur licences comme tout le monde, sauf qu'ils récupèrent une partie de l'argent. Etre membre du MPEG-Group ne veut pas dire pouvoir faire ce que l'on veut avec ses licences.
Ceci étant pour 5M$ on a accès illimité à tout pour l'ensemble de sa companie. Quand on sait que pour être membre du MPEG Group il faut au minimum un petit labo, et qu'un petit labo avec de vraies têtes dedans ca coute minimum 200 ou 300 000$ par mois. On se dit que payer la licence full c'est pas déconnant pour les grosses boites.
Mais de toutes les façons sur le H264 Google ne fait pas partie des ayants droits :
http://www.mpegla.com/main/programs/AVC/Pages/Licensors.aspx
Et Apple s'aquitte scrupuleusement de sa licence auprès du MPEG-LA
http://www.mpegla.com/main/programs/AVC/Pages/Licensees.aspx
Donc la question en se pose même pas vraiment.
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 5.
Là je suis un peu emmerdé parce que la page est out depuis le 19 janvier.
Celle du CESLT aussi est dans les choux (mais là ca date)
Mais bon il reste le cache :
http://209.85.229.132/search?q=cache:iBy9V9gbZC8J:www.chiari(...)
Là tu as tout l'historique de la création du MPEG Group. Il se trouve que le créateur du MPEG Group Chiariglione a vidé sa page récemment (Et accessoirement a moins recemment créé une boite spécialisé dans le DRM).
Si tu as le courage d elire tout le texte tu verras que tout le monde s'est couché devant Chiariglione. Y compris AT&T qui avait pourtant les algos sur l'estimation de mouvement, l'interpolation, l'entrelacement etc.
"In fact," Haskell continued, "AT&T [had] contributed a lot of technology to MPEG-2, such as motion-compensated interpolation, interlaced motion compensation, [and so on]. Moreover, none of these technologies existed before MPEG. So MPEG is something more than selecting from off the shelf. The researchers involved actually invented new technology."
En fait au départ c'était plutôt collaboratif comme environnement. Le laboratoire originel était à Turin avec de gros liens vers Bell Telecom. Les bons codeurs étaient chez AT&T et les fabriquants de matériel étaient chez C-Cube et IBM. Tout le monde avait intérêt à ce que la télé HD fonctionne. Pour le standard HDTV il y a eu un mini clash entre AT&T et le groupe de Chiariglione. Mais la solution AT&T était très chère. Donc AT&T a décidé de contribuer au MPEG-Group pour profiter du génie de Chiariglione.
C-Cube s'est empressé de fabriquer les premières puces de compression et IBM s'est empressé de faire mieux.
C'est ainsi que le MPEG-2 est né et le que MPEG Group s'est trouvé sur-légitimé. La quantité de propriété intellectuelle transférée vers le MPEG Group est tout simplement colossale.
MPEG-4 a bien failli être boudé à cause de sa licence initiale. Mais en 2002 il a été largement reconnu par les acteurs du monde audio visuel
http://www.zdnet.fr/actualites/telecoms/0,39040748,2119318,0(...)
A ce moment là aucune contestation n'a eu lieu.
Depuis on est dans uen situation de lock assez violent. Le MPEG Group possède désormais les brevets sur les conversions d'espace de couleur, la recherche de mouvement, la prédiction de mouvement, l'interpolation bloc à bloc, l'entrelacement bloc à bloc, l'interpolation full frame, moultes techniques de recherches rapides d'ondelettes et j'en passe.
A ma connaissance il ne reste guère que la compression fractale et l'expansion spline( vectorisation de l'image par la technique des moindres carrés) qui ne soient pas bardés de brevets.
A noter que le codec Indeo, très très prometteur à l'époque, a été revendu par Intel à Lingos qui ne semble pas vraiment en faire usage... (15$ la licence, pas encore de versions compatible Vista ou seven en vue). Il est également basé sur les ondelettes, mais il est sorti avant que le travail sur le MPEG4 ne commence réellement.
Chiariglione a également activement participé à la création du layer3 (connu sous le non de MP3) et à la création de puces capables de le lire.
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 2.
Même IBM se couche sans moufter devant le MPEG-Group.
Mais quel que soit le resultat, un format non librement accessible n'est pas compatible et ne repond pas au cahier des charges d'un Internet ouvert.
Là je suis entièrement d'accord. Mais je garde mes réserves vis à vis de Theora (à Savoir qualité moyenne, méthode de compression/décompression trop similaire à ce qui a été breveté par le MPEG-Groupe, dialogue avec les différents acteurs du marché nul ou presque.)
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 2.
Madame Michu. Si tu as un doute, regarde la progression de IE 8.0 dans les stats.
Rien n'empeche de l'avoir aussi en h.264 tant qu'il y a a cote de ca un format lisible et accessible.
Sauf que si tous les navigateurs du monde ont accès à Theora mais pas à H264, ca fera un manque à gagner pour le MPEG Group. Donc ils feront un procès.
Doit-on donc rendre les armes et accepter un format non librement accessible pour cause de racket par un patent troll ?
Non je dis juste de ne pas compter sur Google/Nokia/Apple pour la promotion de Theora.
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 1.
Tu connais les membres du MPEG Group ? Tu penses que madame Michu en a quoi que ce soit à faire ? Si un standard gratuit viens prendre la place du MPEG-4 ils perdent une bonne partie de leur revenus. Ils attaqueront quoi qu'il arrive si Theora passe sur le devant de la scène.
Par ailleurs, Google doit avoir un bon nombre de brevets a sa disposition pour se defendre
Ni Google, ni Apple, ni Nokia n'ont quoi que ce soit pour se défendre contre le MPEG Group. Pour rappel le MPEG Group ne s'interresse qu'aux algorithmes vidéos et à leur implémentation hardware. Ils ne font pas de logiciel, ils ne font pas de matériel, ils ne font pas de réseaux. Il vendent une norme, un code de référence bateau et la possibilité d'utiliser des algos.
De plus quand les travaux sur le MPEG-4 ont commencé, on était en 1996. La norme est sortie en 1999. Apple était dans les choux (et puis bien), Google n'éxistait même pas et l'idée de mettre de la vidéo sur un téléphone portable était tout simplement risible.
Je ne pense pas que ces trois sociétés aient les moyens de faire pression sur le MPEG Group. Et je pense que leur timidité vis à vis de Theora s'explique assez facilement par le fait qu'ils le savent très bien.
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 2.
Et libtheora fait parti des system components de l'OIN, non ?
Cela ne risquerait-il donc pas de declencher une bonne grosse guerre des brevets ?
Peut-être, mais tant que Theora n'est pas un standard, le MPEG Group n'a aucun intéret à attaquer Xiph. Ils ne peuvent pas gagner beaucoup d'argent (du moins pas en regard de ce qu'ils ont l'habitude de gagner) et ils peuvent voir des brevets être invalidés au Tribunal.
Si Google, Apple et Nokia implémentent Théora, le MPEG Group a tout intéret à attaquer Xiph. Ils ne peuvent toujours pas gagner beaucoup d'argent avec Xiph, ils risquent toujours de se faire briser quelques brevets, mais par contre ils peuvent gagner vraiment pas mal d'argent si ils gagnent le procès contre Xiph et qu'ils se retournent alors contre Google, Apple et Nokia.
Et puis quand bien meme mpeg groupe attaque xiph pour violation de brevets, ceux-ci ne se retrouveraient-ils pas corriges dans les heures suivantes ?
Pas si évident que celà. Le MPEG Group possède des brevets sur des pans entiers de mathématiques appliqués à la compression des vidéos. Que ce soit au niveau de la prédiction de mouvement ou de l'utilisation des ondelettes ils ratissent plutôt large.
On pourra éventuellement trouver/écrire un autre codec libre, mais je doute qu'il puisse être compatible avec les vidéos Theora existante.
[^] # Re: Question idiote
Posté par Jerome Herman . En réponse au journal [HS] Roland Magdane, un plagiat comme un autre. Évalué à 6.
A part Elie Semoun, qui n'a pas hésité à dire qu'un de ses auteurs était Dubosc, je ne connais pas beaucoup de comiques qui livrent le nom de leurs auteurs. Il ne faut pas croire que dans un spectacle complet, tout a été écrit par le comique sur scène, c'est même assez rare.
Quant un chanteur fait une reprise, il indique généralement de qui est l'original; de même pour les dessins "blabla d'après plop de M. Machin".
Au niveau des interprètes ca arrive, même si ça n'est pas forcément le cas. Donc effectivement Bill Cosby étant l'interprète, Magdane aurait pu le mentionner. Par contre au niveau des auteurs, il y a un mépris généralisé à l'exception du monde du livre. Les auteurs de roman et les scénaristes de bande dessinées sont reconnus. Mais alors les paroliers, les dialoguistes, les scénaristes et autres auteurs de billets humoristiques sont royalement méprisés....
# Question idiote
Posté par Jerome Herman . En réponse au journal [HS] Roland Magdane, un plagiat comme un autre. Évalué à 10.
Soit lui directement, soit la personne qui a traduit le sketch ?
Surtout que Google a l'air de dire que Magdane considère Bill Cosby comme un de ses modèles.
[^] # Re: standard du web != codec
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 0.
A la seconde ou Google/Apple/Nokia décideront de faire du Theora, tu peut être sur que le MPEG Group, et d'autres feront une série de procès à Xiph pour violation de brevets. Après il est plus que probable qu'ils gagnent au moins un de ces procès et qu'ils se retournent alors contre Google/Apple/Nokia en les sommant de se mettre en règle (comprendre payer les licences au prix fort car la marge de négociation sera alors nulle).
Donc casser les pied à Google/Apple/Nokia ne changera pas grand chose. Ils ne prendront pas le risque financièrement.
La seule chose possible serait soit de militer contre les brevets logiciels jusqu'à les faire annuler (mais là je doute que Google/Apple/Nokia qui vivent en partie des royalties sur leurs brevets aident beaucoup), soit d'espérer qu'un jour le MPEG Group commence à intenter des procès contre des petits projets, ou des projets libres de façon à pouvoir tester au tribunal quels sont les brevets qui tiennent et ceux qui sont dénoncés.
Mais pour le deuxième cas, comme le MPEG Group fait très attention à ne pas attaquer les petits projets, c'est pas gagné non plus.
[^] # Re: M
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 2.
Perdu, ton produit n'utilise pas leur codec, il transmet juste les infos à DirectShow. En tant que dev du programme tu as juste à valider que ton produit a bien le droit d'utiliser DirectShow (ce que tu as déjà du faire avant que le codec machin n'arrive dans DirectShow)
En tant qu'utilisateur tu as juste à valider le fait que tu as le droit d'utiliser DirectShow et le produit. Il suffit (sic) de lire les licences.
La partie utilisation de DirectShow par le produit ne te concerne pas. Elle ne fait pas partie des obligations que tu as. Néamoins si un des ayant droit t'informe que ce produit utilise DirectShow illégalement, tu dois en cesser l'usage (mais il n'y a pas de pénalités)
Ceci étant si tu relis bien mon post, tu verras que je réagissais seulement à la partie
"anyone in the product chain has liability". C'est tout simplement absurde. Quel code judiciaire supporterait ça ?
En disant que tous les produits du monde sont soumis à ce type de contraintes dans la majorité des pays du monde. J'ai bien fait attention à utiliser des termes génériques pour que l'on comprenne bien que le sens était général.
[^] # Re: M
Posté par Jerome Herman . En réponse au journal Pourquoi H264 ne doit pas devenir le codec du web (par le MPEG). Évalué à 1.
Tous les codes judiciaires au monde ou presque.
C'est à la charge du fabriquant de vérifier qu'il a le droit de faire le produit, c'est à la charge du grossiste de valider qu'il a le droit de revendre, à qui et sous quelles conditions, idem pour le détaillant/distributeur et c'est à la charge du consommateur de vérifier que le produit qu'il achète ne relève ni du recel ni de la contrefaçon.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 2.
Quand je compare le prix d'une station SGI ou Wildcats au prix d'une licence Catia, je me dis que si Dassault System (puisque c'est l'exemple que tu cites) décide de faire un portage de OpenGL à DirectX et de Unix à Windows ca doit pas être seulement pour faire plaisir à un SI qui aimerait bien avoir que du x86 dans son infra....
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 2.
Le fait que je sois à la rue aujourd'hui, ce que j'admet volontier et répète souvent moi même n'a aucun impact sur ce qui c'est passé à l'époque alors que je n'était pas vraiment à la rue.
Hors ce qui s'est passé à l'époque (ie entre 1997 et 2005) est ce qui a fait qu'OpenGL est passé à la trappe au profit de DirectX dans le cadre strict du jeu video.
A noter que d'après certains commentaires OpenGL semble aussi passer à la trappe dans le cadre des applications pro...
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 2.
Tu me dis trois réponses plus bas que OpenGL est une spec pas une implementation.(Ce qui est parfaitement exact par ailleurs). Or l'interpretation ou non des HINTS peut être fait en hard directement en mettant le bon regsitre à la bonne valeur. En hard indirectement en activant ou en coupant certaines fonctions via d'autres registres ou encore en soft dans le pilote avec des bidouilles qui impliquent plus ou moins var pas du tout des interventions dans le hard.
Maintenant en ce qui concerne les TNT. Je me fous de savoir qu'il y ait un registre GL_HINT dans la carte et que les geforce ne possèdent pas de registre similaire. Quand la TNT est sortie on était au tout début de l'OpenGL , et le pilote de base windows était pur soft. J'ignore complètement si la TNT gérait correctement les HINTS ou pas.
Par contre je peu te dire que la Quadro sortie quelques années après, qui était une super Geforce, elle les gérait de façon tout à fait correcte. Même si il n'y a pas de registres dédiés dans le hard. Ca devait se régler à coup de paramétrage du T&L ou autres gruikeries soft+hard mais là j'ai pas le code des pilotes de l'époque.
Par contre je peux te dire que les HINTS ca comptait pas mal, et à ma connaissance ca compte toujours pas mal dans le monde professionnel. Dans le dernier bouquin papier que j'ai acheté, le Red Book 2004 OpenGL 1.4 page 243 sur le GL_FOG_HINT il est écrit que le GL_Nicest fait un calcul par pixel et que le GL_FASTEST fait un rendu par vertex. Ca change pas mal le rendu pour les pros.
Non. Des instances séparées de libGL sont utilisées pour chaque appli OpenGL que tu lances. Source : je suis dev X.Org et mesa.
Peut être me suis-je mal exprimé sur celle là, parceque j'ai une autre réponse qui va dans le même sens plus haut. La question est : combien de surfaces de rendu OpenGL distinctes (i.e chacune avec son paramétrage et éventuellement sa ) je peux gérer en même temps sur une carte grand public. Et de façon générale combien de surfaces de rendus accélérées 3D je peux gérer simultanément, chacune avec ses propres composantes. Bien que la carte grand public n'est jamais été mon fort, des gros balèzes de Beyond3D répondaient assez souvent "une seule" à cette question.
Non c'est faux. Tu peux très bien utiliser LD_PRELOAD si tu veux un autre implémentation de GL (par exemple du mesa soft dans une certaine appli au lieu d'un driver DRI).
Source : t'as qu'à essayer LD_PRELOAD=/path/to/mesa/libGL.so ./monappli et tu auras du rendu soft. Tout ça sans "recharger ton X.Org"
J'ai essayé des trucs comme çà avec des drivers proprios et libres sur des cartes ATI et ca c'est jamais vraiment bien passé. Ca venait peut être d'ATI ou de mes configs. Là je ne peux rien affirmer il faut que je trouve le temps et que je reteste complètement.
Non, OpenGL est une spec, et une spec n'a pas de mécanismes pour faire des trucs en software. Source : va voir sur opengl.org et tu verras que c'est une spec.
Il y a des pages entières de la spec qui concernent le "software callback", comment il peut être géré par les implémenteurs et comment avoir une path software fallback est une bonne idée au cas ou on viendrait à manquer de ressources, comment gérer les buffers et les OUT OF BOUNDS quand on est amené à faire un software fallback. Comment doubler certaines infos en cas de possibilité de software fallback etc.
J'imagine que ca ne compte pas....
Non, Quake 1/2 n'a jamais utilisé aucun truc en espace de couleur YUV. Source : lis le code source de quake 1/2. C'est tout du RGB.
C'est exactement ce que je dis. Quake2 n'utilisait que du RGB, c'était même pas la peine d'essayer d'utiliser un autre espace de couleur si on voulait de l'acceleration sur les cartes de salon. On repassait en soft direct.
Non, GL_SMOOTH ne s'applique pas aux textures. Source : la doc OpenGL qui explique que GL_SMOOTH s'applique a l'interpolation des couleurs sur les facettes et non pas l'interpolation des textures.
GL_SMOOTH quand il est utilisé dans le cadre de glShadeModel déclenche un rendu de type Gouraud shading pour peu que l'on ait les bon vertex aux bons endroits. C'est très pratique même sur les textures quand ca se mélange à des infos d'éclairage. Par exemple http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=07 qui est très basique et old school, mais qui met bien en exergue entre GL_SMOOTH et GL_FLAT même sur un objet texturé.
Et bien à l'époque Quake2 Avec les pilotes OpenGL de merde qu'on se trimballait à la maison, GL_FLAT + chargement d'une texture => retour en mode soft.
Non, tu n'as pas à valider la texture
Ah bon ? La fonction glGetTexLevelParameteriv est morte ? On fait quoi on part du principe que la texture est forcément compressée comme il faut, qu'elle va tenir en mémoire et que le proxy va accepter son format sans broncher ?
tu n'as pas à explicitement la décompresser (fait par la carte)
Tu sais quoi tu n'as pas non plus explicitement à venir chez l'utilisateur pour tracer tes triangles, c'est aussi fait par la carte. Mais il faut expliquer à la carte en question que c'est une texture compressée, il faut la mettre dans un buffer avec les bons paramètres et si il y a proxy il faut être gentil avec lui aussi. C'est un peu ce que j'apelle "décompresser" la texture.
ni à la transformer en texels 2D (ça veut rien dire)
Je t'accorde l'horrible abus de langage. Mais bon à un moment ou un autre il va bien falloir recouvrir un ensemble de polygones avec une succession de textures, éventuellement shadés. Car c'est bien le shading qui va casser les piedstant au niveau vertex pour le polygone sous-jacent, qu'au niveau pixel pour la texture elle même.
Oh si parlons-en. En OpenGL l'anisotropique s'active en 1 ligne : glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAX_ANISOTROPY_EXT, 8.0)
Oui, une fois que tu as sorti tes mipmaps, que tu as choisis ceux que tu voulais et que tu les a appliqués comme il faut. Ce qui prend une page.
Enfin bref, encore une fois, j'ai montré point par point que tu dis n'importe quoi et que tu dénigres OpenGL sans fondement.
J'ai peur qu'il ne te faille recommencer depuis le début.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 2.
Je me suis mal exprimé, la fauter en revient plus aux cartes graphiques qu'à OpenGL lui même. Une fois de plus j'ai quitté le monde 3D sous la Geforce 8000, la Radeon 9600. Je ne sais pas si le monde a changé depuis, mais à l'époque ouvrir deux contextes de rendus 3D accélérés sous ces cartes était très complexe pour ne pas dire impossible. Je ne sais pas ce qu'il en est aujourd'hui. Bien sur OpenGL peut gérer des centaines de rendu simultanément si la carte et ses pilotes le permettent.
Tu peux tres bien utiliser un driver particulier pour chacune de tes applications (meme avec le compositing active) et ceux sans relancer le serveur X, il existe plusieurs variable d'environnement pour y arriver (je le fais courament pour tester une modif sans casser ma config qui marche et sans relancer X).
Alors là je veux bien que tu m'expliques comment. En ce moment même je suis en train de me dire que Linux n'est plus fait pour moi (après 10 ans sous l'OS sans discontinuer) justement pour des trucs comme çà.
J'ai cherché comment faire des switchs de lin OpenGL à chaud (application OpenGL en train de tourner) ou à froid sans jamais arriver à un autre résultat que le crash de Xorg ou le freeze de la machine (N.B : plusieurs machines, plusieurs cartes graphiques). Ce que tu dis m'interresse donc grandement.
[^] # Re: C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 2.
Trois petites choses :
Quand la TNT est est sortie, on ne parlait pas vraiment d'OpenGL hardware sur Windows pour Nvidia. Le pilote de base OpenGL sous windows 95 était pur soft.
Et kes drivers qui existait à l'époque s'installait à coup de copie de DLL et d'édition de base de registre.
Les hints sont essentiels dans la plupart des applis professionnelles. Car le rendu diffère vraiment d'un cas à l'autre.
Les denière générations de Cartes 3D sur lesquelles j'ai bossé chez NVidia (à savoir les 8000) font un peu ce qu'elles veulent et ignorent les hints. Certains rendus sont fait en GL_Nicest, les autres sont fait en ce qu'on peut. Et tant pis si il y a des Z aliasing ou des déformations à la con parceque le pilote fait des arrondis un peu cavalier. Certes il s'agit de cartes de desktop, donc ce n'est pas grave techniquement. Mais d'un autre coté ca oblige à tester son rendu carte par carte pour savoir sil il est propre ou pas.
Encore une fois c'est faux. Avoir plusieurs applications OpenGL avec l'acceleration, on y arrive sous X.Org (avec compositing et tout le bordem) et aucune des instances ne tourne en soft. Tu imagines sinon ? Tu tournes compiz (== 1 appli OpenGL) et après tu n'as plus d'accélération 3D
L'architecture Xorg fait que toutes les applis utilisent la même instance avec le composting. L'avantage est que plusieurs applis peuvent faire de l'OpenGL en même temps, l'inconvennient est que toutes les applis sont impactées si il y a un problème. Par exemple si tu charges une vidéo en mode texture dans une appli, tout le monde morfle.
Autre inconvennient tu ne peux pas charger des pilotes spécifiques à ton appli. C'est le même tarif pour tout le monde. Si tu veux faire de l'accéleré Hardware pour un pré-rendu et ensuite du Mesa pour un rendu correct techniquement, tu es bon pour recharger ton Xorg entre les deux.
Si tu parles de drivers miniport, ce n'est pas fait pour quake2. En fait miniport est une couche simplifiée entre OpenGL et le driver windows qui permet de faire un driver OpenGL plus facilement, et laisser miniport implémenter les trucs un peu tordus de manière générique en logiciel. Si tu regardes les cartes de l'époque, elles ne pouvaient pas accélerer tout OpenGL, donc elles auraient de toute façon du implémenter ces fameux fallback en logiciel. Pour résumer, les trucs que miniport faisait en logiciel, tu ne les avais pas dans direct3D.
OpenGL possède de base des mécanismes pour faire en software ce qu'il ne sait pas faire en Hardware. Les mini ports vont plus loin, ils permettent de faire en rendu hardware certaines fonctions OpenGL sous certaines conditions, mais de retomber en rendu soft si la même fonction est appelée dans d'autres conditions. Historiquement les certaines fonctions en question étaient celles utilisées par Quake 2 et les certaines conditions celles de Quake 2. Déjà toutes les fonctions qui n'utilisaient pas GL_RGB mais un autre espace de couleur (au hasard YUV pour plaquer des vidéo) repassaient en soft immédiatement. Alors que les cartes de l'époque (TNT2, ATI Xpert, Millenium G100, Millenium G200 etc.) savaient convertir le YUV en RGB en Hard.
Idem si on charge les textures avec autre chose que du GL_SMOOTH.
Ah voilà un exemple intéressant, celui du transform and lightning. Les applications qui étaient écrites en OpenGL 1.0 (ou plus) ont pu exploiter le transform and lighting sans avoir besoin de recompilation/modification d'aucun genre.
Oui OpenGL supportait le T&L depuis longtemps. Mais pas les pilotes de carte graphique (ni les cartes graphiques d'ailleurs). OpenGL gère tout le pipeline de rendu, donc forcément le T&L aussi. Mais il faudra attendre que la Geforce sorte et qu'elle décide de faire un pilote OpenGL 1.3 pour que l'on ait un semblant de T&L OpenGL sous windows. Sous Linux/Unix/autre il faudra attendre 2002, soit la FireGL d'ATI pour avoir un semblant de support T&L sur Radeon 9000. Alors que les shaders sont déjà en train de remplacer le système T&L.
Concrètement, tu voudrais quels changements dans OpenGL
Comme tout le monde ou presque :
- Une vraie rupture de compatibilité, ou à défaut un hint qui permette de dire si l'on veut utiliser les fonctions OpenGL en mode 3.0 ou en mode deprecated. celà permettrait de faire un grand ménage dans tout un tas de fonctions qui ne sont plus utilisées par personne aujourd'hui. C'était la principale promesse d'OpenGL 3.0.
Un exemple tout con : plaquer une texture S3TC/DXTC sur un cube demande une page complète de code, pour charger la texture, la valider, la binder, la décompresser, la transformer en texels 2D, l'appliquer, corriger la perspective, la lisser et enfin l'afficher. Et là je parle même pas de charger plusieurs résolutions de textures pour faire du filtering aniso. En DirectX 8+ ca ne prend que quelques lignes.
- Les shaders OpenGL sont surpuissant. On peu les rentrer à n'importe quel niveau du traitement de rendu pour les repasser dans la moulinette, seulement c'est horriblement complexe. En DirectX il y a pleins de méthode pour réintégrer facilement des shaders au étapes de tesselations ou d'illumanitions pour les vertex, et aux étapes de mapping et d'illumination pour les pixels. Certes c'est plus limité, mais d'un autre coté c'est aussi nettement plus simple à mettre en place. Les ponts Direct3D <-> Shaders tout pret sont plus nombreux en DirectX.
- Les hints OpenGL sont gentils, mais il y en a un peu trop, un peu trop souvent. En Direct3D on décide une fois pour toute ce que l'on veut appliquer comme méthode ou pas. Et normalement c'est bon. En OpenGL il est théoriquement possible de faire de l'aniso pointu sur une texture tout en faisant un plaquage à l'arrache sur une autre texture du même objet. Il serait bon que l'on puisse définir une table des sélections par défaut et que l'on ait pas à repasser 122 000 arguments à chaque fonction de rendu ou de chargement de modèle.
Encore une fois j'ai l'impression que OpenGL a surtout un problème de communication (au point que même les geeks de linuxfr le renient) en face de la machine de communication de Microsoft.
Le DirectX qui a explosé et qui a placé Microsoft en tête des API de jeux vidéos c'est le 5.0. A l'époque tous les gamers avaient des cartes 3DFX, Le dieu du Jeu Vidéo (Carmack) bossait exclusivement en OpenGL et la bibliothèque de rendu finale (msvcrt.dll) était bugguée jusqu'à la moelle. En plus en 1999/2000 toutes les cartes gamers possédaient un OpenGL 1.2 complet et un OpenGL 1.3 bien avancé.
Malgré tout ces défauts DirectX a gagné haut la main, face à Glide et face à OpenGL. C'est pas juste un problème de com, c'est un problème de COM (quel humour). Utiliser OpenGL de façon propre, efficace et sans casser windows était un casse tête sans nom. DirectX plus limité était aussi plus simple et raccourcissait grandement les temps de dev. Par la suite OpenGL a loupé coche sur coche (filtering avancé, compression de texture, antialiasing, shaders tout celà existe sous OpenGL mais est assez complexe a mettre en place) alors que DirectX s'étoffait.
Aujourd'hui OpenGL est toujours aussi complexe à mettre en place, alors que DirectX a su évolué et combler ses lacunes tout en restant assez simple. Bien entendu aucun jeu vidéo professionnel du devant de la scène (les jeux microtruc c'est moins sur) n'utilise les fonctions DirectX brut de décoffrage. Mais DirectX permet d'avoir très vite un truc qui marche complètement. Quand on sait que le temps de dev d'un jeu est de deux à trois ans et qu'il y a un changement majeur de méthodes de programmation tous les 18 mois, c'est pratique.
# C'est bien son truc... Sauf que c'est faux.
Posté par Jerome Herman . En réponse au journal Une analyse des librairies graphiques par un développeur de jeux vidéos. Évalué à 10.
OpenGL a existé des années avant Direct3D, le pendant d'OpenGL sous DirectX, mais il n'a jamais décolé dans l'industrie du jeu video. Les raisons sont multiples :
Tout d'abord OpenGL n'est pas un système qui permet facilement le rendu 3D temps réel, ca n'est pas sa vocation. OpenGL est une bibliothèque graphique de gestion de rendu. La première chose que l'on fait quand on écrit un programme OpenGL est de définir quelle sera la qualité du rendu, en d'autres termes quelle précision de calcul on veut. Cette option va de GL_Default jusqu'à GL_Nicest.
OpenGL es un système ouvert dans tous les sens du terme. Notamment il est très facile d'y ajouter carte par carte des extensions spécifiques. Or très peu de cartes graphiques grand public, et même très peu de consoles de jeux sont exploitable dans le cadre d'un jeu video moderne sans faire appel massivement à ces fonctions étendues. Lesquelles sont évidement non portables, ou tout du mois spécifiques à certaines familles de puces graphiques.
OpenGL gère l'ensemble du pipeline de rendu graphique de la carte vidéo. Ce qui est très bien pour un rendu de précision, mais qui pose un véritable problème dans le cadre d'un PC de bureau. Si vous lancez une application OpenGL, elle va mettre la main sur tout un pipeline de rendu. Donc si vous lancez une seconde application OpenGL, soit vous avez une carte graphique professionnelle avec Autant de pipeline que nécessaire, soit la seconde application ne sera pas accélérée 3D et passera en mode pur soft. Sous Direct3D il est tout à fait possible d'accélerer simultanément plusieurs rendus, car c'est le système et non l'appli qui fait le dispatch des traitements. C'est pour celà que sous Vista et 7 tant que l'on a pas désactivé Aero, les performances OpenGL sont assez limitée. Bon Microsoft a sorti un patch qui fait que si l'appli OpenGL passe en plein écran aero va faire dodo et on a des perfs correctes, mais en fenétré c'est une catastrophe.
OpenGL ne s'occupe que du graphisme, et seulement dans la qualité voulue. Si par hasard vous vouliez vouer du son ou ajouter des éléments de calcul dans votre appli, à vous de vous démerder pour synchroniser tout çà. Dans DirectX ce sont les modules DirectInput et DirectSound qui se démerde à ne pas saturer trop en évènement le processeur pendant les phases de forte charge. Bon on fini souvent par être obligé de tricher un peu. Mais on a pas à tout faire à la main tout le temps
OpenGL comme DirectX ont subis des changements de paradigme important. Tant au niveau interne que vis à vis des langages et des méthodes de programmation. DirectX 5.0; Dirext 7.0 et DirectX 9.0 font appel à des concepts de programmation graphique suffisament différent pour que l'expérience de l'un ne soit pas utile aux autres. Néamoins c'est DirectX qui reste en tête. Tout simplement parcequ'il est nettement plus adapté au jeu vidéo...
Pour finir OpenGL a de nombreuses applications en dehors du jeu video, il ne viendrait à l'idée de personne de faire une imagerie médicale pour irradiation avec Direct3D (encore que...) Mais cette puissance à un prix, les objets OpenGL sont beaucoup plus pointus et beaucoup moins flexibles que leurs contreparties Direct3D. De fait le temps de programmation est rallongé d'autant.
Quand Microsoft a présenté la suite DirectDraw (Qui allait devenir DirectX 1.0) aux devs de jeux, il se sont foutus de leur gueule. Un moteur 3D ou 2D à l'époque ca se codait à la main et ca se lancait en DOS.
Au départ ni DirectX ni OpenGL n'ont décollé. En fait l'élément perturbateur a été 3DFX avec le Glide. API propriétaire tournée exclusivement vers le jeu. C'est là que ca a fait tilt. Microsoft a sorti un set d'instruction d'accellerations 3D sous la forme de DirectX 3 en faisant très attention à s'arranger pour que la plupart des traitements soient faciles à réaliser soit en MMX, soit en utilisant les fonctions de rendus vidéo déjà présente dans certaines cartes haut de gamme, et qui devaient se généraliser avec l'arrivée des DVD. C'est alors que ATI s'est engouffré dans la brêche avec les cartes xpert@work et xpert@play rejoint très peu après par Matrox qui ont fait des cartes de décompression MPEG-2 avec les suppléments nécessaire pour faire tourner en hard DirectX 3.0 et le draft DirectX 4. Sauf que le Glide2 poussait à la porte, DirectX 4 n'a pas duré très longtemps et directX 5 a été créé dans la foulée pour faire front face au Glide 2.
Mais au moment de la conception DirectX 5 un certain Carmack, qui pour ainsi dire avait rendu possible la 3D temps réel sur PC de salon, décidait de sortir Quake2 en OpenGL. Carmak étant le plus gros vendeur de jeux videos du moment, on a eu droit aussi bien coté glide avec des wrappers que coté ATI et Matrox avec des versions réduites à des pilotes OpenGL un peu costaud sur nos machines.
Seulement il s'agissait de Mini-Drivers, c'est à dire de pilote conçus pour faire tourner Quake 2 et rien d'autre. Pas un vrai support OpenGL.
Après quand Half Life a utilisé une version modifiée du quake engine, ca a fonctionné car les fonctions appelées étaient les mêmes. Cependant ca a transmis un vrai message aux fabriquants de cartes graphiques : il fallait faire de vrais pilotes OpenGL complet et tout. C'est le moment ou toutes les cartes graphique sun peu péchue supportaient l'ensemble de l'API OpenGL 1.2. C'est aussi à ce moment que le groupe Lokhi a fait des merveilles en termes de portages de jeux sous Linux. Leur version OpenGL du moteur d'Unreal poussait le vice jusqu'à battre le moteur Glide2 fait par les devs originaux. OpenGL avait le vent en poupe.
Et puis OpenGL 1.3 est sorti. Et là les fabriquants de cartes graphique sont éclatés de rire et se sont tournés vers Directx7 qui était beaucoup plus raisonnable en terme de puissance demandé pour un résultat correct. C'est un petit nouveau : NVidia qui est venu mettre la pagaille dans tout çà, en annonçant coup sur coup le support du transform and Lightning sur Directx7 et le support complet d'openGL 1.3 (Bon complet du tronc principal de l'ARB, toutes les extensions officielles n'étant pas supportée). La geforce va se vendre comme des petits pains. Et les autres constructeurs corrigent leur copie pour utiliser à fond OpenGL 1.3.
Mais aucun jeu majeur utilisant OpenGL 1.3 ne sortira. Les seuls jeux qui sortent et qui utilisent OpenGL sont OpengL 1.2, basé soit sur le moteur de quake 2 soit sur celui d'Half Life. Des jeux qui auraient pu être pris en charge par des mini drivers tout aussi bien (et en fait la guerre des benchs commencant, les différents fabriquants n'hésitent pas à créer des pilotes spécifiques pour tel et tel jeu en OpenGL de façon à bosster artificiellement les perfs, en rennomant l'executable quake2.exe en quack2.exe le site anandtech observe une perte de framerate de 30% sur Geforce). Le thresh Firing Squad s'en mèle pour donner un point de vue Vitesse d'affichage vs Beauté de l'affichage qui n'est pas en faveur de la beauté du tout. OpenGL 1.4 sort dans l'indifférence générale coté fabriquant. Seul les systèmes de compression de texture et l'illumination dynamique seront implémentés.
OpenGL 2.0 est une catastrophe en regard de l'industrie du jeu, seul Carmack s'en sert un peu, mais son temps est passé et Doom 3 et Quake 3 se vendent mal (pour du Carmack). Aujourd'hui encore très peu de cartes sont capables de gérer l'ensemble du tronc ARB d'OpenGL 2.0 en pur hardware.
OpenGL 3.0 qui devait corriger le tir et devenir un direct3D Killer prend un an de retard sans pratiquement aucune communication du groupe Khronos. Finalement loin de la refonte attendue qui aurait permis de rendre OpenGL utile dans uen optique de jeu, c'est une suite logique d'OpenGL 2.0 qui sort avec ses archaisme et ses shaders séparés. La puissance de calcul nécessaire pour faire de l'OpenGL 3.x en hardware, et la complexité de programmation clouent définitvement OpenGL au sol. Son apotre Carmack prend sa retraite et pouf.
Pour l'instant pas grand chose coté OpenGL, et à moins qu'OpenGL 4.0 ne franchisse le pas que 3.0 aurait du franchir, je en vois pas comment OpenGL peut espérer devenir concurentiel un jour.
[^] # Re: Rediriger une sortie audio vers un serveur de streaming
Posté par Jerome Herman . En réponse au journal Rediriger une sortie audio vers un serveur de streaming.. Évalué à 1.
Il aurait fallu créer une carte son virtuelle sous alsa...
Sous oss c'est encore pire, il aurait fallu diriger la sortie son vers le null audio device et rediriger ce device vers un socket (ou la sortie standard)
En d'autres termes faire à la main ce que fait Pulse audio (l'auteur du journal utilise la méthode device null audio, mais la méthode carte virtuelle fonctionne aussi)
[^] # Re: Pas compatible Linux, mais certains Linux
Posté par Jerome Herman . En réponse au journal Mon imprimante et moi, c'est du bonheur. Évalué à 4.
Presque...
Quand Linus a un problème avec une interface, il la change. Ensuite les personnes en charge des pilotes de ceci ou celà essayent d'adapter. Avec plus ou moins de succès.
Pour les trucs vraiment compliqués, comme la gestions des périphériques IDE, des périphs SATA, des ports COM virtuels ou réel ca reste un beau bordel pendant des mois voire des années. Au bout d'un moment Alan COX prend le problème sous son aile et commence à faire le ménage.
Généralement il y a au moins une altercation entre Linus et Alan pendant ce ménage. A la suite de quoi Alan COX décide de prendre un temps de pause pour étudier le Gaellique.
De manière générale une ABI dure moins de deux mois, une API moins de six...
Malheureusement pour nous et pour Linux en général, Alan Cox en a rien à foutre du tout d'Alsa ou de V4L
Plus sérieusement, le problème de ta théorie est la maintenabilité : ce que tu décris est pure théorie, en pratique il est dur et épuisant de tester les régressions avec les anciennes interfaces, et sans personne pour se coltiner le travail, l'ancienne interface est abandonnée.
Ce qu'il décrit existe depuis des années sous BSD. Notamment FreeBSD. J'ai un module de carte réseau Realtek qui a été compilé pour une 4 et qui tourne très bien en 6.2. Près de 5 ans d'ABI sur un module.
Et pourtant les devs FreeBSD sont nettement moins nombreux que les devs Linux.
[^] # Re: la verite est... quelque part
Posté par Jerome Herman . En réponse au journal Bruce Perens, l'auteur de Busybox, s'exprime sur l'affaire. Évalué à 3.