(57)【要約】【課題】ＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法及び装置を提供する。【解決手段】受信したパケットより抽出されたフレーム情報によって保存されるフレームの数を決定する段階、前記決定されたフレーム数内で前記パケットを該当フレーム別に連結して保存する段階、及び前記該当フレーム別に連結して保存されたパケットをデコーディング部に出力する段階を含むＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。【選択図】図２
2006050604.tif 000002
【特許請求の範囲】
【請求項１】
受信したパケットより抽出されたフレーム情報によって保存されるフレームの数を決定する段階と、
前記決定されたフレームの数内で前記パケットを該当フレーム別に連結して保存する段階と、
前記該当フレーム別に連結して保存されたパケットをデコーディング部に出力する段階と、を含むＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項２】
前記抽出されたフレーム情報は、フレームの画質、秒当りのフレーム数、または１フレームを構成する情報の大きさのうち何れか１つを含む請求項１に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項３】
前記抽出されたフレーム情報は、該当フレームが構成するコンテンツの伝送速度または再生に関する情報を含む請求項１に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項４】
前記保存されるフレームの数を決定する段階は、前記パケットを受信するに当って、ネットワークの状態による遅延時間を計算して保存されるフレームの数を決定する請求項１に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項５】
前記連結して保存する段階は、前記受信したパケットをフレーム別にリンクを構成して保存する段階を含む請求項１に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項６】
前記連結して保存する段階は、前記受信したパケットをフレーム別に順次に保存する段階を含む請求項１に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項７】
前記パケットをデコーディング部に出力する段階は、前記保存されるフレームの数を超過してパケットが保存された場合、前記保存されたフレーム別パケットをデコーディング部に出力する段階を含む請求項１に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項８】
前記保存されるフレームの数より小さなパケットが保存された場合、パケットの出力速度またはパケットの受信速度を制御する段階をさらに含む請求項１に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法。
【請求項９】
受信したパケットを該当フレーム別に連結して保存するフレーム生成部と、
前記パケットより抽出されたフレーム情報によって前記フレーム生成部に保存されるフレームの数を決定するフレーム生成情報設定部と、
前記フレーム生成部に該当フレーム別に連結して保存されたパケットをデコーディング部に出力するフレーム出力部を含むＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１０】
前記フレーム生成部は、前記受信したパケットを該当フレーム別に連結して保存するために受信したパケットをフレーム別にリンクを構成して保存し、前記フレームを管理するためのフレーム管理リストを含む請求項９に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１１】
前記フレーム生成部は、前記受信したパケットを該当フレーム別に連結して保存するために受信したパケットをフレーム別に順次に保存し、前記フレームを管理するためのフレーム管理リストを含む請求項９に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１２】
前記抽出されたフレーム情報は、フレームの画質、秒当りのフレーム数、または１フレームを構成する情報の大きさのうち何れか１つを含む請求項９に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１３】
前記抽出されたフレーム情報は、該当フレームが構成するコンテンツの伝送速度または再生に関する情報を含む請求項9に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１４】
前記フレーム生成情報設定部は、前記パケットを受信するに当って、ネットワークの状態による遅延時間を計算して保存されるフレームの数を決定する請求項９に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１５】
前記フレーム出力部は、前記保存されるフレームの数を超えてパケットが保存された場合、フレーム出力部が前記保存されたフレーム別パケットをデコーディング部に出力する請求項９に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１６】
前記保存されるフレームの数より小さいパケットが保存された場合、パケットの出力速度またはパケットの受信速度を制御する遅延制御部をさらに含む請求項９に記載のＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置。
【請求項１７】
請求項１ないし請求項８の方法を実行するためのコンピュータ可読プログラムを記録した記録媒体。
【請求項１８】
請求項１ないし８の方法を行ってマルチメディアデータを受信する装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法及び装置に関する。
【背景技術】
【０００２】
さる数十年間映像データ及び音響データは、アナログデータ形式でテレビに伝送されてきた。しかし、デジタル信号の多様な長所によって次第に多くの映像情報がデジタル情報で表現、記録されている。最近では、デジタル映像及びオーディオは、衛星放送や地上波放送またはケーブル放送を通じて伝送されており、ユーザはセットトップボックスとデジタルテレビとを用いてデジタル映像とオーディオとが視聴可能となった。
【０００３】
一方、最近では、インターネット技術の発展と共に、ＶＯＤ（Ｖｉｄｅｏ  Ｏｎ  Ｄｅｍａｎｄ）サービスが増加している。インターネット映画館または音楽鑑賞室がこれに該当するが、ユーザがコンピュータ上で要求する映画をサービス業者はインターネットを通じてリアルタイムデータで伝送し、ユーザは伝送された映画をコンピュータ上で鑑賞できる。デジタルテレビやＶＯＤサービスは、何れもユーザがインターネットあるいは無で伝送されたリアルタイムデータを通じて映像や音楽を鑑賞するという共通点を有する。
【０００４】
前記映像または音響データは、アナログデータをデジタルに変換したものである。前記デジタルデータは、その量が多いために情報の損失を減らし、圧縮技術に関する研究が進められてきた。静止映像においては、ＪＰＥＧ（Ｊｏｉｎｔ  Ｐｈｏｔｏｇｒａｐｈｉｃ  Ｅｘｐｅｒｔｓ  Ｇｒｏｕｐ）があり、映像符号化のためにＨ．２６１、Ｈ．２６３などがあり、ＭＰＥＧ（Ｍｏｔｉｏｎ  Ｐｉｃｔｕｒｅ  Ｅｘｐｅｒｔ  Ｇｒｏｕｐ）では、ＭＰＥＧ１、ＭＰＥＧ２とＭＰＥＧ４に対する標準を提示しており、以外にも、ＭＰＥＧ２１も準備している。
【０００５】
映像または音響データを使用する方法は、ダウンロード方式とストリーミング方式とに大別される。ダウンロードは、映像または音響データが含まれたファイルをローカルまたは個人保存装置に保存して使用することを意味する。ストリーミングは、ファイルを受けずに、映像または音響データをリアルタイムで出力することを意味する。前記ストリーミングは、理論的にはリアルタイム出力であるが、ネットワーク状況とファイルの属性上、一定部分があらかじめローカル領域（保存装置またはデジタル装置）に保存されることが要求される。したがって、ストリーミングクライアントは、前記データを受信してバッファのような臨時保存装置に保存した後、保存したデータを出力する方式を採択している。前記ストリーミングクライアントが映像または音響データを要請した時間から、バッファに保存した後、保存したデータを出力するまでかかる時間を初期遅延時間という。また、前記バッファに一定時間出力するデータを保存するが、前記一定時間を遅延時間という。ところで、既存のストリーミングクライアントは、前記遅延時間を算術的にビットの数またはバッファの一定部分を満たす時期までに決め、実際に受信するデータの属性に弾力的に適応できないという問題点がある。
【０００６】
本発明では受信したデータの属性によって前記バッファに保存するデータの量を弾力的に調節しようとする。
【特許文献１】特開昭６３−１２０５７０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００７】
本発明の技術的課題は、映像または音響データの受信時、バッファに保存されるデータの量を弾力的に調節することである。
【０００８】
本発明の他の技術的課題は、映像または音響データの属性によってバッファに保存されるデータの量を調節し、映像または音響データのストリーミングにおいて発生する遅延を減らすことである。
【０００９】
本発明の目的は、前記で言及した目的に限定されず、言及しなかったさらに他の目的は下の記載から明確に理解できる。
【課題を解決するための手段】
【００１０】
本発明は、ＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する方法及び装置に関する。
【００１１】
本発明の一実施例に係るＡＶデータの受信時、バッファ量をコンテンツ属性によって弾力的に調節する方法は、受信したパケットより抽出されたフレーム情報によって保存されるフレームの数を決定する段階、前記決定されたフレームの数内で前記パケットを該当フレーム別に連結して保存する段階及び前記該当フレーム別に連結して保存されたパケットをデコーディング部に出力する段階を含む。
【００１２】
本発明の一実施例に係るＡＶデータの受信時のバッファ量をコンテンツ属性によって弾力的に調節する装置は、受信したパケットを該当フレーム別に連結して保存するフレーム生成部、前記パケットより抽出されたフレーム情報によって前記フレーム生成部に保存されるフレームの数を決定するフレーム生成情報設定部、及び前記フレーム生成部に該当フレーム別に連結して保存されたパケットをデコーディング部に出力するフレーム出力部を含む。
【発明の効果】
【００１３】
本発明を具現することによって、映像または音響データの受信時、バッファに保存されるデータの量を弾力的に調節する事ができる。
【００１４】
本発明を具現することによって、映像または音響データの属性によってバッファに保存されるデータの量を調節し、映像または音響データのストリーミング時に発生する遅延を減らす事ができる。
【発明を実施するための最良の形態】
【００１５】
この明細書で使用する用語を整理すれば次の通りである。
−フレーム
画像信号の空間情報をなすラインの集合である。１フレームは１つの静止画面を表示でき、これらフレームの結合を通じて動画像を具現できる。ＭＰＥＧには、独自に１つの画面情報を含むＩフレームと、他のフレームの情報を参照するＢフレームとＰフレームとが存在する。以外にも、他の動画像圧縮においてもフレームに基づいて行う。以下、この明細書でフレームは、１つの静止画面を圧縮したデータブロックであって、これは独自的な静止画面でもあり、他のフレームの情報を参照しても良い。
【００１６】
−初期遅延時間
ストリーミングクライアントがストリーミングサーバーにデータを要請した後、ストリーミングサーバーがデータを伝送し、これをストリーミングクライアントが自身の臨時保存装置に前記データを保存して一定量のデータが保存されれば、保存されたデータを出力する。初期遅延時間は、前記サーバーにデータを要請した後のデータの出力にかかる時間を意味する。バッファに保存するデータの量が大きければ、初期遅延時間は延びるが、初期に出力するデータの量が多くなるので切れずに出力する事ができる。
【００１７】
−遅延時間
ストリーミングは、インターネットあるいは無線などネットワークを用いて映像または音響データを伝送する方式であるために、ネットワークの速度に左右される。したがって、切れずにデータを出力するためには、一定量のデータをストリーミングクライアントが保存していなければならない。この遅延時間は、ネットワークの問題でデータを受信していない状態でのデータの出力可能時間を意味し、バッファに保存されたデータの量を出力するのにかかる時間を意味する。遅延時間を大きく取る場合、バッファに保存すべきデータの量は増えるが、切れずにデータを出力しうる。
【００１８】
−ストリーミングクライアント
サーバーでストリーミング方式で伝送する映像または音響データを受信して再生する装置を通称する。コンピュータ、携帯電話、デジタルテレビ、ＰＤＡなどがこれに属する。ストリーミングクライアントは、ストリーミングデータを一定時間あるいは一定量を保存するための保存空間（バッファ）を有さねばならず、受信したデータが様々な映像または音響データの標準によってエンコーディングされた場合、これをデコーディングするための機能を提供する。
【００１９】
−マルチメディアコンテンツ受信装置
マルチメディアコンテンツを再生する装置は多様である。コンピュータ、デジタルテレビのような家電製品を始めとして、ノート型パソコン、ＰＤＡ、携帯電話、携帯用ＴＶなどが存在しうる。また、デジタルセットトップボックスもマルチメディアコンテンツを受信して出力する装置であるために、この明細書で言及する装置の一実施例として可能である。
【００２０】
図１は、既存のストリーミングクライアントの動作を示すブロック図である。図１は、高画質のフレーム２１０、２２０と低画質のフレーム３１０、３２０との受信における差を示す。既存のストリーミングクライアント１００は、サーバーからデータを受信するパケット受信部２０と前記受信されたパケットを臨時保存するバッファ３０、そして前記バッファに保存された量を調節するためのバッファ制御部１０と前記パケットに保存された映像または音響データを出力するためにデコーディングするデコーダ１５０で構成される。
【００２１】
前記バッファ３０は、前述した初期遅延時間または遅延時間のために一定量のデータを保存する空間である。ところが、このバッファに保存されるデータの上限線は受信されるパケットの大きさで決めている。例えば、２Ｍｂｙｔｅあるいは３Ｍｂｙｔｅのように受信パケットのデータ量が一定量を満足するか否かによって判断する。
【００２２】
この場合、高画質データ及び低画質データでは、前記バッファの容量が、直ちに遅延時間を意味するものではない。例えば、ＭＰＥＧ−２の場合、ＨＤ及びＳＤの２段階でデータを生成しうる。ＨＤの場合、高画質であるために１つのフレームを表現するための情報の量、すなわちデータサイズが大きい。ＳＤの場合、低画質であるために１つのフレームを表現するための情報の量が少ない。すなわち、ＨＤの場合に１Ｍｂｙｔｅで表現しうる時間を３０秒と仮定する時、ＳＤの場合、１Ｍｂｙｔｅで表現しうる時間は３０秒より長い５０秒になりうる。
【００２３】
しかし、図１のように、ＨＤ級のデータを処理するのに必要な遅延時間だけを考慮してバッファの大きさだけを設定した場合、例えばＨＤ級のデータを対象として遅延時間を１分にした場合、２Ｍｂｙｔｅがバッファの大きさに設定しうる。このバッファを満たすためにＳＤ級データは、２Ｍｂｙｔｅの１分４０秒分量のデータが必要である。しかし、前記ストリーミングクライアントは、１分を遅延時間と仮定してバッファを設定したので、ＳＤ級のデータを受信する場合、４０秒分量のデータをさらに必要とし、ＳＤ級データを通じて速く出力しようとするユーザの要求を充足させられない可能性もある。図１から分かるように、ストリーミングクライアントのバッファを満たすために高画質のデータは、Ｎ個のフレーム２１０〜２２０を必要とするが、低画質のデータはＭ個のフレーム３１０〜３２０を必要とする（Ｎ＜Ｍ）。既存の技術は、コンテンツの属性を考慮せず、単にデータの大きさをバッファ制御に用いた。
【００２４】
この明細書では前記制約を克服するために受信されるコンテンツの属性によってバッファに保存されるデータの量を調節し、ストリーミングクライアントをして遅延時間を適切に調節可能にする。
【００２５】
コンテンツの属性には画質が存在する。高画質の場合、１つのフレームを表すためのデータサイズが大きいが、低画質の場合には１つのフレームを表すのに必要なデータサイズが限定されている。また、コンテンツの属性には秒当りフレーム数がある。秒当り３０フレームで生成されたデータの場合、遅延時間が３０秒ならば、総９００フレームのデータをバッファに保存せねばならない。しかし、秒当り２５フレームで生成されたデータの場合、遅延時間が３０秒であっても、７５０フレームのデータをバッファに保存すればよい。
【００２６】
前記属性以外にも、コンテンツが切れない伝送を重要視するか、あるいは速い再生を重要視するかを適用してバッファにデータを保存する方式がある。コンテンツが切れない伝送を重要視するならば、バッファに多くのフレームを保存せねばならない。しかし、速い再生を重要視するならば、遅延時間を短く設定してバッファに必要なだけのフレームを保存してバッファリングに長時間がかからないようにすることが必要である。
【００２７】
図２は、本発明の一実施例に係るフレームのデータサイズに係るバッファ保存を示すブロック図である。
【００２８】
画質は、同じ方式のビデオコーディング時に、いかほどのデータが該当フレームの生成に必要であるかを通じて判断しうる。１つのフレームを３Ｍｂｙｔｅのデータで表現する場合、１Ｍｂｙｔｅで表現するより、はるかに多くの情報を含むようになり、その結果、フレームの画質は高まる。ＭＰＥＧを例として挙げれば、同じＩフレームまたは同じＰあるいはＢフレームを持って画質を比較でき、ＩとＰ、またはＩとＢフレームを比較して画質を判断することは適当でない。図２の２つの映像データ２００、３００は同じ方式でコーディングされて秒当りフレーム数も同一である。但し、各フレームを示すためのデータの量に差がある。
【００２９】
前記ストリーミングクライアント１００で遅延時間をＴ秒と設定した場合、前記Ｔ秒を満たすためには、高画質のデータ２００もＮ個のフレームを必要とし、低画質のデータ３００もＮ個のフレームを必要とする。Ｎ個のフレームならば、Ｔ秒の間にデータを示しうるからである。一方、同じＮ個のフレームであっても、高画質の場合とは違って低画質のデータはフレーム当りデータサイズ（ｂｉｔ  ｒａｔｅ）が小さいためにバッファに保存されるデータサイズも高画質のデータよりさらに小さい。したがって、高画質のデータと同じ遅延時間を持ちつつ、バッファに保存される時間を短縮できる。図１では、Ｍ個のフレームを必要とし、Ｎ＜Ｍであるために、これは容易に類推されうる。
【００３０】
図３は、ビデオストリームの構造を概略的に示す例示図である。
【００３１】
図３では、ＭＰＥＧ−２ビデオデータを例として示している。ＭＰＥＧ−２ビデオデータは、一連のデータシーケンス９００よりなる。このデータシーケンスは、ビットストリームに基づき、絵（ｐｉｃｔｕｒｅ、以下、フレーム）に関する情報より構成される。フレーム９２０は、１つの静止映像に関する情報を示すものであって、いくつかのスライス９３０より構成される。そして、このスライス９３０は、再び幾つかのマクロブロック９４０よりなり、このマクロブロックは画素に関する情報であるブロック９５０よりなる。ＭＰＥＧ−２でのビデオ情報は、上記の構造よりなっており、他のビデオ圧縮データも図３と類似した構成よりなっている。
【００３２】
したがって、ビデオをストリーミングするには、前記ビデオシーケンスを受信することが必要である。ところが、前記ビデオシーケンスを構成するフレーム及びヘッダ情報は小さなサイズのデータではない。このようなフレームの連続したビデオシーケンスも現在の通信及びデータ処理速度で１つのデータ束で伝送あるいは処理できない。したがって、ビデオシーケンスを所定の長さに分けたパケットで送るようになる。
【００３３】
パケットは、ビットストリームで構成されたビデオストリームを所定の長さ（可変長あるいは固定長であり得る）で割った単位を意味する。ＭＰＥＧ−２の場合、固定長で伝送する伝送ストリームと可変長で伝送するプログラムストリームとがある。伝送ストリームは、一度に多くのプログラムを同時に伝送できるが、データの流失可能性がある。プログラムストリームは、マルチメディアアプリケーションに適するように最適化されている。したがって、マルチメディアデータは前記例示したパケットで伝送される。
【００３４】
これとは違って、通信上のデータ単位がある。通常、このようなデータ単位もパケットと称することもある。通信上のデータ単位は、通信状態とプロトコルによって多様であり、ＴＣＰ／ＩＰ、ＵＤＰ、ＨＴＴＰによってデータの定義も変わる。
【００３５】
前述した伝送ストリームのパケット長は１８８ｂｙｔｅである。例えば、１０２４ｂｙｔｅを伝送単位とする通信プロトコルでは前記伝送ストリームのパケットを５個伝送しうる。
【００３６】
以下、この明細書で使用するパケットは、ビデオストリームを割ったビットストリームの一種である。前記通信を通じて伝達されたデータ単位は、ヘッダの付加情報と実際伝達しようとするマルチメディア情報とが含まれるので、この明細書でのパケットは前記マルチメディア情報、例えば、ビデオストリームの一部に伝送されるビットストリームをパケットと称する。
【００３７】
図４は、本発明の一実施例に係るストリーミングクライアントの構成を示すブロック図である。この実施例で使われる‘〜部’という用語、すなわち‘〜モジュール’はソフトウェア、ＦＰＧＡまたはＡＳＩＣのようなハードウェア構成要素を意味し、モジュールは何れの機能をも行う。しかし、モジュールはソフトウェアまたはハードウェアに限定される意味はでない。モジュールは、アドレッシング可能な保存媒体に存在すべく構成されても良く、１つまたはそれ以上のプロセッサーを実行させるように構成されても良い。したがって、一例としてモジュールは、ソフトウェア構成要素、客体指向ソフトウェア構成要素、クラス構成要素及びタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバー、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイ、及び変数等を含む。構成要素とモジュールから提供される機能は、より少数の構成要素及びモジュールで結合されるか、追加的な構成要素とモジュールにさらに分離されうる。のみならず、構成要素及びモジュールは ディバイスまたは保安マルチメディアカード内の１つまたはそれ以上のＣＰＵを再生させるように具現されることもある。
【００３８】
ストリーミングクライアント１００は、大きく遅延制御部１１０、パケット受信部１２０、送受信部１２５、フレーム生成部１３０、フレーム生成情報設定部１３５、フレーム出力部１４０とデコーディング部１５０とで構成される。ストリーミングクライアントは、ストリーミングサーバーからストリーミングされるデータを受信する。このデータは、前述したようにフレームを構成するパケットであり、図３で説明したビデオストリームの一部となる。１つのフレームを生成するためには、複数のパケットが必要である。これはパケットの大きさがフレームより小さい場合であり、もし、ネットワークとマルチメディアとの圧縮技術が増加する場合、またはコンテンツの特性によって１つのパケットが１つ以上のフレームに関する情報を含むこともある。
【００３９】
すなわち、１つのフレームを、２つ以上のパケットで構成することは、現在の技術に基づいたものであって、フレーム１つを生成するために、必ずしも多数のパケットを必要とするものではない。本発明の一実施例では、１つのフレームを示すために１つ以上のパケットが必要な場合を想定しているが、これは一実施例に過ぎず、これに限定されるものではない。今後、ネットワークの発達とフレーム圧縮とによって、１つのパケットに複数のフレームが含まれて伝送される場合も本発明の一実施例として適用しうる。
【００４０】
ストリーミングクライアントは、送受信部１２５を通じてサーバーとデータとを送受信する。一方、ストリーミングサーバーからデータの受信だけ行う場合には、前記送受信部１２５がパケット受信及びデータ要請などの機能だけを行える。
【００４１】
送受信部１２５で受信したデータは、パケット受信部１２０に伝えられる。パケット受信部１２０が受信するデータは、ビットストリームである。このビットストリームは、前述したように１つのフレームを複数のパケットに分けて伝送する場合を仮定し、１つのフレームを作るためには、前記パケットを取り合わせる過程が必要である。したがって、パケットを受信して直ぐバッファに保存する既存の方式と違って、それをフレーム生成部１３０に伝達する。フレーム生成部は、受信されたパケットをフレーム別に管理する。
【００４２】
受信したパケットをフレーム別に管理することは、パケットより抽出したフレームの情報を通じて分かる。例えば、パケットより抽出したフレームの情報がフレームのヘッダを含む場合、該当パケットは新たなフレームの開始を意味するので、フレーム管理リストに新たなフレームで連結する。そして、フレームのヘッダを含んでいないパケットであれば、以前に受信したパケットと同じフレームを構成するパケットであるために、現在生成しているパケットの連結リストをリンクを通じて結合するか、または以前に受信したパケットが保存された部分以後に順次に保存しうる。
【００４３】
前記フレーム生成部１３０は、順次的な保存のためにパケット受信部から受信したビットストリームを組合わせる作業を行える。ここで、組合わせとは、受信したパケットを付け加えて１つのフレーム単位のビットストリームを作ることを意味する。
【００４４】
フレーム出力部１４０は、フレーム生成部１３０で保存するフレームの数を持続的に検査する。その結果、指定されたフレーム数を超える場合に、フレーム生成部にあるフレームを取ってデコーディング部１５０に出力する。ここで、フレームを取ってデコーディング部に出力するということは、フレーム生成部でパケットを組合わせたフレームをビットストリームで伝送することを意味する。したがって、従来にバッファに保存されたパケットをビットストリームで伝送することと類似しており、デコーディング部は従来のデコーディング部がバッファで受信する方式でフレーム出力部でデータを受信しうる。フレーム出力部１４０が出力し始めれば、フレーム生成部１３０にデータがないか、ユーザが再生中止を要請するまで出力を行う。したがって、ユーザに切れないマルチメディア再生のためにはフレーム出力部１４０の出力速度とパケット受信部１２０のパケット受信速度とは、遅延制御部１１０を通じて制御されうる。
【００４５】
前記パケットは、受信したパケットがビデオあるいはオーディオストリームの単純な片である場合には、そのまま付け加えて保存でき、もし、上記の片以外に異なる情報を含むならば、これに対する処理過程を経てから順次に保存しうる。
【００４６】
デコーディング部１５０では、フレームを出力するためのデコーディング作業を行ってディスプレー部あるいは音響出力部に伝送する。このためには、ビデオまたはオーディオデコーディングと関連した作業を必要とする。
【００４７】
フレーム生成情報設定部１３５は、フレーム生成部１３０で保存するフレームの数と遅延時間に関する情報とを決定して保存する。保存するフレームの数をさらに詳しく説明すれば、フレーム生成部１３０が収容できる最大フレーム数と最小フレーム数、初期出力のために必要なフレーム数などになりうる。また画質に関する情報をも有しうる。このような情報は、何れもフレームに関する属性であって、属性によっていかほどのフレームを保存するかを決定しうる。例えば、前述した遅延時間に関する情報を設定すれば、フレームを受信しつつ、該当フレームの属性によって設定されうる。例えば、遅延時間を１分に設定すれば、受信したフレームが秒当り２５フレームにコーディングされた場合、１５００フレームを保存すればよい。また、最大及び最小フレーム数は、前記遅延時間以外に最小遅延時間または最大遅延時間に設定してフレームの属性に合わせて設定されうる。
【００４８】
また、高画質の場合、受信すべきパケットの量が多いので、遅延による切れ現象が大きくなりうるので、保存可能なフレームの数を高め、低画質の場合には、逆に保存可能なフレームの数を低めうる。これは、各システムとマルチメディアコンテンツによって異なって設定されることがあり、前記高画質及び低画質の場合は１つの実施例に過ぎず、これに限定されるものではない。
【００４９】
遅延制御部１１０は、フレーム生成部１３０に保存されたパケットが構成するフレームの数が保存できる量を超えるか、過度に少なく保存された場合、パケットの受信速度とデコーディング部に出力させる速度とを制御する。例えば、フレーム生成部に最小フレーム数より少ないフレームが保存されているならば、さらに多くのフレームを受信せねばならないために、速い伝送を要求しうる。また、速い伝送が難しい場合には、前記フレームの出力速度を下げ、最小フレーム数より多数のフレームがフレーム生成部に保存されうるようにする。出力速度の制御は、フレーム出力部１４０の制御を通じて可能である。また、受信速度の制御は、送受信部を通じてサーバーとのデータ受信を調節しうる。
【００５０】
一方、最大フレーム数より多ければ、フレーム生成部が管理できる量の限界を超えるので、ストリーミングクライアント１００はストリーミングサーバー９００にデータ伝送を減らすか、一時中止を要請しうる。ストリーミング技術を大きく２つに分ける時、クライアントがデータを持ってくる方式であるプル（Ｐｕｌｌ）方式の場合には、クライアントが流れ制御（ｆｌｏｗ  ｃｏｎｔｒｏｌ）を行えるので、前記遅延制御部１１０はデータ受信に関連した部分を制御しうる。一方、サーバーがクライアントにデータを伝送するプッシュ（Ｐｕｓｈ）方式の場合にもクライアントをして速度を制御可能にするプロトコルを使用する場合、遅延制御部１１０は送受信部を通じてサーバー側にデータ伝送を中止するか、低速で送ることを要請しうる。
【００５１】
図５は、本発明の一実施例に係るフレーム生成部で管理するパケットとフレームとの構造を示すブロック図である。図５の実施例では、フレームが１つ以上のパケットより構成される場合を想定している。
【００５２】
パケット受信部１２０で受信したパケットはフレーム生成部１３０でフレーム別に保存しうる。受信したパケットでフレームのヘッダであるか、否かを判別できるので、ヘッダの場合は新たに連結リストを構成でき、フレームのヘッダでなければ、既存に存在する連結リストにパケットをリンクとして連結しうる。これをリンク方式という。さらに他の実施例による場合、フレーム管理リストを通じてフレーム別に開始位置などの情報を保持でき、パケットはビットストリームであるためにフレーム別に付け加える形式で管理しうる。これを組合わせ方式という。
【００５３】
リンク方式では１つのフレームを構成するためにｋ個のパケットが必要である場合、これらｋ個のパケットをリンクとして連結して保存しうる。そして、このようなパケットリンクのヘッダはデコーディング部に入力される順序でに連結されうる。一方、ｋ個のパケットで１つのフレームを構成すれば、現在フレーム生成部に何個のフレームが保存されているかに関する情報を変更しうる。このような情報は、フレーム生成情報設定部１３５に保存される。フレーム生成情報設定部１３５には以外にも最大／最小遅延時間によるフレーム数も設定しうる。
【００５４】
秒当りのフレーム数が同じ場合に、遅延時間Ｔを充足させるためのフレームが総４つであれば、前記フレームを構成するパケットの数が画質によって異なることがわかる。
【００５５】
図５では、フレーム生成部１３０でパケットをフレーム別に連結リストを構成し、そのパケットのヘッダをさらに他の連結リストとして管理しているが、組合わせ方式を使用し、パケットを１つのフレームに組合わせ、フレーム別に１つの連結リストを構成しうる。
【００５６】
図６Ａ及び図６Ｂは、本発明の一実施例に係るパケット受信からフレーム出力に至るまでのフレーム生成部の変化を示すブロック図である。
【００５７】
（１）、（２）、（３）は時間の順序によってパケットを受信した後、前記パケットがどのように保存されて出力されるかを示すブロック図である。
【００５８】
（１）でパケット受信部１２０を通じてパケットを保存する。パケットのヘッダを通じて前記パケットがフレームの開始パケットであるかあるいはフレームの最後のパケットであるかが分かる。開始パケットの場合、いままで１つのフレームを構成した２１１、２１２のようなパケットの集合、例えば１つのフレームを構成するためにパケットが連結されたリストまたはパケットを順次に保存したことを整理し、次のフレームを構成するためにフレーム管理リスト８００に新たに連結しうる。パケットの集合は、ビットストリームで構成されたパケットを連結させたものであって、一実施例としては、保存空間に順次に保存したものとなりうる。このように順次に保存したパケットでフレーム管理リスト８００はパケットのうちヘッダを含む保存位置に関するポインタを保持し、以後フレーム出力部１４０でフレームを取るようにしうる。
【００５９】
（１）では最小フレーム数より多く、最大フレーム数より少ない数のフレームがフレーム生成部に保存されている。このような最大、最小フレーム数に関する情報は、フレーム生成情報設定部１３５で有している。最大、最小フレーム数は受信速度を調節するために必要な情報であり、必ずしも最大、最小フレーム数の形態で保持する必要はない。単に‘保存可能なフレーム数’のみを保持することもできる。これはシステムの構成によって変わる。
【００６０】
（２）では最大フレーム数までフレームがフレーム生成部１３０に保存されている状態である。この場合には、フレームを出力しなければ、以後パケット受信部で受信されるパケットを保存できない。したがって、フレーム出力部はフレーム生成部で最小フレーム数以上を保持するようにパケットを取ってデコーディング部に送れる。持ってくるパケットの順序は、フレーム管理リストのフレーム順序によって該当フレーム別にパケットを持ってくる。これらパケットの順序は、前述したリンク方式で連結された場合、リンクに沿って持ってくることができる。また、順次に保存された場合には、これらパケットの保存順に持ってくることができる。したがって、２１１、２１２のように、先に保存されたパケットが出力される。フレーム出力部１４０では、パケットを１つのフレームより生成してデコーディング部に送れる。この際、フレーム出力部１４０は、フレーム生成部１３０から１フレームに該当するパケットを取って、これをフレームにしてデコーディング部に送ることができる。またフレーム出力部１４０に保存空間が多い場合、一定数量のフレームを構成する多数のパケットを一度に取ってフレームを生成して出力しうる。これは各システムの構成によって異なる。
【００６１】
フレーム生成部１３０は、最大フレーム数より現在フレーム数が小さいので、パケットを受信しうる。そして、フレーム生成部１３０は、前記パケットを受信しつつ、保存されたフレームはフレーム出力部１４０が持続的に取って出力しうる。この過程でフレーム生成部１３０に保存されたフレーム数が最小フレーム数より多くなるように、または保存されたフレーム数が最大フレーム数より少なくなるように流れ制御を行える。
【００６２】
図７は、本発明の一実施例に係るフレームの属性が変更される場合、フレーム生成部とフレーム生成情報設定部との変化を示すブロック図である。
【００６３】
フレーム生成情報設定部１３５の最大、最小フレーム数は如何なる媒体でも同一に適用されるものではない。これは秒当りフレーム数がコンテンツによって変わるためである。図７から分かるように、Ａというコンテンツは秒当りフレーム数が２５なので、１０秒の遅延時間を有する場合、最小フレーム数が２５０であり、１５秒の遅延時間を予想して最大フレーム数が３７５となる。Ｂというコンテンツは秒当りフレーム数が３０なので、１０秒の遅延時間を有する場合、最小フレーム数が３００であり、１５秒の遅延時間を予想して最大フレーム数が４５０となる。したがって、このような相異なるコンテンツの場合にも一定に遅延時間を保持できて不要なバッファリングを防止しうる。
【００６４】
一方、前記例でフレーム生成に必要な情報は必ずしも秒当りフレーム数ではない。すなわち、ＨＤ、ＳＤのように画質の特性を定義したフィールドの値を読み取りうる。もし、同じ秒当りフレーム数でエンコーディングされ、コンテンツが高画質あるいは低画質に分けられるならば、フレームヘッダにこのような情報を含みうる。また、１つのフレームを構成する情報の大きさを通じて如何ほどのフレームを保存するかを判断する根拠として使用しうる。このような情報を通じてフレーム生成部は受信したパケットが構成するフレームの属性によって如何ほどのデータを保存できるのかを算出しうる。
【００６５】
その他にも、コンテンツが有する属性によって、このコンテンツが切れずに持続的に再生されねばならないコンテンツであるか、あるいは迅速に再生されねばならないコンテンツであるかを判断して、保存するフレーム数を異ならせうる。例えば、コンテンツの伝送がネットワークの状況に照らし合せ遅くなれば、これに合わせて保存するフレーム数を増やせる。したがって、コンテンツの属性は単純にフレーム数、または画質だけでなく、コンテンツの再生及び伝送に関する情報も含む。このような情報はフレームヘッダに保存されうる。
【００６６】
図８は、本発明の一実施例に係るフレーム生成部に保存されるフレームの量を示すグラフである。図７で説明したように受信されるコンテンツの属性が変わる場合、保存されるパケットの量が変わることが分かる。
【００６７】
コンテンツの属性にＡ及びＢがあると仮定する。Ａは、低画質のコンテンツであり、または切れない伝送よりは速い伝送を所望するコンテンツであり得る。一方、Ｂは高画質のコンテンツであり、また速い伝送よりは切れない伝送を所望するコンテンツであり得る。図８を低画質及び高画質の場合を想定して説明する。保存されるパケットの量は一定に増加して再び減るが、減る理由は最大フレーム数に到達すればフレーム出力部に出力されるためである。
【００６８】
（１）の場合を説明する。（１）ではコンテンツを初期に必要な量だけバッファリングして出力する段階である。初期遅延時間に該当するフレーム数は最大値または最小値と異なることがあるからである。Ａ属性のコンテンツの最大フレーム数はＡｍａｘであり、最小フレーム数はＡｍｉｎである。したがって、フレーム生成部がＡｍａｘより多くのパケットを保存すれば、フレーム出力部がフレームを出力させる。またＡｍｉｎより多くのデータが保存されて保持されるように遅延制御部は制御を行う。
【００６９】
（２）ではＡｍａｘに到達してパケットを出力することが分かる。また、ＡｍａｘとＡｍｉｎ間を保持しつつ、持続的にデータを出力しうる。一方、ネットワークの性能が優れてＢ属性のコンテンツを送れる場合、最大フレーム数と最小フレームとに変化が生じることがある。Ｂ属性で保存する最大フレームの量はＢｍａｘであり、最小フレームの量はＢｍｉｎである。これは、受信されたフレームの情報より抽出しうる。したがって、Ｂ属性のコンテンツの受信中にはＡ属性のコンテンツを受信する場合と異なりうる。Ｂ属性のコンテンツを受信する（３）で保存されるパケット量のパターンが変化することが分かる。一方、ネットワーク状態の低下によって再びＡ属性のコンテンツを受信する場合、（４）と同様に再びＡｍａｘとＡｍｉｎとに変更され、この間にデータが保持されるように制御しうる。
【００７０】
上記のＡｍｉｎ、Ａｍａｘ、Ｂｍｉｎ、Ｂｍａｘは、フレーム生成情報設定部に設定されてフレーム生成部が如何ほどのデータを保持しなければならないかが分かるようにする。
【００７１】
図９は、本発明の一実施例に係るストリーミングクライアントがデータをフレーム単位で保存して出力する過程を示すフローチャートである。
【００７２】
パケット受信部１２０は、送受信部１２５がストリーミングサーバーから受信したデータでフレームを構成するパケットを受信する（Ｓ１１０）。パケット受信部１２０はパケットをフレーム生成部１３０に送る。フレーム生成部は、受信したパケットのフレーム情報を調べて、受信したパケットが以前に受信したフレームの属性と異なるかを比較する（Ｓ１２０）。フレームの属性が変わる例は、低画質のコンテンツの受信中にネットワークにトラフィックが少なくて高画質のコンテンツで受信する場合などを意味する。または、以前に受信したフレームがなくて、フレーム生成に必要な情報がない場合にもこれに該当する。ここで以前に受信したフレームと異なる属性のフレームとを伝送するパケットであれば、フレーム生成情報設定部に保存された情報を変更し（Ｓ１２２）、Ｓ１２４に進む。以前に受信したフレームと同じ属性のパケットであれば、Ｓ１２２段階を経ずに、パケットがフレームの開始か否かを検討する（Ｓ１２４）。
【００７３】
受信したパケットがフレームの開始でなく、かつ現在生成しているフレームがないならば、これはパケットの受信自体がコンテンツの中間から伝送されたということを意味する。すなわち、ユーザがストリーミングされるマルチメディアの中間時点に該当するポジションを選択する場合、フレームの開始を含むパケットでない、中間パケットから受信しうる。これらパケットを受信した場合には、１つのフレームを生成できないので、捨てることができる。
【００７４】
ここで、パケットの集合またはまとめは、前述したパケットをフレーム別にリンクを構成して連結するか、または順次に保存するなどの方式を使用してパケットをフレーム別に束ねた単位を意味する。
【００７５】
受信したパケットが新しいフレームの開始でなく、以前に受信したフレームを表したパケットであれば、生成中の、前記フレームを構成するために順次に保存したパケットの集合（あつまり）に前記受信したパケットを追加する（Ｓ１３０）。パケットが新たなフレームの開始であれば、生成中のパケットの集合（あつまり）を整理する過程が必要である（Ｓ１３２）。現在生成中のパケットの集合は、他のフレーム（以前フレーム）に対するパケットの集合であるためである。パケットの集合を整理した後、新たなパケットの集合を生成せねばならない（Ｓ１３４）。なぜなら、新たなフレームに対する最初のパケットであるからである。
【００７６】
一方、１つのフレームに関連したパケットがＳ１３２段階で完結されたので、フレーム生成情報設定部の現在フレーム数を１だけ加算する（Ｓ１３６）。現在フレーム数が１だけ加算されることによって、保存されたフレームが適正な数を超えるか否かを検討せねばならない（Ｓ１３８）。適正な数は、システムと状況により最大フレーム数または最小フレーム数になりうる。例えば、保存されたフレーム数が遅延時間を考慮して十分に出力しても良いくらいのフレーム数を超えるならば、フレーム出力部はフレーム生成部に保存されたフレームを取ってデコーディング部に出力する（Ｓ１４０）。一方、Ｓ１３８段階でフレーム数を超えないとしても、最小フレーム数以下になるまでは、コンテンツが持続的に出力されうるように、フレーム生成部に保存されたフレームが出力されうる。これはコンテンツの性格とストリーミング時点の状況によって変わりうる。
【００７７】
本発明が属する技術分野で当業者ならば本発明がその技術的思想や必須特徴を変更せずとも他の具体的な形に実施されうるということが理解できるであろう。したがって、前述した実施例は全ての面で例示的なものであって、限定的なものではないと理解せねばならない。本発明の範囲は詳細な説明よりは特許請求の範囲により表れ特許請求の範囲の意味及び範囲、そしてその均等概念から導かれるあらゆる変更または変形された形態が本発明の範囲に含まれると解釈されなければならない。
【産業上の利用可能性】
【００７８】
本発明は、ＡＶデータ受信時のバッファ量をコンテンツ属性によって弾力的に調節する技術分野に好適に適用しうる。
【図面の簡単な説明】
【００７９】
【図１】既存のストリーミングクライアントの動作を示すブロック図である。
【図２】本発明の一実施例に係るフレームのデータサイズによるバッファ保存を示すブロック図である。
【図３】ビデオストリームの構造を概略的に示す例示図である。
【図４】本発明の一実施例に係るストリーミングクライアントの構成を示すブロック図である。
【図５】本発明の一実施例に係るフレーム生成部で管理するパケットとフレームの構造を示すブロック図である。
【図６Ａ】本発明の一実施例に係るパケット受信からフレーム出力に至るまでのフレーム生成部の変化を示すブロック図である。
【図６Ｂ】本発明の一実施例に係るパケット受信からフレーム出力に至るまでのフレーム生成部の変化を示すブロック図である。
【図７】本発明の一実施例に係るフレームの属性が変更される場合、フレーム生成部とフレーム生成情報設定部との変化を示すブロック図である。
【図８】本発明の一実施例に係るフレーム生成部に保存されるフレームの量を示すグラである。
【図９】本発明の一実施例に係るストリーミングクライアントがデータをフレーム単位で保存して出力する過程を示すフローチャートである。
【符号の説明】
【００８０】
１００    ストリーミングクライアント
１１０    遅延制御部
１２０    パケット受信部
１３０    フレーム生成部
１３５    フレーム生成情報設定部
【図１】
2006050604.tif 000003
【図２】
2006050604.tif 000004
【図３】
2006050604.tif 000005
【図４】
2006050604.tif 000006
【図５】
2006050604.tif 000007
【図６Ａ】
2006050604.tif 000008
【図６Ｂ】
2006050604.tif 000009
【図７】
2006050604.tif 000010
【図８】
2006050604.tif 000011
【図９】
2006050604.tif 000012