仕事は昨日までで終わったので、今日は一日オフの日。
折角香港にいるのですからどこかへ出かければよいものを、そこは真正の引きこもりであるところの僕はホテルに引きこもっています。
・・・いや、お昼ぐらいから出かけようかとは思っているのですが。
んで、引きこもって何をやっているのかというと艦コ・・ではなく、新年度の動画エンコード環境の修正を。
(ちなみにDMMのサーバは海外のアドレスからアクセスすると一部のサービスしか使えないのでopenvpnで国内を経由させています)
ずっとts2aacでaacに変換していたのですがなぜか、先日たまに1パケット抜出に失敗していたりする、ということに気が付き、最近のDGIndexはちゃんとaacをデコードしてくれるので、ひとまずaacの抜出をd2v作成時に一緒にやってしまおうと変えていたら、実は音ズレしていることに気が付いたりしたところなので(先日の投稿)。
とりあえず、先日の話を一回まとめると
映像の位置はDGIndex基準で音声の最初のパケットを破棄する場合を-1、挿入する場合を+1として、
◆TS→AAC時:
±0:DGIndex
+1:ts2aac -B
◆aac→wav
-1:faad -e1:0 (-eオプションを指定しない時も同様)
±0:faad -e0:0
neroaacdecは試してません
◆ TS→wav時
±0:faad-ptsbase3 e 0:0
◆wav→aac
+約2.5:neroAACenc(LC)
+1:faac
的な。1サンプル・最終的にwav波形で確認しているのでデコード時にどんだけずれているかによって基準は変わる、という調査状態ですが。
自分用のメモなので信用しないでください。
そんなことを先日やったのですが、その結果たまにaacedit2がおかしな挙動を示すようになりました。
具体的には
* PID 104e DELAY -392ms.aac
的なファイル名時に、delayとしては「-392」が正しいのですが「392」だと認識しているんです。
意味不明・・・とか思っていたのですが、aaceditはソースがあるのでちょっと見てみました。
そうしたところ、凡人には理解できないコードが・・・
説明は省きますが、
case 0 :というのを
if ( c == '-' ){
nMinus = 1;
nValue = 0 ;
nPosMinus = nPos ;
}
if(( c >= '0' ) & ( c <= '9' )){
nMinus = 0;
nValue = c - '0';
nPosMinus = nPos ;
}
nState = 1 ;
break ;
case 0 :としてみました。まぁ、なんでこーなっているのか理解できないのを変えただけなので、実は元のコードにも何か意味があるのかもしれませんが。
if ( c == '-' ){
nMinus = 1;
nValue = 0 ;
nPosMinus = nPos ;
nState = 1 ;
}
else if(( c >= '0' ) & ( c <= '9' )){
nMinus = 0;
nValue = c - '0';
nPosMinus = nPos ;
nState = 1 ;
}
break ;
ひとまず、これでおかしな認識はしなくなった気がします。
0 件のコメント:
コメントを投稿