著者：忙しい魚の技術-クラウドo

序文

短い動画の台頭により、フィードストリーム、詳細ページなど、主要なAPPのいたるところに短い動画が表示されるようになりました。ユーザーに優れたビデオ視聴体験を提供する方法は、ますます重要になっています。スワイプしてほとんどのフィードの動画を見ると、明らかに待っている感覚があり、エクスペリエンスはあまり良くありません。この問題に対応して、最適化の波を開始しました。目標は、ビデオ再生秒数、ビデオ再生エクスペリエンスが優れていることです。写真なし、真実なし前の比較写真では、左が最適化前、右が最適化後です。

問題分析

ビデオフォーマットの選択

問題を正式に分析する前に、説明する必要があります。当社のホームページのビデオはすべて、320pH.264でエンコードされたmp4ビデオです。

H.264およびH.265H.264は
、MPEG-4AVC（Advanced Video Codec）とも呼ばれ、ビデオ圧縮規格であり、広く使用されている高精度のビデオ録画、圧縮、および配信形式です。H.264は、Blu-rayディスクのコーデック標準であるため有名です。すべてのBlu-rayプレーヤーはH.264をデコードできる必要があります。以前のコーディング標準と比較して、H.264には、複数の参照フレームの動き補償、可変ブロックサイズの動き補償、フレーム内予測コーディングなど、いくつかの新機能があります。これらの新機能を使用することにより、H.264にはより多くの機能があります。他のコーディング標準よりも高いビデオ品質と低いビットレート
。H.265/ HEVCのコーディングアーキテクチャはH.264 / AVCのコーディングアーキテクチャとほぼ同じで、主にイントラ予測とインター予測、変換（変換）、量子化が含まれます。（量子化）、デブロッキングフィルター（デブロッキングフィルター）、エントロピーコーディング（エントロピーコーディング）およびその他のモジュール。ただし、HEVCコーディングアーキテクチャでは、全体が3つの基本ユニット、つまりコーディングユニット（CU）、予測ユニット（PU）、および変換ユニット（TU）に分割されます。
一般に、H.265は圧縮効率が高く、伝送ビットレートが低く、ビデオ品質が優れています。H.265を使用するのが賢明な選択のようですが、ここではH.264を選択します。その理由は次のとおりです。H.264はより幅広いモデルをサポートしています。
PS：Xianyu H.265ビデオは間もなく赤ちゃんの詳細ページで公開されますので、この体験にご期待ください！
TS＆FLV＆MP4

TSは、日本の高解像度カメラで使用されるカプセル化形式であり、フルネームはMPEG2-TSです。TSは「トランスポートストリーム」の略です。MPEG2-TS形式の特徴は、ビデオストリームの任意のセグメントを個別にデコードできる必要があることです。次のコマンドは、mp4をts形式に変換できます。結果から、tsファイル（4.3MB）はmp4ファイル（3.9MB）よりも約10％大きくなっています。

json
ffmpeg -i input.mp4 -c copy output.ts

FLVはFLASHVIDEOの略で、FLVストリーミングメディアフォーマットはFlashMXの導入により開発されたビデオフォーマットです。ファイルサイズが非常に小さく、読み込み速度が非常に速いため、インターネットでビデオファイルを見ることができます。この出現により、ビデオファイルをFlashにインポートした後、エクスポートされたSWFファイルがかさばり、使用できないという問題が効果的に解決されます。インターネット上でも。その他の問題。FLVは1つのオーディオストリームと1つのビデオストリームのみをサポートし、1つのファイルに複数のオーディオストリームを含めることはできません。オーディオサンプリングレートは48kをサポートしておらず、ビデオエンコーディングはH.265をサポートしていません。同じエンコード形式で、ファイルサイズはmp4とほぼ同じです。

json ffmpeg -i input.mp4 -c copy output.flv

MP4は、よく知られているビデオパッケージ形式です。MP4またはMPEG-4 Part 14は、標準のデジタルマルチメディアコンテナ形式です。MPEG-4 Part 14の拡張子は.mp4で、主にデジタルオーディオとデジタルビデオを保存しますが、字幕や静止画像も保存できます。ビットストリームをサポートするビデオストリームに対応できるため、MP4はネットワーク送信中にストリーミングできます。その互換性は非常に良く、ほとんどすべてのモバイルデバイスがサポートされており、ブラウザやデスクトップシステムでも再生できます。上記のいくつかのパッケージ形式の特性に基づいて、最終的な選択はMP4です。

再生プロセス

クライアントでのビデオの再生プロセスは何ですか？再生のスロースタートとは何ですか？時間のかかる点を迅速かつ低コストで解決できますか？ビデオ再生プロセスを理解することは、問題の突破口を見つけるのに役立ちます。ビデオは、ロードから再生までの3つの段階に分けることができます。

読み取り（IO）：「取得」コンテンツ->「ローカル」または「サーバー」から取得
パーサー：コンテンツを「理解する」->「フォーマットとプロトコル」を参照してコンテンツを「理解する」
レンダリング：コンテンツを「表示」->スピーカー/画面からコンテンツを「表示」

コンテンツの取得が「サーバー」から「ローカル」に変更されていることがわかります。これにより、多くの時間を節約でき、コストが非常に低く、優れたエントリポイントになります。事実は同じです、私たちの最適化はこの時点で実行されます。

PS：私たちが使用するネットワークライブラリとプレーヤーはすべてグループの内部にあり、多くの最適化が行われています。この記事には、ネットワークプロトコル、プレーヤーの最適化に関する説明は含まれていません。

テクニカルソリューション

上記の分析を考慮して、私たちがしなければならないことは、事前にmp4ファイルの一部をキャッシュし、フィードがスライドして再生するときにローカルmp4ファイルを再生することです。ユーザーは引き続き動画を視聴できるため、ローカルデータを再生した後、ネットワークからデータをダウンロードして再生する必要があります。ここで2つの問題を解決する必要があります。

事前にダウンロードする必要のあるデータの量
バッファリングされたデータの再生後にネットワークデータに切り替える方法

MOOVBOXの場所

最初の質問では、mp4のファイル構造を分析して、ダウンロードする必要のあるデータの量を確認する必要があります。MP4は多くのボックスで構成されています。ボックスはボックス内にネストできます。

MP4のフォーマット情報については、ここでは詳しく説明しません。ただし、ムーブボックスは再生にとって非常に重要であり、幅と高さ、継続時間、ビットレート、エンコード形式、フレームリスト、キーフレームリストなどの情報を提供します。プレイヤーはムーブボックスを取得せずにプレイすることはできません。したがって、ダウンロードしたデータには、moovボックスと数十フレームのデータが含まれている必要があります。

簡単な計算が行われます。Xianyuの短いビデオは通常最大30秒の長さで、フィードの解像度は320p、ビットレートは1141kb / s、ftyp + moovビデオのデータ量は約31kbです（ファイルを開いてあなたはmdatを見ることができますそれは31754バイトの位置から始まります）、それでヘッダー情報+データの10フレームはおよそ：（31kb + 1141kb / 3）/ 8 = 51KBです

プロキシ

2番目の質問：バッファリングされたデータが再生された後、ネットワークデータに切り替える方法は？ローカルデータの再生が完了したら、プレーヤーにネットワークアドレスを設定し、ダウンロードしたオフセットをプレーヤーに伝えてから、ネットワークからデータをダウンロードして再生し続けます。これは実現可能と思われますが、プレーヤーはサポートを提供する必要があります。ローカルデータの再生を完了するためのコールバック、ネットワークURLの設定とオフセットのサポート。さらに、サーバーは範囲パラメーターをサポートする必要があり、ネットワーク再生に切り替えるときに新しいネットワーク接続を確立する必要があります。これにより、フリーズが発生する可能性があります。

最終的には、プロキシを仲介として使用し、データのプリロード、プレーヤーへのデータの提供、およびプロキシで完了するロジックの切り替えを担当するプロキシ方式を選択しました。プロキシを追加する前のプロセスは次のとおりです。

プロキシを追加した後のプロセスは次のようになります。

これの利点は明らかです。たとえば、ローカルファイルキャッシュデータやネットワークデータの切り替え作業など、プロキシで多くのことを実行できます。他のプロトコルを使用してCDNと通信することもできます。ここでは、プリロード作業が完了したと想定し、プレーヤーがプロキシとどのように対話するかを確認します。再生時には、プロキシから提供されたローカルホストURLを使用して再生するため、プロキシサーバーはネットワーク要求を受信し、ローカルでプリロードされたデータをプレーヤーに返します。プレイヤーは、プロキシモジュールとプリロードされたモジュールの存在を完全に認識していません。プレーヤーとプリロードされたモジュールはどちらもプロキシクライアントであり、呼び出しロジックは同じです。イラストは次のとおりです。

以下に、データ読み込みプロセスを段階的に説明します。

矢印1に示すように、クライアントはデータを取得するためにhttpリクエストを開始します
要求されたデータがファイルキャッシュに存在する場合、矢印2に示すように、データは直接返されます。
ローカルファイルキャッシュデータが十分でない場合は、矢印3に示すように、ネットワーク要求を開始してCDNにデータを要求します。
矢印4に示すように、ネットワークデータを取得し、ファイルキャッシュに書き込みます。
矢印2に示すように、要求されたデータをクライアントに返します

実装モジュール

プリロードされたモジュール

技術的な解決策を決定した後、モジュールをプリロードするために行うべき多くの作業がまだあります。ネットワークデータのリストが解析された後、ビデオのプリロードがトリガーされます。最初に、URLに従ってmd5値が生成され、次にmd5値に対応するタスクが存在するかどうかが確認されます。存在する場合は存在しません。繰り返し提出されました。タスクが生成された後、タスクはスレッドプールに送信され、バックグラウンドスレッドで処理されます。ネットワークがWifiから3Gに切り替わると、ユーザーのデータトラフィックが消費されないように、タスクがキャンセルされます。

スレッドプールでプリロードタスクを実行する場合のプロセスは次のとおりです。まず、ローカルエージェントのURLを取得します。次に、httpリクエストを開始します。プロキシは処理のためのhttpリクエストを受信し、実際のデータのプリロード作業を開始します。プリロードモジュールは、指定された量のデータを読み取った後に終了します。この時点で、プリロードタスクは完了しています。フローチャートは次のとおりです。

ユーザーがすばやくスワイプしたときに、ビデオを数秒で開き続けることができるようにするにはどうすればよいですか？プリロードモジュールは、タスクごとにステートマシンを維持します。フリング中は、交差したタスクを一時停止し、表示される最新のタスクの優先度を上げて、最初に実行できるようにします。

プロキシモジュール

プロキシ内にローカルhttpServerがあり、プレーヤーおよびプリロードされたモジュールからのhttp要求をインターセプトします。クライアントは、要求時にCDNのURLを取り込み、ローカルキャッシュデータがない場合はCDNにアクセスして新しいデータを取得します。プロキシにデータを要求する場所が複数あるため、スレッドプールを使用して複数のクライアントの接続を処理する必要があります。これにより、複数のクライアントを並列化でき、以前のクライアント要求によってブロックされることはありません。ファイルキャッシュはLruDiskCacheを使用します。指定されたファイルサイズを超えると、古いキャッシュファイルが削除されます。これは、ファイルキャッシュを使用するときに見落とされがちな問題です。シーンビデオは継続的に再生され、シーク状況がないため、ファイルのキャッシュは比較的簡単で、ファイルのセグメンテーションを考慮する必要はありません。プロキシ内では、同じURLがクライアントにマッピングされます。プリロードと再生が同時に実行される場合、データのコピーは1つだけであり、データが繰り返しダウンロードされることはありません。プロキシの内部構造の概略図を次に示します。

発生した問題

テストでは、一部の動画の再生が非常に遅いことがわかりました。予想されるデータサイズがローカルにキャッシュされていることを注意深く確認してください。ただし、再生にはまだ長い待ち時間があります。この種の動画には、ムーブボックスが終わり。moovの最後のビデオは、ファイル全体がダウンロードされた後に再生されます。その理由は、以前のmp4形式の分析で説明したmoovボックスに多くの重要な情報が格納されているためです。この問題には2つの解決策があります。

解決策1：

サーバーは、トランスコーディング時にムーブのヘッドが前面にあることを確認し、ムーブの誤った位置を検出したビデオサーバーが修正を行います。

PS：ファイル内のムーブの位置を表示するには、16進テキストエディターでムーブの位置を開き、文字でムーブの位置を検索します。MACでMediaParserを使用することも、ffmpegを使用することもできます。ヘッドまたはテールにmoovを含むmp4ファイルを生成するコマンド。

例えば：

1.mp4からファイルをコピーし、最後にmoovヘッドを作成します

json
ffmpeg -i 1.mp4 -c copy -f mp4 output.mp4

1.mp4からファイルをコピーして、そのmoovヘッドがヘッドになるようにします。

json
ffmpeg -i 1.mp4 -c copy -f mp4 -movflags faststart output2.mp4

解決策2

moovボックスの位置を変更する必要はありませんが、再生側で処理する必要があります。再生側はストリーム情報を検出する必要があります。前のmoovがない場合は、ファイルのテール情報を要求します。具体的には、HTTP MP4要求を開始し、応答本文の先頭を読み取ります。先頭にmoovが見つかった場合は、引き続きmdatを読み取ります。始まりがないことがわかった場合は、最初にmdatを読み取り、すぐに接続をリセットしてから、Rangeヘッダーを介してファイルデータの終わりを読み取ります。これは、前のHTTPリクエストがすでにContent-Lengthを取得しており、全体を認識しているためです。 MP4ファイルのサイズ、範囲ヘッダーから読み取るファイルのテールデータの一部も可能です。回路図は次のとおりです

このスキームの欠点は、moovボックスの最後にビデオ用のhttp接続がさらに2つあることです。

総括する

この記事では、一般的なビデオエンコーディング形式、ビデオパッケージ形式、およびビデオ再生に対するmoovヘッダー情報の影響を紹介します。再生プロセスの分析により、問題の開始点が見つかりました。簡単に言えば、データのプリロード、事前にネットワークからのデータの要求の作業を完了し、再生中にキャッシュから直接読み取る作業を中心に展開し、後続のビデオレビューはすべてキャッシュから読み取られます。これにより、次の問題が解決されるだけではありません。最初のビデオ再生が遅い、それはまた、1つの石で2羽の鳥を殺すと言うことができる再生キャッシュの問題を解決します。プロキシはこのソリューションの中心的なアイデアです。ローカルローカルホストのURLは重要なリンクです。ビデオプリロードモジュールとプレーヤーモジュールは完全に分離されており、プレーヤーを変更した後も引き続き使用できます。これまでのところ、数秒でのビデオフィードの最適化は完了しています。オンライン後のデータによると、動画の開封速度は約800msです。

振り返ってみると、おそらくさらに一歩進んで、プリロードによって受信されたデータを検証して、固定値ではなく正確な情報がキャッシュされていることを確認できます。より詳細な最適化を実行して、ビデオをよりスムーズに視聴するユーザーエクスペリエンスを実現することもできます。