(日々の記録)デジタルオシロを買った。(木)Edisonの電池駆動無線カメラの実現へWindowsでnode.jsのストリーミング成功(4/5/2015)遂にWindowsでもEdisonのnodeサーバーの画像配信に成功した。うまくいかなかったのは、前の記事のコメントにあるように、単にクライアント側のindex.htmlファイルにWindowsでは動かないローカルサーバー名を使っていたことが原因だった。前々記事にも説明があるが、今度のnodeサーバーは、ローカルネットの中のホスト名を自動的に調べてネームサーバーなどの助けなしに、それが使えるような機能がついている。Unixの世界ではAvahi、Macの世界ではBonjourと言うのだそうだ。前回の記事のコメントで、tmz7273さんから教えて頂いた。WiFiではDHCPで自動的にIPアドレスを設定していくのでネットワークプリンターなどに固定のIPアドレスを振ることが出来ない。勝手に振られて迷子になってしまう。プリンターの個別のホスト名が使えれば、その心配はなくなる。Windowsでも使えるそうだが標準では入ってこない(iTuneをインストールすると入るらしい)。ffmpegとnodeサーバーの映像配信がWindowsで動かなかったのは、nodeのクライアント側のコードが、これを前提としていたためで、tmz7273さんからあらためてコメントを頂き、とりあえずコードの中のローカルホスト名(ホスト名.local)を直か打ちのIPアドレスに修正したら、難なくWindowsでも画像が配信された。懸案は見事に解決である。tmz7273さんには感謝、感謝である。これにより、Edisonの電池駆動の無線カメラの実用化は大きく前進した。1Fの居間に持ち込んで、ノートPC(WinXP)での画像配信を確認する。画面に地下のPCルームの光景が映った。この電池駆動の無線移動カメラはまだ何に使うか決まっていない。これが一番の問題なのだが、当面の目標は達成である。次の課題はこれの実装だ。ここまでは、本体と電池、それにDC-DCコンバーターそれぞれが、完全にバラックの状態である。電池駆動の移動カメラのケースの実装(4/7/2015)電池によって移動できる無線ウェブカメラというのは行き掛かり上の目標で、具体的な用途が決まっていない段階で実装するのは、少し危ない。いえ、このままにしておくわけにもいかない。本体と電源関係はひとつにまとめて動かせるようにしておくべきだ。しておくと、次のアイデアも湧いてくるだろう。いうので、手持ちのケースをいくつか取り出してレイアウトを考える。110x80x33)が入りそうだ。2段にした単三電池4つのホルダーのため、秋月のCサイズの基板を少し切り詰めてマザー基板とする。ここにEdisonブレークアウト基板とDC-DCコンバーター、スイッチなどを置く。Edison基板は50本近くのピンヘッダーとソケットでマザー基板と固定する。Edisonの入出力ピンは、Vccが1.8Vである。3Vや5Vの一般のペリフエラル機器を動かすにはひと手間かかる。秋月では、1.8Vから5Vに双方向に動く8ビットレベルシフターIC(FXMA108)基板を用意してくれている。Edisonを買うときに、一緒に2つほど調達した。基板上の場所も確保してある。何に使うか決まっていないので実装は後回しである。用途の決まっていない基板のレイアウトはいつもながら難しい。Edisonのシリアル端末が消える。nodeサーバーのソース解析に挑戦(4/10/2015)ところが、ここで大きな問題が起きた。Edisonのシリアル回線が動かなくなってしまったのである。心当たりと言えば、ブレークアウト基板の下に密集しているGPIOピンにすべてピンヘッダーをつけて、マザー基板で固定するようにしたことだが、これが原因とは到底思えない。Edisonブレークアウト基板はシリアルが動かなくても、OTG用のUSBソケット(J3)に、PCからタイプBのコネクターをつなげば、USBの仮想IPポートが生まれるので、WiFiがつながらなくても、そう心配ではない。いえ最後の頼み、シリアルが動かないというのは不安である。これにこだわっていたらいつまでたっても先に進めない。何かあれば、もう一台買い直す覚悟で先に進むことにする。今、直か打ちしているhtmlファイルの中のホストIPアドレス(Edison本体の)をnodeの中で変数として取得することだ。サンプルコードは何か事情があって、ホスト名にしか出来なかったと思われるので、もしかするとこの改善は難しいのかもしれない。今のままでは、Edisonの立ち上げのタイミングでその都度IPアドレスが変わってしまい、運用性が極めて悪い。この解決には、node.jsのソースが読めることが必須である。手続き言語のCなどと違ってオブジェクト指向のプログラムは、処理が外から見えないので、ちょっと読んだだけでは歯が立たない。何をやるオブジェクトなのかがわかっていなければ手も足も出ない。nodeの本を買って勉強はしているが、このEdisonのソースは、expressという定番のウェブサーバー用のモジュールを使っており、独自の変数や関数を自在に使っているので全くチンプンカンプンである。幸いにも、nodeはWindowsでも動くそうなので、まずはEdisonではなくメインのWin7のPC上で実際にコーディングしながら勉強して行くことにした。これが苦難の道の始まりだった。JavaScriptのお勉強にもどる(4/12/2015)nodeの言語であるJavaScript(以降js)の文法や構文はCに近い。以前、頼まれてオブジェクト指向ではない普通のアプリケーションプログラムをjsで書いたこともある。nodeのソースはすべてjsなので、すぐ理解できるだろうと、なめてかかっていたのだが、どうも甘かったようだ。オブジェクト指向は、C++などが出る遥か昔のSmallTalkの時代に勉強し、理論としては完全に理解しているつもりだった。C++が出たころ、実際にコーディングしてみて、余りの煩雑さに途中で投げ出したことがある。C++はSmallTalkのように理論的に美しくもなく、既存の手続き言語を強引にオブジェクト指向化した言語だ。まともなクラスを作るのには結局アセンブラープログラムが必要だったり、グループで開発するならともかく、個人でプログラムを書くときに、効率の良い方法とはとても思えなかった。今度はそうも言ってはいられない。もがいていたが、やっぱりjsそのものを理解しないと先に進めない感じがしてきた。先祖へ戻る一番効率の悪いアプローチだが、ウェブ上で評判の高いこの本を買って来た。本当は、こちらなのだろうが、べらぼうな厚さの参考書をいちから読み進めるのは、この際、勘弁申し上げたい。買って読んでみてやっぱり後悔する。言語仕様そのものが好きな人には面白いかもしれない。オブジェクト指向の勉強にはいいが、実践的なところが少ない。このところ電子工作の参考書の選択は、恰好をつけすぎて失敗ばかりしている。これまでに参考書が役に立ったためしがない。しかたなくウェブサイトにもどって片っ端から、実際にコーディングしながら学ぶことにした。所長は、ウェブのアプリケーションプログラムの開発は殆ど未経験である。Perlで見よう見まねのCGIはやってはいるが本格的な開発はやったことがない。それでも最初のうちは好調だった。簡単にサーバーが作れる。node入門の記事に最初に出てくるコードはどこも殆ど同じで、これは問題なく動く。次のステップから一気に難しくなる。nodeではサーバーの構築は、色々な付加的なモジュールを使って進めるのが常道のようで、Edisonのサーバースクリプトにも使われているexpressがやはり定番のようだ。こちらも当然、expressを導入することにした。node.jsのモジュールexpressが動かない。Lチカを超えられない(4/17/2015)ところが、このexpressが入らないのである。ウェブにはnodeについては無数の入門記事がある。Windowsだけの状況かもしれないが、多くの導入方法があり少しづつやりかたが違うが殆ど同じ手順だ。nodeのインストールはどれも順調に終わるが、expressに関してはいつも同じところで引っかかる。エラーもなく、expressはインストールされる。入っているように見えても、サンプルコードを動かすと、「そんなコマンドはない」というエラーではねられる。不思議なことにnodeはパスを必要とするのに、expressは必要としない(パスを通しても動かないことは同じ)。バージョンが変わるとインストール方法なども変わり、expressが所定のところに入っていない感じだ。expressではなく、express-generatorを最初に入れないといけないのだそうだ。してもexpressが動かない状況は変わらない。不思議なことに、カレントディレクトリー(サーバー環境の一番上のディレクトリ)には、expressをインストールするたびに、C;という一般には使わない記名のサブディレクトリが必ず定義され、ここにexpress関係が入ってしまう(セミコロンはCUIでは無効になる)。そもそも、nodeそのもののインストールからしていくつかの方法がある。あるところでは、「WindowsではNodistが良い」というし、本拠地のサイトから一式をダウンロードするのではなく、npm(nodeにおけるパッケージ管理環境)で新しいバージョンをいつも更新できる環境の方が良いとも言われる。いずれにしても、expressサーバーのスクリプトは動かない。色々なサイトを巡って片っ端から前の環境を消しては新たにnodeやexpressをインストールするが、全滅である。バージョンに合ったインストールをしていないことが、この混迷の原因だと思うのだが、今となってはもう遅い。Nodistという既にアンインストールしたはずのパッケージのディレクトリ名が、あのC;のディレクトリーの中に出現したりして、もうわけがわからない。そのうち、何故かいつもこういう状態でこれまで挫折していることに気が付いて愕然とする。雑誌の付録基板などのときも同じだ。言われるままにLチカまで進むが、少し先に進もうとすると一気に難しくなり先に進めなくなる。PID制御や、サーボモーターの時もそうだった。初歩の実験や理論については山ほど情報があるし、簡単に動くのだが、その先がわからない。今度もnodeサーバーが動くまでは至極簡単なのだが、その先に進もうとすると、こうして阻まれる。今の人たちは大変だなと思う。昔はベンダーに囲い込まれていたから、開発環境や、言語は選びようがなかった(歯を食いしばって頑張るしかなかった)。現在はオープンシステムで、それも百花繚乱、こうやって挫折しても次に移れる。簡単に移れることは逆に不幸なことなのだ(また同じ繰り返しになる)。このブログにも再三書いていることだが、理解できなくても我慢して浴びるように情報を摂取していれば、いずれは突然霧が晴れるように全貌が見える時が来る。これが電子工作(いやお稽古ごと全般)の醍醐味なのだが、現実となるとそう強がりも言っていられない。本当にnodeをこのまま勉強して行って、ものになるのか自信がなくなってきた。PCに向かっては、ため息をつく時間が過ぎる。いうときは、何も考えず手を動かす作業が一番気が紛れる。このあいだの雑誌付録のUSB-DACのケースを作ったりして遊ぶ。会社のPCでexpressは動いた。自宅でもなんとか成功(4/21/2015)それが、奇妙なことで解決したのである。自宅のPCでは何かゴミが残っているらしく、どうやってもexpressがうまくインストールできない。それではというので、仕事の出先のPC(Win8.1)に、まっさらからnodeをインストールしてみた(最近の仕事は開店休業状態で時間はたっぷりある)。手順の中では一番まとまっているこれを選ぶしかし、3のexpressの導入で引っかかる。今度はこれまでに起きていた変なC;というディレクトリが作られる現象は止まった。ふーむ、少しは前進したか。次に、expressではなく、express-generatorだよと教えてくれたこのサイトの手順を試してみる。expressはコマンドとしては動かない。間違いなくexpressを入れたHTTPサーバーが動いている。foundなのにnodeスクリプトとしては動く。わけはわからないが動いたことは事実である。帰宅して、とるのもとりあえず地下のPCルームにこもる。Filesの中も隈なく調べてnode関係がないことを確かめたあと、事務所で動いた2番目の手順をインストールした。おやー、事務所では出てこなかったC;というディレクトリが出来ている。どこかにゴミが残っている。消したはずの、Nodistとか、最初に作ったワークディレクトリのNODEというサブディレクトリが出来ている。expressは危惧した通り、サンプルコードも動かない。このあたりになると、expressのディレクトリー構造がわかってきている。閃いたので、C;に入っていたexpressのディレクトリチェーンの中味を本来あるべきところへ強引にコピーし、C;ディレクトリを消して動かしてみた。見事に自宅でも、expressが動いてサーバーが立ち上がった。いやあ手間がかかった。こんなにnodeをインストールするのが大変とは思わなかった。原因は明らかに、C;という変なディレクトリを作る操作がインストールの途中で紛れ込み、それがexpressを動かなくしていたことは間違いない。それがなぜ起きているのかについてはまだ解明出来ない。expressそのものはまだコマンドとして単独では動かない。疑問はまだまだ残るけれど、expressはその後、処理を増やしていっても問題なく動いている。これでブログに報告できるというものだ。(金)Edisonの移動カメラ化はさっぱりすすまず初めての五竜遠見スキー場。季節外れの豪雪(3/13/2015)今年2回目のスキー行が近づいた1週間ほど前、仕事から帰ってきて急に気分が悪くなり食べたものを戻した。夜遅くからは激しい下痢に見舞われる。ノロウイルスにやられたらしい。医者は3~4日で良くなると言ったが、出発まであと4日、スキーを中止するかは微妙なところだ。2日間は食事らしいものは何もとれず。スキーに行く前日にやっと下痢が納まり、おかゆが食べられるようになった。自分の車で仲間を乗せてスキーに行く約束をしているので中止は避けたい。連れに事情を話し、恐る恐る予定通りスキーに出かけた。関東平野は快晴だったが、スキー場に近くなると雪が激しくなった。春も半ばというのに猛吹雪である。宿のペンション前の坂が上りきれない。先に着いたもう一台の仲間の車は180度回転したそうだ。別の道から迂回して何とか宿の駐車場にたどりついた。今回のスキー場は、いつも出かける八方尾根の宿が競技会の本部になってしまったので、その隣の五竜遠見スキー場である。何十年もこのあたりに来ているが初めてのスキー場だ。楽しみにしていたのだが、体力が心配だ。泊まったペンションは当たりだった。ゲレンデにも近く、食事も上品で、ロビーに恐ろしく贅沢なオーディオ装置があるのに驚いた。バブルの儲かったときに先代が揃えたのだという。JBL4344などのスタジオモニター2組と、タンノイのArden(アーデン)が聞き比べられるようになっている。アンプはマッキントッシュ(管ではなく石)。クラシックはやはりタンノイが良い。体の方は、順調に回復した。当初食べられる量はみんなの1/4だったが、帰るころには普通に戻り、スキーをやるのには十分だった。季節外れの大雪でゲレンデには、1m近い新雪が積もった。腕試しに、圧雪していないバーンに飛び込んでみたら、雪が重く、スキーを浮かすことも出来ず、斜滑降のまま前のめりに転倒した。これが簡単に起き上がれない。深雪スキーなどと洒落れているような状態ではない。ほうほうのていで退散した。今回はノロウイルスのせいに出来るが、基礎体力は間違いなく低下している。残念だけれど仕方がない。体力相応(年相応)のスキーをやるしかない。スキーそのものは誰もけがもなく無事に東京に戻ってきた。いんちきなSDカードリーダーで写真データを失う(3/17/2015)しかし、帰ってからも不運は続いた。スキーの写真をPCに移すため、カメラから取り出したマイクロSDカードをUSBアダプターに付けているうち読めなくなったのである。1回目は読めたのだが、2回目から全体が読めなくなる。ディスク自体がないというとんでもないエラーメッセージだ。USBプラグにSDカードのソケットがついている簡便なタイプのSDカードアダプターである。このアダプターは前にもこんな事故が有ったような気がする。SDカードを調べてみるとマスターディレクトリがこわれているようだ。家族が使っていたカメラなのでバックアップは殆どない。データそのものは壊れてなさそうなので、データを回収できるユーティリティをウェブで探した。有償、無償を問わず、無数のリカバリーソフトが見つかった。定番のものはなさそうだ。このあたりは商売になるようで、見つけるときは無料でも、取り出そうとすると有料になるソフトがあったりするので気を付けないといけない。このリカバリーソフトで幸い99%の画像データは回収できた(家族の申告による)。面白いことにこのソフトは、Windows版はデータ回復が連続してできないなどの制約があるが、Linux版は全くフリーで使える。家族がカメラに入れたままにしていた写真データなので(大事なものはバックアップがあった)、幸い大事にならずに済んだが、一度事故があったにもかかわらず、このアダプターをそのまま部品箱に入れたままにしていた自分の不明を恥じる。このアダプターをどこで買ったのか今になれば全く思い出せない。2つ目の抵抗を焼いて、遂にDCDCコンバーターの自作を断念(3/23/2015)こんなこともあって、電子工作の意欲は下がるところまで下がってしまった。Edison基板の電池電源の調査は、NiMH(ニッケル水素)電池4ヶを、DC-DCコンバーターNJM2360で昇圧して(7.5~9V)動かして以来、先に進んでいない。スキーに行く前に、インダクターを大型のものに取り換えたり、抵抗の定数値を変えてみたり、配線を短くして見たり、すこしづつ様々な方法を試していたが、いずれも目立った効果はなかった。性能に関わるファクターが沢山ありすぎる。単体のNJM2360か、外付けにパワーTRを付けるか、さらにFETをつけるかの選択肢がある。それに、インダクターの種類でも結構性能が変わる(URL参照)。入力電源を何にするかでも最大出力電圧(電力)は大きく変わる。リチウムバッテリー(3.7~4.2V)の電池の大小でも変わるし、数Aの容量を持つACアダプターであっても、それに見合う電力が出るわけではない。定格容量内であっても電流を流していくと出力電圧が落ちて電力が下がる。今のところエネループ、NiMH電池が一番高出力なようだが、これも満充電のとき(1.4V)は良くても、最後の方(1.1V以下)では、リチウムにも及ばない(4ヶで4.4Vなのだが)。(1.85W)の出力が最大だった。358mA(2.4W)までしか出力は出なかった。設定電圧は下手に上げたり(9V)すると、かえって出力は下がってしまう(電圧も電流も)。そもそもが、すべてブレッドボード上での実験である。汎用基板で組んでもうまくいかないことがあるという微妙な回路で、ブレッドボードのままで、性能が悪いと断定するわけにはいかない。それにしても心残りなのは外付けの効果があまり感じられないことだ。この回路図(FETひとつにTRを2つ)で組んだ外付けFET(IRLB8721)では、パワーTRより成績が悪かった。実験をまだしていなかった最後の回路、FETとPNPトランジスターひとつ(2SA1015)を外付けしたものも試したみた。これも似たような性能で成果は上がらない。そのうち、誤接触で過大電流制限用の0.5Ω抵抗から一瞬小さな煙が出て、抵抗を焼いてしまった。ブレッドボードの配線をいじっているうちにVccをどこかでショートさせてしまったらしい。この抵抗を焼いたのは、これで2回目である。ひとつ5円もしないパーツだが、焼けて使えなくなってしまう(ひとつは断線、ひとつはキロオーム台に)こと自体が気分的に滅入る。これですっかり意欲を失ってしまった(へたれである)。UVCカメラ付きのEdisonを機嫌よく動かすには、7.5V入力なら、400mA以上を安定的に供給できないといけない(前記事の計測データから)。あともう少しなのだが、アナログは基礎がないので、何をするにもすべて手さぐりで方向を定められない。それにNJM2360は相当設計の古いICで、どこかのサイトでは化石とまで言われている。インダクターや、パワーTR、FETなど沢山部品を揃えてしまったが、ここからの撤退はそろそろ潮時のようだ。ストロベリーのテスト前に、Intelブレークアウト基板の電源を調べる(3/25/2015)実は、スキーに行く前、前記事でとりあげたストロベリーリナックスのDC-DCコンバーター基板を注文してあった(これを2つ、これを1つ)。これらの基板は超小型で、いずれも3~5V入力から、20V近くまで昇圧し、電流も800mA以上出せるという触れ込みで、値段もそう高くない。スキーに行く直前に届き、簡単なテストをしたところ、NiMH電池入力でEdisonが短時間ながらストリーミングまで正常に動作してしまったのである。今までのNJM2360での最高はカメラを付けるまでで、ストリーミングはできなかった。この成功が、NJM2360のさらなる実験に力が入らなくなった原因のひとつなのだが、これが長時間カメラを動かし続けることできるかはまだわからない。このコンバーターの長時間テストの前に、Intel純正のこのブレークアウト基板の電源系統をもういちど調べ直すことにした。いうのは、前の記事のコメントで、この基板には、5VのVccに直接接続する電源供給の方法があることを教えてもらった。そんなこともあるので、安易にストロベリー基板に頼る前に、何が最善策なのか基本的なところを押さえておきたいと思ったからである。頂いたコメントにもあるように、この基板の詳しい回路図は秋月電子のホームページにPDFとして出ている。それによると、基板には、以下の3つの電源関係のICが載っている。型番から調べるとそれぞれ次の機能を持っているようだ。完全な理解ではないが、これまでに調べたところでは、外部の7.5~15V入力は、TPS62133の降圧コンバーター入力で、一旦5Vに落とし(5V_SYSとVBUS)、5V_SYSは、MIC2039の電流制限ICと、BQ24079のリチウム電池充電ICを経由して、V_SYSとなり、これがEdisonのVccに入る。従ってVccは5Vではなく、リチウムバッテリーの3.15~4.4Vの範囲である。このDC降圧コンバーターの効率がどれくらいか、コンバーターを通さないで、直接5VをDC-DCコンバーターで作って供給するのが良いのかどちらが良いかは難しいところである。効率からみれば直接の方が良いに決まっているが、負荷の変動にどちらが強いかはわからない。コメントにある5V供給というのがどこから供給することを指すのかわからない。5V_SYSは、このPDFの回路図によれば、端子として出ておらず、簡単に5Vを供給するポイントはない。VBUSはEdisonのOTGのUSB機器に供給する5V出力で、ここから供給するのは何かおかしい(一応SBDを介して5V-SYSに入るようになっているが)。何度も回路図を調べたが、適当な5V供給ポイントが見当たらないのと、この基板で完結している系を乱したくなかったので当初の予定通り、7~15Vの外部入力ラインに9V程度の電圧をかける方針で行くことにする。ストロベリーリナックスのDC-DCコンバーターでカメラが長時間動いた(3/26/2015)このストロベリーリナックスのDC-DCコンバーターは、短時間ながらスキーに行く前、Edisonにつないでカメラのストリーミングが動いた。数分しか動かしていないので、安定して動くかどうかはわからない。最初、スルーホールに接続できるジャンパーと電流値を測るためのシャント抵抗を入れたミニブレッドボード上の配線で試してみたが、どこかで接触不良が起きるらしく、立ち上がるもののカメラをつないだり、基板を動かしたりするとリセットした。そこで、コンバーター基板にピンをハンダ付けし、ミニブレッドボードにしっかり差して動かすと安定した。一時間経っても、全く問題なくウェブカメラは動作した。よーし、電源のハードはこれで決まりだ。NJM2360は残念なことをしたが、さすがは既製品のDC-DCコンバーターである。この程度の負荷では殆ど熱を持たない(Edisonは触れないほどではないがカメラを動かすと結構熱くなる)。Edisonのウェブカメラの負荷はどれくらいだろう。topコマンドで測ってみる。それによるとCPU使用率は50%で、これはmjpg-streamerのモーションJPEGでも、node.jsのffmpegのMPEG1ストリームでも変わらなかった。PC側のリソースメーターで見ると、転送量はモーションJPEGでは2Mbpsを超えている。node.jsはMPEG1なので1Mbps以下である。apacheなどのHTTPサーバーを入れるとCPU使用率は50%ではすまなくなり、もしかするとこのストロベリーのDC-DCコンバーター基板では動かなくなる危険もあるが、現在のままでは、とりあえず問題はない。やれやれ、やっとのことでハードの問題はクリアしたようだ。次はこれをどういうパッケージに実装するかであるが大きな峠は越した。次の課題は、ストリーミングソフトの決定である。node.jsではどうしてもWindowsで画面が出ない(3/28/2015)NiMH電池による電池駆動は順調である。電池の充電も2回目に入った。途中で止まることもない。単3のエネループ(1900mAh)4ケで、少なくとも3時間以上は動いているので実用には十分だろう。問題は動画ソフトである。ストリーミング画像はmjpg-streamerも、node.js(ffmepegのMPEG1)のどちらでも安定して出ている。node.jsの方が軽くて良いのだが、実はこいつはWindowsでは画像が出ない。mjpg-streamerはWindowsでも画像が出るのだが、自分用の画面を切り出すことが難しい。前のRaspberryPiのときは難儀した。このmjpg-streamerのHTTPサーバーは簡易版で、CGIをサポートしていないだけでなく、スタイルシートがとても複雑で改造を諦めた。モーションJPEGなので反応が遅く、全体に重い。自分用にカストマイズしたいのならApacheなどの別のサーバーを必要とする。そこでnode.jsの方をサーバーとすることにし、画像をWindowsで出せるよういろいろ調べてみた。いじったところは、主にffmpegのパラメーターである。パラメーターをいじるが(ffmpegの)、何を入れてもダメである。Webを探し回るが適切な情報はない。原因はffmpegではなく、node.js側にあるような気がしてきた。node.jsのお勉強をする。node.jsはPERLやRUBYのようなスクリプト言語(JavaScript)のインタープリターと考えれば納得がいく。インタープリターなのでソースコードが直に見える。調べたところでは、jsmpegというコマンド(?)がストリームをデコードしているようだ。ウェブを幾ら漁っても、これがWindowsでは動かないという文言が見当たらないのである。うーむ、ウェブの断片的な情報では、全体をつかむのが難しい。良い機会なので仕事の帰り、久しぶりに秋葉原の書泉に寄って、こんな本を買ってみた。書泉はさすがに専門書が揃っている。node.jsの本だけでも10冊近くあった。何が適当な参考書なのかはわからない。迷った末、定番のオライリー本にする。脱線につぐ脱線だがまあ許してもらおう。このあたりでブログに報告することにする。20日も経ってしまっている。