JP2006323678A

JP2006323678A - コンテンツ再生方法、コンテンツ再生システム、及びコンピュータプログラム

Info

Publication number: JP2006323678A
Application number: JP2005147020A
Authority: JP
Inventors: Tomoyoshi Fukuoka; 朋美福岡; Hajime Oshima; 肇大嶋
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2005-05-19
Filing date: 2005-05-19
Publication date: 2006-11-30
Anticipated expiration: 2025-05-19
Also published as: JP4719506B2

Abstract

【課題】ネットワークを介したマルチメディアコンテンツの再生において、サーバの各種設定やマルチメディアコンテンツファイルの変換等を行わずに、標準的な機能を用いて素早い再生を実現する。
【解決手段】コンテンツのURLを指定してダウンロード再生する際に、ダウンロードの範囲を指定しデータのタイプを判別することにより、ファイルの符号化データか管理情報か否かを判断し、先行して管理情報を取得する。管理情報が取得し終わったら、順次符号化データを取得する。取得サイズと全ファイルサイズの比較を繰り返すことにより、他ファイル情報を完全に取得する。再生に際しては、管理情報を先ず取得し解析し、該当する符号化データを再生可能な単位で入手した時点で再生が開始され、ファイルの構成順序に関わらず素早い再生が可能となる。
【選択図】図２

Description

本発明は、コンテンツ再生方法、コンテンツ再生システム、及びコンピュータプログラムに関し、さらに詳細には、動画像データ、音声データを含むマルチメディアファイル等を、ネットワークを介して再生する際に、バッファリング等の待ち時間を短縮する為に、ファイルの変換やサーバの各種設定、サーバプログラムを生成することをせずに素早い再生を可能にするために用いて好適なものである。

近年、デジタルビデオ、デジタルカメラ、ＰＤＡ、携帯電話等のデジタル機器が急速に普及してきている。また、テレビ放送においてもデジタル化が進むなど、映像や音声、静止画、文字など多様なデータがデジタル形式のデータ（デジタルデータ）として取り扱い可能になってきている。このような背景から、多様なデータを統合的に扱うマルチメディア技術の開発が盛んである。また、マルチメディアの技術の中でも、デジタルデータの情報圧縮技術が重要とされており、その中においても、低速な回線からハイビジョン並の画質をカバーする非常に広いレンジを持った動画や、インタラクティブメディアを再生するための規格であるMPEG-4の標準化作業を、アイエスオー（ISO：International Organization for Standardization）が進めている。なお、MPEG-4情報圧縮技術の詳細に関しては、本発明には直接関係ないため説明を省略する。

MPEG-4規格に準拠した、コンテンツの蓄積用ファイルフォーマット形式としては、ISO/IEC 14496-14により、「ＭＰ４ファイルフォーマット」が規格化されている。ＭＰ４ファイルフォーマットは、メディアに関する情報を記述するメタデータと映像や音響などの符号化されたデータであるメディアデータとから構成される。また、全ての情報は「Ｂｏｘ」（もしくは「アトム」）と呼ばれる構造体に格納される。

図４は、Ｂｏｘのデータ構造を示している。図４に示されている通り、Ｂｏｘ１０１は、sizeフィールド１０２、typeフィールド１０３、及びdataフィールド１０４から構成される。sizeフィールド１０２には、sizeフィールド１０２も含めたＢｏｘ１０１全体のサイズ（バイト数）が格納され、typeフィールド１０３には、Ｂｏｘ１０１の識別子（通常４文字のアルファベット）が格納される。そして、dataフィールド１０４には、実際のヘッダー情報やメディアデータが格納される。

これが基本的なＢｏｘ１０１のデータ構成であるが、この他にversionフィールド（１バイト）やflagsフィールド（３バイト）が、dataフィールド１０４の前に存在することもあり、これらが存在するＢｏｘをFullBoxと呼ぶ。このようなＢｏｘ構造体を用いる、先に述べたＭＰ４ファイルフォーマットを構成するメタデータ部分をMovieBox（以下moovと称する）、メディアデータ部分をMediaDataBox（以下ｍdatと称する）と呼ぶ。

また、このISO/IEC 14496-14において定義されるＭＰ４ファイルフォーマットのＢｏｘには、必須Ｂｏｘだけではなく、必要に応じて用いてもよいオプショナルＢｏｘ、あるいはユーザが自由に定義できるＢｏｘなどが存在する。その中には例えば、FileTypeBox（以下ftypと称する）がある。ftypは、ＭＰ４ファイルの先頭にはなければならない。図５に、ftypを用いたＭＰ４ファイルのＢｏｘの構成の一例を示す。ftyp２０２は、先頭に配置しなければならないが、これ以外のmoov２０３や、mdat２０４のようなＢｏｘに関しては配置順序は自由とされている。

また、更に、moov、mdatの詳細に関して図６を用いて解説する。説明の都合上mdat６２０から説明すると、mdat６２０には、チャンク（chunk）と呼ばれるデータ単位の連続で構成される。図６の例では、mdat６２０は、第１のAudioチャンク（Audioチャンク１）６２１、第１のVideoチャンク（Videoチャンク１）６２２、第２のVideoチャンク（第２のAudioチャンク２）、第２のVideoチャンク（Videoチャンク２）、・・・のように音響チャンクと映像チャンクとが交互に配置された構成を有している。

チャンクの順序や、mdat６２０内のチャンク数は自由とされている。また、１つのチャンクはサンプル（sample）と呼ばれる映像や音響データの１フレームに相当するデータ単位の連続で構成される。図６の第１のVideoチャンク（Videoチャンク１）６２２を例にとって説明すると、第１のVideoサンプル（Videoサンプル１）６２３、第２のVideoサンプル（Videoサンプル２）６２４、第３のVideoサンプル（Videoサンプル３）、・・・のように複数の連続するVideoサンプルから構成されている。

次に、moov６０１の構成を説明する。moov６０１は、更にＢｏｘによる階層構造となっており、必須のＢｏｘは全体としてのヘッダー情報を格納するMovieHeaderBox（mvhd）６０２と、図６に例として挙げたtrak（Audio）６０３と、trak（Video）６０４を有する複数のTrackBoxである。更にこのTrackBoxもＢｏｘの階層構造となっており、trak（Video）６０４を例に挙げて下層の構造を説明する。

図６のtrak（Video）６０４の下層を辿ると、SampleTableBox（stbl）６０５が存在するのが分かる。このＢｏｘ内にはmdat６２０の各チャンク又は各サンプルの少なくとも一方の情報を項目ごとに対応付けて格納している。stbl６０５が有する項目について以下に簡単に説明する。stts６０６はサンプルの継続時間、stsd６０７にはサンプル詳細情報、stsz６０８はサンプルサイズ、stsc６０９はチャンク内に含まれるサンプル数つまりフレーム数、stco６１０はチャンクオフセットであり、それぞれ各サンプルと対応付けて格納されている。

以上のような構成および情報が格納されることから、moov６０１の符号化データの管理情報によりmdat６２０の実際の符号化データを操作しながらＭＰ４ファイルは再生可能となる。このことから、ファイルの再生時にはmdat６２０より前にmoov６０１を読み込んで再生する方が、mdat６２０を先に読み込み、バッファ等に溜め込んでから次にmoovを読み込み、そのmoov６０１をもとに再生するよりも、より早く再生されることが分かる。

そこで、ネットワークを介した動画像コンテンツの再生の場合を考える。サーバ装置からネットワークを介して、ユーザの要求に応じたコンテンツをクライアント端末に配信する方法には、ストリーミング型とダウンロード型とがある。ストリーミング型では、ストリーミングサーバが必要となり、サーバ側にこれらストリーミングを可能とするサーバプログラムの設定が必要となる。また、ダウンロード型では、サーバ装置に特別なサーバソフトウェアは必要なく、非常に標準的なコンピュータ環境で配信が可能である。

また、ダウンロード型のＨＴＴＰプロトコルを用いた場合には、通常のコンテンツファイルの先頭から順次データを転送する為、先に述べたＭＰ４のファイル構成を考えた場合に、mdatのデータがファイルの先頭に配置されている場合には、そのデータを全て取得した上で、moov情報を取得してからでないと再生は可能とならない。

図７を用いて、従来のＭＰ４ファイルのネットワークを介したダウンロード型配信の概念を説明する。図７において、左側をClient３０１、右側をServer３０２とする。ステップ３０３にてClient３０１より、「http://xxx/a.mp4」という再生要求がServer３０２に送信されると、ステップ３０４にてServer３０２から、ステップ３０３で指定されたコンテンツファイルa.mp4の先頭よりファイル内のデータが順次送信される。つまり、mdatの符号化データから送信される。mdatの全てのデータが送信されると、ステップ３０５にてmoovの管理情報が送信される。Client３０１側では、ステップ３０５で送られたmoovデータを解析して初めて、再生が可能となる。それゆえに、ステップ３０４におけるmdatのデータの取得の間、Client３０１はwait状態が続くことになる。

しかし、moovがファイルの先頭にある場合には、moovを取得し終わると、mdatを全て取得し終わるのを待たずに、mdat内の符号化データの再生可能な単位を取得し終えた段階で順次再生が可能となる。つまり、ダウンロード型においてもファイル形式によってはストリーミング型に近い、素早い再生が可能となる。また、先に述べたmdatが先頭にあるファイルと比較すると、mdatのサイズが大きいほど再生開始の時間の差が大きくなると考えられる。

上記ように、ネットワークを介したマルチメディアコンテンツの配信において、ストリーミング型を用いた場合には、ストリーミングサーバの設定が必要となり、ダウンロード型では、予め素早い再生が可能なように、コンテンツのファイル形式をＭＰ４で例えると、moov、mdatの順に配置して作成しておく必要がある。万が一、このようなファイルの形式になっていない場合には、例えば、ＣＧＩのようなサーバプロセスを用意し、moov、mdatの順にファイルを変換するか、あるいは、ファイルの中身を解析し、moovの部分を先行して取得するような処理を行うことが考えられる。しかし、例にあげた両者の場合ともにサーバ側へのサーバプロセスの事前準備という作業が必要となってしまう。

クライアント側、つまりユーザ側からはどんなコンテンツであれ、待ち時間は可能な限り短いことが望ましい。また、サーバ側になんらかの手を加えれば種々の方法を用いた素早いコンテンツ再生が可能な事は周知であるけれども、標準的なプロトコル及びコンピュータ環境を用いて、クライアント主導でどのようなコンテンツのファイル形式であってもより素早く再生させることができなかった。

本発明は、このような問題点に鑑みてなされたものであり、ネットワークを介したマルチメディアコンテンツの再生において、サーバの各種設定やマルチメディアコンテンツファイルの変換等を行わずに、標準的な機能を用いて素早い再生を実現することを目的とする。

本発明は上述の目的を達成するために、符号化データと、前記符号化データを管理する管理情報とを含むコンテンツファイルを配信するサーバ装置と前記サーバ装置から前記ファイルを受信する端末装置とから構成されるシステムにおけるコンテンツ再生方法であって、前記取得した管理情報のデータを解析するステップと、前記判別可能なデータの一部を解析し、符号化データの位置とサイズを取得するステップと、前記取得した符号化データの位置とサイズを指定して符号化データの配信要求を行うステップとを有することを特徴とするコンテンツ再生方法等、を提供する。

本発明によれば、サーバ側に対する各種設定を必要とせずに、標準的なプロトコル及びコンピュータ環境を用いてクライアント主導の動画像再生が可能となり、また、ファイルフォーマット形式に関わらず素早い再生が可能となる。

以下、図面を参照して本発明の実施形態について説明する。
（第１の実施形態）
図１を用いて、最も単純な構成のＭＰ４ファイル、つまりmoovとｍdatとが各１個のＢｏｘのみからなるＭＰ４ファイルのネットワークを介したダウンロード型配信について説明する。

まず、クライアント側においてステップＳ５０１でユーザから入力された再生したいコンテンツのＵＲＬから、配信方法（プロトコル http）と、コンテンツファイルの拡張子（.mp4）とを判別する。前記組み合わせの場合に、次に、クライアントよりステップＳ５０２にて再生をしたいコンテンツファイルのＵＲＬと、ファイルの先頭８バイトの取得要求を行う。この先頭８バイトとは、前述のＢｏｘの説明におけるsizeフィールド（４バイト）とtypeフィールド（４バイト）の両フィールドに相当する。そして、サーバよりステップＳ５０３にてコンテンツファイルの先頭８バイトと、そのコンテンツファイルの全ファイルサイズがクライアントに送られる。

クライアントにおいて、その先頭８バイトを解析し、ステップＳ５０４においてtypeフィールドがmoovかどうか判別する。moovではない場合、つまり、本実施形態ではmdatの場合は、ステップＳ５０５で一度メモリ等にtype、sizeと取得開始位置（先頭）を格納する。その後、ステップＳ５０６において、先頭から既に取得したsize分をプラスした位置から８バイトを取得する。つまり、前述したようにmoovのデータを先行して取得したい為、先頭にmdatがある場合には、その部分を読み飛ばして次のBoxを取得するためである。

ステップＳ５０６で取得した８バイトを解析し、再びステップＳ５０４の処理を行う。２度目に取得したtypeがmoovであった場合には、ステップＳ５０７にて、先頭のＢｏｘか否かの判別を行う。先頭のＢｏｘであった場合には、先頭より８バイトは既に取得している為、ステップＳ５０８において９バイト目からファイルの終端までデータを全て取得する。

もし、ステップＳ５０７の判別において、先頭のＢｏｘでない場合には、ステップＳ５０９にて、前の取得位置より８バイトをプラスした位置から、２度目に取得したsizeから８バイトを引いたサイズを取得する。データ部分を取得した場合には、取得サイズをGetSIZEとし、これにsizeをプラスする。ステップＳ５１０では、前述のGetSIZEと、ステップＳ５０３で取得した全ファイルサイズを比較する。これが一致しない場合には、ステップＳ５１１において、格納された取得位置から８バイトプラスした位置よりsizeから８バイトを引いたサイズ分のデータを取得する。加えてGetSIZEにsizeの加算を行う。ステップＳ５１２では、格納されたtype等の情報でデータを取得し終えた場合に、その情報の削除を行う。

最終的に再びステップＳ５１０にて、GetSIZEと全ファイルサイズとの比較を行い、一致した場合には終了となる。ファイルの取得フローチャートは以上の様になるが、再生開始ポイントは、ステップＳ５０８もしくはステップＳ５１２のmdatデータ取得のタイミングに相当する。

図２に、本実施形態における処理の概念図を示す。図２において、左側がClient４０１、右側がServer４０２とする。まず、Client４０１側においてユーザから入力されたＵＲＬを解析し、配信方法（http）と拡張子（.mp4）を判別し、この組み合わせの場合に、「http://xxx/a.mp4 Range:0-7」というように、レンジを指定してコンテンツファイルa.mp4の先頭８バイトの取得要求（コンテンツのレンジ指定の再生リクエスト）４０３をClient４０１よりServer４０２に送信する。取得要求されたコンテンツファイルa.mp4の先頭８バイト及び全ファイルサイズを含むレスポンス４０４がServer４０２より送信される。Client４０１ではその先頭８バイトに含まれるtypeフィールドの値を判別し、moovの位置を前工程と同様にレンジ指定の取得要求（moovの位置を指定したダウンロードリクエスト）４０５をClient４０１から送信する。Server４０２よりmoovの部分４０６が送信される。次に、Client４０１からmdatの位置をレンジ指定で取得要求（mdatの位置を指定したダウンロードリクエスト）４０７を行い、mdatの部分４０８がServer４０２から送信される。再生はClient４０１がmoovの部分４０６を取得し解析を行った後、mdatの部分４０８の取得において、再生可能な単位をClient４０１で取得した時点で再生が開始される。

以上のように本実施形態では、コンテンツのURLを指定してダウンロード再生する際に、ダウンロードの範囲を指定しデータのタイプを判別することにより、ファイルの符号化データか管理情報か否かを判断し、先行して管理情報を取得する。管理情報が取得し終わったら、順次符号化データを取得する。取得サイズと全ファイルサイズの比較を繰り返すことにより、他ファイル情報を完全に取得する。再生に際しては、管理情報を先ず取得し解析し、該当する符号化データを再生可能な単位で入手した時点で再生が開始され、ファイルの構成順序に関わらず素早い再生が可能となる。

（第２の実施形態）
第１の実施形態においては、最も単純な構成であるmdatと、moovとが各１個のＢｏｘのみからなるＭＰ４ファイルの例を用いて説明したが、前述したようにＭＰ４ファイルには他にftypやユーザ定義のＢｏｘが存在したり、mdatが複数存在したりする場合がある。そのような複雑な場合において図３を用いて説明する。

まず、クライアント側においてステップＳ７０１でユーザから入力された再生したいコンテンツのＵＲＬから、配信方法（プロトコル http）とコンテンツファイルの拡張子（.mp4）を判別する。前記組み合わせの場合に、次に、クライアントよりステップＳ７０２にて再生をしたいコンテンツファイルのＵＲＬと、ファイルの先頭の８バイトの取得要求を行う。この先頭の８バイトとは、前述のＢｏｘの説明におけるsizeフィールド（４バイト）とtypeフィールド（４バイト）の両フィールドに相当する。

サーバよりステップＳ７０３にてコンテンツファイルの先頭の８バイトと、そのコンテンツファイルの全ファイルサイズがクライアントに送られる。この際抽出Sizeとして先行して取得した８バイトのBoxに当たる部分のsizeをプラスしておく。これは、解析したＢｏｘを把握するためであり、後で全ファイルサイズ比較することにより抽出してtypeを解析し忘れているＢｏｘがないかどうかの判断に使用する。

クライアントにおいて、ステップＳ７０３で取得した先頭の８バイトを解析し、ステップＳ７０４において、typeフィールドがmoovかどうかを判別する。moovではない場合、ステップＳ７０５で一度メモリ等にtype、sizeと取得開始位置（先頭）を格納する。その後、ステップＳ７０６において、先頭から既に取得したsize分をプラスした位置から８バイトを取得する。つまり、前述したようにmoovのデータを先行して取得したい為、先頭にmdatがある場合には、その部分を読み飛ばして次のＢｏｘを取得するためである。この際にも抽出Sizeにsizeをプラスする。

ステップＳ７０４で、取得したtypeがmoovであった場合には、ステップＳ７０７にて先頭のＢｏｘか否かの判別を行う。先頭のＢｏｘであった場合には、先頭より８バイトは既に取得している為、ステップＳ７０８において９バイト目からファイルの終端までデータを全て取得する。この場合には処理は以上で終了する。ステップＳ７０６で取得した８バイトを解析した場合には、再びステップＳ７０４の処理を行う。

もし、ステップＳ７０４でmoov且つステップＳ７０７の判別において、先頭のＢｏｘでない場合には、ステップＳ７０９にて、前の取得位置より８バイトをプラスした位置からsizeから８バイトを引いたサイズを取得する。データ部分を取得した場合には、取得サイズをGetSIZEとし、これにsizeをプラスする。この時点でmoovは取得し終えた為に、次にmdatをファイルの先頭に近い部分から取得していく。その為にステップＳ７１０では、メモリ上等に格納されたtypeフィールドがmdatかどうか判別する。ステップＳ７１１で格納された情報のmdat部分に当たるデータ部分をsize、取得情報からサーバより取得する。

ステップＳ７１２では、取得し終えた分のメモリ上の格納情報は削除する。ステップＳ７１０〜Ｓ７１２の操作を行うことにより、既にtype、sizeの８バイトを取得済みの格納情報の中からmdatを検出し、サーバよりデータを全て取得する。その後ステップＳ７１３にて抽出Sizeと全ファイルサイズの比較を行う。一致しない場合には、ステップＳ７１４にて前の抽出位置から８バイトを取得し、ステップＳ７１５によりtypeがmdatかどうかを比較する。mdatではない場合には、ステップＳ７１６にてメモリ上の格納情報に追加する。

ステップＳ７１５にてmdatの場合には、ステップＳ７１７にてそのデータ部分をサーバより取得する。ステップＳ７１３〜Ｓ７１７の処理では、コンテンツファイル内のtypeを未解析のＢｏｘの中からmdatを全て先にサーバより取得する。ステップＳ７１３で抽出サイズと全ファイルサイズとが一致する場合には、ステップＳ７１８でメモリ上等に格納された情報が存在するかチェックし、ステップＳ７１９で存在する場合にはサーバよりそのデータ部分を取得し、ステップＳ７２０で格納情報を削除する。このステップＳ７１８〜Ｓ７２０を繰り返すことにより、先にtypeの解析済みのmoov、mdat以外のデータを取得する。全て取得し終えた時点でGetSIZEと全ファイルサイズが一致することを確認して処理終了となる。

ファイルの取得フローチャートは以上の様になるが、再生開始ポイントは、ステップＳ７０８もしくはステップＳ７１１もしくはステップＳ７１７のmdatのデータの取得のタイミングに相当する。

（第３の実施形態）
第１、第２の実施形態において、クライアント側でユーザから入力されたＵＲＬのコンテンツファイルを判断する際に、ファイルの拡張子（.mp4）を用いてＭＰ４ファイルを判別していたが、他に以下の２点を例としてあげたい。
（１）typeフィールドによる解析
（２）HTTPヘッダーフォールドのメディアタイプによる解析

（１）typeフィールドによる解析とは、前述のISO/IEC 14496-14の「MP4ファイルフォーマット」の規格において、Ｂｏｘ内のtypeフィールドには、ftyp、moov、mdatが存在する。これらのtypeを検出した場合に、ＭＰ４ファイルとして判断する方法がある。

（２）メディアタイプによる解析とは、HTTPプロトコルを用いた場合にヘッダーフィールド定義のおいて、Content-Typeエンティティヘッダーフィールドが存在する。これはGETリクエストがなされた場合に送られるエンティティボディのメディアタイプを示す。MP4ファイルの場合には、「Content-Type：video/mpeg4」のようなメディアタイプが取得できる為、これによって判断する方法がある。

（第４の実施形態）
上述した第１の実施形態、第２の実施形態、及び第３の実施形態で説明した再生方法は、moovがファイル内に先行して保存されていないコンテンツファイルにおいて、常に素早い再生を可能にするとは限らず、動画像コンテンツの撮影時間、コンテンツファイルのサイズ、mdatのサイズもしくは、コンテンツのデータレート等の要素から判断し、従来の方法と本発明の方法を選択する手段を保持することにより、より効果的に素早い再生を実現することが可能となる。
つまり、第１〜第３の実施形態は排他的なものではなく、任意の条件によって従来の方法を含めた各種方法を切り替えて実施することが可能である。

（本発明の他の実施形態）
以上、本発明をその好適な実施形態に基づいて説明してきた。しかし、斯かる実施形態は，本発明の単なる例示に過ぎず、何ら本発明を限定するものではない。例えば、本発明により生成されるファイルは、ＭＰ４ファイルに限定されず、moovのようなメタデータ情報とmdatのようなデータ情報を有する構成の他の任意のファイル再生に対しても適用可能である。また、HTTPプロトコルを用いて説明したが、ファイル内の取得レンジを指定できるような他のプロトコルに対しても適用可能である。

上述した実施形態の機能を実現するべく各種のデバイスを動作させるように、該各種デバイスと接続された装置あるいはシステム内のコンピュータに対し、前記実施形態の機能を実現するためのソフトウェアのプログラムコードを供給し、そのシステムあるいは装置のコンピュータ（ＣＰＵあるいはＭＰＵ）に格納されたプログラムに従って前記各種デバイスを動作させることによって実施したものも、本発明の範疇に含まれる。

また、この場合、前記ソフトウェアのプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコード自体、及びそのプログラムコードをコンピュータに供給するための手段、例えば、かかるプログラムコードを格納した記録媒体は本発明を構成する。かかるプログラムコードを記憶する記録媒体としては、例えばフレキシブルディスク、ハードディスク、光ディスク、光磁気ディスク、ＣＤ−ＲＯＭ、磁気テープ、不揮発性のメモリカード、ＲＯＭ等を用いることができる。

また、コンピュータが供給されたプログラムコードを実行することにより、上述の実施形態の機能が実現されるだけでなく、そのプログラムコードがコンピュータにおいて稼働しているＯＳ（オペレーティングシステム）あるいは他のアプリケーションソフト等と共同して上述の実施形態の機能が実現される場合にもかかるプログラムコードは本発明の実施形態に含まれることは言うまでもない。

さらに、供給されたプログラムコードがコンピュータの機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに格納された後、そのプログラムコードの指示に基づいてその機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって上述した実施形態の機能が実現される場合にも本発明に含まれることは言うまでもない。

本発明の第１の実施形態を示し、ＭＰ４ファイルのネットワークを介したダウンロード型配信のフローチャートである。本発明の第１の実施形態を示し、ＭＰ４ファイルのネットワークを介したダウンロード型配信の概念図である。本発明の第２の実施形態を示し、国際標準規格の範囲の複雑なＭＰ４ファイルのネットワークを介したダウンロード型配信のフローチャートである。従来の技術を示し、ＭＰ４ファイルの基本単位であるＢｏｘの構成を示すブロック図である。従来の技術を示し、ＭＰ４ファイルのＢｏｘの構成を示すブロック図である。従来の技術を示し、ＭＰ４ファイルのmoov、mdatの構成を示すブロック図である。従来の技術を示し、ＭＰ４ファイルのネットワークを介したダウンロード型配信の概念図である。

符号の説明

４０１クライアント
４０２サーバ
４０３再生リクエスト
４０４レスポンス
４０５ダウンロードリクエスト
４０６コンテンツのmoov部分
４０７ダウンロードリクエスト
４０８コンテンツのmdat部分

Claims

符号化データと、前記符号化データを管理する管理情報とを含むコンテンツファイルを配信するサーバ装置と、前記サーバ装置から前記ファイルを受信する端末装置とを備えて構成されるシステムにおけるコンテンツ再生方法であって、
前記ファイルを再生するために、指定されたURLから配信手段とファイル形式を判断するステップと、
前記ファイルの符号化データあるいは管理情報を判別可能なデータの一部のみの配信要求を行うステップと、
前記配信要求の返答と一緒に前記ファイルの全ファイルサイズを取得するステップと、
前記判別可能なデータの一部を解析し、管理情報の位置とサイズを取得するステップと、
前記取得した管理情報の位置とサイズを指定し、管理情報のデータの配信要求を行うステップと、
前記取得した管理情報のデータを解析するステップと、
前記判別可能なデータの一部を解析し、符号化データの位置とサイズを取得するステップと、
前記取得した符号化データの位置とサイズを指定し、符号化データの配信要求を行うステップと、
前記取得した管理情報と前記再生可能な単位を取得した符号化データによって再生を開始するステップと、
前記データの一部の解析により、位置とサイズを指定して取得し終えたデータのサイズの合計を保持し、前記全ファイルサイズと比較するステップとを有し、
前記比較が一致するまで配信要求及び取得処理を繰り返し実行し、前記ファイルの再生を行うことを特徴とするコンテンツ再生方法。
前記判別可能なデータの一部の取得において、先行して取得するデータではない場合に、メモリ上に格納するステップと、
実際に取得した段階でメモリ上から削除する削除ステップとを更に有することを特徴とする請求項１に記載のコンテンツ再生方法。
動画像の符号化データと、前記符号化データを管理する管理情報とを含むコンテンツファイルを配信するサーバ装置と、前記サーバ装置から前記ファイルを受信する端末装置とを備えて構成されるシステムを用いて、コンテンツを再生することをコンピュータに実行させるためのコンピュータプログラムであって、
前記ファイルを再生するために、指定されたURLから配信手段とファイル形式を判断するステップと、
前記ファイルの符号化データあるいは管理情報を判別可能なデータの一部のみの配信要求を行うステップと、
前記配信要求の返答と一緒に前記ファイルの全ファイルサイズを取得するステップと、
前記判別可能なデータの一部を解析し、管理情報の位置とサイズを取得するステップと、
前記取得した管理情報の位置とサイズを指定し、管理情報のデータの配信要求を行うステップと、
前記取得した管理情報のデータを解析するステップと、
前記判別可能なデータの一部を解析し、符号化データの位置とサイズを取得するステップと、
前記取得した符号化データの位置とサイズを指定し、符号化データの配信要求を行うステップと、
前記取得した管理情報と前記再生可能な単位を取得した符号化データによって再生を開始するステップと、
前記データの一部の解析により、位置とサイズを指定して取得し終えたデータのサイズの合計を保持し、前記全ファイルサイズと比較するステップとをコンピュータに実行させ、
前記比較が一致するまで配信要求及び取得処理を繰り返し実行し、前記ファイルの再生を行うことを特徴とするコンピュータプログラム。
符号化データと、前記符号化データを管理する管理情報とを含むコンテンツファイルを配信するサーバ装置と前記サーバ装置から前記ファイルを受信する端末装置とを備えて構成されるコンテンツ再生システムであって、
前記ファイルを再生するために、指定されたURLから配信手段とファイル形式を判断する手段と、
前記ファイルの符号化データあるいは管理情報を判別可能なデータの一部のみの配信要求を行う手段と、
前記配信要求の返答と一緒に前記ファイルの全ファイルサイズを取得する手段と、
前記判別可能なデータの一部を解析し、管理情報の位置とサイズを取得する手段と、
前記取得した管理情報の位置とサイズを指定し、管理情報のデータの配信要求を行う手段と、
前記取得した管理情報のデータを解析する手段と、
前記判別可能なデータの一部を解析し、符号化データの位置とサイズを取得する手段と、
前記取得した符号化データの位置とサイズを指定し、符号化データの配信要求を行う手段と、
前記既に取得し終えた管理情報と前記再生可能な単位を取得した符号化データによって再生を開始する手段と、
前記データの一部の解析により、位置とサイズを指定して取得し終えたデータのサイズの合計を保持し、前記全ファイルサイズと比較する手段とを有し、
前記比較が一致するまで配信要求及び取得処理を繰り返し実行し、前記ファイルの再生を行うことを特徴とするコンテンツ再生システム。
符号化データと、前記符号化データを管理する管理情報とを含むコンテンツファイルを配信するサーバ装置と、前記サーバ装置から前記ファイルを受信する端末装置とを備えて構成されるシステムにおけるコンテンツ再生方法であって、
前記取得した管理情報のデータを解析するステップと、
前記ファイルの符号化データあるいは前記管理情報を判別可能なデータの一部を解析し、符号化データの位置とサイズを取得するステップと、
前記取得した符号化データの位置とサイズを指定して符号化データの配信要求を行うステップとを有することを特徴とするコンテンツ再生方法。