Qiita Teams that are logged in
You are not logged in to any team

Log in to Qiita Team
Community
OrganizationEventAdvent CalendarQiitadon (β)
Service
Qiita JobsQiita ZineQiita Blog
19
Help us understand the problem. What is going on with this article?

More than 1 year has passed since last update.

@daisukeoda

動画の基礎知識まとめ

もし何か間違っていたら優しく教えてください。

コンテナ・コーデックの関係

コンテナとは

映像と音声ファイルを1つのファイルにまとめるときに使用するファイルフォーマットがコンテナ。ファイルをコンテナにまとめる事を、コンテナ化や多重化、Muxと呼んだりする。またコンテナからデータを取り出す事をDemuxと呼ぶ。ちなみに音声ファイルのみの場合は音声ファイル用のコンテナが使われる。

また、コンテナによって字幕表示に対応していたりストリーミング再生に対応していたり、逆に対応していなかったりと、それぞれ機能の違いがある。

映像・音声が入るコンテナ

  • AVI
  • MP4
  • MPEG
  • WMV
  • MPEG2-TS
  • MPEG2-PS
  • FLV
  • WebM

など

音声コンテナ

  • MP3
  • MP2
  • M4A/MP4
  • Opus

- Vorbis

など

コーデックとは

動画・音声データの圧縮アルゴリズム。コンテナに応じて対応するコーデックが違う。

主要コーデック

[MPEG-2]

4〜16Mbps程度の転送レートの動画圧縮フォーマット。DVDや地デジTV通信など様々なメディアや用途での利用を想定して制定された。MPEG-1相当の低解像度からHD/フルHD相当の高解像度まで、4種類の解像度に対応している( ISOのdocsに載ってますが、これなども参考になります。 docshttp://www.netmode.ntua.gr/courses/postgraduate/video_communications/documents/Profiles_MPEG-2.pdf )。また、MPEG2における動画圧縮方式「MPEG-2 Video」では、画質や用途に応じて7種類のプロファイルが用意されている。

MPEG2-TS(TV放送等に使われる)なんかもメジャー。

[MPEG-4]

MPEG-1やMPEG-2よりファイルの圧縮効率が高く、低ビットレートでの使用も想定されている。また特性上転送速度が早くなりやすいことが特徴だったりするが、カバーする範囲が多すぎて一言で「MPEG-4はこういう技術」という説明は難しい。MPEG-4では、技術領域ごとにパートと呼ばれる企画が作成され、技術が採用・規格化されるたびにパートが増える。

DRMがサポートされたり、Part25では3Dグラフィックの圧縮モデル仕様についてとり決められている?そこら辺までは詳しく知らないですが、すごそう。

[H.264(AVC = Advanced Video Coding)]

よくAVCと呼ばれたりする。

MPEG-4 Part10に規定されている動画データ用のコーデック。MPEG-4 Part2にもコーデックが規定されているが、H.264はそれよりも圧縮率が高い。携帯電話などの低ビットレート用途から、HDTVクラスの高ビットレートに到るまで幅広く利用される。またMPEG-2に比べ、同画質なら半分程度のデータ量で済む。MPEG-4 Part2と比べても同画質で少ないデータ容量で表現できる。

ちなみに圧縮アルゴリズムの原理は、従来方式のMPEG-1, MPEG-2などと基本的に同じで、空間変換・量子化(この過程でエントロピー符号化したり)・フレーム間予測を採用している。

フレームレート60fps、4K画質まで対応している(プロファイル・レベルにより異なる)。

[H.265(HEVC = High Efficiency Video Coding)]

H.265はベストエフォートでH.264の2倍程度の圧縮率を誇ります(=MPEG-2の4倍程度の圧縮率)。

H.265では、ブロックサイズが変化量に応じて良い感じに可変長になります。変化の少ないブロックは大きいブロックに。複雑な変化のブロックは小さいブロックにしてオーバヘッドを減らすことで情報量を最適化していきます。

現在フレームレート300fps、8K画質まで対応している(プロファイル・レベルにより異なる)。

[AV1]

Alliance for Open Media(AOM)が開発する動画コーデック。HEVCやVP9よりも高い圧縮効率を誇りさらにロイヤリティーフリーで使える。

効率が良い分、エンコード・デコードにかかるリソースも増えるので、2020年時点でもまだまだ手軽に使えるとは言えないと思いますが、これからの動向に期待です。

[Opus]

2012年にIETFによって開発された非可逆な音声圧縮フォーマット。非常に低いレイテンシを実現でき、一般的な音楽ファイルにも有用なコーデック。低レイテンシであるためWebRTCなんかにも使われたりする。SILK(スピーチ向き)とCELT(低レイテンシで音楽用途に使える)という2つのコーデック技術を組み込んでいる。

[VP6]

On2 TrueMotion VP6(トゥルーモーション ブイピーシックス)の略。米のOn2テクノロジーという企業が開発した動画コーデック。VP5の後継で、全性能がVP5を上回っている。また圧縮率はH.264をはるかに超え、デコードが速い特徴があるが一方でエンコードは遅い。そして、MPEG-2等と比べて、ライセンス料が安い。

画質については、H.264備え付けのフィルタリング機能によく似たデブロッキングフィルター(※)を採用している。このデブロッキングフィルターというのが性能が良いらしく、それ故VP6ではブロックノイズが目立ちづらい。

※デブロッキングフィルターは、データの変換処理などによる映像・画像のブロック状の歪みを緩和するために動き予測と変換のブロック協会にフィルタリング処理を施す。

2020時点では、少なくともIT業界ではプロダクション利用されている例はほとんど無いと言って良いのではないかと思います。

[VP8]

現在、WEBにおいてよく使われているコーデックと言えると思います。具体的にどういう場面で使われがちかというと、WebRTCでデファクトスタンダードなコーデックとして普及しています(webmコンテナをつかうため)。

ライセンス料は無料。

[VP9]

これもOn2テクノロジーが開発した動画コーデック。開発目標が、VP8の半分のビットレートにすることと、H.265より効率の良いコーデックにすることであった。実際VP8と同じ画質において、圧縮率が2倍程度ある。

[AAC(Advanced Audio Coding)]

MP3の後継として1997年に誕生した非可逆の音声コーデック。同程度のビットレートにおいてMP3より高音質。

拡張機能が使用可能かどうかに応じていくつかのプロファイルがあるが、一般的にはAAC-LC(Low Complexity)という基本機能だけ備え付けたプロファイルが使われる。また、1つのストリームに48の全帯域幅音声チャンネルを持たせることができる。
下記にいくつかの種類のAACを簡単に紹介してみる。

  • AAC-LC(AAC Low Complexity)
    • AACの基本機能だけで構成されたもので基本的にAACというとAAC-LCを指す。
    • MP3と比べて低ビットレート時の音質が良い
  • HE-AAC(High-Efficiency AAC)
    • AAC-LCにSBR(スペクトル帯域複製)という擬似補完技術を組み込んだもの。
    • AAC-LCより高圧縮
    • AACの上にSBRが乗っかっているという形式なので、HE-AACに対応してないデコーダでもAAC部分のみ再生できる。低音質になるが。
  • HE-AAC Version2
    • AAC+SBR+PSの構成
    • PS(Parameteic Atereo)とはステレオデータをモノラル化することで圧縮率を高める擬似補完技術。
    • こちらも構成的に、HE-AAC Version2に対応していないデコーダでもAAC部分のみデコードして再生できる。

※VP6より下を書いていなかったんですが、興味があったら..

配信技術・プロトコル

HLS

みんな大好きHTTP Live Streaming。
Appleが開発したHTTPベースのストリーミングプロトコルで、もちろんCBRもABR配信も対応している。

コーデックは主にMPEG2-TSが扱われ、10秒以下の長さで区切られたMPEG2-TSファイルとその区切られたファイルのインデックスがまとまったm3u8というプレイリスト(マニフェスト)を作り、その2つをサーバから配信する。ABRする際はあらかじめ複数ビットレートでエンコードしてそれぞれのビットレートに応じたtsファイル群とm3u8を生成しないといけないのでファイルサイズがかさむ。

ライブ配信でHLSを使うとチャンク生成のためのラグでレイテンシがでがち。チャンクサイズは、観測範囲だと2秒や1秒に区切ることが多いですが、それでもライブ配信時は10〜20秒程度のレイテンシが発生しがちです。

HDS

HTTP Dynamic Streamingの略。HLSと似てるが、HDSはAdobeの動画配信の規格。HLS同様にメディアファイルをセグメント化して配信するが、HDSではセグメント長の推奨値が6秒とされている(変更可能)。

※HLS, HDS両方を配信できるUniversal Streamingという技術をAkamaiが提供している( https://blogs.akamai.com/jp/2013/02/-3---universal-streaminghdshls.html )

MPEG-DASH

Dynamic Adaptive Streaming Over HTTPの略で、よく「DASH」と呼ばれる。HTTPでストリーミングを行うためのISO規格。
HLSと特徴が似ていて、ネットワークの環境に応じて自動的に最適な帯域(Bandwidth)の動画データに切り替える。再生が途切れないように常に切り替えてくれる代物。

HLSと違うのはコーデック・コンテナに依存しないこと。

配信の仕組みは、MPD(Media Presentation Description)というファイルをダウンロードし、そこに記載されてるURIから動画チャンクとしてセグメンテーションファイルを連続的に取得する。(ここもHLSっぽい)

Smooth Streaming

MSが開発したSilver Light向けの配信技術。こちらもHTTPベースで、オンザフライでABRを実現する。

MMT

MPEG Media Transportの略。ISO/ICEが制定するメデイア伝送の国際標準規格。

SRT(Secure Reliability Transport)

UDPプロトコル上でTCPのような信頼性をもつ次世代の動画ストリーミングプロトコル。

RTMP

おなじみの、Adobe製のReal-Time Messaging Protocol。TCPベースのストリーミングプロトコルだ。仕組みとしては、RTMPサーバが動画や音声データを細かくチャンクに分割しクライアント側に配信、受け取ったクライアントはチャンクデータを順番通りにデータを組み立てて再生させる。(ちなみに1ストリームで全てのデータが配信される)

RTMPには機能に応じて変種が数種類存在し、UDPベースのRTMFP(あまり使われていない)や、SSL/TLSで暗号化されたRTMPSなどがある。

クライアント側でポーリング等をしてサーバからデータを取りに行く必要がなく、Server側からPUSHで配信できるのが一つの大きな特徴(遅延が少ない)。また、パケットヘッダのサイズが1, 4, 8, 12byteのどれかで固定になりHTTPと比べて(数百byte程度とする)オーバヘッドがかなり少ない。

RTMPはもともとFlashで利用する目的で開発されたが、2020年にFlashのサポートを終了することから、最近はエンドユーザー向けの配信目的で使うことが減った。が、LODで裏側の中継サーバとしての用途で使う例はよく散見される。

RTSP

Real Time Streaming Protocolの略。音声・映像を効率よく伝送するために制定されたプロトコル。

映像の再生・一時停止・停止・セッション生成&解放などを行うための仕組みが色々定義されている。データの伝送は裏でRTP(Real Time Protocol)プロトコルを使用している。

ABR(Adaptive Bit Rate)

配信側がプレーヤーを監視し、常に最適なビットレートに変化させながら配信するもの。

CMAF(Common Media Application Format)

いくつかの特徴がある。「低遅延でHTTPストリーミングを実現するフォーマット」であり、さらに雑に説明すると「DASHとHLS両方サポートしちゃおう」みたいなノリで生まれたもの。

CMAFでは動画のセグメントを任意のサイズのチャンクに分割できる。クライアント側では、最初のチャンクを受け取り切った段階で再生を開始することができ、しかも先述の通りチャンクサイズを任意で指定できるため低遅延が実現できるらしい。「チャンク(またはセグメント)で分割するとか、HLSとかDASHと一緒やんけ!」と思うかもしれないが、HLSやDASHは最初にマニフェストファイルをダウンロードして、随時更新されるマニフェストファイルを元にチャンクをfetchしながら再生するため、CMAFと比べると遅い。

配信技術に依存しない配信フォーマットと先述したが、CMAFではメディア形式のみを定義している。DASHやMMTなどのMPEGの技術を使う必要はあるが、その制約の範囲内ならどのような配信プロトコルを使っても良い。またコーデックは配信者がどう扱うか決められる。(H.265やVP9、VP10などもサポートしている)。

DRM周り

DRMって?

動画・音声・文章などのデジタルコンテンツを特定のソフト or ハード上でしか再生できないようにして、不正に複製配信されないようにしたり制限を超えた利用枠で悪用されないようにする技術・管理手法のこと。

ストリーミング動画におけるDRM

TV番組、各種VOD動画など著作権保護が必要なコンテンツでDRM使用が必須だったりする。
例えばよくテレビに挿すB-CASカード、あれにはDRMで暗号化されたコンテンツを複合するためのキーが格納されていて視聴の際にそのキーを使って暗号化を解除する。インターネットで配信する動画も同じような感じ。

TVではB-CASカードだったが、動画ストリーミングでよく使われるのがWidevine、PlayReady、FairPlayなどと呼ばれるもの。

Widevineは、Google(厳密にはWidevine Technologies社)が提供するDRM技術。Googleが提供する大体の各種デバイス・ブラウザと、FireFox・Opera、iOSなどで動作する。ちなみにCWIPと呼ばれるライセンスを取らないと本番利用することができない。CTRとCBCを両方サポート。

主にDASHファイルで利用される。

PlayReadyはMicrosoftが開発したDRM技術。最新のIE、Edgeなどで動作する。CTRとCBCを両方サポート。

主にDASHファイルで利用される。Widevineと合わせて、1つのDASHファイルでCENC(Common Encryption)することも多いと思います。

FairPlayはAppleが開発したDRM技術。SafariやiOS、AppleTVなどで動作。AES-CBCモードしかサポートしていない。

HLSで利用可能。

各種企業が参加しているDECE(Digital Entertainment Content Ecosystem)と言う団体が、Ultra Violetと言う標準仕様を制定しているが、AppleのFairPlayはそれに加入していない。ちなみに上記に挙げた3つ以外にもたくさんのDRMがある。

また上記3つのDRMでは、メディアファイルはAES-128で暗号化されることが想定されている。
AES-128にはCTR(Counter)とCBC(Cipher Block Chaining)モードがあり、同じAES-128でも異なるモードで暗号化したら別なファイルが生成されるらしい。


参考文献
19
Help us understand the problem. What is going on with this article?
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
19
Help us understand the problem. What is going on with this article?