LoginSignup
12
11

動画配信技術に入門する

Last updated at Posted at 2023-09-19

動画配信の流れ

DeNAの動画配信サービスを支えるインフラの内部 #denatechcon
image.png

動画配信技術について - Speaker Deck
image.png

ライブ配信を支える技術と知識 | BLOG - DeNA Engineering
image.png

エンコード

ライブ配信:エンコード/エンコーダーとは? ソフトウェアとハードウェア、モバイルエンコーダーの解説 - Jストリーム
エンコードとは、カメラ映像や音声をインターネット伝送に適した形式やビットレートに変換することを指します。

ビデオ コーデック と エンコード、 知っておきたい最新情報 [ Wowza Blog 翻訳 ] | DPSJ
ビデオエンコードとは、元のビデオデータから数多くのデバイスとの互換性を持つデジタルフォーマットに変換するプロセスのことです。ストリーミングの場合では、ギガバイト単位のデータからメガバイト単位のデータに圧縮されることが多いです。ビデオエンコードは、ライブストリーミングに不可欠であり、確実で迅速な配信と再生を可能にします。
...
元のビデオデータをより扱いやすいサイズに圧縮するために、エンコードはビデオやオーディオのコーデックを使用して、かさばるビデオデータを配信用に縮小させるアルゴリズムを適用させます。簡単に言うと、エンコードとは圧縮のプロセスで、コーデックとは圧縮の手段ということです。

コーデック

ビデオ コーデック と エンコード、 知っておきたい最新情報 [ Wowza Blog 翻訳 ] | DPSJ
コンテンツ配信業者は、コーデックと呼ばれるビデオ圧縮技術を用いて、ビデオデータをストリーミング可能なサイズに縮小します。コーデックを使うことで、大きなサイズのデータを圧縮して、配信や保管することができます。
コーデックとは、「符号化-復号化」または「圧縮-伸張展開」に特化した仕組みまたは機能性のことで、映像にアルゴリズムを適用し、その複製を作成するものです。ストリーミングの場合、コーデックは不要なデータを捨てる非可逆圧縮を採用しており、ビデオデータは保管や伝送のために縮小され、後に視聴する際に解凍されます。

動画配信技術について - Speaker Deck
image.png
image.png

コンテナ

【MP4・MOV等】動画のコンテナとは?コーデックとの違い(図解あり)│月額19,800円から始められるITアウトソーシング(ITO)|オフィスドクター(OFFICE DOCTOR)
「コンテナフォーマット(container format)」とは映像データと音声データなど複数のファイルを格納し合わせるファイル形式です。通称「コンテナ」と略されます。
動画ファイルは音声と映像の二つのデータが入っています。これらをまとめ、同期させることで動画として成立させるのが動画ファイル形式のコンテナです。
このようなコンテナは「マルチメディアコンテナ」と呼ばれています。
動画ファイル以外には、音声や画像を圧縮するための専用のコンテナもあります。
image.png

映像コンテナ (マルチメディアコンテナ) には以下のようなものがあります。 これらは動画や音声を格納することができます。

動画配信技術について - Speaker Deck
image.png

ライブ配信を支える技術と知識 | BLOG - DeNA Engineering
コンテナにデータを入れることを Mux
コンテナからデータを取り出すことを Demux
と呼びます。
Mux は Multiplexing のことで多重化とも呼んでいます。
image.png

トランスコード

ビデオ コーデック と エンコード、 知っておきたい最新情報 [ Wowza Blog 翻訳 ] | DPSJ
トランスコードとは、エンコードされたファイルをデコードして、何らかの変更を加えることです。データをより一般的なコーデックに再エンコードしたり、映像をより低い解像度に変換したり、ファイルを異なるビットレートに変換したり、よりスケーラブルなプロトコルに変換したりするといったことが含まれます。
処理が完了すると、メディアサーバーは操作されたファイルを再圧縮して配信します。
トランスコードによって、H.264 にエンコードされたビデオを VP9 や H.265 にエンコードされたビデオへと自由に変更することができます。これにより、4K ストリーミングに最適化されたコンテンツを、スピーディにエンドユーザーに提供することが可能になります。

Ingestion と Egress における配信プロトコル

様々な配信プロトコルが存在しており、これをみるだけでお腹いっぱいです。

WebRTC live streaming to unlimited viewers, with sub-second latency
Ingestion — how broadcasters should send media content (akin to RTMP today)
Egress — how viewers request and receive media content (akin to DASH or HLS today)

Media Ingestion protocols Review
image.png
image.png

最近では RTMP で Ingestion し、HLS で Egress (delivery) することが多いようです。

RTMP Streaming: What Is the Real-Time Messaging Protocol?
image.png

RTMP Streaming: What Is the Real-Time Messaging Protocol?
image.png

WHIP and Janus @ IIT-RTC 2021
image.png

また、以下のページにも対応ソフトウェアとともに、よくまとまっています。

エンコーダ・配信ソフト

Ingestion に使う配信ソフトの例です。

配信プロトコルごとの遅延

HLS で1秒以下の遅延を実現することは難しいため、その場合は WebRTC が検討対象に上がる。

WOWZA media systems / DPSJより引用
image.png

ライブ動画ストリーミングプロトコルと遅延ゼロへの競争 | 低遅延ライブストリーミング技術情報
image.png

メジャーな配信プロトコルピックアップ

動画配信技術について - Speaker Deck
image.png

RTMP

  • TCPベースのため、信頼性が高いが、遅延と輻輳の影響は受ける
  • 歴史上、Ingestion で対応していないソフトウェアやプラットフォームは少ない
  • 再生の互換性はほぼないため、Egress では使われない

様々なストリーミング配信で乗り越えよう ~JANOG49~
image.png
image.png

RTMP 代替案 [ Wowza Blog 翻訳 ] | DPSJ
RTMP はかつて、メディアのインジェストとイーグレスの両方において標準的なプロトコルでした。最近では、最も人気のあるインジェストプロトコルであり続けています。しかし、ストリーミングプロトコルは進化し続けており、特に最近では WebRTC の成長により、開発者がいつまで RTMP に頼るのか、それとも数ある RTMP の代替プロトコルに頼るのかは分かりません。
...
RTMP とは、Real-Time Messaging Protocol の略です。プレイヤーのクライアントとサーバの間で、TCP(Transmission Control Protocol)接続を一定に保つことで動作します。この TCP 接続は、クライアントとサーバのハンドシェイクを必要とし、安定した接続と信頼性の高いストリームを保証します。
...
しかし、HLS や MPEG-DASH などのHTTP ベースのプロトコルは、最終的に配信側で RTMP に取って代わりました。Apple 社のデバイスは、再生に RTMP をサポートしていなかったため、この問題に直面し、人々に HLS を使用するように促しました。さらに、Adobe が Flash のサポートを終了すると発表したことで、ブラウザは RTMP のサポートを終了し、ラストマイル配信のための RTMP の使用は現状。

HLS / MPEG-DASH

  • 互換性の高さ

RTMP 代替案 [ Wowza Blog 翻訳 ] | DPSJ
HLS は最も広く互換性のあるイーグレスプロトコルであり、様々な再生デバイスの視聴者にリーチしたいと考える人にとって理想的なプロトコルとなっています。また、HTTP ベースのプロトコルは、CDN を介してより多くの視聴者に簡単にスケーリングできます。さらに、HLS と DASH はどちらも DRM、キャプション、広告挿入をサポートしています。

ストリーミング配信、ライブ配信に使えるAbema TVで活躍するHLSの強みと課題
例えば、HLSは特定のOS、あるいはブラウザに依存せず、自由に再生することができる点が強みです。
HLSはAppleが開発した再生技術ですが、ハードウェアを開発している企業の技術は、基本的に特定のOSやハードに依存、あるいは優遇しているケースが目立ちます。
しかしながら、HLSはMacやiPhone、SafariのようなApple製品に限らず、Windows、Android環境においても問題なく再生することができます。

  • アダプティブビットレート(ABR)ストリーミングが可能

ライブ動画ストリーミングプロトコルと遅延ゼロへの競争 | 低遅延ライブストリーミング技術情報
HLSやMPEG-DASHなどHTTPベースのライブストリーミングプロトコルは、HLSプレイリストやMPEG-DASHマニフェストに記載した各種ビットレートで動画セグメントをエンコードすることにより、可変ビットレートを実現します。この方法では、コンテンツの再生中に、クライアントはビットレート適応(ABR)アルゴリズムを使用して、再生中に中断や再バッファリングイベントを発生させずに再生に間に合うようにダウンロードできる、できるだけ高いビットレートのセグメントを自動的に選択します。

YouTubeやTwitchで人気のライブ配信を支える技術とは? - GIGAZINE
HLSは複数のビットレートをサポートし、表示クライアントが複数のビットレートを動的に切り替えることが可能です。例えば、屋外からスマートフォンでライブ配信を見ている人のビットレートは低く、自宅のインターネットでライブ配信を見ている人のビットレートは高くというように振り分けることで、使用する通信帯域幅をぐっと絞ることができるようになります。

  • インデックスファイルとセグメントファイル

HTTP Live Streaming, HLSのまとめ 概要・仕組み・課題など|テレワークナビ
インデックスファイル(.m3u8)
インデックスファイル(.m3u8)はプレイリストと呼ばれることもあるファイルです。EXT-X-TARGETDURATIONにより各tsファイルの秒数を指定したり、EXT-X-PLAYLIST-TYPEにより配信形式を指定したりする役割を持ちます。また、tsファイルの順番や秒数、ファイル名を定義して動画をスムーズに再生させるように記述されています。
セグメントファイル(.ts)
動画コンテンツを格納したファイルです。細かく分割されており、AESによる暗号化も可能です。インデックスファイルに定義された規則に従って再生されます。

動画配信方式について整理してみた。. 前回こちらの記事で「動画の概要と仕組み」について整理しましたが、今回はその動画の… | by tonteki4 | Medium
HLS
image.png
MPEG-DASH
image.png

  • HTTP ベースのため、CDN でキャッシュ処理させることが容易など、CDN との親和性が高い

動画CDNとは? | CDN動画ストリーミング | Cloudflare
ストリーミングされる動画は、小さなセグメントに分割されています。各セグメントは、ユーザーの動画プレーヤーに読み込まれ、正しい順序に配置されます。
画像やHTMLページ、JavaScriptのスニペットがCDNにキャッシュされるのと同様に、個々の動画のセグメントもCDNにキャッシュすることができます。ユーザーがストリームをリクエストすると、CDNはストリームのオリジンから動画のセグメントが到着すると同時にキャッシュを開始します。次のユーザーが同じストリームをリクエストすると、CDNは代わりにキャッシュからそれらのセグメントを配信することができ、より高速になります。

  • ブラウザ環境向けの JavaScript ベースのプレイヤー

ビデオストリーミング技術の紹介 | LiveInstantly, LLC.
シンプルな Web プレイヤーの開発と展開 | LiveInstantly, LLC.
以下のオープンソースのプレイヤーが市場では多く利用されています。

  • HLSとDASH:主な違いは?

MPEG-DASHとは?| HLSとDASH | Cloudflare
しかし、2つのプロトコルを区別するいくつかの重要な違いがあります。

  • エンコードフォーマット:MPEG-DASHでは、任意のエンコード標準を使用できます。一方、HLSではH.264またはH.265の使用が必須です。
  • デバイスのサポート:HLSは、Appleデバイスでサポートされている唯一の形式です。iPhone、MacBook、およびその他のApple製品は、MPEG-DASHで配信された動画を再生できません。
  • セグメントの長さ:これはHLSのデフォルトのセグメント長が10秒であった2016年以前のプロトコルと大きく違う点です。現在、HLSのデフォルトの長さは6秒ですが、デフォルトを調節することも可能です。MPEG-DASHセグメントの長さは通常2~10秒ですが、最適な長さは2~4秒です。
  • 標準化:MPEG-DASHは国際標準です。HLSはAppleによって開発され、広く支持されているにもかかわらず、国際標準として公開されていません。

WebRTC

  • 遅延が小さい

RTMP 代替案 [ Wowza Blog 翻訳 ] | DPSJ
WebRTC の最大のセールスポイントは、1 秒以下の遅延であり、ほぼリアルタイムのインタラクティブなストリーミングに理想的な選択肢となります。

動画配信技術について - Speaker Deck
image.png

WebRTC コトハジメ
環境や回線やマシンパワーに依存する。好条件であれば 200 ミリ秒程度の遅延で配信が可能。
この辺りの 1 秒未満の遅延については超低遅延 (Sub-second latency) と呼ばれている。
超低遅延、つまり 200-300 ミリ秒で双方のやり取りが可能になる。

  • なんといってもブラウザだけあれば使える

WebRTC コトハジメ
ブラウザというよく使われるものに、標準で実装されているということがとても大きい。 ブラウザさえあればリアルタイムで音声や映像のやり取りを行えることになる。
今まで音声や映像をリアルタイムにやり取りするためには専用のクライアントが必要になることがほとんどだった。 それがブラウザさえあれば、よくなった。

  • Ingestion (WHIP, WebRTC-HTTP Ingest Protocol) と Egress (WHEP, WebRTC-HTTP Egress Protocol) の両方で使える

WHIPとWHEPの違いについて | meteor Tech Blog
基本的なネゴシエーションはWHIPと同様ですが、視聴に特化した機能があります。
まず、Server Sent Events REST APIです。これは、WHEPで接続した際に、サーバから送られてくるAPIですが、配信のステータス(active/inactive)や、視聴者数(viewercount)や、配信画面の詳細な情報(layer)をクライアントに送ることが出来ます。これにより入室した際に、配信サーバ側から正確なデータが取得できるので、いわゆる視聴者数のズレなどが起きにくくなります。
また、layerを活用することで、Adaptive-Bitrateを実現することもできます。

ブラウザを使った WHIP-WHEP 最小セットアップ

Cloudflare Stream を使えば、以下のようなブラウザを使った構成で簡単に試すことができます。

WHIP Client (Browser) -- ingestion --> Cloudflare Stream -- egress --> WHEP Client (Browser)

WebRTC live streaming to unlimited viewers, with sub-second latency
image.png

コードは以下にあるものを参考にしてください。

Cloudflare Stream で Live Inputs を作成して、自分の WHIP / WHEP URL を使うこともできますが、
image.png

以下のデモサイトで動きを確認することができます。

以下、Mac と iPhone を使って試した結果です。

1秒より小さい遅延であることが見て確認できます。

その他参考リンク

12
11
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
12
11