From 12f8a37ddfaff717a112598c4ccdb73f514512fc Mon Sep 17 00:00:00 2001 From: Yuki MIZUNO Date: Thu, 29 Aug 2019 21:00:26 +0900 Subject: [PATCH 1/2] Fix localized anchor --- README-ja.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README-ja.md b/README-ja.md index cf91875..a82fc3c 100644 --- a/README-ja.md +++ b/README-ja.md @@ -180,7 +180,7 @@ cd digital_video_introduction ### カラーモデル -**RGBモデル**を使って[カラー画像がどのように](#basic-terminology)機能するのか最初に学びましたが、他のモデルも存在します。実は、輝度(明るさ)と色度(色)を別にするモデルが存在します。それは**YCbCr***として知られています。 +**RGBモデル**を使って[カラー画像がどのように](#基本用語)機能するのか最初に学びましたが、他のモデルも存在します。実は、輝度(明るさ)と色度(色)を別にするモデルが存在します。それは**YCbCr***として知られています。 > * 同じ分離を行うモデルはもっと存在します。 @@ -249,7 +249,7 @@ G = Y - 0.344Cb - 0.714Cr ![chroma subsampling examples](/i/chroma_subsampling_examples.jpg "クロマサブサンプリング例") -[解像度が720pで30fpsのビデオを1時間ファイルに保存するためには278GBの領域](#redundancy-removal)が必要になることを先に計算しました。**YCbCr 4:2:0**を使うと、**半分のサイズ(139 GB)***にすることができます。しかしまだ理想には程遠いです。 +[解像度が720pで30fpsのビデオを1時間ファイルに保存するためには278GBの領域](#冗長性除去)が必要になることを先に計算しました。**YCbCr 4:2:0**を使うと、**半分のサイズ(139 GB)***にすることができます。しかしまだ理想には程遠いです。 > * 幅、高さ、ピクセルごとのビット数、フレームレートを掛けることによりこの値を計算しました。先に計算した時は２４ビット必要でしたが、今は１２ビットしか必要ありません。 @@ -386,7 +386,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な ## What? Why? How? -**What?** デジタルビデオを圧縮、解凍するソフトウェア / ハードウェアの部品。**Why?** 制限された帯域とストレージの下でより高い品質のビデオへの要求が、市場と社会で高まっているため。毎秒30フレーム、ピクセルあたり24ビット、解像度が480x240のビデオに[必要な帯域を計算](#basic-terminology)したのを覚えていますか。圧縮なしでは**82.944 Mbps**でした。テレビやインターネットでHD/FullHD/4Kを配信するためには圧縮するしかありません。**How?** ここで主な技法について簡単に見ていきます。 +**What?** デジタルビデオを圧縮、解凍するソフトウェア / ハードウェアの部品。**Why?** 制限された帯域とストレージの下でより高い品質のビデオへの要求が、市場と社会で高まっているため。毎秒30フレーム、ピクセルあたり24ビット、解像度が480x240のビデオに[必要な帯域を計算](#基本用語)したのを覚えていますか。圧縮なしでは**82.944 Mbps**でした。テレビやインターネットでHD/FullHD/4Kを配信するためには圧縮するしかありません。**How?** ここで主な技法について簡単に見ていきます。 > **コーデック 対 コンテナ** > @@ -448,7 +448,7 @@ Iフレーム(参照、キーフレーム、イントラ)は**自己完結的な ## ステップ２ - 予測 -パーティションに分割すると、それらについて予測を行うことができます。[インター予測](#temporal-redundancy-inter-prediction)のために、**動きベクトルと差分を送信する**必要があり、また[イントラ予測](#spatial-redundancy-intra-prediction)のために、**予測方向と差分を送信する**必要があります。 +パーティションに分割すると、それらについて予測を行うことができます。[インター予測](#時間的冗長性-インター予測)のために、**動きベクトルと差分を送信する**必要があり、また[イントラ予測](#空間的冗長性-イントラ予測)のために、**予測方向と差分を送信する**必要があります。 ## ステップ３ - 変換 @@ -703,7 +703,7 @@ 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のストレージ](#クロマサブサンプリング)が必要になることを計算しました。ここで学んだ技法つまり**インター予測、イントラ予測、変形、量子化、エントロピー符号化、その他**を駆使して、**ピクセルあたり0.031ビット**で表現できると仮定すると、**139GBに対したった367.82MBだけ**で同じ知覚画質のビデオを保存できます。 > 今回使用したビデオを元に**ピクセルあたり0.031ビット**が必要になることを導きました。 From 085b0cd9927e8fa4ebfafbdac8b82236571a688b Mon Sep 17 00:00:00 2001 From: Yuki MIZUNO Date: Thu, 29 Aug 2019 23:58:47 +0900 Subject: [PATCH 2/2] Apply changing of a source README.md --- README-ja.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README-ja.md b/README-ja.md index a82fc3c..07e735b 100644 --- a/README-ja.md +++ b/README-ja.md @@ -870,6 +870,7 @@ DRMの抽象的で一般的な形式を、とても単純な方法で説明し その他: +* https://github.com/Eyevinn/streaming-onboarding * http://stackoverflow.com/a/24890903 * http://stackoverflow.com/questions/38094302/how-to-understand-header-of-h264 * http://techblog.netflix.com/2016/08/a-large-scale-comparison-of-x264-x265.html