JP2016072919A - 動画像処理方法、動画像処理システムおよび動画像処理プログラム - Google Patents

Abstract

【課題】最初の画像が表示されるまでの待ち時間を短縮することができる動画像処理方法、動画像処理システムおよび動画像処理プログラムの提供を図る。
【解決手段】送信装置１が、動画像データに基づいて生成した第１画像データＦ(1)をベストエフォート型の回線２を介して端末装置３に送信し、前記送信装置が、前記第１画像データを前記端末装置に送信した後でダミーデータＮＵＬＬを生成して前記端末装置に送信し、前記端末装置が、前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファ３２に格納し、前記受信バッファに格納した順に表示装置３４に表示する。
【選択図】図１７

Description

本明細書で言及する実施例は、動画像処理方法、動画像処理システムおよび動画像処理プログラムに関する。

近年、例えば、ＷｉＦｉ(Wireless Fidelity)等の無線ＬＡＮ(Local Area Network)を介して、地上デジタル放送等のテレビ放送をスマートフォンやタブレット等の端末装置に伝送(送信)するＷｉＦｉチューナが実用化されている。

さらに、このようなＷｉＦｉチューナは、無線ルータと一体化されてモバイルＷｉ−Ｆｉルータとしても製品化されている。また、伝送するテレビ放送は、地上デジタル放送に限定されるものではなく、ＢＳ(broadcasting satellite)放送やＣＳ(Communication Satellite)放送、或いは、ローカル放送等であってもよい。

なお、本明細書では、動画像処理装置の例としてＷｉＦｉチューナを説明するが、ＷｉＦｉを利用してデータを伝送するものに限定されず、他の様々な無線方式を利用するものであってもよく、さらに、有線によりデータを伝送するものであってもよい。

ところで、地上デジタル放送は、例えば、ＭＰＥＧ−２(Moving Picture Experts Group phase 2)によりデジタルデータ化されて放送されている。これを、一般的なテレビ受像機(例えば、専用テレビ)で視聴する場合、チューナにより放送波を受信してＭＰＥＧ−２のデジタルデータを取り出し、ＭＰＥＧ−２のデコーダ装置により、デコードして映像(ビデオ)および音声(オーディオ)の再生を行う。

具体的に、例えば、日本国におけるテレビ放送は、地上デジタル放送であれば１６Ｍｂｐｓ、また、ＢＳデジタル放送であれば２５Ｍｂｐｓというように、伝送するための帯域が確保されている。

一方、無線ＬＡＮも含め、インターネット系のネットワーク(回線)において、帯域を確保する技術も提案されているが、通常のデータ伝送は、ベストエフォート(Best Effort)型の回線を使用するものであり、伝送帯域(伝送能力)は保証されていない。

そのため、ネットワークの平均的な伝送能力が、例えば、地上デジタル放送の１６ＭｂｐｓやＢＳデジタル放送の２５Ｍｂｐｓよりも十分高ければ、無線ＬＡＮ等でも伝送は可能であるが、不十分であれば、伝送するのが困難となる。

そこで、例えば、ＷｉＦｉチューナ等の製品は、例えば、チューナにより放送波を受信してＭＰＥＧ−２のデジタルデータを取り出した後、再度、Ｈ．２６４等のさらに圧縮率の高い方式でエンコードし直して(トランスコードして)、テレビ放送の伝送を行う。

すなわち、ＷｉＦｉチューナ等の製品は、ＷｉＦｉ(無線ＬＡＮ)等のネットワークに十分に圧縮されたデータを伝送し、伝送先におけるタブレット等の端末装置でデコードして映像および音声の再生を行っている。

なお、ＭＰＥＧ−２のデジタルデータをＨ．２６４にトランスコードするのは、単なる一例であり、例えば、Ｈ．２６４による高画質のデータを、同じＨ．２６４の規格であっても、画質の低下は許容してより高い圧縮率でトランスコードする場合等もある。

ところで、従来、動画像処理方法、動画像処理システムおよび動画像処理プログラムとしては、様々なものが提案されている。

国際公開第０９／０１７０８４号 特開２０１０−０６２６２９号公報 特開２００８−２２７７１９号公報 特開２０１２−２２２５１１号公報

上述したように、例えば、ＷｉＦｉチューナは、伝送帯域が保証されていない回線を利用して地上デジタル放送等を端末装置に伝送するため、伝送帯域の変化に対しても安定してデータを伝送するために、送信および受信側に大容量のバッファが設けられている。

ところで、ユーザが、上述したＷｉＦｉチューナおよび無線ＬＡＮを介して、端末装置により地上デジタル放送等を視聴する場合、表示開始の遅れが大きな問題となっている。この表示開始の遅れは、例えば、デジタル放送のチャンネルの切り替えに要する時間だけでなく、送信および受信側における大容量バッファに起因して生じている。その結果、ユーザは、例えば、チャンネルの切り替え操作を行う度に、視聴を長時間待たされることにもなっている。

一実施形態によれば、送信装置が、動画像データに基づいて生成した第１画像データをベストエフォート型の回線を介して端末装置に送信する動画像処理方法が提供される。前記送信装置は、前記第１画像データを前記端末装置に送信した後でダミーデータを生成して前記端末装置に送信する。前記端末装置は、前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファに格納し、前記受信バッファに格納した順に表示装置に表示する。

開示の動画像処理方法、動画像処理システムおよび動画像処理プログラムは、最初の画像が表示されるまでの待ち時間を短縮することができるという効果を奏する。

図１は、動画像処理装置が適用される動画像処理システムの一例を模式的に示す図である。 図２は、図１に示す動画像処理システムの一例およびその動作を説明するための図である。 図３は、図２に示す動画像処理システムにおけるネットワークの伝送能力とデータ量の推移を説明するための図である。 図４は、関連技術の動画像処理装置の一例におけるトランスコーダおよびストリームの一例を示す図である。 図５は、図４に示すトランスコーダにおけるマルチプレクサ部の一例を示すブロック図である。 図６は、図４および図５に示すトランスコーダを適用した場合におけるチャンネル切り替え時の動作を説明するための図(その１)である。 図７は、図４および図５に示すトランスコーダを適用した場合におけるチャンネル切り替え時の動作を説明するための図(その２)である。 図８は、図６および図７に示すチャンネル切り替え時におけるデータ量の推移を説明するための図である。 図９は、図４および図５に示すトランスコーダの全体制御部による全体制御処理の一例を説明するためのフローチャートである。 図１０は、図４および図５に示すトランスコーダのデコーダ部によるビデオデコード処理の一例を説明するためのフローチャートである。 図１１は、図４および図５に示すトランスコーダのデコーダ部によるオーディオデコード処理の一例を説明するためのフローチャートである。 図１２は、図４および図５に示すトランスコーダのエンコーダ部によるビデオトランスコード処理の一例を説明するためのフローチャートである。 図１３は、図４および図５に示すトランスコーダのエンコーダ部によるオーディオトランスコード処理の一例を説明するためのフローチャートである。 図１４は、図４および図５に示すトランスコーダにおけるマルチプレクサ部による多重化処理の一例を説明するためのフローチャートである。 図１５は、本実施例に係る動画像処理システム(動画像処理装置)におけるトランスコーダおよびストリームの一例を示す図である。 図１６は、図１５に示すトランスコーダにおけるマルチプレクサ部の一例を示すブロック図である。 図１７は、図１５および図１６に示すトランスコーダを適用した場合におけるチャンネル切り替え時の動作を説明するための図である。 図１８は、図１７に示すチャンネル切り替え時におけるデータ量の推移を説明するための図である。 図１９は、図１５および図１６に示すトランスコーダのデコーダ部によるビデオデコード処理の一例を説明するためのフローチャートである。 図２０は、図１５および図１６に示すトランスコーダのエンコーダ部によるビデオトランスコード処理の一例を説明するためのフローチャートである。 図２１は、図１５および図１６に示すトランスコーダにおけるマルチプレクサ部による多重化処理の一例を説明するためのフローチャートである。

まず、本実施例の動画像処理方法、動画像処理システムおよび動画像処理プログラムを詳述する前に、図１〜図１４を参照して、動画像処理装置が適用される動画像処理システムの一例およびその動作、並びに、動画像処理方法、動画像処理システムおよび動画像処理プログラムの例およびその問題点を説明する。

図１は、動画像処理装置が適用される動画像処理システムの一例を模式的に示す図である。図１に示されるように、動画像処理システムは、ＷｉＦｉチューナ１(送信装置)，無線ＬＡＮ(ＷｉＦｉ)２，タブレット等の端末装置３，ルータ４およびアンテナ５を含む。

前述したように、ＷｉＦｉチューナ１は、例えば、アンテナ５を介してＢＳ放送や地上デジタル放送等を受信し、スマートフォンやタブレット等の端末装置３に送信する。すなわち、ＷｉＦｉチューナ１は、例えば、ＭＰＥＧ−２によりデジタルデータ化された放送を、より圧縮率の高いＨ．２６４等のデジタルデータにトランスコードし、ＷｉＦｉ等の無線ＬＡＮ２を介して端末装置３に送信する。

また、ＷｉＦｉチューナ１は、ルータ４を介してインターネット６に接続されており、例えば、ＹｏｕＴｕｂｅ（登録商標）やニコニコ動画（登録商標）等の動画サイトからも映像データをダウンロードして、端末装置３に送信できるようになっている。

ところで、ＷｉＦｉ等の無線ＬＡＮ(無線回線)２は、通常、ベストエフォート型の回線(ネットワーク)であり、伝送帯域は保証されておらず、回線の状態によって、伝送能力(伝送帯域)は、大きく変化する。

図２は、図１に示す動画像処理システムの一例およびその動作を説明するための図であり、図２(a)は、動画像処理システムの全体構成を示す。また、図２(b)は、図２(a)に示す動画像処理システムにおいて、安定して伝送(送信)できている状態の動作を説明するためのものであり、図２(c)は、ネットワークの伝送能力が一時的に下がった状態の動作を説明するためのものである。

図２(a)に示されるように、動画像処理システムにおいて、ＷｉＦｉチューナ１は、チューナ１１，トランスコーダ１２，送信バッファ１３およびＬＡＮ(送信)１４を含む。また、端末装置３は、ＬＡＮ(受信)３１，受信バッファ３２，デコーダ３３およびディスプレイ(表示装置)３４を含む。

チューナ１１は、例えば、アンテナ５を介してＢＳ放送や地上デジタル放送等を受信し、例えば、ＭＰＥＧ−２によりデジタルデータ化された放送を再生してトランスコーダ１２に出力する。

トランスコーダ１２は、チューナ１１からのＭＰＥＧ−２のデジタルデータを、例えば、より圧縮率の高いＨ．２６４等のデジタルデータにトランスコードして送信バッファ１３に出力する。

送信バッファ１３は、無線ＬＡＮ(ネットワーク)２の伝送能力が一時的に下がってトランスコーダ１２から一定のビットレートで入力するデータを伝送しきれない場合に、ネットワーク２の伝送能力が回復するまでデータを一時的に溜めておくためのものである。

ＬＡＮ(送信)１４は、送信バッファ１３からのデータを、ネットワーク２を介して端末装置３のＬＡＮ(受信)３１に送信するためのもので、例えば、ルータ４を介してインターネット(６)からも映像データをダウンロードして送信できるようになっている。なお、ＬＡＮ(受信)３１は、例えば、送受信可能なＷｉＦｉ等の無線ＬＡＮ装置の受信機能をしようしてデータを受け取っている様子を示す。

受信バッファ３２は、一定時間分のデータを溜めておくことができ、ネットワーク２の伝送能力が一時的に下がってデータが伝送されなくなった場合でも、一定時間は、映像および音声の再生が続けられるようにするためのものである。そして、この一定時間の間にネットワーク２の伝送能力が回復してデータが伝送さるようになれば、映像および音声が途切れることなく再生を継続することになる。

デコーダ３３は、受信バッファ３２からのデータ(例えば、Ｈ．２６４等のデジタルデータ)を受け取って映像および音声をデコードし、映像をディスプレイ３４に表示させると共に、音声をスピーカ(図示しない)から出力させる。

ここで、受信バッファ３２は、例えば、パーソナルコンピュータ(ＰＣ)でＹｏｕＴｕｂｅ（登録商標）等の動画サイトからも映像データをダウンロードして視聴する場合、円滑に再生されるように、最初に一定のバッファリングを行うのと同様のものである。

ただし、ネットワークが十分な伝送能力を持たず、バッファリングしたデータを再生しきる間に次のデータの充填が間に合わない場合でも、動画サイト等であれば、バッファの再充填処理が行われて再生される。すなわち、バッファのデータが枯渇して再生が止まった場合でも、その停止した画像の続きから再生される。

これは、動画サイトによるサービスでは、コンテンツが予めサーバ側に蓄積されており、ＰＣ側へのデータ伝送が滞った場合、単に、サーバからのデータ伝送を止めておき、ネットワークが回復した段階で、続きからデータ伝送を再開するだけでよいからである。

これに対して、ＷｉＦｉチューナ１のような用途では、データ伝送が滞った場合でも、チューナ１１からのＴＶ放送のデータは流れ込み続け、トランスコーダ１２によるデータも生成され続ける。そのため、例えば、ＹｏｕＴｕｂｅ（登録商標）等の動画サイトのサービスのように、単に、データ伝送を止めるといった単純な対応では問題が生じることになる。

仮に、トランスコーダ１２によるトランスコード処理を一時的に停止させて対応した場合、データ伝送が回復してトランスコード処理を再開しても、その間の実際の時間的な途切れが発生することになる。そのため、このような途切れの発生を極力回避するために、送信側(ＷｉＦｉチューナ１)にも一定時間分のバッファ(送信バッファ１３)が設けられている。

まず、図２(b)に示されるように、安定して伝送できている状態(通常の運用状態)において、例えば、チューナ１１からのＭＰＥＧ−２のデジタルデータは、トランスコーダ１２によって、より圧縮率の高いＨ．２６４のデジタルデータにトランスコードされる。

さらに、トランスコーダ１２からのデジタルデータ(Ｈ．２６４)は、送信バッファ１３およびＬＡＮ(送信)１４を介してネットワーク２に出力される。ここで、通常の運用状態において、送信バッファ１３は、エンプティ(空)気味で動作している。

さらに、ネットワーク２からのデジタルデータ(Ｈ．２６４)は、ＬＡＮ(受信)３１および受信バッファ３２を介してデコーダ３３に入力され、デコードされた映像および音声がディスプレイ３４等から出力される。ここで、通常の運用状態において、受信バッファ３２は、フル(満)気味で動作している。

すなわち、図２(b)において、矢印のハッチング部分の幅が、データの伝送能力を示し、送信バッファ１３および受信バッファ３２におけるハッチング部分の領域が、バッファリング(格納)しているデータ量を示す。なお、送信バッファ１３および受信バッファ３２の全体(箱)の大きさが、データを格納できる最大バッファ量を示す。

これに対して、図２(c)に示されるように、ネットワーク２におけるデータ量およびＬＡＮ３１から受信バッファ３２へのデータ量が小さく(ハッチング部分の幅が細く)なる。このとき、送信バッファ１３に格納されるデータは増加し、逆に、受信バッファ３２に格納されるデータは減少する。

図３は、図２に示す動画像処理システムにおけるネットワーク２の伝送能力とデータ量の推移を説明するための図であり、横軸に時間を取り、縦軸にデータ量を取って、各部の入出力データ量およびバッファ内のデータ量の推移の一例を示すものである。

図３は、ネットワーク(無線ＬＡＮ，回線)２が安定してデータを伝送できている状態(定常状態)の期間Ｐ１１ら、期間Ｐ１２でネットワークの伝送能力が一時的に下がった状態となり、その後、期間Ｐ１３で元の安定状態(過渡状態)に戻る様子を示している。

すなわち、期間Ｐ１１から期間Ｐ１２になり、ネットワーク２の伝送能力が一時的に下がった状態になると、トランスコーダ１２から単位時間あたりに出力されるデータ量よりもネットワークに送信できるデータ量(ＬＡＮ(送信)１４の送信データ量)が低くなる。

このとき、送信側(ＷｉＦｉチューナ１側)では、送信しきれないデータは、一時的に送信バッファ１３内に溜まっていくため、期間Ｐ１２において、送信バッファ１３内のデータ量は、徐々に増大する。

一方、受信側(端末装置３側)では、ネットワーク２から受信するデータ量(ＬＡＮ(受信)３１の受信データ量)が減るため、期間Ｐ１２において、受信バッファ３２内に溜められたデータ量は、徐々に減少する。

ここで、デコーダ３３が単位時間あたりに受け取る入力データ量が受信バッファ３２により維持されている間、デコーダ３３は、途切れることなく動画像を再生することが可能である。

なお、図３の例は、送信バッファ１３内のデータ量があふれ、或いは、受信バッファ３２内のデータ量が枯渇する前に、ネットワーク２の伝送能力が定常状態戻る場合を示している。

そのため、期間Ｐ１２から期間Ｐ１３になると、ネットワーク２の伝送能力が一時的に下がって転送できなかったデータが通常より多くネットワーク２で伝送され、送信バッファ１３内のデータ量は徐々に減少(受信バッファ３２内のデータ量は徐々に増加)する。

ここで、ネットワーク２は、ベストエフォート型の回線であるため、期間Ｐ１３におけるＬＡＮ(送信)１４の送信データ量およびＬＡＮ(受信)３１の受信データ量は、期間Ｐ１１におけるデータ量よりも大きい状態でデータ伝送を行う。

そして、送信バッファ１３および受信バッファ３２のデータ量が本来の状態に戻れば、ＬＡＮ(送信)１４およびＬＡＮ(受信)３１のデータ量も期間Ｐ１１の定常状態に戻ることになる。

なお、ネットワーク２の伝送能力の低下が長く続いて、受信バッファ３２のデータが枯渇した場合、デコーダ３３にはデコートする入力データが与えられず、再生(動画像)が途切れることになる。また、送信バッファ１３がフル(一定容量)になった場合も、トランスコーダ１２の動作を一時停止するかデータを破棄することになり、やはり再生時に動画像が途切れることになる。

このような動画像の途切れを避けるためには、受信バッファ３２および送信バッファ１３の容量を大きく設定するのが好ましい。ネットワークのトラフィックは運用状況によっても変わるが、通常、受信バッファ３２および送信バッファ１３には、例えば、数秒〜十数秒程度の動画像データを保持することができる容量を持たせている。

さらに、例えば、平均的な伝送能力の低下が長時間に及ぶような場合、バッファの容量がいくらあっても対応が難しいため、伝送能力に合わせてトランスコーダ１２の生成ビットレートを下げる等により対応することになる。

ただし、トランスコーダ１２での各種処理でバッファリングしている関係上、生成ビットレートの変更指示に対して実際のデータが減少するのは、例えば、数秒程度の時間が掛かるため、送信バッファ１３には、さらに、数秒程度以上の容量を持たせている。

ところで、近年、アナログＴＶ(テレビ放送)からデジタルＴＶになって、チャンネル切り替えに時間が掛かるようになったのが問題視されている。また、端末装置３によりネットワーク２を介してＷｉＦｉチューナ１からの放送を再生する場合には、さらに、上述した受信バッファ３２にデータが溜まるまで待たされることになる。

すなわち、端末装置３により第１チャンネルから第２チャンネルにチャンネルを切り替えた場合、例えば、受信バッファ３２のデータ量が一定量になるまで、新たな第２チャンネルの画像は表示されず、さらに、長時間待たされることになる。

具体的に、ＷｉＦｉチューナ１およびネットワーク２を介してデジタルＴＶを視聴する場合、端末装置３でチャンネルを切り替えると、例えば、通常のデジタルＴＶの切り替えに要する時間に加え、さらに、数秒〜十数秒程度の時間待たされることになる。

このチャンネル切り替え時に待たされる時間において、端末装置３のディスプレイ３４には、例えば、黒画面か表示され、或いは、チャンネル切り替え前の最後の画面が残ることになる。

或いは、砂時計のアニメーション等と共に、チャンネル切り替え中の表示や別途取得した切り替え先の番組情報等を表示するなどして、チャンネル切り替えの指示を受け付けたことをユーザにフィードバックするための画面を出すことも考えられる。しかしながら、この場合も、チャンネル切り替え後の画面表示までには、数秒〜十数秒程度の時間が掛かることになる。

図４は、関連技術の動画像処理装置の一例におけるトランスコーダおよびストリームの一例を示す図である。すなわち、図４(a)は、トランスコーダ１２の一例の詳細をチューナ１１および送信バッファ１３と共に示し、図４(b)は、トランスコーダ１２から出力されるストリーム(トランスポートストリーム：ＴＳ(Transport Stream))の一例を示す。

図４(a)に示されるように、トランスコーダ１２は、全体制御部(演算処理装置)１２１，デマルチプレクサ部(ＤＥＭＵＸ)１２２，デコーダ部１２３，メモリ１２４，エンコーダ部１２５およびマルチプレクサ部(ＭＵＸ)１２６を含む。

デマルチプレクサ部１２２は、ＰＳＩ(Program Specific Information)解析部２０を含み、デコーダ部１２３は、ビデオ処理部３１'およびオーディオ処理部３２'を含み、そして、エンコーダ部１２５は、ビデオ処理部５１およびオーディオ処理部５２を含む。

全体制御部１２１は、デマルチプレクサ部１２２およびデコーダ部１２３を制御し、例えば、チューナ１１からのＭＰＥＧ−２のデジタルデータから画像データおよび音声データを取り出してメモリ１２４に格納する。

また、全体制御部１２１は、エンコーダ部１２５およびマルチプレクサ部１２６を制御し、メモリ１２４から読み出した画像データおよび音声データを、例えば、ＭＰＥＧ−２よりも高圧縮率のＨ．２６４のデジタルデータに変換して送信バッファ１３に出力する。

すなわち、トランスコーダ１２は、例えば、チューナ１１からのＭＰＥＧ−２のデジタルデータを、ＷｉＦｉ等のネットワーク２でも伝送可能な、より高い圧縮率で圧縮したＨ．２６４等のデジタルデータに変換して、ネットワーク２に出力する。

図４(b)に示されるように、トランスコーダ１２からのストリームは、例えば、ＰＡＴ(Program Association Table)，ＰＭＴ(Program Map Table)，ＰＣＲ(Program Clock Reference)，ＰＡＴ，ＰＭＴ，ＰＣＲ，Ｉ-pic(Intra-coded Picture)，…と配列される。

さらに、ストリームは、例えば、…，ＰＣＲ，Ｂ-pic(Bidirectionally predictive-coded picture)，Ｂ-pic，Ｐ-pic(Predictive-coded picture)，Ｂ-pic，Ｂ-pic，…と配列される。

例えば、端末装置３が図４(b)に示されるデータを受け取る場合、先頭のＩ−ピクチャ(Ｉ-pic)が端末装置３のデコーダ３３に渡るのは、例えば、端末装置３の受信バッファ３２のサイズ(一定の容量)に相当するデータが伝送された後になる。

そのため、端末装置３によりチャンネルが切り替えられた場合、受信バッファ３２のデータ量が一定量になるまで、新たなチャンネルの画像(Ｉ−ピクチャ)はデコーダ３３に入力されず、新たなチャンネルの画像を表示するまで長時間待たされることになる。

ここで、例えば、第１チャンネルから第２チャンネルにチャンネルを切り替えたとき、受信バッファ３２には、先頭のＩ−ピクチャが格納された後、例えば、トランスコーダ１２により処理された第２チャンネルのデータが所定の転送レートで入力される。

すなわち、ＷｉＦｉチューナ１から端末装置３に対して、ベストエフォート型のネットワーク(回線)２を介してデータ伝送する場合であっても、例えば、ＭＰＥＧ−２をＨ，２６４に変換するトランスコーダ１２の出力に基づいたデータ量のデータが伝送される。

図５は、図４に示すトランスコーダにおけるマルチプレクサ部の一例を示すブロック図であり、マルチプレクサ部１２６を、エンコーダ部１２５と共に示すものである。図５に示されるように、マルチプレクサ部１２６は、ＦＩＦＯ(First-In First-Out)バッファ６１，６２、ＳＴＣ(System Time Clock)用カウンタ６３、ビデオＴＳ(Transport Stream)パケット生成部６４およびオーディオＴＳパケット生成部６５を含む。

さらに、マルチプレクサ部１２６は、ＰＡＴ生成部６６、ＰＭＴ生成部６７、ＰＣＲ生成部６８、ヌル(ＮＵＬＬ)パケット生成部６９、多重化対象決定部７０および多重化対象選択部７１を含む。

ビデオＴＳパケット生成部６４は、ビデオＴＳ用多重化時刻カウンタ６４０を含み、ビデオデータにおけるパケット分割，ＴＳヘッダ付加および多重化時刻算出を行う。オーディオＴＳパケット生成部６５は、オーディオＴＳ用多重化時刻カウンタ６５０を含み、オーディオデータにおけるパケット分割，ＴＳヘッダ付加および多重化時刻算出を行う。

ＰＡＴ生成部６６は、ＰＡＴ用多重化時刻カウンタ６６０を含み、ＰＭＴ生成部６７は、ＰＭＴ用多重化時刻カウンタ６７０を含む。また、ＰＣＲ生成部６８は、ＰＣＲ用多重化時刻カウンタ６８０を含み、ＮＵＬＬパケット生成部６９は、ヌルパケット用多重化時刻カウンタ６９０を含む。

ＳＴＣ用カウンタ６３は、多重化マスタークロックＣＬＫmmを受け取り、初期値の設定後、例えば、２７ＭＨｚの多重化マスタークロックＣＬＫmmでカウントアップするカウンタである。このＳＴＣ用カウンタ６３の出力信号は、各生成部の多重化時刻カウンタ６４０，６５０，…，６９０に入力され、システム時刻が与えられることになる。

ビデオＴＳパケット生成部６４は、ＦＩＦＯバッファ６１を介して入力されるエンコーダ１２５のビデオ処理部５１からのビデオＰＥＳ(Packetized Elementary Stream)データ(ＶＤ−ＰＥＳ)を受け取る。

ビデオＴＳ用多重化時刻カウンタ６４０は、ビデオ処理部５１から送られてくるビデオＰＥＳ単位の多重化開始時刻情報を初期値として、ビデオＰＥＳをＴＳパケットに分解した際の、ＴＳパケット毎の多重化開始時刻を管理する。これにより、ビデオＴＳパケット生成部６４により生成されるビデオＴＳ(ＶＤ−ＴＳ)は、カウントアップ量２７ＭＨｚを基準にして、ビデオのビットレートに対応した値になる。

具体的に、ビデオのビットレートが２０Ｍｂｐｓならば、ＴＳパケットのペイロードのデータ量は１８４ｂｙｔｅなので、１秒間に、ＴＳパケット数は、２０Ｍ［ｂｐｓ］÷（１８４［ｂｙｔｅ］×８［ｂｉｔ］）≒１３５８６．９［個］となる。

すなわち、２７ＭＨｚ単位で見た場合の各ＴＳパケットの周期は、２７Ｍ［Ｈｚ］÷１３５８６．９≒１９８７．２［ｃｙｃｌｅ］となり、これが、カウントアップ量となる。実際には、少数点以下を扱うのは難しいため、例えば、分子と分母の形で管理してカウントアップするが、本実施例との関連が薄いので、その詳細については省略する。

オーディオＴＳパケット生成部６５は、ＦＩＦＯバッファ６２を介して入力されるエンコーダ１２５のオーディオ処理部５２からのオーディオＰＥＳデータ(ＡＤ−ＰＥＳ)を受け取る。

オーディオＴＳ用多重化時刻カウンタ６５０は、オーディオ処理部５２から送られてくるオーディオＰＥＳ単位の多重化開始時刻情報を初期値として、オーディオＰＥＳをＴＳパケットに分解した際の、ＴＳパケット毎の多重化開始時刻を管理する。これにより、オーディオＴＳパケット生成部６５により生成されるオーディオＴＳ(ＡＤ−ＴＳ)は、カウントアップ量２７ＭＨｚを基準にして、オーディオのビットレートに対応した値になる。

なお、ＰＡＴ用多重化時刻カウンタ６６０，ＰＭＴ用多重化時刻カウンタ６７０およびＰＣＲ用多重化時刻カウンタ６８０は、初期値の設定後、各ＴＳパケットの挿入周期(規格上は１００ｍｓｅｃ以下)に応じた値がカウントアップ量となる。具体的に、９９ｍｓｅｃの周期ならば、９９ｍ［ｓｅｃ］÷（１／２７Ｍ［Ｈｚ］）≒２６７３０００［ｃｙｃｌｅ］ずつカウントアップすることになる。

また、ヌルパケット用多重化時刻カウンタ６９０は、初期値の設定後、ＴＳのシステムレートに応じた値がカウントアップ量となる。具体的に、ＴＳのシステムレートが２５Ｍｂｐｓならば、ＴＳパケットのデータ量は１８８ｂｙｔｅなので、２７Ｍ［Ｈｚ］÷（２５Ｍ［ｂｐｓ］÷（１８８［ｂｙｔｅ］×８［ｂｉｔ］））≒１６２４．３２［ｃｙｃｌｅ］ずつカウントアップすることになる。

そして、ビデオＴＳパケット生成部６４，オーディオＴＳパケット生成部６５，ＰＡＴ生成部６６，ＰＭＴ生成部６７，ＰＣＲ生成部６８およびＮＵＬＬパケット生成部６９は、それぞれのＴＳパケットを生成して多重化対象選択部７１に出力する。

このとき、各生成部６４〜６９は、それぞれの多重化時刻カウンタ６４０〜６９０により、対応するＴＳパケットの多重化開始時刻を算出する。なお、算出した多重化開始時刻は、ＳＴＣ用カウンタ６３から出力されるシステム時刻と比較され、システム時刻が多重化開始時刻以上になったら、多重化要求信号をバリッド(Valid：有効)にする。

多重化対象決定部７０は、ＮＵＬＬパケット生成部６９からの要求信号(多重化要求信号)がバリッドになる毎に、他の生成部(パケット生成部)６４〜６８からの要求信号をチェックする。

ここで、ＮＵＬＬパケット生成部６９からのバリッドの要求信号以外に、複数の生成部６４〜６８からの要求信号がバリッドであった場合には、優先順位に従って、どれか１つの生成部を選択し、多重化対象選択信号ＳＳmoにその生成部を選択するよう指定する。

なお、優先順位の一例としては、ＰＣＲ生成部６８が最優先で、以下、ＰＭＴ生成部６７，ＰＡＴ生成部６８等のＰＳＩ情報、そして、ビデオＴＳパケット生成部６４，オーディオＴＳパケット生成部６５の順番にすることが考えられる。

一方、ＮＵＬＬパケット生成部６９からの要求信号だけがバリッドで、他の生成部６４〜６８からの要求信号が全てインバリッド(Invalid：無効)の場合には、ＮＵＬＬパケット挿入モードであれば、多重化対象選択信号ＳＳmoとしてＮＵＬＬパケットを選択する。また、ＮＵＬＬパケット挿入モードでなければ、何も多重化しないため、多重化対象選択信号ＳＳmoとしてパケット無効を選択する。

そして、ＮＵＬＬパケット生成部６９以外の生成部６４〜６８の要求信号がバリッドであれば、その生成部のパケット出力を選択する。ここで、ＮＵＬＬパケット挿入モードか否かは、例えば、ＮＵＬＬパケット生成部６９に入力するＮＵＬＬパケット挿入モード指定信号ＭＳnpにより指定される。

多重化対象決定部７０により選択した結果は、多重化対象選択信号ＳＳmoとして多重化対象選択部７１に出力すると共に、選択した生成部６４〜６８に対する多重化アクノリッジ信号(ＡＣＫ)としてバリッドパルスを出力する。ただし、ＮＵＬＬパケット生成部６９に対しては、ＮＵＬＬパケットを選択したか否かに関わらず、多重化アクノリッジ信号としてバリッドパルスを出力する。

各生成部６４〜６８は、多重化アクノリッジ信号のバリッドパルスを受け取ったら、多重化要求信号をインバリッドにすると共に、その生成部の内部に設けられた多重化時刻カウンタ６４０〜６８０をカウントアップする。

なお、ＰＣＲ生成部６８は、ＴＳパケットのＰＣＲフィールドに正確な時刻を入れるために、多重化アクノリッジ信号のバリッドパルスを受け付けた時点で、ＳＴＣ用カウンタ６３からのシステム時刻の値を取り込み、ＴＳパケットのＰＣＲフィールドに書き込む。

図６および図７は、図４および図５に示すトランスコーダを適用した場合におけるチャンネル切り替え時の動作を説明するための図である。ここで、図６(a)は、端末装置(ＷｉＦｉチューナの受信装置)３のユーザが定常状態で視聴している状況を説明するための図である。

また、図６(b)は、ユーザがチャンネルの切り替えを指示した状況を説明するための図であり、図６(c)は、ユーザがチャンネルの切り替えを指示した直後の状況を説明するための図である。

さらに、図７(a)，図７(b)および図７(c)は、ユーザがチャンネルの切り替えを指示した直後の図６(c)に続く状況を説明するための図であり、図７(d)は、切り替え後のチャンネルにより、ユーザが定常状態で視聴している状況を説明するための図である。図６(a)〜図７(d)において、受信バッファ３２中の参照符号Ｆ(n)，Ｆ(n+1)，Ｆ(n+2)，Ｆ(n+3)，…，Ｆ(m)は、符号化された各映像フレームに対応するデータを示す。

以下の説明では、映像表示の時間順序と対応する符号化されたデータの順番は同じものとしているが、実際の符号化では、例えば、リオーダ処理が行われ映像表示の順番とストリームの順番が変わることもある。

まず、図６(a)に示されるように、ユーザが端末装置３のディスプレイ３４を介して、所定のチャンネル(第１チャンネル)のテレビ放送を視聴している場合、送信バッファ１３はエンプティ気味で動作し、受信バッファ３２は、フル気味で動作している。

すなわち、ディスプレイ３４には、受信バッファ３２から順に出力されてデコーダ３３でデコードされた映像(動画像)が表示され、ユーザは、第１チャンネルのテレビ放送を視聴することになる。

次に、図６(b)に示されるように、ユーザが端末装置３を操作して視聴するチャンネルを第１チャンネルから第２チャンネルに切り替える場合、ユーザは、例えば、端末装置３の制御部３５を介してチャンネル切り替えを指示する。

端末装置３において、制御部３５は、ＬＡＮ(受信)３１，受信バッファ３２およびディスプレイ３４を制御すると共に、ネットワーク(回線：ＷｉＦｉ)２を介してＷｉＦｉチューナ１の制御部を制御する。

すなわち、制御部３５は、端末装置３の各部に対するチャンネルの切り替え指示および受信バッファ３２に対するクリア指示を行い、さらに、ＷｉＦｉチューナ１の各部に対するチャンネル切り替えの指示および送信バッファ１３に対するクリア指示を行う。これを受けて、ＷｉＦｉチューナ１および端末装置３の各部は、第１チャンネルから第２チャンネルに切り替えた後のデータ処理の準備を開始する。

ここで、例えば、送信バッファ１３および受信バッファ３２のクリアを行わずに、チューナ１１だけ制御してチャンネルを切り替えた場合、例えば、受信バッファ３２中には、第１チャンネルに関する数秒〜数十秒分のデータが蓄えられている。

そのため、ユーザが第２チャンネルへの切り替えを指示したにも関わらず、切り替え前の第１チャンネルの放送が数秒〜数十秒程度ディスプレイに表示され、ユーザに対して切り替え指示が受け付けられなかったのではないかという心配を与えることになる。

そのため、ユーザが第１チャンネルから第２チャンネルへの切り替え指示を行った場合、送信バッファ１３および受信バッファ３２に格納されているデータを破棄し、新たなデータのバッファリングを行う。なお、ディスプレイ３４には、第２チャンネルの動画が表示されるまで、例えば、黒画面や第１チャンネルの最後の画面が表示される。

その後、送信バッファ１３および受信バッファ３２がクリアされ、チューナ１１によるチャンネル切り替えが行われると、新たな第２チャンネルに関するデータが処理され、送信バッファ１３および受信バッファ３２に格納される。

すなわち、図６(c)に示されるように、第２チャンネルに関するデータがチューナ１１からトランスコーダ１２に入力され、第２チャンネルのテレビ放送の最初の有効映像(画像)に対する符号化データＦ(1)がネットワーク２を介して受信バッファ３２に送られる。

ただし、受信バッファ３２は、この時点では空となっているため、符号化データＦ(1)が届いても、そのデータＦ(1)を直ちにデコーダ３３に出力せず、一定のデータ量を格納(バッファリング)した後、データＦ(1)をデコーダ３３に出力する。

すなわち、図７(a)〜図７(d)に示されるように、受信バッファ３２には、データＦ(1)に続く、データＦ(2)，Ｆ(3)，…，Ｆ(m)，…)が順に入力され、バッファリングされる。そして、受信バッファ３２に有効なデータが一定容量(例えば、数秒〜数十秒分：Ｆ(2)，Ｆ(3)，…，Ｆ(m)，Ｆ(m+1))だけ溜まると、データＦ(1)が押し出されて、デコーダ３３に入力される。

その後、図７(d)(図６(a))と同様に、ディスプレイ３４には、受信バッファ３２に一時的に格納されたデータＦ(2)，Ｆ(3)，…が順に出力されてデコーダ３３でデコードされ、ディスプレイ３４には、第２チャンネルのテレビ放送の映像が表示されることになる。

なお、図６(a)および図７(d)に示されるように、ユーザが端末装置３のディスプレイ３４を介して、所定のチャンネルのテレビ放送を視聴している場合、送信バッファ１３はエンプティ気味で動作し、受信バッファ３２は、フル気味で動作している。

図８は、図６および図７に示すチャンネル切り替え時におけるデータ量の推移を説明するための図であり、横軸に時間を取り、縦軸にデータ量を取って、各部の入出力データ量およびバッファ内のデータ量の推移の一例を示すものである。

すなわち、図８は、例えば、ユーザが端末装置３により第１チェンネルのテレビ放送を視聴している定常状態の期間Ｐ２１から、期間Ｐ２２で他の第２チャンネルに切り替えたときのデータ量の推移を示す。

ここで、図８における期間Ｐ２１は、前述した図６(a)に相当し、期間Ｐ２２は、図６(b)に相当し、期間Ｐ２３は、図６(c)および図７(a)〜図７(d)に相当し、そして、期間Ｐ２４は、図７(d)に相当する。

図８に示されるように、例えば、期間Ｐ２２(期間Ｐ２２の最初のタイミング)で、ユーザが端末装置３を操作して視聴するチャンネルを第１チャンネルから第２チャンネルに切り替えた場合、ユーザは、第２チャンネルの画像を直ちに確認することは困難である。

例えば、ユーザが第２チャンネルのテレビ放送を視聴できるようになるのは、チャンネル切り替えでバッファをクリアし、受信バッファ３２に一定のデータが溜まる期間Ｐ２３の後、期間Ｐ２４でデコーダ３３が動作を開始してからである。

例えば、チャンネルが切り替えられた場合、ある程度(数秒〜数十秒分)のデータが受信バッファ３２に溜まるまで、待たされ、それから、デコーダ３３にデータが入力されて動作が開始し、新たな第２チャンネルの内容がディスプレイ３４に表示される。

そのため、例えば、端末装置３を介してＷｉＦｉチューナ１によるテレビ放送を視聴するユーザは、デジタル放送になってチャンネル切り替えのレスポンスが遅くなったのに加え、受信バッファ３２等へのバッファリングのための時間だけ待たされることになる。

その結果、ユーザは、チャンネルの切り替え操作を行ってから、新たなチャンネルの放送を視聴できるまで、例えば、数秒〜数十秒程度待たされることになる。このような、ユーザの待たされ感を軽減するために、例えば、砂時計等のアイコンや、ＥＰＧ(Electronic program guide：電子番組表)等の情報を表示することも考えられるが、根本的な解決策とはなっていない。

また、明確な視聴したい番組がなくていくつかのチャンネルを切り替える、或いは、視聴している番組があってもＣＭ(Commercial Message)に切り替わった際に、他のチャンネルに興味を引く番組がないか確認するザッピングと呼ばれる行為がしばしば行われる。

このとき、チャンネル切り替えに要する時間が僅かであれば、次々にチャンネル切り替えを行って、軽快にザッピング等を行うことができる。しかしながら、上述したようなＷｉＦｉチューナによるテレビ放送の受信では、チャンネル切り替えのたびに数秒〜数十秒待たされることになる。

ところで、チャンネル切り替えの際に、切り替え先のチャンネルを視聴する意図が明確であれば、再生までにある程度の時間待たされても負担感は少ない。しかしながら、ザッピング等を行う場合、チャンネルの切り替えのたびに数秒〜数十秒待たされ、さらに、待たされた後のチャンネルでも興味のない内容が放送されていると、徒労感が大きく、ザッピングという行為自体が事実上困難となってしまう。

次に、図９〜図１４を参照して、図４および図５に示すトランスコーダにおける各処理(全体制御処理，ビデオデコード処理，オーディオデコード処理，ビデオトランスコード処理，オーディオトランスコード処理および多重化処理)の一例を説明する。

図９は、図４および図５に示すトランスコーダの全体制御部による全体制御処理の一例を説明するためのフローチャートである。図９に示されるように、全体制御部１２１による全体制御処理が開始すると、ステップＳＴ１０において、各部の内部状態初期化し、ステップＳＴ１１に進んで、デマルチプレクサ部１２２が動作を開始(ストリームの取り込みを開始)する。

さらに、ステップＳＴ１２に進んで、デマルチプレクサ部１２２のＰＳＩ解析処理部２０によるＰＳＩ解析処理の完了を待ち、ステップＳＴ１３に進んで、ビデオＰＩＤ(パケット識別子)が確定したか否かを判定する。

ステップＳＴ１３において、ビデオＰＩＤが確定した(YES)と判定すると、ステップＳＴ１７に進んで、デコーダ部１２３のビデオ処理部３１'によるビデオ処理を開始すると共に、マルチプレクサ部１２６の処理を開始してステップＳＴ１４に進む。また、ステップＳＴ１３において、ビデオＰＩＤが確定していない(NO)と判定すると、そのままステップＳＴ１４に進んで、オーディオＰＩＤが確定したか否かを判定する。

ステップＳＴ１４において、オーディオＰＩＤが確定した(YES)と判定すると、ステップＳＴ１８に進んで、デコーダ部１２３のオーディオ処理部３２'によるオーディオ処理を開始してステップＳＴ１５に進む。また、ステップＳＴ１４において、オーディオＰＩＤが確定していない(NO)と判定すると、そのままステップＳＴ１５に進んで、次のユーザによるアクションを待つ。

そして、ステップＳＴ１６に進んで、ユーザによるアクションがチャンネルの切り替えか否かを判定し、チャンネルの切り替えである(YES)と判定すると、ステップＳＴ１９に進んで、各処理部を強制的に停止し、ステップＳＴ１０に戻って同様の処理を行う。なお、ステップＳＴ１６において、ユーザによるアクションがチャンネルの切り替えではない(NO)と判定した場合、本実施例と関連が薄いので、その処理の説明は省略する。

図１０は、図４および図５に示すトランスコーダのデコーダ部によるビデオデコード処理の一例を説明するためのフローチャートである。図１０に示されるように、デコーダ部１２３(ビデオ処理部３１')によるビデオデコード処理が開始すると、ステップＳＴ２０において、ビデオ処理部３１'を初期化して内部状態の初期化を行い、ステップＳＴ２１に進む。

ステップＳＴ２１では、デマルチプレクサ部１２２からのビデオストリームの取り込みをチェックし、ステップＳＴ２２に進んで、１ピクチャ分のストリーム(データ)の取り込みが完了したか否かを判定する。

ステップＳＴ２２において、１ピクチャ分のストリームの取り込みが完了していない(NO)と判定すると、ステップＳＴ２１に戻ってチェックを行い、１ピクチャ分のストリームの取り込みが完了したと判定するまで、同様の処理を繰り返す。

また、ステップＳＴ２２において、１ピクチャ分のストリームの取り込みが完了した(YES)と判定すると、ステップＳＴ２３に進み、１ピクチャ分のストリームのデコード処理を実行する。さらに、ステップＳＴ２４に進んで、デコードしたピクチャがＩ−ピクチャだったか否かを判定する。

ステップＳＴ２４において、デコードしたピクチャがＩ−ピクチャではなかった(NO)と判定すると、ステップＳＴ２０に戻って同様の処理を繰り返し、Ｉ−ピクチャであった(YES)と判定すると、ステップＳＴ２５に進んで、ビデオ先頭発見フラグをセットする。

さらに、ステップＳＴ２６において、先頭のＩ−ピクチャのデコードした画像データを、エンコーダ部１２５に送ってトランスコード処理を開始した後、ステップＳＴ２７に進んで、ビデオストリームの取り込みチェックを行い、ステップＳＴ２８に進む。

ステップＳＴ２８では、前述したステップＳＴ２２と同様に、１ピクチャ分のストリームの取り込みが完了したか否かを判定する。ステップＳＴ２８において、１ピクチャ分のストリームの取り込みが完了していない(NO)と判定すると、ステップＳＴ２７に戻って同様の処理を繰り返し、また、１ピクチャ分のストリームの取り込みが完了した(YES)と判定すると、ステップＳＴ２９に進む。

ステップＳＴ２９において、１ピクチャ分のストリームのデコード処理を実行し、ステップＳＴ３０に進んで、デコードしたピクチャは、クローズドＢ−ピクチャ，Ｉ−ピクチャまたはＰ−ピクチャだったか否かを判定する。ここで、クローズドＢ−ピクチャ(Closed-B-Picture)は、前方に対する参照を行わないＢ−ピクチャである。

ステップＳＴ３０において、デコードしたピクチャがクローズドＢ−ピクチャ，Ｉ−ピクチャおよびＰ−ピクチャの何れでもなかったと判定する(NO)と、ステップＳＴ３１に進む。ステップＳＴ３１において、先頭のＩ−ピクチャのデコードした画像データを、エンコーダ部１２５に送ってトランスコード処理を実行し、ステップＳＴ２７に戻って同様の処理を繰り返す。

一方、ステップＳＴ３０で、デコードしたピクチャがクローズドＢ−ピクチャ，Ｉ−ピクチャまたはＰ−ピクチャであった(YES)と判定すると、ステップＳＴ３５に進む。ステップＳＴ３５において、デコードした画像データを、エンコーダ部１２５に送ってトランスコード処理を実行した後、ステップＳＴ３２に進んで、デマルチプレクサ部１２２からのビデオストリームの取り込みをチェックし、ステップＳＴ３３に進む。

ステップＳＴ３３において、１ピクチャ分のストリームの取り込みが完了していない(NO)と判定すると、ステップＳＴ３２に戻り、１ピクチャ分のストリームの取り込みが完了したと判定するまで、同様の処理を繰り返す。

また、ステップＳＴ３３において、１ピクチャ分のストリームの取り込みが完了した(YES)と判定すると、ステップＳＴ３４に進み、１ピクチャ分のストリームのデコード処理を実行する。さらに、前述したステップＳＴ３５に進んで同様の処理を繰り返し、ビデオデコード処理(ビデオトランスコード処理)を継続する。

図１１は、図４および図５に示すトランスコーダのデコーダ部によるオーディオデコード処理の一例を説明するためのフローチャートである。図１１に示されるように、デコーダ部１２３(オーディオ処理部３２')によるオーディオデコード処理が開始すると、ステップＳＴ４０において、オーディオ処理部３２'を初期化して内部状態の初期化を行い、ステップＳＴ４１に進む。

ステップＳＴ４１では、デマルチプレクサ部１２２からのオーディオストリームの取り込みをチェックし、ステップＳＴ４２に進んで、１ＡＡＵ(Audio Access Unit：オーディオ復号単位)分のストリーム(データ)の取り込みが完了したか否かを判定する。

ステップＳＴ４２において、１ＡＡＵ分のストリームの取り込みが完了していない(NO)と判定すると、ステップＳＴ４１に戻ってチェックを行い、１ＡＡＵ分のストリームの取り込みが完了したと判定するまで、同様の処理を繰り返す。

また、ステップＳＴ４２において、１ＡＡＵ分のストリームの取り込みが完了した(YES)と判定すると、ステップＳＴ４３に進み、ビデオ先頭発見フラグをチェックし、ステップＳＴ４４に進んで、ビデオ先頭が発見済みか否かを判定する。

ステップＳＴ４４において、ビデオ先頭が発見済みではない(NO)と判定すると、ステップＳＴ４７に進み、取り込んだ１ＡＡＵ分のデータを破棄して、ステップＳＴ４１に戻り、ビデオ先頭が発見済みであると判定されるまで同様の処理を繰り返す。

一方、ステップＳＴ４４で、ビデオ先頭が発見済みである(YES)と判定すると、ステップＳＴ４５に進み、１ＡＡＵ分のデコードを実行した後、ステップＳＴ４６に進んで、デコードした音声データをエンコーダ部１２５に送ってトランスコード処理を開始する。

さらに、ステップＳＴ４８に進んで、オーディオストリームの取り込みをチェックした後、ステップＳＴ４９において、１ＡＡＵ分のストリームの取り込みが完了したか否かを判定する。

ステップＳＴ４９において、１ＡＡＵ分のストリームの取り込みが完了していない(NO)と判定すると、ステップＳＴ４８に戻ってチェックを行い、１ＡＡＵ分のストリームの取り込みが完了したと判定するまで、同様の処理を繰り返す。

また、ステップＳＴ４９において、１ＡＡＵ分のストリームの取り込みが完了した(YES)と判定すると、ステップＳＴ５０に進み、１ＡＡＵ分のデコード処理を実行し、ステップＳＴ５１に進む。

ステップＳＴ５１では、デコードした音声データをエンコーダ部１２５に送ってトランスコード処理を実行し、さらに、前述したステップＳＴ４８に戻って、オーディオデコード処理(オーディオトランスコード処理)を継続する。

図１２は、図４および図５に示すトランスコーダのエンコーダ部によるビデオトランスコード処理の一例を説明するためのフローチャートである。図１２に示されるように、エンコーダ部１２５(ビデオ処理部５１)によるビデオトランスコード処理が開始すると、ステップＳＴ６０において、ビデオ処理部５１を初期化して内部状態の初期化を行い、ステップＳＴ６１に進む。

ステップＳＴ６１では、画像データをチェックし、ステップＳＴ６２に進んで、画像データがあるか否かを判定する。ステップＳＴ６２において、画像データがない(NO)と判定すると、ステップＳＴ６１に戻ってチェックを行い、画像データがあると判定するまで、同様の処理を繰り返す。

一方、ステップＳＴ６２において、画像データがある(YES)と判定すると、ステップＳＴ６３に進んで、画像データのビデオエンコード(トランスコード)を実行し、さらに、ステップＳＴ６４に進む。

ステップＳＴ６４では、トランスコードしたビデオストリームをマルチプレクサ部１２６に送った後、ステップＳＴ６１に戻って同様の処理を繰り返し、ビデオトランスコード処理を継続する。

図１３は、図４および図５に示すトランスコーダのエンコーダ部によるオーディオトランスコード処理の一例を説明するためのフローチャートである。図１３に示されるように、エンコーダ部１２５(オーディオ処理部５２)によるオーディオトランスコード処理が開始すると、ステップＳＴ７０において、オーディオ処理部５２を初期化して内部状態の初期化を行い、ステップＳＴ７１に進む。

ステップＳＴ７１では、音声データをチェックし、ステップＳＴ７２に進んで、音声データがあるか否かを判定する。ステップＳＴ７２において、音声データがない(NO)と判定すると、ステップＳＴ７１に戻ってチェックを行い、音声データがあると判定するまで、同様の処理を繰り返す。

一方、ステップＳＴ７２において、音声データがある(YES)と判定すると、ステップＳＴ７３に進んで、音声データのオーディオエンコード(トランスコード)を実行し、さらに、ステップＳＴ７４に進む。

ステップＳＴ７４では、トランスコードしたオーディオストリームをマルチプレクサ部１２６に送った後、ステップＳＴ７１に戻って同様の処理を繰り返し、オーディオトランスコード処理を継続する。

図１４は、図４および図５に示すトランスコーダにおけるマルチプレクサ部による多重化処理の一例を説明するためのフローチャートである。図１４に示されるように、マルチプレクサ部１２６による多重化処理が開始すると、ステップＳＴ８０において、ビデオ先頭発見フラグをチェックし、ステップＳＴ８１に進んで、ビデオ先頭が発見済みか否かを判定する。

ステップＳＴ８１において、ビデオ先頭が発見済みではない(NO)と判定すると、ステップＳＴ８０に戻り、ビデオ先頭が発見済みであると判定されるまで同様の処理を繰り返す。そして、ステップＳＴ８１において、ビデオ先頭が発見済みである(YES)と判定すると、ステップＳＴ８２に進み、トランスコード済みのデータをチェックした後、ステップＳＴ８３に進んで、データがあるか否かを判定する。

ステップＳＴ８３において、データがない(NO)と判定すると、ステップＳＴ８２に戻り、データがあると判定されるまで同様の処理を繰り返す。そして、ステップＳＴ８３において、データがある(YES)と判定すると、ステップＳＴ８４に進んで、ビデオのストリームデータか否かを判定する。

ステップＳＴ８４において、ビデオのストリームデータではない(NO)と判定すると、ステップＳＴ８７に進んで、トランスコード済みのデータを破棄した後、ステップＳＴ８２に戻り、同様の処理を繰り返す。

一方、ステップＳＴ８４で、ビデオのストリームデータである(YES)と判定すると、ステップＳＴ８５に進んで、先頭ピクチャのＰＴＳ(Presentation Time Stamp)およびＤＴＳ(Decode Time Stamp)を取り込み、先頭ピクチャの多重化開始時刻を計算する。さらに、ステップＳＴ８５において、計算された先頭ピクチャの多重化開始時刻をＳＴＣ(System Time Clock)にセットし、ＳＴＣ用カウンタ６３のカウントを開始する。

そして、ステップＳＴ８６に進んで、ＳＴＣに従ってビデオストリーム，オーディオストリームおよびＰＳＩ(Program Specific Information)ストリームの多重化を開始する。なお、ステップＳＴ８６以降の処理は、本実施例と関連が薄いので、その説明は省略する。

以下、動画像処理方法、動画像処理システムおよび動画像処理プログラムの実施例を、添付図面を参照して詳述する。図１５は、本実施例に係る動画像処理システム(動画像処理装置)におけるトランスコーダおよびストリームの一例を示す図である。すなわち、図１５(a)は、トランスコーダ１２の一実施例の詳細をチューナ１１および送信バッファ１３と共に示し、図１５(b)は、トランスコーダ１２から出力されるストリーム(トランスポートストリーム)の一例を示す。

図１５(a)と前述した図４(a)の比較から明らかなように、本実施例の動画像処理装置におけるトランスコーダ１２は、マルチプレクサ部(ＭＵＸ)１２６は、強制ＮＵＬＬ生成部(ダミーデータ生成部)６０を含む。

強制ＮＵＬＬ生成部６０は、例えば、チャンネルが切り替えられ、切り替え後のチャンネルの動画像データにおける先頭にＩ−ピクチャが生成された後、回線(ネットワーク)２の最大伝送能力に基づいてＮＵＬＬデータ(ダミーデータ)を強制的に生成する。なお、詳細は、後に詳述する。

なお、全体制御部１２１，デマルチプレクサ部(ＤＥＭＵＸ)１２２，デコーダ部１２３，メモリ１２４およびエンコーダ部１２５は、実質的に、それぞれ図４(a)を参照して説明したものに相当する。

すなわち、デマルチプレクサ部１２２は、ＰＳＩ解析部２０を含み、デコーダ部１２３は、ビデオ処理部３１'およびオーディオ処理部３２'を含み、そして、エンコーダ部１２５は、ビデオ処理部５１およびオーディオ処理部５２を含む。

全体制御部１２１は、デマルチプレクサ部１２２およびデコーダ部１２３を制御し、例えば、チューナ１１からのＭＰＥＧ−２のデジタルデータから画像データおよび音声データを取り出してメモリ１２４に格納する。

また、全体制御部１２１は、エンコーダ部１２５およびマルチプレクサ部１２６を制御し、メモリ１２４から読み出した画像データおよび音声データを、例えば、ＭＰＥＧ−２よりも高圧縮率のＨ．２６４のデジタルデータに変換して送信バッファ１３に出力する。

すなわち、トランスコーダ１２は、例えば、チューナ１１からのＭＰＥＧ−２のデジタルデータを、ＷｉＦｉ等のネットワーク２でも伝送可能な、より高い圧縮率で圧縮したＨ．２６４等のデジタルデータに変換して、ネットワーク２に出力する。

図１５(b)に示されるように、トランスコーダ１２からのストリームは、例えば、ＰＡＴ，ＰＭＴ，ＰＣＲ，ＰＡＴ，ＰＭＴ，ＰＣＲ，Ｉ-pic，ＰＣＲ，Ｐ-pic，…，Ｐ-pic，ＮＵＬＬ(ヌルデータ、ダミーデータ)，Ｉ-pic，Ｂ-pic，Ｂ-pic，…と配列される。

本実施例の動画像処理装置(トランスコーダ１２)は、例えば、マルチプレクサ部１２６に設けた強制ＮＵＬＬ生成部６０により、チャンネル切り替え後の先頭のＩ−ピクチャの後に、ＮＵＬＬパケット(ダミーデータ)を生成して出力する。

すなわち、図１５(b)に示されるように、トランスコーダ１２は、ＰＡＴ，ＰＭＴ，ＰＣＲを２回以上挿入して、受信側(端末装置３の(デコーダ３３)でＰＩＤ解析が正しく行われるようにしている。

ここで、トランスコーダ１２は、先頭のＩ−ピクチャ(先頭Ｉ−pic)を、ＤＴＳ＝ＰＴＳとしてリオーダなしで再生されるようにして出力する。すなわち、リオーダ処理を行うことにより、圧縮率を高くしてデータ量を低減することが可能であるが、本実施例では、端末装置３において、先頭Ｉ−picの画像を直ちに再生できるように、リオーダ処理は行わない。具体的に、ＰＣＲ(ＰＴＳ)として、先頭Ｉ−picの後、再生開始時刻に到達するようにしている。

すなわち、例えば、Ｈ．２６４等の動画圧縮では、圧縮効率を上げるために双予測(ＭＰＥＧでは、双方向予測と呼ばれる)技術が用いられる。そのため、各ピクチャは、圧縮率を向上させるためにリオーダ処理によって順番が入れ替えられ、その結果、圧縮データのピクチャの並び順と、表示の際のピクチャの並び順は必ずしも一致しない。

本実施例では、例えば、チャンネルを切り替えた後の先頭Ｉ-picによる画像を最短時間で表示させるため、多少の圧縮率が低下しても、リオーダ処理を適用せずに、デコーダ３３が先頭Ｉ-picを受け取ったら直ちにデコードして画像を表示できるようにしている。

さらに、先頭Ｉ-picのデータの後に、Ｉ-picを前参照するだけのＰ−ピクチャ(Ｐ-pic)を複数枚数挿入する。この挿入するＰ-picの枚数は、例えば、１秒分(３０ピクチャ)程度を目安として予め設定される。

なお、挿入するＰ-picの枚数は、例えば、そのシステムに適用される送信バッファ１３および受信バッファ３２の容量に応じて、容量が大きい場合には枚数を増加し、容量が小さい場合には枚数を減少するといった調整を行ってもよい。或いは、元ストリームのリオーダ枚数(Ｂ−ピクチャ(Ｂ-pic)の枚数)やＰＣＲとＩ-picのＰＴＳの差等に基づいて、挿入するＰ-picの枚数を調整することもできる。

そして、受信側(受信バッファ３２)の容量に相当するデータ分のＮＵＬＬパケットを挿入することで、に先頭Ｉ-picが受信バッファ３２からデコーダ３３速やかに渡るようにしている。

このように、図１５(b)に示されるように、本実施例のトランスコーダ１２では、トランスコードの開始時の先頭のＩ−ピクチャ(先頭Ｉ−pic)の後、前参照するだけのＰ−ピクチャを複数枚分挿入する。そして、強制ＮＵＬＬ生成部６０により生成されたＮＵＬＬパケットが、回線(ネットワーク)の最大伝送能力に基づいて端末装置３に伝送(送信)される。

これにより、端末装置３における受信バッファ３２は、ＮＵＬＬパケットにより埋められることになり、短時間で先頭のＩ−ピクチャのデータがデコーダ３３に入力され、端末装置３のディスプレイ３４には、短時間で画像が表示されることになる。

すなわち、例えば、図４(a)および図４(b)を参照して説明した動画像処理装置では、先頭のＩ−ピクチャ以後のデータ(ピクチャストリーム)は、設定ビットレートに従って生成される。

そのため、受信バッファ３２がフル(一定容量)になって先頭Ｉ-picがデコーダに送られるまで、受信バッファのサイズ(数秒〜数十秒)の時間を要するが、本実施例によれば、ＮＵＬＬパケットにより、受信バッファ３２を強制的にフル状態とすることができる。

これにより、先頭Ｉ-picが短時間でデコーダ３３に送られ、速やかに先頭Ｉ-picの表示が実現される。すなわち、最初の画像が表示されるまでの待ち時間を短縮することができる。

なお、２番目のＩ-pic以降は、通常通りにトランスコードされたデータが受信バッファ３２に溜まってからになる。そのため、２番目のＩ-pic以降の画像が表示されるまでには、受信バッファ３２のサイズに対応した時間を要するが、先頭のピクチャの表示がされているため、待たされている感は大幅に緩和される。

ここで、ディスプレイ３４に表示される画像は、例えば、切り替え後のチャンネルにおける放送の先頭Ｉ-pic(静止画)であるが、例えば、ザッピングを行う場合には、チャンネル切り替え後の静止画を確認すれば十分な場合が多いと考えられる。

さらに、本実施例の動画像処理装置(動画像処理システム)の適用は、端末装置３自体に対する新たな改良や変更を行わなくてもよいため、端末装置３は、そのまま使用することが可能となる。すなわち、本実施例によれば、端末装置の構成を変更することなく、最初の画像が表示されるまでの待ち時間を短縮することができる。

図１６は、図１５に示すトランスコーダにおけるマルチプレクサ部の一例を示すブロック図である。図１６と前述した図５の比較から明らかなように、本実施例におけるトランスコーダ１２は、オアゲート１２７を含む。

オアゲート１２７は、ＮＵＬＬパケット挿入モードか否かを指定するＮＵＬＬパケット挿入モード指定信号ＭＳnpと、ＮＵＬＬパケット強制挿入モードを指定するＮＵＬＬパケット強制挿入モード指定信号ＭＳicを受け取り、その論理和信号を出力する。

ここで、オアゲート１２７の出力信号は、ヌル(ＮＵＬＬ)パケット生成部６９に入力され、また、ＮＵＬＬパケット強制挿入モード指定信号ＭＳicは、ＳＴＣ用カウンタ６３'にも入力される。すなわち、ＳＴＣ用カウンタ６３'は、後に詳述するように、ＮＵＬＬパケット強制挿入モード指定信号ＭＳicに基づく高速モード機能を有している。

なお、ＦＩＦＯバッファ６１，６２、ビデオＴＳパケット生成部６４，オーディオＴＳパケット生成部６５およびＰＡＴ生成部６６の構成および動作は、図５を参照したのと同様であり，その説明は省略する。また、ＰＭＴ生成部６７，ＰＣＲ生成部６８，多重化対象決定部７０および多重化対象選択部７１の構成および動作も、図５を参照したのと同様であり，その説明は省略する。

本実施例のマルチプレクサ部１２６において、ＮＵＬＬパケット生成部６９は、ＮＵＬＬパケット強制挿入モード指定信号ＭＳicが入力された場合、ＮＵＬＬパケット挿入モード指定信号ＭＳnpに関わらず、ＮＵＬＬパケットを強制挿入するようになっている。なお、ＮＵＬＬパケット生成部６９の構成および動作自体は、図５を参照したのと同様である。

また、ＳＴＣ用カウンタ６３'には、高速モード機能が付加されており、強制ＮＵＬＬパケット挿入モードが指定(信号ＭＳicが入力)された場合、ＳＴＣ用カウンタ６３'は、通常の動作よりも高速の動作が可能な高速モードとなる。

すなわち、本実施例におけるＳＴＣ用カウンタ６３'には、例えば、１ずつカウントアップしてシステム時刻(ＳＴＣ：System Time Clock)を生成する通常モードと、予め設定された数(カウントアップ値)ずつカウントアップする高速モードを有している。

ここで、カウントアップ値の設定は、例えば、送信バッファ１３および受信バッファ３２の容量、並びに、先頭ピクチャおよび後続のスキップ(Skip-)Ｐ−ピクチャをどれくらいの時間で送り込むかに基づいて行われる。

具体的に、５秒分の時間に相当するデータを、１フレーム時間を３３ｍｓｅｃとして送信バッファ１３および受信バッファ３２に送り込む場合、５ｓｅｃ／３３ｍｓｅｃ≒１５１．５とり、カウントアップ値は、例えば、１５１．５等に設定すればよいことになる。

以上において、図１５および図１６に示すトランスコーダは、単なる例を示すものであり、本実施例が適用されるトランスコーダは、図１５および図１６に示すものに限定されず、様々な変形および変更が可能なのはいうまでもない。

図１７は、図１５および図１６に示すトランスコーダを適用した場合におけるチャンネル切り替え時の動作を説明するための図であり、前述した図７に相当するものである。なお、端末装置(ＷｉＦｉチューナの受信装置)３のユーザが定常状態で視聴している状況は、図６(a)を参照して説明したのと同様である。

さらに、ユーザがチャンネルの切り替えを指示した状況、並びに、ユーザがチャンネルの切り替えを指示した直後の状況も、図６(b)並びに図６(c)を参照して説明したのと同様である。

すなわち、図１７(a)，図１７(b)および図１７(c)は、本実施例の動画像処理装置(トランスコーダ)により、ユーザがチャンネルの切り替えを指示した直後の図６(c)に続く状況を説明するためのものである。なお、切り替え後のチャンネルにより、ユーザが定常状態で視聴している状況は、図７(d)を参照して説明したのと同様である。

図１７(a)〜図１７(c)において、受信バッファ３２中の参照符号Ｆ(1)，Ｆ(2)，Ｆ(3)は、符号化された各映像フレームに対応するデータを示し、ＮＵＬＬは、トランスポートストリームのヌルパケットを示す。

なお、Ｆ(1)は、例えば、ユーザが第１チャンネルから第２チャンネルへの切り替え指示を行った場合、切り替え後の第２チャンネルのテレビ放送の最初の有効映像(先頭のＩ−ピクチャ：先頭Ｉ-pic)に対する符号化データに対応する。

また、上述したように、本実施例では、切り替え後の第２チャンネルのテレビ放送の先頭Ｉ-picを、端末装置３のディスプレイ３４に短時間で表示可能とするために、先頭Ｉ-picに対してはリオーダ処理を行わないようになっている。

まず、前述した図６(c)のように、例えば、第２チャンネルのテレビ放送の先頭Ｉ-picに対する符号化データＦ(1)がネットワーク２を介して受信バッファ３２に送られる。その後、図１７(a)に示されように、トランスコーダ１２は、ヌルパケット(ダミーデータ)ＮＵＬＬを強制的に生成し、ネットワーク２を介して受信バッファ３２に伝送する。

なお、図１５(b)を参照して説明したように、トランスコーダ１２は、先頭Ｉ-pic(データＦ(1))の後に、例えば、端末装置３に対して、先頭Ｉ-picによる静止画の表示を継続するための複数のＰ-picを生成して受信バッファ３２に伝送している。

また、強制的に挿入するヌルパケットＮＵＬＬと共に、例えば、タイムスタンプを調整した音声パケットを、ネットワーク２を介して受信バッファ３２に伝送すれば、端末装置３(ディスプレイ３４)に静止画を表示している間、音声を出力することもできる。

次に、図１７(b)に示されるように、受信バッファ３２が、ヌルパケットＮＵＬＬにより満たされるようになると、先頭Ｉ-picのデータＦ(1)がデコーダ３３に押し出されることになる。

そして、図１７(c)に示されるように、例えば、デコーダ３３により、データＦ(1)の処理が済めば、ディスプレイ３４には、先頭Ｉ-picによる画像が表示され、ユーザは、その画像を確認することができる。なお、図１７(a)〜図１７(c)に示されるように、送信バッファ１３は、エンプティ(空)気味で動作している。

ここで、ヌルパケットＮＵＬＬの伝送量(送信量)は、例えば、ネットワーク２の最大伝送能力に基づいて設定される。すなわち、トランスコーダ１２が生成するヌルパケットＮＵＬＬは、通常通りにトランスコードされたデータよりもはるかに大きいため、受信バッファ３２は、ネットワーク２の最大伝送能力に応じた短時間でフル(満)の状態になる。

また、２番目のＩ-picのデータＦ(2)以降の画像が表示されるまでには、受信バッファ３２のサイズに対応した時間を要するが、先頭Ｉ-picによる画像(静止画)の表示がされているため、待たされている感は大幅に緩和される。

また、受信バッファ３２に蓄えられたヌルパケットＮＵＬＬは、デコーダ３３に入力されることになるが、デコーダ３３は、そのＮＵＬＬデータを単純に破棄するだけで、何ら問題を生じることはない。

さらに、チャンネル切り替え後の内容が、例えば、ＣＭ等で希望のものでなかった場合、数秒〜数十秒も待つことなく、短時間の内に、先頭Ｉ-picによる静止画を確認することができるため、ザッピング等も軽快に行うことができる。

図１８は、図１７に示すチャンネル切り替え時におけるデータ量の推移を説明するための図であり、横軸に時間を取り、縦軸にデータ量を取って、各部の入出力データ量およびバッファ内のデータ量の推移の一例を示すものである。

すなわち、図１８は、例えば、ユーザが端末装置３により第１チェンネルのテレビ放送を視聴している定常状態の期間Ｐ３１から、期間Ｐ３２で他の第２チャンネルに切り替えたときのデータ量の推移を示す。なお、図１８において、クロスハッチングは、ヌルパケットＮＵＬＬ(ダミーデータ)を示す。

ここで、図１８における期間Ｐ３１は、前述した図６(a)に相当し、期間Ｐ３２は、図６(b)に相当し、期間Ｐ３３は、図６(c)に相当し、期間Ｐ３４は、上述した図１７(a)および図１７(b)に相当し、そして、期間Ｐ３５は、図１７(c)に相当する。

図１８に示されるように、例えば、期間Ｐ３２(期間Ｐ３２の最初のタイミング)で、ユーザが端末装置３を操作して視聴するチャンネルを第１チャンネルから第２チャンネルに切り替えた場合、ユーザは、第２チャンネルの画像を直ちに確認することは困難である。

例えば、ユーザが第２チャンネルのテレビ放送を視聴できるようになるのは、チャンネル切り替えでバッファをクリアし、受信バッファ３２に一定のデータが溜まる期間Ｐ３３，Ｐ３４の後、期間Ｐ３５でデコーダ３３が動作を開始してからである。ここで、本実施例では、例えば、ヌルパケットＮＵＬＬにより、ネットワーク２の最大伝送能力に基づいて伝送量で受信バッファ３２にデータを溜めることができる。

すなわち、図８の例では、例えば、テレビ放送といった所定量で与えられるデータを、ピクチャ単位でトランスコードしてネットワーク２に出力するため、間欠的な動作となって受信バッファ３２にデータが溜まるには、数秒〜数十秒程度の時間を要する。

これに対して、図１８に示されるように、本実施例では、期間Ｐ３３で、先頭Ｉ-picおよび複数のＰ-pic等によるデータ伝送を行った後、第２チャンネルのデータ量が少なくても、ヌルパケットＮＵＬＬを使用して受信バッファ３２にデータを溜めることができる。

例えば、ネットワーク２の最大伝送能力(データ量)ＴＤmが、通常のストリームのデータ量の１０倍であれば、その最大伝送能力に基づいたヌルパケットＮＵＬＬを伝送することで、１／１０の時間で受信バッファ３２をフルとすることができる。

これにより、受信バッファ３２から先頭Ｉ-picのデータＦ(1)がデコーダ押し出され、ユーザは、短い待ち時間で先頭Ｉ-picによる画像を確認することができる。すなわち、図１８の期間Ｐ３３，Ｐ３４と、図８の期間Ｐ２３の比較から明らかなように、本実施例によれば、受信バッファ３２にデータが溜まるまでの時間を大幅に短縮することが可能なのが分かる。

以上において、本実施例におけるダミーデータとしては、トランスポートストリーム(ＴＳ)のＮＵＬＬパケットを始め、デコード対象外のＰＩＤを持ったＴＳパケット等のデコーダ３３によるデコード処理に影響を与えず破棄されるものであれば、何でもよい。また、上述した説明では、ＴＳパケットを使用しているが、デコーダ３３側の処理に影響を与えることなく破棄されるデータであれば、ＴＳパケットに限定されるものではない。

次に、図１９〜図２１を参照して、図１６に示すトランスコーダにおける各処理(ビデオデコード処理，ビデオトランスコード処理および多重化処理)の一例を説明する。なお、トランスコーダ１２における全体制御処理，デコーダ部１２３におけるオーディオデコード処理，エンコーダ部１２５におけるオーディオトランスコード処理は、それぞれ図９，図１１および図１３を参照して説明したのと同様であり、その説明は省略する。

図１９は、図１５および図１６に示すトランスコーダのデコーダ部によるビデオデコード処理の一例を説明するためのフローチャートであり、前述した図１０に対応するものである。

ここで、図１９と前述した図１０の比較から明らかなように、図１９において、ステップＳＴ２０〜ＳＴ２４およびステップＳＴ２７〜ＳＴ３５は、図１０と同様の処理を行うものである。

すなわち、図１９に示されるように、ステップＳＴ２４において、デコードしたピクチャがＩ−ピクチャであった(YES)と判定すると、図１０におけるステップＳＴ２５の代わりに、ステップＳＴ２００に進む。

ステップＳＴ２００において、ビデオ先頭発見フラグをセットし、先頭のＩ−ピクチャの本来のＰＴＳ，ＤＴＳを、内部レジスタorgＰＴＳ，orgＤＴＳに退避し(ＰＴＳ：＝orgＰＴＳ，ＤＴＳ：＝orgＤＴＳ)、ステップＳＴ２０１に進む。

ステップＳＴ２０１では、先頭のＩ−ピクチャの本来のＰＴＳ，ＤＴＳを、PreＴｉｍｅ分変更(タイムスタンプを変更)し、デコードした画像データをエンコーダ部１２５に送って、トランスコードを開始する(ＰＴＳ：ＤＴＳ：＝orgＰＴＳ−PreＴｉｍｅ)。

ここで、PreＴｉｍｅの値は、例えば、受信バッファ３２の容量から想定される遅延時間を考慮し、予めパラメータとしてレジスタに設定しておくのが好ましい。ただし、端末装置３から表示開始タイミング(先頭のＩ−ピクチャを表示するタイミング)を、ＷｉＦｉチューナ１(送信装置：トランスコーダ１２)へフィードバックするような仕組みを導入し、遅延量をキャリブレーションするようにしてもよい。

さらに、ステップＳＴ２０２に進んで、先頭のＩ−ピクチャのＰＴＳ，ＤＴＳを本来のＰＴＳ，ＤＴＳに戻し、デコードした画像データをエンコーダ部１２５に送って、トランスコードを実行し、ステップＳＴ２７に進む。なお、ステップＳＴ２７以降の処理は、図１０を参照して説明したのと同様である。

図２０は、図１５および図１６に示すトランスコーダのエンコーダ部によるビデオトランスコード処理の一例を説明するためのフローチャートであり、前述した図１２に対応するものである。

ここで、図２０と前述した図１２の比較から明らかなように、図２０において、ステップＳＴ６０およびＳＴ６１〜ＳＴ６４(ＳＴ６１'〜ＳＴ６４')は、図１２におけるステップＳＴ６０およびＳＴ６１〜ＳＴ６４と同様の処理を行うものである。

すなわち、図２０に示されるように、ステップＳＴ６４において、トランスコードしたビデオストリームをマルチプレクサ部１２６に送った後、ステップＳＴ６１に戻る代わりに、ステップＳＴ６００に進む。

ステップＳＴ６００では、ＰＴＳ，ＤＴＳを、addＴｉｍｅ：＝３３．３ｍｓｅｃ．として更新し(ＰＴＳ：＝ＤＴＳ：＝ＰＴＳ＋３３．３ｍｓｅｃ．，ｃｏｕｎｔ＝３３．３ｍｓｅｃ．)、ステップＳＴ６０１に進む。

ステップＳＴ６０１において、ＰＴＳ，ＤＴＳを更新し(offsetＴｉｍｅ：＝offsetＴｉｍｅ＋addＴｉｍｅ，ＰＴＳ：＝ＤＴＳ：＝ＰＴＳ＋offsetＴｉｍｅ)、ステップＳＴ６０２に進む。

ステップＳＴ６０２では、offsetＴｉｍｅ＜PreＴｉｍｅが成立するか否かを判定する。ステップＳＴ６０２において、offsetＴｉｍｅ＜PreＴｉｍｅが成立する(YES)と判定すると、ステップＳＴ６０３に進む。

ステップＳＴ６０３において、更新したＰＴＳ，ＤＴＳにてskip-Ｐ−ピクチャのビデオストリームをマルチプレクサ部１２６に送った後、ステップＳＴ６０１に戻る。一方、ステップＳＴ６０２において、offsetＴｉｍｅ＜PreＴｉｍｅが成立しない(NO)と判定すると、ステップＳＴ６1'に進む。なお、ステップＳＴ６1'〜ＳＴ６４'の処理は、ステップＳＴ６1〜ＳＴ６４の処理と同様である。

すなわち、ステップＳＴ６１'では、画像データをチェックし、ステップＳＴ６２'に進んで、画像データがあるか否かを判定する。ステップＳＴ６２'において、画像データがない(NO)と判定すると、ステップＳＴ６１'に戻ってチェックを行い、画像データがあると判定するまで、同様の処理を繰り返す。

一方、ステップＳＴ６２'において、画像データがある(YES)と判定すると、ステップＳＴ６３'に進んで、画像データのビデオエンコード(トランスコード)を実行し、さらに、ステップＳＴ６４'に進む。

ステップＳＴ６４'では、トランスコードしたビデオストリームをマルチプレクサ部１２６に送った後、ステップＳＴ６１'に戻って同様の処理を繰り返し、ビデオトランスコード処理を継続する。

図２１は、図１５および図１６に示すトランスコーダにおけるマルチプレクサ部による多重化処理の一例を説明するためのフローチャートであり、前述した図１４に対応するものである。ここで、図２１と前述した図１４の比較から明らかなように、図２１において、ステップＳＴ８０〜ＳＴ８５およびＳＴ８６は、図１２と同様の処理を行うものである。

すなわち、図２１に示されるように、ステップＳＴ８５において、先頭ピクチャのＰＴＳおよびＤＴＳを取り込み、先頭ピクチャの多重化開始時刻を計算し、先頭ピクチャの多重化開始時刻をＳＴＣにセットし、ＳＴＣ用カウンタ６３のカウントを開始する。そして、図１４におけるステップＳＴ８６に進む代わりに、ステップＳＴ８００に進む。

ステップＳＴ８００では、ＮＵＬＬ強制挿入モードを設定し、デオストリーム，オーディオストリームおよびＰＳＩストリームの多重化を開始するし、ステップＳＴ８０１に進んで、ビデオ先頭およびskip-Ｐ−ピクチャの全多重化の完了をチェックする。

さらに、ステップＳＴ８０２に進んで、多重化が完了したか否かを判定する。ステップＳＴ８０２において、多重化が完了していない(NO)と判定すると、ステップＳＴ８０１に戻り、多重化が完了したと判定するまで処理を繰り返す。

また、ステップＳＴ８０２において、多重化が完了した(YES)と判定すると、ステップＳＴ８０３に進んで、送信バッファ１３がチェックし、ステップＳＴ８０４に進んで、送信バッファ１３がフルか否かを判定する。

ステップＳＴ８０４において、送信バッファ１３がフルではない(NO)と判定すると、ステップＳＴ８０３に進んで戻り、送信バッファ１３がフルになったと判定するまで処理を繰り返す。

そして、ステップＳＴ８０４において、送信バッファ１３がフルになった(YES)と判定すると、ステップＳＴ８０５に進み、通常モードに設定し、ビデオストリーム，オーディオストリームおよびＰＳＩストリームの通常の多重化を再開する。なお、ステップＳＴ８０５以降の処理は、本実施例と関連が薄いので、その説明は省略する。

以上、実施形態を説明したが、ここに記載したすべての例や条件は、発明および技術に適用する発明の概念の理解を助ける目的で記載されたものであり、特に記載された例や条件は発明の範囲を制限することを意図するものではない。また、明細書のそのような記載は、発明の利点および欠点を示すものでもない。発明の実施形態を詳細に記載したが、各種の変更、置き換え、変形が発明の精神および範囲を逸脱することなく行えることが理解されるべきである。

以上の実施例を含む実施形態に関し、さらに、以下の付記を開示する。
（付記１）
送信装置が、動画像データに基づいて生成した第１画像データをベストエフォート型の回線を介して端末装置に送信し、
前記送信装置が、前記第１画像データを前記端末装置に送信した後でダミーデータを生成して前記端末装置に送信し、
前記端末装置が、前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファに格納し、前記受信バッファに格納した順に表示装置に表示する、
ことを特徴とする動画像処理方法。

（付記２）
前記ダミーデータの送信量は、前記回線の最大伝送能力に基づいて規定される、
ことを特徴とする付記１に記載の動画像処理方法。

（付記３）
前記送信装置が、
前記第１画像データおよび前記ダミーデータを前記端末装置に送信した後、前記動画像データに基づいて前記第１画像データに続く第２画像データを生成し、前記端末装置に送信する、
ことを特徴とする付記１または付記２に記載の動画像処理方法。

（付記４）
前記表示装置は、
前記第２画像データによる動画像を表示するまで、前記第１画像データによる静止画を継続して表示する、
ことを特徴とする付記３に記載の動画像処理方法。

（付記５）
前記動画像データは、テレビ放送のビデオデータであり、
前記送信装置は、前記端末装置により、前記テレビ放送における第１チャンネルが第２チャンネルに切り替えられた場合に、前記第１画像データを前記端末装置に送信する、
ことを特徴とする付記１乃至付記４のいずれか１項に記載の動画像処理方法。

（付記６）
前記動画像データは、Ｉ−ピクチャ，Ｐ−ピクチャおよびＢ−ピクチャを含み、
前記送信装置は、前記第２チャンネルに関するビデオデータの先頭のＩ−ピクチャに基づいて前記第１画像データを生成する、
ことを特徴とする付記５に記載の動画像処理方法。

（付記７）
前記送信装置は、前記第１画像データを送信した後、前記先頭のＩ−ピクチャを参照する複数のＰ−ピクチャを前記端末装置に送信する、
ことを特徴とする付記６に記載の動画像処理方法。

（付記８）
前記送信装置は、前記第１チャンネルが前記第２チャンネルに切り替えられた場合に、前記第２チャンネルに関するビデオデータの先頭のＩ−ピクチャを受信したことに応じて前記第１画像データを生成する、
ことを特徴とする付記５または付記６に記載の動画像処理方法。

（付記９）
前記回線は、無線回線である、
ことを特徴とする付記１乃至付記８のいずれか１項に記載の動画像処理方法。

（付記１０）
前記ダミーデータは、トランスポートストリームのヌルパケットである、
ことを特徴とする付記１乃至付記９のいずれか１項に記載の動画像処理方法。

（付記１１）
動画像データに基づいて第１画像データを生成し、ベストエフォート型の回線を介して前記第１画像データを送信し、前記第１画像データを送信した後でダミーデータを生成して送信する送信装置と、
前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファに格納し、前記受信バッファに格納したデータを格納した順に表示装置に表示する端末装置と、を含む、
ことを特徴とする動画像処理システム。

（付記１２）
前記送信装置は、
前記動画像データに基づいて前記第１画像データを生成する画像生成部と、
前記ダミーデータを生成するダミーデータ生成部と、を含む、
ことを特徴とする付記１１に記載の動画像処理システム。

（付記１３）
前記端末装置は、
前記送信装置から送信された前記第１画像データおよび前記ダミーデータが格納される受信バッファと、
前記前記受信バッファに格納されたデータが格納された順に表示される表示装置と、を含む、
ことを特徴とする付記１１または付記１２に記載の動画像処理システム。

（付記１４）
前記動画像データは、テレビ放送のビデオデータであり、
前記送信装置は、前記端末装置により、前記テレビ放送における第１チャンネルが第２チャンネルに切り替えられた場合に、前記第１画像データを前記端末装置に送信する、
ことを特徴とする付記１１乃至付記１３のいずれか１項に記載の動画像処理システム。

（付記１５）
前記動画像データは、Ｉ−ピクチャ，Ｐ−ピクチャおよびＢ−ピクチャを含み、
前記送信装置は、前記第２チャンネルに関するビデオデータの先頭のＩ−ピクチャに基づいて前記第１画像データを生成する、
ことを特徴とする付記１４に記載の動画像処理システム。

（付記１６）
前記送信装置は、前記第１画像データを送信した後、前記先頭のＩ−ピクチャを参照する複数のＰ−ピクチャを前記端末装置に送信する、
ことを特徴とする付記１５に記載の動画像処理システム。

（付記１７）
前記送信装置は、前記第１チャンネルが前記第２チャンネルに切り替えられた場合に、前記第２チャンネルに関するビデオデータの先頭のＩ−ピクチャを受信したことに応じて前記第１画像データを生成する、
ことを特徴とする付記１５または付記１６に記載の動画像処理システム。

（付記１８）
前記回線は、無線回線である、
ことを特徴とする付記１１乃至付記１７のいずれか１項に記載の動画像処理システム。

（付記１９）
前記ダミーデータは、トランスポートストリームのヌルパケットである、
ことを特徴とする付記１１乃至付記１８のいずれか１項に記載の動画像処理システム。

（付記２０）
演算処理装置に、
送信装置が、動画像データに基づいて生成した第１画像データをベストエフォート型の回線を介して端末装置に送信し、
前記送信装置が、前記第１画像データを前記端末装置に送信した後でダミーデータを生成して前記端末装置に送信し、
前記端末装置が、前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファに格納し、前記受信バッファに格納した順に表示装置に表示する、のを実行させる、
ことを特徴とする動画像処理プログラム。

１ ＷｉＦｉチューナ(送信装置)
２ 回線(ネットワーク，無線ＬＡＮ，ＷｉＦｉ)
３ 端末装置(受信装置)
４ ルータ
５ アンテナ
６ インターネット
１１ チューナ
１２ トランスコーダ
１３ 送信バッファ
１４ ＬＡＮ(送信)
３１ ＬＡＮ(受信)
３２ 受信バッファ
３３ デコーダ
３４ ディスプレイ(表示装置)
６０ 強制ＮＵＬＬ生成部(ダミーデータ生成部)
６１，６２ ＦＩＦＯバッファ
６３ ＳＴＣ用カウンタ
６４ ビデオＴＳパケット生成部
６５ オーディオＴＳパケット生成部
６６ ＰＡＴ生成部
６７ ＰＭＴ生成部
６８ ＰＣＲ生成部
６９ ヌルパケット生成部
７０ 多重化対象決定部
７１ 多重化対象選択部
１２１ 全体制御部
１２２ デマルチプレクサ部(ＤＥＭＵＸ)
１２３ デコーダ部
１２４ メモリ
１２５ エンコーダ部
１２６ マルチプレクサ部(ＭＵＸ)

Claims (10)

1. 送信装置が、動画像データに基づいて生成した第１画像データをベストエフォート型の回線を介して端末装置に送信し、
   前記送信装置が、前記第１画像データを前記端末装置に送信した後でダミーデータを生成して前記端末装置に送信し、
   前記端末装置が、前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファに格納し、前記受信バッファに格納した順に表示装置に表示する、
   ことを特徴とする動画像処理方法。
2. 前記ダミーデータの送信量は、前記回線の最大伝送能力に基づいて規定される、
   ことを特徴とする請求項１に記載の動画像処理方法。
3. 前記送信装置が、
   前記第１画像データおよび前記ダミーデータを前記端末装置に送信した後、前記動画像データに基づいて前記第１画像データに続く第２画像データを生成し、前記端末装置に送信する、
   ことを特徴とする請求項１または請求項２に記載の動画像処理方法。
4. 前記動画像データは、テレビ放送のビデオデータであり、
   前記送信装置は、前記端末装置により、前記テレビ放送における第１チャンネルが第２チャンネルに切り替えられた場合に、前記第１画像データを前記端末装置に送信する、
   ことを特徴とする請求項１乃至請求項３のいずれか１項に記載の動画像処理方法。
5. 前記動画像データは、Ｉ−ピクチャ，Ｐ−ピクチャおよびＢ−ピクチャを含み、
   前記送信装置は、前記第２チャンネルに関するビデオデータの先頭のＩ−ピクチャに基づいて前記第１画像データを生成する、
   ことを特徴とする請求項４に記載の動画像処理方法。
6. 前記送信装置は、前記第１チャンネルが前記第２チャンネルに切り替えられた場合に、前記第２チャンネルに関するビデオデータの先頭のＩ−ピクチャを受信したことに応じて前記第１画像データを生成する、
   ことを特徴とする請求項５に記載の動画像処理方法。
7. 動画像データに基づいて第１画像データを生成し、ベストエフォート型の回線を介して前記第１画像データを送信し、前記第１画像データを送信した後でダミーデータを生成して送信する送信装置と、
   前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファに格納し、前記受信バッファに格納したデータを格納した順に表示装置に表示する端末装置と、を含む、
   ことを特徴とする動画像処理システム。
8. 前記送信装置は、
   前記動画像データに基づいて前記第１画像データを生成する画像生成部と、
   前記ダミーデータを生成するダミーデータ生成部と、を含む、
   ことを特徴とする請求項７に記載の動画像処理システム。
9. 前記端末装置は、
   前記送信装置から送信された前記第１画像データおよび前記ダミーデータが格納される受信バッファと、
   前記前記受信バッファに格納されたデータが格納された順に表示される表示装置と、を含む、
   ことを特徴とする請求項７または請求項８に記載の動画像処理システム。
10. 演算処理装置に、
    送信装置が、動画像データに基づいて生成した第１画像データをベストエフォート型の回線を介して端末装置に送信し、
    前記送信装置が、前記第１画像データを前記端末装置に送信した後でダミーデータを生成して前記端末装置に送信し、
    前記端末装置が、前記送信装置から送信された前記第１画像データおよび前記ダミーデータを受信バッファに格納し、前記受信バッファに格納した順に表示装置に表示する、のを実行させる、
    ことを特徴とする動画像処理プログラム。

Images