le multithread est clairement un gain de performances... je me souviens de XMMS (à l'époque X11AMP) quand il est passé multithread, le gain de performances "apparent" était énorme. Disons que le player n'est pas forcément hyper plus rapide, mais il fonctionne beaucoup mieux en multitache (le noyau linux n'étant pas -encore- préemptable, là aussi ça a son intérêt) le résultat est appréciable: plus de "coupures" dans la lecture des DIVX, fluidité parfaite même si LICQ décide de kikooter à ce moment là... avec x11amp on a même pu tout à coup bouger la fenêtre en écoutant un mp3 ;-)
et en lisant les liens, je crois que ce n'est pas la seule chose qui motive ce fork en plus. il semble que le type veuille également permettre de changer les librairies liées à mplayer sans avoir forcément besoin de le recompiler, c'est à dire par l'ajout d'une couche d'abstraction, ce qui devrait également avoir pour conséquence de permettre à terme une distribution _binaire_ de MPlayer, ce qui est une très très bonne chose, surtout si l'on considère que le programme doit également pouvoir être utilisé par le plus grand nombre.
[^] # Re: Note du posteur
Posté par anonyme512 . En réponse à la dépêche MPlayer a forké. Évalué à 10.
et en lisant les liens, je crois que ce n'est pas la seule chose qui motive ce fork en plus. il semble que le type veuille également permettre de changer les librairies liées à mplayer sans avoir forcément besoin de le recompiler, c'est à dire par l'ajout d'une couche d'abstraction, ce qui devrait également avoir pour conséquence de permettre à terme une distribution _binaire_ de MPlayer, ce qui est une très très bonne chose, surtout si l'on considère que le programme doit également pouvoir être utilisé par le plus grand nombre.