JP2010252327A - マルチ・ユーザ遠隔ビデオ編集 - Google Patents

Abstract

【課題】遠隔ビデオ編集において、ネットワークの帯域幅を低減する。
【解決手段】遠隔ビデオ編集方法およびシステムは、記憶デバイスにおけるソース・メディア・ファイルと、低帯域幅ネットワークを通じて、ソース・メディア・ファイルに関するビデオ編集コマンドを受信する入力とを含む。ソース・メディア・ファイルの仮想表現は、編集コマンドと、ソース・メディア・ファイルへのリンクとを含む。メディア配信エンジンは、ソース・メディア・ファイルを広帯域幅リンクを通じて読み取り、これに編集コマンドを適用し、編集したソース・メディア・ファイルのプロキシ表現を生成し、このプロキシ表現を低帯域幅ネットワークを通じて送信する。また、編集されたメディアのうち、個々の要求されたフレームも出力することができる。
【選択図】図１

Description

関連出願に対する相互引用
本願は、２００９年４月１４日に出願し、"Multi-User Remote Video Editing"（マルチ・ユーザ遠隔ビデオ編集）と題する米国仮特許出願第６１／１６９，１２５号、および２００９年９月３日に出願し"Rendering in Multi-User Video Editing System"（マルチ・ユーザ・ビデオ編集システムにおけるレンダリング）と題する米国仮特許出願第６１／２３９，６００号に対する優先権の利益を主張する。これら双方をここで引用したことにより、その内容は本願にも含まれるものとする。本願は、本願と同じ日に出願され"Rendering in a Multi-User Video Editing System"（マルチ・ユーザ・ビデオ編集システムにおけるレンダリング）と題する米国特許出願第 号に関係がある。この出願をここで引用したことにより、その内容全体が本願にも含まれるものとする。

編集ソフトウェアを実行するコンピュータは、カット、サイズ変更、レイヤリング(layering)、合成(compositing)、タイリング、および／またはルーピングを含むがこれらに限定されない動作を実行することによって、ビデオおよび／またはオーディオを収容するメディアを編集するために用いることができる。ソース・マテリアルは、例えば、種々のフォーマットのうち任意のもので符号化したディジタル・メディア・ファイルとすることができ、その上、アナログ・ソース・メディアでも、ディジタル・ファイルに変換し、編集し、オプションとしてアナログ・フォーマットに変換し直すこともできる。コンピュータを基本とする従前のビデオ編集システムは、一人または複数のユーザに対処するように構成することができるが、各コンフィギュレーションが望ましくない特性を有する場合もあり得る。単一ユーザ編集システムは、例えば、ユーザ間において協調や資源共有ができず、利用度が過小となる虞れもある。即ち、一人のユーザが編集動作を実行していない間、アイドル状態となっている可能性があり、あるいは実行中の編集動作が計算コストが多大でない場合にはほぼアイドル状態となっている場合がある。単一ユーザ編集システムは、ユーザが実行する可能性がある最も複雑な編集タスクでも処理できる程にロバストでなければならないので、そしてこのロバスト性には出費が伴うこともあるので、単一ユーザ・システムに少しでもアイドル時間が生ずると、システムに投資した資金が無駄になることになる。

他方で、マルチ・ユーザ・システムは、集中配置したメディアを複数ユーザに共有させることができる。例えば、ファイル・サーバは、メディア・ファイルの１つのコピーをホストし、ローカル・エリア・ネットワークを通じて接続されている複数クライアント・ワークステーションにそれを配信することができる。あるいは、ｈｔｔｐサーバは、インターネットを通じて接続されている複数クライアント・ワークステーションにメディア・ファイルをストリーミングすることができる。いずれの場合でも、メディア・ファイルの集中格納が、ビデオ編集アプリケーションの全体的効率を高めることができる。しかしながら、従前のマルチ・ユーザ編集システムには様々な欠点がある。１つには、これらは、メディア・ファイルをホストし配信するための強力なサーバと、実際の編集を実行する強力なワークステーション・クライアントとの双方を必要とする。ワークステーション・クライアントは、前述の単一ユーザ・システムと同様、複雑な編集タスクを処理するためには十分にロバストでなければならないものの、所与のワークステーションにおけるユーザが常にクライアントの最大パワーを用いる訳ではないので、過小利用に陥る虞れがある。更に、ファイル・サーバまたはｈｔｔｐサーバは、ファイルまたはストリームをクライアントに送る前に、それらをインテリジェントに処理する能力に欠ける。例えば、複雑なプロフェッショナル品質の編集プロジェクトでは、様々なオーディオおよびビデオ・クリップを同時に一緒に積層して、合成メディアを作成する。しかしながら、このファイル・サーバまたはｈｔｔｐサーバは各レイヤの全体を要求元のクライアントに送信しなければならず、これによって、更にシステムに負担がかかることになる。

従前のマルチ・ユーザ・システムの別の欠点は、これらが大量のネットワーク帯域幅を必要とすることである。「オンライン」編集、即ち、クライアントによるソース・メディア・ファイルの直接変更では、クライアントが最初にソース・メディア・ファイル全体をサーバからローカル・ストレージにダウンロードし、編集が完了したときにメディア・ファイルをアップロードすること、またはクライアントが、ネットワーク接続されたファイル・システムを通じて、ソース・メディア・ファイルにアクセスすることのいずれかを必要とする。いずれの場合でも、サーバとクライアント間で大量のネットワーク・トラフィックが発生するので、非常に高い帯域幅およびコストのかかるクライアント／サーバ・ネットワークが必要となる。このトラフィックの一部を軽減するために、従前のマルチ・ユーザ・システムは「オフライン」編集を用いることもできるが、その場合、本来のサイズが大きいメディア・ファイルの代わりに、ソース・メディアのサイズを縮小したコピー（「プロキシ」）を発生し、クライアントに送る。クライアントは、このプロキシを編集することができ、プロキシに対して実行される一連の編集コマンド（「タイムライン」）をソース・メディアに適用（即ち、「再リンク」）することができる。しかしながら、オフライン編集には、これらのプロキシを発生するために要する時間、処理資源、およびストレージの浪費に加えて、プロキシを送信および編集するためになおも多大な量のネットワークおよびクライアント処理パワーが必要となるという欠点がある。更に、ユーザがオフライン・プロキシを編集している時間中、ソース・メディアは、例えば、元のメディアを置換すること、または新しいソース・メディアをプロジェクトに追加することによって変化する場合があり、つまり以前に発生したプロキシを追跡し、これらを元のメディアと連続的に同期させるという厄介な作業が必要となる。最後に、ある種のハイ・エンド効果のような複雑な編集機能は、オフラインでは実行することができず、オンラインで実行しなければならない。

更に、従前のリモート・アクセス・ビデオ・システムは、一般に、ビデオ編集に必要とされる、ソース・メディアの正確、高速なフレーム毎の制御ができない。殆どのビデオ符号化方式は、異なる形式のフレームを用いており、それらの全てが自己充足という訳ではない(self-contained)。例えば、所与のフレームが、符号化ピクチャ内・フレーム(intra-coded picture frame)即ちＩ−フレームとして知られている、最大仕様ピクチャ・フレームである場合がある。しかしながら、他のフレームは最大仕様ではなく、代わりに、現フレームと最後のＩ−フレームとの間の差を捕らえるものであることもある。これらのフレームは、予測ピクチャ・フレーム（「Ｐ−フレーム」）または二回予測ピクチャ・フレーム(bipredicted-picture frame)（「Ｂ−フレーム」）として知られている。ユーザが要求したフレームが偶然Ｐ−フレームまたはＢ−フレームである場合、編集アプリケーションは直前のＩ−フレームまで逆戻りし、次いで中間にあるＰ−フレームおよびＢ−フレームを経て順方向に辿らなければならず、こうして要求されたフレームを再現する。しかしながら、この動作を高速に実行するには、メディア・ファイル全体へのローカル・アクセスが必要となり、従前のリモート・アクセス・システムにとって、これはメディア・ファイル全体をダウンロードすることを意味し、これによって、前述したネットワーク帯域幅の不利益(penalties)を招くことになる。ソース・メディア・ファイルに対するローカル・アクセスを行わないと、リモート・クライアントは、要求されたフレームが専有するメディア・ファイルにおける位置を推定するが、推定における誤差があるとそのいずれもが、フレーム・シーク時間において時間的な不利益を招く。

前述の欠点の多くは、ＨＤＴＶのように、ビデオ・フォーマットの分解能が高くなる程悪化する。分解能が大きい程、そして対応するＨＤＴＶ状メディア・ファイルのファイル・サイズが大きい程、分析するための処理パワー増大、および伝達するためのネットワーク帯域幅拡大が必要となる。この傾向は、ビデオ信号の分解能および品質が高くなる限り続くこととなり、クライアント処理パワーの一層の増量およびネットワークの高速化が必要となる。メディア・ファイル・サイズとクライアント処理パワー／ネットワーク帯域幅との間の依存性を低減または解消する、協調的マルチ・ユーザ・ビデオ編集システムが求められていることは明らかである。

概説すると、本明細書において記載するシステム、方法、および装置は、ビデオ編集タスクの集中処理に対する解決策を提供する。本発明の実施形態は、高速リンクを通じてローカル・ストレージに接続されているアプリケーション・サーバと、サーバに離れて接続されている１つ以上のシン・クライアントとを含む。ユーザは、シン・クライアントを通じて、サーバに配置されているメディアにアクセスする。ユーザが元のメディアの特定部分、クリップ、またはフレームを見たい場合、サーバはメディアのその部分にアクセスし、そのサイズを縮小し、実行中に、即ち、要求に対するリアル・タイムの応答として、それをシン・クライアントに配信することができる。ユーザがシン・クライアントを用いてメディアを編集するとき、編集コマンドを表す一連の低帯域幅命令がサーバに向けて返信される。アクティブな聴取エージェント(listening agent)を用いて、サーバはこれらのコマンドを実行し、その実行を反映させてストリームを更新し、クライアントに送り返す。このように、本明細書に記載する発明の実施形態は、費用のかかるクライアント側処理の必要性を低減または解消し、クライアント／サーバ・ネットワーク・リンクにかかる負担を低減する。

概説すると、一態様において、遠隔ビデオ編集システムは、ソース・メディア・ファイルを格納する記憶デバイスと、低帯域幅ネットワークを通じて、ソース・メディア・ファイルに関するビデオ編集コマンドを受信する入力と、ソース・メディア・ファイルの仮想表現であって、編集コマンドと、ソース・メディア・ファイルへのリンクとを備えている、仮想表現と、高帯域幅リンクを通じてソース・メディアを読み取り、編集コマンドをこれに適用し、編集したソース・メディア・ファイルのプロキシ表現を生成するメディア配信エンジンと、プロキシ表現を低帯域幅ネットワークを通じて送信する出力とを含む。

種々の実施形態は、以下の特徴の１つ以上を含む。メディア配信エンジンは、ストリーミング・エンジンであり、プロキシ表現はメディア・ストリームである。本システムは、複数の仮想表現を備えており、仮想表現の各々が、複数組の編集コマンドのうち１つを備えている。本システムは、複数の仮想表現の各々を複数の処理デバイスの１つに割り当てる負荷均衡モジュールを含む。複数のビデオ編集コマンドは、同時に仮想表現に適用される。低帯域幅ネットワークは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、またはインターネットのうち１つである。メディア配信エンジンは、低帯域幅ネットワークにかかる負荷、または高帯域幅リンクにかかる負荷のうち少なくとも１つに応答して、プロキシ表現の帯域幅を調節する。本システムは、更に、サービスの中断から復元するためのウオッチドック・モジュールを含む。

概説すると、別の態様では、遠隔ビデオ編集システムは、メディアのプロキシ表現を受信する入力と、プロキシ表現を復号化するプロセッサと、復号化したプロキシ表現によって表されるコンテンツを表示するグラフィカル・ユーザ・インターフェースと、プロキシ表現を編集するためのコマンドの入力を容易にするユーザ入力と、編集コマンドと送信する出力と、を備えているクライアントと、編集コマンドを受信し、該編集コマンドをソース・メディア・ファイルに適用し、ソース・メディア・ファイルおよび編集コマンドに応じてプロキシ表現を発生するサーバとを含む。

種々の実施形態は、以下の特徴の１つ以上を含む。クライアントはシン・クライアントである。クライアントは、デスクトップ・コンピュータ、ワークステーション、ラップトップ・コンピュータ、ノートブック、およびスマートフォンのうちの１つである。

概説すると、更に別の態様では、ビデオ・ファイル遠隔編集方法は、サーバにおいて、リモート・クライアントからのビデオ編集コマンドを受信するステップと、サーバにおいて、受信したコマンドに応じてメディア・ファイルの仮想表現を変更するステップであって、仮想表現が、記憶デバイスに格納されているソース・メディア・ファイルに対する参照を含み、記憶デバイスが高速リンクを通じてサーバに接続されている、ステップと、リモート・クライアントに、編集コマンドによって変更されたソース・メディア・ファイルを含むデータ・ストリームを送信するステップとを含む。

種々の実施形態は、以下の特徴の１つ以上を含む。本方法は、更に、複数のリモート・クライアントから、テキストベースのビデオ編集コマンドを受信するステップを含む。サーバは、低帯域幅ネットワークを通じて、クライアントに接続されている。低帯域幅ネットワークは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、またはインターネットとすることができる。

概説すると、更に別の態様では、ビデオ・フレームをリモート・クライアントに送る方法は、サーバにおいて、リモート・クライアントからビデオ・フレームの要求を受けるステップと、メディア・ファイルを検索して、要求されたフレームを求めるステップであって、メディア・ファイルが、高速リンクを通じてサーバに接続されている記憶デバイスに格納されている、ステップと、サーバからビデオ・フレームをクライアントに送るステップとを含む。

種々の実施形態は、以下の特徴の１つ以上を含む。要求されたビデオ・フレームは、Ｐ−フレームおよびＢ−フレームのうちの１つである。本方法は、更に、メディア・ファイルにおいて逆方向にＩ−フレームまでシークし、要求されたフレームを再現するステップを備えている。サーバは、低帯域幅ネットワークを通じて、クライアントに接続されている。

図１は、マルチ・ユーザ遠隔ビデオ編集システムの上位ブロック図である。 図２は、図１のマルチ・ユーザ遠隔ビデオ編集システムにおけるサーバとクライアントとの間の相互作用を示すブロック図である。 図３は、ビデオ編集プロジェクトの概念的表現である。 図４は、図１のマルチ・ユーザ遠隔ビデオ編集システムにおけるクライアントのためのグラフィカル・ユーザ・インターフェースのスクリーン・ショットである。 図５は、図１のマルチ・ユーザ遠隔ビデオ編集システムにおけるクライアントによってアクセス可能な最上位アプリケーション・ウィンドウの図である。 図６は、マルチ・ユーザ・ビデオ編集システムのサーバ・アーキテクチャを示す。 図７は、フレーム毎ストリーミングに含まれるステップを示す流れ図である。

本明細書に記載するのは、ビデオおよびオーディオのような、時間基準メディアの集中編集のための方法、システム、および装置である。一実施形態では、メディア・ファイルの処理および格納をサーバに集中化し、クライアントは普通のネットワーク接続を通じてこのサーバにアクセスする。クライアントは、大量の処理要求をサーバに頼るように構成することができる（即ち、これらは「シン・クライアント」として構成することができる）。サーバは、実行中に、ソース・メディア・ファイルのサイズを縮小し、低帯域幅の部分を作成し、作成した部分の個々のフレームまたはストリーム部分を、要求に応じて、クライアントに配信することができる。一方、クライアントは低帯域幅編集コマンドをサーバに向けて逆方向に送信する。言い換えると、最初にソース・メディア・ファイルのプロキシ・コピー全体をクライアントにダウンロードする代わりに、サーバは、クライアントにおいて現在見られているおよび／または編集されているソース・メディア・ファイルの部分のみを配信する。つまり、編集を開始することができるようになる前に、時間がかかり帯域幅を大量に用いるダウンロードが完了する迄待つ必要はない。

図１は、本発明によるクライアント／サーバ・アーキテクチャの一実施形態を示す。サーバ１０２は、高帯域幅リンク１０６を通じてストレージ・コントローラ１０４に接続されており、このストレージ・コントローラは、１つ以上の記憶デバイス１０８を管理する。広帯域幅リンクは、Fibre Channel、InfiniBand、または１０Ｇｂイーサネット（登録商標）というようなプロトコルを用いて実現することができ、毎秒ギガビット単位の帯域幅をサポートすることができる。サーバは、１つ以上の離れて位置する複数クライアント１１０と、低帯域幅ネットワーク１１２を通じて通信する。この低帯域幅ネットワークは、例えば、イーサネット（登録商標）またはワイヤレス・ネットワーク（毎秒メガビット単位程度の帯域幅に制限される）あるいはインターネット接続（毎秒１メガビット未満の帯域幅に制限される）とするとよい。サーバは、１つのデバイスでも、並列に接続されている複数のデバイスでもよい。実施形態によっては、サーバは、既知のアドレスを有する専用マシンである場合もある。他の実施形態では、サーバは、ネットワークを通じてアクセスされる１つ以上のマシンを備えており、例えば、「クラウド」においてリースされる計算および記憶資源の一部をなすサーバである。他のサーバ構成も可能である。一実施形態では、サーバはビデオ編集アプリケーション・サーバである。ストレージ・コントローラおよび記憶装置は、直接接続ストレージまたはネットワーク接続ストレージのような、数ある市販のストレージ提案のうち任意のものでよい。

高帯域幅ネットワーク１０６は、システムの要件に応じて、個々の実現例における使用に合わせて最適化することができる。例えば、大きな記憶ボリュームを必要とするが転送速度が遅くても許容できるアプリケーションには、速度を遅くして価格を抑えたストレージの提案を用いることができる。高分解能のメディア・ファイルを用いるシステムおよび／または多くのユーザを有するシステムには、速度を高めたストレージが適している場合もある。

低帯域幅ネットワーク１１２は、サーバとストレージの間において、高帯域幅リンクよりもスループットが低くてもよく、したがって安価に実現することができる。低帯域幅ネットワークの帯域幅には上限はないが、適したネットワークであれば任意のものを用いることができる。種々の実施形態において、低帯域幅ネットワークは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、および／またはインターネットである。低帯域幅ネットワークにおけるサーバとクライアントとの間の通信は、交換機のような、専用目的デバイスによって管理することができる。ハードウェアおよび／またはソフトウェアで実現されるルータを用いて、インターネット上でクライアントに通信することもできる。

クライアント１１０は、しかるべきタイプの計算デバイスであれば任意のものでよく、デスクトップ・コンピュータ、ワークステーション、ラップトップ・コンピュータ、ノートブック、およびスマートフォンが含まれるがこれらに限定されるのではない。クライアントはシン・クライアントとなるように構成されているので、クライアント側編集アプリケーションを実行するために要求される処理パワーは最小で済む。一実施形態では、クライアント側アプリケーションは、Microsoft社のINTERNET EXPLORER、Mozilla FIREBOX、またはApple社のSAFARIのような標準的なウェブ・ブラウザの内部で実行し、Java（登録商標）またはFlashのような、ブラウザ埋め込み可能言語で実装される。したがって、クライアントは、標準的なウェブ・ブラウザを実行することができる計算デバイスであれば任意のものでよい。別の実施形態では、クライアント側アプリケーションは、特定のオペレーティング・システムおよび／またはデバイスにネーティブな単体アプリケーションとして実装される。

一実施形態では、本発明の実装(installment)は、ネットワークによってローカルに（例えば、同じ建物またはキャンパス内に）接続されているサーバ、ストレージ、およびシン・クライアントを含む。別の実施形態では、本発明の実装は、シン・クライアントのみを含む。この実施形態では、シン・クライアントは、インターネットを通じて、離れて位置するサーバに接続する。このサーバは、別個のエンティティ、人間、会社、および／または組織から接続するシン・クライアントをホストすることができる。

図２は、サーバ１２０とクライアント２０２との間における基本的な相互作用を概念的に示す。このサーバは、元のメディア・ファイル２０４と、メディア・ファイルを編集および合成し、更にメディア・ファイルの任意の時点におけるコンテンツの実行中プロキシ表現を発生するエンジン２０６を含むことができる。サーバは、このプロキシ表現をクライアントに、低帯域幅ネットワーク１１２を通じて送信し、ユーザはメディア・ビューア２０８を用いてクライアントにおいてこのプロキシ表現を見ることができる。一実施形態では、プロキシ表現はストリームであり、メディア・ビューアはメディア・ストリームを表示する。一実施形態では、クライアントは、ユーザの編集コマンドを受け入れるために編集グラフィカル・ユーザ・インターフェース（「ＧＵＩ」）２１０を含む。ユーザによって入力されたコマンドは、サーバに向けて逆方向に送信することができ、サーバはコマンドを編集済みメディア・プロジェクト・ファイル２１２の中に収集し、それに応じて出力するメディア・ストリームを調節する。元のメディア・ファイル全体も、その任意の縮小サイズ・バージョン全体もクライアントに送信する必要はなく、クライアント自体はいずれの編集コマンドも処理しなくてもよい。

図３を端的に参照すると、サーバおよびクライアントの機能をより良く説明するために、編集プロジェクトの概念的表現が示されている。この例では、５つのメディア・クリップが、図示のように、ｙ−軸上の異なる４つのレイヤ上に配列されている。これらのメディア・クリップは、１つ以上のソース・ファイルの部分を表し、各クリップはオーディオおよび／またはビデオを収蔵することができる。時間は、ｘ−軸（「タイムライン」）上に表され、ビデオのフレームにしたがって線引きすることができる。編集プロジェクトを最初に再生すると、時刻ｔ＝０において開始するが、クリップは表示されない。しかしながら、時刻ｔ＝ｔ１において、クリップ１および４双方が再生を開始する。例えば、各クリップのコンテンツおよび不明瞭さ(opacity)に応じて、クリップ１、クリップ４、または２つのクリップの何らかの組み合わせのいずれかを見ることおよび／または聞くことができる。クリップ３が時点ｔ＝ｔ２において追加され、クリップ４は時刻ｔ＝ｔ３において終了する。各クリップの開始および終了は、遷移効果、たとえば、フェードによって遂行することができる。セッションの残りは、しかるべく再生される。

図２に戻って、一実施形態では、サーバは元のメディア・ファイルをホストする。メディア・ファイルは、ＭＰＥＧ、ＤＶ、ＷＭＶ、およびＨ．２６４のような、種々のフォーマットのうち任意のもので伸張、圧縮、および／または符号化されたオーディオおよび／またはビデオ・データを表すことができる。種々の実施形態では、メディア・ファイルは標準品位（「ＳＤ」）ビデオ信号（例えば、７２０×４８０画素の分解能を有する）、高品位（「ＨＤ」）ビデオ信号（例えば、１９２０×１０８０画素、１２８０×７２０画素の分解能、又はその他のＨＤ分解能を有する）、または２Ｋ分解能フィルム走査マテリアル（例えば、２０４８×１５５６画素の分解能を有する）を表す。

元のメディア・ファイルは、一人または複数のユーザによるアクセス時にロック・アップ(lock up)しなくてよい。逆に、編集プロジェクトが元のメディア・ファイルを変更せずにこれを参照するので、複数のユーザが同じ元のメディア・ファイルを並行して用いることができる。更に、複数のユーザは、元のメディア・ファイルがストレージに採集（コピー）されている間であっても、これらのメディア・ファイルを編集および／または参照することもできる。一実施形態では、編集システムは、既に格納されているメディア・ファイルの部分への排他的アクセスを自動的に管理し、したがって、生のニュースのメディア・ファイルの供給(feed)のように、採集の間に編集する編集能力を備えている。

実行中(on-the-fly)メディア配信エンジン２０６は、クライアントからの入力に応答して、メディア・ファイルのうち要求された部分にアクセスし、これをクライアントに流すことができる。メディア配信エンジンは、クライアントがメディアをリアル・タイムで見るために必要なオーディオおよびビデオの特定のフレームのみを送ることができる。一実施形態では、サーバはストリーミング・データを予め発生せず、代わりに、ユーザの要求を受ける毎に、オン・デマンドでデータを発生する。例えば、ユーザが、クライアントを通じて、あるメディア・ファイルのフレーム５０を選択または「シーク」し、このメディアをその位置から先に再生することを要求した場合、サーバは元のメディア・ファイルのそのフレームにアクセスし、フレーム・データをしかるべきストリーミング・フォーマットに変換し、変換したストリーミング・データをクライアントに送り始める。一旦ストリーム・データがクライアントに送られたなら、サーバはそのコピーを保持しなくてもよい。代わりに、例えば、ユーザがシークしてフレーム５０に戻り、そのフレームの再生(replay)を要求した場合、サーバは単にストリーミング・データをソース・メディア・ファイルからそのフレームにおいて再度発生し、それを再度クライアントに送る。

サーバ上に格納されているメディア・ファイルの表現をストリーミングすることの代案として、他のプロキシ表現を発生し、低帯域幅ネットワーク１１２を通じてクライアントに送ることもできる。例えば、ビデオの個々のフレームを、ＪＰＥＧ画像として送ることができ、あるいはビデオ・ファイルの一部を一連のＪＰＥＧ画像として送ることもできる。

サーバ１０２は、ストリーミング・データのサイズを変更してから、それをクライアントに送ることができる。前述のように、元のメディア・ファイルは、高分解能フォーマットで符号化することができ、そのリアル・タイム・ストリーミングには、非常に速く費用がかかるネットワーク・リンクが必要となる。ストリームのサイズを変更してからこれを送ることによって、サーバは、クライアント／サーバ・ネットワークに要求されるスループットを低下させて、ロバスト性が低いネットワークの使用にも対処することができる。一実施形態では、クライアントはサイズ変更のレベルを調節することができる。サイズが大きい程、例えば、クローズ・アップや詳細の編集に適しており、一方サイズが小さい程、粒が粗い(coarse-grained)編集コマンドに適していると言える。一実施形態では、ユーザは実行中、即ち、編集セッションの間にストリームのサイズを調節し、視認したストリームの詳細を具体的な編集コマンドに合わせてカスタム化すること、および／またはネットワーク・レイテンシの可変性に対処することができる。

また、サーバはユーザの編集済みメディア・プロジェクト２１２も含むことができる。このプロジェクトは、図３に示す編集プロジェクトのように、１つ以上のソース・メディア・ファイルの編集済みバージョンを収蔵することができる。しかしながら、ソース・メディア・ファイルを実際に変更する代わりに、ユーザ特定プロジェクトの仮想表現を作成することもできる。この「時間基準オブジェクト」は、ユーザの変更および編集に関する情報の全てを収蔵することができ、例えば、１つまたは複数のソース・ファイルの名称、レイヤの数、レイヤ上におけるソース・ファイルの配置、クロッピング(crop)、カット、編集、および同様の情報が含まれる。ユーザの編集プロジェクト毎におよび他のユーザのプロジェクトのために、別個の時間基準オブジェクトを作成することもできる。

種々の実施形態では、時間基準オブジェクトは、例えば、拡張可能マークアップ言語（「ＸＭＬ」）で書かれたテキストベースのファイル、または編集判断リスト（「ＥＤＬ」）ファイルとして書かれた、テキストベースのファイルとして表される。時間基準オブジェクトは、更に編集するために保存すること、他のユーザと共有すること、および／または通常のメディア・ファイルであるならば再生することもできる。任意の数のユーザが、各々異なる、複数の同時時間基準オブジェクトを作成することができ、各時間基準オブジェクトは同じソース・メディア・ファイルまたは異なるメディア・ファイルを参照することができる。

ユーザの要求時に、サーバは時間基準オブジェクトを、.mpg、.dv、または.aviファイルのような、モノリシック・メディア・ファイルにエクスポートすることができる。エクスポートされたメディア・ファイルは、次に、視聴者に配信することができる。視聴者は、記載しているクライアント／サーバ・ネットワークのドメインの外部におり、サーバにおける元のメディア・ファイルまたはメディア・ファイル群にアクセスすることができなくてもよい。例えば、エクスポートされたメディア・ファイルをＤＶＤにコピーすること、またはインターネット接続を通じて配給する(serve)こともできる。しかしながら、実施形態によっては、本発明の実現例は、エクスポートされるファイルを全く作成することなく、時間基準オブジェクトの生産品質コピー(production-quality copies)を視聴者に向けてストリーミングすることもできることを記しておく。例えば、テレビジョン・ニュース局が、元のソース・メディアおよび時間基準オブジェクトに収蔵されている編集情報のみを用いて、編集したニュース・ストーリーを直接サーバからブロードキャストすることもできる。

一実施形態では、サーバは時間基準オブジェクトの中にある任意のレイヤを「合成」(composite)または平坦化(flatten)してから、そのコンテンツをクライアントに宛ててストリーミングする。こうすることによって、レイヤが任意の数および複雑度を有する場合であっても、これらのレイヤを既知のサイズのストリームに縮約する。一実施形態では、合成ストリームに必要とされる帯域幅は、約８００ｋｂ／ｓから１Ｍｂ／ｓである。しかしながら、クライアントが合成ストリームを見ていても、クライアントは、ストリームが平坦化されていないかのように、時間基準オブジェクトの中にあるレイヤを操作することができる。元のレイヤ情報は、クライアントおよび／またはサーバにおいて維持することができ、クライアントが既存のレイヤを編集すると、レイヤ情報が更新され、サーバは、それに応じて、クライアントに送られるレイヤ・データを調節する。

ここでクライアントに移ると、メディア・ビューア２０８は、サーバから送られるストリーム・データまたは個々のフレームを復号化および表示するために用いることができる。サーバは、元のソース・メディアの低帯域幅の縮小サイズ・バージョンを送ることができるので、ストリームを復号化するためにクライアントに課される処理要求は軽くて済む。実施形態によっては、処理パワーが限られている非常に軽量なクライアントが、リアル・タイムで再生できる程度の小さいなストリームを要求することもある。ストリーム・サイズは、ユーザによって手動で設定することができ、あるいはサーバとクライアントとの間で自動的に取り決めることができ、そして再生のためのクライアントの処理資源が増減するのに応じて動的に変化させることができる。このストリーム・サイズは、クライアントにおいて表示されるビデオ画像の縦×横分解能を変化させることによって、表示されるビデオのフレーム・レートを変化させることによって、および／またはビデオを符号化するために用いられた圧縮のタイプおよびレベルを変化させることによって調節することができる。ストリームのオーディオ部の帯域幅も同様に調節することができる。そして、前述のように、クライアントは、種々の編集タスクをより良く実行するために、異なるサイズおよび品質のストリーミング・データをサーバに要求することができる。

図４および図５は、クライアントによって用いられるＧＵＩの例を２つ示す。図４を参照すると、編集ＧＵＩ２１０の一例において、ウィンドウの上半分にメディアが表示されており、このメディアを編集する際に用いられるレイヤの表現が、ウィンドウの下半分に表示されている。レイヤ・ディスプレイ４０２は、図３に示すレイヤ例と同様である。ここでは、７つのレイヤが図示されている。即ち、ビデオ・レイヤＶ１−Ｖ４、およびオーディオ・レイヤＡ１−Ａ３である。レイヤ・ディスプレイにおける縦の赤線は、現在の再生位置を表す。このＧＵＩが示すように、ビデオ・レイヤＶ１、Ｖ２、およびＶ３ならびにオーディオ・レイヤＡ１およびＡ２は、現在再生されている。３つのビデオ・レイヤは、３つの異なるメディア・ファイルを表すことができ、２つのオーディオ・レイヤは左チャネル、および右チャネルのステレオ音響を表すことができる。各オーディオ・クリップまたはビデオ・クリップには、各クリップの開始および終了において白黒の矩形でＧＵＩに図示されている、フェードまたはワイプのような、遷移効果を関連させることもできる。レイヤ・ディスプレイの発光領域によってＧＵＩに図示されているように、タイムラインの一部をユーザによって選択することができ、この選択した部分に、編集動作を適用することができる。

図４におけるＧＵＩの左上角４０４に、サムネイル画像として図示した、メディア・ファイル群のディレクトリのコンテンツを示す。これらのサムネイルは静止していてもよく、現在視聴されているメディア・ファイルの部分を示すこともでき、現在視聴されているフレームの、ファイル内における、相対的位置を示すために進展バーを表示している。また、このＧＵＩはウィンドウ４０６も含むことができ、編集の間に用いられるソース・メディア・ファイル群のうち１つを１つのウィンドウに示し、現在の編集の結果を別個のウィンドウに示すことができる。図４は、編集セッションのスナップショット４０８を示し、ここでは、レイヤＶ１−Ｖ３上に示される３つのビデオ・クリップをクロッピングし、右上の編集ウィンドウにおいて横に並べて位置付けられている。これらのクリップの１つの未編集バージョンが、右中央のソース・ウィンドウに示されている。更に、図４は、異なるシン・クライアント群（即ち、異なるインターフェース群）が、同じ編集サーバを用いて、同じメディアを編集できることも示す。

図５は、クライアントを通じてアクセス可能な最上位アプリケーション・ウィンドウを示す。このアプリケーション・ウィンドウは、種々の機能を有するツールバー５０２を特徴とする。種々の機能には、進展中のプロジェクトを格納するためのProjects（プロジェクト）、共有ストレージにおけるデータにアクセスするためのShares（共有）、メディア資源を編集するユーザを監視(view)および管理するためのMembers and Teams（メンバーおよびチーム）、Messages（メッセージ）、マルチユーザ・メディア・エディタをローカルにまたはリモートにアクセスするためのMAXedit、Browser（ブラウザ）、大まかなカット編集ならびに見直しおよび承認ツールを記録するためのMAXcut、およびTasks（タスク）が含まれる。ユーザは、このツールボックスを用いて、例えば、図４に示す編集アプリケーションを起動することができる。また、アプリケーション・ウィンドウは、中央表示部５０４において示されるソース・メディアや、図５の下部５０６に示す編集済みメディアを再生するために用いることもできる。

図６は、サーバ・アーキテクチャの一実施形態を更に詳細に示す。１つ以上の物理サーバ（ここでは、ｍ個の物理サーバ）６０２、６０４、６０６を接続し（例えば、並列に）、ネットワーク６０８に接続されているクライアントと通信することができる。これらの物理サーバは、協調して行動(act)して、１つの仮想サーバをクライアントに提示することができ、あるいはクライアントに具体的な物理サーバにログ・インする許可(ability)を付与するように構成することもできる。サーバという用語は、本明細書において用いる場合、物理サーバ・デバイスまたは仮想サーバ・デバイス、あるいは物理サーバまたは仮想サーバの１群のいずれでも指すことができる。

サーバは、ネットワークと直接通信することができ、あるいは交換機を通じてそうすることもできる。ログ・イン・サーバ・ルーチン６１０は、クライアントから着信する認証要求を扱い、１つのサーバに配置すること、または複数のサーバに跨って配置することができる。このログ・イン・サーバは、ユーザの名称およびパスワードを、既知のユーザのリストと突き合わせてチェックして、要求の正当性を判断することができ、更にユーザがサービスを使用するための許諾料を既に支払っていることを検証することもできる。管理運営および／またはシステム・レベルのタスクは、管理運営サービス６１２によって実行および管理することができ、管理運営サービス６１２も同様に１つのサーバに配置すること、または複数のサーバに跨って配置することができる。

各物理サーバは、中央演算装置６１４、グラフィクス・プロセッサ６１６、オペレーティング・システム６１８、ならびにユーザおよびシステム・レベル・ライブラリ６２０というような、その動作のために必要な標準的なハードウェアおよびソフトウェアを含む。サーバのハードウェアおよびソフトウェアは、例えば、処理集約的なメディア圧縮方式の符号化または復号化のような、ビデオ編集タスクの性能を向上させるための標準であるものを超えてカスタム化することもできる。

ユーザ（６２２、６２４、６２６）がサーバにログ・インすると、サーバは各ユーザに別個のプロセス（６２８、６３０、６３２）を作成する。各プロセスは、他のプロセスから分離されている。負荷均衡モジュールが、ｍ個のサーバのうちどれが新たなユーザ要求を実行するのに最も適しているか、自動的に判断することができる。負荷均衡モジュールは、入力として、均衡を取るサーバの処理パワーを表すパラメータを、負荷均衡部における種々の係数(factors)の所望の重み付けを表すパラメータと共に用いる。後者のパラメータは、ユーザが定める。サーバ毎に、ＣＰＵ使用度、メモリ使用度を追跡し、更に全てのサーバにおけるシステムへのアクティブな接続の総数も追跡する。一実施形態では、負荷均衡部は、サーバおよび現在のＣＰＵの処理容量ならびにメモリ使用度の関数として、サーバにかかる負荷を計算し、負荷が最も少ないサーバを、新たなユーザ接続を任せるために選択する。この関数は、以下のように、ユーザが定めたパラメータによって線形に重み付けすることができる。

サーバは、任意の多数のユーザから新たなユーザ要求を受け入れることができ、本発明のシステム・アーキテクチャにおいては、ユーザの最大数を設定するものはない。しかしながら、実施形態によっては、ユーザ数が所与のシステムにおいて利用可能な資源を超過することもある。例えば、サーバ側ストレージへの帯域幅またはサーバ側ストレージからの帯域幅が飽和してくることもあり、サーバの処理パワーを超過することもある。長期の解決策では、サーバの該当する資源を増大させることとするとよい。しかしながら、短期では、サーバは、編集精度に影響を及ぼさない程度に、各クライアントをホストするために用いられる帯域幅および／または処理資源を削減すればよい。例えば、サーバは一時的に各クライアントに送られるストリームのフレーム・レートを低下させる、および／またはサイズを縮小することができる。あるいは、クライアントが複雑な編集タスクを要求する場合、そのタスクの結果はリアル・タイムでは見ることができないことを、クライアントに知らせることもできる。一旦資源不足が解消したなら、サーバは通常の動作に戻ることができる。

サーバおよびクライアントは、異常に対して耐性を有するように実現することができる。例えば、一人のユーザのプロセスが作動しなくなった場合、これは他のユーザのプロセスに関して区分化(compartmentalized)されているので、これら他のプロセスに影響を及ぼさないことが可能である。更に、作動しなくなったプロセスを復元することもできる。ユーザの現在の状態の２つのコピーが、１つはクライアントにそしてもう１つはサーバに、存在することができる。ウオッチドック・プロセスをサーバにおいて実行すると、各クライアント／サーバ接続を監視して、不作動を発見することができる。サーバのプロセスが作動しなくなった場合、例えば、ウオッチドッグ・プロセスはサーバにおいてそのプロセスを再度開始し、クライアントと再接続したときに、クライアントからのユーザのコマンドの最新状態を同期させることができる。クライアント・プロセスが作動しなくなった場合、ウオッチドッグ・プロセスは、編集状態のサーバのバージョンをコピーして、クライアントに戻すことができる。一実施形態では、一旦クライアントがオンラインに戻ったなら、ユーザには、作動しなくなったセッションの復元、保存したセッションへの復帰、または新たなセッションの開始の間で選択肢が与えられる。

サーバは、ステートレス・サーバとして実現することもできる。この実施形態では、サーバは、クライアントから送られる編集コマンドの履歴を維持していない。代わりに、クライアントから受ける各要求が、クライアントの編集セッション全体を再現するために必要な状態情報の全てを収蔵している。一実施形態では、クライアントは、現在編集されている時間基準オブジェクトを表すＸＭＬファイルを送る。

ユーザは、クリップの複数のレイヤを収蔵する、図３に示したタイムラインのような、タイムラインを作成することができる。一実施形態では、前述のように、サーバは実行中にクリップ群を組み合わせて１つの平坦化したストリームを作成し、この平坦化したストリームをクライアントに送信する。別の実施形態では、サーバがタイムラインを予め処理してまたは「レンダリング」して、平坦化一次ファイルを作成し、このファイルのコンテンツをユーザにストリーミングする。つまり、サーバは、例えば、低資源利用度の期間中、機会があればレンダリングを実行しておき、後に高資源利用度の期間（即ち、実行中にストリームを平坦化し送信することが可能ではなかったと思われるとき）中に、レンダリングしたタイムラインをクライアントにストリーミングすることができる。一実施形態では、サーバは、現在ユーザによって用いられているフレーム・レートおよび分解能に応じて、タイムラインをレンダリングする。別の実施形態では、サーバはタイムラインを最大許容フレーム・レートおよび分解能でレンダリングし、サーバは、ストリーミングするときに、レンダリングのサイズをユーザの要求サイズおよびフレーム・レートに落とす。この実施形態では、サーバは、ユーザが異なるサイズおよび／またはフレーム・レートでストリームを表示するためにクライアントの構成を変更した場合、タイムラインを再度レンダリングする必要はない。

信頼されているユーザが同じソース・メディアを用いて一緒に作業している場合、これらのユーザは、レンダリングされたタイムライン、またはクリップおよびレイヤのコンフィギュレーションのようなデータを共有することを選択してもよい。クライアントは、ユーザに、他の信頼されているユーザのリストおよび彼らの作業の説明を提示することができ、最初のユーザが、共有する作業の一部または全部を組み込むことを選択することができる。一実施形態では、タイムラインのレンダリングのような共有される作業は、自動的に組み込まれる。信頼されているローカル・エリア・ネットワークまたはワイド・エリア・ネットワークにおける共同ユーザは自動的に認証することができ、一方インターネットのような信頼されていないネットワークを通じて接続されている共同ユーザは、彼らの作業を共有することができるようになる前に、招待／受入ハンドシェークを完了しなければならない。

本発明によるサーバ・アーキテクチャは、例えば、完全集中処理および格納によって、クライアントから送られる編集要求群をサーバが並列処理することを可能にすることができる。例えば、タイムラインの異なる部分群を並列にレンダリングして、組み合わせることができる。また、ユーザは、タイムラインがレンダリングされている間に、このタイムラインの一部を再生することができる。一般に、他のタスクの完了に依存しないユーザのプロセス内部における任意の編集タスクは、サーバの資源の限界まで並列処理することができる。別の実施形態では、ユーザはあるレベルの並列処理を要求することもできる。

ここで、ソース・メディアの正確で高速なフレーム毎制御に移ると、一実施形態では、混成ビデオ・ストリーミング技法を用いて、ソース・メディア内部にある任意のフレームに迅速にシークする。クライアントがメディア・ファイルを正常に再生しているとき、即ち、標準的なレートで増大しつつあるフレームのシーケンスを再生しているとき、サーバは、標準的なストリーム技法にしたがって、メディアをストリーミングして出力する。先に説明したように、ストリームは、実行中に合成（平坦化）された１つ以上のメディア・ファイルを表すことができる。ユーザがメディア・ファイルにおけるランダム地点までシークすると、サーバは、フレーム毎ストリーミング・モードに移行する。このモードでは、サーバは要求されたフレームのタイプを識別し、最後のＩ−フレームまで逆に辿って、必要であれば、要求されたフレームを再現し、この再現した要求フレームをクライアントにストリーミングする。つまり、クライアントは、要求されたフレームにシークするために、元のメディア・ファイルのいずれの部分もダウンロードする必要はない。

図７は、フレーム毎ストリーミング・モードに含まれるステップ群の一実施形態を示す。サーバは、最初に、メディア・ファイルにおける通常の再生位置以外の位置にシークしたクライアントから、フレーム入手要求（７０２）を受ける。次いで、サーバは元のメディア・ファイルにおけるしかるべき位置にシークする（７０４）。一実施形態では、サーバは元のメディア・ファイルのヘッダ情報を読み取って、ファイルにおいて要求されたフレームの位置を決定する。別の実施形態では、サーバは、ファイル・サイズ、符号化形式、およびフレーム・レートに基づいて、元のメディア・ファイルにおいて要求されたフレームの位置を推定する。最後に、サーバは、しかるべき検索アルゴリズムを用いて元のメディア・ファイルを検索することができ、あるいはこれらの技法の任意の組み合わせを用いて、要求されたフレームの位置を見出すことができる。

一旦要求されたフレームが発見されて、再現できそうな場合、このフレームを伸張し（７０６）、サイズを変更し（７０８）、そして要求されたフレームの画素サイズが、クライアントにストリーミングされるメディアの画素サイズとは異なるのであれば圧縮する（７１０）。最後に、フレーム自体を、当該フレームに関連する任意のオーディオ・データと共に送る（７１２）。複数のフレームをストリーミングすることもできる。

本発明の実施形態は、元のソース・メディアの中にある任意のフレームに対して高速かつ正確な遠隔アクセスを提供するので、本発明がなければリモート・クライアントとでは不可能な種々のアプリケーションを実施することが可能になる。例えば、メディア再生に結合されているスライダ・バーをクリックおよびドラッグしてファイル全域にわたってメディアを順方向および逆方向に素早くシークすることによって、例えば、このメディアを「総ざらい」(scrub)することができる。メディアを総ざらいすると、以前に見たことがない元のファイルの区間であっても、オーディオおよび／またはビデオのフレームをクライアントにおいて再生することができる。一実施形態では、サーバがフレームをシークしこれらをクライアントにストリーミングすることができるのと同じ速さで、総ざらいしたフレームが配給され、その時点で、サーバはフレームから選択した代表的なものをストリーミングする。加えて、フレーム毎ストリーミング・モードによって、例えば、２倍、４倍（以上）、順方向または逆方向再生が含む、従前のストリーミングでは通常可能でない再生速度および方向が可能となる。

また、本発明の実施形態は、１つ以上の製造品目に具現化された１つ以上のコンピュータ読み取り可能プログラムとして提供できることも記してしかるべきであろう。これらの製造品目は、例えば、フロッピ・ディスク、ハード・ディスク、ＣＤ ＲＯＭ、ＣＤ−ＲＷ、ＣＤ−Ｒ、ＤＶＤ ＲＯＭ、ＤＶＤ−ＲＷ、ＤＶＤ−Ｒ、フラッシュ・メモリ・カード、ＰＲＯＭ、ＲＡＭ、ＲＯＭ、または磁気テープのような、適したハードウェア装置であれば任意のものでよい。一般に、コンピュータ読み取り可能プログラムは、任意のプログラミング言語で実現することができる。用いることができる言語の例の一部には、Ｃ、Ｃ＋＋、またはＪＡＶＡ（登録商標）を含むことができる。更に、ソフトウェア・プログラムを機械語または仮想機械命令に変換し、その形態でプログラム・ファイルに格納することもできる。次いで、このプログラム・ファイルを製造品目の１つ以上に格納することができる。

以上、本発明のある種の実施形態について説明した。しかしながら、本発明はこれらの実施形態に限定されるのではなく、逆に、本明細書に明示的に記載したことに対する追加および修正も、発明の範囲に含まれることを意図することを、明示的に記しておく。更に、本明細書に記載した種々の実施形態の特徴は互いに排他的ではなく、本発明の主旨や範囲から逸脱することなく、種々の組み合わせや置換(permutation)も存在できることは、そのような組み合わせや置換が本明細書において明示されていなくても、言うまでもない。実際に、本明細書に記載したことの変形、修正、およびその他の実現例は、発明の主旨や範囲から逸脱することなく、当業者には想起されよう。したがって、本発明は、以上の例示的な記載のみによって定められることはないものとする。

Claims (20)

1. 遠隔ビデオ編集のためのシステムであって、
   ソース・メディア・ファイルを格納するのための記憶デバイスと、
   低帯域幅ネットワークを通じて、前記ソース・メディア・ファイルに関するビデオ編集コマンドを受信するのための入力と、
   前記ソース・メディア・ファイルの仮想表現であって、前記編集コマンドと、前記ソース・メディア・ファイルへのリンクとを含む、仮想表現と、
   高帯域幅リンクを通じて前記ソース・メディア・ファイルを読み取り、前記編集コマンドをこれに適用し、前記編集したソース・メディア・ファイルのプロキシ表現を生成するメディア配信エンジンと、
   前記プロキシ表現を前記低帯域幅ネットワークを通じて送信するのための出力と、
   を含む、遠隔ビデオ編集システム。
2. 請求項１記載のシステムにおいて、前記メディア配信エンジンはストリーミング・エンジンであり、前記プロキシ表現はメディア・ストリームである、システム。
3. 請求項１記載のシステムであって、更に、複数の仮想表現を備えており、該仮想表現の各々が、編集コマンドの複数組のうち１つを含む、システム。
4. 請求項３記載のシステムであって、更に、前記複数の仮想表現の各々を複数の処理デバイスの１つに割り当てるのための負荷均衡モジュールを含む、システム。
5. 請求項１記載のシステムにおいて、前記複数のビデオ編集コマンドは、同時に前記仮想表現に適用される、システム。
6. 請求項１記載のシステムにおいて、前記低帯域幅ネットワークは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、またはインターネットのうち１つである、システム。
7. 請求項１記載のシステムにおいて、前記メディア配信エンジンは、前記低帯域幅ネットワークにかかる負荷、または前記高帯域幅リンクにかかる負荷のうち少なくとも１つに応答して、前記プロキシ表現の帯域幅を調節する、システム。
8. 請求項１記載のシステムであって、更に、サービスの中断から復元するためのウオッチドック・モジュールを含む、システム。
9. 遠隔ビデオ編集のためのシステムであって、
   クライアントであって、
   （ａ）メディアのプロキシ表現を受信するのための入力と、
   （ｂ）前記プロキシ表現を復号化するのためのプロセッサと、
   （ｃ）前記復号化したプロキシ表現によって表されるコンテンツを表示するのためのグラフィカル・ユーザ・インターフェースと、
   （ｄ）前記復号化したプロキシ表現を編集するためのコマンドの入力を容易にするのためのユーザ入力と、
   （ｅ）前記編集コマンドを送信するのための出力と、
   を含む、クライアントと、
   前記編集コマンドを受信し、該編集コマンドをソース・メディア・ファイルに適用し、前記ソース・メディア・ファイルおよび前記編集コマンドに応じて前記メディアの前記プロキシ表現を発生するサーバと、
   を含む、システム。
10. 請求項９記載のシステムにおいて、前記クライアントはシン・クライアントである、システム。
11. 請求項９記載のシステムにおいて、前記クライアントは、デスクトップ・コンピュータ、ワークステーション、ラップトップ・コンピュータ、ノートブック、およびスマートフォンのうちの１つである、システム。
12. ビデオ・ファイル遠隔編集のための方法であって、
    サーバにおいて、リモート・クライアントからのビデオ編集コマンドを受信するステップと、
    前記サーバにおいて、前記受信したコマンドに応じてメディア・ファイルの仮想表現を変更するステップであって、前記仮想表現が、記憶デバイスに格納されたソース・メディア・ファイルに対する参照を含み、前記記憶デバイスが高速リンクを通じて前記サーバに接続された、ステップと、
    前記リモート・クライアントに、前記編集コマンドによって変更された前記ソース・メディア・ファイルを含むデータ・ストリームを送信するステップと、
    を含む、方法。
13. 請求項１２記載の方法であって、更に、複数のリモート・クライアントから、テキストベースのビデオ編集コマンドを受信するステップを含む、方法。
14. 請求項１２記載の方法において、前記サーバは、低帯域幅ネットワークを通じて、前記クライアントに接続される、方法。
15. 請求項１４記載の方法において、前記低帯域幅ネットワークは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、およびインターネットのうちの１つである、方法。
16. ビデオ・フレームをリモート・クライアントに送るのための方法であって、
    サーバにおいて、リモート・クライアントからビデオ・フレームに対する要求を受けるステップと、
    メディア・ファイルを検索して、前記要求されたフレームを求めるステップであって、前記メディア・ファイルが、高速リンクを通じて前記サーバに接続された記憶デバイスに格納された、ステップと、
    前記サーバから、前記ビデオ・フレームを前記クライアントに送るステップと、
    を含む、方法。
17. 請求項１６記載の方法において、前記要求されたビデオ・フレームは、Ｐ−フレームおよびＢ−フレームのうちの１つである、方法。
18. 請求項１７記載の方法であって、更に、前記メディア・ファイルにおいて逆方向にＩ−フレームまでシークし、前記要求されたフレームを再現するステップを含む、方法。
19. 請求項１６記載の方法において、前記サーバは、低帯域幅ネットワークを通じて、前記クライアントに接続される、方法。
20. 請求項１９記載の方法において、前記低帯域幅ネットワークは、ローカル・エリア・ネットワーク、ワイド・エリア・ネットワーク、およびインターネットのうちの１つである、方法。

Images