(57)【要約】マルチメディア再生装置におけるトリックプレイ動作を実施する方法及び装置が、開示されている。トリックプレイ要求が、通常のマルチメディア再生中に受信された場合、該トリックプレイ要求に応答して、最後の処理手段における処理のために適切なフレームが決定される。バッファからの前記適切なフレームは、該フレームを識別する該バッファ内に記憶されているメタデータを使用して取得され、該取得されたフレームは、処理される。この間、記憶されているマルチメディアコンテンツ内の第２の適切なフレームは、前記トリックプレイ要求に応答しての第１処理手段による処理のために、選択される。前記最後の処理手段が前記取得されたフレームの処理を完了している場合、前記第２の適切なフレームが該最後の処理手段に利用可能であるように、前記第２の適切なフレーム及び後続的に選択されるフレームが処理される。
2006520986.tif 000002
【特許請求の範囲】
【請求項１】
マルチメディア再生装置におけるトリックプレイ動作を実施する方法であって、前記マルチメディア再生装置は、各々少なくとも１つのバッファを備えている複数の処理手段を有し、前記複数の処理手段は、記憶されているマルチメディアコンテンツを直列態様で処理する方法において、
―  通常のマルチメディア再生中、トリックプレイ要求を受信するステップ、
―  前記トリックプレイ要求に応答して、最後の処理手段における処理のために適切なフレームを決定するステップと、
―  バッファから前記適切なフレームを、前記フレームを識別する該バッファ内に記憶されているメタデータを使用して取得するステップと、
―  取得された前記フレームを処理するステップと、
―  前記トリックプレイ要求に応答しての第１処理手段による処理のために、記憶されたマルチメディアコンテンツ内の第２の適切なフレームを選択するステップと、
―  前記最後の処理手段が前記取得されたフレームの処理を完了している場合、前記第２の適切なフレームが該最後の処理手段に利用可能であるように、前記第２の適切なフレーム及び後続して選択されるフレームを処理するステップと、
を有する方法。
【請求項２】
前記トリックプレイ要求は、高速フォワードモードの動作のためのものである、請求項１に記載の方法。
【請求項３】
トリックプレイ要求が受信された場合、前記処理手段の各々が、前記トリックプレイ要求に応答しての処理のために、関連付けられている前記バッファから前記適切なフレームを決定するステップを有する、請求項２に記載の方法。
【請求項４】
前記トリックプレイ要求は、高速リバースモードの動作のためのものである、請求項１に記載の方法。
【請求項５】
前記最後の処理手段と関連付けられている前記バッファを除く全てのバッファは、前記トリックプレイ要求が受信された後、フラッシュされる、請求項４に記載の方法。
【請求項６】
複数のバッファが前記最後の処理手段と関連付けられている、請求項１に記載の方法。
【請求項７】
前記最後の処理手段が、該最後の処理手段と関連付けられている前記バッファ内にまだ存在する少なくとも１つの事前に処理されたＩフレームを選択する、請求項４に記載の方法。
【請求項８】
記憶されているマルチメディアコンテンツを直列態様で処理する、各々少なくとも１つのバッファを備えている複数の処理手段であって、
―  通常のマルチメディア再生中、トリックプレイ要求を受信する手段と、
―  前記トリックプレイ要求に応答して、最後の処理手段における処理のために適切なフレームを決定する手段と、
―  バッファから前記適切なフレームを、前記フレームを識別する該バッファ内に記憶されているメタデータを使用して取得する手段と、
―  前記取得されたフレームを処理する手段と、
―  前記トリックプレイ要求に応答して、第１処理手段による処理のために、記憶されたマルチメディアコンテンツ内の第２の適切なフレームを選択する手段と、
―  前記最後の処理手段が前記取得されたフレームの処理を完了している場合、前記第２の適切なフレームが該最後の処理手段に利用可能であるように、前記第２の適切なフレーム及び後続して選択されるフレームを処理する手段と、
を有する複数の処理手段を備える、マルチメディア再生装置。
【請求項９】
前記トリックプレイ要求は高速フォワードモードの動作のためのものである、請求項８に記載の装置。
【請求項１０】
トリックプレイ要求が受信された場合、前記処理手段の各々が、該トリックプレイ要求に応答しての処理のために、関連付けられている前記バッファから前記適切なフレームを決定する、請求項９に記載の装置。
【請求項１１】
前記トリックプレイ要求は高速リバースモードの動作のためのものである、請求項８に記載の装置。
【請求項１２】
前記最後の処理手段と関連付けられている前記バッファを除く全てのバッファは、前記トリックプレイ要求が受信された後、フラッシュされる、請求項１１に記載の装置。
【請求項１３】
複数のバッファが前記最後の処理手段と関連付けられている、請求項８に記載の装置。
【請求項１４】
前記最後の処理手段が、該最後の処理手段と関連付けられている前記バッファ内にまだ存在する少なくとも１つの事前に処理されたＩフレームを選択する、請求項１１に記載の装置。
【請求項１５】
表示装置が、前記最後の処理手段の前記バッファのフレームを逆のフレーム順序で読み出す、請求項１１に記載の装置。
【請求項１６】
前記バッファは単一の供給されているメモリの一部である、請求項８に記載の装置。
【請求項１７】
前記バッファは複数のメモリに分散されている、請求項８に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、記憶されたマルチメディアコンテンツのビデオ処理に関し、より詳細には、該マルチメディアコンテンツの再生中のトリックプレイ動作を改善する方法及び装置に関する。
【背景技術】
【０００２】
ハードディスク記録の場合、しばしば、いわゆるＣＰＩ（Ｃｈａｒａｃｔｅｒｉｓｔｉｃ  Ｐｏｉｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ）データが、記録処理中、生成される。典型的には、ＣＰＩデータは、記憶媒体上の生ビデオデータとは異なるファイルに記憶される。このことは、全てのビデオ及びＣＰＩデータを１つのファイルに一緒に記憶するよりも、都合が良い。
【０００３】
ＣＰＩデータは、記録されているビデオ番組の高度な再生（例えば、高速／低速のフォワード／バック再生）を可能にするのに使用されている。このようなトリックプレイ動作を可能にするのに必要とされる典型的な情報は、Ｉフレームが開始する生ビデオデータファイル内のオフセットである。ＣＰＩファイル内では、タイムスタンプは各Ｉフレームと関連付けられており、時間情報に基づいて、記憶されているビデオストリーム内のジャンプを容易にしている。このように、再生構成要素は、高速再生／リバースのために、どの部分を前記ビデオファイルから読み出し、接続されているデコーダに送る必要があるかを知る。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
プレーヤ構成要素が、高速のフォワード／リバースモードで全フレームを読む場合、これは、当該システムのメモリ帯域幅、通信、ハードディスク及びデコーダに対して過負荷になり得る。このシステムにおいて、トリックプレイモードが選択されている場合、当該システムのビデオ処理エレメントに関連付けられているストリームバッファの全てはフラッシュ（ｆｌｕｓｈ）され、選択されたトリックプレイモードに適切なフレームによって再度満たされる必要がある。このことは、メディアコンテンツの表示における容認できない遅延問題を生じ得る。従って、既知の再生システムと関連付けられている遅延問題を有さないトリックプレイモードの動作を実施する新しい方法が必要である。
【課題を解決するための手段】
【０００５】
本発明は、各処理エレメントが、トリックプレイモードの動作中、ビデオストリーム内に別個のフレームを位置付けることができるように、ＣＰＩデータをビデオ処理ストリーム内の各ストリームバッファに供給することにより、他の既知のビデオ再生システムの欠点を克服する。
【０００６】
本発明の１つの実施例によれば、マルチメディア再生装置におけるトリックプレイ動作を実施する方法及び装置が開示される。トリックプレイ要求が通常のマルチメディア再生中に受信された場合、最後の処理手段における処理のために適切なフレームが、該トリックプレイ要求に応答して決定される。バッファからの前記適切なフレームは、該フレームを識別するバッファ内に記憶されているメタデータを使用して取得され、取得された該フレームが処理される。この間、前記記憶されているマルチメディアコンテンツ内の第２の適切なフレームが、前記トリックプレイ要求に応答しての第１の処理手段による処理のために選択される。次いで、前記最後の処理手段が前記取得されたフレームの処理を完了している場合に、前記第２の適切なフレームが該最後の処理手段に利用可能であるように、前記第２の適切なフレーム及び後続的に選択されるフレームが処理される。
【発明を実施するための最良の形態】
【０００７】
本発明のこれら及び他の見地は、後述の実施例を参照して明らかになり、説明される。
【０００８】
本発明は、例として、以下に記載される実施例を参照して記載される。
【０００９】
ディスク上に記憶されているビデオストリーム用のＣＰＩ情報を単に使用する代わりに、本発明は、前記ＣＰＩ情報を、２つのＡ／Ｖ処理構成要素間の通信チャネルを実施する各ストリームバッファ内で使用する。出願人整理番号ＰＨＮＬ０２１３９０を付された特許出願において提案されているように、Ｃ−ＨＥＡＰにおいて、通信チャネルは、１つ以上のバッファであって、製作者によって書き込まれ消費者によって読み出されるＡ／Ｖデータを記憶するのに使用されることができるバッファによって構成されている。Ｃ−ＨＥＡＰ通信プロトコルにおいて、バッファは、書き込まれることができる前に、先ず請求（確保）されなければならない。これが書き込まれている場合、製作者は、消費者がこれを読み出すことができる前に、これを解放しなければならない。Ａ／Ｖデータをチャネルバッファに書き込む間、ＣＰＩデータも生成されることができ、ＣＰＩデータは、書き込まれているバッファ内のＩフレームの位置を識別する。ＣＰＩデータは、別個のチャネルで伝送されることができ、又は書き込まれているチャネルバッファの確保されている部分であることもできる。
【００１０】
模範的な再生システム１００が、図１に示されている。再生システム１００は、ディスク又は記憶装置１０２と、再生装置１０４と、表示装置１１５とから構成されている。この説明のための例において、再生装置１０４は、プレーヤ又はディスクリーダ１０６及び関連付けられているバッファ１０７と、解読装置１０８及び関連付けられているメモリ１０９と、多重分離装置１１０及び関連付けられているメモリ１１１と、デコーダ１１２及び関連付けられているバッファ１１３と、再生装置１０４の動作を制御するプロセッサ１１４とによって構成されている。例えば、ディスク１０２からのビデオストリームが暗号化されていない場合、再生装置は、解読装置１０８及び関連付けられているバッファ１０９を必要としない。更に、前記バッファは各処理エレメントから分離されて示されているが、該バッファは夫々の処理エレメントの一部であることもでき、本発明は、これらに限定されるものではないことを理解されたい。更に、全てのバッファ及びメモリ（１０７、１０９、１１１、１１３）は、１つの共有されるメモリ又は幾つかの共有されるメモリであっても良い。更に、再生装置１０４は、他の処理エレメントを含むこともできる、又は異なるマルチメディアコンテンツを読み出すための特定の必要性及び要件に基づいて図１に示されているものより、少ない処理エレメントを有することもでき、本発明はこれらに限定されるものではない。
【００１１】
再生中、プレーヤ１０６は、記憶されているビデオデータをディスク１０２から読み出し、該ビデオデータをバッファ１０７内に入れる。典型的な十分な質のＭＰＥＧ  Ａ／Ｖストリームの場合、約４Ｍビット／秒のビットレートが、必要である。一秒当たり２５フレームの場合、平均して約２０キロバイトが、フレームを記憶するのに必要とされる。典型的なＧＯＰの大きさ１２とは、完全なＧＯＰが２４０ｋＢのメモリ内に記憶されることができることを意味する。この場合、１−ＭＢストリームバッファは、典型的には４つのＩフレームを含む。更に、記憶されるデータ用のメタデータ（ＣＰＩデータ）もバッファ１０７に読み込まれる。「プレーヤ」１０６によって処理されるデータはバッファ１０７に入れられ、これは、次の処理エレメント「解読器」１０８によって直接的に読み出されることができる。バッファは、自身からデータが読み出される前に、完全に「満たされている」必要はない。更に、全てのバッファは、典型的には単一のメモリの一部であり、この結果、バッファメモリスペース間でのコピーは必要ない。更に正確には、プレーヤ１０６によって、バッファスペース１０７に書き込まれるデータは、次の処理エレメント（解読器１０８）によって直接的に読み出されることができる。ひとたびバッファ１０７内のデータが十分になれば、最も古いデータがバッファ１０９に転送される。次いで、解読装置１０８はバッファ１０９内のビデオデータを解読し始める。次いで、解読されたデータは、次の処理エレメント（多重分離装置１１０）が入力バッファからの読み出しを開始するまで、バッファ１０９内に記憶されている。次いで、多重分離装置１１０は解読された前記データを多重分離する。多重分離された前記データがバッファ１１１から読み出される（場合によっては、バッファ１１３に転送される）場合、デコーダ１１２は、前記多重分離されたデータをデコードする。デコードされた前記データが表示装置１１５によってバッファ１１３から読み出される場合、前記デコードされたデータは、表示されることができる。
【００１２】
マルチメディア再生装置におけるトリックプレイ動作を実施する方法は、以下で図２を参照して、説明される。ステップ２０１において、トリックプレイ要求は、プロセッサ１１４による通常のマルチメディア再生中に受信される。ステップ２０３において、最後の処理手段（デコーダ１１３）における処理に適切なフレームが、トリックプレイ要求に応答して決定される。ステップ２０５において、バッファからの前記適切なフレームは、該フレームを識別する該バッファ内に記憶されているメタデータを使用して取得され、取得された該フレームは、ステップ２０７において処理される。その間、ステップ２０９において、トリックプレイ要求に応答しての第１処理手段による処理のために、記憶されているマルチメディアコンテンツ内の第２の適切なフレームが選択される。次いでステップ２１１において、前記第２の適切なフレーム及び後続して選択されるフレームは、前記最後の処理手段が、取得された前記フレームの処理を完了している場合、前記第２の適切なフレームが該最後の処理手段に利用可能であるように、処理される。
【００１３】
通常の再生から高速フォワードモードの動作に入る場合、もはやディスク１０２とデコーダ１１２との間の全てのチャネルバッファをフラッシュする必要はなく、ディスク１０２からＩフレームを読み出し、これらをプレーヤ構成要素の出力チャネルに入れるだけで良い。その代わり、前記デコーダは、当該処理チェーン内の処理エレメントの全てがそうできるように、入力ストリームバッファ１１３から直接的に前記Ｉフレームを選択することができる。この間、プレーヤ１０６は、Ｉフレームの読み出しのみに切り換えることができる。ひとたび、全てのＩフレームが、Ｃ−ＨＥＡＰ通信プロトコルによって入力ストリームバッファから読み出されていれば、前記バッファは解放され、製作者によって再び使用可能になる。前記製作者は、ここでストリームバッファ内の全データを上書きするが、高速フォワードモードにおいては、Ｉフレームを書き込むのみである。
【００１４】
低速フォワードモードの動作が選択されている場合、当該処理チェーン内の前記最後の処理エレメント（図１内のデコーダ１１２）は、単純に「低速処理速度」に入れられる。低速フォワードモードの動作中、Ｉフレームを選択する必要はない。
【００１５】
高速リバースモードの動作が要求された場合、再生装置１０４内の前記最後の処理エレメント（例えば、図１に示されている例示的な再生システム内のデコーダ１１２）は、予め処理されたＩフレームであって、まだ入力ストリームバッファ１１３内にあるＩフレームを選択する。このことは、当該処理チェーン内の前記最後の処理エレメントのみによって行われる。前記最後の処理エレメントのために、複数のバッファを同時に入力チャネル内に確保することにより、複数のＩフレームを戻すことが可能である。この間、当該処理チェーン内の全ての他のチャネルはフラッシュされ、プレーヤ１０６は、先行Ｉフレームをディスク１０２から選択し始める。
【００１６】
低速リバースは、高速リバースと似ているが、Ｉフレームを選択する必要はない。全チャネルがフラッシュされプレーヤ１０６がディスク１０２から早期のフレームを読み出し始めるまで、当該処理チェーン内の前記最後の処理エレメントは、入力バッファからフレームを逆の順序で読み出し始めることができる。スムーズな表示のために、低速リバースは、表示装置１１５によって出力バッファ１１３を逆のフレーム順序で読み出すことにより、実施されることができる。デコードされたフレームは、圧縮されたＡ／Ｖデータよりも、多くのバッファスペースを必要とするので、１つの先行出力フレームのみが、ここにバッファされる。ＭＰＥＧストリーム（Ｂ及びＰフレーム）の構造のために、圧縮されたフレームの（デコード用の）逆の順序での簡潔な読み出しは、機能しないことに留意されたい。このような機能の仕方は、リバース再生が通常速度におけるものである場合でさえも、多くの処理電力又は帯域幅を必要としない。当該処理チェーン全体は、「フォワード」モードで動作することができ、これによって、ディスクアクセス及びデコーダの性能を最適化する。バッファ１１３の最終的な読み出しが、リバースされなければならないのみである。バッファ容量を最小化するように、本発明のこの実施例において、１つの先行のデコードされたフレームのみが、ここにバッファされる。
【００１７】
まだ残っている問題は、チャネルバッファが読み出される又はフラッシュされる場合、プレーヤ１０６は、当該処理チェーン内の前記最後の処理エレメントが自身の入力バッファ内のデータを処理した後、前記トリックプレイがスムーズであり続けることを可能にするように、ディスク１０２からどのフレームを次に読み出すべきかを知っていなくてはならないことである。これは、プレーヤ１０６とデコーダ１１２との間に何らかのパイプラインの遅延が存在するので、典型的には、単純にトリックプレイモードへの切り換えの前に前記プレーヤが読み出している次のフレームであるわけではない。結果として、プレーヤ１０６は、データが尽きる前に、当該処理チェーン内の前記最後の処理エレメントによって処理される最後のフレームとなるフレームを見つけ出す必要がある。このことは、処理されるべき前記最後のフレームのための前記入力バッファ内のＣＰＩデータをチェックすることにより、なされることができる。この情報を当該処理チェーン内の前記最後の処理エレメントによって処理されるべき最後のＩフレームに関して得ることにより、プレーヤ１０６は、次にディスク１０２から取得するべきフレームを、知る。例えば、プロセッサ１１４は、ＣＰＩ情報を、デコーダ１１２及びバッファ１１３から取得し、次いで、この情報をプレーヤ１０６に送ることができるが、本発明は、これらに限定されるものではない。
【００１８】
前記処理チェーンのコントローラが、当該処理チェーン内の前記最後の処理エレメントの入力バッファを除いた、全てのストリームバッファをフラッシュするのに十分な時間を有し、当該処理チェーン内の前記最後の処理エレメントが現在のＧＯＰの処理を終了することができることを保証するには、２４０ｋＢのバッファは十分である。高速のフォワード／バックのトリックプレイの場合、恐らく、３つのＩフレームを含む２つのＧＯＰは十分である。高速リバースの場合、当該デコーダが何らかの順序でＩフレームにアクセスすることができる入力バッファ内のデータの２つのＧＯＰによって、当該デコーダは、少なくとも１つの先行Ｉフレームと多くても２つのＩフレームとをデコードし、表示することができる。Ｉフレームの表示は、典型的な５０Ｈｚインターレースのテレビジョン・スクリーンの場合、１／２５秒（４０ｍｓ）かかり、又は典型的な６０Ｈｚインターレースのテレビジョン・スクリーンの場合、１／３０秒かかる。これは、この時間内に、全ての関連するバッファがフラッシュされ、プレーヤ１０６がハードディスク１０２からの読み出しを開始し、データを当該デコーダの入力チャネルに到達させなければならない時間である。ディスクから、良好なディスクアクセス速度を得るように、複数のフレームがフォワードの順序で読み出され、後続の処理エレメントは、前記ディスクのバッファを逆の順序で読み出すことができる。この期限が満たされない場合、前記デコーダは、１又は２つのＩフレーム後方にジャンプした後、入力データを切らし、出力はスムーズにならない。この時間が十分でない場合、この問題を克服するように、当該デコーダのバッファの大きさが増大されても良く、又は当該デコーダによって確保されるバッファの数が増加されても良い。例えば、当該デコーダが、同時に１つのＧＯＰごとに３個のバッファを確保している場合、該デコーダは、最小で２つの先行フレームと最大で３つのフレームとを表示することができ、フラッシュ及びディスクアクセスを達成するように、２又は３つの期間を可能にする。
【００１９】
本発明の異なる実施例は、幾つかのステップのタイミングは、本発明の全体的な動作に影響を与えることなく交換されることができるので、上述のステップの厳密な順序に限定されるものではないことを理解されたい。更に、「有する」という語は、他のエレメント又はステップを排除するものではなく、単数形は、複数及び単一のプロセッサ又は他のユニットが、添付請求項に記載されている幾つかのユニット又は回路の機能を実施することができることを排除するものではない。
【００２０】
マルチメディア再生装置におけるトリックプレイ動作を実施する方法及び装置が、開示されている。トリックプレイ要求が、通常のマルチメディア再生中に受信された場合、最後の処理手段における処理に適切なフレームは、前記トリックプレイ要求に応答して決定される。バッファからの適切なフレームは、前記フレームを識別する該バッファ内に記憶されているメタデータを使用して取得され、該取得されたフレームが、処理される。この間、記憶されているマルチメディアコンテンツ内の第２の適切なフレームは、前記トリックプレイ要求に応答しての第１処理手段による処理のために、選択される。次いで、前記最後の処理手段が前記取得されたフレームの処理を完了している場合、前記第２の適切なフレームが該最後の処理手段に利用可能であるように、前記第２の適切なフレーム及び後続して選択されるフレームが処理される。
【図面の簡単な説明】
【００２１】
【図１】本発明の１つの実施例によるマルチメディア再生装置のブロック図である。
【図２】本発明の１つの実施例によるトリックプレイ動作を説明しているフローチャートである。
【図１】
2006520986.tif 000003
【図２】
2006520986.tif 000004
【国際調査報告】
2006520986.tif 000005
2006520986.tif 000006
2006520986.tif 000007
2006520986.tif 000008