H.265/HEVC Web ライブブロードキャストプレーヤーの開発

H5 ビデオプレーヤーコアの開発は、フロントエンドエンジニアがめったに関与しない分野です。私はたまたま仕事中にそれを調査し、興味のある学生に共有しました。簡単に言うと、プレーヤーコアの機能はビデオタグに似ており、ビデオリソースのカプセル化解除、デコード、再生を担当します。

ビデオプレーヤーのアーキテクチャ

典型的な最新のプレーヤーは、UI、マルチメディアエンジン、デコーダーの 3 つの部分に分割できます [1]。この記事で説明するビデオプレーヤーのコアは、図 1 の下の 2 つの層で主な作業を行い、主にデコーダ、レンダラー、ネットワーク管理エンジン、メディア管理エンジンが含まれます。

H.265/HEVC エンコードおよびハードデコードプラットフォームのサポート

4K ビデオの人気が高まるにつれ、Apple の最新のオペレーティングシステムバージョン (Mac Hight Sierra および iOS 11) は、新しい業界標準 HEVC (High Efficiency Videocoding、別名 H.265) の導入をもたらしました[6]。現在の H.264 ビデオ圧縮規格と比較して、ビデオ圧縮率を最大 40% 高めることができます。H.265 を使用すると、同じビデオ品質を維持しながらビデオストリーミング効果が向上します。同じビットレートであれば、品質はほぼ 2 倍向上します。下の画像は、同じビットレートと同じ解像度 (400kpbs 1080p) の 2 つの画像です。左側は H.265 エンコードを使用し、右側は H.264 エンコードを使用しています。

一般に、OS はハードウェア (グラフィックカード) を使用して H.265 でエンコードされたビデオをデコードしますが、ハードデコードの消費電力が低く、デコード速度が速いという利点があります。ただし、現在、ブラウザーでの H.265 エンコードのハードウェアデコードサポートは普及していません。テスト後は、カスタマイズされた Chromium[7] および Edge 14 ブラウザーでのみサポートされます。このページを使用して、H.265 でエンコードされたオンデマンドビデオのブラウザー再生をテストできます。

ハードウェアデコードには、ユーザーのグラフィックカードが H.265 コーデックをサポートする必要があることに注意してください。現在、H.265 デコードをサポートするグラフィックカードは主に次のとおりです: Intel HD Graphic 4400/4600/5000/5500/6000/620、Iris Graphics 5100 /5200/6100、NVIDIA GeForce GTX 745、GTX 750、GTX 750 Ti、GTX 850M、GTX 860M、GeForce 830M、840M、GeForce GTX 970、GTX 980、GTX 970M、GTX 980M、GeForce GTX TITAN X、GeForce GTX 980ティ、GeForce GTX 750 SE、GTX 950、GTX 960、GeForce GTX 1070、GTX 1080、GeForce GTX 1060、NVIDIA TITAN XP、GeForce GTX 1050、GTX 1050 Ti。

ライブブロードキャストシナリオでは、再生のためにビデオストリームを MSE インターフェイス経由で HTMLMediaElement に送信する必要があるため、MediaSource インターフェイスも H.265 メディアタイプ文字列をサポートする必要があります。現在、H.265 でエンコードされたストリーミングメディアの再生をサポートしていると主張しているのは Edge ブラウザだけです。測定された MediaSource.isTypeSupported('video/mp4; codecs="hvc1.xxx"') は確かに true を返しますが、実際には H.265 でエンコードされたストリーミングメディアを再生します。動画データを mp4 にカプセル化すると、画面が真っ暗になり、画像が表示されなくなります。さらに、HEVC エンコーディングのサポートを宣伝する他の 2 つの Web プレーヤー、Radiant Media Player [9] と Bitmovin Video Player [10] もテストしたところ、同じ現象が見つかりました。

ウェブサイドのソフトウェアソリューション

現在、ライブブロードキャスト用の Web 側のハードウェアソリューションはブラウザのサポートに限定されているため、ソフトウェアデコードが唯一の選択肢となっています。H.265 ビデオのデコードは、高いパフォーマンス要件を伴う CPU 集中型のタスクであるため、Web サイドスクリプト言語で実装されたデコーダのパフォーマンスでは要件を満たすことが困難です。私たちのチームは以前、Flash ベースの H.265 デコードソリューションを試しました。これは、C 言語で書かれたデコーダを FlasCC[11] コンパイラを通じて swc ライブラリにコンパイルし、アクションスクリプトを使用して Flash 内の swc ライブラリを呼び出すというものでした。プレーヤー。テスト結果は、1080p 高解像度ビデオは 1 秒あたり約 10 フレームでしかデコードおよびレンダリングできず、アプリケーションの要件を満たすことができないことを示しています。

もう 1 つのソリューションは HTML5 に基づいており、WebAssembly テクノロジを使用して Kingsoft Cloud の自社開発高性能デコーダを wasm ライブラリにコンパイルします。wasm ファイルはバイナリ形式で存在し、プラットフォームに依存しない仮想命令 (アセンブリ命令と同様) が含まれています。WebAssembly テクノロジは現在、4 つの主要なブラウザの新しいバージョンでサポートされています。このテクノロジに基づくプレーヤーコアの実装を次の図に示します (図内の点線はオブジェクト参照関係を表し、実装はデータ転送を表します)。

この実装には、トランスマックス/多重化ワーカー (TransmuxingWorker)、デコードワーカー (H265decodingWorker)、色空間変換ワーカー (RGBConvertingWorker)、およびレンダリングと再生制御を担当するメインスレッドの 4 つのスレッドが含まれています。TransmuxingWorker では、ストリーミングメディアデータは DownloadController を通じてダウンロードされ (Safari、Chrome、および Edge ブラウザではダウンロードを実装するために Stream API を使用しますが、Firefox ではデータは XMLHttpRequest に基づいてダウンロードできます)、さまざまな形式に従って逆多重化されます。デマルチプレクサーはオーディオとビデオのデータを分離します (http-flv ストリームの逆多重化方法については flv.js 関連のコードを参照してください。HLS ストリームの逆多重化については hls.js 関連のコード [12] を参照してください)。。次に、オーディオデータは Fragmented MP4 形式 [(メディアタイプは mp4a) に再パッケージ化されます。最後に、mp4a オーディオデータはメインスレッドに戻され、AudioMSEController に渡され、AudioMSEController は MSE インターフェイスを介してオーディオタグにオーディオデータを渡し、再生します。

一方、カプセル化解除されたビデオデータは、MessageChannel を通じてデコードワーカー (H265decodingWorker) に送信され、H265Decoder のデータキューに入れられてデコードされます。H265Decoder は、基礎となるデコーダーを呼び出して WebAssembly テクノロジーに基づいてデコードし、YUV[14] データを出力します。次に、RGBConvertingWorker の RGBConverter に送信され、YUV から RGB 色空間に変換されます。最後に、RGB データフレームがメインスレッドのオーディオおよびビデオ同期レンダラー (AVSyncRender) に送信され、レンダリングされるキューに保存されます。

オーディオとビデオの同期レンダリングでは、ビデオをオーディオに同期する戦略が採用されています。つまり、オーディオは通常どおり再生され、レンダリングされるビデオキューの先頭にあるビデオフレームが常にチェックされ、その表示タイムスタンプ (pts) がチェックされます。ビデオフレームがオーディオの現在のタイムスタンプ (currentTime) と比較され、ビデオタイムスタンプがオーディオタイムスタンプより小さい場合、レンダリング対象の現在のキューの先頭にあるビデオフレームがレンダリングされます。それ以外の場合は、ビデオフレームをレンダリングする前に、上記の条件が満たされるまで待ちます。描画対象のキューが空の場合は、一定時間(例えば10ms)待ってから上記の動作を再開してください。ここでの画像レンダリングはキャンバス上でレンダリングされます。現在、主流のブラウザでのキャンバスレンダリングは GPU ハードウェアで高速化されています。テスト後のレンダリングフレームレートは、このシーンでの WebGL [15] レンダリングよりもさらに優れています。さらに、パフォーマンス上の理由から、ワーカー間でデータを通信および転送する場合は、ゼロコピー方式 (転送可能オブジェクト [16] とも呼ばれる) を使用する必要があります。

この記事では、Web 側のライブブロードキャストプレーヤーに関連するバックグラウンドテクノロジと、H.265 コーデックの Web 側のソフトおよびハードソリューションの探求を紹介し、ソフトソリューションの実装について説明します。