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()是一个函数，它在 HTTPOutput ( audioconvert ! lame ! multifdsink ) 中的 fd sink 上发出 add 信号，我们有一个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来创建新副本，以便可以关闭原始副本而不会产生不良影响。

是否有计划在不久的将来添加输出流？

我知道这已经有几个月了，但这是唯一阻止我从 vanilla MPD 切换的原因。 我在我的服务器上运行 MPD，它没有连接扬声器，并从房子周围和其他地方的各种计算机/设备调谐到 HTTP 流。 我很想在 Mopidy 中看到这个。 如果它已经存在，请指出正确的方向！ 已经阅读了一段时间的手册，似乎无法找到使其工作的方法。

AFAIK 可以通过将 Mopidy 与 Icecast 和一些黑客结合来从 Mopidy 获得工作 HTTP 流，记录在https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecast

无间隙分支（参见#1288）的工作正在进行中，与下一轮无间隙改进一起应该使 Mopidy+Icecast 工作而无需任何黑客来保持流的活跃。

只是想补充一点，我对 HTTP 流也很感兴趣。 我想用它在工作时从我的网络服务器/VPN 在令人敬畏的 Moped 网络界面上收听 Spotify。 当我在本地运行它并听到音乐时感到非常沮丧，然后当我尝试远程运行它时遇到了大量的 JACK 错误。 如果我知道如何更好地编码，我会自己尝试。 谢谢！

@jodal您提到的有关 #1288 的问题是否已解决？

即这部分文档可以删除吗？

目前，Mopidy 无法正确处理 GStreamer 中的轨道结束与流结束信号。 这会导致 SHOUTcast 流在每个轨道的末尾断开连接，使其变得毫无用处。 有关更多详细信息，请参阅 #492。 您也可以尝试下面提到的解决方法。

@JohnMaguire我不知道，因为您没有包含链接，所以我们忘记了文档中的某个部分。 AFAIK 文档的“开发”版本与 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是另一种解决方案。 它是为多房间播放而设计的，但我看不出有任何理由它也不能用于流式传输到单个客户端。 我还没有测试过，但看起来很有希望。

是的，我用过 snapcast。 FIFO 的使用有点繁琐，正在开发一种新的替代方法，但最后我听说该方法有其自身的问题。 另请注意，它不是 http 流媒体。