JP4347883B2 - プロアクティブなレート適合シグナリング方法及び装置 - Google Patents

プロアクティブなレート適合シグナリング方法及び装置 Download PDF

Info

Publication number
JP4347883B2
JP4347883B2 JP2006506514A JP2006506514A JP4347883B2 JP 4347883 B2 JP4347883 B2 JP 4347883B2 JP 2006506514 A JP2006506514 A JP 2006506514A JP 2006506514 A JP2006506514 A JP 2006506514A JP 4347883 B2 JP4347883 B2 JP 4347883B2
Authority
JP
Japan
Prior art keywords
server
client
rate
parameter
transmission
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.)
Expired - Fee Related
Application number
JP2006506514A
Other languages
English (en)
Other versions
JP2006524452A (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.)
Nokia Oyj
Original Assignee
Nokia Oyj
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 Nokia Oyj filed Critical Nokia Oyj
Publication of JP2006524452A publication Critical patent/JP2006524452A/ja
Application granted granted Critical
Publication of JP4347883B2 publication Critical patent/JP4347883B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/16—Combinations of two or more digital computers each having at least an arithmetic unit, a program unit and a register, e.g. for a simultaneous processing of several programs
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/54—Store-and-forward switching systems 
    • H04L12/56—Packet switching systems
    • H04L12/5601—Transfer mode dependent, e.g. ATM
    • H04L12/5602—Bandwidth control in ATM Networks, e.g. leaky bucket
    • 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
    • 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/30—Flow control; Congestion control in combination with information about buffer occupancy at either end or at transit nodes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • 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

Description

本発明は、一般に、マルチメディアストリーミングに関し、更に詳しくは、マルチメディアストリーミングサービスにおけるサーバーとクライアント間のレート適合に関するものである。
マルチメディアストリーミングサービスには、ストリーミングサーバー、ストリーミングクライアント、及び伝送チャネル（又は、その基礎をなすネットワーク）という３つの要素が関係している。通常、このサービスのボトルネックは、スループットと信頼性の両方の観点において（即ち、スループットビットレートが保証されていない場合は）、伝送チャネルであるが、スループットの制限は、クライアント及び／又はサーバーにおいても発生する場合がある。
従って、リアルタイムストリーミングシステムにおいては、チャネル、クライアント、及びサーバーのスループット特性の動的な変化に起因し、ユーザーのリアルタイム再生状態を維持するべく、ストリーミング供給を適合可能にしておく必要があり、サーバーは、システムのスループットの変化に対して伝送レートを適合させる必要がある。Ｈａｓｋｅｌｌ他による「Ｅｎｃｏｄｅｒ／Ｄｅｃｏｄｅｒ Ｂｕｆｆｅｒ Ｃｏｎｔｒｏｌ ｆｏｒ Ｖａｒｉａｂｌｅ Ｃｈａｎｎｅｌ」という名称の米国特許第５，５６５，９２４号明細書には、このようなレート適合システムの一例が開示されている。
ストリーミングクライアントにおいては、再生のためにメディアデコーダに伝達する前に、到来データを保存するべく、レシーババッファリングを提供している。即ち、レシーババッファを使用することにより、ソースエンコーディングレート（これは、サンプリングレートとも呼ぶ）と伝送レート（プリデコーダバッファリング）間の差を補償しており、又、これは、チャネル上のパケット転送遅延変動を補償するためにも使用されている（ジッタバッファリング）。尚、一般には、これら２つの機能は、単一のレシーババッファ内に統合されるものと考えられているが、受信側の２つの別個のバッファにより、これらを実装することも可能である（但し、このような実装は、遅延の観点から最適なものではない）。又、レシーババッファリングによれば、整合の不正確性を補正することも可能である（即ち、システムスループットがサーバーのアウトプットと正確に整合していない場合）。
レシーババッファが空になると（即ち、これは、バッファアンダーフローであり、デコーダがデコードするべきデータがなくなったことを意味している）、クライアントは、再生を休止し、到来データを再バッファリングした後に、再生を再開する必要がある。一方、到来データレートが再生レートよりも高速である場合には、レシーババッファのスペースが使い果たされることになり（即ち、バッファオーバーフロー）、この結果、新しい到来データ用の空きを生成するべく、バッファからパケットが削除されることになる。パケットが削除されると、ビデオ品質が劣化する。従って、滑らかで完全な再生を確保するには、クライアントのレシーババッファを一定の充填レンジ内に維持する必要ある。そして、レシーババッファがアンダーフロー又はオーバーフローしないようにするには、サーバーにおける伝送及びサンプリングのビットレートと、クライアントにおける受信及び再生のビットレートを十分に制御しなければならないのである。
以下の説明においては、ビットレートの変化プロット（水平軸が時間（単位：秒）であって、垂直軸が累積データ量（単位：バイト又はビット）である）を参照し、このビットレートの制御について説明するが、このプロットには、次の曲線が定義されている。
・再生曲線Ｐ（ｔ）：これは、所与の時刻においてデコーダが処理したレシーババッファからの累積データ量を示している。
・サンプリング曲線Ｓ（ｔ）：これは、メディアエンコーダがリアルタイムで稼働した場合のデータ生成の経過を示している（これは、再生曲線に対応しており、実際には、再生曲線の時間シフトされたバージョンである）。
・伝送曲線Ｔ（ｔ）：これは、所与の時刻においてサーバーから送出された累積データ量を示している。
・受信曲線Ｒ（ｔ）：これは、所与の時刻において受信され、クライアントバッファ内に配置された累積データ量を示している。
任意の２つの曲線間の差は、それら２つの曲線間における遅延と「バッファサイズ」を定めている。そして、ビットレートの制御は、２つの曲線間の差に関する制限（例：最大バッファサイズや最大遅延）によって制約を受けることになる。図１には、代表的なビットレートの変化プロットが示されている。
ビットレートの制御においてサーバー及びクライアントが協働するための最良の構成を決定する際には、次のような点を考慮する必要がある。
Ａ．サンプリング曲線：この制御（即ち、伝送用のビットストリームの選択）は、完全にサーバーに任せる必要がある。この理由は、（１）それぞれのビットストリームの正確な特性（例：スイッチング位置、フレームの優先順位、及び将来のフレームサイズ）に関する知識を有しているのが、サーバーのみであること、及び（２）ネットワークのビットレートと整合するビットストリームレートが存在せず、なんらかの「トリック」（例：間引きやスイッチングアップ及びダウン）をサーバーが実行することになる可能性があるためである。
Ｂ．伝送曲線：この制御（即ち、伝送するレート）もサーバーに任せる必要がある（即ち、ＲＴＣＰ（Ｒｅａｌ Ｔｉｍｅ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）レポートやクライアントからのその他の帯域幅情報の使用による）。この理由は、（１）一般に、伝送路上のデータ量を計測できるのが、サーバーのみであること、及び（２）サンプリング曲線の柔軟性が限定されている場合には、伝送レートをサンプリング曲線に対して適合させる必要があるためである。
サーバーは、そのサンプリング曲線Ｓ（ｔ）を、その伝送曲線Ｔ（ｔ）に対して適合させることによって、リアルタイム制約を維持しなければならない。十分なバッファリングが提供されておれば、伝送曲線に対してサンプリング曲線を適合させることにより、受信側における正しく同期したメディアの再生が保証されることになる。すべての時点ｔにおいて、伝送曲線Ｔ（ｔ）からのサンプリング曲線Ｓ（ｔ）の逸脱が、一定のバイト数を超過してはならない。
サーバーが、リアルタイム制約によって定められている制限内において稼働している場合に、クライアントは、その制限内においてサーバーに追随するのに必要なバッファリングを提供する責任を負っている。この場合に、クライアントは、（１）｜Ｓ（ｔ）−Ｔ（ｔ）｜のプリデコーダバッファリングと、（２）転送遅延変動｛Ｔ（ｔ）−Ｒ（ｔ）｝のジッタバッファリングについて補償しなければならない。
又、クライアントは、再生曲線とサンプリング曲線間における不整合（例：クライアントプラットフォームのオペレーティングシステムの問題に起因するクロックドリフトや再生のスローダウン）を許容しなければならない。
マルチメディアストリーミングシステムにおいては、送信側（即ち、サーバー）は、それぞれの時点において、送信対象の後続のパケットをどのように（どのレートで）エンコードするかを決定し、且つ、それをいつ送信するかを決定する必要がある。通常の動作においては、送信側は、ＲＴＣＰレポートのみを使用することにより、受信側によるリアルタイム再生を維持することができる。３ＧＰＰ（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）のＰＳＳ（Ｐａｃｋｅｔ Ｓｗｉｔｃｈｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ）には、規範的なビデオバッファリング要件が定義されており、これは、ＶＢＲ（Ｖａｒｉａｂｌｅ Ｂｉｔ Ｒａｔｅ）ビデオ圧縮及び伝送に固有のエンコーディング及びサーバー固有の遅延変動の保証を目的としている（３ＧＰＰ ＴＳ ２６．２３４ Ｖ５．１．０、「Ｔｒａｎｓｐａｒｅｎｔ Ｅｎｄ−ｔｏ−Ｅｎｄ Ｐａｃｋｅｔ Ｓｗｉｔｈｃｅｄ Ｓｔｒｅａｍｉｎｇ Ｓｅｒｖｉｃｅ（ＰＳＳ）； Ｐｒｏｔｏｃｏｌｓ ａｎｄ Ｃｏｄｅｃｓ（Ｒｅｌｅａｓｅ ５）」（２００２年６月）を参照されたい。尚、以下においては、これをＴＳ ２６．２３４と呼ぶこととする）。ストリーミングサーバーとクライアントの両方がこれらのバッファリング要件を満足しており、且つ、サーバーからのストリームが、遅延が一定であって信頼性の高い伝送チャネル上において伝送されておれば、サーバーから伝送されたストリームのクライアントによる再生が、クライアントバッファ違反なしに（即ち、クライアントにおいて、バッファのアンダーフローやオーバーフローが発生することなしに）、保証されることになる。しかしながら、ハンドオーバー、再伝送、又はクロックドリフトなどの状況においては、これは不可能である。この結果、送信側と受信側が互いに矛盾する行動を取り、ユーザーが経験する機能の深刻な劣化が発生することになるのである。
従来技術においては、受信側は、ＲＴＳＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）ヘッダフィールドの速度（オーディオ及び／又はビデオのサブサンプリング）及びスケール（ビットレートの乗法的増大又は減少）を使用することにより、そのバッファレベルを変更しており、これらのヘッダについては、ＩＥＴＦ ＲＦＣ２３２６に定義されている。又、受信側は、３ＧＰＰ ＳＡ４の文書Ｓ４−０３００２４「Ｅｎｄ−ｔｏ−Ｅｎｄ ｂｉｔ ｒａｔｅ ａｄａｐｔａｔｉｏｎ ｆｏｒ ＰＳＳ」に記述されているクライアントによるビットレート切り換え命令を使用することも可能である。
発明の概要
本発明においては、送信側と受信側間におけるレート適合の責任を次のように分割している。
即ち、サーバーは、「受信レートに対する伝送レートの適合（即ち、輻輳制御）」と「伝送レートに対するサンプリングレートの適合（即ち、シフトの管理と、レート適合動作レンジ内におけるその維持）」の責任を担っている。
一方、受信側は、「パケット転送遅延変動（即ち、ネットワークジッタ）の補償」と「サーバーレート適合動作レンジ（即ち、シフトレンジ）のパラメータの設定」の責任を担っている。
サーバーレート適合用の動作レンジは、サーバーが送信するパケットの許容可能な最小及び最大シフトを指定することにより、「サーバーの動的なスケジューリング」の制限を定めている。そして、このサーバーレート適合動作レンジのパラメータが、ハンドオーバー、再伝送、及びクロックドリフトなどの場合におけるアンダーフロー、オーバーフロー、及び品質劣化の発生を極小化するべく、サーバーと受信側間においてネゴシエートされる。
従って、本発明の第１の態様は、マルチメディアストリーミングネットワークのクライアント内のレシーババッファのレベルを適応制御する方法を提供し、このストリーミングネットワークは、クライアントにストリーミングデータを提供するサーバーを有しており、レシーババッファは、クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、サーバーによるデータ伝送量とクライアントによるデータ使用量間の差を補償するために使用されており、この方法は、サーバーとクライアント間におけるレート適合を実行するために、クライアントにおいて、レート適合動作レンジを決定するための少なくとも１つのパラメータを定め；この少なくとも１つのパラメータに基づいて、サーバーにおいて、受信レートに対してデータ量を適合させ；この適合に基づいて、クライアントにおいて、パケット転送遅延変動を調節すること；を有している。
本発明によれば、少なくとも１つのパラメータは、サーバーが最小シフト量に基づいて適合を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の差を表す最小シフト量を有している。
本発明によれば、少なくとも１つのパラメータは、サーバーが目標シフト量に基づいて適合を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の差を上回るシフト量を表す目標シフト量を有している。
本発明によれば、少なくとも１つのパラメータは、サーバーが適合段階を実行できようにするべく、送信されたバイト数とサンプリングされたバイト数間の最大の差を規定する数を有している。
本発明によれば、このサーバー内における適合は、伝送レート又はサンプリングレート、或いは、これらの両方を調節することによって実行される。
本発明によれば、少なくとも１つのパラメータは、クライアントにおける再生の中断を防止するためのクロックシフト量を有している。
本発明によれば、この方法は、少なくとも１つのパラメータに基づいて、サーバー内において、伝送レートに対してサンプリングレートを適合させることを更に有している。
本発明によれば、最小シフト量、目標シフト量、規定数、及びクロックの中の複数のものをサーバーに一緒に送信している。
本発明の第２の態様は、マルチメディアストリーミングシステムを提供する。このシステムは、少なくとも１つのクライアントと；このクライアントに対してストリーミングデータを提供するサーバーと；を有しており、クライアントは、クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、サーバーによるデータ伝送量とクライアントによるデータ使用量間の差を補償するためのレシーババッファを具備しており、クライアントは、サーバーが、少なくとも１つのパラメータに基づいて、受信レートに対してデータ量を適合させることができるようにするべく、レート適合動作レンジを決定するための少なくとも１つのパラメータを定めるメカニズムと；この適合に基づいてパケット転送遅延変動を調節するメカニズムと；を有している。
本発明によれば、少なくとも１つのパラメータは、サーバーが最小シフト量に基づいて適合段階を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量と；サーバーがターゲットシフト量に基づいて適合段階を実行できるようにするべく、サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量と；送信されたバイト数とサンプリングされたバイト数間の最大の差を規定する数と；クライアントにおける再生の中断を防止するためのクロックシフト量と；を含むことができる。
本発明によれば、サーバーは、少なくとも１つのパラメータに基づいて、伝送レートに対してサンプリングレートを適合させる適合メカニズムを有している。
本発明の第３の態様は、クライアント内のレシーババッファのレベルを適応制御するためのマルチメディアストリーミングネットワーク内のクライアントにおいて使用するソフトウェアプロダクトを提供し、このマルチメディアストリーミングネットワークは、ストリーミングデータをクライアントに提供する能力を有するサーバーを有しており、クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、レシーババッファを使用することにより、サーバーによるデータ伝送量とクライアントによるデータ使用量間の差を補償しており、このソフトウェアプロダクトは、サーバーとクライアント間におけるレート適合を実行するべく、サーバー内におけるレート適合動作レンジを決定するための少なくとも１つのパラメータを定めるコードと；この適合に基づいてパケット転送遅延変動を調節するコードと；を有している。
本発明によれば、少なくとも１つのパラメータは、サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量と；サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量と；送信されたバイト数とサンプリングされたバイト数間の最大の差を規定する数と；クライアントにおける再生の中断を防止するためのクロックシフト量と；を含むことができる。
本発明の第４の態様は、端末にストリーミングデータを提供する少なくとも１つのサーバーを具備するマルチメディアストリーミングネットワーク内の端末を提供し、この端末は、この端末が、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、サーバーによるデータ伝送量と端末によるデータ使用量間の差を補償するレシーババッファを具備している。この端末は、サーバーが、少なくとも１つのパラメータに基づいて、受信レートに対してデータ伝送量を適合させることができるようにするべく、サーバー内におけるレート適合動作レンジを決定するための少なくとも１つのパラメータを定義するメカニズムと；この適合段階に基づいてパケット転送遅延変動を調節するメカニズムと；を有している。
本発明によれば、定めるメカニズムは、少なくとも１つのパラメータを定める少なくとも１つのコードを具備するソフトウェアプログラムを有しており、調節メカニズムは、パケット転送遅延変動を調節する少なくとも１つのコードを具備するソフトウェアプログラムを有している。
本発明の第５の態様は、ネットワーク要素からストリーミングデータを受信する少なくとも１つの端末を具備するマルチメディアストリーミングネットワーク内のネットワーク要素を提供し、この端末は、この端末が、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、ネットワーク要素によるデータ伝送量と端末によるデータ使用量間の差を補償するレシーババッファを具備している。そして、ネットワーク要素は、このネットワーク要素内におけるレート適合動作レンジを決定するための少なくとも１つのパラメータを表している要求を端末から受信する手段と；端末が、少なくとも１つのパラメータに基づいて、端末による受信レートに対してデータ伝送量を適合させて適合段階に基づいてパケット転送遅延変動を調節できるようにするメカニズムと；を有している。
本発明によれば、適合メカニズムは、データ伝送量を適合させる少なくとも１つのコードを具備するソフトウェアプログラムを有している。
本発明によれば、ソフトウェアプログラムは、伝送レート又はサンプルレート、或いは、これらの両方を調節するコードを有している。
本発明については、添付の図１〜図３との関連で、以下の説明を参照することにより、明らかとなろう。
発明の詳細な説明
サーバーが送信するパケットに許容される最小及び最大シフトを規定するべく、本発明においては、次のようなレート適合モデルを使用して「シフト」を定義している。
Ａ．協調レート適合モデル
ＲＰＴ（Ｒｅａｌ−Ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）パケット内のメディアのサンプリング時刻（即ち、タイムスタンプ）と、このパケットの伝送時刻（即ち、これがサーバーから送信される時点）の間の時間差αを「シフト」として定義している。即ち、サンプリング曲線（Ｓ）と伝送曲線（Ｔ）を参照すれば、αのシフトは、Ｔ（ｔ）＝Ｓ（ｔ＋α）として表すことが可能である。
従って、パケットサンプリング時刻がパケット伝送時刻よりも遅行している場合には、シフトは、正の値になる。一方、パケットサンプリング時刻がパケット伝送時刻よりも先行している場合には、シフトは、負の値になる。
このように「シフト」を定義することに伴い、最小及び最大シフトパラメータは、次のように定義される。
Ｂ．サーバーレート適合動作レンジのパラメータ
レート適合動作レンジのパラメータは、次のように定義される。
（１）最小シフト：このパラメータは、送信側が使用可能な最小シフトを定義するものである。これによれば、伝送時刻ｔにおいて送信可能な最も古い許容サンプリング時刻が与えられる。即ち、このパラメータをα＿ｍｉｎとすれば、送信側が時刻ｔにおいて送信しているパケットのサンプリング時刻は、「ｔ＋α＿ｍｉｎ」を超過して先行してはならない。
そのサンプリング時刻に対して、どれだけ遅行してパケットを送信可能であるかに関するこの最大限度を具備することにより、受信側においてリアルタイムの再生を維持することができる。受信側は、再生の遅延を回避するために（即ち、レシーババッファのアンダーフローが発生しないようにするために）パケットの待機状態で許容しなければならない最大時間量を推定可能である。
初期レシーババッファリング遅延（即ち、プリロール）の大きさは、この最小シフトを許容すると共にパケット転送遅延変動を補償するように、設定しなければならない。一例として、この最小シフトが、−２０００ｍｓであると仮定しよう。これは、送信側がパケットを送信する場合に、パケットサンプリング時刻が、その伝送時刻と比べて、最大２秒だけ先行可能であり、これを上回ってはならないことを意味している。レシーババッファアンダーフローを回避するために、受信側は、当初、最大予想パケット転送遅延変動＋２秒にわたって、バッファリングすることになろう。そして、この（負の）値が小さくなるほど、受信側における初期バッファリングの必要性が増大することになる。
受信側がクロックドリフト（即ち、送信側において維持されているサンプリング曲線からの受信側の再生曲線のずれ）を検出した場合には、この最小シフトパラメータを変更することにより、サーバーのパケット伝送時刻を再生曲線に追随させることができる。例えば、受信側が相対的に高速であればは、受信側は、データのサンプリング速度よりも高速のレートでデータを再生することになろう。そして、これは、最終的にバッファのアンダーフローを招くことになる。従って、その最小シフトを増大させるべく送信側に対して要求することにより、アンダーフローを回避することができる。
即ち、受信側が送信側よりも低速である場合には、最小シフトを減少させる必要があり、受信側が、送信側よりも高速である場合には、最小シフトを増大させる必要があるのである。
この最小シフトの初期値は、通常、負であるが、受信側がこれを変更し、正になるように修正することも可能である。例えば、受信側が相対的に高速になる（即ち、相対的に再生クロックが高速になる）場合に、最小シフトは、その増大に伴って、正になることもあり得る。例えば、初期値が−２秒であるとすれば、送信側は、このシフトを、−１．９秒、次いで、−１．７秒などとするように後から要求することが可能である。
（２）目標シフト：このパラメータは、送信側が実現することをクライアントが所望しているシフトを定義するものである。このパラメータをα＿ｔａｒｇｅｔとすると、送信側が時刻ｔにおいて送信しているパケットのサンプリング時刻は、ｔ＋α＿ｔａｒｇｅｔである必要がある。
この目標シフトは、先程定義した最小シフトよりも常に大きくなければならない。送信側がこの目標シフトに従ってパケットを送信している場合には、当然のことながら、その定義により、送信側は、その最小シフトをも満足している。
この目標シフトは、リアルタイムデッドライン（即ち、最小シフト）を満足させた状態で伝送レートを突然減少させなければならない場合に（例：ハンドオーバーの際）、サンプリングレートを減少させる必要性を低減することを意図するものである。換言すれば、この目標シフトは、伝送レートが十分に良好である場合に、リアルタイムを満足させるのに厳密に必要とされるものよりも先行してパケットを送信側に送信させることを意図するものである。
この第２パラメータについて更に詳しく説明するべく、送信側が最小シフトの近傍において動作していると仮定しよう。そして、伝送レートが大幅に減少すると仮定しよう（この原因は、ハンドオーバーやＲＴＰ再伝送などであり、この場合には、オリジナルのストリームに提供されているビットレートが減少することになる）。この場合には、最小シフト（並びに、従って、リアルタイム）を保証するべく、送信側も、そのサンプリングレートを急激に減少させなければならないであろう。そして、この結果、送信側が、例えば、サンプリングレートの減少を実現するべくフレームのスキップを余儀なくされることに伴い、品質が低下することになる。
一方、サーバーが目標シフトの近傍において動作している場合には、伝送レートが減少した場合のサンプリングレートの減少は、伝送レートの減少ほどに急激なものにする必要はない。即ち、サンプリングレートの低下を伴うことなしに伝送レートを低下させる送信側の実際のシフトは、目標シフト未満に減少することになるが、この場合にも、伝送レートにおいて観察される減少ほどには劇的にサンプリングレートを減少させることなしに、最小シフトを維持することが可能である。
そのシフトの減少を余儀なくされた後に、伝送レートが再度増大すると、サーバーは、その目標シフトを再構築する必要がある。受信側から通知された目標シフトを実現するべく、送信側は、現在の伝送レートの制約に応じて、伝送レートの増大とサンプリングレートの減少（又は、伝送レートの減少とサンプリングレートの増大）の組み合わせを使用可能である。
このように定義された目標シフトを具備することにより、大きな伝送レートの減少に対応する際に、受信側が、サーバーに対して、まず、シフトを減少させ、次いで、再度、これを増大させて元に戻すように「命令」する必要がなくなる。即ち、以前に受信側から通知されている目標シフトから、シフトを減少させ、次いで、再度、そのシフトを増大させて目標シフトに戻すことを送信側自身が決定することになるのである。
このため、この方式をプロアクティブであると表現可能であり、伝送レートの減少の際に（シフトの）シグナリングを実行する必要はない。
（３）先行送信バイトの最大数：このパラメータは、時刻ｔにおいて送信済みのバイト数とサンプリング時刻ｔまでにサンプリング済みのバイト数間の最大の差を定義するものである（即ち、伝送曲線とサンプリング曲線の差：Ｔ（ｔ）−Ｓ（ｔ）である）。このパラメータは、正のシフトの結果として受信された（従って、受信側がその再生時間まで待たなければならない）パケットの保持に必要な受信側のバッファサイズを制限している。このパラメータの目的は、バッファのオーバーフローを防止することにある。
図１には、これらのパラメータが、伝送曲線Ｔ（ｔ）とサンプリング曲線Ｓ（ｔ）の例と共に示されている。
Ｃ．レート適合動作レンジのパラメータに対するサーバーの準拠要件
サーバーは、「最小シフト」及び「先行送信バイトの最大数」パラメータを厳格に遵守しなければならない。従って、サーバーは、正常な伝送条件下においては、その能力と提供されているメディアエンコーディングが許容する範囲内において、「目標シフト」に近接した状態で動作するべく試みることになる。
しかしながら、時間に伴って発生し得るメディアエンコーディングレートの変動のために、サーバーは、すべての送信パケットについて、「目標シフト」に正確に追随することはできない。従って、「目標シフト」に対して厳格に追随すると、不必要な品質の劣化が発生することになるとサーバーが判断する伝送条件下においては、この「目標シフト」からのずれは、サーバーの裁量によって許容されることになる（後述する使用例を参照されたい）。又、このずれの後に、「目標シフト」がどれだけ迅速に回復されるかについても、サーバーの決定／能力に任されている。
尚、「目標シフト」パラメータと「先行送信バイトの最大数」パラメータが矛盾している場合には（即ち、目標シフトを維持した結果、先行送信バイトの最大数を超過することになる場合には）、常に後者が優先する。
Ｄ．サーバーとクライアント間における責任分割の説明
中断のない再生にとって重要なのは、レシーババッファレベルの効果的な管理である。これは、クライアントにおいて、再生曲線と受信曲線の両方に対する少なくとも間接的な又は推定による制御を具備することによって実現することができる。クライアントは、その定義により、デコーディング／再生タイムラインに関する知識を有しており、これらを制御している。送信側がシフト制御を導入できるようにすることにより、クライアントに対して、受信曲線と、サンプリング曲線に対するその関係の少なくとも推定による制御機能が付与され、従って、レシーババッファレベルの制御機能が付与されることになる。
従って、クライアントは、その絶対的なバッファリング制限を考慮してシフトパラメータを選択し、これを要求する。そして、この協調レート適合モデルにおいて受信側が要求するのは、このシフトパラメータのみであり、この要求に対する応答において、そのエンコーディングレート及び／又は伝送レートをどのように適合させるかは、送信側に任されている。伝送曲線又はサンプリング曲線のいずれか、或いは、これらの両方を適合可能である。
従って、サンプリングレートの制御（即ち、伝送用のビットストリームの選択）は、サーバーの制御下に残されており、この理由は、それぞれのビットストリームの正確な特性（例：スイッチング位置、フレームの優先順位、将来のフレームサイズ）に関する知識を有しているのは、サーバーのみであることと、ネットワークのビットレートに整合するビットストリームレートが存在せず、従って、ネットワークのビットレートにビットストリームのレートをフィットさせるべく、なんらかの「トリック」（例：間引きやスイッチングアップ及びダウン）をサーバーが実行することになる可能性があるためである。
そして、伝送レートの制御（即ち、伝送するレート）も、サーバーの制御下に残されており（即ち、これには、ＲＴＣＰ ＲＲ レポートを使用する）、この理由は、一般に、伝送路上のデータ量を計測できるのは、サーバーのみであることと、サンプリングレート制御の柔軟性が限定されている場合には、サンプリングレートに伝送レートを結び付けることが必要になるためである。
送信側が適合を実行するべく試みる場合には、次の項目によって制限されることになる。
・伝送曲線の変更：伝送曲線は、受信曲線によって制約されており、従って、送信側は、伝送曲線を増大させることができない場合がある。送信側が伝送曲線を増大させることができるのは、送信側が、以前に、その提供されている帯域幅のすべてを使用していなかった場合のみである。例えば、サーバーは、ＴＦＲＣ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ Ｆｒｉｅｎｄｌｙ Ｒａｔｅ Ｃｏｎｔｒｏｌ）メカニズムを使用して（又は、受信側からのシグナリングを介して直接的に帯域幅情報を受信して）その利用可能な伝送レートを算出可能であり、ＴＦＲＣ（又は、実際の通知された帯域幅）が許容するレートを超過して、そのレートを増大させることはない。
サンプリング曲線の変更：これは、送信側のレート適合能力によって左右される。例えば、送信側がビットストリームスイッチングを実装しており、且つ、送信側が、その最低の（又は、最高の）ビットストリームにおいて伝送している場合には、送信側は、サンプリングレートを更に減少（又は、減少）させることはできないであろう。
Ｅ．ユースケース
本発明によれば、ハンドオーバー、再伝送、及びクロックドリフトなどの場合におけるアンダーフロー、オーバーフロー、及び品質劣化の発生を極小化するべく、サーバーと受信側の間において、サーバーレート適合動作レンジのパラメータをネゴシエートしている。
ＲＴＰパケット伝送の場合においては、受信側は、実行を所望するパケット再伝送の数と、再伝送において許容する遅延を選択することができる。
ハンドオーバーの場合には、受信側は、無線ネットワークタイプから、例えば、予想されるハンドオーバーの長さと、従って、必要な目標シフトを導出可能である。受信側は、無線リンクに関して相対的に良好な知識を有していると共に、システム間ハンドオーバーと、これに相応してクロックシフトパラメータを適合させる必要性を検出可能である。
従って、受信側は、クロックシフトパラメータを更新することにより、送信側によるクロックドリフトを補償することができる。
ＲＴＰ再伝送
再伝送の要求を行う前に、受信側は、通常、再伝送対象のパケットが、その再生時間に間に合うかどうかを推定する必要がある。即ち、そのパケットが間に合わない場合には、その再伝送により、利用可能な帯域幅が浪費されることになるからである。
送信側は、受信側におけるリアルタイム制約を満足するために少なくともシフトα＿ｍｉｎによるスケジューリングを要するパケットのサンプリング時刻に関する知識を有している。
この観点において、再伝送パケットは、最初に送信されたパケットと異なるところはない。但し、受信側におけるアンダーフローの閾値を最小シフトが示しているため、送信側は、タイプスタンプがｔ＋α＿ｍｉｎ（ここで、ｔは、現在の時間である）を下回っている場合には、そのパケットを再伝送するべきではない。
従って、シフトパラメータのシグナリングによれば、受信側におけるデコーディング時間に間に合わず、利用可能な帯域幅がその再伝送によって浪費されることになるパケットを送信側が再伝送しないようにすることにより、パケット再伝送の効率を向上させることができる。又、受信側は、消失パケットを再生の前に受信可能かどうかに関する推定において、過度に慎重になる必要はない。これは、サーバーがそのパケットを再伝送しないため、誤った推定が（その無駄な要求自身を除いて）影響を及ぼさないからである。
又、受信側は、目標シフトを介して、実行を所望する再伝送の数をトレードオフすることも可能である。即ち、目標シフトの値が大きいほど、ネットワーク状態を良好に保ちつつ、相対的に多くのパケットが先行送信されることになる（且つ、レシーババッファレベルも高くなる）。そして、この結果、ネットワーク状態が悪化した場合に、相対的に多くの時間が再伝送に対して付与されることになるからである。
この場合にも、クロックシフトは、プロアクティブであり、受信側は、シフト要求をＲＴＣＰ要求と同期させる必要はない。
ハンドオーバー
クロックシフトのシグナリングは、ハンドオーバーに起因する受信側における再生の中断を防止するツールとして使用可能である。
受信側が、ネットワークに接続されており、且つ、そのネットワークの予想ハンドオーバー長がＴHであるという知識を有していると仮定しよう。又、この受信側が、最小シフトよりも少なくともＴHだけ大きくなるように（即ち、α＿ｔａｒｇｅｔ＞α＿ｍｉｎ＋ＴH）、その目標シフトを設定していると仮定しよう。
ハンドオーバーの前に、送信側は、パケットを先行送信することにより、目標シフトを満足させる。そして、ハンドオーバーを検出した場合には、送信側は、伝送を停止する必要がある（そして、これにより、ネットワークバッファのオーバーフローに起因するパケットの消失を回避する必要がある）。そして、このハンドオーバーの最中には、新しいデータが送信されない状態で、クロックが動作する。この結果、（ハンドオーバーが正確にＴHだけ継続したと仮定すれば）、このハンドオーバーにより、シフトは、時間量ＴHだけ減少することになる。そして、送信側は、ハンドオーバーの以前には、目標シフトで稼働していたため、ハンドオーバー後のシフトは、α＿ｔａｒｇｅｔ−ＴHとなる。
この値は、依然として、最小シフトα＿ｍｉｎを上回っている。そして、これは、リアルタイム性が依然として満足されており、受信側において、アンダーフローが発生しなかったことを意味している。従って、受信側は、目標シフトに従って送信側から送信されたパケットを、ハンドオーバーの最中においても、大幅な品質の劣化を伴うことなしに再生可能である。
そして、ハンドオーバーの後に、送信側は、その伝送レートの再度の増大に伴い、目標シフトを再構築することになる。従って、新しいシグナリングは不要である。
受信側が新しいシフトパラメータを通知するのは、許容可能なハンドオーバーの長さを更に増大させるべく、その目標シフトの拡大を所望する場合のみとなろう。具体的には、これには、異なる予想ハンドオーバー長を有する異なるタイプのネットワークに対するハンドオーバーが存在している場合が該当しよう。
当然のことながら、送信側は、ハンドオーバーを検出できる必要がある。送信側は、通常、いくつかのＲＴＣＰインターバルにわたってＲＴＣＰパケットを受信しない場合に、ハンドオーバーを検出することになる。送信側が可能な限り早期にハンドオーバーを検出できるように、受信側は、ＡＶＰＦが提供されている場合には、早期のフィードバックパケットを送信する必要がある。尚、ＡＶＰＦとは、ＲＴＣＰに基づいたフィードバックのための拡張プロファイルである。
受信側がＲＴＳＰによってパラメータを送信している場合には、受信側は、ハンドオーバーの後に、（同一のパラメータ又は更新済みの値と共に）新しい要求を送信することができよう。これは、高速のＲＴＣＰフィードバックが利用不能な場合に、ハンドオーバーが終了したことを送信側が迅速に検出するのに有用である。
図２には、ハンドオーバーと、バッファレベルに対するその影響が示されている。この例においては、ハンドオーバーの最中にバッファレベルが減少しているが、アンダーフローは発生していない。ハンドオーバーの後に、送信側は、初期の目標α＿ｔａｒｇｅｔを独自に再構築することになるが、ハンドオーバーの最中にバッファがほとんど空になっているため、ハンドオーバーの終了後に、受信側が相対的に大きな目標値を通知するべく選択する場合もあろう。この理由は、最初のハンドオーバーが、受信側が当初予想していたものを上回っており、将来、相対的に大きなハンドオーバーをサポートできるようになることを所望するためである。図には、この新しい目標のシグナリングと、曲線に対するその影響が示されている。
（クロックドリフト）
送信側と受信側の間におけるクロックドリフトやその他の理由（例：低速のクライアントプラットフォームオペレーティングシステム）のために、受信側にとって、送信側が過剰に低速に、又は過剰に高速に見える場合がある。新しいシフトパラメータを送信することにより、このようなドリフトを補正可能である。
例えば、受信側が低速である場合には、受信側は、最小シフト値の減少を定期的に要求可能であろう。
Ｆ．メッセージのフォーマットとトランスポート
新しいＲＴＳＰヘッダは、「３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ」と定義することができる。このヘッダは、クライアントが要求するシフトパラメータを通知するためのクライアント要求内において使用可能である。
その要求がセッションレベルのＲＴＳＰ ＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）に適用される場合には、そのシフトも、セッション内のすべてのメディアに適用される必要がある。一方、その要求がメディアレベルのＲＴＳＰ ＵＲＬに適用される場合には、そのシフトも、そのメディアにのみに適用される必要がある。又、送信側は、この「３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ」を、その応答においても使用する。そして、これらのパラメータは、クライアントが要求したパラメータであってよいが、送信側が返すことができるのは、（送信側の能力の制限に起因し）要求されたパラメータに可能な限り近接したパラメータのみである。
この新しいヘッダは、あらゆるＲＴＳＰのメソッドによって送信可能である。
このＲＴＰヘッダのＡＢＮＦは、次のとおりである。
３ｇｐｐｓｈｉｆｔｐａｒａｍｅｔｅｒｓ ＝ “３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ” “：”
ｓｈｉｆｔ−ｐａｒａｍｅｔｅｒ ＊（“；” ｓｈｉｆｔ−ｐａｒａｍｅｔｅｒ） ＣＲＬＦ
ｓｈｉｆｔ−ｐａｒａｍｅｔｅｒ ＝ ａｌｐｈａ−ｍｉｎ ／ ａｌｐｈａ−ｔａｒｇｅｔ ／ ｍａｘ−ｓｉｚｅ
ａｌｐｈａ−ｍｉｎ ＝ “ａｌｐｈａ＿ｍｉｎ” “＝” “＋” ／ “−” １＊ＤＩＧＩＴ ； ｍｓ
ａｌｐｈａ−ｔａｒｇｅｔ ＝ “ａｌｐｈａ＿ｔａｒｇｅｔ” “＝” “＋” ／ “−” １＊ＤＩＧＩＴ ； ｍｓ
ｍａｘ−ｓｉｚｅ ＝ “ｍａｘ＿ｓｉｚｅ” “＝” １＊ＤＩＧＩＴ； ｂｙｔｅｓ
最初に、クライアントは、すべてのパラメータを送信する。そして、後続の要求において、クライアントは、変更を要求する１つ又は複数のパラメータのみを送信可能である。
その変更が許容可能であり、且つ、受信側が要求したようにすべてのパラメータが設定済みである場合には、サーバーは、ヘッダを送信する必要はない。
又、以前の要求が完了する前に、サーバーが新しい要求を受信した場合には、サーバーは、最新の要求に応えなければならない。
又、送信側は、送信側が使用を所望するパラメータをセッションの開始時点において受信側に通知することも可能である。受信側は、これらのパラメータを考慮し、要求するパラメータの値を選択することになる。
尚、パラメータを通知する好適な方法は、ＲＴＳＰによるものであるが、ＲＴＣＰなどの信頼性の低いトランスポートプロトコルを使用することも可能であろう。
図３は、本発明によるストリーミングネットワークにおけるマルチメディアシステム１を示すブロックダイアグラムであり、このシステムには、ネットワーク要素又はストリーミングサーバー１０用のレート適合動作レンジを決定するパラメータを通知する手段が提供されており、このパラメータは、端末又はストリーミングクライアント６０とストリーミングサーバー１０の間においてネゴシエートされる。
ストリーミングサーバー１０は、アプリケーションレベルシグナリングエンジン２０、レートコントローラ３０、及びサーバーバッファ４０を有している。一方、ストリーミングクライアント６０も、ストリーミングサーバー１０内のアプリケーションレベルシグナリングエンジン２０に対応し、且つ、これと通信するべく適合されたアプリケーションレベルシグナリングエンジン７０を有している。そして、これは、クライアントバッファ８０を更に有しており、このクライアントバッファは、この図３に示されている本発明の実施例においては、単一のユニットとして統合されたジッタバッファ８２とプリデコーディングバッファ８４を有している。尚、本発明のその他の実施例においては、ストリーミングクライアント６０は、別個に実装されたジッタバッファ及びプリデコーディングバッファを含むことができる。又、このストリーミングクライアントは、メディアデコーダ９０、ポストデコーダバッファ１００、バッファコントローラ１１０、及びディスプレイ／再生装置１２０を更に有している。
又、この図３に示されているシステムは、更に、ストリーミングサーバーとストリーミングクライアント６０間に位置した「チャネルバッファ」を有するように示されており、このチャネルバッファは、ストリーミングサーバーからクライアントへのデータパケットの伝送において発生する転送遅延の変動を表している。
ストリーミングクライアント６０においては、伝送チャネルからメディアデータを受信し、これをクライアントバッファ８０内においてバッファリングする。バッファコントローラ１１０が、プリデコーダバッファ８４とジッタバッファ８２のパラメータを設定している。これらのパラメータは、サーバー推奨プリデコーダバッファリングパラメータと、クライアントが推定した必要な追加バッファリングの集合体として選択される。クライアントにおいては、提供されている伝送チャネルにおいて予想されるパケット転送遅延の変動（即ち、ジッタ）を許容するために必要なものを推定している。この集合体は、クライアントの最大バッファリング能力の制約を受けることになる。そして、メディアデコーダ９０が、クライアントバッファからメディアデータを抽出し、対象のメディアタイプに適した方式でメディアデータをデコードする。尚、このメディアデータは、一般に、いくつかの異なるタイプのメディアタイプを有することになることを理解されたい。例えば、サーバーから伝送されたメディアデータがビデオシーケンスを表している場合には、そのメディアデータは、ビデオデータ以外に、少なくとも１つのオーディオ成分を有する可能性が高い。従って、図３に示されているメディアデコーダ９０は、実際には、例えば、特定のビデオコーディング規格に従って実装されたビデオデコーダと、その関連するオーディオデコーダなどの複数のデコーダを有する可能性があることを理解されたい。メディアデータは、メディアデコーダ９０によるデコードが完了すると、ポストデコーダバッファ１００に出力され、ここで、そのスケジューリングされている再生時刻まで一時保存された後に、再生時刻になると、バッファコントローラ１１０の制御下において、ポストデコーダバッファからディスプレイ／再生装置１２０に伝達されることになる。
本発明によれば、バッファコントローラ１１０は、アプリケーションレベルシグナリングエンジン７０に対して、最小シフト、ターゲットシフト、及び先行送信バイトの最大数に関する通知を提供する。これらのパラメータは、例えば、クライアントのバッファリング制限やデコーディング／再生タイムラインなどに基づいて、ソフトウェアプログラム１１６によって決定される。そして、アプリケーションレベルシグナリングエンジンが、これらの動作レンジレート適合パラメータを表す信号３００をストリーミングサーバー１０に伝送するべく適合されている。これらのパラメータは、例えば、ＲＳＴＰ（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ）を使用することにより、クライアントからサーバーに伝送される。このＲＳＰＴヘッダは、例えば、「３ＧＰＰ−Ｓｈｉｆｔ−Ｐａｒａｍｅｔｅｒｓ」として定義可能である。
サーバーサイトにおいては、サーバーのレートコントローラ３０が、シフトを管理し、これをレート適合レンジ内に維持しつつ、伝送レートを受信レートに対して適合させ、且つ、サンプリングレートを伝送レートに対して適合させるべく動作可能である。又、サーバーは、クライアントに伝送されるパケットにタイムスタンプを付与するための伝送クロック３２をも具備している。サーバーは、ソフトウェアプログラム３６を使用して、クライアントが推奨したパラメータに従って伝送データレートを調節し、クライアントの推奨シフトパラメータを考慮して伝送チャネル上におけるビットレートを変更することによって動作し、これにより、プリデコーダバッファのアンダーフローに起因するクライアントにおける再生の休止や、バッファオーバーフローに起因するクライアントにおけるパケットの消失を回避するべく試みる。
サーバーバッファ４０は、伝送チャネルを介してストリーミングサーバーからストリーミングクライアント６０に伝送する前に、データパケットを一時的に保存する。データパケットをリアルタイムでサンプリングする「ライブ」ストリーミングの環境においては、サーバーバッファは、実際には、サンプリング時間においてデータパケットが配置され、伝送時間において抽出される物理バッファである。一方、データパケットを、リアルタイムサンプリングすることなしに、プリエンコーディングされたファイル内に保存しておき、伝送時間にファイルから読み取る「プリエンコーディング」ストリーミングの環境においては、サーバーバッファは、データパケットのサンプリング時刻（これは、プリエンコーディングされたファイルの最初のデータパケットが伝送される際にストリーミングサーバーにおいて起動するサンプリングクロックに関係するものである）と伝送時刻の間の差を表す仮想バッファである。
又、サーバーは、アプリケーションレベルシグナリングエンジン２０を使用し、セッションの開始時点において、受信側に対して、サーバーが使用を所望するパラメータを表す信号３００を送信することも可能である。この場合には、受信側は、この信号３００が示しているパラメータを考慮し、サーバーレート適合動作レンジのパラメータを選択することになる。そして、サーバーは、その能力に基づいて、この信号３００を使用してクライアントの要求に応答し、サーバーがレート適合に使用可能なパラメータを返すことができる。
（本発明の利点）
従来技術による方法（ＲＴＳＰヘッダ及びビットレートスイッチング）は、多数の制限を具備している。これらの制限の中の１つが、ＲＴＳＰ ＰＬＡＹ要求内においてしか、ＳＰＥＥＤヘッダを送信できないという点である。
・ＰＬＡＹは、バッファ制御のための操作ではなく、むしろ、クライアントからのユーザー要求をサーバーに対して説明することを意図したものであった。
・Ｒａｎｇｅを有する新しいＰＬＡＹ要求に対する応答とサーバーが要求を取得する時点における実際の再生位置が同期することを期待することはできない（即ち、データのスキップ又は再送が発生する可能性がある）。
・提供されているビットレートに対して伝送レートを適合される必要があるため、しばしば、ＲＴＳＰ ＳＰＥＥＤを通じたクライアントの要求どおりに伝送レートを変更することが、まったく不可能である。
これは、ビットレートドメインにおいて稼働しており、受信側は、このビットレートドメインを時間ドメイン（即ち、受信側が所与の量のデータを再生するのに所要する時間量）に直接的にマッピングすることはできない。この理由は、サンプリング曲線が、通常、直線でないことによるものである。
・ＮＷビットレートに整合したビットストリームレートが存在しない可能性がある。
・レシーババッファレベルの減少／増大の中のどの程度の割合が、所与のビットストリーム内のビットレートの変動又はビットストリーム平均レートと伝送レート間の差の蓄積に起因しているのかに関する知識をクライアントが有していない。
・サーバー及びクライアントのタスクが分離されていないため、送信側と受信側におけるサンプリング曲線の成形判定の間に、矛盾が発生する。これは、送信側及び受信側の責任が明瞭に分離されており、受信側は、曲線に対する制約を変更するのみであり、送信側が、それらの制約を満足させるべく曲線の実際の成形を実行するクロックシフトシグナリングとは対照的である。
一方、本発明は、次のような利点を具備している。
・この方式は、プロアクティブに動作するようになっている。この概念は、クライアントが、厳密な動作ポイントではなく、動作レンジを要求する一方で、サーバーが、相対的に制限の少ない柔軟な方式でレート制御を実行できるようにしようというものである。
・この結果、要求サーバーレート適合動作レンジが、明瞭にはっきりと定義され、準拠サーバーの実装が簡単になっている。
・この方式のシグナリングオーバーヘッドは、クライアントからサーバーへのシグナリングに必要な周波数及び速度（即ち、ＲＴＰに同期したもの）を低減することにより、減少している。
・ＲＴＳＰシグナリングを使用することにより、クライアントからサーバーへのレート適合動作レンジ要求メッセージの搬送の信頼性と正しいパイプライン化を実現することができる。これは、シグナリングの速度と周波数に関する要件の緩和と整合している（即ち、もはや矛盾していない）。
要すれば、本発明は、マルチメディアストリーミングネットワークの端末又はクライアント内のレシーババッファのレベルを適応制御する方法及びシステムを提供している。このマルチメディアストリーミングネットワークは、ストリーミングデータをクライアントに提供するネットワーク要素又はサーバーを具備している。このサーバーは、伝送レートの受信レートに対する適合（即ち、輻輳管理）と、サンプリングレートの伝送レートに対する適合の責任を担っている。従って、サーバーは、シフトを管理し、これをレート適合動作レンジ内に維持する。一方、クライアントは、パケット転送遅延変動（これは、ネットワークジッタとも呼ばれる）を補償する責任を担っている。又、クライアントは、サーバーレート適合動作レンジのパラメータを設定する責任をも担っている。クライアントは、シフトパラメータを選択してサーバーに送信するが、これらのパラメータに応答したそのエンコーディングレート又は伝送レートの適合は、サーバーに任されている。
以上、１つ又は複数の実施例との関連で、本発明について説明したが、当業者であれば、本発明の範囲を逸脱することなしに、その形態及び詳細において、以上の及び様々なその他の変更、省略、及び逸脱を実行可能であることを理解するであろう。
サンプリング曲線及び伝送曲線に関するパラメータを定義したプロットである。 ハンドオーバーと、特定のシフトパラメータにおけるレシーババッファレベルに対するその影響を示すプロットである。 本発明によるレート適合方法を実行可能なサーバー装置とクライアント装置を具備したマルチメディアストリーミングシステムを示すブロック図である。

Claims (21)

  1. マルチメディアストリーミングネットワークのクライアント内において、レート適合動作レンジを決定するための少なくとも１つのパラメータを定め、ここで、前記ストリーミングネットワークは、ストリーミングデータを前記クライアントに提供するように構成されたサーバーを有しており、前記クライアントは、前記サーバーによるデータ伝送量と前記クライアントによるストリーミングデータの使用量との差を補償して前記クライアントが中断を伴うことなく再生するに十分な量のストリーミングデータを持つことを可能にするために前記ストリーミングデータの少なくとも一部を格納するレシーババッファを有しており、前記レート適合動作レンジは前記サーバーと前記クライアントの間のレート適合のために用いられ、
    前記少なくとも１つのパラメータを指示する情報を前記サーバーへ提供し、
    前記サーバー内において、前記少なくとも１つのパラメータに基づいて、前記データ量を受信レートに対して適合させ、
    前記クライアント内において、前記適合に基づいて、パケット転送遅延変動を調節すること、
    を有し、前記少なくとも１つのパラメータは、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量、
    前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量、
    送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数、および
    前記クライアント内における再生の中断を防止するためのクロックシフト量のいずれか１つを有する方法。
  2. 前記少なくとも１つのパラメータに基づいて前記サーバー内においてサンプリングレートを前記伝送レートに対して適合させることを更に有する、請求項１記載の方法。
  3. 前記適合は、伝送レートの調節を有する、請求項１記載の方法。
  4. 前記適合は、サンプリングレートの調節を有する、請求項１記載の方法。
  5. 前記適合は、伝送レートとサンプリングレートの両方の調節を有する、請求項１記載の方法。
  6. 前記少なくとも１つのパラメータは、
    前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量と、
    前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量と、
    送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数と、
    クロックシフト量と、
    を有しており、
    前記最小シフト量、前記ターゲットシフト量、前記規定数、及び前記クロックの中の複数のものが一緒に前記サーバーに対して送信される請求項１記載の方法。
  7. 少なくとも１つのクライアントと、
    前記クライアントに対してストリーミングデータを提供するサーバーとを有し、
    前記クライアントは、前記クライアントが、中断を伴うことなしに再生するのに十分な量のストリーミングデータを有するようにするべく、前記サーバーによるデータ伝送量と前記クライアントによるデータ使用量の間の差を補償するレシーババッファを有しており、
    前記クライアントは、
    前記サーバーが、少なくとも１つのパラメータに基づいて、前記データ量を受信レートに対して適合させることができるようにするべく、レート適合動作レンジを決定するための前記少なくとも１つのパラメータを定め、前記少なくとも１つのパラメータを指示する情報をサーバーへ提供するメカニズムと、
    前記適合に基づいて、パケット転送遅延変動を調節するメカニズムと、
    を有し、前記少なくとも１つのパラメータは、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量、
    前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量、
    送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数、および
    前記クライアント内における再生の中断を防止するためのクロックシフト量のいずれか１つを有する、マルチメディアストリーミングネットワーク。
  8. 前記サーバーは、前記少なくとも１つのパラメータに基づいて、サンプリングレートを前記伝送レートに対して適合させる適合メカニズムを有する、請求項７記載のマルチメディアストリーミングネットワーク。
  9. 前記サーバーは、伝送レートを調節する適合メカニズムを有する、請求項７記載のマルチメディアストリーミングネットワーク。
  10. 前記サーバーは、サンプリングレートを調節する適合メカニズムを有する、請求項７記載のマルチメディアストリーミングネットワーク。
  11. 前記サーバーは、伝送レートとサンプリングレートの両方を調節する適合メカニズムを有する、請求項７記載のマルチメディアストリーミングネットワーク。
  12. 前記サーバーは、前記適合を実行する少なくとも１つのコードを具備するソフトウェアプログラムを有する、請求項７記載のマルチメディアストリーミングネットワーク。
  13. マルチメディアストリーミングネットワークのクライアント内において、コンピュータにレート適合動作レンジを決定する少なくとも１つのパラメータを定めさせるためのプログラミングコードと、ここで、前記ストリーミングネットワークは、ストリーミングデータを前記クライアントに提供するように構成されたサーバーを有しており、前記クライアントは、前記サーバーによるデータ伝送量と前記クライアントによるストリーミングデータの使用量との差を補償して前記クライアントが中断を伴うことなく再生するに十分な量のストリーミングデータを持つことを可能にするために前記ストリーミングデータの少なくとも一部を格納するレシーババッファを有しており、前記少なくとも１つのパラメータを指示する情報が、前記サーバーが前記少なくとも１つのパラメータに基づいて前記サーバーと前記クライアントの間でのレート適合を実行できるようにするために、前記サーバーへ提供され、
    前記クライアント内において、前記レート適合のためにコンピュータにパケット転送遅延変動を調節させるためのプログラミングコードと、
    を有し、前記少なくとも１つのパラメータは、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量、
    前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量、
    送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数、および
    前記クライアント内における再生の中断を防止するためのクロックシフト量のいずれか１つを有するプログラム。
  14. マルチメディアストリーミングネットワーク内のサーバーによる伝送量と装置内のデータ使用量との差を補償して十分な量のストリーミングデータが中断を伴うことなく再生されることを可能にするために、前記サーバーが提供するストリーミングデータの少なくとも一部を格納するバッファと、
    前記サーバーが、前記少なくとも１つのパラメータに基づいて、前記データ伝送量を受信レートに対して適合させることができるようにするべく、前記サーバー内のレート適合動作レンジを決定する少なくとも１つのパラメータを定めるメカニズムと、
    前記適合に基づいて、パケット転送遅延変動を調節するメカニズムと、
    を有し、前記少なくとも１つのパラメータは、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量、
    前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量、
    送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数、および
    前記クライアント内における再生の中断を防止するためのクロックシフト量のいずれか１つを有する装置。
  15. 前記定めるメカニズムは、前記少なくとも１つのパラメータを定める少なくとも１つのコードを具備するソフトウェアプログラムを有する、請求項１４記載の装置。
  16. 前記調節メカニズムは、前記パケット転送遅延変動を調節する少なくとも１つのコードを具備するソフトウェアプログラムを有する、請求項１４記載の装置。
  17. マルチメディアストリーミングネットワークのネットワーク要素であって、
    クライアントからの要求を受信する受信モジュールと、ここで、前記クライアントは、前記クライアントが中断を伴うことなく再生するに十分な量のストリーミングデータを有するように、前記ネットワーク要素によるデータ伝送量と前記クライアントによるデータ使用量との差を補償するために前記ネットワーク要素によって提供される前記ストリーミングデータの少なくとも一部を格納するレシーババッファを有しており、前記要求は、前記ネットワーク要素内におけるレート適合動作レンジを決定する少なくとも１つのパラメータを表しており、
    前記少なくとも１つのパラメータに基づいて、前記データ伝送レートを前記クライアントによる受信レートに対して適合させて、前記適合に基づいて、前記クライアントがパケット転送遅延変動を調節できるようにするメカニズムと、
    を有し、前記少なくとも１つのパラメータは、前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を表す最小シフト量、
    前記サーバーにおけるパケットのサンプリング時刻と伝送時刻の間の差を上回るシフト量を表す目標シフト量、
    送信されたバイト数とサンプリングされたバイト数の間の最大の差を規定する数、および
    前記クライアント内における再生の中断を防止するためのクロックシフト量のいずれか１つを有する、ネットワーク要素。
  18. 前記調節メカニズムは、前記データ伝送量を適合させる少なくとも１つのコードを具備するソフトウェアプログラムを有する、請求項１７記載のネットワーク要素。
  19. 前記ソフトウェアプログラムは、前記伝送レートを適合させるコードを有する、請求項１８記載のネットワーク要素。
  20. 前記ソフトウェアプログラムは、サンプリングレートを調節するコードを有する、請求項１８記載のネットワーク要素。
  21. 前記ソフトウェアプログラムは、伝送レートとサンプリングレートの両方を調節するコードを有する、請求項１８記載のネットワーク要素。
JP2006506514A 2003-04-24 2004-04-23 プロアクティブなレート適合シグナリング方法及び装置 Expired - Fee Related JP4347883B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US46512003P 2003-04-24 2003-04-24
US10/826,687 US7844727B2 (en) 2003-04-24 2004-04-16 Method and device for proactive rate adaptation signaling
PCT/IB2004/001243 WO2004097660A1 (en) 2003-04-24 2004-04-23 Method and device for proactive rate adaptation signaling

Publications (2)

Publication Number Publication Date
JP2006524452A JP2006524452A (ja) 2006-10-26
JP4347883B2 true JP4347883B2 (ja) 2009-10-21

Family

ID=33423544

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006506514A Expired - Fee Related JP4347883B2 (ja) 2003-04-24 2004-04-23 プロアクティブなレート適合シグナリング方法及び装置

Country Status (13)

Country Link
US (1) US7844727B2 (ja)
EP (1) EP1616267B1 (ja)
JP (1) JP4347883B2 (ja)
KR (1) KR20060011964A (ja)
AT (1) ATE446631T1 (ja)
DE (1) DE602004023710D1 (ja)
DK (1) DK1616267T3 (ja)
ES (1) ES2332315T3 (ja)
MX (1) MXPA05011247A (ja)
MY (1) MY140711A (ja)
RU (1) RU2367011C2 (ja)
TW (1) TWI266201B (ja)
WO (1) WO2004097660A1 (ja)

Families Citing this family (37)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2515952A1 (en) * 2003-02-13 2004-08-26 Nokia Corporation Method for signaling streaming quality adaptation and control mechanisms in multimedia streaming
FR2857198B1 (fr) * 2003-07-03 2005-08-26 Canon Kk Optimisation de qualite de service dans la distribution de flux de donnees numeriques
JP4183586B2 (ja) * 2003-09-12 2008-11-19 三洋電機株式会社 映像表示装置
US8868772B2 (en) * 2004-04-30 2014-10-21 Echostar Technologies L.L.C. Apparatus, system, and method for adaptive-rate shifting of streaming content
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
US7571246B2 (en) * 2004-07-29 2009-08-04 Microsoft Corporation Media transrating over a bandwidth-limited network
US7536469B2 (en) * 2004-12-10 2009-05-19 Microsoft Corporation System and process for controlling the coding bit rate of streaming media data employing a limited number of supported coding bit rates
US20060143678A1 (en) * 2004-12-10 2006-06-29 Microsoft Corporation System and process for controlling the coding bit rate of streaming media data employing a linear quadratic control technique and leaky bucket model
US7543073B2 (en) * 2004-12-10 2009-06-02 Microsoft Corporation System and process for performing an exponentially weighted moving average on streaming data to establish a moving average bit rate
KR20060065482A (ko) * 2004-12-10 2006-06-14 마이크로소프트 코포레이션 스트리밍 미디어 데이터의 코딩 비트 레이트의 제어 시스템및 프로세스
TWI401918B (zh) * 2005-02-03 2013-07-11 Nokia Corp 傳送指示接收器緩衝架構之緩衝參數信號的通訊方法
US20060184697A1 (en) * 2005-02-11 2006-08-17 Microsoft Corporation Detecting clock drift in networked devices through monitoring client buffer fullness
US8370514B2 (en) 2005-04-28 2013-02-05 DISH Digital L.L.C. System and method of minimizing network bandwidth retrieved from an external network
US8683066B2 (en) 2007-08-06 2014-03-25 DISH Digital L.L.C. Apparatus, system, and method for multi-bitrate content streaming
JP4274149B2 (ja) * 2005-05-19 2009-06-03 ソニー株式会社 コンテンツ再生装置及びコンテンツ再生方法
US7743183B2 (en) 2005-05-23 2010-06-22 Microsoft Corporation Flow control for media streaming
US8214516B2 (en) * 2006-01-06 2012-07-03 Google Inc. Dynamic media serving infrastructure
US7962637B2 (en) * 2006-11-03 2011-06-14 Apple Computer, Inc. Dynamic adjustments of video streams
KR100899659B1 (ko) * 2006-12-01 2009-05-27 한국전자통신연구원 패킷 스케줄러 및 패킷 스케줄링 방법
FR2923118B1 (fr) * 2007-10-30 2016-04-01 Canon Kk Procede, dispositif et programme d'ordinateur pour la gestion de la quantite de donnees emises par un dispositif d'emission
US8370622B1 (en) * 2007-12-31 2013-02-05 Rockstar Consortium Us Lp Method and apparatus for increasing the output of a cryptographic system
US8305899B2 (en) * 2008-05-28 2012-11-06 Microsoft Corporation Pull-based data transmission approach
KR20110045086A (ko) * 2008-08-28 2011-05-03 쿄세라 코포레이션 무선 단말 및 통신 단말
WO2010111261A1 (en) * 2009-03-23 2010-09-30 Azuki Systems, Inc. Method and system for efficient streaming video dynamic rate adaptation
KR20110065100A (ko) * 2009-12-09 2011-06-15 삼성전자주식회사 멀티미디어 스트리밍 서비스를 지원하는 방법 및 장치
WO2011102791A1 (en) * 2010-02-19 2011-08-25 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for representation switching in http streaming
US9439100B2 (en) * 2012-06-27 2016-09-06 Aruba Networks, Inc. System and method for dynamic rate adaptation based on real-time call quality metrics
US9131251B2 (en) * 2012-09-20 2015-09-08 Google Technology Holdings LLC Use of a receive-window size advertised by a client to a content server to change a video stream bitrate streamed by the content server
US9462021B2 (en) 2012-09-24 2016-10-04 Google Technology Holdings LLC Methods and devices for efficient adaptive bitrate streaming
US9544344B2 (en) * 2012-11-20 2017-01-10 Google Technology Holdings LLC Method and apparatus for streaming media content to client devices
US9137285B2 (en) * 2013-10-21 2015-09-15 Broadcom Corporation Adaptive audio video (AV) stream processing
WO2017063189A1 (en) * 2015-10-16 2017-04-20 Qualcomm Incorporated Deadline signaling for streaming of media data
KR102532645B1 (ko) * 2016-09-20 2023-05-15 삼성전자 주식회사 적응적 스트리밍 서비스에서 스트리밍 어플리케이케이션으로 데이터를 제공하는 방법 및 장치
US10741143B2 (en) * 2017-11-28 2020-08-11 Nvidia Corporation Dynamic jitter and latency-tolerant rendering
US10691082B2 (en) * 2017-12-05 2020-06-23 Cisco Technology, Inc. Dynamically adjusting sample rates based on performance of a machine-learning based model for performing a network assurance function in a network assurance system
US11350268B2 (en) * 2018-05-18 2022-05-31 Qualcomm Incorporated End-to-end rate adaptation using RAN assisted rate adaptation
CN111246284B (zh) * 2020-03-09 2021-05-25 深圳创维－Rgb电子有限公司 视频流播放方法、系统、终端及存储介质

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5543853A (en) 1995-01-19 1996-08-06 At&T Corp. Encoder/decoder buffer control for variable bit-rate channel
KR0176806B1 (ko) * 1995-12-29 1999-05-01 구자홍 텔레비젼의 2화면 구성장치
US6175856B1 (en) * 1996-09-30 2001-01-16 Apple Computer, Inc. Method and apparatus for dynamic selection of compression processing during teleconference call initiation
EP0847171A1 (en) 1996-11-27 1998-06-10 Sony Europa B.V. Method and device for streaming data, including provision of write addresses
US6292834B1 (en) * 1997-03-14 2001-09-18 Microsoft Corporation Dynamic bandwidth selection for efficient transmission of multimedia streams in a computer network
US5903673A (en) * 1997-03-14 1999-05-11 Microsoft Corporation Digital video signal encoder and encoding method
JP3734946B2 (ja) 1997-12-15 2006-01-11 松下電器産業株式会社 データ送出装置、データ受信装置及びデータ伝送装置
JP3589851B2 (ja) * 1998-02-20 2004-11-17 株式会社日立製作所 パケット通信システム及びパケット通信装置
US6643259B1 (en) * 1999-11-12 2003-11-04 3Com Corporation Method for optimizing data transfer in a data network
US6700893B1 (en) 1999-11-15 2004-03-02 Koninklijke Philips Electronics N.V. System and method for controlling the delay budget of a decoder buffer in a streaming data receiver
US7016970B2 (en) * 2000-07-06 2006-03-21 Matsushita Electric Industrial Co., Ltd. System for transmitting stream data from server to client based on buffer and transmission capacities and delay time of the client
EP1307615B1 (en) * 2000-08-01 2004-10-06 Unilever Plc Textile treatment process
US7346698B2 (en) 2000-12-20 2008-03-18 G. W. Hannaway & Associates Webcasting method and system for time-based synchronization of multiple, independent media streams
DE10102154C2 (de) * 2001-01-18 2003-02-13 Fraunhofer Ges Forschung Verfahren und Vorrichtung zum Erzeugen eines skalierbaren Datenstroms und Verfahren und Vorrichtung zum Decodieren eines skalierbaren Datenstroms unter Berücksichtigung einer Bitsparkassenfunktion
JP2003158543A (ja) * 2001-11-22 2003-05-30 Anritsu Corp 中継装置及び中継方法
KR100420601B1 (ko) * 2001-11-22 2004-03-02 에스케이 텔레콤주식회사 비디오 데이터 스트리밍 서비스 방법
EP1359722A1 (en) * 2002-03-27 2003-11-05 BRITISH TELECOMMUNICATIONS public limited company Data streaming system and method
US7305483B2 (en) * 2002-04-25 2007-12-04 Yahoo! Inc. Method for the real-time distribution of streaming data on a network
US7133925B2 (en) * 2002-07-15 2006-11-07 Hewlett-Packard Development Company, L.P. System, method, and format thereof for scalable encoded media delivery
EP1532540A4 (en) * 2002-07-16 2010-06-02 Nokia Corp METHOD FOR ENHANCING PACKET TRANSFER DELAY COMPENSATION IN MULTIMEDIA STR MEN
SG111978A1 (en) * 2002-11-20 2005-06-29 Victor Company Of Japan An mpeg-4 live unicast video streaming system in wireless network with end-to-end bitrate-based congestion control
US6968387B2 (en) * 2003-01-10 2005-11-22 Realnetworks, Inc. Stochastic adaptive streaming of content

Also Published As

Publication number Publication date
RU2367011C2 (ru) 2009-09-10
DE602004023710D1 (de) 2009-12-03
EP1616267B1 (en) 2009-10-21
ES2332315T3 (es) 2010-02-02
EP1616267A1 (en) 2006-01-18
WO2004097660A1 (en) 2004-11-11
EP1616267A4 (en) 2007-08-15
DK1616267T3 (da) 2010-01-04
MY140711A (en) 2010-01-15
US20040267956A1 (en) 2004-12-30
MXPA05011247A (es) 2005-12-14
KR20060011964A (ko) 2006-02-06
TW200508883A (en) 2005-03-01
TWI266201B (en) 2006-11-11
US7844727B2 (en) 2010-11-30
ATE446631T1 (de) 2009-11-15
RU2005136435A (ru) 2006-06-10
JP2006524452A (ja) 2006-10-26

Similar Documents

Publication Publication Date Title
JP4347883B2 (ja) プロアクティブなレート適合シグナリング方法及び装置
US7558869B2 (en) Rate adaptation method and device in multimedia streaming
EP2415234B1 (en) Adaptive bitrate management for streaming media over packet networks
US8230105B2 (en) Adaptive bitrate management for streaming media over packet networks
KR100629158B1 (ko) 스트리밍된 데이터를 버퍼링하기 위한 방법 및 시스템
US20050254508A1 (en) Cooperation between packetized data bit-rate adaptation and data packet re-transmission
JP2004172830A (ja) 動画像符号化ビットレート選択方式
JP2007089137A (ja) ロバストなストリーミングを行うためのサーバメディア処理による適応型メディアプレイアウト
EP1532540A2 (en) Method for enabling packet transfer delay compensation in multimedia streaming
JP2003515289A (ja) ストリーミングデータ受信器における復号器バッファの遅延割当量を制御するためのシステムと方法
EP2710778B1 (en) Method for dynamic adaptation of the reception bitrate and associated receiver
EP3391652A1 (en) Controlling retrieval in adaptive streaming
ZA200508487B (en) Method and device for proactive rate adaptation signaling
CN115695846A (zh) 一种连续隧道场景下优化自适应码率视频调度方法和系统

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080422

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20080718

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20080728

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080925

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090113

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090413

A911 Transfer to examiner for re-examination before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20090528

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: 20090616

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20090716

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20120724

Year of fee payment: 3

LAPS Cancellation because of no payment of annual fees