多分間違ってる。 [開発系とか]
libavformatで、DV.movの時間軸解釈がおかしい件のパッチ。
QuickTimeのSequence Grabber APIで生成したmovには、tmcd(タイムコード)トラックが埋め込まれるのだが、libavformatはこのトラックに対応しないのに、トラック情報だけは反映しようとしていた。
=> libavformat/utils.c : update_stream_timings()
この関数でやっていることは、「各トラック情報を元にムービーの時間軸をのばす」というもので、movフォーマットの管理情報を壊す、正しくないやり方になっている。が、2年以上も放置されていることからみて、「誰も気にしてない」(笑)。
せめて解釈しないAVStreamは処理をスキップしろよ・・・
って、ここをいじるとあちこち被害が大きいな・・・。
QuickTimeのSequence Grabber APIで生成したmovには、tmcd(タイムコード)トラックが埋め込まれるのだが、libavformatはこのトラックに対応しないのに、トラック情報だけは反映しようとしていた。
=> libavformat/utils.c : update_stream_timings()
この関数でやっていることは、「各トラック情報を元にムービーの時間軸をのばす」というもので、movフォーマットの管理情報を壊す、正しくないやり方になっている。が、2年以上も放置されていることからみて、「誰も気にしてない」(笑)。
せめて解釈しないAVStreamは処理をスキップしろよ・・・
って、ここをいじるとあちこち被害が大きいな・・・。
ワケ分からん。 [開発系とか]
初対面。 [日記とか]
ん〜。難題山積。 [開発系とか]
今のところ気がついた問題とか列挙。
自分のコード側:
・Layer側がOKでも、View側だけ表示異常になることがある。
・View側でクローズ出来ずハングするケースあり。
・DV.movで、yuv420でない画像(多分411)が返ってきて落ちる。
ライブラリ側:
・mp4とmovとflvは、最近のは割とOK。ニコニコ系はほぼ通る。
・SANYOやCASIOのデジカメの60fpsサンプルムービーで落ちる。
・QTで通るH.264.mov系で画像が出ないものが散見される。
・tsがほぼ全滅。
・vobもほぼ全滅。
・・・圧倒的にダメダメじゃないか・・・ライブラリ側の問題が厳しいな。
tsとvobは・・・libavformat側の問題かな。SimplePlayerで使ってるぼろいパッチを埋め込むか。
DVは・・・420前提じゃダメということ。swscaleのところ復活させるか。
デジカメが生成する60fps.movが通らないのは・・・対処方法あるのか?
後は、libav gitじゃなくてffmpeg gitを試すとか、かな?
全部対処はまず無理なので、どこまで対処するかは適当に考えることにする。
自分のコード側:
・Layer側がOKでも、View側だけ表示異常になることがある。
・View側でクローズ出来ずハングするケースあり。
・DV.movで、yuv420でない画像(多分411)が返ってきて落ちる。
ライブラリ側:
・mp4とmovとflvは、最近のは割とOK。ニコニコ系はほぼ通る。
・SANYOやCASIOのデジカメの60fpsサンプルムービーで落ちる。
・QTで通るH.264.mov系で画像が出ないものが散見される。
・tsがほぼ全滅。
・vobもほぼ全滅。
・・・圧倒的にダメダメじゃないか・・・ライブラリ側の問題が厳しいな。
tsとvobは・・・libavformat側の問題かな。SimplePlayerで使ってるぼろいパッチを埋め込むか。
DVは・・・420前提じゃダメということ。swscaleのところ復活させるか。
デジカメが生成する60fps.movが通らないのは・・・対処方法あるのか?
後は、libav gitじゃなくてffmpeg gitを試すとか、かな?
全部対処はまず無理なので、どこまで対処するかは適当に考えることにする。
NSOpenGLView。 [開発系とか]
10.7.1のNSOpenGLViewはどこかおかしいです。
先日の記事の続き。
//
とりあえず、LAVPViewのオーバーヘッドを取り除くことに成功。10.6.8環境下なら、LAVPLayerとLAVPViewのCPU使用率は同等に出来ました。
LAVPLayerと同様、FBOに描いてからRectを表示する方式に書換え、CVDisplayLink割り込み時に強制表示(-setNeedsDisplay:ではなく、-displayを使う)とすることで、改善をはかりました。(github)
//
・・・しかし、10.7.1ではLAVPViewのCPU負荷がやはり高いです。先日よりはマシになりましたが。
CVDisplayLink、CIContext、CVPixelBuffer辺りの動作は同一に出来たので、この状態で10.7ではCPU使用率に差が生まれる、ということは・・・。
おそらく、NSOpenGLViewにオーバーヘッドがある、ということになるでしょうか。
自分のコード側の処理方法が基本同じに出来たので、NVIDIAのドライバの線も、考えづらくなりましたし。
先日の記事の続き。
//
とりあえず、LAVPViewのオーバーヘッドを取り除くことに成功。10.6.8環境下なら、LAVPLayerとLAVPViewのCPU使用率は同等に出来ました。
LAVPLayerと同様、FBOに描いてからRectを表示する方式に書換え、CVDisplayLink割り込み時に強制表示(-setNeedsDisplay:ではなく、-displayを使う)とすることで、改善をはかりました。(github)
//
・・・しかし、10.7.1ではLAVPViewのCPU負荷がやはり高いです。先日よりはマシになりましたが。
CVDisplayLink、CIContext、CVPixelBuffer辺りの動作は同一に出来たので、この状態で10.7ではCPU使用率に差が生まれる、ということは・・・。
おそらく、NSOpenGLViewにオーバーヘッドがある、ということになるでしょうか。
自分のコード側の処理方法が基本同じに出来たので、NVIDIAのドライバの線も、考えづらくなりましたし。
リリース:CoreVF Framework SDK 0.1.9 [-リリース情報-]
GT330Mドライバか? [開発系とか]
サポート終了予定のお知らせ。 [開発系とか]
CoreVFの更新版。 [開発系とか]
開発ネタ。
使おうと思ってくれる人が居るのは、本当にありがたい。
CoreVF Framework 0.1.9のテストビルドを作りました。
・testbuild.dmg (リンク削除)
・Xcode 3.2でビルドし直し。
・SDKを10.5.sdkに更新。
・MacOS X 10.4とPPCサポートのドロップ。
・mcdeintとpostprocについて、libav git-29773へ更新。
・imageunit、postprocの致命的なバグを修正。
バージョンが0.1.9止まりなのは、新機能がないからです(笑)
時間がなくて、手元で十分なテストが出来ていないので、しばらくベータ版扱いとします。安定しているようなら正式リリースとし直します。
使おうと思ってくれる人が居るのは、本当にありがたい。
CoreVF Framework 0.1.9のテストビルドを作りました。
・testbuild.dmg (リンク削除)
・Xcode 3.2でビルドし直し。
・SDKを10.5.sdkに更新。
・MacOS X 10.4とPPCサポートのドロップ。
・mcdeintとpostprocについて、libav git-29773へ更新。
・imageunit、postprocの致命的なバグを修正。
バージョンが0.1.9止まりなのは、新機能がないからです(笑)
時間がなくて、手元で十分なテストが出来ていないので、しばらくベータ版扱いとします。安定しているようなら正式リリースとし直します。





