mplayer fait :
1) lecture depuis le disque
2) decodage
3) affichage
Vu le type d'operation effectue, il est evident qu'un model multithreade est plus efficace pour ce type de soft.
Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete), decodage, puis affichage, c'est perdre du temps.
Tu peux tout a fait avoir un thread qui lit depuis le disque et stocke les buffer en RAM et d'autres threads qui s'occupent du decodage et de l'affichage pendant que l'operation d'I/O du/des buffers suivants est effectuee, ca c'est un modele qui optimise l'utilisation du CPU et qui te donne un player performant.
J'aurais presque envie d'ajouter quelque mots sur les I/O completion ports, mais je vais aller dormir un peu avant :+)
[^] # Re: MplayerXP fork de MPlayer avec support des threads
Posté par pasBill pasGates . En réponse à la dépêche Document sur le développement de mplayer. Évalué à 2.
1) lecture depuis le disque
2) decodage
3) affichage
Vu le type d'operation effectue, il est evident qu'un model multithreade est plus efficace pour ce type de soft.
Faire sequentiellement de la lecture(qui revient a s'arreter et attendre que le systeme d'I/O complete la requete), decodage, puis affichage, c'est perdre du temps.
Tu peux tout a fait avoir un thread qui lit depuis le disque et stocke les buffer en RAM et d'autres threads qui s'occupent du decodage et de l'affichage pendant que l'operation d'I/O du/des buffers suivants est effectuee, ca c'est un modele qui optimise l'utilisation du CPU et qui te donne un player performant.
J'aurais presque envie d'ajouter quelque mots sur les I/O completion ports, mais je vais aller dormir un peu avant :+)