JP3916382B2

JP3916382B2 - 動画像受信装置

Info

Publication number: JP3916382B2
Application number: JP2000206929A
Authority: JP
Inventors: 剛弘上田; 晃子林下
Original assignee: Oki Electric Industry Co Ltd
Current assignee: Oki Electric Industry Co Ltd
Priority date: 2000-07-07
Filing date: 2000-07-07
Publication date: 2007-05-16
Anticipated expiration: 2020-07-07
Also published as: US7466754B2; US20060088109A1; US20060088108A1; US7006574B2; JP2002027462A; US20020003840A1

Description

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

Claims

動画像に関する情報の、信号伝送のための単位信号または画面表示を行うための単位信号をそのヘッダーである単位信号ヘッダーと共に含むビットストリームであって、前記単位信号ヘッダーの解析に利用される情報を含むストリームヘッダーをストリーム先頭又はストリーム中間に伴うビットストリームを受信する動画像受信装置において、
前記ビットストリームのストリームヘッダーが有するストリームヘッダー情報の内容を推定して、ストリームヘッダー情報推定値を得るストリームヘッダー情報推定手段と、
前記単位信号の単位信号ヘッダーが有する単位信号ヘッダー情報を、前記ストリームヘッダー情報推定値に基づいて解析して、単位信号ヘッダー情報解析値を得る単位信号ヘッダー情報解析手段と、
当該単位信号ヘッダー情報解析手段の解析結果が誤りであるか否かを判定し、当該解析結果が誤りである場合には前記ストリームヘッダー情報推定値を変更する第１の判定手段と
を備えることを特徴とする動画像受信装置。
請求項１の動画像受信装置において、
前記単位信号が収容している動画像に関する情報を、前記単位信号ヘッダー情報解析値に基づいて復号する復号手段と、
当該復号手段の復号結果が誤りであるか否かを判定し、当該復号結果が誤りである場合には前記ストリームヘッダー情報推定値を変更する第２の判定手段と
を備えることを特徴とする動画像受信装置。
請求項１の動画像受信装置において、同一の前記単位信号が収容している動画像に関する情報を復号するに際し、所定の反復条件を満足するまで、前記ストリームヘッダー情報推定値の変更を繰り返す反復変更手段を備えることを特徴とする動画像受信装置。