(57)【要約】【課題】  ストリーミング再生中に再生開始時間の遅れが生じないようにする技術を提供する。【解決手段】  複数のチャプタに分けてデータを受信するバッファ部と、前記バッファ部を制御するバッファ制御部と、前記バッファ部に溜まった前記データを再生する再生部とを具備し、前記再生部が前記データを再生中に現在再生中の一つの前記チャプタの未再生データが所定分溜まった場合、この一つのチャプタとは別の前記チャプタに、前記バッファ制御部は前記バッファ部に前記データを受信させる映像表示装置。【選択図】  図３
2013110476.tif 000002
【特許請求の範囲】
【請求項１】
複数のチャプタに分けてデータを受信するバッファ部と、
前記バッファ部を制御するバッファ制御部と、
前記バッファ部に溜まった前記データを再生する再生部とを具備し、
前記再生部が前記データを再生中に現在再生中の一つの前記チャプタの未再生データが所定分溜まった場合、この一つのチャプタとは別の前記チャプタに、前記バッファ制御部は前記バッファ部に前記データを受信させる映像表示装置。
【請求項２】
前記現在再生中の一つの前記チャプタの未再生データが所定より少なくなった場合、この一つのチャプタとは別の前記チャプタに代えてこの一つのチャプタに、前記バッファ制御部は前記バッファ部に前記データを受信させる請求項１に記載の映像表示装置。
【請求項３】
前記別の前記チャプタの優先度を外部からの設定により選択できる設定手段を更に備えた請求項１に記載の映像表示装置。
【請求項４】
複数のチャプタに分けてデータをバッファ部で受信し、
前記バッファ部を制御し、
前記バッファ部に溜まった前記データを再生し、
前記データを再生中に現在再生中の一つの前記チャプタの未再生データが所定分溜まった場合、この一つのチャプタとは別の前記チャプタに、前記バッファ部に前記データを受信させるバッファ管理方法。
【請求項５】
データを配信する配信サーバと、
前記配信サーバから複数のチャプタに分けて前記データを受信するバッファ部と、
前記バッファ部を制御するバッファ制御部と、
前記バッファ部に溜まった前記データを再生する再生部とを具備し、
前記再生部が前記データを再生中に現在再生中の一つの前記チャプタの未再生データが所定分溜まった場合、この一つのチャプタとは別の前記チャプタに、前記バッファ制御部は前記バッファ部に前記データを受信させる映像表示システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、ストリーミングデータを再生可能な映像表示装置、バッファ管理方法および映像表示システムに関する。
【背景技術】
【０００２】
従来、配信されたストリーミングデータの未再生の部分において、ユーザが視聴したい場面を選択して再生する再生装置が開発されている。ストリーミング再生のバッファ管理をする技術が用いられている。
【０００３】
例えば、特許文献１に記載されているものは、クライアントに特定コンテンツデータを送信する前に、前記コンテンツのうちあらかじめ定められた区間内の部分データに加え、それらのデータの前後の先頭データをクライアントに送信する。
【０００４】
しかしながらここにある技術では、再生開始前に部分データを取得するものであり、再生開始時間の遅れが生じる懸念があるという問題があった。
【０００５】
よって、再生開始時間の遅れが生じないようにする技術へ要望があるが、かかる要望を実現するための手段は知られていない。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００６−２０１４７７号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明の実施の形態は、ストリーミング再生中に再生開始時間の遅れが生じないようにする技術を提供することを目的とする。
【課題を解決するための手段】
【０００８】
上記課題を解決するために、実施形態によれば映像表示装置は、複数のチャプタに分けてデータを受信するバッファ部と、前記バッファ部を制御するバッファ制御部と、前記バッファ部に溜まった前記データを再生する再生部とを具備し、前記再生部が前記データを再生中に現在再生中の一つの前記チャプタの未再生データが所定分溜まった場合、この一つのチャプタとは別の前記チャプタに、前記バッファ制御部は前記バッファ部に前記データを受信させる。
【図面の簡単な説明】
【０００９】
【図１】この発明の一実施形態を示すストリーミングデータを再生可能なシステムブロック図。
【図２】同実施形態の再生中のバッファ制御フローを示す図。
【図３】同実施形態の上限thresholdに達した状態を説明するために示す図。
【図４】同実施形態の下限thresholdを切った状態の例を示す図。
【図５】同実施形態に用いられるチャプタの優先度変更フローを示す図。
【図６】同実施形態のチャプタ優先度変更画面を示す図。
【図７】同他の形態に用いられる優先度変更時のプログレスバーを示す図。
【発明を実施するための形態】
【００１０】
以下、実施形態を図１乃至図７を参照して説明する。
【００１１】
図１は、実施形態にかかるストリーミングデータを再生可能なシステムブロック図である。なお、以下に説明する要素や構成あるいは機能は、ハードウェアで実現するものであってもよいし、マイクロコンピュータ（処理装置、ＣＰＵ）等、を用いてソフトウェアで実現するものであってもよい。
【００１２】
図１が示す映像表示システム３００はストリーミング配信サーバ１００と映像表示装置２００とから構成されている。映像表示装置２００は、ストリーミング配信サーバ１００からストリーミングデータを受信する通信装置１０と、受信されたストリーミングデータを一次保存するバッファ部(チャプタ分割数により必要に応じて複数個のバッファ領域を確保するが、ここではバッファ１、バッファ２として例示)と、ストリームを再生する映像再生装置１４と、ストリームを表示する表示装置１６と(例えば以上ハードウェア)、それらを制御する制御ソフトウェア２２から構成されている。この実施形態はこれらの制御ソフトウェア２２群の中でも、任意で指定できるチャプタの位置を管理するチャプタ管理部１７と、チャプタ管理と連動して、受信したデータがバッファ部のどちらのバッファのものかを管理し制御するバッファ制御部１８と、映像再生装置１４を制御する再生制御部２０とを利用して実施する。映像再生装置１４と再生制御部２０とで言わば再生部を構成している。
【００１３】
図２は再生中のバッファ制御を示すフローチャートである。下記フローチャートは図１のチャプタ管理部１７およびバッファ制御部１８を用いてバッファ部（バッファ１、バッファ２）を制御するものであり、これらの一連の処理を行っている間も映像再生装置１４では通常再生を継続している。配信サーバ１００よりのコンテンツのダウンロードを始めると以下のステップが開始される。また詳しくはコンテンツのデータを最後まで受信し終わるとステップＳ２−１において処理は終了となる。
【００１４】
ステップＳ２−１：  現在再生中のBuffer（バッファ１、またはバッファ２）にデータを受信する。
【００１５】
ステップＳ２−２：  受信したら、Bufferのデータ残量をチェックする。
【００１６】
ステップＳ２−３：  Bufferの残量が上限Thresholdを以上でなければ、ステップＳ２−１に戻り現在のデータ受信を継続する。図３のように、Bufferの残量が上限Threshold以上となっていた場合、ステップＳ２−４以下で次のチャプタのBuffer量をチェックする。
【００１７】
ステップＳ２−４：  次のチャプタの有無を確認する。次のチャプタが無ければステップＳ２−１に戻り現在再生中のデータ受信を続ける。
【００１８】
ステップＳ２−５：  次のチャプタがある場合は次のチャプタ用Buffer（バッファ２、またはバッファ１）の残量をチェックする。
【００１９】
ステップＳ２−６：  次のチャプタ用Bufferにも既に上限Threshold以上データがある場合、その次のBufferをチェックすべく、上限Threshold未満のBufferを見つけるまでステップＳ２−４からステップＳ２−６の処理を繰り返す。
【００２０】
ステップＳ２−７：  Buffer量が上限Threshold未満のチャプタを検出したら、現在のデータ受信を中止し、配信サーバ１００に指定チャプタからのデータ受信を要求する。
【００２１】
ステップＳ２−８：  指定チャプタ用のBufferにデータを受信する。
【００２２】
ステップＳ２−９：  データを受信したら、現在再生中Bufferのデータ残量をチェックする。
【００２３】
ステップＳ２−１０：  図４のように、現在再生中Bufferの残量が下限Thresholdを切っていた場合（ステップＳ２−９AのＹＥＳ）、現在のデータ受信を中止し、配信サーバ１００に対して現在再生中のデータ受信を要求し、再度上限Thresholdを超えるまで現在再生中のデータ受信を続ける（ステップＳ２−１以下）。
【００２４】
ステップＳ２−１１：  現在再生中Bufferの残量が下限Thresholdを切っていなかった場合（ステップＳ２−９AのNO）、現在データ受信中Bufferの優先度を調べる。
【００２５】
ステップＳ２−１２：  現在データ受信中Bufferの優先度に変化があった場合（ステップＳ２−１１AのNO）、ユーザによってバッファリングを行う優先度が変更されたと判断し、優先度最高のチャプタからのデータ受信を要求する。その後ステップＳ２−８の処理へ飛ぶ。
【００２６】
ステップＳ２−１３：  現在データ受信中Bufferの優先度に変化がなかった場合（ステップＳ２−１１AのYES）、現在データ受信中Bufferの残量を調べる。
【００２７】
ステップＳ２−１４：  現在データ受信中Bufferの残量が上限Threshold以上だった場合、ステップＳ２−４の処理へ飛ぶ。また、現在データ受信中Bufferの残量が上限Threshold以上でなかった場合、ステップＳ２−８の処理へ飛ぶ。
【００２８】
図３は、現在再生中のBuffer１（バッファ１、またはバッファ２）が上限Thresholdを超えた状態を表した図である。このような状態になると、クライアントはBuffer1で行っていた現在再生中のデータ受信をとりやめ、Buffer2（バッファ２または、バッファ１）で次チャプタのデータ受信を開始する。
【００２９】
図４は、次チャプタのデータ受信中に現在再生中Buffer１が下限Thresholdを切った状態を表した図である。このような状態になると、クライアントはBuffer2で行っていた次チャプタのデータ受信をとりやめ、Buffer1で現在再生中のデータ受信を再開する。
【００３０】
図５は、バッファリングの優先度を変える場合のフローチャートである。
【００３１】
ステップＳ５−１：  デフォルトではチャプタ番号順に若い優先度がつけられる。
【００３２】
ステップＳ５−２：  ユーザによって優先してバッファリングを行うチャプタが指定（選択）された場合である。
【００３３】
ステップＳ５−３：  このチャプタよりも優先度の高いチャプタの優先度を一つずつ下げる。
【００３４】
ステップＳ５−４：  指定されたチャプタの優先度を最高にする。
【００３５】
なおチャプタバッファリング中に優先度が変更された場合の処理は、上記図２の説明文中に記載した。
【００３６】
図６（ａ）〜（ｅ）は実際にチャプタの優先度を変更するための画面である。上記選択をするための設定手段であり、ユーザは例えばリモコンなどを用いて対話的に設定できる。
【００３７】
チャプタ優先度を変更するメニューを開くと画面上に、まず図６（ａ）のようなポップアップが表示され、優先度を上げたいチャプタを選択することができる (このとき、既に優先度が最高となっているチャプタAは選択することができない) 。
【００３８】
優先度を上げたいチャプタを選択すると、図６（ｂ）のように優先度を1つ上げるか、図６（ｃ）のように優先度を最高に上げるかを選択できる。優先度を1つあげた場合、図６（ｄ）のように、選択したチャプタの優先度が１つ上がる。優先度を最高に上げた場合、図６（ｅ）のように、選択したチャプタの優先度が最高に上がる。
【００３９】
図７は、バッファリングの優先度が変更された場合のプログレスバー表示を示したものである。本図は、図６（ａ）→図６（ｃ）→図６（ｅ）の順で選択された場合の表示状態である。チャプタCの優先度が最高となっているため、チャプタA,Bを飛ばし、先にチャプタCのバッファリングを行っている。
【００４０】
バッファリングする順序は、図１のチャプタ管理部１７でテーブルとして管理され、バッファ管理部１８はテーブルから優先順位の高いチャプタを選択してバッファリングを行う。指定が無い場合はチャプタ順通りにバッファリングを行う。
【００４１】
あらかじめ次チャプタのデータをバッファに溜めこんでおくことにより、ストリーミング再生でチャプタジャンプを行ったときに従来ではバッファリングを行う必要があったところを、シームレスに映像を切り替えることができる。
【００４２】
従来技術では前後のデータの先頭のデータを再生前にサーバから受信するというものであったが、本実施形態では先頭のデータに十分なデータがたまれば、次のチャプタの先頭部分以外のデータもバッファに溜めこむことができる。
【００４３】
本実施形態は、十分な回線速度を得られる（すなわちデータが溜まりやすい）環境で特に効果を発揮する。
【００４４】
本実施形態はストリーミング再生中に上限Threshold以上のデータが溜まると次のチャプタ位置の部分データを取得するものであるため、開始時の遅れを低減することができる。
【００４５】
先行技術で取得するのは前後の先頭データのみだが、本実施形態では下限Thresholdを切るまで次チャプタのデータを蓄えることができ、先行技術にない効果を発揮することができる。
【００４６】
またデータを蓄えるチャプタは優先度を設定することができるため、どのチャプタのデータを優先的に取得するかをユーザが指定することができる。
【００４７】
即ち、以上説明した実施例によれば次のような特徴を持つ実施形態を構成することができる。
【００４８】
（１）ストリーミング再生で、現在再生中のデータがバッファに十分溜まった場合、自動的に次のチャプタのデータのバッファリングをはじめる。
【００４９】
（２）現在再生中のデータが少なくなったら自動的に次のチャプタのバッファリングを中止し、現在再生中のデータのバッファリングを再開する。
【００５０】
（３）チャプタの優先度(どのチャプタから優先的にデータを溜めるか)はユーザが任意に変更することができる。
【００５１】
なお、この発明は上記実施形態に限定されるものではなく、この外その要旨を逸脱しない範囲で種々変形して実施することができる。例えば放送波を受信する環境でもよいし、録画されたコンテンツの再生に適用することもできる。
【００５２】
また、上記した実施の形態に開示されている複数の構成要素を適宜に組み合わせることにより、種々の発明を形成することができる。例えば、実施の形態に示される全構成要素から幾つかの構成要素を削除しても良いものである。さらに、異なる実施の形態に係わる構成要素を適宜組み合わせても良いものである。
【符号の説明】
【００５３】
１，２・・・ストリームバッファ、１０・・・通信装置、１４・・・映像再生装置、１６・・・表示装置、１７・・・チャプタ管理部、１８・・・バッファ制御部、２０・・・再生制御部、１００・・・配信サーバ、２００・・・映像表示装置、３００・・・システム。
【図１】
2013110476.tif 000003
【図２】
2013110476.tif 000004
【図３】
2013110476.tif 000005
【図４】
2013110476.tif 000006
【図５】
2013110476.tif 000007
【図６】
2013110476.tif 000008
【図７】
2013110476.tif 000009