2009年11月12日木曜日

「世界の新着動画」で紹介されたくない投稿者の対策法を考えてみた

ニコニコ動画で最近始まった「世界の新着動画」で、今日になって、ようやく「生放送での引用」可否選択が追加されましたが、今までも色々あった「世界の新着動画」なので、視聴者としては今日の放送で何が起こるかちょっと心配です。

そこで、思いつく限りで最もマズい状況を想定して、投稿者側の対策法について色々と考えてみました。ただし私自身は投稿者ではないので、勘違いまたは誤解している部分もあると思います。何がありましたらツッコミをよろしくお願いいたします。
それから、これは2009年11月12日の放送開始前の素人予想にすぎないことにご注意ください。
下記の内容はあくまで可能性ですので信じるか信じないかはご自由にどうぞ。
もし内容が間違っていても責任は取れませんのであしからず。


1.「生放送での引用」可否選択の追加に伴い、「世界の新着動画」で紹介される動画の不足を解消するため、動画数の多いカテゴリでは紹介の対象となる動画の範囲を24時間にしている可能性があります。
ただし、範囲がどの時刻から始まるのかは、まだ判明していません。
「世界の新着動画」での紹介を拒否したい投稿者の方は、現時点では昨日(11/11)以降の日付がついている動画で「生放送での引用」を拒否にしておくことをオススメします。

尚、登録動画数の少ないカテゴリ(例:政治カテゴリ)では、紹介される動画の不足を解消するために、紹介範囲に「新着順で○○位以内」という別ルールを適用し、結果として紹介される動画の日付の範囲がさらに拡大する可能性があります。
今までの放送では、紹介される動画のリストで最後の動画を放送した後は、
  • 放送終了時刻前でも放送を終了する
  • リストの最初からまた放送する
の2つのパターンがあるようですが、本日以降どちらになるのか、または別のパターンになるのかは一切不明です。

2.紹介される動画の候補の抽出と「生放送での引用」の可否のチェックはどの時刻に行われているのかは不明で、この2つは別の時刻にチェックされている可能性があります。
そのため、放送の直前に「生放送での引用」を拒否にした場合、
  • 紹介されない
  • 紹介されないが、放送中に再生動画の読み込みだけ行われて再生数だけ上がる
  • 放送開始時点の紹介可否を無視して紹介される
のどれになるかはまだ分かっていません。
ですから、どうしても紹介を拒否したいのであれば、なるべく早めに「生放送での引用」で拒否しておくことをオススメします。

尚、本日の時刻がついた動画は、今日は紹介されなくても明日紹介される可能性がありますので、ユーザー生放送で引用されないのは困るという理由で、「生放送での引用」の拒否を後から解除したい場合は、「世界の新着動画」の変更内容が分かるまでは、動画の日付の翌々日に解除した方がいいと思われます。

3.本日の複数カテゴリ導入に伴い「世界の新着動画」において「○○カテゴリでやれ」に相当するコメントがつけられる可能性が増しています。(注:実際には「でやれ」はNGワード)
例えば、「今までなら「歌ってみた」カテゴリだがバックコーラスに初音ミクがいるからいいだろう」と安易に「VOCALOID」タグをつけてしまうと、「【世界の新着動画】アイマス・東方・ボカロカテゴリ」で紹介されて、「【世界の新着動画】やってみたカテゴリ」で紹介されるよりも更に荒れたコメントがつく結果になりかねません。
カテゴリタグはくれぐれも慎重につけるようにしてください。
【追記 2009/11/12 19:55】ニコニコ動画開発総指揮の戀塚さんのTwitterでの発言によれば、「世界の新着動画のピックアップ対象は、「カテゴリ」マークが付いてる(カテゴリ選択された)カテゴリね」とのことです。

4.本日の「生放送での引用」の追加によって紹介を拒否することができるようになったために、「紹介を拒否しなかったんだから何を言っても構わない」と勘違いした一部の視聴者が、今までよりもヒドいコメントをつける事態が懸念されます。
11/5に元動画に反映されるコメントの数が調整されたのと、「世界の新着動画」におけるNGワードが日々増やされていることから、元動画に反映されるコメントの内容は、開始直後よりは大分マシになったのではないかと思われますが、投稿者の方は今までに紹介された動画の結果を見て「これくらいのコメントなら大したことない」と油断しないようにしてください。

尚、「世界の新着動画」の会場である「試写室」は500人単位で会場が区切られていて、基本的には入場した順に割り振られるようになっています。
そのため、放送の途中からしか入場したことがない投稿者の方は、コメントの少なさに「こんなに少ないのか」と拍子抜けすることがあるようですので、特に注意してください。

5.「生放送での引用」を拒否した場合、「世界の新着動画」で紹介されなくなるのと同時に、「ユーザ生放送」での紹介もできなくなる仕様になっているそうなので、ある動画が「生放送での引用」で「世界の新着動画」での紹介を拒否したかどうかは、ユーザー生放送で再生を試してみれば分かってしまうのではないか?と思われます。
(この辺り、ちょっとよく分かってないので事情をご存知の方は教えて頂けると助かります。)
投稿者の方は、「生放送での引用」で拒否しても、他の人には分からないとは思わないようにした方がよいと思われます。

以上

上記の内容については、いくらなんでも心配し過ぎという意見はもちろんあるでしょうし、確かにそう思うのですが、今日の変更内容についてはまだ情報が乏しいので、紹介を拒否するための自衛策としては過剰な対策法を提示せざるを得ませんでした。

運営側の方々には、投稿者の不安を解消するためにも、「世界の新着動画」で紹介される動画の範囲については、ユーザの努力による調査をあまりあてにせず、多少は情報を公開することを切に要望します。

2009年9月30日水曜日

WMV配信サイトとMacとSilverlightの話 (その2)

もたもたしている内に前回から一ヶ月程経過してしまいましたが、前回からの続きです。

ポイント5:Silverlight版再生プレイヤーではサポートできない機能がある

SilverlightはWMV形式の動画の再生をサポートしていますが、WMV形式と一口に言っても、その種類や配信方法は多種多様です。

しかし、SilverlightはWindows Media Playerや、Webブラウザ向けのWindows Media Player プラグインが再生可能なWMV形式の動画の全てをサポートしているわけではありません。

その理由としては、Silverlightは開発当初からランタイムパッケージのファイルサイズを極力抑えるという目標があったので機能を削らざるを得なかった、あるいはSilverlightは将来的に携帯端末のハードウェアデコーダをサポートする予定があるのでそちらに合わせて機能を絞った等の理由が考えられますが、これらは一部外者の単なる想像に過ぎません。

ともあれ、WMV配信サイトは幸いなことに、WMV形式の種類に関しては、唯一の例外である音声のデュアルモノを除けば従来からSilverlightでの再生が可能な形式を使っていましたので、その点ではほとんど問題はありません。
細かい話をすれば、SilverlightではWMVファイル本体に埋め込まれたメタデータ、例えば動画のタイトル、製作者名や著作権表記を読み込めないという制限はあるのですが、これは別途、Windows Media向けのメタファイルである.ASXファイルに記述すれば済む話です。

しかし、配信手法に関しては、SilverlightがHTTPプロトコルでのメディア配信にしか対応していないために、今まで提供していた非HTTPのメディア配信プロトコルやダウンロードコンテンツと呼ばれる配信方法を見送らざるを得ませんでした。
ここでは、これらの機能の概要を順に説明します。

1. デュアルモノ

Silverlightで使える音声コーデックとしては、1.0と2で利用可能なMP3とWMA、3で新しく追加されたAACがあります。これらのコーデックは全て、一つのステレオ音声のストリームの左右2つのチャネルに別の音声を割り当てて、2つのモノラル音声として扱うデュアルモノという機能を仕様上持っています。
具体的な用途としては、アナログTV放送の二ヶ国語放送や副音声付放送のような使い方ができます。

実際には、動画の配信で二ヶ国語や副音声をサポートしている例は滅多にないのですが、講演や演説の中継で日本語と英語の両方の音声をサポートするようなケースがたまにあります。
最近では、MicrsoftのReMIX Tokyo 09というイベントのキーノート中継が日本語と英語の音声をサポートしようとしていました。

しかし、Silverlightではデュアルモノをサポートしていませんし、デコード後の音声データをアプリケーションが取得する手段が提供されていないので、左右どちらかのチャネルのモノラル音声を左右両方のチャネルに流す手段がありません。

先のイベントでは苦肉の策として、左右に音を振るパン機能を使って、日本語音声の選択時には右スピーカーだけで日本語音声を流し、英語音声の選択時には左スピーカーだけで英語を流すという方法をとっていました。
スピーカーならまだいいのですが、ヘッドフォンで音声が片方からしか流れないのはなかなかツラい物があります。

Silverlightを実際に開発しているのはアメリカですが、二ヶ国語音声のサポートについては、日本や他の国から積極的に提案しないと採用は難しそうです。二ヶ国語音声をデュアルモノを使わずに実現する方法としては、複数の音声ストリームとその切り替えをサポートするような方法も考えられます。

MSKK(Microsoftの日本法人)の中の人には、今後のキーノート中継のためにも、ぜひ本家に対して何らかの提案を行って頂きたいと思います。

2. 非HTTPのメディア配信プロトコル

プロトコルとは、簡単に説明するとデータを送受信する手続きのことです。

プロトコルの種類はうんざりする程多いので、国際標準化されたプロトコルをインターネット向けに限定しても、辞典が作れるぐらいの種類があります。
しかし、最近のWebサービスではプロクシサーバを越えてサービスを提供したいという事情から、目的や用途を問わず、HTTPのみをプロトコルとして利用しようとする強い風潮があり、Silverlightもその例外ではありません。

ただ、昔は、まだHTTPのバージョンが古く、今ならほとんどの環境で使えるいくつかの機能が欠けていたこともあって、サービスの目的や用途に応じて専用のプロトコルを利用するのが一般的でした。

Microsoft(以下MS)社製のストリーミングメディアサーバである、Windows Media Serviceも、古くから使われているサーバですので、RTSP (Real Time Streaming Protocol)やMMS (Microsoft Media Services)等の、メディア配信用の専用プロトコルが既定のプロトコルになっています。

正直に言えば、私はRTSPとMMSの細かい違いは知らないのですが、昔はMS社が開発した独自のプロトコルであるMMSを使っていたものの、ベンダー独自仕様を避ける世の中の流れを受けて、Windows Media 9以降は(主にDRM方面でのMS社独自の拡張の追加はあるものの)国際標準規格であるRTSPを既定のプロトコルとして利用するようになったという事情があるようです。

結局、現在のWindows Media Serviceは、既定のプロトコルとしてはRTSPを用い、RTSPには対応していない古いクライアントに対してはMMSで試してみて、それでもダメなら、いくつかの機能制限はあるものの、HTTP(とその亜種)を使用するという処理が自動的に実行されるようになっています。

尚、上記の処理をMicrosoft社はプロトコルロールオーバーと呼んでいるので、以下ではそう呼ぶことにします。

さて、上述したいくつかの機能制限の話ですが、具体的には、ライブ配信、マルチビットレート(MBR)、マルチキャストの3つが挙げられます。

2-1. ライブ配信

Winows Media Serviceは、蓄積された映像を配信するオンデマンド配信と、生中継の映像を配信するライブ配信の2つの機能をもっているのですが、プロトコルとしてHTTPを使う場合は、ライブ配信には対応していません。(ちょっと自信なし)

Silverlightが対応しているプロトコルは基本的にHTTPだけなので、プロトコルロールオーバーを使って、コンテンツ配信サーバは変えずに再生ができるようになっているのですが、映画やTV放送のような既に存在する映像のオンデマンド配信はできても生中継のライブ配信はできません。

残念ながら、Windows Media Service(あるいはその業務版?)を使用している既存のWMV配信サイトでは、当分の間は、ライブ配信については対象をWindows Media Playerのみとし、Silverlightは対応外ということになりそうです。
先ほどのReMIX Tokyo 09では、Windows Media Serviceではないサーバを使ってSilverlightでのライブ配信を実現していますが、その話はちょっと後回しにさせてください。(^^;)


【訂正】Windows Media ServiceでもSilverlight向けにライブ配信は可能とのことです。Live Smooth Streamingが登場するまでは、Smooth Streamingでライブ配信はできなかったという話を、Silverlightでライブ配信はできなかったという話と誤解していました。お詫びして訂正します。(2009/10/06)

2-2. マルチビットレート

Windows Media Serviceには、マルチビットレート(MBR)という機能があります。
マルチビットレートのビットレートとは一秒間に送れるデータ量の単位を指します。

最近流行のHD映像は今までの映像よりも解像度が高いので、それに伴ってデータ量も増え、結果としてビットレートも高くなるので、速い回線速度を必要とします。

しかし、ユーザ側の回線環境は様々ですし、配信中に状況が変化することも多々あります。回線が細くなって映像に必要なビットレートを保てなくなると、結果として映像がガクガクになりますし、音声も乱れてしまいます。

マルチビットレートはこれを解決するために、異なるビットレートでエンコードした複数の映像データを事前に用意しておいて、再生プレイヤー側の状況に応じて適切なビットレートのデータを選択し、それに切り替えて配信する仕組みです。

ShowTime をWindowsで視聴した経験がある方の中には、高画質で映像を再生している時に、映像がボケボケの低画質になったり、静止画像が数秒に一度程度更新されたり、画面が暗くなったまま音声だけ流れる状態になった経験がある方がいらっしゃると思いますが、これがマルチビットレートの結果です。

細かい話をすると、実際にはマルチビットレート以外にもクライアント側で回線状況の悪化に対応する技術も使われているのですが、話が長くなるので今回は省略させてください。m(__)m

ShowTimeでは高画質と標準画質の2つのビットレートの動画を再生前に選択することはできるのですが、再生中にこの2つを切り替えることはできないので、慎重に選ぶ必要があります。

2-3. マルチキャスト

マルチキャストにはいくつか種類があるのですが、基本的には誰かが送りたいデータを全ユーザに送り、必要なユーザだけがそれを受け取る仕組みということになります。
しかし、その仕組み上、送られるデータが同一である必要がありますので、ライブ配信向けの技術ということになります。
オンデマンド配信の場合は、例え一つの映像しか流さなかったとしても、同一時刻に再生されている画面は視聴しているユーザによって変わりますので、マルチキャストができないということです。
現在のところ、Silverlightはマルチキャストに対応していません。

3. ダウンロードコンテンツ

いわゆるダウンロードコンテンツとは、映像データをストリーミングによってネットから流し続けるのではなく、一度動画ファイルをダウンロードして、オフライン状態で視聴するサービスです。

そのためにはクライアントPCに、映像の全データを保存しておく必要があるのですが、Silverlightはセキュリティ上の都合から、クライアントPCのローカルなファイルへのアクセスが大幅に制限されています。

ほぼ唯一の例外として分離ストレージという領域を利用することはできるのですが、これはユーザのホームディレクトリ以下の特定の場所に隔離されていますので、ファイルサイズの大きい動画データの全てを常に同じ場所に保存するしかなく、ファイル移動も簡単にはできないというデメリットがあります。

Windows Media Playerが提供されていないMac OS Xの様なOSや、ネットワークに常時接続可能とは限らないモバイル端末のような環境でもダウンロードコンテンツを再生可能にするための何らかの方策を考えて欲しいものです。

ポイント6:Silverlightのメディアエンジンはエラー耐性が低い

Silverlightで動画や音声を再生するソフトウェアをメディアエンジンと呼んでいるのですが、Silverlightは、これをWindows Media Playerとは別に、自前で持っています。

機能はほとんど被っているので無駄なようにも見えますが、SilverlightはMac OS X等Windows以外の環境でも実行されるのでメディアエンジンを統一したかったのかもしれませんし、レガシーなコーデックもサポートしていてたまにセキュリティ的な脆弱性が発見されるフルスペックのメディアデコーダの使用を避けて、一から必要最低限のデコーダを作成することで、セキュリティを高めたいという目的があったのかもしれません。

さて、動画を視聴している時間が長い方はご存知だと思いますが、映像の中に緑やピンクの四角を見たことはありませんでしょうか?

これはブロックノイズと呼ばれるノイズの一種で、大抵は映像データのエラーが原因です。
Windows Media PlayerやWebブラウザ向けのWindows Media Player Pluginであればエラーに耐性があるので、画面が多少乱れはするもののそのまま再生が続行されるのですが、SilverlightでこのようなWMVファイルを再生した場合、エラーが発生した時点で問答無用で再生を終了してしまいます。
これはSilverlightのメディアエンジンのエラー耐性が低いからであると考えられます。

Silverlightのメディアエンジンのエラー耐性が低いことで発生しうる問題は、主に3つあります。

1つめは、WMVファイルを単純に複数のファイルに分割して複数のWMVファイルにして再生する場合です。
この場合、分割された2番目以降のファイルを最初から再生しようとしても全く再生されません。
ただ、正規のWMV配信サービスでこのようなデータが配信されることは基本的にはありえません。
強いて言えば、WMV以外の映像形式の話になりますが、FlashでH.264/AAC形式で提供されている動画配信サービスをSilverlightに移植する場合に、問題になるぐらいでしょうか。

Flashの動画配信サービスでは、HTTPを使ったプログレッシブダウンロードのいくつかの欠点を補うために、サーバ上の単一の動画ファイルを、クライアントからは、単純に分割された複数のファイルとして見えるように見せかけて動画のシークを早める技術(正式名称は知りません)を使っている事例があります。
他には、一つの映像を映像の仕様上は分断してはいけない箇所で分断して別々の映像として配信している事例もあるようです。先日の大臣就任会見の映像で、このような映像を見かけました。

Flashの動画デコーダはエラー耐性があるので、このようなファイルであっても最初は画面が乱れるものの何とか再生できてしまうのですが、Silverlightでは、サーバ側で独立した複数の動画ファイルを単一の動画ファイルとして正しくなるように辻褄を合わせない限り再生できないことになります。

エラー耐性の低さが問題になるケースの2つめはデータの転送経路にノイズが多い経路が含まれていたために、動画データが意図せずにほんの少しだけ壊れていた場合です。

これが実際に問題になるのは、生放送をライブ配信して、複数の離れた中継地点から現場中継するような状況です。

この場合、カメラから電波で映像を飛ばすことになると思われますが、電波はノイズが多い媒体なので中継中に画像が乱れることがあるのはよくご存じだと思います。
先日のテレビで中継していた日食の映像で、画面が停まったり多少ノイズが発生するような映像が流れることがありましたが、Silverlightの場合は再生自体が終了することになります。

これを防ぐ方法としてはエラーの混じった映像データを、再度エラーがない映像としてエンコードし直すような方法が考えられますが、再エンコードは一般的に画質が落ちますし、エラーのある映像データをピンポイントで修正するようなソフトは今のところ見たことがありません。

さて、エラー耐性の低さが問題になるケースの3つめは、非MS製のエンコーダがWMVとしては不正なデータを出力するケースです。

MS社製のエンコーダであれば、そのようなデータを出力することはないはずなのですが、世の中にはハードウェア、ソフトウェアを問わず、様々なWMVエンコーダがあり、残念ながら常に正しい映像データが出力されるとは限りません。

具体的にはWMV形式で提供されているゲームのデモムービーの一部でブロックノイズが発生する動画があり、Silverlightではそれ以降の映像が全く再生できないという事例がありました。
デモムービーは通常はWindows Media Playerを対象としていますから、多少のエラーはエラー補正によって解決されるために見逃されてしまうようなのですが、後で同じ映像データをSilverlightでも再生する必要が生じた場合に問題になってしまいます。

コンテンツを作成する方には、納品データがWMV形式の場合は、極力MS社で確認済みのエンコーダを使い、Silverlightでも再生可能かどうかをチェックすることをオススメしたいと思います。

(その3に続く)

2009年8月26日水曜日

WMV配信サイトとMacとSilverlightの話 (その1)

先週は、Microsoft Tech·Ed Japan 2009の開催、Snow Leopardの発売等、話題に事欠かない一週間でしたが、同じく先週の8月25日、動画配信サイトのShowTimeがついにMac OS X環境での視聴への対応を発表しました。翌日の26日には無料動画サイトのGyaOも、2009年秋に予定されているYahoo!動画との統合と同時にMac OS X環境で視聴可能になる旨を発表しています。

【公式ページ】
【関連記事】
それにしても、BB Watchと同じ記事を配信しているINTERNET Watchを含めても、このニュースを取り上げたニュースサイトが3つというのは少々寂しく感じられます。

というのは、Macユーザ(の一部)は、デジタル著作権管理(DRM)機能で保護された、Windows Media Video形式の動画を配信するサイト(以下「WMV配信サイト」とします)を正規に視聴する手段を、前世紀からずっと待ち続けていたからです。

2008年10月にSilverlight 2がリリースされたことで技術的には視聴が可能になったあとも、これに対応するWMV配信サイトがなかなか現れず、しびれを切らしていたのですが、これでようやく一つの節目を迎えたように思います。

その間の、Macユーザ(の一部)のMicrosoft社に対する積年の恨みつらみを書き連ねるとブログの容量が足りなくなってしまいますので、そこはさっくり省略して、今回はMacユーザの立場から、WMV配信サイトをMacで視聴するポイントと今後の予想について書いてみたいと思います。

WMV配信サイトをMacで視聴するポイント

ポイント1: PowerPC搭載のMacでは再生できない。
今回、WMV配信サイトの動画コンテンツがMac OS X環境で視聴できるようになったのは、Mac OS Xで動作可能なSilverlight版の動画再生プレイヤーが開発されたからです。

Silverlightは、現状 1.0/2/3の3種類がありますが、WMV配信サイトが著作権管理に使用している Windows Media DRM(WM DRM)に対応しているのは、Silverlight 2以降になっています。

しかし、PowerPC版のMac OS X向けに提供されているのは、Silverlight 1.0だけです。

その理由としては、Mac OS X版のSilverlight 2以降ではSilverlightランタイムの核であるCoreCLRのWindows版のバイナリを、Win32 APIをエミュレートするPlatform Adaptation Layer(PAL)というレイヤー上でほぼそのまま実行する仕組みになっていることが大きいのではないかと考えられます。

Windows版のCoreCLRのバイナリを非Intel製のCPUで実行するには、Win32 APIだけではなくCPUもエミュレートする必要があるので、パフォーマンスが足りなくなってしまうのではないか?というのがその理由です。

「結局は単にPowerPCなMacのシェアが低いからじゃね?」という、もっともな意見はさておき、PowerPC搭載のMacではWMV配信サイトを視聴できませんので、どうしてもMacで再生したい場合は、Intel Macを購入しなければなりません。

尚、CPUの種類については、動作条件として Core Duo 1.83GHz 以上となっていますが、これはSilverlight 2および3の動作条件と同じです。

Intel Macでこの条件を満たさないのは、2006年に出荷されたMac miniに搭載されていた Core Solo 1.5GHz と Core Duo 1.66MHz だけのはずですが、これらのMacでSilverlight 2をインストールしようとすると、CPUのチェックでエラーが発生するそうです。

ポイント2:Mac OS X 10.4.8より古いOSでは再生できない。
この件については、初代のIntel Macの時点でMac OS X 10.4.6がインストールされていて、無料アップデートで10.4.11までアップデートが可能なので上記の条件を満たしていれば特に問題ないはずです。

むしろ心配なのは、今月の28日に発売されたMac OS X 10.6(Snow Leopard)での動作です。
Silverlightは今のところ32ビット版しか提供されていないので、64ビットカーネルモードのSnow Leopardで何かしら問題が発生するのではないかと少し心配しています。

特に心配なのは、手元の Mac OS X 10.5.8 + Silverlight 3.0.40723.0 + Firefox 3.0.13/3.5.2 では
入力された先頭の文字が化けてしまう現象が発生している日本語入力関連ですが、今回ShowTimeから発表されたプレイヤーでは日本語入力はありませんでしたし、日程的にはMicrosoft社のSnow LeopardでのSilverlightのテストは既に終わっていないとおかしいはずですので、多分大丈夫だろうと信じることにします。

本当に信じてるかどうかは聞かないでください。(ぉぃ

ポイント3:全画面モードで視聴時にカクツクようであれば画面解像度を下げてみる
ShowTimeの現時点のプレイヤーはSilverlight 2アプリケーションであるために、Silverlight 3のGPUハードウェアアクセラレーション機能には対応していません。

Silverlight 2では元映像の拡大処理をCPUでしか実行できないので、その分CPUとバスに負担がかかります。この負担はCPUは遅いが画面解像度が高いMac(結構あります)で全画面表示する場合に顕著になります。

ShowTimeの動画コンテンツは640x480ピクセル以下のようですので、再生画面を表示する前に、Mac OS Xの「システム環境設定」の「ディスプレイ」で画面解像度を下げてから再生プレイヤー側で全画面モードにすることで、CPU負荷を多少は下げることができるようです。

もし、ShowTimeの動画再生プレイヤーがSilverlight 3アプリケーションになれば、全画面モードの場合に限り、動画の拡大処理をGPUハードウェアアクセラレーション機能を用いてGPU側で実行することが可能になるので、CPUとバスの負担を減らせます。ぜひ対応を検討していただきたいものです。

ただし、Silverlight 3は、Windows版/Mac OS X版を問わず、AvivoやPureVideoのようなGPUによる映像のデコード支援機能には対応していませんので、これ以上の負荷低減についてSilverlight 3の次のバージョン以降に注目するしかありません。

私個人はグラフィックドライバの安定性に対して根強い不信感を持っていますので、インターネット上の信頼性が低い映像ストリームをユーザの個別許可無しに直接GPUに流し込むことについてはかなり不安があるのですが、Microsoft社もライバルであるFlashの動向次第では踏み切らざるを得ないだろうなーぐらいに考えています。

尚、Windows版のSilverlight 3では非全画面モードでもGPUハードウェアアクセラレーションが有効になるのに、Mac OS X版のSilverlight 3では有効にならない理由ははっきりとは分かりません。

Microsoft社はこの制限を、Mac OS XのWebブラウザプラグインのモデルに起因する制限であると主張しているようなのですが、いやそんなことはないという意見もあるようで、ちょっと判断がつきませんでした。

(その2に続く)

2009年5月31日日曜日

要するに三田さんの考えるフェアユースってこういうこと?

三田「お金を払わなきゃフェアじゃない。フェアユースじゃない。」

問「お金の問題なんですか?」

三田「金銭的なインセンティブは本質的な問題ではない。重要なのは作家へのリスペクトだ。」

問「なるほど、金銭以外にもリスペクトする方法があるってことですね。」

三田「お金を払わなきゃフェアじゃない。フェアユースじゃない。」

(以下、繰り返し)

2009年4月1日水曜日

Silverlight 3で追加されたaglimitパラメータによる機能制限はSilverlight広告への布石?

【注意】aglimitはエイプリルフールのネタで実際には存在しませんのであしからず。(追記 2009/4/3)

●はじめに

先月発表された、Silverlight 3 Beta 1でちょっと面白い機能を見つけました。

HTMLからSilverlight3アプリケーションを呼び出す時は、<object>タグを使用するのですが、その内部で、<params>タグを使って指定するパラメータにaglimitというパラメータが追加されているのです。
まずはサンプルを挙げてみます。
1: <object data="data:application/x-silverlight-2," type="application/x-silverlight-2">
2: <param name="minRuntimeVersion" value="3.0.40307.0" />
3: <param name="aglimit" value="audio+movie" />
4: ...
5: <object>

上記の value="audio+movie"の部分で、Silverlightアプリケーションでの動画や音声の再生が禁止されます。
ちなみに、agは銀の元素記号で、Silverlightを指しています。
Silverlight関連で、agを接頭辞に持つ名前が色々あるのはそのためです。(例:agcore.dll、AgDLR)

ついでですが、Silverlight 3 Beta 1で作成したアプリケーションを呼び出す<object>タグの使い方については、@matarilloさんの、「ユーザーがSilverlight 3ベータ版をインストールするときの挙動」が必読です。少なくともSilverlight 3アプリケーションを公開するかもしれない人は全員読むべきだと思います。

●なぜaglimitが追加されたのか?


Microsoft側としては、Silverlightの表現力を制限する機能であるaglimitをあまり大っぴらに宣伝したくないのか、MIX09でのSilverlight関連の発表でも触れられていないようですし、開発者向けのドキュメントやヘルプにもまだ記載がありません。

そのため、aglimitが追加された理由については、はっきりとは分からないのですが、個人的には、aglimitは「Silverlight広告」の推進の布石ではないだろうか?と予想をしています。
というのは、従来のFlash広告には、この手の機能を制限する仕組みがほとんどありません。
ですから、広告のあるページを開いただけでいきなり音が鳴ってビックリした経験をお持ちの方も多いと思います。Flash広告が嫌われる理由の一つですね。

この問題については、仮に広告掲載側がFlash広告での音声の再生を禁止しようとしても、基本的にはFlash広告の中身を提供する側との契約内容で制限し、それを信頼するしかありませんでした。
つまり、Flashは広告として利用するにはアプリの自由度が少し高すぎるという欠点があったわけです。

Microsoftはこの点に目をつけて、Silverlight広告を掲載するページのHTML側でSilverilghtアプリケーションの機能をきめ細かく制限する方法を提供し、Flash広告との差別化を図ろうとしたのではないでしょうか?

HTML側から機能制限が可能になれば、広告を掲載する側が、Silverlight広告が悪意を持ったコードを含んでいるかどうかを心配する必要性が多少は減りますし、広告を提供する側も、一つのSilverlight広告を、禁止内容が異なる複数のサイトで使いまわすことができます。

●aglimitの詳細


先ほども書いたように、現時点ではドキュメントやヘルプにaglimitについての記載がないので、ごにょごにょして調べてみたのですが、どうやら以下の文字列を指定可能のようです。内容については一通り確認してみましたが、一部推測が混じってますので、注意してください。
  • audio - 音声再生の禁止
  • movie - 動画再生の禁止
  • media - audio+movie
  • cookie - cookieの受信の禁止
  • http - HTTP使用の禁止
  • socket - ソケット使用の禁止
  • link - URLリンクの禁止
  • network - cookie+http+socket (linkは対象外)
  • ps - ピクセルシェーダの禁止
  • hwaccel - GPUを使ったハードウェアアクセラレーションの禁止
  • gpu - ps+hwaccel
  • is - 分離ストレージの使用の禁止
  • fullscreen - 全画面モードの禁止
  • all - 上記全てのオプションを有効
(注)
文字列は+で連結して複数指定が可能。
 aglimit=audio+movie -> audioとmovieを同時指定
文字列の前に-をつけると禁止を無効にできる
 aglimit=media-audio ->movieとimageは無効でaudioのみ有効
後ろのパラメータが優先
 aglimit=movie+audio-movie ->audioと同じ
大文字小文字は無視される
 aglimit=Audio -> aglimit=audioと同じ
TYPOは黙って無視される
 aglimit=soket -> socketのTYPOだが何も起こらない

かなり細かい指定が可能なのが分かると思います。

●aglimitの使用上の注意点


・パラメータを一つでも有効にすると、アプリケーション側からのJavaScriptとDOM操作が禁止される。
 これは、aglimitで制限を加えても、JavaScriptやDOM操作を可能にしてしまうと機能制限を解除されてしまうからじゃないかと思います。

・httpまたはnetを指定した場合に、Assembly Caching機能が使用できない。
 Assembly Cachingは、Silverlight 3で追加された新機能で、拡張ライブラリである.slvx形式のファイルを実行時にWebサイトから読み込むことで、アプリケーション本体のサイズを縮小し、一度読み込んだ拡張ライブラリをキャッシュして複数のアプリケーションで使いまわす機能です。.slvx形式のファイルは、アセンブリと呼ばれる.dllファイルを含んでいるのが普通ですが、もし他のファイルを含んでいた場合、aglimitでhttpやnetを使って外部ファイルの読み込みを禁止しても回避できてしまいます。故にAssembly Cachingも禁止対象になったということだと思います。

・Sloob(SilverLight Out Of the Browserの略)化すると、aglimitが無効になる。
 Sloob化したSilverlightアプリケーションには、<params>の内容を渡すことが元々できませんので、これはまあ仕方ないと思います。

・aglimit=audioは音声を完全に禁止できるが、aglimit=movieは動画を完全には禁止できない。
 movieはMediaElementを使った動画ファイルや動画ストリームの再生を禁止する事はできますが、複数の画像ファイルの連続表示を使った擬似的な動画再生を禁止することはできません。
かといって、imageも追加指定すると普通の静止画像も禁止されてしまい、表現力が大幅に損なわれます。この辺りは難しいところですね。

・hwaccelはCPU利用率を上げてしまうことがある。
 GPUを使ったハードウェアアクセラレーションが、ソフトウェアエミュレーションに切り替わるからです。hwaccelは、GPUの利用によってシステムの安定性が下がることが懸念されるケース、例えば同じページ内にGPUを酷使している物が他にある場合等に限るか、gpuを指定してソフトウェアによるエミュレーションも完全に禁止した方がいいかもしれません。

・aglimitではCPU使用率はそんなに下がらない。
 aglimitによる機能制限は、net等を指定して通信エラーが発生するような場合を除けば、アプリケーション側からはaglimitの内容を確認しない限りaglimitによる制限を感知できないようです。
ですから、audioを指定して音声の再生を禁止すると、音は鳴りませんが、アプリケーションは音声を流したつもりになっています。
これはアプリケーションの開発者がaglimitの存在を気にせずにコードを書くことを可能にするためじゃないだろうか?と予想していますが、よく分かりません。

・<params>で指定するパラメータとしてaglimitが予約されたので、他の用途で使えなくなった。
これは可能性としては低いだろうと思いますが、もし既存のSilverlight 2アプリで独自にaglimitパラメータを使って何らかの処理をしていたアプリケーションはソースの修正が必要になります。

●aglimit機能への要望


一見、いいことづくめに見えるaglimit機能ですが、一つ残念なことがあります。
それは、実際に閲覧するユーザ側ではaglimitの指定が簡単にはできないことです。
これについては、Silverlightの構成に「機能」のようなタブを追加して、limitで指定するのと同等の制限を与えられるといいのではないかと思います。
Silverlightの構成のタブについては、Silverlight 2の「アプリケーション記憶域」タブもBeta 2になってから、ようやく追加されたという前例がありますので、今後、正式リリースまでの間にタブが追加される可能性はありそうです。

●最後に


以上、Silverlight 3で追加されたaglimitパラメータについて、ざっと説明してみました。尚、Silverlight 3はまだBeta 1ですので、正式リリースまでの間に仕様の大幅な変更があることも充分考えられますので、実際に試す際は注意してください。
ひょっとするとドキュメントやヘルプに記載がないのもそのせいかもしれません。(了)

2009年3月23日月曜日

Silverlight 3 Beta 1で (H.264/AAC).mp4 の再生を試す簡単なやり方

先日、Microsoftから発表された、Silverlight 3 Beta 1(以下、SL3Beta1)の新機能の一つが、映像コーデックにH.264、音声コーデックにAAC、コンテナフォーマットにISO Base Mediaファイルフォーマット(ISO/IEC 14496-12)を使った動画ファイル(以下、(H.264/AAC).mp4)の再生機能です。

しかし、SL3Beta1は開発者向けのβ版なので、一般ユーザ向けのβ版のランタイム、つまりSL3Beta1のWebブラウザ用プラグインは配布されていませんし、今のところ、Silverlight 3が正式リリースされる前に、一般ユーザ向けにランタイムを配布する予定はないとのことです。

また、SL3Beta1のライセンス条項に従えば、Microsoft社と別途契約して許諾を得ない限り、公開されたWebサイト上でテストすることもできません。

ただ、開発者がPC上のローカルな環境でテストすることまでは、さすがに禁止されてはいないので、自分ではアプリを作成できないが、どうしても試してみたい方は
  1. 開発者用 Microsoft Silverlight 3 ランタイム Beta 1 (Windows版/Mac OS X版)をインストールする
  2. JW WMV Playerをダウンロードして展開する
  3. 展開したフォルダに、(H.264/AAC).mp4な動画ファイルを置く
  4. サンプルのHTMLファイル(readme.html)を参考に、動画ファイル名とサイズの指定を書き換える
という手順で、開発者向けのツールを使わずに、再生機能の簡単な確認ができます。
JW WMV Player以外のSilverlight版のビデオ再生アプリとしては、Tim Heuer氏のSilverlight 2 Video Playerがありますが、こちらでも同様の手順で再生可能です。

なお、WebブラウザとしてFirefoxやChromeを使用している場合、ローカルなHTMLファイルのパスに日本語(例:デスクトップ)が含まれていると、Silverlightアプリケーションが実行できなくなりますので注意してください。
IEであればパスに日本語が含まれていても問題ありませんでした。恐らく、URLのエンコーディング絡みの問題だと思います。
Silverlight側とWebブラウザ側のどちらの問題か?については、あえてコメントしませんのであしからずw

それから、再生に必要な(H.264/AAC).mp4な動画ファイルの入手方法ですが、Microsoft社が推奨しているのは、Microsoft Expressio Encoder 2(試用版もあります)にExpression Encoder 2 Service Pack 1を適用し、エンコード機能を使って(H.264/AAC).mp4な動画ファイルを作成する方法です。

そういうのは面倒くさいけど高解像度の動画の再生をちょっと試してみたいなーという方は、Apple - QuickTime - HD Gallerryからファイルを入手するのが一番手っ取り早くてオススメです。

「Silverlight 3向けの動画ファイルとしてAppleのサンプルファイルを紹介するのはけしからん!」とおっしゃる方もいらっしゃるでしょうが、Microsoftの高精細コンテンツ ショーケースにはWMV HDなファイルしかないので仕方がありません。というかどうにかしてください>中の人

具体的には、適当な映像を選択してから、HTMLのソースを表示して、拡張子が.movになっているURLを探し、QuickTime Plug-inアドオンを停止(そうしないとブラウザ内で再生が始まってしまうので)した状態でWebブラウザのアドレスバーに入力するか、ダウンロード用のツールか何かを使ってダウンロードしてください。

ここで公開されているファイルは、(H.264/AAC).movなQuickTime形式のファイルですが、QuickTimeのファイルフォーマットは、ISO Base Mediaファイルフォーマットのベースになっている関係で、Silverlight3でも一応再生ができます。他に、iPod向けの(H.264/AAC).movなファイルをいくつか試してみましたが、今のところ問題ないようです。

もし、上記のサイトでダウンロードしたファイルのサイズが数十バイトだった場合、それはWindows MediaのASXファイルに相当する、QuickTime Metafileという形式のメタファイルですので、メモ帳やテキストエディットで中身を開いて、実体のファイル名を探してダウンロードし直してください。

以上の手順で私も実際に試してみましたが、Silverlight 3の発表時にポイントとして挙げられていた、「GPUによる動画の再生支援」については、全画面化やサイズ変更等のスケーリングがメインで、GPUにH.264デコードをさせるようなことはしていないことがCPUの負荷から確認できました。

ただ、これについては昨年9月の時点で、MS本社のAlex Zambelli氏がDXVAを使ったハードウェアアクセラレーションはサポートしないよと非公式に発言しているので、予想の範疇です。

その他、QuickTime Plug-Inとの挙動の違いとしては、
  • (QuickTime形式ではない)同じ動画ファイルをQuickTime Plug-InとSilverlight 3 Beta 1で再生すると色味が多少違う
  • 再生品質がキープできない程高解像度の映像だった場合に、QuickTime Playerはフレームを間引くが、Silverlight3は画面が固まって音が途切れる
  • ビットレートが高い映像をhttp経由で再生した場合に、再生バッファは十分溜まっているのに画面が1秒程度固まることがたまにある。
等の違いがありましたが、Silverlight 3 はまだBeta1ですので正式リリースでは変わっているかもしれません。

最後に、何故 Silverlight 2用のアプリでSilverlight 3の新機能である(H.264/AAC).mp4が再生できるのか?という疑問を持った方もいらっしゃると思いますが、Silverlight 3 Beta 1 ランタイムは、<param>タグのminRuntimeVersionも、AppManifest.xamlのRuntimeVersionも無視して、新機能が常に使える状態になっているからというのが、現時点での予想です。
この件については、気が向いたら 項を改めてまた書いてみたいと思います。(了)

2009年2月23日月曜日

あまり奇をてらった言葉をBlogのタイトルに使うべきではない(かもしれない)という話

先ほど、id:shi3zさんの、『テレビ朝日から「つれづれ~というブログタイトルが多いという客観的な証拠を今日中に示せ」と言われた』 from Keep Crazy;shi3zの日記 を読んで、自分のBlogタイトル名でGoogleブログ検索を試してみたら、あまり奇をてらった言葉をBlogのタイトルに使うべきではない(かもしれない)という面白い結果になりました。


一目瞭然ですね。Blogのタイトルに "っき雑記" を指定して検索すると検索結果が0件になります。
私は検索エンジンの仕組みはよく知らないので理由は分かりませんが、ひょっとすると、Googleブログ検索は「っ」で始まるBlogのタイトルをBlogのタイトルとしては扱わないようにしているのかもしれません。

私は、id:shi3zさんの

「人の記憶に残っても「つれづれ」などのありふれた言葉をタイトルに使っていると、検索して見つけてもらえる可能性が低くなってしまうのでタイトルとして採用するべきではない」

という主張はおっしゃる通りだろうと思っていますが、あまり奇をてらった言葉にするのも考えもののようですね。

ちなみに「っき」というのは私が使っているハンドルネームで、昔、アーケードゲームのスコアネームにアルファベット3文字しか使えなかった時代に使っていた"KKI"をローマ字読みしたものです。

SEO上不利(笑)なのかもしれませんが、それなりに愛着もありますのでタイトルはこのままにしておこうと思います。