JP6420006B2 - ビデオ電話における遅延の低減 - Google Patents

ビデオ電話における遅延の低減 Download PDF

Info

Publication number
JP6420006B2
JP6420006B2 JP2018028790A JP2018028790A JP6420006B2 JP 6420006 B2 JP6420006 B2 JP 6420006B2 JP 2018028790 A JP2018028790 A JP 2018028790A JP 2018028790 A JP2018028790 A JP 2018028790A JP 6420006 B2 JP6420006 B2 JP 6420006B2
Authority
JP
Japan
Prior art keywords
rate
network link
data
bit rate
recovery
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2018028790A
Other languages
English (en)
Other versions
JP2018139407A (ja
Inventor
ゲールト・ファン・デア・オーウェラ
ムハンメド・ゼイド・コバン
マルタ・カークゼウィックズ
ニコライ・コンラド・レウン
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2018139407A publication Critical patent/JP2018139407A/ja
Application granted granted Critical
Publication of JP6420006B2 publication Critical patent/JP6420006B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • H04L43/0894—Packet rate
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/24—Traffic characterised by specific attributes, e.g. priority or QoS
    • H04L47/2416—Real-time traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/26—Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • H04L47/263—Rate modification at the source after receiving feedback
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/40—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using video transcoding, i.e. partial or full decoding of a coded input stream followed by re-encoding of the decoded output stream
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N19/00—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals
    • H04N19/60—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding
    • H04N19/61—Methods or arrangements for coding, decoding, compressing or decompressing digital video signals using transform coding in combination with predictive coding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365—Multiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • H04N21/2365—Multiplexing of several video streams
    • H04N21/23655—Statistical multiplexing, e.g. by controlling the encoder to alter its bitrate to optimize the bandwidth utilization
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • H04N21/4347—Demultiplexing of several video streams
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/147—Communication arrangements, e.g. identifying the communication as a video-communication, intermediate storage of the signals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/141—Systems for two-way working between two video terminals, e.g. videophone
    • H04N7/148—Interfacing a video terminal to a particular transmission medium, e.g. ISDN
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/14—Systems for two-way working
    • H04N7/15—Conference systems
    • H04N7/152—Multipoint control units therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays
    • H04L43/0864—Round trip delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H04L43/106—Active monitoring, e.g. heartbeat, ping or trace-route using time related information in packets, e.g. by adding timestamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/16—Threshold monitoring
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D30/00—Reducing energy consumption in communication networks
    • Y02D30/50—Reducing energy consumption in communication networks in wire-line communication networks, e.g. low power modes or reduced link rate

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Multimedia (AREA)
  • Environmental & Geological Engineering (AREA)
  • Databases & Information Systems (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Communication Control (AREA)
  • Telephonic Communication Services (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)

Description

[0001]本出願は、その内容全体が参照により本明細書に組み込まれる、２０１４年７月２９日に出願された米国仮出願第６２／０３０，５１３号の利益を主張する。
[0002]本開示は、ビデオデータの処理に関する。
[0003]ビデオ電話（ＶＴ：video telephony）は、オーディオデータとビデオデータとを搬送するパケットのリアルタイム通信を伴う。ＶＴ機器は、ビデオカメラ又はビデオアーカイブなどの撮像装置からビデオを取得してビデオパケットを生成する、ビデオエンコーダを含む。同様に、ＶＴ機器の中のオーディオエンコーダは、マイクロフォン又は音声合成器などのオーディオキャプチャ機器からオーディオを取得し、オーディオパケットを生成する。ビデオパケット及びオーディオパケットは、無線リンクプロトコル（ＲＬＰ）キューの中に配置される。媒体アクセス制御（ＭＡＣ）レイヤユニットは、ＲＬＰキューの内容から媒体アクセス制御（ＭＡＣ）レイヤパケットを生成する。ＭＡＣレイヤパケットは、別のＶＴ機器への通信チャネルにわたる送信のために、物理（ＰＨＹ）レイヤパケットに変換される。
[0004]モバイルＶＴの用途では、ＶＴ機器は、基地局からワイヤレス端末としてのＶＴ機器へのワイヤレス順方向リンク（ＦＬ）（又は「ダウンリンク」）を介して、物理レイヤパケットを受信する。ＶＴ機器は、基地局へのワイヤレス逆方向リンク（ＲＬ）（又は「アップリンク」）を介してＰＨＹレイヤパケットを送信する。各ＶＴ機器は、受信されたＰＨＹレイヤパケットとＭＡＣレイヤパケットとを変換してパケットペイロードをオーディオパケット及びビデオパケットへと再び組み立てるために、ＰＨＹレイヤとＭＡＣレイヤとを含む。ＶＴ機器内のビデオデコーダは、表示装置を介したユーザへの提示のために、ビデオデータを復号する。ＶＴ機器内のオーディオデコーダは、オーディオスピーカーを介した出力のために、オーディオデータを復号する。
[0005]本開示の技法は、ネットワーク条件に基づいてデータを符号化するためのビットレートを決定することに関する。例えば、本開示の態様は、ネットワークリンクレートの低下に応答して、送信ビットレート（又は単にレートとも呼ばれる）を第１のレートから第２のレートに下げることに関する。本開示の態様によれば、ネットワークリンクレートの低下を特定すると、送信機機器は、送信レートを第２のネットワークリンクレート未満の低減されたレートへと下げることができ、例えば、第２のネットワークリンクレートをアンダーシュートすることができる。送信機機器は、低減されたレートに基づく、及び、その間は送信機機器又はネットワークと関連付けられる別の機器においてデータがバッファリングされる、ネットワークリンクレートの低下を特定することとネットワークリンクレートの低下に反応することとの間の時間長に基づく、時間期間の間、送信レートを低減されたレートに維持することができる。このようにして、送信機機器は、ユーザ体験に過度に影響を与えることなく、ネットワークリンクレートの低下の間にバッファリングされてきたデータの量を、比較的速く減らすことができる。
[0006]本開示の態様はまた、ネットワークリンクレートが完全には利用されていない事例において、送信レートを上げることに関する。例えば、本開示の態様によれば、受信機機器は、データが再生されるように予定される時間より前に受信機機器においてデータが受信されることに基づいて、ネットワークリンクレートが十分に利用されていないと決定することができる。受信機機器は、データが受信される時間とデータが再生されるように予定される時間との間の時間の差に基づいて、許容可能超過遅延パラメータを決定することができる。受信機機器は、許容可能超過遅延パラメータに従って、送信レートの増加を決定することができる。受信機機器は、幾つかの事例では、送信機機器に送信レートの増加の指示を送信することができるので、送信機機器は、ネットワークリンクレートを超えることなくネットワークリンクレートをより良好に利用することができる。
[0007]ある例では、データを処理する方法は、第１のビットレートでネットワークを通じてデータを送信することと、第１のネットワークリンクレートから第２のネットワークリンクレートへのネットワークのネットワークリンクレートの低下を特定することと、ネットワークリンクレートの低下を特定したことに応答して、ネットワークを通じてデータを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、回復ビットレートは第２のネットワークリンクレートより低い、ネットワークリンクレートの低下の特定の時間とネットワークリンクレートの低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、回復ビットレート及びバッファリング時間長に基づいて、回復ビットレートでデータを送信すべき回復レート時間長を決定することとを含む。
[0008]別の例では、データを処理するための機器は、データを記憶するように構成されるメモリと、１つ又は複数のプロセッサとを含み、１つ又は複数のプロセッサは、第１のビットレートでネットワークを通じてデータを送信し、第１のネットワークリンクレートから第２のネットワークリンクレートへのネットワークのネットワークリンクレートの低下を特定し、ネットワークリンクレートの低下を特定したことに応答して、ネットワークを通じてデータを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、回復ビットレートは第２のネットワークリンクレートより低い、ネットワークリンクレートの低下の特定の時間とネットワークリンクレートの低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、回復ビットレート及びバッファリング時間長に基づいて、回復ビットレートでデータを送信すべき回復レート時間長を決定するように構成される。
[0009]別の例では、データを処理するための装置は、第１のビットレートでネットワークを通じてデータを送信するための手段と、第１のネットワークリンクレートから第２のネットワークリンクレートへのネットワークのネットワークリンクレートの低下を特定するための手段と、ネットワークリンクレートの低下を特定したことに応答して、ネットワークを通じてデータを送信する際に用いるべき回復ビットレートを決定するための手段と、ここにおいて、回復ビットレートは第２のネットワークリンクレートより低い、ネットワークリンクレートの低下の特定の時間とネットワークリンクレートの低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定するための手段と、回復ビットレート及びバッファリング時間長に基づいて、回復ビットレートでデータを送信すべき回復レート時間長を決定するための手段とを含む。
[0010]別の例では、非一時的コンピュータ可読媒体は、実行されると、１つ又は複数のプロセッサに、第１のビットレートでネットワークを通じてデータを送信させ、第１のネットワークリンクレートから第２のネットワークリンクレートへのネットワークのネットワークリンクレートの低下を特定させ、ネットワークリンクレートの低下を特定したことに応答して、ネットワークを通じてデータを送信する際に用いるべき回復ビットレートを決定させ、ここにおいて、回復ビットレートは第２のネットワークリンクレートより低い、ネットワークリンクレートの低下の特定の時間とネットワークリンクレートの低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定させ、回復ビットレート及びバッファリング時間長に基づいて、回復ビットレートでデータを送信すべき回復レート時間長を決定させる、命令を記憶している。
[0011]別の例では、データを処理する方法は、受信機機器によって、受信されたデータが受信機機器によって受信される時間と受信されたデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータを決定することと、ここにおいて、許容可能超過遅延パラメータは送信機機器と受信機機器との間のチャネルによって対応可能な遅延の量を示す、受信機機器によって、決定された許容可能超過遅延パラメータに基づいて、送信機機器から受信機機器にデータが送信される際に用いるべきビットレートを上げるための送信機ビットレートの増加を決定することと、送信機ビットレートの増加の指示を送信機機器に送信することとを含む。
[0012]別の例では、データを処理するための受信機機器は、データを記憶するように構成されるメモリと、１つ又は複数のプロセッサとを含み、１つ又は複数のプロセッサは、データが受信機機器によって受信される時間とデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータ（allowable excess delay parameter）を決定し、ここにおいて、許容可能超過遅延パラメータは送信機機器と受信機機器との間のチャネルによって対応可能な遅延の量を示す、決定された許容可能超過遅延パラメータに基づいて、送信機機器から受信機機器にデータが送信される際に用いるべきビットレートを上げるための送信機ビットレートの増加を決定し、送信機ビットレートの増加の指示を送信機機器に送信するように構成される。
[0013]別の例では、データを処理するための装置は、受信されたデータが受信機機器によって受信される時間と受信されたデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータを決定するための手段と、ここにおいて、許容可能超過遅延パラメータは送信機機器と受信機機器との間のチャネルによって対応可能な遅延の量を示す、決定された許容可能超過遅延パラメータに基づいて、送信機機器から受信機機器にデータが送信される際に用いるべきビットレートを上げるための送信機ビットレートの増加を決定するための手段と、送信機ビットレートの増加の指示を送信機機器に送信するための手段とを含む。
[0014]別の例では、非一時的コンピュータ可読媒体は、実行されると、１つ又は複数のプロセッサに、受信されたデータが受信機機器によって受信される時間と受信されたデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータを決定させ、ここにおいて、許容可能超過遅延パラメータは送信機機器と受信機機器との間のチャネルによって対応可能な遅延の量を示す、決定された許容可能超過遅延パラメータに基づいて、送信機機器から受信機機器にデータが送信される際に用いるべきビットレートを上げるための送信機ビットレートの増加を決定させ、送信機ビットレートの増加の指示を送信機機器に送信させる、命令を記憶している。
[0015]本開示の１つ又は複数の例の詳細が添付の図面及び以下の説明に記載される。他の特徴、目的及び利点は、説明、図面及び特許請求の範囲から明らかになろう。
[0016]ビデオ電話（ＶＴ）用途のためのオーディオ／ビデオ符号化及び復号システムを示すブロック図。 [0017]本開示の技法によるビデオ発信源レート適合を実施し得るビデオ符号化システムを示すブロック図。 [0018]本開示の技法によるビデオ発信源レート適合を実施し得るビデオ復号システムを示すブロック図。 [0019]本開示の技法によるビデオ発信源レート適合技法を示すグラフ。 本開示の技法によるビデオ発信源レート適合技法を示すグラフ。 [0020]本開示の技法によるバッファリング時間長の決定を示す概念図。 [0021]ネットワークリンクレートの低下を示すグラフ。 対応する遅延時間を示すグラフ。 [0022]ネットワークリンクレートの低下を示すグラフ。 対応する遅延時間を示すグラフ。 [0023]本開示の技法による、データが送信されるレートをダウンスイッチングするための例示的なプロセスを示す流れ図。 [0024]本開示の技法による、データが送信されるレートをアップスイッチングするための例示的なプロセスを示す流れ図。
[0025]ビデオ電話（ＶＴ）機器は、ＶＴセッション（例えば、ＶＴ機器間のオーディオデータ及び又はビデオデータの送信）を行うための有線又はワイヤレスネットワークを介して接続され得る。別のＶＴ機器への送信のためにオーディオデータ及び又はビデオデータを処理しているＶＴ機器は、送信機機器と呼ばれ得る。同様に、（例えば、ＶＴ機器のユーザへの提示のために）受信されたオーディオデータ及び又はビデオデータを処理しているＶＴ機器は、受信機機器と呼ばれ得る。
[0026]送信機機器は、特定のレート（本明細書では交換可能にビットレートと呼ばれ得る）でオーディオデータ及び／又はビデオデータを符号化することができる。送信機機器は、ネットワーク条件に基づいてレートを選択することができる。例えば、送信機機器は、ＶＴセッションのために使用されているネットワークによってサポートされる最大の（又は最大に近い）ネットワークリンクレートに基づいてレートを選択することができる。このようにして、送信機機器は、ネットワークの制限を超えることなく、ネットワークによってサポートされる相対的により高い品質を使用して送信されるようにデータを準備することができる。
[0027]幾つかの事例では、ＶＴ機器を接続するネットワークリンクレートは、特にＷｉ−Ｆｉ（登録商標）又はセルラーネットワークなどのワイヤレスネットワーク上でＶＴを使用するとき、変化し得る。幾つかの事例では、ネットワーク機器は、リンクレートの変動に対処するために、及び／又はキュー管理を実行するために、バッファを使用し得る。例えば、送信機機器は、データを受信機機器に送信する前に符号化されたオーディオデータ及び／又はビデオデータをバッファリングするためのバッファを含み得る。ネットワークリンクレートの突然の低下は、ＶＴセッションに悪影響を与え得るボトルネックを引き起こし得る。例えば、ネットワークリンクレートが下がるとき、バッファの中に符号化されたビデオデータを蓄積するための送信機機器、これは、受信機機器でのＶＴセッションにおいて中断及び／又はジャーキネスを引き起こし得る。
[0028]送信機機器は、ネットワークリンクレートの低下に応答して、ビデオデータが送信されるレート（本明細書では送信レートと呼ばれることがあり、レートはビットレートを指すために本開示全体で使用される）を変更することができる。幾つかの例では、送信機機器は、オーディオデータ及び／又はビデオデータが符号化されるレートを変えることによって、送信レートを変更することができる。しかしながら、受信機機器の混雑制御フィードバックの遅延、受信機機器から送信機機器への戻り経路における遅延、レート適合反応の遅延などにより、レートを下げる際に反応の遅延があり得る。従って、送信レートは、ネットワークリンクレートの低下からある時間期間の間、ネットワークリンクレートを大きく上回ったままであり得る。送信レートとネットワークリンクレートの不整合は、ボトルネックのリンクにおけるバッファレベルの増大、従ってエンドツーエンドの遅延の増大（また更にはパケットの喪失）をもたらすことがあり、これはＶＴセッションの品質体験に悪影響を与えることがある。
[0029]加えて、送信機機器がネットワークリンクレートの低下に応答して送信レートを下げた後でも、ある時間は蓄積された遅延が残り得る。例えば、一般に、遅延は、データがネットワークリンクにわたる送信に利用可能であることと、データがネットワークに実際に送信される時間との間の時間を指し得る。従って、遅延はデータのバッファリングと関連付けられ得る。例えば、遅延の増大はバッファレベルの増大をもたらし、それは、符号化の後に、及びネットワークへの送信の前にデータが記憶されなければならないからである。
[0030]送信レートとボトルネックのネットワークリンクレートとの間の差に応じて、送信機機器は、バッファリングされたデータの品質を比較的ゆっくり下げることがある。即ち、低減された送信レートとネットワークリンクレートとの間の差が比較的小さい場合、送信機機器は、蓄積された遅延を比較的ゆっくり減らすことがあり、ＶＴセッションへの影響が残ることがある。
[0031]バッファリングされたデータの量を下げることに対する１つの手法は、推定されたネットワークリンクレート未満に送信レートを下げることである。比較的保守的な手法、例えば、推定されるネットワークリンクレートを大きく下回る送信レートを使用することは、リンクの不十分な使用と、受信機機器におけるビデオ品質体験の全体的な低下とをもたらし得る。しかしながら、そのような保守的な手法はまた、ボトルネックのリンクのバッファを比較的速く減らすことができる。逆に比較的積極的な手法、例えば、送信レートをネットワークリンクレートに下げるだけであることは、リンクの完全な使用とより高品質な符号化されたデータとをもたらし得る。しかしながら、上で述べられたように、そのような手法は、データを比較的長い時間の期間バッファにとどまらせることがある。
[0032]本開示の態様は、ネットワーク条件に基づいて送信レート（例えば、送信機機器においてオーディオデータ及び／又はビデオデータを符号化するためのビットレート）を決定することに関する。具体的には、本技法は、ネットワークリンクレートの低下に応答して送信レートを下げることを含む。本開示の態様によれば、低減されたネットワークリンクレートを特定すると、送信機機器は、送信レートをネットワークリンクレート未満のレートへと下げることができる。幾つかの例では、受信機機器は、次いで送信機機器によって実装される、低減された送信レートを要求することができる。送信レートをネットワークリンクレート未満のレートに下げることは、ネットワークリンクレートをアンダーシュートすることとして呼ばれることがある。
[0033]本技法はまた、低減されたレートに送信レートを維持するための時間の量を決定することを含む。幾つかの例では、本開示の態様は、以下でより詳細に説明されるように、バッファリング時間長、ネットワークリンクレートの低下の大きさ、レート低減係数及び／又は他の係数に基づいて回復レート時間長（アンダーシュート期間とも呼ばれる）を決定することを含む。このようにして、本技法は、最適なアンダーシュート期間を決定するために使用され得る。例えば、送信機機器は、ネットワークによってサポートされる増加された送信レートに戻る前に、バッファリングされたデータの量を減らすために必要とされる場合にのみ限り、低減された送信レートを維持することができる。本技法は、上で説明された保守的な手法と積極的な手法のバランスを実現することができるので、バッファリングされるデータの量は、ユーザ体験に過度に影響を与えることなく比較的速く減らされ得る。
[0034]本開示の態様はまた、符号化されたオーディオデータ及び／又はビデオデータを処理することと関連付けられる遅延データを信号伝達することを含む。本開示の技法は、送信機機器においてバッファリング時間長を決定する際に使用するためのデータを生成することを含む。バッファリング時間長は、実際のネットワークリンクレートの低下と、ネットワークリンクレートの低下が検出される時間との間の遅延と関連付けられ得る（例えば、送信機及び／又は受信機機器がネットワークリンクレートの低下を直ちに認識してそれに応答することはないと仮定する）。この遅れ時間の間、送信機機器は通常、元の送信レートで準備／符号化されたデータをバッファリングするが、これは低減されたネットワークリンクレートではリアルタイム（又はほぼリアルタイム）で送信されることが可能ではない。データのバッファリングは、その間はデータが受信されない遅延を、受信機機器において生み出す。上で述べられたように、バッファリング時間は、送信機機器においてバッファリングされるデータの量及び／又は回復レート時間長を決定するために使用され得る。
[0035]本開示の他の態様は、ネットワークリンクレートが完全には利用されていない事例において、送信レートを上げることに関し得る。例えば、送信機機器は、送信レートが送信機機器を受信機機器につなぐネットワークによってサポート可能なリンクレート未満であるユーザ体験事例の品質を上げるために、データの送信レートを上げることができる。データが符号化されるビットレートを上げることは、本明細書ではアップスイッチングと呼ばれ得る。しかしながら、大きすぎるインクリメントで送信レートをアップスイッチングすることは、ネットワークリンクレートのオーバーシュートをもたらすことがあり、これは、説明されたようにユーザ体験を悪くすることがある。逆に、小さすぎるインクリメントで送信レートをアップスイッチングすることは、ネットワークリンクレートのアンダーシュートの継続をもたらすことがあり、これは、ネットワークリンクレートによってサポート可能なものよりも低い品質のユーザ体験をもたらすことがある。
[0036]本開示の態様によれば、受信機機器は、データが再生されるように予定される時間より前にデータが受信されることに基づいて、ネットワークリンクレートが十分に利用されていないと決定することができる。受信機機器は、データが受信される時間とデータが再生されるように予定される時間との間の差に基づいて許容可能超過遅延パラメータを決定することができ、受信機機器は、許容可能超過遅延パラメータに従って送信レートの増加を決定することができる。受信機機器は、幾つかの事例では、送信機機器に送信レートの増加の指示を送信することができるので、送信機機器は、ネットワークリンクレートをオーバーシュートすることなくネットワークリンクレートをより良好に利用することができる。
[0037]従って、本開示の態様は、送信機機器から発信され、受信機機器への時間変化する帯域幅を伴うネットワークチャネル（ネットワークリンクとも呼ばれる）を通じて送信される、ビデオフローを制御するためのレート適合又は混雑制御技法を含む。具体的には、本技法は、ネットワークに混雑をもたらすことなくユーザ体験を改善するために、制御された方式でビデオフローの平均ビットレートをアップスイッチングすることを含む。そのようなレート適合技法は、パケット損失をもたらし得るエンドツーエンドの遅延の大幅な増加を避け得る。
[0038]例えば、本開示の態様によれば、受信機機器は、受信されたビデオパケットを検査し、データがデータの予定された再生に対して早く到着しているか、時間通りに到着しているか、又は遅く到着しているかを決定することができる。データが意図される再生より遅く到着している場合、受信機機器は、ネットワークリンクレートが送信レート（例えば、送信機機器において実装される符号化レート）より低いと決定することができる。従って、受信機機器は、送信レートを下げるための要求を送信機機器に送信することができる。幾つかの例では、受信機機器は、システムがネットワークチャネルの混雑を解消することを可能にするために、ネットワークリンクレートの持続可能なレート（例えば、利用可能な帯域幅）より低い初期レートを要求することができる。
[0039]幾つかの事例では、本明細書で説明される技法は、ＩＰマルチメディアサブシステム（ＩＭＳ：IP Multimedia Subsystem）のためのマルチメディア電話サービス（ＭＴＳＩ：Multimedia Telephony Service for IP Multimedia Subsystem）機器によって実行され得る。例えば、ＭＴＳＩ機器は、本明細書で説明される技法を使用してビットレート適合及び／又は混雑制御を実行することができる。
[0040]図１は、符号化及び復号システム１０を示すブロック図である。図１に示されるように、システム１０は、送信チャネル１６によって接続されるエンコーダシステム１２とデコーダシステム１４とを含む。図１の例では、エンコーダシステム１２は、第１のビデオ通信機器と関連付けられ、オーディオ発信源１７と、ビデオ発信源１８と、ビデオエンコーダ２０と、オーディオエンコーダ２２と、リアルタイムトランスポートプロトコル（ＲＴＰ）／リアルタイムトランスポートプロトコル（ＲＴＣＰ）／ユーザデータグラムプロトコル（ＵＤＰ）／インターネットプロトコル（ＩＰ）／ポイントツーポイントプロトコル（ＰＰＰ）変換ユニット２６と、無線リンクプロトコル（ＲＬＰ）キュー２８と、ＭＡＣレイヤユニット３０と、物理（ＰＨＹ）レイヤユニット３２とを含む。デコーダシステム１４は、別のビデオ通信機器と関連付けられ、ＰＨＹレイヤユニット３４と、ＭＡＣレイヤユニット３６と、ＲＬＰキュー３８と、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換ユニット４０と、ビデオデコーダ４２と、オーディオデコーダ４４と、オーディオ出力機器４６と、ビデオ出力機器４８とを含む。
[0041]以下でより詳細に説明されるように、エンコーダシステム１２及び／又はデコーダシステム１４は、ネットワーク条件に基づいて符号化レートを調整するために、本開示の技法を使用することができる。例えば、ビデオエンコーダ２０は、少なくとも一部、ネットワーク帯域幅の関数として、ビデオ発信源符号化レートを制御することができる。具体的には、ビデオエンコーダ２０は、ネットワークリンクレートの低下に応答して、ビデオデータ及び／又はオーディオデータの符号化レートを下げることができる。同様に、ビデオエンコーダ２０は、ネットワークリンクレートの不十分な利用の指示に応答して、ビデオデータ及び／又はオーディオデータの符号化レートを上げることができる。
[0042]システム１０は、例えば、送信チャネル１６を介したビデオ電話のために、双方向のビデオ及びオーディオの送信を提供することができる。従って、全般に相対応する符号化、復号及び変換ユニットが、チャネル１６の反対側に設けられ得る。幾つかの実施形態では、エンコーダシステム１２及びデコーダシステム１４は、ビデオストリーミング、ビデオ電話又は両方に対応したワイヤレスモバイル端末などのビデオ通信機器内で具現化され得る。モバイル端末は、ＲＴＰ、ＲＴＣＰ、ＵＤＰ、ＩＰ又はＰＰＰなどのパケット交換規格に従ってＶＴをサポートすることができる。
[0043]例えば、エンコーダシステム１２において、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換ユニット２６は、ビデオエンコーダ２０及びオーディオエンコーダ２２から受信されたオーディオデータ及びビデオデータに、適切なＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダデータを追加し、データをＲＬＰキュー２８に配置する。例示的なビットストリームは、ＭＡＣヘッダと、ＩＰヘッダと、ＵＤＰヘッダと、ＲＴＣＰヘッダと、ペイロードデータとを含み得る。幾つかの例では、ＲＴＰ／ＲＴＣＰはＵＤＰの上で動作するが、ＵＤＰはＩＰの上で動作し、ＩＰはＰＰＰの上で動作する。幾つかの例では、本明細書で説明されるように、「ＲＦＣ ３５５０： ＲＴＰ： Ａ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ ｆｏｒ Ｒｅａｌ−Ｔｉｍｅ Ａｐｐｌｉｃａｔｉｏｎｓ」、Ｈ． Ｓｃｈｕｌｚｒｉｎｎｅ他、２００３年７月、「ＲＦＣ ５１０４： Ｃｏｄｅｃ Ｃｏｎｔｒｏｌ Ｍｅｓｓａｇｅｓ ｉｎ ｔｈｅ ＲＴＰ Ａｕｄｉｏ−Ｖｉｓｕａｌ Ｐｒｏｖｉｄｅ ｗｉｔｈ Ｆｅｅｄｂａｃｋ （ＡＶＰＦ）」、Ｓ．Ｗｅｎｇｅｒ他、２００８年２月（以後ＲＦＣ ５１０４）及び／又はデータのリアルタイムのトランスポート若しくはほぼリアルタイムのトランスポートのための他の適用可能な規格などの、特定の規格に適合するＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換ユニット２６。ＭＡＣレイヤユニット３０は、ＲＬＰキュー２８の内容からＭＡＣ ＲＬＰパケットを生成する。ＰＨＹレイヤユニット３２は、チャネル１６を通じた送信のために、ＭＡＣ ＲＬＰパケットをＰＨＹレイヤパケットに変換する。
[0044]デコーダシステム１４のＰＨＹレイヤユニット３４及びＭＡＣレイヤユニット３６は、相互に動作する。ＰＨＹレイヤユニット３４は、チャネル１６から受信されたＰＨＹレイヤパケットをＭＡＣ ＲＬＰパケットに変換する。ＭＡＣレイヤユニット３６は、ＭＡＣ ＲＬＰパケットをＲＬＰキュー３８に配置する。ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換ユニット４０は、ＲＬＰキュー３８中のデータからヘッダ情報を奪い、ビデオデコーダ４２及びオーディオデコーダ４４への配信のためにそれぞれ、ビデオデータとオーディオデータとを再び組み立てる。
[0045]システム１０は、符号分割多重接続（ＣＤＭＡ）、周波数分割多重接続（ＦＤＭＡ）、時分割多重接続（ＴＤＭＡ）又は直交周波数分割多重化（ＯＦＤＭ）若しくは別の適切なワイヤレス技法などの、１つ又は複数のワイヤレス通信技術をサポートするように設計され得る。上のワイヤレス通信技術は、様々な無線アクセス技術のいずれかに従って実現され得る。例えば、ＣＤＭＡは、ｃｄｍａ２０００又は広帯域ＣＤＭＡ（ＷＣＤＭＡ（登録商標））規格に従って実現され得る。ＴＤＭＡは、Ｇｌｏｂａｌ Ｓｙｓｔｅｍ ｆｏｒ Ｍｏｂｉｌｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ（ＧＳＭ（登録商標））規格に従って実現され得る。Ｕｎｉｖｅｒｓａｌ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｓｙｓｔｅｍ（ＵＭＴＳ）規格は、ＧＳＭ又はＷＣＤＭＡ動作を可能にする。通常、ＶＴ用途では、システム１０はｈｉｇｈ ｄａｔａ ｒａｔｅ（ＨＤＲ）技術をサポートするように設計され得る。
[0046]ビデオエンコーダ２０は、ＭＰＥＧ−４、Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ Ｖｉｄｅｏ Ｃｏｄｉｎｇ（ＨＥＶＣ）又は別のビデオコード化規格などの、あるビデオ圧縮方法に従って符号化されたビデオデータを生成する。他のビデオ圧縮方法は、国際電気通信連合（ＩＴＵ）Ｈ．２６３、ＩＴＵ Ｈ．２６４又はＭＰＥＧ−２の方法を含む。オーディオエンコーダ２２は、ビデオデータに付随するオーディオデータを符号化する。ビデオ発信源１８は、１つ又は複数のビデオカメラ、１つ又は複数のビデオアーカイブ又はビデオカメラとビデオアーカイブの組合せなどの、撮像装置であり得る。
[0047]オーディオデータは、適応マルチレートナローバンド（ＡＭＲ−ＮＢ：adaptive multi-rate narrow band）又は他の技法などの、オーディオ圧縮方法に従って符号化され得る。オーディオ発信源１７は、マイクロフォン又は音声合成器機器などの、オーディオキャプチャ機器であり得る。ＶＴ用途では、ビデオは参加者にＶＴ会議を見えるようにし、オーディオはその参加者の話している声を聞こえるようにする。
[0048]動作において、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換ユニット２６は、ビデオエンコーダ２０及びオーディオエンコーダ２２からビデオデータパケットとオーディオデータパケットとを取得する。前に言及されたように、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換ユニット２６は、適切なヘッダ情報をオーディオパケットに追加し、得られたデータをＲＬＰキュー２８内に挿入する。同様に、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰ変換ユニット２６は、適切なヘッダ情報をビデオパケットに追加し、得られたデータをＲＬＰキュー２８内に挿入する。ＭＡＣレイヤユニット３０は、ＲＬＰキュー２８からデータを取り出し、ＭＡＣレイヤパケットを形成する。各ＭＡＣレイヤパケットは、ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰヘッダ情報と、ＲＬＰキュー２８内に含まれるオーディオパケットデータ又はビデオパケットデータとを搬送する。オーディオパケットは、ビデオパケットとは独立にＲＬＰキュー２８に挿入され得る。
[0049]幾つかの場合、ＲＬＰキュー２８の内容から生成されるＭＡＣレイヤパケットは、ヘッダ情報とビデオパケットデータとのみを搬送する。他の場合、ＭＡＣレイヤパケットは、ヘッダ情報とオーディオパケットデータとのみを搬送する。多くの場合、ＭＡＣレイヤパケットは、ＲＬＰキュー２８の内容に応じて、ヘッダ情報と、オーディオパケットデータと、ビデオパケットデータとを搬送する。ＭＡＣレイヤパケットは、無線リンクプロトコル（ＲＬＰ）に従って構成されてよく、ＭＡＣ ＲＬＰパケットと呼ばれ得る。ＰＨＹレイヤユニット３２は、チャネル１６にわたる送信のために、ＭＡＣ ＲＬＰオーディオ−ビデオパケットをＰＨＹレイヤパケットに変換する。
[0050]チャネル１６は、ＰＨＹレイヤパケットをデコーダシステム１４に搬送する。チャネル１６は、エンコーダシステム１２とデコーダシステム１４との間の任意の物理的接続であり得る。例えば、チャネル１６は、ローカルエリア又はワイドエリアの有線ネットワークなどの、有線接続であり得る。代替的に、本明細書で説明されるように、チャネル１６は、セルラー接続、衛星接続又は光接続などの、ワイヤレス接続であり得る。チャネル条件は、有線チャネル及びワイヤレスチャネルの課題であり得るが、ワイヤレスチャネル１６を通じて実行されるモバイルＶＴ用途では特に関係があることがあり、ワイヤレスチャネル１６においては、チャネル条件がフェージング又は混雑により悪化することがある。チャネル１６は、チャネル条件に従って変動することがある、特定のネットワークリンクレート（例えば、特定の帯域幅）をサポートし得る。例えば、チャネル１６は、チャネル条件に従って変化するスループットを有する逆方向リンク（ＲＬ）によって特徴付けられ得る。
[0051]一般に、デコーダシステム１４のＰＨＹレイヤユニット３４は、ＰＨＹレイヤパケットからＭＡＣレイヤパケットを特定し、内容をＭＡＣ ＲＬＰパケットへと再び組み立てる。ＭＡＣレイヤユニット３６は次いで、ＲＬＰキュー３８内へ挿入するためのビデオパケットとオーディオパケットとを提供するために、ＭＡＣ ＲＬＰパケットの内容を再び組み立てる。ＲＴＰ／ＲＴＣＰ／ＵＤＰ／ＩＰ／ＰＰＰユニット４０は、付随するヘッダ情報を除去し、ビデオパケットをビデオデコーダ４２に、オーディオパケットをオーディオデコーダ４４に提供する。ビデオデコーダ４２は、表示装置を駆動する際に使用するためのビデオデータのストリームを生成するために、ビデオデータフレームを復号する。オーディオデコーダ４４は、例えばオーディオスピーカーを介してユーザに提示するためのオーディオ情報を生成するために、オーディオデータを復号する。
[0052]上で述べられたように、システム１０は、例えば送信チャネル１６を介したビデオ電話のために、双方向のビデオ及びオーディオの送信を提供することができる。幾つかの例では、チャネル１６のネットワークリンクレートが変化するときに問題が発生することがあり、この変化は、Ｗｉ−Ｆｉ、セルラー又は他のネットワークリンクにおいて発生し得る。以下で図２に関してより詳細に説明されるように、レートの変動に対処し、場合によってはキューの管理を実行するために、１つ又は複数のバッファがネットワーク機器に含まれ得る。
[0053]例えば、ある送信レート（例えば、ビデオエンコーダ２０によって使用される符号化レート）を伴うＶＴフローは、リンクレートの突然の下落に遭遇することがあり、これはフローのボトルネックを生み得る。このリンクレートの下落に対するエンコーダシステム１２における反応の遅延（例えば、これは、受信機の混雑制御フィードバックの遅延、送信機から受信機への戻り経路上での遅延、レート適合反応の遅延などによって引き起こされ得る）が原因で、送信レートはある時間の期間、リンクレートを大きく上回ったままであり得る。これは、ボトルネックリンクで増加したバッファレベルをもたらし、従って、エンコーダシステム１２とデコーダシステム１４との間のエンドツーエンドの遅延の増加（また更にはパケットの損失）をもたらすことがあり、これは、ＶＴセッションの品質体験に悪影響を与えることがある。
[0054]データがチャネル１６を通じて送信される際のビットレートをエンコーダシステム１２が下げた（例えば、送信レートを下げた）後で、蓄積された遅延がある時間残り得る。例えば、幾つかの事例では、蓄積された遅延が残る時間の長さは、送信レートと低減されたリンクレート（例えば、ボトルネックを引き起こすリンクレート）との間の差に依存し得る。送信レートの低下が小さすぎる場合、蓄積された遅延は比較的ゆっくり下がり、このことはデコーダシステム１４におけるユーザ体験に影響を与え得る。保守的な送信レートの手法は、一貫して、推定されるリンクレートよりもはるかに低いレートで送信することである。しかしながら、この手法は、チャネル１６におけるリンクの不十分な使用と、全体的なビデオ品質体験の低下とをもたらし得る。
[0055]本開示で説明される技法によれば、ビデオエンコーダ２０は、チャネル１６の条件に基づいて、ビデオ発信源１８からビデオを符号化することができる。具体的には、ビデオエンコーダ２０は、チャネル１６における帯域幅の低下に基づいて、符号化レート（本明細書では送信レートとも呼ばれる）を下げることができる。符号化レートを下げることは、本明細書ではダウンスイッチングと呼ばれ得る。エンコーダシステム１２は、チャネル１６におけるリンクレートの大幅な下落が検出された後で、例えば、デコーダシステム１４において生成された受信機側の混雑制御フィードバックメッセージがエンコーダシステム１２において受信された後で、ビデオエンコーダ２０において符号化されたデータの送信レートを一時的に下げることができる。
[0056]一例では、本開示の態様によれば、エンコーダシステム１２は最初に、第１のビットレートでチャネル１６を通じてデータを送信することができる。エンコーダシステム１２は、第１のネットワークリンクレートから第２のネットワークリンクレートへのチャネル１６におけるネットワークリンクレートの低下を特定することができる。幾つかの例では、エンコーダシステム１２は、デコーダシステム１４から受信された１つ又は複数の報告に基づいて、ネットワークリンクレートの低下を特定することができる。
[0057]本開示の態様によれば、ネットワークリンクレートの低下を特定したことに応答して、エンコーダシステム１２は、チャネル１６を通じてデータを送信する際に用いるべき回復ビットレートを決定することができ、ここで回復ビットレートは第２のネットワークリンクレートより低い。エンコーダシステム１２はまた、ネットワークリンクレートの低下の特定の時間と、ネットワークリンクレートの低下の推定される実際の時間との間の差を含む、バッファリング時間長を決定することができる。例えば、上で述べられたように、遅延を特定することと、ビデオエンコーダ２０がデータを符号化する際のレートを調整することとに関連付けられる、何らかの反応時間があり得る。エンコーダシステム１２は、ビデオエンコーダ２０が符号化レートを特定してより低いレートへと調整するための時間を有するまで、初期の（より高い）ネットワークリンクにおいて、又はその近くで、ビデオエンコーダ２０によって符号化されたデータをバッファリングすることができる。
[0058]エンコーダシステム１２は、回復ビットレート及びバッファリング時間長に基づいて、回復ビットレートでデータを送信すべき回復レート時間長を決定することができる。エンコーダシステムは次いで、決定された回復レート時間長の間、回復ビットレートでデータを送信することができる。このようにして、本技法は、蓄積されたエンドツーエンドの遅延を比較的速く減らすことができ、エンドツーエンドの遅延が減らされた後で利用可能なリンクレートを使用することによって（例えば、より長い時間の期間、低減されたレートに送信レートを維持する場合よりも）、ユーザ体験の品質を守ることができる。例示を目的としてエンコーダシステム１２に関して説明されたが、上で述べられた技法の幾つかは、追加で、又は代替的に、デコーダシステム１４によって実行され得ることを理解されたい。
[0059]本開示の更に他の技法は、ネットワーク条件に基づいて、データが符号化されるレートをアップスイッチングする（例えば、上げる）ための技法を含む。例えば、「Ｄｉｓｃｕｓｓｉｏｎ ｏｎ Ｕｐｓｗｉｔｃｈ Ｐｒｉｎｃｉｐａｌｓ」、ＳＡ４ ＭＴＳＩ ＳＷＧ Ｃｏｎｆｅｒｅｎｃｅ Ｃａｌｌ Ｎｏ． ４ ｏｎ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｖｉｄｅｏ Ｒａｔｅ Ａｄａｐｔａｔｉｏｎ ｏｆ Ｅ２ＥＭＴＳＩ−Ｓ４、Ｓ４−ＡＨＭ２１５、２０１４年６月２４日（「ＡＨＭ２１５」）の発表において、アップスイッチングについての幾つかの問題が特定された。「Ｒｅｐｏｒｔ ｆｒｏｍ ＳＡ４ ＭＴＳＩ ＳＷＧ Ｃｏｎｆｅｒｅｎｃｅ Ｃａｌｌ Ｎｏ． ４ ｏｎ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｖｉｄｅｏ Ｒａｔｅ Ａｄａｐｔａｔｉｏｎ ｏｆ Ｅ２ＥＭＴＳＩ−Ｓ４ （２０１４年６月２４日）」、Ｔｄｏｃ Ｓ４ （１４）０７６８において記載されているように、アップスイッチングの原則について合意する前に、電話会議からの新たな着想について研究するために、さらなる議論が必要であると思われた。
[0060]一般に、ＡＨＭ２１５において発表されたモデルは、ランプアッププロービングモデルに依存し、これには、プローブがチャネル条件に一致していないときに、プロービングがシステムに遅延をもたらし得るという欠点があり得る。よりロバストなモデルは、デコーダシステム１４などの受信機が、システムに余剰の能力があり得るかどうかを決定するためにチャネル１６の状態を受動的に測定することを可能にすることである。これに基づいて、デコーダシステム１４は、システムの持続可能なレートのより正確な推定を行うことができる。
[0061]ＡＨＭ２１５において発表されたモデルはまた、２段階の手法を提案しており、この手法では、エンコーダシステム１２はまず、さらなる能力があり得るかどうかを確認するためにチャネルをプローブする。プロービング段階が成功すると、ビデオエンコーダ２０は、「ランプアップ段階(ramp-up phase)」の間にレートをより積極的に上げることができる。そのようなモデルは、比較的大量の混雑をシステムにもたらす可能性があり、それは、データレートの微増を伴う成功したプローブは、システムがその後非常に大幅な増加を処理できることを暗示し得ないためである。実際には、ビデオエンコーダ２０のレートをシステムの能力と一致するように増加するとき、よりロバストな手法は、まずレートを比較的大きく増加して、その後、チャネル１６によってサポートされる持続可能なレートへとレートが収束するにつれてよりステップを小さくすることである。
[0062]上で説明された方式で持続可能なレートに収束する、潜在的によりロバストな手法に従うには、適合を駆動するエンティティ（例えば、送信機（エンコーダシステム１２）又は受信機（デコーダシステム１４））は、システムの持続可能なレートの推定値を有しなければならない。送信機は、エンドツーエンドのチャネル条件を検出するためにＲＴＣＰ受信機報告に依存することがあり、全体のスループットを計算することができるが、それでも、ＲＴＣＰ報告によりいくらかの測定遅延がある。受信機は、全体のスループットと、予定される再生に対してデコーダシステム１４におけるパケットの到着が遅すぎるとはされない、許容され得る追加の遅延の量との両方を、計算することができる。従って、受信機において計算される関連する尺度が送信機に直接送信される場合、受信機により駆動される適合モデルは、実現され、よりロバストであることがあり、最小限の適合の実行を決定する際に使用されるべきである。
[0063]本開示の態様によれば、デコーダシステム１４は、チャネル１６において帯域幅が十分に利用されていないと決定すると、受信機により駆動されるレートアップスイッチング技法を実施することができる。例えば、本開示の態様によれば、デコーダシステム１４は、ビデオエンコーダ２０に符号化レートを上げるように促すデータをエンコーダシステム１２に提供することができる。
[0064]幾つかの例では、本開示の態様によれば、デコーダシステム１４は、データがデコーダシステム１４によって受信される時間と受信されたデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータを決定することができる。許容可能超過遅延パラメータは、ユーザ体験が影響を受けない、例えば、適切な時間に復号され、再生されるのにデータの到着が遅すぎない、チャネル１６によって対応可能な遅延の量を示すことができる。デコーダシステム１４はまた、決定された許容可能超過遅延パラメータに基づいて、データがエンコーダシステム１２からデコーダシステム１４に送信される際に用いるべきビットレートを増加するための、送信機ビットレートの増加を決定することができる。デコーダシステム１４はまた、送信機ビットレートの増加の指示をエンコーダシステム１２に送信することができる。
[0065]このように、デコーダシステム１４は、ネットワークに混雑をもたらすことなくユーザ体験を改善するために、制御された方式でビデオフローの平均ビットレートを制御することができる。この技法は、パケット損失をもたらし得るエンドツーエンドの遅延を大きく増加することを避け得る。
[0066]図２は、本開示の技法によるビデオ発信源レート適合を実施し得るエンコーダシステム１２を示すブロック図である。図２に示されるように、ビデオエンコーダ２０は、ビデオ符号化エンジン５０と、ビデオバッファ５２と、ビデオレートコントローラ５４とを含む。ビデオエンコーダ２０はまた、ネットワークリンクレート情報５６を受信し、これはデコーダシステム１４によって準備され得る（以下でより詳細に説明される）。
[0067]ビデオ符号化エンジン５０は、ビデオ発信源１８からビデオデータを取得し、ビデオレートコントローラ５４によって制御されるレートでビデオデータを符号化する。ビデオ符号化エンジン５０は次いで、符号化されたビデオをビデオバッファ５２に収納する。ビデオレートコントローラ５４は、ビデオバッファ５２の充満度を監視し、充満度に少なくとも一部基づいて、ビデオ符号化エンジン５０によって適用されるビデオ符号化レートを制御することができる。加えて、以下でより詳細に説明されるように、ビデオレートコントローラ５４は、ネットワークリンクレート情報５６及び／又はチャネル１６（図１）の条件と関連付けられる他のデータに基づいて、レートを制御することができる。
[0068]幾つかの例では、ビデオエンコーダ２０は、全般にコーデックとは独立なビデオ発信源レート制御方式を提供することができる。例えば、ビデオエンコーダ２０は、ＨＥＶＣ、ＭＰＥＧ４、ＩＴＵ Ｈ．２６３、又はＩＴＵ Ｈ．２６４に従って、ビデオ符号化のために適合され得る。加えて、ビデオエンコーダ２０は、ＤＳＰ又は組込み型論理コア内での実装の影響を受けやすいことがある。幾つかの実施形態では、ビデオエンコーダ２０（例えば、ビデオエンコーダ２０のビデオレートコントローラ５４）は、モデルベースのレート制御を適用することができ、例えば、ビデオブロックレート制御をｒｈｏ領域において適用することができる。例えば、フレームビット計画が特定のビデオフレームに対して確立されると、フレームビット計画は、フレーム内のビデオブロック、例えばコーディングユニット（ＣＵ）及び／又はマクロブロック（ＭＢ）の間で、ｒｈｏ領域レート制御を使用して割り振られ得る。個々のＭＢのためのｒｈｏ領域値は次いで、量子化パラメータ（ＱＰ）値にマッピングされ得る。
[0069]本開示の態様によれば、ビデオレートコントローラ５４は、ネットワーク条件に基づいてレートダウンスイッチングを実行することができる。例えば、ビデオ符号化エンジン５０は最初に、チャネル１６（図１）などのトランスポート媒体を通じた送信のために、第１のビットレートでデータを符号化することができる。ビデオレートコントローラ５４は、第１のネットワークリンクレートから第２のネットワークリンクレートへのネットワークリンクレートの低下を特定することができる。幾つかの例では、ビデオレートコントローラ５４は、ビデオエンコーダ２０において、ネットワークリンクレートの低下をフィードバックから特定することができる。他の例では、ビデオレートコントローラ５４は、ネットワークリンクレート情報５６に基づいて、ネットワークリンクレートの低下を特定することができる。
[0070]ネットワークリンクレートの低下を特定したことに応答して、ビデオレートコントローラ５４は、第２の（低減された）ネットワークリンクレートより低い、ビデオエンコーダ２０のための回復ビットレートを決定することができる。回復レートは、ネットワークリンクレートの低下の実際の時間とネットワークリンクレートの低下の同定との間にバッファリングされたデータ量を減らすために使用され得る。そのようなバッファリングされたデータを減らすことは、ユーザ体験が受信機機器において影響を受けないように支援する。従って、ビデオレートコントローラ５４は、ビデオエンコーダ２０においてバッファリングされたデータの量を少なくするために低減されたネットワークリンクレートをアンダーシュートする、ビデオエンコーダ２０において使用するための回復ビットレートを決定することができる。
[0071]本開示の態様によれば、ビデオレートコントローラ５４は、アンダーシュート係数に基づいて回復レートを決定することができる。ビデオレートコントローラ５４は、第１のネットワークリンクレートと低減されたネットワークリンクレートとの間の差に基づいてアンダーシュート係数を決定することができる。即ち、ビデオレートコントローラ５４は、ネットワークリンクレートの低下の大きさに基づいて変化する大きさを有する、アンダーシュート係数を決定することができる。従って、ネットワークリンクレートの低下が比較的大きい場合、ビデオレートコントローラ５４は、比較的大きいアンダーシュート係数を決定し得る。同様に、ネットワークリンクレートの低下が比較的小さい場合、ビデオレートコントローラ５４は、比較的小さいアンダーシュート係数を決定し得る。
[0072]幾つかの例では、ビデオレートコントローラ５４は、回復レートを決定するために低減されたネットワークリンクレートに適用され得るアンダーシュート係数を決定することができる。例えば、ビデオレートコントローラ５４は、小数のアンダーシュート係数を決定することができ、小数のアンダーシュート係数を低減されたネットワークリンクレートに適用して回復レートを決定することができる。一例では、ビデオレートコントローラ５４は、ネットワークリンクレートの低下の大きさの、第１のネットワークリンクレートに対する比に基づいてアンダーシュート係数を決定することができる。
[0073]本開示の態様によれば、ビデオレートコントローラ５４は、ネットワークリンクレートの低下の特定の時間とネットワークリンクレートの低下の推定される実際の時間との間で、どれだけのデータがビデオエンコーダ２０においてバッファリングされるか（又は、より一般的には、ビデオエンコーダ２０を含む送信機機器においてどれだけのデータがバッファリングされるか）に基づいて、回復レートをどれだけ長く維持するかを決定することができる。送信機機器においてデータをバッファリングすることと関連付けられる時間は、バッファリング時間長（又はバッファリング時間期間）と本明細書では呼ばれ得るが、回復レートを維持すべき時間長は、回復レート時間長（又は低減レート時間期間）と本明細書では呼ばれ得る。幾つかの事例では、回復レート時間長はまた、アンダーシュート時間長又は期間と呼ばれることがあり、それは、回復レート時間長の間にデータが符号化されるレートがネットワークリンクレートより低いからである。
[0074]以下で図５に関してより詳細に説明されるように、ビデオレートコントローラ５４は、様々な方法でバッファリング時間長を決定することができる。例えば、ビデオレートコントローラ５４は、ビデオエンコーダ２０を組み込む送信機機器と受信機機器との間のラウンドトリップ時間（ＲＴＴ）、ダウンリンク遅延（例えば、受信機から送信機への遅延）、レート適合反応の遅延に関するデータ、混雑制御の反応遅延（例えば、リンクレートの推定）、メッセージ生成遅延（ＲＴＣＰパケット）などの、ネットワークリンクレート情報５６からバッファリング時間長を推定することによって、バッファリング時間長を決定することができる。ネットワークリンクレート情報５６は、ビデオエンコーダ２０において利用可能であることがあり、又は受信機機器によってビデオエンコーダ２０に信号伝達され得る。
[0075]本開示の態様によれば、ビデオレートコントローラ５４は、回復レートの大きさに基づいて、及びバッファリング時間長に基づいて、回復レート時間長を決定することができる。幾つかの例では、ビデオレートコントローラ５４は、（例えば、回復レートによって示されるような）ネットワークリンクレートの低下の大きさと、（例えば、バッファリング時間長によって示されるような）ネットワークリンクレートの低下に反応することと関連付けられる時間の量とに比例する、バッファリング時間長を決定することができる。即ち、ネットワークリンクレートの低下が比較的大きい場合、及び／又は、ネットワークリンクレートの低下に反応するのに必要な時間が比較的長い場合、ビデオレートコントローラ５４は、それに比例して長い回復レート時間長を決定することができる。同様に、ネットワークリンクレートの低下が比較的小さい場合、及び／又は、ネットワークリンクレートの低下に反応するのに必要な時間が比較的短い場合、ビデオレートコントローラ５４は、それに比例して短い回復レート時間長を決定することができる。
[0076]本開示の他の態様によれば、ビデオレートコントローラ５４は、加えて、又は代替的に、ネットワーク条件に基づいてレートのアップスイッチングを実行することができる。例えば、ビデオレートコントローラ５４は、デコーダシステム１４（図１）を含む機器などの受信機機器からネットワークリンクレート情報５６を受信することができる。ビデオレートコントローラ５４は、データを符号化するためにビデオ符号化エンジン５０によって使用されている送信レート（例えば、符号化レート）をアップスイッチングするために、受信されたネットワークリンクレート情報５６を使用することができる。
[0077]幾つかの例では、受信されたネットワークリンクレート情報５６は、ビデオ符号化エンジン５０によって実施されている特定の要求された送信レート（例えば、符号化レート）を含み得る。他の例では、受信されたネットワークリンクレート情報５６は、現在の送信レート（例えば、送信レートステップ）に追加されるべき、レートステップの増加を含み得る。いずれの場合でも、図３に関して以下でより詳細に説明されるように、受信されたネットワークリンクレート情報５６は、パケットが再生されるように予定される前に受信機機器においてパケットが受信されたことを示す超過遅延パラメータに基づき得る。そのような事例において、ビデオレートコントローラ５４は、パケットの到着時間が受信機機器におけるパケットの予定された再生時間とより厳密に一致するまで、ビデオ符号化エンジン５０によって使用される送信レートを上げることができる。
[0078]図２の技法は図２の特定のコンポーネント（例えば、ビデオレートコントローラ５４など）によって行われるものとして説明されるが、そのような技法は、追加で、又は代替的に、ビデオ電話機器の１つ又は複数の他のコンポーネントによって実行され得ることを理解されたい。例として、ＭＴＳＩ機器は、レート適合及び／又は混雑制御を実行するために、上で説明された幾つかの技法を行うことができる。この例では、ＭＴＳＩ機器は次いで、ビデオエンコーダにおいて適切なレート制御を実施するためにデータをビデオレートコントローラ５４に提供することができる。
[0079]図３は、本開示の技法によるビデオ発信源レート適合を実施し得るビデオデコーダシステム１４を示すブロック図である。図３に示されるように、ビデオデコーダ４２は、符号化されたデータとネットワークリンクレート情報６０とを受信し、ビデオ復号エンジン６２と、再生決定ユニット６４と、レート制御データ６８を生成するレート制御ユニット６６とを含む。
[0080]ビデオ復号エンジン６２は、符号化されたデータとネットワークリンクレート情報６０とを受信し、ビデオデータを復号する。幾つかの例では、ビデオ復号エンジン６２は、１つ又は複数のビデオコード化規格に適合し得る。上で述べられたように、例示的なビデオコード化規格は、ＨＥＶＣ、ＭＰＥＧ４、ＩＴＵ Ｈ．２６３、又はＩＴＵ Ｈ．２６４を含む。
[0081]ビデオデータが受信されるレートは、ビデオエンコーダ２０（図２）のビデオレートコントローラ５４によって制御され得る。本開示の態様によれば、レート制御ユニット６６は、符号化レートを調整する際に使用するためのレート制御データ６８を準備して、ビデオエンコーダ２０に送信することができる。幾つかの例では、レート制御データ６８は、送信機機器においてダウンスイッチングを実行するためのデータを含み得る。他の例では、加えて、又は代替的に、レート制御データ６８は、送信機機器においてアップスイッチングを実行するためのデータを含み得る。レート制御ユニット６６は、送信機機器が適切なビットレートを決定することを可能にするデータを準備することができ、又は、送信機機器から特定のビットレートを要求することができる。
[0082]ダウンスイッチングのためのデータを準備することに関して、本開示の態様によれば、レート制御ユニット６６は、図２に関して上で説明されたのと同様の方式で、回復レート、バッファリング時間長及び／又は回復レート時間長を決定することができる。他の例では、レート制御ユニット６６は、回復レート、バッファリング時間長及び／又は回復レート時間長を決定するために送信機機器（エンコーダシステム１２など）によって使用され得る、データを生成し、及び／又はメッセージを送信することができる。
[0083]一例では、レート制御ユニット６６は、ネットワークリンクレートの低下を示すために、順方向チャネルの推定される最大ビットレートを伴う、送信機機器へのＲＴＣＰ一時最大メディアストリームビットレート要求（ＴＭＭＢＲ：Temporary Maximum Media Stream Bit Rate Request）メッセージを生成することができる。一般に、上で述べられたＲＦＣ５１０４に記載されるように、受信機、変換器又は混合器は、メディアストリームの最大ビットレートを与えられた値に、又はそれ未満に制限するように送信機に要求するために、ＴＭＭＢＲ（「ｔｉｍｂｅｒ」と呼ばれる）を使用することができる。一時最大メディアストリームビットレート通知（ＴＭＭＢＮ）は、メディア送信機を更に制約しないであろうＴＭＭＢＲを参加者が抑制するのを助けるためにメディア送信機が受信した、ＴＭＭＢＲで定義された制限の最も限定的なサブセットの、メディア送信機の現在の見方を含んでいる。
[0084]本開示の態様によれば、第１のレートから第２のより低いレートへの順方向チャネルの推定される最大ビットレートの変化は、ネットワークリンクレートの低下を示す。幾つかの例では、レート制御ユニット６６は、混雑が検出されると直ちに、又はほぼ直ちに、ＴＭＭＢＲを送信することができる（例えば、ＴＭＭＢＲメッセージを生成することと関連付けられるメッセージ生成遅延があり得る）。ＴＭＭＢＲメッセージが例示を目的に説明されるが、遅延／混雑を示す様々な他のメッセージが使用され得ることを理解されたい。
[0085]本明細書で説明されるバッファリング時間長を推定することで送信機機器を支援するために、レート制御ユニット６６は、ＲＴＣＰ受信機報告（ＲＲ：receiver report）メッセージを生成して送信することもできる。例えば、上で述べられたＲＦＣ３５５０において記載されるように、幾つかのＲＴＣＰパケットのタイプが、様々な制御情報を搬送するために使用され得る。送信機報告（ＳＲ：sender report）が、動作している送信機である参加者からの送信と受信の統計のために使用され得る。ＲＲは、動作している送信機ではない参加者からの受信統計のために、及び、３２個以上の発信源についての動作している送信機の報告のためのＳＲと組み合わせて、使用され得る。
[0086]本開示の態様によれば、レート制御ユニット６６は、ＴＭＭＢＲメッセージの後で、例えばＴＭＭＢＲメッセージの直後に、又はほぼ直後に、ＲＲメッセージを生成して送信することができる。この例では、送信機機器は、ＴＭＭＢＲメッセージとＲＲメッセージとを受信することができ、ＲＲに含まれる最後のＳＲのタイムスタンプ（ＬＳＲデータ）によってＲＲにおいて参照されるＳＲの送信の時間と、送信機機器によってＲＲが受信される時間との時間差として、バッファリング時間長の上限を決定することができる。言い換えると、レート制御ユニット６６は、ビットレート制限のための要求を示す第１のデータ（例えば、ＴＭＭＢＲメッセージ）と、メッセージが生成された時間を示す第２のデータ（例えば、ＬＳＲデータ）とを送信することができる。ＬＳＲデータは、発信源から最新のＲＴＣＰ ＳＲパケットの一部として受信された、６４ビットのネットワーク時間プロトコル（ＮＴＰ）タイムスタンプのうちの中間の３２ビットを含み得る。ＳＲがまだ受信されていない場合、ＬＳＲタイムスタンプフィールドは０に設定され得る。送信機機器は、上で述べられたデータを受信することができ、そのデータを使用してバッファリング時間長を決定することができ、バッファリング時間長はダウンスイッチングの間に使用され得る。
[0087]別の例では、２つの別の連続するメッセージ（例えば、ＴＭＭＢＲ及びＲＴＣＰ ＲＲ）を送信するのではなく、レート制御ユニット６６は、ＴＭＭＢＲデータとＲＴＣＰ ＲＲデータとを単一のＲＴＣＰメッセージへとグループ化することができ、単一のメッセージを送信機機器に送信することができる。最低でも、レート制御ユニット６６はＬＳＲデータを送信することができ、これは送信機機器がバッファリング時間長を推定することを可能にする。この例では、２つの別のメッセージを送信する場合よりも、メッセージサイズが減らされ得る。
[0088]幾つかの例では、レート制御ユニット６６は、送信機機器に送信すべき最後の受信されたＲＴＣＰ ＳＲのＬＳＲを、同じＬＳＲを有するＲＴＣＰ ＲＲを以前に送信していたとしても、使用することができる。レート制御ユニット６６がＲＲをまだ送信していない場合、レート制御ユニット６６は、完全なＲＲをＴＭＭＢＲと組み合わせることができる。他の例では、メッセージサイズを減らすために、レート制御ユニット６６は、ＬＳＲデータをＴＭＭＢＲと一緒に送信することだけが可能であり、送信機機器は、ＲＴＴを決定するためにＴＭＭＢＲを受信して使用することができる。更に別の例では、レート制御ユニット６６がすでにＲＲを送信していた場合、送信機機器は、最後の受信されたＲＲを受信した時間と新たなＲＲ（例えば、混雑が検出された後でレート制御ユニット６６によって送信されたＲＲ）を受信した時間との間の時間差として、バッファリング時間長をより正確に計算することができる。
[0089]レート制御ユニット６６はまた、回復レート時間長を決定し、及び／又は、回復レート時間長を決定するためにデータを生成して送信機機器に送信することができる。例えば、上で説明された技法の代わりに、又はそれに加えて、レート制御ユニット６６（又は送信機機器）は、回復レート時間長をいつ終了すべきか決定するために、ＲＴＣＰ ＲＲ到着間ジッタ（inter-arrival jitter data）を監視することができる。一般に、到着間ジッタデータは、タイムスタンプ単位で測定され、符号なしの整数として表される、ＲＴＰデータパケットの到着間の時間の統計的な分散の推定を与え得る。到着間ジッタＪは、パケットのペアのための送信機と比較された、受信機におけるパケット間隔の差分Ｄの標準偏差（平滑化された絶対値）として定義され得る。下の式（１）に示されるように、これは、２つのパケットの「相対送信時間」の差分と等価であり、相対送信時間は、パケットのＲＴＰタイムスタンプと、同じ単位で測定された到着の時間における受信機の時計との間の差分である。ＳｉがパケットｉからのＲＴＰタイムスタンプであり、Ｒｉがパケットｉに対するＲＴＰタイムスタンプ単位の到着の時間である場合、２つのパケットｉ及びｊに対して、Ｄは次のように表され得る。
D(i,j) = (Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si) (1)
[0090]本開示の態様によれば、到着間ジッタが０又は閾値未満になる場合、送信機機器は、レート低減を終了することができる（例えば、送信機機器は、低減されたレートからほぼネットワークリンクレートへと送信レートを上げることができる）。閾値は、定数であってよく、又はネットワーク条件の変化に適応してよい。幾つかの例では、送信機機器は、到着間ジッタが最小の時間の期間の間０又は閾値未満に維持されると、レート低減を終了することができる。幾つかの事例では、レート制御ユニット６６がＲＴＣＰ ＳＲとＲＲとを頻繁に信号伝達するほど、送信機機器は到着間ジッタをより正確に監視することができる。
[0091]更に別の例では、送信機機器（エンコーダシステム１２など）は遅延（例えば、ＲＴＴ）を監視することができ、送信機は、遅延が十分に低減されるまで、送信レートを低減されたレートに維持することができる。例えば、送信機機器は、バッファに記憶されているデータの量が閾値レベルを下回るまで、送信レートを低減されたレートに維持することができる。
[0092]本開示の他の技法によれば、再生決定ユニット６４は、受信されたビデオパケットを検査し、受信されたデータが予定された再生に対して早く到着しているか、時間通りに到着しているか、又は遅く到着しているかを決定することができる。予定された再生タイミングは、符号化されたデータを用いて示され得る。パケットが遅く到着している場合（例えば、パケットが受信／検査されるより前に再生時間がある場合）、レート制御ユニット６６は、送信ビットレートを下げるように送信機機器に要求することができる。幾つかの例では、レート制御ユニット６６は、選択されたレートを用いてＴＭＭＢＲメッセージを送信することができる。
[0093]幾つかの態様によれば、レート制御ユニット６６は、除去される必要のある超過遅延の量を決定し、レート制御ユニット６６によって測定されるような到着したビデオのデータレートとこの超過遅延パラメータを乗算することによって、残りのデータ（例えば、送信機機器においてバッファリングされたデータ）の量を推定することができる。言い換えると、レート制御ユニット６６は、データが受信／検査される時間とデータを用いて示される再生時間との間の差に基づいて、遅延を決定することができる。レート制御ユニット６６は次いで、データが受信されているビットレートとこの遅延時間を乗算して、送信機によってバッファリングされているデータの量を決定することができる。
[0094]幾つかの例では、レート制御ユニット６６は、システムがチャネルの混雑を解消することを可能にするために、ビデオデコーダ４２と送信機機器との間のトランスポート経路の持続可能なレート（例えば、ネットワークリンクの使用可能な帯域幅）より低い初期レートを（例えば、ＴＭＭＢＲメッセージにおいて）要求することができる。ある例では、レート制御ユニット６６は、システムが（変数Ｔ＿ｄｅｃｏｎｇｅｓｔによって示される）固定された量の時間でチャネルの混雑を解消することを可能にするのに十分低い初期レートを選択することができる。変数Ｒ＿ｓｕｓｔａｉｎがチャネルの持続可能なレートに等しい場合、変数ΔＤｅｌａｙは除去される必要のある遅延の量に等しく、そして、レート制御ユニット６６は最初に、以下の式（２）に従ってビットレートＲでデータを符号化するように送信機機器に要求することができる。
R = R_sustain (1- ΔDelay/T_decongest) (2)
要求されたビットレートを含むメッセージ（例えば、ＴＭＭＢＲメッセージ）を送信した後で、レート制御ユニット６６は、混雑解消時間（Ｔ＿ｄｅｃｏｎｇｅｓｔ）が経過するのを待つことができる。レート制御ユニット６６は次いで、ネットワークリンクによって持続可能なレート（Ｒ＿ｓｕｓｔａｉｎ）で、別の要求されたビットレート（例えば、追加のＴＭＭＢＲメッセージ）を送信することができ、こうして、混雑解消期間を終了する。
[0095]別の例では、レート制御ユニット６６、レートを上げるために別のメッセージ（例えば、追加のＴＭＭＢＲメッセージ）を送信しなくてよい。この例では、レート制御ユニット６６は、許容可能な遅延の量（例えば、所定の閾値より少ない遅延）を測定するのを単に開始することができる。遅延の量が必要とされるよりも小さい（例えば、適切に予定された再生のために必要とされるよりも早くパケットが到着している）とレート制御ユニット６６が決定する場合、レート制御ユニット６６は、送信機機器の符号化レートを増加する(increase)／上昇する(ramp up)するために、別のメッセージ（例えば、別のＴＭＭＢＲメッセージ）を送信することができる。
[0096]アップスイッチングに関して、送信機機器と受信機機器との間のチャネル（エンコーダシステム１２とデコーダシステム１４との間のチャネル１６（図１）など）が送信機機器によって十分に利用されていないとき、ビデオデコーダ４２へのビデオパケットの配信は、そのようなビデオパケットが実際に再生される（例えば、データを用いて示される再生時間の前に受信される）ことが必要になる前に発生する可能性が高い。そのような事例では、送信機レートは増加されてよく、幾つかの追加の遅延が、ユーザ体験に悪影響を与えることなくシステムにもたらされ得る。
[0097]送信経路にもたらされ得る超過ビットは、チャネル帯域幅がレート制御ユニット６６において測定される平均受信レートに等しい事例（例えば、利用可能な予備のチャネル帯域幅がない最悪の場合）では、以下の式（３）に従って計算され得る。
excess_bits = rate_increase_step * (RTT + receiver_detection_delay) (3)
ここで、ｅｘｃｅｓｓ＿ｂｉｔｓはシステムにもたらされる追加のビットを示し、ｒａｔｅ＿ｉｎｃｒｅａｓｅ＿ｓｔｅｐは符号化レートの増加を示し、ＲＴＴはラウンドトリップ時間を示し、ｒｅｃｅｉｖｅｒ＿ｄｅｔｅｃｔｉｏｎ＿ｄｅｌａｙは受信機によってシステムの遅延を検出することと関連付けられる遅延を示す（これは、本明細書で説明される技法のいずれかに従って決定され得る）。
[0098]幾つかの例では、レート制御ユニット６６は、以下の式（４）に従って、もたらされた超過ビット（ｅｘｃｅｓｓ＿ｂｉｔｓ）が原因の対応する最悪の場合の超過遅延（ｅｘｃｅｓｓ＿ｄｅｌａｙ）を決定することができる。
excess_delay = rate_increase_step * (RTT + receiver_detection_delay) / avg_receiving_rate
(4)
ここで、ｅｘｃｅｓｓ＿ｄｅｌａｙは送信機機器においてもたらされる遅延の量を示し、ｒａｔｅ＿ｉｎｃｒｅａｓｅ＿ｓｔｅｐは符号化レートの増加を示し、ＲＴＴは送信機機器とビデオデコーダ４２との間のラウンドトリップ時間を示し、ｒｅｃｅｉｖｅｒ＿ｄｅｔｅｃｔｉｏｎ＿ｄｅｌａｙはレート制御ユニット６６によってシステムの遅延を検出することと関連付けられる遅延を示し、ａｖｇ＿ｒｅｃｅｉｖｉｎｇ＿ｒａｔｅはデータがビデオデコーダ４２において受信されているレートを示す。
[0099]従って、幾つかの例では、本開示の態様によれば、ビデオデコーダ４２のレート制御ユニット６６は、特定のレート増加と関連付けられる超過ビットの数（例えば、ｅｘｃｅｓｓ＿ｂｉｔｓ）と、超過ビットの混入と関連付けられる遅延（例えば、ｅｘｃｅｓｓ＿ｄｅｌａｙ）とを決定することができる。
[0100]レート制御ユニット６６は、許容可能超過遅延パラメータに基づいて、レート増加の量を計算することができる。例えば、レート制御ユニット６６は、下の式（５）に従って、混雑及び／又は遅延をシステムにもたらすことなく送信レートがどれだけ送信機機器によって上げられ得るかを決定することができる。
rate_increase_step = allowable_excess_delay * avg_receiving_rate / (RTT +
receiver_detection_delay) (5)
ここで、ｒａｔｅ＿ｉｎｃｒｅａｓｅ＿ｓｔｅｐは送信レートが増加され得る量（送信機ビットレートの増加と呼ばれ得る）を示し、ａｌｌｏｗａｂｌｅ＿ｅｘｃｅｓｓ＿ｄｅｌａｙは許容可能超過遅延パラメータ（以下でより詳細に説明されるような）を示し、ａｖｇ＿ｒｅｃｅｉｖｉｎｇ＿ｒａｔｅはレート増加を決定する前にデータが受信されていた平均レートを示し、ＲＴＴはビデオデコーダ４２と送信機機器（ビデオエンコーダ２０など）との間のラウンドトリップ時間を示し、ｒｅｃｅｉｖｅｒ＿ｄｅｔｅｃｔｉｏｎ＿ｄｅｌａｙはビデオデコーダ４２において遅延を特定するために必要とされる時間の量を示す。幾つかの事例では、受信機検出遅延パラメータは、処理系依存（implementation dependent）であり得て、オフラインの試験において推定又は測定され得る。そのような受信機検出遅延が利用可能ではない場合、レート制御ユニット６６は、推定される反応遅延を使用するように構成されてよく、これは、レート制御ユニット６６が遅延を特定するために必要とされる時間の比較的保守的な推定であり得る。
[0101]送信機機器からビデオデコーダ４２を含む受信機機器への片道の遅延は一般に受信機機器には知られていないので、受信機機器は通常、許容可能超過遅延パラメータ（ａｌｌｏｗａｂｌｅ＿ｅｘｃｅｓｓ＿ｄｅｌａｙ）を計算するためにこれを使用することができない。代わりに、本開示の態様によれば、レート制御ユニット６６は、受信されたビデオパケットから許容可能な超過遅延の量を決定することができる。例えば、レート制御ユニット６６は、ビデオパケットがビデオデコーダ４２において受信及び／又は処理される時間を決定することができる。レート制御ユニット６６はまた、ビデオパケットと関連付けられるビデオデータが再生される（例えば、ユーザに表示される）ように設計される時間を決定することができる。レート制御ユニット６６は、パケットが受信及び／又は評価される時間と再生時間）との間の差に基づいて、許容可能超過遅延パラメータを決定することができる。
[0102]許容可能超過遅延パラメータは一般に、ユーザ体験に影響を与えることなくビットレートを増加するための基礎として、送信機機器によって利用され得る時間の量を示し得る。例えば、許容可能超過遅延パラメータは、ユーザ体験に影響を与えることなく、例えば、適切な時間に復号され、再生されるにはビデオデコーダ４２におけるデータの到着が遅くなりすぎるような、チャネル１６によってサポート可能ではないレートに送信レートを増加することなく、送信レートを増加するために使用され得る時間の量を示し得る。許容可能な超過遅延の尺度は、ユーザ体験の観点からはより正確であることがあり、それは、許容可能超過遅延パラメータは、受信されたパケット中のビデオ情報が劣化（例えば、ジッタ、スタッタリング、又はフレーム損失など）を伴わずに実際にユーザに表示され得るかどうかを直接示すからである。
[0103]本開示の態様によれば、上の分析に基づいて、レート制御ユニット６６は、アップスイッチングを実行するために、受信機機器及び送信機機器において以下の要件を課し得る。
・受信機は、パケットの到着を検査し、これを通常の予定された再生時間と比較して、送信経路にもたらされ得る許容可能な遅延の量：ａｌｌｏｗａｂｌｅ＿ｅｘｃｅｓｓ＿ｄｅｌａｙがあるかどうかを決定するものとする。
・受信機は、平均受信レート：ａｖｇ＿ｒｅｃｅｉｖｉｎｇ＿ｒａｔｅを計算するために、パケットの到着を検査するものとする。
・受信機は、ラウンドトリップ時間：ＲＴＴを計算するものとする。
・受信機は、以下のようにｒａｔｅ＿ｉｎｃｒｅａｓｅ＿ｓｔｅｐを計算するものとする。
rate_increase_step = allowable_excess_delay * avg_receiving_rate / (RTT + receiver_detection_delay)
・Ａｕｄｉｏ Ｖｉｓｕａｌ Ｐｒｏｖｉｄｅ ｗｉｔｈ Ｆｅｅｄｂａｃｋ（ＡＶＰＦ）ＲＴＣＰ送信規則によって許容されるとき、受信機は、
ｒａｔｅ＿ｉｎｃｒｅａｓｅ＿ｓｔｅｐ＞５％×ａｖｇ＿ｒｅｃｅｉｖｉｎｇ＿ｒａｔｅであることを検出するとき、一時最大メディアストリームビットレート要求（ＴＭＭＢＲ）を送信すべきであり、
ｒａｔｅ＿ｉｎｃｒｅａｓｅ＿ｓｔｅｐ＞１５％×ａｖｇ＿ｒｅｃｅｉｖｉｎｇ＿ｒａｔｅであることを検出するとき、ＴＭＭＢＲを送信するものとする。
・ＴＭＭＢＲメッセージを送信するとき、ＴＭＭＢＲ中のｒｅｑｕｅｓｔｅｄ＿ｒａｔｅは、
avg_receiving_rate + rate_increase_step
に等しくなければならず、
avg_receiving_rate + 0.80(rate_increase_step) <= requested_rate <=
avg_receiving_rate + rate_increase_step
であるものとする。
[0104]加えて、本開示の態様によれば、以下の要件が、アップスイッチングを実行するために送信機機器において課され得る。
・一時最大メディアストリームビットレート要求（ＴＭＭＢＲ）を受信すると、ビデオ送信機は、送信レートを５００ｍｓ以内にｒｅｑｕｅｓｔｅｄ＿ｒａｔｅにランプアップすべきであり、１秒以内にそれをランプアップするものとする。
[0105]上で述べられた「要件」は例示を目的に与えられており、本開示の技法は上で述べられた特定の値とは異なる値を使用しても適用され得ることを理解されたい。加えて、特定の技法が例示を目的に図３の特定のユニット（例えば、レート制御ユニット６６など）に帰せられているが、ビデオデコーダ４２の１つ又は複数の他のユニットがそのような技法を行うことを担い得ることを理解されたい。その上、ＶＴは双方向の通信フローであることが多いので、同様の技法は、順方向ネットワーク経路と逆方向ネットワーク経路の両方で、例えば、送信機機器（図２のビデオエンコーダ２０を組み込む機器など）として本明細書で指定される機器と、受信機機器（図３のビデオデコーダ４２を組み込む機器など）として本明細書で指定される機器の両方によって、適用され得る。
[0106]図４Ａ及び図４Ｂは、本開示によるビデオ発信源レート適合技法を示すグラフである。例えば、図４Ａは全般に、ネットワークリンクレートの低下を含む時間の間の、送信機機器（例えば、エンコーダシステム１２など）における符号化されたデータのビットレートを示す。図４Ｂは全般に、ネットワークリンクレートの低下と関連付けられる、結果として生じる遅延を示す。図４Ａ及び図４Ｂの技法はエンコーダシステム１２に関して説明されるが、本技法は様々な他のコンポーネントを有する様々な他の送信機機器によって行われ得ることを理解されたい。
[0107]図４Ａの例では、時刻ｔ0において、リンクレート（ネットワークリンクレート又は帯域幅とも呼ばれる）は、線８０によって示されるようにＲ0からＲ1へと低下し、ここで送信レート＝リンクレートである）。ネットワークリンクレートの低下に応答して、エンコーダシステム１２は送信レートを下げることができる。しかしながら、図４Ａの例に示されるように、破線８２によって示されるような、送信レートを下げることと関連付けられるｔ0からｔ1への応答遅延（ΔＴ）がある。応答遅延はバッファリング時間長としても本明細書では説明されることがあり、その時間の間、送信レートはネットワークリンクレートをオーバーシュートし、エンコーダシステム１２はネットワークリンクによって対処され得ないデータをバッファリングすることを担う。
[0108]図４Ｂの例において線８４によって示されるように、遅延（例えば、符号化されたデータが送信可能になることと、符号化されたデータが実際に送信される時間との間の時間）は、応答遅延（ΔＴ）の間にＤ0からＤ1へと相対的に速く増大する。即ち、遅延は、ネットワークリンクレートの低下の時間ｔ0と、ネットワークリンクレートの低下の特定の時間ｔ1との間に、Ｄ0からＤ1へと相対的に速く増大する。この遅延は、エンコーダシステム１２においてバッファリングされるデータの量に比例し得る。
[0109]時間ｔ1において、図４Ａ及び図４Ｂの例は、送信レート技法を分岐させることを示す。例えば、実線８０は、エンコーダシステム１２が送信レートをネットワークリンクレートに維持する第１の例を示す。例えば、ネットワークリンクレートの低下を特定すると、エンコーダシステム１２は、送信レートを元のレートＲ0から新たな低減されたネットワークリンクレートＲ1に下げる。この例では、対応する遅延は、実線８８によって示されるように比較的大きいままである。即ち、送信レートがネットワークリンクレートＲ1に設定されるので、バッファリングされたデータの量を減らすために用いる超過の帯域幅はない。
[0110]破線８２及び８６は、エンコーダシステム１２が、元のレートＲ0から、ネットワークリンクレートＲ1より低い低減されたレートＲUに送信を減らす、第２の例を示す。これは、ネットワークリンクレートを「アンダーシュートすること」として呼ばれ得る。この例では、エンコーダシステム１２は、決定された回復レート時間長（ΔＴu）の間、低減されたレートＲuを維持することができる。この時間の間、破線９０によって示されるように、エンコーダシステム１２は、時間ｔ2においてＤ1からＤ2に遅延を減らす。
[0111]本明細書で説明されるように、エンコーダシステム１２は、低減されたレート（ＲＵ）と、バッファリング時間長（ΔＴ）と、回復レート時間長（ΔＴu）とを、様々な技法を使用して決定することができる。一例では、エンコーダシステム１２は、式（１−ｆU）×Ｒ1に基づいて低減されたレートＲUを決定することができ、ここで、ｆUはアンダーシュート係数であり、Ｒ1は低減されたリンクレートであり、ｆUはレートアンダーシュート係数（１−ｆU）を決定し、０＜ｆU＜１であり、レートアンダーシュート係数は送信レートをリンクレートＲ1に関連付ける。幾つかの例では、ｆUは、ネットワークリンクレートの低下の大きさに依存することがあり、これは、式ΔＲ＝（Ｒ0−Ｒ1）によって表され得る。この例では、図４Ａに示されるように、Ｒ0は下げられる前の第１のネットワークリンクレートである。ネットワークリンクレートの低下の大きさΔＲが大きい場合、ｆUは比例して大きくなり得る。他の例では、ΔＲが小さい場合、以下の式（６）において示されるように、ｆUは比例して小さくなり得る。
fU = ΔR / R0 (6)
[0112]エンコーダシステム１２がバッファリング時間長（ΔＴ）の間にビットのすべてをバッファリングし、遅延に寄与している場合、エンコーダシステム１２は、以下の式（７）に基づいて回復レート時間長（ΔＴu）を決定することができる。
ΔTu = ΔT (R0-R1) / (fU R1) (7)
ここで、ΔＴuは回復レート時間長であり、ΔＴはバッファリング時間長を備え、Ｒ0は第１のネットワークリンクレートを備え、Ｒ1は第２の低減されたネットワークリンクレートを備え、ｆUはレート低減係数を備える。
[0113]幾つかの例では、エンコーダシステム１２は最小限のビットレート要件を適用することができる。最小限のビットレート要件は、ビデオエンコーダ２０の能力、ユーザ体験のための最小限のシステム要件などに基づき得る。エンコーダシステム１２が最小限のビットレート要件を適用する例では、ビデオエンコーダ２０は、最小限のビットレート要件をＲUに、従って、アンダーシュート係数ｆUにも適用することができる。例えば、エンコーダシステム１２は、低減されたレートＲUとアンダーシュート係数ｆUとを決定するために、以下の式（８）と（９）とを適用することができる。
RU >= Rmin (8)
fU <= 1-(Rmin/R1) with R1 > Rmin (9)
ここで、ＲUは低減されたビットレートであり、Ｒminは最小の符号化レートであり、Ｒ1は第２の低減されたネットワークリンクレートであり、ｆUはアンダーシュート係数である。
[0114]回復レート時間長（ΔＴu）の間、新たなレート値Ｒ2を搬送するＴＭＭＢＲメッセージがエンコーダシステム１２によって受信され、Ｒ2はＲ1よりはるかに大きく（例えば、Ｒ2はＲ1に１．２を乗じたもの以上である）、エンコーダシステム１２は回復レート時間長を短くすることができる。逆に、Ｒ2がＲ1より低い場合、エンコーダシステム１２は追加の又は延長された回復レート時間長を決定することができる。
[0115]一般に、図２及び図３に関して上で述べられたように、エンコーダシステム１２は、ＲＴＴ、ダウンリンク遅延（例えば、受信機から送信機への）、レート制御反応遅延についての知識、混雑制御の反応遅延（例えば、リンクレートの推定）、メッセージ生成遅延（例えば、ＲＴＣＰパケットを生成することと関連付けられる遅延）などのネットワーク情報から、バッファリング時間長（ΔＴ）を推定することができる。このネットワーク情報は、送信機側において利用可能であることがあり、又は、ビデオデコーダ４２（図３）を組み込む機器などの受信機機器によって、エンコーダシステム１２に信号伝達され得る。
[0116]図４Ａ及び図４Ｂの例は、例示を目的として、ステップ的な変化（例えば、Ｒ0とＲUの間での単一のレート変化を示すが、本技法は、アンダーシュートの形状がよりなだらかとなるように繰り返し適用され得ることを理解されたい。
[0117]図５は、本開示の技法による、バッファリング時間長を決定することを示す概念図である。図５の例では、送信機機器（例えば、エンコーダシステム１２など）は、時間１２０において、ＲＴＣＰ送信機報告（ＳＲ）を受信機機器（例えば、デコーダシステム１４など）に送信することができる。例えば、上で述べられたようなＲＦＣ３５５０において説明されたように、幾つかのＲＴＣＰパケットは、様々な制御情報を搬送するために使用され得る。送信機報告（ＳＲ）が、動作している送信機である参加者からの送信と受信の統計のために使用され得る。同様に、受信機報告（ＲＲ）は、動作している送信機ではない参加者からの受信統計のために、及び、３２個以上の発信源についての動作している送信機の報告のためのＳＲと組み合わせて、使用され得る。受信機機器は、時間１２２において、ＲＴＣＰ ＳＲを受信することができる。
[0118]受信機機器は、時間１２４において、順方向チャネルの推定される最大ビットレートで、ＲＴＣＰ ＴＭＭＢＲメッセージを送信機機器に送信することができる。幾つかの例では、メッセージを生成することと関連付けられる遅延があり得るが、受信機機器は、混雑を検出した直後にＴＭＭＢＲメッセージを送信することができる。ＴＭＭＢＲメッセージが例示を目的に説明されるが、遅延／混雑を示し得る様々な他のメッセージが使用され得る。
[0119]バッファリング時間長（ΔＴ）を推定することよって送信機機器を支援するために、受信機機器はまた、時間１２４において、ＲＴＣＰ ＲＲメッセージを送信することができる。本開示の態様によれば、受信機機器は、ＴＭＭＢＲメッセージの直後にＲＲメッセージを送信することができる。このようにして、送信機機器は、時間１２６において、ＴＭＭＢＲメッセージとＲＲメッセージとを受信することができ、ＲＲに含まれる最後のＳＲタイムスタンプ（ＬＳＲデータ）によってＲＲにおいて参照されるＳＲを送信することと、ＲＲが受信される時間との間の時間差として、バッファリング時間長（ΔＴ）１２８の上限を計算することができる。言い換えると、受信機機器は、ビットレート制限のための要求を示す第１のデータ（例えば、ＴＭＭＢＲメッセージ）と、メッセージが生成された時間を示す第２のデータ（例えば、ＬＳＲデータ）とを送信することができる。ＬＳＲデータは、発信源から最新のＲＴＣＰ ＳＲパケットの一部として受信された、６４ビットのネットワーク時間プロトコル（ＮＴＰ）タイムスタンプのうちの中間の３２ビットを含み得る。ＳＲがまだ受信されていない場合、ＬＳＲタイムスタンプフィールドは０に設定され得る。
[0120]別の例では、上で述べられたデータを伴う２つの別々の連続するメッセージ（例えば、ＴＭＭＢＲ及びＲＴＣＰ ＲＲ）を送信するのではなく、ＴＭＭＢＲデータ及びＲＴＣＰ ＲＲデータは、単一のＲＴＣＰメッセージへとグループ化され得る。最低でも、受信機機器はＬＳＲデータを送信することができ、これは送信機機器がバッファリング時間長（ΔＴ）１２８を推定することを可能にする。この例では、メッセージサイズが低減され得る。
[0121]受信機機器は、同じＬＳＲを有するＲＴＣＰ ＲＲメッセージを以前に送信していたとしても、最後の受信されたＲＴＣＰ ＳＲメッセージのＬＳＲを使用することができる。受信機機器がＲＲをまだ送信していなかった場合、受信機機器は、完全なＲＲメッセージをＴＭＭＢＲメッセージと組み合わせることができる。他の例では、メッセージサイズを減らすために、受信機機器は、ＴＭＭＢＲメッセージと一緒にＬＳＲデータを送信するだけであってよく、これはＲＴＴを計算するために使用され得る。
[0122]別の例では、受信機機器がすでにＲＲを送信していた場合、送信機機器は、最後の受信されたＲＲメッセージを受信することと、（例えば、混雑が検出された後に受信機によって送信された）新たなＲＲメッセージとの間の時間差として、バッファリング時間長（ΔＴ）１２８をより正確に計算することができる。
[0123]更に別の例では、送信機機器は遅延（例えば、ＲＴＴ）を監視することができ、送信機機器は、遅延が十分に低減されるまで、送信レートを低減されたレートＲuに保つことができる。例えば、送信機機器は、送信機機器のバッファに記憶されているデータの量が閾値レベルを下回るまで、送信レートを低減されたレートＲuに維持することができる。
[0124]図６Ａ及び図６Ｂは、ネットワークリンクレートの低下及び対応する遅延時間をそれぞれ示すグラフである。図６Ａのグラフは図４Ａの線８０と関連付けられ得るが、図６Ｂのグラフは図４Ｂの線８８と関連付けられ得る。例えば、図６Ａは破線によって示されるネットワーク帯域幅１４０（ネットワークリンクレートとも呼ばれる）と、実線によって示される送信レート１４２（符号化ビットレートとも呼ばれる）（例えば、キロバイト毎秒（ＫＢＰＳ）単位で測定される）とを示す。図６Ａに示されるように、送信機機器（例えば、エンコーダシステム１２など）は、帯域幅１４０と同じ、又は同様のレートの送信レート１４２でデータを符号化することができる。従って、帯域幅１４０が時間１４４において下げられるとき、送信機機器は、送信レート１４２を帯域幅１４０とほぼ同じ値に下げることができる。
[0125]図６Ｂの対応する遅延グラフに示されるように、帯域幅１４０の低下の後で、エンコーダシステム１２における遅延は、（例えば、ミリ秒（ＭＳ）単位で測定される）第１のレベル１４６から第２のレベル１４８に上げられ得る。本明細書で説明されるように、帯域幅が低下すると遅延は増え、それは、送信レート１４２を帯域幅１４０のレベルに下げることと関連付けられる反応時間があるからである。エンコーダシステム１２は、帯域幅１４０と一致するように送信レート１４２を減らす前の元の（より高い）レートで符号化されるバッファデータをバッファリングすることができる。図６Ｂに示されるように、遅延は、遅延を減らすための技法が適用されない場合、比較的長い時間長残り得る。
[0126]図７Ａ及び図７Ｂは、ネットワークリンクレートの低下及び対応する遅延時間をそれぞれ示すグラフである。図７Ａのグラフは図４Ａの線８２及び８６と関連付けられ得るが、図７Ｂのグラフは図４Ｂの破線９０と関連付けられ得る。例えば、図７Ａは破線によって示されるネットワーク帯域幅１６０（ネットワークリンクレートとも呼ばれる）と、実線によって示される送信レート１６２（符号化ビットレートとも呼ばれる）（例えば、キロバイト毎秒（ＫＢＰＳ）単位で測定される）とを示す。図７Ａに示されるように、送信機機器（例えば、エンコーダシステム１２など）は最初に、帯域幅１６０と同じ、又は同様のレートの送信レート１６２でデータを符号化することができる。
[0127]本開示の態様によれば、帯域幅１６０が時間１６４において下げられるとき、送信機機器は、帯域幅１６０より低い低減されたレートに送信レートを下げることができる。即ち、送信機機器は、帯域幅１６０の低下と関連付けられる遅延を減らすために、帯域幅１４０をアンダーシュートする送信レート１６２を決定することができる。本明細書で説明されるように、送信機機器は、本開示の技法に従って、バッファリング時間長、低減されたレート及び／又は回復レート時間長を決定することができる。
[0128]図７Ｂの対応する遅延グラフに示されるように、帯域幅１６０の低下の後で、エンコーダシステム１２における遅延は、（例えば、ミリ秒（ＭＳ）単位で測定される）第１のレベル１６６から第２のレベル１６８に上げられ得る。上で述べられたように、帯域幅が低下すると遅延は増え、それは、帯域幅１６０の低下に応答して送信レート１６２を下げることと関連付けられる反応時間があるからである。しかしながら、送信レート１６２を（帯域幅１６０をアンダーシュートする）低減されたレートに下げることによって、エンコーダシステム１２は、図６Ｂに示される例より高速に遅延を減らすことができる。
[0129]図８は、データが送信されるレートをダウンスイッチングするための例示的なプロセスを示す流れ図である。図８の例は、例示を目的にエンコーダシステム１２に関して説明される。しかしながら、図８のプロセスは様々な他の機器及び／又はプロセッサによって行われ得ることを理解されたい。
[0130]エンコーダシステム１２は、第１のレートでネットワークを通じてデータを符号化し送信することができる（１８０）。第１のレートでデータを送信する間に、エンコーダシステム１２は、第１のレートから第２のレートへのネットワークリンクレートの低下を特定することがある（１８２）。例えば、エンコーダシステム１２は、ネットワーク条件を監視し、及び／又は、ネットワークリンクレートの低下を示す１つ又は複数のメッセージを受信することができる。
[0131]エンコーダシステム１２は、第２の（低減された）ネットワークリンクレートより低い回復ビットレートを決定することができる（１８４）。例えば、エンコーダシステム１２は、新たなネットワークリンクレートをアンダーシュートする、データを符号化するためのビットレートを決定することができる。本開示の態様によれば、エンコーダシステム１２は、第１のネットワークリンクレートと低減されたネットワークリンクレートとの間の差に基づいて回復ビットレートを決定することができる。例えば、ネットワークリンクレートの低下が比較的大きい場合、エンコーダシステム１２は、比較的積極的な（例えば、低減されたレートをかなりのマージンでアンダーシュートする）回復ビットレートを決定することができる。同様に、ネットワークリンクレートの低下が比較的小さい場合、エンコーダシステム１２は、比較的保守的な（例えば、低減されたレートを比較的小さいマージンでアンダーシュートする）回復ビットレートを決定することができる。
[0132]エンコーダシステム１２はまた、反応遅延（例えば、ネットワークリンクレートの低下に応答して送信レートを下げることと関連付けられる時間）に基づいて、バッファリング時間長を決定することができる（１８６）。エンコーダシステム１２は、様々な方法でバッファリング時間長を決定することができる。例えば、エンコーダシステム１２は、エンコーダシステム１２と受信機機器との間のラウンドトリップ時間（ＲＴＴ）、ダウンリンク遅延、レート適合反応遅延、混雑制御の反応遅延、メッセージ生成遅延などのネットワーク情報からバッファリング時間長を推定することによって、バッファリング時間長を決定することができる。エンコーダシステム１２は、ネットワーク情報を独立に決定することができ、又は、受信機機器からネットワーク情報を受信することができる。
[0133]エンコーダシステム１２は次いで、回復ビットレートを維持すべき回復レート時間長を決定することができる（１８８）。幾つかの例では、エンコーダシステム１２は、回復レートの大きさに基づいて、及びバッファリング時間長に基づいて、回復レート時間長を決定することができる。幾つかの例では、エンコーダシステム１２は、（例えば、回復レートによって示されるような）ネットワークリンクレートの低下の大きさと、（例えば、バッファリング時間長によって示されるような）ネットワークリンクレートの低下に反応することと関連付けられる時間の量とに比例する、バッファリング時間長を決定することができる。
[0134]エンコーダシステム１２は、回復レート時間長の間、回復ビットレートでデータを送信することができる（１９０）。幾つかの例では、ネットワークリンクレートが回復レート時間長の間に上がる場合、エンコーダシステム１２は、回復レート時間長を早く終了することができ、より高い送信レートへとアップスイッチングすることができる。例に応じて、図８に関して説明された技法のいずれかの、幾つかの行為又はイベントは、異なる順序で実行されてよく、追加されてよく、統合されてよく、又は完全に除外されてよい（例えば、説明された行為又はイベントのすべてが技法の実践のために必要であるとは限らない）ことを理解されたい。
[0135]図９は、データが送信されるレートをアップスイッチングするための例示的なプロセスを示す流れ図である。図９の例は、例示を目的にデコーダシステム１４に関して説明される。しかしながら、図９のプロセスは様々な他の機器及び／又はプロセスによって行われ得ることを理解されたい。
[0136]デコーダシステム１４は、データが受信される時間を決定することができる（２００）。例えば、幾つかの事例では、デコーダシステム１４は、データがデコーダシステム１４において受信され、記憶される時間を特定することができる。他の事例では、デコーダシステム１４は、デコーダシステム１４によってデータが処理（例えば、復号）される時間を特定することができる。
[0137]デコーダシステム１４は、また、受信されたデータの再生時間を決定することができる（２０２）。例えば、受信されたデータは、データがユーザへの表示のために出力されることが意図される時間の指示を含み得る。従って、再生時間の指示は、出力のためにデータを編成する際にデコーダシステム１４を支援することができる。
[0138]デコーダシステム１４は、許容可能超過遅延パラメータを決定することができる（２０４）。例えば、デコーダシステム１４は、データが受信される時間と受信されたデータが再生されるように予定される時間との間の差に基づいて、許容可能超過遅延パラメータを決定することができる。本明細書で説明されるように、遅延は、データがネットワークリンクにわたる送信に利用可能であることと、データが送信機機器においてネットワークに実際に送信される時間との間の時間を指し得る。従って、許容可能超過遅延パラメータは、ユーザ体験が影響を受けないような、システムによって対応可能な遅延の量を示し得る。即ち、許容可能超過遅延パラメータは一般に、ユーザ体験に影響を与えることなくビットレートを上げるための基礎として、送信機機器によって利用され得る時間の量を示し得る。
[0139]デコーダシステム１４は次いで、送信機ビットレートの増加を決定することができる（２０６）。例えば、本開示の態様によれば、デコーダシステム１４は、許容可能超過遅延パラメータに基づいて送信機ビットレートの増加を決定することができる。即ち、デコーダシステム１４は、混雑をシステムにもたらすことなく送信レートがどれだけ送信機機器によって上げられ得るかを決定することができる。
[0140]幾つかの例では、デコーダシステム１４は、送信レートに追加されるべきステップ的なレートの増加を決定することができる。例えば、デコーダシステム１４は、許容可能超過遅延パラメータと、送信レートの増加を決定する前の、データが受信された現在の平均送信レート（例えば、現在の受信レート）とに基づいて、送信機ビットレートの増加を決定することができる。この例では、デコーダシステム１４は、持続可能なリンクレートを超えて（例えば、パケットの予定された再生時間の後に、パケットがデコーダシステム１４に到着するようなレートに）レートを上げることなく、現在の送信レートがどれだけ上げられ得るかを決定することができる。
[0141]幾つかの例では、デコーダシステム１４はまた、デコーダシステム１４と送信機機器（例えば、ラウンドトリップ時間）との間でメッセージを送信するために必要とされる時間の量及び／又はデコーダシステム１４において遅延を特定することと関連付けられる遅延を考慮することができる。例えば、デコーダシステム１４は、ラウンドトリップ時間とデコーダシステム１４において遅延を検出するための時間との合計に対する、受信機レートと乗じられた許容可能超過遅延パラメータの比に基づいて、送信機ビットレートの増加を決定することができる。
[0142]デコーダシステム１４は次いで、送信機レートの増加の指示を送信することができる（２０８）。例えば、デコーダシステム１４は、送信機機器が送信レートに追加すべき、送信機機器に対するステップ的な送信機レートの増加を表すデータを送信することができる。別の例では、デコーダシステム１４は、送信機機器の送信レートの増加を包含する要求された送信レートを表すデータを送信することができる。
[0143]幾つかの例では、デコーダシステム１４は、送信機ビットレートの増加が閾値の量を超えるときだけ、送信機ビットレートの増加の指示を送信し得る。例えば、デコーダシステム１４は、送信機ビットレートの増加を所定の閾値と比較することができる。一例では、デコーダシステム１４は、送信機ビットレートの増加が受信レートの約５パーセントを超えるときだけ、送信機ビットレートの増加の指示を送信し得る。別の例では、デコーダシステム１４は、送信機ビットレートの増加が受信レートの約１５パーセントを超えるときだけ、送信機ビットレートの増加の指示を送信し得る。他の閾値又は百分率も可能である。
[0144]例に応じて、図９に関して説明された技法のいずれかの、幾つかの行為又はイベントは、異なる順序で実行されてよく、追加されてよく、統合されてよく、又は完全に除外されてよい（例えば、説明された行為又はイベントのすべてが技法の実践のために必要であるとは限らない）ことを理解されたい。
[0145]本明細書で説明される幾つかの例が特定の観点（例えば、「送信機機器」又は「受信機機器」によって実行されること）に関して説明されてきたが、本開示の技法はこのようには限定されないことを理解されたい。例えば、上で述べられたように、ＶＴは双方向の通信フローであることが多い。従って、同様の技法は、順方向と逆方向の両方のネットワーク経路上で、例えば「送信機機器」と「受信機機器」の両方によって適用され得る。その上、幾つかの機器が例示を目的にある観点に関して示され説明されているが、本明細書で説明される機器は示されたものよりも多数又は少数のコンポーネントを有し得ることを理解されたい。例として、送信機機器は、ビデオエンコーダ２０（図２）とビデオデコーダ４２（図３）の両方を組み込むことができ、説明された技法の各々をそれらに対して実行することができる。
[0146]１つ又は複数の例では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、又はそれらの任意の組合せで実行され得る。ソフトウェアで実行される場合、機能は、１つ又は複数の命令又はコードとしてコンピュータ可読媒体上に記憶されるか、若しくはコンピュータ可読媒体を介して送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、データ記憶媒体などの有形媒体に対応する、コンピュータ可読記憶媒体を含み得るか、又は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を可能にする任意の媒体を含む通信媒体を含み得る。このようにして、コンピュータ可読媒体は、全般に、（１）非一時的である有形コンピュータ可読記憶媒体、又は（２）信号若しくは搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明された技法の実装のための命令、コード及び／又はデータ構造を取り出すために、１つ又は複数のコンピュータ若しくは１つ又は複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0147]限定ではなく例として、そのようなコンピュータ可読記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ（登録商標）、ＣＤ−ＲＯＭもしくは他の光ディスク記憶装置、磁気ディスク記憶装置もしくは他の磁気記憶機器、フラッシュメモリ、又は、命令又はデータ構造の形式で所望のプログラムコードを記憶するために使用されコンピュータによってアクセスされ得る任意の他の媒体を備え得る。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。例えば、命令が、ウェブサイト、サーバ又は他のリモート発信源から、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線（ＤＳＬ）又は赤外線、無線及びマイクロ波などのワイヤレス技術を使用して送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、ＤＳＬ又は赤外線、無線及びマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体及びデータ記憶媒体は、接続、搬送波、信号又は他の一時的媒体を含まないが、代わりに非一時的有形記憶媒体を対象とすることを理解されたい。本明細書で使用されるディスク（disk）及びディスク（disc）は、コンパクトディスク（disc）（ＣＤ）、レーザーディスク（登録商標）（disc）、光ディスク（disc）、デジタル多用途ディスク（disc）（ＤＶＤ）、フロッピー（登録商標）ディスク（disk）及びＢｌｕ−ｒａｙ（登録商標）ディスク（disc）を含み、ここで、ディスク（disk）は、通常、データを磁気的に再生し、ディスク（disc）は、データをレーザーで光学的に再生する。上記の組合せもコンピュータ可読媒体の範囲に含まれるべきである。
[0148]命令は、１つ又は複数のデジタル信号プロセッサ（ＤＳＰ）、汎用マイクロプロセッサ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブル論理アレイ（ＦＰＧＡ）又は他の等価な集積回路もしくはディスクリート論理回路のような、１つ又は複数のプロセッサによって実行され得る。従って、本明細書で使用される「プロセッサ」という用語は、前述の構造又は本明細書で説明された技法の実装に好適な任意の他の構造のいずれかを指し得る。加えて、幾つかの態様では、本明細書で説明された機能は、符号化及び復号のために構成された専用ハードウェア及び／又はソフトウェアのユニット若しくはモジュール内で与えられるか、又は複合コーデックに組み込まれ得る。また、本技法は、１つ又は複数の回路又は論理要素中で完全に実行され得る。
[0149]本開示の技法は、ワイヤレスハンドセット、集積回路（ＩＣ）又はＩＣのセット（例えば、チップセット）を含む、多種多様な機器又は装置において実装され得る。本開示では、開示される技法を実行するように構成された機器の機能的態様を強調するために、様々なコンポーネント、モジュール又はユニットが説明されたが、それらのコンポーネント、モジュール、又はユニットは、必ずしも異なるハードウェアユニットによる実現を必要とするとは限らない。むしろ、上で説明されたように、様々なユニットが、適切なソフトウェア及び／又はファームウェアとともに、上で説明された１つ又は複数のプロセッサを含めて、コーデックハードウェアユニットにおいて組み合わされるか、又は相互動作可能なハードウェアユニットの集合によって与えられ得る。
[0150]様々な例が、説明された。これら及び他の例は以下の特許請求の範囲内にある。
以下に本願発明の当初の特許請求の範囲に記載された発明を付記する。
［Ｃ１］
データを処理する方法であって、
第１のビットレートでネットワークを介してデータを送信することと、
第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定することとを備える、方法。
［Ｃ２］
前記回復ビットレートを決定することが、前記ネットワークリンクレートの前記低下の大きさに基づくアンダーシュート係数を使用して前記回復ビットレートを決定することを備える、Ｃ１に記載の方法。
［Ｃ３］
前記第１のネットワークリンクレートと前記第２のネットワークリンクレートとの間の差として前記アンダーシュート係数を決定することと、前記第１のネットワークリンクレートによって前記差を除することとを更に備える、Ｃ２に記載の方法。
［Ｃ４］
前記回復ビットレートを決定することが、１と前記アンダーシュート係数との間の差と乗じられた前記第２のネットワークリンクレートとして前記回復ビットレートを決定することを備える、Ｃ３に記載の方法。
［Ｃ５］
前記アンダーシュートレート及び前記バッファリング時間長に基づいて前記低減されたレート時間期間を決定することが、式
ΔT u = ΔT (R 0 -R 1 ) / (f U R 1 )
に基づいて前記回復レート時間長を決定することを備え、ΔＴ u が前記回復レート時間長を表し、ΔＴが前記バッファリング時間長を表し、Ｒ 0 が前記第１のネットワークリンクレートを表し、Ｒ 1 が前記第２の低減されたネットワークリンクレートを表し、ｆ U が前記ネットワークリンクレートの前記低下に基づく前記アンダーシュート係数を表す、Ｃ２に記載の方法。
［Ｃ６］
前記回復ビットレートを決定することが最小ビットレートより大きい回復ビットレートを決定することを備え、前記最小ビットレートが前記データを符号化するように構成されるエンコーダの符号化ビットレートに基づく、Ｃ１に記載の方法。
［Ｃ７］
前記回復レート時間長の間に前記データを送信する間に、前記第２のネットワークリンクレートから第３のネットワークリンクレートへの前記ネットワークリンクレートの増加を特定することと、
前記ネットワークリンクレートの前記増加を特定したことに応答して、前記回復ビットレートより高いビットレートへ前記回復ビットレートを増加することとを更に備える、Ｃ１に記載の方法。
［Ｃ８］
前記バッファリング時間長を決定することが、ラウンドトリップ時間（ＲＴＴ）データ、受信機機器から送信機機器へのダウンリンク遅延と関連付けられるデータ、レート制御反応遅延と関連付けられるデータ、混雑制御の反応遅延と関連付けられるデータ又はメッセージ生成遅延と関連付けられるデータの少なくとも１つに基づいて、前記バッファリング時間長を決定することを備える、Ｃ１に記載の方法。
［Ｃ９］
それらの間で前記データが送信される、送信機機器から受信機機器への順方向チャネルの推定された最大ビットレートを示すデータを受信することと、
受信品質フィードバックを示すデータを受信することとを更に備え、
前記バッファリング時間長を決定することが、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて、前記バッファリング時間長を決定することを備える、Ｃ１に記載の方法。
［Ｃ１０］
前記推定された最大ビットレートを示す前記データを受信することが、一時最大メディアストリームビットレート要求（ＴＭＭＢＲ）メッセージを受信することを備え、前記受信品質フィードバックを示す前記データを受信することが、受信機報告（ＲＲ）メッセージを受信することを備える、Ｃ９に記載の方法。
［Ｃ１１］
前記推定された最大ビットレートを示す前記データを受信し、前記受信品質フィードバックを示す前記データを受信することが、前記推定された最大ビットレートを示す前記データと、前記受信品質フィードバックを示す前記データとを含む単一のメッセージを受信することを備える、Ｃ９に記載の方法。
［Ｃ１２］
前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて前記バッファリング時間長を決定することが、第１のメッセージが受信機機器に送信される時間と、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データが受信される時間との間の差を決定することを備える、Ｃ９に記載の方法。
［Ｃ１３］
前記データが符号化されたビデオデータを備え、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信することを更に備え、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信することが、前記符号化されたビデオデータの前記ビットレートを決定された前記回復レート時間長の間前記回復ビットレートに下げるようにレート制御を実行することを備える、Ｃ１に記載の方法。
［Ｃ１４］
データを処理するための機器であって、
データを記憶するように構成されたメモリと、
１つ以上のプロセッサとを備え、前記１つ以上のプロセッサが、
第１のビットレートでネットワークを介して前記データを送信し、
第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定し、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定する
ように構成される、機器。
［Ｃ１５］
前記回復ビットレートを決定するために、前記１つ以上のプロセッサが、前記ネットワークリンクレートの前記低下の大きさに基づくアンダーシュート係数を使用して前記回復ビットレートを決定するように構成される、Ｃ１４に記載の機器。
［Ｃ１６］
前記１つ以上のプロセッサが更に、前記第１のネットワークリンクレートと前記第２のネットワークリンクレートとの間の差として前記アンダーシュート係数を決定し、前記第１のネットワークリンクレートによって前記差を除するように構成される、Ｃ１５に記載の機器。
［Ｃ１７］
前記回復ビットレートを決定するために、前記１つ以上のプロセッサが、１と前記アンダーシュート係数との間の差と乗じられた前記第２のネットワークリンクレートとして前記回復ビットレートを決定するように構成される、Ｃ１６に記載の機器。
［Ｃ１８］
前記アンダーシュートレート及び前記バッファリング時間長に基づいて前記低減されたレート時間期間を決定するために、前記１つ以上のプロセッサが、式
ΔT u = ΔT (R 0 -R 1 ) / (f U R 1 )
に基づいて前記回復レート時間長を決定するように構成され、ΔＴ u が前記回復レート時間長を表し、ΔＴが前記バッファリング時間長を表し、Ｒ 0 が前記第１のネットワークリンクレートを表し、Ｒ 1 が前記第２の低減されたネットワークリンクレートを表し、ｆ U が前記ネットワークリンクレートの前記低下に基づく前記アンダーシュート係数を表す、Ｃ１５に記載の機器。
［Ｃ１９］
前記回復ビットレートを決定するために、前記１つ以上のプロセッサが、最小ビットレートより大きい回復ビットレートを決定するように構成され、前記最小ビットレートが前記データを符号化するように構成されるエンコーダの符号化ビットレートに基づく、Ｃ１４に記載の機器。
［Ｃ２０］
前記１つ以上のプロセッサが更に、
前記回復レート時間長の間に前記データを送信する間に、前記第２のネットワークリンクレートから第３のネットワークリンクレートへの前記ネットワークリンクレートの増加を特定し、
前記ネットワークリンクレートの前記増加を特定したことに応答して、前記回復ビットレートより高いビットレートへ前記回復ビットレートを増加するように構成される、Ｃ１４に記載の機器。
［Ｃ２１］
前記バッファリング時間長を決定するために、前記１つ以上のプロセッサが、ラウンドトリップ時間（ＲＴＴ）データ、受信機機器から送信機機器へのダウンリンク遅延と関連付けられるデータ、レート制御反応遅延と関連付けられるデータ、混雑制御の反応遅延と関連付けられるデータ又はメッセージ生成遅延と関連付けられるデータの少なくとも１つに基づいて、前記バッファリング時間長を決定するように構成される、Ｃ１４に記載の機器。
［Ｃ２２］
前記１つ以上のプロセッサが更に、
それらの間で前記データが送信される、送信機機器から受信機機器への順方向チャネルの推定された最大ビットレートを示すデータを受信し、
受信品質フィードバックを示すデータを受信するように構成され、
前記バッファリング時間長を決定するために、前記１つ以上のプロセッサが、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて、前記バッファリング時間長を決定するように構成される、Ｃ１４に記載の機器。
［Ｃ２３］
前記推定された最大ビットレートを示す前記データを受信するために、前記１つ以上のプロセッサが、一時最大メディアストリームビットレート要求（ＴＭＭＢＲ）メッセージを受信するように構成され、前記受信品質フィードバックを示す前記データを受信するために、前記１つ以上のプロセッサが、受信機報告（ＲＲ）メッセージを受信するように構成される、Ｃ２２に記載の機器。
［Ｃ２４］
前記推定された最大ビットレートを示す前記データを受信し、前記受信品質フィードバックを示す前記データを受信するために、前記１つ以上のプロセッサが、前記推定された最大ビットレートを示す前記データと、前記受信品質フィードバックを示す前記データとを含む単一のメッセージを受信するように構成される、Ｃ２２に記載の機器。
［Ｃ２５］
前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて前記バッファリング時間長を決定するために、前記１つ以上のプロセッサが、第１のメッセージが受信機機器に送信される時間と、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データが受信される時間との間の差を決定するように構成される、Ｃ２２に記載の機器。
［Ｃ２６］
前記データが符号化されるビデオデータを備え、前記１つ以上のプロセッサが更に、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信するように構成され、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信するために、前記１つ以上のプロセッサが、前記符号化されたビデオデータの前記ビットレートを決定された前記回復レート時間長の間前記回復ビットレートに下げるようにレート制御を実行するように構成される、Ｃ１４に記載の機器。
［Ｃ２７］
集積回路、
マイクロプロセッサ、又は
ワイヤレス通信機器の少なくとも１つを備える、Ｃ１４に記載の機器。
［Ｃ２８］
データを処理するための装置であって、
第１のビットレートでネットワークを介してデータを送信するための手段と、
第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定するための手段と、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定するための手段と、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定するための手段と、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定するための手段とを備える、装置。
［Ｃ２９］
実行されると、１つ以上のプロセッサに、
第１のビットレートでネットワークを介してデータを送信させ、
第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定させ、
前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定させ、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定させ、
前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定させる
命令を記憶した、非一時的コンピュータ可読媒体。

Claims (25)

  1. データを処理する方法であって、
    第１のビットレートでネットワークを介してデータを送信することと、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信するための回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定することとを備え、ここにおいて、前記回復ビットレートを決定することが、前記ネットワークリンクレートの前記低下の大きさに基づくアンダーシュート係数を使用して前記回復ビットレートを決定することを備える、
    方法。
  2. 前記第１のネットワークリンクレートと前記第２のネットワークリンクレートとの間の差として前記アンダーシュート係数を決定することと、前記第１のネットワークリンクレートによって前記差を除することとを更に備える、請求項１に記載の方法。
  3. 前記回復ビットレートを決定することが、１と前記アンダーシュート係数との間の差と乗じられた前記第２のネットワークリンクレートとして前記回復ビットレートを決定することを備える、請求項２に記載の方法。
  4. 前記回復ビットレート及び前記バッファリング時間長に基づいて回復レート時間長を決定することが、式
    ΔＴu＝ΔＴ（Ｒ0−Ｒ1）／（ｆU Ｒ1）
    に基づいて前記回復レート時間長を決定することを備え、ここにおいてΔＴ ｕ が前記回復レート時間長を表し、ΔＴが前記バッファリング時間長を表し、Ｒ0が前記第１のネットワークリンクレートを表し、Ｒ1が前記第２のネットワークリンクレートを表し、ｆUが前記ネットワークリンクレートの前記低下の前記大きさに基づく前記アンダーシュート係数を表す、請求項１に記載の方法。
  5. データを処理する方法であって、
    第１のビットレートでネットワークを介してデータを送信することと、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定することとを備え、ここにおいて、前記回復ビットレートを決定することが最小ビットレートより大きい回復ビットレートを決定することを備え、前記最小ビットレートがオーディデータ及びビデオデータの少なくとも１つのデータを符号化するように構成されるエンコーダの符号化ビットレートに基づく、方法。
  6. データを処理する方法であって、
    第１のビットレートでネットワークを介してデータを送信することと、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定することと、
    前記回復レート時間長の間に前記データを送信する間に、前記第２のネットワークリンクレートから第３のネットワークリンクレートへの前記ネットワークリンクレートの増加を特定することと、
    前記ネットワークリンクレートの前記増加を特定したことに応答して、前記回復ビットレートより高いビットレートへ前記回復ビットレートを増加することと、
    を備える、方法。
  7. データを処理する方法であって、
    第１のビットレートでネットワークを介してデータを送信することと、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定することとを備え、ここにおいて、前記バッファリング時間長を決定することが、受信機機器から送信機機器へのダウンリンク遅延と関連付けられるデータ、レート制御反応遅延と関連付けられるデータ、混雑制御の反応遅延と関連付けられるデータ又はメッセージ生成遅延と関連付けられるデータの少なくとも１つに基づいて、前記バッファリング時間長を決定することとを備える、方法。
  8. データを処理する方法であって、
    第１のビットレートでネットワークを介してデータを送信することと、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定すること、
    それらの間で前記データが送信される、送信機機器から受信機機器への順方向チャネルの推定された最大ビットレートを示すデータを受信することと、
    受信品質フィードバックを示すデータを受信することとを、備え、
    前記バッファリング時間長を決定することが、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて、前記バッファリング時間長を決定することを備える、方法。
  9. 前記推定された最大ビットレートを示す前記データを受信することが、一時最大メディアストリームビットレート要求（ＴＭＭＢＲ）メッセージを受信することを備え、前記受信品質フィードバックを示す前記データを受信することが、受信機報告（ＲＲ）メッセージを受信することを備える、請求項８に記載の方法。
  10. 前記推定された最大ビットレートを示す前記データを受信し、前記受信品質フィードバックを示す前記データを受信することが、前記推定された最大ビットレートを示す前記データと、前記受信品質フィードバックを示す前記データとを含む単一のメッセージを受信することを備える、請求項８に記載の方法。
  11. 前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて前記バッファリング時間長を決定することが、第１のメッセージが受信機機器に送信される時間と、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データが受信される時間との間の差を決定することを備える、請求項８に記載の方法。
  12. データを処理する方法であって、
    第１のビットレートでネットワークを介してデータを送信することと、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定することと、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定することと、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定することと、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定することとを備え、ここにおいて前記データが符号化されたビデオデータを備え、前記方法は、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信することを更に備え、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信することが、前記符号化されたビデオデータの前記回復ビットレートを決定された前記回復レート時間長の間の前記回復ビットレートに下げるようにレート制御を実行することを備える、方法。
  13. データを処理するための機器であって、
    データを記憶するように構成されたメモリと、
    １つ以上のプロセッサとを備え、前記１つ以上のプロセッサが、
    第１のビットレートでネットワークを介して前記データを送信し、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定し、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定し、
    前記回復ビットレートを決定するために、前記ネットワークリンクレートの前記低下の大きさに基づくアンダーシュート係数を使用して前記回復ビットレートを決定する
    ように構成される、機器。
  14. 前記１つ以上のプロセッサが更に、前記第１のネットワークリンクレートと前記第２のネットワークリンクレートとの間の差として前記アンダーシュート係数を決定し、前記第１のネットワークリンクレートによって前記差を除するように構成される、請求項１３に記載の機器。
  15. 前記回復ビットレートを決定するために、前記１つ以上のプロセッサが、１と前記アンダーシュート係数との間の差と乗じられた前記第２のネットワークリンクレートとして前記回復ビットレートを決定するように構成される、請求項１４に記載の機器。
  16. 前記回復ビットレート及び前記バッファリング時間長に基づいて前記回復レート時間長を決定するために、前記１つ以上のプロセッサが、式
    ΔT u = ΔT (R 0 -R 1 ) / (f U R 1 )
    に基づいて前記回復レート時間長を決定するように構成され、ΔＴ u が前記回復レート時間長を表し、ΔＴが前記バッファリング時間長を表し、Ｒ 0 が前記第１のネットワークリンクレートを表し、Ｒ 1 が前記第２のネットワークリンクレートを表し、ｆ U が前記ネットワークリンクレートの前記低下の前記大きさに基づく前記アンダーシュート係数を表す、請求項１３に記載の機器。
  17. データを処理するための機器であって、
    データを記憶するように構成されたメモリと、
    １つ以上のプロセッサとを備え、前記１つ以上のプロセッサが、
    第１のビットレートでネットワークを介して前記データを送信し、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定し、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定し、ここにおいて、前記回復ビットレートを決定するために、前記１つ以上のプロセッサが、最小ビットレートより大きい回復ビットレートを決定するように構成され、前記最小ビットレートがオーディオデータ及びビデオデータの少なくとも１つのデータを符号化するように構成されるエンコーダの符号化ビットレートに基づく、機器。
  18. データを処理するための機器であって、
    データを記憶するように構成されたメモリと、
    １つ以上のプロセッサとを備え、前記１つ以上のプロセッサが、
    第１のビットレートでネットワークを介して前記データを送信し、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定し、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定し、
    前記回復レート時間長の間に前記データを送信する間に、前記第２のネットワークリンクレートから第３のネットワークリンクレートへの前記ネットワークリンクレートの増加を特定し、
    前記ネットワークリンクレートの前記増加を特定したことに応答して、前記回復ビットレートより高いビットレートへ前記回復ビットレートを増加するように構成される、
    機器。
  19. データを処理するための機器であって、
    データを記憶するように構成されたメモリと、
    １つ以上のプロセッサとを備え、前記１つ以上のプロセッサが、
    第１のビットレートでネットワークを介して前記データを送信し、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定し、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定するように構成され、
    前記バッファリング時間長を決定するために、前記１つ以上のプロセッサが、受信機機器から送信機機器へのダウンリンク遅延と関連付けられるデータ、レート制御反応遅延と関連付けられるデータ、混雑制御の反応遅延と関連付けられるデータ又はメッセージ生成遅延と関連付けられるデータの少なくとも１つに基づいて、前記バッファリング時間長を決定するように構成される、機器。
  20. データを処理するための機器であって、
    データを記憶するように構成されたメモリと、
    １つ以上のプロセッサとを備え、前記１つ以上のプロセッサが、
    第１のビットレートでネットワークを介して前記データを送信し、
    第１のネットワークリンクレートから第２のネットワークリンクレートへの前記ネットワークのネットワークリンクレートの低下を特定し、
    前記ネットワークリンクレートの前記低下を特定したことに応答して、前記ネットワークを介して前記データを送信する際に用いるべき回復ビットレートを決定し、ここにおいて、前記回復ビットレートは前記第２のネットワークリンクレートより低い、
    送信機機器が、前記ネットワークリンクレートの前記低下の前記特定の時間と、前記ネットワークリンクレートの前記低下の推定される実際の時間との間の差に基づいて、バッファリング時間長を決定し、
    前記回復ビットレート及び前記バッファリング時間長に基づいて、前記回復ビットレートで前記データを送信すべき回復レート時間長を決定し、
    それらの間で前記データが送信される、送信機機器から受信機機器への順方向チャネルの推定された最大ビットレートを示すデータを受信し、
    受信品質フィードバックを示すデータを受信し、
    前記バッファリング時間長を決定するために、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて、前記バッファリング時間長を決定するように構成される、機器。
  21. 前記推定された最大ビットレートを示す前記データを受信するために、前記１つ以上のプロセッサが、一時最大メディアストリームビットレート要求（ＴＭＭＢＲ）メッセージを受信するように構成され、前記受信品質フィードバックを示す前記データを受信するために、前記１つ以上のプロセッサが、受信機報告（ＲＲ）メッセージを受信するように構成される、請求項２０に記載の機器。
  22. 前記推定された最大ビットレートを示す前記データを受信し、前記受信品質フィードバックを示す前記データを受信するために、前記１つ以上のプロセッサが、前記推定された最大ビットレートを示す前記データと、前記受信品質フィードバックを示す前記データとを含む単一のメッセージを受信するように構成される、請求項２０に記載の機器。
  23. 前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データに基づいて前記バッファリング時間長を決定するために、前記１つ以上のプロセッサが、第１のメッセージが受信機機器に送信される時間と、前記推定された最大ビットレートを示す前記データ及び前記受信品質フィードバックを示す前記データが受信される時間との間の差を決定するように構成される、請求項２０に記載の機器。
  24. 前記データが符号化されるビデオデータを備え、前記１つ以上のプロセッサが更に、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信するように構成され、決定された前記回復レート時間長の間前記回復ビットレートで前記データを送信するために、前記１つ以上のプロセッサが、前記符号化されたビデオデータの前記回復ビットレートを決定された前記回復レート時間長の間前記回復ビットレートに下げるようにレート制御を実行するように構成される、請求項１３に記載の機器。
  25. 集積回路、
    マイクロプロセッサ、又は
    ワイヤレス通信機器の少なくとも１つを備える、請求項１３に記載の機器。
JP2018028790A 2014-07-29 2018-02-21 ビデオ電話における遅延の低減 Active JP6420006B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US201462030513P 2014-07-29 2014-07-29
US62/030,513 2014-07-29
US14/811,491 2015-07-28
US14/811,491 US9426418B2 (en) 2014-07-29 2015-07-28 Reducing delay in video telephony

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2017504781A Division JP2017530584A (ja) 2014-07-29 2015-07-29 ビデオ電話における遅延の低減

Publications (2)

Publication Number Publication Date
JP2018139407A JP2018139407A (ja) 2018-09-06
JP6420006B2 true JP6420006B2 (ja) 2018-11-07

Family

ID=55181425

Family Applications (3)

Application Number Title Priority Date Filing Date
JP2017504792A Active JP6602842B2 (ja) 2014-07-29 2015-07-29 ビデオ電話における受信機で駆動されるアップスイッチング
JP2017504781A Ceased JP2017530584A (ja) 2014-07-29 2015-07-29 ビデオ電話における遅延の低減
JP2018028790A Active JP6420006B2 (ja) 2014-07-29 2018-02-21 ビデオ電話における遅延の低減

Family Applications Before (2)

Application Number Title Priority Date Filing Date
JP2017504792A Active JP6602842B2 (ja) 2014-07-29 2015-07-29 ビデオ電話における受信機で駆動されるアップスイッチング
JP2017504781A Ceased JP2017530584A (ja) 2014-07-29 2015-07-29 ビデオ電話における遅延の低減

Country Status (11)

Country Link
US (2) US9438853B2 (ja)
EP (2) EP3175584B1 (ja)
JP (3) JP6602842B2 (ja)
KR (2) KR102366630B1 (ja)
CN (2) CN106576081B (ja)
AU (1) AU2015296540B2 (ja)
BR (2) BR112017001040B1 (ja)
CA (1) CA2953711C (ja)
ES (2) ES2673701T3 (ja)
HU (2) HUE037155T2 (ja)
WO (2) WO2016019015A1 (ja)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2942958B1 (en) * 2013-01-07 2018-03-21 NEC Corporation Coding unit split signaling for pcm coded blocks
US9438853B2 (en) * 2014-07-29 2016-09-06 Qualcomm Incorporated Receiver driven up-switching in video telephony
CN107113024A (zh) * 2014-11-19 2017-08-29 领特投资两合有限公司 链路丢失检测
WO2016126735A2 (en) * 2015-02-02 2016-08-11 Accelerated Media Technologies, Inc. Systems and methods for electronic news gathering
CN106937073B (zh) * 2015-12-29 2019-10-15 展讯通信（上海）有限公司 基于VoLTE的视频通话码率调整方法、装置及移动终端
US10492085B2 (en) 2016-01-15 2019-11-26 Qualcomm Incorporated Real-time transport protocol congestion control techniques in video telephony
JP6724517B2 (ja) * 2016-04-14 2020-07-15 日本電気株式会社 ビットレート指示装置、ビットレート指示方法、及び、ビットレート指示プログラム
US10321849B2 (en) * 2016-10-13 2019-06-18 Etectrx, Inc. System for ingestion event monitoring and method for detecting ingestion events with high accuracy
US12238353B2 (en) * 2018-10-03 2025-02-25 Qualcomm Incorporated Service description for streaming media data
EP3881591A4 (en) * 2018-11-14 2021-12-15 ZTE Corporation SYSTEMS AND METHODS FOR DETERMINING COMMUNICATION PARAMETERS FOR NON-TERRESTRIAL NETWORKS
CN110351595B (zh) * 2019-07-17 2023-08-18 北京百度网讯科技有限公司 一种缓冲处理方法、装置、设备和计算机存储介质
CN110740284A (zh) * 2019-10-30 2020-01-31 中电福富信息科技有限公司 一种基于网络状况调节手机视频通话动态码率的方法
CN112565224B (zh) * 2020-11-26 2022-08-19 北京经纬恒润科技股份有限公司 一种视频处理方法及装置
CN116601932B (zh) * 2020-12-16 2026-02-06 华为技术有限公司 一种网络拥塞管理方法以及相关装置
US11936698B2 (en) * 2022-01-21 2024-03-19 Verizon Patent And Licensing Inc. Systems and methods for adaptive video conferencing
US20230396357A1 (en) * 2022-06-01 2023-12-07 Qualcomm Incorporated Indication of network condition at a remote ue
US11902659B1 (en) 2022-08-25 2024-02-13 Benjamin Slotznick Computer program product and method for auto-focusing a lighting fixture on a person in a venue who is wearing, or carrying, or holding, or speaking into a microphone at the venue
CN115499374B (zh) * 2022-11-08 2023-03-24 腾讯科技（深圳）有限公司 一种参数调节方法和相关装置
US12184558B1 (en) * 2022-12-16 2024-12-31 Amazon Technologies, Inc. Bandwidth estimation adaption for network stalls
CN118573574A (zh) * 2023-02-28 2024-08-30 抖音视界有限公司 带宽估计方法、装置、电子设备及存储介质
US20250191105A1 (en) * 2023-12-11 2025-06-12 Qualcomm Incorporated Rendering delay aware packet pacing for real time multimedia applications

Family Cites Families (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5063562A (en) * 1990-05-23 1991-11-05 International Business Machines Corporation Flow control for high speed networks
KR950005150B1 (ko) * 1992-03-23 1995-05-18 조명언 휴대용 tv 겸용 영상모니터장치
US6335922B1 (en) * 1997-02-11 2002-01-01 Qualcomm Incorporated Method and apparatus for forward link rate scheduling
US6450954B1 (en) * 1999-11-01 2002-09-17 New England Medical Center Hospitals, Inc. Method of randomizing patients in a clinical trial
JP2004007361A (ja) * 2001-10-11 2004-01-08 Nippon Telegr & Teleph Corp <Ntt> データ送信制御方法及びこの方法のプログラム並びにこれを用いるデータ送信装置
US7379546B2 (en) 2004-03-03 2008-05-27 King Fahd University Of Petroleum And Minerals Method for XZ-elliptic curve cryptography
US8416694B2 (en) 2004-06-22 2013-04-09 Telefonaktiebolaget Lm Ericsson (Publ) Network feedback method and device
CN101002192A (zh) * 2004-07-27 2007-07-18 索尼株式会社 具有传输差错恢复的家庭网络系统
US8977063B2 (en) 2005-03-09 2015-03-10 Qualcomm Incorporated Region-of-interest extraction for video telephony
US7701851B2 (en) 2005-07-20 2010-04-20 Vidyo, Inc. System and method for the control of the transmission rate in packet-based digital communications
GB2430124B (en) * 2005-09-09 2008-01-09 Toshiba Res Europ Ltd Quantum communication system
US8111720B2 (en) * 2007-01-09 2012-02-07 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus to indicate maximum scheduling delay for jitter buffer implementations
US7760642B2 (en) * 2007-03-12 2010-07-20 Citrix Systems, Inc. Systems and methods for providing quality of service precedence in TCP congestion control
US7957307B2 (en) * 2007-03-14 2011-06-07 Microsoft Corporation Reducing effects of packet loss in video transmissions
US20080239953A1 (en) * 2007-03-28 2008-10-02 Honeywell International, Inc. Method and apparatus for minimizing congestion in gateways
US8626896B2 (en) * 2007-12-13 2014-01-07 Dell Products, Lp System and method of managing network connections using a link policy
WO2009081871A1 (ja) * 2007-12-20 2009-07-02 Ntt Docomo, Inc. 移動局、基地局装置、通信制御方法及び移動通信システム
BRPI0822489B1 (pt) * 2008-03-12 2020-10-06 Telefonaktiebolaget Lm Ericsson (Publ) Método para adaptar uma taxa alvo atual de um sinal de vídeo transmitido de um provedor de vídeo para um receptor de vídeo, dispositivo para calcular uma nova taxa alvo de um sinal de vídeo transmitido a partir de um provedor de vídeo, e, meio legível por computador
US20090305715A1 (en) 2008-06-04 2009-12-10 Motorola, Inc. Channel quality reporting in a wireless communication system
US8325754B2 (en) * 2008-10-16 2012-12-04 Soongsil University Research Consortium Techno-Park Method for transmitting network data
CN101582852B (zh) * 2009-06-10 2012-04-11 中兴通讯股份有限公司 一种网络拥塞管理的方法及系统
US8537699B2 (en) * 2009-06-16 2013-09-17 Qualcomm Incorporated Managing video adaptation algorithms
US8199665B2 (en) * 2009-11-30 2012-06-12 Samsung Electronics Co., Ltd Apparatus and method for scheduling service based on network delay
US9276832B2 (en) * 2011-03-20 2016-03-01 King Abdullah University Of Science And Technology Buffer sizing for multi-hop networks
US9119111B2 (en) * 2011-08-12 2015-08-25 Alcatel Lucent Method and apparatus for controlling wireless uplink sessions
CN103999414B (zh) * 2011-09-30 2017-09-08 英国电讯有限公司 一种归因针对相应用户寄存器的共享资源的拥塞贡献的方法和装置
US10292066B2 (en) * 2011-11-04 2019-05-14 Cisco Technology, Inc. System and method of modifying congestion control based on mobile system information
US9197565B2 (en) 2012-04-27 2015-11-24 Magor Communications Corp. Network congestion prediction
US20130332621A1 (en) * 2012-06-08 2013-12-12 Ecole Polytechnique Federale De Lausanne (Epfl) System and method for cooperative data streaming
WO2014031106A1 (en) * 2012-08-21 2014-02-27 Hewlett-Packard Development Company, L.P. Congestion notification in a network
US9247448B2 (en) * 2012-08-27 2016-01-26 Qualcomm Incorporated Device and method for adaptive rate multimedia communications on a wireless network
CN104662970B (zh) * 2012-09-26 2019-10-11 Lg电子株式会社 控制上行链路控制信道的发送功率的方法和装置
TWI474740B (zh) * 2012-12-04 2015-02-21 Univ Nat Taiwan Science Tech 資料叢發排程方法
CN105075202B (zh) * 2013-03-28 2019-07-12 英国电讯有限公司 用于在分组网络中处理分组的方法、节点和分组网络
KR101767913B1 (ko) * 2013-03-29 2017-08-14 브이아이디 스케일, 인크. 조기 패킷 손실 검출 및 피드백
US20140376376A1 (en) * 2013-06-20 2014-12-25 Alcatel-Lucent Usa Inc. Method And Apparatus For Improved Multicast Rate Control
US9124520B2 (en) * 2013-08-27 2015-09-01 Cisco Technology, Inc. Reducing buffer bloat while probing for additional bandwidth in an adaptive bitrate network
US9794311B2 (en) * 2014-03-18 2017-10-17 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US9438853B2 (en) 2014-07-29 2016-09-06 Qualcomm Incorporated Receiver driven up-switching in video telephony

Also Published As

Publication number Publication date
US9426418B2 (en) 2016-08-23
CN106537855B (zh) 2018-05-25
BR112017001040A2 (pt) 2017-11-14
HUE043634T2 (hu) 2019-08-28
KR20170040216A (ko) 2017-04-12
EP3175584B1 (en) 2018-03-14
CN106537855A (zh) 2017-03-22
KR101727450B1 (ko) 2017-04-14
EP3175583A1 (en) 2017-06-07
EP3175583B1 (en) 2019-05-01
KR20170018458A (ko) 2017-02-17
US9438853B2 (en) 2016-09-06
CA2953711C (en) 2018-02-27
JP6602842B2 (ja) 2019-11-06
KR102366630B1 (ko) 2022-02-22
WO2016019019A1 (en) 2016-02-04
CN106576081B (zh) 2019-08-06
EP3175584A1 (en) 2017-06-07
BR112017001510B1 (pt) 2023-10-24
JP2017530584A (ja) 2017-10-12
BR112017001040B1 (pt) 2023-11-14
BR112017001510A2 (pt) 2017-11-21
US20160037128A1 (en) 2016-02-04
JP2017531345A (ja) 2017-10-19
CA2953711A1 (en) 2016-02-04
US20160037125A1 (en) 2016-02-04
JP2018139407A (ja) 2018-09-06
ES2673701T3 (es) 2018-06-25
WO2016019015A1 (en) 2016-02-04
AU2015296540A1 (en) 2017-01-19
CN106576081A (zh) 2017-04-19
HUE037155T2 (hu) 2018-08-28
AU2015296540B2 (en) 2019-09-12
ES2739527T3 (es) 2020-01-31

Similar Documents

Publication Publication Date Title
JP6420006B2 (ja) ビデオ電話における遅延の低減
EP3335341B1 (en) Sender side video telephony downgrade method
US8489758B2 (en) Method of transmitting data in a communication system
US10492085B2 (en) Real-time transport protocol congestion control techniques in video telephony
JP4504429B2 (ja) 端末間のボイスオーバインターネットプロトコルのメディアの待ち時間を管理する方法および装置
CN103828324A (zh) 用于分组网络上的流媒体的按需自适应比特率管理
CN107079132B (zh) 在视频电话中的端口重配置之后馈送经帧内译码的视频帧

Legal Events

Date Code Title Description
A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20180808

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20180828

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20180911

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20181010

R150 Certificate of patent or registration of utility model

Ref document number: 6420006

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250