$ sudo apt-get install libccid libpcsclite-dev libpcsclite1 pcsc-tools pcscd
Keys
pcsclite.h
$ sudo vim /usr/include/PCSC/pcsclite.h
extern const SCARD_IO_REQUEST g_rgSCardT0Pci, g_rgSCardT1Pci, g_rgSCardRawPci;
↓
extern const SCARD_IO_REQUEST g_rgSCardT0Pci, g_rgSCardRawPci;
sed -i "/LONG SCardGetStatusChange/s/LPSCARD_READERSTATE_A/LPSCARD_READERSTATE/g" winscard.cpp
sed -i "s/SCARD_IO_REQUEST g_rgSCardT1Pci;/const SCARD_IO_REQUEST g_rgSCardT1Pci = { SCARD_PROTOCOL_T1, sizeof(SCARD_IO_REQUEST) };/g" winscard.cpp
make通った
/usr/include/PCSC/pcsclite.h
の改造を元に戻す。
併用設定。
libarib25
↓
cmakeか。
$ cmake -S . -B build
$ sudo apt-get -y --force-yes install cmake
$ cmake -S . -B build
$ cmake --build build
なってない。
README.mdを読む。
:%s/pcsclite/pcsckai/g
$ cmake -S . -B build
g_rgSCardT1Pci なんて定義されてないって感じのエラー。
最初のsoftcasをmakeするときにg_rgSCardT1Pciの行を消してmakeしたのがいけなかったのか？
もっかいsoftcasをmakeして libpcsckai を作り直してみよう。
あらためて libarib25 をmake
とおった！？
よっしゃ！ libpcsckai.so（という共有ライブラリ）を使う b25バイナリができた！
このb25（柔Cas）で録画できるrecfsusbを次はインストールする。
http://ktvwiki.22web.org/?BonDriver_FSUSB2i
$ recfsusb2i 27 10 test20220917.ts
ダメか。
こないだ入れた、B-CASのほうを読むタイプのrecfsusb2nに影響ないか確かめる。
おいおい何か、録画はできる（タイトルも出てる）けど再生できない状況になっとるぞ…
b25を元に戻しても改善せず…何が起きた？
と思ったら、地デジの電波状況悪かっただけみたい。時間経ったら録画またできるようになってた。
sudo vim /usr/include/PCSC/pcsclite.h
$ cmake -S . -B build
cmake --build build
今度こそとおった！？
sudo make install
「行うべきことはありません」てことは、いったんmakeしてバイナリできちゃってるからか。
recrsusb2i のほうはデバイス認識すらできてない（No device can be used.）。古すぎてダメなのか。
だんだん分かってきた。softcasが無いほう（カードリーダー読むほう）の共有ライブラリlibarib25.so.0.2.5を見ると
$ cd /home/pi/Desktop/libalib25/
$ cd build
$ ldd libarib25.so.0.2.5
libpcsclite.so.1 => /lib/arm-linux-gnueabihf/libpcsclite.so.1
となってて、b25デコードするときに libpcsclite.so.1 を使うようだ。
これが、softcas導入してると
$ cd /home/pi/Desktop/libalib25-master/
$ cd build
$ ldd libarib25.so.0.2.5
libpcsckai.so => /lib/arm-linux-gnueabihf/libpcsckai.so
となるわけだから、b25デコードのときに読む共有ライブラリは libpcsckai.so なわけで
あとは録画ソフトウェア
recfsusb2n ないし
recfsusb2i（こっちのが古くてダメか）を使って録画するときに
libpcsckai.so を読むようにするために
recfsusb2n（or 2i ）をmakeするときに、libpcsckai.so を読むように仕込みがいるよ、それからmakeして、できたバイナリを/usr/local/binに置けよ、ってことらしい。
録画はバッチリできるけど、再生するとなぜか開始50秒くらいで固まる。
原因想定
・pi3の処理能力不足？
・FSUSB2のハードウェアの問題か？
・カードリーダーから読み込むときにタイムラグがあるとか？
・録画ソフトウェアrecfsusb2n（または2i）バイナリを作り直せばいい？softcasでmakeすれば、カードリーダーを読み込む時のタイムラグが無くなって改善するとか？
・FSUSB2のハードウェアの問題か？
を試すために2台目を購入。3,000円でts貫できるなら格安だわ。
到着。挿してみる。
$ lsusb | grep 0511
おお。ばっちり2台認識してるじゃないか。
しかし再生50秒で固まる現象は（新しいハードでも）起きてしまった。KTV-FSUSB（というハード）の問題ではないらしい。
ということは、録画ソフトrecfsusb2nをもっかい作り直してみればいいのか。
recfsusb2i の install のとき、makeするのにoption として make B25=1 としたけど、
今回（recfsusb2n）もこれやればsoftcas（libalib25kaiで作ったほう）を認識するようになるのか？
$ make B25=1
$ make だけだと？
通る。なぜだ。
libpcsclite 読んじゃってるよなぁ。
libpcsckaiを読んでほしいんだけど。
もっかいmakeするとエラー（もうバイナリ＝recfsusb2nはできてるから当然）
libpcsckaiを読んでほしいなら、cppソースを書き換えればいい？
該当の記述無し。うーむ。
あれ、recfsusb2i だと標準出力から直でvlcに流せるらしい。
これあれか。たしかvlcってサーバ機能でUDPで配信できたんじゃないっけか？てことは、piのvlcを配信サーバにして、リモートにあるmacOS（のVLCアプリ）をクライアントにしてリアルタイムts受信できるんじゃなの？
$ sudo apt-get install vlc
vlc - CVLC udp Stream as service Raspberry PI - Stack Overflow
$ recfsusb2n --b25 27 - - | vlc --quiet --width 1000 -
おお、いけるじゃん！piのローカルVLCでは再生できてる。
mplayerでも視聴できるぽい。標準入力から受けられるんだから当たり前か。
$ recfsusb2n --b25 27 - - | mplayer -
SoftCASとwpa supplicantを併用する · GitHub
streamlinkでrecfsusb2からのb25配信をストリーム＋broadcast（udpとか）できないのか？調べる。
$ pip3 install --upgrade --user streamlink
$ sudo apt install mpv
streamlinkめっちゃ使いやすいな。macにも入れておこう。
$ pip3 install --user streamlink
$ brew install streamlink
macOSのvlcの場所が分からん。cvlcコマンドは動くから入ってるのは間違いないんだが。
調べたらここっぽい。
$ ls /Applications/VLC.app/Contents/MacOS/
おっしゃ動いた。
$ streamlink -p /Applications/VLC.app/Contents/MacOS/VLC https://www.twitch.tv/vivi0z1 480p
こりゃいい。かなり応用効くぞ。
ffmpegでrecfsusbのTV画像をパイプしてhttpなりで配信できないか？を調べてたら、ラズパイのffmpegでハードウェアエンコードできる感じの記事。
recfsusb2n が認識しているdeviceは /dev/bus/usb/001/004 だったから
それを v4l2-ctl コマンドに食わせると
$ v4l2-ctl -d /dev/bus/usb/001/004
デバイスの認識はダメみたいけど、ffmpegのエンコードには別に関係ないか。
これ。h264_omx オプションでラズパイの omxplayerで？ハードウェアエンコード？できるっぽい。
ts録画して…
こうか？
$ ffmpeg -i test4.ts -c:v h264_omx -y test4omx.mp4
なんかエラーだな…
変換前がコレで
変換後がこう。変換自体はできてる！
tsがmp4に（すごい速度で）変換できた。HandBrakeCLIより速い？高解像度化のオプションないか調べる。
-b:vオプションで高解像度化できる！
$ ffmpeg -i test4.ts -c:v h264_omx -y -b:v 1000k test4omx2.mp4
だいぶマシになった！
HD映像（ハイビジョン？）の時は -b:vに4m を指定せよとある。
$ ffmpeg -i test4.ts -c:v h264_omx -y -b:v 4M test4omx3.mp4
こりゃ素晴らしい。
サイズは15MB→4MBだから約4分の1になる。
母艦fedoraのHandBrakeCLIで同じこと（ts→mp4）してみよう。手元でいつもやってるやつだ。
$ HandBrakeCLI -i test4.ts -o test4omx4HBCLI.mp4 -Z "Apple 1080p30 Surround"
体感だとffmpeg（omxハードウェアエンコード）に比べて倍の時間かかってる気がする。
さすがにHandBrakeは画質キレイ？いや、そんな違わんでしょ。
これでサイズもffmpeg（h264_omxエンコード）のほうが小さい！
てことは、ffmpeg（h264_omxエンコード）を使えば
・ラズパイの筐体で（電力消費が極小）
・HandBrakeCLIよりも速く
・エンコード後サイズも小さく
できる！素晴らしすぎる。
てことは、普段はVPNサーバにしてて、GPUを持て余してるラズパイ4でも同じことffmpeg（h264_omxエンコード）できるのか！？
$ ffmpeg -i test4.ts -c:v h264_omx -y -b:v 4M test4omx4Pi4.mp4
できちゃった！画質もバッチリ。
上がffmpeg。下はHandBrakeCLI。見た目違い分からんくらいキレイ。これで日々撮り溜めたニュース.tsのエンコードが倍速になる。
試しに昨日のニュース.ts（286MB）をエンコードさせてみる。
ちょっとエラー吐くが無視。
実測の1.4倍で変換できてる！？らしい。こりゃ捗る。
わずか2分で286MBのエンコードが終了！
画質ばっちり。サイズも元の半分近くに圧縮された。
ちなみに同じh264_omxエンコードでも、V4L2M2Mエンコードは動かんかった。
