(57)【特許請求の範囲】
【請求項１】
符号化されたビットストリームを入力データとして入力し、前記入力データを修正して出力するデータ修正装置であって、
前記入力データにおけるエラー位置の情報を含むエラー検出データと、前記入力データのデータ構造を再構成したビデオストリームとを出力するシステムデコーダ部と、
前記エラー検出データを前記システムデコーダ部より取得し、前記エラー検出データを用いて得られた前記ビデオストリームにおけるエラーデータ部分を用いて、前記システムデコーダ部から出力される前記ビデオストリームを修正する処理を行うデータ処理部とを備え、
前記ビデオストリームは、フレーム単位で符号化されたデータを含み、
前記フレーム単位で符号化されたデータは、前記フレームの符号化情報を格納するフレームヘッダ情報を含み、
前記データ処理部は、前記データ処理部に入力される前記ビデオストリームの前記フレームヘッダ情報の少なくとも一部が前記エラーデータ部分に含まれ、かつ前記フレームの符号化データの中に前記フレームヘッダ情報以外で、前記フレームヘッダ情報に相当する情報が存在する場合に、前記フレームヘッダに相当する情報を用いて前記フレームにおける前記フレームヘッダ情報を復元する処理を行って、処理後のビデオストリームを出力する
ことを特徴とするデータ修正装置。
【請求項２】
符号化されたビットストリームを入力データとして入力し、前記入力データを修正して出力するデータ修正装置であって、
前記入力データにおけるエラー位置の情報を含むエラー検出データと、前記入力データのデータ構造を再構成したビデオストリームとを出力するシステムデコーダ部と、
前記エラー検出データを前記システムデコーダ部より取得し、前記エラー検出データを用いて得られた前記ビデオストリームにおけるエラーデータ部分を用いて、前記システムデコーダ部から出力される前記ビデオストリームを修正する処理を行うデータ処理部とを備え、
前記ビデオストリームは、フレーム単位で符号化されたデータを含み、
前記フレーム単位で符号化されたデータは前記フレームの符号化情報を格納するフレームヘッダ情報を含み、
前記フレームヘッダ情報は、前記フレームヘッダ情報に対応するフレームの表示時刻情報を含み、
前記データ処理部は、前記データ処理部に入力される前記ビデオストリームの前記フレームヘッダ情報の少なくとも一部が前記エラーデータ部分に含まれ、かつ前記フレームの符号化データの中に前記フレームヘッダ情報以外で、前記フレームヘッダ情報に相当する情報が存在しない場合に、前記フレーム画像の時間的に直前のフレームと同じ画像となるように符号化データを修正する処理を行い、前記フレームヘッダの表示時刻情報を前記フレームの時間的に直前のフレームの表示時刻と前記フレームの時間的に直後のフレームの表示時刻との中間の時刻の情報に修正する処理を行って、処理後のビデオストリームを出力する
ことを特徴とするデータ修正装置。
【請求項３】
符号化されたビットストリームを入力データとして入力し、前記入力データを修正して出力するデータ修正装置であって、
前記入力データにおけるエラー位置の情報を含むエラー検出データと、前記入力データのデータ構造を再構成したビデオストリームとを出力するシステムデコーダ部と、
前記エラー検出データを前記システムデコーダ部より取得し、前記エラー検出データを用いて得られた前記ビデオストリームにおけるエラーデータ部分を用いて、前記システムデコーダ部から出力される前記ビデオストリームを修正する処理を行うデータ処理部とを備え、
前記ビデオストリームは、フレーム単位で符号化されたデータを含み、
前記フレーム単位で符号化されたデータは、マクロブロック単位で符号化されたデータを複数含むビデオパケットを含み、
前記ビデオパケットは前記ビデオパケットに関する情報を格納するビデオパケットヘッダ情報を含み、
前記ビデオパケットヘッダ情報は前記ビデオパケットが含むマクロブロックの位置情報を含み、
前記データ処理部は、前記データ処理部に入力される前記ビデオストリームの前記マクロブロックの符号化データの少なくとも一部が前記エラーデータ部分に含まれる場合に、当該マクロブロックの符号化データを含むビデオパケットの直後のビデオパケットのビデオパケットヘッダに含まれるマクロブロックの位置情報を用いて、当該マクロブロックの符号化データを含むビデオパケットの符号化データを修正する処理を行って、処理後のビデオストリームを出力する
ことを特徴とするデータ修正装置。
【請求項４】
符号化されたビットストリームを入力データとして入力し、前記入力データを修正して出力するデータ修正装置であって、
前記入力データにおけるエラー位置の情報を含むエラー検出データと、前記入力データのデータ構造を再構成したビデオストリームとを出力するシステムデコーダ部と、
前記エラー検出データを前記システムデコーダ部より取得し、前記エラー検出データを用いて得られた前記ビデオストリームにおけるエラーデータ部分を用いて、前記システムデコーダ部から出力される前記ビデオストリームを修正する処理を行うデータ処理部とを備え、
前記ビデオストリームは、フレーム単位で符号化されたデータを含み、
前記フレーム単位で符号化されたデータは、マクロブロック単位で符号化されたデータを含み、
前記マクロブロック単位で符号化されたデータはＤＣＴ変換を用いて符号化され、該ＤＣＴ変換におけるＡＣ成分とＤＣ成分を含み、
前記データ処理部は、前記データ処理部に入力される前記ビデオストリームの前記マクロブロックの少なくとも一部が前記エラーデータ部分に含まれる場合に、前記ＡＣ成分と前記ＤＣ成分のうち、少なくとも一方を削除する処理を行って、処理後のビデオストリームを出力する
ことを特徴とするデータ修正装置。
【請求項５】
複数のパケットデータが入力され、到着していないパケットまたは伝送エラーを伴うパケットの部分をエラー検出用のユニークワードとするとともに、到着しているパケットのペイロード部と前記ユニークワードとをアプリケーションデコーダが再生する順序に入れ替えた信号として出力するシステムデコーダ部と、
前記信号から検出したユニークワードの位置情報に基づいて前記信号の修正処理を行うデータ処理部とを備え、
前記データ処理部は、前記信号がビデオデータである場合、フレーム画像のデータに含まれるタイムスタンプ情報を変更する処理を行って、処理後の信号を出力する
ことを特徴とするデータ修正装置。
【請求項６】
複数のパケットデータが入力され、到着していないパケットまたは伝送エラーを伴うパケットの部分をエラー検出用のユニークワードとするとともに、到着しているパケットのペイロード部と前記ユニークワードとをアプリケーションデコーダが再生する順序に入れ替えた信号として出力するシステムデコーダ部と、
前記信号から検出したユニークワードの位置情報に基づいて前記信号の修正処理を行うデータ処理部とを備え、
前記データ処理部は、前記信号が複数の符号化ブロックを１個のビデオパケットとして扱うことが可能なブロック単位の符号化アルゴリズムにて生成されたビデオデータである場合、ビデオパケットのヘッダ部に含まれるブロック位置情報を変更する処理を行って、処理後の信号を出力する
ことを特徴とするデータ修正装置。
【請求項７】
複数のパケットデータが入力され、到着していないパケットまたは伝送エラーを伴うパケットの部分をエラー検出用のユニークワードとするとともに、到着しているパケットのペイロード部と前記ユニークワードとをアプリケーションデコーダが再生する順序に入れ替えた信号として出力するシステムデコーダ部と、
前記信号から検出したユニークワードの位置情報に基づいて前記信号の修正処理を行うデータ処理部とを備え、
前記データ処理部は、前記信号が複数の符号化ブロックを１個のビデオパケットとして扱うことが可能なブロック単位の符号化アルゴリズムにて生成されたビデオデータである場合、ビデオパケット内にて処理すべき符号化ブロックの数を変更する処理を行って、処理後の信号を出力する
ことを特徴とするデータ修正装置。
【請求項８】
複数のパケットデータを入力し、
到着していないパケットまたは伝送エラーを伴うパケットの部分にエラー検出用のユニークワードを出力し、
到着しているパケットのペイロード部と前記ユニークワードとをアプリケーションデコーダが再生する順序に入れ替えた信号を生成し、
前記信号からユニークワードを検出し、
前記信号がビデオデータである場合、フレーム画像のデータに含まれるタイムスタンプ情報を変更する処理を含む修正を行う
ことを特徴とするデータ修正方法。
【請求項９】
複数のパケットデータを入力し、
前記到着していないパケットまたは伝送エラーを伴うパケットの部分にエラー検出用のユニークワードを出力し、
到着しているパケットのペイロード部と前記ユニークワードとをアプリケーションデコーダが再生する順序に入れ替えた信号を生成し、
前記信号からユニークワードを検出し、
前記信号が複数の符号化ブロックをひとつのビデオパケットとして扱うことが可能なブロック単位の符号化アルゴリズムにて生成されたビデオデータである場合、ビデオパケットのヘッダ部に含まれるブロック位置情報を変更する処理を含む修正を行う
ことを特徴とするデータ修正方法。
【請求項１０】
複数のパケットデータを入力し、
前記到着していないパケットまたは伝送エラーを伴うパケットの部分にエラー検出用のユニークワードを出力し、
到着しているパケットのペイロード部と前記ユニークワードとをアプリケーションデコーダが再生する順序に入れ替えた信号を生成し、
前記信号からユニークワードを検出し、
前記信号が複数の符号化ブロックをひとつのビデオパケットとして扱うことが可能なブロック単位の符号化アルゴリズムにて生成されたビデオデータである場合、ビデオパケット内にて処理すべき符号化ブロックの数を変更する処理を含む修正を行う
ことを特徴とするデータ修正方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、ディジタルメディアデータの無線通信動画像符号化技術に関するものであり、特に、パケットロスが生じた場合の受信データ処理に関するものである。
【０００２】
【従来の技術】
次世代無線通信サービスとして、データ圧縮され、配信サーバに蓄積されているディジタルメディアデータファイルを、携帯電話のような無線携帯端末にて受信・再生することが想定されている。このような無線通信サービスで、パケットロス（伝送中のパケットデータの損失）が生じた時の通信の形態としては、以下の２点が想定されている。
1) 損失したパケット(データの単位、データのかたまりの総称)の再送を行わないコネクションレス型のトランスポート層プロトコル(例えば、UDP: User Datagram Protocol, RTP: Realtime Transport Protocol)を使用し、データを受信しながら再生するストリーミング、
2) 損失したパケットの再送を可能とするコネクション型のトランスポート層プロトコル(例えば、TCP: Transmission Control Protocol、全てのメッセージに対して、エラー検出や応答確認処理を行うため、信頼性を要求するアプリケーションに適している。但し、伝送路の状態が悪いと、頻繁な確認応答や再送要求により、スループット低下が起こりやすい)を使用し、全データを受信し、一旦蓄積してから再生処理を開始するダウンロード。(UDP, RTP, TCPの詳細は後述する)
ここで、トランスポート層とは、異機種間通信を可能にするネットワークアーキテクチャの標準参照モデル(OSI: Open Systems Interconnection, 開放型システム相互接続、通信回線に近いところから物理層-データリンク層-ネットワーク層-トランスポート層)において、「データを確実に相手に届ける」役割を果たすレベルのこと。「アドレスの管理や経路の選択を行う」役割を果たすIP(Internet Protocol)はネットワーク層にあたる。上記２通りのサービス形態のうち、ダウンロードでは、データ損失を伴う全てのパケットに対して再送要求をかけるため、受信データに伝送エラーが含まれることはない。一方、ストリーミングサービスでは、データ損失を伴うパケットが存在しても再送されないため、受信データに伝送エラーが含まれる可能性がある。
【０００３】
ここで、具体的な事例を示す。図２は携帯電話のシステム構成を示す図であり、図３は、送信されるパケットを表したものである。この携帯電話端末２００に向けて、図３に示すトランスポート層のパケット列(１種類のメディアデータ)が送信された場合を考える。TCP、UDP-RTPに関わらずトランスポート層の１パケットは、トランスポート層のヘッダ部（４１１，４２１，４３１，４４１，４５１）とペイロード部（４１２，４２２，４３２，４４２，４５２）にて構成されている。この例では、ペイロード部は実際のメディアデータである。ヘッダ部には、ペイロード部のデータ量 (バイト単位)、パケットの通し番号(シーケンス番号)、ペイロードタイプ(RTPの場合のみ、TCPでは１度に複数タイプのデータを扱うことはない。ビデオデータ、オーディオデータの識別をこのデータにて行う)ならびにタイムスタンプ(RTPの場合のみ)等が書かれている。まず、アンテナ２０１から受信した無線信号は、無線インタフェース部２０２にて電気的に変換され、データリンク層プロトコルのパケット２０３の形式でシステムデコーダ２０５に入力される。システムデコーダ２０５では、入力されたデータリンク層プロトコルのパケットがネットワーク層のパケット、トランスポート層のパケットへと順にプロトコル変換され、トランスポート層のペイロード部だけがメモリ２０７に出力される。また、システムデコーダでは、パケット内のエラー検出処理や、各パケットにおけるペイロードタイプの識別(RTPの場合のみ)等も行う。更に、異なるペイロードタイプのメディアデータが同時に配信されている場合には、ペイロードタイプ別にメディアデータを構成し、共に互いに同期を取りながらメモリ２０７に出力される。
【０００４】
トランスポート層のプロトコルがTCPである場合には、システムデコーダは、エラーなく到達した各パケットについて、応答確認情報２０４を無線インタフェース部２０２に返答する。これらの応答確認情報は、無線インタフェース部２０２にて無線信号に変換され、送信側に返信される。送信側では、送信したパケットの応答確認を待ってから次のパケットの送信処理を行うが(複数のパケットを並列に処理することも可能)、送信から一定時間が経過しても応答確認が到達しない場合には、そのパケットを携帯電話端末２００に再送する。そのため、TCPではパケットロスは発生せず、図４の２０６０に示されるようなペイロード部のみから成るデータがペイロードデータ２０６としてメモリ２０７に出力される。ここで言うペイロードデータとは、一般的に、ダウンロードの場合には、画像・音声等をまとめたファイルフォーマットのデータとなり、具体的には、MPEG-4のMP4ファイルフォーマット、アップル社のQuick Time、Microsoft社のWMT(Windows Media Technology)などがある。
【０００５】
トランスポート層のプロトコルがUDP-RTPである場合には、システムデコーダは、応答確認を行わないため、パケットロスは許容される。例えば、図３の第２パケット(421及び422)がシステムデコーダに到着しなかった場合、あるいは第２パケットに伝送エラーが含まれている場合には、図５の２０６１に示されるような第２パケットを除いたペイロード部のみから成るデータがペイロードデータ２０６としてメモリ２０７に出力される。ここで言うペイロードデータとは、ストリーミングの場合には、一般にビデオ符号化データのパケットとオーディオ符号化データのパケットが混成されたデータとなる。このように複数のメディアデータ(例えば、ビデオデータとオーディオデータ)が同時に配信されており、同時に再生する必要がある場合には、システムデコーダ２０５にて、RTPパケットのヘッダ部に含まれているペイロードタイプによって各パケットが関連するメディアデコーダ(例えば、ビデオデコーダ、オーディオデコーダ)の種類が解読され、異なる種類のメディアデータとしてメモリ２０７に出力する必要がある。
その後、メモリ２０７に蓄積されたデータは、ストリーミングの場合には順次、最終パケットが到達した時点でメディアデータ２０８としてアプリケーションデコーダ２０９に出力される。なお、本明細書では、アプリケーションデコーダ２０９を、ファイルフォーマットのファイルデコーダならびに、ビデオデコーダ、オーディオデコーダなどのメディアデコーダの総称とし、アプリケーションデコーダと示した場合には、内部の構成は限定しないことにする。アプリケーションデコーダでは、ロスパケットの誤り隠蔽処理を行いつつ、タイミングをはかって各メディアデータの復元・再生処理を行う。但し、メディアデコーダに含まれる誤り隠蔽処理は標準化されていないため、メディアデータ２０８にパケットロスが含まれる場合の再生画像の画質や音声品質は、誤り隠蔽処理の性能によって異なることになる。
【０００６】
【発明が解決しようとする課題】
伝送中にパケットロスが発生した場合、アプリケーションデコーダに渡されるメディアデータは、ロスが発生したパケットのペイロードを省略した形式となる。一般にアプリケーションデコーダでは、適用標準デコード方式に含まれないデータの組み合わせを入力データ内に発見したときに伝送誤りが発生していると判断する。そのため、ロスしたパケットの前後のパケットを結合したデータが適用標準デコード方式に含まれる組み合わせとなっていた場合、伝送誤りの正確な位置を検出することができない。
【０００７】
また、パケットロスを含むデータを高画質で再現するためには、アプリケーションデコーダが伝送誤りを検出し、エラーの影響が画質に現れないように制御する必要がある。このような誤り訂正処理はデコーダの処理量を増加させるため、製品価格や消費電力の関係で高速なプロセッサを使用できないアプリケーションでは、再生処理速度や画像サイズの面で要求を十分に満たせないことになる。
【０００８】
【課題を解決するための手段】
本発明の一実施の態様は、例えば特許請求の範囲に記載されるように構成すればよい。
【０００９】
【発明の実施の形態】
まず、図２、図３８、図３９、図６ならびに図７にて、パケットロスの発生を検出する仕組みを考える。図６は、図２に示すシステムデコーダ２０５の内部構成を示したものである。
入力されたパケットデータは、まず、パケット処理部３０１にてトランスポート層のパケットとへ変換される。
トランスポート層のプロトコルがUDP-RTPの場合には、各UDPパケットのヘッダ部に含まれているエラー検出情報を解析し、受信パケットがエラーを含んでいる場合には、パケット処理部３０１にてそのパケットを破棄する。RTPパケットは、UDPパケットのペイロード部にあたり、ペイロードデータと、シーケンス番号ならびにペイロードタイプ情報を含むRTPヘッダにて構成されている。そのため、後に送信されたパケットが先に受信側に到着した場合でも、システムデコーダのメディアデータ再構成部３０８にて送信された順序に入れ替えることが可能となる。そこで、受信したUDPパケットがエラーを含んでいない場合には、RTPパケットを解析し、ペイロードデータ３０７と、タイムスタンプ・シーケンス番号・ペイロードタイプ８０１をメディアデータ再構成部３０８に出力する。この際、タイムスタンプ・シーケンス番号・ペイロードタイプ８０１をパケットロス検出部８０２にも出力する。これにより、パケットロス検出部８０２では、シーケンス番号とペイロードタイプを解析することで、到着していないパケットデータならびに伝送エラーを伴うパケットデータをペイロードタイプ別に検出することが可能となる。具体的には、メディアデータ再構成部３０８から出力すべきタイミングになっても、シーケンス番号とペイロードタイプがパケットロス検出部８０２に届いていないパケットを、ロスパケットであると判定する。なお、ペイロードデータ３０７と、タイムスタンプ・シーケンス番号・ペイロードタイプ８０１を受け取ったメディアデータ再構成部３０８では、各RTPパケットのシーケンス番号とペイロードタイプに従って、ペイロードタイプ毎にパケット列の順序の入れ替える操作を行う。例えば、図７の(a)のように、「あるペイロードタイプにおける２番目のパケット（４２１と４２２）が未着信」で、「通信に使用したネットワークの状況により、そのペイロードタイプのパケットが、第１パケット、第４パケット、第５パケット，第３パケットの順序で携帯端末側に着信した」場合を想定する。この場合、パケット処理部３０１は、到着したパケットを到着順（４１１と４１２，４４１と４４２，４５１と４５２，４３１と４３２）に処理し、図７の(b)に示すように４１２，４４２，４５２，４３２からなるペイロードデータ列３０７とRTPヘッダ部のタイムスタンプ・シーケンス番号・ペイロードタイプ列８０１(図中では、シーケンス番号のみを表示している)に分けてメディアデータ再構成部３０８に対して出力する。メディアデータ再構成部３０８では、各RTPパケットのシーケンス番号ならびにペイロードタイプに従って、ペイロードタイプ毎にパケット列の順序の入れ替える操作を行う。図７の例では、図５に示すようなペイロードデータ２０６１が、システムデコーダとアプリケーションとのインタフェースの役割を果たすメディアデータ出力部３１０を通してメモリ２０７に出力される。メディアデータ再構成部３０８がメディアデータ出力部３１０に各ペイロードデータを出力するタイミングは、一般に各RTPパケットに含まれるタイムスタンプによって管理されるが、アプリケーションデコーダの再生状況を考慮しながら制御することも可能である。
図３８は携帯電話端末の別の実施例を示す図で、２種類のメディアデータ(ビデオデータとオーディオデータ)がRTPにてストリーミング配信された場合について示している。図３８では、図２に示した携帯電話端末２００と、システムデコーダからアプリケーションデコーダへのデータの流れの点で異なる。
この場合には、RTPパケットヘッダ部のペイロードタイプは、ビデオデータあるいはオーディオデータを示している。システムデコーダ２０５１は受信した各RTPパケットのヘッダ部に記載されているペイロードタイプとシーケンス番号を調査し、ビデオデータとオーディオデータに分け、それぞれシーケンス番号順にペイロードデータ２０６１をメモリ２０７１に出力する。この際の各ペイロードの出力タイミングは、RTPパケットヘッダ部のタイムスタンプを参考に、再生時にビデオとオーディオ間で互いに同期が取れるように決められる。メモリ２０７１に蓄積された各メディアデータ２０８１は、それぞれ再生単位のデータ量に達した時点で、アプリケーションデコーダ２０９１内のビデオデコーダならびにオーディオデコーダに入力され、再生処理される。
【００１０】
一方、トランスポート層のプロトコルがTCPである場合には、各TCPパケットのヘッダ部に含まれているエラー検出情報を解析し、エラー検出結果３０２を再送判定部３０４に渡す。その際、受信パケットがエラーを含んでいる場合には、そのパケットを破棄する。再送判定部３０４では、エラー検出結果３０２が「エラーなし」を示している場合には、応答確認情報３０５を応答確認部３０６に通知する。この応答確認情報３０５は、応答確認部３０６にて無線信号２０４に変換され、無線インタフェース部２０２を通して送信側に通知される。送信側では、送信から一定時間が経過しても応答確認が到達しないパケットを携帯電話端末２００に再送する。プロトコルがTCPである場合には、送信側のパケット送信は応答確認の到着状況を考慮して行われており、基本的に不正なパケットは発生しない。しかしながら、最近では、ダウンロードの信頼性とストリーミングのリアルタイム性の中間にあたる性能を持つサービスとして、擬似ストリーミングも提案されている。この擬似ストリーミングは、「ダウンロードと同様に信頼性の高いコネクション型のトランスポート層プロトコルを使用するが、メディアデータを数個のファイルに分けて送信することにより、再生に必要な全データの受信を待たずに受信したファイル内のメディアデータから適宜再生する」というものである。ダウンロードは、通信の信頼性は高いが、ファイルが完全に受信し終わるまで再生処理を開始することができない。そのため、携帯電話のように大きなメモリを組み込めない端末では、再生時間の長いメディアデータは受信できないという問題がある。そこで、送信側にて、予めメディアデータを分割しておき、到着したファイルから再生処理を行うことで、処理が終わったファイルをメモリから削除していくという方法が有効と成る。しかしながら、無線通信にて擬似ストリーミングを行う場合には、パケットの再送が頻繁に発生すると、あるファイルの再生が終了しても、次のファイルが到着せず、再生を一時停止しなければならないという問題が発生する。そこで、擬似ストリーミングでは、TCPのように送信側とのコネクションを持つ通信方式であっても、ある程度のパケットエラーを許容する仕組みを取り入れる必要が生じてくる。なお、このパケットエラーを許容する方法は、ユーザ指令からの遅延等を考えた場合、ダウンロードであっても有効となる。
【００１１】
TCPにてパケットロスを許容する場合のパケットロス検出方法は、パケットロスを許容する方法そのものである。パケットロスを許容するには、送信側あるいは端末側のいずれかで応答確認手順を制御すればよい。送信側で制御するには、一定時間が経過しても応答確認が到達しない場合や再送回数が一定回数を超えた場合などの条件で、応答確認の到達をあきらめることで実現される。この場合、パケットロスの発生は、TCPパケットヘッダ部のシーケンス番号列にて確認できる(TCPでは、同時に応答確認を行うパケット数が端末側に通知されるため、その条件より大きなシーケンス番号を持つパケットが着信した時点でパケットロスの発生が判断できる)。しかし、この方法では端末側のアプリケーションデコーダにおける再生処理の進行状況を応答確認手順の制御に反映することができないため、各ファイルの処理時間の推定値と実値と間にズレがあった場合には、再生処理を一時停止せざるを得ない状況が生じる可能性がある。
そこで、次に端末側で応答確認処理を制御する方法について考える。具体的には、図６の再送判定部３０４とパケットロス検出部８０２を利用する。パケット処理部３０１は、各TCPパケットのヘッダ部に含まれているエラー検出情報を解析し、エラー検出結果３０２を再送判定部３０４に渡す。この際、受信パケットがエラーを含んでいる場合には、そのパケットを破棄する。一方、受信パケットがエラーを含んでいない場合には、TCPパケットを解析し、ペイロードデータ３０７と、シーケンス番号８０１(TCPには、ペイロードタイプは存在しない)をメディアデータ再構成部３０８に出力する。同時にシーケンス番号８０１をパケットロス検出部８０２に出力する。これにより、パケットロス検出部８０２では、シーケンス番号を解析することで、受信していないパケットを検出することが可能となる。具体的には、パケット処理部３０１からシーケンス番号が届いていないパケットを、受信していないパケットであると判定する。パケットロス検出部８０２では、前後のパケットが受信された後、規定時間(システムデコーダにて制御)が経過しても受信されないパケットをロスパケットとし、そのシーケンス番号８０７を再送判定部３０４に通知する。再送判定部３０４では、ロスパケットの再送により再生処理に支障があるか否かを判断する。そして再送を待つと再生処理遅延の面で問題があると判断した場合には、応答確認情報３０５を応答確認部３０６に通知するとともに、再送を行わないことを示す再送判定結果・シーケンス番号３０３をパケットロス検出部８０２に返答する。再送を待っても再生処理が滞りなく進行すると判断できる場合には、再送を行うことを示す再送判定結果・シーケンス番号３０３をパケットロス検出部８０２に返答する。この返答結果から、パケットロス検出部８０２は、メディアデータ再構成部３０８にて受信できていないパケットが、再送待ちのパケット(再送を行うことを示す再送判定結果が通知されている)であるか、パケットロスとして許容されたパケットであるか(再送を行わないことを示す再送判定結果が通知されている)が判断できる。そして、再送待ちのパケットについては、規定時間(システムデコーダにて制御)経過しても受信しない場合には、再度、再送判定部３０４に、シーケンス番号８０７を通知する。再送判定部３０４では、再送回数も考慮に入れて、再送要求の可能性について判定を行う。なお、再送判定部３０４がロスパケットと判定した後で、受信したパケットについては、通常通り処理することで情報の書き換えることも可能となる。このような手順で、ペイロードデータ３０７とシーケンス番号を受け取ったメディアデータ再構成部３０８では、各TCPパケットのシーケンス番号に従って、受信パケットの出力順序を入れ替える操作が行われる。入れ替え後、メディアデータ再構成部３０８がメディアデータ出力部３１０にペイロードデータを出力するタイミングは、一般に、一定の時間間隔で制御されるが、アプリケーションデコーダの再生状況を考慮しながら制御することも可能である。図３９は携帯電話端末のさらなる実施例を示す図で、２種類のメディアデータ(ビデオデータとオーディオデータ)を１つのファイルに統合・蓄積したMP4ファイルフォーマットデータがTCPにて擬似ストリーミング配信された場合について示している。図３９では、図２に示した携帯電話端末２００と、システムデコーダからアプリケーションデコーダへのデータの流れが異なっている。
システムデコーダ２０５２はTCPパケットヘッダ部のシーケンス番号を調査し、シーケンス番号順にペイロードデータ２０６２をメモリ２０７２に出力する。この際の各ペイロードの出力タイミングは、アプリケーションデコーダにおけるメディアデータの処理状況を考慮して決める。また、システムデコーダにおけるロスパケットの再送制御にもアプリケーションデコーダでの処理状況を反映する。メモリ２０７２に蓄積されたメディアデータ２０８２は、１つのファイルフォーマットデータとして成立した時点で、アプリケーションデコーダ２０９２内のファイルデコーダに入力される。ファイルデコーダでは、ファイルヘッダの情報からファイル内の各メディアデータ(ここでは、ビデオデータとオーディオデータが含まれていることを想定)を取りだし、それぞれビデオデコーダならびにオーディオデコーダに入力される。
図４０に携帯電話端末の別の実施例を、図４１にシステムデコーダの別の実施例を示し、アプリケーションデコーダでの処理状況を考慮して、再送判定部３０４にてロスパケットならびにエラーパケットの再送要求判定を行うためのデータの流れを説明する。図４０に示したデータ２１０ならびに２１１が処理状況関連情報にあたる。データ２１１としては、メモリ内の未処理データの残量、データ２１０としては、再生遅延の発生状況、フレームレートならびにビットレートなどが含まれる。これらのデータは、図４１の再送判定部３０４に送られる。再送判定部３０４では、データ２１１により得られるデータ残量と、データ２１０から得られるデータの消費速度に関する情報、さらに再送パケットが到達するにかかる時間の推定値(それまでのデータ到達状況から推測する)、そのパケットの重要性(例えば、ファイルフォーマットデータのヘッダ部やビデオデータのシーケンスヘッダ部を失うとデータ全体の再生が困難となる)等から、パケット再送待ちがアプリケーションデコーダに与える影響を推定する。
【００１２】
TCPにおいてパケットロスを制御する方法としては、上記以外に、送信側と受信端末側の双方で制御することも可能である。この場合には、応答確認情報以外に、再送中止要求や再送要求を端末側から送る仕組みを作ることでより高速で緻密な制御が可能となる。
【００１３】
以上説明したTCPを利用した擬似ストリーミングでは、１回の通信で１種類のメディアデータしか扱えないという問題がある。そのため、メディアデータを分割した各ファイルにはファイルヘッダをつけなければならず、通信容量の増大を招く可能性がある。そこで、擬似ストリーミングでは、TCP-RTPという通信手段も有効である。ここでは、端末側で応答確認処理を制御する方法についてTCP-RTPの仕組みを図６にて説明する。パケット処理部３０１は、各TCPパケットのヘッダ部に含まれているエラー検出情報を解析し、エラー検出結果３０２を再送判定部３０４に渡す。この際、受信パケットがエラーを含んでいる場合には、そのパケットを破棄する。一方、受信パケットがエラーを含んでいない場合には、TCPパケットヘッダとTCPペイロードに含まれるRTPヘッダを解析し、RTPペイロードデータ３０７と、TCPシーケンス番号・RTPタイムスタンプ・RTPシーケンス番号・RTPペイロードタイプ８０１をメディアデータ再構成部３０８に出力する。同時にTCPシーケンス番号・RTPタイムスタンプ・RTPシーケンス番号・RTPペイロードタイプ８０１をパケットロス検出部８０２に出力する。これにより、パケットロス検出部８０２では、TCPシーケンス番号、RTPペイロードタイプ、RTPシーケンス番号を解析することで、受信していないRTPパケットとそのペイロードタイプを検出することが可能となる。具体的には、パケット処理部３０１からTCPシーケンス番号が届いていないパケットを、受信していないパケットであると判定し、RTPペイロードタイプとRTPシーケンス番号からその種別を判定する。パケットロス検出部８０２では、前後のTCPパケットが受信された後、規定時間(システムデコーダにて制御)が経過しても受信されないTCPパケットをロスパケットとし、そのTCPシーケンス番号８０７を再送判定部３０４に通知する。再送判定部３０４では、ロスパケットの再送により再生処理に支障があるか否かを判断する。そして再送を待つと再生処理遅延の面で問題があると判断した場合には、応答確認情報３０５を応答確認部３０６に通知するとともに、再送を行わないことを示す再送判定結果・TCPシーケンス番号３０３をパケットロス検出部８０２に返答する。再送を待っても再生処理が滞りなく進行すると判断できる場合には、再送を行うことを示す再送判定結果・TCPシーケンス番号３０３をパケットロス検出部８０２に返答する。この返答結果から、パケットロス検出部８０２は、メディアデータ再構成部３０８にて受信できていないTCPパケットが、再送待ちのパケット(再送を行うことを示す再送判定結果が通知されている)であるか、パケットロスとして許容されたパケットであるか(再送を行わないことを示す再送判定結果が通知されている)が判断できる。そして、再送待ちのパケットについては、規定時間(システムデコーダにて制御)経過しても受信しない場合には、再度、再送判定部３０４に、TCPシーケンス番号８０７を通知する。再送判定部３０４では、再送回数も考慮に入れて、再送要求の可能性について判定を行う。なお、再送判定部３０４がロスパケットと判定した後で、受信したパケットについては、通常通り処理することで情報を書き換えることも可能となる。このような手順で、ペイロードデータ３０７とTCPシーケンス番号・RTP��イムスタンプ・RTPシーケンス番号・RTPペイロードタイプを受け取ったメディアデータ再構成部３０８では、各RTPパケットのシーケンス番号ならびにペイロードタイプに従って、ペイロードタイプ毎にパケット列の順序の入れ替える操作が行われる。メディアデータ再構成部３０８がメディアデータ出力部３１０に各ペイロードデータを出力するタイミングについては、各RTPパケットに含まれるタイムスタンプとアプリケーションデコーダの再生状況を考慮しながら制御する方法が有効である。システムデコーダから出力された各ペイロードの再生方法は、例えば、図３８にて説明される。２種類のメディアデータ(ビデオデータとオーディオデータ)がTCP-RTPにて擬似ストリーミング配信された場合では、RTPパケットヘッダ部のペイロードタイプは、ビデオデータあるいはオーディオデータを示している。システムデコーダ２０５１は受信した各RTPパケットのヘッダ部に記載されているペイロードタイプとシーケンス番号を調査し、ビデオデータとオーディオデータに分け、それぞれシーケンス番号順にペイロードデータ２０６１をメモリ２０７１に出力する。この際の各ペイロードの出力タイミングは、RTPパケットヘッダ部のタイムスタンプとアプリケーションデコーダにおけるメディアデータの処理状況を考慮して決められる。また、システムデコーダにおけるロスパケットの再送制御にもアプリケーションデコーダでの処理状況を反映する。システムデコーダにおけるロスパケットの再送制御は、TCPの場合と同じく図４０ならびに図４１にて説明できる。図４０に示したデータ２１０ならびに２１１が処理状況関連情報にあたる。データ２１１としては、メモリ内の各ペイロードタイプにおける未処理データの残量、データ２１０としては、再生遅延の発生状況、フレームレートならびにビットレートなどが含まれる。これらのデータは、図４１の再送判定部３０４に送られる。再送判定部３０４では、データ２１１により得られるデータ残量と、データ２１０から得られるデータの消費速度に関する情報、さらに再送パケットが到達するにかかる時間の推定値(それまでのデータ到達状況から推測する)、ペイロードタイプの重要性(基本的にオーディオ再生が途切れることは許されない)、ロスパケットのペイロードタイプ割合、各ペイロードタイプのタイムスタンプ等から、パケット再送待ちがアプリケーションデコーダに与える影響を推定する。そして、メモリ２０７に蓄積された各メディアデータ２０８は、「擬似ストリーミングにおけるTCP通信の伝送速度を考慮した受信から再生開始までの待ち時間」を考慮して規定されたデータ量に達した時点で、順にアプリケーションデコーダ２０９内のビデオデコーダならびにオーディオデコーダに入力され、再生処理される。
【００１４】
ここで、パケット処理部３０１の動作について触れておく。図８は、ＩＳ−９５規格無線端末のパケット処理部の詳細を示したものである。まず、無線信号は無線インタフェース部２０２にてデータリンク層制御プロトコルであるRLP (Radio Ling Protocol) のフレームデータ９０２(フレームとパケットはともにデータ単位のこと)に変換され、RLP解析部に入力される。図１１にRLPフレームのデータフォーマットを示す。RLPはCDMAデータに対応した通信プロトコルであり、データリンク層のプロトコルとのインタフェースを保つ役割を果たす。RLP解析部９０３では、RLPヘッダ情報に基づいて、複数のRLPペイロードデータ９０４を組み合わせることで、PPP (Point to Point Protocol) に対応したフレームデータ９０４１を構成し、PPP解析部９０５に出力する。図１０にPPPフレームのデータフォーマットを示す。PPPは、データリンク層のプロトコルの一種でありシリアル回線にて使用される。データリンク層は、主に「物理的な通信を確立する」役割と「データが通信路を通過している間に発生したエラーの検出を行う」役割を果たす。PPP解析部９０５では、使用されているネットワーク層プロトコルの判別 (上位プロトコルデータを解析)、データが通信路を通過している間に発生したエラーの検出 (誤り検査データを解析)、ならびに複数ペイロードデータ９０６を組み合わせたIPパケットデータ９０６１の構成の処理を行う。なお、ここでは、上位プロトコルであるネットワーク層のプロトコルとしてIPv4が採用されているものとして記載する (一般的に知られているIPとしては、他に、IPv6、AppleTalk等があり、勿論本発明に適用可能である)。図９にIPv4パケットのデータフォーマットを示す。IPv4パケットデータ９０６は、IP解析部９０７に入力される。IP解析部では、使用されているトランスポート層プロトコルの判別 (上位プロトコルデータを解析)やヘッダ部のエラーの検出 (チェックサムデータを解析)を行うと共に、複数のIPペイロードデータ９０８を組み合わせることで、上位プロトコルのパケットを構成する。そして、上位パケットがTCPであった場合には、TCP解析部９１０にTCPパケット９０８０を出力し、UDPであった場合には、UDP解析部９１１にUDPパケット９０８１を出力する。図１２にTCPパケットのデータフォーマット、図１３にUDPパケットのデータフォーマットを示す。TCPとUDPの使い分けは、伝送データの性質により行われ、一般的には、伝送速度よりも信頼性が重要なデータではTCP、リアルタイム性が重要な場合にはUDPが用いられる。TCP解析部９１０では、TCPパケットのヘッダ部に含まれるチェックサムを解析することでエラー検出処理が行われ、エラー検出結果３０２が再送判定部３０４に渡される(図６に示したエラー検出結果３０２ならびに再送判定部３０４と同じ)。エラー検出結果がエラーなしを示している場合には、ペイロードデータ３０７がメディアデータ再構成部３０８に、送信元シーケンス番号８０１がパケット検出部８０２とメディアデータ再構成部３０８に渡される。一方、UDP解析部では、UDPペイロードデータを、RTPパケット９１２１としてRTP解析部９１３に出力する。UDPパケットのチェックサムはオプション機能であり、エラー検出も必須の作業ではないが、安定した通信を提供するため、使用することが推奨されている。RTP解析部９１３では、ペイロード３０７をメディアデータ再構成部３０８に、タイムスタンプ・シーケンス番号・ペイロードタイプ８０１をパケット検出部８０２とメディアデータ再構成部３０８に振り分ける。
【００１５】
図４２は、図８のTCP部の処理をTCP-RTPに置き換えた図である。図８との相違点は、TCP-RTPの部分である。TCP解析部では、TCPパケットのヘッダ部に含まれるチェックサムを解析することでエラー検出処理が行われ、エラー検出結果３０２が再送判定部３０４に渡される(図６に示したエラー検出結果３０２ならびに再送判定部３０４と同じ)。エラー検出結果がエラーなしを示している場合には、TCPペイロードデータを、RTPペイロードデータ９１２０としてRTP解析部に渡すとともに、TCPヘッダ部のTCPシーケンス番号９１２２をパケットロス部とメディアデータ再構成部に渡す。RTP解析部９１３では、RTPペイロード３０７をメディアデータ再構成部３０８に、RTPヘッダのタイムスタンプ、シーケンス番号・ペイロードタイプをTCPシーケンス番号と共にパケット検出部８０２とメディアデータ再構成部３０８に振り分ける。
【００１６】
次に図６のパケットロス検出部８０２にて取得したパケットロス情報を用いて、パケットロス位置をアプリケーションデコーダに明示的に通知する方法を考える。図５に示されるように、パケットロスが発生した場合には、失ったパケット部分のデータが省略されてアプリケーションデコーダに渡されることになるが、パケットロスの情報はアプリケーションデコーダには通知されない。そのため、アプリケーションデコーダがパケットロスの発生ならびにその発生位置を加味して再生処理を行えるか否かは、アプリケーションデコーダの誤り検出能力に委ねられることになる。例えば、ロスしたパケットの前後をつなげた時のデータ列が、偶然、アプリケーションデコーダの仕様に含まれていた場合には、パケットロスの検出が遅れる原因となることも考えられる。本発明では、アプリケーションデコーダがパケットロスの発生位置を正確に判定できるようにするために、パケットロス部分にアプリケーションデコーダが理解できない符号化列を埋め込む仕組みを考える。具体的には、アプリケーションデコーダにおけるエラー検出を容易にするために、デコーダが理解できないデータ列(エラー検出用埋め込みデータ)をパケットロス部分に埋め込む。アプリケーションデコーダは理解できないデータ列をエラーと判断するため、パケットロスの発生位置をほぼ正確に検出可能となる。これにより、デコーダがエラーデータを正常データとして扱ってしまうようなエラー検出の遅延が回避され、再生画像・音声の乱れが抑制できる。なお、ここで言うアプリケーションデコーダには、ファイルフォーマットのファイルデコーダや、ビデオデコーダ、オーディオデコーダ、シーン記述デコーダ (複数のオブジェクトの表示位置再生処理)等のメディアデコーダが含まれる。従って、アプリケーションデコーダが理解できないデータ列(エラー検出用埋め込みデータ)は、アプリケーションデコーダに含まれるデコーダの種類によって異なる。例えば、図３９のようにアプリケーションデコーダがMP4ファイルのファイルデコーダとビデオ・オーディオのメディアデコーダで構成されている場合には、ファイルデコーダ、ビデオデコーダ、オーディオデコーダの全てが理解できないデータ列を「アプリケーションデコーダが理解できない符号化列(エラー検出用埋め込みデータ)」としてもよいし、ロスパケットがMP4ファイルのヘッダ部にあたる場合にはファイルデコーダのみが理解できない符号列、ビデオデータ部にあたる場合にはビデオデコーダのみが理解できない符号列、オーディオデータ部にあたる場合にはオーディオデコーダのみが理解できない符号列を埋め込むことで、アプリケーションデコーダ全体として理解できない符号列(エラー検出用埋め込みデータ)を定義してもよい。また、図３８のようにアプリケーションデコーダがオーディオデコーダとビデオデコーダで構成される場合には、システムデコーダにて、受信パケットが、ビデオデータとオーディオデータに分けて処理されるため、ペイロードタイプ別に異なるエラー検出用埋め込みデータを用意し、アプリケーションデコーダ全体として理解できない符号列(エラー検出用埋め込みデータ)を定義すればよい。
【００１７】
エラー検出用データ列を埋め込む手順は次に述べるとおりである。前に述べたように、メディアデータ再構成部３０８まで到達していないパケットのシーケンス番号(ならびにペイロードタイプ)と再送処理状況(再送処理中/パケットロス)は、パケットロス検出部８０２にて認識されている。そこで、図６と図４１に示すように、エラー検出用埋め込みデータ８０５をパケットロス検出部８０２にて作成し、パケットロスが発生したシーケンス番号(ならびにペイロードタイプ)８０６と共にメディアデコーダ再構成部３０８に通知する仕組みをシステムデコーダ内に設ける。そして、メディアデコーダ再構成部３０８は、ロスしたパケットのシーケンス番号(ならびにペイロードタイプ)８０６に対応する順番で、エラー検出用埋め込みデータ８０５を出力する。これにより、エラー検出用データの埋め込みが可能となる。ここでは、簡素化のため、パケットロスが発生した部分のメディアデータを復号するアプリケーションデコーダが、MPEG-4ビデオ規格であった場合、つまり図３９で、RTPパケットのペイロードタイプがビデオであった場合を例として、埋め込みデータのタイプを考える。
図１５は、図５のように第２番目のパケットをロスした場合のエラー検出用埋め込みデータの例である。MPEG-4ビデオ規格では２進数表示で２４個以上の０を続けることは禁止されている。従って、埋め込みデータ８０５２は、MPEG-4ビデオ規格には含まれないデータ列であり、ビデオデコーダには理解できず、エラーが発生したと認識できる。しかしながら、この例のように、アプリケーションデコーダ(ここでは、ビデオデコーダ)との間で特に取り決めのないユニークワードをエラー検出用埋め込みデータとして使用した場合では、パケットロス位置の周辺で誤りを検出することは可能であるが、エラーデータと正常データの切れ目を正確に検出することは難しい。従って、既存の市販ビデオデコーダをそのまま利用し、システムデコーダを新規開発する場合のパケットロス位置検出方法としては有効であるが、十分な検出性能は得られない。
そこで図１に、アプリケーションデコーダとの間で予め決めておいたユニークワード８０５１を埋め込んでおく場合のMPEG-4ビデオ規格の例を示す。MPEG-4ビデオでは、２３個の０と１個の１の組み合わせをデータの切れ目を示すための識別コードとしており、その２４ビットに続く２バイトのデータがその切れ目の種類を示すように設計されている。図１で使用している、１６進数のＡ１ならびにＡ５は、リザーブ用の識別コードとされており、現在の規格では使用されていない。従って、このようなユニークワードはMPEG-4ビデオの標準デコーダでは理解できず、エラーと見なされることになる。そこで、このようなデータ列が予めエラー検出用埋め込みデータであることを、MPEG-4ビデオデコーダとパケットロス検出部８０２が理解しておくことにより、ビデオデコーダにて正確なパケットロスの位置検出が実現でき、正常データとエラー検出用埋め込みデータの切れ目も明確となる。また、２個のユニークワードを設定し、これらをエラー検出用埋め込みデータの最初と最後につけておく方法も有効である。この方法では、第１のユニークワードの数ビットを誤ってデコードしてしまったとしても、埋め込みデータ区間の途中でエラーが検出されるように細工しておけば(２４個以上の０を挟む)、第２のユニークワードを検索することにより正常データが始まる位置を正確に検出することが可能となる。また、一度処理したデータを再度検索し直すことが可能な場合には、少し前に戻ってから、第１のユニークワードを改めて検索することにより、パケットロスが始まる位置も正確に検出することが可能となる。
【００１８】
図１６は、メディアデータのほかに、それと同サイズの誤り通知データを用意する方法である。誤り通知データにおける各バイナリーデータを、メディアデータにおける各バイナリーデータと１対１で対応させておき、例えば、メディアデータ内の埋め込みデータ８０５３の区間に１を割り当て、正常パケットの区間には０を割り当てておく。この誤り通知データにより、アプリケーションデコーダは正確にパケットロスの発生を認識できる。この際、埋め込みデータ８０５３は、必ずしもユニークワードである必要はない。但し、誤り通知データをアプリケーションデコーダに渡すための構成が必要となる。例えば、図６に示すように、パケットロス検出部８０２にて生成した誤り通知データパケット７０６を、誤り通知出力部８０４からメモリ２０７に出力する仕組みとする。この場合、携帯電話端末の全体構成は図１７のようになる。図２と図１７の相違点は、誤り通知データパケット７０６がシステムデコーダ２０５からメモリ２０７に渡される点と、メモリ２０７に蓄積後、メディアデータと同期して、誤り通知データ７０３がアプリケーションデコーダ２０９に出力されている点である。図４３ならびに図４４は、それぞれ図３８ならびに図３９の携帯電話端末構成に誤り通知データの機能を加えたものを示す。RTPを使用する図４３では、ペイロードタイプ別に、誤り通知データパケット７０６１ならびに誤り通知データ７０３１が処理されている。これに対し、TCPを使用しており、TCPパケットがペイロードタイプを持っていない図４４では、アプリケーションデコーダ内のファイルデコーダにて誤り通知データが各メディアデコーダに分配される。なお、図４４にて、ファイルフォーマットデータのヘッダ部にてパケットロスが発生している場合には、ファイルデコーダにてヘッダ部の情報を修正する必要が生じる。但し、より確実に再生処理を行うためには、図６あるいは図４１の再送判定部３０４にて、ファイルヘッダ部でロスパケットが発生している場合にはデータが到達するまで再送要求をかけるか、ファイルの構成を送信側と端末側の間で決めておくとよい。
【００１９】
ここまでは、メディアデコーダにパケットロスを通知する方法について述べてきたが、この方法では、再生される画質ならびに音質は最終的にアプリケーションデコーダの性能に依存することになる。そのため、アプリケーションデコーダ自体が高度な誤り訂正手段を持っていない場合には、エラー検出用の埋め込みデータは逆にデコードの性能を落としてしまう可能性もある。また、アプリケーションデコーダが高度な誤り訂正手段を持つためには、誤り検出、誤り修復等の処理をアプリケーションデコーダに追加する必要があり、処理量も増える。そのため、メモリ要求、CPUパワーならびに消費電力等の要求が厳しい通信端末では、リアルタイム再生を実現する上で、簡易な誤り訂正手段しか採用できない場合も考えられる。そこで、本出願では、ファイル転送型のサービスに関して、エラー検出用埋め込みデータを利用してアプリケーションデコーダで処理される前に、パケットロスを伴うメディアデータをビデオ、オーディオ等の仕様や標準規格に対応したデータに修正する方法についても提案する。
【００２０】
図１８に示す携帯電話端末２００３は、図１７の携帯電話端末２００２に、メディアデータの修正処理構成を加えたものである。メモリ２０７へのメディアデータ入力以降の処理を以下に説明する。エラー・同期マーカ検出７０１では、メディア処理の標準規格にて定められている同期確保用の識別コード(同期マーカ)とシステムデコーダ２０５にて埋めこんだエラー検出用埋め込みデータ８０５を検索対象として、メモリ２０７内のメディアデータ２０８を順に検索する(図１６で説明した誤り通知データを利用している場合には、誤り通知データ７０３も並列に検索し、メディアデータ内のエラー検出用埋め込みデータの替わりに、誤り通知データ内に記載されているエラー発生位置を示すデータ列を検出する)。そして、その何れかが検出された時点で、検出結果が同期マーカとエラー検出用埋め込みデータ(誤り通知データを利用している場合には、誤り通知データ内に記載されているエラー発生位置を示すデータ列)のいずれであったかを示す識別情報７１３をデータ修正処理部７０７に通知する。この際、同時にスイッチ７０５に、制御情報７０４を渡す。制御情報７０４は、検索開始位置から検出位置までのデータを第２メモリ７１０とデータ修正処理部７０７のいずれに出力すべきかを示す情報で、検出結果が同期マーカの場合には第２メモリ７１０に、検出結果がエラー検出用埋め込みデータ(誤り通知データを利用している場合には、誤り通知データ内に記載されているエラー発生位置を示すデータ列)の場合にはデータ処理部７０７にデータを出力することを示す。スイッチ７０５は、制御情報７０４の値に従ってスイッチを制御し、検出開始位置から次の同期マーカまでのメディアデータを第２のメモリ７１０あるいはデータ修正処理部７０７に渡るようにする(誤り通知データを利用している場合であり、かつ検出結果が誤り通知データ内に記載されているエラー発生位置を示すデータ列であるときには、メディアデータに対応する誤り通知データ７０３も同時にデータ修正処理７０７に渡される)。その後、メモリ２０７ではエラー・同期マーカ検出７０１にて検出したデータ位置までの情報を削除する(あるいは、検出した位置までポインタを移動する。誤り通知データも同様に処理)。データ修正処理部７０７では、入力データを調査し、規格方式に対応したデータに修正して第２メモリ７１０に出力する。この際、データ処理修正部７０７からスイッチ７０５に対して、スイッチ制御情報７１２が通知される場合がある(詳細は後述)。また、データ修正処理部７０７が、修正のために既に第２メモリ７１０に渡っているデータを必要とする場合には、処理済みデータ７０９を第２メモリから検索して入手する。第２メモリ７１０は、ユーザからの要求に応じてアプリケーションデコーダ２０９にメディアデータ７１１を出力する。この場合、アプリケーションデコーダ２０９は高度な誤り修正処理を必要としない(誤り通知データを使用しており、アプリケーションデコーダが誤り通知データを受信する仕組みを持っている場合には、誤り通知データをアプリケーションデコーダまで渡すことも可能である)。
【００２１】
ここで説明したデータ修正処理は、システムデコーダにてメディアデータがすでにビデオデータとオーディオデータに分かれているような場合には、個々のメディアデータ毎に修正処理を行えばよいが、MP4ファイルのように複数のメディアデータが１個のファイルに統合されている場合には、ファイル内のデータ位置に応じて異なる修正処理を行う必要がある。具体的には、ファイル内の各メディアデータ部(ビデオデータ、オーディオデータ)ならびにファイルヘッダ部に、個々に修理処理を施す。そして、メディアデータ部の修正内容に従いファイルヘッダ部に記載されているデータ容量等を更に書き換える必要がある。このように、ファイルヘッダをファイルフォーマットの仕様に対応したデータに修正することにより、ファイルフォーマットデコーダが各メディアデータを対応するデコーダに割り当てることができるようになる。
【００２２】
次に、MPEG-4ビデオ規格を例にとって、データ修正処理部７０７での処理を詳細に説明する。説明に先立ち、まず、MPEG-4ビデオ規格の復号方式ならびにデータ構造について説明する。MPEG-4で扱う動画像の１フレームは、図２３に示すように、１個の輝度信号(Y信号：2001)と２個の色差信号(Cr信号：2002, Cb信号：2003)にて構成されており、色差信号の画像サイズは縦横とも輝度信号の1/2となる。MPEG-4ビデオ規格では、動画像の各フレームを図２３に示すような小ブロックに分割し、マクロブロックと呼ばれるブロック単位で再生処理を行う。図24にマクロブロックの構造を示す。マクロブロックは１６×１６画素の１個のY信号ブロック２１０１と、それと空間的に一致する８×８画素のCr信号ブロック２１０２ならびにCb信号ブロック２１０３にて構成されている。なお、Y信号ブロックは、マクロブロックの復元過程では更に４個の８×８画素ブロック（２１０１１，２１０１２，２１０１３，２１０１４）に分割して処理されることがある。MPEG-4ビデオの符号化アルゴリズムは、MC-DCT(動き補償-離散コサイン変換)と呼ばれており、上記に示したマクロブロック単位で再生処理がなされる。動き補償とは、前フレームから対象マクロブロックの内容と似通った部分を抜き出し、その動き量を符号化する方法のことであり、動き補償により抜き出された前フレームのブロック領域と原画像の符号化対象ブロック（２１０１１，２１０１２，２１０１３，２１０１４，２１０２，２１０３）との差分ブロック画像が、DCTにて周波数変換された後、各変換係数が量子化して符号化される。さらに細かく見るとMPEG-4ビデオ規格にはフレーム内符号化 (イントラ符号化)、フレーム間符号化 (予測符号化)、双方向符号化と呼ばれる符号化方法がある。イントラ符号化とは、動き補償後の差分ブロック画像ではなく、符号化対象の入力ブロック画像に対して直接ＤＣＴを施し、各変換係数を量子化・符号化するデータ圧縮方法であり、全てのマクロブロックに対してイントラ符号化を適用したフレームをI-VOP(Intra-coded Video Object Plane、矩形画像ではVOPはフレームと同義)と呼ぶ。I-VOPは、過去のフレームの復号情報を必要としないため、ランダムアクセス時の復号開始フレームとして使用される。予測符号化とは、MC-DCTを利用した圧縮方法で、特に時間的に過去フレームに対してMCを行う符号化方法のこと。そして、フレーム内のマクロブロックに対して、予測符号化あるいはイントラ符号化を施したフレームをP-VOP(Predictive-coded VOP)と呼ぶ。これ以外に、時間的に過去と未来のフレームの情報を用いてMCを行う方法(双方向符号化)もあり、この符号化方法を使用したフレームはB-VOP(Bidirectionally predicted-coded VOP)と呼ばれている。
【００２３】
図１９は一般的なMPEG-4ビデオ復号化のブロック図である。入力されたメディアデータは、まず、符号解読部５０１によって、バイナリーコードから意味のある復号情報に変換される。そして、DCT係数の量子化データに関連する情報は、逆量子化部５０２に送られ、DCT係数データに復号された後、逆DCT器５０３にて差分マクロブロック画像に復元される。一方、動き量に関する情報は動き補償部５０４に送られる。動き補償器５０４では、前フレームのデータが蓄積されているフレームメモリ５０７から、復号された動き量に従って予測マクロブロック画像が復元される。このようにして復元された差分マクロブロック画像と予測マクロブロック画像は、加算器５０５にて復元マクロブロック画像が生成され、合成部５０６にて復元フレーム画像に合成される。復元されたフレーム画像は、表示処理部に出力されると共に、次フレームの動き補償のために、フレームメモリ５０７に保存される。
図２０は、誤り検出ならびに誤り修正処理機能を持つMPEG-4ビデオ復号化のブロック図例である。符号解読部５０１２では、入力データの解析と共に誤り検出が行われる。誤り検出にはいろいろな方法があるが、一般的には、MPEG-4ビデオ符号化のコードブックに存在しない可変長コードの検出によって行われる。データ誤りが検出された場合には、符号解読部５０１２は対象データを修復処理部５０９に出力する。また、符号解読部５０１２は、データ誤りを検出した時点で予測マクロブロック画像の出力制御情報５１０をスイッチ５０８に通知し、予測マクロブロック画像が修復処理部５０９に渡るように制御する。符号解読部５０１２における誤り検出処理ならびに修復処理部５０９の処理内容は標準化されていないため、伝送エラーが含まれるデータの再生画質は、各製品の仕様に依存することになる。
【００２４】
図２１, 図２２ならびに図２５は、MPEG-4ビデオ符号化の基本的なデータ構造を示したものである。図２１が全体のデータ構造、図２２がフレームヘッダのデータ構造、図２５が各マクロブロックのデータ構造を示している。図２１において、VOSヘッダはMPEG-4ビデオ製品の適用範囲を決めるプロファイル・レベル情報、VOヘッダはMPEG-4ビデオ符号化のデータ構造を決めるバージョン情報、VOLヘッダは画像サイズ、符号化ビットレート、フレームメモリサイズ、適用ツール等の情報を含んでいる。いずれも受信した符号化データを復号する上で必須の情報である。GOVヘッダには時刻情報が含まれているが、これは必須の情報ではなく省略も可能である。VOSヘッダ、VOヘッダ、VOLヘッダ、GOVヘッダとも32ビットのユニークワードから始まるため、容易に検索できる。シーケンスの終了を示すEnd code of VOSも32ビットのユニークワードである。これらのユニークワードは、２３個の０と１個の１で始まり、その２４ビットに続く２バイトのデータがその区切れの種類を示すような構造となっている。VOPには、各フレーム(MPEG-4ビデオではVOPと呼ぶ)のデータが含まれている。VOPは、図２２に示したVOPヘッダから始まり、図２５に示される構造のマクロブロックデータが、フレームの上から下、左から右の順で続く構造となっている。図２２がVOPヘッダのデータ構造である。VOPスタートコードと呼ばれる32ビットのユニークワードから始まる。vop_coding_typeがVOPの符号化タイプ(I-VOP, P-VOP, B-VOP等)を表し、それに続くmodulo_time_baseならびにvop_time_incrementがそのVOPの出力時刻を示すタイムスタンプとなっている。modulo_time_baseは秒単位の情報、vop_time_incrementは秒以下の情報である。vop_time_incrementの精度に関する情報はVOLヘッダのvop_time_increment_resolutionに示されている。modulo_time_base情報は、前VOPの秒単位の値と現VOPの秒単位の値との変化分を示す値で、その変化分の数だけ１が符号化される。つまり、秒単位の時刻が前のVOPと同じ場合には０が、1秒分異なる場合には１０、２秒分異なる場合には１１０が符号化されている。vop_time_increment情報は、各VOPにおける秒以下の情報をvop_time_increment_resolutionが示す精度で示している。intra_dc_vlc_thrには、イントラ符号化マクロブロックにおけるDCT係数のDC成分が、AC成分とは異なる符号化デーブルで符号化されているか、同じ符号化テーブルで符号化されているかを識別するための情報が含まれている。このintra_dc_vlc_thrの値と各マクロブロックにおけるDCT係数の量子化精度から、いずれの符号化テーブルを用いるかがマクロブロック単位で選択される。vop_quantは、DCT係数を量子化する際の量子化精度を示す値であり、そのフレームの量子化精度初期値となる。vop_fcode_forwardとvop_fcode_backwardはMCにおける動き量の最大範囲を示している。図２５がマクロブロックの基本データ構造 (I-VOPとP-VOP)である。not_codedはP-VOPのみで使用される１ビットのフラグで、以降にそのマクロブロックに関するデータが続いているかどうかを示している、０の場合には、そのマクロブロックに関するデータが続くことを意味し、１の場合には、以降に続くデータが次のマクロブロックに関するデータであり、そのマクロブロックの復号信号は前フレームの同じ位置からコピーすることにより生成することを示している。mcbpcは1〜9ビットの可変長符号であり、そのマクロブロックの符号化タイプを示すmb_typeと、２個の各色差ブロック内に符号化すべき量子化DCT係数(０以外の値)があるか否かを示すcbpc (イントラ符号化ブロックの場合には、量子化DCT係数のAC成分があるか否かを示す)を１個の符号で表している。mb_typeが示す符号化タイプには、intra, intra+q, inter, inter+q, inter4v (inter4vは、輝度信号の動き補償を行う単位が図２４の２１０１ではなく、２１０１１から２１０１４の４個の小ブロック単位であることを示す), stuffingの５種類があり、intraとintra+qがイントラ符号化、inter、inter+qならびにinter4vが予測符号化、stuffingは符号化レートを調整するためのダミーデータであることを示している。＋ｑは、DCT係数の量子化精度が前ブロックの値(quant)あるいは初期値(vop_quant、フレームの最初の符号化マクロブロックに適用)から変更されることを示している。なお、stuffingの場合には、図２５内のac_pred_flag以降のデータは省略されており、復号されたmcbpcとnot_codedの値も再生画像の合成には反映されない。ac_pred_flagは、mb_typeがイントラ符号化であった場合のみ含まれる情報で、DCT係数のAC成分に対して、周囲のブロックからの予測を行うか否かを示す。この値が１の場合は、AC成分の量子化再生値の一部が周囲のブロックからの差分値となっている。cbpyは１〜６ビットの可変長符号で、４個の各輝度ブロック内に符号化された量子化DCT係数(０以外の値)があるか否かを示している (cbpcと同様に、イントラ符号化ブロックの場合には、量子化DCT係数のAC成分があるか否かを示す)。dquantは、mb_typeがintra+qあるいはinter+qであった場合にのみ存在し、前ブロックの量子化精度の値からの差分値を示しており、quant+dquantがそのマクロブロックのquantとなる。動きベクトルの符号化に関する情報は、mb_typeが予測符号化の場合のみ含まれる。Intra差分DC成分は、mb_typeがイントラ符号化であり、かつuse_intra_dc_vlcが１の場合にのみ含まれる情報である。MPEG-4ビデオでは、イントラ符号化ブロックにおけるDCT係数のDC成分は、周囲のマクロブロックにおけるDCT係数のDC成分との差分値が量子化されている。量子化の方法もAC成分とは異なり、符号化方法もAC成分とは別の方法が用意されている。但し、use_intra_dc_vlcを０とすることによりDC成分の量子化値もAC成分の量子化値と同様の符号化方法を適用することが可能となる。なお、use_intra_dc_vlcの値は、VOPヘッダにて定義されるintra_dc_vlc_thrと当該マクロブロックのquantにて決定される。Intra AC成分 or Inter DC&AC成分に関しては、「cbpy, cbpcにて、DCTの量子化係数に０以外の値が存在することが示されている」ブロックのみ情報を持つ。
【００２５】
上記で示した図２５のマクロブロックデータ構造では、伝送誤り等の影響で１度データの同期が失われると、次フレームのスタートコードまでデータ同期を回復することができない。そこで、MPEG-4ビデオ規格では、誤り耐性用のデータ構造を別途用意している。具体的には、ビデオパケットならびにデータ分割と呼ばれる処理が用意されており、VOLヘッダにてその適用が指定される。ビデオパケットとは、数個のマクロブロックを集めたデータ単位のことで、各ビデオパケットデータの先頭には同期マーカとフレーム内での位置情報を含むビデオパケットヘッダが配置されている。また、ブロック間でのデータの予測もパケット内で閉じている。そのため、データ同期が失われた場合でも、その影響を１個のパケット内にとどめることが可能で、次のビデオパケットの先頭で同期を回復することも可能である。図２６がビデオパケット分割の例である。図２６では、２３０１，２３０２，２３０３，２３０４，２３０５の５個のビデオパケットに分割されている。フレームの第１パケット２３０１を除く各パケットデータの先頭には、図２８に示されるビデオパケットヘッダが配置され、フレームの第１パケットについては、図２２のVOPヘッダが配置される。パケットヘッダのデータ構造は、resync_markerと呼ばれる同期マーカから始まる。この同期マーカは、１７〜２３ビットのユニークワードで、そのデータサイズはフレームの符号化タイプや動き補償時の動き量の範囲から一意に決まるものである。macroblock_numberはパケット内の先頭マクロブロックのフレーム内位置を示すものである。この最初の２個のデータにより、同期は完全に回復する。quant_scaleは、そのビデオパケットにおけるDCT係数の量子化精度の初期値である。この値が当該ビデオパケットの最初の符号化マクロブロックに対する前マクロブロックのquantとして適用される。header_extension_codeは、modulo_time_baseからvop_fcode_backwardまでのデータをビデオパケットヘッダに含めるか否かを示すための１ビットのフラグで、１の場合にはmodulo_time_base以降が含まれる。なお、modulo_time_base以降のデータについては、VOPヘッダと同じ値にすることが規定されており、VOPヘッダ内の情報が伝送エラーの影響を受けているかどうかを調査する等の役割を持つ。これに対してデータ分割とは、図２５にて説明したマクロブロックのデータ構造にて示される符号の位置をビデオパケット内で入れ替えることにより、各マクロブロックの重要データが伝送エラーにて解読不能になる確率を減らす機能のことである。
【００２６】
図２７は、フレームタイプがI-VOPの場合について、ビデオパケット内のデータ分割構造を示したものである。図２７におけるビデオパケットヘッダ２４０１のデータ構造は、図２８に示したとおりである。図２９は、図２７の優先データ部２４０２に配置されるデータについて、１マクロブロック分の優先データ部のデータ構造２４０２１を示したものである。この図２９のデータは、図２５に示したマクロブロックデータから再生ブロックを合成する上で重要なデータのみを抜き出したものと言える。図２７の優先データ部２４０２には、ビデオパケット内の各マクロブロックについて図２９に示したデータ)のみを抜き出し、順次配置される。但し、dquantとIntra差分DC成分については、図中に示した条件が成立しているマクロブロックのみに存在する。図２７のdc_marker２４０３は１９ビットのユニークワードである。図３０は、図２７のAC成分制御情報2404に配置されるデータについて、１マクロブロック分のAC成分制御情報部のデータ構造２４０４１を示したものである。図３１は、図２７のAC成分情報２４０５に配置されるデータについて、１マクロブロック分のAC成分情報部のデータ構造２４０５１を示したものである。いずれも、ビデオパケット内の各マクロブロックについて、図２５に示したマクロブロックデータから図２９または図３０に示したデータのみを抜き出し、順次配置される。但し、各マクロブロックにおけるAC成分情報の存在はcbpy, cbpcの値に依存して変化する。このような構造を持つことにより、２４０４あるいは２４０５にて伝送誤りが発生しても、dc_markerの復号にて、優先データ部２４０２が同期崩れなく復号されていることが判定できるようになる。これにより、優先データ部のデータのみを用いて、当該ビデオパケット内の全マクロブロックについて、大まかな特徴を持つブロック画像を合成することが可能となる。また、優先データ部２４０２にて伝送誤りが発生しても、dc_markerを検索することにより、ビデオパケット内で同期を回復させることも可能である。但し、優先データ部のデータが壊れているとAC成分制御情報部２４０４とAC成分情報部２４０５に伝送エラーが無い場合であっても、mb_type, cbpcならびにdquant等の情報が使えないため、必ずしも正確に復号できるとは限らない。
【００２７】
図３２は、フレームタイプがP-VOPの場合について、ビデオパケット内のデータ分割構造を示したものである。図３２におけるビデオパケットヘッダ２４０１のデータ構造は、図２８に示したとおりである。図３３は、図３２の優先データ部２９０２に配置されるデータについて、１マクロブロック分の優先データ部のデータ構造２９０２１を示したものである。この図３３のデータは、図２５に示したマクロブロックデータから再生ブロックを合成する上で重要なデータのみを抜き出したものと言える。図３２の優先データ部２９０２には、ビデオパケット内の各マクロブロックについて、図３３に示したデータのみを抜き出し、順次配置される。但し、not_codedの値が１のマクロブロックについては、mcbpcと動きベクトル情報は省略される。また、mb_typeがイントラ符号化あるいはstuffingのマクロブロックについては、動きベクトル情報は省略される。図３２のmotion_marker２９０３は１７ビットのユニークワードである。図３４は、図３２のIntra差分DC成分情報&AC成分制御情報２９０４に配置されるデータについて、１マクロブロック分のIntra差分DC成分情報&AC成分制御情報のデータ構造２９０４１を示したものである。図３５は、図３２のIntra AC成分 or Inter DC&AC成分情報２９０５に配置されるデータについて、１マクロブロック分のIntra AC成分 or Inter DC&AC成分情報のデータ構造２９０５１を示したものである。いずれも、ビデオパケット内の各マクロブロックについて、図２５に示したマクロブロックデータから図３４または図３５に示したデータのみを抜き出し、順次配置される。但し、not_codedが１のマクロブロックについては、マクロブロック内に図３４ならびに図３５に示すデータが存在しないため、省略される。また、各マクロブロックにおけるIntra差分DC成分情報&AC成分制御情報２９０４１内のac_pred_flag, dquantならびにIntra差分DC成分については、図中に示した条件が成立しているマクロブロックのみに存在する。さらに、各マクロブロックにおけるIntra AC成分(mb_typeがイントラ符号化の場合) or Inter DC&AC成分情報 (mb_typeが予測符号化の場合)の存在はcbpy, cbpcに依存して変化する。
【００２８】
図３６に、データ修正処理部７０７での処理をビデオパケットならびにデータ分割の機能を用いたデータを例として示す。最初に、図１８のエラー・同期マーカ検出部７０１から、データ検索の結果が同期マーカ(各種スタートコードあるいはresync_marker)あるいはエラー検出用埋め込みデータのいずれであったかを示す識別情報７１３を受け、検出結果が同期マーカであったか否かを判定する（ステップ３３０１）。検出結果が同期マーカであった場合には、検索開始位置から検出位置までのデータ、すなわち１ビデオパケット分のデータが、図１８のエラー・同期マーカ検出部７０１からスイッチ７０５に通知される制御情報７０４により第２メモリ７１０に出力される。データ処理部７０７では、第２メモリ７１０へ入力されたデータを保存することを示す情報を通知し、処理を終了する（ステップ３３１３）。一方、検出結果がエラー検出用埋め込みデータであった場合には、図１８のエラー・同期マーカ検出部７０１からスイッチ７０５に通知される制御情報７０４により、検索開始位置から次の同期マーカまでのメディアデータ２０８がメモリ２０７からデータ修正処理部７０７に得られる（ステップ３３０２）。次に、データ処理部７０７では、獲得したメディアデータ２０８を解析し、エラー区間をチェックする。チェックは、エラー区間がVOLヘッダを含むか？（ステップ３３０３）、ステップ３３０３でVOLヘッダを含んでいない場合、エラー区間がVOPヘッダを含むか？（ステップ３３０４）、ステップ３３０４でVOPヘッダを含んでいない場合、エラー区間がビデオパケットヘッダ内のマクロブロック位置データ(図２８のmacroblock_number)を含むか？（ステップ３３０５）、ステップ３３０３でVOLヘッダを含んでいた場合、そのVOLヘッダは再送ヘッダであるか？（ステップ３３０６）、ステップ３３０４でVOPヘッダを含んでいた場合、vop_coding_typeがB-VOPであるか？（ステップ３３０７）の５つで行う。ここでステップ３３０７については、VOPヘッダ内のvop_coding_type情報がエラー区間に含まれていた場合、当該フレーム内のパケットヘッダに含まれるvop_coding_type情報(図２８のvop_coding_type)をこの判定に利用してもよい。エラー区間チェックの結果、ステップ３３０６にて、エラー区間が再送VOLヘッダを含むと判定される場合には、VOSヘッダ、VOヘッダならびにVOLヘッダの組み合わせを捨てることを示すエラー修正情報７０８を図１８の第２のメモリ７１０に通知し、処理を終了する（ステップ３３１５）。この際、VOSヘッダ、VOヘッダが既に第２のメモリ７１０に移動している場合には、第２のメモリはエラー修正情報７０８に応じて、対応するヘッダ情報を削除する。エラー区間チェックの結果、4)にて、エラー区間がシーン先頭のVOLヘッダを含むと判定される場合には、エラーを含まない次のVOLヘッダまでのメディアデータがデータ修正処理部７０７に入力されるようにスイッチ制御情報７１２を制御し、図１８のスイッチ７０５に通知する（ステップ３３１４）。そして、次のVOLヘッダまでの情報を削除し、VOLヘッダ情報のみをエラー修正情報７０８として第２のメモリに渡す。また、VOLヘッダ後のVOPがI-VOPでない場合には、次のI-VOPまでのメディアデータがデータ修正処理部７０７に入力されるようにスイッチ制御情報７１２を制御し、スイッチ７０５に通知する。そして、シーン先頭のVOLヘッダに続くVOPの種類がI-VOPとなるようにデータの削除を行う。エラー区間チェックの結果、ステップ３３０７にて、vop_coding_typeがB-VOPであると判定できる場合には、次のVOPヘッダまでのメディアデータがデータ修正処理部７０７に入力されるように、スイッチ制御情報７１２を図１８のスイッチ７０５に通知し、次のスタートコードまでのデータを削除する（ステップ３３１５）。エラー区間チェックの結果、5)にて、vop_coding_typeがB-VOPでないと判断できる場合には、以下の（１）から（４）の処理をおこなう（ステップ３３１７）。
(1) 次のヘッダ情報付き同期マーカあるいはスタートコードまでのデータを捨てるようにスイッチ制御情報７１２を制御し、スイッチ７０５に通知する。
(2) 現マクロブロックの位置(macroblock_number)を０とする。
(3) ヘッダ情報付き同期マーカがフレーム内に含まれる場合、ヘッダ情報からVOPヘッダを生成する。
(4) ヘッダ情報付き同期マーカがフレーム内に含まれていない場合、vop_codedを０としてVOPヘッダを作成する。次フレームのvop_time_incrementの値が、前フレームよりも小さい場合には、modulo_time_baseを１０とし、vop_time_incrementを０とする。それ以外の場合には、modulo_time_baseを０とし、vop_time_incrementを前フレームの値に1を加えた値とする。
なお、処理(3)、(4)に示すヘッダ情報付き同期マーカの検索の際には、メモリ２０７内のメディアデータ２０８を利用する。処理(4)を実行した場合には、修正データの終端部にバイトアライン処理を施し（ステップ３３１１）、第２のメモリ７１０にバイトアライン化した修正データ７０８を出力して、処理を終了する（ステップ３３１２）。エラー区間チェックの結果、ステップ３３０５にて、エラー区間がビデオパケットヘッダ内のマクロブロック位置データを含んでいた場合、第２のメモリから前ビデオパケット(VP)の処理済みデータ７０９を読み込み、前VPヘッダ内のmacroblock_numberと前VPの符号化MB数を調査する（ステップ３３１６）。この処理により、当該VPヘッダのmacroblock_numberを再現することが可能となる。
【００２９】
エラー区間処理にて、ステップ３３０３とステップ３３０４の処理を満たさない場合と、ステップ３３０７にてVOP符号化タイプがB-VOPではないと判定でき、かつステップ３３１７の処理にて処理(3)を実行した場合については、マクロブロックデータの修正処理を行う。まず、ステップ３３０３とステップ３３０４の処理を満たさない場合については、当該ビデオパケットの第１MBの位置(macroblock_number)を検出する（ステップ３３０８）。ステップ３３０４を満たす場合に関しては、ステップ３３１７の処理(2)において、当該ビデオパケットの第１MBの位置を0と設定しているため、ステップ３３０８は省略できる。次に、メモリ２０７内のメディアデータ２０８を検索し、次VPの第１MBの位置、すなわち当該VP内における処理MB数を検出する（ステップ３３０９）。なお、検索の結果、次VPのresync_markerの前にスタートコードが検出された場合には、当該VPの最終MBが当該VOPの最終MBであると判定する。そして、ビデオパケット内の符号化マクロブロック数情報とビデオパケット内のメディアデータ２０８を用いて、図３７に示すマクロブロックデータ修正処理３３１０を実行する。最後に修正データの終端部にバイトアライン処理３３１１を施し、第２のメモリ７１０にバイトアライン化した修正データ７０８を出力して、処理を終了する（ステップ３３１２）。
【００３０】
次に、図３７のマクロブロックデータ修正処理３３１０について説明する。パケット内の各マクロブロックのデータ修正方法として、本明細書では以下の３つの方法を用いることにする。
処理Ｉ：not_codedフラグを１とする。MB内の元データは削除。
処理ＩＩ：MB内の差分DC成分を全て０とし、mb_typeを「intra」、cpby, cbpcを符号化ブロックなしに設定する。ＭＢ内の元データは削除。
処理ＩＩＩ：cpby, cbpcを符号化ブロックなしに設定する。さらに、I-VOPの場合には、ac_pred_flagを０とし、AC成分データは削除する。P-VOPの場合には、mb_typeがイントラ符号化(intra, intra+q)のときは処理I、mb_typeが予測符号化(inter, inter+q, inter4v)のときは、Inter DC&AC成分データを削除する。
処理方法の選択手順は、図２７あるいは図３２のどの部分でエラーが発生しているかによって決める。そこで、入力されたビデオパケット内のメディアデータ２０８をチェックし、エラー区間を、エラー区間がビデオパケットヘッダ(図２７の２４０１あるいは図３２の２４０１)を含むか？（ステップ３４０１）、ステップ３４０１でビデオパケットヘッダを含んでいない場合、エラー区間が優先データ部(図２７の２４０２あるいは図３２の２９０２)を含むか？（ステップ３４０３）、ステップ３４０３でビデオパケットヘッダを含んでいる場合、エラー区間が中間マーカ(図２７の２４０３あるいは図３２の２９０３)を含んでいるか？（ステップ３４０４）のように３つのステップでチェックする。
【００３１】
ステップ３４０１にて、エラー区間がビデオパケットヘッダを含むと判断される場合には、ステップ３４０２処理を実行し、処理を終了する。具体的には、まず、図３６のステップ３３０８の処理で検出した第１MBの位置に従って、ビデオパケットヘッダ部を修正する。その際、quant_scaleがエラー区間に含まれていた場合には、前VPパケットと同じ値に定める。次に、ビデオパケット内の各MBについてデータを生成する。生成方法としては、VOPの符号化タイプがI-VOPの場合には処理ＩＩ、P-VOPの場合には処理Ｉの方法を利用する。さらに、優先データ部の後に中間マーカ(I-VOPの場合にはdc_marker、P-VOPの場合にはmotion_marker)を追加する。なお、このケースでは、パケット内の元のデータは全て廃棄し、修正データのみ出力する。
【００３２】
ステップ３４０３にて、エラー区間が優先データを含まないと判断される場合には、ステップ３４０７の処理を実行し、処理を終了する。具体的には、DCTデータ部(図２７の２４０４と２４０５、あるいは図３２の２９０４と２９０５)が正常なMBについては、優先データ部ならびにDCTデータ部のデータをそのまま保存する。DCTデータ部がエラー区間に含まれているMBについては、処理ＩＩＩの方法でデータを修正する。なお、次のVPヘッダのresync_markerがエラー区間に含まれている場合には、図３６のステップ３３０９の処理にて検出したVPは、実際には２つ後のVPとなり、次VP内のMBも当該VP内のMBとして扱う必要が生じる。このように優先データ部の情報がないMBについては、VOPの符号化タイプがI-VOPなら処理ＩＩ、P-VOPなら処理Ｉを用いて優先データ部ならびにAC成分制御情報部(I-VOPの場合のみ)のMBデータを生成し、優先データ部の直後に中間マーカを挿入する。
【００３３】
ステップ３４０４にて、エラー区間が中間マーカを含んでいると判断される場合には、ステップ３４０５の処理を実行し、処理を終了する。具体的には、優先データ部が正常なMBについては
処理ＩＩＩ、優先データ部がエラー区間に含まれているI-VOP上のMBについては処理ＩＩ、優先データ部がエラー区間に含まれているP-VOP上のMBについては処理Ｉの方法でデータを修正する。さらに、優先データ部の直後に中間マーカ(I-VOPの場合にはdc_marker、P-VOPの場合にはmotion_marker)を挿入する。
【００３４】
ステップ３４０４にて、エラー区間が中間マーカを含まないと判断される場合には、ステップ３４０６の処理を実行し、処理を終了する。具体的には、優先データ部、DCTデータ部共に正常なMBについては、優先データ部ならびにDCTデータ部のデータをそのまま保存する。優先データ部のみエラー区間に含まれているMBについては、VOPの符号化タイプがI-VOPなら処理ＩＩ、P-VOPなら処理Ｉを用いて優先データ部ならびにAC成分制御情報部(I-VOPの場合のみ)のMBデータを修正する。DCTデータ部のみがエラー区間に含まれているMBについては、処理ＩＩＩの方法でデータを修正する。なお、次のVPヘッダのresync_markerまでがエラー区間に含まれている場合には、図３６のステップ３３０９の処理にて検出したVPは、実際には２つ後のVPとなり、次VP内のMBも当該VP内のMBとして扱う必要が生じる。このような優先データ部情報がないMBについては、VOPの符号化タイプがI-VOPなら処理ＩＩ、P-VOPなら処理Ｉを用いて優先データ部ならびにAC成分制御情報部(I-VOPの場合のみ)のMBデータを生成する。
【００３５】
ここまで述べてきたように、データのエラー修正機能はスタートコード、同期マーカならびに中間マーカを起点として行われる。従って、これらのユニークワードを区切りとし、例えば、中間マーカとDCTデータ部が１個のパケットに含まれないように、送信側で伝送パケットを構成しておくことで、本発明にて述べている方法はより有効に機能する。
本発明には次のような場合も含まれる。
１つめは、本発明のエラー検出用埋め込みデータの埋め込み方法は、パケットロスを伴う通信手段で利用でき、かつ各パケット内のヘッダ部にそのパケットのシーケンス番号(パケットを合成する順番)が含まれているプロトコルであれば、送信端末とのコネクションレス型、コネクション型に関わらず適用可能である。よって、本発明のエラー検出用埋め込みデータの埋め込み方法は、本明細書で示したTCPとUDP/RTPに特化するものではない。また、回線交換方式であっても、決まった区切りで伝送エラーを修正するため、アプリケーションデコーダへの出力にエラー修正結果を反映させることが可能である。このように、受信データの特定部分に通信エラーが発生していると判定できる場合には本発明のエラー検出用データ埋め込み方法は適用できる。
２つめは、本発明のエラー検出用埋め込みデータの埋め込み方法は、パケットロス部等の影響で発生するデータ誤りの位置を、明示的にアプリケーションデコーダに伝えるための識別コードをメディアデータ内に埋め込むことに特徴があり、その具体的な数値は図１、図１５ならびに図１６に示した数値には依存しない。パケットロス部分のデータを再生するアプリケーションデコーダがエラーと判定できる埋め込みデータの発生手段ならびに埋め込み構成は本発明に含まれる。また、埋め込み位置の検出方法ならびに構成も図２と図６に限定されるものではない。
３つめは、本発明のメディアデータ修正方法は、パケットロス等の伝送誤りの影響を受けた画像、音声等のメディアデータを、アプリケーションデコーダに入力する前に、そのメディアデータを解読し、再現するための仕様・規格に従ったデータに修正することに特徴がある。従って、本明細書では、MPEG-4ビデオ規格を例にとって説明したが、このようなデータ修正は、他の動画像符号化方式でも同様のことは実現可能であり、様々な静止画符号化方式、音声符号化方式ならびにデータ符号化方式、さらにMP4のようなメディア統合ファイルフォーマットに対しても実現可能である。よって、アプリケーションデコーダ(ビデオデコーダ、オーディオデコーダ、シーン記述デコーダ、ファイルフォーマットデコーダならびにこれらの組み合わせ等)に入力する前に、データを仕様準拠・規格準拠に変換する方法は全て本発明に含まれる。また、本発明を実現するための構成は図１８に限定されるものではない。例えば、メモリを１個とし、随時データを修正して入れ替える方法やエラー検出機能をデータ修正処理部に含めるような場合も本発明に含まれる。
４つめは、本明細書では、携帯電話端末を例にとって説明したが、本発明はその他の無線端末や配信サーバ等でも実現できる。例えば、無線通信から有線通信へデータ変換部・変換機に本発明のデータ修正方法を適用することは有効である。
【００３６】
【発明の効果】
本発明により、アプリケーションデコーダにてパケットロスの影響を受けているデータ位置を正確に検出することが可能となる。また、アプリケーションデコーダに入力する前にメディアデータをデコーダの仕様・規格に修正することで、アプリケーションデコーダにおける誤り修正処理の負担を減らし、データの再生速度を高速化することが可能となる。
【図面の簡単な説明】
【図１】本発明のユニークワードを埋め込んだシステムデコーダの出力データ。
【図２】携帯電話端末の内部構成を示す図。
【図３】送信パケットの一例図。
【図４】パケットロスが発生していない場合のシステムデコーダからの出力メディアデータの一例図。
【図５】パケットロスが発生した場合の、システムデコーダからの出力メディアデータの一例図。
【図６】エラー検出用埋め込みデータの埋め込み処理を実現するためのシステムデコーダ。
【図７】本発明のシステムデコーダにおける、パケット処理部からメディアデータ再構成部への出力データ。
【図８】本発明のシステムデコーダにおいて、パケット処理部の処理手順の一例。
【図９】  IPv4パケットのデータ構成。
【図１０】  PPPフレームのデータ構成。
【図１１】  RLPフレームのデータ構成。
【図１２】  TCPパケットのデータ構成。
【図１３】  UDPパケットのデータ構成。
【図１４】  RTPパケットのデータ構成。
【図１５】本発明のエラー検出用埋め込みデータの一例。
【図１６】本発明の誤り通知データを付加するエラー検出用埋め込みデータの一例。
【図１７】誤り通知データの出力機能を持つ携帯電話端末の内部構成図。
【図１８】本発明のデータ修正処理を実現する携帯電話端末の内部構成図。
【図１９】  MPEG-4デコーダのブロック図の一例。
【図２０】誤り訂正機能を持つMPEG-4デコーダのブロック図の一例。
【図２１】  MPEG-4ビデオ符号化ビットストリームの一例。
【図２２】  MPEG-4ビデオ符号化ビットストリームにおけるVOPヘッダのデータ構成。
【図２３】  MPEG-4ビデオ符号化におけるマクロブロック分割を示す図。
【図２４】  MPEG-4ビデオ符号化におけるマクロブロックの構成。
【図２５】  MPEG-4ビデオ符号化ビットストリームにおけるMBデータのデータ構成。
【図２６】  MPEG-4ビデオ符号化におけるビデオパケット分割例。
【図２７】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケットデータ(I-VOP)のデータ構造。
【図２８】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケットヘッダのデータ構造。
【図２９】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケット優先データ部(I-VOP)のデータ構造。
【図３０】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケットAC成分制御情報部のデータ構造。
【図３１】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケットAC成分情報部のデータ構造。
【図３２】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケットデータ(P-VOP)のデータ構造。
【図３３】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケット優先データ部(P-VOP)のデータ構造。
【図３４】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケットIntra差分DC成分情報&AC成分制御情報部のデータ構造。
【図３５】  MPEG-4ビデオ符号化ビットストリームにおけるビデオパケットIntra AC成分 or Inter DC&AC制御情報部のデータ構造。
【図３６】本発明のメディアデータ修正アルゴリズムを示すフローチャート。
【図３７】本発明のマクロブロックデータ修正アルゴリズム示すフローチャート。
【図３８】  RTP使用時における携帯電話端末の内部構成を示す図。
【図３９】  TCP使用時における携帯電話端末の内部構成を示す図。
【図４０】アプリケーションデコーダでの処理状況を考慮して、不正パケットの再送判定を行うことが可能な携帯電話端末の内部構成を示す図。
【図４１】エラー検出用埋め込みデータの埋め込み処理を行うシステムデコーダ。
【図４２】本発明のシステムデコーダにおいて、擬似ストリーミングにおけるパケット処理部の処理手順の一例。
【図４３】  RTP使用時における誤り通知データの出力機能を持つ携帯電話端末の内部構成図。
【図４４】  TCP使用時における誤り通知データの出力機能を持つ携帯電話端末の内部構成図。
【符号の説明】
２０５…システムデコーダ、２０７、７１０…メモリ、２０９…アプリケーションデコーダ、３０１…パケット処理部、３０３…再送判定結果・シーケンス番号、３０４…再送判定部、３０５…応答確認部、３０７…ペイロードデータ、３０８…メディアデータ再構成部、８０１…タイムスタンプ・シーケンス番号・ペイロードタイプ、８０２…パケットロス検出部、７０１…エラー・同期マーカ検出部、８０５、８０５１、８０５２、８０５３…エラー検出用埋め込みデータ、８０６、８０７…パケットロスが発生したシーケンス番号ならびにペイロードタイプ、８０７…パケットロスが発生したシーケンス番号、７０６…誤り通知データ、７０５…スイッチ、７０７…データ修正処理部、３３１０…マクロブロックデータ修正部、３３１１…バイトアライン処理部
【図１】
0003931595.tif 000002
【図２】
0003931595.tif 000003
【図３】
0003931595.tif 000004
【図４】
0003931595.tif 000005
【図５】
0003931595.tif 000006
【図６】
0003931595.tif 000007
【図７】
0003931595.tif 000008
【図８】
0003931595.tif 000009
【図９】
0003931595.tif 000010
【図１０】
0003931595.tif 000011
【図１１】
0003931595.tif 000012
【図１２】
0003931595.tif 000013
【図１３】
0003931595.tif 000014
【図１４】
0003931595.tif 000015
【図１５】
0003931595.tif 000016
【図１６】
0003931595.tif 000017
【図１７】
0003931595.tif 000018
【図１８】
0003931595.tif 000019
【図１９】
0003931595.tif 000020
【図２０】
0003931595.tif 000021
【図２１】
0003931595.tif 000022
【図２２】
0003931595.tif 000023
【図２３】
0003931595.tif 000024
【図２４】
0003931595.tif 000025
【図２５】
0003931595.tif 000026
【図２６】
0003931595.tif 000027
【図２７】
0003931595.tif 000028
【図２８】
0003931595.tif 000029
【図２９】
0003931595.tif 000030
【図３０】
0003931595.tif 000031
【図３１】
0003931595.tif 000032
【図３２】
0003931595.tif 000033
【図３３】
0003931595.tif 000034
【図３４】
0003931595.tif 000035
【図３５】
0003931595.tif 000036
【図３６】
0003931595.tif 000037
【図３７】
0003931595.tif 000038
【図３８】
0003931595.tif 000039
【図３９】
0003931595.tif 000040
【図４０】
0003931595.tif 000041
【図４１】
0003931595.tif 000042
【図４２】
0003931595.tif 000043
【図４３】
0003931595.tif 000044
【図４４】
0003931595.tif 000045