JP2004040276A - デジタル放送受信端末 - Google Patents

Abstract

【課題】瞬断によってデジタル放送の映像データが不連続になった場合には、再度正常に受信されるまで、最後に正常に出力したデジタルデータを出力しつづけている。この場合、音声が不自然になるため、視聴者は常に心地よく番組を聞くことができない。
【解決手段】データの欠落が発生した後に、欠落したデータを補完するデータを携帯電話等の通信機器経由で取得し、放送が切れないようにデータの連続性を保つ。補完データの取得が間に合わない場合には、欠落したデータの部分に、ノイズデータを挿入する。更に欠落個所までのデータの再生する速度を遅くすることにより、バッファ中に一定量のデータを保持することにより、放送が途切れることを防止する。
【効果】視聴者に途切れない快適なデジタル放送を提供することが可能となる。
【選択図】　図２

Description

【０００１】
【発明の属する技術分野】
本発明はデジタル放送の送信装置，受信端末に関し、特にデジタル放送の瞬断を防止するための技術に関する。
【０００２】
【従来の技術】
従来、デジタル放送受信中に電波が途切れてデータが受信できなくなった場合には、特開２０００−２１６８４８号公報にあるように、デジタルインターフェースを介して他の機器から受信したトランスポートストリーム中の付加情報内に不連続情報が含まれているか否かを調べ、不連続情報が検出された場合には、トランスポートストリーム中の付加情報の取り込みを行うことにより、外部から入力されるプログラムが変化した時のビデオデータおよびオーディオデータの復号化を迅速に行って復号出力が途切れないようにする技術がある。
【０００３】
また、特開平１０−２４３３６６号公報の技術には、データ放送による送信データファイルが未到着などの理由で途切れた場合には、放送局から電波を利用して、データファイルを伝送するとともに、このデータファイルのファイル属性を含む補助情報を有するファイル一覧を、データファイルとは別のファイルとして伝送するデータ放送システムが記載されている。このデータ放送システムにおけるデータ放送受信表示装置は、データファイル及びファイル一覧を含むデータ放送を受信するデータ放送データ受信手段と、受信したデータをファイルとして蓄積するデータファイル蓄積手段と、受信したファイルの中からファイル一覧を抽出するファイル一覧抽出手段と、ファイル一覧とデータファイルとから未到着ファイルを特定する未到着ファイル特定手段と、特定した未到着ファイルのファイル属性を判定するファイル属性判定手段と、未到着ファイルが未到着であるという情報を含むデータを生成する代替データ生成手段と、代替データ生成手段で生成されたデータに未到着ファイルと同じファイル名を付けて代替ファイルを生成し、データファイル蓄積手段に対して出力する代替ファイル生成手段とを備えており、未到着データファイルの存在を確認して、そのファイル名も特定することができる。また、エラーメッセージを別途表示するような必要がなく、邪魔になることもない。さらに、リトライを繰り返して未到着データを取りに行き、既に受信しているデータやエラーメッセージの表示に時間がかかるという問題を回避することができる効果がある。
【０００４】
【発明が解決しようとする課題】
しかし、前記した発明においては、不連続情報を検出した後、例えば映像データが不連続になった場合には、デジタルデータが再度正常に検出されるまでの間、最後に正常に出力したデジタルデータを出力し続けている。このような方法では、視聴者にとっては音声が不自然になってしまうこととなる。
【０００５】
また前記した２つの技術は、いずれも放送データが来ないことを検知してから、代替データの作成、並びに最後に正常に出力したデータを出力するために、処理の時間遅れが発生しやすくリアルタイム性を満足させることが難しい。この時間遅れは、デジタル放送の視聴者にとっては心地よいものではなく、リアルタイムで視聴者が意識しないようにデジタルデータを補完し、出力する方法が望まれている。
【０００６】
【課題を解決するための手段】
前記の課題を解決するために、本発明ではデジタルデータの欠落が発生した後に、欠落したデジタルデータを補う補完データを携帯電話等のモデム経由で取得する時間を、通信機器の電波の状況から推定する。その推定時間を、欠落したデータを再生するまでの時間と比較して、欠落データを再生するまでに、補完データの取得が可能である場合はそのまま補完データの取得を続け、放送が切れないようにデジタルデータの連続性を保つ。もし補完データの取得が間に合わない場合には、欠落したデータの部分に、ノイズデータを挿入することにより、放送聴取者に音が切れたことを判別しにくくさせる。また、前記推定した時間が欠落した最初のデータの再生までに間に合うものの、デジタルデータを再生するためのバッファが空に近くなるような場合には、欠落個所までのデータの再生する速度を遅くすることにより、バッファ中に一定量のデータを保持することにより、放送が途切れることを防止する。以上に示した手段を用いることにより、予想外の急激な放送電波の途切れが発生して、視聴者に対する映像や音声の出力が停止してしまう確率を低減させた、視聴者のストレスが少ないデジタル放送を提供する。
【０００７】
【発明の実施の形態】
次に、本発明の実施の形態に関して図面を用いて説明する。図１は本発明のデジタル放送補完サービスの大まかな構成である。本発明は、コンテンツ配信局
１００，地上波デジタル放送局１２０，乗用車に代表される移動体１１０，地上波デジタル放送を用いて放送されるコンテンツデータ１５０，移動体に搭載された携帯電話に代表される通信機器１８１０からなる。なお、第１の実施例ではコンテンツ配信局から移動体までの放送手段として、地上波デジタル放送を用いた場合について記述するが、後述するように、これは通信衛星，放送衛星、あるいは双方向通信ができる長楕円軌道衛星を用いたサービス等にも適用することが可能である。
【０００８】
次に、コンテンツ配信局１００及び移動体１１０中に搭載された移動体受信端末２０１の構成について、図２を用いて説明する。コンテンツ配信局１００はコンテンツを放送波に乗せて送信する送出装置１８０５，コンテンツを符号化するエンコーダ１８０７，デジタル放送に送出するコンテンツが蓄積されたコンテンツＤＢ１８０９，放送するコンテンツをエンコーダ１８０７で放送波に乗せる形式に変換して蓄積するエンコード済みコンテンツＤＢ１８０６から構成され、これらの機能は一つのバスで接続されている。また、コンテンツ配信局１００はＷｅｂサーバ１８０８を備え、インターネットに代表される通信網がコンテンツ配信局中のＷｅｂサーバ１８０８に接続されており、移動体１１０に備えている通信機器１８１０とコンテンツ配信局間で双方向通信を行うことが可能となっている。コンテンツ配信局１００は送出装置１８０５を通じて放送電波を送出する。電波を媒体としてコンテンツ配信局１００から送信されたデータは、移動体受信端末２０１にて受信される。
【０００９】
移動体受信端末２０１は、アンテナ１８０１，ＲＦ受信機１８０２，受信した電波よりデジタルデータを取り出すデジタル復調器１８０４，デジタルデータに欠落が発生した場合に、補完処理を行うデータ補完プラットフォーム１１０５，デコーダ１００６，音楽再生部（スピーカ）２１７から構成される。また、通信機器１８１０は、ハードウェア的にはデータ補完プラットフォーム１１０５に接続されている。
【００１０】
次に図３を用いて本実施例で用いるデジタルデータのフォーマットについて説明する。以下ではデジタルコンテンツを放送波に乗せて送信する方法として規格化されているＩＳＯ／ＩＥＣ国際標準１３８１８−１（以後、ＭＰＥＧ２０００）に準拠してデジタル放送を行う場合について説明する。
【００１１】
ＭＰＥＧ２０００は放送データを送受信するフォーマットとしてＭＰＥＧ２−ＴＳと呼ばれるフォーマットを用いている。これは図３に示すトランスポートストリーム７００（以後ＴＳ）に示されるように、ｓｙｎｃ＿ｂｙｔｅ（７０１），ｔｒａｎｓｐｏｒｔ＿ｅｒｒｏｒ＿ｉｎｄｉｃａｔｏｒ（７０２），ｐａｙｌｏａｄ＿ｕｎｉｔ＿ｓｔａｒｔ−ｉｎｄｉｃａｔｏｒ（７０３），ｔｒａｎｓｐｏｒｔ＿ｐｒｉｏｒｊｔｙ（７０４），ＰＩＤ（７０５），ｔｒａｎｓｐｏｒｔ＿ｓｃｒａｍｂｌｉｎｇ＿ｃｏｎｔｒｏｌ（７０６），ａｄａｐｔａｔｉｏｎ＿ｆｉｅｌｄ＿ｃｏｎｔｒｏｌ（７０７），ｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒ（７０８），ｄａｔａ＿ｂｙｔｅ（７０９）の各フィールドからなるデータの集合を一単位とした伝送方法である。まず、途切れないデジタル放送を実現するにはこのＴＳに一貫した通し番号をつけることが必要となる。しかし、以上に述べたＭＰＥＧ２００規格では各ＴＳを識別する識別子としてＰＩＤ（７０５）とｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒ（７０８）の値を用いることができるものの、特にｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒ（７０８）は０から１６までの数値しか取らないため、たとえばデータ欠落前後でｃｏｎｔｉｎｕｉｔｙ＿ｃｏｕｎｔｅｒ（７０８）の値が４から６に変わったとしても、その間で１個のＴＳだけが欠落したのか、それとも１７個のＴＳが欠落したのか判断する術がない。そこで、このような不確定性を低減するために、本実施例ではＴＳペイロード（７２０）に相当するｄａｔａ＿ｂｙｔｅ（７０９）フィールドの先頭に、ｃｏｕｎｔｅｒ＿ｆｌａｇ（７２１）、ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒ（７２２）という２つのフィールドを付加し、その後にｄａｔａ＿ｂｙｔｅ＿ｍａｉｎ（７２３）として、従来のｄａｔａ＿ｂｙｔｅ（７０９）に相当するデータを付加する。これにより、送信側では何番のトランスポートストリームにどのようなデータが入っていたかを管理することが容易になり、データ欠落の際にデータ補完を実施する際のインデキシングが容易となる。
【００１２】
次にエンコーダ１８０７でコンテンツＤＢ１８０９のデータをエンコードする際の手順について図１０を用いて説明する。まず、通し番号である前記の
ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドを０に初期化する（処理１０５１）。次に、エンコードを実施するコンテンツのファイルをロードし（処理１０５２）、ＭＰＥＧ２０００規格に従ったＴＳパケットのペイロードの大きさに合うサイズにコンテンツデータを分割する（処理１０５３）。次にｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドに通し番号が入っていることを認識させるための識別子であるｃｏｕｎｔｅｒ＿ｆｌａｇフィールドの値として１を設定する（処理１０５４）。なお、ｃｏｕｎｔｅｒ＿ｆｌａｇフィールドは０か１の値をとり、０の場合はｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの傾域に通し番号が入っていないことを示し、１が入っているときはｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの領域に通し番号が入っていること示す。そしてｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値を１だけ増やし（処理１０５５）、その後、ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値が一般的なコンテンツのサイズを元にして予め設定しておいたＭＡＸ値よりも小さいかをチェックする（処理１０５６）。もし、ＭＡＸ値より小さいのであれば、ｃｏｕｎｔｅｒ＿ｆｌａｇ，ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値と処理１０５３にて切り出したコンテンツファイルのデータをＴＳパケットに設定し、エンコード済みコンテンツＤＢ１８０６に格納する（処理１０５８）。予め設定したＭＡＸ値よりも大きくなった場合は、ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値を初期化（本実施例では０）する（処理１０５７）。次にエンコード対象のコンテンツファイルが終端にきたかどうかをチェックする（処理１０５９）。終端に来ていなければ、コンテンツの次に続く部分に対して処理１０５３以下を繰り返し実施し、コンテンツの終端に来ている場合はエンコードを終了する。
【００１３】
図１０に示したコンテンツのエンコード方法はリアルタイム性を求められない場合であった。一方、デジタル放送のコンテンツとして、渋滞映像，スポーツ中継に代表されるライブ放送がある。ライブ放送に代表されるコンテンツをエンコードする際には、図１１に示した方法でストリーミングコンテンツをエンコードする。まず、ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値を０にし（処理１１５１）、またバッファを空に初期化する（処理１１５２）。そして、ライブカメラ等からネットワークを経由して送信されてくるライブ放送のストリームファイルをエンコーダに取り込む（処理１１５３）。次に、ストリームファイルが終了したか否かを判定する（処理１１５４）。ここでストリームファイルが終了、即ちライブ放送が終了した場合には、エンコード処理を終了する。ライブ放送が継続している場合には、図３に示したＴＳパケットのペイロードであるｄａｔａ＿ｂｙｔｅ＿ｍａｉｎフィールドに入れることができる残りデータ量ＳＺと、取り込んだストリームファイルの大きさ（ＳＺＳＴ）を比較する（処理１１５５）。ＳＺ＞ＳＺＳＴと判定された場合（処理１１５６）は、まだ前記設定したバッファに余裕があるため、処理１１５３に戻り再度ストリーミングデータを読み込む。そうでない場合はバッファに余裕が無いため、バッファ中にたまったＳＺＳＴの量に相当するデータをデータ到着が早い順番でバッファから押し出してエンコードする（処理１１５７）。次に、処理１１５７でＳＺの大きさよりも大きかったストリームファイルのデータはバッファが一度クリアされた後に、バッファ中に格納される（処理１１５８）。ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドをインクリメントし、ｃｏｕｎｔｅｒ＿ｆｌａｇの値を１に設定し（処理１１５９）、その後にｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値があらかじめ設定したＭＡＸ値よりも小さいかどうかを判定する（処理１１５０）。処理１１５０にてＭＡＸ値よりも小さいと判定された場合は、ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールド，ｃｏｕｎｔｅｒ＿ｆｌａｇフィールド，エンコードされたコンテンツをＴＳパケットに設定する（処理１１５２）。処理１１５０にてＭＡＸ値よりも大きいと判定された場合には、ｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値を初期化（処理１１５１）してから処理１１５２に進む。
【００１４】
ここまでの説明はコンテンツを送信する側の説明であった。以下では、前述のようなＴＳパケット中にｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒフィールドの値を持つデータ放送を受信して、瞬断によるデータ欠落が発生した場合でも、データが途切れることなく表示ならびに再生可能となる移動体受信端末２０１について説明する。
【００１５】
まず、第１の実施例について説明する。図２に端末の概要を示したように、端末はアンテナ１８０１，電波受信機（ＲＦ受信機）１８０２，デジタル復調器
１８０４，データ補完プラットフォーム１１０５，デコーダ１００６，音楽再生部（スピーカ）２１７からなる。アンテナ１８０１は一般的に用いられているパラボラアンテナ，ダイポールアンテナ，ダイバーシチアンテナ等を用いる。ＲＦ受信機１８０２，デジタル復調器１８０４は一般的に用いられている放送受信モジュールと復調器である。データ補完プラットフォーム１１０５は本実施例の特徴的な装置である。デコーダ１００６は後述するように、エンコードされた映像，音声，静止画，文字図形，字幕，地図データ，ナビデータ等のデータからそれぞれ所望のデータの取得，変換を実施する装置である。受信されデコードされた放送データは図２に示すように信号線で接続され音楽再生部（スピーカ）２１７より出力される。なお、本実施例では音楽再生に関する実施例のみであるが、映像，ナビデータ等の他のデータについても同様の処理を実施することが可能である。
【００１６】
デコーダ１００６の詳細実施例について図１２を用いて説明する。デコーダ
１００６はデータ補完プラットフォームを通過したデータを、それぞれのコンテンツ識別ＩＤをもとに、ＭＰＥＧ２０００規格に従ったデコード処理部に振り分けられる。本実施例ではＡＶデコード処理１１１１のみを対象とするが、コンテンツ識別ＩＤがその他のデータの種類の場合には、たとえば文字図形静止画デコード処理，字幕文字スーパー処理，地図デコード処理等のデコード処理部から構成される。地点情報（ＰＯＩ），バイナリデータで表現された渋滞情報，緊急情報に関するアラーム等をデコードするデコーダを備えることも可能である。それぞれのデコーダでデコードされた各データは、端末の出力装置に出力される。本実施例ではスピーカ１１１６のみであるが、動画プレーン，静止画プレーン，文字図形プレーン，字幕プレーン，地図画面プレーンを備え、デコード結果を各プレーンに出力することも可能である。
【００１７】
次にデータ補完プラットフォーム１１０５について説明する。データ補完プラットフォーム１１０５は図４に示すように、データ欠落検出装置４０１，欠落データ取得時間推定装置４０２，データ取得装置４０３，ノイズデータ発生装置
４０４，データ補完装置４０５、からなり、データ取得装置４０３は通信機器
１８１０と接続され、データ補完装置４０５はデコーダ１００６に接続している。データ欠落検出装置４０１は受信したデジタル放送データからｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒ７２２フィールドを検出し、この値が順番になっているか、すなわち、番号の不連続がないかどうかをチェックする。ここでもしデータ欠落が検出されなかった場合には、受信したデジタルデータをデコーダ１００６に送り、データの再生を行う。
【００１８】
データ欠落検出装置４０１が受信したデジタルデータの不連続を検出した場合には、欠落データ取得時間推定装置４０２での処理を行う。ここでは、通信機器１８１０を用いて欠落データを取得する際に、電波を受信する地点の電界強度から、通信機器１８１０を経由してコンテンツ配信局から欠落データをダウンロードするのに必要な時間を算出する。電波を受信する地点の電界強度は、周囲の地形情報などから図１３に示すような秦式と呼ばれる一般的な指標を用いて算出することが可能である。また通信機器１８１０経由でのデータダウンロード時間は、ある電界強度において実際に測定した経験値を元に、そのダウンロード時間Ｄｔを電界強度の関数として求めておき、予め欠落データ取得時間推定装置４０２に記憶させておく。また一般的にデジタル放送では、データを一時的にバッファに蓄積してからデコーダなどで再生するために、欠落データを検出してから欠落部分の再生に達するまでに若干の時間Ｌｔがある。欠落データのダウンロードがこの時間Ｌｔの間に完了する場合は、データ取得装置４０３により通信機器１８１０を経由してデータを取得して、データ補完装置４０５にて欠落データの補完を行い、その後デコーダ１００６にデータを渡す。
【００１９】
欠落データのダウンロードに要する時間ＤｔがＬｔよりも大きく、かつＤｔがＬｔの１．５　倍以下の時には、欠落データ取得時間推定装置４０２からデコーダに対して、デコーダでの再生速度を通常のＤｔ／Ｌｔだけ遅くするように指示する。ここでの１．５　倍という数値は、音楽の再生速度を変化させた場合に違和感のない程度の遅さであり、デジタル放送のコンテンツ、たとえば音楽のソースによってはこれ以上の値を用いて更に遅く再生することも可能である。また、音楽ソースによって、たとえばデジタル放送のヘッダ中に埋め込まれているコンテンツ情報を元にして、この１．５　という数値を動的に変更することも可能である。ＤｔがＬｔの１．５　倍以上のときはデータのダウンロードを行わず、ノイズデータ発生装置４０４にて発生するノイズデータを、欠落したデジタル放送データに補完することにより、擬似的にアナログ放送で音が途切れるような状況を作り出して、あたかも音が途切れないような放送を実現する。
【００２０】
以上の処理をフローチャートにしたものが図５である。データ補完プラットフォーム１１０５では、まず再生時の遅延を行うかどうかの変数ｄｅｌａｙＦｌａｇ　の初期化を行う（処理５０１）。そして、デジタル放送データを受信して（処理５０２）、デジタル放送データのパケット番号をカウントする（処理５０３）。その後、受信したデータに欠落がないかどうかを検出する（処理５０４）。データ欠落を検出しない場合には、通常の再生処理を行うようにデコーダ１００６に指示する（処理５１０）。データ欠落を検出した場合には、欠落部位を再生するまでの時間Ｌｔとデータをダウンロードするのに必要な時間を上記図１３中の式などを用いて算出する（処理５０５）。このＬｔとＤｔを比較して（処理５０６）、ＬｔがＤｔよりも大きいときには、通信機器１８１０（本実施例の場合、携帯電話を用いる）を経由してデータを取得し（処理５０７）、補完処理を行い（処理５０８）、変数ｄｅｌａｙＦｌａｇを調べて遅延再生を行う必要があるかどうかを判定し（処理５０９）、遅延再生の必要がない場合には通常再生処理を行うようにデコーダ１００６に指示する（処理５１０）。処理５０６の比較によりＬｔがＤｔよりも小さい場合には、データ再生の時間を遅らすことにより、切れない放送が可能であるかどうかを判定する（処理５１１）。遅延再生により切れない放送が可能である場合には、欠落しているデジタル放送データの個数Ｎを検出し、さらに、遅延再生を実施することを認識するフラグを立てる（処理５１２）。その後、処理５０８にて補完処理を行い、処理５０９にて遅延再生フラグが１であるため、遅延再生を実施する指令をデコーダ１００６に送信する（処理５１４）。そして、処理したデジタル放送データの個数を差し引く（処理５１５）。前記欠落したデジタル放送データがなくなったかどうかを判定し（処理５１６）、まだ欠落したデジタル放送データがある場合には、処理５０２に戻って引き続き受信するデジタル放送データを取りこむ。欠落したデジタル放送データがすでになくなった場合には、遅延再生フラグを初期化した後（処理５１７）、引き続きデジタル放送データを受信して、これまでの処理を繰り返す。処理５１１でデータ再生の時間を遅らすことにより、切れない放送が可能とならない場合には、データ欠落部に埋め込むノイズデータを作成し（処理５１３）、データ補完を行う（処理５０８）。その後、処理５０９では遅延フラグがたっていないので、処理５１０にて通常再生を行い、デジタル放送データを受信する処理５０２以下を繰り返す。
【００２１】
次に、コンテンツ配信局とデータ補完プラットフォームの連携について図６を用いて説明する。コンテンツ配信局１００ではストリーム放送を行う際に、送信したＴＳパケットの蓄積履歴をあらかじめ保存しておく（処理２００１）。これはコンテンツ配信局から送信する時間と、前記したＴＳパケットのｓｅｑｕｅｎｔｉａｌ＿ｃｏｕｎｔｅｒ　の値を記憶装置に保存しておくことで実現可能である。このように配信履歴を蓄積しながら、コンテンツ配信局から車載端末に対してストリームデータを放送する（処理２００２）。ここで放送されてきたストリームデータは、移動体受信端末２０１側の放送キャッシュに蓄積される（処理１９０３）。この後、データ補完プラットフォーム１１０５では、受信データに欠落が発生しているかどうかを判定する（処理２００４）。データ欠落が発生している場合には通信処理２００５にてコンテンツ配信局１００に欠落パケットを要求する。ここで要求するデータの品質は通信回線の混雑状況、ならびにデジタル放送の契約形態により柔軟に変更することが可能である。このときの要求方法は一般的なＷｅｂサーバのＣＧＩ（Ｃｏｍｍｏｎ　Ｇａｔｅｗａｙ　Ｉｎｔｅｒｆａｃｅ）と呼ばれる機能を使って、“ｈｔｔｐ：／／ｗｅｂｓｅｒｖｅｒ．ｈｏｇｅｈｏｇｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｇｅｔＤａｔａ？ｓｔａｒｔ＿ｉｄ＝０００００＆ｅｎｄ＿ｉｄ＝０００３０”のようなＵＲＬを指定することによって実現できる。この表記の意味は、“ｈｔｔｐ：／／ｗｅｂｓｅｒｖｅｒ．ｈｏｇｅｈｏｇｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ”がデータ補完を行うためのプログラムが存在しているコンテンツ配信局のＷｅｂサーバのアドレスを示していて、“ｇｅｔＤａｔａ”が補完すべきデータを取得するプログラム、“ｓｔａｒｔ＿ｉｄ”　が、補完すべきデータの始まりのパケット番号（Ｓｅｑｕｅｎｔｉａｌ＿Ｃｏｕｎｔｅｒ）、“ｅｎｄ＿ｉｄ”が補完すべきデータの終りのパケット番号を示している。もちろん、これはデータ取得のための一表現であるため、他の表現方法や他の言語処理系を用いることも可能である。
【００２２】
このようにして欠落データを検索した後（処理２００６）、該当するパケットを通信機器（本実施例では携帯電話）１８１０を経由して取得し（処理１９０７）、通信キャッシュに格納する（処理２００８）。この処理の間に若干の時間が必要となるので、その間に新たなデータ欠落が発生していないかを判定する（処理２００９）。以上の点線で囲んだ処理２０１０を、コンテンツが配信されている一定時間あるいは端末に電源が入っている一定時間繰り返す。その間、データ補完プラットフォーム１１０５からの指令により、データの欠落が発生した際には、放送キャッシュと通信キャッシュの中身をデータマージ処理して（処理２０１１）、デコーダに再生指示を送り（処理２０１２）デコード処理を行った後に再生装置にてデータを再生する。
【００２３】
次に、本実施例における受信端末２０１の画面イメージについて図９を用いて説明する。本来、本発明で実施される放送が切れないサービスは意識されることなく行われるべきものであるものの、受信端末の動作検証、あるいは再生品質の確認や保証などのために、画面上で動作の確認をおこなうことがある。図９はそのための画面の一例である。図９中の９０１はデジタル放送データの受信状態を表すバーグラフである。データを正常に受信してバッファに格納した個所は灰色で表示されていて、受信していない個所、すなわちデータ欠落が発生している個所（９０４，９０５，９０６）は背景が白く表示されている。９０２はデジタル放送データを再生している進行状況を示している。黒く表されている個所が、前記したバッファ内に受信済みデジタル放送データを再生した部分を表している。９０３のテキストエリアはデータのダウンロード状況、ならびに再生状況を表している。９０４に示す斜線部分は欠落したデジタル放送データを通信機器経由で既にダウンロードした後に補完したことを示している。９０５の部分は、欠落したデジタル放送データをダウンロードしている途中の経過を示しており、斜線部分までダウンロードが完了したことを表している。９０６の部分は、欠落したデジタル放送データがダウンロードされるのを待っている状態を示している。
【００２４】
本発明の第１の実施例を用いる事により、放送データの欠落が発生した際に、その欠落部位を別の通信手段を用いてダウンロードするのに必要な時間を予想して、欠落したデータをダウンロードする時間がかかる場合には、データの出力速度を調整、あるいはノイズを入れることにより、視聴者に途切れないデジタル放送を提供し、快適なデジタル放送環境を提供することが可能となる。
【００２５】
次に本発明の第２の実施例について説明する。本発明の第２の実施例は第１の実施例が、デジタル放送データのビットレートと、コンテンツ配信局から通信機器を用いて取得する補完データのビットレートが同一であることを仮定していたのに対して、第２の実施例では、補完データのダウンロード時間を調整するために、コンテンツ配信局側でコンテンツをエンコードする際に、複数のビットレートによるエンコード済みコンテンツを作成し、データ欠落したデジタル放送データをダウンロードする際に、第１の実施例にて述べたＤｔがＬｔよりも大きい際に、ビットレートの小さいデータを通信機器経由で取得することにより、データをダウンロードする時間を短縮して、途切れない放送を実現するものである。以下、第２の実施例におけるデータ補完プラットフォーム１１０５について、図７を用いて説明する。
【００２６】
第２の実施例におけるデータ補完プラットフォーム１１０５はデータ欠落検出装置７５１，ビットレート検出装置７５２，欠落データ取得時間推定装置７５３，ダウンロードビットレート算出装置７５４，データ取得装置７５５，ノイズデータ発生装置７５６，データ補完装置７５７からなる。データ取得装置７５５に通信機器（本実施例では携帯電話）１８１０が接続され、データ補完装置７５７の後段にデコーダ１００６が接続されているのは第１の実施例と同じである。データ欠落検出装置７５１は第１の実施例と同様である。第１の実施例で説明に用いていた音楽データの場合は、そのデータ中に図１４に示すようなヘッダデータが存在し、このヘッダデータ中にビットレートに関する記述が含まれるため、ビットレート検出装置７５２は、このヘッダデータと、そのビットレート情報を取得する。欠落データ取得時間推定装置７５３では、第１の実施例で述べた欠落部位を再生するまでの時間Ｌｔと、デジタル放送で受信したデータと同一のビットレートのデータをダウンロードする際に必要な時間Ｄｔ，ダウンロードするデータサイズＳｔを推定する。欠落データをダウンロードする時間を稚定する方法は、第１の実施例で述べたものと同様である。ここでの推定結果から、ダウンロードビットレート算出装置７５４では、ダウンロードするデータのビットレートを低くすることで、途切れない放送を実現することが可能であるかどうかを判定し、これが可能である場合は、データ取得装置７５５から、ビットレートを指定したデータを通信機器１８１０を介してコンテンツ配信局１００に対して要求し、指定したビットレートで欠落データのダウンロードを行う。このとき、コンテンツ配信局では予め決め打ちした複数のビットレート、たとえば、通常のビットレート、通常の半分のビットレート、通常の４分の１のビットレート、という形態でエンコードしたデジタルデータを保存しておく必要がある。あるいは、車載端末からの要求に応じて必要なビットレートでダイナミックにデータをエンコードして、ダウンロード要求がきたデータを準備することも可能である。ノイズデータ発生装置７５６，データ補完装置７５７，デコーダ１００６は第１の実施例と同様である。
【００２７】
次に第２の実施例の詳細な処理手順を図８のフローチャートを用いて説明する。まずデジタル放送データを受信する（処理８０１）。そして、デジタル放送データのストリームデータ中のパケット番号をカウントする（処理８０２）。その後、データ欠落を検出する（処理８０３）。データ欠落がない場合には、そのまま通常のデジタル放送データの再生を実施する（処理８０７）。データ欠落を検出した際には、欠落部位を再生するまでの時間Ｌｔ、データダウンロードに必要な時間Ｄｔを算出する（処理８０４）。その後、ＬｔとＤｔを比較し（処理８０５）、Ｌｔのほうが大きければ処理８１１に進み通信機器経由でデジタル放送で更信したデータのビットレートと同一のビットレートのデータをコンテンツ配信局よりダウンロードし、その後に補完処理を実施して（処理８０６）、通常の再生処理を実施する（処理８０７）。もし処理８０５にてＬｔがＤｔよりも小さいと判定された場合には、ダウンロード可能なビットレートのデータが存在するかを算出する（処理８０８）。ここでのダウンロード可能なビットレートとは、コンテンツ配信局に決め打ちのビットレートでのエンコード済みコンテンツがあるかどうかを検出することを意味する。あるいは、デジタル放送データのソースがＡＡＣ（Ａｄｖａｎｃｅｄ　Ａｕｄｉｏ　Ｃｏｄｉｎｇ）のフォーマットに従っている場合には、１６ｋｂｐｓ以下の音楽データは音質的に劣るため、逆にノイズを補完データの代わりに用いても大きな差異はない。このような状況になっているかを検出する意味もある。ダウンロード可能なビットレートのデータが存在する場合は、該ビットレートのデータを通信機器１８１０経由で取得し（処理８０９）、その後補完処理８０６を実施し、再生処理８０７を行う。処理８０８にてダウンロード可能なデータが存在しない場合には、欠落データの部分に埋めるノイズデータを生成し（処理８１０）、補完処理８０６を行い、再生処理８０７を行う。
【００２８】
なお、異なったビットレートのデータをダウンロードする場合は、先に述べた図６中で欠落パケットをデータ補完プラットフオームからコンテンツ配信局に要求を出す際のＣＧＩコマンドは、“ｈｔｔｐ：／／ｗｅｂｓｅｒｖｅｒ．ｈｏｇｅｈｏｇｅ．ｃｏｍ／ｃｇｉ−ｂｉｎ／ｇｅｔＤａｔａ？ｓｔａｒｔ＿ｉｄ＝０００００＆ｅｎｄ＿ｉｄ＝０００３０＆ｂｉｔｒａｔｅ＝１２８”のようになる。第１の実施例との違いは、“ｂｉｔｒａｔｅ”がコンテンツファイルのエンコード時ビットレートを示している点である。
【００２９】
本発明の第２の実施例を用いる事により、放送データの欠落が発生した際に、その欠落部位をダウンロードするのに必要な時間を予想して、欠落したデータをダウンロードする時間がかかる場合には、もとの受信データと異なる（再生品質が劣る）ビットレートを持つダウンロードデータを用いる、あるいはノイズを入れることにより、視聴者に途切れないデジタル放送を提供し、快適なデジタル放送環境を提供することが可能となる。
【００３０】
本発明の第３の実施例は第１の実施例と第２の実施例を組み合わせた形態である。すなわち、第１の実施例では再生速度を遅くし、第２の実施例ではビットレートの低いデータを探すことにより補完データのダウンロード時間に余裕を持たせていたが、第３の実施例ではこれらを組み合わせて、デジタル放送データが欠落した場合に補完するデータの順番を、通常のデータ（デジタル放送データと同一のビットレートを持つデータ）をダウンロードして放送が途切れないかの可否、それが遅れそうな場合は、データの再生を遅らして放送が途切れないかどうかの判定、それでも放送が切れそうな場合はビットレートを低くして、ダウンロードするデータの大きさを小さくして、ダウンロード時間を短縮して、放送が途切れないかの可否、の順番で途切れない放送を実現する方法である。装置全件の構成は図７と同様であるため、処理のフローチャートについて図１５を用いて説明する。
【００３１】
処理５０１では前記した再生時の遅延を行うかどうかの変数の初期化を行う。処理５０２でデジタル放送データを受信した後に、デジタル放送データのパケット番号を処理５０３にてカウントする。その後に、処理５０４にて受信したデータに欠落がないかどうかを検出する。データ欠落を検出しない場合には処理５１０にて通常の再生処理を行う。データ欠落を検出した場合には処理５０５にて欠落部位を再生するまでの時間Ｌｔとデータをダウンロードするのに必要な時間を図１３中の式などを用いて算出する。ＬｔがＤｔよりも大きいときには処理５０７にて本実施例の場合に用いる通信機器を経由してデータを取得し、処理５０８にて補完処理を行い、処理５０９にて遅延再生を行う必要があるかどうかを判定し、その必要がない場合には処理５１０にて通常再生を行う。処理５０６にてＬｔがＤｔよりも小さい場合には処理５１１にて、データ再生の時間を遅らすことにより、切れない放送が可能であるかどうかを判定する。それが可能である場合には、処理５１２で欠落しているデジタル放送データの個数Ｎを検出し、さらに、遅延再生を実施することを認識するフラグを立てる。その後、処理５０８にて補完処理を行い、処理５０９にて遅延再生フラグが１であるため、処理５１４にて遅延再生を実施する指令をデコーダ１００６に送信する。その後、処理５１５にて、処理したデジタル放送データの個数を差し引く。処理５１６にて前記欠落したデジタル放送データがなくなったかどうかを判定し、まだ欠落したデジタル放送データがある場合には引き続き受信するデジタル放送データを取りこむ。欠落したデジタル放送データがすでになくなった場合には、処理５１７にて遅延再生フラグを初期化して、引き続きデジタル放送データを受信して、これまでの処理を繰り返す。処理５１１でデータ再生の時間を遅らすことにより、切れない放送が可能とならない場合は、処理８０８にてダウンロード可能なビットレートのデータが存在するかを算出する。ここでのダウンロード可能なビットレートとは、コンテンツ配信局に決め打ちのビットレートでのエンコード済みコンテンツがあるかどうかを検出することを意味する。あるいは、たとえばデジタル放送データのソースがＡＡＣ（Ａｄｖａｎｃｅｄ　Ａｕｄｉｏ　Ｃｏｄｉｎｇ）のフォーマットに従っている場合には、１６ｋｂｐｓ以下の音楽データは音質的に劣るため、逆にノイズを補完データの代わりに用いても大きな差異はない。このような状況になっているかを検出する意味もある。ダウンロード可能なビットレートのデータが存在する場合は、処理８０９にて該ビットレートのデータを通信機器経由で取得し、その後処理５０８にて補完処理を実施し、この場合は遅延フラグが立っていないため、処理５０９を素通りし処理５１０で再生を行う。処理８０８にてダウンロード可能なデータが存在しない場合には、処理８１０にて欠落データの部分に埋めるノイズデータを生成し、処理５０８にて補完処理を行い、先と同様に処理５１０にて再生を行う。
【００３２】
本発明の第３の実施例を用いる事により、放送データの欠落が発生した際に、その欠落部位をダウンロードするのに必要な時間を予想して、欠落予想部位の再生品質を段階的に落としていくことにより、視聴者にとっては途切れないデジタル放送を提供して、快適なデジタル放送環境を提供することが可能となる。
【００３３】
【発明の効果】
本発明を用いる事により、放送電波の欠落が発生した際に、その欠落部位をダウンロードするのに必要な時間を予想して、欠落したデータをダウンロードする時間がかかる場合には、まず、データの再生をデータのダウンロードしている間に遅くし、それでも放送が途切れそうな場合は、もとの受信データと異なるビットレートを持つダウンロードデータを用いて欠落データを補完し、それでも放送が途切れそうな場合は、データが欠落した部分にノイズデータを入れて視聴者に途切れないデジタル放送を提供することが可能となるので、視聴者に快適なデジタル放送環境を提供することが可能となる。
【図面の簡単な説明】
【図１】本発明を用いるデジタル放送の全体構成図。
【図２】本発明によるデジタル放送補完方法を用いた放送システムの機能構成図。
【図３】ＴＳパケットの詳細図。
【図４】第１の実施例におけるデータ補完プラットフォームの構成図。
【図５】第１の実施例におけるデータ補完プラットフォームのフローチャート。
【図６】コンテンツ配信局とデータ補完プラットフォームのシーケンス図。
【図７】第２の実施例におけるデータ補完プラットフォームの構成図。
【図８】第２の実施例におけるデータ補完プラットフォームのフローチャート。
【図９】受信端末の表示画面を示す図。
【図１０】コンテンツのエンコードに関するフローチャート。
【図１１】コンテンツのエンコードに関するフローチャート。
【図１２】デコーダの構成。
【図１３】電波伝播強度を示す式（秦式）を示す図。
【図１４】音楽データのヘッダ定義を示す図。
【図１５】第３の実施例におけるデータ補完プラットフォームのフローチャート。
【符号の説明】
１００…コンテンツ配信局、１１０…移動体、１２０…地上波デジタル放送局、１５０…コンテンツデータ、２０１…移動体受信端末、２１７…スピーカ、
４０１，７５１…データ欠落検出装置、４０２，７５３…欠落データ取得時間推定装置、４０３…データ取得装置、４０４，７５６…ノイズデータ発生装置、
４０５，７５７…データ補完装置、７５２…ビットレート検出装置、７５４…ダウンロードビットレート算出装置、７５５…データ取得装置、１１０５…データ補完プラットフォーム。

Claims (6)

1. 送信局から放送されたデジタル放送波を受信して所望のデータを出力するデジタル放送受信端末において、
   前記受信端末は、
   デジタル放送のコンテンツデータが欠落したことを検出するデータ欠落検出装置と、
   通信機器を経由して送信局から欠落したコンテンツデータを取得する装置と、前記取得したコンテンツデータと、放送で取得したコンテンツデータをマージする装置と
   を備えたことを特徴とするデジタル放送受信端末。
2. データ放送の送信局から放送されたデジタル放送波を受信し、所望のデータを出力するデジタル放送受信端末におけるデジタル放送受信方法において、
   デジタル放送のデータが欠落したことを検出するデータ欠落検出処理と、
   データの欠落が発生した場合には、通信機器を経由して送信局から欠落したデータを取得する処理と、
   該取得したデータと、放送で取得したデータをマージして再生する処理を備えたこと
   を特徴とするデジタル放送受信方法。
3. 請求項１に記載のデジタル放送受信端末において、
   データの欠落を検出した時点から欠落したデータが本来再生を開始される時点までのデータ再生速度を遅くし、データ送信局に該欠落データを要求してデータ送信局からのデータの取得を行い、欠落したコンテンツデータを補完することを特徴とするデジタル放送受信端末。
4. 請求項１に記載のデジタル放送受信端末において、
   欠落したデータよりもビットレートの低く、該欠落データに該当するデータを送信局へ要求し、データ送信局から取得した低ビットレートデータにより欠落したデータを補完することを特徴とするデジタル放送受信端末。
5. 請求項１に記載のデジタル放送受信端末において、
   欠落したデータ個所に受信端末側でノイズデータを挿入することを特徴としたデジタル放送受信端末。
6. 請求項３または４のデジタル放送受信端末において、
   更に欠落したコンテンツデータを通信機器を用いて送信局から取得するために必要な時間を推定する推定装置を備え、
   該推定装置により、欠落したデータを送信局から取得するのに必要な時間が、欠落したデータの再生を開始するべき時間よりも長いと予測された場合は、端末側で生成したノイズデータを挿入することを特徴としたデジタル放送受信端末。

Images