図解 H.265 入門 (0) 全体地図：コーデック・コンテナ・プロトコル

この記事の本文は AI（Claude Code）で生成し、筆者が全文を読んで内容を確認したものです。事実と数値は脚注の一次資料と手元の実測で裏を取っています。

会社で H.265 を採用することになったのを機に、動画コーデックの基礎から勉強し直したので、その内容を 0〜8 章の全 9 本のシリーズにまとめました。動画について調べると「コーデック」「コンテナ」「プロトコル」といった用語が一度にたくさん出てきて、どの用語が何を決めているのかで混乱しやすいです。この 0 章で用語どうしの関係を押さえておくと後ろの章が読みやすくなるので、最初にここだけでも読んでもらえると嬉しいです。

このシリーズは、H.265 をブラウザで扱うために必要な知識を、画素の成り立ちから始めて、実際にエンコードして測るところまで順に説明していくものです。 この 0 章では、動画を扱うときに必ず出てくる「コーデック」「コンテナ」「配信プロトコル」の 3 つの層を整理し、H.265 がその中のどこに位置する規格なのかを確認します。 あわせて、シリーズ全章の地図と用語集、読む順の提案を置いておきます。

TL;DR

• 動画は「コーデック（どう圧縮するか）」「コンテナ（どう詰めるか）」「配信プロトコル（どう運ぶか）」の 3 層に分かれ、それぞれ独立に差し替えられます
• H.265 は 3 層のうちコーデック層の規格です。2 つの標準化グループ（VCEG と MPEG）の合同チーム JCT-VC が策定し、ITU-T H.265 と ISO/IEC 23008-2 は同じ規格に付いた 2 つの番号です¹
• 最初の版は 2013 年 4 月に出ました。規格はその後も改訂され続けていて、2026 年 9 月時点の現行版は 2026 年 1 月の版です²
• ブラウザで H.265 が面倒なのは、特許のライセンス構造と、再生がハードウェアデコードの有無に左右されるためです（詳細は → 7 章『ブラウザで H.265：対応状況・判定 API・特許』）
• 本章の後半に、シリーズ全 9 章の地図・用語集・読む順の提案を置いています

3 つの層：作る・詰める・運ぶ

層の分担

ブラウザで動画を再生するまでには、生の映像をエンコード（符号化）し、ファイルに詰め、ネットワークで運び、最後にデコード（復号）して表示する、という流れをたどります。

flowchart LR
  A["生の映像<br/>画素の並び"] --> B["エンコード<br/>コーデック層"]
  B -->|HLS| C["格納<br/>コンテナ層"]
  C --> D["運搬<br/>配信プロトコル層"]
  B -->|WebRTC| D
  D --> E["デコード<br/>コーデック層"]
  E --> F["表示<br/>video 要素"]

3 つの層の役割は次のように分かれています。

大事なのは、この 3 層が互いに独立していることです。H.265（HEVC、High Efficiency Video Coding）でエンコードすると、コーデックが定めた並びのビット列であるビットストリーム（bitstream）ができます。これをフラグメント MP4（fMP4、fragmented MP4）に詰めても MPEG-2 TS（Transport Stream）に詰めても、ビットストリームを意味のある単位に区切った塊である NAL ユニット（Network Abstraction Layer unit）1 つ 1 つの中身は変わりません。変わるのは、NAL ユニットどうしをどう区切るかと、パラメータセット（復号に必要な設定をまとめた NAL ユニット）などをどこに置くかです。運ぶときも、HLS（HTTP Live Streaming）ならコンテナに詰めたセグメントを HTTP で運び、WebRTC ならコンテナを通さずに NAL ユニットを直接 RTP（Real-time Transport Protocol）のパケットに載せます。どちらの運び方でも、中を流れる NAL ユニットは同じです（→ 6 章『コンテナと伝送：fMP4・TS・HLS・RTP』）。そのため「MP4 が再生できない」と言われたときは、原因がコンテナの形式にあるのか、中に入っているコーデックにあるのか、配信の経路にあるのかを分けて調べる必要があります。原因がどの層にあるかを見分けられるようになることが、このシリーズの実務上の目標のひとつです。

3 層を通って映像がどう姿を変え、データ量がどう増減するのかを、1 本の流れとして見てみます。

1 本の映像が、生の画素からビットストリーム、セグメント、パケットと姿を変えて運ばれ、最後にまた画素へ戻るまでの流れです。下のバーはデータ量の目安で、圧縮で大きく縮み、復号で元に戻ることを表しています。長さは縮尺どおりではありません。

アナロジー：圧縮されたページ・バインダー・郵送

この 3 層は、文書に例えると掴みやすくなります。コーデックは、映像を「順番に並んだ、圧縮されたページの束」に変えるものです。コンテナは、そのページを綴じ、ページ番号を振り、目次を刷り、どこが章かを示し、本文が何語で書かれているかを記すバインダーです³。配信プロトコルは、コンテナのバイト列をある機器から別の機器へネットワーク越しに動かすための規則の集まりで³、ここではバインダーを相手に届ける郵送の取り決めにあたります。

ページの圧縮のされ方を知らなければページは読めず（コーデック）、綴じ方と目次がなければどのページから読めばよいか分からず（コンテナ）、届け方が決まっていなければ手元に来ない（配信プロトコル）、というわけです。

例えと実際の配信には違う点もあります。郵送ではバインダーを丸ごと 1 個届けますが、実際の配信ではバインダーを数秒ずつの束に切り分けて順番に届けます。しかも、WebRTC がメディアを運ぶのに使う RTP には、時間内の配送や品質を保証する仕組みがなく、配送そのものも順序も保証されません⁴。このように「届いたら中身は完全」という前提が成り立たないので、配信プロトコル層はコーデックやコンテナとは別に学ぶ必要があります（→ 6 章『コンテナと伝送：fMP4・TS・HLS・RTP』）。

H.265 はどこに位置するのか

誰が決めた規格なのか

H.265 は、3 層のうちコーデック層の規格です。策定したのは、ITU-T の VCEG（Video Coding Experts Group）と ISO/IEC の MPEG（Moving Picture Experts Group）という 2 つの標準化グループから、映像符号化の専門家が集まって 2010 年に作った合同チーム JCT-VC（Joint Collaborative Team on Video Coding）です¹。

この 1 つの規格には、よく目にする呼び名が 3 つあります。JCT-VC の成果は ITU、ISO、IEC から中身がまったく同じ規格（twin text）として出ていて、ITU-T H.265 と ISO/IEC 23008-2 は同じものを指します¹。さらに、規格の名前そのものである HEVC（High Efficiency Video Coding）で呼ばれることも多くあります。資料によって使う呼び名がまちまちなので別々の規格だと思ってしまいがちですが、どの呼び名で書かれていても同じ規格を指しています。このシリーズでは H.265 に統一します。

JCT-VC が掲げた目標は、当時最新だった H.264（AVC、Advanced Video Coding）に比べて、高画質な映像に必要なデータ量をさらに半分にすることでした¹。よく聞く「H.265 は H.264 の半分」という数字はこの目標と同じ数字ですが、実際にどの条件でデータ量がどれだけ減るのかは、測り方によって変わります。この数字が成り立つ条件は → 5 章『H.265 で何が変わったか』で扱います。

規格の系譜

主なコーデック規格を、最初の版が承認・公開された時期とともに整理します。

規格は最初の版が出た後も改訂され続けます。2026 年 9 月時点の現行版は、H.265 が 2026 年 1 月²、H.264 が 2026 年 6 月⁵、H.266（VVC、Versatile Video Coding）が 2026 年 1 月の版です⁸。ネット上の解説が古い版を前提にしていることもあるので、規格の細かい規定を確かめるときは、参照している版の日付も確認すると安全です。

なぜブラウザで H.265 が面倒なのか（予告）

H.264 は Chrome、Edge、Firefox、Opera、Safari の全バージョンで再生できます⁶。一方 H.265 は、すべてのブラウザで再生できるわけではありません。その理由は 2 つに整理できます。

1 つは特許です。H.265 は多数の特許の対象になっているプロプライエタリな形式で⁶、特許権者が特許をまとめて一括でライセンスするパテントプール（patent pool）が許諾の主な窓口になります⁹。2026 年 9 月時点で主なパテントプールを運営しているのは Access Advance です。自前の HEVC Advance¹⁰ に加えて、Via LA が運営していた H.265 / H.266 のプログラム（名称は HEVC/VVC）も 2025 年 12 月に取得しました⁹¹¹。誰が誰にライセンス料を払っているのかは → 7 章『ブラウザで H.265：対応状況・判定 API・特許』で扱います。

もう 1 つは、機器に内蔵された専用回路でデコードするハードウェアデコード（hardware decoding）に再生が頼っていることです。2026 年 9 月時点で、Chrome は Windows 8 以降・Linux・ChromeOS ではハードウェアで対応している機器に限って H.265 を再生でき、macOS Big Sur 11 以降と Android 5.0 以降では機器を問わず再生できます⁶。つまり、再生できるかどうかはブラウザ名だけでは決まらないので、OS と機器まで含めて実行時に判定する必要があります。この判定の書き方と、ライセンス条件によってブラウザごとの対応にどんな差が出ているかは → 7 章『ブラウザで H.265：対応状況・判定 API・特許』で扱います。

ただし「H.264 は無条件、H.265 だけが特許で面倒」という単純な対比ではありません。Firefox の H.264 対応は、特許上の懸念を避けるため、OS に組み込み済みまたはプリインストールされたコーデックに依存しています⁶。

シリーズの章立て

全 9 章の地図です。

シリーズ用語集

シリーズ全体で繰り返し出てくる用語の索引です。意味は一言に留めてあるので、詳しくは「詳しく扱う章」を読んでください。コーデック・コンテナ・配信プロトコルなど、この章で出てきた用語は章末の「この章で出てきた用語と規格」にまとめてあります。

読む順の提案

章は、0 から順に読むと前の章の内容を土台に次の章を理解できるように書いていますが、目的によっては飛ばして読めます。

flowchart TD
  S["0 章 全体地図"] --> A1["1 章 動画データ"]
  A1 --> A2["2 章 圧縮の数学"]
  A2 --> A3["3 章 予測と GOP"]
  A3 --> A4["4 章 H.264 の復習"]
  A4 --> A5["5 章 H.265 の差分"]
  A5 --> A6["6 章 コンテナと伝送"]
  A6 --> A7["7 章 ブラウザ実務"]
  A7 --> A8["8 章 ハンズオン"]
  S -.実務ルート.-> A7
  A7 -.詰まったら.-> A6
  A7 -.詰まったら.-> A5
  A7 -.詰まったら.-> A4
  A8 -.CRF が分からなければ.-> A2
  A8 -.詰まったら.-> A3
  A8 -.詰まったら.-> A6

ルート A：基礎から順に読む

0 章 → 1 章 → …… → 8 章の順です。圧縮でなぜデータ量が減るのかを理解したうえで、H.265 で加わった工夫を読みたい場合はこのルートです。2 章と 3 章には、DCT の基底が重なって画像が組み上がる様子や、動き補償のブロック探索といった、動きのある図を多く置いています。数式が続く章でもありますが、「アナロジー → 定義・数式 → 数値例」の順で書いているので、数式で詰まったら 1 つ前のアナロジーに戻れば追えるはずです。

ルート B：実務だけ急ぐ

「今すぐブラウザで H.265 を再生できるか判定したい」という場合は、0 章 → 7 章 → 8 章だけを読んで、分からないところが出てきたら前の章に戻って読むのが早いです。戻り先の目安は次の通りです。

• 7 章で hvc1.1.6.L93.B0 のような codecs パラメータの中身（プロファイル・ティア・レベル）が分からなくなったら → 5 章『H.265 で何が変わったか』の hvc1.1.6.L93.B0 の読み方へ。hvc1 と hev1 の違いは → 6 章『コンテナと伝送：fMP4・TS・HLS・RTP』へ。さらにプロファイル・レベルの意味が分からなければ → 4 章『H.264 の復習：マクロブロック・NAL ユニット・パラメータセット』のプロファイルとレベルの説明へ
• 7 章で「エンコード時の設定によって再生できたりできなかったりする」理由が分からなくなったら → 5 章『H.265 で何が変わったか』のプロファイルとティアの説明、および → 4 章『H.264 の復習：マクロブロック・NAL ユニット・パラメータセット』の SPS／PPS の説明へ
• 8 章で CRF の値を動かしても何が変わっているのか掴めなければ → 2 章『圧縮の数学：DCT・量子化・エントロピー符号化』の QP の説明へ
• 8 章の -g と B フレーム、ffprobe の表示順と復号順で詰まったら → 3 章『フレーム間予測と GOP』へ
• 8 章のボックス・hvc1・SDP で詰まったら → 6 章『コンテナと伝送：fMP4・TS・HLS・RTP』へ
• ライブ配信の遅延を短くしたくなったら → 3 章『フレーム間予測と GOP』の GOP 長の説明へ

なお 7 章は → 6 章『コンテナと伝送：fMP4・TS・HLS・RTP』の MSE と hvc1 / hev1、→ 5 章『H.265 で何が変わったか』の codecs パラメータの読み方を前提にしているため、実務ルートでも 5 章の hvc1.1.6.L93.B0 の読み方を説明する節と 6 章には目を通しておくと、読み進める途中で前の章へ戻る回数が減ります。

まとめ

動画まわりの用語がこんがらがるのは、「圧縮方式」「ファイル形式」「配信方式」という別々の層の名前が、どれも「動画の形式」という一言でまとめて語られるからです。H.265 はこのうち圧縮方式、つまりコーデック層の規格です。2 つの標準化グループ（VCEG と MPEG）の合同チーム JCT-VC が作り¹、最初の版は 2013 年に出ました²。

そしてブラウザで H.265 を扱うときの面倒さは、コーデック層の技術的な難しさではなく、特許のライセンス構造とハードウェアデコードの有無という、規格の外側の事情から来ています⁶。この構造を理解するために、次章からはいったん圧縮の仕組みそのものを詳しく見ていきます。

H.265 そのものの変更点は → 5 章『H.265 で何が変わったか』でまとめて扱うので、それまでの 1〜4 章は動画データと圧縮の基礎に付き合ってもらえれば。

この章で出てきた用語と規格

出典