JP5421346B2 - 高速チャンネル変更におけるユニキャストストリームの高速送信方法および装置 - Google Patents

高速チャンネル変更におけるユニキャストストリームの高速送信方法および装置 Download PDF

Info

Publication number
JP5421346B2
JP5421346B2 JP2011277873A JP2011277873A JP5421346B2 JP 5421346 B2 JP5421346 B2 JP 5421346B2 JP 2011277873 A JP2011277873 A JP 2011277873A JP 2011277873 A JP2011277873 A JP 2011277873A JP 5421346 B2 JP5421346 B2 JP 5421346B2
Authority
JP
Japan
Prior art keywords
terminal
multicast
latest
frame
server
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
JP2011277873A
Other languages
English (en)
Other versions
JP2013042473A (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.)
Huawei Technologies Co Ltd
Original Assignee
Huawei Technologies Co Ltd
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 Huawei Technologies Co Ltd filed Critical Huawei Technologies Co Ltd
Publication of JP2013042473A publication Critical patent/JP2013042473A/ja
Application granted granted Critical
Publication of JP5421346B2 publication Critical patent/JP5421346B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43Processing 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/438Interfacing the downstream path of the transmission network originating from a server, e.g. retrieving encoded video stream packets from an IP network
    • H04N21/4383Accessing a communication channel
    • H04N21/4384Accessing a communication channel involving operations to reduce the access time, e.g. fast-tuning for reducing channel switching latency
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/752Media network packet handling adapting media to network capabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/64Addressing
    • H04N21/6405Multicasting

Landscapes

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

Description

本発明はインターネット・プロトコル・テレビジョン(IPTV)の高速チャンネル変更(FCC)に関し、詳細にはFCCにおける高速ユニキャストストリーム送信の方法および装置に関する。
従来のデジタルテレビジョンと比較して、IPTVはチャンネル変更が長いという欠点を有する。FCC方法はチャンネル変更の遅れを短縮することができる。
FCCのプロセス中に、セット・トップ・ボックス(STB)から送られたFCCの要求を受けた後、サーバーは最新のIフレームの前のIフレーム(イントラピクチャー)から始まるユニキャストストリームの高速送信を行う。
先行技術において、ユニキャストストリームは最新のIフレームの前のIフレームから始まる高速送信が行われ、バーストトラフィックは大きく、必要な帯域幅は増大する。さらに、STBは、像コンテントが最新のチャンネルコンテントよりも早期のものであるように、すなわち、最新のチャンネルコンテントと比較してFCC後のコンテントが遅くなるように、最新のIフレームの前のIフレームから始まるデコーディングを行う。STBによって実行されるチャンネコンテントを最新のIフレームの前のIフレームから最新のチャンネルコンテントに同期させる必要があり、これは同期プロセス時間を増加させる。
バーストトラフィックおよびチャンネルコンテントの同期プロセス時間を低減するために、本発明の実施形態はFCCにおけるユニキャストストリームの高速送信の方法および装置を提供する。技術的な解決は以下の通りである。
本発明の一態様によれば、FCCにおけるユニキャストストリームの高速送信の方法は、
端末のマルチキャスト結合遅れを得ることと、
高速ユニキャストストリームの開始位置と端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って最新のパケット位置の間のデータ量の最小値を決定することと、
パケットバッファー状態によって最新のIフレームが完全に到着したかどうかを判断することと、
最新のIフレームが完全に到着し、最新のIフレームから始まる到着したデータ量が最小値以上である場合、最新のIフレームから始まるユニキャストストリームの高速送信を行うことと、を含む。
本発明の他の態様によれば、FCCにおけるユニキャストストリームの高速送信の装置は、
端末のマルチキャスト結合遅れを得るように構成される獲得モジュールと、
端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値を決定するように構成される決定モジュールと、
パケットバッファー状態に従って最新のIフレームが完全に到着したかどうかを判断する判断モジュールと、
最新のIフレームが完全に到着し、最新のIフレームから始まる到着したデータ量が最小値以上である場合、最新のIフレームから始まるユニキャストストリームの高速送信を行うように構成される送信モジュールと、を含む。
本発明の実施形態に提供された技術的解決によりもたらされる有益な効果は、
高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値が、端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って決定され、最新のIフレームが完全に到着し、最新のIフレームから始まる到着したデータ量が最小値以上である場合、最新のIフレームから始まるユニキャストストリームの高速送信が行われる。最新のIフレームの前のIフレームからユニキャストストリームを固定して高速割り込むのに比較して、バーストトラフィックが低減され、同時に、長いマルチキャスト結合遅れに起因する端末のバッファーのアンダーフローを確実に防止し、したがって、端末で実行される像の品質を確保しながら、必要な帯域幅およびチャンネルコンテントのための同期プロセス時間を低減する。
本発明の実施形態による技術的な解決をより明確に説明するために、実施形態または先行技術を説明するのに必要な添付図面が以下で簡単に紹介される。明らかに、以下の説明における添付図面は本発明のいくつかの実施形態のみであり、当業者であれば、創造努力なしに添付図面に従って他の図面を得ることができる。
本発明の第1実施形態によるFCCにおけるユニキャストストリームの高速送信の方法のフローチャートである。 本発明の第2実施形態によるFCCにおけるユニキャストストリームの高速送信の方法のフローチャートである。 本発明の第2実施形態による実時間伝送制御プロトコル(RTCP)拡張レポート(XR)拡張メッセージの概要図である。 本発明の第2実施形態によるFCCの情報対話の図である。 本発明の第2実施形態によるパケットバッファー状態の概要図である。 本発明の第3実施形態によるFCCにおけるユニキャスト高速送信の装置の構造図である。
本発明の目的、技術的解決、および利点の理解をより容易にするために、以下に添付図面を参照して本発明を詳細に説明する。
(実施形態1)
図1を参照すると、この実施形態はFCCにおけるユニキャストの高速送信の方法を提供する。方法は、以下を含む。
101:端末のマルチキャスト結合遅れを得る。
端末はSTB、パーソナルコンピュータ、テレビジョン、または携帯電話、タブレットコンピュータなどの携帯端末とすることができ、この実施形態に制限されない。
102:端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って高速ユニキャストストリームの開始位置と最新パケット位置の間のデータ量の最小値を決定する。
高速ユニキャストストリームの開始位置と最新パケット位置の間のデータ量の最小値は、端末のバッファーのデータ量がマルチキャスト結合遅れ後のデコーディングのために必要な最低バッファーデータ量よりもまだ大きいことを確実にするために用いられる。デコーディングに必要な最低バッファーデータ量はゼロとすることができる。
103:パケットバッファー状態に従って最新のIフレームが完全に到着したかどうかを判断する。
104:最新のIフレームが完全に到着し、最新のIフレームから始まる到着したデータ量が最小値以上である場合、最新のIフレームから始まるユニキャストストリームの高速送信を行う。
端末から送られたFCCを受け取った後、FCCのプロセス中に、サーバーはユニキャストストリームの高速送信を行う。いわゆるユニキャストストリームの高速送信は、ユニキャストの送信速度が元の速度よりも大きい、例えば元の速度の1.3倍の速度であることを指す。端末はユニキャストストリームを受け取り、ユニキャストストリームのデコーディングを行い、デコーディング速度は基本的に元の速度に等しい。ユニキャストストリームがマルチキャストストリームを捕捉したことが判明するとき、サーバーはユニキャストストリームの低速送信を開始し、マルチキャストパケット同期メッセージを端末に送る。いわゆるユニキャストの低速送信は、ユニキャストストリームの送信速度が元の速度よりも小さい、例えば元の速度の0.3倍であることを指す。サーバーがユニキャストストリームの低速送信を行う理由は、ユニキャストストリームの低速送信速度が、通常ユニキャストの高速送信から元の速度を差し引いた速度であるように、端末によって受け取られるマルチキャストストリーム用に十分な帯域幅を確保するためである。無論、他の速度および方法、例えばユニキャストの高速送信を継続することも許される。マルチキャストパケット同期メッセージを受け取った後、端末はインターネットグループ管理プロトコル(IGMP)結合メッセージをマルチキャスト応答点に送り、マルチキャストへの結合およびマルチキャストストリームを受け取る準備を求める。端末がデコードを行って画像を再生するとき、デコーディング速度はユニキャストストリームの低速送信速度よりも大きいので、バッファー中のデータは連続的に消費される。IGMP結合メッセージを送る時間(ユニキャストストリームの低速送信を開始するとき、サーバーはマルチキャストパケット同期メッセージを送るので、端末によるIGMP結合メッセージを送る時間は、端末がマルチキャストストリームの低速送信の受け取りを開始する時間でもある)と端末によるマルチキャストストリームを受け取る時間の間の遅れ、すなわちマルチキャストストリーム結合遅れが長い場合、バッファー中のデータ量はアンダーフローする、すなわちデータ量は閾値以下まで低減され、または消去されて、デコーダーがデコーディングのための十分なデータを持たなくなり、これは再生される像の停止または不鮮明なスクリーン現象を招く。
この実施形態において、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値は、端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って決定され、最新のIフレームが完全に到着し、到着した最新のIフレームから始まるデータ量が最小値以上である場合、ユニキャストストリームは最新のIフレームから始まる高速送信が行われる。最新のIフレームの前のフレームからユニキャストストリームを固定して高速割り込むのに比較して、バーストトラフィックは低減され、同時に端末のバッファーは長いマルチキャスト結合遅れに起因するアンダーフローが確実に防止され、したがって、端末で実行される像の品質を確保しながら、帯域幅の要求およびチャンネルコンテントのための同期プロセス時間が減少する。
(実施形態2)
この実施形態は第1の実施形態に基づく改善である。図2を参照すると、FCCにおけるユニキャストストリームの高速送信の方法は以下を含む。
201:サーバーが端末のマルチキャスト結合遅れを得る。
詳細には、端末によって送られたRTCPXR拡張メッセージが受け取られ、RTCPXR拡張メッセージは端末のマルチキャスト結合遅れの関連情報を保持する。端末のマルチキャスト結合遅れの関連情報はマルチキャスト結合遅れ、または端末によるマルチキャスト結合メッセージを送る時間および端末による最初のマルチキャストパケット(FMP)を受け取る時間とすることができ、マルチキャスト結合遅れは、端末がマルチキャスト結合メッセージを送る時間と端末がFMPを受け取る時間によって計算して得られ、すなわち、端末がマルチキャスト結合メッセージを送る時間と端末がFMPを受け取る時間の間隔はマルチキャスト結合遅れである。端末のマルチキャスト結合遅れは、端末のヒストリーデータによって得られる。
図3は、RTCPXR拡張メッセージの一例を示し、拡張フィールドはIGMP結合遅れ、すなわちマルチキャスト結合遅れを含み、または拡張フィールドはigmp結合送信時間および最初のマルチキャストバースト時間、すなわち、端末によるマルチキャスト結合メッセージを送る時間および端末によるFMPを受け取る時間を含む。あるいは、拡張フィールドは前述の3つの拡張フィールドを含むこともできる。
202:サーバーは端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値を決定する。
詳細には、Vi(min)=(nX−sX)×T3+cBにより、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値Vi(min)が決定される。
Vi(min)は高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値であり、nXはデコーディング速度であり、Xはビデオ平均速度であり、nはデコーディング倍率であり、sXはユニキャスト送信速度であり、sは送信倍率である。詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するとき、サーバーがユニキャストストリームの低速送信を行う状況の下で、sは低速送信倍率(bに設定される)、すなわちb<1である。詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するときの状況下で、マルチキャスト応答点がマルチキャストストリームを送るまでサーバーはやはりユニキャストの高速送信を行い、sは高速送信倍率(aに設定される)、すなわちa>1である。T3は端末のマルチキャスト結合遅れであり、cBは端末のデコーディングに必要な最低バッファーデータ量であり、cはバッファー係数であり、Bはビデオバッファー検証(VBV)がバッファリングすることのできる最大データ量である。
図4はFCCの情報対話の図であり、情報対話は以下を含む。
301:端末が時点1でサーバーにFCC要求を送信する。
302:サーバーは時点2でFCC要求を受け取り、端末にユニキャストの高速送信を開始する。ユニキャストストリームがマルチキャストストリームを捕捉するとき、すなわち、時点3でサーバーはユニキャストストリームの低速送信を開始し、マルチキャストパケット同期メッセージを端末に送る。
サーバーによってユニキャストの高速送信がわれる、時点2から時点3までの間の間をT1とする。この実施形態において、サーバーがユニキャストパケットの低速送信を開始する時点はサーバーがマルチキャストパケット同期メッセージを送る時点に設定される。
303:端末は同期メッセージを受け取り、時点4でマルチキャスト結合要求を送る。
端末は、マルチキャスト結合遅れがマルチキャスト応答点のレベル、リンク状態、アクセス状況、およびクライエント状況などの要因によって影響を受けるように、対応するマルチキャスト応答点にマルチキャスト結合メッセージを送る。一例として、展開されるネットワークのためのマルチキャスト応答点のレベルを取り上げると、マルチキャスト応答点のレベルは固定され、マルチキャスト応答点の各レベルは固定されたマルチキャスト結合遅れを有し、ユーザーの結合を要求するチャンネルのデータが最も近いマルチキャスト応答点に到着する場合、上位レベルのマルチキャスト応答点からのチャンネルデータを要求する必要はなく、マルチキャスト結合遅れは比較的短い。最も近いマルチキャスト応答点がユーザーの要求するチャンネルデータを持たない場合、上位レベルまたはさらに上位レベルのマルチキャスト応答点からチャンネルデータを要求する必要はなく、マルチキャスト結合遅れは比較的長い。
時点4での端末によるバッファリングされたデータ量はV1、すなわち高速ユニキャストストリームがマルチキャストを捕捉するときに端末によってバッファリングされるデータ量である。
304:端末は点5でFMPを受け取る。
時点3から時点5までの間の時間である、サーバーがユニキャストパケットの低速送信を開始するときから端末がFMPを受け取るときまでの時間隔をT2とし、時点4から時点5までの間の時間である、マルチキャスト結合遅れをT3とする
時点5で端末によってバッファリングされるデータ量はV2、すなわち端末がFMPを受け取るときのバッファリングされたデータ量である。
305:端末はFMP識別を保持する同期メッセージ応答をサーバーに戻す。
306:同期メッセージ応答を受け取った後、サーバーは時点6でユニキャストストリームの低速送信を停止する。
時点3から時点6までの間の時間である、ユニキャストストリーム低速送信される時間間隔をT4とする
この実施形態において、以下のように設定される。ビデオ平均速度(元の速度)はX Mbpsであり、デコーディング速度はnX Mbpsであり、nはデコーディング倍率、通常n=1であり、高速ユニキャスト送信速度はaXであり、aは高速送信倍率、現在aは通常1.3であり、ユニキャスト低速送信速度はbXであり、bは低速送信倍率であり、現在bは通常0.3であり、通常端末のVBVがバッファリングできる最大データ量はB=7995392ビット=0.95Mバイトであり、端末のデコーディングに必要な最低バッファーデータ量はcBであり、cはバッファー係数であり、現在、それは通常c=1/2に制御され、VBVによってバッファリングされるデータ量がcBより小さいとき、デコーディングは開始することができない。端末が他の値を有する他の態様で評価するとき、例えば、端末のバッファーが完全に消去された簡略化した状態で決定されるとき、端末はデコーディングを実行することができない。Viはユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量であり、Vi(min)はユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量の最小値である。
時点3で、ユニキャスト送信のデータ量はマルチキャスト送信のデータ量よりもVi多く、増加したデータ量と端末がFMPを受け取る前に受け取ったデータ量bXT3の和は時点T3で端末がデコーディングを行ったデータ量nXT3よりも大きい。すなわち、Vi−cB+bXT3>=nXT3およびVi>=(nX−bX)×T3+cBである。したがって、像品質の劣化を防止するためのViの最小値はVi(min)=(nX−bX)×T3+cBである。
当業者であれば、原理に従って、他のユニキャスト態様、例えば、時点3の後に、マルチキャスト応答点がマルチキャストストリームを送るまでユニキャストはまだ高速送信が行われ、または時点3の後にユニキャストは所定時間まだ高速送信が行われ、次いでユニキャストの低速送信が行われ、高速ユニキャストストリームの開始位置と最新のパケット位置の間の対応するデータ量の最小値を得ることもできる態様を理解する。例えば、時点3の後に、マルチキャスト応答点がマルチキャストストリームを送るまでユニキャストの高速送信がまだ行われる態様については、Vi>=(nX−aX)×T3+cBである。aXはユニキャストの送信速度であり、詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するとき、マルチキャストの応答点がマルチキャストストリームを送るまでサーバーがまだユニキャストの高速送信を行う状況下で、aは高速送信倍率、すなわちa>1である。ここで、像品質の劣化の主な理由はデコーディングに必要なバッファリングされたデータ量が大きいことである。同様に、時点3の後ユニキャストが所定時間やはり高速送信が行われ、次いでユニキャストの低速送信が行われる態様については、Vi(min)=(nX−sX)×T3+cBであり、ここでb<s<aである。
203:サーバーは、最新のIフレームがパケットバッファー状態に従って完全に到着するかどうかを判断する。
図5に示すサーバーのパケットバッファー状態の概要図を参照すると、点線部分は最新のIフレームを表し、サーバーのパケットバッファー状態は概略2つの状態に分割され、1つは最新のIフレームが完全に到着し(状態1)、他は最新のIフレームが完全に到着しない(状態2)。最新のIフレームが完全に到着する状態はさらに定義することができ、すなわち、最新のIフレームから始まるデータ量は最新のIフレームによって形成され(状態1−1)または最新のIフレームと後続のフレームによって形成される(状態1−2)。
204:サーバーは最新のIフレームが完全に到着するかどうかに従って、対応するIフレームから始まるユニキャストストリームの高速送信を行う。
詳細には、最新のIフレームが完全に到着し、最新のIフレームから始まるデータ量が最小値Vi(min)以上である場合、ユニキャストストリームは最新のIフレームから高速送信が行われる。
最新のIフレームが完全に到着し、最新のIフレームから始まるデータ量が最小値よりも小さい場合、最新のIフレームの前のIフレームからユニキャストストリームの高速送信が始まり、最新のIフレームの前のIフレームは最新のIフレームの前のIフレーム、またはより早期のIフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のIフレームの前のIフレームからユニキャストストリームの高速送信が行われる前に、最新のIフレームの前のIフレームから始まる到着したデータ量が最小値Vi(min)以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のIフレームの前のIフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のIフレームよりも早期のIフレームからユニキャストストリームの高速送信が行われる。
最新のIフレームが完全に到着しない場合、最新のIフレームの前のIフレームからユニキャストストリームの高速送信が行われ、最新のIフレームの前のIフレームは最新のIフレームの前のIフレーム、またはより早期のIフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のIフレームの前のIフレームからユニキャストストリームの高速送信が行われる前に、最新のIフレームの前のIフレームから始まる到着したデータ量が最小値Vi(min)以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のIフレームの前のIフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のIフレームよりも早期のIフレームからユニキャストストリームの高速送信が行われる。
最新のIフレームの前のIフレームは最新のIフレームの前のIフレーム、または早期のIフレームであってもよい。
この実施形態において、ユニキャストストリームの高速送信の開始位置と最新パケット位置の間のデータ量の最小値は、端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って決定される。ユニキャストストリームは、最新のIフレームが完全に到着し、最新のIフレームからの到着したデータ量が最小値以上である場合、最新のIフレームから始まる高速送信である。最新のIフレームの前のIフレームからユニキャストの固定された高速送信に比較して、バーストトラフィックは低減され、同時に、端末のバッファーは長いマルチキャスト結合遅れに起因するアンダーフローが確実に防止され、したがって、端末で実行される像の品質を確保しながら、チャンネルコンテントのための帯域幅の要求および同期プロセス時間が減少する。
(実施形態3)
図6を参照すると、この実施形態はFCCにおけるユニキャストの高速送信の装置を提供し、装置は、以下を含む。
獲得モジュール401は端末のマルチキャスト結合遅れを得るように構成される。
決定モジュール402は、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値を端末のマルチキャスト結合遅れ、デコーディング速度、ユニキャスト送信速度、およびデコーディングに必要な最低バッファーデータ量に従って決定するように構成される。
判断モジュール403はパケットバッファー速度に従って最新のIフレームが完全に到着するかどうかを判断するように構成される。
図5に示したサーバーのパケットバッファー状態の概要図を参照すると、点線部分は最新のIフレームを表し、サーバーのパケットバッファー状態は概略2つの状態に分割され、1つは最新のIフレームが完全に到着し(状態1)、他は最新のIフレームが完全に到着しない(状態2)。最新のIフレームが完全に到着する状態はさらに定義することができ、すなわち、最新のIフレームから始まるデータ量は最新のIフレームによって形成され(状態1−1)または最新のIフレームと後続のフレームによって形成される(状態1−2)。
送信モジュール404は、最新のIフレームが完全に到着し、最新のIフレームから到着したデータ量が最小値以上である場合、最新のIフレームから始まるユニキャストストリームの高速送信を行うように構成される。
獲得モジュール401は端末によって送られたRTCPXR拡張メッセージを受け取るように構成され、RTCPXR拡張メッセージは端末のマルチキャスト結合遅れの関連情報を保持する。関連情報は、以下を含む。
マルチキャスト結合遅れ、ここで、マルチキャスト結合遅れは端末によるマルチキャスト結合メッセージを送る時間と端末によるFMPを受け取る時間の間隔であり、または、
端末によるマルチキャスト結合メッセージを送る時間および端末によるFMPを受け取る時間であり、または、
マルチキャスト結合遅れ、端末によるマルチキャスト結合メッセージを送る時間、および端末によるFMPを受け取る時間である。
図3は、RTCPXR拡張メッセージの一例を示し、拡張フィールドはIGMP結合遅れ、すなわちマルチキャスト結合遅れを含み、または拡張フィールドはigmp結合送信時間および最初のマルチキャストバースト時間、すなわち、端末によるマルチキャスト結合メッセージを送る時間および端末によるFMPを受け取る時間を含む。あるいは、拡張フィールドは前述の3つの拡張フィールドを含むこともできる。
決定モジュール402は、詳細には、
Vi(min)=(nX−sX)×T3+cBに従って高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値Vi(min)を決定するように構成され、
Vi(min)は高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値であり、
nXはデコーディング速度であり、nはデコーディング倍率であり、Xはビデオ平均速度であり、
sXはユニキャスト送信速度であり、sは送信倍率であり、
T3は端末のマルチキャスト結合遅れであり、
cBは端末のデコーディングに必要な最低バッファーデータ量であり、cはバッファー係数であり、BはVBVがバッファリングすることのできる最大データ量である。
図4に示したFCCの情報対話の図に基づいて、この実施形態において、以下のように設定される。ビデオ平均速度(元の速度)はX Mbpsであり、デコーディング速度はnX Mbpsであり、nはデコーディング倍率、通常n=1であり、高速ユニキャスト送信速度はaXであり、aは高速送信倍率、現在aは通常1.3であり、ユニキャスト低速送信速度はbXであり、bは低速送信倍率であり、現在bは通常0.3であり、端末のVBVがバッファリングできる最大データ量はB=7995392ビット=0.95Mバイトであり、端末のデコーディングに必要な最低バッファーデータ量はcBであり、cはバッファー係数であり、現在、それは通常c=1/2に制御され、VBVによってバッファリングされるデータ量がcBより小さいとき、デコーディングは開始することができない。端末が他の値を有する他の態様で評価するとき、例えば、端末のバッファーが完全に消去された簡略化した状態で決定されるとき、端末はデコーディングを実行することができない。Viはユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量であり、Vi(min)はユニキャストストリームの高速送信開始位置と最新パケット位置の間のデータ量の最小値である。
時点3で、ユニキャスト送信のデータ量はマルチキャスト送信のデータ量よりもVi多く、増加したデータ量と端末がFMPを受け取る前に受け取ったデータ量bXT3の和は時点T3で端末がデコーディングを行ったデータ量nXT3よりも大きい。すなわち、Vi−cB+bXT3>=nXT3およびVi>=(nX−bX)×T3+cBである。したがって、像品質の劣化を防止するために、Viの最小値はVi(min)=(nX−bX)×T3+cBである。
当業者であれば、原理に従って、他のユニキャスト態様、例えば、時点3の後にマルチキャスト応答点がマルチキャストストリームを送るまでまだユニキャストの高速送信が行われ、または時点3の後にまだ所定時間ユニキャストの高速送信が行われ、次いでユニキャストの低速送信が行われ、高速ユニキャストストリームの開始位置と最新のパケット位置の間の対応するデータ量の最小値を得ることもできる態様を理解する。例えば、時点3の後に、マルチキャスト応答点がマルチキャストストリームを送るまでまだユニキャストの高速送信が行われる態様については、Vi>=(nX−aX)×T3+cBである。aXはユニキャストの送信速度であり、詳細には、ユニキャストストリームがマルチキャストストリームを捕捉するとき、マルチキャストの応答点がマルチキャストストリームを送るまでまだサーバーがユニキャストの高速送信を行う状況下で、aは高速送信倍率、すなわちa>1である。ここで、像品質の劣化の主な理由はデコーディングに必要なバッファリングされたデータ量が大きいことである。同様に、時点3の後ユニキャストが所定時間やはり高速送信が行われ、次いでユニキャストの低速送信が行われる態様については、Vi(min)=(nX−sX)×T3+cBであり、ここでb<s<aである。
さらに、送信モジュール404は、最新のIフレームが完全に到着し、最近のIクレームから到着したデータ量が最小値よりも小さい場合、最新のIフレームの前のIフレームから始まるユニキャストストリームの高速送信が行われるように構成され、最新のIフレームの前のIフレームは最新のIフレームの前のIフレーム、またはより早期のIフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のIフレームの前のIフレームから始まるユニキャストストリームの高速送信が行われる前に、最新のIフレームの前のIフレームから始まる到着したデータ量が最小値Vi(min)以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のIフレームの前のIフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のIフレームよりも早期のIフレームから始まるユニキャストストリームの高速送信が行われる。
さらに、送信モジュール404は、最新のIフレームが完全に到着しない場合、最新のIフレームの前のIフレームからユニキャストストリームの高速送信が行われるように構成され、最新のIフレームの前のIフレームは最新のIフレームの前のIフレーム、またはより早期のIフレームであってもよい。さらに、マルチキャスト結合遅れが長くなるのを防止するために、デコーダーがデコーディングのための十分なデータを持たないようにバッファー中のデータ量をアンダーフローしてもよく、これは実行される像の停止または不鮮明なスクリーン現象を招く。最新のIフレームの前のIフレームからユニキャストストリームの高速送信が始まる前に、最新のIフレームの前のIフレームから始まる到着したデータ量が最小値Vi(min)以上である条件を満足するかどうかを判断し、データ量が条件を満足する場合、ユニキャストストリームは最新のIフレームの前のIフレームから高速送信が行われ、データ量が条件を満たさない場合、条件を満たす最新のIフレームよりも早期のIフレームからユニキャストストリームの高速送信が始まる。
この実施形態に提供される装置および方法実施形態のサーバーは同じ概念に属し、特定の実施プロセスについてはここには繰り返して説明されない方法の実施形態を参照されたい。
この実施形態において、高速ユニキャストストリームの開始位置と最新のパケット位置の間のデータ量の最小値は、端末のマルチスキャン結合遅れ、デコーディング速度、ユニキャスト送信速度、デコーディングに必要な最低バッファーデータ量に従って決定される。最新のIフレームが完全に到着し、最新のIフレームから到着したデータ量が最小値以上である場合、ユニキャストストリームは最新のIフレームから始まる高速送信が行われる。最新のIフレームの前のフレームから始まるユニキャストストリームを固定して高速割り込むのに比較して、バーストトラフィックは低減され、同時に端末のバッファーは長いマルチキャスト結合遅れに起因するアンダーフローが確実に防止され、したがって、端末で実行される像の品質を確保しながら、帯域幅の要求およびチャンネルコンテントのための同期プロセス時間が減少する。
実施形態によって提供される技術的解決における内容の全てまたは一部分は、ソフトウェアプログラミングによって実施することができ、ソフトウェアプログラムは読み取り可能な記憶媒体、例えばコンピュータ中のハードディスク、光ディスク、またはフロッピー(登録商標)ディスクに保存することができる。
前述の説明は単に本発明のいくつかの例示的実施形態であるが、本発明の保護範囲を制限するものではない。本発明に開示された技術範囲における当業者であれば容易に想起することのできるさまざまな修正および変更は本発明の保護範囲に含まれる。したがって、本発明の保護範囲は請求項の保護範囲に従属する。
401 獲得モジュール
402 決定モジュール
403 判断モジュール
404 送信モジュール

Claims (10)

  1. サーバーにより、端末から高速チャンネル変更(FCC)要求を受け取ることと、
    サーバーにより、前記端末のマルチキャスト遅れを得ることであって、前記端末のマルチキャスト遅れは、前記端末がマルチキャストストリームを受け取るためのマルチキャスト要求メッセージをマルチキャスト応答点に送る時間と、前記端末が最初のマルチキャストパケット(FMP)を受け取る時間の間隔である、ことと、
    前記サーバーにより、前記端末のマルチキャスト遅れ、前記端末がユニキャストストリームをデコーディングするためのデコーディング速度、ユニキャストストリーム送信速度、及び前記端末がユニキャストストリームをデコーディングするために必要な前記端末の最低バッファーデータ量に従って、前記FCC要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの最小バッファーデータ量の値を決定することと、
    前記サーバーにより、前記サーバー上のパケットバッファー状態に従って最新のIフレームの全てが到着したかどうかを判断することと、
    前記最新のIフレームの全てが到着し、前記最新のIフレームから始まる到着したデータ量が前記最小バッファーデータ量の値以上である場合、前記高速送信されるユニキャストストリームの前記高速送信を前記最新のIフレームから始めることと、
    を含むことを特徴とするFCCにおけるユニキャストストリームの高速送信方法。
  2. 前記端末の前記マルチキャスト遅れを得ることが、
    前記サーバーにより、前記端末によって送られた実時間伝送制御プロトコル拡張レポート(RTCPXR)拡張メッセージを受け取ることを含み、前記RTCPXR拡張メッセージは前記端末の前記マルチキャスト遅れの関連情報を保持し、前記関連情報が、
    前記端末による前記マルチキャスト要求メッセージを送る時間と前記端末による最初のFMPを受け取る時間の間隔、または、
    前記端末による前記マルチキャスト要求メッセージを送る時間と前記端末による前記FMPを受け取る前記時間、または、
    前記マルチキャスト遅れ、前記端末による前記マルチキャスト要求メッセージを送る前記時間、および前記端末による前記FMPを受け取る前記時間を含むことを特徴とする、請求項1に記載の方法。
  3. 前記サーバーにより、前記端末の前記マルチキャスト遅れ、前記端末がユニキャストストリームをデコーディングするための前記デコーディング速度、前記ユニキャスト送信速度、および前記端末がユニキャストストリームをデコーディングするために必要な前記端末の前記最低バッファーデータ量に従って、前記FCC要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値を決定することが、
    前記サーバーにより、Vi(min)=(nX−sX)×T3+cBにより、前記FCC要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値を決定することを含み、
    Vi(min)は前記FCC要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値であり、
    nXは前記デコーディング速度であり、nはデコーディング倍率であり、Xは前記ビデオ平均ビット速度であり、
    sXは前記ユニキャストストリーム送信速度であり、sは送信倍率であり、
    T3は端末のマルチキャスト遅れであり、
    cBは前記端末の前記デコーディングのために必要な最低バッファーデータ量であり、cはバッファー係数であり、Bはビデオバッファリング検証(VBV)がバッファーできる最大データ量であることを特徴とする、請求項1または2に記載の方法。
  4. 前記サーバーにより、前記パケットバッファー状態に従って前記最新のIフレームの全てが到着したかどうかを判断した後、
    前記サーバーにより、前記最新のIフレームの全てが到着し、前記最新のIフレームから始まる前記到着したデータ量が前記最小バッファーデータ量の値より小さい場合、前記高速送信されるユニキャストストリームの前記高速送信を前のIフレームから始めることをさらに含むことを特徴とする、請求項1から3のいずれか一項に記載の方法。
  5. 前記サーバーにより、前記パケットバッファー状態に従って前記最新のIフレームの全てが到着したかどうかを判断した後、
    前記最新のIフレームの全てが到着していない場合、前記高速送信されるユニキャストストリームの前記高速送信を前記最新のIフレームの前のIフレームから始めることをさらに含むことを特徴とする、請求項1から3のいずれか一項に記載の方法。
  6. 高速チャンネル変更(FCC)におけるユニキャストストリームの高速送信のための装置であって、
    端末から高速チャンネル変更(FCC)要求を受け取った後に、前記端末がマルチキャストストリームを受け取るためのマルチキャスト要求メッセージをマルチキャスト応答点に送る時間と、前記端末が最初のマルチキャストパケット(FMP)を受け取る時間の間隔である前記端末のマルチキャスト遅れを得るように構成される獲得モジュールと、
    前記端末の前記マルチキャスト遅れ、前記端末がユニキャストストリームをデコーディングするためのデコーディング速度、ユニキャストストリーム送信速度、及び前記端末がユニキャストストリームをデコーディングするために必要な前記端末の最低バッファーデータ量に従って、前記FCC要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの最小バッファーデータ量の値を決定するように構成される決定モジュールと、
    前記装置上のパケットバッファー状態に従って最新のIフレームの全てが到着したかどうかを判断するように構成された判断モジュールと、
    前記最新のIフレームの全てが到着し、前記最新のIフレームから始まる到着した前記データ量が前記最小バッファーデータ量の値以上である場合、前記高速送信されるユニキャストストリームの前記高速送信を前記最新のIフレームから開始するように構成される送信モジュールとを含むことを特徴とする装置。
  7. 前記獲得モジュールが、前記端末によって送られた実時間伝送制御プロトコル拡張レポート(RTCPXR)拡張メッセージを受け取るように構成され、前記RTCPXR拡張メッセージが前記端末の前記マルチキャスト結合遅れの関連情報を保持し、
    前記関連情報がマルチキャスト遅れを含み、前記マルチキャスト遅れが、前記端末によるマルチキャスト要求メッセージを送る時間と前記端末による最初のマルチキャストパケットを受け取る時間の間隔、または、
    前記端末による前記マルチキャスト要求メッセージを送る時間と前記端末による前記FMPを受け取る時間、または、
    前記マルチキャスト遅れ、前記端末による前記マルチキャスト要求メッセージを送る前記時間、および前記端末による前記FMPを受け取る前記時間を含むことを特徴とする、請求項6に記載の装置。
  8. 前記決定モジュールが、
    Vi(min)=(nX−sX)×T3+cBに従って前記FCC要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値を決定するように構成され、
    Vi(min)は前記FCC要求を受信した前記サーバーがビデオ平均ビット速度よりも速いビット速度で高速送信されるユニキャストストリームを送信するときの前記サーバーの前記最小バッファーデータ量の値であり、
    nXは前記デコーディング速度であり、nはデコーディング倍率であり、Xは前記ビデオ平均ビット速度であり、
    sXは前記ユニキャストストリーム送信速度であり、sは送信倍率であり、
    T3は前記端末の前記マルチキャスト遅れであり、
    cBは前記端末のデコーディングのために必要な前記最低バッファーデータ量であり、cはバッファー係数であり、Bはビデオバッファリング検証(VBV)がバッファーできる最大データ量であることを特徴とする、請求項6または7に記載の装置。
  9. 前記送信モジュールがさらに、
    前記最新のIフレームの全てが到着し、前記最新のIフレームから始まる到着したデータ量が前記最小バッファーデータ量の値より小さい場合、前記最新のIフレームの前のIフレームから前記高速送信されるユニキャストストリームの前記高速送信を開始するように構成されることを特徴とする、請求項6から8のいずれか一項に記載の装置。
  10. 前記送信モジュールがさらに、
    前記最新のIフレームの全てが到着していない場合、前記最新のIフレームの前のIフレームIから前記高速送信されるユニキャストストリームの前記高速送信を開始するように構成されることを特徴とする、請求項6から8のいずれか一項に記載の装置。
JP2011277873A 2010-12-20 2011-12-20 高速チャンネル変更におけるユニキャストストリームの高速送信方法および装置 Active JP5421346B2 (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN201010602783.2 2010-12-20
CN2010106027832A CN102137275B (zh) 2010-12-20 2010-12-20 快速频道切换中快速推送单播流的方法和装置

Publications (2)

Publication Number Publication Date
JP2013042473A JP2013042473A (ja) 2013-02-28
JP5421346B2 true JP5421346B2 (ja) 2014-02-19

Family

ID=44296916

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2011277873A Active JP5421346B2 (ja) 2010-12-20 2011-12-20 高速チャンネル変更におけるユニキャストストリームの高速送信方法および装置

Country Status (8)

Country Link
US (1) US8861372B2 (ja)
EP (1) EP2466911B1 (ja)
JP (1) JP5421346B2 (ja)
CN (1) CN102137275B (ja)
BR (1) BRPI1107348B8 (ja)
CA (1) CA2758763C (ja)
HU (1) HUE025968T2 (ja)
MX (1) MX2011013684A (ja)

Families Citing this family (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ITTO20110745A1 (it) 2011-08-05 2013-02-06 Indesit Co Spa Cassetto per una vasca di una lavastoviglie comprendente un telaio perimetrale estraibile da detta vasca
TW201338528A (zh) * 2012-03-02 2013-09-16 Mstar Semiconductor Inc 數位電視資料處理方法以及使用此數位電視資料處理方法的數位電視系統
CN103533437A (zh) * 2013-10-30 2014-01-22 乐视致新电子科技(天津)有限公司 一种智能电视的频道切换方法及装置
WO2015145834A1 (ja) 2014-03-24 2015-10-01 株式会社スクウェア・エニックス インタラクティブシステム、端末装置、サーバ装置、制御方法、プログラム、及び記録媒体
WO2016184646A1 (en) 2015-05-20 2016-11-24 Nxt Solutions Ag Iptv in managed networks
CN106937155B (zh) * 2015-12-29 2020-06-02 北京华为数字技术有限公司 接入设备、因特网协议电视iptv***和频道切换方法
WO2017185212A1 (zh) * 2016-04-25 2017-11-02 华为技术有限公司 一种组播时延诊断方法及装置
CN108471548B (zh) * 2018-01-25 2021-07-06 湖南于一科技有限公司 直播视频快速播放方法及装置
CN109756745B (zh) * 2018-12-06 2021-06-15 北京东方广视科技股份有限公司 一种直播流数据的发送方法、直播加速服务器及终端
KR102654716B1 (ko) * 2019-02-11 2024-04-04 한화비전 주식회사 요청된 영상 재생시점에 따라 영상을 재생하는 방법 및 그 장치
CN111866526B (zh) * 2019-04-29 2021-10-15 华为技术有限公司 一种直播业务处理方法和装置
CN114363715A (zh) * 2021-12-22 2022-04-15 中国电信股份有限公司 视频播放方法及相关设备

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7562375B2 (en) * 2003-10-10 2009-07-14 Microsoft Corporation Fast channel change
US7430222B2 (en) * 2004-02-27 2008-09-30 Microsoft Corporation Media stream splicer
US20090064242A1 (en) * 2004-12-23 2009-03-05 Bitband Technologies Ltd. Fast channel switching for digital tv
US8713195B2 (en) * 2006-02-10 2014-04-29 Cisco Technology, Inc. Method and system for streaming digital video content to a client in a digital video network
CN101212328B (zh) * 2006-12-27 2010-05-19 中兴通讯股份有限公司 组播频道快速启动***及其方法
CN101212406A (zh) * 2006-12-28 2008-07-02 中兴通讯股份有限公司 组播频道快速启动***
CN101267538B (zh) * 2007-03-15 2010-09-08 华为技术有限公司 一种切换网络电视频道的方法和***
US9032433B2 (en) * 2007-10-05 2015-05-12 Alcatel Lucent Personalized ad insertion during start over service
US8424036B2 (en) * 2007-10-05 2013-04-16 Alcatel Lucent Targeted/addressable advertisement insertion into video streams delivered to users
EP2353292A1 (en) * 2008-09-24 2011-08-10 Alcatel Lucent Client configuration and management for fast channel change of multimedia services
US20100115566A1 (en) * 2008-10-30 2010-05-06 Raziel Haimi-Cohen Fast Channel Change Request Processing
US7830908B2 (en) * 2008-11-03 2010-11-09 Cisco Technologies, Inc. Systems and methods of reducing delay in decoding
US9077937B2 (en) * 2008-11-06 2015-07-07 Alcatel Lucent Method and apparatus for fast channel change
US8381258B2 (en) * 2008-11-14 2013-02-19 Alcatel Lucent Creating channel sequence segments for fast channel change in IPTV
CN102356619B (zh) * 2009-03-16 2016-11-09 皇家Kpn公司 已修改流同步
CN101854336A (zh) * 2009-03-31 2010-10-06 华为技术有限公司 一种获取视频传输管理服务器地址的方法、***和装置
WO2011022868A1 (zh) * 2009-08-24 2011-03-03 华为技术有限公司 频道切换方法、装置和***
US8301982B2 (en) * 2009-11-18 2012-10-30 Cisco Technology, Inc. RTP-based loss recovery and quality monitoring for non-IP and raw-IP MPEG transport flows

Also Published As

Publication number Publication date
BRPI1107348B1 (pt) 2018-12-26
BRPI1107348A2 (pt) 2013-11-05
EP2466911B1 (en) 2015-08-19
MX2011013684A (es) 2012-06-19
JP2013042473A (ja) 2013-02-28
CA2758763A1 (en) 2012-06-20
CA2758763C (en) 2016-01-26
CN102137275B (zh) 2012-12-19
HUE025968T2 (en) 2016-05-30
US8861372B2 (en) 2014-10-14
BRPI1107348B8 (pt) 2019-07-16
EP2466911A1 (en) 2012-06-20
CN102137275A (zh) 2011-07-27
US20120155280A1 (en) 2012-06-21

Similar Documents

Publication Publication Date Title
JP5421346B2 (ja) 高速チャンネル変更におけるユニキャストストリームの高速送信方法および装置
JP5663810B2 (ja) チャネル切替を処理するための方法、システム、および関連デバイス
US7793329B2 (en) Method and system for reducing switching delays between digital video feeds using multicast slotted transmission technique
EP1708506B1 (en) Rapid media channel changing mechanism and access network node comprising same
KR101330907B1 (ko) 디지털 비디오 장치에서 채널 변경 시간을 단축하는 방법
JP5650197B2 (ja) マルチキャスト配信を通じてメディアを提供するシステムのための方法及び装置
EP2424241A1 (en) Method, device and system for forwarding video data
WO2019062050A1 (zh) 直播管控方法、装置及电子设备
WO2017096935A1 (zh) 一种快速频道切换方法、服务器及iptv***
EP2494774B1 (en) Method of digital audio/video channel change and corresponding apparatus
CN102547449A (zh) 一种控制终端缓冲媒体流数据的方法、机顶盒及媒体服务器
CN113242436B (zh) 直播数据的处理方法、装置及电子设备
US20120117265A1 (en) Method and communication system for implementing stream services, and relevant device
JP2010028516A (ja) 映像配信システム、映像配信装置、映像受信装置、映像配信方法、映像受信方法及びプログラム
CN105245946B (zh) 可变码率媒体流的流量控制方法、装置以及***
US10834166B2 (en) Transmission apparatus that is capable of maintaining transmission quality in switching transmission path, reception apparatus, transmission and reception system, method of controlling transmission apparatus and reception apparatus, and storage medium
CN115102927B (zh) 一种保持视频清晰的sip对讲方法、***、存储装置
WO2011022983A1 (zh) 组播视频数据的方法、装置及***
CN116170612A (zh) 一种直播的实现方法、边缘节点、电子设备及存储介质
GB2500406A (en) Providing rapid channel changes, with client itself assessing technical environment and network connection parameters

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130319

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20130617

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20130716

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20131015

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20131121

R150 Certificate of patent or registration of utility model

Ref document number: 5421346

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

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250