VideoLAN : nouvelle série de releases

Posté par  . Modéré par Fabien Penso.
Étiquettes :
0
12
mar.
2003
Audiovisuel
L'équipe VideoLAN a sorti de nouvelles versions de son client (VLC) et de son serveur (VLS) qui permettent de diffuser en temps réel/streamer des fichiers MPEG-1, MPEG-2, MPEG-4 / DivX, des DVDs, des chaînes satellites numériques, des chaînes de la télévision numérique terrestre (pas très intéressant en France pour l'instant !) et des vidéos encodées en temps réel. La diffusion ne fait en unicast ou en multicast sur un réseau haut-débit.

VLS fonctionne sous Linux uniquement. VLC fonctionne sous Linux, Familiar Linux, Yopy/Linupy, BSD, Windows, Mac OS X, et BeOS. VLC peut aussi faire office de player multimédia comme Xine, Mplayer ou Ogle.

Aller plus loin

  • # Re: VideoLAN : nouvelle série de releases

    Posté par  (site web personnel) . Évalué à -9.

    Rha je venais juste de passer a la 0.5.1 :)

    khorben

  • # Non, là vraiment c'est trop!

    Posté par  . Évalué à 7.

    L'équipe VideoLAN a releasé
    Là c'est trop, tu pourrais pas dire "a sorti" ou "a mis à disposition", parce que "releasé" c'est vraiment horrible.

    Un peu pareil pour le "streamer" sauf que je vois pas comment le dire en français (diffuser?).
    • [^] # Re: Non, là vraiment c'est trop!

      Posté par  . Évalué à -2.

      fluxer ?
      • [^] # Re: Non, là vraiment c'est trop!

        Posté par  . Évalué à 8.

        "diffuser" me semble comvenir parfaitement et on le retrouve
        dans n'importe quel bon dictionnaire de français :)
        • [^] # Re: Non, là vraiment c'est trop!

          Posté par  (site web personnel) . Évalué à 2.

          sauf que "diffuser" ne reprend pas l'idée d'un flux continu interprété en cours de diffusion. Tu peux diffuser quelque chose qui n'est pas sous forme de "flux continu interprété en cours de diffusion" mais simplement de fichier dur à télécharger completement avant lecture.

          Le francais c'est bien ... quand on a les mots simples pour définir les concepts en question (ce qui n'est pas le cas ici, ou alors en faisant une phrase complète).
          • [^] # Re: Non, là vraiment c'est trop!

            Posté par  (site web personnel) . Évalué à 2.

            sauf que "diffuser" ne reprend pas l'idée d'un flux continu interprété en cours de diffusion.

            Et tu crois vraiment que stream reprend cette idée ???

            Diffuser en français à de nombreux sens... tout comme stream en anglais. Simplement en Français, on a tendance à réduire un terme anglais au sens qu'on lui donne en franglais !!!

            Il me semble qu'une émission de radio est difusée... tout comme la presse écrite, j'en convient.

            Il suffit de dire « difuser en temps réel » ce qui reste un anglicisme, mais assez communément admit.
  • # Re: VideoLAN : nouvelle série de releases

    Posté par  . Évalué à 8.

    Juste pour faire chier: xine va bientôt proposer le meme genre de service. Le code est pour l'instant dans une branche séparée (tag broadcast), mais va bientot etre mergé dans la branche main après relecture. A la différence de VLC, il n'y a pas un programme client et un programme serveur, le tout est dans xine-lib, qui opère soit en mode "master", soit en mode "slave" (donc support de tout ce que sait lire xine-lib). Niveau réseau, c'est moins élaboré que VLC, pour l'instant c'est du broadcast.
    • [^] # Re: VideoLAN : nouvelle série de releases

      Posté par  . Évalué à 5.

      Niveau réseau c'est du broadcast ?!???

      Euhh ... C'est pas un peu du suicide de réseau ça ?
      • [^] # Re: VideoLAN : nouvelle série de releases

        Posté par  (site web personnel) . Évalué à 10.

        C'est prévu pour fonctionner sur un LAN donc ca n'est pas si idiot.

        En broadcast un flux MP3 par exemple occupe 16ko/s de la bande passante pour tous les hôtes, quel que soit le nombre d'auditeurs réel.
        En unicast le flux n'occupe de la BP que sur les auditeurs, mais occupe N*16ko/s sur les backbones du réseau. Pour les flux video l'effet est encore plus sensible.

        Donc l'usage du broadcast peut se justifier si le pourcentage d'auditeurs est élevé où si le flux occupe trop de BP.

        vic
        • [^] # Re: VideoLAN : nouvelle série de releases

          Posté par  . Évalué à 1.

          Je ne voulais pas comparer le broadcast à l'unicast, mais bien au multicast, qui est
          a mon avis le grand interet de videolan (server).

          On a alors le schema suivant : seuls les auditeurs reçoivent le flux, et le flux n'est pas duplique sur le reseau.

          Avec du mulicast, tu peux meme envisager de diffuser des video sur du 10Mb/s (du moins avec un switch).
    • [^] # Re: VideoLAN : nouvelle série de releases

      Posté par  . Évalué à 2.

      VideoLAN a exactement la même chose avec la libvlc, qui permet de reçevoir un flux ou de le streamer !
      • [^] # Re: VideoLAN : nouvelle série de releases

        Posté par  . Évalué à 0.

        videolan server utilise libvlc ?
        • [^] # Re: VideoLAN : nouvelle série de releases

          Posté par  . Évalué à 10.

          Non, le Serveur VideoLAN (VLS) est complètement indépendant du code du Client VideoLAN (VLC). Par contre, on est entrain de développer un serveur RTSP qui utilisera libvlc pour streamer.

          C'est vrai qu'on est un peu coinçé au niveau des appellations maintenant que le Client (VLC) peut aussi faire office de serveur de streaming.... ça prête à confusion !
          • [^] # Re: VideoLAN : nouvelle série de releases

            Posté par  . Évalué à -1.

            Désolé, je ne connais pas grand chose à VideoLAN, c'est pour ça que je me suis fait pièger. Par contre je peux répondre aux questions sur xine s'il y en a. Le mode "master-slave" de xine-lib n'a pas comme but de faire un serveur rtsp.
    • [^] # Re: VideoLAN : nouvelle série de releases

      Posté par  (site web personnel) . Évalué à 5.

      Un des développeurs (un 'p' ou deux? je ne me rappelle jamais :) m'avait laissé sous-entendre au salon solutions linux qu'ils prévoyaient de ne faire qu'un seul prog qui rempalcerait vlc-client et vlc-serveur, évolution logique quand on voit tout ce que peut déja faire le client.
  • # ouéééé \o/

    Posté par  (site web personnel) . Évalué à 5.

    vraiment sympa vlc...
    pour un player non natif, je trouve qu'il s'interface à merveille avec BeOS... le gui, plus de threads qu'un player natif (faut le faire :), drag-drop... mplayer a du chemin à faire là dessus :)

    La 0.5.2 fix un problème que j'avais rapporté pour le stream de France Info ( mms://viptvr.yacast.fr/encoderfranceinfo ), et même si le wma sai Mal (sai pa Libre), ça marche nickel (Rire Et Chanson par contre tj pas).
  • # Re: VideoLAN : nouvelle série de releases

    Posté par  . Évalué à 5.

    Alexis De Lattre, membre du projet VL, et "posteur" de la news, est également l'auteur d'un très bon tutorial Linux (basé sur Debian), disponible à: http://www.via.ecp.fr/~alexis/formation-linux/
  • # Re: VideoLAN : nouvelle série de releases

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    Ca faisait longtemps que je voyais parler de Videolan ici et ailleur et suite à cette annonce, je me suis decidé de le tester.

    Et bien, c'est réellement bluffant: je lance vlc avec un divx sur une machine un peu puissant en multicast et je peux lire la video sur deux autres pc de plus faible configuration et le tout de manière synchrone.

    Je lance un petit iptraf pour voir ce que ça consomme et la je vois que ca n'occupe "que" 100 Ko/s sur mon petit Lan.

    En tout cas, bravo à l'équipe de développement !
  • # DLFPTB

    Posté par  . É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.