Journal Divx sous config Restreinte

Posté par bartman le 14 décembre 2004 à 11:27.

Étiquettes :

déc.

2004

Salut les gens !

Vu que c'est un journal publique, je m'ouvre aux compétents car dans mon précédent journal [1] , j'ai été agréablement surpris non seulement par les bonnes volontés, mais en plus du fait que les remarques étaient constructives.

Ce journal provient donc d'une réflexion d'autres journaux-dépêches, notament : sur le mini-itx [2] et LFS[3] .
En effet, j'ai mon eden 800 (un processeur C3 classe Pentium) qui s'ennuie tout seul depuis quelques temps, je me suis dit que mes pitchounes pourraient regarder leur mulan 8 avec.

Vu que j'ai toujours pensé que Linux savait faire ça : s'adapter à l'environement (hard) sur lequel il tourne,
le fond du problème est comme le lait de mes momes,autant dire qu'il reste entier :

Comment peut on lire un divx même avec une petite config ?.

- Quelles sont les "tuning", recompilations possibles?
- dois je reconstruire le kernel?,
- utiliser un codec particulier, quitte à réencoder le divx ?
- Quid des options de lecture mplayer [4] pour obtenir la plus grande vitesse (sauter des trames peut être tendancieux)?
- j'ai nommé LFS : faut il une distrib dédiée ?
- Est ce mieux de le relier en réseau (cable croisé) à mon PC de bureau (un XP1600 +) pour faire du streaming (option -bandwidth ) ? :: l'Eden suivra-t-il pour autant ?
- Lara Fabian fera-t-elle enfin un duo avec Yvette Horner ?

Ah que de questions métaphysiques !

Alors toi lecteur, peut-tu me libérer de ces errements dans ces "Oooh" troubles et combien alambiqués de ce problème qui pourtant doit connaitre une possible résolution.
Je crois que ce journal est utile, il ne pose pas seulement la question vis-à-vis de linux et l'Eden, mais aussi des petites configurations comme ces occases pas chères qui reviennent en force dans les magasins.

Tcho !

[1] Quel journal !! :

http://linuxfr.org/~bartman/16248.html(...)

[2] mini-itx :

http://linuxfr.org/~patatorz/16057.html(...)

[3] LFS :

http://linuxfr.org/2004/12/09/17844.html(...)

[4] options mplayer :

http://www.mplayerhq.hu/DOCS/man/fr/mplayer.1.html(...)

# Ça ne va pas forcément t'avancer mais...

Posté par fmaz fmaz le 14 décembre 2004 à 12:11. Évalué à 5.

Il fut un temps ou j'avais compilé mplayer sur un PII300Mhz et j'avais
été surpris de voir à quel point ça tournait bien. Ceci dit, c'était
il y a 2 ans. Les choses ont donc pu changer, mais à l'époque les
gens de mplayer insistaient lourdement sur le fait que compiler
mplayer, c'était bien parce qu'il faisaient énormément d'optimisation
CPU-dependant.
- [^] # Re: Ça ne va pas forcément t'avancer mais...
  
  Posté par LaBienPensanceMaTuer le 14 décembre 2004 à 12:46. Évalué à 4.
  
  Il y a encore 1 an et demi j'étais étudiant et pauvre et possesseur d'une config à base de céléron 400 avec 128Mo de Ram.
  Et bien je n'ai jamais eu aucun souci de lecture de divx, par contre les DVD c'était très limite.
  Simple tweak, pense à activer le support des mtrr dans ton kernel, mplayer en tire parti.
- [^] # Re: Ça ne va pas forcément t'avancer mais...
  
  Posté par Yannick (site web personnel) le 14 décembre 2004 à 13:22. Évalué à 1.
  
  Il y a 3 ans, quand j'était encore avec un K6-200Mhz, mplayer me permettrait de lire euh, non, de pré-visualiser des vidéos impossible à faire tourner sous windows. Reste que ma config était vraiment trop juste, car avec l'option -framedrop qui m'était obligatoire, beaucoup d'images manquaient et ça n'était pas regardable.
  Oui, j'avais pas mal optimizé et oui, il ne manquait pas beaucoup de puissance de calcul ( je dirait 10%, 20% au plus) pour avoir quelque chose d'exploitable.
# Mplayer xp

Posté par dawar (site web personnel) le 14 décembre 2004 à 12:12. Évalué à 5.

C'est un mplayer optimisé : http://mplayerxp.sourceforge.net/(...)

MplayerXP is a branch of the well known mplayer (http://mplayerhq.hu(...)) which is based on the new (thread based) core. The new core provides better CPU utilization and excellently improves performance of video decoding. Main goal of this project is to get monotonous CPU loading during movie playback.

J'ai essayé, perso je vois pas la différence mais peux être sur une machine moins puissante...
- [^] # Re: Mplayer xp
  
  Posté par Marc (site web personnel) le 14 décembre 2004 à 12:26. Évalué à 4.
  
  je pensais pas que ça se faisait encore des sites avec des vieilles frame pourries qui obligent à scroller pour lire le titre...
  - [^] # Re: Mplayer xp
    
    Posté par bmc le 15 décembre 2004 à 19:24. Évalué à 4.
    
    Ils sont peut-être meilleurs en développement système qu'en développement web :)
- [^] # Re: Mplayer xp
  
  Posté par Colin Leroy (site web personnel) le 14 décembre 2004 à 13:52. Évalué à 3.
  
  ça utilise juste une approche multithread, les devels de mplayer disent que ça n'apporte pas beaucoup (et peut entrainer des problèmes, particulièrement sur la synchro A/V).
# FB?

Posté par Marc (site web personnel) le 14 décembre 2004 à 12:17. Évalué à 2.

peut être qu'en utilisant le framebuffer ou les autres pilotes de mplayer ça serait plus rapide qu'avec un serveur X classique
- [^] # Re: FB?
  
  Posté par JoeltheLion (site web personnel) le 14 décembre 2004 à 13:12. Évalué à 1.
  
  Je suis loin d'être un expert, mais sur mon portable les divx ramaient jusqu'à ce que je trouve le switch "-vo xv" de mplayer. Maintenant tout marche bien et l'utilisation processeur est même faible (~10%).
  Apparamment ce switch active une certaine forme d'accélération matérielle, peut être faut-il avoir une carte qui le supporte?
  - [^] # Re: FB?
    
    Posté par Colin Leroy (site web personnel) le 14 décembre 2004 à 13:54. Évalué à 6.
    
    -vo xv utilise l'extension Xv du serveur X. C'est, en gros, l'overlay. Mplayer a des options plus rapides, qui fonctionnent avec des Ati, certaines Nvidia et deux/trois autres cartes (Matrox je crois): -vo xvidix (sous X) et -vo cvidix (en Console). Ces deux là sont terriblement performantes (par rapport à Xv, elles court-circuitent quelques niveaux d'abstraction logicielle supplémentaires).
    - [^] # Re: FB?
      
      Posté par bartman le 14 décembre 2004 à 15:18. Évalué à 3.
      
      ok mais en te lisant une question me vient à l'esprit : ne gagnerait on pas un peu de CPU en console plutot qu'en rajoutant un serveur X ?
      - [^] # Re: FB?
        
        Posté par Colin Leroy (site web personnel) le 14 décembre 2004 à 17:08. Évalué à 4.
        
        Pas avec [x|c]vidix, du moment que le serveur n'a rien de spécial à faire à côté. Mplayer le courtcircuite totalement avec xvidix.
        
        [^] # Re: FB?
        
        Posté par Tutur le 14 décembre 2004 à 21:07. Évalué à 1.
        
        Personellement, j'utilisait -vo fbdev:vidix Enfin, ça marchais nickel et je pouvais faire du fullscreen. Mais depuis la version pre3, un idiot a reécrit la partie vidix pour les ati rage 128 et ça marche plus.
        
        [^] # Re: FB?
        
        Posté par Colin Leroy (site web personnel) le 15 décembre 2004 à 09:18. Évalué à 3.
        
        Ben patche ou remets la version pre2. A ta place j'éviterai de prendre les devels mplayer pour des idiots - ça fait un peu paille,poutre,tout ça :)
- [^] # Re: FB?
  
  Posté par Nicolas Boulay (site web personnel) le 14 décembre 2004 à 15:10. Évalué à 3.
  
  le framebuffer est hyper lent devant XV. il n'y a pas de gestion DMA, seul la mémoire video est vu comme un gros buffer, aucune accélération 2D n'y est possible.
  
  L'interret est la simplicité d'utilisation pas les performances.
  "La première sécurité est la liberté"
  - [^] # Re: FB?
    
    Posté par rlksirocco le 14 décembre 2004 à 16:49. Évalué à 2.
    
    Personnellement sur un portable avec un proc Transmeta Crusoe Tm5600 600 Mhz et avec 256 Mo Sdram je fais tourné mplayer avec le framebuffer et l'option -vo vesa ... aucun probleme, impeccable je dirais meme :)
    - [^] # Re: FB?
      
      Posté par Nicolas Boulay (site web personnel) le 16 décembre 2004 à 16:36. Évalué à 3.
      
      je dis juste qu'avec un drivers xv cela irait plus vite...
      "La première sécurité est la liberté"
# Ma vie, mon histoire, mon P233 avec 32MB de RAM

Posté par Jonathan Loriaux le 14 décembre 2004 à 12:40. Évalué à 4.

Il était une fois un vieux portable acheté pas cher, et un idée dans la tête de le transformer en tv numérique.

La bête est un Dell Latitude 233Mhz avec 32MB de RAM et une neomagic comme carte graphique. Sans détours, la meilleure manière pour moi fut de créer un flux optimisé en audio/video grâce à VideoLan venant de ma machine de bureau (bien plus puissante celle-là) vers Mplayer en console sur le portable en utilisant Vesafb et en sautant des frames ...

Le résulata n'était pas extra, mais j'étais fier de ma réussite ... depuis, on a acheté une vrai télévision ... quelle horreur.
- [^] # Re: Ma vie, mon histoire, mon P233 avec 32MB de RAM
  
  Posté par Ozz le 14 décembre 2004 à 13:24. Évalué à 3.
  
  j'arrive a lire des divx sur un pentium 233, 128mo de ram, avec un ptit mplayer -hardframedrop . Je n'ai fais aucune compile spécial (apt-get install kernel-2.4-586 mplayer-586)
  
  Bon ils ne passent pas tous, mais j'arrive à en lire pas mal quand même (il faudrait que je vérifie avec quels codecs et en quel résolution ça passe bien)
  - [^] # Re: Ma vie, mon histoire, mon P233 avec 32MB de RAM
    
    Posté par Jonathan Loriaux le 14 décembre 2004 à 18:32. Évalué à 2.
    
    Mon problème je pense n'est pas tant dû au processeur qu'à la RAM (mais je peux me tromper), d'où l'intérêt du stream. Mais si quelqu'un a de bonnes propositions à me donner pour que ce soit plus performant ....
# framebuffer

Posté par hommelix le 14 décembre 2004 à 13:28. Évalué à 2.

Il y a deux ans, quand j'avais recu mon epia800, j'avais joue avec mplayer, sans bcq d'optimisation ca tourne nickel.

J'avais juste rapidement installe une mdk (8.2 je crois) et rajouter le plf et un urpmi

Ensuite c'etait fluide sans pb en framebuffer.
- [^] # Re: framebuffer
  
  Posté par bartman le 14 décembre 2004 à 15:23. Évalué à 2.
  
  étonnant, je suis dans le même cas et sous X , mplayer arrive à peine à afficher quelques images, le son par contre est niquel vu qu'il y à un codec implémenté dessus.
  
  Es-tu sur que tu n'avais pas fait autre chose vu que je suis également avec une MDK 10.0 ?
  - [^] # Re: framebuffer
    
    Posté par hommelix le 14 décembre 2004 à 20:53. Évalué à 0.
    
    oui, c'etait avec un noyau 2.4, et juste un framebuffer. un mplayer -vo vesa.
    
    Maintenant, c'est une debian en serveur nfs, donc j'ai plus de mplayer dessus.
# options mplayer

Posté par Colin Leroy (site web personnel) le 14 décembre 2004 à 13:56. Évalué à 3.

En plus des options -vo xvidix ou cvidix dont j'ai parlé plus haut, il faut essayer les différents drivers audio (-ao sdl, alsa, oss, ...). Certains sont bien plus efficaces que d'autres. Vérifier aussi l'utilisation des implémentations de codecs ffmpeg au lieu des dll natives, qui rament plus. Si les codecs ffmpeg ne sont pas utilisés, voir dans un des fichiers de conf.
# Conf reduite, intervention Minime

Posté par cce le 14 décembre 2004 à 14:01. Évalué à 3.

Salut, je ne te propose pas de reconmpiler Mplayer avec module ffmpeg et tout le reste mais un truc tout fait (pas besion de reinventer la roue ) mais qui necessite un reboot ....
La fameuse et non moins efficace GeexBox[1].
Une iso de 6 Mo[2], et les prerequis materiel sont .... PII 400[3] 64Mo de RAM, il me semble que ton C3 800 sera parfait !

[1]http://geexbox.org/(...)
[2]http://geexbox.org/fr/downloads.html(...)
[3]http://geexbox.org/fr/requirements.html(...)
- [^] # Re: Conf reduite, intervention Minime
  
  Posté par bartman le 14 décembre 2004 à 15:28. Évalué à 2.
  
  ça tombe bien !!
  
  j'ai eut cette démarche, j'ai trouvé l'idée de ce projet trés attractive, seulement après avoir gravé l' ISO et testé sur le PC de bureau et sur l'eden je peux dire que le boot ne marchait pas.
  
  Je me suis d'abord mis en cause (mauvaise gravure, erreur de télechargement, etc) jusqu'à ce que je m'aperçoive que d'autres personnes que je connaissait n'arrivait pas non plus à booter avec le CD.
  - [^] # Re: Conf reduite, intervention Minime
    
    Posté par fimbles le 14 décembre 2004 à 16:34. Évalué à 3.
    
    Pareil, je n'ai jamais réussi à booter avec Geexbox.
    Par contre, je n'ai jamais eu de souci avec Movix2 http://movix.sf.net(...) sur un Celeron 300 avec 160Mo de RAM (lecture de DVD et DivX en tout genre).
  - [^] # Re: Conf reduite, intervention Minime
    
    Posté par cce le 15 décembre 2004 à 09:30. Évalué à 2.
    
    Vu sur le Forum de Geexbox :
    on the EPIA boards you must pass ACPI=off at boot
    je sais pas comment le faire mais c'est a tester ...
    - [^] # Re: Conf reduite, intervention Minime
      
      Posté par Hugues Hiegel (site web personnel) le 15 décembre 2004 à 10:13. Évalué à 3.
      
      > on the EPIA boards you must pass ACPI=off at boot
      > je sais pas comment le faire mais c'est a tester ...
      
      normalement (je sais pas, j'ai jamais testé geekbox) tu as une invite au tout début du boot, voire un ecran de démarrage qui te cache tout mais attend qques secondes...
      il faut juste appuyer sur TAB a ce moment la, afin d'avoir l'invite de commande de boot -a moins qu'elle ne s'affiche déjà.
      Et il suffit juste de rajouter cette option après le nom du noyau/de l'entrée à démarrer.
      
      Par exemple sur un linux classique, avec lilo, ca donnera un truc du genre :
      
      LILO: linux ACPI=off
      
      pour booter l'entree lilo "linux" avec l'option ACPI en question..
      
      Voila, j'espere t'avoir donné suffisamment d'infos :-/
      - [^] # Re: Conf reduite, intervention Minime
        
        Posté par bartman le 15 décembre 2004 à 10:59. Évalué à 2.
        
        ça part d'un bon sentiment certes, cela dit dans ma remarque j'incluai mes 2 PC et pas seulement l'EPIA.
        
        En fait après avoir gravé l'ISO les PC ne bootait pas dessus, tout simplement, aucune invite proposée.
# Et pourquoi pas xine ?

Posté par Geo Vah le 14 décembre 2004 à 15:13. Évalué à 2.

Même si je suis pro-mplayer,
une utilisation de xine optimisé par VIA pour leur plate-forme peut etre une bonne idée :-)

http://www.toolinux.com/news/logiciels/via_veut_ameliorer_le_logici(...)

Voili,voilou....
- [^] # Re: Et pourquoi pas xine ?
  
  Posté par bartman le 14 décembre 2004 à 15:38. Évalué à 2.
  Génial ta réponse !
  je vais vivement essayer ce lecteur qui semble fait pour la plateforme VIA,.
  
  JE quand même comparer avec les options -vo xvidix et xv -hardframedrop citées plus haut
  - [^] # CLE266?
    
    Posté par hommelix le 14 décembre 2004 à 21:33. Évalué à 1.
    
    L'epia800 utilise un PLE133 amha (ou un nom tres semblable), qui n'a rien a voir avec les CLE266. Donc ca ne sera pas plus accelerer. Le CLE266 est dans les epia M, comme les epia 10000M et 9000M, ils utilisent un core C3 NEhemiah et plus Erza.
    
    Enfin bonne chance qd meme.
    - [^] # Re: CLE266?
      
      Posté par bartman le 15 décembre 2004 à 11:47. Évalué à 2.
      
      exact !
      
      j'avais pourtant vérifié sur le site de VIA, à croire que je me suis trompé de lien,
      
      je confirme c'est un PLE133 et non pas un CLE266 avec :
    - http://www.viaembedded.com/product/3/4/EPIA_operating_guidelines1.p(...)

[^] # Re: Et pourquoi pas xine ?

Posté par sk le 15 décembre 2004 à 16:51. Évalué à 3.

Petite précision à ce sujet.

Ce texte est trompeur. D'une part, VeXP ne tire partie que du CLE266 et du tout récent CN400 de Via. Ce que ce texte ne dit pas, c'est à quoi cette accélération s'applique.

En ce qui concerne le MPEG2, les deux chipsets ont un début d'accélération MPEG2 (uniquement la phase de compensation de mouvement) et les gains sur mon EPIA sont plutot de l'ordre 20-30% (grosso modo). Pour ceux que ca intéresse, il y a dans le cvs de Xorg un support du xmvc via et aussi un plugin mplayer sur le site du projet unichrome ( http://unichrome.sf.net(...) ) .
En ce qui concerne le MPEG4, seul le CN400 est accéléré. Il n'y aura aucun gain sur les autres chipsets.

En ce qui concerne le vidix, il y a un début de support du chipset VIA dans le cvs de mplayer (malheureusement je pense que ca ne concerne à nouveau que le CLE266). Ce driver ne marche pas terrible encore (pas du tout en fait chez moi...).

Pour la différence de perf entre framebuffer et X, je n'ai pas vu de différence notable (même en utilisant directFB). Xv est à mon avis la meilleure solution pour l'instant.

Avec une epia MII-10000 avec 256Mo de RAM, j'arrive à lire les DVDs sans le moindre problème à environ 50% d'utilisation CPU (sans l'accélération) , des fichiers Xvid de très bonne qualité à une utilisation CPU qui varie entre 20 et 60%. La machine commence à être "limite" pour les wmv9 (qui n'est pas vraiment connu pour être un codec vraiment économe au niveau proc...). En -vo null et -nosound, le cpu ne suit pas sur certaines scenes tres rapides.

Pour avoir une idée de ce que ca peut donner sur un eden, il faut avoir en tête la différence de fréquence entre les deux, mais aussi les différences d'architecture (pas de gestion de SSE, FPU cadencé à la moitié de la vitesse d'horloge, etc.).

[^] # Re: Et pourquoi pas xine ?

Posté par bartman le 16 décembre 2004 à 11:01. Évalué à 2.

utile, cela situe plus précisément les gains par rapport à la réalité.

Est ce que par hasard sur ton EPIA tu as tenté une recompil du kernel, et/ou de mplayer, réencodage (avec ffmpeg par ex), autres.... et si oui, quelles options t'ont semblées bénéfiques ?

Je commence à me demander si je suis un des rares à m'entéter à mettre en oeuvre un Linux sur une petit config, mais j'ai la foi : je verrai 3 images successives d'un divx sur l'Eden ;op
- [^] # Re: Et pourquoi pas xine ?
  
  Posté par sk le 17 décembre 2004 à 10:07. Évalué à 1.
  
  Le kernel que j'utilise est un kernel vanilla (2.6.7) sur lequel j'ai rajouté le patch -epia. Globalement, ce patch n'apporte aucune optimisation spécifique en terme de performances, mais plutot un support amélioré (et opensource !) des différents périphériques embarqués sur l'epia.
  Tu peux le trouver assez facilement sur http://www.epiawiki.org.(...)
  
  Entre autres, ca apporte:
  - Support du framebuffer via: assez bizzare, j'ai reussi à le faire marcher uniquement sur un kernel 2.4... Il semblerait qu'il y ait quelque chose de cassé... Celui embarqué dans ce patch fournit en théorie un embryon d'accélération 2D pour le framebuffer contrairement au driver fournit par via, mais honnetement j'ai vu aucune différence... Ca fournit aussi dans le même domaine le helper spécifique au CLE266 pour directfb.
  - Driver DRI pour via: il est possible que ce driver marche pour l'eden aussi. C'est quoi exactement la dénomination du controleur graphique de l'epia ? Si c'est le cyberblade trident, il y a deja un driver DRI qui traine quelque part il me semble, et il y a aussi un driver vidix (ca j'en suis a peu pres sur).
  + Quelques autres bricoles supplémentaires.
  
  Pour le kernel, j'ai mis la cible c3-2 (nehemiah), qui est de toute facon un alias pour i686 pour gcc, donc je doute que ca apporte grand chose au niveau optimisation. Il faut cependant bien voir que l'eden est plus proche au niveau structure d'un 586 voire 486 que d'un processeur i686 (notamment une compilation en i686 entrainera des erreurs un peu bizarres du fait de l'absence d'instructions spécifiques, et notamment l'instruction CMOD). Sur epiawiki tu trouveras les paramètres de compil les plus adaptés pour ton eden, je pense...
  
  Pour Mplayer, je pense qu'il vaut mieux le laisser faire sa sauce tout seul, vu qu'il détecte le processeur lors de la phase de compil (par contre ca peut clairement être une bonne idée d'utiliser une version recompilée dans ton cas qu'une version binaire, les quelques % de gain en terme de perf valent bcp plus sur une epia qu'une machine classique ;)).
  
  Pour la lecture avec mplayer, je pense que ce qui a été dit plus haut résume bien ce qui est le plus efficace: utiliser vidix si ca marche, puis xv, en modulant avec des -framedrop ou -hardframedrop si c'est encore trop juste.
  J'ai pas essayé le réencodage avec cette machine, ca prendrait une éternité (fréquence d'horloge pas très haute, cache processeur très faible (64ko)). La meilleure solution que j'ai trouvé, c'est encore d'utiliser mon bon vieux (sic...) Athlon 1.4 pour faire ca... A priori si tu réencodes en xvid, sans trop forcer sur le bitrate, tu dois obtenir une vidéo de bonne qualité que tu pourras lire sans trop de souci avec ton epia. J'ai été assez agréablement surpris par l'efficacité du codec, que ce soit par la qualité d'encodage/décodage, que par l'utilisation cpu lors de la lecture.
  
  Ne t'inquiètes pas, tu n'es pas le seul à passer des nuits et des week-ends à tenter d'optimiser la bête ;)
  - [^] # Re: Et pourquoi pas xine ?
    
    Posté par bartman le 17 décembre 2004 à 14:58. Évalué à 2.
    
    - Sur l'Eden 800, la docpour la vidéo, VIA manque un peu de clarté, il semblerait que ce soit exactement un S3 Graphics Savage
    
    PAr contre à la lecture de la doc de mplayer, et du site d'optimisation cité plus haut, il semble que l'emploi du framebuffer est déconseillé.
    
    Apparament tu as testé " l'intérieur" de la bête, qu'à tu fait exactement ? quelle à été ta config pour la compilation du kernel ? as tu fait du tuniing ? càd modifié les perf IDE, IRQ, buffers et consors ? peut tu préciser tous les détails de ce que tu as fait stp ? (peut etre tu as fait un site où cela est expliqué ?)
    
    Pour le Xvid je vais tenter de réencoder quelques films pour essyer, bien sur sur la 2e machine du bureau, je ne suis pas Eden-addict non plus :o)
    
    Le vanilla est téléchargé, j'ai pas intégralement saisi a qui il s'adresse, puisqu'il y a aussi un patch-2.6.8.1-epia1.
    
    Apparament encore pas mal de temps à passer avec l'EPIA, mais je reste persuadé que c'est dans ces conditions difficiles que Linux peut s'exprimer.

# Documentations

Posté par gouchi (site web personnel) le 14 décembre 2004 à 21:00. Évalué à 3.

L'optimisation de MPlayer par Arpi of Ice :)
http://freshmeat.net/articles/view/747/(...)

Le bouquin chez Eyrolles :
"Home cinéma et musique sur un PC Linux"
http://www.editions-eyrolles.com/Livre/9782212114027(...)

Un site dédié au media stations sous Linux avec en autres l'utilisation de Freevo ou MythTV :
http://www.lahiette.com/biboobox/(...)

[^] # Re: Documentations

Posté par bartman le 15 décembre 2004 à 11:24. Évalué à 4.

sympa le lien Freshmeat !

je me réjouirai toujours de constater les informations qui peuvent arriver dans ce genre d' échanges, alors même si apparament ça ne se fait pas (je ne l'ai vu dans aucun journal) :

merci à tous pour vos réactions et ces informations hyper-utiles.

J'éspère aussi que cela permet de montrer un peu l'esprit du libre à travers les bonnes volontés et surtout la capacité de pouvoir mettre les mains dans le "moteur" (e.g. : recompiler ou modifier le source ). Je souhaite aussi que comme moi avec les précèdents journaux, d'autres personnes pourront se servir de ce journal comme informations, pour savoir comment faire avec une config minmaliste, l'optimisation de mplayer, du kernel, etc....

# Un truc à savoir...

Posté par ʭ ☯ le 16 décembre 2004 à 23:57. Évalué à 2.

pour ceux qui aiment à se frotter aux extrêmes limites du matériel :
- j'ai découvert par hasard que l'accélération XVideo (xv quoi) est moins efficace en grosse résolution que en résolution minimale, sur certains chips graphiques. Exemples :

- sur ATI Rage PRO avec 8Mo en 1024x768/16bpp, mplayer descend à 4fps sur une vidéo 512x384 en plein écran. Si on passe en 640x480, la même vidéo passe à 25fps sans problème.

- sur Intel i845 avec 32Mo pris dans la RAM système, en 1600x1200 l'accélération xv est carrément indisponible, faut passer en 1280x1024 pour y accéder!

Bref, xv n'équivaut pas à tout baigne ;-)

⚓ À g'Auch TOUTE! http://afdgauch.online.fr

[^] # Re: Un truc à savoir...

Posté par Psychofox (Mastodon) le 20 décembre 2004 à 13:56. Évalué à 2.

et pour info, pour ceux qui passent parune sortie télé, une petite résolution suffit. La résolution utilisée par la majoritée des DVD commerciaux est de 720x576 par exemple. Un SVCD, qui rend très bien sur une télé normale a une résolution de 480 X 576 et un VCD, dont la qualité d'image peut-être comparée à une cassette video est de seulement 352 X 288.

# C3+Sis630

Posté par WH (site web personnel) le 21 décembre 2004 à 00:13. Évalué à 1.

Salut,

Pour ma part, j'ai fait tourner sans soucis MPlayer et Totem sur un C3 cadencé à 533 Mhz avec 128 Mo de Ram (dont 16 Mo pour la carte vidéo intégrée Sis630) avec un chipset son CMI9738 et lecteur CD 48x sous ... Mandrake 10.1 et Gnome 2.6 (au fou !).

J'ai eu peur au début quand j'ai récupéré la machine, elle était sur Windows 2000 et vlc saccadait terrible, mais en remettant un driver son plus ancien, nickel aussi !

Depuis j'ai viré le C3 et l'ai remplacé par un Celeron 500 MHz et j'ai upgradé à 256 Mo de Ram sans voir de différences (sauf quelques pouillèmes au niveau des BoGoMips...).

Caractèristiques de la bestiole ici : http://www.amptron.com/html/BK630e.html(...)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.