Bon, ça parle de threads, fallait bien que je réponde :D
Comme on l'a déja dit l'utilisation de threads permet de découper un programmes en unités d'exécution parallèles. Un programme n'est pas plus rapide, (même moins puisqu'il y a + de changements de contexte), mais il sera plus réactif, par exemple le GUI fonctionnera encore pendant le chargement du fichier. Le problème étant bien sur un découpage intelligent (pas si évident que ça à faire), et la synchronisation de tout ça...
Sous BeOS par exemple, on est obligé d'avoir au moins un thread par fenêtre (en plus du thread principal), donc si une fenetre bloque, le reste fonctionne toujours (si le programme est bien écrit...) (et même on peut débuguer un thread tout en utilisant toujours les autres comme si de rien n'était, par exemple il arrive qu'app_server (l'interface graphique) plante, dans ce cas, le noyau crée un thread supplémentaire chargé de dialoguer avec le débugueur, et un dialogue est affiché, mais les autres threads fonctionnent encore, et tant qu'on ne ferme pas le dialogue ça roule :-)) De même l'explorateur (Tracker) peut planter dans une fenetre, qu'à cela ne tienne, on la met de côté et on continue.
C'est une force, mais aussi une faiblesse, car ça complique fortement le portage d'application non-multithread (venant d'UNIX), car cela impose de sérialiser les actions des threads de gestion des fenetres.
Le principal problème à mon avis des threads sous Linux est le même que sous UNIX: l'API
j'ai déja vu du code pthread... c'est affreux.
Par comparaison BeOS est enfantin à programmer (encore faut-il savoir ce qu'on fait) (et non à ce niveau là c'est du C pur, puisque ça touche au noyau).
Pour ce qui est des avantages au niveau multimédia, il est clair que c'est intéressant sur les points suivants:
- avec une bécane SMP (qq1 m'en offre une à Pâques ?), autrement on a 100% d'un CPU, les autres ne font rien, et la vidéo est sacadée, mais on peut rien faire, puisque c'est monolithique,
- au niveau de l'architecture, il est plus élégant et plus logique d'avoir un thread de décodage video, un décodage audio, un extraction fichier... ça évite d'avoir une construction du type boucle d'évènement, d'utiliser des trucs du genre select() ou poll()... par exemple pendant que l'extracteur de fichier attend un secteur du disque, on peutfaire du décodage... Egalement ça permet d'assigner des priorités différentes à chaque thread, par exemple on dit que l'audio est + important que la video (on peut dropper une frame sans que ça se voit si cpuload>100%, mais avoir une cassure dans le son c + génant), alors qu'avec un truc monolithique, si on veut pas de glitch -> prio élevée, mais vu que le décodage vidéo prend énormément de ressources et qu'on l'a mis aussi en prio élevée -> le GUI ne répond plus.
ffmpeg: c'est clair que c'est plus rapide que les codecs en DLL... et le développement des codecs (qui ne sont pourtant qu'une partie de ffmpeg) avance à grand pas... la mailing liste est en ce moment à + de 5 message par jour (y a que 3 ou 4 qui contribuent bcp, le reste étant occasionnel).
Je rappelle également que ffmpeg justement c'est _aussi_ un convertisseur de fichiers ((open)divx, mpeg1, 2, ...ASF (mais pas WMA), .rm ...) Le seul reproche c'est qu'il encode pas encore en mp3 (juste mp2, et encore y a un patch pour utiliser lame), et qu'il manque aussi le support ogg.
# threads
Posté par Francois Revol (site web personnel) . En réponse à la dépêche MPlayer a forké. Évalué à 10.
Comme on l'a déja dit l'utilisation de threads permet de découper un programmes en unités d'exécution parallèles. Un programme n'est pas plus rapide, (même moins puisqu'il y a + de changements de contexte), mais il sera plus réactif, par exemple le GUI fonctionnera encore pendant le chargement du fichier. Le problème étant bien sur un découpage intelligent (pas si évident que ça à faire), et la synchronisation de tout ça...
Sous BeOS par exemple, on est obligé d'avoir au moins un thread par fenêtre (en plus du thread principal), donc si une fenetre bloque, le reste fonctionne toujours (si le programme est bien écrit...) (et même on peut débuguer un thread tout en utilisant toujours les autres comme si de rien n'était, par exemple il arrive qu'app_server (l'interface graphique) plante, dans ce cas, le noyau crée un thread supplémentaire chargé de dialoguer avec le débugueur, et un dialogue est affiché, mais les autres threads fonctionnent encore, et tant qu'on ne ferme pas le dialogue ça roule :-)) De même l'explorateur (Tracker) peut planter dans une fenetre, qu'à cela ne tienne, on la met de côté et on continue.
C'est une force, mais aussi une faiblesse, car ça complique fortement le portage d'application non-multithread (venant d'UNIX), car cela impose de sérialiser les actions des threads de gestion des fenetres.
Le principal problème à mon avis des threads sous Linux est le même que sous UNIX: l'API
j'ai déja vu du code pthread... c'est affreux.
Par comparaison BeOS est enfantin à programmer (encore faut-il savoir ce qu'on fait) (et non à ce niveau là c'est du C pur, puisque ça touche au noyau).
Pour ce qui est des avantages au niveau multimédia, il est clair que c'est intéressant sur les points suivants:
- avec une bécane SMP (qq1 m'en offre une à Pâques ?), autrement on a 100% d'un CPU, les autres ne font rien, et la vidéo est sacadée, mais on peut rien faire, puisque c'est monolithique,
- au niveau de l'architecture, il est plus élégant et plus logique d'avoir un thread de décodage video, un décodage audio, un extraction fichier... ça évite d'avoir une construction du type boucle d'évènement, d'utiliser des trucs du genre select() ou poll()... par exemple pendant que l'extracteur de fichier attend un secteur du disque, on peutfaire du décodage... Egalement ça permet d'assigner des priorités différentes à chaque thread, par exemple on dit que l'audio est + important que la video (on peut dropper une frame sans que ça se voit si cpuload>100%, mais avoir une cassure dans le son c + génant), alors qu'avec un truc monolithique, si on veut pas de glitch -> prio élevée, mais vu que le décodage vidéo prend énormément de ressources et qu'on l'a mis aussi en prio élevée -> le GUI ne répond plus.
ffmpeg: c'est clair que c'est plus rapide que les codecs en DLL... et le développement des codecs (qui ne sont pourtant qu'une partie de ffmpeg) avance à grand pas... la mailing liste est en ce moment à + de 5 message par jour (y a que 3 ou 4 qui contribuent bcp, le reste étant occasionnel).
Je rappelle également que ffmpeg justement c'est _aussi_ un convertisseur de fichiers ((open)divx, mpeg1, 2, ...ASF (mais pas WMA), .rm ...) Le seul reproche c'est qu'il encode pas encore en mp3 (juste mp2, et encore y a un patch pour utiliser lame), et qu'il manque aussi le support ogg.