(57)【要約】【課題】元の動画データの保管場所の検索や元の動画データ中の特定の場面の検索を素早く行うことができるようにする。【解決手段】蓄積装置に蓄積された第１の動画データをネットワークを介して取得するための動画取得情報を入手する取得情報入手手段と、前記第１の動画データのビットレート、フレームレート、または解像度のうち少なくとも１つを変換した第２の動画データを再生する再生手段と、前記取得情報入手手段により入手した前記動画取得情報に基づいて、前記第１の動画データの再生制御指示を生成する再生指示生成手段と、前記再生指示生成手段により生成された再生制御指示を、前記第１の動画データを取得、再生可能な再生表示装置にネットワークを介して送信する通信手段とを設ける。【選択図】図２
2014204265.tif 000002
【特許請求の範囲】
【請求項１】
蓄積装置に蓄積された第１の動画データをネットワークを介して取得するための動画取得情報を入手する取得情報入手手段と、
前記第１の動画データのビットレート、フレームレート、または解像度のうち少なくとも１つを変換した第２の動画データを再生する再生手段と、
前記取得情報入手手段により入手した前記動画取得情報に基づいて、前記第１の動画データの再生制御指示を生成する再生指示生成手段と、
前記再生指示生成手段により生成された再生制御指示を、前記第１の動画データを取得、再生可能な再生表示装置にネットワークを介して送信する通信手段とを有することを特徴とする再生制御装置。
【請求項２】
前記再生制御指示は、前記第２の動画データに対する、一時停止、早送り再生、スロー再生、巻戻し再生、ランダムアクセスのようなトリックプレーを含む再生制御情報であることを特徴とする請求項１に記載の再生制御装置。
【請求項３】
前記第２の動画データは、時間軸上、第１の動画データの一部を切り出した動画データであり、前記動画取得情報は、時間軸上の切り出した部分を示す情報を含むことを特徴とする請求項１または２に記載の再生制御装置。
【請求項４】
前記再生制御指示は、前記第２の動画データの始めから終わりまでに相当する部分の再生指示であることを特徴とする請求項１〜３の何れか１項に記載の再生制御装置。
【請求項５】
前記動画取得情報は、前記第２の動画データにメタデータとして記録されることを特徴とする請求項１〜４の何れか１項に記載の再生制御装置。
【請求項６】
前記再生制御装置は携帯端末装置として構成されており、
前記携帯端末装置に記録された１つ以上の前記第２の動画データが前記動画取得情報を備えているか否かを、色分け、グループ分け、或いは属性情報から識別可能なＵＩを備えることを特徴とする請求項１〜５の何れか１項に記載の再生制御装置。
【請求項７】
蓄積装置に蓄積された第１の動画データをネットワークを介して取得するための動画取得情報を入手する取得情報入手工程と、
前記第１の動画データのビットレート、フレームレート、または解像度のうち少なくとも１つを変換した第２の動画データを再生する再生工程と、
前記取得情報入手工程において入手した前記動画取得情報に基づいて、前記第１の動画データの再生制御指示を生成する再生指示生成工程と、
前記再生指示生成工程において生成された再生制御指示を、前記第１の動画データを取得、再生可能な再生表示装置にネットワークを介して送信する通信工程とを有することを特徴とする再生制御方法。
【請求項８】
蓄積装置に蓄積された第１の動画データをネットワークを介して取得するための動画取得情報を入手する取得情報入手工程と、
前記第１の動画データのビットレート、フレームレート、または解像度のうち少なくとも１つを変換した第２の動画データを再生する再生工程と、
前記取得情報入手工程において入手した前記動画取得情報に基づいて、前記第１の動画データの再生制御指示を生成する再生指示生成工程と、
前記再生指示生成工程において生成された再生制御指示を、前記第１の動画データを取得、再生可能な再生表示装置にネットワークを介して送信する通信工程とをコンピュータに実行させることを特徴とするプログラム。
【請求項９】
請求項８に記載のプログラムを記憶したことを特徴とするコンピュータ読み取り可能な記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は再生制御装置及び再生制御方法に関し、特に、物理特性の異なる複数の動画データの同期的な再生制御を実現するために用いて好適な技術に関する。
【背景技術】
【０００２】
近年、デジタルビデオカメラ等の撮像機器の中には、撮影中或いは撮影済みの動画データをスマートフォン等の携帯端末に伝送し、携帯端末側で再生処理、及び動画データの蓄積が可能な製品が出てきている。
【０００３】
一般に、このような携帯端末に伝送される動画データは、携帯端末のディスプレイ解像度や対応コーデック、対応可能な動画フォーマット、或いはＣＰＵ（Central Processing Unit）の処理能力等の制約に従う必要がある。よって、撮像機器に記録される動画データから、ビットレートやフレームレート、或いは解像度などを変換した動画データが送信されることが多い。つまり、撮像機器内に記録された動画データとはコンテンツとしての内容が同じでも、動画データとしては何らかの物理特性が異なる動画データが携帯端末に記録されるケースがある。
【０００４】
このようなケースにおいて、近年では撮影した動画データ（元の動画データ）を撮像機器から取り外した記録メディアの状態で管理するだけでなく、ＰＣやＤＶＲ（Digital Video Recorder）に取り込んで保管する。或いは、ＮＡＳ（Network Attached Storage）やクラウド上のサーバに保管する等の保管方法が行われるようになってきている。そして、撮影した動画データをネットワーク経由で取得し、再生することが比較的容易になってきている。
【０００５】
しかし、数ある動画データの中から所望の動画データを探し出したり、動画データの中の特定の場面を検索したりすることに関しては、携帯端末に記録した動画データを扱うほど簡単ではない。
【０００６】
携帯端末に記録した動画データは、いわゆるお気に入り場面の動画クリップであることが多い。従って、携帯端末に記録した動画クリップよりも高品質な元の動画データを、携帯端末に記録した動画データを参照するように簡単な操作で検索し、大画面のモニターやテレビで観賞することが求められている。例えば、携帯端末の動画クリップに対する操作が元の動画データに対する操作としてリモートコントロール可能になると、携帯端末の動画クリップと元の動画データの同期的な再生制御が可能になる。
【０００７】
ここで従来技術として、同期再生に関する技術には、例えば以下のものがある。
複数の異なる端末装置において動画データを再生する場合、複数の端末装置の中の１つの端末装置における再生制御情報を、他の端末装置と共有することで再生タイミングを同期させる技術が提案されている（例えば特許文献１）。
【０００８】
また、同一の動画コンテンツを複数の端末でストリーミング視聴している場合において、複数の端末における再生位置を推定し、端末間の時間的なズレを算出する。そして、各々の端末に対して再生位置の制御を指示することで、複数端末での同期再生を実現する技術も提案されている（例えば特許文献２）。
【０００９】
一方、動画配信サーバから配信された動画を再生する複数のクライアントが参加する視聴グループに対し、全てのクライアントからバッファリングの完了通知を受信した場合に、動画の再生指示を送信することで同期再生を行う技術もある（例えば特許文献３）。
【先行技術文献】
【特許文献】
【００１０】
【特許文献１】特開２００５−２３６４６２号公報
【特許文献２】特開２００５−２４４６０５号公報
【特許文献３】特開２００９−２８４０５５号公報
【発明の概要】
【発明が解決しようとする課題】
【００１１】
しかしながら、従来技術では、元の動画データから解像度やビットレート等を変換した動画データをアクセスし易いように携帯端末等に記録し、元の動画データは異なる場所に記録されている場合に種々の困難があった。例えば、元の動画データの保管場所の検索や元の動画データ中の特定の場面の検索を素早く行うことが困難であった。
【００１２】
また、手元の携帯端末に元の動画データから変換した動画データの一部を記録しておく場合が考えられる。このような場合、元の動画データの再生画像を見られない場所（例えば遠隔地）にいる人が、元の動画データの再生画像を見られる場所にいる人に対して、正確に元の動画データの中の特定の場面を説明することが困難であった。
本発明は前述の問題点に鑑み、元の動画データの保管場所の検索や元の動画データ中の特定の場面の検索を素早く行うことができるようにすることを目的とする。
【課題を解決するための手段】
【００１３】
本発明の再生制御装置は、蓄積装置に蓄積された第１の動画データをネットワークを介して取得するための動画取得情報を入手する取得情報入手手段と、前記第１の動画データのビットレート、フレームレート、または解像度のうち少なくとも１つを変換した第２の動画データを再生する再生手段と、前記取得情報入手手段により入手した前記動画取得情報に基づいて、前記第１の動画データの再生制御指示を生成する再生指示生成手段と、前記再生指示生成手段により生成された再生制御指示を、前記第１の動画データを取得、再生可能な再生表示装置にネットワークを介して送信する通信手段とを有することを特徴とする。
【発明の効果】
【００１４】
本発明によれば、第１の動画データから解像度やビットレート等を変換した第２の動画データを再生する際に、第１の動画データの保管場所の検索や第１の動画データ中の特定の場面の検索を素早く行うことができる。
また、本発明の他の特徴によれば、第１の動画データと第２の動画データの同期的な再生制御を実現することができる。
【図面の簡単な説明】
【００１５】
【図１】本発明の実施形態を示し、再生制御装置の構成例を示すブロック図である。
【図２】再生制御装置における再生制御手順の一例を示すフローチャートである。
【図３】動画クリップと元の動画データとの関係を模式的に示す概念図である。
【図４】本発明の実施形態である再生制御装置が送信した再生指示によって、元の動画データが再生処理される流れを示す概略図である。
【図５】本発明の実施形態である再生制御装置を備えた携帯端末のＵＩの例を示す概念図である。
【図６】本発明の実施形態である再生制御装置における再生制御手順の別の一例を示すフローチャートである。
【図７】動画クリップのヘッダ部分に動画取得情報を記録する一例を示す概略図である。
【発明を実施するための形態】
【００１６】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１７】
＜第１の実施形態＞
図１は、本発明の実施形態を示し、再生制御装置の構成例を示すブロック図である。
図１において、再生制御装置１００は、通信部１０１、動画データ記憶部１０２、再生処理部１０３、表示部１０４、取得情報保持部１０５、再生指示生成部１０６から構成されている。
伝送路１０７は、３Gや４G等の携帯電話系の通信サービスやインターネット、或いはLAN（Local Area Network）等のネットワークである。
【００１８】
通信部１０１はデータを送受信する機能を備え、伝送路１０７と通信可能なように接続されている。なお、通信手段は無線でも有線でもよい。
動画データ記憶部１０２には、デジタルビデオカメラ等の撮像機器で撮影した動画データ（第１の動画データ）から、ビットレートやフレームレート等を変換した動画クリップ（第２の動画データ）が記録される。動画クリップの記録は、撮像機器での撮影中或いは撮影後に行われる。
【００１９】
再生処理部１０３は、動画データ記憶部１０２に記録された動画クリップを再生処理し、表示部１０４に再生画像を表示する。再生処理部１０３における再生処理方法には、早送り、巻戻し、一時停止、ランダムアクセスなど一連の再生制御が可能である。
【００２０】
取得情報保持部１０５には、動画データ記憶部１０２に記録された動画クリップの元の動画データを取得するために必要な情報が記録されている。以下、この情報を動画取得情報と呼ぶ。動画取得情報には、動画クリップの元の動画データが記録されている場所を示す情報が含まれる。
【００２１】
再生指示生成部１０６は、再生処理部１０３の指示により、取得情報保持部１０５から動画取得情報を入手する取得情報入手処理を行い、入手した動画取得情報を基にして、元の動画データの再生指示を生成する。再生指示生成部１０６で生成された再生指示は、通信部１０１によって、伝送路１０７に送信される。
【００２２】
次に、本実施形態の再生制御装置１００による再生制御の詳細について、図２を用いて説明する。図２は、本実施形態の再生制御装置１００における再生制御手順の一例を示すフローチャートである。
図２において、まずＳ２０１で、動画データ記憶部１０２に記録された動画クリップの中から、再生する動画クリップを選択する。
【００２３】
次にＳ２０２で、再生する動画クリップの元の動画データの動画取得情報が、取得情報保持部１０５に記録されているか確認する。動画取得情報が取得情報保持部１０５に記録されている場合は、Ｓ２０３にて元の動画データの再生指示が作成される。この再生指示は、再生指示生成部１０６で生成される。
【００２４】
再生指示生成部１０６で生成された再生指示は、Ｓ２０４にて通信部１０１から伝送路１０７を介して送信される。そして、その送信先は、元の動画データを取得、再生可能な再生装置であって、例えばＤＶＲやテレビのＳＴＢ（Set Top Box）等が挙げられる。
【００２５】
その後、Ｓ２０５で動画クリップの再生処理を開始する。なお、Ｓ２０２で動画クリップの元の動画の動画取得情報が、取得情報保持部１０５に記録されていない場合、そのままＳ２０５に移行し、動画クリップの再生処理が開始される。
【００２６】
次に、動画データ記憶部１０２に記録されている動画クリップと元の動画データの関係を、図３を用いて説明する。図３は、動画クリップと元の動画データの関係を模式的に示す概念図である。
図３において、元の動画データはデジタルビデオカメラ等の撮像機器で撮影した動画データであり、そのまま携帯端末で視聴するには、ビットレートや解像度が高すぎたり、コーデックやフォーマットが未対応であったりする場合がある。更に、撮影した動画データのファイルの中の一部分のみを動画クリップとして切り出したい場合がある。
【００２７】
そこで図３では、携帯端末に記録する動画クリップは、元の動画データの時間軸上の一部分を、ビットレートや解像度等を低く変換して切り出したデータであることを模式的に示している。
【００２８】
次に、動画取得情報の内容について説明する。動画取得情報は、携帯端末に記録されている動画クリップを切り出した元の動画データを取得するための情報である。
元の動画データは、ＰＣやＤＶＲ、或いはＮＡＳやクラウド上のサーバ等に保管されている。このため、元の動画データを取得するための情報として、まず、元の動画データが保管されている場所を示すＵＲＬ（Uniform Resource Locator）情報が挙げられる。
【００２９】
また、図３にて説明したように、動画クリップが元の動画データの一部分を切り出したものである場合、切り出し位置を示す情報が挙げられる。
これらの情報を基に、元の動画データを取得し再生するための再生指示は、例えば次のようになる。
http://cloudserver/contents/movie/20121119/0025.MTS?from=2834&to=3025
【００３０】
ここに示す“0025.MTS"が元の動画データのファイル名であり、前述した例では、クラウド上のサーバに元の動画データが保管されていることを意図している。また、ファイル名に続くクエリーで記載した“2834”は再生開始位置、“3025”は再生終了位置を示している。したがって、第２の動画データの始めから終わりまでに相当する部分の再生を指示する内容である。
【００３１】
なお、再生開始位置と再生終了位置は、必ずしも動画クリップの切り出し位置と同一である必要はない。つまり、切り出した部分に含まれていない位置を指示することや、切り出した部分の中の特定位置を指示することも可能である。
【００３２】
次に、本実施形態の再生制御装置１００が送信した再生指示によって、元の動画データが再生処理される流れについて図４を用いて説明する。図４においては、再生制御装置１００は携帯端末装置として構成されている例を示している。
図４において、まず再生制御装置１００は、ＳＴＢ２００に対して元の動画データの再生指示２０１を送信する。再生指示の内容は上記に説明した通りである。
【００３３】
再生指示を受信したＳＴＢ２００は、再生指示の内容を基に元の動画データの特定部分のデータを要求するメッセージ２０２を、元の動画データを蓄積する蓄積装置として設けられているクラウドサーバ３００に送信する。
要求を受けたクラウドサーバ３００は、ＳＴＢ２００に対し元の動画データの特定部分のデータ２０３を配信する。
【００３４】
元の動画データの特定部分のデータ２０３を受信したＳＴＢ２００は、クラウドサーバ３００から受信したデータ２０３の再生処理を行い、テレビ４００に再生画像を表示する。
このようにして、再生制御装置１００から送信された再生指示２０１によって、元のデータの再生処理が開始される。前述した例では、ＳＴＢ２００とテレビ４００を別々に構成した例を示したが、ＳＴＢ２００とテレビ４００とを一体的に備えた再生表示装置としてもよい。
【００３５】
ところで、再生制御装置１００を備えた携帯端末に記録された動画クリップの中には動画取得情報を備えていないものが含まれるケースが考えられる。そこで、動画クリップが動画取得情報を備えているか否かを簡単に識別するためのＵＩの例について図５を用いて説明する。
【００３６】
図５は、再生制御装置１００を備えた携帯端末のＵＩの例を示す概念図である。図５において、複数の四角の表示は各動画クリップのサムネイルを示している。
５０１は動画クリップが動画取得情報を備えているか否かによって動画クリップのサムネイルの枠に色付けすることで、一目で動画取得情報の有無を識別可能にすることを示している。
【００３７】
また５０２は、動画クリップが動画取得情報を備えているか否かによってグループ分けすることによって、一目で動画取得情報の有無を識別可能にすることを示している。
更に５０３は、各動画クリップの属性情報を表示すると、属性情報の中の項目の１つとして動画取得情報の有無を表示することで、各動画クリップの動画取得情報の有無を識別可能にすることを示している。
つまり、色分けやグループ分け、或いは属性情報等によるＵＩ上での識別によって、複数の動画クリップの動画取得情報の有無が容易に識別可能となる。
【００３８】
ところで、図２及び図４を用いた前述の説明では、元の動画データが再生処理されるまでの流れについて説明した。
ここでは更に、元の動画データの再生処理が開始された後に、動画クリップと元の動画データで同期的に再生制御する形態について、図６を用いて説明する。
【００３９】
図６は、本実施形態の再生制御装置１００における再生制御手順の別の一例を示すフローチャートである。
図２に示したフローチャートでは、Ｓ２０４で元の動画データの再生指示を送信した後、Ｓ２０５で動画クリップの再生を開始しているので、動画クリップと元の動画データはほぼ同時に再生を開始した状態になっている。
【００４０】
図６のフローチャートは、図２のフローチャートで説明した処理の後に、動画クリップに対して一時停止や早送り再生、スロー再生、巻戻し再生、ランダムアクセス等のいわゆるトリックプレーの操作を行った時に行なわれる一連の処理手順を示す。
【００４１】
図６において、まずＳ６０１で再生中の動画クリップに再生制御を指示すると、Ｓ６０２で動画クリップの元の動画データの動画取得情報が存在するか確認し、存在する場合はＳ６０３で元の動画データの再生制御指示を生成する。
【００４２】
Ｓ６０３で生成した再生制御指示はＳ６０４で、元の動画データを取得、再生可能な再生装置に送信され、次にＳ６０５で動画クリップへの再生制御を実行する。なお、Ｓ６０２で動画クリップの元の動画データの動画取得情報が存在しない場合は、そのままＳ６０５で動画クリップへの再生制御を実行する。
【００４３】
ここで、トリックプレーの再生制御指示の一例を、一時停止、早送り再生（２倍速）、巻戻し再生、ランダムアクセスの場合、の各々について示す。
http://cloudserver/contents/movie/20121119/0025.MTS?pause=true
http://cloudserver/contents/movie/20121119/0025.MTS?speed=x2
http://cloudserver/contents/movie/20121119/0025.MTS?direction=reverse
http://cloudserver/contents/movie/20121119/0025.MTS#time=3000
【００４４】
前述した例では、それぞれの再生制御に関して個別の再生制御情報の例を示したが、複数の制御指示は１つにまとめてもよい。例えば下記の例では、２倍速の巻戻し再生の再生指示となる。
http://cloudserver/contents/movie/20121119/0025.MTS?direction=reverse& speed=x2
【００４５】
ここに示した再生制御指示の記述はあくまで一例であり、他の記述方法としては、例えばXML（Extensible Markup Language）等を用いたり、或いはhttp以外のスキームを使用したりして、再生制御指示を行ってもよい。
【００４６】
＜第２の実施形態＞
次に、第２の実施形態として、動画取得情報を取得情報保持部１０５以外の場所に記録する構成について説明する。
前述した第１の実施形態では、動画取得情報は取得情報保持部１０５に記録すると説明したが、再生制御装置１００が動画取得情報を入手可能であれば、動画取得情報は他の場所に記録してもよい。
【００４７】
そこで一例として、動画クリップの中に動画取得情報を記録する方法について図７を用いて説明する。図７は、動画クリップのヘッダ部分に動画取得情報を記録する一例を示す概略図である。
【００４８】
図７において、７００はISO Base Media File Format（以下、ISO BMFFと略す）の概略を示している。ISO BMFFは大きく分けて、ftyp（File type box）と、moov(Movie box)と、mdat(Media data box)とから構成されている。ftypはファイルの種別を示し、moovは各種メタデータを格納したボックスを含むコンテナである。また、mdatは動画や音声のデータを格納する。
【００４９】
moovは、mdatに格納した動画や音声に関するメタデータをトラックと言う形式で格納し、更に、ユーザが任意の情報を格納可能なudta（User data box）を格納可能となっている。本実施形態では、一例として図７に示すudta７０１に動画取得情報を格納するものとする。
従って、動画取得情報は必ずしも取得情報保持部１０５に記録しておく必要は無く、必要な時に動画クリップのヘッダから随時読み出すことで入手してもよい。
【００５０】
ところで、動画クリップを切り出した元の動画データの格納場所を変更した場合、動画取得情報に含まれるＵＲＬが正しくない情報となってしまうことが考えられる。そのような場合に対処するための１つ目の方法として、例えば動画取得情報を管理可能な管理サーバを用いる方法を説明する。
【００５１】
すなわち、元の動画データの格納場所を変更した場合、直ちに管理サーバで管理している動画取得情報を更新することで、動画取得情報を常に最新の状態に保つことが可能である。
なお、概管理サーバは、動画クリップを記録した携帯端末からネットワークでアクセス可能であることが望ましい。
【００５２】
続いて、元の動画データの格納場所を変更した場合の第２の対処方法として、電子メールを用いる方法を説明する。
この方法では、元の動画データの格納場所を変更した場合に、変更した内容を通知する電子メールを携帯端末に送信する。変更通知を受信した携帯端末は、適宜動画取得情報を更新することで、動画取得情報を常に最新の状態に保つことが可能である。
【００５３】
更に、元の動画データの格納場所を変更した場合の第３の対処方法として、リダイレクト情報を利用する方法を説明する。
この方法では、元の動画データの格納場所を変更した場合に、変更前の場所には変更先の場所の情報が残され、動画取得情報を頼りに元の動画データがあった場所にアクセスすると、変更先にリダイレクトされるので、動画取得情報を更新することが可能である。
【００５４】
以上のように本実施形態では、動画取得情報の格納場所及び更新方法に関して、第１の実施形態との違いについて説明したが、ここに説明したように、動画取得情報を必要とする時に参照可能であれば、格納場所は再生制御装置１００の内部でも外部でもよい。
【００５５】
（その他の実施形態）
また、本発明は、以下の処理を実行することによっても実現される。すなわち、前述した実施形態の機能を実現するソフトウェア（コンピュータプログラム）を、ネットワークまたは各種のコンピュータ読み取り可能な記憶媒体を介してシステム或いは装置に供給する。そして、そのシステム或いは装置のコンピュータ（またはＣＰＵやＭＰＵ等）がプログラムを読み出して実行する処理である。
【符号の説明】
【００５６】
１００  再生制御装置
１０１  通信部
１０２  動画データ記憶部
１０３  再生処理部
１０４  表示部
１０５  取得情報保持部
１０６  再生指示生成部
１０７  伝送路
【図１】
2014204265.tif 000003
【図２】
2014204265.tif 000004
【図３】
2014204265.tif 000005
【図４】
2014204265.tif 000006
【図５】
2014204265.tif 000007
【図６】
2014204265.tif 000008
【図７】
2014204265.tif 000009