日々の戯言


バックナンバー

1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

11月2日(金) Friio

今朝 2ch DTV 板で知ったのだが、Friio なる USB 地デジチューナが発売されたらしい。放送用エンコーダの出力ビットストリームを眺めてハァハァしたい人としては、人柱やってみるのも楽しいかと思ってポチろうとしたのだけど残念なことに現時点では在庫切れで注文できず。

昨晩のうちに気がついていれば間に合ったようなのだが惜しいことをした。うーむ。税関で止められるよーになる前に出荷再開してくれるといいのだけどなー。


11月3日(土) x264 [23] --me sau のその後

--me sau (シミュレーテッドアニーリングと umhex の組み合わせ) がその後どーなったかを気にしてる人を見かけたので。私が知ってる情報を。

By the way, I totally trashed the Simulated Annealing algorithm in favor of another one (since I couldn't get SA to work well enough). The new algorithm basically takes advantage of the fact that the HEX ME algorithm is so well optimized, and, well... has fun with that

以上のように doom9 のフォーラムで考案者が語ってる [URI] 以上、--me sau はゴミ箱に放り込まれたのだろう。上の引用部分で出てくる The new algorithm というのが現在の --me imh。

imh の方は 既に解説済み なので、sau とはどーゆー処理になってたかを簡単に解説しとく。まず基本が umhex なのは変化しない。

  1. 非対称クロス検索
  2. 5x5 グリッド検索
  3. ラージヘキサゴン検索
  4. スモールヘキサゴン検索
  5. スモールダイアモンド検索

上記の umhex での検索手順のなかで、ラージヘキサゴンとスモールヘキサゴンの間に、sau での追加検索手順が挿入される。その追加検索手順とゆーのが……

  1. スモールヘキサゴンの 1st ステップの評価パターン 6 個 [(-1,-2), (+1,-2), (-2, 0), (+2, 0), (-1,+2), (+1,+2)] の中から乱数で 1 つだけ選択したものを、ベスト位置を更新しながら複数回評価する
  2. 5x5 グリッド検索を実行する

とゆー何をしたいのか謎 (乱数使ってるけど、移動先がスモールヘキサゴンの検索パターンと変わらないので、素直にスモールヘキサゴンやった方がマシ) なもので、意味があるのは 5x5 グリッド検索だけとゆー手順だったりする。

完全にランダムに評価座標を決定してから、スモールヘキサゴン + スモールダイアモンドで絞り込むという手順を繰りかえし実行するのならシミュレーテッドアニーリングと名乗るのも妥当なのだけど sau の実装はそーなってはいなかった。作者が捨てることにしたもの当然かなーと思ったりする。imh の方がシミュレーテッドアニーリングの本来の手順に近い処理になる訳だし。


11月5日(月) Lanczos 3-lobed 拡大縮小 ver. 0.5.3

更新。ダウンロードは [AUF] から。祝 aviutl 更新再開というわけで、需要の多そうなフィルタを MT 拡張に対応させてみた。YUY2 拡張に関してはフィルタのコア部分をかなり変更しなければいけないので今回は見送り。

どうやら圧縮音声の AVI を入力とした場合に出力プラグインから取得可能なオーディオサンプル数が壊れている問題はまだ修正されてない (バグレポートを送ってないので当然といえば当然) ので、更新も再開されたことだしバグレポートを送ってみようかという気になりつつあったり。


11月8日(木) flv.auo

一応需要があるようなので作ることにした。といってもまだ FLV のファイルフォーマット仕様を調べ始めたあたりでコードは一行たりとも書いていないのだが、一応途中で放り投げないように着手報告をして自分を追い込んでおく。

でーそれはさておき Adobe の SWF and FLV File Format Specification License Agreement のクソっぷりに腹が立つ。

a. You may not use the Specification in any way to create or develop a runtime, client, player, executable or other program that reads or renders SWF files.

「これ読んだら、SWF/FLV プレイヤーは作っちゃダメよ」だそーで、一次資料が封印されてしまった。仕方がないので以下を参考にフォーマット仕様を調べてる。

比較的シンプルなフォーマットのようなのでメタタグ以外に関しては大体理解できたと思ってるのだけど……ここから先は調べるのが大変そうだなー。

今週末の間にある程度まで到達しときたいと思ってるので、順調に進んでくれればいいなと願ってる。


11月10日(土) tsselect

某 USB 地上デジタルチューナのスレッドで、こーゆーの を望んでる人がいたようなので (C で 500 行も必要とせずに作れるものだし) 作成。つーか flvmux 放置して何をやってるのだろうとフト疑問を抱いたりもする。

探せば他に見つかりそうな気もするのだけど、2 時間コード書けば解決するんだったらそっちのが速いかと考えてしまい、ついフラフラと。

・名称 

 tsselect - MPEG-2 TS stream(pid) selector

・機能

 MPEG-2 TS を読み込んで
 ・PID 別に、パケット数・ドロップ数 (カウンタエラー数)・スクランブル
  パケット数を表示する
 ・指定された PID だけを含むストリームに再構築する

まー見ての通りですな。一応 flv の方も作業はしてますんで安心を。

仕様は大体判ったんだけど、メタデータのフォーマットで「IEEE 754 形式 ビッグエンディアン 倍精度浮動小数点バイナリ」とかゆーのを見てしまって「うへぇ」ってな気分になっていたり。なんで映像の画素サイズやらステレオ・モノラルのビットフラグを実数形式でファイルに書き込むんだか……ホント謎仕様だよなぁ。


11月11日(日) むご〜

flvmux の実装が終わらん。こりは今日中のリリースは無理かも知れん。flvmux 自体の残りはインタリーブ処理用のオーディオバッファだけなんだが、ここは結構難物だし flvmux の作業が終わっても、設定 GUI と VP6VFW の (2 パスまで含めた) 制御方法確認とかがあるからな〜。

まーなるべく頑張っているつもりとはいえ、Friio 2 次ロット発売祭りに参加したりもしてるんであんま言い訳はできないよなー。とりあえずもー遅い (現在 AM 01:34) ので寝ることにしよう。後は起きてからの作業だ。

◆◇◆

うーむ。まさかまだ (現在 22:34) flvmux の実装が終わらないなどという事態に陥ろうとは。やはり誰も使う人がいないであろう PCM 音声の対応を追加しようなどと考えたのが間違いだったのだろうか。

それでも残りはあとちっとなので一応今日中に flvmux の片を付けることができるだろうと思ってはいる。flv.auo は……遅くても 11/18 までには何とかできるだろう。flv の多重化部分さえ終われば後は exavi とたいして変わらんのだし。


11月12日(月) 土橋 真二郎「ツラトゥストラへの階段」(電撃文庫)

そこそこ気に入っている作家の新刊が出ていたので購入。一応楽しめた。(B)

読む前までは「扉の外」シリーズとは別ものなのだろうと思い込んでいたのだけど、どうやら微妙にリンクした世界の話らしい。楽しめているので続きが出るなら購入予定。


11月13日(火) 上月 雨音「SHI-NO シノ 支倉志乃の敗北」(富士見ミステリー文庫)

布団は悪魔かツンデレ天使のどちらかと言われると……日々二度寝の誘惑に敗北している人としては、やはり悪魔になってしまうのだろうか。寝室の暖房はオイルヒーターなせいで常時 ON が基本だから布団が冷たいっつーこと自体がないし。

それはさておき、継続中のシリーズの新刊が出てたので購入。このレーベルにミステリーを期待するほど初心ではないし、そもそもミステリーをパズルとして楽しむ習慣がないので、普通の人々が大きなマイナス要素として許容しきれない部分をスルーできてしまう人としてはそこそこ楽しめた。(B-)

前の巻までと比較すれば読むのが苦痛の部分も減ってきているので、一応今後も継続購入予定。むー「円環少女」とか「SHI-NO」とかを読んでる人間としてはやっぱり「紅」も読んでおくべきなのかなー。それとも途中で放置してるナボコフ先生の古典を片づけてからにした方がよいのかしらん。


11月14日(水) 視聴リスト

前回 の報告からほぼひと月が経過し、評価の上がった番組もあれば、脱落してしまう番組も出始めてきたというわけで現状報告。

今回までに脱落したのは「逆境無頼カイジ」「魔人探偵脳噛ネウロ」「まめうしくん & わんころべぇ」「しおんの王」以上 4 作品。肌にあわなかったり、微妙に縁がなかったり (仕事が忙しい時期に録画ファイルがたまって見る機会をなくしてそれっきり) とかが原因。

現状で 30 本か。ボーダー上のはいくつか落ちるかもしれないけど、これぐらいならそんなに負荷は高くないから意外と脱落せずに見続けるかも。


11月15日(木) Friio 到着

 ついに念願の Friio を手に入れたぞ。
 1. ふ〜ん関係ないね
 2. たのむゆずってくれ
 3. B-CAS に通報する

そーゆーわけで余っている B-CAS カードを入れて正常に動作することを確認。上は視聴中のスクリーンショット。Athlon64 3700+ (2.2GHz) 環境では Friio アプリケーション付属の MPEG-2 ビデオデコーダフィルタでプレビュー表示して CPU 負荷が 45〜60% といったところ。最近のマルチコア CPU ならこの程度の負荷は余裕でこなせることだろう。

保存も普通に平文 TS で全セグメントを記録してくれるので (自力でどうにでもできるから) 不満はなし。原価を考えると約 3 万という値段はちと高めかもと思ったりもするが、他に同等商品がない以上は仕方がない。現時点ではおおむね満足してる。


11月16日(金) イベントのその後

572 [2007/11/16(金) 11:34:33 ID:vS92sT3J] 名無しさん@編集中

 tsselect.exeは糞ソフト。使用しない。 
 pid=0x0100, total= 26025, drop=26024って言うけど、本当に0。 
 ●も歯ね 
 > ttp://www.marumo.ne.jp/ 
 > 3. B-CAS に通報する
 な、なにをする きさまらー!!

とゆーわけで、continuity_counter 関連をもう少し真面目に処理することにしてみた。ファイル名は同一で上書きしてる。[URI]

◆◇◆

追記。DTV 板 friio スレ 26うわw 295 さんの指摘でエラーメッセージの typo も修正。(ファイル上書き済み)


11月17日(土) MPEG-2 TS あれこれ

DTV 板 「Friio スレッド 26 うわw目」の 624 さんの質問への回答です。長くなる上すでにかなり流れているので、こちらに書きます。

624 [2007/11/17(土) 02:38:41 ID:EGisJZxt] 名無しさん@編集中

 まるも氏のtsselect.exe 
 ・TS解析&指定PIDのみのデータで吐き出し「tsselect」(中の人の指摘で現在改良中)  
 ttp://www.marumo.ne.jp/junk/tsselect.lzh  
  
 のMPEG-2 TS を読み込んでPID 別に、パケット数・ドロップ数 (カウンタエラー数)・スクランブルパケット数を表示する 
 のドロップ数、スクランブルパケット数って何を現しているのですか? 
  
 ドロップ数=取りこぼしたTSパケット 
 スクランブルパケット=スクランブルの解除に失敗したパケット 
 と考えて良いのでしょうか。 
  
 192byteTSは扱えないようですか付属のソースコードの中の188の数字を192にすべて置換してコンパイルしたら192byteパケット情報表示に使えますか? 
 まるも氏のHPに質問するところが無いのでここで書きます。

元質問は以上で、順に回答していきます。まず drop について。

MPEG-2 TS のパケットヘッダには continuity_counter という 4 bit の項目があり、同一 PID のパケットであれば基本的に continuity_counter は 1 つずつ増加していき、4 bit の上限である 16 に到達した場合は 0 に戻るという順で値が設定されます。

ただし、PCR パケットのようにヘッダだけで情報が格納できてペイロードを持たないストリーム (PID) の場合、continuity_counter は、前のパケットと同一の値を持ち続けます。通常のストリーム (PID) のようにカウントアップしていくことはありません。

tsselect の dump (情報表示) モードで表示される drop 数というのは、上で書いたルールに従っていない TS パケットの数を表示するものです。これだけで取りこぼしが発生していると判断すべきではありません。また映像ストリームと音声ストリーム以外で発生している drop は無視しても問題ありません。(番組情報を取得しようとしている場合やデータ放送に対応しようという場合は、それぞれの情報を格納しているストリームでのドロップの有無は重要になります)

次に scrambling についてです。例えば、録画中に唐突に No Card エラーを発症させ、白点滅を開始した(いわゆる NG 病発症の)場合 (なぜ「灼眼のシャナII」で発生しやがりますかね) の録画結果を入力した場合の tsselect の結果表示は以下のようになります。

pid=0x0000, total=   17860, drop=  0, scrambling=0
pid=0x0010, total=    1783, drop=  0, scrambling=0
pid=0x0011, total=     892, drop=  0, scrambling=0
pid=0x0012, total=   87027, drop=  0, scrambling=0
pid=0x0014, total=     357, drop=  0, scrambling=0
pid=0x0023, total=    1646, drop=  0, scrambling=0
pid=0x0024, total=    1783, drop=  0, scrambling=0
pid=0x0027, total=    1966, drop=  0, scrambling=0
pid=0x0028, total=      99, drop=  0, scrambling=0
pid=0x0029, total=      86, drop=  0, scrambling=0
pid=0x0031, total=   17840, drop=  0, scrambling=0
pid=0x0100, total=   30846, drop=  0, scrambling=0
pid=0x0101, total=   34680, drop=  0, scrambling=0
pid=0x0102, total=   34680, drop=  0, scrambling=0
pid=0x0111, total=12885373, drop=  0, scrambling=8942791
pid=0x0112, total=  183128, drop=  0, scrambling=126581
pid=0x0114, total=    3434, drop=  0, scrambling=2186
pid=0x0200, total=    7712, drop=  0, scrambling=0
pid=0x0281, total=  293933, drop=  0, scrambling=0
pid=0x0283, total=   59464, drop=  0, scrambling=0
pid=0x0287, total=     597, drop=  0, scrambling=0
pid=0x07f0, total=   17839, drop=  0, scrambling=0
pid=0x07f1, total=    3568, drop=  0, scrambling=0
pid=0x07f2, total=    8919, drop=  0, scrambling=0
pid=0x07f3, total=   19622, drop=  0, scrambling=0
pid=0x07f4, total=    8598, drop=  0, scrambling=0
pid=0x0840, total=  832538, drop=  0, scrambling=579823
pid=0x0850, total=   44664, drop=  0, scrambling=30731
pid=0x0857, total=    4744, drop=  0, scrambling=3281
pid=0x0858, total= 2109941, drop=  0, scrambling=1466534
pid=0x0859, total=    4745, drop=  0, scrambling=3281
pid=0x085e, total=    2304, drop=  0, scrambling=0
pid=0x085f, total=    3558, drop=  0, scrambling=0
pid=0x0860, total= 1554926, drop=  0, scrambling=1081688
pid=0x086e, total=    1818, drop=  0, scrambling=0
pid=0x0980, total=   58766, drop=  0, scrambling=0
pid=0x098b, total=   40867, drop=  0, scrambling=0
pid=0x1fc8, total=    3573, drop=  0, scrambling=0

えー録画開始後 8 分程度で発症してくれやがりましたので、実に映像ストリーム (PID=0x0111) 音声ストリーム (PID=0x0112) の 3/4 のパケットが scrambling 状態になってくれています。(ワンセグ映像の 0x0281 とワンセグ音声の 0x0283 は無傷なところを見ると、ワンセグにはストリーム暗号がかかってないというのは本当のようですね)

なんつーか、「苦しくったって悲しくったって、コードを書いてりゃ平気な〜の♪だけど涙がでちゃう、だってアニヲタだもの」とか歌いだしたい気持ちだったりするのですがその辺は置いといて。

MPEG-2 TS のパケットヘッダには transport_scrambling_control という項目があり、scrambling では、この項目が 0 以外だったパケットの数をカウントしています。で、実例がここにあるように scrambling は MULTI2 のデコードに失敗したパケットを示していると解釈してよいと思います。

最後、192 byte TS について。一応 204 byte (リードソロモン付き放送波) TS や 192 byte (IEEE1394 シーケンスカウンタ付き) TS も TS パケット 188 バイト部分だけですが、扱えます。

pid=0x0000, total=    2706, drop=  0, scrambling=0
pid=0x0010, total=    2705, drop=  0, scrambling=0
pid=0x0011, total= 6123724, drop=  0, scrambling=0
pid=0x0014, total=  263774, drop=  0, scrambling=0
pid=0x0015, total=  263774, drop=  0, scrambling=0
pid=0x1fff, total=   17538, drop=  0, scrambling=0

これは 204 byte TS を情報表示モードで動かした場合の出力結果です。手元に 192 byte TS がないのでテストはしていないのですが、一応動くように作ったつもりですので、192 byte TS を入れてみてください。

ただし、TS 再構成を行う場合、ちょっとした制限があります。再構成後の出力結果は入力 TS のユニットサイズがいくつであっても、188 byte TS に統一されます。

当初は真面目に入力と同じユニットサイズで出力させるつもりだったのですが、非 188 byte 部分を前後どちらの TS パケットとセットにして扱うべきかを考えて (192 byte の場合は後の TS パケットとペアにして扱うべきで、204 byte の場合は前の TS パケットとペアにすべき) 対応が面倒になり、どーせ非 188 TS なんて使うやついないだろーという脳内会議の結果、再構築の際の出力は 188 byte TS に統一されることになりました。

出力も 192 にしたい場合は、色々大変だとはおもいますが頑張ってください。なお、188 となっている部分をすべて 192 とした場合、192 byte TS の情報表示も正常に動作しなくなると予想されるので推奨しません。

◆◇◆

flv.auo の方は一応動いてファイルが出てくるようになったのですが、まだメタ情報を正しく出力できずに再生できないファイルが量産されています。

なんとか今日明日でテストを終わらせてリリースしたいんですが……ちょっと難しめですな。


11月18日(日) FLV (VP6/MP3) 出力プラグイン

なんとか正常に再生できるものを出力できるようになったので、公開します。ダウンロードは AUF からどうぞ。

On2 VP6 VFW CODEC と MP3 ACM CODEC を呼び出して圧縮した結果を、直接 FLV (Flash Video) 形式に多重化する AviUtl 用出力プラグインです。

当然ながら VP6 VFW CODEC がインストールされていない環境では動作しません。多分こーいったものを欲しがる方の環境には大抵インストール済みだろうと思うので大丈夫でしょう。

これを作成するにあたっては google code の flvmeta 内の flvdump が大変役に立ちました。特に flvmux のテストとデバッグに。

flvdump がなければ動作確認にさらに時間を取られてしまい、リリースが来週に延びてしまっていたことでしょう。また、出力した flv ファイルの再生確認には FLVP を利用しました。両ソフトに感謝します。

◆◇◆

tsselect ですが、ver. 0.1.2 には NULL パケットの drop 数をカウントしてしまう問題と、192 byte TS が与えられた場合にファイル終端で無限ループに落ちてしまう問題があったため、修正しています。最新版は ver. 0.1.4 になります。ファイルは上書き済みですので [URI] から更新をお願いします。

◆◇◆

FLV (VP6/MP3) 出力プラグインに、Lame MP3 で音声を圧縮した場合の大きめなバグが残っていたので修正。最新版は ver. 0.1.1 です。Lame MP3 で出力していてフリーズするといったトラブルが発生していた皆様、ご迷惑をおかけして申し訳ありませんでした。

◆◇◆

さらに FLV (VP6/MP3) 出力プラグインを更新。メタデータに記録するデータレートが kbits/sec ではなく kbytes/sec になっていた問題を修正。最新版は ver. 0.1.2。もー少し落ち着いて確認しなきゃだめだろ。


11月21日(水) FLV (VP6/MP3) 出力プラグイン ver. 0.1.3

結局さらにバグが発見されたため、ver. 0.1.3 に更新。これで最後になってくれればよいのだが。とりあえずリソース管理周りでの問題は……もうないと思いたい。

うーん。オーディオなしで出力した場合に再生できないファイルが出来上がるという書き込みをちらほらと見かけるのだけど手元の環境で再現できてないのでいまいち原因が判らなかったり。

今回の修正で関係しそうなバグを一つ潰せているので、これで解決していれば良いと期待しているのだけど……あんま無駄な望みは持たない方がいいのかもしれない。

◆◇◆

あー早く SCardTransmit() で遊んでみたいのだけど、なかなかこー世の中うまくいかないもんだね。まとまった時間が取れるのは今週末の連休ぐらいかなー。とりあえず 0x90 0x30 0x00 0x00 0x00 を送って正しい応答が返ってくるところまでしか確認できてないや。


11月23日(金) ARIB STD-B25 仕様確認テストプログラム

ぺちぺちとコードを書いて作ってる。IC カード関連の Win32 API 仕様は大体判ったので、MPEG-2 TS の PAT/PMT/ECM 処理の辺りを ITU-T H.222.0 や ARIB STD-B10/STD-B25/STD-B32 を眺めたり、hex ダンプ眺めながら作ってるところ。

いちおー出来上がったら、ソース + VC 2005 プロジェクトファイル (および Makefile) の形で公開する予定。バイナリ配布はさすがに怖いんで無理。

これが終わるまでは、Amazon から到着したリマスター版「天空のエスカフローネ」DVD BOX と「NG恋」は封印というわけでがんばろー。


11月24日(土) FLV (VP6/MP3) 出力プラグインでの可変フレームレート

あーそういう需要もあるのか。プラグイン側からの情報取得方法が判れば不可能じゃないはずなので、あとで調べることにしよう。

今作ってるものが片付いたら着手する。来週の途中あたりから作業開始できるんじゃなかろーかと予想してる。


11月25日(日) ARIB STD-B25 仕様確認テストプログラム ver. 0.1.0

投下 [URI]。以下注意事項。

このテストプログラムを作成するにあたっては TS 抜きを検討してこられた先人方の成果が助けとなりました。個別に名前を挙げることはしませんが、ここで感謝を表明します。

◆◇◆

2012, 2/13 追記更新。最新版は 2/13 に公開した ver. 0.2.5 です。[URI] 左リンクから当該記事に移動できます。


11月26日(月) 今後起こりうるシナリオ (最悪ケース)

前日投下したソースは某所でそれなりに評判のようなのだけど、最悪ケースを想像しておくのも多少は意味があるのではないかと思う。以下は想定されるシナリオ。

地上アナログ停波を3年半後に控えたこの時期に機器認証システムを導入することは事実上無理だろうと考えているけど、放送波ダウンロードという仕組みがある以上絶対に不可能な訳ではないので。

実際、2006 年 5 月 29 日 版 の ARIB STD-B25 Ver.4.2 でも Two Way Authentication System 関連は "Undetermined (To be determined at the start of opration)" ばかりだからなぁ。やる気があるとはとても思えん。導入時の混乱を思えばせめて技術仕様ぐらい固まってないと無理だろう。ただでさえ貿易障壁だと批判されてるのに、さらに敷居高くするようなことできるの?


11月27日(火) 今後起こりうるシナリオ (楽観ケース)

永続リンク貼りたい場合は 11月25日 ARIB STD-B25 仕様確認テストプログラム の方がオススメだったりする。tawagoto.htm の方は最新 7 日分しか置いてないし。まー HTML ソース見ないと判らない不親切なページだから仕方がないか。

それはさておき、昨日は悲観論での予想される未来を描いたわけなのだが、今回は楽観ケースでの未来予想をしてみる。

B-CAS 強化さえなければ、ほぼ確実に訪れる未来だろうと考えている。悲観論での未来への恐怖よりも、こちらの未来への妄想に負けたがゆえに、いくつか受け取った忠告メールにも関わらず例のソースを公開したわけだ。

実際のところデジタルチューナのコスト要因は HD MPEG-2/AAC デコーダと外部出力コネクタ類、そして ARIB 仕様の根性のねじ曲がったデータ放送・文字放送に対応するためのソフトウェアな訳だ。チューナモジュールと USB アダプタチップだけならその辺は全部考えずに済むので原価 $50 程度だろうというのもそんなに外れた推定ではなかろうと思ってる。


11月28日(水) 片山 憲太郎「紅」(スーパーダッシュ文庫)

というわけ で三大炉利ライトノベル最後の 1 シリーズである「紅」に手を出してみた。結果。ちょっぴり設定が鼻につくけどその辺は適当にスルーしてなかなか楽しめた。(B+)

シリーズ最新刊の「紅〜醜悪祭(上)〜」までと「電波的な彼女」既刊3冊まで読了。この後も作家買いを継続することを決意した。続きはまだかな〜。

有川 浩の図書館シリーズ最終巻も購入は済ませてあるのだけど、ハードカバーなせいで通勤中に読むのは辛く、未だに 1 ページも読めていない始末。ここ最近アレコレと活動していたせいでまとまった時間が取れてないせいもあるんだけど。

とりあえず予告済みの FLV 出力プラグインの方にバグレポートが一件入っているのでそちらをさっさと片付けてしまわないとな。


11月30日(金) 地デジ新 RMP

地上デジタル放送の新 RMP 方式について昨日のうちに書くつもりだったのだけど、飲み会に参加したため帰宅時には日付が変わっていた。まだ酒が抜けてないので一度寝てから続きを書くつもり。

◆◇◆

Friio の関連スレッドで「新 RMP」というキーワードを拾ったので WEB で探せる範囲で探してみた。とりあえず日経 IT Pro の「新RMP対応の地上デジタル放送,新たな放送設備の設置が放送事業者の負担に」[URI] の記事の中で次の部分が目を引いた。

 放送事業者は,新RMP対応受信機の発売後,地上デジタル放送のスクランブルをB-CASカードの鍵データと専用ソフトの鍵データの両方で解除できるようにしなければならない。このため放送事業者は新RMP対応受信機の利用者に,専用ソフトの鍵データに対応する暗号情報の送信設備を設置する必要があるという

上の記述を読んで、一瞬、全く別の物理チャンネルで全く別の暗号化を行った放送を始めるのかと誤解してしまったのだけど、冷静に考えればそんな無駄なことをするはずもないと思い直した。

新 RMP 方式というのはいわゆるソフト CAS (柔らかい CAS か……セキュリティも ARIB STD-B25 並に柔らかいと B-CAS カードが完全に不要になってうれしいなぁ) と呼ばれているもののこと。てっきり B-CAS カードとバイナリデータ仕様をそろえて追加投資は不要にするのだろうと思いこんでいたのだけど、記事を見る限りでは B-CAS との互換性は考えていないらしい。

B-CAS 自体は現状実質的にスクランブル鍵配布にしか使われていないので、新 RMP 方式向けの ECM (新) に新しく PID を配分して、それむけに PMT とかの記述方式を多少変更するという形になるのだろう。TS マルチプレクサを多少変更するだけのように思えるので、放送局側での追加負担とか大げさに騒ぐほどのことなのかなーと思ったりするのだけど動作確認とかまで含めれば大変なのかも。

どっちかというと既存の受信機で本当に問題が出ないか (新 RMP 向け ECM が多重化されていても問題なく動作するか) 確認する必要がある家電メーカの方が負担が重いような気がする。

◆◇◆

これ関連の調査中に、ARIB STD-B25 の新しいバージョン (5.0 版) が出ていることに気がついたので公式通販から購入。てっきり英語版 (4.2 版) が最新だと思い込んでいたのだけど甘かったらしい。メジャーバージョンがあがっているけど何が変わったのだろう。到着が楽しみ。


1997年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1998年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
1999年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2000年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2001年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2002年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2003年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2004年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2005年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2006年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2007年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2008年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2009年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2010年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2011年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2012年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2013年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2014年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
2015年 1月 2月 3月 4月 5月 6月 7月 8月 9月 10月 11月 12月
バックナンバー内のリンクは無保証です

[TOP]