14/06/22 16:21:38.42 9K15rOHz
>>400
実は当方もアカウントつくってからそう思いました(;´Д`)
>>402
そんな感じです
BonDriverProxyは、BonDriverインタフェースに対応しているアプリと実際の使用BonDriverをTCP経由でプロキシするものです
基本的にはリモート視聴用途ですね
このプロキシの際の副次的な機能として、クライアント1と2から同じBonDriver(大抵の場合は＝物理チューナです)を要求された場合は、
そのチューナからのTSストリームを両方のクライアントに配信します
なので、同じ物理チャンネルなら複数のユーザが同じチューナを利用して視聴できる形になります
＃プロキシ対象がBonDriver_LinuxPTなら配信対象は生TSストリームになるので、同じトラポン内の別サービスを
＃それぞれのクライアントが利用するというのも可能です
＃例えばクライアント1はフジテレビnextを、クライアント2はフジテレビoneをみる、みたいなパターンですね
またチューナを共有しているユーザ同士の間で、チューナのチャンネル変更権の優先度を設定する事が出来ます
クライアント1はいつでもチャンネル変更できるけど、クライアント2は優先権を持ったユーザが接続していない場合のみ変更できる、
みたいな設定です
これは、誰かがリアルタイム視聴してても録画機能はチャンネルを持って行けると言う様な用途を想定しています
まあぶっちゃけSpinelと同じようなもんだと思ってもらえばそれ程間違いは無いかと
411:login:Penguin
14/06/22 16:34:44.40 9K15rOHz
>>403
BonDriver_HTTPですね
あれはrecpt1をhttpプロトコル経由でチャンネル指示を受けてストリーム配信開始するように改造したのを、
TVTest等から受けられるようにするための物なので、Linux側のアプリがBonDriverインタフェースに
対応していると言うわけじゃないんですよね
＃ちなみにrecpt1のHTTPサーバ版にはド直球のスタックバッファオーバーランがあるので、そこを修正してない人は
＃外部への公開はお勧めしません
>>404
まあそこですよね
ユーザ視点で見れば、正直現状で困ってないのなら移行する必要性はあんまりない感じです
当方の提案はどっちかと言うと、ユーザではなく開発者向けのものですね
>>406
そうなんですが、現在のところ(少なくとも日本では)一番メジャーだと思われるrecpt1では使われてませんし、
BonDriver層はどっちかと言うとそれよりもう一段上位層に位置してそうなイメージです
Windowsでは事実上標準のインタフェースにする事で、Windows用のソフトを移植しやすくなるんじゃね？てのもあります
EDCBのUIはともかくエンジン部分とかですね
>>407
LNB用のioctlに引数がついてpt3_ioctlと同じになってます
412:login:Penguin
14/06/22 17:01:16.22 9K15rOHz
>>408
BonDriverは、そのドライバ毎にスペース/チャンネルと実際のデバイスの物理チャンネルとの対応を内部的に持つ形になります
例えばUHFでの物理チャンネルが27でも24でも、BonDriver側の設定で、アプリからは同じチャンネルに見せる事が出来ます
テレビのリモコン番号のイメージですね
＃ただ、おそらくもっともメジャーなBonDriver対応アプリであるTVTestでは、チャンネルスキャンする事によって、
＃そこから更に内部的に放送局とあるBonDriverでのスペース/チャンネルとの対応を把握して保存する形なので、
＃「アプリに同じチャンネルに見せる」と言う機能はあんまり活用されてない感じですが
スペースに関しては便宜的な物で、BS空間とCS110空間を分けて扱いたい、みたいな場合に使う感じです
と言うのが当方の理解です
当方もBonDriverインタフェースの考案者に意図を確認したわけではないので、各種BonDriverの挙動からの判断となってしまいますが…
で、BonDriver_LinuxPTで言えば、スペースは使用しておらず、0固定です
具体的には、PT3のS0を使う場合、スペース0のチャンネル0はBS朝日、スペース0のチャンネル17はNHK-BS1、みたいな感じで
confファイルに設定してます
BonDriverインタフェースに移行するメリットは、開発者的には>>402さんの通りですが、
ユーザ的には正直あんまりないかもしれません
＃BonDriverProxyを使うと言う前提でなら、>>410で書いた様な運用が可能になりますけども
>>409
Ex版の方は使用BonDriverの選択を自動にして、クライアントからの要求毎になるべく少ない数のチューナで対応しようと言う物です
VirtualPTみたいな機能が欲しいって声があったので、つくってみたって感じの機能です
チューナの共有は無印でも可能です
例えばepgrecが起動するアプリからBonDriver_Proxyを使用して(チャンネル変更権を設定して)TS保存する形にすれば、
別アプリからやはりBonDriver_Proxy経由でそのチューナがリクエストされた場合には、そちらには(チャンネル変更権を
設定していない限り)録画中のチャンネルのTSストリームが配信されます
413:login:Penguin
14/06/22 17:10:05.18 yqCR4suw
なるほど
自分で言っておいてなんだけど、アプリケーションのインターフェースをBonDriverで統一したとしてもWindowsアプリをLinuxに移植できる訳じゃないよね？
いまいちメリットを理解出来てないw
414:login:Penguin
14/06/22 17:37:04.90 BasD8bs2
>>412
全然ついていけんｗ
BonDriverのことがわからんのがいかんな・・・
なんとかBonDriverProxy動くとこまで行きたいけど・・・
415:login:Penguin
14/06/22 20:16:11.97 p+R10FJz
・１つのチューナーで同じチャンネルを複数プロセス（録画･視聴･EPG取得）で同時利用できるので
・同じチャンネルの連続した番組を１つのチューナーでそれぞれに糊代をつけたまま録画できる
・野球などの録画延伸とEPG更新が同時にできる。
が簡単にできるようになるね
で質問なんだけどチューナーの使用状況（使用の有無･チャンネル・用途）がわかるAPIてあるの？
416:login:Penguin
14/06/22 20:34:24.09 AWfMcXnb
以下、ユーザー視点の勝手な感想ってことで。
WindowsのBonDriverの考え方を持ち込むのは？だと思う。
新しいチューナーが出たとして、そのチューナーのLinux用ドライバに加えて
BonDriverを書かなきゃ使えないということになるよね？それはさすがに厳しす
ぎるだろうと思うなあ。現状見てもPT3でchardevドライバ版しか使えないって
ことだろうし。
他の人も書いているけど、LinuxにはDVBがすでにあるのだし、サーバー側の
チューナー制御がDVB経由なら対応チューナーが一気に増えると思う。DVB
ドライバがあるFriio白,PT1,PT2,PT3,PX-S1UDが使えるのではないのかな？
DVB用BonDriverで良いのかもしれないけど。あとサーバー側でB25デコード
機能は欲しい。
WindowsでSpinel使っていたから、Linuxには、ネットワーク経由でチューナー
共有や制御できる機能がないのは残念だなと思っていたので期待してる。
417:login:Penguin
14/06/22 20:47:00.62 PoQYfK5M
確かにBonDriver_DVBとか作ってそこでB25デコードすりゃ使い勝手はよさそうだな
だけどBonDriverのinterfaceでは視聴してるサービス知らせるすべが無いから
CSのデコードは全サービスをデコードするしか無いからなぁ
418:login:Penguin
14/06/22 20:55:30.82 p+R10FJz
>CSのデコードは全サービスをデコードするしか無いからなぁ
FUSE_B25はどうしてる？
419:login:Penguin
14/06/22 22:11:49.31 yqCR4suw
LinuxにBoDriverインターフェースを採用する話とBoDriverProxyの話が混ざってよくわからなくなってる
420:login:Penguin
14/06/22 23:25:35.72 9K15rOHz
>>413
> アプリケーションのインターフェースをBonDriverで統一したとしてもWindowsアプリをLinuxに移植できる訳じゃないよね？
ですね
単に現在BonDriverインタフェースを使ってるアプリが移植しやすくなると言うだけです
>>414
PTの刺さってるLinuxマシンがあるならすぐに試せますよ
まあ今LinuxでBonDriverインタフェース使ってるアプリはBonDriverProxy本体とそのおまけのサンプルアプリだけでしょうから、
それでしか試せませんが…
例えばBonDriver_Proxy.soの指定BonDriverをBonDriver_LinuxPT.soとして、BonDriver_LinuxPT.soは/dev/ptXvideo0
を使う様に設定して、サンプルアプリではBonDriver_Proxy.soを使用して複数起動すれば、チューナの使用は一つだけですが、
起動した数だけの録画が行われるはずです
上記設定で、
$ ./sample -b ./BonDriver_Proxy.so -s 0 -c 0 -t 10 -o a.ts & sleep 3;./sample -b ./BonDriver_Proxy.so -s 0 -c 17 -t 5 -o b.ts
な感じで実行した場合、a.tsには最初の3秒がBS朝日で残りの7秒がNHK-BS1、b.tsには5秒のNHK-BS1が出力されるはずです
＃ただしこの例の場合、新たな接続があるたびにチャンネル変更要求が投げられそれが受理される形になるので、
＃その度毎に既存接続のストリームにはドロップが発生する事になるでしょう
＃また、サンプルアプリで保存されるTSは生ストリームなので視聴するにはb25を使うなどしてデスクランブルが必要です
421:login:Penguin
14/06/22 23:30:52.96 9K15rOHz
>>415
> 使用の有無
この判定は出来たりできなかったり、BonDriver毎の実装依存です
Windowsの例で言うと、大抵のBonDriverは誰かがチューナを使ってる状態だと、CreateBonDriver()での
インスタンス取得に失敗するか、インスタンスが得られても続くOpenTuner()が失敗します
BonDriver_Proxyの場合はチューナが使用されていても共有する関係で、たとえ使用されていても成功するので
使用されているかどうかはわからないですね
> チャンネル
IBonDriver2.hの
virtual const DWORD GetCurSpace(void) = 0;
virtual const DWORD GetCurChannel(void) = 0;
が現在の(BonDriverとしての)チャンネル取得APIです
ただし、まだオープンしていないチューナの現在チャンネルを知る事は出来ません
また、チューナをオープンして、一度もチャンネル設定のリクエストを出していない状態でも知る事は出来ません
> 用途
これに関してもBonDriverインタフェースとしてはその情報は持っていませんね
なので、録画アプリは自分が使用するチューナのみに関しては被らないようにしなきゃいけないのは変わりません
なお、その辺りの空きチューナ管理なども行い、アプリからはどのチューナを使うのか意識しないでも良い
BonDriverも存在します
＃移植してませんが、BonDriveProxyのExの方はそう言う感じの用途向けです
422:login:Penguin
14/06/22 23:57:00.37 BasD8bs2
>>420
やっぱわかりずらいな。
BonDriverProxyは起動するんよね？
BonDriver_Proxy.confのBONDRIVERにBonDriver_LinuxPT.soを設定する。
アドレスとポートは起動したBonDriverProxyのを指定。
BonDiver_linuxPT.confには/dev/pt3video0を指定する？
地上波チューナ使う時は別途
BonDriver_LinuxPT-T.soとか別名のsoとconfつくってデバイスを変更する？
sampleが地上波とCSを同時に使うとかはどうするんだろう？
BonDriver_Proxy1とか作って増やすのかな？
423:login:Penguin
14/06/23 00:00:37.24 9K15rOHz
>>416
とりあえずchardevドライバ版でつくったのは、単にそれが一番普通に使われてる感じだったからなんですよね
PTシリーズと、あとPX-W3PEもPTシリーズのchardevドライバと(多分意図的に)インタフェースは互換みたいです
＃デバイスオープン直後に恐らくスクランブル関連のAPI呼んでますが、それ以外は全く同じです
感覚としては、BonDriver_LinuxPTを雛形にすれば、他のデバイス用のBonDriverつくるのは(デバイスへの
インタフェースが公開されてる限り)そんなに手間ではない感じかなと思ってますが…
BonDriver_DVBは良いアイデアですね
時間が出来たら調べてみます
デスクランブルは…例の著作権法改定のからみで開発者的にはかなりスリリングなので、BonDriverProxyでは
意図的に避けてるんですよね…
＃Windows系ではデスクランブル機能を持ってたソフトはTVTestはじめ軒並み機能削除か自粛しちゃいましたが、
＃Unix系ではまだごく普通にGitHubに公開されてたりするのでちょっと驚いてるところです
>>417
今時のB-CASカードなら処理速度的には大丈夫なのかなとも思いますが、PT二枚刺しとかでサービス数が
多いトラポンを数チャンネル同時とかはやっぱり厳しいでしょうか
アプリ側でキャッシュを持てば多少マシかな…
まあぶっちゃけsoftcas化がもっとも簡単なんですが、もっとも黒いので選択肢に入りませんね…
424:login:Penguin
14/06/23 00:39:47.52 DN2vhIfe
>>422
例えば以下PT3一枚の例で話すと、まずBonDriver_LinuxPT.soは物理デバイスと一対一なので四つコピーをつくります
で、それぞれ用にconfもコピーして、使用デバイスに対応させます
e.g.
BonDriver_LinuxPT-S0.so
BonDriver_LinuxPT-S0.so.conf -> /dev/pt3video0を指定
BonDriver_LinuxPT-S1.so
BonDriver_LinuxPT-S1.so.conf -> /dev/pt3video1を指定
BonDriver_LinuxPT-T0.so
BonDriver_LinuxPT-T0.so.conf -> /dev/pt3video2を指定
BonDriver_LinuxPT-T1.so
BonDriver_LinuxPT-T1.so.conf -> /dev/pt3video3を指定
この時点でもサンプルからBonDriver_LinuxPT-S0.so等を指定すれば使えます
425:login:Penguin
14/06/23 00:42:26.76 DN2vhIfe
で次に、クライアント側のBonDriver_Proxy.soは、基本的には対象BonDriverと一対一なので、これも四つコピーをつくります
そのそれぞれのconfは、上でつくったBonDriver_LinuxPT.soのコピーをそれぞれ指定します
e.g.
BonDriver_Proxy-S0.so
BonDriver_Proxy-S0.so.conf -> BonDriver_LinuxPT-S0.soを指定
BonDriver_Proxy-S1.so
BonDriver_Proxy-S1.so.conf -> BonDriver_LinuxPT-S1.soを指定
BonDriver_Proxy-T0.so
BonDriver_Proxy-T0.so.conf -> BonDriver_LinuxPT-T0.soを指定
BonDriver_Proxy-T1.so
BonDriver_Proxy-T1.so.conf -> BonDriver_LinuxPT-T1.soを指定
また、confのADDRESSとPORTはもちろんBonDriverProxyを起動した際の引数と同じものを指定します
この状態で、サンプルからBonDriver_Proxy-S0.soを指定すれば、プロキシを通してBonDriver_LinuxPT-S0.soが使用され、
BonDriver_Proxy-T0.soを指定すればBonDriver_LinuxPT-T0.soが使用されます
サンプルからBonDriver_Proxy-S0.soを使用中に、別端末からサンプルをやはりBonDriver_Proxy-S0.soを指定して起動すると、
BonDriver_LinuxPT-S0.soが共有され、/dev/pt3video0からのTSストリームが両方に配信されます
とまあこんな感じですがわかるでしょうか
426:login:Penguin
14/06/23 01:27:13.24 dq7KpCTh
>>425
ありがとう。だいぶわかってきた。
もう寝るけどｗ。むずかしいね。
427:login:Penguin
14/06/23 10:25:28.82 quj7m4zR
>>423
まあ、DVBがあるからって要らないってことはないよね。
実際、インストールベースを考えるとWinでの開発が先行するだろうし。
よくわからないんだけど、BonDriver_DVBができたら種類の異なるチューナを隠せるんかな。
例えば、PT3とFriioを持ってるとき、PT3が埋まってたらFriioを使うとか。
今うちでは、もっと上位でそれをやってるんだよね。
Shell Script書いて、recpt1とrecfriioを状況に応じて使い分けるみたいな。
ちなみにそのために、recpt1等をいじって終了ステータスを手直ししてるけど。
スクランブルについては、法的問題以外に純粋に作りの話として、
外部にした方がいいんじゃなかろうか。
ま、それは感覚の問題だけど。
428:login:Penguin
14/06/23 12:23:34.00 DN2vhIfe
>>427
> よくわからないんだけど、BonDriver_DVBができたら種類の異なるチューナを隠せるんかな。
> 例えば、PT3とFriioを持ってるとき、PT3が埋まってたらFriioを使うとか。
元々BonDriver層はPT3やFriioみたいに別のデバイスの差異を吸収するための物ですから、DVB対応かどうかは関係なく、
アプリからはチューナの差異は隠される事になります
しかしDVBによってそれらのデバイスが同じインタフェースで扱えるのなら、それのインタフェースに対応するだけで
複数デバイス対応のBonDriverになるので、その分開発の手間が減って助かるでしょうね
チューナが使われてるかどうかまで管理するかどうかは実装次第ですが、どっちかと言うとアプリ側に任せるのが普通です
ただこの場合、例えば録画アプリが使おうとしてるチューナを別プロセスが使ってしまうと録画失敗する事になるので、
そうならないようにのチューナ共有アプリのチャンネルロック設定です
＃もっとも、チューナを使う全部のアプリが共有アプリ経由でアクセスしないと管理できませんが…
429:login:Penguin
14/06/23 12:32:08.06 DN2vhIfe
> スクランブルについては、法的問題以外に純粋に作りの話として、
> 外部にした方がいいんじゃなかろうか。
> ま、それは感覚の問題だけど。
その辺は当方もそう思ってます
一つの全部入りの大きなプログラムより、小さな専用ツールを組み合わせて使う方が、何かと小回りが利くので好きです
例えば今あるサンプルを特にいじらなくても、スクランブル解除して保存したいなら
$ ./sample -b ./BonDriver_Proxy-S0.so -s 0 -c 17 -t 60 | b25 -v 0 -p 0 /dev/stdin /path/to/file.ts
みたいな感じで行けますし、vlcにudpストリーミングしたいなら
$ ./sample -b ./BonDriver_Proxy-S0.so -s 0 -c 17 | b25 -v 0 -p 0 /dev/stdin /dev/stdout | nc -u 192.168.0.101 12345
で行けますね
＃ncはudpでのこう言う用途に関しては微妙な気もしますが
録画やチャンネル変更用のアプリからは、こんな感じでサンプルに適切な引数付けて起動したり殺したりするだけで
良いワケですから、PTユーザに関しては、ある意味BonDriver対応は既に出来てると言えばできてますね…
＃この例のままでは、クライアントが多数接続してくるとB-CASカードの処理能力の都合でデスクランブルが
＃間に合わなくなる可能性はありますが
430:login:Penguin
14/06/23 15:51:20.66 quj7m4zR
>>428
> チューナが使われてるかどうかまで管理するかどうかは実装次第ですが、どっちかと言うとアプリ側に任せるのが普通です
それについては、チューナ側がTest-and-Set的になっててほしい気がする。
コメントされてるとおり、アプリ同士で協調ってちょっと大変だし。
というか、デバイスアクセスの時点でそうならないんかな。
recpt1のソースなんか見ると、SET_CHANNELのioctlの時点でそれわかるみたいだし。
ただ、じゃあそれで使用中の場合次はどれを、というのはアプリでいいと思うんだけど。
>>429
> 一つの全部入りの大きなプログラムより、小さな専用ツールを組み合わせて使う方が、何かと小回りが利くので好きです
まあ、Linux使いならそういうUNIX的感覚があるんじゃないかとか思ったり。
431:login:Penguin
14/06/23 17:21:34.69 st9m78/+
なんか話が混ざっててややこしくなってるけど
アプリってのはBonDriverProxyのことじゃないの？
Spinelしか使ったことないけどBonDriverProxyがSpinel相当ならば
BonDriverProxy側で排他制御してくれるから全チューナーをBonDriverProxy通して使ってれば
録画、視聴アプリ側では排他制御は気にしなくてもいいでしょ
432:login:Penguin
14/06/23 19:27:50.38 DN2vhIfe
>>430
ああ、大抵の実装ではあるデバイスがあるアプリから使用されているのを、別のアプリからオープンしようとすると
失敗するので、「試してみればわかる」のはまあ可能なんですが、録画失敗を避ける為にはそれじゃダメですよね
「チューナの録画での使用予定まで全アプリで協調して制御する」あるいは「使われてても強制的に奪う」事が必要になります
前者は多分無理なので、結局チューナへのアクセスは必ず何らかの管理機構を通して行い、その管理機構が後者の処理を
行うのが現実的、と言う事になります
例えばepgrecが、録画が始まるとリアルタイム視聴用に起動してたrecpt1を殺すとか、そう言う話ですね
チューナ共有アプリのチャンネルロック設定も効果としてはこれと似たような物ですが、プロセスごと殺すのではなく、
視聴用のクライアントからそのチューナのチャンネル制御権を奪うと言う物ですね(録画と視聴チャンネルが同じなら、
そのまま視聴が続けられます)
>>431
> Spinelしか使ったことないけどBonDriverProxyがSpinel相当ならば
> BonDriverProxy側で排他制御してくれるから全チューナーをBonDriverProxy通して使ってれば
> 録画、視聴アプリ側では排他制御は気にしなくてもいいでしょ
これは(どのクライアントが録画用/視聴用かが正しく設定されていれば)その通りです
確かにBonDriver全般の話とチューナ共有ソフト(今の場合はBonDriverProxy)の機能の話が混ざっちゃってる気がしますね
Linuxユーザにはどちらもなじみの無い物かもしれないのでしょうがない部分もあるとは思いますが
433:login:Penguin
14/06/23 21:01:28.61 v8soB1YB
>>416
chardev→BonDriverの共通ラッパー書けば終わりやん(^_^)
434:login:Penguin
14/06/23 22:41:44.55 UrqYkzjU
>>423
設定ファイルのデバイスファイル名をpt1にするだけで
「PT2」でも動作しました。
#DEVICE=/dev/pt3video0 → #DEVICE=/dev/pt1video0
435:login:Penguin
14/06/24 15:49:44.48 CGRN0YX5
>>432
あーなるほど、録画失敗を避けるってのは録画の方を優先したいってことね。
わかるわかる。
それなら、fuserとかでプロセスわかるんだから同じ方法でなんとかなるんじゃなかろうか。
fuserが中で何やってるかよく知らないけど。
でもそれだと、使用中の誰かがリアルタイム視聴なのか録画なのかまではわからないか。
まあ、それについては今度こそアプリ側で
自分の管理対象プロセスかどうかチェックするってことでいいんじゃないかという気がする。
436:login:Penguin
14/06/24 16:41:22.96 v2ma19RF
つまり、プロセスを殺せば良い。
437:login:Penguin
14/06/25 23:13:25.70 alAbLvBn
recpt1 でちと気になったんだけど
coreライブラリに分かれた c9b1d21c5035 からかな、SID指定でTS保存すると字幕情報が取れてない気がするんだけど、みんなどう？
地上波だと PID 0x0114 あたりだと思うんだけど、
ffmpeg で確認するとPIDはあるんだけどtsselectするとパケット無いんだ
古い recpt1 に戻すとちゃんと出てくる
CSもPIDは違うんだけど字幕ないみたい
SID未指定のフルTSはまだ試してない
438:login:Penguin
14/06/26 00:27:04.74 jxSnb/To
UNA版のhttpパッチを使ってるなら同梱されている削除PID追加パッチを適用してないか？
>３については通常の映像・音声の再生に支障が無いのを確認していますが無保証です。
>また字幕・5.1chなど私が必要としていないものについては何も検証していません。
439:login:Penguin
14/06/26 00:53:33.39 S6+AoS75
>>438
おお、完全に私の早とちりでした。
tssplitter-apnd.diff は当ててないつもりが当ててしまっていたようです。
c8688d7d6382 DLしなおして素のまま build したら平気でした。
ごめんなさい。ありがとうございます。
440:login:Penguin
14/06/26 19:10:45.88 ctsx0K82
>>434
その辺はPT1/2とPT3のchardev版ドライバの開発者の方々が、インタフェース互換でつくってくれてるからですね
>>435
>>436
デバイスを使用しているプロセス列挙と、それらが行ってるのが録画なのか視聴なのかが判別できるのであれば
(やりようはいくらでも有るでしょう)、録画開始時に確認して、チューナが足りなければ視聴用プロセス殺せば
とりあえず用は足りますけどね
まあ結局のところ、チューナ共有にメリットを感じるかどうかは人それぞれでしょうから、現状困ってないし
わざわざ導入する事もねぇな、と言うのも一つの考え方として有りだと思います
441:login:Penguin
14/06/26 19:16:01.07 ctsx0K82
そう言えばここに書こうと思って忘れてたんですが、w3peとかのplexチューナ持ってる方、もし時間があったら
URLﾘﾝｸ(github.com)
のdevelopブランチの方のBonDriver_LinuxPTを試してみてもらえないでしょうか
上の方で書いた通り、対応簡単そうだったのでとりあえずコードだけは書いてみたんですが、
当方実機を持っておらず動作確認は出来ていないもので…
442:login:Penguin
14/06/26 22:31:25.24 IGubDjYd
>>ctsx0K82
今出先でザラっと流れ見ただけなんだけど
KVM上のWindows仮想環境で録画ソフト類を動かしておいて
hostのPTxにBondriverをTCP/UDP越しにつないで録画しながら同じチャンネルや空きチャンネルを
LAN内のクライアントでTvTestで見たりできるようにできる？
今はML110G6をファイルサーバ兼仮想環境サーバにしてあって
PT2をPCIパススルーでKVMゲストのWHS2011から見えるようにして
spinel+TVrockで録画管理と自動再エンコードしながらLan内の
各部屋のクライアントのWindowsでTVtestで見れるようにしてるんだ
録画したものはWHSがDLNAサーバも勝手にやってくれるんだが
たまにKVM上のPT2がこける事があるのでパススルーしなくても良くなるなら
ワールドカップ終わったところでやってみる
443:login:Penguin
14/06/26 23:41:20.94 IGubDjYd
排他制御とか録画優先とかはプロキシーにホストのIPとデバイスのIDで優先度つけたらどう？
niceみたいな感じでIPとデバイスIDごとに優先度をconfに書けば録画鯖のIPからのリクエストは
優先度の低いホストの接続を中断して切り替えちゃう
父ちゃんのホストはかーちゃんのホストより優先度が低いとか
デバイスの優先度は最優先のホストに対して決めておいて
優先度の低いホストからはデバイスの優先度も低い順に割り当てられる
切断する場合ホストの優先度＞デバイスの優先度にしておいて
優先度の高いリクエストがきたら容赦なく切断されるで良いと思う
ついでに希望としては昔あったVirtualPTみたいに
チューナー共有サーバ形式でクライアント側のBonDriverは
UHF/BS/CS全部を仮想化したチューナとしてサーバと通信する
サーバ側はクライアントのリクエストを空きチューナに
ホスト/デバイスの優先度順で割り付けるとかできるともっと良いなぁ
クライアントのドライバはBondriverとしての
インターフェイスとサーバと通信する機能だけで
サーバ側は共有制御部分と実デバイスのドライバに分かれる感じで
今はUHF/BS/CSごとにチューナーとドライバをセットで指定してるので
クライアントドライバからは実際のデバイスを隠蔽できる方が録画サーバも作りやすいんじゃないか？
444:login:Penguin
14/06/27 06:31:04.84 6gm02sDZ
>>442-443
PT2+Spinelの分の機能をホスト側に移動したいと言う事ですね
それなら可能だと思います
ただし、BonDriverProxy自体はデスクランブル機能は持っていないので、それに関してはそれぞれのクライアント側で
行う必要があります
＃そこに関しては、各クライアントにB-CASカード用意するなり、B-CASカードの処理能力的に大丈夫な範囲で
＃BonCasLink等でまとめるなりして下さい
> 排他制御
これに関しては、現在(クライアント側の自己申告で)チャンネルロック権を持つか持たないかの二値だけで制御しています
個人的な要件として、録画用クライアントに確実にチャンネルロック権を持たせる事が出来る事のみが重要だったので
それで事足りているのですが、段階的な優先度の設定も実装するのは多分そんなに面倒ではないと思うので、
必要そうなら考えてみます
＃なお、本来的には自己申告でなくサーバ側で設定を持つのが筋ですが、確実に設定が煩雑になってしまうので躊躇してます
> VirtualPT
当方シンプルなのが好みだったので、サーバ側とクライアント側のBonDriverは(機能的には)一対一対応なのをまずつくったのですが、
確かにVirtualPTみたいな制御がしてほしいて声も結構あったので、サーバ側をフォークしてBonDriverProxyExとして公開してます
気が向いたらこっちも移植すれば良いのかな…
チューナの仮想3波化は、BonDriver_RDCTと言うのがソース含めて公開されてるので、上記BonDriverProxyExのクライアントに
設定したBonDriver_Proxyをそれ経由で使えば、要望されてる機能は大体可能かと思いますよ
445:391
14/06/29 04:54:52.92 NiUCYq/U
空気読まずに投下
destroy_queue(p_queue);
をいきなり叩いているのが原因ですね。
p_queue->buffer がリークしている。
暫定パッチ作ったけど欲しい？
夜中の変な勢いで書いたものだけど。
446:login:Penguin
14/06/29 06:34:25.26 NWynDbUH
いらねえよ！
447:login:Penguin
14/06/29 09:12:09.58 Y8Pe/3cq
＞445
ください！
448:login:Penguin
14/06/29 13:01:42.94 U7BI4yqJ
質問です。
chinachuで深夜3:05-5:05の番組を録画予約しました。
ところが直前のサッカー中継が延長され、見たい番組は録画できませんでした。
質問1: chinachuは延長未対応という認識で合っていますか？
質問2: Linux(debian)で使えるソフトで延長に対応しているものはありますか？
初心者質問で申し訳ありませんが、よろしくお願いします。
449:login:Penguin
14/06/29 13:24:23.63 NiUCYq/U
>>447
URLﾘﾝｸ(www1.axfc.net)
450:login:Penguin
14/06/29 13:50:59.43 NiUCYq/U
>>449
ごめんなさい。コンパイル通らないものをアップロードしました。
こちらをご利用ください。
URLﾘﾝｸ(www1.axfc.net)
451:login:Penguin
14/06/29 14:10:04.59 z6oWkA97
>>445
ついでだから切断後シグナルマスク戻さないからSIGKILLしなきゃならんバグも直してよ
452:login:Penguin
14/06/29 14:11:52.83 Y8Pe/3cq
>450
ありがとうございます～！
453:login:Penguin
14/06/29 14:46:34.55 j+vHdLLp
>>450
修正ありがとうございます。
つまらないことでスルーして貰って結構なんですが、こういうのはdestroyで一緒にやる方が良いんじゃないでしょうか。
454:login:Penguin
14/06/29 16:12:34.97 IV5o2OlC
>>448
まだそういう認識で合ってると思うよ
現状EPG解析はepgdumpでやってるから録画時にリアルタイムで更新できないはず
複数チューナかつ運が良ければ間に合うかもしれないけど。
SI解析も実装する予定でいるらしいが(ポシャった？)
あれをNodeに実用レベルで載せられるかどうか…
455:448
14/06/29 18:31:24.74 U7BI4yqJ
>>454
ありがとうございます。
延長に対応していないのは残念ですがわかりました。
Schedulerログによるとchinachuは1時間ごとに予約を更新しますが、
録画中や深夜1時から朝5時までは更新を休むようです。
(チューナーはPT2×1+PT3×1)
456:login:Penguin
14/06/29 18:49:46.01 ReMJfVhg
放送時間の延長に対応するには、一般的に、
読み取った内容を解析すること(スクランブル解除を含む)の他に
単純な録画している時間を、実行中に変化させることができなければいけない
要は、recpt1ctlに相当する機能をすべてのrecxxxに持たせなければいけないということ
例えば、recfsusb2nctl、といったものを個別に作る必要がある
こういう点を考えれば、インターフェースを統一してすべてを同じ操作で扱える
bondriver形式にもメリットがある
windows上でいろいろ揉まれた結果でもあるし
さらにspinnel的な扱いが出来ればより良いだろうけどね
457:login:Penguin
14/06/29 21:15:30.46 NGSA/MjH
PX-W3PE って Ubuntu 14.04 64bit 3.13.0-30-generic で使えます？
>>441読んで試して見ようと思ったのだけど。
URLﾘﾝｸ(www.plex-net.co.jp)
からドライバダウンロードして readme.txt 読んでみたけどRelease note
のみでインストール方法や対応ディストリの記述はないです。
insmodはダメでした。
sudo insmod ./asv5220_dtv.ko
insmod: ERROR: could not insert module ./asv5220_dtv.ko: Invalid module format
対応カーネルバージョン以下の様です。
modinfo ./asv5220_dtv.ko
vermagic: 2.6.32-279.5.1.el6.x86_64 SMP mod_unload modversions
カーネルバージョンで検索するとCentOS6とか出てくるのでRed Hat系？
458:login:Penguin
14/06/30 00:07:13.47 abQ5XaIy
>>450
パッチをみてみたらepgrecUNAの所で配布してるのと構造が違うので調べてみたらRC4か新本家にRC4をそのまま移植したやつ用か・・・
459:login:Penguin
14/06/30 00:58:16.48 bRxCtVkq
そういえばUNA版は延長対応してなかったっけ？
460:login:Penguin
14/06/30 01:26:08.62 dfg1knvX
もうこんなことは辞めてレコーダー買おう
461:login:Penguin
14/06/30 02:02:33.86 8CwJEBXv
DVB版でも dvb_appsの録画ツール(gstreamer + python)は一応延長対応のはず ( >>39 )
462:login:Penguin
14/06/30 02:10:06.71 6mosU4bC
>>459
録画中の番組の延長は知らんけど、
開始前の予約は録画開始前にEIT[p/f]をチェックして追随するようにはなってる。
463:login:Penguin
14/06/30 03:14:31.39 DwN01oO6
まさかレコーダーを買えないからやってるの？
レコーダーごときを？
464:login:Penguin
14/06/30 03:23:27.43 6mosU4bC
金の話ならレコーダ買う方がよっぽど安上がりだろ
465:login:Penguin
14/06/30 07:17:42.97 7ocuUzw7
>>463
違うからもう来んな
466:login:Penguin
14/06/30 07:19:18.71 dfg1knvX
>>463
じ、じつはそうなんです、、、Orz=3ﾌﾞｯ
467:login:Penguin
14/06/30 09:06:48.10 MA99xvB1
>>457
プレクのドライバはubuntuはダメだったはず
今まで報告されてる使ってみた事例は全部CentOSだと思う
468:login:Penguin
14/06/30 09:22:39.28 ujPq+PnL
>>456
細かいことだけど、EIT見るのにはスクランブル解除は要らんのでは？
469:login:Penguin
14/06/30 11:23:18.73 f61EEGBP
>>463
買ったレコーダーがたまに録画失敗するクソだったんで信用しないことにしました
470:login:Penguin
14/06/30 15:48:14.78 THsPIyp+
放送時間延長とかイベントリレーは対応めんどくさそうだよね
まず最低限、epgrecとかの録画管理ツールからrecpt1とかの実際の録画ツールに録画設定の変更を伝える
しくみが必要で（recpt1に関しては、recpt1ctlが使えるからここはクリアしてるけど）、
その上で録画管理ツールが延長やイベントリレーの監視と、それらに該当すると判断した場合には、
それを録画ツールに指示するなり新たな録画予約を追加するなりする必要がある
さらに、他の録画予約が入っててチューナーに空きが無い場合はどうするかとかの設定ができる必要もあるだろうし、
録画ツール側はともかく、録画管理ツール側でやらなきゃダメな事がかなり多い
正直epgrecいじって対応しようとするくらいなら、EpgTimerSrv移植とかした方が早いかも
471:login:Penguin
14/06/30 18:20:04.56 Z2o/PPr0
>>470
epgrecUNAは録画中でもEPGが更新されれば時間を延長してくれる
まあ中の人にスポーツにたいする愛が無いようなので完全自動ではないし他Chの予約と重複するとやめちゃうみたいだけどｗ
472:login:Penguin
14/06/30 18:23:12.98 aPcosLFk
>>467
やっぱりUbuntuだとダメなのか。
CentOS6.4での導入事例があったのでCentOSでトライしてみるよ。
URLﾘﾝｸ(www2.filewo.net)
473:login:Penguin
14/06/30 20:47:20.03 THsPIyp+
>>471
見てみた
イベントリレーはまあ置いておくとして、なるほど、延長する可能性のある番組の後番組の頭だけ予約を入れておいて
EPGの更新を確認する、か
少し面倒ではあるけど、全く対応してないのと比べたら全然マシだね
そこが自動化されたらだいぶ使い勝手良くなりそうだけど、対象の番組を録画してるのとは違うチューナーを使って
EPGの更新確認する関係上、難しいかなぁ
録画ツールを改造して、指定録画時間の最後数分になったらEPG更新用に録画とは別ファイルにも出力とかすれば行けそう？
チューナー共有されてる状態なら、普通に番組録画してるチューナーを共有して使えば良いから話は簡単なんだけど・・・
つーかrecpt1をbondriver使えるように改造すればいいのか？
474:login:Penguin
14/06/30 21:12:44.01 DwN01oO6
すみません。
epgrecUNAのログって、リセットすることはできないでしょうか。
誤ってすごくありふれたキーワードを自動録画ワードにしてしまったので、削除したのですが、大量に予約追加と削除のログが残ってしまいました。
ログを開くたびに、数秒くらい待たされてしまうので、なんとかまっさらにしたいのですが。
475:login:Penguin
14/06/30 21:59:03.56 MA99xvB1
>>472
ソースは非公開でCentOS用のバイナリだけしか公開しないんなら、
Linux用じゃなくてCentOS用ってちゃんと書けよって思うよね
modinfoではライセンスGPLって表示されるくせにソースは公開してくれないみたいだし、
会社としていろいろと雑な印象
476:login:Penguin
14/07/01 00:08:54.22 F+DeUV5E
> modinfoではライセンスGPLって表示されるくせにソースは公開してくれない
雑って言うかそれライセンス違反じゃん
477:login:Penguin
14/07/01 01:08:46.62 sI+XcYWl
ソースの請求先がわかりにくくちっさく書いてて
請求しても音沙汰なしっていうケースはよく聞く
478:login:Penguin
14/07/01 02:06:00.44 QUQSWhvI
>>474
TRUNCATE TABLE
479:login:Penguin
14/07/01 10:52:56.19 Zy9veG3Z
>>470
放送が後ろにずれる場合であれば、
録画用のプロセス（recpt1とか）の起動にスクリプトか何かかませて、
EIT見て適当に眠ってくれるコマンド呼んだ後に録画開始するようにすれば、
ってのはだめ？
チューナの管理はまた別に考えないといけないかもしれないけど。
480:login:Penguin
14/07/01 18:39:53.25 e6olk3A5
>>479
単に後ろにずれるだけならそれで良いと思う
確かepgrecUNA版がやってるのもそれだったんじゃないかね
481:login:Penguin
14/07/01 18:41:10.82 Raq5LBsF
お手軽インターフェイスのパッケージをお願いします
482:login:Penguin
14/07/01 20:47:09.14 ezxEUewa
チューナーの空きを意識しつつEPGを更新して録画をやってくれるプログラムがあるといいわけかｗ。
483:login:Penguin
14/07/02 01:07:53.26 M5XTVbsQ
>>441
下のような構成でPX-W3PEを試してみました。
動作しますね。
・サーバー
CentOS 6.5 64bit (2.6.32-431.20.3.el6.x86_64)
PX-W3PE V1.2 (PX-W3PE_LinuxDriver_ver.1.0.0.zip 64bit asv5220_dtv.ko)
BonDriverProxy + BonDriver_ProxyPT.so (develop branch)
・クライアント
Windows8.1
TVTest + BonDriver_Proxy.dll
ただ、1チューナーに2接続以上すると不安定になる感じです。
TVTestが固まりサーバーでPacket Queue OVERFLOWが多量に出力され
しばらくするとBonDriverProxyが終了してます。
接続クライアント数に応じてFifoやQueueサイズを変更するってことですかね？
484:login:Penguin
14/07/02 09:59:48.42 cRaNnxwL
素人質問で申し訳ないですけど、
このスレでいうLinuxというのは、CentOSと思っていいのですか？
他のデストリビューションでは動きませんか？
485:login:Penguin
14/07/02 10:07:17.03 zT0wTg+q
がんばれば動くと思うけど。
W3PEの場合、CentOSのが動作報告多いってだけ（というか>>472辺りの話？）でね？
Chinachuは一応推奨がUbuntuだったりするし。
486:login:Penguin
14/07/02 10:22:42.31 AO9c6Mvs
>>478
遅ればせながらありがとう。
でも、その他にもいろいろうまく行かないところとかあって、結局DB作成しなおしてしまいました。
みんなはログ膨れ上がったらmysql操作して消してるの？
487:login:Penguin
14/07/02 12:36:53.34 eMEK3G9M
>>485
レスどうもです
しかしLinuxはよく分からんなぁ
動いたり動かなかったりラジバンダリ
488:login:Penguin
14/07/02 12:46:01.85 /3ZW/MrB
>>483
おお、ありがとうございます
3wpeの初期化は、一応はうまく行ってると言う事でしょうか…
> ただ、1チューナーに2接続以上すると不安定になる感じです。
> TVTestが固まりサーバーでPacket Queue OVERFLOWが多量に出力され
> しばらくするとBonDriverProxyが終了してます。
> 接続クライアント数に応じてFifoやQueueサイズを変更するってことですかね？
ありゃ
ウチでUbuntu 14.04 + PT3使って動かしてる分には、キューサイズ等は全部デフォルトのままで1チューナへの
複数接続(チューナ共有)の場合も含めて特に問題なく動いてるので、plexチューナ特有の何かでしょうか…？
ただ、大量の"Packet Queue OVERFLOW"はおそらくサーバからクライアントへのTSストリームを、クライアントが
読み出さない状態が続いた結果だと思うので、その辺を考えると、ネットワーク絡みの何かにも見えますね
＃プロセスが終了するのはちとわかりませんが、上記の件の絡みで最終的にメモリ確保に失敗して…とかの線でしょうか
一応の確認ですが、1チューナに2接続以上と言うのは、CentOS上の同じBonDriver_ProxyPT.soをリクエストする
TVTest + BonDriver_Proxy.dllを複数起動したと言う事ですよね？
489:login:Penguin
14/07/02 12:52:18.97 /3ZW/MrB
>>483
あ、それから、もしWindowsでもチューナとそれにアクセスするBonDriverが使用できる状態であれば、良ければ以下を
試してみていただけないでしょうか？
1. WindowsとLinuxでそれぞれBonDriverProxy(サーバプロセス)を動かす
2. Windows上のTVTest + BonDriver_Proxy.dllからLinux側のサーバプロセスに対してBonDriver_Proxy.soをリクエスト
3. Linux上のBonDriver_Proxy.soはWindows側のサーバプロセスに対してチューナにアクセスするBonDriverをリクエスト
つまり、Windowsから一旦Linuxを経由して結局Windowsのチューナを使用しているだけですが、意図としては、
これが問題なく動くかどうかである程度の問題の切り分けができそうかな、と言うものです
＃これに関しては、当方ではHyper-V上のCentOS 6.5で特に問題なく動作する事を確認しています
490:login:Penguin
14/07/02 15:14:41.72 OZyIazCq
>>485
epgrecUNA版もdebian系向けだった気がする
491:login:Penguin
14/07/03 00:07:17.50 LQRgd6Tw
>>488
>>483で1チューナーに2接続上と書いたのは、書いたときには正確な個数が
よくわからなかったからでして、動作確認として、TVTestを1個起動し、S0,S1,
T0,T1とBonDriver(チューナー)を切り替えて表示させると特に問題なく表示して
くれたので、嬉しくなってTVTestを1個、2個…と追加で起動していくうちに起こっ
たので何個からか良くわからなかったのです。まあ、最低2接続以上だろうという
ことで書いたのですが…。
(1)ノートPCで無線LAN(>>483の場合)
クライアントはノートPCで無線LANを挟んでいます。
クライアント : ノートPC (Windows + TVTest + BonDriver_Proxy_W3PE_S0.dll)
--- 無線LAN --- ルーター --- 有線LAN ---
サーバー : デスクトップPC (CentOS + BonDriverProxy + BonDriver_LinuxPT_W3PE_S0.so + PX-W3PE)
【ネットワーク絡みの何か】というのであれば見るからに無線LANが飽和しそう
です。それなら、転送量の多いBSをどんどん起動していけばそのうち起きそうです。
実際にやってみた所、BS4個目からTVTestの表示が壊れ始め、Packet Queue OVERFLOWの
メッセージが表示されました。推察どおりネットワークの問題で同一チューナー2接続
以上とか関係なかったです。
(2)デスクトップPCで有線LAN
だったらということで、クライアントをデスクトップPCにしCPUパワーをあげて
かつ有線LANでネットワークを安定させてみたところTVTestを7個程度起動して
もきちんと表示してくれました。ですので、間違いなくネットワークの問題で
PX-W3PEは関係ないです。さらに追加でPT3をサーバーに差して確認してみま
したが同じ結果でした。
492:login:Penguin
14/07/03 01:34:01.24 LQRgd6Tw
>>488
(3)BonDriverProxyプロセスの終了
再度確認したのですが、Packet Queue OVERFLOWのメッセージが
表示された後しばらくするとBonDriverProxyが終了するのではなく、
連続してTVTestを起動すると、最後に起動したTVTestがハングアップ
状態になります。そうするとメッセージが表示されます。ハングアップ
状態のTVTestを除いて、動作していそうなTVTestのうちどれか1個を
終了させると、同時にBonDriverProxyのプロセスが終了するという
挙動でした。
-g オプション付加して再コンパイル gdb上で実行、上の手順でプロ
セスが終了した際の出力です。
Program received signal SIGPIPE, Broken pipe.
[Switching to Thread 0x7fffd35fe700 (LWP 31499)]
0x000000315d00ecdc in send () from /lib64/libpthread.so.0
(gdb) backtrace
#0 0x000000315d00ecdc in send () from /lib64/libpthread.so.0
#1 0x0000000000401db5 in cProxyServer::Sender (pv=0x607b70) at BonDriverProxy.cpp:632
#2 0x000000315d0079d1 in start_thread () from /lib64/libpthread.so.0
#3 0x000000315cce8b5d in clone () from /lib64/libc.so.6
こんな感じの挙動かなあと思ったりはしたのですが。
URLﾘﾝｸ(d.hatena.ne.jp)
>>489は後日確認してみます。
493:login:Penguin
14/07/03 13:18:45.72 a1vOG2RQ
>>491-492
詳しい確認ありがとうございます
どうやらネットワーク側の問題だったと言うところまで確認できたのなら>>489はもう必要なさそうです
w3pe対応に関しては大丈夫そうとの事で、developからmasterにマージしようかと思います
ネットワーク容量に関しては、BonDriverProxyの場合、デフォルトではTSストリームを定常送信している時
188*1024バイト(TSパケットのバッファサイズ)毎に16バイトのオーバヘッドが付く様になっています
なので、トラフィックの殆どがTSストリーム自身の物なのですが、それでもBSでは1TSストリームで24Mbpsとかになるので、
多数のストリームを送信すると無線では厳しくなってしまいますね
サーバプロセスが死ぬ件は、そのログから確かにSIGPIPEを無視してないからのようです
＃元々Windows版からの移植なので対応忘れてました(;´Д`)
今グローバルなロック掛けてる処理をBonDriverのインスタンス毎に分ける形に変更してるところなので、
それと一緒に対応する事にしますね
494:login:Penguin
14/07/03 14:36:00.20 PkrsOdjH
Windows⇔Unix移植でシグナル関係はマジで鬼門…
495:login:Penguin
14/07/05 16:11:30.94 W/F+l3Z5
px-q3pe / CentOS 6.5 で 安定動作中。素晴らしいな。
>>441
plex.cpp (´▽｀)ｱﾘｶﾞﾄ!
496:login:Penguin
14/07/05 22:57:47.67 dQ8aHTrO
>>495
おお、plex.cppのq3peでの動作確認していただけたと言う事でしょうか
＃recpt1で使用とかでしょうか？
お役に立ったのなら何よりです
なお>>493の件、対応完了しております
URLﾘﾝｸ(github.com)
497:login:Penguin
14/07/09 01:33:08.89 cvRDG/nS
PX-W3PEをwindowsで使っています
Windowsだと内臓ブースターの感度調整ができますが、foltia anime lockerでもできますか？
498:login:Penguin
14/07/09 02:08:23.38 ARuOD0a6
debian系で動かぬとは…
499:login:Penguin
14/07/09 02:18:52.63 xu7Dt0I9
unknownさん
confファイルのPACKET_FIFO_SIZE，TS_FIFO_SIZE，TSPACKET_BUFSIZEを変更すると具体的に何がどんな感じで変わりますか？
URLﾘﾝｸ(github.com)
TS Queue OVERFLOW : size[64]と出力されます。
500:login:Penguin
14/07/09 20:10:01.27 GgPhQLZW
>>499
TSPACKET_BUFSIZEはTSストリームをTSキューに放り込む際の一単位のサイズです
TSストリームをデバイスから読み出して、そのサイズまでバッファリングしてから一つのTSデータ用パケットとして
クライアントモジュールに送信します
PACKET_FIFO_SIZEは上記のTSデータ用パケットを含めた通信プロトコルのコマンドパケットのキューサイズです
＃普通の使い方をする限り、定常送信中は全部がTSデータ用パケットになるでしょう
TS_FIFO_SIZEは、クライアントモジュールはTSデータ用パケットを受け取ったらTSキューに放り込んでいきますが、
それがアプリケーションに読み出されるまでの間保持しておくためのキューのサイズです
TSPACKET_BUFSIZE * TS_FIFO_SIZEがクライアント側モジュールでTSデータ用に保持される最大バッファサイズです
501:login:Penguin
14/07/09 20:14:02.70 GgPhQLZW
>>500の続きです
例えばネットワーク速度が安定せず、速くなったり遅くなったりするならPACKET_FIFO_SIZEを大きくするとドロップ
しなくなるかもしれません
しかし、絶対的に速度が足りていない場合は、大きくしてもキューサイズを超えるまでの時間が少し延びるだけでしょう
TS_FIFO_SIZEに関しても同じで、アプリケーション側の読み出し方次第です
新規データはサーバ側でどんどんデバイスから読み出され、クライアントモジュールに送られてTSキューに積まれて
いきますが、そのデータをアプリケーションが読み出さない場合、どこかでデータを捨てないとメモリを無尽蔵に
消費する事になるので、そのリミットとしてのTS_FIFO_SIZEです
sample.cppでやってるように、GetTsStream()で読み出したのをそのままファイルに書き出しするような場合は、
余程書き出し先デバイスが遅くない限りは問題にはならないハズです
しかし、読み出した後に同スレッドで何らかの時間の掛かる処理を行っていて、次の読出しまでにTSキューに新規データが
常に複数積まれていく様な状況だと、その内TSキューのサイズはリミットに達してしまうでしょう
この場合、とりあえずデータは読み込んでおいて時間の掛かる処理は別スレッドで、と言うのが王道かと思います
例えば、B-CASカードでのECM処理はかなり遅い部類の処理なので、TS読み出しスレッドとデスクランブルスレッドは
分ける、などのパターンですね
＃libarib25を使用する場合は、確か内部に専用バッファを持っていたと思うので、面倒な事は考えなくても大丈夫かも
＃しれません…が、未確認です
502:login:Penguin
14/07/09 20:17:23.99 GgPhQLZW
更に続きです
と言う訳で、PACKET_FIFO_SIZEもTS_FIFO_SIZEも、平均的には新規データの供給よりも速いペースでデータを捌けるけれど、
何回かに一回は時間が掛かる事があってその時にドロップしてしまう、と言う様な状況でいじると効果があるかもしれない
項目だと思っていただければ大体間違いないかと思います
捌く速度が新規データ供給よりも平均的に遅い場合には、これらのサイズを大きくしても多分時間稼ぎにしかなりません
TSPACKET_BUFSIZEに関しては、大きくしていくと、チャンネル変更の際などにそのサイズ分のバッファが溜まるまで
サーバからデータが来ないので、レスポンスが悪くなっていくでしょう
逆に小さくしていくと、レスポンスは良くなるかわりに各種オーバヘッドが大きくなっていくので、小さくしすぎは
意味が無いでしょう
大体こんな感じでわかるでしょうか…？
長文失礼しました
503:login:Penguin
14/07/10 00:29:04.36 Vdu/474/
>>500-502
詳しい情報ありがとうございます。
プログラマーではないので全ては理解できませんが、特に>>502で疑問点はおそらく解決しました。
最後に
URLﾘﾝｸ(github.com)
このサンプル設定はunknownさんの環境では十分なサイズなのでしょうか。
504:login:Penguin
14/07/10 07:02:22.93 1ScKKN6I
>>503
はい、ウチのテスト環境(Hyper-V上のCentOS6.5、Core i7 3630QMから仮想プロセッサ2つ割り当て、
HDDは容量可変VHDX形式)では、sample+BonDriver_Proxy(キューサイズ等の設定はデフォルト)によって
LAN(1000BASE-T)経由で他のマシンに刺さってるPT2を使って録画、と言うのが特に問題無く出来ています
topで眺めてる限り、上記環境+設定ではsample実行中のCPU負荷も殆ど上昇しない感じです
＃これに関しては、想定使用環境を録画用サーバとすると、上記テスト環境は若干CPU性能が高い気はするので、
＃参考程度の情報として下さい
505:login:Penguin
14/07/11 15:34:23.80 OUxv2+uD
>>504
ご親切な対応、本当にありがとうございました。
506:login:Penguin
14/07/11 15:59:09.38 dxK0BNE0
親切を敬語にすると煽られてる気分になるのはなぜだろう
507:login:Penguin
14/07/11 18:48:10.02 6ySvc8u0
unknownさん、 Pull RequestsとIssues見てくれるとうれしい。
508:login:Penguin
14/07/12 01:26:29.76 QUHdXLZV
>>507
今更ながら確認しました、ありがとうございます
GitHubの使い方良くわかってないのでなんとなくでやってみましたが、あんな感じで良いんでしょうか…
509:login:Penguin
14/07/12 21:48:40.06 SnB0zLWa
BonDriverProxy_Linuxに付属している sample.cpp をコンパイルして実行したところ
dlopen: Success と表示されファイルサイズゼロの aaa.ts しか作成されずに終了します。
./sample -b BonDriver_LinuxPT.so -s 0 -c ０ -t 10 -o aaa.ts
dlopen: Success
ソースを見て原因は BonDriverがロードできなかったためとわかったのですが、最初は
エラーメッセージだとは思えなかったので少しハマりました。
URLﾘﾝｸ(github.com)
perror("dlopen"); を fprintf(stderr, "%s\n",dlerror()); とかに変更すれば、まともなエラー
メッセージになってくれます。
BonDriver_LinuxPT.so: cannot open shared object file: No such file or directory
# BonDriverのロードが成功してから出力ファイルのopenをしたほうが
# サイズゼロの出力ファイルができないので自分としては好みです。
510:login:Penguin
14/07/12 22:47:38.33 9B3a+VZM
>>508
あんな感じで大丈夫だと思います。
(unknownさんの環境でも確認出来ているならば）
511:login:Penguin
14/07/13 00:00:43.87 n2Vjk8dB
-rdynamicいらんのけ？
512:login:Penguin
14/07/13 01:49:05.62 YTm9Pv5Y
>>509
確かにその通りですね
とりあえずサンプルはあった方が良いかなとサラッとつくったものなので、エラーはチェックだけやって
メッセージ周りはテキトーでした(;´Д`)失礼しました、修正しておきました
>>510
こんなマイナーなツールにPull Requestが来るなんて全然考えてませんでしたヽ(;´ー`)ノありがとうございました
>>511
確かに、sampleにはCentOS 5.4とかの古めの環境でコンパイル&実行するとダウンキャスト失敗すると言う事を
報告していただいて、-rdynamicオプション付けたんでした
その辺サーバも同じで付けておいた方が無難な気がするので、追加しておきました
513:login:Penguin
14/07/13 02:20:53.01 YTm9Pv5Y
>>511
と思ったんですが、どうもなんだかよろしくないみたいなので戻しました(;´Д`)
押し入れの中のLinkers & Loaders引っ張り出すべきか…
514:login:Penguin
14/07/16 00:16:08.34 todPSfmo
マザーボードG1.Sniper M5[URLﾘﾝｸ(www.gigabyte.jp)でfoltia ANIME LOCKERを使いたいと思っています。
このマザーボードにはNICとしてQualcomm® Atheros Killer E2201 chip (10/100/1000 Mbit)が採用されており、おそらくはこれが認識されていないために、foltia ANIME LOCKERが使えていません。
まずはインストールについてはURLﾘﾝｸ(aniloc.foltia.com)を参考にし、HDDが3台あったので下記のようにして何とか出来ました。
/home/foltia/perl/hddinstaller.pl -d /dev/sda -d /dev/sdb -d /dev/sdc -confirm yes -url URLﾘﾝｸ(127.0.0.1)
しかし、その後起動させても以下のように表示され、その後どうすればいいか分かりません。
________________________________________
foltia ANIME LOCKER
You can access URLﾘﾝｸ(foltia.local)<)
foltia login: Bridge firewalling registered
________________________________________
NICが認識されていればおそらくはDHCPによりプライベートIPアドレスが割り当てられ、ネットワーク上の他パソコンから操作できると思うのですが…
ちなみにE2201ではないですが、E2200については↓のようにlinuxでの動作はするようです
URLﾘﾝｸ(ubuntuforums.org)
このマザーボードでfoltia ANIME LOCKERを使う方法があればご教示ください。
因みに、拡張ボードには空きがなく、出来ればLANポート増設以外の方法がよいのですが…
515:login:Penguin
14/07/16 02:26:42.59 Rd9MnMt+
スレ違い乙
516:login:Penguin
14/07/16 08:34:24.03 zRntf19q
半板違い丙
517:login:Penguin
14/07/16 11:34:02.07 fMwVkLO8
甲乙丙丁
518:514
14/07/16 22:58:14.62 todPSfmo
初心者質問スレに行ってきます
519:login:Penguin
14/07/23 02:49:41.51 UIQy6iIM
Chinachuって追従するの？
520:login:Penguin
14/07/26 00:40:28.44 8ZSXKiqI
バカな質問で申し訳ないのだが、Chinachu+PT3で録画してます。
DLNAクライアントで閲覧してるんだが、字幕をONにしても表示されません。
これってそんなもの？？
521:login:Penguin
14/07/26 01:47:32.37 t6v8y6+x
そんなもの
522:login:Penguin
14/07/26 13:54:08.49 4LQEoPJM
Linuxは細かいところの作り込みが甘い。
それぐらいよくある話。
523:login:Penguin
14/07/26 16:00:48.94 pZx1Q0T3
何の貢献もしないくせに上から目線で批評。
それもよくある話ｗｗｗ
524:login:Penguin
14/07/26 19:15:45.99 t1mYoald
>>522はリーナスなんか問題にならいくらいの凄腕
525:login:Penguin
14/07/26 22:06:27.61 7IPYc6BL
なけりゃ自分で作れってだけの話
526:login:Penguin
14/07/26 22:53:20.19 lBpGoaG4
何がいけないのか調べずによく話ができるなぁ
優秀なエスパーさんが勢ぞろいなんですねｗ
527:login:Penguin
14/07/27 10:51:59.71 tY684ELH
>>520
とりあえず、recpt1のオプションに
--strip付いてると思うので除去してみては
528:login:Penguin
14/07/27 11:01:05.48 tY684ELH
>>527
すまん、--stripいれても字幕入ってた
529:login:Penguin
14/07/27 12:58:38.24 7ePzb8Np
>>520
使ってるDLNAクライアントがARIBの字幕に対応してるか調べてた？
530:login:Penguin
14/07/28 17:30:56.36 m/Vi1iyq
Chinachuの番組表で、どうも東海テレビが2列でちまうんだな…
1つルール作ったら予約済欄に2個予約されちまうぜ…
こういうときってどうすりゃいいでしょうか…
531:login:Penguin
14/07/28 21:37:01.16 E+3TlTnW
設定ファイルにチャンネル定義が二行でダブってるだけって愉快なオチに期待
532:login:Penguin
14/08/02 23:28:29.92 s+soKDEh
Chinachuって、重複が録画可能数超えてもなにも言わない？
533:362
14/08/07 22:00:24.80 GxNjbWzT
>>532
今試したけど、どんどん予約できた
534:login:Penguin
14/08/08 12:46:23.98 0t1JUWl+
おめでとー
535:login:Penguin
14/08/09 17:44:54.27 AsfeVmjW
録画できないー。
手動でrecpt1しても、数分ぐらいしかできない。
ログに↓がでるとだめだーーー。
systemd: Started PC/SC Smart Card Daemon.
pcscd: 00000000 utils.c:53:GetDaemonPid() Can't open /var/run/pcscd/pcscd.pid: No such file or directory
CentOS7なんだけど、これじゃまずい？
さっぱりだ・・・・どうすればいいんでしょう？
536:login:Penguin
14/08/09 18:07:02.68 mQ8TOVgQ
エスパーの皆さん、出番ですよーｗ
537:login:Penguin
14/08/09 18:23:14.34 u8uxwlhZ
カーネルやドライバ等数分でコケる筈ないだろって場合はマザボや電源の劣化を疑ってみる
早い話ノイズ耐性や瞬発力が下がってる可能性がある
538:login:Penguin
14/08/09 18:26:02.51 rc5wPGdb
No such file or directory
でマザボや、電源？
os動かないだろ。
539:login:Penguin
14/08/09 19:16:47.45 /ZynO8Gm
>>535
pcscdはB-CASの解除だけにしか使わないから、動いてなくてもrecpt1は動く
pcscdが動いてないのは /var/run/pcscdがないかパーミッションか所有者がおかしいっぽいけど
540:login:Penguin
14/08/09 19:19:01.52 AsfeVmjW
>>539
おかしいな。。。
たとえば、recpt1で、10分とかオプションで指定(オプションでは600か)しても、
1分とか、3分ぐらいで勝手に録画が終わってしまう・・・
エラーはでてない
なぜだ・・・
541:login:Penguin
14/08/09 19:27:08.61 rc5wPGdb
その録画は出来てるの？再生出来る？
542:login:Penguin
14/08/09 19:29:56.44 AsfeVmjW
>>541
再生できます。
543:login:Penguin
14/08/10 02:28:06.50 f94X+Pf1
>>542
カードリーダー見失ってるのかも
そのメッセージでた直後に、lsusbとかpcsc_scanしてみて
あるいはやわらかい奴かな
544:login:Penguin
14/08/10 10:04:28.43 2FRObZti
>>543
どうも、例のログは関係ないらしい。
何もログでないのに、途中で止まる。なぜ・・・
ソースにデバッグコード入れるしかないのか。。。
545:login:Penguin
14/08/10 18:54:16.10 dPQJBXwC
すぐ再現できるならとりあえずstraceとかで何が起きてるか見てみてよ
546:login:Penguin
14/08/10 22:50:17.01 hcloJPEb
DVBドライバーを殺してないんじゃ？
547:login:Penguin
14/08/11 01:20:28.46 +lM8QzpO
天狗の仕業だ
548:login:Penguin
14/08/12 00:44:10.29 aAA1LoVC
パックスのしわざ
549:login:Penguin
14/08/12 06:20:34.08 m2fKpwXo
>>65
いちお情報としてかなり前のにレス
epgrec UNAで同じ症状が出たけどrecpt1をbuildし直したら取得できた
550:login:Penguin
14/08/12 17:42:52.81 FrmrUazc
BonDriverProxy_LinuxのサーバーにSpinelのTSOptimizerのような機能が欲しい・・・。
551:login:Penguin
14/08/16 11:26:43.18 g5+q7xCY
>>545
見てみたが。さっぱり。
途中から突然PT3からの読み取りがなくなっている。
違うディストリ試してみるか
552:login:Penguin
14/08/19 23:37:09.08 I4h+PUKm
ショボイパッチですが…
URLﾘﾝｸ(hg.honeyplanet.jp) へのパッチ
→ URLﾘﾝｸ(www1.axfc.net)
* ログメッセージ（dmesg）のプレフィックスを "PT1: " に統一 (pt3_drvと同様に)
* エラーやドロップが発生しなかった場合はその報告を省略
* モジュールパラメータdebugを変更できるように修正
例） echo 0 > /sys/module/pt1_drv/parameters/debug （ログメッセージを最小限に）
553:login:Penguin
14/08/20 00:06:57.56 YgoPyQnX
>>551
まずハードじゃないのそれ
554:login:Penguin
14/08/20 12:31:40.91 EMVxX4TT
>>553
ディストリをdebianにして、b25オプション外したら治った。
別原因で止まったりしたが、recpt1直接打ちはうまくいくようになった。
555:login:Penguin
14/08/20 20:27:01.17 g5L5m6zD
>>554
よく覚えていなけど、以前 ubuntu でも pcscd のとあるバージョンで不具合なかった？
それでパッケージのバージョンを古いのに固定していた時期があったと思うけど。それの可能性は？
556:login:Penguin
14/08/20 21:30:01.69 +tWqmdAb
うちは14.04でも固定してるよ。
不定期のタイミングでカードリーダを見失ってb25のデコードができなくなるから。
557:login:Penguin
14/08/20 21:55:37.22 g5L5m6zD
>>556
あれはデコードできなくなるだけなの？
だったら違うか
558:login:Penguin
14/08/22 03:16:22.15 ivHfULC0
BonDriverProxy_Linuxの作者さん、
リポジトリにあるメールアドレスはダミーですか？
libarib25関連のパッチを送ろうかなと思っているのですが。
559:login:Penguin
14/08/22 09:01:55.71 KFky9orq
プルリクすりゃええじゃん。(´・ω・｀)
560:login:Penguin
14/08/22 19:32:41.76 MKqaNber
>>558
元々全然使ってないメールアドレスだったので存在すら忘れかけてました
さっき確認してみたら1か月以上放置してしまったメールとかが…(;´Д`)誠に申し訳ありません
パッチに関してはとても嬉しいのですが、実はデスクランブル機能関連は意図的に避けている部分なんです
特にサーバ部分に組み込んだら、理屈的にはデスクランブル済みのを公衆送信できるシステム扱いできてしまいますので…
こんなニッチなツールの事なんざ権利者さんも気にしねーよ、てのは全くその通りだとは思うのですが、
当方破城槌で石橋叩き、壊れちゃったらやっぱり危なかった渡らずに済んで良かった、と言う感じの
ポリアンナ的メンタルの人間です(;´Д`)
>>550
この間、サーバじゃなくてドライバに1サービス1チャンネル扱いする機能を追加してみたんですが、もしかして
これで用が足りたりしませんか？
＃CAT(とEMM)まで削ったのはちとやり過ぎだったかなと思ってるので、それは残す方向に戻すべきかと思案中ですが
561:login:Penguin
14/08/22 19:51:30.29 ivHfULC0
>>560
同じ理由でプルリクエストではなくてメールにしようと考えてました（当方もチキンです）。
もう少し関連事項（ライブラリの使用だけでもアウトなのか等）を調べてからメールしようと思います。
一応パッチはrecpt1みたいな感じ（ユーザがライブラリをリンクしないと使えない）にしてあるのだけども。
562:login:Penguin
14/08/23 11:47:12.22 +GPqjlNx
>>560
util/testのチャンネル列挙ができないけどどこ見たらいい？
なんかch1から列挙しようとしてるみたいだけど、
これ地上波なのかBSなのかわからんのじゃないのかという気がする。
なんかまた俺が勘違いしているのか・・・・
563:login:Penguin
14/08/23 15:38:33.25 +GPqjlNx
>>562
conf間違ってた。気づかなかったわｗ
564:login:Penguin
14/08/24 13:12:03.09 pstTkKz2
たまにsyslogに PT3 invalid sync data って録画中に出まくって、その後録画止まるんだが、
これって単なるドロップ？
ドロップもして、止まるのはなんとならんか。。。
565:login:Penguin
14/08/24 23:03:33.33 VdOCmrwl
>>564
chardev版PT3ドライバでの話だと思いますが、PT3から取得したTSデータがおかしいとそうなります
そうなった場合、録画を止めるかどうかは録画アプリ次第ですが、仮に止めなくてもそれが発生してる間は
まともなデータは期待できないでしょう
ソフトではなくハード(PT3やメモリだけでなく、アンテナ、ケーブル、分波器等も含んだ何か)の問題ですね
たまになるだけって事なら、普段からアンテナレベルがギリギリとかなんじゃないでしょうか
とりあえずCN比確認してみるのが良いかと
566:login:Penguin
14/08/24 23:37:23.90 BqLcLvkb
アンテナレベルギリギリだとデータがおかしくなることがあるというのであれば、
それ込みで電波の仕様だよ。不正なデータは発生しうるという仕様。
だからこの場合は、できる限りドライバ内でフォールバックするようにしないと。
テレビがアンテナギリギリでシステムが停止する？
映像は映らなくてもシステム自体は停止しないでしょ？
567:login:Penguin
14/08/25 01:11:16.65 VF+oB84Q
>>566
いやだから、そうなってもドライバは単にアプリからのread()に0を返すようになるだけですよ
まさにフォールバックですね
録画が止まるならそれはread()が0を返したのを受けてアプリが終了してるだけでしょう
録画を止めるかどうかは録画アプリ次第と言うのはそう言う意味です
あるいは、録画終了時刻まで復帰しなかったら、ファイルだけ後から見れば途中で終了してるように見えるでしょうね
いずれにせよ、少なくともドライバには非は無いと思いますよ
568:login:Penguin
14/08/25 20:37:24.54 PCu13YIt
やっとchinachu & BonDriverProxy & TVTestでリアルタイム視聴&録画が出来るようになった
作るにあたってこの構成取ってるまとめサイトが無かったんで、まとめたら需要ってありますか？
569:login:Penguin
14/08/25 20:48:40.75 Zge50iv1
ありまーす
570:login:Penguin
14/08/25 20:55:04.22 MXNU2n50
>>568
是非お願いします！
いやマジで！！
571:login:Penguin
14/08/25 21:01:33.50 PCu13YIt
ではちょっと構成と画像、設定まとめます
色々無理くりやってるので、欠点もありますが...今運用している範疇で作ってきます
572:login:Penguin
14/08/25 21:52:06.88 MXNU2n50
ありがとうございます！
本当にありがとうございます！！
573:login:Penguin
14/08/26 11:04:05.20 PAMz3I9n
>>568
需要ないですよ
574:login:Penguin
14/08/26 21:36:19.94 BpOkUOJ2
>>568
是非お願いします！
575:login:Penguin
14/08/26 21:51:25.09 SH+I10L8
>>573
ちょっおまっっ
ちゃんと需要あるから全然あるから
576:login:Penguin
14/08/27 00:59:28.56 1MChGv8J
epgrecに対してのメリット デメリットや乗り換え指南とか有ると嬉しいけど
両方使い込んでないと難しいか
577:login:Penguin
14/08/28 00:34:23.36 u3Vrdj9d
かきこみ食い！
578:login:Penguin
14/08/28 00:36:33.79 u3Vrdj9d
誤爆したああ
579:login:Penguin
14/08/28 12:27:15.42 0cTXkwdI
安定して動いてるとなかなか新しいのに手出せないよね(´・ω・｀)
580:login:Penguin
14/08/28 12:38:52.91 jFp4EclH
PT2の2枚差しでまだまだ行けます
581:login:Penguin
14/08/29 04:06:51.23 v3ONMbB+
URLﾘﾝｸ(www.dcc-jpl.com)
URLﾘﾝｸ(foltia.com)
なるほどなぁ～
582:login:Penguin
14/08/31 09:19:00.43 VMP6HcFa
>>565
なるほど・・・
その後、手動でrecpt1すると何事もなく無事なんだが・・・
たまたまなんだろうか。
BSで13.5dBぐらいは低いか？！
583:login:Penguin
14/08/31 11:45:26.47 xX+VaeoE
>>582
低いんじゃないかな
うちはBS/CSは16-18dBくらい
584:login:Penguin
14/08/31 11:52:49.66 VMP6HcFa
>>583
まじか・・・ さてどうしたものか。。。
分配しているテレビの方はSHARP表示で90/100とかあるんだけどな・・・・
分配の先が悪いのか。
585:login:Penguin
14/08/31 11:54:35.77 VMP6HcFa
Win版のPT3は、DMA転送の時に、CPU-DMAとかの同期APIがはいったけど、
もしかして、Linux版も同じようなことしないといけないのか・・・
わからんなぁ。
586:568
14/08/31 18:14:36.39 EugbJio5
遅くなりましたが、とりあえず個人メモを公開
かなり端折ってますので、わからなかったらスミマセン
URLﾘﾝｸ(blog.kickitout.net)
注意事項にも書いてありますが、B25復号ができないです
運用してみるとCASの都合からPCで復号したほうが良いので方法見つかるまでこのままです
あとはTVTest視聴中にChinachuのEPGスキャンが走ると
チャンネル変更されるのが面倒くさいくらいですが、録画優先のためこれは仕方がないかと
587:568
14/08/31 18:21:57.37 EugbJio5
>>576
epgrecは使ったことないですね
Chinachuを選んだ理由はルールによる自動録画とストリーミング再生でした
番組表についてはスクロールでしか画面遷移できないので、ここはepgrecが良いと思います
588:login:Penguin
14/08/31 19:17:14.51 vUw0Vf62
>>586
b25はパイプじゃダメなん？
/usr/local/BDPL/sample ～(略)～ | b25 /dev/stdin /dev/stdout 2> /dev/null
589:568
14/08/31 19:36:32.34 EugbJio5
>>588
試したんですが、駄目でした
まずchinachuにパイプ付きで実行させるとエラーとなり、
shellスクリプトで実行させても/dev/stdinが開けなくてNGです
(エラー内容は忘れました)
590:568
14/08/31 21:07:03.48 Tov9UBtf
あとはChinachuのrecordedCommandで録画後にB25復号させる方法もあります
もちろん録画後に行うので時間はかかりますが...
これ応用すると>>581の自動CMカットも行けそうですね
----------------------------
#!/bin/bash
B25=/usr/local/bin/b25
if [ $# -lt 1 ]; then
echo "$0 {recPath} {jsonProgram}" 1>&2
exit 1;
fi
# B25 decode
${B25} -p 0 -v 0 "$1" "$1.tmp"
if [ -e "$1.tmp" ]; then
if [ $? -eq 0 ]; then
rm -f "$1"
mv "$1.tmp" "$1"
else
rm -f "$1.tmp"
fi
fi
exit
----------------------------
591:login:Penguin
14/08/31 22:42:25.46 pPCOz4VV
BonDriverProxy_Linuxnのsample.cppにb25デコード追加パッチ
URLﾘﾝｸ(www1.axfc.net)
592:568
14/08/31 22:48:55.26 Tov9UBtf
>>591
早い C++学習してなくて諦めてました
593:591
14/08/31 23:57:03.92 pPCOz4VV
>>591 はb25デコード強制でちょっと良くないねってことで、
recpt1準拠のオプションに対応してみました。
usage: ./sample [--b25 [--round N] [--strip] [--EMM]] [-b bondriver] [-s space_no] [-c channel_no] ( [-t sec] [-o filename] )
--b25: Decrypt using BCAS card
--round N: Specify round number
--strip: Strip null stream
--EMM: Instruct EMM operation
URLﾘﾝｸ(www1.axfc.net)
594:568
14/09/01 00:16:30.09 PCe7o4Q1
有難うございます
既に今日だけで2つも課題(注意事項)が解決しました
BSだけは不明なため、申し訳ないですが各自でお試しください
595:591
14/09/01 00:47:49.14 a7hMx0Xw
>>593にミスがありました！
パッチ後の77行目、write を ::write に書き換えてください。(*ﾉｪﾉ)
if (dbuf.size > 0) return write(fd, dbuf.data, dbuf.size);
↓
if (dbuf.size > 0) return ::write(fd, dbuf.data, dbuf.size);
596:login:Penguin
14/09/01 01:01:21.97 BNTqI31W
元々のpatchの76行目を修正…でいいんですよね？
597:login:Penguin
14/09/01 03:26:06.65 O9repODI
何が入っているかわからんから
コードを理解してからやること。
598:591
14/09/01 10:38:32.04 a7hMx0Xw
>>596
はい。
すみません。
patchの56行目も同様のミスありました。
if (!valid) return write(fd, buf, count);
↓
if (!valid) return ::write(fd, buf, count);
鬱だ氏のう(´A｀)
599:login:Penguin
14/09/01 13:44:04.90 dFvWFsJ3
こういうのはpastebinでやろうや
URLﾘﾝｸ(pastebin.com)
スレ内で出てたパッチの修正済み
600:591
14/09/01 17:42:50.72 a7hMx0Xw
writeで書き込まれるバイト数が指定バイト未満になる場合が考慮されていなかった不具合を修正しました。
度々申し訳ないです。m(__)m
URLﾘﾝｸ(pastebin.com)
601:login:Penguin
14/09/01 17:59:55.44 a7hMx0Xw
毎度(ry
URLﾘﾝｸ(pastebin.com)
602:login:Penguin
14/09/01 19:22:22.10 RUZKEFrJ
>>601
これをBonDriverProxyに組み込んだら、
鯖のBCASだけで行けるのかな。
録画鯖にBCASつけてる人はクライアントはどうしてるんだろ。共有してんのかな。
603:login:Penguin
14/09/02 14:47:23.78 XL1oxIjN
>>601
@@ -75,7 +75,7 @@
ssize_t write(int fd, void *buf, size_t count)
{
if (!valid)
- return ::write(fd, buf, count);
+ return write_full(fd, buf, count);
sbuf.data = static_cast<uint8_t*>(buf);
sbuf.size = count;
604:login:Penguin
14/09/02 17:33:14.10 XL1oxIjN
ここまでのsample.cppへのパッチ ＋ BonDriverProxy.cppへのパッチ
URLﾘﾝｸ(pastebin.com)
usage: ./BonDriverProxy [--b25 [--round N] [--strip] [--EMM]] address port (packet_fifo_size tspacket_bufsize)
e.g. $ ./BonDriverProxy 192.168.0.100 1192
--b25を有効にするときは、
デコード済みのストリームが外部ネットに漏れないよう十分配慮してください。
605:login:Penguin
14/09/02 23:39:48.14 XL1oxIjN
URLﾘﾝｸ(pastebin.com)
・ b25::set_b_cas_cardでエラーになる対策
・ b25::putが失敗した後ハマる対策
>>604のパッチを適用後にパッチしてください。
視聴中にチャンネル切換すると稀にストリームが滞る事があるようです。
＃b25->putがARIB_STD_B25_ERROR_NO_PMT_IN_HEAD_32Mを返してる。
放っておけばそのうち流れだすので、とりあえず放置(；´∀｀)
606:login:Penguin
14/09/02 23:59:03.15 XL1oxIjN
すみません。こっちで URLﾘﾝｸ(pastebin.com)
607:login:Penguin
14/09/03 06:35:33.40 ZY4L+Z2d
> -#define FILE_OFFSET_BITS 64
> +#define _FILE_OFFSET_BITS 64
…(;´Д`)
失礼しました
sample.cppの方も直しておきますね
と言うか、sampleがちゃんとサンプルとして機能してるみたいで良い感じですね
細かい事言えばpIBon->CloseTuner()後でも、pIBon->GetTsStream()でdwRemain(アプリによる読み出し待ちバッファ数)が
1以下である保証は無いです
＃元のsample.cppがdwRemainが0になるまでループさせてるのはそれが理由です
608:login:Penguin
14/09/03 06:52:51.56 ZY4L+Z2d
>>604-606
サーバでのスクランブル解除はカードの処理能力がボトルネックになる場合があるから注意…
と思ってたんですが、今libarib25をナナメ読みした限りでは、あるサービスに対して最初のECMで購入済みか
チェックして、未購入だった場合は以降のECMはカードに投げない様にしてくれてるみたいですね
＃win環境で一般的に使われてるB25Decoder.dllではやってなかったと思います
これならあんまり心配する必要は無さそう
＃20チューナー同時稼働とかでない限り
ただその辺りも含めて、libarib25は内部的に色々と現在のTSストリームの状態を保持しているので、
チャンネル変更の際にはそれらの情報の破棄が必要でしょう
> 視聴中にチャンネル切換すると稀にストリームが滞る事があるようです。
の現象も、その内部情報破棄を行っていない事が原因だと推測します
対応としては、チャンネル変更のタイミングでb25->reset()を呼べば良いと思います
そうすればb25->put()やb25->get()でコケる事も無くなるかと
実装的には、b25を配信スレッドのローカル変数からcProxyServerのメンバ変数にして、m_pposなどと
同じ様な形で持つのが良いんじゃないでしょうか
b25の取得、release()及びreset()も、m_pposの場所に準じる感じで
＃そこでなら排他ロックも掛かってるので
609:login:Penguin
14/09/03 07:04:53.15 ZY4L+Z2d
そう言えばこう言う話もある様ですが、
URLﾘﾝｸ(twitter.com)
これが普通に取り込まれて利用可能になったとしたら一つの目安となりますね
＃本来的には、そんな事考えないで良いように法律の方でハッキリと線引きしておいて欲しいものですが…
610:login:Penguin
14/09/03 09:03:42.03 sZbKOuDA
ぐっとB25関係が進展したみたいですね。
Windows の BonDriver_HDP2とかはB25デコード後のTSが直接出てきた様な
記憶があるので、BonDriver側(BonDriver_LinuxPT.cpp)でデコード済みのを
返すというのは筋が悪いのですかね？
そうできたら、それより上にあるBonDriverProxy、sampleも特に変更しないで
良さそうな気がしてるのですが。
611:login:Penguin
14/09/03 10:43:10.73 vjzT1Nr4
>>609
その人は日本人ではないし、バイナリの配布も日本のサーバーを使わないと思うのだが。
612:login:Penguin
14/09/03 16:03:26.39 Z1VCVlkc
>>609
字幕パッチが取り込まれたり、ここにきてVLCのISDB対応が増えてるのはなんでだ?
SkyDriveに置いてあるOSX用独自ビルド、ここ半年のものでデュアルモノラルの分離が上手くいかない..
613:login:Penguin
14/09/03 17:11:31.39 qNJLyKdr
>>612
南米やアフリカで、ISDB規格が奮闘してるからではないかと。
614:login:Penguin
14/09/03 20:20:08.29 ZY4L+Z2d
>>610
個人的には録画あるいは視聴機能でやるのが一番シンプルで理に適ってるかな、とは思ってますが、
あえてサーバ側でやるなら、サーバ部分(BonDriverProxy)よりもドライバ部分(BonDriver_LinuxPT)に組み込む方が好みですね
ただ、正しく機能してる限りどこでやろうが結果は(そんなに)変わらないので、これはあくまでも当方の好みの問題です
実装は>>608に書いたサーバ部分でのモノとほぼ同様になると思いますが、b25をメンバじゃなくてグローバルで持てば
それで良さそうですね
>>611
そうなんですが、BLACKCASの様な実例もありますので…
配布にしても、公式サイトからはパッと見わからないだけで、実際は日本のミラー経由でダウンロードしてる事も
多いんじゃないでしょうか
615:login:Penguin
14/09/03 20:24:21.72 ZY4L+Z2d
>>586
> チャンネル設定を[0始まりのBonDriverProxy用]と[実chと合わせたchinachu用]の2つを定義
これちょっと驚きましたヽ(;´ー`)ノ考えてみれば確かに可能…
ただ、やっぱりChinachu側で設定するのが本来の形かなとは思います
S側でチャンネル数が多くなるとカブッてくるとこもありそうですしね
Chinachuを使った事ないので実際に可能かどうか良く知らないのですが、ソースをちょっと眺めた感じでは、
config.jsonのchannelsのchannelをBonDriverとしてのチャンネル番号に編集すれば行けそうに思いました
616:login:Penguin
14/09/03 21:01:00.41 JJSBj14D
VLCってフランス製だっけ？
フランスはアフリカ方面の移民が多いからかもね
617:login:Penguin
14/09/03 21:01:32.76 JJSBj14D
>>613
VLCってフランス製だっけ？
フランスはアフリカ方面の移民が多いからかもね
618:605
14/09/03 23:02:24.44 ZgkNyMVF
>>608
アドバイスありがとうございます！
> 対応としては、チャンネル変更のタイミングでb25->reset()を呼べば良いと思います
実装してみたのですが、b25->put()でコケることがあります。
ioctl(fd, SET_CHANNEL)が反映されたストリームを保障できれば良さそうですがどうしたものか(；´∀｀)
＃ b25->reset()のタイミングでPurgeTsStreamも試みたのですが、改善せず
BonDriver_LinuxPT.cppにもb25を組み中です
STOP_REC → 空read → SET_CHANNEL → b25->reset() → START_REC
とすることで上手く動いているようです。たまーにコケますが(；´∀｀)
619:login:Penguin
14/09/03 23:16:47.79 ZgkNyMVF
現状のを晒しておきます。
>>606からのパッチです。URLﾘﾝｸ(pastebin.com)
620:568
14/09/04 08:08:21.22 pIWfyEJi
>>615
本来はそれがベストなんですが、
BonDriverProxy以外の混在利用を考慮してChinachu側の
channnels設定はそのままにしました
BonDriverProxy OnlyでしたらChinachu側弄ったほうが楽ですね
621:login:Penguin
14/09/04 13:28:01.85 /tUehKy7
>>612
たまにはmplayerのことも思い出してあげて下さい ( >> 39 )
622:login:Penguin
14/09/04 17:15:39.11 D15wE/JR
b25パッチ、安定してきました。
本家最新(16c770ecf355e0155f49eb5a52766d30e6afe7d1)からの差分です。
URLﾘﾝｸ(pastebin.com)
環境変数 B25 を定義した状態でmakeするとデコーダあり版をビルドできます。
$ B25=1 make
ドライバ(BonDriver_LinuxPT)でデコーダ有効にするには、confに
#B25=1
を追記。(パッチ後のBonDriver_LinuxPT.confを参照)
BonDriverProxy, sampleは recpt1のb25関連オプションに準拠
usage: ./sample [--b25 [--round N] [--strip] [--EMM]] ～略
usage: ./BonDriverProxy [--b25 [--round N] [--strip] [--EMM]] ～略
623:login:Penguin
14/09/04 19:02:48.45 D15wE/JR
微修正
URLﾘﾝｸ(pastebin.com)
624:login:Penguin
14/09/04 20:32:53.92 vbqHHR+q
>>622-623
URLﾘﾝｸ(gist.github.com)
使ってくれないかな？
patch自体をgitで管理できるし
リビジョン間のdiffも見れるし。
625:login:Penguin
14/09/04 21:10:43.19 D15wE/JR
>>622-623をまとめたやつ
URLﾘﾝｸ(gist.github.com)
今後はここにpushすればいい？
垢作らないと更新できなさそうだけど(；´∀｀)
626:login:Penguin
14/09/04 21:27:21.46 vbqHHR+q
>>625
垢作らないとダメなのか。
それじゃ使えないな・・・すまん。
627:login:Penguin
14/09/04 22:32:47.53 kpxJ/orl
>>626
Gmailかなんかで捨てアド取って、ダミー垢つくれば？
628:login:Penguin
14/09/04 23:30:51.11 FSjilAqd
epgrec_20111001.tar.gz をそのまま使ってると、
録画ファイルを削除してもサムネイルファイルが削除されずに残ってしまう件、
cancelReservation.php 下の方で、
@unlink($path);
@unlink($path.".jpg");
という箇所を、
@unlink($path);
@unlink(INSTALL_PATH."/".$settings->thumbs."/".basename($path).".jpg");
に書き換えたらサムネイルもきちんと削除されるようになったので、
とても今さら感がありますが、ここに記しておきます。
629:625
14/09/04 23:48:06.17 D15wE/JR
垢作ってforkしてみました。今後はこちらをフォローしていだければと。
URLﾘﾝｸ(gist.github.com)
>>607
>細かい事言えばpIBon->CloseTuner()後でも、pIBon->GetTsStream()でdwRemain(アプリによる読み出し待ちバッファ数)が
>1以下である保証は無いです
>＃元のsample.cppがdwRemainが0になるまでループさせてるのはそれが理由です
↑を対策したものに更新しました。
＃間違ってコード削っちゃってました
630:login:Penguin
14/09/05 01:15:51.00 xh94W/Rp
>>629
ありがとう！
631:login:Penguin
14/09/05 06:38:37.05 YWm7Cq3O
>>618
タイミングを逃した感がありますが、以前のバージョンに付いてです(;´Д`)
SET_CHANNELだけではデバドラ内のバッファがクリアされないみたいですね
こうなってくるとサーバモジュールだけで何とかするのは無理で、ドライバモジュール側で対策する必要がある感じですね
PT3のデバドラでは気持ち対応しようとしてるみたいですが…
STOP_REC -> START_RECはPT3のデバドラでは有効そうですが、PT1/2のデバドラでは効果無さそうな？(自信なし)
PT3で(ですよね？)STOP_REC -> b25->reset() -> START_RECで基本うまく行ってるのに、
> たまーにコケますが(；´∀｀)
となってしまうのは、多分cBonDriverLinuxPT::TsReader()及びcBonDriverLinuxPT::TsSplitterのposをゼロに戻してないからかなと
しかし、ナナメ読みから流し読みくらいにレベルを上げてlibarib25読んでみたら、ストリーム変更への自動追従の仕組みも
ちゃんと入ってるみたいなんですが、どこでコケてるんでしょうね
調べてみるのも面白いかもしれません
632:login:Penguin
14/09/05 06:47:41.88 YWm7Cq3O
そんでもって、現状最新版での、面倒な事考えずにb25->put()し続けて急にb25->get()でバッファが
返って来なくなったらb25->reset()と言うのはシンプルで良いですねヽ(´ー`)ノ
真面目に完璧に対応しようとしたら、デバドラにパッチ当てるか、いったんデバイス閉じて開き直すとかの
微妙な形にするか、あるいはlibarib25のコケてる理由を特定して対応するか、みたいな感じになりそうなので、
この方法はかなりバランス良いナイスな実装だと思います
なお、>>629適用後のBonDriverProxy.cpp、448行辺りと498行辺りで、m_b25もコピーして下さいね
でないと、クライアント1接続 -> クライアント2が1とドライバ共有で接続 -> クライアント1切断 -> クライアント2切断
と言う流れでリークしちゃいます
気になったのはそれくらいでしょうか
confのパースも「=」が離れてても良くなってて素晴らしい…
＃実は気になってたんですが、まあ良いかと放置してました(;´Д`)失礼しました
633:login:Penguin
14/09/05 19:00:47.72 AZWHso9+
>>632
> なお、>>629適用後のBonDriverProxy.cpp、448行辺りと498行辺りで、m_b25もコピーして下さいね
> でないと、クライアント1接続 -> クライアント2が1とドライバ共有で接続 -> クライアント1切断 -> クライアント2切断
> と言う流れでリークしちゃいます
対処しました。
本家様のレビューがあると安心ですね(*´∀｀)
634:login:Penguin
14/09/06 01:41:41.05 FexPwWIJ
>>586を応用してsid指定で録画出来るようにしたいんだけど、sampleってチャンネルが3桁の数字には対応してないのかな？
例えばこういう感じにconfで設定して（USESERVICEID=1）
BS日テレ 141 6 0 141
BS日テレ 2 6 0 141
sample -b (BonDriver) -s 0 -c 141 でも sample -b (BonDriver) -s 0 -c 2 でも取得出来るようにしたい
現状は後者のみ動いて前者は0バイトのファイルが作成される
635:login:Penguin
14/09/06 01:50:18.50 FexPwWIJ
自己解決
BonDriver_LinuxPT.hのMAX_CHを適当に増やした所録画出来ました
636:login:Penguin
14/09/06 17:22:09.15 eO/pxnZ3
最新のパッチ当てた状態、オプション有効にして
sample実行するとPacket Queue OVERFLOW : size[0]
がでまくった上にプロセスが止まらないorz
637:login:Penguin
14/09/06 18:45:30.88 eO/pxnZ3
>>636
BonDriverProxy自体のソースが更新されててパッチ
あたってなかっただけでしたorz
申し訳ない
638:login:Penguin
14/09/06 20:48:29.03 zseocNOz
confパース部分のパッチです。 URLﾘﾝｸ(pastebin.com)
=は詰めて記述すれば済む話なので必要性は無いんですけど
本家でマージしていただければ幸いです。
639:629
14/09/07 06:18:05.44 ufRLo5FT
b25 patch for BonDriverProxy_Linux rev.4
B-CASカードが無い状態でストリームを流すとクラッシュするバグを修正しました。
デコード中のB-CASカード抜き差しに対応しました。
640:login:Penguin
14/09/07 06:33:59.10 9WNSn1qS
>>638
GitHubの方には反映してなかったんですが、ローカルでは>>632書いてから同じ事をやってしまっております…
＃個人的な好みで若干型や関数/変数名を変更してますが
せっかくパッチ書いていただいたのにスミマセン(;´Д`)
641:login:Penguin
14/09/07 06:36:21.79 9WNSn1qS
それはともかく、libarib25の動き眺めてたら、チャンネル変更しなくても普通に番組の切り替えタイミング(PATの更新とか)に
get()結果のバッファサイズがゼロになる事もあるみたいですね
＃厳密には、次のget()までにput()されたバッファの合計サイズに依存します
こう言う場合にreset()かけてしまうとドロップする事になるので、連続何回そうなったらreset()かける的な、
閾値みたいなのを設けた方が良いかなと思いました
上述の通り、put()するバッファサイズ依存なので、閾値はユーザが設定出来るようにしておくとかでしょうか…
642:login:Penguin
14/09/07 06:43:45.54 9WNSn1qS
あと、libarib25はPATの更新があった際に、当該PATをダブって出力しちゃうんですね
TVTest(と言うかBonTsEngine)では連続性指標のエラーになるので、1パケットドロップしてる様に表示されます
実際はデータが落ちてるわけではないので別に深刻な問題ではないのですが、個人的には気になるので対応してみました
当方と同じく気になる人は、
URLﾘﾝｸ(github.com)
で言うと、2054-2055行目のproc_pat()とgoto LASTの間に、
curr += unit;
を入れるとこの挙動はなくなります
ついでに言うと、2063行目も意味的にはsbuf.headじゃなくてsbuf.poolでしょうね
＃こちらは最終的な出力結果に影響を与えるわけではなく、単にまるもさんの意図はこうだったんだろうな、と言う話です
643:login:Penguin
14/09/07 13:16:41.37 ufRLo5FT
>>640
いえいえｗありがとうございます!
b25 patch for BonDriverProxy_Linux rev.5
>>641
resetするまでのしきい値を設けました。(現状は3回まで許容)
オプションで変更できたほうが良いかなとも思ったのですが取り急ぎ
644:login:Penguin
14/09/08 07:30:13.76 9KuKI2Lg
>>643
> オプションで変更できたほうが良いかなとも思ったのですが取り急ぎ
バッファサイズが小さな場合に大丈夫ならバッファサイズが大きな場合でも大丈夫なので、
小さめのバッファでビットレートの高いストリームやサービス数の多いストリームでも確実に大丈夫な回数を
指定しておけばそれで用は足りるかもしれませんね
回数を大きくしても、チャンネル変更時に>>605の問題↓
> 視聴中にチャンネル切換すると稀にストリームが滞る事があるようです。
> ＃b25->putがARIB_STD_B25_ERROR_NO_PMT_IN_HEAD_32Mを返してる。
が起こった場合にfail-safeが発動するまでの時間が延びる以外の問題は無いと思うので、多少大きめの値でも良いんじゃないかと
例えば、バッファのサイズをクライアントモジュールのデフォルト値である188*1024として、
問題が発生したストリームのビットレートを15Mbpsだとすると、仮に10回見送っても、
(188*1024*8*10)/(15*1024*1024)=約0.98で、オーバヘッドを考えても最長約1秒でreset()かかる計算です
＃当然、ドライバモジュールの様にバッファの小さな(188*256)場合や、ストリームのビットレートが
＃もっと高い場合にはもっと早めにreset()かかるでしょう
個人的にはこれくらいなら十分許容範囲かなと思います
＃そもそも滅多に発生しない問題な気もしますし…
645:login:Penguin
14/09/08 07:42:44.54 9KuKI2Lg
それから、その問題の発生するそもそもの原因を考えてみたんですが、
以下の様なパターンで発生しそうな気がします
---
チャンネル変更
↓
PAT更新検出
↓
次回以降のput()ではfind_pmt()でPMT探しを始める
↓
変更後のチャンネルで番組切り替わり、あるいは再度のチャンネル変更などでPAT再更新
↓
find_pmt()ではそれを検出しないので、もう流れて来ない旧PATで示されたPMTを探し続ける
↓
ARIB_STD_B25_ERROR_NO_PMT_IN_HEAD_32M
---
PAT/PMTの送出頻度は100msに1回以上と規定されているので、タイミングはシビアですが…
ただ、PMTが発見されても今度はfind_ecm()で同じ状態になるので、
こちらは結構有り得るんじゃないかなと思います
で、試しに上記の状況を再現するTSファイルを作成してb25に食わせたら、
やはりARIB_STD_B25_ERROR_NO_PMT_IN_HEAD_32Mで終了しました
対応としては、libarib25にパッチ当てる形になりますが、
URLﾘﾝｸ(pastebin.com)
な感じかなと思います
＃>>642の件も含んでます
上述のTSファイルをこのパッチ当てたlibarib25を使用するb25に食わせると、
意図通りの出力が行われるのを確認しています
646:login:Penguin
14/09/08 21:13:39.99 HcnwnBd6
閾値の件、了解しました。ありがとうございます。
ドライバのバッファサイズ(188*256)で現在観測中です。
>>645
ARIB_STD_B25_ERROR_NO_ECM_IN_HEAD_32MでコケてたTSも食わせてみましたが、
エラー無しです。ヽ(=´▽`=)ﾉ
647:login:Penguin
14/09/09 03:12:06.64 yZ6ry4LB
>>645
デコード出来ない
648:login:Penguin
14/09/09 21:16:21.74 mah88T5D
>>647
recpt1とB25からならデコードできてるけど、そっちでもダメ？
自分はlibarib25のパッチと関係なく、sampleからはデコードできないorz
あとWindows側のProxyの方で使用するBonDriverは何使えばいいんだろ
とりあえずBonDriver_pipe指定しているけど初期化に失敗するって出る
649:login:Penguin
14/09/10 07:25:05.47 dfnWCajE
もうちょっとだけ変えて、各種異常系に対応するパッチにしてみました
URLﾘﾝｸ(pastebin.com)
正常なデータに対する処理は、後述の箇所以外は前回のパッチと変わりません
＃処理結果に影響しないビミョーな変更した部分はあります
＃＃行末空白消したらdiffの出力がエラい事になってしまいました(;´Д`)
前回のパッチで、追加した部分でPAT更新を検知した場合、そのPAT自体は削除していたのですが、
よく考えたらこの場合は残した方が良いかと思ったので、残すようにしました
＃削除しても、適切にTSを扱えるソフトならその次のPATを見つけるはずなので、
＃どちらでも大して変わらないかもしれませんが…
>>647
どちらかと言うと、TSとしては一応正常だけど扱いがややこしいデータに対応する為のパッチで、
ごく普通の(変なタイミングでPATの更新が発生したりはしない)TSストリームの扱いに関しては
元のコードと(ほぼ)同じなので、このパッチでデコードできなくなるような理由は無いと思うんですが…
650:login:Penguin
14/09/10 07:38:25.75 dfnWCajE
>>648
基本的には、win環境で使えるチューナ使用の為のBonDriverを想定してます
当方ptTimerを使用しているので、BonDriver_ptmr.dllを使う事が多いです
他には、BonDriver_PT.dllやBonDriver_PT3.dllで動作確認とれてます
BonDriver_Pipeに関しては、ファイル読み込み担当のTvtPlayと名前付きパイプで通信しようとするので、
dllのみリモートで読み込む形になるBonDriverProxyでは機能しないでしょうね
基本的にTVTest+TvtPlayからの直接ロードのみを想定したBonDriverなのだと思います
リモートのファイルをTvtPlayで扱いたいなら普通にファイル共有で扱えますしね
651:login:Penguin
14/09/10 12:16:01.87 h/4bPT67
b25 patch for BonDriverProxy_Linux rev.6
* resetするまでのしきい値を8へ増やしました。
* BonDriver_LinuxPT デコード処理をfifo排他ロックの外に移動しました。
libarib25パッチのおかげで、当方の付け焼刃的対策は不要となりました。（感謝！）
一応まだ残してありますが、気になる方は、decode.cppの12行、30行をコメントアウトしてください。