<mini> rtmp の簡易まとめ (H.264/AVC, timestamp, CT, DT)

　H.264/MPEG-4 AVC 部分のまとめが少ないと思うので、そこをまとめようと思う。前日の「H.264 について（まとめ） 【H.264/Annex B/NAL file format/AVC/rtmp】」も参照ください。

H.264/AVC は Decoding times (DT) と Composition times (CT) が必要

　この 2 値が必要です (ちなみに DT は DTS (Decode timestamp), CT は PTS (Presentation timestamp) とも)。

　この値は名前の通り、デコードする時間と表示する時間を表します。FLV コンテナー、rtmp では Composition time offset (CTO) として扱っています。まあわかると思いますが、timestamp (DT) をずらせば、CT も自動でずれるってことですね。サーバー側での実装を複雑化させないためにもこうなっているのかと。

VIDEOPACKET - AVCVIDEOPACKET

　FLV コンテナーの仕様書に乗っていますが改めて。

• AVCPacketType AVCPacketType
  enum AVCPacketType: uint8_t { SequenceHeader = 0, Nalu = 1, EndOfSequence = 2 };
• int24_t CompositionTime (int24_t です! uint24_t ではありません)
  if (AVCPacketType == AVCPacketType::Nalu)
  　Composition time offset
  else
  　0
• std::vector<uint8_t> data
  if (AVCPacketType == AVCPacketType::SequenceHeader)
  　AVCDecoderConfigurationRecord
  else if (AVCPacketType == AVCPacketType::Nalu)
  　One or more NALUs.
  　Data sample: length | NALU | length | NALU | … | length | NALU
  else if (AVCPacketType == AVCPacketType::EndOfSequence)
  　Empty

　AVCDecoderConfigurationRecord は前回説明しているので割愛。改めて確認事項。ここでは CTO の値が記述されています。したがって CT を求めるには timestamp (DT, 1 ms unit) に CTO (1 ms unit) を足し算するだけでおｋ (なハズ) です。

　おｋなハズ、と書いているのは確証がないからですｗ　MP3 と AAC で H.264/AVC な映像の再生速度が変わる謎減少に襲われていたり、H.264/AVC の再生速度がおかしかったり… Windows Runtime 向けのクラスに渡す値の解像度が違うのかな？ 100 ns unit だと思って渡しているつもりなんですが…

FLV はかなり独自色が強い

　FLV って独自色強いですね…　F4V フォーマットも同じ文章にちらっ、と乗ってあるのですが、こちらはさすがに QuickTime (MOV) や MP4 を参照しているので、そっちの色がかなり入っています。

　FLV って意外にフォーマットが簡単なので実装も割と楽な気がします (そのかわりできることも少ないが…)。将来的には Windows ストア アプリ向けの動画再生ソフト作ったりもしたいなーとか思ってたりするんですけど、F4V が嫌らしいですねｗ

まとめ

　timestamp について自分的まとめを書いた感じです。これ、よくわからなかったのですが、まあ理解できました。ただ、うまく音声と映像が同期して再生されないのが問題なので、このあたり要調査ですね。

　以上。