(57)【要約】【課題】再生するコンテンツを切り替える場合にコンテンツを効率的に切り替えることができるようにする。【解決手段】映像データを送信装置に対して要求するとともに送信装置から送信された映像データを受信する通信部と、受信した映像データのセグメントを保持して映像データを再生表示する場合に再生タイミング順に映像データのセグメントを出力するバッファと、再生表示する映像データを切り替える場合、バッファに保持されている変更前の映像データのセグメントに基づいて、送信装置に対して要求する変更後の映像データのセグメントを決定する取得セグメント決定部とを備え、取得セグメント決定部での決定に基づく要求に対する応答として送信装置から送信された、次の再生タイミングに対応した変更後の映像データのセグメントがバッファに保持されると、バッファが出力する映像データを変更後の映像データに切り替える。【選択図】図２
2017228972.tif 000002
【特許請求の範囲】
【請求項１】
再生タイミングに対応した複数のセグメントに分割された映像データを送信装置に対して要求するとともに、前記要求に対する応答として前記送信装置から送信された映像データを受信する通信手段と、
前記セグメントの単位で、前記通信手段が受信した映像データを保持して当該映像データを再生表示する場合に前記再生タイミング順に当該映像データを出力する保持手段と、
再生表示する映像データを第１の映像データから第２の映像データに切り替える場合、前記保持手段に保持されている前記第１の映像データのセグメントに基づいて、前記送信装置に対して要求する前記第２の映像データのセグメントを決定する決定手段とを備え、
前記保持手段は、前記決定手段による決定に基づく要求に対する応答として前記送信装置から送信された、次の前記再生タイミングに対応した前記第２の映像データのセグメントを保持すると、出力する映像データを前記第１の映像データから前記第２の映像データに切り替えることを特徴とする映像処理装置。
【請求項２】
前記保持手段が出力する映像データを再生表示する表示手段を備えることを特徴とする請求項１記載の映像処理装置。
【請求項３】
前記保持手段は、前記通信手段が受信した映像データのセグメントの再生可能時刻を求め、当該セグメントの再生予定時刻が求めた前記再生可能時刻より先である場合、受信した映像データのセグメントを破棄することを特徴とする請求項１又は２記載の映像処理装置。
【請求項４】
前記決定手段は、前記保持手段に保持されている前記第１の映像データのセグメントの前記再生タイミングの内、前記再生タイミングの早いものから当該再生タイミングに対応する前記第２の映像データのセグメントを要求するよう決定することを特徴とする請求項１〜３の何れか１項に記載の映像処理装置。
【請求項５】
前記決定手段は、現在時刻から前記送信装置との間におけるラウンドトリップタイム以降の前記再生タイミングに対応する前記第２の映像データのセグメントを要求するよう決定することを特徴とする請求項４記載の映像処理装置。
【請求項６】
前記決定手段は、前記保持手段に保持されている前記第１の映像データのセグメントの前記再生タイミングの内、前記再生タイミングの遅いものから当該再生タイミングに対応する前記第２の映像データのセグメントを要求するよう決定することを特徴とする請求項１〜３の何れか１項に記載の映像処理装置。
【請求項７】
前記決定手段は、前記保持手段に保持されている前記第１の映像データのセグメントのうち、再生タイミングが早いものから所定数のセグメントのうち、再生タイミングが最も遅いセグメントに対応する前記第２の映像データのセグメントを要求するように決定することを特徴とする請求項１〜３の何れか１項に記載の映像処理装置。
【請求項８】
再生タイミングに対応した複数のセグメントに分割された映像データを送信装置に対して要求するとともに、前記要求に対する応答として前記送信装置から送信された映像データを受信する通信手段と、前記セグメントの単位で、前記通信手段が受信した映像データを保持して当該映像データを再生表示する場合に前記再生タイミング順に当該映像データを出力する保持手段とを備える映像処理装置の映像処理方法であって、
再生表示する映像データを第１の映像データから第２の映像データに切り替える場合、前記保持手段に保持されている前記第１の映像データのセグメントに基づいて、前記送信装置に対して要求する前記第２の映像データのセグメントを決定する工程と、
前記決定に基づいて前記第２の映像データを送信装置に対して要求する工程と、
前記送信装置に対する要求の応答として前記送信装置から送信された、次の前記再生タイミングに対応した前記第２の映像データのセグメントを前記保持手段が保持した場合、前記保持手段が出力する映像データを前記第１の映像データから前記第２の映像データに切り替える工程とを有することを特徴とする映像処理方法。
【請求項９】
コンピュータを、請求項１〜７の何れか１項に記載の映像処理装置の各手段として動作させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像処理装置、映像処理方法、及びプログラムに関する。
【背景技術】
【０００２】
近年、音声データや映像データ等のコンテンツをユーザーに対してリアルタイムに配信する配信システムが提供されている。このような配信システムにより、ユーザーは、自身の端末装置を介して、ライブ映像等の所望のコンテンツをリアルタイムで楽しむことができる。スマートフォンやタブレットのような端末装置の普及により、様々な端末装置でストリーミングコンテンツを楽しみたいという需要が高まってきている。この要求を実現するために端末装置の性能や通信環境に応じて、動的に取得するストリームデータを変更する技術（ＭＰＥＧ−ＤＡＳＨ、Ｈｔｔｐ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ等）が知られている。
【０００３】
これらの技術ではコンテンツ（例えば映像データ）を細かい時間単位のセグメントに分割し、セグメントを取得するためのＵＲＬ（Ｕｎｉｆｏｒｍ  Ｒｅｓｏｕｃｅ  Ｌｏｃａｔｏｒ）をプレイリストと呼ばれるファイルに記述する。受信装置（端末装置）は、初めにこのプレイリストを取得し、プレイリストに記述されている情報を用いて所望の映像データを取得する。プレイリスト中に複数のバージョンの映像データセグメントに対するＵＲＬを記載することで、受信装置が自身の性能や通信環境に応じて、最適なバージョンの映像データセグメントを取得することができる。
【０００４】
また、新しい番組が選択された後であっても、新しい番組をデコードするために必要なオーバーヘッド情報が受信されるまで、受信装置が現在の番組を受信、デコード、解凍、表示し続ける技術が提案されている（特許文献１参照）。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１０−２３９６３２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
特許文献１では、受信装置が再生する番組を切り替える場合、新しい番組をデコードするために必要なオーバーヘッド情報が受信されるまで、２種類のストリームデータを受信することになり、通信のオーバーヘッドが大きくなってしまうという課題がある。また、再生中の番組の映像データの受信を中止し新しい番組の映像データのみを受信するようにした場合、再生する映像データの枯渇を防ぐために一定の映像データを受信してから新しい番組を再生するする必要がある。この場合、受信装置が受信する番組（ストリーム）の切り替えを始めてから実際に再生をするまでに遅延が発生し、ユーザーエクスペリエンスの低下につながってしまう。また、上記課題は、映像データのみならず、音声データ（オーディオデータ）など他のコンテンツについても同様である。本発明は、このような問題に鑑みてなされたものであり、再生するコンテンツを切り替える場合にコンテンツを効率的に切り替えることができるようにすることを目的とする。
【課題を解決するための手段】
【０００７】
本発明に係る映像処理装置は、再生タイミングに対応した複数のセグメントに分割された映像データを送信装置に対して要求するとともに、前記要求に対する応答として前記送信装置から送信された映像データを受信する通信手段と、前記セグメントの単位で、前記通信手段が受信した映像データを保持して当該映像データを再生表示する場合に前記再生タイミング順に当該映像データを出力する保持手段と、再生表示する映像データを第１の映像データから第２の映像データに切り替える場合、前記保持手段に保持されている前記第１の映像データのセグメントに基づいて、前記送信装置に対して要求する前記第２の映像データのセグメントを決定する決定手段とを備え、前記保持手段は、前記決定手段による決定に基づく要求に対する応答として前記送信装置から送信された、次の前記再生タイミングに対応した前記第２の映像データのセグメントを保持すると、出力する映像データを前記第１の映像データから前記第２の映像データに切り替えることを特徴とする。
【発明の効果】
【０００８】
本発明によれば、再生するコンテンツを切り替える場合にコンテンツを効率的に切り替えることができる。
【図面の簡単な説明】
【０００９】
【図１】本実施形態における通信システムの構成例を示す図である。
【図２】本実施形態における受信装置１０１の機能構成例を示す図である。
【図３】プレイリストの一例を示す図である。
【図４】本実施形態における受信装置１０１のハードウェア構成例を示す図である。
【図５】本実施形態における取得映像変更処理及び再生映像変更処理の処理例を示すフローチャートである。
【図６】本実施形態における次取得セグメント決定処理の処理例を示すフローチャートである。
【図７】本実施形態における映像変更処理例１を説明する図である。
【図８】本実施形態における映像変更処理例２を説明する図である。
【図９】本実施形態における映像変更処理例３を説明する図である。
【図１０】本実施形態における映像変更処理例４を説明する図である。
【発明を実施するための形態】
【００１０】
以下、本発明の実施形態を図面に基づいて説明する。なお、以下に示す構成は一例にすぎず、本発明は図示された構成に限定されるものではない。
【００１１】
＜システム全体の構成＞
図１は、本発明の一実施形態における通信システムの全体構成例を示す図である。本実施形態における通信システムにおいて、受信装置１０１と送信装置１０２とはネットワーク１０３を介して接続される。なお、受信装置１０１、送信装置１０２は、それぞれ複数存在しても良い。
【００１２】
本実施形態における映像処理装置としての受信装置１０１は、コンテンツの再生・表示機能、及び通信機能を有し、例えばネットワーク１０３を介してコンテンツの映像データを受信して映像を表示する。また、受信装置１０１は、ユーザーからの入力を受け付ける機能を有していても良い。受信装置１０１は、例えばスマートフォン装置、ＰＣ（パーソナルコンピュータ）装置、テレビジョン装置、携帯電話等である。なお、受信装置１０１は、後述の機能構成を満たすものであれば、例示したものに限定されない。
【００１３】
送信装置１０２は、コンテンツの送信機能を有し、例えば要求されたコンテンツの映像データをネットワーク１０３を介して受信装置１０１に送信する。また、送信装置１０２は、ユーザーからの入力を受け付ける機能を有していても良い。送信装置１０２は、例えば、カメラ装置、ビデオカメラ装置、スマートフォン装置、ＰＣ（パーソナルコンピュータ）装置、携帯電話等である。
【００１４】
ネットワーク１０３は、受信装置１０１と送信装置１０２との間でデータを伝送するネットワークであり、例えば有線ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）又は無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ  ＬＡＮ）である。なお、これに限らず、ＷＡＮ（Ｗｉｄｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）やＰＡＮ（Ｐｅｒｓｏｎａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）等でもよい。
【００１５】
＜受信装置の機能構成＞
図２は、本実施形態における受信装置１０１の機能構成例を示す図である。受信装置１０１は、ネットワーク１０３を介して送信装置１０２より送信されるプレイリストを通信部２０８で要求し受信する。受信したプレイリストは、プレイリスト解析部２０５に渡され解析される。取得セグメント決定部２０６は、取得するセグメントとその取得タイミングを決定する。ここで、セグメントとは、映像データを再生タイミングに対応させ細かい時間単位に分割したものである。
【００１６】
具体的には、まずプレイリスト解析部２０５が、送信装置１０２から取得したプレイリストを解析し、特定タイミングの映像データを取得するためにアクセスするＵＲＬを特定する。次に、取得セグメント決定部２０６が、取得映像決定部２０７から入力される取得対象映像の情報を基に取得セグメントを決定する。その後、取得セグメント決定部２０６が、バッファ２０４に蓄積されている映像データの状態と復号化部２０２の残り再生時間を考慮して取得タイミングを決定する。そして、決定した取得タイミングで決定した取得セグメントを、映像データを取得するためのＵＲＬにアクセスすることで取得する。
【００１７】
取得映像決定部２０７は、ユーザーインターフェース部２０３からの入力に基づいて取得映像を決定する。なお、これに限らずネットワーク１０３の状況に応じて取得モードを決定する等、取得映像を決定する方法は他の方法でも良い。通信部２０８は、取得セグメント決定部２０６が決定した取得セグメントをネットワーク１０３を介して送信装置１０２に要求し受信する。受信したセグメントは、再生表示制御機能を有するバッファ２０４へ渡されて保持されて再生タイミング順に出力され、その後復号化部２０２で復号化されて、表示部２０１で表示される。なお、バッファ２０４へのセグメントの蓄積順は、再生タイミング以外の順でもよい。
【００１８】
図３に、プレイリスト解析部２０５が解析するプレイリストの一例を示す。本実施形態においては、ＭＰＥＧ−ＤＡＳＨで規定されているＭＰＤ（Ｍｅｄｉａ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｉｏｎ）と呼ばれるプレイリストの記述方法に従うものとする。なお、Ｈｔｔｐ  Ｌｉｖｅｓｔｒｅａｍｉｎｇにおけるプレイリストの記述方法等、これと同等の機能を有するものでも良い。また、図３においては説明を簡素化するためにＭＰＥＧ−ＤＡＳＨで規定されるＭＰＤ記述に関する情報の一部を示している。
【００１９】
図３に示す３０１はＭＰＤの記述例の１つである。３０３の各Ｒｅｐｒｅｓｅｎｔａｔｉｏｎに、送信装置１０２が提供可能な映像の情報及びセグメントへアクセスするためのＵＲＬが記述されており、３０２のＢａｓｅＵＲＬと合わせることでセグメントをリクエストすることができる。Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ毎のセグメント情報は、時系列順にリストされており、各Ｒｅｐｒｅｓｅｎｔａｔｉｏｎのリストのセグメントにおいてセグメント番号（リスト先頭からの通し番号）が同じものは同じタイミングで再生するものとされている。例えば、３０４のセグメントと３０５のセグメントの再生タイミングは同じである。
【００２０】
＜受信装置のハードウェア構成＞
図４は、本実施形態における受信装置１０１のハードウェア構成例を示す図である。中央処理装置（以下、ＣＰＵとも称す）４０１は、装置全体を制御しデータの計算や加工等を行う。ＣＰＵ４０１は、ＲＯＭ４０２に格納されたプログラムをＲＡＭ４０３に展開して実行することにより各種処理を実行する。ＣＰＵ４０１がＲＯＭ４０２に格納されたプログラムをＲＡＭ４０３に展開して実行することで、例えば取得映像決定部２０７、取得セグメント決定部２０６、プレイリスト解析部２０５、及び復号化部２０２の機能が実現される。
【００２１】
ＲＯＭ４０２は、一度書き込まれた情報を読み出すための記憶装置であり、例えば図２に示した各機能部を機能させるためのプログラムを格納する。ＲＡＭ４０３は、一時的にデータを書き込み及び読み出すための記憶装置であり、例えば各プログラムの実行に係る一時的な値の記憶を行う。内蔵メモリ４０４及び外部メモリ４０６は、アプリケーションのコンテンツを記憶しておく外部記憶装置である。内蔵メモリ４０４及び外部メモリ４０６により図２に示したバッファ２０４の機能が実現される。
【００２２】
入力装置４０５は、電源ボタンや音量ボタン、ホームボタン等のボタンとして実装される入力装置である。入力装置４０５は、受信装置１０１に複数実装することができる。入力装置４０５により図２に示したユーザーインターフェース部２０３の機能が実現される。スピーカー４０７及びディスプレイ４０８は、送信装置１０２から受信したコンテンツを再生することが可能であり、図２に示した表示部２０１を実現する。ネットワークインターフェース（Ｉ／Ｆ）４０９は、ネットワーク１０３を介してデータを送受信するための装置であり、図２に示した通信部２０８の機能を実現する。電源４１０は、受信装置１０１に電力を供給する装置であり、例えば電池と充電装置を含む。
【００２３】
次に、本実施形態における動作について説明する。
＜映像変更処理例１＞
まず、受信装置１０１における取得映像変更処理及び再生映像変更処理について説明する。取得映像決定部２０７が取得対象映像を現在取得中の映像から別の映像へ変更した際、受信装置１０１は、以下に説明する取得映像変更処理及び再生映像変更処理を同時に開始する。ただし、取得映像変更処理と再生映像変更処理の開始のタイミングにタイムラグが生じても良い。
【００２４】
図５（Ａ）は、本実施形態における取得映像変更処理の処理例を示すフローチャートである。ステップＳ５０１にて、取得セグメント決定部２０６は、取得対象となる別映像のセグメントを決定する。このステップＳ５０１での処理については、図６（Ａ）を参照して後述する。ステップＳ５０２にて、通信部２０８は、ステップ５０１において取得対象として決定したセグメントを取得するためのリクエストを送信装置１０２へ送信する。
【００２５】
ここで、レスポンスを待たずに複数のリクエストを連続して送信できる場合、ステップＳ５０１及びＳ５０２の処理を複数回繰り返し、複数のリクエストを送信してもよい。レスポンスを待たずに複数のリクエストを連続して送信できる通信には、例えばＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）通信やＨＴＴＰ（Ｈｙｐｅｒｔｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）パイプライン機能のような通信がある。
【００２６】
ステップＳ５０３にて、通信部２０８は、リクエストに対する応答として送信装置１０２から送信されたセグメントを受信する。ステップＳ５０４にて、バッファ２０４は、受信したセグメントの再生可能時刻を確認する。再生可能時刻は、例えば受信したセグメントを復号化するために要する時間を現在時刻に加えることにより求める。なお、受信したセグメントの再生可能時刻を他の方法で求めるようにしても良い。
【００２７】
ステップＳ５０５にて、通信部２０８は、受信したセグメントの再生可能時刻と、受信したセグメントの再生予定時刻とを比較する。受信したセグメントの再生可能時刻が受信したセグメントの再生予定時刻より先であると通信部２０８が判定した場合、ステップＳ５０６へ遷移し通信部２０８は受信したセグメントをバッファ２０４へバッファリングし、その後ステップＳ５０７へ遷移する。一方、受信したセグメントの再生予定時刻が受信したセグメントの再生可能時刻より先であると通信部２０８が判定した場合、ステップＳ５０９へ遷移し、通信部２０８は受信したセグメントを破棄し、その後ステップＳ５０７へ遷移する。
【００２８】
ステップＳ５０７にて、通信部２０８は、ステップＳ５０２においてリクエストを出したセグメントをすべて受信したか否かを判定する。ステップＳ５０２においてリクエストを出したセグメントをすべて受信したと通信部２０８が判定した場合、ステップＳ５０８へ遷移する。なお、リクエストの送信時にタイムアウト時間を設け、未受信のセグメントがあってもタイムアウト時間が経過していればステップＳ５０８へ遷移するようにしてもよい。また、ステップＳ５０２においてリクエストを出したセグメントのうち、未受信のセグメントがあると通信部２０８が判定した場合、ステップＳ５０３へ遷移する。
【００２９】
ステップＳ５０８にて、取得セグメント決定部２０６は、図５（Ｂ）に示す再生映像変換処理がステップＳ５２５へ遷移済みであるかどうかを判定する。再生映像変換処理がステップＳ５２５へ遷移済みでないと取得セグメント決定部２０６が判定した場合、ステップＳ５０１へ遷移する。再生映像変換処理がステップＳ５２５へ遷移済みであると取得セグメント決定部２０６が判定した場合、取得映像変更処理を終了する。
【００３０】
図５（Ｂ）は、本実施形態における再生映像変更処理の処理例を示すフローチャートである。ステップＳ５２１にて、バッファ２０４は、再生中である変更前の映像のセグメントに対して次のタイミングで再生する変更後の映像のセグメントがバッファリング済みであるか否かを判定する。該当のセグメントをバッファ２０４にバッファリングしていないとバッファ２０４が判定した場合、ステップＳ５２２へ遷移し、バッファ２０４は、復号化部２０２で復号し表示部２０１で再生するセグメントとして変更前の映像のセグメントを継続して使用する。なお、変更前の映像の再生を継続するのではなく、今まで再生していた映像をフリーズさせても良いし、青や黒の背景等でブランク表示にしてもよい。
【００３１】
ステップＳ５２１において、該当のセグメントをバッファ２０４にバッファリングしているとバッファ２０４が判定した場合、ステップＳ５２３へ遷移する。ステップＳ５２３にて、バッファ２０４は、復号化部２０２で復号し表示部２０１で再生するセグメントを変更後の映像のセグメントに変更する。ステップＳ５２４にて、バッファ２０４は、バッファリング済みの変更前の映像のセグメントを復号化部２０２へ送る対象から除外し、ステップＳ５２５にて再生映像変更処理を終了する。
【００３２】
なお、図５（Ｂ）に示した再生映像変更処理において、ステップＳ５２３とＳ５２４の処理の実行順序は逆でもよい。また、ステップＳ５２３以降、後述するステップＳ６０３で取得できないと判定された変更後の映像のセグメントと同じタイミングで再生する変更前の映像のセグメントをバッファ２０４にバッファリング済みであれば、そのセグメントを代用し再生してもよい。また、ステップＳ５２３以降、ステップＳ５０３で受信できなかった変更後の映像のセグメントと同じタイミングで再生する変更前の映像のセグメントをバッファ２０４にバッファリング済みであれば、そのセグメントを代用し再生してもよい。
【００３３】
図６（Ａ）を参照して、ステップＳ５０１に示した次取得セグメント決定処理について説明する。ステップＳ６０１にて、取得セグメント決定部２０６は、バッファ２０４にバッファリング済みの変更前の映像のセグメントの内、最も再生タイミングが早いセグメントを入替セグメントとして特定する。入替セグメントとは、図５（Ｂ）に示したステップＳ５２５で再生映像が変更された後、この次取得セグメント決定処理で決定される変更後の映像のセグメントが再生される代わりに再生対象から外れるセグメントである。ステップＳ６０２にて、取得セグメント決定部２０６は、特定した入替セグメントを本ステップ以降で入替セグメントを特定する際の対象から除外し選択されないようにする。
【００３４】
ステップＳ６０３にて、取得セグメント決定部２０６は、プレイリストの解析結果から入替セグメントと同じタイミングで再生する変更後の映像のセグメントが送信装置１０２から取得可能か否かを判定する。該当するセグメントが送信装置１０２から取得不可であると取得セグメント決定部２０６が判定した場合、ステップＳ６０５へ遷移する。ステップＳ６０５にて、取得セグメント決定部２０６は、特定した入替セグメントの次に再生タイミングが早いセグメントを新たに入替セグメントとして特定し、ステップＳ６０２へ遷移する。
【００３５】
一方、該当するセグメントが送信装置１０２から取得可能であると取得セグメント決定部２０６が判定した場合、ステップＳ６０４へ遷移する。ステップＳ６０４にて、取得セグメント決定部２０６は、送信装置１０２から取得可能であると判定した変更後の映像のセグメントを取得セグメントとして決定し、次取得セグメント決定処理を終了する。
【００３６】
図７は、本実施形態における映像変更処理例１を実施した場合の処理を時系列に示す図である。図７を参照して、映像変更処理例１について説明する。送信装置１０２は、映像Ａ及び映像Ｂの２種類の映像のセグメントを提供するものとする。また、図７において、［バッファ状態］は、受信装置１０１のバッファ２０４におけるセグメントのバッファリング状態を示しており、［再生内容］は、受信装置１０１の表示部２０１で再生する内容を示している（図８〜図１０においても同様）。例えば、時刻ｔbにおいては、セグメントＡ1が表示部２０１で再生中であり、それ以降のセグメントはバッファ２０４へバッファリングされているということを表している。
【００３７】
受信装置１０１は、時刻ｔaより送信装置１０２から映像Ａのセグメントの取得を開始している。時刻ｔa以降、受信装置１０１は、映像Ａのセグメントを順に取得しバッファ２０４にバッファリングしていく。バッファにおける映像データの枯渇を予防するために必要なｋ個のセグメントをバッファリングし終わった後、時刻ｔbにて受信装置１０１は、映像Ａの再生を開始する。例えば、受信装置１０１は、時刻ｔbにて映像ＡのセグメントＡ1を表示部２０１で再生表示し、時刻ｔcにて映像ＡのセグメントＡ2を表示部２０１で再生表示する。
【００３８】
時刻ｔeにて、ユーザーがユーザーインターフェース部２０３へ再生映像を変更する入力を行う。再生映像変更の入力に基づき、取得映像決定部２０７は、取得対象映像を現在取得中の映像Ａから映像Ｂへ変更し、受信装置１０１は、取得映像変更処理及び再生映像変更処理を開始する。
【００３９】
ステップＳ６０１の処理を実行し、時刻ｔeでのバッファ状態を確認して、取得セグメント決定部２０６が、バッファ２０４にバッファリングされている映像Ａのセグメントの内、最も再生タイミングが早いものがセグメントＡn+1であることを特定する。その後、ステップＳ６０３の処理を実行し、プレイリストを確認して、取得セグメント決定部２０６が、セグメントＡn+1と同じ再生タイミングである映像ＢのセグメントＢn+1が送信装置１０２より取得可能であることを確認する。なお、セグメントＢn+1が取得可能でないと判定した場合、ステップＳ６０５の処理を実行し、取得セグメント決定部２０６がセグメントＡn+1の次に再生タイミングが早いセグメントＡn+2を特定し、再度ステップＳ６０２の処理を行う。
【００４０】
続いて、ステップＳ６０４の処理を実行し、取得セグメント決定部２０６が、セグメントＢn+1を次の取得対象のセグメントに決定する。そして、ステップＳ５０２の処理を実行し、通信部２０８が、セグメントＢn+1を要求するリクエストを送信装置１０２へ送信する。
【００４１】
時刻ｔfにて、ステップＳ５０３の処理を実行し、通信部２０８が送信装置１０２からセグメントＢn+1を受信する。続いて、通信部２０８が、ステップＳ５０４、Ｓ５０５の処理を実行してセグメントＢn+1が再生タイミングに間に合うと判定し、ステップＳ５０６の処理を実行してセグメントＢn+1をバッファ２０４へバッファリングする。そして、ステップＳ５２１の処理を実行し、バッファ２０４が、再生中のセグメントＡnの次に再生するセグメントＢn+1をバッファリング済みであることを確認する。その後、時刻ｔgにて、ステップＳ５２３の処理を実行し、受信装置１０１は、映像Ｂの再生を開始する。また、ステップＳ５２４の処理を実行し、バッファ２０４にバッファリングしてある映像Ａのセグメントを表示部２０１への再生対象から除外する。
【００４２】
＜映像変更処理例２＞
次に、前述した映像変更処理例１とは異なり、ステップＳ６０１の処理の実行時に受信装置１０１と送信装置１０２との間のラウンドトリップタイム（ＲＴＴ：Ｒｏｕｎｄ  Ｔｒｉｐ  Ｔｉｍｅ）を考慮した映像変更処理例２について説明する。映像変更処理例２における取得映像変更処理、再生映像変更処理、及び次取得セグメント決定処理は、図５（Ａ）、図５（Ｂ）、及び図６（Ａ）に示した処理と同様であるので説明は省略する。
【００４３】
図８は、本実施形態における映像変更処理例２を実施した場合の処理を時系列に示す図である。図８を参照して、映像変更処理例２について説明する。図８に示す時刻ｔeまでの処理は、図７に示した時刻ｔeまでの処理と同様であるので説明は省略する。時刻ｔeにて、ユーザーがユーザーインターフェース部２０３へ再生映像を変更する入力を行う。再生映像変更の入力に基づき、取得映像決定部２０７は、取得対象映像を現在取得中の映像Ａから映像Ｂへ変更し、受信装置１０１は、取得映像変更処理及び再生映像変更処理を開始する。
【００４４】
ステップＳ６０１の処理を実行し、時刻ｔeでのバッファ状態を確認して、取得セグメント決定部２０６が、バッファ２０４にバッファリングされている映像Ａのセグメントの内、最も再生タイミングが早いセグメントを特定する。このとき、取得セグメント決定部２０６は、現在時刻から受信装置１０１と送信装置１０２との間のラウンドトリップタイム以降で、最も再生タイミングが早いセグメントを特定する。図８に示す例では、セグメントＡn+3であることを特定する。ラウンドトリップタイムの取得方法については特に言及しない。
【００４５】
その後、ステップＳ６０３の処理を実行し、プレイリストを確認して、取得セグメント決定部２０６が、セグメントＡn+3と同じ再生タイミングである映像ＢのセグメントＢn+3が送信装置１０２より取得可能であることを確認する。なお、セグメントＢn+3がより取得可能でないと判定した場合、ステップＳ６０５の処理を実行し、取得セグメント決定部２０６がセグメントＡn+3の次に再生タイミングが早いセグメントＡn+4を特定し、再度ステップＳ６０２の処理を行う。
【００４６】
続いて、ステップＳ６０４の処理を実行し、取得セグメント決定部２０６が、セグメントＢn+3を次の取得対象のセグメントに決定する。そして、ステップＳ５０２の処理を実行し、通信部２０８が、セグメントＢn+3を要求するリクエストを送信装置１０２へ送信する。
【００４７】
時刻ｔfにて、ステップＳ５０３の処理を実行し、通信部２０８が送信装置１０２からセグメントＢn+3を受信する。続いて、通信部２０８が、ステップＳ５０４、Ｓ５０５の処理を実行してセグメントＢn+3が再生タイミングに間に合うと判定し、ステップＳ５０５の処理を実行してセグメントＢn+3をバッファ２０４へバッファリングする。そして、時刻ｔgにて、ステップＳ５２１の処理を実行し、バッファ２０４が、再生中のセグメントＡn+2の次に再生するセグメントＢn+3をバッファリング済みであることを確認する。その後、時刻ｔhにて、ステップＳ５２３の処理を実行し、受信装置１０１は、映像Ｂの再生を開始する。また、ステップＳ５２４の処理を実行し、バッファ２０４にバッファリングしてある映像Ａのセグメントを表示部２０１への再生対象から除外する。
【００４８】
＜映像変更処理例３＞
次に、前述した映像変更処理例１とは異なり、ステップＳ６０１の処理の実行時に再生タイミングが最も遅いセグメントを入替セグメントとして特定する映像変更処理例３について説明する。映像変更処理例３における取得映像変更処理、再生映像変更処理、及び次取得セグメント決定処理は、図５（Ａ）、図５（Ｂ）、及び図６（Ａ）に示した処理と同様であるので説明は省略する。
【００４９】
図９は、本実施形態における映像変更処理例３を実施した場合の処理を時系列に示す図である。図９を参照して、映像変更処理例３について説明する。図９に示す時刻ｔeまでの処理は、図７に示した時刻ｔeまでの処理と同様であるので説明は省略する。時刻ｔeにて、ユーザーがユーザーインターフェース部２０３へ再生映像を変更する入力を行う。再生映像変更の入力に基づき、取得映像決定部２０７は、取得対象映像を現在取得中の映像Ａから映像Ｂへ変更し、受信装置１０１は、取得映像変更処理及び再生映像変更処理を開始する。
【００５０】
ステップＳ６０１の処理を実行し、時刻ｔeでのバッファ状態を確認して、取得セグメント決定部２０６が、バッファ２０４にバッファリングされている映像Ａのセグメントの内、最も再生タイミングが遅いものがセグメントＡn+k-1であることを特定する。その後、ステップＳ６０３の処理を実行し、プレイリストを確認して、取得セグメント決定部２０６が、セグメントＡn+k-1と同じ再生タイミングである映像ＢのセグメントＢn+k-1が送信装置１０２より取得可能であることを確認する。なお、セグメントＢn+k-1が取得可能でないと判定した場合、ステップ６０５の処理を実行し、取得セグメント決定部２０６がセグメントＡn+k-1の次に再生タイミングが遅いセグメントを特定し、再度ステップＳ６０２の処理を行う。
【００５１】
続いて、ステップＳ６０４の処理を実行し、取得セグメント決定部２０６が、セグメントＢn+k-1を次の取得対象のセグメントに決定する。そして、ステップＳ５０２の処理を実行し、通信部２０８が、セグメントＢn+k-1を要求するリクエストを送信装置１０２へ送信する。
【００５２】
時刻ｔfにて、ステップＳ５０３の処理を実行し、通信部２０８が送信装置１０２からセグメントＢn+k-1を受信する。続いて、通信部２０８が、ステップＳ５０４、Ｓ５０５の処理を実行してセグメントＢn+k-1が再生タイミングに間に合うと判定し、ステップＳ５０５の処理を実行してセグメントＢn+k-1をバッファ２０４へバッファリングする。時刻ｔe以降、図５（Ｂ）に示した再生映像変更処理が終了するまで、ステップＳ５０１〜Ｓ５０８の処理を繰り返し、送信装置１０２から映像Ｂのセグメントを再生タイミングが遅いものから順に取得していく。そして、時刻ｔgにて、ステップＳ５２１の処理を実行し、バッファ２０４が、再生中のセグメントＡn+3の次に再生するセグメントＢn+4をバッファリング済みであることを確認する。その後、時刻ｔhにて、ステップＳ５２３の処理を実行し、受信装置１０１は、映像Ｂの再生を開始する。
【００５３】
＜映像変更処理例４＞
次に、前述した映像変更処理例３とは異なり、次取得セグメント決定処理を始めて行う際、バッファの先頭から所定数以降のセグメントを入替対象候補から除外する映像変更処理例４について説明する。映像変更処理例４における取得映像変更処理及び再生映像変更処理は、図５（Ａ）及び図５（Ｂ）に示した処理と同様であるので説明は省略する。
【００５４】
図６（Ｂ）は、映像変更処理例４における次取得セグメント決定処理の処理例を示すフローチャートである。ステップＳ６２１にて、取得セグメント決定部２０６は、取得映像決定部２０７が取得対象の映像を変更した後、初めて次取得セグメント決定処理を行っているかどうか判定する。２回目以降の次取得セグメント決定処理を行っていると取得セグメント決定部２０６が判定した場合、ステップＳ６２３へ遷移する。一方、初めて次取得セグメント決定処理を行っていると取得セグメント決定部２０６が判定した場合、ステップＳ６２２へ遷移する。
【００５５】
ステップＳ６２２にて、取得セグメント決定部２０６は、バッファ２０４のセグメントを先頭からカウントする。そして、取得セグメント決定部２０６は、バッファにおける映像データの枯渇を予防するために必要なセグメント数以降のセグメントを本ステップ以降で入替セグメントを特定する際の対象から除外し選択されないようにする。なお、バッファにおける映像データの枯渇を予防するために必要なセグメント数以外の数値を利用し本ステップの処理を実施してもよい。ステップＳ６２３以降の処理は、図６（Ａ）に示したステップＳ６０１以降の処理と同様であるので説明は省略する。
【００５６】
図１０は、本実施形態における映像変更処理例４を実施した場合の処理を時系列に示す図である。図１０を参照して、映像変更処理例４について説明する。時刻ｔbにて受信装置１０１は映像Ａの再生を開始するが、前述した映像変更処理例３とは異なり、バッファにおける映像データの枯渇を予防するために必要なｋ個より大きい数のｍ個のセグメントをバッファ２０４へバッファリングしてから再生を開始する。
【００５７】
時刻ｔeにて、ユーザーがユーザーインターフェース部２０３へ再生映像を変更する入力を行う。再生映像変更の入力に基づき、取得映像決定部２０７は、取得対象映像を現在取得中の映像Ａから映像Ｂへ変更し、受信装置１０１は、取得映像変更処理及び再生映像変更処理を開始する。
【００５８】
ステップＳ６２１の処理を実行し、取得セグメント決定部２０６が、初めての次取得セグメント処理であると判定すると、ステップＳ６２２の処理を実行し、時刻ｔeでのバッファ状態を確認する。そして、取得セグメント決定部２０６が、バッファ２０４にバッファリングしているセグメントの内、セグメントＡn+k-1以降のセグメントを、取得映像変更での入替対象候補から除外する。
【００５９】
続いて、ステップＳ６２３の処理を実行し、時刻ｔeでのバッファ状態を確認して、取得セグメント決定部２０６が、バッファ２０４にバッファリングされている映像Ａのセグメントの内、最も再生タイミングが遅いものを特定する。このとき、取得セグメント決定部２０６は、バッファ２０４にバッファリングされている、対象外のセグメントを除いた映像Ａのセグメントの内から、最も再生タイミングが遅いものを特定する。図１０に示す例では、セグメントＡn+k-1１００２であることを特定する。
【００６０】
その後、ステップＳ６２５の処理を実行し、プレイリストを確認して、取得セグメント決定部２０６が、セグメントＡn+k-1と同じ再生タイミングであるセグメントＢn+k-1が送信装置１０２より取得可能であることを確認する。なお、セグメントＢn+k-1が取得可能でないと判定した場合、ステップＳ６２７の処理を実行し、取得セグメント決定部２０６がセグメントＢn+k-1の次に再生タイミングが遅いセグメントを特定し、再度ステップＳ６２４の処理を行う。
【００６１】
続いて、ステップＳ６２６の処理を実行し、取得セグメント決定部２０６が、セグメントＢn+k-1を次の取得対象のセグメントに決定する。そして、ステップＳ５０２の処理を実行し、通信部２０８が、セグメントＢn+k-1を要求するリクエストを送信装置１０２へ送信する。
【００６２】
時刻ｔfにて、ステップＳ５０３の処理を実行し、通信部２０８が送信装置１０２からセグメントＢn+k-1を受信する。続いて、通信部２０８が、ステップＳ５０４、Ｓ５０５の処理を実行してセグメントＢn+k-1が再生タイミングに間に合うと判定し、ステップＳ５０５の処理を実行してセグメントＢn+k-1をバッファ２０４へバッファリングする。時刻ｔe以降、図５（Ｂ）に示した再生映像変更処理が終了するまで、ステップＳ５０１〜Ｓ５０８の処理を繰り返し、送信装置１０２から映像Ｂのセグメントを再生タイミングが遅いものから順に取得していく。
【００６３】
そして、時刻ｔgにて、ステップＳ５２１の処理を実行し、バッファ２０４が、再生中のセグメントＡn+3の次に再生するセグメントＢn+4をバッファリング済みであることを確認する。その後、時刻ｔhにて、ステップＳ５２３の処理を実行し、受信装置１０１は、映像Ｂの再生を開始する。また、ステップＳ５２４の処理を実行し、バッファ２０４にバッファリングしてある映像Ａのセグメントを表示部２０１への再生対象から除外する。
【００６４】
本実施形態によれば、受信装置１０１は、バッファ２０４にバッファリングされている変更前の映像のセグメントに基づいて、取得するセグメントを決定して変更後の映像のセグメントを取得する。そして、受信装置１０１は、次の再生タイミングで再生する変更後の映像のセグメントがバッファ２０４にバッファリング済みであると判定すると、再生する映像を変更後の映像に切り替える。これにより、再生するコンテンツを切り替える場合にコンテンツを効率的に切り替えることができる。
【００６５】
（本発明の他の実施形態）
本発明は、前述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読み出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【００６６】
なお、前記実施形態は、何れも本発明を実施するにあたっての具体化のほんの一例を示したものに過ぎず、これらによって本発明の技術的範囲が限定的に解釈されてはならないものである。すなわち、本発明はその技術思想、又はその主要な特徴から逸脱することなく、様々な形で実施することができる。
【符号の説明】
【００６７】
１０１：受信装置  １０２：送信装置  １０３：ネットワーク  ２０１：表示部  ２０２：復号化部  ２０３：ユーザーインターフェース部  ２０４：バッファ  ２０５：プレイリスト解析部  ２０６：取得セグメント決定部  ２０７：取得映像決定部  ２０８：通信部
【図１】
2017228972.tif 000003
【図２】
2017228972.tif 000004
【図３】
2017228972.tif 000005
【図４】
2017228972.tif 000006
【図５】
2017228972.tif 000007
【図６】
2017228972.tif 000008
【図７】
2017228972.tif 000009
【図８】
2017228972.tif 000010
【図９】
2017228972.tif 000011
【図１０】
2017228972.tif 000012