【文献】
Ericsson,Requirements for end-to-end video rate adaptation,3GPP TSG-SA4 Meeting #79 S4-140686,2014年 5月15日,pp.1-11
(58)【調査した分野】(Int.Cl.,DB名)
【発明を実施するための形態】
【0017】
[0025]ビデオ電話(VT)機器は、VTセッション(例えば、VT機器間のオーディオデータ及び又はビデオデータの送信)を行うための有線又はワイヤレスネットワークを介して接続され得る。別のVT機器への送信のためにオーディオデータ及び又はビデオデータを処理しているVT機器は、送信機機器と呼ばれ得る。同様に、(例えば、VT機器のユーザへの提示のために)受信されたオーディオデータ及び又はビデオデータを処理しているVT機器は、受信機機器と呼ばれ得る。
【0018】
[0026]送信機機器は、特定のレート(本明細書では交換可能にビットレートと呼ばれ得る)でオーディオデータ及び/又はビデオデータを符号化することができる。送信機機器は、ネットワーク条件に基づいてレートを選択することができる。例えば、送信機機器は、VTセッションのために使用されているネットワークによってサポートされる最大の(又は最大に近い)ネットワークリンクレートに基づいてレートを選択することができる。このようにして、送信機機器は、ネットワークの制限を超えることなく、ネットワークによってサポートされる相対的により高い品質を使用して送信されるようにデータを準備することができる。
【0019】
[0027]幾つかの事例では、VT機器を接続するネットワークリンクレートは、特にWi−Fi(登録商標)又はセルラーネットワークなどのワイヤレスネットワーク上でVTを使用するとき、変化し得る。幾つかの事例では、ネットワーク機器は、リンクレートの変動に対処するために、及び/又はキュー管理を実行するために、バッファを使用し得る。例えば、送信機機器は、データを受信機機器に送信する前に符号化されたオーディオデータ及び/又はビデオデータをバッファリングするためのバッファを含み得る。ネットワークリンクレートの突然の低下は、VTセッションに悪影響を与え得るボトルネックを引き起こし得る。例えば、ネットワークリンクレートが下がるとき、バッファの中に符号化されたビデオデータを蓄積するための送信機機器、これは、受信機機器でのVTセッションにおいて中断及び/又はジャーキネスを引き起こし得る。
【0020】
[0028]送信機機器は、ネットワークリンクレートの低下に応答して、ビデオデータが送信されるレート(本明細書では送信レートと呼ばれることがあり、レートはビットレートを指すために本開示全体で使用される)を変更することができる。幾つかの例では、送信機機器は、オーディオデータ及び/又はビデオデータが符号化されるレートを変えることによって、送信レートを変更することができる。しかしながら、受信機機器の混雑制御フィードバックの遅延、受信機機器から送信機機器への戻り経路における遅延、レート適合反応の遅延などにより、レートを下げる際に反応の遅延があり得る。従って、送信レートは、ネットワークリンクレートの低下からある時間期間の間、ネットワークリンクレートを大きく上回ったままであり得る。送信レートとネットワークリンクレートの不整合は、ボトルネックのリンクにおけるバッファレベルの増大、従ってエンドツーエンドの遅延の増大(また更にはパケットの喪失)をもたらすことがあり、これはVTセッションの品質体験に悪影響を与えることがある。
【0021】
[0029]加えて、送信機機器がネットワークリンクレートの低下に応答して送信レートを下げた後でも、ある時間は蓄積された遅延が残り得る。例えば、一般に、遅延は、データがネットワークリンクにわたる送信に利用可能であることと、データがネットワークに実際に送信される時間との間の時間を指し得る。従って、遅延はデータのバッファリングと関連付けられ得る。例えば、遅延の増大はバッファレベルの増大をもたらし、それは、符号化の後に、及びネットワークへの送信の前にデータが記憶されなければならないからである。
【0022】
[0030]送信レートとボトルネックのネットワークリンクレートとの間の差に応じて、送信機機器は、バッファリングされたデータの品質を比較的ゆっくり下げることがある。即ち、低減された送信レートとネットワークリンクレートとの間の差が比較的小さい場合、送信機機器は、蓄積された遅延を比較的ゆっくり減らすことがあり、VTセッションへの影響が残ることがある。
【0023】
[0031]バッファリングされたデータの量を下げることに対する1つの手法は、推定されたネットワークリンクレート未満に送信レートを下げることである。比較的保守的な手法、例えば、推定されるネットワークリンクレートを大きく下回る送信レートを使用することは、リンクの不十分な使用と、受信機機器におけるビデオ品質体験の全体的な低下とをもたらし得る。しかしながら、そのような保守的な手法はまた、ボトルネックのリンクのバッファを比較的速く減らすことができる。逆に比較的積極的な手法、例えば、送信レートをネットワークリンクレートに下げるだけであることは、リンクの完全な使用とより高品質な符号化されたデータとをもたらし得る。しかしながら、上で述べられたように、そのような手法は、データを比較的長い時間の期間バッファにとどまらせることがある。
【0024】
[0032]本開示の態様は、ネットワーク条件に基づいて送信レート(例えば、送信機機器においてオーディオデータ及び/又はビデオデータを符号化するためのビットレート)を決定することに関する。具体的には、本技法は、ネットワークリンクレートの低下に応答して送信レートを下げることを含む。本開示の態様によれば、低減されたネットワークリンクレートを特定すると、送信機機器は、送信レートをネットワークリンクレート未満のレートへと下げることができる。幾つかの例では、受信機機器は、次いで送信機機器によって実装される、低減された送信レートを要求することができる。送信レートをネットワークリンクレート未満のレートに下げることは、ネットワークリンクレートをアンダーシュートすることとして呼ばれることがある。
【0025】
[0033]本技法はまた、低減されたレートに送信レートを維持するための時間の量を決定することを含む。幾つかの例では、本開示の態様は、以下でより詳細に説明されるように、バッファリング時間長、ネットワークリンクレートの低下の大きさ、レート低減係数及び/又は他の係数に基づいて回復レート時間長(アンダーシュート期間とも呼ばれる)を決定することを含む。このようにして、本技法は、最適なアンダーシュート期間を決定するために使用され得る。例えば、送信機機器は、ネットワークによってサポートされる増加された送信レートに戻る前に、バッファリングされたデータの量を減らすために必要とされる場合にのみ限り、低減された送信レートを維持することができる。本技法は、上で説明された保守的な手法と積極的な手法のバランスを実現することができるので、バッファリングされるデータの量は、ユーザ体験に過度に影響を与えることなく比較的速く減らされ得る。
【0026】
[0034]本開示の態様はまた、符号化されたオーディオデータ及び/又はビデオデータを処理することと関連付けられる遅延データを信号伝達することを含む。本開示の技法は、送信機機器においてバッファリング時間長を決定する際に使用するためのデータを生成することを含む。バッファリング時間長は、実際のネットワークリンクレートの低下と、ネットワークリンクレートの低下が検出される時間との間の遅延と関連付けられ得る(例えば、送信機及び/又は受信機機器がネットワークリンクレートの低下を直ちに認識してそれに応答することはないと仮定する)。この遅れ時間の間、送信機機器は通常、元の送信レートで準備/符号化されたデータをバッファリングするが、これは低減されたネットワークリンクレートではリアルタイム(又はほぼリアルタイム)で送信されることが可能ではない。データのバッファリングは、その間はデータが受信されない遅延を、受信機機器において生み出す。上で述べられたように、バッファリング時間は、送信機機器においてバッファリングされるデータの量及び/又は回復レート時間長を決定するために使用され得る。
【0027】
[0035]本開示の他の態様は、ネットワークリンクレートが完全には利用されていない事例において、送信レートを上げることに関し得る。例えば、送信機機器は、送信レートが送信機機器を受信機機器につなぐネットワークによってサポート可能なリンクレート未満であるユーザ体験事例の品質を上げるために、データの送信レートを上げることができる。データが符号化されるビットレートを上げることは、本明細書ではアップスイッチングと呼ばれ得る。しかしながら、大きすぎるインクリメントで送信レートをアップスイッチングすることは、ネットワークリンクレートのオーバーシュートをもたらすことがあり、これは、説明されたようにユーザ体験を悪くすることがある。逆に、小さすぎるインクリメントで送信レートをアップスイッチングすることは、ネットワークリンクレートのアンダーシュートの継続をもたらすことがあり、これは、ネットワークリンクレートによってサポート可能なものよりも低い品質のユーザ体験をもたらすことがある。
【0028】
[0036]本開示の態様によれば、受信機機器は、データが再生されるように予定される時間より前にデータが受信されることに基づいて、ネットワークリンクレートが十分に利用されていないと決定することができる。受信機機器は、データが受信される時間とデータが再生されるように予定される時間との間の差に基づいて許容可能超過遅延パラメータを決定することができ、受信機機器は、許容可能超過遅延パラメータに従って送信レートの増加を決定することができる。受信機機器は、幾つかの事例では、送信機機器に送信レートの増加の指示を送信することができるので、送信機機器は、ネットワークリンクレートをオーバーシュートすることなくネットワークリンクレートをより良好に利用することができる。
【0029】
[0037]従って、本開示の態様は、送信機機器から発信され、受信機機器への時間変化する帯域幅を伴うネットワークチャネル(ネットワークリンクとも呼ばれる)を通じて送信される、ビデオフローを制御するためのレート適合又は混雑制御技法を含む。具体的には、本技法は、ネットワークに混雑をもたらすことなくユーザ体験を改善するために、制御された方式でビデオフローの平均ビットレートをアップスイッチングすることを含む。そのようなレート適合技法は、パケット損失をもたらし得るエンドツーエンドの遅延の大幅な増加を避け得る。
【0030】
[0038]例えば、本開示の態様によれば、受信機機器は、受信されたビデオパケットを検査し、データがデータの予定された再生に対して早く到着しているか、時間通りに到着しているか、又は遅く到着しているかを決定することができる。データが意図される再生より遅く到着している場合、受信機機器は、ネットワークリンクレートが送信レート(例えば、送信機機器において実装される符号化レート)より低いと決定することができる。従って、受信機機器は、送信レートを下げるための要求を送信機機器に送信することができる。幾つかの例では、受信機機器は、システムがネットワークチャネルの混雑を解消することを可能にするために、ネットワークリンクレートの持続可能なレート(例えば、利用可能な帯域幅)より低い初期レートを要求することができる。
【0031】
[0039]幾つかの事例では、本明細書で説明される技法は、IPマルチメディアサブシステム(IMS:IP Multimedia Subsystem)のためのマルチメディア電話サービス(MTSI:Multimedia Telephony Service for IP Multimedia Subsystem)機器によって実行され得る。例えば、MTSI機器は、本明細書で説明される技法を使用してビットレート適合及び/又は混雑制御を実行することができる。
【0032】
[0040]
図1は、符号化及び復号システム10を示すブロック図である。
図1に示されるように、システム10は、送信チャネル16によって接続されるエンコーダシステム12とデコーダシステム14とを含む。
図1の例では、エンコーダシステム12は、第1のビデオ通信機器と関連付けられ、オーディオ発信源17と、ビデオ発信源18と、ビデオエンコーダ20と、オーディオエンコーダ22と、リアルタイムトランスポートプロトコル(RTP)/リアルタイムトランスポートプロトコル(RTCP)/ユーザデータグラムプロトコル(UDP)/インターネットプロトコル(IP)/ポイントツーポイントプロトコル(PPP)変換ユニット26と、無線リンクプロトコル(RLP)キュー28と、MACレイヤユニット30と、物理(PHY)レイヤユニット32とを含む。デコーダシステム14は、別のビデオ通信機器と関連付けられ、PHYレイヤユニット34と、MACレイヤユニット36と、RLPキュー38と、RTP/RTCP/UDP/IP/PPP変換ユニット40と、ビデオデコーダ42と、オーディオデコーダ44と、オーディオ出力機器46と、ビデオ出力機器48とを含む。
【0033】
[0041]以下でより詳細に説明されるように、エンコーダシステム12及び/又はデコーダシステム14は、ネットワーク条件に基づいて符号化レートを調整するために、本開示の技法を使用することができる。例えば、ビデオエンコーダ20は、少なくとも一部、ネットワーク帯域幅の関数として、ビデオ発信源符号化レートを制御することができる。具体的には、ビデオエンコーダ20は、ネットワークリンクレートの低下に応答して、ビデオデータ及び/又はオーディオデータの符号化レートを下げることができる。同様に、ビデオエンコーダ20は、ネットワークリンクレートの不十分な利用の指示に応答して、ビデオデータ及び/又はオーディオデータの符号化レートを上げることができる。
【0034】
[0042]システム10は、例えば、送信チャネル16を介したビデオ電話のために、双方向のビデオ及びオーディオの送信を提供することができる。従って、全般に相対応する符号化、復号及び変換ユニットが、チャネル16の反対側に設けられ得る。幾つかの実施形態では、エンコーダシステム12及びデコーダシステム14は、ビデオストリーミング、ビデオ電話又は両方に対応したワイヤレスモバイル端末などのビデオ通信機器内で具現化され得る。モバイル端末は、RTP、RTCP、UDP、IP又はPPPなどのパケット交換規格に従ってVTをサポートすることができる。
【0035】
[0043]例えば、エンコーダシステム12において、RTP/RTCP/UDP/IP/PPP変換ユニット26は、ビデオエンコーダ20及びオーディオエンコーダ22から受信されたオーディオデータ及びビデオデータに、適切なRTP/RTCP/UDP/IP/PPPヘッダデータを追加し、データをRLPキュー28に配置する。例示的なビットストリームは、MACヘッダと、IPヘッダと、UDPヘッダと、RTCPヘッダと、ペイロードデータとを含み得る。幾つかの例では、RTP/RTCPはUDPの上で動作するが、UDPはIPの上で動作し、IPはPPPの上で動作する。幾つかの例では、本明細書で説明されるように、「RFC 3550: RTP: A Transport Protocol for Real−Time Applications」、H. Schulzrinne他、2003年7月、「RFC 5104: Codec Control Messages in the RTP Audio−Visual Provide with Feedback (AVPF)」、S.Wenger他、2008年2月(以後RFC 5104)及び/又はデータのリアルタイムのトランスポート若しくはほぼリアルタイムのトランスポートのための他の適用可能な規格などの、特定の規格に適合するRTP/RTCP/UDP/IP/PPP変換ユニット26。MACレイヤユニット30は、RLPキュー28の内容からMAC RLPパケットを生成する。PHYレイヤユニット32は、チャネル16を通じた送信のために、MAC RLPパケットをPHYレイヤパケットに変換する。
[0044]デコーダシステム14のPHYレイヤユニット34及びMACレイヤユニット36は、相互に動作する。PHYレイヤユニット34は、チャネル16から受信されたPHYレイヤパケットをMAC RLPパケットに変換する。MACレイヤユニット36は、MAC RLPパケットをRLPキュー38に配置する。RTP/RTCP/UDP/IP/PPP変換ユニット40は、RLPキュー38中のデータからヘッダ情報を奪い、ビデオデコーダ42及びオーディオデコーダ44への配信のためにそれぞれ、ビデオデータとオーディオデータとを再び組み立てる。
【0036】
[0045]システム10は、符号分割多重接続(CDMA)、周波数分割多重接続(FDMA)、時分割多重接続(TDMA)又は直交周波数分割多重化(OFDM)若しくは別の適切なワイヤレス技法などの、1つ又は複数のワイヤレス通信技術をサポートするように設計され得る。上のワイヤレス通信技術は、様々な無線アクセス技術のいずれかに従って実現され得る。例えば、CDMAは、cdma2000又は広帯域CDMA(WCDMA(登録商標))規格に従って実現され得る。TDMAは、Global System for Mobile Communications(GSM(登録商標))規格に従って実現され得る。Universal Mobile Telecommunications System(UMTS)規格は、GSM又はWCDMA動作を可能にする。通常、VT用途では、システム10はhigh data rate(HDR)技術をサポートするように設計され得る。
【0037】
[0046]ビデオエンコーダ20は、MPEG−4、High Efficiency Video Coding(HEVC)又は別のビデオコード化規格などの、あるビデオ圧縮方法に従って符号化されたビデオデータを生成する。他のビデオ圧縮方法は、国際電気通信連合(ITU)H.263、ITU H.264又はMPEG−2の方法を含む。オーディオエンコーダ22は、ビデオデータに付随するオーディオデータを符号化する。ビデオ発信源18は、1つ又は複数のビデオカメラ、1つ又は複数のビデオアーカイブ又はビデオカメラとビデオアーカイブの組合せなどの、撮像装置であり得る。
【0038】
[0047]オーディオデータは、適応マルチレートナローバンド(AMR−NB:adaptive multi-rate narrow band)又は他の技法などの、オーディオ圧縮方法に従って符号化され得る。オーディオ発信源17は、マイクロフォン又は音声合成器機器などの、オーディオキャプチャ機器であり得る。VT用途では、ビデオは参加者にVT会議を見えるようにし、オーディオはその参加者の話している声を聞こえるようにする。
【0039】
[0048]動作において、RTP/RTCP/UDP/IP/PPP変換ユニット26は、ビデオエンコーダ20及びオーディオエンコーダ22からビデオデータパケットとオーディオデータパケットとを取得する。前に言及されたように、RTP/RTCP/UDP/IP/PPP変換ユニット26は、適切なヘッダ情報をオーディオパケットに追加し、得られたデータをRLPキュー28内に挿入する。同様に、RTP/RTCP/UDP/IP/PPP変換ユニット26は、適切なヘッダ情報をビデオパケットに追加し、得られたデータをRLPキュー28内に挿入する。MACレイヤユニット30は、RLPキュー28からデータを取り出し、MACレイヤパケットを形成する。各MACレイヤパケットは、RTP/RTCP/UDP/IP/PPPヘッダ情報と、RLPキュー28内に含まれるオーディオパケットデータ又はビデオパケットデータとを搬送する。オーディオパケットは、ビデオパケットとは独立にRLPキュー28に挿入され得る。
【0040】
[0049]幾つかの場合、RLPキュー28の内容から生成されるMACレイヤパケットは、ヘッダ情報とビデオパケットデータとのみを搬送する。他の場合、MACレイヤパケットは、ヘッダ情報とオーディオパケットデータとのみを搬送する。多くの場合、MACレイヤパケットは、RLPキュー28の内容に応じて、ヘッダ情報と、オーディオパケットデータと、ビデオパケットデータとを搬送する。MACレイヤパケットは、無線リンクプロトコル(RLP)に従って構成されてよく、MAC RLPパケットと呼ばれ得る。PHYレイヤユニット32は、チャネル16にわたる送信のために、MAC RLPオーディオ−ビデオパケットをPHYレイヤパケットに変換する。
【0041】
[0050]チャネル16は、PHYレイヤパケットをデコーダシステム14に搬送する。チャネル16は、エンコーダシステム12とデコーダシステム14との間の任意の物理的接続であり得る。例えば、チャネル16は、ローカルエリア又はワイドエリアの有線ネットワークなどの、有線接続であり得る。代替的に、本明細書で説明されるように、チャネル16は、セルラー接続、衛星接続又は光接続などの、ワイヤレス接続であり得る。チャネル条件は、有線チャネル及びワイヤレスチャネルの課題であり得るが、ワイヤレスチャネル16を通じて実行されるモバイルVT用途では特に関係があることがあり、ワイヤレスチャネル16においては、チャネル条件がフェージング又は混雑により悪化することがある。チャネル16は、チャネル条件に従って変動することがある、特定のネットワークリンクレート(例えば、特定の帯域幅)をサポートし得る。例えば、チャネル16は、チャネル条件に従って変化するスループットを有する逆方向リンク(RL)によって特徴付けられ得る。
【0042】
[0051]一般に、デコーダシステム14のPHYレイヤユニット34は、PHYレイヤパケットからMACレイヤパケットを特定し、内容をMAC RLPパケットへと再び組み立てる。MACレイヤユニット36は次いで、RLPキュー38内へ挿入するためのビデオパケットとオーディオパケットとを提供するために、MAC RLPパケットの内容を再び組み立てる。RTP/RTCP/UDP/IP/PPPユニット40は、付随するヘッダ情報を除去し、ビデオパケットをビデオデコーダ42に、オーディオパケットをオーディオデコーダ44に提供する。ビデオデコーダ42は、表示装置を駆動する際に使用するためのビデオデータのストリームを生成するために、ビデオデータフレームを復号する。オーディオデコーダ44は、例えばオーディオスピーカーを介してユーザに提示するためのオーディオ情報を生成するために、オーディオデータを復号する。
【0043】
[0052]上で述べられたように、システム10は、例えば送信チャネル16を介したビデオ電話のために、双方向のビデオ及びオーディオの送信を提供することができる。幾つかの例では、チャネル16のネットワークリンクレートが変化するときに問題が発生することがあり、この変化は、Wi−Fi、セルラー又は他のネットワークリンクにおいて発生し得る。以下で
図2に関してより詳細に説明されるように、レートの変動に対処し、場合によってはキューの管理を実行するために、1つ又は複数のバッファがネットワーク機器に含まれ得る。
【0044】
[0053]例えば、ある送信レート(例えば、ビデオエンコーダ20によって使用される符号化レート)を伴うVTフローは、リンクレートの突然の下落に遭遇することがあり、これはフローのボトルネックを生み得る。このリンクレートの下落に対するエンコーダシステム12における反応の遅延(例えば、これは、受信機の混雑制御フィードバックの遅延、送信機から受信機への戻り経路上での遅延、レート適合反応の遅延などによって引き起こされ得る)が原因で、送信レートはある時間の期間、リンクレートを大きく上回ったままであり得る。これは、ボトルネックリンクで増加したバッファレベルをもたらし、従って、エンコーダシステム12とデコーダシステム14との間のエンドツーエンドの遅延の増加(また更にはパケットの損失)をもたらすことがあり、これは、VTセッションの品質体験に悪影響を与えることがある。
【0045】
[0054]データがチャネル16を通じて送信される際のビットレートをエンコーダシステム12が下げた(例えば、送信レートを下げた)後で、蓄積された遅延がある時間残り得る。例えば、幾つかの事例では、蓄積された遅延が残る時間の長さは、送信レートと低減されたリンクレート(例えば、ボトルネックを引き起こすリンクレート)との間の差に依存し得る。送信レートの低下が小さすぎる場合、蓄積された遅延は比較的ゆっくり下がり、このことはデコーダシステム14におけるユーザ体験に影響を与え得る。保守的な送信レートの手法は、一貫して、推定されるリンクレートよりもはるかに低いレートで送信することである。しかしながら、この手法は、チャネル16におけるリンクの不十分な使用と、全体的なビデオ品質体験の低下とをもたらし得る。
【0046】
[0055]本開示で説明される技法によれば、ビデオエンコーダ20は、チャネル16の条件に基づいて、ビデオ発信源18からビデオを符号化することができる。具体的には、ビデオエンコーダ20は、チャネル16における帯域幅の低下に基づいて、符号化レート(本明細書では送信レートとも呼ばれる)を下げることができる。符号化レートを下げることは、本明細書ではダウンスイッチングと呼ばれ得る。エンコーダシステム12は、チャネル16におけるリンクレートの大幅な下落が検出された後で、例えば、デコーダシステム14において生成された受信機側の混雑制御フィードバックメッセージがエンコーダシステム12において受信された後で、ビデオエンコーダ20において符号化されたデータの送信レートを一時的に下げることができる。
[0056]一例では、本開示の態様によれば、エンコーダシステム12は最初に、第1のビットレートでチャネル16を通じてデータを送信することができる。エンコーダシステム12は、第1のネットワークリンクレートから第2のネットワークリンクレートへのチャネル16におけるネットワークリンクレートの低下を特定することができる。幾つかの例では、エンコーダシステム12は、デコーダシステム14から受信された1つ又は複数の報告に基づいて、ネットワークリンクレートの低下を特定することができる。
【0047】
[0057]本開示の態様によれば、ネットワークリンクレートの低下を特定したことに応答して、エンコーダシステム12は、チャネル16を通じてデータを送信する際に用いるべき回復ビットレートを決定することができ、ここで回復ビットレートは第2のネットワークリンクレートより低い。エンコーダシステム12はまた、ネットワークリンクレートの低下の特定の時間と、ネットワークリンクレートの低下の推定される実際の時間との間の差を含む、バッファリング時間長を決定することができる。例えば、上で述べられたように、遅延を特定することと、ビデオエンコーダ20がデータを符号化する際のレートを調整することとに関連付けられる、何らかの反応時間があり得る。エンコーダシステム12は、ビデオエンコーダ20が符号化レートを特定してより低いレートへと調整するための時間を有するまで、初期の(より高い)ネットワークリンクにおいて、又はその近くで、ビデオエンコーダ20によって符号化されたデータをバッファリングすることができる。
【0048】
[0058]エンコーダシステム12は、回復ビットレート及びバッファリング時間長に基づいて、回復ビットレートでデータを送信すべき回復レート時間長を決定することができる。エンコーダシステムは次いで、決定された回復レート時間長の間、回復ビットレートでデータを送信することができる。このようにして、本技法は、蓄積されたエンドツーエンドの遅延を比較的速く減らすことができ、エンドツーエンドの遅延が減らされた後で利用可能なリンクレートを使用することによって(例えば、より長い時間の期間、低減されたレートに送信レートを維持する場合よりも)、ユーザ体験の品質を守ることができる。例示を目的としてエンコーダシステム12に関して説明されたが、上で述べられた技法の幾つかは、追加で、又は代替的に、デコーダシステム14によって実行され得ることを理解されたい。
【0049】
[0059]本開示の更に他の技法は、ネットワーク条件に基づいて、データが符号化されるレートをアップスイッチングする(例えば、上げる)ための技法を含む。例えば、「Discussion on Upswitch Principals」、SA4 MTSI SWG Conference Call No. 4 on End−to−End Video Rate Adaptation of E2EMTSI−S4、S4−AHM215、2014年6月24日(「AHM215」)の発表において、アップスイッチングについての幾つかの問題が特定された。「Report from SA4 MTSI SWG Conference Call No. 4 on End−to−End Video Rate Adaptation of E2EMTSI−S4 (2014年6月24日)」、Tdoc S4 (14)0768において記載されているように、アップスイッチングの原則について合意する前に、電話会議からの新たな着想について研究するために、さらなる議論が必要であると思われた。
【0050】
[0060]一般に、AHM215において発表されたモデルは、ランプアッププロービングモデルに依存し、これには、プローブがチャネル条件に一致していないときに、プロービングがシステムに遅延をもたらし得るという欠点があり得る。よりロバストなモデルは、デコーダシステム14などの受信機が、システムに余剰の能力があり得るかどうかを決定するためにチャネル16の状態を受動的に測定することを可能にすることである。これに基づいて、デコーダシステム14は、システムの持続可能なレートのより正確な推定を行うことができる。
【0051】
[0061]AHM215において発表されたモデルはまた、2段階の手法を提案しており、この手法では、エンコーダシステム12はまず、さらなる能力があり得るかどうかを確認するためにチャネルをプローブする。プロービング段階が成功すると、ビデオエンコーダ20は、「ランプアップ段階(ramp-up phase)」の間にレートをより積極的に上げることができる。そのようなモデルは、比較的大量の混雑をシステムにもたらす可能性があり、それは、データレートの微増を伴う成功したプローブは、システムがその後非常に大幅な増加を処理できることを暗示し得ないためである。実際には、ビデオエンコーダ20のレートをシステムの能力と一致するように増加するとき、よりロバストな手法は、まずレートを比較的大きく増加して、その後、チャネル16によってサポートされる持続可能なレートへとレートが収束するにつれてよりステップを小さくすることである。
【0052】
[0062]上で説明された方式で持続可能なレートに収束する、潜在的によりロバストな手法に従うには、適合を駆動するエンティティ(例えば、送信機(エンコーダシステム12)又は受信機(デコーダシステム14))は、システムの持続可能なレートの推定値を有しなければならない。送信機は、エンドツーエンドのチャネル条件を検出するためにRTCP受信機報告に依存することがあり、全体のスループットを計算することができるが、それでも、RTCP報告によりいくらかの測定遅延がある。受信機は、全体のスループットと、予定される再生に対してデコーダシステム14におけるパケットの到着が遅すぎるとはされない、許容され得る追加の遅延の量との両方を、計算することができる。従って、受信機において計算される関連する尺度が送信機に直接送信される場合、受信機により駆動される適合モデルは、実現され、よりロバストであることがあり、最小限の適合の実行を決定する際に使用されるべきである。
【0053】
[0063]本開示の態様によれば、デコーダシステム14は、チャネル16において帯域幅が十分に利用されていないと決定すると、受信機により駆動されるレートアップスイッチング技法を実施することができる。例えば、本開示の態様によれば、デコーダシステム14は、ビデオエンコーダ20に符号化レートを上げるように促すデータをエンコーダシステム12に提供することができる。
【0054】
[0064]幾つかの例では、本開示の態様によれば、デコーダシステム14は、データがデコーダシステム14によって受信される時間と受信されたデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータを決定することができる。許容可能超過遅延パラメータは、ユーザ体験が影響を受けない、例えば、適切な時間に復号され、再生されるのにデータの到着が遅すぎない、チャネル16によって対応可能な遅延の量を示すことができる。デコーダシステム14はまた、決定された許容可能超過遅延パラメータに基づいて、データがエンコーダシステム12からデコーダシステム14に送信される際に用いるべきビットレートを増加するための、送信機ビットレートの増加を決定することができる。デコーダシステム14はまた、送信機ビットレートの増加の指示をエンコーダシステム12に送信することができる。
【0055】
[0065]このように、デコーダシステム14は、ネットワークに混雑をもたらすことなくユーザ体験を改善するために、制御された方式でビデオフローの平均ビットレートを制御することができる。この技法は、パケット損失をもたらし得るエンドツーエンドの遅延を大きく増加することを避け得る。
【0056】
[0066]
図2は、本開示の技法によるビデオ発信源レート適合を実施し得るエンコーダシステム12を示すブロック図である。
図2に示されるように、ビデオエンコーダ20は、ビデオ符号化エンジン50と、ビデオバッファ52と、ビデオレートコントローラ54とを含む。ビデオエンコーダ20はまた、ネットワークリンクレート情報56を受信し、これはデコーダシステム14によって準備され得る(以下でより詳細に説明される)。
【0057】
[0067]ビデオ符号化エンジン50は、ビデオ発信源18からビデオデータを取得し、ビデオレートコントローラ54によって制御されるレートでビデオデータを符号化する。ビデオ符号化エンジン50は次いで、符号化されたビデオをビデオバッファ52に収納する。ビデオレートコントローラ54は、ビデオバッファ52の充満度を監視し、充満度に少なくとも一部基づいて、ビデオ符号化エンジン50によって適用されるビデオ符号化レートを制御することができる。加えて、以下でより詳細に説明されるように、ビデオレートコントローラ54は、ネットワークリンクレート情報56及び/又はチャネル16(
図1)の条件と関連付けられる他のデータに基づいて、レートを制御することができる。
【0058】
[0068]幾つかの例では、ビデオエンコーダ20は、全般にコーデックとは独立なビデオ発信源レート制御方式を提供することができる。例えば、ビデオエンコーダ20は、HEVC、MPEG4、ITU H.263、又はITU H.264に従って、ビデオ符号化のために適合され得る。加えて、ビデオエンコーダ20は、DSP又は組込み型論理コア内での実装の影響を受けやすいことがある。幾つかの実施形態では、ビデオエンコーダ20(例えば、ビデオエンコーダ20のビデオレートコントローラ54)は、モデルベースのレート制御を適用することができ、例えば、ビデオブロックレート制御をrho領域において適用することができる。例えば、フレームビット計画が特定のビデオフレームに対して確立されると、フレームビット計画は、フレーム内のビデオブロック、例えばコーディングユニット(CU)及び/又はマクロブロック(MB)の間で、rho領域レート制御を使用して割り振られ得る。個々のMBのためのrho領域値は次いで、量子化パラメータ(QP)値にマッピングされ得る。
【0059】
[0069]本開示の態様によれば、ビデオレートコントローラ54は、ネットワーク条件に基づいてレートダウンスイッチングを実行することができる。例えば、ビデオ符号化エンジン50は最初に、チャネル16(
図1)などのトランスポート媒体を通じた送信のために、第1のビットレートでデータを符号化することができる。ビデオレートコントローラ54は、第1のネットワークリンクレートから第2のネットワークリンクレートへのネットワークリンクレートの低下を特定することができる。幾つかの例では、ビデオレートコントローラ54は、ビデオエンコーダ20において、ネットワークリンクレートの低下をフィードバックから特定することができる。他の例では、ビデオレートコントローラ54は、ネットワークリンクレート情報56に基づいて、ネットワークリンクレートの低下を特定することができる。
【0060】
[0070]ネットワークリンクレートの低下を特定したことに応答して、ビデオレートコントローラ54は、第2の(低減された)ネットワークリンクレートより低い、ビデオエンコーダ20のための回復ビットレートを決定することができる。回復レートは、ネットワークリンクレートの低下の実際の時間とネットワークリンクレートの低下の同定との間にバッファリングされたデータ量を減らすために使用され得る。そのようなバッファリングされたデータを減らすことは、ユーザ体験が受信機機器において影響を受けないように支援する。従って、ビデオレートコントローラ54は、ビデオエンコーダ20においてバッファリングされたデータの量を少なくするために低減されたネットワークリンクレートをアンダーシュートする、ビデオエンコーダ20において使用するための回復ビットレートを決定することができる。
【0061】
[0071]本開示の態様によれば、ビデオレートコントローラ54は、アンダーシュート係数に基づいて回復レートを決定することができる。ビデオレートコントローラ54は、第1のネットワークリンクレートと低減されたネットワークリンクレートとの間の差に基づいてアンダーシュート係数を決定することができる。即ち、ビデオレートコントローラ54は、ネットワークリンクレートの低下の大きさに基づいて変化する大きさを有する、アンダーシュート係数を決定することができる。従って、ネットワークリンクレートの低下が比較的大きい場合、ビデオレートコントローラ54は、比較的大きいアンダーシュート係数を決定し得る。同様に、ネットワークリンクレートの低下が比較的小さい場合、ビデオレートコントローラ54は、比較的小さいアンダーシュート係数を決定し得る。
【0062】
[0072]幾つかの例では、ビデオレートコントローラ54は、回復レートを決定するために低減されたネットワークリンクレートに適用され得るアンダーシュート係数を決定することができる。例えば、ビデオレートコントローラ54は、小数のアンダーシュート係数を決定することができ、小数のアンダーシュート係数を低減されたネットワークリンクレートに適用して回復レートを決定することができる。一例では、ビデオレートコントローラ54は、ネットワークリンクレートの低下の大きさの、第1のネットワークリンクレートに対する比に基づいてアンダーシュート係数を決定することができる。
【0063】
[0073]本開示の態様によれば、ビデオレートコントローラ54は、ネットワークリンクレートの低下の特定の時間とネットワークリンクレートの低下の推定される実際の時間との間で、どれだけのデータがビデオエンコーダ20においてバッファリングされるか(又は、より一般的には、ビデオエンコーダ20を含む送信機機器においてどれだけのデータがバッファリングされるか)に基づいて、回復レートをどれだけ長く維持するかを決定することができる。送信機機器においてデータをバッファリングすることと関連付けられる時間は、バッファリング時間長(又はバッファリング時間期間)と本明細書では呼ばれ得るが、回復レートを維持すべき時間長は、回復レート時間長(又は低減レート時間期間)と本明細書では呼ばれ得る。幾つかの事例では、回復レート時間長はまた、アンダーシュート時間長又は期間と呼ばれることがあり、それは、回復レート時間長の間にデータが符号化されるレートがネットワークリンクレートより低いからである。
【0064】
[0074]以下で
図5に関してより詳細に説明されるように、ビデオレートコントローラ54は、様々な方法でバッファリング時間長を決定することができる。例えば、ビデオレートコントローラ54は、ビデオエンコーダ20を組み込む送信機機器と受信機機器との間のラウンドトリップ時間(RTT)、ダウンリンク遅延(例えば、受信機から送信機への遅延)、レート適合反応の遅延に関するデータ、混雑制御の反応遅延(例えば、リンクレートの推定)、メッセージ生成遅延(RTCPパケット)などの、ネットワークリンクレート情報56からバッファリング時間長を推定することによって、バッファリング時間長を決定することができる。ネットワークリンクレート情報56は、ビデオエンコーダ20において利用可能であることがあり、又は受信機機器によってビデオエンコーダ20に信号伝達され得る。
【0065】
[0075]本開示の態様によれば、ビデオレートコントローラ54は、回復レートの大きさに基づいて、及びバッファリング時間長に基づいて、回復レート時間長を決定することができる。幾つかの例では、ビデオレートコントローラ54は、(例えば、回復レートによって示されるような)ネットワークリンクレートの低下の大きさと、(例えば、バッファリング時間長によって示されるような)ネットワークリンクレートの低下に反応することと関連付けられる時間の量とに比例する、バッファリング時間長を決定することができる。即ち、ネットワークリンクレートの低下が比較的大きい場合、及び/又は、ネットワークリンクレートの低下に反応するのに必要な時間が比較的長い場合、ビデオレートコントローラ54は、それに比例して長い回復レート時間長を決定することができる。同様に、ネットワークリンクレートの低下が比較的小さい場合、及び/又は、ネットワークリンクレートの低下に反応するのに必要な時間が比較的短い場合、ビデオレートコントローラ54は、それに比例して短い回復レート時間長を決定することができる。
【0066】
[0076]本開示の他の態様によれば、ビデオレートコントローラ54は、加えて、又は代替的に、ネットワーク条件に基づいてレートのアップスイッチングを実行することができる。例えば、ビデオレートコントローラ54は、デコーダシステム14(
図1)を含む機器などの受信機機器からネットワークリンクレート情報56を受信することができる。ビデオレートコントローラ54は、データを符号化するためにビデオ符号化エンジン50によって使用されている送信レート(例えば、符号化レート)をアップスイッチングするために、受信されたネットワークリンクレート情報56を使用することができる。
【0067】
[0077]幾つかの例では、受信されたネットワークリンクレート情報56は、ビデオ符号化エンジン50によって実施されている特定の要求された送信レート(例えば、符号化レート)を含み得る。他の例では、受信されたネットワークリンクレート情報56は、現在の送信レート(例えば、送信レートステップ)に追加されるべき、レートステップの増加を含み得る。いずれの場合でも、
図3に関して以下でより詳細に説明されるように、受信されたネットワークリンクレート情報56は、パケットが再生されるように予定される前に受信機機器においてパケットが受信されたことを示す超過遅延パラメータに基づき得る。そのような事例において、ビデオレートコントローラ54は、パケットの到着時間が受信機機器におけるパケットの予定された再生時間とより厳密に一致するまで、ビデオ符号化エンジン50によって使用される送信レートを上げることができる。
【0068】
[0078]
図2の技法は
図2の特定のコンポーネント(例えば、ビデオレートコントローラ54など)によって行われるものとして説明されるが、そのような技法は、追加で、又は代替的に、ビデオ電話機器の1つ又は複数の他のコンポーネントによって実行され得ることを理解されたい。例として、MTSI機器は、レート適合及び/又は混雑制御を実行するために、上で説明された幾つかの技法を行うことができる。この例では、MTSI機器は次いで、ビデオエンコーダにおいて適切なレート制御を実施するためにデータをビデオレートコントローラ54に提供することができる。
【0069】
[0079]
図3は、本開示の技法によるビデオ発信源レート適合を実施し得るビデオデコーダシステム14を示すブロック図である。
図3に示されるように、ビデオデコーダ42は、符号化されたデータとネットワークリンクレート情報60とを受信し、ビデオ復号エンジン62と、再生決定ユニット64と、レート制御データ68を生成するレート制御ユニット66とを含む。
【0070】
[0080]ビデオ復号エンジン62は、符号化されたデータとネットワークリンクレート情報60とを受信し、ビデオデータを復号する。幾つかの例では、ビデオ復号エンジン62は、1つ又は複数のビデオコード化規格に適合し得る。上で述べられたように、例示的なビデオコード化規格は、HEVC、MPEG4、ITU H.263、又はITU H.264を含む。
【0071】
[0081]ビデオデータが受信されるレートは、ビデオエンコーダ20(
図2)のビデオレートコントローラ54によって制御され得る。本開示の態様によれば、レート制御ユニット66は、符号化レートを調整する際に使用するためのレート制御データ68を準備して、ビデオエンコーダ20に送信することができる。幾つかの例では、レート制御データ68は、送信機機器においてダウンスイッチングを実行するためのデータを含み得る。他の例では、加えて、又は代替的に、レート制御データ68は、送信機機器においてアップスイッチングを実行するためのデータを含み得る。レート制御ユニット66は、送信機機器が適切なビットレートを決定することを可能にするデータを準備することができ、又は、送信機機器から特定のビットレートを要求することができる。
【0072】
[0082]ダウンスイッチングのためのデータを準備することに関して、本開示の態様によれば、レート制御ユニット66は、
図2に関して上で説明されたのと同様の方式で、回復レート、バッファリング時間長及び/又は回復レート時間長を決定することができる。他の例では、レート制御ユニット66は、回復レート、バッファリング時間長及び/又は回復レート時間長を決定するために送信機機器(エンコーダシステム12など)によって使用され得る、データを生成し、及び/又はメッセージを送信することができる。
【0073】
[0083]一例では、レート制御ユニット66は、ネットワークリンクレートの低下を示すために、順方向チャネルの推定される最大ビットレートを伴う、送信機機器へのRTCP一時最大メディアストリームビットレート要求(TMMBR:Temporary Maximum Media Stream Bit Rate Request)メッセージを生成することができる。一般に、上で述べられたRFC5104に記載されるように、受信機、変換器又は混合器は、メディアストリームの最大ビットレートを与えられた値に、又はそれ未満に制限するように送信機に要求するために、TMMBR(「timber」と呼ばれる)を使用することができる。一時最大メディアストリームビットレート通知(TMMBN)は、メディア送信機を更に制約しないであろうTMMBRを参加者が抑制するのを助けるためにメディア送信機が受信した、TMMBRで定義された制限の最も限定的なサブセットの、メディア送信機の現在の見方を含んでいる。
【0074】
[0084]本開示の態様によれば、第1のレートから第2のより低いレートへの順方向チャネルの推定される最大ビットレートの変化は、ネットワークリンクレートの低下を示す。幾つかの例では、レート制御ユニット66は、混雑が検出されると直ちに、又はほぼ直ちに、TMMBRを送信することができる(例えば、TMMBRメッセージを生成することと関連付けられるメッセージ生成遅延があり得る)。TMMBRメッセージが例示を目的に説明されるが、遅延/混雑を示す様々な他のメッセージが使用され得ることを理解されたい。
【0075】
[0085]本明細書で説明されるバッファリング時間長を推定することで送信機機器を支援するために、レート制御ユニット66は、RTCP受信機報告(RR:receiver report)メッセージを生成して送信することもできる。例えば、上で述べられたRFC3550において記載されるように、幾つかのRTCPパケットのタイプが、様々な制御情報を搬送するために使用され得る。送信機報告(SR:sender report)が、動作している送信機である参加者からの送信と受信の統計のために使用され得る。RRは、動作している送信機ではない参加者からの受信統計のために、及び、32個以上の発信源についての動作している送信機の報告のためのSRと組み合わせて、使用され得る。
【0076】
[0086]本開示の態様によれば、レート制御ユニット66は、TMMBRメッセージの後で、例えばTMMBRメッセージの直後に、又はほぼ直後に、RRメッセージを生成して送信することができる。この例では、送信機機器は、TMMBRメッセージとRRメッセージとを受信することができ、RRに含まれる最後のSRのタイムスタンプ(LSRデータ)によってRRにおいて参照されるSRの送信の時間と、送信機機器によってRRが受信される時間との時間差として、バッファリング時間長の上限を決定することができる。言い換えると、レート制御ユニット66は、ビットレート制限のための要求を示す第1のデータ(例えば、TMMBRメッセージ)と、メッセージが生成された時間を示す第2のデータ(例えば、LSRデータ)とを送信することができる。LSRデータは、発信源から最新のRTCP SRパケットの一部として受信された、64ビットのネットワーク時間プロトコル(NTP)タイムスタンプのうちの中間の32ビットを含み得る。SRがまだ受信されていない場合、LSRタイムスタンプフィールドは0に設定され得る。送信機機器は、上で述べられたデータを受信することができ、そのデータを使用してバッファリング時間長を決定することができ、バッファリング時間長はダウンスイッチングの間に使用され得る。
【0077】
[0087]別の例では、2つの別の連続するメッセージ(例えば、TMMBR及びRTCP RR)を送信するのではなく、レート制御ユニット66は、TMMBRデータとRTCP RRデータとを単一のRTCPメッセージへとグループ化することができ、単一のメッセージを送信機機器に送信することができる。最低でも、レート制御ユニット66はLSRデータを送信することができ、これは送信機機器がバッファリング時間長を推定することを可能にする。この例では、2つの別のメッセージを送信する場合よりも、メッセージサイズが減らされ得る。
【0078】
[0088]幾つかの例では、レート制御ユニット66は、送信機機器に送信すべき最後の受信されたRTCP SRのLSRを、同じLSRを有するRTCP RRを以前に送信していたとしても、使用することができる。レート制御ユニット66がRRをまだ送信していない場合、レート制御ユニット66は、完全なRRをTMMBRと組み合わせることができる。他の例では、メッセージサイズを減らすために、レート制御ユニット66は、LSRデータをTMMBRと一緒に送信することだけが可能であり、送信機機器は、RTTを決定するためにTMMBRを受信して使用することができる。更に別の例では、レート制御ユニット66がすでにRRを送信していた場合、送信機機器は、最後の受信されたRRを受信した時間と新たなRR(例えば、混雑が検出された後でレート制御ユニット66によって送信されたRR)を受信した時間との間の時間差として、バッファリング時間長をより正確に計算することができる。
【0079】
[0089]レート制御ユニット66はまた、回復レート時間長を決定し、及び/又は、回復レート時間長を決定するためにデータを生成して送信機機器に送信することができる。例えば、上で説明された技法の代わりに、又はそれに加えて、レート制御ユニット66(又は送信機機器)は、回復レート時間長をいつ終了すべきか決定するために、RTCP RR到着間ジッタ(inter-arrival jitter data)を監視することができる。一般に、到着間ジッタデータは、タイムスタンプ単位で測定され、符号なしの整数として表される、RTPデータパケットの到着間の時間の統計的な分散の推定を与え得る。到着間ジッタJは、パケットのペアのための送信機と比較された、受信機におけるパケット間隔の差分Dの標準偏差(平滑化された絶対値)として定義され得る。下の式(1)に示されるように、これは、2つのパケットの「相対送信時間」の差分と等価であり、相対送信時間は、パケットのRTPタイムスタンプと、同じ単位で測定された到着の時間における受信機の時計との間の差分である。SiがパケットiからのRTPタイムスタンプであり、Riがパケットiに対するRTPタイムスタンプ単位の到着の時間である場合、2つのパケットi及びjに対して、Dは次のように表され得る。
【0080】
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) (1)
[0090]本開示の態様によれば、到着間ジッタが0又は閾値未満になる場合、送信機機器は、レート低減を終了することができる(例えば、送信機機器は、低減されたレートからほぼネットワークリンクレートへと送信レートを上げることができる)。閾値は、定数であってよく、又はネットワーク条件の変化に適応してよい。幾つかの例では、送信機機器は、到着間ジッタが最小の時間の期間の間0又は閾値未満に維持されると、レート低減を終了することができる。幾つかの事例では、レート制御ユニット66がRTCP SRとRRとを頻繁に信号伝達するほど、送信機機器は到着間ジッタをより正確に監視することができる。
【0081】
[0091]更に別の例では、送信機機器(エンコーダシステム12など)は遅延(例えば、RTT)を監視することができ、送信機は、遅延が十分に低減されるまで、送信レートを低減されたレートに維持することができる。例えば、送信機機器は、バッファに記憶されているデータの量が閾値レベルを下回るまで、送信レートを低減されたレートに維持することができる。
【0082】
[0092]本開示の他の技法によれば、再生決定ユニット64は、受信されたビデオパケットを検査し、受信されたデータが予定された再生に対して早く到着しているか、時間通りに到着しているか、又は遅く到着しているかを決定することができる。予定された再生タイミングは、符号化されたデータを用いて示され得る。パケットが遅く到着している場合(例えば、パケットが受信/検査されるより前に再生時間がある場合)、レート制御ユニット66は、送信ビットレートを下げるように送信機機器に要求することができる。幾つかの例では、レート制御ユニット66は、選択されたレートを用いてTMMBRメッセージを送信することができる。
【0083】
[0093]幾つかの態様によれば、レート制御ユニット66は、除去される必要のある超過遅延の量を決定し、レート制御ユニット66によって測定されるような到着したビデオのデータレートとこの超過遅延パラメータを乗算することによって、残りのデータ(例えば、送信機機器においてバッファリングされたデータ)の量を推定することができる。言い換えると、レート制御ユニット66は、データが受信/検査される時間とデータを用いて示される再生時間との間の差に基づいて、遅延を決定することができる。レート制御ユニット66は次いで、データが受信されているビットレートとこの遅延時間を乗算して、送信機によってバッファリングされているデータの量を決定することができる。
【0084】
[0094]幾つかの例では、レート制御ユニット66は、システムがチャネルの混雑を解消することを可能にするために、ビデオデコーダ42と送信機機器との間のトランスポート経路の持続可能なレート(例えば、ネットワークリンクの使用可能な帯域幅)より低い初期レートを(例えば、TMMBRメッセージにおいて)要求することができる。ある例では、レート制御ユニット66は、システムが(変数T_decongestによって示される)固定された量の時間でチャネルの混雑を解消することを可能にするのに十分低い初期レートを選択することができる。変数R_sustainがチャネルの持続可能なレートに等しい場合、変数ΔDelayは除去される必要のある遅延の量に等しく、そして、レート制御ユニット66は最初に、以下の式(2)に従ってビットレートRでデータを符号化するように送信機機器に要求することができる。
【0085】
R = R_sustain (1- ΔDelay/T_decongest) (2)
要求されたビットレートを含むメッセージ(例えば、TMMBRメッセージ)を送信した後で、レート制御ユニット66は、混雑解消時間(T_decongest)が経過するのを待つことができる。レート制御ユニット66は次いで、ネットワークリンクによって持続可能なレート(R_sustain)で、別の要求されたビットレート(例えば、追加のTMMBRメッセージ)を送信することができ、こうして、混雑解消期間を終了する。
【0086】
[0095]別の例では、レート制御ユニット66、レートを上げるために別のメッセージ(例えば、追加のTMMBRメッセージ)を送信しなくてよい。この例では、レート制御ユニット66は、許容可能な遅延の量(例えば、所定の閾値より少ない遅延)を測定するのを単に開始することができる。遅延の量が必要とされるよりも小さい(例えば、適切に予定された再生のために必要とされるよりも早くパケットが到着している)とレート制御ユニット66が決定する場合、レート制御ユニット66は、送信機機器の符号化レートを増加する(increase)/上昇する(ramp up)するために、別のメッセージ(例えば、別のTMMBRメッセージ)を送信することができる。
【0087】
[0096]アップスイッチングに関して、送信機機器と受信機機器との間のチャネル(エンコーダシステム12とデコーダシステム14との間のチャネル16(
図1)など)が送信機機器によって十分に利用されていないとき、ビデオデコーダ42へのビデオパケットの配信は、そのようなビデオパケットが実際に再生される(例えば、データを用いて示される再生時間の前に受信される)ことが必要になる前に発生する可能性が高い。そのような事例では、送信機レートは増加されてよく、幾つかの追加の遅延が、ユーザ体験に悪影響を与えることなくシステムにもたらされ得る。
【0088】
[0097]送信経路にもたらされ得る超過ビットは、チャネル帯域幅がレート制御ユニット66において測定される平均受信レートに等しい事例(例えば、利用可能な予備のチャネル帯域幅がない最悪の場合)では、以下の式(3)に従って計算され得る。
【0089】
excess_bits = rate_increase_step * (RTT + receiver_detection_delay) (3)
ここで、excess_bitsはシステムにもたらされる追加のビットを示し、rate_increase_stepは符号化レートの増加を示し、RTTはラウンドトリップ時間を示し、receiver_detection_delayは受信機によってシステムの遅延を検出することと関連付けられる遅延を示す(これは、本明細書で説明される技法のいずれかに従って決定され得る)。
【0090】
[0098]幾つかの例では、レート制御ユニット66は、以下の式(4)に従って、もたらされた超過ビット(excess_bits)が原因の対応する最悪の場合の超過遅延(excess_delay)を決定することができる。
【0091】
excess_delay = rate_increase_step * (RTT + receiver_detection_delay) / avg_receiving_rate
(4)
ここで、excess_delayは送信機機器においてもたらされる遅延の量を示し、rate_increase_stepは符号化レートの増加を示し、RTTは送信機機器とビデオデコーダ42との間のラウンドトリップ時間を示し、receiver_detection_delayはレート制御ユニット66によってシステムの遅延を検出することと関連付けられる遅延を示し、avg_receiving_rateはデータがビデオデコーダ42において受信されているレートを示す。
【0092】
[0099]従って、幾つかの例では、本開示の態様によれば、ビデオデコーダ42のレート制御ユニット66は、特定のレート増加と関連付けられる超過ビットの数(例えば、excess_bits)と、超過ビットの混入と関連付けられる遅延(例えば、excess_delay)とを決定することができる。
【0093】
[0100]レート制御ユニット66は、許容可能超過遅延パラメータに基づいて、レート増加の量を計算することができる。例えば、レート制御ユニット66は、下の式(5)に従って、混雑及び/又は遅延をシステムにもたらすことなく送信レートがどれだけ送信機機器によって上げられ得るかを決定することができる。
【0094】
rate_increase_step = allowable_excess_delay * avg_receiving_rate / (RTT +
receiver_detection_delay) (5)
ここで、rate_increase_stepは送信レートが増加され得る量(送信機ビットレートの増加と呼ばれ得る)を示し、allowable_excess_delayは許容可能超過遅延パラメータ(以下でより詳細に説明されるような)を示し、avg_receiving_rateはレート増加を決定する前にデータが受信されていた平均レートを示し、RTTはビデオデコーダ42と送信機機器(ビデオエンコーダ20など)との間のラウンドトリップ時間を示し、receiver_detection_delayはビデオデコーダ42において遅延を特定するために必要とされる時間の量を示す。幾つかの事例では、受信機検出遅延パラメータは、処理系依存(implementation dependent)であり得て、オフラインの試験において推定又は測定され得る。そのような受信機検出遅延が利用可能ではない場合、レート制御ユニット66は、推定される反応遅延を使用するように構成されてよく、これは、レート制御ユニット66が遅延を特定するために必要とされる時間の比較的保守的な推定であり得る。
【0095】
[0101]送信機機器からビデオデコーダ42を含む受信機機器への片道の遅延は一般に受信機機器には知られていないので、受信機機器は通常、許容可能超過遅延パラメータ(allowable_excess_delay)を計算するためにこれを使用することができない。代わりに、本開示の態様によれば、レート制御ユニット66は、受信されたビデオパケットから許容可能な超過遅延の量を決定することができる。例えば、レート制御ユニット66は、ビデオパケットがビデオデコーダ42において受信及び/又は処理される時間を決定することができる。レート制御ユニット66はまた、ビデオパケットと関連付けられるビデオデータが再生される(例えば、ユーザに表示される)ように設計される時間を決定することができる。レート制御ユニット66は、パケットが受信及び/又は評価される時間と再生時間)との間の差に基づいて、許容可能超過遅延パラメータを決定することができる。
【0096】
[0102]許容可能超過遅延パラメータは一般に、ユーザ体験に影響を与えることなくビットレートを増加するための基礎として、送信機機器によって利用され得る時間の量を示し得る。例えば、許容可能超過遅延パラメータは、ユーザ体験に影響を与えることなく、例えば、適切な時間に復号され、再生されるにはビデオデコーダ42におけるデータの到着が遅くなりすぎるような、チャネル16によってサポート可能ではないレートに送信レートを増加することなく、送信レートを増加するために使用され得る時間の量を示し得る。許容可能な超過遅延の尺度は、ユーザ体験の観点からはより正確であることがあり、それは、許容可能超過遅延パラメータは、受信されたパケット中のビデオ情報が劣化(例えば、ジッタ、スタッタリング、又はフレーム損失など)を伴わずに実際にユーザに表示され得るかどうかを直接示すからである。
【0097】
[0103]本開示の態様によれば、上の分析に基づいて、レート制御ユニット66は、アップスイッチングを実行するために、受信機機器及び送信機機器において以下の要件を課し得る。
・受信機は、パケットの到着を検査し、これを通常の予定された再生時間と比較して、送信経路にもたらされ得る許容可能な遅延の量:allowable_excess_delayがあるかどうかを決定するものとする。
・受信機は、平均受信レート:avg_receiving_rateを計算するために、パケットの到着を検査するものとする。
・受信機は、ラウンドトリップ時間:RTTを計算するものとする。
・受信機は、以下のようにrate_increase_stepを計算するものとする。
【0098】
rate_increase_step = allowable_excess_delay * avg_receiving_rate / (RTT + receiver_detection_delay)
・Audio Visual Provide with Feedback(AVPF)RTCP送信規則によって許容されるとき、受信機は、
rate_increase_step>5%×avg_receiving_rateであることを検出するとき、一時最大メディアストリームビットレート要求(TMMBR)を送信すべきであり、
rate_increase_step>15%×avg_receiving_rateであることを検出するとき、TMMBRを送信するものとする。
・TMMBRメッセージを送信するとき、TMMBR中のrequested_rateは、
avg_receiving_rate + rate_increase_step
に等しくなければならず、
avg_receiving_rate + 0.80(rate_increase_step) <= requested_rate <=
avg_receiving_rate + rate_increase_step
であるものとする。
【0099】
[0104]加えて、本開示の態様によれば、以下の要件が、アップスイッチングを実行するために送信機機器において課され得る。
・一時最大メディアストリームビットレート要求(TMMBR)を受信すると、ビデオ送信機は、送信レートを500ms以内にrequested_rateにランプアップすべきであり、1秒以内にそれをランプアップするものとする。
【0100】
[0105]上で述べられた「要件」は例示を目的に与えられており、本開示の技法は上で述べられた特定の値とは異なる値を使用しても適用され得ることを理解されたい。加えて、特定の技法が例示を目的に
図3の特定のユニット(例えば、レート制御ユニット66など)に帰せられているが、ビデオデコーダ42の1つ又は複数の他のユニットがそのような技法を行うことを担い得ることを理解されたい。その上、VTは双方向の通信フローであることが多いので、同様の技法は、順方向ネットワーク経路と逆方向ネットワーク経路の両方で、例えば、送信機機器(
図2のビデオエンコーダ20を組み込む機器など)として本明細書で指定される機器と、受信機機器(
図3のビデオデコーダ42を組み込む機器など)として本明細書で指定される機器の両方によって、適用され得る。
【0101】
[0106]
図4A及び
図4Bは、本開示によるビデオ発信源レート適合技法を示すグラフである。例えば、
図4Aは全般に、ネットワークリンクレートの低下を含む時間の間の、送信機機器(例えば、エンコーダシステム12など)における符号化されたデータのビットレートを示す。
図4Bは全般に、ネットワークリンクレートの低下と関連付けられる、結果として生じる遅延を示す。
図4A及び
図4Bの技法はエンコーダシステム12に関して説明されるが、本技法は様々な他のコンポーネントを有する様々な他の送信機機器によって行われ得ることを理解されたい。
【0102】
[0107]
図4Aの例では、時刻t
0において、リンクレート(ネットワークリンクレート又は帯域幅とも呼ばれる)は、線80によって示されるようにR
0からR
1へと低下し、ここで送信レート=リンクレートである)。ネットワークリンクレートの低下に応答して、エンコーダシステム12は送信レートを下げることができる。しかしながら、
図4Aの例に示されるように、破線82によって示されるような、送信レートを下げることと関連付けられるt
0からt
1への応答遅延(ΔT)がある。応答遅延はバッファリング時間長としても本明細書では説明されることがあり、その時間の間、送信レートはネットワークリンクレートをオーバーシュートし、エンコーダシステム12はネットワークリンクによって対処され得ないデータをバッファリングすることを担う。
【0103】
[0108]
図4Bの例において線84によって示されるように、遅延(例えば、符号化されたデータが送信可能になることと、符号化されたデータが実際に送信される時間との間の時間)は、応答遅延(ΔT)の間にD
0からD
1へと相対的に速く増大する。即ち、遅延は、ネットワークリンクレートの低下の時間t
0と、ネットワークリンクレートの低下の特定の時間t
1との間に、D
0からD
1へと相対的に速く増大する。この遅延は、エンコーダシステム12においてバッファリングされるデータの量に比例し得る。
【0104】
[0109]時間t
1において、
図4A及び
図4Bの例は、送信レート技法を分岐させることを示す。例えば、実線80は、エンコーダシステム12が送信レートをネットワークリンクレートに維持する第1の例を示す。例えば、ネットワークリンクレートの低下を特定すると、エンコーダシステム12は、送信レートを元のレートR
0から新たな低減されたネットワークリンクレートR
1に下げる。この例では、対応する遅延は、実線88によって示されるように比較的大きいままである。即ち、送信レートがネットワークリンクレートR
1に設定されるので、バッファリングされたデータの量を減らすために用いる超過の帯域幅はない。
【0105】
[0110]破線82及び86は、エンコーダシステム12が、元のレートR
0から、ネットワークリンクレートR
1より低い低減されたレートR
Uに送信を減らす、第2の例を示す。これは、ネットワークリンクレートを「アンダーシュートすること」として呼ばれ得る。この例では、エンコーダシステム12は、決定された回復レート時間長(ΔT
u)の間、低減されたレートR
uを維持することができる。この時間の間、破線90によって示されるように、エンコーダシステム12は、時間t
2においてD
1からD
2に遅延を減らす。
【0106】
[0111]本明細書で説明されるように、エンコーダシステム12は、低減されたレート(RU)と、バッファリング時間長(ΔT)と、回復レート時間長(ΔT
u)とを、様々な技法を使用して決定することができる。一例では、エンコーダシステム12は、式(1−f
U)×R
1に基づいて低減されたレートR
Uを決定することができ、ここで、f
Uはアンダーシュート係数であり、R
1は低減されたリンクレートであり、f
Uはレートアンダーシュート係数(1−f
U)を決定し、0<f
U<1であり、レートアンダーシュート係数は送信レートをリンクレートR
1に関連付ける。幾つかの例では、f
Uは、ネットワークリンクレートの低下の大きさに依存することがあり、これは、式ΔR=(R
0−R
1)によって表され得る。この例では、
図4Aに示されるように、R
0は下げられる前の第1のネットワークリンクレートである。ネットワークリンクレートの低下の大きさΔRが大きい場合、f
Uは比例して大きくなり得る。他の例では、ΔRが小さい場合、以下の式(6)において示されるように、f
Uは比例して小さくなり得る。
【0107】
f
U = ΔR / R
0 (6)
[0112]エンコーダシステム12がバッファリング時間長(ΔT)の間にビットのすべてをバッファリングし、遅延に寄与している場合、エンコーダシステム12は、以下の式(7)に基づいて回復レート時間長(ΔT
u)を決定することができる。
【0108】
ΔT
u = ΔT (R
0-R
1) / (f
U R
1) (7)
ここで、ΔT
uは回復レート時間長であり、ΔTはバッファリング時間長を備え、R
0は第1のネットワークリンクレートを備え、R
1は第2の低減されたネットワークリンクレートを備え、f
Uはレート低減係数を備える。
【0109】
[0113]幾つかの例では、エンコーダシステム12は最小限のビットレート要件を適用することができる。最小限のビットレート要件は、ビデオエンコーダ20の能力、ユーザ体験のための最小限のシステム要件などに基づき得る。エンコーダシステム12が最小限のビットレート要件を適用する例では、ビデオエンコーダ20は、最小限のビットレート要件をR
Uに、従って、アンダーシュート係数f
Uにも適用することができる。例えば、エンコーダシステム12は、低減されたレートR
Uとアンダーシュート係数f
Uとを決定するために、以下の式(8)と(9)とを適用することができる。
【0110】
R
U >= R
min (8)
f
U <= 1-(R
min/R
1) with R
1 > R
min (9)
ここで、R
Uは低減されたビットレートであり、R
minは最小の符号化レートであり、R
1は第2の低減されたネットワークリンクレートであり、f
Uはアンダーシュート係数である。
【0111】
[0114]回復レート時間長(ΔT
u)の間、新たなレート値R
2を搬送するTMMBRメッセージがエンコーダシステム12によって受信され、R
2はR
1よりはるかに大きく(例えば、R
2はR
1に1.2を乗じたもの以上である)、エンコーダシステム12は回復レート時間長を短くすることができる。逆に、R
2がR
1より低い場合、エンコーダシステム12は追加の又は延長された回復レート時間長を決定することができる。
【0112】
[0115]一般に、
図2及び
図3に関して上で述べられたように、エンコーダシステム12は、RTT、ダウンリンク遅延(例えば、受信機から送信機への)、レート制御反応遅延についての知識、混雑制御の反応遅延(例えば、リンクレートの推定)、メッセージ生成遅延(例えば、RTCPパケットを生成することと関連付けられる遅延)などのネットワーク情報から、バッファリング時間長(ΔT)を推定することができる。このネットワーク情報は、送信機側において利用可能であることがあり、又は、ビデオデコーダ42(
図3)を組み込む機器などの受信機機器によって、エンコーダシステム12に信号伝達され得る。
【0113】
[0116]
図4A及び
図4Bの例は、例示を目的として、ステップ的な変化(例えば、R
0とR
Uの間での単一のレート変化を示すが、本技法は、アンダーシュートの形状がよりなだらかとなるように繰り返し適用され得ることを理解されたい。
【0114】
[0117]
図5は、本開示の技法による、バッファリング時間長を決定することを示す概念図である。
図5の例では、送信機機器(例えば、エンコーダシステム12など)は、時間120において、RTCP送信機報告(SR)を受信機機器(例えば、デコーダシステム14など)に送信することができる。例えば、上で述べられたようなRFC3550において説明されたように、幾つかのRTCPパケットは、様々な制御情報を搬送するために使用され得る。送信機報告(SR)が、動作している送信機である参加者からの送信と受信の統計のために使用され得る。同様に、受信機報告(RR)は、動作している送信機ではない参加者からの受信統計のために、及び、32個以上の発信源についての動作している送信機の報告のためのSRと組み合わせて、使用され得る。受信機機器は、時間122において、RTCP SRを受信することができる。
【0115】
[0118]受信機機器は、時間124において、順方向チャネルの推定される最大ビットレートで、RTCP TMMBRメッセージを送信機機器に送信することができる。幾つかの例では、メッセージを生成することと関連付けられる遅延があり得るが、受信機機器は、混雑を検出した直後にTMMBRメッセージを送信することができる。TMMBRメッセージが例示を目的に説明されるが、遅延/混雑を示し得る様々な他のメッセージが使用され得る。
【0116】
[0119]バッファリング時間長(ΔT)を推定することよって送信機機器を支援するために、受信機機器はまた、時間124において、RTCP RRメッセージを送信することができる。本開示の態様によれば、受信機機器は、TMMBRメッセージの直後にRRメッセージを送信することができる。このようにして、送信機機器は、時間126において、TMMBRメッセージとRRメッセージとを受信することができ、RRに含まれる最後のSRタイムスタンプ(LSRデータ)によってRRにおいて参照されるSRを送信することと、RRが受信される時間との間の時間差として、バッファリング時間長(ΔT)128の上限を計算することができる。言い換えると、受信機機器は、ビットレート制限のための要求を示す第1のデータ(例えば、TMMBRメッセージ)と、メッセージが生成された時間を示す第2のデータ(例えば、LSRデータ)とを送信することができる。LSRデータは、発信源から最新のRTCP SRパケットの一部として受信された、64ビットのネットワーク時間プロトコル(NTP)タイムスタンプのうちの中間の32ビットを含み得る。SRがまだ受信されていない場合、LSRタイムスタンプフィールドは0に設定され得る。
【0117】
[0120]別の例では、上で述べられたデータを伴う2つの別々の連続するメッセージ(例えば、TMMBR及びRTCP RR)を送信するのではなく、TMMBRデータ及びRTCP RRデータは、単一のRTCPメッセージへとグループ化され得る。最低でも、受信機機器はLSRデータを送信することができ、これは送信機機器がバッファリング時間長(ΔT)128を推定することを可能にする。この例では、メッセージサイズが低減され得る。
【0118】
[0121]受信機機器は、同じLSRを有するRTCP RRメッセージを以前に送信していたとしても、最後の受信されたRTCP SRメッセージのLSRを使用することができる。受信機機器がRRをまだ送信していなかった場合、受信機機器は、完全なRRメッセージをTMMBRメッセージと組み合わせることができる。他の例では、メッセージサイズを減らすために、受信機機器は、TMMBRメッセージと一緒にLSRデータを送信するだけであってよく、これはRTTを計算するために使用され得る。
【0119】
[0122]別の例では、受信機機器がすでにRRを送信していた場合、送信機機器は、最後の受信されたRRメッセージを受信することと、(例えば、混雑が検出された後に受信機によって送信された)新たなRRメッセージとの間の時間差として、バッファリング時間長(ΔT)128をより正確に計算することができる。
【0120】
[0123]更に別の例では、送信機機器は遅延(例えば、RTT)を監視することができ、送信機機器は、遅延が十分に低減されるまで、送信レートを低減されたレートR
uに保つことができる。例えば、送信機機器は、送信機機器のバッファに記憶されているデータの量が閾値レベルを下回るまで、送信レートを低減されたレートR
uに維持することができる。
【0121】
[0124]
図6A及び
図6Bは、ネットワークリンクレートの低下及び対応する遅延時間をそれぞれ示すグラフである。
図6Aのグラフは
図4Aの線80と関連付けられ得るが、
図6Bのグラフは
図4Bの線88と関連付けられ得る。例えば、
図6Aは破線によって示されるネットワーク帯域幅140(ネットワークリンクレートとも呼ばれる)と、実線によって示される送信レート142(符号化ビットレートとも呼ばれる)(例えば、キロバイト毎秒(KBPS)単位で測定される)とを示す。
図6Aに示されるように、送信機機器(例えば、エンコーダシステム12など)は、帯域幅140と同じ、又は同様のレートの送信レート142でデータを符号化することができる。従って、帯域幅140が時間144において下げられるとき、送信機機器は、送信レート142を帯域幅140とほぼ同じ値に下げることができる。
【0122】
[0125]
図6Bの対応する遅延グラフに示されるように、帯域幅140の低下の後で、エンコーダシステム12における遅延は、(例えば、ミリ秒(MS)単位で測定される)第1のレベル146から第2のレベル148に上げられ得る。本明細書で説明されるように、帯域幅が低下すると遅延は増え、それは、送信レート142を帯域幅140のレベルに下げることと関連付けられる反応時間があるからである。エンコーダシステム12は、帯域幅140と一致するように送信レート142を減らす前の元の(より高い)レートで符号化されるバッファデータをバッファリングすることができる。
図6Bに示されるように、遅延は、遅延を減らすための技法が適用されない場合、比較的長い時間長残り得る。
【0123】
[0126]
図7A及び
図7Bは、ネットワークリンクレートの低下及び対応する遅延時間をそれぞれ示すグラフである。
図7Aのグラフは
図4Aの線82及び86と関連付けられ得るが、
図7Bのグラフは
図4Bの破線90と関連付けられ得る。例えば、
図7Aは破線によって示されるネットワーク帯域幅160(ネットワークリンクレートとも呼ばれる)と、実線によって示される送信レート162(符号化ビットレートとも呼ばれる)(例えば、キロバイト毎秒(KBPS)単位で測定される)とを示す。
図7Aに示されるように、送信機機器(例えば、エンコーダシステム12など)は最初に、帯域幅160と同じ、又は同様のレートの送信レート162でデータを符号化することができる。
【0124】
[0127]本開示の態様によれば、帯域幅160が時間164において下げられるとき、送信機機器は、帯域幅160より低い低減されたレートに送信レートを下げることができる。即ち、送信機機器は、帯域幅160の低下と関連付けられる遅延を減らすために、帯域幅140をアンダーシュートする送信レート162を決定することができる。本明細書で説明されるように、送信機機器は、本開示の技法に従って、バッファリング時間長、低減されたレート及び/又は回復レート時間長を決定することができる。
【0125】
[0128]
図7Bの対応する遅延グラフに示されるように、帯域幅160の低下の後で、エンコーダシステム12における遅延は、(例えば、ミリ秒(MS)単位で測定される)第1のレベル166から第2のレベル168に上げられ得る。上で述べられたように、帯域幅が低下すると遅延は増え、それは、帯域幅160の低下に応答して送信レート162を下げることと関連付けられる反応時間があるからである。しかしながら、送信レート162を(帯域幅160をアンダーシュートする)低減されたレートに下げることによって、エンコーダシステム12は、
図6Bに示される例より高速に遅延を減らすことができる。
【0126】
[0129]
図8は、データが送信されるレートをダウンスイッチングするための例示的なプロセスを示す流れ図である。
図8の例は、例示を目的にエンコーダシステム12に関して説明される。しかしながら、
図8のプロセスは様々な他の機器及び/又はプロセッサによって行われ得ることを理解されたい。
【0127】
[0130]エンコーダシステム12は、第1のレートでネットワークを通じてデータを符号化し送信することができる(180)。第1のレートでデータを送信する間に、エンコーダシステム12は、第1のレートから第2のレートへのネットワークリンクレートの低下を特定することがある(182)。例えば、エンコーダシステム12は、ネットワーク条件を監視し、及び/又は、ネットワークリンクレートの低下を示す1つ又は複数のメッセージを受信することができる。
【0128】
[0131]エンコーダシステム12は、第2の(低減された)ネットワークリンクレートより低い回復ビットレートを決定することができる(184)。例えば、エンコーダシステム12は、新たなネットワークリンクレートをアンダーシュートする、データを符号化するためのビットレートを決定することができる。本開示の態様によれば、エンコーダシステム12は、第1のネットワークリンクレートと低減されたネットワークリンクレートとの間の差に基づいて回復ビットレートを決定することができる。例えば、ネットワークリンクレートの低下が比較的大きい場合、エンコーダシステム12は、比較的積極的な(例えば、低減されたレートをかなりのマージンでアンダーシュートする)回復ビットレートを決定することができる。同様に、ネットワークリンクレートの低下が比較的小さい場合、エンコーダシステム12は、比較的保守的な(例えば、低減されたレートを比較的小さいマージンでアンダーシュートする)回復ビットレートを決定することができる。
【0129】
[0132]エンコーダシステム12はまた、反応遅延(例えば、ネットワークリンクレートの低下に応答して送信レートを下げることと関連付けられる時間)に基づいて、バッファリング時間長を決定することができる(186)。エンコーダシステム12は、様々な方法でバッファリング時間長を決定することができる。例えば、エンコーダシステム12は、エンコーダシステム12と受信機機器との間のラウンドトリップ時間(RTT)、ダウンリンク遅延、レート適合反応遅延、混雑制御の反応遅延、メッセージ生成遅延などのネットワーク情報からバッファリング時間長を推定することによって、バッファリング時間長を決定することができる。エンコーダシステム12は、ネットワーク情報を独立に決定することができ、又は、受信機機器からネットワーク情報を受信することができる。
【0130】
[0133]エンコーダシステム12は次いで、回復ビットレートを維持すべき回復レート時間長を決定することができる(188)。幾つかの例では、エンコーダシステム12は、回復レートの大きさに基づいて、及びバッファリング時間長に基づいて、回復レート時間長を決定することができる。幾つかの例では、エンコーダシステム12は、(例えば、回復レートによって示されるような)ネットワークリンクレートの低下の大きさと、(例えば、バッファリング時間長によって示されるような)ネットワークリンクレートの低下に反応することと関連付けられる時間の量とに比例する、バッファリング時間長を決定することができる。
【0131】
[0134]エンコーダシステム12は、回復レート時間長の間、回復ビットレートでデータを送信することができる(190)。幾つかの例では、ネットワークリンクレートが回復レート時間長の間に上がる場合、エンコーダシステム12は、回復レート時間長を早く終了することができ、より高い送信レートへとアップスイッチングすることができる。例に応じて、
図8に関して説明された技法のいずれかの、幾つかの行為又はイベントは、異なる順序で実行されてよく、追加されてよく、統合されてよく、又は完全に除外されてよい(例えば、説明された行為又はイベントのすべてが技法の実践のために必要であるとは限らない)ことを理解されたい。
【0132】
[0135]
図9は、データが送信されるレートをアップスイッチングするための例示的なプロセスを示す流れ図である。
図9の例は、例示を目的にデコーダシステム14に関して説明される。しかしながら、
図9のプロセスは様々な他の機器及び/又はプロセスによって行われ得ることを理解されたい。
【0133】
[0136]デコーダシステム14は、データが受信される時間を決定することができる(200)。例えば、幾つかの事例では、デコーダシステム14は、データがデコーダシステム14において受信され、記憶される時間を特定することができる。他の事例では、デコーダシステム14は、デコーダシステム14によってデータが処理(例えば、復号)される時間を特定することができる。
【0134】
[0137]デコーダシステム14は、また、受信されたデータの再生時間を決定することができる(202)。例えば、受信されたデータは、データがユーザへの表示のために出力されることが意図される時間の指示を含み得る。従って、再生時間の指示は、出力のためにデータを編成する際にデコーダシステム14を支援することができる。
【0135】
[0138]デコーダシステム14は、許容可能超過遅延パラメータを決定することができる(204)。例えば、デコーダシステム14は、データが受信される時間と受信されたデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータを決定することができる。本明細書で説明されるように、遅延は、データがネットワークリンクにわたる送信に利用可能であることと、データが送信機機器においてネットワークに実際に送信される時間との間の時間を指し得る。従って、許容可能超過遅延パラメータは、ユーザ体験が影響を受けないような、システムによって対応可能な遅延の量を示し得る。即ち、許容可能超過遅延パラメータは一般に、ユーザ体験に影響を与えることなくビットレートを上げるための基礎として、送信機機器によって利用され得る時間の量を示し得る。
【0136】
[0139]デコーダシステム14は次いで、送信機ビットレートの増加を決定することができる(206)。例えば、本開示の態様によれば、デコーダシステム14は、許容可能超過遅延パラメータに基づいて送信機ビットレートの増加を決定することができる。即ち、デコーダシステム14は、混雑をシステムにもたらすことなく送信レートがどれだけ送信機機器によって上げられ得るかを決定することができる。
【0137】
[0140]幾つかの例では、デコーダシステム14は、送信レートに追加されるべきステップ的なレートの増加を決定することができる。例えば、デコーダシステム14は、許容可能超過遅延パラメータと、送信レートの増加を決定する前の、データが受信された現在の平均送信レート(例えば、現在の受信レート)とに基づいて、送信機ビットレートの増加を決定することができる。この例では、デコーダシステム14は、持続可能なリンクレートを超えて(例えば、パケットの予定された再生時間の後に、パケットがデコーダシステム14に到着するようなレートに)レートを上げることなく、現在の送信レートがどれだけ上げられ得るかを決定することができる。
【0138】
[0141]幾つかの例では、デコーダシステム14はまた、デコーダシステム14と送信機機器(例えば、ラウンドトリップ時間)との間でメッセージを送信するために必要とされる時間の量及び/又はデコーダシステム14において遅延を特定することと関連付けられる遅延を考慮することができる。例えば、デコーダシステム14は、ラウンドトリップ時間とデコーダシステム14において遅延を検出するための時間との合計に対する、受信機レートと乗じられた許容可能超過遅延パラメータの比に基づいて、送信機ビットレートの増加を決定することができる。
【0139】
[0142]デコーダシステム14は次いで、送信機レートの増加の指示を送信することができる(208)。例えば、デコーダシステム14は、送信機機器が送信レートに追加すべき、送信機機器に対するステップ的な送信機レートの増加を表すデータを送信することができる。別の例では、デコーダシステム14は、送信機機器の送信レートの増加を包含する要求された送信レートを表すデータを送信することができる。
【0140】
[0143]幾つかの例では、デコーダシステム14は、送信機ビットレートの増加が閾値の量を超えるときだけ、送信機ビットレートの増加の指示を送信し得る。例えば、デコーダシステム14は、送信機ビットレートの増加を所定の閾値と比較することができる。一例では、デコーダシステム14は、送信機ビットレートの増加が受信レートの約5パーセントを超えるときだけ、送信機ビットレートの増加の指示を送信し得る。別の例では、デコーダシステム14は、送信機ビットレートの増加が受信レートの約15パーセントを超えるときだけ、送信機ビットレートの増加の指示を送信し得る。他の閾値又は百分率も可能である。
【0141】
[0144]例に応じて、
図9に関して説明された技法のいずれかの、幾つかの行為又はイベントは、異なる順序で実行されてよく、追加されてよく、統合されてよく、又は完全に除外されてよい(例えば、説明された行為又はイベントのすべてが技法の実践のために必要であるとは限らない)ことを理解されたい。
【0142】
[0145]本明細書で説明される幾つかの例が特定の観点(例えば、「送信機機器」又は「受信機機器」によって実行されること)に関して説明されてきたが、本開示の技法はこのようには限定されないことを理解されたい。例えば、上で述べられたように、VTは双方向の通信フローであることが多い。従って、同様の技法は、順方向と逆方向の両方のネットワーク経路上で、例えば「送信機機器」と「受信機機器」の両方によって適用され得る。その上、幾つかの機器が例示を目的にある観点に関して示され説明されているが、本明細書で説明される機器は示されたものよりも多数又は少数のコンポーネントを有し得ることを理解されたい。例として、送信機機器は、ビデオエンコーダ20(
図2)とビデオデコーダ42(
図3)の両方を組み込むことができ、説明された技法の各々をそれらに対して実行することができる。
【0143】
[0146]1つ又は複数の例では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せで実行され得る。ソフトウェアで実行される場合、機能は、1つ又は複数の命令又はコードとしてコンピュータ可読媒体上に記憶されるか、若しくはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、又は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、全般に、(1)非一時的である有形コンピュータ可読記憶媒体、又は(2)信号若しくは搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コード及び/又はデータ構造を取り出すために、1つ又は複数のコンピュータ若しくは1つ又は複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
【0144】
[0147]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶機器、フラッシュメモリ、又は、命令又はデータ構造の形式で所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。例えば、命令が、ウェブサイト、サーバ又は他のリモート発信源から、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)又は赤外線、無線及びマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL又は赤外線、無線及びマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体及びデータ記憶媒体は、接続、搬送波、信号又は他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク(disk)及びディスク(disc)は、コンパクトディスク(disc)(CD)、レーザーディスク(登録商標)(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピー(登録商標)ディスク(disk)及びBlu−ray(登録商標)ディスク(disc)を含み、ここで、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。
【0145】
[0148]命令は、1つ又は複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)又は他の等価な集積回路もしくはディスクリート論理回路のような、1つ又は複数のプロセッサによって実行され得る。従って、本明細書で使用される「プロセッサ」という用語は、前述の構造又は本明細書で説明された技法の実装に好適な任意の他の構造のいずれかを指し得る。加えて、幾つかの態様では、本明細書で説明された機能は、符号化及び復号のために構成された専用ハードウェア及び/又はソフトウェアのユニット若しくはモジュール内で与えられるか、又は複合コーデックに組み込まれ得る。また、本技法は、1つ又は複数の回路又は論理要素中で完全に実行され得る。
【0146】
[0149]本開示の技法は、ワイヤレスハンドセット、集積回路(IC)又はICのセット(例えば、チップセット)を含む、多種多様な機器又は装置において実装され得る。本開示では、開示される技法を実行するように構成された機器の機能的態様を強調するために、様々なコンポーネント、モジュール又はユニットが説明されたが、それらのコンポーネント、モジュール、又はユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明されたように、様々なユニットが、適切なソフトウェア及び/又はファームウェアとともに、上で説明された1つ又は複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わされるか、又は相互動作可能なハードウェアユニットの集合によって与えられ得る。
【0147】
[0150]様々な例が、説明された。これら及び他の例は以下の特許請求の範囲内にある。
以下に本願発明の当初の特許請求の範囲に記載された発明を付記する。
[C1]
データを処理する方法であって、
第1のビットレートでネットワークを介してデータを送信することと、
第1のネットワークリンクレートから第2のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第2のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定することとを備える、方法。
[C2]
前記回復ビットレートを決定することが、前記ネットワークリンクレートの前記低下の大きさに基づくアンダーシュート係数を使用して前記回復ビットレートを決定することを備える、C1に記載の方法。
[C3]
前記第1のネットワークリンクレートと前記第2のネットワークリンクレートとの間の差として前記アンダーシュート係数を決定することと、前記第1のネットワークリンクレートによって前記差を除することとを更に備える、C2に記載の方法。
[C4]
前記回復ビットレートを決定することが、1と前記アンダーシュート係数との間の差と乗じられた前記第2のネットワークリンクレートとして前記回復ビットレートを決定することを備える、C3に記載の方法。
[C5]
前記アンダーシュートレート及び前記バッファリング時間長に基づいて前記低減されたレート時間期間を決定することが、式
ΔTu = ΔT (R0-R1) / (fU R1)
に基づいて前記回復レート時間長を決定することを備え、ΔTuが前記回復レート時間長を表し、ΔTが前記バッファリング時間長を表し、R0が前記第1のネットワークリンクレートを表し、R1が前記第2の低減されたネットワークリンクレートを表し、fUが前記ネットワークリンクレートの前記低下に基づく前記アンダーシュート係数を表す、C2に記載の方法。
[C6]
前記回復ビットレートを決定することが最小ビットレートより大きい回復ビットレートを決定することを備え、前記最小ビットレートが前記データを符号化するように構成されるエンコーダの符号化ビットレートに基づく、C1に記載の方法。
[C7]
前記回復レート時間長の間に前記データを送信する間に、前記第2のネットワークリンクレートから第3のネットワークリンクレートへの前記ネットワークリンクレートの増加を特定することと、
前記ネットワークリンクレートの前記増加を特定したことに応答して、前記回復ビットレートより高いビットレートへ前記回復ビットレートを増加することとを更に備える、C1に記載の方法。
[C8]
前記バッファリング時間長を決定することが、ラウンドトリップ時間(RTT)データ、受信機機器から送信機機器へのダウンリンク遅延と関連付けられるデータ、レート制御反応遅延と関連付けられるデータ、混雑制御の反応遅延と関連付けられるデータ又はメッセージ生成遅延と関連付けられるデータの少なくとも1つに基づいて、前記バッファリング時間長を決定することを備える、C1に記載の方法。
[C9]
それらの間で前記データが送信される、送信機機器から受信機機器への順方向チャネルの推定された最大ビットレートを示すデータを受信することと、
受信品質フィードバックを示すデータを受信することとを更に備え、
前記バッファリング時間長を決定することが、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて、前記バッファリング時間長を決定することを備える、C1に記載の方法。
[C10]
前記推定された最大ビットレートを示す前記データを受信することが、一時最大メディアストリームビットレート要求(TMMBR)メッセージを受信することを備え、前記受信品質フィードバックを示す前記データを受信することが、受信機報告(RR)メッセージを受信することを備える、C9に記載の方法。
[C11]
前記推定された最大ビットレートを示す前記データを受信し、前記受信品質フィードバックを示す前記データを受信することが、前記推定された最大ビットレートを示す前記データと、前記受信品質フィードバックを示す前記データとを含む単一のメッセージを受信することを備える、C9に記載の方法。
[C12]
前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて前記バッファリング時間長を決定することが、第1のメッセージが受信機機器に送信される時間と、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データが受信される時間との間の差を決定することを備える、C9に記載の方法。
[C13]
前記データが符号化されたビデオデータを備え、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信することを更に備え、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信することが、前記符号化されたビデオデータの前記ビットレートを決定された前記回復レート時間長の間前記回復ビットレートに下げるようにレート制御を実行することを備える、C1に記載の方法。
[C14]
データを処理するための機器であって、
データを記憶するように構成されたメモリと、
1つ以上のプロセッサとを備え、前記1つ以上のプロセッサが、
第1のビットレートでネットワークを介して前記データを送信し、
第1のネットワークリンクレートから第2のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定し、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、前記回復ビットレートは前記第2のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定する
ように構成される、機器。
[C15]
前記回復ビットレートを決定するために、前記1つ以上のプロセッサが、前記ネットワークリンクレートの前記低下の大きさに基づくアンダーシュート係数を使用して前記回復ビットレートを決定するように構成される、C14に記載の機器。
[C16]
前記1つ以上のプロセッサが更に、前記第1のネットワークリンクレートと前記第2のネットワークリンクレートとの間の差として前記アンダーシュート係数を決定し、前記第1のネットワークリンクレートによって前記差を除するように構成される、C15に記載の機器。
[C17]
前記回復ビットレートを決定するために、前記1つ以上のプロセッサが、1と前記アンダーシュート係数との間の差と乗じられた前記第2のネットワークリンクレートとして前記回復ビットレートを決定するように構成される、C16に記載の機器。
[C18]
前記アンダーシュートレート及び前記バッファリング時間長に基づいて前記低減されたレート時間期間を決定するために、前記1つ以上のプロセッサが、式
ΔTu = ΔT (R0-R1) / (fU R1)
に基づいて前記回復レート時間長を決定するように構成され、ΔTuが前記回復レート時間長を表し、ΔTが前記バッファリング時間長を表し、R0が前記第1のネットワークリンクレートを表し、R1が前記第2の低減されたネットワークリンクレートを表し、fUが前記ネットワークリンクレートの前記低下に基づく前記アンダーシュート係数を表す、C15に記載の機器。
[C19]
前記回復ビットレートを決定するために、前記1つ以上のプロセッサが、最小ビットレートより大きい回復ビットレートを決定するように構成され、前記最小ビットレートが前記データを符号化するように構成されるエンコーダの符号化ビットレートに基づく、C14に記載の機器。
[C20]
前記1つ以上のプロセッサが更に、
前記回復レート時間長の間に前記データを送信する間に、前記第2のネットワークリンクレートから第3のネットワークリンクレートへの前記ネットワークリンクレートの増加を特定し、
前記ネットワークリンクレートの前記増加を特定したことに応答して、前記回復ビットレートより高いビットレートへ前記回復ビットレートを増加するように構成される、C14に記載の機器。
[C21]
前記バッファリング時間長を決定するために、前記1つ以上のプロセッサが、ラウンドトリップ時間(RTT)データ、受信機機器から送信機機器へのダウンリンク遅延と関連付けられるデータ、レート制御反応遅延と関連付けられるデータ、混雑制御の反応遅延と関連付けられるデータ又はメッセージ生成遅延と関連付けられるデータの少なくとも1つに基づいて、前記バッファリング時間長を決定するように構成される、C14に記載の機器。
[C22]
前記1つ以上のプロセッサが更に、
それらの間で前記データが送信される、送信機機器から受信機機器への順方向チャネルの推定された最大ビットレートを示すデータを受信し、
受信品質フィードバックを示すデータを受信するように構成され、
前記バッファリング時間長を決定するために、前記1つ以上のプロセッサが、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて、前記バッファリング時間長を決定するように構成される、C14に記載の機器。
[C23]
前記推定された最大ビットレートを示す前記データを受信するために、前記1つ以上のプロセッサが、一時最大メディアストリームビットレート要求(TMMBR)メッセージを受信するように構成され、前記受信品質フィードバックを示す前記データを受信するために、前記1つ以上のプロセッサが、受信機報告(RR)メッセージを受信するように構成される、C22に記載の機器。
[C24]
前記推定された最大ビットレートを示す前記データを受信し、前記受信品質フィードバックを示す前記データを受信するために、前記1つ以上のプロセッサが、前記推定された最大ビットレートを示す前記データと、前記受信品質フィードバックを示す前記データとを含む単一のメッセージを受信するように構成される、C22に記載の機器。
[C25]
前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて前記バッファリング時間長を決定するために、前記1つ以上のプロセッサが、第1のメッセージが受信機機器に送信される時間と、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データが受信される時間との間の差を決定するように構成される、C22に記載の機器。
[C26]
前記データが符号化されるビデオデータを備え、前記1つ以上のプロセッサが更に、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信するように構成され、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信するために、前記1つ以上のプロセッサが、前記符号化されたビデオデータの前記ビットレートを決定された前記回復レート時間長の間前記回復ビットレートに下げるようにレート制御を実行するように構成される、C14に記載の機器。
[C27]
集積回路、
マイクロプロセッサ、又は
ワイヤレス通信機器の少なくとも1つを備える、C14に記載の機器。
[C28]
データを処理するための装置であって、
第1のビットレートでネットワークを介してデータを送信するための手段と、
第1のネットワークリンクレートから第2のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定するための手段と、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定するための手段と、ここにおいて、前記回復ビットレートは前記第2のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定するための手段と、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定するための手段とを備える、装置。
[C29]
実行されると、1つ以上のプロセッサに、
第1のビットレートでネットワークを介してデータを送信させ、
第1のネットワークリンクレートから第2のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定させ、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定させ、ここにおいて、前記回復ビットレートは前記第2のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定させ、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定させる
命令を記憶した、非一時的コンピュータ可読媒体。