2012年1月14日 (土)

RGB24の1677万7216色のうち、YUVが表せる色の数は?

「RGB24の1677万7216色のうち、
 
8bit-depthのYUVで表せるのは、最大でも440万色程度」

この計算を行ったChikuzen氏のブログ記事に触発され、自分でもちょっと計算してみました。
まず最初にChikuzen氏の記事を読んだうえでご覧になってください。

   Ch's barn: ConvertToRGB (Chikuzen氏のブログ記事)

 
Chikuzen氏の記事では8bit-depthの計算を行っていたので、
こちらではそれに加えて9bit-depthと10bit-depthについても計算をしてみました。

ただし、正直なところ、こんな計算でいいのか不安です。
記事の最後にソースコードも示していますので、間違ってるとこがあればご指摘ください。
プログラミングも初心者レベルです。

さて、まずは計算結果から。

 
 8bit-Rec601: 2955936
 8bit-Pc.601: 4262360
 8bit-Rec709: 3046424
 8bit-PC.709: 4400226
 9bit-Rec601: 15831400
 9bit-Pc.601: 16713229
 9bit-Rec709: 16149193
 9bit-PC.709: 16777216
10bit-Rec601: 16777216
10bit-PC.601: 16777216
10bit-Rec709: 16777216
10bit-PC.709: 16777216

  ■8bit-depthについては、おおまかな数値はChikuzenさんの計算結果と一致しています。
    フルレンジでも最大440万色。実際にはTVレンジで扱うことが多いので実質300万色前後というところですね。

  ■9bit-depthについては、RGB24の全ての色を表現しうるのはPC.709だけという結果となりました。
    とはいえ、Rec601でも1583万色を表現できますので実用上はほぼ問題ないレベルでしょうか。

  ■10bit-depthについては、どのパターンでもRGB24の全ての色を表現できるという結果となりました。

 
計算に使ったソースコードを以下に示します。表示に「SyntaxHighlighter 3.0」を使っています。
下の「expand source」の部分をクリックするとソースコードが展開表示されます。
ソース部分をダブルクリックすると全選択され、コピーできます。

/* yuvcolor_calc.cpp */
#include <stdio.h>
#include <stdlib.h>
#include <math.h>

#define CLIP_Y(Y) Y = (Y < 0) ? 0.0 : (Y > 1.0) ? 1.0 : Y
#define CLIP_C(C) C = (C < -0.5) ? -0.5 : (C > 0.5) ? 0.5 : C
#define SATURATE(X) X = (X < 0) ? 0 : (X > 255) ? 255 : X

/* RGB24の色数(256*256*256色) */
#define RGB_TABLE_SIZE 16777216

/* H.264のRound()がこんな感じなので */
int myRound(double x)
{
	return (x >= 0) ? (int)floor(x + 0.5) : (int)(-floor(abs(x) + 0.5));
}

int main(void)
{
	const struct {
		char *name;		// 色空間の名称
		int bitDepth;	// ビット深度
		int y_min;		// 輝度Yの最小値
		int y_max;		// 輝度Yの最大値
		int uv_min;		// 色差の最小値
		int uv_max;		// 色差の最大値
		double r_cr;	// YUV→RGB変換の係数1
		double g_cb;	// YUV→RGB変換の係数2
		double g_cr;	// YUV→RGB変換の係数3
		double b_cb;	// YUV→RGB変換の係数4
	} matrix[] = {
		{" 8bit-Rec601",  8, 16,  235, 16,  240, 1.402 , -0.344 , -0.714 , 1.772 },
		{" 8bit-Pc.601",  8,  0,  255,  0,  255, 1.402 , -0.344 , -0.714 , 1.772 },
		{" 8bit-Rec709",  8, 16,  235, 16,  240, 1.5748, -0.1873, -0.4681, 1.8556},
		{" 8bit-PC.709",  8,  0,  255,  0,  255, 1.5748, -0.1873, -0.4681, 1.8556},
		{" 9bit-Rec601",  9, 32,  470, 32,  480, 1.402 , -0.344 , -0.714 , 1.772 },
		{" 9bit-Pc.601",  9,  0,  511,  0,  511, 1.402 , -0.344 , -0.714 , 1.772 },
		{" 9bit-Rec709",  9, 32,  470, 32,  480, 1.5748, -0.1873, -0.4681, 1.8556},
		{" 9bit-PC.709",  9,  0,  511,  0,  511, 1.5748, -0.1873, -0.4681, 1.8556},
		{"10bit-Rec601", 10, 64,  940, 64,  960, 1.402 , -0.344 , -0.714 , 1.772 },
		{"10bit-Pc.601", 10,  0, 1023,  0, 1023, 1.402 , -0.344 , -0.714 , 1.772 },
		{"10bit-Rec709", 10, 64,  940, 64,  960, 1.5748, -0.1873, -0.4681, 1.8556},
		{"10bit-PC.709", 10,  0, 1023,  0, 1023, 1.5748, -0.1873, -0.4681, 1.8556},
		{NULL}
	};

	bool *rgbTable = (bool *)malloc(RGB_TABLE_SIZE*sizeof(bool));
	if(!rgbTable){
		fprintf(stderr,"malloc(rgbTable) failed\n");
		return -1;
	}

	double Y_a=0,Cb_a=0,Cr_a=0;
	int r=0,g=0,b=0;
	int i=0,count=0,num=0;
	int rgbNumber;

	for(int m=0; m<=11; m++){

		printf("%s: ", matrix[m].name);

		// rgbTableをクリア(falseにする)
		for(i=0;i < RGB_TABLE_SIZE;i++){
			rgbTable[i]=false;
		}

		count=0;
		for (int Y = matrix[m].y_min; Y <= matrix[m].y_max; Y++){
			for (int Cb = matrix[m].uv_min; Cb <= matrix[m].uv_max; Cb++){
				for (int Cr = matrix[m].uv_min; Cr <= matrix[m].uv_max; Cr++) {

					// まずはデジタルYCbCr→アナログYCbCr変換
					// (Y_a:0.0~1.0、Cb_a,Cr_a:-0.5~0.5)
					// "アナログYCbCr"という表現はよろしくないけどスルーの方向で。
					// bitDepthをnとすると、H.264で定義されてる量子化式はだいたいこんな感じなので、
					// ここから逆算してY_a、Cb_a、Cr_aを求める。
					// ●TVレンジ
					//   Y = ( 1 << (n-8) ) * (219 * Y_a + 16)
					//   Cb = ( 1 << (n-8) ) * (224 * Cb_a + 128)
					//   Cr = ( 1 << (n-8) ) * (224 * Cr_a + 128)
					// ●フルレンジ
					//   Y = ( (1 << n) - 1) * Y_a
					//   Cb = ( (1 << n) - 1) * Cb_a + ( 1 << (n-1) )
					//   Cr = ( (1 << n) - 1) * Cr_a + ( 1 << (n-1) )

					// minとmaxを用意しとけばTVレンジでもフルレンジでも
					// 1つの式でいけるので、そのように変形してみた。
					Y_a  = (Y -  matrix[m].y_min) / (double)(matrix[m].y_max - matrix[m].y_min);
					Cb_a = (Cb - ( 1 << (matrix[m].bitDepth - 1) ) ) / (double)(matrix[m].uv_max - matrix[m].uv_min);
					Cr_a = (Cr - ( 1 << (matrix[m].bitDepth - 1) ) ) / (double)(matrix[m].uv_max - matrix[m].uv_min);
					CLIP_Y(Y_a);
					CLIP_C(Cb_a);
					CLIP_C(Cr_a);

					// 続いてアナログYCbCr→デジタルRGB変換
					// 基本的には、まるも氏の
					//  http://www.marumo.ne.jp/db2002_5.htm#15
					// の記事を参照。
					// ただしこの記事は2002年のものであり、
					// BT.709の係数はBT.709-1のものになっている。
					// H.264ではBT.709-2以降の係数が使われているので、
					// ここではBT.709-2の係数で計算している。
					// YUV→RGBのアナログ変換式のみ載せておく。
					// (R,G,B,Y:0.0~1.0、U,V:-0.5~0.5)
					// ●BT.601
					//   R = Y          + 1.402 × V 
					//   G = Y - 0.344 × U - 0.714 × V 
					//   B = Y + 1.772 × U 
					// ●BT.709-2
					//   R = Y           + 1.5748 × V
					//   G = Y - 0.1873 × U - 0.4681 × V
					//   B = Y + 1.8556 × U

					r = myRound(255.0 * (Y_a                         + matrix[m].r_cr * Cr_a));
					g = myRound(255.0 * (Y_a + matrix[m].g_cb * Cb_a + matrix[m].g_cr * Cr_a));
					b = myRound(255.0 * (Y_a + matrix[m].b_cb * Cb_a                        ));
					SATURATE(r);
					SATURATE(g);
					SATURATE(b);

					// 再現できた色はtrueにする
					rgbNumber = ((r << 16) | (g << 8) | b);
					rgbTable[rgbNumber] = true;
				}
			}
		}

		// trueになっている色の数をカウントして出力
		num = 0;
		for (i = 0; i < RGB_TABLE_SIZE; i++){
			if (rgbTable[i]){
				num++;
			}
		}
		printf("%d\n", num);
	}
	free(rgbTable);
	return 0;
}


| | コメント (0) | トラックバック (0)

2011年12月 9日 (金)

2012年1月末頃にJahshaka 3.0がリリースされるらしい

2011/12/09追記:
  ・記事の最後にJahshaka公式のTwitterアカウントブログYoutubeチャンネルのリンクを追加。


最近ではフリーの動画編集・加工ソフトといえば

  ■NicoVisualEffects (NiVE1.xx & NiVE2.xx)

  ■AviUtl+拡張編集Plugin

  ■Javie (Sourceforge作者らくさん氏のブログ

  ■CrystelEngine

  ■紙芝居クリエーター

など、色々な選択肢がありますが、これらが登場する前には

  ■Debugmode Wax

  ■Jahshaka(CineFXとも呼ばれているらしい) (SourceforgeWebSite

といった海外ソフトの名前が挙がっていた時代がありました。あったのかな。あったんじゃないかな。
まあ時代と言っても私が動画作成に興味をもって調べ始めた2008年頃の話ですし、
当時色々ググって見つかったのがこれくらいだったというだけなんですけども。
結局私はNiVEに飛びつきましたので、これらの海外ソフトについて詳しいことは知りません。
一応インストールしてみた記憶はあるのですが、「うん、よくわからねー」で終わった気がします。\(^o^)/

Waxは2005年7月、Jahshakaは2006年10月を最後に更新されていなかったのですが、
最近になってJahshakaのほうに動きがあったようです。

いつ頃からかは不明ですが、JahshakaのWebsiteに行くと、以下のようなカウントダウン画面が表示されるようになっています。
(画像は日本時間の2011/12/08 23:36にキャプチャしたものです。)

Jahshaka20111208233657

どうやら2012年1月末頃にJahshakaのバージョン3.0がリリースされるようですね。

英語WikiのJahshakaの記事を見ると、

   The project has come under criticism as the latest update, being in October 2006, has been
   abandoned by developers due to inefficient code and excessive glitches.
   After the version 2 abandonment, developers have been promising a newly coded, reliable version 3.
   The developers have been updating OpenLibraries, pushing the development of version 3
   further in an unannounced time table.
   However, as of August 2011, there hasn't been any new information about this project since 2009;
   it seems that development has terminated.

   (2006年10月の最終更新が色々ボロクソだったこともありプロジェクトはバージョン2を最後に放棄されたが、
    その後開発者たちは新たに信頼性の高いバージョン3を開発すると約束した。
    予定は未定のままバージョン3に向けてライブラリの更新などが行なわれてきたようだが、
    2009年以降、2011年8月の時点でも何の情報も出てきてないし、
    もう開発やめちまったんじゃねえかな、これ。

なんて書かれてるわけですが、水面下では着々と開発が進められていたようです。

とはいえ、これ以上の情報は見つからず、どのようなものになるのかはまだよくわかりません。
2.0はOpenGLやOpenMLを利用したクロスプラットフォーム対応で、Windowsだけではなく
MacOSやLinuxでも動作するソフトでしたから、多分そのあたりは変わらないでしょう。
独特のユーザーインターフェースで操作がわかりづらいという評価を見かけた気がしますが、
そのあたりも含め大幅に変わってくるのか、単に安定性などをアップさせただけのものになるのか、気になるところです。

まあ最初に挙げたフリーソフト群が素晴らしすぎるので、Jahshaka  3.0が出たからと言って
それに乗り換える人はほとんどいないとは思うのですが、リリースされたら少し試してみたいですね。

Jahshakaがどういうものか気になる人は、SourceforgeのJahshakaプロジェクトのページから
バージョン2.0などがダウンロードできるので、予習的な意味も兼ねて試してみるのもよいかもしれません。
以下にいくつか参考リンクも載せておきます。(日本語での情報はほとんどないようですが・・・)

■公式関連リンク

   Jahshaka 公式Website

   JahshakaのSourceforgeプロジェクト

   Jahshaka公式Twitterアカウント(@jahshakafx)

   Jahshaka公式ブログ

   YoutubeのJahshakafxチャンネル

■参考サイトリンク

   日本語WikiのJahshaka記事

   英語WikiのJahshaka記事

   ジャーシャカ・ドット・ネット

   ニコニコ動画でJahshakaタグを検索(解説動画などがいくつか上がっています)

| | コメント (0) | トラックバック (0)

2011年12月 6日 (火)

ffdshow tryoutsにRGB24出力が復活。更に10bit/16bitのYUV出力も追加。

以前の記事で書いたように、2011/02/25のrev3765でRGB24を含むいくつかの出力色空間を削除したffdshow tryoutsですが、
ffdshow tryoutsのchangelogを見ると、

  2011/11/20 rev4054: re-enable RGB24 as output color space

  2011/11/23 rev4064: add new output color space: 4:2:0 16-bit. P016, MFVideoFormat_P016

  2011/11/23 rev4067: add new output color space: 4:2:0 10-bit. (P010, MFVideoFormat_P010)

  2011/12/01 rev4099: add new output color space: 4:2:2 10/16-bit. P216/P216
                  or MFVideoFormat_P210/MFVideoFormat_P216

  2011/12/03 rev4103: add new output color space: AYUV and Y416, YCbCr 4:4:4 8/16-bit.

といった感じで、rev4054でRGB24が復活し、その後10bit/16bitの出力色空間の実装が進められているようです。
2011/12/05のrev4123の時点ではまだY410(10bitのYUV4:4:4)が実装されていませんが、これから実装されるのかな?
とりあえずRGB24出力が復活したことで、以前書いた
   「CravingExplorerでAVI保存したファイルをMMD(MikuMikuDance)の背景AVIに読み込む
という件も、以前のとおりVFW設定でMP42を有効にするだけでOKになりました。

しかし10bit/16bitの出力というのはこれからどの程度活用されていくのか、いまいちよくわからない・・・。

なお、rev4123時点での出力色空間の設定画面は以下のようになっています。
"Primary output color space"という選択ボックスは、優先する出力色空間を指定するためのもので、
2011/12/04のrev4121で追加されたものです。

Ffdshowrev4123outputcolor

| | コメント (0) | トラックバック (0)

2011年11月25日 (金)

HuffyuvS(末尾にSがつくもの)は基本的に使わないほうが良いというお話

可逆圧縮コーデックとして有名なものに「Huffyuv」があります。

それを独自に改造したコーデックに「HuffyuvS」というものがあります。
本家と間違えやすいですが、末尾に「S」がつく別物です。
(おそらくこの「S」は「ストレート」の「S」だと思われます。)

※最後のSを小文字にして「Huffyuvs」と表記されることもありますが
  ここでは最後のSを大文字にした「HuffyuvS」という表記に統一します。
  (そもそもコーデックの設定画面などでも両方の表記が使われており統一されていません)

比較的初期のニコニコ動画まとめWikiでは、可逆圧縮コーデックの定番として
この「HuffyuvS」を勧めていましたが、現在では取り消されています。

aviutlを使ったVP6 2pass - ニコニコ動画まとめwiki
 
可逆圧縮コーデック「Huffyuv」を、コーデック内部のRGB-YUV変換が
ストレート変換になるように改造したもの。
この改造の意味がわからないまま使うと映像の色が大きく変わるという
結果を招くことがあるので、基本的には使うべきではない。

このページに書いてあるように、HuffyuvSの仕組みを理解しないまま使うと
映像の色が大きく変わるという結果を招くことがあるので、
動画編集ではHuffyuvSを使うのはやめたほうがよいでしょう。

また、現在入手できるHuffyuvS(huffyuvs_0.6_-_left_origin_-_base2.1.1-ccesp_dll.zip)は、
   「Huffyuv 2.1.1 CCESP Patch v0.2.2」
という、本家Huffyuv 2.1.1にパッチを当てたものをベースにしていますが、
このパッチ自体にも欠陥がありますので、あまり使うべきではありません。

以下、調べたことを書いていきます。

» 続きを読む

| | コメント (0) | トラックバック (0)

2011年11月23日 (水)

ニコエンコ v0.77を使う場合の注意点

ニコニコ動画にアップロードする動画をエンコードするために使われる
代表的なエンコードツールの1つとして「ニコエンコ」が挙げられます。
最新版は2010/04/25のv0.77となっています。

これを使う際、以下の2点に注意すべきだと思うのでまとめてみました。
個人的な意見も入りますので、参考程度に見てください。

  注意点1.「ヘルプ→本体の設定」にある「変換速度」で「最低速」を選んではいけない。

  注意点2.トップ画面の「動画を変換する」ボタンによる自動変換ではなく、
        メニューの「手動変換」を使ってエンコードしたほうがよい。

以下に理由を示していきます。

» 続きを読む

| | コメント (0) | トラックバック (0)

2011年11月 5日 (土)

AviUtlと拡張x264(GUI)Ex 1.13までは10bit-depthのBT.709エンコードをするのは難しかった(1.14で対応済)

※2011/11/9追記
  2011/11/8にリリースされた「拡張x264(GUI)Ex 1.14」にて、YC48からの色空間変換の設定が実装されました。
  したがって、この記事の内容は既に意味がなくなっています。

  拡張x264(GUI)Ex 1.14で「10bit-depthでのBT.709出力」を行ないたい場合は、
    1.ソース映像を通常どおりプレビューが正しい色になるように読み込む。
    2.拡張x264(GUI)Exの「x264」タブで「10bit depth」にチェックを入れ、10bit-depthのx264.exeを指定する。
    3.拡張x264(GUI)Exの「x264」タブで「colormatrix」に「bt709」を指定する。
    4.拡張x264(GUI)Exの「拡張」タブで「YC48出力」を「BT.601→BT.709」にする。
  という設定を行なえば、YC48からの10bit変換で色空間を考慮した変換が行なわれ、
  問題なく「10bit-depthでのBT.709出力」ができるようになっています。
  作者のrigaya様、実装ありがとうございます。

 
◎2011/11/9追記
   ・拡張x264(GUI)Ex 1.14にてYC48からの色空間変換の設定がサポートされたので記事をクローズ。
    タイトルも過去形に変更。
   ・10bitでの色変換についての参考記事へのリンクを書き忘れていたので追加。
       rigayaの日記兼メモ帳 H.264 high bit depth decoder

◎2011/11/6修正
   ・YC48を「約12bit深度」としましたが実際には「16bit深度」でした。
    輝度や色差のマッピング範囲が約12bit+α相当なのであながち間違っていないかもしれませんが
    YC48のデータ構造自体は16bit深度です。(PIXEL_YC構造体では輝度と色差の値はshortとなっている)
       参考: x264のYUV4:4:4/RGB、AviUtlのYC48とYUY2入出力の仕様 (POP@4bit)
   ・拡張x264出力(GUI)Exの設定画面で出力色空間を指定するなら、拡張タブではなく
    x264タブの「10bit depth」の近くで設定できたほうが自然かもと思ったのでその旨を追記。
    

◎2011/11/5修正
   ・YC48を「12bit+1深度」と表現していたのを「約12bit深度」に修正。
    TVスケール輝度が0~4096になるだけで、フルスケール輝度は-299~4470の範囲を取るため。
   ・Makki氏の「AviUtlの内部形式について」のリンクを追加。
   ・デコーダーについていくつか注意書きを追記。
    比較的新しいものでないと10bit再生には対応していません。

※注意
  記事作成時の各ソフトのバージョンは、
     AviUtl 0.99j2
     拡張x264(GUI)Ex 1.13
  です。

------------------------------記事本文ここから------------------------------

AviUtl」と「拡張x264(GUI)Ex」を使って

   「10bit-depthのBT.709エンコード」

を行なおうとした場合、8bitの時と同じ感覚では間違えるというか、
かなりわかりにくいことをしないと正しくエンコードできないことがわかったのでまとめてみました。
色空間の話になるので、なかなか厄介でわかりにくいです。

うまく対処するには、拡張x264(GUI)Ex側での機能追加が必要な気がします。

この記事にある内容の影響を受けるのは、地デジのTSなどを10bit-depthでエンコードして
保存しているような人になると思います。(HDサイズならBT.709にしているはずですし。)
あとはPV3/PV4を使ってHDキャプチャしたものを10bit-depthでエンコードしている人とか。

なお、ニコニコ動画への投稿には10bit-depthは使ってはいけないので関係ありません。
(FlashPlayerは10bit-depthを正しく再生できないため。右側にマゼンタ色の線が入る上、色も微妙におかしくなる。)

■問題点

  AviUtlと拡張x264(GUI)Exを使って、以下の2つの条件を満たす出力を行なう場合、
  特殊な方法をとらないと正しく出力ができない。

    条件1.8bit-depthでi444出力を行ないたい。
         あるいは10bit-depthで出力(i420,i422,i444)を行いたい。

    条件2.出力色空間をBT.709としたい。

  AviUtlと拡張x264(GUI)Exでの色空間の扱いを詳しく知らないまま
  直感的にやろうとすると、かなりの高確率で間違ったエンコードになると思います。
  特にAviUtlの内部色空間である「YC48(16bit深度)」について理解しておかないとわかりにくいです。

長いので折りたたみます。
 

» 続きを読む

| | コメント (4) | トラックバック (0)

2011年11月 3日 (木)

AviUtl拡張編集のLuaスクリプトのデバッグツール

AviUtl拡張編集のLuaスクリプトをデバッグする方法を教えてもらったので記事にしておきます。

使用するツールは、以下の2つのいずれかがよさそうです。(両方ともフリーソフト)

  DebugView for Windows (Microsoft TechNet)
    ・Windows7で動作するかどうかは不明。
    ・表示フォントが選べる。
    ・ログの検索やフィルタリングが出来る。
    ・他にもなんか色々機能があるみたいだけどよくわからない。

  デバッグモニタツール (Vector)
    ・VistaやWindows7で動作するかどうかは不明。
       →Windows7 64bit環境でちゃんと動いたそうです。
    ・シンプルな表示のみ。ごちゃごちゃしてるのが嫌な人はこっちでいいかも。

書いたスクリプトがうまく動かないような場合に、このツールを起動しておくと、
Luaのエラーメッセージを表示してくれるので、それを手がかりとしてLuaスクリプトを修正できます。

また、スクリプト用に用意されているdebug_print()関数を使えば、デバッグ用のメッセージを出力することもできます。
ただし英数字以外は文字化けしてしまいます。日本語も表示できると便利そうなんですけどねえ。

なお、「スクリプト制御」などでスクリプトを直接入力している場合、
1文字書くごとにスクリプトが評価されるためエラーメッセージが連発されます。
書き変えるときは「スクリプト制御」右上のチェックを外してスクリプト制御を一時的に無効にしたり、
問題が起きたときだけデバッグモニタツールを起動するようにするなど、使い方を工夫しましょう。

なお、*.anmや*.objなどのスクリプトファイルを書き変えた場合は、
拡張編集上でF5キーでキャッシュのクリアを行えば、新しいスクリプトを再読み込みしてくれます。

●参考:(拡張編集プラグイン付属のlua.txtより)

    ○debug_print(text)
       指定の文字をOutputDebugString()に送ります。デバック用です。
       ※スクリプト実行エラーのメッセージは自動的にOutputDebugString()に
         送られるようになっています。
            text : デバック表示文字
            例 : debug_print("デバック表示")

いや~、OutputDebugString()ってなんだろうって思ってたんですよね・・・。
普段からプログラム書いてるような人にとっては常識なのかもしれないけど、全然知らなかった・・・orz

DebugView

Debugview

デバッグモニタツール(Debug Monitor Tool)

Debugmonitortool

| | コメント (0) | トラックバック (0)

2011年10月27日 (木)

つんでれんこ v2.51のx264設定を、拡張x264(GUI)Ex v1.13用の設定ファイルにしてみた

エンコードの勉強がてら、窓屋(Twitter)氏のつんでれんこ v2.51のx264設定を調べて、
rigaya氏の拡張x264(GUI)Ex v1.13用の設定ファイル(*.stg)を作ってみました。

   拡張x264(GUI)Ex v1.13用設定ファイルのダウンロード

使い方や細かい説明などは同梱したreadmeを参照。
以下、調べたプリセット内容についてのメモ。(長いので折りたたみ)

» 続きを読む

| | コメント (0) | トラックバック (0)

2011年10月14日 (金)

ハードウェアアクセラレーション(GPU再生支援)を考慮した場合のx264エンコード設定について

※重要
 知識が浅いため色々と間違ってる可能性があるので
 書いてあることは鵜呑みにせず厳しい目でチェックしてください。

※今更な感じもしますけど、自分がちゃんと理解できておらずエンコードスレで質問中なことをまとめ。
※間違ってる点があればコメントをいただけると、とてもありがたいです。
※調べれば調べるほど、これまでLevelとか全然気にせずエンコしてたのが恥ずかしくなってきました。/(^o^)\
  PS3とかPSPとか携帯端末とか向けにエンコしてる人とか、ちゃんと勉強してエンコしてる人なら
  refとかbframesとかが色々関わってくるのは常識なのだろうけど、
  とにかくニコニコにアップして見れればいいやと適当にエンコしてたからなあ・・・。orz

※2011/10/18更新
  ・一覧表にて、レベル3.2についての記述と計算が抜けていたので追加してその結果を反映。
  ・表に解像度720x480、720x576、1024x576、1024x768、1440x1080を追加。
  ・自分でもテスト用動画をアップしてみたので、その動画一覧のマイリストへのリンクを追記。
  ・その他、記述をいくつか修正。

-----

FlashPlayerは、2010/6/10にリリースされたバージョン10.1から
H.264のハードウェアアクセラレーション(GPU再生支援)をサポートしています。
これを利用すれば、GPUがデコードを行なってくれるので、比較的貧弱なCPUでも
HDサイズのH.264動画をさくさくと快適に再生できるわけですね。

ハードウェアアクセラレーション機能は、FlashPlayerの再生画面を右クリックして「設定...」を選択し、
左下の「ディスプレイ」タブにある「ハードウェアアクセラレーションを有効化」のチェックボックスで
有効・無効を切り替えることができます。
(実際に有効・無効を切り替えるには、動画の再読み込みも必要になります。)

Flashplayerhwconfig

また、ハードウェアアクセラレーションを利用するには、使っているPCのグラフィックカード(チップ)が
H.264の動画再生支援をサポートしていることも条件となります。
まあ最近のPCであれば、多分サポートされていると思います。
(私が使っている5年前のノートPCはIntel945GMチップセットなのでサポートされていませんが・・・orz)

H.264の動画再生支援がサポートされているかどうかは、DXVACheckerというツールで調べることもできます。
AMD系のグラフィックカード(Radeonシリーズとか)なら「デコーダデバイス」の欄に
   ModeH264_VLD_NoFGT_Flash
が出てくればOKで、それ以外なら
   ModeH264_
で始まるのが出てくれば、多分サポートされてます。(自分で試せないのでかなりアバウト。)
ドライバが古いと出てこない可能性もあるので、サポートされているはずなのに出てこないという場合は
ドライバを最新のものにしてみるとよいかもしれません。(ただし自己責任でお願いします。)

さて、このハードウェアアクセラレーションですが、
場合によっては働かなかったり、映像が乱れてしまうことがあるようです。

そのあたりの参考情報が、以下の大百科記事やマイリストにまとめられています。

  動画がおかしくなる方は大百科をクリック→とは- ニコニコ大百科

  FLVENC2 ツール&画質テスト H264

  ガラクタ置き場(互換検証)

大百科記事では、
  ハードウェアアクセラレーション有効時に再生に問題が起きた場合は、FlashPlayerの
     「ハードウェアアクセラレーションを有効にする」
  のチェックを外したうえで動画を再読み込みする。

という対処方法が示されています。
ただし、そうするとGPUではなくCPUでデコード(ソフトウェアデコード)することになるため、
CPUの処理能力が低い場合は動画がカクついたりまともに再生できなかったりすることがあります。

上の記事やマイリスに入っているなかで、GPU再生支援で問題が起きることがあるらしいという動画を、
  解像度 フレームレート プロファイル@レベル ref bframes
のパラメータつきで3つ貼っておきます。(MediaInfo 0.7.47 で調査)
映像がおかしくなるかどうかは環境次第だとは思いますが、
ハードウェアアクセラレーションを有効にした上で視聴してみてください。
(問題が起きた場合、問題が起きた動画と、使っているグラフィックカードをコメントで教えてもらえるとありがたいです。
 勝手に動画を貼ってすみません。本当なら自分でテスト動画をアップすべきなんでしょうけど、
 作ったとしても自分では確認できないもので・・・。

2011/10/18追記:
  自分でもテスト用の動画をアップロードしてみました。640x360 24fpsのもので、
  まずいとされるエンコードオプションの値を少しずつ変えてみたものです。以下のマイリストからどうぞ。
  (自作PC板のIntelスレやコメントの反応を見ると、少なくともIntel HD Graphics 2000or3000ではref=16のもので映像が乱れるそうです。
   なお、低画質モードだとサーバー側で再エンコードされた映像を見ることになり、テストにならないのでご注意下さい。)
     ハードウェアアクセラレーション(DXVA)テスト用動画リスト

動画1. 512x384 30fps High@3.0 ref=5 bframes=3
 

動画2. 1280x720 59.94fps High@L5.0 ref=16 bframes=16
 

動画3. 512x288 29.97fps High@5.1 ref=16 bframes=16
 

また、少し古い情報ですが、

  H.264(AVC) + UVD(DXVA) / J-pro.info

  x264 Encoding Options for Hardware Compatibility & DXVA - AVS Forum

を見ると、GPU再生支援を利用するためには、エンコード時にH.264 Levelの条件をしっかり守って
--levelでレベルを明示的に指定するといったことが大事になってきたりするようです。

更に

  【ニコニコ動画】FLV/MP4エンコードスレ 53【質問】

で質問してみたところ、動き予測の参照距離(--ref)が16だとGPU再生支援が無効になったり
映像が乱れることがあるという話を教えてもらいました。

つまり、x264でのエンコード時に、ハードウェアアクセラレーション(GPU再生支援)が
きちんと働くように設定を行なうことが重要になってくるわけですね。

 
さて、ここからが本題です。

以上の情報を踏まえてニコニコ動画まとめWikiの推奨設定を見てみたところ、
レベルをきっちり守れず、refも16になってしまうケースがあることに気づきました。
これがどの程度問題になるのかはよくわかりませんし、実は全然問題ないかもしれませんが、
どうせならきっちりとした設定を考えてみたいと思い、今ある情報をまとめてみました。

長くなるので折りたたみます。
わからないことだらけですので、コメントなどいただければありがたいです。
(ここではなく「【ニコニコ動画】FLV/MP4エンコードスレ 53【質問】」のほうでも質問中なのでそちらでも。)
 

» 続きを読む

| | コメント (0) | トラックバック (0)

2011年10月 3日 (月)

文字を3Dモデル化してAviUtl拡張編集に読み込ませる方法(立体テキストの作成)

※筆者は3DCGモデリングの知識があんまりない素人です。
  メタセコイアもPMDエディタも、今回初めて使ったので、詳しいことはよくわかっていません。
  この記事は「とりあえずこんな感じでやったらできた」というメモにすぎませんので、
  コメントで色々と指摘していただければ幸いです。

※2011/10/03
  とりあえずざっくりとした概要のみ。まだ文字だけですが少しずつ手を入れていきたいと思っています。

※2011/10/03 21:45追記
  Blenderという3DCGアニメーションソフトでも、テキストの3Dモデルを簡単に作れる上、
  色々な整形ツール(捻ったり)も使えて便利だとのことです。
  まだ試せていませんが、興味のある方はそちらも試してみるとよいかもしれません。

 
---ここから記事開始---

今更ですが、「AviUtl拡張編集Pluginスレッド Part4」の223氏が書いてくれた
立体テキストの作り方を試してみましたので、手順をメモとしてまとめてみました。
223氏、本当にありがとうございました。

 ◎単色の立体テキストを作って読み込んだ例(拡張編集プラグインによる動画)

 ◎テクスチャを貼った立体テキストを作って読み込んだ例(拡張編集プラグインによる動画)

AviUtl拡張編集Pluginスレッド Part4 のレス223

223 名前:名無しさん@お腹いっぱい。 投稿日:2011/08/20(土) 09:56:52.05 qC0dOcHc0
>>218
スレ違いというか板違いだけど、ヒント的な
PMD=MMD用可動3Dフィギュア
おすすめ3DCGモデリングソフトはとっつきやすいメタセコイア
「メタセコイア テキスト」でググると立体文字作成ソフトが出てくる
できたmqoをメタセコで読み込んで.xで出力して、MMD関連ソフトのPMDeditorでインポートしてPMD出力
自分でモデルを作るのは、MMD本とかメタセコ解説サイト(clip-studio)色々あるけど、絵が描けないとかなり辛い

» 続きを読む

| | コメント (0) | トラックバック (0)

«ffdshow tryouts rev3765での出力色空間の削減とその影響