2005年11月17日

映像と音声の再生時間が異なるのはQT系も一緒?

【概要】QT系でも映像と音声の再生時間は異なる。
【タグ】[x264][.mp4][MEncoder][シェルスクリプト]
Doom9のmencoder+x264スレを読んで、さぁ困ったなと思い、QT系で やって見た。
、、、やっぱデノイズが無いよ〜、インタレ解除がヘボイよ〜。悲しひ。
でもまぁ、映像と音声の再生時間差は、、、あれ?異なってる。
MPEG_Streamclip_1.5.1、MoviesForMyPod、どっちも一緒。約0.2sec違う。何ソレ。デメリットしか無いじゃん!
いや、まぁ、楽だとか、MPEG_Streamclip_1.5.1ではB使ってもQTで再圧縮抜きで加工できたとかあるけども。

、、、MPEG2-PSの問題?
そういやbond氏はvobで必ずエンコード開始点を0.400秒ずらしてたな。
-ss 00:00:00.400
これこれ。これ試すべ。
MP2/AC3音声のサンプリング単位?そういやCaptyTV付属のCMカッターはバックグラウンドでm2vとaiffにdemux,remuxしてた な。
あ〜あと、MEncoderで一旦x264+aac.avi吐いちゃえってのもあるな。んでffmpegで音だけコピって.mp4化とか。
ともかく。
目標は再生時間差0.024秒!AVC-in-AVIがヤヴァイとかMEncoder使うと1フレーム足りないとかはその後!。
って事で、しこしこと下準備。シェルスクリプト作り直し。
まだまだ手直しの余地があるけど眼目は、
  • 複数ファイルの連続処理。
これに尽きる。
これでちょっとだけ設定かえて、一括試験ができる。毎回1素材ごとにスクリプト書き換えてらんない。
051117とか適当な名前で保存して、
$ sh 051117 infile01.mpeg infile02.mpeg infile03.mpeg infile04.mpeg...
で、連続で以下を行います。
  1. MEncoderでx264.avi作成(-oac copy)。
    1. 1stは.aviを出力せず、ログのみ書き出す(-o /dev/null
  2. MEncoderでraw video.264抽出(-ovc copy -of rawvideo)。
  3. 音声はffmpegでaac.mp4化
  4. muxはmp4box使用。
ToDo
  • 時間計測
  • 記録ファイルの書き出し
  • 各ツールの所在確認(ifの使い方)
などなど、手直しの余地はいっぱいあるが、こんなん。一応、手許では動作。
#!bin/bash
#Version 051117
#charset="UTF-8"
#LF

#Hensu_Tools path
MENCODER=/usr/local/bin/mencoder
FFMPEG=/usr/local/bin/ffmpeg
MP4BOX=/usr/local/bin/mp4box
#Hensu_Settings
EXT=mp4

#Hensu_Options for mencoder --Video
EXTME=avi
OPTSME_A="-oac copy"
OPTSME_V="-ovc x264 -x264encopts threads=2:me=3:bitrate=1024:qp_min=16:qp_max=51:i4x4:frameref=5:subq=6:keyint=230:cabac:deblock:nob_adapt:bframes=1"
OPTSME_VP1=":turbo=1:pass=1"
OPTSME_VP2=":pass=2"
OPTSME_VF="-vf pullup,softskip,crop=720:480:0:0,scale=640:480,hqdn3d=4:3:6,pp=l5,harddup"
OPTSME_OTHER="-ni -sws 9 -ofps 23.976 -of"
OPTSME_264="-nosound -ovc copy -of rawvideo"

#Hensu_Options for ffmpeg --Audio
OPTSFF="-y -vn -f mp4 -acodec aac -ar 48000 -ac 2 -ab 64 -map 0.1:0.0"
EXTFF=_aac.mp4
#Hensu_Options for mp4box --mux
OPTSMP4BOX="-fps 23.976"

#Hensu_Options for mp4box --info

#if-for loop
if [ -x "${MENCODER}" ]; then
for f in "$@"
do
foME="${f%.*}.${EXTME}"
echo "===MENCODER_PASS1==="
echo ${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP1} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER} ${EXTME} -o /dev/null
${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP1} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER} ${EXTME} -o /dev/null

echo "===MENCODER_PASS2==="
echo ${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP2} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER} ${EXTME} -o ${foME}
${MENCODER} ${f} ${OPTSME_A} ${OPTSME_V}${OPTSME_VP2} -passlogfile ${foME}.log ${OPTSME_VF} ${OPTSME_OTHER} ${EXTME} -o ${foME}

echo "===MENCODER_EXTRACT==="
echo ${MENCODER} ${foME} ${OPTSME_264} -o ${foME}.264
${MENCODER} ${foME} ${OPTSME_264} -o ${foME}.264

echo "===FFMPEG_AUDIO==="
foFF="${f%.*}.${EXTFF}"
echo ${FFMPEG} -i ${f} ${OPTSFF} ${foFF}
${FFMPEG} -i ${f} ${OPTSFF} ${foFF}

echo "===MP4BOX_--mux==="
echo ${MP4BOX} ${OPTSMP4BOX} -add ${foME}.264 -add ${foFF} -new ${f}.${EXT}
${MP4BOX} ${OPTSMP4BOX} -add ${foME}.264 -add ${foFF} -new ${f}.${EXT}

echo "===MP4BOX_--info==="
echo"${MP4BOX} -info ${f}.${EXT}"
${MP4BOX} -info ${f}.${EXT}
done
else
echo "Command not found: ${MENCODER}!"
fi

参考にさせて頂いたのは、此方。有り難い有り難い。
posted by ばる at 23:00| Comment(4) | TrackBack(0) | mencoder[スクリプト] | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
えっと、MPEGStreamclipは時間軸操作を独自にやってたはずです。VFRとか使えないんで。

PSの時間軸完全保持するエンコーダは多分QTPlayerとmpeg2decxくらいでしょう。で、後者はH.264対応版が出てないんで中間生成物が必要です…。

いずれにせよ、逆テレシネやデインターレース処理するならもはやQT系は選択肢にあがってこないかもです。
Posted by Yoshiki@その蜩blog at 2005年11月24日 14:04
毎度有り難うございます。

>MPEGStreamclipは時間軸操作を独自にやってたはずです。VFRとか使えないんで。
なるほど〜。元がTVCMカッターですからねぇ。やっぱQuickTime Player すごいなぁ。
あ、エントリで書き漏らしましたのでMPEGStreamclip経由のApple-h.264のマルチパスの印象を。

ハイデフ・分散環境にチューンされたAVC/H.264アプライアンス。
どんな素材でも一定水準の画質を出さねばいけないプロ/ハイエンドアマチュア向け。という印象です。
エンコ中のスレッド数は6〜9程度。
・各パスは速い。ほぼ実時間(2G-Dual)。スレッド数が多い程CPUの空回りが減る。
 ただし、理屈の上では分散するほど圧縮率が低下します。
 DualCPU程度では各スレッドの待機時間もでるハズです。
 できればこのへんのバランスを考えて弄りたいところです(x264は最大4ですが、自分は2にしてます)。
 高解像度では分散で時間を稼ぐ方が圧倒的に重要ですから、そんな調整してる余地は無いでしょう。
4パス(5かも?)
・パスが多い程、動き予測の精度が向上。
 ただし、効果は映像内容次第で、3パス以上を必要とする素材は(MEncoderの初心者向けガイドでは)例外扱い。
 たぶんその「例外」もデフォでうまく取り回せる。
高解像度コンテンツが普及して、かつ、8CPUとかザラになれば、、、いずれにせよかなり先ですが、今から見込んでる臭いと思いました。

>逆テレシネやデインターレース処理するならもはやQT系は選択肢にあがってこないかも

や、タイガーでQT系作り易くなったと聞きますし、地味にシェアも上がってますし。これからかもしれません。やっぱ楽ですし^^;。
ところで「時間軸」=「timescale」と理解して良いものでしょうか?
Posted by ばる at 2005年11月25日 01:32
私も以前、不用意に時間軸という単語を使ってしまったので、ちょっと整理
して説明します。長文失礼。

A〜DのIDをつけた4枚の画像をスライドショーにする場合を考えてみます。
まず、A→B→C→Dの順番で表示するというルールを設定します。
この時点で、このスライドショーは図1のように時間軸を持っています。

◎図1(すみませんが等幅フォントで見てください)
 −−−−−−−−−−>(時間軸)
 A B  C  D 

AとBの間隔よりもBとCの間隔が長いのはワザとです。最初のルールは画像の
表示順序を規定しただけですから、個々の画像の表示タイミングはまだ決まって
いません。
そこでまず、時間軸のタイムスケールの最小単位は1秒というルールを追加します。

◎図2
 0123456789(秒)
 ++++++++++>(時間軸)

時間軸が図2のように、タイムスケールを持つようになりました。
しかし、これだけではどの時点でどの画像を表示するかは決定できません。
時間軸の0秒から0.5fpsで表示するというルールを追加しましょう。
結果は図3のようになります。

◎図3
 0123456789(秒)
 ++++++++++>(時間軸)
 A B C D  

固定フレームレートが実現できました。しかし、個々の画像の表示間隔
は一定なので、開始時刻とフレームレートを指定するだけでは、図4の
ようなフレームレートが一定ではない状態を表現できません。

◎図4
 0123456789(秒)
 ++++++++++>(時間軸)
 A B  C  D 

図4のような状態を実現するには、各画像のタイムスタンプを保存する
必要があります。図4から各画像のタイムスタンプを抜き出したのが、
表1です。

◎表1
 A=0
 B=2
 C=5
 D=8

Bのタイムスタンプが2である事は、始まってから2秒後にBが表示される
事を意味「しない」事に注意してください。
タイムスケールの最小単位が1分であれば、Bは2分後に表示されます。

ここまで、以下の事を説明しました。
・時間軸とタイムスケールは別物で、時間軸はタイムスケールを持つ場合と
 持たない場合がある。
・時間軸とタイムスケールの最小単位は固定フレームレートにも存在する。
・完全な可変フレームレートを実現するには、タイムスケールの最小単位と、
 タイムスタンプを保存する必要がある。

(大雑把ですが)結論はこうです。
タイムスタンプを保存しないと可変フレームレートを実現できない。

正直、QuickTime用語はよく分かりませんので、もし誤解や間違いがあれば
指摘をお願いします。>Yoshikiさん
Posted by at 2005年11月26日 19:00
有り難うございます。

【みなさんへ】
頂いたコメント、そのままエントリ化させて頂きたいと思いますので、以後のコメントはそちらへお願い致しますm(_ _)m。
Posted by ばる at 2005年11月27日 01:18
コメントを書く
お名前: [必須入力]

メールアドレス: [必須入力]

ホームページアドレス: [必須入力]

コメント: [必須入力]

認証コード: [必須入力]


※画像の中の文字を半角で入力してください。
この記事へのトラックバックURL
http://blog.seesaa.jp/tb/9465720
※言及リンクのないトラックバックは受信されません。

この記事へのトラックバック
×

この広告は1年以上新しい記事の投稿がないブログに表示されております。