tag:blogger.com,1999:blog-8930619268823051312024-02-21T00:45:40.187+09:00っき雑記KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-893061926882305131.post-974992263589907562009-11-12T18:29:00.003+09:002009-11-12T19:56:42.830+09:00「世界の新着動画」で紹介されたくない投稿者の対策法を考えてみたニコニコ動画で最近始まった「世界の新着動画」で、今日になって、ようやく「生放送での引用」可否選択が追加されましたが、今までも色々あった「世界の新着動画」なので、視聴者としては今日の放送で何が起こるかちょっと心配です。<br /><br />そこで、思いつく限りで最もマズい状況を想定して、投稿者側の対策法について色々と考えてみました。ただし私自身は投稿者ではないので、勘違いまたは誤解している部分もあると思います。何がありましたらツッコミをよろしくお願いいたします。<br /><span style="color: rgb(255, 0, 0);">それから、これは2009年11月12日の放送開始前の素人予想にすぎないことにご注意ください。</span><br /><span style="color: rgb(255, 0, 0);">下記の内容はあくまで可能性ですので信じるか信じないかはご自由にどうぞ。</span><br /><span style="color: rgb(255, 0, 0);">もし内容が間違っていても責任は取れませんのであしからず。</span><br /><br /><br />1.「生放送での引用」可否選択の追加に伴い、「世界の新着動画」で紹介される動画の不足を解消するため、動画数の多いカテゴリでは紹介の対象となる動画の範囲を24時間にしている可能性があります。<br />ただし、範囲がどの時刻から始まるのかは、まだ判明していません。<br />「世界の新着動画」での紹介を拒否したい投稿者の方は、現時点では昨日(11/11)以降の日付がついている動画で「生放送での引用」を拒否にしておくことをオススメします。<br /><br />尚、登録動画数の少ないカテゴリ(例:政治カテゴリ)では、紹介される動画の不足を解消するために、紹介範囲に「新着順で○○位以内」という別ルールを適用し、結果として紹介される動画の日付の範囲がさらに拡大する可能性があります。<br />今までの放送では、紹介される動画のリストで最後の動画を放送した後は、<br /><ul><li>放送終了時刻前でも放送を終了する</li><li>リストの最初からまた放送する</li></ul>の2つのパターンがあるようですが、本日以降どちらになるのか、または別のパターンになるのかは一切不明です。<br /><br />2.紹介される動画の候補の抽出と「生放送での引用」の可否のチェックはどの時刻に行われているのかは不明で、この2つは別の時刻にチェックされている可能性があります。<br />そのため、放送の直前に「生放送での引用」を拒否にした場合、<br /><ul><li>紹介されない</li><li>紹介されないが、放送中に再生動画の読み込みだけ行われて再生数だけ上がる</li><li>放送開始時点の紹介可否を無視して紹介される</li></ul>のどれになるかはまだ分かっていません。<br />ですから、どうしても紹介を拒否したいのであれば、なるべく早めに「生放送での引用」で拒否しておくことをオススメします。<br /><br />尚、本日の時刻がついた動画は、今日は紹介されなくても明日紹介される可能性がありますので、ユーザー生放送で引用されないのは困るという理由で、「生放送での引用」の拒否を後から解除したい場合は、「世界の新着動画」の変更内容が分かるまでは、動画の日付の翌々日に解除した方がいいと思われます。<br /><br />3.本日の複数カテゴリ導入に伴い「世界の新着動画」において「○○カテゴリでやれ」に相当するコメントがつけられる可能性が増しています。(注:実際には「でやれ」はNGワード)<br />例えば、「今までなら「歌ってみた」カテゴリだがバックコーラスに初音ミクがいるからいいだろう」と安易に「VOCALOID」タグをつけてしまうと、「【世界の新着動画】アイマス・東方・ボカロカテゴリ」で紹介されて、「【世界の新着動画】やってみたカテゴリ」で紹介されるよりも更に荒れたコメントがつく結果になりかねません。<br />カテゴリタグはくれぐれも慎重につけるようにしてください。<br />【追記 2009/11/12 19:55】ニコニコ動画開発総指揮の<a href="http://twitter.com/koizuka/status/5646228277">戀塚さんのTwitterでの発言</a>によれば、「世界の新着動画のピックアップ対象は、「カテゴリ」マークが付いてる(カテゴリ選択された)カテゴリね」とのことです。<br /><br />4.本日の「生放送での引用」の追加によって紹介を拒否することができるようになったために、「紹介を拒否しなかったんだから何を言っても構わない」と勘違いした一部の視聴者が、今までよりもヒドいコメントをつける事態が懸念されます。<br />11/5に元動画に反映されるコメントの数が調整されたのと、「世界の新着動画」におけるNGワードが日々増やされていることから、元動画に反映されるコメントの内容は、開始直後よりは大分マシになったのではないかと思われますが、投稿者の方は今までに紹介された動画の結果を見て「これくらいのコメントなら大したことない」と油断しないようにしてください。<br /><br />尚、「世界の新着動画」の会場である「試写室」は500人単位で会場が区切られていて、基本的には入場した順に割り振られるようになっています。<br />そのため、放送の途中からしか入場したことがない投稿者の方は、コメントの少なさに「こんなに少ないのか」と拍子抜けすることがあるようですので、特に注意してください。<br /><br />5.「生放送での引用」を拒否した場合、「世界の新着動画」で紹介されなくなるのと同時に、「ユーザ生放送」での紹介もできなくなる仕様になっているそうなので、ある動画が「生放送での引用」で「世界の新着動画」での紹介を拒否したかどうかは、ユーザー生放送で再生を試してみれば分かってしまうのではないか?と思われます。<br />(この辺り、ちょっとよく分かってないので事情をご存知の方は教えて頂けると助かります。)<br />投稿者の方は、「生放送での引用」で拒否しても、他の人には分からないとは思わないようにした方がよいと思われます。<br /><br />以上<br /><br />上記の内容については、いくらなんでも心配し過ぎという意見はもちろんあるでしょうし、確かにそう思うのですが、今日の変更内容についてはまだ情報が乏しいので、紹介を拒否するための自衛策としては過剰な対策法を提示せざるを得ませんでした。<br /><br />運営側の方々には、投稿者の不安を解消するためにも、「世界の新着動画」で紹介される動画の範囲については、ユーザの努力による調査をあまりあてにせず、多少は情報を公開することを切に要望します。KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-43508609232733312242009-09-30T23:52:00.002+09:002009-10-19T14:40:34.057+09:00WMV配信サイトとMacとSilverlightの話 (その2)もたもたしている内に前回から一ヶ月程経過してしまいましたが、前回からの続きです。<br /><br /><span style="font-weight: bold;">ポイント5:Silverlight版再生プレイヤーではサポートできない機能がある</span><br /><br />SilverlightはWMV形式の動画の再生をサポートしていますが、WMV形式と一口に言っても、その種類や配信方法は多種多様です。<br /><br />しかし、SilverlightはWindows Media Playerや、Webブラウザ向けのWindows Media Player プラグインが再生可能なWMV形式の動画の全てをサポートしているわけではありません。<br /><br />その理由としては、Silverlightは開発当初からランタイムパッケージのファイルサイズを極力抑えるという目標があったので機能を削らざるを得なかった、あるいはSilverlightは将来的に携帯端末のハードウェアデコーダをサポートする予定があるのでそちらに合わせて機能を絞った等の理由が考えられますが、これらは一部外者の単なる想像に過ぎません。<br /><br />ともあれ、WMV配信サイトは幸いなことに、WMV形式の種類に関しては、唯一の例外である音声のデュアルモノを除けば従来からSilverlightでの再生が可能な形式を使っていましたので、その点ではほとんど問題はありません。<br />細かい話をすれば、SilverlightではWMVファイル本体に埋め込まれたメタデータ、例えば動画のタイトル、製作者名や著作権表記を読み込めないという制限はあるのですが、これは別途、Windows Media向けのメタファイルである.ASXファイルに記述すれば済む話です。<br /><br />しかし、配信手法に関しては、SilverlightがHTTPプロトコルでのメディア配信にしか対応していないために、今まで提供していた非HTTPのメディア配信プロトコルやダウンロードコンテンツと呼ばれる配信方法を見送らざるを得ませんでした。<br />ここでは、これらの機能の概要を順に説明します。<br /><br /><span style="font-weight: bold;">1. デュアルモノ</span><br /><br />Silverlightで使える音声コーデックとしては、1.0と2で利用可能なMP3とWMA、3で新しく追加されたAACがあります。これらのコーデックは全て、一つのステレオ音声のストリームの左右2つのチャネルに別の音声を割り当てて、2つのモノラル音声として扱うデュアルモノという機能を仕様上持っています。<br />具体的な用途としては、アナログTV放送の二ヶ国語放送や副音声付放送のような使い方ができます。<br /><br />実際には、動画の配信で二ヶ国語や副音声をサポートしている例は滅多にないのですが、講演や演説の中継で日本語と英語の両方の音声をサポートするようなケースがたまにあります。<br />最近では、MicrsoftのReMIX Tokyo 09というイベントのキーノート中継が日本語と英語の音声をサポートしようとしていました。<br /><br />しかし、Silverlightではデュアルモノをサポートしていませんし、デコード後の音声データをアプリケーションが取得する手段が提供されていないので、左右どちらかのチャネルのモノラル音声を左右両方のチャネルに流す手段がありません。<br /><br />先のイベントでは苦肉の策として、左右に音を振るパン機能を使って、日本語音声の選択時には右スピーカーだけで日本語音声を流し、英語音声の選択時には左スピーカーだけで英語を流すという方法をとっていました。<br />スピーカーならまだいいのですが、ヘッドフォンで音声が片方からしか流れないのはなかなかツラい物があります。<br /><br />Silverlightを実際に開発しているのはアメリカですが、二ヶ国語音声のサポートについては、日本や他の国から積極的に提案しないと採用は難しそうです。二ヶ国語音声をデュアルモノを使わずに実現する方法としては、複数の音声ストリームとその切り替えをサポートするような方法も考えられます。<br /><br />MSKK(Microsoftの日本法人)の中の人には、今後のキーノート中継のためにも、ぜひ本家に対して何らかの提案を行って頂きたいと思います。<br /><br /><span style="font-weight: bold;">2. 非HTTPのメディア配信プロトコル</span><br /><br />プロトコルとは、簡単に説明するとデータを送受信する手続きのことです。<br /><br />プロトコルの種類はうんざりする程多いので、国際標準化されたプロトコルをインターネット向けに限定しても、辞典が作れるぐらいの種類があります。<br />しかし、最近のWebサービスではプロクシサーバを越えてサービスを提供したいという事情から、目的や用途を問わず、HTTPのみをプロトコルとして利用しようとする強い風潮があり、Silverlightもその例外ではありません。<br /><br />ただ、昔は、まだHTTPのバージョンが古く、今ならほとんどの環境で使えるいくつかの機能が欠けていたこともあって、サービスの目的や用途に応じて専用のプロトコルを利用するのが一般的でした。<br /><br />Microsoft(以下MS)社製のストリーミングメディアサーバである、Windows Media Serviceも、古くから使われているサーバですので、RTSP (Real Time Streaming Protocol)やMMS (Microsoft Media Services)等の、メディア配信用の専用プロトコルが既定のプロトコルになっています。<br /><br />正直に言えば、私はRTSPとMMSの細かい違いは知らないのですが、昔はMS社が開発した独自のプロトコルであるMMSを使っていたものの、ベンダー独自仕様を避ける世の中の流れを受けて、Windows Media 9以降は(主にDRM方面でのMS社独自の拡張の追加はあるものの)国際標準規格であるRTSPを既定のプロトコルとして利用するようになったという事情があるようです。<br /><br />結局、現在のWindows Media Serviceは、既定のプロトコルとしてはRTSPを用い、RTSPには対応していない古いクライアントに対してはMMSで試してみて、それでもダメなら、いくつかの機能制限はあるものの、HTTP(とその亜種)を使用するという処理が自動的に実行されるようになっています。<br /><br />尚、上記の処理をMicrosoft社はプロトコルロールオーバーと呼んでいるので、以下ではそう呼ぶことにします。<br /><br />さて、上述したいくつかの機能制限の話ですが、具体的には、<del>ライブ配信</del>、マルチビットレート(MBR)、マルチキャストの3つが挙げられます。<br /><br /><del><span style="font-weight: bold;">2-1. ライブ配信</span><br /><br />Winows Media Serviceは、蓄積された映像を配信するオンデマンド配信と、生中継の映像を配信するライブ配信の2つの機能をもっているのですが、プロトコルとしてHTTPを使う場合は、ライブ配信には対応していません。(ちょっと自信なし)<br /><br />Silverlightが対応しているプロトコルは基本的にHTTPだけなので、プロトコルロールオーバーを使って、コンテンツ配信サーバは変えずに再生ができるようになっているのですが、映画やTV放送のような既に存在する映像のオンデマンド配信はできても生中継のライブ配信はできません。<br /><br />残念ながら、Windows Media Service(あるいはその業務版?)を使用している既存のWMV配信サイトでは、当分の間は、ライブ配信については対象をWindows Media Playerのみとし、Silverlightは対応外ということになりそうです。<br />先ほどのReMIX Tokyo 09では、Windows Media Serviceではないサーバを使ってSilverlightでのライブ配信を実現していますが、その話はちょっと後回しにさせてください。(^^;)</del><br /><br /><span style="color: rgb(255, 0, 0);">【訂正】Windows Media ServiceでもSilverlight向けにライブ配信は可能とのことです。Live Smooth Streamingが登場するまでは、Smooth Streamingでライブ配信はできなかったという話を、Silverlightでライブ配信はできなかったという話と誤解していました。お詫びして訂正します。(2009/10/06)</span><br /><br /><span style="font-weight: bold;">2-2. マルチビットレート</span><br /><br />Windows Media Serviceには、マルチビットレート(MBR)という機能があります。<br />マルチビットレートのビットレートとは一秒間に送れるデータ量の単位を指します。<br /><br />最近流行のHD映像は今までの映像よりも解像度が高いので、それに伴ってデータ量も増え、結果としてビットレートも高くなるので、速い回線速度を必要とします。<br /><br />しかし、ユーザ側の回線環境は様々ですし、配信中に状況が変化することも多々あります。回線が細くなって映像に必要なビットレートを保てなくなると、結果として映像がガクガクになりますし、音声も乱れてしまいます。<br /><br />マルチビットレートはこれを解決するために、異なるビットレートでエンコードした複数の映像データを事前に用意しておいて、再生プレイヤー側の状況に応じて適切なビットレートのデータを選択し、それに切り替えて配信する仕組みです。<br /><br />ShowTime をWindowsで視聴した経験がある方の中には、高画質で映像を再生している時に、映像がボケボケの低画質になったり、静止画像が数秒に一度程度更新されたり、画面が暗くなったまま音声だけ流れる状態になった経験がある方がいらっしゃると思いますが、これがマルチビットレートの結果です。<br /><br />細かい話をすると、実際にはマルチビットレート以外にもクライアント側で回線状況の悪化に対応する技術も使われているのですが、話が長くなるので今回は省略させてください。m(__)m<br /><br />ShowTimeでは高画質と標準画質の2つのビットレートの動画を再生前に選択することはできるのですが、再生中にこの2つを切り替えることはできないので、慎重に選ぶ必要があります。<br /><br /><span style="font-weight: bold;">2-3. マルチキャスト</span><br /><br />マルチキャストにはいくつか種類があるのですが、基本的には誰かが送りたいデータを全ユーザに送り、必要なユーザだけがそれを受け取る仕組みということになります。<br />しかし、その仕組み上、送られるデータが同一である必要がありますので、ライブ配信向けの技術ということになります。<br />オンデマンド配信の場合は、例え一つの映像しか流さなかったとしても、同一時刻に再生されている画面は視聴しているユーザによって変わりますので、マルチキャストができないということです。<br />現在のところ、Silverlightはマルチキャストに対応していません。<br /><br /><span style="font-weight: bold;">3. ダウンロードコンテンツ</span><br /><br />いわゆるダウンロードコンテンツとは、映像データをストリーミングによってネットから流し続けるのではなく、一度動画ファイルをダウンロードして、オフライン状態で視聴するサービスです。<br /><br />そのためにはクライアントPCに、映像の全データを保存しておく必要があるのですが、Silverlightはセキュリティ上の都合から、クライアントPCのローカルなファイルへのアクセスが大幅に制限されています。<br /><br />ほぼ唯一の例外として分離ストレージという領域を利用することはできるのですが、これはユーザのホームディレクトリ以下の特定の場所に隔離されていますので、ファイルサイズの大きい動画データの全てを常に同じ場所に保存するしかなく、ファイル移動も簡単にはできないというデメリットがあります。<br /><br />Windows Media Playerが提供されていないMac OS Xの様なOSや、ネットワークに常時接続可能とは限らないモバイル端末のような環境でもダウンロードコンテンツを再生可能にするための何らかの方策を考えて欲しいものです。<br /><br /><span style="font-weight: bold;">ポイント6:Silverlightのメディアエンジンはエラー耐性が低い</span><br /><br />Silverlightで動画や音声を再生するソフトウェアをメディアエンジンと呼んでいるのですが、Silverlightは、これをWindows Media Playerとは別に、自前で持っています。<br /><br />機能はほとんど被っているので無駄なようにも見えますが、SilverlightはMac OS X等Windows以外の環境でも実行されるのでメディアエンジンを統一したかったのかもしれませんし、レガシーなコーデックもサポートしていてたまにセキュリティ的な脆弱性が発見されるフルスペックのメディアデコーダの使用を避けて、一から必要最低限のデコーダを作成することで、セキュリティを高めたいという目的があったのかもしれません。<br /><br />さて、動画を視聴している時間が長い方はご存知だと思いますが、映像の中に緑やピンクの四角を見たことはありませんでしょうか?<br /><br />これはブロックノイズと呼ばれるノイズの一種で、大抵は映像データのエラーが原因です。<br />Windows Media PlayerやWebブラウザ向けのWindows Media Player Pluginであればエラーに耐性があるので、画面が多少乱れはするもののそのまま再生が続行されるのですが、SilverlightでこのようなWMVファイルを再生した場合、エラーが発生した時点で問答無用で再生を終了してしまいます。<br />これはSilverlightのメディアエンジンのエラー耐性が低いからであると考えられます。<br /><br />Silverlightのメディアエンジンのエラー耐性が低いことで発生しうる問題は、主に3つあります。<br /><br />1つめは、WMVファイルを単純に複数のファイルに分割して複数のWMVファイルにして再生する場合です。<br />この場合、分割された2番目以降のファイルを最初から再生しようとしても全く再生されません。<br />ただ、正規のWMV配信サービスでこのようなデータが配信されることは基本的にはありえません。<br />強いて言えば、WMV以外の映像形式の話になりますが、FlashでH.264/AAC形式で提供されている動画配信サービスをSilverlightに移植する場合に、問題になるぐらいでしょうか。<br /><br />Flashの動画配信サービスでは、HTTPを使ったプログレッシブダウンロードのいくつかの欠点を補うために、サーバ上の単一の動画ファイルを、クライアントからは、単純に分割された複数のファイルとして見えるように見せかけて動画のシークを早める技術(正式名称は知りません)を使っている事例があります。<br />他には、一つの映像を映像の仕様上は分断してはいけない箇所で分断して別々の映像として配信している事例もあるようです。先日の大臣就任会見の映像で、このような映像を見かけました。<br /><br />Flashの動画デコーダはエラー耐性があるので、このようなファイルであっても最初は画面が乱れるものの何とか再生できてしまうのですが、Silverlightでは、サーバ側で独立した複数の動画ファイルを単一の動画ファイルとして正しくなるように辻褄を合わせない限り再生できないことになります。<br /><br />エラー耐性の低さが問題になるケースの2つめはデータの転送経路にノイズが多い経路が含まれていたために、動画データが意図せずにほんの少しだけ壊れていた場合です。<br /><br />これが実際に問題になるのは、生放送をライブ配信して、複数の離れた中継地点から現場中継するような状況です。<br /><br />この場合、カメラから電波で映像を飛ばすことになると思われますが、電波はノイズが多い媒体なので中継中に画像が乱れることがあるのはよくご存じだと思います。<br />先日のテレビで中継していた日食の映像で、画面が停まったり多少ノイズが発生するような映像が流れることがありましたが、Silverlightの場合は再生自体が終了することになります。<br /><br />これを防ぐ方法としてはエラーの混じった映像データを、再度エラーがない映像としてエンコードし直すような方法が考えられますが、再エンコードは一般的に画質が落ちますし、エラーのある映像データをピンポイントで修正するようなソフトは今のところ見たことがありません。<br /><br />さて、エラー耐性の低さが問題になるケースの3つめは、非MS製のエンコーダがWMVとしては不正なデータを出力するケースです。<br /><br />MS社製のエンコーダであれば、そのようなデータを出力することはないはずなのですが、世の中にはハードウェア、ソフトウェアを問わず、様々なWMVエンコーダがあり、残念ながら常に正しい映像データが出力されるとは限りません。<br /><br />具体的にはWMV形式で提供されているゲームのデモムービーの一部でブロックノイズが発生する動画があり、Silverlightではそれ以降の映像が全く再生できないという事例がありました。<br />デモムービーは通常はWindows Media Playerを対象としていますから、多少のエラーはエラー補正によって解決されるために見逃されてしまうようなのですが、後で同じ映像データをSilverlightでも再生する必要が生じた場合に問題になってしまいます。<br /><br />コンテンツを作成する方には、納品データがWMV形式の場合は、極力MS社で確認済みのエンコーダを使い、Silverlightでも再生可能かどうかをチェックすることをオススメしたいと思います。<br /><br />(その3に続く)KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-68787376214465602222009-08-26T21:57:00.011+09:002009-09-30T22:50:20.498+09:00WMV配信サイトとMacとSilverlightの話 (その1)先週は、<a href="http://www.microsoft.com/japan/teched/2009/default.mspx">Microsoft Tech·Ed Japan 2009</a>の開催、<a href="http://www.apple.com/jp/macosx/">Snow Leopard</a>の発売等、話題に事欠かない一週間でしたが、同じく先週の8月25日、動画配信サイトの<a href="http://www.showtime.jp/">ShowTime</a>がついにMac OS X環境での視聴への対応を発表しました。翌日の26日には無料動画サイトの<a href="http://www.gyao.jp/">GyaO</a>も、2009年秋に予定されている<a href="http://streaming.yahoo.co.jp/">Yahoo!動画</a>との統合と同時にMac OS X環境で視聴可能になる旨を発表しています。<br /><br />【公式ページ】<br /><ul><li><a href="http://www.showtime.jp/special/info_mac/">【ShowTime】MacintoshでShowTimeを見るには〜はじめてのShowTime!<ショウタイム></a></li><li><a href="http://gyao.yahoo.co.jp/">生まれ変わる映像サイト「GyaO」はこうなる!<GyaO [ギャオ]></a></li></ul> 【関連記事】<br /><ul><li><a href="http://www.showtime.jp/special/info_mac/">ShowTime、Silverlight採用でMac環境での視聴が可能に -BB Watch </a></li><li><a href="http://www.rbbtoday.com/news/20090825/61979.html">有料動画配信サイト「ShowTime」、Silverlightを採用した動画配信を開始:RBB TODAY (ブロードバンド情報サイト) 2009/08/25</a></li><li><a href="http://bb.watch.impress.co.jp/docs/news/20090826_310896.html">新生GyaO、Silverlight本格採用でMacからの視聴に対応へ -BB Watch</a></li></ul>それにしても、<a href="http://internet.watch.impress.co.jp/docs/news/20090825_310616.html">BB Watchと同じ記事</a>を配信している<a href="http://internet.watch.impress.co.jp/">INTERNET Watch</a>を含めても、このニュースを取り上げたニュースサイトが3つというのは少々寂しく感じられます。<br /><br />というのは、Macユーザ(の一部)は、デジタル著作権管理(DRM)機能で保護された、Windows Media Video形式の動画を配信するサイト(以下「WMV配信サイト」とします)を正規に視聴する手段を、前世紀からずっと待ち続けていたからです。<br /><br />2008年10月にSilverlight 2がリリースされたことで技術的には視聴が可能になったあとも、これに対応するWMV配信サイトがなかなか現れず、しびれを切らしていたのですが、これでようやく一つの節目を迎えたように思います。<br /><br />その間の、Macユーザ(の一部)のMicrosoft社に対する積年の恨みつらみを書き連ねるとブログの容量が足りなくなってしまいますので、そこはさっくり省略して、今回はMacユーザの立場から、WMV配信サイトをMacで視聴するポイントと今後の予想について書いてみたいと思います。<br /><br /><span style="font-weight: bold;font-size:130%;" >WMV配信サイトをMacで視聴するポイント<br /></span><br /><span style="font-weight: bold;">ポイント1: PowerPC搭載のMacでは再生できない。</span><br />今回、WMV配信サイトの動画コンテンツがMac OS X環境で視聴できるようになったのは、Mac OS Xで動作可能なSilverlight版の動画再生プレイヤーが開発されたからです。<br /><br />Silverlightは、現状 1.0/2/3の3種類がありますが、WMV配信サイトが著作権管理に使用している Windows Media DRM(WM DRM)に対応しているのは、Silverlight 2以降になっています。<br /><br />しかし、PowerPC版のMac OS X向けに提供されているのは、Silverlight 1.0だけです。<br /><br />その理由としては、Mac OS X版のSilverlight 2以降ではSilverlightランタイムの核であるCoreCLRのWindows版のバイナリを、Win32 APIをエミュレートするPlatform Adaptation Layer(PAL)というレイヤー上でほぼそのまま実行する仕組みになっていることが大きいのではないかと考えられます。<br /><br />Windows版のCoreCLRのバイナリを非Intel製のCPUで実行するには、Win32 APIだけではなくCPUもエミュレートする必要があるので、パフォーマンスが足りなくなってしまうのではないか?というのがその理由です。<br /><br />「結局は単にPowerPCなMacのシェアが低いからじゃね?」という、もっともな意見はさておき、PowerPC搭載のMacではWMV配信サイトを視聴できませんので、どうしてもMacで再生したい場合は、Intel Macを購入しなければなりません。<br /><br />尚、CPUの種類については、動作条件として Core Duo 1.83GHz 以上となっていますが、これはSilverlight 2および3の動作条件と同じです。<br /><br />Intel Macでこの条件を満たさないのは、2006年に出荷されたMac miniに搭載されていた Core Solo 1.5GHz と Core Duo 1.66MHz だけのはずですが、これらのMacでSilverlight 2をインストールしようとすると、CPUのチェックでエラーが発生するそうです。<br /><br /><span style="font-weight: bold;">ポイント2:Mac OS X 10.4.8より古いOSでは再生できない。</span><br />この件については、初代のIntel Macの時点でMac OS X 10.4.6がインストールされていて、無料アップデートで10.4.11までアップデートが可能なので上記の条件を満たしていれば特に問題ないはずです。<br /><br />むしろ心配なのは、今月の28日に発売されたMac OS X 10.6(Snow Leopard)での動作です。<br />Silverlightは今のところ32ビット版しか提供されていないので、64ビットカーネルモードのSnow Leopardで何かしら問題が発生するのではないかと少し心配しています。<br /><br />特に心配なのは、手元の Mac OS X 10.5.8 + Silverlight 3.0.40723.0 + Firefox 3.0.13/3.5.2 では<br />入力された先頭の文字が化けてしまう現象が発生している日本語入力関連ですが、今回ShowTimeから発表されたプレイヤーでは日本語入力はありませんでしたし、日程的にはMicrosoft社のSnow LeopardでのSilverlightのテストは既に終わっていないとおかしいはずですので、多分大丈夫だろうと信じることにします。<br /><br />本当に信じてるかどうかは聞かないでください。(ぉぃ<br /><br /><span style="font-weight: bold;">ポイント3:全画面モードで視聴時にカクツクようであれば画面解像度を下げてみる</span><br />ShowTimeの現時点のプレイヤーはSilverlight 2アプリケーションであるために、Silverlight 3のGPUハードウェアアクセラレーション機能には対応していません。<br /><br />Silverlight 2では元映像の拡大処理をCPUでしか実行できないので、その分CPUとバスに負担がかかります。この負担はCPUは遅いが画面解像度が高いMac(結構あります)で全画面表示する場合に顕著になります。<br /><br />ShowTimeの動画コンテンツは640x480ピクセル以下のようですので、再生画面を表示する前に、Mac OS Xの「システム環境設定」の「ディスプレイ」で画面解像度を下げてから再生プレイヤー側で全画面モードにすることで、CPU負荷を多少は下げることができるようです。<br /><br />もし、ShowTimeの動画再生プレイヤーがSilverlight 3アプリケーションになれば、全画面モードの場合に限り、動画の拡大処理をGPUハードウェアアクセラレーション機能を用いてGPU側で実行することが可能になるので、CPUとバスの負担を減らせます。ぜひ対応を検討していただきたいものです。<br /><br />ただし、Silverlight 3は、Windows版/Mac OS X版を問わず、AvivoやPureVideoのようなGPUによる映像のデコード支援機能には対応していませんので、これ以上の負荷低減についてSilverlight 3の次のバージョン以降に注目するしかありません。<br /><br />私個人はグラフィックドライバの安定性に対して根強い不信感を持っていますので、インターネット上の信頼性が低い映像ストリームをユーザの個別許可無しに直接GPUに流し込むことについてはかなり不安があるのですが、Microsoft社もライバルであるFlashの動向次第では踏み切らざるを得ないだろうなーぐらいに考えています。<br /><br />尚、Windows版のSilverlight 3では非全画面モードでもGPUハードウェアアクセラレーションが有効になるのに、Mac OS X版のSilverlight 3では有効にならない理由ははっきりとは分かりません。<br /><br />Microsoft社はこの制限を、Mac OS XのWebブラウザプラグインのモデルに起因する制限であると主張しているようなのですが、いやそんなことはないという意見もあるようで、ちょっと判断がつきませんでした。<br /><br />(その2に続く)KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-65189609338426335352009-05-31T23:47:00.003+09:002009-05-31T23:57:26.930+09:00要するに三田さんの考えるフェアユースってこういうこと?三田「お金を払わなきゃフェアじゃない。フェアユースじゃない。」<br /><br />問「お金の問題なんですか?」<br /><br />三田「金銭的なインセンティブは本質的な問題ではない。重要なのは作家へのリスペクトだ。」<br /><br />問「なるほど、金銭以外にもリスペクトする方法があるってことですね。」<br /><br />三田「お金を払わなきゃフェアじゃない。フェアユースじゃない。」<br /><br />(以下、繰り返し)KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-14027118088784160902009-04-01T22:15:00.002+09:002009-04-04T03:10:59.736+09:00Silverlight 3で追加されたaglimitパラメータによる機能制限はSilverlight広告への布石?<span style="color: rgb(255, 0, 0);font-size:100%;" >【注意】aglimitはエイプリルフールのネタで実際には存在しませんのであしからず。(追記 2009/4/3)</span><br /><h3>●はじめに</h3>先月発表された、Silverlight 3 Beta 1でちょっと面白い機能を見つけました。<br /><br />HTMLからSilverlight3アプリケーションを呼び出す時は、<object>タグを使用するのですが、その内部で、<params>タグを使って指定するパラメータにaglimitというパラメータが追加されているのです。<br />まずはサンプルを挙げてみます。<br /><pre class="syntax-highlight">1: <span class="synIdentifier"><</span><span class="synStatement">object</span><span class="synIdentifier"> </span><span class="synType">data</span><span class="synIdentifier">=</span><span class="synConstant">"data:application/x-silverlight-2,"</span><span class="synIdentifier"> </span><span class="synType">type</span><span class="synIdentifier">=</span><span class="synConstant">"application/x-silverlight-2"</span><span class="synIdentifier">></span><br />2: <span class="synIdentifier"><</span><span class="synStatement">param</span><span class="synIdentifier"> </span><span class="synType">name</span><span class="synIdentifier">=</span><span class="synConstant">"minRuntimeVersion"</span><span class="synIdentifier"> </span><span class="synType">value</span><span class="synIdentifier">=</span><span class="synConstant">"3.0.40307.0"</span><span class="synIdentifier"> /></span><br />3: <span class="synIdentifier"><</span><span class="synStatement">param</span><span class="synIdentifier"> </span><span class="synType">name</span><span class="synIdentifier">=</span><span class="synConstant">"aglimit"</span><span class="synIdentifier"> </span><span class="synType">value</span><span class="synIdentifier">=</span><span class="synConstant">"audio+movie"</span><span class="synIdentifier"> /></span><br />4: ...<br />5: <span class="synIdentifier"><</span><span class="synStatement">object</span><span class="synIdentifier">></span><br /></pre><br />上記の value="audio+movie"の部分で、Silverlightアプリケーションでの動画や音声の再生が禁止されます。<br />ちなみに、agは銀の元素記号で、Silverlightを指しています。<br />Silverlight関連で、agを接頭辞に持つ名前が色々あるのはそのためです。(例:agcore.dll、AgDLR)<br /><br />ついでですが、Silverlight 3 Beta 1で作成したアプリケーションを呼び出す<object>タグの使い方については、@matarilloさんの、「<a href="http://d.hatena.ne.jp/matarillo/20090325/p1">ユーザーがSilverlight 3ベータ版をインストールするときの挙動</a>」が必読です。少なくともSilverlight 3アプリケーションを公開するかもしれない人は全員読むべきだと思います。<br /><h3>●なぜaglimitが追加されたのか?</h3><br />Microsoft側としては、Silverlightの表現力を制限する機能であるaglimitをあまり大っぴらに宣伝したくないのか、MIX09でのSilverlight関連の発表でも触れられていないようですし、開発者向けのドキュメントやヘルプにもまだ記載がありません。<br /><br />そのため、aglimitが追加された理由については、はっきりとは分からないのですが、個人的には、aglimitは「Silverlight広告」の推進の布石ではないだろうか?と予想をしています。<br />というのは、従来のFlash広告には、この手の機能を制限する仕組みがほとんどありません。<br />ですから、広告のあるページを開いただけでいきなり音が鳴ってビックリした経験をお持ちの方も多いと思います。Flash広告が嫌われる理由の一つですね。<br /><br />この問題については、仮に広告掲載側がFlash広告での音声の再生を禁止しようとしても、基本的にはFlash広告の中身を提供する側との契約内容で制限し、それを信頼するしかありませんでした。<br />つまり、Flashは広告として利用するにはアプリの自由度が少し高すぎるという欠点があったわけです。<br /><br />Microsoftはこの点に目をつけて、Silverlight広告を掲載するページのHTML側でSilverilghtアプリケーションの機能をきめ細かく制限する方法を提供し、Flash広告との差別化を図ろうとしたのではないでしょうか?<br /><br />HTML側から機能制限が可能になれば、広告を掲載する側が、Silverlight広告が悪意を持ったコードを含んでいるかどうかを心配する必要性が多少は減りますし、広告を提供する側も、一つのSilverlight広告を、禁止内容が異なる複数のサイトで使いまわすことができます。<br /><h3>●aglimitの詳細</h3><br />先ほども書いたように、現時点ではドキュメントやヘルプにaglimitについての記載がないので、ごにょごにょして調べてみたのですが、どうやら以下の文字列を指定可能のようです。内容については一通り確認してみましたが、一部推測が混じってますので、注意してください。<br /><ul><li><span style="font-weight: bold;">audio</span> - 音声再生の禁止</li><li><span style="font-weight: bold;">movie</span> - 動画再生の禁止</li><li><span style="font-weight: bold;">media</span> - audio+movie</li><li><span style="font-weight: bold;">cookie</span> - cookieの受信の禁止</li><li><span style="font-weight: bold;">http </span>- HTTP使用の禁止</li><li><span style="font-weight: bold;">socket</span> - ソケット使用の禁止</li><li><span style="font-weight: bold;">link</span> - URLリンクの禁止</li><li><span style="font-weight: bold;">network</span> - cookie+http+socket (linkは対象外)</li><li><span style="font-weight: bold;">ps</span> - ピクセルシェーダの禁止</li><li><span style="font-weight: bold;">hwaccel</span> - GPUを使ったハードウェアアクセラレーションの禁止</li><li><span style="font-weight: bold;">gpu</span> - ps+hwaccel</li><li><span style="font-weight: bold;">is</span> - 分離ストレージの使用の禁止</li><li><span style="font-weight: bold;">fullscreen</span> - 全画面モードの禁止</li><li><span style="font-weight: bold;">all</span> - 上記全てのオプションを有効</li></ul><span style="font-weight: bold;"></span>(注)<br />文字列は+で連結して複数指定が可能。<br /> aglimit=audio+movie -> audioとmovieを同時指定<br />文字列の前に-をつけると禁止を無効にできる<br /> aglimit=media-audio ->movieとimageは無効でaudioのみ有効<br />後ろのパラメータが優先<br /> aglimit=movie+audio-movie ->audioと同じ<br />大文字小文字は無視される<br /> aglimit=Audio -> aglimit=audioと同じ<br />TYPOは黙って無視される<br /> aglimit=soket -> socketのTYPOだが何も起こらない<br /><br />かなり細かい指定が可能なのが分かると思います。<br /><h3>●aglimitの使用上の注意点</h3><br />・パラメータを一つでも有効にすると、アプリケーション側からのJavaScriptとDOM操作が禁止される。<br /> これは、aglimitで制限を加えても、JavaScriptやDOM操作を可能にしてしまうと機能制限を解除されてしまうからじゃないかと思います。<br /><br />・httpまたはnetを指定した場合に、Assembly Caching機能が使用できない。<br /> Assembly Cachingは、Silverlight 3で追加された新機能で、拡張ライブラリである.slvx形式のファイルを実行時にWebサイトから読み込むことで、アプリケーション本体のサイズを縮小し、一度読み込んだ拡張ライブラリをキャッシュして複数のアプリケーションで使いまわす機能です。.slvx形式のファイルは、アセンブリと呼ばれる.dllファイルを含んでいるのが普通ですが、もし他のファイルを含んでいた場合、aglimitでhttpやnetを使って外部ファイルの読み込みを禁止しても回避できてしまいます。故にAssembly Cachingも禁止対象になったということだと思います。<br /><br />・Sloob(SilverLight Out Of the Browserの略)化すると、aglimitが無効になる。<br /> Sloob化したSilverlightアプリケーションには、<params>の内容を渡すことが元々できませんので、これはまあ仕方ないと思います。<br /><br />・aglimit=audioは音声を完全に禁止できるが、aglimit=movieは動画を完全には禁止できない。<br /> movieはMediaElementを使った動画ファイルや動画ストリームの再生を禁止する事はできますが、複数の画像ファイルの連続表示を使った擬似的な動画再生を禁止することはできません。<br />かといって、imageも追加指定すると普通の静止画像も禁止されてしまい、表現力が大幅に損なわれます。この辺りは難しいところですね。<br /><br />・hwaccelはCPU利用率を上げてしまうことがある。<br /> GPUを使ったハードウェアアクセラレーションが、ソフトウェアエミュレーションに切り替わるからです。hwaccelは、GPUの利用によってシステムの安定性が下がることが懸念されるケース、例えば同じページ内にGPUを酷使している物が他にある場合等に限るか、gpuを指定してソフトウェアによるエミュレーションも完全に禁止した方がいいかもしれません。<br /><br />・aglimitではCPU使用率はそんなに下がらない。<br /> aglimitによる機能制限は、net等を指定して通信エラーが発生するような場合を除けば、アプリケーション側からはaglimitの内容を確認しない限りaglimitによる制限を感知できないようです。<br />ですから、audioを指定して音声の再生を禁止すると、音は鳴りませんが、アプリケーションは音声を流したつもりになっています。<br />これはアプリケーションの開発者がaglimitの存在を気にせずにコードを書くことを可能にするためじゃないだろうか?と予想していますが、よく分かりません。<br /><br />・<params>で指定するパラメータとしてaglimitが予約されたので、他の用途で使えなくなった。<br />これは可能性としては低いだろうと思いますが、もし既存のSilverlight 2アプリで独自にaglimitパラメータを使って何らかの処理をしていたアプリケーションはソースの修正が必要になります。<br /><h3>●aglimit機能への要望</h3><br />一見、いいことづくめに見えるaglimit機能ですが、一つ残念なことがあります。<br />それは、実際に閲覧するユーザ側ではaglimitの指定が簡単にはできないことです。<br />これについては、Silverlightの構成に「機能」のようなタブを追加して、limitで指定するのと同等の制限を与えられるといいのではないかと思います。<br />Silverlightの構成のタブについては、Silverlight 2の「アプリケーション記憶域」タブもBeta 2になってから、ようやく追加されたという前例がありますので、今後、正式リリースまでの間にタブが追加される可能性はありそうです。<br /><h3>●最後に</h3><br />以上、Silverlight 3で追加されたaglimitパラメータについて、ざっと説明してみました。尚、Silverlight 3はまだBeta 1ですので、正式リリースまでの間に仕様の大幅な変更があることも充分考えられますので、実際に試す際は注意してください。<br />ひょっとするとドキュメントやヘルプに記載がないのもそのせいかもしれません。(了)KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-50215469482931825382009-03-23T01:25:00.006+09:002009-03-23T12:58:33.937+09:00Silverlight 3 Beta 1で (H.264/AAC).mp4 の再生を試す簡単なやり方先日、Microsoftから発表された、Silverlight 3 Beta 1(以下、SL3Beta1)の新機能の一つが、映像コーデックに<a href="http://ja.wikipedia.org/wiki/H.264">H.264</a>、音声コーデックに<a href="http://ja.wikipedia.org/wiki/AAC">AAC</a>、コンテナフォーマットに<a href="http://ja.wikipedia.org/wiki/MP4#ISO.E3.83.99.E3.83.BC.E3.82.B9.E3.83.A1.E3.83.87.E3.82.A3.E3.82.A2.E3.83.95.E3.82.A1.E3.82.A4.E3.83.AB.E3.83.95.E3.82.A9.E3.83.BC.E3.83.9E.E3.83.83.E3.83.88">ISO Base Mediaファイルフォーマット(ISO/IEC 14496-12)</a>を使った動画ファイル(以下、(H.264/AAC).mp4)の再生機能です。<br /><br />しかし、SL3Beta1は開発者向けのβ版なので、一般ユーザ向けのβ版のランタイム、つまりSL3Beta1のWebブラウザ用プラグインは配布されていませんし、今のところ、Silverlight 3が正式リリースされる前に、一般ユーザ向けにランタイムを配布する予定はないとのことです。<br /><br />また、SL3Beta1のライセンス条項に従えば、Microsoft社と別途契約して許諾を得ない限り、公開されたWebサイト上でテストすることもできません。<br /><br />ただ、開発者がPC上のローカルな環境でテストすることまでは、さすがに禁止されてはいないので、自分ではアプリを作成できないが、どうしても試してみたい方は<br /><ol><li><div align="justify">開発者用 Microsoft Silverlight 3 ランタイム Beta 1 (<a href="http://go.microsoft.com/fwlink/?LinkID=143433">Windows版</a>/<a href="http://go.microsoft.com/fwlink/?LinkID=143434">Mac OS X版</a>)をインストールする</div></li><li><a href="http://www.longtailvideo.com/players/jw-wmv-player/">JW WMV Player</a>をダウンロードして展開する</li><li>展開したフォルダに、(H.264/AAC).mp4な動画ファイルを置く</li><li>サンプルのHTMLファイル(readme.html)を参考に、動画ファイル名とサイズの指定を書き換える</li></ol>という手順で、開発者向けのツールを使わずに、再生機能の簡単な確認ができます。<br />JW WMV Player以外のSilverlight版のビデオ再生アプリとしては、<a href="https://timheuer.com/blog/">Tim Heuer</a>氏の<a href="http://www.codeplex.com/sl2videoplayer">Silverlight 2 Video Player</a>がありますが、こちらでも同様の手順で再生可能です。<br /><br />なお、WebブラウザとしてFirefoxやChromeを使用している場合、ローカルなHTMLファイルのパスに日本語(例:デスクトップ)が含まれていると、Silverlightアプリケーションが実行できなくなりますので注意してください。<br />IEであればパスに日本語が含まれていても問題ありませんでした。恐らく、URLのエンコーディング絡みの問題だと思います。<br />Silverlight側とWebブラウザ側のどちらの問題か?については、あえてコメントしませんのであしからずw<br /><br />それから、再生に必要な(H.264/AAC).mp4な動画ファイルの入手方法ですが、Microsoft社が推奨しているのは、<a href="http://www.microsoft.com/japan/products/expression/products/Overview.aspx?key=encoder">Microsoft Expressio Encoder 2</a>(試用版もあります)に<a href="http://www.microsoft.com/japan/products/expression/try-it/default.aspx?filter=servicepack">Expression Encoder 2 Service Pack 1</a>を適用し、エンコード機能を使って(H.264/AAC).mp4な動画ファイルを作成する方法です。<br /><br />そういうのは面倒くさいけど高解像度の動画の再生をちょっと試してみたいなーという方は、<a href="http://www.apple.com/quicktime/guide/hd/">Apple - QuickTime - HD Gallerry</a>からファイルを入手するのが一番手っ取り早くてオススメです。<br /><br />「Silverlight 3向けの動画ファイルとしてAppleのサンプルファイルを紹介するのはけしからん!」とおっしゃる方もいらっしゃるでしょうが、Microsoftの<a href="http://www.microsoft.com/japan/windows/windowsmedia/musicandvideo/hdvideo/contentshowcase.aspx">高精細コンテンツ ショーケース</a>にはWMV HDなファイルしかないので仕方がありません。というかどうにかしてください>中の人<br /><br />具体的には、適当な映像を選択してから、HTMLのソースを表示して、拡張子が.movになっているURLを探し、QuickTime Plug-inアドオンを停止(そうしないとブラウザ内で再生が始まってしまうので)した状態でWebブラウザのアドレスバーに入力するか、ダウンロード用のツールか何かを使ってダウンロードしてください。<br /><br />ここで公開されているファイルは、(H.264/AAC).movなQuickTime形式のファイルですが、QuickTimeのファイルフォーマットは、ISO Base Mediaファイルフォーマットのベースになっている関係で、Silverlight3でも一応再生ができます。他に、iPod向けの(H.264/AAC).movなファイルをいくつか試してみましたが、今のところ問題ないようです。<br /><br />もし、上記のサイトでダウンロードしたファイルのサイズが数十バイトだった場合、それはWindows MediaのASXファイルに相当する、QuickTime Metafileという形式のメタファイルですので、メモ帳やテキストエディットで中身を開いて、実体のファイル名を探してダウンロードし直してください。<br /><br />以上の手順で私も実際に試してみましたが、Silverlight 3の発表時にポイントとして挙げられていた、「GPUによる動画の再生支援」については、全画面化やサイズ変更等のスケーリングがメインで、GPUにH.264デコードをさせるようなことはしていないことがCPUの負荷から確認できました。<br /><br />ただ、これについては昨年9月の時点で、MS本社の<a href="http://alexzambelli.com/blog/">Alex Zambelli</a>氏が<a href="http://alexzambelli.com/blog/2008/09/09/h264-and-aac-support-coming-in-silverlight-vnext/">DXVAを使ったハードウェアアクセラレーションはサポートしないよ</a>と非公式に発言しているので、予想の範疇です。<br /><br />その他、QuickTime Plug-Inとの挙動の違いとしては、<br /><ul><li>(QuickTime形式ではない)同じ動画ファイルをQuickTime Plug-InとSilverlight 3 Beta 1で再生すると色味が多少違う</li><li>再生品質がキープできない程高解像度の映像だった場合に、QuickTime Playerはフレームを間引くが、Silverlight3は画面が固まって音が途切れる</li><li>ビットレートが高い映像をhttp経由で再生した場合に、再生バッファは十分溜まっているのに画面が1秒程度固まることがたまにある。<br /></li></ul>等の違いがありましたが、Silverlight 3 はまだBeta1ですので正式リリースでは変わっているかもしれません。<br /><br />最後に、何故 Silverlight 2用のアプリでSilverlight 3の新機能である(H.264/AAC).mp4が再生できるのか?という疑問を持った方もいらっしゃると思いますが、Silverlight 3 Beta 1 ランタイムは、<param>タグのminRuntimeVersionも、AppManifest.xamlのRuntimeVersionも無視して、新機能が常に使える状態になっているからというのが、現時点での予想です。<br />この件については、<span style="font-size:85%;">気が向いたら </span>項を改めてまた書いてみたいと思います。(了)KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-51097564099491221882009-02-23T18:03:00.003+09:002009-02-23T18:23:17.732+09:00あまり奇をてらった言葉をBlogのタイトルに使うべきではない(かもしれない)という話<div>先ほど、id:shi3zさんの、『<a href="http://d.hatena.ne.jp/shi3z/20090223/1235372694">テレビ朝日から「つれづれ~というブログタイトルが多いという客観的な証拠を今日中に示せ」と言われた</a>』 from <a href="http://d.hatena.ne.jp/shi3z/">Keep Crazy;shi3zの日記</a> を読んで、自分のBlogタイトル名で<a href="http://blogsearch.google.com/">Googleブログ検索</a>を試してみたら、あまり奇をてらった言葉をBlogのタイトルに使うべきではない(かもしれない)という面白い結果になりました。</div><div><br /></div><div><ul><li><a href="http://blogsearch.google.com/blogsearch?hl=ja&num=10&c2coff=1&ie=UTF-8&q=inblogtitle:"%E9%9B%91%E8%A8%98"+blogurl:http://kki-zakki.blogspot.com/&btnG=%E3%83%96%E3%83%AD%E3%82%B0%E6%A4%9C%E7%B4%A2&lr=">inblogtitle:"雑記" blogurl:http://kki-zakki.blogspot.com/ の検索結果</a> …… 9件<br /></li><li><a href="http://blogsearch.google.com/blogsearch?hl=ja&num=10&c2coff=1&ie=UTF-8&q=inblogtitle:"%E3%81%A3%E3%81%8D"+blogurl:http://kki-zakki.blogspot.com/&btnG=%E3%83%96%E3%83%AD%E3%82%B0%E6%A4%9C%E7%B4%A2&lr=">inblogtitle:"っき" blogurl:http://kki-zakki.blogspot.com/ の検索結果</a> …… 9件<br /></li><li><a href="http://blogsearch.google.com/blogsearch?hl=ja&num=10&c2coff=1&ie=UTF-8&q=inblogtitle:"%E3%81%A3%E3%81%8D%E9%9B%91%E8%A8%98"+blogurl:http://kki-zakki.blogspot.com/&btnG=%E3%83%96%E3%83%AD%E3%82%B0%E6%A4%9C%E7%B4%A2&lr=">inblogtitle:"っき雑記" blogurl:http://kki-zakki.blogspot.com/ の検索結果</a> …… 0件<br /></li></ul></div><div><br /></div><div>一目瞭然ですね。Blogのタイトルに "っき雑記" を指定して検索すると検索結果が0件になります。</div><div>私は検索エンジンの仕組みはよく知らないので理由は分かりませんが、ひょっとすると、Googleブログ検索は「っ」で始まるBlogのタイトルをBlogのタイトルとしては扱わないようにしているのかもしれません。</div><div><br /></div><div>私は、id:shi3zさんの<br /></div><div style="text-align: left;"><span class="Apple-style-span" style="font-style: italic;"><br /></span></div><div style="text-align: left;"><span class="Apple-style-span" style="font-style: italic;">「人の記憶に残っても「つれづれ」などのありふれた言葉をタイトルに使っていると、検索して見つけてもらえる可能性が低くなってしまうのでタイトルとして採用するべきではない」</span></div><div><br /></div><div>という主張はおっしゃる通りだろうと思っていますが、あまり奇をてらった言葉にするのも考えもののようですね。</div><div><br /></div><div>ちなみに「っき」というのは私が使っているハンドルネームで、昔、アーケードゲームのスコアネームにアルファベット3文字しか使えなかった時代に使っていた"KKI"をローマ字読みしたものです。</div><div><br /></div><div>SEO上不利(笑)なのかもしれませんが、それなりに愛着もありますのでタイトルはこのままにしておこうと思います。</div>KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-75269382772090684292009-01-09T00:41:00.003+09:002009-01-09T01:25:12.611+09:00「空から女の子が降ってきたらどうすればいいのか?」を電話なんでも相談室に相談してみた先日、<a href="http://twitter.com/">Twitter</a>で「<a href="http://twitter.com/KKI/status/1098696224">今時、空から女の子が降ってきたくらいで困惑する読者はいないよね</a>」とつぶやいたあとで、実際にそんなことがあったらどうするのか何も考えてなかったことに気がついたので、せっかくだから市内にある『電話なんでも相談室』に質問してみることにした。電話をかけると、親切そうな感じのおじさんの相談員の人に繋がった。<br /><br /><span style="font-weight: bold;">相談員のおじさん</span>(以下、お)「お待たせしました。えーと、質問内容は『空から女の子が降ってきたらどうすればいいでしょうか?』ですね?」<br /><span style="font-weight: bold;">私</span>「はい」<br /><span style="font-weight: bold;">お</span>「うーん、それはとても危ないですね。」<br /><span style="font-weight: bold;">私</span>「え? 危ないんですか?」<br /><span style="font-weight: bold;">お</span>「はい、ですからその場合は周りに気をつけながら、すぐに地面に伏せて、じっと降ってくるのを待っててください。」<br /><span style="font-weight: bold;">私</span>「えーと、逃げなくていいんでしょうか?」<br /><span style="font-weight: bold;">お</span>「はい、逃げるより地面に伏せる方が安全です。もしまだ遠くに見えても、必ず逃げずに伏せてください。」<br /><span style="font-weight: bold;">私</span>「遠くでも伏せるんですか?」<br /><span style="font-weight: bold;">お</span>「はい、遠くでも伏せてください。降ってくるのは女の子なんですよね?」<br /><span style="font-weight: bold;">私</span>「え? あ、はい」<br /><span style="font-weight: bold;">お</span>「降ってくるのが女の子だと分かるのであれば、地面に落ちるまで時間の余裕はありません。」<br /><span style="font-weight: bold;">私</span>「はあ、なるほど」<br /><span style="font-weight: bold;">お</span>「それに、遠くに見えても、空に浮いてる物の大きさは分かりにくいので、実は案外近いことがあります。迷ったりしてる暇はありませんから、見かけたらすぐ地面に伏せてくださいね。」<br /><span style="font-weight: bold;">私</span>「は、はい」<br /><span style="font-weight: bold;">お</span>「それから地面に伏せる時はうつ伏せで、両足を揃えてピンと伸ばして、頭を抱えて、かかとを寝かせるようにしてください」<br /><span style="font-weight: bold;">私</span>「? かかとを寝かせるんですか?」<br /><span style="font-weight: bold;">お</span>「はい、かかとを寝かせてください。そうすると女の子に発見されにくくなります。」<br /><span style="font-weight: bold;">私</span>「え? 発見されちゃダメなんですか?」<br /><span style="font-weight: bold;">お</span>「はい、発見されちゃダメです。空から降ってくるような女の子に発見されてはいけません。」<br /><span style="font-weight: bold;">私</span>「はあ」<br /><span style="font-weight: bold;">お</span>「回答内容は以上です。これでよろしいでしょうか?」<br /><span style="font-weight: bold;">私</span>「え? あ、はい」<br /><span style="font-weight: bold;">お</span>「ご利用ありがとうございました。」<br /><br />電話はこれで終わったが、空から女の子が降ってきた後、うつ伏せで頭を抱えて両足を揃えてピンと伸ばし、かかとを寝かせて地面に伏せた状態の私は一体どうすればいいのか?という肝心な事を聞き忘れたことに気がついた。<br />今は、もう一度同じ電話番号に電話をかけてみるべきなのかどうかを真剣に悩んでいる。(了)<br /><br /><br /><br /><br />以上、<a href="http://q.hatena.ne.jp/1231366704">降臨賞</a>(はてなIDが無いので)<span style="font-weight: bold;">非公式</span>応募作品。KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-33961609196048022672008-12-13T03:45:00.003+09:002008-12-22T07:51:12.728+09:00LHa for Native Client (本編)<span style="color: rgb(255, 0, 0);">【警告】タイトルだけ見るとNative ClientでLHaが普通に動くように見えますが、実際には実用には堪えませんので、誤解のないようお願い致します。</span><br /><br />(このエントリーは「<a href="http://kki-zakki.blogspot.com/2008/12/lha-for-native-client.html">LHa for Native Client (準備編)</a>」の続きです。)<br /><br />Native Clientの発表から、もうかなり経ちますので話題の旬はとっくに過ぎてしまったのですが、今回は実際にLHa for Native Clientを実行するところまで、何とか話を進めてみたいと思います。<br /><br />ただし、LHa for Native Clientは、現時点でNative Clientがサポートしている3種類のOSの内、Mac OS XとLinuxで実行できることは確認しているのですが、Windowsでは今のところ実行に成功していません。<br /><br />その理由を説明するには、そもそもNative Clientで何ができて、何ができないのか?を先に説明する必要があります。<br />当初はWindows版でも普通に動くだろうと思っていたので、これは誤算でした。<br /><br />もう一つの誤算は、Native Clientが三日で飽きられてしまったためにx86ネイティブコードのsandbox以外の話を日本語で説明してくれるエントリに丸投げすることが出来なかったことです。<br />そのため、エントリがやたらと長くなってしまいましたが、どうか最後までおつきあいください。m(__)m<br /><br /><span style="font-weight: bold;">インブラウザモードとスタンダローンモード</span><br /><br />Native Client上で動作する実行コード、これをGoogleはNatie Client moduleと呼んでいますので、以下では単にmoduleと呼ぶことにしますが、moduleには2種類の実行方法があります。<br /><br />一つは、WebブラウザのNative Clientプラグイン上で実行する方法で、もう一つは、sel_ldrというローダを使うことで、単一のアプリケーションとして実行する方法です。<br /><br />Googleは、この2種類の実行方法については、今のところ特に用語を命名してはいないようですので、ここでは仮にインブラウザモードとスタンダローンモードと呼ぶことにします。<br /><br />moduleがスタンダローンモードとインブラウザモードの両方で実行可能な場合、moduleの実体である .nexeファイルは同じファイルで構いません。<br />基本的には同じ .nexeファイルが、Mac OS X、Linux、WindowsのどのOSでも動作します。<br /><br /><span style="font-weight: bold;">moduleの実行にはgccは不要<br /></span><br /><a href="http://journal.mycom.co.jp/news/2008/12/09/039/">「GCCベースのコンパイラを含んだブラウザ用プラグインの形で提供され」と書いてある紹介記事</a>を読んだために誤解している方がいらっしゃるようなので繰り返しますが、Native Clientは同一の.nexeファイルを複数のOSで実行可能なので、実行時にコンパイルは必要ありません。<br />Native Clientのパッケージに含まれているgccは、moduleのビルドに使われるだけです。<br /><br />尚、moduleの実行環境及び開発環境そのもののビルドには、それぞれのOS向けの開発環境が別途必要になりますが、各OS向けのNative Clientパッケージはビルド済みの実行環境及び開発環境を含んでいますので、moduleをビルドして実行するだけであれば、実行環境や開発環境のビルドは不要になっています。<br /><br />それから、Native Clientの実行条件として、Pythonが挙げられていますが、PythonはSconsというNative Clientの付属ツールや、スタンダローンモードのサンプルでsel_ldrを起動する際の補助に必要とされているだけで、Native Client moduleのビルドや実行に必須という訳ではないようです。<br /><br /><span style="font-weight: bold;">Native Client moduleの正体</span><br /><br />正体という単語に期待した人には申し訳ないのですが、moduleの正体は、単に32-bit LSBなELF形式の実行ファイルです。<br /><br />sandboxの実現のためにmoduleのビルドの際に実行コードに手を加えてはいますが、仕組み上、ELFのABIに違反するようなことはしていないはず(ここは自信なし、特にret)なので、moduleの実行をgdbで追いかけることもできるそうです。<br /><br />しかし、Mac OS XのアプリケーションはMach-OというELFとは異なる形式で、付属のgdbもMach-O形式にしか対応していませんので、仮想OS上でLinuxを起動して、Linux上のgdbを使うのが無難だと思います。<br /><br />それから、x86ネイティブコードのsandboxについては、<a href="http://d.hatena.ne.jp/amachang/20081209/1228804423">id:amachangさん</a>、<a href="http://steps.dodgson.org/?date=20081214">omoさん</a>、<a href="http://d.hatena.ne.jp/yaneurao/20081211">id:yaneuraoさん</a>の各エントリに詳細が書いてありますので、そちらを参照することを強くオススメします。<br /><br /><span style="font-weight: bold;">Native Clientにできること</span><br /><br />Native Clientは、newlibが提供する標準Cライブラリ、pthread、libSDLを使った音声と映像の出力機能の一部、NPAPIによるWebブラウザホストとの通信、IMCによるNative Client module同士の通信等が可能です。<br /><br />スタンダローンモードではホストになるWebブラウザが無いためにNPAPIを使えませんが、実行時にAPIを呼び出した時点でエラーが返るだけなので、場合分けで処理を切り替えることも可能になっています。<br /><br />スタンダローンモードで複数のmoduleを同時に実行してIMCで通信できるかどうかはちょっと分からないのですが、(私には難しそうですが)いつか試してみたいと思います。<br /><br />映像出力と音声出力の仕様については、映像はRGBA各16ビットのフレームバッファになっています。フルスクリーンモードはありません。<br />「フレームバッファのハンドルはやるから好きにしろ、後は知らん」という感じですね。<br /><br />音声は、44.1KHzまたは48KHzでステレオ、16ビットのリニアPCMを出力可能ですが、ヘッダのコメントによるとまだ多重再生はできないとのことなので、音声のMIXは自前で行う必要があります。<br /><br /><span style="font-weight: bold;">Native Clientにできないこと<br /></span><br /><br />Native Clientはまだバージョンが0.1ということもあって、使えるライブラリがほとんどありません。<br /><br />GUIコンポーネントの表示どころか、基本的な描画ライブラリもなく、フォント、文字列エンコーディングの変換、画像、音声、動画のデコーダ等は全て自前で何とかする必要があります。<br /><br />moduleは先に説明したようにELF形式なので、リンクできるライブラリもELF形式に限定され、Native Client向けにビルドしたライブラリである必要があります。<br />動的リンクはできないので、静的リンクのみです。<br /><br />ですから、もしNative Clientで、例えばMac OS XのOpenGLライブラリを使用したいのであれば、実行環境をビルドする時にリンクして、moduleから利用するためのAPIを追加しなければいけません。しかし、それは実行環境の独自ビルドになるので、実行環境も一緒に配布しない限り、他の人のNative Client環境では実行できません。<br />結局、OpenGLやOpenCLについては、Googleが対応しない限りどうにもならないという事です。<br /><br />Googleの今後の予定については何ともいえませんが、OpenGLやOpenCLを使えるようにするとセキュリティ上の安全性や安定性がOS側のドライバ頼みになってしまうので、見込みが薄いんじゃないかなーと個人的には思っています。あくまで個人的意見ですのであしからず。<br /><br /><span style="font-weight: bold;">ファイルI/Oの制限</span><br /><br />ファイルI/Oについては、GoogleのTechnical Paperを読むと、ファイルI/OとしてPOSIX標準ファイルI/Oを利用可能だが、インブラウザモードの場合は、Web上のコンテンツの読み込みに用いられ、ファイル出力はできず、statはファイルサイズしか取れないと書いてあります。<br />これはHTTPではディレクトリ上のファイルの一覧を普通は取れないことを考えれば当然の仕様だと思います。<br /><br />スタンダローンモードでもインブラウザモードの上記の制限を受けるために、クライアントPCのローカルファイルへのアクセスは基本的にできません。<br />(Native Clientがローカルファイルへのアクセスが自由に可能と説明している文章もあるようですが、それは何かの誤解だと思います。)<br /><br />しかし、LHaはファイルの圧縮と圧縮を実行するツールなので、ローカルファイルにアクセスできないと意味がありません。<br /><br />そこで、今回は、Native Clientに一つだけ用意されている抜け道を利用することにしました。スタンダローンモードのデバッグモードです。<br /><br /><span style="font-weight: bold;">デバッグモード</span><br /><br />デバッグモードはsel_ldrに-dというオプションをつけて実行することで有効になるモードですが、このモードを使うとPOSIX標準ファイルI/Oでローカルファイルにアクセスすることが可能になります。<br /><br />デバッグモードでもディレクトリエントリに対する操作はほとんど出来ませんが、ログ出力のために新規にファイルを作成したりバイナリファイルの読み書きを行う程度であれば何とかなります。<br /><br />しかし、Windows版のNative Clientだけ、何故かsel_ldrでデバッグモードを有効にできません。<br />各OSで、スタンダローンモードでearthサンプルを実行してみた方は気づいたと思いますが、Windowsの場合だけフレーム数の表示がないことから、標準出力もできないようです。<br />これが、最初にWindowsでは動作しないと書いた理由です。<br /><br /><span style="font-weight: bold;">LHaの移植</span><br /><br />今回のLHaの移植は、デバッグモードを利用しつつ、ディレクトリエントリが絡んだ部分を誤魔化す事で実現しています。<br /><br />具体的には、Mac OS X上で普通に./configureを実行してconfig.hを作成した後で、nacl-gccでコンパイルした時にどのヘッダが足りないかを確認しながら、config.hの中身を適宜修正し、nacl-gccのリンカでエラーが出る関数をdummy.cというファイルででっちあげるという方法を取りました。<br /><br />あくまで誤魔化しただけなので、ディレクトリ構造を持ったLZHファイルの作成や展開では問題が多々ありますし、実行権、シンボリックリンク、タイムスタンプ等も無視されます。最初に警告として実用には堪えないと書いたのはそのためです。<br /><br />Makefileの流用も検討はしたのですが、結局、nacl_build.shというシェルスクリプトを用意しました。<br />結果的に出来上がったの以下のパッチとバイナリ<br /><br />lha4nacl.patch<br />lha.nexe<br /><br />を<a href="http://demo-n.e-neta.jp/files/MacOSX/lha4nacl.tar.gz">lha4nacl.tar.gz</a>というファイルにしておきました。<br /><br />ビルド方法としては、Mac OS Xの場合、<a href="http://lha.sourceforge.jp/">LHa for UNIX</a>のソースを展開してから、上記のファイルも展開し、<br /><br />$ patch -p1 <lha4nacl.patch<br />(nacl_build.sh 内のNACLINSTALLPATHを適宜修正)<br />$ ./nacl_build.sh<br /><br />と実行すれば、src/lha.nexeが作成されるはずです。<br /><br />lha4nacl.patchを読めば分かりますが、元のソースには一切手を加えていません。移植性を考慮したコンソールアプリのソースなら、機能制限に目をつぶれば元ソースに手を加えなくてもそこそこ動いてしまうのがNaClの面白いところだと思います。<br /><br />以上、駆け足で説明しましたが、抜けているところは適宜修正していきたいと思います。<br />もし、何かありましたら、メールまたはKKI@Twitter等にご連絡ください。<br />おつきあいありがとうございました。m(__)m<br /><br /><span style="font-weight: bold;">【蛇足】"Native"な"Client module"</span><br /><br />Native Clientの登場直後から、Native ClientはGoogleのOSになるのではないか?という意見を見かけますが、私はそうは思いませんでした。<br /><br />というのは、GoogleがNative ClientのバイナリをNative Client Applicationではなく、Native Client moduleと一貫して呼称しているからです。<br /><br />Native Clientのパッケージの階層は、nacl/google_client/nativeclient となっていますが、Native Client moduleは、"Native Client"の"module"ではなく、Google Clientの"Native"な"Client module"なのではないでしょうか?<br /><br />つまり、Native Client moduleはあくまで、NativeではないClient moduleと共にGoogle Clientを構成するmoduleの一つであり、最終的には単体のアプリケーションとして動作させる利用方法は減っていくのではないか?ということです。<br /><br />Google Clientがどのような物かはまだ分かりませんが 将来的には、例えばGoogle DocumentのエンジンがNative Client moduleになったりするのではないかと私は考えています。KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-17108057694027158292008-12-13T00:47:00.007+09:002008-12-13T03:04:11.483+09:00LHa for Native Client (準備編)<span style="color: rgb(255, 0, 0);">【警告】タイトルだけ見るとNative ClientでLHaが普通に動くように見えますが、実際には実用には堪えませんので、誤解のないようお願い致します。</span><br /><br />Googleの<a href="http://code.google.com/p/nativeclient/">Native Client</a>のスタンダローン版のデバッグモードで<a href="http://lha.sourceforge.jp/">LHa for UNIX (autoconf版)</a>を動かしてみたのでメモ。<br /><br />ウチの環境は、iMac(24-inch, Early 2008) 3.06GHzモデルなので、<a href="http://d.hatena.ne.jp/amachang/">id:amachang</a>さんの「<a href="http://d.hatena.ne.jp/amachang/20081209/1228804423">ブラウザで X86 のマシン語を動かす! Google 謹製 Native Client をさっそく試してみる</a>」を参考にさせて頂きました。記事と違う点としては、<br /><ul><li>nacl_mac_0.1_9380090.tgzがリリースされていたので、そちらを利用</li><li>wgetはMac OS Xには標準でインストールされていないので、代わりにcurlを使って、<pre>curl -O http://nativeclient.googlecode.com/files/nacl_mac_0.1_9380090.tgz</pre>を実行</li><li>ファイルの展開先は、~/src<br /></li><li>サンプルのlifeは、<pre>$ cd ~/src/nacl/googleclient/native_client/tests/life<br />$ ./run.py</pre>で実行</li><li>./sconsは、~/src/nacl/googleclient/native_client/ から実行<br /></li><li>ブラウザで開いたURLは、file:///Users/kki/src/nacl/googleclient/native_client/scons-out/nacl/staging/earth.html<br /></li><li>このURLで指定したファイルは、さっきまでの ~/src/nacl/googleclient/native_client/tests/earth ディレクトリのearth.htmlファイルではない事に注意。そちらのHTMLファイルを直接開くとearth.nexeファイルが同じディレクトリにないので、<blockquote>The Native Client plugin was unable to load</blockquote>というエラーが表示される。ここで少しハマった。</li><li>ブラウザ上でNative Clientモジュールを実行する時に、HTMLファイルをopenコマンドで開くと、file://localhost/... というURLになるが、この場合、<br /><blockquote>Load failed: NaCl module did not come from a whitelisted source.<br />Use a URL beginning with file://</blockquote>という警告ダイアログが表示され「(意訳)URLがfile://localhost/... になっているが、このURLは許可されていないので、file:///... にして開き直してくれ」と(何故か)怒られる。</li><li>testsディレクトリ以下にある、ブラウザで表示可能なサンプルのリストが(私の場合は)file:///Users/kki/src/nacl/googleclient/native_client/scons-out/nacl/staging/index.html で表示されるので、こっちを使うのがオススメ</li><li>add.nexeとdiff.nexeは、testsディレクトリ以下にadd、diffディレクトリを作成してその中で作成したが、今回は .nexeファイルがあるので、同じディレクトリ内のHTMLファイルをブラウザで直接指定しても問題ない</li></ul>等がありますが、これで id:amachangさんの記事の「文字列の diff を取る nexe を作ってみる」の項まで完了しました。<br /><br />さて、ここからが本題である LHa for Native Client の話なのですが、Native Clientのバージョンが新しくなってしまったので、その確認等が終わってから次のエントリーで書く事にします。KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-52703302070120896522008-12-08T04:24:00.006+09:002010-02-23T22:43:46.179+09:00MonoDevelop 2.0 AlphaのMac OS X版で日本語を表示する方法<div><a href="http://twitter.com/">Twitter</a>で<a href="http://twitter.com/atsushieno">@atsushieno</a>さんから、<a href="http://twitter.com/hayashih">@hayashih</a>さんが、<a href="http://monodevelop.com/Main_Page">MonoDevelop</a> 2.0 Alpha版のMac OS X版で日本語が化けて表示されて困っているという話を聞いたので調べてみたのですが、あまり良い方法ではない、というかむしろ最後の手段に近いのですが、</div><div><br /></div><div>/Library/Frameworks/Mono.Framework/Version/Current/etc/pango/pango.aliases</div><div><br /></div><div>というファイルを管理者権限で作成し、</div><div><br /></div><div>"Lucida Grande" = "Hiragino Kaku Gothic Pro"</div><div><br /></div><div>という行を書けば、とりあえず日本語が表示できることが分かりました。</div><div><br /></div><div>結局のところ、初期状態のMonoDevelop.appで日本語が化けてしまう「根本的な」原因は、</div><div><br /></div><div></div><blockquote><div>Mac OS X版の<a href="http://www.mono-project.com/Main_Page">Mono</a>が依存している<a href="http://www.pango.org/">Pango</a>ライブラリのpango-atsuiモジュールが、フォントファイルから表示可能なコードポイントの範囲を取得できないという理由で、全てのフォントファイルが全てのコードポイントのグリフを持っているという嘘の情報を作成し、Pangoがそれを信じてしまうので、フォントがフォールバックされないから。</div><div></div></blockquote><div><br /></div><div>ということになるのですが、この説明ではいくらなんでも不親切過ぎるので、まずは、Mac OS X版のMonoはどうやってフォントを表示しているのか?という話から始めたいと思います。</div><div><br /></div><div>Monoは、GTK#, WinForms, libgdiplus, Cocoa#, Moonlight, etc... と様々な方法で文字をレンダリングできますが、今回問題になっているMonoDevelop.appの日本語は GTK# を使っているはずです。</div><div><br /></div><div>GTK#は、簡単に言えば <a href="http://www.gtk.org/">GTK+2</a> のラッパーで、基本的にはOSの違いの影響を受けないようになっています。</div><div>しかし、Monoが利用するGTK+2の実体は、OSによって様々です。</div><div><br /></div><div>Mac OS X版の場合は、Monoの本体であり、/Library/Framework にインストールされる Mono.Framework内に、<a href="http://www.imendio.com/">Imendio社</a>の <a href="http://www.gtk-osx.org/">Gtk+ on OSX</a> というプロジェクトの成果(以下、gtk-osx)を同梱することで、<strike>.NETアプリケーション</strike>GTK#アプリケーションを、X11を起動せずに単独のMac OS Xアプリケーションとして起動し、GUIを表示する事ができます。</div><div><br /></div><div>尚、gtk-osx は、環境変数を設定する事で、従来のようにX11アプリケーションとして動作させる事も可能のようなのですが、私はそっちはまだ試していません。</div><div><br /></div><div>さて、GTK+2はテキストをレンダリングする際にPangoというライブラリを使う事になっていて、Mono.Frameworkのgtk-osxもPangoライブラリを自前で持っています。</div><div><br /></div><div>Pangoがテキストをレンダリングする処理をもう少し具体的に説明すると、</div><div><ol><li>UTF-8で符号化された文字列とレイアウトに関する情報を受け取る<br /></li><li>必要に応じて適切なレイアウトエンジンでレイアウトを決定し、バックエンドのフォントレンダリングシステムにグリフのレンダリングを指示する<br /></li><li>返ってきた結果を元に、テキスト全体をレンダリングした最終的な結果を返す<br /></li></ol></div><div>という流れになります。</div><div><br /></div><div>最近のPangoはバックエンドのフォントレンダリングシステムを<a href="http://www.cairographics.org/">Cairo</a>, Xft, FT2(<a href="http://www.freetype.org/">FreeType2</a>)の3種類から選択できます(core X font protocol は選択できなくなりました)が、Xftバックエンドと(何故かはよく知りませんが)FT2バックエンドはXサーバを必要とするので、「X11を使わずに」フォントをレンダリングするには、Cairoを使うしかありません。</div><div>ちなみに、Mono.Frameworkは、Cairoライブラリも自前で持っています。</div><div><br /></div><div>CairoはCairoで、フォントのラスタライズをバックエンドに丸投げしてしまうのですが、こちらも選択が可能で、FreeType, Win32, Quartzの3種類があります。</div><div><br /></div><div>FreeTypeは上記のとおりX11が必要ですし、Win32はWindowsのフォントラスタライザ、つまりGDIなのでMac OS Xでは当然使えませんから、結局「Mac OS X」で「X11を使わずに」フォントをラスタライズするには、Quartzフォントバックエンドを使うしかありません。Quartzは、Mac OS X 10.4から導入された、CoreTextフレームワークを使用します。<br /><br /></div><div>ここまでの話をまとめると、Mac OS X版のMonoでGTK#を使って多言語のテキストをレンダリングする場合の処理は、</div><div><br /></div><div><blockquote>MonoDevelop.app→Mono→GTK# → GTK+ 2(gtk-osx) → Pango → Cairo → CoreText<br /></blockquote></div><div><br /></div><div>という流れになります。</div><div><br /></div><div>上記の処理の中でテキストのレイアウトを決定するのは、先ほど述べたようにPangoです。</div><div><br /></div><div>テキストを、単なる文字の並びではなくテキストとしてレイアウトするには、テキスト内の個々の文字のグリフの情報が必要になりますが、その際に得られる情報の内容は、同じフォントファイルから得られるグリフであっても、ラスタライザに依存します。</div><div><br /></div><div>そのため、Pangoでフォント情報を管理する機能は、fontconfig, Win32, ATSUIの3種類のそれぞれに対応したモジュールに分かれています。</div><div>この中でATSUIを受け持つモジュールが、pango-atsuiモジュールです。</div><div><br /></div><div>しかし、現在のpango-atsuiモジュールは、ATSUIで使用されるフォントが描画可能なコードポイントの範囲を正しく取得する事ができません。</div><div><br /></div><div>何故かというと、ATSUIは元々単独で完結しているシステムなので、FreeTypeのようにフォントの詳細を得るためのAPIが存在しないからです。(この辺、ちょっと自信なし)</div><div><br /></div><div>だからと言って、FreeTypeを使って個々のフォントファイルから直接情報を得ようとしても、ATSUIに対して指定したフォントの実体となるフォントファイルのパスを知ってるのはATSUIだけで、それを外から知る(真っ当な)手段がありません。ちなみに、この問題についてはWindowsのGDIでも似た状況らしく、<a href="http://kikyou.info/diary/?200510#i10_1">吉里吉里の作者のW.Deeさんも苦労した</a>そうです。</div><div><br /></div><div>結局、pango-atsuiモジュールは、全フォントファイルが全てのコードポイントのグリフを持っているという嘘の情報をでっちあげるという方法をとってしまいました。</div><div><br /></div><div>ですから、gtkrcやpango.aliasesでフォントのリストを与えて、描画できない文字をリストの次のフォントで描画(この仕組みをフォントのフォールバックと言います)させようとしても、Pangoがフォント情報の管理にpango-atsuiモジュールを使っている限り、リストの先頭で指定したフォントが全てのコードポイントの文字を描画可能ということになっているので、リストの先頭で指定したフォントを常に使い続けてしまうのです。</div><div><br /></div><div>もう少し具体的な例で説明してみましょう。</div><div>Pangoに対して、Mac OS Xの欧文フォントである Lucida Grande で「あ」という文字を描画しろと指示した場合を考えてみます。</div><div>もしpango-atsuiモジュールが物理フォントで描画可能な文字の範囲を取得することができれば、PangoはLucida Grandeに「あ」という文字のグリフはない事が分かりますので、別の物理フォントにフォールバックすることができます。</div><div>しかし、Mono.Frameworkに含まれているPangoのpango-atsuiモジュールは、Lucida Grandeにも「あ」という文字のグリフがあるという嘘の情報を流し、Pangoはそれを信じてしまうために、フォールバックすることができません。</div><div><br /></div><div>pango-atsuiが今回の問題の根本的な原因であることを納得していただけたでしょうか?</div><div><br /></div><div>ちょっと長くなったので、この続きは次のエントリーに移して、</div><div><ul><li>以前のMonoDevelopでは有効だったgtcrcの書き換えが何故使えなくなったのか?<br /></li><li>現状のpango-atsuiの制限下で、Monoはどうすれば良かったのか?<br /></li></ul></div><div>の2点について考えてみたいと思います。</div><div><br /></div><div>……えーと、多分、今週中には何とか(汗</div><div><br /></div><div>(2008/12/08 07:15 追記) @atsushienoさんから、MonoのWinformsなアプリケーションはGTK+2に依存しないとの指摘があったので、.NETアプリケーションをGTK#アプリケーションに修正しました。<br /></div>KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com1tag:blogger.com,1999:blog-893061926882305131.post-12803953531350665482008-12-04T03:59:00.002+09:002008-12-04T04:33:35.384+09:00JavaFXって既にレガシーだよねwwwタイトルは釣りです。すみません。<br /><br />さて、12月2日と3日に東京で「Sun Tech Days 2008 in Tokyo」というイベントがあり、Twitterの方で会場にいる参加者の方々の実況を見たりしていたのですが、Silverlightユーザの端くれでJavaはほとんど知らない私から見て、JavaFXアプレットについて、よく分からないところが3点程あったので、以下に挙げてみます。<br /><br /><span class="Apple-style-span" style="font-weight: bold;">その1</span><br />Silverlightには全画面モードがあります。<br />このモードには色々な制限があって、例えば、<br /><ul><li>全画面モードへの移行にはイベントハンドラを使う必要があって、Silverlightアプリケーションの起動後に即全画面モードにはできない<br /></li><li>全画面モードは背景透過(Windowless)にはできない<br /></li><li>全画面モードに移行すると画面中央に警告が表示され、Escキーで全画面モードが解除できることと、Silverlightアプリケーションのホストのドメイン名が強制的に表示される<br /></li><li>全画面モードのキー入力には制限があって、通常の文字は入力できない<br /></li></ul>といった具合です。<br /><br /><div>これらの制限は、全画面モードでアプリケーションに好き勝手させると、本物そっくりの偽画面でユーザを騙してパスワードを盗むような悪質なアプリケーションが登場しかねないので、機能に制限を加える事で対策をしているというのが主な理由のようです。</div><div>これはSilverlightに限った話ではなく、AdobeのFlashの全画面モードにも同様の制限があります。<br /><br /></div><div>というか、むしろMicrosoftがFlashの全画面モードの制限仕様をパクったんじゃないの?なんて事は口が裂けても言いませんが、先月話題になったニコニコ動画の全画面モードにコメント欄が無い件も、上記の制限の影響を受けていたわけです。<br /><br />ただ、AdobeはFlash10で全画面モードで使用可能なキーをいくつか増やしていて、これはどうやら、Silverlightの全画面モードでは使えるが、Flashの全画面モードでは使えなかった一部のキーを追加したようです。<br />AdobeとMicrooftがお互いの仕様を意識しつつ、セキュリティを考慮しながら利便性も高めようとしている様子が伺えます。<br /><br />ここで質問ですが、JavaFXアプレットの全画面モードってどうなっているんでしょうか?</div><div><br /><span class="Apple-style-span" style="font-weight: bold;">その2</span><br />SilverlightのUIコンポーネントは、全てベクターベースでスケーラブルになっています。<br />これは本来、GPUの支援下で高解像度で10フィートUIを実現するような場合に有利な方式のはずです。<br />例えば、1900x1200ピクセルの画面で、64x64ピクセルのグラデーションがかかったチェックボックスを描くような状況を考えてみます。<br />チェックボックスをピクセルベースの画像として持つ場合、少なくとも未選択状態と選択状態の2種類の画像が必要で実際には他にも画像が必要でしょうが、ベクターベースであれば、描画命令のリストで済みデータの量も少なくなるはずです。<br /><br />しかし、MicrosoftはSilverlightをモバイル端末や車載端末のような低解像度のデバイスにも展開しようとしています。そのため、<br /><blockquote>「これだと、スケーラブルなUIの利点が活かしにくいと思うけど、どうなんだろう? もちろん、UIがスケーラブルだと拡大縮小のアニメーションが綺麗になるのは確かだけれど、そんなエフェクトのためにUIをスケーラブルにするのは、いくらRIAでもリッチ過ぎるんじゃないだろうか?」<br /></blockquote>等と考えていたのですが、最近になってHighDPIというキーワードを目にするようになって、<br /><blockquote>「あー、携帯端末の小さい画面でも将来的に解像度が縦横4倍くらいになったら、スケーラブルなUIの方が有利になるかもしれないし、Microsoftとしてはそれぐらい先を見越しておくべきだよね。AcrobatでPC画面上に紙を再現する事にこだわってるAdobeとしても、HighDPIは当然意識してるんだろうし、そういう研究開発もしてるんだろう。」</blockquote>と考えを改めました。<br /><br /><div>ここで質問ですが、JavaFXアプレットのUIってベクターベースなんでしょうか?</div></div><div><br /><span class="Apple-style-span" style="font-weight: bold;">その3</span><br />Silverlightには分離ストレージという機能があります。<br />分離ストレージを大雑把に説明すると、信頼できないアプリケーションがクライアント側でデータの永続記憶を必要とする場合に、ローカルストレージの代わりに提供される仮想的なファイルストレージということになります。<br />他の記憶手段、例えばCookieの場合、データの容量制限を別にしても、HTTPヘッダに常に全ての内容を載せる方式なので大量のデータには向きませんし、かといってWebサーバ側に永続記憶を持たせてしまうと、少なくともWebアプリケーションの起動時にクライアントにデータを転送し、終了前にクライアントが変更したデータをサーバ側に転送する必要があります。<br />データへの操作が、「画像のこの範囲にグラデーションをかける」のような単純なコマンドでで済む内はいいですが、大量のデータを全面的に修正するような状況、例えば何かの映像にクライアント側のローカルストレージ内の任意の画像を重ね合わせて表示するような話になると、さすがに無理が出てきます。</div><div><br /></div><div>分離ストレージはクライアント側の永続記憶で、Cookieのように毎回Webサーバに内容を送るような事はしないので、上記のような用途には特に向いています。(Webアプリケーションで映像を編集するのが現実的かどうかは別にしてですが)<br /><br />それから、分離ストレージは通常はアプリケーション別に管理され、ローカルストレージとは独立していますので、ローカルストレージへのアクセス権限がなくても利用できますし、他のアプリケーションからデータを保護する事もできます。容量については初期状態で1MBの容量制限があり、拡張が必要な場合にはユーザにダイアログで問い合わせる仕組みになっています。<br /><br /></div><div>Flashの方にはSharedObjectという機能があって、これが分離ストレージと大体同じ機能のようです。<br />今時、Webアプリケーションに、「PC内の貴方のデータ全てを好きにいじる許可を頂けますか? OK/Cancel」とか言われても困ってしまいますよね?<br /><br /><div>ここで質問ですが、JavaFXアプレットはこの辺の仕組みはどうなっているんでしょうか?</div></div><div><br /><br /></div><div><br />上記の3点、かなり気になってますので、詳細をご存じの方がいらっしゃいましたら、どうか教えてください。よろしくお願いします。m(__)m</div>KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-68198251813326822442008-11-02T21:34:00.005+09:002008-11-03T20:45:26.244+09:00Silverlight 2 for MobileはDLRをサポートしない?<a href="http://blog.sharplab.net/">SharpLab.</a>さんの「<a href="http://blog.sharplab.net/computer/cprograming/silverlight/1335/">Windows MobileとSilverlight 2絡みの話題について訂正・追補と落穂拾い</a>」に、<br /><blockquote>Silverlight2 for MobileではIronPythonやIronRubyを動かすための基盤であるDLRがサポートされないとのこと。MSはSilverlight2が バラバラになるのを避けたいと考えているから、と説明されていますが、よくわかりません。</blockquote>との記述があったので調べてみたのですが、<a href="http://blog.jimmy.schementi.com/">Jimmy Schementi</a>氏(MSのDLRチームのPM)の<a href="http://www.theregister.co.uk/2008/10/29/silverlight_mobile/comments/">元記事へのコメント</a>、<br /><blockquote>Clarifying DLR support<br />By Jimmy Schementi Posted Friday 31st October 2008 23:44 GMT<br />Is correct that Silverlight for Mobile does not support the DLR today, since the Reflection.Emit namespace is not in the .NET Compact Framework. However, I'm making changes to the Silverlight integration for IronRuby and IronPython to let them run in interpreted-mode, which will not depend on Reflection.Emit. Once that happens then applications that run in interpreted mode can run on Silverlight Mobile. This will be in the next release on <a href="http://codeplex.com/sdlsdk">http://codeplex.com/sdlsdk</a>.<br /></blockquote><br />と、<a href="http://twitter.com/jschementi">Twitterでのつぶやき</a>、<br /><blockquote><table class="doing" id="timeline" cellspacing="0"><tbody id="timeline_body"><tr id="status_981905919" class="hentry status"><td class="status-body"><div><span class="entry-content">@<a href="http://twitter.com/toddogasawara">toddogasawara</a> so it *should* work when/if the DLR interpreter doesn't depend on ref.emit </span> <span class="meta entry-meta"> <a href="http://twitter.com/jschementi/status/981905919" class="entry-date" rel="bookmark"><span class="published" title="2008-10-30T09:19:45+00:00">6:19 PM Oct 30th</span></a> <span>from <a href="http://www.twhirl.org/">twhirl</a></span> <a href="http://twitter.com/toddogasawara/status/981899728">in reply to toddogasawara</a> </span> </div> </td> <td class="actions"> <div> <a href="http://twitter.com/jschementi#" class="non-fav" id="status_star_984874429" title="favorite this update"> </a> <a href="http://twitter.com/home?status=@jschementi&in_reply_to_status_id=981905919" class="repl" title="reply to jschementi"> </a> </div> <br /></td> </tr> <tr id="status_981904719" class="hentry status"> <td class="status-body"> <div> <span class="entry-content"> @<a href="http://twitter.com/toddogasawara">toddogasawara</a> cf doesn't have ref.emit, which the DLR compiler depends on. However, the DLR interpreter *could* run on it </span> <span class="meta entry-meta"> <a href="http://twitter.com/jschementi/status/981904719" class="entry-date" rel="bookmark"><span class="published" title="2008-10-30T09:18:04+00:00">6:18 PM Oct 30th</span></a> <span>from <a href="http://www.twhirl.org/">twhirl</a></span> <a href="http://twitter.com/toddogasawara/status/981899728">in reply to toddogasawara</a> </span> </div> </td> <td class="actions"> <div> <a href="http://twitter.com/jschementi#" class="non-fav" id="status_star_984874429" title="favorite this update"> </a> <a href="http://twitter.com/home?status=@jschementi&in_reply_to_status_id=981904719" class="repl" title="reply to jschementi"> </a> </div> <br /></td> </tr> </tbody></table></blockquote>を読んだ限りでは、<br /><ul><li>.NET Compact Frameworkには Reflection.Emit名前空間がないので、Silverlight for MobileではDLRのフルサポートはできない。</li><li>ただし、DLRでRefrection.Emitが必須なのはCompilerなので、Interpreterは依存しないようにする事もできる。</li><li>これについては、<a href="http://codeplex.com/sdlsdk">Silverlight Dynamic Languages SDK</a>の次のリリース(0.5.0?)で対応するつもりだ。</li></ul>という話のようです。ちょっと気になるのは、<br /><ul><li>Silverlight 2のCoreCLRは .NET FrameworkのCLRとは独立しているので、Silverlight 2の実行環境は .NET Frameworkのインストールを必要としないが、Silverlight 2 for Mobileは .NET Compact Frameworkのインストールを必要とするのか?</li><li>Compilerを使えるDLRと使えないDLRでアセンブリが変わるのか? シナリオとしては、<br /><ol><li>Silverlight 2用のDLRとSilverlight 2 for Mobile用のDLRとして同一のアセンブリを利用できる</li><li>DLRのCompilerが別のアセンブリに分離される</li><li>Silverlight 2用のDLRとSilverlight 2 for Mobile用のDLRが別のバイナリになる</li></ol>の3択のはず。</li></ul>の2点でしょうか。<br /><br />.NET Frameworkは、DLL Hell問題を解決したのが長所らしいのですが、<a href="http://devhawk.net/2008/09/17/DLR+Namespace+Change+Fire+Drill.aspx">ExtensionAttribute Hell</a>の件といい、今回の件といい、実行環境に依存した問題が続くとちょっと不安になりますね。<br /><br />(追記 2008/11/03) <br />SharpLab.さんから、「<a href="http://blog.sharplab.net/computer/cprograming/silverlight/1341/">Silverlight 2 for Mobileは .NET Compact Frameworkのインストールが必須要件のようです。</a>」とのフォローがありました。<br />カメラ入力やスタンドアロンアプリケーションとしての実行等、将来のSilverlightで追加が予想されている機能をある意味先取りしているSilverlight 2 for Mobileが、独自のCoreCLRではなく、.NET Compact Framework CLRを採用するというのは、Silverlightの今後を予想する上で興味深いですし、採用を決定したのはSilverlight for Mobileのリリーススケジュールの遅延の原因なのか、結果なのか、それとも関係ないのか?という点でも考えさせられます。KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-46681906589031965702008-10-14T05:41:00.004+09:002008-10-14T06:06:46.579+09:00【ネタ】Silverlight Assembly ServerSilverlight 2 アプリケーションを開発している時の悩みの一つとして、Silverlightのランタイムパッケージには含まれない拡張ライブラリ(実体は、*.DLLファイルで個々のファイルはアセンブリと呼ばれます)のサイズがかなり大きく、Silverlightアプリケーションの本体である、XAPファイルのサイズが大きくなってしまう事が挙げられます。<br /><br />この問題は、実行時にDLRが必要なIronRubyやIronPythonを選択した場合に特に顕著で、C#で開発すればアセンブリの合計サイズが数KBで済むようなアプリケーションが、DLRと各言語用のランタイムライブラリで数百KB増加してしまいます。<br />現状のままでは、商用サイトのSilverlightアプリケーションではIronRubyやIronPythonは全く使われないだろうと考えられている原因の一つがこれです。(すみません、他の原因については今回は割愛します。)<br /><br />このような状況を産んでしまった原因としては、まず第一に、Silverlightチームが、Silverlightのランタイムパッケージに含まれる基本ライブラリのサイズを極力減らして、ランタイムパッケージのインストーラのサイズを減らし、ユーザがSilverlightを導入する敷居を下げようとしている事が挙げられます。<br /><br />DLRをSilverlightのランタイムパッケージに含めてくれれば……という声は、あちこちから挙がっているはずですが、DLRは1.0のリリース前でまだ安定していない事もあって、今のところその動きはないようです。<br /><br />第二に、Silverlightには、.NET FrameworkのGAC(Global Assembly Cache)に相当する機能が無い事が挙げられます。<br />GACは、複数のアプリケーションで共有が可能なアセンブリをアプリケーションフォルダの外にインストールして、システムが一元的に管理する機能(らしい)ですが、Silverlightにこの機能が無いのは、Silverlightチームが、「Silverlightはデスクトップアプリケーションよりも信頼性が低いWebアプリケーションを対象にしている」という理由で、アセンブリの共有については、慎重な態度を取っているからではないかと考えられます。あとは、無制限にアセンブリを登録できてしまうと、Silverlight for Mobileのようなディスクの空き容量が少ない環境で困るというのも理由の一つなのかもしれません。<br /><br />尚、GAC内のアセンブリが悪意を持ったアセンブリで改鼠されると大変な事になるので、これを防ぐためにアセンブリの署名という機能があります。<br />Silverlightのアセンブリのファイル構造は.NET Fremeworkのアセンブリのファイル構造と同じなので、Silverlightのアセンブリにも署名は可能です。実際、MS製のアセンブリには署名がついてます。<br /><br />ただ、Silverlightには実行時にアセンブリの署名をチェックする機能自体はあるようなのですが、拡張ライブラリの署名済みのアセンブリと未署名のアセンブリで実行時の権限に差があるという話は聞いた事がありません。(この部分、自信ないです。私の勉強不足だったらすみません)<br />ひょっとすると、DRMを使っている間に限り、未署名のアセンブリを弾くような事をしているのではないか?と個人的に予想しているのですが、実際どうなってるのかは知りません。<br /><br />閑話休題<br /><br />余計な話が長くなりましたが、XAPファイルのサイズが増えると実際に困るのは、主に、<br /><br />1.アプリケーションのロードに時間がかかる<br />2.XAPファイルを提供するWebサーバの転送量が増えてサーバの転送量の上限に引っかかる<br /><br />の2点です。この内、2を何とかしようというのが、今回の、Silverlight Assembly Serverというアイデアです。<br />1については分離ストレージからアセンブリをロードするというアイデアを考えているのですが、これは別の機会に紹介します。<br /><br />さて、Silverlight Assembly Serverとは要するに、<br /><br />「誰かがcrossdomain.xmlがフルオープンのWebサーバを立てて、どこかのSilverlightアプリケーションが必要なアセンブリのリストを厳密名をつけて要求したら、それらのアセンブリが含まれるXAPファイルを返してくれるだけのサービスを作ればいいんじゃね?」<br /><br />という話です。これだけです。<br /><br />サービスの負荷については、XAPファイルが単なるZIPファイルである事を利用し、<br /><br />・アセンブリはZIP圧縮した状態のバイナリデータを用意しておく<br />・XAPファイルに同梱するAppManifest.xamlファイルは要求に応じて内容が変化するがファイルサイズは大した事がないので、圧縮は「しない」<br /><br />とする事で、最終的に、ZIPヘッダ、未圧縮のAppManifest.xaml、圧縮済みの個々のアセンブリを連結して返す「だけ」にしてしまえば、極力抑えられるのではないか?と考えています。<br /><br />残る問題は、このサービスを提供するサーバが、サービスを利用するSilverlightアプリケーションが置いてあるサーバよりも回線が太く、安定していないとあまり意味がないという点ですが、これについては、<br /><br />「Microsoftにはそういうサービスの提供を期待できそうにないけど、Google使えば余裕じゃね?」<br /><br />という現実的な解決案がありますので、どなたか、ぜひ一度ご検討をよろしくお願い致します。m(__)mKKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-6738440655651944032008-10-07T05:29:00.003+09:002008-10-14T06:07:21.578+09:00PDC2008で発表されるSilverlightの最新動向の予想2008年10月26日(日)~30日(木)、米国ロサンゼルスで Microsoft Professional Developers Conference 2008(長いので、PDC2008と略されます) という、Windows開発者向けのカンファレンスが開催されるそうです。<br /><br />私は今まで自発的な興味は全く無かったので、どのようなイベントなのかはよく知らないのですが、きっとPDCというのはAppleのWWDCのようなお祭り騒ぎで、日本では有志が基調講演を同時通訳で実況しながらユーザー同士で檀上の発言にツッコミを入れるのを徹夜覚悟で待ちつつ、滅多に話せない人々とチャットで昔話に花を咲かせるような、それはそれは楽しいイベントなのでしょう……多分。<br /><br />さて、PDC2008は、Microsoft社が現在開発中の最新技術を公開したり発表する場なのだそうで、当然、Silverlightの最新動向についても、一般向けの発表が色々あるはずです。私はSilverlightについては守秘義務契約に縛られるような内容は一切知らないという強み(?)があるので、時期的にまだ少し早いですが、PDC2008で発表されそうな内容を予想してみる事にしました。<br />以下、予想です。<br /><ul><li>Silverlight 2の正式リリース</li><li>2008年の年末までにリリースされる、Silverlight 2の追加コンポーネント集</li><li>(Silverlight 3ではなく) Silverlight 2.1 の概要</li><li>DLR(Dynamic Language Runtime) に対応した VBx のパブリックベータ版の大まかなリリース日程</li><li>Silverlight 1.0 for Mobile の正式リリースと Silverlight 2 for Mobile のパブリックベータ版のリリース</li><li>PlayReadyによってSilverlightアプリケーション本体を保護した動画配信サービスが他社から提供</li></ul>……あまり面白みの無い予想ですね、すみません。KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0tag:blogger.com,1999:blog-893061926882305131.post-75538834997458875662008-10-02T11:13:00.003+09:002008-10-02T11:27:20.468+09:00雑記はじめました雑記をはじめてみる事にしました。<br /><br />Silverlight方面の話でTwitterの140字制限に収まらない話が増えてきたのですが、「連投うざいだろうなー」とか、「人様のblogのコメントで二十数行とか長すぎるよなー」とか悩んでるうちに、「こういう内容は雑記に書くべきだよね」という結論になりました。<br /><br />どうして日記じゃないのか?はお察しください。KKIhttp://www.blogger.com/profile/08122188032447745857noreply@blogger.com0