Mopidy: Agregue soporte para transmisión de salida de audio HTTP

Asumiendo el siguiente código:

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)

donde register_fd_with_output() es una función que emite la señal de adición en el receptor fd en un HTTPOutput ( audioconvert ! lame ! multifdsink ) y tenemos un BaseHTTPServer.HTTPServer ejecutándose en un ThreadingActor con los StreamingHTTPRequestHandler que deberíamos tener en funcionamiento la transmisión HTTP.

Para funciones adicionales como metadatos, los siguientes enlaces deberían ser útiles:

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

El código anterior probablemente no debería usarse para resolver este problema. Con el estado actual de la base del código, queremos algo que se base en cherrypy.

Lo primero que debe hacerse es crear y registrar un elemento GStreamer que podamos usar en la configuración OUTPUT . Usando los mezcladores, el código en # 152 o ejemplos de Pitivi debería ser suficiente para comenzar. Básicamente, el elemento envolverá un multifdsink , manejará las cosas cherrypy y pasará los FD entre ellos.

En cuanto a la parte HTTP, al menos hay formas de hacerlo. El primero es probablemente el más fácil, inicie un servidor cherrypy independiente para el frontend y úselo. El segundo, el que creo que queremos es tener un servidor HTTP singleton compartido entre la interfaz y las partes de transmisión del código. Esta parte es actualmente la gran incógnita en lo que a mí respecta.

Una vez que un servidor HTTP está en su lugar, necesitamos desconectar el socket de cherrypy, mirando ws4py parece que configurar request.rfile.rfile._sock = None es la solución alternativa más probable que podamos administrar. Antes de separar probablemente queramos emitir algunos encabezados, luego separamos y emitimos el fd al receptor y deberíamos estar transmitiendo. Observar cómo ws4py se hace cargo de los sockets debería permitirnos descubrir los detalles.

Otra parte que se desconoce un poco es si ampliamos nuestra API de audio central para permitir la emisión de FD. Eso es algo especializado solo para ese caso o algo más general que da acceso a la bandeja de salida que estamos usando.

Por qué nunca pensé en esto antes, no tengo idea, pero en cuanto a robar sockets, deberíamos simplemente usar socket.fromfd para crear una nueva copia para que el original pueda cerrarse sin efectos nocivos.

¿Hay planes para agregar transmisión de salida en un futuro próximo?

Sé que esto tiene meses, pero esto es lo único que me impide cambiar de MPD de vainilla. Ejecuto MPD en mi servidor, que no tiene altavoces conectados, y sintonizo la transmisión HTTP desde varias computadoras / dispositivos en la casa y en otros lugares. Me ENCANTARÍA ver esto en Mopidy. Y si ya está allí, ¡apúnteme en la dirección correcta! He estado leyendo los manuales durante un tiempo y parece que no puedo encontrar una manera de hacer que esto funcione.

AFAIK, es posible hacer funcionar la transmisión HTTP desde Mopidy combinándola con Icecast y un par de hacks, documentados en https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

Se está trabajando en una rama sin espacios (ver # 1288) que, junto con la próxima ronda de mejoras sin espacios, deberían hacer que Mopidy + Icecast funcione sin ningún truco para mantener viva la transmisión.

Solo quiero comentar que también tengo un gran interés en HTTP Streaming. Quiero usarlo para escuchar Spotify en la increíble interfaz web de Moped, desde mi servidor web / VPN, en el trabajo. Estaba bastante molesto cuando lo ejecuté localmente y escuché música, luego obtuve una tonelada de errores JACK cuando intenté ejecutarlo de forma remota. Si supiera codificar mejor, lo probaría yo mismo. ¡Gracias!

@jodal ¿Están

es decir, ¿se puede eliminar esta parte de la documentación?

Actualmente, Mopidy no maneja correctamente la señalización de final de pista frente a final de flujo en GStreamer. Esto hace que la transmisión de SHOUTcast se desconecte al final de cada pista, volviéndola bastante inútil. Para obtener más detalles, consulte el n. ° 492. También puede probar la solución alternativa que se menciona a continuación.

@JohnMaguire No lo sé si hay una sección en algún lugar de los documentos que hemos olvidado ya que no incluyes un enlace. AFAIK, la versión de "desarrollo" de los documentos está actualizada con los próximos cambios en 2.0.

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

Parece que se actualizó en la versión de desarrollo de los documentos, tiene razón: https://docs.mopidy.com/en/develop/audio/#streaming -through-icecast

¡Gracias @jodal!

alguna actualización en los últimos 2 años?

alguna actualización en los últimos 5 años?

No. Icecast sigue siendo la mejor solución.

Como parte de Mopidy 3, eliminamos la versión mínima compatible de GStreamer que abre algunas opciones mejores para la transmisión HTTP, por ejemplo, hlssink2. Si alguien está interesado en lograr esto, entonces ese podría ser un buen lugar para comenzar.

Snapcast es otra solución. Está hecho para la reproducción en varias habitaciones, pero no veo ninguna razón por la que no se pueda usar para transmitir a un solo cliente también. No lo he probado, pero parece prometedor.

Sí, he usado snapcast. El uso de un quince es un poco complicado y se estaba desarrollando un nuevo método alternativo, pero la última vez que escuché que el método tenía sus propios problemas. También tenga en cuenta que no es transmisión http.