wellton/digital_video_introduction
1
0
Fork 0
Código Issues Pull Requests Ações Pacotes Projetos Versões Wiki Atividade

Merge pull request #68 from c-bata/proofread-japanese

Ver Código-Fonte 
Proofread a Japanese translation
Esse commit está contido em:
Leandro Moreira
2018-07-08 14:06:19 -03:00
commit de GitHub
pai fe9d63f99e aa994bc184
commit d171e8c365
1 arquivos alterados com 58 adições e 62 exclusões
Baixar Arquivo de Patch Baixar Arquivo de Diff Expandir todos os arquivos Colapsar todos os arquivos
japanese/README-ja.md
+58 -62
Ver Arquivo
@@ -4,18 +4,18 @@
ビデオ技術のやさしい入門書です。ソフトウェア開発者／エンジニア向けですが、**誰でも理解できるように**やさしく説明したいと思っています。 [ビデオ技術初心者のためのミニワークショップ](https://docs.google.com/presentation/d/17Z31kEkl_NGJ0M66reqr9_uTG6tI5EDDVXpdPKVuIrs/edit#slide=id.p)からこのアイディアが生まれました。
できるだけ**簡潔な言葉、たくさんの視覚的要素、実質的な例**を使っていくつかのデジタルビデオの概念を紹介し、誰でもこの知識を得る機会を提供することが目標です。どうかご自由に訂正や提案を送ったり、改善したりしてください。
できるだけ**簡潔な言葉、たくさんの視覚的要素、具体的な例**を使っていくつかのデジタルビデオの概念を紹介し、誰でもこの知識が得られる機会を提供することが目標です。どうかご自由に訂正や提案を送り、改善してみてください。
いくつかの**ハンズオン** セクションでは**dockerがインストール**されて、このレポジトリがクローンされていることが必要です。
いくつかの**ハンズオン**セクションでは**dockerがインストール済み**で、このレポジトリがクローンされている必要があります。
```bash
git clone https://github.com/leandromoreira/digital_video_introduction.git
cd digital_video_introduction
./setup.sh
```
> **注意**: `./s/ffmpeg` や `./s/mediainfo` コマンドを見ることがありますが、これらのプログラムの **コンテナ化版** を実行していることを意味します。これらはすでに全ての必要条件を満たしています。
> **注意**: `./s/ffmpeg` や `./s/mediainfo` コマンドは、そのプログラムが**Dockerコンテナ上**で実行されることを意味しています。コンテナの中には、すでに必要な依存関係が全て含まれています。
全ての**ハンズオンはこのレポジトリをクローンしたフォルダで実行してください**。 **jupyter examples**については、`./s/start_jupyter.sh`でサーバーを起動して、URLをコピーして、ブラウザにそれを入力してください。
全ての**ハンズオンはこのレポジトリをクローンしたフォルダで実行してください**。 **jupyter examples**については、`./s/start_jupyter.sh`でサーバーを起動して、表示されるURLをブラウザで開いてください。
# 変更履歴
@@ -82,14 +82,14 @@ cd digital_video_introduction
**画像**は**二次元マトリクス**として考えることができます。**色**を考慮すると、画像を**色のデータ**を表すための**もう一つの次元**を持った**三次元マトリクス**として捉えることができます。
これらの色を[原色 (赤、緑、青)](https://ja.wikipedia.org/wiki/%E5%8E%9F%E8%89%B2)で表現すると、三つの平面を定義することになります。一つめが**赤**、二つ目が**緑**そして三つ目が**青**色です。
これらの色を[原色 (赤、緑、青)](https://ja.wikipedia.org/wiki/%E5%8E%9F%E8%89%B2)で表現すると、三つの平面を定義することになります。一つめが**赤**、二つ目が**緑**そして三つ目が**青**です。
![an image is a 3d matrix RGB](/i/image_3d_matrix_rgb.png "画像は三次元マトリクスです")
マトリクスのそれぞれの要素を**ピクセル** (画素)と呼びます。一つのピクセルはその色の**輝度** (通常は数値)を表します。例えば、**赤ピクセル**は緑が０、青が０、赤が最大を意味します。**ピンク色ピクセル**もこれら三つの値で表現できます。０から２５５の数値で表現することにより、ピンクピクセルは**赤=255、緑=192、青=203**と定義されます。
マトリクスのそれぞれの要素を**ピクセル** (画素)と呼びます。一つのピクセルはその色の**輝度** (通常は数値)を表します。例えば、**赤ピクセル**は緑が0、青が0、赤が最大を意味します。**ピンク色ピクセル**もこれら三つの値で表現できます。0から255の数値で表現することにより、ピンクピクセルは**赤=255、緑=192、青=203**と定義されます。
> #### カラー画像を符号化する別の方法
> 画像を形成する色を表現するためには、他にも多くのモデルが使えます。例えば、色を表現するのにRGBモデルでは３バイト使うのに対して、１バイトしか使わないインデックスパレットを使うことができます。そういったモデルでは、色を表現するために三次元モデルを使わずに二次元モデルを使用できるできるでしょう。メモリを節約できますが、色の選択肢を狭めることになります。
> 画像を形成する色を表現するためには、他にも多くのモデルが使えます。例えば、色を表現するのにRGBモデルでは3バイト使うのに対して、1バイトしか使わないインデックスパレットを使うことができます。そういったモデルでは、色を表現するために三次元モデルを使わずに二次元モデルを使用できるできるでしょう。メモリを節約できますが、色の選択肢を狭めることになります。
>
> ![NES palette](/i/nes-color-palette.png "ファミコンパレット")
@@ -99,13 +99,13 @@ cd digital_video_introduction
**赤色**が最終的な色に対して**より貢献している** (二番目の顔の最も明るい部分)ことが分かります。一方**青色** の貢献は服の一部と**マリオの目にしかみられません**(最後の顔) 。**マリオのひげ**に対しては、**全ての平面があまり貢献していない**(最も暗い部分)ことが分かります。
各色の輝度では**ビット深度**として知られる一定量のビットが不可欠です。色(平面)ごとに(0から２５５の値で表現する)**8ビット**を使うとすると、**24 (8 X 3)ビット**の**色深度**を持つことになり、２の２４乗種類の色を使えることが推論できます。
各色の輝度では**ビット深度**として知られる一定量のビットが不可欠です。色(平面)ごとに(0から255の値で表現する)**8ビット**を使うとすると、**24 (8 X 3)ビット**の**色深度**を持つことになり、2の24乗種類の色を使えることが推論できます。
> [画像がどのように万物をビットとしてとらえるのか](http://www.cambridgeincolour.com/tutorials/camera-sensors.htm)を学ぶと **良い**でしょう
もう一つの画像のプロパティは **解像度**です。解像度は長さあたりのピクセルの数です。解像度はよく幅 x 高さとして表現されます。例えば、下記は**4×4**の画像です。
![image resolution](/i/resolution.png "画像解像度")
![image resolution](/i/resolution.png "画像解像度")
> #### ハンズオン: 画像と色の実験
> [jupyter](#jupyterの使い方) (python、numpy、matplotlib、その他)を使って、[画像と色の実験](/image_as_3d_array.ipynb)をしましょう。
@@ -131,7 +131,7 @@ cd digital_video_introduction
> ビットレート = 幅 x 高さ x ビット深度 x フレームレート
例えば、圧縮を全く使わないなら、フレームレートが３０で、ピクセルあたりが２４ビットで、解像度が480x240のビデオは、**秒間あたり82,944,000ビット**もしくは82.944 Mbps (30x480x240x24)が必要です。
例えば、圧縮を全く使わないなら、フレームレートが30で、ピクセルあたりが24ビットで、解像度が480x240のビデオは、**秒間あたり82,944,000ビット**もしくは82.944 Mbps (30x480x240x24)が必要です。
**ビットレート**がほとんど一定なら、固定ビットレート(**CBR**)と呼ばれます。ビットレートが変動するなら、可変ビットレート (**VBR**)と呼ばれます。
@@ -139,13 +139,13 @@ cd digital_video_introduction
>
> ![constrained vbr](/i/vbr.png "制約付きのvbr")
黎明期に、技術者たちが**帯域幅を増やさずに**ビデオ画面で認識できるフレームレートを倍にする技術を思いつきました。この技術は**インターレース動画**として知られています。基本的には一つ目の「フレーム」中で画面の半分を送り、次の「フレーム」で残りの半分を送ります。
黎明期に、技術者たちが**帯域幅を増やさずに**ビデオ画面で認識できるフレームレートを倍にする技術を思いつきました。この技術は**インターレース動画**として知られています。基本的には一つ目の「フレーム」で画面の半分を送り、次の「フレーム」で残りの半分を送ります。
今日では **プログレッシブスキャン技術**を使って画面に描画されます。プログレッシブは、動く画像を描画、保存、転送する手段の一つで、各フレームの全走査線を順番に描画します。
今日では **プログレッシブスキャン技術**を使って画面に描画されます。プログレッシブは、動画を描画、保存、転送する手段の一つで、各フレームの全走査線を順番に描画します。
![interlaced vs progressive](/i/interlaced_vs_progressive.png "インターレース対プログレッシブ")
これで **画像**がどのようにデジタル表現されるのかが分かりました。**色**がどのように配置され、ビデオを表すのにどのくらいの**秒間あたりのビット**が必要なのか、それが固定なのか(CBR)可変なのか(VBR)、**解像度**と**フレームレート**、他にもインターレースやピクセルアスペクト比やその他のたくさんの用語を学びました。
これで**画像**がどのようにデジタル表現されるのかが分かりました。**色**がどのように配置され、ビデオを表すのにどのくらいの**秒間あたりのビット**が必要なのか、それが固定なのか(CBR)可変なのか(VBR)、**解像度**と**フレームレート**、他にもインターレースやピクセルアスペクト比、その他のたくさんの用語を学びました。
> #### ハンズオン: ビデオプロパティを調べる
> [ffmpegやmediainfoを使って説明したプロパティのほとんどを調べる](https://github.com/leandromoreira/introduction_video_technology/blob/master/encoding_pratical_examples.md#inspect-stream)ことができます。
@@ -166,7 +166,7 @@ cd digital_video_introduction
左側の**正方形Aと正方形B**の色は**同じ**であることが分からないとしても大丈夫です。私たちの脳は**色よりも明暗に注意をはらう**ことで錯覚を起こさせているのです。右側では、同じ色のコネクターがあるため、私たち（私たちの脳）は、それらは実際は同じ色であるということを簡単に気づきます。
> **私たちの目がどのように機能するかの簡単な説明**
> **私たちの目がどのように機能するかの簡単な説明**
>
> [眼は複雑な器官](http://www.biologymad.com/nervoussystem/eyenotes.htm)で、たくさんのパーツから成り立っていますが、主に錐体細胞と桿体細胞に関心があります。眼は [1億2000万の桿体細胞と600万の錐体細胞を含んでいる](https://en.wikipedia.org/wiki/Photoreceptor_cell)のです。
>
@@ -176,7 +176,7 @@ cd digital_video_introduction
>
> ![eyes composition](/i/eyes.jpg "眼の構成")
私たちは**輝度** (画像の明るさの度合い)により敏感であることが分かったところで、それを利用してみることができます。
私たちは**輝度**(画像の明るさの度合い)により敏感であることが分かりました。この特性を利用しましょう。
### カラーモデル
@@ -215,7 +215,7 @@ G = Y - 0.344Cb - 0.714Cr
> <sup>*</sup> グループや標準はデジタルビデオではよくでてきます。彼らは何が標準なのかを定義します。例えば[4Kとは何か？どのフレームレート、解像度、カラーモデルを使うべきか？](https://en.wikipedia.org/wiki/Rec._2020)などです。
一般的に**ディスプレイ** (モニター、テレビ、スクリーン等) は色々な方法で組織化された**RGBモデルだけ**を利用します。下の写真でいくつか拡大したもの示しています。
一般的に**ディスプレイ** (モニター、テレビ、スクリーン等) は様々な方法で構成された**RGBモデルだけ**を利用します。下の写真でいくつか拡大したもの示しています。
![pixel geometry](/i/new_pixel_geometry.jpg "画素形状")
@@ -227,7 +227,7 @@ G = Y - 0.344Cb - 0.714Cr
![ycbcr subsampling resolutions](/i/ycbcr_subsampling_resolution.png "ycbcrサブサンプリング解像度")
色度の解像度をどのくらい小さくすべきでしょうか？解像度と結合 (`最終的な色 = Y + Cb + Cr`)の仕方をどのようにするかを定義したいくつかの方式がすでに存在しています。
色度の解像度をどのくらい小さくすべきでしょうか？！解像度と結合 (`最終的な色 = Y + Cb + Cr`)の仕方をどのようにするかを定義したいくつかの方式がすでに存在しています。
これらの方式はサブサンプリングシステムとして知られ、３つの部分からなる比`a:x:y`として表現されます。これは `a x 2`ブロックの輝度ピクセルに対する色度解像度を定義しています。
@@ -245,7 +245,7 @@ G = Y - 0.344Cb - 0.714Cr
>
> ![YCbCr 4:2:0 merge](/i/ycbcr_420_merge.png "YCbCr 4:2:0結合")
主なタイプのクロマサブサンプリングで符号化された同じ画像を見て下さい。一行目の画像は最終的なYCbCrで、二行目の画像は色度解像度を示しています。実に小さな劣化で素晴らしい結果です。
クロマサブサンプリングの主要な形式で符号化された同じ画像を見て下さい。一行目の画像は最終的なYCbCrで、二行目の画像は色度解像度を示しています。実に小さな劣化で素晴らしい結果です。
![chroma subsampling examples](/i/chroma_subsampling_examples.jpg "クロマサブサンプリング例")
@@ -262,7 +262,7 @@ G = Y - 0.344Cb - 0.714Cr
## フレームの種類
次に**時間的な冗長性**の削減を試みてみましょう。しかし、その前にいくつかの基本的用語 について押さえておきましょう。30 fpsの動画があり、下記が最初の4フレームであるとします。
次に**時間的な冗長性**の削減を試みましょう。しかし、その前にいくつかの基本的用語について押さえておきましょう。30 fpsの動画があり、下記が最初の4フレームであるとします。
![ball 1](/i/smw_background_ball_1.png "ボール1") ![ball 2](/i/smw_background_ball_2.png "ボール2") ![ball 3](/i/smw_background_ball_3.png "ボール3")
![ball 4](/i/smw_background_ball_4.png "ボール4")
@@ -277,7 +277,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
### Pフレーム (予測)
現在の画像は、ほとんど毎回**１つ前のフレームを使って描画する**ことができるという事実をPフレームは利用しています。例えば、2番目のフレームでは、ボールが前に動いたという変化しかありません。**フレーム1を再構築して、相違点だけを使い、１つ前のフレームを参照する**ことができます。
現在の画像は、ほとんど毎回**１つ前のフレームを使って描画する**ことができるという事実をPフレームは利用しています。例えば、2番目のフレームでは、ボールが前に動いたという変化しかありません。**1つ前のフレームを参照し、そのフレームとの差分だけを用いてフレーム1を再構築**できます。
![ball 1](/i/smw_background_ball_1.png "ボール1") <- ![ball 2](/i/smw_background_ball_2_diff.png "ボール2")
@@ -299,7 +299,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
### まとめ
これらの異なる種類のフレームは**より高い圧縮率を得る**ために使われます。次の節でどうやってこれが行われるのか見ていきます。しかし、今のところは**Iフレームは重く、Pフレームは軽いが、最も軽いのはBフレーム**と考えておいてよいでしょう。
これらの異なる種類のフレームは**より高い圧縮率を得る**ために使われます。次の節でどうやってこれが行われるのか見ていきます。しかし、今のところは**Iフレームは重く、Pフレームは比較的軽いですが、最も軽いのはBフレーム**と考えておいてよいでしょう。
![frame types example](/i/frame_types.png "フレームの種類の例")
@@ -319,15 +319,15 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
しかし、さらに少ないビットしか使わない**もっとよい方法**があると言ったらどうでしょう！まず、`フレーム0`をきちんと定められた区画の集合であるとします。そして`フレーム0`のそれぞれのブロックを`フレーム1`上にマッチさせようとします。.これは **動き推定**として考えることができます。
> ### Wikipedia - ブロック動き補償
> "**ブロック動き補償**は現在のフレームを重ならないブロックに分けて、動き補償ベクトルは**これらのブロックがどこからのものかを表します** (前回のフレームが重ならないブロックに分けられ、動き補償ベクトルはこれらのブロックがどこへ行くかを表すというのは、よくある誤解です。)。 元のブロックは元のフレーム内で通常は重なり合います。ビデオ圧縮アルゴリズムの中には、 すでに送信された異なったいくつかのフレームの断片から現在のフレームを組み立てるものもあります。"
> "**ブロック動き補償**は現在のフレームを重ならないブロックに分けて、動き補償ベクトルは**これらのブロックがどこからのものかを表します** (前回のフレームが重ならないブロックに分けられ、動き補償ベクトルはこれらのブロックがどこへ行くかを表すというのは、よくある誤解です)。 元のブロックは元のフレーム内で通常は重なり合います。ビデオ圧縮アルゴリズムの中には、 すでに送信された異なったいくつかのフレームの断片から現在のフレームを組み立てるものもあります。"
![delta frames](/i/original_frames_motion_estimation.png "フレーム差分")
ボールが`x=0、y=25`から`x=6、y=26`へ移動したと推定することができます。**x**と**y**の値は**動きベクトル**です。ビットを節約するためのもう１つの**さらなるステップ**は、前回のブロック位置と予測されるブロック位置との**動きベクトルの差分だけをエンコードする**ことです。 最終的な動きベクトルは`x=6 (6-0)、y=1 (26-25)`のようになります。
> 現実世界の状況では、この**ボールはスライスされてn個の区画にまたがるでしょう**。しかし処理は同じです
> 実際には、この**ボールは分割されてn個の区画にまたがるでしょう**。しかし処理は同じです
フレーム状の物体は**3D方向に動き**、ボールは背景の方に動くと小さくもなります。 ブロックへの**完全なマッチを見つけられない**のはよくあることです。 推定画像と実際の画像を重ねると下記のようになります。
フレーム上の物体は**3D空間で移動します**。ボールは背景の方に動くと小さくもなります。 **完全にマッチするブロックを見つけられない**ことはよくあります。 推定画像と実際の画像を重ねると下記のようになります。
![motion estimation](/i/motion_estimation.png "動き推定")
@@ -336,9 +336,9 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
![motion estimation vs delta ](/i/comparison_delta_vs_motion_estimation.png "動き推定 差分")
> ### 可視化された実際の動き補償
> この手法は全てのブロックに適用され、かなり頻繁にボールは１つ以上のブロックに配置されます。
> この手法は全てのブロックに適用され、高い確率でボールは１つ以上のブロックに配置されます。
> ![real world motion compensation](/i/real_world_motion_compensation.png "現実世界の動き補償")
> Source: https://web.stanford.edu/class/ee398a/handouts/lectures/EE398a_MotionEstimation_2012.pdf
> 引用元: https://web.stanford.edu/class/ee398a/handouts/lectures/EE398a_MotionEstimation_2012.pdf
[jupyterを使ってこれらの概念を実験](/frame_difference_vs_motion_estimation_plus_residual.ipynb)できます。
@@ -353,7 +353,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
## 空間的冗長性 (イントラ予測)
ビデオの中の**１つ１つのフレーム**を分析すると、**たくさんの相関性のある領域**が存在することが分かります。
ビデオの中の**1つ1つのフレーム**を分析すると、**たくさんの相関性のある領域**が存在することが分かります。
![](/i/repetitions_in_space.png)
@@ -365,11 +365,11 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
![](/i/smw_bg_block.png)
このフレームでは**色が垂直方向に広がり**続けることを**予測**してみます。**未知のピクセルの色が隣の色を持つ**ことを意味します。
このフレームでは**色が垂直方向に広がり**続けることを**予測**してみます。**未知のピクセルの色が隣接するピクセルの色を持つ**ことを意味します。
![](/i/smw_bg_prediction.png)
**予測が間違うかもしれません**。そのため、この手法(**イントラ予測**)を適用してから、**実際の値を引いて**差分を生成する必要があります。その差分は元よりももっと圧縮しやすいマトリクスになります。
**予測が間違うかもしれません**。そのため、この手法(**イントラ予測**)を適用してから、**実際の値を引いて**差分を生成する必要があります。その差分は予測前よりもさらに圧縮しやすいマトリクスになります。
![](/i/smw_residual.png)
@@ -386,7 +386,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
## 何か? なぜ? どのように?
**何か?** デジタルビデオを圧縮、解凍するソフトウェア / ハードウェアの部品。**なぜ?** 制限された帯域とストレージの下でより高い品質のビデオへの要求が、市場と社会で高まっているため。30フレーム毎秒、24ビット毎ピクセル、解像度が480x240のビデオに[必要な帯域を計算](#basic-terminology)したのを覚えていますか。圧縮なしでは**82.944 Mbps**でした。テレビやインターネットでHD/FullHD/4Kを配信するためには圧縮するしかありません。**どのように?** ここで主な技法について簡単に見ていきます。
**何か?** デジタルビデオを圧縮、解凍するソフトウェア / ハードウェアの部品。**なぜ?** 制限された帯域とストレージの下でより高い品質のビデオへの要求が、市場と社会で高まっているため。毎秒30フレーム、ピクセルあたり24ビット、解像度が480x240のビデオに[必要な帯域を計算](#basic-terminology)したのを覚えていますか。圧縮なしでは**82.944 Mbps**でした。テレビやインターネットでHD/FullHD/4Kを配信するためには圧縮するしかありません。**どのように?** ここで主な技法について簡単に見ていきます。
> **コーデック 対 コンテナ**
>
@@ -400,9 +400,9 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
ビデオコーデックである[H.261](https://en.wikipedia.org/wiki/H.261)は1990年(厳密には1988年)に生まれました。H.261は**64 kbit/sのデータレート**で動作するように設計されました。クロマサブサンプリングやマクロブロックなどの考えをすでに使っていました。1995年に、**H.263**ビデオコーデック標準が発表され2001年まで拡張され続けました。
2003年に**H.264/AVC**の初版が完成しました。同じ年に**TrueMotion**と呼ばれる会社が、**ロイヤリティーフリー**で非可逆ビデオ圧縮の **VP3**と呼ばれるビデオコーデックをリリースしました。2008年にこの会社を**Googleが買収**し、同じ年に**VP8**をリリースしました。2012年の12月にGoogleが**VP9**をリリースしました。VP9は(モバイルを含む)**ブラウザ市場のおよそ¾にサポートされています**。
2003年に**H.264/AVC**の初版が完成しました。同じ年に**TrueMotion**と呼ばれる会社が、**ロイヤリティーフリー**で非可逆ビデオ圧縮の **VP3**と呼ばれるビデオコーデックをリリースしました。2008年にこの会社を**Googleが買収**し、同じ年に**VP8**をリリースしました。2012年の12月にGoogleが**VP9**をリリースしました。VP9は(モバイルを含む)**ブラウザ市場のおよそ¾でサポートされています**。
**[AV1](https://en.wikipedia.org/wiki/AOMedia_Video_1)**は新しい**ロイヤリティーフリー**でオープンソースのビデオコーデックで、[Alliance for Open Media (AOMedia)](http://aomedia.org/)によって設計されました。AOMediaは**複数の会社: Google、Mozilla、Microsoft、Amazon、Netflix、AMD、ARM、NVidia、Intel、Cisco**と他のいくつかの会社から成り立っています。リファレンスコーデックの**初版** 0.1.0が**2016年4月7日に公開されました**。
**[AV1](https://en.wikipedia.org/wiki/AOMedia_Video_1)**は新しい**ロイヤリティーフリー**でオープンソースのビデオコーデックで、[Alliance for Open Media (AOMedia)](http://aomedia.org/)によって設計されました。AOMediaは**複数の会社: Google、Mozilla、Microsoft、Amazon、Netflix、AMD、ARM、NVidia、Intel、Cisco**と他のいくつかの会社から成り立っています。リファレンスコーデックの**初版** 0.1.0が**2016年4月7日に公開されました**。
![codec history timeline](/i/codec_history_timeline.png "コーデック歴史年表")
@@ -437,9 +437,9 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
**しかしなぜ?** たくさんの理由があります。例えば、画像を分割すると小さなパーティションを動きのある小さな部分に使い、より大きなパーティションを静的な背景に使って、予測をより正確に行うことができます。
通常は、コーデックは、スライス(もしくはタイル)、マクロ(もしくは符号ツリーユニット)やたくさんのサブパーティンにと **パーティションを構造化します**。これらのパーティションの最大サイズは様々で、HEVCでは64x64、AVC16x16ですが、サブパーティションは4x4までです。
通常、コーデックは、スライス(もしくはタイル)、マクロ(もしくは符号ツリーユニット)やたくさんのサブパーティションで **パーティションを構成します**。これらのパーティションの最大サイズは様々で、HEVCでは64x64、AVC16x16ですが、サブパーティションは4x4までです。
**フレームはいくつかのタイプに分けられている**のを学んだことを覚えていますか？**さて、これらの考えをブロックに適用する**こともできます。それで、Iスライス、Bスライス、Iマクロブロックなどを持つことができます。
**フレームはいくつかの形式に分けられている**のを学んだことを覚えていますか？！さて、**これらのアイデアをブロックに適用する**こともできます。つまりIスライス、Bスライス、Iマクロブロックなどを持つことができます。
> ### ハンズオン: パーティションを調べる
> [Intel Video Pro Analyzer](https://software.intel.com/en-us/intel-video-pro-analyzer) (有料ですが、最初の10フレームに制限された無料お試し版もあります)を使うこともできます。これが分析された[VP9パーティション](/encoding_pratical_examples.md#transcoding)です。
@@ -452,7 +452,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
## ステップ３ - 変換
差分ブロック (`予測パーティション - 実際のパーティション`)を生成した後、**変換**することで**大まかな画質**を保ったままどの**ピクセルを捨てられるか**が分かるようになります。それを行うためにはいくつかの変換が存在します。
差分ブロック (`予測パーティション - 実際のパーティション`)を生成した後、それを**変換**することで**画質をある程度**保ったまま、どの**ピクセルを捨てられるか**が分かるようになります。それにはいくつかの変換が存在します。
[他の変換](https://en.wikipedia.org/wiki/List_of_Fourier-related_transforms#Discrete_transforms)もありますが、離散コサイン変換(DCT)をしっかり見ていきます。[**DCT**](https://en.wikipedia.org/wiki/Discrete_cosine_transform)の主な特徴は:
@@ -462,9 +462,9 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
> 2017年2月2日にCintra, R. J.とBayer, F. Mが[14加算のみの画像圧縮用DCT近似変換](https://arxiv.org/abs/1702.00817)という論文を発表しました。
上記の箇条書きの利点を全て理解しなかったとしても心配いりません。その本当の価値を見い出すためにいくつかの実験を試みてみます。
上記の箇条書きの利点を全て理解しなかったとしても心配いりません。その本当の価値を見い出すためにいくつかの実験を試みます。
次の**ピクセルのブロック** (8x8)を例にとりましょう:
次の**ピクセルのブロック**(8x8)を例にとりましょう:
![pixel values matrix](/i/pixel_matrice.png "ピクセル値マトリクス")
@@ -476,11 +476,11 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
![coefficients values](/i/dct_coefficient_values.png "係数の値")
この係数のブロックを描画すれば、この画像を得るでしょう。:
この係数のブロックを描画すれば、次の画像が得られるでしょう:
![dct coefficients image](/i/dct_coefficient_image.png "dct係数画像")
元の画像とは似ても似つかないことが分かり、**最初の係数**は他の係数とは全く異なっていることに気づくかもしれません。 この最初の係数はDC係数として知られ、入力配列の**サンプル全体**を表します。**平均に似てる**何かです。
元の画像とは似ても似つかないことが分かり、**最初の係数**は他の係数とは大きく異なっていることにお気づきかもしれません。この最初の係数はDC係数として知られ、入力配列の**サンプル全体**を表します。**平均に似た**何かです。
この係数のブロックは高周波数成分を低周波数成分から切り離すという面白い特性を持っています。
@@ -504,7 +504,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
![original vs quantized](/i/original_vs_quantized.png "元 vs 量子化後")
この画像は元の画像と似ていますが、多くの相違点が発生しています。**67.1875%を捨てました**が、 少なくとも元の画像に似ている画像を得ることができました。より知的に係数を捨てて、もっと画質を良くすることもできましたが、それは次のトピックです。
この画像は元の画像と似ていますが、多くの相違点が発生しています。**67.1875%を捨てました**が、 少なくとも元の画像に似ている画像を得ることができました。より賢い方法で係数を捨てて、もっと画質を良くすることもできたのですが、それは次のトピックで扱います。
> **それぞれの係数は画素全体を使って形成される**
>
@@ -514,13 +514,10 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
>
> 原典: https://web.archive.org/web/20150129171151/https://www.iem.thm.de/telekom-labor/zinke/mk/mpeg2beg/whatisit.htm
>
> DCT基底ごとの[単純な画像の形成を見てDCTを視覚化する](/dct_better_explained.ipynb)こともできます。例えば、下記はそれぞれの係数の重みをを使って[１つの文字が形成されていく](https://en.wikipedia.org/wiki/Discrete_cosine_transform#Example_of_IDCT)過程です。
> DCT基底ごとの[単純な画像の形成を見てDCTを視覚化する](/dct_better_explained.ipynb)こともできます。例えば、下記はそれぞれの係数の重みを使って[１つの文字が形成されていく](https://en.wikipedia.org/wiki/Discrete_cosine_transform#Example_of_IDCT)過程です。
>
> ![](https://upload.wikimedia.org/wikipedia/commons/5/5e/Idct-animation.gif )
<br/>
> ### ハンズオン: 種々の係数を捨てる
@@ -528,13 +525,13 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
## ステップ４ - 量子化
前のステップ (変換)で係数をいくつか捨てるときに、量子化のようなものを行いました。 このステップでは、捨てる情報(**損失部分**)を選びます。単純な言葉でいうと、**圧縮を成し遂げるために係数を量子化**します。
前のステップ (変換)で係数をいくつか捨てるときに、量子化のようなものを行いました。このステップでは、捨てる情報(**損失部分**)を選びます。単純な言葉でいうと、**圧縮を成し遂げるために係数を量子化**します。
どのように係数のブロックを量子化できるでしょうか？１つの単純な方法は、均一量子化でしょう。ブロックを**単一値** (10) **で割り**、小数点を切り捨てます。
![quantize](/i/quantize.png "量子化")
どのようにこの係数のブロックを**元に戻す** (再量子化)できるでしょうか？**同じ値** (10)**を掛ける**ことにより戻すことができます。
どのようにこの係数のブロックを**元に戻せる**(再量子化)でしょうか？**同じ値** (10)**を掛ける**ことにより戻すことができます。
![re-quantize](/i/re-quantize.png "再量子化")
@@ -568,7 +565,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
それぞれのコードはユニークな接頭符号を持つ必要があることに注意してください [ハフマンがこれらの数字を見つけることを助けてくれます](https://en.wikipedia.org/wiki/Huffman_coding)。いくつかの問題がありますが、この方法は[いくつかのビデオコーデックでまだサポート](https://en.wikipedia.org/wiki/Context-adaptive_variable-length_coding)しています。これは圧縮を必要とする多くのアプリケーションに有用なアルゴリズムです。
エンコーダーとデコーダーの両方がそのコードの記号テーブルを**知らなくてはいけません**。それでテーブルも送信する必要があります。
エンコーダーとデコーダーの両方がそのコードの記号テーブルを**知らなくてはいけません**。そのためテーブルも送信する必要があります。
### 算術符号:
@@ -586,7 +583,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
![second sub range](/i/second_subrange.png "2番目の部分範囲")
ストリーム**eat**の符号化を続けましょう。次に記号**a**を取り上げます。これは**0.3以上0.39未満**に存在ます。そして、最後の記号 **t**を取り上げます。もう一度同じ処理を行うと**0.354以上0.372未満**という最終的な範囲を得ます。
ストリーム**eat**の符号化を続けましょう。次に記号**a**を取り上げます。これは**0.3以上0.39未満**に位置しています。そして、最後の記号 **t**を取り上げます。もう一度同じ処理を行うと**0.354以上0.372未満**という最終的な範囲を得ます。
![final arithmetic range](/i/arithimetic_range.png "最終的な算術範囲")
@@ -604,11 +601,11 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な
この考えは、量子化ビットストリームを可逆圧縮する為のものです。間違いなくこの記事では伝えきれていない詳細、理由、トレードオフ等が山のようにあります。しかし、読者はデベロッパーとして[もっと学ぶべきです](https://www.amazon.com/Understanding-Compression-Data-Modern-Developers/dp/1491961538/)。より新しいコーデックは別の[ANSのようなエントロピー符号化アルゴリズム](https://en.wikipedia.org/wiki/Asymmetric_Numeral_Systems)を使おうとしています。
> ### ハンズオン: CABAC対CAVLC
> [１つはCABAC、もう一方はCAVLCを使って２つのストリームを生成](https://github.com/leandromoreira/introduction_video_technology/blob/master/encoding_pratical_examples.md#cabac-vs-cavlc)し、生成する為にかかる**時間と最終的なサイズを比較し**してみましょう。
> [１つはCABAC、もう一方はCAVLCを使って２つのストリームを生成](https://github.com/leandromoreira/introduction_video_technology/blob/master/encoding_pratical_examples.md#cabac-vs-cavlc)し、生成する為にかかる**時間と最終的なサイズを比較**してみましょう。
## ステップ６ - ビットストリームフォーマット
これらのステップ全てを行った後、**圧縮されたフレームとこれらのステップまでのコンテキストを一つにまとめる**必要があります。 **エンコーダによってなされた決定**についてデコーダへ明示的に知らせる必要があります。ビット深度、色空間、解像度、予測情報（動きベクトル、イントラ予測方向）、プロファイルレベル、フレームレート、フレームタイプ、フレーム数、その他多数です。
これらのステップ全てを行った後、**圧縮されたフレームとこれらのステップまでのコンテキストを一つにまとめる**必要があります。 **エンコーダによってなされた決定**をデコーダへ明示的に知らせる必要があります。ビット深度、色空間、解像度、予測情報（動きベクトル、イントラ予測方向）、プロファイルレベル、フレームレート、フレームタイプ、フレーム数、その他多数です。
H.264ビットストリームについて表面的に学んでいきます。最初のステップは[最小限のH.264 <sup>*</sup>ビットストリームを生成する](/encoding_pratical_examples.md#generate-a-single-frame-h264-bitstream)ことです。このレポジトリと[ffmpeg](http://ffmpeg.org/)を使って、これができます。
@@ -616,7 +613,7 @@ H.264ビットストリームについて表面的に学んでいきます。最
./s/ffmpeg -i /files/i/minimal.png -pix_fmt yuv420p /files/v/minimal_yuv420.h264
```
> <sup>*</sup> ffmpegは、デフォルトで**SEI NAL**として符号化された全パラメータを加えます。NALがなんであるかはすぐに定義します。
> <sup>*</sup> ffmpegは、デフォルトで**SEI NAL**として符号化された全パラメータを加えます。NALが何であるかは後ほど定義します。
このコマンドは、**単一フレーム**、64x64、色空間がyuv420、次の画像をフレームとして使っている生のh264ビットストリームを生成します。
@@ -624,7 +621,7 @@ H.264ビットストリームについて表面的に学んでいきます。最
### H.264ビットストリーム
AVC (H.264)標準は、情報が**マクロフレーム** (ネットワーク的には)**[NAL](https://en.wikipedia.org/wiki/Network_Abstraction_Layer)** (Network Abstraction Layer)と呼ばれる形で送信されることを定義しています。NALの主な目的は、"ネットワークフレンドリー"なビデオ表現を提供することです。この標準は、TV (ストリームベース)、インターネット(パケットベース)やその他で動作しなければなりません。
AVC (H.264)標準は、情報が **[NAL (Network Abstraction Layer)](https://en.wikipedia.org/wiki/Network_Abstraction_Layer)** と呼ばれる **マクロフレーム** (ネットワーク的には)で送信されることを定義しています。NALの主な目的は、"ネットワークフレンドリー"なビデオ表現を提供することです。この標準は、TV (ストリームベース)、インターネット(パケットベース)やその他で動作しなければなりません。
![NAL units H.264](/i/nal_units.png "NALユニット H.264")
@@ -650,7 +647,7 @@ NALユニットの境界を定義する **[同期マーカー](https://en.wikipe
| 11 | ストリームの最後 |
| ... | ... |
普通は、ビットストリームの最初のNALは**SPS**で、このタイプのNALは、**プロファイル**、**レベル**、**解像度**やその他の汎用エンコーディング変数を知らせる役割を持ちます。
通常、ビットストリームの最初のNALは**SPS**です。このNALの種類は、**プロファイル**、**レベル**、**解像度**やその他の汎用エンコーディング変数を知らせる役割を持ちます。
最初の同期マーカーを飛ばすと、**最初のバイト**を復号化して**NALのタイプ**が何かを知ることができます。
@@ -689,8 +686,7 @@ SPS NALについてH.264ビットストリーム仕様を読むと、**パラメ
![h264 bitstream macro diagram](/i/h264_bitstream_macro_diagram.png "h264ビットストリームマクロ図表")
[VP9ビットストリーム](https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf)や[H.265 (HEVC)](http://handle.itu.int/11.1002/1000/11885-en?locatt=format:pdf)や、さらには**新しいベストフレドである** [**AV1** ビットストリーム](https://medium.com/@mbebenita/av1-bitstream-analyzer-d25f1c27072b#.d5a89oxz8
)のビットストリームを探索することができます。[それらはみんな似てますか？いいえ](http://www.gpac-licensing.com/2016/07/12/vp9-av1-bitstream-format/)、しかし１つを学ぶと、他のは簡単に理解できます。
[VP9ビットストリーム](https://storage.googleapis.com/downloads.webmproject.org/docs/vp9/vp9-bitstream-specification-v0.6-20160331-draft.pdf)や[H.265 (HEVC)](http://handle.itu.int/11.1002/1000/11885-en?locatt=format:pdf)や、さらには**新しいベストフレドである** [**AV1** ビットストリーム](https://medium.com/@mbebenita/av1-bitstream-analyzer-d25f1c27072b#.d5a89oxz8)のビットストリームを探索することができます。[それらはみんな似てますか？いいえ](http://www.gpac-licensing.com/2016/07/12/vp9-av1-bitstream-format/)、しかし1つを学ぶと、他は簡単に理解できます。
> ### ハンズオン: H.264ビットストリームを調べる
> [単一フレームのビデオを生成](https://github.com/leandromoreira/introduction_video_technology/blob/master/encoding_pratical_examples.md#generate-a-single-frame-video)し、[mediainfo](https://en.wikipedia.org/wiki/MediaInfo)を使ってH.264ビットストリームを検査してみましょう。実際、[h264 (AVC)ビットストリームをパースするソースコード](https://github.com/MediaArea/MediaInfoLib/blob/master/Source/MediaInfo/Video/File_Avc.cpp)を見ることもできます。
@@ -707,13 +703,13 @@ SPS NALについてH.264ビットストリーム仕様を読むと、**パラメ
![thor_codec_block_diagram](/i/thor_codec_block_diagram.png "thor_codec_block_diagram")
先に、[720p解像度で30fpsで1時間のビデオファイルを保存するのに139GBのストレージ](#chroma-subsampling)が必要になることを計算しました。ここで学んだ技法を使えば、つまり**インター予測、イントラ予測、変形、量子化、エントロピー符号化、その他**を使えば、**ピクセルあたり0.031ビット**を使うことを想定して、同じ知覚画質のビデオを保存するのに、**139GBに対して、367.82MBだけ必要**になることを実現できます。
まず[720p解像度で30fpsで1時間のビデオファイルを保存するのに139GBのストレージ](#chroma-subsampling)が必要になることを計算しました。ここで学んだ技法つまり**インター予測、イントラ予測、変形、量子化、エントロピー符号化、その他**を駆使して、**ピクセルあたり0.031ビット**で表現できると仮定すると、**139GBに対したった367.82MBだけ**で同じ知覚画質のビデオを保存できます。
> ここで使った例のビデオを元に**ピクセルあたり0.031ビット**を使うことを導きました。
> 今回使用したビデオを元に**ピクセルあたり0.031ビット**が必要になることを導きました。
## どのようにH.265はH.264よりも良い圧縮率を実現しているのか?
今、コーデックの仕組みについてより理解しています。それで、新しいコーデックがどのようにより高い解像度をより低いビットで配信することができるかが簡単に理解できます。
今、コーデックの仕組みについてより理解しています。そのため、新しいコーデックがより高い解像度をより少ないビットでどのように配信できるのか簡単に理解できます。
AVCとHEVCを比較してみましょう。より多くのCPUサイクル(複雑さ)と圧縮率は、ほとんどいつでもトレードオフであることを心に止めておきましょう。
@@ -746,7 +742,7 @@ HEVCはAVCに比べて、より大きく、より多くの**パーティショ
![drm](/i/drm.png "drm")
実際の製品システムで、人々はしばしばこれら両方の技術を使って、承認と認証を提供します。
実際の製品システムで、人々はしばしばこれら両方の技術を使って、認可と認証を提供します。
### DRM
#### メインシステム
@@ -762,7 +758,7 @@ DRMはデジタル著作権管理を意味します。それは、例えばデ
#### なぜ?
コンテンツ製作者(たいていはスタジオ)は、デジタルメディアの不正な再配布を防ぐために、 知的財産がコピーされることから守りたいためです。
コンテンツ製作者(たいていはスタジオ)は、デジタルメディアの不正な再配布を防ぐために、 知的財産が複製されることから守りたいためです。
#### どのように?
@@ -776,9 +772,9 @@ DRMの抽象的で一般的な形式を、とても単純な方法で説明し
デバイスD1のプレイヤーP1は２つの(非対称)鍵、**秘密鍵PRK1** (この鍵は保護され<sup>1</sup>**D1**にしか知られていない)と**公開鍵PUK1**を持っています。
> **<sup>1</sup>保護される**: この保護は、**ハードウェアを介して**なされます。例えば、この鍵は、特別な(読み取り専用)チップの中に保存されます。これは、復号を提供する[ブラックボックス](https://en.wikipedia.org/wiki/Black_box)のように働きます。もしくは(あまり安全でない)**ソフトウェアにより** なされます。DRM システムは、与えられたデバイスがどのタイプの保護を持っているかを知る方法を提供します。
> **<sup>1</sup>保護される**: この保護は、**ハードウェアを介して**なされます。例えば、この鍵は、特別な(読み取り専用)チップの中に保存されます。これは、復号を提供する[ブラックボックス](https://en.wikipedia.org/wiki/Black_box)のように働きます。もしくは(あまり安全でない)**ソフトウェアにより**なされます。DRM システムは、与えられたデバイスがどのタイプの保護を持っているかを知る方法を提供します。
**プレイヤーP1がコンテンツC'1を再生したい**とき、**DRMシステムDRM1**を使う必要があり、まず公開鍵**PUK1**を与えます。DRMシステムDRM1は クライアントの公開鍵**PUK1**で**暗号化された鍵K1**を返します。理論上、このレスポンスは.**D1だけが復号可能**です。
**プレイヤーP1がコンテンツC'1を再生したい**とき、**DRMシステムDRM1**を使う必要があり、まず公開鍵**PUK1**を与えます。DRMシステムDRM1は クライアントの公開鍵**PUK1**で**暗号化された鍵K1**を返します。理論上、このレスポンスは**D1だけが復号可能**です。
`K1P1D1 = enc(K1, PUK1)`