C'est une version majeure puisqu'en plus des habituelles corrections de bugs, on a droit à de nouvelles interfaces skinnables, le support de Quicktime (SVQ3) grâce à la ffmpeg, un nouvel input pour les cartes d'acquisition et les webcams, la possibilité d'enregistrer à la volée en diffusant le flux et en l'affichant en local, et bien plus encore ! La liste des principales nouvelles fonctions par rapport à VLC 0.5.3 :
- nouvel input video 4 Linux pour les webcams et les cartes d'acquisition
- nouvel input CDDA pour les CD audio
- support du multicast IPv6 sous Windows et Mac OS X
- support des fichiers au format de containeur Matroska
- support de Sorenson 3 (SVQ3 et Quicktime) grâce à ffmpeg
- support des codecs Quicktime sous Mac OS X
- nouvelle interface web (HTTP) pour l'administration à distance
- interface wXWindows améliorée, désormais l'interface par défaut sous Windows
- interface skinnable améliorée, avec support X11
- amélioration des annonces SAP/SDP en IPv4 ou IPv6 (nécessite le miniSAPserver 0.2.1)
- nouvelle architecture du stream output qui autorise désormais de le chaîner et ainsi par exemple de diffuser un contenu tout en l'affichant en local
- support de la recompression à la volée (transcoding) pour le stream output, permettant par exemple de lire un flux au format MPEG2 et de le diffuser en MPEG4
Aller plus loin
- VideoLAN (6 clics)
- Télécharger VLC 0.6.0 (11 clics)
- Changelog (7 clics)
- VideoLAN Quickstart (4 clics)
# Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Goon . Évalué à 2.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Goon . Évalué à 2.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Goon . Évalué à 4.
# Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Rastaman . Évalué à -1.
Par contre je ne trouve pas le petit nom de celle-ci, « attack of the cones » étant celui de la 0.5.3
Une autre fonction ajoutée à VLC est la possibilité de lire les CD audio (CDDA)
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Goon . Évalué à 2.
En ce qui concerne le numéro de version de la news, cf mon commentaire plus haut ;)
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Rastaman . Évalué à 1.
# VLC ROXOR
Posté par Francois Revol (site web personnel) . Évalué à 9.
[^] # Re: VLC ROXOR
Posté par ceituna (site web personnel) . Évalué à 10.
Quelqu'un pour infirmer ou confirmer ?
En tout cas, nous avons encore ici une belle preuve des capacités des étudiants... Je ne dis qu'une chose :
Favorisons la créations de projets libres en projets de fin d'étude/TER/projets tut'/mgx/etc... plutôt que les projets à 0.02E qui n'intéressenet personnes... :)
# Sniffff !!
Posté par Infernal Quack (site web personnel) . Évalué à 2.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Sniffff !!
Posté par Goon . Évalué à 6.
Ceci dit l'interface skinnable est annoncée sur X11.
[^] # Re: Sniffff !!
Posté par Infernal Quack (site web personnel) . Évalué à -10.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Sniffff !!
Posté par AsMaX . Évalué à 2.
C'est plus agréable que les rapports de bugs ;)
[^] # Re: Sniffff !!
Posté par hippolyte . Évalué à 1.
[^] # Re: Sniffff !!
Posté par AsMaX . Évalué à 1.
# Concernant la version Windows
Posté par Jerome . Évalué à -2.
Il est impossible de lire correctement un fichier MPG. Pas moyen de mettre en pause au début du film ou d'aller directement au milieu du film. J'ai essayé la version 0.6 et la version 0.5.3 et c'est toujours la même chose.
Du coup je pense que je vais rester avec mon trio Media Player Classic/ZoomPlayer/BsPlayer sous windows pour lire mes fichiers vidéo (en local).
[^] # Re: Concernant la version Windows
Posté par Goon . Évalué à 10.
[^] # Re: Concernant la version Windows
Posté par Pierre Tramonson . Évalué à 4.
Ceci dit je n'ai pas testé la dernière version, dont on parle dans cette news, je vais le faire :)
[^] # Re: Concernant la version Windows
Posté par hippolyte . Évalué à 5.
Avant que je tombe sur ce bijou, j'avais énormément de problèmes avec la lecture de DVDs sous XP: lecture saccadée du son et de l'image et ce quelque soit le player soft (WinDVD, PowerDVD, WMP, nvDVD), impossible d'identifier et d'isoler l'origine de ces problèmes et apparament aucun entécédent sur le net et pis chuis tombé sur vlc; quand je pense que je me suis galéré des mois entiers avec des logiciels qui coûtent la peau du c**
Non franchement, ce logiciel mérite qu'on s'y intéresse et qu'on en aide les développeurs
[^] # Re: Concernant la version Windows
Posté par gnumdk (site web personnel) . Évalué à 10.
As tu deja entendu parler de Xine ou du Mplayer? Ce sont deux lecteurs puissant et fiable qui lisent quasiment tous les types de videos... Contrairement a ce que tu fais sous windows, j'ai pas besoin de changer de lecteur suivant la video et ca fait des mois que j'ai pas vu une video non lisible par le mplayer...
Pour Xine, c'est surement la meme chose meme si je lui reproche sont temps de lancement, sont interface horrible et le fait qu'il eprouve plus de difficultés a se deplacer dans un fichier... Sinon, il y'a aussi Totem qui utilise Xine et qui possede une interface a la Windows Media Player. M'enfin, sans gui avec des options entierement accessible depuis le clavier, je prefere le mplayer :)
Donc, tu n'as aucune raison de rester sous windows ;) xine est dans toutes les bonnes distribs et si tu veux le mplayer, je te conseille quand meme de le compiler a la main si tu veux pouvoir lire des fichier tel que le sorenson ou le ram... Tout est expliqué sur le site du mplayer...
http://www.mplayerhq.hu/homepage/design4/news.html(...)
[^] # Re: Concernant la version Windows
Posté par seedeexeen . Évalué à 8.
(console) http://xinehq.de/images/releases/aaxine.jpg(...)
(x11) http://xinehq.de/index.php/skins(...)
(gtk) http://xinehq.de/images/releases/gxine.jpg(...)
(gnome2) http://www.hadess.net/totem.php3(...)
(kde3) http://members.chello.at/kaffeine(...) (petite nouvelle)
"le fait qu'il eprouve plus de difficultés à se deplacer dans un fichier" : tu peux détailler et me donner des url de flux problématiques ?
[^] # Re: Concernant la version Windows
Posté par gnumdk (site web personnel) . Évalué à 8.
Pour l'exemple, la video kde du fosdem:
sous mplayer: => aucune erreur
Movie-Aspect is 1,25:1 - prescaling to correct movie aspect.
VO: [xv] 720x576 => 720x576 Planar YV12 [fs]
A:2594,8 V:2594,8 A-V: 0,044 ct: 0,008 64871/64871 0% 0% 0,0% 0 0 0%%
Exiting... (End of file)
Sous Xine:
demux_avi: video seek to start failed
looks like this file was encoded with (divx4/(old)xvid/opendivx) -> forcing low_delay flag
demux_avi: video seek to start failed
demux_avi: video seek to start failed
demux_avi: video seek to start failed
cela ne gene pas sur cette video, mais j'ai eu plein de probleme avec xine lors de deplacement dans le video... sur la video fosdem-kde, il est amusant de voir que si on deplace la barre de progression du debut a la fin, et qu'on essaye de repartir en arriere, on se mange une erreur: "Erreur du moteur xine, Echec du demultiplexeur, Le fichier (null) est peut etre corrompu
Loin de moins l'idée de descréditer xine(qui technologiquement est mieux foutu) mais je pense que le mplayer est bien plus légé et pour l'instant plus stable chez moi...
[^] # Re: Concernant la version Windows
Posté par seedeexeen . Évalué à 5.
[^] # fluidité mplayer et support faad
Posté par Olivier Jeannet . Évalué à 7.
Moi aussi, j'ai constaté cette différence entre xine et mplayer : mplayer est instantané à se déplacer dans un fichier (flèches gauche et droite), alors que xine met beaucoup de temps, ce que je ne m'explique pas. Du coup, je n'utilise quasiment jamais xine, sauf pour faire des ralentis, ce que ne fait pas mplayer (ou alors qu'on me détrompe, tant mieux). mplayer est vraiment super à utiliser au clavier, très réactif.
si tu veux le mplayer, je te conseille quand meme de le compiler a la main si tu veux pouvoir lire des fichier tel que le sorenson ou le ram... Tout est expliqué sur le site du mplayer...
J'ai essayé de rajouter à mplayer le support "faad" (Advanced Audio Coding) mais je n'ai pas réussi. Quelqu'un m'a envoyé une vidéo prise avec le Sony Clié et c'est au format Quicktime 6, lisible par ffmpeg pour la partie image mais pas le son. J'ai pris plusieurs archives sur le site de faad, mais soit la partie faad ne compile pas, soit mplayer se lance mais échoue avec "FAAD: Failed to initialize the decoder!". (à noter, la seule version de faad qui a compilé pour moi est la version cvs). Quelqu'un a-t-il déjà réussi ?
J'ai aussi essayé de rajouter le support faad à vlc 0.5.3 il y a 15 jours mais j'ai eu un core dump au lancement de vlc.
[^] # Re: fluidité mplayer et support faad
Posté par seedeexeen . Évalué à 6.
Je pensais avoir corrigé ce pb.
[^] # Re: fluidité mplayer et support faad
Posté par Olivier Jeannet . Évalué à 3.
Je pensais avoir corrigé ce pb.
\o/ un développeur/contributeur de xine :-)
Pour être précis, j'ai téléchargé xine-lib-1-beta12.tar.gz et xine-ui-0.9.21.tar.gz du site principal, et je les ai compilés (./configure && make) et installés ( su ; make install). J'essaie les nouvelles versions de xine régulièrement.
Au fait, je suis curieux de savoir ce qui crée cet effet de latence important au "seek", une bufferisation trop importante ?
[^] # Re: fluidité mplayer et support faad
Posté par seedeexeen . Évalué à 4.
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 ?
[^] # Re: fluidité mplayer et support faad
Posté par Olivier Jeannet . Évalué à 2.
D'ailleurs, je me demande s'il est utile de bufferiser quand la source vient d'un disque dur, voire d'un CD-ROM rapide. Si je ne m'abuse, le noyau effectue du "read-ahead" de son côté. En tous cas, il faudrait que la bufferisation soit ramenée à un délai très court lors d'appui sur les touches de déplacement (1/10 sec semble pas mal, mais on dirait que c'est insuffisant). As-tu regardé comment s'y prend mplayer ? Détail qui me revient, contrairement au cas du déplacement dans un fichier, il me semble que xine est très rapide pour passer d'un fichier à un autre, ce qui est original.
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 ?
J'ai la latence quelque soit le format je crois, mpeg ou avi/divx ou wmv. Comme sortie audio, je dois avoir alsa et oss. Pour ces questions, il faudrait que je sois devant ma machine pour en être totalement sûr. Je viens de me logguer et de faire un "xine -h" et il me dit : "Sélection du pilote audio par nom. Pilotes disponibles : null alsa oss". Pour la latence selon le type de vidéo, si je me suis trompé je te ferai une autre réponse ce soir.
[^] # Re: fluidité mplayer et support faad
Posté par seedeexeen . Évalué à 8.
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.
[^] # Re: fluidité mplayer et support faad
Posté par Olivier Jeannet . Évalué à 1.
(on parle toujours de xine)
Alors j'ai vérifié hier soir, en fait le seek est rapide, j'obtiens l'image (la nouvelle image) quasiment tout de suite, mais elle reste figée pendant un bout de temps avant de reprendre son cours. Ce bout de temps est quasiment de l'ordre de la seconde, et dépend du codec, ça va plus vite avec du mpeg que du wmv.
A noter que j'ai un Duron 1GHz, 384 M de RAM et XFree 4.2 avec l'extension Xv sur une Matrox G400 (une config respectable autrement dit).
Merci pour tes explications sur 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.
J'ai renommé le fichier de config pour voir, mais ça n'a rien changé (il a été recrée avec presque les mêmes valeurs qu'avant, j'ai fait un diff).
Il y a une option appelée "audio.av_sync_method:metronom_feedback" (# choose method to sync audio and video) mais je n'y ai pas touchée car ça ne m'a pas semblé pertinent. J'ai aussi vu "video.num_buffers:500" (# number of video buffers to allocate (higher values mean smoother playback but higher latency)), j'ai ramené le chiffre à 100 pour voir mais je n'ai vu aucune différence.
Votre avis, ô grand maître de xine ? ;-)
[^] # Re: fluidité mplayer et support faad
Posté par seedeexeen . É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.
[^] # Re: fluidité mplayer et support faad
Posté par neveruml . Évalué à 2.
xine se déplace assez rapidement, mais pas de manière continue. Si je laisse par exemple la fleche de gauche enfoncée, le deplacement va se bloquer, voir le film va recommencer au début.
Pour moi ca fait ca qu'avec les fichiers divx (mpeg et RV9 sont ok).
J'utilise une version CVS pre-beta13, et xine-ui-0.9.21
A part ce petit défaut, xine-ui est un excellent lecteur, plutot joli, et il marche très bien avec les fichiers RV9 (y compris le déplacement).
[^] # Re: fluidité mplayer et support faad
Posté par seedeexeen . Évalué à 1.
Allo Daniel ? ;-)
[^] # Re: fluidité mplayer et support faad
Posté par M . Évalué à 3.
[^] # Re: fluidité mplayer et support faad
Posté par Olivier Jeannet . Évalué à 1.
le configure la detecte bien ?
Pour être béton, j'ai carrément ré-extrait l'archive de MPlayer (la 0.90 finale), et j'ai relancé le "./configure" et tout. Il a bien détecté le faad.
Sinon, mplayer n'aurait pas changé le message que j'avais toujours eu (du genre "unable to handle faad, codec not found") et dont je voulais me passer (:-) pour celui que je rapportais ("FAAD: Failed to initialize the decoder!").
Quel type de fichier as-tu réussi à voir et qui utilise le faad ? S'il n'est pas trop gros, tu peux me l'envoyer par mail (plusieurs mégas ne me font pas peur), ou le mettre sur un FTP/HTTP et me donner l'URL par mail. Je peux de mon côté t'envoyer mon fichier, il fait 470 K.
[^] # Re: Concernant la version Windows
Posté par Jiel (site web personnel) . Évalué à 1.
# Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Yann KLIS (site web personnel) . Évalué à 3.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par analogue o/ (site web personnel) . Évalué à 3.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par AsMaX . Évalué à 2.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Yann KLIS (site web personnel) . Évalué à 1.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par AsMaX . Évalué à 3.
# Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par M . Évalué à 1.
Le support des bframe qui a été ajouté il y a quelques jours est il inclu ?
# Radio libre
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Radio libre
Posté par Rastaman . Évalué à 7.
[^] # Re: Radio libre
Posté par Jean-Marc (site web personnel) . Évalué à 1.
# Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Ludovic Gasc . Évalué à 0.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Goon . Évalué à 2.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Goon . Évalué à 2.
# Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Jiel (site web personnel) . Évalué à 1.
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Clément Stenac (site web personnel) . Évalué à 1.
Le principal problème n'est pas l'écriture initiale, mais plutôt la maintenance après. Il n'est déjà pas facile de garder une documentation en une seule langue toujours bien à jour, alors plusieurs langues, cela devient vite difficilement gérable, mais il est vrai que grâce à plusieurs contributeurs, cela devrait être plus simple.
Par contre, pour le site, rien n'est pour l'instant prévu
[^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0
Posté par Jiel (site web personnel) . Évalué à 1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.