特許 5876480 マルチメディア・ストリーム・ファイルの保存ファイルフォーマット、保存方法及びそれを利用したクライアント装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5876480

(24)【登録日】2016年1月29日

(45)【発行日】2016年3月2日

(54)【発明の名称】マルチメディア・ストリーム・ファイルの保存ファイルフォーマット、保存方法及びそれを利用したクライアント装置

(51)【国際特許分類】

   G11B 20/12 20060101AFI20160218BHJP

   G11B 20/10 20060101ALI20160218BHJP

   H04N 21/433 20110101ALI20160218BHJP

   H04N 21/44 20110101ALI20160218BHJP

   H04N 5/765 20060101ALI20160218BHJP

   H04N 5/91 20060101ALI20160218BHJP

【ＦＩ】

   G11B20/12

   G11B20/10 D

   G11B20/10 311

   H04N21/433

   H04N21/44

   H04N5/91 L

   H04N5/91 Z

【請求項の数】15

【全頁数】16

(21)【出願番号】特願2013-515275(P2013-515275)

(86)(22)【出願日】2011年6月20日

(65)【公表番号】特表2013-536537(P2013-536537A)

(43)【公表日】2013年9月19日

(86)【国際出願番号】KR2011004489

(87)【国際公開番号】WO2011159140

(87)【国際公開日】20111222

【審査請求日】2014年6月18日

(31)【優先権主張番号】10-2010-0092508

(32)【優先日】2010年9月20日

(33)【優先権主張国】KR

(31)【優先権主張番号】61/356,107

(32)【優先日】2010年6月18日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】503447036

【氏名又は名称】サムスン エレクトロニクス カンパニー リミテッド

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】ジョン，ド−ヨン

(72)【発明者】

【氏名】キム，ギル−ユン

(72)【発明者】

【氏名】キム，ヨン−ギュ

(72)【発明者】

【氏名】ジョン，スン−ヨン

【審査官】 堀 洋介

(56)【参考文献】

【文献】 特開２０１１−０８７１０３（ＪＰ，Ａ）

【文献】 国際公開第２０１１／０３８０１３（ＷＯ，Ａ１）

【文献】 国際公開第２０１０／１１７３１６（ＷＯ，Ａ１）

【文献】 特表２００８−５０４７５０（ＪＰ，Ａ）

【文献】 Alex Zambelli，"IIS Smooth Streaming Technical Overview"，[online]，Microsoft Corporation，２００９年 ３月，p.1-17，[平成26年12月12日検索],インターネット<URL:www.microsoft.com/en-us/download/details.aspx?id=17678>

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ１１Ｂ ２０／１２

Ｇ１１Ｂ ２０／１０

Ｈ０４Ｎ ５／７６５

Ｈ０４Ｎ ５／９１

Ｈ０４Ｎ ２１／４３３

Ｈ０４Ｎ ２１／４４

(57)【特許請求の範囲】

【請求項1】

マルチメディア・ストリーム・ファイルの保存方法において、
マルチメディアデータを、互いに異なるビットレートでエンコーディングした複数レベルのトラックを含むマルチメディア・ストリーム・ファイルを提供するサーバから、前記マルチメディア・ストリーム・ファイルの再生のためのメタ情報を受信し、受信されたメタ情報を保存する段階と、
前記マルチメディア・ストリーム・ファイルを構成するフラグメントを受信して保存する段階と、
前記受信されたフラグメントのランダムアクセスのためのランダムアクセス情報を獲得する段階と、
前記獲得されたランダムアクセス情報に基づいて、前記保存されたフラグメントのリプレイのためのフラグメントアクセスメタ情報を生成して保存する段階と、を含むことを特徴とするマルチメディア・ストリーム・ファイルの保存方法。

【請求項2】

前記フラグメントは、１レベルのトラックのマルチメディアデータのうち一部であり、
ネットワーク環境またはクライアントの要請によって、前記複数レベルのトラックのうち、少なくとも１つのフラグメントのトラックのレベルを選択する段階をさらに含むことを特徴とする請求項１に記載のマルチメディア・ストリーム・ファイルの保存方法。

【請求項3】

前記メタ情報は、
前記複数レベルのトラックごとのトラック情報、コーデック情報及びフラグメントの長さ情報を含むことを特徴とする請求項１に記載のマルチメディア・ストリーム・ファイルの保存方法。

【請求項4】

前記フラグメントを受信して保存する段階は、
前記受信されたフラグメントのトラック情報、及び前記フラグメントが受信された順序に割り当てられたシーケンスナンバーを含むフラグメントヘッダ情報を生成する段階と、
前記受信されたフラグメントに含まれたマルチメディアデータと、前記フラグメントヘッダ情報とを結合して再構成されたフラグメントを保存する段階と、を含むことを特徴とする請求項１に記載のマルチメディア・ストリーム・ファイルの保存方法。

【請求項5】

前記ランダムアクセス情報を獲得する段階は、
前記マルチメディア・ストリーム・ファイルを構成するフラグメントのうち、前記受信されたフラグメントを識別するためのセグメント・インデックス情報、受信された全体フラグメント個数情報、及びマルチメディア時間同期情報を獲得することを特徴とする請求項１に記載のマルチメディア・ストリーム・ファイルの保存方法。

【請求項6】

前記保存されたフラグメントのレベルと、利用可能な前記フラグメントのレベルとを比較する段階と、
前記保存されたフラグメントのレベルよりさらに高いレベルのフラグメントが利用可能である場合、前記サーバに、前記さらに高いレベルのフラグメントを要請する段階と、
前記さらに高いレベルのフラグメントを受信して保存する段階と、
前記受信されたさらに高いレベルのフラグメントのランダムアクセス情報を獲得し、前記獲得されたさらに高いレベルのフラグメントのランダムアクセス情報を利用し、前記フラグメントアクセスメタ情報を更新する段階と、をさらに含むことを特徴とする請求項１に記載のマルチメディア・ストリーム・ファイルの保存方法。

【請求項7】

前記保存されたフラグメントのレベルが、所定ビットレート以上のレベル値を有するか否かを判断する段階と、
前記保存されたフラグメントのレベルが、前記所定ビットレート以上のレベル値を有することができない場合、前記サーバに、前記所定ビットレート以上のレベル値を有するフラグメントを要請する段階と、
前記所定ビットレート以上のレベル値を有するフラグメントを受信して保存する段階と、
前記受信された所定ビットレート以上のレベル値を有するフラグメントのランダムアクセス情報を獲得し、前記所定ビットレート以上のレベル値を有するフラグメントのランダムアクセス情報を利用し、前記フラグメントアクセスメタ情報を更新する段階と、をさらに含むことを特徴とする請求項１に記載のマルチメディア・ストリーム・ファイルの保存方法。

【請求項8】

マルチメディア・ストリーム・ファイルを提供されるクライアント装置において、
サーバから提供される互いに異なるビットレートでエンコーディングした複数レベルのトラックを含むマルチメディア・ストリーム・ファイルを要請して受信する通信部と、
前記通信部を介して受信されるマルチメディア・ストリーム・ファイルを構成するフラグメントを保存する保存部と、
前記マルチメディア・ストリーム・ファイルを再生する再生部と、
前記保存部に保存されたフラグメントのランダムアクセスのためのランダムアクセス情報を保存するフラグメントアクセス・データベースと、
前記フラグメントアクセス・データベースに保存されたランダムアクセス情報に基づいて、前記マルチメディア・ストリーム・ファイルを構成するフラグメントの保存いかんを決定し、保存されていないフラグメントが受信されるように、前記通信部を制御するフラグメントアクセス管理部と、
前記マルチメディア・ストリーム・ファイルの再生のためのメタ情報、及び前記保存されたフラグメントのリプレイのためのフラグメントアクセスメタ情報を生成し、前記保存部に保存し、前記保存部に保存されたメタ情報、及びフラグメントアクセスメタ情報を読み取るメタデータ入出力部と、を含むことを特徴とするクライアント装置。

【請求項9】

前記フラグメントは、前記複数レベルのトラックのうち、ネットワーク環境またはクライアントの要請によって選択されたレベルのトラックのマルチメディアデータのうち、一部であることを特徴とする請求項８に記載のクライアント装置。

【請求項10】

前記メタ情報は、
前記複数レベルのトラックごとのトラック情報、コーデック情報及びフラグメントの長さ情報を含むことを特徴とする請求項８に記載のクライアント装置。

【請求項11】

前記メタデータ入出力部は、
前記受信されたフラグメントのトラック情報、及び前記フラグメントが受信された順序に割り当てられたシーケンスナンバーを含むフラグメントヘッダ情報を生成し、
前記保存部は、前記受信されたフラグメントに含まれたマルチメディアデータと、前記フラグメントヘッダ情報とを結合して再構成されたフラグメントを保存することを特徴とする請求項８に記載のクライアント装置。

【請求項12】

前記ランダムアクセス情報は、
前記マルチメディア・ストリーム・ファイルを構成するフラグメントのうち、前記受信されたフラグメントを識別するためのセグメント・インデックス情報、受信された全体フラグメント個数情報、及びマルチメディア時間同期情報を含むことを特徴とする請求項８に記載のクライアント装置。

【請求項13】

前記フラグメントアクセス管理部は、前記保存されたフラグメントのレベルと、利用可能な前記フラグメントのレベルとを比較し、前記保存されたフラグメントのレベルよりさらに高いレベルのフラグメントが利用可能である場合、前記サーバに、前記さらに高いレベルのフラグメントを要請するように、前記通信部を制御することを特徴とする請求項８に記載のクライアント装置。

【請求項14】

前記さらに高いレベルのフラグメントを受信された場合、前記フラグメントアクセス・データベースは、前記受信されたさらに高いレベルのフラグメントのランダムアクセス情報を利用し、前記フラグメントアクセスメタ情報を更新することを特徴とする請求項１３に記載のクライアント装置。

【請求項15】

前記フラグメントアクセス管理部は、前記保存されたフラグメントのレベルが、所定ビットレート以上のレベル値を有するか否かを判断し、前記保存されたフラグメントのレベルが、前記所定ビットレート以上のレベル値を有することができない場合、前記サーバに、前記所定ビットレート以上のレベル値を有するフラグメントを要請するように、前記通信部を制御することを特徴とする請求項８に記載のクライアント装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、マルチメディアデータ・ストリーミングに係り、さらに具体的には、サーバから提供される適応的（adaptive）マルチメディア・ストリームの保存後、リプレイを支援するためのクライアント側での保存ファイルフォーマット、かような保存ファイルフォーマットを使用するクライアント装置、及びクライアント装置でマルチメディア・ストリームを保存する方法に関する。

【背景技術】

【0002】

最近、インターネットや移動通信網を介してマルチメディアデータを伝送するストリーミング・サービス（streaming service）が汎用されている。

【0003】

ストリーミング・サービスは、ユーザの端末機にマルチメディアデータを保存せずに、再生（play）させるマルチメディア・サービスである。固定されたビットレートでデータを提供するストリーミング・サービスが利用されたが、最近では、ネットワーク環境によってビットレートが可変する適応的ストリーミング・サービスが使用されている。適応的ストリーミングのためには、サーバ側で、あらかじめ多様なビットレートのメディアストリームデータを準備しておき、ネットワーク環境またはクライアントの要請によって、ビットレートを変更してデータを伝送する。

【0004】

適応的ストリーミング・サービスは、サーバとクライアントとの間で、チャンク（chunk）とも呼ばれるフラグメント単位のデータを送受信することによって遂行される。すなわち、サーバは、全体マルチメディアデータを数秒単位のフラグメント（fragment）で分けてクライアントに伝送し、クライアントは、かようなフラグメント単位のマルチメディアデータを受信して再生する。

【0005】

適応的ストリーミング・サービスは、データ通信によるレイテンシ、クライアント側でのジッタ補償やマルチメディアデータの同期のためのバッファリング時間などの誤差を除き、ほぼリアルタイムでサーバ側から提供されるマルチメディア・サービスをクライアント側で再生すると仮定する。従って、クライアント側では、適応的ストリーミング・サービスによって提供されるマルチメディアデータを保存した後、リプレイが困難であるという問題点がある。

【発明の概要】

【発明が解決しようとする課題】

【0006】

本発明が解決しようとする技術的課題は、適応的ストリーミングされるマルチメディア・ストリームのリプレイを可能にするための保存ファイルフォーマット、保存ファイルフォーマットを使用するクライアント装置、及びクライアント装置でマルチメディア・ストリームを保存する方法を提供することである。

【0007】

また本発明の課題は、マルチメディア・ストリームデータを保存した後でリプレイするとき、さらに高品質データの再生を可能にするクライアント装置、及びクライアントでマルチメディア・ストリームを保存する方法を提供することである。

【課題を解決するための手段】

【0008】

本発明の一実施形態によるマルチメディア・ストリーム・ファイルの保存方法は、マルチメディアデータを、互いに異なるビットレートでエンコーディングした複数レベルのトラックを含むマルチメディア・ストリーム・ファイルを提供するサーバから、前記マルチメディア・ストリーム・ファイルの再生のためのメタ情報を受信し、受信されたメタ情報を保存する段階と、前記マルチメディア・ストリーム・ファイルを構成するフラグメントを受信して保存する段階と、前記受信されたフラグメントのランダムアクセスのためのランダムアクセス情報を獲得する段階と、前記獲得されたランダムアクセス情報を利用し、前記保存されたフラグメントのリプレイのためのフラグメントアクセス・メタ情報を生成して保存する段階と、を含むことを特徴とする。

【0009】

本発明の一実施形態によるマルチメディア・ストリーム・ファイルを提供されるクライアント装置は、サーバから提供される互いに異なるビットレートでエンコーディングした複数レベルのトラックを含むマルチメディア・ストリーム・ファイルを要請して受信する通信部と、前記通信部を介して受信されるマルチメディア・ストリーム・ファイルを構成するフラグメントを保存する保存部と、前記マルチメディア・ストリーム・ファイルを再生する再生部と、前記保存部に保存されたフラグメントのランダムアクセスのためのランダムアクセス情報を保存するフラグメントアクセス・データベースと、前記フラグメントアクセス・データベースを介して、前記マルチメディア・ストリーム・ファイルを構成するフラグメントの保存いかんを確認し、保存されていないフラグメントが受信されるように、前記通信部を制御するフラグメントアクセス管理部と、前記マルチメディア・ストリーム・ファイルの再生のためのメタ情報、及び前記保存されたフラグメントのリプレイのためのフラグメントアクセス・メタ情報を生成し、前記保存部に保存し、前記保存部に保存されたメタ情報、及びフラグメントアクセス・メタ情報を読み取るメタデータ入出力部と、を含むことを特徴とする。

【0010】

本発明の一実施形態によるマルチメディア・ストリーム・ファイルの保存のための保存ファイルフォーマットは、ファイル類型を保存するファイル類型（ｆｔｙｐ）ボックスと、保存されるマルチメディア・ストリーム・ファイルの再生のためのメタ情報を保存するｍｏｏｖボックスと、受信されたフラグメントのメタ情報を保存するフラグメントヘッダ情報ボックス、及び前記受信されたフラグメントのメディアデータを保存するメディアデータボックスを具備するフラグメントと、前記フラグメントのランダムアクセス及びリプレイのためのフラグメントアクセス・メタ情報であるｍｆｒａボックスと、を含む。

【発明の効果】

【0011】

本発明によれば、適応的ストリーミング・サービスによって提供されるマルチメディアデータを保存してオフライン状態で再生可能にすることができる。

【0012】

また本発明によれば、保存されたマルチメディア・ストリームデータの再生時、さらに高品質のマルチメディアデータ再生を可能にする。

【図面の簡単な説明】

【0013】

【図1】本発明の一実施形態による適応的マルチメディア・ストリーミング・サービスを説明するための参照図である。

【図2】本発明の一実施形態によるマルチメディア・ストリームデータの保存ファイルフォーマットの構造図である。

【図3】図２のｍｏｏｖボックスの具体的な構成を示した参照図である。

【図4】図２の各フラグメント別メタ情報を保存するフラグメントヘッダ情報ボックス（ｍｏｏｆ）の具体的な構成を示した参照図である。

【図5】図２のフラグメントアクセス・メタ情報であるｍｆｒａボックス（ｍｆｒａ：movie fragment random access）の具体的な構成を示した参照図である。

【図6】本発明の一実施形態によるクライアント装置の構成を示したブロック図である。

【図7】本発明の他の実施形態によるクライアント装置の動作を説明するための参照図である。

【図8】本発明の一実施形態によるマルチメディア・ストリーム・ファイルの保存方法を示したフローチャートである。

【図9】本発明の他の実施形態によるマルチメディア・ストリーム・ファイルの保存方法を示したフローチャートである。

【発明を実施するための形態】

【0014】

以下、添付された図面を参照しつつ、本発明の具体的な実施形態について詳細に説明する。

【0015】

図１は、本発明の一実施形態による適応的（adaptive）マルチメディア・ストリーミング・サービスについて説明するための参照図である。

【0016】

図１を参照すれば、適応的マルチメディア・ストリーミング・サービスで、サーバ１１０は、マルチメディアデータを、互いに異なるビットレートを有するようにエンコーディングし、複数レベルのマルチメディア・ストリーム・ファイル１４０をあらかじめ準備し、ネットワーク１２０環境、またはクライアント１３０の要請によって、マルチメディア・ストリーム・ファイル１４０を構成する複数レベルのマルチメディアデータ１４１，１４２，１４３のうち、選択されたレベルのマルチメディアデータを構成するフラグメント（ｆｒａｇ）をクライアント１３０に伝送する。マルチメディア・ストリーム・ファイル１４０を構成する各レベルのマルチメディアデータ１４１，１４２，１４３は、トラック（track）とも定義され、各トラックは、トラック識別子（track＿ＩＤ）で区別されもする。マルチメディア・ストリーム・ファイル１４０を構成する各レベルのマルチメディアデータ１４１，１４２，１４３は、互いに異なる方式でエンコーディングされ、互いに異なるビットレートを有する。各レベルのマルチメディアデータ１４１，１４２，１４３は、ビットレート以外にも、解像度または利用されたコーデック別に区別されてもよい。

【0017】

各レベルのマルチメディアデータ１４１，１４２，１４３は、数秒分量のマルチメディアデータに該当するフラグメントで構成される。互いに異なるレベルのフラグメントは、同一のマルチメディアデータを、互いに異なる方式でエンコーディングしたものであるから、互いに異なる大きさを有することになる。例えば、レベル１のマルチメディアデータ１４３を構成するフラグメントは、１Ｍｂｐｓ、レベル２のマルチメディアデータ１４２を構成するフラグメントは、５Ｍｂｐｓ、レベル３のマルチメディアデータ１４１を構成するフラグメントは、１０Ｍｂｐｓの互いに異なるビットレートを有することができる。前述のように、ネットワーク１２０環境、またはクライアント１３０の要請によって、マルチメディア・ストリーム・ファイル１４０を構成する複数レベルのマルチメディアデータ１４１，１４２，１４３のうち選択されたレベルのマルチメディアデータを構成するフラグメントが、クライアント１３０に伝送される。もしネットワーク１２０の帯域幅、またはクライアント１３０で利用可能なデータ帯域幅が、図面符号１５０に図示されたように変動される場合を仮定すれば、サーバ１１０は、帯域幅の変動に適するように利用可能な複数個のマルチメディアデータ１４１，１４２，１４３のうち、最大ビットレートを有するレベルのマルチメディアデータを構成するフラグメントを、クライアント１３０に伝送する。すなわち、現在帯域幅が良好な場合には、現在帯域幅で利用可能な最大ビットレートを有するフラグメントをストリーミングし、現在帯域幅が劣化された場合には、相対的に小さいビットレートを有するフラグメントをストリーミングすることによって、帯域幅に適応的にフラグメントを伝送する。言い替えれば、フラグメントのレベル及びビットレートは、利用可能な帯域幅の変化によって、伝送過程の間に変更されてもよい。

【0018】

従来、マルチメディア・ストリーミング・サービスで、サーバ１１０は、クライアント１３０の要請によって要請されたフラグメント単位のデータを伝送し、クライアント１３０は、かような全体マルチメディア・ストリーム・ファイルのうち、一部分に該当するフラグメントを受信して再生する方式であるから、クライアント１３０でマルチメディア・ストリーミング・サービスされるマルチメディアデータをリプレイし難いという問題点がある。

【0019】

従って、本発明では、リプレイのためのランダムアクセス情報、及び再生のためのメタ情報をフラグメントデータに付け加え、マルチメディア・ストリームデータを保存する保存ファイルフォーマット、保存ファイルフォーマットを使用するクライアント装置、及びクライアント装置でマルチメディア・ストリームを保存する方法を開示する。

【0020】

図２は、本発明の一実施形態によるマルチメディア・ストリームデータの保存ファイルフォーマットの構造図である。

【0021】

図２を参照すれば、本発明の一実施形態によるマルチメディア・ストリームデータの保存ファイルフォーマットは、ファイル類型を保存するファイル類型ボックス（ｆｔｙｐ：file type）２１０、保存されるマルチメディア・ストリーム・ファイルの再生のためのメタ情報を保存するｍｏｏｖボックス（ｍｏｏｖ：movie meta data）（２２０）、複数個のフラグメント（fragment）２３０，２４０、及び保存されたフラグメントのランダムアクセス及びリプレイのためのフラグメントアクセス・メタ情報であるｍｆｒａボックス（ｍｆｒａ：movie fragment random access）２５０を含む。フラグメント２３０，２４０は、各フラグメント別メタ情報を保存するフラグメントヘッダ情報（ｍｏｏｆ：movie fragment metadata）ボックス２３１，２４１、及びメディアデータボックス（ｍｄａｔ）２３２，２４２を含む。また、図２では、ｍｏｏｖボックス２２０が、ファイル類型ボックス２１０のすぐ後に位置する場合を図示しているが、ここに限定されるものではなく、ｍｏｏｖボックス２２０は、最後のフラグメントと、ｍｆｒａボックス２５０との間に位置することができる。その場合、ｍｏｏｖボックス２２０は、メタ情報以外に、ｍｏｏｖボックスの大きさを記述する情報を含んでもよい。

【0022】

本発明について説明するにおいて、保存ファイルフォーマットは、ＭＰ４ファイルフォーマット標準による場合を中心に説明するが、本発明の詳細な説明を介して、本発明の思想は、かようなＭＰ４ファイルフォーマット標準に限定されるものではなく、他の方式の伝送ファイルフォーマット標準に適用されるということを、本発明が属する技術分野で当業者であるならば、理解することができるであろう。

【0023】

ファイル類型ボックス（ｆｔｙｐ）２１０は、保存されるマルチメディア・ストリーム・ファイルの類型を保存するボックスである。前述のように、ＭＰ４ファイルフォーマット標準による場合ファイル類型ボックス（ｆｔｙｐ）は、「ｍ」「４」「ｄ」「ｓ」の値を有する。

【0024】

図３は、図２のｍｏｏｖボックス２２０の具体的な構成を示した参照図である。図３を参照すれば、ｍｏｏｖボックス（ｍｏｏｖ）３００は、サーバ側に設けた複数レベルのマルチメディアデータの各トラックを識別するためのトラック識別子（track＿ＩＤ）情報、及び各トラックのコーデック情報を含むトラック情報３１０；及びフラグメントの長さ（segment duration）情報３２０；を含む。トラック情報３１０のトラック識別子（track＿ＩＤ）を複数レベルのマルチメディアデータ別に固有に定義することによって、保存されるフラグメントがいかなるレベルのマルチメディアデータのうち一部であるかを確認することができる。このために、後述されるように、トラック識別子（track＿ＩＤ）は、受信される各フラグメントのフラグメントヘッダ情報にも含まれ、各フラグメントが属したマルチメディアデータのレベルを確認させる。フラグメントの長さ情報３２０は、リプレイ時や再生時に、時間同期化を可能にするためのものである。

【0025】

また、図３に図示されていないが、ｍｏｏｖボックス３００は、受信されたフラグメントが、サーバ側から提供されるマルチメディアデータファイルを基に、何番目のフラグメントであるかを示すセグメント・インデックス情報をさらに含んでもよい。かようなセグメント・インデックス情報は、所望するフラグメントの検索のために利用されてもよい。

【0026】

ＲＴＳＰ（real time streaming protocol）基盤の適応的ストリーミングの場合、かようなメタ情報は、ＳＤＰ（session description protocol）フォーマットを介して伝達され、ＨＴＴＰ（hypertext transfer protocol）基盤の適応的ストリーミングの場合ｍメタ情報は、マニフェストファイル（manifest file）のような別途のメタファイル形態でクライアントに伝達される。

【0027】

図４は、図２の各フラグメント別メタ情報を保存するフラグメントヘッダ情報ボックス（ｍｏｏｆ）２３１，２４１の具体的な構成を示した参照図である。

【0028】

図４を参照すれば、フラグメントヘッダ情報ボックス（ｍｏｏｆ）４００は、フラグメントが受信される順に増加する値を有するように割り当てられるシーケンスナンバー（sequence number）４１０、及び受信されたフラグメントが属したマルチメディアデータのレベルを確認させるトラック識別子（track＿ＩＤ）４２０を含む。前述の図３のトラック情報３１０のトラック識別子（track＿ＩＤ）を介して、サーバから利用可能な各トラックの識別子を把握し、受信される各フラグメントごとに付加されたトラック識別子（track＿ＩＤ）４２０を介して、各フラグメントが含まれたマルチメディアデータのレベルを確認することができる。シーケンスナンバー４１０は、受信される順序に各フラグメントに割り当てられ、保存されたフラグメントのランダムアクセス時に、所望するフラグメントを検索させる。かようなシーケンスナンバー４１０は、サーバ側で、現在フラグメントが全体フラグメントのうち何番目に該当するかを示すセグメント・インデックスと区別される。サーバから伝送されるフラグメントは、クライアントの要請による任意時刻のデータであるから、クライアント側で受信される順序と、実際にサーバ側で設けたマルチメディア・ストリームデータの構成順序は、違いが生じうる。例えば、図１のように、３つのレベルでエンコーディングされたマルチメディアデータ１４１，１４２，１４３は、それぞれセグメント・インデックスが同一である３個のフラグメントを有する。すなわち、図１で、レベル１，２，３のｆｒａｇ ｎ（ｎは、１以上の整数）は、全体マルチメディアデータのうちｎ番目のフラグメントであるということを示すものであり、レベル１，２，３のｆｒａｇ ｎは、同一のセグメント・インデックスを有する。かようなセグメント・インデックスは、サーバ側では、全体マルチメディア・ストリームデータを分割し、各フラグメントごとに順次に割り当てられるものの、実際のストリーミング・サービス時には、かようなセグメント・インデックスの順序によってストリーミングされるのではなく、任意のフラグメントを要請してストリーミングされるから、クライアント側で受信されるフラグメントの順序と、サーバ側に設けられたマルチメディア・ストリームデータのセグメント・インデックス順序は、違いが生じうる。従って、クライアント側で受信されるフラグメントの順序を区別するために受信される順序として、シーケンスナンバー４１０が割り当てられ、各フラグメントのランダムアクセスのために、セグメント・インデックスとシーケンスナンバーとを利用して保存されたフラグメントのうち、所望するフラグメントを検索することができる。

【0029】

かようなフラグメントヘッダ情報ボックス（ｍｏｏｆ）４００と、実際のメディアデータであるｍｄａｔとが結合され、かような結合を介して再構成されたフラグメントは、受信されたフラグメントを保存する１つの単位を構成することになる。

【0030】

図５は、図２のフラグメントアクセス・メタ情報であるｍｆｒａボックス（ｍｆｒａ：movie fragment random access）２５０の具体的な構成を示した参照図である。

【0031】

図５を参照すれば、ｍｆｒａボックス（ｍｆｒａ）５００は、全体フラグメント個数情報５１０、フラグメント・ファイル・オフセット（offset）情報５２０、及び時間同期情報５３０を含む。

【0032】

フラグメント・ファイル・オフセット情報５２０は、図２の保存ファイルフォーマットによるとき、保存ファイルの最初からフラグメントの保存位置を示す。かようなファイルオフセット情報５２０を利用し、最初のフラグメントの位置を判断することができる。時間同期情報５３０は、フラグメントに含まれたメディアデータ（ｍｄａｔ）の再生時、同期化（ｓｙｎｃ）のためのものである。

【0033】

また、ｍｆｒａボックス５００は、図示された以外に、受信されたフラグメントを識別するためのセグメント・インデックス情報をさらに含んでもよい。前述のように、セグメント・インデックス情報は、各マルチメディア・ストリーム・ファイルのフラグメントが何番目フラグメントであるかを示すことにより、かようなセグメント・インデックス情報と、ファイルオフセット情報５２０とを利用し、所望するフラグメントの保存位置を決定することができる。セグメント・インデックス情報は、ｍｆｒａボックス５００に保存されず、図２のｍｏｏｖボックス２２０に保存される。

【0034】

ｍｆｒａボックス（ｍｆｒａ）５００は、ＭＰ４ファイルフォーマットのランダムアクセスのためのトラックフラグメント・ランダムアクセスボックス（ｔｆｒａ：track fragment random access）ボックス及びムービーフラグメント・ランダムアクセス・オフセット（ｍｆｒｏ：movie fragment random access offset）ボックスの形態に具現されてもよい。

【0035】

以下、図２ないし図５を介して説明された保存ファイルフォーマットを利用し、サーバからサービスされるマルチメディア・ストリームを保存するクライアント装置について説明する。

【0036】

図６は、本発明の一実施形態によるクライアント装置の構成を示したブロック図である。図６を参照すれば、クライアント装置６００は、再生部６１０、フラグメントアクセス管理部６２０、通信部６３０、フラグメントアクセス・データベース６４０、メタデータ入出力部６５０及び保存部６６０を含む。

【0037】

再生部６１０は、マルチメディア・ストリーム・ファイルを再生するモジュールであり、ユーザ・インターフェースなどを介して、所定フレームのデータが要請された場合、フラグメントアクセス管理部６２０に、当該フレームのデータを構成するフラグメントの提供を要請する。このとき、再生部６１０は、互いに異なるビットレートでエンコーディングした複数レベルのトラックを含むマルチメディア・ストリーム・ファイルのうち、いかなるレベルのマルチメディア・ストリーム・ファイルが必要であるかに係わるレベル情報も、フラグメントアクセス管理部６２０に伝達することができる。

【0038】

フラグメントアクセス管理部６２０は、再生部６１０の要請によって要請されたフレームのデータを含むフラグメントの保存いかんを、フラグメントアクセス・データベース６４０を介して確認する。もし要請されたフラグメントが保存されていない場合、フラグメントアクセス管理部６２０は、通信部６３０がサーバから当該フラグメントを受信するように制御し、すでに保存部６６０に要請されたフラグメントが保存されている場合、当該フラグメントを保存部６６０から読み取る。フラグメントアクセス管理部６２０は、フラグメント・パーザ（parser）の機能も行う。

【0039】

保存部６６０は、図２に図示されたような保存ファイルフォーマットによって、サーバから受信されたフラグメントに、メタ情報に該当するｍｏｏｖボックス、及びフラグメントアクセス・メタ情報に該当するｍｆｒａボックスが結合された形態の保存ファイルを保存する。

【0040】

フラグメントアクセス・データベース６４０は、通信部６３０を介して受信し、保存部６６０に保存されたフラグメントの情報を保存するデータベースである。具体的には、フラグメントアクセス・データベース６４０は、図２で説明されたｍｏｏｖボックス（ｍｏｏｖ）に含まれたメタ情報、及びｍｆｒａボックス（ｍｆｒａ）に含まれたフラグメントランダムアクセスメタ情報を含む。すなわち、フラグメントアクセス・データベース６４０は、保存部６６０に保存された各フラグメントのトラック識別子（track＿ＩＤ）、セグメント・インデックス、シーケンスナンバー、開始時間、ｍｏｏｆボックスのオフセット情報、全体フラグメント個数情報、フラグメントのオフセット、フラグメント内のメディアの開始地点、またはかような開始地点を計算することができる情報を含む。

【0041】

通信部６３０は、フラグメントアクセス管理部６２０の制御によって、サーバにフラグメントを要請して受信する。具体的には、通信部６３０は、フラグメントアクセス管理部６２０で要請されたセグメント・インデックス、及び所望のレベル情報を入力され、当該フラグメントをサーバに要請する。このとき、通信部６３０は、ネットワークの状態、クライアント装置６００内部の残存バッファ量、メモリのような可用リソースなどの情報を利用し、受信に適するレベルのフラグメントを判断し、サーバに要請することができる。例えば、フラグメントアクセス管理部６２０で、５Ｍｂｐｓのビットレートを有するレベル２のマルチメディア・ストリームデータのうち、セグメント・インデックスが３であるフラグメントを要請した場合、通信部６３０は、サーバに、当該セグメント・インデックス及びレベル値を有するフラグメントを要請して受信する。もしネットワーク環境が劣悪であるか、クライアントの残存バッファ量などが不足し、５Ｍｂｐｓのフラグメントを受信して処理することができない場合には、通信部６３０は、要請されたレベルより下位レベルであるレベル１の１Ｍｂｐｓのフラグメントをサーバに要請することもできる。

【0042】

メタデータ入出力部６５０は、マルチメディア・ストリーム・ファイルの再生のためのメタ情報に該当するｍｏｏｖボックス（ｍｏｏｖ）、及び保存されたフラグメントのリプレイのためのフラグメントアクセス・メタ情報であるｍｆｒａボックス（ｍｆｒａ）を生成し、生成されたｍｏｏｖボックス及びｍｆｒａボックスと、受信されたフラグメントとを結合し、図２に図示されたような保存ファイルフォーマットによって保存ファイルを生成し、保存部６６０に保存する。また、メタデータ入出力部６５０は、保存部６６０に保存されたメタ情報を抽出し、フラグメントアクセス・データベース６４０に伝達することによって、保存部６６０に保存されたファイルをロードするとき、フラグメントアクセス・データベース６４０の更新を可能にする。

【0043】

以下、図６に図示されたクライアント装置の動作について具体的に説明する。

【0044】

最初の動作時に、メタデータ入出力部６５０は、保存部６６０に保存されたファイルをロードし、フラグメントアクセス・データベース６４０を初期化する。具体的には、メタデータ入出力部６５０は、保存部６６０に保存された保存ファイルのｍｏｏｖボックス（ｍｏｏｖ）及びｍｆｒａボックス（ｍｆｒａ）をロードし、フラグメントアクセス・データベース６４０に伝達し、フラグメントアクセス・データベース６４０は、伝達されたｍｆｒａボックスをパージングし、現在保存部６６０に保存された全体フラグメントの個数を獲得し、ｍｏｏｖボックスをパージングし、レベル別トラック識別子（track＿ＩＤ）や、各レベルのトラックを再生するために必要なコーデックなどの情報を獲得する。また、ｍｏｏｖボックス（ｍｏｏｖ）及びｍｆｒａボックス（ｍｆｒａ）から得られたフラグメント個数と、レベル別トラック識別子情報とを利用し、現在時点でのシーケンスナンバーを設定する。例えば、現在まで受信されたシーケンスナンバーが１００００であるならば、その後、通信部６３０を介して受信されるフラグメントには、１０００１からシーケンスナンバーが割り当てられるように、現在時点でのシーケンスナンバーを設定する必要がある。かようなシーケンスナンバーの初期設定を介して、追って受信されるフラグメントに重複されていないシーケンスナンバーが割り当てられてもよい。

【0045】

再生部６００で、フレームデータを要請したり、あるいは検索が要請された場合、フラグメントアクセス管理部６２０は、要請されたフラグメントが、保存部６６０に保存されているか否かをフラグメントアクセス・データベース６４０を介して判断する。

【0046】

もし要請されたフラグメントが保存部６６０に保存されていない場合、フラグメントアクセス管理部６２０は、必要なフラグメントのセグメント・インデックスと、所望するレベル情報とを通信部６３０に伝達する。通信部６３０は、ネットワーク環境、クライアント装置６００の残存バッファ量及び可用リソースに基ついて、サーバに適するレベルのフラグメントを要請して受信する。通信部６３０を介して受信が完了したフラグメントについて、メタデータ入出力部６５０は、シーケンスナンバー及びトラック識別子（track＿ＩＤ）を付け加えてフラグメントを再構成し、保存部６６０に保存する。また、メタデータ入出力部６５０は、新たに受信が完了したフラグメントの情報に基づいて、保存部６６０に保存されたｍｏｏｖボックス（ｍｏｏｖ）及びｍｆｒａボックス（ｍｆｒａ）の情報を更新する。もし図２に図示されたように、ｍｏｏｖボックス（ｍｏｏｖ）がファイル類型ボックスの次に位置せずに、ｍｆｒａボックス（ｍｆｒａ）のすぐ前に位置する場合、新たに受信されたフラグメントによって、既存のｍｏｏｖボックスが書き換えられるから、その場合、新たにｍｏｏｖボックスを生成し、生成されたｍｏｏｖボックスを、新たに受信されたフラグメントの後に位置するように保存することができる。

【0047】

また、メタデータ入出力部６５０は、新たに受信が完了したフラグメントの情報を、フラグメントアクセス・データベース６４０に伝達し、フラグメントアクセス・データベース６４０は、伝達した情報に基づいてデータベースを更新する。

【0048】

フラグメントアクセス管理部６２０は、通信部６３０を介して要請されたフラグメントが受信された場合、受信されたフラグメントを再生部６１０に伝達する。

【0049】

もし要請されたフラグメントが保存部６６０に保存されている場合であるならば、フラグメントアクセス管理部６２０は、必要なフラグメントを保存部６６０から読み取り、再生部６１０に伝達する。

【0050】

かような本発明の一実施形態によるクライアント装置６００は、フラグメント単位で伝送されたマルチメディア・ストリームに、メタ情報に該当するｍｏｏｖボックス及びランダムアクセスのためのｍｆｒａボックスを付け加えて保存することによって、リプレイを可能にする。

【0051】

以下、本発明の他の実施形態によるクライアント装置について説明する。

【0052】

本発明の他の実施形態によるクライアント装置は、その動作においてのみ差があり、図６のクライアント装置と同一の構成を有する。

【0053】

図７は、本発明の他の実施形態によるクライアント装置の動作について説明するための参照図である。図７を参照すれば、本発明の他の実施形態によるクライアント装置は、保存部６６０に保存されたフラグメント７１０のそれぞれのレベルと、受信可能なフラグメントのレベルとを比較し、さらに高品質のフラグメントを保存することによって、さらに高品質のマルチメディアデータのリプレイを可能にするためのものである。図７で、レベル１は、１Ｍｂｐｓのビットレート、レベル２は、５Ｍｂｐｓのビットレート、レベル３は、１０Ｍｂｐｓのビットレートを有し、利用可能な最大レベル値が３であるとするとき、本発明の他の実施形態によるクライアント装置は、各フラグメントをできる限り最大レベル値を有するフラグメントに保存されるようにすることを特徴とする。すなわち、図７に図示されたように、レベル１及び２の値を有する既存に保存されたｆｒａｇ１ ７１１、ｆｒａｇ２ ７１２及びｆｒａｇ３ ７１３について、高品質の同一のセグメント・インデックスを有するレベル３のｆｒａｇ１ ７２１、ｆｒａｇ２ ７２２及びｆｒａｇ３ ７２３をさらに受信して保存する。

【0054】

具体的には、再生部６００は、フレームデータを要請するとき、当該フラグメント・セグメント・インデックス情報以外に、所望するレベル値をフラグメントアクセス管理部６２０に伝達する。

【0055】

フラグメントアクセス管理部６２０は、要請されたレベル値を有するセグメント・インデックスのフラグメントが、保存部６６０に保存されているか否かを判断する。具体的には、フラグメントアクセス管理部６２０は、現在保存部６６０に保存された当該セグメント・インデックスを有するフラグメントのうち、最高レベルのフラグメント情報を獲得し、現在保存部６６０に保存された当該セグメント・インデックスを有する最高レベルのフラグメントが要請されたレベル値による品質を満足するフラグメントであるか否かを判断する。もし保存部６６０に保存されたフラグメントが所望する品質のフラグメントである場合、フラグメントアクセス管理部６２０は、当該フラグメントを保存部６６０から読み取り、再生部６１０で伝達する。

【0056】

もし保存部６６０に、当該セグメント・インデックスを有するフラグメントが保存されていないか、あるいは保存されたフラグメントが所望する品質のフラグメントではない場合、フラグメントアクセス管理部６２０は、必要なフラグメントのセグメント・インデックスと、所望するレベル情報とを通信部６３０に伝達する。フラグメントアクセス管理部６２０は、ネットワーク環境、クライアント装置６００の残存バッファ量及び可用リソースに基づいて、現在利用可能な最高品質を有するレベルのフラグメントを要請して受信するように、通信部６３０を制御することができる。また、フラグメントアクセス管理部６２０は、現在利用可能な最高品質を有するレベルのフラグメントが新たに受信された場合、新たに受信されたフラグメントのレベル値と、既存に保存部６６０に保存されたフラグメントのレベルとを比較し、さらに高いレベル、すなわち、さらに高品質を有するフラグメントを再生部６１０に伝達することができる。また、フラグメントアクセス管理部６２０は、サーバから提供可能なフラグメントのレベルと、現在利用可能な最高品質を有するレベルとを比較し、ネットワーク環境やクライアント装置のリソース不足によって、現在利用可能なレベルが低い場合には、追ってネットワーク環境やクライアントのリソース不足が解決されたとき、当該フラグメントを受信するように、通信部６３０を制御することができる。

【0057】

通信部６３０を介して受信が完了したフラグメントについて、メタデータ入出力部６５０は、シーケンスナンバー及びトラック識別子（track＿ＩＤ）を付け加え、フラグメントを再構成し、保存部６６０に保存する。また、メタデータ入出力部６５０は、新たに受信が完了したフラグメントの情報に基づいて、保存部６６０に保存されたｍｏｏｖボックス（ｍｏｏｖ）及びｍｆｒａボックス（ｍｆｒａ）の情報を更新する。

【0058】

また、メタデータ入出力部６５０は、新たに受信が完了したフラグメントの情報をフラグメントアクセス・データベース６４０に伝達し、フラグメントアクセス・データベース６４０は、伝達した情報に基づいて、データベースを更新する。

【0059】

フラグメントアクセス管理部６２０は、通信部６３０を介して、所望する品質のレベル値を有するフラグメントが受信された場合、受信されたフラグメントを再生部６１０に伝達する。

【0060】

一方、かような高品質のフラグメントの受信動作は、バックグラウンド・モジュールを介して独立して遂行されもする。すなわち、クライアント装置６００は、図示されていない別途のバックグラウンド・ダウンロード・モジュールを具備し、バックグラウンド・ダウンロード・モジュールを利用し、現在再生中のフラグメント後のセグメント・インデックスを有するフラグメントのうち、当該セグメント・インデックスを有するフラグメントが、保存部６６０に保存されていないか、あるいは保存されたフラグメントが、所望する品質以上のフラグメントではない場合、当該フラグメントをバックグラウンド動作を介して、サーバから受信して保存する。

【0061】

図８は、本発明の一実施形態によるマルチメディア・ストリーム・ファイルの保存方法を示したフローチャートである。図８を参照すれば、段階８１０で、マルチメディアデータを、互いに異なるビットレートでエンコーディングした複数レベルのトラックを含むマルチメディア・ストリーム・ファイルを提供するサーバから、マルチメディア・ストリーム・ファイルの再生のためのメタ情報を受信し、受信されたメタ情報を保存する。前述のように、メタ情報は、複数レベルのトラックごとのトラック情報、コーデック情報及びフラグメント長さ情報を含む。

【0062】

段階８２０で、マルチメディア・ストリーム・ファイルを構成するフラグメントを受信して保存する。具体的には、受信されたフラグメントのトラック情報、及びフラグメントが受信された順序に割り当てられたシーケンスナンバーを含むフラグメントヘッダ情報を生成し、受信されたフラグメントに含まれたマルチメディアデータと、フラグメントヘッダ情報とを結合して再構成されたフラグメントを保存する。

【0063】

段階８３０で、受信されたフラグメントのランダムアクセスのためのランダムアクセス情報を獲得する。ランダムアクセス情報は、受信されたフラグメントを識別するためのセグメント・インデックス情報、受信された全体フラグメント個数情報及びマルチメディア時間同期情報であることが望ましい。

【0064】

段階８４０で、獲得されたランダムアクセス情報を利用し、保存されたフラグメントをリプレイするためのフラグメントアクセス・メタ情報を生成して保存する。前述のようにフラグメントアクセス・メタ情報は、ＭＰ４ファイルフォーマットによるｍｆｒａボックスを利用して保存されてもよい。

【0065】

図９は、本発明の他の実施形態によるマルチメディア・ストリーム・ファイルの保存方法を示したフローチャートである。図９を参照すれば、段階９１０で、フラグメントのセグメント・インデックスと、所望するレベル値とを利用し、クライアント装置に要するフラグメントの保存いかん確認を要請する。

【0066】

段階９２０で、要請されたセグメント・インデックスを有するフラグメントが存在するか否かを判断し、段階９２０の判断結果、要請されたセグメント・インデックスを有するフラグメントが存在する場合、段階９３０で、当該フラグメントが、所望する品質のフラグメントであるか否かを判断する。もし要請されたセグメント・インデックスを有するフラグメントが、所望する品質も満足する場合には、段階９３５で、保存された当該フラグメントを提供する。

【0067】

もし要請されたセグメント・インデックスを有するフラグメント、または所望する品質のフラグメントが存在しない場合には、段階９４０で、サーバに、要請されたセグメント・インデックスを有する所望するレベルのフラグメントを要請する。

【0068】

段階９５０で、所望するレベルのフラグメントを受信し、段階９６０で、新たに受信されたフラグメントを利用し、フラグメントアクセス・メタ情報及び再生のためのメタ情報を更新する。すなわち、段階９６０で、新たに受信されたフラグメントを利用し、ｍｏｏｖボックス及びｍｆｒａボックスを更新する。

【0069】

本発明はまた、コンピュータで読み取り可能な記録媒体に、コンピュータで読み取り可能なコードとして具現することが可能である。コンピュータで読み取り可能な記録媒体は、コンピュータシステムによって読み取り可能なデータが保存されるすべての種類の記録装置を含む。コンピュータで読み取り可能な記録媒体の例としては、ＲＯＭ（read-only memory）、ＲＡＭ（random-access memory）、ＣＤ（compact disc）−ＲＯＭ、磁気テープ、ハードディスク、フロッピー（登録商標）ディスク、フラッシュメモリ、光データ保存装置などがある。また、コンピュータで読み取り可能な記録媒体は、ネットワークに連結されたコンピュータシステムに分散され、分散方式でコンピュータで読み取り可能なコードとして保存されて実行されてもよい。

【0070】

以上の説明は、本発明の一実施形態に過ぎず、本発明が属する技術分野で当業者であるならば、本発明の本質的特性から外れない範囲で変形された形態で具現することができるであろう。従って、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲に記載された内容と同等な範囲内にある多様な実施形態が含まれるものであると解釈されなければならないのである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】