Journal Idok, petit outil pour envoyer des medias sur son XBMC

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
17
9
sept.
2014

Voilà presque… houlla 2 ans que je fais du Go (Golang) à longueur de soirée. Et dans le même temps, un collègue me pousse un peu pour me payer un raspberry-pi. Vous allez voir que ces deux sujets sont liés.

Après avoir installé mon raspberr-pi avec XBMC dessus, je m'éclate un peu à manipuler le jouet. Mais une chose me manquait. J'ai des vidéos ou des musiques que je ne veux pas forcément "ajouter à ma collection" pour les lire une seule fois. Autre souci, j'avais envie de mater le filme "tears of steel" sans le télécharger (on se clame les enfants, le film est libre), donc il fallait que je me crée un fichier "strm", poser le lient dans ce fichier, ajouter le répertoire dans la collection, ouvrir le fichier… non, sérieux là ça m'allait pas. Autant j'adore XBMC, autant j'ai besoin de faire des opération "one shot" de temps en temps.

J'ai donc regardé coté API jsonrpc. Ha ok, on peut donc contrôler XBMC comme ça… Ouais mais fallait que je serve le fichier de mon coté, un service http (python -mSimpleHTTPServer) et une ouverture de port… bon on approchait.

Puis un jour, entre deux arrachage de cheveux, je me dis "bon, allez tu prends ton vim et tu crée un truc qui fasse ça pour toi".

Et voilà comment est né "idok". Idok (kodi à l'envers, kodi étant le prochain nom de XBMC) est un binaire statique (donc pas de dépendance les amis) qui permet de faire:

  • ouverture d'un fichier local au travers un port en HTTP
  • ouverture d'un fichier local au travers un tunnel SSH (service http bindé dans le tunnel)
  • ouverture d'une vidéo youtube (à condition d'avoir installé l'add-on youtube sur XBMC)
  • ouverture d'un stream autre (rtsp, http, …)

En clair, vous allez voir la page http://metal3d.github.io/idok/ et vous suivez les indications.

La création de cet outil m'a permi de découvir un autre serveur ssh que je ne connaissais pas, dropbear. Et il m'a posé de sérieux soucis… Voir https://code.google.com/p/go/issues/detail?id=8657

Bref, il y a des build pour linux 32 et 64 bits, et deux autre build pour mac et windows dont je n'ai aucune idée de si ils fonctionnent (la honte, je teste pas windows… en même temps j'ai pas de windows… ni de mac)

En théorie, les amis, vous pouvez installer idok de cette manière:

bash <(wget https://github.com/metal3d/idok/releases/download/0.2.6/install-idok.sh -qO -)

ou

bash <(curl -L https://github.com/metal3d/idok/releases/download/0.2.6/install-idok.sh)

Ca vous proposera deux types d'installation. A vous de voir :)

Bon et si ça vous plait, parlez-en. Si vous avez un bug à me rapporter, utilisez github s'il vous plait.

Et la liste de TODO va s'agrandir, notamment la création d'une interface graphique, gérer une liste de media, et surtout, au delà de toute, une refonte pour rendre le code un peu plus maintenable (c'était parti d'un truc de base, et je suis allé plus loins que prévu)

Voilà pour ce billet.

  • # Fichiers montés à distance

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

    C'est sympa, ça. Je testerai à l'occasion.
    Par contre, en HTTP, si c'est un fichier quelconque (.avi), tu peux seeker?

    Personnellement, j'utilise sshfs (mais inversé, c'est-à-dire que la machine qui exécute la commande monte un répertoire local vers le pc XMBC distant). Du coup, sur XBMC, j'ai accès à mon PC portable.

    blog.rom1v.com

    • [^] # Re: Fichiers montés à distance

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

      Oui on peut seeker, du moins pour un fichier local. Le fait est que le package http de Golang permet de range-byte, ça marche plutôt bien.

      Pour le montage inversé, je suis d'accord, c'est pas mal, mais… ça demande un peu de configuration sur ton raspbmc/openelec ou autre. En plus, il faut que tes medias se trouvent dans un répertoire particulier (ou alors tu montes tout le home…)

      Idok est un peu plus simple, certes c'est jeune et je suis encore à la phase "je règle des soucis, j'optimise" mais il détache complètement le PC du XBMC. La configuration est quasi inexistante, c'est le point fort (mais si mais si)

      Et puis, idok, il permet de demander une ouverture de flux depuis le net (mms, rtsp, http) sans avoir à créer un ".strm".

      Bon oui ok tu me disais ça pour l'exemple… mais je suis en mode "défense de mon outil" :)

  • # promotion en dépêche ?

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

    Cela ferait une bonne dépêche, juste mon avis…

    ウィズコロナ

    • [^] # Re: promotion en dépêche ?

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

      Etant donné que je suis l'auteur, j'ai pas osé proposer "mon outil" comme ça en dépêche, et puis encore une fois, le projet n'a que 3 jours :) Il marche, mais il est peut-être un peu jeunot non ?

  • # SendToXbmc

    Posté par  . Évalué à 2.

    Ça a l'air sympa, mais ça semble faire la même chose (à part peut-être le transfert sécurisé par ssh) que SendToXbmc : https://addons.mozilla.org/en-US/firefox/addon/send-to-xbmc/
    En plus, ici c'est un plugin firefox assez user-friendly.

    Par contre ce qui pourrait-être intéressant, c'est une version pour smartphone : si je veux montrer mes photos de vacances stockées sur mon smartphone, ça peut être sympa de les envoyer sur la TV.

    • [^] # Re: SendToXbmc

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

      Oui, justement l'un des auteurs de raspbmc que j'ai contacté à cause de dropbear (serveur ssh sur raspbmc… qui m'a posé un paquet de soucis) me disait qu'il codait, lui aussi, un "plugin pour navigateur"

      J'utilise aussi un de ces plugins, je trouve ça super, vraiment, mais…

      Mais voilà, je vais sur la page de tears of steel, je veux balancer la vidéo mkv sur mon rasp. Bizarrement je trouve pas l'option… le plugin détecte une vidéo youtube (la version youtube de la vidéo en tête de page) et me la balance comme ça.

      J'ai des vidéos de screencast que je fais pour des tuto de code, de musique, etc… je veux les mater sur ma télé: le plugin refuse… Et pour cause, aucun "serveur" ne "sert" le fichier. Si j'ouvre la page "file:///dir/to/my/videos" tu comprends bien que le raspberry, de l'autre coté, ne sait pas comment y accéder.

      C'est là que idok prend le relais, il crée un serveur http et "sert" le fichier (en gérant le range byte et tout). Et comme j'ai pas envie d'ouvrir un port avec firewall-cmd, j'utilise le mode "ssh".

      Les plugins browser je suis fan, mais ça ne sert pas à la même chose :) idok est une ligne de commande que tu peux introduire dans un script.

      Ps: je me suis amusé à créer un flux RTSP avec python et gstreamer, puis j'ai fournis ça à idok dans la ligne de commande… ça marche :)

    • [^] # Re: SendToXbmc

      Posté par  (site web personnel) . Évalué à 1. Dernière modification le 21 septembre 2014 à 15:08.

      Soit dit en passant, il y a Yatse qui marche super bien sur Android, qui utilise à peu près la même méthode que Idok

  • # Intéressant

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

    Une fonctionnalité m'apparaît indispensable pour faire de ce soft le compagnon idéal de toute install de Kodi : récupérer la sortie d'une commande.

    Je pense notamment à livestreamer, qui permet comme son nom l'indique de streamer depuis tout un tas de sites là où Kodi ne propose pas les plugins correspondant (au hasard, ustream). Ainsi, livestreamer prend en paramètre un player video (VLC, MPlayer) pour afficher le stream. Pouvoir indiquer idok comme player serait vraiment une killer feature.

    Livestreamer propose bien l'option --stream-url qui renvoie, quand c'est possible, l'url du stream que l'on pourrait passer à idok, mais ce n'est pas toujours le cas (toujours au hasard, ustream).

    Bref, j'ai très envie de voir le stream HD de la Station Spatiale Internationale sur ma téloche faisant tourner Raspbmc : http://www.ustream.tv/channel/iss-hdev-payload. Cela ferait un merveilleux économiseur (?) d'écran et m'éviterait l'achat d'un aquarium.

    • [^] # Re: Intéressant

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

      Alors, idok permet de prendre des streams de pas mal de formats, rtsp, mms, http, et autres… Normalement, lancer le stream de la station spaciale devrait être assez simple. Si t'as une url, je veux bien tester de voir ce soir :)

      Encore une fois, mon outil n'a que 3 jours. L'idée, après quelques jours de boulot dessus, sera de pouvoir faire encore un peu plus de choses, tels que streamer le bureau et le son du pc ou encore par exemple.

      Je ne suis pas là pour tenter de faire mieux ou moins bien qu'un autre outil, je cherche à faire un outil léger qui permette de ne pas avoir à ouvrir des ports sur le pc, et de faire passer des medias sur ma téloche. Il existe tellement de possibilités avec pleins de logiciels…

      Mais j'accepte volontiers les remarques ;)

      • [^] # Re: Intéressant

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

        Ben justement, ça ne marche pas !

        # livestreamer --stream-url http://www.ustream.tv/channel/iss-hdev-payload 480p
error: The stream specified cannot be translated to a URL
# livestreamer --subprocess-cmdline http://www.ustream.tv/channel/iss-hdev-payload 480p
error: The stream specified cannot be translated to a command

        À noter que livestreamer propose une option --stdout pour renvoyer le stream sur la sortie standard, il devrait y avoir moyen de passer tout ça à idok via un pipe.

        • [^] # Re: Intéressant

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

          Oui je n'ai pas encore testé ce genre de chose, mais ce soir je regarde.

          Et effectivement j'ai deux options que je veux mettre en place:

          • transférer stdin à idok
          • transférer un flux de port

          Mais bon, hein, 3 jours le bébé :) laissez moi le temps :p

        • [^] # Re: Intéressant

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

          Bon j'ai regardé…

          Ustream a complètement refondu leur bouzin. Maintenant ils envoient des chunk avec reconnexion au flux sur une adresse aléatoire. Pour réussir le tour de force, la lib python rtmp s'amuse à lire le swf…

          Et comme les flux RTMP demande des réponse clientes, c'est impossible d'utiliser le flux de manière "proxifié" (stdin > tunnel). L'astuce me parait très compliqué en soit.

          Bref, j'ai une autre solution, mais qui va demander beaucoup de boulot. Je verrai ça dans la semaine. Pour l'heure je dois me préparer à la refactorisation du code en packages.

          Je tenterai de te tenir au courant.

        • [^] # Re: Intéressant

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

          Juste pour te dire que j'ai réussi à streamer le flux sur le raspberry avec idok. La branche de developpement aura un fix et je mettrai une version "pre2" pour que tu puisses me dire.

          Pour le moment, sans utiliser de tunnel, la commande est:

          livestreamer http://www.ustream.tv/channel/iss-hdev-payload 480p -Q -O | idok -target=raspbmc.local -port=8000 -stdin

          A cette heure (tardive, si si), mon poste transmet bien le flux… ce fut un peut "touchy" mais ça le fait.

          Comme quoi, on se battant un peu…

        • [^] # Re: Intéressant

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 10 septembre 2014 à 14:05.

          Tu peux tester…

          bash <(wget https://github.com/metal3d/idok/releases/download/0.2.9-alpha1/install-idok.sh -O -)
          Normalement (ssh):

          livestreamer http://www.ustream.tv/channel/iss-hdev-payload 480p -Q -O | idok -target=raspbmc.local -ssh -stdin1

          ou (local port)

          livestreamer http://www.ustream.tv/channel/iss-hdev-payload 480p -Q -O | idok -target=raspbmc.local -stdin
          Doit fonctionner…

          • [^] # Re: Intéressant

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

            En effet, ça fonctionne, même en http.

            C'est cool que idok puisse récupérer la sortie standard, avec livestreamer, youtube-dl et videoob (de weboob), ça fait déjà un paquet de sites qu'il va maintenant être possible de streamer sur XBMC Kodi.

            Sinon, tu as vu mon commentaire plus bas sur le souci avec -target ?

  • # Marche pô

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

    idok-i686 0.2.6 sous Arch Linux

    Premier lancement : Post http://ianux:login@password/jsonrpc: dial tcp 192.168.1.20:80: connection refused
    Soit, le port HTTP est non standard sur mon Raspbmc
    je relance avec -target=192.168.1.20:8010. Réponse : Unable to get local ip

    • [^] # Re: Marche pô

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

      Ha c'est dans la TODO list ça, ajouter le port de connexion à XBMC pour l'interface jsonrpc… Bon j'ai compris, ce soir je fais une nouvelle release :p

      • [^] # Re: Marche pô

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

        Voilà, j'ai créé une 0.2.8-pre pour voir si tout se passe bien.

        Tu peux l'installer comme ça:

        bash <(wget https://github.com/metal3d/idok/releases/download/0.2.8-pre/install-idok.sh -qO -)

        ou

        bash <(curl -L https://github.com/metal3d/idok/releases/download/0.2.8-pre/install-idok.sh)

        L'option à ajouter est -targetport=8080 par exemple, par défaut c'est 80.

        Normalement, ça devrait bien se passer :)

        • [^] # Re: Marche pô

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

          Je me répond encore, je suis idiot hein…

          J'ai aussi pensé que, à terme, je gèrerai un fichier de conf pour mettre les options une bonne fois pour toute quelque part. Du coup, on met l'ip, port, password et tout le bazard dans un fichier, et on utilise juste la commande "idok". Comme ça, plus d'options à taper, sauf bien sûr on s'amuse avec une autre cible…

        • [^] # Re: Marche pô

          Posté par  (site web personnel) . Évalué à 1. Dernière modification le 09 septembre 2014 à 23:08.

          une 0.2.8-pre

          le kernel a abandonné cette notation depuis le passage en 2.6 iirc.

          Je vais ressortir ma blague habituelle :

          • il y a quoi après une v0.9 ?
          • euh la 1.0 ? /o\
          • bin non, la v0.10 (et, oui, ça pète toute la numérotation par ordre alphabétique… mais on est peinard jusque la v0.99)

          Des numéros de version, ça se suit, ça n'a aucun sens en soi… c'est simplement une version suivante (comme l'a montré le passage de 2.6.42^W39 à la 3.0, pas de changement notable malgré le changement de majeur et de mineur…).

        • [^] # Re: Marche pô

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

          Ça a l'air de fonctionner. Je viens de tester avec un .ogg, ça passe. Par contre, avec un .mp4, ça crash.
          De plus, si je passe l'adresse IP (ou même raspbmc.local, je ne fais pas tourner avahi) à l'option -target, j'ai la même erreur. Il faut que je donne le nom d'hôte entré dans /etc/hosts pour que idok trouve Raspbmc.

          • [^] # Re: Marche pô

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

            Ha, alors là on entre dans un souci tordu…

            Ce que je fais, pour le moment, c'est un lookup, donc je pense que je vais devoir trouver plusieurs méthodes pour trouver ce qui peut coincer à ce niveau.

            Par contre, ce serait mieux que les rapports de bug et demandes d'améliorations passent par les "issues" de github… c'est pas que ça m'ennui, mais je peux mieux suivre l'historique et je pense que le journal DLFP est pas le meilleurs endroit (la preuve, j'avais pas vu ce commentaire :) )

            Bref, je jette un oeil ce soir. Je vais ajouter aussi un système qui check si une nouvelle version de idok est dispo… et pourquoi pas, installer le jouet automatiquement si l'utilisateur répond par "oui".

  • # DLNA

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

    Il n'y aurait pas eu moyen de passer par le DLNA ? La plupart des télés (et lecteurs blu-ray et XBMC) le gèrent. Bon, ça ne fait pas de transcodage de vidéo…

    • [^] # Re: DLNA

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

      J'ai justement passé des jours à chercher un truc viable qui ferait ça… DLNA est un truc imbuvable en soit. Je comprend bien la demande mais idok est vraiment un outil pour Kodi/XBMC, il utilise l'api jsonrpc. Pour le DLNA, faut se battre avec rygel… :)

  • # Retour d’expérience Golang

    Posté par  . Évalué à 2.

    Peux tu nous donner tes impressions sur le développement en golang.
    Ce que tu as aimé et ce que tu as moins apprécié.
    Golang m’intéresse.
    Merci ;)

    • [^] # Re: Retour d’expérience Golang

      Posté par  (site web personnel) . Évalué à 5. Dernière modification le 10 septembre 2014 à 09:32.

      Ha bha j'aime tellement que j'écris un bouquin depuis plus d'un an sur le sujet. Le Go (ou Golang pour parler language finalement) est vraiment une solution qui s'adapte à presque tout.

      Je développe un framework web avec (en cours de refonte) et je n'ai jamais eut de point qui m'ait coincé longtemps.

      On apprécie le système de "goroutine" qui simplifie le mode "concurrent" au possible, on abandonne ces foutus design pattern (non, pas de troll) et c'est compilé.

      Ce langage apporte tout ce que j'aime de Python, tout ce que j'aime de C, et n'apporte rien de ce que je déteste de Java.

      Il faut un temps d'adaptation, c'est comme tout, mais aujourd'hui je suis arrivé au point où, quand je vais développer un truc, je me dis "bon je le fais en Python ou en Go ?"

      Les points faibles sont rares… mais peuvent poser des souci de modélisation. Un de ceux là est simple: ne pas pouvoir passer de "type" aux fonctions. On s'en sort avec des factory, mais encore…

      EDIT; je ferai un réponse plus précise plus tard :)

  • # ce qui me plairait personnellement…

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

    au lieu de pouvoir envoyer un fichier ou un lien vers mon xbmc, ce qui me plairait c’est de pouvoir dirigé le son d’une appli vers xbmc. Genre directement dans les paramètres sonores, pouvoir choisir xbmc comme carte son ou pouvoir envoyer le son de rhythmbox simplement. Si seulement je savais dev…

    • [^] # Re: ce qui me plairait personnellement…

      Posté par  (site web personnel) . Évalué à 2. Dernière modification le 19 septembre 2014 à 19:56.

      Alors, pour ça, j'ai une solution que je travaille actuellement…

      De mon point de vue, ce n'est pas à Idok de le faire, mais il doit être assez large pour permettre la redirection de flux en continue vers xbmc.

      Et comme on est sous Linux, et je pense que ça doit se faire aussi sous d'autre Unix, on a gstreamer…

      Du coup je me suis penché sur la question, et voilà mon résultat.

      1 - Je choppe le nom du device pulseaudio qui sert de "monitor"

      $ pactl list | grep -A2 'Source #' | grep 'Name: .*\.monitor$' | cut -d" " -f2
      alsa_output.pci-0000_00_1b.0.analog-stereo.monitor
      2 - Je lance la commande:

      $ gst-launch-1.0 pulsesrc device=alsa_output.pci-0000_00_1b.0.analog-stereo.monitor ! audioresample ! lamemp3enc  ! filesink location=/dev/stdout | idok -stdin -target=raspbmc.local -ssh

      Et hop… j'ai le son sur mon xbmc :)

      EDIT: j'encode en mp3 parce que (je ne sais pas pourquoi encore) vorbisenc refuse de faire un stream… et rien ne démarre

Suivre le flux des commentaires

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