番組配信システムおよび番組配信プログラム
【課題】 シームレスで連続した番組の視聴を確保するとともに番組配信の内容の動的で柔軟な編集・変更を可能とした番組配信システムを提供する。
【解決手段】 システムタイマ１０は起動時にゼロクリアされ経過時間をカウントアップする。配信予定リスト３１と現在時刻情報から配信開始時刻に達した配信コンテンツをコンテンツ記憶部２０から読み込んで動的にデコード部４０によりデコード処理し、フレーム番号管理部５０はデコード部４０が逐次にデコード処理しているフレームデータを逐次に受け取り、各フレームデータに対して通しフレーム番号情報として与える。フレーム番号管理部によりフレーム番号が与えられたフレームデータは逐次再エンコード部６０に渡され次々と動的に再びエンコード処理され、ストリーミング配信部から配信される。
【解決手段】 システムタイマ１０は起動時にゼロクリアされ経過時間をカウントアップする。配信予定リスト３１と現在時刻情報から配信開始時刻に達した配信コンテンツをコンテンツ記憶部２０から読み込んで動的にデコード部４０によりデコード処理し、フレーム番号管理部５０はデコード部４０が逐次にデコード処理しているフレームデータを逐次に受け取り、各フレームデータに対して通しフレーム番号情報として与える。フレーム番号管理部によりフレーム番号が与えられたフレームデータは逐次再エンコード部６０に渡され次々と動的に再びエンコード処理され、ストリーミング配信部から配信される。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は番組コンテンツデータをストリーミング配信する番組配信システムおよび番組配信プログラムに関する。
【背景技術】
【０００２】
番組コンテンツデータのネットワークを介した配信技術としてコンテンツ転送型とストリーミング配信型が知られている。
従来のコンテンツ転送型の配信技術は、配信する番組コンテンツデータをコンテンツ転送により番組配信システムからクライアントシステムに一括ダウンロードさせる技術であり、クライアントシステムは番組コンテンツデータのダウンロードが完全に終ってから再生を始める必要があった。このコンテンツ転送型の番組配信技術は、転送する番組コンテンツデータが大容量のコンテンツデータである場合にはダウンロードに必要な時間が長くなり実用に耐えない場合もある。
【０００３】
そこで、ストリーミング配信型の番組コンテンツデータの配信技術が注目されている。ストリーミング配信型の番組コンテンツデータの配信技術ではストリーミング配信用の通信プロトコルに則った通信環境をストリーミングサーバとクライアントシステムの間のインターネット上に実現する。ストリーミングサーバ側は番組コンテンツデータをストリーミングデータとして逐次継続的に送信し、クライアントシステム側はストリーミングデータを逐次継続的に受信する。クライアントシステムではバッファにおける所定数のフレームデータのバッファリング処理の後、再生ソフトウェアによる番組コンテンツデータの再生が可能となり、以後、ストリーミングサーバからの番組コンテンツデータの受信とその再生が継続される。このように、全体としては長時間大容量の番組コンテンツデータであっても、ストリーミング配信開始時の短いバッファリングの待ち時間のみで再生を即座に開始することができる。
【０００４】
図１２は従来のストリーミング配信型の番組コンテンツデータの配信の流れを模式的に示した図である。
送信制御部１０１０は後述する再生リスト１０４０を参照して現在の時刻に応じた番組コンテンツの該当部分のデータを特定し、ストリーミングサーバ１０３０に対して配信すべきデータを記憶部１０２０から取り出して受け渡し、ストリーミング配信を制御する部分である。
記憶部１０２０に記憶されている番組コンテンツデータはストリーミング配信に適した形式に圧縮されたエンコード済みのコンテンツデータとなっている。番組コンテンツとしては撮影したビデオ映像、編集したビデオ映像、ＣＧアニメーションなど多様のものがある。
ストリーミングサーバ１０３０は送信制御部１０１０から配信するデータを受けてストリーミングデータとして配信する。ネットワークとのインターフェイスも備えている。
再生リスト１０４０は番組コンテンツの再生順序を記述したものであり、再生する時間情報を持つことも可能である。つまり、配信する番組コンテンツとその配信予定時間が記述されており、いわゆるテレビ欄などの番組配信表と位置付けることもできる。
【０００５】
番組コンテンツデータの配信の流れは以下のようになる。
送信制御部１０１０は再生リスト１０４０を参照しつつ、現在時刻に配信すべきコンテンツの該当部分のデータを特定する。例えば番組コンテンツデータＡの終盤部分であったとすると記憶部１０２０からエンコード済コンテンツＡ１０２１Ａの該当部分のデータを取得する。送信制御部１０１０は取得した該当部分のデータをストリーミングサーバ１０３０に渡し、ストリーミングサーバ１０３０からクライアントシステムに対してストリーミングデータが配信される。
時刻が進むたび、送信制御部１０１０は再生リスト１０４０を参照し、現在時刻に配信されるべき番組コンテンツの該当部分のデータを特定し、記憶部１０２０から当該データを取得してストリーミングサーバ１０３０に渡す。
このように、再生リスト１０４０の記述に従って次々と、エンコード済コンテンツＡ、エンコード済コンテンツＢ、エンコード済コンテンツＣとストリーミング配信されて行き、クライアントシステムでは再生リスト１０４０があたかもＴＶ番組の配信予定リストのように位置付けられる。
【０００６】
【特許文献１】特開２００１−５４０９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記従来のストリーミング配信型の番組配信システムによれば、従来のコンテンツ転送型の番組配信システムのような長時間の待ち時間がなく、実用に耐えるシステムとして普及しつつある。代表的なアプリケーションはインターネットテレビジョン放送である。
しかし、従来のストリーミング配信技術では、テレビジョン放送のようにあらかじめ決められた配信予定リストに従って時刻通りに番組コンテンツをストリーミング配信する場合、番組コンテンツ配信の連続性が完全には保てず、クライアントシステムのモニタでの表示において、番組コンテンツの配信開始時のみならず、番組コンテンツと番組コンテンツの谷間においても毎回、「黒み」や「切れ目」のバッファリングが生じてしまう現象が知られている。
まず、ストリーミング配信の開始時にバッファリングが発生する理由について説明し、次に従来のストリーミング配信技術において番組コンテンツと番組コンテンツの谷間において「黒み」や「切れ目」が生じる理由について説明する。
【０００８】
図１３は従来のストリーミング配信の開始時においてバッファリング発生する理由を模式的に示す図である。
番組配信システム１０００は、記憶部１０２０、番組コンテンツのエンコード済コンテンツ１０２１、ストリーミングサーバ１０３０を備えている。クライアントシステム１１００は受信部１１１０およびバッファ１１２０を備えている。番組配信システム１０００とクライアントシステム１１００はネットワーク１２００を介してつながっている。
【０００９】
まず、クライアントシステム１１００から番組配信システム１０００に番組配信の要求が出され（図１３の［１］ストリーミング要求）、番組配信システム１０００が要求にかかる番組コンテンツデータ１０２１を記憶部１０２０から読み出してストリーミングデータとして送信を開始する（図１３の［２］ストリーミング開始）。クライアントシステム１１００は要求した番組コンテンツデータ１０２１を受信し始めた直後にバッファ１１２０を用いて所定数のフレームデータのバッファリング処理を行なう（図１３の［３］バッファリング）。バッファリングを行なう理由は幾つかあるが、ここではバッファリングの理由としてデータ転送状態の変動緩衝と新たなコンテンツ再生に向けた再生ソフトの調整時間確保を挙げておく。
【００１０】
まず、データ転送状態は常に均一というわけではなく回線状態によって若干の変動がある。ストリーミングデータは逐次連続的に送られてくるデータを逐次連続的に再生表示するものであり、一瞬、データ転送が遅れたり途切れたりするとクライアント１１１０のモニタ表示が不安定になるという不具合が発生する。そのため、あらかじめ所定数のフレームデータをバッファに蓄積してから再生表示するという緩衝を持たせる工夫を行なう。このデータ転送状態の変動緩衝のバッファリングを行なうために即座に表示ができず「黒み」や「切れ目」が生じる。
【００１１】
次に、再生されるデータ形式は常に一定というわけではなく受信データに合わせて再生ソフトのパラメタなどを調整する必要がある。受信コンテンツのヘッダを読み込めば新たなコンテンツ再生に向けた処理を開始し、ヘッダのコンテンツ情報を利用して再生ソフトのパラメタを調整する。特に、ストリーミングデータの場合、再生ソフトにおける映像レート（映像ビットレート）と音声レート（音声サンプリングレート）のパラメタ調整は重要である。この再生ソフトの調整時間中に受信したデータを一時的にバッファリングするため「黒み」や「切れ目」が生じる。
バッファ１１２０に所定データ量のバッファリングができれば、所定の再生ソフトウェアにより再生を始める（図１３の［４］モニタ表示開始）。
【００１２】
ここで、従来のストリーミング配信技術では、番組コンテンツと番組コンテンツの谷間においてもバッファリングに伴う「黒み」や「切れ目」が生じる現象が毎回生じるという問題が知られている。
上記のような番組コンテンツと番組コンテンツの谷間においてバッファリング処理に伴う「黒み」や「切れ目」が発生することは好ましくなく、通常の地上波や衛星波のテレビジョン放送ではこのような「黒み」や「切れ目」が発生しないことからインターネット放送の弱点の一つとされている。また、この番組と番組の谷間は、広告コンテンツを流すいわゆる広告枠であることが通例であり、数秒間の「黒み」や「切れ目」であってもその影響は大きいと言わざるを得ない。
【００１３】
なお、上記問題は、近年のネットワーク環境の発達と、情報発信主体の多様化に伴い、番組コンテンツを一箇所で集中的に製作する環境ではなく、ネットワークを介して、ローカルシステムで作成した多様な番組コンテンツデータをセンタシステム側で収集するとともに収集した番組コンテンツデータの配信順序などをセンタシステム側で動的かつ柔軟に編集・変更するという環境では番組コンテンツ間の映像レートや音声レートが異なることが多く、避けがたい問題となる。
【００１４】
上記問題点に鑑み、本発明は、配信したストリーミングデータのクライアントシステムでの表示において、シームレスで連続した番組コンテンツの視聴を確保する番組配信システムを提供することを目的とする。
特に、番組コンテンツを一箇所で集中的に製作する環境ではなく、ネットワークを介して、ローカルシステムで作成した多様な番組コンテンツデータを収集するとともに収集した番組コンテンツデータの配信順序などを動的かつ柔軟に編集・変更する環境での適用が可能である番組配信システムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するため、本発明の番組配信システムは、
起動時にゼロクリアされ経過時間をシステムタイムとしてカウントしてゆくシステムタイマと、
複数個のエンコード済み配信コンテンツを記憶したコンテンツ記憶部と、
前記配信コンテンツの配信予定リストを編集する配信予定リスト編集部と、
前記配信予定リストに従い配信開始時刻に達した前記配信コンテンツを前記コンテンツ記憶部から読み込んで動的にデコード処理するデコード部と、
前記デコード部が逐次にデコード処理しているフレームデータを逐次に受け取り、先頭フレームに対しては前記配信開始時刻における前記システムタイムの値を付与し、各後続フレームに対しては前記先頭フレームに付与された前記システムタイムの値に前記各後続フレームに予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間を合算した値を付与することにより、各フレームデータに対して通しフレーム番号情報を与えるフレーム番号管理部と、
前記フレーム番号管理部により通しフレーム番号が与えられたフレームデータを逐次に受け取り、次々と動的に所定の音声レートと映像レートにて再びエンコード処理する再エンコード部と、
前記再エンコード部から供給されるデータをストリーミング配信するストリーミング配信部とを備えたものである。
【００１６】
なお、上記番組配信システムにおいて、前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、前記配信予定リスト編集部が、前記番組コンテンツ間に前記広告コンテンツを挟み込む形で配信予定リストを編集することが好ましい。
【００１７】
また、上記番組配信システムにおいて、前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、前記配信予定リスト編集部が、一つの前記番組コンテンツを複数個に分割し、その間に前記広告コンテンツを挟み込む形で配信予定リストを編集することが好ましい。
【００１８】
上記構成により、番組と番組の間においてクライアントシステムの表示において黒みや切れ目などを生じさせることなくシームレスで連続した番組コンテンツの視聴を確保することができ、さらに、番組配信の内容・順序を動的に編集・変更することができ、柔軟な番組配信が可能となる。クライアントシステムにおいて番組コンテンツの谷間において黒味が発生することはない。
【発明の効果】
【００１９】
本発明の番組配信システムによれば、シームレスで連続した番組コンテンツの視聴を確保するとともに番組配信の内容・順序の動的で柔軟な編集・変更が可能となる。
【発明を実施するための最良の形態】
【００２０】
以下、図面を参照しつつ、本発明の番組配信システムの実施形態を説明する。ただし、本発明の技術的範囲は以下の実施形態に示した具体的な用途や形状・寸法などには限定されない。
【実施例１】
【００２１】
本発明の番組配信システムは、配信したストリーミングデータのクライアントシステムでの表示において、番組コンテンツと番組コンテンツの谷間において黒みや切れ目が生じることなく、シームレスで連続した番組コンテンツの視聴を確保するとともに番組配信の内容・順序の動的で柔軟な編集・変更を可能としたものである。
【００２２】
本発明の番組配信システムの説明にあたり、まず、最初に、［１］一般にストリーミング配信での番組コンテンツの谷間においてクライアントシステムの再生表示に黒みや切れ目が生じる理由を解析しておく。次に［２］本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理を説明する。次に［３］ローカルシステムとセンタシステムを用いたネットワーク分散環境における本発明の番組配信システムの構成例、次に［４］番組配信の流れについて説明する。
【００２３】
［１］番組コンテンツの谷間の再生において黒みや切れ目が生じる理由の解析
以下、一般にストリーミング配信において番組コンテンツと番組コンテンツの谷間においてクライアントシステムでの再生表示に黒みや切れ目が生じる理由を解析する。
【００２４】
番組コンテンツと番組コンテンツの谷間において黒みや切れ目を生じさせる原因は、後者の新たなコンテンツ再生に向けた「再生ソフトのパラメタ調整などのためのバッファリング」にあると考えられる。ここで、新たなコンテンツ再生に向けた再生ソフトの調整が必要になる場合としては、（ａ）新たなヘッダ受信があった場合と、（ｂ）先行する番組コンテンツと後続の番組コンテンツの映像レートと音声レートが異なる場合が考えられる。
【００２５】
図１を参照しつつ、一般のストリーミング配信の番組コンテンツの谷間におけるクライアントシステムでの再生に黒みや切れ目が生じる現象を説明する。
【００２６】
（ａ）新たなヘッダ受信に伴うバッファリング処理
例えば、先行の番組コンテンツＡが既に再生表示されているとする（図１（ａ））。ここで、先行の番組コンテンツＡの配信が終了し、後続の番組コンテンツＢのストリーミングデータが受信されたとする（図１（ｂ））。
後続の番組コンテンツＢのストリーミングデータの先頭にはヘッダが付されているので、再生ソフトウェアは当該ヘッダを受信することにより新たな番組コンテンツＢのストリーミング再生処理が始まることを認識し、新たなコンテンツ再生に向けて処理を開始する。現在普及している再生ソフトウェアは新たなコンテンツのヘッダを読み込めば、新たなストリーミング再生処理に向けた再生ソフトウェアのパラメタ調整の時間確保のため、現在バッファに存在する先行の番組コンテンツデータを破棄し、新たに後続の番組コンテンツデータのバッファリング処理を開始する仕組みとなっている（図１（ｂ））。このバッファリング処理の間「黒み」や「切れ目」が発生する。
【００２７】
（ｂ）番組コンテンツ間で映像レートと音声レートが異なる場合のバッファリング処理
一般的にはストリーミング配信されるデータの映像レートと音声レートは多様である。ニュース取材の過程で製作したビデオ映像、ミュージックビデオクリップ、アニメーション映像、コンピュータグラフィック映像など製作の過程や目的に応じて映像の画質と音声の音質にはバリエーションがある。クライアントシステムの再生ソフトは音声レートおよび映像レートに合わせてデコード・再生処理する必要があり、音声レートおよび映像レートの異なるエンコード済コンテンツが受信されるとクライアントシステムの再生ソフトは新たなレートに対応するためパラメタを調整する必要が生じる。
【００２８】
図１において、例えば先行の番組コンテンツＡの映像レートと音声レートがＲ１（例えば、映像レート１８０ｂｐｓ、音声レート７６ｂｐｓ）で既に再生表示されているとする（図１（ａ））。ここで、先行の番組コンテンツＡの配信が終了し、後続の番組コンテンツＢのストリーミングデータが受信されたとする（図１（ｂ））。この後続の番組コンテンツＢの映像レートと音声レートがＲ２（例えば、映像レート２２０ｂｐｓ、音声レート３６ｂｐｓ）であるとする。音声レートと映像レートが異なる場合は再生ソフトウェアのパラメタ調整などが必要となるので、再生ソフトウェアは映像レートと音声レートの違いを認識すれば新たな番組コンテンツデータの再生準備のため、現在バッファ中の先行の番組コンテンツデータを破棄し、新たな後続の番組コンテンツデータのバッファリング処理を開始する仕組みとなっている（図１（ｂ））。このバッファリング処理の間「黒み」や「切れ目」が発生する。
【００２９】
［２］本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理
次に、本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理を説明する。
【００３０】
本発明の番組配信システムでは、配信予定リストに従って現在時刻に応じて番組コンテンツコンテンツをデコード処理して一旦フレームデータとし、フレームデータを順々にフレーム番号管理部を通してフレーム通し番号情報を付した後に再エンコード部を通して再エンコードすることにより一定レートで配信することにより、動的にオンタイムでフレームデータを通し番号順に延々とつないで配信するものである。フレーム通し番号はもとの番組コンテンツコンテンツ単位ではなく、例えば一日の配信予定リストの朝の配信開始時刻から深夜の配信終了時刻まで一日単位のフレーム通し番号である。
本発明の番組配信システムでは、配信番組を一日の配信が開始された以後でも動的に変更し得るものであることが前提であるところ、各番組コンテンツには予め通し番号は付さず、配信時刻に達して配信処理を行なう段階で初めて各フレームに通し番号を付しつつ配信処理を行なうという特徴を持つ。
【００３１】
図２は、本発明の番組配信システムにおけるストリーミング配信の仕組みを模式的に説明する図である。
【００３２】
複数個のエンコード済みコンテンツが番組配信の素材となるデータである。エンコード済みコンテンツのエンコード形式はデコード部が対応可能な限り限定されない。ここではそれぞれのエンコード済みコンテンツＡ，Ｂ，Ｃが不統一であっても良い。
このエンコード済みコンテンツＡ，Ｂ，Ｃは、現時点で有効な配信予定リストに従って配信時刻になるとその順にデコード部４０に渡される。デコード部４０はエンコード済みコンテンツをデコード処理し、フレームデータ単位に分解してゆく。フレームデータ単位に分解されてしまえば各々のフレームデータは一枚の画像データであり、元のエンコード済みコンテンツの違いには依存しない。つまり、元のエンコード済みコンテンツがエンコード済みコンテンツＡであってもエンコード済みコンテンツＢであってもフレームデータにすると一枚の画像データである。
【００３３】
デコード部４０よりフレームデータ単位に分解されたフレームデータは次々にフレーム番号管理部５０に渡されてゆく。フレーム番号管理部５０は渡されたフレームデータに通し番号を付してゆく。ここで、通し番号とは番組配信システム一日の処理を通した通し番号のことを言う。たとえば、番組配信システムによりエンコード済みコンテンツＡ，Ｂ，Ｃの順に配信予定リストが変更されることなくそのまま配信される場合、エンコード済みコンテンツＡ，Ｂ，Ｃからデコードされたフレームデータに対して所定のルールにて動的に順々に通し番号が付される。
【００３４】
通し番号は以下の手順により付されてゆく。
デコード部４０は上記したように、現時点で有効な配信予定リストに従い配信開始時刻に達した配信コンテンツをコンテンツ記憶部から読み込んで動的にデコード処理を開始する。
フレーム番号管理部５０はデコード部４０からフレームデータを逐次に受け取り通し番号を付与して行くが、ここで、配信コンテンツの先頭フレームに対して通し番号を付与するルールと後続フレームに対して通し番号を付与するルールは異なる。
【００３５】
図３は先頭フレームおよび後続フレームに対して通し番号を付与するルールを模式的に説明する図である。
先頭フレームに対しては配信開始時刻においてシステムタイマ１０を参照してシステムタイムの値をそのまま通し番号として付与する。ここで、システムタイムとは、番組配信システムが起動された時点をゼロとしたシステム稼動の経過時間を言う。例えば、ミリ秒単位の数値とする。いま、番組配信システムが６：００に起動され番組Ａが配信開始された場合は、当該配信開始時刻においてシステムタイムを参照すると“０００００００（ｍｓｅｃ）”であり、番組Ａの先頭フレームには通し番号として“０００００００”が付与される。番組Ｂが７：００に配信されるならば当該配信開始時刻においてシステムタイムを参照すると“３６０００００（ｍｓｅｃ）”であり番組Ｂの先頭フレームには通し番号として“３６０００００”が付与される。同様に、番組Ｃが８：００に配信されるならば当該配信開始時刻においてシステムタイムを参照すると“７２０００００（ｍｓｅｃ）”であり番組Ｃの先頭フレームには通し番号として“７２０００００”が付与される。
【００３６】
次に、後続フレームに対しては、先頭フレームに通し番号として付与されたシステムタイムの値に、各後続フレームに予め与えられている番組内での再生タイミングであるタイムスタンプ時間を合算した値を付与する。通常、番組の各フレームには番組が再生表示開始されてから当該フレームが再生表示されるべきタイミング情報がタイムスタンプ情報として与えられている。つまり、各フレームにはそれが表示されるべき再生タイミング、例えば、３０フレーム／秒の場合、２フレーム目には“０００００３３（ｍｓｅｃ）”、３フレーム目には“０００００６７（ｍｓｅｃ）”、４フレーム目には“００００１００（ｍｓｅｃ）”というタイムスタンプ情報がもともと付されている。そこで、番組Ｂについては、先頭フレームには通し番号“３６０００００”が付与されているので、番組Ｂの第２フレームには合算値として通し番号“３６０００３３”、番組Ｂの第３フレームには合算値として通し番号“３６０００６７”、第４フレームには合算値として通し番号“３６００１００”が付与される。例えば、番組Ｃについては、先頭フレームには通し番号“７２０００００”が付与されているので、番組Ｃの第２フレームには合算値として通し番号“７２０００３３”、番組Ｃの第３フレームには合算値として通し番号“７２０００６７”、第４フレームには合算値として通し番号“７２００１００”が与えられるという具合である。
【００３７】
このように先頭フレームの通し番号と後続フレームの通し番号を付与する理由を以下に示す。
配信される番組コンテンツの後続フレームには、先頭フレームに与えられたシステムタイム（Ｔ）と予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間（Ｓ）を合算した値（Ｔ+Ｓ）を付与する。
【００３８】
まず、先頭フレームにはシステムタイム（Ｔ）を用いるので、配信番組間の順序制御と配信開始時間が正しく処理される。本発明の番組配信システムでは、配信番組を一日の配信が開始された以後でも動的に変更し得るものであることが前提であるところ、各番組コンテンツには予め通し番号は付さず、配信時刻に達して配信処理を行なう段階で初めて通し番号を付しつつ配信処理を行なう。番組コンテンツは現時点で有効な配信予定リスト上で配信時刻に達して始めてその先頭フレームにシステムタイム（Ｔ）を通し番号として付与するので、動的な変更を可能としつつ配信開始時間が正しく処理される。
【００３９】
次に、後続フレームに対してはタイムスタンプ時間（Ｓ）を用いるので、すべての後続フレームは、後続フレーム間の順序が正しく制御されるとともに配信を受けるローカルシステムにおける表示タイミングも正しく制御される。番組配信システム１００のリソース状態によりデコード処理にかかる時間はまちまちで番組配信システム内での処理は長短が生じるが、各フレームにはローカルシステム２００上で表示されるべきタイミング情報となるタイムスタンプ情報（Ｓ）が与えられているので、番組配信システム１００上でのデコード処理のタイミングがバラバラであっても配信を受けるローカルシステム２００上での再生表示は当該正しい表示タイミングにて再生できる。
【００４０】
もし、各後続フレームに対しても毎回システムタイマ１０を参照してシステムタイム（Ｔ）を通し番号として与えることを仮定すると、システムタイム（Ｔ）は必ず増加して行くので後続フレーム間の順序は正しく制御される。しかし、上記したように、番組配信システム１００のリソース状態によりデコード処理にかかる時間はまちまちで番組配信システム内での処理は長短が生じるため、配信処理の過程において毎回システムタイマ１０を参照してシステムタイム（Ｔ）を通し番号として与えると、後続フレーム間の時間間隔は一定ではなくなってしまう。そのため配信を受けたローカルシステム２００において再生表示を行なうと、本来は各フレームが１／３０秒のスピードで再生されるものが、あるフレームは１／３０秒よりも短く表示され、あるフレームは１／３０秒よりも長く表示されるなどの不具合が発生してしまう。
【００４１】
一方、タイムスタンプ情報（Ｓ）はローカルシステムにおける表示タイミングそのものであるので、通し番号としてタイムスタンプ情報（Ｓ）を用いることにより、ローカルシステムにおける表示タイミングは、後続フレーム間の時間間隔は正しい一定間隔で表示される。
【００４２】
ここで、タイムスタンプ情報（Ｓ）のみを通し番号とすると、番組コンテンツ内での順序制御と表示タイミングの制御は可能となるが、番組コンテンツをまたがる形での順序制御と表示タイミングの制御はできない。つまり、タイムスタンプ情報（Ｓ）は番組コンテンツの先頭フレームに対する相対的表示タイミングでしかないため、例えば１時間の番組Ａと１時間の番組Ｂのつなぎ目付近では、番組Ａの最後尾付近のフレームデータには３６０００００（ｍｓｅｃ）近くの大きな値のタイムスタンプ情報（Ｓ）が付されているはずである。一方、番組Ｂの先頭付近のフレームデータには０００００００（ｍｓｅｃ）近くの小さな値のタイムスタンプ情報（Ｓ）が付されているはずである。つまり、後続フレームに対してタイムスタンプ情報（Ｓ）のみを通し番号とすると、正しく順序制御ができない恐れがある。
【００４３】
そこで、本発明では、後続フレームに対して、先頭フレームに与えられたシステムタイム（Ｔ）とタイムスタンプ時間（Ｓ）を合算した値（Ｔ+Ｓ）を付与する。つまり、システムタイム（Ｔ）は必ず増加して行くところ、各番組が配信されるときに動的にシステムタイマ１０が参照されるので各番組の先頭フレームにはシステムタイム（Ｔ）が通し番号として与えられ、後続フレームには（Ｔ+Ｓ）という形で通し番号が与えられるので後続フレームは番組の配信開始時刻からの表示タイミングとして与えられる。例えば番組Ａと番組Ｂのつなぎ目付近においては、番組Ａの最後尾付近のフレームデータには、システム（Ｔ）が“０００００００”、タイムスタンプ（Ｓ）が３６０００００（ｍｓｅｃ）より小さな値であり、通し番号は（Ｔ＋Ｓ）は３６０００００（ｍｓｅｃ）より小さな値となる。例えば、番組Ａの最後のフレームデータには通し番号“３５９９９６７”が付与されたとする。一方、番組Ｂの先頭付近のフレームデータには、システム（Ｔ）が“３６０００００”、タイムスタンプ（Ｓ）は０００００００（ｍｓｅｃ）近くの小さな値であり、通し番号は（Ｔ＋Ｓ）は３６０００００よりも大きな値が付される。例えば、番組Ｂの先頭のフレームデータの通し番号は“３６０００００”、その次のフレームデータの通し番号“３６０００３３”として付される。つまり、番組Ａと番組Ｂをまたぐ形で、すべての先頭フレームと後続フレームの順序制御とローカルシステムでの表示タイミング制御が可能となる。
【００４４】
なお、もし、番組コンテンツＡの最後のフレームの処理が、システムリソースの状態により３３ｍｓｅｃ以上かかってしまった場合でもタイムスタンプ情報は変わらないので“３５９９９６７”が付与されることとなる。番組Ｂの先頭付近のフレームデータは、配信予定リストに従って７時つまり３６０００００（ｍｓｅｃ）の時点でシステムタイマを参照するので“３６０００００”が付与されることとなり、番組Ａの最後尾フレームと番組Ｂの先頭フレームの通し番号の順序が逆になることはない。
【００４５】
図２に戻り、再エンコード処理について述べる。配信番組リストに従ってデコードされたフレームデータに対して、各々のフレームデータは再エンコード部６０に次々に渡されてエンコードされて行く。ここでは模式的に前後３個のフレームデータがあればエンコードできるものとして図示しているが、採用するエンコード形式に従って必要なフレーム数を取り揃えてエンコードすることとなる。この際に各フレームデータは通し番号を手掛かりに正しく順序制御されてエンコードされる。ここで、エンコード済みコンテンツのつなぎ目においてもシームレスにつながれてエンコードされる。例えば、エンコード済みコンテンツＡとエンコード済みコンテンツＢのつなぎ目において、番組Ａの最後のフレームデータには通し番号“３５９９９６７”、番組Ｂの先頭のフレームデータの通し番号は“３６０００００”、その次のフレームデータの通し番号“３６０００３３”として付されているので再エンコード部６０における再エンコード処理ではエンコード済みコンテンツのつなぎ目がなくなりシームレスに連続するものとして編集される。
再エンコード部６０により再エンコードされた再エンコード済みデータは、ストリーミング配信部７０により番組コンテンツのつなぎ目が連続したものとしてストリーミング配信される。
【００４６】
ローカルシステム２００では、ストリーミング配信されたコンテンツデータをデコードしつつ再生表示して行く。各フレームには通し番号という形でタイムスタンプ情報が含まれており、ローカルシステム２００上では正しい表示タイミングにて表示される。
以上が本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理である。
【００４７】
［３］ローカルシステムとセンタシステムを用いたネットワーク分散環境における本発明の番組配信システムの構成例
次に、ローカルシステムとセンタシステムを用いたネットワーク分散環境における本発明の番組配信システムの構成例を説明する。
図４は、ローカルシステム２００とセンタシステム１００を用いたネットワーク分散環境における本発明の番組配信システムの構成例を示す図である。
図４の構成は、システムタイマ１０、タイマ１１、コンテンツ記憶部２０、配信予定リスト編集部３０、デコード部４０、フレーム番号管理部５０、再エンコード部６０、ストリーミング配信部７０を備えた構成となっている。
【００４８】
システムタイマ１０は上述したとおりである。
タイマは現在時刻を刻むものであり、デコード部４０が参照して現在時刻を把握し、配信予定リストでの各番組コンテンツの配信開始を検知するために用いる。
コンテンツ記憶部２０には複数個のエンコード済み配信コンテンツが記憶されている。この例ではエンコード済み配信コンテンツＡ，Ｂ，・・・，Ｌの１２個のコンテンツが記憶されている。なお、ローカルシステム２００からエンコード済みコンテンツがアップロードされ、当該アップロードされたエンコード済み配信コンテンツを格納することも好ましい。分散環境においてはローカルシステム２００側で配信番組を編集し、アップロードしてセンタシステム側から配信するという利用形態もあり得るからである。
【００４９】
配信予定リスト編集部３０は、配信コンテンツの配信予定リスト３１を編集する機能を備えている。図５は配信予定リスト３１を模式的に示したものである。配信予定リスト編集部３０は動的に配信コンテンツの配信予定リスト３１を編集できる。例えば図５に示すように、１０時から配信予定だった番組Ｅに代えて番組Ｍを配信したい場合、既に一日の配信が始まっている場合（例えば８時）であっても１０時に配信する予定の番組を動的に差し替えることができる。
【００５０】
デコード部４０が備えるデコード機能はコンテンツ記憶部２０内に記憶されているエンコード済みコンテンツのエンコード形式に対応するデコード処理ができるものであれば良い。番組配信システム１００全体で取り扱うエンコード形式が１種類に限定されておれば当該エンコード形式に対応するデコード機能を持てば良く、想定されるエンコード形式が３種類であれば３種類のデコード機能を持てば良い。たとえば、番組配信システム１００においてＷＭＦ、ＡＶＩ、ＭＰＥＧの３種類のエンコード形式が想定される場合、デコード部４０はそれぞれのデコード機能を備えれば良い。
【００５１】
フレーム番号管理部５０は上述したとおりである。
再エンコード部６０はフレーム番号管理部５０によりフレーム番号が与えられたフレームデータを逐次に受け取り、エンコード処理に必要な複数個のフレームデータが集積すると次々と動的に所定の音声レートと映像レートにて再びエンコード処理するものである。例えば、ＭＰＥＧでは前後複数枚のフレームを集めて非圧縮フレーム（Ｉフレーム）とイントラ圧縮フレーム（Ｐフレーム）とインター圧縮フレーム（Ｂフレーム）を決めて圧縮するので、１枚のフレームデータを入手しただけではエンコードできず、前後の複数枚のフレームを集めて圧縮するが、再エンコード部６０は必要な前後複数枚のフレームを受け入れて再エンコードする。
ストリーミング配信部７０は、再エンコード部６０から供給されるエンコード済みデータをストリーミング配信するものである。
【００５２】
［４］番組配信の流れ
実施例１に示した番組配信システムの番組配信の流れを整理しておく。
図６は実施例１にかかる番組配信システムのセンタシステムでの処理を中心とした処理の流れを示すフローチャートである。
前提として、コンテンツ記憶部２０には既にエンコード処理番組コンテンツが記憶されており、配信予定リスト３１の編集処理は完了しているものとする。
【００５３】
まず、配信開始に向けて番組配信システム１００を起動する（ステップＳ１）。例えば、朝６時に番組の配信が開始できるように番組配信システム１００を起動する。
この起動と同時にシステムタイマ１０の計数値が一旦ゼロクリアされ、経過時間のカウントアップを開始する（ステップＳ２）。番組配信システム１００の起動時から終了時まで途切れずに経過時間をカウントアップする。
【００５４】
次に、デコード部４０は現在時刻情報を得て、配信予定リスト３１にアクセスし、現在時刻に配信が行なわれる番組が何であるかを把握する（ステップＳ３）。例えばいま８時丁度に至ったとする。
デコード部４０は配信予定リスト３１から配信すべき番組コンテンツを把握し、コンテンツ記憶部２０にアクセスし、当該番組コンテンツのデコードを行なう（ステップＳ４）。いま、８時になり、新たな番組コンテンツＣの配信開始が検知され、デコード部４０がコンテンツ記憶部２０にアクセスし、番組コンテンツＣのコンテンツのデコードを開始したものとする。
【００５５】
デコード部４０のデコード処理によりフレームデータが次々と逐次に得られてゆくが、デコード部４０はそれらを逐次にフレーム番号管理部５０に渡して行く（ステップＳ５）。ここでは、番組コンテンツＣの先頭フレームから順に時系列にフレームがフレーム番号管理部５０に渡される。
【００５６】
次に、フレーム番号管理部５０は時系列に逐次にデコード部４０から渡されるフレームデータに対して、システムタイマ１０を参照してシステムタイムを得てその値を通し番号として与える（ステップＳ６）。例えば、番組コンテンツＣの先頭フレームデータに対して通しフレーム番号情報“７２０００００”を付与する。次のフレームデータに対してタイムスタンプの値を足し込んだ“７２０００３３”を通しフレーム番号情報として付与し、その後のフレームデータに対してもタイムスタンプが足し込まれた通し番号を順々に付与してゆく。
【００５７】
次に、フレーム番号管理部５０により通しフレーム番号情報が付されたフレームデータは再エンコード部６０に渡され、再エンコード部６０は所定の映像レートと音声レートにて再エンコード処理を行なう（ステップＳ７）。
ストリーミングサーバ７０は再エンコード部６０から再エンコード処理したデータを受け取り、クライアントシステム２００に対して番組コンテンツデータを配信する（ステップＳ８）。つまり、現在時刻に合わせて配信すべきデータがストリーミングサーバ７０からクライアントシステム２００に対してシームレスなストリーミングデータとして配信され続ける。
時刻が進むたび上記処理を繰り返す（ステップＳ３へ戻る）。
以上がストリーミングデータ配信の流れの概要である。
【００５８】
なお、クライアントシステム２００の再生表示において番組コンテンツ間の谷間で「黒み」、「切れ目」を生じることはない。
図７は本発明の第１の番組配信システム１００からストリーミング配信された番組コンテンツのクライアントコンピュータでの再生処理を模式的に示す図である。
【００５９】
番組コンテンツＡの最終部分のストリーミング配信の処理（図７（ａ））に引き続き、番組コンテンツＢの冒頭部分のストリーミング配信処理が行なわれる（図７（ｂ））。ここで、番組コンテンツＣの終端部分と番組コンテンツＤの冒頭部分の谷間においてヘッダやフッタは存在せずかつ同じ統一規約のレートＲ０であるのでストリーミングサーバ７０からシームレスに連続するデータとして配信される。クライアントシステム２００においては、番組コンテンツＣの終端部分と番組コンテンツＤの冒頭部分はまったくシームレスで連続したデータとして供給されるので、再生ソフトによる再生処理もシームレスに行なわれ、モニタ上には連続な映像として表示される。つまり、番組コンテンツＣと番組コンテンツＤの谷間において「黒み」や「切れ目」が生じることはなく、所定の時刻に所定の内容の番組コンテンツが表示され、あたかもＴＶ番組を視聴する如くの表示環境が得られる（図７（ｂ）モニタ表示）。
【００６０】
次に、番組配信の動的編集機能について説明する。
まず比較のために配信予定リスト編集部３０による変更がない場合の配信を説明する。図８は、１０時における配信予定リスト編集部３０による変更がなく、当初の配信予定リスト３１の通り、番組コンテンツＥが配信される場合の流れを模式的に示す図である。
【００６１】
デコード部４０により１０時直前まで番組コンテンツＤがデコードされており、１０時になるとデコード部４０は番組コンテンツＥがデコードされる。フレーム番号管理部５０が通しフレーム番号を付して行くが、番組コンテンツＥの配信が当初の予定どおりで合った場合、番組コンテンツＤの最終フレームに付される通しフレーム番号が“１４３９９９６７”、番組コンテンツＥの先頭フレームに付される通しフレーム番号が“１４４０００００”であり、番組コンテンツＤと番組コンテンツＥのつなぎ目においても通しフレーム番号は連続したものとなっており、番組コンテンツ内のフレームデータ同士のつながりも番組コンテンツ間のフレームデータ同士のつながりも同じものとなっている。このフレームデータを順に再エンコードして行くことにより番組コンテンツＤと番組コンテンツＥの間がシームレスなストリーミングデータとして配信される。
【００６２】
次に、図５に示したように、当初、配信予定リスト３１において１０時に配信される番組の予定が番組コンテンツＥであったものが配信予定リスト編集部３０により番組コンテンツＭに変更されたものとする。図９は、配信予定リスト編集部３０によって１０時における配信予定リスト３１が編集され、番組コンテンツＥに代え、番組コンテンツＭが配信される場合の流れを模式的に示す図である。
【００６３】
デコード部４０により１０時直前まで番組コンテンツＤがデコードされており、１０時になるとデコード部４０は番組コンテンツＭがデコードされる。フレーム番号管理部５０が通しフレーム番号を付して行くが、この例でも、番組コンテンツＤの最終フレームに付される通しフレーム番号が“１４３９９９６７”、番組コンテンツＭの先頭フレームに付される通しフレーム番号が“１４４０００００”となり、番組コンテンツＤと番組コンテンツＭのつなぎ目においても通しフレーム番号は連続したものとなっており、配信される番組コンテンツが番組コンテンツＥから番組コンテンツＭに変更されたとしても番組コンテンツ間のフレームデータ同士のつながりは同じものとなっている。つまり、この動的編集された場合でもフレームデータを順に再エンコードして行くことにより番組コンテンツＤと番組コンテンツＭの間がシームレスなストリーミングデータとして配信される。
【００６４】
以上、実施例１の番組配信システムによれば、番組と番組の間においてクライアントシステムの表示において黒みや切れ目などを生じさせることなくシームレスで連続した番組コンテンツの視聴を確保することができ、さらに、番組配信の内容・順序を動的に編集・変更することができ、柔軟な番組配信が可能となる。クライアントシステムにおいて番組コンテンツの谷間において黒味が発生することはない。
【実施例２】
【００６５】
実施例２では、本発明の番組配信システムにおいて、広告コンテンツを挿入する方法について説明する。
第１の方法は、単純に配信コンテンツの一つとして広告コンテンツを位置づける方法である。本発明の番組配信システムでは、配信コンテンツの内容が、映画などのコンテンツか広告などのコンテンツかの違いには依存しないので、広告コンテンツを挿入することができる。
図１０に示すように、例えば、４つの配信コンテンツのうち第１番目の配信コンテンツを番組コンテンツＡとし、第２番目の配信コンテンツを広告コンテンツＡとし、第３番目の配信コンテンツを広告コンテンツＢとし、第４番目の配信コンテンツを番組コンテンツＢとした例である。番組コンテンツの配信、広告コンテンツの配信は実施例１に示したように処理され、シームレスなストリーミングとして配信される。
ただし、この方法では、番組コンテンツ自体は、配信が始まるとその配信が終わるまで広告を挿入することはできない。つまり、２時間の映画を配信する場合、２時間は映画を流し続け、その後でないと広告を配信することはできない。
【００６６】
次に、第２の方法は、一かたまりの番組コンテンツを前編集により分割し、複数のサブコンテンツに分割しておき、そのサブコンテンツの間に広告コンテンツを挿入する方法である。現在の一般のテレビジョン放送では映画などを放送する場合、１５分きざみ程度で分割し、その間に広告を挿入する方式が一般的であるが、この第２の方法は、番組コンテンツを複数のサブコンテンツに分割して広告を挿入するものであり、現在のテレビジョン放送と近い広告の挿入方法と言える。
【００６７】
図１１に示すように、例えば、前編集により配信コンテンツＡを４つに分割し、「番組Ａの前半１」、「番組Ａの前半２」、「番組Ａの後半１」、「番組Ａの後半２」の４つのサブコンテンツとしておき、サブコンテンツの間に広告コンテンツＡ、広告コンテンツを挟む。番組のサブコンテンツの配信、広告コンテンツの配信は実施例１または実施例２に示したように処理され、シームレスなストリーミングとして配信される。
【００６８】
以上、実施例２の番組配信システムによれば、広告コンテンツを番組コンテンツの間に挿入することができ、かつ、クライアントシステムの表示において黒みや切れ目などを生じさせることなくシームレスで連続した番組コンテンツおよび広告コンテンツの視聴を確保することができ、柔軟な番組配信が可能となる。クライアントシステムにおいて番組コンテンツと広告コンテンツの谷間において黒味が発生することはない。
【００６９】
以上、本発明の番組配信システムにおける好ましい実施形態を図示して説明してきたが、本発明の技術的範囲を逸脱することなく種々の変更が可能であることは理解されるであろう。
【産業上の利用可能性】
【００７０】
本発明は番組配信システムに適用することができる。特に、インターネットを利用したインターネット放送などに適用することができる。
【図面の簡単な説明】
【００７１】
【図１】ヘッダが存在する場合、レートが異なる場合の番組コンテンツの谷間での黒みの発生の理由を説明する図
【図２】本発明の番組配信システムにおけるストリーミング配信の仕組みを模式的に説明する図
【図３】先頭フレームおよび後続フレームに対して通し番号を付与するルールを模式的に説明する図
【図４】ローカルシステム２００とセンタシステム１００を用いたネットワーク分散環境における本発明の番組配信システムの構成例を示す図
【図５】配信予定リスト３１を模式的に示した図
【図６】実施例１にかかる番組配信システムのセンタシステムでの処理を中心とした処理の流れを示すフローチャート
【図７】本発明の第１の番組配信システム１００からストリーミング配信された番組コンテンツのクライアントコンピュータでの再生処理を模式的に示す図
【図８】当初の配信予定リスト３１の通り、番組コンテンツＥが配信される場合の流れを模式的に示す図
【図９】番組コンテンツＥに代え、番組コンテンツＭが配信される場合の流れを模式的に示す図
【図１０】第１の広告コンテンツの挿入方法の具体例を模式的に示す図
【図１１】第２の広告コンテンツの挿入方法の具体例を模式的に示す図
【図１２】従来のストリーミング配信型の番組コンテンツデータの配信の流れを模式的に示した図
【図１３】従来のストリーミング配信の開始時においてバッファリング発生する理由を模式的に示す図
【符号の説明】
【００７２】
１０ システムタイマ
２０ コンテンツ記憶部
３０ 配信予定リスト編集部
３１ 配信予定リスト
４０ デコード部
５０ フレーム番号管理部
６０ 再エンコード部
７０ ストリーミングサーバ
１００ センタシステム
２００ ローカルシステム
【技術分野】
【０００１】
本発明は番組コンテンツデータをストリーミング配信する番組配信システムおよび番組配信プログラムに関する。
【背景技術】
【０００２】
番組コンテンツデータのネットワークを介した配信技術としてコンテンツ転送型とストリーミング配信型が知られている。
従来のコンテンツ転送型の配信技術は、配信する番組コンテンツデータをコンテンツ転送により番組配信システムからクライアントシステムに一括ダウンロードさせる技術であり、クライアントシステムは番組コンテンツデータのダウンロードが完全に終ってから再生を始める必要があった。このコンテンツ転送型の番組配信技術は、転送する番組コンテンツデータが大容量のコンテンツデータである場合にはダウンロードに必要な時間が長くなり実用に耐えない場合もある。
【０００３】
そこで、ストリーミング配信型の番組コンテンツデータの配信技術が注目されている。ストリーミング配信型の番組コンテンツデータの配信技術ではストリーミング配信用の通信プロトコルに則った通信環境をストリーミングサーバとクライアントシステムの間のインターネット上に実現する。ストリーミングサーバ側は番組コンテンツデータをストリーミングデータとして逐次継続的に送信し、クライアントシステム側はストリーミングデータを逐次継続的に受信する。クライアントシステムではバッファにおける所定数のフレームデータのバッファリング処理の後、再生ソフトウェアによる番組コンテンツデータの再生が可能となり、以後、ストリーミングサーバからの番組コンテンツデータの受信とその再生が継続される。このように、全体としては長時間大容量の番組コンテンツデータであっても、ストリーミング配信開始時の短いバッファリングの待ち時間のみで再生を即座に開始することができる。
【０００４】
図１２は従来のストリーミング配信型の番組コンテンツデータの配信の流れを模式的に示した図である。
送信制御部１０１０は後述する再生リスト１０４０を参照して現在の時刻に応じた番組コンテンツの該当部分のデータを特定し、ストリーミングサーバ１０３０に対して配信すべきデータを記憶部１０２０から取り出して受け渡し、ストリーミング配信を制御する部分である。
記憶部１０２０に記憶されている番組コンテンツデータはストリーミング配信に適した形式に圧縮されたエンコード済みのコンテンツデータとなっている。番組コンテンツとしては撮影したビデオ映像、編集したビデオ映像、ＣＧアニメーションなど多様のものがある。
ストリーミングサーバ１０３０は送信制御部１０１０から配信するデータを受けてストリーミングデータとして配信する。ネットワークとのインターフェイスも備えている。
再生リスト１０４０は番組コンテンツの再生順序を記述したものであり、再生する時間情報を持つことも可能である。つまり、配信する番組コンテンツとその配信予定時間が記述されており、いわゆるテレビ欄などの番組配信表と位置付けることもできる。
【０００５】
番組コンテンツデータの配信の流れは以下のようになる。
送信制御部１０１０は再生リスト１０４０を参照しつつ、現在時刻に配信すべきコンテンツの該当部分のデータを特定する。例えば番組コンテンツデータＡの終盤部分であったとすると記憶部１０２０からエンコード済コンテンツＡ１０２１Ａの該当部分のデータを取得する。送信制御部１０１０は取得した該当部分のデータをストリーミングサーバ１０３０に渡し、ストリーミングサーバ１０３０からクライアントシステムに対してストリーミングデータが配信される。
時刻が進むたび、送信制御部１０１０は再生リスト１０４０を参照し、現在時刻に配信されるべき番組コンテンツの該当部分のデータを特定し、記憶部１０２０から当該データを取得してストリーミングサーバ１０３０に渡す。
このように、再生リスト１０４０の記述に従って次々と、エンコード済コンテンツＡ、エンコード済コンテンツＢ、エンコード済コンテンツＣとストリーミング配信されて行き、クライアントシステムでは再生リスト１０４０があたかもＴＶ番組の配信予定リストのように位置付けられる。
【０００６】
【特許文献１】特開２００１−５４０９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記従来のストリーミング配信型の番組配信システムによれば、従来のコンテンツ転送型の番組配信システムのような長時間の待ち時間がなく、実用に耐えるシステムとして普及しつつある。代表的なアプリケーションはインターネットテレビジョン放送である。
しかし、従来のストリーミング配信技術では、テレビジョン放送のようにあらかじめ決められた配信予定リストに従って時刻通りに番組コンテンツをストリーミング配信する場合、番組コンテンツ配信の連続性が完全には保てず、クライアントシステムのモニタでの表示において、番組コンテンツの配信開始時のみならず、番組コンテンツと番組コンテンツの谷間においても毎回、「黒み」や「切れ目」のバッファリングが生じてしまう現象が知られている。
まず、ストリーミング配信の開始時にバッファリングが発生する理由について説明し、次に従来のストリーミング配信技術において番組コンテンツと番組コンテンツの谷間において「黒み」や「切れ目」が生じる理由について説明する。
【０００８】
図１３は従来のストリーミング配信の開始時においてバッファリング発生する理由を模式的に示す図である。
番組配信システム１０００は、記憶部１０２０、番組コンテンツのエンコード済コンテンツ１０２１、ストリーミングサーバ１０３０を備えている。クライアントシステム１１００は受信部１１１０およびバッファ１１２０を備えている。番組配信システム１０００とクライアントシステム１１００はネットワーク１２００を介してつながっている。
【０００９】
まず、クライアントシステム１１００から番組配信システム１０００に番組配信の要求が出され（図１３の［１］ストリーミング要求）、番組配信システム１０００が要求にかかる番組コンテンツデータ１０２１を記憶部１０２０から読み出してストリーミングデータとして送信を開始する（図１３の［２］ストリーミング開始）。クライアントシステム１１００は要求した番組コンテンツデータ１０２１を受信し始めた直後にバッファ１１２０を用いて所定数のフレームデータのバッファリング処理を行なう（図１３の［３］バッファリング）。バッファリングを行なう理由は幾つかあるが、ここではバッファリングの理由としてデータ転送状態の変動緩衝と新たなコンテンツ再生に向けた再生ソフトの調整時間確保を挙げておく。
【００１０】
まず、データ転送状態は常に均一というわけではなく回線状態によって若干の変動がある。ストリーミングデータは逐次連続的に送られてくるデータを逐次連続的に再生表示するものであり、一瞬、データ転送が遅れたり途切れたりするとクライアント１１１０のモニタ表示が不安定になるという不具合が発生する。そのため、あらかじめ所定数のフレームデータをバッファに蓄積してから再生表示するという緩衝を持たせる工夫を行なう。このデータ転送状態の変動緩衝のバッファリングを行なうために即座に表示ができず「黒み」や「切れ目」が生じる。
【００１１】
次に、再生されるデータ形式は常に一定というわけではなく受信データに合わせて再生ソフトのパラメタなどを調整する必要がある。受信コンテンツのヘッダを読み込めば新たなコンテンツ再生に向けた処理を開始し、ヘッダのコンテンツ情報を利用して再生ソフトのパラメタを調整する。特に、ストリーミングデータの場合、再生ソフトにおける映像レート（映像ビットレート）と音声レート（音声サンプリングレート）のパラメタ調整は重要である。この再生ソフトの調整時間中に受信したデータを一時的にバッファリングするため「黒み」や「切れ目」が生じる。
バッファ１１２０に所定データ量のバッファリングができれば、所定の再生ソフトウェアにより再生を始める（図１３の［４］モニタ表示開始）。
【００１２】
ここで、従来のストリーミング配信技術では、番組コンテンツと番組コンテンツの谷間においてもバッファリングに伴う「黒み」や「切れ目」が生じる現象が毎回生じるという問題が知られている。
上記のような番組コンテンツと番組コンテンツの谷間においてバッファリング処理に伴う「黒み」や「切れ目」が発生することは好ましくなく、通常の地上波や衛星波のテレビジョン放送ではこのような「黒み」や「切れ目」が発生しないことからインターネット放送の弱点の一つとされている。また、この番組と番組の谷間は、広告コンテンツを流すいわゆる広告枠であることが通例であり、数秒間の「黒み」や「切れ目」であってもその影響は大きいと言わざるを得ない。
【００１３】
なお、上記問題は、近年のネットワーク環境の発達と、情報発信主体の多様化に伴い、番組コンテンツを一箇所で集中的に製作する環境ではなく、ネットワークを介して、ローカルシステムで作成した多様な番組コンテンツデータをセンタシステム側で収集するとともに収集した番組コンテンツデータの配信順序などをセンタシステム側で動的かつ柔軟に編集・変更するという環境では番組コンテンツ間の映像レートや音声レートが異なることが多く、避けがたい問題となる。
【００１４】
上記問題点に鑑み、本発明は、配信したストリーミングデータのクライアントシステムでの表示において、シームレスで連続した番組コンテンツの視聴を確保する番組配信システムを提供することを目的とする。
特に、番組コンテンツを一箇所で集中的に製作する環境ではなく、ネットワークを介して、ローカルシステムで作成した多様な番組コンテンツデータを収集するとともに収集した番組コンテンツデータの配信順序などを動的かつ柔軟に編集・変更する環境での適用が可能である番組配信システムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
上記目的を達成するため、本発明の番組配信システムは、
起動時にゼロクリアされ経過時間をシステムタイムとしてカウントしてゆくシステムタイマと、
複数個のエンコード済み配信コンテンツを記憶したコンテンツ記憶部と、
前記配信コンテンツの配信予定リストを編集する配信予定リスト編集部と、
前記配信予定リストに従い配信開始時刻に達した前記配信コンテンツを前記コンテンツ記憶部から読み込んで動的にデコード処理するデコード部と、
前記デコード部が逐次にデコード処理しているフレームデータを逐次に受け取り、先頭フレームに対しては前記配信開始時刻における前記システムタイムの値を付与し、各後続フレームに対しては前記先頭フレームに付与された前記システムタイムの値に前記各後続フレームに予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間を合算した値を付与することにより、各フレームデータに対して通しフレーム番号情報を与えるフレーム番号管理部と、
前記フレーム番号管理部により通しフレーム番号が与えられたフレームデータを逐次に受け取り、次々と動的に所定の音声レートと映像レートにて再びエンコード処理する再エンコード部と、
前記再エンコード部から供給されるデータをストリーミング配信するストリーミング配信部とを備えたものである。
【００１６】
なお、上記番組配信システムにおいて、前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、前記配信予定リスト編集部が、前記番組コンテンツ間に前記広告コンテンツを挟み込む形で配信予定リストを編集することが好ましい。
【００１７】
また、上記番組配信システムにおいて、前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、前記配信予定リスト編集部が、一つの前記番組コンテンツを複数個に分割し、その間に前記広告コンテンツを挟み込む形で配信予定リストを編集することが好ましい。
【００１８】
上記構成により、番組と番組の間においてクライアントシステムの表示において黒みや切れ目などを生じさせることなくシームレスで連続した番組コンテンツの視聴を確保することができ、さらに、番組配信の内容・順序を動的に編集・変更することができ、柔軟な番組配信が可能となる。クライアントシステムにおいて番組コンテンツの谷間において黒味が発生することはない。
【発明の効果】
【００１９】
本発明の番組配信システムによれば、シームレスで連続した番組コンテンツの視聴を確保するとともに番組配信の内容・順序の動的で柔軟な編集・変更が可能となる。
【発明を実施するための最良の形態】
【００２０】
以下、図面を参照しつつ、本発明の番組配信システムの実施形態を説明する。ただし、本発明の技術的範囲は以下の実施形態に示した具体的な用途や形状・寸法などには限定されない。
【実施例１】
【００２１】
本発明の番組配信システムは、配信したストリーミングデータのクライアントシステムでの表示において、番組コンテンツと番組コンテンツの谷間において黒みや切れ目が生じることなく、シームレスで連続した番組コンテンツの視聴を確保するとともに番組配信の内容・順序の動的で柔軟な編集・変更を可能としたものである。
【００２２】
本発明の番組配信システムの説明にあたり、まず、最初に、［１］一般にストリーミング配信での番組コンテンツの谷間においてクライアントシステムの再生表示に黒みや切れ目が生じる理由を解析しておく。次に［２］本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理を説明する。次に［３］ローカルシステムとセンタシステムを用いたネットワーク分散環境における本発明の番組配信システムの構成例、次に［４］番組配信の流れについて説明する。
【００２３】
［１］番組コンテンツの谷間の再生において黒みや切れ目が生じる理由の解析
以下、一般にストリーミング配信において番組コンテンツと番組コンテンツの谷間においてクライアントシステムでの再生表示に黒みや切れ目が生じる理由を解析する。
【００２４】
番組コンテンツと番組コンテンツの谷間において黒みや切れ目を生じさせる原因は、後者の新たなコンテンツ再生に向けた「再生ソフトのパラメタ調整などのためのバッファリング」にあると考えられる。ここで、新たなコンテンツ再生に向けた再生ソフトの調整が必要になる場合としては、（ａ）新たなヘッダ受信があった場合と、（ｂ）先行する番組コンテンツと後続の番組コンテンツの映像レートと音声レートが異なる場合が考えられる。
【００２５】
図１を参照しつつ、一般のストリーミング配信の番組コンテンツの谷間におけるクライアントシステムでの再生に黒みや切れ目が生じる現象を説明する。
【００２６】
（ａ）新たなヘッダ受信に伴うバッファリング処理
例えば、先行の番組コンテンツＡが既に再生表示されているとする（図１（ａ））。ここで、先行の番組コンテンツＡの配信が終了し、後続の番組コンテンツＢのストリーミングデータが受信されたとする（図１（ｂ））。
後続の番組コンテンツＢのストリーミングデータの先頭にはヘッダが付されているので、再生ソフトウェアは当該ヘッダを受信することにより新たな番組コンテンツＢのストリーミング再生処理が始まることを認識し、新たなコンテンツ再生に向けて処理を開始する。現在普及している再生ソフトウェアは新たなコンテンツのヘッダを読み込めば、新たなストリーミング再生処理に向けた再生ソフトウェアのパラメタ調整の時間確保のため、現在バッファに存在する先行の番組コンテンツデータを破棄し、新たに後続の番組コンテンツデータのバッファリング処理を開始する仕組みとなっている（図１（ｂ））。このバッファリング処理の間「黒み」や「切れ目」が発生する。
【００２７】
（ｂ）番組コンテンツ間で映像レートと音声レートが異なる場合のバッファリング処理
一般的にはストリーミング配信されるデータの映像レートと音声レートは多様である。ニュース取材の過程で製作したビデオ映像、ミュージックビデオクリップ、アニメーション映像、コンピュータグラフィック映像など製作の過程や目的に応じて映像の画質と音声の音質にはバリエーションがある。クライアントシステムの再生ソフトは音声レートおよび映像レートに合わせてデコード・再生処理する必要があり、音声レートおよび映像レートの異なるエンコード済コンテンツが受信されるとクライアントシステムの再生ソフトは新たなレートに対応するためパラメタを調整する必要が生じる。
【００２８】
図１において、例えば先行の番組コンテンツＡの映像レートと音声レートがＲ１（例えば、映像レート１８０ｂｐｓ、音声レート７６ｂｐｓ）で既に再生表示されているとする（図１（ａ））。ここで、先行の番組コンテンツＡの配信が終了し、後続の番組コンテンツＢのストリーミングデータが受信されたとする（図１（ｂ））。この後続の番組コンテンツＢの映像レートと音声レートがＲ２（例えば、映像レート２２０ｂｐｓ、音声レート３６ｂｐｓ）であるとする。音声レートと映像レートが異なる場合は再生ソフトウェアのパラメタ調整などが必要となるので、再生ソフトウェアは映像レートと音声レートの違いを認識すれば新たな番組コンテンツデータの再生準備のため、現在バッファ中の先行の番組コンテンツデータを破棄し、新たな後続の番組コンテンツデータのバッファリング処理を開始する仕組みとなっている（図１（ｂ））。このバッファリング処理の間「黒み」や「切れ目」が発生する。
【００２９】
［２］本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理
次に、本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理を説明する。
【００３０】
本発明の番組配信システムでは、配信予定リストに従って現在時刻に応じて番組コンテンツコンテンツをデコード処理して一旦フレームデータとし、フレームデータを順々にフレーム番号管理部を通してフレーム通し番号情報を付した後に再エンコード部を通して再エンコードすることにより一定レートで配信することにより、動的にオンタイムでフレームデータを通し番号順に延々とつないで配信するものである。フレーム通し番号はもとの番組コンテンツコンテンツ単位ではなく、例えば一日の配信予定リストの朝の配信開始時刻から深夜の配信終了時刻まで一日単位のフレーム通し番号である。
本発明の番組配信システムでは、配信番組を一日の配信が開始された以後でも動的に変更し得るものであることが前提であるところ、各番組コンテンツには予め通し番号は付さず、配信時刻に達して配信処理を行なう段階で初めて各フレームに通し番号を付しつつ配信処理を行なうという特徴を持つ。
【００３１】
図２は、本発明の番組配信システムにおけるストリーミング配信の仕組みを模式的に説明する図である。
【００３２】
複数個のエンコード済みコンテンツが番組配信の素材となるデータである。エンコード済みコンテンツのエンコード形式はデコード部が対応可能な限り限定されない。ここではそれぞれのエンコード済みコンテンツＡ，Ｂ，Ｃが不統一であっても良い。
このエンコード済みコンテンツＡ，Ｂ，Ｃは、現時点で有効な配信予定リストに従って配信時刻になるとその順にデコード部４０に渡される。デコード部４０はエンコード済みコンテンツをデコード処理し、フレームデータ単位に分解してゆく。フレームデータ単位に分解されてしまえば各々のフレームデータは一枚の画像データであり、元のエンコード済みコンテンツの違いには依存しない。つまり、元のエンコード済みコンテンツがエンコード済みコンテンツＡであってもエンコード済みコンテンツＢであってもフレームデータにすると一枚の画像データである。
【００３３】
デコード部４０よりフレームデータ単位に分解されたフレームデータは次々にフレーム番号管理部５０に渡されてゆく。フレーム番号管理部５０は渡されたフレームデータに通し番号を付してゆく。ここで、通し番号とは番組配信システム一日の処理を通した通し番号のことを言う。たとえば、番組配信システムによりエンコード済みコンテンツＡ，Ｂ，Ｃの順に配信予定リストが変更されることなくそのまま配信される場合、エンコード済みコンテンツＡ，Ｂ，Ｃからデコードされたフレームデータに対して所定のルールにて動的に順々に通し番号が付される。
【００３４】
通し番号は以下の手順により付されてゆく。
デコード部４０は上記したように、現時点で有効な配信予定リストに従い配信開始時刻に達した配信コンテンツをコンテンツ記憶部から読み込んで動的にデコード処理を開始する。
フレーム番号管理部５０はデコード部４０からフレームデータを逐次に受け取り通し番号を付与して行くが、ここで、配信コンテンツの先頭フレームに対して通し番号を付与するルールと後続フレームに対して通し番号を付与するルールは異なる。
【００３５】
図３は先頭フレームおよび後続フレームに対して通し番号を付与するルールを模式的に説明する図である。
先頭フレームに対しては配信開始時刻においてシステムタイマ１０を参照してシステムタイムの値をそのまま通し番号として付与する。ここで、システムタイムとは、番組配信システムが起動された時点をゼロとしたシステム稼動の経過時間を言う。例えば、ミリ秒単位の数値とする。いま、番組配信システムが６：００に起動され番組Ａが配信開始された場合は、当該配信開始時刻においてシステムタイムを参照すると“０００００００（ｍｓｅｃ）”であり、番組Ａの先頭フレームには通し番号として“０００００００”が付与される。番組Ｂが７：００に配信されるならば当該配信開始時刻においてシステムタイムを参照すると“３６０００００（ｍｓｅｃ）”であり番組Ｂの先頭フレームには通し番号として“３６０００００”が付与される。同様に、番組Ｃが８：００に配信されるならば当該配信開始時刻においてシステムタイムを参照すると“７２０００００（ｍｓｅｃ）”であり番組Ｃの先頭フレームには通し番号として“７２０００００”が付与される。
【００３６】
次に、後続フレームに対しては、先頭フレームに通し番号として付与されたシステムタイムの値に、各後続フレームに予め与えられている番組内での再生タイミングであるタイムスタンプ時間を合算した値を付与する。通常、番組の各フレームには番組が再生表示開始されてから当該フレームが再生表示されるべきタイミング情報がタイムスタンプ情報として与えられている。つまり、各フレームにはそれが表示されるべき再生タイミング、例えば、３０フレーム／秒の場合、２フレーム目には“０００００３３（ｍｓｅｃ）”、３フレーム目には“０００００６７（ｍｓｅｃ）”、４フレーム目には“００００１００（ｍｓｅｃ）”というタイムスタンプ情報がもともと付されている。そこで、番組Ｂについては、先頭フレームには通し番号“３６０００００”が付与されているので、番組Ｂの第２フレームには合算値として通し番号“３６０００３３”、番組Ｂの第３フレームには合算値として通し番号“３６０００６７”、第４フレームには合算値として通し番号“３６００１００”が付与される。例えば、番組Ｃについては、先頭フレームには通し番号“７２０００００”が付与されているので、番組Ｃの第２フレームには合算値として通し番号“７２０００３３”、番組Ｃの第３フレームには合算値として通し番号“７２０００６７”、第４フレームには合算値として通し番号“７２００１００”が与えられるという具合である。
【００３７】
このように先頭フレームの通し番号と後続フレームの通し番号を付与する理由を以下に示す。
配信される番組コンテンツの後続フレームには、先頭フレームに与えられたシステムタイム（Ｔ）と予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間（Ｓ）を合算した値（Ｔ+Ｓ）を付与する。
【００３８】
まず、先頭フレームにはシステムタイム（Ｔ）を用いるので、配信番組間の順序制御と配信開始時間が正しく処理される。本発明の番組配信システムでは、配信番組を一日の配信が開始された以後でも動的に変更し得るものであることが前提であるところ、各番組コンテンツには予め通し番号は付さず、配信時刻に達して配信処理を行なう段階で初めて通し番号を付しつつ配信処理を行なう。番組コンテンツは現時点で有効な配信予定リスト上で配信時刻に達して始めてその先頭フレームにシステムタイム（Ｔ）を通し番号として付与するので、動的な変更を可能としつつ配信開始時間が正しく処理される。
【００３９】
次に、後続フレームに対してはタイムスタンプ時間（Ｓ）を用いるので、すべての後続フレームは、後続フレーム間の順序が正しく制御されるとともに配信を受けるローカルシステムにおける表示タイミングも正しく制御される。番組配信システム１００のリソース状態によりデコード処理にかかる時間はまちまちで番組配信システム内での処理は長短が生じるが、各フレームにはローカルシステム２００上で表示されるべきタイミング情報となるタイムスタンプ情報（Ｓ）が与えられているので、番組配信システム１００上でのデコード処理のタイミングがバラバラであっても配信を受けるローカルシステム２００上での再生表示は当該正しい表示タイミングにて再生できる。
【００４０】
もし、各後続フレームに対しても毎回システムタイマ１０を参照してシステムタイム（Ｔ）を通し番号として与えることを仮定すると、システムタイム（Ｔ）は必ず増加して行くので後続フレーム間の順序は正しく制御される。しかし、上記したように、番組配信システム１００のリソース状態によりデコード処理にかかる時間はまちまちで番組配信システム内での処理は長短が生じるため、配信処理の過程において毎回システムタイマ１０を参照してシステムタイム（Ｔ）を通し番号として与えると、後続フレーム間の時間間隔は一定ではなくなってしまう。そのため配信を受けたローカルシステム２００において再生表示を行なうと、本来は各フレームが１／３０秒のスピードで再生されるものが、あるフレームは１／３０秒よりも短く表示され、あるフレームは１／３０秒よりも長く表示されるなどの不具合が発生してしまう。
【００４１】
一方、タイムスタンプ情報（Ｓ）はローカルシステムにおける表示タイミングそのものであるので、通し番号としてタイムスタンプ情報（Ｓ）を用いることにより、ローカルシステムにおける表示タイミングは、後続フレーム間の時間間隔は正しい一定間隔で表示される。
【００４２】
ここで、タイムスタンプ情報（Ｓ）のみを通し番号とすると、番組コンテンツ内での順序制御と表示タイミングの制御は可能となるが、番組コンテンツをまたがる形での順序制御と表示タイミングの制御はできない。つまり、タイムスタンプ情報（Ｓ）は番組コンテンツの先頭フレームに対する相対的表示タイミングでしかないため、例えば１時間の番組Ａと１時間の番組Ｂのつなぎ目付近では、番組Ａの最後尾付近のフレームデータには３６０００００（ｍｓｅｃ）近くの大きな値のタイムスタンプ情報（Ｓ）が付されているはずである。一方、番組Ｂの先頭付近のフレームデータには０００００００（ｍｓｅｃ）近くの小さな値のタイムスタンプ情報（Ｓ）が付されているはずである。つまり、後続フレームに対してタイムスタンプ情報（Ｓ）のみを通し番号とすると、正しく順序制御ができない恐れがある。
【００４３】
そこで、本発明では、後続フレームに対して、先頭フレームに与えられたシステムタイム（Ｔ）とタイムスタンプ時間（Ｓ）を合算した値（Ｔ+Ｓ）を付与する。つまり、システムタイム（Ｔ）は必ず増加して行くところ、各番組が配信されるときに動的にシステムタイマ１０が参照されるので各番組の先頭フレームにはシステムタイム（Ｔ）が通し番号として与えられ、後続フレームには（Ｔ+Ｓ）という形で通し番号が与えられるので後続フレームは番組の配信開始時刻からの表示タイミングとして与えられる。例えば番組Ａと番組Ｂのつなぎ目付近においては、番組Ａの最後尾付近のフレームデータには、システム（Ｔ）が“０００００００”、タイムスタンプ（Ｓ）が３６０００００（ｍｓｅｃ）より小さな値であり、通し番号は（Ｔ＋Ｓ）は３６０００００（ｍｓｅｃ）より小さな値となる。例えば、番組Ａの最後のフレームデータには通し番号“３５９９９６７”が付与されたとする。一方、番組Ｂの先頭付近のフレームデータには、システム（Ｔ）が“３６０００００”、タイムスタンプ（Ｓ）は０００００００（ｍｓｅｃ）近くの小さな値であり、通し番号は（Ｔ＋Ｓ）は３６０００００よりも大きな値が付される。例えば、番組Ｂの先頭のフレームデータの通し番号は“３６０００００”、その次のフレームデータの通し番号“３６０００３３”として付される。つまり、番組Ａと番組Ｂをまたぐ形で、すべての先頭フレームと後続フレームの順序制御とローカルシステムでの表示タイミング制御が可能となる。
【００４４】
なお、もし、番組コンテンツＡの最後のフレームの処理が、システムリソースの状態により３３ｍｓｅｃ以上かかってしまった場合でもタイムスタンプ情報は変わらないので“３５９９９６７”が付与されることとなる。番組Ｂの先頭付近のフレームデータは、配信予定リストに従って７時つまり３６０００００（ｍｓｅｃ）の時点でシステムタイマを参照するので“３６０００００”が付与されることとなり、番組Ａの最後尾フレームと番組Ｂの先頭フレームの通し番号の順序が逆になることはない。
【００４５】
図２に戻り、再エンコード処理について述べる。配信番組リストに従ってデコードされたフレームデータに対して、各々のフレームデータは再エンコード部６０に次々に渡されてエンコードされて行く。ここでは模式的に前後３個のフレームデータがあればエンコードできるものとして図示しているが、採用するエンコード形式に従って必要なフレーム数を取り揃えてエンコードすることとなる。この際に各フレームデータは通し番号を手掛かりに正しく順序制御されてエンコードされる。ここで、エンコード済みコンテンツのつなぎ目においてもシームレスにつながれてエンコードされる。例えば、エンコード済みコンテンツＡとエンコード済みコンテンツＢのつなぎ目において、番組Ａの最後のフレームデータには通し番号“３５９９９６７”、番組Ｂの先頭のフレームデータの通し番号は“３６０００００”、その次のフレームデータの通し番号“３６０００３３”として付されているので再エンコード部６０における再エンコード処理ではエンコード済みコンテンツのつなぎ目がなくなりシームレスに連続するものとして編集される。
再エンコード部６０により再エンコードされた再エンコード済みデータは、ストリーミング配信部７０により番組コンテンツのつなぎ目が連続したものとしてストリーミング配信される。
【００４６】
ローカルシステム２００では、ストリーミング配信されたコンテンツデータをデコードしつつ再生表示して行く。各フレームには通し番号という形でタイムスタンプ情報が含まれており、ローカルシステム２００上では正しい表示タイミングにて表示される。
以上が本発明の番組配信システムのクライアントシステムの再生表示においてシームレスなストリーミング配信を実現する原理である。
【００４７】
［３］ローカルシステムとセンタシステムを用いたネットワーク分散環境における本発明の番組配信システムの構成例
次に、ローカルシステムとセンタシステムを用いたネットワーク分散環境における本発明の番組配信システムの構成例を説明する。
図４は、ローカルシステム２００とセンタシステム１００を用いたネットワーク分散環境における本発明の番組配信システムの構成例を示す図である。
図４の構成は、システムタイマ１０、タイマ１１、コンテンツ記憶部２０、配信予定リスト編集部３０、デコード部４０、フレーム番号管理部５０、再エンコード部６０、ストリーミング配信部７０を備えた構成となっている。
【００４８】
システムタイマ１０は上述したとおりである。
タイマは現在時刻を刻むものであり、デコード部４０が参照して現在時刻を把握し、配信予定リストでの各番組コンテンツの配信開始を検知するために用いる。
コンテンツ記憶部２０には複数個のエンコード済み配信コンテンツが記憶されている。この例ではエンコード済み配信コンテンツＡ，Ｂ，・・・，Ｌの１２個のコンテンツが記憶されている。なお、ローカルシステム２００からエンコード済みコンテンツがアップロードされ、当該アップロードされたエンコード済み配信コンテンツを格納することも好ましい。分散環境においてはローカルシステム２００側で配信番組を編集し、アップロードしてセンタシステム側から配信するという利用形態もあり得るからである。
【００４９】
配信予定リスト編集部３０は、配信コンテンツの配信予定リスト３１を編集する機能を備えている。図５は配信予定リスト３１を模式的に示したものである。配信予定リスト編集部３０は動的に配信コンテンツの配信予定リスト３１を編集できる。例えば図５に示すように、１０時から配信予定だった番組Ｅに代えて番組Ｍを配信したい場合、既に一日の配信が始まっている場合（例えば８時）であっても１０時に配信する予定の番組を動的に差し替えることができる。
【００５０】
デコード部４０が備えるデコード機能はコンテンツ記憶部２０内に記憶されているエンコード済みコンテンツのエンコード形式に対応するデコード処理ができるものであれば良い。番組配信システム１００全体で取り扱うエンコード形式が１種類に限定されておれば当該エンコード形式に対応するデコード機能を持てば良く、想定されるエンコード形式が３種類であれば３種類のデコード機能を持てば良い。たとえば、番組配信システム１００においてＷＭＦ、ＡＶＩ、ＭＰＥＧの３種類のエンコード形式が想定される場合、デコード部４０はそれぞれのデコード機能を備えれば良い。
【００５１】
フレーム番号管理部５０は上述したとおりである。
再エンコード部６０はフレーム番号管理部５０によりフレーム番号が与えられたフレームデータを逐次に受け取り、エンコード処理に必要な複数個のフレームデータが集積すると次々と動的に所定の音声レートと映像レートにて再びエンコード処理するものである。例えば、ＭＰＥＧでは前後複数枚のフレームを集めて非圧縮フレーム（Ｉフレーム）とイントラ圧縮フレーム（Ｐフレーム）とインター圧縮フレーム（Ｂフレーム）を決めて圧縮するので、１枚のフレームデータを入手しただけではエンコードできず、前後の複数枚のフレームを集めて圧縮するが、再エンコード部６０は必要な前後複数枚のフレームを受け入れて再エンコードする。
ストリーミング配信部７０は、再エンコード部６０から供給されるエンコード済みデータをストリーミング配信するものである。
【００５２】
［４］番組配信の流れ
実施例１に示した番組配信システムの番組配信の流れを整理しておく。
図６は実施例１にかかる番組配信システムのセンタシステムでの処理を中心とした処理の流れを示すフローチャートである。
前提として、コンテンツ記憶部２０には既にエンコード処理番組コンテンツが記憶されており、配信予定リスト３１の編集処理は完了しているものとする。
【００５３】
まず、配信開始に向けて番組配信システム１００を起動する（ステップＳ１）。例えば、朝６時に番組の配信が開始できるように番組配信システム１００を起動する。
この起動と同時にシステムタイマ１０の計数値が一旦ゼロクリアされ、経過時間のカウントアップを開始する（ステップＳ２）。番組配信システム１００の起動時から終了時まで途切れずに経過時間をカウントアップする。
【００５４】
次に、デコード部４０は現在時刻情報を得て、配信予定リスト３１にアクセスし、現在時刻に配信が行なわれる番組が何であるかを把握する（ステップＳ３）。例えばいま８時丁度に至ったとする。
デコード部４０は配信予定リスト３１から配信すべき番組コンテンツを把握し、コンテンツ記憶部２０にアクセスし、当該番組コンテンツのデコードを行なう（ステップＳ４）。いま、８時になり、新たな番組コンテンツＣの配信開始が検知され、デコード部４０がコンテンツ記憶部２０にアクセスし、番組コンテンツＣのコンテンツのデコードを開始したものとする。
【００５５】
デコード部４０のデコード処理によりフレームデータが次々と逐次に得られてゆくが、デコード部４０はそれらを逐次にフレーム番号管理部５０に渡して行く（ステップＳ５）。ここでは、番組コンテンツＣの先頭フレームから順に時系列にフレームがフレーム番号管理部５０に渡される。
【００５６】
次に、フレーム番号管理部５０は時系列に逐次にデコード部４０から渡されるフレームデータに対して、システムタイマ１０を参照してシステムタイムを得てその値を通し番号として与える（ステップＳ６）。例えば、番組コンテンツＣの先頭フレームデータに対して通しフレーム番号情報“７２０００００”を付与する。次のフレームデータに対してタイムスタンプの値を足し込んだ“７２０００３３”を通しフレーム番号情報として付与し、その後のフレームデータに対してもタイムスタンプが足し込まれた通し番号を順々に付与してゆく。
【００５７】
次に、フレーム番号管理部５０により通しフレーム番号情報が付されたフレームデータは再エンコード部６０に渡され、再エンコード部６０は所定の映像レートと音声レートにて再エンコード処理を行なう（ステップＳ７）。
ストリーミングサーバ７０は再エンコード部６０から再エンコード処理したデータを受け取り、クライアントシステム２００に対して番組コンテンツデータを配信する（ステップＳ８）。つまり、現在時刻に合わせて配信すべきデータがストリーミングサーバ７０からクライアントシステム２００に対してシームレスなストリーミングデータとして配信され続ける。
時刻が進むたび上記処理を繰り返す（ステップＳ３へ戻る）。
以上がストリーミングデータ配信の流れの概要である。
【００５８】
なお、クライアントシステム２００の再生表示において番組コンテンツ間の谷間で「黒み」、「切れ目」を生じることはない。
図７は本発明の第１の番組配信システム１００からストリーミング配信された番組コンテンツのクライアントコンピュータでの再生処理を模式的に示す図である。
【００５９】
番組コンテンツＡの最終部分のストリーミング配信の処理（図７（ａ））に引き続き、番組コンテンツＢの冒頭部分のストリーミング配信処理が行なわれる（図７（ｂ））。ここで、番組コンテンツＣの終端部分と番組コンテンツＤの冒頭部分の谷間においてヘッダやフッタは存在せずかつ同じ統一規約のレートＲ０であるのでストリーミングサーバ７０からシームレスに連続するデータとして配信される。クライアントシステム２００においては、番組コンテンツＣの終端部分と番組コンテンツＤの冒頭部分はまったくシームレスで連続したデータとして供給されるので、再生ソフトによる再生処理もシームレスに行なわれ、モニタ上には連続な映像として表示される。つまり、番組コンテンツＣと番組コンテンツＤの谷間において「黒み」や「切れ目」が生じることはなく、所定の時刻に所定の内容の番組コンテンツが表示され、あたかもＴＶ番組を視聴する如くの表示環境が得られる（図７（ｂ）モニタ表示）。
【００６０】
次に、番組配信の動的編集機能について説明する。
まず比較のために配信予定リスト編集部３０による変更がない場合の配信を説明する。図８は、１０時における配信予定リスト編集部３０による変更がなく、当初の配信予定リスト３１の通り、番組コンテンツＥが配信される場合の流れを模式的に示す図である。
【００６１】
デコード部４０により１０時直前まで番組コンテンツＤがデコードされており、１０時になるとデコード部４０は番組コンテンツＥがデコードされる。フレーム番号管理部５０が通しフレーム番号を付して行くが、番組コンテンツＥの配信が当初の予定どおりで合った場合、番組コンテンツＤの最終フレームに付される通しフレーム番号が“１４３９９９６７”、番組コンテンツＥの先頭フレームに付される通しフレーム番号が“１４４０００００”であり、番組コンテンツＤと番組コンテンツＥのつなぎ目においても通しフレーム番号は連続したものとなっており、番組コンテンツ内のフレームデータ同士のつながりも番組コンテンツ間のフレームデータ同士のつながりも同じものとなっている。このフレームデータを順に再エンコードして行くことにより番組コンテンツＤと番組コンテンツＥの間がシームレスなストリーミングデータとして配信される。
【００６２】
次に、図５に示したように、当初、配信予定リスト３１において１０時に配信される番組の予定が番組コンテンツＥであったものが配信予定リスト編集部３０により番組コンテンツＭに変更されたものとする。図９は、配信予定リスト編集部３０によって１０時における配信予定リスト３１が編集され、番組コンテンツＥに代え、番組コンテンツＭが配信される場合の流れを模式的に示す図である。
【００６３】
デコード部４０により１０時直前まで番組コンテンツＤがデコードされており、１０時になるとデコード部４０は番組コンテンツＭがデコードされる。フレーム番号管理部５０が通しフレーム番号を付して行くが、この例でも、番組コンテンツＤの最終フレームに付される通しフレーム番号が“１４３９９９６７”、番組コンテンツＭの先頭フレームに付される通しフレーム番号が“１４４０００００”となり、番組コンテンツＤと番組コンテンツＭのつなぎ目においても通しフレーム番号は連続したものとなっており、配信される番組コンテンツが番組コンテンツＥから番組コンテンツＭに変更されたとしても番組コンテンツ間のフレームデータ同士のつながりは同じものとなっている。つまり、この動的編集された場合でもフレームデータを順に再エンコードして行くことにより番組コンテンツＤと番組コンテンツＭの間がシームレスなストリーミングデータとして配信される。
【００６４】
以上、実施例１の番組配信システムによれば、番組と番組の間においてクライアントシステムの表示において黒みや切れ目などを生じさせることなくシームレスで連続した番組コンテンツの視聴を確保することができ、さらに、番組配信の内容・順序を動的に編集・変更することができ、柔軟な番組配信が可能となる。クライアントシステムにおいて番組コンテンツの谷間において黒味が発生することはない。
【実施例２】
【００６５】
実施例２では、本発明の番組配信システムにおいて、広告コンテンツを挿入する方法について説明する。
第１の方法は、単純に配信コンテンツの一つとして広告コンテンツを位置づける方法である。本発明の番組配信システムでは、配信コンテンツの内容が、映画などのコンテンツか広告などのコンテンツかの違いには依存しないので、広告コンテンツを挿入することができる。
図１０に示すように、例えば、４つの配信コンテンツのうち第１番目の配信コンテンツを番組コンテンツＡとし、第２番目の配信コンテンツを広告コンテンツＡとし、第３番目の配信コンテンツを広告コンテンツＢとし、第４番目の配信コンテンツを番組コンテンツＢとした例である。番組コンテンツの配信、広告コンテンツの配信は実施例１に示したように処理され、シームレスなストリーミングとして配信される。
ただし、この方法では、番組コンテンツ自体は、配信が始まるとその配信が終わるまで広告を挿入することはできない。つまり、２時間の映画を配信する場合、２時間は映画を流し続け、その後でないと広告を配信することはできない。
【００６６】
次に、第２の方法は、一かたまりの番組コンテンツを前編集により分割し、複数のサブコンテンツに分割しておき、そのサブコンテンツの間に広告コンテンツを挿入する方法である。現在の一般のテレビジョン放送では映画などを放送する場合、１５分きざみ程度で分割し、その間に広告を挿入する方式が一般的であるが、この第２の方法は、番組コンテンツを複数のサブコンテンツに分割して広告を挿入するものであり、現在のテレビジョン放送と近い広告の挿入方法と言える。
【００６７】
図１１に示すように、例えば、前編集により配信コンテンツＡを４つに分割し、「番組Ａの前半１」、「番組Ａの前半２」、「番組Ａの後半１」、「番組Ａの後半２」の４つのサブコンテンツとしておき、サブコンテンツの間に広告コンテンツＡ、広告コンテンツを挟む。番組のサブコンテンツの配信、広告コンテンツの配信は実施例１または実施例２に示したように処理され、シームレスなストリーミングとして配信される。
【００６８】
以上、実施例２の番組配信システムによれば、広告コンテンツを番組コンテンツの間に挿入することができ、かつ、クライアントシステムの表示において黒みや切れ目などを生じさせることなくシームレスで連続した番組コンテンツおよび広告コンテンツの視聴を確保することができ、柔軟な番組配信が可能となる。クライアントシステムにおいて番組コンテンツと広告コンテンツの谷間において黒味が発生することはない。
【００６９】
以上、本発明の番組配信システムにおける好ましい実施形態を図示して説明してきたが、本発明の技術的範囲を逸脱することなく種々の変更が可能であることは理解されるであろう。
【産業上の利用可能性】
【００７０】
本発明は番組配信システムに適用することができる。特に、インターネットを利用したインターネット放送などに適用することができる。
【図面の簡単な説明】
【００７１】
【図１】ヘッダが存在する場合、レートが異なる場合の番組コンテンツの谷間での黒みの発生の理由を説明する図
【図２】本発明の番組配信システムにおけるストリーミング配信の仕組みを模式的に説明する図
【図３】先頭フレームおよび後続フレームに対して通し番号を付与するルールを模式的に説明する図
【図４】ローカルシステム２００とセンタシステム１００を用いたネットワーク分散環境における本発明の番組配信システムの構成例を示す図
【図５】配信予定リスト３１を模式的に示した図
【図６】実施例１にかかる番組配信システムのセンタシステムでの処理を中心とした処理の流れを示すフローチャート
【図７】本発明の第１の番組配信システム１００からストリーミング配信された番組コンテンツのクライアントコンピュータでの再生処理を模式的に示す図
【図８】当初の配信予定リスト３１の通り、番組コンテンツＥが配信される場合の流れを模式的に示す図
【図９】番組コンテンツＥに代え、番組コンテンツＭが配信される場合の流れを模式的に示す図
【図１０】第１の広告コンテンツの挿入方法の具体例を模式的に示す図
【図１１】第２の広告コンテンツの挿入方法の具体例を模式的に示す図
【図１２】従来のストリーミング配信型の番組コンテンツデータの配信の流れを模式的に示した図
【図１３】従来のストリーミング配信の開始時においてバッファリング発生する理由を模式的に示す図
【符号の説明】
【００７２】
１０ システムタイマ
２０ コンテンツ記憶部
３０ 配信予定リスト編集部
３１ 配信予定リスト
４０ デコード部
５０ フレーム番号管理部
６０ 再エンコード部
７０ ストリーミングサーバ
１００ センタシステム
２００ ローカルシステム
【特許請求の範囲】
【請求項１】
起動時にゼロクリアされ経過時間をシステムタイムとしてカウントしてゆくシステムタイマと、
複数個のエンコード済み配信コンテンツを記憶したコンテンツ記憶部と、
前記配信コンテンツの配信予定リストを編集する配信予定リスト編集部と、
前記配信予定リストに従い配信開始時刻に達した前記配信コンテンツを前記コンテンツ記憶部から読み込んで動的にデコード処理するデコード部と、
前記デコード部が逐次にデコード処理しているフレームデータを逐次に受け取り、先頭フレームに対しては前記配信開始時刻における前記システムタイムの値を付与し、各後続フレームに対しては前記先頭フレームに付与された前記システムタイムの値に前記各後続フレームに予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間を合算した値を付与することにより、各フレームデータに対して通しフレーム番号情報を与えるフレーム番号管理部と、
前記フレーム番号管理部により通しフレーム番号が与えられたフレームデータを逐次に受け取り、次々と動的に所定の音声レートと映像レートにて再びエンコード処理する再エンコード部と、
前記再エンコード部から供給されるデータをストリーミング配信するストリーミング配信部とを備えた番組配信システム。
【請求項２】
前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、
前記配信予定リスト編集部が、前記番組コンテンツ間に前記広告コンテンツを挟み込む形で配信予定リストを編集することを特徴とする請求項１に記載の番組配信システム。
【請求項３】
前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、
前記配信予定リスト編集部が、一つの前記番組コンテンツを複数個に分割し、その間に前記広告コンテンツを挟み込む形で配信予定リストを編集することを特徴とする請求項１または２に記載の番組配信システム。
【請求項４】
起動時にシステムタイマをゼロクリアし、経過時間をシステムタイムとしてカウントしてゆくシステムタイム処理ステップと、
コンテンツ記憶部に複数個のエンコード済み配信コンテンツを記憶するコンテンツ記憶処理ステップと、
前記配信コンテンツの配信予定リストを編集する配信予定編集処理ステップと、
前記配信予定リストに従い配信開始時刻に達した前記配信コンテンツを前記コンテンツ記憶部から読み込んで動的にデコード処理するデコード処理ステップと、
前記デコード処理ステップにより逐次にデコード処理されたフレームデータを逐次に受け取り、先頭フレームに対しては前記配信開始時刻における前記システムタイムの値を付与し、各後続フレームに対しては前記先頭フレームに付与された前記システムタイムの値に前記各後続フレームに予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間を合算した値を付与することにより、各フレームデータに対して通しフレーム番号情報を与えるフレーム番号管理処理ステップと、
前記フレーム番号管理処理ステップによりフレーム番号が与えられたフレームデータを逐次に受け取り、次々と動的に所定の音声レートと映像レートにて再びエンコード処理する再エンコード処理ステップと、
前記再エンコード処理ステップから供給されるデータをストリーミング配信するストリーミング配信処理ステップとを備えた番組配信プログラム。
【請求項１】
起動時にゼロクリアされ経過時間をシステムタイムとしてカウントしてゆくシステムタイマと、
複数個のエンコード済み配信コンテンツを記憶したコンテンツ記憶部と、
前記配信コンテンツの配信予定リストを編集する配信予定リスト編集部と、
前記配信予定リストに従い配信開始時刻に達した前記配信コンテンツを前記コンテンツ記憶部から読み込んで動的にデコード処理するデコード部と、
前記デコード部が逐次にデコード処理しているフレームデータを逐次に受け取り、先頭フレームに対しては前記配信開始時刻における前記システムタイムの値を付与し、各後続フレームに対しては前記先頭フレームに付与された前記システムタイムの値に前記各後続フレームに予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間を合算した値を付与することにより、各フレームデータに対して通しフレーム番号情報を与えるフレーム番号管理部と、
前記フレーム番号管理部により通しフレーム番号が与えられたフレームデータを逐次に受け取り、次々と動的に所定の音声レートと映像レートにて再びエンコード処理する再エンコード部と、
前記再エンコード部から供給されるデータをストリーミング配信するストリーミング配信部とを備えた番組配信システム。
【請求項２】
前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、
前記配信予定リスト編集部が、前記番組コンテンツ間に前記広告コンテンツを挟み込む形で配信予定リストを編集することを特徴とする請求項１に記載の番組配信システム。
【請求項３】
前記配信コンテンツが、番組コンテンツのコンテンツである番組コンテンツと、広告コンテンツのコンテンツである広告コンテンツを含み、
前記配信予定リスト編集部が、一つの前記番組コンテンツを複数個に分割し、その間に前記広告コンテンツを挟み込む形で配信予定リストを編集することを特徴とする請求項１または２に記載の番組配信システム。
【請求項４】
起動時にシステムタイマをゼロクリアし、経過時間をシステムタイムとしてカウントしてゆくシステムタイム処理ステップと、
コンテンツ記憶部に複数個のエンコード済み配信コンテンツを記憶するコンテンツ記憶処理ステップと、
前記配信コンテンツの配信予定リストを編集する配信予定編集処理ステップと、
前記配信予定リストに従い配信開始時刻に達した前記配信コンテンツを前記コンテンツ記憶部から読み込んで動的にデコード処理するデコード処理ステップと、
前記デコード処理ステップにより逐次にデコード処理されたフレームデータを逐次に受け取り、先頭フレームに対しては前記配信開始時刻における前記システムタイムの値を付与し、各後続フレームに対しては前記先頭フレームに付与された前記システムタイムの値に前記各後続フレームに予め与えられている先頭フレームからの経過時間であるタイムスタンプ時間を合算した値を付与することにより、各フレームデータに対して通しフレーム番号情報を与えるフレーム番号管理処理ステップと、
前記フレーム番号管理処理ステップによりフレーム番号が与えられたフレームデータを逐次に受け取り、次々と動的に所定の音声レートと映像レートにて再びエンコード処理する再エンコード処理ステップと、
前記再エンコード処理ステップから供給されるデータをストリーミング配信するストリーミング配信処理ステップとを備えた番組配信プログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【公開番号】特開２００８−１９３６１６（Ｐ２００８−１９３６１６Ａ）
【公開日】平成２０年８月２１日（２００８．８．２１）
【国際特許分類】
【出願番号】特願２００７−２８６２５（Ｐ２００７−２８６２５）
【出願日】平成１９年２月７日（２００７．２．７）
【出願人】（３０１０６６３４９）株式会社シービット (2)
【Ｆターム（参考）】
【公開日】平成２０年８月２１日（２００８．８．２１）
【国際特許分類】
【出願日】平成１９年２月７日（２００７．２．７）
【出願人】（３０１０６６３４９）株式会社シービット (2)
【Ｆターム（参考）】
[ Back to top ]