Amazon Kinesis Video Streams でレイテンシを削減する方法 – Part 1

この記事は How to reduce latency with Amazon Kinesis Video Streams – Part 1 の日本語訳です。

この 2 部構成の記事で、Amazon Kinesis Video Streams で管理されるストリーミングメディアのレイテンシを低減する方法と、2 秒未満のレイテンシで様々なネットワーク条件下で堅牢なビデオ品質を提供できる方法について説明します。そして、Amazon Kinesis Video Streams Web Viewer を使って、Amazon Kinesis Video Streams (KVS) で1.4秒のレイテンシが可能であることを示す実用的なデモを提供します。

Part 1 では、ストリーミングメディアの基礎知識、KVS の動作、一般的なデザインパターン、KVS で管理されるストリーミングメディアのレイテンシの主な要因について説明します。

Part 2 では、KVS、メディアプロデューサー、メディアプレーヤーのレイテンシを最適に設定するための手法を説明します。最後に、Amazon Kinesis Video Streams Web Viewer を紹介し、KVS で様々な実験を行い、様々な設定や構成で期待できるレイテンシの数値を検証します。

Amazon Kinesis Video Streams のメディアフォーマット

メディアは、GStreamer KVSSink プラグイン、KVS Producer ライブラリまたは KVS API を使用して KVS に取り込まれますが、いずれの場合も取り込まれるメディアの基本フォーマットは Matroska (MKV) コンテナ化されたセグメントとなります。コンシューマー側では、ライブメディアは、Fragmented MP4 として配信される HTTP Live Streaming (HLS) を使用して、ウェブおよびモバイルアプリケーションに最も一般的な形式で配信されています。この一般的な KVS デザインパターンでは、プロデューサーとコンシューマーの両方が、ストリーミングメディアの技術に依存しています。このブログでは、この一般的な KVS デザインパターンを使用して、ストリーミングメディアのエンドツーエンドのレイテンシを低減する方法に焦点を当てます。

図 1 – KVSがメディアを取り込み、保存し、HLS形式でクライアントアプリケーションに配信する

KVSにおけるライブメディアのレイテンシの要因

KVS を介したストリーミングメディアのエンドツーエンドのレイテンシは、ビデオエンコード/デコード、フラグメント化遅延、ネットワーク遅延、KVS によるバッファリング、メディアプレーヤーによるフラグメントバッファリングの合計となります。これらの要因を比較するために、以下の表は、ライブメディアにはあまり利用されないパラメータを使用した場合の KVS メディアストリームのレイテンシの指標値を示しており、合計レイテンシはおよそ9.5秒未満になります。

表 1 – KVS ストリームの遅延の指標となる数値（ライブメディア用に不適切な設定を行った場合）

ここに示した数値は代表的なものですが、KVS の多くの新規ユーザーにとって共通のスタート地点であり、遅延を改善するには、ビデオのフラグメント化とフラグメントバッファリングをより詳細に検討する必要があることを明確に示しています。

ストリーミングメディアとビデオフラグメンテーション

インターネット上でライブメディアを確実かつタイムリーに伝送するために、エンコードされたビデオフレームのグループは、MPEG-4 (MP4)、QuickTime Movie (MOV)、Matroska (MKV) など、いくつかのフォーマットのうちのどれかでコンテナ化されています。フレームの各グループがメディアコンテナに入れられると、フラグメントとして知られる自己完結型の転送可能なユニットになり、これが私たちがストリーミングメディアと呼ぶものの基礎を形成します。フレームが記録され、伝送され、バッファリングされ、表示されるまでの時間は、エンドユーザーが遅延として経験するものです。

図 2 – H.264/265 でエンコードされたフレームは、ストリーミングメディアフラグメントとして送信されます

ビデオエンコードとフラグメント長

H.264 / H.265 ビデオエンコーダは、フレーム間で変更されたピクセルだけを送信することによって、高い圧縮率を達成しています。各フラグメントは、すべてのデータ（ピクセル）を含むキーフレーム（または I フレーム）で始まり、順方向予測フレーム（P フレーム）、双予測フレーム（B フレーム）を進めるための基準を提供する必要があります。これらのフレームは、次のキーフレームが挿入されるまで、変化しない部分のデータを送信することなく、変化する画像を表現するために協調して動作するということを理解すれば十分です。

各キーフレーム間のフレーム数はエンコーダによって設定され、キーフレーム間隔と呼ばれます。ストリーミングメディア、特に KVS では、各キーフレームの到着時に新しいフラグメントを開始するのが一般的であるため、フラグメント長（秒単位）は一般に次のように計算することができます。

フラグメント長（秒） = キーフレーム間隔（フレーム数） / 秒あたりのフレーム数（fps）

図 3 – H.264/265 のフレームタイプ

例えば、キーフレーム間隔が 30 でフレームレートが 15 fps のメディアストリームは、2 秒ごとにキーフレームを受信することになり、KVS ビデオプロデューサーでは通常 2 秒のフラグメント長になります。フラグメント長はストリーミングメディアのレイテンシに直接影響するため、関係性があります。

メディアプレーヤーのフラグメントバッファリング

すべてのメディアプレーヤーは、ネットワークが不安定なときにビデオの品質が低下するのを避けるために、ある程度の数のフラグメントをバッファリングします。メディアプレーヤーには、QuickTime や VLC などのデスクトッププレーヤー、カスタムウェブアプリケーションやモバイルアプリケーションで使用される react-player などのアプリケーションライブラリ、各種ウェブブラウザで見られるデフォルトのメディアプレーヤーが含まれます。

メディアプレーヤーのアプリケーションライブラリは、フラグメントバッファの設定をプログラム向けに提供していることが多いですが、デスクトップとブラウザベースのメディアプレーヤーは、それぞれライブとオンデマンドのビデオ再生用に事前設定された設定を使用します。

フラグメントバッファリングは、受信したメディアとコンシューマーの間に直接介在し、ライブビデオ用に特別に設定されていない場合は、30 秒ものレイテンシを生じさせます。メディアプレーヤーによるフラグメントバッファリングは、ストリーミングメディアのレイテンシの主要な要因であり、以下のように計算されます。

フラグメントバッファのレイテンシ（秒） = バッファリングされたフラグメントの数 X フラグメントの長さ（秒）

図 4 – メディアプレーヤーのバッファに起因する遅延

したがって、レイテンシを減らすには、メディアプレーヤーでバッファリングされるフラグメントの数を減らす必要があります。興味深いことに、ほとんどのメディアプレーヤーのバッファ設定は、総バッファリング時間ではなく、フラグメントの数に基づいているため、フラグメントの長さを短くすると、ストリーミングメディアのレイテンシを減らすのと同じ効果があります。

HLS プレイリスト

HTTP Live Streaming (HLS) は、アダプティブビットレートストリーミングプロトコルであり、メディアフラグメントを HLS メディアプレイリスト (.m3u8) ファイルを介してメディアプレーヤーに配信します。これは、メディア設定タグと必要なメディアフラグメントへの URL リンクを含む、クリアテキストのマニフェストファイルです。以下は、HLS メディアプレイリストの抜粋です。

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-PLAYLIST-TYPE:EVENT
#EXT-X-TARGETDURATION:1
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-DISCONTINUITY
#EXT-X-MAP:URI="getMP4InitFragment.mp4?SessionToken==...&TrackNumber=1&SequenceNumber=1"
#EXTINF:0.498,
getMP4MediaFragment.mp4?FragmentNumber=91343852333181769835329731216345997453612345678&SessionToken=...&TrackNumber=1&SequenceNumber=1"
#EXT-X-DISCONTINUITY
#EXTINF:0.5,
getMP4MediaFragment.mp4?FragmentNumber=91343852333181769840281491373487518686823456789&SessionToken=...&TrackNumber=1&SequenceNumber=1"
#EXT-X-DISCONTINUITY
#EXTINF:0.5,
getMP4MediaFragment.mp4?FragmentNumber=91343852333181769845233251530629039917934567890&SessionToken=...&TrackNumber=1&SequenceNumber=1"

#COMMAND フィールドは、設定タグです。たとえば、#EXT-X-PLAYLIST-TYPE:EVENT タグは、ライブメディアプロデューサーがアクティブである限り、マニフェストにフラグメントが追加され続けることを示します。このタグが設定されている場合、メディアプレーヤーは、#EXT-X-ENDLIST タグ（HLS 終了イベント）を受信するまで、更新されたフラグメントをプレイリストに継続的にポーリングします。

getMP4MediaFragment.mp4 フィールドは、ベース URL に追加され、KVS 内の個々のメディアフラグメントへの完全なリンクを作成するために使用されます。

KVS は、ユーザが選択したデバイスとメディアプレーヤで動画を再生する場合でも、低遅延メディアをサポートするために、遅延を最適化した構成で HLS メディアプレイリストを要求する手段を提供しています。

まとめ

Amazon Kinesis Video Streams で管理するメディアのエンドツーエンドのレイテンシを低減する方法に関するシリーズの Part 1 では、ストリーミングメディアの基本的な事項について説明しました。また、KVS の操作、一般的なデザインパターン、そして最後に KVS のストリーミングメディアのレイテンシの主な要因について学びました。

Part 2 では、フラグメント長とメディアプレーヤーのバッファサイズを小さくすることで、ストリーミングメディアのレイテンシを低減するテクニックをご紹介します。KVS API から HLS URL をリクエストする際に、最適な HLS プレイリスト設定を選択し、低遅延なメディアを実現する方法について学びます。また、堅牢なビデオ品質と遅延を最適化したメディアストリームの推奨設定と、Amazon KVS Web Viewer を使用したテスト方法についても学びます。

著者について

Dean Colcott は、Amazon Web Services (AWS) のシニア IoT and Robotics スペシャリストソリューションアーキテクトで、Amazon Kinesis Video Streams の SME を務めています。分散アプリケーションとフルスタック開発、ビデオとメディア、ビデオ分析とコンピュータビジョン、産業用 IoT とエンタープライズデータプラットフォームに深い専門性を持っています。IoT、産業用データ、ビデオ、物理的資産が生成するデータから、企業データ戦略との関連性、価値、洞察を得ることにフォーカスしています。

この記事はソリューションアーキテクトの三平が翻訳しました。

Amazon Web Services ブログ