JP5338595B2

JP5338595B2 - データ処理方法およびデータ処理装置

Info

Publication number: JP5338595B2
Application number: JP2009223199A
Authority: JP
Inventors: 隆幸菅原; 克也小野寺; 誠司日暮; 卓也對馬; 達也新谷垣内; 俊夫黒岩; 勝義西谷; 和行宮内
Original assignee: JVCKenwood Corp
Current assignee: JVCKenwood Corp
Priority date: 2009-09-28
Filing date: 2009-09-28
Publication date: 2013-11-13
Anticipated expiration: 2029-09-28
Also published as: JP2011071905A

Description

本発明は、データ処理装置に関し、特に、復号処理を実行すべく、受信したデータを一時的にバッファに格納するデータ処理技術に関する。

従来のネットワーク型受信処理装置では、たとえば、ネットワークを介してホスト装置から供給される受信データを印字するプリンタ装置においては、受信データ、または通信プロトコルによって受信データの終端を検知できない場合、この受信データの出力が未完了のまま、停止してしまうという問題があった。そこで、送信元であるホスト装置からの受信データが一定時間（受信タイムアウト時間）を越えて受信されないと、プリンタ装置の専有状態を解除する技術が知られている。また、受信先の処理装置において、パケット受信中にプログラムによる割込みが発生した場合、命令処理部は受信割込み要因を起こしたパケットのヘッダ部を主記憶部内に保持し続けるため、割込み処理が終了するまで処理装置は新たなパケットを受信することができず、タイムアウトせざるをえないという状況があった。

このような状況はＡＶ（Audio Visual）機器においての一時停止（ポーズ）、再復活再生（レジューム）機能には非常に不都合なものであり、一旦ネットワークからのＡＶデータを伝送されている以上、受信バッファやデータの復号用バッファにあるデータがフラッシュしてしまうと、次にレジュームした場合に正確な位置からのレジュームができない。即ち、送信側サーバーが何処までを送ったかの情報を持っているとしても、受信側クライアントのほうにある受信バッファやデータの復号用バッファにはどこまでのバッファが溜まっていたか（消費されていたか）の情報がフラッシュしてしまっていると、ＡＶデータがＭＰＥＧなどのように圧縮符号化されているアプリケーションなどでは余計に再生位置の誤差が大きくなってしまう。しかし、ポーズしたタスク全てを完全に保持していることを行っていると、複数のポーズなどの事象が多く発生してくると、バッファなどのリソースを多く保持しなければならなくなり、システムに破綻をきたしてしまうという問題があった。

また、一時停止（ポーズ）、再復活再生（レジューム）に対応した技術として、特許文献１の発明がある。特許文献１の発明は、送信側サーバが動画の配信中にユーザが一時中断を選択したときは配信を停止するが、その後ユーザが配信の再開を選択したときは中断個所から引き続き配信を再開することを特徴とするものである。

特開２００１−３５９０７３号公報

しかし、特許文献１の発明は、タイムアウトの概念がないので、例えば、一時停止（ポーズ）中に、他の原因において、受信側クライアントでのデータ受信のための通信プロセスが消滅し、再復活再生（レジューム）に支障をきたす場合となっても、他の受信側クライアントからの要求に、送信側サーバは一切応答できないという問題が発生する。

本発明は上述した課題を解決するためになされたものであり、その目的は、ネットワークを介してのデータ受信のプロセスを停止した後において（受信側クライアントでデータが受信できない状態になった後において）、データ復号再開（レジューム）がされたときでも、大きな誤差を発生することなく正確な位置からデータ再生することにある。

上記課題を解決するために、本発明のある態様のデータ処理方法は、復号処理を実行すべく、受信したデータを一時的にバッファに格納するデータ処理方法において、第１のデータの受信が中断した場合に、第１のデータの受信中断状態が所定時間以上継続しているか否かを判定するステップと、第１のデータの受信中断状態が所定時間まで継続していない場合、第１のデータのうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、第１のデータの受信中断状態が所定時間以上継続している場合、第１のデータとは別の第２のデータの受信要求があるか否かを判定するステップと、第２のデータの受信要求がない場合、一部のデータが占有しているバッファの解放を回避するステップと、第２のデータの受信要求があった場合、一部のデータが占有しているバッファを第２のデータの受信のために解放するステップと、を備える。

本発明の別の態様もまた、データ処理方法である。この方法は、復号処理を実行すべく、受信したデータを一時的にバッファに格納するデータ処理方法において、少なくとも１つの受信中断中のデータがある場合に、受信中断中のデータの各々について、受信中断状態が所定時間以上継続しているか否かを判定するステップと、受信中断中のデータのうち受信中断状態が所定時間まで継続していない少なくとも１つの第１のデータがある場合、第１のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、受信中断中のデータのうち受信中断状態が所定時間以上継続している少なくとも１つの第２のデータがある場合、受信中断中のデータとは別のデータの受信要求があるか否かを判定するステップと、別のデータの受信要求がない場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、別のデータの受信要求があった場合に、別のデータを受信するためのバッファが解放されているか否かを判定するステップと、別のデータを受信するためのバッファが解放されている場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、別のデータを受信するためのバッファが不足している場合、別のデータを受信するためのバッファを確保するよう、受信中断時間が長い第２のデータから順に、その一部のデータが占有しているバッファを解放するステップと、を備える。

本発明のさらに別の態様は、データ処理装置である。この装置は、受信したデータを一時的に格納するバッファと、バッファに格納されたデータに復号処理を実行する復号化手段と、バッファの解放を制御するバッファ管理手段と、を備える。バッファ管理手段は、第１のデータの受信が中断した場合、第１のデータの受信中断状態が所定時間まで継続していないときは第１のデータのうち既に受信した一部のデータが占有しているバッファの解放を回避し、第１のデータの受信中断状態が所定時間以上継続しているときは、第１のデータとは別の第２のデータの受信要求がない場合は一部のデータが占有しているバッファの解放を回避し、第２のデータの受信要求があった場合は一部のデータが占有しているバッファを第２のデータの受信のために解放する。

本発明のさらに別の態様もまた、データ処理装置である。この装置は、受信したデータを一時的に格納するバッファと、バッファに格納されたデータに復号処理を実行する復号化手段と、バッファの解放を制御するバッファ管理手段と、を備える。バッファ管理手段は、少なくとも１つの受信中断中のデータがある場合に、受信中断中のデータの各々について、受信中断状態が所定時間以上継続しているか否かを判定し、受信中断中のデータのうち受信中断状態が所定時間まで継続していない少なくとも１つの第１のデータがある場合、第１のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避し、受信中断中のデータのうち受信中断状態が所定時間以上継続している少なくとも１つの第２のデータがある場合、受信中断中のデータとは別のデータの受信要求があるか否かを判定し、別のデータの受信要求がない場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避し、別のデータの受信要求があった場合であって別のデータを受信するためのバッファが解放されている場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避し、別のデータの受信要求があった場合であって別のデータを受信するためのバッファが不足している場合、別のデータを受信するためのバッファを確保するよう、受信中断時間が長い第２のデータから順に、その一部のデータが占有しているバッファを解放する。

本発明によれば、ネットワークを介してのデータ受信のプロセスを停止した後において（受信側クライアントでデータが受信できない状態になった後において）、データ復号再開がされたときでも、大きな誤差を発生することなく正確な位置からデータ再生することができる。

本実施例に係るデータ送受信システムの構成を示すブロック図である。ネットワークを介してＡＶ送信機からＡＶ受信機にＡＶデータを送信する送信手順を示すフローチャートである。本実施例に係る、ＡＶ情報要求コマンド、ＡＶリストコマンド、ＡＶ受信要求コマンド、ＡＶ受信許可コマンドなどの構成例を示す図である。本実施例に係るデコーダーバッファの具体的な例を模式的に示す図である。本実施例に係るネットワークバッファ状態管理テーブルを示す図である。バッファの解放を行う場合と行わない場合のプロセスを示すフローチャートである。

本発明の実施例として、データ処理装置について以下説明する。このデータ処理装置は、受信したデータを一時的に格納するバッファと、バッファに格納されたデータに復号処理を実行する復号化手段と、バッファの解放を制御するバッファ管理手段と、を備える。バッファ管理手段は、第１のデータの受信が中断した場合、第１のデータの受信中断状態が所定時間まで継続していないときは第１のデータのうち既に受信した一部のデータが占有しているバッファの解放を回避する。また、第１のデータの受信中断状態が所定時間以上継続しているときは、第１のデータとは別の第２のデータの受信要求がない場合は一部のデータが占有しているバッファの解放を回避し、第２のデータの受信要求があった場合は一部のデータが占有しているバッファを第２のデータの受信のために解放する。

また、バッファ管理手段は、少なくとも１つの受信中断中のデータがある場合に、受信中断中のデータの各々について、受信中断状態が所定時間以上継続しているか否かを判定し、受信中断中のデータのうち受信中断状態が所定時間まで継続していない少なくとも１つの第１のデータがある場合、第１のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避する。受信中断中のデータのうち受信中断状態が所定時間以上継続している少なくとも１つの第２のデータがある場合、受信中断中のデータとは別のデータの受信要求があるか否かを判定する。別のデータの受信要求がない場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避する。別のデータの受信要求があった場合であって別のデータを受信するためのバッファが解放されている場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避し、別のデータの受信要求があった場合であって別のデータを受信するためのバッファが不足している場合、別のデータを受信するためのバッファを確保するよう、受信中断時間が長い第２のデータから順に、その一部のデータが占有しているバッファを解放する。

本実施例によれば、伝送側でデータが受信できない状態になった場合に、まずバッファを保持する。そして伝送側からデータが送信されない状態が所定時間以上経過し、さらに、新たな別のデータ受信が要求されたときにバッファを解放するようにする。その結果、保持されたバッファとプロセスは、受信側に蓄積されているバッファもそのまま一時停止されるので、ネットワークを介してのデータ受信のプロセスを停止した後において、データ復号再開（レジューム）がされたときでも大きな誤差を発生することなく、正確な位置からデータ再生ができることになる。また伝送側からデータが送信されない状態が所定時間以上経過し、さらに、新たな別のデータ受信が要求されたときにバッファを解放し、要求されたデータを受信するのでリソースが適度な状態で解放されるためにシステムの破綻が無くなる。

さらには、本実施例によれば、複数のデータを受信し、複数のバッファを経由してデータ復号処理をする場合においても、新たな別のデータ受信が要求され、かつ、全てのバッファが使用中のときに、伝送側からデータが送信されない状態が所定時間以上経過しているバッファのうち、経過時間が長いバッファを解放し、要求されたデータを受信するようにしたので、時間的に古い一時停止プロセスからバッファが解放されていくので、リソースが適度な状態で解放されるためにシステムの破綻が無くなる。以下、図面を参照して本発明の実施例について詳細に説明する。

図１は、本実施例に係るデータ送受信システムの構成を示すブロック図である。データ送受信システムは、左のオーディオビデオデータのサーバー（以下、「ＡＶ送信機」という）と、右のオーディオビデオデータのレシーバー（以下、「ＡＶ受信機」という）とがネットワークを経由して接続され構成される。ＡＶ送信機は、ＵＳＢ（Universal Serial Bus）１、チューナー２、ＨＤＤ（Hard disk drive）３、ＣＰＵ４、ネットワークバッファ５、およびポーズ手段６を有する。ＡＶ受信機は、ＣＰＵ７、デコードバッファ８、復号化手段９、ＡＶモニター１０、データ通信管理手段１１、バッファ管理手段１２、およびネットワークバッファ１３を有する。

ＨＤＤ３には、送信するＡＶデータが保存されている。このＡＶデータは、チューナー２からの受信データであっても、カムコーダーによって自分で撮影したＡＶデータをＵＳＢ１経由でＨＤＤ３に記録されたものであってもよい。ＨＤＤ３からＡＶデータを送信するとき、ＣＰＵ４は、ネットワークへ送信するためのコマンドを送信する。

図２は、ネットワークを介してＡＶ送信機からＡＶ受信機にＡＶデータを送信する送信手順を示すフローチャートである。図２においてコントローラは、ＡＶ送信機およびＡＶ受信機を操作すべくユーザが操作入力可能に設けられている。本実施例では、コントローラは、ネットワークを介してＡＶ送信機およびＡＶ受信機の各々にデータを送受信可能に設けられている。

まず、コントローラに設けられたＡＶ情報要求ボタンなどがユーザに押されると、コントローラは、ネットワークを介してＡＶ送信機にＡＶ情報要求コマンドを送信する。ＡＶ送信機のＣＰＵ４は、ＡＶ情報要求コマンドを受信すると、ＨＤＤ３に格納されたデータを参照してＡＶリストコマンドを構成し、ネットワークを介してコントローラに返送する。

コントローラには、ＡＶコンテンツを選択する選択ボタンが設けられている。ユーザは、受信したＡＶリストコマンドが示すＡＶコンテンツの中から、この選択ボタンを押すことにより、ＡＶ受信機に送信したいＡＶコンテンツを選択することができる。ユーザによってＡＶコンテンツが選択されると、コントローラは、ネットワークを介してＡＶ受信機にＡＶ受信要求コマンドを送信する。ＡＶ受信機のＣＰＵ７は、ＡＶ受信要求コマンドを受信すると、ＡＶコンテンツを受信するポート情報を指定してＡＶ受信許可コマンドをコントローラに返送する。

ＡＶ受信許可コマンドを受信すると、コントローラは、ＡＶ受信機から指定された受信ポート番号、ＡＶ受信機のＩＰアドレス、ＡＶコンテンツ識別情報をパラメータとして、ネットワークを介してＡＶ送信機にＡＶ送信要求コマンドを送信する。

ＡＶ送信機のＣＰＵ４は、ＡＶ送信要求コマンドを受信すると、ＨＤＤ３に格納されたデータを参照し、ＡＶコンテンツ識別情報で示されるＡＶコンテンツの有無を判定する。そのＡＶコンテンツが存在する場合、同時送信チャネル数や、既に別のＡＶ受信機に送信中か否か、などの状況を確認し、再生可能か否かを判定する。

ここで、要求されたＡＶコンテンツが再生不可能な状態であれば、ＣＰＵ４はネットワークを介して、コントローラに理由と共にＮＡＣＫを返送する。再生可能であればＣＰＵ４はコントローラに再生識別子をパラメータとしてＡＣＫを返送すると共に、ＨＤＤ３に対して、ネットワークバッファ５の未使用のチャネルｘにＡＶ受信機から要求されたＡＶコンテンツのデータの読み出しを指示する。再生識別子は以降、このチャネルｘを使用してＡＶコンテンツの伝送を識別するための情報である。

さらに、ＣＰＵ４はネットワークバッファ５の監視を開始する。所定時間毎（例えば１００ミリ秒毎とし、以下、１００ミリ秒毎に送信すると仮定する）に、チャネルｘからＡＶデータを１００ミリ秒分、ＡＶ受信機のＩＰアドレス、ポート番号に対して送信する。この時、送信するＡＶデータの送信サイズ、ＡＶコンテンツ全体中のオフセット等の情報も一緒に送信する。また、ジッタ、アンダーラン等を考慮し、３００ミリ秒分のＡＶデータがネットワークバッファ５に読み出された時点で、送信を開始する（場合によっては考慮せず、読み出しと同時に送信してもよい）。ＣＰＵ４は１００ミリ秒毎に、１００ミリ秒分の指定されたコンテンツのデータをから読み出し、指定されたチャネルｘにセットするようにＨＤＤ３に指示する。

ＡＶ受信機のＣＰＵ７は、ＡＶ送信機からＡＶデータを受信すると、ＡＶ送信機にＡＣＫを返送すると共に、受信したＡＶデータをネットワークバッファ１３に一旦蓄積する。そして、ネットワーク上のジッタやアンダーラン等を考慮し、ある程度、ネットワークバッファ１３に蓄積されると、デコードバッファ８に転送され、復号化手段９を介してＡＶモニター１０に再生される。

次に、ポーズについて説明する。コントローラには、ポーズボタン（一時停止ボタン）が設けられている。このポーズボタンがユーザによって押されることによりポーズ要求を取得すると、コントローラは、再生識別子をパラメータとして、ポーズコマンドをＡＶ送信機にネットワークを介して送信する。ＡＶ送信機のＣＰＵ４は、ネットワークを介してポーズコマンドを受信すると、ＨＤＤ３にポーズコマンドにより指定された識別子から、ＡＶコンテンツデータの読み出し停止を指示し、ネットワークバッファ５のチャネルｘの監視も停止する。そして、ポーズ手段６に指示して、再開時にＨＤＤ３から読み出す予定のオフセットを記憶する。

ＡＶ送信機のＣＰＵ４は、ネットワークを介してコントローラからレジュームコマンドを受信すると、その再生識別子を用いてポーズ手段６に次に読み出すべきオフセットを問い合わせ、ＨＤＤ３に続きからＡＶデータを読み出してチャネルｘにセットするように指示する。同時に、ネットワークバッファ５の監視を開始し、通常再生時と同様の処理を再開する。

図２において、ＡＶデータそれぞれにＡＣＫを返送しているが、ストリーム系のデータの場合はデータが欠落しても再送しない場合が多いため、そのような場合はＡＣＫの返送を省いても構わない。

図３は、本実施例に係る、ＡＶ情報要求コマンド、ＡＶリストコマンド、ＡＶ受信要求コマンド、ＡＶ受信許可コマンドなどの構成例を示す図である。ＡＶリストコマンドは、ＡＶリストであることを示すデータと、ＡＶ送信機が有する各ＡＶコンテンツの名称を示すＡＶコンテンツ情報識別子と、各ＡＶコンテンツのフォーマットを示すフォーマット識別情報、各ＡＶコンテンツのデータサイズを示すコンテンツサイズ等の属性情報を含む。

ＡＶ受信要求コマンドには、ＡＶ受信要求であることを示すデータと、ＡＶコンテンツ情報識別子と、フォーマット識別情報と、コンテンツサイズとを含む。図３に示す例では、ユーザに「誕生日」という名称のＡＶコンテンツが選択された例が示されている。

図２のフローの後に、ＡＶデータはネットワークバッファ５に一度、蓄えられ、ネットワークを経由して、図１の右側のＡＶ受信機へ送信される。なお、ポーズをかける場合にはＣＰＵ４からポーズ手段６にポーズをかける信号が伝送され、ポーズ手段はネットワークバッファ５に対し、データをネットワークへ送信することをポーズするように指示信号がだされて、ネットワークバッファ５はネットワークへの伝送をポーズする。ＡＶ受信機ではネットワークバッファ１３に一度蓄えられ、ＣＰＵ７で受信の管理がなされる。即ち、所定のサイズのパケット化されたデータで送られてくるので、どれだけの量のデータを受けたか、ある程度ネットワークバッファ１３に蓄積したものはデコードバッファ８へ伝送したりする制御を行う。デコードバッファに送られたデータは、ある程度蓄積され、所定の時刻になるとＡＶデータは復号化手段９によって復号されるため、データがデコードバッファ８から抜き取られる。

図４は、本実施例に係るデコーダーバッファの具体的な例を模式的に示す図である。図４のＡの位置からデータがデコードバッファに蓄積開始される。右上の傾きはバッファに入る転送レートである。縦軸はバッファに溜まっているデータの占有量、横軸は時間を示す。Ｂの位置になると第１の単位のデータが復号される。これは具体的には、ＡＶデータの主にビデオデータの１ピクチャー分に相当する。例えば地上波デジタルデータなどはＭＰＥＧ２によって可変レートで圧縮符号化されている。従って画面の複雑さや、各ピクチャーのテクスチャーの動き量などの状況により、各フレームに与えられる画像の符号量は異なる。そこでＢからＣへのバッファからデコーダーへ引き抜かれる量が、各ピクチャー単位で異なってくる。次のピクチャーはＤからＥ、その次はＦからＧであって、それぞれ異なっているのが分かる。

ただし、バッファには上限があって、そこまではバッファしてもよいが、それ以上は溜めることはできない。溜めた場合には情報ビットが欠落し、ＭＰＥＧではそのピクチャー、あるいは予測符号化されているリファレンスピクチャーである場合には、数ピクチャーのグループ単位で復号が出来なくなってしまうこともある。その上限ギリギリにまでバッファ占有したときにポーズがかかると、例えば図４のＹのようなところまで占有しているときに、タイムアウトが発生し、受信バッファやデータの復号用バッファにあるデータがフラッシュしてしまうと、次にレジュームした場合に正確な位置からのレジュームができなくなる。

即ち、送信側サーバーが何処までを送ったかの情報を持っているとしても、受信側クライアントのほうにある受信バッファやデータの復号用バッファにはどこまでのバッファが溜まっていたか（消費されていたか）の情報がフラッシュしてしまっているので、図４のＸからＹまでの時刻、即ち時間Ｓの期間が、誤差として発生する。ＡＶデータがＭＰＥＧなどのように圧縮符号化されているアプリケーションなどでは符号化しているピクチャーの符号量が変動するので、その期間が小さい符号量などであれば、バッファの値が上限に近い場合に、数多くのピクチャーのデータがバッファされていることになる。このためその分、バッファに溜まっているデータの再生時間が長い状態で溜まってしまうことになる。したがって、本来のポーズとポーズ解除における再生のタイミングと、ポーズしてからバッファをフラッシュして初めからバッファに溜めてからスタートということになると、前者と後者では再生位置が大きく違ってしまい、誤差が大きくなってしまう。

そこで本実施例ではＣＰＵ７がネットワークバッファを経由して、ＡＶ送信機のネットワークバッファと、ＡＶ受信機のネットワークバッファを繋ぐ、ネットワークのプロセスに対して、ポーズ手段６でポーズをかけた場合、所定の時間が掛かってもタイムアウトしてバッファフラッシュをしないようにＣＰＵ７からバッファ管理手段１２で、タイムアウトしてネットワークバッファがフラッシュしないように制御をかける。またその際、データ通信管理手段１１では、データ通信が停止してからどの程度の時間が経過したかを管理する。データ通信管理手段１１によってデータが送信されない状態が所定時間以上経過したと判断され、さらに、新たな別のデータ受信が要求されたときにはバッファ管理手段によってバッファを解放する。バッファを解放し、要求されたデータを受信することにより新たな要求がない限り、ポーズ状態が解消されたときにデータ復号処理が続きから再開する。

また、伝送プロセスが複数になる場合、そのプロセスが占有するバッファが複数あると考えられる。（実際は１つのバッファやメモリーでもその中を、複数のプロセスが分け合って使用するという意味で、複数のバッファを持つと表現する。）ネットワーク上の伝送装置からの複数のデータを受信し、複数のバッファを経由してデータ復号処理をする伝送場合には、新たな別のデータ受信が要求され、かつ、全てのバッファが使用中のときに、伝送装置からデータが送信されない状態が所定時間以上経過したかどうかをデータ通信管理手段において管理し、データ通信管理手段によってデータが送信されない状態が所定時間以上経過していると判断されたバッファのうち、経過時間が最も長いバッファをバッファ管理手段によって解放する。要求されたデータを受信することにより新たな要求がない限り、ポーズ状態が解消されたときにデータ復号処理が続きから再開する。

ここで複数のプロセスの発生する状態をさらに詳しく説明する。複数のＡＶ受信機でＡＶデータを送受信するプロセスが複数発生する場合がある。その場合にはプロセスが生成されるたびにネットワークバッファを分割して割り当て、各プロセスの付随する情報として、ネットワークバッファ状態管理テーブルにプロセスの状態、最後に受信した時刻を記憶しておく。

図５は、本実施例に係るネットワークバッファ状態管理テーブルを示す図である。この例では、ネットワークバッファを４分割しているので、４チャンネル分(プロセス４個分)同時に受信できる。プロセスの状態は何も再生してなければアイドル、再生中、一時停止中の３つの状態で管理する。プロセスの状態が再生中の場合は、所定の時間経過してデータを受信しなければタイムアウト発生と見なすが、まずは、プロセス状態を一時停止中に更新し、即座にはタイムアウト処理を行わない。ここで、全てのバッファを使用中に、新たな受信プロセスが生成されるとする。タイムアウトの判定として、プロセス状態が一時停止中であるプロセスの中で、受信時刻の古い順にタイムアウト判定を行うことにより、所定の個数のプロセスを待たせておいたなら、その古い順番にタイムアウトをする。

例えば、１０個のプロセスまでとＣＰＵ７に設定した場合には、１１番目のポーズのプロセスが指定されたら、１番目のプロセスは自動的にタイムアウトする。タイムアウトの時間は自由に設定する。なお、プロセスにはネットワークバッファ状態管理テーブルという仕組みを使うことにより、そのポーズプロセスが発生したときの時刻が記録されているので、その時刻情報を見ることにより、古いもの、新しいもの判断をＣＰＵ７ですることができる。ＡＶ受信機にはタイムアウト保持手段（図示せず）が設けられており、タイムアウト保持手段は、ＣＰＵ７からの指示信号によりプロセスの個数、タイムアウトをするタイミングを管理制御する。

デコードバッファに溜まったデータは、前記のようにデコードのタイミングによって（ＭＰＥＧにはＤＴＳ＝でコーディングタイムスタンプがある）そのピクチャーの復号が、復号化手段９によってなされる。またオーディオも同様に復号化手段９によってなされる。その後、復号されたＡＶデータはＡＶモニター１０にて再生され、ユーザに視聴可能とされる。

図６は、バッファの解放を行う場合と行わない場合のプロセスを示すフローチャートである。スタートから第１のステップでＣＰＵ４からＨＤＤ３にデータ送信指示を出す。次にステップ２でＣＰＵ７からＡＶ情報要求コマンドを出す。次にステップ３でＣＰＵ４がＡＶ情報要求コマンドを受けて各パラメータを返す。このパラメータとはＡＶ受信機から指定された受信ポート番号、ＡＶ受信機のＩＰアドレス、ＡＶコンテンツ識別情報などである。次にステップ４でＡＶデータをネットワークバッファ５に読み出して送信を開始する。次にステップ５にてＣＰＵ４からＨＤＤ３にポーズをかける。

次にステップ６にてデータが受信されない状態が所定時間以上経過したかどうかをデータ通信管理手段１１にて判断する。判断の結果、所定時間以上経過していない（ＮＯ）場合にはそのままカレントのステップ６へ戻る。所定時間以上経過している（ＹＥＳ）場合にはステップ７へ進む。ステップ７ではＣＰＵ７からバッファ管理手段１２でバッファを保持させる指示をさせる、且つ、プロセスなどを一時停止するように保持させる指示をする。次にステップ８にてバッファ管理手段１２にバッファを保持（タイムアウトをしない）させる。次にステップ９にてデータ通信管理手段１１によってデータの通信停止時刻を管理する。

次にステップ１０にて新たに別のデータ受信要求があったかどうかを判断する。もし新たに別のデータ受信要求が無かった（ＮＯ）の場合には、ステップ８に飛ぶ。新たに別のデータ受信要求があった（ＹＥＳ）の場合には、ステップ１１に進む。ステップ１１では、バッファが使用中かどうかを判断する。バッファが使用中で無い（ＮＯ）場合にはステップ１４に進む。ステップ１４では使用中でないバッファで受信を行い、終了する。バッファが使用中である（ＹＥＳ）の場合、ステップ１２に進み、ＣＰＵ７からバッファ管理手段１２にもっとも経過時間の長いバッファを解放するよう指示させる。ステップ１３では使用中のバッファを解放（タイムアウト）を行い終了する。

なお、ここでは、バッファの解放（タイムアウトすること）を、データ送信されない状態が所定時間以上続いたか、また、新たに別のデータ受信要求があったかによって判断をしたが、一時停止しているプロセスの個数で古いものからタイムアウトをするようにして判断してもよい。またＡＶ受信機においてのリソース（ポーズするたびに一時停止しておくバッファの量や、ＣＰＵの負荷の量など）によって、その値が所定以上になった場合に、古いものからタイムアウトをするようにしてもよい。また、ＵＳＢ１はＳＤメモリーであってもよく、チューナーは、外からのデータの受信が可能であれば、デジタルでもアナログでも、通信経路からであるシステムであってもよい。また、ネットワークは、ＩＰ接続でも特別なプロトコル接続であってもよく、パケットフォーマットも特に規制するものではない。

本発明は上述の各実施形態に限定されるものではなく、各実施形態の各要素を適宜組み合わせたものも、本発明の実施形態として有効である。また、当業者の知識に基づいて各種の設計変更等の変形を各実施形態に対して加えることも可能であり、そのような変形が加えられた実施形態も本発明の範囲に含まれうる。

１ＵＳＢ、２チューナー、３ＨＤＤ、４ＣＰＵ、５ネットワークバッファ、６ポーズ手段、７ＣＰＵ、８デコードバッファ、９復号化手段、１０ＡＶモニター、１１データ通信管理手段、１２バッファ管理手段、１３ネットワークバッファ。

Claims

復号処理を実行すべく、受信したデータを一時的にバッファに格納するデータ処理方法において、
第１のデータの受信が中断した場合に、第１のデータの受信中断状態が所定時間以上継続しているか否かを判定するステップと、
第１のデータの受信中断状態が前記所定時間まで継続していない場合、第１のデータのうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、
第１のデータの受信中断状態が前記所定時間以上継続している場合、第１のデータとは別の第２のデータの受信要求があるか否かを判定するステップと、
第２のデータの受信要求がない場合、前記一部のデータが占有しているバッファの解放を回避するステップと、
第２のデータの受信要求があった場合、前記一部のデータが占有しているバッファを第２のデータの受信のために解放するステップと、
を備えることを特徴とするデータ処理方法。
復号処理を実行すべく、受信したデータを一時的にバッファに格納するデータ処理方法において、
少なくとも１つの受信中断中のデータがある場合に、前記受信中断中のデータの各々について、受信中断状態が所定時間以上継続しているか否かを判定するステップと、
前記受信中断中のデータのうち受信中断状態が前記所定時間まで継続していない少なくとも１つの第１のデータがある場合、第１のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、
前記受信中断中のデータのうち受信中断状態が前記所定時間以上継続している少なくとも１つの第２のデータがある場合、前記受信中断中のデータとは別のデータの受信要求があるか否かを判定するステップと、
前記別のデータの受信要求がない場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、
前記別のデータの受信要求があった場合に、前記別のデータを受信するためのバッファが解放されているか否かを判定するステップと、
前記別のデータを受信するためのバッファが解放されている場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避するステップと、
前記別のデータを受信するためのバッファが不足している場合、前記別のデータを受信するためのバッファを確保するよう、受信中断時間が長い第２のデータから順に、その一部のデータが占有しているバッファを解放するステップと、
を備えることを特徴とするデータ処理方法。
受信したデータを一時的に格納するバッファと、
バッファに格納されたデータに復号処理を実行する復号化手段と、
バッファの解放を制御するバッファ管理手段と、
を備え、
前記バッファ管理手段は、第１のデータの受信が中断した場合、第１のデータの受信中断状態が所定時間まで継続していないときは第１のデータのうち既に受信した一部のデータが占有しているバッファの解放を回避し、第１のデータの受信中断状態が前記所定時間以上継続しているときは、第１のデータとは別の第２のデータの受信要求がない場合は前記一部のデータが占有しているバッファの解放を回避し、第２のデータの受信要求があった場合は前記一部のデータが占有しているバッファを第２のデータの受信のために解放することを特徴とするデータ処理装置。
受信したデータを一時的に格納するバッファと、
バッファに格納されたデータに復号処理を実行する復号化手段と、
バッファの解放を制御するバッファ管理手段と、
を備え、
前記バッファ管理手段は、
少なくとも１つの受信中断中のデータがある場合に、前記受信中断中のデータの各々について、受信中断状態が所定時間以上継続しているか否かを判定し、
前記受信中断中のデータのうち受信中断状態が前記所定時間まで継続していない少なくとも１つの第１のデータがある場合、第１のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避し、
前記受信中断中のデータのうち受信中断状態が前記所定時間以上継続している少なくとも１つの第２のデータがある場合、前記受信中断中のデータとは別のデータの受信要求があるか否かを判定し、
前記別のデータの受信要求がない場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避し、
前記別のデータの受信要求があった場合であって前記別のデータを受信するためのバッファが解放されている場合、第２のデータの各々のうち既に受信した一部のデータが占有しているバッファの解放を回避し、
前記別のデータの受信要求があった場合であって前記別のデータを受信するためのバッファが不足している場合、前記別のデータを受信するためのバッファを確保するよう、受信中断時間が長い第２のデータから順に、その一部のデータが占有しているバッファを解放することを特徴とするデータ処理装置。