je voudrais savoir ce que vous me conseilleriez comme lecteur vidéo
pour un vieux PC à 500 ou 600 Mhz, windows 98 et 476 Mo de ram. Je
cherche un lecteur qui soit le plus "rapide" possible, c'est à dire qui
me permette une lecteur assez fluide malgré la puissance toute relative
de la machine. Je précise que c'est pour lire en majorité des DVD
venant du video-club ainsi que quelques divX.
Le mediaplayer semble souvent aux fraises.
Cédric
--
Cédric Trojani
Graphic designer and Illustrator
www.graphinc.com
Le Tue, 25 Oct 2005 19:13:28 +0200, Patrick 'Zener' Brunet a écrit :
Bonjour.
[...]
Avez-vous des liens instructifs sur la stratégie du monde Linux pour fournir des drivers performants en temps réel sans bénéficier du support intime des constructeurs ? C'est un truc qui m'échappe encore, et je dirais que c'est même ce qui me freine le plus...
Je n'ai pas de lien particulier sur le sujet.
1) Le support actif des constructeurs (de composants électroniques ou de matériel informatique) est exceptionnel au sens propre du terme. La règle générale se décompose en deux options: 2) les constructeurs publient les spécifications techniques de leurs matériels/composants 3) les constructeurs ne le font pas
Dans le cas N°1, tout est presque pour le mieux dans le meilleur des mondes, le constructeurs fournissant des drivers (pas toujours libres...) développés par lui-même ou sur commande par une société tierce. Dans le cas N°2, les développeurs du "monde libre ;-)" créent un projet visant à l'utilisation fiable d'un driver libre, ce qui arrive le plus souvent avec quelques mois de retard par rapport au monde de Redmond. Dans le cas N°3, la seule solution est le reverse-engineering (rétro-ingénierie) qui consiste à faire des études de cas de fonctionnements, à en déduire un principe de fonctionnement du driver propriétaire, à désassembler le code binaire du même driver et à développer un nouveau driver libre : tout cela est évidemment long, pénible et semé d'embûches.
Petit rappel concernant les cartes vidéo pour PC: elles sont toutes (depuis un certain temps) compatibles avec la norme Vesa (2D) et la 3D n'est utilisée que pour les jeux et les applications de DAO 3D (Dessin Assisté par Ordinateur en 3 dimensions). Pour le reste, les capacités 3D ne servent à rien.
Merci, Cordialement,
Le Tue, 25 Oct 2005 19:13:28 +0200, Patrick 'Zener' Brunet a écrit :
Bonjour.
[...]
Avez-vous des liens instructifs sur la stratégie du monde Linux pour fournir
des drivers performants en temps réel sans bénéficier du support intime des
constructeurs ? C'est un truc qui m'échappe encore, et je dirais que c'est
même ce qui me freine le plus...
Je n'ai pas de lien particulier sur le sujet.
1) Le support actif des constructeurs (de composants électroniques ou de
matériel informatique) est exceptionnel au sens propre du terme.
La règle générale se décompose en deux options:
2) les constructeurs publient les spécifications techniques de leurs
matériels/composants
3) les constructeurs ne le font pas
Dans le cas N°1, tout est presque pour le mieux dans le meilleur des
mondes, le constructeurs fournissant des drivers (pas toujours libres...)
développés par lui-même ou sur commande par une société tierce.
Dans le cas N°2, les développeurs du "monde libre ;-)" créent un projet
visant à l'utilisation fiable d'un driver libre, ce qui arrive le plus
souvent avec quelques mois de retard par rapport au monde de Redmond.
Dans le cas N°3, la seule solution est le reverse-engineering
(rétro-ingénierie) qui consiste à faire des études de cas de
fonctionnements, à en déduire un principe de fonctionnement du driver
propriétaire, à désassembler le code binaire du même driver et à
développer un nouveau driver libre : tout cela est évidemment long,
pénible et semé d'embûches.
Petit rappel concernant les cartes vidéo pour PC: elles sont toutes
(depuis un certain temps) compatibles avec la norme Vesa (2D) et la 3D
n'est utilisée que pour les jeux et les applications de DAO 3D (Dessin
Assisté par Ordinateur en 3 dimensions). Pour le reste, les capacités 3D
ne servent à rien.
Le Tue, 25 Oct 2005 19:13:28 +0200, Patrick 'Zener' Brunet a écrit :
Bonjour.
[...]
Avez-vous des liens instructifs sur la stratégie du monde Linux pour fournir des drivers performants en temps réel sans bénéficier du support intime des constructeurs ? C'est un truc qui m'échappe encore, et je dirais que c'est même ce qui me freine le plus...
Je n'ai pas de lien particulier sur le sujet.
1) Le support actif des constructeurs (de composants électroniques ou de matériel informatique) est exceptionnel au sens propre du terme. La règle générale se décompose en deux options: 2) les constructeurs publient les spécifications techniques de leurs matériels/composants 3) les constructeurs ne le font pas
Dans le cas N°1, tout est presque pour le mieux dans le meilleur des mondes, le constructeurs fournissant des drivers (pas toujours libres...) développés par lui-même ou sur commande par une société tierce. Dans le cas N°2, les développeurs du "monde libre ;-)" créent un projet visant à l'utilisation fiable d'un driver libre, ce qui arrive le plus souvent avec quelques mois de retard par rapport au monde de Redmond. Dans le cas N°3, la seule solution est le reverse-engineering (rétro-ingénierie) qui consiste à faire des études de cas de fonctionnements, à en déduire un principe de fonctionnement du driver propriétaire, à désassembler le code binaire du même driver et à développer un nouveau driver libre : tout cela est évidemment long, pénible et semé d'embûches.
Petit rappel concernant les cartes vidéo pour PC: elles sont toutes (depuis un certain temps) compatibles avec la norme Vesa (2D) et la 3D n'est utilisée que pour les jeux et les applications de DAO 3D (Dessin Assisté par Ordinateur en 3 dimensions). Pour le reste, les capacités 3D ne servent à rien.
Merci, Cordialement,
Patrick 'Zener' Brunet
Bonjour.
Je réponds à didier gaumet
Bonjour.
[...]
Avez-vous des liens instructifs sur la stratégie du monde Linux pour fournir des drivers performants en temps réel sans bénéficier du support intime des constructeurs ? C'est un truc qui m'échappe encore, et je dirais que c'est même ce qui me freine le plus...
Je n'ai pas de lien particulier sur le sujet.
1) Le support actif des constructeurs (de composants électroniques ou de matériel informatique) est exceptionnel au sens propre du terme. La règle générale se décompose en deux options: 2) les constructeurs publient les spécifications techniques de leurs matériels/composants 3) les constructeurs ne le font pas
Dans le cas N°1, tout est presque pour le mieux dans le meilleur des mondes, le constructeurs fournissant des drivers (pas toujours libres...) développés par lui-même ou sur commande par une société tierce. Dans le cas N°2, les développeurs du "monde libre ;-)" créent un projet visant à l'utilisation fiable d'un driver libre, ce qui arrive le plus souvent avec quelques mois de retard par rapport au monde de Redmond. Dans le cas N°3, la seule solution est le reverse-engineering (rétro-ingénierie) qui consiste à faire des études de cas de fonctionnements, à en déduire un principe de fonctionnement du driver propriétaire, à désassembler le code binaire du même driver et à développer un nouveau driver libre : tout cela est évidemment long, pénible et semé d'embûches.
C'est bien ce que j'avais compris avant, et qui reste d'actualité...
Mais comme disait Gandhi, c'est en parlant aux gens leur langage qu'on arrive à les toucher. Le but premier d'un constructeur est de vendre son matériel, et donc tout dépend de la représentativité du système pour lequel on lui réclame un driver, ou à défaut le simple effort de publier les specs. Donc c'est en bonne voie :-)
Concernant le cas n° 3: -------------------------
En me penchant un peu sur le Plug 'n Play et fonctionnement de l'identification des "devices" par "VendorID" et "ProductID", je me suis rendu compte que finalement, pour le BIOS et la partie la plus basse du système, tout est perçu de manière assez homogène, comme monté en grappe autour du chipset de la carte-mère, avec éventuellement des "ponts" tels que le contrôleur PCI, le contrôleur IDE, les ports, etc.
Je me demande alors dans quelle mesure il serait possible d'envisager un driver "hook" générique (éventuellement associé à une carte spécialisée) pour écouter tous les échanges liés à un composant donné, et donc en extraire tous ses chronogrammes.
Un tel outil faciliterait grandement la reconstitution du protocole formel des échanges, sans même nécessiter un reverse-engineering du code du driver.
Quelqu'un a-t-il entendu parler d'un tel projet ?
Petit rappel concernant les cartes vidéo pour PC: elles sont toutes (depuis un certain temps) compatibles avec la norme Vesa (2D) et la 3D n'est utilisée que pour les jeux et les applications de DAO 3D (Dessin Assisté par Ordinateur en 3 dimensions). Pour le reste, les capacités 3D ne servent à rien.
Oui, je crois que pour les cartes graphiques, les standards sont pas mal établis.
Par contre pour les cartes d'acquisition, le problème est très récent...
Merci pour ces informations. Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
Bonjour.
Je réponds à didier gaumet <didier.gaumet@libertysurf.fr>
Bonjour.
[...]
Avez-vous des liens instructifs sur la stratégie du monde Linux pour
fournir des drivers performants en temps réel sans bénéficier du
support intime des constructeurs ? C'est un truc qui m'échappe
encore, et je dirais que c'est même ce qui me freine le plus...
Je n'ai pas de lien particulier sur le sujet.
1) Le support actif des constructeurs (de composants électroniques ou
de matériel informatique) est exceptionnel au sens propre du terme.
La règle générale se décompose en deux options:
2) les constructeurs publient les spécifications techniques de leurs
matériels/composants
3) les constructeurs ne le font pas
Dans le cas N°1, tout est presque pour le mieux dans le meilleur des
mondes, le constructeurs fournissant des drivers (pas toujours
libres...) développés par lui-même ou sur commande par une société
tierce.
Dans le cas N°2, les développeurs du "monde libre ;-)" créent un
projet visant à l'utilisation fiable d'un driver libre, ce qui arrive
le plus souvent avec quelques mois de retard par rapport au monde de
Redmond.
Dans le cas N°3, la seule solution est le reverse-engineering
(rétro-ingénierie) qui consiste à faire des études de cas de
fonctionnements, à en déduire un principe de fonctionnement du driver
propriétaire, à désassembler le code binaire du même driver et à
développer un nouveau driver libre : tout cela est évidemment long,
pénible et semé d'embûches.
C'est bien ce que j'avais compris avant, et qui reste d'actualité...
Mais comme disait Gandhi, c'est en parlant aux gens leur langage qu'on
arrive à les toucher. Le but premier d'un constructeur est de vendre son
matériel, et donc tout dépend de la représentativité du système pour lequel
on lui réclame un driver, ou à défaut le simple effort de publier les specs.
Donc c'est en bonne voie :-)
Concernant le cas n° 3:
-------------------------
En me penchant un peu sur le Plug 'n Play et fonctionnement de
l'identification des "devices" par "VendorID" et "ProductID", je me suis
rendu compte que finalement, pour le BIOS et la partie la plus basse du
système, tout est perçu de manière assez homogène, comme monté en grappe
autour du chipset de la carte-mère, avec éventuellement des "ponts" tels que
le contrôleur PCI, le contrôleur IDE, les ports, etc.
Je me demande alors dans quelle mesure il serait possible d'envisager un
driver "hook" générique (éventuellement associé à une carte spécialisée)
pour écouter tous les échanges liés à un composant donné, et donc en
extraire tous ses chronogrammes.
Un tel outil faciliterait grandement la reconstitution du protocole formel
des échanges, sans même nécessiter un reverse-engineering du code du driver.
Quelqu'un a-t-il entendu parler d'un tel projet ?
Petit rappel concernant les cartes vidéo pour PC: elles sont toutes
(depuis un certain temps) compatibles avec la norme Vesa (2D) et la 3D
n'est utilisée que pour les jeux et les applications de DAO 3D (Dessin
Assisté par Ordinateur en 3 dimensions). Pour le reste, les capacités
3D ne servent à rien.
Oui, je crois que pour les cartes graphiques, les standards sont pas mal
établis.
Par contre pour les cartes d'acquisition, le problème est très récent...
Merci pour ces informations.
Cordialement,
--
/***************************************
* Patrick BRUNET
* E-mail: lien sur http://zener131.free.fr/ContactMe
***************************************/
Avez-vous des liens instructifs sur la stratégie du monde Linux pour fournir des drivers performants en temps réel sans bénéficier du support intime des constructeurs ? C'est un truc qui m'échappe encore, et je dirais que c'est même ce qui me freine le plus...
Je n'ai pas de lien particulier sur le sujet.
1) Le support actif des constructeurs (de composants électroniques ou de matériel informatique) est exceptionnel au sens propre du terme. La règle générale se décompose en deux options: 2) les constructeurs publient les spécifications techniques de leurs matériels/composants 3) les constructeurs ne le font pas
Dans le cas N°1, tout est presque pour le mieux dans le meilleur des mondes, le constructeurs fournissant des drivers (pas toujours libres...) développés par lui-même ou sur commande par une société tierce. Dans le cas N°2, les développeurs du "monde libre ;-)" créent un projet visant à l'utilisation fiable d'un driver libre, ce qui arrive le plus souvent avec quelques mois de retard par rapport au monde de Redmond. Dans le cas N°3, la seule solution est le reverse-engineering (rétro-ingénierie) qui consiste à faire des études de cas de fonctionnements, à en déduire un principe de fonctionnement du driver propriétaire, à désassembler le code binaire du même driver et à développer un nouveau driver libre : tout cela est évidemment long, pénible et semé d'embûches.
C'est bien ce que j'avais compris avant, et qui reste d'actualité...
Mais comme disait Gandhi, c'est en parlant aux gens leur langage qu'on arrive à les toucher. Le but premier d'un constructeur est de vendre son matériel, et donc tout dépend de la représentativité du système pour lequel on lui réclame un driver, ou à défaut le simple effort de publier les specs. Donc c'est en bonne voie :-)
Concernant le cas n° 3: -------------------------
En me penchant un peu sur le Plug 'n Play et fonctionnement de l'identification des "devices" par "VendorID" et "ProductID", je me suis rendu compte que finalement, pour le BIOS et la partie la plus basse du système, tout est perçu de manière assez homogène, comme monté en grappe autour du chipset de la carte-mère, avec éventuellement des "ponts" tels que le contrôleur PCI, le contrôleur IDE, les ports, etc.
Je me demande alors dans quelle mesure il serait possible d'envisager un driver "hook" générique (éventuellement associé à une carte spécialisée) pour écouter tous les échanges liés à un composant donné, et donc en extraire tous ses chronogrammes.
Un tel outil faciliterait grandement la reconstitution du protocole formel des échanges, sans même nécessiter un reverse-engineering du code du driver.
Quelqu'un a-t-il entendu parler d'un tel projet ?
Petit rappel concernant les cartes vidéo pour PC: elles sont toutes (depuis un certain temps) compatibles avec la norme Vesa (2D) et la 3D n'est utilisée que pour les jeux et les applications de DAO 3D (Dessin Assisté par Ordinateur en 3 dimensions). Pour le reste, les capacités 3D ne servent à rien.
Oui, je crois que pour les cartes graphiques, les standards sont pas mal établis.
Par contre pour les cartes d'acquisition, le problème est très récent...
Merci pour ces informations. Cordialement,
-- /*************************************** * Patrick BRUNET * E-mail: lien sur http://zener131.free.fr/ContactMe ***************************************/
