Audiovisuel Sortie de VideoLAN Client (VLC) 0.6.0

Posté par . Modéré par Jaimé Ragnagna.
Tags :
0
24
juin
2003
Audiovisuel
La version 0.6.0 « Trevelyan » du VLC, un lecteur multimédia (MPEG 1/2/4, DivX, Xvid, Ogg, MP3, DVD, VCD, etc.) multi-plateformes (Linux, Familiar Linux, Yopy/Linupy, Windows, MacOSX, BeOS, *BSD) vient de sortir. Comme toujours, c'est du GPL. Une des particularités du VLC est d'être capable de streamer des flux MPEG 1/2/4.

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
  • # Re: Sortie de VideoLAN Client (VLC) 0.6.0

    Posté par . Évalué à  2 .

    Horreur ! J'ma gourré dans la reprise du copier-coller de l'annonce précédente : c'est bien évidemment la version 0.6.0 "Trevelyan" qui vient de sortir, pas la 0.5.3 "attack of the cones" ! Vous aurez corrigé par vous même. ;) Désolé...
  • # Re: Sortie de VideoLAN Client (VLC) 0.6.0

    Posté par (page perso) . Évalué à  -1 .

    La news parle de la version 0.5.3 alors qu'il s'agit de la 0.6.0

    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)
  • # VLC ROXOR

    Posté par (page perso) . Évalué à  9 .

    bon, à part la licence qui ne permet pas à certains projets Libres de bénéficier de son code c'est le player non natif qui s'intègre le plus à BeOS, avec des threads partout et une interface au poil.
    • [^] # Re: VLC ROXOR

      Posté par (page perso) . Évalué à  10 .

      De plus, en discutant avec les responsables du projet, ils m'ont affirmé qu'ils étaient en mesure de livrer leur première mouture sous MacOS X avant même ce dernier...

      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 (page perso) . Évalué à  2 .

    VLC has now a skinnable interface. It's only available on Windows systems and is experimental. That means it should work on Windows 2000 and has not yet been tested on Win9x/WinXP OS

    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 . Évalué à  6 .

      L'équipe manque cruellement de bêta testeurs et ils sont toujours à la recherche de bons rapports de bugs via leur interface http://bugzilla.videolan.org(...) ou sur leur mailing-lists.

      Ceci dit l'interface skinnable est annoncée sur X11.
      • [^] # Re: Sniffff !!

        Posté par (page perso) . Évalué à  -10 .

        Oui mais le gtk sapuduku :)

        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 . Évalué à  2 .

        J'ajoute que toutes les demandes de fonctionnalités sur l'interface (skins surtout) sont les bienvenues aussi dans bugzilla.
        C'est plus agréable que les rapports de bugs ;)
      • [^] # Re: Sniffff !!

        Posté par . Évalué à  1 .

        en anglais j'imagine, les rapports sur bugzilla ...
        • [^] # Re: Sniffff !!

          Posté par . Évalué à  1 .

          oui tu imagines bien ;) Ceci dit pour l'instant les développeurs qui travaillent sur les skins sont tous français, mais ce n'est pas très sympa pour les autres de poster en français.
  • # Concernant la version Windows

    Posté par (page perso) . Évalué à  -2 .

    Ne connaissant que tres peu VLC je l'installe rapidement sur ma machine. Le résultat est décevant.

    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 . Évalué à  10 .

      Etonnant, j'ai jamais eu de problèmes et VLC est connu pour être un des players les plus robustes, c'est-à-dire qui lit le mieux les flux pourris. Tu pourrai peut-être prendre 5 minutes pour leur signaler le problème, ça les aidera à améliorer leur logiciel. ;)
      • [^] # Re: Concernant la version Windows

        Posté par . Évalué à  4 .

        Effectivement il est capable de lire des vidéos un peu endommagées, c'est bien, mais je le trouve un peu capricieux pour la mise en pause / reprise de la lecture. Il y a un temps de latence désagréable.
        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 . Évalué à  5 .

        J'ai le même avis que toi.
        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 (page perso) . Évalué à  10 .

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

      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 . Évalué à  8 .

        "interface horrible" : de laquelle tu parles ?
        (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 (page perso) . Évalué à  8 .

          Pas la peine de mettre des exemples comme ca vu que je parlais de totem dans le post d'avant, tu te doutes biens que je parlais de l'interface de xine lui meme, le lecteur video, xine-ui si tu preferes...

          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...
      • [^] # fluidité mplayer et support faad

        Posté par . Évalué à  7 .

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

        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 . Évalué à  6 .

          t'utilises la derniere version de xine-lib ?
          Je pensais avoir corrigé ce pb.
          • [^] # Re: fluidité mplayer et support faad

            Posté par . Évalué à  3 .

            t'utilises la derniere version de xine-lib ?
            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 . Évalué à  4 .

              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 ?
              • [^] # Re: fluidité mplayer et support faad

                Posté par . Évalué à  2 .

                Avant la beta11, il y avait une prébufferisation trop importante (1/3 s) qui a été réduite (à environ 1/10 s),

                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 . Évalué à  8 .

                  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.
                  • [^] # Re: fluidité mplayer et support faad

                    Posté par . Évalué à  1 .

                    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 !

                    (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 . Évalué à  3 .

                      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.
              • [^] # Re: fluidité mplayer et support faad

                Posté par . Évalué à  2 .

                J'ajouterai simplement qu'avec mplayer, maintenir les touches de déplacement enfoncées ne pose aucun problème, et le déplacement est epoustouflant de rapidité.
                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 . Évalué à  1 .

                  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 ? ;-)
        • [^] # Re: fluidité mplayer et support faad

          Posté par . Évalué à  3 .

          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 ? tu as bien recompiler mplayer apres avoir installer la libfaad ? le configure la detecte bien ? chez moi ça a marché du premier coup.
          • [^] # Re: fluidité mplayer et support faad

            Posté par . Évalué à  1 .

            tu as bien recompiler mplayer apres avoir installer la libfaad ?
            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 (page perso) . Évalué à  1 .

      Etonnant comme commentaire parce que j'ai utilisé mainte fois VLC sous Windows quasiment depuis le debut de ce logiciel. Je n'ai jamais eu de problème pour lire un .mpg ou un .avi et encore moins pour faire pause/play/stop/fast fwd ou autre. Pareil pour se deplacer dans la video. Es tu sur que tu avais un vrai mpg?
  • # Re: Sortie de VideoLAN Client (VLC) 0.6.0

    Posté par (page perso) . Évalué à  3 .

    Et est-ce que sous windows on peut lire les streams MPEG4 (url de type rtsp://) avec VLC ?
  • # Re: Sortie de VideoLAN Client (VLC) 0.6.0

    Posté par . Évalué à  1 .

    - support de Sorenson 3 (SVQ3 et Quicktime) grâce à ffmpeg
    Le support des bframe qui a été ajouté il y a quelques jours est il inclu ?
  • # Radio libre

    Posté par . Évalué à  2 .

    A quand un streaming p2p pour faire sa radio depuis une ligne ADSL ?

    "La liberté de tout dire n'a d'ennemis que ceux qui veulent se réserver le droit de tout faire". "La question n'est pas de savoir si vous avez quelque chose à cacher. La question est de savoir si c'est nous qui contrôlons le gouvernement ou l'inverse

  • # Commentaire supprimé

    Posté par . Évalué à  0 .

    Ce commentaire a été supprimé par l'équipe de modération.

  • # Re: Sortie de VideoLAN Client (VLC) 0.6.0

    Posté par (page perso) . Évalué à  1 .

    Un seul reproche que j'ai a faire a Videolan: bien qu'il soit développé essentiellement par l'Ecole Centrale de Paris, leur site et leur documentation sont uniquement en anglais. On comprend qu'ils ont voulu aller au plus rapide et au plus international possible, mais c'est dommage. Surtout qu'en tant que francais, ce ne serait peut etre pas tres compliqué d'ecrire en francais.
    • [^] # Re: Sortie de VideoLAN Client (VLC) 0.6.0

      Posté par (page perso) . Évalué à  1 .

      C'est progressivement en train de changer: la FAQ est désormais traduite en francais, et le reste de la doc le sera probablement bientôt (j'ai dit probablement, hein :).

      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

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.