2006年03月25日

PTSとDTS

【概要】表示時刻タイムスタンプと復号時刻タイムスタンプ

PTSとDTS

MPEG2などがバッファ管理に使うもの。これがないとバッファチェックができない。
Bフレーム(MPEG1以降)を使う場合、エンコーダ/デコーダバッファ内部でQTの言う「フレーム並べ替え」が発生する。
エンコード/デコードの順番と画面に表示する順番が異なってくる為、各フレームのヘッダに順番を付けてやる必要がある。

PTS
    Presentation Time Stamp、表示時刻タイムスタンプ
DTS
    Decoding Time Stamp、復号時刻タイムスタンプ

デコーダバッファにはデータ内に並んでる通りにIPBBの順番で入って来る。デコードはIPBBの順番でないとできない。
だが、実際に表示すべき順番はIBBPだ。デコードした端からデコーダバッファから吐き出しては続くBのデコードができなくなる。
参照関係(依存関係みたいなもの)にあるBのデコードが終わるまでIとPはバッファに居てもらわないと困る。Iに至っては次のIがくるまでずっと。
eijiさんのコメントによると、
MPEG-2 Video で P/B picture が利用する参照画像は,
- P: 時間順で直前の I または P picture
- B: 時間順で直近の前後の I または P picture
ですので, 次の I が来るまで今の I を保持しつづける必要はないです. picture の参照関係は
http://www.pioneer.co.jp/crdl/tech/mpeg/2-2.html
の絵が解り易いです.
との事です。有り難うございましたm(_ _)m。
理 屈としちゃこんなかんじとおもわれ。 MovieVideoChartだとこんな漢字
中程で線で繋がってる数字がPTSと思われ
DTSは別にTime Stampでなくても良いように思えるんだけど、、、あ、可変フレームレートで使うのか!

H.264/AVCのバッファチェック

H.264/AVCのバッファチェックはHRD(Hypothetical Reference Decoder、仮想参照デコーダ、*詳細不詳)が
  • ピクチャタイミングSEI
  • バッファリング期間SEI
なるもの(ビデオストリームヘッダにあんだと思う)を参照する事で実現している。
framerefb_pyramid(QT7非互換)なんてものがある以上、「各フレームを いつまでバッファ内にとどめておくべきか」の管理はヘヴィと思われ。

AVIインフラ下におけるバッファチェック

こうしたものがある以上、MPEG系は可変フレームレート(VFR)が容易と思われる。
Quick"Time".mov ベースの.mp4は特に(そのわりにAppleのBサポートは遅かった気もするが、マイクロソフトのパテント?)
固定フレームレート(CFR)とCBR音声がa-v Syncの前提になってるAVIには、PTSもDTSもなんちゃらSEIも無い。
AVIインフラ下でのエンコードで「正しい」.mp4を生成するには、PTSもDTSもきちんと読んで、なんちゃらSEIに「翻訳」できるエンコーダを使 う必要がある。
  • 素材がMPEG系ならばPTS,DTSを参照して「翻訳」する事ができる。
    • Esperanceはこれを行っている模様。
  • MEncoderにはそもそもPTS,DTSを読む仕組みがない。
    • 素材から出力まで、完全に固定FPSを前提としたエンコードになる。
    • Xvid.avi用のデコーダをダマすハッキング=Delay Frame(冒頭に空フレームを入れてバッファ内から参照フレームが出てしまわないようにする)を使う。これでVfW/AVIの1-Frame-In-1 -Frame-Out原則は守れる。"ピクチャタイミングSEI"は固定FPSだから一定間隔として、"バッファリング期間SEI"は作りようがないよ なぁ。特にframerefb_pyramid。ウルトラあり得ねぇくらい巨大にとってんのか。keyintの指定値ぶん全部とか。

余談

其の1
b_adaptはB使用を「控える」方向にしか働かない。
するとDelay Frameの効果がバリアブルになって、不規則なa-v Desyncの原因になったりは、、、いや、ないか。
バッファに留まるフレーム数は一定のままだもんな。いや一定数じゃマズいだろ。framerefあんだし。
やっぱ"バッファリング期間SEI"を余裕みて巨大にすんだべ。
其の2
それわそれとして、MEncoderの吐く rawvideo.264からDelay Frameをカットするツールがどっか落ちてないものか。
其の3
b_pyramid使うとQT7非互換になる理由。
QT側の「フレーム並べ替え」がまだそこまでサポートしてない可能性大。AppleのBサポートは弱い。QT-APIの説明の中にBを参照フレームに使 うっぽいもんが見当たらない。
もう一つの可能性はMEncoder+mp4boxが吐き出す"ピクチャタイミングSEI"、"バッファリング期間SEI"がちょー規格外。こっちはほぼ 確実。
日々進化するオープンソースがISO MPEGのコンフォーマンス(規格適合性)試験なんて受けないだろうし。

やっぱQuickTime Player Proの代替物が欲しいなぁ。QTコンポーネントを流用できて、デコード時の優先順位を指定できて、プラグイン形式でビデオフィルタ拡張できるやつ。プラ グインでフィルタとコデックが拡張できるエンコーダでもいいや、ってそれがmediapipeだったのか^^;
posted by ばる at 02:23| Comment(2) | TrackBack(0) | MPEG-4全般 | このブログの読者になる | 更新情報をチェックする
この記事へのコメント
> Iに至っては次のIがくるまでずっと。
MPEG-2 Video で P/B picture が利用する参照画像は,
- P: 時間順で直前の I または P picture
- B: 時間順で直近の前後の I または P picture
ですので, 次の I が来るまで今の I を保持しつづける必要はないです. picture の参照関係は
http://www.pioneer.co.jp/crdl/tech/mpeg/2-2.html
の絵が解り易いです.
Posted by eiji at 2006年04月11日 03:05
本文中に追記しました。
ご指摘ありがとうございます!!
Posted by ばる at 2006年04月16日 00:28
コメントを書く
お名前: [必須入力]

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

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

コメント: [必須入力]

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


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

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

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