Mopidy: Ajout de la prise en charge du streaming de sortie audio HTTP

En supposant le code suivant :

import logging
from BaseHTTPServer import BaseHTTPRequestHandler

from mopidy import get_version

logger = logging.getLogger('mopidy.outputs.http')

class StreamingHTTPRequestHandler(BaseHTTPRequestHandler):
    server_version = 'HTTPOutput/%s' % get_version()

    def do_GET(self):
        self.send_response(200)
        self.send_header('content-type', 'audio/mpeg')
        self.end_headers()

        register_fd_with_output(self.wfile.fileno())

        self.close_connection = 0

    def log_message(self, format, *args):
        logger.info(format, *args)

où register_fd_with_output() est une fonction qui émet le signal d'ajout sur le récepteur fd dans un HTTPOutput ( audioconvert ! lame ! multifdsink ) et nous avons un BaseHTTPServer.HTTPServer exécuté dans un ThreadingActor avec le StreamingHTTPRequestHandler nous devrions avoir un streaming HTTP fonctionnel.

Pour des fonctionnalités supplémentaires telles que les métadonnées, les liens suivants devraient être utiles :

• http://www.smackfu.com/stuff/programming/shoutcast.html
• http://sphere.sourceforge.net/flik/docs/streaming.html

Le code ci-dessus ne devrait probablement pas être utilisé pour résoudre ce problème. Avec l'état actuel de la base de code, nous voulons quelque chose qui s'appuie sur Cherrypy.

La première chose à faire est de créer et d'enregistrer un élément GStreamer que nous pouvons utiliser dans le paramètre OUTPUT . En utilisant les mélangeurs, le code dans les exemples #152 ou Pitivi devrait suffire pour commencer. L'élément encapsulera essentiellement un multifdsink , gérera les trucs de cerise et passera les FD entre eux.

Quant à la partie HTTP, il y a au moins des façons de s'y prendre. Le premier est probablement le plus simple, démarrez un serveur Cherrypy indépendant sur le serveur frontal et utilisez-le. Le second, celui que je pense que nous voulons, c'est d'avoir un serveur HTTP singleton partagé entre les parties frontend et streaming du code. Cette partie est actuellement la grande inconnue en ce qui me concerne.

Une fois qu'un serveur HTTP est en place, nous devons détacher le socket de cherrypy, en regardant ws4py, il semble que la définition de request.rfile.rfile._sock = None soit la solution de contournement la plus probable que nous puissions gérer. Avant de nous détacher, nous voulons probablement émettre des en-têtes, puis nous détachons et émettons le fd vers le récepteur et nous devrions diffuser en continu. Regarder comment ws4py prend en charge les sockets devrait nous permettre de comprendre les détails.

Une autre partie est légèrement inconnue si nous étendons notre API audio de base pour permettre l'émission des FD. C'est soit quelque chose de spécialisé pour ce cas, soit quelque chose de plus général qui donne accès au bac de sortie que nous utilisons.

Pourquoi je n'y ai jamais pensé plus tôt, je n'en ai aucune idée, mais en ce qui concerne le vol de sockets, nous devrions simplement utiliser socket.fromfd pour créer une nouvelle copie afin que l'original puisse être fermé sans effets néfastes.

Est-il prévu d'ajouter le streaming de sortie dans un proche avenir ?

Je sais que cela date de plusieurs mois, mais c'est la seule chose qui m'empêche de passer de la vanille MPD. J'exécute MPD sur mon serveur, qui n'a pas de haut-parleurs connectés, et je me connecte au flux HTTP à partir de divers ordinateurs/périphériques de la maison et d'ailleurs. J'adorerais voir ça à Mopidy. Et si c'est déjà là, merci de m'indiquer la bonne direction ! Je lis les manuels depuis un moment et je n'arrive pas à trouver un moyen de faire fonctionner cela.

AFAIK, il est possible d'obtenir un streaming HTTP fonctionnel à partir de Mopidy en le combinant avec Icecast et quelques hacks, documentés sur https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

Le travail est en cours sur une branche sans faille (voir #1288) qui, avec la prochaine série d'améliorations sans faille, devrait permettre à Mopidy+Icecast de fonctionner sans aucun piratage pour maintenir le flux en vie.

Je veux juste souligner que j'ai aussi un intérêt sérieux pour le streaming HTTP. Je veux l'utiliser pour écouter Spotify sur l'interface Web géniale de Moped, depuis mon serveur Web/VPN, au travail. J'étais plutôt contrarié lorsque je l'ai exécuté localement et que j'ai entendu de la musique, puis j'ai eu une tonne d'erreurs JACK lorsque j'ai essayé de l'exécuter à distance. Si je savais mieux coder, je l'essayerais moi-même. Merci!

@jodal Les problèmes que vous avez mentionnés concernant le #1288 sont-ils résolus ?

c'est-à-dire que cette partie de la documentation peut être supprimée ?

Actuellement, Mopidy ne gère pas correctement la signalisation de fin de piste et de fin de flux dans GStreamer. Cela provoque la déconnexion du flux SHOUTcast à la fin de chaque piste, le rendant tout à fait inutile. Pour plus de détails, voir #492. Vous pouvez également essayer la solution de contournement mentionnée ci-dessous.

@JohnMaguire Je ne sais pas s'il y a une section quelque part dans la documentation que nous avons oubliée car vous n'incluez pas de lien. AFAIK, la version "développer" des docs est à jour avec les changements à venir dans 2.0.

Désolé : https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

Il semble qu'il ait été mis à jour dans la version de développement de la documentation, vous avez raison : https://docs.mopidy.com/en/develop/audio/#streaming -through-icecast

Merci @jodal !

des mises à jour au cours des 2 dernières années?

des mises à jour au cours des 5 dernières années?

Non. Icecast reste la meilleure solution.

Dans le cadre de Mopidy 3, nous avons supprimé la version minimale prise en charge de GStreamer, ce qui ouvre de meilleures options pour le streaming HTTP, par exemple hlssink2. Si quelqu'un est intéressé à poursuivre cela, cela pourrait être un bon point de départ.

Snapcast est une autre solution. Il est conçu pour la lecture multiroom, mais je ne vois aucune raison pour qu'il ne puisse pas également être utilisé pour la diffusion en continu vers un seul client. Je ne l'ai pas testé, mais il semble prometteur.

Oui, j'ai utilisé Snapcast. L'utilisation d'un fifo est un peu délicate et une nouvelle méthode alternative était en cours de développement, mais la dernière fois que j'ai entendu dire que cette méthode avait ses propres problèmes. Notez également qu'il ne s'agit pas de streaming http.