Mopidy: Unterstützung für HTTP-Audioausgabe-Streaming hinzufügen

Angenommen der folgende Code:

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)

wobei register_fd_with_output() eine Funktion ist, die das Add-Signal auf der fd-Senke in einem HTTPOutput ( audioconvert ! lame ! multifdsink ) ausgibt und wir haben ein BaseHTTPServer.HTTPServer in einem ThreadingActor mit die StreamingHTTPRequestHandler sollten wir funktionierendes HTTP-Streaming haben.

Für zusätzliche Funktionen wie Metadaten sollten die folgenden Links nützlich sein:

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

Der obige Code sollte wahrscheinlich nicht zur Lösung dieses Problems verwendet werden. Mit dem aktuellen Stand der Codebasis wollen wir etwas, das auf Cherrypy aufbaut.

Als erstes müssen Sie ein GStreamer-Element erstellen und registrieren, das wir in der Einstellung OUTPUT . Mit den Mixern sollte der Code in #152 oder Pitivi-Beispielen ausreichen, um loszulegen. Das Element wird im Grunde ein multifdsink umhüllen, das knusprige Zeug verarbeiten und die FDs zwischen ihnen weitergeben.

Was den HTTP-Teil angeht, gibt es zumindest einige Möglichkeiten, dies zu tun. Der erste ist wahrscheinlich der einfachste, starten Sie einen unabhängigen Cherrypy-Server zum Frontend und verwenden Sie diesen. Der zweite, von dem ich denke, dass wir einen Singleton-HTTP-Server haben möchten, der zwischen dem Frontend und den Streaming-Teilen des Codes geteilt wird. Dieser Teil ist für mich derzeit die große Unbekannte.

Sobald ein HTTP-Server vorhanden ist, müssen wir den Socket von Cherrypy trennen. Wenn man sich ws4py ansieht, scheint es, dass die Einstellung von request.rfile.rfile._sock = None die wahrscheinlichste Problemumgehung ist, die wir verwalten können. Bevor wir uns trennen, möchten wir wahrscheinlich einige Header ausgeben, dann trennen wir das fd und geben es an die Senke aus, und wir sollten streamen. Wenn wir uns ansehen, wie ws4py Sockets übernimmt, sollten wir die Details herausfinden.

Ein anderer Teil, der etwas unbekannt ist, ist, ob wir unsere Kern-Audio-API erweitern, um die Ausgabe der FDs zu ermöglichen. Das ist entweder etwas Spezielles für diesen Fall oder etwas Allgemeineres, das den Zugriff auf das von uns verwendete Ausgabefach ermöglicht.

Warum ich früher nie daran gedacht habe, weiß ich nicht, aber was das Stehlen von Sockets betrifft, sollten wir einfach socket.fromfd , um eine neue Kopie zu erstellen, damit das Original ohne negative Auswirkungen geschlossen werden kann.

Gibt es Pläne, in naher Zukunft Ausgabestreaming hinzuzufügen?

Ich weiß, das ist Monate alt, aber das ist das einzige, was mich davon abhält, von Vanilla MPD zu wechseln. Ich führe MPD auf meinem Server aus, an den keine Lautsprecher angeschlossen sind, und stelle den HTTP-Stream von verschiedenen Computern/Geräten im Haus und anderswo ein. Ich würde das gerne in Mopidy sehen. Und wenn es schon da ist, weisen Sie mich bitte in die richtige Richtung! Ich lese schon seit einiger Zeit die Bedienungsanleitungen und finde keine Möglichkeit, das zum Laufen zu bringen.

AFAIK ist es möglich, funktionierendes HTTP-Streaming von Mopidy zu erhalten, indem es mit Icecast und ein paar Hacks kombiniert wird, dokumentiert unter https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

Es wird an einem lückenlosen Zweig gearbeitet (siehe #1288), der zusammen mit der nächsten Runde lückenloser Verbesserungen Mopidy+Icecast ohne Hacks zum Laufen bringen sollte, um den Stream am Leben zu erhalten.

Ich möchte nur einstimmen, dass ich auch ernsthaftes Interesse an HTTP-Streaming habe. Ich möchte damit Spotify auf der fantastischen Moped-Weboberfläche von meinem Webserver/VPN bei der Arbeit hören. War ziemlich verärgert, als ich es lokal laufen ließ und Musik hörte, und bekam dann eine Menge JACK-Fehler, als ich versuchte, es aus der Ferne auszuführen. Wenn ich besser codieren könnte, würde ich es selbst versuchen. Vielen Dank!

@jodal Sind die Probleme, die Sie in Bezug auf #1288 erwähnt haben, behoben?

Dh Kann dieser Teil der Dokumentation entfernt werden?

Derzeit verarbeitet Mopidy in GStreamer die Signalisierung am Ende des Tracks im Vergleich zum Ende des Streams nicht korrekt. Dies führt dazu, dass der SHOUTcast-Stream am Ende jedes Tracks getrennt wird, was ihn ziemlich nutzlos macht. Weitere Einzelheiten finden Sie unter #492. Sie können auch die unten erwähnte Problemumgehung ausprobieren.

@JohnMaguire Ich nicht, wenn es irgendwo in den Dokumenten einen Abschnitt gibt, den wir vergessen haben, da Sie keinen Link

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

Es scheint, dass es in der Entwicklungsversion der Dokumentation aktualisiert wurde, Sie haben Recht: https://docs.mopidy.com/en/develop/audio/#streaming -through-icecast

Danke @jodal!

irgendwelche Updates in den letzten 2 Jahren?

irgendwelche Updates in den letzten 5 Jahren?

Nein. Icecast bleibt die beste Lösung.

Als Teil von Mopidy 3 haben wir die minimal unterstützte Version von GStreamer herausgenommen, die einige bessere Optionen für HTTP-Streaming eröffnet, zB hlssink2. Wenn jemand daran interessiert ist, dies zu verfolgen, könnte dies ein guter Anfang sein.

Snapcast ist eine andere Lösung. Es ist für die Wiedergabe in mehreren Räumen gedacht, aber ich sehe keinen Grund, warum es nicht auch für das Streaming an einen einzelnen Client verwendet werden kann. Ich habe es nicht getestet, aber es sieht vielversprechend aus.

Ja, ich habe Snapcast verwendet. Die Verwendung eines Fifos ist etwas fummelig und es wurde eine neue alternative Methode entwickelt, aber zuletzt hörte ich, dass diese Methode ihre eigenen Probleme hatte. Beachten Sie auch, dass es sich nicht um HTTP-Streaming handelt.