seedeexeen a écrit 113 commentaires

- cache
libdvdnav propose 2 algos de cache, que l'on est pas obligé d'utiliser.

- no mouse input handled [NDB: le click est supporté, mais pas les positions, et ca forcerait à le supporter pour tous les drivers de sortie]
Un peu de math à faire quand on utilise des options de zoom/crop/aspect ratio

- no still images support -> non-animated menus wont work
hehe, ça c'est plus chiant à faire. Le changement d'état des bouton nécéssite d'utiliser la meme image de fond pour l'overlay.

- no subpicture highliting support -> you can't see selection in menu
- no runtime track switching (audio, sub, etc) possible
dommage

unless these are solved (can't be - most are design issues) it won't be usable.

C'est peut-etre une des raisons pour lesquelles Arpi veut se lancer dans un autre player, ce genre de truc n'a pas été prévu au départ et maintenant il est trop tard pour tout changer.
Le support de libdvdnav dans MPlayer rique d'être une grosse magouille, idem pour la navigation des vcd.

<troll>C'est pour ça qu'il y a Ogle et xine....</troll>

Au passage Ogle n'utilise pas libdvdnav, Ogle a été la source d'inspiration de libdvdnav.
Et il n'y a plus de dvdnav ! Mais 2 projets à la place :
libdvdnav: bibliotheque indépendante utilisable par d'autre projet que xine
xine-dvdnav: plugin d'entrée xine qui utilise libdvdnav, ce plugin est directement intégré dans xine-lib depuis le début de la série 1.0* (bouton "dvd")

Pour moi, Real est incable de coder un player digne de ce nom sous linux.
Pour preuve : essayez de lire des flux Real avec les dernieres versions de MPlayer et de xine, et comparez l'utilisation cpu avec realplay.
realplayer n'utilise pas Xv et ça lui donne des perfs de merde.
Sachant que les protocoles de streaming pnm et rtsp sont aussi supportés (j'en suis sûr pour xine, je n'ai pas vérifié pour MPlayer), quel est l'intéret d'utiliser realplay ?
Le plugin netscape 4 ? gxine en propose un, et il doit y avoir l'équivalent pour MPlayer.

J'ai oublié de dire un truc pour xine cvs, la version du decoder ffmpeg qu'on utilise semble poser problème, faut le virer et utiliser les libs win32 ;-(

MPlayer utilise la version http du protocole de streaming, par defaut c'est la première solution qu'il essaye. Peut on le configurer pour le forcer à utiliser mms

xine utilise "mms over tcp" (et ne sait pas gérer la version modifiée de http par microsoft)

Il est quand même très fort ce Stallman ;-)

Pour les droits de la bande annonce, j'en ai aucune idée. En plus, aucun dévéloppeur n'était au courant de cette histoire, le responsable de la release a tranquillement décidé de rajouter cette video. Le grand chef (qui n'était pas responsable de cette release) m'a avoué qu'il n'avait pas autorisé ça.

Les vidéos qui passent mal sous xine m'interessent, t'as des exemples téléchargeables ?

La personne qui a eu cette idée nous (developpeurs) met une certaine pression...

Nan, des trucs habituels du genre : "la bande annonce est mortelle", "ils finiront jamais avant noel!", "mplayer roxor", "je vais tester tout de suite", "ça marche pas", etc.

Y a vraiment personne pour lire ma news ?

J'ai oublié de préciser que xine-ui contient maintenant un éditeur de raccourcis clavier.
On peut maintenant affecter n'importe quelle action à n'importe quelle touche sans éditer les fichiers de config.
De plus, le decodeur sorenson SVQ1 n'est pas une blague et il marche bien.

Merci pour l'encouragement.
Un truc qui prend plus de temps sur xine que sur mplayer c'est la décompression de la partie mpeg audio , mplayer utilise une bibliothèque 3-4 fois plus rapide que libmad (censée être de meilleure qualité). D'après ce que j'ai compris, ce problème sera résolu dans la prochaine version de xine où on aura le choix entre les 2 bibliothèques.

Thibaut Mattern (xine team)

Lance xine-check pour obtenir un diagnostique sur les trucs qui peuvent poser des problemes de perfs.
Ensuite, utilise Xv, pour cela lance "xine -V Xv"

L'auteur de l'article n'a pas seulement oublié mplayer, il y a aussi ogle et videolan pour les dvd.

mplayer est le player qui supporte le plus grand nombre de codec et est surement le plus stable actuellement cependant qu'est-ce-qui te permet de dire que c'est le plus économe en resources ?
Tu parles de memoire ou de cpu ?
En ce qui concerne le cpu, certains developpeurs de mplayer n'ont pas trouvé que son architecture était faite pour consommer le moins possible de cpu et c'est d'ailleurs pour cela qu'il y a eu un fork pour le rendre multithreadé (mplayer XP) comme d'autres player (xine par exemple).
As-tu comparé l'occupation cpu de mplayer et xine sur la lecture d'un dvd ou d'un divx en utilisant un driver d'affichage commun comme Xv ?

Chez moi avec un celeron 400 et une pauvre carte graphique, y a pas photo.

Pourquoi personne n'écrit de comparatif Xine vs MPlayer ?
Xine consomme nettement moins de cpu lors d'une lecture de dvd.
En plus les plugins comme dvdnav commencent a bien marcher.