(57)【要約】【課題】送受信間で放送時刻の同期を確保した上で、データ転送の平均レートを下げる。【解決手段】ＭＰＥＧ２−ＴＳのパケット各々にタイムスタンプを付けてＭＰＥＧ２−ＴＴＳ）を生成し（ＳＴ４１）、このＭＰＥＧ２−ＴＴＳを通信回線（インターネット等）に送出する（ＳＴ４５）。その際、元のＭＰＥＧ２−ＴＳにヌルパケットが含まれているときは、通信される前のＭＰＥＧ２−ＴＴＳから全てのヌルパケットが削除される。これによりデータ転送の平均レートが下がる。また、ＭＰＥＧ２−ＴＴＳの各パケットはタイムスタンプを持っているので、各パケットを本来のタイミングでデコードできるから、送受信間で放送時刻の同期を確保できる。【選択図】図４
2007104085.tif 000002
【特許請求の範囲】
【請求項１】
ＭＰＥＧエンコードされた第１のデータストリームのパケット各々にタイムスタンプを付けて第２のデータストリームを生成し、
前記第２のデータストリームを通信回線に送出するように構成されたデジタル放送方法。
【請求項２】
１種類以上の変調方法のいずれかで変調された複数の情報を合成して、前記第１のデータストリームが得られるように構成された請求項１に記載の方法。
【請求項３】
生成後の前記第２のデータストリームがヌルパケットを含む場合に、前記通信回線へ送出する前に前記第２のデータストリームから前記ヌルパケットを除去するように構成された請求項１または請求項２に記載の方法。
【請求項４】
前記タイムスタンプが付されたパケットを複数纏めたパケットグループに対して所定のパケットグループヘッダを付与することで、前記第２のデータストリームが構成され、
前記パケットグループヘッダが、前記通信回線に送出される前記第２のデータストリームに含まれる前記パケットグループの順番を示す情報を含むように構成された請求項１ないし請求項３のいずれか１項に記載の方法。
【請求項５】
前記パケットグループヘッダが、前記パックグループのタイムスタンプ情報および／または前記第２のデータストリームを送出する送信元の識別情報を含むように構成された請求項４に記載の方法。
【請求項６】
複数の前記パケットグループ各々に対してエラー訂正情報が付加されるように構成された請求項４または請求項５に記載の方法。
【請求項７】
ＭＰＥＧエンコードされた第１のデータストリームのパケット各々にタイムスタンプを付けて生成された第２のデータストリームを受け取り、
前記パケット各々に付された前記タイムスタンプの時系列に沿って、受け取った前記第２のデータストリームのパケットを配列し、
配列された前記第２のデータストリームのパケットを、前記第１のデータストリームに対応したフォーマットへ変換するように構成されたデジタル放送のデータ処理方法。
【請求項８】
受け取った前記第２のデータストリームは、前記タイムスタンプが付されたパケットを複数纏めたパケットグループに対して所定のパケットグループヘッダを付与した構成を持ち、
前記パケットグループヘッダが、前記第２のデータストリームに含まれる前記パケットグループの順番を示す情報を含む場合において、
前記パケットグループの順番を示す情報に従った順番で、前記第２のデータストリームを前記第１のデータストリームに対応したフォーマットへ変換するように構成された請求項７に記載の方法。
【請求項９】
前記第２のデータストリームのパケットを前記第１のデータストリームに対応したフォーマットへ変換する際に、前記パケットを一旦バッファリングする場合において、
前記第２のデータストリームのパケットをバッファに格納し、このバッファに対する前記パケットの占有量を調べ、
前記占有量が予め定めた規定範囲を下回るときは前記バッファから前記パケットを読み出すペースを遅くし、
前記占有量が前記規定範囲を上回るときは前記バッファから前記パケットを読み出すペースを早くし、
前記占有量が前記規定範囲内にあるときは前記バッファから前記パケットを所定のペースで読み出すように構成された請求項７または請求項８に記載の方法。
【請求項１０】
前記占有量が前記規定範囲内にあるときに前記バッファから前記パケットを所定の基準クロックで読み出す場合において、前記占有量が減少傾向にあるときは前記基準クロックを遅くし、前記占有量が増加傾向にあるときは前記基準クロックを早くするように構成された請求項９に記載の方法。
【請求項１１】
ＭＰＥＧエンコードされた第１のデータストリームのパケット各々にタイムスタンプを付けて生成された第２のデータストリームを通信回線から受け取る手段と、
前記パケット各々に付された前記タイムスタンプの時系列に沿って、受け取った前記第２のデータストリームのパケットを配列する手段と、
配列された前記第２のデータストリームのパケットを、前記第１のデータストリームと同じフォーマットのデータストリームへ変換する手段を備えたデジタル放送の受信装置。
【請求項１２】
前記第１のデータストリームと同じフォーマットでエンコードされたデジタル放送ストリームを受信するデジタルチューナ系と、
前記変換する手段からの、前記第１のデータストリームと同じフォーマットのデータストリームと、前記デジタルチューナ系からの、前記第１のデータストリームと同じフォーマットでエンコードされたデジタル放送ストリームとのいずれか一方あるいは双方を受け取り、受け取ったデータストリームをデコードするデコーダをさらに備えた請求項１１に記載の装置。
【請求項１３】
受け取った前記第２のデータストリームは、前記タイムスタンプが付されたパケットを複数纏めたパケットグループに対して所定のパケットグループヘッダを付与した構成を持ち、前記パケットグループヘッダが、前記第２のデータストリームに含まれる前記パケットグループの順番を示す情報を含む場合において、
前記パケットグループの順番を示す情報に従った順番で、前記第２のデータストリームを前記第１のデータストリームに対応したフォーマットへ変換する手段をさらに備えた請求項１１または請求項１２に記載の装置。
【請求項１４】
前記第２のデータストリームのパケットを前記第１のデータストリームに対応したフォーマットへ変換する際に、前記パケットを一旦バッファリングするバッファと、
前記バッファに対する前記パケットの占有量を調べ、前記占有量が予め定めた規定範囲を下回るときは前記バッファから前記パケットを読み出すペースを遅くし、前記占有量が前記規定範囲を上回るときは前記バッファから前記パケットを読み出すペースを早くし、前記占有量が前記規定範囲内にあるときは前記バッファから前記パケットを所定のペースで読み出す手段をさらに備えた請求項１１ないし請求項１３のいずれか１項に記載の装置。
【請求項１５】
前記占有量が前記規定範囲内にあるときに前記バッファから前記パケットを所定の基準クロックで読み出す場合において、前記占有量が減少傾向にあるときは前記基準クロックを遅くし、前記占有量が増加傾向にあるときは前記基準クロックを早くする手段をさらに備えた請求項１４に記載の装置。
【請求項１６】
請求項１ないし請求項６のいずれか１項に記載の方法を実施する手段を備えた送信設備。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、デジタル情報パケットを通信回線を介して放送する方法および装置に関する。特に、高転送レートを要する動画情報（ＭＰＥＧ２−ＴＳ等）のパケットをインターネットプロトコル（ＩＰ：Internet Protocol）を用いてネットワーク経由で放送するＩＰ放送時刻同期システムに関する。
【背景技術】
【０００２】
近年、テレビジョン等の放送方式はデジタル化（地上デジタル、衛星デジタル等）が進んでいる。デジタル放送では、映像と音声を多重化したＭＰＥＧ２−ＴＳ（Transport Stream）が使用されている。ＴＶ放送として電波で送信する場合には、ＭＰＥＧ２−ＴＳにはＰＣＲ（program clock reference）が付加されており、ＭＰＥＧ２−ＴＳは定レートで信号が送られてくる。そのため、受信機側では送受間の同期が可能となり、受信機側で送信データより速くあるいは遅く再生されるのを防いでいる。
【０００３】
これに対し、ネットワークでＭＰＥＧ２−ＴＳを送信する場合は、定レートで信号を送受することが必ずしも保証されないため、放映時間にずれが生じる可能性がある。その対応策として、例えば送信側で破棄されたパケットの数情報を送信し、受信側で破棄されたパケット個数分を生成／再生することが考えられる（特許文献１参照）。
【０００４】
一方、ＭＰＥＧ２−ＴＳのハイビジョン放送（高精細動画情報）は必要な転送レートが高く（例えば２４Ｍｂｐｓ以上）、ネットワーク（インターネット等の通信回線）を介して放送するには荷が重い。その対応策として、ＭＰＥＧ２−ＴＳからコンテンツに直接関係ない情報（ヌルパケット等）を削除して、実質的な平均レートを下げることが考えられる（特許文献２参照）。
【特許文献１】特開２０００−１８７９４０
【特許文献２】特開２００３−１１５８０７
【発明の開示】
【発明が解決しようとする課題】
【０００５】
特許文献１では、受信側で破棄したパケット個数分の生成／再生をしないと送受信間で放送時刻の同期がとれない恐れがある。この生成／再生処理が受信側の負担になる。また、特許文献２では無効階層のヌルパケットのみを削除しており、送信されるパケットの平均レートを下げる効果が薄い。
【０００６】
この発明の課題の１つは、受信側で破棄パケットを生成／再生するといった処理が必要でなく、かつデータ転送の平均レートを効果的に下げることができる（通信回線を用いた）デジタル放送方法およびその装置を提供することである。
【課題を解決するための手段】
【０００７】
この発明の一実施の形態に係るデジタル放送方法では、ＭＰＥＧエンコードされた第１のデータストリーム（ＭＰＥＧ２−ＴＳ）のパケット各々にタイムスタンプを付けて第２のデータストリーム（ＭＰＥＧ２−ＴＴＳ）を生成し（図４のＳＴ４１）、この第２のデータストリーム（ＭＰＥＧ２−ＴＴＳ）を通信回線（２００）に送出する（ＳＴ４５）ようにしている。
【発明の効果】
【０００８】
通信回線を介して送られてきたパケットを受信する側は、送信側で破棄されたパケット（ヌルパケット）を生成／再生するといった処理が必要でなく（かつヌルパケットを入れて送信する必要がないので）、通信回線でのデータ転送の平均レートを効果的に下げることができる。さらに受信側でストリームの正確な再生が可能である。
【発明を実施するための最良の形態】
【０００９】
ネットワークでＭＰＥＧ２−ＴＳを送信する場合は、定レートで信号を送受することは必ずしも保証されないため、放映時間にずれが生じる可能性がある。この問題を解決する手段として、この発明の一実施の形態では、ＭＰＥＧ２−ＴＳの各パケットにタイムスタンプを付加した、ＭＰＥＧ２−ＴＴＳ（Time-stamped Transport Stream）を使用する。ただし、ＭＰＥＧ２−ＴＴＳは１パケットサイズが大きくなるという欠点がある（例えば４バイトのタイムスタンプを１８８バイトのＴＳパケットに付加すると１９２バイトになる）。また、ＭＰＥＧ２−ＴＴＳの形態をとっていても、依然として受信している機器に内蔵されているクロックを基準として再生が行なわれる。そのため、基準クロックの誤差等により放映時間に差が出て、最悪、受信側エンコーダのバッファモデルが崩れて再生映像が破綻することも考えられる。この発明の一実施の形態では、以下に述べる方法により上記の問題に対処している。
【００１０】
図１は、この発明の一実施の形態に係るＩＰ放送時刻同期システムを説明する図である。このシステム構成は、大きくいって、送信側１００と受信側３００に分かれる。まず、送信側１００で、通常放送に使われているＭＰＥＧ２−ＴＳからＭＰＥＧ２−ＴＴＳへの変換を行う。この時、「タイムスタンプの付加」が行われる。すなわち、デジタル放送復調器１１０から出力されるＭＰＥＧ２−ＴＳのデータストリーム中の各パケット（図２（ａ）または図８（ａ）参照）それぞれに、ＴＴＳ化処理部１２０において、タイムスタンプが付与される（図２（ｂ）のｔ１，ｔ２，…または図８（ｂ）のＴＴＳ参照）。
【００１１】
ここで、元となるＭＰＥＧ２−ＴＳには、放送局等で元の映像からエンコードされるときに、再生タイミングを調整するための、映像等は含まれてないパケット（以下Nullパケット）が挿入されている（図２（ａ）（ｂ）または図８（ａ）（ｂ）参照）。さらに、地上デジタル放送では、変調方式としてＱＰＳＫ、１６ＱＡＭ、６４ＱＡＭのいずれかを選択できるようにするため、実際の伝送信号にはNullパケットが挿入されている。このため、ヌルパケット除去部１３０にて、受信処理において必要のないNullパケットを取る処理を行う（図２（ｃ）または図８（ｃ）参照）。
【００１２】
このように除去対象となるNullパケットは、変調処理によって生じるものだけでなく、エンコード処理によって再生タイミングを調整するために挿入されているNullパケットも対象とすることが可能である。つまり、送信前のＭＰＥＧ２−ＴＴＳ中の全てのヌルパケットを除去可能である。ヌルパケット除去部１３０に入る前のＭＰＥＧ２−ＴＴＳには既にタイムスタンプは付加されているため、再生タイミングを計るための映像データが含まれないパケットが無くなったとしても、再生に支障はなく、またこれによりネットワークに流すデータ量を減らすことが出来る（図８の例では３２．５Ｍｂｐｓのレートを平均１８Ｍｂｐｓに減らしている）。
【００１３】
このヌルパケット除去処理の後、Network I/F１４０から、ＩＰパケットにパッキングされたパケット（図８（ｄ）参照）がネットワーク（インターネット等の通信回線）２００へ送出される。
【００１４】
一般的にいって、ネットワークを介して送られたパケットは、等間隔できれいに届くことは少ない。そのため、受信機側３００では、それらパケット（通常はＩＰパケット）の、ジッタ、消失、順番の入れ替わり等を考慮する必要がある。このため、Network I/F３１０で受信したパケットを、まずネットワーク調整装置３２０に送る。
【００１５】
ネットワーク調整装置３２０は、ある程度パケットを貯めるバッファメモリ３２２を持つ。このバッファメモリに一旦貯めることにより、送受信過程等で派生したジッタを吸収できる。受信されたＭＰＥＧ２−ＴＴＳ中のパケットの消失、入れ替わりは、RTP/RTCP（RFC1889）等のプロトコルで検出することができる。パケットの入れ替わりが検出されたときは、各パケットまたはそのグループ毎のヘッダにつけられたシーケンス番号（図１０参照）により、正しい順序に戻すことができる（図５を参照して後述）。
【００１６】
また、パケットの消失を訂正したい場合には、シーケンス番号（図１０）によりどれがロスしたか特定し、順方向誤り訂正（ＦＥＣ：Forward Error Correction）等の冗長パケットから訂正を行う処理を入れることもできる（図１１を参照して後述）。これらの処理により、正しい値（正しいデータ内容）／正しい順番でＴＴＳパケットが取り出され、ＴＴＳデコーダ３３０へ送られる。
【００１７】
ＴＴＳデコーダ３３０では、ＴＴＳパケットのタイムスタンプ（図２（ｂ）（ｃ）のｔ１，ｔ２，…または図８（ｅ）のＴＴＳ）に従ってＴＳパケットをＭＰＥＧデコーダ３４０に送出すれば映像が再生されるが、このままでは受信機器３００の内蔵クロックを基準とするため、再生時間（タイミング）が送信側における実際の時間と異なる可能性がある。このため、この実施の形態では、ＴＴＳデコーダ３３０からＭＰＥＧデコーダ３４０に送るタイミングを変えることにより調整を行う（この調整の具体例は後述）。
【００１８】
図２はＭＰＥＧ２−ＴＳ（Transport Stream）をＭＰＥＧ２−ＴＴＳ（Time-stamped Transport Stream）に変換したあとにヌルパケットを除去する場合のパケット構造変化を例示している。図２（ａ）は図１のＴＴＳ化処理部１２０に対する入力例であり、図２（ｂ）はＴＴＳ化処理部１２０からの出力例またはヌルパケット除去部１３０に対する入力例である。また、図２（ｃ）はヌルパケット除去部１３０からの出力例（ＩＰパケットにパッキングする前）を例示している。ヌルパケット除去部１３０からの出力がネットワーク２００へ送出される前段階では、Network I/F３１０においてＩＰパケットへのパッキングがなされ、図８（ｄ）に例示されるようなＩＰパケット列（全てのヌルパケットが除去され、その分平均レートが下がっている）がネットワーク２００へ送出される。
【００１９】
図３は、この発明の他の実施の形態に係るＩＰ放送時刻同期システムを説明する図である。図１のシステムとは送信側１００ａの構成が異なっている。送信されるデータの構成が図１と図３では異なるので、図３の受信機側３００ａの動作は図１と同じではないが、受信機側のブロック構成は図１と図３で変わらない。図３の構成では、映像信号エンコーダ（ＴＳ多重部）１１１ａからの出力に、ＳＩ信号再多重器１２ａにおいて、サービス情報（ＳＩ：Service Information）が再度多重化される。再多重器１２ａでは、伝送速度の異なる複数ポートの入力ストリームから、セグメント構造による階層伝送に適した固定の伝送速度で、１つの出力ストリームが生成される。生成されたストリームには、リードソロモン符号化部等の外符号誤り訂正符号化部（図示せず）で、パリティが付加される。
【００２０】
その後、階層伝送を行なう場合には、階層分離部１１３ａにおいて階層情報の指定に沿って入力信号が階層分離され、分離された各階層（最大３系統）の信号が、階層変調器１１４ａ〜１１６ａへそれぞれ入力される。これらの階層変調器１１４ａ〜１１６ａでは、それぞれの入力信号に対して、以下の並列処理（３種類の階層変調：ＱＰＳＫ、１６ＱＡＭ、６４ＱＡＭ）が行われる。すなわち、この並列処理において、エネルギ拡散、インターリーブ等による階層毎の遅延を調整するための遅延補正、外符号（リードソロモンＲＳ符号）の性能を引き出すためのバイトインターリーブ、内符号（畳み込み符号）符号化、内符号の性能を引き出すためのビットインターリーブ等の処理が施される。そして、キャリア変調されたあと、階層合成部１１７ａで階層合成される。
【００２１】
階層合成部１１７ａで階層合成された信号（ＭＰＥＧ２−ＴＳ）は、移動受信性能、対マルチパス性能等を確保するための時間インターリーブ部（図示せず）および周波数インターリーブ部（図示せず）に入力される。そうして得られたＭＰＥＧ２−ＴＳは、変調部１１８ａで所定の変調を受けてオンエアされ、および／またはＴＴＳ化処理部１２０〜ネットワークインターフェイス部１４０を介して通信回線（インターネット等）２００に送出される。
【００２２】
図４は、ＭＰＥＧ２−ＴＳをＭＰＥＧ２−ＴＴＳに変換して出力する手順の一例を説明するフローチャート図である。この変換処理は、図１または図３のＴＴＳ化処理部１２０内のファームウエアにより実行できる。すなわち、ＴＴＳ化処理部１２０にＭＰＥＧ２−ＴＳ（図８（ａ）の１８８バイトＴＳ１〜ＴＳ１４参照）が入力されると（ステップＳＴ４０）、ＴＴＳ化処理部１２０の入口に着いたときのタイムスタンプ（図８（ｂ）の４バイトＴＴＳ参照）が、ＭＰＥＧ２−ＴＳのパケットに付けられる（ステップＳＴ４１）。
【００２３】
続いて、タイムスタンプが付けられたＴＳのヘッダが読み取られ（ステップＳＴ４２）、この「タイムスタンプが付けられたＴＳヘッダ」中のパケットＩＤ（ＰＩＤ）がチェックされる（ステップＳＴ４３）。ここで、ＰＩＤがヌルパケットを意味する“ＰＩＤ＝１ＦＦＦ”であったなら（ステップＳＴ４３イエス）、そのパケット（ＴＴＳパケット）はヌルパケットであるので破棄され（ステップＳＴ４４）、ステップＳＴ４０に戻る。一方、ＰＩＤがヌルパケットを意味する“ＰＩＤ＝１ＦＦＦ”でないときは（ステップＳＴ４３ノー）、そのパケット（ＴＴＳパケット）は有効な情報を含むパケットであるのでＭＰＥＧ２−ＴＴＳのパケットとして出力し（ステップＳＴ４５）、ステップＳＴ４０に戻る。
【００２４】
以上のようにして、ヌルパケットを含んでいたタイムスタンプ付きＭＰＥＧ２−ＴＴＳのデータストリーム（図８（ｂ））から全てのヌルパケット分が取り除かれ（図８（ｃ））、ＩＰパケットにパッキングされたＭＰＥＧ２−ＴＴＳのデータストリーム（図８（ｄ））がネットワークインターフェイス部１４０を介して通信回線（インターネット等）２００に送出される。
【００２５】
ネットワークインターフェイス部１４０から通信回線（インターネット等）２００に送出されるＭＰＥＧ２−ＴＴＳのデータストリームは、所定数のタイムスタンプ付きＴＳパケット（ＴＴＳパケット）を纏めたパケットグループにヘッダを付したＲＴＰ（Real-time Transport Protocol）パケットを持つように構成できる。
【００２６】
図１０は、このＲＴＰパケットのデータ構造の一例を説明する図である。このＲＴＰパケットのヘッダは、このデータ構造を規定する規格バージョンの情報と、パディングと、拡張情報と、ＣＳＲＣ（Contributing Source）数と、マーカと、ペイロードタイプと、シーケンス番号と、タイムスタンプと、同期送信元識別子を含んで構成されている。ここで、シーケンス番号はそのＲＴＰパケットの送信側での元の順番を示している。タイムスタンプはそのＲＴＰパケットが生成されたときの時間（あるいはタイミング）を示している。同期送信元識別子は、そのＲＴＰパケットの送信元を特定するもので、受信機側で再生同期すべき相手（送信元）はこ、の識別子で特定される。
【００２７】
図１１は、ＲＴＰパケットに対して用いられるＦＥＣ（Forward Error Correction：順方向誤り訂正）の一例を説明する図である。図１０のような構成を持つ複数のＲＰＴパケット群はインターリーブされ、それにエラー訂正パケットが付される。送信側では連続していたシーケンス番号が受信機側で欠番していた場合、通信過程で何らかの情報欠落が生じたものと推定される。この場合、エラー訂正パケットを用いて欠落のあったＲＴＰパケットの箇所を訂正し、欠番のないデータ転送を実現する（このエラー訂正に失敗した場合は、通信をやり直すか、情報欠落に起因するブロックノイズ等を不問にして情報受信を行なう）。なおＦＥＣの処理は、このシステムとしては必須ではない。
【００２８】
図９は、上記のような（シーケンス番号で本来の順番が分かっている）ＲＴＰパケット群を含むＭＰＥＧ２−ＴＴＳがネットワーク調整システム３２０に入力されると、どのようにＴＴＳパケットが再配列されて出力されるかを例示している。
【００２９】
図５は、受信したＭＰＥＧ２−ＴＴＳのパケットの順番を正規の順番に適宜修正し、受信側でパケットを正規の順序で出力する手順の一例を説明するフローチャート図である。図１または図３のネットワークインターフェイス部３１０で受信されたＭＰＥＧ２−ＴＴＳのパケットは、ジッタ吸収のため、バッファメモリ３２２に一旦格納される（ステップＳＴ５１）。その後、バッファメモリ３２２からＲＴＰの１パケット（図９のｔ１付きＴＳ１等、あるいは図１０のＴＴＳ参照）がネットワーク調整システム３２０に戻される（ステップＳＴ５２）。
【００３０】
なお、ＲＴＰパケットは、バッファメモリ３２２に入力されてくるが、そのバッファからシーケンス番号を検査して、順番に並んでいなかったら、並べ替える処理を行なう。ここでは、バッファメモリ３２２からＲＴＰのヘッダを読み込み、その中のシーケンス番号に基づいて並べ替えを行っている。すなわち、バッファメモリ３２２から戻ってきたＲＴＰパケットのヘッダにはシーケンス番号（図１０）の情報（図９の例ではＲＴＰの＃１、＃３、＃２）が書き込まれている。このシーケンス番号が続き番号であれば（ステップＳＴ５３イエス）、順番が狂っていないと判定し、ネットワーク調整システム３２０はそのときのＴＴＳパケットをＴＴＳデコード部３３０へ出力して（ステップＳＴ５４）、ステップＳＴ５２に戻る。
【００３１】
上記シーケンス番号が続き番号でなければ（ステップＳＴ５３ノー）、順番が狂っていると判定し、ネットワーク調整システム３２０はそのときのＲＴＰパケットのシーケンス番号を図示しないワークメモリの保留エリアに記録する（ステップＳＴ５５）。例えば、直前に出力したパケットのシーケンス番号が＃１であったところ、今回のシーケンス番号が＃３であれば、順番が狂っていると判定される。この場合、保留エリア（図示せず）に抜けたシーケンス番号（ここでは＃２）の情報が記録されておれば（ＳＴ５６イエス）、その抜けたシーケンス番号に該当するパケットをバッファメモリ３２２から読み込んで（ステップＳＴ５７）、ネットワーク調整システム３２０はそのときのＴＴＳパケットをＴＴＳデコード部３３０へ出力して（ステップＳＴ５４）、ステップＳＴ５２に戻る。
【００３２】
保留エリア（図示せず）に抜けたシーケンス番号（ここでは＃２）の情報が記録されていないときは（ＳＴ５６ノー）、パケットバッファ３３２に格納されるパケット（シーケンス番号を検査するＲＴＰパケット）の数が規定値に達しているかどうかチェックする（規定値は例えばバッファ満杯の状態に対応）。規定値に達していないときは（ステップＳＴ５８ノー）、格納したＲＴＰパケットの数を計数しているカウンタ（図示せず）を＋１カウントアップし、ステップＳＴ５２に戻って、別のＲＴＰパケットを読み込む。規定値に達しているときは（ステップＳＴ５８イエス）、そのときのシーケンス番号を消失パケットとして図示しないワークメモリに記録し（ステップＳＴ６０）、格納したＲＴＰパケットの数を計数している上記カウンタ（図示せず）をリセットする（ステップＳＴ６１）。そして、シーケンス番号を＋１インクリメントしてから（ステップＳＴ６２）ステップＳＴ５６に戻る。
【００３３】
図６は、受信側でのクロック調整手順の一例を説明するフローチャート図である。まず、バッファ３３２の半分程度ＴＴＳパケットを貯め（ステップＳＴ７０）、ある既定時間待ってから（ステップＳＴ７１）、現在のバッファ３３２の占有量の情報を取得する（ステップＳＴ７２）。最初は、現在の内蔵クロック（図示せず）を基準にタイムスタンプ通りＭＰＥＧデコーダ３４０へＴＳパケットを送出する。その後、ある時間内にバッファメモリ３２２内のＴＴＳパケット量に変化が殆どなければ（ステップＳＴ７３の範囲内）、所定のクロック増減処理を行なうか（ステップＳＴ８０）、この処理を行わずに現状のクロックで送出を続ける。
【００３４】
ある時間内にバッファメモリ３２２内のＴＴＳパケット量に変化がある場合、現在のバッファ３３２の占有量が予め定めた規定範囲を下回る（バッファが枯渇する危険あり）ときは、バッファ３３２からパケットを読み出すペースが遅くなるように基準クロックを遅くする（ステップＳＴ７４）。一方、前記占有量が前記規定範囲を上回る（バッファがオーバーフローする危険あり）ときは、バッファ３３２からパケットを読み出すペースが早くなるように基準クロックをを早くする（ステップＳＴ７５）。前記占有量が前記規定範囲内にあるときは前記バッファから前記パケットを所定のペースで読み出す（ＳＴ８０）。
【００３５】
図７は、受信側でのクロック調整手順の他例を説明するフローチャート図である。まず、現在と過去のバッファ使用量から、その使用傾向が調べられる（ステップＳＴ８１）。その結果、バッファ３３２の占有量がある時間内に増加傾向にある場合は、自分の内蔵クロックが遅いと判断し、クロックを引き上げた上で（ステップＳＴ８５）タイムスタンプ通りに送出を続ける。また、バッファ３３２を占有するパケット量が決められた上限値を超えた場合は、直ちにクロックを引き上げる（図６のステップＳＴ７５）。
【００３６】
逆に、バッファ３３２の占有量がある時間内に減少傾向にある場合は、自分のクロックが速いと判断し、クロックを引き下げた上で（ステップＳＴ８４）タイムスタンプ通りに送出を続ける。また、バッファ３３２を占有するパケット量が決められた下限値を下回る場合は、直ちにクロックを引き下げる（図６のステップＳＴ７４）。
【００３７】
このようにすることにより、（ネットワーク２００から受信機側３００が受け取るＭＰＥＧ２−ＴＴＳのデータ受信ペースが一定していなくても）平均的に再生時間を一定に保つことができる。
【００３８】
なお、クロックの変化量は、増加・減少傾向の度合の大きさにより、あるいは閾値を超えた場合で変化を付けても良いし、それぞれ固定値でもよい。また、図６のＳＴ７３あるいは図７のＳＴ８３における判定の方法は、前述したように、傾向と閾値の両方を用いてもよいし、どちらか片方のみを用いてもよい。またこのクロック変更後の値は、番組またはチャンネルが変わったときに、使い続けてもいいし、初期値に戻してもよい。
【００３９】
実際のクロック制御の方法としては、バッファ３３２の占有量が閾値を超えた場合は、内蔵のクロックを早く、逆にバッファ３３２の占有量が閾値を下回った場合は内蔵クロックを遅くすることでバッファ量を制御することが可能となる。このバッファ占有量をコントロールすることで、実際には送信側でタイムスタンプをつけるために使ったクロックと受信側のクロックが非常に長い時定数を持ったＰＬＬ（Phase-Locked Loop）動作と同等の処理をしていることになる。
【００４０】
これ以降の処理は、通常の地上デジタル受信機と同じため、追加の形でネットワークと電波の両用の受信装置を実現することが出来る。
【００４１】
図１２は、送信側における処理に伴う転送レート変化と、受信側における処理に伴う転送レート変化の一例を説明する図である。送信側では初め３２．５Ｍｂｐｓもあった重たいＭＰＥＧ２−ＴＳも、ＭＰＥＧ２−ＴＴＳ化の後全てのヌルパケットを抜くことで、平均転送レートを１８Ｍｂｐｓ程度（あるいはそれ以下）に下げることができる。その後ネットワーク通信過程でのデータ消失等（パケットロス）に対処する場合にはＲＴＰパケットのインターリーブと順方向誤り訂正処理（ＦＥＣ）を行う。この処理により若干転送レートが増える（１８Ｍｂｐｓ＋α）が、元の転送レート（３２．５Ｍｂｐｓ）と比較すれば不問にできる。なおＦＥＣの処理は、このシステムとしては必須ではないので、図１２においてＦＥＣの処理を行うことは任意である。
【００４２】
受信側では、送信側で抜いたヌルパケットの生成／再生処理は不要なので（ＴＴＳパケット各々に自分のタイムスタンプがあるから）、受信側では高レート（３２．５Ｍｂｐｓ）処理は不要となっている。
【００４３】
図１３はネットワークジッタを低減する処理を説明する概念図である。また、図１４はクロックリカバリ処理を行なう構成例を説明する図である。ネットワーク２００を介して送られてくるＭＰＥＧ２−ＴＴＳのパケットがジッタにより本来の時間間隔でなく図１３の下段のようになってしまっても、図１４のＴＴＳバッファ（あるいは、図１、図３のバッファメモリ３２２および／またはパケットバッファ３３２）に一旦格納してからジッタのないクロックで読み出すことで、図１３の上段に示すように、本来の時間間隔を取り戻すことができる。
【００４４】
なお、図１４のＴＴＳバッファは図１あるいは図３のＴＴＳパケットバッファ３３２に対応している。図１あるいは図３のクロック３３４に対応するクロックとして、図１４では２７ＭＨｚクロックを採用している。図７の基準クロックを早くする処理（ＳＴ８５）はこの２７ＭＨｚクロックのカウンタ値にオフセットをかけてカウントアップを早くすることで実行できる。また、図７の基準クロックを遅くする処理（ＳＴ８４）はこの２７ＭＨｚクロックのカウンタ値に（カウントアップを早くする場合とは反対方向の）オフセットをかけてカウントアップを遅くすることで実行できる。
【００４５】
［図１または図３の構成の特徴］
１．送信側と受信側で都度調整を行わなくても、破綻なく再生を行うことができるＩＰ放送システム；
２．余分なデータを抜くことにより、転送レートを下げられるＩＰ放送システム；
３．ＩＰと通常の電波の両方が受けられる受信装置。
【００４６】
［この発明の実施による効果］
１）受信機のクロックを調整することにより、破綻なく再生を行うことができる；
２）受信側が独立して調整を行うため、送信側は調整および制御のためのやり取りを都度行わなくてよい；
３）送信（放送局）側で、データを間引くことにより、ネットワーク上のトラフィックを下げられ、かつ画質等の劣化はない；
４）ＩＰ放送でも、現行の電波による放送と同じ映像データを扱えるため、受信機を共用できる。
【００４７】
（実施の形態による効果）
この発明の一実施の形態に係るデジタル放送方法では、ＭＰＥＧエンコードされた第１のデータストリーム（ＭＰＥＧ２−ＴＳ）のパケット各々にタイムスタンプを付けて第２のデータストリーム（ＭＰＥＧ２−ＴＴＳ）を生成し（図４のＳＴ４１）、この第２のデータストリーム（ＭＰＥＧ２−ＴＴＳ）を通信回線（２００）に送出する（ＳＴ４５）ようにしている。
【００４８】
送出されるパケットは各々がタイムスタンプを持っているので、受信側で受け取った第２のデータストリーム（ＭＰＥＧ２−ＴＴＳ）のパケットのタイミング（あるいは順序）が送信側からずれてしまったとしても、受信側では正しいタイミング（および正しい順序）でパケットを再配列することができる（図９参照）。そのため、受信側で第２のデータストリーム（ＭＰＥＧ２−ＴＴＳ）を送信側の元の第１のデータストリーム（ＭＰＥＧ２−ＴＳ）と同じものに正しいタイミング（および正しい順序）で復元できる。
【００４９】
従い、送信側でヌルパケットを削除してデータ転送レートを下げた場合に、受信側で削除されたヌルパケット分を生成／再生する処理をしなくても、送受信間で放送時刻の同期をとることができる。
【００５０】
すなわち、通信回線を介して送られてきたパケットを受信する側は、送信側で破棄されたパケット（ヌルパケット）を生成／再生するといった処理が必要でなく（かつヌルパケットを入れて送信する必要がないので）、通信回線でのデータ転送の平均レートを効果的に下げることができる。
【００５１】
なお、この発明は前述した実施の形態に限定されるものではなく、現在または将来の実施段階では、その時点で利用可能な技術に基づき、その要旨を逸脱しない範囲で種々に変形することが可能である。また、各実施形態は可能な限り適宜組み合わせて実施してもよく、その場合組み合わせた効果が得られる。さらに、上記実施形態には種々の段階の発明が含まれており、開示される複数の構成要件における適当な組み合わせにより種々の発明が抽出され得る。例えば、実施形態に示される全構成要件からいくつかの構成要件が削除されても、この構成要件が削除された構成が発明として抽出され得る。
【図面の簡単な説明】
【００５２】
【図１】この発明の一実施の形態に係るＩＰ放送時刻同期システムを説明する図。
【図２】ＭＰＥＧ２−ＴＳ（Transport Stream）をＭＰＥＧ２−ＴＴＳ（Time-stamped Transport Stream）に変換したあとにヌルパケットを除去する場合のパケット構造変化を説明する図。
【図３】この発明の他の実施の形態に係るＩＰ放送時刻同期システムを説明する図。
【図４】ＭＰＥＧ２−ＴＳをＭＰＥＧ２−ＴＴＳに変換して出力する手順の一例を説明するフローチャート図。
【図５】受信側でパケットを正規の順序で出力する手順の一例を説明するフローチャート図。
【図６】受信側でのクロック調整手順の一例を説明するフローチャート図。
【図７】受信側でのクロック調整手順の他例を説明するフローチャート図。
【図８】送信側および受信側における処理過程でＭＰＥＧ２−ＴＳ／ＭＰＥＧ２−ＴＴＳのデータフォーマットと平均転送レートがどのように変化するかの一例を説明する図。
【図９】ＲＴＰ（Real-time Transport Protocol）によるパケット入れ替え処理の一例を説明する図。
【図１０】ＲＴＰパケットのデータ構造の一例を説明する図。
【図１１】ＲＴＰパケットに対して用いられるＦＥＣ（Forward Error Correction：順方向誤り訂正）の一例を説明する図。
【図１２】送信側における処理に伴う転送レート変化と、受信側における処理に伴う転送レート変化の一例を説明する図。
【図１３】ネットワークジッタを低減する処理を説明する概念図。
【図１４】クロックリカバリ処理を行なう構成例を説明する図。
【符号の説明】
【００５３】
１００、１００ａ…送信側（ＩＰ伝送局）；２００…ネットワーク（インターネット等の通信回線）；３００、３００ａ…受信機側（デジタルＴＶ等）；１１０…デジタル放送復調器；１２０…ＴＴＳ化処理部；１３０…ヌルパケット除去部；１４０、３１０…ネットワークインターフェイス部；３２０…ネットワーク調整システム；３２２…バッファメモリ；３３０…ＴＴＳデコード部；３３２…ＴＴＳパケットバッファ；３３４…クロック発生部；３４０…ＭＰＥＧデコード部；３４２…標準バッファ；３５０…デジタルチューナ；３５２…デモジュレータ（復調器）；３６０…表示装置（ディスプレイ部）；３７０…スピーカ。
【図１】
2007104085.tif 000003
【図２】
2007104085.tif 000004
【図３】
2007104085.tif 000005
【図４】
2007104085.tif 000006
【図５】
2007104085.tif 000007
【図６】
2007104085.tif 000008
【図７】
2007104085.tif 000009
【図８】
2007104085.tif 000010
【図９】
2007104085.tif 000011
【図１０】
2007104085.tif 000012
【図１１】
2007104085.tif 000013
【図１２】
2007104085.tif 000014
【図１３】
2007104085.tif 000015
【図１４】
2007104085.tif 000016