コグノスケ

VLCプレイヤーとARIB字幕

スクランブルを解除したストリームを再生して初めて、VLCプレイヤーがARIB字幕に対応していることを知りました。

VLCプレイヤーがARIB字幕（青色の字）を表示しているところ

すごいなVLCプレイヤー……。

Nullパケットの多さにびっくり

ネットワーク帯域食いすぎ問題は、試しにNullパケット（PID: 0x1fff）を全て捨てたところ、帯域が半分（地デジで30Mbps → 16Mbps）くらいになりました。

追加でワンセグ、字幕、音声も捨ててみましたが、あまり帯域は変わりません。1Mbps変わるくらいかな…。

VLCプレイヤーさん曰く、動画の平均ビットレートが13Mbpsほどらしいので、TS化のオーバーヘッドと、UDP/IPのオーバヘッドも考えるとこんなもんなんでしょう。

Nullパケットを捨ててBSプレミアムをUDPで送った時の帯域

我が家のPT2は元々Nullパケットを捨てているらしく、デスクランブラ側でNullパケットを捨てようが捨てまいが、特に帯域は変わりませんでした。写真はBSプレミアムのときの帯域です。地デジよりはちょっと高目かな？

メモ: 技術系の話はFacebookから転記しておくことにした。加筆あり。

DVB APIの不思議な仕様

Linux DVB APIの仕様を完全に誤解していました。DVB APIではチャンネルを選局する際に、DTV_FREQUENCYプロパティにチャンネルの周波数を指定します。

この仕様がかなり変わっていて、衛星系はkHzで指定しますが、地上波やケーブル系はHzで指定する（ドキュメントへのリンク）んです。

私は今までどちらもHzだと思っていたので、テスト用のアプリを思い切り間違って書いていました。テストアプリでPT2を制御しようとすると、ISDB-Sだけエラーになって選局が出来なかったので、何かおかしいな？？とは思っていたのですが、まさかこんな仕様だったとは……。

メモ: 技術系の話はFacebookから転記しておくことにした。追記あり。

ISDB-S/ISDB-Tのデスクランブル

無料放送のデスクランブルはうまくいきました。会社のPCにフルセグが映って満足です。画面が綺麗になったお陰か、仕事中についテレビに目が行ってしまい危険です……。

デスクランブルの実装に速度的な工夫は皆無ですが、PCで実行しているので性能は余裕です。CPU利用率はCore i7 1コア12％程度、地上波の全番組（10番組で十分）を同時処理してもお釣りが来ます。

CPU性能とは別の問題があって、3番組以上同時にデスクランブルしようとすると、B-CASカードorカードリーダーが変な動きをして死にます。エラーも何も出ないので、理由が良くわかりません…。

Facebookにて「B-CASカード内のマイコンかバスの性能限界が2番組では？」と教えていただきました。となるとB-CAS 2枚差しに対応したら、4番組まで処理できそうですね。

データ転送は何か考えた方が良さそうです。今は素朴にMPEG2-TSをUDPに載せて垂れ流していますが、ネットワークへの負荷がハンパじゃありません。1番組で20Mbps強、帯域を浪費します。

プログラム番号を指定して、どのPMTを通すか決め、要らないPIDのパケットは捨てるフィルタを入れた方が良さそうです。家ならば、ギガビットイーサネット前提にした力尽くの解決でも良いです。Wi-Fiだと厳しいかな……。

振り返り

かれこれ1週間くらいで作れましたが、知識ゼロから書き始めたらこんなにうまく行かなかったでしょう。スムーズに進んだ要因は2つかな？

1つ目は昔買ったEarthsoft PT2です。PT2は有志の方によりLinuxドライバが開発されました。お陰でLinux PCがあれば、スクランブル掛かったMPEG2-TSが簡単に取得できました。

会社の開発ボード＋先日作ったドライバでもMPEG2-TSは取得できますが、会社から取得したデータを持って帰ってくる方法が無いんですよね。

2つ目は昔のコードです。MULTI2復号/暗号や、デスクランブル処理は、以前Javaで書いたことがあって、そこから流用しました。一番難しい部分を瞬殺できたのは大きかったです。

細かい中身を忘れてたせいなのか、自分で納得して書いたコードだと確信できるのに、どうしてこれで動くのかちょっと悩んだりする、不思議な体験をしました。

いやはや、昔の自分はほぼ他人ですね。

メモ: 技術系の話はFacebookから転記しておくことにした。加筆あり。

白髪の原因

病気やストレスで「白髪」になるのは、免疫システムの働きだった：研究結果 - WIRED.jp を読んで。

ずっとストレス＝白髪は俗説だと思っていたけど、関係あるんですね。あくまでも、マウスによる実験なので人間にそのまま適用できるかどうか、まだわからないです。

白髪が多いのは昔からなので気にしていませんが、大きな病気とか、ストレスと関連していると言われると、ちょっと気になってしまいます。

今までは頭の上が白くて、前髪やサイドは黒かったのですが、サイドがかなり白髪に侵略されていて、白くなってきました。最近はストレスフリーな生活してるのに変だなー……？

メモ: 技術系の話はFacebookから転記しておくことにした。加筆あり。

ワンセグよりフルセグ

ISDB-Tを受信できるようになり、ワンセグを見ることができるようになりましたが、ワンセグは解像度が低く細かいところが見えません。動きもカクカク（15fps）です。

フルセグの動画も拝みたいところですが、日本でフルセグを見るためにはスクランブルを解除しなければなりません。

日本はなぜか無料放送にスクランブルが掛かっています。ISDB仲間のブラジルではスクランブルは無いそうです。日本は変な国ですね…。

テレビを作るわけではないのでPAT, PMT, ECMだけ処理して、B-CASとの通信部分、Multi2の暗号/復号処理（※）を実装すれば、動作チェックくらいならできるはず。たぶん。

（※）CBCとOFBモードを両方使うので、復号するために、暗号処理が要ります。気になる方はWikipediaをご覧あれ（暗号利用モード - Wikipedia）。

久しぶりに読んだ

久しぶりにARIBの仕様書（ARIB STD-B25）読みました。日本語はありがたいですけど、やや読むのは辛いです。

できればB-CASに送るINSコマンドの値をコマンド例と一緒に書いてくれれば見やすいのになあ。なぜ仕様書の最後に書くんでしょうか。見づらい。

暗号に関しては割と書いてあっても、復号に関する記述が適当で、受信機の設計者はこれ見て作れます？？と要らん心配をしてしまいます。

有料になっていた

以前はARIBの仕様書は気前良く無料で公開されていましたが、有料に変わっていました。お金無くなったんでしょうか？天下のARIBが貧乏臭くなっちゃって……。

これも今の日本のテレビ業界の斜陽を表しているのかもしれません。

単純なデスクランブル

会社のテレビソフトウェアを使えば、ハードウェアでデスクランブル（＝処理負荷が低くて優秀）できますが、要らんシステムがゴチャゴチャくっ付いて来て外せないので死ぬほどウザいです。デスクランブルだけ行うのは不可能じゃないはずですが……ちと面倒です。

ソフトウェアデスクランブルだけ出来ても、番組表も字幕も録画も何もないので、会社で役立つことはほぼなさそうです。お役立ちは目指してないし、個人的にはPCにフルセグが映ったら十分なので、他は要らねっすわ。

メモ: 技術系の話はFacebookから転記しておくことにした。加筆あり。

Linux DVB Frontendドライバ

目次: Linux

会社でLinux用のフロントエンド（チューナー、デモジュレータ、デマルチプレクサ）のドライバを書いていました。商品に使うかどうかは知りませんけどね……。

この辺の機能はDVB Frontend APIとか、単にDVB APIと呼ばれて（わかりやすい図）いるようです。Video For Linux 2（V4L2）と共に、Linux Media Subsystemという名前のSubsystem（ドキュメント）を構成しています。

DVBという名前は欧州の放送規格のDVBに由来していますが、現在はDVBに限らず他の放送規格にも対応しています。

衛星（ISDB-S）と地上波（ISDB-T）

私は日本在住なので、とりあえず日本の放送が映れば嬉しいです。ISDB-S, ISDB-T用のチューナー、デモジュレーターのドライバを作ってみました。

無事、会社の開発ボードで放送波が受信でき、開発ボード → PCにTSを投げつけることで、PCのVLCプレーヤーでワンセグを拝めました。VLCプレーヤー便利です。

フロントエンドって何ですか？状態のド素人からの出発で、1人でセカセカ3週間くらいでした。チューナーもデモジュレーターも、単品で独立したLSIが多いのでわかりやすい（※）です。フロントエンド系に詳しくて、Linuxのドライバ開発に慣れている人なら、もっと早くできるでしょう。

実装したドライバはLinuxの開発MLに送ってみたけれど、今のところ特にお返事ありません。悲しい…。

Linuxのフロントエンドドライバの対応状況は結構偏っています。DVBは手厚いですがATSC, DTMB, ISDBは手薄に見えます。もしご興味ある方はDVB以外にトライしてみると、喜ばれるのではないでしょうか？

（※）悲しいことに、一番訳が分からなくて手間が掛かるのは、いつも自社のSoCです。未だに良くわからん部分があり、Linuxの開発MLに投稿できていません。

メモ: 技術系の話はFacebookから転記しておくことにした。加筆あり。

最初の設計が肝心

初期段階の設計失敗を、最終段階の設定や運用で取り返そうとすると苦労するよね…。と思った良い例だったので、つらつら書いてみます。

Windows 7（Vistaからかも？）あたりからWindows Update後にコンピュータを自動再起動する仕組みが導入されました。この仕組みは不評らしく、自動再起動を無効化する方法を紹介するページがたくさん見つかります。

一方のMicrosoftは最新セキュリティパッチを当てた状態のWindowsを使ってほしいため、自動再起動を無効化する手段を片っ端から潰しています。

しかしユーザー側は諦めません。Windows 10時代になっても、あの手この手で「自動再起動を無効化する方法」を紹介するページがたくさん見つかります。Windows 7, 8, 10と導入から時間が経ってもこの有様ですから、相当嫌われていることがわかります。

挙句の果てにMicrosoft公式サポートが自動再起動を無効化する方法を紹介（Windows 10 / Windows Server 2016のWindows Update後の自動再起動の制御方法 - Japan WSUS Support Team Blog）しているほどですから、Microsoftだってこの仕組みが鬱陶しいことに気づいています。

直したいけど直せない？

でもどうして改善されないんでしょうか？

この問題の根本原因はWindows Updateの仕組みがイマイチ、つまりいちいち再起動を必要とすることです。Update後の再起動を不要にすれば問題は解決します。

当然この程度のことMicrosoftも分かっているはずなのに、いつまでも取り組まないところを見ると、おそらくかなり初期段階のミスというか設計不良をやらかしていて、直すのが困難なのでしょう。

根本原因を直せない以上、場当たり的な方法（自動再起動）で誤魔化し続けるしかなく、Microsoftとユーザーの不毛な争いが続くんですね。

私もやらかしたことありますけど、設計段階の大失敗が量産後に判明することは割とあります。私がやらかした問題は直し方がわかっていますし、あちこちで火を噴いている問題児なのですが「直すと影響が大きい」という理由で、小手先の対応しか取らないまま、数年放置されています。

規模や難易度が全く違いますが、Windows Updateの自動再起動問題と同じ構造だなあ……、なんて思いました。

メモ: 技術系の話はFacebookから転記しておくことにした。