libwebrtc リップシンク¶

ComputeRelativeDelay() と ComputeDelays() の詳細¶

StreamSynchronization::ComputeRelativeDelay() のシグネチャは以下のようになっている:

bool StreamSynchronization::ComputeRelativeDelay(
    const Measurements& audio_measurement,  // 音声用の StreamSynchronization::Measurements
    const Measurements& video_measurement,  // 映像用の StreamSynchronization::Measurements
    int* relative_delay_ms) // 音声を基準にした、映像の遅延時間（音声の方が遅れている場合には負の値になる）

メソッド内で行われていることは単純で次の通り:

• RtpToNtpEstimator::Estimate() メソッドを使って、最後に受信した RTP パケットのタイムスタンプを NTP ドメインに変換する（映像と音声のそれぞれ）
• 次の式で relative_delay_ms の値を計算する:
  • (映像パケット受信システム時刻 - 音声パケット受信システム時刻) - (映像パケット NTP 時刻 - 音声パケット NTP 時刻)

StreamSynchronization::ComputeDelays() の方はもう少し複雑で、シグネチャは以下のようになっている:

bool StreamSynchronization::ComputeDelays(
    int relative_delay_ms,            // 上で求めた`relative_delay_ms`の値（i.e., 音声に対する映像の遅延時間）
    int current_audio_delay_ms,       // 音声の現在の遅延時間 (`Info.current_delay_ms`）
    int* total_audio_delay_target_ms, // 音声用の同期用遅延時間（初期値は 0）
    int* total_video_delay_target_ms) // 映像用の同期用遅延時間（初期値は映像の現在の遅延時間=`Info.current_delay_ms`）

この関数は、大まかには以下のようなことを行なっている:

1. 映像の現在の遅延 - 音声の現在の遅延 + relative_delay_ms という式で映像と音声の遅延のズレを算出
   • この結果は、過去四回分が保持されており、以降ではその平均値が使用される
2. 上の結果が 30 ms 未満なら、許容範囲ということで、ここで処理は終了
   • 次節に記載の同期用遅延の反映処理もスキップされる
3. 急激な遅延調整を防ぐために、上で求めた「ズレの平均値」の値を調整する
   • 二で割った後に、±80 ms の範囲に収まるようにmin/max を取る
   • 結果は diff_ms という変数に格納する
4. diff_ms が正の場合:
   • 映像の方が遅れている（遅延時間が長い）ので 映像の遅延を減らす か 音声の遅延を増やす 必要がある
   • 別途設定された「基準となるターゲット遅延時間」よりも映像の遅延時間が長い場合には、映像の遅延時間を diff_ms 分だけ減らす
     • かつ、音声の遅延時間を「基準となるターゲット遅延時間」にリセットする
     • 注釈:

       • 「基準となるターゲット遅延時間」は StreamSynchronization::SetTargetBufferingDelay() メソッドによって設定される
       • ただし通常はデフォルト値である 0 が使用されるように見える

   • 「基準となるターゲット遅延時間」よりも映像の遅延時間が短い場合には、音声の遅延時間を diff_ms 分だけ増やす
     • かつ、映像の遅延時間を「基準となるターゲット遅延時間」にリセットする
5. diff_ms が負の場合:
   • 音声の方が遅れている（遅延時間が長い）ので 音声の遅延を減らす か 映像の遅延を増やす 必要がある
   • 映像と音声が逆転している以外はひとつ前のステップで行なっていることと同じなので、詳細は割愛する
6. ここまでで計算した映像の遅延時間が「基準となるターゲット遅延時間」を超えている場合には、その値を結果に採用する
   • そうではない場合には、前回の映像遅延時間をそのまま採用する
   • なお、遅延時間は 10 秒を超えないように min を取る
   • この値が total_video_delay_target_ms に格納されて呼び出し元に伝えられる
7. 映像で前回の遅延時間が採用されなかった場合には、音声の方の遅延時間を更新する
   • 一度のメソッド呼び出しで更新されるの映像か音声のどちらか一つの遅延時間のみ
   • それ以外は映像の場合の処理と同様
   • この値が total_audio_delay_target_ms に格納されて呼び出し元に伝えられる

映像の場合¶

• 映像の Syncable 実装は VideoReceiveStream2 クラスで行われているので VideoReceiveStream2::SetMinimumPlayoutDelay() メソッドがエントリポイントとなる
  • このメソッドの内部では（細々とした調整処理を経て） VCMTiming::set_min_playout_delay() にターゲット遅延値が渡される
  • 映像の遅延関連処理はこの VCMTiming クラスに集約されている
    • 同期用の遅延以外にも jitter, render, composition, etc の遅延がこのクラスで管理されている
• 上述の VCMTiming インスタンスへの参照は、 VideoReceiveStream2 以外にも複数箇所で共有されている
  • その内の一つが FrameBufferProxy であり、同期遅延の反映処理は、このクラスで行われている
  • FrameBufferProxy は設定によっていくつか別のクラスに処理を委譲することになる
    • 例えば FrameBuffer2Proxy が使われる場合には、 VCMTiming への参照は、さらに FrameBuffer クラスに渡されて、処理されることになる
    • 以降では、この FrameBuffer での挙動を見ていく
• VCMTiming に保持された同期用の遅延時間は、以下のメソッドの中で参照されている:
  • VCMTiming::TargetVideoDelay():「同期用遅延時間」と「jitter, decode, render 遅延の合計時間」を比較し、大きい方を返すメソッド
  • VCMTiming::RenderTime(): 「フレームのタイムスタンプ」を入力として受け取り、それを描画すべきタイムスタンプを返すメソッド
    • その際に「現在の遅延時間」を加味するが、その現在値が同期用の遅延時間の範囲内に収まるように min/max を取っている
  • VCMTiming::MaxWaitingTime(): 「デコーダに次のフレームを渡すまでの待機時間」を計算するメソッド
    • 同期用の遅延時間が 0 の場合（かつ、その他の条件が整った場合）には、特別な計算が実施される
  • この中の最初の二つのメソッドは FrameBuffer::GetNextFrame() メソッド、最後の一つは FrameBuffer::FindNextFrame() の中で使用されている
• FrameBuffer::FindNextFrame() は「次にデコードするフレーム」と「デコードまでの待機時間」を決定するためのメソッド
  • この中で VCMTiming::RenderTime() を使ってフレームの描画時刻が決定される（まだ未定だった場合）
  • その次に VCMTiming::MaxWaitingTime() を呼び出して、そのフレームをデコーダに渡すまでの待機時間が決定される
    • もしその待機時間が負数（正確には -5ms 未満）だった場合には、そのフレームはドロップされる
• FrameBuffer::GetNextFrame() は上で準備したフレームを、デコード時間になったら、実際に取得するメソッド
  • 対象フレームの描画時刻は FrameHasBadRenderTiming() 関数を使ってチェックされる
    • このメソッドに VCMTiming::TargetVideoDelay() の値も渡される
    • ざっくり言えば、タイムスタンプの値が負数だったり、遅延時間が 10 秒を超えている場合に "Bad" と判定される
    • その場合には VCMTiming::reset() を呼び出して状態をリセットした上で、再度 VCMTiming::RenderTime() を使って描画時刻が計算される

音声の場合¶

• 音声の Syncable 実装は AudioReceiveStream クラスで行われているので AudioReceiveStream::SetMinimumPlayoutDelay() メソッドがエントリポイントとなる
  • その後、以下のメソッド群の呼び出し通じて値が（ほぼそのまま）伝播する:
    1. ChannelReceiveInterface::SetMinimumPlayoutDelay()
    2. AcmReceiver::SetMinimumDelay()
    3. NetEq::SetMinimumDelay()
    4. NetEqController::SetMinimumDelay()
    5. DelayManager::SetMinimumDelay()
• DelayManager::SetMinimumDelay() に渡された遅延時間は DelayManager::Update() メソッドの中で参照される
  • これは「RTP パケットのタイムスタンプ」を入力に受け取り、内部の統計情報等を更新した上で、パケットの遅延時間を返すメソッド
  • このメソッド呼び出し時には、他のクラスから参照される「ターゲット遅延時間」の値も更新される
    • このターゲット遅延時間の値は DelayManager::TargetDelayMs() 経由で取得できる
    • DelayManager::TargetDelayMs() の返り値と DelayManager::SetMinimumDelay() に渡された値は、必ずしも一致する訳ではない
      • ただし、大枠を理解する上では「おおむね同じもの」と考えてしまってもそこまで問題はない
• DelayManager::TargetDelayMs() は DecisionLogic クラスの色々な箇所で呼び出されている
  • その中でも DecisionLogic::GetDecision() がおそらく一番重要
  • DecisionLogic::GetDecision() は最後に受け取ったパケットやジッタバッファの情報を使って、次に行うべき操作を指示する NetEq::Operation 列挙型を返す
  • 操作決定の際には DelayManager::TargetDelayMs() の値も考慮し、それに応じて Operation::kAccelerate (再生時間を早める） や Operation::kExpand (再生時間を遅らせる）を指示してペース調整が行われる
  • なお NetEq クラスについては以下のリンクも参考になる:
    • https://chromium.googlesource.com/external/webrtc/+/master/modules/audio_coding/neteq/g3doc/index.md