(57)【特許請求の範囲】
【請求項１】
ビデオ・フレームのシーケンスを表すソース符号化ビット・ストリームを形成するためのビデオ・ソース符号化方法であって、前記ソース符号化ビット・ストリームは、符号化されるビデオ・フレームの各々について、それぞれ画定された符号化フレームを有する符号化フレーム構造を有し、前記方法は、
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第１のものによって、第１のソース符号化データを提供すること、ただし前記第１のソース符号化データは、前記ビデオ・フレームのうち第１のものを表すと共に、該第１のビデオ・フレームのための画像ヘッダ・データと、該画像ヘッダ・データに対応する前記第１のビデオ・フレーム全体のソース符号化画像データとを含むことと；
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記第１の符号化フレームの後に、第２のソース符号化データを供給することと；
を含み、ただし前記第２のソース符号化データは、前記第１のビデオ・フレームのための前記画像ヘッダ・データの少なくとも一部の複製を含むが、前記対応する前記第１のビデオ・フレーム全体のソース符号化画像データの複製は含まない、方法。
【請求項２】
請求項１に記載の方法において、
前記第１のビデオ・フレームがＩＮＴＲＡフレーム・フォーマットで符号化される場合だけ、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含む前記第２のソース符号化データを提供することを含む、方法。
【請求項３】
請求項１に記載の方法において、
前記第２のソース符号化データを、ビデオ・フレームの不完全な一部を表し、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復および前記第１のビデオ・フレームのソース符号化画像データの第１のセグメントのみを含むソース符号化データとして提供することを含む、
方法。
【請求項４】
請求項１に記載の方法において、
前記第１のビデオ・フレームの画像ヘッダおよび前記第１のビデオ・フレームのソース符号化画像の第１のセグメントのみを有する、ビデオ・フレームの不完全な部分を表すソース不符号化データとして、前記第２のソース符号化データを提供することと；
前記複製された画像ヘッダに、前記第１のビデオ・フレームの前記画像ヘッダと同じ参照情報を与えることにより、前記第１のビデオ・フレームの前記画像ヘッダ・データの複製を含むものとして、前記第２のソース符号化データを識別することと；
を含む、方法。
【請求項５】
請求項１に記載の方法において、
前記第２のソース符号化データを、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復および他のデータを含むソース符号化データとして提供することであって、前記他のデータが、前記第２のソース符号化データが基準ビデオ・フレームに対して変化していないビデオ・フレームを表していることを示すことを含む、
方法。
【請求項６】
請求項５に記載の方法において、
前記他のデータが、ソース符号化画像データが前のビデオ・フレームに対して変化していないことを示す１つまたは複数の表示を含む、
方法。
【請求項７】
請求項１に記載の方法において、
前記第２のソース符号化データを、前記符号化フレーム構造の第２の画定された符号化フレームの中のソース符号化ビット・ストリーム中のデータの中で提供することを含み、
ここで前記第２のソース符号化データは、ビデオ・フレームのシーケンス内の前記第１のビデオ・フレームの後のビデオ・フレームを表し、
前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データおよび前記後のビデオ・フレームのソース符号化画像データを含み、
前記方法は、前記後のビデオ・フレームの画像ヘッダ・データ内に前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を提供することを含む、
方法。
【請求項８】
請求項１に記載の方法において、
前記第２のソース符号化データを、前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第２のものの中のデータの中で提供することを含み、
ここで前記第２のソース符号化データは、ビデオ・フレームのシーケンス内の前記第１のビデオ・フレームの後のビデオ・フレームを表し、
前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データと、補足エンハンスメント情報（ＳＥＩ）と、前記後のビデオ・フレームのソース符号化画像データとを有し、ただし前記補足エンハンスメント情報（ＳＥＩ）は、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含む、
方法。
【請求項９】
請求項８に記載の方法において、
前記第１のビデオ・フレームの画像開始コードを除く、前記後のビデオ・フレームの補足エンハンスメント情報（ＳＥＩ）フィールド内に前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を提供することを含む、
方法。
【請求項１０】
請求項７に記載の方法において、
前記後のビデオ・フレームのために、画像ヘッダ・データ内に前記第１のビデオ・フレームの画像ヘッダ・データのいくつかのフィールドだけを反復することを含む、
方法。
【請求項１１】
ビデオ・フレームのシーケンスを表すソース符号化ビット・ストリームを提供するためのビデオ・ソース符号化装置であって、前記ソース符号化ビット・ストリームは、符号化されるビデオ・フレームの各々について、それぞれ画定された符号化フレームを有する符号化フレーム構造を有し、前記ビデオ・ソース符号化装置が、
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第１のものによって、第１のソース符号化データを提供し、ただし前記第１のソース符号化データは、前記ビデオ・フレームのうち第１のものを表すと共に、該第１のビデオ・フレームのための画像ヘッダ・データと、該画像ヘッダ・データに対応する前記第１のビデオ・フレーム全体のソース符号化画像データとを含み、
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記第１の符号化フレームの後に第２のソース符号化データを供給する、
ように構成され、ただし前記第２のソース符号化データは、前記第１のビデオ・フレームのための前記画像ヘッダ・データの少なくとも一部の複製を含むが、前記対応する前記第１のビデオ・フレーム全体のソース符号化画像データの複製は含まない、ビデオ・ソース符号化装置。
【請求項１２】
請求項１１に記載のビデオ・ソース符号化装置において、
前記第１のビデオ・フレームがＩＮＴＲＡフレーム・フォーマットで符号化される場合だけ、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含む第２のソース符号化データを提供するように構成される、
ビデオ・ソース符号化装置。
【請求項１３】
請求項１１に記載のビデオ・ソース符号化装置において、
前記第２のソース符号化データを、ビデオ・フレームの不完全な一部を表すソース符号化データとして提供し、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復および前記第１のビデオ・フレームのソース符号化画像データの第１のセグメントのみを含むように構成される、
ビデオ・ソース符号化装置。
【請求項１４】
請求項１１に記載のビデオ・ソース符号化装置において、
前記第１のビデオ・フレームの画像ヘッダおよび前記第１のビデオ・フレームのソース符号化画像の第１のセグメントのみを有する、ビデオ・フレームの不完全な部分を表すソース不符号化データとして、前記第２のソース符号化データを提供することと；
前記複製された画像ヘッダに、前記第１のビデオ・フレームの前記画像ヘッダと同じ参照情報を与えることにより、前記第１のビデオ・フレームの前記画像ヘッダ・データの複製を含むものとして、前記第２のソース符号化データを識別することと；
を実行しうるように構成される、ビデオ・ソース符号化装置。
【請求項１５】
請求項１１に記載のビデオ・ソース符号化装置において、
前記第２のソース符号化データを、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復および他のデータを含むソース符号化データとして提供するように構成され、前記他のデータが、前記第２のソース符号化データが前記ビデオ信号の基準ビデオ・フレームに対して変化していないビデオ・フレームを表していることを意味する、
ビデオ・ソース符号化装置。
【請求項１６】
請求項１５に記載のビデオ・ソース符号化装置において、
前記他のデータが、ソース符号化画像データが前のビデオ・フレームに対して変化していないことを示す１つまたは複数の表示を含む、
ビデオ・ソース符号化装置。
【請求項１７】
請求項１１に記載のビデオ・ソース符号化装置において、
前記第２のソース符号化データを、前記符号化フレーム構造の第２の画定された符号化フレームの中のソース符号化ビット・ストリーム中のデータの中で提供するように構成され、
ここで前記第２のソース符号化データは、ビデオ・フレームのシーケンス内の前記第１のビデオ・フレームの後のビデオ・フレームを表し、
前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データおよび前記後のビデオ・フレームのソース符号化画像データを含み、
前記ビデオ・ソース符号化装置は、前記後のビデオ・フレームの画像ヘッダ・データ内の前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を提供するように構成される、
ビデオ・ソース符号化装置。
【請求項１８】
請求項１１に記載のビデオ・ソース符号化装置において、
前記第２のソース符号化データを、前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第２のものの中のデータの中で提供するように構成され、
ここで前記第２のソース符号化データは、ビデオ・フレームのシーケンス内の前記第１のビデオ・フレームの後のビデオ・フレームを表し、
前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データと、補足エンハンスメント情報（ＳＥＩ）と、前記後のビデオ・フレームのソース符号化画像データとを有し、ただし前記補足エンハンスメント情報（ＳＥＩ）は、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含むように構成される、
ビデオ・ソース符号化装置。
【請求項１９】
請求項１８に記載のビデオ・ソース符号化装置において、
前記第１のビデオ・フレームの画像開始コードを除く、前記後のビデオ・フレームの補足エンハンスメント情報（ＳＥＩ）フィールド内の前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を提供するように構成される、
ビデオ・ソース符号化装置。
【請求項２０】
請求項１７に記載のビデオ・ソース符号化装置において、
前記後のビデオ・フレームのために、画像ヘッダ・データ内の前記第１のビデオ・フレームの画像ヘッダ・データのいくつかのフィールドだけを反復するように構成される、
ビデオ・ソース符号化装置。
【請求項２１】
ビデオ・フレームのシーケンスを表すソース符号化ビット・ストリームのビデオ・ソース復号方法であって、前記ソース符号化ビット・ストリームは、符号化されるビデオ・フレームの各々について、それぞれ画定された符号化フレームを有する符号化フレーム構造を有し、前記方法は、
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第１のもので提供される、第１のソース符号化データを受信することであって、ただし前記第１のソース符号化データは、前記ビデオ・フレームのうち第１のものを表すと共に、該第１のビデオ・フレームのための画像ヘッダ・データと、該画像ヘッダ・データに対応する前記第１のビデオ・フレーム全体のソース符号化画像データとを含むことと、
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記第１の符号化フレームの後の第２のソース符号化データが、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含むが、前記対応する前記第１のビデオ・フレーム全体の前記ソース符号化画像データの複製は含まないかどうかを判定することと、
前記第１の符号化フレームで提供される前記第１のビデオ・フレームの画像ヘッダ・データが破損又は喪失していると判定した場合、前記第２のソース符号化データで提供される、前記第１のビデオ・フレームの前記複製された画像ヘッダ・データを、前記第１の符号化フレームで提供される、前記第１のビデオ・フレームの前記ソース符号化画像データを復号することに使用することと、
を含む、方法。
【請求項２２】
請求項２１に記載の方法において、
前記第２のソース符号化データが、前記第１のビデオ・フレームの画像ヘッダ・データおよび前記第１のビデオ・フレームのソース符号化画像データの第１のセグメントのみを含む、ビデオ・フレームの不完全な一部を表している場合に、前記第２のソース符号化データが、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含んでいると判定することを含む、方法。
【請求項２３】
請求項２１に記載の方法において、
前記第２のソース符号化データの画像ヘッダ・データが、以前に受信して正しく復号されたビデオ・フレームの画像ヘッダ・データの参照情報と同じ参照情報を有している場合は、前記第２のソース符号化データの画像ヘッダ・データと画像データとを無視することを含む、方法。
【請求項２４】
請求項２１に記載の方法において、
前記第２のソース符号化データが、画像ヘッダ・データおよび他のデータを含んでいる場合、前記第２のソース符号化データが前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含んでいると判定することを含み、ただし前記他のデータは、前記受信した第２のソース符号化データが基準となるビデオ・フレームに対して変化していないビデオ・フレームを表していることを意味するデータである、方法。
【請求項２５】
請求項２１に記載の方法において、
前記第２のソース符号化データが、前記ビデオ・フレームのシーケンスにおける前記第１のビデオ・フレームの後のビデオ・フレームを表し、且つ前記符号化フレーム構造の第２の符号化フレーム中のソース符号化ビット・ストリーム中で提供され、
さらに前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データおよび前記後のビデオ・フレームのソース符号化画像データを含み、
前記方法は、前記後のビデオ・フレームの画像ヘッダ・データをチェックして、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含んでいるかどうかをチェックすることを含む、
方法。
【請求項２６】
請求項２１に記載の方法において、
前記第２のソース符号化データが、前記ビデオ・フレームのシーケンスにおける前記第１のビデオ・フレームの後のビデオ・フレームを表し、前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第２のものの中で提供され、
さらに前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データと、補足エンハンスメント情報（ＳＥＩ）と、前記後のビデオ・フレームのソース符号化画像データとを含み、ただし前記補足エンハンスメント情報（ＳＥＩ）は、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含む、
方法。
【請求項２７】
請求項２６に記載の方法において、
前記以降のビデオ・フレームの補足エンハンスメント情報（ＳＥＩ）フィールドをチェックして、前記第１のビデオ・フレームの画像開始コードを除く、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含んでいるかどうかをチェックすることを含む、
方法。
【請求項２８】
請求項２５に記載の方法において、
前記後のビデオ・フレームの画像ヘッダ・データをチェックして、前記第１のビデオ・フレームの画像ヘッダ・データのいくつかのフィールドだけの反復を含んでいるかどうかをチェックすることを含む、
方法。
【請求項２９】
ビデオ・フレームのシーケンスを表すソース符号化ビット・ストリームを復号するためのビデオ・ソース復号装置であって、前記ソース符号化ビット・ストリームは、符号化されるビデオ・フレームの各々について、それぞれ画定された符号化フレームを有する符号化フレーム構造を有し、前記ビデオ・ソース復号装置が、
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第１のもので提供される、第１のソース符号化データを受信し、ただし前記第１のソース符号化データは、前記ビデオ・フレームのうち第１のものを表すと共に、該第１のビデオ・フレームのための画像ヘッダ・データと、該画像ヘッダ・データに対応する前記第１のビデオ・フレーム全体のソース符号化画像データとを含み、
前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記第１の符号化フレームの後の第２のソース符号化データが、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含むが、前記対応する前記第１のビデオ・フレーム全体の前記ソース符号化画像データの複製は含まないかどうかを判定し、
前記第１の符号化フレームで提供される前記第１のビデオ・フレームの画像ヘッダ・データが破損又は喪失していると判定した場合、前記第２のソース符号化データで提供される、前記第１のビデオ・フレームの前記複製された画像ヘッダ・データを、前記第１の符号化フレームで提供される、前記第１のビデオ・フレームの前記ソース符号化画像データを復号することに使用するように構成される、
ビデオ・ソース復号装置。
【請求項３０】
請求項２９に記載のビデオ・ソース復号装置において、
前記第２のソース符号化データが、前記第１のビデオ・フレームの画像ヘッダ・データおよび前記第１のビデオ・フレームのソース符号化画像データの第１のセグメントのみを含む、ビデオ・フレームの不完全な一部を表している場合に、前記第２のソース符号化データが、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含んでいると判定するように構成される、ビデオ・ソース復号装置。
【請求項３１】
請求項２９に記載のビデオ・ソース復号装置において、
前記第２のソース符号化データの画像ヘッダ・データが、以前に受信して正しく復号されたビデオ・フレームの画像ヘッダ・データの参照情報と同じ参照情報を有している場合は、前記第２のソース符号化データの画像ヘッダ・データと画像データとを無視するように構成される、ビデオ・ソース復号装置。
【請求項３２】
請求項２９に記載のビデオ・ソース復号装置において、
前記第２のソース符号化データが、画像ヘッダ・データおよび他のデータを含んでいる場合、前記第２のソース符号化データが前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含んでいると判定するように構成され、ただし前記他のデータは、前記受信した第２のソース符号化データが基準となるビデオ・フレームに対して変化していないビデオ・フレームを表していることを意味するデータである、ビデオ・ソース復号装置。
【請求項３３】
請求項２９に記載のビデオ・ソース復号装置において、
前記第２のソース符号化データが、前記ビデオ・フレームのシーケンスにおける前記第１のビデオ・フレームの後のビデオ・フレームを表し、且つ前記符号化フレーム構造の第２の符号化フレーム中のソース符号化ビット・ストリーム中で提供され、
さらに前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データおよび前記後のビデオ・フレームのソース符号化画像データを含み、
前記方法は、前記後のビデオ・フレームの画像ヘッダ・データをチェックして、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の複製を含んでいるかどうかをチェックするように構成される、
ビデオ・ソース復号装置。
【請求項３４】
請求項２９に記載のビデオ・ソース復号装置において、
前記第２のソース符号化データが、前記ビデオ・フレームのシーケンスにおける前記第１のビデオ・フレームの後のビデオ・フレームを表し、前記ソース符号化ビット・ストリームの前記符号化フレーム構造における前記符号化フレームのうち第２のものの中で提供され、
さらに前記第２のソース符号化データは、前記後のビデオ・フレームの画像ヘッダ・データと、補足エンハンスメント情報（ＳＥＩ）と、前記後のビデオ・フレームのソース符号化画像データとを含み、ただし前記補足エンハンスメント情報（ＳＥＩ）は、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含むように構成される、
ビデオ・ソース復号装置。
【請求項３５】
請求項３４に記載のビデオ・ソース復号装置において、
前記後のビデオ・フレームの補足エンハンスメント情報（ＳＥＩ）フィールドをチェックして、前記第１のビデオ・フレームの画像開始コードを除く、前記第１のビデオ・フレームの画像ヘッダ・データの少なくとも一部の反復を含んでいるかどうかをチェックするように構成される、
ビデオ・ソース復号装置。
【請求項３６】
請求項３３に記載のビデオ・ソース復号装置において、
前記後のビデオ・フレームの画像ヘッダ・データをチェックして、前記第１のビデオ・フレームの画像ヘッダ・データのいくつかのフィールドだけの反復を含んでいるかどうかをチェックするように構成される、
ビデオ・ソース復号装置。
【請求項３７】
請求項１１に記載のビデオ・ソース符号化装置を備えるネットワーク・デバイス。
【請求項３８】
請求項２９に記載のビデオ・ソース復号装置を備えるネットワーク・デバイス。
【請求項３９】
請求項１１に記載のビデオ・ソース符号化装置を備える端末デバイス。
【請求項４０】
請求項２９に記載のビデオ・ソース復号装置を備える端末デバイス。
【請求項４１】
請求項３７乃至４０のいずれかに記載のデバイスにおいて、
前記デバイスが、パケット交換網で動作するように構成される、
デバイス。
【請求項４２】
請求項３７乃至４０のいずれかに記載のデバイスにおいて、
前記デバイスが、回線交換網で動作するように構成される、
デバイス。
【請求項４３】
請求項３７乃至４０のいずれかに記載のデバイスにおいて、
前記デバイスが、移動通信網で動作するように構成される、
デバイス。
【請求項４４】
請求項３７乃至４０のいずれかに記載のデバイスにおいて、
前記デバイスが、インターネットで動作するように構成される、
デバイス。
【請求項４５】
請求項３７乃至４０のいずれかに記載のデバイスにおいて、
前記デバイスが、リアルタイム・ビデオを提供するように構成される、
デバイス。
【請求項４６】
請求項３７または３８に記載のネットワーク・デバイスを含むネットワーク。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、動画・静止画を含むビテオ画像を符号化・復号化する方法、およびその装置に関するものである。
【０００２】
【従来の技術】
移動通信分野における最近のターゲットのひとつは、データ移送速度をより増加させて、移動ネットワークに対するマルチメディア・サービスの組込みを拡大発展させてゆくことである。マルチメディアのキーとなる構成要素のひとつは、デジタルビデオ画像技術である。画像データの移送は、動画表現データの明確な継時的輸送や移動を含むものである。
【０００３】
一般的に知られているように、画像の移送に必要なデータ量は、メディアの他の多くのタイプとよく比較されるが、低ビット率の装置端末類でのビデオ画像の使用に限れば、無視してもよい程度となっていた。
しかしながら、低ビット率のビデオ画像圧縮技術の分野では、かなり顕著な進展が遂げられてきている。受入れ可能な画像品質は、ビット率が１秒当たり約２０キロビットのときに、得ることができる。そして、ビット率の飛躍的な低下の結果として、移動通信よりもっと多くのチャンネルを提供することで、ビデオ画像の移送技術は今後有望なサービスとなりうるものである。
【０００４】
ビデオ画像シーケンスは、スティル画像(静止画像イメージ)またはフレームの連続のものから構成される。ビデオ画像圧縮方法は、画像シーケンスのリダンダンシー(冗長度)と知覚的に不適合な構成要素とを減らすことを基本としている。ビデオ画像シーケンスにおけるリダンダンシー(冗長度)は、空間的・時間経過的・スペクトラル(分光的)なリダンダンシーの中に分類されることができる。
空間的リダンダンシーとは、ひとつのフレーム中(画面内)での隣接する画素(ピクセル)間の相関関係を意味する。また、時間経過的リダンダンシーは、時間の経過順的な複数フレームのエリア間の相関関係(前画面との)を意味する。この時間経過的リダンダンシーは、前の画面(画像)で現れて現在の画面(画像)でも現れる対象物のゆう度(likelihood)によって、起こってくるものである。
【０００５】
圧縮化は、動き補償データを発生させることにより達成されるが、それらの動き補償データは、現在と過去の画像(静止画像イメージ)の類似するエリア間での動き(たとえば、転移や置換など)を描くものである。この現在の画像は、以前の画像からこのようにして予測される。そして、スペクトラル(分光的)リダンダンシーは、同じ画像の異なる色彩の構成要素間における相関関係を意味する。
【０００６】
ビデオ画像データ圧縮方法は、画像間で典型的に区分されていて、時間的リダンダンシーの減少を利用するかしないか、に依っている。時間的リダンダンシーの減少を利用しないで圧縮された画像データは、通常は「INTRA-frames」または「Ｉ-frames」と呼ばれる。これに対して、時間的に予測された画像データは「INTER-frames」または「Ｐ-frames」と呼ばれる。また、INTERフレームが前または後ろにある方式(マナー)で予測される可能性があるようなときには「Ｂ-frames」と呼ばれる。このINTERフレームの場合には、予測された(動作が補償された)画像は、ほとんど正確なものとはならず、それゆえに、空間的な圧縮された予測エラー画像は、それぞれのINTERフレームの１パートでもある。
【０００７】
しかしながら、ビデオ画像シーケンスのリダンダンシーを単に減少させることにより、十分な圧縮化がいつでも達成されるわけではない。このように、ビデオ画像エンコーダ(デコーダ)においては、本来重要ではないビデオ画像シーケンスのこれらパーツの品質を減らす試みがなされている。これに加えて、復号化されたビット・ストリームのリダンダンシーは、効率的なロスのない、圧縮パラメーターと係数因子の符号化(coding)によって、減少させられる。
【０００８】
圧縮されるビデオ画像は、主に２つの理由による通信エラーによって、容易に破損や改悪をさせられてしまう。第１には、時間予測フレーム間差分符号化方式(INTERフレーム)のために、ひとつのエラーが空間と時間の両方に伝搬させられてしまうことである。実際に、エラーが起こると、比較的長い時間の間、人の目に容易に視覚的にとらえられる。少数のINTRA符号化されたフレームだけがあるというような、低ビット率での通信では、とりわけ、影響を受けやすくなる。 (INTRA符号化されたフレームの通信は、時間的なエラー伝搬を終わらせてしまうこととなろう。)
【０００９】
また第２には、可変長型の符号化方式を使用すると、エラーに対する感受性が増加してしまう。ビット・エラーが、ひとつの符号語を異なる長の符号語に変更するときに、デコーダは、符号語同期性を失ってしまい、その後に続くエラーなしの符号語(いくつかのビットからなる)を、次の同期またはスタートコードまで、不正確に符号化してしまう。（同期符号はビットパターンであって、他の符号語の合法的な組合せからつくられることはできない。）
【００１０】
無線データ通信の固有の特性のひとつは、比較的高いエラーの可能性である。その問題は、様々な通信・ネットワーク・リンク層再通信などの手段によって、アドレス指定されることである。しかしながら、そのような組織体系の障害は、制限がされてなくて、揺動的な伝送遅延の可能性である。従来のオーディオ・ビジュアル・サービスにおいて、エンド・ツー・エンド式の大きな遅延は受け入れ難いものである。こうした再通信方式は、そのようなサービスで用いることはできない。かわりに、通信エラーを探査して隠匿するように試みられなくてはならない。
間断のないオーディオ・ビジュアル探索サービスにおいて、プレイバックのスタート以前にいくつか初期的バッファリングが起きるという事実によって、伝送遅延は種々に変化することがありえる。しかしながら、最大の受容可能な遅延は固定化されうるし、もし遅延が大き過ぎるのであるなら、プレイバックでのアノイング・ポーズがある。実際には、信頼できるものと信頼できないものの両方の通信チャンネルが、探索サービスにおいて用いられている。
【００１１】
圧縮されたビデオ画像データのビット・ストリームにおけるすべてのビットは、減圧された画像(イメージ)と同じ重要性を有しているわけではない。いくつかのビットでは、これまで使われてきた画像タイプ(INTRAやINTER等)・量子化の値・任意の符号化モードのような大切な情報を、定義している。ITU-T推奨H.263は、低ビット率コミュニケーション向けのビデオ画像符号化に関係を有している。H.263では、最も重要な情報は画像ヘッダーに集められる。画像ヘッダーでの通信エラーは、画像内容を定義する続きのビットの全体的な誤処理を、典型的に引き起こすことがある。時間予測差分符号化方式(INTERフレーム)のために、そのエラーが空間と時間の両方に伝搬させられてしまう。こうして、画像ヘッダーの改悪(破損)までの普通のアプローチは、画面上での前画像を凍結すること、通信末端部までINTRA画像要求を送ること、要求されたINTRAフレームを待つこと、である。このことは、受け取られたビデオ画像、特には、リアルタイムの従来のビデオ画像シーケンスにおいて、迷惑ポーズの原因となることがある。
【００１２】
伝送のエラーは、張り巡らされたネットワークに依存するという異なる特質を有する。インターネットなどのようなパケット交換型のネットワークでは、伝送エラーは、代表的にはパケット損失であり、これはネットワーク構成要素の過密化によるものである。
移動通信ネットワーク(GSMのためのHSCSD等)のような回路スイッチ型のネットワークでは、伝送エラーは代表的にはビット・エラーであり、例えば１が０に改悪されるなどのことが起こる。
【００１３】
伝送エラーによって導かれた画像(イメージ)データでの劣化を妨げるために、再伝送がなされうるし、エラー探索および／またはエラー修正の方法が適用されうるし、得られた改変データからの影響を隠すこともできうる。通常は、再伝送手段は、エラーからビデオ画像データ・ストリームを保護するための道理ある道筋を提供する。しかし、低ビット率伝送と中庸または高いエラー・レートとを伴なう、大きな周旋型の遅延においては、実際のところ再伝送は不可能となり、特に、リアルタイムのビデオフォーン・アプリケーションを伴なう場合はそうである。エラー探索と修正の方法では、データにいくつかリダンダンシーを加えるため、大型架空送電設備が通常的には必要となる。それと同時に、低ビット率アプリケーションのために、伝送エラーから画像(イメージ)を保護して回復させるための好適なやり方として、エラーの隠蔽が考慮されなければならない。ビデオ画像エラーを隠蔽する方法として、典型的には、パケット損失とビット改悪(破損)を通して起こる伝送エラーに適用することが可能である
【００１４】
Ｈ.263は、低ビット率コミュニケーションのためのビデオ画像符号化のITU-T推奨であり、一般的には64 kbps以下のデータ・レートを意味する。この推奨では、ビット・ストリーム・シンタックスとビット・ストリームの復号化とを規定している。近年、Ｈ.263にはふたつのバージョンがある。Ｈ.263バージョン１は、コア・アルゴリズムと４つのオプショナルの符号化モードから構成される。またＨ.263バージョン２は、バージョン１の拡張版であって、新しい取り決めの符号化モードを提供するものである。Ｈ.263は、現在では移動無線通信に適用される最も好適な符号化方法のひとつであり、ビット率が毎秒当たり28.8ビットのオーダーのもので、176×144画素のQCIF画像(Quarter Common Intermediate Format)のものが、よく用いられている。現在では、第三世代の無線製品向けにと期待されたビット率は約64 kbpsであって、その画像(イメージ)解像度はより高くなる可能性がある。
【００１５】
画像は、輝度(Ｙ)と２つの色彩の差異(クロミナンス)構成要素(ＣBとＣR)として符号化がなされる。クロミナンス画像は、両方の座標軸に沿ってクロミナンス画像の半分の解像度でサンプリングされる。画像データは、ブロック毎を基礎にして符号化され、それぞれのブロックは、輝度またはクロミナンスの8×8画素を画像表示する。
【００１６】
それぞれの符号化された画像は、対応する符号化のされたビット・ストリームと同様に、４層を有する階層構造に調整配置がなされ、その階層構造は下から上に「ブロック層・マクロブロック層・画像セグメント層・画像層(ピクチャー・レイヤ)」である。また、画像セグメント層は、ブロックのグループまたは分層(スライス)として調整配置されることもできる。
【００１７】
ひとつのブロックは、輝度またはクロミナンスの8×8画素に関係している。ブロック層データは、一様な量子化された別々の余弦変成係数から構成されていて、これらは、ジグザグ・オーダーでスキャンがなされ、ラン・レングス復号装置で処理され、可変長のコードで符号化される。
【００１８】
それぞれのマクロブロックは、輝度の16×16画素、および、空間的に対応する２つのクロミナンス構成要素の8×8画素と、関係を有している。言葉を代えれば、  ひとつのマクロブロックは、４つの8×8輝度ブロックと、２つの空間的な対応する8×8色彩の異なるブロックと、から構成される。
それぞれのINTERマクロブロックは、ひとつの動作ベクトルと関連付けがなされ、このベクトルは、最新のINTERマクロブロックの画素と類似する参照フレームでの対応エリアの位置を規定する。このINTERマクロブロック・データは、マクロブロックの画素の符号化された予測エラーデータを含んでいる。
【００１９】
通常では、それぞれの画像(ピクチャー)は、ブロックのグループ(ＧＯＢｓ)として知られるセグメントに分割される。ＱＣＩＦ(Quarter Common Intermediate Format)画像のためのブロックの１グループ(ＧＯＢ)は、典型的には、複数のマクロブロックのひとつの行を構成する(たとえば、11のマクロブロック)。それぞれのGOBのためのデータは、オプショナルのGOBヘッダーから構成されていて、GOBヘッダーはGOB内でのマクロブロックのためのデータに従うものである。
【００２０】
もし、オプショナルのスライス構造のモードが用いられるとすれば、それぞれの画像(ピクチャー)は、ＧＯＢｓの代わりにいくつかのスライスに分割される。ひとつのスライスは、スキャン・オーダーの連続するマクロブロックのある数を含んでいる。それぞれのスライスのデータは、スライス・ヘッダーから構成されていて、スライスヘッダーは、そのスライスのマクロブロックのためのデータによって従われる。
【００２１】
画像(ピクチャー)レイヤデータはパラメーターを含んでいて、これらのパラメーターは、全体の画像エリアと画像データの復号化に影響を及ぼす。符号化されたパラメーターデータは、いわゆる画像ヘッダーに調整配備がなされる。ＱＣＩＦフォーマットにおいて、ひとつの画像は、１１のマイクロブロックの９行に対応する176×144画素(ピクセル)に分割される。
【００２２】
画像(ピクチャー)とGOB(またはスライス)ヘッダーは、同期(シンクロナイゼーション)またはスタート・コードをもって、始まる。他の符号語または符号語の合法的組合せが、同期コードと同じビットパターンを形成することはない。このようにして、同期コードは、ビット・ストリームエラー探査のためと、ビット・エラーの後の再同期のために用いられる。
【００２３】
H.263はビデオ画像圧縮標準であり、これはITU-T推奨H.324「低ビット率コミュニケーションのための端末(1998年2月)」で使用されており、PSTNを越えるビデオフォーン・コミュニケーションおよび移動通信ネットワークを規定している。H.324の接続が無線チャンネルを越えてしまうと、受信されたビット・ストリームは通信エラーを含むものとなりやすい。H.263のビデオ画像ビット・ストリームでは、これらのエラーが、もし画像ヘッダーの中で起こるものなら、非常に害を及ぼすこととなる。そのようなエラーが、画像コンテンツの符号化を妨げることがある。INTRA画像(ピクチャー)ヘッダーでのエラーは、これらの画像が初期的時間予測のソースとして使用されるので、最も厳しい含意(implications)を引き起こす原因となる。また、あるINTRA画像(ピクチャー)ヘッダーでのエラーは、対応する符号化されたINTRA画像と、このINTRA画像から初期に予測されたそれぞれの一連の画像とに、有害な影響を及ぼす。
【００２４】
【発明の実施の形態】
本願発明に従えば、特許請求の範囲には、ビデオ画像の符号化と復号化に関する方法が提供されている。また、ビデオ画像の符号化または復号化に関連する装置もまた、特許請求の範囲に示されている。
【００２５】
本願発明の第１の実施の形態では、ビデオ画像のビット・ストリームで、INTRA画像(ピクチャー)ヘッダーを反復する新規な方法を提唱しており、これはITU-T H.324推奨に十分に追従するものである。また本願発明は、ビット・ストリームでの画像(ピクチャー)ヘッダーのリダンダント・コピーを提案している。もしも、最初の画像(ピクチャー)ヘッダーが改悪させられたとき、画像(ピクチャー)コンテンツの復号化を可能とするために、デコーダはそれのコピーを使用してもよい。本願発明では、INTRA画像(ピクチャー)ヘッダーの反復方法を提供し、これはH.263の標準的なシンタクスと意味論(semantics)を用いている。それゆえに、すべての標準追従型のデコーダは、本願発明の方法を使用することができる。
【００２６】
少なくともINTRAフレームのための画像(ピクチャー)ヘッダーの反復を含むことは、受信しているデコーダは必ずしも表示画面を凍結させておいたり、エンコーダに反復要求を送ったり、繰り返された情報を送信するためエンコーダを待っている、というようなことが、必ずしも必要ない、ということを意味する。このような画像(ピクチャー)凍結のための不愉快なポーズ時間を発生させることがなく、末端のユーザーはより高品質のビデオ画像を知覚できるものである。
【００２７】
本願発明は、リアルタイムにでも、またノン・リアルタイムにでも適用することが可能であり、受信中のデコーダからのINTRA反復要求に応答することはできないような情報データ復旧サービスにも適用が可能である。
【００２８】
本願発明については、ここではそのわずかな例が示されるだけであるが、これより添付する図面を参照しながら記載されるものである。
図１は、マルチメディア移動通信コミュニケーション・システムの一例を示す。
図２は、マルチメディア端末のマルチメディア構成要素の一例を示す。
図３は、H.263に従って符号化されたビデオ画像信号の代表的なデータ構造の一例を示す。
図４は、本発明によるビデオ画像コーデックの一例を示す。
【００２９】
図５は、本発明の第１の実施の形態によるエンコーダにより符号化されたビデオ画像信号出力のデータ構造の例を示す。
図６は、本発明の第２の実施の形態によるエンコーダにより符号化されたビデオ画像信号出力のデータ構造の例を示す。
図７は、本発明の第３の実施の形態によるビデオ画像エンコーダの処理を示すフロー図である。
図８は、本発明の第１の実施の形態によるビデオ画像デコーダの処理を示すフロー図である。
図９は、本発明の第３の実施の形態によるビデオ画像デコーダの処理を示すフロー図である。
【００３０】
本発明のさらなる記載や説明は、H.324とH.263の推奨を参照にしながら、なされるものである。しかしながら、これらまたは関係するプロトコルに本発明を適用するにあたって、本発明に限定を加えようとする意図は、出願人は全く持っていない。
【００３１】
図１は、代表的なマルチメディア移動通信コミュニケーション・システムの例を示す。この図で、第一のマルチメディア端末１と第二のマルチメディア端末２とは、通信接続によって、リンク手段３とネットワーク４を介して、コミュニケーションをとる構成である。制御データはふたつの端末(１・２)間に送信され、マルチメディア・データも同様である。そして、本発明の実施の形態で記載されているように、マルチメディア端末(１、２)はモバイル／無線のビデオ・フォーンであり、コミュニケーション・ネットワークはＧＳＭのようなネットワークである。ここで採用されているコミュニケーション用リンク３は、ラジオ無線リンクである。本発明の他の実施の形態では、マルチメディア端末はPSTN(Public Switched Telephone Network)ビデオ・フォーンでも、移動マルチメディア端末でもよいし、また、PSTNマルチメディア端末でもよい。マルチメディア端末(１、２)は、ビデオ・テレフォニーのようなリアルタイム・アプリケーションのものが使用されてもよく、復旧型サービスのようなノン・リアルタイム・アプリケーションのものも使用されてよい。
【００３２】
図２は、H.324に適合する端末１の代表的なマルチメディア構成示す。この図で、この端末は、H.263適合のビデオ画像コーデック１０、G.723.1適合のオーディオ・コーデック２０、T.120適合のデータ・プロトコル制御部３０、H.245コントロール・プロトコルに従って信号を出力する主制御部(コントロール部)４０、H.223適応のマルチプレクサ／ディマルチプレクサ５０、モデム６０(もし必要なら)、を備えて、構成されている。
【００３３】
ビデオ画像コーデック１０は、符号化する端末の画像獲得用装置(例えば、図示していないがカメラなどによる)から信号を受信して、そして、離れた所にある復号化のための別の端末２からの信号を受信して、表示部７０(画面、ディスプレー)のある端末１に表示する。
オーディオ・コーデック２０は、端末１のマイクロフォン(図示せず)から符号化のための信号を受信して、離れた所にある復号化のための別の端末２からの信号を受信して、端末１のラウド・スピーカー(図示せず)により再生を行う。
上に示した標準的なシステムは、単に一例証を提示しただけであって、本発明を限定する意図はなにもない。
【００３４】
主制御部４０は、画像コーデック１０、オーディオ・コーデック２０、データ・プロトコル制御部３０、マルチプレクサ／ディマルチプレクサ５０の制御を行う。しかしながら、本発明では、ビデオ画像コーデック１０の制御に多大の関心があるので、端末の他の構成要素に関する説明や検討などについては、あまり多くを記述してはいない。
【００３５】
このビデオ画像コーデック１０は、信号源(図示せず)からデジタル入力ビデオ画像信号を受信する。ビデオ画像信号は、それぞれのフレームがひとつの静止画像(イメージ)である複数フレームのシーケンスを描出する。シーケンスで表示されたときに、動きを含むある画像(イメージ)の印象を、フレームが提供することができる。複数フレームのシーケンスは動画(動的イメージ)として、こうして表示されることになる。コーデック１０は、信号源(図示せず)から動画(動的イメージ)を符号化し、そして、受信された信号を復号化して表示部７０に動画(動的イメージ)を供給する。
【００３６】
図３は、H.263に従って符号化された画像信号のあるフレーム(またはピクチャー)のためのデータ構造を示す図である。それぞれのフレームは、画像(ピクチャー)ヘッダー８０から始まり、通常は約５０ビットである。
画像(ピクチャー)ヘッダー８０は、次のものを含む。
【００３７】
・同期のための画像(ピクチャー)スタート・コード(PSC)
・一時的な参照基準(ＴＲ)； 一時的で前の参照基準画像(ピクチャー) (例えば、I-フレームなど)のヘッダーにおいて、ＴＲの値を増分することで形成され、前に伝送された参照基準画像(ピクチャー)から、スキップされた画像(ピクチャー)または非参照基準の画像(ピクチャー)の数が加えられる。
・タイプ情報(PTYPE)； 他のものの中にあって、そのフレームがINTRAフレームまたはINTERフレームかどうか、画像(ピクチャー)のフォーマット(CIF,QCIFなど)かどうか、などの指示や表示を行う。
・クアンタイザー(量子化装置)の情報(PQUANT)； 画像(ピクチャー)の残りのために用いられるDCTクアンタイザーを表示または指示させる。
【００３８】
画像(ピクチャー)ヘッダー８０をフォローする(に従う)のは、画像(ピクチャー)の第１セグメント(ＧＯＢ,sliceなど)のための画像(ピクチャー)データ８２である。画像(ピクチャー)ヘッダー８０が存在するために、第１セグメントのためのセグメント・ヘッダーは不要である。こうして、画像(ピクチャー)ヘッダー８０をフォローするの画像(ピクチャー)データ８２は、マクロブロック動作ベクトル８２１(適用可なら)とブロックデータ８２２とを含んでいる。
【００３９】
画像(ピクチャー)の第１セグメントのためのデータ８２のあとは、次のセグメントのためのセグメント・ヘッダー８４(例としてＧＯＢヘッダー)である。
ＧＯＢヘッダーは、次の要素を含む。
・同期のためのＧＯＢスタート・コード(ＧＢＳＣ)
・画像(ピクチャー)の中にあって、そのGOBの数を示すグループナンバー(GN)
・ＧＯＢフレームID(GFID)；ひとつの与えられた画像(ピクチャー)のすべてのセグメントにおいて同じ値を有し、また、２つの画像が同じタイプ(I,P等)のものであるなら、前に符号化された画像と同じ値を有する。
・クアンタイザー(量子化装置)情報(PQUANT)；これは、画像(ピクチャー)の残りのために用いられるクアンタイザーを、表示または指示させるもの (ビット・ストリームで連続して変化されないなら)。
【００４０】
画像(ピクチャー)の第２セグメントのためのセグメント・ヘッダー８４は、次のセグメントのための画像(ピクチャー)データ８６(例えば、マクロブロック動作ベクトル(適用可なら)とブロックデータ)にフォローされている。フレーム・データは、全てのフレームが符号化されるまで、セグメント・ヘッダー８４と画像(ピクチャー)データ８６に続いている。次のフレームのための画像(ピクチャー)ヘッダー８０は、そのとき(それから)送られる。
【００４１】
画像(ピクチャー)ヘッダーの損失が、画像(ピクチャー)復号化で深刻な影響を及ぼすことは、リーダーには明瞭になっている。デコーダ(復号化装置)は、画像(ピクチャー)に同期させることはできないし、その画像がどのように符号化される(ＩまたはＰ)のかなどについては分からない。従来には、その画像(ピクチャー)ヘッダーが改悪されたとき、データの全てが放棄され、そして、INTRA画像(ピクチャー)更新のための要求が、伝送するデバイスに送られる。応答として、伝送するデバイスはINTRAモードであるフレームを符号化して、現在の画像(ピクチャー)は、この新規のINTRA符号化データが受信されて復号化されるまで、表示部上に凍結させられる。
【００４２】
図４は本発明にかかるビデオ画像コーデック１０の一例を示す図である。このビデオ画像コーデックは、符号化(エンコーダ)パート100と復号化(デコーダ)パート200とからなっている。
【００４３】
端末２に符号化ビデオ画像データを伝送する端末として端末１を考慮するに、ビデオ画像コーデック１０の制御に関しては、符号化(エンコード)の役割のものを、ここでは記載することとする。符号化パート100は、カメラからのビデオ画像信号、または端末１のビデオ画像ソース(図示せず)を受信するための入力部101を備えている。スイッチ102は、符号化のINTRAモードとINTERモードとの間でのエンコーダを、スイッチ動作させる。
【００４４】
INTRAモードでは、入力部101からのビデオ画像信号は、DCT変換部103に直接的に入力されて、ここでピクセル(画素)データをDCT係数に変換する。このDCT係数はそれからクワンタイザー104に伝えられ、係数の量子化を行う。スイッチ102とクワンタイザー104の双方とも、ビデオ画像コーデックの符号化制御部105によって制御がなされ、H.245主制御部40によって、受信する端末２からのフィードバック制御を受ける。クワンタイザー104からのデータ出力は、逆クワンタイザー108と逆DCT変換装置109を通して、伝えられる。結果のデータは、加算器110によって画像(ピクチャー)記憶部107のコンテンツへ加算される。INTRAモードにおいて、スイッチ115は開かれて、画像(ピクチャー)記憶部107のコンテンツが、逆DCT変換器109の出力によって上書きがなされる。
【００４５】
INTERモードでは、スイッチ102が開かれて、サブトラクター106から、入力部101からの信号と前のピクチャー画像(画像(ピクチャー)記憶部107に記憶保管されている)との間との相違データを受け入れる。サブトラクター106からの相違データ出力は、現在の画像(ピクチャー)と画像記憶部107に記憶保管されている過去(前)の画像(ピクチャー)との間の予測エラーを描出する。予測エラーはDCT変換と量子化がなされる。画像記憶部107にあるデータは更新されるが、逆クワンタイザー108と逆DCT変換部109を介して、クワンタイザー104によるデータ出力がなされ、加算器110により画像記憶部107のコンテンツへ結果データが加算され、スイッチ115は閉じられる。動作推定評価部111は、従来の方式により、画像記憶部107にあるデータから動作補償データを発生させてもよい。
【００４６】
ビデオ画像符号化のコーダー100は、ヘッダー情報(一時的参照基準など)を供給するが、他にも、符号化されたフレーム番号を示す矢印(→)TR 112、符号化された(ＩまたはP/B)モードを示すINTRA/INTER矢印(→)112b、量子化インデックス112c(例、使用されたクワンタイザーの詳細)、量子化されたDCT係数112dと,符号化された画像(ピクチャー)のための動作ベクトル112e、などを提供する。これらは、可変長のコーデック(VLC)113により、符号化とマルチプル化が施される。復号化(エンコーダ)の出力は、マルチプレクサ50による他の信号を伴なって、そのときマルチプレクサ化がなされる。
【００４７】
本発明の第1の実施の形態では、エンコーダは、全てのINTRAフレームの後にピクチャー画像ヘッダーの反復を送るよう調整がなされる。データ記憶部114は、それゆえに反復されるデータの一時的記憶のために提供される。第1の実施の形態において、全てのINTRAフレームのために、ピクチャー画像ヘッダー80とデータ８２の第１セグメントは、受信するデコーダへ伝送のために、反復動作をされる。こうして、エンコーダは、図５に示されるような形式により、データ出力を行う。
【００４８】
図５に示されるように、符号化されたビデオ画像信号は、画像信号の第１画像510用のデータをもって、開始する。このフレームは符号化されたINTRAである。そのデータは、ピクチャー画像ヘッダー８０、第１のセグメント８２のためのデータ、ヘッダー８４、第１画像の連続的セグメントのためのデータ８６、を含んで構成される。ピクチャー画像ヘッダー８０と、第１画像(ピクチャー)510の第１セグメントのためのデータ８２とは、データ512としてそれから反復(繰り返し)が行われ、反復されたピクチャー画像ヘッダーは、オリジナルなフレームとして同じ一時的参照基準ＴＲを有する。また、反復されたデータは、連続するINTER符号化フレーム520,522,524のためのデータによって続けられていく。次のINTRAフレームが符号化されるときは、そのフレームのためのデータ510'は、ピクチャー画像ヘッダー８０の反復(繰り返し)512'とINTRAフレーム510'のための第１セグメントのためのデータ８２とが、フォローされる。
【００４９】
このような調整や配置は、28.8 kbps接続とＱＣＩＦ画像のためのＩＮＴＲＡフレームにつき約227バイトのオーバーヘッドへ導くこととなる。
【００５０】
受信するデコーダは、それゆえに、ヘッダー情報の同一複製のものを、受け取る。このシナリオでは、デコーダは、Reference Picture Selection(ＲＰＳ)を参照基準とするH.263のAnnexＮで描写されるように制御され、調整がなされる。H.263 AnnexＮによれば、もしもデコーダが、同じ一時的参照基準(ＴＲ)を有する２またはそれ以上のピクチャー画像ヘッダーを受信すると、そのとき、その２番目と連続するピクチャー画像ヘッダー(そして関連するデータも)は、デコーダによって無視される。こうして、受信するデコーダが、ピクチャー画像ヘッダーの最初の発生を正確に復号化させるよう制御するならば(そしてこのヘッダーのＴＲを読み取る)、デコーダはピクチャー画像ヘッダーの反復を無視する。こうして、本発明の第１の実施の形態によるエンコーダは、たとえそのような装置調整が本発明の便宜に帰することにはならなくとも、従来のデコーダを制御することも可能である。しかしながら、それらの互換性は提供可能である。
【００５１】
上記した第１の実施の形態において、反復されたデータは、あるフレームの不完全パートと、特にピクチャー画像ヘッダーとピクチャー画像の第１セグメントのためのデータとに関連付けがなされる。本発明によるデコーダは、それゆえに、不完全フレームのためのデータが受信されたことを探査することにより、反復されたデータの存在を探査し、フレームを完全にするために記憶されたデータを使用する。
【００５２】
本発明にかかるエンコーダの第２の実施の形態において、リダンダントのビデオ画像フレームが、符号化されたビット・ストリームに加えられる。そのようなリダンダント・フレームは、伝送されたビデオ画像シーケンスへの付加的情報を提供するためには用いられない。代わりに、リダンダント・フレームは前の画像(ピクチャー)のピクチャー画像ヘッダーを反復するのに用いられる。リダンダント・フレームは、本発明にかかるデコーダによってビデオ画像ビット・ストリームに加えられる。リダンダント・フレームの存在により、デコーダへの明快な信号送信がなされ、そのデコーダは、そのようなリダンダント・フレームの存在を探査するため、リダンダント・フレームの絶対的な特質を使用してよい。
【００５３】
図６は、本発明の第２の実施の形態にかかり、エンコーダによる信号出力のフレーミング構造を示す。そのエンコーダは、それぞれのINTRAフレーム610の後にリダンダント・フレーム612を発生させて送出するように調整されて構成がなされる。H.263によれば、参照基準画像(ピクチャー)選択(ＲＰＳ)モードが選択されないと、連続する圧縮された画像(ピクチャー)は同じ非圧縮画像(ピクチャー)を表示することはできない。本発明の第２の実施の形態は、選択されるＲＰＳを頼りにしてはいない。この場合において、ピクチャー画像ヘッダーだけは、データ記憶部114に記憶保管される。制御部105の制御のもと、オリジナルのピクチャー画像ヘッダー８０は変えられ、新しいピクチャー画像ヘッダー８０'がINTRAフレーム610のためのものと同じになるようにされるが、ただし、PTYPEフィールドにおける画像符号化タイプがＩからＰへ変化させられること、と、ＴＲフィールドが増加させられること、とは、除かれる。
【００５４】
制御部105はフィールド88の設定を行い、全フレームのためのデータへの変化はなかったことを示す。H.263で、このフィールドは、符号化マクロブロック・インディケーション(ＣＯＤ)フラッグを含み、マクロブロックに関して設定がなされ、これはINTER符号化がなされ、設定時には、マクロブロックに送られるさらなる情報はないことを、示す。連続するINTERフレーム620,622,624は、図５に示したフレーム520,522,524と同じように符号化され、次のINTRAフレーム610'まで送信される。
【００５５】
本発明による別の実施の形態によれば、リダンダント・フレームは、INTRAフレームと同様にINTERフレームの後に含まれる。
【００５６】
反復されるデータ612のリダンダント・フレームは、約50ビットのピクチャー画像ヘッダー80'と、99ＣＯＤビット(QCIFピクチャー画像内の99のマクロブロックのそれぞれのためのひとつ)と、完全なフレームのためのビット整数を作るためのいくつかの詰込みビットとを含んで構成される。また同様に、そのようなリダンダント・フレームは、代表的には、19バイトからなり、28.8 kbpsH.263接続とQCIF画像のためのデータ・ストリームへのオーバーヘッドの約８％を加算することとなる。それぞれのINTRAフレームとINTERフレームとがリダンダント・フレームに一緒にされるときだけ、このオーバーヘッドの値が適応する。明らかにそのオーバーヘッドは、リダンダント・フレームがそれぞれのINTRAフレームだけの後に符号化されるのなら、減らされてよい。
【００５７】
図５および図６を参照して記述してきたように、あるフレームのための反復されたピクチャー画像ヘッダーは、画像(ピクチャー)のフレームのためのオリジナルデータへ連続的に供給され、また次のフレームのためのデータより先に供給される。
【００５８】
デコーダの第３の実施の形態が、今ここに記載される。この実施の形態は、H.263の追加的画質向上情報(Supplemental Enhancement Information,ＳＥＩ)フィールド(AnnexＬ)に新しく追加するにおいての基礎とされる。この追加は、現在の画像(ピクチャー)の追加的画質向上情報フィールドにおける、前の画像のある画像レイヤフィールドの反復を可能としている。(画像(ピクチャー)レイヤフィールドは同じ画像内で反復されない。それらが、画像レイヤデータ自体と同じ時間に改悪させられるという危険があるからである。)
【００５９】
画像ヘッダーで追加的画質向上情報を含むものは、H.263に従って、矢印PEIによって示される。PEIが設定されるなら、８ビットフィールドRSUPPにおいて、供給情報が続いてゆくことが、指示または表示される。さらなる(後続する)PEIは、さらなる(後続する)RSUPPフィールドがさらなる(後続する)情報を伴なって続いてゆくことを、示している。
【００６０】
デコーダは、AnnexＬにおいて画像表示される拡大された性能をサポートすることはなく、もしPEIが１に設定されるなら、PSUPPを放棄するよう設計がなされる。このことは、AnnexＬの拡大された性能のための、過去分からの互換性を可能としていて、よって、拡大された性能の使用をさせるビット・ストリームは、拡大された性能をサポートしないデコーダによる改変を無くして、使用されることができる。
【００６１】
H.263のAnnexＬは、このリコメンデーション(推奨)の画像のPSUPPフィールドに送られた追加的画質向上情報フォーマットを、画像表示する。追加的画質向上情報の存在はPEIに示され、そして、追加的PEIビットはPSUPPデータの全てのオクテットの間に挿入される。
【００６２】
PSUPPデータは、ある４ビット構成タイプ表示FTYPEから成り、４ビット・パラメータ・データサイズ仕様DSIZEにフォローされる、機能パラメータ・データのDSIZEオクテットにフォローされる、他の機能タイプ表示指示手段にオプショナル的にフォローされる、などのようにして、構成がなされる。サポートされない機能タイプ表示を受けとるデコーダは、その機能のための機能パラメータ・データを放棄することができ、サポートされている連続する機能タイプ表示をチェックする。定義がなされたFTYPE値は、H.263のテーブルL.1に示される。
【００６３】
本発明の実施の形態は、H.263のAnnexＬにいくつかの変更を要求する。これら変更点は次のとおりである。
１. H.263のテーブルL.1での新規機能タイプ表示(FTYPE)の定義について。例えば、エントリー13−画像(ピクチャー)レイヤデータ反復再現。
【００６４】
２. FTYPEコードの影響効果の説明の、AnnexＬで包含する点。
画像(ピクチャー)レイヤデータ反復再現機能は、前画像の画像レイヤデータの符号化された描出(表示)のフィールドが反復されることである。反復されるフィールドは、一時的参照基準(ＴＲ)フィールドから始まる自然なシンタクティク・オーダーで、出現する。言葉を代えれば、PEIビットが反復画像(ピクチャー)レイヤ・データから取り除かれるなら、反復のビット・ストリームは、対応ポジションにある元のビット・ストリームと全く同じになるであろう。SEIのDSIZEフィールドは、反復されたバイトの数を表示する。ゼロに等しいDSIZEは、これからの使用のために保存される。画像(ピクチャー)ヘッダー情報はFTYPE／DSIZEオクテットに従う。
【００６５】
この提案された方法は、考慮されるべき遅延を引き起こし、この遅延は、改悪された画像ヘッダーを回復するとき、前の実施の形態と比較される。というのは、次の画像(ピクチャー)の開始が受信されるまで、その回復は起きないからである。しかしながら、デコーダの制御処理は、少なくとも低フレーム・レートでは、リアルタイム画像データ送信よりも相当速いものであって、デコーダは、次の画像(ピクチャー)の到着を待つために消費される時間を回復することができる。
【００６６】
第３の実施の形態によるエンコーダを実施するための、ひとつの可能なやり方が、図７のフローチャートとして示されている。実施の形態の見地から見て、ピクチャー画像ヘッダーは、ビット・ストリーム同期性シンタックスでの追加的画質向上情報（ＳＥＩ）に先立つ画像（ピクチャー）レイヤデータを、参照することになる。
【００６７】
非圧縮信号が、あるフレーム・レートでエンコーダに入力される(700)。ビット率制御アルゴリズムは、ある特定フレームを符号化するかスキップするかを決定する(702)。あるフレームが符号化されることになると、その画像(ピクチャー)ヘッダーが最初に符号化される(704)。画像ヘッダーはまた、データ記憶部114に記憶保存される(708)。３つ以上の画像ヘッダーは同時に必要ではなく、すなわち、現在の画像(ピクチャー)からのヘッダーと、2つの前に符号化された画像からのヘッダーと、である。エンコーダは、GFIDがこの画像で(前の画像との比較において)変化されるかどうかを決定するが、この画像は現在の前画像の画像ヘッダーをベースとされている。もしも、前の画像のGFIDもまた、その画像のGFIDのものと異なるものであるなら(710)、前の画像の画像ヘッダーを追加的画質向上情報(ＳＥＩ)として反復する必要がある。またこれとは反対に、受信機器は、前の画像の画像ヘッダーを回復させることができ(712)、この前の画像は、現在の画像か前の画像に先立つ画像のいずれかのGFIDを使用する。最後に、画像の残りは符号化される(714)。そして、符号化ループは始めから続けられる。
【００６８】
反復されるピクチャー画像ヘッダーはPSCなしで反復されてよい。二者択一的に、ヘッダーは、システマティックなエラー修正コードにより処理操作されてもよい。システマティックなエラー修正コードとしては、ｋ第１シンボルは実際のメッセージであり、シンボルの残りはエラーのチェッキングに使用される。この特別な場合では、ｋ第１ビットは画像ヘッダーであり、ビットの残りは次のフレームに追加的画質向上情報(ＳＥＩ)として送信される。その結果として、エラー修正コードの選択は、どのくらいのビット反転エラーが探索されて修正されるか、そして、どのくらいの追加補足的ビットがエラー防護の供給に必要とされるかに、影響している。
【００６９】
上に示されるエンコーダ100の実施の形態において、そのエンコーダは、画像ヘッダーを反復送信するために前もってプログラムされている。しかしながら、エンコーダ100は、デコーダからのコマンドに応答して、画像データの反復動作またはリフレッシュ動作をするよう、追加的に調整配備が行われてもよい。
【００７０】
追加的なことまたは逆のこととして、エンコーダは、GFIDパラメータが状態をかえるたび毎に、反復画像ヘッダーを送出するよう、調整配備されてもよい。
【００７１】
端末２からの符号化されたビデオ画像データを受信する端末１を考慮するに、本発明にかかるビデオ画像コーデック１０の制御について、その復号化の役割を参照しながら、ここに記載される。端末１は、送信端末２からのマルチメディア信号を受信する。デマルチプレクサ５０は、マルチメディア信号の出力処理を行い、デマルチプレクス処理された信号を受信機器の正しい構成部材にパスを行うが、ここでたとえば、ビデオ画像コーデック１０への画像データ、オーディオ・コーディック２０へのオーディオデータ、H.245制御部４０へのH.245制御データになどがある。ビデオ画像コーデックのデコーダ200は、符号化されたビデオ画像データの復号化処理を行うが、このビデオ画像データは、逆(反転)量子化・逆DCT変換・データ補償動作によるものである。それから、復号化されたビデオ画像データは、受信端末１の表示部７０で表示再生のために出力される。
【００７２】
図４に示されるように、ビデオ画像コーデック10の復号化パート200は、可変長型デコーダ218、逆(反転)クアンタイザー(量子化手段)220、逆(反転)DCT変換部221、動作補償部222、画像(ピクチャー)保管部223、制御部224、一時画像データ記憶部228、スイッチ(230と232)を備えて構成されている。制御部224は、デマルチプレクサ５０により符号化されたマルチメディア・ストリームからデマルチプレクス処理のなされた、ビデオ画像コーデック制御信号を、受け取る。実際に、エンコーダ(符号化処理)の制御部105とデコーダ(復号化処理)の制御部224とは、同じプロセッサーであってもよい。
【００７３】
デコーダの制御部224は受信データの保全性のチェックを行う。画像(ピクチャー)ヘッダーでのエラーは、その画像(ピクチャー)が復号化されないこと、完全に失なわれたこと、または、改悪や破壊をされて効果的に失われたこと、を意味することもある。
【００７４】
今ここにデコーダの第１の実施の形態を示す。ノーマル制御では、デコーダ200は復号化されたデータを受信する。可変長デコーダ部(VLD)218は、元のフレーム構造を再生表示する試みをもって受信データの復号化を行うが、元のフレーム構造は図３に示されるようなフォーマットを有している。ここでいわば、VLD218は符号化されたデータを減圧処理し、そのとき制御部224は受信されたデータの中で画像(ピクチャー)スタート・コード(PSC)を探索する。そして、制御部224は、逆クオンタイザー220とスイッチ230とを制御するため、画像ヘッダー内の情報を使用する。PTYPE情報がINTRAフレームを表示するとき、スイッチ230は開かれ、逆DCTデバイス221の出力が画像記憶部230に入力される。また、PTYPE情報がINTERフレームを表示するとき、スイッチ230は閉じられ、画像記憶部223のコンテンツが、加算器234による逆DCTデバイス221(復号化された予測エラー)の出力に、加えられる。
【００７５】
デコーダが最初の画像(ピクチャー)ヘッダーを復号化することができなく、しかし、画像の他のセグメントを探索することができるのなら、そのとき、デコーダは、一時画像(ピクチャー)データ記憶部228にこのデータを記憶保管する。デコーダは、受信をして、復号化処理をして、反復ヘッダーデータを(そして最初のセグメントデータ82を)識別特定化するときには、そのデコーダは、画像の残りを再生するのに一時画像記憶部228を利用する。
【００７６】
このようにして、もしも、制御部224が、フレームの開始でPSCを探索しないで(または逆に、画像ヘッダーが改悪されることが決まり)、しかしセグメント・ヘッダーを探索する(例えば、GOB開始コードGBSCを探索することによる)としたら、制御部224がスイッチ232のステータス(状況)を変化させて、VLD218からのデータ出力が、一時画像データ記憶部228に入力される。このデータは、探索されたGBSCコードから開始されるが、VLDは画像(ピクチャー)の開始と同期化されるようにはできない。
【００７７】
図５を参照するに、デコーダは、フレーム510の第２セグメントのためのヘッダー84でGBSCを探知したものと、我々は推測できる。一時画像デコーダ記憶部228に記憶保管されたデータは、ヘッダー84、第２セグメントのためのヘッダー、第２セグメントのためのデータ、第３セグメントのためのヘッダー、フレーム510の第３セグメントなどのためのデータなどを備えている。
【００７８】
もし、失くなったか破損(改悪)されたかした画像(ピクチャー)ヘッダーが、INTRAフレームに所属するなら、デコーダによって受信された次のデータは、それゆえに、反復される画像ヘッダーと最初の第１セグメントデータ512とになる。デコーダは、反復画像ヘッダー80と第１データデータ82に関するデータ512を受け取る。制御部は、反復されたデータ512でPSCを探索し、ヘッダーでPTYPEフィールドを読み取り、クワンタイザー220が使われるように指導をして、INTRAフレームを表示するヘッダーでのPTYPEフィールドに応答して、スイッチ230を開く。反復された情報の残りは、逆クワンタイザー220とIDCT変換221とにより復号化されて、復号化され反復された第１画像(ピクチャー)セグメントは、IDCTから画像記憶部223に出力がなされる。
【００７９】
デコーダは以下のことを認識する。データはすべての画像(ピクチャー)のためのものではなく、すなわち、それは、連続フレームの画像ヘッダーによりフォローされた最初のセグメントのための画像データ82によりフォローされた画像ヘッダー80だけであり、例えて云えば、そのデコーダは、反復データ512を復号化して、それから、連続的開始コードが異なるフレーム(例えばフレーム520)のためにあることを探索する。デコーダによる探索に応答して、制御部224はスイッチ232の状態を変化させ、一時画像記憶部228に記憶保存されているフレーム510からのデータは、逆クアンタイザー220とIDCT変換221とに出力がなされる。その復号化されたデータは、現在の画像のための復号化されたデータの残りを伴なう、画像記憶保管コンテンツの更新で、画像記憶部223に出力される
【００８０】
上述してきたように、本発明によるデコーダの第１の実施の形態では、デコーダは、全画像のためのデータによりフォローされない画像(ピクチャー)ヘッダーの発生を探索することにより、反復画像ヘッダーの受け取りを探知する。（例えば、その画像のひとつのセグメントのためのデータによりフォローされたある画像であって、それ以上はない。）また、他の方法がヘッダー情報の反復を探査するのに用いられてもよい。
【００８１】
前に説明したように、もしデコーダがフレーム510を正確に復号化することができるならば、信号が図５に示すようにフォーマットされるときに、デコーダはヘッダー512の反復を単に放棄する。
【００８２】
図８は、本発明の第１の実施の形態にかかるデコーダを制御する方法を示すフローチャートである。始めに(400)、デコーダ200は、画像スタート・コード(PSC)が入力データにおいて次コードであるなら、チェッキングによる受信した信号の復号化を開始する。もし、画像ヘッダーが破損された(402)と推察されるなら、制御部は画像データを記憶保存するが、その画像データは、一時画像データ記憶部228にある画像の残存しているセグメントを伴なっている。
【００８３】
画像が破損されたかどうかを決定するには、種々の方法が用いられてよい。いくつか例証的な方法を示せば、デコーダがPSCを探索できないとき、または、エラー探索方法がエラーがあることを表示したとき、そして、好ましくないパラメーターが画像ヘッダー中に発見されたとき(例えば、画像ヘッダーの復号化タイプがINTRAであるとき、INTERフラグはセグメント・ヘッダー内に設定がなされる。)などが、挙げられる。
【００８４】
デコーダ200は、次のエラー無しのヘッダーを探す。このヘッダーがINTRAフレームのためであるときには、デコーダはフレームの復号化を試みる。画像セグメントのいくつかが無くなっていることが判明されたときには、前のフレームの対応するセグメントは一時画像記憶部228から読み込まれて復号化がなされる。紛失または破損された画像ヘッダーがINTRAフレームに属するものなら、デコーダにより受信された次のデータはそれゆえに反復画像ヘッダーと第１セグメントデータ512となる。デコーダは、画像ヘッダーと画像の第１セグメントのためのデータを復号化する(408)。デコーダは、そのデータがフレーム全体のためのものではないことを探索し(406)、そして応答として、デコーダは、反復画像ヘッダーのベースにある一時画像記憶部228に保存されたデータを復号化する(408)。
【００８５】
ノーマルなエラー隠蔽技術は、送信または復号化エラーから引き起こされた、画像(ピクチャー)内のエラーを隠すのに、使用される。復号化されたフレームがあまりに間違っているものと考えられるときには、従来のようにデコーダは最新情報の要求をエンコーダに送信してもよい。
【００８６】
従来のデコーダでは、データの不完全フレームを受信するにあたって、見つからないデータは通信中に紛失してしまったものと結論づけをする。このようにして、デコーダはINTRA画像(ピクチャー)リクエストを既知の方法で要求してもよい。また、本発明にかかるエンコーダは、本発明と不調和のデコーダをもって、動作することもできる。
【００８７】
本発明にかかるデコーダの第２の実施の形態を、ここに記載する。図６で示されるフォーマットされた信号を参照するに、デコーダがフレーム610の元のヘッダーを復号化することができないなら、そのデコーダは、一時画像記憶部228のフレームのための残存する画像データ(84,86)を、記憶保存する。そのフレームの第１セグメントは、それがデコーダで同一確認できないために、記憶保存されない。リダンダント・フレーム612が受信されたときには、デコーダは、無変化で符号化されたINTERであるとして、そのデータを読み取る。先行技術によるエンコーダは、この情報をいつも提供するようなことはない(明らかに100％リダンダントである)。本発明によるデコーダは、反復画像ヘッダーの受信を探索するが、無変化を表示するフィールドによってフォローされる、INTER画像ヘッダーの発生存在を検知するものである。そのようなデータを受け取るに当たっては、デコーダを形作るためにINTER画像ヘッダーを使用して、前のフレームからの情報(記憶部228で保存されていたもの)を、復号化する。
【００８８】
この実施の形態においては、画像(ピクチャー)の第１セグメントのためのデータは反復されずに、それゆえに失くなったものと考えられてもよい。そのデコーダは、反復されたヘッダーデータの受信において、スイッチ232にステータス変化を起こさせて、画像データのコンテンツが第２のセグメントからリフレッシュされるようにする。その代わりに、デコーダは、第１セグメント画像データが破損データで始まり、その箇所からデータの復号化を行う、との判断することができてもよい。例を挙げれば、元の画像の画像ヘッダーにひとつのビット反転エラーがあり、それゆえに画像は復号化されない、というようなことが我々には推測できる。しかしながら、PSCはなおも有効であり、フレームの開始はそれゆえに確実に探知がなされる。全画像610は一時画像記憶部228で保管され、反復ヘッダーが受信されるとき、デコーダ200がそのポジションにある保存データの復号化を開始して、そこの位置で、画像ヘッダーが終わり、第１セグメントのためのデータが始まるようになされる。
【００８９】
このようにして、デコーダは入力してくるデータを監視する。画像ヘッダーが失くなるか破損を受けたときは、フレームの残りのデータは一時画像記憶部228で保管される。連続するデータは復号化されて、そのデータがINTERフレームに関係し、また画像中に変化がないことを表示するときには、画像ヘッダーは復号化され、一時画像記憶部228からのデータが、リダンダント・フレームの画像ヘッダーでの情報を使用して、復号化がされる。
【００９０】
信号が図６に示したようにフォーマット化されるときに、デコーダがフレーム610の画像ヘッダーを正確に復号化させるなら、デコーダは継続してヘッダー612の反復を復号化する。図６を参照しながら次を記載するに、繰り返された情報612は、画像ヘッダー82(増分化されたＴＲを含み)とフィールド88とを備えていて、このフィールド88は、前の符号化されたフレームの見地からは、変化したデータはなにもないことを表示する。一時画像記憶部228に保管されたデータは何もないので、デコーダは、データ612のリダンダント・フレームを放棄して、連続するフレーム620を符号化させる。
【００９１】
本発明の第３の実施の形態による符号化された信号の受信において、本発明によるデコーダは、一時画像記憶部228に保管されたデータを復号化するため、連続するフレームでの追加的画質向上情報(ＳＥＩ)のFTYPE/DSIZEオクテットをフォローするデータを使用する。
【００９２】
デコーダの第３の実施の形態は、図９を参照しながら記載される。この実施の形態は、エンコーダ(符号化装置)と図７とを参照するに、前に述べたようなＳＥＩ方法を利用するものである。
【００９３】
デコーダは、次のように制御動作を行う。始めに(900)、デコーダは、次に送信された画像(ピクチャー)の画像ヘッダーを受信する。そのヘッダーにエラーがないなら、デコーダは問題なしにそのヘッダーを復号化する(902)。それから、画像の残りの復号化を続ける(904)。画像ヘッダーにいくつかエラーが探知された(901)ときには、デコーダは、第一のエラー無し画像セグメント(GOBまたはスライス)ヘッダーをサーチする。このビット・ストリーム・ポジションを、第一再同期位置とよんでいい。ヘッダーのGFIDが、前の画像で同じであるなら(908)、デコーダは画像ヘッダーの重要なパーツを回復させて、復号化動作を継続させて、特定の画像セグメントから開始させる。GFIDが前の画像のそれと相違するとき、そのデコーダは次の画像開始コードをサーチする。あの画像の画像レイヤデータがＳＥＩ画像ヘッダー反復を含むなら、デコーダは、現在画像の画像ヘッダーを回復させることができる(916)。それはまた、最初の再同期化位置に戻る、ビット・ストリームでの復号化位置を、設定させることとなる。
【００９４】
画像(ピクチャー)レイヤデータがSEI画像ヘッダー反復を含んでいないなら、デコーダは次のセグメント開始コードの探知を行い、そして、ヘッダーでのGFIDが復号化がなされた画像のGFIDと同じであるかをチェックする(920)。GFIDが同じであったら、デコーダは画像ヘッダーを回復させて(910)、最初の再同期ポジションからの復号化を継続する。GFIDが互いに違つていたら、デコーダは、破損された画像ヘッダーを回復させる手段は持たない。この場合では(922)、INTRA更新を要求できる。
【００９５】
一時画像記憶部は、複数フレームのための符号化されたデータを記憶保管してよい。低ビット率アプリケーションでのほとんどのフレームは、INTERフレーム方式でコード化されて、一時画像記憶部に保存されているデータのほとんどは予測エラーデータを表示してもよく、またそれゆえに、比較的コンパクトである。一時画像記憶部は、データの保存が十分可能にして設計がなされるへきであって、少なくとも、INTRAフレーム１枚とデータINTERフレーム１枚、また、INTERフレームで符号化されたもので、28.8kbpsでQCIF画像のための約250バイトのもの、などが良い。
【００９６】
ビデオ画像の連続するフレームのためのデータが、一時画像(ピクチャー)記憶部228にも保存されているときに、これらは復号化もなされて画像記憶部223に出力され、画像記憶部223のコンテンツをアラインメント(配列調整)させ、また、通信デバイスの対応する画像記憶部のコンテンツを備えている。
【図面の簡単な説明】
【図１】  マルチメディア移動通信コミュニケーション・システムの一例を示す。
【図２】  マルチメディア端末のマルチメディア構成要素の一例を示す。
【図３】  H.263に従って符号化されたビデオ画像信号の代表的なデータ構造の一例を示す。
【図４】  本発明によるビデオ画像コーデックの一例を示す。
【図５】  本発明の第１の実施の形態によるエンコーダにより符号化されたビデオ画像信号出力のデータ構造の例を示す。
【図６】  本発明の第２の実施の形態によるエンコーダにより符号化されたビデオ画像信号出力のデータ構造の例を示す。
【図７】  本発明の第３の実施の形態によるビデオ画像エンコーダの処理を示すフロー図である。
【図８】  本発明の第１の実施の形態によるビデオ画像デコーダの処理を示すフロー図である。
【図９】  本発明の第３の実施の形態によるビデオ画像デコーダの処理を示すフロー図である。
【図１】
0004969003.tif 000002
【図２】
0004969003.tif 000003
【図３】
0004969003.tif 000004
【図４】
0004969003.tif 000005
【図５】
0004969003.tif 000006
【図６】
0004969003.tif 000007
【図７】
0004969003.tif 000008
【図８】
0004969003.tif 000009
【図９】
0004969003.tif 000010