(57)【要約】【課題】受信したストリームの内容を大きな負荷がないようにチェックし、バッファのサイズを適度なものにするとともに、ネットワークの不具合への耐性を安定化することを目的とする。【解決手段】ストリーミング端末１０２は、ストリーム受信部２０１において、サーバー１０１とコンテンツの再生開始および再生中のストリーム制御について通信を行い（図４のステップ１）、かつ、サーバーから送られてきたストリームデータを受信し、ストリームバッファリング部２０２に送る（図４のステップ２）。ストリームバッファリング部２０２は送られたストリームの所定の同期信号を検出し（図４のステップ３）、その情報から得られる所定の位置からバッファ２０３にストリームデータを書き込み（図４のステップ４）、所定のデータ量をバッファリングした後に復号処理を開始するようにデコード部２０４へ通知する（図４のステップ５）。【選択図】図４
2005167893.tif 000002
【特許請求の範囲】
【請求項１】
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記バッファリング手段が、ストリーム内の同期コードを検出し、前記同期コードから得られる所定の位置までのデータはバッファリングせずに、前記所定の位置以降のデータをバッファリングすることを特徴とするストリーミング端末におけるデータバッファリング方法。
【請求項２】
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記バッファリング手段が、ストリーム内の同期コードを検出し、前記同期コードから得られる所定の位置までのデータはバッファリングせずに、前記所定の位置以降のデータをバッファリングし、かつ、前記デコード手段がデコードを開始する契機を前記同期コードから算出できる所定量のデータをバッファリングしたときとすることを特徴とするストリーミング端末におけるデータバッファリング方法。
【請求項３】
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段を有し、
前記バッファリング手段が、バッファリングを行いながらストリーム内の同期コードを検出し、前記デコード手段がデコードを開始する契機を前記同期コードから算出できる所定量のデータをバッファリングしたときとすることを特徴とするストリーミング端末におけるデータバッファリング方法。
【請求項４】
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記バッファリング手段が、バッファリングを行いながらストリーム内の同期コードを検出し、バッファ内の同期コードを記録した位置情報を一時記憶し、前記デコード手段がデコードを開始する契機を前記同期コードから算出できる所定量のデータをバッファリングした後とし、かつ、前記デコード手段が、前記一時記憶された同期コードの記録位置情報をもとにデコード開始時に使用するストリームの開始位置を決めることを特徴とするストリーミング端末におけるデータバッファリング方法。
【請求項５】
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記サーバーから送られてくるストリームがセキュリティ強化のために、所定の単位での順番入れ替え（インターリーブ）が行われたものである場合に、前記バッファリング手段が、インターリーブの１周期の開始位置を検出し、インターリーブの周期の先頭からバッファリングを開始することを特徴とするストリーミング端末におけるデータバッファリング方法。
【請求項６】
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記サーバーから送られてくるストリームがセキュリティ強化のために、所定の単位での順番入れ替え（インターリーブ）が行われたものである場合に、前記バッファリング手段が、インターリーブの１周期の開始位置を検出し、インターリーブの周期の先頭からバッファリングを開始し、かつ、前記デコード手段がデコードを開始する契機を前記周期から算出できる所定量のデータをバッファリングした時とすることを特徴とするストリーミング端末におけるデータバッファリング方法。
【請求項７】
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記サーバーから送られてくるストリームがセキュリティ強化のために、所定の単位での順番入れ替え（インターリーブ）が行われたものである場合に、前記バッファリング手段が、バッファリングを行いながらインターリーブの１周期の開始位置を検出し、バッファ内にインターリーブの先頭を記録した位置情報を一時記憶するものであり、かつ、前記デコード手段がデコードを開始する契機を前記周期から算出できる所定量のデータをバッファリングした後とし、前記デコード手段が、前記一時記憶されたインターリーブの先頭を記録した位置からデコードを開始することを特徴とするストリーミング端末におけるデータバッファリング方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、映像信号と音声信号として再生できるストリーミング端末におけるデータバッファリング方法に関するものである。
【背景技術】
【０００２】
従来、インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、映像信号と音声信号として再生するためのストリーミング端末がある。
【０００３】
従来のストリーミング端末における再生方法を図１と図２および図１０を用いて説明する。
【０００４】
図１は、インターネット上のデジタルストリーミング放送システムを示すブロック図である。図１において、１０１は複数のデジタルストリーミングコンテンツを有するサーバー、１０２はコンテンツを受信再生するストリーミング端末である。
【０００５】
サーバー１０１は、コンテンツもしくはコンテンツの付加情報（メタファイル）をインターネット上にブラウザとして公開する機能を有するか、もしくは、他のサーバーがインターネット上にブラウザとして公開したアンカーからコンテンツもしくはコンテンツの付加情報にリンクが張れる機能を有している。
【０００６】
ストリーミング端末１０２は、ブラウザ上のコンテンツを選択し、コンテンツの配信をサーバー１０１に要求する。その後、サーバー１０１からのストリームを受けたストリーミング端末１０２はストリームを再生した映像信号および音声信号を出力する。
【０００７】
図２はストリーミング端末１０２内部の構成を説明する図である。図２において、２０１はストリーム受信部、２０２はストリームバッファリング部、２０３はバッファ、２０４はデコード部、２０５は出力部である。
【０００８】
以下、データバッファリング方法について、図１０のフローチャートに基づき説明する。
【０００９】
ストリーミング端末１０２は、ストリーム受信部２０１において、サーバー１０１と再生開始の手順および再生中のストリーム制御について通信を行い（図１０のステップ１）、かつ、サーバー１０１から送られてきたストリームデータを受信し、ストリームバッファリング部２０２に送る（図１０のステップ２）。ストリームバッファリング部２０２は、所定のバッファ２０３にストリームデータを書き込み（図１０のステップ３）、所定のデータ量をバッファリングした後に復号処理を開始するようにデコード部２０４へ通知する（図１０のステップ４）。デコード部２０４は、ストリームバッファリング部２０２からの復号処理開始の通知をうけ、バッファ２０３からデータを読み出し、所定の復号処理を行い映像信号と音声信号を出力する（図１０のステップ５）。出力部２０５は映像信号と音声信号を所定のフォーマットもしくはプロトコルに変換し出力する（図１０のステップ６）。
【００１０】
たとえば本例では、ストリームがＭＰＥＧ−２規格で定められたＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のものであり、出力はアナログ形式の映像信号および音声信号が出力されると仮定すると、デコード部２０４は、ＭＰＥＧ−２のＴｒａｎｓｐｏｒｔＳｔｒｅａｍを解析し、その中に含まれるＭＰＥＧ−２のビデオとオーディオのパケットを復号化することにより、デジタル映像信号とデジタル音声信号を出力する。そして、出力部２０５は、デジタル映像信号とデジタル音声信号をそれぞれデジタル−アナログ変換したアナログ形式の映像信号と音声信号を出力する。
【００１１】
特許文献１はストリーミング端末に関するものである。
【特許文献１】特開２００２−３４４９３６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１２】
しかしながら、従来のストリーミング端末におけるデータバッファリング方法では、ストリーミングバッファリング部２０２が、受信したデータを単にバッファ部２０３に書き込み、デコード部２０４が復号処理を開始するだけでは、バッファ２０３のデータ量の安定化および出力画質の安定化が行えないという課題を有していた。図３は、ＭＰＥＧ−２のビデオのデータ構造を示しており、ＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅ）とは、ＭＰＥＧ−２のビデオ圧縮規格に示された単位であり、ＧＯＰの先頭には、他のピクチャと相関を持たないＩピクチャという名前のフレームが存在する。ＧＯＰ内部には、複数のフレームの情報が圧縮されたコードが含まれているが、Ｉピクチャは１つだけであり、かつ、当該ＧＯＰはこのＩピクチャの情報がないと復号化できないという構成になっている。したがって、バッファリングされたデータがＧＯＰの途中からであった場合、次のＧＯＰの先頭のデータまでは、デコード部２０４は映像信号を出力できない。また、通常デコード部２０４は、復号化できないコードは通常以上のスピードでサーチしていきデコードできるコードを探そうとするために、毎回、復号処理開始時に消費するデータ量が異なる。このために、毎回一定量のデータをバッファしていても、どこから開始するかにより、再生開始後の安定状態となったバッファ２０３内のデータ量が異なることになる。これにより、再生開始時もしくは直後にバッファがアンダーフローする恐れがある。また、再生中でもバッファ量によってはアンダーフローする恐れがある。これに対応するためには、大き目のバッファを準備する必要がある。また、この再生中のバッファ２０３内のデータ量は、ネットワークにおける不具合の耐性の指標となるものであるために、これが毎回異なることはストリーミング端末に対して一定の耐性を持たせることが困難である。
【００１３】
本発明は、受信したストリームの内容を大きな負荷がないようにチェックし、バッファのサイズを適度なものにするとともに、ネットワークの不具合への耐性を安定化することを目的とする。
【課題を解決するための手段】
【００１４】
上記課題を解決するために、本発明の第１の発明のストリーミング端末におけるデータバッファリング方法は、
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記バッファリング手段が、ストリーム内の同期コードを検出し、前記同期コードから得られる所定の位置までのデータはバッファリングせずに、前記所定の位置以降のデータをバッファリングすることを特徴とするストリーミング端末におけるデータバッファリング方法であり、
本発明の第２の発明のストリーミング端末におけるデータバッファリング方法は、
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記バッファリング手段が、ストリーム内の同期コードを検出し、前記同期コードから得られる所定の位置までのデータはバッファリングせずに、前記所定の位置以降のデータをバッファリングし、かつ、前記デコード手段がデコードを開始する契機を前記同期コードから算出できる所定量のデータをバッファリングしたときとすることを特徴とするストリーミング端末におけるデータバッファリング方法であり、
本発明の第３の発明のストリーミング端末におけるデータバッファリング方法は、
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記バッファリング手段が、ストリーム内の同期コードを検出し、その情報を一時記憶した上でバッファリングを開始し、かつ、前記デコード手段が、前記一時記憶された同期コードの情報をもとにデコード開始時に使用するストリームの開始位置を前記バッファリングされたデータ内から選択することを特徴とするストリーミング端末におけるデータバッファリング方法であり、
本発明の第４の発明のストリーミング端末におけるデータバッファリング方法は、
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記バッファリング手段が、ストリーム内の同期コードを検出した上でバッファリングを開始し、かつ、前記デコード手段がデコードを開始する契機を前記同期コードから算出できる所定量のデータをバッファリングした後とすることを特徴とするストリーミング端末におけるデータバッファリング方法であり、
本発明の第５の発明のストリーミング端末におけるデータバッファリング方法は、
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段とを有し、
前記サーバーから送られてくるストリームがセキュリティ強化のために、所定の単位での順番入れ替え（インターリーブ）が行われたものである場合に、前記バッファリング手段が、インターリーブの１周期の開始位置を検出し、インターリーブの周期の先頭からバッファリングを開始することを特徴とするストリーミング端末におけるデータバッファリング方法であり、
本発明の第６の発明のストリーミング端末におけるデータバッファリング方法は、
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段を有し、
前記サーバーから送られてくるストリームがセキュリティ強化のために、所定の単位での順番入れ替え（インターリーブ）が行われたものである場合に、前記バッファリング手段が、インターリーブの１周期の開始位置を検出し、インターリーブの周期の先頭からバッファリングを開始し、かつ、前記デコード手段がデコードを開始する契機を前記周期から算出できる所定量のデータをバッファリングした時とすることを特徴とするストリーミング端末におけるデータバッファリング方法であり、
本発明の第７の発明のストリーミング端末におけるデータバッファリング方法は、
インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、少なくとも映像信号か音声信号のどちらかを再生できるストリーミング端末において、
前記コンテンツを有するサーバーから送られたストリームを受信する受信手段と、
受信したデータをバッファリングするバッファリング手段と、
バッファリングしたデータをデコードするデコード手段と
デコードした映像信号および音声信号を出力する出力手段を有し、
前記サーバーから送られてくるストリームがセキュリティ強化のために、所定の単位での順番入れ替え（インターリーブ）が行われたものである場合に、前記バッファリング手段が、インターリーブの１周期の開始位置を検出し、その情報を一時記憶するものであり、かつ、前記デコード手段がデコードを開始する契機を前記周期から算出できる所定量のデータをバッファリングした後とし、前記デコード手段が、前記一時記憶された開始位置からデコードを開始することを特徴とするストリーミング端末におけるデータバッファリング方法である。
【発明の効果】
【００１５】
本発明の第１の発明のストリーミング端末におけるデータバッファリング方法は、サーバーから配信された圧縮符号化されたストリーム内から圧縮符号化の同期を検出し、同期ポイントまでのデータはバッファリングせず、同期ポイント以降のデータからバッファリングすることによって、再生開始後のバッファ量を安定させることにより、再生品質の劣化を妨ぐことができ、
本発明の第２の発明のストリーミング端末におけるデータバッファリング方法は、サーバーから配信された圧縮符号化されたストリーム内から圧縮符号化の同期を検出し、同期ポイントからバッファリングし、かつ、同期ポイントから所定の同期周期分のデータをバッファリングした後に再生を開始することによって、再生開始後のバッファ量を安定させることにより、再生品質の劣化を妨ぐことができ、
本発明の第３の発明のストリーミング端末におけるデータバッファリング方法は、サーバーから配信された圧縮符号化されたストリーム内から圧縮符号化の同期を検出し、受信データは全てバッファリングするが、同期ポイントから所定の同期周期分のデータをバッファリングした後に再生することにより、再生開始後のバッファ量を安定させることにより、再生品質の劣化を妨ぐことができ、
本発明の第４の発明のストリーミング端末におけるデータバッファリング方法は、サーバーから配信された圧縮符号化されたストリーム内から圧縮符号化の同期を検出し、受信データは全てバッファリングするが、同期ポイントから所定の同期周期分のデータをバッファリングした後に再生し、かつ、受信データのバッファリングデータ内の同期ポイントをデコード部に通知し、デコード部は通知された同期ポイントからデコードすることにより、再生開始後のバッファ量を安定させることにより、再生品質の劣化を妨ぐことができ、
本発明の第５の発明のストリーミング端末におけるデータバッファリング方法は、サーバーで並べ替えられたストリーム内から並べ替えの同期を検出し、同期ポイントからバッファリングすることにより、再生開始後のバッファ量を安定させることにより、再生品質の劣化を妨ぐことができ、
本発明の第６の発明のストリーミング端末におけるデータバッファリング方法は、サーバーで並べ替えられたストリーム内から並べ替えの同期を検出し、同期ポイントからバッファリングし、かつ、同期ポイントから所定の同期周期分のデータをバッファリングした後に再生を開始することにより、再生開始後のバッファ量を安定させることにより、再生品質の劣化を妨ぐことができ、
本発明の第７の発明のストリーミング端末におけるデータバッファリング方法は、サーバーで並べ替えられたストリーム内から並べ替えの同期を検出し、受信データは全てバッファリングするが、同期ポイントから所定の同期周期分のデータをバッファリングした後に再生し、かつ、受信データのバッファリングデータ内の同期ポイントをデコード部に通知することにより、再生開始後のバッファ量を安定させることにより、再生品質の劣化を妨ぐことができる。
【発明を実施するための最良の形態】
【００１６】
以下、本発明の実施の形態を、図面を参照しながら説明する。
【００１７】
（実施の形態１）
図１から図３は従来の技術の説明で使用したものと同じものであるため、説明が重複する。
【００１８】
図４は本発明の実施の形態１におけるストリーミング端末におけるデータバッファリング方法を示すフローチャートである。
【００１９】
図１は、インターネット上のデジタルストリーミング放送システムを示すブロック図である。図１において、１０１は複数のデジタルストリーミングコンテンツを有するサーバー、１０２はコンテンツを受信再生する端末である。
【００２０】
サーバー１０１は、コンテンツもしくはコンテンツの付加情報（メタファイル）をインターネット上にブラウザとして公開する機能を有するか、もしくは、他のサーバーがインターネット上にブラウザとして公開したアンカーからコンテンツもしくはコンテンツの付加情報にリンクが張れる機能を有している。
【００２１】
ストリーミング端末１０２は、ブラウザ上のコンテンツを選択し、コンテンツの配信をサーバー１０１に要求する。その後、サーバー１０１からのストリームを受けたストリーミング端末１０２はストリームを再生した映像信号および音声信号を出力する。
【００２２】
図２はストリーミング端末１０２の内部の構成を説明する図である。図２において、２０１はストリーム受信部、２０２はストリームバッファリング部、２０３はバッファ、２０４はデコード部、２０５は出力部である。
【００２３】
以下、本実施の形態におけるデータバッファリング方法について、図４のフローチャートに基づき説明する。
【００２４】
ストリーミング端末１０２は、ストリーム受信部２０１において、サーバー１０１とコンテンツの再生開始および再生中のストリーム制御について通信を行い（図４のステップ１）、かつ、サーバーから送られてきたストリームデータを受信し、ストリームバッファリング部２０２に送る（図４のステップ２）。ストリームバッファリング部２０２は送られたストリームの所定の同期信号を検出し（図４のステップ３）、その情報から得られる所定の位置からバッファ２０３にストリームデータを書き込み（図４のステップ４）、所定のデータ量をバッファリングした後に復号処理を開始するようにデコード部２０４へ通知する（図４のステップ５）。デコード部２０４はストリームバッファリング部２０２からの復号処理開始の通知をうけ、バッファ２０３からデータを読み出し、所定の復号処理を行い映像信号と音声信号を出力する（図４のステップ６）。出力部２０５は映像信号と音声信号を所定のフォーマットもしくはプロトコルに変換し出力する（図４のステップ７）。
【００２５】
本実施の形態では、ストリームがＭＰＥＧ−２規格で定められたＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のものであり、出力はアナログ形式の映像信号および音声信号が出力されるとする。また、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ内に含まれている映像信号と音声信号は、それぞれＭＰＥＧ−２ビデオとＭＰＥＧ−１オーディオの規格で圧縮されたものであるとする。
【００２６】
そこで、ストリームバッファリング部２０２は、受信したＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデータを解析し、ＧＯＰの先頭を検出した所からバッファ２０３に受信データを書き込む。それまでの受信データは破棄する。ここから、例えば２ＧＯＰ分バッファリングを行ってからデコード部２０４に復号処理開始を通知する。つまり図３においてaのポイントから受信した場合には、ＧＯＰ３とＧＯＰ４のストリームをバッファ２０３に書き込んでからデコード部２０４に再生開始を通知する。
【００２７】
これにより、デコード部２０４は毎回ＧＯＰの先頭から復号処理を開始することになるので、バッファ２０３から読み出すデータ量も安定する。つまり、ＧＯＰの途中から復号処理を開始すると、次のＧＯＰの先頭までのデータは復号できないので、それまでは復号処理時に本来再生時に処理する速度より早くデータを処理してしまうが、そのようなことがない。また、ＧＯＰの先頭から復号処理を開始すると以後のバッファ２０３からの読み出し速度はネットワーク上でサーバーから送られてくるデータのスピードと等価なので、バッファ２０３内のデータ量は常に所定の時間分あることになる。つまり、この例の場合では常に２ＧＯＰ分のデータをもつようになる。ＧＯＰの途中から復号処理を開始すると、前記のようにバッファ２０３のデータを高速で処理してしまうために、溜めておいたデータが減ってしまうことになり、最悪アンダーフローしてバッファが空になることもあるが、本実施の形態ではそのようなことがない。
【００２８】
なお、本実施の形態では、ＧＯＰの先頭からバッファに書くとしたが、バッファに書くデータはＧＯＰの先頭を含むＴｒａｎｓｐｏｒｔＳｔｒｅａｍのパケットからでも良いし、ＧＯＰの先頭を含むＴｒａｎｓｐｏｒｔＳｔｒｅａｍより大きな通信系のパケットの先頭からでも良い。例えばＲＴＰ（Ｒｅａｌ−Ｔｉｍｅ  Ｔｒａｎｓｐｏｒｔ  Ｐｒｏｔｏｃｏｌ）のパケットでも良い。もしくは、ＧＯＰの先頭より前の近傍でも構わない。また、２ＧＯＰをバッファリングするとしたがいくつのＧＯＰのものでも良いし、ＧＯＰより下の階層であるピクチャ層まで検出し、数ピクチャバッファリングするとしても良い。
【００２９】
（実施の形態２）
図１と図２および図３において、実施の形態１と同様の動作をするものは、説明を省略する。
【００３０】
図５は本発明の実施の形態２におけるストリーミング端末におけるデータバッファリング方法を示すフローチャートである。
【００３１】
本実施の形態では、ストリームがＭＰＥＧ−２規格で定められたＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のものであり、出力はアナログ形式の映像信号および音声信号が出力されるとする。また、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ内に含まれている映像信号と音声信号は、それぞれＭＰＥＧ−２ビデオとＭＰＥＧ−１オーディオの規格で圧縮されたものであるとする。
【００３２】
以下、本実施の形態におけるデータバッファリング方法について、図５のフローチャートに基づき説明する。
【００３３】
ストリームバッファリング部２０２は、受信したＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデータを解析し、ＧＯＰの先頭を検出する（図５のステップ３）。受信データは最初に受信したものからバッファ２０３に書き続けるが、検出したＧＯＰの先頭から、例えば２ＧＯＰ分バッファリングを行ってから（図５のステップ４）デコード部２０４に復号処理開始を通知する（図５のステップ５）。
【００３４】
これにより、デコード部２０４はＧＯＰの途中から復号処理を開始すると、次のＧＯＰの先頭までのデータは復号できないので、それまでは復号処理時に処理する速度より早くデータを処理してしまうが、その分を考慮してバッファリングを行っているので、この例の場合常に２ＧＯＰ分のデータをもつようになる。つまり、ＧＯＰの途中から復号処理を開始すると、前記のようにバッファ２０３のデータを高速で処理してしまうために、溜めておいたデータが減ってしまうことになり、最悪アンダーフローして空っぽになることもあるが、そのようなことがない。
【００３５】
なお、本実施の形態では、２ＧＯＰをバッファリングするとしたがいくつのＧＯＰのものでも良いし、ＧＯＰより下の階層であるピクチャ層まで検出し、数ピクチャバッファリングするとしても良い。
【００３６】
（実施の形態３）
図１と図２および図３において、実施の形態１と同様の動作をするものは、説明を省略する。
【００３７】
図６は本発明の実施の形態３におけるストリーミング端末におけるデータバッファリング方法を示すフローチャートである。
【００３８】
本実施の形態では、ストリームがＭＰＥＧ−２規格で定められたＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のものであり、出力はアナログ形式の映像信号および音声信号が出力されるとする。また、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ内に含まれている映像信号と音声信号は、それぞれＭＰＥＧ−２ビデオとＭＰＥＧ−１オーディオの規格で圧縮されたものであるとする。
【００３９】
以下、本実施の形態におけるデータバッファリング方法について、図６のフローチャートに基づき説明する。
【００４０】
ストリームバッファリング部２０２は、受信したＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデータをバッファリングしながら解析し、ＧＯＰの先頭を検出する（図６のステップ３）。ＧＯＰの先頭を書き込んだバッファ２０３内の位置を一時記憶する（図６のステップ４）。その後、例えば２ＧＯＰ分バッファリングを行った後（図６のステップ５）、ＧＯＰの先頭を書き込んだバッファ２０３内の位置をデコード部２０４に通知して、かつ、復号処理開始を通知する（図６のステップ６）。デコード部２０４は、通知されたＧＯＰの先頭部分からデータを読み出して復号を開始する（図６のステップ７）。これにより、デコード部２０４は毎回ＧＯＰの先頭から復号処理を開始することになるので、バッファ２０３から読み出すデータ量も安定する。つまり、ＧＯＰの途中から復号処理を開始すると、次のＧＯＰの先頭までのデータは復号できないので、それまでは復号処理時に処理する速度より早くデータを処理してしまうが、そのようなことがない。また、ＧＯＰの先頭から復号処理を開始するとバッファ２０３からの読み出し速度はネットワーク上でサーバーから送られてくるデータのスピードと等価なので、バッファ２０３内のデータ量は常に所定の時間分あることになる。つまり、この例の場合  常に２ＧＯＰ分のデータをもつようになる。つまり、ＧＯＰの途中から復号処理を開始すると、前記のようにバッファ２０３のデータを高速で処理してしまうために、溜めておいたデータが減ってしまうことになり、最悪アンダーフローして空っぽになることもあるが、そのようなことがない。
【００４１】
なお、本実施の形態では、ＧＯＰの先頭からバッファに書くとしたが、ＧＯＰの先頭を含むＴｒａｎｓｐｏｒｔＳｔｒｅａｍのパケットからでも良いし、ＧＯＰの先頭を含むＴｒａｎｓｐｏｒｔＳｔｒｅａｍより大きなパケットからでも良い。例えばＲＴＰのパケットでも良い。もしくは、ＧＯＰの先頭より前の近傍でも構わない。また、２ＧＯＰをバッファリングするとしたがいくつのＧＯＰのものでも良いし、ＧＯＰより下の階層であるピクチャ層まで検出し、数ピクチャバッファリングするとしても良い。
【００４２】
（実施の形態４）
図１と図２および図３において、実施の形態１と同様の動作をするものは、説明を省略する。
【００４３】
図７は、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデータの構成図、図８は本発明の実施の形態４におけるストリーミング端末におけるデータバッファリング方法を示すフローチャートである。
【００４４】
本実施の形態では、ストリームがＭＰＥＧ−２規格で定められたＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のものであり、出力はアナログ形式の映像信号および音声信号が出力されるとする。また、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ内に含まれている映像信号と音声信号は、それぞれＭＰＥＧ−２ビデオとＭＰＥＧ−１オーディオの規格で圧縮されたものであるとする。
【００４５】
また、本実施の形態では、サーバーから端末に送信されるＴｒａｎｓｐｏｒｔＳｔｒｅａｍのデータは、セキュリティ強化のために、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍＰａｃｋｅｔ単位での順番入れ替え（インターリーブ）が行われているとする。つまり図７に示すように、サーバーが送信時にＴｒａｎｓｐｏｒｔＳｔｒｅａｍＰａｃｋｅｔ単位で並べ替え、送信する。端末は、これを受信し、並べなおして復号化を行う。当然、サーバー側と端末側は、別途並べ替えの情報をやり取りしている。これにより、送信中のデータを所定の端末以外が受信しても復号しづらくすることができる。
【００４６】
以下、本実施の形態におけるデータバッファリング方法について、図８のフローチャートに基づき説明する。
【００４７】
ストリームバッファリング部２０２は、受信したＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデータを解析し、インターリーブの周期の先頭を検出し（図８のステップ３）、ここからバッファ２０３に受信データを書き込む（図８のステップ４）。例えば、図７においてｂで示すＴＳ５から受信した場合は、ＴＳ１０からバッファ２０３に書き込み、かつＴＳ５からＴＳ９の受信データは破棄する。そして、ここから、例えばインターリーブの２周期分バッファリングを行って、デコード部２０４に復号開始を通知する（図８のステップ５）。インターリーブの途中のデータは復号処理を行ったとしても、連続性が失われたデータなので、それをそのまま使用することはできない。このために、インターリーブの途中からデータをバッファ２０３に書くとデコード部２０４で復号処理した後の映像や音声にノイズなどの障害が生じることになる。そこで、インターリーブの周期の先頭からバッファ２０４にデータを書き込むことにより、それを防ぐことが出来る。また、連続性を保つためには、インターリーブの周期毎にしか処理を行えないので、最初にインターリーブの２周期分のデータをバッファリングしておくと、安定して処理を行うことができる。
【００４８】
なお、本実施の形態では、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ単位でのインターリーブとしたが、別途の通信系のパケットの単位でもよい。例えばＲＴＰ単位でもよい。また、本実施の形態に付随して実施の形態１もしくは実施の形態２もしくは実施の形態３のバッファリング方法を組み合わせても良い。また２周期分をバッファリングするとしたがいくつの周期でも良い。
【００４９】
（実施の形態５）
図１から図３および図８において、実施の形態１および実施の形態４と同様の動作をするものは、説明を省略する。
【００５０】
図９は本発明の実施の形態５におけるストリーミング端末におけるデータバッファリング方法を示すフローチャートである。
【００５１】
本実施の形態では、ストリームがＭＰＥＧ−２規格で定められたＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のものであり、出力はアナログ形式の映像信号および音声信号が出力されるとする。また、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ内に含まれている映像信号と音声信号は、それぞれＭＰＥＧ−２ビデオとＭＰＥＧ−１オーディオの規格で圧縮されたものであるとする。
【００５２】
また、本実施の形態では、サーバーから端末に送信されるＴｒａｎｓｐｏｒｔＳｔｒｅａｍのデータは、セキュリティ強化のために、ＴｒａｎｓｐｏｒｔＳｔｒｅａｍＰａｃｋｅｔ単位での順番入れ替え（インターリーブ）が行われているとする。
【００５３】
以下、本実施の形態におけるデータバッファリング方法について、図９のフローチャートに基づき説明する。
【００５４】
ストリームバッファリング部２０２は、受信したＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデータをバッファ２０３に書きながら解析し、インターリーブの周期の先頭を検出し（図９のステップ３）、インターリーブの周期の先頭を書き込んだ位置を一時記憶する（図９のステップ４）。ここから、例えばインターリーブの２周期分バッファリングを行って（図９のステップ５）、デコード部２０４に一時記憶したインターリーブの周期の先頭をバッファ２０３に書き込んだ位置を通知し、かつ、復号開始を通知する（図９のステップ６）。インターリーブの途中のデータは復号処理を行ったとしても、連続性が失われたデータなので、それをそのまま使用することはできない。このために、インターリーブの途中からデータをデコードするとデコード部２０４で復号処理した後の映像や音声にノイズなどの障害が生じることになる。そこで、デコード部２０４がインターリーブの周期の先頭からバッファ２０３からデータを読み出すことにより、それを防ぐことが出来る。また、連続性を保つためには、インターリーブの周期毎にしか処理を行えないので、最初にインターリーブの２周期分のデータをバッファリングしておくと、安定して処理を行うことができる。
【００５５】
なお、本実施の形態では、インターリーブの周期について述べたが、これに付随して実施の形態１もしくは実施の形態２もしくは実施の形態３のバッファリング方法を組み合わせても良い。また２周期分をバッファリングするとしたがいくつの周期でも良い。
【００５６】
なお、本実施の形態すべてにおいて、ストリームはＭＰＥＧ−２規格で定められたＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式としたが、圧縮規格のストリームであれば何でも良い。例えば、ＭＰＥＧ−４でもよい。また、ビデオ（映像信号）の同期について実施の形態を説明したが、これは、ＭＰＥＧ−２ビデオ規格において、ＭＰＥＧ−１オーディオ規格より長い周期であるＧＯＰでの同期を必要とするからであり、オーディオ側の同期周期がビデオ側より長い場合は、オーディオ側でバッファリングを制御しても構わない。
【産業上の利用可能性】
【００５７】
本発明にかかるストリーミング端末におけるデータバッファリング方法は、バッファ開始点もしくはデコード開始点を調整し、バッファのサイズを適度なものにするとともに、ネットワークの不具合への耐性を安定化するという効果を有し、インターネット上に公開されたコンテンツおよびインターネット上に放送されているコンテンツを受信し、映像信号と音声信号として再生できるストリーミング端末におけるデータバッファリング方法等として有用である。
【図面の簡単な説明】
【００５８】
【図１】デジタルストリーミング放送システムのブロック図
【図２】ストリーミング端末のブロック図
【図３】ＭＰＥＧ−２のビデオのデータ構造を示す図
【図４】本発明の実施の形態１におけるストリーミング端末におけるデータバッファリング方法を示すフローチャート
【図５】本発明の実施の形態２におけるストリーミング端末におけるデータバッファリング方法を示すフローチャート
【図６】本発明の実施の形態３におけるストリーミング端末におけるデータバッファリング方法を示すフローチャート
【図７】ＴｒａｎｓｐｏｒｔＳｔｒｅａｍ形式のデータの構成図
【図８】本発明の実施の形態４におけるストリーミング端末におけるデータバッファリング方法を示すフローチャート
【図９】本発明の実施の形態５におけるストリーミング端末におけるデータバッファリング方法を示すフローチャート
【図１０】従来のストリーミング端末におけるデータバッファリング方法を示すフローチャート
【符号の説明】
【００５９】
１０１  サーバー
１０２  ストリーミング端末
２０１  ストリーム受信部
２０２  ストリーミングバッファリング部
２０３  バッファ
２０４  デコード部
【図１】
2005167893.tif 000003
【図２】
2005167893.tif 000004
【図３】
2005167893.tif 000005
【図４】
2005167893.tif 000006
【図５】
2005167893.tif 000007
【図６】
2005167893.tif 000008
【図７】
2005167893.tif 000009
【図８】
2005167893.tif 000010
【図９】
2005167893.tif 000011
【図１０】
2005167893.tif 000012