JP4838143B2 - 送信装置 - Google Patents
送信装置 Download PDFInfo
- Publication number
- JP4838143B2 JP4838143B2 JP2006544846A JP2006544846A JP4838143B2 JP 4838143 B2 JP4838143 B2 JP 4838143B2 JP 2006544846 A JP2006544846 A JP 2006544846A JP 2006544846 A JP2006544846 A JP 2006544846A JP 4838143 B2 JP4838143 B2 JP 4838143B2
- Authority
- JP
- Japan
- Prior art keywords
- transmission
- rate
- packet
- delay
- time
- 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
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0015—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy
- H04L1/0019—Systems modifying transmission characteristics according to link quality, e.g. power backoff characterised by the adaptation strategy in which mode-switching is based on a statistical approach
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0002—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the transmission 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L1/00—Arrangements for detecting or preventing errors in the information received
- H04L1/0001—Systems modifying transmission characteristics according to link quality, e.g. power backoff
- H04L1/0009—Systems modifying transmission characteristics according to link quality, e.g. power backoff by adapting the channel coding
-
- 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)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- Probability & Statistics with Applications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Detection And Prevention Of Errors In Transmission (AREA)
- Communication Control (AREA)
Description
［技術分野］
【０００１】
本発明は、ストリームデータの送受信において、データ伝送の遅延時間やパケットロス率を求め、それに基づいて回線品位や帯域余裕を考慮して最適なエンコードレートを与えるように制御する送信装置に関する。
［背景技術］
［０００２］
インターネット等のネットワークでは、伝送帯域や回線品位等の原因により、データ伝送に遅延が生じ、さらにはパケットが失われたり、伝送遅延にジッタが発生したりする。このため、映像や音声情報のような連続メディアを圧縮して得られたストリームデータを伝送して連続再生する場合、データ伝送品質の劣化を生じてしまい、スムーズな再生が困難となる場合がある。
［０００３］
すなわち、ネットワークは有限長のキューと有限帯域の回線の連鎖と考えられる。回線の帯域以上のデータを流そうとすると、キューに蓄積され、伝送にかかる遅延が増大する。さらに帯域以上のデータを流し続けるとついにはキューがオーバフローしてパケットが失われる。また、伝送の品質が悪い回線では、データ量とは無関係にパケットが失われたり、パケットの順序が変わったり、伝送遅延に揺らぎが発生したりする。
［０００４］
そこで、例えば後述する特許文献１に開示されているように、データ受信側の品質低下をできる限り抑えて、効率的にデータ伝送ができるように、エンコードレートを制御する。
［０００５］
図１１は、従来の通信システムを示すブロック図である。図示都合上、Ａ点を境にして（ａ）、（ｂ）に分割して示している。送信側は、カメラ１０１、リアルタイムエンコーダ１０２、送信制御部１０３を備え、受信側は、受信制御部１１１、リアルタイムデコーダ１１２、再生表示部１１３を備える。送信側と受信側はネットワーク１０５を介して接続されている。
［０００６］
同図（ａ）の送信側において、カメラ１０１から入力された映像情報は、リアルタイムエンコーダ１０２において、送信制御部１０３により指定された送出ビットレートでリアルタイムエンコードされる。リアルタイムエンコーダ１０２における送出ビットレートは、送信制御部１０３からのビットレートフィードバック情報により指定される。
【０００７】
この送出のデータフォーマットは、送信したパケットの順序ならびに再生タイミングが受信側で分かるようにパケット毎にシリアル番号が付与され、そのパケットに含まれるデータの再生タイミングを表すタイムスタンプも同様に付与されたものとなっている。このようなフォーマットとしてはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が広く使われている。また、ＲＴＰを使った伝送を制御するためにＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が広く使われている。本発明、ならびに従来技術はＲＴＰ／ＲＴＣＰに限定されるものではないが、以下では簡単のため広く理解されうるＲＴＰ／ＲＴＣＰを想定したシステムについて説明する。
【０００８】
ネットワーク１０５により伝送された映像データパケットは、図（ｂ）の受信側の受信制御部１１１により受信される。受信制御部１１１において、受信した映像データパケットに格納されているシリアル番号に基づいて映像データパケットのロスや到着順序入替り、重複受信などのイレギュラーな映像データパケットの受信状況が検出される。再生時刻に間に合ったと判定された映像データパケットからは、そのペイロード内に格納されている映像データが取り出される。再生時刻に間にあわない映像データパケットは捨てられる。この映像データは、タイムスタンプと共にリアルタイムデコーダ１１２に渡されてリアルタイムでデコードされた後、タイムスタンプに従って再生表示部１１３において再生表示される。
【０００９】
送信制御部１０３からは、映像データパケット以外に、ネットワークの品質パラメータを測定し輻輳状態を判定するために、コントロール情報を伝えるＳＲ（Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ）パケット（以下、ＳＲパケットという。）が送出される。このＳＲパケットは、送信制御部１０３から図１（ｂ）の受信側の受信制御部１１１に対して定期的に送出される。ＳＲパケットのフォーマット中には送信した時の時刻情報（送信タイムスタンプ）が含まれている。
【００１０】
また、ＳＲパケットを受信すると受信制御部１１１から送信制御部１０３に対してコントロール情報を伝えるＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）パケット（以下、ＲＲパケットという。）が送出される。このＲＲパケットのフォーマット中には、受信したＳＲパケット中に含まれていた送信タイムスタンプ情報および受信側がＳＲパケットを受信してからＲＲパケットを送信するまでの経過時間情報が格納される。
【００１１】
ＲＲパケットを受信した送信制御部１０３おいて、コントロールパケット（ＳＲパケット、ＲＲパケット）の往復伝播遅延（ラウンドトリップタイム：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を下記（１）式により求めることができる。
Ｔｒｎｄ＝（Ｔｒｃｖ−Ｔｓｎｄ）−Ｔｓｔａｙ・・・（１）
ここで、
Ｔｒｎｄ：コントロール信号パケットの往復伝播遅延、
Ｔｒｃｖ：送信制御部がＲＲパケットを受信した時刻、
Ｔｓｎｄ：送信制御部が受信したＲＲパケットに対応するＳＲパケットを送信した時刻（ＲＲパケットに格納されている送信タイムスタンプ情報）、
Ｔｓｔａｙ：受信制御部がＳＲパケットを受信してからＲＲパケットを送信するまでの時間（ＲＲパケットに格納されている経過時間情報）、
である。
【００１２】
また、ＲＲパケットのフォーマット中には、受信制御部１１１で受信された映像データパケットに関するパケットロス率と伝播遅延のゆらぎを表すジッタ情報などのネットワークの輻輳情報も格納される。
【特許文献１】
特開２００３−２４４６９５
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記従来技術で伝送レート制御に用いられているラウンドトリップタイム（以降ＲＴＴと呼ぶ）は、送受信装置それぞれの計時部間のずれの影響を受けないため、算出しやすい。しかし、ＲＴＴは送信装置から受信装置に向けての伝送遅延だけではなく、受信装置から送信装置に向けての伝送遅延の影響を受けてしまう。ここで、受信装置から送信装置に至るまでの逆方向の遅延は、送信装置が送り出すストリームデータの伝送レートには無関係であり、このような要素の影響を受けることは正確な伝送レート制御の妨げとなっている。このような悪影響は回線の帯域が非対称なＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）において顕著に表れる。
［００１４］
また、図１２に示すように、送信レートを徐々に増加させていくと、最初、遅延時間は一定で、受信レートが送信レートに一致して上昇していく。送信レートが回線帯域に達すると、受信レートは頭打ちとなり、ネットワーク中のキューにデータが蓄積されることによる伝送遅延の増加が観測される。さらに送信レートが回線帯域を越える状態が継続するとパケットロスが発生し、送信したデータの一部が失われる。この状態では、送信データを単に捨てることになるため、送信レートを高めても再生される映像や音声の品質は向上しないばかりかデータの欠落による品位の悪化をもたらすことになる。そのため、上記従来技術はパケットロス率だけが上昇した場合でも、伝送レートを下げるように制御する。しかしながら、パケットロスは送信装置の過剰な伝送レート以外の原因によって発生する可能性があり、この場合に伝送レートを下げたとしても伝送される映像や音声の品位が低下するだけでパケットロス率は低下しない。
【００１５】
本発明は、斯かる実情に鑑み、データ伝送の遅延時間やパケットロス率を求め、それらに基づいて回線品位や帯域余裕を考慮して最適なエンコードレートを与えるように制御する送信装置を提供しようとするものである。
【００１６】
本発明の送信装置は、ストリームデータを送信し、受信装置が受信して求めたストリームデータの伝送遅延及びパケットロス率に基づき、エンコードレートを制御し、前記ストリームデータを送信する送信装置であって、制御に使用する前記伝送遅延は、少なくとも通信開始時の遅延を基準とする増減値であり、前記伝送遅延が増加しない場合には、前記パケットロス率の程度及び前記ストリームデータを送信する帯域の余裕に応じて前記エンコードレートを変更し、前記ストリームデータを制御し、前記伝送遅延が増加した場合には、前記エンコードレートを絞り、送信するレートを低減するように前記ストリームデータを制御することを特徴とする。
【００１７】
本発明の送信装置は、ストリームデータを送信し、受信装置が受信して求めたストリームデータの伝送遅延及びパケットロス率に基づき、エンコードレートを制御し、前記ストリームデータを送信する送信装置であって、制御に使用する前記伝送遅延は、送信開始からの前記通信遅延の最小値を基準とする増減値であり、前記伝送遅延が増加しない場合には、前記パケットロス率の程度及び前記ストリームデータを送信する帯域の余裕に応じて前記エンコードレートを変更し、前記ストリームデータを制御し、前記伝送遅延が増加した場合には、前記エンコードレートを絞り、送信するレートを低減するように前記ストリームデータを制御することを特徴とする。
［００１８］
［００１９］
［００２０］
［００２１］
［００２２］
［００２３］
［００２４］
［００２５］
［００２６］
［００２７］
［発明の効果］
［００２８］
本発明によれば、送信装置が送ったストリームデータに基づいて、受信装置が伝送遅延及びパケットロス率を求め、その求めた値によって送信側が送信ビットレート又はエンコードレートを制御するので、ＩＰ網のような、不安定なネットワークにおいても、乱れを最小限にとどめた状態でデータを送受信できる。特に、送信装置から受信装置への一方向の伝送遅延やパケットロス率を求めているので、ＲＴＴのように不要な方向の遅延の影響を受けずに済む。
【図面の簡単な説明】
【００２９】
【図１】本発明の通信システムの一実施形態を示すブロック図である。
【図２】回線品位、帯域余裕を軸にネットワーク状態を示す説明図である。
【図３】ソース装置とシンク装置の制御内容を示す表である。
【図４】初期適応期間後の基準遅延設定期間を設ける説明図である。
【図５】所定の算定期間毎に、遅延時間の平均値を求めて基準遅延時間とする説明図である。
【図６】回線帯域の変動に応じてエンコードレートを変更する状況を示す説明図である。
【図７】デッドタイムを設けたエンコード設定手順を示すフローチャートである。
【図８】エンコードレートを変更直後から応答時間内にエンコードレートを越えるエンコードデータを捨てる状況を示す説明図である。
【図９】エンコードレートを超えるデータは捨てる手順を示すフローチャートである。
【図１０】エンコードレートを超えたＩフレーム以外のパケットデータを破棄する場合の送信状況を示す説明図である。
【図１１】従来の通信システムを示すブロック図である。
【図１２】回線帯域に対する送信レートの増加によるネットワーク状態を示す説明図である。
【図１３】拡張ヘッダ部分に送信タイムスタンプを入れたＲＴＰパケットの構造を示す説明図である。
【符号の説明】
【００３０】
１０ ソース装置
１１ エンコード部
１２ パケット送信部
１３ 計時部
１４ ネットワークインターフェース
１５ パケット受信部
１６ 回線帯域推定部
２０ シンク装置
２０ ソース装置
２１ ネットワークインターフェース
２２ パケット受信部
２３ 統計データ取得部
２４ パケット送信部
２５ デコード部
２６ 計時部
３０ ネットワーク
【発明を実施するための最良の形態】
【００３１】
以下、本発明の実施の形態を添付図面を参照して説明する。
【００３２】
図１は、本発明の通信システムの一実施形態を示すブロック図である。この通信システムは送信側のソース装置１０、インターネット等のネットワーク３０、受信側のシンク装置２０から構成されている。ネットワーク３０としているが、この部分はソース装置１０とシンク装置２０を繋ぐ単なる回線でも構わない。
【００３３】
ソース装置１０は、エンコード部１１、パケット送信部１２、計時部１３、ネットワークインターフェース１４、パケット受信部１５、回線帯域推定部１６とから構成される。また、シンク装置２０は、ネットワークインターフェース２１、パケット受信部２２、統計データ取得部２３、パケット送信部２４、デコード部２５、計時部２６とから構成される。
【００３４】
この通信システムの送受信装置は、このソース装置１０とシンク装置２０を一組備え、互いにデータの送受信を行っている。
【００３５】
ソース装置１０に入力された映像音声は、エンコード部１１で例えばＭＰＥＧ４にエンコードされ、パケット送信部１２でＲＴＰパケットに分割されて、ネットワークインターフェース１４を介してネットワーク３０に送出される。このとき、パケットには計時部１３で計測されている時刻がタイムスタンプとして付与される。
【００３６】
シンク装置２０は、ネットワークインターフェース２１を介して受け取ったＲＴＰパケットをパケット受信部２２にてＭＰＥＧ４ストリームに組み立て、デコード部２５によりデコードして映像音声を出力する。またパケット受信部２２では、パケットの通し番号やパケットサイズ、タイムスタンプなどの情報を抽出して、統計データ取得部２３により片側遅延時間、パケットロス率、受信レート等の統計データを算出する。パケット送信部２４では、片方向遅延を伝送するために拡張したＲＴＣＰパケットによって統計データをネットワークインターフェース２１を介してシンク装置２０からソース装置１０に向けて送信する。
【００３７】
ソース装置２０でネットワークインターフェース１４を介して受信された統計情報は、パケット受信部１５にて抽出されて回線帯域推定部１６に入力され、回線帯域推定部１６はエンコード部１１に対して最適なエンコードを与えるよう指示する。
【００３８】
次に、それぞれの領域でソース側、シンク側で行うべき制御の概要を示す。
【００３９】
発明が解決しようとする課題の項目において説明したように、一般に、送信レートを徐々に増加させていくと、最初、遅延時間は一定で、受信レートが送信レートに一致して上昇していく。送信レートが回線帯域に達すると、受信レートは頭打ちになり、ネットワーク中のキューにデータが蓄積されることによる伝送遅延の増加が観測される。さらに送信レートが回線帯域を越える状態が継続するとパケットロスが発生し、送信したデータの一部が失われる。この状態では遅延時間は飽和する。
【００４０】
ここで、回線品位、帯域余裕（＝回線帯域−送信レート）を軸にネットワーク状態を整理すると図２に示すようになる。縦軸に回線品位、横軸に帯域余裕を設ける。
まず、第１象限は問題のない領域であり、回線品位が高いためパケットロス率は小さく、また右に行くに従って、帯域余裕は大きくなるため送信レートの微細な揺らぎに伴う遅延変動も少なくなる。この領域においては特に、送信ビットレートやエンコードレートを制御する必要はない。
【００４１】
第２，第３象限は、帯域が不足している領域であり、伝送遅延が増加中／一定があるので、便宜上斜めの線で区切っている。斜め線の上側は帯域不足で遅延大、パケットロス率が大である。また、斜め線の下側は、遅延が増大し、帯域がやや不足している。なお、第２象限においては、回線品位がよいので、斜め線の下側は、パケットロス率は少ない。第３象限においては、回線品位がよくないので、斜め線の下側は、パケットロス率は中程度である。これら領域では帯域不足を解消するため、伝送遅延とパケットロス率に基づいて、損失データをできる限り抑えるように、送信ビットレートやエンコードレートを制御する。本発明は、これら第２，第３象限における制御に関するものである。
【００４２】
第４象限は、帯域余裕はあるが、回線品位が低い領域であり、遅延変動を起こし、パケット率も中程度であるが、これらは回線品位に起因するため、ソース装置における制御によって伝送品位が改善する見込みはなく制御を行う必要はない。
【００４３】
図３は、ソース装置とシンク装置の制御内容を示す表である。各項目毎にソース装置とシンク装置の制御内容を説明する。
伝送良好の場合は、ソース装置とシンク装置共に現状維持である。帯域余裕が大きい場合は、ソース装置はエンコードレートを増加させて伝送効率を増加させ、シンク装置は現状維持とする。帯域余裕がない場合は、ソース装置とシンク装置共に現状維持かエンコードレートをやや減少させる。伝送品質が低い場合は、ソース装置は現状維持で、シンク装置はデータのエラー補正を行う。帯域が不足している場合は、ソース装置はエンコードレートを受信レートに変更し、シンク装置はエラーコンシールメント、すなわちエラーを隠す処理を行う。例えば、動画の壊れたフレームを捨てその間静止画を表示するなどの処理である。帯域がやや不足している場合は、ソース装置はエンコードレートを減少させ、シンク装置は遅延パケットを破棄する。
各項目ではこのような制御が考えられるが、次に伝送品位と帯域余裕を考慮した具体的制御について説明する。
【００４４】
このような制御を行うには、まず遅延時間を求めなければならない。遅延時間を求めるためには、シンク装置２０で受信した時刻から、ソース装置１０で付与されたタイムスタンプを引けばよい。しかし、ソース装置１０、シンク装置２０のそれぞれの計時部１３と計時部２６を正確に同期させることは困難である。そこで、シンク装置２０は、ネットワーク３０の標準的な遅延時間を基準遅延時間として求め、これを０とみなして、求めた遅延時間を補正する。つまり、
遅延時間＝パケット受信時刻−送信タイムスタンプ−基準遅延時間・・・（２）
となる。
【００４５】
図４に示すように、通信開始直後の初期適応期間は遅延時間やパケットロス率等が求められておらず過大な送信を行う可能性があるため、この期間の遅延時間は無視する。通信安定後、基準遅延設定期間を設けて、この期間の遅延時間を測定し、この遅延時間を平均して、基準遅延時間とする。
【００４６】
しかし、インターネット等のネットワークにおいては、データ伝送経路が変わる可能性があり、そのため回線品位や帯域余裕等が変化し、突然遅延時間が変化する可能性がある。そこで、基準遅延時間により補正した遅延時間が、通信中に大きくマイナスに振れた場合、平均値である基準遅延時間基準遅延時間を見直す。詳しくは、式（２）で求められる遅延時間が、あらかじめ定めておいた基準値（例えば、−２００ｍｓｅｃ）を下回ったときに、再び、基準遅延設定期間だけ遅延時間を測定し、その平均値を基準遅延時間とする。
【００４７】
また、図５に示すように、所定の算定期間毎に、遅延時間の平均値を求めて基準遅延時間とする方法もある。そして、算定期間中は、前回の算定期間中に求めた基準遅延時間を用いて遅延時間を求める。こうして基準遅延時間を定期的に見直すことにより、求める遅延時間に大きな誤差が生じないようにしている。
片方向遅延の測定方法に関して、ＲＴＣＰを利用する方法の他に、ＲＴＰパケットの拡張ヘッダ部分に送信タイムスタンプを入れることで、パケット単位で測定することができる。送信タイムスタンプを含んだＲＴＰパケットフォーマットは、例えば図１３のようになる。
ＲＴＣＰの送信間隔は、あまり短くすることができないが、ＲＴＰパケットに送信タイムスタンプを入れる方法では、例えば１０パケット間隔で、片方向遅延の平均値や最大値で増減傾向を判断することによって、より迅速かつ正確に輻輳状態を把握することができる。
【００４８】
また、基準遅延時間の他の求め方としては、それまでの遅延時間の最小値を用いる方法もある。通信開始からすべてのパケットの遅延時間の最小値を遅延時間とみなす方法だけではなく、現時刻から一定期間さかのぼった範囲だけで最小値を求める方法や、図５と同様にオーバラップさせながら最小値を更新していく方法もある。
【００４９】
さて、こうして求めた遅延時間に基づいて、ソース装置１０のエンコード部１１は、エンコードレートを回線帯域に対して、エンコーダの出力揺らぎ、他のトラヒックのための余裕帯域を加味して決定する。
【００５０】
回線帯域が一時的に減少した際にはパケットロス率、片側伝送遅延などからこれを検出して、エンコードレートを絞る操作を行う。遅延の増加が見られる段階では、エンコードレートを少し絞るような制御を行う。詳しくは、以下のとおりである。
【００５１】
（１）送信遅延が上昇したときには、遅延を解消するために必要な分送信レートを落とす。
（２）送信遅延が上昇したと判断する閾値は、通常時の遅延が２００ｍｓｅｃ以下であると仮定し、その２倍の４００ｍｓｅｃとする。
（３）遅延／送信レートの計測結果より、送信レートを１０％落とす。送信レートを落とした後、３秒後に送信遅延が減少していなかったら再度１０％落とす。
【００５２】
送信レートが回線帯域を大幅に上回っているためにパケットロスが発生していると考えられる場合には、受信レートを参考にエンコードレートを定める。この状況には、回線品位が低いためにパケットロスが発生している状況を含まない。例えば、図６に示すように、初期適応期間においては、ソース装置１０のエンコード部１１は、回線品位や帯域余裕等の情報がないため、まずは送信レートが回線帯域を大幅に上回るように設定し、シンク装置２０から送られてくる遅延時間やパケットロス率をみて、受信レートを推定し、エンコードレートを設定する。送信レートが回線帯域を大幅に上回らなければ、パケットロスは発生しないことから、「大幅に上回る」とは、帯域オーバーによってある一定以上、例えば１％を越えるパケットロスが発生することによって判別する。ここで、１％とは回線品位が低いことによって発生しうるパケットロス率の最大値として仮定している。
【００５３】
多くのエンコーダにおいて、エンコードレートを変更してからそれが出力レートに反映されるまでには遅延があるため、この期間の統計データに基づいてさらに制御を行うと制御が収束しなくなる可能性がある。そのため、エンコードレートを変更してからしばらくはエンコードレートの変更を行わないデッドタイムを設ける。デッドタイムは、基本的にはエンコーダ依存の固定値であり、例えば、３秒である。３秒としたのは、エンコードレート設定（反映まで１秒の遅延）→伝送→シンク側で統計情報更新（１秒間隔）→統計情報伝送（余裕１秒）のステップを経て初めてソース側に伝わるからである。
【００５４】
図７は、デッドタイムを設けたエンコード設定手順を示すフローチャートである。
ソース装置１０の計時部１３の計時から、エンコード部１１はエンコードレートの最終変更時刻を現在時刻とする（ステップＳ１）。さらに、現在時刻は最終変更時刻より３秒経過したかを確認する（ステップＳ２）。３秒を経過した場合、シンク装置２０からソース装置１０の回線帯域推定部１６に統計データが入力され、このデータから回線帯域推定部１６がネットワーク状態を検出し（ステップＳ３）、エンコードレート変更が必要か否かを判断する（ステップＳ４）。エンコードレート変更が必要であれば、エンコード部１１にエンコードレートを設定し（ステップＳ５）、再びステップＳ１に戻る。エンコードレート変更が不要であれば、ステップＳ３に戻り、ネットワーク状態を検出する。
【００５５】
こうして、回線帯域推定部１６がエンコードレートを変更しても、応答期間内はエンコード部１１にエンコードレートの設定を行わないので、制御が収束しない等の問題は回避できる。
【００５６】
しかしながら、図８に示すように、デッドタイムの存在は制御応答性の悪化を招くため、ソース装置１０のパケット送信部１２において、ネットワークにパケットを送出する前に、エンコードレートを変更直後からエンコードレートを越えるエンコードデータを捨てるような操作も有効である。捨てるデータはデコードに影響を与えにくいデータを選択的に捨てることが望ましい。すなわち、エンコード部１１がエンコードレートを変更しても、その応答時間の間は、エンコードの変更はされないので、エンコードレートを超えるデータを破棄することにすれば、デッドタイムを設ける必要がない。
【００５７】
ここで、「デコードに影響を与えにくいデータ」とは、ＭＰＥＧの場合であれば、ＩフレームよりはＰフレーム、ＰフレームよりはＢフレームに相当するデータである。さらには次のＩフレームに近いＰフレームやＢフレームに相当するデータが影響を与えにくいデータである。また、各フレームの末尾に近いデータつまり、画面の下端に近いデータを捨てるほうが人間の視覚的には影響を与えにくい。
【００５８】
エンコード出力を選択的に捨てるためには、データの再生画像に与える影響を評価し、影響の軽微なものから捨てるようにすることになる。このアルゴリズムの一例として次のようなものが考えられる。
・Ｉフレームは最重要であるため、捨てない。
・Ｂフレームを最優先に捨てる。
・Ｂフレームを捨てても足りない場合はＰフレームを捨てる。
・次のＩフレームまでの時間が長いＰフレームは優先的に残す。
この判定基準に基づきデータを捨てるアルゴリズムの一例を示す。簡単のため、ＩフレームとＰフレームのみを含むＭＰＥＧストリームに関する処理を示している。
【００５９】
図９は、エンコードレートを超えるデータは捨てる手順を示すフローチャートであり、エンコードレートを変更された場合にこの手順が開始される。
まず、エンコード部１１がエンコードレートを変更した変更時刻を計数部１３が測定し、それを現在時刻とする（ステップＳ１１）。回線帯域推定部１６は、初期のリミットをエンコードレート×Ｉフレーム間隔×０．２、総伝送量を０とし、フラグを偽とする（ステップＳ１２）。ここで、リミットはこれを越えるデータを送信するとデータを捨てるべきであると判定する基準値であり、フラグは一度Ｐフレームを捨てると次のＩフレームが表れるまでデータを捨てつづけることを示すフラグである。ここでは、Ｉフレームと次のＩフレームまでに伝送されるデータ量が２０％程度変動すると仮定してリミットの初期値を設定している。
データがＩフレームであるか否かを判定し（ステップＳ１３）、Ｉフレームであればリミットにエンコードレート×Ｉフレーム間隔を加え、フラグを偽とし（ステップＳ１４）、パケット送信部１２からパケット送信を行う（ステップＳ１５）。そして、（総伝送量＋フレームデータ量）を総伝送量として（ステップＳ１６）、ステップＳ１７に進む。
【００６０】
データがＩフレームではない場合は、回線帯域推定部１６は、総伝送量＋フレームデータ量がリミットより小さく、且つフラグが偽であるかを判断し（ステップＳ１８）、そうであればステップ１５に進む。そうでなければ、（総伝送量＋フレームデータ量）を総伝送量とし、且つフラグを真として（ステップＳ１９）、ステップＳ１７に進む。
【００６１】
ステップＳ１７において、最終変更時刻＋１秒と現在時刻とを比較し、最終変更時刻より１秒が経過していた場合は処理が終了し、次のエンコードレート変更に備える。経過していない場合はステップＳ１３に戻る。ここで１秒はエンコードレートを変更してからエンコーダが応答するまでに要する時間である。
【００６２】
図１０は、これを適応した場合の送信状況を示す説明図である。マージンは上記のエンコードレート×Ｉフレーム間隔×０．２に相当する。また、各長方形の高さがそれぞれのパケットのデータ量を示しており、斜線を付した長方形がＩフレームに対応するパケットを示す。破線のパケットは破棄されたパケットを示す。一度パケットが破棄されると、次のＩフレームまでのパケットは無条件に捨てられる。
【００６３】
こうして、ネットワーク状態に応じてエンコードレートを下げた場合、エンコーダの応答時間に相当する時間分だけデッドタイムを短縮することができる。また、応答時間内にエンコードレートを超えるデータを捨てる必要が生じても、Ｉフレーム以外のパケットデータを捨てるので、視覚的に再生される映像品質をあまり落とさずに対応できる。
【０００１】
本発明は、ストリームデータの送受信において、データ伝送の遅延時間やパケットロス率を求め、それに基づいて回線品位や帯域余裕を考慮して最適なエンコードレートを与えるように制御する送信装置に関する。
［背景技術］
［０００２］
インターネット等のネットワークでは、伝送帯域や回線品位等の原因により、データ伝送に遅延が生じ、さらにはパケットが失われたり、伝送遅延にジッタが発生したりする。このため、映像や音声情報のような連続メディアを圧縮して得られたストリームデータを伝送して連続再生する場合、データ伝送品質の劣化を生じてしまい、スムーズな再生が困難となる場合がある。
［０００３］
すなわち、ネットワークは有限長のキューと有限帯域の回線の連鎖と考えられる。回線の帯域以上のデータを流そうとすると、キューに蓄積され、伝送にかかる遅延が増大する。さらに帯域以上のデータを流し続けるとついにはキューがオーバフローしてパケットが失われる。また、伝送の品質が悪い回線では、データ量とは無関係にパケットが失われたり、パケットの順序が変わったり、伝送遅延に揺らぎが発生したりする。
［０００４］
そこで、例えば後述する特許文献１に開示されているように、データ受信側の品質低下をできる限り抑えて、効率的にデータ伝送ができるように、エンコードレートを制御する。
［０００５］
図１１は、従来の通信システムを示すブロック図である。図示都合上、Ａ点を境にして（ａ）、（ｂ）に分割して示している。送信側は、カメラ１０１、リアルタイムエンコーダ１０２、送信制御部１０３を備え、受信側は、受信制御部１１１、リアルタイムデコーダ１１２、再生表示部１１３を備える。送信側と受信側はネットワーク１０５を介して接続されている。
［０００６］
同図（ａ）の送信側において、カメラ１０１から入力された映像情報は、リアルタイムエンコーダ１０２において、送信制御部１０３により指定された送出ビットレートでリアルタイムエンコードされる。リアルタイムエンコーダ１０２における送出ビットレートは、送信制御部１０３からのビットレートフィードバック情報により指定される。
【０００７】
この送出のデータフォーマットは、送信したパケットの順序ならびに再生タイミングが受信側で分かるようにパケット毎にシリアル番号が付与され、そのパケットに含まれるデータの再生タイミングを表すタイムスタンプも同様に付与されたものとなっている。このようなフォーマットとしてはＲＴＰ（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）が広く使われている。また、ＲＴＰを使った伝送を制御するためにＲＴＣＰ（ＲＴＰ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）が広く使われている。本発明、ならびに従来技術はＲＴＰ／ＲＴＣＰに限定されるものではないが、以下では簡単のため広く理解されうるＲＴＰ／ＲＴＣＰを想定したシステムについて説明する。
【０００８】
ネットワーク１０５により伝送された映像データパケットは、図（ｂ）の受信側の受信制御部１１１により受信される。受信制御部１１１において、受信した映像データパケットに格納されているシリアル番号に基づいて映像データパケットのロスや到着順序入替り、重複受信などのイレギュラーな映像データパケットの受信状況が検出される。再生時刻に間に合ったと判定された映像データパケットからは、そのペイロード内に格納されている映像データが取り出される。再生時刻に間にあわない映像データパケットは捨てられる。この映像データは、タイムスタンプと共にリアルタイムデコーダ１１２に渡されてリアルタイムでデコードされた後、タイムスタンプに従って再生表示部１１３において再生表示される。
【０００９】
送信制御部１０３からは、映像データパケット以外に、ネットワークの品質パラメータを測定し輻輳状態を判定するために、コントロール情報を伝えるＳＲ（Ｓｅｎｄｅｒ Ｒｅｐｏｒｔ）パケット（以下、ＳＲパケットという。）が送出される。このＳＲパケットは、送信制御部１０３から図１（ｂ）の受信側の受信制御部１１１に対して定期的に送出される。ＳＲパケットのフォーマット中には送信した時の時刻情報（送信タイムスタンプ）が含まれている。
【００１０】
また、ＳＲパケットを受信すると受信制御部１１１から送信制御部１０３に対してコントロール情報を伝えるＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）パケット（以下、ＲＲパケットという。）が送出される。このＲＲパケットのフォーマット中には、受信したＳＲパケット中に含まれていた送信タイムスタンプ情報および受信側がＳＲパケットを受信してからＲＲパケットを送信するまでの経過時間情報が格納される。
【００１１】
ＲＲパケットを受信した送信制御部１０３おいて、コントロールパケット（ＳＲパケット、ＲＲパケット）の往復伝播遅延（ラウンドトリップタイム：Ｒｏｕｎｄ Ｔｒｉｐ Ｔｉｍｅ）を下記（１）式により求めることができる。
Ｔｒｎｄ＝（Ｔｒｃｖ−Ｔｓｎｄ）−Ｔｓｔａｙ・・・（１）
ここで、
Ｔｒｎｄ：コントロール信号パケットの往復伝播遅延、
Ｔｒｃｖ：送信制御部がＲＲパケットを受信した時刻、
Ｔｓｎｄ：送信制御部が受信したＲＲパケットに対応するＳＲパケットを送信した時刻（ＲＲパケットに格納されている送信タイムスタンプ情報）、
Ｔｓｔａｙ：受信制御部がＳＲパケットを受信してからＲＲパケットを送信するまでの時間（ＲＲパケットに格納されている経過時間情報）、
である。
【００１２】
また、ＲＲパケットのフォーマット中には、受信制御部１１１で受信された映像データパケットに関するパケットロス率と伝播遅延のゆらぎを表すジッタ情報などのネットワークの輻輳情報も格納される。
【特許文献１】
特開２００３−２４４６９５
【発明の開示】
【発明が解決しようとする課題】
【００１３】
上記従来技術で伝送レート制御に用いられているラウンドトリップタイム（以降ＲＴＴと呼ぶ）は、送受信装置それぞれの計時部間のずれの影響を受けないため、算出しやすい。しかし、ＲＴＴは送信装置から受信装置に向けての伝送遅延だけではなく、受信装置から送信装置に向けての伝送遅延の影響を受けてしまう。ここで、受信装置から送信装置に至るまでの逆方向の遅延は、送信装置が送り出すストリームデータの伝送レートには無関係であり、このような要素の影響を受けることは正確な伝送レート制御の妨げとなっている。このような悪影響は回線の帯域が非対称なＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）において顕著に表れる。
［００１４］
また、図１２に示すように、送信レートを徐々に増加させていくと、最初、遅延時間は一定で、受信レートが送信レートに一致して上昇していく。送信レートが回線帯域に達すると、受信レートは頭打ちとなり、ネットワーク中のキューにデータが蓄積されることによる伝送遅延の増加が観測される。さらに送信レートが回線帯域を越える状態が継続するとパケットロスが発生し、送信したデータの一部が失われる。この状態では、送信データを単に捨てることになるため、送信レートを高めても再生される映像や音声の品質は向上しないばかりかデータの欠落による品位の悪化をもたらすことになる。そのため、上記従来技術はパケットロス率だけが上昇した場合でも、伝送レートを下げるように制御する。しかしながら、パケットロスは送信装置の過剰な伝送レート以外の原因によって発生する可能性があり、この場合に伝送レートを下げたとしても伝送される映像や音声の品位が低下するだけでパケットロス率は低下しない。
【００１５】
本発明は、斯かる実情に鑑み、データ伝送の遅延時間やパケットロス率を求め、それらに基づいて回線品位や帯域余裕を考慮して最適なエンコードレートを与えるように制御する送信装置を提供しようとするものである。
【００１６】
本発明の送信装置は、ストリームデータを送信し、受信装置が受信して求めたストリームデータの伝送遅延及びパケットロス率に基づき、エンコードレートを制御し、前記ストリームデータを送信する送信装置であって、制御に使用する前記伝送遅延は、少なくとも通信開始時の遅延を基準とする増減値であり、前記伝送遅延が増加しない場合には、前記パケットロス率の程度及び前記ストリームデータを送信する帯域の余裕に応じて前記エンコードレートを変更し、前記ストリームデータを制御し、前記伝送遅延が増加した場合には、前記エンコードレートを絞り、送信するレートを低減するように前記ストリームデータを制御することを特徴とする。
【００１７】
本発明の送信装置は、ストリームデータを送信し、受信装置が受信して求めたストリームデータの伝送遅延及びパケットロス率に基づき、エンコードレートを制御し、前記ストリームデータを送信する送信装置であって、制御に使用する前記伝送遅延は、送信開始からの前記通信遅延の最小値を基準とする増減値であり、前記伝送遅延が増加しない場合には、前記パケットロス率の程度及び前記ストリームデータを送信する帯域の余裕に応じて前記エンコードレートを変更し、前記ストリームデータを制御し、前記伝送遅延が増加した場合には、前記エンコードレートを絞り、送信するレートを低減するように前記ストリームデータを制御することを特徴とする。
［００１８］
［００１９］
［００２０］
［００２１］
［００２２］
［００２３］
［００２４］
［００２５］
［００２６］
［００２７］
［発明の効果］
［００２８］
本発明によれば、送信装置が送ったストリームデータに基づいて、受信装置が伝送遅延及びパケットロス率を求め、その求めた値によって送信側が送信ビットレート又はエンコードレートを制御するので、ＩＰ網のような、不安定なネットワークにおいても、乱れを最小限にとどめた状態でデータを送受信できる。特に、送信装置から受信装置への一方向の伝送遅延やパケットロス率を求めているので、ＲＴＴのように不要な方向の遅延の影響を受けずに済む。
【図面の簡単な説明】
【００２９】
【図１】本発明の通信システムの一実施形態を示すブロック図である。
【図２】回線品位、帯域余裕を軸にネットワーク状態を示す説明図である。
【図３】ソース装置とシンク装置の制御内容を示す表である。
【図４】初期適応期間後の基準遅延設定期間を設ける説明図である。
【図５】所定の算定期間毎に、遅延時間の平均値を求めて基準遅延時間とする説明図である。
【図６】回線帯域の変動に応じてエンコードレートを変更する状況を示す説明図である。
【図７】デッドタイムを設けたエンコード設定手順を示すフローチャートである。
【図８】エンコードレートを変更直後から応答時間内にエンコードレートを越えるエンコードデータを捨てる状況を示す説明図である。
【図９】エンコードレートを超えるデータは捨てる手順を示すフローチャートである。
【図１０】エンコードレートを超えたＩフレーム以外のパケットデータを破棄する場合の送信状況を示す説明図である。
【図１１】従来の通信システムを示すブロック図である。
【図１２】回線帯域に対する送信レートの増加によるネットワーク状態を示す説明図である。
【図１３】拡張ヘッダ部分に送信タイムスタンプを入れたＲＴＰパケットの構造を示す説明図である。
【符号の説明】
【００３０】
１０ ソース装置
１１ エンコード部
１２ パケット送信部
１３ 計時部
１４ ネットワークインターフェース
１５ パケット受信部
１６ 回線帯域推定部
２０ シンク装置
２０ ソース装置
２１ ネットワークインターフェース
２２ パケット受信部
２３ 統計データ取得部
２４ パケット送信部
２５ デコード部
２６ 計時部
３０ ネットワーク
【発明を実施するための最良の形態】
【００３１】
以下、本発明の実施の形態を添付図面を参照して説明する。
【００３２】
図１は、本発明の通信システムの一実施形態を示すブロック図である。この通信システムは送信側のソース装置１０、インターネット等のネットワーク３０、受信側のシンク装置２０から構成されている。ネットワーク３０としているが、この部分はソース装置１０とシンク装置２０を繋ぐ単なる回線でも構わない。
【００３３】
ソース装置１０は、エンコード部１１、パケット送信部１２、計時部１３、ネットワークインターフェース１４、パケット受信部１５、回線帯域推定部１６とから構成される。また、シンク装置２０は、ネットワークインターフェース２１、パケット受信部２２、統計データ取得部２３、パケット送信部２４、デコード部２５、計時部２６とから構成される。
【００３４】
この通信システムの送受信装置は、このソース装置１０とシンク装置２０を一組備え、互いにデータの送受信を行っている。
【００３５】
ソース装置１０に入力された映像音声は、エンコード部１１で例えばＭＰＥＧ４にエンコードされ、パケット送信部１２でＲＴＰパケットに分割されて、ネットワークインターフェース１４を介してネットワーク３０に送出される。このとき、パケットには計時部１３で計測されている時刻がタイムスタンプとして付与される。
【００３６】
シンク装置２０は、ネットワークインターフェース２１を介して受け取ったＲＴＰパケットをパケット受信部２２にてＭＰＥＧ４ストリームに組み立て、デコード部２５によりデコードして映像音声を出力する。またパケット受信部２２では、パケットの通し番号やパケットサイズ、タイムスタンプなどの情報を抽出して、統計データ取得部２３により片側遅延時間、パケットロス率、受信レート等の統計データを算出する。パケット送信部２４では、片方向遅延を伝送するために拡張したＲＴＣＰパケットによって統計データをネットワークインターフェース２１を介してシンク装置２０からソース装置１０に向けて送信する。
【００３７】
ソース装置２０でネットワークインターフェース１４を介して受信された統計情報は、パケット受信部１５にて抽出されて回線帯域推定部１６に入力され、回線帯域推定部１６はエンコード部１１に対して最適なエンコードを与えるよう指示する。
【００３８】
次に、それぞれの領域でソース側、シンク側で行うべき制御の概要を示す。
【００３９】
発明が解決しようとする課題の項目において説明したように、一般に、送信レートを徐々に増加させていくと、最初、遅延時間は一定で、受信レートが送信レートに一致して上昇していく。送信レートが回線帯域に達すると、受信レートは頭打ちになり、ネットワーク中のキューにデータが蓄積されることによる伝送遅延の増加が観測される。さらに送信レートが回線帯域を越える状態が継続するとパケットロスが発生し、送信したデータの一部が失われる。この状態では遅延時間は飽和する。
【００４０】
ここで、回線品位、帯域余裕（＝回線帯域−送信レート）を軸にネットワーク状態を整理すると図２に示すようになる。縦軸に回線品位、横軸に帯域余裕を設ける。
まず、第１象限は問題のない領域であり、回線品位が高いためパケットロス率は小さく、また右に行くに従って、帯域余裕は大きくなるため送信レートの微細な揺らぎに伴う遅延変動も少なくなる。この領域においては特に、送信ビットレートやエンコードレートを制御する必要はない。
【００４１】
第２，第３象限は、帯域が不足している領域であり、伝送遅延が増加中／一定があるので、便宜上斜めの線で区切っている。斜め線の上側は帯域不足で遅延大、パケットロス率が大である。また、斜め線の下側は、遅延が増大し、帯域がやや不足している。なお、第２象限においては、回線品位がよいので、斜め線の下側は、パケットロス率は少ない。第３象限においては、回線品位がよくないので、斜め線の下側は、パケットロス率は中程度である。これら領域では帯域不足を解消するため、伝送遅延とパケットロス率に基づいて、損失データをできる限り抑えるように、送信ビットレートやエンコードレートを制御する。本発明は、これら第２，第３象限における制御に関するものである。
【００４２】
第４象限は、帯域余裕はあるが、回線品位が低い領域であり、遅延変動を起こし、パケット率も中程度であるが、これらは回線品位に起因するため、ソース装置における制御によって伝送品位が改善する見込みはなく制御を行う必要はない。
【００４３】
図３は、ソース装置とシンク装置の制御内容を示す表である。各項目毎にソース装置とシンク装置の制御内容を説明する。
伝送良好の場合は、ソース装置とシンク装置共に現状維持である。帯域余裕が大きい場合は、ソース装置はエンコードレートを増加させて伝送効率を増加させ、シンク装置は現状維持とする。帯域余裕がない場合は、ソース装置とシンク装置共に現状維持かエンコードレートをやや減少させる。伝送品質が低い場合は、ソース装置は現状維持で、シンク装置はデータのエラー補正を行う。帯域が不足している場合は、ソース装置はエンコードレートを受信レートに変更し、シンク装置はエラーコンシールメント、すなわちエラーを隠す処理を行う。例えば、動画の壊れたフレームを捨てその間静止画を表示するなどの処理である。帯域がやや不足している場合は、ソース装置はエンコードレートを減少させ、シンク装置は遅延パケットを破棄する。
各項目ではこのような制御が考えられるが、次に伝送品位と帯域余裕を考慮した具体的制御について説明する。
【００４４】
このような制御を行うには、まず遅延時間を求めなければならない。遅延時間を求めるためには、シンク装置２０で受信した時刻から、ソース装置１０で付与されたタイムスタンプを引けばよい。しかし、ソース装置１０、シンク装置２０のそれぞれの計時部１３と計時部２６を正確に同期させることは困難である。そこで、シンク装置２０は、ネットワーク３０の標準的な遅延時間を基準遅延時間として求め、これを０とみなして、求めた遅延時間を補正する。つまり、
遅延時間＝パケット受信時刻−送信タイムスタンプ−基準遅延時間・・・（２）
となる。
【００４５】
図４に示すように、通信開始直後の初期適応期間は遅延時間やパケットロス率等が求められておらず過大な送信を行う可能性があるため、この期間の遅延時間は無視する。通信安定後、基準遅延設定期間を設けて、この期間の遅延時間を測定し、この遅延時間を平均して、基準遅延時間とする。
【００４６】
しかし、インターネット等のネットワークにおいては、データ伝送経路が変わる可能性があり、そのため回線品位や帯域余裕等が変化し、突然遅延時間が変化する可能性がある。そこで、基準遅延時間により補正した遅延時間が、通信中に大きくマイナスに振れた場合、平均値である基準遅延時間基準遅延時間を見直す。詳しくは、式（２）で求められる遅延時間が、あらかじめ定めておいた基準値（例えば、−２００ｍｓｅｃ）を下回ったときに、再び、基準遅延設定期間だけ遅延時間を測定し、その平均値を基準遅延時間とする。
【００４７】
また、図５に示すように、所定の算定期間毎に、遅延時間の平均値を求めて基準遅延時間とする方法もある。そして、算定期間中は、前回の算定期間中に求めた基準遅延時間を用いて遅延時間を求める。こうして基準遅延時間を定期的に見直すことにより、求める遅延時間に大きな誤差が生じないようにしている。
片方向遅延の測定方法に関して、ＲＴＣＰを利用する方法の他に、ＲＴＰパケットの拡張ヘッダ部分に送信タイムスタンプを入れることで、パケット単位で測定することができる。送信タイムスタンプを含んだＲＴＰパケットフォーマットは、例えば図１３のようになる。
ＲＴＣＰの送信間隔は、あまり短くすることができないが、ＲＴＰパケットに送信タイムスタンプを入れる方法では、例えば１０パケット間隔で、片方向遅延の平均値や最大値で増減傾向を判断することによって、より迅速かつ正確に輻輳状態を把握することができる。
【００４８】
また、基準遅延時間の他の求め方としては、それまでの遅延時間の最小値を用いる方法もある。通信開始からすべてのパケットの遅延時間の最小値を遅延時間とみなす方法だけではなく、現時刻から一定期間さかのぼった範囲だけで最小値を求める方法や、図５と同様にオーバラップさせながら最小値を更新していく方法もある。
【００４９】
さて、こうして求めた遅延時間に基づいて、ソース装置１０のエンコード部１１は、エンコードレートを回線帯域に対して、エンコーダの出力揺らぎ、他のトラヒックのための余裕帯域を加味して決定する。
【００５０】
回線帯域が一時的に減少した際にはパケットロス率、片側伝送遅延などからこれを検出して、エンコードレートを絞る操作を行う。遅延の増加が見られる段階では、エンコードレートを少し絞るような制御を行う。詳しくは、以下のとおりである。
【００５１】
（１）送信遅延が上昇したときには、遅延を解消するために必要な分送信レートを落とす。
（２）送信遅延が上昇したと判断する閾値は、通常時の遅延が２００ｍｓｅｃ以下であると仮定し、その２倍の４００ｍｓｅｃとする。
（３）遅延／送信レートの計測結果より、送信レートを１０％落とす。送信レートを落とした後、３秒後に送信遅延が減少していなかったら再度１０％落とす。
【００５２】
送信レートが回線帯域を大幅に上回っているためにパケットロスが発生していると考えられる場合には、受信レートを参考にエンコードレートを定める。この状況には、回線品位が低いためにパケットロスが発生している状況を含まない。例えば、図６に示すように、初期適応期間においては、ソース装置１０のエンコード部１１は、回線品位や帯域余裕等の情報がないため、まずは送信レートが回線帯域を大幅に上回るように設定し、シンク装置２０から送られてくる遅延時間やパケットロス率をみて、受信レートを推定し、エンコードレートを設定する。送信レートが回線帯域を大幅に上回らなければ、パケットロスは発生しないことから、「大幅に上回る」とは、帯域オーバーによってある一定以上、例えば１％を越えるパケットロスが発生することによって判別する。ここで、１％とは回線品位が低いことによって発生しうるパケットロス率の最大値として仮定している。
【００５３】
多くのエンコーダにおいて、エンコードレートを変更してからそれが出力レートに反映されるまでには遅延があるため、この期間の統計データに基づいてさらに制御を行うと制御が収束しなくなる可能性がある。そのため、エンコードレートを変更してからしばらくはエンコードレートの変更を行わないデッドタイムを設ける。デッドタイムは、基本的にはエンコーダ依存の固定値であり、例えば、３秒である。３秒としたのは、エンコードレート設定（反映まで１秒の遅延）→伝送→シンク側で統計情報更新（１秒間隔）→統計情報伝送（余裕１秒）のステップを経て初めてソース側に伝わるからである。
【００５４】
図７は、デッドタイムを設けたエンコード設定手順を示すフローチャートである。
ソース装置１０の計時部１３の計時から、エンコード部１１はエンコードレートの最終変更時刻を現在時刻とする（ステップＳ１）。さらに、現在時刻は最終変更時刻より３秒経過したかを確認する（ステップＳ２）。３秒を経過した場合、シンク装置２０からソース装置１０の回線帯域推定部１６に統計データが入力され、このデータから回線帯域推定部１６がネットワーク状態を検出し（ステップＳ３）、エンコードレート変更が必要か否かを判断する（ステップＳ４）。エンコードレート変更が必要であれば、エンコード部１１にエンコードレートを設定し（ステップＳ５）、再びステップＳ１に戻る。エンコードレート変更が不要であれば、ステップＳ３に戻り、ネットワーク状態を検出する。
【００５５】
こうして、回線帯域推定部１６がエンコードレートを変更しても、応答期間内はエンコード部１１にエンコードレートの設定を行わないので、制御が収束しない等の問題は回避できる。
【００５６】
しかしながら、図８に示すように、デッドタイムの存在は制御応答性の悪化を招くため、ソース装置１０のパケット送信部１２において、ネットワークにパケットを送出する前に、エンコードレートを変更直後からエンコードレートを越えるエンコードデータを捨てるような操作も有効である。捨てるデータはデコードに影響を与えにくいデータを選択的に捨てることが望ましい。すなわち、エンコード部１１がエンコードレートを変更しても、その応答時間の間は、エンコードの変更はされないので、エンコードレートを超えるデータを破棄することにすれば、デッドタイムを設ける必要がない。
【００５７】
ここで、「デコードに影響を与えにくいデータ」とは、ＭＰＥＧの場合であれば、ＩフレームよりはＰフレーム、ＰフレームよりはＢフレームに相当するデータである。さらには次のＩフレームに近いＰフレームやＢフレームに相当するデータが影響を与えにくいデータである。また、各フレームの末尾に近いデータつまり、画面の下端に近いデータを捨てるほうが人間の視覚的には影響を与えにくい。
【００５８】
エンコード出力を選択的に捨てるためには、データの再生画像に与える影響を評価し、影響の軽微なものから捨てるようにすることになる。このアルゴリズムの一例として次のようなものが考えられる。
・Ｉフレームは最重要であるため、捨てない。
・Ｂフレームを最優先に捨てる。
・Ｂフレームを捨てても足りない場合はＰフレームを捨てる。
・次のＩフレームまでの時間が長いＰフレームは優先的に残す。
この判定基準に基づきデータを捨てるアルゴリズムの一例を示す。簡単のため、ＩフレームとＰフレームのみを含むＭＰＥＧストリームに関する処理を示している。
【００５９】
図９は、エンコードレートを超えるデータは捨てる手順を示すフローチャートであり、エンコードレートを変更された場合にこの手順が開始される。
まず、エンコード部１１がエンコードレートを変更した変更時刻を計数部１３が測定し、それを現在時刻とする（ステップＳ１１）。回線帯域推定部１６は、初期のリミットをエンコードレート×Ｉフレーム間隔×０．２、総伝送量を０とし、フラグを偽とする（ステップＳ１２）。ここで、リミットはこれを越えるデータを送信するとデータを捨てるべきであると判定する基準値であり、フラグは一度Ｐフレームを捨てると次のＩフレームが表れるまでデータを捨てつづけることを示すフラグである。ここでは、Ｉフレームと次のＩフレームまでに伝送されるデータ量が２０％程度変動すると仮定してリミットの初期値を設定している。
データがＩフレームであるか否かを判定し（ステップＳ１３）、Ｉフレームであればリミットにエンコードレート×Ｉフレーム間隔を加え、フラグを偽とし（ステップＳ１４）、パケット送信部１２からパケット送信を行う（ステップＳ１５）。そして、（総伝送量＋フレームデータ量）を総伝送量として（ステップＳ１６）、ステップＳ１７に進む。
【００６０】
データがＩフレームではない場合は、回線帯域推定部１６は、総伝送量＋フレームデータ量がリミットより小さく、且つフラグが偽であるかを判断し（ステップＳ１８）、そうであればステップ１５に進む。そうでなければ、（総伝送量＋フレームデータ量）を総伝送量とし、且つフラグを真として（ステップＳ１９）、ステップＳ１７に進む。
【００６１】
ステップＳ１７において、最終変更時刻＋１秒と現在時刻とを比較し、最終変更時刻より１秒が経過していた場合は処理が終了し、次のエンコードレート変更に備える。経過していない場合はステップＳ１３に戻る。ここで１秒はエンコードレートを変更してからエンコーダが応答するまでに要する時間である。
【００６２】
図１０は、これを適応した場合の送信状況を示す説明図である。マージンは上記のエンコードレート×Ｉフレーム間隔×０．２に相当する。また、各長方形の高さがそれぞれのパケットのデータ量を示しており、斜線を付した長方形がＩフレームに対応するパケットを示す。破線のパケットは破棄されたパケットを示す。一度パケットが破棄されると、次のＩフレームまでのパケットは無条件に捨てられる。
【００６３】
こうして、ネットワーク状態に応じてエンコードレートを下げた場合、エンコーダの応答時間に相当する時間分だけデッドタイムを短縮することができる。また、応答時間内にエンコードレートを超えるデータを捨てる必要が生じても、Ｉフレーム以外のパケットデータを捨てるので、視覚的に再生される映像品質をあまり落とさずに対応できる。
Claims (2)
- ストリームデータを送信し、受信装置が受信して求めたストリームデータの伝送遅延及びパケットロス率に基づき、エンコードレートを制御し、前記ストリームデータを送信する送信装置であって、
制御に使用する前記伝送遅延は、少なくとも通信開始時の遅延を基準とする増減値であり、
前記伝送遅延が増加しない場合には、前記パケットロス率の程度及び前記ストリームデータを送信する帯域の余裕に応じて前記エンコードレートを変更し、前記ストリームデータを制御し、
前記伝送遅延が増加した場合には、前記エンコードレートを絞り、送信するレートを低減するように前記ストリームデータを制御することを特徴とする送信装置。 - ストリームデータを送信し、受信装置が受信して求めたストリームデータの伝送遅延及びパケットロス率に基づき、エンコードレートを制御し、前記ストリームデータを送信する送信装置であって、
制御に使用する前記伝送遅延は、送信開始からの前記通信遅延の最小値を基準とする増減値であり、
前記伝送遅延が増加しない場合には、前記パケットロス率の程度及び前記ストリームデータを送信する帯域の余裕に応じて前記エンコードレートを変更し、前記ストリームデータを制御し、
前記伝送遅延が増加した場合には、前記エンコードレートを絞り、送信するレートを低減するように前記ストリームデータを制御することを特徴とする送信装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2006544846A JP4838143B2 (ja) | 2004-11-17 | 2005-10-31 | 送信装置 |
Applications Claiming Priority (4)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2004333246 | 2004-11-17 | ||
| JP2004333246 | 2004-11-17 | ||
| JP2006544846A JP4838143B2 (ja) | 2004-11-17 | 2005-10-31 | 送信装置 |
| PCT/JP2005/020005 WO2006054442A1 (ja) | 2004-11-17 | 2005-10-31 | 送信装置、受信装置及び通信システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPWO2006054442A1 JPWO2006054442A1 (ja) | 2008-05-29 |
| JP4838143B2 true JP4838143B2 (ja) | 2011-12-14 |
Family
ID=36406987
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2006544846A Expired - Fee Related JP4838143B2 (ja) | 2004-11-17 | 2005-10-31 | 送信装置 |
Country Status (5)
| Country | Link |
|---|---|
| US (1) | US8281356B2 (ja) |
| EP (1) | EP1821442A4 (ja) |
| JP (1) | JP4838143B2 (ja) |
| CN (1) | CN101057439B (ja) |
| WO (1) | WO2006054442A1 (ja) |
Families Citing this family (51)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| BRPI0411458B1 (pt) * | 2003-06-16 | 2019-01-02 | Thomson Licensing | método e aparelho de codificação permitindo mudança rápida de canal de vídeo comprimido |
| US9189307B2 (en) | 2004-08-06 | 2015-11-17 | LiveQoS Inc. | Method of improving the performance of an access network for coupling user devices to an application server |
| US7953114B2 (en) | 2004-08-06 | 2011-05-31 | Ipeak Networks Incorporated | System and method for achieving accelerated throughput |
| US9647952B2 (en) | 2004-08-06 | 2017-05-09 | LiveQoS Inc. | Network quality as a service |
| US8009696B2 (en) | 2004-08-06 | 2011-08-30 | Ipeak Networks Incorporated | System and method for achieving accelerated throughput |
| WO2007130746A2 (en) * | 2006-03-28 | 2007-11-15 | The Board Of Governors For Higher Education, State Of Rhode Island And Providence Plantations | Systems and methods for distance estimation between electronic devices |
| US8639833B1 (en) * | 2006-10-06 | 2014-01-28 | Nvidia Corporation | Dynamic control of scaling in computing devices |
| JP2008113225A (ja) * | 2006-10-30 | 2008-05-15 | Kyocera Corp | 通信装置および通信方法 |
| EP2081330A4 (en) * | 2006-10-30 | 2013-12-04 | Kyocera Corp | COMMUNICATION APPARATUS, COMMUNICATION METHOD, COMMUNICATION CONTROL APPARATUS, WIRELESS COMMUNICATION APPARATUS, COMMUNICATION CONTROL METHOD, AND WIRELESS COMMUNICATION METHOD |
| KR101389277B1 (ko) * | 2007-10-16 | 2014-04-28 | 삼성전자주식회사 | 무선 센서 네트워크에서 브로드캐스팅 제어 방법 |
| US8699383B2 (en) | 2007-10-19 | 2014-04-15 | Voxer Ip Llc | Method and apparatus for real-time synchronization of voice communications |
| EP2171982B1 (en) * | 2007-10-19 | 2012-04-18 | Voxer IP LLC | Method and device for real-time media synchronisation across a network |
| US8559319B2 (en) | 2007-10-19 | 2013-10-15 | Voxer Ip Llc | Method and system for real-time synchronization across a distributed services communication network |
| CN101425868A (zh) * | 2007-11-01 | 2009-05-06 | 华为技术有限公司 | 一种媒体传输质量的监测与控制的方法及系统 |
| CN101183917B (zh) * | 2007-12-24 | 2010-09-01 | 腾讯科技（深圳）有限公司 | 一种多媒体数据编码速率调节方法和装置 |
| US8194756B2 (en) * | 2008-05-28 | 2012-06-05 | Broadcom Corporation | Using program clock references to assist in transport of video stream to wireless device |
| CA2723788C (en) * | 2008-07-28 | 2016-10-04 | Vantrix Corporation | Data streaming through time-varying transport media |
| US7844725B2 (en) | 2008-07-28 | 2010-11-30 | Vantrix Corporation | Data streaming through time-varying transport media |
| US8001260B2 (en) | 2008-07-28 | 2011-08-16 | Vantrix Corporation | Flow-rate adaptation for a connection of time-varying capacity |
| ES2394262T3 (es) * | 2008-11-05 | 2013-01-30 | Thine Electronics, Inc. | Dispositivo de transmisor, dispositivo de receptor y sistema de comunicación |
| US7975063B2 (en) | 2009-05-10 | 2011-07-05 | Vantrix Corporation | Informative data streaming server |
| US8537699B2 (en) * | 2009-06-16 | 2013-09-17 | Qualcomm Incorporated | Managing video adaptation algorithms |
| JP5506362B2 (ja) * | 2009-12-15 | 2014-05-28 | キヤノン株式会社 | 送信装置、送信方法 |
| US8848720B2 (en) * | 2010-03-25 | 2014-09-30 | Infinera Corporation | Method and apparatus for determining propagation delay in a network |
| US8514715B2 (en) | 2010-04-22 | 2013-08-20 | Akamai Technologies, Inc. | Congestion window control based on queuing delay and packet loss |
| EP2388947A1 (en) * | 2010-05-20 | 2011-11-23 | Thomson Licensing | Method of determination of transmission quality of a communication link and corresponding apparatus |
| US10951743B2 (en) * | 2011-02-04 | 2021-03-16 | Adaptiv Networks Inc. | Methods for achieving target loss ratio |
| US9590913B2 (en) | 2011-02-07 | 2017-03-07 | LiveQoS Inc. | System and method for reducing bandwidth usage of a network |
| US8717900B2 (en) | 2011-02-07 | 2014-05-06 | LivQoS Inc. | Mechanisms to improve the transmission control protocol performance in wireless networks |
| JP5736237B2 (ja) * | 2011-05-26 | 2015-06-17 | 日本放送協会 | 映像伝送装置 |
| US8730930B2 (en) * | 2011-05-31 | 2014-05-20 | Broadcom Corporation | Polling using B-ACK for occasional back-channel traffic in VoWIFI applications |
| US9137551B2 (en) | 2011-08-16 | 2015-09-15 | Vantrix Corporation | Dynamic bit rate adaptation over bandwidth varying connection |
| US20150215180A1 (en) | 2012-08-06 | 2015-07-30 | Nec Corporation | Communication system, server apparatus, server apparatus control method and program |
| US10051519B2 (en) | 2012-08-27 | 2018-08-14 | Qualcomm Incorporated | Device and method for adaptive rate multimedia communications on a wireless network |
| US9247448B2 (en) | 2012-08-27 | 2016-01-26 | Qualcomm Incorporated | Device and method for adaptive rate multimedia communications on a wireless network |
| CN103051558B (zh) * | 2012-12-06 | 2016-06-15 | 惠州Tcl移动通信有限公司 | 一种近场通信软件栈逻辑链路层的流量控制方法 |
| CN103152649B (zh) * | 2013-01-30 | 2016-01-06 | 北京佳讯飞鸿电气股份有限公司 | 一种流媒体分发传输分级别自动减帧控制方法 |
| WO2014132723A1 (ja) * | 2013-03-01 | 2014-09-04 | 日本電気株式会社 | 送信レート制御装置送信レート制御システム、送信レート制御方法及び送信レート制御プログラム |
| CN103248964B (zh) * | 2013-04-07 | 2016-04-06 | 同济大学 | 基于rtp/rtcp的车载视频传输系统 |
| JP5987798B2 (ja) * | 2013-08-06 | 2016-09-07 | 富士ゼロックス株式会社 | 情報処理システム、情報処理装置及びプログラム |
| GB2547815B (en) * | 2013-08-28 | 2018-08-29 | Metaswitch Networks Ltd | Data processing |
| US10263894B2 (en) | 2014-04-23 | 2019-04-16 | Bequant S.L. | Method and apparatus for network congestion control based on transmission rate gradients |
| JP6589261B2 (ja) * | 2014-08-28 | 2019-10-16 | 株式会社リコー | 配信制御システム、配信制御方法、及びプログラム |
| CN104580006B (zh) * | 2014-12-24 | 2018-02-09 | 无锡儒安科技有限公司 | 一种移动网络发送速率控制方法、装置及系统 |
| JP6747150B2 (ja) * | 2016-08-03 | 2020-08-26 | 富士通株式会社 | 情報処理装置、情報処理方法、及び、情報処理プログラム |
| CN107783721B (zh) * | 2016-08-25 | 2020-09-08 | 华为技术有限公司 | 一种数据的处理方法和物理机 |
| CN107948628B (zh) * | 2016-10-12 | 2019-09-03 | 阿里巴巴集团控股有限公司 | 一种多维视频数据的编码、解码方法和装置 |
| KR102424047B1 (ko) * | 2017-09-19 | 2022-07-21 | 광동 오포 모바일 텔레커뮤니케이션즈 코포레이션 리미티드 | 데이터 패킷 배포 방법, 송신자 장치, 수신자 장치 및 저장 매체 |
| US11736406B2 (en) * | 2017-11-30 | 2023-08-22 | Comcast Cable Communications, Llc | Assured related packet transmission, delivery and processing |
| EP3541137A1 (en) * | 2018-03-15 | 2019-09-18 | Tata Consultancy Services Limited | Method and system for delay aware uplink scheduling in a communication network |
| CN113489745B (zh) * | 2021-07-29 | 2024-04-05 | 百果园技术(新加坡)有限公司 | 视频数据发送方法、装置、设备和存储介质 |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0856237A (ja) * | 1994-08-10 | 1996-02-27 | Nippon Telegr & Teleph Corp <Ntt> | パケット網の輻輳防止方法および該方法を用いた通信システム |
| JP2001160824A (ja) * | 1999-12-03 | 2001-06-12 | Mitsubishi Electric Corp | 有線無線混在網データ配信装置及びデータ配信方法 |
| JP2001230809A (ja) * | 2000-02-15 | 2001-08-24 | Mitsubishi Electric Corp | 通信システム及び通信方法及び送信端末及び受信端末 |
| JP2003169090A (ja) * | 2001-11-30 | 2003-06-13 | Fujitsu Ltd | 伝送システム |
| JP2003244695A (ja) * | 2002-02-14 | 2003-08-29 | Kddi Corp | 映像情報伝送方式、それに用いられる装置およびプログラム |
| JP2003318967A (ja) * | 2002-04-23 | 2003-11-07 | Nec Corp | 帯域制御方法および輻輳制御方法ならびにネットワーク構成装置 |
| JP2004254258A (ja) * | 2002-12-24 | 2004-09-09 | Sony Corp | 情報処理装置および情報処理方法、データ通信システム、並びに、プログラム |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5574934A (en) * | 1993-11-24 | 1996-11-12 | Intel Corporation | Preemptive priority-based transmission of signals using virtual channels |
| US5812790A (en) * | 1996-09-09 | 1998-09-22 | Sonic Solutions | Variable encoding rate plan generation |
| US5949975A (en) * | 1997-03-12 | 1999-09-07 | Microsoft Corp. | Method and system for negotiating capabilities when sharing an application program with multiple computer systems |
| US5931928A (en) * | 1997-05-07 | 1999-08-03 | 3Com Corporaton | System for ISDN terminal adapter DCE for automatically negotiating data compression with it's PPP peer when DTE is unable or unwilling to negotiate compression |
| US6366959B1 (en) * | 1997-10-01 | 2002-04-02 | 3Com Corporation | Method and apparatus for real time communication system buffer size and error correction coding selection |
| US6175871B1 (en) * | 1997-10-01 | 2001-01-16 | 3Com Corporation | Method and apparatus for real time communication over packet networks |
| US6233226B1 (en) * | 1998-12-14 | 2001-05-15 | Verizon Laboratories Inc. | System and method for analyzing and transmitting video over a switched network |
| JP2000350197A (ja) | 1999-06-02 | 2000-12-15 | Hitachi Ltd | 映像伝送方法とそれを用いた監視システム |
| JP3699910B2 (ja) * | 2000-10-31 | 2005-09-28 | 株式会社東芝 | データ伝送装置、データ伝送方法及びプログラム |
| US7274661B2 (en) * | 2001-09-17 | 2007-09-25 | Altera Corporation | Flow control method for quality streaming of audio/video/media over packet networks |
| US6909753B2 (en) * | 2001-12-05 | 2005-06-21 | Koninklijke Philips Electronics, N.V. | Combined MPEG-4 FGS and modulation algorithm for wireless video transmission |
| KR20030095995A (ko) | 2002-06-14 | 2003-12-24 | 마츠시타 덴끼 산교 가부시키가이샤 | 미디어 전송방법 및 그 송신장치 및 수신장치 |
| US7099954B2 (en) | 2002-06-27 | 2006-08-29 | Microsoft Corporation | Congestion control mechanism for streaming media |
| EP1450514A1 (en) * | 2003-02-18 | 2004-08-25 | Matsushita Electric Industrial Co., Ltd. | Server-based rate control in a multimedia streaming environment |
| ITBA20030039A1 (it) * | 2003-08-29 | 2005-02-28 | Grieco Luigi Alfredo | Controllo di congestione rate-based del traffico entrante |
| CN1226844C (zh) * | 2003-09-01 | 2005-11-09 | 中国科学院计算技术研究所 | 一种适合有线/无线混合网络的自适应拥塞控制方法 |
| CN1969562B (zh) * | 2004-05-13 | 2011-08-03 | 高通股份有限公司 | 在无线通信系统中的音频和视频数据的同步 |
-
2005
- 2005-10-31 US US11/666,613 patent/US8281356B2/en not_active Expired - Fee Related
- 2005-10-31 EP EP20050805454 patent/EP1821442A4/en not_active Withdrawn
- 2005-10-31 JP JP2006544846A patent/JP4838143B2/ja not_active Expired - Fee Related
- 2005-10-31 WO PCT/JP2005/020005 patent/WO2006054442A1/ja active Application Filing
- 2005-10-31 CN CN200580038931XA patent/CN101057439B/zh not_active Expired - Fee Related
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH0856237A (ja) * | 1994-08-10 | 1996-02-27 | Nippon Telegr & Teleph Corp <Ntt> | パケット網の輻輳防止方法および該方法を用いた通信システム |
| JP2001160824A (ja) * | 1999-12-03 | 2001-06-12 | Mitsubishi Electric Corp | 有線無線混在網データ配信装置及びデータ配信方法 |
| JP2001230809A (ja) * | 2000-02-15 | 2001-08-24 | Mitsubishi Electric Corp | 通信システム及び通信方法及び送信端末及び受信端末 |
| JP2003169090A (ja) * | 2001-11-30 | 2003-06-13 | Fujitsu Ltd | 伝送システム |
| JP2003244695A (ja) * | 2002-02-14 | 2003-08-29 | Kddi Corp | 映像情報伝送方式、それに用いられる装置およびプログラム |
| JP2003318967A (ja) * | 2002-04-23 | 2003-11-07 | Nec Corp | 帯域制御方法および輻輳制御方法ならびにネットワーク構成装置 |
| JP2004254258A (ja) * | 2002-12-24 | 2004-09-09 | Sony Corp | 情報処理装置および情報処理方法、データ通信システム、並びに、プログラム |
Also Published As
| Publication number | Publication date |
|---|---|
| JPWO2006054442A1 (ja) | 2008-05-29 |
| EP1821442A4 (en) | 2011-07-20 |
| WO2006054442A1 (ja) | 2006-05-26 |
| EP1821442A1 (en) | 2007-08-22 |
| CN101057439A (zh) | 2007-10-17 |
| US20080095247A1 (en) | 2008-04-24 |
| CN101057439B (zh) | 2011-07-27 |
| US8281356B2 (en) | 2012-10-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4838143B2 (ja) | 送信装置 | |
| US20230171301A1 (en) | Monitoring Network Conditions | |
| EP2255535B1 (en) | Device and method for adaptation of target rate of video signals | |
| RU2304364C2 (ru) | Устройство и способ для измерения времени задержки на двустороннее распространение для мультимедийных данных с переменной скоростью передачи битов | |
| US7218610B2 (en) | Communication system and techniques for transmission from source to destination | |
| US8797850B2 (en) | System and method to adapt to network congestion | |
| US7729391B2 (en) | Transmitting device with discard control of specific media data | |
| WO2008014707A1 (fr) | Procédé, système et écran de réglage de qualité vidéo | |
| CN108401128B (zh) | 一种视频通话中的拥塞控制方法 | |
| EP3125497B1 (en) | Estimating processor load | |
| TW200836543A (en) | Method and arrangement for video telephony quality assessment | |
| US10587518B2 (en) | Identifying network conditions | |
| TWI801835B (zh) | 往返估算 | |
| KR100931375B1 (ko) | 개선된 파라미터 산출방법이 적용된 데이터 스트림 전송률 제어방법 및 데이터 스트리밍 서버 | |
| JP2010136159A (ja) | データ受信装置 | |
| Chua et al. | Application-level adaptive congestion detection and control for VoIP | |
| AU2002337730A1 (en) | Communication system and techniques for transmission from source to destination |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20081017 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110111 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110311 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20110524 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20110624 |
|
| 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: 20110927 |
|
| 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: 20110929 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20141007 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| LAPS | Cancellation because of no payment of annual fees |