モバイルインターネットの急速な発展とスマート端末の性能の漸進的な改善に伴い、スマート端末間のリアルタイムのオーディオおよびビデオ通信は、モバイルインターネットの発展にとって重要な方向性となっています。実際、リアルタイムのオーディオとビデオの通信 = オーディオとビデオの処理 + ネットワーク伝送です。取得、エンコード、ネットワーク送信、デコード、再生、その他のリンクを含みます。単純ではない多くの技術アプリケーションは、適切に把握しないと、実際の開発プロセスで次々と落とし穴に遭遇します. この記事では、いくつかの典型的な問題について簡単な参考提案を提供します.
主流は H.264 エンコーダーであり、オープン ソース コーデックの実装は主に x264 と openh264 です.その中で、openh264 は Cisco のオープン ソース プロジェクトであり、リアルタイムのビデオ通話シナリオに最適化されています. また、Google の vp8 もモバイル端末向けに多くの最適化を行っています (VP8 (最新バージョンは既に VP9 です) は Chrome のデフォルトのエンコード形式です)。
H.264 の特許認可に関する余談について話します。
MPEG 4 Part 10 とも呼ばれる H.264 は、MPEG 2 と同じ承認料が必要であり、特許同盟 MPEGLA によって一律に管理および収集されています (H.264 などの標準は、実際には多数の特許取得済みのコレクションの集まりです)。ある会社が保有しているので、Win-Winの協力のために、みんなで特許を取って、いわゆるアライアンスを組んで、みんなで争うのはよくない）。MPEG4規格を使用するには、エンコード/デコードのライセンス料の支払いが必要です.年間10万製品以降は無料ですが、10万製品を超えると、製品ごとに0.2ドルのライセンス料が発生します.500万を超えると、承認手数料は 0.1 米ドルに引き下げられ、上限は 500 万米ドルです。
ただし、YouTube などの動画サイトなどのオンライン無料コンテンツは、2016 年まで無料で利用できます。ただし、NetFix のようにレンタル動画を提供する場合は、ユーザー数に応じて承認料が発生します; PPV (Pay Per View) や VOD (Video on Deman) で使用する場合は、MOD の有料動画やBBTV デジタル ケーブル テレビは、12 分を超えるコンテンツですが、販売価格の 2% の承認手数料も請求されます。上限として500万まで。
上記のライセンス料を見ると、誰もがテクノロジー企業であり、もちろん不満を抱く人もいるでしょう。そのため、多くのオープンソース ソリューションが生まれています (もちろん、そう簡単にうまくいくわけではありません)。その中で、Google の抵抗が最も大きくなっています。集中。Google と Microsoft + Apple の間のオーディオとビデオの規格に関する論争は非常にホットなトピックです. 興味がある場合は、Baidu にアクセスして詳細を確認しないでください.
ソフトウェア コーディングを使用すると、より多くの CPU リソースを消費します。つまり、デバイスが熱くなり、すぐに電力を消費しますが、デバイスの互換性は良好で、ほぼすべてのデバイスで実行できます。インスタント メッセージングおよびチャット ソフトウェア アプリの開発を Wei Keyun に追加できます
ハードウェアエンコーディング方式を使用すると、エンコーディングパフォーマンスが高く、1080pフルHD画像のリアルタイムエンコーディングを完全にサポートでき、電力も節約できますが、デバイスの適応性は比較的低く、特にハードウェアエンコーディングモードAndroid デバイスの割合は比較的低いです。iOS デバイスがサポートする適応性は比較的良好ですが、下位レベルのエンコーディング インターフェイスを開かないと、リアルタイム ライブ ブロードキャスト用のフレーム単位でコード ストリームを取得することは困難です。さらに、ハードウェア エンコーディングで動的なビット レート制御を行うことはより困難です。
Web ライブ ブロードキャストおよびオンデマンドのシナリオでは、ビット レート制御アルゴリズムの最適化が必要な、エンコード段階でのビット レートの変動を滑らかにするようにしてください。
キー フレームの間隔が短いと、ビット レートのスパイクが頻繁に発生し、データ送信時に瞬時に輻輳が発生します。
ストリーミング側に送信バッファを追加するなどのバッファを設定し、フレームごとにデータを送信するのではなく、固定ビットレートでデータを送信することで、ビットレート変動の問題を解決できます。
同様に、プレーヤーに受信バッファーを設定して、ネットワークの変動によって頻繁に発生するフリーズを解決することもできます。ただし、バッファを大きく設定しすぎると遅延が増加するため、ライブ ブロードキャスト アプリケーションには適していませんが、オンデマンド アプリケーションには適しています。ライブ ブロードキャストのシナリオでは、エンド ツー エンドの遅延をできるだけ小さくする必要があります。これにより、プレーヤーはすぐに開始して画像を見ることができます。
rtmp ライブ ブロードキャストでは、累積的な遅延を解決する必要があるため、プレーヤーのバッファを積極的にクリアする方法を使用できます。
ライブ放送であろうとオンデマンドサービスであろうと、エンドツーエンドのデータ伝送リンクの問題があります. ストリーミング側では、まずストリーミングサーバーに接続する必要があります. このとき, 選択する必要があります.適切なノード. 1 つは、クライアントの DNS ドメイン名に従って選択することです. 最も近いノードの場合、DNS 構成が間違っていると、不正確なスケジューリングの問題が発生する可能性があります.
もう 1 つは、クライアントの送信 IP に基づいてノードを選択する方法で、このスケジューリング方法はより正確になります。プレーヤー側でも、同様の方法を使用して、ストリーミング メディア サーバー クラスターのエッジ ノードを選択します。
ライブまたはオンデマンドのプロセス全体で、ネットワークの種類、マシン情報、リアルタイムのネットワーク ステータス、フレーム レート、ビット レート、解像度などを含むリアルタイムの統計データを取得することをお勧めします。このようにして、発生したさまざまな問題を分析できます。特にライブ ブロードキャストのシナリオでは、ネットワークが変動してフリーズが発生したときに、QOS を動的に調整するための基礎を提供できます。
リアルタイムのオーディオおよびビデオのライブ ブロードキャスト シナリオでは、エンコード パラメータを動的に調整するために qos 戦略が採用されます。フレームレート、ビットレート、解像度、バッファを含みます。生放送がフリーズしている場合は、急速に下降し、ゆっくりと上昇するという戦略が採用され、ネットワークの変動が激しい場合、これによりエンコード パラメータの頻繁な調整が回避され、悪循環が生じます。
エンコード パラメータを調整する場合、コード レートとフレーム レートは通常、解像度に応じていくつかのグレードに分けられ、一定期間内の統計データに従ってこれらの参加者のグループ間を行き来して、スムーズな音声と音声を確保します。ビデオ 同時に、画質を可能な限り向上させます。