Ok

En poursuivant votre navigation sur ce site, vous acceptez l'utilisation de cookies. Ces derniers assurent le bon fonctionnement de nos services. En savoir plus.

système réseau

  • HLS Streaming Tips

    Il y a quelques temps que je n'avais pas posté ici. Mais je vous avais déjà fait un petit article à propos du streaming/VOD avec nginx et ffmpeg, nous allons donc dans ce petit post parler de la même chose.

    Imaginez que vous désiriez faire une petite infrastructure capable de streamer du HLS pour pas mal de client.

    Vous allez donc avoir une configuration nginx de ce type sur vos serveurs de réception client :

    application hls {
    allow publish x.x.x.x;
    deny publish all;
    allow play all;
    live on;
    hls on;
    hls_path /tmp/hls;
    }

    Seulement vous avez un petit problème : la source est un produit d'automation qui ne vous envoie que ... du MP3. Je vous laisse tester, mais au final vous n'aurez que de la vidéo, le son ne sera pas là, et oui HLS ne prend pas de MP3 !

    Il faut donc mettre votre flux en AAC.

    Les plus habitués d'entre vous l'auront deviner il faut déjà préparer un peu de ffmpeg. Nous savons donc qu'il faut garder la vidéo et transformer le son en AAC. La commande sera donc quelque chose de ce type :

    ffmpeg -i source -c:v copy -c:a libfdk_aac -f format destination

    Donc comment faire : nous allons déjà recevoir notre flux via une application RTMP classique.

            application rtmp {
                live on;
                allow publish x.x.x.x;
                deny publish all;
                allow play all;
            }

    On va ensuite faire du ffmpeg :

    ffmpeg -i rtmp://127.0.0.1/rtmp/stream -c:v copy -c:a libfdk_aac -f flv rtmp://127.0.0.1/hls/live

    Nous pouvons maintenant configurer notre application HLS comme suit :

    application hls {
    allow publish 127.0.0.1;
    deny publish all;
    allow play all;
    live on;
    hls on;
    hls_path /tmp/hls;
    }

    Attention ne faites pas ça sur une machine "faible" ffmpeg ça peut demander de la puissance de calcul.

    Et pour finaliser le tout on automatise de ffmpeg avec exec (moi je préfère en faire un service mais bon on peut faire comme ça aussi), et on push l'application HLS vers nos serveurs de restream ce qui donne :

            application rtmp {
                live on;
                allow publish x.x.x.x;
                deny publish all;
                allow play all;

                exec ffmpeg -i rtmp://127.0.0.1/rtmp/stream -c:v copy -c:a libfdk_aac -f flv rtmp://127.0.0.1/hls/live;
            }

           application hls {
                allow publish 127.0.0.1;
                deny publish all;
                allow play all;
                live on;
                hls on;
                hls_path /tmp/hls;

                push ip_restream_1;

                push ip_restream_2;
    }

    Et sur vos serveurs de restream :

           application hls {
                allow publish IP_server_source;
                deny publish all;
                allow play all;
                live on;
                hls on;
                hls_path /tmp/hls;

    }

    Et tout est bon, enfin n'oubliez pas la configuration du serveur HTTP et voilà tout sera bon vous retrouverez votre live.m3u8 prêt à lire pour vos clients :).

     

    Voilà j'espère que ça vous sera utile.

    Have Fun !

  • Faire un petit service de streaming et VoD avec nginx et ffmpeg

    Récemment j'ai été amené à faire un petit service de streaming et de VoD, je me suis donc aventuré dans ce petit monde. Je vais essayer via ce blog post de montrer quelques petites technologies et techniques permettant de monter simplement un petit service de ce style. Il s'agit d'une introduction, à vous par lasuite d'aller plus loin :).

    Le but :

    . Faire un streaming continu type WebTV mais avec des contenus connu à l'avance (playlist)

    . Faire de la VoD

    . Niveau technos : pour le "live" : un flux rtmp, un HLS. Pour la VoD : player HTML5(mp4, webm), flux rtmp.

    Pré-requis :

    • Aucun, enfin si un système GNU/Linux.

    Premier temps :

    •  Il vous faut nginx-rtmp-module : https://github.com/arut/nginx-rtmp-module/
    • Et ffmpeg, bien que certaines distributions proposent des paquets ffmpeg (ou avconv sous Debian) je vous conseille tout de même l'installation via les sources afin d'être up-to-date et d'avoir toutes les options disponibles : https://www.ffmpeg.org/

    Maintenant préparons nos vidéos :

    • On prend en entrée des vidéos .mp4
    • On veut y rajouter un petit logo : logo.png en haut à droite

    Déjà nous voulons mettre nos vidéos au format webm ... voici donc la commande :

    ffmpeg -i video.mp4 -vf "movie=logo.png [logo]; [in][logo] overlay=main_w-overlay_w-10:10 [out]" -c:v libvpx -crf 10 -b:v 1M -c:a libvorbis fazo-vibes.webm

    Explications :

    • -i : spécifie le fichier en entrée (mais ça peut être un flux, on le verra plus tard);
    • -vf : permet de filtrer les frames vidéos (dans notre cas pour y ajouter notre logo), -vf est utilisé pour des cas simples à savoir un input et un output;
    • - overlay : permet d'insérer une vidéo, ou une image, sur notre vidéo et définit sa position (je vous laisse lire la bonne doc ffmpeg sur le sujet : https://ffmpeg.org/ffmpeg-filters.html#overlay-1);
    • -c:v : codec video, en l'occurence libvpx pour du webm : http://www.webmproject.org/code/;
    • -c:a : codec audio;
    • Ensuite le video output (ou le flux si on le désire).

    Ensuite on veut aussi s'assurer que notre fichier mp4 est bien conforme afin de pouvoir être lu par un player HTML5 au besoin donc, et on veut ajouter notre petit logo aussi :) :

    ffmpeg -i video.mp4 -vf "movie=logo.png [logo]; [in][logo] overlay=main_w-overlay_w-10:10 [out]" -c:v libvpx -crf 10 -b:v 1M -c:a libvorbis fazo-vibes.webm

    Flux RTMP :

    Nous allons maintenant nous occuper de nos flux RTMP. Faisons d'abord la "VoD" (vous comprendrez pourquoi je commence par là ;)). Donc regardons notre fichier de configuration nginx.conf :

    Si elle n'exite pas déjà créons une section rtmp :

    rtmp {
        server {
            listen 1935;
            ping 30s;
            notify_method get;
        }

    }

    Ajoutons-y de quoi faire notre VoD :

    rtmp {
        server {
            listen 1935;
            ping 30s;
            notify_method get;

    application mavod {
                play /repertoire/des/videos/mp4;
            }
       }}

     Je vous conseille d'ailleurs de mettre ce répertoire vidéo accessible à votre serveur http cela permettra de les utiliser pour le player HTML5 un peu plus tard.

    Maintenant imaginons que vous voulez lire la vidéo mesdernieresvacances.mp4 qui se trouve dans /repertoire/des/videos/mp4 ... vous n'aurez qu'à consulter le flux : rtmp://ip/mavod/mesdernieresvacances.mp4

    ;)

    Passons maintenant au "live-stream" :

    D'abord configurons nginx ... tout comme pour la VoD il nous faut rajouter une "application" :

    application mawebtv {
            live on;
        }

    Attention il s'agit d'une configuration de PoC : je vous conseille par la suite pour éviter que n'importe qui ne stream via votre serveur de vous intéresser aux directives on_play et on_publish !

    Imaginons maintenant que je désire faire tourner en boucle video1.mp4, video2.mp4 et video3.mp4 sur ce feed. Faisons un petit script bash :

    while :

       do

          ffmpeg -f flv -i rtmp://127.0.0.1/mavod/video1.mp4 -c:v libx264 -b:v 5M -pix_fmt yuv420p -c:a:0 libfdk_aac -b:a:0 480k -f flv rtmp://127.0.0.1/mawebtv/live

          ffmpeg -f flv -i rtmp://127.0.0.1/mavod/video2.mp4 -c:v libx264 -b:v 5M -pix_fmt yuv420p -c:a:0 libfdk_aac -b:a:0 480k -f flv rtmp://127.0.0.1/mawebtv/live

          ffmpeg -f flv -i rtmp://127.0.0.1/mavod/video3.mp4 -c:v libx264 -b:v 5M -pix_fmt yuv420p -c:a:0 libfdk_aac -b:a:0 480k -f flv rtmp://127.0.0.1/mawebtv/live

         done

    Voilà ;) ... vous avez remarqué, j'ai changé certains codecs, dans ce cas ce n'était pas réellement nécessaire mais vous verrez que pour HLS ces changements le sont ! (par exemple de codec AAC pour le son, car HLS n'est pas compatible avec mp3 !).

    Flux HLS :

     Préparation de nginx :

    HLS est un stream HTTP il faut donc préparer notre serveur HTTP, donc dans nginx.conf :

    server {
            listen       80;
            server_name  localhost;

            location / {
                root   html;
                index  index.html index.htm;
            }

            error_page   500 502 503 504  /50x.html;
            location = /50x.html {
                root   html;
            }

        location /hls {
                types {
                        application/vnd.apple.mpegurl m3u8;
                        video/mp2t ts;
                }
                alias /tmp;
            }
    }

    Et ensuite dans la section rtmp :

    application hls {
                live on;

                hls on;
                hls_path /tmp/hls;
                hls_nested on;
        }

    Maintenant pour streamer, la même technique que pour le live rtmp mais en output : rtmp://127.0.0.1/hls/live

    Vous pouvez ensuite accéder au flux via : http://ip/hls/hls/live/index.m3u8 !!!

    Lecteur web :

    Full HTML5, c'est assez simple : pour chaque vidéo :

    <video id="our-video" width="600" height="400" controls>
        <source src="repvidmp4/video.mp4" type="video/mp4">
        <source src="repvidwebm/video.webm" type="video/webm">
            Votre navigateur ne gère pas l'élément <code>video</code>.
    </video>

    Attention pour que cela marche sous Firefox pensez à renseigner les MIME type dans un .htaccess ;)

    Pour lire des flux RTMP je vous conseille de jeter un oeil à video.js : http://www.videojs.com/

    Aller plus loin :

    Voilà vous avez la base, mais certaines choses montrés ici sont "sales" et il y a de nombreuses choses à faire avec ffmpeg, ffserver, ffplay et nginx (fonction push et pull par exemple :)). Vous pouvez aussi jeter un oeil à GStreamer et à ffserver !

    En gros je vous laisse vous amuser un peu ;)

    Have Fun !

  • /tmp/lab à la gaîté lyrique et autres ...

    Voilà quelques jours de retard pour ce blog post mais ce n'est pas si grave.

    Jeudi donc j'ai été pointé ma tête à l'atelier du /tmp/lab à la gaîté lyrique, je pensais qu'il s'agissait d'un évenement exceptionnel mais au fait pas du tout, c'est tout les jeudis à priori. Et donc l'ambiance d'un hacker space (ben genre chacun vient pour amener ce qu'il veut, et parler de ce qu'il veut, pour apprendre et partager, etc ....) dans un milieu comme la gaîté c'est déroutant mais très sympathique il n'y a pas à dire.

    Je vous invite donc à venir y faire un tour vous aussi, surtout que la semaine prochaine il y aura le Chaos Computer Club avec le /tmp/lab !!! Donc pas d'excuses !

     

    Donc de quoi est-ce que cela à parler dans la soirée :

    . De Christine Albanel : car il semblerait qu'elle était sur place, mais elle n'est pas venue nous voir (bizarrement tiens ...).

    . Des lois liberticides et stupides de la France.

    . De journalisme (y a des étudiants en SportsCom et des journalistes de Arte qui étaient sur place).

    . De performances artistiques.

    . Et de plein d'autres choses (BioHack, GSM, logiciels libres ...).

    Bref beaucoup de discussions sympathiques tout plein :).

    En résumé, j'espère pouvoir voir ce d'entre vous qui sont proches de Paris la semaine prochaine.

    Dans un autre registre : ça y est ma place au SSTIC est validée, donc rendez-vous à Rennes en Juin aussi pour ceux qui y vont.

    Ah oui en parlant de conférence, l'appel du 18 juin de la nuit du hack. Bon ok la nuit du hack c'est cool, mais les gens vous trouvez pas que vous trollez un peu trop la sur le coup ! Pour ceux qui ne l'ont pas vu c'est ici.

    1299936176318.png

    Voilà, voilà ...

    Autre petite news : le déménagement de d4 n3ws : espérons que ça tienne plus longtemps ce coup-ci :).

    Sur ceux je vous souhaite une bonne fin de soirée, et bon courage à ceux qui se lèvent tôt demain comme moi.

    Ah oui non j'allais oublié, une petite promesse à un de mes voisins d'open space, un lien faire sa vidéo non assumée :).

    D'ailleurs je ne savais qu'il existait encore des gens qui ne connaissent pas 4chan (et /b/) ...

  • Firewall next-gen ... et si on regardait ce que les gens font

    Voilà, il y a quelque temps je demandais si certains d'entre vous connaissez Palo Alto. J'ai eu l'occasion depuis de jouer avec ces petites bêbétes ... Il y a rien à dire le fonctionnement est très interessant, c'est ... comment dire ... une autre vision du firewalling. Mais je ne suis pas là pour faire non plus la pub de ce produit (oui je ne suis pas sponsorisé non plus), néanmoins si vous avez l'occasion de tester, faites le :).

    Ce qui me fait écrire cet article c'est ma paranoïa latente :) En effet quand on voit ce que l'on peut faire avec cette bête on peut se dire que ça peut craindre pour la vie privé des utilisateurs (parfois, mais je fais confiance aux RSSI et aux Directions de nos chers entreprises pour ne pas se servir de cet outils pour espionner leurs employés ... hum ...).

    Enfin bref rentrons au coeur du sujet : comme que ça fonctionne cette p'tite bête.

    PAN_Family_HR.jpg

    "Application visibility, application control and threat prevention is handled by three unique identification technologies, App-ID, User-ID, and Content-ID"

    En gros on contrôle qui transfert quoi avec quel outils. Et c'est la que cet outil se distingue des autres, finit le firewalling en pensant aux ports, maintenant on pense en terme d'applications. De quoi se faire plaisir, surtout si on veut tout savoir des habitudes de nos chers utilisateurs.

    (les screenshots qui vont suivre je les ai pris sur un boitier de test, afin de n'afficher aucune donnée utilisateur)

    Allons donc voir dans l'application control center (ACC) [on dirait une organisation de l'armée US avec un nom pareil :)] :

     

    acc-edit.png

     

    Voilà on voit les différentes "applications" (le terme n'est pas juste mais bon) qui ont été utilisées. Allons plus loin (dans SSL qui n'apparaissait pas dans le premier screen désolé, la flemme de le refaire) :

     

    accappssl-edit.png

     

    L'on voit déjà que les informations se font de plus en plus précises ... vous me direz rien d'inquiétant, ça permet même de voir si un malin de fait pas de conneries sous couvert d'une connexion HTTPS. C'est pas faux, mais voyons un peu ce dont palo alto est capable :

     

    objects-edit.png

     

    Y ouais madame michu on peut bloquer le chat facebook ... ou bien l'espionner ! Sympa non ? En plus on peut même personnaliser les applications à surveiller. Plus besoin de sondes supplémentaires ! Tout est dans le firewall (enfin si on veut l'utiliser en firewall, car on peut tout simplement le mettre en mode transparent ... et hop une jolie sonde qui fait des beaux rapports, mieux que niksun je dois l'avouer) !

    Sans oublier que ça tient la charge.

    Bref je pourrais parler des heures de palo alto, en bien comme en mal. Mais je ne suis pas là pour faire la pub de ce produit non plus.

    C'était juste un exemple parmis tant d'autres de produits qui me font psychoter parfois :D.

    Sur ceux ...