ESP @Wiki

T-TOP

最終更新：2006年07月23日 22:53

匿名ユーザー

- view

メンバー限定登録/ログイン

x264のリビジョン 2006/07/23

私のソフトのリリースに関してですが、基本的に内部修正や大きな変更があった際に、アップするようにしています。ですが、実世界として、x264の改良が進んでいるわけで、これの扱いをどうするかですよ。

エンコード速度が速くなったというような改良であっても、実際に動作検証をしてみないことには、本当に安定して動くのかどうか疑わしく、そこが障害になって、なかなかx264のリリースだけに合わせたリリースがしにくい状況にあります。

実際に非公開版では、最新のx264でリビルドしたもので、エンコードしています。slightly faster とか言われたら、使わなくてはーーー、ってのりなんですけど、公開となるとよく調べないと。ちょっと速いだけでも、大歓迎なんですけどね、ただまれにバグがあるときがあるので。

っていうか、ただ単に私が怠け者なだけなのですが。

仕上げの機能 2006/07/16 その２

Windowsビルドで、fps表示と残り時間表示を付け加えました。どちらも、sleep関数とスレッドと使う超アバウトな設計なので、厳密な領域では誤差がすんごいあると思いますが、ないよりましということで目安、あくまで目安として表示するようにしてみました。

うごかした 2006/07/16

Windowsビルドが開発マシン以外でも動きました。問題はマニフェスト関連で、mfcやcrtのマニフェスト関連のDLLがシステムに存在しない場合に、きちんとアプリケーションが起動しないようです。

かといって、ネットで指摘されている、マニフェストを生成しないオプションを利用すると、アプリケーションの初期化に失敗して起動しなくなってしまうという問題がありましたので、結局パッケージ構成を見直し、dllを含めることによって、動作するようにしました。ついでに、スタティックライブラリ群も全て再ビルドして、なるべく文字コードやマニフェスト関連のビルドオプションをそろえました。

結果として、開発環境がないマシン上でも起動するようになりました。

いろいろとご迷惑をおかけしました。

うごかん 2006/07/04

先ほど、Ｄ様からご指摘があり、Windowsバージョンが起動しないという問題が発生するとういうことで、調査したところ、、、

起動しなかった。orz

原因は不明で、手当たり次第にググってみましたが、いい情報は得られず。すみません、修正には１週間から、１ヶ月ほどかかると思います。まとまった時間がないと対応が難しいです。

正直、なんでだろうーーー、状態です。コンパイラや、本体以外のライブラリ等のコンパイル方法も変えて試してみなければ、というのと、.NETが悪さをしているのかも、という情報もあったりと、やばいです。

VisualStudioをインストールして、再コンパイルすると動くと思うんですけどね。それって、問題解決になってませんね。

久しぶりのアップ 2006/07/02

WindowsのGUI環境をアップしました。出し惜しんでいたわけではなく、たんに私がずぼらだっただけです、はい。内容物に、コンパイル等で必要となるライブラリなどもありますので、その為にも利用できます。

特にlibavcodecは、VisualStudioでコンパイルすることが、超大変なので、その為に悩んだりする、無駄なロスタイムを省くことができるのではないかと思います。

また、Windowsバージョンでは、libx264のリビジョンを533へ更新しています。実は、52x番台では、ソフトが落ちるという問題があったために、今までリンクを控えていました。

プロジェクトの方は、かなり実用的なレベルに達していますので、開発そのものがほぼストップしています。

なんかイノベーションがないとなーー、、、

インターレース３ 2006/06/12

ここ数日観察した結論としては、キャプチャしたアニメに限っては、あえてインターレースを解除してエンコードしないで、再生時にインターレース解除をしたほうが、はっきりいって綺麗だという結論に達しました。

優れたプラグインは再生時に利用しよう。って感じです。

インターレース２　2006/06/11

昨日の続きなのですが、'いぬかみ' ってただのインターレースのようです。

つまり、libavcodecのデインターレーシング機能がしょぼいだけなのですね。いや、しょぼいっていっちゃわるいんだけど、スクロール時にぼろぼろになったり、アニメ特有のエッジというか、輪郭がギザギザになってしまったりしますね。わかってはいたことですが、、、

ただ、VLCの実行時デインターレーシングを用いれば綺麗になるのかも。ってことで、個人的にエンコードするときは、アニメに限りデインターレーシングをしないことにしようかな。

この、on/offによって、fpsハンドル動作には影響を与えないから、まあ副作用はないでしょう。

インターレース 2006/06/10

最近、TV東京で水曜の深夜にやっている、いぬかみ　をキャプチャして、それをエンコードしているのですが、元ソースがプログレッシブでも、キャプチャするとフレーム属性が基本的にインターレースになっちゃうんですよね。

ってことは、自動処理をしている現在の状況はまずいわけで、on/offスイッチをつけなくては。Windowsバージョンにはついては特に。

x264のリリースを追って 2006/05/21

ありゃ、気づけばなんだか久しぶりの書き込み。その間、プログラム本体には全く手を加えていません。シンクロナイズの問題が山場でしたので、他にできることがほとんどないのですよ。

で、今日は久しぶりにx264の最新リビジョンとリンクさせてビルドしたのですが、何故かプログラムの実行途中で落ちるようになってしまっていました。

これは、Windowsバージョンだけなのですが。って、もちろん非公開ビルドです。なぜだかようわからないところでクラッシュするからこまったもんですよ。

今後について 2006/05/07

今後、実際の生活で忙しくなりそうでして、開発のペースが大きく遅れてきそうです。ですが、解消しなければならない問題は、ほぼ解決できたので、まあよしと、個人的に思っております。

今度は、作る側から使う側になって、問題が生じるようならその都度対応していこうと思います。できましたら、皆様のご意見をいただけると嬉しいです。

WindowsGUI あげいん　2006/05/06

'EsperanceXP Light'　と命名して、WindowsGUIバージョンを公開しました。ファイルをWindowへドラッグ＆ドロップして、次にボタンをポチっと押すとエンコードが開始される、シンプルな機能しか実装していません。

日本語がパス上にあるとうまく動かないと思います。きっと、たぶん、ぜったい。怖くて試していません。

と、無責任なことはできないと思って、ちょうど今試したところ、うまく動いてくれました。これはこれで恐ろしいね。

WindowsGUI 2006/05/05

昨日から、WindowsGUIバージョンに取り組んでいます。なかなか楽しくもしんどい作業ですが、大まかな枠組みが固まりつつあります。

概要
- MFCを用いたダイアログスタイルのネイティブアプリケーション
- インプットファイルはドロップ&ドラッグで指定する
- エンコードにはスレッドを使い、ボタンで中断ができる仕様
- クオリティはプリセットから選択 (予定)
- プログレスバーで進行状況を表示する (予定)

と、こんな感じでほぼ出来上がっています。が、これからテレビで亀田兄弟のボクシングと富豪刑事デラックス、とテレビ三昧なので公開は明日かも。

まとめのエンコード 2006/05/05

今日は、まとめとして最高画質で本番エンコードをしてみました。Pen4 2.66GHzのマシンで、２時間ものを12時間かけてエンコードしました。

subpixel_refine = 7
crf = 18
high profile

結果、サイズ720x480ですが平均ビットレートは1.31Mbpsでした。印象としては、ずば抜けて高画質。ただ、輝度勾配が小さなところでちょっとチカチカしてしまうことがあります。

まあ、よくここまできたもんだと。プログレッシブ素材でしたが、映像と音声のズレはまったくありませんでした。エンコード中もときどき監視していましたが、ずれても徐々に修正していく様子が見れたり〜、感動でした。

ゴールデンウィーク 2006/05/04

有り余っている時間を使ってこんなことやっています。本気のWindowsプログラミングは初なので、超苦戦しています。ほんとに、超、超、ちょう、、、

めも: CButton *pBtn = (CButton *)GetDlgItem(IDC_BUTTON);

シンボルサイズ　2006/05/04

今日はライブラリを最新のものへ更新しようと思っていろいろやっているんですが、ffmpegで特に有効な方法として、--disable-debugというオプションがあります。これによって、にゃんとファイルサイズが２分の１に圧縮できました。

というわけで、今度からMacOSXバージョンでは、CUIバージョンとGUIバージョンを１ファイルに含めて配布しようと思います。

やりました 2006/05/03 - 6

音ズレ解消。やっとここまできました。まあ手持ちの素材を３つ試しただけですが、とりあえず少しのイレギュラーにも対応できるものができあがったのではないかと思います。

今度は、スタートタイムを考慮した書き出しを実装しようと思います。まだ若干ずれているような気がしますので。

今回でとりあえず、だんだんずれるという、たちの悪い問題が解消できたと思います。

以下はプログレッシブ素材の扱いに関する簡単なまとめ。２つの方法が必要

フレーム長の和、これは packet.durationの和と、実際にMP4ファイルに書き出したフレーム長の和、これは 3003と4505のフレーム長平均、3754に補正して書き出したものの和、この２者の差が780以上になったら、書き出しフレーム長3754を変化させて対応する。ズレる原因は、プログレッシブとインターレースの検出ルーチンの限界によるもの。つまり私の未熟さから。っていうか、世の中にはプログレッシブだけど、29.97fpsのものが存在しますし、30fpsのものも存在します。ゲームのプロモーションとかそうなんですよ。
実際のビデオタイムスタンプと書き出しデータとの差もとり、この２者の差を一定に保つようにする。大体、cur_dtsとかは17000ぐらいからはじまるので、この差以下になるということは、つまりフレーム長が実際より長く書き出され、音声が先にくるようにズレる原因となる。また、cur_dtsが突然リセットされる素材があるから油断できない。

One last time 2006/05/03 - 5

さてーーー、トライの2of3まで終了しました。２戦全勝です。あと一つ○車男を残すのみになりました。もう、いろいろ試したので、もともと汚かったソースコードがさらにぐっちゃぐちゃになりました。

ですが

これさえ成功すれば、、、　結果は１１時頃に判明予定です。ちなみに、240x144とか96x64とか超ミニサイズにしてエンコードしています。これぐらいだと H.264のリアルタイムエンコードができますよ。

うぐぐぐｇ 2006/05/03 - 4

先ほど、タイムスタンプがと言いましたが、どうやらそんなに易しいものではなかったようです。

なんとタイムスタンプが突然０に近い値に戻ることがあるようです。int64_t型だからそんなことはないはずと思っていましたが、リセットされるようです。どこかで。

でもまあ、前パケットDTSとの差をとって、一定以上の開きがあればごにょごにょっと、うまくできるのではと、また頭を使っています。

ぐぐぐ 2006/05/03 -3

なんか結果が、14秒もずれた。なんでだろ〜、ってデータを見てると、どうやら元データのタイムスタンプが壊れているパケットがあるみたい。そのところで、アルゴリズムが暴走してずれまくってしまったみたい。

で、例外データをハンドルするルーチンも追加して再試行中。

２つの〜 2006/05/03 -2

２つの機構で音ズレを解消しようと、早速実装を変更し、エンコードした結果

修正前の結果

Track # 1 Info - TrackID 1 - TimeScale 90000 - Duration 00:30:12.231
Media Info: Language "und" - Type "vide" - Sub Type "avc1" - 43461 samples

修正後の結果

Track # 1 Info - TrackID 1 - TimeScale 90000 - Duration 00:30:12.102
Media Info: Language "und" - Type "vide" - Sub Type "avc1" - 43461 samples

なんというか微妙な差ですが、ズレの違和感が解消されているのではないかと思います。

で、今から２時間もの素材を２つ試し、どうなるかを調べたいと思います。どきどき、、、

またこなかったーー 2006/05/03 - 1

昨日変更した方法でエンコードをしてみたんですが、またずれました。が、デバッグ情報から有意義なものが。

とりあえずエンコードの後半で、リアルタイムスタンプを書き出しタイムスタンプが大きく上回り、その結果映像と音がずれてしまうようです。つまり、以下の２点を考慮すればずれなくなるのでは。

24FPSプログレッシブでスムージング3754フレーム長の和と、frame_durationの和同士の差を一定以上ずれないようにする
current_dtsと書き出しフレーム長の差も、ずれるようなら補正をかけるようにする

これでよいのでは、、、
今度こそ、、、

こなかったーーー 2006/05/02

というわけで、最後のテストでこけました。ずれたよ。凹んでいます。

なんというか、もっと簡単な方法でもいいのかも、と思っています。ただ単に、frame_durationの和と、アウトプットに書き出した和の差が、一定以上にならないように、適時調整するような方法にするので良いのかと。

キターーーーー 2006/04/30

久しぶりにきました。どうやら出来たみたいです。○車男でもまったくずれませんでした。最後の砦の'7'(日本語で、いち、にー、さん、、、)で試してみて大丈夫そうだったら、大丈夫なのでしょう。

この悪夢のような戦いは、いずれドキュメントとして残そうと考えています。

先行公開として、実装リビジョンの91をアップします。ただちに、、、

試行その？？？ 2006/04/30

というわけで、ソースコードでいうところのFFMPEGDecoderモジュールでフレーム長ハンドルとシンクロナイズ操作をするように実装を変更しました。で、何をどうすればいいのか考えた結果が次の通り。

もともとオリジナルのストリーム中でも、映像と音声のタイムスタンプはことなる。もしも、オリジナルに忠実なフレーム長で書き込んだら、結果として出来たものは、映像と音がずれないと仮定。VFRでは、オリジナルの情報をねじ曲げて、一定長のフレーム長にそろえる。つまり、ズレる可能性があるのはここの部分。

で、いろいろはしょって書くと、オリジナルの映像DTSと音声DTSの差(通常０ではない)と、MP4ファイルに実際に書き込んだ結果の映像DTSと音声DTSの差を見張る。その差どうしの値が、ある一定以上ずれたら、すなわち本当に映像と音声が、ある一定以上ずれたら、映像フレーム長を3754としていたところを、数百フレームを使ってズレを修正するようにします。

泥臭く書くと、3754-25=3729フレーム長を150回繰り返します。で、どうなるかというと、ほぼ映像１フレーム分のズレが修正されます。

忘れてはいけないのは、オリジナルのストリーム以上にずらさないので、副作用がない、、、、はずです。

現在動作検証中で、とりあえず例によって○○○をねらえ２！の第５話で試したところ完璧、ばっちりでした。今は、○車男で検証、というかエンコード中です。

改造方針 2006/04/28

ちょっと、プログラムの実装というか設計を変更しようかなと思います。今まで、制御エンジンのところで、フレーム長のハンドリングを行っていましたが、こんどからデコーダでタイムスタンプ等を見張るように設計変更をしようと思っています。

こうなりゃ意地なんですけどね。

迷走 2006/04/27

うーん、やっぱり何故音と映像がずれてしまうのかよく分かりません。わかりません、わかりません。

もしかして、音も若干ずれるのか？だからその影響でビデオフレーム長のハンドルが正しくても、結果としてずれちゃうの？

って感じで、何がどうダメなのかわからないから、ダメという最悪な状況に陥っています。はーーー、、、

技術的な話 2006/04/22

そもそもフレーム長とはなにか。映像の場合、それはパラパラ漫画としての画像フレームを表示している時間である。一般的に、TVキャプチャボード等で録画したもののフレーム長は、ほぼ１００％固定で、その値は3003である。これは、１秒を90000タイムスケールとした場合で、つまり１枚あたりの表示時間は、およそ0.033秒であり、それを約３０回繰り返すと１秒になる。これが、30FPS。全てがこうならなんの問題もない。ところがだ、、、

今私が問題としていることは、フレーム長がまばらなプログレッシブ素材である。説明困難なほど厄介。主にフレーム長3003と4505を繰り返す。パラパラ漫画でめくるスピードが異なると違和感があると思うが、それと同じで特にスクロールシーンで動きが荒くなってしまう。普通のエンコーダは恐らく関知しないであろう。が、妥協出来ない私はそれを何とかしようとしている。つまりパラパラ漫画のめくるスピードを一定に調節しようと。

これは、3003と4505の平均値3754で書き込めば実現できる。が、実際問題そんなに簡単な問題ではない。ムービーのタイムスタンプを表すDTSの変動値は、憎らしくも3001や4503とずれることがある。というかむしろほとんどずれる。この問題に対しては、3003-3001=2の変化値を3754に適用する、つまり3754-2=3752。

これで完璧なはず。が、これでもずれることもある。何故、Why???　気づいた１つの問題がベースフレーム長の値、実は3754よりも3753がベースになっていることがあるようだ。

結局なにを言いたいのかというと、愚痴が言いたかっただけです。すみません。何回も何日もトライして、それでも考えてアタックして、でもダメだと正直凹みます。

近況報告 2006/04/22

シンクロナイザー、結局今のところうまくいっていません。rev.89で試した結果、うまくいくのとうまくいかないのが存在していました。オリジナル素材の情報にのっとって制御しているはずなのですが、なんでずれるんでしょう。

まいっています。

今後の予定としては、とりあえずrev.89のバグを修正したバージョンをrev.90として公開し、シンクロナイザーの改良は非公開で進めていこうと思っています。

ふーーー

Synchronizer??? 2006/04/19

よく考えると、3754(後に3753と判明 orz)からずれた値、例えば3001の長さなら、3003-3001=2　このズレを適時3753に反映させて(3751になる)書き込んだらいいんじゃない、と思ったわけで、早速昨日・今日と改良をしていました。

で、結果として、できました。まだ○○○をねらえ２！の第５話でしか試していませんが、確かにずれなくなりました。っていうか、感動もの。現在〜〜で検証中(2時間素材)。

フライング気味ですが、revision89をアップしました。新しい、フレーム長ハンドリングメカニズムが有効になっています。

昨日、１・２週間かかりますとか書いておきながら、見込みが甘いなーーワダスは、、、

Synchronizer 2006/04/18

自前のシンクロナイザーを実装することに決めました。根本的に規格通りの素材というものは無い、という結論にたどり着き、こうなったら自分でなんとかするしかないと思いました。つまり、あっちに合わせるとそっちでズレるし、そっちに合わせるとこっちでズレるし、という感じで、根本的な問題解決にはこれしかないと思いました。

以前の実装では、DTSベースといっていましたが、実はフレームDurationベースで実装してました。VRF素材のDTSは3003と4505を繰り返すのではなく、3001とか4503とか、この２つの値のなかでもズレがあることがあるのです。

と言い切りたいけど、たった今気づいたんですよ orz

で、結論としてフレームの加算DTS(=PTS)と24fpsのフレーム長3754の和、この２つの値の差が大きくなるにつれて、3754の値を変化させ、徐々に正しいPTSへ補正する、という手法で解決しようと思っています。１フレームで補正するのではなく、あくまで適応型の徐々に補正が目標です。

デバッグ等の時間を考慮すると、あと１・２週間ほど時間が必要だと考えています。

ちょっと撃沈 2006/04/17

VFR素材、つまり24fpsのプログレッシブ素材ですが、ちょっと撃沈気味です。あれがよいと、これがだめ、、、という具合に問題ありです。

今日とかは時間がないのであれですが、シンクロナイズ機構を導入するしかないみたいです。

mplayer のビルド 2006/04/16

ちょっと暇だったので、mplayerのCVSをビルドしてみました。

、、、MP4(H.264 + AAC) HighProfileが再生できる。っていうかできてる。私が以前に使っていたビルドがやばかっただけなのね。20050123とかいってるし。最新のバージョンでは問題なく再生されるねーーー。Sample Aspect Ratioもきちんとハンドルされるし。

Quicktime どうしましょ。なんか、だめだめになってきたな。コーデックは標準技術を用いるくせに、独自コンテナのMOVにこだわりすぎて、他のコンテナのサポートが中途半端になってる気がします。

ちなみに、altivec関係のオプションでエラーがでまくりましたが、各MakefileのCFLAGSにオプション' -faltivec と -maltivec'を追加してあげればコンパイルできましたよ。

近況報告 2006/04/16

最近プログラミングの山場はちょっと越えた感じで、以下のようなことをやっています。

可変長フレーム素材のエンコードテスト
ソースコードの見た目の修正 (タブとかコメントとか)
WindowsGUIプログラミング方法の勉強
How to Use ffmpegxメモでお勉強

で、特に重要なのが可変長フレーム素材のテストで、音がずれるのを防ぐ機構を導入するのでなく、根本的・仕様的にずれるのを防ぐように改良をしています。といっても、小数の値をいじって、後はエンコードが終わるのをひたすら待ってるだけなんですけどね。

って書いてる今もまっています。素材は、8-1です。答えが答えになります。

ズレ情報 2006/04/11

正確にはこれだけずれました。２時間で、0.5secのズレで、明らかに違和感があるレベルですね。フル24fps(23.97かも)で、固定フレーム長モード、フレーム長3754で出力した結果です。なんというか、フレーム長を3753.???に調整すれば直りそう。電卓、電卓

追記:
23.976fpsぐらいになるそうです。で、電卓で計算すると、3753.7〜3753.75ぐらいのレンジでフレーム長をなんとかすれば、精度の高い結果がでるような気がします。ちなみに、90000÷3753.7とかで計算します。

一回無駄にエンコードして、実際に何fpsになるのか測定すれば一発だけどね。この間の結果取り忘れてさ、しかもずれて、やるきが〜

* Movie Info *
        Timescale 90000 - Duration 01:53:58.987
        Fragmented File no - 2 track(s)
        File Brand mp42 - version 0

File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: High Quality Audio Profile @ Level 2 (0x0f)
No streams included in root OD

Track # 1 Info - TrackID 1 - TimeScale 90000 - Duration 01:53:58.987
Media Info: Language "und" - Type "vide" - Sub Type "avc1" - 163964 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 854 x 480
Self-synchronized

Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 01:53:58.402
Media Info: Language "und" - Type "soun" - Sub Type "mp4a" - 320551 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40 
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

ちょっとまとめ 2006/04/10

ずれるね　2006/04/09

だめだ、はじめて２時間もの24fpsプログレッシブ素材をエンコードしたけど、２時間後に約0.5秒ほどずれてる。ふー、3754固定フレーム長で出力してるけど、これじゃだめなのか。

解決策として、ストリームの情報にべったり依存型のルーチンで処理、つまりモード１を使うしか、他のエンコーダが備えるシンクロルーチンを実装するか。後者は無理だ。

奥深いね。この分野って。

VLCとQuicktime 　その２　2006/04/09

VLCの色彩補正ですが、Windowsバージョンのみ補正されるみたいです。つまりMacバージョンはQuicktimeと同等の品質。たぶんそういう仕組みでできているのかな？

で、なんかWindowsバージョンを見ているとQuicktimeの無力さが、、、っていうかWinバージョンのQuicktimeでは、B-FrameありのMPEG4ストリームの再生がうまくできないんですけど、、、orz

というわけで、最近のリビジョンでは極力B-Frameなしで出力するような設定にしてあります。でも、VLCではきちんと再生されるんですよね。はぁー、どうしたものか。

VLCとQuicktime 2006/04/08

知ってる方は気づいているかもしれませんが、VLCとQuicktimeで再生したときに明らかな彩度や輝度の違いを感じませんか？VLCで再生すると異様に濃い色になりまたちょっと明るくなったような。本来その色が正しいのでしょうが、Quicktimeでは補正していないようですよね。

っていうことで、rev.86では補正の度合いを弱めました。VLCで再生すると２重補正になってしまいますから。にしても、ある特定のプレイヤーに合わせないような出力というか工夫って大変ですね。

interlaced_frame 2006/04/07

avcodec.hのAVFrameのメンバに、interlaced_frameなる怪しいパラメータがあったんだけど、それってデコードした結果がインターレースされているかどうかっていうのを表してくれているみたい。っていうことで、制御方式を変更して、VFR Detectルーチンとインターレース検出ルーチンを分離。気分的にすっきりした動作をするように改造しました。

でも、B-Frameを使っているときだと、VFRとCFRの境界でやばいかもって思うけど、まあ大丈夫でしょう。

OFF-TOPIC 2006/04/03

Quicktimeやなんでもいいから、マックのライン入力の音声を録音できるソフトが欲しいっす。ちょっと見あたらない。作りたいが、、、無理っぽい。うーん。

ちなみにコマンドラインで動くやつです。cronにまかせて定期的に録音したいっす。

アスペクト比 2006/04/02

場合によっては大問題。先ほどVLCプレイヤーで、私のソフトが吐くムービーを再生したところ、めちゃくちゃ横に長くなって再生される。どうやらQuicktimeは、H.264ストリームのsar_width、sar_heightをハンドルできず、リサイズすることでしか元の画像比を表現できず、逆にVLCはこの情報をうまくハンドルできるため、再生時に更にリサイズして横長とかになってしまうようです。なにせ出力形式が標準MPEG4で、QuicktimeのMOVコンテナではありませんので。っていうかQuicktime中途半端すぎ。

ということは、x264のアスペクト比を常に1:1にして、必ずリサイズすることで、QuicktimeとVLC両対応のムービーが作成されるようです。つまり、今まで作ったムービーは、、、

手許で1:1で試したら、VLCでもうまくいきました。rev.85からそういたします。すみませんです。いつもながら。

ビルド 2006/04/02

が面倒になってきました。なにせ、3OSバージョンをビルドするのは半端なく時間がかかります。しかもWindowsマシンとLinuxマシンは同一で、デュアルブートではなく、HDD切り替えということをやっています。rev.83で全部ビルドしましたが、結局半日ぐらいかかりました。なんとかならないものかな？

という愚痴でした。実験的にMacOSX CUIで輝度・彩度補正機能を実装しました。

彩度アップ 2006/04/01

できました。エイプリルフールじゃなくマジでできました。みなさまありがとうございました。画像全体が色的にちょっと明るくなりました。輝度アップのように白くなるのではなく。まあ問題として、現在彩度の値の範囲を0〜255で扱っていますが、実際どのくらい補正すればよいのかわかっていません。画像をアップできればよいのですが、それはまた今度で。

感覚的に、、、例えば彩度を１画素あたり10アップさせると、ほとんど見た目に反映されないほどですが、明るくなったような感じを受けます。というか、色が生きているような感じになります。個人的なスタンスではこのような、ほとんど行っているんだかどうだか解らないけど、感覚的に補正されているような加減がよいのではないかと思います。

次のバージョンでは、これを扱えるようにしたいなと考えています。リリースはいつになることやらですが、、、

結論 2006/03/31 深夜

もがいてもダメだ。知識不足でうまくコントロールできない。で、avcodec.hをあさっていたところ、CODEC_ID_RAWVIDEOとPIX_FMT_RGB24を組み合わせて、一度libavcodecでエンコードして、RGBデータを得ることができるのかもと思えてきた。まあ今日はタイムオーバーですが。

ギブアップ

だめでした。YUVからRGBへの変換式というのだけでも相当な奥深さがあって、３・４時間ぐらいでよいしょっ、とできるようなものではありませんでした。最終的にこのページで挫折しました。他にもここも参考にしましたが、ダメでした。

どうだめだったかというと、頑張ってlibavcodecが出力するYUV情報をRGBに変換してしても、値が0〜255の範囲内に収まってくれないのです。いろいろな変換式を試したのですが、だめでした。

そうしてくれないと後の方の変換で、望みの変換がきちんとできない(彩度アップ)のです。ちょっと実現するには時間がなさすぎます。やばい、、、

ちょっと話がそれ、、、はしないのですが、このページをみると、いかにYUV420プランナーがよわっちいか解ります。こんなの見たらなんとかして補正したくなります。それが人間、、、

だれかなんとしてくれーーー、って心境です。なのでこういう変換をプラグインという形で実現している、Aviutilが素晴らしいわけで、プラグインか、、、

ちょっと考えていました。４月から社会人ですので、これまでのようなハイペースの改良はほぼ不可能です。だから丸投げるってわけでもないのですが、デコード結果YUVからlibx264へのプランナーへコピーする直前に、理論上はプラグインの使用が可能なはずなんですよね。とにかく今このエンコーダに関しての気持ちの整理がついておらず、時間もないという状況で、とほほです。

RGB → HSB変換だそうです 2006/03/31

めっちゃ数学だそうです。まあすでに、YUV → RGBが数学ですので、想像通りですね。計算式的に負荷は軽いんでしょう。ちょっとトライ。

何故こんなにこだわるのかというと、デインターレーシングすると彩度が落ちたり、テレビをキャプチャしたものも、通常輝度や彩度が落ちたりしますので補正したいのです。

ちょっとまった。そういえばプランナーがYUV420だった。１画素あたりの正確なデータってどうやってとるんだ？なんか複雑になりそう。やなかんじ〜、、、

彩度 2006/03/30 pm 10:08

彩度を上げる方法を探し始めました。簡単かもしれませんが、今日はこれからおでかけなので、また明日もがきます。さっきY(輝度)成分だけ上昇させたら、、、、明るくなりました　笑)

見栄えが違う 2006/03/30

なんというか、Windowsビルドでエンコード試していますが、どうも画像が崩れているところとかあるみたいです。というか、Macでエンコードした結果に比べて明らかにおかしいところがあるみたいです。まあ、まだ不安定ですが、MacOS CUIやLinuxでも動く同じコードで試しているので、怪しいですね。

特にSSE系のコードが怪しさ満点。もうちょっと観察してみます。っていうかコンパイルの時に一カ所消したところあるからそのせいかも。

と思ったら、速攻で作った簡易エンコーダの方は画像が乱れていない。っていうことはどういうこっちゃ。

追記

やっぱり初期値の設定していないパラメータが悪さをしていたみたい。関連する全ての値をセットしたら直りました。っていうことで、MacOSXバージョンと内部的には同じ機能を実現しています。まだ実行時に画質の設定とかはできませんが、MacOSXが起動したときの設定と全く同じ出力結果が得られるようになりました。

こんなんなりました 2006/03/29

できました。Windows build。とりあえず感動。なによりそのスピードに。はやっ！！　マイマックと比べるとウサギとカメみたいな差が。ぐあーーー、できちまった。こうなったら、GUI作るしかねーじゃん

Windows build 3 2006/03/29

MinGWをいれてコンパイルの問題は解決しました。avcodec.dll, avformat.dll, avutil.dllのバージョン0.49をゲット、というか苦労の末生成。

いましがたリンクして動作確認したけど、きちんとVC++とリンクできて正常動作。ってことで、現在のソースコードに手を加えずにコンパイルできるはず。理論上は、、、むふふ

Windows build 2 2006/03/29

Windowsビルドは、昨日発見したdllのおかげでかなり光明が差してきましたが、このavcodec.dllのバージョンが0.48 orz

あー、構造体とか宣言不一致でエラーでまくり。おまけにav_picture_allocとかav_seekとかないし、極めつけは av_read_frameが無い!!!

おわった。半日で完成させる野望が。特にav_read_frameが無いのは致命的。デコードの実装が一気に複雑になるから、こりゃ痛い。あーどうしよ。

Windows build 2006/03/28

Windowsビルドは、なんか無理っぽいです。技術的にではなく、気合い的に無理そうです。Visual Studio 2005のVC++でコンパイルして、libx264、libfaac、libmp4v2といったエンコードステージに関係するライブラリのコンパイルはできたのですが、ffmpegライブラリのコンパイルが、、、

エラー７５００個

あー無理無理。MSコンパイラと相性悪すぎ、あのコードは。で、デコードに関する全てが、ぽっかり抜け落ちてしまったわけで、デコード出来なきゃエンコードもできないっすよ。あはは。まあYUVファイル経由では可能ですが、HDD壊れるだけですし。

実は以前に、mpeg2decでもプログラミングしたことがあるので、プログラムストームから音声無しのMP4の出力だけは技術的に可能なんですよ。さてどうしたものか、、、

ちなみに以前、Cygwinでビルドしたとこがありましたが、コンパイルは全て通って、いざ実行ってところで、落ちました。あれは、落ち方的に見込み無しですね。

エンコードソフト 2006/03/28

最近やっとこ、MPEG4エンコード対応製品もH.264のサポートをしているみたいですが、なんであんなに高いんだろう。国産のマイナーなソフトは１０万円近くするし、はっきり言ってそんな価値があるんだろうか？

分散エンコードとかを装備しているならまだしも、、、

デブロッキングループフィルタ 2006/03/27

そういえば、プログラムで手の届いていない放置気味のロジックとして、x.264のデブロッキングフィルタの設定があったなー、と思いalphaもbetaも0ならループフィルタフィルタを切るようなコードに変更したところ、出力結果が悲惨なものになってしまいました。

そうか、このループフィルタがONになっているだけで相当な画質の向上があるのですね。っていうことで、今後常にループフィルタはONにしておきましょう。

そういえば、本家のx.264でGUIフロントエンドがついたり、YUV4MPEG2とのコンビネーションが可能となったりとかがあるみたいですね。まあ、私のソフトの存在意義が無くなってしまうようなものではないけど、最近いろいろなもんがでてきていますねー。

このEsperanceは、MacOSXに、これはという決め手がなかったので作った物ですから、いいものがでてきたら私自身が乗り移ってしまうかも。多分、Handbrakeがmpeg2をエンコード出来たら作らなかったでしょう。ですが、この制作の体験は素晴らしいものでしたから、なんらかの方法で伝えていきたいなと思っている、今日この頃でした。

個人的に、サスペンド機能がストライクしています。おーーーパワーが溢れてるみたいな〜。

LPCM Decoding 2006/03/26

できたー。結局libfaacのエンコード時のインプットサンプルを常に2048になるように内部機構を調整したらうまくエンコード出来るようになった。現在、感動しながら動作検証中。

副作用がありませんように、、、

FAAC FIFO 2006/03/26

LPCM関係の話。よく観察してみると、LPCMの場合だけ、FAACのmax input samplesを下回っていることが判明。mp2、ac3、waveのいずれも上回ってて、FIFOが機能してうまくいっているのかも。

雑音とかエンコード結果から推測すると、2048のつもりで、1004サンプルをエンコードしているのでは。つまり、足りない分が雑音として補完されているんかな？

ってかんがえると、FIFOの実装を変更すれば直るかも。試す価値ありだね〜

LPCM Decoding 2006/03/24

ffmpeg.cを改造して、EsperanceがはくLPCMのデコード結果と比較をしてみた。結果、同じ情報を出力していることが判明。

つまり、エンコードでこけてる。明日もっと突き詰めて解析し、なんとかしようと考え中。

QP?B-Frame?PowerPC? 2006/03/16

最近このＱＰってなんなのかわからなくなってきている。エンコードした結果のクオリティなのか、はたまたエンコードしたときに用いたメソッドレベルなのか。複雑な処理のうち有効になったもののレベルがＱＰなんだろうか？

まあそれはいいや。問題は、QP=20のフレームが出てきたときに、854x480のサイズでエンコードしていると、B-Frameなんか使ってられないってことがよくわかった。とてもPowerPCG4 1.33GHzのマシンじゃ再生できない。

それこそ、Syncフラグをかまって、すべてI-Frameであるかのようなムービーを書き込んで、駒落ちしても再生がとまらないようにしないと、落ち着いて視聴ができない。

このH.264って規格は、ブルーレイが普及しだした頃に威力を発揮するんだろうな。つまり今はまだ先駆け。一般の人に認知が始まりつつある段階。

まとめると、どうしても高画質に保存したいものは、ターゲットQPを低く設定して、B-Frame抜きでエンコードしましょう。ってことです。

最近のターゲットは、さいかの

とんだリビジョン x264 2006/03/15

というわけで、昨日vbvモード(CRF)のときに、ビットレートがぶっ飛ぶと書きましたが、やはりsvnのログからrev.464以降のリビジョンから飛ぶことが判明いたしました。

rev.464LOG:macroblock-level ratecontrol: improved vbv strictness, and improved quality when using vbv.

とあります。実際試した結果、rev.463まででは問題がでなかったです。動き予測に新機能が加わった rev.457、エンコード速度がおよそ１％程向上するrev.463が利用できるといいなと思われ、そのバージョンをアップしましょう。

っていうか、このrev.464以降の問題はどうすれば解決できるんだ？パラメータかな？

最近のリビジョンのx264

とリンクすると、とりあえずビットレートがぶっ飛ぶ問題が発生する。rev.451と同じ設定でエンコードした場合、rev.467では4Mbpsにもなってしまう。どうして？

なにやら、動き予測方式を動的に切り替えるオートモードが搭載されている、最近のリビジョンを試したいだけに残念。明日あたりローラー作戦でいってみようかな。

LPCM?

とりあえず、音のズレとかは無事に落ち着くところにきました。

いま、音声形式LPCMのデコードではまっています。LPCMはDVDに利用される形式で、何がPCMと異なるのかという根本的なことをわかっておらず、またなぜエンコードに失敗するのか原因がわからず、こまっちまってます。

だいたいさ、PCMなんだからデコードもくそも無いと思うんだけど、これがまたそううまくいかないんだよね。2008サンプルが１単位らしく、デコードすると941サンプルになる。っていうかこの場合のデコードってなにやってるの？　で、いろいろ検証してみたりするんだけど、どうやってもうまくエンコードできない。デコード関数呼ばないで、memcpyでコピーだけしても同じ問題が発生するし。

はぁ〜。音声の長さが約２倍になるのよね。うーむ。

Esperance rev.?? - 2006/3/11

微調整の結果

映像:Duration 00:27:09.565
音声:Duration 00:27:09.408

となりました。え！、ずれてるじゃん、って思われるかもしれませんが、実際の音声は、もうちょびっと長いはずなんですよ。つまり、どんぴしゃ。映像と音声のズレが全く感じられないレベルのものができました。

方法としては、3753:3752=1:1の頻度。つまり、3752.5として書き込みました。まあ、これは素材ピンポイントな設定ですので、他のプログレッシブ素材に対してうまくいくのかは不明です。

っていうことで、これから第１話と第３話で、また検証してみます。

Esperance rev.?? - 2006/3/11

rev.75の結果

映像:Duration 00:27:10.211
音声:Duration 00:27:09.408

新しい方法と、フレーム長3754を組み合わせた結果、、、ずれた。最近このズレに関して神経質にやっているから、0.1secのズレでも敏感に反応できるのですが、この0.8secのズレは問題外でしょう。

で昨晩遅く、また考えました。お酒が抜けきらない頭で電卓を使って。その結果、3752フレーム長をメインに使い、一定回数使ったら、3753フレーム長を入れてあげれば良いと。で、そのアルゴリズムで立ち向かった結果。

映像：Duration 00:27:09.436
音声：Duration 00:27:09.408

めでたく、ほぼズレのない結果ができました。現在、音声のフラッシュが甘いので、実際には音声は、あと0.2秒ほどのびる可能性があります。つまり、ちょびっとだけ音声が早いのです。

もともと、3752:3753=5:1　の頻度で登場させたので、これを 3:1とかにして再テスト。ブランチを見ながら、いざ、、、

Esperance rev.75 - 2006/3/10

○○○をねらえ！２　第2話を固定24fpsでエンコードしてみたその後

わかりました。なんでずれたか。最初の18フレームはインターレースで、その後プログレッシブ。Movieなんちゃらチャートで確認しても、プログレッシブがずーっと続いていて、僕のソフトのバグなんだと思ったがしかし、最後の最後が再度インターレースになっていることが判明。そこで、24fpsを適用していたので、映像の長さと音声の長さが2秒ほどずれてしまったのね。

っていうことで、rev.75では根本的にデコード結果を見直し、インターレースとプログレッシブを判定することによって、自動的にフレーム長を切替える方式に変更しました。

これは、６フレームをひとまとまりにして、その6フレームで長さの変化が起こってなければインターレース。3003→4505に変化していればプログレッシブと判定します。ちなみに、この６フレームの途中で発見された場合も、すぐにプログレッシブモードへ移行します。

Esperance rev.74 - 2006/3/9

○○○をねらえ！２　第2話を固定24fpsでエンコードしてみた

先ほど実装した、固定24fps機能をもちいてエンコードしてみた。結果、映像と音がだんだんずれていく最悪な結果に終わった。うーん、先日オリジナル素材の情報に忠実なモードでエンコードしたときのfpsが、24.04と表示されていて気になっていたんだけど、やっぱりね。つまり、プログレッシブ24fpsの素材であっても、ちょっとずれるだろうね。あーどうしよ、もっと根本的な、例えばエンコードを行う前に、最適なフレーム長を計算するような仕組みが必要になるんだろうね。ってことで、次の目標はこれですね。とりあえずどれだけずれたかの情報。

* Movie Info *
       Timescale 90000 - Duration 00:27:12.125
       Fragmented File no - 2 track(s)
       File Brand mp42 - version 0

File has root IOD
Scene PL 0xff - Graphics PL 0xff - OD PL 0xff
Visual PL: AVC/H264 Profile (0x15)
Audio PL: High Quality Audio Profile @ Level 2 (0x0f)
No streams included in root OD

Track # 1 Info - TrackID 1 - TimeScale 90000 - Duration  00:27:12.125
Media Info: Language "und" - Type "vide" - Sub Type "avc1" - 39171 samples
MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21
AVC/H264 Video - Visual Size 854 x 480
Self-synchronized

Track # 2 Info - TrackID 2 - TimeScale 48000 - Duration 00:27:09.408
Media Info: Language "und" - Type "soun" - Sub Type "mp4a" - 76379 samples
MPEG-4 Config: Audio Stream - ObjectTypeIndication 0x40
MPEG-4 Audio AAC LC - 2 Channel(s) - SampleRate 48000
Synchronized on stream 1

電卓で計算してみた結果、90000 / 24.04 = 3743.8 このフレーム長でエンコードした場合は、音声とほぼ同じ再生時間の水準になることがわかった。って一回エンコードするのも、もの凄く時間がかかるのに、これはなんとかして、エンコードする前に算出しなくては、、、

Esperance rev.73 - 2006/3/8

○○○をねらえ！２　第１話をエンコードしてみた

この素材、最初の１分は29.97fpsインターレースで、その後24fpsのプログレッシブに変わるという曲者。で、rev.73で実装した自動プログレッシブ検出機能を用いて、不要なデインターレーシングを途中から無効にすることで、画質の低下を防いだ結果を得ることができた。

ここまでは大成功。

Esperance rev.72 - 2006/3/7

○○○をねらえ！２をエンコードしてみた

夜間を利用してエンコードした。B-FrameとB-Adaptiveを有効にして連続エンコードしてみたんだけど、だめだった。

何がだめだったかというと、映像と音がずれる。致命的。この素材、異なるフレーム長が混在していて、さらにB-Frameがあるから並び替える必要があって、うまいことハンドルできていない。救いは、後半になるほどずれていくのではなく、可変長フレームの並び替えのタイミングなどで、ずれているところとずれていないところがある点。早い話、こういう可変長フレームを持つ素材に対しては、Bを使わず、IとPのみでエンコードするべしってかんじ。

解決方法は、今のようなフレーム長(多分DTS)ベースではなく、PTSによってきちんとハンドルしてあげれば解決できると思うけど、改造が大変すぎで、いまのところ無理って感じ。

画質は相変わらず素晴らしく、サイズも854 x 480で27分もあるのに112MBでおさまった。Bがあるので、再生がとてつもなく重いところがある。CRF=23だったか24でエンコードしたので、もっと大きな値を使えば軽いのができるだろう。

追記-午後

Bなし、ディレイ無しで再エンコードしてみたところ、音のズレ等は解消されている。やっぱり、Bと可変長フレームの組み合わせがいけないのね。

っていうか、デインターレースいらない素材みたい。ま、また再エンコードしなくては、、、orz

「T-TOP」をウィキ内検索

ESP @Wiki

記事メニュー

人気記事ランキング

P-MP4V21

最近更新されたページ

人気Wikiランキング

atwikiでよく見られているWikiのランキングです。新しい情報を発見してみよう！

全体ページランキング

最近アクセスの多かったページランキングです。話題のページを見に行こう！

T-TOP

x264のリビジョン 2006/07/23

仕上げの機能 2006/07/16 その２

うごかした 2006/07/16

うごかん 2006/07/04

久しぶりのアップ 2006/07/02

インターレース３ 2006/06/12

インターレース２ 2006/06/11

インターレース 2006/06/10

x264のリリースを追って 2006/05/21

今後について 2006/05/07

WindowsGUI あげいん 2006/05/06

WindowsGUI 2006/05/05

まとめのエンコード 2006/05/05

ゴールデンウィーク 2006/05/04

シンボルサイズ 2006/05/04

やりました 2006/05/03 - 6

One last time 2006/05/03 - 5

うぐぐぐｇ 2006/05/03 - 4

ぐぐぐ 2006/05/03 -3

２つの〜 2006/05/03 -2

またこなかったーー 2006/05/03 - 1

こなかったーーー 2006/05/02

キターーーーー 2006/04/30

試行その？？？ 2006/04/30

改造方針 2006/04/28

迷走 2006/04/27

技術的な話 2006/04/22

近況報告 2006/04/22

Synchronizer??? 2006/04/19

Synchronizer 2006/04/18

ちょっと撃沈 2006/04/17

mplayer のビルド 2006/04/16

近況報告 2006/04/16

最近の本気設定

ズレ情報 2006/04/11

ちょっとまとめ 2006/04/10

ずれるね 2006/04/09

VLCとQuicktime その２ 2006/04/09

VLCとQuicktime 2006/04/08

interlaced_frame 2006/04/07

OFF-TOPIC 2006/04/03

アスペクト比 2006/04/02

ビルド 2006/04/02

彩度アップ 2006/04/01

結論 2006/03/31 深夜

ギブアップ

RGB → HSB変換だそうです 2006/03/31

彩度 2006/03/30 pm 10:08

見栄えが違う 2006/03/30

こんなんなりました 2006/03/29

Windows build 3 2006/03/29

Windows build 2 2006/03/29

Windows build 2006/03/28

エンコードソフト 2006/03/28

デブロッキングループフィルタ 2006/03/27

LPCM Decoding 2006/03/26

FAAC FIFO 2006/03/26

LPCM Decoding 2006/03/24

QP?B-Frame?PowerPC? 2006/03/16

とんだリビジョン x264 2006/03/15

最近のリビジョンのx264

LPCM?

Esperance rev.?? - 2006/3/11

Esperance rev.?? - 2006/3/11

Esperance rev.75 - 2006/3/10

Esperance rev.74 - 2006/3/9

Esperance rev.73 - 2006/3/8

Esperance rev.72 - 2006/3/7

インターレース２　2006/06/11

WindowsGUI あげいん　2006/05/06

シンボルサイズ　2006/05/04

ずれるね　2006/04/09

VLCとQuicktime 　その２　2006/04/09