|
|
|
|
|
||
|
||
|
0001 | 01 | 02 | 04 |
2004 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2005 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2006 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2007 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 10 | 11 | 12 | 2008 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 12 | 2009 | 01 | 02 | 03 | 06 | 07 | 10 | 2010 | 01 | 09 | 2011 | 08 | |
備忘用。今回はケースから総とっかえしました(´・ω・`)あらゆる面で快適環境に生まれ変わってしあわせ。
Permalink | コメント(0) | トラックバック(0) | 14:30 
最近、鍵付きに移行した@hazumaの人が「新インタフェースになってから、たくさん来るフォロー承認を一つ一つ却下するのが面倒（意訳）」と、有名人ならではの悩みを語っていたのを見て、
と思い立って、TwitterのREST APIを叩くコードをゴリゴリ書いていたのですが、肝心な「承認待ちユーザの承認・拒否」をするためのAPIが公開されていなかったので実現できないという残念なオチに(´・ω・`)
この件についてはほとんど情報が出ておらず、Stack Overflowに少しだけ書いてありました。
皆様ご存知の通り、公式の新しいWeb UIは、それ自体がTwitter REST APIのクライアントとして動作しています。故に、公式Web UIから叩ける機能は、理屈上はそれ以外の外部アプリからも叩けるはず。
結論から言うと、「承認待ちユーザの承認・拒否」に対応するREST API自体は存在しますが、通常はアクセスできません。一方で、公式Web UIは、当該APIの呼び出し時に"post_authenticity_token"というパラメータを追加しているようです。
で、このパラメータの値は"twttr.anywhere.api.config.postAuthenticityToken"というプロパティから取得しており、このプロパティの値はTwitterからロードしたHTML内に"postAuthenticityToken"という名前で書かれた部分から読み取っている、と（boot/bootstrap_dataからも読めるみたい）。
しかし、単純にページ内からこの値を拾ってきて与えても"Not authorized to use this endpoint"と言われてしまってわけがわからないよ。あと、上記のStack Overflowのコメント欄には、真偽不明ですが「TOS（利用規約）違反だからやめとけ」とも書いてあったりしてうーむ(´・ω・`)
この件については、かなり以前からTwitterに対して要望が出ているのですが、数年単位でスルーされ続けているようです。
常識的には、「使い道の限られている機能を実装・公開・メンテする動機がない」が故に放置プレイを食らっている、と考えるのが妥当でしょう。
ただ、上でも書いたように、使いようによっては鍵付き生活の有り様を変えるポテンシャルを持った機能でもあります*1。そうした意味で、積極的に機能を制限しているという線もありうる、のかも。
というわけで、誰か頑張ってください(´・ω・`)
Permalink | コメント(2) | トラックバック(0) | 03:26 
日曜日の「DDR天下一舞踏会」参加者および関係者の皆様、おつかれさまでした(´・ω・｀)ノ いやいや楽しかったです。
今回、主催者様のご厚意により、大会のUstream配信を実現できました。配信中は、最大で90人前後の同時視聴者数を達成し、多少なりとも会場外に大会の盛り上がりを伝えることができたのではないかと思います。当日の視聴者の皆様の様子は、Togetterに作ったまとめでご覧になれます。
というわけで、今後の音ゲーイベントでUst配信が普及することを願って、今回、試行錯誤した結果として得たノウハウについて、少し書いてみようと思います。これから、イベントの開催を考えておられる方の参考になれば幸いです。
なお、Ustreamのアカウントの取り方とかサイトの使い方については省略。この記事では、主に機材に関することに絞って解説していきます(´・ω・｀)ｂ
（私は、AV関係にそこまで詳しいわけではないので、間違ったことを書いているかもしれません。また、撮影対象や環境によっても「何が最適か」は変わってきますので、下記の内容については、ぜひご自身でも検証なさった上でご判断ください）
このエントリと併せてご覧になると良いかもです。
「とにかく手軽に配信したい！」ということなら、Ust配信に必要な機能をオールインワンにしたものとして、こういうものがあります。「ビデオカメラにUst配信機能を付けてみました！」的なコンセプト製品です。
CEREVO CAM live! (マットブラック) CDP-C1M-B
画質や音質についてこのくらいで十分だとお考えなら、一考に価すると思います。配信時のネットへの接続は無線LAN前提のようなので、その辺はご注意を。
同じく手軽なところでは、iPhoneをお持ちの方なら、Ustreamが公式に提供している「Ustream Live Broadcaster」というアプリで配信できます。ただし、こちらはフレームレート的にかなり辛いかな、という感じがします。音ゲー配信用としては力不足かと。
次に、ウェブカメラを使う方法をご紹介。ノートPCとウェブカメラだけあれば良いので、あちこちに持ち歩く際にも負担にならないのがうれしい点。これから配信をお考えの方は、まずこの辺から始めてみるのが良いのではないでしょうか。
「ウェブカメラ」というジャンルは、ピンからキリまで、数多くの製品がリリースされています。
下の「ポイント」の項で詳しく書きますが、基本的には、「30fps」程度のフレームレートに対応している製品なら何でも良いと思います。後は、暗い場所でも撮影できるかとか、ズームが使えるかとか。ただし、多くの製品は普通のビデオチャット用（＝至近距離で静止した自分の顔を撮影する用途向け）なので、選定にあたっては用途を店員さんに伝えて相談されると良いかと。ちなみに、最近はこういうUstream用の専用キットとかもあるようです。ちょっと高いけど。
注意したいのは、ウェブカメラを繋げるPCのスペックが低かったり、暗い場所で撮影する場合、期待通りのフレームレートが出ないことがある点。今回の配信でも、ウェブカメラをうちのノートPC(ThinkPad X61)に繋いだら満足なフレームレートが出なかったため、家庭用ビデオカメラを使用する方法へ切り替えた経緯があったり(´・ω・｀)この辺りの話は中級編にて。
そのままでも、ウェブカメラをPCにつなげて、ブラウザでUstreamの配信ページを開けば配信できます。しかし、これだとあまり画質が良くありません。
そこで、少し画質にこだってみたいという方は、Ustreamが公式に提供している「Ustream Producer」というソフトを使ってみてはいかがでしょう。
Ustream Producerは、簡単な設定だけで高画質配信ができる優れモノです。以前は、高画質配信をするには「Flash Media Live Encoder」(FMLE)という（セットアップが非常に面倒な）ソフトを使う必要がありました。Ustream Producerは、あまり細かい設定ができない代わりに、FMLEの機能を手軽に使えるようにしたものと言ってよいでしょう。公式アプリなので、配信や録画の操作もボタン一発で可能と至れり尽くせり。
なお、具体的な使い方についてはググってください(´・ω・｀)実際、ほとんどインストールして起動するだけで使えるので、困ることはあまりないと思います。
「ポイント」と書いて「うんちく」と読む。というわけで、中級編に入る前に、予備知識として少し細かい話を。
さて、Ust配信はUst配信でも、「音ゲーイベントの配信」を実現する上で何を重視するべきか。その前提を置いて考えると、優先順位的には以下のようになるのかな、と。
今回の配信で、特に重要性を痛感したのがこれです。
今回、わりと気合を入れて各種収録機材を準備したのですが、結論から言うとイーモバ回線の不安定さに全て足を引っ張られる形になりました。特に、夕方に入ってから断続的に調子が悪くなり、決勝戦あたりでは視聴者の皆様にお見苦しいところを見せる結果に(´・ω・｀)
転送量自体は、動画と音声を合わせて300kbps程度（参考：Pocket Wifiの上り帯域は公称5.8Mbps）に抑えていましたが、土日の夕方という回線が混雑する時間帯に被ったことに加え、密閉されたコンクリ建造物の中での配信という点も大きかったのかもしれません。
そんなわけで、配信を行う際には、会場に固定で引かれている回線を利用できないか、まず検討してみると良いと思います。また、天下一舞踏会の会場で@Ysk439さんに教えていただいたのですが、UQ WiMAXの1 Dayプランという手があるかも、とのこと。WiMAXは「ダメな場所では全然ダメ」という話も聞きますが、速度面でかなり有利なので一考する価値はありそうです。
一秒間に画面を更新する回数。多ければ多いほど、高い帯域幅とPCのスペックが要求されます。普通の勉強会の配信等では、カクカク動画でも講演者とスライドが見えれば良いので重視されないことも多いです。しかし、音ゲーイベントということであれば、せめてゲーム画面の表示には追随したいところではないでしょうか。
具体的な数値ですが、今回ベンチマークに使ったDDRプレイ動画で試した範囲では、30(29.97)fpsあれば十分だと思います。60fpsを狙うかは、カメラ、回線およびPCの性能と相談で。
フレームレートごとに見え方がどう変わるか、という点についてはこの動画をご参考に。ただし、見る人間によって感じ方が変わる要素が大きいので、高ければ高いほど良いというわけではない点にはご注意。あと、インターレースとかプログレッシブとか、色々細かい話もありますが、気になる人はこの辺をご覧になるかググってください(´・ω・｀)
意外とバカにできない要素。動画のエンコード等でPCに負荷をかけ続けると、熱暴走で落ちる場合があります（というか実際に落ちた）。Mobile Meterというソフトを使うと、PCの内部温度を計測できます。物によると思いますが、CPUが70〜80度を長時間キープし続けるのはあまり良い傾向ではないかと。
対策としては、とにかく風を当てて冷やせば良いです。実際、今回はノートPCクーラーと卓上扇風機の併用で強引に乗り切りました(´・ω・｀)こういう面ではPCもただの電気製品ですので、原始的な方法が有効というわけで。
…まぁ、ちゃんと何やってるか分かればいいんじゃないかな、とか（なげやり。
上記の通り、高品質で収録しても回線が安定しないとどうしようもないので、様子を見ながら調整することになると思います。
音質は、よほどこだわらない限りは128〜192kbps程度あれば十二分だと言われているので、残りを映像に回すと良いかと思います。ちなみに、今回は96kbpsで配信していましたが、特に視聴者の方からクレームはいただきませんでした。どちらかといえば、収録時のノイズ等を軽減すべく、マイクやオーディオインタフェースに金をかけた方が良い結果が出ると思います。
画質は、主な指標としては「解像度（画面の大きさ）」「フレームレート」「ビットレート」の三点でしょうか。基本的には、数値が高いほど高画質になります。あと、エンコード方式が云々みたいな話題もありますが、詳しくないので省略。実際問題としても、とりあえず気にする必要はないと思います。
DDRといえばパネルを踏む時の振動。特に今回は、外部マイク（＝小さな衝撃でも音として拾ってしまう）を導入したこともあり、渋谷の東急ハンズに行って耐振素材を買い漁ったりしました。が、こちらも当初心配したほど影響は無かったです（チェックしてくれた友人曰く「パタパタという音が聞こえた」程度）。
考えてみれば、踏む時に出る音と被るので、さほど気にならないのかもしれません。その上で、少しでも対策したい方は、耐振マットの上になるべく重い机を置き、さらにソルボセイン等の「縦振動を横振動に変換する」系の素材を敷いた上に三脚を立てる、とかやるとマシになるかも。
家庭用ビデオカメラや外部マイクなど、ちゃんとした収録機材を使いたい人向け。ここから、少し物入りになってきます。
何でも良いです、はい(´・ω・｀)今回、私が使用したのは、Canonの「iVIS HF M31」です。早い話が、実家に転がっていたのをパクって来ただけですが。
Canon フルハイビジョンビデオカメラ iVIS HF M31 シルバー IVISHFM31 (内蔵メモリ32GB)
注意点としては、ビデオカメラはウェブカメラと異なり、外部出力をそのままPCに入力することはできません。これを実現するには、次の項目で説明する「ビデオキャプチャ」と呼ばれるデバイスが必要になります。
なお、DVテープ式カメラの一部（Sonyの「HDR-HC9」やCanonの「iVIS HV30」など）は、ビデオキャプチャを使用せず、IEEE1394端子経由で高画質映像をPCに直接入力できるらしいです。が、DVカメラという製品ジャンル自体が、全体的に生産終了になりつつあるのでどうなんでしょう、とか。もし、ご自宅にIEEE1394（i.LINKとかFireWireという名前かも）で出力が可能なカメラがあるなら、ビデオキャプチャデバイスは不要かもしれません。
ビデオカメラについているコンポジット(RCA)端子（白色と赤色と黄色のアレ）やS端子からの外部出力は、そのままではPCに取り込めません。USB端子がついている場合もありますが、基本的にはリアルタイムで出力を流し込むような機能はないです。そのため、ビデオカメラの出力をPCのUSBに入力できるように変換する「ビデオキャプチャ」デバイスが必要になります。
この手の製品は、高いものから安いものまで色々あるようですが、基本的には以下のどちらかで十分だと思います。どちらも3,000円前後で、画質についてもそれなりです。
I-O DATA USB接続ビデオキャプチャBOX GV-USB
Princeton USBビデオキャプチャーユニット デジ造 映像版 PCA-DAV2
ちなみに、私はI-O DATAの「GV-USB」を購入しました。が、この製品はUstreamの配信ソフトと相性が悪く、音声をきちんと入力できません。この問題は、音声出力に変換ケーブルをかましてPCのマイク端子（or オーディオインタフェース）に入れる、あるいはこのエントリに書かれている「AmarecTV」というソフトを導入することで解決できます。
ただ、とにかく面倒を避けたいということなら、Princetonの「PCA-DAV2」をチョイスされると良いかと。
細かい注意点として、基本的には「ソフトウェアエンコード」方式の製品を選んだ方が良いです。「ハードウェアエンコード」方式は、デバイスの中でエンコードしてくれるのでPCの負荷が減る利点がありますが、安物だとデバイス自体の性能が低いので、エンコードが遅れて悲惨な目に遭う場合があるとの由。ウン万円するような高級品ならば、その限りではないかもしれませんが。
「音ゲー収録するのにビデオカメラの内臓マイク使う男の人とかちょっと＾＾；；；」という人向け。
今回、外部マイクとして↓を新規購入しました。単一指向性のステレオマイクです。これを筐体に向けて固定し、ビデオカメラのマイク入力に入れて収録しました。
audio-technica ステレオマイクロホン AT9941
今回、初めてまともにマイクについて調べたのですが、マイクにも、ステレオだったりアナログだったり、ダイナミックだったりプラグインパワーだったり、全指向性だったり単一指向性だったりと、色々あるようです。少なくとも、「プラグの形状が合ってれば繋がるべー」というものではないようなので、興味がある人は調べてみてください(´・ω・｀)ノ
通常は必要ありません。今回は、上記のようにGV-USBの音声入力が利用できなかったため、カメラから別ラインで音声を入力するために導入しました。
オーディオインタフェースは、マイク等の音源の出力を、USB経由でPCに入力する時に使います。多くの場合、PC本体にもマイク入力やライン入力が内臓されていますが、内蔵の端子は（PC本体の電磁波で）どうしてもノイズが乗ってしまいます。そこで、外付けのインタフェースを使うことで、この現象を防ぐことができます。
通常、「オーディオインタフェース」というと、音楽制作をする人たちが使う高級なものを指すようですが、他に適当な呼び方を知らないので…。というわけで、安価な製品も色々あります。以下は一例。
Creative サウンドカード Sound Blaster X-Fi Surround 5.1 SB-XFI-SR51
ちなみに、私が今回使ったのは、Rolandの「UA-1G」という少し本格的な奴。ま、端的に言うと趣味です(´・ω・｀)他の放送主さんの使用機材にリストされていたというのもあるのですが。
EDIROL USB Audio Interface UA-1G
とはいえ、単に音楽制作用で高いというだけではなく、Ust配信的にオイシイ所もいくつかあります。入力端子の種類が多かったり、入力する音量を手元のダイヤルで調整できたり、音量が大きすぎると警告表示が出たり、複数ラインを同時に入力できたり。応用としては、マイクと筐体の外部出力を同時に入力、みたいなのもアリかも。
完全なる余談。
Picture in Picture(PinP)。画面の隅にもう一個ちっちゃな画面が出るアレです。つまり、筐体の映像出力をもらってきて、隅っこにPinPで表示できると面白いなぁ、と妄想していたというお話。方法は二つあります。
前者は、いくつかそういうソフトがあります。ただし、二つの映像入力＋合成処理をさばく性能を持つPCは必要です。後者は、知っている範囲だと、I-O DATAの「VABOX2」という製品があります。ただし、この製品の出力はVGA（PCのディスプレイ用）なので、そのままではキャプチャデバイスに繋がりません。VGA端子をコンポジット端子に変換するためには、別途「ダウンスキャンコンバータ」と呼ばれるデバイスが必要です。以下は一例。
I-O DATA 高画質化回路搭載ビデオコンバーター VABOX2
I-O DATA UXGA対応ダウンスキャンコンバータ TVC-XGA2
未検証の話ですが、こういう配信方法の可能性もあるということで。
最近のHD対応ビデオカメラにはHDMI出力端子がついているので、「これ使えないの？」と思う方も多いと思います。もちろん、外付けタイプのHDMI用キャプチャデバイスを導入すれば可能ですが、この手のデバイスは最低で2万円前後から、と大変お高いです。下手をすると5〜10万円とか（白目。
前述の通り、高画質に見合う回線が用意できないと宝の持ち腐れなので、私のような金を捨てるのが趣味の方（←）以外にはお勧めしかねます(´・ω・｀)コンポジット端子でも、十分見れる画質で収録できますし。
基本的には、金と労力をかければかけるだけ、高品質の配信が実現できます。問題は、その結果がかけた労力に見合ったものか、ということになります。言うまでもなく、一番大事なのはイベント自体の成功ですし。
個人的には、あまり気張らずに、まずはウェブカメラでサクッと始めてみるのが良いのではないかと思います。そして、実際にやってみて不満が出てきたら、機材の更新を考えてみるという感じで。こういう事があるとwktkして、小山のように機材を抱えて現地入りしてしまうのは、単にガジェットヲタの悪癖以上の何物でもありません(´・ω・｀)私みたいなのとか。
なお、これから音ゲーイベントの配信をお考えの方で、このエントリの内容について何か質問等ありましたら、Twitterで@Dryadまでお問い合わせください。今回の経験を元に、多少であればご相談に乗れると思います(´・ω・｀)ノ
Permalink | コメント(0) | トラックバック(0) | 17:42 
そんなものはない。*1パスワードを保存しようとした時点で、一定のリスクは避けようがない。
一方で、過剰にパラノイアになっても仕方がないので、そこをどう考えるかということではあるのだろう。
保存されている多数のアカウント情報を、一つのパスワードで暗号化することによってアカウント管理を容易にする。FirefoxやOperaに搭載されている機能。
当然のことながら、単体のアプリケーションで採用しても、問題が一周して戻ってくるだけなので意味がない。
ログイン中のWindowsアカウントのパスワードから暗号鍵を生成して、与えたバイト列を暗号化および復号してくれる。
早い話が、ログイン中のユーザ自身がマルウェアを実行してしまうとアウト。
DPAPIには、"entropy"というパラメータがある。名前だけ見るとsaltやIV(Initial Vector)的な何かに見えるが、実質的に「二番目の暗号鍵」と考えるべきであるようだ。entropyを使うことで、他のアプリケーションからデータが丸見えになるのを防ぐことができる。nullも指定できるが、基本的に何かは指定すべき。
Entropy could be considered analogous to salt, in that it is an additional key or secret used to further abstract the encrypted content. Unlike salt, your application's entropy would need to remain the same for every encryption operation under a given credential. With salt, its generally best to change it as often as you can.
Entropy is essentially an additional key, and it should be treated like any other cryptographic key. Keep it private and secure.
.net - Windows DPAPI - what to do with entropy? - Stack Overflow
また、大半のサンプルではハードコーディングされているが、entropyを知れば解読できることを考えるとあまりよくない。が、毎回変えるにせよ、entropyかそれを計算するためのパラメータはどこかに「保存」しなければならないわけで、攻撃者が本気でそのアプリからデータを抜こうとすれば、それを止める手段はない。
つまり、完全にセキュアにできるわけではないし、それを期待して使うべきものでもない。
というか最初は、DPAPIってそういうことをやってくれる機能かと思っていたのだが。
Permalink | コメント(0) | トラックバック(0) | 06:30 
なんかやたらと苦労したのでメモ。
namespace Sample { public class Entry { public Entry() { } // 最初から明示的に定義しておいた方が良さげ public string Key { get; set; } public string Value { get; set; } } }
<Setting Name="Entries" Type="global::Sample.Entry[]" Scope="User">
<Value Profile="(Default)" />
</Setting>
[global::System.Configuration.UserScopedSettingAttribute()]
[global::System.Diagnostics.DebuggerNonUserCodeAttribute()]
public global::Sample.Entry[] Entries {
get {
return ((global::Sample.Entry[])(this["Entries"]));
}
set {
this["Entries"] = value;
}
}
Permalink | コメント(0) | トラックバック(0) | 05:48 
|