JP2005275643A - コンテンツデータ処理装置及び方法 - Google Patents

Abstract

【課題】
動画や音声のようなコンテンツデータの取扱いは、ビットレートを保証する必要があるなど実装が難しいため、ハードウェアに依存した構成になるものが多く、システムの移植性が悪かった。
【解決手段】
レイヤ化されたコンテンツ処理アーキテクチャにより、システムの移植性を高くし、またアプリケーションプログラムも容易に開発可能とする。また装置の一部をＬＳＩ化した場合にはこれにも適用することが可能である。
【選択図】 図１

Description

本発明はマルチメディアデータの処理をする、ソフトウェア及びハードウェアアーキテクチャに関する。

近年、コンピュータで取り扱われるマルチメディアデータとして、動画、及び音声等が様々な用途で利用されている。例えば、テレビ放送等の動画をリアルタイムに動画用コーデックで変換してハードディスクに録画するハードディスクレコーダと呼ばれる機器や、DVD等の光ディスクにデジタルデータとして記録されている動画コンテンツデータをビデオディスプレイ装置に表示するプレイヤーなどが広く普及している。一般にこれらのコンテンツ処理では、コンテンツデータを指定されたビットレートで読み込み、一定時間内に処理を行わなければならない。また、これらの複雑なストリーム処理を実行するプログラムモジュールを容易に開発できることが、利用においては重要となる。このため、性能を保証しやすいOSのカーネルの中でコンテンツ処理を行うプログラムを実行する方式が存在する。

一般的なOSでは、カーネルの中で実行されるプログラムは、ユーザレベルで実行されるプログラムと比較して、優先的に処理が実行できる。このため、一定の時間内で処理を終了する必要があるコンテンツ処理プログラムはカーネルの中で実行される。例えば、特許文献１では、フィルタと呼ぶデータを処理するデバイスドライバを複数連結することでコンテンツ処理を行うことが可能である。フィルタはデバイスやデータ形式に特化されたモジュールで、それぞれが入出力や制御のためのインターフェースを持っており、特定のフィルタが処理したデータを他のフィルタに渡して行くことでデータを処理するものである。この方式は、フィルタがOSのカーネル部で動作するため、性能を保証し易く、フィルタの接続だけでプログラムを作成できるという特徴がある。

しかし、ストリーム処理プログラムをＯＳのカーネル内に実装することで、特定の実行環境、特にＯＳに依存した構成になる。

一方、特許文献２のようにハードウェアによるストリーム処理装置をレイヤ構成にすることで移植性を高めたものも存在する。しかしながら、これは各処理に個別のハードウェアを利用することから、装置自体が大型化、高価格化するという問題がある。

特開平10-283195号 特開平8-279963号

先に述べたように、従来の方法ではストリームを取り扱うための実装を、性能を保証しやすいドライバ、あるいはＯＳのカーネル部分で実装するものが殆どであった。これはＯＳやハードウェア構成（以下、本組み合わせをプラットフォームと呼ぶ）への依存性が高く、コンテンツを利用するプログラムは、異なったプラットフォームに対応することが難しい。

また、各プラットフォームは、それぞれ固有のコンテンツデータ処理手段を有することとなるため、コンテンツを利用するプログラムの開発は、ＯＳ、あるいはハードウェア構成毎に行う必要が生じ、開発工程の増大を招くという問題があった。

上記課題を解決すべく、本発明では、様々なプラットフォームに対応可能なコンテンツ処理手段およびそのコンテンツ処理アーキテクチャを提供する。

また、本発明ではコンテンツの処理を、コンテンツ処理に必要な機能を持つレイヤの組み合わせにより実現する。

本発明によれば、コンテンツ処理プログラムを異なったプラットフォームに移行する場合に、コンテンツ処理プログラムを殆ど変更することなく動作させることが可能となり、開発の工数を削減することが可能となる。また、コンテンツデータを利用するプログラム開発の容易化を実現可能である。

以下に、本発明の実施の形態を説明する。システムアーキテクチャは、まず、ハードウェアとのインターフェースを提供するドライバ部等を有するOS、各OS毎に異なる機能（例えば、システムコールやデバイスドライバへのアクセス方法等のプラットフォームによって異なる機能）を共通化したインターフェースとして提供されるレイヤであるシステムインターフェース部、その上部にコンテンツデータの処理やデータソースからのデータの取得処理などを行うコンテンツ処理部、取り扱うコンテンツ向けのデータ処理を提供するコンテンツ管理部、さらにこれらのレイヤで提供される機能を利用するアプリケーションプログラムで構成される。

この構造では、レイヤの間には上下のレイヤでデータ、イベント等をやり取りするためのインターフェースが規定される。例えば、システムインターフェース部はコンテンツの処理に必要なＯＳの機能、例えばメモリ管理や、ディスクのアクセス、タスクの生成などのシステムコールを共通化して上位のレイヤに提供する。これによりシステムインターフェース部よりも上位のレイヤは、プラットフォームに依存しない実装になる。ここで、共通化とは、上位のプログラムレイヤから命令に基づき、下位のプログラムレイヤ側で、上記命令を予め定義された処理手順で実行させることをいう。

コンテンツ処理部はシステムインターフェース部が提供する機能を利用してコンテンツデータの処理を行う。このコンテンツ処理におけるデータ処理パターンはコンテンツ管理部が管理しており、コンテンツ管理部はアプリケーションプログラムに対するインターフェースを提供する。アプリケーションプログラムからは、上記インターフェースを介してデータ処理パターンを指定することでコンテンツ処理のデータパスがコンテンツ処理部に構築される。コンテンツ処理のデータパスとは、対象となるコンテンツを処理するのに必要な機能モジュールを指定することで作られた、処理されるコンテンツデータの流路である。後はユーザが指示するタイミングでコンテンツ処理の開始、終了をアプリケーションプログラムからコンテンツ管理部を経由して指示することで制御が可能である。

また、このようにして作成されたアプリケーションプログラムは、異なったプラットフォームにおいても、本発明で提案するコンテンツ処理アーキテクチャに準じたコンテンツ処理系が実装されていれば、必要最小限の変更のみで実行することが可能である。

また、当該コンテンツ処理アーキテクチャはハードウェアの一部あるいは全てがLSI化された場合にも適用でき、この場合にもアプリケーションプログラムの変更をほとんど行うことなく利用できる。

図１に本実施例の構成を示した。本実施例は図のようなレイヤ構造を取る。このレイヤは下位から、ドライバ部（５０）、システム機能提供部（４０）、システムインターフェース部（２０）、コンテンツ処理部（１０）、コンテンツ管理部（３０）、およびアプリケーションプログラム（８０）からなる。ドライバ部（５０）はプラットフォームに存在するハードウェア、例えば、ハードディスク装置、コーデック処理装置、またはネットワークインターフェース等の装置に対応してアクセスするためのそれぞれのデバイスドライバを管理するレイヤである。システム機能提供部（４０）はOS（５）の提供する機能、例えばファイルシステム（４１）、ネットワークのプロトコルスタック（４２）等を提供するレイヤである。一般的なOSでは、ドライバ部およびシステム機能提供部はOSに備えられていることが多いが、これらのレイヤがOSに存在しない場合は本実施例のアーキテクチャを利用するために新たに追加しても良いし、ドライバ部（５０）とシステム機能提供部（４０）が１つのレイヤとして実現されていても良い。ここで、処理対象となるコンテンツデータは、ストリームデータ等がある。ストリームデータとは、シーケンシャルにアクセスされるデータである。

システムインターフェース部（２０）は、OS（５）の提供する機能や、各種のデバイスドライバ（ＨＤＤ用ドライバ、ＮＩＣ用ドライバ等）を通じてデバイスにアクセスするデバイスアクセス機能を共通化して、プラットフォームに依存しない方式でデバイスにアクセスするインターフェースを提供する。つまり、プラットフォームが異なっても、例えばＨＤＤ装置やネットワークにアクセスする方法は基本的には同じで、例えば、ファイルの読込には、読込むファイル名と、読込モード、及び読込位置と長さを指定する機能を提供する。これらの手順、インターフェースはプラットフォーム毎にまちまちなので、これらを使ったプログラムを、異なったプラットフォームに移行する際には変更が必要となる。一方、プラットフォームによって異なるインターフェースや手順をシステムインターフェース部（２０）で吸収し上位のレイヤに提供する。この他にも例えば、複数のアプリケーションプログラム（８０）が相互にデータを交換する場合もこのシステムインターフェース部（２０）が提供する機能を利用すると、プラットフォーム非依存のプログラムとなる。システムインターフェース（２０）で提供する機能はプラットフォームが提供する機能を共通化することであり、データの変更はコンテンツ処理部（１０）中のデータアクセス部（１２）で行う。その処理詳細については図１３を用いて後に説明する。

コンテンツ処理部（１０）には、システムインターフェース部（２０）を通じてドライバ部（５０）とのデータ交換を行うデータアクセス部（１２）と、データを処理するデータ処理部（１１）を備える。

データ処理部（１１）はデータアクセス部（１２）から受け取ったデータを、予め定めた処理手順に従った処理を行い、再びデータアクセス部（１２）に出力する。例えば、アプリケーションプログラムから指定された指示が、HDDに格納されたデータをネットワークに接続された他の機器への転送命令であれば、データアクセス部（１２）がハードディスクから読んだデータに、データ処理部（１１）で適切なヘッダを付けて、データアクセス部（１２）を通じて、ネットワーク出力するなどである。例えばUDPでデータを送信する場合、パケットが消失することや、送信順序と到着順序が異なってしまう可能性がある。これを検出するためにデータに一連の番号を持つヘッダを付けることが考えられる。このように適切なヘッダとは、コンテンツデータをデバイスで正しく処理、あるいは正しく送受信するためにデータに付加されるデータのことである。この他ネットワーク以外のデバイスからの入出力についても同様にデバイスに必要なヘッダを追加、削除する事が考えられる。これは例えば、正常に転送が行えたかどうかをチェックするためのチェックサムなどが考えられる。なお、データアクセス部（１２）及びデータ処理部（１１）で取り扱ったコンテンツデータはコンテンツ管理部（３０）より上位のレイヤには出力されない。

コンテンツ管理部（３０）は、コンテンツ処理部（１０）に備えられた制御インターフェースを使用してコンテンツ処理部（１０）を制御する。また、コンテンツ管理部（３０）は、本アーキテクチャが適用されている機器で取り扱えるリソースをリソース管理テーブル（３００）で管理している。ここでリソースとは、ＣＰＵ、メモリ、利用可能な装置等、またその装置で利用できる帯域等コンテンツ処理をする際に必要となるハードウェア資源を指す。該リソース管理テーブルについては、図１０、図１１を用い後述する。本実施例では、コンテンツ管理部（３０）はアプリケーションプログラム（８０）がコンテンツ処理を容易に実行することが出来るように、要求された処理が実行可能かどうかの判断を行った上で、コンテンツ処理部（１０）に処理を依頼する。コンテンツ管理部（３０）が提供する機能は、例えば、HDD中に存在するファイルのファイル名を指定して、そのファイルの内容を、指定したIPアドレスのネットワーク機器の、指定したポート番号へ、指定したビットレートでの送信をコンテンツ処理部（１０）に指示する等である。これにより、アプリケーションプログラム（８０）は、転送元機器と処理対象データ名と転送先機器を指定すれば、指定した機器への具体的なアクセス手法、データの取扱い方法等を知らなくても、目的のデータの転送が行える。例えば、ハードディスクから得たデータをネットワークに転送する場合、ネットワークから出力されるデータは不正な視聴を防止するために暗号化する必要があるが、どの暗号処理をどこで行うかをアプリケーションが認識しなくてもデータの転送を行うことができる。

また、該プラットフォームで取り扱えるコンテンツのリストをアプリケーションプログラム（８０）に提供し、ハードウェアの性能を越えた処理の要求がアプリケーションプログラム（８０）からあった場合にこれを拒絶する機能を持つ。この機能の詳細については、図１０、図１１を用いて後述する。

ここで、図５を用いて、アプリケーションプログラム（８０）からコンテンツ処理部（１０）にコンテンツ処理を要求して、これが終了するまでの処理を説明する。

最初に要求されたコンテンツ処理が実行可能であるかを、コンテンツ管理部（３０）が判断する（ステップ１０００）。判断の方法については、図１０、図１１を使用して後述する。利用が可能であれば、そのコンテンツ処理を行うのに必要なデータパスの設定を行う（ステップ１０１０）。これは例えば、ハードディスクから光ディスク装置を使ったコピーを行う場合に、データをどのように流すかの最適なデータパスを、予めコンテンツ管理部（３０）が保有しているパターンと利用できるリソースから決定する。次にデータの転送開始処理を行う（ステップ１０３０）。これによりコンテンツデータがステップ１０１０で設定したデータバスを経由して転送される（ステップ１０４０）。これをコンテンツデータが終了するか、ユーザが停止するまで行う（ステップ１０５０）。パターンについては、図１４を用いて後述する。

例えば、アプリケーションプログラム（８０）からコンテンツ管理部（１０）に対して、ハードディスク（１０３）から読み出したデータをネットワークアダプタ（１０４）に送出する命令が送信された場合の処理は次のようになる。最初に、アプリケーションプログラムから要求された処理が実行可能なコンテンツ処理かを判断する。この場合はハードディスクやネットワークアダプタが備わっており、その時点で利用できるかを判定する（詳細後述）。可能であると判断した場合は、ハードディスクからネットワークアダプタへコンテンツを流すための、データパスを設定する。転送の開始をアプリケーションプログラムが指示すると、データの転送がデータパスを通じて行われる。ここから、送信するコンテンツのファイルの終端まで送信した場合や、アプリケーションプログラムからの処理中止の指示が来るまで処理を続ける。

このデータ転送において、コンテンツデータはアプリケーションプログラム（８０）には渡されず、処理はコンテンツ処理部（１０）データアクセス部（１１）で行われる。その他の、コンテンツデータの停止、一時停止、復帰、前方早送り、及び後方送り等の操作も同様に行われる。

図１０のリソース管理テーブルと、図１１の処理フローを用いてリソース管理テーブル（３００）を用いて処理可能な要求か、不可能な要求かを判断する方法について説明する。該リソース管理テーブル（３００）では、利用できるデバイス（３０１）、そのデバイスの最大能力（３０２）、現在の利用量（３０３）、及び備考（３０４）を持つ。例えば、リソース管理テーブルの内容が図１０のように記述されていた場合、アプリケーションプログラム（８０）から、２０Ｍｂｐｓのビットレートで、ハードディスクからネットワークへの転送を行う要求が来た場合、最初に、必要なリソースを要求から抽出する（ステップ１２００）。この場合はハードディスクとネットワークのリソースを利用すると判断する。次にハードディスクの現在使用量（３０３）にさらに２０Ｍｂｐｓのコンテンツ処理を追加しても問題ないかを判断する（ステップ１２１０）。この場合最大能力（３０２）である１００Ｍｂｐｓに達さないので、処理が行えると判断する。次に、ネットワークについても同様に判断し（ステップ１２２０）、ネットワークの最大能力である４０Ｍｂｐｓを超えないので処理が可能と判断し（ステップ１２３０）、リソース管理テーブルを更新して（ステップ１２４０）終了する。他に、例えば、ハードディスクから光ディスクへの書込が要求された場合は、該プラットフォームで利用できる光ディスクは読込のみをサポートしているので、処理不可能と判断する（ステップ１２５０）。

次に、図２を用いて、本実施例を実行し得るハードウェア構成について説明する。本実施例はＣＰＵ（１００）、ＲＡＭ（１０１）、ＲＯＭ（１０２）、ハードディスク（１０３）、ネットワークアダプタ（１０４）、チューナ（１０５）、光ディスク装置（１０６）、ディスプレイ（１０７）、シリアルインターフェース（１０８）、コーデック処理手段（１０９）、操作手段（１１２）および暗号処理手段（１１０）がバス（１１１）で接続されている。これらは一般的なコンピュータやハードディスクレコーダの構成とほぼ同じである。ネットワークアダプタ（１０４）は例えばイーサネット（登録商標）のような有線のネットワーク、あるいは無線のネットワークなどが考えられる。チューナ（１０５）は、地上波、放送衛星あるいは通信衛星からの放送電波を受信して、コンピュータで取り扱えるデータに変換する機器である。これも様々な放送に対応するチューナが複数存在しても良い。光ディスク装置（１０６）はCD(Compact Disc)、DVD(Digital Versatile Disk)、AOD(Advanced Optical Disc)、あるいはBlu-Ray等の記憶媒体読み取り、及び書き込み装置である。ディスプレイ（１０７）はブラウン管、液晶ディスプレイ、プラズマディスプレイ、及び有機ＥＬディスプレイなどが考えられる。ディスプレイを接続するためのインターフェースを介してディスプレイを接続しても良い。

シリアルインターフェース（１０８）は例えばRS-232C、USB(Universal Serial Bus)あるいは、IEEE1394等のシリアル転送によってデータを転送するインターフェースが考えられる。コーデック処理手段（１０９）は、コンテンツデータを、特定の動画フォーマット、例えばMPEG2やMPEG4等の変換、あるいは、特定の動画フォーマットから映像情報、及び音声情報を取得する処理を行う手段である。この装置の機能はソフトウェアで実装することも可能である。暗号処理手段（１１０）はコンテンツデータに暗号化が施されている場合にこれを解除する場合や、逆に暗号化を施す場合の処理を行う。これもソフトウェアで実装することが可能である。バス（１１１）は汎用的なバスや、ＣＰＵや周辺チップに特化したローカルバスが考えられる。汎用バスとしては例えばＰＣＩ(Peripheral Components Interconnect)バスが考えられる。またバスブリッジで、異なったバスを結合して利用することも考えられる。操作手段（１１２）は例えばリモコンやキーボードなどの使用者が装置を制御するためのものである。これまでに述べた本実施例を構成する装置、手段は必要に応じて複数備えることが可能であり、また、ＣＰＵ、ＲＡＭ、およびバス以外は必要に応じて実装されればよい。また、上記アプリケーションプログラムや各レイヤーで必要とされるソフトウェアは、メモリにロードされCPUにより実行されることで実現される。

次に、図１２のフローチャートを使用して、図２に示す構成のハードウェアにおいて、図１で示すアーキテクチャを持つソフトウェアを利用して、ネットワークアダプタ（１０４）から放送を受信して、ディスプレイ（１０７）に映像を出力するまでの処理を説明する。

最初にアプリケーションプログラム（８０）から、コンテンツ管理部（３０）に対して「ネットワークからの放送をディスプレイに表示する」ことを要求する（ステップ１４００）。コンテンツ管理部（３０）では、この要求に基づき、要求に必要な処理を決定し、リソース管理テーブルを参照して、必要なデバイスの抽出を行い、これらが利用できるかを判断する（ステップ１４１０）。この判断の方法については、図１０、図１１を用いて前述した通りであり、詳しくは、図１４、１５、１６を用いて後述する。

この処理において抽出されるデバイスは、ネットワークアダプタ（１０４）、コーデック処理手段（１０９）及びディスプレイ（１０７）である。利用できると判断した場合は、次にコンテンツ管理部（３０）は、コンテンツ処理部（１０）に、ネットワークアダプタ（１０４）からの入力データを、コーデック処理手段（１０９）に入力して、この出力をディスプレイ（１０７）に出力するよう要求する（ステップ１４２０）。コンテンツ処理部（１０）では、要求されたデバイスからデータの入出力が可能なようにデータアクセス部（１２）を設定し（ステップ１４３０）、これで得たデータを適切に処理するようにデータ処理部を設定する（ステップ１４４０）。この処理の詳細については、図１３を用いて後述する。この処理が終了した後、アプリケーションプログラム（８０）から、再生の要求をコンテンツ管理部（３０）に出すと（ステップ１４５０）、コンテンツ管理部（３０）から、コンテンツ処理部（１０）に再生の要求が発生し（ステップ１４６０）、ネットワークアダプタ（１０４）から読みだしたデータがコンテンツ処理部（１０）に読み込まれ、次に、コーデック処理手段（１０９）に入力され、この出力がディスプレイ（１０７）に入力されることで映像を再生可能である。この場合、映像データはコンテンツ処理部（１０）より上のレイヤには出力されない。再生が終了したり、エラーが発生した場合は、コンテンツ処理部（１０）から、コンテンツ管理部（３０）にイベントが送られる（ステップ１４７０）。このイベントは、コンテンツ管理部（３０）からアプリケーションプログラム（８０）に渡される（ステップ１８７０）。再生の他、再生の停止、一時停止、早送り、あるいは巻き戻しのような処理についてもステップ１４５０からステップ１４８０の処理で実現可能である。

図１３を用いてコンテンツ処理部（１０）のデータ処理部（１１）とデータアクセス部（１２）の初期設定手順（ステップ１４３０，１４４０）と、データの変換処理について説明する。図１３はコンテンツ処理部（１０）、システムインターフェース部（２０）、及びドライバ部（５０）の詳細を示したものである。データアクセス部（１２）にはデバイスＡ（９７）用のデータアクセス処理（１２１）、（１２２）及び、デバイスＢ（９８）用のデータアクセス処理（１２３）が関数などのソフトウェアモジュールとして存在する。例えば、デバイスAが、ネットワークアダプタの場合、データアクセス処理Aには、ＴＣＰを用いた通信を実現するソフトウェアが格納されている。この説明では、デバイスをＡ，Ｂの２種類としたが、この他複数のデバイスに対するデータアクセス処理が存在しても良いことは言うまでもない。このデータアクセス処理Ａ１（１２１）とアクセス処理Ａ２（１２２）は同じデバイスドライバＡ（５７）を通じて、デバイスＡ（９７）とのデータの交換を行う。データアクセス処理Ａ１（１２１）とデータアクセス処理Ａ２（１２２）のように複数のデータアクセス処理が存在するのは、例えば広くネットワークで用いられているＴＣＰ(Transmission Control Protocol)とＵＤＰ(User Diagram Protocol)のように、同じデバイスを用いてデータを転送する場合でも複数の手順が存在する場合にそれぞれに対応したデータアクセス処理が必要となるからである。また入力、出力でもそれぞれ別のデータアクセス処理が必要になることも考えられる。

図１２におけるステップ１４３０での処理は、コンテンツ処理に必要なデバイスと、それに必要となるデータアクセス処理を決定し、その初期化を行う処理となる。例えば図１３に示した例では、デバイスＡ（９７）に対するデータアクセス処理はデータアクセス処理Ａ１（１２１）に、デバイスＢ（９８）に対するデータアクセス処理はデータアクセス処理Ｂ（１２３）を割り当てる。本実施例においては、デバイスＡはネットワークアダプタであるため、データアクセス処理Ａ１は、ソケットを用いてＴＣＰで送られてくるデータ受信を実現する処理となり、デバイスＢはディスプレイであるため、データアクセス処理Ｂ１は、ディスプレイドライバへのデータ転送を実現する処理となる。

次に、データ処理部（１１）にはデータ処理１（１１１）、データ処理２（１１２）およびデータ処理３（１１３）が関数等のプログラムモジュールとして存在する。これらのデータ処理はデータの変換処理を行うモジュールである。処理の例としては例えば、データのフォーマット変換、ヘッダの付加・削除、データの圧縮・解凍、あるいは暗号化等の処理が考えられる。本実施例においては、入力したデータが、ＭＰＥＧ符号化され、ＤＥＳ暗号され、ＴＣＰ／ＩＰのパケットで入力されたデータの場合、データ処理１でヘッダが削除され、データ処理２で暗号が復号化され、データ処理３でMPEG復号化がされることとなる。なお、このデータ処理モジュールの連結順序などの決定はコンテンツ管理部が行う。コンテンツ管理部は要求されたコンテンツ処理にどのデータ処理モジュールをどのように接続するかを判断し、この設定をコンテンツ処理部で行う。この処理の詳細については図１４、１５、１６を使用して後述する。

さらに、各データ処理はデータの入力と出力を行うためのインターフェースを持ち、これを利用して他のデータ処理モジュールやデータアクセス処理モジュールとデータを交換することが可能である。処理するデータはデータアクセスモジュールから入力、あるいは出力してもよい。例えば、本実施例において、入力データが暗号化されていなかった場合は、データ処理２が終了した後、処理後のデータがデータアクセス処理Ｂに出力される。したがって、該処理は、デバイスからのデータの取得、あるいはデバイスへのデータの出力に対応する。またデータ処理モジュール間の入出力についても１対１のデータ交換には限定せず、多対多、１対多あるいは多対１のパターンが考えられる。これは、例えば、１対多のパターンとしては、取得したコンテンツデータを録画しながら同時に再生する場合が該当し、多対１のパターンとしては、音声と映像が別々のコンテンツデータとして存在し、これを１つのコンテンツとしてファイルに記録するような処理を行う場合が該当する。ステップ１４４０の処理は、目的とするコンテンツ処理に必要なデータ処理を行うデータ処理モジュールを初期化して連結するものである。

図１４は、コンテンツ管理部において、アプリケーションプログラムから要求されたコンテンツを処理するための、コンテンツ処理におけるデータ処理フローを記したテーブル（２００）と、その構成の例である。このテーブルにはアプリケーションプログラムからの要求パターン（２１０）と適用するデータパスのパターン（２２０）の２つの列がある。例えば、アプリケーションプログラムから「チューナからの入力をディスプレイに表示」するように要求を受けた場合は、その要求に合った適用するデータパスのパターンを得る。これにより、チューナからの入力を「チューナアクセス処理」アクセス処理モジュールで読み、これを「フォーマット変換」データ処理モジュールで変換し、「ディスプレイアクセス処理」アクセス処理モジュールでディスプレイに出力すれば良いことが判る。これによりステップ１４１０での処理でコンテンツ処理に必要なデバイスを抽出することが可能になる。また、例えばチューナからの入力をディスプレイに出力する場合、あるチャンネルではデータに暗号化がなされているが、その他のチャンネルでは暗号化されていないことも考えられる。この場合は（２１０）に該パターンを登録、例えば「チューナからの入力（１〜４チャンネル）をディスプレイに表示」として、該要求パターンに対応するデータパスのパターンを（２２０）に登録することで対応することが可能である。

図１５は、コンテンツ管理部において、該実装において利用可能なデータアクセスモジュールのテーブル（３００）とその構成の例である。このテーブルには利用可能なアクセスモジュールの識別子（３１０）、入力用インターフェース・パラメタ（３２０）、及び出力用インターフェース・パラメタ（３３０）からなる。コンテンツ管理部は要求されたコンテンツ処理に必要なデータアクセスモジュールを前記処理によって決定した後、該テーブルを利用して必要なデータアクセスモジュールを得る。例えば、ハードディスクアクセス処理モジュールに対して出力を行う場合は３３１に記されたモジュールを、３３２で記されたパラメタで呼び出せばよく、ＵＤＰネットワークアクセス処理モジュールに対して出力を行う場合は３３３に示されたモジュールを、３３４で示されたパラメタで呼び出せばよい。

図１６は、コンテンツ管理部において、該実装において利用可能なデータ処理モジュールのテーブル（４００）とその構成の例である。このテーブルには利用可能なデータ処理モジュールの識別子（４１０）、入力インターフェース・パラメタ（４２０）及び、出力用インターフェース・パラメタ（４３０）からなる。コンテンツ管理部は要求されたコンテンツ処理に必要なデータ処理モジュールを前記処理によって決定した後、該テーブルを利用して必要なデータ処理モジュールを得る。例えば、暗号化処理を行うモジュールを得る場合は、４２１で記されたモジュールを、４２２で記されたパラメタで呼び出せよい。この場合、暗号化方式が複数ある場合には、各暗号化方式毎に、暗号化処理モジュールが備えられている。

このように、コンテンツ管理部ではアプリケーションプログラムから要求されたコンテンツ処理に適したデータアクセスモジュール、データ処理モジュールを選択して、必要な処理のパスを設定することが可能である。

また、コンテンツデータをどのように復号あるいは符号化すれば良いかはそのコンテンツの提供方式、あるいは記録時に決められる。例えばデジタル放送ではコンテンツがどの方式で符号化され、どのような暗号化がかかっているか等が予め公開されている。図１４で示した要求パターン（２１０）を予めそれらの情報を基に構築することで、アプリケーションはどのような暗号化、符号化がなされているかを知る必要が無く、ストリーム制御部は要求パターン（２１０）が与えられるだけで、必要なデータアクセスモジュールとデータ処理モジュールを正しく連結することが可能である。

モジュールの連結とは、処理するコンテンツデータがモジュール間で受け渡されることをいう。例えばデータアクセスモジュールがデバイスから読み出したコンテンツデータをデータ処理モジュールに渡して処理する場合は、読み込んだデータが２つのモジュールで送受信できれば良い。この方法としては例えば、データを記録したバッファメモリのアドレスを、パラメタとして関数呼び出しをしても良いし、該モジュールが入力用のキューを持ち、該キューにデータを投入する方法でも良いし、共有メモリを利用することも考えられるし、ソケットなどを利用してデータ交換することも考えられる。

このようなデータの流れ道、即ちデータパスを設定することで、コンテンツ処理の準備が整う。このデータパスにおいて、データの入り口、即ち、データを入力するデバイスのデータアクセス処理の処理を開始するとデバイスからデータが得られ、これがデータ処理モジュールに渡り、データパスに沿ってデータが処理されて、最終的にはデータの出口、すなわちデータを出力するデータアクセス処理に渡され、デバイスにデータが出力される。デバイスアクセス処理については一部プラットフォームによって処理が異なることが考えられる。これは例えば、一般的なデバイスであっても、プラットフォームが異なると入出力データが異なること等である。その場合は、これらの差異を取り除きデータを共通化する処理をデータアクセス処理で行うことも考えられる。このようにすることでデータアクセス部（１２）より上位のレイヤで取り扱うデータはプラットフォームからは完全に非依存になる。例えば、文字コード等のようなプラットフォームにより利用される形式が異なるものは、例えばデータアクセス部でより標準的なUnicode等の文字コードに変換するような場合である。

図３は図２で示した装置のうち一部にＬＳＩを利用した場合の構成を示す。
この図のＬＳＩ（１２０）は、ＨＤＤ（１２４）、チューナ（１２５）、ディスプレイ（１２６）、及びコーデック処理手段（１２７）らの機能手段をバス（１２８）で結合し、Ｓｕｂ−ＣＰＵ（１２１）、ＲＡＭ（１２２）、ＲＯＭ（１２３）及びデータ交換手段（１２９）を追加した構成である。このようなＬＳＩは、ＳｏＣ(System on chip)と呼ばれている。このＬＳＩ（１２０）をＣＰＵ（１００）、ＲＡＭ（１０１）、ＲＯＭ（１０２）、ネットワークアダプタ（１０４）、光ディスク装置（１０６）、シリアルインターフェース（１０８）、及び暗号処理手段（１１０）と共にバス（１１１）で接続することで、図２で示したハード構成と同じ機能を持たせることが可能となる。図３では、上記に説明したように機器をＬＳＩに搭載した構成を示したが、装置の配置はこの例に限定されない。例えば、ＬＳＩ（１２０）側にはＨＤＤ（１２４）が無く、その代わりに主ＣＰＵ（１）のバス（１１１）にＨＤＤ（１０３）が存在しても良いし、両者をともに実装した構成も考えられる。

この例では、ＬＳＩ（１２０）に備えられた装置と同じ装置をＬＳＩ外部には備えていないが、例えばチューナをＬＳＩ（１２０）内に持ち、外部にもチューナを備えるなど、同等な装置を２つ以上備えても良い。ＣＰＵ（１００）とＳｕｂ−ＣＰＵ（１２１）との通信にはデータ交換手段（１２９）を利用する。この実装はＬＳＩ（１２０）やシステムの構成によって多様な方法が考えられる。例えば、簡単な方法としてFIFO(First In First Out)方式のバッファを利用して、データを交換する方法が考えられる。また共有メモリとDMA(Direct Memory Access)転送を利用して高速に大量のデータを交換することも考えられる。この他には、LSIのレジスタを利用する方法やOSが提供する機能を利用することも考えられる。またこの手段は一つ存在していても複数存在していても良い。

図４はシステムの一部にＬＳＩを適用した図３のような構成に対して、本コンテンツ処理アーキテクチャを利用した場合の構成の例を示したものである。図４では図３の構成要素であるコーデック処理手段（１２７）、光ディスク装置（１０６）、シリアルインターフェース（１０８）、及び暗号処理手段（１１０）についての記載は省略したが、省略された手段についても同様な構成で取り扱うことが可能である。このＬＳＩ（１２０）内で動作する本実施例のコンテンツ処理アーキテクチャは、ドライバ部（５３）、システムインターフェース部（２１）、コンテンツ処理部（１１）、コンテンツ管理部（３１）及びアプリケーションプログラム（８１）から構成されて、図１で示した構成とほぼ同じである。異なる部分はＣＰＵ（１００）と通信をするためのデータ共有手段（１２９）のためのドライバ（５９）が追加されていることである。

ＬＳＩ（１２０）外の装置で処理されるコンテンツ処理アーキテクチャも、ドライバ部（５０）、システム機能提供部（４０）、システムインターフェース部（２０）、コンテンツ処理部（１０）、コンテンツ管理部（３０）、及びアプリケーションプログラム（８０）から構成され、図１の構成と同じである。このアーキテクチャにとってＬＳＩ（１２０）はＬＳＩドライバ（５１）経由でアクセスする一つの装置のように見える。例えば、ＬＳＩのチューナ（５５）で取得したデータを主ＣＰＵ側のネットワークアダプタで送出する場合、チューナ（１２５）から取得したデータはコンテンツ処理部（１１）を通り、データ共有ドライバ（５９）を使ってデータ共有手段（１２９）に出力される。ＬＳＩドライバ（５１）からデータ共有手段（１２９）に書き込まれたデータを取得し、コンテンツ処理部（１０）がネットワークアダプタ（１０４）に出力する。ＬＳＩ内のコンテンツ処理（１１）部に入力されたデータは、図１でも説明したように、上位のレイヤには出力されず、例えばチューナだけに意味があるヘッダ等の不要なデータを取り除く等の最低限の処理を行って、データ共有手段に出力される。この処理については図６で詳細を記す。このデータは主ＣＰＵ側からは単にデバイスからのデータに見えるので、コンテンツ処理部（１０）はデータを読み出して、これを適切に加工し、ネットワークドライバ（５２）に出力すればよい。

図６は図４に示したＬＳＩを使用した構成における、本アーキテクチャのコンテンツデータ処理のフローを示したものである。ここでは例としてチューナ（１２５）からのコンテンツデータをネットワークアダプタ（１０４）に出力する場合を考える。最初に、アプリケーションプログラム（８０）からコンテンツ処理部（３０）に対して利用できるコンテンツかをチェックする（ステップ１１００）。この処理はステップ１０００と同じである。コンテンツ処理を実行できる状況であれば、コンテンツ管理部はＬＳＩドライバ（５１）を使用してＬＳＩ（１２０）上のアプリケーションプログラム（８１）に、チューナ（１２５）から、データ共有手段（１２９）にコンテンツデータの処理パスを作成するように依頼する（ステップ１１１０）。これを受けてＬＳＩ（１２０）上のアプリケーションプログラム（８１）はまず要求されたコンテンツ処理が実行可能かを確認して（ステップ１１２０）、チューナ（１２５）とデータ共有手段（１２９）間のデータパスを設定する（ステップ１１３０）。次にコンテンツ処理部（１０）に対してはＬＳＩ（１２０）のデータ共有手段（１２９）からのデータをネットワークアダプタ（１０４）に出力するためのデータパスを設定する（ステップ１１４０）。

この後、ＬＳＩ（１２０）上のアプリケーションプログラム（８１）にコンテンツ処理開始を要求し、アプリケーションプログラム（８１）はコンテンツ処理部（１１）に処理開始要求を行う（ステップ１１５０）、コンテンツ処理部（１０）に対してもコンテンツ処理の開始を要求する（ステップ１１６０）。これにより、チューナ（１２５）で得たデータが、データ共有手段（１２９）に出力されるので（ステップ１１７０）、このデータをコンテンツ処理部（１０）がネットワークアダプタに出力する（ステップ１１８０）。これをデータの終了、あるいはユーザの停止要求があるまで繰り返して行う（ステップ１１９０）。
ＬＳＩ（１２０）上のアプリケーションプログラム（８１）と、ＬＳＩドライバ（５１）の通信は、コンテンツデータの交換と同じく、データ共有手段（１２９）を用いて行われる。

図７は本アーキテクチャに、拡張機能ライブラリ（６０）を追加した場合の構成を示したものである。拡張機能ライブラリ（６０）は、例えば、利用において特殊な手順が必要で、またこの手順が公開されていないデバイスを考えるとき、この制御プログラムのソースが公開されず、バイナリのライブラリだけが提供されることが考えられる。例えば、特殊なストレージデバイスで、記録されたデータを読み込むためには読込用の鍵をデバイスに設定しなければならない装置で、その鍵と利用処理手順が該ライブラリに隠蔽されて実装されているようなことが考えられる。このような場合、該デバイスを使用するには前記ライブラリを利用する他にない。この場合に、当該ライブラリを拡張機能ライブラリ（６０）として導入することで、目的のデバイスが利用可能となる。拡張ライブラリは予めシステムに組み込まれているか、あるいはコンテンツ管理部が必要に応じて動的に追加する。拡張機能ライブラリで処理されたデータの転送及び制御はシステムインターフェース経由でコンテンツ処理部が行う。この場合、拡張機能ライブラリ用のデータアクセスモジュールをコンテンツ処理部が備えれば、機能拡張ライブラリはストリーム制御部からはデバイスとして見えるので、図１４、１５で示した仕組みで利用することが可能である。

図８は図１で示した本アーキテクチャのシステムインターフェース部（２０）を、ＯＳ（５）内に実装した形態を示したものである。この構成では、システムインターフェース部（２０）がＯＳ（５）内のモジュールとして実装されるため、ＯＳ内のモジュールがアプリケーションプログラムより優先的に実行が行わるＯＳでは、ユーザ空間で実装されるよりも、性能で有利になる。

図９は図１で示した本アーキテクチャのシステムインターフェース部（２０）および、コンテンツ処理部（１０）をＯＳ（５）に実装した形態を示したものである。この構成では、システムインターフェース部（２０）および、コンテンツ処理部（１０）がＯＳ（５）内のモジュールとして実装されるため、ＯＳ内のモジュールがアプリケーションプログラムより優先的に実行が行わるＯＳでは、ユーザ空間で実装されるよりも、性能で有利になる。特に、リアルタイム性が必要となる、高ビットレートでのコンテンツ処理を行う場合には特に有効と考えられる。一方で、ＯＳ内での実装は、開発が難しく、実行時に障害が発生した場合に、ＯＳを異常終了させる可能性があるので、図１、図８あるいは図９の何れの構成を取るかは、用途、ハードウェア構成、及び開発工数などを考慮して決められるべきである。例えば、ＣＰＵの性能が低いプラットフォームでの実装、あるいは高い性能が要求される場合は、デバッグなどは多少困難になるが、高性能を実現することが比較的容易な図９のような構成が考えられる。逆に、ＣＰＵが十分に早くメモリ等の実行リソースが十分に利用できる場合や、高性能が要求されない場合等は、実装が容易な図１のような構成とすることが考えられる。

本実施例によれば、アプリケーションプログラムは、プラットフォームに非依存で処理を実行することが可能となる。また、様々なプラットフォームに対応可能なコンテンツ処理手段およびそのコンテンツ処理アーキテクチャを提供することが可能となり、コンテンツ処理プログラムを異なったプラットフォームに移行する場合に、コンテンツ処理プログラムを殆ど変更することなく動作させることが可能となる。

本実施例のソフトウェア構成を示した図である 本実施例を適用可能なハードウェア構成図である 図２の構成にＬＳＩを適用した場合の構成図である。 図３におけるソフトウェア構成を示した図である コンテンツ処理の手順のフローである。 ＬＳＩを適用したシステムにおけるコンテンツ処理の手順のフローである 機能拡張ライブラリを追加したソフトウェア構成を示した図である システムインターフェース部をＯＳ内に実装した構成を示した図である コンテンツ処理部をＯＳ内に実装した構成を示した図である リソース管理テーブルの構成を示した図である リソースの利用可否を判定する処理のフローである 基本的な処理を行った場合のフローである コンテンツ処理部内の処理を示した図である コンテンツ処理におけるデータ処理フローを記したテーブルの図である 利用可能なデータアクセスモジュールのテーブルの図である 利用可能なデータ処理モジュールのテーブルの図である

符号の説明

５…ＯＳ，１０…コンテンツ処理部、２０…システムインターフェース部、３０…コンテンツ管理部、４０…システム機能提供部、５０…ドライバ部、６０…拡張機能ライブラリ、７０…システムアクセスインターフェース、７１…コンテンツ処理制御インターフェース、８０…アプリケーションプログラム、１００…ＣＰＵ、１０１…ＲＡＭ、１０２…ＲＯＭ、１０３…ＨＤＤ、１０４…ネットワークアダプタ、１０５…チューナ、１０６…光ディスク装置、１０７…ディスプレイ、１０８…シリアルインターフェース、１０９…コーデック処理手段、１１０…暗号処理手段、１１１…バス、１１２…操作手段、１２０…ＬＳＩ

Claims (10)

1. コンテンツ処理装置であって、
   コンテンツの入力装置と、
   コンテンツの出力装置と、
   処理モジュールを格納した記憶部と、
   命令を発行する命令発行部と、
   前記命令を受信し、当該命令を実行するのに必要な前記処理モジュールを選択するコンテンツ管理部と、
   前記選択された処理モジュールを用いて処理を実行するコンテンツ処理部とを有し、
   前記コンテンツ処理部は、
   前記選択された処理モジュールを用いて、
   前記入力装置からのコンテンツの入力処理、あるいは前記出力装置へのコンテンツの出力処理を実行するデータアクセス部と、前記データアクセス部を介して入力されたコンテンツに所定の処理を実行した後に該処理後のコンテンツを前記データアクセス部に出力するデータ処理部とを有することを特徴とするコンテンツ処理装置。
2. 請求項１記載のコンテンツ処理装置であって、
   前記コンテンツ管理部は、前記記憶部に格納された、前記命令に対応する処理モジュールの組み合わせを規定した第１のテーブル、および選択可能な処理モジュールを規定した第２のテーブルを参照して、前記処理モジュールを選択することを特徴とするコンテンツ処理装置。
3. 請求項２記載のコンテンツ処理装置であって、
   前記第１のテーブルには、前記命令を実行するための処理モジュールの順序が規定されていることを特徴とするコンテンツ処理装置。
4. 請求項１記載のコンテンツ管理装置であって、
   前記記憶部には、前記入出力装置の使用可能性能を規定した第３のテーブルが格納され、
   前記コンテンツ管理部は、前記命令を実行するのに必要な入出力装置の性能が、前記第３のテーブルに規定された値の範囲内か否かを判断し、その結果、該テーブルに規定された範囲内である場合に、前記命令を実行することを特徴とするコンテンツ処理装置。
5. 請求項１記載のコンテンツ処理装置であって、
   前記データアクセス部あるいは前記データ処理部では、少なくとも１以上の処理モジュールが用いられることを特徴とするコンテンツ処理装置。
6. 請求項１記載のコンテンツ処理装置であって、
   前記命令に対応する処理モジュールの組み合わせを規定した第１のテーブル、および選択可能な処理モジュールを規定した第２のテーブル、前記入出力装置の使用可能性能を規定した第３のテーブルが格納された記憶部をさらに有し、
   前記入力装置がHDDで前記出力装置がネットワークアダプタである場合に、HDDからネットワークアダプタへのデータ転送要求命令がコンテンツ管理部に送信された場合、
   前記コンテンツ管理部は、前記命令を実行するのに必要な入出力装置の性能が、前記第３のテーブルに規定された値の範囲内か否かを判断し、その結果、該テーブルに規定された範囲内である場合に、前記第２のテーブルを参照して、前記データアクセス部で用いる処理モジュールとして、ハードディスクアクセス処理モジュールおよびネットワークアクセス処理モジュール、前記データ処理部で用いる処理モジュールとして、少なくともフォーマット変換処理モジュールを選択して、前記ハードディスクアクセス処理モジュールで処理されたデータが前記フォーマット変換処理モジュールに入力され、前記フォーマット変換処理モジュールで処理されたデータが前記ネットワークアクセス処理モジュールに入力されるように連結し、
   前記コンテンツ処理部は、各処理モジュールにおける処理を実行することで、該命令が実行されることを特徴とするコンテンツ処理装置。
7. 請求項６記載のコンテンツ処理装置であって、
   前記命令に含まれるデータの転送元情報と転送先情報に基づき、
   前記ハードディスクアクセス処理モジュールでは、前記HDDから前記転送元情報で指定されたデータが出力される処理が実行され、前記フォーマット変換処理モジュールでは前記データにヘッダが付加される処理が実行され、前記ネットワークアクセス処理モジュールでは前記転送先情報に基づき、前記データがネットワーク上に送信される処理が実行されることを特徴とするコンテンツデータ処理装置。
8. 請求項６記載のコンテンツ処理装置であって、
   前記命令に符号化方法が含まれている場合、前記コンテンツ管理部は符号化処理モジュールを選択し、前記フォーマット変換処理モジュールで処理されたデータが前記符号化処理モジュールに入力されるように連結し、
   前記コンテンツ処理部は、各処理モジュールにおける処理を実行することで、該命令が実行されることを特徴とするコンテンツ処理装置。
9. 命令を発行する命令発行部とコンテンツの入力装置と出力装置とを有するコンテンツ処理装置におけるコンテンツ処理方法であって、
   前記命令発行部から命令が発行される工程と、
   前記入力装置あるいは出力装置の使用可能性能を規定した第１のテーブルを参照して、前記命令を実行するのに用いられる入出力装置の性能が、前記第１のテーブルに規定された値の範囲内か否かを判断する工程と、
   前記判断の結果、前記第１のテーブルに規定された範囲内である場合に、前記命令に対応する処理モジュールの組み合わせを規定した第２のテーブルおよび選択可能な処理モジュールを規定した第３のテーブルを参照して、前記該当する処理モジュールを抽出して選択された処理モジュールを連結する工程と、
   前記連結された処理モジュールを用いて、前記命令を実行する工程とを有することを特徴とするコンテンツ処理方法。
10. 命令を発行する命令発行部とコンテンツの入力装置と出力装置とを有する計算機におけるコンテンツ処理プログラムであって、計算機に、
    前記命令発行部から命令が発行される工程と、
    前記入力装置あるいは出力装置の使用可能性能を規定した第１のテーブルを参照して、前記命令を実行するのに用いられる入出力装置の性能が、前記第１のテーブルに規定された値の範囲内か否かを判断する工程と、
    前記判断の結果、前記第１のテーブルに規定された範囲内である場合に、前記命令に対応する処理モジュールの組み合わせを規定した第２のテーブルおよび選択可能な処理モジュールを規定した第３のテーブルを参照して、前記該当する処理モジュールを抽出して選択された処理モジュールを連結する工程と、
    前記連結された処理モジュールを用いて、前記命令を実行する工程と実行させるためのプログラム。
    

Images