Mopidy: Adicionar suporte para streaming de saída de áudio HTTP

Supondo o seguinte 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)

onde register_fd_with_output() é uma função que emite o sinal de adição no coletor de fd em um HTTPOutput ( audioconvert ! lame ! multifdsink ) e temos um BaseHTTPServer.HTTPServer rodando em um ThreadingActor com o StreamingHTTPRequestHandler que devemos ter streaming HTTP funcionando.

Para recursos adicionais, como metadados, os links a seguir devem ser úteis:

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

O código acima provavelmente não deve ser usado para resolver esse problema. Com o estado atual da base de código, queremos algo que se baseie em cereja.

A primeira coisa que precisa ser feita é criar e registrar um elemento GStreamer que podemos usar na configuração OUTPUT . Usando os mixers, o código em # 152 ou exemplos Pitivi deve ser suficiente para começar. O elemento basicamente envolverá multifdsink , manipulando o material cereja e passando os FDs entre eles.

Quanto à parte HTTP, há pelo menos maneiras de fazer isso. O primeiro é provavelmente o mais fácil, inicie um servidor cereja independente para o front-end e use-o. O segundo, o que eu acho que queremos é ter um servidor HTTP singleton compartilhado entre o front-end e as partes de streaming do código. Esta parte é atualmente a grande incógnita para mim.

Uma vez que um servidor HTTP está instalado, precisamos desconectar o soquete de cherrypy, olhando para ws4py parece que definir request.rfile.rfile._sock = None é a solução mais provável que podemos gerenciar. Antes de desanexar, provavelmente queremos emitir alguns cabeçalhos, então desanexamos e emitimos o fd para o coletor e devemos fazer o streaming. Observar como o ws4py assume o controle dos soquetes deve nos permitir descobrir os detalhes.

Outra parte um pouco desconhecida é se estendermos nossa API de áudio principal para permitir a emissão de FDs. Isso é algo especializado apenas para esse caso ou algo mais geral que dá acesso ao compartimento de saída que estamos usando.

Não tenho ideia de por que nunca pensei nisso antes, mas quanto a roubar soquetes, devemos apenas usar socket.fromfd para criar uma nova cópia de modo que o original possa ser fechado sem efeitos nocivos.

Existem planos para adicionar streaming de saída em um futuro próximo?

Eu sei que isso tem meses, mas é a única coisa que me impede de mudar do MPD vanilla. Eu executo o MPD no meu servidor, que não tem alto-falantes conectados, e sintonizo o fluxo HTTP de vários computadores / dispositivos da casa e de outros lugares. Adoraria ver isso em Mopidy. E se já estiver lá, por favor, me indique a direção certa! Tenho lido os manuais há algum tempo e não consigo encontrar uma maneira de fazer isso funcionar.

AFAIK, é possível obter fluxo de HTTP funcional de Mopidy combinando-o com Icecast e alguns hacks, documentados em https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

O trabalho está em andamento em um branch sem intervalos (consulte # 1288) que, juntamente com a próxima rodada de melhorias sem intervalos, deve fazer o Mopidy + Icecast funcionar sem quaisquer hacks para manter o stream vivo.

Só quero alertar que também tenho sério interesse em HTTP Streaming. Eu quero usá-lo para ouvir o Spotify na incrível interface da web do Moped, do meu servidor web / VPN, no trabalho. Fiquei bastante chateado quando o executei localmente e ouvi música, então recebi uma tonelada de erros JACK quando tentei executá-lo remotamente. Se eu soubesse codificar melhor, tentaria sozinho. Obrigado!

@jodal Os problemas que você mencionou em relação ao # 1288 foram resolvidos?

ou seja, esta parte da documentação pode ser removida?

Atualmente, o Mopidy não lida corretamente com a sinalização de fim de trilha vs fim de stream no GStreamer. Isso faz com que o fluxo de SHOUTcast seja desconectado no final de cada faixa, tornando-o totalmente inútil. Para obter mais detalhes, consulte # 492. Você também pode tentar a solução alternativa mencionada abaixo.

@JohnMaguire Não sei se há uma seção em algum lugar dos documentos que esquecemos, já que você não incluiu um link. AFAIK, a versão "desenvolvida" dos documentos está atualizada com as próximas mudanças no 2.0.

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

Parece que foi atualizado na versão de desenvolvimento dos documentos, você está correto: https://docs.mopidy.com/en/develop/audio/#streaming -through-icecast

Obrigado @jodal!

alguma atualização nos últimos 2 anos?

alguma atualização nos últimos 5 anos?

Não. O Icecast continua sendo a melhor solução.

Como parte do Mopidy 3, eliminamos a versão mínima suportada do GStreamer, que abre algumas opções melhores para streaming de HTTP, por exemplo, hlssink2. Se alguém estiver interessado em prosseguir, esse pode ser um bom lugar para começar.

Snapcast é outra solução. É feito para reprodução multiroom, mas não vejo nenhuma razão para que não possa ser usado para streaming para um único cliente também. Não testei, mas parece promissor.

Sim, usei o snapcast. O uso de um fifo é um pouco complicado e um novo método alternativo estava sendo desenvolvido, mas a última vez que ouvi dizer que o método tinha seus próprios problemas. Observe também que não é streaming HTTP.