山梨国体中継を終えてメモ
--[ATM-Rの起動]--
１）OS起動、ログイン（ルートになる）
２）pvcstat.shを起動。内容は以下。
--[DVTSマシンの起動]--
１)電源OFFの状態(コンセントも抜いて放電効果を得る)で、IEEE1394コードも抜いておく。
２)電源をONにする->OS起動、ログイン（ルートになる）
３)IEEE1394ケーブルを差し、認識メッセージを確認する。
4)dvtsstat.sh起動。内容は以下。
#!/bin/sh /root/tmp/dvts/dvs/dvs/dvs -e
/root/tmp/dvts/dvts-0.2.1/DVTS-0.2.1/dvrecv
-j 225.0.0.1 -f 0 -n
/root/tmp/dvts/dvs/dvs/dvs -e
-(DVTS関係の説明)-
dvrecvコマンドについて
・EthernetボードよりのDVデータを受信し、IEEE1394ボードよりDVデータ(DV
over IEEE1394)を送出する。
-j オプションについて
・-j [multicast address] とオプションを付けた場合、[multicast
address]で指定されたマルチキャストネットワークよりパケットを受け取る。
-n オプションについて
・
-f /-m オプションについて
・man dvtsにおいてmagic numberとされているこれらオプションは-mがあまりで-fが分母らしく、経験により値を出すらしい。あとは「祈る」とか。つまるところ、何通りかやってみてうまくいくのを探すということ。計算方法については以下メールより抜粋。
| NTSC を DV にするときは 29.97 frame/sec DV に変換すると 1 frame が 250 packets firewire は 8000 packets / sec 運べるとか... で (8000 - 29.97 * 250) の部分に何をどう突っ込むか、という のを指定するのが -f/-m parameters だそうです。 |
dvsコマンドについて
・dvs -e と実行すると、ドライバの切り替えのような事をする（あやふや）。これを行うと、IEEE1394ボード関連のコマンドを実行した後にハングアップが起こりやすいというのを回避できる。
今回困ったこと
・高知ATM-Rについて、当初FreeBSD4.2 + ALTQ-3.0の組み合わせであったのだが、この組み合わせの場合、pvc0だけにIPを割り当てても通信ができずにen0にもIPを割り当てると通信ができるという不可解な現象が起きた。その為、前回（ギガビットシンポジウム）の時に成功した急遽FreeBSD4.0
+ ALTQ-2.2という組み合わせに変更したところ正常に動作をした。
反省
・受信画像を監視しておく体制をもっとしっかりしておけばよかった。受信画像をもっと多くの人へ見てもらえるようなアプローチをもっと考えるべきであった。
今後の学習課題
・mrinfoは、どのような情報をくれるのか調べたい。（今回、高知ATM-Rでmrinfoを行ってもmulticast
clientである高知DVTSの情報を得ることができなかったから）
・multicastのパケットを受信”している”ということを知る術はないものか。