iPhoneでチャプター

コメントでiPhoneでチャプターが反映されないとあったので、iPhoneでチャプターならちょっと変わった方法があるのでご紹介。ただ、残念ながらこの方法では自動フィールドシフトと一緒には使えないのでそこは注意。

ようはL-SMASHのチャプター読み込みを使ってしまおう、ということ。

POP氏のx264 L-SMASH版をダウンロード。そいでchapter.aufでチャプター打ち込み。自動出力にチェック。

それからx264guiExの設定画面で以下のところを変更。

1.「x264.exeの指定」で今ダウンロードしたx264 L-SMASHを指定

2. 「音声先にエンコード」にチェックを入れる

3. 追加コマンドに
--audiofile "%{audpath}" --acodec copy --chapter "%{aviutldir}\chapter.txt"

4. 「外部muxerを使用する」のチェックを外す

5. エンコ開始

これでできたmp4をiPhoneに送ればいいはず。(iTunesではチャプター反映された)

設定ファイルのサンプルをあげておきます。
こちら>>
x264guiEx_stgフォルダに入れて使ってみてください。

iPhone4の技術仕様を参考にmain profile, Level 3.1で作ってあります。4Sならhigh profileが使えますけどね。

x264guiEx 1.13

バグ修正と要望のあった機能の追加

・「このウィンドウ(ログウィンドウ)を最小化で開始」が一回しか効力を発揮せず、解除されてしまう問題を修正。
ご指摘どうもです。

・x264エンコード経過時間表示
ログウィンドウ、ステータスバーに表示

・ツールチップヘルプの抑制
例によってその他の設定から

---

ダウンロード>>

x264guiExの導入>

---

ビットレート計算とkとKとKi

ビットレートは表記の意味によってちょい変わるかもよ、という話。

私みたいにほとんどcrfでばっかエンコする人には関係ないけど、ビットレート指定でエンコする人には重要かもしれない。もっともみんなご存知だとは思うのだが、x264guiEx 1.xxで簡易ビットレート計算機を作ったので念のため。

続きを読む

続きを閉じる

ビットレートってたいていkbps(kb/s, kbit/sec)で表すけど、
PC関連の"k"はクセモノだったりする…という話。
k と K と Ki があって 1000のことだったり、1024のことだったりする。
で、意味を取り違えると、ちょっと計算がずれることになる。

なので実際に計算して調べてみた。
以下でてくるソフトのバージョンを書いとく。
x264 r2085
真空波動研Lite 110813
MediaInfo 0.7.50


x264のログに
encoded xxxx frames, xx.xx fps, xxxx.xx kb/s
って出てくるけど、あの"k"は1000。(つまり 1kb/s = 1000b/s)

ついでに真空波動研のkb/sも同様で、k = 1000。

実際に音声なしのmp4動画を出力してチェックすると、
x264 2012.35 kb/s
真空波動研 2012.35kb/s, 長さ 1:30.023
この時、8bit = 1Byteとともに計算して、

( 2012.35(kb/s) × 90.023(s) ) × 1000(b/kb) / 8(b/B) / 1024 (B/KB) / 1024(MB/KB) = 21.596(MB)

これがファイルサイズ 21.6 MB (22,671,170 バイト) にほぼ一致することから確認できる。(ファイルサイズが計算値よりわずかに大きいのは、mp4コンテナの分だろう)


一方で、Windowsのファイルサイズは
1024 B = 1 KB
1024 KB = 1 MB
1024 MB = 1 GB
1024 GB = 1 TB
こいつのせいで 2TB HDD を買っても Windowsからは 1.82TB あれぇ～みたいなことになる。

ファイルサイズ関連でわざわざ大文字にしてある K は 1000 ではなく 1024 を意味することが多い。

多いってのは違うのもあるってことで、MediaInfoは違う。
ファイルサイズを xx MiBと書いているし、実際に計算してみても

MediaInfo的には
Ki = 1024
K = 1000
の模様。


まあそんな感じで、ビットレートで細かい値を気にするなら、k とか K とか Ki の違いに気をつけましょう。そして特に K は書いた人によって意味が違うかもしれないので注意。


最後に、x264guiExでは簡易ビットレート計算機などもすべてkbps表記にしてあり、k = 1000。ファイルサイズは1MB = 1024KB = 1024×1024Bとして計算しています。特に問題ないはず。

x264guiEx 1.12

相対パス使用時に発生するバグ修正・対策。

・aviutl.exeと同じフォルダにあるx264.exe等実行ファイルを相対パスで指定するとエンコードに失敗するのを修正。

・Windows XPで相対パスを使用すると様々な挙動不審が発生する現象への対策を行った。
.NET のOpenFileDialog/SaveFileDialogで(マネージドコード側の)カレントディレクトリが勝手に変更されることがあるという有名な(?)問題がXPにはあるらしい。Win7ではそんなおかしな事にはならんので、XP(あるいはXP用.NET Framework)のバグっぽい。どういうことだってばよ。とりあえず、回避策を入れといた。

ともかく、tne様、ecoenco様、詳細な報告ありがとうございました。おかげで問題の原因に辿りつけました。

---

ダウンロード>>

x264guiExの導入>

---

x264guiEx 1.11

・x264.exe等実行ファイルの指定などに相対パスを使用できるようにした。
これまでは相対パスだと設定ファイルを閉じるときのファイルチェックでエラーになってしまっていた。

・YC48->YUV444(10bit)にSSE4.1版を追加。SSE2版より少し速い。
　output-csp i444は私も使わないし、使う人もいないだろうと思って放置していたのをとりあえず書いておいた。色変換部分を速くしてもエンコ速度に大きな影響はないけど、わずかでも速いに越したことはないだろう。

---

ダウンロード>>

x264guiExの導入>

---

もうプライマリじゃなくても怖くない QSVEnc 0.02

いろいろやって、QSVEncをIntel 内蔵GPUがプライマリじゃなくても動くようにしてみた。

その前に、Z68で遊んでみたこととか、Intel内蔵GPUを2nd GPUで動かす方法とか。

続きを読む

続きを閉じる

---

Z68にしてみた

---

H61マザーを売って、Z68マザーを買ってみた。
AsRockのZ68M/USB3というやつ。

そいで、内蔵GPU(iGPU)を2ndとして使いたいので、なんか別にグラボが必要。

というわけで、昔使って封印していたGeForce 8600GTを掘り当てて(探しだして)、くっつけてみた。

なので、Sandyマシンはこんなかんじになった。

Win7 x64
Core i5 2500 + Z68 (AsRock Z68M/USB3)
4GB RAM(そのへんにあった2GBx2)
GeForce 8600GT (GDDR3 256MB)
320GB HDD(そのへんにあった外付けから引っペがしたやつ)

8600GTって4年ぐらい前のミドルレンジのはずだから…あ～弱そう。そもそも最近のローエンド以外のGPUにはほとんどある外部電源コネクタがない。最近GPUって性能もどんどん上がったけど、消費電力もどんどん上がったってのを実感する。
とりあえず今は試せればおkとしよう。

---

Intel 内蔵GPUを2nd GPUとして動かす

---

iGPUの電源が落ちてしまうと、当然QSVはどうやっても使用できない(P67の状態)。

裏を返せばiGPUの出力が何かに繋がっていればiGPUの電源を入れておくことができるので、iGPUのアナログVGAをモニタにつないでおく。

一度BIOS(ってかUEFIだっけか)からiGPUをプライマリにして起動して、Intel Graphics Driver 8.15.10.2509を入れ、その後はUEFIからPCI Express(ようはdGPU)をプライマリGPUに設定する。

これで2nd GPUとしてiGPUが動く。

ちなみにうちでは内蔵GPUの出力も8600GTの出力も同じモニタに出力するなんちゃってマルチモニタ。

もちろん、Windowsに入ってからもプライマリGPUは切り替えられる。
デスクトップを右クリック > 画面の解像度から入って「こちらのディスプレイをメインにする」とかすればいい。

---

いろいろいじった感想とか

---

っていうかVirtuの使い所って?
内蔵GPUと外部GPUを両方動かすのが難しいからVirtuが必要なんだと思い込んでたけど、なんか普通にできてしまったのだが…まだよくわかってない。

Z68にしてよかったのは"K"付きじゃなくても4段階OCできたこと。4コアTurboMax 3.4GHzが3.8GHzまであがった。電圧オートだと電圧が自動的に上がって熱くなったんで、UEFIのoffsetという項目で下げて行ってみたが、-0.2Vぐらいしても余裕で動いてる。もっと下げられるかも。

Sandyでは4.5GHz常用って人もいると聞いて驚いてたんだけど、1.03～1.05Vで3.8GHzが動いてるから、もっとしっかリした電源とマザボなら4.5GHz常用も全然いけるんだなと思う。個体差はあるだろうけどSandyすごいなあ。

ところで、最近のGPUってのはアイドル時はちゃんとクロックとか電圧とか自動的に下げてくれるもんだけど、8600GTともなるとそんな機能もなく、アイドル時も全力で回ってた。昔使ってた頃は気付かなかったけど。なんとなくGPU BIOSいじってアイドル時はクロック落とさせた。

もうひとつ。
以前リモートデスクトップするとQSVが使えないって書いたけど、調べるとTrueRemoteだと大丈夫らしいと出てきたのでやってみたら、見事動いた。有線LAN内なのでさくさく動く。無線LANとかネット越しだとどうかわからんけど。

TrueRemoteはWindowsのリモートデスクトップより(主にリモートされる側に)負荷がかかるけど、そんなに大きなもんでもないし、Aeroの半透過もそのままなので嬉しい。Windowsのリモートだと半透過が切られてしまうので、半透明大好き人間としては寂しい物があった。

---

QSVEnc 0.02 スクリーンショット

---

・Aviutl 0.99j + QSVEnc 0.02

・QSV + HW VPP 作動中
・アダプタ 0 (つまりプライマリGPU)として、GeForce 8600GT で NL-Means Lightが動いてる。(8600GTのGPU Loadが90%以上)
・8600GTが残念なため、そこが律速になって、QSVの威力を発揮しきれていない。(CPUやMFX使用率が低い)
みたいなことがわかる。

クリックで拡大


そもそもQSVエンコ時に重いフィルタ処理をするのはQSVの利点を殺してしまうんで現実的でないけれども、こんなことも出来る、という参考程度に。

まあこんな感じで、プライマリじゃない内蔵GPUを使用できるように改良した。
特になんか指定する必要ななく、自動的に検出できる。
※エンコの途中で切り替えないものとする。

---

QSVEnc ダウンロード>>

---

x264guiEx 1.10

・自動マルチパス時に、ステータスファイルを自動で削除するオプションを追加。
設定画面右上、「その他の設定」から。

念のため書いとくと、afsのエラー時自動解除もそうだけど、これらの設定はx264guiEx.confに保存される。(バッチ処理ごとの保存ではない)


・YC48->NV12/NV16/YUV444のSSSE3版/SSE4.1版をいじった。わずかに高速化。

が、(色形式変換とかたいして重くもないのであたりまえだが)エンコ時間に差はほぼない。

---

ダウンロード>>

x264guiExの導入>

---