JP4596693B2 - Streaming method and system for executing the same - Google Patents
Streaming method and system for executing the same Download PDFInfo
- Publication number
- JP4596693B2 JP4596693B2 JP2001202147A JP2001202147A JP4596693B2 JP 4596693 B2 JP4596693 B2 JP 4596693B2 JP 2001202147 A JP2001202147 A JP 2001202147A JP 2001202147 A JP2001202147 A JP 2001202147A JP 4596693 B2 JP4596693 B2 JP 4596693B2
- Authority
- JP
- Japan
- Prior art keywords
- terminal
- server
- buffer
- target amount
- data
- 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 - Lifetime
Links
- 238000000034 method Methods 0.000 title claims description 58
- 230000005540 biological transmission Effects 0.000 claims description 204
- 239000000872 buffer Substances 0.000 claims description 204
- 238000012546 transfer Methods 0.000 claims description 29
- 230000008859 change Effects 0.000 claims description 23
- 230000007704 transition Effects 0.000 claims description 22
- 230000007423 decrease Effects 0.000 claims description 18
- 230000003247 decreasing effect Effects 0.000 claims description 13
- 238000001514 detection method Methods 0.000 claims description 12
- 238000004422 calculation algorithm Methods 0.000 description 29
- 230000006870 function Effects 0.000 description 28
- 238000010586 diagram Methods 0.000 description 25
- 230000005684 electric field Effects 0.000 description 21
- 230000008569 process Effects 0.000 description 15
- 238000012545 processing Methods 0.000 description 13
- 238000009825 accumulation Methods 0.000 description 11
- 238000007906 compression Methods 0.000 description 10
- 230000006835 compression Effects 0.000 description 10
- 101000969688 Homo sapiens Macrophage-expressed gene 1 protein Proteins 0.000 description 5
- 102100021285 Macrophage-expressed gene 1 protein Human genes 0.000 description 5
- 230000003139 buffering effect Effects 0.000 description 5
- 238000002360 preparation method Methods 0.000 description 5
- 238000004364 calculation method Methods 0.000 description 4
- 230000004044 response Effects 0.000 description 4
- 238000013459 approach Methods 0.000 description 3
- 238000004891 communication Methods 0.000 description 3
- 230000006866 deterioration Effects 0.000 description 3
- 230000009467 reduction Effects 0.000 description 3
- 238000013144 data compression Methods 0.000 description 2
- 238000013500 data storage Methods 0.000 description 2
- 230000003111 delayed effect Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000008707 rearrangement Effects 0.000 description 2
- 230000002123 temporal effect Effects 0.000 description 2
- 238000010521 absorption reaction Methods 0.000 description 1
- 230000015556 catabolic process Effects 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000006731 degradation reaction Methods 0.000 description 1
- 108700041286 delta Proteins 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 239000000284 extract Substances 0.000 description 1
- 239000012464 large buffer Substances 0.000 description 1
- 238000005259 measurement Methods 0.000 description 1
- 230000000116 mitigating effect Effects 0.000 description 1
- 239000012536 storage buffer Substances 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/23406—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving management of server-side video buffer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
- H04N21/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
- H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
- H04N21/234381—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering the temporal resolution, e.g. decreasing the frame rate by frame skipping
-
- 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/258—Client or end-user data management, e.g. managing client capabilities, user preferences or demographics, processing of multiple end-users preferences to derive collaborative data
- H04N21/25808—Management of client data
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
- H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
- H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
- H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/44004—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving video buffer management, e.g. video decoder buffer or video display buffer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
- H04N21/4402—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display
- H04N21/440281—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving reformatting operations of video signals for household redistribution, storage or real-time display by altering the temporal resolution, e.g. by frame skipping
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
- H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
- H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
- H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
- H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
- H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
-
- 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/60—Network 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/63—Control 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/637—Control signals issued by the client directed to the server or network components
- H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
-
- 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/60—Network 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/63—Control 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/637—Control signals issued by the client directed to the server or network components
- H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
-
- 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/60—Network 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/63—Control 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/643—Communication protocols
-
- 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/60—Network 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/65—Transmission of management data between client and server
- H04N21/658—Transmission by the client directed to the server
Landscapes
- Engineering & Computer Science (AREA)
- Multimedia (AREA)
- Signal Processing (AREA)
- Databases & Information Systems (AREA)
- Computer Networks & Wireless Communication (AREA)
- Computer Graphics (AREA)
- Compression Or Coding Systems Of Tv Signals (AREA)
- Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Description
【0001】
【発明の属する技術分野】
本発明は、ストリーミング方法に関し、より特定的には、サーバが端末へインターネットを通じてマルチメディアデータを送信し、かつ端末がそのデータを受信しつつ再生するためのストリーミング方法に関する。
【0002】
【従来の技術】
(マルチメディアデータの符号化圧縮方式およびバッファモデルの説明)
インターネットでの伝送に使用されるマルチメディアデータには、動画、静止画、音声、テキスト、およびそれらが多重化されたデータ等、さまざまな種類がある。動画では、H.263やMPEG1、2、4といった符号化圧縮方式が著名であるし、静止画としてはJPEG、音声では、MPEGオーディオ、G.729など枚挙にいとまがない。
【0003】
本発明では、ストリーミング再生に的を絞っているので、動画および音声が伝伝送の対象となる。ここでは、動画圧縮方式の代表であるMPEGビデオ、中でも比較的仕組みが単純なMPEG1(ISO/IEC 11172)ビデオや、MPEG2(ISO/IEC 13818)ビデオについて説明する。
【0004】
MPEGビデオは、高効率なデータ圧縮を実現するために、主に次の2つの特徴を有している。一つ目は、動画像データの圧縮において、従来から行われていた空間周波数特性を用いた圧縮方式の他に、フレーム間での時間相関特性を用いた圧縮方式を取り入れたことである。MPEGでは、ストリームを構成している各フレーム(ピクチャとも呼ぶ)を、Iフレーム(フレーム内符号化ピクチャ)、Pフレーム(フレーム内符号化と過去からの参照関係を使用したピクチャ)、Bフレーム(フレーム内符号化と過去および未来からの参照関係を使用したピクチャ)の3種類に分類してデータ圧縮を行う。これらの3種では、Iフレームが最も大きく(つまり情報量が最も多く)、次いでP、Bの順である。圧縮アルゴリズムにも大きく依存するが、情報量の比は、おおよそI:P:B=4:2:1程度となる。また一般的に、MPEGビデオストリームは、15フレーム(=1GOP)を単位として、1GOPについてIフレームが1枚、Pフレームが4枚、Bフレームが10枚の割合で含まれている。
【0005】
MPEGビデオの二つ目の特徴は、画像の複雑さに応じた動的な符号量割り当てをピクチャ単位で行える点である。MPEGのデコーダは、デコーダバッファを備え、このデコーダバッファにデータを蓄積してからデコードを行うことで、圧縮の難しい複雑な画像に対して大量の符号量を割り当てることが可能になっている。MPEGに限らず動画圧縮では、標準的なデコーダバッファの容量を規格で定義する場合が殆どである。MPEG1やMPEG2の場合、標準デコーダバッファは、規格で容量が224KByteと定義されており、MPEGエンコーダは、この容量の範囲内でデコーダバッファ占有量が遷移するようにピクチャデータを生成しなければならない。
【0006】
図19(A)〜(C)は、従来のストリーミング方法を説明するための図である。図19(A)は、ビデオフレームを示す図、図19(B)は、バッファ占有量の遷移を模式的に示した図、図19(C)は、従来端末の構成例を示す図である。図19(C)において、端末は、ビデオバッファと、ビデオデコーダと、I,P並べ替えバッファと、スイッチとを備えている。ビデオバッファが、前述のデコーダバッファに相当し、転送されてくるデータは、ビデオバッファに蓄積された後、ビデオデコーダによってデコードされる。デコードされたデータは、I,P並べ替えバッファおよびスイッチを通じて再生時刻順に並べ替えられる。
【0007】
図19(B)において、縦軸はバッファ占有量(ビデオバッファのデータ蓄積量)を、横軸は時間を示し、図中の太線がバッファ占有量の時間的遷移を示している。また、太線の傾きは、ビデオのビットレートに相当し、一定のレートでデータがバッファに入力されていることを示している。また、一定間隔(33.3667msec)でバッファ占有量の削減が起こっているが、これは、一定周期で各フレームのデータがデコードされていくことによる。また、斜め点線と時間軸との交点は、各ビデオフレーム内のデータがビデオバッファへ向けて転送開始される時刻を示している。従って、図19(A)に示されたフレームXの転送開始時刻はt1、フレームYの転送開始時刻はt2となる。
【0008】
図19(A),(B)において、ビデオの先頭フレームXがビデオバッファに入力開始される時刻t1から、最初にデコードが実行される時刻(図中、太線の第1の立ち下がり位置)までの時間を一般に、vbv_delay時間と呼ぶ。最初のデコードは、ビデオバッファが満杯になった瞬間に実行されるので、vbv_delay時間は、通常、データ入力開始から容量224KByteのビデオバッファが満杯になるまでの時間であり、従って、ビデオの入力が開始されてから、デコーダを通じてビデオ再生が開始されるまでの初期遅延時間(頭出し時の待ち時間)ということになる。
【0009】
図19(A)のフレームYが複雑な画像である場合、図19(B)に示されているように、その符号量が大量なので、フレームYのデコード時刻(図中のt3)よりも早い時刻(図中のt2)から、ビデオバッファへのデータ転送を開始しなければならない。ただし、どんなに複雑な画像でも、バッファを占有するピクチャ量は、224KByteの許容範囲内である。
【0010】
図19(B)に示したバッファ遷移がきちんと保たれるようにビデオバッファにデータが転送されるならば、ビデオバッファのアンダーフローやオーバーフローによるストリーミング破綻が起こらないことは、MPEGの規格で保証されている。
【0011】
(ネットワーク転送ジッタ吸収用の受信バッファの説明)
ところが、図20に示すように、サーバ201と端末202とをネットワーク203で接続し、ストレージ210中のMPEGデータを配信する場合、生成モジュール211でパケットを生成する時間や、ネットワーク機器204,205における転送手続き時間、ネットワーク203の混雑などに伴なう伝送遅延時間などのために、データの転送レートに揺れが生じる。従って、実際には、図19(B)に示したバッファ遷移が保たれないのが実情である。このような転送レートの揺れ(ジッタ)を緩和吸収する方法としては、まず、ネットワークの帯域に比べ十分小さい符号化レートのコンテンツを流すことが考えられる。しかし、ネットワーク資源をできる限り有効に使って高品位な映像や音声を提供する必要があるので、この方法は適切ではない。そこで、一般には、ネットワーク機器204,205に、それぞれ適当な容量の送受信バッファ206,207を設け、普段からデータを多少先送り気味に転送しておいて、データ転送に遅延が発生した時の不足を補う方法が採用される。
【0012】
ここで、端末202側に受信バッファ207を設けるということは、結局、図19(B)のバッファ遷移において、バッファ占有量の上限を、デコーダバッファ208の規格である224KByteから受信バッファ207による蓄積量の分だけかさ上げするのとおおむね等価である。図21(A),(B)に、受信バッファ297を追加する前後のバッファ占有量を並べて示す。なお、図21(A)に示されているのは、図19(B)と同一のバッファ遷移である。
【0013】
受信バッファ207の追加によって、バッファ遷移の許容範囲が拡がり、その結果、図19(B)のバッファ遷移、すなわち図21(A)のバッファ遷移は、図21(B)のようになって、ネットワークの転送レートが低下しても、アンダーフローを回避することが可能となる。反面、vbv_delay時間が、受信バッファ207による蓄積量に相当する時間だけ長くなり、デコーダ209でのデコード開始および再生装置212での再生開始が遅れる。つまり、頭出し時間が、受信バッファ207へのデータ蓄積にかかる時間の分だけ長くなる。
【0014】
【発明が解決しようとする課題】
以上から明らかなように、小規模LANなどの信頼性や伝送速度の保証されたネットワーク環境において、MPEG等のマルチメディアデータをストリーミング再生する場合には、基本的に、コーデックの規格で定められた再生初期遅延時間(vbv_delay)やデコーダバッファ遷移をきちんと遵守するようなシステム設計になってさえいれば、デコーダバッファのアンダーフローやオーバーフローが起こってストリーミング再生が破綻をきたすことはない。
【0015】
しかしながら、インターネットなどの広域ネットワーク環境においては、通信経路の伝送特性変動に伴なう転送ジッタが無視できないほど大きいため、従来の端末202は、コーデックの規格で定められたデコーダバッファ(vbvバッファ)に加えて、図20の受信バッファ207のような、転送ジッタ吸収のためのバッファを持つ場合が多い。このとき、次のような課題が存在する。
【0016】
端末に搭載されるジッタ吸収用のバッファの容量は、一般に、機種によって様々である。そのため、同じデータを同じ条件下で配信しても、バッファ容量の多い機種ではストリーミング再生を破綻なく行えるが、少ない機種では、ジッタを吸収しきれずに破綻する場合があった。
【0017】
この課題を解決するには、例えば、端末の搭載メモリ量を増やして、ジッタ吸収用のバッファ容量を十分確保すればよい。しかしながら、搭載メモリ量は、端末の価格を決める主な要因の一つであり、可能な限り少なく抑えたい要求がある。加えて、ジッタ吸収用のバッファ容量が多すぎると、再生開始までの頭出し時間が長くなって、ユーザにいらだちを感じさせてしまうという新たな問題が発生する。
【0018】
それゆえに、本発明の目的は、端末のバッファ容量が機種によって異なっていても、ネットワークの伝送能力が変動しても、バッファのアンダーフローやオーバーフローによるストリーミング再生の破綻を回避することが可能であり、しかも、ストリーミング再生の破綻回避と、頭出し時の待ち時間短縮とを互いに両立させることができるようなストリーミング方法を提供することである。
【0019】
【課題を解決するための手段および発明の効果】
第1の発明は、サーバが端末へネットワークを通じてストリームデータを送信し、かつ端末が当該ストリームデータを受信しつつ再生するストリーミング方法であって、
端末が、自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定ステップ、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、端末が、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定ステップ、
決定した目標時間および遅延時間を、端末がサーバに通知するステップ、
サーバが端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御ステップを備える。
【0020】
上記第1の発明では、端末が、自身のバッファ容量とネットワークの伝送能力とに応じた目標量を決定し、さらに、バッファ容量を伝送能力で除して得られる値を超えない範囲内で、遅延時間を決定する。サーバは、こうして端末が決定した目標量および遅延時間に基づいて送信速度を制御するので、端末のバッファ容量が機種によって異なっていても、ネットワークの伝送能力が変動しても、バッファ量および伝送能力に応じた送信速度制御が行え、その結果、バッファのアンダーフローやオーバーフローによるストリーミング再生の破綻を回避することが可能となる。しかも、目標量とは独立に遅延時間が決定されるので、ストリーミング再生の破綻回避と、頭出し時の待ち時間短縮とを互いに両立させることができる。
【0021】
ここで、遅延時間が、バッファ容量を伝送能力で除して得られる値以下に制限されるのは、遅延時間がこの値を超えると、ストリーミング再生の破綻が起こる恐れがあるためである。この値を超えない範囲であれば、遅延時間をどのような値に決めてもよい。ただし、値を決める際には、伝送能力の変動に対する耐性と、頭出し時の待ち時間との間のバランスが考慮される。
【0022】
第2の発明は、第1の発明において、
制御ステップにおいて、サーバは、
端末のバッファに蓄積されているストリームデータの量が、当該目標量の近傍において当該目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする。
【0023】
上記第2の発明では、蓄積量が目標量の近傍において目標量を超えることなく遷移するので、バッファのアンダーフローやオーバーフローが起こりにくい。
【0024】
第3の発明は、第2の発明において、
制御ステップにおいて、サーバは、当該送信速度と、当該遅延時間と、端末がストリームデータをデコードする速度とに基づいて、端末のバッファに蓄積されるストリームデータの量を予測算出することを特徴とする。
【0025】
上記第3の発明では、サーバが蓄積量を予測算出して、その量に基づいて送信速度制御を行うので、蓄積量を目標量の近傍で目標量を超えないように遷移させることができる。
【0026】
ここで、端末が現在の蓄積量をサーバに通知し、サーバは、通知に基づいて送信速度制御を行ってもよい。しかし、この場合、端末からサーバへの情報伝達に時間がかかるので、サーバは、過去の蓄積量に基づいて送信速度制御を行うことになる。そのため、蓄積量を目標量の近傍で目標量を超えないように遷移させることができるとは限らない。
【0027】
第4の発明は、第1の発明において、
端末が、ネットワークの伝送能力が所定の閾値を跨いで変化したことを検出する検出ステップ、
検出ステップでの検出結果に応じて、端末が当該目標量を変更する目標量変更ステップ、および
変更後の目標量を、端末がサーバに通知するステップをさらに備え、
制御ステップにおいて、サーバは、変更後の目標量の通知を受けると、端末のバッファに蓄積されるストリームデータの量が、当該変更後の目標量の近傍において当該変更後の目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする。
【0028】
上記第4の発明では、伝送能力が閾値を跨いで変化すると、端末によって目標量が変更される。サーバは、変更後の目標量の近傍において変更後の目標量を超えることなく遷移するように送信速度を制御して、目標量の変更に追従する。
【0029】
第5の発明は、第4の発明において、
検出ステップでネットワークの伝送能力が第1の閾値を跨いで低下したことを検出すると、端末は、目標量変更ステップにおいて、当該目標量を増加させる向きに変更し、
制御ステップにおいて、サーバは、当該目標量が増加されたのに応じて、当該送信速度を上昇させる向きに制御することを特徴とする。
【0030】
上記第5の発明では、伝送能力が第1の閾値を跨いで変化すると、端末によって目標量が増加される。サーバは、送信速度を上昇させることにより、目標量の増加に追従する。
【0031】
第6の発明は、第5の発明において、
当該第1の閾値は、実現可能な最大の伝送能力と、ストリームデータの転送ロスが発生し始めるような伝送能力との略中間の値であることを特徴とする。
【0032】
上記第6の発明では、伝送能力が低下しつつあるとき、ストリームデータの転送ロスが発生し始める前に、送信速度を上昇させて蓄積量を増やしておく。これにより、伝送能力の低下が進行したときに、ストリーミング再生が破綻するのを防ぐことができる。
【0033】
第7の発明は、第4の発明において、
検出ステップでネットワークの伝送能力が当該第1の閾値より小さい第2の閾値を跨いで低下したことを検出すると、端末は、目標量変更ステップにおいて、当該目標量を減少させる向きに変更し、
制御ステップにおいて、サーバは、当該目標量が減少方向に変更されたのに応じて、当該送信速度を低下させる向きに制御することを特徴とする。
【0034】
上記第7の発明では、伝送能力が第2の閾値を跨いで変化すると、端末によって目標量が減少される。サーバは、送信速度を低下させることにより、目標量の減少に追従する。
【0035】
第8の発明は、第7の発明において、
当該第2の閾値は、ストリームデータの転送ロスが発生し始めるような伝送能力と対応する値であることを特徴とする。
【0036】
上記第8の発明では、伝送能力の低下が進行して、ストリームデータの転送ロスが発生し始めると、一転、送信速度を低下させる。失われたデータの再送処理を妨害しないためである。
【0037】
ここで、送信速度を低下させる場合、サーバは、低下幅に応じた頻度でフレームの送信をスキップしなければならない。フレームがスキップされると、端末が再生して得られる映像や音声の品位劣化が起こる。この品位劣化を抑えるために、下記第9の発明では、スキップされるフレームとして、再生時刻に間に合わないフレームが選択される。下記第10の発明では、スキップされるフレームとして、重要度の低いフレームと、重要度は高いが再生時刻に間に合わないようなフレームとが選択される。
【0038】
第9の発明は、第8の発明において、
目標量変更ステップにおいて、端末が当該目標量を減少させる向きに変更すると、制御ステップにおいて、サーバは、送信しようとするストリームを構成する各フレームの再生時刻を現在時刻と逐次比較して、再生時刻が現在時刻よりも古いフレームの送信をスキップし、それよって当該送信速度を低下方向に制御することを特徴とする。
【0039】
上記第11の発明では、再生時刻に間に合わないフレームが選択的にスキップされるので、無作為的にスキップするのと比べて、送信速度の低下による品位劣化を少なく抑えることができる。
【0040】
第10の発明は、第8の発明において、
目標量変更ステップにおいて、端末が当該目標量を減少させる向きに変更すると、制御ステップにおいて、サーバは、送信しようとするストリームを構成する各フレームの重要度を基準値と逐次比較して、
重要度が基準値未満であるフレームについては、全て送信をスキップし、
重要度が基準値以上であるフレームについては、それぞれの再生時刻を現在時刻と逐次比較して、再生時刻が現在時刻よりも古いものだけ送信をスキップし、それによって当該送信速度を低下方向に制御することを特徴とする。
【0041】
上記第10の発明では、重要度の低いフレームと、重要度は高いが再生時刻に間に合わないようなフレームとが選択的にスキップされるので、無作為的にスキップするのと比べて、送信速度の低下による品位劣化を少なく抑えることができる。
【0042】
ここで、第10の発明のような、スキップすべきフレームを選択する際に再生時刻に間に合うか否かに加えて重要度をも考慮する方法は、典型的には、MPEGによる映像フレームに対して用いられる。この場合、送信速度を低下させるとき、PやBのフレームが重要度の低いフレームとしてスキップされる一方、Iフレームは、重要度の高いフレームとして、再生時刻に間に合わない場合を除いてスキップされることがないので、送信速度低下による再生画像の品位劣化が最小限に抑えられる。なお、MPEGによる音声フレームの場合、フレーム間に重要度の違いがないので、再生時刻に間に合うか否かだけを考慮すればよい。
【0043】
第11の発明は、ネットワークを通じてストリームデータを送信するサーバと、当該ストリームデータを受信しつつ再生する端末とからなるシステムであって、
端末は、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段を備え、
サーバは、端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段を備える。
【0044】
第12の発明は、ネットワークを通じてストリームデータを送信するサーバと共に用いられ、当該ストリームデータを受信しつつ再生する端末であって、
サーバには、端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段が備わり、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段を備える。
【0045】
第13の発明は、ストリームデータを受信しつつ再生する端末と共に用いられ、ネットワークを通じて当該ストリームデータを送信するサーバであって、
端末には、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段が備わり、
端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段を備え、
制御手段は、端末のバッファに蓄積されているストリームデータの量が、当該目標量の近傍において当該目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする。
【0046】
第14の発明は、上記第1の発明のようなストリーミング方法を記述したプログラムである。
【0047】
第15の発明は、上記第14の発明のようなプログラムを記録した記録媒体である。
【0048】
【発明の実施の形態】
以下、本発明の実施形態について、図面を参照しながら説明する。図1は、本発明の一実施形態に係るストリーミング方法を実行するサーバ・クライアント・システムの構成例を示すブロック図である。図1において、本システムは、サーバ101と、そのクライアントとして動作する端末102とを備えている。サーバ101側には、映像や音声のデータが蓄積されている。このデータは、MPEGによって符号化圧縮されたデータである。サーバ101は、端末102からの要求に応じ、蓄積しているデータをパケット化してストリームを生成する。そして、ネットワーク103を通じ、生成したストリームを端末102に送信する。端末102は、サーバ101から送信されるストリームを受信してデコードし、得られた映像や音声を表示出力する。
【0049】
図2は、図1のサーバ101の構成を示すブロック図である。図2において、サーバ101は、蓄積デバイス411と、送受信モジュール402と、生成モジュール405と、RAM404と、CPU412と、ROM413とを備えている。蓄積デバイス411には、映像や音声のデータが蓄積されている。この蓄積デバイス411内のデータが生成モジュール405に与えられる。生成モジュール405は、読み出しバッファ407と、パケット生成回路406と、パケット生成バッファ408とを含み、与えられるデータをパケット化してストリームを生成する。
【0050】
送受信モジュール402は、ネットワークコントローラ410と、送信バッファ409とを含み、生成モジュール405によって生成されたストリームを端末102へ、ネットワーク103経由で送信する。また、端末102からネットワーク103経由で送信されてくる情報を受信する。
【0051】
送受信モジュール402によって受信された端末102からの情報は、RAM404に書き込まれる。ROM413には、サーバ制御プログラムが格納されており、CPU412は、RAM404に記憶されている端末からの情報を参照しつつROM413内のプログラムを実行し、それによって、送受信モジュール402および生成モジュール405の制御を行う。なお、ここではプログラムがROM413に格納されているとしたが、ROM以外の記憶媒体、例えばハードディスクやCD−ROM等に格納されていてもよい。
【0052】
図3は、図1の端末102の構成を示すブロック図である。図3において、端末102は、送受信モジュール507と、再生モジュール510と、表示デバイス511と、ROM502と、CPU503とを備えている。送受信モジュール507は、ネットワークコントローラ506と、受信バッファ505とを含み、サーバ101からネットワーク103経由で送信されてくるストリームを受信する。また、CPU503からの情報をサーバ101へ、ネットワーク103経由で送信する。
【0053】
送受信モジュール507によって受信されたストリームが、再生モジュール510に入力される。再生モジュール510は、デコーダバッファ508と、デコーダ509とを含み、入力されるストリームをデコードして再生する。再生モジュール510により再生されたデータが表示デバイス511に与えられ、表示デバイス511は、そのデータを映像に変換して表示する。
【0054】
ROM502には、端末制御プログラムが格納されており、CPU503は、ROM502内のプログラムを実行し、それによって、送受信モジュール507、再生モジュール510および表示デバイス511の制御を行う。
【0055】
以上のように構成されたシステムの動作を、以下に説明する。図4は、図1のシステムの全体動作を説明するためのシーケンス図である。図4には、サーバ101側の送受信層および制御層と、端末102側の送受信層および制御層とが示されており、これら各層の間でやりとりされるコマンドやストリームが時系列的に並べられている。
【0056】
最初、本システムの全体的な動作について、図4を用いて説明する。図4において、最初、端末102からサーバ101へ、コマンド”SETUP”が送信される。サーバ101では、”SETUP”に応じて初期設定が行われ、設定が完了すると、サーバ101から端末102へ、”OK”が応答される。
【0057】
サーバ101から”OK”が返ってくると、端末102からサーバ101へ、コマンド”PLAY”が送信される。サーバ101では、送信準備が行われ、準備が完了すると、サーバ101から端末102へ、”OK”が応答される。
【0058】
サーバ101から”OK”が返ってくると、端末102は、ストリームを待ち受ける態勢へと移行する。この”OK”の応答に引き続いて、サーバ101は、ストリームの送信を開始する。
【0059】
その後、端末102からサーバ101へ、コマンド”TEARDOWN”が送信され、サーバ101は、”TEARDOWN”に応じてストリーム送信を終了する。送信が終了されると、サーバ101から端末102へ、”OK”が応答される。
サーバ101から”OK”が返ってくると、端末102は、ストリーム待ち受け態勢から脱する。
【0060】
以上が本システムの全体的な動作の概要であり、上で説明した限りでは、本システムの動作は、従来と同様である。本システムの動作が従来と異なるのは、次の(1)および(2)の2点である。
(1)端末102からサーバ101へのコマンド”SETUP”にパラメータ”S_target”および”T_delay”が添付されており、サーバ101は、ストリームを送信する際、これらのパラメータに基づいて送信速度を制御する。
【0061】
上記(1)において、”S_target”は、端末102がバッファに蓄積するデータ量の目標値であり、その端末102に備わるバッファ(図3の例では、受信バッファ505およびデコーダバッファ508)の総容量(”S_max”)と、ネットワーク103の伝送能力とに基づいて決定される。従って、”S_target”は、一般に、端末102の機種によって値が異なる。
【0062】
また、”T_delay”は、端末102が先頭データをバッファに書き込んでから、そのデータを読み出してデコードを開始するまでの時間(つまり頭出し遅延時間)であり、”S_target”を送信速度(後述)で除して得られる値を最大値として、その最大値を超えない範囲内で任意の値に決定される。すなわち、「”S_target”を送信速度で除して得られる値を超えない範囲内で」という条件が付くものの、端末102は、”S_target”とは独立に”T_delay”を決めることができる。
【0063】
また、「送信速度」は、単位時間に送信する情報の量をいい、例えば、単位時間に送信するパケットの個数が決められている場合、各パケットに詰め込むデータの量を増減させることによって、送信速度を制御することができる。また、各パケットに詰め込むデータの量が決められている場合、パケットと次のパケットとの時間的な間隔を伸縮させることによって、送信速度を制御することができる。あるいは、両方を同時に行う(すなわち、各パケットに詰め込むデータの量を増減させ、かつパケットと次のパケットとの時間的な間隔を伸縮させる)ことによっても、送信速度を制御することができる。本実施形態では、各パケットに詰め込むデータの量を増減させることにより速度制御を行うものとする。
【0064】
(2)端末102は、ストリームの配信中、必要に応じて”S_target”を変更することができる。この場合、変更後の”S_target”が端末102からサーバ101に通知され、以降、サーバ101は、変更後の”S_target”に基づいて送信速度を制御する。
【0065】
上記(2)において、”S_target”の変更は、ネットワーク103の伝送能力の変動に応じて行われる。具体的には、端末102が携帯電話の場合、電界強度(例えば「強・中・弱・圏外」の4段階の強度)を検知することができるので、この電界強度の変化を「ネットワーク103の伝送能力の変動」と見なして、”S_target”を変化させる。例えば、電界強度が「強」から「中」に変化すると、端末102は、”S_target”の値をより大きな値に変更し、「中」から「弱」に変化すると、”S_target”の値をより小さな値に変更する。
本システムの動作が従来と異なるのは、主として上の2点である。
【0066】
次に、本システムの全体動作の具体例を詳細に説明する。図4において、端末102は、ストリーム再生を開始するのに先立ち、端末制御プログラムに従ってCPU503がROM502より端末に固有のパラメータ群を抽出する。このパラメータ群中には、受信バッファ505とデコーダバッファ508とを合わせた総容量(端末102が実際に蓄積できる最大データ量)S_maxが含まれる。一方、CPU503は、ストリーム再生補助データなどの事前入手の手続きによって、受信したいストリームデータの符号化圧縮レートVrや、ビデオないしオーディオのフレーム発生周期Tfrmを知っているものとする。また、CPU503は、ネットワークインターフェースを通じ、ネットワーク103の伝送能力、たとえば携帯電話における受信電波強度や、通信速度(PHSの場合では64Kbps接続ないし32Kbps接続などの情報)も検出しているものとする。
【0067】
CPU503は、これらS_max、Vr、Tfrm、ネットワーク103の伝送能力(例えば有効転送速度=networkRate)などをもとに、端末102内のバッファにどれだけのデータを蓄積するかを示す目標量S_target、およびストリーム再生を始めるまでのプレバッファリング時間(すなわち頭出し遅延時間)T_delayを決定する。
【0068】
ここで、S_targetの本質的な意味は、今から開始するストリーミング再生において、S_target近傍かつそれを越えないように端末の蓄積バッファ量が遷移すれば、途切れなく正常にストリーミング再生が持続できるような基準値のことである。前述のように、T_delayが大きいと頭出し遅延時間が長くなるが、ネットワーク103の転送ジッタに対しては強くなる。しかし、遅延時間があまり長いとサービス仕様として不適切なので、T_delayを決める際には、転送ジッタに対する耐性と、頭出し時の待ち時間との間のバランスをとる配慮が必要である。
【0069】
なお、T_delayの代わり、もしくはT_delayと併せて、端末102内のバッファにデータを何バイトまで充填したらデコードを開始するかという充填量S_delayを決定してもよい。端末102がS_delayのみを決定してサーバ101に通知する場合は、サーバ101側でT_delay=S_delay/networkRateなる式を用いて、S_delayをT_delayに換算することが可能である。また、S_delayの値は、バッファ総量S_maxに対する充填率rS(%)であってもよい(この場合、換算式は、S_delay=S_max*rS/100となる)。
【0070】
端末102は、S_targetと、T_delay(および/またはS_delay)とを準備すると、図4に示されているように、サーバ101に対し、ストリーム配信の準備を促すSETUPコマンドを発行する。SETUPコマンド中には、引数としてS_targetと、T_delay(および/またはS_delay)とが含まれている。サーバ101は、SETUPを受信すると、引数をRAM404に記憶して、ストリーム配信のための初期設定を行う。具体的には、サーバ101のCPU412が、最初RAM404から引数を取り出し、次いで、たとえばストリームのソースファイルを蓄積デバイス411から読み出してバッファ407に書き込む操作と、読み出したデータをパケット化するパケット生成回路406のパラメータ設定とを行う。なお、パケット生成回路406は、必ずしも専用のハードウエアである必要はなく、サーバ101(例えばワークステーションなどで実現される)のCPU412に同様のパケット化処理を実行させるプログラム(ソフトウエアアルゴリズム)であってもよい。
【0071】
前述のS_targetと、T_delay(および/またはS_delay)との2つの値も、パケット生成回路406に引き渡される。パケット生成回路406では、これらの値を用いて最適なレート制御パラメータの算出が行われ、その結果、端末102へのストリーム配信に適したレートでパケットが生成、送出されるようになる。ネットワーク103中にパケットを送出する準備が正常に完了すると、図4のように、送受信層から制御層にOKが返り、次いで、端末102へ向けてSETUPコマンドに対するOKが返る。こうして、本システムにおいて、ストリーム配信準備が完了する。
【0072】
次いで、端末102がサーバ101に対し、ストリーム配信の開始を促すPLAYコマンドを発行する。サーバ101は、PLAYを受信すると、ストリームデータの配信を開始する。端末102は、サーバ101からのストリームデータを受信して蓄積する。そして、蓄積開始から前述のプレバッファリング時間(T_delay)が経過したのちに、ストリームデータのデコード、再生を開始する。このときストリーム配信は、SETUP時に設定された適切なレート制御パラメータに基づいてなされていることはいうまでもない。
【0073】
ストリーム再生の終了時には、端末102よりサーバ101に対し、TEARDOWNコマンドが発行される。サーバ101は、TEARDOWNを受信すると、ストリーム配信の終了処理を行い、全手続きを完了させる。以上が、本システムの具体的な動作例である。
【0074】
以下には、端末102の動作について詳細に説明する。端末102は、インターネットに接続可能な携帯電話であり、電界強度(受信電波強度)を検知する機能を持っているとする。図5は、図1の端末102の動作を示すフローチャートである。図5において、最初、端末102は、2つのパラメータS_targetおよびT_delayの値を決定する(ステップS101)。
【0075】
ここで、上記ステップS101の処理内容を具体的に説明する。図6は、図3のROM502の記憶内容を示す図である。図6に示すように、ROM502内には、端末制御プログラムと、電界強度およびS_targetが互いに対応付けて記載されたテーブル601と、パラメータT_delayの値とが記憶される。パラメータS_targetの値としては、電界強度「強」と対応するS_target1、「中」と対応するS_target2、「弱/圏外」と対応するS_target3の3つの値が記憶されている。一方、パラメータT_delayの値は、1つだけが記憶されている。
【0076】
上記3つの値S_target1〜3は、次の関係を満たすように決められる。
S_target3<S_target1<S_target2≦S_max一方、値T_delayは、値S_maxをネットワーク103の実効的な伝送能力で除して得られる値を超えないように決められる。
【0077】
一例として、S_maxが512(KB)であれば、S_target1=256(KB),S_target2=384(KB),S_target3=128(KB)などのように決められる。また、ネットワーク103の実効的な伝送能力を384(Kbps)すなわち48(KB/sec)とすると、T_delayは、512÷48≒10.7(秒)を超えない範囲で、任意の値(例えば4秒や3秒など)に決定される。
【0078】
上記ステップS101では、ROM502から、初期値としてのS_target1と、値T_delayとが読み出される。
【0079】
なお、ここでは、S_target1〜3と、T_delayの値とが予め計算されてROM502に記憶されており、CPU503は、必要な値をROM502から読み出すようにしているが、代わりに、バッファの総容量と、ネットワーク103の実効的な伝送能力と、S_targetおよびT_delayの値を計算するためのプログラムとをROM502に記憶しておいてもよい。この場合、CPU503は、必要があれば、その都度、ROM502から容量、速度およびプログラムを読み出して、S_targetおよびT_delayの値を計算する。また、ここでは、T_delayの値が1つだけであるが、複数の値を準備しておいて、その中から選択してもよい。以上がステップS101の処理内容である。
【0080】
再び図5において、端末102は、ステップS101で決定されたS_targetおよびT_delayをSETUPコマンドに添付して、サーバ101へ向けて送信する(ステップS102)。応じて、サーバ101からストリームが送られてくる。ストリーム送信の際、サーバ101は、端末から通知されたS_targetおよびT_delayに基づく送信速度制御を実行する(サーバ側の動作ついては後述)。
【0081】
次に、端末102は、サーバ101から送られてくるストリームを受信して、バッファに書き込む動作を開始する(ステップS103)。具体的には、図3に示されているように、ネットワーク103を通じて送られてくるストリームは、まずネットワークコントローラ506を経由して受信バッファ505に書き込まれる。時間が経過して受信バッファ505が満杯になると、受信バッファ505内のストリームが先頭データから順番に読み出されて、デコーダバッファ508へと書き込まれていく。
【0082】
次に、端末102は、バッファリング開始から時間がT_delayだけ経過したか否かを判定し(ステップS104)、その判定結果が否定であれば、肯定となるまで待機する。ステップS104の判定結果が肯定となると、端末102は、バッファからストリームを読み出してデコード・再生する動作を開始する(ステップS105)。具体的には、図3において、CPU503がバッファリング開始からの経過時間を計測しており、その計測結果がROM502内のT_delayと一致した瞬間、再生モジュール510に命じて、デコーダバッファ508内のストリームを先頭データから順番に読み出してデコーダ509に入力する処理を開始させる。
【0083】
次に、端末102は、ネットワーク103の伝送能力が閾値を跨いで変化したか否かを判定する(ステップS106)。この判定は、具体的には、次のようにして行われる。例えば、ネットワーク103を管理するホストコンピュータ(図示せず)が、ネットワーク103の伝送能力に関する情報をネットワーク103経由で端末102に随時配信するようにし、端末102は、ホストコンピュータからの情報をもとに変化の有無を判定する。
【0084】
この場合、具体的には、図3に示すように、伝送能力に関する情報が送受信モジュール507を通じてCPU503へと送られる。ROM502には、予め閾値が格納されており、CPU503は、送られてきた情報と、保持している前回の情報と、ROM502内の閾値とを互いに比較することにより、伝送能力が閾値を跨いで変化したか否かを判定することができる。
【0085】
または、ネットワーク103を管理するホストコンピュータがその伝送能力に関する情報を端末102に配信する機能を持たない場合、端末102は、例えば、次のようにして自ら判定を行うことができる。すなわち、端末102が携帯電話の場合、図7(後述)に示すように、周囲の電界強度を検知して、検知結果を「強・中・弱・圏外」のように表示する機能を持っている。この電界強度の変化をネットワーク103の伝送能力の変化と見なせば、端末102は、検出を簡単に行えることになる。
【0086】
ステップS106の判定結果が肯定の場合、端末102は、新たなS_targetを決定し(ステップS107)、それをサーバ101へ向けて送信する(ステップS108)。一方、ステップS106の判定結果が否定の場合、ステップS107,S108をスキップして、ステップS109(後述)を実行する。
【0087】
ここで、上記ステップS106およびステップS107の処理内容について、詳しく説明する。以下では、端末102が携帯電話であり、電界強度の変化に応じてS_targetを変更する場合を説明する。図7は、あるエリアにおける電界強度の分布と、端末の移動に伴う伝送能力の変化とを示す模式図である。図7(A)には、3つの中継局B1〜B3を含むエリアにおける電界強度分布が示されている。図7(A)において、各中継局B1〜B3を中心とする同心円が、互いに等しい電界強度の点を繋いでできる等電界曲線である。
【0088】
例えば、中継局に最も近い同心円703内では、電界強度が「強」であり、この同心円703から次の同心円704までの間の領域では「中」となる。さらに、同心円704から同心円705までの間では「弱」、同心円705の外側の領域では「圏外」となる。ただし、各中継局を中心とする同心円は、一部が互いに交差しており、電界強度が「圏外」となる領域は、わずかしかない。
【0089】
いま、端末102は、矢印702で示される経路に沿って、中継局B1の近傍から中継B2の近傍へ移動しようとしている。図7(B)には、図7(A)の矢印702に沿った電界強度(これをネットワーク103の伝送能力と見なすことができる)が示されている。図7(B)に示されているように、電界強度は、端末102が中継局の近傍にあるとき「強」であり、中継局B1から離れるにつれて「中」、「弱」、「圏外」のようにだんだん弱くなっていく。そして、中継局B1の「圏外」となった直後、端末102は、中継局B2の「圏内」に入り、電波強度が「弱」、「中」、「強」のようにだんだん強くなっていく。
【0090】
上記のように移動する端末102は、電界強度が「強」から「中」へと変化した瞬間、ネットワーク103の伝送能力が閾値Aを跨いで変化したと判定して、新たなS_targetを決定し、「中」から「弱」へと変化した瞬間、伝送能力が閾値Bを跨いで変化したと判定して、新たなS_targetを決定する。逆に、「弱」から「中」へと変化した瞬間、伝送能力が閾値Bを跨いで変化したと判定して、新たなS_targetを決定し、「中」から「強」へと変化した瞬間、伝送能力が閾値Aを跨いで変化したと判定して、新たなS_targetを決定する。
【0091】
なお、一般的には、閾値Aは、ネットワーク103において実現可能な最大の伝送能力と、ストリームの転送ロスが発生し始めるような伝送能力との略中間の値である。閾値Bは、ストリームの転送ロスが発生し始めるような伝送能力と対応する値である。
【0092】
新たなS_targetは、ROM502内のテーブル601(図6)を参照することにより、次のように決定される。図8は、図5のステップS107の詳細を示すフローチャートである。図8において、端末102は、最初、変化後の電界強度が「強」か否かを判定し(ステップS201)、判定結果が肯定であれば、新たなS_targetをS_target1に決定する(ステップS202)。ステップS201の判定結果が否定あれば、ステップS202をジャンプして、ステップS203に進む。
【0093】
次に、端末102は、変化後の電界強度が「中」か否かを判定し(ステップS203)、判定結果が肯定であれば、新たなS_targetをS_target2に決定する(ステップS204)。ステップS203の判定結果が否定であれば、ステップS204をジャンプして、ステップS205に進む。
【0094】
次に、端末102は、変化後の電界強度が「弱/圏外」か否かを判定し(ステップS205)、判定結果が肯定であれば、新たなS_targetをS_target3に決定し(ステップS206)、その後、図5のフローに戻る。ステップS205の判定結果が否定であれば、ステップS206をジャンプして、図5のフローに戻る。
【0095】
従って、図7(A)の矢印702に沿って端末102が移動して行く場合、電界強度の変化に伴って、端末102は、パラメータS_targetの値を、S_target1→S_target2→S_target3→S_target2→S_target1のように変化させる。具体例を挙げれば、256(KB)→384(KB)→128(KB)→384(KB)→128(KB)のように変化させる。以上が、ステップS106およびステップS107の具体的な処理例である。
【0096】
再び図5において、ステップS108で端末102が新たなS_targetをサーバ101へ向けて送信すると、それに応じて、サーバ101は、パラメータS_targetの値を、端末102から新たに通知された値に変更して、送信速度制御を続行する。
【0097】
次に、端末102は、ストリーミング再生を終了するか否かを判断し(ステップS109)、終了する場合は、サーバ101へコマンドTEARDOWNを送信すると共に、ストリームの受信およびバッファリングを停止し(ステップS110)、次いで、再生処理を停止する(ステップS111)。一方、ストリーミング再生を継続する場合には、端末102は、ステップS106に戻って、上記と同様の処理を繰り返す。以上が、端末102の動作である。
【0098】
次に、サーバ101の動作について詳細に説明する。なお、ここでは説明を簡単にするために、サーバ101は、MPEG1ビデオ(ISO/IEC 11172−2)、MPEG2ビデオ(ISO/IEC 13818−2)、あるいはMPEG2−AACオーディオ(ISO/IEC 13818−7)のような、固定周期Tfrmでフレームを発生させる符号化圧縮アルゴリズムを用いて符号化を行い、かつ、固定周期Tsで符号化データのパケット化を行うものとする。
このパケット化は、フレーム単位で行われるものとする。
【0099】
最初、サーバ101が行うストリーム送信速度制御の概要について、図9〜図11を用いて説明する。図9〜図11は、サーバ101が行うストリーム送信速度制御によって、端末102のバッファに蓄積されているデータ量(バッファ占有量)がどのように遷移するかを示す図である。サーバ101は、送信先の端末102において、バッファ占有量が図9〜図11に示されているごとく遷移するように、ストリームの送信速度を制御する。
【0100】
図9には、バッファ占有量がS_targetに近づいていく様子が示されている。図10には、バッファ占有量がS_targetの近傍で遷移している状態で、S_targetの値がより大きな値(S_target2)に変更された場合に、バッファ占有量がS_target2に近づいていく様子が示されている。図11には、バッファ占有量がS_targetの近傍で遷移している状態で、S_targetの値がより小さな値(S_target3)に変更された場合に、バッファ占有量がS_target3に近づいていく様子が示されている。
【0101】
図9〜図11に共通して、”S_max”は、端末102のバッファの総容量であり、”Sum”が、バッファ占有量である。”delta(0,1,2,…)”は、サーバ101が単位時間Tsあたりに送信するデータの量(すなわち、1つのパケットに詰め込まれているデータの量)を示す。ここで、単位時間Tsは、サーバ101がパケットを送信する周期であり、固定値である。”L(0,1,2,…)”は、1つのフレームあたりのデータ量である。
【0102】
サーバ101は、端末102からT_delayの値の通知を受けると、その値に基づいてストリームの送信速度を制御する。この速度制御は、1つのパケットに詰め込むデータの量を変化させることにより行われる。
【0103】
図9において、サーバ101が最初に送信したパケット(i=0)には、量delta0のデータが詰め込まれており、時刻t=0では、バッファ占有量Sumは、delta0となる。単位時間Tsが経過すると、次のパケット(i=1)が送られてくるが、そこには、量delta1のデータが詰め込まれている。従って、時刻t=Tsでは、Sumは、{delta0+delta1}となる。以降、単位時間Tsが経過する毎に、次々とパケット(i=2,3,…)が送られてきて、Sumにdelta2,delta3,…が加算されていく。
【0104】
一方、3つ目のパケット(i=2)が送られてくる以前である時刻t=T_delayに、バッファからデータを読み出してデコードする処理が開始される。デコードはフレーム単位で行われるので、t=T_delay以降、固定周期Tfrm毎に、SumからL0,L1,L2…が減算されていく。
【0105】
すなわち、バッファ占有量Sumは、時刻t=0以降、周期Ts毎に、delta0,delta1,…が加算されて、だんだん増加していく。その一方で、時刻t=T_delay以降、周期Tfrm毎にL0,L1,L2…が減算されていく。従って、Sumが目標値S_targetに達する直前までの期間は、1つのパケットに詰め込むデータ量を標準よりも多くして(より一般的には送信速度を速くして)、バッファへの書き込み速度がバッファからの読み出し速度を上回るようにし、それ以降は、1つのパケットに詰め込むデータ量を標準に戻して、書き込み速度と読み出し速度とを均衡させれば、Sumを目標値S_targetの近傍で遷移させることが可能となる。
【0106】
このような送信速度制御を行えば、図10,図11のように、目標値S_targetが途中で新たな目標値(S_target2,3)に変更された場合にも、Sumを新たな目標値(S_target2,3)の近傍で遷移させることが可能となる。
【0107】
すなわち、図10において、Sumが目標値S_targetの近傍で遷移している状態で、S_targetがより大きな値(S_target2)に変更されると、サーバ101は、以降のパケット(i=3,4)に詰めるデータの量を増やすことによって、バッファへの書き込み速度がバッファからの読み出し速度を上回るようにする。Sumが新たな目標値S_target2に達して以降は、1つのパケットに詰め込むデータ量を標準に戻して、書き込み速度と読み出し速度とを均衡させればよい。
【0108】
また、図11において、Sumが目標値S_targetの近傍で遷移している状態で、S_targetがより小さな値(S_target3)に変更されると、サーバ101は、以降のパケット(i=3,4)に詰めるデータの量を減らすことによって、バッファへの書き込み速度がバッファからの読み出し速度を下回るようにする。Sumが新たな目標値S_target3に達して以降は、1つのパケットに詰め込むデータ量を標準に戻して、書き込み速度と読み出し速度とを均衡させればよい。
【0109】
次に、上で説明したようなサーバ101による送信速度制御について詳細に説明する。図12は、サーバ101が行う送信速度制御アルゴリズムの一例を示すフローチャートである。図12において、最初、端末102が自身のバッファ占有量(Sum)を検出し、サーバ101は、端末102からバッファ占有量Sumの通知を受ける(ステップS301)。次に、サーバ101は、ステップS301で通知されたバッファ占有量Sumが、端末102から指定された目標値S_targetの近傍で遷移しているか否かを判定する(ステップS302)。その判定結果が肯定であれば、現在の送信速度が維持される。
【0110】
ステップS302の判定結果が否定の場合、サーバ101は、ステップS301で通知されたバッファ占有量Sumが目標値S_targetよりも大きいか否かを判定する(ステップS303)。そして、判定結果が否定であれば、送信速度を現在よりも速い速度に変更し(ステップS304)、その後、ステップS306に進む。一方、ステップS303の判定結果が肯定であれば、送信速度を現在よりも遅い速度に変更し(ステップS305)、その後、ステップS306に進む。
【0111】
ステップS306では、速度制御動作を継続するか否かが判断され、判断結果が肯定の場合、ステップS301に戻って、上記と同様の動作が繰り返される。一方、判断結果が否定の場合、動作が終了される。以上が、サーバ101が行う送信速度制御の一例である。
【0112】
ところで、図12の例では、端末102が自身のバッファ占有量を検出して、サーバ101に通知している。しかしその場合、端末102が検出するのは、現在時刻におけるバッファ占有量である。その上、端末102からサーバ101への情報伝達に時間がかかるので、サーバ101は、伝達遅延時間の分だけ過去のバッファ占有量に基づいて送信速度制御を行うことになり、バッファ占有量をS_targetの近傍で遷移させるのは、現実には困難である。
【0113】
これに対して、以下に説明する別の例(図13,14参照)では、未来のある時点でのバッファ占有量に基づいて送信速度制御を行うことによって、バッファ占有量をS_targetの近傍で遷移させることが可能となる。この場合、サーバ101は、端末102からSumの通知を受けるのでなく、未来のある時刻における端末102側のバッファ占有量Sumを予測算出する。この予測算出は、次のようにして行われる。
【0114】
すなわち、図2において、ROM413には、パケット送信周期Ts(固定値)と、デコード周期Tfrm(固定値)とが予め記憶されている。CPU412は、パケットが生成される際、そのパケットに詰め込まれたデータの量(delta0,delta1,delta2,…)をRAM404に記憶させておく。さらに、ストリームが送信される際、各フレームのデータ量(L0,L1,L2,…)をRAM404に記憶させておく。
【0115】
RAM404にはまた、先に端末102から通知されたT_delayが記憶されており、CPU412は、ROM413内のTsおよびTfrmと、RAM404内のdelta(0,1,2,…)、L(0,1,2,…)およびT_delayとを参照して所定の演算を行うことにより、未来のある時刻におけるバッファ占有量Sumを算出することができる。このような算出処理を行うことによって、サーバ101は、端末102側においてバッファ占有量Sumがどのように遷移してくか(図9〜図11参照)を予測することができる。
【0116】
以下、サーバ101が端末102のバッファ占有量Sumを予測算出して送信速度制御を行う具体的な動作例について、図9のバッファ遷移図、図13および図14のフローチャート、図15のパケット構成図を用いて説明する。
【0117】
図9において、S_maxは、端末102内バッファの有効蓄積量の最大値(これを簡単に「バッファの総容量」と呼んでいる)であり、S_targetは、今回のストリーミングにおいて端末102内バッファに蓄積しようとする目標量であり、T_delayは、頭出し遅延時間の設定値である。これら各パラメータの意味については、既に説明したとおりである。以下では、端末102よりS_targetとT_delayが通知されたものとして説明を行う。
【0118】
本実施の形態では、理解を簡単にするために、固定時間周期Ts毎にパケットの生成・配信を行う例(i=nに相当する時刻でパケット配信:nは整数)を示している。また、i=nに相当する時刻(t=i*Ts)でパケットの配信がなされた際に、端末102の受信バッファ505およびデコーダバッファ508内の蓄積量Sumは、数フレームに相当するデータ量が瞬時に増加しているが、これは、図15(A)に示されているように、1パケットに複数フレームを挿入するパターンでパケットを生成して端末102に配信しているためである。実際には、パケット配信には転送時間がかかり、図のように瞬時にバッファ占有量が増加する訳ではない(傾き=networkRateの斜線になる)が、あくまでモデルとして単純化して取り扱うものとする。また、時刻t=T_delay以降、階段状にバッファ占有量が減じられていくのは、その時刻に端末102でストリーム再生が始まったことを示している。すなわち、フレームの再生周期Tfrm毎に、各々のフレーム長L=L[k](kは整数)ずつデコーダ509でデータが処理される。
【0119】
図13および図14は、図9のバッファ遷移を実現するためにサーバ101によって行われる送信制御アルゴリズムの別の例を示したフローチャートである。図13がアルゴリズムの全体像であり、図14は、図13のステップS404中の関数mkPacketの一例を示すフローチャートである。このようなアルゴリズムを記述したプログラムがROM413(図2参照)に格納されており、CPU412は、このプログラムに従って各種の演算や制御を行い、その結果、図9のバッファ遷移が実現される。なお、説明を簡単にするために、ストリーム途中での配信停止などは、今回考えないものとする。以下、各ステップについて順次説明を行う。
【0120】
図9において、サーバ101は、端末102から送られてきたS_targetおよびT_delayを受信して記憶する(ステップS401)。具体的には、図2において、端末102からネットワーク103経由で送られてきたS_targetおよびT_delayの値が、ネットワークコントローラ410を通じてRAM404に書き込まれる。
【0121】
なお、ここでは、端末102がパラメータS_targetおよびT_delayの値を決定して、結果をサーバ101に通知しているが、代わりに、サーバ101がそれらの値を予め記憶しておいてもよく、あるいは、端末102の機種情報(バッファの総容量等)を記憶しておいて、この機種情報をもとにサーバ101がパラメータの値を計算してもよい。
【0122】
次に、各変数の初期化が行われる(ステップS402,S403)。各変数の意味は、図14の説明にて後述する。初期化が完了すると、ステップS404以降の処理、すなわち関数mkPacketにてパケットを生成してネットワーク103中に送出する処理が開始される。生成されたパケットは、この例では固定周期Tsで端末102に配信されるので、サーバ101は、ステップS405にてタイミング調整を行ったのち、ステップS406にて送出を行う。この一連の処理が完了すると、CPU412は、関数mkPacketの実行カウンタiを更新し、ステップS404に戻ってループする。ストリームデータの読み出しおよびパケット化が全て完了すると、CPU412は、関数mkPacketを抜けて、ステップS404に判定結果FALSEでreturnする。CPU412は、このとき配信が完了したと見なし、アルゴリズムを完了する。以上が、本送信制御アルゴリズムの概要である。
【0123】
次に、ステップS404に示された関数mkPacketの詳細なアルゴリズムであるが、まず各変数について説明を行う。Sumは、端末102内の受信バッファ505およびデコーダバッファ508に蓄積されているデータ量の総和であり、Lは、フレームのデータ量であり、deltaは、関数mkPacketが今回呼ばれてからパケット化したデータ量の総和(すなわち1つのパケットに詰め込んだデータの量)であり、inは、蓄積デバイス411から読み出したストリームソースのフレーム数を示すカウンタであり、outは、端末102内のデコーダ509でデコードされたフレーム数を示すカウンタであり、dtsは、デコーダ509にてフレームがデコードされる時刻であり、gridは、前回の関数mkPacketの1ループを処理する際に進んだdtsの上限値である。
【0124】
図14において、関数mkPacketは、大きくパケット生成アルゴリズムA1と、デコード量算出アルゴリズムA2との2つのアルゴリズムに分けられる。前者において、最初のステップ(S501)では、CPU412は、deltaをクリアする。続くステップS502では、CPU412は、L=L[in]のフレーム(既に読み出し済み)を今回のパケット生成に用いて良いかどうかの判定を行う。判定の基準は、(a)SumにLを加えてもS_targetを越えないこと、および(b)今回の関数呼び出しでパケット化したデータの量(今回1つのパケットに詰め込んだデータの量)deltaにLを加えても、1つのパケットに詰め込み可能なデータ量の上限値deltaMaxを超えないこと、の2つであるである。
【0125】
ここでdeltaMaxは、図15(A)に示される不等式
(deltaMax+hdr)/Ts<NetworkRate
を満たす値であって、周期Ts以内に端末に配信可能なデータ量の最大値であり、ネットワーク103の実効転送レート(伝送能力)から算出が可能である。ステップS502にて真と判定されると、CPU412は、ステップS503に進み、L=L[in]のフレームをパケット化する。続くステップS504では、CPU412は、パケット化の実行に伴い、Sumおよびdeltaを更新する。続くステップS505では、CPU412は、次のフレームのデータを読み出しバッファ407から、フレーム長LをRAM404から、それぞれ読み出す。
そして、Lが0よりも大きいか否かを判定する。
【0126】
ステップS505の判定結果が否定、すなわちL=0であれば、CPU412は、全データの読み出しが完了した(End of File検出)とみなし、関数を抜ける。そして、メインフロー(図13)のステップS404に判定結果FALSEでRETURNする。一方、判定結果が肯定、すなわちL>0であれば、CPU412は、次のステップ(S506)に進み、L[in]を配列leng内に加える(RAM404に記憶させる)。これは後ほど説明するが、デコード量算出アルゴリズムA2で用いるためである。次に、CPU412は、ステップS507に進み、読み出したフレーム数カウンタinを更新して、ステップS502にループする。
【0127】
上記のループによるパケット生成を繰り返すうち、Sumおよびdeltaの値がだんだん大きくなっていく。そして、ステップS502にてSumまたはdeltaが十分大きくなったと判定されると、CPU412は、このループを抜けて、デコード量算出アルゴリズムA2に入る。
【0128】
デコード量算出アルゴリズムA2において、最初のステップ(S508)では、i*Tsがgrid以上であるか否かが判定される。このステップS508は、端末102においてデコードが開始される時刻になったかどうかを判定することが目的である。具体的には、gridが最初T_delayに設定されているため、関数呼び出しカウンタ数iが小さくてt=i*Tsがgrid未満の間は、端末102でのデコードがまだ始まっていないものと判定される。図9では、i=0およびi=1と対応する時刻がこれに相当する。
【0129】
ステップS508の判定結果が否定の場合、CPU412は、デコードによるフレームデータの減算を行わずに関数を抜ける。一方、iが十分大きくなってパケット生成時刻t=i*Tsがgrid以上になると、CPU412は、端末102でのデコードが既に始まっているとみなし、フレームデータの減算処理を行う。図9では、iが2以上の時刻がこれに相当する。続くステップS509からステップS512までのループにおいて、現在のgrid時刻から次のgrid時刻(=grid+Ts)に挟まれた時間内にデコード処理されるフレームデータの量leng[out]をSumから減算し、かつデコードしたフレーム数outをカウントアップする。
【0130】
上記ループ内のステップS511において、dtsには、フレームを1つデコードするたびにTfrmずつ加算されるが、これは、本実施形態が固定時間間隔Tfrmのフレーム発生を行う符号化方式を用いていることに由来する。ステップS512では、CPU412は、今回の時間間隔Tsでデコードされるべきフレームの有無を判定している。ステップS512の判定結果が否定、すなわち、もはや今回の時間間隔Tsでデコードされるフレームは無いと判定されると、CPU412は、上記のループ(ステップS509〜S512)から抜け、ステップS513に進む。ステップS513では、CPU412は、変数gridを次のgrid時刻に更新する。そして、関数を抜け、メインフロー(図13)のステップS404に判定結果TRUEでRETURNする。
【0131】
以上のアルゴリズムにより、図9で示したように、端末102内において、バッファ占有量Sumを常にS_targetの近傍でかつS_targetを超えないように遷移させることが可能となる。従って、複数機種の端末102があって、バッファの総容量Smaxが機種によって異なっていても、それぞれの端末102のSmaxに応じてS_targetを適切な値に設定すれば、バッファのオーバーフローもアンダーフローも生じないようにすることができる。
【0132】
なお、今回の例では、図15(A)のように1パケットに複数フレームを挿入するパターンでパケットを生成したが、代わりに、図15(B)のように、1パケットに1フレームのフレームを挿入するパターンでパケットを生成することも可能である。この場合は、図14のステップS502において、後半の不等式を
delta+(L+hdr) <= deltaMax
とし、ステップS504の後半の等式を
delta += (L+hdr)
とするだけでよい。
【0133】
また、本実施形態では、説明を簡単にするために、固定時間間隔Tfrmでフレーム発生を行う符号化方式を用いたが、使用する符号化方式―たとえばMPEG4ビデオ(ISO/IEC 14496−2)―に合わせてデコード量算出アルゴリズムA2を設計すれば、必ずしも固定時間間隔のフレーム発生を行わなくても構わないことはいうまでもない。また、必ずしもフレーム単位でデータを扱うアルゴリズムでなくてもよく、例えばスライス単位、あるいはMPEG1やMPEG2システムストリームのパック単位でデータを扱うアルゴリズムであってもよい。
【0134】
一方、図14のステップS502において、S_targetの値が途中で変更されると、本アルゴリズムは瞬時に、変更された新しいS_targetをターゲットとしてパケットの生成を行うようになる。S_targetの値が途中で変更された場合のバッファ遷移の様子が、図10および図11に示されている。図10において、i=3の時刻にS_targetがS_target2に変更(S_target<S_target2≦S_max)されると、変更後しばらくは多量のフレームデータがパケット化され(図中、delta3やdelta4)、その結果、Sumが新しい目標値S_target2の近傍に到達するようになる。
【0135】
また、図11のように、i=2の時刻にS_targetがS_target3に変更(S_target3<S_target)されると、少量(delta4)または0(delta3)のフレームデータがパケット化される。その一方、デコードによりSumが消費されるので、やはりSumが新しい目標値S_target3の近傍に到達するようになる。このような仕組みを利用すると、ネットワーク103の伝送能力(あるいは端末102の電波受信状態)に応じて、動的に端末102内のバッファ占有量Sumを増減させることが可能となり、以下に説明するような応用が可能となる。
【0136】
図7(A)において、携帯電話701(図1の端末102と対応)を持ったユーザが、図中の矢印702ように、中継局B1の圏内から中継局B2の圏内へと移動する場合を考える。移動に伴い、携帯電話701からの呼を受け付ける業務が、中継局B1から中継局B2へと引き渡される。このとき、携帯電話701の受信電波強度は、おおむね図7(B)に示したグラフのように変化する。本モデルでは、説明を簡単にするために、電波強度が強から中(または中から強)に変わるところをネットワーク103の伝送能力に関する閾値A、中から弱(または弱から中)に変わるところを閾値B、弱から圏外(または圏外から弱)に変わるところを閾値Cとした。
【0137】
図7(B)において、今、携帯電話701を持ったユーザが距離d1だけ移動し、伝送能力が閾値Aを下回ったとする。このとき携帯電話701は、図11に示されるように、S_delayをより大きい値(S_target2)に変更して、その値をサーバ101に通知する。これは、その後も進むと予想される伝送能力低下に備えて、サーバ101による新たなパケット生成および送出を促進させ、それにより、できるだけ長時間(これをΔtとする)ぶんのデータを携帯電話701内のバッファに蓄積しておくためである。伝送能力が閾値Aを下回っても、閾値B以上である間は、まだパケットの転送ロスが発生することがないので、このような伝送速度の高速化が可能である。
【0138】
ユーザが移動して距離d2に達すると、伝送能力が閾値Bを下回って、パケットの転送ロスが発生し始める。このとき、携帯電話701は、図11に示されるように、S_targetを小さい値(S_target3)に変更して、その値をサーバ101に通知する。これは、その後もさらに進むと予想される伝送能力低下に備えて、できるだけサーバ101による新たなパケット生成および送出を抑制させるためである。パケット生成および送出を抑制するのは、次の理由による。
【0139】
たとえば、携帯電話701が通信方式としてPHSのPIAFS方式を採用している場合、パケットの伝送ロスが発生すると、リンクレイヤであるPIAFS層のプロトコルに基づくデータ再送処理が行われる。再送処理中に、新たなパケット生成および送出が行われると、それが再送処理の邪魔をする結果となり、かえって好ましくないからである。
【0140】
ユーザが移動して距離d3に達すると、伝送能力が閾値Cを下回って、一瞬、パケット転送が困難となる。しかし、ユーザがさらに移動して距離d4に達すると、伝送能力が閾値Bを上回り、かつ呼を受け付ける業務の引き渡し(ハンドオーバー)も完了しているので、携帯電話701は、今度はS_target3を元の値S_targetに戻して、その値をサーバ101に通知し、それによって、データの蓄積量(すなわちバッファ占有量Sum)を増加させる。なお、PHS等のハンドオーバー時間は、普通に人が歩く速さでもおおよそ2〜3秒程度で完了するため、上記のΔtをおおよそ3〜4秒程度確保しておけば、ハンドオーバーが起こっても携帯電話701でのストリーミング再生を滞りなく継続することができる。
【0141】
ところで、図11のように、ストリーム配信の途中でS_targetの設定値がより小さな値に変更されると、図14のアルゴリズムにおいてステップS502の判定文がなかなか真にならず、次のフレームのデータを送出できないケースが起こりうる。このようなケースがたびたび発生すると、折角パケットを端末102に届けても、もはやそのパケット内のフレームデータを再生するべき時刻(Presentation Time)を経過してしまっており、データが無駄になってしまうことがある。このような場合は、再生時刻が経過してしまったフレームデータをスキップした方が、無駄なデータをネットワーク103に流さないで済む分だけ効率的である。
【0142】
図16は、図13のステップS404中の関数mkPacketの別の例を示すフローチャートである。図16の関数mkPacketには、サーバ101が送信速度を遅くする際に、再生時刻を過ぎたデータの送出をスキップするためのステップ(S601およびS602)が含まれている。すなわち、図16のアルゴリズムは、図14と比較して、ステップS601およびステップS602が追加されただけである。他のステップは、図14と全く同じであり、同一の参照番号が付されている。ステップS601では、CPU412は、今から送出しようとしているin番目のフレームデータが、0番目のフレームのデータでなく、かつ、端末102にて既にデコードされたとみなされるout番目のフレームデータより再生時刻が後かどうかを判定している。
【0143】
この判定結果が真ならば、CPU412は、in番目のフレームのデータが端末での再生時刻に間に合うと見なして、ステップS503にてそのデータをパケット化し、端末102に送出する。偽の場合は、in番目のフレームデータを無かったものとみなし、ステップS602にてL=0とする。これにより、ステップS502では必ず真と判定され、かつステップS503のパケット化において、不要なフレームデータのコピーを行わずに、送出フレームを次に進めることができる。なお、このようなフレームスキップがあった場合は、デコーダ509での再生が時間Tfrmだけ飛ぶので、その旨を端末102に通知する情報が、図15(A),(B)のパケット中に記述されるものとする。例えば、ヘッダ内にそのような再生時刻情報を記述する領域を設ければよい。
【0144】
図16に示したアルゴリズムは、MPEGオーディオのように各フレームどうしの優先順位(重要度)に差が無い場合には、十分有効な手法である。しかし、MPEGビデオにおいては、従来例の紹介において既に説明したように、Iフレームであればそれ単独で意味のある画像を再構成することができるが、PやBのフレームでは、時間的に前後の参照フレームがなければ、意味のある画像を再構成することができない。この場合には、図16のアルゴリズムにおいてフレームの間引きを行う際に、再生時刻に間に合うIフレームを優先的に送出する一方、PやBのフレームを全てスキップすることで、ネットワーク103の転送速度が遅い状況においても、端末102に対してより高品位の映像を提供することが可能となる。
【0145】
図17は、図13のステップS404中の関数mkPacketの、さらに別の例を示すフローチャートである。図17の関数mkPacketには、サーバ101が送信速度を遅くする際に、優先度の低いデータと、優先度は高いが再生時刻を過ぎたデータとの送出をスキップするためのステップ(S505’,S601,S602,S701およびS702)が含まれている。すなわち、図17のアルゴリズムは、図14と比較して、ステップS601,S602,S701およびS702が追加され、かつステップS505がステップS505’に置き換えられている。ステップS505’は、ステップS505に対し、関数NexTfrmに優先順位priの検出機能が加えられたものである。他のステップは、図14,図16と全く同じであり、同一の参照番号が付されている。
【0146】
従って、図17のアルゴリズムは、図16と比較すると、ステップS701,S702が追加され、かつステップS505がS505’に置き換わっている。
【0147】
図17のアルゴリズムを実行するには、端末102が検出した受信状態を示す情報(受信状態情報)を、端末102からサーバ101に通知する機能が必要となる。このような機能を持ったサーバ・クライアント・システムの構成例を、図18に示す。図18において、端末102は、受信状態を検出する検出部801を備えている。端末102とサーバ101との間には、検出された受信状態情報を端末102からサーバ101に通知する通知部802が設けられる。サーバ101は、保持部803を備えており、通知された受信状態情報を保持する。
【0148】
再び図17において、mkPacket関数が呼び出されると、ステップS501に先立って、ステップS701が実行される。ステップS701において、サーバ101(のCPU412)は、保持部803内の情報(端末102側の受信状態)を参照して、ネットワーク103の伝送能力が閾値Bを下回るか否かを判定する。この判定の結果、閾値Bを下回っていればslowflagを真とし、そうでなければ偽とする。
【0149】
ステップS505’では、次のフレームの優先度が検出され、続くステップS702では、そのフレームのデータの優先度が高く、かつslowflagが真であるか否かが判定される。この判定結果が肯定、すなわちネットワーク103の転送速度が遅いことを示すslowflagが真であり、かつ優先度の高いフレームである場合、ステップS601に進んで、再生時刻が経過してしまったフレームか否かが判定される。一方、判定結果が否定である場合、ステップS602に進んで、L=0とされる(つまり、たとえ再生時刻に間に合うようであっても、そのフレームはスキップされる)。後の処理は、図14や図16の処理と全く同様である。
【0150】
以上のように、本実施形態によれば、端末102が、自身のバッファ容量とネットワーク103の伝送能力とに応じた目標量を決定し、さらに、目標量を伝送能力で除して得られる値を超えない範囲内で、遅延時間を決定する。サーバ101は、こうして端末102が決定した目標量および遅延時間に基づいて送信速度を制御するので、端末102のバッファ容量が機種によって異なっていても、ネットワーク103の伝送能力が変動しても、バッファ量および伝送能力に応じた送信速度制御が行え、その結果、バッファのアンダーフローやオーバーフローによるストリーミング再生の破綻を回避することが可能となる。しかも、目標量とは独立に遅延時間が決定されるので、ストリーミング再生の破綻回避と、頭出し時の待ち時間短縮とを互いに両立させることができる。
【図面の簡単な説明】
【図1】本発明の一実施形態に係るストリーミング方法を実行するサーバ・クライアント・システムの構成例を示すブロック図である。
【図2】図1のサーバ101の構成を示すブロック図である。
【図3】図1の端末102の構成を示すブロック図である。
【図4】図1のシステムの全体動作を説明するためのシーケンス図である。
【図5】図1の端末102の動作を示すフローチャートである。
【図6】図3のROM502の記憶内容を示す図である。
【図7】あるエリアにおける電界強度の分布(A)と、端末の移動に伴う伝送能力の変化(B)とを示す模式図である。
【図8】図5のステップS107の詳細を示すフローチャートである。
【図9】図1のサーバ101が行う送信速度制御によって、端末102のバッファ占有量がどのように遷移するか(S_targetに近づいていく様子)を示す図である。
【図10】バッファ占有量がS_targetの近傍で遷移している状態で、S_targetの値がより大きな値(S_target2)に変更された場合に、図1のサーバ101が行う送信速度制御によって、端末102のバッファ占有量がどのように遷移するかを示す図である。
【図11】バッファ占有量がS_targetの近傍で遷移している状態で、S_targetの値がより小さな値(S_target3)に変更された場合に、図1のサーバ101が行う送信速度制御によって、端末102のバッファ占有量がどのように遷移するかを示す図である。
【図12】図1のサーバ101が行う送信速度制御アルゴリズムの一例を示すフローチャートである。
【図13】図9〜図11のバッファ遷移を実現するためにサーバ101によって行われる送信速度制御アルゴリズムの別の例を示したフローチャートである。
【図14】図13のステップS404中の関数mkPacketの一例を示すフローチャートである。
【図15】図1のサーバ101が生成するパケットの構成例(Aは1パケットに複数フレームを挿入する場合、Bは1パケットに1フレームを挿入する場合)を示す図である。
【図16】図13のステップS404中の関数mkPacketの別の例を示すフローチャートである。
【図17】図13のステップS404中の関数mkPacketの、さらに別の例を示すフローチャートである。
【図18】本発明の一実施形態に係るストリーミング方法を実行するサーバ・クライアント・システムの別の構成例を示すブロック図である。
【図19】従来のストリーミング方法を説明するための図である(Aはビデオフレーム、Bはバッファ占有量の遷移、Cは従来端末の構成例)。
【図20】従来のストリーミング方法を実行するサーバ・クライアント・システムの構成例を示すブロック図である。
【図21】受信バッファを追加することによってバッファ占有量の遷移がどのように変化するかを説明するための図である(Aが追加前、Bが追加後)。
【符号の説明】
101 サーバ
102 端末
103 ネットワーク
402,507 送受信モジュール
404 RAM
405 生成モジュール
406 パケット生成回路
407 読み出しバッファ
408 パケット生成バッファ
409 送信バッファ
410,506 ネットワークコントローラ
411 蓄積デバイス
412,503 CPU
413,502 ROM
505 受信バッファ
508 デコーダバッファ
509 デコーダ
510 再生モジュール
511 表示デバイス[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a streaming method, and more particularly to a streaming method in which a server transmits multimedia data to a terminal through the Internet, and the terminal reproduces the data while receiving the data.
[0002]
[Prior art]
(Description of multimedia data encoding and compression method and buffer model)
There are various types of multimedia data used for transmission on the Internet, such as moving images, still images, audio, text, and data in which they are multiplexed. In the video, H. Coding compression methods such as H.263, MPEG1, 2, 4 are well known, JPEG is used for still images, MPEG audio is used for audio, and G.264 is used for audio. 729 and so on.
[0003]
In the present invention, since the focus is on streaming reproduction, moving images and audio are targets for transmission. Here, an MPEG video that is a representative of the moving image compression method, particularly an MPEG1 (ISO / IEC 11172) video and an MPEG2 (ISO / IEC 13818) video that have a relatively simple mechanism will be described.
[0004]
MPEG video mainly has the following two features in order to realize highly efficient data compression. First, in compression of moving image data, a compression method using temporal correlation characteristics between frames is adopted in addition to a compression method using spatial frequency characteristics which has been conventionally performed. In MPEG, each frame (also referred to as a picture) constituting a stream is divided into an I frame (an intra-frame encoded picture), a P frame (a picture using intra-frame encoding and a reference relationship from the past), a B frame ( Data compression is performed by classifying into three types (pictures using intra-frame coding and past and future reference relationships). In these three types, the I frame is the largest (that is, the amount of information is the largest), followed by P and B. Although greatly dependent on the compression algorithm, the ratio of the information amount is approximately I: P: B = 4: 2: 1. In general, an MPEG video stream includes 15 frames (= 1 GOP) as a unit, and 1 GOP includes 1 I frame, 4 P frames, and 10 B frames.
[0005]
The second feature of MPEG video is that dynamic code amount allocation according to image complexity can be performed in units of pictures. An MPEG decoder includes a decoder buffer. By decoding data after storing the data in the decoder buffer, a large amount of code can be assigned to a complex image that is difficult to compress. In moving image compression, not limited to MPEG, the standard decoder buffer capacity is mostly defined by the standard. In the case of MPEG1 or MPEG2, the standard decoder buffer has a capacity defined as 224 Kbytes in the standard, and the MPEG encoder must generate picture data so that the decoder buffer occupancy transitions within this capacity.
[0006]
19A to 19C are diagrams for explaining a conventional streaming method. FIG. 19A is a diagram showing a video frame, FIG. 19B is a diagram schematically showing a transition of buffer occupancy, and FIG. 19C is a diagram showing a configuration example of a conventional terminal. . In FIG. 19C, the terminal includes a video buffer, a video decoder, an I / P rearrangement buffer, and a switch. The video buffer corresponds to the decoder buffer described above, and the transferred data is stored in the video buffer and then decoded by the video decoder. The decoded data is rearranged in order of reproduction time through the I, P rearrangement buffer and the switch.
[0007]
In FIG. 19B, the vertical axis represents the buffer occupation amount (data accumulation amount of the video buffer), the horizontal axis represents time, and the thick line in the figure represents the temporal transition of the buffer occupation amount. The slope of the thick line corresponds to the video bit rate and indicates that data is input to the buffer at a constant rate. Further, the buffer occupancy is reduced at regular intervals (33.3667 msec). This is because the data of each frame is decoded at regular intervals. In addition, the intersection of the oblique dotted line and the time axis indicates the time when the data in each video frame starts to be transferred to the video buffer. Accordingly, the transfer start time of frame X shown in FIG. 19A is t1, and the transfer start time of frame Y is t2.
[0008]
19A and 19B, from the time t1 when the start frame X of the video starts to be input to the video buffer to the time when decoding is first executed (the first falling position of the bold line in the figure). Is generally called vbv_delay time. Since the first decoding is performed at the moment when the video buffer is full, the vbv_delay time is usually the time from the start of data input until the video buffer with a capacity of 224 Kbytes is full. This is the initial delay time (waiting time for cueing) from the start until video playback is started through the decoder.
[0009]
When the frame Y in FIG. 19A is a complex image, as shown in FIG. 19B, the amount of code is large, so that it is earlier than the decoding time of frame Y (t3 in the figure). Data transfer to the video buffer must be started from time (t2 in the figure). However, the amount of pictures that occupy the buffer is within the allowable range of 224 Kbytes, no matter how complex the image is.
[0010]
If data is transferred to the video buffer so that the buffer transition shown in FIG. 19B is properly maintained, it is guaranteed by the MPEG standard that no streaming failure occurs due to an underflow or overflow of the video buffer. ing.
[0011]
(Description of network transfer jitter absorption receive buffer)
However, as shown in FIG. 20, when the
[0012]
Here, providing the
[0013]
By adding the
[0014]
[Problems to be solved by the invention]
As is apparent from the above, when streaming multimedia data such as MPEG in a network environment where reliability and transmission speed are guaranteed such as a small LAN, it is basically determined by the codec standard. As long as the system design properly observes the playback initial delay time (vbv_delay) and the decoder buffer transition, the decoder playback will not underflow or overflow, and streaming playback will not fail.
[0015]
However, in a wide area network environment such as the Internet, since the transfer jitter due to the transmission characteristic variation of the communication path is so large that it cannot be ignored, the
[0016]
In general, the capacity of a buffer for absorbing jitter mounted on a terminal varies depending on the model. For this reason, even if the same data is distributed under the same conditions, streaming playback can be performed without failure on a model with a large buffer capacity. However, on a small model, there is a case in which it fails without absorbing jitter.
[0017]
In order to solve this problem, for example, the amount of memory installed in the terminal may be increased to ensure a sufficient buffer capacity for absorbing jitter. However, the amount of installed memory is one of the main factors that determine the price of a terminal, and there is a demand to suppress it as much as possible. In addition, if the buffer capacity for absorbing jitter is too large, a new problem arises that the cue time until the start of reproduction becomes long and the user is frustrated.
[0018]
Therefore, the object of the present invention is to avoid the failure of streaming playback due to buffer underflow or overflow even if the buffer capacity of the terminal varies depending on the model or the transmission capacity of the network fluctuates. Furthermore, it is to provide a streaming method capable of achieving both the avoidance of failure of streaming reproduction and the reduction of waiting time at the time of cueing.
[0019]
[Means for Solving the Problems and Effects of the Invention]
A first invention is a streaming method in which a server transmits stream data to a terminal through a network, and the terminal reproduces the stream data while receiving the stream data,
A target amount determination step in which the terminal determines a target amount of stream data to be stored in its buffer in relation to its buffer capacity and network transmission capability;
The delay time from when the terminal writes the head data of the stream to its own buffer until the data is read and playback is started, as long as it does not exceed the value obtained by dividing the buffer capacity by the transmission capacity Determine the delay time determination step,
The terminal notifies the server of the determined target time and delay time;
When the server transmits the stream data to the terminal through the network, the server includes a control step of controlling the transmission speed based on the notified target amount and delay time.
[0020]
In the first invention, the terminal determines a target amount according to its own buffer capacity and the transmission capacity of the network, and further within a range not exceeding a value obtained by dividing the buffer capacity by the transmission capacity, Determine the delay time. Since the server controls the transmission speed based on the target amount and delay time determined by the terminal in this way, even if the terminal buffer capacity varies depending on the model or the transmission capacity of the network fluctuates, the buffer amount and transmission capacity As a result, it is possible to avoid failure of streaming playback due to buffer underflow or overflow. In addition, since the delay time is determined independently of the target amount, it is possible to achieve both the avoidance of failure of streaming playback and the reduction of the waiting time at the time of cueing.
[0021]
Here, the reason why the delay time is limited to a value obtained by dividing the buffer capacity by the transmission capability is that there is a risk that streaming playback may fail if the delay time exceeds this value. As long as the value does not exceed this value, the delay time may be determined to any value. However, when determining the value, the balance between the tolerance to fluctuations in transmission capability and the waiting time at the time of cueing is considered.
[0022]
According to a second invention, in the first invention,
In the control step, the server
The transmission speed is controlled so that the amount of stream data stored in the buffer of the terminal changes without exceeding the target amount in the vicinity of the target amount.
[0023]
In the second aspect of the invention, since the accumulated amount transitions in the vicinity of the target amount without exceeding the target amount, the buffer underflow and overflow are unlikely to occur.
[0024]
According to a third invention, in the second invention,
In the control step, the server predicts and calculates the amount of stream data stored in the terminal buffer based on the transmission speed, the delay time, and the speed at which the terminal decodes the stream data. .
[0025]
In the third aspect, since the server predicts and calculates the accumulation amount and performs transmission speed control based on the amount, the accumulation amount can be shifted in the vicinity of the target amount so as not to exceed the target amount.
[0026]
Here, the terminal may notify the server of the current accumulation amount, and the server may perform transmission speed control based on the notification. However, in this case, since it takes time to transmit information from the terminal to the server, the server performs transmission speed control based on the past accumulation amount. Therefore, it is not always possible to make a transition so that the accumulated amount does not exceed the target amount in the vicinity of the target amount.
[0027]
According to a fourth invention, in the first invention,
A detection step in which the terminal detects that the transmission capability of the network has changed across a predetermined threshold;
A target amount changing step in which the terminal changes the target amount according to the detection result in the detecting step; and
The terminal further includes a step of notifying the server of the target amount after the change,
In the control step, when the server receives the notification of the changed target amount, the amount of stream data accumulated in the terminal buffer does not exceed the changed target amount in the vicinity of the changed target amount. The transmission speed is controlled so as to transit.
[0028]
In the fourth aspect, when the transmission capacity changes across the threshold, the target amount is changed by the terminal. The server follows the change in the target amount by controlling the transmission speed so that the change does not exceed the target amount after the change in the vicinity of the target amount after the change.
[0029]
A fifth invention is the fourth invention,
When detecting that the transmission capability of the network has decreased across the first threshold in the detection step, the terminal changes the direction to increase the target amount in the target amount change step,
In the control step, the server controls the transmission speed to increase in accordance with the increase of the target amount.
[0030]
In the fifth aspect, when the transmission capacity changes across the first threshold, the target amount is increased by the terminal. The server follows the increase in the target amount by increasing the transmission speed.
[0031]
According to a sixth invention, in the fifth invention,
The first threshold is a value approximately in the middle between the maximum realizable transmission capability and the transmission capability at which stream data transfer loss begins to occur.
[0032]
In the sixth aspect of the invention, when the transmission capability is decreasing, the transmission rate is increased to increase the accumulation amount before the transfer loss of stream data starts to occur. As a result, it is possible to prevent the streaming reproduction from failing when the transmission capability is reduced.
[0033]
According to a seventh invention, in the fourth invention,
When detecting that the transmission capability of the network has dropped across the second threshold value smaller than the first threshold value in the detection step, the terminal changes the direction to decrease the target amount in the target amount change step,
In the control step, the server controls the transmission speed to decrease in accordance with the target amount being changed in the decreasing direction.
[0034]
In the seventh aspect, when the transmission capacity changes across the second threshold, the target amount is decreased by the terminal. The server follows the decrease in the target amount by reducing the transmission rate.
[0035]
In an eighth aspect based on the seventh aspect,
The second threshold value is a value corresponding to a transmission capability at which a transfer loss of stream data starts to occur.
[0036]
In the eighth aspect of the invention, when the transmission capacity declines and stream data transfer loss begins to occur, the transmission speed is reduced. This is to prevent the lost data from being retransmitted.
[0037]
Here, when reducing the transmission rate, the server must skip frame transmission at a frequency corresponding to the decrease rate. When a frame is skipped, the quality of video and audio obtained by playing back the terminal is degraded. In order to suppress this deterioration in quality, in the ninth invention, a frame that is not in time for the reproduction time is selected as a skipped frame. In the following tenth invention, as a frame to be skipped, a frame with low importance and a frame with high importance but not in time for the reproduction time are selected.
[0038]
In a ninth aspect based on the eighth aspect,
In the target amount changing step, when the terminal changes in a direction to decrease the target amount, in the control step, the server sequentially compares the reproduction time of each frame constituting the stream to be transmitted with the current time, thereby reproducing the reproduction time. Is characterized by skipping transmission of frames older than the current time, thereby controlling the transmission rate in a decreasing direction.
[0039]
In the eleventh aspect of the invention, frames that do not meet the playback time are selectively skipped, so that deterioration in quality due to a decrease in transmission speed can be suppressed as compared with random skipping.
[0040]
In a tenth aspect based on the eighth aspect,
In the target amount changing step, when the terminal changes in a direction to decrease the target amount, in the control step, the server sequentially compares the importance of each frame constituting the stream to be transmitted with the reference value,
For frames whose importance is less than the reference value, all transmissions are skipped,
For frames whose importance is greater than or equal to the reference value, each playback time is sequentially compared with the current time, and transmission is skipped only when the playback time is older than the current time, thereby controlling the transmission speed in a decreasing direction. It is characterized by doing.
[0041]
In the tenth aspect of the invention, a frame with low importance and a frame with high importance but not in time for the reproduction time are selectively skipped, so the transmission rate is higher than when skipping randomly. It is possible to suppress the deterioration of the quality due to the decrease in the quality.
[0042]
Here, as in the tenth aspect of the invention, a method that considers the importance in addition to whether or not it is in time for the reproduction time when selecting a frame to be skipped is typically used for an MPEG video frame. Used. In this case, when the transmission speed is reduced, the P and B frames are skipped as low importance frames, while the I frame is skipped as a high importance frame unless it is not in time for the playback time. Therefore, quality degradation of the reproduced image due to a decrease in transmission speed can be minimized. In the case of an MPEG audio frame, there is no difference in importance between frames, so it is only necessary to consider whether or not it is in time for the playback time.
[0043]
An eleventh invention is a system comprising a server that transmits stream data through a network and a terminal that reproduces the stream data while receiving the data.
The terminal
A target amount determining means for determining a target amount of stream data to be accumulated in its own buffer in relation to its own buffer capacity and network transmission capability;
Arbitrarily determine the delay time from writing the head data of the stream to its own buffer until reading the data and starting playback within a range not exceeding the value obtained by dividing the buffer capacity by the transmission capacity Delay time determining means, and
Means for notifying the server of the determined target time and delay time;
The server includes control means for controlling the transmission speed based on the notified target amount and delay time when transmitting stream data to the terminal through the network.
[0044]
A twelfth aspect of the invention is a terminal that is used together with a server that transmits stream data over a network and that plays back the stream data while receiving the stream data.
The server is equipped with a control means for controlling the transmission speed based on the notified target amount and delay time when transmitting stream data to the terminal through the network,
A target amount determining means for determining a target amount of stream data to be accumulated in its own buffer in relation to its own buffer capacity and network transmission capability;
Arbitrarily determine the delay time from writing the head data of the stream to its own buffer until reading the data and starting playback within a range not exceeding the value obtained by dividing the buffer capacity by the transmission capacity Delay time determining means, and
Means for notifying the server of the determined target time and delay time.
[0045]
A thirteenth aspect of the invention is a server that is used together with a terminal that reproduces while receiving stream data, and that transmits the stream data through a network.
On the device,
A target amount determining means for determining a target amount of stream data to be accumulated in its own buffer in relation to its own buffer capacity and network transmission capability;
Arbitrarily determine the delay time from writing the head data of the stream to its own buffer until reading the data and starting playback within a range not exceeding the value obtained by dividing the buffer capacity by the transmission capacity Delay time determining means, and
A means to notify the server of the determined target time and delay time is provided.
When transmitting stream data to the terminal through the network, the control means for controlling the transmission speed based on the notified target amount and delay time,
The control means controls the transmission speed so that the amount of stream data accumulated in the buffer of the terminal changes without exceeding the target amount in the vicinity of the target amount.
[0046]
A fourteenth invention is a program describing a streaming method as in the first invention.
[0047]
A fifteenth aspect of the invention is a recording medium on which a program like the fourteenth aspect of the invention is recorded.
[0048]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings. FIG. 1 is a block diagram showing a configuration example of a server client system that executes a streaming method according to an embodiment of the present invention. In FIG. 1, the system includes a
[0049]
FIG. 2 is a block diagram showing the configuration of the
[0050]
The transmission /
[0051]
Information from the terminal 102 received by the transmission /
[0052]
FIG. 3 is a block diagram showing a configuration of the
[0053]
A stream received by the transmission /
[0054]
A terminal control program is stored in the
[0055]
The operation of the system configured as described above will be described below. FIG. 4 is a sequence diagram for explaining the overall operation of the system of FIG. FIG. 4 shows a transmission / reception layer and a control layer on the
[0056]
First, the overall operation of this system will be described with reference to FIG. In FIG. 4, the command “SETUP” is first transmitted from the terminal 102 to the
[0057]
When “OK” is returned from the
[0058]
When “OK” is returned from the
[0059]
Thereafter, the command “TEARDOWN” is transmitted from the terminal 102 to the
When “OK” is returned from the
[0060]
The above is an overview of the overall operation of the system, and as long as it has been described above, the operation of the system is the same as the conventional one. The operation of this system differs from the conventional one in the following two points (1) and (2).
(1) Parameters “S_target” and “T_delay” are attached to the command “SETUP” from the terminal 102 to the
[0061]
In the above (1), “S_target” is a target value of the amount of data stored in the buffer by the terminal 102, and the total capacity of the buffers (
[0062]
Further, “T_delay” is a time from when the terminal 102 writes the head data to the buffer until the data is read and decoding is started (that is, cue delay time), and “S_target” is a transmission speed (described later). The value obtained by dividing by is determined as an arbitrary value within a range not exceeding the maximum value. That is, although the condition “within a range not exceeding the value obtained by dividing“ S_target ”by the transmission rate” is attached, the terminal 102 can determine “T_delay” independently of “S_target”.
[0063]
The “transmission speed” refers to the amount of information transmitted per unit time. For example, when the number of packets transmitted per unit time is determined, the amount of data packed in each packet is increased or decreased to increase the amount of information transmitted. The speed can be controlled. In addition, when the amount of data to be packed in each packet is determined, the transmission speed can be controlled by expanding / contracting the time interval between the packet and the next packet. Alternatively, the transmission speed can also be controlled by performing both simultaneously (that is, increasing or decreasing the amount of data packed in each packet and expanding or contracting the time interval between the packets and the next packet). In the present embodiment, the speed control is performed by increasing or decreasing the amount of data packed in each packet.
[0064]
(2) The terminal 102 can change “S_target” as needed during the delivery of the stream. In this case, the changed “S_target” is notified from the terminal 102 to the
[0065]
In (2) above, “S_target” is changed in accordance with the change in the transmission capability of the
The operation of this system is mainly different from the above two points.
[0066]
Next, a specific example of the overall operation of this system will be described in detail. In FIG. 4, before starting the stream reproduction, the terminal 102 extracts a parameter group specific to the terminal from the
[0067]
The
[0068]
Here, the essential meaning of S_target is that the streaming playback can be normally continued without interruption if the storage buffer amount of the terminal changes so that it does not exceed the vicinity of S_target in the streaming playback to be started from now. It is a value. As described above, when T_delay is large, the cue delay time becomes long, but it becomes strong against the transfer jitter of the
[0069]
In addition, instead of T_delay or in combination with T_delay, a filling amount S_delay that determines how many bytes of data are filled in the buffer in
[0070]
When the terminal 102 prepares S_target and T_delay (and / or S_delay), the terminal 102 issues a SETUP command that prompts the
[0071]
The two values of S_target and T_delay (and / or S_delay) are also passed to the packet generation circuit 406. The packet generation circuit 406 calculates an optimum rate control parameter using these values, and as a result, packets are generated and transmitted at a rate suitable for stream delivery to the terminal 102. When the preparation for transmitting the packet into the
[0072]
Next, the terminal 102 issues a PLAY command that prompts the
[0073]
At the end of stream reproduction, a TEARDOWN command is issued from the terminal 102 to the
[0074]
Hereinafter, the operation of the terminal 102 will be described in detail. The terminal 102 is a mobile phone that can be connected to the Internet, and has a function of detecting electric field strength (received radio wave strength). FIG. 5 is a flowchart showing the operation of the
[0075]
Here, the processing content of the said step S101 is demonstrated concretely. FIG. 6 is a diagram showing the contents stored in the
[0076]
The three
S_target3 <S_target1 <S_target2 ≦ S_max On the other hand, the value T_delay is determined not to exceed the value obtained by dividing the value S_max by the effective transmission capability of the
[0077]
As an example, if S_max is 512 (KB), S_target1 = 256 (KB), S_target2 = 384 (KB), S_target3 = 128 (KB), and the like. Further, assuming that the effective transmission capacity of the
[0078]
In step S101, S_target1 as an initial value and a value T_delay are read from the
[0079]
Here,
[0080]
In FIG. 5 again, the terminal 102 attaches the S_target and T_delay determined in step S101 to the SETUP command and transmits them to the server 101 (step S102). In response, a stream is sent from the
[0081]
Next, the terminal 102 receives a stream sent from the
[0082]
Next, the terminal 102 determines whether or not the time T_delay has elapsed from the start of buffering (step S104). If the determination result is negative, the terminal 102 waits until it becomes affirmative. If the determination result in step S104 is affirmative, the terminal 102 starts an operation of reading a stream from the buffer and decoding / reproducing it (step S105). Specifically, in FIG. 3, the
[0083]
Next, the terminal 102 determines whether or not the transmission capability of the
[0084]
In this case, specifically, as shown in FIG. 3, information regarding transmission capability is sent to the
[0085]
Alternatively, when the host computer that manages the
[0086]
If the determination result of step S106 is affirmative, the terminal 102 determines a new S_target (step S107) and transmits it to the server 101 (step S108). On the other hand, if the determination result of step S106 is negative, steps S107 and S108 are skipped and step S109 (described later) is executed.
[0087]
Here, the processing contents of steps S106 and S107 will be described in detail. Hereinafter, a case where the terminal 102 is a mobile phone and S_target is changed according to a change in electric field strength will be described. FIG. 7 is a schematic diagram showing a distribution of electric field strength in a certain area and a change in transmission capability accompanying the movement of the terminal. FIG. 7A shows an electric field strength distribution in an area including three relay stations B1 to B3. In FIG. 7A, concentric circles centering on the relay stations B1 to B3 are equi-electric field curves that can connect points having the same electric field strength.
[0088]
For example, the electric field strength is “strong” in the
[0089]
Now, the terminal 102 is about to move from the vicinity of the relay station B1 to the vicinity of the relay B2 along the route indicated by the
[0090]
The terminal 102 that moves as described above determines that the transmission capability of the
[0091]
In general, the threshold A is a value approximately between the maximum transmission capability that can be realized in the
[0092]
The new S_target is determined as follows by referring to the table 601 (FIG. 6) in the
[0093]
Next, the terminal 102 determines whether or not the electric field strength after the change is “medium” (step S203). If the determination result is affirmative, the terminal 102 determines a new S_target as S_target2 (step S204). If the determination result of step S203 is negative, the process jumps to step S204 and proceeds to step S205.
[0094]
Next, the terminal 102 determines whether or not the changed electric field strength is “weak / out of range” (step S205). If the determination result is affirmative, the terminal 102 determines a new S_target as S_target3 (step S206). Thereafter, the flow returns to the flow of FIG. If the determination result of step S205 is negative, the process jumps to step S206 and returns to the flow of FIG.
[0095]
Therefore, when the terminal 102 moves along the
[0096]
In FIG. 5 again, when the terminal 102 transmits a new S_target to the
[0097]
Next, the terminal 102 determines whether or not to end the streaming reproduction (step S109). When the terminal 102 ends, the terminal 102 transmits the command TEARDOWN to the
[0098]
Next, the operation of the
This packetization is performed in units of frames.
[0099]
First, an overview of stream transmission speed control performed by the
[0100]
FIG. 9 shows how the buffer occupancy approaches S_target. FIG. 10 shows how the buffer occupancy approaches S_target2 when the value of S_target is changed to a larger value (S_target2) while the buffer occupancy is in the vicinity of S_target. ing. FIG. 11 shows a state in which the buffer occupancy approaches S_target3 when the value of S_target is changed to a smaller value (S_target3) while the buffer occupancy is in the vicinity of S_target. ing.
[0101]
9 to 11, “S_max” is the total buffer capacity of the terminal 102, and “Sum” is the buffer occupation amount. “Delta (0, 1, 2,...)” Indicates the amount of data that the
[0102]
When the
[0103]
In FIG. 9, the packet (i = 0) transmitted first by the
[0104]
On the other hand, at time t = T_delay before the third packet (i = 2) is sent, a process of reading and decoding data from the buffer is started. Since decoding is performed on a frame basis, L0, L1, L2,... Are subtracted from Sum every fixed period Tfrm after t = T_delay.
[0105]
That is, after the time t = 0, the buffer occupancy Sum is gradually increased by adding delta0, delta1,... Every period Ts. On the other hand, L0, L1, L2,... Are subtracted every cycle Tfrm after time t = T_delay. Accordingly, during the period until the Sum reaches the target value S_target, the amount of data packed in one packet is made larger than the standard (more generally, the transmission speed is increased), and the writing speed to the buffer is increased. From then on, if the amount of data packed in one packet is returned to the standard and the writing speed and the reading speed are balanced, Sum can be shifted in the vicinity of the target value S_target. It becomes possible.
[0106]
When such transmission speed control is performed, as shown in FIGS. 10 and 11, even when the target value S_target is changed to a new target value (S_target2, 3) in the middle, Sum is changed to the new target value (S_target2). , 3) in the vicinity.
[0107]
That is, in FIG. 10, when S_target is changed to a larger value (S_target2) in a state where Sum is transitioning in the vicinity of target value S_target,
[0108]
In FIG. 11, when S_target is changed to a smaller value (S_target3) while Sum is transitioning in the vicinity of the target value S_target, the
[0109]
Next, transmission rate control by the
[0110]
When the determination result of step S302 is negative, the
[0111]
In step S306, it is determined whether or not to continue the speed control operation. If the determination result is affirmative, the process returns to step S301 and the same operation as described above is repeated. On the other hand, if the determination result is negative, the operation is terminated. The above is an example of transmission speed control performed by the
[0112]
By the way, in the example of FIG. 12, the terminal 102 detects its own buffer occupation amount and notifies the
[0113]
On the other hand, in another example described below (see FIGS. 13 and 14), the buffer occupancy is changed in the vicinity of S_target by performing transmission rate control based on the buffer occupancy at a certain time in the future. It becomes possible to make it. In this case, the
[0114]
That is, in FIG. 2, the
[0115]
The
[0116]
Hereinafter, with regard to a specific operation example in which the
[0117]
In FIG. 9, S_max is the maximum value of the effective accumulation amount of the buffer in the terminal 102 (this is simply called “total capacity of the buffer”), and S_target is accumulated in the buffer in the terminal 102 in the current streaming. T_delay is a set value for the cue delay time. The meaning of each parameter has already been described. In the following description, it is assumed that S_target and T_delay are notified from the terminal 102.
[0118]
In the present embodiment, in order to facilitate understanding, an example in which packets are generated / distributed every fixed time period Ts (packet distribution at a time corresponding to i = n: n is an integer) is shown. In addition, when a packet is delivered at a time corresponding to i = n (t = i * Ts), the accumulation amount Sum in the
[0119]
FIG. 13 and FIG. 14 are flowcharts showing another example of the transmission control algorithm performed by the
[0120]
In FIG. 9, the
[0121]
Here, the terminal 102 determines the values of the parameters S_target and T_delay and notifies the result to the
[0122]
Next, each variable is initialized (steps S402 and S403). The meaning of each variable will be described later with reference to FIG. When the initialization is completed, processing after step S404, that is, processing for generating a packet with the function mkPacket and sending it to the
[0123]
Next, a detailed algorithm of the function mkPacket shown in step S404 will be described. First, each variable will be described. Sum is the total amount of data stored in the
[0124]
In FIG. 14, the function mkPacket is roughly divided into two algorithms: a packet generation algorithm A1 and a decoding amount calculation algorithm A2. In the former, in the first step (S501), the
[0125]
Here, deltaMax is the inequality shown in FIG.
(DeltaMax + hdr) / Ts <NetworkRate
Is the maximum value of the amount of data that can be distributed to the terminal within the period Ts, and can be calculated from the effective transfer rate (transmission capability) of the
Then, it is determined whether or not L is greater than zero.
[0126]
If the determination result in step S505 is negative, that is, if L = 0, the
[0127]
As the packet generation by the above loop is repeated, the values of Sum and delta increase gradually. If it is determined in step S502 that Sum or delta has become sufficiently large, the
[0128]
In the decoding amount calculation algorithm A2, in the first step (S508), it is determined whether i * Ts is equal to or greater than grid. The purpose of step S508 is to determine whether or not it is time to start decoding in the
[0129]
If the determination result of step S508 is negative, the
[0130]
In step S511 in the above loop, Tfrm is added to dts every time one frame is decoded, and this embodiment uses an encoding method that generates frames with a fixed time interval Tfrm. It comes from that. In step S512, the
[0131]
With the above algorithm, as shown in FIG. 9, the buffer occupancy Sum can be changed within the terminal 102 so that it is always in the vicinity of S_target and does not exceed S_target. Therefore, even if there are a plurality of types of
[0132]
In this example, a packet is generated with a pattern in which a plurality of frames are inserted into one packet as shown in FIG. 15A. Instead, one frame is included in one packet as shown in FIG. 15B. It is also possible to generate a packet with a pattern for inserting. In this case, in step S502 in FIG.
delta + (L + hdr) <= deltaMax
And the latter half of step S504
delta + = (L + hdr)
Just do it.
[0133]
Further, in the present embodiment, for the sake of simplicity, an encoding method for generating frames at a fixed time interval Tfrm is used. However, an encoding method to be used—for example, MPEG4 video (ISO / IEC 14496-2) — If the decoding amount calculation algorithm A2 is designed according to the above, it goes without saying that it is not always necessary to generate frames at fixed time intervals. Further, the algorithm does not necessarily need to handle data in units of frames. For example, it may be an algorithm that handles data in units of slices or packs of MPEG1 or MPEG2 system streams.
[0134]
On the other hand, when the value of S_target is changed halfway in step S502 of FIG. 14, the present algorithm instantly generates a packet with the changed new S_target as a target. The state of buffer transition when the value of S_target is changed in the middle is shown in FIGS. In FIG. 10, when S_target is changed to S_target2 at the time of i = 3 (S_target <S_target2 ≦ S_max), a large amount of frame data is packetized for a while after the change (delta3 and delta4 in the figure). Sum reaches the vicinity of the new target value S_target2.
[0135]
As shown in FIG. 11, when S_target is changed to S_target3 at the time of i = 2 (S_target3 <S_target), a small amount (delta4) or 0 (delta3) of frame data is packetized. On the other hand, Sum is consumed by decoding, so that Sum reaches near the new target value S_target3. If such a mechanism is used, the buffer occupancy Sum in the terminal 102 can be dynamically increased or decreased according to the transmission capability of the network 103 (or the radio wave reception state of the terminal 102), as will be described below. Application becomes possible.
[0136]
In FIG. 7A, a case where a user having a mobile phone 701 (corresponding to the terminal 102 in FIG. 1) moves from the area of the relay station B1 to the area of the relay station B2 as indicated by an
[0137]
In FIG. 7B, it is assumed that the user holding the
[0138]
When the user moves to reach the distance d2, the transmission capability falls below the threshold value B, and packet transfer loss starts to occur. At this time, the
[0139]
For example, when the
[0140]
When the user moves to reach the distance d3, the transmission capability falls below the threshold C, and packet transfer becomes difficult for a moment. However, when the user further moves to reach the distance d4, the transmission capability exceeds the threshold value B, and the handover of the task for accepting the call is completed, so that the
[0141]
By the way, as shown in FIG. 11, when the set value of S_target is changed to a smaller value in the middle of stream distribution, the judgment sentence in step S502 in the algorithm of FIG. There may be cases where it cannot be sent. When such a case frequently occurs, even when the corner packet is delivered to the terminal 102, the time (Presentation Time) at which the frame data in the packet should be reproduced has passed, and the data is wasted. Sometimes. In such a case, skipping the frame data for which the playback time has passed is more efficient as long as unnecessary data does not flow through the
[0142]
FIG. 16 is a flowchart showing another example of the function mkPacket in step S404 of FIG. The function mkPacket in FIG. 16 includes steps (S601 and S602) for skipping the transmission of data past the reproduction time when the
[0143]
If this determination result is true, the
[0144]
The algorithm shown in FIG. 16 is a sufficiently effective technique when there is no difference in priority (importance) between frames as in MPEG audio. However, in MPEG video, as already explained in the introduction of the conventional example, a meaningful image can be reconstructed by itself if it is an I frame. Without a reference frame, a meaningful image cannot be reconstructed. In this case, when performing frame decimation in the algorithm of FIG. 16, while preferentially transmitting I frames in time for playback time, skipping all P and B frames allows the transfer rate of the
[0145]
FIG. 17 is a flowchart showing yet another example of the function mkPacket in step S404 of FIG. In the function mkPacket of FIG. 17, when the
[0146]
Accordingly, in the algorithm of FIG. 17, steps S701 and S702 are added and step S505 is replaced with S505 ′ as compared with FIG.
[0147]
In order to execute the algorithm of FIG. 17, a function for notifying the
[0148]
In FIG. 17 again, when the mkPacket function is called, step S701 is executed prior to step S501. In step S <b> 701, the server 101 (the
[0149]
In step S505 ′, the priority of the next frame is detected. In subsequent step S702, it is determined whether the priority of the data of the frame is high and the slow flag is true. If this determination result is affirmative, that is, if the slow flag indicating that the transfer speed of the
[0150]
As described above, according to the present embodiment, the terminal 102 determines a target amount according to its own buffer capacity and the transmission capability of the
[Brief description of the drawings]
FIG. 1 is a block diagram illustrating a configuration example of a server client system that executes a streaming method according to an embodiment of the present invention.
FIG. 2 is a block diagram illustrating a configuration of the
FIG. 3 is a block diagram illustrating a configuration of the
4 is a sequence diagram for explaining the overall operation of the system of FIG. 1. FIG.
FIG. 5 is a flowchart showing an operation of the
6 is a diagram showing the contents stored in the
FIG. 7 is a schematic diagram showing an electric field intensity distribution (A) in a certain area and a change in transmission capability (B) accompanying the movement of the terminal.
FIG. 8 is a flowchart showing details of step S107 in FIG. 5;
9 is a diagram illustrating how the buffer occupancy of the terminal 102 changes (approaching S_target) according to transmission speed control performed by the
FIG. 10 shows a state in which the terminal 102 performs transmission speed control performed by the
11 shows a state in which the terminal 102 is subjected to transmission speed control performed by the
12 is a flowchart showing an example of a transmission rate control algorithm performed by the
FIG. 13 is a flowchart showing another example of a transmission rate control algorithm performed by the
14 is a flowchart illustrating an example of a function mkPacket in step S404 in FIG.
15 is a diagram illustrating a configuration example of a packet generated by the
16 is a flowchart showing another example of the function mkPacket in step S404 in FIG.
FIG. 17 is a flowchart showing still another example of the function mkPacket in step S404 in FIG.
FIG. 18 is a block diagram showing another configuration example of the server client system that executes the streaming method according to the embodiment of the present invention.
FIG. 19 is a diagram for explaining a conventional streaming method (A is a video frame, B is a transition of buffer occupancy, and C is a configuration example of a conventional terminal).
FIG. 20 is a block diagram illustrating a configuration example of a server / client system that executes a conventional streaming method;
FIG. 21 is a diagram for explaining how the transition of buffer occupancy changes by adding a reception buffer (A is before addition and B is after addition);
[Explanation of symbols]
101 server
102 terminals
103 network
402,507 Transmission / reception module
404 RAM
405 generation module
406 Packet generation circuit
407 Read buffer
408 Packet generation buffer
409 Transmission buffer
410,506 Network controller
411 Storage device
412 and 503 CPU
413, 502 ROM
505 Receive buffer
508 Decoder buffer
509 decoder
510 Playback module
511 Display device
Claims (15)
端末が、自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定ステップ、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、端末が、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定ステップ、
決定した目標時間および遅延時間を、端末がサーバに通知するステップ、
サーバが端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御ステップを備える、ストリーミング方法。A streaming method in which a server transmits stream data to a terminal through a network, and the terminal reproduces while receiving the stream data,
A target amount determination step in which the terminal determines a target amount of stream data to be stored in its buffer in relation to its buffer capacity and network transmission capability;
The delay time from when the terminal writes the head data of the stream to its own buffer until the data is read and playback is started, as long as it does not exceed the value obtained by dividing the buffer capacity by the transmission capacity Determine the delay time determination step,
The terminal notifies the server of the determined target time and delay time;
A streaming method comprising a control step of controlling a transmission rate based on a notified target amount and delay time when a server transmits stream data to a terminal through a network.
端末のバッファに蓄積されているストリームデータの量が、当該目標量の近傍において当該目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする、請求項1に記載のストリーミング方法。In the control step, the server
The transmission rate is controlled so that the amount of stream data accumulated in a buffer of a terminal does not exceed the target amount in the vicinity of the target amount. Streaming method.
前記検出ステップでの検出結果に応じて、端末が当該目標量を変更する目標量変更ステップ、および
変更後の目標量を、端末がサーバに通知するステップをさらに備え、
前記制御ステップにおいて、サーバは、変更後の目標量の通知を受けると、端末のバッファに蓄積されるストリームデータの量が、当該変更後の目標量の近傍において当該変更後の目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする、請求項1に記載のストリーミング方法。A detection step in which the terminal detects that the transmission capability of the network has changed across a predetermined threshold;
According to the detection result in the detection step, the terminal further includes a target amount changing step in which the terminal changes the target amount, and a step in which the terminal notifies the server of the changed target amount,
In the control step, when the server receives the notification of the changed target amount, the amount of stream data accumulated in the terminal buffer exceeds the changed target amount in the vicinity of the changed target amount. The streaming method according to claim 1, wherein the transmission speed is controlled so as to make a transition without any change.
前記制御ステップにおいて、サーバは、当該目標量が増加されたのに応じて、当該送信速度を上昇させる向きに制御することを特徴とする、請求項4に記載のストリーミング方法。When detecting that the transmission capability of the network has dropped across the first threshold in the detection step, the terminal changes the direction to increase the target amount in the target amount change step,
5. The streaming method according to claim 4, wherein, in the control step, the server controls the transmission speed to increase in accordance with an increase in the target amount.
前記制御ステップにおいて、サーバは、当該目標量が減少方向に変更されたのに応じて、当該送信速度を低下させる向きに制御することを特徴とする、請求項4に記載のストリーミング方法。When the detection step detects that the transmission capability of the network has dropped across the second threshold value that is smaller than the first threshold value, the terminal changes the direction so as to decrease the target amount in the target amount change step. ,
5. The streaming method according to claim 4, wherein, in the control step, the server controls the transmission speed to decrease in accordance with the target amount being changed in a decreasing direction.
重要度が基準値未満であるフレームについては、全て送信をスキップし、
重要度が基準値以上であるフレームについては、それぞれの再生時刻を現在時刻と逐次比較して、再生時刻が現在時刻よりも古いものだけ送信をスキップし、それによって当該送信速度を低下方向に制御することを特徴とする、請求項8に記載のストリーミング方法。In the target amount changing step, when the terminal changes in a direction to decrease the target amount, in the control step, the server sequentially compares the importance of each frame constituting the stream to be transmitted with a reference value,
For frames whose importance is less than the reference value, all transmissions are skipped,
For frames whose importance is greater than or equal to the reference value, each playback time is sequentially compared with the current time, and transmission is skipped only when the playback time is older than the current time, thereby controlling the transmission speed in a decreasing direction. The streaming method according to claim 8, wherein:
端末は、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段を備え、
サーバは、端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段を備える、システム。A system comprising a server that transmits stream data over a network and a terminal that reproduces the stream data while receiving the data,
The terminal
A target amount determining means for determining a target amount of stream data to be accumulated in its own buffer in relation to its own buffer capacity and network transmission capability;
Arbitrarily determine the delay time from writing the head data of the stream to its own buffer until reading the data and starting playback within a range not exceeding the value obtained by dividing the buffer capacity by the transmission capacity A delay time determining means, and means for notifying a server of the determined target time and delay time;
The server comprises control means for controlling a transmission speed based on the notified target amount and delay time when transmitting stream data to a terminal through a network.
サーバには、端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段が備わり、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段を備える、端末。A terminal that is used together with a server that transmits stream data through a network and that plays back the stream data while receiving the stream data,
The server is equipped with a control means for controlling the transmission speed based on the notified target amount and delay time when transmitting stream data to the terminal through the network,
A target amount determining means for determining a target amount of stream data to be accumulated in its own buffer in relation to its own buffer capacity and network transmission capability;
Arbitrarily determine the delay time from writing the head data of the stream to its own buffer until reading the data and starting playback within a range not exceeding the value obtained by dividing the buffer capacity by the transmission capacity A terminal comprising delay time determining means and means for notifying a server of the determined target time and delay time.
端末には、
自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定手段、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定手段、および
決定した目標時間および遅延時間をサーバに通知する手段が備わり、
端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御手段を備え、
前記制御手段は、端末のバッファに蓄積されているストリームデータの量が、当該目標量の近傍において当該目標量を超えることなく遷移するように、当該送信速度を制御することを特徴とする、サーバ。A server that is used together with a terminal that reproduces while receiving stream data and that transmits the stream data through a network,
On the device,
A target amount determining means for determining a target amount of stream data to be accumulated in its own buffer in relation to its own buffer capacity and network transmission capability;
Arbitrarily determine the delay time from writing the head data of the stream to its own buffer until reading the data and starting playback within a range not exceeding the value obtained by dividing the buffer capacity by the transmission capacity A delay time determining means, and means for notifying the server of the determined target time and delay time;
When transmitting stream data to the terminal through the network, the control means for controlling the transmission speed based on the notified target amount and delay time,
The control means controls the transmission speed so that the amount of stream data stored in the buffer of the terminal changes without exceeding the target amount in the vicinity of the target amount. .
端末が、自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定ステップ、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、端末が、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定ステップ、
決定した目標時間および遅延時間を、端末がサーバに通知するステップ、
サーバが端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御ステップを備えるストリーミング方法を記述した、プログラム。A program that describes a streaming method in which a server transmits stream data to a terminal through a network and the terminal plays back the stream data while receiving the stream data,
A target amount determination step in which the terminal determines a target amount of stream data to be stored in its buffer in relation to its buffer capacity and network transmission capability;
The delay time from when the terminal writes the head data of the stream to its own buffer until the data is read and playback is started, as long as it does not exceed the value obtained by dividing the buffer capacity by the transmission capacity Determine the delay time determination step,
The terminal notifies the server of the determined target time and delay time;
A program describing a streaming method including a control step of controlling a transmission rate based on a notified target amount and delay time when a server transmits stream data to a terminal through a network.
端末が、自身のバッファ容量とネットワークの伝送能力とに関連して、自身のバッファに蓄積すべきストリームデータの目標量を決定する目標量決定ステップ、
当該バッファ容量を当該伝送能力で除して得られる値を超えない範囲内で任意に、端末が、自身のバッファにストリームの先頭データを書き込んでから当該データを読み出して再生開始するまでの遅延時間を決定する遅延時間決定ステップ、
決定した目標時間および遅延時間を、端末がサーバに通知するステップ、
サーバが端末へネットワークを通じてストリームデータを送信する際に、通知された目標量および遅延時間に基づいて送信速度を制御する制御ステップを備えるストリーミング方法が記述されたプログラムを記録した、記録媒体。A recording medium that records a program in which a server transmits stream data to a terminal through a network and a terminal describes a streaming method for reproducing the stream data while receiving the stream data,
A target amount determination step in which the terminal determines a target amount of stream data to be stored in its buffer in relation to its buffer capacity and network transmission capability;
The delay time from when the terminal writes the head data of the stream to its own buffer until the data is read and playback is started, as long as it does not exceed the value obtained by dividing the buffer capacity by the transmission capacity Determine the delay time determination step,
The terminal notifies the server of the determined target time and delay time;
A recording medium on which is recorded a program describing a streaming method including a control step of controlling a transmission speed based on a notified target amount and delay time when a server transmits stream data to a terminal through a network.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2001202147A JP4596693B2 (en) | 2000-07-06 | 2001-07-03 | Streaming method and system for executing the same |
Applications Claiming Priority (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2000-204632 | 2000-07-06 | ||
JP2000204632 | 2000-07-06 | ||
JP2001202147A JP4596693B2 (en) | 2000-07-06 | 2001-07-03 | Streaming method and system for executing the same |
Publications (3)
Publication Number | Publication Date |
---|---|
JP2002084339A JP2002084339A (en) | 2002-03-22 |
JP2002084339A5 JP2002084339A5 (en) | 2008-03-21 |
JP4596693B2 true JP4596693B2 (en) | 2010-12-08 |
Family
ID=26595476
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2001202147A Expired - Lifetime JP4596693B2 (en) | 2000-07-06 | 2001-07-03 | Streaming method and system for executing the same |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP4596693B2 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9477430B2 (en) | 2013-07-16 | 2016-10-25 | Globalfoundries Inc. | Adapting transfer rate of cached data to prevent stoppage of data transmission |
Families Citing this family (32)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8055894B2 (en) | 1999-11-09 | 2011-11-08 | Google Inc. | Process and streaming server for encrypting a data stream with bandwidth based variation |
FI118830B (en) * | 2001-02-08 | 2008-03-31 | Nokia Corp | Streaming playback |
US7299292B2 (en) | 2002-03-29 | 2007-11-20 | Widevine Technologies, Inc. | Process and streaming server for encrypting a data stream to a virtual smart card client system |
MXPA04012760A (en) | 2002-06-21 | 2005-03-23 | Thomson Licensing Sa | Ever-decreasing network qos requirements for stored video streaming in a mobile wireless interworking environment. |
AU2003252347A1 (en) | 2002-07-31 | 2004-03-11 | Sharp Kabushiki Kaisha | Data communication device, its intermittent communication method, program describing its method, and recording medium on which program is recorded |
US7877439B2 (en) * | 2003-04-17 | 2011-01-25 | Thomson Licensing | Data requesting and transmitting devices and processes |
WO2004102968A1 (en) * | 2003-05-13 | 2004-11-25 | Fujitsu Limited | Device for estimate buffer size, device for monitoring delivery quality, device for managing delivery quality, method for estimating buffer size, method for monitoring delivery quality, method for managing delivery quality, program for estimating buffer size, and program for monitoring delivery quality |
JP4909590B2 (en) * | 2003-06-11 | 2012-04-04 | 日本電気株式会社 | Media signal receiving device, transmitting device, and transmitting / receiving system |
KR20060096044A (en) * | 2003-10-16 | 2006-09-05 | 닛본 덴끼 가부시끼가이샤 | Medium signal transmission method, reception method, transmission/reception method, and device |
KR100601886B1 (en) | 2004-07-12 | 2006-07-19 | 삼성전자주식회사 | Method for controlling handover between a different kind of network |
KR20060065482A (en) * | 2004-12-10 | 2006-06-14 | 마이크로소프트 코포레이션 | A system and process for controlling the coding bit rate of streaming media data |
JP4773505B2 (en) * | 2005-03-07 | 2011-09-14 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Switching multimedia channels |
JP4643330B2 (en) | 2005-03-28 | 2011-03-02 | ソニー株式会社 | COMMUNICATION PROCESSING DEVICE, DATA COMMUNICATION SYSTEM, COMMUNICATION PROCESSING METHOD, AND COMPUTER PROGRAM |
JP4770248B2 (en) * | 2005-04-19 | 2011-09-14 | ソニー株式会社 | Information processing apparatus and method, program, and recording medium |
JP2007013675A (en) * | 2005-06-30 | 2007-01-18 | Sanyo Electric Co Ltd | Streaming distribution system and server |
JP4673411B2 (en) * | 2005-11-07 | 2011-04-20 | テレフオンアクチーボラゲット エル エム エリクソン(パブル) | Method and apparatus in a mobile communication network |
US8689016B2 (en) | 2005-12-02 | 2014-04-01 | Google Inc. | Tamper prevention and detection for video provided over a network to a client |
CN101502121A (en) * | 2006-09-11 | 2009-08-05 | 松下电器产业株式会社 | Image decoding device, image decoding method, image decoding system, and system LSI |
JP2008172515A (en) | 2007-01-11 | 2008-07-24 | Sony Corp | Transmitter and method, communication device, and program |
KR100780396B1 (en) * | 2007-06-18 | 2007-11-28 | 주식회사 셀런 | Traffic control method for iptv broadcasting service |
US8243924B2 (en) | 2007-06-29 | 2012-08-14 | Google Inc. | Progressive download or streaming of digital media securely through a localized container and communication protocol proxy |
JP4900317B2 (en) * | 2008-05-12 | 2012-03-21 | 富士通株式会社 | Frame transmitting apparatus, frame transmitting method, and frame transmitting program |
JP5171459B2 (en) * | 2008-07-29 | 2013-03-27 | キヤノン株式会社 | Stream data processing apparatus, stream data processing method, and stream data processing program |
US8204038B2 (en) * | 2009-01-13 | 2012-06-19 | Mediatek Inc. | Method for efficient utilization of radio resources in wireless communications system |
JP5342658B2 (en) * | 2009-03-06 | 2013-11-13 | アスペラ,インク. | Method and system for speed adaptation of I / O drive |
JP4931093B2 (en) * | 2010-01-18 | 2012-05-16 | ブラザー工業株式会社 | Delivery speed control device, delivery speed control method, and delivery speed control program |
EP2410743A1 (en) * | 2010-07-23 | 2012-01-25 | Alcatel Lucent | Method for transferring video chunks, server entity, client entity and intermediate network entity realizing such a method |
JP6280644B2 (en) * | 2013-07-08 | 2018-02-14 | 華為技術有限公司Huawei Technologies Co.,Ltd. | Method, device and system for controlling video playback |
WO2015011841A1 (en) | 2013-07-26 | 2015-01-29 | 富士通株式会社 | Encoding device, encoding method, and encoding program |
JP6432976B2 (en) | 2014-11-19 | 2018-12-05 | 日本電気株式会社 | Data transmission apparatus, data transmission method and program |
JP6515687B2 (en) * | 2015-06-03 | 2019-05-22 | 富士通株式会社 | Relay method, relay program and relay apparatus |
CN108810554B (en) | 2018-06-15 | 2021-06-22 | 腾讯科技(深圳)有限公司 | Scene image transmission method of virtual scene, computer device and storage medium |
Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0575666A (en) * | 1991-09-17 | 1993-03-26 | Toshiba Corp | Transmission flow control system |
JPH07170290A (en) * | 1993-12-15 | 1995-07-04 | Sony Corp | Communication system |
JPH08237650A (en) * | 1994-10-21 | 1996-09-13 | At & T Corp | Synchronizing system for data buffer |
JPH09298734A (en) * | 1996-04-30 | 1997-11-18 | Matsushita Electric Ind Co Ltd | Video on-demand system |
JPH1041953A (en) * | 1996-07-23 | 1998-02-13 | Hitachi Ltd | Congestion control system |
JPH10336626A (en) * | 1997-05-30 | 1998-12-18 | Nec Software Ltd | Transfer method and transfer device for video data |
JPH1168880A (en) * | 1997-08-22 | 1999-03-09 | Canon Inc | Data communication equipment, method, system and storage medium |
JPH11187367A (en) * | 1997-12-19 | 1999-07-09 | Nec Corp | Video transmitter, video receiver and video transmitting system using these |
JPH11205390A (en) * | 1998-01-14 | 1999-07-30 | Toshiba Corp | Transmission system, terminal equipment, server system and storage medium |
JP2000183873A (en) * | 1998-12-11 | 2000-06-30 | Fujitsu Ltd | Data transfer method |
JP2001257715A (en) * | 2000-03-09 | 2001-09-21 | Nippon Hoso Kyokai <Nhk> | Storage transmission terminal |
-
2001
- 2001-07-03 JP JP2001202147A patent/JP4596693B2/en not_active Expired - Lifetime
Patent Citations (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH0575666A (en) * | 1991-09-17 | 1993-03-26 | Toshiba Corp | Transmission flow control system |
JPH07170290A (en) * | 1993-12-15 | 1995-07-04 | Sony Corp | Communication system |
JPH08237650A (en) * | 1994-10-21 | 1996-09-13 | At & T Corp | Synchronizing system for data buffer |
JPH09298734A (en) * | 1996-04-30 | 1997-11-18 | Matsushita Electric Ind Co Ltd | Video on-demand system |
JPH1041953A (en) * | 1996-07-23 | 1998-02-13 | Hitachi Ltd | Congestion control system |
JPH10336626A (en) * | 1997-05-30 | 1998-12-18 | Nec Software Ltd | Transfer method and transfer device for video data |
JPH1168880A (en) * | 1997-08-22 | 1999-03-09 | Canon Inc | Data communication equipment, method, system and storage medium |
JPH11187367A (en) * | 1997-12-19 | 1999-07-09 | Nec Corp | Video transmitter, video receiver and video transmitting system using these |
JPH11205390A (en) * | 1998-01-14 | 1999-07-30 | Toshiba Corp | Transmission system, terminal equipment, server system and storage medium |
JP2000183873A (en) * | 1998-12-11 | 2000-06-30 | Fujitsu Ltd | Data transfer method |
JP2001257715A (en) * | 2000-03-09 | 2001-09-21 | Nippon Hoso Kyokai <Nhk> | Storage transmission terminal |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9477430B2 (en) | 2013-07-16 | 2016-10-25 | Globalfoundries Inc. | Adapting transfer rate of cached data to prevent stoppage of data transmission |
Also Published As
Publication number | Publication date |
---|---|
JP2002084339A (en) | 2002-03-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4596693B2 (en) | Streaming method and system for executing the same | |
US7016970B2 (en) | System for transmitting stream data from server to client based on buffer and transmission capacities and delay time of the client | |
US10225620B1 (en) | System and method for effectuating selective ABR segment delivery for ABR bandwidth control | |
CN106464601B (en) | Channel bundling | |
US10587664B2 (en) | Systems and methods for controlling the encoding of a segmented media stream using segment transmit times | |
JP4857379B2 (en) | Predictive frame dropping to enhance quality of service of streaming data | |
US9544602B2 (en) | Wireless video transmission system | |
US7797723B2 (en) | Packet scheduling for video transmission with sender queue control | |
US7652994B2 (en) | Accelerated media coding for robust low-delay video streaming over time-varying and bandwidth limited channels | |
US7784076B2 (en) | Sender-side bandwidth estimation for video transmission with receiver packet buffer | |
JP4118232B2 (en) | Video data processing method and video data processing apparatus | |
US20190069038A1 (en) | System and method for providing fast abr startup with selective abr segment delivery | |
KR101263514B1 (en) | Communication processing device, and communication control method, and recording medium | |
KR100832537B1 (en) | Multimedia data streaming server and method for changing a traffic in response to network bandwidth condition | |
JP2008029005A (en) | Client device, communication system and data processing method | |
JP2008301309A (en) | Encoding rate control method, transmission apparatus to control encoding rate, program storage medium, and integrated circuit | |
JP6463041B2 (en) | Image processing apparatus, image processing method, and program | |
JP2008029006A (en) | Client device, communication system and data processing method | |
US20110137984A1 (en) | Method and apparatus for supporting multimedia streaming service | |
KR20020026250A (en) | Video signal encoding and buffer management | |
KR101038645B1 (en) | apparatus and method for prevention of underflow and overflow in streaming system | |
Kritzner et al. | Priority based packet scheduling with tunable reliability for wireless streaming | |
JP5522987B2 (en) | Transmission device, transmission method, and computer program | |
JP2002271740A (en) | Data input output device | |
JP2004023548A (en) | Distribution rate change method for streaming service, stream distribution server, stream distribution program, and information recording medium therefor |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080131 |
|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20080131 |
|
A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20100618 |
|
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: 20100831 |
|
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: 20100921 |
|
R150 | Certificate of patent or registration of utility model |
Ref document number: 4596693 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20131001 Year of fee payment: 3 |
|
SZ02 | Written request for trust registration |
Free format text: JAPANESE INTERMEDIATE CODE: R313Z02 |
|
S131 | Request for trust registration of transfer of right |
Free format text: JAPANESE INTERMEDIATE CODE: R313133 |
|
R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
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 |
|
EXPY | Cancellation because of completion of term |