QRS-UT100B ちょっと進展
recfriioでいう、Hdus.cppと同じデータを送っていたのだけど、UT100BはHdp.cppの方が正しいというのに気づいたのが昨日。EP0へのコントロールデータを、recfriioのHdpのものに入れ替えてみたら、TSデータが落ちてくるようになった。
なったが、とんでもない量のdropが。
$ tsselect out.ts processing: finish pid=0x0000, total= 88, d= 13, e= 0, scrambling=0 pid=0x0010, total= 18, d= 0, e= 0, scrambling=0 pid=0x0011, total= 9, d= 0, e= 0, scrambling=0 pid=0x0012, total= 417, d= 69, e= 0, scrambling=0 pid=0x0014, total= 4, d= 0, e= 0, scrambling=0 pid=0x0023, total= 9, d= 2, e= 0, scrambling=0 pid=0x0024, total= 18, d= 0, e= 0, scrambling=0 pid=0x0027, total= 19, d= 0, e= 0, scrambling=0 pid=0x0028, total= 1, d= 0, e= 0, scrambling=0 pid=0x0031, total= 92, d= 11, e= 0, scrambling=0 pid=0x0100, total= 153, d= 0, e= 0, scrambling=0 pid=0x0101, total= 87, d= 8, e= 0, scrambling=0 pid=0x0102, total= 88, d= 11, e= 0, scrambling=0 pid=0x0111, total= 80325, d=6098, e= 0, scrambling=80325 pid=0x0112, total= 871, d=128, e= 0, scrambling=871 pid=0x0200, total= 82, d= 0, e= 0, scrambling=0 pid=0x0281, total= 3104, d= 0, e= 0, scrambling=0 pid=0x0283, total= 629, d= 0, e= 0, scrambling=0 pid=0x07f0, total= 83, d= 12, e= 0, scrambling=0 pid=0x07f1, total= 8, d= 2, e= 0, scrambling=0 pid=0x07f2, total= 19, d= 2, e= 0, scrambling=0 pid=0x07f3, total= 368, d= 46, e= 0, scrambling=0 pid=0x0840, total= 2797, d=378, e= 0, scrambling=2797 pid=0x0850, total= 163, d= 18, e= 0, scrambling=163 pid=0x0857, total= 27, d= 1, e= 0, scrambling=27 pid=0x0858, total= 7005, d=842, e= 0, scrambling=7005 pid=0x0859, total= 25, d= 3, e= 0, scrambling=25 pid=0x085e, total= 20, d= 3, e= 0, scrambling=0 pid=0x085f, total= 17, d= 4, e= 0, scrambling=0 pid=0x0860, total= 5017, d=666, e= 0, scrambling=5017 pid=0x086e, total= 8, d= 1, e= 0, scrambling=0 pid=0x0980, total= 620, d= 0, e= 0, scrambling=0 pid=0x098b, total= 433, d= 0, e= 0, scrambling=0 pid=0x1fc8, total= 37, d= 0, e= 0, scrambling=0
b25でデコードしてVLCで表示した結果も、見るに堪えない結果に。。。
HDUSFの場合と違うのはチューナ制御の処理がほとんどで、TSパケットの受信周りは全く同じ。なので、受信処理が重くて処理落ちしてるとは考えにくい。うーん。