Je me suis planté sur l'option de config, ça ne figure pas dans le fichier de conf, c'est juste un parametre modifiable depuis le code.
Par contre en ce qui concerne l'asf, je suis entierement d'accord,, le seek était foireux, et c'est pour ça que j'ai modifié la façon de faire, et Mike Melanson (notre grand maitre des demultiplexeurs semble ravi) : http://article.gmane.org/gmane.comp.video.xine.devel/4305(...)
Après un seek, la premiere image décodée et le premier "buffer" audio décodé n'ont pas tout à fait le meme timestamp (cette difference depend du format, de la façon de seeker du demultiplexeur, du stream). Le role du demultiplexeur est d'envoyer aux décoders audio et video des packets avec des timestamps les plus proches possible apres un seek.
La différence entre mplayer et xine, c'est que mplayer semble jouer immédiatement l'audio et la video malgré la différence de timestamp et essaye de resynchroniser progressivement (ça peut mettre plusieurs secondes dans le cas de streams asf mal foutus avec des packets audio très longs), tandis que xine est tout le temps synchronisé. Si après un seek, l'audio est en avance sur la vidéo, xine va jouer l'audio et attendre le bon moment pour afficher la video (sauf la 1ere image qui est affichée immédiatement), et c'est la latence que tu observes.
Le parametre "audio.av_sync_method" n'a rien à voir la dedans il permet de choisir quelle methode utiser pour gerer la différence de vitesse entre l'horloge de la carte audio et l'horloge systeme.
"metronom_feedback": l'horloge audio est maître, la video va suivre cette horloge
"resample": l'audio est rééchantillonné à et s'adapte à la vitesse de l'horloge système.
Le parametre "video.num_buffers" n'a rien à voir non plus là-dedans, c'est le nombre de buffers video que xine peut demultiplexer en avance (et xine n'attend pas d'avoir démultiplexé un certain nombre de buffers avant de commencer à jouer).
[^] # Re: fluidité mplayer et support faad
Posté par seedeexeen . En réponse à la dépêche Sortie de VideoLAN Client (VLC) 0.6.0. Évalué à 3.
Par contre en ce qui concerne l'asf, je suis entierement d'accord,, le seek était foireux, et c'est pour ça que j'ai modifié la façon de faire, et Mike Melanson (notre grand maitre des demultiplexeurs semble ravi) :
http://article.gmane.org/gmane.comp.video.xine.devel/4305(...)
Après un seek, la premiere image décodée et le premier "buffer" audio décodé n'ont pas tout à fait le meme timestamp (cette difference depend du format, de la façon de seeker du demultiplexeur, du stream). Le role du demultiplexeur est d'envoyer aux décoders audio et video des packets avec des timestamps les plus proches possible apres un seek.
La différence entre mplayer et xine, c'est que mplayer semble jouer immédiatement l'audio et la video malgré la différence de timestamp et essaye de resynchroniser progressivement (ça peut mettre plusieurs secondes dans le cas de streams asf mal foutus avec des packets audio très longs), tandis que xine est tout le temps synchronisé. Si après un seek, l'audio est en avance sur la vidéo, xine va jouer l'audio et attendre le bon moment pour afficher la video (sauf la 1ere image qui est affichée immédiatement), et c'est la latence que tu observes.
Le parametre "audio.av_sync_method" n'a rien à voir la dedans il permet de choisir quelle methode utiser pour gerer la différence de vitesse entre l'horloge de la carte audio et l'horloge systeme.
"metronom_feedback": l'horloge audio est maître, la video va suivre cette horloge
"resample": l'audio est rééchantillonné à et s'adapte à la vitesse de l'horloge système.
Le parametre "video.num_buffers" n'a rien à voir non plus là-dedans, c'est le nombre de buffers video que xine peut demultiplexer en avance (et xine n'attend pas d'avoir démultiplexé un certain nombre de buffers avant de commencer à jouer).
Bon voilà, j'espère que ce n'est pas trop confu.