JP2005151128A - データ処理方法および装置 - Google Patents

Abstract

【課題】MP4あるいは類似のファイル形式で記述されたコンテンツデータを、該コンテンツデータが有する同期制御情報にしたがって正しく安全に再生可能とする。
【解決手段】マルチメディアコンテンツデータを処理するにおいて、再生対象のマルチメディアコンテンツの構造を解析し（Ｓ２）、マルチメディアコンテンツに含まれる同期制御項目の構成情報を、解析された当該マルチメディアコンテンツの構造に基づいて変換する（Ｓ３）。
【選択図】 図７

Description

本発明は、マルチメディアコンテンツデータの処理に好適なデータ処理方法および装置に関する。特に、同期制御情報を含む、MPEG-4ファイル形式（以下、MP4と記す）あるいは類似のファイル形式で記述されたマルチメディアコンテンツのデータ処理に好適なものである。

映像、音声の圧縮符号化技術の進歩にともない、さまざまな圧縮符号化形式が標準として規格化され、現在利用されている。しかし、実際にそれらのデータの再生などを行う際には、映像・音声を同期させて正しく再生するといったような制御を行うため、タイムスタンプなどの制御情報も規格として定められていなくてはならない。そのため、ISO（International Organization for Standardization）によって制定された標準符号化形式であるMPEG（Moving Picture Expert Group）では、映像、音声データの符号化に加え、それらの同期制御等を行うための制御情報および制御システムを「Systems」パートとして規格化している。

MPEG-4 Systems（ISO/IEC 14496-1。非特許文献１参照）では、MPEG-4コンテンツの再生を行う端末（再生端末）のアーキテクチャを図１のように定めている。再生端末は、図１のように複数のレイヤ２０１〜２０４から構成される。デリバリー・レイヤ（Delivery Layer）２０１では、物理的なデバイスあるいはネットワークからコンテンツ・データを取得し、非多重化を行い、タイムスタンプなどの同期情報を付加したSL-PDUと呼ばれるデータブロック２１０を作成し、これを同期レイヤ（Sync Layer）２０２に受け渡す。同期レイヤ２０２では、渡されたSL-PDUに含まれる同期情報をもとに同期制御を行う。以降、後続のレイヤ２０３、２０４によって圧縮解除、合成、描画処理が行われる。

このようなレイヤ構造によって、同期レイヤ２０２はコンテンツ・データがどのようなプロトコルを用いて、どのようなデータ形式で伝送されたかを意識することなく処理を行うことができる。また、同様にデリバリー・レイヤ２０１ではコンテンツ・データの内容がどのような符号化形式であるかといったことや、データの内容が正しいかどうかを意識せずに処理が行えるようになっている。

さらに、このアーキテクチャでは、どのような伝送形態やプロトコルであっても、同期レイヤ２０２への入力データは常にSL-PDUの形で渡すように規定しているため、同期レイヤ２０２とデリバリー・レイヤ２０１間は伝送手段を問わず透過的な処理が行える。この伝送透過の仕組みはDMIF（Delivery Multimedia Integration Framework）と呼ばれ、MPEG-4の１パート（ISO/IEC 14496-6。非特許文献２参照）として規格化されている。また、同期レイヤ２０２とデリバリー・レイヤ２０１間のやり取りを行うための抽象的なインターフェースのセットであるDAI（DMIF Application Interface）も同パートで定義されている。

SL-PDU２１０は、図２のようにSL_PacketHeader、SL_PacketPayloadの２つの部分から構成される。SL_PacketHeaderには同期レイヤ２０２が制御に用いるデータ項目のセットが格納され、SL_PacketPayloadには圧縮レイヤ２０３以降で処理される符号化データが格納される。

SL_PacketHeaderに格納される項目は一般には図３のように定義されているが、SL_PacketHeaderの項目レイアウトは必ずしも一定ではなく、SL_PacketHeaderの構成を定義するためのSLConfigDescriptorと呼ばれるデータの内容によって決定される。なお、この記法の解釈方法および各項目の意味については、詳細がISO/IEC 14496-1に記載されているため本明細書では説明を省略する。

SLConfigDescriptorは、図４で示すように、SL_PacketHeaderの各項目を使用するか否かを示す値が格納され、その内容によってSL_PacketHeaderの構成を知ることができる。そのため、デリバリー・レイヤ２０１は、同期レイヤ２０２が同期制御に必要な情報をSL_PacketHeaderから抽出できるよう、再生開始時あるいは任意のタイミングでSLConfigDescriptorを含むデータをDAIを介して同期レイヤ２０２に受け渡す必要がある。なお、SLConfigDescriptorの内容次第ではSL_PacketHeaderが存在しないSL-PDUもあり得る。

SL_PacketHeaderの構成のうち、代表的なものには番号が割り当てられており、SLConfigDescriptorの項目predefinedにその番号をセットすれば、SL_PacketHeaderの構成はその番号で示される構成と同じものを使用すると解釈される。従って、predefinedを用いればSLConfigDescriptorの内容の多くを省略することができる。図５は、predefinedに設定できる値およびそれに対応する構成を示したものである。例えば、predefinedの値0x02（Reserved for use in MP4 files）は、MPEG-4の標準ファイル形式として規格化（ISO/IEC 14496-14。非特許文献３参照）されているMP4ファイル形式で記述されたコンテンツを扱う場合の構成を定義したもので、SLConfigDescriptorのuseTimeStampsFlagにのみ１がセットされる。この場合、SL_PacketHeaderにはタイムスタンプのみがセットされることになる。
ISO/IEC 14496-1; "Information technology -- Coding of audio-visual objects -- Part 1: Systems"; ISO/IEC; 2003-02-20 ISO/IEC 14496-6; "Information technology -- Coding of audio-visual objects -- Part 6: Delivery Multimedia Integration Framework (DMIF)"; ISO/IEC; 2000-12-15 ISO/IEC 14496-14; "Information technology -- Coding of audio-visual objects -- Part 14: MP4 file format"; ISO/IEC; 2003-10-09 "Internet Streaming Media Alliance Implementation Specification Version 1.0"; Internet Streaming Media Alliance; 2001-8-28

MP4ファイルには、predefinedに0x02がセットされたSLConfigDescriptorのデータを記録することが義務付けられているため、MP4ファイルを再生する場合はどのようなコンテンツでも通常はSL_PacketHeaderのレイアウトは同じになる。しかしながら、MP4ファイルに記録されたSLConfigDescriptorのpredefinedの値が0x02であったとしても、実際のMP4ファイルの内容はpredefined=0x02の場合のSL_PacketHeaderの内容を反映したものであるという保証はない。

例を挙げれば、SL_PDUの処理優先度を示すdegradationPriorityは、MP4ファイルにはDegradationPriorityAtomのエントリとして記録することが可能である。しかし、predefined=0x02の時にはdegradationPriorityは使用されないようになっているため、同期レイヤ２０２では優先度の制御は行われなくなってしまう。このように、より適切な再生を行うための制御情報がMP4ファイル中に存在するにも関わらず、現状ではそれを同期レイヤ２０２以降で利用することができないことになる。このため、コンテンツの製作者が期待する再生制御が完全には実現されず、結果的にコンテンツの再生品位を劣化させる可能性があるといった課題がある。

また、逆にSL_PacketHeaderにセットされるべき情報がMP4ファイル中に存在しない場合もありえる。例えば、predefined=0x02の場合、SL_PacketHeaderのタイムスタンプを用いるようになっているが、タイムスタンプ情報を保持しているDecodingTimeToSampleAtomがMP4ファイル中に存在しないこともあり得なくはない。このケースでは、SL_PacketHeaderの構成とMP4ファイルの構成に矛盾が生じてしまう。この状態で処理を継続すると、同期レイヤ２０２では予測できないデータが受け渡されることになるため、安全に処理が実行されることは保証されない。結果として再生システムのクラッシュ等の事態を引き起こす可能性がある。

もっとも、TimeToSampleAtomはMP4ファイルには必須であると規定されているため、TimeToSampleAtomが存在しない場合は無条件にエラーとして処理を停止するといった解決手段もある。しかしこの解決策では、データ自体には矛盾がないにも関わらず、同期情報が欠落しているというだけで全くコンテンツの再生ができなくなるという課題を残してしまう。

以上述べたように、現状では、SL_ConfigDescriptorの内容と実際のMP4ファイルの内容とが一致しているという保証はないため、再生品位の劣化や処理の安全性低下といった課題がある。この課題は、MP4ファイル形式の規格としてpredefinedの値に固定値を使用することが強制されていることによるところが大きい。しかし、仮に任意の内容が設定されたSLConfigDescriptorをMP4ファイルに記録することが認められているとしても、それで不一致が生じないことを保証することにはならず、本質的な問題解決にはならない。

本発明はこのような上述した課題を解決するためものであり、MP4あるいは類似のファイル形式で記述されたコンテンツデータを、該コンテンツデータが有する同期制御情報にしたがって正しく安全に再生可能とすることを目的としている。

上記の目的を達成するための本発明によるデータ処理方法は、
マルチメディアコンテンツデータの処理方法であって、
再生対象のマルチメディアコンテンツの構造を解析する解析工程と、
前記マルチメディアコンテンツに含まれる同期制御項目の構成情報を、前記解析工程で解析された当該マルチメディアコンテンツの構造に基づいて変換する変換工程とを備える。

また、上記の目的を達成するための本発明によるデータ処理装置は以下の構成を備える。すなわち、
マルチメディアコンテンツデータの処理装置であって、
再生対象のマルチメディアコンテンツの構造を解析する解析手段と、
前記マルチメディアコンテンツに含まれる同期制御項目の構成情報を、前記解析手段で解析された当該マルチメディアコンテンツの構造に基づいて変換する変換手段とを備える。

本発明によれば、MP4あるいは類似のファイル形式で記述されたコンテンツデータを、本来の同期制御情報にしたがって正しく安全に再生することができる。

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

なお、上述の課題はコンテンツデータがMP4ファイル形式である場合を中心に解説したが、MP4に限らず類似のファイル形式およびアーキテクチャを用いるケースに対しても適用される。例えば、ISOではMPEG-4の後進規格としてMPEG-7（ISO/IEC 15938）、MPEG-21（ISO/IEC 20001）といった標準規格が制定あるいは検討されているが、MPEG-4と同様のファイル形式およびアーキテクチャが採用されるならば、これらの規格で用いられるファイル形式に対しても本発明の適用が可能であることは当業者には明らかであろう。

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

〈実施形態の概要〉
図６Ａは、実施形態によるマルチメディアコンテンツデータの再生処理を実現する情報処理装置の構成を示すブロック図である。図６Ａにおいて、ＣＰＵ１０１はＲＯＭ１０２あるいはＲＡＭ１０３に格納された制御プログラムに従って所定の処理を実行する。外部記憶装置１０４に格納された制御プログラムは、ＲＡＭ１０３へロードされ、ＣＰＵ１０１によって実行されることになる。なお、外部記憶装置１０４には再生処理の対象となるMP4ファイル形式で記述されたコンテンツデータを格納することができる。コンテンツデータの再生処理によって画像情報が再生された場合は、ディスプレイＩ／Ｆ１０５を介してディスプレイへ１１０出力され、表示される。また、コンテンツデータの再生処理によって音響情報が再生された場合は、音響Ｉ／Ｆ１０６を介して音響機器１１１へ出力され、再生される。

なお、再生の対象となるコンテンツデータは、ネットワーク（インターネット、ＬＡＮを含む）よりネットワークＩ／Ｆ１０７を介して取得することも可能であるし、ＣＤ（compact disc）やＤＶＤ（Digital Versatile Disc）等のメディア１１２に記録されたコンテンツデータをメディアドライブ１０８を介して取得することも可能である。また、上記各構成はバス１０９により相互に通信可能に接続され、各種機能が達成される。

ＣＰＵ１０１は、所定の制御プログラムを実行することにより、図１に示したような、コンテンツデータのための再生アーキテクチャを実現する。本実施形態では、デリバリー・レイヤ２０１において、再生すべきコンテンツデータに適したパケットヘッダー構成情報（SLConfigDescripter）を生成し、これを同期レイヤ２０２に提供する構成情報生成部が設けられている。図６Ｂは、本実施形態による構成情報生成部のモジュール構成例を説明する図である。

図６Ｂにおいて、ファイルデータ解析部１は、入力されたMP4あるいは類似のファイル形式のコンテンツデータの内部構造を解析する機能を有する。ファイルデータ解析部１への入力データはどのような伝送形態で入力されてもよい。例えば、外部記憶や外部媒体から何らかのネットワークや伝送路を介してデータの実体がファイルデータ解析部１に受け渡されてもよいし、ファイルパスなどデータの実体の位置を渡し、ファイルデータ解析部１がデータを取得するようになっていてもよい。

パケットヘッダー構成情報変換部２は、MP4あるいは類似のファイル形式のコンテンツデータ中に含まれるSLConfigDescriptorあるいはそれに相当するパケットヘッダー構成情報を、実際のコンテンツデータの内部構造に応じて変換し出力する機能を有する。パケットヘッダー構成情報変換部２が用いるコンテンツデータの内部構造は、ファイルデータ解析部１から取得あるいは参照する。変換結果として出力されたパケットヘッダー構成情報はデリバリー・レイヤ２０１で保持されると共に、同期レイヤ２０２に渡される。

デリバリー・レイヤ２０１においては、SL_PacketHeaderあるいはそれに類似する同期情報を含んだデータブロックを生成するのにパケットヘッダー構成情報が用いられる。また、同期レイヤ２０２においては、SL_PacketHeaderの内容に基づいて同期制御情報を解析する等の目的にパケットヘッダー構成情報が利用される。

また、変換結果のパケットヘッダー構成情報は、任意のモジュールに対して出力することができる。例えば、ファイルデータ解析部１からパケットヘッダー構成情報変換部２に対する処理を実行し、出力結果をファイルデータ解析部１に戻すようにすることも可能である。このようにすれば、利用者はファイルデータ解析部１に対して処理を要求することによってパケットヘッダー構成情報変換部２の存在を意識することなくパケットヘッダー構成情報が変換されたデータを得ることが可能となる。

本実施形態では、コンテンツデータに記録されているSLConfigDescriptorの内容を、コンテンツの内部構造に適合するようファイルデータ解析部１と連携しながら、パケットヘッダー構成情報変換部２が変換し、出力する。これによって、コンテンツデータの内容に一致する同期制御情報を生成することが可能になる。

なお、ファイルデータ解析部１およびパケットヘッダー構成情報変換部２はどのような配置で実装することも可能であるが、両方とも図１で示されるデリバリー・レイヤ２０１に論理的に配置されることが好ましい。その理由は次のとおりである。両者が異なるレイヤ、例えば、デリバリー・レイヤ２０１と同期レイヤ２０２に配置されるような場合は、ファイルデータの内部構造を参照するにはレイヤを超える操作が必要となる。ところが、レイヤ間にはDAIのような抽象的なインターフェースしか存在しないため、MP4などのデータ形式に固有の処理を行うにはインターフェースの独自拡張を行わなければならない。このことは、レイヤ構造による処理の抽象化や、DMIFによって提供される伝送手段に対する透過性による利点を損なってしまう。ゆえに、両者を異なるレイヤに配置するのは可能ではあるが、推奨はしない。

次に、本実施形態によるヘッダー構成情報変換部２の処理手順を説明する。図７は、パケットヘッダー構成情報の変換処理の手順を説明する図である。

まず、ステップＳ１において、再生対象のファイルデータに記録されているパケットヘッダー構成情報を変換する必要があるかをチェックする。例えば、コンテンツデータの形式（MP4か否か）と構成情報（SLConfigDescriptor）の内容に基づいてパケットヘッダー構成情報を変換する必要があるかを判定する。本実施形態では、パケットヘッダー構成情報の変換が必要となるケースとは、コンテンツデータがMP4ファイル形式である場合であるとする。ステップＳ１では、コンテンツデータの内容がこの条件と一致するか確認し、その結果、変換が必要な場合にのみパケットヘッダー構成情報変換部２を呼び出して後続の処理を実行する。

ステップＳ２において、パケットヘッダー構成情報変換部２は、パケットヘッダー構成情報の所定の項目に関連するファイルデータ中のデータ構造を参照する（パケットヘッダー構成情報がSLConfigDescriptorである場合の詳細例について、図８に示す各項目に関して後述する）。この処理を行うためにはファイルデータの内部構造が解析されていなければならない。したがって、前もって、あるいは必要になった時点でファイルデータ解析部１に対してデータ解析を要求する必要がある。

次に、ステップＳ３において、パケットヘッダー構成情報変換部２は、ステップＳ２で参照されたデータ構造の内容にしたがって、対応するパケットヘッダー構成情報の項目の内容を修正する。なお修正の具体例は後述する。修正された内容は、全ての項目に対する処理が終了するまでパケットヘッダー構成情報変換部２の内部に記憶される。

以上のステップＳ２及びステップＳ３の処理が、パケットヘッダー構成情報変換部２でファイルデータ中のパケットヘッダー構成情報の全項目に対して実行される。すなわち、ステップＳ４において、ステップＳ２、Ｓ３の処理がパケットヘッダー構成情報の全項目に対して実行されたか否かを判定し、全項目が処理されるまでステップＳ２とステップＳ３の処理を繰り返す。

全項目が処理されると、ステップＳ５に進み、パケットヘッダー構成情報変換部２は、上記ステップの実行によって得られた変換後のパケットヘッダー構成情報を出力する。

なお、出力されたパケットヘッダー構成情報の出力においては、その利用者の利用目的に適合する任意の形式で表現してもよい。例えば、出力されたパケットヘッダー構成情報をネットワークを介して外部モジュールに転送するような場合、各モジュール間の伝送プロトコルに適合する形式で表現されてもよい。

上記の手順により、本実施形態のデータ処理方法ではコンテンツデータの構造と一致する同期制御情報が得られるようになる。次に、より具体的な実施形態について、以下、説明する。

〈第１実施形態〉
第１実施形態では、処理対象のコンテンツ・データがMP4ファイル形式で記述されている場合に、ステップＳ２、Ｓ３で実行されるパケットヘッダー構成情報（SLConfigDescriptor）の変換処理の詳細を説明する。

パケットヘッダー構成情報変換部２は、図８に示す変換ルールを用いてSLConfigDescriptorの内容を変換する場合を説明する。図８において、列FieldはSLConfigDescriptorに含まれる項目を示す。列inはMP4ファイル形式データに含まれる変換前のSLConfigDescriptorの内容を示し、列outは変換後のSLConfigDescriptorの内容を示す。列inおよび列outに○で示される項目は、有効な制御項目としてSLConfigDescriptorに設定されることを表している。列inおよび列outにおいて無印の項目は、無効な制御項目であり、SLConfigDescriptorには設定されない。また、列out中の△は、本実施形態では有効な項目として説明されないが、理論的には有効な制御項目として扱うことが可能な項目を示す。列Commentは、該当する項目がどのような状態で、どのように設定されるかの説明である。本実施形態では、predefinedに0x02がセットされたSLConfigDescriptorが処理の対象となるので、変換前においてはuseTimeStampFlagのみが有効となっている（図５参照）。

引き続き、図８の各項目が、上記のステップＳ３においてどのようにしてSLConfigDescriptorに反映されるかを説明する。

まず、SLConfigDescriptorのpredefinedの値を0x00（Custom）に変更する。上述のように、SLConfigDescriptorのpredefinedの値はMP4ファイルデータから取得された時点では通常は0x02になっているので、本実施形態のように各項目を個別に設定する場合は、predefinedの値を0x00に変更しなければならない。

useAccessUnitStartFlag、useAccessUnitEndFlagは、ストリーミングなどでパケットを断片化する必要がある場合に用いられるが、この断片化のための情報は、通常ヒントトラックを用いてMP4ファイルに記述される。したがって、これらのフラグが使われるかどうかは、ヒントトラックの有無による。すなわち、パケットヘッダー構成情報変換部２は、処理対象のストリームに対するヒントトラックがMP4ファイルデータに存在する場合には、useAccessUnitStartFlag及びuseAccessUnitEndFlagに１を設定する。

また、メディア・トラックにSyncSampleAtomが存在する場合には、useRandomAccessPointFlagに１が、存在しない場合にはhasRandomAccessUnitsOnlyFlagに１が設定される。useRandomAccessPointFlagが１に設定されている場合は、SL_PacketHeaderには、そのSL-PDUがランダムアクセス可能かどうかを示すフラグがセットされる。したがって、パケットヘッダー構成情報変換部２は、MP4ファイルデータにSyncSampleAtomが存在するかどうかを確認し、useRandomAccessFlag及びhasRandomAccessUnitsOnlyFlagに適切な値を設定する。

useIdleFlag、usePaddingFlagは、MP4ファイル形式に対応するデータ構造が存在しないため、本実施形態では扱わない。

useTimeStampFlagは、DecodingTimeToSampleAtomの有無によって決定される。パケットヘッダー構成情報変換部２は、MP4ファイルデータにDecodingTimeToSampleAtomが存在するかどうかを確認し、存在する場合は１を、存在しなければ０を設定する。

timeStampResolutionには、処理対象のストリームに対応するトラックのtimescaleの値を用いる。したがって、パケットヘッダー構成情報変換部２は、MP4ファイルデータから該当するトラックのtimescaleを取得し、timeStampResolutionとして設定する。なお、timescaleは常に３２ビット長である。

OCRResolutionは、処理対象のストリームから参照されるOCRトラックのtimescaleの値を用いる。したがって、パケットヘッダー構成情報変換部２は、トラック参照情報から該当するOCRトラックを判断し、OCRトラックのtimescaleを取得し設定する。

durationFlag、およびtimeScale、accessUnitDuration、compositionUnitDurationを使用するには、サンプル単位のdurationを得るためにサンプル間のDTS、CTSの差分値を計算しなければならない。特に、サンプルはCTS順に並んでいるとは限らないため、実行時にcompositionUnitDurationを得るのは難しい。したがって、本実施形態ではこれらの項目は処理対象から除外している。ただし、サンプル単位のdurationを計算する処理が実装可能であれば、durationFlagを使用することは可能である。

timeStampLength、OCRlengthは、MP4ファイル形式のバージョンによって最大ビット長が変わる。そのため、パケットヘッダー構成情報変換部２は、MP4ファイル形式のバージョンを確認し、Version0であれば32を、Version1であれば64を設定する。なお、ここで示される値はビット長の上限値であり、実際のMP4ファイルデータでは最大ビット長に満たない値が使用されるかもしれないため、パケットヘッダー構成情報変換部２は実際に使用されている最大ビット数を取得、設定するようにしてもよい。

AU_Lengthには、現時点のMP4の規格でSampleSizeAtomのエントリサイズとして規定されている32をセットする。しかし、将来のバージョンでは、64ビット長の整数値を用いるための拡張や、あるいは圧縮形式オーディオなどのサイズの小さいサンプルを用いたストリームに対応するための拡張が予想されるため、設定値が変わる可能性がある。その場合は、規格に沿った値を設定するようルールを変更すればよい。

instantBitrateLengthは、MP4ファイルデータ中にはinstantBitrateに相当する項目は保持できないため、本実施形態では処理対象から除外している。ただし、instantBitrateを実行時に動的に計算する処理が実装されていれば、instantBitrateLengthを使用することは可能である。

degradationPriorityLengthは、DegradationPriorityAtomが存在する場合に使用される。SL_PacketHeaderには、そのSL-PDUに対応する DegradationPriorityAtomのエントリのpriority値が設定される。したがって、パケットヘッダー構成情報変換部２は、DegradationPriorityAtomのが存在するかどうかを確認し、適切な値（0又は16）を設定する。なお、degradationPriorityの最大ビット幅は１５ビットである。そのため、degradationPriorityLengthには15またはパディングビットを含む16のいずれかを設定することができる。どちらを使用するかは実装に依存する（図８では16とした）。

AU_seqNumLength、PacketSeqNumLengthは、主にストリーミング時にパケットロスや重複送信パケットを検出するために用いる。これらの情報は一般的にはヒントトラックに記述される。したがって、パケットヘッダー構成情報変換部２は、MP4ファイルデータ中に処理対象のストリームに対するヒントトラックが存在するか確認し、ヒントトラックが存在する場合は、AU_seqNumLength、PacketSeqNumLengthに、ヒントトラックのSample Entryから取得した各項目の値を設定する。

startDecodingTimeStamp、startCompositionTimeStampは常に0を設定する。これは、現行のMP4規格では、タイムスタンプの開始値は0であると規定されており、これらの値を保持できる領域がMP4ファイル形式中に定義されていないためである。

上述のような変換処理仕様を、図７のステップＳ３の処理に適用させることによって、パケットヘッダー構成情報変換部２はSLConfigDescriptorの変換を適切に行えるようになる。なお、上述のルールは現行のMP4ファイル形式の規格に基づいて決定されたものであるため、MP4ファイル形式に拡張が発生した場合や、他の類似のファイル形式に適用する場合は、各ファイル形式に応じて適切な変換ルールを定義しなければならないのは言うまでもない。

〈第２実施形態〉
第２実施形態では、上述のようにして変換されたSLConfigDescriptorをデリバリー・レイヤ２０１から同期レイヤ２０２に渡す方法について説明する。なお、MPEG-4 Systemsにおいては、デリバリー・レイヤ２０１から同期レイヤ２０２にSLConfigDescriptorを渡す方法は２種類ある。１つは再生開始時にInitialObjectDescriptorのデータの一部として渡すというものであり、もう１つは再生中の任意の時点でObjectDescriptorストリームのデータの一部として渡すという方法である。第２実施形態では前者の方法について説明し、後者の方法については第３実施形態で説明する。

SLConfigDescriptorがInitialObjectDescriptorの一部として同期レイヤ２０２に渡される処理は、通常はコンテンツデータの再生が開始された直後に一回のみ実行される。

図９は、InitialObjectDescriptorのデータ構造を示す図である。SLConfigDescriptorは図９に示すようにInitialObjectDescriptorに格納される。InitialObjectDescriptorには複数のSLConfigDescriptorが格納可能である。したがって、第２実施形態ではInitialObjectDescriptorからSLConfigDescriptorを順次抽出して処理を行う。

以下に、第２実施形態による処理手順を図１０Ａ及び図１０Ｂを用いて説明する。図１０Ａは第２実施形態による処理手順を説明するフローチャートであり、図１０Ｂは第２実施形態の処理の流れを説明する図である。

まず、ステップＳ１１において、ファイルデータ解析部１は、MP4ファイルデータ５１中に含まれるInitialObjectDescriptor５２のデータを解析し、SLConfigDescriptor５３のデータを抽出し、パケットヘッダー構成情報変換部２に提供する。InitialObjectDescriptor５２は、MP4ファイル形式の場合はObjectDescriptorAtomに保持されている。したがって、この処理を実行する前に、ファイルデータ解析部１は前もってMP4ファイルデータを解析し、InitialObjectDescriptor５２のデータを取得しておく。

次に、ステップＳ１２において、抽出されたSLConfigDescriptorデータ５３に対して、パケットヘッダー構成情報変換部２により、図７で説明したパケットヘッダー構成情報変換処理を実行する。出力結果はすべてのSLConfigDescriptorに対する処理が完了するまでデリバリー・レイヤ２０１に記憶しておく。

ステップＳ１３では、ステップＳ１１及びＳ１２の処理がすべてのSLConfigDescriptorに対して行われたかをチェックする。未処理のSLConfigDescriptorが存在する場合には、すべてのSLConfigDescriptorが処理されるまで上記ステップＳ１１、Ｓ１２の処理を繰り返す。すべてのSLConfigDescriptorの処理が完了したら、ステップＳ１４において、SLConfigDescriptor５３の内容をパケットヘッダー構成情報変換部２の出力結果（SLConfigDescriptor５３’）に置き換えて、InitialObjectDesciptorを再構築する。再構築されたInitialObjectDesciptorは同期レイヤ２０２に出力される。

〈第３実施形態〉
次に、再生中の任意の時点でObjectDescriptorストリームのデータの一部としてSLConfigDescriptorを同期レイヤ２０２に渡す場合について説明する。

図１１は、ObjectDescriptorストリームのデータ構造を示す図である。同期レイヤ２０２には、ObjectDescriptorストリームのデータは図２に示されるようなSL-PDU形式で渡される。すなわち、SLConfigDescriptorを含むデータの実体は、MP4の場合、SL-PDUのSL_PacketPayloadにセットされる。ObjectDescriptorストリームによってSLConfigDescriptorが渡される場合、SL_PacketPayloadの内容は、ObjectDescriptorUpdateコマンドを示すデータ列となる。ObjectDescriptorUpdateコマンドデータには、複数のSLConfigDescriptorデータを含むデータを格納することが出来る。SLConfigDescriptorは図１１のようにObjectDescriptorに格納される。また、ObjectDescriptorには複数のSLConfigDescriptorを格納することができる。したがって、第３実施形態ではObjectDescriptorストリーム中のSL-PDUからSLConfigDescriptorを順次抽出して処理を行う必要がある。

以下、第３実施形態の処理手順を図１２Ａ及び図１２Ｂを用いて説明する。まず、ステップＳ２１において、当該SL-PDUがSLConfigDescritporを含むか否か（変換処理の要否）を判定するために、処理対象のストリーム６１がObjectDescriptorストリーム（ODストリーム）であるかどうかを判断する。MP4ファイル形式の場合、処理対象のストリームの種類はHandlerReferenceAtom６２のhandler_type項目によって判定可能である。ObjectDescriptorストリームの場合、対応するHandlerReferenceAtomのhandler_typeは“odsm”となっている。処理対象のストリームがObjectDescriptorストリームでなければ、変換を行うべきSLConfigDescriptorは含まれないため、後続の処理はスキップする。

ObjectDescriptorストリームであれば、ステップＳ２２において、ストリームのSL-PDUをSL_PacketHeader６３とSL_PacketPayload６４に分解する。そして、ステップＳ２３において、SL_PacketPayload６４に格納されているコマンドデータからSLConfigDescriptor６５のデータを抽出する。ステップＳ２４において、抽出されたSLConfigDescriptorデータ６５はパケットヘッダー構成情報変換部２へ提供され、図７で説明したパケットヘッダー構成情報変換処理が実行され、変換されたSLConfigDescriptorデータ６５’が得られる。変換結果はすべてのSLConfigDescriptorに対する処理が完了するまで記憶しておく。

ステップＳ２５では、ステップＳ２３とステップＳ２４の処理がすべてのSLConfigDescriptorに対して行われたかをチェックし、未処理のSLConfigDescriptorが存在する場合には、すべてのSLConfigDescriptorが処理されるまでステップＳ２２、Ｓ２３の処理を繰り返す。すべてのSLConfigDescriptorの処理が完了したら、ステップＳ２６へ進み、SL_PacketPayload６４のSLConfigDescriptor６５の内容をパケットヘッダー構成情報変換部２の出力結果（SLConfigDescriptor６５’）に置き換え、SL-PDUを再構築する。

〈第４実施形態〉
第４実施形態では、パケットヘッダー構成情報変換処理を行った結果得られるSLConfigDescriptorの構成が、結果として変換を行う前のSLConfigDescriptorの構成と変わらない場合の処理について説明する。

例えば、predefinedを用いて既定の構成を用いる場合は、SLConfigDescriptorにはpredefinedのみを設定すればよいので、predefined を用いずに各項目の構成を個別に設定する場合と比較してSLConfigDescriptorのデータサイズを小さくすることが出来る。このことは、変換結果として出力されるパケットヘッダー構成情報およびそれに基づいて生成される同期制御情報が、低速の伝送路を介して他のモジュールに伝送されるような処理系や、あるいは利用可能なメモリなどのリソースが極めて限定されているため処理対象のデータ量を出来るだけ削減する必要があるような処理系に適用する際には有効となる。

第４実施形態の処理では、まず、MP4ファイルデータに含まれるSLConfigDescriptorデータの複製を、一時的に記憶しておく。なお、この際、SLConfigDescriptorにpredefinedが設定されていれば、それを各項目に展開して保持しておく（例えば、predefinedが0x01や0x02の場合は、図５に示すように展開されることになる）。そして、図７で示されるパケットヘッダー構成情報変換処理を実行し、出力結果として得られたSLConfigDescriptorデータと、最初に記憶されているSLConfigDescriptorデータが示す構成を比較する。その結果、両者の構成内容が同じである場合は、パケットヘッダー構成情報変換部２による出力結果のSLConfigDescriptorデータを破棄し、よりデータサイズが小さい最初に記憶したSLConfigDescriptorデータを利用する。

例えば、図１０Ａ（図１２Ａ）のフローチャートに上記処理を適用する場合、次のようにすればよい。すなわち、ステップＳ１１（Ｓ２３）では、抽出した（predefinedが設定されている場合はこれを展開して）SLConfigDescriptorを所定の記憶領域に保持しておく。そして、ステップＳ１４（Ｓ２６）の再構成処理において、変換後の各SLConfigDescriptorと上記所定の記憶領域に記憶された変換前の各SLConfigDescriptorを比較する。比較の結果、両者の構成内容が同等であれば、変換後のSLConfigDescriptorを破棄し、すなわちSLConfigDescriptorの再構成を行なわずに元のSLConfigDescriptorを用いるようにする。

このようにして、パケットヘッダー構成情報およびそれに基づいて生成される同期制御情報のデータサイズが不必要に増加することを抑制することが可能になる。

〈第５実施形態〉
第５実施形態では、上述の各実施形態の変換処理によって得られた変換後のSLConfigDescripterを含むInitialObjectDescriptorあるいはObjectDescriptorデータが、ネットワークを介して他の再生端末に伝送されるケースにおいて、当該伝送されるデータを端末間の通信手段に適合する形に変換する際の処理の例を説明する。

これまで述べてきた説明では、変換結果のデータはデリバリー・レイヤ２０１から同一再生端末の同期レイヤ２０２に渡されるものと想定して説明を行ってきた。これに対し、第５実施形態のケースでは、変換結果はデリバリー・レイヤ２０１から他の再生端末のデリバリー・レイヤ２０１に送出されることになる。このケースの典型的な実装例は、コンテンツサーバからクライアント端末にコンテンツデータをストリーミング配信するような再生システムである。

MP4コンテンツをストリーミング配信するための通信手段を規定するための仕様には、米Apple Computer社、米Philips社などの企業が参加している業界団体であるISMA（Internet Streaming Media Alliance）によって発行されている"Internet Streaming Media Alliance Implementation Specification"（以降"ISMA仕様"と表記する）といったものがある（詳しくは"Internet Streaming Media Alliance Implementation Specification Version 1.0"; Internet Streaming Media Alliance; 2001-8-28参照）。

ISMA仕様においては、InitialObjectDescriptorおよびObjectDescriptorは、RTSP（Real-Time Streaming Protocol）を用いて送信されるようになっている。データの実体は、図１３で示されるように、SDP（Session Description Protocol）で規定される形式で記述されたRTSPのヘッダ項目中、“a=mpeg4-iod:”で始まる行のデータとして記述される。この行のデータはURL（Uniform Resource Locator）として表され、URLの末尾には、二進データのテキスト符号化形式の一つであるBase64形式で符号化されたInitialObjectDescriptorをセットするように規定している。さらに、ObjectDescriptorストリームのデータも、InitialObjectDescriptor同様のURL形式で符号化され、InitialObjectDescriptorに埋め込まれるものとしている（ISMA仕様では、ObjectDescriptorストリームのデータはSL-PDUとしてではなく、SL_PacketPayloadの部分、すなわちObjectDescriptorデータのみが記録される）。

ISMA仕様で規定される形式での出力は、上記各実施形態の変換処理でSLConfigDescripterを変換したのち、SLConfigDescripterを含むInitialObjectDescriptorおよびObjectDescriptorデータを所定のURL形式に符号化し、SDP形式のRTSPヘッダとして整形し、RTSPを用いて送出するといった処理を行うことによって可能である。なお、上記のISMA仕様における符号化の詳細な処理手順については、周知の処理である上に発明の本質を超える範囲の処理でもあるため、説明を省略する。

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

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

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

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

MPEG-4 Systemsにおける再生端末のアーキテクチャを示す図である。 SL-PDUの構成を示す図である。 SL_PacketHeaderの項目定義を示す図である。 SLConfigDescriptorの項目定義を示す図である。 predefined項目の値に対応する設定値を示す図である。 実施形態による処理装置の構成を示す図である。 実施形態によるパケットヘッダー構成情報変換処理のためのモジュール構成例を示す図である。 実施形態による、パケットヘッダー構成情報変換処理を説明するフローチャートである。 実施形態によるパケットヘッダー構成情報変換処理で、各項目に対して適用される変換ルールを示す図である。 InitialObjectDescriptorの構成を示す図である。 第２実施形態による、InitialObjectDescriptorに含まれるSLConfigDescriptorの変換処理を説明するフローチャートである。 第２実施形態による、InitialObjectDescriptorに含まれるSLConfigDescriptorの変換処理の概要を示す図である。 ObjectDescriptorストリームのSL-PDUの構成を示す図である。 第３実施形態による、ObjectDescriptorストリームに含まれるSLConfigDescriptorの変換処理を説明するフローチャートである。 第３実施形態による、bjectDescriptorストリームに含まれるSLConfigDescriptorの変換処理の概要を示す図である。 ISMA仕様におけるInitialObjectDescriptorおよびObjectDescriptorの伝送形式の例を示す図である。

Claims (15)

1. マルチメディアコンテンツデータの処理方法であって、
   再生対象のマルチメディアコンテンツの構造を解析する解析工程と、
   前記マルチメディアコンテンツに含まれる同期制御項目の構成情報を、前記解析工程で解析された当該マルチメディアコンテンツの構造に基づいて変換する変換工程とを備えることを特徴とするデータ処理方法。
2. 前記解析工程で得られる前記マルチメディアコンテンツの構造における、コンテンツデータの形式と構成情報の内容に基づいて前記変換工程を実行するか否かを判定する判定工程を更に備えることを特徴とする請求項１に記載のデータ処理方法。
3. 前記マルチメディアコンテンツに含まれるデータから、一つ以上の構成情報を抽出する抽出工程を更に備え、
   前記変換工程は、前記抽出工程によって抽出された前記構成情報を変換することを特徴とする請求項１に記載のデータ処理方法。
4. 前記構成情報を一つ以上含む制御データストリームを判別する判別工程と、
   前記制御データストリームより構成情報を抽出する抽出工程とを更に備え、
   前記変換工程は、前記制御データに含まれる構成情報を変換することを特徴とする請求項１記載のデータ処理方法。
5. 前記変換工程による前記構成情報の変換結果が変換前の当該構成情報と同等であるか否かを判定する判定工程と、
   前記判定工程により同等であると判定された場合、変換前後の構成情報のうち、データサイズのより小さい方の構成情報を出力することを特徴とする請求項１記載のデータ処理方法。
6. 前記変換工程による変換後の構成情報を含むデータを、通信手段を介して外部装置に送信する送信工程を更に備えることを特徴とする請求項１に記載のデータ処理方法。
7. 前記送信工程は、前記構成情報を含むデータを、装置間の通信プロトコルで規定される形式に変換して送信することを特徴とする請求項６に記載のデータ処理方法。
8. マルチメディアコンテンツデータの処理装置であって、
   再生対象のマルチメディアコンテンツの構造を解析する解析手段と、
   前記マルチメディアコンテンツに含まれる同期制御項目の構成情報を、前記解析手段で解析された当該マルチメディアコンテンツの構造に基づいて変換する変換手段とを備えることを特徴とするデータ処理装置。
9. 前記解析手段で得られる前記マルチメディアコンテンツの構造における、コンテンツデータの形式と構成情報の内容に基づいて前記変換手段を実行するか否かを判定する判定手段を更に備えることを特徴とする請求項８に記載のデータ処理装置。
10. 前記マルチメディアコンテンツに含まれるデータから、一つ以上の構成情報を抽出する抽出手段を更に備え、
    前記変換手段は、前記抽出手段によって抽出された前記構成情報を変換することを特徴とする請求項８に記載のデータ処理装置。
11. 前記構成情報を一つ以上含む制御データストリームを判別する判別手段と、
    前記制御データストリームより構成情報を抽出する抽出手段とを更に備え、
    前記変換手段は、前記制御データに含まれる構成情報を変換することを特徴とする請求項８記載のデータ処理装置。
12. 前記変換手段による前記構成情報の変換結果が変換前の当該構成情報と同等であるか否かを判定する判定手段と、
    前記判定手段により同等であると判定された場合、変換前後の構成情報のうち、データサイズのより小さい方の構成情報を出力することを特徴とする請求項８記載のデータ処理装置。
13. 前記変換手段による変換後の構成情報を含むデータを、通信手段を介して外部装置に送信する送信手段を更に備えることを特徴とする請求項８に記載のデータ処理装置。
14. 請求項１乃至７のいずれかに記載のデータ処理方法をコンピュータによって実行させるための制御プログラム。
15. 請求項１乃至７のいずれかに記載のデータ処理方法をコンピュータによって実行させるための制御プログラムを格納する記憶媒体。

Images