メディアコンテンツデータ再生装置及び方法
データ通信ネットワークにおけるクライアントのメディアコンテンツ再生方法は、メディアコンテンツディスクリプターのリクエストをサーバに送信するステップと、特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを上記サーバから受信するステップと、上記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて上記特定のメディアコンテンツデータを受信するステップとを有する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メディアコンテンツデータ再生装置及び方法に関し、特に、データ通信ネットワークから受信したメディアコンテンツデータの再生に関する倍速機能（X-speed play function）（ここで、Ｘは特定の数字）及びランダムアクセス（Random Access）機能の遅延を最小化するメディアコンテンツデータ再生装置及び方法に関する。
【背景技術】
【０００２】
通常、データ通信網を通して様々なメディアコンテンツサービス（media contents service）にアクセスする方法は、ダウンロード（download）方式及びストリーミング（streaming）方式に大別することができる。このメディアコンテンツサービスは、放送、映画、及び音楽のような様々なタイプのディジタルメディアデータ（digital media data）により提供されるサービスを意味する。この時、“ディジタルメディアデータ”は、映像、音響、場面（scene）などのような関連するメディアコンテンツを構成するディジタル情報を意味する。
【０００３】
ダウンロード方式は、ユーザが所望するメディアコンテンツサービスを構成するディジタルメディアデータを非実時間でダウンロードし、ディジタルメディアデータを記憶媒体に格納し、この格納されたディジタルメディアデータを所望する時間に再生できるようにする。したがって、ダウンロード方式は、映画及びドラマのような非実時間メディアコンテンツサービスに主に使用される。
【０００４】
ストリーミング方式は、ユーザが現在必要としているディジタルメディアデータを受信し、この受信されたディジタルメディアデータを実時間で再生できるようにする。したがって、ストリーミング方式は、ニュース及びスポーツ中継のような生放送に対応する実時間メディアコンテンツサービスに主に使用される。
【０００５】
一方、メディアコンテンツサービスを受信する間に、ユーザは、一般的な再生速度よりさらに速い再生速度でメディアコンテンツデータを再生（これを“倍速再生”と呼ぶ）するか又は現在再生している部分でない特定の部分を再生（これを“ランダムアクセス”と呼ぶ）することを希望する場合がある。
【０００６】
通常、ユーザがＭＰＥＧ（Moving Picture Experts Group）ファイルフォーマットに基づく倍速再生又はランダムアクセスを求める場合に、ユーザが求める倍速再生又はランダムアクセスを正確に実行することができない場合がある。これは、既存のＭＰＥＧファイルフォーマットがクライアントとサーバ間の通信網を考慮したものではなく、サーバでブロードキャストを考慮したファイルフォーマットに基づいて実現されているためである。
【０００７】
したがって、クライアントとサーバ間の通信網を考慮する場合には、既存のＭＰＥＧファイルフォーマットに基づいてユーザが求める倍速再生機能及びランダムアクセス機能を正確に提供することができない。したがって、既存のＭＰＥＧファイルフォーマットに基づいて倍速再生及びランダムアクセス機能を正確に提供する方法が長い間必要とされてきた。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明の目的は、少なくとも上述した問題点及び／又は不都合な点に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、ストリーミング方式／ダウンロード方式に基づくメディアコンテンツデータを正確に制御するためのメディアコンテンツデータ再生装置及び方法を提供することにある。
【０００９】
本発明の他の目的は、倍速再生機能及びランダムアクセス機能のためのストリームグループで構成されたメディアコンテンツデータを制御するためのメディアコンテンツデータ再生装置及び方法を提供することにある。
【００１０】
本発明のまた他の目的は、提供されるメディアコンテンツのセマンティック構成及び役割（role）情報を提供することにより様々なコンテンツタイプ及びユーザの嗜好に従って調整され制御されることができるメディアコンテンツデータを提供するためのメディアコンテンツデータ再生装置及び方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記のような目的を達成するために、本発明の一態様によれば、データ通信ネットワークにおけるクライアントのメディアコンテンツ再生方法を提供する。上記方法は、メディアコンテンツディスクリプターのリクエストをサーバに送信するステップと、特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを上記サーバから受信するステップと、上記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて上記特定のメディアコンテンツデータを受信するステップとを有することを特徴とする。
【００１２】
本発明の他の態様によれば、データ通信ネットワークにおけるサーバによる、クライアントのメディアコンテンツ再生をサポートする方法を提供する。上記方法は、メディアコンテンツディスクリプターのリクエストを上記クライアントから受信するステップと、特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを上記クライアントに送信するステップとを有することを特徴とする。
【００１３】
本発明のさらに他の態様によれば、データ通信ネットワークにおけるクライアントのメディアコンテンツ再生装置を提供する。上記装置は、メディアコンテンツディスクリプターのリクエストをサーバに送信し、特定の機能の実行のために構成された特定のメディアコンテンツデータのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを上記サーバから受信し、上記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて上記特定のメディアコンテンツデータを受信する制御器を有することを特徴とする。
【発明の効果】
【００１４】
本発明は、複数のソースコンテンツ又は複数のストリームを含む複合コンテンツを提供するにあたりに、ストリーミング方式及びダウンロード方式を用いるディジタルＴＶのようなビデオサービスにおいてトリックモードデータのイントラリフレッシュフレームの反復サイクルを一般的な再生のための一般モードデータのイントラリフレッシュフレームの反復サイクルより短く設定することにより、正確な倍速再生機能のサポート及びランダムアクセスの間にビット率の増加及び時間遅延を最小化することができるという効果がある。
【００１５】
また、本発明の実施形態によると、基本レイヤーのイントラリフレッシュフレームのタイムポイントとは異なるトリックモードデータレイヤーのイントラリフレッシュフレームのタイムポイントを設定することにより、ビットレートがイントラフレームに集中し、ピークを形成することを防止し、その結果、ビット率の平坦化を容易にすることができるという効果がある。
【００１６】
さらに、本発明の他の実施形態によると、ＰＩＰ（Picture-In-Picture）画面の複雑度を１／４又は１／Ｎ（ここで、Ｎは数十を示す）に減少させることによりＰＩＰを簡素に実現することができ、使用可能なビットレートが無線網又はインターネットプロトコル（ＩＰ）網でのように変化する場合に、ネットワーク状況に従って個別のトリックモードデータだけを送信することができるという効果もある。
【００１７】
一方、本発明の他の様々な効果は、本発明の実施形態の詳細な説明において明示的に又は暗示的に開示される。
【図面の簡単な説明】
【００１８】
【図１】従来の単一階層符号化のＩ、Ｐ、及びＢフレームの配列を示す図である。
【図２】従来の倍速再生及びランダムアクセスの時に発生する問題状況を示す図である。
【図３】本発明の実施形態によるメディアコンテンツ再生装置の内部構成を示すブロック図である。
【図４】本発明の実施形態によるメディアコンテンツ再生装置でのサーバとクライアント間の動作を示すフロー図である。
【図５】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図６】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図７】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図８】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図９】本発明の一実施形態によるメディアコンテンツ再生方法を示す図である。
【図１０】本発明の一実施形態によるメディアコンテンツ再生方法を示すフローチャートである。
【図１１】本発明の他の実施形態によるメディアコンテンツ再生方法を示す図である。
【発明を実施するための形態】
【００１９】
本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。下記の説明において、本発明の詳細な構成および要素のような本発明の詳細な説明において定義される特徴は、本発明の実施形態の包括的な理解を助けるために提供される。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明された実施形態の様々な変更及び変形が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【００２０】
以下の説明において、一般の速度でメディアコンテンツデータを再生する動作モードを“一般再生モード”又は“一般モード”と呼び、ユーザの特定の倍速機能のリクエストの際にｎ−倍速（ｎは、１倍速と等価である一般の速度の整数倍を示す特定の数字である）で再生する動作モードを“倍速再生モード”又は“倍速モード”と呼び、ユーザが特定の時点からの再生リクエストを“ランダムアクセスリクエスト”と呼び、ランダムアクセスリクエストに応じて開始される動作モードを“ランダムアクセスモード”と呼ぶ。また、倍速再生モードとランダムアクセスモードとを合わせて“トリックモード（trick mode）”とも呼んでよい。
【００２１】
本発明の実施形態は、メディアコンテンツデータ再生のための動作の間に倍速モード及び／又はランダムアクセスモードの時に発生し得る時間遅延を最小化する方法を提供する。このような方法において、ビデオストリーミング／ダウンロードサービスにより受信され圧縮されたメディアコンテンツデータを再生している間に、ユーザが倍速（例えば、２倍速又は０．５倍速）再生機能をリクエストするか又は特定の時点からメディアコンテンツデータの再生をリクエストする場合に、ユーザリクエストと再生開始との間の時間遅延を減少させることができ、これにより、ユーザのリクエストの時に正確な再生を可能にする。
【００２２】
また、本発明の実施形態は、倍速再生モード及び／又はランダムアクセスモードから一般再生モードにさらに切り替える場合にユーザが使いやすい動作方法を提供する。
【００２３】
本発明の実施形態に関連した技術の限定されない例であるＭＰＥＧ２、ＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４及びディジタルメディアの標準として最近台頭している高効率ビデオコーディング（ＨＶＣ）のようなビデオ圧縮技術は、圧縮効率を増加させるために次のような３つの方式を使用する。
【００２４】
圧縮効率性を増加させるための１番目の方式は、赤／緑／青（Red/Green/Blue：ＲＧＢ）入力を輝度／青いクロミナンス／赤いクロミナンス（luminance/blue-chrominance/red-chrominance：ＹＣｂＣｒ）入力に変換する方式である。このような方式において、ＲＧＢ入力で重複して存在する輝度及びクロミナンス情報は、Ｙ情報、Ｃｂ情報、及びＣｒ情報にそれぞれ変換する。
【００２５】
圧縮効率性を増加させるための２番目の方式は、この変換されたデータの空間的重複性（spatial redundancy）を除去する方式である。この場合には、１つの画面内の空間的類似性（spatial similarity）が離散コサイン変換（Discrete Cosine Transform：ＤＣＴ）、量子化（Quantization）、及び可変長符号化（Variable Length Coding：ＶＬＣ）を用いて除去される。
【００２６】
圧縮効率性を増加させるための３番目の方式は、時間的に相互に近い連続したイメージの部分の類似性に基づいて連続した画面間の時間的重複性（temporal redundancy）を除去する方式である。このような時間的重複性は、動き推定（Motion Estimation：ＭＥ）により測定される動きベクトル（Motion Vector：ＭＶ）を用いて差分パルスコード変調（Differential Pulse Code Modulation：ＤＰＣＭ）のような予測技術で除去することができる。
【００２７】
図１は、時間的重複性を除去するための方式の一例を示し、一般の単一階層符号化のイントラ（Ｉ）、予測（Predictive：Ｐ）、双方向性（Bi-directional：Ｂ）フレームの配列及び参照関係を示す。
【００２８】
時間的重複性を除去するために、ＭＰＥＧ技術において、図１に示すようにそれぞれのフレームのタイプを設定し、フレームのタイプをＩ、Ｐ、及びＢフレームに分類する。 独立したフレームであるＩフレームは、自身のデータだけを用いてデコードすることができる。Ｐフレームは前のＩフレームを参照してデコードされる。Ｂフレームは、前のＩフレーム及び次のＰフレームを参照してデコードされる。
【００２９】
また、すべての符号化方式において、一般的に、１番目の画面はＩフレームで符号化され、その次の画面は、Ｐフレーム又はＢフレームで符号化されることによりビット率を減少させることができる。しかしながら、Ｐフレーム及びＢフレームだけが連続して存在する場合には、受信側で復号化される時にＰ又はＢフレームにエラーが発生すると、連続したエラーが発生する可能性がある。この場合に、ユーザが特定のフレームに対するランダムアクセスをリクエストする場合に、対応するフレームに対する正確なランダムアクセスのためのデコードが実行されることが難しい場合がある。
【００３０】
したがって、Ｉフレームは、連続したＰフレームとＢフレームとの間で周期的に挿入され、これは、“イントラリフレッシュ（Intra-Refresh）”と呼ばれる。任意のＩフレームとその次のＩフレームとの間のフレームの個数をＧＯＰ（Group of Picture）と呼ぶ。図１の例では、ＧＯＰ値が９である。
【００３１】
図２は、一般的な再生のために設定された一般モードデータを倍速再生モード又はランダムアクセスモードで再生する場合に発生し得る問題点を説明する図である。
【００３２】
図２の上部のフレームは、一般的な再生のために構成された一般モードデータを示す。通常、一般モードデータ内にイントラリフレッシュのためのＩフレームを１５フレームごとに１回ずつ挿入する。この場合に、１秒当たりに３０フレームを含むように設定されたビデオクリップ、すなわち、１秒当たり２つのＩフレームが挿入されるように設定されたビデオクリップの場合に、２つのＩフレーム間の時間差が０．５秒であるので、ランダムアクセスがこのようなビデオクリップで実行される場合には、最大０．５秒までの時間遅延が発生し得る。このような問題は、放送のようなストリーミングビデオクリップだけではなく事前にダウンロードされ記憶されたビデオクリップを再生する時にも同一の問題点が発生し得る。
【００３３】
図２を参照して、一般モードデータにアクセスする２つの例を考える。具体的には、一般モードデータにおいてランダムアクセスが実行される例及び一般モードデータにおいて倍速再生が実行される例である。
【００３４】
まず、一般モードデータを用いてランダムアクセスモードを実行する場合について、ユーザによるランダムアクセスリクエストがＩフレーム２０１と次のＩフレーム２０３との間のＧＯＰ期間内の特定のフレームで発生する場合に、クライアントは、ランダムアクセスリクエストが発生した時点２００直後のＰフレーム２０５からデコードを開始する代わりに、特定の時間ｄ１だけ移動した後に次のＩフレーム２０３からデコードを開始する。これは、上述したように、最初のデコードがＩフレームから開始するためである。この場合に、ユーザがランダムアクセスをリクエストした時点が実際にデコードを開始する時点とは異なるために、２つの時点間の期間ではいずれのフレームも再生することができず、したがって、ユーザがリクエストしたランダムアクセス動作を正確に実行することができない。
【００３５】
また、一般モードデータを用いて倍速再生を実行する場合について、一般モードデータの倍速再生を行う場合に高速再生のためにＩフレームだけを符号化する。したがって、整数倍（例えば、１倍及び２倍）の倍速再生よりむしろ倍速再生（例えば、１．２倍速又は０．４倍速）機能を効率的にサポートすることが難しい。
【００３６】
したがって、本発明の実施形態は、効率的な倍速再生モードをサポートし、ランダムアクセスリクエストの時に発生する時間遅延を最小化する方法を提供する。
【００３７】
図３は、本発明の実施形態によるメディアコンテンツデータ再生装置の内部構成を示すブロック図である。
【００３８】
図３を参照すると、クライアント３５０は、通信網（図示せず）を通して外部サーバ３００に接続される。クライアント３５０は、ストリーミング方式又はダウンロード方式によりサーバ３００から受信したメディアコンテンツデータを実時間で再生するか、又は受信したメディアコンテンツデータのパーツを格納部３５７に記録し、格納されたメディアコンテンツデータを分析し、分析されたメディアコンテンツデータを再生する装置である。クライアント３５０は、ディジタルテレビジョン（Digital TeleVisions：ＤＴＶｓ）、パーソナルコンピュータ、ディジタル多用途ディスク（Digital Versatile Disc：ＤＶＤ）プレーヤーなどを含む。
【００３９】
本発明の実施形態において、図３に示すクライアント３５０がメディアコンテンツデータを格納する機能を実行することができるが、本発明はこのような構成に限定されず、クライアント３５０は、本発明の実施形態に従って格納機能なしにメディアコンテンツデータを実時間で再生する機能だけを実行してもよい。クライアント３５０をサーバ３００に接続する通信網は、任意の有線又は無線通信ネットワークを含む。
【００４０】
サーバ３００は、放送局、通信オペレータ、映画製作者、又はプライベートコンテンツプロバイダーが運営する。サーバ３００は、オーディオデータ、ビデオデータ、テキストデータ、イメージデータなど及びこれらに対するメタデータのような各種複合メディアコンテンツデータを格納する。
【００４１】
図３を参照すると、クライアント３５０は、メディアコンテンツデータをサーバ３００から受信する。しかしながら、クライアント３５０は、サーバ３００以外のデータベースからメディアコンテンツデータを受信してもよい。
【００４２】
クライアント３５０は、通信部３５１、格納部３５７、分析器３５５、デコーダ３６１、制御器３５３、及び出力部３５９を含む。図３には図示されていないが、クライアント３５０は、ユーザとのインターフェースを担当するユーザインターフェースをさらに含んでもよい。ユーザは、ユーザインターフェースを用いてユーザのリクエストを制御器３５３に送信する。一般的に、ユーザの入力を受信するユーザインターフェースは、キーボード、マウス、タッチスクリーン、ハプティック（haptic）デバイス、及びマイクロフォンのような物理的な変換部を含むことができる。ユーザインターフェースは、ユーザから命令、テキスト、イベント、数字、又は音声情報を受信し、受信したデータを制御器３５３に提供する。
【００４３】
本発明の実施形態によれば、ユーザは、制御器３５３がユーザインターフェースを用いて現在のＧＯＰ期間に対応するメディアコンテンツデータを倍速再生モードで再生するように制御し、現在のＧＯＰ期間のメディアコンテンツデータが倍速再生モードで再生されている間に、次のＧＯＰ期間のメディアコンテンツデータをどのように再生するかを設定することができる。
【００４４】
通信部３５１は、有線又は無線ネットワークを通してサーバ３００又は第３のデータベース（図示せず）に接続され、サーバ３００又は第３のデータベースとデータを交換する。クライアント３５０が無線ネットワーク技術を使用する場合に、通信部３５１は、一般的なデータパケット通信方法を用いてサーバ３００とクライアント３５０間の制御命令及びデータを送受信することができる。通信方法は、無線ローカルエリアネットワーク（Wireless Local Area Network：ＷＬＡＮ）、ブルートゥース（登録商標）、ジグビー（Zigbee：登録商標）、無線ブロードバンド（Wireless Broadband：ＷｉＢｒｏ：登録商標）、無線メディア（Wireless Media：ＷｉＭｅｄｉａ）、第３世代（３Ｇ）符号分割多重接続（ＣＤＭＡ）のような移動通信技術などを含むことができる。
【００４５】
格納部３５７は、通信部３５１がサーバ３００又は第３のデータベースから受信した情報を格納する。分析器３５５は、格納部３５７に格納されたメディアコンテンツデータを分析し、分析されたメディアコンテンツデータをデコーダ３６１に提供する。
【００４６】
デコーダ３６１は、分析器３５５が分析したメディアコンテンツデータを本発明の実施形態によるＭＰＥＧファイル構造に基づく符号化方式の逆の方式を用いてデコードし、デコードされたメディアコンテンツデータを出力部３５９に提供する。この時に、メディアコンテンツデータが異なるタイプのデータを含んでいる場合に、デコーダ３６１は、必要とされるメディアコンテンツデータを選択し、これを出力部３５９に提供する。
【００４７】
例えば、メディアコンテンツデータが一般再生モードのための“一般モードデータ”及び倍速再生モード又はランダムアクセスモードのための“トリックモードデータ”を含み、倍速再生モードが選択される場合に、制御器３５３は、トリックモードデータを選択し、これをデコーダ３６１に提供することができる。
【００４８】
出力部３５９は、デコーダ３６１によりデコードされたメディアコンテンツデータを画面に出力することができる。また、出力部３５９は、クライアント３５０の全般的な状態及びユーザがユーザインターフェースを通して入力した情報を画面又はスピーカに出力することができる。
【００４９】
図３には図示されていないが、クライアント３５０は、別途のシステム時間情報に基づいて動作する。
【００５０】
ユーザは、最初のＧＯＰ期間のメディアコンテンツデータが倍速再生モードで再生される間に、ユーザインターフェースを通して次のＧＯＰ期間のメディアコンテンツデータを再生するための再生モードを設定することができる。場合によっては、クライアント３５０は、ユーザ動作に関係なくクライアント３５０の内部に予め定義された方法を用いて次のＧＯＰ期間のメディアコンテンツデータをデコードしてもよい。
【００５１】
以下に述べられる表１は、本発明の実施形態によるメディアコンテンツディスクリプターの構造を示す。メディアコンテンツディスクリプターは、サーバ又は第３のデータベースから端末又はクライアントに提供される情報であり、端末（又はクライアント）が対応するメディアコンテンツデータと関連した機能を実行するために必要とする様々な情報を含む。
【００５２】
例えば、表１を参照すると、本発明の一実施形態によるメディアコンテンツディスクリプターは、一般再生モードのための情報だけでなく、倍速再生モード及びランダムアクセスモードのための情報も含む。
【００５３】
メディアコンテンツディスクリプターは、メディアコンテンツサービスを最初に開始する時にメディアコンテンツデータに含まれるか又は周期的にメディアコンテンツデータに含まれ、サーバ又は第３のデータベースから端末（又はクライアント）に送信されるとよい。一例において、メディアコンテンツディスクリプターに含まれる情報の一部だけが端末に送信されることもある。この場合に、端末は、この送信された情報に対応する機能だけを実行してもよい。
【００５４】
【表１】
表１を参照してメディアコンテンツディスクリプターについてさらに詳細に説明する。
【００５５】
メディアコンテンツディスクリプターは、マニフェスト（Manifest）情報及びファイル構造（File structure）情報を含む。
【００５６】
メディアコンテンツディスクリプターにより参照されるスキーマ（Schema）情報を示す‘コンテンツ（Contents）’属性として、メディアコンテンツのマニフェスト情報は、‘タイトル（Title）’情報、‘シノプシス（Synopsis）’情報、メディアコンテンツのクリエーター情報を含む‘OriginSite’情報、メディアコンテンツのクリエーターの名称を含んでいる‘OriginSiteName’、メディアコンテンツの識別のための‘ContentID’、メディアコンテンツの制御情報を参照することができる‘ContentsURL’情報及びメディアコンテンツ自体を示す‘ContentItem’情報のうちの少なくとも１つを含む。
【００５７】
メディアコンテンツデータのファイル構造を示すファイル構造情報は、‘ContentType’属性のコンテナー（container）エレメントとして、ストリーミング方式又はダウンロード方式において実際のメディアコンテンツデータの位置決め方法を示す‘URLTemplate’、次のＧＯＰ単位に基づいて制御される‘NextControlURL’、倍速情報及びランダムアクセスの際にサポート可能な時間に関する情報のような付加情報を参照することができる‘RelDataURL’、及び一般モードで使用可能な一般モードデータ及び倍速再生モード又はランダムアクセスモードの時に使用可能なトリックモードデータを識別することができる‘TrackID’のような情報を含むことができる。
【００５８】
クライアント３５０の制御器３５３は、マニフェスト情報に含まれているContentURLのMainContentsDescription.xmlファイルを分析し、所望するメディアコンテンツデータ情報に対するリクエストをＧＯＰ単位でサーバ３００に送信することができる。例えば、最初の状態での一般再生モードでビデオクリップを視聴している間に、ユーザが倍速再生機能又はランダムアクセス機能のリクエストの時に一般再生モードから倍速再生モード又はランダムアクセスモードに切り替える場合がある。この場合に、クライアント３５０は、倍速再生又はランダムアクセスのためのマニフェスト情報に対するリクエストをサーバ３００に送信する。表１でのマニフェスト情報をサーバ３００から受信する時に、クライアント３５０は、MainContentsDescription.xmlファイルに対するリクエストをマニフェスト情報に含まれたContentsURL情報に含まれているアドレスに送信し、このアドレスから倍速再生又はランダムアクセスのためのトリックモードデータを受信することができる。
【００５９】
図４は、本発明の実施形態によるメディアコンテンツデータ再生装置を有するクライアントとサーバ間の動作を示す図である。
【００６０】
図４を参照すると、表１で説明したデータファイル構造に対応するサーバ３００とクライアント３５０間の動作が実行される。その動作によると、クライアントのユーザが特定のメディアコンテンツデータをサーバから受信し、受信したデータを再生する間に倍速再生又はランダムアクセスを希望する場合に、クライアントは、マニフェスト情報に対するリクエストをサーバに送信し、このリクエストに応じてマニフェスト情報をサーバから受信し、この受信された情報を分析し、この分析された情報が、サーバが倍速再生又はランダムアクセス機能をサポートすることを示す場合に、倍速再生又はランダムアクセス機能をリクエストする。図４では、倍速再生がリクエストされると仮定する。
【００６１】
より具体的に、クライアント３５０のユーザが特定のメディアコンテンツデータを受信し再生する間に倍速再生を希望する場合に、クライアント３５０は、ステップ４０１において、サーバ３００がマニフェスト情報を送信することをリクエストする。それに応じて、ステップ４０３において、サーバ３００は、リクエストされたマニフェスト情報をクライアント３５０に送信する。
【００６２】
ステップ４０５において、クライアント３５０は、受信されたマニフェスト情報に含まれているContentURLを有するMainContentsDescription.xmlファイルを分析し、この分析された情報が、サーバが倍速再生機能をサポートすることを示す場合に、倍速再生機能に対するリクエストをContentURLに含まれているサーバ３００のアドレス（例えば、ＵＲＬ）に送信する。それに応じて、ステップ４０７において、サーバ３００は、倍速再生に関連したフラグメントボックスをクライアント３５０に送信する。参考に、‘フラグメントボックス’の用語は、特定の機能の実行に必要とされる情報の集合を意味する。クライアント３５０は、フラグメントボックスに含まれる情報を用いて倍速再生を実行する。
【００６３】
一方、図５乃至図８は、本発明の実施形態による一般モードデータ及びトリックモードデータの構成を説明する図である。
【００６４】
上述したように、一般モードデータは、一般再生モードで使用可能なデータであり、トリックモードデータは、倍速再生モード又はランダムアクセスモードの時に使用可能なデータである。本発明の実施形態によると、トリックモードデータは、通常に、一般モードデータに比べて１／４倍又は１／Ｎ（ここで、Ｎは、数十、すなわち、１０、２０、３０などである）のサイズで設定され、トリックモードデータのＧＯＰ値も一般モードデータのＧＯＰ値より小さく設定されることによりＩフレームの回数（すなわち、Ｉフレームの発生の回数）が増加する。言い換えれば、トリックモードデータは、一般モードデータの量より全体的に少ない量を有し、トリックモードデータのＩフレームは、一般モードデータのＩフレームよりさらに頻繁に現れる。したがって、トリックモードデータの使用は、一般モードデータの使用に比べて送受信及びデコードの速度を増加させる。結果的に、倍速再生及びランダムアクセスの時の遅延時間が減少し、ユーザがメディアデータの正確な再生及び／又は探索を行うことができる。本発明の実施形態に従って、一般モードデータもやはり倍速再生モード又はランダムアクセスモードで再生されることができ、トリックモードデータも一般再生モードで再生されることができる。しかしながら、ここでは、ユーザが一般モードデータを一般再生モードの時に使用し、トリックモードデータを倍速再生モード又はランダムアクセスモードで使用することを選択するものと仮定する。
【００６５】
図５の（ａ）は、ＧＯＰ＝９である一般モードデータを示し、図５の（ｂ）は、ＧＯＰ＝３であるトリックモードデータを示す。図５の（ｂ）のトリックモードデータは、ＧＯＰ値及びデータサイズの観点で図５の（ａ）の一般モードデータより小さい。
【００６６】
図６乃至図８は、本発明の実施形態による一般モードデータ及びトリックモードデータの他の構成を示す図である。
【００６７】
図６の（ａ）乃至図６の（ｃ）の一例を示し、ここで、図６の（ａ）及び図６の（ｂ）のデータは、それぞれ図５の（ａ）及び図５の（ｂ）のデータと同一である。図６の（ｃ）は、Ｉフレームだけを含むように構成されたトリックモードデータを示す。トリックモードデータがＩフレームだけを含む場合に、倍速再生の時の再生速度及びランダムアクセスの時の移動速度はさらに増加することができる。
【００６８】
図７の（ａ）乃至図７の（ｃ）は、他の例を示し、ここで、図７の（ａ）は、複合（または、マルチレイヤー）一般モードデータの一例を示す。例えば、それぞれのフレームが３個のレイヤーデータを含む場合に、３個のレイヤーデータを用いてデータスケーラービリティ（scalability）を実現することができる。図７の（ｂ）及び図７の（ｃ）のデータは、それぞれ図６の（ｂ）及び図６の（ｃ）のデータと同一である。
【００６９】
図８の（ａ）乃至図８の（ｃ）は、トリックモードデータをスケーラブルなデータで実現する他の例を示す図である。すなわち、図８の（ａ）の一般モードデータは、図５の（ａ）の一般モードデータと同一である。しかしながら、図８の（ｂ）及び図８の（ｃ）の複合（又は、マルチレイヤー）トリックモードデータは、それぞれ図６の（ｂ）及び図６の（ｃ）のトリックモードデータの複数の集合を結合することにより構成され、これにより、スケーラービリティをサポートする。
【００７０】
図７及び図８に示すように、本発明のメディアコンテンツデータは、マルチレイヤー一般モードデータ（図７の（ａ））及び／又はマルチレイヤートリックモードデータ（図８の（ｂ）及び図８の（ｃ））を含むことができる。マルチレイヤーデータ構造で構成される場合に、メディアコンテンツデータは、スケーラービリティをサポートすることができる。一方、一般モードデータ及びトリックモードデータは、相互に独立して存在するので、相互に異なる時点で独立して再生されることができる。
【００７１】
上述したように、ユーザは、一般モードデータを一般モードで再生する。また、ユーザは、倍速再生モード又はランダムアクセスモードでトリックモードデータの再生を選択することができる。例えば、一般モードデータが一般モードで再生されている間に、ユーザが倍速再生モードを選択する場合に、クライアントは、トリックモードデータをリクエストし、トリックモードデータを倍速再生モードで再生する。
【００７２】
一般モードデータが一般モードで再生されている間に、ユーザが倍速再生モードでトリックモードデータの再生を選択する場合に、制御器３５３は、一般モードデータ内の時間情報を出力部３５９及びデコーダ３６１に提供するシステム時間クロック情報を分析した後に、この分析された結果に従ってトリックモードデータをリクエストする。したがって、一般モードデータの再生の間に２倍速再生がリクエストされる場合に、クライアントは、トリックモードデータを２倍の速度で再生する。
【００７３】
図９の（ａ）及び図９の（ｂ）は、本発明の実施形態に従ってトリックモードデータを用いてランダムアクセスを実行する動作を説明する図である。図９の（ａ）は一般モードデータを示し、図９の（ｂ）はトリックモードデータを示す。
【００７４】
図９の（ａ）及び図９の（ｂ）を参照すると、一般モードデータ（図９の（ａ）に図示されている）が再生されている間に、時点９０１でユーザによるランダムアクセスリクエストが行われる。従来では、一般モードデータ（図９の（ａ））を用いてランダムアクセスが実行される場合に、時点９０１の次のＰフレーム９０７ではなく次のＩフレーム９０３からデコードを開始するためにｄ１の時間遅延を発生させる。しかしながら、トリックモードデータ（図９の（ｂ）に図示されている）を用いてランダムアクセスが実行される場合に、時点９０１の次のＩフレーム９０５からデコードを開始することができるために時間遅延をｄ２に減少させる。ｄ２は、従来の時間遅延ｄ１より格段に短いことをわかる。
【００７５】
図１０は、本発明の一実施形態によるメディアコンテンツ再生方法を示すフローチャートであり、クライアント３５０が一般モードデータを再生するためにメディアコンテンツディスクリプターに対するリクエストをサーバ３００に送信したことを前提とする。
【００７６】
図１０を参照すると、ステップ７０１において、クライアント３５０は、このリクエストに応じてサーバ３００から受信したメディアコンテンツディスクリプターを分析する。ステップ７０３において、一般モードデータに関する内容がメディアコンテンツディスクリプターに含まれている場合に、クライアント３５０は、サーバ３００からの一般モードデータのリクエスト／受信を行い、この受信した一般モードデータをデコードする。
【００７７】
ステップ７０５において、クライアント３５０は、一般モードデータが再生されている間に倍速再生モード又はランダムアクセスモードへの切り替えリクエストがユーザから受信されたか否かを判定する。倍速再生モード又はランダムアクセスモードへの切り替えリクエストを受信する時に、クライアント３５０は、一般モードデータのデコードを中断し、ステップ７０７に進む。
【００７８】
ステップ７０７において、クライアント３５０は、メディアコンテンツディスクリプターに含まれているトラック情報（すなわち、図４を参照して説明した‘ContentURL’に含まれているサーバのＵＲＬアドレス）に従ってトリックモードデータに対するリクエストをＵＲＬに送信し、リクエストされたトリックモードデータを受信する。ステップ７０９において、クライアント３５０は、受信されたトリックモードデータに対応するメディアコンテンツデータをデコードする。
【００７９】
しかしながら、ステップ７０５において、倍速再生モード又はランダムアクセスモードへの切り替えリクエストがユーザから受信されることができない時に、クライアント３５０は、ステップ７０９に進み、一般再生モードで一般モードデータを継続してデコードし再生する。
【００８０】
図１１の（ａ）及び図１１の（ｂ）は、本発明の他の実施形態によるメディアコンテンツ再生方法を示す図である。
【００８１】
図１１の（ａ）及び図１１の（ｂ）の例において、ユーザは、一般モードデータを倍速再生モード又はランダムアクセスモードで再生しないことを選択した場合を前提とする。トリックモードデータが倍速再生モード又はランダムアクセスモードで再生されている間に、ユーザが倍速再生モード又はランダムアクセスモードから一般モードへの切り替えをリクエストする場合に、クライアントは、本発明の実施形態によるモード切り替えを実行し、一般モードでトリックモードデータを再生する。図１１の（ａ）は一般モードデータを示し、図１１の（ｂ）はトリックモードデータを示す。
【００８２】
この前提に従って、クライアント３５０は、倍速再生モード又はランダムアクセスモードでトリックモードデータ（図１１の（ｂ）に示すように）を用いてメディアコンテンツを再生する。トリックモードデータ（図１１の（ｂ）に示すように）が再生されている間に、ユーザが時点１００１で一般モードへの切り替えをリクエストする場合に、クライアント３５０は、時点１００１でトリックモードデータの再生（すなわち、トリック再生）を中断し、一般モードデータ（図１１の（ａ））を再生する。しかしながら、この場合に、上述したように、一般モードデータの復号化をＩフレームから開始するために、トリック再生の終了時点１００１とトリック再生の終了時点１００１の後の一般モードデータでの１番目のＩフレーム１００３との間で時間差が発生し、これにより遅延時間が生じる。この遅延時間の間にはコンテンツが再生されない。
【００８３】
本発明の他の実施形態によると、遅延時間の間に連続したコンテンツ再生を保証するために、このような遅延時間の間に既存のトリックモードデータを用いて連続した再生を行う。すなわち、トリック再生の終了時点１００１と一般モードデータでの１番目のＩフレーム１００３との間の時間期間の間に、トリックモードデータのフレーム１００５は、Ｉ＝＝＞Ｐ＝＝＞Ｐフレームの順序にデコードされる。その後に、一般モードデータで新たなＧＯＰ期間内の１番目のＩフレーム１００３の受信が完了する場合に、対応する一般モードデータをデコードすることによりコンテンツを再生する。
【００８４】
本発明の他の実施形態によると、図３を参照して説明したメディアコンテンツ再生装置は、次のように動作する。
【００８５】
制御器３５３は、倍速再生モード又はランダムアクセスモードから一般モードへの切り替えリクエストがユーザから受信されたか否かを判定する。一般モードへの切り替えリクエストを受信する際に、制御器３５３は、この切り替えリクエストを分析器３５５に通知する。分析器３５５は、受信されたメディアコンテンツディスクリプターのマニフェスト情報に含まれているサーバ３００のContentURLを分析し、分析された結果に従ってサーバ３００のＵＲＬを制御器３５３に提供する。制御器３５３は、新たなＩフレームからＧＯＰ単位で一般モードデータに対するリクエストをＵＲＬに送信する。
【００８６】
デコーダ３６１は、一般モードデータの新たなＧＯＰ期間内のＩフレーム情報をサーバ３００から受信し、この受信されたフレームデータをデコードするまで既存のトリックモードデータを継続してでコードする。一般モードデータの新たなＧＯＰ期間内の１番目のＩフレームを受信する時に、制御器３５３はトリックモードデータのデコードを中断し、一般モードデータをデコードするようにデコーダ３６１を制御する。デコーダ３６１は、制御器３５３の制御の下に一般モードデータをデコードする。
【００８７】
一方、本発明で説明したマニフェスト情報がメディアコンテンツサービスの提供、サービス設定、及び／又はサービス初期化のための情報を提供するために使用されるので、マニフェスト情報は、例えば、別の名称として‘構成情報’とも呼ばれてよい。しかしながら、マニフェスト情報と同一の意味又は役割を有する情報でありさえすれば、別のどの名称でも使用可能である。また、本発明の実施形態を説明するために必要とされる基本的なフィールド及び／又はこれらの属性情報について説明しているが、本発明の各実施形態で説明される設定ファイルの情報は、使用環境又はサービスに従って追加の情報をフィールド及び属性としてさらに含んでもよい。さらに、設定ファイルに含まれる情報の論理的意味を図示し説明しているが、この情報は、システム及びサービス製造／提供環境に従って拡張マークアップ言語（ｘｍｌ）、２進データ、及びフォーマットされた情報構造のような様々な情報表現構造又はフォーマットの形態で表現されてもよい。
【００８８】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【技術分野】
【０００１】
本発明は、メディアコンテンツデータ再生装置及び方法に関し、特に、データ通信ネットワークから受信したメディアコンテンツデータの再生に関する倍速機能（X-speed play function）（ここで、Ｘは特定の数字）及びランダムアクセス（Random Access）機能の遅延を最小化するメディアコンテンツデータ再生装置及び方法に関する。
【背景技術】
【０００２】
通常、データ通信網を通して様々なメディアコンテンツサービス（media contents service）にアクセスする方法は、ダウンロード（download）方式及びストリーミング（streaming）方式に大別することができる。このメディアコンテンツサービスは、放送、映画、及び音楽のような様々なタイプのディジタルメディアデータ（digital media data）により提供されるサービスを意味する。この時、“ディジタルメディアデータ”は、映像、音響、場面（scene）などのような関連するメディアコンテンツを構成するディジタル情報を意味する。
【０００３】
ダウンロード方式は、ユーザが所望するメディアコンテンツサービスを構成するディジタルメディアデータを非実時間でダウンロードし、ディジタルメディアデータを記憶媒体に格納し、この格納されたディジタルメディアデータを所望する時間に再生できるようにする。したがって、ダウンロード方式は、映画及びドラマのような非実時間メディアコンテンツサービスに主に使用される。
【０００４】
ストリーミング方式は、ユーザが現在必要としているディジタルメディアデータを受信し、この受信されたディジタルメディアデータを実時間で再生できるようにする。したがって、ストリーミング方式は、ニュース及びスポーツ中継のような生放送に対応する実時間メディアコンテンツサービスに主に使用される。
【０００５】
一方、メディアコンテンツサービスを受信する間に、ユーザは、一般的な再生速度よりさらに速い再生速度でメディアコンテンツデータを再生（これを“倍速再生”と呼ぶ）するか又は現在再生している部分でない特定の部分を再生（これを“ランダムアクセス”と呼ぶ）することを希望する場合がある。
【０００６】
通常、ユーザがＭＰＥＧ（Moving Picture Experts Group）ファイルフォーマットに基づく倍速再生又はランダムアクセスを求める場合に、ユーザが求める倍速再生又はランダムアクセスを正確に実行することができない場合がある。これは、既存のＭＰＥＧファイルフォーマットがクライアントとサーバ間の通信網を考慮したものではなく、サーバでブロードキャストを考慮したファイルフォーマットに基づいて実現されているためである。
【０００７】
したがって、クライアントとサーバ間の通信網を考慮する場合には、既存のＭＰＥＧファイルフォーマットに基づいてユーザが求める倍速再生機能及びランダムアクセス機能を正確に提供することができない。したがって、既存のＭＰＥＧファイルフォーマットに基づいて倍速再生及びランダムアクセス機能を正確に提供する方法が長い間必要とされてきた。
【発明の概要】
【発明が解決しようとする課題】
【０００８】
本発明の目的は、少なくとも上述した問題点及び／又は不都合な点に取り組み、少なくとも以下の便宜を提供することにある。すなわち、本発明の目的は、ストリーミング方式／ダウンロード方式に基づくメディアコンテンツデータを正確に制御するためのメディアコンテンツデータ再生装置及び方法を提供することにある。
【０００９】
本発明の他の目的は、倍速再生機能及びランダムアクセス機能のためのストリームグループで構成されたメディアコンテンツデータを制御するためのメディアコンテンツデータ再生装置及び方法を提供することにある。
【００１０】
本発明のまた他の目的は、提供されるメディアコンテンツのセマンティック構成及び役割（role）情報を提供することにより様々なコンテンツタイプ及びユーザの嗜好に従って調整され制御されることができるメディアコンテンツデータを提供するためのメディアコンテンツデータ再生装置及び方法を提供することにある。
【課題を解決するための手段】
【００１１】
上記のような目的を達成するために、本発明の一態様によれば、データ通信ネットワークにおけるクライアントのメディアコンテンツ再生方法を提供する。上記方法は、メディアコンテンツディスクリプターのリクエストをサーバに送信するステップと、特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを上記サーバから受信するステップと、上記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて上記特定のメディアコンテンツデータを受信するステップとを有することを特徴とする。
【００１２】
本発明の他の態様によれば、データ通信ネットワークにおけるサーバによる、クライアントのメディアコンテンツ再生をサポートする方法を提供する。上記方法は、メディアコンテンツディスクリプターのリクエストを上記クライアントから受信するステップと、特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを上記クライアントに送信するステップとを有することを特徴とする。
【００１３】
本発明のさらに他の態様によれば、データ通信ネットワークにおけるクライアントのメディアコンテンツ再生装置を提供する。上記装置は、メディアコンテンツディスクリプターのリクエストをサーバに送信し、特定の機能の実行のために構成された特定のメディアコンテンツデータのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを上記サーバから受信し、上記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて上記特定のメディアコンテンツデータを受信する制御器を有することを特徴とする。
【発明の効果】
【００１４】
本発明は、複数のソースコンテンツ又は複数のストリームを含む複合コンテンツを提供するにあたりに、ストリーミング方式及びダウンロード方式を用いるディジタルＴＶのようなビデオサービスにおいてトリックモードデータのイントラリフレッシュフレームの反復サイクルを一般的な再生のための一般モードデータのイントラリフレッシュフレームの反復サイクルより短く設定することにより、正確な倍速再生機能のサポート及びランダムアクセスの間にビット率の増加及び時間遅延を最小化することができるという効果がある。
【００１５】
また、本発明の実施形態によると、基本レイヤーのイントラリフレッシュフレームのタイムポイントとは異なるトリックモードデータレイヤーのイントラリフレッシュフレームのタイムポイントを設定することにより、ビットレートがイントラフレームに集中し、ピークを形成することを防止し、その結果、ビット率の平坦化を容易にすることができるという効果がある。
【００１６】
さらに、本発明の他の実施形態によると、ＰＩＰ（Picture-In-Picture）画面の複雑度を１／４又は１／Ｎ（ここで、Ｎは数十を示す）に減少させることによりＰＩＰを簡素に実現することができ、使用可能なビットレートが無線網又はインターネットプロトコル（ＩＰ）網でのように変化する場合に、ネットワーク状況に従って個別のトリックモードデータだけを送信することができるという効果もある。
【００１７】
一方、本発明の他の様々な効果は、本発明の実施形態の詳細な説明において明示的に又は暗示的に開示される。
【図面の簡単な説明】
【００１８】
【図１】従来の単一階層符号化のＩ、Ｐ、及びＢフレームの配列を示す図である。
【図２】従来の倍速再生及びランダムアクセスの時に発生する問題状況を示す図である。
【図３】本発明の実施形態によるメディアコンテンツ再生装置の内部構成を示すブロック図である。
【図４】本発明の実施形態によるメディアコンテンツ再生装置でのサーバとクライアント間の動作を示すフロー図である。
【図５】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図６】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図７】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図８】本発明の実施形態によるメディアコンテンツディスクリプターにより定義されるファイル構成を示す図である。
【図９】本発明の一実施形態によるメディアコンテンツ再生方法を示す図である。
【図１０】本発明の一実施形態によるメディアコンテンツ再生方法を示すフローチャートである。
【図１１】本発明の他の実施形態によるメディアコンテンツ再生方法を示す図である。
【発明を実施するための形態】
【００１９】
本発明の望ましい実施形態を添付の図面を参照して詳細に説明する。下記の説明において、本発明の詳細な構成および要素のような本発明の詳細な説明において定義される特徴は、本発明の実施形態の包括的な理解を助けるために提供される。したがって、本発明の範囲及び趣旨を逸脱することなく、ここに説明された実施形態の様々な変更及び変形が可能であるということは、当該技術分野における通常の知識を有する者には明らかである。また、明瞭性と簡潔性の観点から、当業者に良く知られている機能や構成に関する具体的な説明は、省略する。
【００２０】
以下の説明において、一般の速度でメディアコンテンツデータを再生する動作モードを“一般再生モード”又は“一般モード”と呼び、ユーザの特定の倍速機能のリクエストの際にｎ−倍速（ｎは、１倍速と等価である一般の速度の整数倍を示す特定の数字である）で再生する動作モードを“倍速再生モード”又は“倍速モード”と呼び、ユーザが特定の時点からの再生リクエストを“ランダムアクセスリクエスト”と呼び、ランダムアクセスリクエストに応じて開始される動作モードを“ランダムアクセスモード”と呼ぶ。また、倍速再生モードとランダムアクセスモードとを合わせて“トリックモード（trick mode）”とも呼んでよい。
【００２１】
本発明の実施形態は、メディアコンテンツデータ再生のための動作の間に倍速モード及び／又はランダムアクセスモードの時に発生し得る時間遅延を最小化する方法を提供する。このような方法において、ビデオストリーミング／ダウンロードサービスにより受信され圧縮されたメディアコンテンツデータを再生している間に、ユーザが倍速（例えば、２倍速又は０．５倍速）再生機能をリクエストするか又は特定の時点からメディアコンテンツデータの再生をリクエストする場合に、ユーザリクエストと再生開始との間の時間遅延を減少させることができ、これにより、ユーザのリクエストの時に正確な再生を可能にする。
【００２２】
また、本発明の実施形態は、倍速再生モード及び／又はランダムアクセスモードから一般再生モードにさらに切り替える場合にユーザが使いやすい動作方法を提供する。
【００２３】
本発明の実施形態に関連した技術の限定されない例であるＭＰＥＧ２、ＭＰＥＧ４、Ｈ．２６３、Ｈ．２６４及びディジタルメディアの標準として最近台頭している高効率ビデオコーディング（ＨＶＣ）のようなビデオ圧縮技術は、圧縮効率を増加させるために次のような３つの方式を使用する。
【００２４】
圧縮効率性を増加させるための１番目の方式は、赤／緑／青（Red/Green/Blue：ＲＧＢ）入力を輝度／青いクロミナンス／赤いクロミナンス（luminance/blue-chrominance/red-chrominance：ＹＣｂＣｒ）入力に変換する方式である。このような方式において、ＲＧＢ入力で重複して存在する輝度及びクロミナンス情報は、Ｙ情報、Ｃｂ情報、及びＣｒ情報にそれぞれ変換する。
【００２５】
圧縮効率性を増加させるための２番目の方式は、この変換されたデータの空間的重複性（spatial redundancy）を除去する方式である。この場合には、１つの画面内の空間的類似性（spatial similarity）が離散コサイン変換（Discrete Cosine Transform：ＤＣＴ）、量子化（Quantization）、及び可変長符号化（Variable Length Coding：ＶＬＣ）を用いて除去される。
【００２６】
圧縮効率性を増加させるための３番目の方式は、時間的に相互に近い連続したイメージの部分の類似性に基づいて連続した画面間の時間的重複性（temporal redundancy）を除去する方式である。このような時間的重複性は、動き推定（Motion Estimation：ＭＥ）により測定される動きベクトル（Motion Vector：ＭＶ）を用いて差分パルスコード変調（Differential Pulse Code Modulation：ＤＰＣＭ）のような予測技術で除去することができる。
【００２７】
図１は、時間的重複性を除去するための方式の一例を示し、一般の単一階層符号化のイントラ（Ｉ）、予測（Predictive：Ｐ）、双方向性（Bi-directional：Ｂ）フレームの配列及び参照関係を示す。
【００２８】
時間的重複性を除去するために、ＭＰＥＧ技術において、図１に示すようにそれぞれのフレームのタイプを設定し、フレームのタイプをＩ、Ｐ、及びＢフレームに分類する。 独立したフレームであるＩフレームは、自身のデータだけを用いてデコードすることができる。Ｐフレームは前のＩフレームを参照してデコードされる。Ｂフレームは、前のＩフレーム及び次のＰフレームを参照してデコードされる。
【００２９】
また、すべての符号化方式において、一般的に、１番目の画面はＩフレームで符号化され、その次の画面は、Ｐフレーム又はＢフレームで符号化されることによりビット率を減少させることができる。しかしながら、Ｐフレーム及びＢフレームだけが連続して存在する場合には、受信側で復号化される時にＰ又はＢフレームにエラーが発生すると、連続したエラーが発生する可能性がある。この場合に、ユーザが特定のフレームに対するランダムアクセスをリクエストする場合に、対応するフレームに対する正確なランダムアクセスのためのデコードが実行されることが難しい場合がある。
【００３０】
したがって、Ｉフレームは、連続したＰフレームとＢフレームとの間で周期的に挿入され、これは、“イントラリフレッシュ（Intra-Refresh）”と呼ばれる。任意のＩフレームとその次のＩフレームとの間のフレームの個数をＧＯＰ（Group of Picture）と呼ぶ。図１の例では、ＧＯＰ値が９である。
【００３１】
図２は、一般的な再生のために設定された一般モードデータを倍速再生モード又はランダムアクセスモードで再生する場合に発生し得る問題点を説明する図である。
【００３２】
図２の上部のフレームは、一般的な再生のために構成された一般モードデータを示す。通常、一般モードデータ内にイントラリフレッシュのためのＩフレームを１５フレームごとに１回ずつ挿入する。この場合に、１秒当たりに３０フレームを含むように設定されたビデオクリップ、すなわち、１秒当たり２つのＩフレームが挿入されるように設定されたビデオクリップの場合に、２つのＩフレーム間の時間差が０．５秒であるので、ランダムアクセスがこのようなビデオクリップで実行される場合には、最大０．５秒までの時間遅延が発生し得る。このような問題は、放送のようなストリーミングビデオクリップだけではなく事前にダウンロードされ記憶されたビデオクリップを再生する時にも同一の問題点が発生し得る。
【００３３】
図２を参照して、一般モードデータにアクセスする２つの例を考える。具体的には、一般モードデータにおいてランダムアクセスが実行される例及び一般モードデータにおいて倍速再生が実行される例である。
【００３４】
まず、一般モードデータを用いてランダムアクセスモードを実行する場合について、ユーザによるランダムアクセスリクエストがＩフレーム２０１と次のＩフレーム２０３との間のＧＯＰ期間内の特定のフレームで発生する場合に、クライアントは、ランダムアクセスリクエストが発生した時点２００直後のＰフレーム２０５からデコードを開始する代わりに、特定の時間ｄ１だけ移動した後に次のＩフレーム２０３からデコードを開始する。これは、上述したように、最初のデコードがＩフレームから開始するためである。この場合に、ユーザがランダムアクセスをリクエストした時点が実際にデコードを開始する時点とは異なるために、２つの時点間の期間ではいずれのフレームも再生することができず、したがって、ユーザがリクエストしたランダムアクセス動作を正確に実行することができない。
【００３５】
また、一般モードデータを用いて倍速再生を実行する場合について、一般モードデータの倍速再生を行う場合に高速再生のためにＩフレームだけを符号化する。したがって、整数倍（例えば、１倍及び２倍）の倍速再生よりむしろ倍速再生（例えば、１．２倍速又は０．４倍速）機能を効率的にサポートすることが難しい。
【００３６】
したがって、本発明の実施形態は、効率的な倍速再生モードをサポートし、ランダムアクセスリクエストの時に発生する時間遅延を最小化する方法を提供する。
【００３７】
図３は、本発明の実施形態によるメディアコンテンツデータ再生装置の内部構成を示すブロック図である。
【００３８】
図３を参照すると、クライアント３５０は、通信網（図示せず）を通して外部サーバ３００に接続される。クライアント３５０は、ストリーミング方式又はダウンロード方式によりサーバ３００から受信したメディアコンテンツデータを実時間で再生するか、又は受信したメディアコンテンツデータのパーツを格納部３５７に記録し、格納されたメディアコンテンツデータを分析し、分析されたメディアコンテンツデータを再生する装置である。クライアント３５０は、ディジタルテレビジョン（Digital TeleVisions：ＤＴＶｓ）、パーソナルコンピュータ、ディジタル多用途ディスク（Digital Versatile Disc：ＤＶＤ）プレーヤーなどを含む。
【００３９】
本発明の実施形態において、図３に示すクライアント３５０がメディアコンテンツデータを格納する機能を実行することができるが、本発明はこのような構成に限定されず、クライアント３５０は、本発明の実施形態に従って格納機能なしにメディアコンテンツデータを実時間で再生する機能だけを実行してもよい。クライアント３５０をサーバ３００に接続する通信網は、任意の有線又は無線通信ネットワークを含む。
【００４０】
サーバ３００は、放送局、通信オペレータ、映画製作者、又はプライベートコンテンツプロバイダーが運営する。サーバ３００は、オーディオデータ、ビデオデータ、テキストデータ、イメージデータなど及びこれらに対するメタデータのような各種複合メディアコンテンツデータを格納する。
【００４１】
図３を参照すると、クライアント３５０は、メディアコンテンツデータをサーバ３００から受信する。しかしながら、クライアント３５０は、サーバ３００以外のデータベースからメディアコンテンツデータを受信してもよい。
【００４２】
クライアント３５０は、通信部３５１、格納部３５７、分析器３５５、デコーダ３６１、制御器３５３、及び出力部３５９を含む。図３には図示されていないが、クライアント３５０は、ユーザとのインターフェースを担当するユーザインターフェースをさらに含んでもよい。ユーザは、ユーザインターフェースを用いてユーザのリクエストを制御器３５３に送信する。一般的に、ユーザの入力を受信するユーザインターフェースは、キーボード、マウス、タッチスクリーン、ハプティック（haptic）デバイス、及びマイクロフォンのような物理的な変換部を含むことができる。ユーザインターフェースは、ユーザから命令、テキスト、イベント、数字、又は音声情報を受信し、受信したデータを制御器３５３に提供する。
【００４３】
本発明の実施形態によれば、ユーザは、制御器３５３がユーザインターフェースを用いて現在のＧＯＰ期間に対応するメディアコンテンツデータを倍速再生モードで再生するように制御し、現在のＧＯＰ期間のメディアコンテンツデータが倍速再生モードで再生されている間に、次のＧＯＰ期間のメディアコンテンツデータをどのように再生するかを設定することができる。
【００４４】
通信部３５１は、有線又は無線ネットワークを通してサーバ３００又は第３のデータベース（図示せず）に接続され、サーバ３００又は第３のデータベースとデータを交換する。クライアント３５０が無線ネットワーク技術を使用する場合に、通信部３５１は、一般的なデータパケット通信方法を用いてサーバ３００とクライアント３５０間の制御命令及びデータを送受信することができる。通信方法は、無線ローカルエリアネットワーク（Wireless Local Area Network：ＷＬＡＮ）、ブルートゥース（登録商標）、ジグビー（Zigbee：登録商標）、無線ブロードバンド（Wireless Broadband：ＷｉＢｒｏ：登録商標）、無線メディア（Wireless Media：ＷｉＭｅｄｉａ）、第３世代（３Ｇ）符号分割多重接続（ＣＤＭＡ）のような移動通信技術などを含むことができる。
【００４５】
格納部３５７は、通信部３５１がサーバ３００又は第３のデータベースから受信した情報を格納する。分析器３５５は、格納部３５７に格納されたメディアコンテンツデータを分析し、分析されたメディアコンテンツデータをデコーダ３６１に提供する。
【００４６】
デコーダ３６１は、分析器３５５が分析したメディアコンテンツデータを本発明の実施形態によるＭＰＥＧファイル構造に基づく符号化方式の逆の方式を用いてデコードし、デコードされたメディアコンテンツデータを出力部３５９に提供する。この時に、メディアコンテンツデータが異なるタイプのデータを含んでいる場合に、デコーダ３６１は、必要とされるメディアコンテンツデータを選択し、これを出力部３５９に提供する。
【００４７】
例えば、メディアコンテンツデータが一般再生モードのための“一般モードデータ”及び倍速再生モード又はランダムアクセスモードのための“トリックモードデータ”を含み、倍速再生モードが選択される場合に、制御器３５３は、トリックモードデータを選択し、これをデコーダ３６１に提供することができる。
【００４８】
出力部３５９は、デコーダ３６１によりデコードされたメディアコンテンツデータを画面に出力することができる。また、出力部３５９は、クライアント３５０の全般的な状態及びユーザがユーザインターフェースを通して入力した情報を画面又はスピーカに出力することができる。
【００４９】
図３には図示されていないが、クライアント３５０は、別途のシステム時間情報に基づいて動作する。
【００５０】
ユーザは、最初のＧＯＰ期間のメディアコンテンツデータが倍速再生モードで再生される間に、ユーザインターフェースを通して次のＧＯＰ期間のメディアコンテンツデータを再生するための再生モードを設定することができる。場合によっては、クライアント３５０は、ユーザ動作に関係なくクライアント３５０の内部に予め定義された方法を用いて次のＧＯＰ期間のメディアコンテンツデータをデコードしてもよい。
【００５１】
以下に述べられる表１は、本発明の実施形態によるメディアコンテンツディスクリプターの構造を示す。メディアコンテンツディスクリプターは、サーバ又は第３のデータベースから端末又はクライアントに提供される情報であり、端末（又はクライアント）が対応するメディアコンテンツデータと関連した機能を実行するために必要とする様々な情報を含む。
【００５２】
例えば、表１を参照すると、本発明の一実施形態によるメディアコンテンツディスクリプターは、一般再生モードのための情報だけでなく、倍速再生モード及びランダムアクセスモードのための情報も含む。
【００５３】
メディアコンテンツディスクリプターは、メディアコンテンツサービスを最初に開始する時にメディアコンテンツデータに含まれるか又は周期的にメディアコンテンツデータに含まれ、サーバ又は第３のデータベースから端末（又はクライアント）に送信されるとよい。一例において、メディアコンテンツディスクリプターに含まれる情報の一部だけが端末に送信されることもある。この場合に、端末は、この送信された情報に対応する機能だけを実行してもよい。
【００５４】
【表１】
表１を参照してメディアコンテンツディスクリプターについてさらに詳細に説明する。
【００５５】
メディアコンテンツディスクリプターは、マニフェスト（Manifest）情報及びファイル構造（File structure）情報を含む。
【００５６】
メディアコンテンツディスクリプターにより参照されるスキーマ（Schema）情報を示す‘コンテンツ（Contents）’属性として、メディアコンテンツのマニフェスト情報は、‘タイトル（Title）’情報、‘シノプシス（Synopsis）’情報、メディアコンテンツのクリエーター情報を含む‘OriginSite’情報、メディアコンテンツのクリエーターの名称を含んでいる‘OriginSiteName’、メディアコンテンツの識別のための‘ContentID’、メディアコンテンツの制御情報を参照することができる‘ContentsURL’情報及びメディアコンテンツ自体を示す‘ContentItem’情報のうちの少なくとも１つを含む。
【００５７】
メディアコンテンツデータのファイル構造を示すファイル構造情報は、‘ContentType’属性のコンテナー（container）エレメントとして、ストリーミング方式又はダウンロード方式において実際のメディアコンテンツデータの位置決め方法を示す‘URLTemplate’、次のＧＯＰ単位に基づいて制御される‘NextControlURL’、倍速情報及びランダムアクセスの際にサポート可能な時間に関する情報のような付加情報を参照することができる‘RelDataURL’、及び一般モードで使用可能な一般モードデータ及び倍速再生モード又はランダムアクセスモードの時に使用可能なトリックモードデータを識別することができる‘TrackID’のような情報を含むことができる。
【００５８】
クライアント３５０の制御器３５３は、マニフェスト情報に含まれているContentURLのMainContentsDescription.xmlファイルを分析し、所望するメディアコンテンツデータ情報に対するリクエストをＧＯＰ単位でサーバ３００に送信することができる。例えば、最初の状態での一般再生モードでビデオクリップを視聴している間に、ユーザが倍速再生機能又はランダムアクセス機能のリクエストの時に一般再生モードから倍速再生モード又はランダムアクセスモードに切り替える場合がある。この場合に、クライアント３５０は、倍速再生又はランダムアクセスのためのマニフェスト情報に対するリクエストをサーバ３００に送信する。表１でのマニフェスト情報をサーバ３００から受信する時に、クライアント３５０は、MainContentsDescription.xmlファイルに対するリクエストをマニフェスト情報に含まれたContentsURL情報に含まれているアドレスに送信し、このアドレスから倍速再生又はランダムアクセスのためのトリックモードデータを受信することができる。
【００５９】
図４は、本発明の実施形態によるメディアコンテンツデータ再生装置を有するクライアントとサーバ間の動作を示す図である。
【００６０】
図４を参照すると、表１で説明したデータファイル構造に対応するサーバ３００とクライアント３５０間の動作が実行される。その動作によると、クライアントのユーザが特定のメディアコンテンツデータをサーバから受信し、受信したデータを再生する間に倍速再生又はランダムアクセスを希望する場合に、クライアントは、マニフェスト情報に対するリクエストをサーバに送信し、このリクエストに応じてマニフェスト情報をサーバから受信し、この受信された情報を分析し、この分析された情報が、サーバが倍速再生又はランダムアクセス機能をサポートすることを示す場合に、倍速再生又はランダムアクセス機能をリクエストする。図４では、倍速再生がリクエストされると仮定する。
【００６１】
より具体的に、クライアント３５０のユーザが特定のメディアコンテンツデータを受信し再生する間に倍速再生を希望する場合に、クライアント３５０は、ステップ４０１において、サーバ３００がマニフェスト情報を送信することをリクエストする。それに応じて、ステップ４０３において、サーバ３００は、リクエストされたマニフェスト情報をクライアント３５０に送信する。
【００６２】
ステップ４０５において、クライアント３５０は、受信されたマニフェスト情報に含まれているContentURLを有するMainContentsDescription.xmlファイルを分析し、この分析された情報が、サーバが倍速再生機能をサポートすることを示す場合に、倍速再生機能に対するリクエストをContentURLに含まれているサーバ３００のアドレス（例えば、ＵＲＬ）に送信する。それに応じて、ステップ４０７において、サーバ３００は、倍速再生に関連したフラグメントボックスをクライアント３５０に送信する。参考に、‘フラグメントボックス’の用語は、特定の機能の実行に必要とされる情報の集合を意味する。クライアント３５０は、フラグメントボックスに含まれる情報を用いて倍速再生を実行する。
【００６３】
一方、図５乃至図８は、本発明の実施形態による一般モードデータ及びトリックモードデータの構成を説明する図である。
【００６４】
上述したように、一般モードデータは、一般再生モードで使用可能なデータであり、トリックモードデータは、倍速再生モード又はランダムアクセスモードの時に使用可能なデータである。本発明の実施形態によると、トリックモードデータは、通常に、一般モードデータに比べて１／４倍又は１／Ｎ（ここで、Ｎは、数十、すなわち、１０、２０、３０などである）のサイズで設定され、トリックモードデータのＧＯＰ値も一般モードデータのＧＯＰ値より小さく設定されることによりＩフレームの回数（すなわち、Ｉフレームの発生の回数）が増加する。言い換えれば、トリックモードデータは、一般モードデータの量より全体的に少ない量を有し、トリックモードデータのＩフレームは、一般モードデータのＩフレームよりさらに頻繁に現れる。したがって、トリックモードデータの使用は、一般モードデータの使用に比べて送受信及びデコードの速度を増加させる。結果的に、倍速再生及びランダムアクセスの時の遅延時間が減少し、ユーザがメディアデータの正確な再生及び／又は探索を行うことができる。本発明の実施形態に従って、一般モードデータもやはり倍速再生モード又はランダムアクセスモードで再生されることができ、トリックモードデータも一般再生モードで再生されることができる。しかしながら、ここでは、ユーザが一般モードデータを一般再生モードの時に使用し、トリックモードデータを倍速再生モード又はランダムアクセスモードで使用することを選択するものと仮定する。
【００６５】
図５の（ａ）は、ＧＯＰ＝９である一般モードデータを示し、図５の（ｂ）は、ＧＯＰ＝３であるトリックモードデータを示す。図５の（ｂ）のトリックモードデータは、ＧＯＰ値及びデータサイズの観点で図５の（ａ）の一般モードデータより小さい。
【００６６】
図６乃至図８は、本発明の実施形態による一般モードデータ及びトリックモードデータの他の構成を示す図である。
【００６７】
図６の（ａ）乃至図６の（ｃ）の一例を示し、ここで、図６の（ａ）及び図６の（ｂ）のデータは、それぞれ図５の（ａ）及び図５の（ｂ）のデータと同一である。図６の（ｃ）は、Ｉフレームだけを含むように構成されたトリックモードデータを示す。トリックモードデータがＩフレームだけを含む場合に、倍速再生の時の再生速度及びランダムアクセスの時の移動速度はさらに増加することができる。
【００６８】
図７の（ａ）乃至図７の（ｃ）は、他の例を示し、ここで、図７の（ａ）は、複合（または、マルチレイヤー）一般モードデータの一例を示す。例えば、それぞれのフレームが３個のレイヤーデータを含む場合に、３個のレイヤーデータを用いてデータスケーラービリティ（scalability）を実現することができる。図７の（ｂ）及び図７の（ｃ）のデータは、それぞれ図６の（ｂ）及び図６の（ｃ）のデータと同一である。
【００６９】
図８の（ａ）乃至図８の（ｃ）は、トリックモードデータをスケーラブルなデータで実現する他の例を示す図である。すなわち、図８の（ａ）の一般モードデータは、図５の（ａ）の一般モードデータと同一である。しかしながら、図８の（ｂ）及び図８の（ｃ）の複合（又は、マルチレイヤー）トリックモードデータは、それぞれ図６の（ｂ）及び図６の（ｃ）のトリックモードデータの複数の集合を結合することにより構成され、これにより、スケーラービリティをサポートする。
【００７０】
図７及び図８に示すように、本発明のメディアコンテンツデータは、マルチレイヤー一般モードデータ（図７の（ａ））及び／又はマルチレイヤートリックモードデータ（図８の（ｂ）及び図８の（ｃ））を含むことができる。マルチレイヤーデータ構造で構成される場合に、メディアコンテンツデータは、スケーラービリティをサポートすることができる。一方、一般モードデータ及びトリックモードデータは、相互に独立して存在するので、相互に異なる時点で独立して再生されることができる。
【００７１】
上述したように、ユーザは、一般モードデータを一般モードで再生する。また、ユーザは、倍速再生モード又はランダムアクセスモードでトリックモードデータの再生を選択することができる。例えば、一般モードデータが一般モードで再生されている間に、ユーザが倍速再生モードを選択する場合に、クライアントは、トリックモードデータをリクエストし、トリックモードデータを倍速再生モードで再生する。
【００７２】
一般モードデータが一般モードで再生されている間に、ユーザが倍速再生モードでトリックモードデータの再生を選択する場合に、制御器３５３は、一般モードデータ内の時間情報を出力部３５９及びデコーダ３６１に提供するシステム時間クロック情報を分析した後に、この分析された結果に従ってトリックモードデータをリクエストする。したがって、一般モードデータの再生の間に２倍速再生がリクエストされる場合に、クライアントは、トリックモードデータを２倍の速度で再生する。
【００７３】
図９の（ａ）及び図９の（ｂ）は、本発明の実施形態に従ってトリックモードデータを用いてランダムアクセスを実行する動作を説明する図である。図９の（ａ）は一般モードデータを示し、図９の（ｂ）はトリックモードデータを示す。
【００７４】
図９の（ａ）及び図９の（ｂ）を参照すると、一般モードデータ（図９の（ａ）に図示されている）が再生されている間に、時点９０１でユーザによるランダムアクセスリクエストが行われる。従来では、一般モードデータ（図９の（ａ））を用いてランダムアクセスが実行される場合に、時点９０１の次のＰフレーム９０７ではなく次のＩフレーム９０３からデコードを開始するためにｄ１の時間遅延を発生させる。しかしながら、トリックモードデータ（図９の（ｂ）に図示されている）を用いてランダムアクセスが実行される場合に、時点９０１の次のＩフレーム９０５からデコードを開始することができるために時間遅延をｄ２に減少させる。ｄ２は、従来の時間遅延ｄ１より格段に短いことをわかる。
【００７５】
図１０は、本発明の一実施形態によるメディアコンテンツ再生方法を示すフローチャートであり、クライアント３５０が一般モードデータを再生するためにメディアコンテンツディスクリプターに対するリクエストをサーバ３００に送信したことを前提とする。
【００７６】
図１０を参照すると、ステップ７０１において、クライアント３５０は、このリクエストに応じてサーバ３００から受信したメディアコンテンツディスクリプターを分析する。ステップ７０３において、一般モードデータに関する内容がメディアコンテンツディスクリプターに含まれている場合に、クライアント３５０は、サーバ３００からの一般モードデータのリクエスト／受信を行い、この受信した一般モードデータをデコードする。
【００７７】
ステップ７０５において、クライアント３５０は、一般モードデータが再生されている間に倍速再生モード又はランダムアクセスモードへの切り替えリクエストがユーザから受信されたか否かを判定する。倍速再生モード又はランダムアクセスモードへの切り替えリクエストを受信する時に、クライアント３５０は、一般モードデータのデコードを中断し、ステップ７０７に進む。
【００７８】
ステップ７０７において、クライアント３５０は、メディアコンテンツディスクリプターに含まれているトラック情報（すなわち、図４を参照して説明した‘ContentURL’に含まれているサーバのＵＲＬアドレス）に従ってトリックモードデータに対するリクエストをＵＲＬに送信し、リクエストされたトリックモードデータを受信する。ステップ７０９において、クライアント３５０は、受信されたトリックモードデータに対応するメディアコンテンツデータをデコードする。
【００７９】
しかしながら、ステップ７０５において、倍速再生モード又はランダムアクセスモードへの切り替えリクエストがユーザから受信されることができない時に、クライアント３５０は、ステップ７０９に進み、一般再生モードで一般モードデータを継続してデコードし再生する。
【００８０】
図１１の（ａ）及び図１１の（ｂ）は、本発明の他の実施形態によるメディアコンテンツ再生方法を示す図である。
【００８１】
図１１の（ａ）及び図１１の（ｂ）の例において、ユーザは、一般モードデータを倍速再生モード又はランダムアクセスモードで再生しないことを選択した場合を前提とする。トリックモードデータが倍速再生モード又はランダムアクセスモードで再生されている間に、ユーザが倍速再生モード又はランダムアクセスモードから一般モードへの切り替えをリクエストする場合に、クライアントは、本発明の実施形態によるモード切り替えを実行し、一般モードでトリックモードデータを再生する。図１１の（ａ）は一般モードデータを示し、図１１の（ｂ）はトリックモードデータを示す。
【００８２】
この前提に従って、クライアント３５０は、倍速再生モード又はランダムアクセスモードでトリックモードデータ（図１１の（ｂ）に示すように）を用いてメディアコンテンツを再生する。トリックモードデータ（図１１の（ｂ）に示すように）が再生されている間に、ユーザが時点１００１で一般モードへの切り替えをリクエストする場合に、クライアント３５０は、時点１００１でトリックモードデータの再生（すなわち、トリック再生）を中断し、一般モードデータ（図１１の（ａ））を再生する。しかしながら、この場合に、上述したように、一般モードデータの復号化をＩフレームから開始するために、トリック再生の終了時点１００１とトリック再生の終了時点１００１の後の一般モードデータでの１番目のＩフレーム１００３との間で時間差が発生し、これにより遅延時間が生じる。この遅延時間の間にはコンテンツが再生されない。
【００８３】
本発明の他の実施形態によると、遅延時間の間に連続したコンテンツ再生を保証するために、このような遅延時間の間に既存のトリックモードデータを用いて連続した再生を行う。すなわち、トリック再生の終了時点１００１と一般モードデータでの１番目のＩフレーム１００３との間の時間期間の間に、トリックモードデータのフレーム１００５は、Ｉ＝＝＞Ｐ＝＝＞Ｐフレームの順序にデコードされる。その後に、一般モードデータで新たなＧＯＰ期間内の１番目のＩフレーム１００３の受信が完了する場合に、対応する一般モードデータをデコードすることによりコンテンツを再生する。
【００８４】
本発明の他の実施形態によると、図３を参照して説明したメディアコンテンツ再生装置は、次のように動作する。
【００８５】
制御器３５３は、倍速再生モード又はランダムアクセスモードから一般モードへの切り替えリクエストがユーザから受信されたか否かを判定する。一般モードへの切り替えリクエストを受信する際に、制御器３５３は、この切り替えリクエストを分析器３５５に通知する。分析器３５５は、受信されたメディアコンテンツディスクリプターのマニフェスト情報に含まれているサーバ３００のContentURLを分析し、分析された結果に従ってサーバ３００のＵＲＬを制御器３５３に提供する。制御器３５３は、新たなＩフレームからＧＯＰ単位で一般モードデータに対するリクエストをＵＲＬに送信する。
【００８６】
デコーダ３６１は、一般モードデータの新たなＧＯＰ期間内のＩフレーム情報をサーバ３００から受信し、この受信されたフレームデータをデコードするまで既存のトリックモードデータを継続してでコードする。一般モードデータの新たなＧＯＰ期間内の１番目のＩフレームを受信する時に、制御器３５３はトリックモードデータのデコードを中断し、一般モードデータをデコードするようにデコーダ３６１を制御する。デコーダ３６１は、制御器３５３の制御の下に一般モードデータをデコードする。
【００８７】
一方、本発明で説明したマニフェスト情報がメディアコンテンツサービスの提供、サービス設定、及び／又はサービス初期化のための情報を提供するために使用されるので、マニフェスト情報は、例えば、別の名称として‘構成情報’とも呼ばれてよい。しかしながら、マニフェスト情報と同一の意味又は役割を有する情報でありさえすれば、別のどの名称でも使用可能である。また、本発明の実施形態を説明するために必要とされる基本的なフィールド及び／又はこれらの属性情報について説明しているが、本発明の各実施形態で説明される設定ファイルの情報は、使用環境又はサービスに従って追加の情報をフィールド及び属性としてさらに含んでもよい。さらに、設定ファイルに含まれる情報の論理的意味を図示し説明しているが、この情報は、システム及びサービス製造／提供環境に従って拡張マークアップ言語（ｘｍｌ）、２進データ、及びフォーマットされた情報構造のような様々な情報表現構造又はフォーマットの形態で表現されてもよい。
【００８８】
以上、本発明を具体的な実施形態を参照して詳細に説明してきたが、本発明の範囲及び趣旨を逸脱することなく様々な変更が可能であるということは、当業者には明らかであり、本発明の範囲は、上述の実施形態に限定されるべきではなく、特許請求の範囲の記載及びこれと均等なものの範囲内で定められるべきである。
【特許請求の範囲】
【請求項１】
データ通信ネットワークにおけるクライアントのメディアコンテンツ再生方法であって、
メディアコンテンツディスクリプターのリクエストをサーバに送信するステップと、
特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを前記サーバから受信するステップと、
前記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて前記特定のメディアコンテンツデータを受信するステップと
を有することを特徴とする方法。
【請求項２】
前記受信されたメディアコンテンツディスクリプターは、前記特定のメディアコンテンツデータのＧＯＰ又は期間情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記特定の機能の実行のために構成された特定のメディアコンテンツデータは、倍速再生機能又はランダムアクセス機能の実行のために構成されたトリックモードデータを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記トリックモードデータは、一般モード再生の実行のために構成された一般モードデータの品質より低い品質を有するデータを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＵＲＬを用いて前記特定のメディアコンテンツデータを受信するステップは、
前記特定のメディアコンテンツデータのリクエストを前記ＵＲＬのアドレスに送信するステップと、
前記特定のメディアコンテンツデータを前記ＵＲＬのアドレスに対応するサーバから受信するステップと、
前記受信された特定のメディアコンテンツデータを用いて前記特定の機能を実行するステップと
を有することを特徴とする請求項１に記載の方法。
【請求項６】
データ通信ネットワークにおけるサーバによる、クライアントのメディアコンテンツ再生をサポートする方法であって、
メディアコンテンツディスクリプターのリクエストを前記クライアントから受信するステップと、
特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを前記クライアントに送信するステップと
を有することを特徴とする方法。
【請求項７】
前記送信されたメディアコンテンツディスクリプターは、前記特定のメディアコンテンツデータのＧＯＰ又は期間情報を含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記特定の機能の実行のために構成された特定のメディアコンテンツデータは、倍速再生機能又はランダムアクセス機能の実行のために構成されたトリックモードデータを有することを特徴とする請求項６に記載の方法。
【請求項９】
前記トリックモードデータは、一般モード再生の実行のために構成された一般モードデータの品質より低い品質を有するデータを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ＵＲＬのアドレスと関連した前記特定のメディアコンテンツデータのリクエストを前記クライアントから受信するステップと、
前記ＵＲＬのアドレスに従って格納された前記特定のメディアコンテンツデータを前記クライアントに送信するステップとをさらに有することを特徴とする請求項６に記載の方法。
【請求項１１】
データ通信ネットワークにおけるクライアントのメディアコンテンツ再生装置であって、
メディアコンテンツディスクリプターのリクエストをサーバに送信し、特定の機能の実行のために構成された特定のメディアコンテンツデータのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを前記サーバから受信し、前記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて前記特定のメディアコンテンツデータを受信する制御器を有することを特徴とする装置。
【請求項１２】
前記受信されたメディアコンテンツディスクリプターは、前記特定のメディアコンテンツデータのＧＯＰ又は期間情報を含むことを特徴とする請求項１１に記載の装置。
【請求項１３】
前記特定の機能の実行のために構成された特定のメディアコンテンツデータは、倍速再生機能又はランダムアクセス機能の実行のために構成されたトリックモードデータを含むことを特徴とする請求項１１に記載の装置。
【請求項１４】
前記トリックモードデータは、一般モード再生の実行のために構成された一般モードデータの品質より低い品質を有するデータを含むことを特徴とする請求項１３に記載の装置。
【請求項１５】
前記制御器は、前記特定のメディアコンテンツデータのリクエストを前記ＵＲＬのアドレスに送信し、前記特定のメディアコンテンツデータを前記ＵＲＬのアドレスを有するサーバから受信し、前記受信された特定のメディアコンテンツデータを用いて前記特定の機能を実行することを特徴とする請求項１１に記載の装置。
【請求項１】
データ通信ネットワークにおけるクライアントのメディアコンテンツ再生方法であって、
メディアコンテンツディスクリプターのリクエストをサーバに送信するステップと、
特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを前記サーバから受信するステップと、
前記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて前記特定のメディアコンテンツデータを受信するステップと
を有することを特徴とする方法。
【請求項２】
前記受信されたメディアコンテンツディスクリプターは、前記特定のメディアコンテンツデータのＧＯＰ又は期間情報を含むことを特徴とする請求項１に記載の方法。
【請求項３】
前記特定の機能の実行のために構成された特定のメディアコンテンツデータは、倍速再生機能又はランダムアクセス機能の実行のために構成されたトリックモードデータを含むことを特徴とする請求項１に記載の方法。
【請求項４】
前記トリックモードデータは、一般モード再生の実行のために構成された一般モードデータの品質より低い品質を有するデータを含むことを特徴とする請求項３に記載の方法。
【請求項５】
前記ＵＲＬを用いて前記特定のメディアコンテンツデータを受信するステップは、
前記特定のメディアコンテンツデータのリクエストを前記ＵＲＬのアドレスに送信するステップと、
前記特定のメディアコンテンツデータを前記ＵＲＬのアドレスに対応するサーバから受信するステップと、
前記受信された特定のメディアコンテンツデータを用いて前記特定の機能を実行するステップと
を有することを特徴とする請求項１に記載の方法。
【請求項６】
データ通信ネットワークにおけるサーバによる、クライアントのメディアコンテンツ再生をサポートする方法であって、
メディアコンテンツディスクリプターのリクエストを前記クライアントから受信するステップと、
特定の機能の実行のために構成された特定のメディアコンテンツデータへのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを前記クライアントに送信するステップと
を有することを特徴とする方法。
【請求項７】
前記送信されたメディアコンテンツディスクリプターは、前記特定のメディアコンテンツデータのＧＯＰ又は期間情報を含むことを特徴とする請求項６に記載の方法。
【請求項８】
前記特定の機能の実行のために構成された特定のメディアコンテンツデータは、倍速再生機能又はランダムアクセス機能の実行のために構成されたトリックモードデータを有することを特徴とする請求項６に記載の方法。
【請求項９】
前記トリックモードデータは、一般モード再生の実行のために構成された一般モードデータの品質より低い品質を有するデータを含むことを特徴とする請求項８に記載の方法。
【請求項１０】
前記ＵＲＬのアドレスと関連した前記特定のメディアコンテンツデータのリクエストを前記クライアントから受信するステップと、
前記ＵＲＬのアドレスに従って格納された前記特定のメディアコンテンツデータを前記クライアントに送信するステップとをさらに有することを特徴とする請求項６に記載の方法。
【請求項１１】
データ通信ネットワークにおけるクライアントのメディアコンテンツ再生装置であって、
メディアコンテンツディスクリプターのリクエストをサーバに送信し、特定の機能の実行のために構成された特定のメディアコンテンツデータのアクセスのためのユニフォームリソースロケータ（ＵＲＬ）を含むメディアコンテンツディスクリプターを前記サーバから受信し、前記受信されたメディアコンテンツディスクリプターに含まれるＵＲＬを用いて前記特定のメディアコンテンツデータを受信する制御器を有することを特徴とする装置。
【請求項１２】
前記受信されたメディアコンテンツディスクリプターは、前記特定のメディアコンテンツデータのＧＯＰ又は期間情報を含むことを特徴とする請求項１１に記載の装置。
【請求項１３】
前記特定の機能の実行のために構成された特定のメディアコンテンツデータは、倍速再生機能又はランダムアクセス機能の実行のために構成されたトリックモードデータを含むことを特徴とする請求項１１に記載の装置。
【請求項１４】
前記トリックモードデータは、一般モード再生の実行のために構成された一般モードデータの品質より低い品質を有するデータを含むことを特徴とする請求項１３に記載の装置。
【請求項１５】
前記制御器は、前記特定のメディアコンテンツデータのリクエストを前記ＵＲＬのアドレスに送信し、前記特定のメディアコンテンツデータを前記ＵＲＬのアドレスを有するサーバから受信し、前記受信された特定のメディアコンテンツデータを用いて前記特定の機能を実行することを特徴とする請求項１１に記載の装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公表番号】特表２０１３−５２１６９６（Ｐ２０１３−５２１６９６Ａ）
【公表日】平成２５年６月１０日（２０１３．６．１０）
【国際特許分類】
【出願番号】特願２０１２−５５６０２９（Ｐ２０１２−５５６０２９）
【出願日】平成２３年３月８日（２０１１．３．８）
【国際出願番号】ＰＣＴ／ＫＲ２０１１／００１６０４
【国際公開番号】ＷＯ２０１１／１１１９８７
【国際公開日】平成２３年９月１５日（２０１１．９．１５）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
【公表日】平成２５年６月１０日（２０１３．６．１０）
【国際特許分類】
【出願日】平成２３年３月８日（２０１１．３．８）
【国際出願番号】ＰＣＴ／ＫＲ２０１１／００１６０４
【国際公開番号】ＷＯ２０１１／１１１９８７
【国際公開日】平成２３年９月１５日（２０１１．９．１５）
【出願人】（５０３４４７０３６）サムスン エレクトロニクス カンパニー リミテッド (2,221)
【Ｆターム（参考）】
[ Back to top ]