Journal Diffusion de vidéo en direct (FTP Streaming)

Posté par  .
Étiquettes : aucune
0
16
juin
2007
Hello !

J'ai inventé un moyen de diffuser de la vidéo en direct avec un simple serveur apache avec extension php.

Le principe (je schématise un peu) : Enregistrement/encodage d'une source vidéo dans un fichier -> transfert de ce fichier en continue par FTP sur un serveur Web -> Découpage par un script php pour n'envoyer que l'en-tête et les paquets les plus récents au lecteur.

Si ça vous intéresse, j'ai mis toutes les explication, schéma à l'appui et les sources (sous GPL) sur mon blog :
http://jeanmichel.lacroix.free.fr/

  • # Comme promis...

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

    Au fait, si on fait faire la même chose avec un format libre, autre que wma,

    "faut juste adapter un peu" ? :D

    • [^] # Re: Comme promis...

      Posté par  . Évalué à 1.

      Je suis parti sur du Windows Média Encodeur car il marchait bien avec la caméra et que mon collègue le connaissait déjà.

      L'encodage devrait pouvoir se faire avec VLC. Faudrait que je me plonge un peu dans le format avi (ou autre) ou que je trouve une lib python pour le faire... en tout cas, ça sera sûrement mieux documenté que le wmv.

    • [^] # Re: Comme promis...

      Posté par  . Évalué à 3.

      Je trouve aussi dommage de baser un truc libre comme ça sur des formats proprios à la ***. FFmpeg ou Gstreamer n'auraient pas pu faire l'affaire ?

      * jette un rapide coup d'oeil aux sources *

      En dehors de ça, je trouve les 5 dernières lignes de ftpstream.py particulièrement tarabiscottées :) (et c'est quoi ce +30+6 à headerSize ?)
      Mais effectivement, AMHA ça devrait vraiment pas être difficile à adapter à un format libre.
      Et en plus, je pense que toute la partie acquisition/encodage/ftpstream pourrait se faire facilement à l'aide d'une chaine gstreamer avec l'aide de gnome-vfs, genre:
      gst-launch v4l2src ! ffmpegcolorspace ! theoraenc ! oggmux ! gnomevfssink location=ftp://user:password@server/stream.ogg
      Yapuka :p

      • [^] # Re: Comme promis...

        Posté par  . Évalué à 5.

        Pourquoi tu les trouves tarabiscoté ?

        C'est vrai que le "+30+16" doit paraître un peut bizarre mais il y a une explication :
        wmainfo donne la taille de l'en-tête sans les 30 octets inutile de la fin (réservés mais non utilisés). Pour le +16, je me suis aperçu qu'il y avais encore 16 octets non documentés avant les paquets de données. Fichue doc...

  • # remplissage?

    Posté par  . Évalué à 3.

    heu, ça remplit un peu le stockage, ça, non? Comment vider régulièrement le fichier mis sur le ftp?

    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

    • [^] # Re: remplissage?

      Posté par  . Évalué à 2.

      Oui, 1Mo la minutes en 148Kbs il me semble. Le bon côté c'est qu'une fois le direct terminé, la vidéo sera immédiatement disponible en téléchargement.

      Mais si on est vraiment limité en place, on peu imaginer un système façon logrotate :
      Au bout d'une taille définie, l'envoi ftp se fait sur un autre fichier et le premier est effacé au bout d'un temps de latence pour permettre à stream.php de passer de l'un à l'autre.

  • # Mwais...

    Posté par  . Évalué à 3.

    Il y a des protocoles tels que le rtp qui restent bien plus efficaces pour ce genre d'opérations...

    Mais ton approche est intéressante, pas recommandée pour faire de la diffusion de gros volumes, mais intéressante.

    • [^] # Re: Mwais...

      Posté par  . Évalué à 4.

      Le principe est justement de faire une solution a l'arrachée avec du php+ftp.

      rtp est plus adapté mais s'il n'y avait que ca comme enjeu ! ce que du vrai streaming d'homme est capable de faire :
      - seek non pas dans le tampon, mais a distance (client qui dit au serveur "lis a partir de là maintenant") - bon le seek avant marchera moyen pour du live ;)
      - adaptation côté serveur a la bande passante du client pour éviter des tailles tampons qui explosent ou une video qui se coupe 10s toutes a chaque 5s de lecture (sans réencodage mains nécessite des codecs évolués)
      - encore mieux avec une adaptation aux débits client dynamique pour résister aux aléas de connection.
      - flux multicanal ou le client peut zapper de l'un a l'autre dans le même stream (sans reconnection) mais la ca commence a être très musclé.

      La liste n'est pas longue, mais du joli casse tête quand même :)

      • [^] # Re: Mwais...

        Posté par  . Évalué à 5.

        Au boulot, j'ai implémenté une solution streaming RTP pour diffuser la propa... euh... communication d'entreprise avec comme objectif de fournir 6000 vidéos simultanément...

        Je ne te dis pas le chantier... mais ça marche...

        Sinon le seek avant, on a essayé pour le lotto, mais ça marche pas...

      • [^] # Re: Mwais...

        Posté par  . Évalué à 2.

        adaptation côté serveur a la bande passante du client pour éviter des tailles tampons qui explosent ou une video qui se coupe 10s toutes a chaque 5s de lecture (sans réencodage mains nécessite des codecs évolués)
        Tu peux me donner les codecs ?
        Car dans toutes les solutions que j'ai vu il FALLAIT un double encodage.
        Et c'est le conteneur qui faisait le boulot.

        • [^] # Re: Mwais...

          Posté par  . Évalué à 2.

          Ha bah je me suis peut être fourvoyé, mais par exemple ce genre de choses sont possible avec le Jpeg2000 (une minute de silence pour les brevets), ou plus tu télécharges meilleure est la définition de ton image, mais tu peux commencer a afficher quelque chose dès les premiers (premières dizaines ?) de kilo octets.

          Vu que le Jpeg2000 commence a dater un poil, je suis parti du principe que des applications a la vidéo étaient déjà sorties. En tous cas pour VP6 y'a un truc intéressant (même si tu l'as sans doutes étudié) :
          «Achieves any requested data rate by choosing automatically to adjust quantization levels, adjust encoded frame dimensions, or drop frames altogether.»

  • # FTP ...

    Posté par  . Évalué à 0.

    En plus le FTP c'est un protocole moderne qui traverse bien les NAT et tout....

    • [^] # Re: FTP ...

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

      Mais non FTP c'est un protocol futuriste prévu des le debut pour ipv6 !

    • [^] # Re: FTP ...

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

      C'est vrai que SFTP commence a se faire vieux ....
      Mais je n'ai pas l'impression que Mac OS le comprenne malgré son grand âge.

      • [^] # Re: FTP ...

        Posté par  . Évalué à 1.

        ça existe encore "Mac OS" ?

        ~~>[]

Suivre le flux des commentaires

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