seedeexeen a écrit 113 commentaires

C'est un FUD ?
Comme si ogle, xine, vlc ne geraient pas les menus depuis des années...

"Both Xine and VIA developers have been working hard"

les developpeurs de xine n'ont pas bossé là dessus.
et nous ne supportons pas leur version de xine-lib.

par contre xine supporte Xvmc (l'extension de XFree).

Modestes, ça dépend, ils annoncent fièrement xine 1.0, alors que ça n'est pas prévu avant plusieurs mois.

http://www.mandrakelinux.com/en/9.2/features/(...)

Des developpeurs de plusieurs projets de lecteur video participent à ffmpeg.
Par exemple, Mike Melanson est un développeur de xine, et il ajoute pas mal de codecs et demuxers en ce moment. Son but étant de porter ce qu'il a developpé pour xine (et auparavant pour mplayer) vers ffmpeg.

pour s'en rendre compte:
http://news.gmane.org/gmane.comp.video.ffmpeg.devel(...)

Je trouve ça très facile d'accuser les threads...
Au pire c'est la création/destruction de threads en masse qui peut être un peu lente avec l'api posix sous linux.
Dire qu'Eclipse est lent à cause de l'implementation des threads sous linux, ça revient à peu près à dire qu'Eclipse s'amuse à créer 100 threads par secondes, j'ai quelques doutes...
A mon avi, l'explication est plus simple, les jvm sont developpés pour windows, puis portées sous linux, et comme dans la plupart des cas, la version portée est moins complète, moins optimisée, plus lente, etc.

Tu donnes 10 euros à quelqu'un pour qu'il t'achete ton produit à 10 euros, ç'est une façon à peine déguisée de donner le produit directement. Si ce produit ne te coute que 2 euros, et bien ça équivaut à donner 2 euros en faisant croire que tu en donnes 10.
C'est génial comme principe. Tu fais croire que t'es sympa, tu récupères presque tout ce que tu as donné, et tu enbrigades les jeunes pour qu'ils achètent vraiment tes produits plus tard.

Pour te montrer que j'apprecie ton boulot, je change de nom.
Et j'espere que tu ne vas pas changer la license de ce produit fabuleux.

Salut f1rmb,
je suis sûr que tout ça c'est pour ralentir la productivité des developpeurs linux, et d'ailleurs on dirait que ça marche pas mal. ;-)

J'ai failli oublier : certains players comme xine et mplayer possèdent aussi un parseur de fichier ASX.
Et puis, tout ce que je dis sur xine, est biensûr vrai pour tout les frontends basés sur xine-lib (totem, gxine, rhythmbox+backend xine, kaffeine, oxine...), et pas seulement pour xine-ui (à part le parseur smil ;) ).

Je précise juste que tu as au moins le choix entre mplayer, xine, vlc.
C'est les 3 players que je connaisse qui supportent au moins un des protocoles de streaming mms, qui possèdent un demultiplexeur asf, et qui savent utiliser soit les codecs win32, soit ffmpeg pour decoder le wma.
Si mes souvenirs sont bons :
mplayer et xine supportent "mms over http" et "mms over tcp"
vlc supporte "mms over tcp" et "mms over udp"

Je ne me souviens pas de ce que sais gerer avifile.
Je doute que xmms supporte tout ça.
Quant à gstreamer, je sais qu'il y a un debut de parser asf, par contre en ce qui concerne mms, aucune idée.

Je ne suis pas sûr que tu puisses faire simplement un plugin proprio pour xine. A mon avi, le plugin doit être sous GPL, et faire un dlopen() de ta lib proprio.
Le truc c'est qu'il n'y a pas de proprio dans cette histoire, puisqu'ils n'ont touché à rien à par xine-ui (et le patch est dispo), ils ont rajouté un splashscreen. La nouvelle version de xine-ui inclus aussi un splashscreen, et en plus d'après de dev de xine-ui, leur splashscreen est pourri car il consomme des ressources.

Le probleme, ce n'est pas trop par rapport aux devs de xine, à par le fait qu'on aurait bien aimé être au courant de leurs magouilles, c'est plutôt comment ils ont fait pour que celà soit légal aux US. Il y a d'autres boites qui aimeraient vendre des produits légaux basés sur xine/mplayer/ogle/vlc/etc qui fassent de la lecture de dvd cryptés.

Leur description du produit est biensûr pipo, ya pas un gramme de nouveau codec, ou de changement dans xine-lib.
Qu'est ce qu'ils y connaissent les devs de Lindows au developpement de codec, et de plugin pour xine ???

"Lindows DVD Player"
c'est xine-ui + xine-lib + libdvdcss

Avec aucun nouveau codec ou autre plugin, aucune modif à part un petit patch pour xine-ui.
la preuve : http://article.gmane.org/gmane.comp.video.xine.devel/4902(...)

C'est qui vraiment étrange, c'est qu'ils pretendent que c'est légal.
Ca interesse tout plein de monde de comprendre comment ils ont fait, c'est peut-etre juste du bluff...

lance xine-check

ouaih, mais imagine la gueule de Jayce ;-)
mais pas de pascal s'il te plait.

qui se fini par "ine", andouille ;-)

allez tu peux le dire que ça commence par un g, et que c'est en 5 lettres.

ya Jayce sur le chat ;) (le jayce de multideskos ?)
A quand le chat "multideskos ou windows" ?

http://www.mplayerhq.hu/pipermail/mplayer-users/2002-July/018454.ht(...)

Donc aucun interet.
Tous les dev de player te le diront :
helix est une vaste fumisterie.

Je me demande toujours si faut le prendre au premier ou deuxième degré. Il ne peut pas être sérieux, ce n'est pas possible, ce mec c'est le JCVD de l'informatique. Chaque nouvelle annonce surpasse la précedente ;)

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).


Bon voilà, j'espère que ce n'est pas trop confu.

J'ai aussi ce pb avec le maintient de touche, je vais alerter le developeur de xine-ui (qui lit peut-etre ces lignes d'ailleurs).
Allo Daniel ? ;-)

Il y a un truc bizarre parce que perso, j'arrive à faire à peu près 10 seeks par seconde sur mes videos sur disque dur, et ma machine n'est qu'un celeron 400 !

Le prébuffering dont je parle (c'est surement mal nommé) c'est en fait le temps laissé aux decoders audio/video pour decoder les premières frames avant que les plugins de sortie audio/video commencent à les consommer (après un seek). L'ideal étant de mettre une valeur qui soit proche du temps de decodage d'une frame. Si tu mets moins, le plugin de sortie va considérer que ta frame est en retard et va la sauter. Cette façon de faire n'est certes pas idéale mais est très simple à gérer, bien plus simple que d'attendre le rendu de la premiere frame (compte de tenu de l'architecture de xine).

Cette latence est une option de config qui doit se trouver dans ~/.xine/config, la valeur par défaut a surement changé entre la beta10 et la beta11, et ton fichier de config contient peut-etre encore la vieille valeur. Essaye de supprimer la ligne correspondante (un truc genre metronom_prebuffering), ou bien de virer le fichier de conf si tu ne tiens pas trop à tes options.

Avant la beta11, il y avait une prébufferisation trop importante (1/3 s) qui a été réduite (à environ 1/10 s), et d'autres problemes introduits lors du passage à la nouvelle api.
Ton probleme vient peut-etre d'un demultiplexeur particulier,
t'as une latence sur toutes tes videos ?
Tu utilises quoi comme sortie audio ? oss, alsa, artsd ?

t'utilises la derniere version de xine-lib ?
Je pensais avoir corrigé ce pb.