6

要求された 1 つの mp3 ファイルを最初から最後までストリーミングする Python サーバーを作成しようとしています。（ライブストリーミングなし）
そのストリームを任意のメディアプレーヤー（VLCなど）で再生し、再生位置を変更できる機能が欲しいです。

HTTP ストリーミングについてはよく耳にしますが、ウィキペディアの記事をいくつか読んだ後、「HTTP ストリーミング」はRTSP / RTCP / RTPなどのさまざまなストリーミング プロトコルを総称するものにすぎないように思えます。

その後、独自のプロトコルを使用してメディアをストリーミングするための独自のソフトウェア (サーバー!) であるSHOUTcastに出会いました。同様の機能を提供すると思われる別の既存のサーバー プログラムはIcecastです。
SHOUTcast と Icecast の関係についてはよくわかりませんが、あるようです。

1 つの特定のメディア ファイルをストリーミングすることは、Web ラジオのような継続的なストリームをストリーミングすることとそれほど変わらないと考えたので、最初の Webradio をググって .pls または .m3u ファイルをダウンロードしました。
どちらも基本的に、URL を含むテキストファイルでした。だから私はwiresharkを開始し、VLCをそのURLに向けました。
私が見たのは、本質的に HTTP トラフィックでした:

VLC: 

GET /schizoid HTTP/1.1

VLC:

Host: <ip>:8000
User-Agent: VLC/2.0.5 LibVLC/2.0.5
Range: bytes=0-
Connection: close
Icy-MetaData: 1

サーバーが応答しました:

HTTP/1.0 200 OK
Content-Type: audio/mpeg
icy-br:128
ice-audio-info: bitrate=128
icy-br:128
icy-description:PsyTrance 24x7
icy-genre:psytrance
icy-name:Radio Schizoid
icy-pub:1
icy-url:http://schizoid.in:8000/schizoid
Server: Icecast 2.3.2
Cache-Control: no-cache
icy-metaint:16000

次に、サーバーは mp3 ストリームと思われる生データの送信を開始します。

ウィキペディアによると、これは SHOUTcast プロトコルです。
(これが Icecast が使用するプロトコルと同じかどうかはわかりません)

しかし、閉じられた (文書化されていない) プロトコルは、ストリーミング メディアの標準にはなり得ないと考えました。
だから私の質問は、ストリーミング（特定のmp3ファイル）をPythonサーバーに統合するための最良の（最も簡単でサポートされている）方法は何ですか？
SHOUTcast プロトコルを手動で実装する必要がありますか、それとも RTP のようなものでしょうか?
（サードパーティのライブラリを使用してもかまいません）

4

1 に答える 1

5

SHOUTcast クライアント プロトコルは事実上、HTTP/1.0 と同じです。関連する唯一の違いは、応答ステータス行です。

ICY 200 OK

の代わりにHTTP/1.0、 が得られICYます。それは本当にそれです！そこからは、同じように動作します。Web ブラウザ、およびほとんどの HTTP クライアントはこれを無視します。Android と一部のブラウザはチョークしますが、ほとんどは問題ありません。HTTP/1.0 200 OKIcecast のクライアント ストリームの動作は、実際にステータス ラインに戻ることを除いて、SHOUTcast と同じです。

これらの応答ヘッダーには、ストリーム情報を含む追加のヘッダーがいくつかあることに気付きました。1 つを除くすべては、返されるデータに影響を与えない単なる追加情報です。メタデータを要求しない場合、サーバーはソースから送信されたすべてのバイトを取得し、それを各クライアントに中継するだけです (サーバー側のバッファーも少し使用します)。

リクエスト ヘッダーで を指定するIcy-MetaData: 1と、動作が少し変わります。応答では、Icy-MetaInt: 8192または同様のものを取得します。これは、8,192 バイトごとにメタデータのチャンクがあることを意味します。そのチャンクは0x00、メタデータの更新がないことを意味するだけの場合があります。のようなバイトがある場合もあります0x01。その値に 16 を掛けると、次の 16 バイトが のような ASCII メタデータであることがわかりStreamTitle: 'My Stream';StreamUrl='';ます0x00。メタデータについては、別の投稿で詳しく説明していますので、興味がある方はご覧ください。

つまり、最も一般的なストリーミング プロトコルは実際には HTTP であり、SHOUTcast/Icecast/その他の多くのサーバーは、ストリームにインターリーブされたメタデータを取得できるリクエスト ヘッダーを追加しています。メタデータを要求しない HTTP クライアントは、通常の MP3 ストリームを取得するだけで、ブラウザはこれをどこかのファイルと見なします。結局、ブラウザはデータの取得方法を気にしません。

さて、あなたは何を使うべきですか？あなたの要件:

要求された 1 つの mp3 ファイルを最初から最後までストリーミングする Python サーバーを作成しようとしています。(ライブ配信はありません)

必要なのは HTTP だけです。実際、このためにサーバーを作成する必要はありません。Apache/Nginx/何でも問題なく動作します。シンプルな HTTP サーバーです。ID でファイルを提供したい場合は、Python の出番です。その ID に基づいて、ディスクから適切なリソースを取得して取得する何かを記述します。私はこれについて RTSP を気にしません...それはあなたが必要とするものに対してあまりにも多くのオーバーヘッドであり、クライアントの互換性を損なうことになります.

そのストリームを任意のメディア プレーヤー (VLC など) で再生し、再生位置を変更できる機能が必要です。

その要件については、サーバーがrange requestsをサポートしていることを確認してください。残りはクライアントが処理します。

これをすべてまとめると

  • SHOUTcast/Icecast サーバーは、すべてのクライアントが (ほぼ) 同時に同じオーディオ ストリームを取得する「ライブ」ラジオのようなストリーム用です。
  • HTTP は、ストリーミングかどうかに関係なく、クライアントに何かを配信するための最も互換性のあるプロトコルです。
  • RTSP/RTMP/RTP および関連するすべてのプロトコルは、クライアント帯域幅の可用性に基づく可変ビットレートが重要な長時間実行またはライブ ストリームをストリーミングする場合を除き、必要ありません。(これらのプロトコルには他にも機能がありますが、これがそれらを選択する決定的な要因のようです。詳細が必要な場合は、それぞれを読むことをお勧めします。)
于 2013-05-25T13:36:27.887 に答える