2ちゃんねる★スマホ版★■掲示板に戻る■全部1-最新50

【H.265/HEVC】コーデック開発の勉強をしよう [転載禁止]©2ch.net

1 :
2014/11/03(月) 22:38:02.27
コーデック開発の勉強をしたいと思います。
正直コーデックに関しての知識はまったく無いといっていいので基礎からの勉強になります。
何故この分野を選んだのかというと、自分にしか出来ない分野の技術力(強み)が欲しいからです。


スペック
年齢:28歳(もうすぐ29)
経歴:8年ほどSIやっていて、今年から自社開発メインの会社に転職した。
言語:C、C++
知識:基本的なIO、TCP、UDP(BSD、winsock)、マルチスレッド(POSIX、Win32)、MFC、WinSDK
RFCでの開発経験:多少有り
コーデックの知識:まったく無し
2 :
2014/11/03(月) 22:52:35.09
【 H.265/HEVC規格の概要 】
対応フォーマット:最大 7680×4320/120(画像サイズ/fps)
マクロブロックサイズ:8×8〜64×64
イントラ予測(予測モード数):4×4〜64×64ブロックで35種類
インター予測:8×4/4×8〜64×64ブロックで動き予測(1/4画素精度予測)
変換:4×4〜32×32ブロックで整数DCT、4×4ブロックで整数DST/変換スキップ
エントロピー符号化:CABAC
ループフィルタ:デブロッキングフィルタおよび画素適応オフセット


対応フォーマットはかろうじてわかるけど他が全くわからない。
まずはマクロブロックサイズのところから勉強しよう。
3 :
2014/11/03(月) 22:55:16.91
【 H.264/AVC絡みのサイトから抜粋 】
ピクチャ:概ねフレーム(1つの画面)に相当。
スライス:ピクチャをある程度分割したもの。
マクロブロック:スライスよりも小さな単位。一般的には16x16ピクセル。「動き補償」という圧縮方式が使う。
ピクセル:これはそのままピクセル。
ハーフペル:ハーフピクセル。「動き補償」で使う。隣接ピクセルの値の間の値を計算で出したもの。「1/2精度動き補償」などと言う。
クォーターペル:Qpel とか。「動き補償」で使う。「1/4精度動き補償」などと言う。
4 :
2014/11/03(月) 22:57:06.06
人によっては激しい腹痛に襲われるらしいね
5 :
2014/11/04(火) 00:25:22.55
処理の高速化のために、汗んブラを勉強しなさい
6 :
2014/11/04(火) 01:16:51.98
ピクチャとは概ねフレーム(1つの画面)に相当する。
概ねというところが意味深だけど1つのフレーム(静止画像)という認識をもっておこう。

スライスとはピクチャをある程度分割したもの。
参考サイトのイメージ画像の内容からするとピクチャを何分割にしたものがスライスという意味。
スライスにも色々種類があってBスライス、Iスライス、Pスライスというものがあるらしくて、
符号化の基本は「スライス」単位でやるものらしい。

マクロブロックサイズ(MBというらしい)は1フレーム(1画像)を正方形の小さなブロックに分割する事をいう。
つまり8 x 8だと縦横8ピクセル x 8ピクセルの事をマクロブロックという意味なのかな?
64 x 64だったりするのはよくわからないけどとりあえずマクロブロックの意味はなんとなく想像ついた。

ピクセルは1画素のこと(だと思ってる)

ハーフペルとクォーターペルはよくわからないから今は気にしないでおこう。

イントラ予測とインター予測もよくわからないから今は気にしないでおこう。

エントロピー符号化どこかで聞いたことある単語だけど今は気にしないでおこう。

ループフィルタもよくわからないから今は気にしないでおこう。



大まかな知識はこれくらいとし、まず課題としてyuvファイルを一つのフレームずつ読み込むサンプルプログラムを作る事にしよう。


>>5
汗はnaked(スタック処理を全部自分でやる)使ってE8h、E9hに対してのトランポリン仕込んでデバッグするぐらいしかやったことがないな
高速化のノウハウもわからないし、思いつくのはせいぜいレジスタ使ってスタック(自動変数)を
介した処理を極力しないぐらいしか思い浮かばない
7 :
2014/11/06(木) 00:05:45.33
1フレームの計算式 = width * height + width * height / 4 + width * height /4

探し方が悪いのか必死こいてやっと見つけた式
ただ、この式があってるのかどうかわからないし何となくモヤモヤする(掲載されていたソースから拾った式なので公式なのかがわからない)


176x144の2101フレームのyuv動画ファイルサイズを元に上記の式に当てはめたところちゃんと割り切れたからあっているとは思うが。。。

■yuvplayerを使った計算(フレーム数とファイルサイズさえわかれば計算できる)
動画ファイルサイズ = 79871616byte
79871616 / 2101 = 38016
1フレーム = 38016byte

■見つけた公式?に当てはめてみる
176 * 144 = 25344
25344 + 25344 / 4 + 25344 / 4 = 38016byte


動画処理やってる人口は少ないだろうから情報調べるのに苦労しそうだ
ひとまず課題で必須の材料は揃ったから読み込み処理はすぐできるはず
そういえばスライスで分割する個数って決まってるのかな
分割した後の圧縮や複合処理はスレッドでやるのがベターなんだろうな
8 :
2014/11/08(土) 08:46:00.34
「H.265/HEVC教科書」くらいは買ったんだろうな?
9 :
2014/11/08(土) 19:22:00.63
>>8
早速買ってきた
昼ごろから錦糸町の書店4件回ったけど全滅で秋葉原のヨドバシ7F(有隣堂)にあったわ
探すだけで半日ぐらい潰れてしまったから今思うとamazonで買えばよかったかな

決して安くない買い物だったから積み本にならなければいいが
10 :
2014/11/09(日) 02:16:14.91
本読んでてあんまり書いてる時間なかったけど
叩き台となる課題の処理は概ね出来上がった
後はこれベースに実験を重ねて映像処理の基礎理解を深めていければと思ってる

ttp://uproda.2ch-library.com/8385628zp/lib838562.c


今日買った本を読んでるけど難しすぎてさっぱりだ
元々敷居が高いのはわかっていたけど、やっぱり改めて映像処理は敷居が高いと感じた
こればっかりは地道に基礎知識を身につけていくしかないと思うがどこまでやっていけることやら(遠い目)
11 :
2014/12/11(木) 09:59:44.87
デジタルテレビやってる下請けへ行くといいよ
12 :
2015/03/12(木) 21:04:43.41
とりあえず動かしてから書けよ

口先君
13 :
仕様書無しさん
2015/05/02(土) 09:44:57.81
ffmpeg?
14 :
2015/05/09(土) 23:58:34.47
Aviutlプラグインのh265ハードエンコ
bフレ非対応なのなんとかして欲しい
15 :
2016/03/16(水) 23:45:10.61
独自コーデックなんて需要皆無だしオープンな規格のはエンコーダもデコーダもすでに無料で用意されてるしな
8KB

新着レスの表示

★スマホ版★■掲示板に戻る■全部前100次100最新50

名前:E-mail: