Faisant parti des devs MPlayer, il y a plusieurs raisons à cela:
- "politiquement" (ce n'est pas mon avis, mais bon ...) à partir du moment ou tu as une lib, tu perds en performance (linking) et si tu veux une lib, utilises xine (mauvaise réponse ....)
- cela cache surtout le fait que MPlayer dispose d'une architecture codée par un gnou atrophié manchot et avec des moufles qui fait qu'on y retrouve une floppée de variables globales, le tout étant donc tout sauf thread-safe et donc on pourrait en faire une lib à la seule condition que personne n'utilise 2 instances de la lib en même temps (tu parles d'une condition).
- il y a un mode dit "slave", qui est d'ailleurs utilisé par les différents frontends (smplayer ...), qui correspond à une FIFO par lequel on peut envoyer des commandes de controle à un processus mplayer tournant déjà. Le GUI officiel MPlayer n'utilise pas du tout ce principe, hélas, mais se contente d'être un gros hack dans le code.
Le projet libplayer dont je parlais plus haut, initié par le projet GeeXboX, propose une API en C, thread-safe, vers différentes APIs multimedia (libxine, libvlc, gstreamer et MPlayer). Pour MPlayer nous utilisons donc le mode slave, mais en proposant une API de haut-niveau exploitable.
Chaque frontend MPlayer s'amusant à reinventer le code nécessaire à l'envoi de commandes via la FIFO et la lecture/parsing des infos de retour (stdin), il serait evidemment bien plus simple d'utiliser libplayer pour eviter de reinventer la roue.
[^] # Re: En executable standard
Posté par Benjamin Zores . En réponse à la dépêche Sortie de la GeeXboX 1.2. Évalué à 5.
- "politiquement" (ce n'est pas mon avis, mais bon ...) à partir du moment ou tu as une lib, tu perds en performance (linking) et si tu veux une lib, utilises xine (mauvaise réponse ....)
- cela cache surtout le fait que MPlayer dispose d'une architecture codée par un gnou atrophié manchot et avec des moufles qui fait qu'on y retrouve une floppée de variables globales, le tout étant donc tout sauf thread-safe et donc on pourrait en faire une lib à la seule condition que personne n'utilise 2 instances de la lib en même temps (tu parles d'une condition).
- il y a un mode dit "slave", qui est d'ailleurs utilisé par les différents frontends (smplayer ...), qui correspond à une FIFO par lequel on peut envoyer des commandes de controle à un processus mplayer tournant déjà. Le GUI officiel MPlayer n'utilise pas du tout ce principe, hélas, mais se contente d'être un gros hack dans le code.
Le projet libplayer dont je parlais plus haut, initié par le projet GeeXboX, propose une API en C, thread-safe, vers différentes APIs multimedia (libxine, libvlc, gstreamer et MPlayer). Pour MPlayer nous utilisons donc le mode slave, mais en proposant une API de haut-niveau exploitable.
Chaque frontend MPlayer s'amusant à reinventer le code nécessaire à l'envoi de commandes via la FIFO et la lecture/parsing des infos de retour (stdin), il serait evidemment bien plus simple d'utiliser libplayer pour eviter de reinventer la roue.