2005年06月27日
画像認識
NHK映像科学館と言うのが昼前にやっていた。
今日は「人体のしくみ(5) 脳と知覚」の再放送だった。
目から入った情報をどのよう脳で認識しているかというような内容。
かなり面白かった。
CGとか実写映像とかが多くてわかりやすかったし。
そして、一番興味を引かれたのがどのようにして画像を認識しているか？と言うところ。
まだ、完全には解明されていないそうだが、有力なものとして、楕円形などのいくつかの図形パターンに反応する箇所があり、それぞれのところでそのパターンを処理した後に、それを統合して処理すると言うものだった。
なるほどー
脳はすさまじい並列処理をしているので、パターンに分解してから統合し認識しても一瞬で判断できるのだろう。
なら、コンピュータでも、パターンに分割しベイズ理論を使って確率的に判断すれば、かなりの画像識別が出来るかも。と言うか、既にある？
まあ、なんにしても面白そうな分野だ。
投稿者 Takenori : 22:45 | コメント (0) | トラックバック
2005年06月30日
音の視覚化
WBSで音を視覚化する装置を紹介していた。
単なるグラフィカルイコライザーの類かと思いきや、実際の映像に音源の位置と音をオーバーラップして表示する装置だった。
音の大きさによって、オーバーラップされる円の大きさが変わり、周波数によって色が変わるようになっていた。
音が出ている位置に表示されるのが面白い。
技術的にも面白かったが、それよりもその映像が良かった。
サーモグラフィのような視覚効果のように使うと面白いかも。
似たような物として臭いを視覚化するようなエフェクトがあると面白いかも。
音の視覚化は今までなかったもので、映像効果としてもなかったが、ないものを効果として作るのは楽しいかもしれない。
コンピュータ上ではいろいろなことが出来るわけだし。
投稿者 Takenori : 23:20 | コメント (0) | トラックバック
2005年07月05日
1GB！！ Yahoo!フォト/Yahoo!ブリーフケース
Yahoo!フォト/Yahoo!ブリーフケースの容量が最大1GBに!!
見てみたら、本当に1GBになってた。
これはいろいろと入れたい放題だなぁ。
動画とかも気軽に上げられそう。
とりあえずは、ローカルにあるデジカメの写真をバックアップとして上げるぐらいかな？
前使ったとき、1個1個アップロードするのが面倒だったけど、今も同じかなぁ。
エクスプローラーのように気軽にアップロード＆ダウンロードできるツールないかなぁ。
やっぱり1個1個ファイル選択ダイアログでアップロードしないとダメか。
Vectorで探したけど、ツールも見付からなかった。
作るとなると… 少し時間がかかるなぁ。
投稿者 Takenori : 17:07 | コメント (0) | トラックバック
2005年08月06日
シューティングゲーム
シューティングゲームアルゴリズムマニアックス
シューティングもなかなか面白いなぁ。
ただ、自分で作っても自分でクリアできなさそうだけど。
投稿者 Takenori : 14:02 | コメント (0) | トラックバック
2005年08月11日
お盆
さてどうするか。
やりたいことや途中になっていることがいっぱいある。
こつこつやっていかないと。
投稿者 Takenori : 23:14 | コメント (0) | トラックバック
2005年10月24日
O／Rマッピング
xilionでは、データをSQLiteを使って保存している。
が、SQL文を直に書いていくのはすこぶる面倒臭い。
これを何とかできないかと、Templateを使って楽にテーブルに対応したクラスの定義が出来るようにする方法などを考えていたのだが、このようなことを行うものは既に存在していてO／Rマッピングツールと言うそうだ。
これについては@ITのHibernateで理解するO/RマッピングやCastorでオブジェクトをRDBにマッピングが参考になる。
これらの記事で述べられているツールはJAVA用。
C++用のないかな？
また今度探そう。
投稿者 Takenori : 23:05 | コメント (0) | トラックバック
2005年11月06日
Google パーソナライズ
Google パーソナライズを使ってみた。
RSSリーダーなどは少し使っていたが、どうもなじめなかった。
起動待ちやブログはブラウザで読みたいと言ったことが不満だった。
でも、Google パーソナライズはHPなのでいつも通りブラウザで見れる。
いつも読んでいるブログのRSSを登録した。
並び順もD&Dで変更できる。
なかなかいい感じだ。
XOOPSを使って似たようなものを作ろうと思っていたけど、必要ないかも。
ただ、シンプルなGoogleの画面が文字だらけになってしまうので、普段はホームにしておいたほうが良さそうだ。
投稿者 Takenori : 12:47 | コメント (0) | トラックバック
2005年11月15日
教育ピラミッド
多くの技術は他の技術を土台にして作られている。
例えば数学はかなりこの傾向が強い。
四則演算、方程式、微積分…… 以前習ったことを理解していなければ、その次のことを理解するのは難しい。
技術が発達していくと、そこに到達するまでに習わなければならないことは増大していく。
もし、ずっと増大を続けるのであれば、いずれ人生の全てを使っても理解出来ないことが出てきてしまうのではないか？
そこまで行かなくても、習得するのにかなりの時間を要するものになってしまうのではないかと思う。
そして、これを何とかできないかと考える。
私は、理解できている人がいるのなら、私もそれを理解できると考える派だ。
理解できないのは、理解に必要な前提知識が足りないからだ。
それはパズルのピースのようなものだと思う。
ピースが欠けているとパズルは完成しない。
おぼろげながら形はわかったとしても、完全ではない。
ならば、初めから理解に必要なピースが列挙できればどうだろう？
『これを理解するのに前提とする知識一覧』が作れたら。
その一覧をいきなり細かくしすぎたら量が膨大になるのは必至だ。
それを避けるためには階層化する必要があるだろう。
そして、それはピラミッドのようになり、一番下のものはかなり平易なものになる。
もし、このようなピラミッドが構築できたと仮定したら、知りたいものを最短で理解できるのではないだろうか？
すでに理解していることなどがデータベース化されていれば、差分を取って足りないピースが列挙できる。
また、その依存関係などから最短の学習プログラムが組めるのではないだろうか？
このピラミッドの構築するには克服すべき課題が多いかもしれないが、やるだけの価値があるのではないかと思う。
そして、それはまるでゲームのようだ。
誰々は何々を覚えた！
誰々が覚えている技術一覧。
何か楽しくなってこないだろうか？
誰か作ってくれないかなぁ。
投稿者 Takenori : 17:05 | コメント (0) | トラックバック
2005年12月26日
ゲームキャスティング？
RSSの用法を考えながらふと思った。
ゲームやソフトウェアをポッドキャスト出来ないか？ と。
ソフトウェアのアップデート通知はうざい。
現在の機能に特に不満もないのに起動したら、新しいソフトウェアが・・・といちいち教えてくれる。
別にいらないんだよっ！ と思うが、毎度毎度五月蝿いのでやむなくアップデートする。
それでうまく動かなくなったら目も当てられない。
その点自動アップデートは幾分ましだ。
ウィルス駆除ソフトなどは自動的にアップデートを行って、アップデートしましたよと教えてくれる。
手間いらずだ。
ただ、突然アップデートが始まるので時々びっくりする。
なんかハードディスクがガリガリいい始めた。なんだ？と思ったりもする。
それ以外は快適だ。
ソフトウェアのアップデート通知は、こういったことがあるので少々使いづらい。
その点、ネットラジオなどのポッドキャストは使ったことないけど、使いやすそうだ。
新しいものを取り込んでもらっても特に困らない。
音楽は、ソフトウェアと違って単なるデータだからだろうか？
では、ゲームはデータか？
Yesでもあり、Noでもあるが、データとみなせるだろう。
この場合のデータかどうかと言うのは、感じ方によるものだ。
家庭用ゲーム機ではカセットやCD、DVDでゲームを入れ替える。
CDプレイヤーもDVDプレイヤーも似たようなものだ。
データと言う言い方は少し違うかもしれない。
少しの間楽しむもの・・・メディアやコンテンツと言う言い方が近いだろうか？
プログやニュースなどもそのくくりに入るだろう。
まあ、何にしてもそういう傾向をもつものがRSSなどによる配信に向いているのではないかと思う。
では、現実的にゲームをRSSで配信していくことを考えた場合、どのような形態が良いだろうか？
クライアントソフトが必要なことは間違いないが、勝手にインストールされるのは嫌だ。
データ的なものから離れてしまうし、いろいろと問題も発生しそうだ。
家庭用ゲーム機+カセット(DVD)的な構成が良いだろう。
つまり、ゲームのデータと実行エンジンが分離したような形のものが扱いやすい。
では、クライアントソフトは？
実行エンジンとくっついていると感じるものが扱いやすそうだ。
クライアントソフトから適当に選んで起動できるのがいい。(保守の面を考えるとプログラム自体は分離していた方が良さそう)
クライアントソフトを起動したら、新着ソフトや過去にダウンロードしたソフトウェアが一覧表示され、適当なものを選んでプレイする。
遊ばなくなったものは消したり、お気に入りなどを分類できる。
新着ソフトもジャンルごとに分かれている。
お気に入りの続編は新着リストで優先的に表示される。
かなりお手軽ではないだろうか？
ポッドキャストで有料のものはどのような形態なのだろうか？
ググってみたところ、月額料金のものがすぐにヒットする。
月額、ダウンロードごと、広告がすぐに思い付くものだろう。
なんだかかなり可能性が見えてきた気がする。
吉里吉里を実行エンジンとしたクライアントソフトを試作してみるかな。
投稿者 Takenori : 10:29 | コメント (0) | トラックバック
2006年09月18日
忙しいけれど
最近、全然更新していなかった。
かといって、ソフトウェア開発していないわけではなく、詳細などが書けない開発はしている。
それ以外は、ほとんどやっていない状態。
でも、やる時間がまったくないと言うわけではない。
少し前にmixi Alertの機能追加作業をしてみたが、出来なくはないと言う印象。
少しずつ他のも進めて行きたいところ。
まあ、あと数ヶ月でゆとりが出来るはずだけど。
投稿者 Takenori : 12:16 | コメント (0) | トラックバック
2007年07月18日
差分表示をデバッガやエディタに
プログラムに変更を加えた時、その変更による影響範囲についてテストを行うけど、その時変更を加えた箇所付近にブレークポイントを張ることが多い。
だから、デバッガでも差分表示できると便利だと思うんだけど、そういうのってないのかな？
後、エディタでも。
アンドゥ・リドゥではなくて、指定した部分を前に戻したり、前がどうなっていたか見ながら編集したり、バグッた時に怪しい箇所をいつ変えたかを簡単に追えたり。
WinMergeのような感じで編集できるといいんだけど。
エディタ側は探せばありそうな気もするな。
WinMergeやサクラエディタ、Eclipseをカスタマイズしていくって手もあるか。
投稿者 Takenori : 15:33 | コメント (0) | トラックバック
2007年07月19日
テスト
単体・結合試験をしないとどうも不安な今日この頃。
単体試験、結合試験・・・と進めれば品質が高くなるのは間違いない。
コーディングすればミスをするし、考慮が漏れていることも多い。
試験はその実施のみではなく、試験仕様書の作成自体にも不具合発見の効果がある。
試験仕様書を作成する時、仕様書やソースコードなどを見直し取りうる入力、パスを通すための入力、様々な状態などを列挙していく。
この段階で、この状態でこの入力がきたらバグる、そもそもこの入力に対する考慮が漏れているなどが発見される。
考慮漏れと言うものは、ある程度系統立てて検証しないと発見しづらい。
これはソースコード上のバグのみでなく、様々な成果物に対して言える。
最終段階において元となる要件が漏れていれば、かなりの手戻りが発生することがあるのは周知の通りだ。
少し脱線した。その辺りのことは別の機会に書くとしてテストだ。
ある程度の規模を持ったソフトウェアでは、すべてをテストすることは現実的ではない。
よってそこには時間 ( コスト ) による制限が加わる。
当然、その制限内に終わるように計画を立てなければならない。
単体試験では、全パスを通さなければならない。
それは本当なのだろうか？
実際に結合された段階では通りえないパスが存在する。
使われないものをテストする必要はあるのか？
それはないだろう。
しかし、規模が大きくなればなるほど通らないパスを見つけることは困難になる。
また、今回は通らなかったが、将来加えた変更によって通るようになることもある。
そして発見させるのが潜在バグだ。
ゲーム開発において系統立ててテストが行われることは、経験上や見聞きした範囲ではない。
ゲーム開発でのテストは2種類。
動作確認とシステム全体に対するテスト。
単体や結合なんてすっ飛ばして、いきなりシステムテスト ( 総合テスト ) 。
しかも、そのシステムテストはランダムテストだったりする。
これはある意味合理的とも言える。
システムテストでは、通らないパスをテストすることはない。
しかし、システムテストで見付かった不具合を直したら通らなかったパスを通るようになり不具合が顕在化することはよくある。
潜在バグだ。
では、これをどうやって回避するのか？
回帰テストによって回避する。
不具合修正の影響範囲を調べて、その影響範囲を元に試験書を作成。実施するなどと言うまどろっこしいことはしない。
不具合修正したら、動作確認して次のシステムテストのテストサイクルで何とかする。
同じテストを何度も繰り返して不具合が収束するのを待つ。
それがいつ終わるのかはわからないが、その内収束する。
だから大丈夫。(？)
力業ではあるが、合理的とも言える。
システムテストで基本的なことがすべてカバーできているのであれば、最終製品のクオリティーもある程度保障される。
だが少し心もとない。
もう少し改善できないのだろうか？
つづく・・・
投稿者 Takenori : 15:36 | コメント (0) | トラックバック
2007年08月10日
グラフ
マインドマップなどの手法に対して今までどうも懐疑的だった。
なぜか絶賛されればされるほど胡散臭いような。
Vector で Frieve Editor のレビューがあったので見た。
なんかこのソフトは使いやすそうに見えたので、とりあえず使ってみることにした。
初め分類の仕方などよくわからなかったが、ヘルプ自体もこのソフトで作られているので、その構造を見ながらやるとだんだんわかってきた。
なるほどわかりやすい。
まず有向グラフが描きやすい。
ノードのグループ分けがしやすい。
ノードにメモを付けられて、それが後ろにうっすら見えるのが使いやすい。
クラス図や状態遷移図を描いたことがあるのなら、何も言われなくてもどのように使うかはなんとなくわかると思う。
と言うか、私の場合書き方の手法については何も見ていない。
いわゆる我流なのだが、単にノードと関連のあるものをつないでいくだけでわかりやすく整理できる。
しかも、考えやすい。
何かを考える時は、連想ゲームのようにしてAだからB、BだからCかD、Cの場合・・・のように考えるが、これをグラフとして置いておけば、思考の分岐に立ち戻って考えやすい。
いろいろ考えていると、気付いたら全然関係のないこと考えてたりするが、その時も何について考えていたか戻りやすい。と言うか、グラフに描いていたら、それ以外のことはあんまり考えない。
脱線しだしたら、これは後で考えようとかなる。
また、グラフはクラス図に近いので理解しやすい。
各ノードを単純な関連で表しているだけだが、単純な関連ゆえに細かく考えなくていいのでさくさく描ける。
とにかく、何かつながっていると思うからつなげるだけ。
どういう関連かは後で考えればいい。
ただ、クラス図を描いたりする影響か、ああここは継承だなぁと思っても、それを表せないのは少し辛い。
クラス図を描く前に、何がクラスで何がプロパティでなどと考えずに、すべてノードとしてつなげるなどして、クラス図の下書きと言うか、思考の整理段階で使えそうだ。
また、何かを考える時のサポートツールとしても使える。
他に物語も表せそうだ。
大まかなストーリーの流れがあって、それぞれの箇所で詳細が枝分かれするような形で物語が表せそうだ。
このソフトのファイル形式はテキストなので、グラフを他でも使いまわせそうだ。
メモの書き方にルールを設ければ、有向グラフを使うものであれば他用途でも使える。
なんだかいろいろと便利なソフトだな。
関係ないけど、自動スクロールがなんだか気持ちいい。
投稿者 Takenori : 13:13 | コメント (0) | トラックバック
2008年01月14日
引数の個数
初めに引数の個数を強く意識したのは、組み込み開発の時のターゲットとそのコンパイラの仕様からだった。
そのコンパイラでは、正確な個数は覚えていないが確か4個まではレジスタ渡しで、それ以上はスタック渡しとなっていた。
つまり、効率を考え出来るだけ引数は4個以内になるように作っていた。
当然、C++ のクラスのメンバ関数では、暗黙的に this が渡されるので 3個以内にしていた。
※ PCでも、呼び出し規約に __fastcall を使えばレジスタ渡しになりレジスタ渡し出来る個数に上限が発生する。ただ、PCの場合は、__fastcall を使い、引数の個数に気を付けても、効果が上がるほど速くなるかどうかは疑問。
そのターゲットから離れて開発をし始めても、だいたい4個ぐらいを目安にしているが、最近は6個ぐらいを限度として書いている。
なぜかと言えば、個数が増えると見辛くなるから。
では、効率云々ではなく、見易さとして考えた場合は何個ぐらいが妥当なのだろうか？
人が瞬間的に判別できる数は3、4個ぐらいという話がある。
テーブルの上にみかんがあるとして、4個ぐらいまでなら、瞬間的に4個と確かな自信を持って言える。
ただ、5個、6個となってくると少し自信がなくなると言うか、瞬間的に認識できないように思う。
6個ぐらいかな？程度に感じる。
でも、この個数は経験によってある程度増えるような気がする。
瞬間的に確かな自身を持って言える数はあまり変わらないが、たぶん6個とか7個とかいうレベルであれば判別でき、誤りも少ない。
このことから考えると、個数を瞬時に認識できると言う意味では、4個と言う目安は悪くないのではないだろうか。
また、6個ぐらいが限度というのも。
他の切り口で見れば、また個数は変わるだろうけど、私は現状では4個以内を目安にし、6個ぐらいが限度として書くかな。
出来れば、4個以内にしたいが。
投稿者 Takenori : 16:15 | コメント (0) | トラックバック
クラスメンバ渡しと引数渡し
クラスのメンバに値を入れて、メソッドをコールするか、引数にすべて入れて渡すかはよく迷う。
クラス自身の責務に関係している値であれば、メンバに入れるのは気にならないが、一時的なものの場合はメンバとして持たせるのではなく、引数に入れて渡そうとする。
それが、クラス内部のprivateなメソッドで外部から呼べないとしても、そのような形にしがちだ。
そして、よくクラス非依存になり、static メンバでも問題なくなったりする。
なぜそのような作りにするのか？
それは、出来るだけ依存性を少なくしたいからと言うのが大きい。
クラスからも独立して使おうとすれば使えるように。
ただ、そのようなメソッドを他のクラスに持っていって使ったことは記憶している限りない。
つまり、そのようなアプローチはまったく意味なしとも言える。
もうひとつの理由は、マルチスレッドだろう。
クラスのメンバを経由してしまうと、リエントラントではなくなってしまう。
マルチスレッドのことはよく失念してしまって、気付かないうちに値が変わって、なんか動作がおかしい、なぜ？と言うことが良くある。
しっかり意識して書いている時はいいのだが、そうでないときはミスをする。
そのことが頭の片隅にあるため、クラスのメンバに値を入れて受け渡しすると言うのを無意識のうちに避けているのかもしれない。
投稿者 Takenori : 21:44 | コメント (0) | トラックバック
マルチスレッドとアトミック/インターロック
ムービーでは、特に気にせずクリティカルセクションでロックをかけて処理しているが、Windows のクリティカルセクションはかなり遅いらしい。
これはいくつかの文書で見かける。
そして、クリティカルセクションではなく、可能ならインターロック系のメソッドを使うとかなり改善するとも。
インターロック系のメソッドは、InterlockedIncrement や InterlockedDecrement、InterlockedCompareExchange など。
Linux なら、atomic.h の atomic_inc や atomic_dec、atomic_compare_and_swap が該当するもののようだ。
これらは boost の atomic_count_win32.hpp や atomic_count_linux.hpp で使われている。
アトミック/インターロックを使ってプログラムを書く際の触り(？)の部分は、Lock-freeとWait-freeアルゴリズム ( Wikipedia ) に軽く書かれている。
このような方法を使えば、確かにロックせずに動く。
が、ムービーの場合は、処理の単位が大きいので、ロックする方法でもさして問題にはならないような気もする。
まあ、デコーダーの内部処理をマルチスレッド化する際は気にかけた方が良さそうだ。
参考 :
カプコン×インテル。「ロスト プラネット」のマルチスレッド最適化対談
【GDC07】ゲーム開発者はさらなるマルチコア化に備えよ その時の資料 PDF
false sharing の問題 については、OpenMP による共有メモリ並列プログラミング に説明がある。
このようなことを総合すると CUDA や PS3 の SPE のように、コードとデータをパッケージ化して、コアに処理を依頼するような形のプログラミングモデルに向かっているのだろうか？
CUDA で、GPU用に書いたソースコードとCPU用のソースコードが共用できるのであれば、GPU も CPU もわけ隔てなく、空いているコアへ処理を依頼することなども出来そうだが。
投稿者 Takenori : 22:17 | コメント (0) | トラックバック
2008年01月24日
TMPGEncのライセンスとテスト用データ
吉里吉里の掲示板のやり取りで気付いたんだけど、TMPGEnc 3.0 XPress や 4.0 XPress って商用利用不可だったのか。
ただ、「お客様（個人または法人のいずれであるかを問いません）」と記載されているので、「本ソフトウェアを個人利用の範囲で利用する権利」を許諾すると言うところの個人は、法人も含まれると言う解釈かな？
私は思いっきり個人的なエンコードと実験用データの作成に使っているが、何らかの製品に TMPGEnc 3.0 XPress でエンコードしたムービーを入れるのは NG か。
で、TMPGEnc Plus 2.5 には、この個人利用云々の記載はないようなので、何らかの製品に入れるにはこちらを使えってこと？
TMPGEnc無料版 ソフトウェアライセンス規約 や FAQ の TMPGEnc 2.5（無料版）の商用利用は？ にもそのような内容のことが書かれている。
これはまったく気付かなかった。
自分的解釈としては、Visual C++でビルドした実行ファイルは売っちゃダメとか、PhotoShopで描いた絵を売っちゃダメとかそんな印象で、それはないだろうと言うことでさして気にしていなかったのだが、TMPGEnc XPress はダメなようだ。
初音ミクなどのVOCALOID で作られたデータについては、声のデータが最終データに含まれるので、作成データの頒布などに関して制限が加わるのは特に違和感はないのだが、エンコーダーでエンコードしたデータに制限が加わるとは思ってもみなかった。
と言うことで、TMPGEnc XPress で作ったデータの扱いには気を付けましょう。
で、終わるかと思ったんだけど、ライセンス的に変なことに気付いた。
それは、FLV4 出力プラグインの存在。
TMPGEnc 4.0 XPress は、FLV4 出力プラグインがあって、これを使えばニコニコ動画向けの動画を出力できる。
TMPGEnc Movie Plug-in FLV4 ページ には、アップロードに便利的なことが書かれている。
でも、ちょっと待って欲しい。
ニコニコ動画にアップロードするのは、明らかに個人利用の範囲は超えている。
後、PEGASYS WEB FLV Player と言う、自分のHPで FLV を表示するに便利なソフトも配布している。
当然、HP で動画を配信するのも個人利用の範囲は超えているだろう。
なんだろうか……
ニコニコ動画用の動画ファイルを作ることは出来るけど、アップロードは出来ません。ってこと？
本当に？
こうなるとつい邪推してしまう。
つまり、「ライセンスには一応書いているけど、黙認していて、特許持ってるところに訴えられたら、それをした人が悪い。うちはライセンスに書いている。」とか？
それとも、生成されたデータに関する制限は加わらないのか？
でも、そしたら掲示板の内容はおかしい。
もしかして制限が加わるのはMPEGのみでFLVについてはないのだろうか？
1度ニコニコ動画に動画を上げた後、AVI 用の FLV 4 Codec を使って動画を作った時、かなり低レートなのに生成された動画が綺麗だったことから、TMPGEnc 4.0 XPress にアップグレードしようかなぁとか思っていたんだけど、使えないのかなぁ。。。
これは問い合わせないと解決しなさそうだな。
投稿者 Takenori : 20:03 | コメント (0) | トラックバック
TMPGEnc 4.0 XPressについて聞いてみる
疑問点をペガシスさんに聞いてみる。
とりあえず、以下の質問内容で質問フォームから送ってみた。
----
現在、TMPGEnc 3.0 XPress を使用していて、TMPGEnc 4.0 XPress のアップグレードを検討しています。
その際、使用許諾契約書 を確認していて、気になることがありましたので、ご教授願いたく。
使用許諾契約書には、「本ソフトウェアを個人利用の範囲で利用する権利」とあります。
TMPGEnc 4.0 XPress へのアップグレードの目的は FLV4 プラグインが使えることなのですが、この TMPGEnc 4.0 XPress + FLV4 プラグインで生成された動画は、ニコニコ動画などへアップロードし、公開する事は出来ないのでしょうか？
ニコニコ動画へのアップロードは、明らかに個人利用の範囲を超えていると考えられますので、ライセンス的に不可なのではないかと思いました。
ただ、そうなると FLV4 プラグイン が存在する理由やニコニコ動画対応をアピールしている理由が良くわかりません。
「個人利用の範囲で利用する権利」とは、ソフトウェアの使用に関する制限であって、生成された動画ファイルの頒布に関する制限ではないのでしょうか？
もし、生成された動画ファイルの頒布に関する制限でない場合、それは生成可能なすべての動画ファイルに関して同じ扱いとなるのでしょうか？
つまり、FLV4 以外の WMV や MPEG 1 & 2、AVI ファイル、H.264、MPEG4 も同じ扱いなのでしょうか？
----
数営業日で返信があるようだ。
投稿者 Takenori : 20:26 | コメント (0) | トラックバック
2008年01月28日
TMPGEnc 4.0 XPressについてペガシスからの返答
挨拶などを抜いた返答は以下の通り。
----
御質問いただきました件ですが、
|
＞ 使用許諾契約書には、「本ソフトウェアを個人 |
弊社製品機能において、動画配信サイトへのアップロード機能は
含まれておりません。よって本件については、各配信サイト運営先まで
お問い合わせください。
|
＞ 「個人利用の範囲で利用する権利」とは、ソフ |
御指摘の通り、頒布に関しては各ライセンス保持者の規定を
御確認ください。
----
意味がわかりません。
もう少し突っ込んで聞かないことにはなんともいえないなぁ。
2個目のは、頒布の制限はコーデックのライセンス保持者の規定に従えばOKとも取れるが、わかりづらい。
投稿者 Takenori : 20:01 | コメント (0) | トラックバック
2008年01月30日
TMPGEnc 再質問内容検討
前回の質問の意味が良くわからなかったので、再質問の内容を考える。
確認したいことを簡潔に書くと、TMPGEnc XPress を使ってエンコードした動画ファイルをユーザーがどのように使おうとも、ペガシスは文句を言わないかどうか。
とりあえず、考えた質問は以下。
-----
ご回答ありがとうございました。
内容を確認しましたが、理解できませんでしたので再度質問させていただきたく。
こちらが確認したいことは明確なため、回答がYesかNoとなる質問と致しました。
疑義が発生しないように、YesかNoで回答していただきたく思います。
また、回答がNoの場合は、その理由をご教示ください。
なお、質問中では敬称を省略させていただいています。
1. TMPGEnc 4.0 XPress でエンコードした動画を動画配信サイトへアップロードすること、およびHPでの配信に関して、ペガシスは関知せず、ユーザーに対して制限は加えていない。
これについて、Yesでしょうか？ Noでしょうか？
2. TMPGEnc 4.0 XPress でエンコードした動画の頒布に関して、ペガシスは関知せず、ユーザーがどのように扱おうともかまわない。
これについて、Yesでしょうか？ Noでしょうか？
3. TMPGEnc 4.0 XPress でエンコードされた動画の頒布は、その動画形式のライセンス保持者の規定に従えば問題ない。
これについて、Yesでしょうか？ Noでしょうか？
以上、よろしくお願いいたします。
-----
こんな感じでいいと思うが、1日寝かせてもう少し検討しよう。
投稿者 Takenori : 01:32 | コメント (0) | トラックバック
2008年02月05日
TMPGEnc 再質問回答
再度質問した内容に対して答えが返ってきた。
質問内容はこれ。
挨拶などを抜いた返答は以下の通り。
----
TMPGEnc 4.0 XPressの使用許諾契約書に関してはアプリケーション自体の
使用に関する事になり、これをお守りしていただく限り、出力していただ
いたファイルに関して制限をするものではございません。それを前提とし
た上でいただきましたご質問に対してお答えさせていただきます。
1. TMPGEnc 4.0 XPress でエンコードした動画を動画配信サイトへアップ
ロードすること、およびHPでの配信に関して、ペガシスは関知せず、
ユーザーに対して制限は加えていない。
これについて、Yesでしょうか？ Noでしょうか？
Yesになります。
2. TMPGEnc 4.0 XPress でエンコードした動画の頒布に関して、
ペガシスは関知せず、ユーザーがどのように扱おうともかまわない。
これについて、Yesでしょうか？ Noでしょうか？
Yesになります。
3. TMPGEnc 4.0 XPress でエンコードされた動画の頒布は、
その動画形式のライセンス保持者の規定に従えば問題ない。
これについて、Yesでしょうか？ Noでしょうか？
Yesになります。
上記３点についてですが、文面中の「動画」を全て「動画または音声」
に読み替えて解釈していただけるようにお願いいたします。
また、全ての質問の回答に対し、「一般公開にふさわしくない内容の
コンテンツの公開」や「著作権侵害の恐れのあるコンテンツの作成ま
たは公開」などに関する問題については除外した返答となっているこ
とをご了承ください。これらの問題は今回のご質問とは別に存在し、
弊社の製品はこのような行為を助長するための製品ではないことを付
け加えさせて頂きます。
----
と言うことで、エンコードした動画の再配布に関しては、いわゆる公序良俗に反しない限り問題ないと言うことのようだ。