仮想サーバをやめて、やっと安定的な録画体制が築けた。長らく先送りとなっていた、録画後処理の自動化を進めていく。録画し終わったデータはTSファイルとして記録される。これを保管および視聴しやすいデータに自動で作り変えたい。検証してきた処理はCPUのハードウェアエンコードを使ったQSVエンコードとcomskipを使ったCMチャプター処理。また、カーナビ用の動画データもついでに自動生成するが、こちらは更に小さいデータでよいのと、うちのカーナビがチャプターあると正しく動作しないのでチャプターなしで生成する。後処理としては以下のような流れを想定している。

1. QSVエンコードで1時間2GB程度のMP4データを生成
2. MP4データに対してcomskipを実行してチャプター位置を検出
3. 検出したチャプター位置をMP4BoxでMP4データに対して設定
4. QSVエンコードで更に小さいカーナビ用のMP４データを生成

エンコードはQSV対応したffmpegを準備しやすいSkylake+CentOS7機で行う必要があり、CentOS6縛りのあるPX-Q3PEとは別ノードになってしまう。録画データはGlusterFSで共有されているため、録画機でもエンコード機でも見える。録画後処理は録画機での録画終わった後に、ssh経由でエンコード機の該当scriptを叩くという形で実現する必要がある。epgrecにはトランスコードという録画後処理用のインターフェースが用意されているが、リモートでエンコードやらCM処理やらはさすがに無理だろうと想像して、録画処理が行われるatの中でscriptを呼び出す形を取った。

atなんて今まであまり触ったことなかったのだが、こいつが意外と厄介。atを生成する処理はReservation.class.phpにある。このコードを読んで、どこにscriptのkickerを組み込むかを検討する。at内の処理は以下のような流れになっている。

1. recpt1での録画処理
2. recomplete.phpでの終了処理
3. gen-thumbnail.shでサムネイル生成
4. 一時ファイル削除

最後の最後に処理を入れようと、3と４の間にscriptを実行するコマンドを追加したが、何故かscriptが実行されない。仕方がないので、1と2の間に入れてみると今度は動作した。釈然とせず、2と3の間に入れてみても動作する。しかし、どちらの場合もサムネイル生成処理が実行されない。何だかよくわからない。何にしてもできれば最後の最後に入れたいので、まず3の後処理が実行されないことを調べてみる。

よくよく確認すると4で削除されるはずの一時ファイルが全て残っていて、以前からgen-thumnail.sh以降がおかしかった模様。エラーの出方も不気味で、本来は『rm /tmp/tuner_3267』みたいなコマンドなのだが、『uner_3267: command not found』のような感じの出力。最初の数バイトが何かに食われている様子。当然、疑いの目は直前のgen-thumnmail.shに。この中ではffmpegを実行しているのみなんだけど。おもむろに同じコマンドを実行してみると、このffmpegがinteractiveモードで動いていることに気付く！これだと直後に発行された文字が、ffmpegに食われてしまうことに。

うちのffmpegがinteractiveなだけで、そうでないffmpegもあるのかもしれないけど、とりあえずffmpegをbatchモードで動かす方法を探る。以下のコマンドで実行すれば、後段の標準入力を食わなくなるので、後発のコマンドも正しく処理される。

${FFMPEG} -y -nostdin -i "$OUTPUT" -r 1 -s 160x90 -ss ${offset} -vframes 1 -f image2 "$THUMB"

これでgen-thumbnail.shのあとにscript実行コマンドを配置しても問題なくなった。script実行は『ssh enc1 /home/rec/script/encode.pl FILENAME』のように実行して、enc1サーバのencode.plコマンドを叩く。このコマンドを差し込むとまたも、それ以降の処理が実行されない。そういえばgen-thumbnail.shの前に置くと、gen-thumbnail.shが実行されなかったな。atの実行処理部分はヒアドキュメントで区切られているのだが、これがちょっと気になる。

ヒアドキュメント内にssh処理をするようなサンプルshellを作って実行してみると、sshのところで終了してしまう。なるほど、atではなくヒアドキュメントの問題か。結論から言うと、sshする時点で標準出力が切り替わるために、元の処理に戻れないらしい。何か、こういうの避けるオプションがsshにあった気がするなと調べて見ると、-nオプションで問題を回避できた。

ssh -n enc1 /home/rec/script/encode.pl FILENAME

とまあ、ここまでやった上で、この程度のコマンドならトランスコード処理に組み込めるかもと思い直す。トランスコードはsettings/trans_config.phpに設定を用意することで実行できる。trans_config.php.sampleをこぴって該当ファイルを作成。以下のような設定を入れてみる。

        3 => array(
                'name'    => 'H264-QSV-HD',
                'suffix'  => '.ts',
                'tsuffix' => '.mp4',
                'command' => 'ssh enc1 /home/rec/script/encode.pl "%TS%" "%TRANS%"',
                'succode' => TRUE,
                'tm_rate' => 4.0,
        ),

設定ファイルを作った段階で、自動録画キーワード編集画面にトランスコードの選択肢が現れる。その中で、今回用意したH264-QSV-HDを選んでやれば、録画後にエンコード処理が走ってくれる。しかも生成されたMP4ファイルもブラウザから参照できるので、自力で組み込むよりトランスコードの中で処理させた方が圧倒的に便利。トランスコードに失敗している場合も視覚的にすぐわかるし。ちなみにカーナビ用のエンコードも独立した処理に変えて、別のトランスコードとして登録しました。カーナビ用の動画生成は任意で済むように。

ただ、後処理の問題点として、やはり時間がかかるのが不満。QSVエンコードとはいえ、1時間辺り2GBに圧縮するには、録画時間の3分の１ほど時間がかかる。1時間の録画なら18分待たされる。MP4ファイルでないとCMチャプターがないので不便だし。そんなにすぐ見たい録画なんてないんだけど、録画サーバを使うのは自分だけではないから、なるべくユーザビリティは既存のレコーダー並にしたい。ぶっちゃけ素のTSファイルを残すことにあまり意味はないので、録画時にリアルタイム・エンコーディングしてMP4ファイルで記録。録画終了と同時にcomskipとMP4Boxでチャプター付けて視聴可能とするのがベストかな。次回はその辺りに挑戦してみたい。