ｽﾗｲﾄﾞﾀｲﾄﾙなし

Size: px

Start display at page:

Download "ｽﾗｲﾄﾞﾀｲﾄﾙなし"

そうすけたけはな
5 years ago
Views:

1 画像情報特論 (5) - アダプテーション (1) RTP/RTCP メディア同期情報理工学専攻甲藤二郎 katto@waseda.jp

2 プロトコル階層インターネット AV の仕組みメディアセッション制御レイアウト記述ビデオオーディオ SDP SMIL RTP / RTCP RTSP, SIP, SAP HTTP 等 UDP or TCP TCP IP 各種ネットワーク

3 アダプテーション

4 ストリーミングダウンロード TCP ファイルサーバクライアントストリーミングダウンロードしてから同期再生 ( 待ち時間が我慢できない ) UDP or TCP パケットサーバクライアント受信しながら同期再生 ( 待ち時間がほとんどない )

5 ストリーミングの課題インターネット : もともとリアルタイムメディア用のネットワークではない 1. 同期再生到着時間がばらばらのパケットからどのように同期再生するか 2. パケット廃棄対策廃棄されたパケットの影響をどのように抑えるか 3. ふくそう制御レートを上げすぎるとふくそうが起こり下げると品質が劣化する

6 アダプテーション同期再生パケット廃棄対策ふくそう制御の問題解決アプリケーション層ビデオオーディオアダプテーションリアルタイムメディア特有の機能トランスポート層 UDP or TCP ネットワーク層 IP リンク物理層各種ネットワーク

7 RTP/RTCP RTP: Real-time Transport Protocol RTCP: RTP Control Protocol

8 RTP RTCP の基本的な使い方送信側 RTP パケット受信側 RTCP-SR RTCP-RR データ RTP UDP IP リンク RTP パケット RTCP UDP IP リンク RTCP パケット

9 RTP v=2 P X CSRC カウント M パケットタイプシーケンスナンバタイムスタンプ SSRC 識別子 CSRC 識別子 (list) ( ペイロードフォーマット拡張 ) データパケットタイプ : 転送データの符号化アルゴリズムシーケンスナンバ : パケット廃棄の検出 (for パケット廃棄対策 ) タイムスタンプ : 同期再生 (for メディア内同期 ) Mビット : フレーム境界の通知 SSRC: ストリームの識別子 ( セッション内でユニーク )

10 パケットタイプ PT encoding audio/video clock rate channels (packet type) name (A/V) (Hz) (audio) 0 PCMU A G721 A GSM A PCMA A G722 A MPA A G728 A JPEG V H261 V MPV V MP2T AV ~127 dynamic タイムスタンプの解像度最近の符号化アルゴリズムは SDP を用いた動的割り当て

11 M ビットアルゴリズムに応じたパケット区切りの解釈典型的な使い方 : 音声の場合 : 有音無音区間の区切り RTP パケット m=0 m=0 m=1 m=0 有音区間無音区間ビデオの場合 : フレームの区切り m=0 m=0 m=1 m=0 m=1 フレーム #1 フレーム #2

12 RTCP-SR (Sender Report) v=2 P RC PT=SR=200 送信元 SSRC 識別子パケット長 NTP タイムスタンプ (MSB) sender report NTP タイムスタンプ (LSB) RTP タイムスタンプ送出パケット数 (total_packets) 送出バイト数 (total_bytes) SSRC 識別子 #n report block * n 瞬時廃棄率累積廃棄パケット数シーケンスナンバの最大値ジッタ遅延 SSRC #n の最新の SR 受信時の NTP タイムスタンプ (LSR) LSR から現在までの遅延 (DLSR)

13 RTCP-RR RR (Receiver Report) v=2 P RC PT=SR=201 送信元 SSRC 識別子パケット長 SSRC 識別子 #n report block * n 瞬時廃棄率累積廃棄パケット数シーケンスナンバの最大値ジッタ遅延 SSRC #n の最新のSR 受信時の NTP タイムスタンプ (LSR) LSR から現在までの遅延 (DLSR)

14 ラウンドトリップ遅延の計算 sender elapsed T A RTCP-SR RTCP-RR receiver LSR DLSR delay 送受信端末間の NTP 同期が信頼できる場合 : delay = T A DLSR -LSR NTP 同期が信頼できない場合 : delay (elapsed DLSR) / 2

15 ジッタの計算 sender S i S i+1 RTP #i RTP #j receiver R i R i+1 瞬時ジッタの計算 : Jitter(i) = (R i+1 -R i ) (S i+1 S i ) 平均ジッタの計算 : Jitter ave = (1-α) Jitter ave + α Jitter(i) (α=1/16)

16 交換情報の整理 RTP RTCP メディア同期 RTP タイムスタンプ NTP タイムスタンプ RTP タイムスタンプパケット廃棄対策シーケンスナンバペイロードフォーマット ( 後述 ) フロー制御パケット廃棄率ラウンドトリップ遅延ジッタ

17 RTCP パケット一覧名称目的 SR (Sender Report) 送信者からの NTP タイムスタンプと統計情報 ( 送信パケット数送信バイト数 ) の通知 + 受信者でもある場合は Receiver Report RR (Receiver Report) 受信者からの統計情報 ( 廃棄率ジッタ等 ) の通知 SDES (Source Description) セッション参加者の情報 (CNAME メールアドレス等) BYE セッションからの離脱 APP (Application Specific) アプリケーション拡張

18 SDES アイテム一覧 SDES アイテム識別番号目的 END 0 SDES アイテムの終了 CNAME 1 参加者毎に固有の識別子 ( 例 : foo@pc.waseda.ac.jp) NAME 2 参加者の名前 3 参加者の電子メールアドレス PHONE 4 参加者の電話番号 LOC 5 参加者の住所 TOOL 6 参加者の使用しているアプリケーション名 NOTE 7 参加者の状態 ( 例 : 電話中で話せません ) PRIV 8 アプリケーション拡張 RTP の SSRC: ストリーム毎に固有の識別子 RTCP-SDES の CNAME: 参加者毎に固有の識別子

19 RTCP の送信間隔 sender 5 秒以上 * [0.5, 1.5] RTP RTCP #i RTCP #j receiver RTCP の情報量は全体の 5% を超えてはいけない受信者数の増加と共に ( マルチキャスト時 ) 送信間隔も増加させる

20 DCCP Datagram Congestion Control Protocol

21 DCCP ヘッダ 4 byte 送信者ポート番号受信者ポート番号オフセット ( ヘッダ長 ) CCVal CsCov チェックサム予約タイプ X 予約シーケンスナンバ (high bits) ( シーケンスナンバ (low bits) if X= 1 ) ( オプション ) データ CCVal (Congestion Control Value) : 別途既定されるプロファイルに応じて送信者が輻輳制御情報を通知するために使用 CsCov (Checksum Coverage): チェックサムがパケットのどの部分までカバーするかを通知通常 UDP では 1 ビットでも誤ったらパケットを廃棄するが CsCov は無線応用を想定してデータ部のビット誤りを許容 UDP-Lite (RFC 3828) の考えを踏襲

22 DCCP パケットタイプフィールドと DCCP パケットセットアップデータの送受信タイプ DCCPパケット目的 0 DCCP-Request クライアントによる接続要求 1 DCCP-Response 接続要求に対するサーバの応答 2 DCCP-Data アプリケーションデータの送信 3 DCCP-Ack アプリケーションデータを伴わないACK 4 DCCP-DataAck アプリケーションデータを伴うACK 5 DCCP-CloseReq サーバからの接続終了要求 6 DCCP-Close クライアントからの接続終了要求 7 DCCP-Reset 接続の終了通知 8 DCCP-Sync 障害発生時の同期回復要求 9 DCCP-SyncAck 同期回復要求に対するACK 障害対策終了処理

23 DCCP 手順 Client DCCP-Response DCCP-Request DCCP-ACK Server Session setup by 3-way handshake DCCP-Data DCCP-Data DCCP-ACK DCCP-ACK Data transfer DCCP-Close DCCP-CloseReq DCCP-Reset Session termination

24 DCCP 輻輳制御 CCID と DCCP の輻輳制御手段 CCID 輻輳制御手段 0 Reserved 1 Unspecified Sender-based Congestion Control 2 TCP-like Congestion Control (TCP と同様の AIMD 制御 : オンラインゲーム用 ) 3 TFRC Congestion Control (TCPフレンドリ制御:AV 系アプリケーション用 ) CCID=2: 2 個のパケットを受信するたびに ACK を返す AIMD 制御 CCID=3: RTT ごとに ACK を返す TFRC 制御 ( 後日説明 )

25 メディア同期バッファリング + タイムスタンプ

26 三種類の同期メカニズム (1) 共通クロック ( 狭帯域回線交換 ) ネットワークあるいは外部から信頼できる共通クロックを提供する狭帯域ネットワーク ( 例 ) 電話網 ISDN モバイル端末 A 端末 B 網クロック (8kHz) (2) 搬送クロック ( 広帯域回線交換 ) クロックを相手端末に搬送する受信側は PLL でクロックを生成広帯域ネットワーク ( 例 ) ATM ディジタル放送端末 A PLL 端末 B (3) 自走クロック ( インターネット ) まず端末自身の自走クロックを信頼する端末間同期は NTP を利用精度に問題 ( 例 ) インターネット端末 A 端末 B NTP

27 固定遅延モデル (1) 固定遅延キャプチャネットワークエンコードバッファバッファデコード再生固定遅延モデル (constant delay model) (1) 共通クロック方式 ( 回線交換 ) 固定固定固定すべてが網クロックに従って動作 (2) タイムスタンプ方式 ( パケット交換 ) 可変可変可変可変可変可変固定固定タイムスタンプ

28 固定遅延モデル (2) キャプチャから再生までの遅延時間が一定 (1) 共通クロック方式 ( 電話網ディジタル放送 ) エンコードデコードネットワークの処理時間 ( 遅延 ) が一定キャプチャから再生まで固定遅延 (2) 自走クロック方式 ( インターネット ) エンコードデコードネットワークの処理時間 ( 遅延 ) が可変バッファリングで遅延のばらつきを吸収タイムスタンプ ( キャプチャ時刻 ) で再生時刻を決定キャプチャから再生まで固定遅延

29 バッファリング (1) インターネット放送 ( 片方向 ) 大容量バッファ (~ 数十秒 ) パケットサーバクライアントインターネット電話 ( 双方向 ) パケット小容量バッファ (~ 数百 ms) サーバクライアント

30 バッファリング (2) ジッタ ( 遅延のばらつき ) の吸収 (1) インターネット放送片方向なので数十秒間のバッファリングを行ってもユーザは気にならないユニキャスト時はTCPが利用可能 ( パケット廃棄対策が不要 ) ( 注 ) マルチキャスト時はUDPを使用 ( パケット廃棄対策が必要 ) (2) インターネット電話双方向なのであまり長時間のバッファリングを行うと会話にならない TCPは利用困難 UDPを使用 ( 一般的にパケット廃棄対策が必要 )

31 三階層のメディア同期 (1) メディア内同期メディア内同期一つのメディア ( ビデオあるいはオーディオ ) の同期再生の実現 ( 手段 ) RTP タイムスタンプ ( 固定遅延モデル ) (2) メディア間同期複数のメディア ( ビデオとオーディオ ) の同期再生の実現 ( リップシンク ) メディア間同期 ( 手段 ) RTCP によるタイムスタンプの関連付け (3) システム間同期端末毎のシステム時刻の調整 ( 手段 ) ネットワークタイムプロトコルシステム間同期

32 メディア内同期キャプチャ送信受信再生 TS =100 TS =150 TS =100 RTP パケットバッファリング遅延 TS =200 TS =250 TS =300 TS =350 TS =150 TS =200 TS =250 TS =300 TS =350 RTP タイムスタンプによる再生時刻の復元 TS =100 TS =150 TS =200 TS =250 TS =300 ジッタ到着時間の揺らぎ TS =350 エンコードデコード固定遅延モデル RTP

33 メディア間同期リップシンクのずれ補正後 ( メディア間同期 ) 補正前 ( メディア内同期 ) オーディオ音声 (RTP) 時間軸ビデオ補正補正ビデオ (RTP) 時間軸 RTCP 補正共通 (NTP) 時間軸個々のメディア用タイムスタンプ (RTP) + 共通時間軸のタイムスタンプ (NTP) RTCP

34 システム間同期複数人による実時間会議の問題点 10:40:41 メディア間同期 B 10:41:34 10:40:25 A C メディア間同期 B から来るメディアと C から来るメディアの時間軸を整列することができない複数人が同時に話してもそれを同時に再生できない結局すべての端末の時刻をそろえるしかない NTP

35 NTP (Network Time Protocol) ネットワーク上の端末の時刻を合わせるためのプロトコル ( 例 ) UNIX: xntpd Windows: 桜時計など... stratum 1 サーバ原子時計 GPS... stratum 2 サーバ stratum 3 クライアントサーバクライアント型パケット情報交換ラウンドトリップ時間計測時刻の推定数ミリ ~ 数十ミリ秒の誤差と言われているがリアルタイム系の精度の問題も指摘されている

36 実践編

37 メディア同期の実際 (1. 送信側 ) キャプチャカードキャプチャバッファ ( 専用カード ) アクセラレーションエンコードネットワークカードネットワークタイムスタンプ付与バッファバッファの活用 ( 実体はメモリ ) バッファ : 冗長構成 ( ダブルバッファ数十ミリ ~ 数百ミリ秒のバッファリング )

38 メディア同期の実際 (2. 受信側 ) ネットワークカードネットワークバッファタイムスタンプ処理バッファ ( 専用カード ) アクセラレーションデコードサウンドビデオカード再生バッファバッファの活用バッファ : 冗長構成 ( ダブルバッファ数十ミリ ~ 数秒のバッファリング )

39 メディア同期の実際 (3) オーディオのストリーミング再生バッファ - デコードサウンドカード書込みのタイムイベント管理デコード - サウンドカードにおける読出し位置書込み位置のオフセットによる遅延タイムイベント書込みカーソル復号データサウンドカードに起因する遅延要因読出しカーソルリングバッファオーディオ出力サウンドカード

40 メディア同期の実際 (4) ビデオのストリーミング再生バッファ - デコードビデオカード書込みのタイムイベント管理デコード - ビデオデータ読出し書込みのダブルバッファ構成タイムイベント復号データ書込みビデオカードビデオメモリ読出しビデオ出力

41 メディア同期の実際 (5) フレーム k フレーム k+1 フレーム k+2 受信バッファ遅延 t B (k) 復号遅延 t D (k) 復号タイムイベント再生遅延 t P (k) 再生フレームバッファ t B (k) = variable, t D (k) + t P (k) = const

42 メディア同期のモデル (1) 定常モデルデータ量 S 受信データ再生データ理想 ( 傾きが受信レート ) 傾きが再生レート T B 遅延 (= t B + t D + t P ) 0 受信バッファ量時間プレイアウト遅延

43 メディア同期のモデル (2) 受信バッファのアンダーフローとオーバーフローデータ量 S オーバーフロー ( パケット廃棄 ) B max 0 アンダーフロー ( フリーズ ) 時間ただし ( メモリを十分に使える ) PC ではオーバーフローはあまり発生しない

44 メディア同期のモデル (3) プレイアウト遅延アンダーフロー対策 (1) データを送れるときに早めに送ってしまう ( プリフェッチング ) (2) 送信レートを下げる (TCP フレンドリ : 次回参照 ) ( 欠点 ) ライブには適用できない

ｽﾗｲﾄﾞﾀｲﾄﾙなし

ｽﾗｲﾄﾞﾀｲﾄﾙなし画像情報特論 (3) -TCP/IP (2) TCP (Transport Control Protocol) UDP (User Datagram Protocol) 2004.04.30 情報ネットワーク専攻甲藤二郎 E-Mail: katto@waseda.jp TCP Transport Control Protocol インターネットの基礎プロトコルスタック端末 T アプリケーション

ｽﾗｲﾄﾞ ﾀｲﾄﾙなし

ｽﾗｲﾄﾞﾀｲﾄﾙなし