ライブストリーミングに関する技術的な詳細はすべてここにあります。 _html/css_WEB-ITnose

アクセラレーションに関するメモ: この記事は、 の有名なライブ ストリーミングで使用されているクラウド コンピューティング会社 UCloud のストリーミング メディア R&D チームによって書かれています。プラットフォーム！オンライン ビデオ ライブ ブロードキャストは長い間存在しており、モバイルのアップリンクおよびダウンリンク帯域幅の増加と料金の引き下げにより、人々は、いつでもどこでもライブ ブロードキャストや視聴を楽しむことができます。 1 つのビデオだけでは満足できないため、視聴者はライブ ブロードキャストの開始時間と遅延が製品の機能開発に影響を与える重要な指標となっています。そこで、次のような疑問が生じます: ライブ ブロードキャストを低遅延で即座に開始するにはどうすればよいでしょうか?

まず、ビデオ ライブ ブロードキャストの 5 つの主要なプロセスを見てみましょう: 録画 -> エンコード -> ネットワーク送信 -> デコード -> 再生 それぞれのリンクが重要です。ライブブロードキャストの場合、遅延はさまざまな程度の影響を及ぼします。ここではモバイルデバイスの状況を中心に分析していきます。テクノロジーの成熟度、ハードウェア環境などによって制限されるため、モバイル シナリオ向けのライブ ブロードキャストの遅延最適化の 4 つのポイント (ネットワーク、プロトコル、コーデック、モバイル端末) を簡単にまとめ、4 つの主要な部分に分けて UCloud ライブ ブロードキャスト クラウドを 1 つずつデコードします。 . 低遅延と即時起動を実現するための技術的な詳細。

1. UCloud ライブ ブロードキャスト クラウドのアクセス ネットワーク最適化の技術的詳細:

1) グローバル ロード バランシング - 近隣アクセス

近隣アクセスの実現最もよく知られているテクノロジーは CDN (コンテンツ配信ネットワーク) です。 CDN は、負荷分散と分散ネットワークという 2 つのコア テクノロジーで構成されています。10 年以上の進化により、分散ネットワークの構築戦略は、通常、最適なものをまとめたものになります。配布ルーティングは静的ではないため、調整と動的な操作に常に注意を払う必要があります。ここでは、CDN の負荷分散テクノロジーに焦点を当てます。

負荷分散はどのようにしてユーザー アクセスを実現しますか?より一般的な実装方法: ユーザーが使用する DNS サーバーを通じてクライアントのネットワーク位置を特定し、対応するサービス IP を返します。次の例に示すように:

Guangdong Telecom ユーザー IP: 1.1.1.1 はライブ ブロードキャスト http://www.ucloud.cn/helloworld.flv を視聴する必要があります。最も近いアクセスを実現するには:

1> ユーザーは、設定された DNS サーバー 1.1.1.0 (通常はオペレーターによって指定され、ローカル DNS とも呼ばれ、以下 Ldns と呼ばれます) に対して www.ucloud.cn のクエリを開始します。 ;

2> Ldns UCloud NS にドメイン名のレコードがない場合、トップレベルのルート NS でクエリが開始され、Ldns に通知されます。ドメイン名の権限のある解決レコードは UCloud NS にあります。

4>Ldns UCloud NS へのクエリを開始します。 Ldns1.1.1.0 は Guangdong Telecom に属します;

6> は Guangdong Telecom IP1.1.1.2 を返します;

7> は Ldns に返します。

8> ユーザー 1.1.1.2 に戻り、ユーザーはライブ ブロードキャスト コンテンツを取得するために 1.1.1.2 に移動します。

リンクは非常に長いですが、各 LDN はクエリされたドメイン名を適切にキャッシュし、次の Guangdong Telecom ユーザーが再度クエリを実行すると、直接 1.1.1.2 を返すことができます。アーキテクチャは複雑ではありません。重要な点は、Ldns が広東電信にあることを知る方法であり、これには IP アドレス ライブラリが関係します。オープンソースのアドレス ライブラリと商用アドレス ライブラリがあり、需要に応じて通常は年間約 10,000 個購入できます。 ここで、スケジューリングの精度がユーザーによって構成された Ldn に完全に依存していること、およびこれらの Ldn のほとんどが省レベルであることを理解するのは難しくありません。つまり、GLSB はユーザーが Guangdong Telecom であることのみを認識しますが、多くの場合は認識できません。 Guangdong Guangzhou Telecom か Guangdong Shenzhen Telecom かを教えてください。 HTTPDNS は、より正確なスケジューリングを実現する方法です。

1> ユーザー 1.1.1.1 は、HTTP プロトコルを通じて UCloud NS からライブ ブロードキャスト ドメイン名 www.ucloud.cn を直接リクエストします。

2> UCloud NS はユーザー IP 1.1.1.1 が広東深セン電信に属していることを検出し、

3> は広東深セン電信ノード 1.1.1.11 を UCloud NS に返します。ユーザー。

HTTPDNS の利点は明白です。まず、クライアントの IP を正確に取得でき、ユーザーの LDN が一致しない状況 (場合によってはネットワーク センターが DNS と一致しない場合があります) を効果的に回避でき、ユーザーの IP アドレスをより正確に特定できます。ネットワークの場所。 2 番目に、DNS 解決のハイジャックを回避できます。

2) BGP トランジット アーキテクチャ - 最短伝送パス

BGP はボーダー ゲートウェイ プロトコルであり、業界では BGP と呼ばれます。 BGP トランジット アーキテクチャがライブ ブロードキャストの高速化と配信にとってそれほど重要なのはなぜですか?国内ネットワークの複雑な状況について言及しなければなりませんが、より広く知られているのは、「華南電信と華北聯通」におけるブロードバンド ユーザーの分布です。単純な質問です。通信アンカーがライブ放送を開始しました。チャイナユニコムのユーザーがそれを見たい場合はどうすればよいでしょうか? 構造的に言えば、チャイナテレコムとチャイナユニコムの間には、情報橋に相当する交差点の数が限られているはずです。 これにより、2 つの問題が発生します。1. 距離が長く、ネットワーク遅延が大きく不安定です。2. ピーク時の混雑により、ライブ ストリームがフリーズします。

簡単に言うと、BGP の技術原理は、同じ IP が異なるネットワークに異なるルーティング情報をブロードキャストできるようにすることです。その結果、通信ユーザーが訪問したときに、その IP 内のルートを選択することになります。チャイナユニコムのユーザーが訪問する場合、チャイナユニコムのルートを利用します。したがって、BGP テクノロジーは、特にライブ ブロードキャスト シナリオにおいて、クロスオペレーター アクセスに大きな利便性をもたらします。従来のファイル キャッシュのシナリオとは異なり、初めて遠距離の元のサイトから画像を取得した場合でも、ローカル ネットワーク上にキャッシュされ、その後のアクセスはローカル ネットワークを経由します。ライブ ブロードキャストの高速化はストリーミングであり、低遅延を達成するには、中間バッファリングをできるだけ少なくする必要があります。 BGP は、ネットワークをまたがるユーザーのために近くに橋を架けるのと同等であり、長い迂回をする必要がなく、遅延と安定性が大幅に改善されます。

技術原則が導入されたところで、非常に多くのライブ ブロードキャストの遅延の影響により、どの程度改善できるでしょうか?まず、ここでの「最も近い」という用語は、必ずしも物理的な距離を意味するものではなく、瞬間的な負荷を考慮せず、最適な速度測定遅延のあるコンピューター室を指します。中国では、一般に、同じアクセス オペレーター (テレコム、チャイナ ユニコム、チャイナ モバイル) と地理的位置が最も近い場合、ネットワーク遅延は最適であり、15 ミリ秒未満です。同じ通信事業者の州間でのネットワーク遅延は 25 ～ 50 ミリ秒ですが、通信事業者間の状況はさらに複雑で、50 ～ 100 ミリ秒の範囲です。要約すると、ネットワークの重畳効果により、ライブブロードキャスト中の各パケットの遅延が 100ms 短縮され、上位層に反映される遅延が数秒短縮されます。

2. ライブ ブロードキャスト アプリケーション層プロトコルとトランスポート層プロトコルの選択、およびライブ ブロードキャスト エクスペリエンスに対するそれらの影響の分析

ライブ ブロードキャスト プロトコルの選択

いくつかの一般的なプロトコルがあります。中国の公共ライブブロードキャストプロトコル: RTMP、HLS、HDL (HTTP-FLV)、RTP を 1 つずつ紹介します。

RTMP プロトコル:

は Adob​​e の特許取得済みプロトコルであり、ほとんどの外国 CDN ではサポートされていません。国内で非常に人気があります。理由はいくつかあります。

1. オープン ソース ソフトウェアとオープン ソース ライブラリのサポートは安定しており、完全です。たとえば、Douyu アンカーで一般的に使用される OBS ソフトウェア、オープンソースの librtmp ライブラリ、サーバー側の nginx-rtmp プラグインなどです。

2. プレーヤーのインストール率が高い。ブラウザが FlashPlayer をサポートしている限り、RTMP ライブ ブロードキャストを非常に簡単に再生できます。プロトコルの詳細については、Google で調べてください。他のプロトコルと比較すると、RTMP プロトコルが初めて接続を確立するときのハンドシェイク プロセスは複雑すぎます (最下層は TCP に基づいており、ここではネットワークに応じて RTMP プロトコル自体の相互作用について話します)。条件によっては、最初のオープニングまでに 100ms 以上の遅延が発生します。 RTMP ベースのライブ ブロードキャストの一般的なコンテンツ遅延は 2 ～ 5 秒です。

HTTP-FLV プロトコル:

つまり、HTTP プロトコルを使用してメディア コンテンツをストリーミングします。 RTMP に比べて、HTTP はシンプルでよく知られており、Adobe の特許にさらされる心配はありません。コンテンツの遅延も 2 ～ 5 秒になる可能性があり、HTTP 自体には複雑なステータスのやり取りがないため、開く速度が速くなります。したがって、遅延の観点から見ると、HTTP-FLV は RTMP よりも優れています。

HLS プロトコル:

Http Live Streaming は、Apple が提案した HTTP ベースのストリーミング メディア伝送プロトコルです。 HLS には非常に大きな利点があります。HTML5 は直接開いて再生できます。これは、ライブ ブロードキャスト リンクを WeChat などを通じて転送したり共有したりできることを意味します。独立したアプリをインストールする必要はなく、ブラウザーだけをインストールする必要があるため、非常に便利です。人気のある。 ソーシャルライブストリーミングアプリ、HLSは必須とも言えます その原理を分析してみましょう。

HLS ベースのライブ ストリーム URL は m3u8 ファイルで、これには http://www.ucloud などの最近の小さなビデオ TS (ビデオ カプセル化形式、ここでは紹介しません) ファイルがいくつか含まれています。 cn/helloworld.m3u8 は、次のコンテンツを含むライブ ブロードキャスト リンクです:

リストに 5 つの TS ファイルが含まれており、各 TS ファイルには 5 秒のビデオ コンテンツが含まれていると仮定します。遅延は25秒です。もちろん、リストの長さと 1 つの TS ファイルのサイズを短縮してレイテンシーを減らすことはできますが、極端な場合、リストの長さを 1、つまり 1 秒のコンテンツを含む m3u8 ファイルに減らすことができますが、これは非常に影響を受けやすくなります。ネットワークの変動により遅延が発生します。

公共ネットワークの検証を通じて、同じ都市ネットワークに基づく現在の最良の効果は 5 ～ 7 秒の遅延であり、これは総合的な流暢さとコンテンツの遅延の結果でもあります。では、HTML5 には、より低い遅延で直接開くことができるライブ ストリーミング テクノロジを搭載できるのでしょうか? この問題については最後に検討します。

RTP プロトコル:

は、インターネットでマルチメディア データ ストリームに使用されるトランスポート層プロトコルであるリアルタイム トランスポート プロトコルです。

実際のアプリケーションシナリオでは、多くの場合、RTCP (RTP Control Protocol) を併用する必要があります。これは、単に RTCP がインタラクティブな制御シグナリングを送信し、RTP が実際のメディア データを送信すると理解できます。

RTP は、ビデオ監視、ビデオ会議、および IP テレフォニーで広く使用されています。ビデオ会議と IP テレフォニーの重要なユーザー エクスペリエンスは、コンテンツのリアルタイム性が高いためです。

上記の 3 つ、実際には 2 つのプロトコルと比較すると、RTP とそれらの重要な違いの 1 つは、デフォルトではデータの送信に UDP プロトコルを使用するのに対し、RTMP と HTTP は TCP プロトコルの送信に基づいていることです。 UDP はなぜこのようなリアルタイム効果を実現できるのでしょうか? TCP と UDP の違いについては多くの分析記事がありますが、ここでは詳しく説明しません。

UDP: 単一のデータグラム、接続を確立する必要がなく、シンプルです。信頼性が低く、パケット損失があり、順序が乱れています。

TCP : ストリーミング、接続を確立する必要がある、複雑、信頼性の高い 、秩序ある。

リアルタイムのオーディオおよびビデオのストリーミング シナリオでは、信頼性の保証が必要ないため、再送信メカニズムは必要ありません。ネットワークが切断されたときに、一部のコンテンツが失われることがあります。ジッターが発生し、画面がぼやけて歪みます。まったく重要ではありません。 TCP では、再送信のために遅延と非同期が発生し、再送信により特定のコンテンツが 1 秒後に到着すると、ネットワーク ジッターにより遅延が 2 秒または 3 秒に増加します。 .秒間、クライアントの再生が処理されない場合、ライブ ブロードキャスト エクスペリエンスに重大な影響を与えます。

要約すると、ライブ ブロードキャスト プロトコルの選択で RTMP または HTTP-FLV を選択すると、コンテンツに 2 ～ 5 秒の遅延が発生することになりますが、遅延がオンになっている場合、HTTP- FLV は RTMP よりも優れています。 HLS には 5 ～ 7 秒のコンテンツ遅延があります。ライブ ブロードキャストに RTP を選択すると、ライブ ブロードキャストの遅延は 1 秒以内に達します。しかし、私たちが知る限り、主要な CDN メーカーはいずれも RTP ベースのライブ ブロードキャストをサポートしていないため、中国における現在の主流は依然として RTMP または HTTP-FLV です。

HLS 以外にレイテンシを下げるソリューションはありますか?

HLS の利点は明らかです。モバイル端末に APP をインストールする必要がなく、HTML5 互換のブラウザで開くだけで表示できるため、主流のモバイル ブラウザはすべて基本的に HTML5 をサポートしており、これには大きな利点があります。ライブブロードキャストの普及と経験において大きな利点があります。

唯一の欠点は、コンテンツの遅延が大きいことです (H264 AAC エンコードなど、ここでは言及されていない HLS 制限も多数ありますが、これも「欠点」の 1 つと考えられます)。それが解決できれば、生放送技術は大きく進歩することになる。あるいは、別の言い方をすると、リンクを介して直接送信できる、遅延が少ないライブ ブロードキャスト ソリューションはあるのでしょうか? HLS 自体に限定されません。

Google は、ブラウザーでの直接的なビデオ インタラクションについて WebRTC を推進しており、現在、ブラウザーで開いてリアルタイムの会話やライブ ブロードキャストを行うことができる、多くの成熟した製品が登場しています。しかし、次のブラウザ オーバーレイを見てください:

非常に残念ですが、Safari は iOS 9.3 まで WebRTC をサポートしていません。調査を続けますが、Websocket のサポートは何ですか?

古くて時代遅れの Opera Mini を除き、すべてのブラウザが WebSocket をサポートしています。これは良い知らせのようです。 HTML5 WebSocket ライブ ブロードキャストのために解決する必要がある問題を整理しましょう。

1. バックエンドの互換性

3. デコードと再生

#1 これは、RTMP から HLS および RTP への変換を行ったことがある人にとっては基本的なスキルであるようです。 #2 ブラウザが送信に HTTP を使用することは、より良いオプションです。 #3 については、オープン ソースの JS デコード プロジェクト jsmpeg が推奨されています: https://github.com/phoboslab/jsmpeg。これには、ライブ ブロードキャスト用の NodeJS サーバー stream-server.js がすでにあります。

テスト結果から判断すると、このプロジェクトのコードは比較的薄く、産業としての成熟度にまだ達していないため、大規模に適用する必要がある場合、多くの落とし穴があると推定されます。興味のある学生は学び、研究することができます。

上記はライブ ブロードキャスト クラウドです。ライブ ブロードキャスト アプリケーション層プロトコルとトランスポート層プロトコルの選択と、ライブ ブロードキャスト エクスペリエンスへの影響の分析です。アクセスネットワークの最適化、コンテンツのキャッシュと送信戦略の最適化、端末の最適化については、今後公開される別のセクションを参照してください。

3. ライブ ストリーミング メディアの送信プロセスにおけるコンテンツ キャッシュと送信戦略の最適化の詳細な原​​則

基礎知識: I フレーム、B フレーム、P フレーム

I フレーム表現キーフレーム。これは、このフレームが完全に保存されるため、デコード時に必要となるのはこのフレームのデータだけであると理解できます。 (完全な画像が含まれているため)

P フレームは、このフレームと前のキー フレーム (または P フレーム) の差分を示します。デコードするときは、このフレームで定義された差分を以前にキャッシュされたピクチャと重ね合わせて、最終的なピクチャを生成する必要があります。 (つまり、差分フレーム、P フレームには完全な画像データはなく、前のフレームからの差分データのみが含まれます)

B フレームは双方向の差分フレームです。 B フレームは、このフレームと前後のフレームの差分を記録します (詳細はさらに複雑で、状況は 4 つあります)。つまり、B フレームをデコードするには、キャッシュされた前のピクチャを取得するだけでなく、後続のピクチャもデコードし、前後のピクチャとこのフレームのデータを重ね合わせて最終的なピクチャを取得する必要があります。

B フレームは圧縮率が高いですが、エンコードとデコードにより多くの CPU を消費し、ライブブロードキャスト中にライブブロードキャストの遅延が増加する可能性があるため、B フレームは通常モバイル端末では使用されません。

キー フレーム キャッシュ戦略

一般的なビデオ フレーム シーケンスは IBBPBBPBBP です...

ライブ ブロードキャストの場合、ライブの遅延を減らすためにブロードキャスト。通常、エンコード時に B フレームは使用されません。 P フレームと B フレームは I フレームに直接的または間接的に依存しているため、プレーヤーがビデオ フレーム シーケンスをデコードして再生したい場合は、まず I フレームをデコードする必要があり、その後、後続の B フレームと P フレームをデコードできます。したがって、サーバーがキーフレームをどのようにキャッシュするかは、ライブブロードキャストの遅延やその他の側面に大きな影響を与えます。

より良い戦略は、サーバーがキー フレーム間の間隔を自動的に決定し、ビジネス ニーズに従ってフレーム シーケンスをキャッシュし、低負荷に対処するために少なくとも 2 つ以上のキー フレームがキャッシュに保存されるようにすることです。遅延、遅延、インテリジェントなパケット損失、その他の要件を防ぎます。

遅延とラグのトレードオフ

ライブ ブロードキャストの遅延とラグは、ライブ ブロードキャスト サービスの品質を分析する際に非常に懸念される 2 つの指標です。インタラクティブなライブ ブロードキャスト シナリオは遅延に非常に敏感ですが、ニュースやスポーツのライブ ブロードキャストは再生のスムーズさにさらに注意を払います。

しかし、理論的に言えば、これら 2 つの指標には矛盾した関係があります。レイテンシーを低くする必要があるということは、サーバー側と再生側の両方のバッファーを短くする必要があることを示しています。ネットワークのジッターによる異常により、簡単に遅延が発生する可能性があります。 ; ビジネスはより大きな遅延を受け入れることができ、サーバーと再生側の両方がネットワークからのジッターに対処し、よりスムーズなライブ ブロードキャスト エクスペリエンスを提供するためにより長いバッファーを備えることができます。

もちろん、ネットワーク状態が非常に良好なユーザーの場合は、これら 2 つの項目を同時に保証できます。これは、主にネットワーク状態があまり良くないユーザー向けの、遅延と遅延の問題を解決する方法です。

通常、これら 2 つの指標のバランスをとり、最適化するための 2 つの手法があります。

まず、サーバーは、遅延要件に敏感なユーザーのために、停止要件が高いライブ ブロードキャストの場合はキー フレームを確保しながら、接続ごとに小さいバッファ キューを維持します。 、スムーズな再生を確保するために、バッファ キューの長さを適切に増やしてください。

2 つ目は、サーバーがすべての接続のネットワーク状態をインテリジェントに検出し、ネットワーク状態が良好な場合には接続のバッファー キューのサイズを減らし、遅延を軽減します。特にジッターが明らかであると検出された場合、サーバーはスムーズな再生を確保することを優先して、接続のバッファー キューの長さを増やします。

パケットロス戦略

いつパケットをドロップする必要がありますか?

ネットワーク接続が良好で遅延が比較的小さい接続の場合、パケット損失戦略は決して役に立ちません。ネットワーク接続が不十分なユーザーの場合、ダウンロード速度が遅いかジッターが大きいため、このユーザーの遅延はますます大きくなります。

別の状況としては、ライブ ストリームのキー フレーム間隔が比較的長い場合、最初のパケットがキー フレームである場合、この番組を視聴している視聴者の遅延がキー フレーム シーケンスの長さに達する可能性があります。 。どちらの場合も、再生遅延を調整するにはパケット損失ポリシーを有効にする必要があります。

パケット損失に関しては、2 つの問題を解決する必要があります。

1 つ目は、いつパケット損失を実行する必要があるかを正確に判断することです。

2 つ目は、パケットを損失する方法です。そのため、視聴者にとっての再生はエクスペリエンスへの影響を最小限に抑えることができます。より良いアプローチは、バックエンドがすべての接続のバッファ キューの長さを定期的に監視し、キューの長さと時間が個別の関数関係を形成するようにすることです。バックエンドは独自に開発したアルゴリズムを使用してこの個別の関数を分析し、パケットが送信されたかどうかを判断します。損失が必要です。

一般的なフレーム ドロップ戦略は、完全なビデオ フレーム シーケンスを直接破棄することです。この戦略は単純に見えますが、ユーザーの再生エクスペリエンスに大きな影響を与えます。 代わりに、背景は、ユーザーの知覚を最小限に抑え、遅延の影響をスムーズに徐々に減らすために、ビデオ フレーム シーケンスごとに、最後の 1 つまたは 2 つのフレームを徐々に失う戦略を採用する必要があります。

4. クライアントの最適化

解析の最適化

以下に示すように、前に紹介した DNS プロセスを参照してください。

制御性と災害復旧のニーズに基づいて、モバイル端末コードは通常、ストリーミングと再生用にサーバー IP アドレスをハードコーディングせず、代わりにドメイン名を使用します。 IP のダウンタイムやネットワークの中断が発生した場合は、DNS を変更することで問題のある IP を排除することもできます。ドメイン名の解決時間は、チャネルが存在する限り、数十ミリ秒から数秒の範囲です。上図の各リンクによると、一般的な平均解決遅延は 300 ミリ秒です。ネットワークの変動や機器の高負荷により、 は 2 番目のレベルに増加します。数十ミリ秒の状況では、熱が十分に高い場合に ISP NS レイヤーがドメイン名解決をキャッシュします。以下に示すように:

上記の分析によると、この州の遅延は約 15 ミリ秒であるため、最小のドメイン名解決は約 15 ミリ秒になる可能性があります。ただし、ライブ ブロードキャスト シナリオの特殊性により、ストリーミングと再生に使用されるドメイン名が ISP NS キャッシュ標準に達することが困難であるため、多くの場合、クエリのためにルート NS に戻る必要があります。

次に、クライアント側の解析最適化の原理が現れます。マシンはドメイン名の解析結果をキャッシュし、ライブ時に毎回 DNS プロセスを通過する必要はありません。ストリーミングと再生が必要です。これにより、数十ミリ秒から数百ミリ秒の開始遅延が節約されます。

再生の最適化

ライブ ブロードキャスト プレーヤーの関連技術点には、ライブ ブロードキャストの遅延、最初の表示時間 (再生の開始から最初に画面が表示されるまでの時間を指します) が含まれます。 、オーディオとビデオの同期、ソフト デコーディング、ハード デコーディング。次の再生プロセスを参照してください:

再生手順の説明:

1. プロトコルの種類 (RTMP、RTP、RTSP、HTTP など) に従って、サーバーとの接続を確立し、データを受信します。
関連するストリーム情報を見つけてバイナリ データを解析します。
さまざまなカプセル化形式 (FLV、TS など) に従って逆多重化 (デマルチプレクス) します。
エンコードされた H.264 ビデオを取得します。データと AAC オーディオ データをそれぞれ、
ハード デコード (システム API に対応) またはソフト デコード (FFMpeg) を使用して、オーディオ データとビデオ データを解凍します。
デコード後、元のビデオ データ (YUV) ) と音声データ (AAC) が取得されます ;
音声とビデオのデコードは別々であるため、同期する必要があります。そうしないと、音声とビデオが同期しなくなります。たとえば、他の人のスピーチが一致しなくなります。口の形;
最後に、同期された音声データがヘッドフォンまたは外部スピーカーに送信され、ビデオ データが表示のために画面に送信されます。

プレーヤーの再生プロセスを理解した後、次の点を最適化できます:

初回画面時間の最適化

ステップ 2 から開始してプリセットまでファイル タイプの検出にかかる時間を節約するためのデコーダ タイプ。
ステップ 5 から始めて、ビデオ データの検出範囲を絞り込みます。これは、特にネットワークが良好でない場合に、ダウンロードする必要があるデータの量を減らすことも意味します。 、ダウンロードされるデータの量を減らすと、再生を開始するときに大幅に時間を節約できます。I フレーム データが検出されると、すぐに戻り、デコード プロセスに入ります。

遅延の最適化

ビデオ バッファーまたはビデオ キャッシュ戦略の原理は、ネットワークが滞っているときに、一定量のビデオ データをキャッシュするためのユーザーの待ち時間を増やすことです。この技術は、視聴効果の点で効果的にフリーズ数を減らすことができますが、ライブ ブロードキャストではコンテンツの遅延が発生するため、このテクノロジは主にオンデマンド ブロードキャストに使用されます。ブロードキャストにより、ネットワークからライブ ブロードキャストへのコンテンツを可能な限り削除または削減します (遅延を減らすのに役立ちます)。

ダウンロードデータ検出プール技術は、ユーザーのダウンロード速度が不十分で遅延が発生した後、ネットワークが突然スムーズに戻ったときに、以前にサーバー上に滞留していたデータを加速して送信します。遅延による遅延を減らすために、プレーヤーは検出プール内のビデオ データの再生を加速し、現在加速している部分のオーディオ データを破棄して、現在視聴しているコンテンツの安定した遅延を確保します。

プッシュの最適化

プッシュの手順についての説明: プッシュとプレイが実際には逆であることは簡単にわかるため、詳細については説明しません。具体的なプロセス。

最適化 1:

適切な Qos (サービス品質、サービス品質) 戦略。

ストリーミング端末は、現在のアップリンク ネットワークの状況に応じて、音声およびビデオ データのパケットの送信とエンコードを制御します。ネットワークが貧弱な場合、音声およびビデオ データを送信できず、データが停止します。この時点では、データ送信のさらなる遅延を防ぐためにエンコーダーが停止され、ネットワーク状況に基づいてオーディオとビデオの送信を制御するための適切な戦略が選択されます。

たとえば、ネットワークが非常に貧弱な場合、ストリーミング側はユーザーが音声を確実に聞こえるように音声データの送信を優先し、ユーザーが確実に音声を視聴できるように一定の間隔内でキーフレーム データを送信します。一定時間経過後に画面が切り替わります。

最適化 2:

合理的なキーフレーム構成。

キー フレームの送信間隔を合理的に制御します (2 秒ごとまたは 1 秒ごとに 1 つを推奨)。これにより、バックエンドの処理が軽減され、バックエンド バッファー設定が小さくなる条件が作成されます。

ソフト コーデックとハード コーデックの選択

ソフト コードとハード コードの選択については、インターネット上に多くの分析記事があり、ここでもいくつかの体験談が紹介されていますが、根本的な問題はありません。すべてのオペレーティング システムとモデルと互換性のある最適なユニバーサル ソリューション。

プッシュ エンコーディング: Andorid4.3 (API18) 以降ではハード コーディングを使用することをお勧めします。iOS では完全なハード コーディング ソリューションを使用します。 🎜>:

Andorid プレーヤーと iOS プレーヤーはどちらもソフト デコーディング ソリューションを使用しており、当社と多数の顧客によるテストと要約の結果、消費電力は犠牲になりますが、細部のパフォーマンスは向上し、制御性と互換性は向上します。まれにエラーもなく強力です。

添付は、ソフト コーデックとハード コーデックの長所と短所の比較です。

クラウド モデルとネットワーク適応

ビデオ用の多数のパラメータ以上、コーデックの解析を行ってきましたが、実際にはiOSは機種に応じて最適なエンコード・デコード効果を適用する必要があるため、機種ごとにターゲットを絞ったテストやチューニングを行うことは非常に困難です。 Android では、モデルごとにターゲットを絞ったチューニングを行うため、毎年多くの新しいマシンが生産されますが、設定や判断ロジックがコード内にハードコーディングされている場合、メンテナンスと反復に非常に悪影響を及ぼします。

そこで私たちは、これらの判断ロジックや構成をクラウド上に配置できないかというアイデアを思いつき、このようにして、クラウド モデルとネットワーク アダプテーションのテクノロジーが誕生しました。

端末は、プッシュして再生する前に、プロトコルを通じて報告される現在のモデル構成、ネットワーク状態、および IP 情報を取得します。クラウドは、最適なエンコードおよびデコード戦略構成 (ソフト エンコードまたはハード エンコード、さまざまなパラメーターの構成、近くのストリーミング サービスの IP、および近くの再生サービスの IP) を返します。 端末は一度取得すればよく、ストリーミングや再生前に毎回取得する必要はありません。

このようにして、モデル コーデック適応ライブラリの反復と改善を継続することで、このテクノロジーを使用するすべてのライブ ストリーミング アプリにメリットがもたらされます。

概要

低遅延と即時起動のための多くのライブ ブロードキャストのバックエンドと端末の最適化テクノロジーを分析し、関連する実践が UCloud ライブ ブロードキャスト クラウドに実装されており、それらはすべて比較的"静的」「テクノロジー。実際に安定、低遅延、スムーズなライブ配信サービスを提供するのは、日常生活における非常に緻密なモニタリング、アルゴリズム、動的操作の結果であり、一定の条件を達成すれば安定したライブ配信サービスが楽しめるわけではありません。技術的な点では、万里の長城の最初のレンガが完成したと言えます。

アクセラレータークラブ 注: 特に明記されていない限り、すべての記事はアクセラレータークラブによって編集されたオリジナルです。転載する場合は出典を明記してください。

最もファッショナブルで最先端のインターネット情報を入手するには、加速会議公式 WeChat アカウント jiasuhuihao をフォローしてください。

レポートやフィードバックが必要な場合、また Acceleration Meeting の編集長と友達になるには、WeChat を追加してください: leaderweb