やっとシークバーの使い方を理解したけどこんな時間だぁ！
三日も掛かったぞ！覚書ページに書き出しは明日！
万が一のためにコッチにバックアップ、以上。
play.py
/usr/share/gst-python/0.10/examples
以下に play.py なんつーファイルがあった。
うおぉ！これは参考になる、コードをパクってもいいのかな？
でもプレイ状態の把握を自力フラグでやっているなぁ。
本家本元が配布しているファイルが…俺の考えた方法はマズいんかい？
まあ完成させて使い込めばわかることだ。
正月からプログラミング
正月からプログラミング。
まあ毎年のことだ。
マジで Linux 版動画プレイヤーを作っている。
以外に再生するだけなら簡単だった。
細かい部分を作っていくと多分…
そんときは又軽量プレイヤーだと言ってごまかしちゃえ！
名前は悩んだけど面倒なので Y901x にする予定。
この名前の著作権を持っている…別に申請はしていないが…
法律上そうなってしまうので使わないのももったいないから。
RealMedia が関係無いので抵抗はあるが今となってはどうでもいいだろう。
てか Cinema じゃどこか他国に同じ名前がありそう。
それではみなさん、サイトの Copyright 書き換えを忘れないように。
さっき覚書全ページ PHP 読み込みに書き換えた、メンドクセ！
まあこうしておけば来年からは１つ書き換えればいいだけだ。
どうがぷれいやー
あけましておめでとうございます。
さて今年は Linux プログラマーとしてバリバリいくぞ！
しかし Ubuntu を本格的に使い始めて一番困ったこと。
動画プレイヤーだ、何故どれも同じ方向なのだ？
どんなファイルでも再生できるなんてどうでもいい。
ぶっちゃけ flv と wmv だけ再生できれば今のエンドユーザーは十分だ。
プラスで H264 以外の形式なんてこの世から抹殺してくれ！
一つ再生したらディレクトリ内の指定拡張子ファイルを勝手に列挙したり。
リストにフォーカスが無くても矢印キーでファイルの切り替えができたり。
そのリストはマウスならシングルクリックで使えたり。
異様にキーボード操作が単純だったりマウスジェスチャで操作できたり。
そんなのが欲しいんだよ、全然無いってどういうことだ。
んーこれは作ってみるしかないかなぁ、需要は少なそうだが。
とりあえず Gnome 標準の Totem コンポーネントが使えればよさそう。
Windows Media Player コントロールみたく使えないのかな？
って考えたので調べてみる。
GStreamer: open source multimedia framework
Totem はコイツのフロントエンドらしい。
扱うソースコードは結構簡単に見つかるけど Python からでは使えないかな？
あえて Python で作りたい、と思ったらこれまた簡単に見つかった。
Python 端末で import pst と打ってみる。
例外にならない、どうやら Ubuntu に最初から入っているようだ。
ちなみに端末にて
$ gst-launch-0.10 playbin uri=file:///home/sasakima-nao/wrc1992.flv
と gst-launch-0.10 へファイルへの URI を引数で渡すだけで再生は可能。
具体的には DirectShow の IVideoWindow みたいなのが出てきて再生できる。
あぁ…セリカ、ギャラン、レガシー、そしてパルサーまで。
この頃の日本車はイケイケだったなぁ、今こうなるなんて誰が予想した？
YouTube – WRC 1992 – Round 1-6
は、どうでよくて。
勉強にもなりそうなのでとりあえず今年はコイツから。
仮想でも WPF は動く
Visual Studio ソリューションツリーの再構築が面倒だ。
久々に HDD を Vista に繋ぎかえて丸ごと DVD-R にコピー。
そういえば、ライセンスについて一応書いておきますが。
Visual Studio は本人が使う範囲なら複数インストールが認められていますので。
しかし Vista の画面はなめらかで綺麗だなぁ…
それでいて CPU 負荷は全然掛かっていないんだよなぁ…
なにより Windows 版の Opera はウソみたいに安定しているなぁ…
やっぱり戻そうかなぁ…
という誘惑を断ち切って Ubuntu + ゲストの XP へ。
コピーしたり ATOK とかの忘れていたアプリのインストール。
せっかくなので CrystalCPUID を機動してみる。
うおー Name String だけホストのまま、扱いはシングルコアになってるぅ！
コレはどういうことだろう？
Super πを使ってみる、Vista で 104 万桁は 41 秒だった。
結果 41 秒だった、何故同じ？
この時の CPU 負荷。
つまり、ゲスト状態での CPU 解析はアテにならないってことなのね。
結局ホスト CPU の性能がそのままということらしい。
はっきりいってホスト化で早くなることよりゲスト化で遅くなるほうが気になる。
まぁこういうことなら全然いけちゃうんではないかと。
問題が出るのは DirectX を使う時…しまった俺は Cinema を作っていたぁ！
あーあ VMR9 が作れない、どうしようコレ。
○onoha は対策しているみたい、やはり勉強しているなぁこの作者さんは。
マジで動画系アプリ作成は止めたほうがよさげ、サポートできん。
そんなことより心配なのは WPF 製の SeeMe のほうだ、動くのか？
結果おそーーーーーーーーーーい！けどなんとか動く。
むしろセレロン M 1.4GB の Dynabook で使うより早いくらいだ。
CPU 負荷はホストと変わらないんだから DirectX のサポートがどうだだけだ。
ということは通常の XP とほとんど変わらないってことみたい。
逆にそういうことなら Atom のミニノートでは絶望的かも。
とりあえず WPF は動くと解った、もう少し凝ると解らないけど。
とはいえこのレベルなら我慢すれば使えるんじゃないか？程度の速度だが。
仮想マシンでの .NET はデスクトップなら使えなくもないということで。