(57)【要約】【課題】  パケットロスなどがあっても、より自然に、動画像を画面表示できるようにする。【解決手段】  動画像に関する情報の画面表示を行うための映像単位信号（フレーム）を出力する映像出力装置に関する。そして、（１）受け取った復号結果に基づいて復号単位信号を生成する復号単位信号生成手段と、（２）生成された復号単位信号を、参照用復号単位信号として一時的に格納する一時格納手段と、（３）当該参照用単位信号の後に復号単位信号生成手段によって生成された復号単位信号である出力候補復号単位信号を、その構成要素ブロック毎に、参照用復号単位信号と比較することで、各構成要素ブロックが正しく復号されたか否かを検査し、その検査結果に応じて、各出力候補復号単位信号を、映像単位信号として出力するか否かを決定する出力候補処理手段とを備える。【選択図】  図３
2007097211.tif 000002
【特許請求の範囲】
【請求項１】
動画像に関する情報の画面表示を行うための映像単位信号を出力する映像出力装置において、
受け取った復号結果に基づいて復号単位信号を生成する復号単位信号生成手段と、
当該復号単位信号生成手段が生成した復号単位信号を、参照用復号単位信号として一時的に格納する一時格納手段と、
当該参照用単位信号のあとに前記復号単位信号生成手段によって生成された復号単位信号である出力候補復号単位信号を、当該出力候補復号単位信号の構成要素ブロック毎に前記参照用復号単位信号と比較することで、各構成要素ブロックが正しく復号されたか否かを検査し、その検査結果に応じて、各出力候補復号単位信号を、前記映像単位信号として出力するか否かを決定する出力候補処理手段とを備えることを特徴とする映像出力装置。
【請求項２】
請求項１の映像出力装置において、
前記映像単位信号を出力できない状態が継続している期間、当該映像出力装置の動作状況を画面表示するための代替単位信号を出力する代替単位信号生成手段を備えることを特徴とする映像出力装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画像受信装置と共に使用し得る映像出力装置に関するものである。
【背景技術】
【０００２】
一般に、動画像を符号化して生成されるビットストリームには、動画像全体の符号化形式を記述するストリームヘッダーと、各フレームの符号化形式を記述するフレームヘッダー、あるいはフレームを１つ又は複数のパケットに分割して符号化した場合のパケットの符号化形式を記述するパケットヘッダーなど、各種のヘッダー情報が埋め込まれており、復号側ではこれらのヘッダー情報を解析して、データストリームの復号処理を実行する（特許文献１参照）。ストリームヘッダーには、画像のサイズや全体の符号化タイプなどの基本的な情報（ヘッダ情報）が含まれており、ビットストリームデータの先頭に埋め込まれる場合や、データとは別の通信路で伝送される場合がある。また、ストリームの途中から復号が可能となるように、適当な間隔でビットストリームに挿入する場合もある。
【０００３】
フレームヘッダーは、画像の各フレームの先頭に埋め込まれ、フレームの予測方式や画質パラメータ等の各フレームの符号化に関する情報が含まれており、含まれる内容はストリームヘッダーのヘッダ情報に依存する。
【０００４】
パケットヘッダーは、フレームを分割した際の先頭ブロック番号や、以前のパケットが欠落した場合でも復号できるようにフレームヘッダーに類する情報が含まれている。
【０００５】
なお、パケット分割符号化ではフレームヘッダーをパケットヘッダーの一種として取り扱うことが可能である。
【０００６】
復号側の処理は、まず、ストリームの先頭にあるストリームヘッダーを解析し、その解析結果に基づきパケットヘッダーの解析を行い、パケットデータの復号を行う。また、放送のような既に流れているストリームの途中から復号を行う場合は、予め別のチャンネルでストリームヘッダーに相当する情報を受信しておくか、挿入されているストリームヘッダーを受信してから、パケットヘッダーの解析及びパケットデータの復号を行う。
【０００７】
また、伝送中のパケットのロスなどによってフレームの一部が欠落した場合は、周辺の欠落していない情報を用いて欠落した部分を補完することにより、映像の復号及び表示を継続する手法や、次のイントラフレームを受信するまで、直前のフレームを表示し続けることにより乱れた映像を表示しない手法などが用いられている。
【特許文献１】特開平１１−３１３６２号公報
【発明の開示】
【発明が解決しようとする課題】
【０００８】
しかしながら、以上に述べた方法では、先頭のストリームヘッダーを受信できなかった場合に、次に挿入されたストリームヘッダーを受信するまで復号を開始できないという問題点がある。
【０００９】
また、途中にストリームヘッダーを挿入した場合、少なくともストリームヘッダーの直後の１フレームは、他のフレームを参照しないイントラフレームとして符号化する必要がある。途中から受信しはじめた視聴者（ユーザ）の受信装置は、それ以前のフレームのデータを蓄積していないため、インターフレームを処理することができないからである。
【００１０】
しかしながら、イントラフレームを使用すると、符号量が増大し画質が低下するという問題が生じるため、頻繁にストリームヘッダーを挿入することは好ましくない。
【００１１】
特に、リアルタイム性を重視するアプリケーションでは、イントラフレームの挿入は遅延の原因となるため、最初のフレーム以外にはイントラフレームを挿入しない場合もあり、最初のストリームヘッダーを受信できなかったり、途中からストリームを受信する場合に、正常に復号を行うことができないという問題点があった。
【００１２】
さらに、伝送中にパケットロスが発生する環境下において、十分な補完処理が行えない場合は、乱れた映像や同じフレームが継続して表示（不自然な静止画が表示）されるといった、視聴者の好まざる映像が出力されるという問題点もあった。
【課題を解決するための手段】
【００１３】
かかる課題を解決するために、本発明では、動画像に関する情報の画面表示を行うための映像単位信号を出力する映像出力装置において、（１）受け取った復号結果に基づいて復号単位信号を生成する復号単位信号生成手段と、（２）当該復号単位信号生成手段が生成した復号単位信号を、参照用復号単位信号として一時的に格納する一時格納手段と、（３）当該参照用単位信号のあとに前記復号単位信号生成手段によって生成された復号単位信号である出力候補復号単位信号を、当該出力候補復号単位信号の構成要素ブロック毎に前記参照用復号単位信号と比較することで、各構成要素ブロックが正しく復号されたか否かを検査し、その検査結果に応じて、各出力候補復号単位信号を、前記映像単位信号として出力するか否かを決定する出力候補処理手段とを備えることを特徴とする。
【発明の効果】
【００１４】
以上に説明したように、本発明によれば、より自然に、動画像を画面表示することができる。
【発明を実施するための最良の形態】
【００１５】
（Ａ）第１の実施形態
以下、本発明の第１の実施形態について説明する。
【００１６】
（Ａ−１）第１の実施形態の構成及び各部の動作
第１の実施形態に係る映像出力装置を含む受信装置１０の構成を図１に示す。
【００１７】
図１において、この受信装置１０は、ヘッダー判定手段１１と、ストリームヘッダー解析手段２１と、ストリームヘッダー情報保持手段２２と、ストリームヘッダー推定手段２３と、パケットヘッダー解析手段３１と、パケットヘッダー解析エラー判定手段３２と、パケットデータ復号手段４１と、パケットデータ復号エラー判定手段４２と、入力端子１と、出力端子２とを備えている。
【００１８】
このうち入力端子１に供給される入力ストリームｓ１は、図５（Ｂ）のような構造を備えているものとする。
【００１９】
図５（Ｂ）において、例えばパケットヘッダーＰＨＭ（ここで、Ｍは自然数）とパケットデータＰＤＭによって１つのパケットＰＭが構成されている。
【００２０】
同様に、パケットヘッダーＰＨＭ＋１とパケットデータＰＤＭ＋１によってパケットＰＭ＋１が構成され、パケットヘッダーＰＨＭ＋２とパケットデータＰＤＭ＋２によってパケットＰＭ＋２が構成され、…、パケットヘッダーＰＨＭ＋８とパケットデータＰＤＭ＋８によってパケットＰＭ＋８が構成されている。
【００２１】
そして、パケットッＰＭ＋１とパケットＰＭ＋２とパケットＰＭ＋３がフレーム（画面表示単位）ＦＬに対応し、パケットＰＭ＋４とパケットＰＭ＋５がフレームＦＬ＋１に対応し、パケットＰＭ＋６がフレームＦＬ＋２に対応するというように、１又は複数のパケットが１つのフレームに対応する。ここで、Ｌは自然数である。
【００２２】
また、この入力ストリームｓ１のなかには、パケットＰＭ＋３とパケットＰＭ＋４の間に挿入されているストリームヘッダーＳＨＫ（ここで、Ｋは自然数）のように、ストリームヘッダーが間欠的に複数挿入されている。
【００２３】
仮に、入力ストリームｓ１の送信装置（図示せず）と当該受信装置１０とが予めハンドシェークした上で当該送信装置が入力ストリームｓ１の送信を開始するシステム構成ならば、例えば、図５（Ａ）に示すように、ストリームヘッダーは、入力ストリームｓ１の最初に１回だけ送信すれば十分であるが、例えば、放送のように、各ユーザがどの時点から視聴しはじめるかが不明である場合には、図５（Ｂ）のようにストリームヘッダーを間欠的に複数回送信する必要がある。
【００２４】
なお、前記パケットヘッダーＰＨＭ、ＰＨＭ＋４、ＰＨＭ＋７などは、パケットヘッダーであると同時に、各フレームの先頭に位置するフレームヘッダーＦＨＬ、ＦＨＬ＋１、ＦＨＬ＋３でもある。また、図５（Ｂ）においては、左側ほど時間的に早く、右側ほど時間的に遅い。
【００２５】
入力ストリームｓ１を、入力端子１を介して受信するヘッダー判定手段１１は、受信した入力ストリームｓ１のなかからストリームヘッダー（例えば、前記ストリームヘッダーＳＨＫ）と、パケットヘッダー（例えば、前記パケットヘッダーＰＨＭ）と、パケットデータ（例えば、前記パケットデータＰＤＭ）とを識別して取り出し、それぞれ別の出力先へ供給する部分である。
【００２６】
すなわち、当該ストリームヘッダーは、ストリームヘッダー信号ｓ１２としてストリームヘッダー解析手段２１へ供給され、パケットヘッダーは、パケットヘッダー信号ｓ１３としてパケットヘッダー解析手段３１へ供給され、パケットデータは、パケットデータ信号ｓ１４としてパケットデータ復号手段４１へ供給される。
【００２７】
ストリームヘッダー解析手段２１に供給するストリームヘッダーの構造は、図６（Ａ）に示す通りである。
【００２８】
図６（Ａ）において、スタートコードＳは、ここからストリームヘッダーが始まることを示す所定ビットパターンのフィールドであり、当該スタートコードＳ以降には、「情報１」、「情報２」、「情報３」などの各情報フィールドが配置されている。
【００２９】
情報フィールドのなかには、パケットデータの復号にとって重要な情報を収容しているフィールドもあり、それほど重要でない情報（例えば、当該ストリームヘッダーが送信装置において生成された時刻を示すタイムスタンプなど）を収容しているフィールドもある。
【００３０】
復号にとって重要な情報を収容しているフィールドの例としては、図示した符号化タイプＣＴや画像サイズＶＳなどがある。
【００３１】
このうち、符号化タイプＣＴは、例えば、パケットデータを符号化する際に用いたハフマン符号などの符号化方式を特定する部分であり、画像サイズＶＳは、復号後に画面表示される画像のサイズ（例えば、６４０×４８０画素のＶＧＡ、３５２×２８８画素のＣＩＦなど）を特定する部分である。
【００３２】
ストリームヘッダー解析手段２１は、ストリームヘッダーを解析してこのような各情報フィールドの持つ情報を解析し、解析結果として得られたストリームヘッダー情報ｓ２１をストリームヘッダー情報保持手段２２に格納する部分である。
【００３３】
使用される可能性のあるストリームヘッダー情報（これは、スタートコードＳを除く、ストリームヘッダーの全フィールドのビットパターンに対応する）ｓ２のパターンは、原理的には、２の当該全フィールドのビット数乗（例えば、当該全フィールドのビット数が１６ビットであれば６５５３６（＝２１６））にのぼり、数万通り以上の膨大な数となるが、現実的には、例えば画像サイズなら、前記ＶＧＡやＣＩＦなど一般的に受け入れられている特定のサイズだけが使用され、一般的に受け入れられていないその中間のサイズが使用されることは希である。この点は、符号化タイプＣＴなどに関しても同様である。
【００３４】
従って、現実的に使用される可能性が高いストリームヘッダー情報ｓ２のパターンは、例えば、１００通り程度に限定することが可能であると考えられる。
【００３５】
このため、何らかの予備的な情報があれば、実際にストリームヘッダーを受信する前でも、この１００通り程度をさらに絞り込むことができ、ストリームヘッダーの内容をある程度の確かさで推定することが可能である。
【００３６】
初期状態のストリームヘッダー推定手段２３には、このようにして入力ストリームｓ１の受信前に推定されたストリームヘッダー情報の初期値が格納されている。
【００３７】
ストリームヘッダー推定手段２３は、当初は、この初期値を、ストリームヘッダー推定情報ｓ２３としてストリームヘッダー情報保持手段２２に格納する。
【００３８】
ストリームヘッダー情報保持手段２２は、ストリームヘッダー解析手段２１からのストリームヘッダー情報ｓ２１の格納要求とストリームヘッダー推定手段２３からのストリームヘッダー推定情報ｓ２３の格納要求が同時に発生（競合）した場合、ストリームヘッダー情報ｓ２１の方を優先して格納し、ストリームヘッダー情報ｓ２１の格納要求がない場合にだけストリームヘッダー推定情報ｓ２３を格納し得る（競合制御）。推定値よりも、実際にストリームヘッダーを解析して得られた解析値の方が、はるかに信頼性が高いのが普通だからである。
【００３９】
このようなストリームヘッダー情報保持手段２２による競合制御の内容は、初期時以降においても同様である。
【００４０】
ストリームヘッダー情報保持手段２２が同時に格納することができる情報（格納情報）は、ストリームヘッダー情報ｓ２１かストリームヘッダー推定情報ｓ２３のいずれか１つだけであり、当該１つの格納情報がストリームヘッダー情報ｓ２２としてパケットヘッダー解析手段３１に供給される。
【００４１】
パケットヘッダー解析手段３１は、ストリームヘッダー情報保持手段２２からのストリームヘッダー情報ｓ２２に基づいて、ヘッダー判定手段１１から受け取ったパケットヘッダーｓ１３を解析し、当該解析結果であるパケットヘッダー解析情報ｓ３１をパケットヘッダー解析エラー判定手段３２に供給する部分である。
【００４２】
ここで、パケットヘッダーｓ１３のなかには、上述したようにフレームヘッダーも含まれている。従って、パケットヘッダー解析手段３１は、フレームヘッダー（例えば、前記フレームヘッダーＦＨＬ）の解析も行い、解析結果であるパケットヘッダー解析情報ｓ３１には、フレームヘッダーの解析情報も含まれている。
【００４３】
フレームヘッダーの構造を、図６（Ｂ）、（Ｃ）に示す。
【００４４】
図６（Ａ）に示すストリームヘッダーが収容している符号化タイプＣＴが、例えば、ある符号化タイプ「Ａ」を示す場合、フレームヘッダーの構造は図６（Ｂ）となり、当該符号化タイプＣＴが、例えば、符号化タイプ「Ｂ」を示す場合、フレームヘッダーの構造は図６（Ｃ）となるものとする。
【００４５】
図６（Ｂ）において、スタートコードＦは、上述のスタートコードＳと同様に、ここからフレームヘッダーが始まることを示す所定ビットパターンのフィールドであり、当該スタートコードＦ以降には、「情報Ａ１」、「情報Ａ２」、「情報Ａ３」などの各情報フィールドが配置されている。図中、所定位置に配置されたマーカービットＭＢ１は、値が常に１になるビットである。
【００４６】
同様に、図６（Ｃ）においても、スタートコードＦは、ここからフレームヘッダーが始まることを示す所定ビットパターンのフィールドであり、当該スタートコードＦ以降には、「情報Ｂ１」、「情報Ｂ２」、「情報Ｂ３」、「情報Ｂ４」などの各情報フィールドが配置されている。また、マーカービットＭＢ２は、上述のマーカービットＭＢ１と同様に、値が常に１になるビットであるが、マーカービットＭＢ１とは配置された位置が異なる。
【００４７】
このような解析情報を含んだパケットヘッダー解析情報ｓ３１を受け取るパケットヘッダー解析エラー判定手段３２は、マーカービットＭＢ１、ＭＢ２や、各情報フィールド（例えば、「情報Ａ１」フィールドなど）の外形的な正当性に着目して、パケットヘッダー解析手段３１による解析にエラーがなかったかどうかを判定する部分である。すなわち、このパケットヘッダー解析エラー判定手段３２は、ストリームヘッダー情報ｓ２２とパケットヘッダーｓ１３が整合しているかどうかを判定する。
【００４８】
仮に、ストリームヘッダー情報ｓ２２が指定する符号化タイプＣＴが「Ａ」で、パケットヘッダーｓ１３によって供給されるパケットヘッダーが図６（Ｂ）のパケットヘッダーであれば、両者は整合しており、所定のマーカービットＭＢ１は１になるはずである。また、両者が整合していれば、「情報Ａ１」フィールドなどのサイズも予め設定された正常な値に一致するはずである。
【００４９】
ところが、ストリームヘッダー情報ｓ２２が指定する符号化タイプＣＴが「Ａ」であるのに、パケットヘッダーｓ１３によって供給されるパケットヘッダーが図６（Ｃ）のパケットヘッダーであれば、両者は整合しておらず、所定のマーカービットＭＢ１は１にならない可能性がある。但し、マーカービットだけを基準としたのでは、両者が整合していなくても、マーカービットＭＢ１と同じ位置のビットが、偶然、１に一致してしまう可能性もあるので、各フィールドのサイズなども基準として、パケットヘッダー解析エラー判定手段３２の判定の信頼性を高める。
【００５０】
パケットヘッダー解析エラー判定手段３２の判定では、整合していないのに整合していると誤判定する可能性を完全に０にすることは困難であるが、伝送誤りでも発生しない限り、整合しているのに整合していないと誤判定することはあり得ない。
【００５１】
このようにして判定した結果、解析エラーがある（すなわち、ストリームヘッダーｓ２２とパケットヘッダーｓ１３が整合していない）と判定した場合、当該パケットヘッダー解析エラー判定手段３２は、パケットヘッダーエラー情報ｓ３３をストリームヘッダー推定手段２３に供給して、推定値の変更を指示する。これに応じて、ストリームヘッダー推定手段２３は、適応的に推定値を変更する。
【００５２】
これに対して、解析エラーがない（すなわち、ストリームヘッダーｓ２２とパケットヘッダーｓ１３が整合している）と判定した場合、パケットヘッダー解析エラー判定手段３２は、パケットヘッダー情報ｓ３２をパケットデータ復号手段４１に供給する。このパケットヘッダー情報ｓ３２は、パケットヘッダー解析情報ｓ３１から抽出した復号に必要な情報によって構成されている。
【００５３】
なお、パケットヘッダー解析エラー判定手段３２は、単に推定値の変更を指示するだけではなく、解析エラーの状態に基づいて、どのように推定値を変更するかを具体的に指示するようにしても良い。解析エラーの状態を分析すれば、前記推定値の候補（推定値候補）をある程度絞り込んで、正しい推定値を得られる傾向を高めることは可能であると考えられるからである。
【００５４】
一例として、映像符号化では、１６×１６画素のブロック単位で処理することが多いため、符号化されたブロック数から逆算して正しい画像サイズＶＳを絞り込むことができ、ブロック数は、パケットヘッダーやパケットデータの復号結果から得られる可能性が高い。正しい画像サイズＶＳが決定できれば、前記推定値を絞り込むことができる。
【００５５】
パケットデータ復号手段４１は、パケットヘッダー情報ｓ３２に基づいてパケットデータｓ１４を復号し、復号結果をパケットデータ復号情報ｓ４１としてパケットデータ復号エラー判定手段４２に供給する部分である。
【００５６】
パケットデータ復号エラー判定手段４２は、例えば、復号テーブルに存在しないデータの出現や、規定数を上回るデータの復号等の一般的な方法を用いて、パケットデータ復号情報ｓ４１に復号エラーがないかどうかを判定する部分である。この復号エラーは、パケットヘッダー情報ｓ３２とパケットデータｓ１４が整合していない場合に発生する。従って、当該パケットデータ復号エラー判定手段４２は、パケットヘッダー情報ｓ３２とパケットデータｓ１４が整合しているかどうかを検査することになる。
【００５７】
そして、復号エラーがあると判定した場合、パケットデータ復号エラー判定手段４２は、パケットデータエラー情報ｓ４３を、ストリームヘッダー推定手段２３に供給して、推定値の変更を指示する。これに応じて、ストリームヘッダー推定手段２３は、適応的に推定値を変更する。
【００５８】
なお、単に推定値の変更を指示するだけでなく、解析エラーの場合と同様に、復号エラーの状態に基づいて、どのように推定値を変更するかを具体的に指示するようにしても良い。復号エラーの状態を分析すれば、解析エラーの場合よりも高精度に、推定値候補を絞り込むことが可能であると考えられるからである。
【００５９】
パケットヘッダー解析エラー判定手段３２に重ねて、類似の処理をこのパケットデータ復号エラー判定手段４２でも行うのは、パケットヘッダー解析エラー判定手段３２における処理が復号前のもので、マーカービット（ＭＢ１など）や情報フィールド（「情報Ａ１」フィールドなど）のサイズ等の外形的な正当性に基づいて行われ、その判定の信頼性は確率に依存したものとなり、必ずしも十分に高いものではないのに対し、パケットデータ復号エラー判定手段４２の判定は、復号後に情報の内実に着目して行われるので、その判定の信頼性は、通常、パケットヘッダー解析エラー判定手段３２の判定よりも高いからである。
【００６０】
すなわち、このパケットデータ復号エラー判定手段４２の判定でも、パケットヘッダー解析エラー判定手段３２の判定と同様に、伝送誤りでも発生しない限り、整合しているのに整合していないと誤判定することはあり得ないが、整合していないのに整合していると誤判定する可能性は、パケットヘッダー解析エラー判定手段３２よりもはるかに低い。
【００６１】
しかも、ストリームヘッダー推定手段２３は、パケットヘッダーエラー情報ｓ３３又はパケットデータエラー情報ｓ４３のいずれか一方が供給されただけでも格納している推定値を変更するので、異なる判定基準に基づいて、パケットヘッダー解析エラー判定手段３２とパケットデータ復号エラー判定手段４２においてエラー判定を行う意義は大きい。
【００６２】
なお、復号エラーがないと判定した場合に、パケットデータ復号エラー判定手段４２は、復号パケットデータｓ４２を出力端子２から送出する。この復号パケットデータｓ４２は、パケットデータ復号情報ｓ４１に対応したものである。
【００６３】
（Ａ−２）第１の実施形態の全体動作
以下、以上のような構成を有する第１の実施形態の受信装置１０における動作について説明する。
【００６４】
受信装置１０が、放送に対応する図５（Ｂ）の入力ストリームｓ１を、図５（Ｂ）の受信タイミングＴ１の時点から受信し始めるものとする。
【００６５】
入力ストリームｓ１が入力される前に、受信装置１０の内部では、ストリームヘッダー推定手段２３が一般的な初期値となるストリームヘッダーの情報を推定し、ストリームヘッダー推定情報ｓ２３として出力している。
【００６６】
次に、受信装置１０による受信が開始されると、入力ストリームｓ１がヘッダー判定手段１１に入力され、ヘッダー判定手段１１ではストリームヘッダーかパケットヘッダーかを判定してストリームヘッダーｓ１２又はパケットヘッダーｓ１３を出力する。
【００６７】
受信タイミングＴ１は、パケットデータＰＤＭに一致しているために、最初にヘッダー判定手段１１に入力されるのは、パケットデータＰＤＭであるが、この時点ではまだ、パケットヘッダー情報ｓ３２が供給されていないから、パケットデータ復号手段４１は、パケットデータＰＤＭを有効に復号することはできない。
【００６８】
また、受信タイミングＴ１にはストリームヘッダーが存在しないため、ストリームヘッダー解析手段２１はストリームヘッダー情報ｓ２１の出力を行わない。従って、ストリームヘッダー情報保持手段２２には、ストリームヘッダー推定情報ｓ２３の初期値が格納される。
【００６９】
この後、図５（Ｂ）のパケットデータＰＤＭに続くパケットヘッダーＰＨＭ＋１（すなわちフレームヘッダーＦＨＬ）が入力されると、ヘッダー判定手段１１は、このパケットヘッダーＰＨＭ＋１をパケットヘッダー解析手段３１に供給する。
【００７０】
パケットヘッダー解析手段３１はストリームヘッダー情報保持手段２２に格納されているストリームヘッダー情報ｓ２２をもとに、入力されたパケットヘッダーｓ３１を解析してパケットヘッダー解析情報ｓ３１を出力し、パケットヘッダー解析エラー判定手段３２は、解析エラーの判定を実行する。
【００７１】
ストリームヘッダー推定情報ｓ２３の初期値が正しければ、解析エラーはないと判定され、この初期値が維持される可能性が高いが、初期値が正しくなければ、解析エラーがあると判定され、パケットヘッダーエラー情報ｓ３３によってこの初期値が変更される可能性が高い。
【００７２】
解析エラーがないと判定された場合には、パケットヘッダー情報ｓ３２が出力されるので、このパケットヘッダーＰＨＭ＋１に続くパケットデータＰＤＭ＋１が、パケットデータ復号手段４１において復号される。
【００７３】
ストリームヘッダー推定情報ｓ２３の初期値が正しければ、復号エラーはないと判定され、この初期値が維持される可能性が高いが、初期値が正しくなければ、復号エラーがあると判定され、パケットデータエラー情報ｓ４３によって、この初期値が変更される可能性が高い。
【００７４】
パケットＰＭ＋１に続く、パケットＰＭ＋２やパケットＰＭ＋３に関しても同様な処理が繰り返されるので、初期値が正しくない場合でも、ストリームヘッダー推定情報ｓ２３の信頼性は徐々に向上して行き、正しい推定値が得られる可能性も高い。
【００７５】
そして、パケットＰＭ＋３の次に挿入されているストリームヘッダーＳＨＫが入力されると、ヘッダー判定手段１１がこのストリームヘッダーＳＨＫを、ストリームヘッダー解析手段２１に供給し、ストリームヘッダーの解析が初めて実行される。この解析結果として得られる解析値は、ストリームヘッダー情報ｓ２１として、優先的にストリームヘッダー情報保持手段２２に格納される。この解析値の格納によって、ストリームヘッダー情報保持手段２２上から、ストリームヘッダー推定情報ｓ２３は失われる。
【００７６】
解析値がストリームヘッダー情報保持手段２２に格納された後、通常、パケットヘッダー解析エラー判定手段３２からパケットヘッダーエラー情報ｓ３３が出力されることはなく、パケットデータ復号エラー判定手段４２からパケットデータエラー情報ｓ４３が出力されることもない。
【００７７】
解析値がストリームヘッダー情報保持手段２２に格納された後でパケットヘッダーエラー情報ｓ３３やパケットデータエラー情報Ｓ４３が出力されるのは、伝送誤りが発生した場合などの極めて希なケースに限られるから、当該解析値がストリームヘッダー情報保持手段２２に格納されてから後は、パケットヘッダー解析エラー判定手段３２は解析エラーの判定を行わず、パケットデータ復号エラー判定手段４２も復号エラーの判定を行わないようにし、パケットヘッダー情報ｓ３２や復号パケットデータｓ４２の出力だけを行うようにしても良い。
【００７８】
但し、この場合には、解析値自体が伝送誤りの影響を受けていることもあり得るので、正常な動画像が視聴できないと感じたユーザの指示があった場合にだけ、パケットヘッダー解析エラー判定手段３２が解析エラーの判定を再開すると共に、パケットデータ復号エラー判定手段４２も復号エラーの判定を再開するようにしても良い。
【００７９】
なお、以上の説明では、ストリームヘッダー（ＳＨＫなど）は、入力ストリームｓ１に間欠的に挿入されているため、入力ストリームｓ１の受信を継続すれば必ずいつかは、実際にストリームヘッダーを受信できて、解析値が得られるが、第１の実施形態はこのような入力ストリームに対してだけ適用できるものではない。
【００８０】
例えば、図５（Ａ）のような構造の入力ストリームを途中から受信する場合にも、第１の実施形態は有効である。
【００８１】
従来は、図５（Ａ）のように最初にだけストリームヘッダー（ＳＨ）が配置されている入力ストリームを途中から受信した場合、まったく正常な復号を行うことは不可能であったが、第１の実施形態の受信装置１０によれば、このようなケースでも正常な復号を行うことが可能である。第１の実施形態の推定値（ストリームヘッダー推定情報ｓ２３）の信頼性は、パケットヘッダー（フレームヘッダー）の処理を繰り返すほど向上し、最終的には正しい値に到達することが可能だからである。
【００８２】
（Ａ−３）第１の実施形態の効果
以上のように、第１の実施形態によれば、ストリームヘッダー（ＳＨＫなど）が間欠的に挿入された入力ストリームを受信する場合、ストリームヘッダーを受信して解析値が得られる前の時点から、正常な復号を行うことができ、受信開始後ただちに動画像を画面表示することが可能で、使い勝手が良く、信頼性の高い受信装置を提供することができる。
【００８３】
また、第１の実施形態によれば、ストリームヘッダーが最初にだけ配置された図５（Ａ）のような入力ストリームを、途中から受信する場合でも、正常な復号を行うことができ、動画像を画面表示することが可能であるため、高性能で汎用性が高い。
【００８４】
さらに、第１の実施形態では、ストリームヘッダー自体を受信できなくても正常な復号を行うことが可能で、放送のように既に流れているストリームの途中から復号を行う場合でも、従来のように、ストリームヘッダーに相当する情報を別のチャネルで受信しておく必要性が低いため、伝送路を小規模化し簡略化することができ、送信装置側の出力回路や受信装置（１０）の入力回路をハードウエア的に小規模化することも可能である。
【００８５】
（Ｂ）第２の実施形態
以下では、第２の実施形態が第１の実施形態と相違する点についてのみ説明する。
【００８６】
（Ｂ−１）第２の実施形態の構成及び動作
この第２の実施形態に係る受信装置２０の構成を図２に示す。
【００８７】
図２において、図１と同じ符号を付した各部１，２，２１，２２，２３，３１，３２，４１の機能は、第１の実施形態と同じである。従って、パケットデータ復号エラー判定手段６２とヘッダー判定手段６１に関連する部分だけが、第１の実施形態と相違する。
【００８８】
パケットデータ復号エラー判定手段６２は、第１の実施形態のパケットデータ復号エラー判定手段４２と同じ機能を備えているが、そのほかに、ストリーム再復号指示信号ｓ６４を出力する機能を装備している。
【００８９】
図２のパケット復号手段４１で復号されたパケットデータ復号情報ｓ４１に前記復号エラーが含まれている場合、パケットデータ復号エラー判定手段６２からは、パケットデータエラー情報ｓ４３をストリームヘッダー推定手段２３に出力して新しいストリームヘッダーを推定すると同時に、ストリーム再復号指示信号ｓ６４をヘッダー判定手段６１に出力し、再度入力ストリームｓ１の復号処理を実行させる。
【００９０】
例えば、図５（Ｂ）のパケットデータＰＤＭ＋３の復号で、復号エラーがあると判定された場合、当該パケットデータＰＤＭ＋３は、所定の繰り返し条件が満足されるまで複数回復号されることになる。
【００９１】
繰り返し条件の内容としては、例えば、復号エラーがないと判定されるまでという条件を設定しても良いし、具体的な回数を設定するようにしても良い。
【００９２】
回数を設定した場合、その数だけ得られたパケットデータ復号情報ｓ４１のなかで、最も復号エラーの程度が軽微なパケットデータ復号情報ｓ４１を、最終的な復号パケットデータｓ６２として、出力端子２から送出するようにすると良い。
【００９３】
入力ストリームｓ１の速度と、ヘッダー判定手段６１、パケットデータ復号手段４１、パケットデータ復号エラー判定手段６２の動作速度の関係にもよるが、通常は、このように同一のパケットデータ（ＰＤＭ＋３など）に対して複数回の復号を実行するためには、入力ストリームｓ１中の各パケット（ＰＭ＋３など）を一時的に蓄積しておくための比較的大きな容量のバッファメモリＢＭを装備することになると考えられる。
【００９４】
図２の構成ならば、このバッファメモリＢＭを装備するのは、ヘッダー判定手段６１である。
【００９５】
新たなストリーム再復号指示信号ｓ６４が供給されるたびに、当該ヘッダー判定手段６１は、当該バッファメモリＢＭからパケット（例えばＰＭ＋３）を読み出して、当該パケットのパケットヘッダー（例えばＰＨＭ＋３）をパケットヘッダーｓ１３としてパケットヘッダー解析手段３１に供給し、当該パケットのパケットデータ（例えばＰＤＭ＋３）をパケットデータｓ１４としてパケットデータ復号手段４１に供給することになる。
【００９６】
そして、パケットヘッダーｓ１３やパケットデータｓ１４が出力されるたびに、パケットヘッダー解析エラー判定手段３２がパケットヘッダーエラー情報ｓ３３を出力すると共に、パケットデータ復号エラー判定手段６２がパケットデータエラー情報ｓ４３を出力することが可能で、そのたびにストリームヘッダー推定手段２３が推定値の変更を行う。
【００９７】
従って、入力ストリームｓ１上のパケット数を基準とすると、第１の実施形態よりも少ないパケット数で、推定値を最適値（正しいストリームヘッダー推定情報ｓ２３）に収束させることが可能である。
【００９８】
なお、上述した繰り返し条件として回数を設定した場合には、バッファメモリＭＢの容量は比較的小さくて済み、最終的な復号パケットデータｓ６２の出力間隔も安定するが、個々のフレームに関する画質の点では、必ずしも十分な高画質を得られない場合もあり得る。
【００９９】
一方、繰り返し条件として、復号エラーがないと判定されるまでという条件を設定した場合には、バッファメモリＭＢの容量は比較的大きく、最終的な復号パケットデータｓ６２の出力間隔は必ずしも安定しないものの、個々のフレームに関する画質は十分に高品質となる。
【０１００】
しかしながら、いずれの繰り返し条件を選んでも、第１の実施形態よりは、高い画質を得ることが可能である。
【０１０１】
（Ｂ−２）第２の実施形態の効果
以上のように、第２の実施形態によれば、第１の実施形態と同様な効果を奏することができる。
【０１０２】
加えて、第２の実施形態では、より早い時点に受信されたパケットに基づいて、推定値を最適化することができるので、受信開始後、第１の実施形態よりも早い段階で、動画像を画面表示することが可能である。これにより、使い勝手の良さや信頼性は、いっそう向上する。
【０１０３】
また、第２の実施形態では、画面表示される画像の画質を、第１の実施形態よりも高品質にすることが可能である。
【０１０４】
（Ｃ）第３の実施形態
以下では、第３の実施形態が、既述した第１、第２の実施形態と相違する点についてのみ説明する。
【０１０５】
この第３の実施形態と後述する第４の実施形態は、第１又は第２の実施形態の出力端子２に接続して使用される映像出力装置に関するものである。
【０１０６】
従って、この映像出力装置は、前記受信装置１０（又は２０）と、画面表示装置などの画像出力手段の間に挿入して配置される。
【０１０７】
なお、受信装置を広くとらえると、この映像出力装置も受信装置の一部であるとみなすこともできる。
【０１０８】
（Ｃ−１）第３の実施形態の構成及び動作
第３の実施形態の映像出力装置５０の構成を図３に示す。この映像出力装置５０は、復号パケットデータからフレームを構成して出力する装置である。
【０１０９】
図３において、映像出力装置５０は、入力端子３と、復号フレーム生成手段５１と、復号ブロック検証手段５２と、参照フレーム格納手段５３と、映像出力端子４とを備えている。
【０１１０】
このうち、入力端子３は、上述した受信装置１０（又は２０）の出力端子２に接続される端子で、上述した復号パケットデータｓ４２（又はｓ６２）を復号フレーム生成手段５１に入力するために使用される。
【０１１１】
そして、復号フレーム生成手段５１は、復号パケットデータｓ４２（ｓ６２）から復号フレームを生成し、復号フレームデータｓ５１として出力する部分である。
【０１１２】
また、参照フレーム格納手段５３は、この復号フレームデータｓ５１を以降のフレーム復号時に参照するために格納する部分である。
【０１１３】
復号ブロック検証手段５２は、復号フレームデータｓ５１として供給されるフレーム中の各ブロックが、パケットロス等により正常に復号できなかったブロックを参照せずに復号できているかどうかを検証する部分である。
【０１１４】
入力端子３から入力される復号パケットデータｓ４２（ｓ６２）はまず復号フレーム生成手段５１に接続され、復号フレーム生成手段５１から出力される復号フレームデータｓ５１が参照フレーム格納手段５３及び復号プロック検証手段５２に接続され、復号映像データｓ５２が映像出力端子４に接続されて、外部の画像出力手段などに出力される。
【０１１５】
映像を符号化する場合には、一般にフレームを小さなブロックに分割し、複数のブロックを１つのパケットにまとめて伝送する。従って、復号パケットデータｓ４２（ｓ６２）には複数のブロックデータが含まれており、復号フレーム生成手段５１で各ブロックをフレーム内の所定の位置に順次配置することによりフレームが生成される。
【０１１６】
生成されたフレームは復号フレームデータｓ５１として、以降のフレームを復号する際に参照するために参照フレーム格納手段５３に格納されると同時に、復号ブロック検証手段５２へも送られる。
【０１１７】
復号ブロック検証手段５２では、復号フレームデータｓ５１中の各ブロックがパケットロス等の影響を受けずに正しく復号されたブロックかどうかを検証し、全てのブロックが正しく復号されているフレームだけを、復号映像データｓ５２として映像出力端子４へ出力する。
【０１１８】
（Ｃ−１）第３の実施形態の効果
以上のように、第３の実施形態によれば、伝送中のパケットロスなどによってフレームの一部が欠落した場合でも、従来のように、次のイントラフレームを受信するまで直前の（同一の）フレームを表示し続けるのではなく、フレーム中のブロックの状況に応じて新たな復号フレームを表示するため、規則的にイントラブロックとして符号化する手法等と組み合わせることにより、十分に補完処理を行い、早期のフレーム表示回復を行うことが可能となる。
【０１１９】
これにより、動画像を視聴しているユーザは、パケットロスなどが起きた場合でも、不自然な静止画ではなく動画像を見ることが可能になる。
【０１２０】
（Ｄ）第４の実施形態
以下では、この第４の実施形態が既述した第３の実施形態と相違する点についてのみ説明する。
【０１２１】
上述したように、この第４の実施形態も、第３の実施形態と同様な映像出力装置に関するものである。
【０１２２】
（Ｄ−１）第４の実施形態の構成及び動作
第４の実施形態の映像出力装置６０の構成を図４に示す。
【０１２３】
図４において、図３と同一の符号を付した各部３，４，５１，５３の機能は、第３の実施形態と同じである。
【０１２４】
また、図４中の復号ブロック検証手段５５は、第３の実施形態の復号ブロック検証手段５２と同じ機能を備えているが、そのほかに、検証状況データｓ５３を出力する機能も装備している。
【０１２５】
従って、第４の実施形態の映像出力装置６０は、第３の実施形態の映像出力装置５０と比べて、復号ブロック検証手段５５及び代替映像生成手段５４に関連する部分が相違する。
【０１２６】
当該代替映像生成手段５４は、有効な復号映像データｓ５２が出力できない期間に検証の状況に応じた代替映像（例えば、長時間にわたり検証が完了しない場合はその旨を知らせる映像や、検証の進み具合をグラフ表示した映像など）を画面表示させるために、代替映像データｓ５４を出力する部分である。
【０１２７】
第４の実施形態の映像出力装置６０では、復号ブロック検証手段５５において、全てのブロックが正しく復号されるまでの状況を検証状況データｓ５３として代替映像生成手段５４へ出力し、代替映像生成手段５４では検証の状況に応じた代替映像データｓ５４を出力し、静止ではなく動いている映像を、映像出力端子４を通じて外部の画像出力手段などに画面表示させる。
【０１２８】
これにより、システムの稼動状況を視聴者に示すことが可能となる。
【０１２９】
（Ｄ−２）第４の実施形態の効果
以上のように、第４の実施形態によれば、第３の実施形態と同様な効果を奏することができる。
【０１３０】
加えて、第４の実施形態では、第３の実施形態でも新たな映像を画面表示させることができない状況（内部処理に時間を消費している状態など）には、代替映像を画面表示することができる。
【０１３１】
これにより、ユーザは、動画像の視聴中には、一瞬たりとも、何も表示されない画面や不自然な静止画を見せられることがなくなり、システムの異常停止に対する不安等に起因するユーザの心理的負担の軽減が期待でき、非常に快適に動画像を視聴することが可能となる。
【０１３２】
（Ｅ）他の実施形態
第１〜第４の実施形態は、主として、国際標準規格ＭＰＥＧ（Moving  Pictures  Experts  Group）−４を想定したものであるが、本発明は、ＭＰＥＧ−４規格以外にも広く適用することが可能である。
【０１３３】
また、第１〜第４の実施形態では、動画像に関する情報の画面表示を行うための単位信号としてフレームを用いたが、本発明は、例えば、フィールド単位で処理することも可能である。
【０１３４】
さらに、第１〜第４の実施形態では、動画像に関する情報の信号伝送を行うための単位信号としてパケットを用いたが、本発明は、例えば、固定長のＡＴＭ（非同期転送モード）セルを利用することも可能である。
【０１３５】
なお、第３及び第４の実施形態では、図３、図４に示した映像出力装置５０、６０を、第１、第２の実施形態の受信装置１０、２０の出力端子２に接続されたものとして説明したが、映像出力装置５０、６０は、パケットの復号機能を装備した一般的な動画像処理装置に接続して使用することも可能である。
【図面の簡単な説明】
【０１３６】
【図１】第１の実施形態に係る受信装置の構成を示すブロック図である。
【図２】第２の実施形態に係る受信装置の構成を示すブロック図である。
【図３】第３の実施形態に係る映像出力装置の構成を示すブロック図である。
【図４】第４の実施形態に係る映像出力装置の構成を示すブロック図である。
【図５】第１〜第４の実施形態で使用する入力ストリームの構成を示す概略図である。
【図６】第１〜第４の実施形態で使用するヘッダーの構成を示す概略図である。
【符号の説明】
【０１３７】
１０、２０…受信装置、１１，６１…ヘッダー判定手段、２１…ストリームヘッダー解析手段、２２…ストリームヘッダー情報保持手段、２３…ストリームヘッダー推定手段、３１…パケットヘッダー解析手段、３２…パケットヘッダー解析エラー判定手段、４１…パケットデータ復号手段、４２、６２…パケットデータ復号エラー判定手段、ｓ１…入力ストリーム、ｓ１２…ストリームヘッダー、ｓ１３…パケットヘッダー、ｓ１４…パケットデータ、ｓ２１…ストリームヘッダー情報、ｓ２３…ストリームヘッダー推定情報、ｓ３３…パケットヘッダーエラー情報、ｓ４３…パケットデータエラー情報、ｓ４２、ｓ６２…復号パケットデータ。
【図１】
2007097211.tif 000003
【図２】
2007097211.tif 000004
【図３】
2007097211.tif 000005
【図４】
2007097211.tif 000006
【図５】
2007097211.tif 000007
【図６】
2007097211.tif 000008