奥山 健一
( Home )
2002-07-01 10:20:52 ( ID:vj4g5uxhnaw )
[ 削除 / 引用して返信 ]
2pass モードについて質問があります。
VBR で 2pass を選択すると、1度ソースを展開して端から端までスキャンしていますよね?で、そこで得られた情報を利用しつつ、2度目の展開で encoding を行っているとおもいます。
しかし、この 2pass モード、ここまで「完全に」2度再生しなくてはいけないものなのでしょうか…。たとえば(Encode 後のframe 数で)6GOP分だけ先読みしておく、とかそういう「部分的な」2pass モードというのは意味がないんでしょうか?
マルチCPU環境でメモリもゴッソリ存在する場合などには、こういう部分的な 2pass は「適度に高品質で、適度に早い」状態を作れるのではないか、と思ったんですが…。
fay
2002-07-01 11:44:58 ( ID:k07nygitk0f )
[ 削除 / 引用して返信 ]
ちょっと内容が分かり辛いんですが、エンコードスレッドよりも先行して動く調査ス
レッドのようなものを用意すればどうか?ということでしょうか? もしそうであれ
ば、レートの割り振りはどのように行うのでしょうか?
例えばアニメなどではOPは凝った作りで高レートを必要とするけども、本編はそれ
ほどでもないということが普通です。OPと本編一部(例えばクライマックスなど)だ
け8Mbpsで残りは適度に3〜5Mbpsを使い平均6Mbpsというエンコードの場合、やはり全
体をスキャンしなければレートの割り振りは出来ないように思います。
アニメなどは極端な例ですが、他にもドラマなどはクライマックスでも何でもない
シーンで結構レートを食われたりします。そういうのは突発的に発生することが多い
ので、なかなか事前に予測するのは難しいと思います。
奥山 健一
( Home )
2002-07-01 16:20:05 ( ID:vj4g5uxhnaw )
[ 削除 / 引用して返信 ]
>例えばアニメなどではOPは凝った作りで高レートを必要とするけども、本編はそれ
>ほどでもないということが普通です。OPと本編一部(例えばクライマックスなど)だ
>け8Mbpsで残りは適度に3〜5Mbpsを使い平均6Mbpsというエンコードの場合、やはり全
>体をスキャンしなければレートの割り振りは出来ないように思います。
しかし同時に、大抵のOPと本編の間にはCMが入りますよね?このCMを切るために、OPと本編が別ソースになる人も多いはずです。OPと本編を別々にエンコードする人にとって、そういう大きなレート割り振りはマニュアルで決定するものです。この場合は、結局全体をスキャンする必要性はありません。
完全2passはいらない、という意味ではありません。
微妙なビット割り振りを可能にするには2pass の最初のパスでかなりの情報を保存する必要があるはずです。『そこまで凝らなくてもいいぞ』という人向きの「1passよりは先読みをするけど完全2passじゃない」的なバランスポイントってあるんじゃないか、ということです。
とおりすがり
2002-07-01 16:38:32 ( ID:enngnieiyb2 )
[ 削除 / 引用して返信 ]
>微妙なビット割り振りを可能にするには2pass の最初のパスでかなりの情報を保存する必要があるはずです。『そこまで凝らなくてもいいぞ』という人向きの「1passよりは先読みをするけど完全2passじゃない」的なバランスポイントってあるんじゃないか、ということです。
そう言う人は1Pathで良いんじゃ?
逆に考えて、2Pathは「そこまで凝りたい」人だけ使えば良いのでは?
実際、エンコ時間倍増するわけで、凝りたくなかったら1Pathで十分じゃ?
初診者
2002-07-01 17:03:58 ( ID:jglxtithahh )
[ 削除 / 引用して返信 ]
CQで設定を工夫すれば画質的には充分な気がしますね
出来上がりサイズは2パスVBRよりも予測しづらいでしょうけど
fay
2002-07-01 17:58:44 ( ID:k07nygitk0f )
[ 削除 / 引用して返信 ]
奥山 健一さんがおっしゃっている内容については分かりましたが、それで意味のある
処理になるのか?ということと、実現可能なのか?という点が疑問です。
2PassVBRの亜種と言うからには、指定サイズで作成するための「平均レート」という設
定内容があると考えます。2PassVBRとは指定サイズ内でいかに高画質にするかという処
理なわけですから。しかし先読みが例のように6GOP(約3秒)だと仮定すると、その3秒
(+これまでのエンコード結果)で平均レートを満たすようなエンコード処理をしなけれ
ばならなくなります。これはちょっと無理なんじゃないでしょうか? 逆にこの部分を
満たせるアルゴリズムがあるなら、確かに魅力的なエンコード処理となるわけですが。
なお平均レート設定が無いなら、今度は1PassVBRとどこが違う?となってしまうわけで
す。
確かにCCE(Lite)では数GOP先まで先読みした上でCBRの制御をしているそうです。そう
やってCBRの制限内での精度を高めているのですが、これはレート制御が要らないCBR
だからこそ出来る処理だと思います。
奥山 健一
( Home )
2002-07-01 20:19:34 ( ID:qxbertlhwho )
[ 削除 / 引用して返信 ]
>2PassVBRの亜種と言うからには、指定サイズで作成するための「平均レート」という設
>定内容があると考えます。2PassVBRとは指定サイズ内でいかに高画質にするかという処
>理なわけですから。しかし先読みが例のように6GOP(約3秒)だと仮定すると、その3秒
>(+これまでのエンコード結果)で平均レートを満たすようなエンコード処理をしなけれ
>ばならなくなります。これはちょっと無理なんじゃないでしょうか? 逆にこの部分を
>満たせるアルゴリズムがあるなら、確かに魅力的なエンコード処理となるわけですが。
たとえば前後13GOPでの平均値が維持されるように頑張るモデルとか。
#厳密には前後 2*n+1 GOP で平均値を維持しろ、となるのでしょう。
過去 nGOP 分はすでにビットレートが決まっていますので、これからの n+1GOP 分で残りのビットをわけあう、というアルゴリズムですね。
n とビットレートを両方指定できるようにして、2*n+1≡全GOP数 にすれば2pass そのものだ、と言うこともできるような気がするので、こちらの方が柔軟性がある気もします。
少なくとも実現可能性は十分あると思います。
ただし、『意味があるか』の方は…んー。判りません。やってみないことには。
#画質の荒いビデオの場合はあるいは…。
素人
2002-07-01 21:31:25 ( ID:5r/fkf3e8h. )
[ 削除 / 引用して返信 ]
素人考えだと思うのですが
映像を全フレームスキャンするのではなく、1-αのフレームを飛ばしながら映像をスキャン
してエンコードを行う、という方法で
全体のエンコード時間を短くするということは出来ないのでしょうか?
夜勤明けの初心者2
2002-07-02 01:18:24 ( ID:a3f2.vln9tg )
[ 削除 / 引用して返信 ]
半分しか意味が分かりませんでしたが・・・要は1,5パスのようなものがほしいということでしょうか?
それとも2パスを時間重視と画質重視に分けてほしいということでしょうか?
個人的には画質重視のままでいいと思いますが・・・。(べつに否定する気はありませんが)
それよりは2,55 2,56と安定性が悪い気がするので、そちらに力をまわしてほしいですね。
2,54aで安定しているので別にいいことといえばいいことなんですが・・・。
奥山 健一
( Home )
2002-07-02 14:44:21 ( ID:vj4g5uxhnaw )
[ 削除 / 引用して返信 ]
>それよりは2,55 2,56と安定性が悪い気がするので、そちらに力をまわしてほしいですね。
>2,54aで安定しているので別にいいことといえばいいことなんですが・・・。
中を見たことがあるわけではないので、何とも言いがたいのですが、この手のプログラムは普通、「フレームワーク」と言われるものと「ファンクション」と言われるものの2つに分離してデザインします。2.55, 2.56 と、不安定なのは「フレームワーク」であって「ファンクション」ではありません(なんかDVD(NTSC) のテンプレートが 384x480 になってるとか、いくつか変なところが増えている気もしますが)。
きちんとしたデザインに基づいていて、開発に参加可能な人間の数が増やせるなら、今回の私の意見は「ファンクションの増設」であって「フレームワークの安定化」ではないので、並行してできる事だろうと思います。「フレームワークの安定化」には人数ではなく時間がかかるものですし、デザインが良ければ一旦安定したフレームワークは、長い間有効に使えますから。
ICZ
2002-07-02 15:27:33 ( ID:114ayb6nh.g )
[ 削除 / 引用して返信 ]
6GOP先行して2PASSにしたところで、結局は2PASSには変わりないのでエンコード時間は今の2PASSと同じになるのではないのでしょうか。
デュアル環境で6GOP先行1PASSをCPU1、2PASS目をCPU2で処理させるということと、TMPGEncを2つ立ち上げて例えば前半部と後半部を同時に2PASSエンコードしても結果的に同じ処理時間になるのでないかと思いますが。
思うにインターリーブの設定が0で映像部のエンコード後に音声部を一括エンコードするのと、インターリーブ1で映像と音声を同期してエンコードしても最終的に処理時間は同じ(?)という事と同義な気もします。
一つのプロジェクトだけ処理する時に1.5〜2.0倍の速度でエンコードが完了し、ファイルサイズがエンコード前にビットレート計算した物と誤差がないこと、画質が1.5倍のエンコード時間に見合うものが得られる事、であれば先行2PASSVBRの意味はあると思います。
でも1CPUマシンでは意味なさそうですが。
ICZ
2002-07-02 15:33:00 ( ID:114ayb6nh.g )
[ 削除 / 引用して返信 ]
>1.5〜2.0倍の速度でエンコードが完了し
今の2PASS時の1.5倍〜2倍程度、処理時間が速いという事です。
奥山 健一
( Home )
2002-07-02 17:10:23 ( ID:vj4g5uxhnaw )
[ 削除 / 引用して返信 ]
>6GOP先行して2PASSにしたところで、結局は2PASSには変わりないのでエンコード時間は今の2PASSと同じになるのではないのでしょうか。
>デュアル環境で6GOP先行1PASSをCPU1、2PASS目をCPU2で処理させるということと、TMPGEncを2つ立ち上げて例えば前半部と後半部を同時に2PASSエンコードしても結果的に同じ処理時間になるのでないかと思いますが。
ソース decoding コストがかからなくなる可能性があるので、安くなる可能性があります。ので、1CPUでも効果がある場合がありましょう。
#メモリは山のように乗っている必要があるので、お金持ちしかメリットがないかも知れません。
前半部と後半部を分離する手間もかかりませんし、あとでくっつけるための時間も手間も必要ありません(シーンの切目を探すのはめんどうだぞ?)また、それらのシーン間の前後にビット割り当てのチューンポイントがあった場合、分解してしまうと適切なビット割り振りになりません。
前半部と後半部をバラバラに読むために発生する、鬱陶しい HDD に対する head seek に伴う性能劣化も起こらないでしょう。
ようするに『pipeline 化』に伴うコストダウンのメリットは全部享受できる、と言っているだけですので、他にも等コストな処理は挙げられると思います。でも「汎用性」では他の方法より勝っていると思います。
もちろん、出てくるものの品質如何でしょうが、『コストに見合った』品質劣化以内に収まるなら、選択肢としても有効でしょう。
とおりすがり
2002-07-02 19:29:45 ( ID:enngnieiyb2 )
[ 削除 / 引用して返信 ]
>ようするに『pipeline 化』に伴うコストダウンのメリットは全部享受できる、と言っているだけですので、他にも等コストな処理は挙げられると思います。でも「汎用性」では他の方法より勝っていると思います。
何処のミドルウェアだかオブジェクト至高(誤変換じゃ無い)言語使いか知らんが。
ホントにファンクションの追加(普通はもっと平易に、機能追加って言わんか?)で終わるのか?
現状のTMPGEncのフレームワークの変更(要は一部機能じゃなくて基本仕様の変更だろ?)が要らないと、どうして言い切れるのが不思議だ。
2回ソースからのデコード&TMPGEncでの加工を掛けるのはロスが多いから、1回で済ませるための短範囲の先読み2重変換、みたいな事を書いてる?
それなら一度AVIに出力したら?
2Path時、加工設定を反映させたAVI作ると、複数回2Pathやり直すときとかはグッと作業を短縮できる。
この場合、先読みは所詮そのつど読み込むから、複数回やり直すときには複数回デコード&TMPGEncでの加工を行うのに対して、デコード&TMPGEncでの加工を反映したAVIを読み込むならデコード&TMPGEncでの加工は最初の1回だけ。
HD容量の追加は、メモリの追加やCPUの高速化や複数化に比べて、圧倒的にローコストで済むと思うし。
ICZ
2002-07-02 23:21:11 ( ID:114ayb6nh.g )
[ 削除 / 引用して返信 ]
1PASS目と2PASS目の動き検索精度を変える事が出来たらどうなんでしょ。
1PASS目、最低画質で高速にビットレート割り振り
2PASS目、最高画質で高画質にエンコード
これってMPEGやエンコーダーの構造的、技術的に可能なんでしょうか。
fay
2002-07-02 23:40:46 ( ID:pkdki5pff/k )
[ 削除 / 引用して返信 ]
確かにICZさんのいわれるように試しも含めてエンコードするフレーム数自体が減る
わけではないので、速くなる点としては読み込み負荷を減らす程度しかないように
思います。また奥山さんのアルゴリズムだと、ある一定幅の中に収まるレートのソー
スしか平均レートを守ってうまくエンコード出来ないと思います。最初に一定幅に
収まるレベルのモノしか扱わないと言うなら良いですが、長時間のものはなかなか
そういうわけにも行かず、非常に扱いづらくなってしまうと思います。
また動きを見てレートを調査するMPEGの場合、フレームを飛ばすわけにはいかない
と思います。また1Passと2Passで動き検索精度を変えるという案は可能で効果があ
ると思いますが、現在のTMPGEncにはキャッシュ機能があり、これがキャッシュする
解析の大半は動き検索の結果だと聞いています。キャッシュを使うと2Pass目の動
き検索自体をほとんど省くことが出来るようです。
奥山 健一
( Home )
2002-07-03 23:59:59 ( ID:qxbertlhwho )
[ 削除 / 引用して返信 ]
> ホントにファンクションの追加(普通はもっと平易に、機能追加って言わんか?)で終わるのか?
終わらないとしたら根本構造がおかしいことになる。たぶん、そんなに変な作りだと主思えない。
ちなみに「機能追加」は「ファンクションの追加」とは概念が違う。ので「機能追加」と言うのは間違いだ。
> 現状のTMPGEncのフレームワークの変更(要は一部機能じゃなくて基本仕様の変更だろ?)が要らないと、どうして言い切れるのが不思議だ。
2pass は「フレームワーク」ではないから。
> この場合、先読みは所詮そのつど読み込むから、複数回やり直すときには複数回デコード&TMPGEncでの加工を行うのに対して、デコード&TMPGEncでの加工を反映したAVIを読み込むならデコード&TMPGEncでの加工は最初の1回だけ。
それでは「非可逆圧縮に伴う加工」分は消えない。一方において、加工するだけなら、ビットレート最大で「別マシンで」TMPGEnc を動かしてもにたような処理速度で済むので、AVI にする必要性はない。
そういう部分を計算にいれるのは(処理量計算としてフェアじゃないので)今回はしていません。
yammo
2002-07-04 08:55:46 ( ID:dat.2whhaqf )
[ 削除 / 引用して返信 ]
>終わらないとしたら根本構造がおかしいことになる。たぶん、そんなに変な作りだと主思えない。
>ちなみに「機能追加」は「ファンクションの追加」とは概念が違う。ので「機能追加」と言うのは間違いだ。
プログラマー経験も無く、PCにも詳しくない人も読んでいると思われる
ここの掲示板で、「概念が違う」とか言われても何のことだか解からないんです。
とおりすがりさんは「普通はもっと平易に」って書いてますよね。
それに対して「間違いだ」は無いんじゃないですか。
>2pass は「フレームワーク」ではないから。
その根拠を聞かれていると思うのですが。
それからもともとの欲しい機能は、2Passをどうこうじゃなくて、
1Pass先読み予測みたいなことにしかみえないから、
1Passへの問いではないんでしょうか。
2Passあるいはマルチパスの本質は、
映像全体を走査することで全体の情報量を推し量ることに意味があるわけですから、
数GOPだけ先読みしてとかは意味がないと思います。
|