(57)【要約】【課題】ベストエフォート型のＩＰ通信網における通信状態をユーザに分かり易く表示できるようにした映像受信装置を提供する。【解決手段】受信機１は、ＩＰ網を介して受信されるＵＤＰパケットから、受信すべき総パケット数及び実際に受信したパケット数を含むパケット情報を取得するＩＰ放送チューナ部１６と、取得したパケット情報に基づいてパケット受信率又はパケットロス率を算出するパケット受信率算出部２５ａと、算出したパケット受信率又はパケットロス率により通信状態を表示するためのＯＳＤ信号を生成するＯＳＤ処理部１９と、生成したＯＳＤ信号を表示する液晶表示部２９とを備える。【選択図】図３
2010258512.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰ通信網に接続可能な映像受信装置であって、
前記ＩＰ通信網を介して受信されるＵＤＰパケットから、受信すべき総パケット数及び実際に受信したパケット数を含むパケット情報を取得するパケット情報取得部と、該取得したパケット情報に基づいてパケット受信率又はパケットロス率を算出するパケット受信率算出部と、該算出したパケット受信率又はパケットロス率により通信状態を表示するためのＯＳＤ信号を生成するＯＳＤ処理部と、該生成したＯＳＤ信号を表示する表示部とを備えたことを特徴とする映像受信装置。
【請求項２】
請求項１に記載の映像受信装置において、前記ＵＤＰパケットの中で失ったロスパケットを復元する復元部を備え、前記パケット情報取得部は、前記パケット情報として、受信すべき総パケット数、実際に受信したパケット数、及び前記復元部で復元したロスパケット数を取得することを特徴とする映像受信装置。
【請求項３】
請求項２に記載の映像表示装置において、前記パケット情報として、前記復元部で復元したロスパケット数を取得した場合、前記パケット受信率算出部は、該復元後のパケット受信率又はパケットロス率を算出し、前記ＯＳＤ処理部は、該算出した復元後のパケット受信率又はパケットロス率による通信状態を含めてＯＳＤ信号を生成することを特徴とする映像受信装置。
【請求項４】
請求項３に記載の映像受信装置において、前記ＯＳＤ処理部は、前記復元部による復元前後のパケット受信率又はパケットロス率を１つのグラフにしたＯＳＤ信号を生成することを特徴とする映像受信装置。
【請求項５】
請求項１〜４のいずれか１項に記載の映像受信装置において、前記パケット受信率算出部は、前記映像受信装置の通信状態を、前記パケット受信率又は前記パケットロス率に応じてレベル分けし、前記ＯＳＤ処理部は、前記パケット受信率算出部によりレベル分けされた通信状態のレベルと、該レベルの通信状態を説明するためのメッセージとを含むＯＳＤ信号を生成することを特徴とする映像受信装置。
【請求項６】
請求項１〜５のいずれか１項に記載の映像受信装置において、前記パケット受信率算出部は、前記パケット受信率又は前記パケットロス率を所定時間毎に更新することを特徴とする映像受信装置。
【請求項７】
請求項１〜６のいずれか１項に記載の映像受信装置において、前記表示部は、前記映像受信装置の本体操作部あるいはリモコン操作部でユーザにより入力される操作信号に応じて、前記ＯＳＤ処理部で生成されたＯＳＤ信号を表示することを特徴とする映像受信装置。
【請求項８】
請求項１〜６のいずれか１項に記載の映像受信装置において、前記パケット受信率又は前記パケットロス率により前記映像受信装置の通信状態を判定する判定部を備え、該判定部により前記映像受信装置の通信状態が悪いと判定された場合、前記表示部は、前記ＯＳＤ処理部で生成されたＯＳＤ信号を表示することを特徴とする映像受信装置。
【請求項９】
請求項１〜８のいずれか１項に記載の映像受信装置において、前記ＵＤＰパケットは、ＲＴＰパケットを含むことを特徴とする映像受信装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、映像受信装置に関し、より詳細には、ベストエフォート型のＩＰ（Internet Protocol）通信網における通信状態を表示する機能を備えた映像受信装置に関する。
【背景技術】
【０００２】
近年、ＡＤＳＬ（Asymmetric Digital Subscriber Line）やＦＴＴＨ（Fiber To The Home）などのネットワークではベストエフォート型（通信品質非保証型）のＩＰ通信網が整備され、ＩＰ接続機能を備えたテレビにおいて、「ひかりＴＶ」や「アクトビラ」などのＩＰを用いた放送サービス（ＩＰＴＶサービス）が提供されるようになってきた。このＩＰＴＶサービスでは、主にブロードバンド回線上の専用のＩＰ網により、ＩＰ放送、ＶＯＤ、映像ダウンロードなどのサービスが提供されている。
【０００３】
上記ＩＰ網により、ＭＰＥＧ−２形式などで圧縮された映像コンテンツをストリーミング配信する場合には、映像コンテンツのスループット（帯域利用効率）とリアルタイム性を確保するために、ＵＤＰ（User Datagram Protocol）／ＩＰという誤り再送を行わずに連続的に送信する方式を用いることがある。しかし、この方式にはデータ誤りや伝送遅延に伴うパケット損失が生じたときに通信品質が劣化してしまう避けられない問題があった。
【０００４】
これに対して、例えば、特許文献１には、無線通信ネットワークの通信品質の情報を、デジタルテレビなどのデジタルＡＶ機器上で表示可能とした通信品質通知装置が記載されている。この通信品質通知装置は、無線通信ネットワークの通信品質パラメータを検知する無線通信部と、通信品質データと判定基準テーブルデータとの比較処理により、通信品質レベルを判定する無線通信品質レベル判定部と、デジタルテレビでデコード可能なＭＰＥＧ方式で予め圧縮符号化され且つ判定されたレベルに対応する通信品質を表現する通信品質通知用ＭＰＥＧデータを、通信品質レベルデータに基づき選択する選択スイッチと、選択された通信品質通知用ＭＰＥＧデータをデジタルテレビに伝送する通信部とを備える。
【０００５】
また、特許文献２には、ベストエフォート型の通信網を利用したテレビ映像信号の受信において、画質の劣化や表示中断の原因をユーザに通知する映像受信端末が記載されている。この映像受信端末の受信側装置は、パケット損失による通信異常をＲＴＰ処理部で検出し、通信異常による誤りの検出を通知された誤り処理部は通信状態表示部に表示指示を送り、通信状態表示部は通信状態を表示する状態表示ランプを点灯して通信異常を提示する。
【先行技術文献】
【特許文献】
【０００６】
【特許文献１】特開２００４−２４２１５６号公報
【特許文献２】特開２００５−２１０１６０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１に記載の通信品質通知装置は、無線通信ネットワークの通信品質データを、ＩＥＥＥ１３９４などの有線ネットワークを介して既存のデジタルテレビに送信し、通信状態をユーザに通知できるようにしているが、この通知状態の内容は通信品質レベルを単に高，中，低の３段階に分けているに過ぎず、また、特許文献２に記載の映像受信端末は、通信状態に問題があるときに状態表示ランプを点灯させているに過ぎない。
【０００８】
このように上記特許文献１，２に記載の技術をはじめとする従来技術は、パケットロスが発生したか否かを単純に通知するだけのものであり、ベストエフォート型ＩＰ通信網における通信状態をユーザに分かり易く通知するようにはなっていない、従って、ユーザは、映像が乱れた場合などに通信状態について詳しく知ることができず、通信状態に問題があるのか否か、さらに、映像が正常に受信できている場合でも、通信状態に余裕があるのか否かといったことまで把握することができなかった。
【０００９】
本発明は、上述のごとき実情に鑑みてなされたものであり、ベストエフォート型のＩＰ通信網における通信状態をユーザに分かり易く表示できるようにした映像受信装置を提供すること、を目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するために、第１の技術手段は、ＩＰ通信網に接続可能な映像受信装置であって、前記ＩＰ通信網を介して受信されるＵＤＰパケットから、受信すべき総パケット数及び実際に受信したパケット数を含むパケット情報を取得するパケット情報取得部と、該取得したパケット情報に基づいてパケット受信率又はパケットロス率を算出するパケット受信率算出部と、該算出したパケット受信率又はパケットロス率により通信状態を表示するためのＯＳＤ信号を生成するＯＳＤ処理部と、該生成したＯＳＤ信号を表示する表示部とを備えたことを特徴としたものである。
【００１１】
第２の技術手段は、第１の技術手段において、前記ＵＤＰパケットの中で失ったロスパケットを復元する復元部を備え、前記パケット情報取得部は、前記パケット情報として、受信すべき総パケット数、実際に受信したパケット数、及び前記復元部で復元したロスパケット数を取得することを特徴としたものである。
【００１２】
第３の技術手段は、第２の技術手段において、前記パケット情報として、前記復元部で復元したロスパケット数を取得した場合、前記パケット受信率算出部は、該復元後のパケット受信率又はパケットロス率を算出し、前記ＯＳＤ処理部は、該算出した復元後のパケット受信率又はパケットロス率による通信状態を含めてＯＳＤ信号を生成することを特徴としたものである。
【００１３】
第４の技術手段は、第３の技術手段において、前記ＯＳＤ処理部は、前記復元部による復元前後のパケット受信率又はパケットロス率を１つのグラフにしたＯＳＤ信号を生成することを特徴としたものである。
【００１４】
第５の技術手段は、第１〜第４のいずれか１の技術手段において、前記パケット受信率算出部は、前記映像受信装置の通信状態を、前記パケット受信率又は前記パケットロス率に応じてレベル分けし、前記ＯＳＤ処理部は、前記パケット受信率算出部によりレベル分けされた通信状態のレベルと、該レベルの通信状態を説明するためのメッセージとを含むＯＳＤ信号を生成することを特徴としたものである。
【００１５】
第６の技術手段は、第１〜第５のいずれか１の技術手段において、前記パケット受信率算出部は、前記パケット受信率又は前記パケットロス率を所定時間毎に更新することを特徴としたものである。
【００１６】
第７の技術手段は、第１〜第６のいずれか１の技術手段において、前記表示部は、前記映像受信装置の本体操作部あるいはリモコン操作部でユーザにより入力される操作信号に応じて、前記ＯＳＤ処理部で生成されたＯＳＤ信号を表示することを特徴としたものである。
【００１７】
第８の技術手段は、第１〜第６のいずれか１の技術手段において、前記パケット受信率又は前記パケットロス率により前記映像受信装置の通信状態を判定する判定部を備え、該判定部により前記映像受信装置の通信状態が悪いと判定された場合、前記表示部は、前記ＯＳＤ処理部で生成されたＯＳＤ信号を表示することを特徴としたものである。
【００１８】
第９の技術手段は、第１〜第８のいずれか１の技術手段において、前記ＵＤＰパケットは、ＲＴＰパケットを含むことを特徴としたものである。
【発明の効果】
【００１９】
本発明によれば、ベストエフォート型のＩＰ通信網における通信状態をユーザに分かり易く表示できるため、ユーザは現在の通信状態を迅速に把握して、家庭内ネットワークの点検や、回線契約の見直し、他の通信機器を停止させる、などの対策を施すことができる。
【図面の簡単な説明】
【００２０】
【図１】本発明に係る映像受信装置の一例として受信機が組み込まれたＶＯＤ配信システムの構成例を示す概略図である。
【図２】図１に示す受信機の構成例を示すブロック図である。
【図３】本発明に係る受信機における通信状態表示を行う主要部の構成例を説明するためのブロック図である。
【図４】一般的なＲＴＰパケットの構成例を示す図である。
【図５】パケット受信率により通信状態を表示するＯＳＤ画面の一例を示す図である。
【発明を実施するための形態】
【００２１】
以下、添付図面を参照しながら、本発明の映像受信装置に係る好適な実施の形態を説明する。
【００２２】
図１は、本発明に係る映像受信装置の一例として受信機が組み込まれたＶＯＤ配信システムの構成例を示す概略図で、図中、１は映像受信装置の一例である受信機、２はリモコン操作部に相当するリモートコントローラ（リモコン）、３はＩＰ網、４はポータルサーバ、５はＣＡＳ（Conditional Access System）／ＤＲＭ（Digital Rights Management）サーバ、６はコンテンツサーバを示す。本例では、受信機１として、ＶＯＤ配信コンテンツの受信・再生機能を備えたテレビジョン放送受信装置（液晶テレビ）を例示して説明するが、これに限定されるものではなく、例えば、ＶＯＤ配信コンテンツの受信・再生機能を備えたレコーダやセットトップボックスなどであってもよい。
【００２３】
図１に例示するＶＯＤ配信システムは、受信機１にＩＰ網３を介してポータルサーバ４、ＣＡＳ／ＤＲＭサーバ５、コンテンツサーバ６が接続され、これらのサーバによりＣＤＮ（Contents Delivery Network）が構成される。各サーバは、例えば、ＣＰＵ（Central Processing Unit）、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、記憶装置、ネットワークインターフェイス（ネットワークＩ／Ｆ）などで構成され、ＲＯＭ等にはサーバプログラムがＣＰＵで実行可能に格納されている。
【００２４】
コンテンツサーバ６は、提供用のコンテンツ６ａを記憶装置に格納し、ＩＰによるＶＯＤサービスとしてそのコンテンツ６ａを受信機１に提供するサーバである。コンテンツ６ａは、例えば、ＭＰＥＧ−２やＨ．２６４で圧縮符号化されており、いずれの場合でもＭＰＥＧ−２  ＴＳ（Transport Stream）形式のパケット、好ましくは受信機１側のバッファオーバーフローを防ぐためにタイムスタンプ付きＴＳ（ＴＴＳ）形式のパケットで配信すればよい。
【００２５】
コンテンツサーバ６は、ＲＴＰ（Real-time Transfer Protocol）に従って、このようなコンテンツ６ａをＩＰ網３にユニキャストアドレスで出力（ストリーム配信）する。このとき、トランスポート層のプロトコルとしてはＵＤＰ（User Datagram Protocol）を採用しＵＤＰパケットでストリーム配信すればよい。また、配信は、欠損（ロス）したパケットを受信機１側で復元するために前方誤り訂正（ＦＥＣ）技術を採用して実行してもよく、受信機１側でもこれに対応する回路を具備しておけばよい。
【００２６】
また、コンテンツサーバ６の記憶装置には、コンテンツ６ａ毎に再生制御ファイル６ｂが記憶されている。再生制御ファイル６ｂは、対象となるコンテンツ６ａの再生に必要な情報ファイルであり、ＸＭＬ（eXtensible Markup Language）形式で記述され、ＥＲＩ（Entry Resource Information）、ＬＬＩ（license Link Information）、ＮＣＩ（Networkcontent Control Information）が含まれる。ＥＲＩは、コンテンツタイトル、提供元、尺長、チャプタ位置などのコンテンツ固有の情報であり、コンテンツ起動文書とも呼ばれる。ＬＬＩは、コンテンツのライセンス情報にアクセスするための情報である。ＮＣＩはストリーミングコンテンツの再生制御に関する情報であり、サーバ側で対応しているトリックプレイ（早送りや巻き戻しなど）の種類や速度が記述されている。
【００２７】
コンテンツサーバ６は、受信機１から再生制御ファイル取得要求を受信し、その応答として、要求された再生制御ファイル６ｂを記憶装置から読み出して受信機１に送信する。このときの通信プロトコルは、ＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰを採用すればよい。ここで、ＨＴＴＰ（Ｓ）は、ＨＴＴＰ（Hypertext Transfer Protocol）あるいはＨＴＴＰにＳＳＬ（Secure Sockets Layer）によるデータの暗号化機能を付加したＨＴＴＰＳ（HTTP Security）を指す。
【００２８】
また、図１では受信機１にコンテンツサーバ６が１台接続された例を示しているが、複数台接続されていてもよい。さらに、コンテンツサーバ６をセンタサーバとし、そのセンタサーバに対するキャッシュサーバを設置しておき、受信機１からのコンテンツ６ａや再生制御ファイル６ｂの配信要求に対して、キャッシュサーバのＵＲＬ（Uniform Resource Locators）等のＵＲＩ（Uniform Resource Identifier）を返し、受信機１にそのＵＲＩで配信要求を行わせるようにＣＤＮを構成してもよい。
【００２９】
ポータルサーバ４は、受信機１からポータル画面の表示要求を受信し、ＢＭＬ形式やＨＴＭＬ形式などでポータル画面を提供するための画面である。このときの通信プロトコルは、ＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰを採用すればよい。このポータル画面は、コンテンツサーバ６で提供するコンテンツ６ａをユーザに選択させるための画面（コンテンツ選択画面）であり、例えば、ＢＭＬデータで受信機１に提供される。このコンテンツ選択画面は、例えば、コンテンツ６ａ毎にタイトルや代表的な静止画像等の情報を選択可能に表示するものであればよい。
【００３０】
ＣＡＳ／ＤＲＭサーバ５は、コンテンツサーバ６で提供するコンテンツ６ａに対する視聴制限や課金を行うためのサーバである。例えば、コンテンツサーバ６で提供するコンテンツ６ａを有料で且つ受信機１がその視聴用のライセンスを持たない場合に、ＣＡＳ／ＤＲＭサーバ５は受信機１からのライセンス取得要求を受信し、ライセンスを発行して返信する。このときの通信プロトコルもＨＴＴＰ（Ｓ）／ＴＣＰ／ＩＰを採用すればよい。また受信機１の認証にはＣＡＳカードを用いることができる。
【００３１】
図２は、図１に示す受信機１の構成例を示すブロック図である。受信機１は、全体を制御する制御部の一例として、受信機１全体の制御を実行するＣＰＵ２５、ＲＡＭ２４、及びＥＥＰＲＯＭ（Electrically Erasable and Programmable ROM）等の不揮発性メモリ２８を備え、それらが他部と共にバス接続されてなる。不揮発性メモリ２８には、受信機１全体の制御を行うための制御プログラムをはじめ、ＥＰＧ（Electronic Program Guide）などを表示するためのキャラクタ（文字，シンボル，オブジェクト等）や、ユーザ設定データなどの各種データが格納される。なお、上記制御プログラムはＲＯＭ（図示せず）に格納してもよい。ＲＡＭ２４は、任意のアドレスを指定して読み書きすることが可能な半導体メモリであって、ＣＰＵ２５の作業領域となって不揮発性メモリ２８に格納されたプログラムを読み出したり、処理中のデータを一時的に格納したりする。
【００３２】
受信機１に対するユーザ操作は図示しない本体の操作部で行うか、あるいは受信機１用のリモコン２によって行う。リモコン２は、搭載されたボタンの押下によって操作信号を生成し、受信機１へその操作信号を送信する。この操作信号を受信するために、受信機１はリモコン受光部２７を備える。リモコン受光部２７で受信した操作信号に基づき、ＣＰＵ２５は、受信機１の現在の動作状態に応じた動作を実行するように受信機１内の各部を制御する。
【００３３】
図２に例示する受信機１は、ＶＯＤ配信コンテンツの受信機能の他に、デジタル放送の受信機能も組み込まれている。そのため、受信機１は、デジタル放送を受信する受信アンテナ１１と、デジタル放送の受信信号をチューニング（選局）するデジタルチューナ部１２と、チューニングされたデジタル放送のデータを復調するデジタル復調部１３とを備える。なお、本発明に係る受信機１において、ＶＯＤ配信コンテンツ受信機能を備えていればよく、デジタル放送受信機能は必須ではないため、上記の各部を備えない構成としてもよい。
【００３４】
受信機１は、ＩＰを用いてＶＯＤ配信されたコンテンツ６ａを受信可能とするために、ＬＡＮ（Local Area Network）１４に接続され、コンテンツサーバ６からＬＡＮ１４を介してコンテンツ６ａのＵＤＰパケットを受信するネットワークＩ／Ｆ部１５と、ネットワークＩ／Ｆ部１５を介してＵＤＰパケットで受信したコンテンツ６ａをＴＳパケットに変換するＩＰ放送チューナ部１６とを備える。受信機１のＩＰ網３への接続はＬＡＮ１４を経由してネットワークＩ／Ｆ部１５が行うが、ネットワークＩ／Ｆ部１５を例えばメディアコンバータなどと直接接続することで、ＬＡＮ１４を構築しなくとも可能である。
【００３５】
また、受信機１は、ＩＰ網３に接続された各サーバ４〜６と通信するために通信制御部２６を備える。通信制御部２６もネットワークＩ／Ｆ部１５を介して外部との通信を行う。通信制御部２６は、コンテンツサーバ６とのコンテンツ６ａの再生制御（再生の開始や終了、トリックプレイなどの制御）に際しては、通信プロトコルとしてＲＴＳＰ／ＴＣＰ／ＩＰを用いる。
【００３６】
さらに、受信機１は、デジタル放送ストリームに含まれるか別途放送されるＳＩ情報（番組情報）を、デジタル復調部１３から出力された復調データから分離する分離部（ＤＭＵＸ）１７を備える。ＤＭＵＸ１７は、ＶＯＤ配信型ＩＰ放送のＳＩ情報がＶＯＤ配信ストリームに含まれるか別途配信されている場合には、ＩＰ放送チューナ部１６の出力であるＴＳパケットからその番組情報の分離も実行する。また、ＤＭＵＸ１７は、復調データやＴＳパケットをビデオデータとオーディオデータとに分離する。なお、デジタル放送とＶＯＤ配信されたＩＰ放送との間でのビデオデータ及びオーディオデータの切り換えは、ＣＰＵ２５からの制御によりこのＤＭＵＸ１７で行うなどすればよい。
【００３７】
ビデオ信号の出力のために、受信機１は、ＤＭＵＸ１７で分離されたデジタル放送のビデオデータやＶＯＤ配信コンテンツのビデオデータをデコードするビデオデコード部１８と、不揮発性メモリ２８に予め格納されたキャラクタを用いてＥＰＧや設定メニューなどのＯＳＤ（On Screen Display）用の信号（ＯＳＤ信号）を生成するＯＳＤ処理部１９と、このＯＳＤ信号をビデオデコード部１８から出力されたビデオ信号に重畳する合成部２０と、合成部２０で合成された信号を出力用のビデオ信号に変換するビデオ出力変換部２１とを備える。
【００３８】
オーディオ信号の出力のために、受信機１は、ＤＭＵＸ１７で分離されたオーディオデータをデコードするオーディオデコード部２２と、オーディオデコード部２２から出力されたオーディオ信号を出力用のオーディオ信号に変換するオーディオ出力変換部２３とを備える。
【００３９】
さらに、受信機１には、映像表示用の液晶表示部２９と、音声出力用のスピーカ３０とを備える。液晶表示部２９は、ビデオ出力変換部２１から出力されたビデオ信号に基づき映像を表示する。スピーカ３０は、オーディオ出力変換部２３から出力されたオーディオ信号に基づき音声を出力する。
【００４０】
ここで、合成部２０によりＯＳＤ処理部１９から重畳される、ＥＰＧ画面、ＢＭＬ画面などを表示するためのＯＳＤ信号について説明する。なお、ＯＳＤ処理部１９では、これらの画面の他に例えば、選局プログラム２８ａで選局されたチャンネル番号やＤＭＵＸ１７で分離されたＳＩ情報を表示するためのＯＳＤ信号を生成し、合成部２０で重畳することもできる。
【００４１】
ＥＰＧ画面を表示させるために、受信機１は、ＥＰＧ処理プログラム２８ｂを、不揮発性メモリ２８にＣＰＵ２５で実行可能に格納している。ＥＰＧ画像信号の生成処理は、ＥＰＧ処理プログラム２８ｂが、ＤＭＵＸ１７で分離された番組データを不揮発性メモリ２８などに蓄積しておき、それらの番組データを読み出し、番組データの枠となる枠データと共にＯＳＤ処理部１９に渡して指示する。ＯＳＤ処理部１９では番組データ及び枠データから対応するキャラクタを読み出してＥＰＧ画面用の画像を生成し、ＥＰＧ画像信号として出力する。また、ＥＰＧ処理プログラム２８ｂによって表示されたＥＰＧ画面においてユーザ操作により或る番組が選択された場合には、上述の選局プログラム２８ａが実行される。
【００４２】
ＢＭＬ画面を表示させるために、受信機１は、ＢＭＬブラウザ２８ｃを、不揮発性メモリ２８にＣＰＵ２５で実行可能に格納している。ＢＭＬ画像信号の生成処理は、まず、ＢＭＬブラウザ２８ｃが通信制御部２６を制御して、通信制御部２６がネットワークＩ／Ｆ部１５にＢＭＬ画面の元となるＢＭＬ文書データをポータルサーバ４から取得させる。そして、ＢＭＬブラウザ２８ｃは、取得したＢＭＬ文書データを解析しＢＭＬ画面の画像を生成し、ＢＭＬ画像信号としてＯＳＤ処理部１９へ渡す。ＢＭＬ画像信号を受け取ったＯＳＤ処理部１９は、そのまま合成部２０へ出力する。
【００４３】
また、受信機１は、ＩＰ放送チューナ部１６でコンテンツサーバ６から所望のコンテンツ６ａを受信させるが、その受信制御並びにコンテンツ再生制御を行う制御プログラムとして、ＡＶプレーヤ２８ｄを備える。ＡＶプレーヤ２８ｄは、ＶＯＤ配信型ＩＰ放送のコンテンツの受信及び再生制御を行うためのプログラムであり、不揮発性メモリ２８にＣＰＵ２５で実行可能に格納されている。
【００４４】
また、受信機１は、ＣＡＳ／ＤＲＭサーバ５とＩＰ網３を介して接続され、コンテンツサーバ６で提供するコンテンツ６ａに対する視聴制限や課金が行われる。この視聴制限や課金を行うためのプログラムが、ＣＡＳ／ＤＲＭクライアント２８ｅである。このＣＡＳ／ＤＲＭクライアント２８ｅは、不揮発性メモリ２８にＣＰＵ２５で実行可能に格納されている。
【００４５】
また、再生制御ファイル２８ｆは、前述したように、コンテンツサーバ６から取得されるコンテンツ６ａの再生に必要なファイルであり、例えば、ＥＲＩ、ＬＬＩ、ＮＣＩのＸＭＬ文書で構成されている。
【００４６】
図３は、本発明に係る受信機１における通信状態表示を行う主要部の構成例を説明するためのブロック図である。本発明の主たる特徴部分は、ベストエフォート型のＩＰ通信網における通信状態をユーザに分かり易く表示することにある。このための構成として、受信機１は、ＩＰ網３を介して受信されるＵＤＰパケットから、受信すべき総パケット数及び実際に受信したパケット数を含むパケット情報を取得するパケット情報取得部に相当するＩＰ放送チューナ部１６と、取得したパケット情報に基づいてパケット受信率又はパケットロス率を算出するパケット受信率算出部２５ａと、算出したパケット受信率又はパケットロス率により通信状態を表示するためのＯＳＤ信号を生成するＯＳＤ処理部１９と、生成したＯＳＤ信号を表示する表示部に相当する液晶表示部２９とを備える。なお、受信機１がレコーダまたはセットトップボックスなどである場合、外部接続されたテレビ装置の表示部にＯＳＤ信号を表示させるようにしてもよい。
【００４７】
図４は、一般的なＲＴＰパケットの構成例を示す図である。図４（Ａ）はＲＴＰパケットのフォーマットの例を示し、図４（Ｂ）はＲＴＰパケットのヘッダフォーマットの例を示す。このＲＴＰはリアルタイムデータ転送プロトコルと呼ばれ、映像や音声データをリアルタイムに伝送することを目的としたプロトコルであり、ＵＤＰの上位プロトコルとして機能する。以下では、リアルタイムデータ転送プロトコルとしてＲＴＰを用いた場合を例示して説明するが、リアルタイムデータ転送プロトコルであれば、このＲＴＰ以外であってもよい。
【００４８】
ＲＴＰパケットは、図４（Ａ）に示すように、ＵＤＰパケットのデータ部に格納されるため、ＵＤＰパケットに含まれるものといえるが、設計自体はトランスポート層（ＵＤＰ）やネットワーク層（ＩＰ）のプロトコルに依存しないものとなっている。また、ＲＴＰはリアルタイム伝送を実現するために、データと共に送受信間及びデータ内での同期クロック情報（タイムスタンプ）や順序（シーケンス）番号、データタイプを送信する。これらの情報に基づいて受信機側はデータのリアルタイム再生を行う。ＲＴＰパケットでは、欠損したパケットを無視して有効なパケットのみで再生できるように構成されているため、映像や音声のデータが部分的に欠けていても再生することができる。
【００４９】
図４（Ｂ）において、“Ｖ”はバージョン番号を示す（２ビット）。通常は“２”が入る。“Ｐ”はパディングを示す（１ビット）。これはパケットの最後にペイロードがパディングされ、本来の長さよりも長くなっていることを示すもので、パケットが暗号化される際など、フィールド長が固定長とされている場合に使用される。“Ｘ”はＲＴＰヘッダの直後に拡張ヘッダをもつ場合に設定されるフラグを示す（１ビット）。ヘッダ拡張は可変長であるが、先頭に１６ビットの長さフィールドがあり、受信機側で拡張部分を理解できない場合にはそれを無視できるようになっている。“ＣＣ”はＣＳＲＣカウントを示す（４ビット）。後続するＣＳＲＣ識別子の数が入る。
【００５０】
“Ｍ”はマーカを示す（１ビット）。これはパケットストリームでのフレーム境界の有無やストリーム内での重要なイベントにマークを付けるために使用される。その意味は使用するＲＴＰプロファイルとメディアタイプによって定義される。“ＰＴ”はペイロードタイプを示す（７ビット）。これは図示しないペイロードのタイプを示し、受信機側のアプリケーションではデータをどのデコンプレッサに渡すか等の処理方法の判断のためにこの値を使用する。
【００５１】
“シーケンス番号”は１ずつ増加するパケットの通し番号を示す（１６ビット）。初期値はセキュリティ確保のためにランダム値が用いられる。１６ビットではシーケンス番号がすぐに１周してしまうため、例えば、３２ビット以上に拡張し、下位１６ビットにシーケンス番号を入れ、上位１６ビットにシーケンス番号が何周したかカウントした値（回数）を入れるようにしてもよい。“タイムスタンプ”は先頭バイトの送信時刻を示す（３２ビット）。この値はメディアデータ毎に異なる割合で増加し、最大値を超えると“０”となる。メディアデータの再生をスケジュールするために使用される。
【００５２】
“同期ソース（ＳＳＲＣ：Synchronization Source）識別子”は、ＲＴＰセッション内の参加者の識別子を示す（３２ビット）。これはセッション毎に変わる一時的な識別子であり、複数の参加者が同じ値を選び衝突が起きた場合は別の値に変えなければならない。“貢献ソース（ＣＳＲＣ：Contributing Source）識別子”は、メッセージ内の各ストリーム要素を準備した送信元の識別子を示す（３２ビット）。それぞれの値は各ＳＳＲＣと同じであり、ＣＳＲＣリストに含まれるのはミキサで処理されたパケットである。
【００５３】
前述の図３において、ＩＰ放送チューナ部１６は、ＩＰ網３を介して受信されるＵＤＰパケット（以下、ＲＴＰパケットという）から、受信すべき総パケット数及び実際に受信したパケット数を含むパケット情報を取得するが、このパケット情報は上記のシーケンス番号から取得することができる。まず、受信すべき総パケット数ａは、最初のパケットのシーケンス番号ｂと、最後のパケットのシーケンス番号ｃから、下記の式１で求めることができる。
【００５４】
受信すべき総パケット数ａ＝最後のパケットのシーケンス番号ｃ−最初のパケットのシーケンス番号ｂ＋１  …式１
例えば、最初のバケットのシーケンス番号ｂが“１”であり、最後のパケットのシーケンス番号ｃが“１０”であった場合、受信すべき総パケット数ａは、“１０”と求めることができる。なお、最初と最後のパケットは例えば最小のシーケンス番号を持つパケットを最初のパケットとみなし、最大のシーケンス番号を持つパケットを最後のパケットとみなすようにしてもよく、あるいは、パケットのヘッダ情報に含まれるパケットＩＤにより認識できる場合にはこれにより最初と最後のパケットを特定してもよい。
【００５５】
次に、実際に受信したパケット数ｄは、ＩＰ放送チューナ部１６が受信したパケット数をカウントしておくことで、求めることができる。このようにして求めた、受信すべき総パケット数ａと実際に受信したパケット数ｄとをパケット情報として、パケット受信率算出部２５ａに渡す。そして、パケット受信率算出部２５ａは、受信すべき総パケット数ａと実際に受信したパケット数ｄとに基づいて、下記の式２によりパケット受信率ｅを算出する。
【００５６】
パケット受信率ｅ（％）＝１００・実際に受信したパケット数ｄ／受信すべき総パケット数ａ  ・・・式２
例えば、実際に受信したパケット数ｄが“８”であり、受信すべき総パケット数ａが“１０”であった場合、パケット受信率ｅは、“８０％”と算出される。
【００５７】
また、ＩＰ放送チューナ部１６が、ＲＴＰパケットの中で失ったロスパケットを復元する復元部（ＦＥＣ機能など）を備える場合、復元後のパケット受信率を算出するようにしてもよい。なお、復元部はＦＥＣのみに限定されず、他の復元機能を適用してもよい。このロスパケットの数ｆは、受信すべき総パケット数ａから実際に受信したパケット数ｄを減算することで算出される。上記の例では、ロスパケット数ｆは、“１０”から“８”を減じて、“２”と算出される。そして、ＩＰ放送チューナ部１６はこのロスパケット数ｆのうち、ＦＥＣで復元したロスパケット数ｇを、受信すべき総パケット数ａと実際に受信したパケット数ｄと共に、パケット情報として、パケット受信率算出部２５ａに渡す。そして、パケット受信率算出部２５ａは、受信すべき総パケット数ａ、実際に受信したパケット数ｄ、及びＦＥＣで復元したロスパケット数ｇに基づいて、下記の式３により復元後のパケット受信率ｈを算出する。
【００５８】
復元後のパケット受信率ｈ（％）＝１００・（実際に受信したパケット数ｄ＋ＦＥＣで復元したロスパケット数ｇ）／受信すべき総パケット数ａ  ・・・式３
例えば、実際に受信したパケット数ｄが“８”であり、受信すべき総パケット数ａが“１０”であり、ＦＥＣで復元したロスパケット数ｇが“１”であった場合、復元後のパケット受信率ｈは、“９０％”と算出される。
【００５９】
ここで、上記ではパケット受信率を算出しているが、パケットロス率を算出するようにしてもよい。この場合、上述の式２，３を下記のようにすればよい。
パケットロス率ｉ（％）＝１００・（１−実際に受信したパケット数ｄ／受信すべき総パケット数ａ）  ・・・式４
復元後のパケットロス率ｊ（％）＝１００・（１−（実際に受信したパケット数ｄ＋ＦＥＣで復元したロスパケット数ｇ）／受信すべき総パケット数ａ）  ・・・式５
例えば、実際に受信したパケット数ｄが“８”であり、受信すべき総パケット数ａが“１０”であり、ＦＥＣで復元したロスパケット数ｇが“１”であった場合、パケットロス率ｉは式４から、“２０％”と算出され、復元後のパケットロス率ｊは式５から、“１０％”と算出される。
【００６０】
上記において、パケット受信率算出部２５ａは、ＩＰ放送チューナ部１６からパケット情報を取得し、パケット受信率またはパケットロス率を所定時間毎（例えば、１秒毎）に更新する。そして、ＣＰＵ２５は、ユーザが受信機１の本体操作部あるいはリモコン２を操作することで入力される操作信号を受信すると、ＯＳＤ処理部１９に対して、通信状態表示指示を送り、ＯＳＤ処理部１９は、上記のパケット受信率またはパケットロス率により通信状態を表示するためのＯＳＤ信号を生成し、液晶表示部２９は、このＯＳＤ信号を表示出力する。
【００６１】
上記ＯＳＤ信号を表示させるタイミングについて説明する。例えば、ユーザが受信機１でコンテンツ視聴中に、映像が乱れ、通信状態が気になったときなどに、ユーザがリモコン２の所定の操作キーを押下して、あるいは、リモコン２で表示させたメニュー画面から選択して、通信状態を示すＯＳＤ信号を表示させるようにしてもよい。また、ＣＰＵ２５がパケット受信率またはパケットロス率により受信機１の通信状態を自動的に判定し、受信機１の通信状態が悪いと判定した場合に、通信状態を示すＯＳＤ信号を表示するようにしてもよい。通信状態の良否は、例えば、ＦＥＣ復元後のパケット受信率が８０％未満は通信状態が悪いといったように、パケット受信率またはパケットロス率に対して適切な閾値を設定しておけばよい。
【００６２】
図５は、パケット受信率により通信状態を表示するＯＳＤ画面の一例を示す図で、図中、４０はＯＳＤ画面を示す。ＯＳＤ画面４０は、ロスパケットのＦＥＣによる復元の有無を示すロスパケット復元４１と、パケット受信率をグラフ化したパケット受信率４２と、復元後のパケット受信率４６と、受信機１の受信状態を示すメッセージ及びレベル４７とを含む。パケット受信率４２は、復元前のパケット受信率４３、復元後のパケット受信率４４、及び復元できなったパケットの割合４５を１つにまとめた棒グラフとして例示されているが、円グラフなどの他のグラフとしてもよい。また、上記のパケット受信率４３〜４５を色分けして表示すると、ユーザが一見して受信状態を把握できるためより好ましい。
【００６３】
また、受信機１のパケット受信率算出部２５ａは、受信機１の通信状態を、パケット受信率に応じてレベル分けしてもよい。この場合、ＯＳＤ処理部１９は、パケット受信率算出部２５ａによりレベル分けされた通信状態のレベルと、レベルの通信状態を説明するためのメッセージとを含むＯＳＤ信号を生成する。そして、受信状態４７に示すように、通信状態のレベルと、レベルの通信状態を説明するためのメッセージとをＯＳＤ表示することができる。
【００６４】
具体的に例示すると、パケットを全て受信できた場合、すなわち、復元前のパケット受信率が１００％の場合をレベルＡとする。また、ロスパケットがあったが全て復元できた場合、すなわち、復元前のパケット受信率が１００％未満で、且つ、復元後のパケット受信率が１００％であった場合をレベルＢとする。ロスパケットがあったが全て復元できなかった場合、すなわち、復元前のパケット受信率が１００％未満で、且つ、復元後のパケット受信率が５０％以上１００％未満であった場合をレベルＣとし、復元前のパケット受信率が１００％未満で、且つ、復元後のパケット受信率が５０％未満であった場合をレベルＤとする。
【００６５】
そして、上記のようにレベル分けしたレベル情報（Ａ，Ｂ、Ｃ，Ｄ）と共に、各レベルを説明するメッセージとして、例えば、レベルＡには「良好です」、レベルＢには「受信できます」、レベルＣには「受信状態がよくありません」、レベルＤには「受信状態が非常に悪いです」をＯＳＤ表示する。また、パケットストリームを受信していない場合には、「通信を行っていません」というメッセージを表示させてもよい。
【００６６】
図５の例では、ユーザは、ロスパケット復元４１が「あり」であるため、ＦＥＣ復元を行っていることがわかり、パケット受信率４２のグラフ及び復元後のパケット受信率４６から、復元前のパケット受信率が９４％、復元後のパケット受信率が９７％、復元できなかった割合が３％であることがわかる。そして、ユーザは、受信状態４７から、現在の受信状態がレベルＣで、あまりよい受信状態ではないということがわかる。
【００６７】
なお、上記ではパケット受信率に基づいてＯＳＤ画面を表示している場合について例示したが、パケットロス率についても同様のＯＳＤ画面表示を行うことができるのは言うまでもない。
【００６８】
このように、本発明によれば、ベストエフォート型のＩＰ通信網における通信状態をユーザに分かり易く表示できるため、ユーザは現在の通信状態を迅速に把握して、家庭内ネットワークの点検や、回線契約の見直し、他の通信機器を停止させる、などの対策を施すことができる。
【符号の説明】
【００６９】
１…映像受信装置（受信機）、２…リモコン、３…ＩＰ網、４…ポータルサーバ、５…ＣＡＳ／ＤＲＭサーバ、６…コンテンツサーバ、６ａ…コンテンツ、６ｂ…再生制御ファイル、１１…デジタル放送受信アンテナ、１２…デジタルチューナ部、１３…デジタル復調部、１４…ＬＡＮ、１５…ネットワークＩ／Ｆ部、１６…ＩＰ放送チューナ部、１７…分離部、１８…ビデオデコード部、１９…ＯＳＤ処理部、２０…合成部、２１…ビデオ出力変換部、２２…オーディオデコード部、２３…オーディオ出力変換部、２４…ＲＡＭ、２５…ＣＰＵ、２５ａ…パケット受信率算出部、２６…通信制御部、２７…リモコン受光部、２８…不揮発性メモリ、２８ａ…選局プログラム、２８ｂ…ＥＰＧ処理プログラム、２８ｃ…ＢＭＬブラウザ、２８ｄ…ＡＶプレーヤ、２８ｅ…ＣＡＳ／ＤＲＭクライアント、２８ｆ…再生制御ファイル、２９…液晶表示部、３０…スピーカ。
【図１】
2010258512.tif 000003
【図２】
2010258512.tif 000004
【図３】
2010258512.tif 000005
【図４】
2010258512.tif 000006
【図５】
2010258512.tif 000007