インターネット ラジオ局用の Web サイトとモバイル アプリ (iOS、Android) を構築しようとしています。Web サイトのユーザーは自分の音楽やラジオをブロードキャストし、モバイル ユーザーはラジオ局を聞いて他のリスナーとチャットします。
1 週間検索して、Amazon EC2 上の Wowza エンジン (HLS と RTMP を使用) と SHOUTcast サーバーでプロトタイプを作成しました。
HLS の使用には 5 秒の遅延がありますが、RTMP と SHOUTcast には 2 秒の遅延があります。この結果では、RTMP または SHOUTcast を選択する必要があると思います。
しかし、RTMP と SHOUTcast が最適なプロトコルかどうかはわかりません。:(
どのプロトコルを選択すればよいですか? すべてのプラットフォームをカバーするために、さまざまなプロトコルを提供する必要がありますか?
これは非常に幅広い質問です。配布プロトコルから始めましょう。
HLS には、ユーザーが接続に最適なビットレートでストリームを取得できるという利点があります。クライアントは、再生を停止することなくシームレスにスケールアップ/ダウンできます。これはビデオの場合に特に重要ですが、オーディオの場合でも、ほとんどの地域でモバイル クライアントで 128kbit ストリームを再生できます。さまざまなビットレートを利用可能にし、ストリームの途中で品質を変更したい場合は、HLS が適切なプロトコルです。
HLS の欠点は互換性です。iOS はそれをサポートしていますが、それだけです。Android は HLS をサポートしていますが、まだバグがあります。(おそらく、Android 3.0 関係者がすべていなくなってから 1 年か 2 年後には、これはそれほど問題にはならないでしょう。) JWPlayer には、デスクトップ ユーザー向けに HLS を Flash で動作させるためのいくつかのハックがあります。
Flash ユーザーだけに関心がある場合を除き、RTMP を気にする必要はありません。
HTTP を使用した純粋なプログレッシブ ストリーミングは、私がほぼ常に選択するルートです。 すべて再生できます。(私の Palm Pilot の 12 年前のデフォルトのメディア プレーヤーでさえも。) 実装は簡単で、よく理解されています。
SHOUTcast は実質的には HTTP ですが、実装が不十分なバージョンであり、特にモバイル デバイスで互換性の問題があります。多くのクライアントを壊す応答に非標準のステータス行があります。Icecast は優れた代替手段であり、現在のプロダクションでの使用に推奨します。もう 1 つのオプションとして、私は AudioPump という独自のストリーミング サービスを作成しました。これも HTTP であり、古いハードウェア上のネイティブ Android プレーヤーなど、風変わりなモバイル クライアントとの互換性を修正するために特別に構築されています。まだ一般公開されていませんが、試してみたい場合は brad@audiopump.co までご連絡ください。
2 秒のレイテンシーが望ましいとおっしゃいました。SHOUTcast で 2 秒の遅延が発生する場合は、何か問題があります。あなたはしませんモバイル クライアントにストリーミングしている場合は特に、レイテンシを低くしたい。私は通常、最低でも 20 秒のバッファーから始めます。これは、クライアントが受信できる限りの速さでフラッシュされます。これにより、ストリームの再生をすぐに開始できるようになり (クライアント側のバッファーがいっぱいになり、デコードを開始できるようになるため)、ネットワークの状態によるバッファーのアンダーランに対する保護が提供されます。モバイル ユーザーが建物の角を歩き回り、良好な信号品質を失うことは珍しくありません。ストリームが可能な限り存続するようにするため、ドロップアウトをカバーするためにデータを既に送信している場合、ユーザーは、接続が短期間で平凡になったことを知ったり気にしたりする必要はありません。
低レイテンシが必要な場合は、完全に間違ったテクノロジを見ています。低レイテンシーについては、WebRTC をチェックしてください。
確かに、従来のインターネット ラジオの設定を微調整して遅延を減らすことはできますが、それが良い考えであることはめったにありません。
コーデックの選択は、何よりも互換性を決定するものです。MP3 は簡単に最も互換性が高く、AAC もそれほど遅れていません。AAC を使用すると、特定のビットレートで高品質のオーディオが得られます。ほとんどの人はこれを使用して、帯域幅の請求を減らします.
MP3 にはライセンス料がかかり、コーデックに何を使用しているかによっては、AAC にもライセンス料がかかる場合があります。弁護士に確認してください。私はそうではなく、ライセンスは非常に複雑です。
その他のコーデックには、Vorbis と Opus があります。Opus を使用できる場合は、ライセンスが広く開放されており、帯域幅の質が高いため、使用してください。ただし、ここでのクライアントの互換性は、Opus のキラーです。(数年後には改善されるかもしれません。) Vorbis は平凡なコーデックですが、無料でクリアです。
極端な例として、FLAC でストリーミングを行っているステーションがいくつかあります。これはロスレスのオーディオ品質ですが、中品質の MP3 ステーションの 8 倍の帯域幅を支払うことになります。FLAC over HTTP ストリーミングの互換性は現時点ではコードではありませんが、VLC では問題なく動作します。
ストリームで複数のコーデックをサポートすることは非常に一般的です。予算にもよりますが、それができない場合は MP3 が最適です。
最後に、エンコーディングについてですが、できれば非可逆コーデックから別の非可逆コーデックに移行しないでください。出力ストリームをできるだけ入力に近づけるようにしてください。オーディオを再エンコードすると、毎回品質が低下します。
ブラウザからストリーミングしているユーザーに言及しました。私は数年前に Web Audio API を使用してこのようなものを作成しました。この API では、オーディオがキャプチャされ、エンコードされて Icecast/SHOUTcast サーバーに送信されます。ここで確認してください: http://demo.audiopump.co:3000/ 仕組みの簡単な説明はこちら: https://stackoverflow.com/a/20850467/362536
とにかく、これがあなたが始めるのに役立つことを願っています。
ストレートaudio/mpeg(mp3 パケット) のストリーミングは、私が試したすべての場所で機能しました。