Webでのビデオ再生：ビデオ配信のベストプラクティス（パート2）

前回の投稿では、HTTPアーカイブのデータを使用して、今日のWeb上のビデオトレンドを調べました。 多くのWebサイトがモバイルとデスクトップで同じビデオコンテンツを提供しており、多くのビデオストリームが3G速度接続で再生するには高すぎるビットレートで配信されていることがわかりました。 また、Webサイトがビデオをモバイルデバイスに自動的にダウンロードする可能性があることも発見しました。これにより、再生されない可能性のあるビデオの顧客のデータプラン、バッテリー寿命が損なわれる可能性があります。

TL; DR ：この投稿では、顧客へのビデオの速度と配信を最適化するための手法を検討し、ビデオアセットの配信に役立つ9つのベストプラクティスのリストを提供します。

ビデオ再生メトリック

現在使用されている3つの主要なビデオ再生メトリックがあります。

1. ビデオの起動時間
2. ビデオストール
3. ビデオ品質

ビデオファイルは大きいため、ビデオを可能な限り小さく最適化すると、ビデオ配信が高速化され、ビデオの開始が高速化され、ストールの数が減り、配信されるビデオの品質の影響が最小限に抑えられます。 もちろん、起動速度とストールのバランスを、品質の3番目のメトリックとバランスさせる必要があります（高品質のビデオは通常、より多くのデータを使用します）。

ビデオスタートアップ

ユーザーが動画の再生を押すと、動画をすばやく視聴できることが期待されます。 Conviva（ビデオメトリック分析のリーダー）によると、2018年の第1四半期には、ユーザーが再生を押した後、ビデオの14％が再生を開始しませんでした（24億回のビデオ再生）。

ユーザーが再生ボタンを押した後、2.3％の動画（4億件の動画リクエスト）が再生に失敗しました。 11.54％（2Bプレイ）は、プレイを押した後にユーザーによって放棄されました。 これらの問題を引き起こしている可能性のあるものを分析してみましょう。

ビデオ再生の失敗

ビデオ再生の失敗は、すべてのビデオ再生の2.3％を占めました。 何がこれにつながる可能性がありますか？ HTTPアーカイブデータでは、すべてのビデオリクエストの0.3％が4xxまたは5xx HTTP応答になっていることがわかります。そのため、一部の割合は、不正なURLまたはサーバーの設定ミスに失敗します。 もう1つの潜在的な問題（HTTPアーカイブデータでは観察されない）は、ジオロケーションによってブロックされたビデオです（視聴者の場所とそのロケールでビデオを表示するプロバイダーのライセンスに基づいてブロックされます）。

ビデオ再生の放棄

Convivaレポートによると、すべてのビデオ再生の11.5％が再生されますが、顧客はビデオの再生が開始される前に再生を中止しました。 ここでの問題は、ビデオが十分な速さで顧客に配信されておらず、顧客が諦めていることです。 長い遅延がWebページの放棄を引き起こすモバイルWebに関する多くの研究があり、同じ効果がビデオ再生でも発生するようです。

Akamaiの調査によると、視聴者は2秒間待機しますが、その後1秒間ごとに、視聴者の5.8％が動画を放棄します。

では、何がビデオ再生の問題につながるのでしょうか？ 一般に、ファイルが大きいほどダウンロードに時間がかかるため、再生が遅れます。 ビデオの再生を高速化する方法をいくつか見てみましょう。 起動時に破棄されるビデオの数を減らすには、これらのファイルを可能な限り「スリム化」して、ファイルがすばやくダウンロード（および再生を開始）できるようにする必要があります。

MP4：ビデオプリロード

Webでの高速再生を確実にするために、1つのオプションは、ビデオを事前にデバイスにプリロードすることです。 そうすれば、顧客が「再生」をクリックしたときに、ビデオはすでにダウンロードされており、再生は高速になります。 HTMLは、 auto 、 metadata 、 noneの3つの可能なオプションを備えたプリロード属性を提供します。

preload = auto

ビデオがpreload="auto"で配信されると、ブラウザはビデオファイル全体をダウンロードしてローカルに保存します。 これにより、ビデオがデバイス上でローカルに利用可能になり、ネットワーク干渉によって起動が遅くなることがないため、動画の起動のパフォーマンスが大幅に向上します。

ただし、 preload="auto"は、動画が視聴される可能性が高い場合にのみ使用してください。 ビデオが単にWebページに常駐し、毎回ダウンロードされる場合、モバイルユーザーに大きなデータペナルティが追加されるだけでなく、ビデオ全体をすべてのユーザーに配信するためのサーバー/ CDNコストが増加します。

このウェブサイトには、いくつかのビデオを含む「ビデオギャラリー」というタイトルのセクションがあります。 このセクションの各ビデオでは、プリロードがautoに設定されており、WebPageTestウォーターフォールでのダウンロードを緑色の水平線として視覚化できます。

「ビデオギャラリー」と呼ばれるセクションがあり、ウェブサイトのこの小さなセクションのファイルは、ページダウンロードの1460万（83％）を占めています。 （多くの）ビデオの1つが再生される可能性はおそらくかなり低いため、 preload="auto"を使用すると、サイトのデータトラフィックが大量に生成されるだけです。

この場合、これらのビデオの1つでも表示される可能性は低いですが、すべてが完全にダウンロードされ、モバイルサイトに14.8MBのコンテンツ（ページ上のコンテンツの83％）が追加されます。 再生の可能性が高いビデオの場合（おそらくページビューの90％以上がビデオ再生になります）、ビデオ全体をプリロードすることは非常に良い考えです。 ただし、再生される可能性が低いビデオの場合、 preload="auto"を使用すると、サーバーを介して顧客のモバイル（およびデスクトップ）デバイスに大量のコンテンツが送信されるだけです。

preload="metadata"

preload="metadata"属性を使用すると、ビデオの最初のセグメントがダウンロードされます。 これにより、プレーヤーはビデオウィンドウのサイズを知ることができ、おそらく1秒または2秒のビデオをダウンロードしてすぐに再生することができます。 ブラウザは、ビデオコンテンツの206（部分的な要求）を行うだけです。 少量のビデオデータをデバイスに保存することにより、転送されるデータの量に大きな影響を与えることなく、ビデオの起動時間が短縮されます。

Chromeでは、属性が選択されていない場合、メタデータがデフォルトの選択肢です。

注：ビデオが大きい場合、これでも大量のビデオがダウンロードされる可能性があります。

たとえば、動画がpreload="metadata"に設定されているモバイルウェブサイトでは、動画のリクエストが1つだけ表示されます。

リクエストは部分的なダウンロードですが、フルビデオは1080p、長さ150秒、97 MBであるため、2.7 MBのビデオがダウンロードされます（ビデオサイズの最適化については次のセクションで説明します）。

したがって、 preload="metadata"は、ユーザーがビデオを視聴する可能性がかなり高い場合、またはビデオが小さい場合にのみ使用することをお勧めします。

preload="none"

ページの読み込み時にビデオファイルがダウンロードされないため、ビデオの最も経済的なダウンロードオプション。 これにより、再生が遅れる可能性がありますが、最初のページの読み込みが速くなります。1ページに多数の動画があるサイトの場合、動画ウィンドウにポスターを追加し、動画がダウンロードされるまで動画をダウンロードしないのが理にかなっています。エンドユーザーから明示的に要求された。 ウェブサイトに埋め込まれているすべてのYouTube動画は、再生ボタンが押されるまで動画コンテンツをダウンロードすることはなく、基本的にpreload="none"のように動作します。

プリロードのベストプラクティス：ビデオが視聴される可能性が高い場合にのみ、 preload="auto"を使用してください。 一般に、 preload="metadata"を使用すると、データ使用量と起動時間のバランスが取れますが、過度のデータ使用量がないか監視する必要があります。

MP4ビデオ再生のヒント

ビデオが開始されたので、ビデオの再生を最適化して、停止して再生を継続しないようにするにはどうすればよいですか。 繰り返しますが、秘訣はビデオをできるだけ小さくすることです。

ビデオダウンロードのサイズを最適化するためのいくつかのトリックを見てみましょう。 ビデオのサイズを縮小するために最適化できるビデオのいくつかの次元があります。

オーディオ

ビデオファイルはさまざまな「ストリーム」に分割されます。最も一般的なのはビデオストリームです。 2番目に一般的なストリームは、ビデオに同期するオーディオトラックです。 一部のビデオ再生アプリケーションでは、オーディオストリームは個別に配信されます。 これにより、さまざまな言語をシームレスに配信できます。

ビデオがサイレントな方法で再生される場合（ループするGIFやバックグラウンドビデオなど）、ビデオからオーディオストリームを削除すると、ファイルサイズをすばやく簡単に減らすことができます。 バックグラウンドビデオの一例では、ファイル全体は5.3 MBでしたが、オーディオトラック（聞こえない）は300 KB近く（ファイルの5％）でした。オーディオを削除するだけで、ファイルは無駄にならずにすばやく配信されます。バイト。

HTTPアーカイブで見つかったMP4ファイルの42％には、オーディオストリームがありません。

ベストプラクティス：サイレント再生されるビデオからオーディオトラックを削除します。

ビデオエンコーディング

ビデオをエンコードする場合、ビデオ品質（フレームあたりのピクセル数、または1秒あたりのフレーム数）を下げるオプションがあります。 高品質のビデオをWebに適したものに縮小することは簡単であり、通常、エンドユーザーに配信される品質には影響しません。 この記事は、ビデオで利用できるすべてのさまざまな圧縮技術の詳細な説明には十分な長さではありません。 x264およびx265エンコーダーには、 C onstant Rate Factor（CRF）と呼ばれる用語があります。 23〜28のCRFを使用すると、通常、優れた圧縮と品質のトレードオフが得られ、ビデオ圧縮の領域への最初の素晴らしいスタートとなります。

ビデオサイズ

ビデオサイズは、長さ、幅、高さなど、さまざまなサイズの影響を受ける可能性があります（おそらくここにオーディオを含めることもできます）。

ビデオの長さ

ビデオの長さは、通常、Web開発者が調整できる機能ではありません。 ビデオが3分間再生される場合、ビデオは3分間再生されます。 ビデオが非常に長い場合、 preload="none"やビデオのストリーミングなどのツールを使用すると、最初にダウンロードするデータ量を減らして、ページのロード時間を短縮できます。

ビデオの寸法

HTTPアーカイブで見つかったすべてのビデオの18％は、モバイルとデスクトップで同一です。 レスポンシブウェブデザインを扱ったことのある人は、さまざまなビューポート用に画像を最適化すると、画面が小さいほど画像のサイズがはるかに小さくなるため、読み込み時間を大幅に短縮できることを知っています。

同じことがビデオにも当てはまります。 30 MBの2560×1226のバックグラウンドビデオがあるWebサイトでは、モバイル（おそらくデスクトップでも！）でビデオをダウンロードするのに苦労します。 ビデオのサイズを変更すると、ファイルサイズが大幅に減少し、3つまたは4つの異なるバックグラウンドビデオを提供できる場合もあります。

現在、残念ながら、ブラウザはHTMLのビデオに対するメディアクエリをサポートしていません。つまり、これは機能しません。

 <video preload="auto" autoplay muted controls source src="large.mp4" </video>

したがって、さまざまな画面サイズで必要なビデオを配信するために、小さなJSラッパーを作成する必要があります。 しかし、そこに行く前に…

ビデオをダウンロードしているが、ビューから隠す

初期のレスポンシブWebへのもう1つの逆戻りは、フルサイズの画像をダウンロードすることですが、モバイルデバイスではそれらを非表示にすることです。 顧客は、大きな画像をダウンロードするためのすべての遅延（およびモバイルデータプランへのアクセス、余分なバッテリーの消耗など）を受け取りますが、実際に画像を表示するメリットはありません。 これは、モバイルのビデオで非常に頻繁に発生します。 したがって、スクリプトを作成するときに、小さい画面が最初から表示されないビデオを要求しないようにすることができます。

網膜品質のビデオ

デバイスの画面密度が異なると、ビデオが異なる場合があります。 これにより、モバイル顧客にビデオをダウンロードする時間が増える可能性があります。 小さい画面のデバイス、またはネットワーク帯域幅が制限されているデバイスで網膜ビデオが、これらのデバイスの標準品質のビデオにフォールバックするのを防ぎたい場合があります。 Network Information APIなどのツールは、ネットワークスループットを提供し、顧客に提供するビデオ品質を決定するのに役立ちます。

デバイスサイズとネットワーク品質に基づいてさまざまな種類のビデオをダウンロードする

小さい画面への映画の配信を最適化するいくつかの方法について説明しました。また、ビデオタグでビデオの種類を選択できないことにも注意しました。そのため、画面幅を使用して次のことを行う簡単なJSスニペットを次に示します。

• 500px未満の画面では動画を配信しません。
• 画面500〜1400の小さなビデオを配信します。
• より大きなサイズのビデオを他のすべてのデバイスに配信します。

 <html><body> <div> </div> <div></div> <script> //get screen width and pixel ratio var width = screen.width; var dpr = window.devicePixelRatio; //initialise 2 videos — //“small” is 960 pixels wide (2.6 MB), large is 1920 pixels wide (10 MB) var smallVideo="https://res.cloudinary.com/dougsillars/video/upload/w_960/v1534228645/30s4kbbb_oblsgc.mp4"; var bigVideo = "https://res.cloudinary.com/dougsillars/video/upload/w_1920/v1534228645/30s4kbbb_oblsgc.mp4"; //TODO add logic on adding retina videos if (width<500){ console.log("this is a very small screen, no video will be requested"); } else if (width< 1400){ console.log("let's call this mobile sized"); var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +smallVideo +"\"/\>"; console.log(videoTag); document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a small video."; } else{ var videoTag = "\<video preload=\"auto\" width=\"100%\" autoplay muted controls src=\"" +bigVideo +"\"/\>"; document.getElementById('video').innerHTML = videoTag; document.getElementById('text').innerHTML = "This is a big video."; } </script> </html></body>

このスクリプトは、ユーザーの画面を3つのオプションに分割します。

1. 500ピクセル未満では、ビデオは表示されません。
2. 500から1400の間で、より小さなビデオがあります。
3. 1400ピクセル幅を超える画面の場合は、より大きなビデオがあります。

私たちのページには、2つの異なるサイズのレスポンシブビデオがあります。1つはモバイル用、もう1つはデスクトップサイズの画面用です。 モバイルユーザーは優れたビデオ品質を得ることができますが、ファイルはデスクトップ用の10MBのビデオと比較してわずか2.6MBです。

アニメーションGIF

アニメーションGIFは大きなファイルです。 aGIFとビデオファイルの両方が幅と高さの次元でデータを圧縮しますが、ビデオファイルのみが（多くの場合、より大きな）時間軸で圧縮されます。 aGIFは、基本的に静的GIF画像をすばやく「めくり」ます。 この圧縮の欠如により、大量のデータが追加されます。 ありがたいことに、aGIFをループするビデオに置き換えることができ、リクエストごとにMBのデータを節約できる可能性があります。

 <video loop autoplay muted playsinline src="pseudoGif.mp4">

Safariには、さらに洗練されたアプローチがあります。次のように、ループするmp4をpictureタグに配置できます。

 <picture> <source type="video/mp4" loop autoplay> <source type="image/webp"> <src="animated.gif"> </picture>

この場合、SafariはアニメーションGIFを再生し、Chrome（およびWebPをサポートする他のブラウザー）はアニメーションGIFにフォールバックして、アニメーションWebPを再生します。 このアプローチの詳細については、ColinBendellのすばらしい投稿をご覧ください。

サードパーティのビデオ

Webサイトにビデオを追加する最も簡単な方法の1つは、ビデオ共有サービスからコードをコピーして貼り付け、サイトに配置することです。 ただし、サイトにサードパーティを追加する場合と同様に、ページに追加されるコンテンツの種類と、それがページの読み込みにどのように影響するかについて注意する必要があります。 これらの「これをHTMLに貼り付けるだけ」のウィジェットの多くは、数百KBのJavaScriptを追加します。 他の人は映画全体をダウンロードし（ preload="auto"と考えてください）、いくつかは両方を実行します。

サードパーティのビデオのベストプラクティス：信頼するが検証する。 追加されるコンテンツの量と、それがページの読み込み時間にどの程度影響するかを調べます。 また、動作が変わる可能性があるため、分析を定期的に追跡してください。

ストリーミングスタートアップ

ビデオストリームが要求されると、サーバーはマニフェストファイルをプレーヤーに提供し、利用可能なすべてのストリームをリストします（ディメンションとビットレート情報を含む）。 HLSストリーミングでは、プレーヤーは通常、リストの最初のストリームを選択して再生を開始します。 したがって、マニフェストファイルの最初に配置されたストリームは、モバイルとデスクトップの両方でのビデオ起動用に最適化する必要があります（または、代替のマニフェストファイルをモバイルとデスクトップの両方に配信する必要があります）。

ほとんどの場合、起動は低品質のストリームを使用して再生を開始することで最適化されます。 プレーヤーがいくつかのセグメントをダウンロードすると、利用可能なスループットをより正確に把握し、後のセグメント用に高品質のストリームを選択できます。 ユーザーとして、これを見たことがあるでしょう。ビデオの最初の数秒は非常にピクセル化されているように見えますが、再生の数秒後にはビデオが鮮明になります。

HTTPアーカイブからモバイルデバイスに配信された1,065個のマニフェストファイルを調べると、59％のビデオの初期ビットレートが1.2 MBPS未満であり、1.6 MBPS3Gデータレートでそれほど遅延することなくストリーミングを開始する可能性があります。 11％は1.2〜1.6 MBPSのビットレートを使用します—これは3Gでの起動を遅くする可能性があり、30％は1.6 MBPSを超えるビットレートを持っています—そして3G接続ではこのビットレートで再生できません。 このデータに基づくと、すべての動画の約41％がモバイルで初期ビットレートを維持できないようです。これにより、起動の遅延が増加し、再生中のストールの数が増える可能性があります。

ストリーミングスタートアップのベストプラクティス：マニフェストファイルの初期ビットレートが、ほとんどの顧客に有効なものであることを確認します。 プレーヤーが起動中にストリームを変更する必要がある場合、再生が遅れ、ビデオビューが失われます。

では、ビデオのビットレートが利用可能なスループットに近い（またはそれを超える）とどうなりますか？ 完成したビデオセグメントを再生する準備ができていない状態で数秒間ダウンロードした後、プレーヤーはダウンロードを停止し、低品質のビットレートビデオを選択して、プロセスを再開します。 ビデオセグメントをダウンロードしてから放棄するというアクションは、追加の起動遅延につながり、ビデオの放棄につながります。

これは、初期ビットレートが異なるビデオマニフェストを作成することで視覚化できます。 3つの異なるシナリオをテストします。最低（215 KBPS）、中間（600 KBPS）、および最高ビットレート（2.6 MBPS）から始めます。

最低品質のビデオから始める場合、再生は11秒から始まります。 数秒後、プレーヤーはより高品質のストリームを要求し始め、画像が鮮明になります。

最高のビットレートで開始すると（1.6 MBPSで3G接続でテスト）、プレーヤーは再生が発生しないことにすぐに気付き、最低のビットレートのビデオ（215 KBPS）に切り替えます。 ビデオは17秒で再生を開始します。 6秒の遅延があり、ビデオ品質は最初のテストで提供されたものと同じ低品質です。

中品質のビデオを使用すると、多少のトレードオフが可能になります。ビデオは13秒（2秒遅く）で再生を開始しますが、最初から高品質であり、ピクセル化されたビデオから高品質のビデオにジャンプすることはありません。

ビデオスタートアップのベストプラクティス：最速の再生のために、最低品質のストリームから始めます。 長いビデオの場合は、開始時に「中品質」のストリームを使用して、起動時に鮮明なビデオを配信することを検討してください（少し長い遅延があります）。

WebPageTestの結果：最初のビデオストリームは、低、中、高（上から下）です。 ビデオは、最低品質のビデオで最も速く始まります。 17秒での高品質の開始ビデオは11秒での低品質の開始と同じ品質であることに注意することが重要です。

ストリーミング：再生の継続

ビデオプレーヤーが再生に最適なビデオストリームを決定でき、ストリームが利用可能なネットワーク速度よりも遅い場合、ビデオは問題なく再生されます。 ビデオが最適な方法で配信されることを保証するのに役立つトリックがあります。 次のマニフェストエントリを調べると、次のようになります。

 #EXT-X-STREAM-INF:BANDWIDTH=912912,PROGRAM-ID=1,CODECS="avc1.42c01e,mp4a.40.2",RESOLUTION=640x360,SUBTITLES="subs" video/600k.m3u8

情報行は、このストリームのビットレートが913 KBPS、解像度が640×360であることを報告しています。 この行が指すURLを見ると、600kのビデオを参照していることがわかります。 ビデオファイルを調べると、ビデオが600 KBPSであり、マニフェストがビットレートを誇張していることがわかります。

ビデオビットレートを誇張する

• プロ
  ビットレートを誇張すると、プレーヤーがストリームを選択したときに、ビデオが予想よりも早くダウンロードされ、バッファーが予想よりも早くいっぱいになり、ストールの可能性が低くなります。
• CON
  ビットレートを誇張することにより、配信されるビデオは低品質のストリームになります。 報告されたビットレートと実際のビットレートのリスト全体を見ると、次のようになります。

1.6 MBPS接続のユーザーの場合、プレーヤーは913 KBPSビットレートを選択し、600KBPSのビデオを顧客に提供します。 ただし、ビットレートが正確に報告されていれば、950 KBPSのビットレートが使用され、問題なくストリーミングされた可能性があります。 ここでの選択はストールを防ぎますが、消費者に配信されるビデオの品質も低下させます。

ベストプラクティス：ビデオのビットレートを少し誇張すると、再生中のストールの数を減らすのに役立つ場合があります。 ただし、値が大きすぎると、再生品質が低下する可能性があります。

ブラウザでNeilsenビデオをテストし、前後にジャンプできるかどうかを確認します。

結論

この投稿では、Webサイトに表示するビデオを最適化するためのさまざまな方法について説明しました。 この投稿に示されているベストプラクティスに従うことにより、次のようになります。

1. preload="auto"
   この動画が顧客に視聴される可能性が高い場合にのみ使用してください。
2. preload="metadata"
   Chromeのデフォルトですが、それでも大きなビデオファイルのダウンロードにつながる可能性があります。 注意して使用してください。
3. サイレントビデオ（ループGIFまたはバックグラウンドビデオ）
   オーディオチャンネルを取り除く
4. ビデオの寸法
   異なるサイズのビデオをデスクトップ経由でモバイルに配信することを検討してください。 ビデオは小さくなり、ダウンロードが速くなり、ユーザーが違いを理解する可能性は低くなります（サーバーの負荷も低下します！）
5. ビデオ圧縮
   ビデオが確実に配信されるように、ビデオを圧縮することを忘れないでください
6. 動画を「非表示」にしないでください
   ビデオが表示されない場合は、ダウンロードしないでください。
7. サードパーティのビデオを定期的に監査する
8. ストリーミング
   起動を速くするために、低品質のストリームから始めます。 （長時間再生するビデオの場合は、起動時の品質を高めるために中程度のビットレートを検討してください）
9. ストリーミング
   ストールを防ぐためにビットレートを控えめにすることは問題ありませんが、行き過ぎてしまうと、ストリームは低品質のビデオを配信します。

あなたはあなたのページのビデオが最適な配信のために合理化されていること、そしてあなたの顧客があなたが提示するビデオを喜ぶだけでなく、全体としてより速いページ読み込み時間を楽しむことを見つけるでしょう。