mencoder -xvidencopts fixed_quant=4」だと普段1856kb/sでencodeしているものが2.3Mb/sぐらいになってしまった。
確かにこれは奇麗だけど、ちょっとこれは取りすぎなので一週間分を様子を見るのを止めてfixed_quant=4.2で実験。
mencoderのoptionを
-oac mp3lame -lameopts cbr:preset=128 -ovc xvid -sws 2 -xvidencopts fixed_quant=4.5:max_key_interval=300:vhq=4:max_bframes=1:trellis:chroma_me:chroma_opt:hq_ac:cartoon -vf hqdn3d=4:3:6 -noodml
lavcを使っていた時に比べてなんとなく全体的にもやっとした感じがする。
実際のファイルサイズの方は、動きが少なかったり、全体的にノッペリしたような物では予想通り小さくなって、そうじゃないのは今までと大差ないか、ちょっと大きくなっている気がする。
fixed_quant=4.5はちょっと品質落し過ぎかな。
でも、比較のため元のDVを残しておいてものについては、もやっとしているところで、同じ場面を比較しても、あんまり変わらなかったりするんだよなぁ。
とりあえず、一週間、つまり日曜日分まではfixed_quant=4.5で様子を見て、そのあとfixed_quant=4にして一週間様子を見てみよう。
fwohci0: txd err= 3 miss Ack err firewire0: bus manager election failed fw_rcv: unknown response LRES(b) src=0xffc1 tl=0x1 rt=1 data=0x40002 try ad-hoc work around!! no use... firewire0: New S400 device ID:00a0b0210001a733 fwohci0: txd err= 3 miss Ack err firewire0: bus_explore node=1 addr=0x408 resp=22 retry=1 fw_rcv: unknown response RRESQ(6) src=0xffc1 tl=0x7 rt=1 data=0x128164e0 try ad-hoc work around!! no use... fwohci0: txd err= 3 miss Ack err firewire0: bus_explore node=1 addr=0x418 resp=22 retry=1 fw_rcv: unknown response RRESQ(6) src=0xffc1 tl=0xb rt=1 data=0xb0a00003 try ad-hoc work around!! no use...と、出た。 なんかヤバイ感じ。 しかし、ちゃんとスイッチ切替とか、録画は出来るので放置していたのだが、大抵の場合
fwohci0: txd err= 3 miss Ack errと出るので、気にはなっていた。 が、単に「
fwcontrol -r」したら普段と同じ挙動を示すようになった。
よかった。
fixed_quant=4.5でencodeして、様子を見ることにする。
mencoder option最適化実験:fixed_quant=3.5の方は10fpsぐらいでencodeが進んでいる。
ちょっとは速くなったみたいだ。
CPUはNorthwood 2.8GHz。
fixed_quant=4の方はPrescott 3.0GHzで、13fpsぐらい出ている。
fixed_quant=4の方は動画が1259kb/sぐらいになった。
お、結構いい感じだぞ。
これでも納得できる気がする。
若干いえば、ゴチック体で書いてある文字の周りに影が出て気になるぐらい。
fixed_quant=3.5の方は動画が1729kb/sぐらいになった。
mencoder -o e.avi -oac mp3lame -lameopts cbr:br=128 -ovc xvid -sws 2 -xvidencopts fixed_quant=3.5:max_key_interval=300:vhq=4:max_bframes=1:trellis:chroma_me:chroma_opt:hq_ac:cartoon -ofps 23.967 -vf filmdint,hqdn3d=4:3:6 -noodml e.dv
@@@@@@@@ Bottom-first field??? @@@@@@@@が大量に出る。 これ以上の実験は無駄かな。 ちょっとここまでの分で試聴してみようか。
-ofps 23.967」を外して実験。
filmdintをfilmdint=io=2997:2997に変更して実験。
-filmdint=io=2997:2997」を外してencode。
fixed_quant=5にしてencodeしたのを試聴してみた。
もともと動きが少ないアニメというのもあるんだけど1068kb/sで動画部分はencodeされていて、かなり小さい。
んでノイズが走っているように感じる部分は普段の1792kb/sのを見てもやっぱり走っていることからどうも素材の問題みたい。
でも、よくよく見るとちょっとぼやけた感じもしないでもないけど、比較しないと分からんのだよな。
実は、私の体感ではfixed_quant=5でも十分なのかもしれない。
fixed_quant=3のは2479kb/sだった。
これだったら、普段の2176kb/sより食っているので比較の価値ないな。
ということでfixed_quant=4にして、encodeしなおし。
なんか、10fpsぐらいしか出ていないので1-passだと考えても普段より遅いぞ。
まぁ質がよければ許容するが。
fixed_quant=4では1894kb/sだった。
これで視聴実験するか。
fixed_quant=5のencodingが出来た。
1344kb/sだった。
ざっと見た感じ若干もやっと感じるけど許容範囲かもしれない。
もう一度、25分かけて見る気は起きないので、次の映像でfixed_quant=5にして実験かな。
-ovc xvid」と大差ないということか。
現在、2-pass目の60%ぐらいが終ったところ。
mencoderで、-ovc helpで出てくるlavc - libavcodec codecs - best quality!を信じてずっと
-ovc lavcしてきたけど、ちょっと気になってきたので「How to Use ffmpegX」を参考にしながら-ovc xvid
を某アニメを素材にして実験:
-oac mp3lame -lameopts cbr:br=128 -ovc xvid -sws 2 -xvidencopts fixed_quant=3:max_key_interval=300:vhq=3:max_bframes=1:trellis:cartoon -vop denoise3d -noodml
lavcで使っている1856kb/sより多いんだったら比較する意味ないなぁ。
よ〜く、見たら確かに差が出ているところあったけどもともと気になる部分じゃなかったし。
ということで、同じoptionで、但し、fixed_quant=だけ、3.5および4にして、実験。
mencoderのoptionを最近いじってみて一週間ほど様子を見たけど、なんとなく変わったような気もするしという感じでよく分からないので、時間がかかることはあきらめて、とあるアニメ30分番組全部に対してencodeして目視確認してみる。vbitrate=1792とvqscale=5の比較。
後者は2796kb/s使っているだけあって奇麗だった。
vqscale=6との比較。
1965kb/sということもあってやっぱり奇麗だった。
vqscale=7との比較。
1536kb/sだったけど、それほど差を感じなかった。
全部を通して見た訳ではないのだが。
mount_msdosしたままUSB cableを抜いてしまった。
おかげで、もう一度抜き差ししてもdevd的にはdevdの再起動とかしても認識しなくなってしまった。
あきらめて別のPCにつないで読み出す。
問題のPCは今やっている作業が終ったら再起動かな。
mencoder -vf hqdn3d=4:3:6」だけでしばらく様子を見てみた。
確かに「面」は奇麗になった気がするが、輪郭線のジャギーが目立つようになった気がする。
いわゆる高周波成分に対してはよろしくないということだろうか。
そもそも輪郭線が無い実写に関しては非常によい感じなのだが。
さて、どうするかな。
mencoder -vf pp=md,hqdn3d=4:3:6」を始めていくつかの録画分を見たけど、うーむ。
確かに、なんかnon-interlaceな感じだったのが無くなったけど、ちょっとなんか輪郭が丸い感じになって、どうも、ぼやけた感じ。
もちろんbitrateをあげたらなんとかなるのかもしれないけど、それじゃぁ割が合わないし。
block noiseが出ないのはいいのだが。
「-vf hqdn3d=4:3:6」だけにしてしばらく様子を見てみるか。
mencoderのfilter設定をいじりたくなってちょっとGoogle空間をさまよって見たところ「How to Use ffmpegX」がなんかいい感じ。
これを参考にちょっと実験。-vf filmdint=io=2997:2396」を試してみた。
GV-MVP/IDVから来たDVのencoding中に「@@@@@@@@ Bottom-first field??? @@@@@@@@」とか何度か出るので気にはなっていたんだけど案の定なんか動きがぎこちなくなってしまった。
念のためということで「-vf filmdint=io=2997:2997」も
試してみたけど、ちょっとましになっただけで元より悪化。
やっぱり30→24fps変換は以前も-ofpsとかで試したけど、うまくいかんな。
-vf hqdn3d=4:3:6」を追加して実験。
普段使っているoptionでvbitrateを8192という大きな値で
実験したところ、7778kb/s→5247kb/sになった。
見た目も変化なし。
なかなかいい感じ。
-vf pp=md」に挑戦。
これで7778kb/s→5657kb/sとなった。
これも見た目も変化なし。
なかなかいい感じ。
-vf pp=md,hqdn3d=4:3:6」したところ3810kb/sで十分だった。
見た目も大丈夫。
vqscale=というので指定できるらしい。
普段使っているoptionと上の2つのoptionを加えてvbitrateを外して、vqscaleの値を色々いじって某アニメのopeningで実験。
video streamのbitrateは次の通り。vqscale=5.5で実験したが1437kb/sになった。
実際、vqscale=6で出来たファイルとcmpしたら全く同じだった。
ということで小数は駄目なようだ。
cmpしてみると…なんか違うらしい。
vqscale=6での目視ではよく分からなかったんだけど。
で、vpass=1を外してvqscale=5にすると…
あれ？6270kb/sも必要らしい。
うーむ。
例が悪いのかな。
vqscale=5については、
現状、番組毎に結構細かくbitrateをmanualで指定している状況なので、どう対応したらいいかすぐにはよく分からんので、まずは「-vf pp=md,hqdn3d=4:3:6」を1st PCの方だけ追加してみる。
これで、しばらく様子見かな。
rtprioでどれくらい頑張れるか実験。fwcontrol -R dv」として、DVをどんどん取ってみる。
この状態で「dd if=/dev/zero of=x bs=8m」とかすると…
予定通り(?)「(134 blocks padded)」とかでて、kernelの方も「fwohci0: IR DMA overrun (0x40008011)」と主張した。
psでfwcontrolのPIDを調べて「rtprio 31 -66415」としてみる。
ドキドキ。
ps -ao pid,state,rtprio,command」すると66415 S+ real:92 fwcontrol -R dvと出た。
dd if=/dev/zero of=x bs=8m」すると…
やっぱり「(114 blocks padded)」とか出て、kernelも「kernel: fwohci0: IR DMA overrun (0x40008011)」と主張した。
ダメか。
どうも、そういう問題じゃないのかなぁ。
本ページの主張等は著者の所属組織に全く関係なく、個人としてのものです。