昨日のx265guiEx 3.47の更新を反映。…まあGUI部以外はなるべく同じになるよう書いているので、単にコピペしただけ。
・x264エンコード時にAviutlとx264のCPU使用率を表示。・x264guiEx.iniにopusenc用の設定を追加。
ダウンロード>>ダウンロード (ミラー) >>Skydriveの調子がいまいちの時はミラー(dropbox)からどうぞ。同じものです。x264guiExの導入>
スポンサーサイト
いつもありがたく使わせて頂いております。
ただいま1.75を使用しておりますが、諸事情から.NET Framework 4を
インストールすることができず、2.xx系以降に更新することが出来ておりません。
現状は問題無く利用出来ておりますが、今後の利用に不安を感じております。
大変身勝手なお願いで恐縮ではございますが、年に１回でも良いので、
.NET4のランタイムを入れなくても使える最新版のx264guiExの開発・公開を
ご検討いただくことはできませんでしょうか？
.NET 2.0対応の件ですが、かなり難しいようです…。
かなり長くなりますが、以下に可能かどうか調査した結果を述べさせていただきます。もし、以下のことをご存知であれば申し訳ありません。わたしは寡聞にして存じませんでした…。もし認識違いがあればご指摘ください。
.NET Framework 2.0への変更はVisual Studio 2013においてはプロジェクトファイル(*.vcxproj)の書き換えによって可能であるように見えます。実際、
<TargetFrameworkVersion>v2.0</TargetFrameworkVersion>
とすることにより、GUI上も
.NET Framework 2.0用のプログラム生成を行うように表示されました。
しかし、この状態でコンパイルしても.NET 2.0環境では例外"0x0434f4d"を出すだけで実行できませんでした。(WinXP + .NET 2.0 / Win7 + .NET 3.5 の2環境で確認)
どうやら、Visual Studio 2010以降では.NET 2.0系用の実行ファイルを作成できないようで、Visual Studio 2008 (VC++2008)でのコンパイルが必要のようです。
現在のx264guiExは複数の部分にC++0x/C++11の便利な機能を使用しています。
・autoによる型推論
・範囲ベースfor文
・lambda式
・stdint.h
・unique_ptr
・メンバ初期化子
これらはいずれもVC++2008ではサポートされず、コンパイルを通すことができません。VC++2008で無事コンパイルするには、かなり細かい修正が必要になってしまいそうで、簡単にはできそうにありません。
貴重なお時間をいただきまして誠にありがとうございました。
私は開発に関する知識は無く、適当なことしか申し上げられませんが、
現在windows7上にてx264guiExを利用しておりますので、.NET3.5ならシステムを変更すること無く使うことができ、
.NET3.5自体も比較的最近に出たものなので、.NET4用のプロジェクトをNET3.5用に作り替えるだけならば
最小限の変更で比較的簡単に作れるものなどと考えておりました。
最近のバージョンではx264guiEx_src.7zが同梱されている為、本来ならばユーザー自身でまず試してみるべき所
わざわざご検証までしていただいて誠に恐縮です。
.NETのバージョンのターゲットの変更は容易なことではないということが分かりましたので、しばらく1.75の利用を継続して
また状況に変化が訪れるのを待ちたいと考えております。
重ねて御礼申し上げます。
X264guiExをありがたく使わせていただいております。
X264guiExをは最新のバージョンを自動（auo_setup.exe）で入れて使っています。
既存のチャプター情報があるので、ogg形式で記述したfoo.chapter.txtをソースと同じフォルダに置いて取り込ませています。ソースはDVDだったりプログレッシブ動画だったり様々ですがターゲットは主にMKVです。
そこで質問です。「拡張」パネルに「チャプター位置にキーフレームを設定する（mux有効時）」というのがありますが、これは何をするものでしょうか？（補足）MKVの拡張オプションで「チャプター追加」を選択済み。
というのは、ログの最初に「チャプターファイルから *箇所 キーフレーム設定を行いました。」というコメントが出るので機能していると思いますが、実際にエンコしたものを調べてみると指定時間のフレームがキーフレームになっているわけではなかったからです。AVIUTL上ではMKVのキーフレームの確認ができなかったので他の編集ソフトで調べました。
それから、この機能は自動フィールドシフトと併用できないのでしょうか？aｓｆ使用時には「チャプターファイルから *箇所 キーフレーム設定を行いました。」というコメントがログに出てきませんでした。
＜以下は要望です＞
そもそもソースにチャプター情報が入っているときにはそれを引き継いでくれるとありがたいんですが。。。
情報の引き継ぎと言えば、音声トラックの言語の情報が抜け落ちてしまうんですが、これも何とかなりませんか？
チャプター位置にキーフレームを設定する機能ですが、2.23では正常に動作しておらず、2.24にて修正しました。ご指摘ありがとうございました。
http://rigaya34589.blog135.fc2.com/blog-entry-546.html
>自動フィールドシフトと併用
この機能を使用するには、エンコード
前にキーフレームを挿入するフレーム番号を確定させる必要があります。しかし、自動フィールドシフト使用時には、エンコード中にdropさせるフレームが決定します。キーフレームを挿入するフレーム番号がエンコード前にはわからないため、すみませんがこの機能は使用できません。
>ソースのチャプター情報、音声トラックの言語情報
そうした情報は出力プラグイン(x264guiEx.auo)側にはAviutl本体より一切提供されていません。そのため、申し訳ありませんがそうした機能の追加は困難です。
お忙しいところ対応ありがとうございました。
>自動フィールドシフトと併用 -> できない
残念。。。
>ソースのチャプター情報、音声トラックの言語情報 -> 対応無理
了解です。毎回re-muxで対応します。この辺のことはHandBrakeが対応しているので、AVIUTLで特殊なフィルターを使用するとき以外はHandBrakeでいこうと思います。
キーフレーム検出と設定が自動フィールドシフトと併用できないのは
x264guiExの設定画面のポップアップヘルプに書いてありますし、
AviUtlにはソースファイルのキーフレーム表示機能もありますよ。
>キーフレーム検出と設定が自動フィールドシフトと併用できないのは x264guiExの設定画面のポップアップヘルプに書いてあります。
キーフレームの検出をさせているわけではありません。時間を与えているのでその辺に適当に入れてくれるのかなと思ったりしただけです。
>AviUtlにはソースファイルのキーフレーム表示機能もありますよ。
知っています。正確にキーフレームを表示できるのはAVIだけです。少なくとも私の環境では。
ちゃんと確かめてからコメントしてください。
>正確にキーフレームを表示できるのはAVIだけです。
間違っています。
キーフレームかどうか、正確かどうかはコンテナとは関係ありません。
AVI(ここでは1.0の非Open-DMLについて言及)では、AVIコンテナ内のAVIINDEXENTRYのdwFlagsにAVIIF_KEYFRAMEがセットされて、初めてキーフレームとして認識されます。
従って、AVIコンテナ作成時に、このAVIIF_KEYFRAMEが正しくセットされて無ければ、AVIでもキーフレームかどうか知ることは出来ません。
他のコンテナについても同様です。
また、キーフレームという用語は現在ではいささか曖昧というか時代遅れな定義をとることが多く、処理系によってはそれをキーフレームとはみなさないものもあります。
(例えばH.264/AVCにおけるx264エンコーダのintra-refresh相当の機能でのリカバリの開始点はキーフレームと言えるのか言えないのか。)
なので、正しいのか正しくないのか、一概に言うことはできません。
コンテナは、キーフレームの正確性を決定しません。
AviUtlは入力プラグインに「このフレームはキーフレームです」と説明できる機能を提供しているので、正しくキーフレームが指定されているにも関わらず、キーフレーム情報がAviUtl上で正しく反映されていないのであれば、それは入力プラグイン側の問題です。
>キーフレーム情報がAviUtl上で正しく反映されていないのであれば、それは入力プラグイン側の問題です。
語弊がある言い方をしてしまったことをお詫びします。
AVI以外はDirectShow (Haali splitter + ffdshow)で開かれていたので。。。
ただ、以前にL-SMASH Worksで読み込んでみましたが、MKV (avc) はキーフレームの位置がおかしかったという記憶があり、もう一度現在手に入る最新のL-SMASH Worksを入れてやってみましたが同じでした。MKVやAVIがコンテナであることはもちろん承知しています。ただ、avcのMP4, AVIでは問題ないのにMKVだけおかしいというのは、MKVに依存したL-SMASH Worksのバグなんですかね。
「おかしい」というのは、TMPGENC VMW5やSolveigMM VSBEで調べたものと違うということです（両ソフトでは同じ結果）。AVIUTLでは総フレーム数が少なくなっていたので、これが原因でキーフレームの数が減少したり時間がずれたりしているようです。もちろんソースによって度合いが違いますが。
>現在手に入る最新のL-SMASH Works
何を以って最新とするのかとか、どこから入手したのかとか(以下略)
>MKVに依存したL-SMASH Worksのバグなんですかね。
L-SMASH Worksは使用しているffmpeg/libavのライブラリに強く依存しており、MKVに関しては、L-SMASH Works側では一切 関与しておりません。
従って、ffmpeg/libavが「ここがキーフレームだぜ」って言ってきたら、AviUtl側はそのとおりに受取ります。
なお、MKVにはVfW互換モードという格納方法があって、Bフレームを扱うのにVfW的なズルをすることができるので、このモードが使われていると、表示順序が狂ってキーフレームの指示位置がおかしくなる、ということはありえます。
まぁ、そのファイルがどんなものかは知りませんが、そういう可能性はあります。
自分はそのようなMKVは手元には無いので、これ以上は何も言えませんが。
>何を以って最新とするのかとか、どこから入手したのかとか(以下略)
失礼しました。
http://pop.4-bit.jp/ からr708とr717の２つ落としてきました。
>L-SMASH Worksは使用しているffmpeg/libavのライブラリに強く依存しており、MKVに関しては、L-SMASH Works側では一切 関与しておりません。
従って、ffmpeg/libavが「ここがキーフレームだぜ」って言ってきたら、AviUtl側はそのとおりに受取ります。
なお、MKVにはVfW互換モードという格納方法があって、Bフレームを扱うのにVfW的なズルをすることができるので、このモードが使われていると、表示順序が狂ってキーフレームの指示位置がおかしくなる、ということはありえます。
なるほど。貴重な情報ありがとうございます。
試しに、ビデオだけを抽出したもの (.h264) やMP4Box (0.4.6-rev2698) でコンテナだけMP4に変換したものを調べてみたら、MKVのときとは違った時間になっていて、さらに３つのアプリで時間が揃わないという悲惨な結果でした。ただ、抽出したものとmp4に変換したものは同じでしたが。。。
>自分はそのようなMKVは手元には無いので、これ以上は何も言えませんが。
そうですか。自分がエンコしたもの２つ、他人がエンコしたもの８つの合計10のMKVを調べてみましたが、AVIUTLと他の２つのアプリとの結果が一致していたものは1つしかありませんでした（他の2つのアプリでは同じ結果）。一見同じように見えても微妙に時間がずれていたり、ある時間のところが抜けていたりといった違いがありました。最初と最後の方の数個のキーフレームを見るだけですが。
>失礼しました。
http://pop.4-bit.jp/ からr708とr717の２つ落としてきました。
それなりに古いです(ぁ)
とても最新とは言えません。
>試しに、ビデオだけを抽出したもの (.h264) やMP4Box (0.4.6-rev2698) ～
なんかこれらの説明を見ていると、とってもVFR臭がするのですが、まさかVFRじゃありませんよね？
>キーフレームの検出をさせているわけではありません。
>時間を与えているのでその辺に適当に
>入れてくれるのかなと思ったりしただけです。
「キーフレームの検出と設定」と書いたのは、
「AviUtlのキーフレーム設定検出を行う」
「チャプター位置にキーフレームを設定する(mux有効時)」
の２つの設定を指していました。
後者の話をしていたので、そこのポップアップヘルプに
書いてあるという注意喚起をしただけです。
ポップアップヘルプには大事な手がかりも書かれていますから
設定で抑制してしまわず、なるべく見るようにしたほうが良いと思います。
>他人がエンコした～MKV
報告がバグ修正につながったのは喜ばしいのですが以下略
>それなりに古いです(ぁ)
とても最新とは言えません。
ですから、「現在手に入る最新の・・・」という但し書きをしたのですが。。。
>まさかVFRじゃありませんよね？
MediaInfoで調べた限りではすべてCFRです。
http://pastebin.com/Rd46rRJr
を参考にして、フレームレートの強制指定方法を試してみたところ、ビデオだけを抽出したもの（MP4にコンテナ変換したもの）と同じ時間になりました。しかし、依然として総フレーム数が少ないので、MKVに関して他の2つのアプリで得られた結果とは違います。
