ISDB用のチューナーとデモジュレーターを買ってきて、動かせる人ならば、放送されているMPEG2-TSをそのままコピーできてしまいます。PT2はそんな感じの製品です。
じゃあテレビ番組はコピーし放題かというと、そんなことはありません。日本ではB-CASカードの発行許可と、ダビング10の順守によって、番組のコピーが出回るのを防いでいます。
ダビング10とは、無料放送でも10回までしかコピーしてはいけないルールのことです。市販のテレビは全てこのルールを守っています。
ルールはダビング10以外にも色々ありますが、全てのルールを守らないと日本向けのテレビとして認められず、B-CASカードが発行されません。
例えばTSを無限にダビングできるような受信機にはB-CASカードは絶対に発行されません。B-CASカードが無ければ、無料放送のスクランブルすら解除できませんから、いくらMPEG2-TSをコピーしても視聴できません。
一見良さそうな仕組みに見えますが、実は穴だらけです。
スクランブルが掛かったまま構わずコピーし、RF送出機(安いものでも20万円くらいしますけど)を使い、正規のテレビに送れば、何度でも視聴できます。
また、正規のテレビからB-CASカードを奪うこともできます。テレビとB-CASカードに関連付けが無いからできる技ですが、これは仕様の穴ではなく想定通りのはずです。
B-CASは有料放送の視聴管理、つまり、スカパーやWOWOWを何年の何月まで見る資格があります、という情報を管理するためのカードです。もしテレビとB-CASが紐づいていたら、テレビを買い換えた瞬間に有料放送の契約が全て消えてしまいます。そんなことしたら、みなさん怒りますよね?
何が何でもコピーを阻止したい人たち(テレビ局などのコンテンツホルダー?)はB-CASを乱用して、無料放送にスクランブル掛けたり、ダビング10とか、色々頑張っているものの……。
悲しいことに本当に悪い人から見ると、今の仕組みは有っても無くても大差ないです。真っ当に使っている人が不便するだけの嫌がらせ(ダビング1から、ダビング10への移行で少しマシになったけど)です。
メモ: 技術系の話はFacebookから転記しておくことにした。
この記事にコメントする
スクランブルを解除したストリームを再生して初めて、VLCプレイヤーがARIB字幕に対応していることを知りました。

VLCプレイヤーがARIB字幕(青色の字)を表示しているところ
すごいなVLCプレイヤー……。
ネットワーク帯域食いすぎ問題は、試しにNullパケット(PID: 0x1fff)を全て捨てたところ、帯域が半分(地デジで30Mbps → 16Mbps)くらいになりました。
追加でワンセグ、字幕、音声も捨ててみましたが、あまり帯域は変わりません。1Mbps変わるくらいかな…。
VLCプレイヤーさん曰く、動画の平均ビットレートが13Mbpsほどらしいので、TS化のオーバーヘッドと、UDP/IPのオーバヘッドも考えるとこんなもんなんでしょう。

Nullパケットを捨ててBSプレミアムをUDPで送った時の帯域
我が家のPT2は元々Nullパケットを捨てているらしく、デスクランブラ側でNullパケットを捨てようが捨てまいが、特に帯域は変わりませんでした。写真はBSプレミアムのときの帯域です。地デジよりはちょっと高目かな?
メモ: 技術系の話はFacebookから転記しておくことにした。加筆あり。
この記事にコメントする
目次: Linux
Linux DVB APIの仕様を完全に誤解していました。DVB APIではチャンネルを選局する際に、DTV_FREQUENCYプロパティにチャンネルの周波数を指定します。
この仕様がかなり変わっていて、衛星系はkHzで指定しますが、地上波やケーブル系はHzで指定する(ドキュメントへのリンク)んです。
私は今までどちらもHzだと思っていたので、テスト用のアプリを思い切り間違って書いていました。テストアプリでPT2を制御しようとすると、ISDB-Sだけエラーになって選局が出来なかったので、何かおかしいな??とは思っていたのですが、まさかこんな仕様だったとは……。
メモ: 技術系の話はFacebookから転記しておくことにした。追記あり。
この記事にコメントする
無料放送のデスクランブルはうまくいきました。会社の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
会社でLinux用のフロントエンド(チューナー、デモジュレータ、デマルチプレクサ)のドライバを書いていました。商品に使うかどうかは知りませんけどね……。
この辺の機能はDVB Frontend APIとか、単にDVB APIと呼ばれて(わかりやすい図)いるようです。Video For Linux 2(V4L2)と共に、Linux Media Subsystemという名前のSubsystem(ドキュメント)を構成しています。
DVBという名前は欧州の放送規格のDVBに由来していますが、現在はDVBに限らず他の放送規格にも対応しています。
私は日本在住なので、とりあえず日本の放送が映れば嬉しいです。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から転記しておくことにした。
この記事にコメントする
| < | 2018 | > | ||||
| << | < | 06 | > | >> | ||
| 日 | 月 | 火 | 水 | 木 | 金 | 土 |
| - | - | - | - | - | 1 | 2 |
| 3 | 4 | 5 | 6 | 7 | 8 | 9 |
| 10 | 11 | 12 | 13 | 14 | 15 | 16 |
| 17 | 18 | 19 | 20 | 21 | 22 | 23 |
| 24 | 25 | 26 | 27 | 28 | 29 | 30 |
25年10月6日
25年10月6日
25年9月29日
25年9月29日
20年8月24日
20年8月24日
16年2月14日
16年2月14日
25年7月20日
25年7月20日
25年7月20日
25年7月20日
25年7月20日
25年7月20日
20年8月16日
20年8月16日
20年8月16日
20年8月16日
24年6月17日
24年6月17日
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: