ビデオでのYahooのFlashからHTML5への移行方法

Adobe Flashは、かつてWebメディアの世界で事実上の標準でしたが、セキュリティとパフォーマンスの理由から、時間の経過とともにAdobe Flashに背を向けています。 ビデオ再生用のプラグインのインストールをユーザーに要求することも悪い習慣です。 その結果、ビデオ用にHTML5に移行しています。

HTML5ビデオ再生の開発はまだ初期段階にあり、最初はブラウザーがこれらの機能を最も原始的な方法でサポートしていました。 アダプティブストリーミングを含むようにサポートが拡張されたのはごく最近です。 アダプティブストリーミングには、主に2つの利点があります。

• 適応ビットレート（ABR）：アルゴリズムは、ユーザーチャネルの帯域幅、プロセッサパワー、プレーヤーサイズなどを決定します。 リアルタイムで、ビデオ設定を調整します。
• 可変バッファサイズ：再生の開始にかかる時間を制御できる機能。

これらの機能により、ビデオストリーミング業界はFlashからHTML5およびJavaScriptに移行できます。

ヤフーのビデオプレーヤーは、すべての最新ブラウザーでHTML5を使用しています。 この投稿では、これらの機会を実現するためのパスを説明し、遭遇した問題について話し、目にする機会について説明します。

HTML5への最初のステップ

2015年10月に、NFLゲームの世界的なライブブロードキャストを初めてホストしたときに、HTML5に向けた最初の一歩を踏み出しました。 このイベントでは、Safariで「クリーンな」HTML5プレーヤーを公開しました。 HTTP Live Streaming（HLS）のネイティブHTML5ブラウザサポートに基づいていました。 このイベントの一環として、クライアントのブラウザに応じてさまざまな種類のレンダリングを可能にする特別な機能を開発しました（Flashサポート、デバイス構成、オペレーティングシステム、ブラウザなど）。

建築ソリューション

すべてのブラウザーでHTML5サポートを実現するには、プレーヤーのストリーミングを再設計する必要がありました。 私たちには選択肢があり、その決定はYahooのビジネス全体とユーザーエクスペリエンスに影響を与える可能性がありました。

最初の、おそらく最も重要なポイントは、サポートするストリーミングプロトコルです。 選択はHLSとDASHの間で、どちらもHTTPを介したアダプティブストリーミングをサポートしています。 ただし、スタックを十分にシンプルにし、開発を十分に速くするために、HLSをサポートすることにしました。 iOSの場合、とにかくHLSをサポートする必要があり、ある時点で標準が開発されると、 Media Source Extensions（MSE）がHLSで動作し始める可能性があります。 MSEはHTML5標準の最近の開発であり、 タグを使用して再生するメディアストリームを動的に生成できます。

次の質問は、自分でビルドするか、既製を購入するか、オープンソースのHTML5プレーヤーを使用することです。 HTML5プレーヤーが必要なのはヤフーだけではありません。 また、いくつかのオープンソースプロジェクトがあります。 それらを使用すると、最初の時間を節約できます。 ただし、市場の他のプレーヤーによる実際の条件でのテストを含む分析では、既存のプレーヤーでは、Yahoo Video Playerに期待される品質、パフォーマンス、およびスケーラビリティが十分に提供されないことが示されました。

そして最後に、Flashをサポートする既存のビデオプレーヤーは、すでに成熟したテスト済みの時間でした。 デザインとロジックをFlashからJavaScriptに移植するか、プレーヤーを最初からビルドして設計するかを決定する必要がありました。 2番目を選択しました。 これにより、後の段階でDASHをサポートできる拡張性レベルを含む、いくつかのアーキテクチャ上の目標を達成できました。 このソリューションにより、以前の設計に関連した問題や欠点を回避できました。

以下に示すように、これらのソリューションはすべて多くの利点をもたらしました。

未来にズームイン

これらのソリューションを武器に、Flashから解放されるプレーヤーの開発を開始しました。 プロジェクトにはコード名「ズーム」が与えられました。これは、DCコミックスの宇宙から来たFlashスーパーヒーローの主な敵です。

HLSストリーミングのメディアパイプラインは次のようになりました。

図1. HTML5のメディアパイプライン

プレーヤーは、着信トランスポートストリーム（ MPEG-TS ）のデマルチプレクサとして機能します。 ストリームをオーディオとビデオに分割し、断片化されたMP4形式にパッケージ化され、ブラウザのMSEレベルで受け入れられます。

新しいHTML5プレーヤーを設計したとき、いくつかの目標がありました。 次のようになります。

• モジュラー：各コンポーネントを個別に開発し、個別にテストする必要があります
• 拡張可能：新しいプレーヤーは、プレーヤーを再設計することなく、新しい機能（DASHなど）をサポートできる必要があります。
• ステートレス：同じページまたは異なるアプリケーションの異なるプレーヤーインスタンスでコンポーネント（ABRなど）を使用できます。

下の図2は、新しいHTML5 MSEプレーヤーの高レベルアーキテクチャを示しています。

図2. Yahoo HTML5プレーヤーのアーキテクチャ

• フレームワークサービスは、HTTPダウンローダー（ビデオのダウンロード用）、Webワーカー（マルチスレッド用）、チャネルスループット決定機能などの一般的な機能を提供します。
• Stream＆Media Servicesには、パイプラインのさまざまな段階でメディアを処理するサービスが含まれます。 トランスポートストリームの読み込み、ストリームの分割、MSEを使用して再生されるMP4でのパッキングを含みます。
• Streaming Controllerは、ビデオコンテンツのストリーミングを制御するコンポーネントです。 また、ABRエンジンと通信して、目的のビットレートを決定します。
• 再生コントローラーは、さまざまなモジュールを使用してビデオを再生します。 さまざまな再生状態を持つ状態マシンを保存します。 また、再生、一時停止、巻き戻しなどのためのAPIも提供します。

問題

まず、すべてのブラウザーで同じ環境を提供する単一のフレームワーク（Adobe Flash）から、さまざまなプラットフォームとブラウザー（Chrome、Firefox、IE、Edge）のいくつかのフレームワーク（MSE、 XHR 、Web Workers、HTML5 Media Elements）に移行しました、Safariなど）、それぞれがシステムに独自の問題を追加しました。

2番目の問題は広告でした。 ビデオの再生はHTML5に切り替わりましたが、ビデオの世界のほとんどの広告主は引き続きFlashを使用しています。 したがって、HTML5を介してビデオを再生しながら、Flash広告を表示する方法を見つける必要がありました。 プレーヤーが複数のレンダリングコンポーネントを使用できるように作成しました。各コンポーネントは独自のレンダリング手法（Flash、HTML5など）をサポートしています。 これにより、ユーザーにとって最適な条件を維持し、収益を失うことはありませんでした。

3つ目の問題は、ユーザーのエンゲージメントを改善する方法です。これは、ビデオを適切に消費するための重要な指標です。 私たちは、ユーザーが常にビデオに関与し、対話することを望み、クリックや追加のページの読み込みなど、ユーザーが何らかのアクションを必要としないようにしました。 同時に、ページを順番に再生したくありませんでした。 そのため、ビデオプレーヤー自体のファーストクラスAPIに「プレイリスト」を含めました。 これで、特定のユーザー向けに高度なコンテキストとパーソナライズされた動画のキュレーションリストを設定できます。

下の図3は、Yahooビデオプレーヤーの高レベルアーキテクチャを示しています。

図3. Yahooビデオプレーヤーのアーキテクチャ

• コントローラーはレンダーコンポーネントの切り替えを担当し、さまざまな再生機能へのアクセスを提供します。
• Ads Controllerは、ビデオ広告を管理および実行します。
• プレイリストマネージャーは、ビデオプレイリストを管理し、プレイリスト機能へのアクセスを提供します。

パフォーマンス（再バッファリングと起動時間）は、ユーザーエンゲージメントの主な要因です。 パフォーマンス関連の変更は常に障害です。

オーディオ/ビデオの逆多重化とMP4パッケージは、プロセッサにとって高価な操作です。 ブラウザのメインUIスレッドでこれらの操作を実行すると、ページとプレーヤーのユーザーインターフェイスの応答性に影響します。 幸いなことに、ブラウザにはWebワーカーがマルチスレッドを有効にしますが、それらを使用すると、スレッド間でメッセージを転送する必要があります。

私たちの経験から、Firefoxでは、ワーカーを使用してストリームを分割し、MP4をパックする方が（ワーカーのないバージョンに比べて）20％効率的です。 一方、スレッド間でのメッセージ送信に関連する余分なワークロードはIEとEdgeで特に顕著であり、これが再バッファリングの増加につながることがわかりました。 これらの問題を解決するために、次の変更を行いました。

• ワーカー内のプロセッサのユニットを起動します
• スレッド間のメッセージを最小限に抑える

メディアを変換するためにWebワーカーを効果的に使用することで、プレーヤーは他のプレーヤーよりもパフォーマンスが向上しています。 これは、プロセッサの10％〜20％の改善と、再バッファリングレートの30％の改善です。

特徴

多くの問題に直面したという事実にもかかわらず、プレーヤーを設計することで、以前のプレーヤーでは利用できなかった機能を追加する機会が与えられました。

レンダリングコンポーネントを切り替えてFlashの広告とHTML5のコンテンツをサポートする機能を追加したため、ビデオをプリロードすることができました。 つまり、再生を開始する前に、プレイリスト内の次の動画のアップロードを開始できます。 たとえば、広告が読み込まれて再生が開始されると、コンテンツをバックグラウンドでプリロードできます。 広告からビデオへの移行は、テレビのように取得されます。

また、チャネルの帯域幅を決定するアルゴリズムを改善しました。 最初は、コンテンツの読み込み時間のみに基づいていました。 APIから取得した情報、たとえばTTFB（最初のバイトまでの時間-最初のバイトまでの時間）を追加しました。

また、キーフレームのレベルでビットレートを切り替えることができる機能も追加しました。 これにより、ネットワーク条件の予期しない変化への対応が改善されました。

結果

Google Chromeで新しいHTML5プレーヤーの展開を開始し、時間の経過とともに他のブラウザーのサポートを追加しました。 現在、新しいプレーヤーはすべての最新のブラウザーで動作します。 下の図4は、使用するレンダリングコンポーネントに応じたビデオ再生回数を示しています。 現在、トラフィックの約70％にHTML5レンダリングを使用しています。 この数は、Yahooネットワークの他の部分にプレーヤーを導入すると増加します。 MSEをサポートしない最も目に見えるプラットフォームは、Windows 7のIEです。Flashは引き続きそこで使用されます。

図4.ビューとレンダリング方法

再バッファリングの指標としてのこのような重要なメトリックに関しては、HTML5プレーヤーはFlashとほぼ同じレベルか、Flashよりわずかに優れています（図5）。

図5.再バッファリング率-フラッシュvs. HTML5

HTML5は、ユーザーが「PLAY」をクリックした後の開始時間に関しては優れています。 図6は、FlashプレーヤーとHTML5プレーヤーの「PLAY」をクリックしてからビデオの最初のフレームがレンダリングされるまでの遅延（クリックして再生のレイテンシー）を示しています。

図6.クリックしてレイテンシーを再生-Flash vs. HTML5

これらのグラフは、HTML5プレーヤーの利点（ロードの高速化、パフォーマンスの向上など）を明確に示しています。

次は何ですか

インターネット上のアダプティブストリーミングは急速に発展しています。 業界では、シングルプレーヤーのコンテキストでの再生の最適化に引き続き注力しています。Yahooでは、1ページでの複数のビデオのストリーミングの最適化にも取り組んでいます。 また、MSE-HTML5プレーヤーをモバイルWebの世界に持ち込むよう取り組んでいます。

Appleは最近、HLSのトランスポートストリームとしてフラグメント化されたMP4のサポートを発表しました 。 このソリューションは、HLSを使用するという当社の決定によく適合しています。 これにより、3つの利点が得られます。

• MP4はMSEとネイティブに互換性があるため、プレーヤーの簡素化。
• 高価なプロセッサとMP4の分割操作を回避することにより、プレーヤーのパフォーマンスが向上しました。
• 送信される情報の量を減らし、品質と開始時間を改善します。

インターネット上の最新のストリーミングテクノロジーの改善に引き続き注力し、新しい人材を採用しています！ amitnj@yahoo-inc.comに手紙を書いてください。チームでのキャリアの機会について話し合います。