動的メディア供給インフラストラクチャ
【課題】 動的に作成および修正されたストリーミングのおよびダウンロードされたメディアコンテンツを供給すること。
【解決手段】 システムおよび方法は、コンテンツが供給された時点でのメディアコンテンツの動的な生成を提供する。本システムおよび方法は、単純で、既存の、オープンプロトコルの範囲内で機能し、供給されたメディアファイルは標準的なメディア再生クライアントで再生可能である。本方法は、クライアントからのメディアコンテンツのリクエストによって起動され、該リクエストは編集リストを明記している。サーバは、1つ以上のソースファイルを開き、編集リストの命令に基づいて送信すべき1つ以上のファイルの部分を選択し、クライアントに供給するための出力部にそれら部分を順次書き込む。本方法により、供給前のコンテンツの各種修正が可能となる。
【解決手段】 システムおよび方法は、コンテンツが供給された時点でのメディアコンテンツの動的な生成を提供する。本システムおよび方法は、単純で、既存の、オープンプロトコルの範囲内で機能し、供給されたメディアファイルは標準的なメディア再生クライアントで再生可能である。本方法は、クライアントからのメディアコンテンツのリクエストによって起動され、該リクエストは編集リストを明記している。サーバは、1つ以上のソースファイルを開き、編集リストの命令に基づいて送信すべき1つ以上のファイルの部分を選択し、クライアントに供給するための出力部にそれら部分を順次書き込む。本方法により、供給前のコンテンツの各種修正が可能となる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ストリーミングおよびダウンロードメディアコンテンツの表示および修正に関し、特に、動的に作成および修正されたストリーミングのおよびダウンロードされたメディアコンテンツの供給に関する。
【背景技術】
【０００２】
例えば、メディアコンテンツのクライアントリクエストに応じてサーバからクライアントへインターネットを横断するような、メディアコンテンツのストリーミングおよびダウンロードのための方法が知られている。既存の技術は従来の静的ファイル供給インターフェイスを使用し、このインターフェイスでは完全なファイルがクライアントに供給される。これらの技術は、全部のファイル、または、ファイル内のクライアントから要求されたバイトレンジのいずれかを供給する。ファイルは通常、再生のためのサーバ上で格納もしくはキャッシュされている。一般に、ユーザがこういった方法でメディアコンテンツを閲覧することを望む場合、専用のクライアントはメディアコンテンツの再生のためにダウンロードをする必要があり、専用のプロトコル、フォーマット、および、映像符号化が使用される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、動的に作成および修正されたストリーミングのおよびダウンロードされたメディアコンテンツを供給するための方法およびシステムを提供しようとするものである。
【課題を解決するための手段】
【０００４】
本発明はメディアコンテンツを供給するための方法およびシステムの各種実施形態を提供する。本システムは、インデックスが付されたデータソースファイルの本体からのメディアコンテンツの動的な生成を提供する。本システムおよび方法は、単純で、既存のオープンプロトコル、例えばＨＴＴＰと、基準に準拠した映像符号化、例えばＭＰＥＧ−４やｈ．２６３とを使用する。本システムおよび方法により、コンテンツがクライアントに供給された時点でメディアコンテンツの動的な生成が可能となる。本システムにより、ファイルの部分のためのクライアントからの時間ベースのリクエストが可能となる。供給されたメディアファイルは標準的なメディア再生クライアントで再生可能である。
【０００５】
本方法は、クライアントからメディアコンテンツのリクエストを受信することを含み、リクエストはメディアソースファイルの要旨リストおよび編集リストを含んでいる。サーバは、1つ以上のソースメディアファイルを開き、これらファイルをパースし、編集リストに基づいて送信するフレームまたは他の部分を選択し、続いて、それら部分をクライアントへの供給のための出力ファイルに書き込む。本方法により、要求された時間以降および供給前のコンテンツの動的な修正が可能となり、従って、音声および映像の接合および編集、リアルタイムの広告挿入、暗号化、供給されたコンテンツのレート変更（例えば、スピードアップやスローダウン）などの修正が可能となる。
本明細書の記述は全てを含んでいるわけではなく、特に、図面、明細書、および、特許請求の範囲を考慮すると、多くの付加的な特徴は当業者とって明らかである。さらに、注意すべきは、本明細書で使用される言語は、可読性および教示用目的のために主として選択され、発明的主題を線引きまたは範囲を定めるために選択されたわけではない、ということである。
【図面の簡単な説明】
【０００６】
【図１】本発明の一実施形態に係るクライアントサーバアーキテクチャを示すブロック図。
【図２】本発明の一実施形態に係る前記サーバのさらなる詳細を示すブロック図。
【図３】本発明の一実施形態に係る、メディアコンテンツを供給するための方法を示すフローチャート。
【図４Ａ】本発明の一実施形態に係る、実行可能なＵＲＬを示す図。
【図４Ｂ】本発明の別の実施形態に係る、実行可能なＵＲＬを示す図。
【図４Ｃ】本発明の別の実施形態に係る、実行可能なＵＲＬを示す図。
【図５Ａ】本発明の一実施形態に係るファイルフォーマットの図。
【図５Ｂ】本発明の一実施形態に従ったサンプルＡＶＩファイルの図。
【図６】一実施形態に従ってここで述べられた方法を使用する場合の一例を示す図。
【発明を実施するための最良の形態】
【０００７】
ここで説明される本発明の原理から乖離することなく、ここで示される構成および方法の代替実施形態を使用することができるということを、当業者であれば以下の解説から容易に認識することができるであろう。
ここで、メディアを供給するための方法およびシステムを説明する。ここで使用されるメディアコンテンツとは、あらゆるタイプの映像および音声コンテンツフォーマットを指し、音声のみのフォーマットと同様に、動画ファイル、すなわち、画像および音声を共に含んだファイルを含んでおり、あらゆる形式の音声、映像、メタデータ、またはこれらの組み合わせを含んでもよい。一般例は、２つのインタレース方式のストリーム、１つの映像ストリーム、および、１つの音声ストリームを含んだ映像アーティクルである。しかし、ここで述べられる技術はあらゆる数のファイル部分またはストリームで使用することができ、メタデータを含んでもよい。
【０００８】
方法の一実施形態は、標準的なクライアントサーバアーキテクチャのコンテキストで実施される。図１は、この方法をサポートするために好適なクライアントサーバアーキテクチャを示すブロック図である。このようなシステムは、クライアント１０５およびサーバ１１０を備え、これらは例えばネットワーク１１５によって通信可能なように接続されている。クライアント１０５は、あらゆるタイプのクライアントコンピュータデバイス、例えば、プロトコル（例えばＴＣＰ／ＩＰおよびＨＴＴＰ）に関連したインターネット上で通信をするため、および、ユーザインターフェイスを表示するための少なくとも一方に適合したブラウザアプリケーションや他のアプリケーションを実行する装置であってもよい。一実施形態によれば、クライアント１０５のユーザインターフェイスで、ユーザはメディアコンテンツ部分を閲覧、編集、および選択することができ、これらを整理することができ、その結果ここで説明されるように編集リストの基礎が形成される。クライアント１０５は一実施形態によれば従来通りの設計であり、プロセッサ、アドレス指定できるメモリ、および、他の装備、例えば、表示装置、ローカルメモリ、入出力ポート、ネットワークインターフェイスを含む。他の実施形態では、クライアント１０５の１つ以上の構成要素は遠隔設置して、ネットワーク、すなわち１１５を介してアクセスしてもよい。ネットワークインターフェイスおよびネットワークコミュニケーションプロトコルは、ネットワーク１１５および他のコンピュータ、例えば、サーバ１１０または他のサードパーティコンピュータへのアクセスを提供し、そこでは、インターネットへのアクセスと共に、ＴＣＰ／ＩＰタイプ接続を介し、または、他のネットワークの実例、例えば、ＬＡＮ、ＷＡＮ、ＭＡＮ、有線もしくは無線ネットワーク、専用ネットワーク、仮想ネットワーク、他のネットワークを介して、または、２つもしくはそれ以上のコンピュータシステム間でデータ通信を可能とする他のシステムへのアクセスを提供する。各種実施形態では、クライアント１０５はマイクロソフトオペレーティングシステム（登録商標）、マックＯＳ（登録商標）、リナックス(Linux) （登録商標）系の各種、ＵＮＩＸ（登録商標）、パームＯＳ（登録商標）、および、他のオペレーティングシステムの少なくとも１つを稼働するコンピュータ上で構築するようにしてもよい。単一のクライアント１０５のみが図示されているが、システムは多くのクライアント１０５を用いた多量の並行セッションをサポートすることができる。
【０００９】
一実例では、システムは高性能サーバクラスコンピュータ１１０上で稼働する。サーバ１１０のハードウェア局面の詳細は当業者には周知のものであり、ここではこれ以上説明はしない。サーバ１１０は単一のコンピュータシステムとして図１に描画されているが、システムはコンピュータプロセッサのネットワークとして実現し、記憶装置と関連付けることができる。サーバ装置１１０の例は、サーバ、メインフレームコンピュータ、ネットワークコンピュータ、プロセッサに基づく装置、および、同種のシステムおよび装置である。サーバ装置１１０およびそれに関連付けられた記憶装置は物理的な共同設置を必要としない、しかも、記憶装置およびサーバコンピュータ間のいかなる所定の配置を必要としない。サーバプロセッサは、多数の周知のコンピュータプロセッサ、例えば、カリフォルニア州、サンタクララのインテル株式会社や、イリノイ州、ショウンバーグのモトローラ株式会社によるプロセッサのいずれであってもよい。一実施形態では、サーバ１１０は十分な処理能力および処理量を有し、ここで述べられる提供に先立ってコンテンツの修正を実行する。ネットワーク１１５は、各種実施形態によれば、インターネット単独で構成しても、他のネットワーク、有線および無線の、例えば、イントラネット、ローカルエリアネットワーク、ワイドエリアネットワーク、またはブロードキャストネットワークと組み合わせて構成してもよい。
【００１０】
図２はサーバ１１０の更なる詳細を示すブロック図である。一実施形態では、サーバ１１０は、サーバソフトウェア１２０、ソースファイルデータ記憶装置１２５、コンテンツインデックス１３０、およびキーデータ記憶装置１３５を含む。他の実施形態では、ソースファイルデータ記憶装置１２５、コンテンツインデックス１３０、およびキーデータ記憶装置１３５は、アクセスは可能であるが、サーバ１１０から分離されるか、および、単一のデータ記憶装置を形成するかの少なくとも一方である。サーバソフトウェア１２０は、多くの実行可能なコード部分およびデータファイルで構成される。これらは、ここで述べられる方法を可能とするためのコードを含む。いくつかの実施形態では、サーバソフトウェア１２０は、サーバ１１０の外部でスタンドアロンアプリケーションとして実現することができる。サーバソフトウェア１２０は、本発明の方法に従って実行される処理を調整するための責任を負う。サーバソフトウェア１２０は、本発明の一実施形態によれば、リードモジュール１４０、ライトモジュール１４５、およびバッファモジュール１５０を含む。リードモジュール１４０は一実施形態によればリードスレッド機能を使用可能にするものであって、これを行うための手段である。リードモジュール１４０は、一実施形態によれば、ここで説明されるようなソースメディアファイルアクセス、処理、ヘッダ形成、コンテンツリード、コンテンツ修正、フッタ構築、および出力部への書き込みを制御する。ライトモジュール１４５は一実施形態によればライトスレッド機能を使用可能にするものであって、これを行うための手段である。ライトモジュール１４５は、一実施形態によれば、サーバ１１０が出力部（ネットワーク送信バッファ）からネットワーク１１５へのデータの書き込みを制御できるようにする。バッファモジュール１５０は、一実施形態によれば、ネットワーク送信バッファにデータを配置することで、システムがネットワークに書き込むためのデータの準備できるようにするものであって、これを行うための手段である。バッファモジュール１５０はネットワーク送信バッファの機能を制御する。前述のソフトウェア部分１４０、１４５、１５０は個別のソフトウェアモジュールである必要はない。示されているソフトウェア構成はほんの一例を意味し、他の構成は本発明の範囲でおよび範囲内で考えられる。本発明のこれらの局面によれば、サーバ１１０は、供給のためにコンテンツを複写する必要なく、格納されたコンテンツからメディアコンテンツを直接供給することができる。加えて、供給されたメディアファイルは標準的なメディア再生クライアントで再生可能である。
【００１１】
格納されたメディアコンテンツは、アップロードされた結果として、ユーザによりクライアント１０５から予め受信することができる。他の実施形態では、メディアコンテンツは１つ以上の他のソースから、例えばテレビ放送コンテンツとして受信することができる。メディアコンテンツがサーバ１１０により一旦受信されると、メディアファイルは供給フォーマットにコード変換される。この実施形態では、供給ファイルフォーマットへのコード変換は、メディアファイルを処理すること、メディアファイル内のインデックスを付すことができる部分を識別すること、フレームを列挙して各フレームにタイムスタンプを割り当てること、メディアファイルヘッダおよびフッタをパースすること、および、フォーマット特定のチャンクバウンダリポイントを計算することを含む。メディアコンテンツはソースファイルデータ記憶装置１２５に格納され、該メディアコンテンツに係るデータはメディアコンテンツの帯域外（アウト・オブ・バンド）でコンテンツインデックス１３０に格納されていて、コンテンツ識別子を用いて照会することができる。コンテンツ識別子は、格納されたメディアコンテンツの単一作品 (piece) およびメディアコンテンツに係るデータを一義的に識別する数字識別子であって、例えば、格納されたメディアコンテンツの属性から計算された６４ビットのハッシュ値や、作成されたときにこのコンテンツに割り当てられた任意の数である。識別子は、ファイル名を使用する代わりに、メディアコンテンツの匿名の照会、例えば、プライバシーおよびセキュリティのより一層の提供に用いられる。
【００１２】
ソースファイルデータ記憶装置１２５は、一実施形態によれば、メディアコンテンツデータを格納するリレーショナルデータベースまたは他のいずれのタイプのデータベースであってもよい。サーバ上のメディアコンテンツは、各種形式（例えば、圧縮または非圧縮）で各種ソースから受信することができる。メディアアーティクルは各種方法およびフォーマットで格納することができる。例えば、メディアアーティクルは、ファイルまたは他のデータとしてデータベースまたは他の記憶媒体に格納することができる。メディアアーティクルは、任意の解像度（例えば、ＨＤまたはＳＤ）と同様に、例えば、エムペグ（ＭＰＥＧ−２、ＭＰＥＧ−４）、ウィンドウズ（登録商標）メディア９（Windows（登録商標）Media High Definition Video）、ビデオフォーウィンドウズ（登録商標）（ＡＶＩ）、クイックタイム、インデオなどの任意のフォーマットや、単一のフォーマット（例えば、テレビジョン方式審議委員会（ＮＴＳＣ）、パル方式（ＰＡＬ）、セカムカラーテレビジョン方式（ＳＥＣＡＭ））で格納された映像コンテンツ、または、任意のフォーマットおよび標準のいかなるものでの好適な他の映像コンテンツを含んでもよい。メディアアーティクルは、ブロードキャストに好適であること、および、ネットワーク（例えばインターネット）、パーソナルコンピュータ、または他の計算機または記憶手段を利用可能にすることとの少なくとも一方であって、プログラムガイド情報、メタデータ、および、閉ざされたキャプショニングテキストなどの映像コンテンツに関連した他のデータを含んでもよい。ここで説明される実施形態は映像コンテンツに関して概ね解説され、こうして映像アーティクルと見なされるが、実施形態は、音声のみのコンテンツを含んだ任意の好適な種類のコンテンツで作用してもよい。
【００１３】
一実施形態に従ったファイルフォーマット例は図５Ａに示される。ファイルフォーマットは、ファイルコンテンツ５０２が続く任意のファイルヘッダ、および、任意のファイルフッタを含む。ファイルコンテンツ５０２は０以上のチャンク５０４の一続きを備え、各チャンクは「フレーム」５０６（もしくは、ここで説明されるグループ）の一続きである。各フレーム５０６は、フレームコンテンツ５０８が続く任意のフレームヘッダ、および、任意のフレームフッタを含む。フレーム５０６（またはグループ）は、一実施形態によれば、任意のタイプの、音声、映像、または、メタデータであってよい。他の実施形態では、このモデルは、例えば、アドビフォトスクリプト（商標登録済み）、ＰＤＦ、ｍｐ３のための他のファイルタイプや、他のカスタムファイルタイプに使用することができる。フレームまたはグループ５０６は１つ以上のコンテンツストリームを含む。ストリームは、ファイルフォーマットを含むことで識別されるフレームのセットを指す。例えば、ファイルは０以上の映像ストリームを含んでも、０以上の音声ストリームを含んでもよい。各フレーム５０６は、少なくとも１つのストリームの部分であるとして印を付ける識別子を有する。いくつかのフォーマットはフレームフォーマットタイプに基づいてストリームを暗黙のうちに定義する。
【００１４】
各フレーム５０６は、一実施形態によれば、映像符号化フォーマットおよび符号化パラメータの使用で定義されるように、キーフレームであってもよい。メディアファイルは１つ以上のキーフレームを含む必要があり、チャンクは０以上のキーフレームを含んでもよい。キーフレームは、再生を開始することができるメディアコンテンツのセグメントを許可するために使用される。しかし、多くの音声フォーマットはこういった規制を持たず、個々の音声フレームバウンダリで切り取ることができる。本発明によれば、各フレーム５０６用にタイムスタンプを計算することができる。タイムスタンプは必ずしも物理的な時間である必要はなく、ファイル内の各ストリームの各フレームに割り当てられた任意の単調増加値として考えられるべきである。タイムスタンプが直接利用可能ではない場合、タイムスタンプを映像ファイルのパラメータに従って補間法を介して合成することができる。各フレーム５０６は、データ、典型的な圧縮された音声、圧縮された映像、テキストメタデータ、バイナリメタデータ、または、圧縮されたもしくは圧縮されていないデータの他の任意のタイプのいずれかで構成される。
【００１５】
一実施形態では、ＡＶＩファイルはメディアアーティクルの格納に用いられる。図５Ｂは、一実施形態に係るＡＶＩファイルコンテンツ例を示す。この例では、ＡＶＩファイルは、セグメントに関する基本情報、例えば、幅、高さ、映像フォーマット、音声フォーマット、映像フレーム数、音声フレーム数、映像フレーム長など、を含んだヘッダ５０５を含む。ファイルのバルクはバイトコンテンツ情報５１０を列記する。加えて、ファイルはバイトオフセットなどに関連する情報を含んだフッタ５１５で終了する。この例では、各フレームはキーフレームである。
【００１６】
コンテンツインデックス１３０は、一実施形態によれば、ソースファイルメディアに対応するインデックスが付されたデータを格納するリレーショナルデータベースまたは他の任意のタイプのデータベースであってよい。コンテンツインデックス１３０は、一実施形態によれば、ファイルフォーマット特定のデータ構造であって、この構造は全体的なファイル情報と同様に、ソースメディアファイルヘッダおよびフッタから関連する情報を含む。コンテンツインデックス１３０は格納されたリストのセットとして構成してもよい。コンテンツインデックス１３０は、ファイルの部分である、チャンクにセグメント化されたメディアを格納する。図５Ａに示されるファイル構造と同様に、各チャンクは内部データアクセスのための自身のファイル名を有し、フレームおよびグループの少なくとも一方のセットを含む。各チャンクはコンテンツインデックス１３０の行に関連してもよい。一実施形態では、各列は６４ｋバイトの最大サイズを有し、行識別子で識別され、コンテンツ識別子とフォーマットおよび解像度の映像符号化のための識別子とのハッシュである。この例では、行識別子は複数の列を含み、ここで述べるようにコンテンツインデックス１３０データを指定する。他の実施形態では、メディアファイルの全チャンクのための全てのデータは、１つ以上の列を使用して、単一のデータベース行に格納されている。一実施形態によれば、チャンクインデックスは、各チャンクのために、チャンク識別子番号、チャンクバイトオフセット（ファイルのスタートから）、バイト単位のチャンク長、チャンクスタートタイムスタンプ、および、チャンクエンドタイムスタンプを格納し、さらに、チャンクの各ストリームのために、ストリームフレーム番号、ストリームフレーム数、ストリームスタートタイムスタンプ、および、ストリームエンドタイムスタンプを格納する。本発明のこの局面により、所定のメディアファイルは多くの個別のチャンクに切り離され、これらは個別にまたは一緒に格納され、リードおよびライト性能を最適化する。さらに、フレーム、グループ、または他のファイル部分へのチャンクの分離により、各種ファイル操作（コード変換、解像度など）がフレームまたはグループレベルで実行することができ、システムはこのレベルでの粒度で修正を行うことができる。
【００１７】
コンテンツインデックス１３０はコンテンツ識別子および時間からファイル名、バイトオフセット、および、（映像、音声）フレーム番号およびグループ番号の少なくとも一方をマップする。このマッピングはメディアコンテンツがサーバで受信されたときに作成される。一実施形態では、マッピングは、映像および音声供給内の特定のタイムインデックスポイントをソースファイルの特定バイトにマップする。バイトオフセットは、本発明によれば、音声または映像フレームの開始に関連し、コンテンツインデックス１３０自身はファイル不可知論(file-agnostic)であるフォーマットで、特定ファイルフォーマットとインデックス１３０のメタデータとして格納されるコーデックと共に格納される。従って、コンテンツインデックス１３０は、オリジナルファイルのタイムインデックスポイントの関連位置の表示を提供し、そのバイトにどんなコンテンツ（例えば、音声および映像）が格納されているかが正確に提供される。
【００１８】
一実施形態では、時間からバイトへのマッピングは各映像キーフレームのために存在する。他の実施形態では、時間からバイトへのマッピングは、映像アーティクルの全ての音声フレームおよび映像フレームのために、映像アーティクルの全てのＮフレームのために、または、全てのＮ映像キーフレームのために、情報のサイズ（マッピングの項目数）に関連する制限無く存在する。さらに他の実施形態によれば、時間からオフセットへのマッピングは最も近いグループにマップする。多くの圧縮された映像フォーマットは、画像のグループ（「ＧＯＰ(Group Of Pictures)」、「グループ」）の概念を有し、この画像のグループは映像フレームの原子（および分割できない）セットと考えることができる。映像フレームのこのセットは映像の復号化および再符号化することなく、いかなるポイントでも切り離すことができない。従って、一実施形態では、メディアコンテンツは、フレームレベルよりもグループレベルでアドレス指定される。一般に、音声フォーマットはこういった制限が無く、個々の音声フレームバウンダリで切り離すことができる。各フレームまたはグループは時間で分類され、スタートタイム、音声および映像フレーム番号の少なくとも一方、および、バイトオフセットを含む。言い換えると、いかなるメディアファイルの所定のタイムポイント（もしくは時間範囲）のために、コンテンツインデックス１３０は、その時間に関連する特定のチャンクおよび、それに関連する特定フレームを判定するために使用することができ、これにより必要に応じてそれらを検索することができる。
【００１９】
従って、一実施形態によれば、コンテンツインデックス１３０は、コンテンツ識別子、メディアファイル内のファイル部分またはストリームおよびストリームタイプの数、バイト単位のファイルコンテンツオフセット、バイト単位のファイルフッタオフセット、ストリーム特定の情報（例えば、フレームレート、フォーマット、幅、高さ、継続時間）、ファイルフォーマットの特定フラグ、および、ファイルフォーマット識別子を含む。この例では、インデックスが付されたデータは、前述で参照されたコード変換の結果として利用することができる。加えて、受信した映像ファイルからの他の情報（例えば、幅、高さ、音声および映像フレームレート、音声および映像継続時間、ファイルフォーマット、音声および映像コーデック）はまたコンテンツインデックス１３０に格納してもよい。メディアコンテンツは、複数の個別のインデックス部分のソースファイルに格納される。ここで使用される「部分」とは、ファイルのあらゆるセグメントまたは断片を指し、フレーム、チャンク、グループ、セグメント、または、ここで定義される他の部分を含む。
【００２０】
キーデータ記憶装置１３５は、ＵＲＬ内の暗号化データのためのキーに対応するデータを格納するリレーショナルデータベースまたは他の任意のデータベースであってよい。キーデータ記憶装置１３５は、ユーザインターフェイスを介してサーバソフトウェア１２０によりアクセスすることができる。
【００２１】
サーバソフトウェア１２０、ソースファイルデータ記憶装置１２５、コンテンツインデックス１３０、および、キーデータ記憶装置１３５は、単一のコンピュータ、または、ネットワークを介して互いに通信する個別のコンピュータシステムに格納されて稼働してもよい。
【００２２】
一実施形態におけるサーバ１１０は、例えば、１つ以上のクライアント１０５でアップロードされたメディアコンテンツを格納する。他の実施形態では、メディアコンテンツ、例えばここで説明される映像アーティクルは、例えば遠隔配置されたシステムなどの外部のサーバに格納されてもよい。
【００２３】
図１および図２に示されるシステム構成は単に典型例であり、本発明が多くの他の構成および環境を用いて実践および実現することができる、ということを当業者は認識するはずである。
【００２４】
再び図２を参照すると、一実施形態では、本発明は、映像コンテンツ用の処理クエリのための情報検索システムのコンテンツで動作する。図３は、本発明の一実施形態に係るメディアコンテンツ供給のための方法を示すフローチャートである。この方法は、クライアント１０５からのリクエストがサーバ１１０に格納されたメディアコンテンツのために受信されたとき（３１０）に開始する。このリクエストはサーバ１１０へのネットワークインターフェイスで受信される。サーバ１１０へのリクエストは、ユーザが再生を望むコンテンツのためのコンテンツ識別子、メディアコンテンツを再生するときの解像度、および、時間範囲を含み、これらはスタートタイム（ミリ秒で、もしくは他の時間単位、コンテンツへの）および長さ（ミリ秒または他の時間単位で）として特定される。コンテンツ識別子は、例えば、格納されたメディアコンテンツの属性から計算された６４ビットのハッシュ値や、このコンテンツが作成された時間でコンテンツに割り当てられたランダム値などの、格納されたメディアコンテンツの単一作品 (piece) およびメディアコンテンツに関するデータを一義的に識別する数値識別子である。コンテンツ識別子は、ファイル名を用いる代わりにメディアコンテンツの匿名照会、例えば、プライバシーおよびセキュリティのより一層の提供に用いられる。従来のバイトベースのリクエストに比べて、クライアントからの時間ベースのリクエストが可能となるため、本発明のこういった局面は好適である。
【００２５】
リクエストはまた編集リストを含む。ここで使用される編集リストは、格納されたメディアコンテンツの供給および編集のための動的または静的な命令のリストを参照する。編集リスト命令は、クライアント１０５およびサーバ１１０のいずれか、またはその両方によって加えることができる。例えば、クライアント１０５から受信した編集リストが提供されると、サーバ１１０は、追加の命令をクライアントリクエストコンテンツの先頭に付加、最後に追加、または、挿入することができるか、もしくは、コンテンツの長さ、レート、ストリーム数、ファイルラッパフォーマットを修正することができる。編集リスト命令は、完全なソースファイルの非常に単純な供給から、複雑な修正までに至り、一実施形態によれば、ソースファイルの部分を供給すること、１つ以上のソースファイルの複数の部分を供給すること、ソースファイルまたは部分が供給されるレートを変更すること（スピードアップまたはスローダウンすること）、ソースファイルまたは部分が供給されるレートをクライアントの能力に適合させること、ファイルまたは部分を暗号化すること、ファイルまたは部分にストリームを加えたり取り除いたりすること、異なったファイルまたは部分からストリームをインターリーブすること、データストリームをファイルまたは部分に加えること、ファイルラッパフォーマットを変換すること、所有者ファイルフォーマットを基準に準拠したフォーマットに変換すること、メタデータをファイルまたは部分に挿入すること、および、各種他の修正を含む。各種実施形態によれば、他の可能な修正は、ステレオ音声をモノラル音声に変更すること、カラー映像を白黒映像に変更すること、映像ストリームの解像度を下げること、静止画ストリームの解像度を下げること、映像または静止画ストリームの各種視覚アルゴリズムを実行すること（シャープにする、ぼやかす、変形させる、クロスフェードするなど）、および、各種音声アルゴリズムを実行すること（サンプルレートを変更する、ピッチシフト、レート調整、エコー、フランジをつけるなど）を含む。これらの修正を実現する方法の例は以下の説明に含まれる。
【００２６】
リクエストは、単一のメディアソースファイルからのコンテンツのための、メディアコンテンツの変化した（例えば、切り詰められた）バージョン、または、異なるメディアソースファイルからの作品 (piece) の組み合わせであってよい。１つ以上のファイルの複数の部分を含んだリクエストのために、リクエストは複数の時間範囲を含み、この実施形態によれば、サーバ１１０はコンテンツインデックスに、要求されたタイムスタンプに最も近くにあるチャンクを見つける問い合わせを行う。
【００２７】
リクエストは、図４Ａに示されるように、ハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエスト（または類似の転送プロトコル）であって、ＵＲＬ(Uniform Resource Locator)の形式をとる。ＵＲＬ４００は典型的なフォーマットであって、プロトコル４０５、ホスト（および、妥当であればポート）４１０、および、ソースパスとクエリストリングの少なくとも一方４１５を含む。加えて、編集リスト４２０は、１つ以上のファイル上の動作を実行するための命令の形式で含まれる。図４Ａは単純な例を示し、ここでは時間範囲は唯一のパラメータである。いくつかの実施形態では、ＵＲＬ４００の一部はここで説明されるように暗号化される。図４Ｂは暗号化されたＵＲＬ４２５の一例を示す。ＵＲＬが暗号化された実施形態では、クライアントは暗号化された部分を修正することはできないが、例えば、レートを上げる、ディアコンテンツの小さなサブセットを要求するといった修正をＵＲＬに加えることができる。図４Ｃは、追加の編集リスト命令４３０が最後に付加された、暗号化されたＵＲＬの一例を示す。この例では、コンテンツのためのレートを上げるため（通常速度の１．５倍に）および１０〜５００の時間範囲を選択するために命令が追加されている。一実施形態によれば、クライアント１０５により許可された修正は暗号化された部分を変えない。例えば、ファイルサイズが１０００である場合、１０〜５０００へのリクエストは、サーバにより利用可能な時間範囲に自動的に調整される。
【００２８】
リクエストが受信されると（３１０）、メディアコンテンツリクエストに対応する少なくとも１つのソースメディアファイルが開かれる（３２０）。このためには、リクエストはリードスレッドに送られると、コンテンツ識別子を用いたコンテンツインデックス１３０の非同期検索を行い、特定時間範囲からのバイトオフセットおよびフレーム長を計算し、そしてソースメディアファイルを開く（３２０）。一実施形態では、複数の部分が組み合わされる、もしくは、複数のストリームがインターリーブされた場合、サーバ１１０は、全ての部分に関連する全てのコンテンツ項目のためのコンテンツインデックスの読み出しに先立って、送信される順番にコンテンツ項目をソートする。加えて、サーバ１１０は、関連するヘッダおよびフッタ情報、例えば、映像解像度およびフレームレート、圧縮されたファイルの部分のバイトレンジ、および、他のファイルフォーマットの特定情報、を格納する。データストリームが加えられている場合、サーバ１１０はまた、データストリームのためのコンテンツインデックス情報を読み出し、この情報はストリームに挿入されるタイムスタンプされたデータオブジェクトのリストを含む。タイムスタンプされたデータオブジェクトは任意のバイナリデータ、テキストデータ、または、他のいかなるフォーマットであってもよい。
【００２９】
加えて、一実施形態によれば、コンテンツインデックス１３０に格納されている情報から新しいファイルヘッダが作成され、出力部に書き込まれる。一実施形態では、サーバ１１０は、コンテンツインデックス１３０を調べ、ヘッダ情報を読み出し、および、要求された時間範囲を示すセグメントメディアヘッダを構築する。サーバ１１０は、このリクエストの間に送信されることになっている音声および映像フレームの数を算出する。１つ以上の部分が使用されている場合、サーバ１１０は送信されることになっている全てのコンテンツ項目からフレームの総数としての総数を算出する。コンテンツがスピードアップまたはスローダウンされている場合、送信されることになっているフレーム数は、ソースメディアファイルのフレーム数と異なるはずである。サーバ１１０はまた、一実施形態に従って、オリジナルバイトレンジおよび（映像および音声）フレーム数を指定するデータを最後に追加する。データが暗号化されている場合、クライアントが後続する暗号化されたデータを復号化できるようにするための、暗号化キー、ユーザ識別マーク、または、他の情報をヘッダは含んでもよい。ファイルラッパが変換されている場合、「新しい」ラッパフォーマット（例えば、ラッパが変換されるフォーマット）に従って、サーバは有効なファイルヘッダを作る。ラッパ変換が所有者フォーマットから基準に準拠したフォーマットへのものである場合、例えば、オリジナルラッパフォーマットが基準に準拠したフォーマットではないフォーマットの場合、新しいラッパフォーマットが基準に準拠したそれになる。
【００３０】
ファイルが開かれると（３２０）、いくつか、もしくは、全てのファイルコンテンツが読み出される。
【００３１】
オリジナルソースとして同じファイルフォーマットでメディアファイルを再構築するために、対象である最初および最後の映像および音声フレーム（またはグループ）のバイトオフセットは、セグメントの映像および音声フレームの数と同様に、クライアントに有用でありうる他のあらゆるメタデータと同様に、配置される。加えて、新しいヘッダ（および、フォーマットに妥当であればフッタ）が作成され、互いに接合されて出力ファイルを構築する。
【００３２】
編集リストの命令に基づいて送信するために、メディアコンテンツの個別にインデックスが付された部分が選択される（３３０）。一実施形態では、先の選択（３３０）はソースメディアファイルからの読み出しループの一部であり、そのデータは出力部に書き込まれる。一旦選択されると（３３０）、サーバ１１０はオリジナルメディアソースファイルのバイトレンジを見つけ出し、領域を読み出す。一実施形態では、出力部はネットワークの送信バッファである。一実施形態によれば、クライアントへの供給のために、ネットワークの送信バッファはネットワークへの出力に備えてデータを格納する。
【００３３】
オプションとして、サーバは次に部分を修正する（３４０）。各種修正が可能であり、各修正は編集リストの命令に列挙される。各修正工程は長さを維持してもしなくてもよく、よって、修正処理の各工程後、フレームおよび他の部分はいずれの長さであってもよい。実行可能なデータ修正の１つはデータの暗号化である。フレームまたは部分のそれぞれのコンテンツは要求に先立って生成されたキーを用いて暗号化される。これを実現するため、サーバ１１０はこのコンテンツの各フレームを調べ、標準暗号化アルゴリズムをこれらフレームのいくつかもしくは全てに適用し、暗号化されたデータを出力部に書き込む前に暗号化されたものとしてそれらを明確に示す方法でフレームを修正する。キーは例えばキーデータ記憶装置１３５に格納されており、復号化する目的のため後に検索することができる。暗号化の使用により、追加のデータ、例えば広告対象情報を挿入することができる。他の実行可能なデータ修正は、オリジナル符号化レートと異なったレートにレートを変更することである。例えば、ユーザは、オリジナルコンテンツよりも速く再生されることになっているファイルを送信する「早送り」ストリームまたは部分を要求することができる。早送りを実現するために、一実施形態では、フレームが選択されてソースファイルから取り込まれ、残りのフレームは出力部に通常に、もしくはそれらのタイムスタンプに応じて適合するように書き込まれる。例えば、各映像フレームのために、フレームは廃棄または出力部に書き込まれる。要求されたスピードアップ要因および映像符号化の規定は廃棄されるべきフレーム数を判定する。サーバ１１０はまた、映像ストリームのレートに一致した有効な音声ストリームを構築する必要がある。音声ストリームは、例えば、オリジナル音声の代わりに予め計算された「サイレンス」音声トラックを用いたり、新しい映像レートに一致する音声レートに調整するためのより高性能の音声処理を実行したり、オリジナル音声フレームの一部を廃棄することで構築される。
【００３４】
他の例は、オリジナルソースより低いレートで再生されるデータを送出するようになっている「スローモーション」ストリームもしくは部分である。スローモーションを実現するために、フレームは複製のために選択されるか、もしくは、「パディング」フレームが自動的に複製されたフレームに加えられる。例えば、各映像フレームのために、フレームは無傷で送信されるか、予め送信されたフレームを複製するフォーマット特定の目印がファイル内に配置される。要求されたスローダウンおよび映像の符号化フォーマットの規定は複製されるべきフレーム数を判定し、複製フレームに目印を付けるために送信されるバイトと同様に、フレームを複製することができる。コンテンツのスピードアップと同様に、サーバ１１０はまた、例えば前述したように、映像ストリームのレートに一致する有効音声ストリームを構築する必要がある。他の実行可能なレート変更修正は適応可能なビットレートである。この修正を実現するために、サーバ１１０はクライアント１０５がリアルタイムでの復号化に十分であるレートで映像を受信することができるかどうかを判定する。例えば、クライアントが出力部から読み出すレートはリクエストを通じてモニタされる。クライアントが読み出すレートが映像の符号化されたレート未満の場合、サーバ１１０は、オリジナルの符号化された映像フレームを、クライアントの映像デコーダに先のフレームを画面上で複製することを通知する十分に小さく、動的に作成されたフレームに取り替えてもよい。他の実施形態では、サーバ１１０はアルゴリズムを適用してオリジナルの符号化されたフレームを修正し、小さいサイズの新しいフレームを作成する。このアルゴリズムは、映像フレームの全部または一部の再符号化と同様に、オリジナル映像フレームの全部または一部の符号化を含む。この工程は送信された音声および映像全体のレートを下げる。
【００３５】
他の実行可能なデータ修正は、ファイル内からデータストリームまたは他のファイル部分の選択である。コンテンツの複数のストリームを含むデータファイルのために、サーバ１１０は、ストリーム内の送信しないいくつかを動的に選択することができる。例えば、データファイルは１つの映像ストリームと３つの音声ストリームを含んでもよい。ファイルが送出されたとき、３つの音声ストリームの内の１つが映像ストリームと共に送信するために選択される。例えば、サーバ１１０は、最初のファイルから正確なバイトレンジを読み出し、これを出力部に書き込み、各コンテンツ項目が読み出されて出力部に書き込まれるまで後続のファイルに対してこの工程を繰り返す。しかも、他の実行可能なデータ修正はストリーム検索もしくはデータ検索である。サーバ１１０は、１つ以上のファイルからデータを検索するとともに、コンテンツの新しい、動的な、作品 (piece) を作成する。例えば、サーバは１つのファイルからの音声ストリームを他のファイルからの映像ストリームに重ね合わせることを選択することができる。この例では、サーバ１１０は、各ファイルからのチャンクを同時に読み出し、映像および音声ストリームの組を取り出し、ファイルフォーマット特定ストリーム印を、一致した音声および映像の組に適用する。そして、それらの代表的なタイムスタンプによって全てのフレームをソートし、このデータを出力部に書き込む。ストリーム間で音声および映像フレームの数が異なっている場合、サーバ１１０は、空の映像フレーム、ブラック映像フレーム、または他のファイルフォーマット特定構造体で映像をパディングしてもよい。類似のパディング動作は音声ストリームに対しても使用することができる。この工程は、映像および音声コンテンツの総継続時間が各ストリームで同一であることを保証する。データ検索の他の例は、テキストまたはメタデータストリームの混合、例えば、クローズされたキャプションのまたは販売促進のデータを、存在する音声および映像の少なくとも一方のストリームに混合することである。データストリームを加えるため、データストリームのためのインデックス情報、例えばバイトレンジ、は収集されて、結果として生成されたメディアファイルに包含するために好適なフォーマットに変換される。その後、映像フレームおよびデータストリームフレームはこれらの内部タイムスタンプによって格納され、各フレームは引き続き出力部に書き込まれる。この過程は、データおよび映像ストリームの効果的なインターリーブをもたらし、データストリームは映像および音声ストリームに正確に同期することになる。一実施形態では、追加されたデータはサーバによって動的に算出されたメタデータである。メタデータはユーザに有用でないデータであってもよく、再生クライアントによって費やされる。
【００３６】
他の実行可能なデータ修正はデータラッパ (data wrapper) 変換である。異なったコンピュータおよびオペレーティングシステムは異なるファイルラッパおよびフレームラッパフォーマットをサポートする。各ソースファイルのために、オリジナルフォーマットを特定するフレームヘッダおよびフッタは廃棄され、所望のファイルフォーマットを特定する新しいヘッダおよびフッタを生成する。このデータに含まれる各フレームのために、サーバ１１０はオリジナルラッパフォーマットに従ってデータをパースし、圧縮された映像および音声データを抽出し、そしてこのデータを「新しい」ラッパフォーマットを用いて符号化し、このバイトレンジを出力部に書き込む。まださらに、他の実行可能なデータ修正は計算されたデータ挿入であって、ここでは、一実施形態によれば、データが実行中に生成され、供給されたファイルに挿入される。例えば、新しい「ストリーム」が作成され、ファイルヘッダで特定され、このストリームがサーバによって送信される。この例では、各種実施形態によれば、新しいストリームはデータ送信統計値、評判統計値、または、他の計算されたメタデータを含む。
【００３７】
加えて、各フレームのために、音声および映像の少なくとも一方の処理の各種タイプが適用されることができ、例えば、１つ以上の処理アルゴリズムを用いることができる。アルゴリズムは符号化された映像上で直接的に作用し、所望の映像オフセットを作成する。もしくは、サーバ１１０は、映像フレームそれぞれの部分もしくは全体の符号化を行い、部分的もしくは全体的に符号化された映像上で任意の映像変換を行い、部分もしくは全体の符号化を行って結果としてフレームを生成してもよい。各音声フレームは類似の方法で処理してもよい。映像処理および拡張アルゴリズムは周知であって、カラーから白黒への変換、鮮明化、ぼかし、任意の変形、解像度をおとす、および、１つ以上の映像ストリーム間で混合効果のようなことを含む。音声処理工程は、サンプルレートの変更、ピッチシフト、ビットレート調整、エコー、フランジ、クロスフェード、モノラルへの変換、および、ダイナミックレンジ圧縮のようなことを含む。
【００３８】
いくつかの実施形態では、フレームに先立つ変換が適用されて、ファイルが安定して表示される。一実施形態によれば、出力映像アーティクルのタイムスタンプは更新され、最初のフレームはタイムスタンプ０であり、時間と共に増加する。映像と音声とのフレームの継続時間がしばしば等しくないが、個別の映像および音声タイムオフセットがコンテンツインデックス１３０に格納されているため、映像および音声フレーム間は可能な限り小さなオフセットである。従って、映像および音声フレームの再混合は不要である（しかし、要望があれば可能である）。一実施形態によれば、サーバ１１０はまた、同じ作品 (piece) のメディアコンテンツのための複数修正と一緒に、連鎖法によりデータを動的に修正する機能を有する。
【００３９】
部分に対して何らかの修正が施されると（３４０）、部分は出力部に書き込まれる（３５０）。そして、オプションとして、更なる命令が要求されたメディアに対して求められているかどうかが判定される（３６０）。編集リストが更なる命令を含んでいる場合、編集リストの次の命令に従って工程３３０〜３６０は繰り返される。
【００４０】
一実施形態では、サーバ１１０は次に、オリジナルメディアソースファイルから関連する情報のインデックスを含んだフッタを構築し、このフッタを出力部に書き込む。一実施形態では、ソースファイルフッタの領域は読み出され、修正され、ネットワーク送信バッファに書き込まれる。１つ以上のファイル部分が供給されたコンテンツに含まれている場合、最初のソースメディアファイルフッタの領域が先ず読み出され、そして後続のファイルが順次読み出される。データラッパに変換が施されている場合、サーバ１１０はオリジナルラッパフォーマットに従ってフッタをパースし、新しいラッパフォーマットと共に安定するようにフッタを修正する。ヘッダと同様に、所有者フォーマットから基準に準拠したフォーマットへの変換である場合、オリジナルラッパフォーマットは基準に準拠していないフォーマットであり、新しいラッパフォーマットが基準に準拠したものである。
【００４１】
一実施形態によれば、このポイントまで、サーバ１１０の工程は単一のリードスレッドによって実行されている。別個のスレッド、ライトスレッドは、クライアントへの供給のために出力部（ネットワーク送信バッファ）からネットワーク１１５へのデータの書き込みを制御する。ライトスレッドは、ネットワーク送信バッファ内にデータがあるかどうかを判定する。データがある場合、そのデータはネットワークに書き込まれる。ネットワーク送信バッファ内にデータが無い場合、もしくは、バッファがほぼ空の場合、ライトスレッドは更なるデータ、すなわち、リードスレッドによる前述の過程からのデータを要求する。
【００４２】
使用事例
図６は一実施形態に従ったここで説明される方法のための使用事例の一例を示す。この例では、異なるファイル部分からのストリームはインターリーブされている。先立つ工程として、ユーザは、例えばユーザインターフェイスを介して、メディアコンテンツの１つ以上の作品（piece）（"ショット"（shot））をサーバにアップロードする。この例では、ユーザはショット１〜４を含むメディアコンテンツをアップロードする。メディアコンテンツはサーバ上で供給フォーマットにコード変換される。そして、ユーザインターフェイスを用いて、ユーザは選択し、編集し、閲覧のために好適なフォーマットにコンテンツを配置する。この例では、ショット１〜３に関連するコンテンツからの映像の部分、すなわち、ショット１〜３として示される部分を、ショット４に関連する音声の部分、すなわち、ショット４として示される部分とともに含むメディアコンテンツの新しい作品（piece）を作成することをユーザは望む。ユーザインターフェイスソフトウェアは命令を、編集されたコンテンツのためのクライアントからのリクエストの一部として編集リストに変換し、編集リストはサーバに送出される。以下に詳述される工程の後、クライアントはサーバからリクエスト毎に編集されたコンテンツの単一作品 (piece) を受信するはずである。
【００４３】
サーバは、図４Ａ〜図４Ｃと併せて説明されたＵＲＬの形式で、リクエストをクライアントから受信し、リクエストは、ユーザが再生を所望するコンテンツの各作品 (piece)、この例のショット１〜４、のそれぞれのためのコンテンツ識別子と、コンテンツを再生するときの解像度とを含む。リクエストはまた、スタートタイム（例えばコンテンツ内での秒時間）および長さ（例えば秒単位）として特定される、各ショットのための時間範囲を含む。例えば、ショット１では、スタートタイムは１０秒（begin＝１０）で長さは８秒（len＝８）である。リクエストはまた、ショット１〜４から４つのストリームをインターリーブするための命令のリストを参照する編集リストを含み、コンテンツの新しい作品 (piece) はショット１〜３のそれぞれの映像とショット４の音声とを含む。
【００４４】
図３と併せて述べられたように、要求されたメディアコンテンツのソースメディアファイル、この例では、ショット１〜４のそれぞれに対応するもの、が開かれる。この工程を実現するために、リクエストはリードスレッドに送られ、リードスレッドはコンテンツ識別子を用いてコンテンツインデックスを非同期で検索し、特定の時間範囲からスタートバイトオフセットおよびフレーム長を計算し、各ファイルを開く。リードスレッドはまた新しいコンテンツのための新しいヘッダを作成する。
【００４５】
編集リストの命令に順次続いて、メディアコンテンツの次のフレームが送信のために選択される。この例では、サーバは、新しく動的なコンテンツの作品 (piece) を作成することと同時に、４つのファイルからのデータをインターリーブする。具体的に、サーバは１つのファイル（ショット４）からの音声ストリームを選択し、他のファイル（ショット１〜３）からの映像ストリームでインターリーブする。
【００４６】
この例では、図６に示されるように、タイムスタンプ「４１」であるショット４の音声フレームが送信のために選択されて（６０５）、ネットワーク送信バッファに書き込まれる。次に、タイムスタンプ「１１」であるショット１の映像フレームが選択されて（６１０）、出力バッファに書き込まれる。リードスレッドは、編集リストの最後の命令が完了するまで、順次次のフレームを選択し続ける。フレームはリナンバリングされ、コンテンツの新しく作成された作品 (piece) に関連するタイムスタンプは、新しいタイムスタンプから単調に増加する。新しいショットのフレームは、音声および映像フレームがＡおよびＶよりもＡ’およびＢ’に割り当てられているという事実で示されるように、オリジナルショットからのフレームに比べて、ここで説明された各種修正のいずれかを含むことができる。ここで、リードバッファは新しいフッタを構築する。新しいヘッダ、コンテンツ、および、フッタは互いに接合されて、クライアントに供給するための新しい出力ファイルを構築する。ライトスレッドがバッファにデータがあることを検出したとき、データはクライアントに供給するためにネットワークへ送信される。
【００４７】
従って本発明は、インデックスが付されたデータソースファイルの本体からの、オンザフライのサーバによるメディアコンテンツの動的な生成を提供する。本システムおよび方法は、単純で、既存の、オープンプロトコル、例えばＨＴＴＰと、基準に準拠した映像符号化、例えばＭＰＥＧ−４やｈ．２６３とを使用する。供給されたメディアファイルは標準的なメディア再生クライアントによって再生可能である。本方法は、クライアントからのメディアコンテンツのリクエストの一部として受信された編集リストを使用する。サーバは、送信のためにソースメディアファイルの部分を選択し、供給する前にコンテンツを動的に修正する。
【００４８】
本発明は、１つの可能な実施形態に関連して特に詳細に説明されている。当業者であれば、本発明が他の実施形態でも実践できるということを十分理解することができる。第１に、構成要素の特別な命名、タームの大文字化、属性、データ構造、または、他のプログラミングのまたは構成的な局面のいずれかは、必須でも重要でもなく、本発明やその特徴を実施するメカニズムは異なる名前、フォーマット、または、プロトコルを有してもよい。さらに、本システムは、説明されたように、ハードウェアおよびソフトウェアの組み合わせを介して、または、完全にハードウェア部品で実施してもよい。また、ここで説明された各種システムコンポーネント間の機能の特別な区分けは典型例に過ぎず、必須ではなく、機能は、単一のシステムコンポーネントで実行される代わりに、複数のコンポーネントで実行されても、複数のコンポーネントで実行される代わりに、単一のコンポーネントで実行されてもよい。
【００４９】
前述のいくつかの部分は、本発明の特徴を、アルゴリズムのタームおよび情報の動作の記号表示で提示する。これらのアルゴリズムの記述および表示は、データ処理分野の当業者によって利用されることを意味し、これらの動作の本質をこの分野の他の当業者に最も効果的に伝える。これらの動作は、機能的にまたは論理的に説明されている一方、コンピュータプログラムで実現されるはずであることが理解される。さらに、これら動作の割り振りがモジュールとしてもしくは機能的な名前で参照されるということは、普遍性を損なうことなく都合のよいことが折に触れ証明されている。
【００５０】
具体的に主張されているかもしくは先の説明から明らかでない限り、全体を通した説明、例えば「判定する」または「表示する」などのタームを使用した解説が、コンピュータシステムまたは類似の電子計算装置の動作および処理を指しており、このコンピュータシステムは、コンピュータシステムメモリまたはレジスタまたは他の情報記憶装置、送信または表示装置内で、物理的な（電子的な）量として示されたデータの操作および変換をする。
【００５１】
本発明のある局面は、アルゴリズムの形式でここで説明される、処理工程および命令を含む。注意すべきは、本発明の処理工程および命令を、ソフトウェア、ファームウェア、または、ハードウェアで具体化することができるということであり、ソフトウェアで具体化される場合、これらは常駐するようにダウンロードできたり、リアルタイムネットワークオペレーティングシステムを用いて異なるプラットフォームから操作できたりする。
【００５２】
本発明はまた、ここでの動作を実行するための装置に関連する。この装置は必要な目的のために特別に構築してもよく、コンピュータによりアクセスできるコンピュータ読み取り可能な媒体に格納されたコンピュータプログラムによって、選択的に稼働または再構築される汎用コンピュータを備えてもよい。こういったコンピュータプログラムは、例えば、ただし限定されるわけではなく、フロッピー（登録商標）ディスクを含んだあらゆるタイプのディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、特定用途向けＩＣ（ＡＳＩＣ）、または、電子命令を格納するのに好適なあらゆるタイプの媒体であるコンピュータ読み取り可能な記憶媒体に格納してもよく、これら媒体のそれぞれはコンピュータのシステムバスに接続される。さらに、この明細書で参照されるコンピュータは、シングルプロセッサを含んでもよく、または、計算能力を向上するために設計されたマルチプロセッサを採用したアーキテクチャであってもよい。
【００５３】
ここで提示されるアルゴリズムおよび動作は、何らかの特別なコンピュータや他の装置に本質的に関連しているわけではない。各種汎用システムをここでの教示に従ってプログラムと共に使用することができ、または、必要な方法工程を実行するより専門的な装置を構築することが便利であることも証明できる。これらシステムの多様性のための必要な構成は、等価の変化と共に当業者とって明らかである。加えて、本発明は何らかの特別なプログラミング言語を参照して説明されてはいない。プログラミング言語の多様性は、ここで説明されるように、本発明の教示を実現するために使用することができ、特定言語の何らかの参照は本発明の使用可能性および本発明のベストモードのために提供される。
【００５４】
本発明は、多くの配置に基づくコンピュータネットワークシステムの広い多様性に十分適している。この分野では、巨大ネットワークの構成および管理は、例えばインターネットなどのネットワークを介して異種コンピュータおよび記憶装置に通信接続された記憶装置およびコンピュータを備える。
【００５５】
最後に、注意すべきは、本明細書で使用される言語は、可読性および教示用目的のために主として選択され、発明的主題を線引きまたは範囲を定めるために選択されたわけではない、ということである。従って、本発明の開示は、本発明の範囲の実例となるように意図されており、限定されず、特許請求の範囲に示される。
【符号の説明】
【００５６】
１０５ クライアント
１１０ サーバ
１１５ ネットワーク
１２５ ソースファイルデータ記憶装置
１３０ コンテンツインデックス
１３５ キーデータ記憶装置
【技術分野】
【０００１】
本発明は、ストリーミングおよびダウンロードメディアコンテンツの表示および修正に関し、特に、動的に作成および修正されたストリーミングのおよびダウンロードされたメディアコンテンツの供給に関する。
【背景技術】
【０００２】
例えば、メディアコンテンツのクライアントリクエストに応じてサーバからクライアントへインターネットを横断するような、メディアコンテンツのストリーミングおよびダウンロードのための方法が知られている。既存の技術は従来の静的ファイル供給インターフェイスを使用し、このインターフェイスでは完全なファイルがクライアントに供給される。これらの技術は、全部のファイル、または、ファイル内のクライアントから要求されたバイトレンジのいずれかを供給する。ファイルは通常、再生のためのサーバ上で格納もしくはキャッシュされている。一般に、ユーザがこういった方法でメディアコンテンツを閲覧することを望む場合、専用のクライアントはメディアコンテンツの再生のためにダウンロードをする必要があり、専用のプロトコル、フォーマット、および、映像符号化が使用される。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
本発明は、動的に作成および修正されたストリーミングのおよびダウンロードされたメディアコンテンツを供給するための方法およびシステムを提供しようとするものである。
【課題を解決するための手段】
【０００４】
本発明はメディアコンテンツを供給するための方法およびシステムの各種実施形態を提供する。本システムは、インデックスが付されたデータソースファイルの本体からのメディアコンテンツの動的な生成を提供する。本システムおよび方法は、単純で、既存のオープンプロトコル、例えばＨＴＴＰと、基準に準拠した映像符号化、例えばＭＰＥＧ−４やｈ．２６３とを使用する。本システムおよび方法により、コンテンツがクライアントに供給された時点でメディアコンテンツの動的な生成が可能となる。本システムにより、ファイルの部分のためのクライアントからの時間ベースのリクエストが可能となる。供給されたメディアファイルは標準的なメディア再生クライアントで再生可能である。
【０００５】
本方法は、クライアントからメディアコンテンツのリクエストを受信することを含み、リクエストはメディアソースファイルの要旨リストおよび編集リストを含んでいる。サーバは、1つ以上のソースメディアファイルを開き、これらファイルをパースし、編集リストに基づいて送信するフレームまたは他の部分を選択し、続いて、それら部分をクライアントへの供給のための出力ファイルに書き込む。本方法により、要求された時間以降および供給前のコンテンツの動的な修正が可能となり、従って、音声および映像の接合および編集、リアルタイムの広告挿入、暗号化、供給されたコンテンツのレート変更（例えば、スピードアップやスローダウン）などの修正が可能となる。
本明細書の記述は全てを含んでいるわけではなく、特に、図面、明細書、および、特許請求の範囲を考慮すると、多くの付加的な特徴は当業者とって明らかである。さらに、注意すべきは、本明細書で使用される言語は、可読性および教示用目的のために主として選択され、発明的主題を線引きまたは範囲を定めるために選択されたわけではない、ということである。
【図面の簡単な説明】
【０００６】
【図１】本発明の一実施形態に係るクライアントサーバアーキテクチャを示すブロック図。
【図２】本発明の一実施形態に係る前記サーバのさらなる詳細を示すブロック図。
【図３】本発明の一実施形態に係る、メディアコンテンツを供給するための方法を示すフローチャート。
【図４Ａ】本発明の一実施形態に係る、実行可能なＵＲＬを示す図。
【図４Ｂ】本発明の別の実施形態に係る、実行可能なＵＲＬを示す図。
【図４Ｃ】本発明の別の実施形態に係る、実行可能なＵＲＬを示す図。
【図５Ａ】本発明の一実施形態に係るファイルフォーマットの図。
【図５Ｂ】本発明の一実施形態に従ったサンプルＡＶＩファイルの図。
【図６】一実施形態に従ってここで述べられた方法を使用する場合の一例を示す図。
【発明を実施するための最良の形態】
【０００７】
ここで説明される本発明の原理から乖離することなく、ここで示される構成および方法の代替実施形態を使用することができるということを、当業者であれば以下の解説から容易に認識することができるであろう。
ここで、メディアを供給するための方法およびシステムを説明する。ここで使用されるメディアコンテンツとは、あらゆるタイプの映像および音声コンテンツフォーマットを指し、音声のみのフォーマットと同様に、動画ファイル、すなわち、画像および音声を共に含んだファイルを含んでおり、あらゆる形式の音声、映像、メタデータ、またはこれらの組み合わせを含んでもよい。一般例は、２つのインタレース方式のストリーム、１つの映像ストリーム、および、１つの音声ストリームを含んだ映像アーティクルである。しかし、ここで述べられる技術はあらゆる数のファイル部分またはストリームで使用することができ、メタデータを含んでもよい。
【０００８】
方法の一実施形態は、標準的なクライアントサーバアーキテクチャのコンテキストで実施される。図１は、この方法をサポートするために好適なクライアントサーバアーキテクチャを示すブロック図である。このようなシステムは、クライアント１０５およびサーバ１１０を備え、これらは例えばネットワーク１１５によって通信可能なように接続されている。クライアント１０５は、あらゆるタイプのクライアントコンピュータデバイス、例えば、プロトコル（例えばＴＣＰ／ＩＰおよびＨＴＴＰ）に関連したインターネット上で通信をするため、および、ユーザインターフェイスを表示するための少なくとも一方に適合したブラウザアプリケーションや他のアプリケーションを実行する装置であってもよい。一実施形態によれば、クライアント１０５のユーザインターフェイスで、ユーザはメディアコンテンツ部分を閲覧、編集、および選択することができ、これらを整理することができ、その結果ここで説明されるように編集リストの基礎が形成される。クライアント１０５は一実施形態によれば従来通りの設計であり、プロセッサ、アドレス指定できるメモリ、および、他の装備、例えば、表示装置、ローカルメモリ、入出力ポート、ネットワークインターフェイスを含む。他の実施形態では、クライアント１０５の１つ以上の構成要素は遠隔設置して、ネットワーク、すなわち１１５を介してアクセスしてもよい。ネットワークインターフェイスおよびネットワークコミュニケーションプロトコルは、ネットワーク１１５および他のコンピュータ、例えば、サーバ１１０または他のサードパーティコンピュータへのアクセスを提供し、そこでは、インターネットへのアクセスと共に、ＴＣＰ／ＩＰタイプ接続を介し、または、他のネットワークの実例、例えば、ＬＡＮ、ＷＡＮ、ＭＡＮ、有線もしくは無線ネットワーク、専用ネットワーク、仮想ネットワーク、他のネットワークを介して、または、２つもしくはそれ以上のコンピュータシステム間でデータ通信を可能とする他のシステムへのアクセスを提供する。各種実施形態では、クライアント１０５はマイクロソフトオペレーティングシステム（登録商標）、マックＯＳ（登録商標）、リナックス(Linux) （登録商標）系の各種、ＵＮＩＸ（登録商標）、パームＯＳ（登録商標）、および、他のオペレーティングシステムの少なくとも１つを稼働するコンピュータ上で構築するようにしてもよい。単一のクライアント１０５のみが図示されているが、システムは多くのクライアント１０５を用いた多量の並行セッションをサポートすることができる。
【０００９】
一実例では、システムは高性能サーバクラスコンピュータ１１０上で稼働する。サーバ１１０のハードウェア局面の詳細は当業者には周知のものであり、ここではこれ以上説明はしない。サーバ１１０は単一のコンピュータシステムとして図１に描画されているが、システムはコンピュータプロセッサのネットワークとして実現し、記憶装置と関連付けることができる。サーバ装置１１０の例は、サーバ、メインフレームコンピュータ、ネットワークコンピュータ、プロセッサに基づく装置、および、同種のシステムおよび装置である。サーバ装置１１０およびそれに関連付けられた記憶装置は物理的な共同設置を必要としない、しかも、記憶装置およびサーバコンピュータ間のいかなる所定の配置を必要としない。サーバプロセッサは、多数の周知のコンピュータプロセッサ、例えば、カリフォルニア州、サンタクララのインテル株式会社や、イリノイ州、ショウンバーグのモトローラ株式会社によるプロセッサのいずれであってもよい。一実施形態では、サーバ１１０は十分な処理能力および処理量を有し、ここで述べられる提供に先立ってコンテンツの修正を実行する。ネットワーク１１５は、各種実施形態によれば、インターネット単独で構成しても、他のネットワーク、有線および無線の、例えば、イントラネット、ローカルエリアネットワーク、ワイドエリアネットワーク、またはブロードキャストネットワークと組み合わせて構成してもよい。
【００１０】
図２はサーバ１１０の更なる詳細を示すブロック図である。一実施形態では、サーバ１１０は、サーバソフトウェア１２０、ソースファイルデータ記憶装置１２５、コンテンツインデックス１３０、およびキーデータ記憶装置１３５を含む。他の実施形態では、ソースファイルデータ記憶装置１２５、コンテンツインデックス１３０、およびキーデータ記憶装置１３５は、アクセスは可能であるが、サーバ１１０から分離されるか、および、単一のデータ記憶装置を形成するかの少なくとも一方である。サーバソフトウェア１２０は、多くの実行可能なコード部分およびデータファイルで構成される。これらは、ここで述べられる方法を可能とするためのコードを含む。いくつかの実施形態では、サーバソフトウェア１２０は、サーバ１１０の外部でスタンドアロンアプリケーションとして実現することができる。サーバソフトウェア１２０は、本発明の方法に従って実行される処理を調整するための責任を負う。サーバソフトウェア１２０は、本発明の一実施形態によれば、リードモジュール１４０、ライトモジュール１４５、およびバッファモジュール１５０を含む。リードモジュール１４０は一実施形態によればリードスレッド機能を使用可能にするものであって、これを行うための手段である。リードモジュール１４０は、一実施形態によれば、ここで説明されるようなソースメディアファイルアクセス、処理、ヘッダ形成、コンテンツリード、コンテンツ修正、フッタ構築、および出力部への書き込みを制御する。ライトモジュール１４５は一実施形態によればライトスレッド機能を使用可能にするものであって、これを行うための手段である。ライトモジュール１４５は、一実施形態によれば、サーバ１１０が出力部（ネットワーク送信バッファ）からネットワーク１１５へのデータの書き込みを制御できるようにする。バッファモジュール１５０は、一実施形態によれば、ネットワーク送信バッファにデータを配置することで、システムがネットワークに書き込むためのデータの準備できるようにするものであって、これを行うための手段である。バッファモジュール１５０はネットワーク送信バッファの機能を制御する。前述のソフトウェア部分１４０、１４５、１５０は個別のソフトウェアモジュールである必要はない。示されているソフトウェア構成はほんの一例を意味し、他の構成は本発明の範囲でおよび範囲内で考えられる。本発明のこれらの局面によれば、サーバ１１０は、供給のためにコンテンツを複写する必要なく、格納されたコンテンツからメディアコンテンツを直接供給することができる。加えて、供給されたメディアファイルは標準的なメディア再生クライアントで再生可能である。
【００１１】
格納されたメディアコンテンツは、アップロードされた結果として、ユーザによりクライアント１０５から予め受信することができる。他の実施形態では、メディアコンテンツは１つ以上の他のソースから、例えばテレビ放送コンテンツとして受信することができる。メディアコンテンツがサーバ１１０により一旦受信されると、メディアファイルは供給フォーマットにコード変換される。この実施形態では、供給ファイルフォーマットへのコード変換は、メディアファイルを処理すること、メディアファイル内のインデックスを付すことができる部分を識別すること、フレームを列挙して各フレームにタイムスタンプを割り当てること、メディアファイルヘッダおよびフッタをパースすること、および、フォーマット特定のチャンクバウンダリポイントを計算することを含む。メディアコンテンツはソースファイルデータ記憶装置１２５に格納され、該メディアコンテンツに係るデータはメディアコンテンツの帯域外（アウト・オブ・バンド）でコンテンツインデックス１３０に格納されていて、コンテンツ識別子を用いて照会することができる。コンテンツ識別子は、格納されたメディアコンテンツの単一作品 (piece) およびメディアコンテンツに係るデータを一義的に識別する数字識別子であって、例えば、格納されたメディアコンテンツの属性から計算された６４ビットのハッシュ値や、作成されたときにこのコンテンツに割り当てられた任意の数である。識別子は、ファイル名を使用する代わりに、メディアコンテンツの匿名の照会、例えば、プライバシーおよびセキュリティのより一層の提供に用いられる。
【００１２】
ソースファイルデータ記憶装置１２５は、一実施形態によれば、メディアコンテンツデータを格納するリレーショナルデータベースまたは他のいずれのタイプのデータベースであってもよい。サーバ上のメディアコンテンツは、各種形式（例えば、圧縮または非圧縮）で各種ソースから受信することができる。メディアアーティクルは各種方法およびフォーマットで格納することができる。例えば、メディアアーティクルは、ファイルまたは他のデータとしてデータベースまたは他の記憶媒体に格納することができる。メディアアーティクルは、任意の解像度（例えば、ＨＤまたはＳＤ）と同様に、例えば、エムペグ（ＭＰＥＧ−２、ＭＰＥＧ−４）、ウィンドウズ（登録商標）メディア９（Windows（登録商標）Media High Definition Video）、ビデオフォーウィンドウズ（登録商標）（ＡＶＩ）、クイックタイム、インデオなどの任意のフォーマットや、単一のフォーマット（例えば、テレビジョン方式審議委員会（ＮＴＳＣ）、パル方式（ＰＡＬ）、セカムカラーテレビジョン方式（ＳＥＣＡＭ））で格納された映像コンテンツ、または、任意のフォーマットおよび標準のいかなるものでの好適な他の映像コンテンツを含んでもよい。メディアアーティクルは、ブロードキャストに好適であること、および、ネットワーク（例えばインターネット）、パーソナルコンピュータ、または他の計算機または記憶手段を利用可能にすることとの少なくとも一方であって、プログラムガイド情報、メタデータ、および、閉ざされたキャプショニングテキストなどの映像コンテンツに関連した他のデータを含んでもよい。ここで説明される実施形態は映像コンテンツに関して概ね解説され、こうして映像アーティクルと見なされるが、実施形態は、音声のみのコンテンツを含んだ任意の好適な種類のコンテンツで作用してもよい。
【００１３】
一実施形態に従ったファイルフォーマット例は図５Ａに示される。ファイルフォーマットは、ファイルコンテンツ５０２が続く任意のファイルヘッダ、および、任意のファイルフッタを含む。ファイルコンテンツ５０２は０以上のチャンク５０４の一続きを備え、各チャンクは「フレーム」５０６（もしくは、ここで説明されるグループ）の一続きである。各フレーム５０６は、フレームコンテンツ５０８が続く任意のフレームヘッダ、および、任意のフレームフッタを含む。フレーム５０６（またはグループ）は、一実施形態によれば、任意のタイプの、音声、映像、または、メタデータであってよい。他の実施形態では、このモデルは、例えば、アドビフォトスクリプト（商標登録済み）、ＰＤＦ、ｍｐ３のための他のファイルタイプや、他のカスタムファイルタイプに使用することができる。フレームまたはグループ５０６は１つ以上のコンテンツストリームを含む。ストリームは、ファイルフォーマットを含むことで識別されるフレームのセットを指す。例えば、ファイルは０以上の映像ストリームを含んでも、０以上の音声ストリームを含んでもよい。各フレーム５０６は、少なくとも１つのストリームの部分であるとして印を付ける識別子を有する。いくつかのフォーマットはフレームフォーマットタイプに基づいてストリームを暗黙のうちに定義する。
【００１４】
各フレーム５０６は、一実施形態によれば、映像符号化フォーマットおよび符号化パラメータの使用で定義されるように、キーフレームであってもよい。メディアファイルは１つ以上のキーフレームを含む必要があり、チャンクは０以上のキーフレームを含んでもよい。キーフレームは、再生を開始することができるメディアコンテンツのセグメントを許可するために使用される。しかし、多くの音声フォーマットはこういった規制を持たず、個々の音声フレームバウンダリで切り取ることができる。本発明によれば、各フレーム５０６用にタイムスタンプを計算することができる。タイムスタンプは必ずしも物理的な時間である必要はなく、ファイル内の各ストリームの各フレームに割り当てられた任意の単調増加値として考えられるべきである。タイムスタンプが直接利用可能ではない場合、タイムスタンプを映像ファイルのパラメータに従って補間法を介して合成することができる。各フレーム５０６は、データ、典型的な圧縮された音声、圧縮された映像、テキストメタデータ、バイナリメタデータ、または、圧縮されたもしくは圧縮されていないデータの他の任意のタイプのいずれかで構成される。
【００１５】
一実施形態では、ＡＶＩファイルはメディアアーティクルの格納に用いられる。図５Ｂは、一実施形態に係るＡＶＩファイルコンテンツ例を示す。この例では、ＡＶＩファイルは、セグメントに関する基本情報、例えば、幅、高さ、映像フォーマット、音声フォーマット、映像フレーム数、音声フレーム数、映像フレーム長など、を含んだヘッダ５０５を含む。ファイルのバルクはバイトコンテンツ情報５１０を列記する。加えて、ファイルはバイトオフセットなどに関連する情報を含んだフッタ５１５で終了する。この例では、各フレームはキーフレームである。
【００１６】
コンテンツインデックス１３０は、一実施形態によれば、ソースファイルメディアに対応するインデックスが付されたデータを格納するリレーショナルデータベースまたは他の任意のタイプのデータベースであってよい。コンテンツインデックス１３０は、一実施形態によれば、ファイルフォーマット特定のデータ構造であって、この構造は全体的なファイル情報と同様に、ソースメディアファイルヘッダおよびフッタから関連する情報を含む。コンテンツインデックス１３０は格納されたリストのセットとして構成してもよい。コンテンツインデックス１３０は、ファイルの部分である、チャンクにセグメント化されたメディアを格納する。図５Ａに示されるファイル構造と同様に、各チャンクは内部データアクセスのための自身のファイル名を有し、フレームおよびグループの少なくとも一方のセットを含む。各チャンクはコンテンツインデックス１３０の行に関連してもよい。一実施形態では、各列は６４ｋバイトの最大サイズを有し、行識別子で識別され、コンテンツ識別子とフォーマットおよび解像度の映像符号化のための識別子とのハッシュである。この例では、行識別子は複数の列を含み、ここで述べるようにコンテンツインデックス１３０データを指定する。他の実施形態では、メディアファイルの全チャンクのための全てのデータは、１つ以上の列を使用して、単一のデータベース行に格納されている。一実施形態によれば、チャンクインデックスは、各チャンクのために、チャンク識別子番号、チャンクバイトオフセット（ファイルのスタートから）、バイト単位のチャンク長、チャンクスタートタイムスタンプ、および、チャンクエンドタイムスタンプを格納し、さらに、チャンクの各ストリームのために、ストリームフレーム番号、ストリームフレーム数、ストリームスタートタイムスタンプ、および、ストリームエンドタイムスタンプを格納する。本発明のこの局面により、所定のメディアファイルは多くの個別のチャンクに切り離され、これらは個別にまたは一緒に格納され、リードおよびライト性能を最適化する。さらに、フレーム、グループ、または他のファイル部分へのチャンクの分離により、各種ファイル操作（コード変換、解像度など）がフレームまたはグループレベルで実行することができ、システムはこのレベルでの粒度で修正を行うことができる。
【００１７】
コンテンツインデックス１３０はコンテンツ識別子および時間からファイル名、バイトオフセット、および、（映像、音声）フレーム番号およびグループ番号の少なくとも一方をマップする。このマッピングはメディアコンテンツがサーバで受信されたときに作成される。一実施形態では、マッピングは、映像および音声供給内の特定のタイムインデックスポイントをソースファイルの特定バイトにマップする。バイトオフセットは、本発明によれば、音声または映像フレームの開始に関連し、コンテンツインデックス１３０自身はファイル不可知論(file-agnostic)であるフォーマットで、特定ファイルフォーマットとインデックス１３０のメタデータとして格納されるコーデックと共に格納される。従って、コンテンツインデックス１３０は、オリジナルファイルのタイムインデックスポイントの関連位置の表示を提供し、そのバイトにどんなコンテンツ（例えば、音声および映像）が格納されているかが正確に提供される。
【００１８】
一実施形態では、時間からバイトへのマッピングは各映像キーフレームのために存在する。他の実施形態では、時間からバイトへのマッピングは、映像アーティクルの全ての音声フレームおよび映像フレームのために、映像アーティクルの全てのＮフレームのために、または、全てのＮ映像キーフレームのために、情報のサイズ（マッピングの項目数）に関連する制限無く存在する。さらに他の実施形態によれば、時間からオフセットへのマッピングは最も近いグループにマップする。多くの圧縮された映像フォーマットは、画像のグループ（「ＧＯＰ(Group Of Pictures)」、「グループ」）の概念を有し、この画像のグループは映像フレームの原子（および分割できない）セットと考えることができる。映像フレームのこのセットは映像の復号化および再符号化することなく、いかなるポイントでも切り離すことができない。従って、一実施形態では、メディアコンテンツは、フレームレベルよりもグループレベルでアドレス指定される。一般に、音声フォーマットはこういった制限が無く、個々の音声フレームバウンダリで切り離すことができる。各フレームまたはグループは時間で分類され、スタートタイム、音声および映像フレーム番号の少なくとも一方、および、バイトオフセットを含む。言い換えると、いかなるメディアファイルの所定のタイムポイント（もしくは時間範囲）のために、コンテンツインデックス１３０は、その時間に関連する特定のチャンクおよび、それに関連する特定フレームを判定するために使用することができ、これにより必要に応じてそれらを検索することができる。
【００１９】
従って、一実施形態によれば、コンテンツインデックス１３０は、コンテンツ識別子、メディアファイル内のファイル部分またはストリームおよびストリームタイプの数、バイト単位のファイルコンテンツオフセット、バイト単位のファイルフッタオフセット、ストリーム特定の情報（例えば、フレームレート、フォーマット、幅、高さ、継続時間）、ファイルフォーマットの特定フラグ、および、ファイルフォーマット識別子を含む。この例では、インデックスが付されたデータは、前述で参照されたコード変換の結果として利用することができる。加えて、受信した映像ファイルからの他の情報（例えば、幅、高さ、音声および映像フレームレート、音声および映像継続時間、ファイルフォーマット、音声および映像コーデック）はまたコンテンツインデックス１３０に格納してもよい。メディアコンテンツは、複数の個別のインデックス部分のソースファイルに格納される。ここで使用される「部分」とは、ファイルのあらゆるセグメントまたは断片を指し、フレーム、チャンク、グループ、セグメント、または、ここで定義される他の部分を含む。
【００２０】
キーデータ記憶装置１３５は、ＵＲＬ内の暗号化データのためのキーに対応するデータを格納するリレーショナルデータベースまたは他の任意のデータベースであってよい。キーデータ記憶装置１３５は、ユーザインターフェイスを介してサーバソフトウェア１２０によりアクセスすることができる。
【００２１】
サーバソフトウェア１２０、ソースファイルデータ記憶装置１２５、コンテンツインデックス１３０、および、キーデータ記憶装置１３５は、単一のコンピュータ、または、ネットワークを介して互いに通信する個別のコンピュータシステムに格納されて稼働してもよい。
【００２２】
一実施形態におけるサーバ１１０は、例えば、１つ以上のクライアント１０５でアップロードされたメディアコンテンツを格納する。他の実施形態では、メディアコンテンツ、例えばここで説明される映像アーティクルは、例えば遠隔配置されたシステムなどの外部のサーバに格納されてもよい。
【００２３】
図１および図２に示されるシステム構成は単に典型例であり、本発明が多くの他の構成および環境を用いて実践および実現することができる、ということを当業者は認識するはずである。
【００２４】
再び図２を参照すると、一実施形態では、本発明は、映像コンテンツ用の処理クエリのための情報検索システムのコンテンツで動作する。図３は、本発明の一実施形態に係るメディアコンテンツ供給のための方法を示すフローチャートである。この方法は、クライアント１０５からのリクエストがサーバ１１０に格納されたメディアコンテンツのために受信されたとき（３１０）に開始する。このリクエストはサーバ１１０へのネットワークインターフェイスで受信される。サーバ１１０へのリクエストは、ユーザが再生を望むコンテンツのためのコンテンツ識別子、メディアコンテンツを再生するときの解像度、および、時間範囲を含み、これらはスタートタイム（ミリ秒で、もしくは他の時間単位、コンテンツへの）および長さ（ミリ秒または他の時間単位で）として特定される。コンテンツ識別子は、例えば、格納されたメディアコンテンツの属性から計算された６４ビットのハッシュ値や、このコンテンツが作成された時間でコンテンツに割り当てられたランダム値などの、格納されたメディアコンテンツの単一作品 (piece) およびメディアコンテンツに関するデータを一義的に識別する数値識別子である。コンテンツ識別子は、ファイル名を用いる代わりにメディアコンテンツの匿名照会、例えば、プライバシーおよびセキュリティのより一層の提供に用いられる。従来のバイトベースのリクエストに比べて、クライアントからの時間ベースのリクエストが可能となるため、本発明のこういった局面は好適である。
【００２５】
リクエストはまた編集リストを含む。ここで使用される編集リストは、格納されたメディアコンテンツの供給および編集のための動的または静的な命令のリストを参照する。編集リスト命令は、クライアント１０５およびサーバ１１０のいずれか、またはその両方によって加えることができる。例えば、クライアント１０５から受信した編集リストが提供されると、サーバ１１０は、追加の命令をクライアントリクエストコンテンツの先頭に付加、最後に追加、または、挿入することができるか、もしくは、コンテンツの長さ、レート、ストリーム数、ファイルラッパフォーマットを修正することができる。編集リスト命令は、完全なソースファイルの非常に単純な供給から、複雑な修正までに至り、一実施形態によれば、ソースファイルの部分を供給すること、１つ以上のソースファイルの複数の部分を供給すること、ソースファイルまたは部分が供給されるレートを変更すること（スピードアップまたはスローダウンすること）、ソースファイルまたは部分が供給されるレートをクライアントの能力に適合させること、ファイルまたは部分を暗号化すること、ファイルまたは部分にストリームを加えたり取り除いたりすること、異なったファイルまたは部分からストリームをインターリーブすること、データストリームをファイルまたは部分に加えること、ファイルラッパフォーマットを変換すること、所有者ファイルフォーマットを基準に準拠したフォーマットに変換すること、メタデータをファイルまたは部分に挿入すること、および、各種他の修正を含む。各種実施形態によれば、他の可能な修正は、ステレオ音声をモノラル音声に変更すること、カラー映像を白黒映像に変更すること、映像ストリームの解像度を下げること、静止画ストリームの解像度を下げること、映像または静止画ストリームの各種視覚アルゴリズムを実行すること（シャープにする、ぼやかす、変形させる、クロスフェードするなど）、および、各種音声アルゴリズムを実行すること（サンプルレートを変更する、ピッチシフト、レート調整、エコー、フランジをつけるなど）を含む。これらの修正を実現する方法の例は以下の説明に含まれる。
【００２６】
リクエストは、単一のメディアソースファイルからのコンテンツのための、メディアコンテンツの変化した（例えば、切り詰められた）バージョン、または、異なるメディアソースファイルからの作品 (piece) の組み合わせであってよい。１つ以上のファイルの複数の部分を含んだリクエストのために、リクエストは複数の時間範囲を含み、この実施形態によれば、サーバ１１０はコンテンツインデックスに、要求されたタイムスタンプに最も近くにあるチャンクを見つける問い合わせを行う。
【００２７】
リクエストは、図４Ａに示されるように、ハイパーテキスト転送プロトコル（ＨＴＴＰ）リクエスト（または類似の転送プロトコル）であって、ＵＲＬ(Uniform Resource Locator)の形式をとる。ＵＲＬ４００は典型的なフォーマットであって、プロトコル４０５、ホスト（および、妥当であればポート）４１０、および、ソースパスとクエリストリングの少なくとも一方４１５を含む。加えて、編集リスト４２０は、１つ以上のファイル上の動作を実行するための命令の形式で含まれる。図４Ａは単純な例を示し、ここでは時間範囲は唯一のパラメータである。いくつかの実施形態では、ＵＲＬ４００の一部はここで説明されるように暗号化される。図４Ｂは暗号化されたＵＲＬ４２５の一例を示す。ＵＲＬが暗号化された実施形態では、クライアントは暗号化された部分を修正することはできないが、例えば、レートを上げる、ディアコンテンツの小さなサブセットを要求するといった修正をＵＲＬに加えることができる。図４Ｃは、追加の編集リスト命令４３０が最後に付加された、暗号化されたＵＲＬの一例を示す。この例では、コンテンツのためのレートを上げるため（通常速度の１．５倍に）および１０〜５００の時間範囲を選択するために命令が追加されている。一実施形態によれば、クライアント１０５により許可された修正は暗号化された部分を変えない。例えば、ファイルサイズが１０００である場合、１０〜５０００へのリクエストは、サーバにより利用可能な時間範囲に自動的に調整される。
【００２８】
リクエストが受信されると（３１０）、メディアコンテンツリクエストに対応する少なくとも１つのソースメディアファイルが開かれる（３２０）。このためには、リクエストはリードスレッドに送られると、コンテンツ識別子を用いたコンテンツインデックス１３０の非同期検索を行い、特定時間範囲からのバイトオフセットおよびフレーム長を計算し、そしてソースメディアファイルを開く（３２０）。一実施形態では、複数の部分が組み合わされる、もしくは、複数のストリームがインターリーブされた場合、サーバ１１０は、全ての部分に関連する全てのコンテンツ項目のためのコンテンツインデックスの読み出しに先立って、送信される順番にコンテンツ項目をソートする。加えて、サーバ１１０は、関連するヘッダおよびフッタ情報、例えば、映像解像度およびフレームレート、圧縮されたファイルの部分のバイトレンジ、および、他のファイルフォーマットの特定情報、を格納する。データストリームが加えられている場合、サーバ１１０はまた、データストリームのためのコンテンツインデックス情報を読み出し、この情報はストリームに挿入されるタイムスタンプされたデータオブジェクトのリストを含む。タイムスタンプされたデータオブジェクトは任意のバイナリデータ、テキストデータ、または、他のいかなるフォーマットであってもよい。
【００２９】
加えて、一実施形態によれば、コンテンツインデックス１３０に格納されている情報から新しいファイルヘッダが作成され、出力部に書き込まれる。一実施形態では、サーバ１１０は、コンテンツインデックス１３０を調べ、ヘッダ情報を読み出し、および、要求された時間範囲を示すセグメントメディアヘッダを構築する。サーバ１１０は、このリクエストの間に送信されることになっている音声および映像フレームの数を算出する。１つ以上の部分が使用されている場合、サーバ１１０は送信されることになっている全てのコンテンツ項目からフレームの総数としての総数を算出する。コンテンツがスピードアップまたはスローダウンされている場合、送信されることになっているフレーム数は、ソースメディアファイルのフレーム数と異なるはずである。サーバ１１０はまた、一実施形態に従って、オリジナルバイトレンジおよび（映像および音声）フレーム数を指定するデータを最後に追加する。データが暗号化されている場合、クライアントが後続する暗号化されたデータを復号化できるようにするための、暗号化キー、ユーザ識別マーク、または、他の情報をヘッダは含んでもよい。ファイルラッパが変換されている場合、「新しい」ラッパフォーマット（例えば、ラッパが変換されるフォーマット）に従って、サーバは有効なファイルヘッダを作る。ラッパ変換が所有者フォーマットから基準に準拠したフォーマットへのものである場合、例えば、オリジナルラッパフォーマットが基準に準拠したフォーマットではないフォーマットの場合、新しいラッパフォーマットが基準に準拠したそれになる。
【００３０】
ファイルが開かれると（３２０）、いくつか、もしくは、全てのファイルコンテンツが読み出される。
【００３１】
オリジナルソースとして同じファイルフォーマットでメディアファイルを再構築するために、対象である最初および最後の映像および音声フレーム（またはグループ）のバイトオフセットは、セグメントの映像および音声フレームの数と同様に、クライアントに有用でありうる他のあらゆるメタデータと同様に、配置される。加えて、新しいヘッダ（および、フォーマットに妥当であればフッタ）が作成され、互いに接合されて出力ファイルを構築する。
【００３２】
編集リストの命令に基づいて送信するために、メディアコンテンツの個別にインデックスが付された部分が選択される（３３０）。一実施形態では、先の選択（３３０）はソースメディアファイルからの読み出しループの一部であり、そのデータは出力部に書き込まれる。一旦選択されると（３３０）、サーバ１１０はオリジナルメディアソースファイルのバイトレンジを見つけ出し、領域を読み出す。一実施形態では、出力部はネットワークの送信バッファである。一実施形態によれば、クライアントへの供給のために、ネットワークの送信バッファはネットワークへの出力に備えてデータを格納する。
【００３３】
オプションとして、サーバは次に部分を修正する（３４０）。各種修正が可能であり、各修正は編集リストの命令に列挙される。各修正工程は長さを維持してもしなくてもよく、よって、修正処理の各工程後、フレームおよび他の部分はいずれの長さであってもよい。実行可能なデータ修正の１つはデータの暗号化である。フレームまたは部分のそれぞれのコンテンツは要求に先立って生成されたキーを用いて暗号化される。これを実現するため、サーバ１１０はこのコンテンツの各フレームを調べ、標準暗号化アルゴリズムをこれらフレームのいくつかもしくは全てに適用し、暗号化されたデータを出力部に書き込む前に暗号化されたものとしてそれらを明確に示す方法でフレームを修正する。キーは例えばキーデータ記憶装置１３５に格納されており、復号化する目的のため後に検索することができる。暗号化の使用により、追加のデータ、例えば広告対象情報を挿入することができる。他の実行可能なデータ修正は、オリジナル符号化レートと異なったレートにレートを変更することである。例えば、ユーザは、オリジナルコンテンツよりも速く再生されることになっているファイルを送信する「早送り」ストリームまたは部分を要求することができる。早送りを実現するために、一実施形態では、フレームが選択されてソースファイルから取り込まれ、残りのフレームは出力部に通常に、もしくはそれらのタイムスタンプに応じて適合するように書き込まれる。例えば、各映像フレームのために、フレームは廃棄または出力部に書き込まれる。要求されたスピードアップ要因および映像符号化の規定は廃棄されるべきフレーム数を判定する。サーバ１１０はまた、映像ストリームのレートに一致した有効な音声ストリームを構築する必要がある。音声ストリームは、例えば、オリジナル音声の代わりに予め計算された「サイレンス」音声トラックを用いたり、新しい映像レートに一致する音声レートに調整するためのより高性能の音声処理を実行したり、オリジナル音声フレームの一部を廃棄することで構築される。
【００３４】
他の例は、オリジナルソースより低いレートで再生されるデータを送出するようになっている「スローモーション」ストリームもしくは部分である。スローモーションを実現するために、フレームは複製のために選択されるか、もしくは、「パディング」フレームが自動的に複製されたフレームに加えられる。例えば、各映像フレームのために、フレームは無傷で送信されるか、予め送信されたフレームを複製するフォーマット特定の目印がファイル内に配置される。要求されたスローダウンおよび映像の符号化フォーマットの規定は複製されるべきフレーム数を判定し、複製フレームに目印を付けるために送信されるバイトと同様に、フレームを複製することができる。コンテンツのスピードアップと同様に、サーバ１１０はまた、例えば前述したように、映像ストリームのレートに一致する有効音声ストリームを構築する必要がある。他の実行可能なレート変更修正は適応可能なビットレートである。この修正を実現するために、サーバ１１０はクライアント１０５がリアルタイムでの復号化に十分であるレートで映像を受信することができるかどうかを判定する。例えば、クライアントが出力部から読み出すレートはリクエストを通じてモニタされる。クライアントが読み出すレートが映像の符号化されたレート未満の場合、サーバ１１０は、オリジナルの符号化された映像フレームを、クライアントの映像デコーダに先のフレームを画面上で複製することを通知する十分に小さく、動的に作成されたフレームに取り替えてもよい。他の実施形態では、サーバ１１０はアルゴリズムを適用してオリジナルの符号化されたフレームを修正し、小さいサイズの新しいフレームを作成する。このアルゴリズムは、映像フレームの全部または一部の再符号化と同様に、オリジナル映像フレームの全部または一部の符号化を含む。この工程は送信された音声および映像全体のレートを下げる。
【００３５】
他の実行可能なデータ修正は、ファイル内からデータストリームまたは他のファイル部分の選択である。コンテンツの複数のストリームを含むデータファイルのために、サーバ１１０は、ストリーム内の送信しないいくつかを動的に選択することができる。例えば、データファイルは１つの映像ストリームと３つの音声ストリームを含んでもよい。ファイルが送出されたとき、３つの音声ストリームの内の１つが映像ストリームと共に送信するために選択される。例えば、サーバ１１０は、最初のファイルから正確なバイトレンジを読み出し、これを出力部に書き込み、各コンテンツ項目が読み出されて出力部に書き込まれるまで後続のファイルに対してこの工程を繰り返す。しかも、他の実行可能なデータ修正はストリーム検索もしくはデータ検索である。サーバ１１０は、１つ以上のファイルからデータを検索するとともに、コンテンツの新しい、動的な、作品 (piece) を作成する。例えば、サーバは１つのファイルからの音声ストリームを他のファイルからの映像ストリームに重ね合わせることを選択することができる。この例では、サーバ１１０は、各ファイルからのチャンクを同時に読み出し、映像および音声ストリームの組を取り出し、ファイルフォーマット特定ストリーム印を、一致した音声および映像の組に適用する。そして、それらの代表的なタイムスタンプによって全てのフレームをソートし、このデータを出力部に書き込む。ストリーム間で音声および映像フレームの数が異なっている場合、サーバ１１０は、空の映像フレーム、ブラック映像フレーム、または他のファイルフォーマット特定構造体で映像をパディングしてもよい。類似のパディング動作は音声ストリームに対しても使用することができる。この工程は、映像および音声コンテンツの総継続時間が各ストリームで同一であることを保証する。データ検索の他の例は、テキストまたはメタデータストリームの混合、例えば、クローズされたキャプションのまたは販売促進のデータを、存在する音声および映像の少なくとも一方のストリームに混合することである。データストリームを加えるため、データストリームのためのインデックス情報、例えばバイトレンジ、は収集されて、結果として生成されたメディアファイルに包含するために好適なフォーマットに変換される。その後、映像フレームおよびデータストリームフレームはこれらの内部タイムスタンプによって格納され、各フレームは引き続き出力部に書き込まれる。この過程は、データおよび映像ストリームの効果的なインターリーブをもたらし、データストリームは映像および音声ストリームに正確に同期することになる。一実施形態では、追加されたデータはサーバによって動的に算出されたメタデータである。メタデータはユーザに有用でないデータであってもよく、再生クライアントによって費やされる。
【００３６】
他の実行可能なデータ修正はデータラッパ (data wrapper) 変換である。異なったコンピュータおよびオペレーティングシステムは異なるファイルラッパおよびフレームラッパフォーマットをサポートする。各ソースファイルのために、オリジナルフォーマットを特定するフレームヘッダおよびフッタは廃棄され、所望のファイルフォーマットを特定する新しいヘッダおよびフッタを生成する。このデータに含まれる各フレームのために、サーバ１１０はオリジナルラッパフォーマットに従ってデータをパースし、圧縮された映像および音声データを抽出し、そしてこのデータを「新しい」ラッパフォーマットを用いて符号化し、このバイトレンジを出力部に書き込む。まださらに、他の実行可能なデータ修正は計算されたデータ挿入であって、ここでは、一実施形態によれば、データが実行中に生成され、供給されたファイルに挿入される。例えば、新しい「ストリーム」が作成され、ファイルヘッダで特定され、このストリームがサーバによって送信される。この例では、各種実施形態によれば、新しいストリームはデータ送信統計値、評判統計値、または、他の計算されたメタデータを含む。
【００３７】
加えて、各フレームのために、音声および映像の少なくとも一方の処理の各種タイプが適用されることができ、例えば、１つ以上の処理アルゴリズムを用いることができる。アルゴリズムは符号化された映像上で直接的に作用し、所望の映像オフセットを作成する。もしくは、サーバ１１０は、映像フレームそれぞれの部分もしくは全体の符号化を行い、部分的もしくは全体的に符号化された映像上で任意の映像変換を行い、部分もしくは全体の符号化を行って結果としてフレームを生成してもよい。各音声フレームは類似の方法で処理してもよい。映像処理および拡張アルゴリズムは周知であって、カラーから白黒への変換、鮮明化、ぼかし、任意の変形、解像度をおとす、および、１つ以上の映像ストリーム間で混合効果のようなことを含む。音声処理工程は、サンプルレートの変更、ピッチシフト、ビットレート調整、エコー、フランジ、クロスフェード、モノラルへの変換、および、ダイナミックレンジ圧縮のようなことを含む。
【００３８】
いくつかの実施形態では、フレームに先立つ変換が適用されて、ファイルが安定して表示される。一実施形態によれば、出力映像アーティクルのタイムスタンプは更新され、最初のフレームはタイムスタンプ０であり、時間と共に増加する。映像と音声とのフレームの継続時間がしばしば等しくないが、個別の映像および音声タイムオフセットがコンテンツインデックス１３０に格納されているため、映像および音声フレーム間は可能な限り小さなオフセットである。従って、映像および音声フレームの再混合は不要である（しかし、要望があれば可能である）。一実施形態によれば、サーバ１１０はまた、同じ作品 (piece) のメディアコンテンツのための複数修正と一緒に、連鎖法によりデータを動的に修正する機能を有する。
【００３９】
部分に対して何らかの修正が施されると（３４０）、部分は出力部に書き込まれる（３５０）。そして、オプションとして、更なる命令が要求されたメディアに対して求められているかどうかが判定される（３６０）。編集リストが更なる命令を含んでいる場合、編集リストの次の命令に従って工程３３０〜３６０は繰り返される。
【００４０】
一実施形態では、サーバ１１０は次に、オリジナルメディアソースファイルから関連する情報のインデックスを含んだフッタを構築し、このフッタを出力部に書き込む。一実施形態では、ソースファイルフッタの領域は読み出され、修正され、ネットワーク送信バッファに書き込まれる。１つ以上のファイル部分が供給されたコンテンツに含まれている場合、最初のソースメディアファイルフッタの領域が先ず読み出され、そして後続のファイルが順次読み出される。データラッパに変換が施されている場合、サーバ１１０はオリジナルラッパフォーマットに従ってフッタをパースし、新しいラッパフォーマットと共に安定するようにフッタを修正する。ヘッダと同様に、所有者フォーマットから基準に準拠したフォーマットへの変換である場合、オリジナルラッパフォーマットは基準に準拠していないフォーマットであり、新しいラッパフォーマットが基準に準拠したものである。
【００４１】
一実施形態によれば、このポイントまで、サーバ１１０の工程は単一のリードスレッドによって実行されている。別個のスレッド、ライトスレッドは、クライアントへの供給のために出力部（ネットワーク送信バッファ）からネットワーク１１５へのデータの書き込みを制御する。ライトスレッドは、ネットワーク送信バッファ内にデータがあるかどうかを判定する。データがある場合、そのデータはネットワークに書き込まれる。ネットワーク送信バッファ内にデータが無い場合、もしくは、バッファがほぼ空の場合、ライトスレッドは更なるデータ、すなわち、リードスレッドによる前述の過程からのデータを要求する。
【００４２】
使用事例
図６は一実施形態に従ったここで説明される方法のための使用事例の一例を示す。この例では、異なるファイル部分からのストリームはインターリーブされている。先立つ工程として、ユーザは、例えばユーザインターフェイスを介して、メディアコンテンツの１つ以上の作品（piece）（"ショット"（shot））をサーバにアップロードする。この例では、ユーザはショット１〜４を含むメディアコンテンツをアップロードする。メディアコンテンツはサーバ上で供給フォーマットにコード変換される。そして、ユーザインターフェイスを用いて、ユーザは選択し、編集し、閲覧のために好適なフォーマットにコンテンツを配置する。この例では、ショット１〜３に関連するコンテンツからの映像の部分、すなわち、ショット１〜３として示される部分を、ショット４に関連する音声の部分、すなわち、ショット４として示される部分とともに含むメディアコンテンツの新しい作品（piece）を作成することをユーザは望む。ユーザインターフェイスソフトウェアは命令を、編集されたコンテンツのためのクライアントからのリクエストの一部として編集リストに変換し、編集リストはサーバに送出される。以下に詳述される工程の後、クライアントはサーバからリクエスト毎に編集されたコンテンツの単一作品 (piece) を受信するはずである。
【００４３】
サーバは、図４Ａ〜図４Ｃと併せて説明されたＵＲＬの形式で、リクエストをクライアントから受信し、リクエストは、ユーザが再生を所望するコンテンツの各作品 (piece)、この例のショット１〜４、のそれぞれのためのコンテンツ識別子と、コンテンツを再生するときの解像度とを含む。リクエストはまた、スタートタイム（例えばコンテンツ内での秒時間）および長さ（例えば秒単位）として特定される、各ショットのための時間範囲を含む。例えば、ショット１では、スタートタイムは１０秒（begin＝１０）で長さは８秒（len＝８）である。リクエストはまた、ショット１〜４から４つのストリームをインターリーブするための命令のリストを参照する編集リストを含み、コンテンツの新しい作品 (piece) はショット１〜３のそれぞれの映像とショット４の音声とを含む。
【００４４】
図３と併せて述べられたように、要求されたメディアコンテンツのソースメディアファイル、この例では、ショット１〜４のそれぞれに対応するもの、が開かれる。この工程を実現するために、リクエストはリードスレッドに送られ、リードスレッドはコンテンツ識別子を用いてコンテンツインデックスを非同期で検索し、特定の時間範囲からスタートバイトオフセットおよびフレーム長を計算し、各ファイルを開く。リードスレッドはまた新しいコンテンツのための新しいヘッダを作成する。
【００４５】
編集リストの命令に順次続いて、メディアコンテンツの次のフレームが送信のために選択される。この例では、サーバは、新しく動的なコンテンツの作品 (piece) を作成することと同時に、４つのファイルからのデータをインターリーブする。具体的に、サーバは１つのファイル（ショット４）からの音声ストリームを選択し、他のファイル（ショット１〜３）からの映像ストリームでインターリーブする。
【００４６】
この例では、図６に示されるように、タイムスタンプ「４１」であるショット４の音声フレームが送信のために選択されて（６０５）、ネットワーク送信バッファに書き込まれる。次に、タイムスタンプ「１１」であるショット１の映像フレームが選択されて（６１０）、出力バッファに書き込まれる。リードスレッドは、編集リストの最後の命令が完了するまで、順次次のフレームを選択し続ける。フレームはリナンバリングされ、コンテンツの新しく作成された作品 (piece) に関連するタイムスタンプは、新しいタイムスタンプから単調に増加する。新しいショットのフレームは、音声および映像フレームがＡおよびＶよりもＡ’およびＢ’に割り当てられているという事実で示されるように、オリジナルショットからのフレームに比べて、ここで説明された各種修正のいずれかを含むことができる。ここで、リードバッファは新しいフッタを構築する。新しいヘッダ、コンテンツ、および、フッタは互いに接合されて、クライアントに供給するための新しい出力ファイルを構築する。ライトスレッドがバッファにデータがあることを検出したとき、データはクライアントに供給するためにネットワークへ送信される。
【００４７】
従って本発明は、インデックスが付されたデータソースファイルの本体からの、オンザフライのサーバによるメディアコンテンツの動的な生成を提供する。本システムおよび方法は、単純で、既存の、オープンプロトコル、例えばＨＴＴＰと、基準に準拠した映像符号化、例えばＭＰＥＧ−４やｈ．２６３とを使用する。供給されたメディアファイルは標準的なメディア再生クライアントによって再生可能である。本方法は、クライアントからのメディアコンテンツのリクエストの一部として受信された編集リストを使用する。サーバは、送信のためにソースメディアファイルの部分を選択し、供給する前にコンテンツを動的に修正する。
【００４８】
本発明は、１つの可能な実施形態に関連して特に詳細に説明されている。当業者であれば、本発明が他の実施形態でも実践できるということを十分理解することができる。第１に、構成要素の特別な命名、タームの大文字化、属性、データ構造、または、他のプログラミングのまたは構成的な局面のいずれかは、必須でも重要でもなく、本発明やその特徴を実施するメカニズムは異なる名前、フォーマット、または、プロトコルを有してもよい。さらに、本システムは、説明されたように、ハードウェアおよびソフトウェアの組み合わせを介して、または、完全にハードウェア部品で実施してもよい。また、ここで説明された各種システムコンポーネント間の機能の特別な区分けは典型例に過ぎず、必須ではなく、機能は、単一のシステムコンポーネントで実行される代わりに、複数のコンポーネントで実行されても、複数のコンポーネントで実行される代わりに、単一のコンポーネントで実行されてもよい。
【００４９】
前述のいくつかの部分は、本発明の特徴を、アルゴリズムのタームおよび情報の動作の記号表示で提示する。これらのアルゴリズムの記述および表示は、データ処理分野の当業者によって利用されることを意味し、これらの動作の本質をこの分野の他の当業者に最も効果的に伝える。これらの動作は、機能的にまたは論理的に説明されている一方、コンピュータプログラムで実現されるはずであることが理解される。さらに、これら動作の割り振りがモジュールとしてもしくは機能的な名前で参照されるということは、普遍性を損なうことなく都合のよいことが折に触れ証明されている。
【００５０】
具体的に主張されているかもしくは先の説明から明らかでない限り、全体を通した説明、例えば「判定する」または「表示する」などのタームを使用した解説が、コンピュータシステムまたは類似の電子計算装置の動作および処理を指しており、このコンピュータシステムは、コンピュータシステムメモリまたはレジスタまたは他の情報記憶装置、送信または表示装置内で、物理的な（電子的な）量として示されたデータの操作および変換をする。
【００５１】
本発明のある局面は、アルゴリズムの形式でここで説明される、処理工程および命令を含む。注意すべきは、本発明の処理工程および命令を、ソフトウェア、ファームウェア、または、ハードウェアで具体化することができるということであり、ソフトウェアで具体化される場合、これらは常駐するようにダウンロードできたり、リアルタイムネットワークオペレーティングシステムを用いて異なるプラットフォームから操作できたりする。
【００５２】
本発明はまた、ここでの動作を実行するための装置に関連する。この装置は必要な目的のために特別に構築してもよく、コンピュータによりアクセスできるコンピュータ読み取り可能な媒体に格納されたコンピュータプログラムによって、選択的に稼働または再構築される汎用コンピュータを備えてもよい。こういったコンピュータプログラムは、例えば、ただし限定されるわけではなく、フロッピー（登録商標）ディスクを含んだあらゆるタイプのディスク、光ディスク、ＣＤ−ＲＯＭ、光磁気ディスク、リードオンリーメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、ＥＰＲＯＭ、ＥＥＰＲＯＭ、磁気または光カード、特定用途向けＩＣ（ＡＳＩＣ）、または、電子命令を格納するのに好適なあらゆるタイプの媒体であるコンピュータ読み取り可能な記憶媒体に格納してもよく、これら媒体のそれぞれはコンピュータのシステムバスに接続される。さらに、この明細書で参照されるコンピュータは、シングルプロセッサを含んでもよく、または、計算能力を向上するために設計されたマルチプロセッサを採用したアーキテクチャであってもよい。
【００５３】
ここで提示されるアルゴリズムおよび動作は、何らかの特別なコンピュータや他の装置に本質的に関連しているわけではない。各種汎用システムをここでの教示に従ってプログラムと共に使用することができ、または、必要な方法工程を実行するより専門的な装置を構築することが便利であることも証明できる。これらシステムの多様性のための必要な構成は、等価の変化と共に当業者とって明らかである。加えて、本発明は何らかの特別なプログラミング言語を参照して説明されてはいない。プログラミング言語の多様性は、ここで説明されるように、本発明の教示を実現するために使用することができ、特定言語の何らかの参照は本発明の使用可能性および本発明のベストモードのために提供される。
【００５４】
本発明は、多くの配置に基づくコンピュータネットワークシステムの広い多様性に十分適している。この分野では、巨大ネットワークの構成および管理は、例えばインターネットなどのネットワークを介して異種コンピュータおよび記憶装置に通信接続された記憶装置およびコンピュータを備える。
【００５５】
最後に、注意すべきは、本明細書で使用される言語は、可読性および教示用目的のために主として選択され、発明的主題を線引きまたは範囲を定めるために選択されたわけではない、ということである。従って、本発明の開示は、本発明の範囲の実例となるように意図されており、限定されず、特許請求の範囲に示される。
【符号の説明】
【００５６】
１０５ クライアント
１１０ サーバ
１１５ ネットワーク
１２５ ソースファイルデータ記憶装置
１３０ コンテンツインデックス
１３５ キーデータ記憶装置
【特許請求の範囲】
【請求項１】
メディアコンテンツを要求するリクエストであって、編集リストを明記する該リクエストをサーバで受信することと、
前記メディアコンテンツに関連する少なくとも１つのソースファイルを開くことことと、ここで、前記少なくとも１つのソースファイルは個別にインデックスが付された複数の部分に格納されており、
前記少なくとも１つのソースファイルから前記個別にインデックスが付された複数の部分の内の１つを選択して、前記編集リスト内の命令に基づいて送信することと、
前記個別にインデックスが付された複数の部分の内の前記１つを出力部に書き込むことと、
前記個別にインデックスが付された複数の部分の内の前記１つを含むメディアコンテンツをクライアントに供給すること
を備えるメディアコンテンツを供給するための方法。
【請求項１】
メディアコンテンツを要求するリクエストであって、編集リストを明記する該リクエストをサーバで受信することと、
前記メディアコンテンツに関連する少なくとも１つのソースファイルを開くことことと、ここで、前記少なくとも１つのソースファイルは個別にインデックスが付された複数の部分に格納されており、
前記少なくとも１つのソースファイルから前記個別にインデックスが付された複数の部分の内の１つを選択して、前記編集リスト内の命令に基づいて送信することと、
前記個別にインデックスが付された複数の部分の内の前記１つを出力部に書き込むことと、
前記個別にインデックスが付された複数の部分の内の前記１つを含むメディアコンテンツをクライアントに供給すること
を備えるメディアコンテンツを供給するための方法。
【図１】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図４Ｃ】
【図５Ａ】
【図５Ｂ】
【図６】
【図２】
【図３】
【図４Ａ】
【図４Ｂ】
【図４Ｃ】
【図５Ａ】
【図５Ｂ】
【図６】
【公開番号】特開２０１２−２１３１９８（Ｐ２０１２−２１３１９８Ａ）
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願番号】特願２０１２−１２９１６３（Ｐ２０１２−１２９１６３）
【出願日】平成２４年６月６日（２０１２．６．６）
【分割の表示】特願２００８−５４９５９１（Ｐ２００８−５４９５９１）の分割
【原出願日】平成１９年１月４日（２００７．１．４）
【出願人】（５０５２８１０６７）グーグル インコーポレイテッド (58)
【氏名又は名称原語表記】ＧＯＯＧＬＥ ＩＮＣ．
【Ｆターム（参考）】
【公開日】平成２４年１１月１日（２０１２．１１．１）
【国際特許分類】
【出願日】平成２４年６月６日（２０１２．６．６）
【分割の表示】特願２００８−５４９５９１（Ｐ２００８−５４９５９１）の分割
【原出願日】平成１９年１月４日（２００７．１．４）
【出願人】（５０５２８１０６７）グーグル インコーポレイテッド (58)
【氏名又は名称原語表記】ＧＯＯＧＬＥ ＩＮＣ．
【Ｆターム（参考）】
[ Back to top ]