私は、ライブオーディオストリーミングサービスを作りたいと思っていました。今はこれが難しいと言いますが、すでにそこにあるサービスを使うべきです。私は実際にこれを実際に地上からどうやって行うのかについての素敵なことを本当に知りたいです。私はいくつかの調査をしましたが、私が見つけた結果は非常に曖昧でした。あるいは私をWowzaのようなものに誘導しました。私はHTTPライブストリーミングについていくつかのことを見てきました。私は一般的な考え方を理解していると思います。マイク/カメラはそのフィードをエンコーダに送り、エンコーダはフィードをm3u8形式でサーバーに送り、人々はm3u8ファイルをサーバーをデバイスに接続します。しかし、どうやってこれを実際にやっていくのですか？これの背後にある実際のプログラミングは何ですか？ WowzaやRed5のようなサービスを使う必要がありますか？ライブオーディオストリーミングウェブサイトの作成方法？
私はいくつかの研究を行ってきたが、私が見つけた結果が
残念ながら非常に漠然としていた、あなたがあいまいな答えを得ている理由である、いくつかの非常に漠然とした質問をしています。あなたの質問を細分化するために刺すようにしましょう。詳細について質問がある場合は、別個の特定の質問を投稿し、コメントにリンクしてください。
WowzaやRed5のようなサービスを使用する必要がありますか？
これらはサービスではありません（もちろん、Wowzaも提供しています）が、ストリーミングメディアを処理するサーバーです。彼らはあなたのソースストリームを受け取り、効果的にそれをすべてのリスナーに中継します。はい、ストリーミングメディアをインターネット上の人々に配信するには、ある種のサーバーが必要です.WowzaやRed5にする必要はありません。特定のニーズに応じて、これを実行する他の多くの方法があります。
もっと簡単な方法について話しましょう... HTTPプログレッシブストリーミング。あなたのクライアント（ウェブブラウザ、アプリ、インターネットラジオなど）は、オーディオストリームを受け取ったときに再生することができます。彼らはそれが生きていることを知らない、気にもしません。彼らが知っていることは、彼らがHTTPリクエストを行い、再生に十分なデータを受け取り、再生を開始したことだけです。また、ストリームにトランスコードされたファイルであっても、マイクに向かって話しているファイルであっても、ソースが何であるかはわかりません。それは重要ではない。このモードでは、インターネットラジオストリームは基本的に決して終わらないようなオーディオファイルのようなものです。 SHOUTcastやIcecastを見ると、彼らが話すプロトコルはHTTPプログレッシブです。
エンコーダでは、オーディオキャプチャデバイス（マイク、ミキサーなど）やオーディオファイルの束など、元のオーディオがどこかから来ている必要があります。生のオーディオデータ（一般にPCM）は、コーデック（MP3のような）で符号化される。そのコーデックの出力は、最近、HTTP PUTリクエスト（あなたがIcecast ... SHACKcastのためのhacky他のメソッド、古いIcecastのためのSOURCEを使用している場合）によってサーバーに送られます。サーバーはこのデータを受信し、小さなバッファーを保持し、接続しているクライアントにそのデータのコピーを送信します。
MP3をストリーミングしている場合、サーバーはデータをクライアントに送信するだけです.Oggのような他のコンテナ形式では、ストリームがキャッチアップする前に最初にヘッダーを送信する必要があります。その時点で、サーバは基本的に各クライアントのためにストリームデータをコンテナに動的に多重化します。通常、これはヘッダーを作成し、残りのストリームを右端にスプライスすることによって行われます。
HTTPプログレッシブストリーミングは、ブラウザのすぐに使用できるという点で、デバイスと互換性があり古いものと新しいもの（私の古いPalm Pilotはうまくいっています）が必要で、サーバーリソースはほとんど必要ありません。
私はHLSは、使用可能なプロトコルの一つである
HTTPライブストリーミングに関するいくつかのものを見てきました。 HTTPプログレッシブのように継続的に実行されるストリームではなく、一度に数秒間コーデック出力を記録し、データのまとまりを保存し、サーバーにアップロードします。クライアントは、それらのチャンクを順番にダウンロードして再生することができます。この方法でのオーバーヘッドの束がありますが、人々はそれを選択し、いくつかの重要な理由があります。
クライアントは、セグメントの区切りで別のストリームに切り替えることができます。クライアントが一部のHDビデオをストリーミングしているが、サポートする帯域幅がないことがわかった場合、代わりにSDビデオのダウンロードを開始できます。エンコーダは、通常、さまざまなビットレートでチャンクを提供するように構成されています。 HLSで使用されるコンテナ形式は、この種の直接ストリーム連結をサポートしています。なぜなら、コーデックには、ストリームがその時点でスプライス可能であることを保証するために基本的に通知されるからです。
HLSに特別なサーバーは必要ありません。あなたは、SFTPやその他の通常どおりの方法でファイルをWebサーバーにアップロードできます。 Webページに通常必要とされるものの上にインストールするものはありません。
サーバーにデータを格納しているので、クライアントがそれを処理でき、ディスク領域がある場合は、自動的に時間通りに再生をサポートすることができます。
CDN分布。 S3バケットの前でCloudfrontのようなものを使用したい場合は、他のファイルを配布する場合とは異なる方法でAWSがサポートする必要はありません。
しかし、HLSに対する大きな否定は、クライアントのサポートです。 HTTPプログレッシブストリーミングはHTTPから効果的に使用されていますが、HLSは新しいものであり、クライアントはあまりうまくいきません。ブラウザは直接サポートしておらず、再生を処理するにはMediaSource APIといくつかのクラフトJavaScriptを使用する必要があります。標準フレームワークに頼っているモバイルアプリは、しばしば問題に遭遇します...特にAndroid 3.0では、本当に面倒なHLSバグがありました。時間が経つにつれてこれは良くなっています。
もう1つの同様のプロトコルがありますが、それはMPEG DASHです。セグメンテーションはHLSと同様に行われ、HLSの実際の使用状況を急速に蝕んでいます。
しかし、実際にこれを行うにはどうすればいいですか？これの背後にある実際のプログラミングは何ですか？
あなたは達成したいことを決めるためにこの問題を細分化する必要があります。 は何ですか？具体的にはですか？エンコーダを作りたいですか？サーバーを作る？
私は、ライブオーディオストリーミングサービスを作りたいと思っていました。
このため、自分で技術を発明する必要はありません。既にそこにある作品を組み立てるだけです。さんは「単収縮のように」と仮定し、次のことを意味します
これを行うには、私は言うでしょう： - Do not hosあなた自身のストリームには、CDNを使用してください。 - エンコーディングにMediaRecorder APIを使用します。 （まだ広く利用できませんが、すぐになります。）
私はこの記事に文字制限が不足しています...ので、私はそれはあなたが開始を取得願っています。それ以上の具体的な質問を投稿してください。