BonDriver共有ツール総合 その2

1 ：名無しさん＠編集中：2015/04/07(火) 20:25:07.03 ID:n6IDd8Gi.net

BonDriver共有ツール総合

※前スレ
http://peace.2ch.net/test/read.cgi/avi/1366339738/

321 ：名無しさん＠編集中：2015/09/19(土) 23:12:57.82 ID:W5x7rP0N.net

>>318,319
詳細な解説ありがとうございます。
パフォーマンスの実情を踏まえて安全側にふるのはまさにその通りだと思います。

仰る通り、xtne6f氏がEDCBを改良してくれたのでBondriverのCOM問題は実質解決ですね。

322 ：名無しさん＠編集中：2015/09/20(日) 14:13:51.94 ID:klFkVMgH.net

>>319
解析おつかれさまです。
詳細な報告、非常に参考になります。

323 ：名無しさん＠編集中：2015/09/21(月) 20:06:23.79 ID:GRggE4EQ.net

>>320

GIUDとコマンドの件ありがとうございます。
dllからそれを引き出すとは、BonDriverProxyの作者さん、スゴイ解析力ですね！。
とても関心します。

この様に初期化部分を作って　　　http://www1.axfc.net/u/3537512
動かしてみてます。
結果ですが、確かに[0x0c 読出] [0x0d 読出] [0x14 書込]　コマンドとして
全てS_OKで返って来るところまで来たのですが、今の所グラフの動作には至っておりません。
pIKsPropertySetの引数についていまいち理解できないので、おおよその検討で引数を入れています。


後、guidPropSet値なんですが、これをHDUS用のソースに入っているものと比較した時に
同じ9E1781E1なので不思議に思って調べていくと、ドライバのinfを見るとコメントの
記述の仕方が同じ。ドライバーsysの中を調べてみるとASICENとの記述が両方ともに。
ASICENとHDUSとPLEXでネットで検索すると、HDUSもPXシリーズも台湾のASICEN社の
製品だと理解しました。　
それでHDUSとPLEXのリモコンが完全互換なんだと、納得です。

324 ： ◆SALrG1ld3mTc ：2015/09/22(火) 06:55:06.68 ID:knSVcOol.net

>>323
ｽﾐﾏｾﾝ、良く見たらdwPropID==0x14はデスクランブルさせる場合のオプション用っぽかったので、
本筋には関係無さそうでした
＃M2_DECオプションを有効にする場合は0x14でそれ用の初期化を行う、みたいな感じっぽいです
その辺もまとめると、多分こんな感じになるのかなと思いますヽ(;´ー`)ノ
ttp://pastebin.com/KLvqDwir

325 ：名無しさん＠編集中：2015/09/23(水) 01:01:15.12 ID:FbNy3djd.net

>>324　結果から言いますと、

ついにフィルタグラフにrunが掛かりました。
チューナーに対する初期設定がうまくいったようです。

現状の改変ソースを参考資料としてアップしてみます。
http://www1.axfc.net/u/3538282
一部constがビルドで引っ掛かるとこがありましたので、
constを抜いて、仮にg_M2_Dec = 0を入れて起動させています。

BonDriverProxyの作者さん。モノスゴイ解析力ですねぇ。
コマンドの解釈や、GetKey2の処理をよく新たに見つけ出したものだと驚きます。

一点質問なのですが、M2_DECオプションを有効にした場合
ハード上もしくはドライバ上でデスクランブルすると解釈して
いいのでしょうか？

326 ： ◆SALrG1ld3mTc ：2015/09/24(木) 07:28:51.80 ID:gsOg05yg.net

>>325
> 一点質問なのですが、M2_DECオプションを有効にした場合
> ハード上もしくはドライバ上でデスクランブルすると解釈して
> いいのでしょうか？

全然調べていませんが、恐らくドライバで行われるんだと思います
linux版のドライバにはまるもさん作の「ARIB STD-B25 仕様確認テストプログラム」が
ほぼそのまま組み込まれているようなので、多分windows版でも同じなんでしょう
＃もちろん、内蔵カードリーダにカードを刺しておく事が前提でしょう

327 ： ◆SALrG1ld3mTc ：2015/09/24(木) 07:33:48.18 ID:gsOg05yg.net

あともうちょっと調べたら、>>320で書いた
> 一応、このIKsPropertySetは他のdwPropIDでSetChannel()やらGetTsStream()の中からも使われているようですが、
はやっぱり使われてるみたいですね
特にGetTsStream()から呼ばれる方はコンテンツの復号(MULTI2ではなく独自のスクランブルの)を行うために必須のようです
適当にですがコードに起こしてみました
ttp://pastebin.com/2cxf0Sb5

SetChannel()の方では、m_pcDShow->SetChFreq( iFreq );の後に、
---
m_pcDShow->SetChannel(BSならtrue CSならfalse, TSID, SID);
---
と言う感じで呼びます
TSIDはそのTSストリームのTSID、SIDは(恐らく)そのTSストリームのサービスの適当なSIDか0で、
これらは(SetChFreq()に渡す周波数とともに)iniファイルから読み出して設定します
なお、この処理はS側のみでT側では必要ありません

GetTsStream()の方では、m_LastBuffにデータを取得した後、
---
m_pcDShow->Decode(m_LastBuff->pbBuff, m_LastBuff->dwSize);
---
と言う感じです
手元にはテストできる環境が無いので、ちゃんと動く可能性はだいぶ低そうですが(;´Д`)

328 ：名無しさん＠編集中：2015/09/24(木) 19:44:37.76 ID:YSiFFSy0.net

なにこの難解なスレｗ

329 ：名無しさん＠編集中：2015/09/24(木) 23:27:54.23 ID:cIFUPuu/.net

>>327 結果からですが。

動きましたーー！。
まだ地上波のみですがTvTestで表示できましたー！

衛星側はまだ作りこまないと何もできませんが、とりあえず地上波側の表示はできました。

>>327 の新しいコードと入れ替えて動かしてみるとTSデータの取得が始まって最初の数秒はパケット数が少ないのですが、
途中からパケットが多くなってそこでエラー停止していたので一時バッファだと思われるバッファをを倍にしてみたところ
動作するようになりました。
このバッファを倍にして他に影響ないのかよく理解していないのですが、とりあえずこれで動きます。

この停止が起きた時に１００％ではないのですが、デバイスドライバが離脱することがあることがわかりました。
その辺りの耐久性がないようです。ネットで時々書き込みを見るPLEXチューナーを見失う現象は、
このことではないかと考えています。
このバッファオーバーによるものと思われる対処としては、バッファが溜まり過ぎた時の処理を見直すか、
バッファを増やしてにして他に悪影響ないようであればiniでバッファ量を指定できるようにしようと考えています。

今後はゆっくりですが先に衛星側の作りこみ、チューナーとキャプチャ（現在固定）の選択の仕方変更、
iniでバッファ量を指定、その後TSバッファがらみでメモリコピーを多用しているところがあり、ポインタ処理に
置き換えれば若干パフォーマンスアップを狙えそうな所があるので、その辺りに手を付けるつもりです。

開発資料として現状のソース公開しておきます。

http://www1.axfc.net/u/3539440

BonDriverProxyの作者さん、またまた大感謝です。
これだけのコードを解析から引っ張りだしてくるとは・・・・
今では、何かの実を食べた「能力者」なのではないかと思っていますyo。

330 ： ◆SALrG1ld3mTc ：2015/09/25(金) 07:28:16.61 ID:rOivCOgP.net

>>329
あ、動きましたか
Decode()の処理相当の部分を追いかけてる時に、なんか凄く冗長だったので、無駄だと思われる部分をかなり削って、
でも実はやっぱり必要だったりして…とか少し思ってたんですがヽ(;´ー`)ノともあれ動いたようで何よりです

これらのロジックがちゃんと動くなら、後は普通のBDA系のBonDriverと同じなので、PLEX機器用のBonDriverが
バイナリしかないと言う状況は近々終わりそうですね
どうせならBonDriver_HDUSベースよりも、近年の改良・整理されたBonDriver_BDAをベースにした方が
良いかもしれません
ぜひ良いものをつくって公開して下さいヽ(´ー`)ノ

リンク先のソースでの使用方法をパッと見た感じでは、CBonTuner::RecvProc()でDecode()を呼んでいますが、
呼ぶなら現在の位置ではなく、
---
memcpy(pItem->pbBuff, pSys->m_bRecvBuff, pItem->dwSize);
---
の行の直後に、
---
m_pcDShow->Decode(pItem->pbBuff, pItem->dwSize);
---
とした方が良いんじゃないでしょうか
細かい単位で頻繁にシステムコールを呼び出すよりも、ある程度まとめてから呼んだ方が良いと思うので

また、多分勘違いだと思うのですがCBonTuner::SetChannel()からも呼んでいますが、Decode()は188*nの
単位での呼び出ししか想定していないので、この呼び出しでメモリ破壊が起きてるかも…

あと、もしPLEX_FUNC_0x0CやPLEX_FUNC_0x0Dの呼び出しで得られる結果が毎回同じなら、
鍵(dwKey)は最初に一度つくればDecode()呼び出すたびに毎回つくらなくても良くなりますね

とりあえずそんな感じですよ