EDCBからBonTsDemuxを使い自動エンコードPart2

前回の日記に続いてになりますが、今回は安定的にバッチファイルでEpgDataCap_BonからBonTsDemuxに渡す方法が暫定ですが出来たので、公開します。


まず症状ですが。
録画が完了し、BonTsDemuxが立ち上がり進行度はちゃんと進む。そして処理としては完了しているように見えるのですが、実際にはファイルが出来ていないということ。

そして詳しく見ていくと、BonTsDemuxが立ち上げるハズのffmpegがちゃんと立ち上がっていない。

成功している場合は、ちゃんとffmpegが立ち上がり動作する。


原因
父の方がこのあたりの分野は詳しいので相談すると見えてきたのが、

通常のエンコードはほぼ100％問題なく終了する。
録画後のバッチファイル動作でのみ発生するようである。
ログを見ると、一連の流れは成功しているように見える。

そこで、鍵となるのはffmpegが立ち上がらないところで、何故立ち上がらないのかということになった。そこで、可能性として見えてきたのは録画のアプリケーション側か何かが、エンコードする対象のファイルにアクセスしており、そのためにBonTsDemuxがデータを読み込めずffmpegの立ち上げに失敗しているということ。

ようはffmpegがファイルの読み込み・展開に失敗してるということ。

これなら納得がいく。BonTsDemuxがffmpegが立ち上がらない時に対してエラーと判断しないのが
またなんとも・・・。元々ファイルがちゃんと作成されている事を前提として動かしているから、なのかもしれませんが。また、OSにSSD(シーケンシャルリード500MB/sオーバー)、データ保存にHDD(ライト最大100MB/s前後)を使っているため書き込みの終了より速くアプリケーションが立ち上がってしまうのが原因なのかもしれません。

対策
簡単な話で、バッチの実行にディレイ(遅延)を意図的に発生させます。そうする事でオーバーヘッドを用意し確実に渡すようにします。
録画ファイルなのでアクセスをしているのは録画のアプリケーションであるEpgDataCap_Bonのハズです。ならば、そのアプリケーションが書き込みを確実に終了するまでの時間をとります。

ただ、バッチファイル単体ではその遅延をとれません。父曰くUNIX系ではsleepコマンドによって行う事が出来るそうなのですが。
そこで調べてみたところ、バッチでも同じ事をさせるアプリケーションがありました。
http://www.vector.co.jp/soft/win95/personal/se452993.html
こちらのソフトウェア「sleep.exe」をダウンロードします。
父が以前作ったバッチファイルでは先頭にチェンジディレクトリ=cdでBonTsDemuxのあるフォルダに移動しています。
なのでsleep.exeをBonTsDemuxと同じフォルダに置きます。
そして以下のようにします。




cd "BonTsDemuxがあるフォルダ"
echo %date% %time% START FILE=$FilePath$ >>psp.log
sleep 30000 >>psp.log
BonTsDemux.exe -start -encode "PSP" -rf64 -vf -nd -i "$FilePath$" -o "保存先$FileName$" -quit
echo %date% %time% END FILE=$FilePath$ >>psp.log

「""」は付け忘れるとファイルの渡すのに失敗する事があったので追加しました。

元々エンコード処理は自動化されるわけで、速度を求めているわけでもなく30秒ほど遅延を作っています。環境に応じてこの遅延は変わると思います。

今のところこれで失敗はしてないので解決してると思います。ただ2チャンネル同時の場合の処理に関してはまだ未検証ですが・・・。

以上、報告終わりっ!　次回は今期のアニメについて書きたいなぁ・・・。

Fate ZeroのOPいいよー。久しぶりに熱くなってつい歌っちゃいましたw

CD買おうかな。