JP4756848B2 - データ配信方法および情報処理装置 - Google Patents

Description

本発明は、マルチメディアファイルの処理に好適なデータ配信方法および装置およびプログラムに関する。特に、ストリーミング配信のための通信制御情報およびコンテンツデータ間の関連定義を記述するオブジェクトディスクリプタ情報を含む、MP4ファイル形式あるいは類似のファイル形式で記述されたマルチメディアファイルのデータ配信処理に好適なものである。

映像、音声の圧縮符号化技術の進歩にともない、さまざまな圧縮符号化形式が標準として規格化され、現在利用されている。また、映像や音声といったコンテンツデータを単独で扱うのではなく、複数種のコンテンツデータが互いに関連付けられて単一のコンテンツとして扱われる、いわゆるマルチメディアコンテンツも一般的に利用されている。このようなマルチメディアコンテンツの圧縮符号化形式の典型として、ISO（Internarional Organization for Standardization）によって制定された動画・音声符号化形式であるMPEG（Moving Picture Expert Group）が挙げられる。

上述のISOでは、MPEGなどの動画・音声のコンテンツデータをファイルに記録するために「ISO Base Mediaファイル形式」という汎用のファイル形式を規格化している（ISO/IEC 14496-12。非特許文献１参照）。さらに、このファイル形式をベースに、特定の符号化形式のデータを記録するために拡張されたファイル形式も標準化されている。MPEG-4の動画・音声符号化データを記録するための標準ファイル形式である「MP4ファイル形式」（ISO/IEC 14496-14。非特許文献２参照）はその代表例である。

デジタルカメラや携帯電話などの機器では、動画・音声データをMPEG-4形式で符号化し、その符号化データはファイルに記録するために多重化され、また、多重化された符号化データを分離されてファイルから抽出され、再生される。このような符号化データの多重化分離のために、上記のMP4ファイル形式を採用するケースが増えてきている。

一方、インターネット環境、通信環境の整備によって、上記のようなファイル形式で記録されたマルチメディアコンテンツを、機器内で再生するだけでなく、ネットワークを介してストリーミング配信するといった利用形態も増加しつつある。そのため、上述のISO Base Mediaファイル形式では、ファイル中の動画・音声データのストリーミング配信を支援するための「ヒントトラック」と呼ばれる追加のデータ構造が定義されている。

＜ヒントトラック＞
ストリーミング配信処理で用いられるデータ単位は、使用される通信プロトコルの「パケット」であり、動画・音声符号化データのデータ単位とは必ずしも一致しない。そのため、配信時には動画・音声符号化データを通信プロトコルのパケットとして伝送可能な単位に分割・結合する必要が生じる。さらに、通信パケットには、通信制御のための付加情報（例えばプロトコル・ヘッダ情報、以下、通信制御情報という）を付加しなければならない場合もある。

ヒントトラックには、これらのコンテンツデータの分割・結合や通信制御情報の付与といった処理を行うための指示が記述される。ストリーミング配信を行うファイルにヒントトラックとして上記のような指示情報を記録しておき、ストリーミングを行う配信装置（以下、ストリーミングサーバ）が配信プロトコルに対応するヒントトラックをファイルから抽出して記述されている指示にしたがってパケット化処理を行うことで、通信プロトコルに準じた形でパケットが生成される。

一般的に、パケット化の方法は、使用する通信プロトコルや配信対象となるコンテンツデータの符号化形式によって異なる。例えば、通信プロトコルにRTP（非特許文献４参照）、符号化形式にMPEG-4を用いる場合、RFC3640（非特許文献５参照）、RFC3016（非特許文献６参照）といったパケット化方法が規格化されている。上述のISO Base Mediaファイル形式規格では、現在、通信プロトコルにRTPを用いる場合に対応したヒントトラックの形式が規格化されている。

なお、このヒントトラックの概念および利用法は、特許文献１および特許文献２においても言及されている。

＜オブジェクトディスクリプタ＞
また、MPEG-4は、映像、音声といった個々のコンテンツデータの符号化に加えて、各コンテンツデータをシーンを構成する物体（オブジェクト）として扱い、オブジェクト単位で符号化する「オブジェクトベース符号化形式」であるという特徴も持っている。そのため、MPEG-4では、映像、音声といった各オブジェクトの属性情報と、各オブジェクトに対応する符号化データとの関連付けを行うために、「オブジェクトディスクリプタ」と呼ばれる両者の関連を記述するための情報が用いられる。このオブジェクトディスクリプタによって、コンテンツデータの属性を正しく扱うことができる。なお、このオブジェクトディスクリプタは、MPEG-4の１パートであり、同期制御等の制御システムに関する標準を規定しているMPEG-4 Systems（非特許文献３参照）によって規格化されている。

MPEG-4では、コンテンツデータは、エレメンタリーストリーム（Elementary Stream、以下、ESと記述）と呼ばれるデータ列として独立して符号化される。ESとして扱われるコンテンツデータは、映像、音声に限らず、上述のオブジェクトディスクリプタなども対象となる。また、このESを一意に識別できるようにするため、各ESにはエレメンタリー・ストリームID（ES_IDと記述）と呼ばれる固有の識別子が割り当てられる。MPEG-4では、ES_IDを用いることによって、特定のESに含まれるコンテンツデータを参照できる。すなわち、このES_IDをオブジェクトディスクリプタに記述することで、オブジェクトディスクリプタとコンテンツデータとの関連付けが実現できる。

オブジェクトディスクリプタには、再生を開始する時の初期データとして用いられるInitialObjectDescriptor（以下、IODと記述）と、再生動作が開始されてから用いられるObjectDescriptor（以下、ODと記述）の２種類のデータ構造が定義されている。通常は、ODはESのデータとして記録され、IODはESとは異なる独立したデータとして扱われる。

IODおよびODは、参照されるESの属性情報を記述するためのES_Descriptor（以下、ESDと記述）というデータ構造を含んでいる。ESDには、ストリームの符号化形式の種類やビットレート、デコーダを初期化するためのDecoderSpecificInfoと呼ばれるデータとともに、ES_IDが含まれる。そのため、IOD、ODのいずれからもESを参照することが可能となっている。

典型的なMPEG-4のコンテンツでは、図１に示すように、ODのESを示すES_IDを含んだIODが最初に処理される。まず、IODに記述されているES_IDからODのデータを参照する。そして、同様にODに記述されているES_IDからコンテンツデータを参照するといった手順で処理が行われる。

＜BIFS＞
さらに、MPEG-4では、オブジェクトを合成して一つのシーンを構成するためにシーン記述と呼ばれる考え方が導入されている。シーン記述は、映像、音声などのオブジェクトのコンテンツデータとは別に、オブジェクトのシーン上の位置を示す空間的属性、オブジェクトの出現や消滅のタイミングを示す時間的属性が記述された情報であり、オブジェクトからシーンを合成するのに利用される。MPEG-4では、シーン記述情報はBIFS（Binary Format for Scene）と呼ばれる符号化データとして記述される。一般的なMP4ファイル形式のコンテンツは、上述のIOD、OD、BIFSデータを含んでいる。

＜ISMA＞
上記のヒントトラックやOD、BIFSといったデータは、MPEG-4コンテンツをストリーミング配信するための通信手段を規定するための仕様として、米Apple Computer社、米Philips社などの企業が参加している業界団体であるISMA（Internet Streaming Media Alliance）によって規定されている標準仕様“Internet Streaming Media Alliance Implementation Specification”（非特許文献７参照。以降、ISMA仕様と表記する）でも規定されている。

このISMA仕様において、ヒントトラックやOD、BIFSがどのように用いられるかの概略を図２を用いて説明する。

ISMA仕様では、多くの映像配信方式と同様に、セッション制御プロトコルとしてRTSP（非特許文献８参照）およびSDP（非特許文献９参照）が用いられており、また、映像・音声符号化データのストリーミング・プロトコルとして前述のRTPが用いられている。

ストリーミングサーバは、まず、SDP形式で記述されたセッション記述情報をRTSPなどのプロトコルで受信端末に送付する（２１）。このとき、IOD、OD、BIFSの情報は、Base64形式でエンコードされたテキストデータとしてセッション記述情報の一部として送付される。すなわち、このセッション記述情報を配信対象のファイル中にSDP形式で記述しておけば、配信時にストリーミングサーバによって当該ファイルから取得され、送信されることになる。

セッションが確立されたら、引き続き、あらかじめファイルに記録されているヒントトラックから、SDP形式で記述された映像・音声データストリームの情報をRTSPで送信し、ストリーミングを行うためのRTPセッションを確立する（２２）。そして、ヒントトラックの内容に基づいて映像・音声データを分割、パケット化し、上記確立されたRTPセッション上で受信端末にストリーミングする（２３）といった手順で配信処理が行われる。

以上述べたように、MPEG-4コンテンツを含むファイルに、ヒントトラック、およびIOD、OD、BIFSを含むセッション記述情報をあらかじめ記録しておくことによって、それらの情報はストリーミングサーバによって配信処理に使用される。
米国特許第６７１７９５２ 特表２００４−５０５５１９ ISO/IEC 14496-12; "Information technology -- Coding of audio-visual objects -- Part 12: ISO base media file format"; ISO/IEC; 2004-01-23 ISO/IEC 14496-14; "Information technology -- Coding of audio-visual objects -- Part 14: MP4 file format"; ISO/IEC; 2003-11-24 ISO/IEC 14496-1; "Information technology -- Coding of audio-visual objects -- Part 1: Systems"; ISO/IEC; 2003-02-20 RFC1889; "RTP: A Transport Protocol for Real-Time Applications"; H.Schulzrinne, S.Casner, R.Frederick, V.Jacobson; January 1996; IETF RFC3640; "RTP Payload Format for Transport of MPEG-4 Elementary Streams"; J.van der Meer, D.Mackie, V.Swaminathan, D.Singer, P.Gentric; November 2003; IETF RFC3016; "RTP Payload Format for MPEG-4 Audio/Visual Stream"; Y.Kikuchi, T.Nomura, S.Fukunaga, Y.Matsui, H.Kimata; November 2000; IETF "Internet Streaming Media Alliance Implementation Specification Version 1.0"; Internet Streaming Media Alliance; 2001-08-28 RFC2326; "Real Time Streaming Protocol (RTSP)"; H.schlzrinne, A.Rao, R.Lanphier; April.1998; IETF RFC2327; "SDP: Session Description Protocol"; M.Handley, V.Jacobson; April.1998; IETF 3GPP TS 26.244 "Technical Specification Group Services and System Aspects Transparent end-to-end packet switched streaming service (PSS); 3GPP file format (3GP) (Release 6)" 3rd Generation Partnership Project; 2003-02-28

上述のストリーミングサーバの処理は、ヒントトラックやIOD、OD、BIFSを含むセッション記述情報といったストリーミング情報がファイルに含まれていることが前提となっていた。言い換えれば、ストリーミングを行うためには、配信対象のファイルにあらかじめこれらの情報を記録しておかなければならなかった。

しかし、これらのストリーミング情報は必ずしもファイルに記述されているとは限らない。実際、デジタルカメラやカメラ付き携帯電話などの撮像機器で作成されるファイルには、データの冗長性を抑えるためにこれらのストリーミング情報は付加されないケースがほとんどである。

そのため、コンテンツの作成者は、ストリーミング配信を行う前準備として、撮像機器や記録機器で作成されたファイルに対してストリーミング情報を付加してからストリーミングサーバにアップロードするという作業を行う必要があった。

このため、コンテンツ作成者は、ストリーミングを行うか行わないかによって２種類のファイルを扱わなければならなくなり、ファイルの管理が複雑になるといった課題が生じる。更に、ストリーミング情報をファイルに付与するための追加作業が発生するためコンテンツ作成者の作業負荷が高まるといった課題、ストリーミング情報の付加によりデータ量が増加するため、ストリーミングサーバへのアップロードによけいに時間がかかるといった課題が発生し、コンテンツ配信のための作業が煩雑で非効率的なものになってしまっていた。

上記の課題を解決するための一案として、撮像機器・記録機器のファイル作成処理において、ストリーミングを行うか否かに関わらずヒントトラックなどのストリーミング情報を付与するという方法が考えられる。

しかしこの方法によれば、ストリーミング配信を行わない場合は、付与したストリーミング情報は使用されない冗長なデータとしてファイルに残されてしまうため、データ効率が悪くなってしまう。また、撮像機器・記録機器が本来行うべき動画記録処理を遂行するための処理能力やメモリなどの資源をストリーミング情報の記録に割り当てなければならなくなるため、機器の性能が劣化してしまうといった別の課題が発生してしまう。更に、この方法を用いても、上述したストリーミングサーバへのアップロードに時間がかかるといった課題は依然として解決することはできない。

また、前述のIOD、OD、BIFSといった情報は、MPEG-4を扱えるすべてのファイル形式においてファイル中に保持されるとは限らない。例えば、第三世代携帯電話向けに3GPP（3rd Generation Partnership Project）によって定義された3GPPファイル形式（非特許文献１０参照）や、KDDI株式会社の携帯電話の動画記録形式として用いられていたAMCファイル形式では、これらの情報はファイル中には記録されない。したがって、上記のような形式のファイルは、ISMA仕様により規定されている形式でIOD、OD、BIFSデータを送付することが出来ないため、仕様に準拠することは出来なかった。

本発明は上記の課題に鑑みてなされたものであり、ファイルに配信のための制御情報が含まれているか否かに関わらず、ストリーミング配信を行うことを可能にするデータ配信方法および情報処理装置を提供せんとするものである。

上記の目的を達成するための本発明によるデータ配信方法は、
コンテンツデータの配信方法であって、
配信対象のコンテンツデータの構造を解析する解析工程と、
前記解析工程の解析結果より前記コンテンツデータに配信制御のための記述が含まれていないと判断された場合に、該解析工程の解析結果であるコンテンツデータの構造に基づいてストリーミング情報を生成する生成工程と、
前記生成工程で生成されたストリーミング情報に基づいて前記コンテンツデータをネットワークに配信する配信工程とを有し、
前記生成工程では、前記解析結果に基づいて、前記コンテンツデータが有するオブジェクトに関する記述を前記配信工程における配信プロトコルに適応した記述に変換する。

また、上記の目的を達成するための本発明による情報処理装置は、
コンテンツデータをメモリに格納する格納手段と、
前記メモリに格納されたコンテンツデータのうち、配信対象のコンテンツデータの構造を解析する解析手段と、
前記解析手段の解析結果により前記コンテンツデータに配信制御のための記述が含まれていないと判断された場合に、該解析手段の解析結果であるコンテンツデータの構造に基づいてストリーミング情報を生成する生成手段と、
前記生成手段で生成されたストリーミング情報に基づいて前記コンテンツデータをネットワークに配信する配信手段とを備え、
前記生成手段は、前記解析結果に基づいて、前記コンテンツデータが有するオブジェクトに関する記述を前記配信手段における配信プロトコルに適応した記述に変換する。

本発明によれば、ファイルに配信のための制御情報が含まれているか否かに関わらずストリーミング配信を行うことが可能になる。

以下、本発明の実施形態を添付の図面を参照しながら詳細に説明する。

なお、以下の実施形態ではコンテンツデータがMP4ファイル形式である場合を中心に説明されるが、MP4に限らず類似のファイル形式およびアーキテクチャを用いるケースに対しても適用できる。例えば、ISOではMP4と同様のアーキテクチャを用いる規格として、「Motion JPEG 2000ファイル形式」（ISO/IEC 15444-3）や、「AVCファイル形式」（ISO/IEC 14496-15）といった標準規格が制定されている。これらの標準規格や、上述の3GPPファイル形式など、MP4で規定されるものと類似のファイル形式およびアーキテクチャが採用されている規格に対しても、本発明を適用することが可能である。加えて、本実施形態に適用するファイル形式規格で用いるように規定されているものであれば、いかなるビデオ符号化形式およびオーディオ符号化形式が用いられてもよい。例えば、ファイル形式として3GPPファイル形式を適用する場合、ビデオ符号化形式としてH.263、オーディオ符号化形式としてAMR（Adaptive Multi-Rate）といった符号化形式が用いられてもよい。

また、本明細書で述べている「コンテンツデータがMP4ファイル形式で記述されている」という状態は、取り扱うデータの実体が物理的なファイルであることを示すものではない。ネットワークを介して伝送されたデータや、メモリ上に記憶されているデータに対しても本発明を適用することができる。

＜第１実施形態＞
図３は、第１実施形態におけるマルチメディアコンテンツの配信処理を実現するネットワークカメラの構成を示すブロック図である。第１実施形態のネットワークカメラは、撮影した映像をMP4ファイルとして保存する機能と、保存されたMP4ファイルをネットワークを介してストリーミング配信する機能とを備える。

図３のネットワークカメラにおいて、撮影時の映像情報はカメラ１００から入力され、映像Ｉ／Ｆ１０２を介してビデオキャプチャコントローラ１０４に渡される。同様に、撮影時の音声情報はマイク１０１から入力され、音声Ｉ／Ｆ１０３を介してオーディオキャプチャコントローラ１０５に渡される。ビデオキャプチャコントローラ１０４は、入力された映像情報をデジタル映像信号に変換し、ビデオエンコーダ１０６の入力として渡す。同様に、オーディオキャプチャコントローラ１０５は、入力された音声信号をデジタル音声信号に変換し、オーディオエンコーダ１０７に渡す。

ビデオエンコーダ１０６は、入力された映像信号に対して圧縮符号化を行い、MPEG-4ビデオ符号化データを生成する。また、オーディオエンコーダ１０７も同様に、入力された音声信号を圧縮符号化し、MPEG-4オーディオ符号化データを生成する。ビデオエンコーダ１０６およびオーディオエンコーダ１０７が生成した符号化データは、ファイル多重化コントローラ１０８によってMP4ファイル形式に多重化され、ファイルとして出力される。このとき、ファイル多重化コントローラ１０８は、外部記憶Ｉ／Ｆ１１１を介して、出力するMP4ファイルのデータを外部記憶１１２に書き出す。本実施形態では、外部記憶１１２はSDカード等の不揮発性メモリーカードを想定しているが、CD（Compact Disc）やDVD（Digital Versatile Disc）等の記録媒体を用いるようにしてもよいし、ハードディスク等の記憶装置であってもよい。

さらに、図３のネットワークカメラでは、ストリーミング配信機能を実現するために、ストリーミングコントローラ１１３およびネットワークＩ／Ｆ１１４を備える。ストリーミングコントローラ１１３は、上述のRTP、RTSPを用いてMP4ファイルの内容をストリーミング配信する機能を提供する。ストリーミングコントローラ１１３は、配信先端末からMP4ファイルの配信要求をネットワークＩ／Ｆ１１４を介して受け取ると、要求されたMP4ファイルを外部記憶Ｉ／Ｆ１１１を介して外部記憶１１２から取得する。そして、多重化分離して得られた符号化データからRTPパケットを生成し、ネットワークＩ／Ｆ１１４を介して上記配信先端末に対してRTPでストリーミング配信を行う。

なお、図３のネットワークカメラの各構成部は、内部バス１１８によって相互に通信可能なように接続されており、各構成部の処理はシステムコントローラ１１５によって制御される。また、カメラシステムの固定的な情報はシステムＲＯＭ１１６に、システムの状態など変動する情報はシステムＲＡＭ１１７に保持される。ただし、ビデオデータやオーディオデータのような大容量データは、ビデオフレームメモリ１０９、オーディオフレームメモリ１１０といった専用のメモリに保持される。各構成部間のデータのやりとりは、上記のシステムＲＡＭ１１７、あるいはビデオフレームメモリ１０９、オーディオフレームメモリ１１０を介することによって行われる。

図４は、第１実施形態のネットワークカメラにおいて、ストリーミングコントローラ１１３で実行される処理の概略手順を説明するフローチャートである。

図４のフローチャートにおいて、まず、ステップＳ２０１において、ストリーミングコントローラ１１３は配信対象のMP4ファイルの内容を取得する。本実施形態では、ストリーミングコントローラ１１３は、配信先端末から送付されたファイル配信要求に関する情報をネットワークＩ／Ｆ１１４を介して取得し、要求されたファイルの内容を外部記憶Ｉ／Ｆ１１１を介して外部記憶１１２から取得する。配信先端末からのファイル配信要求は、上述のRTSPを用いて送信されるものと想定する。

次に、ステップＳ２０２において、ストリーミングコントローラ１１３は、配信対象のMP4ファイルの内部構造を解析し、多重化分離して得られる符号化データの配信などの後続の処理で必要となる情報を抽出する。抽出された情報はシステムＲＡＭ１１７上に保持され、ストリーミングコントローラ１１３によって管理される。

次に、ステップＳ２０３において、上述のステップＳ２０２で抽出された情報に基づいてストリーミング情報を生成する。ストリーミング情報には、典型的には、配信先端末と通信セッションを確立するために必要なセッション記述情報、タイムスタンプなどパケットヘッダーの生成に必要な情報、パケットのペイロードとなる符号化データを配信対象のMP4ファイルから抽出するための情報、符号化データを配信プロトコルや配信条件に適したパケットサイズに分割するための分割情報、あるいはペイロードとなる符号化データ自体が含まれる。本実施形態の場合、これらのストリーミング情報は、MP4ファイルに記録されるSDP情報およびRTPヒントトラック情報であると換言することも出来る。

そして、ステップＳ２０４において、ストリーミングコントローラ１１３は上述の処理で生成されたストリーミング情報に含まれるセッション記述情報をRTSPで配信することによって通信セッションを確立する、その後、上記のストリーミング情報を元にRTPパケッタイズ処理を行い、配信ファイルの符号化データを含むRTPパケットを生成する。このようにして生成されたRTPパケットは、ネットワークＩ／Ｆ１１４を介してネットワーク上に送出され、配信先端末にRTPでストリーミング配信される。すなわち、ステップＳ２０４では、SDP形式のセッション記述情報がRTSPプロトコルで、符号化Ａ／ＶデータがRTPプロトコルのパケットとして送信されることになる。なお、第２実施形態で説明するように、ISMA仕様に則って配信する場合は、セッション記述情報はISMA仕様で定められる内容を含んだ形で送信されることになる。

次に、第１実施形態において、図４のステップＳ２０３で行われるストリーミング情報の生成処理を図５のフローチャートを参照して詳細に説明する。図５は、第１実施形態におけるストリーミング情報の生成処理手順を説明するためのフローチャートである。

まず、ステップＳ３０１において、ストリーミングコントローラ１１３は、配信対象のMP4ファイルの内容の解析結果を参照する。この解析結果は、上述のステップＳ２０２の解析処理によってあらかじめ参照可能な状態でシステム内（システムＲＡＭ１１７）に保持されているものとする。

次に、ステップＳ３０２において、配信対象のMP4ファイルの配信処理を行うためにストリーミング情報を生成する必要があるか否かをチェックする。本実施形態では、RTPヒントトラックの情報やSDP情報といった、配信を行うプロトコルで用いられるストリーミング情報がMP4ファイル内に記述されていない場合に、ストリーミング情報の生成が必要であると判断する。したがって、ステップＳ３０２では、配信対象のMP4ファイルがこの条件と一致するか確認し、ストリーミング情報の生成が必要な場合にはステップＳ３０３以降のストリーミング情報生成処理を実行する。ストリーミング情報が存在する場合は、ステップＳ３０３からステップＳ３０５までの処理はスキップし、ステップＳ３０６で、MP4ファイル中に含まれるストリーミング情報を、そのまま後続のステップＳ２０４に受け渡して配信処理を行う。なお、この場合の処理は一般的なストリーミングサーバと同様の処理である。

ストリーミング情報の生成が必要である場合は、まず、ステップＳ３０３において、ストリーミング情報を構成するデータ項目に関連するMP4ファイル中のデータ構造を参照する（ストリーミング情報を構成するデータ項目の具体例については、図６および図７で示されるデータ項目を例に後述する）。言うまでもなく、この処理を行うためには、ステップＳ２０２で配信対象のMP4ファイルの内部構造があらかじめ解析され、その結果がストリーミングコントローラ１１３が参照可能な状態でシステム内（システムＲＡＭ１１７）に保持されていることが必要である。

次に、ステップＳ３０４において、ステップＳ３０３で参照されたMP4ファイルのデータ構造の内容にしたがって、ストリーミング情報を設定する（設定の具体例については後述する）。設定された内容は、全てのストリーミング情報のデータ項目の設定が終了するまで、後続のステップＳ３０６には受け渡されずに保持される。

以上のステップＳ３０３及びステップＳ３０４の処理が、生成されるストリーミング情報を構成する全てのデータ項目に対して実行される。すなわち、ステップＳ３０５において、ステップＳ３０３、Ｓ３０４の処理が全てのデータ項目に対して実行されたか否かを判定し、全項目が処理されるまでステップＳ３０３とステップＳ３０４の処理を繰り返す。

ストリーミング情報の全てのデータ項目の設定が終了すると、ステップＳ３０５からステップＳ３０６に進み、上記ステップＳ３０３〜Ｓ３０５の実行によって得られたストリーミング情報の内容を、後続のステップＳ２０４に受け渡す。

上記の手順によって、本実施形態のネットワークカメラにおいて配信に用いられるストリーミング情報が得られるようになる。

次に、より詳細な実施形態について具体例を挙げて説明する。具体例として、処理対象のコンテンツ・データに含まれているMPEG-4 Videoの動画データをRTSPおよびRTPを用いてストリーミング配信する場合について、ステップＳ３０３、Ｓ３０４で行われる処理の詳細を説明する。この例において、ステップＳ３０３、Ｓ３０４では、RTSPでの通信時にはSDP形式で記述される映像・音声データストリーム情報が、RTPでの通信時にはRFC3016によって規定されるペイロード形式のRTPパケットがストリーミング情報として生成される。以降の説明では、これらの２種類の情報がどのようにして生成されるかを、順を追って説明する。

［映像・音声データストリーム情報の生成］
まず、RTSPで送信されるSDP形式の映像・音声データストリーム情報の生成手順を示す。

図６は、SDP形式で記述された映像・音声データストリーム情報の典型例を示す図である。図６に示されるセッション記述の内容は、RFC3016で示される仕様にしたがって記述されたものである。この情報は、配信される映像・音声データに対するヒントトラックに含まれるデータとして、通常はMP4ファイルのヒントトラック中に記述されている。なお、図６に示される情報構成は一例であり、実際の配信処理で用いられるデータおよび形式、順序は必ずしもこの図で示される内容と一致するとは限らない。従って、その場合は、実際の配信処理の仕様に合わせてデータが出力されるよう生成手順が変更されることになる。

始めに、図６の１行目（６１）に示されるメディア情報を設定する。この情報として、メディアタイプとしてビデオを扱うことを示す“video”、後続のストリーミング処理で使用するRTPセッションのポート番号、および、RFC3016におけるMPEG-4 Videoのペイロード・フォーマットを示す値“RTP/AVP 96”を設定する。

次に、図６の２行目（６２）に示される帯域幅情報を設定する。“AS”は、Application-Specificの略である。すなわちこの情報はアプリケーションおよび環境依存であり、任意の内容を設定する。

次に、図６の３行目（６３）に示される、メディアのサブタイプおよびタイムスタンプの解像度を設定する。メディアのサブタイプは、RFC3016におけるMPEG-4 Videoを示す“MP4V-ES”を設定する。タイムスタンプの解像度は、特に指定が必要なければ、90000（90kHz）を設定する。

次に、図６の４行目（６４）に示される、ISMA仕様におけるヒントトラックに対する操作を行うためのトラック識別子を設定する。しかし、この例ではヒントトラックは存在しないため、配信対象の映像ストリームのデータを保持するビデオトラックに対する仮想的なヒントトラックを示す識別子として“trackID=5”を設定する。この内容は、「５番のＩＤを持つトラックは、配信される映像ストリームのヒントトラック」であることを示している。ただし、実際にはそのようなトラックは存在しないので、“trackID=5”が指定された場合は、仮想的に関連付けられたビデオトラックに対して操作を行うように振る舞う。このＩＤの値は、他の実在するトラックおよび仮想的なトラックのＩＤと重複せず、トラック間の関連が一意に管理できるようになっている限りは、仕様で許可される範囲内で任意の値を用いることができる。なお、この行の内容は、後述の第２実施形態で説明するISMA仕様に準拠する機器においては必須となるため、第２実施形態を実施する場合はこの記述にしたがって設定されなければならない。

次に、図６の５行目（６５）に示される、メディアのフォーマット・タイプおよびプロファイル・レベル、デコーダの設定情報を設定する。フォーマット・タイプは、RFC3016におけるMPEG-4 Videoフォーマットを示す値96を指定する。プロファイル・レベル（profile-level-id）には、入力ファイル中のビデオトラックのESDに含まれるDecoderSpecificInfoに記述されているプロファイル・レベルの値を、デコーダの設定情報（config）には、上記DecoderSpecificInfo全体のデータを１６進テキスト化して設定する。

次に、図６の６行目（６６）に示される、ISMA仕様におけるMPEG-4 Videoストリームのエレメンタリー・ストリームIDを設定する。このエレメンタリー・ストリームIDは、入力ファイル中のビデオトラックのESDに記述されているES_IDの値を取得、設定するか、あるいは第２実施形態で後述するISMA仕様に準拠する場合においては、ISMA仕様によってあらかじめビデオストリームに対して設定されている固定値（ここでは201）を設定する。なお、この行の内容は、後述の第２実施形態で説明するISMA仕様に準拠する機器においては必須となるため、第２実施形態を実施する場合はこの記述にしたがって設定されなければならない。

以上の手順にしたがって設定されたデータは、図６で示される形式に整形され、ストリーミング情報を構成するセッション記述情報として生成される。

［RTPパケットの生成］
次に、RTPで送信されるRFC3016で示される形式のパケットの生成手順を示す。

図７は、RFC3016で規定されるパケットの各項目のレイアウトを示す図である。左端の列は各項目の４バイト単位のバイトオフセットＮを示す列であり、上段の行はバイトオフセットＮに対してさらにバイト単位のオフセットを示す行である。すなわち、例えばTimestamp（タイムスタンプ）の項目は、パケットの先頭から５バイト目に配置される（Ｎ＝４であり、Ｎ＋１から配置される）ことを示している。なお、この実施形態では、拡張ヘッダおよびSSRCおよびCSRCは使用しないものと想定する。

まず、項目Version（Ｖ）に、0x02を設定する。この項目はRTPのプロトコルバージョンを示すもので、現在は2が用いられているためである。その次の項目Padding Flag（Ｐ）は、一連の処理の最後に設定するものであり、ここでは設定しない。項目Extension Flag（Ｘ）は、RTPヘッダに拡張ヘッダが付加されるかどうかを示す。本実施形態では拡張ヘッダは使用されないものと想定しているため、0を指定する。項目CCRC Count（ＣＣ）は、後続のCSRCのエントリ数を示す。本実施形態ではCSRCは使用されないものと想定しているため、0を指定する。

その次の項目Marker Bit（Ｍ）は、一連の処理の最後に設定されるものであり、ここでは設定しない。項目Payload Type(ＰＴ)は、パケットのペイロード・タイプを示す。本実施形態では、入力データに、MPEG-4 Videoストリーム・データが格納されていることを示すデータ構造であるMP4VSample Entry（“mp4v”）が存在している場合、もしくは、このMP4VSample Entryを構成する前述のES_Descriptorに含まれる項目objectTypeIndicationにMPEG-4 Visualを示す値0x20がセットされている場合に、RFC3016におけるMPEG-4 Videoのペイロード・フォーマットを示す値96を項目ＰＴに設定する。

項目Sequence Numberは、ある特定のランダムな値から始まり、RTPパケットの送信毎にインクリメントされるシーケンシャルな番号で、RTPセッションの開始時に任意の初期値が選択される。本実施形態では、RTPセッションの開始時に選択されたSequence Numberの初期値がRTPパケットの送信毎にインクリメントされる。

項目Timestampは、コンポジット時刻を示すタイムスタンプである。本実施形態では、入力MP4ファイルにコンポジット時刻を記述するデータ構造であるCompositionTimeToSampleBox（“ctts”）が存在している場合は、そこから伝送対象のフレームのコンポジット時刻を取得し、Timestampに設定する。ただし、入力MP4ファイルにCompositionTimeToSampleBoxが存在しない場合は、代わりにデコード時刻を記述するデータ構造であるTimeToSampleBox（“stts”）から伝送対象フレームのデコード時刻を取得し、コンポジット時刻として設定するようにする。伝送対象フレームが複数のパケットに分割される場合、最初のパケットと同じTimestampの値を同一のフレームを示す２番目以降のパケットに対しても適用する。

項目SSRC（Syncronization Source Identifier）は、同期して扱われる複数のストリームが同じパラメータを共有するために割り当てられる識別子である。本実施形態ではSSRCは使用されないものと想定しているため、0を指定する。

項目CSRC（Contributing Source Identifiers）は、ストリームが変形・編集された場合に、処理後のストリームの提供元を示す識別子である。本実施形態ではCSRCは使用されない（ＣＣ＝０）ものと想定しているため、CSRCは設定しない。

以上のパケットヘッダー項目に続けて、送信対象のフレーム・データをペイロード・データとして設定する。本実施形態では、フレーム・データは1488バイト毎に分割され、ペイロード・データとして用いられるものとする。

なお、上記のフレーム・データの分割単位である1488バイトは、主にＬＡＮ環境で用いられるIEEE802.3（イーサネット（登録商標））を伝送媒体に用いる場合を前提に設定された値である。図８は、イーサネット（登録商標）におけるデータ伝送単位のレイアウトを示す図である。図において、イーサネット（登録商標）で伝送可能なデータ・ブロックのサイズは48バイトから1500バイトであると示されている。すなわち、前述の1488バイトは、イーサネット（登録商標）を用いる場合の最大MTU（Maximum Transmission Unit Size）である1500バイトから、図７で説明したRTPヘッダのサイズである12バイトを減じたもので、イーサネット（登録商標）上でRTPパケットを伝送する場合の最大ペイロード・サイズを示す値である。

上記のように、フレーム・データを分割して生成されるペイロード・データのサイズが４バイトの倍数に満たない場合、ペイロードの末尾にパディング・ビットを付加し、さらに前述のヘッダ項目Padding Bit（Ｐ）に１を設定する。また、１つのフレーム・データから生成される最後のパケットに対しては、前述のヘッダ項目Marker Bit（Ｍ）に１を設定する。

なお、上記の手順では分割された符号化データがペイロードとしてパケットに含まれた形で送信パケットの情報を生成しているが、必ずしも符号化データの内容を含んだ形でパケット情報を生成する必要はなく、パケットヘッダー情報とペイロードとして設定される符号化データを取得するためのオフセット位置やサイズなどの参照情報を１組としてパケット情報が構成されてもよい。その場合は、後続のステップＳ２０４では、パケット情報に含まれるペイロードの参照情報を元に、MP4ファイルから符号化データを参照し、データを取得する必要がある。なお、ペイロードとして設定される符号化データを参照するための関連情報は、後述のトラック参照としてMP4ファイル中に記述される。

以上述べたような手順にしたがって、上記ステップＳ２０３によって送信パケットの生成に必要な情報が生成される。

上記の手順によって、ステップＳ２０３で生成されたセッション記述情報および送信パケットはストリーミング情報としてステップＳ２０４に渡され、ステップＳ２０４ではその情報を元に、RTSPおよびRTPの送信手順にしたがってネットワークＩ／Ｆ１１４を介して送信される。

このように本実施形態で示されるネットワークカメラは、ヒントトラックやセッション記述情報を含んでいないMP4ファイルの配信が要求された場合にも、配信に必要なストリーミング情報を逐次生成しストリーミング配信を行うことができる。

＜第２実施形態＞
次に、第２実施形態として、前述のISMA仕様によって規定される通信方法に準拠したネットワークカメラを例にとって説明する。

ISMA仕様においては、図２で説明したように、RTSPにより通信セッションを開始する時点で、IOD、OD、BIFSのデータを送信するように規定されている。これらのデータの実体は、図９で示されるように、SDP形式で記述されたRTSPのヘッダ項目中、“a=mpeg4-iod:”で始まる行のデータとして記述される。この行のデータはURL（Uniform Resource Locator）として表され、URLの末尾には、二進データのテキスト符号化形式の一つであるBase64形式で符号化されたIODのデータをセットするように規定している。さらに、ODおよびBIFSストリームのデータも、IOD同様のURL形式で符号化され、IODのデータ中に埋め込まれるものとしている
すなわち、ISMA仕様で規定される形式での通信処理に対応する場合は、MP4ファイルに含まれるIOD、ODおよびBIFSデータをISMA仕様で規定されるURL形式に符号化し、RTSPによるセッションの開始時にSDP形式のRTSPヘッダとして送信するといった処理が必要になる。本実施形態では、このようなIOD、OD、BIFSデータを含むセッション記述情報を生成するために行われる処理の詳細を説明する。

［IOD、OD、BIFSデータを含むセッション記述情報の生成］
ISMA仕様にしたがって配信を行うにあたり、図５のステップＳ３０２において、配信を行うコンテンツ・データがISMA仕様で定められている要件を満たしているかチェックする。例えば、映像・音声ストリームが複数存在するようなケースは要件外であるため、エラーとして以降の処理をキャンセルしたり、要件と適合するストリームのみを選択して使用するなどの制御を行う。なお、要件の詳細に関しては、ISMA仕様文書に定義されているため、本明細書では説明を省略する。

その後、ステップＳ３０３、Ｓ３０４の処理により、図９に示されるセッション記述情報を生成する。なお、図９に示される情報構成は一例であり、実際の配信処理で用いられるデータおよび形式、順序は必ずしも図９で示される内容と一致するとは限らない。従って、その場合は、実際の配信処理の仕様に合わせてデータが出力されるよう生成手順が変更されることになる。

始めに、図９の１行目（９１）に示される帯域幅情報を設定する。この情報はアプリケーションおよび環境に依存するものであり、任意の内容を設定する。

その次に、図９の２行目（９２）に示されるように、ISMA仕様準拠であることを示す文字列“isma-compliance:1,1.0,1”を設定する。更に、次に、図９の３行目（９３）で示されるような形式で、ISMA仕様で示される形式で符号化された、OD、BIFS を含むIODデータを設定する。

ただし、MP4ファイルに含まれるIOD、ODデータは、ISMA仕様で規定されているIOD、ODのデータとは異なる構造になっているため、MP4ファイルに記録されているデータをそのまま取得して使用することは出来ず、データ構造の変換処理が必要になる。その処理の説明に先立って、IOD、ODデータがどのような構造になっているかを説明する。

［IOD、ODのデータ構造］
ISMA仕様で定義されるIODおよびODは、図１で示されるように、エレメンタリーストリームを一意に識別する識別子であるES_IDを用いて記述対象のエレメンタリーストリームとの関連を記述する。図１の場合、IODにはODストリームのES_IDが記述され、ODにはビデオあるいはオーディオストリームのES_IDが記述されていることが示されている。

しかしながら、MP4ファイルに記録されるIODおよびODのデータ構造は、図１で示されるものとは若干異なっている。MP4ファイルに記録される場合のIODおよびODのデータ構造について、図１０を用いて説明する。

図１０に示されるように、MP4ファイルに記録されるデータは「ボックス」（Box）と呼ばれるいわゆる入れ子型のデータ構造によって構造化されて記述される。コンテンツの情報は「ムービー」（moov）と呼ばれるコンテンツ全体を示すボックス内に、個々のエレメンタリーストリームに対応する「トラック」（trak）というボックスを包含する形で構造化される。また、トラックに対応するエレメンタリーストリームの符号化データは、「メディアデータ」(mdat)というボックス内に格納される。

トラックを一意に識別できるようにするため、各トラックには「トラックID」（Track ID）という識別子が割り当てられ、そのトラックIDを「トラック参照」(tref)と呼ばれるボックス中に記述することによって、複数のトラック間の関連を定義することが可能となっている。トラック参照には、意味が異なる複数の関連を定義できるようにするため、関連の意味を示すタイプ情報を持たせることができる。ODから参照されるストリームの関連情報は、mpodというタイプを持ったトラック参照として記述される。また、ヒントトラックから参照される符号化データを含むトラックの関連情報は、hintというタイプを持ったトラック参照として記述される。

図１０が示す通り、MP4ファイル形式の場合はこのトラック参照を用いてエレメンタリーストリームの参照を行うようになっている。そのため、関連の記述方法は図１とは明らかに異なった形となっている。

まず、IODはESDを持っておらず、参照するESに対応するトラックのトラックIDのみを持つ。本来IODに含まれるESDは、参照先のトラックのデータとして、IODとは独立したデータとして記録される。

また、ODもESDを持たず、mpodタイプのトラック参照に含まれるデータのインデックスを示す１から始まる番号のみが記録される。ODとESの関連を示すタイプのトラック参照のデータ中のインデックス番号で示される位置のデータに、参照するESに対応するトラックのトラックIDが記述されており、このトラックIDによってODが参照するESが特定される。IODと同様に、本来ODに含まれるESDは、参照先のトラック中にODとは独立したデータとして記録される。

このように、MP4ファイル形式の場合、IOD、ODおよびESDに相当するデータの形式は通常と異なっているため、それぞれに対して割り当てられているタグの値もMP4ファイル形式用の特殊な値が使用される。図１０のように、IODに相当するデータには0x10（MP4_IOD_Tag）が、その中に含まれるESDに代わるデータには0x0E（ES_ID_IncTag）が使用される。また、ODに相当するデータには0x11（MP4_OD_Tag）、その中に含まれるESDに代わるデータには0x0F（ES_ID_RefTag）が使用される。

上記のようなIOD、ODの記述形式の違いが存在するため、ISMA仕様に従ったIODおよびODデータを生成するには、MP4ファイルのボックス構造を解析し、各トラックの参照関係が正しく反映されたES_ID、および各トラックのESDが含まれた形でIODおよびODデータを生成しなければならない。

以下、、MP4ファイルの内部に格納される形式のIODのデータ構造の変換処理について、図１１のフローチャートを用いて説明する。なお、図１１のフローチャートは、ストリーミングコントローラ１１３によって実行されるステップＳ３０４におけるIODの設定処理をより詳細に説明するものである。

［IODの変換処理］
まず、ステップＳ４０１において、ファイルにIODデータが含まれているか否かを確認する。通常、MP4ファイルにはIODデータは含まれているが、含まれていない場合はステップＳ４０２へ進み、デフォルトのIODデータを作成する処理を実行して、後続の処理はスキップする。なお、ステップＳ４０２によるデフォルトのIOD生成処理の詳細については後述する。

ファイル中にIODデータが含まれている場合は、ステップＳ４０３へ進み、MP4ファイルの内部に格納される形式のIODのバイナリデータを取得する。このIODデータは、あらかじめステップＳ２０２でMP4ファイルを解析して得られた結果として、ストリーミングコントローラ１１３によって取得可能な状態で保持されている（システムＲＡＭ１１７に保持されている）ものとする。

次に、ステップＳ４０４において、IOD中のES_ID_IncTagをES_DescrTagに置換する。同時に、ES_ID_IncTagに続くトラックIDで参照されるトラックの“esds”ボックスからESDデータを取得し、IOD中のES_DescrTagで示される位置にセットする。図１２を例に挙げて説明すると、MP4ファイルにおいて、IOD５０１内のTrack IDによってトラック５０２が指定されている。このTrack IDを示すES_ID_IncTagを、ESDを示すES_DescrTagに置換する。そして、指示されたトラック502内の“esds”ボックス５０３にあるESD５０４を取得し、これを置換したES_DescrTagの位置にセットする。こうして、ESD５０４を含んだIOD５０１'に変換される。

そして、ステップＳ４０５において、IODから参照される全てのエレメンタリーストリームに対して、ESDを設定する処理が行われたかチェックする。全てのエレメンタリーストリームの処理が完了していなければ、ステップＳ４０４に戻り、未処理のエレメンタリーストリームの処理を行う。

上述のような変換処理によって、MP4ファイルに格納される形式のIODデータを適切に変換できるようになる。

［ODの変換処理］
引き続き、MP4ファイル形式のODデータを変換する場合の手順を、図１３を用いて説明する。なお、図１３のフローチャートは、ストリーミングコントローラ１１３によりステップＳ３０４として行われるODの設定処理をより詳細に説明するものである。

ODのデータは、IODと異なり、エレメンタリーストリームのデータとしてMP4ファイルに記録される。すなわち、ODのデータは他のビデオやオーディオなどのデータ形式と同じように、メディアデータの構成単位である「サンプル」として扱われる。従って、ODデータを処理するためには、ODストリームのサンプルデータをそのままの状態で参照できるようにするための解析処理がステップＳ２０２で行われなければならない。さらに、ODのデータを取得するためには、サンプルデータを取得しようとするトラックがODデータのトラックであるかどうかを判断するための情報が必要である。トラックがODデータのトラックであるかどうかは、そのトラックのESDに含まれるDecoderConfigDescriptorのstreamTypeが0x01(ObjectDescriptorStream)であるかによって判断可能である。したがって、ステップＳ２０２の処理でにおいてトラックのstreamTypeを参照可能な状態でシステムＲＡＭ１１７に保持しておく必要がある。

以下のODの変換処理では、トラックのstreamTypeの内容を確認し、streamType=0x01の時であればそのトラックはODストリームであると判断し、そのトラックのデータの変換処理を行うようにする。

ODに含まれるESDも、IODと同様に、MP4ファイルの内部では別のタグおよび参照形式として表わされ、記録される。具体的には、ODに含まれるESDは、MP4ファイル内では“mpod”トラック参照のインデックスを保持するES_ID_Refとして保持される。そのため、MP4ファイル形式のODデータの変換は、IODの変換とおおむね同じ処理手順で行える。

まず、ステップＳ６０１において、ファイルにODデータが含まれているか否かを確認する。ODデータの有無は、ESD中のstreamTypeが0x01であるトラックがファイルにあるか否かをチェックすることによって確認できる。通常、MP4ファイルにはODデータは含まれているが、含まれていない場合は、ステップＳ４０２においてデフォルトIODデータ作成処理を実行し、IODと一緒にデフォルトのODデータを作成する。なお、ステップＳ４０２のデフォルトのIOD生成処理の詳細については後述する。

ODデータがある場合は、ステップＳ６０２において、MP4ファイルの内部に格納される形式のODデータを取得する。次に、ステップＳ６０３において、ODデータ中のES_ID_RefTagをES_DescrTagに置換する。同時に、そのODデータを取得したトラックに含まれる“mpod”タイプのトラック参照データ中、ES_ID_RefTagに続くインデックス番号の位置のトラックIDで参照されるトラックの“esds”ボックスからESDデータを取得し、OD中のES_DescrTagで示される位置にセットする。

例えば、図１４の場合、トラック７０２において、DecoderConfigDescriptorのstreamTypeが0x01であり、トラック７０２に対応するエレメンタリーストリームがOD７０１であった場合、OD７０１内のES_ID_RefTagで示される領域７１０をES_DescrTagに置換する。そして、ODトラックに含まれる“mpod”タイプのトラック参照７０５から、領域７１０内のindex７１１によって示されるトラックID７０６を取得し、そのトラックID７０６で示されるODの参照トラック７０７のesdsボックス７０８よりESD７０９を取得する。そして、ES_DescrTagの部分にこのESD７０９を組み込んだODデータ７０１'を生成する。

そして、ステップＳ６０４において、ODが参照する全てのエレメンタリーストリームに対して、ESDの設定処理が行われたかをチェックし、未処理のエレメンタリーストリームがある場合はステップＳ６０３に戻る。

［IODデータのISMA形式への変換］
ISMA仕様で配信に用いられるIODデータの場合、上述の処理によって、MP4ファイルに格納される形式のIODデータおよびODデータから、さらにISMA仕様で規定される形式に変換しなければならない。

上記の処理で変換されたIOD、ODと、ISMA仕様のIOD、ODのデータ構造の違いを図１５に示す。上記の変換によって得られる形式の場合、図１５におけるIOD８０１は、典型的にはODストリーム８０４に対応するESD８０２と、BIFSストリーム８０５に対応するESD８０３とを含んでいる。しかし、ODストリーム８０４およびBIFSストリーム８０５のストリームデータ自体はIOD８０１とは独立したデータとして存在している。

これに対して、ISMA形式の場合、IODの形式はODデータ８０４、BIFSデータ８０５が組み込まれた形のIOD８０１'のような形式になる。そのため、ISMA準拠のストリーミング情報を作成するには、上記の処理によって得られたIODをさらにISMA形式に変換しなければならない。その変換処理の手順を図１６のフローチャートで説明する。

まず、ステップＳ９０１において、図１１のフローチャートで示した手順によりMP4ファイルからIODデータを取得し、変換する処理を行う。次に、ステップＳ９０２において、図１３で示した手順によりMP4ファイルからODデータを取得し、変換する処理を行う。

次に、ステップＳ９０３において、MP4ファイルからBIFSデータを取得する処理を行う。BIFSデータを取得するには、前述のDecoderConfigDescriptorのstreamTypeが0x03（SceneDescriptionStream）であるESDを持ったトラックを探し、そのトラックのデータを取得する。なお、MP4ファイルには通常、BIFSトラックは必ず存在するので、本例ではBIFSトラックが存在しない場合を考慮していない。

そして、ステップＳ９０４において、上記のステップＳ９０１で得られたIODデータに、ステップＳ９０２、Ｓ９０３で得られたODデータ、BIFSデータを、ISMA仕様で規定される形式で組み込む。ISMA仕様では、IODに組み入れられるODおよびBIFSデータは、Base64形式でテキスト符号化され、先頭に“data:application/mpeg4-od-au;base64,”（ODの場合）、あるいは“data:application/mpeg4-bifs-au;base64,”（BIFSの場合）という接頭句が付加されたテキストの形で、ESDのURLstringフィールドで保持される。以上のような形式でIOD、OD、BIFSデータの統合および符号化処理を行い、ISMA仕様で規定された形態のIODデータが生成されることになる。

以上述べたような処理を行うことによって、MP4ファイルに含まれるIOD、OD、BIFSなどのシステムデータをISMA仕様準拠の形に変換できる。このことにより、MP4ファイルにISMA準拠のIODデータが含まれていなくても、ISMAに準拠したストリーミング配信に対応した形式のIODデータを生成し、これを送信できるようになる。

［デフォルトIODの生成処理（ステップＳ４０２の処理）］
以上、MP4ファイルから取得したIODおよびODデータをISMA仕様の形式に変換する処理について説明してきたが、IOD、ODといったデータはどのようなファイルにも含まれているとは限らない。例えば、3GPPファイルはMP4ファイルとは異なり、IOD、BIFS、ODといったデータは含まれない。そのため、3GPPファイルのようなファイルを扱う場合には、IODなどのデータをファイルから取得せず、デフォルトのIODとして作成するといった処理を行う必要がある。

デフォルトのIODデータは、あらかじめ本実施形態のネットワークカメラのシステムＲＯＭ１１６で固定のデータとして準備しておく。あるいは、システムＲＯＭ１１６に保持されている固定IODデータを「テンプレート」として、システムＲＯＭ１１６のIODデータの内容のうち、ビットレートやデコードバッファサイズ、DecoderSpecificInfoなど条件によって変動する一部のデータ項目を書き換えたIODデータを、システムＲＡＭ１１７に保持して使用するような処理を行ってもよい。なお、デフォルトIODの内容は配信するファイルのストリーム構成（例えば、映像のみ、音声のみ、映像・音声といったストリームの組み合わせ）によって異なるため、構成毎に複数のデフォルトIODを準備しておく必要がある。

以下、ファイル中にIODデータが存在しない3GPPファイルを扱う場合に、デフォルトのIODを生成する処理を図１７のフローチャートを用いて説明する。なお、このフローチャートは、上述の図１１および図１３の処理において、3GPPファイルを扱った場合のステップＳ４０２における処理を詳細に説明するものである。

まず、ステップＳ１００１において、処理対象の3GPPファイルのストリーム構成が、映像のみ、音声のみ、映像・音声の組み合わせのいずれであるかを確認する。次に、ステップＳ１００２において、ステップＳ１００１で確認された3GPPファイルのストリーム構成に対応するデフォルトのIODデータを、システムＲＯＭ１１６から取得し、システムＲＡＭ１１７上に保持する。そして、ステップＳ１００３において、システムＲＡＭ１１７上に保持されているデフォルトのIODデータ中、ビットレートやデコードバッファサイズ、DecoderSpecificInfoなど、エンコード条件によって変化するデータや、ES_IDなどファイルから取得可能なデータの内容を3GPPファイルから取得し、システムＲＡＭ１１７上のデフォルトのIODデータに上書きして書き換える。

このような処理を行うことによって、3GPPファイルのようにファイル中にIOD、OD、BIFSデータが含まれていないファイルであっても、ISMA仕様で規定されているIODデータを生成し利用することが可能になる。

以上のように、本実施形態のネットワークカメラでは、以上述べたような諸々の処理によって、ステップＳ２０３でストリーミング情報を作成し、それを用いてストリーミング配信を行うことができる。これまでの説明で述べたように、特に、第２実施形態で示されるネットワークカメラは、ストリーミング配信用に図９のようなセッション記述情報を含んでいないコンテンツファイルや、3GPPファイル形式のようにIOD、OD、BIFSを含まない形式のファイルに対しても、ISMA仕様に準拠した形でセッション記述情報を生成し、ストリーミング配信が行うことが出来る。

＜第３実施形態＞
第３実施形態では、配信時に生成するストリーミング情報をファイルとして出力するネットワークカメラを例にとって説明する。

図４のステップＳ２０３で生成されたストリーミング情報は、第１実施形態では、作成直後にストリーミング配信処理で用いられた後は保存されずに破棄されていた。第３実施形態では、この出力データを配信処理が終わっても利用できるようファイルなどの形で装置内で保持・管理し、以前に配信されたことのあるファイルの配信が再び要求された場合にはこの出力データを再利用することで、ストリーミング情報の生成処理を逐一行わずとも配信が行えるようにするる。

［ストリーミング情報ファイルの出力処理］
以下、第３実施形態のネットワークカメラにおいて、配信時に生成されたストリーミング情報をファイルとして出力、記録する処理について、図１８のフローチャートを用いて説明する。

図１８のフローチャートの処理は図４とほぼ同じであり、ステップＳ１１０１からＳ１１０４の処理は、図４におけるステップＳ２０１からＳ２０４と同じであるため、説明は省略する。図１８のフローチャートでは、ステップＳ１１０１からＳ１１０４の処理が行われた後に、ステップＳ１１０５において、ステップＳ１１０３で生成したストリーミング情報の出力処理が行われる。

ステップＳ１１０５で、ストリーミングコントローラ１１３は、ステップＳ１１０３で生成されたストリーミング情報をファイルとして外部記憶Ｉ／Ｆ１１１を介して外部記憶１１２に記録していく。ストリーミング情報はその生成もとのコンテンツデータとの対応がわかり、後から読み出し可能に記録されればよい。本実施形態では、図１９に示されるようにファイルの形態でストリーミング情報を保存する。この例では、配信対象のMP4ファイルが“MOV0001.MP4”というファイル名である場合、ステップＳ１１０５で出力される情報は、配信対象ファイルのファイル名のベース名“MOV0001”に、出力される情報の種類を示す拡張子が付加されたファイル名で出力される。さらに、ファイルの各トラックの情報は、ベース名“MOV0001”にトラックを識別する連番を付加したファイル名として出力される。例えば、ムービーのセッション記述情報は“MOV0001.SDP”、１番目のトラックに対して付与されたヒントトラック情報は、“MOV0001-1.HNT”というファイル名でストリーミング情報が出力される。

［ストリーミング情報ファイルを用いる配信処理］
引き続き、上記の処理によってファイルに記録されたストリーミング情報を用いる配信処理の手順を、図２０のフローチャートを用いて説明する。

まず、ステップＳ１２０１において、ストリーミングコントローラ１１３はネットワークＩ／Ｆ１１４を介して配信先端末から送付されたMP4ファイルの配信要求を受信する。本実施形態では、MP4ファイルの配信要求はRTSPを用いて図２１で示されるような書式で配信先端末から送付されるものと想定する。図２１では、配信対象のMP4ファイルは、RTSPのDESCRIBEコマンド（２１１）で指定されているURL文字列“rtsp://192.168.0.1/MOV0001.MP4”中の、“MOV0001.MP4”の部分で示される。

ステップＳ１２０２では、ストリーミングコントローラ１１３は受信した配信要求に含まれる配信対象のファイル名を取得する。図２２の例の場合は、“MOV0001.MP4”の部分をURLを解析して取得する。

次に、ステップＳ１２０３で、ストリーミングコントローラ１１３は要求されたファイルが存在するかどうかをチェックする。図２１の例の場合、ファイル名が“MOV0001.MP4”のファイルが外部記憶１１２に存在するかチェックし、存在しない場合はステップＳ１２０４で示されるエラー処理を行い、後続の処理は行わずに当該配信要求に対する処理を終了する。

要求されたファイルが存在する場合は、ステップＳ１２０５において、ストリーミングコントローラ１１３は要求されたMP4ファイルの内容を解析する。ただし、本実施例の場合、解析結果は後続の符号化データの配信などの処理に用いられるが、ストリーミング情報の生成には利用されない。なお、この処理は、上述の図４のステップＳ２０２の処理と同じであるため、ここでの説明は省略する。次に、ステップＳ１２０６において、ストリーミングコントローラ１１３は要求されたMP4ファイルに対応するストリーミング情報が記録されたファイルが存在するかチェックする。図２１の例の場合、要求されたファイル名が“MOV0001.MP4”であるので、ファイルのベース名として“MOV0001”を有する、図１９で示されるようなストリーミング情報ファイル群が外部記憶１１２に存在するか否かをチェックする。

要求ファイルに対応するストリーミング情報ファイルが存在する場合は、ステップＳ１２０７において、外部記憶１１２からストリーミング情報ファイルの内容を取得する。ストリーミング情報ファイルが存在しない場合は、ステップＳ１２０８において、ストリーミング情報の生成処理を行う。なお、この生成処理は上述の図４のステップＳ２０３の処理と同じであるため、ここでの説明は省略する。

そして、ステップＳ１２０９において、ストリーミングコントローラ１１３は上記のステップＳ１２０７で取得あるいはステップＳ１２０８で生成されたストリーミング情報に基づいて、要求されたMP4ファイルの符号化データをネットワークＩ／Ｆ１１４を介してストリーミング配信する。

このように、配信対象のファイルと関連付けられた形でファイルを生成することにより、後で再びファイルの配信が要求された時に、要求されたファイルのベース名を持ったストリーミング情報ファイルが存在する場合は、そのファイルの情報を使用してストリーミング配信処理を行うということが可能になる。

なお、本実施形態では、ステップＳ１１０５でファイルに出力されるストリーミング情報の記述形式は、MP4ファイル形式のような標準ファイル形式で記述されても、任意の独自の形式で記述されてもよい。

また、本実施形態では、配信対象のMP4ファイルとストリーミング情報ファイルとの相関をファイル名を用いて定義しているが、配信対象のMP4ファイルにストリーミング情報ファイルとの関連を定義するための管理用データを別途生成したり、あるいはストリーミング情報自体を配信対象のMP4ファイルに追加記録するようにしてもよい。

＜第４実施形態＞
第４実施形態として、ストリーミング情報の生成のしかたを静的に、あるいは実行時に動的に変更することができるネットワークカメラを例にとって説明する。

本実施形態では、ストリーミング制御情報の生成方法に関する設定情報をストリーミングコントローラ１１３に与えることによって、ストリーミングコントローラ１１３はストリーミング情報の生成方針や生成形態を変化させることが出来るものとする。

ストリーミングコントローラ１１３に与えられる設定情報の例を図２２に示す。例えば図２２の１行目（２２１）に示される“max_pdu_size”は、ストリーミングコントローラ１１３が生成するパケットの最大サイズを示す。ストリーミングコントローラ１１３はこの値に基づいて、ペイロード・データの分割を制御する。２行目（２２２）に示される“repeat”は、伝送エラーに備えてパケットを複数回送信するか否かを示す。ストリーミングコントローラ１１３はこの値に基づいてパケットに再送フラグ等の設定を行う。３行目（２２３）の“approval_packet_loss”は、許容されるパケット損失率（％）を示すもので、ネットワークＩ／Ｆ１１４において検出されたパケット損失率が指定されたパケット損失率を上回った場合に、ストリーミングコントローラ１１３はパケットの再送フラグを設定するなど、エラーに対する耐性を高めるための制御を行う。

なお、これらの設定情報は、システムＲＯＭ１１６上に固定データとして保持されても、あるいは外部記憶１１２やシステムＲＡＭ１１７に書き換え可能なデータとして保持されてもよい。また、複数の設定情報をテーブルとして保持し、配信時のモードやネットワークの混み具合、セッション数などの配信条件に応じて適応的に設定条件を選択するようにしてもよい。このようにすることで、本実施形態で示されるネットワークカメラは、ストリーミング情報が実際に適用されるネットワーク環境と適合していなくても、適応的なストリーミング配信を行えるようにすることができる。

＜第５実施形態＞
第５実施形態として、配信されるMP4ファイルが登録された時点で、ストリーミング情報を生成するネットワークカメラを例にとって説明する。

本実施形態のネットワークカメラは、図２３で示されるようなコンテンツ配信システムの構成要素として用いられるものと想定する。図２３は典型的なコンテンツ配信システムの概略構成を示している。図２３において、コンテンツの作成者は、ファイル作成端末１３０３から作成したMP4ファイルを配信サーバの役割を果たすネットワークカメラ１３０１へアップロードすることにより、配信対象のファイルとして登録出来るものとする。このファイル作成端末１３０３は、パーソナルコンピュータや携帯電話、PDA、あるいは他のネットワークカメラなど、ネットワークカメラ１３０１に対してコンテンツファイルの送信が可能な機器であれば、いかなるものであってもよい。また、アップロード時の通信経路は、インターネット等の公衆網であっても、BluetoothやUWB、IEEE 802.11などの無線通信路であっても、USBやIEEE1394などの機器間接続用外部バスであってもよい。

上記のアップロード処理によってネットワークカメラ１３０１に登録されたMP4ファイルは、配信先端末１３０２から閲覧、配信要求が可能になる。すなわち、ネットワークカメラ１３０１は配信先端末１３０２からの要求に応じてMP4ファイルをストリーミング配信する。

図２３のコンテンツ配信システムにおいて、ネットワークカメラ１３０１は、ファイル作成端末１３０３からアップロードされるMP4ファイルの受信時に、第３実施形態で示されるようにストリーミング情報をファイルに出力する処理を行う。本実施形態では、MP4ファイルがネットワークカメラ１３０１に登録された時点では、ストリーミング情報の生成のみを行い、登録されたファイルの配信は行わない。ネットワークカメラ１３０１は、、配信先端末１３０２から配信要求を受け付けてから、MP4ファイルの登録時に生成されたストリーミング情報を利用して要求されたファイルの配信を行う。

［ファイル登録時のストリーミング情報の生成処理］
以下に、本実施形態のネットワークカメラにおいてファイルの登録時に行われるストリーミング情報の生成処理の手順を、図２４のフローチャートを用いて説明する。

まず、ステップＳ１４０１で、ネットワークカメラ１３０１はファイル作成端末１３０３からアップロードされたMP4ファイルをネットワークＩ／Ｆ１１４から受け取り、外部記憶Ｉ／Ｆ１１２を介して外部記憶１１２に保存する。なお、この処理はストリーミング配信処理と連動して行われる必要はないため、ストリーミングコントローラ１１３によってではなく、システムコントローラ１１５やその他の図示されない制御モジュールによって行われてもよい。ただしその場合、後続の処理をストリーミングコントローラ１１３で実行するため、ステップＳ１４０１の処理を実行したモジュールはストリーミングコントローラ１１３に対して、ファイルが登録されたことを何らかの手段で通知する必要がある。

次に、ストリーミングコントローラ１１３は、ステップＳ１４０１で登録されたMP4ファイルの内容を外部記憶１１２から取得し、ステップＳ１４０３で取得したMP4ファイルを解析し、ステップＳ１４０４でMP4ファイルのストリーミング情報を生成する。なお、これらステップＳ１４０２からステップＳ１４０４の処理は、図４のステップＳ２０１からＳ２０３の処理と同じである。

そして、ステップＳ１４０５において、ストリーミングコントローラ１１３は、生成されたストリーミング情報をファイルとして出力する。このファイルは、第３実施形態で説明したように、処理対象のMP4ファイルに対する配信要求が発生した時にストリーミング配信制御に用いられる。なお、ステップＳ１４０５の処理は、図１８におけるステップＳ１１０５の処理と同じであるためここでの説明は省略する。

このように第５実施形態で示されるネットワークカメラでは、あらかじめストリーミング用に作成されていないMP4ファイルでも、ストリーミング用の制御情報をMP4ファイルに付加するといった追加の作業を行うことなくストリーミングを行える。その際、アップロードされるMP4ファイルのデータ量も小さくて済むため、アップロードにかかる負荷や時間を圧縮することが出来る。

＜第６実施形態＞
図２５は、第６実施形態による、マルチメディアコンテンツのストリーミング配機能を提供するストリーミングサーバの構成を示すブロック図である。本実施形態のストリーミングサーバは、接続されている外部装置からMP4ファイルを取得し、ネットワークを介してストリーミング配信する機能を備える。

図２５において、ストリーミングサーバ１５０１は、第１実施形態のネットワークカメラと同様に、ストリーミングコントローラ１１３、ネットワークＩ／Ｆ１１４、システムコントローラ１１５、システムＲＯＭ１１６、システムＲＡＭ１１７を備える。また、各構成部は内部バス１１８によって接続されており、各部の処理はシステムコントローラ１１５によって制御される。また、ストリーミングサーバ１５０１は接続されている外部装置とのデータ入出力機能を提供する外部バスＩ／Ｆ１５０２を備える。本実施形態では、外部装置としてUSBマスストレージクラスに対応しているデジタルビデオカメラ１５０３が接続されているものと想定する。

ストリーミングコントローラ１１３は、外部バスＩ／Ｆ１５０２を介してデジタルビデオカメラ１５０３から配信対象のMP4ファイルを取得し、第１実施形態と同様に、多重化分離して得られた符号化データからRTPパケットを生成し、ネットワークＩ／Ｆ１１４を介して配信先端末にRTPでストリーミング配信を行う。

なお、以上のようなMP4ファイルを外部装置（ストリーミングサーバ１５０１）に蓄積する機器構成であっても、上記の第１実施形態から第５実施形態において説明した処理手順をそのまま当該外部装置に適用することができる。

＜第７実施形態＞
図２６は、第７実施形態によるストリーミングサーバの構成を示すブロック図である。本実施形態のストリーミングサーバ１６０１は、接続されている撮像装置から送信されたビデオデータおよびオーディオデータを多重化してMP4ファイルとして記録する機能と、記録されたMP4ファイルをネットワークを介してストリーミング配信する機能とを備える。

ストリーミングサーバ１６０１は、第６実施形態のストリーミングサーバ１５０１の構成に加え、さらに第１実施形態のネットワークカメラで示されたものと同様のファイル多重化コントローラ１０８、外部記憶Ｉ／Ｆ１１１、外部記憶１１２を備えるものとする。また、本実施形態では、撮像装置としてUSBビデオクラスに対応しているデジタルビデオカメラ１６０２が接続され、撮影されたビデオ、オーディオデータはMPEG-4符号化され、USBでアイソクロナス伝送されるものと想定する。

ストリーミングサーバ１６０１に、デジタルビデオカメラ１６０２で撮影されたビデオおよびオーディオの符号化データが外部バスＩ／Ｆ１５０２を介して入力されると、ファイル多重化コントローラ１０８は第１実施形態のネットワークカメラと同様に、符号化データをMP4ファイル形式に多重化し、外部記憶Ｉ／Ｆ１１１を介して、MP4ファイルを外部記憶１１２に出力する。

さらに、ストリーミングコントローラ１１３では、第１実施形態と同様に、外部記憶Ｉ／Ｆ１１１からMP4ファイルを取得、多重化分離してRTPパケットを生成し、ネットワークＩ／Ｆ１１４を介して配信先端末にRTPでストリーミング配信する。

以上のように、撮影機能を持たない機器構成（ストリーミングサーバ１６０１）であっても、第１実施形態から第５実施形態において説明した処理手順は、そのまま同じように適用することができる。

＜他の実施形態＞
本発明で生成される情報は、任意の通信手段（装置間プロトコル）およびデータフォーマットに適合する形式に加工することで、ネットワークなどの伝送路を介した他の機器に対しても本実施形態による出力を提供することが可能である。すなわち、本発明は、複数の機器から構成されるシステムに適用しても、単一の機器からなる装置に適用してもよい。

また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはCPUやMPU）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム(OS)などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるCPUなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。

本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

以上説明したように、上記各実施形態によれば、コンテンツ作成者はストリーミングを行うか行わないかによって関わらず単一のファイルのみを扱えばよくなるため、ファイルの管理を簡略化することが出来る。また、ストリーミング情報をファイルに付与するための追加作業が不要になるため、コンテンツ作成者の作業負荷を軽減できる。また、冗長なデータが付加されなくなるため、ストリーミングサーバへのアップロードに要する時間を短縮する事が出来る。さらに、例えば、IOD、OD、BIFSデータを含まないファイルでも、ISMA仕様により規定されている形式で配信することが可能になり、互換性を保つことが出来る。

MPEG-4におけるオブジェクトディスクリプタ情報を用いたメディアデータの関連定義を説明する図である。 ISMA仕様におけるストリーミング処理の手順を説明する図である。 第１実施形態による処理を実現するネットワークカメラの構成を示すブロック図である。 第１実施形態における、MP4ファイルの配信処理の手順を示すフローチャートである。 第１実施形態によるストリーミング情報生成処理を説明するフローチャートである。 SDP形式で記述された映像・音声データストリームの情報の例を示す図である。 RFC3016で規定されるパケットの各項目のレイアウトを示す図である。 イーサネット（登録商標）におけるデータ伝送単位のレイアウトを示す図である。 SDP形式で記述されたRTSPセッション記述情報の例を示す図である。 MP4ファイルにおけるメディアデータの関連定義を説明する図である。 MP4ファイルに格納される形式のIODデータ変換処理手順を示すフローチャートである。 IODデータ変換処理を説明する図である。 MP4ファイルに格納される形式のODデータ変換処理手順を示すフローチャートである。 IODデータ変換処理を説明する図である。 IODデータのISMA形式への変換処理を説明する図である。 IODデータのISMA形式への変換処理手順を示すフローチャートである。 デフォルトIOD生成処理手順を示すフローチャートである。 第３実施形態の処理手順を示すフローチャートである。 ストリーミング情報ファイルの構成例を示す図である。 ストリーミング情報出力処理手順を示すフローチャートである。 RTSPのファイル要求を例を示す図である。 ストリーミング情報生成動作の設定に用いられる設定情報の例を示す図である。 典型的なコンテンツ配信システムの概略構成を示す図である。 第５実施形態の処理手順を示すフローチャートである。 第６実施形態による処理を実現するストリーミングサーバの構成を示すブロック図である 第７実施形態による処理を実現するストリーミングサーバの構成を示すブロック図である

Claims (7)

1. コンテンツデータの配信方法であって、
   配信対象のコンテンツデータの構造を解析する解析工程と、
   前記解析工程の解析結果より前記コンテンツデータに配信制御のための記述が含まれていないと判断された場合に、該解析工程の解析結果であるコンテンツデータの構造に基づいてストリーミング情報を生成する生成工程と、
   前記生成工程で生成されたストリーミング情報に基づいて前記コンテンツデータをネットワークに配信する配信工程とを有し、
   前記生成工程では、前記解析結果に基づいて、前記コンテンツデータが有するオブジェクトに関する記述を前記配信工程における配信プロトコルに適応した記述に変換することを特徴とするデータ配信方法。
2. 前記ストリーミング情報は、配信先とのセッションを確立するための情報を含み、
   前記配信工程では、前記生成工程で生成されたストリーミング情報に基づいて前記配信先とのセッションを確立し、前記コンテンツデータを前記ネットワークを介して前記配信先に配信することを特徴とする請求項１に記載のデータ配信方法。
3. 前記生成工程では、前記配信プロトコルに対応した記述が前記コンテンツデータに存在しない場合、予め保持したデフォルトの記述を前記解析結果に基づいて書き換えることにより該配信プロトコルに適応した記述を取得することを特徴とする請求項１に記載のデータ配信方法。
4. 前記生成工程では、前記コンテンツデータの送信が要求され、配信を行う時点で前記ストリーミング情報を生成することを特徴とする請求項１乃至３のいずれか１項に記載のデータ配信方法。
5. コンテンツデータをメモリに格納する格納手段と、
   前記メモリに格納されたコンテンツデータのうち、配信対象のコンテンツデータの構造を解析する解析手段と、
   前記解析手段の解析結果により前記コンテンツデータに配信制御のための記述が含まれていないと判断された場合に、該解析手段の解析結果であるコンテンツデータの構造に基づいてストリーミング情報を生成する生成手段と、
   前記生成手段で生成されたストリーミング情報に基づいて前記コンテンツデータをネットワークに配信する配信手段とを備え、
   前記生成手段は、前記解析結果に基づいて、前記コンテンツデータが有するオブジェクトに関する記述を前記配信手段における配信プロトコルに適応した記述に変換することを特徴とする情報処理装置。
6. コンピュータに請求項１乃至４のいずれか１項に記載のデータ配信方法を実行させるためのプログラム。
7. 請求項１乃至４のいずれか１項に記載のデータ配信方法をコンピュータによって実行させるためのプログラムを格納したコンピュータ読み取り可能な記憶媒体。
   

Images