今は、Mac用AGMPlayerの開発フェーズで、まず、AGM⇔MP4変換用コマンドラインツールを作成しているのだが、普通の変換は可能になったので、追加機能として、映像の拡大・縮小機能も実装しようとしている。作者的には、画像の拡大・縮小を行う自前の処理コードは既に持っている。動画変換時にデコードされた画像をこの処理コードを使って拡大・縮小し、その結果から、新しい動画をエンコードすれば、変換時に映像の拡大・縮小は簡単に行える。実際、Windows版のAGMPlayerやAG-ムービーカッターでは、上記のコードを使って映像の拡大・縮小を行っているのだが、上記のコードは、普通にCPUを使って画像処理を行っているので、CPU負荷が、結構、かかる。通常は、映像の拡大は行われず、縮小が行われるので、エンコード対象映像サイズが小さくなる分、映像を縮小したエンコードの処理時間は、総合的には、短くて済む。実際には、前述の様に、映像の縮小処理にはCPU負荷がかかっているので、何とか出来るものなら、したい所な訳だ。Xには、GPUに処理を行わせる画像処理ライブラリがあるので、作者的には、それを使ってみようか、としている訳なのだが、GPUに処理を行わせる場合、画像データをGPUに転送し、処理結果をCPUメモリ空間に再度転送する必要がある。CPUでは、GPUはCPUに内蔵されていて、GPUはメモリをCPUと共有している。CPU⇔GPUでのデータ転送は大して問題にはならないかもしれないので、そうなれば、画像の拡大・縮小処理なんてのは、GPUが得意とする処理なので、今時、CPUでやらせるのは時代遅れかもしれない。Xで使える画像処理ライブラリを使った映像の拡大・縮小処理を追加しようとしているのだが、その処理性能を見る為に、前述の自前CPUルーチンを使った場合との比較も行ってみるつもりだ。Xの場合、APIが目的志向になっているとは思えない訳だ。Xでは、ある体系として纏められたライブラリにある使えそうな機能を幾つか組み合わせ、やりたい処理を実現させる、みたいな感じにならざるを得ない訳だ。みたいな疑問符を付けつつ、提示されている事も多い。XのAPI体系というのは、何を基準に定められ、誰が使う事を想定しているのか、についても、作者的には、不明だ。判り辛く、使い辛い、という点を除けば、それなりの機能は存在しているかもしれないし、とりあえず、使えるモノはこれだけなので、使ってみるしかない訳だ。Adsense)サービスを利用しています。使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。パートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。