通話アプリはテレビ放送と比較して、映像と音声のズレが気になりにくい理由と違い
テレビ放送を見ていると、口の動きと声が少しずれて見えることがあります。 一方で作業中に使う Zoom や Teams では、映像ありでもそこまで違和感を覚えないことが多いです。 この違いは、単純な回線速度の差ではありません。音声と映像をどう同期させ、どこまで遅延を許し、どこで吸収するかという設計思想の違いでした。(ITU)
ここでは、テレビ放送で映像と音声のズレが目立ちやすい理由と、Zoom や Teams のような通話系サービスでそれが目立ちにくい理由を、同期ずれ、リアルタイム通信の設計、ネットワーク変動への対処という3つの観点から整理します。放送では音声と映像の相対的なタイミングが品質そのものに直結し、リアルタイム通話の世界では会話の自然さを守るために低遅延と同期維持の仕組みが組み込まれています。(ITU)
まず「遅れ」の理由はひとつではありません。 番組全体がライブ現場より後から届く遅延と、映像と音声のタイミングがずれて見える遅延は別物です。今回対象にしたいのは後者、いわゆるリップシンクの崩れです。ITU-R BT.1359 でも、テレビ信号の音声と映像に知覚できる時間差があると視聴体験を損なうと明記されています。(ITU)
この点は、数字でもかなりはっきりしています。ITU-R BT.1359 では、主観評価の平均として、音声が映像より約45ミリ秒先行、または音声が映像より約125ミリ秒遅れるあたりから、ずれが検知されやすくなるとされています。さらに、放送では最終的な番組切り替え点から送信機入力までの相対ずれを、音声先行 +22.5ミリ秒から音声遅れ -30ミリ秒の範囲に保つことが推奨されています。つまり、放送は昔から「音と絵をそろえる」ことを厳しく考えています。(ITU)
テレビ放送でズレが気になりやすい理由
そのように推奨しているにも関わらず、なぜテレビ放送でそのずれが気になりやすいのでしょうか。 理由は、テレビ放送の映像と音声がそれぞれ複数の処理段階を通るからです。撮影された映像と収録された音声は、圧縮、伝送、受信、復号、表示・再生という流れをたどります。そのどこかで映像側と音声側にわずかな処理差が入ると、口の動きと声にズレが生じます。(ITU)
ここで誤解しやすいのですが、これは「テレビ放送は技術的に劣っている」という話ではありません。 放送の目的は、多数の視聴者に対して番組を安定して届けることです。そのため、多少のバッファや機器処理を前提にしながら、全体として安定した配信を成立させます。結果として、もし映像と音声の処理のどこかに差が出ると、その差が視聴者に見えやすくなります。放送は「安定して届ける」仕組みであり、双方向の会話を自然に成立させることを最優先にした仕組みではありません。(ITU)
通話アプリが自然に感じやすい理由
一方で、Zoom や Teams のような通話系サービスは、「番組を安定して配ること」ではなく、相手と自然に会話できることを目的としています。だからこそ、多少の画質や音質の揺れを許してでも、体感遅延や同期ずれを小さく見せる方向で全体が設計されています。リアルタイム通信の基盤である RTP は、音声や映像のようなリアルタイムデータ向けに設計された転送プロトコルで、RTCP による監視機能も備えています。(RFC Editor)
音声側では、その思想がさらに分かりやすく表れます。 Opus は IETF 標準の音声コーデックで、Voice over IP や videoconferencing を含むinteractive audio applications向けに設計されています。つまり、最初から「会議」や「通話」のような、待たされると困る用途を想定して作られています。音声を長くためてからまとめて送るのではなく、小さな単位でどんどん送り、相手がすぐ聞けることを重視します。(RFC Editor)
ネットワークの揺らぎをどう吸収するか
それでも、インターネット上では音声や映像のパケットが毎回同じタイミングで届くわけではありません。 あるパケットは少し早く届き、別のパケットは少し遅く届きます。このばらつきがジッタです。通話系サービスでは、この揺らぎをそのまま再生してしまうと音切れや同期ずれが目立つため、受信側で少し整える必要があります。Chromium の WebRTC 実装で使われる NetEq は、まさにそのための適応的ジッタバッファで、ネットワーク状況に応じてバッファ遅延を調整しながら、音の乱れを減らしつつ、できるだけ遅延を低く保つことを目標にしています。(Chromium Git Repositories)
この「少し整えるが、ためすぎない」というバランス感覚が、通話系サービスの自然さを支えています。 テレビ放送では安定配信のための処理が積み上がりやすいのに対し、通話では低遅延を崩さない範囲で必要最小限の調整をしています。そのため Zoom や Teams のようなサービスでは、映像ありでも「ズレている」と感じる場面が比較的少なくなります。遅延がゼロなのではなく、ズレとして意識されにくい範囲へ抑え込む仕組みが強いのです。(ITU)
Teams では、この考え方が運用面にも表れています。 Microsoft の Call Quality Dashboard では、ネットワーク品質を round-trip time、packet loss、jitter から計算する Network Score で評価しています。また、ユーザー向けの通話品質表示でも、round-trip time は低いほどよく、received jitter は 30 ミリ秒未満が望ましいと説明されています。つまり、通話系サービスは単に音声と映像を送るだけでなく、その通話が自然に成立しているかどうかを継続的に観測しながら成立させています。(Microsoft Learn)
まとめ
ここまでをまとめると、テレビ放送と通話系サービスの違いは、単なる「速い・遅い」の差ではありません。 テレビ放送で目立ちやすいのは、映像と音声の相対タイミングが崩れたときのリップシンクの違和感です。これに対して、Zoom や Teams のような通話系サービスは、RTP/RTCP による時刻管理、Opus のような対話向けコーデック、適応的ジッタバッファ、品質メトリクスの監視といった仕組みを重ね、会話の自然さを最優先に守っています。だからこそ、映像ありの通話でも、「ズレていない」と感じやすいのです。(RFC Editor)
参考資料
- ITU-R BT.1359, Relative timing of sound and vision for broadcasting. 放送における音声・映像同期の検知しきい値と推奨範囲。(ITU)
- RFC 3550, RTP: A Transport Protocol for Real-Time Applications. リアルタイム音声・映像の転送基盤。(RFC Editor)
- RFC 6716, Definition of the Opus Audio Codec. Opus が VoIP やビデオ会議向けの対話用途コーデックであること。(RFC Editor)
- Chromium WebRTC, NetEq. 音声ジッタバッファが low delay と smooth playout を両立しようとする設計。(Chromium Git Repositories)
- Microsoft Learn / Support, Teams の Call Quality Dashboard と Call health。round-trip time、packet loss、jitter などの品質指標。(Microsoft Learn)