Mopidy over HTTPで再生されるオーディオのストリームを提供した場合、HTTPストリームをサポートするMPDクライアントと、 Squeezeboxesなどのデバイスの両方で使用できます。
ストリームエンコーディングは、おそらくOggVorbisおよび/またはMP3である必要があります。
次のコードを想定します。
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シンクで追加信号を出力する関数であり、 BaseHTTPServer.HTTPServer
実行されているThreadingActor
があります。 StreamingHTTPRequestHandler
HTTPストリーミングが機能しているはずです。
メタデータなどの追加機能については、次のリンクが役立ちます。
上記のコードは、おそらくこの問題を解決するために使用されるべきではありません。 コードベースの現在の状態では、cherrypyに基づいて構築されたものが必要です。
最初に行う必要があるのは、 OUTPUT
設定で使用できるGStreamer要素を作成して登録することです。 ミキサーを使用すると、#152またはPitiviの例のコードで十分に開始できます。 要素は基本的にmultifdsink
ラップし、cherrypyのものを処理し、それらの間でFDを渡します。
HTTPの部分に関しては、少なくともそれを実行する方法があります。 最初のものがおそらく最も簡単です。フロントエンドサーバーに対して独立したcherrypyサーバーを起動し、それを使用します。 2つ目は、コードのフロントエンド部分とストリーミング部分の間でシングルトンHTTPサーバーを共有することです。 この部分は、私に関する限り、現在大きな未知数です。
HTTPサーバーを配置したら、cherrypyからソケットを切り離す必要があります。ws4pyを見ると、 request.rfile.rfile._sock = None
設定することが管理できる最も可能性の高い回避策のようです。 デタッチする前に、おそらくいくつかのヘッダーを発行したいと思うでしょう。次に、デタッチしてfdをシンクに発行し、ストリーミングする必要があります。 ws4pyがどのようにソケットを引き継ぐかを見ると、詳細を理解できるはずです。
他の部分は少し不明ですが、FDを発行できるようにコアオーディオAPIを拡張するかどうかです。 これは、その場合に特化したものか、使用している出力ビンへのアクセスを提供するより一般的なもののいずれかです。
なぜ以前にこれを考えたことがなかったのか私にはわかりませんが、ソケットを盗むことに関しては、元のコピーを悪影響なしに閉じることができるように、新しいコピーを作成するためにsocket.fromfd
を使用する必要があります。
近い将来、出力ストリーミングを追加する予定はありますか?
私はこれが数ヶ月前であることを知っています、しかしこれは私がバニラMPDから切り替えることを妨げている唯一のことです。 スピーカーが接続されていないサーバーでMPDを実行し、家中やその他の場所にあるさまざまなコンピューター/デバイスからのHTTPストリームにチューニングします。 Mopidyでこれを見てみたいです。 そして、それがすでにそこにあるなら、私を正しい方向に向けてください! しばらくマニュアルを読んでいて、これを機能させる方法を見つけることができないようです。
AFAIK https://docs.mopidy.com/en/latest/config/#streaming -through-shoutcast-icecastに記載されているIcecastといくつかのハックを組み合わせることで、MopidyからHTTPストリーミングを機能させることができます。
ギャップレスブランチ(#1288を参照)で作業が進行中であり、ギャップレスの次のラウンドと合わせて、ストリームを存続させるためのハッキングなしでMopidy + Icecastを機能させる必要があります。
私もHTTPストリーミングに真剣に興味を持っているという点でチャイムを鳴らしたいだけです。 これを使用して、仕事中のWebサーバー/ VPNから素晴らしいMopedWebインターフェイスでSpotifyを聴きたいです。 ローカルで実行して音楽を聴いたときはかなり動揺し、リモートで実行しようとすると大量のJACKエラーが発生しました。 より良いコーディング方法を知っていれば、自分で試してみます。 ありがとう!
@ jodal #1288に関してあなたが言及した問題は解決されましたか?
つまり、ドキュメントのこの部分を削除できますか?
現在、MopidyはGStreamerでトラックの終わりとストリームの終わりのシグナリングを正しく処理していません。 これにより、SHOUTcastストリームが各トラックの終わりで切断され、まったく役に立たなくなります。 詳細については、#492を参照してください。 下記の回避策を試すこともできます。
@JohnMaguireリンクが含まれていないため、ドキュメントのどこかに忘れてしまったセクションがあるかどうかはわかりません。 ドキュメントの「開発」バージョンは、2.0での今後の変更に対応しています。
過去2年間の更新はありますか?
過去5年間の更新はありますか?
いいえ。Icecastは依然として最良の解決策です。
Mopidy 3の一部として、サポートされている最小バージョンのGStreamerを追加しました。これにより、hlssink2などのHTTPストリーミングのより優れたオプションがいくつか開かれます。 誰かがこれを追求することに興味があるなら、それは始めるのに良い場所かもしれません。
スナップキャストは別のソリューションです。 マルチルーム再生用に作られていますが、シングルクライアントへのストリーミングにも使用できない理由はわかりません。 私はそれをテストしていませんが、それは有望に見えます。
はい、スナップキャストを使用しました。 fifoの使用は少し面倒で、新しい代替方法が開発されていましたが、最後に、その方法には独自の問題があると聞きました。 また、httpストリーミングではないことに注意してください。
最も参考になるコメント
過去2年間の更新はありますか?