・video/audio captureの追加
UOClist
download uoclist0.8.1.53.zip
まだuoclist本体への組込みが完全ではありませんが、
キャプチャ機能を追加しました。
まだまだ改良が必要ですが、やっとRazorにおいついた感じｗｗｗ
画面サイズが大きくなると、僕のVista初期の頃に買ったノートPCでは
コマ落ちが激しいです＞＜
新しいPC買うか。
このノートPC、A4サイズで1400x1050の画面サイズなので、今の時期、こたつに
入ったままUOするのにいいんだけどなぁ。。。
エンコーダのセッティングは、
videoをx264、audioをOS付属のMPEG Layer-3にしてます。
OS付属のMPEG Layer-3のエンコーダ機能を有効にするには、
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
の
m3acm.l3acmのデータをl3codecp.acm
に書き換える必要があります。
LameのMP3エンコーダだと、CBRっていってもABRなためかサイズが可変なので音ズレがでると
思う。
AACのacmエンコーダがあればいいんですけどねぇ。。。
x264の設定は今はこんな感じ。
コマ落ちに対しては、キャプチャ済み画像で代用してAVIStreamWrite()の繰り返しで埋め合わせをしています。
AVIなので、設定した15FPSに見合うコマ数を書き出さないと、videoとaudioの時間ズレが発生
してしまうので。。。
コマ落ち対応はもうちょっと工夫が必要だな。
追記:)
うーん、やっぱりvideoとaudioのズレがどうしても出てしまう。
audioがバーチャルデバイスのソフトドライバだからってのもあるけど、ズレが酷いよね。
同期をとる工夫が必要か。。。
audio側を基準にして、video側の水増しで調整するしかない？？？
追記2:)
原因を推定してみると
video側は、timeGetTime()を基準にどうにかこうにか15FPSのコマをAVIStreamWrite()でつくろうと
頑張っている。
audio側は、waveInのドライバがバッファに指定したサンプリング周波数でデータを詰め込んでいき
貯まったところ(MP3の変換前ブロック長の定数倍の長さになったところ)で、次のバッファをキュー
から取り出してきて、貯まったよってメッセージを送る。
そのデータをMP3に変換してAVIStreamWrite()に流し込む。
videoとaudioでまったく干渉のない作業をしているんですね。
waveInからのサンプリングの取りこぼしがあると、audio側の時間が伸びてしまう。
なのでaudio側の伸びた時間をvideo側の基準時間、もしくはaudio側のAVIStreamWrite()の
タイミング周期から換算して、伸びた分をvideo側で調整するのが
やりやすいかな。audio側は、MP3変換のためのブロック長が決まっているので、間引くためには
コーディング的には手間が多くなる。
追記3:)
いやいやまてよ。
video側、15FPSに設定しているけど、timeGetTime()はミリ秒までの精度しか出せないから
間隔で言うと1000/15=66.6666を四捨五入して67msecに取り込み間隔を設定している。
処理の実行時間を考えてないから、誤差で伸びることもあるだろう。
なので、正確には14.93FPS。0.07枚足りない。3分=180秒だと、12.6枚も足りない。
12.6/15=0.84秒短くなる、ってことか。
15FPSでぴったりの枚数にするには、1/0.07=14.3秒毎に1枚余計に追加するってことかいね？
枚数でいうと、14.93*14.3=213.5回、AVIWriteStream()を実行したら、1回余計に
AVIWriteStream()を実行する、ってことかな？
なんかピッタリの数字でなくて気分悪いけど。
audio側のサンプリングレートの正確さを信じるとすると、こういうことか。
追記4:)
さらに考えてみると、15FPSに設定するんでなくて、14.93FPSに設定すればいいのか。
AVICreateStream()はdwScaleとdwRateで決めるようになっているんで、
dwScale=1, dwRate=15とするんじゃなくて、
dwScale=67, dwRate=1000
とすれば、辻褄が合うじゃん
追記5:)
どうやら、追記4:)が正解のようだ。パラメタ修正だけですむからすぐ確認できた。
あとは、1時間とか録画したときにどれくらいズレが出るかだなぁ。。。
0 件のコメント:
コメントを投稿