あと、彼が言っている"1080p24 encoder 1 set to 3 is not helping you. Stick it on 2 and try it."というのはソッコー試しましたがこれは・・・無いです(笑)
今のままのパラメータで問題ないと思いますが、この部分に関しては、ひょっとすると彼はこのエンコーダーセッティングを使われるのがイヤなのかな？と勘ぐりました。もしくは"with Driftwood Tune" がイヤなのかな？^^；
raitankさん
お疲れ様です^^
とうとう"Also use streameye to check your macroblocking”と言われてしまいましたね^^;
まさかあのバカ高いソフトを買おうとはさすがに思いませんが（これ仕事じゃないし^^;）、またハードル上げられました。
近々お試し版でもDLしてみますか・・・誰か持ってる方はいらっしゃいませんか？(笑)
Forum
▶ トピック一覧は こちらをクリック してください。
ようこそ ゲスト
Show/Hide Headerようこそゲストさん。このフォーラムに投稿するには ユーザ登録が必要です。
フォーラム » Raitank Forum » フォーラム » GH2 カスタムファームのお勉強
投稿： 591
Permalink
on: November 18, 2011, 02:19
bkmcwdさん、お疲れさまです。
先ほど、InterBEE 二日目から戻りまして、今、ちょうど Vimeoからbkmcwdさんのテストデータをダウンロード中だったのですが…(笑)
バッファ分析までやらねばなりませんか！ やっぱ目視ではダメ、と？ あらまー！！ (ﾟДﾟ;)
本当にご苦労様でございます。。。 <(_ _)>
投稿： 1798
Permalink
on: November 18, 2011, 03:06
raitankさん
お疲れ様です(^^)
要はどんな時にもビットレートを無駄に使うなということなんだと思うんですが、本能のテスターがまさかこんなことさせられるとは…f^_^;)
十分キレイで普通に使えればええやん！とは思いますが、でも他にやる人いないんで、私がやるしかないですね。
勢いであの高いソフトを買うハメになりそうなのが少し恐いです（笑）
投稿： 1798
Permalink
on: November 18, 2011, 10:04
raitankさん
仕方ないので例のソフトのお試し版をDLしてdriftwoodと同じテストをしてみました。
そしたら・・・なんか自分の予想した通りの結果で、問題がない様に思えて早速driftwoodに質問しました。
http://personal-view.com/talks/discussion/comment/26093#Comment_26093
実はこのチャートの見方がよくわからないんですが(爆)これだけ見るとより高ストレスなときにリミットラインすれすれになってて、低ストレスだと離れているのでこんなもんなんじゃないの？と思うのですが・・・
どなたかここを読んでいる方でこの辺お詳しい方はいらっしゃいませんかねえ？
正直、そもそも門外漢の私だけの頭ではどうにもならない世界ですわorz
投稿： 1798
Permalink
on: November 18, 2011, 12:39
raitankさん、追記(笑)です。
その後driftwoodが丁寧に説明してくれたので、なんとなく見えてきました^^
恐らく他のパッチにもこの傾向があると思いますがとりあえずはしばらくこのQ18だけの話にさせてもらうと、理由はわかりませんが(爆)フレームサイズやビットレートに何も問題がなくてもこのフレームバッファに問題があるとイカンという話ですね^^；
で、確かにこのElecardを使ってストレス量を変えて調べてみると、確かにこのバッファーってやつが落ちてることがあります。
一方でフレームサイズは理想的だったりするんですが・・・
つまり、「もう一つの目」が必要だということなんですね～きっと^^
でもこのElecardって確かdriftwoodが初めて出してきたし、他の人で使ってるのを見たことがないんですけど、これナシでセッティングをつめるにはどうすればいいんでしょうねえ。
もしかしたらその手間を省くために初期にChrisがコレとコレの倍数揃えてとか言ってたのかも。
結局はその「教え」に従わないとダメみたいですけど、それにしてもこのQ18は撮った感じすごくよかったんですけどね～
ところでこのElecardですけど、お試し版を使ってみたら意味はわからない(笑)にせよなんか面白いですよ^^
今まで一番悩んでたのがこのFrame Buffer sizeなんですが、これを使えば悩むことはなくなりそうです。
とりあえずこれのチャート「も」落ちないようにすりゃいいってことでしょうから、ハードルは一つ増えてしまいましたがやってみます。
投稿： 591
Permalink
on: November 19, 2011, 01:28
bkmcwdさん、お疲れさまです。今、driftwoordさんのコメントを読んでみましたが、まず冒頭で、Strayさんと Pappasさんのチャートテストをする際、手を動かしてるどうか（よりストレスをかけているかどうか）は「どーでもいい」と言ってますね？ つまり、bkmcwdさんのパッチの問題は、ストレスがかかった時にどうか？とは関係ない、と。
次いで「せっかく最高ビットレート＝176Mbit に設定してるのに、frame buffer１、２及び HiTop LowTop／bottoms 他の設定が足を引っぱってトータルビットレートが伸び悩んでいるじゃんか」と。
…よく解っていないボクは「ふ〜ん、そうなんだー (ﾟДﾟ)」てなもんですが、ただ、未だにそれの何が問題なのか？がよくわかりません(泣)。
さて、また週末定例の自然塾の撮影で５時起きなので、今日はこの辺で！
投稿： 1798
Permalink
on: November 19, 2011, 14:25
raitankさん
まさにこんな時いろいろ参考意見を聞かせて欲しいんですが、今日も雨の中、山中へ出撃ですよね。お疲れ様です^^
昨日一日テストしまくって何となく見えてきたことは、私のQ18の目的を「driftwoodは誤解している」ということです(笑)
というのは彼のコメントの通りストレスじゃないというのは、「176Mに設定したそのビットレートをできるだけ高く維持できるように」ということ、つまり「Lowlight時にもビットレートが上がるように」という意味じゃないかなと・・・
もちろんこれから聞いてみますが、私が「わざと」いざという時（高ストレス時）以外はビットレートが上がらないようにしているという意図が伝わっていないような気がしてきました^^；
これって実質88Mくらいのセッティングなんですけど、超高ストレス時に止まったりエラーにならないように176Mにしてあるだけなんですよね。
なので、多分フレームサイズが「私にとって」理想的に叩けているということで、このセッティングは「私にとって」実用上問題なく理想的に使えるパッチであるということなんじゃないかと思います。
彼にとってはこれもまた「アウトロー」だと言うのかもしれませんが、元々目的としていることが高ビットレートではないのでこれでいいと思うんですよね。
今までの「アウトロー」と違って実用上問題も出ないですし。
これは今までの流れの中でしかたのないことだとは思います。なぜなら私はStrayに散々「暗いとこでもフレームサイズが小さくならないのが欲しいよ～」と言ってきたわけで、これもその目的で作られたと思われても自然ですよね。
あと、彼が言っている"1080p24 encoder 1 set to 3 is not helping you. Stick it on 2 and try it."というのはソッコー試しましたがこれは・・・無いです(笑)
今のままのパラメータで問題ないと思いますが、この部分に関しては、ひょっとすると彼はこのエンコーダーセッティングを使われるのがイヤなのかな？と勘ぐりました。もしくは"with Driftwood Tune" がイヤなのかな？^^；
貴兄だけでなく是非ここを読んでいる方々にもお願いしたいのですが、私がDriftwood Tuneを施したものと施していないもので、例のグレインの細かさが違うかどうか？を確認して欲しいです。
私のvimeoでもある程度はわかると思いますが、できればご自身で確かめて結果を教えていただければと思います。
もちろんバリバリ主観で構いません(笑)
http://vimeo.com/user8021739/videos
それぞれのパッチの所在については各サンプル動画の説明のところにリンクを貼ってあります^^
投稿： 1798
Permalink
on: November 19, 2011, 22:18
raitankさん
その後気が付いたネタを・・・
今、最近の私のQ18～16までを例のElecardで見てみたんですが、確かにdriftwoodが指摘するようなもったいなさ？はあるのかわからないですが、我ながらその絶妙な塩梅に驚いています(笑)
特にこのバッファーサイズってちょっといじるとすごく変わるのですが、さっき試しに世に出していないQ17でパラメータの倍数を2/100ずつ変えて様子を見てみました。
そしたら前後に0.02ずつずらしたものだと話にならないくらいこのバッファーが低くなってしまうんですが、元々私が決めていた数字にするとガーンとそれが上がるんです。びっくりしました^^;
私の本能も意外といいとこ突いてるじゃん～まあ今聞いてる質問の結果次第では根本的にダメ出しされる可能性はありますが(爆)
・・・ということは、このソフトがあると楽ではあるけど無くてもいいのかなということですね。
それで積極的に推奨されてないのかな？
少なくともStreamparserだけでも結構いけるということがわかりました。
こちらはバッファーとかいう食べて美味いのかもわからないようなものではなく、撮ったそのままのフレームサイズで評価するツールですからわかりやすいです。
そもそも高ストレス時にバッファー使い切るのは当たり前だし、それ以上バッファーがあったらもっとフレームサイズ稼げる（カード速度限界はありますが）んだし、可変ビットレートなんだから低ストレス時にはバッファーもなくても困らないと思うんですけどね～違うんでしょうか？
もしここまで私が書いてることで間違いがあれば誰か指摘してください^^
全てがなんとなく感じたことからの仮説なので(笑)
なんにしてもdriftwoodが私からの質問にどう答えてくれるか楽しみです。
根本的な問題があればChrisが介入してくるでしょうし・・・
投稿： 1798
Permalink
on: November 19, 2011, 23:48
結果・・・driftwoodも「なんも問題ないよ」と言ってくれました～よかった！.｡ﾟ+.(*'ω'*)｡+.ﾟ｡.
やはり「そのビットレート無駄じゃね？」ということだったようで^^;
投稿： 1798
Permalink
on: November 20, 2011, 02:32
raitankさん
お疲れ様です^^
とうとう"Also use streameye to check your macroblocking”と言われてしまいましたね^^;
まさかあのバカ高いソフトを買おうとはさすがに思いませんが（これ仕事じゃないし^^;）、またハードル上げられました。
近々お試し版でもDLしてみますか・・・誰か持ってる方はいらっしゃいませんか？(笑)
ところで私のQ18ですが、ここまでビットレートを下げると長時間録画も可能な「ことがある」みたいですね。流石driftwood、しっかり指摘されました。
今テストしてみたら、ISO800では問題なく4GB超えて録画できましたがISO3200では4GB止まりでした。
http://personal-view.com/talks/discussion/comment/26421#Comment_26421
http://personal-view.com/talks/discussion/comment/26425#Comment_26425
基本4GB以上連続撮影は考えていないので別に気にはしませんが、言い換えるとこのパッチはその程度のビットレートしか普段は叩かないということです。ISO800で約67Mですかね。ISO12800では115M出てますが。あと、ISO3200では88Mでした。
三脚で全く動かない状態でISO800で3GOPのIフレームがここまで大きければ十分と思うのですがどうでしょうか・・・
天気が悪くて例の林の中を上を見上げて歩くテストもできないので正確にはまだわからないのですが、今試作しているQ17は多分クリアできないと思うので、林の中を歩きまくっている私(笑)にとってはこのQ18が最良のパッチということになりつつあります。
「縦」の動きさえ気にしなければ、どうせ録画が止まるわけでもないのでQ16～14の方が暗所でもフレームサイズが大きくなるのは間違いありませんが、私にはそこまで必要ないかも^^;
ただ、いつものカワセミの方もQ14で理想的なフレームサイズを叩いていましたし、使い方次第ということで^^
http://www.youtube.com/watch?v=T5tZ3sFVZg0
↑↑↑
動画の最後にStreamparserもつけてくださってます^^
投稿： 591
Permalink
on: November 21, 2011, 01:49
bkmcwdさん、その後のご連絡が遅くなりました！
最近の bkmcwdさんのテストデータをもう一度、目を皿のようにして見直していたのですが、driftwoord tune のあり／なしによる違い、わかりません。最初は、tune ありの方がノイズがより細かい気がしたのですが、tune のせいというよりも光の当たり方の違いや動きの違いによるものな気がしてきました。
＞ やはり「そのビットレート無駄じゃね？」ということだったようで^^;
で、今回のやり取りを拝見していて感じたのは、bkmcwdさんのパッチが実質 88Mbit程度で稼働するように設定されているのに、天井を176Mbitに… つまり、平均の倍以上の値に設定していることの根拠がわからんのよね？、ということみたいですよね。まぁ普通に考えたら、せいぜい平均の1.5倍（130Mbit 程度）もあれば必要充分なはずですから、そう言われるのもわからないでもありませんが(笑)。
…ただ、ボクはまだ Q18を使い倒していないのでアレですが、ここしばらく入れっぱなし状態で使ってきた Q14のほうが好きかも？です。どこがどうと言えないんですが、う〜ん、そんな気がしています。しばらく今度は Q18を入れっぱなしにして使ってみますね。(^_^)v
投稿： 1798
Permalink
on: November 21, 2011, 09:15
raitankさん
お忙しい中恐縮です^^;
フィードバックをお待ちしておりました^^
例のエンコーダーセッティングに関してdriftwoodからまた宿題を出されたのは報告したとおりですが、彼が私にstreameyeで見てみろというからには、恐らく1GOP向けのセッティングとはまた違うチューニングが必要なのかも？と思っています。
正直肉眼でわかるレベルかはわかりませんが(笑)
確かに実質66～88Mなのになぜ176M？というのはワケワカメですよね。
彼に言われた通りビットレートの無駄のないとこまで下げると多分143M辺りが本来の設定値になると思うんですが、これだと「縦の動き」のときにフレームサイズ圧縮が176Mに比べて激しいので、やはり176Mでなければダメというのが私の考えです。
この一見矛盾している結果は「縦と横とのストレスの度合いの差」が原因ですが、ほんと倍くらいは違うイメージなんですよ。
私が気が付いていないだけかもしれませんが、本家でこのことが話題に上ったことがないみたいなのが不思議です。
特にこの「縦横の差」がある限り、driftwoodのように最大フレームサイズを780kくらいに下げないと圧縮が起きてしまうので、ある意味彼の780kというのはとても合理的なんですが、同じことやってても仕方ないので私はひたすら1Mにこだわって参ります^^
これはChrisやStrayの遺志？を継ぐ・・・みたいな意味もありますし。
多分普通に使えばQ14の方が画質は良いように思いますが、Q18でも十分のようにも思います・・・どっちやねんな(笑)
Q14もバッファーを見てみたらパラメータ倍数を1/100変えたほうがベターという結果が出てますので少し直す可能性はありますので、それまでとりあえずQ18を試してみてください。
本家に報告したとおりISO800ならspannig isuueが起きないくらい中庸なビットレートですから、ちょっと拍子抜けするかもしれません^^
投稿： 12
Permalink
on: November 21, 2011, 23:04
raitankさん、bkmcwdさん、そしてGH2で本日も奮闘している皆様はじめまして！
大変勉強になるフォーラムで、ここ最近ずっと眺めさせて頂いていました。特にsoruさんが撮られたバリの映像は本当に素晴らしく、また映像を撮ってみたいと思うきっかけになるものでした。
自分は今は、カードの性能が少し不安で42Mbitのハックから挑戦しているのですが（raitankさんのブログ記事大変たすかりました！）、今後は色々なパッチに挑戦していきたいと思います。
ゆくゆくは、bkmcwdさんの66Mbitのパッチ使わせていただければと思っています。なかなかまだ分からない事ばかりなのですが、日々精進していこうと思います！
投稿： 1798
Permalink
on: November 21, 2011, 23:54
saitoさん、はじめまして！
soruさんの動画には私も感動しました(^^)
私は作る人なので、raitankさんやsoruさんのような素晴らしい「表現する人」たちに自作のパッチを使っていただくだけで嬉しい限りですが、まだまだわからないことだらけで勉強中の身です。
よろしければ私のパッチを使った感想もまたお聞かせいただければ助かりますf^_^;)
ちなみに件の66Mですが、実質は130Mオーバーのパッチを強引に66Mに見せかけているものなので、安定感にはイマイチ欠けるものになっています。
もし試されるなら、最新の176M,Q18は同程度のビットレートで安定志向ですから、そちらをオススメします。
投稿： 591
Permalink
on: November 22, 2011, 03:23
bkmcwdさん
＞私が気が付いていないだけかもしれませんが、本家でこのことが話題に
＞上ったことがないみたいなのが不思議です。
そうなんですよね。あれだけの人たちが集まっていて、誰もこの縦運動、横運動に関するストレス度合いの違いに言及する人がいない。どうしてなんでしょうね？ …まさか、単純に誰も気づいていない、なんてこと、ないですよね？ (^_^;)
ただ、今回の bkmcwdさんと driftwoordさんのやり取りを横から拝見していて思ったのは、driftwoordさんは単なる GOP１信者というだけではないのだなぁ〜、ちゃんと理論武装もしていれば、各種高額ソフトを使った科学的な検証までバッチリぬかりないんだなぁ〜という事でした(笑)。
つまりは『欧米人ぽいなぁ』って事なんですが、こういうアプローチで世の中が（良くも悪くも）進化してきたのは事実だとして…
でもそれだけじゃ、例えば写真や映像に現れるボケは「排除すべきもの」でしかないワケで、やはりここに日本人的なというか、論理や科学では測れないもっと “本能的な感性” のようなものが働いて初めて、ボケ＝美しい空間表現の一つという価値観が生まれるような気がするんですよね。
そういう意味で、bkmcwdさんにおかれましては、今まで通り本能のおもむくままに頑張って頂きたいな！と。…もっと具体的に言うと、あまり driftwoordさんの宿題等に頭を悩ませなくてもいいんじゃないですか？と(笑)。(^_^)v
投稿： 591
Permalink
on: November 22, 2011, 03:24
Saito さん、ようこそ〜！！
soruさんのバリ映像、いいですよねぇ。soruさんは謙遜魔神なので、褒めると必ず「私なんか！」と返されちゃうんですが、色からフレーミングまでボクも大好きです。
42Mbitパッチから試されているとの事ですが、bkmcwdさんも仰っている通り、最新のパッチが「176Mbit」と謳われていても、平均ビットレートはもっとずっと低いですし、撮影が停まったりカメラが壊れたりすることはまずありませんので(笑)、どうか最新版パッチもトライされてください。
そして、もし宜しければ、soru さんのようにお撮りになったものをご紹介ください。お待ちしております！(^_^)v
投稿： 1798
Permalink
on: November 22, 2011, 09:54
raitankさん
＞まさか、単純に誰も気づいていない、なんてこと、ないですよね？ (^_^;)
Chrisはもちろん、driftwoodは気づいていると思いますが、ほかの人は気づいてないっぽいですよね(笑)
driftwoodはすごいことやってるくせに、ドシロウトでも使えるパッチを目指しているのでこの辺の事情を一々説明していないのではないかと想像しています。
で、driftwoodですが、彼のパッチは私が今まで何度も述べているように超「合理的」です。私も欧米人ぽいなあとずっと感じていますよ(笑)
しかも理論武装ありきではなく、彼は誰よりも多くの「失敗」を経験した上でのものですから説得力が違います。
GH2は今のカード速度では恐らくフレームサイズを800k未満で使うように設計されているのか、結果としてそうなっているのかはわかりませんが、自分で高ビットレートパッチを作っていれば気が付くのが例の「フレームサイズ圧縮」です。
彼はこれにいち早く気が付いて1Mクラスのフレームサイズに見切りをつけました。
恐らく例のバッファーセッティングをつめていくと、そうせざるを得なかったのだと思います。
そして、私が彼に対して書いたコメントの中にも書いたように、彼こそがLowlight時のフレームサイズを最大にすることに成功したということですが、なぜかというと、おそらく影の中でこそ潰れてしまいがちなディティールの再現性を上げるためで、この辺は私やStrayと同じことを志向していたと言えます。
もちろん画質レベルの要求以上に話題性としても明確にイントラパッチを完成させるという目標は持っていたと思いますので、この辺もさすがだなと思いますね。
恐らく1Mのフレームサイズを捨てた時点で、780k辺りでの最高画質を追求していって、これで十分と判断したと思います。
私たちがずっと悩んできた「フレームサイズの謎」ですね^^;
余談ですが、これがあるからこそここを見られているであろうキヤノンがどんなイントラを90Mクラスで載せてくるのかが楽しみなわけです。「たった」90Mでどれだけすごいものになるのか、本職のメーカーの底力が楽しみですね。
まさか女子供向け玩具カメラであるGH2の半分のクオリティなんてことはないでしょうし(笑)
これに対して、私は1Mの方が画質がよくなる可能性があるという仮説の元、フレーム圧縮がギリギリ起こらないポイントを探してきているわけですが、これはGH2の限られたリソースの中で実現するにはかなり無茶な要求であることもわかってきています。
それは彼もわかっているからこそ、早々に1Mに見切りを付けたわけですが・・・ですから、この日本人は何無茶してるのかな？と思っているのではないかと思いますね(笑)
まとめると、彼の初期の3GOPでも超高ストレス時にはフレーム圧縮が起きることを見て、「通常使用時に圧縮されないように」セッティングをつめてきた私と、「絶対に圧縮され得ないサイズまでフレームサイズを落とした」driftwoodとの違いということで、とても興味深いです。
結果的に、私の方がフレームサイズを維持しながらいかに実質ビットレートを下げられるか？の方向になってきたのも、イントラでは逆に実現するのが難しいテーマだからで、結構こういうパッチへのニーズはあると思うのですがdriftwoodの勢いの前に誰も作らなくなってしまったので、しかたなく私が作り続けているという・・・元々例の高額ソフト持ってる人とか協力してくれないですかねえ(笑)
＞あまり driftwoordさんの宿題等に頭を悩ませなくてもいいんじゃないですか？
この宿題の障壁はコトの難易度ではなく、単純に高額ソフトが要ること＝カネの問題だけなのでそんなに悩みはしませんが、これは一回やってみれば済むことのように思うので、お試し版でやってみます。
「本能」は、合理主義者からみたら無茶なセッティングを作っている時点で発揮していますから、これはまた別の話ですねきっと^^;
投稿： 1798
Permalink
on: November 22, 2011, 12:23
余談ですが、イントラは大排気量のアメリカンV8、私のは小排気量のターボに例えるとわかりやすいかも･･･
低速からトルクが盛り上がって、常に燃費が悪い（笑）大排気量V8と、高回転時だけトルクが盛り上がって、低回転時には燃費もそこそこの小排気量ターボというわけです^^
わかりやすくないかな？(笑)
投稿： 12
Permalink
on: November 22, 2011, 23:28
bkmcwdさん
パッチアドバイスどうもありがとうございます。実はパッチの選択には色々悩んでいた部分もありましたので、本当にたすかりました。ありがとうございます！
早速、明日176M,Q18のビットレートを試させて頂こうと思います！
raitankさん
平均ビットレートがずっと低いと聞いて、早速使用させていただく事になりました。
ただ、今まで撮った自分の映像が酷くて、さっき映像でちらつくのが、やっとインターレースのせいだと分かったレベルですので、なかなか皆様の様なハイレベルな映像はアップできないかもしれません...ともあれ懲りずに撮ってみようと思います！
投稿： 1798
Permalink
on: November 23, 2011, 00:28
saitoさん
早速ありがとうございます(^^)
私がセッティングしているのはクリエイティブ動画モードのシネマ動画24Hだけですので、よろしくお願いします。
ビットレートがどれくらいだったかとかでも何でも結構です。感想をお聞かせくださるとありがたいです。
投稿： 173
Permalink
on: November 23, 2011, 00:35
こんばんは、GH2初心者の１－３００と申します。よろしくお願いします。
思うところあって・・・と言うか 気が付いたら 14mmF2.5 付きGH2が MERLIN に乗っかっていたり、14-140mm とかマウントアダプターが足元に転がっていたりして驚いています。
私の機体はまだハッキング前夜という所で、レンズのテストやノーマル状態のフイルムモードの特性をみたりしているところです。
＞影の中でこそ潰れてしまいがちなディティールの再現性を上げるため
＞女子供向け玩具カメラであるGH2
bkmcwdさんのショッキングな発言をタイムリーに読みながら ノーマルGH2 のダイナミックレンジの狭さを目の当たりにして少し落ち込んでいます。
どのフイルムモードをいじっても 7stop 程のレンジしかない感じです。
5DMarkⅡのDレンジをネガに例えると、今のところ GH2のDレンジはポジって感じです。
ハッキングしてグレーディングするともう少しDレンジは広げる事が出来るのでしょうか？
あと もう一つ質問なんですけど とりあえず今は 家にあった133倍(20MB/s)と書かれた１GBの SD Card を使っていますが、ハッキングして使用するには
やはり、サンディスク エクストリーム® プロ™ SDHC™ UHS-Iカード （ UHS規格に対応し、最大95MB/秒の読取り速度と最大90MB/秒の書込み速度を実現した超高速SDHCカード ） の 32GB とかを使われていらっしゃるのでしょうか？
バージョン： 1.0.34 ; 表示するページ： 0.145 秒。