Mopidy: Добавить поддержку потоковой передачи аудиосигнала HTTP

Предполагая следующий код:

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)

где register_fd_with_output() - это функция, которая излучает сигнал добавления на приемник fd в HTTPOutput ( audioconvert ! lame ! multifdsink ), и у нас есть BaseHTTPServer.HTTPServer работающий в ThreadingActor с StreamingHTTPRequestHandler у нас должна быть работающая потоковая передача HTTP.

Для дополнительных функций, таких как метаданные, могут быть полезны следующие ссылки:

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

Приведенный выше код, вероятно, не следует использовать для решения этой проблемы. С текущим состоянием кодовой базы нам нужно что-то, построенное на Cherrypy.

Первое, что нужно сделать, это создать и зарегистрировать элемент GStreamer, который мы можем использовать в настройке OUTPUT . При использовании микшеров кода из # 152 или примеров Pitivi должно быть достаточно для начала. Элемент будет в основном обертывать multifdsink , обрабатывать вишневый материал и передавать между ними FD.

Что касается HTTP, то есть, по крайней мере, способы решить эту проблему. Первый, вероятно, самый простой, запустите независимый сервер Cherrypy для внешнего интерфейса и используйте его. Второй, который, я думаю, нам нужен, - это иметь единый HTTP-сервер, совместно используемый фронтендом и потоковой частью кода. Насколько мне известно, эта часть в настоящее время является большой неизвестностью.

Как только HTTP-сервер установлен, нам нужно отсоединить сокет от cherrypy, глядя на ws4py, кажется, что установка request.rfile.rfile._sock = None является наиболее вероятным обходным путем, с которым мы можем справиться. Перед тем, как мы отключаемся, мы, вероятно, хотим передать некоторые заголовки, затем мы отключаемся и отправляем fd в приемник, и мы должны начать потоковую передачу. Рассмотрение того, как ws4py берет на себя сокеты, должно позволить нам разобраться в деталях.

Другая часть, немного неизвестная, заключается в том, расширим ли мы наш основной аудио API, чтобы разрешить испускание FD. Это либо что-то специализированное для этого случая, либо что-то более общее, дающее доступ к используемому нами выходному лотку.

Почему я никогда не думал об этом раньше, я понятия не имею, но что касается кражи сокетов, мы должны просто использовать socket.fromfd чтобы создать новую копию, чтобы оригинал можно было закрыть без вредных последствий.

Планируется ли в ближайшем будущем добавить потоковую передачу вывода?

Я знаю, что ему уже несколько месяцев, но это единственное, что удерживает меня от перехода с ванильного MPD. Я запускаю MPD на своем сервере, к которому не подключены динамики, и настраиваюсь на HTTP-поток с различных компьютеров / устройств в доме и в других местах. Мне бы очень хотелось увидеть это в Mopidy. И если он уже там, пожалуйста, укажите мне правильное направление! Некоторое время читал руководства и, похоже, не могу найти способ заставить это работать.

AFAIK можно получить рабочую потоковую передачу HTTP из Mopidy, объединив ее с Icecast и парой хаков, задокументированных на https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

Продолжается работа над веткой без разрывов (см. №1288), которая вместе со следующим раундом улучшений без разрывов должна заставить Mopidy + Icecast работать без каких-либо взломов, чтобы поддерживать поток.

Просто хочу сказать, что я также серьезно интересуюсь HTTP Streaming. Я хочу использовать его для прослушивания Spotify через потрясающий веб-интерфейс Moped с моего веб-сервера / VPN на работе. Был довольно расстроен, когда я запустил его локально и услышал музыку, а затем получил массу JACK-ошибок, когда попытался запустить его удаленно. Если бы я знал, как лучше писать, я бы попробовал сам. Спасибо!

@jodal Решены ли проблемы, которые вы упомянули относительно # 1288?

т.е. можно эту часть документации удалить?

В настоящее время Mopidy некорректно обрабатывает сигнализацию конца трека и конца потока в GStreamer. Это приводит к отключению потока SHOUTcast в конце каждой дорожки, что делает его совершенно бесполезным. Подробнее см. # 492. Вы также можете попробовать обходной путь, упомянутый ниже.

@JohnMaguire Я не знаю, если где-то в документах есть раздел, который мы забыли, так как вы не включаете ссылку. Насколько мне известно, «разрабатываемая» версия документации актуальна с учетом предстоящих изменений в 2.0.

Извините: https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

Кажется, он был обновлен в разрабатываемой версии документов, вы правы: https://docs.mopidy.com/en/develop/audio/#streaming -through-icecast

Спасибо @jodal!

какие-либо обновления за последние 2 года?

какие-либо обновления за последние 5 лет?

Нет. Icecast остается лучшим решением.

В рамках Mopidy 3 мы удалили минимально поддерживаемую версию GStreamer, которая открывает некоторые лучшие возможности для потоковой передачи HTTP, например hlssink2. Если кто-то заинтересован в этом, то это может быть хорошим началом.

Snapcast - еще одно решение. Он предназначен для воспроизведения в нескольких помещениях, но я не вижу причин, по которым его нельзя использовать и для потоковой передачи на одного клиента. Я не тестировал, но выглядит многообещающе.

Да, я использовал снапкаст. Использование FIFO немного неудобно, и разрабатывается новый альтернативный метод, но в последний раз я слышал, что этот метод имеет свои собственные проблемы. Также обратите внимание, что это не потоковая передача по протоколу http.