JPWO2004040908A1 - Stream server - Google Patents

Stream server Download PDF

Info

Publication number
JPWO2004040908A1
JPWO2004040908A1 JP2004547993A JP2004547993A JPWO2004040908A1 JP WO2004040908 A1 JPWO2004040908 A1 JP WO2004040908A1 JP 2004547993 A JP2004547993 A JP 2004547993A JP 2004547993 A JP2004547993 A JP 2004547993A JP WO2004040908 A1 JPWO2004040908 A1 JP WO2004040908A1
Authority
JP
Japan
Prior art keywords
data
hit
content
live
miss determination
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004547993A
Other languages
Japanese (ja)
Other versions
JP4408811B2 (en
Inventor
祐司 野村
祐司 野村
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fujitsu Ltd
Original Assignee
Fujitsu Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fujitsu Ltd filed Critical Fujitsu Ltd
Publication of JPWO2004040908A1 publication Critical patent/JPWO2004040908A1/en
Application granted granted Critical
Publication of JP4408811B2 publication Critical patent/JP4408811B2/en
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N7/00—Television systems
    • H04N7/16—Analogue secrecy systems; Analogue subscription systems
    • H04N7/162—Authorising the user terminal, e.g. by paying; Registering the use of a subscription channel, e.g. billing
    • H04N7/165—Centralised control of user terminal ; Registering at central

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

ストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバに関し、不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度等にリアルタイムに対応したコンテンツ配信又はライブ配信を行う。Regarding a stream server that distributes live and content using the Internet or the like by streaming technology as a medium, the environment given to each unspecified number of user terminals, that is, the network load, the processing capability of the user terminals, or the stream server Content distribution or live distribution corresponding to the degree of congestion in real time.

Description

本発明はストリーム・サーバに関し、特にストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバに関するものである。
近年、ＡＤＳＬ及び無線ＬＡＮ等の普及によるインターネット等のネットワークのブロードバンド化が進んでいる。これに伴い、データ、音声、映像等を送受信するマルチメディア・多チャネルの通信環境が急速に整備されている。さらに、常時接続が一般化され、情報家電とネットワークの融合化が促進され、映像・音楽等のコンテンツ配信及びライブ配信等の需要が拡大している。
このようなネットワークにおいては、マルチメディアを多重化して１つのディジタル情報の流れとして扱うストリーミング技術によるライブ及びコンテンツを配信は重要である。The present invention relates to a stream server, and more particularly to a stream server that distributes live content and contents using the Internet or the like based on streaming technology or the like as a medium.
In recent years, networks such as the Internet are becoming broadband due to the spread of ADSL and wireless LAN. Accordingly, a multi-media / multi-channel communication environment for transmitting / receiving data, audio, video, etc. has been rapidly established. Furthermore, the constant connection is generalized, the integration of information appliances and networks is promoted, and the demand for content distribution such as video / music and live distribution is expanding.
In such a network, it is important to distribute live and content by streaming technology that multiplexes multimedia and handles it as one digital information flow.

図１０は、従来のライブ配信及びコンテンツ配信例を示している。ユーザ端末（ＰＤＡ）１７０＿２がライブ７２０を配信要求したときに、キャッシュサーバ１５０＿２がライブ７２０を保持していない場合、映像入力装置１２０で撮影されたライブ７２０は、リアルタイムエンコーダ１３０に与えられる。
エンコーダ１３０は、ライブ７２０を、要求された符号化方式・符号化レートのデータに変換して、ＩＰネットワーク１４０及びキャッシュサーバ１５０＿２を経由したライブ配信７２０ａで、ユーザ端末１７０＿２に送信する。このとき、キャッシュサーバ１５０＿２は、ライブ７２０を一時的に記憶する。
ユーザ端末（携帯電話）１７０＿３が、同じ符号化方式・符号化レートのライブ７２０を配信要求したとき、キャッシュサーバ１５０＿２は、記憶したライブ７２０を、ライブ配信７２０ｂでユーザ端末１７０＿３に送信する。
コンテンツ７１０は、コンテンツサーバ１１０のソースデータベース７００に格納されている。ユーザ端末（デスクトップＰＣ）１７０＿１がコンテンツ７１０を配信要求したときに、キャッシュサーバ１５０＿１がコンテンツ７１０を記憶していない場合、コンテンツ７１０は、コンテンツサーバ１１０からＩＰネットワーク１４０及びターミナルアダプタ（ＴＡ）１６０を経由して、ユーザ端末１７０＿１にコンテンツ配信７１０ａが行われる。
このとき、キャッシュサーバ１５０＿１は、コンテンツ７１０を一時記憶する。この後、例えば、ユーザ端末１７０＿２からコンテンツ７１０の配信要求があったときのキャッシュサーバ１５０＿１の動作は、キャッシュサーバ１５０＿２と同様である。
ライブ配信７２０ａ，７２０ｂ及びコンテンツ配信７１０ａは、例えば、リファレンスデータ参照による伸長処理を行うＭＰＥＧストリーム等で行われる。
ＩＰネットワーク１４０は、基本的にはベストエフォート型であり、ＭＰＥＧストリームを長時間途切れずに配信には適応していない。
この課題を解決する従来技術として、例えば、リアルタイム転送プロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ、以下、ＲＴＰと称する。）、リアルタイム転送制御プロトコル（Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、以下、ＲＴＣＰと称する。）、及びリアルタイム・ストリーム制御プロトコル（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ、以下ＲＴＳＰと称する。）等のストリーミング技術がある。
ＲＴＰは、メディア同期が受信側で可能となるように、音声データや映像データを伝送する際のパケット形式を定めた伝送プロトコルである。ＲＴＳＰは、コンテンツの配信開始や一時停止等のようなストリーム制御を行うプロトコルである。ＲＴＣＰは、音声や映像のストリームに対するフロー制御に必要な情報やメディア同期のための基準時間情報を伝達する手順を定めているプロトコルである。
これらのプロトコルによって、ユーザ端末と配信元とのネゴシエーション、データ配信時におけるネットワーク負荷、及びユーザ端末の処理能力等の与えられた環境を考慮したより快適なＲＴＰストリーム（コンテンツ配信又はライブ配信）がリアルタイムで制御される。
しかしながら、従来のストリーミング環境においては、ライブ配信は、ストリーム・サーバ（配信側）から、固定化された複数の符号化レートのデータを不特定多数のユーザ端末（受信側）に対して配信している。
ユーザ端末は、自身の処理能力に応じて、配信元から固定化された複数の符号化レートのデータの内から選択して受信している。従って、不特定多数のユーザ端末に対して、それぞれ、ネットワーク負荷及びユーザ端末の処理能力等をリアルタイムに考慮した、快適なマルチキャスト型のコンテンツ配信及びライブ配信を実現していない。
すなわち、従来のストリーミング環境は、コンテンツ配信において、或る１つのコンテンツ（ワンソース）を、符号化方式のみならず、リアルタイムな最適符号化レートも各ユーザ端末に対応したデータ（マルチユース）を配信することは困難である。
これを解決するためには、ユーザ端末数分のリアルタイムエンコーダ、若しくは全符号化レートのデータのデータベースといった、莫大なハードウェアが必要であり現実的ではない。
すなわち、コンテンツ、符号化方式のみならず符号化レートまでを範疇としたワンソース・マルチユース化ができない。
また、ライブ配信において、リアルタイムエンコーダ１３０がリアルタイムエンコードデータを、そのままネットワークに配信するため、ユーザ端末は、コンテンツ・サーバに対して、巻き戻し、一時停止等のコミュニケーション（選択性）の拡張が困難である。
したがって、ユーザ端末は、コンテンツ配信とライブ配信が異なることを考慮したサービスを受けなければならない。また、配信サーバは、コンテンツ・サーバとライブ・サーバが独立装置であり、それぞれ独立に制御する必要があり、コンテンツ配信とライブ配信の融合が困難である。
コンテンツ配信において、コンテンツに対応する複数の符号化データを予めデータベース化しているため、多数のユーザが視聴する映画コンテンツ、或る個人ユーザのみが視聴するパーソナルビデオコンテンツに関係なく、全コンテンツデータをデータベース化する必要があり、莫大なデータベース容量が必要となる。
このため、最近のトレンドである個人ユーザがオリジナルに制作したディジタルコンテンツ等を格納するパーソナルデータベースの構築にも限界が生じる。
また、コンテンツ配信において、データベースは、圧縮された符号化データを格納しており、ＭＰＥＧストリームにおけるシーケンスヘッダの任意位置への挿入／削除が困難なため、ユーザ端末（受信側）任意の映像の頭出し機能、アクセス回線種別、ネットワークの混雑度、ユーザ端末処理能力等を考慮した最適符号化レート／解像度変更等が困難である。
また、従来のコンテンツ配信又はライブ配信は、配信サーバとキャッシュサーバ（エッジサーバ）が独立配備かつ独立動作しており、キャッシュサーバでは、ユーザ端末（受信側）から要求されたコンテンツ又はライブ、符号化方式を考慮したヒット／ミス判定は可能である。
しかし、ネゴシエーション又はユーザ端末からのＲＲ（Ｒｅｃｅｉｖｅｒ Ｒｅｐｏｒｔ）タイプのＲＴＣＰパケットのフィードバックをトリガとして決定した符号化レートまでを考慮した要求データの視聴開始／停止／変更を管理できない。したがって、視聴率を考慮したヒット／ミス判定を実施することが困難である。
従来のコンテンツ配信又はライブ配信は、ネゴシエーション動作時又はストリーミングにおけるＲＲタイプのＲＴＣＰパケットフィードバック時のような、ユーザ端末からのアクションに対応して、ストリーム・サーバが動作している。
したがって、ある映画コンテンツの配信開始となった日時に不特定多数ユーザからの視聴要求が重なった場合に、トランスコーダ（ｔｒａｎｓｃｏｄｅｒ）へのアクセス競合が多数発生し、ユーザ端末に対する配信サービスの即応性が困難になる。
また、従来のコンテンツ配信又はライブ配信におけるキャッシュサーバ（エッジサーバ）は、様々なコンテンツ又はライブデータ、符号化方式、符号化レート等のデータが格納されており、ユーザ端末が要求するデータの有無の確認を全格納データに対して行うため、そのヒット／ミス判定回路は莫大なハードウェア規模が必要になる。
また、従来のコンテンツ配信又はライブ配信は、配信サーバとキャッシュサーバ（エッジサーバ）が独立配備かつ独立動作しており、ユーザ端末からのキャッシュサーバ（エッジサーバ）内に格納されていない新コンテンツ又はライブ、新符号化方式、新符号化レートが要求された場合、ミス判定になる。
これにより、配信サーバは上記コンテンツ、符号化方式に対応したデータをキャッシュサーバに配信するため、キャッシュサーバは、必ず既に格納されているデータを破棄しなければならない。
また、キャッシュサーバ（エッジサーバ）のヒット／ミス判定において、配信サーバ側の混雑度等を考慮しないため、配信サーバの即応性が悪い場合には、配信データのスループットの低下、揺らぎ等が発生する。
また、従来の階層符号化において、ある階層データの符号化レート又は解像度等を変更する場合には、上記階層をリファレンスデータとして参照し、符号化処理を実施する。
以後、全上位階層データも再生成する必要があるため、莫大なハードウェアが必要となり、かつトランスコーダ等の資源の使用回数の増大（資源の有効活用が困難）を招く。
そこで本発明は、ストリーミング技術等によるインターネット等を媒体としてライブ及びコンテンツを配信するストリーム・サーバにおいて、以下の項目（１）〜（９）を目的とする。
（１）不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度等にリアルタイムに対応したコンテンツ配信又はライブ配信を行う。
（２）コンテンツ配信とライブ配信とを融合することを、少ないハードウエアで実現する。
（３）必要なデータベースの容量を削減する。
（４）要求されたコンテンツ及び符号化方式のみならず、要求された符号化レートに対応したワンソース・マルチユースを実現する。
（５）ユーザ端末が、アクセス回線種別、ネットワークの混雑度、及びユーザ端末処理能力に対応した、任意の映像の頭出し、最適符号化レート変更、及び解像度変更を行うことを可能とする。
（６）視聴率に対応したコンテンツ又はライブ配信サービスを行う。
（７）ユーザが要求したデータの有無の判定を高速化する。
（８）ユーザから要求された新コンテンツ又は新ライブ、新符号化方式、及び新符号化レートのデータのヒットミスを少なくする。
（９）階層符号化において、符号化レート及び解像度の変更の効率化を図る。
〈先行技術文献〉
・特開２０００−２２８６６９号
・特開２００１−５４０９５号
・特開２００１−５４０９４号
・特開平１０−１０８１６０号
・特開２０００−２９９７０２号FIG. 10 shows an example of conventional live distribution and content distribution. When the user terminal (PDA) 170_2 requests the live 720 to be distributed, if the cache server 150_2 does not hold the live 720, the live 720 captured by the video input device 120 is given to the real-time encoder 130.
The encoder 130 converts the live 720 into data of the requested encoding method and encoding rate, and transmits the data to the user terminal 170_2 through the live distribution 720a via the IP network 140 and the cache server 150_2. At this time, the cache server 150_2 temporarily stores the live 720.
When the user terminal (mobile phone) 170_3 requests distribution of the live 720 having the same encoding method and encoding rate, the cache server 150_2 transmits the stored live 720 to the user terminal 170_3 through the live distribution 720b.
The content 710 is stored in the source database 700 of the content server 110. When the user terminal (desktop PC) 170_1 requests distribution of the content 710 and the cache server 150_1 does not store the content 710, the content 710 passes from the content server 110 via the IP network 140 and the terminal adapter (TA) 160. Then, the content distribution 710a is performed to the user terminal 170_1.
At this time, the cache server 150_1 temporarily stores the content 710. Thereafter, for example, the operation of the cache server 150_1 when there is a distribution request for the content 710 from the user terminal 170_2 is the same as that of the cache server 150_2.
The live distributions 720a and 720b and the content distribution 710a are performed by, for example, an MPEG stream that performs decompression processing with reference to reference data.
The IP network 140 is basically a best-effort type, and is not adapted for distribution without interrupting the MPEG stream for a long time.
As conventional techniques for solving this problem, for example, a real-time transfer protocol (hereinafter referred to as RTP), a real-time transfer control protocol (hereinafter referred to as RTCP), and a real-time transfer control protocol (hereinafter referred to as RTCP). There is a streaming technology such as a Real Time Stream Control Protocol (hereinafter referred to as RTSP).
RTP is a transmission protocol that defines a packet format for transmitting audio data and video data so that media synchronization is possible on the receiving side. RTSP is a protocol that performs stream control such as start and pause of content distribution. RTCP is a protocol that defines a procedure for transmitting information necessary for flow control on audio and video streams and reference time information for media synchronization.
By these protocols, more comfortable RTP streams (content distribution or live distribution) considering the given environment such as negotiation between the user terminal and the distribution source, network load at the time of data distribution, and processing capability of the user terminal are realized in real time It is controlled by.
However, in the conventional streaming environment, live distribution distributes data at a plurality of fixed encoding rates from a stream server (distribution side) to an unspecified number of user terminals (reception side). Yes.
The user terminal selects and receives data from a plurality of encoding rate data fixed from the distribution source according to its own processing capability. Therefore, comfortable multicast-type content distribution and live distribution in which the network load and the processing capacity of the user terminal are considered in real time are not realized for a large number of unspecified user terminals.
That is, in the conventional streaming environment, in content distribution, not only one encoding method (one source) but also data corresponding to each user terminal (multi-use) is distributed not only in the encoding method but also in the real-time optimum encoding rate. It is difficult to do.
In order to solve this, enormous hardware such as real-time encoders for the number of user terminals or a database of data of all coding rates is required, which is not practical.
In other words, it is not possible to achieve one-source / multi-use that covers not only contents and encoding methods but also encoding rates.
Further, in live distribution, the real-time encoder 130 distributes real-time encoded data as it is to the network, so that it is difficult for the user terminal to expand communication (selectivity) such as rewinding and pausing to the content server. is there.
Therefore, the user terminal must receive a service considering that content distribution and live distribution are different. In addition, in the distribution server, the content server and the live server are independent devices, and it is necessary to control them independently, and it is difficult to merge the content distribution and the live distribution.
In content distribution, since a plurality of encoded data corresponding to the content is stored in a database in advance, all content data is stored in a database regardless of movie content viewed by many users and personal video content viewed only by a certain individual user. And a huge database capacity is required.
For this reason, there is a limit to the construction of a personal database that stores digital contents originally produced by individual users, which is a recent trend.
In content distribution, a database stores compressed encoded data, and it is difficult to insert / delete a sequence header at an arbitrary position in an MPEG stream. It is difficult to change the optimum encoding rate / resolution in consideration of the output function, access line type, network congestion, user terminal processing capability, and the like.
In addition, in the conventional content distribution or live distribution, the distribution server and the cache server (edge server) are independently deployed and operated independently. In the cache server, the content requested from the user terminal (receiving side) or live, encoded Hit / miss determination in consideration of the method is possible.
However, it is not possible to manage the start / stop / change of the request data in consideration of the encoding rate determined by negotiation or feedback of an RR (Receiver Report) type RTCP packet from the user terminal as a trigger. Therefore, it is difficult to perform hit / miss determination in consideration of the audience rating.
In conventional content distribution or live distribution, a stream server is operated in response to an action from a user terminal, such as at the time of negotiation operation or feedback of an RR type RTCP packet in streaming.
Therefore, when a viewing request from an unspecified number of users overlaps at the date and time when distribution of a certain movie content starts, many access conflicts to the transcoder occur, and the responsiveness of the distribution service to the user terminal is increased. It becomes difficult.
Further, a cache server (edge server) in conventional content distribution or live distribution stores various contents or live data, data such as an encoding method and an encoding rate, and whether or not there is data requested by the user terminal. Since confirmation is performed on all stored data, the hit / miss judgment circuit requires a huge hardware scale.
In addition, conventional content distribution or live distribution has a distribution server and a cache server (edge server) independently deployed and operated independently, and new content or live content not stored in the cache server (edge server) from the user terminal. When a new encoding method and a new encoding rate are requested, a miss determination is made.
Accordingly, since the distribution server distributes data corresponding to the content and the encoding method to the cache server, the cache server must always discard already stored data.
In addition, in the hit / miss determination of the cache server (edge server), the degree of congestion on the distribution server side is not taken into account, so that when the distribution server is not responsive, the throughput of the distribution data is reduced, fluctuations, etc. occur. .
Further, in the conventional hierarchical encoding, when changing the encoding rate or resolution of certain hierarchical data, the hierarchical processing is referred to as reference data and the encoding process is performed.
Thereafter, since it is necessary to regenerate all the upper layer data, a huge amount of hardware is required, and the number of times of use of resources such as a transcoder is increased (it is difficult to effectively use resources).
SUMMARY OF THE INVENTION The present invention is directed to the following items (1) to (9) in a stream server that distributes live and content using the Internet or the like by streaming technology as a medium.
(1) The content distribution or the live distribution corresponding to the given environment, that is, the network load, the processing capacity of the user terminal, the congestion degree of the stream server, or the like is performed to the unspecified large number of user terminals.
(2) Fusing content distribution and live distribution is realized with a small amount of hardware.
(3) Reduce the required database capacity.
(4) Realize one-source multi-use corresponding to the requested encoding rate as well as the requested content and encoding method.
(5) It is possible for the user terminal to perform arbitrary cueing, optimum coding rate change, and resolution change corresponding to the access line type, network congestion, and user terminal processing capability.
(6) Provide a content or live distribution service corresponding to the audience rating.
(7) Speed up the determination of the presence or absence of data requested by the user.
(8) To reduce hit mistakes in data of new contents or new live requested by the user, new encoding method, and new encoding rate.
(9) In hierarchical encoding, the efficiency of changing the encoding rate and resolution is improved.
<Prior art documents>
-JP 2000-228669-JP 2001-54095-JP 2001-54094-JP 10-108160-JP 2000-299702

上記の課題を解決するため、本発明のストリーム・サーバは、１つ以上のトランスコーダと、データを格納するキャッシュ型データベースと、コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット／ミス判定部と、を備えたことを特徴としているストリーム・サーバ。
すなわち、トランスコーダは、通常の如く、指定されたコンテンツ又はライブを、指定された符号化方式の指定された符号化レートのデータに変換する。このデータをキャッシュ型データベースは格納する。
ヒット／ミス判定部は、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、要求されたデータをキャッシュ型データベースに格納することを、トランスコーダ及びキャッシュ型データベースが連携して制御する。
これにより、キャッシュ型データベースは、例えばユーザ端末から要求されたコンテンツ又はライブを、要求された符号化方式の要求された符号化レートのデータとして格納することになり、各ユーザ端末は、要求した符号化方式の符号化レートのコンテンツ配信又はライブ配信を実現することが可能になる。
なお、ここで言うキャッシュ型データベース及びトランスコーダは、後述するそれぞれ制御／調停部が含んでいるものとするが、以下において、キャッシュ型データベースをキャッシュ型データベース本体とその制御／調停部に分け、トランスコーダをトランスコーダとその制御／調停部に分けて表示することがある。
また、本発明は、該トランスコーダがエンコーダ又はＣＯＤＥＣであることが可能である。
すなわち、本発明においてトランスコーダには、ＣＯＤＥＣ、及びエンコーダを含むものとする。例えば、ライブ配信の場合、トランスコーダの代わりにエンコーダを用いることが可能である。
また、本発明は、該キャッシュ型データベースが、同一のコンテンツ又はライブ及び符号化方式に対して異なる符号化レートの該データをそれぞれ格納する複数のラインを有することができる。
すなわち、キャッシュ型データベースは、複数のラインを有し、これらのラインには、それぞれ、例えば、同一のコンテンツ及び符号化方式に対して異なる符号化レートに変換したデータが格納される。
これにより、不特定多数のユーザ端末に対してマルチキャスト型コンテンツ配信又はライブ配信を実現する。すなわち、コンテンツ又はライブ、符号化方式、さらには符号化レートを各ユーザ端末に対応して配信するワンソース・マルチユースを実現することが可能になる。
また、本発明は、ユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻し制御に関するネゴシエーションを行い、その結果を該ヒット／ミス判定部に通知する呼制御／ネゴシエーション処理部をさらに有し、該ヒット／ミス判定部が、該結果に基づき該トランスコーダ及び該キャッシュ型データベースに対する連携制御を行うことが可能である。
すなわち、呼制御／ネゴシエーション処理部はユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻しのネゴシエーションを行う。
この結果に基づき、ヒット／ミス判定部は、キャッシュ型データベースに格納されたデータの配信の開始、一時停止、又は巻戻し制御を行う。
これにより、コンテンツ配信に対する開始、一時停止、巻戻制御が可能になるとともにライブ配信をデータをキャッシュ型データベースに格納後、行うことにより、ライブ配信に対する開始、一時停止、巻戻制御も可能になる。
また、本発明は、さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット／ミス判定部に与えるネットワーク監視部を有し、該ヒット／ミス判定部が該監視結果に基づき最適符号化レートを決定することができる。
すなわち、ネットワーク監視部は、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力を監視する。この監視結果に基づきヒット／ミス判定部は、各ユーザ端末に対する最適な符号化レートを決定する。
これにより、例えば、ネットワーク負荷、コンテンツサーバの混雑度、ユーザ端末の現在の処理能力等をリアルタイムで考慮した符号化レートのコンテンツ配信又はライブ配信が可能になる。
すなわち、与えられた環境の中で、ユーザに対して、より快適なコンテンツ配信又はライブ配信をリアルタイムに制御することが可能になる。
また、本発明では、所定のプロトコルを実装し、該所定プロトコルに基づきユーザ端末との間の通信処理を行うプロトコル実装処理部をさらに有することができる。
すなわち、プロトコル実装処理部は、本ストリーム・サーバとユーザ端末との間の通信処理を行うプロトコルを実装している。この実装されたプロトコルに基づき、コンテンツ配信又はライブ配信の及びそれらの制御を実行することができる。
また、本発明では、該プロトコル実装処理部が、少なくともＩＰヘッダ処理部、ＵＤＰヘッダ処理部、ＲＴＰヘッダ処理部、ＲＴＣＰヘッダ処理部、及びＲＴＳＰヘッダ処理部の中のいずれか１つを備えることができる。
これにより、ＩＰ、ＵＤＰ、ＲＴＰ、ＲＴＣＰ、ＲＴＳＰ等のプロトコルに基づきコンテンツ配信又はライブ配信及びそれらの制御することが可能になる。
また、本発明では、該プロトコル実装処理部が、ＭＰＥＧシーケンスヘッダ処理部を備えていることができる。
これにより、アクセス回線種別、ネットワークの混雑度、又はユーザ端末能力を考慮した、ＭＰＥＧ符号化方式の最適符号化レートの変更及び解像度変更、並びに任意の映像の頭出し機能等が容易になる。
また、本発明では、該トランスコーダが、入力した少なくとも素材データ、トランスコードデータ、及びライブデータの内のいずれか１つを該指定された符号化方式の指定された符号化レートのデータに変換することができる。
すなわち、トランスコーダは、例えば、ソースデータベース装置から素材データ又はトランスコードデータを入力し、映像入力装置からライブデータを入力して該データに変換することができる。
なお、ストリーム・サーバとソースデータベース装置及び映像入力装置との接続は、直接接続及びネットワークを介した接続のいずれでもよい。
また、本発明では、該ヒット／ミス判定部が、要求されたコンテンツ又はライブの検索、その符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序を所定の順序で行い要求データのヒット／ミス判定を行うことができる。
すなわち、ヒット／ミス判定部は、例えば、要求されたコンテンツ又はライブ及びその符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序で要求データのヒット／ミス判定を行う。
これにより、ヒット／ミス判定が容易になると共に、ハードウェアの大幅な削減が可能になる。
また、本発明では、該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されているか否かの判定に、該符号化レートが許容範囲に入っている否かを判定することができる。
すなわち、該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートに変換されたのデータが該キャッシュ型データベースに格納されているか否かの判定するとき、例えば、要求された符号化レートと同一符号化レートでなく、要求された符号化レートから許容範囲にある符号化レートのデータもヒットしたものとみなす。
これにより、要求された符号化レートの代わりに、許容範囲内の符号化レートのデータを配信することが可能になり、要求された全ての符号化レートのデータを格納する必要がなくなり、効率的にキャッシュ型データベースを運用することが可能になるとともに、安定したコンテンツ配信及びライブ配信が実現する。
また、本発明では、該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていないとき、該要求されたコンテンツ又はライブ、要求された符号化方式であり、該要求された符号化レートに近い符号化レートのデータを破棄し、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御することができる。
すなわち、ヒット／ミス判定部は、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていなとき、該要求されたコンテンツ又はライブであって要求された符号化方式であるが、該要求された符号化レートに近い符号化レートのデータを検索して破棄する。
そして、ヒット／ミス判定部は、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御する。
これにより、要求されたデータをユーザ端末に配信することが可能になる。
また、本発明では、該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、又は低視聴率の符号化レートのデータを破棄することができる。
これにより、該キャッシュ型データベースのサイズを削減することが可能になるとともに、高視聴率のコンテンツ又はライブのデータを保持され続けるため、キャッシュ型データベースのヒット率も高くなる。
また、本発明では、該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納し、該ヒット／ミス判定部が、該情報に基づきヒット／ミス判定を行うことができる。
すなわち、該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納する。該ヒット／ミス判定部が、該情報に基づき、例えば、リアルタイムな視聴率を計算し、この視聴率に基づきヒット／ミス判定を行う。
これにより、ヒット／ミス判定部は、例えば、リアルタイムな視聴率を考慮したヒット／ミス判定を行うことが可能になる。
また、本発明では、該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータの内の少なくとも１つを破棄して、該破棄されたデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納するように該トランスコーダ及びキャッシュ型データベースに指示することができる。
すなわち、ヒット／ミス判定部は、例えば、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する場所がキャッシュ型データベース内に無いとき、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータを破棄する。
そして、破棄したデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する。
これにより、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納する場所を確保することが可能になる。
また、該キャッシュ型データベースのサイズを削減することが可能になるとともに、高視聴率のコンテンツ又はライブのデータが保持され続ける。
これにより、キャッシュ型データベースのヒット率も高くなり、効率的なキャッシュ型データベースの運用を実現することができる。
また、本発明では、該ヒット／ミス判定部は、未使用トランスコーダがあるとき、このトランスコーダ及び該キャッシュ型データベースを制御して、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納することができる。
すなわち、ヒット／ミス判定部は、新規コンテンツ又は新規ライブがあるときで、且つ使用していないトランスコーダがあるとき、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納するように該トランスコーダ及び該キャッシュ型データベースを制御する。
これにより、トランスコーダは、例えば、要求されたコンテンツの変換を行っていないときで且つキャッシュ型データベースに空きがあるとき、事前に新規コンテンツを所定符号化方式の所定符号化レートのデータに変換することが可能になる。この結果、トランスコーダ及びキャッシュ型データベースのアクセス競合を回避することが可能になるとともに、資源の有効活用が実現できる
さらに、本発明では、該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はＳＮＲスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることが可能である。
これにより、他に使用されている符号化レートデータに対して影響を与えることなく、ターゲットとなる符号化レートを変更することができる。
また、符号化レート変更対象階層及びその１つ上位の階層を新規作成するのみで、全上位階層のデータを新規に作成する必要がなくなり、莫大なハードウエアが必要でなくなるとともに、トランスコーダ等の資源の使用回数を少なくすることが可能になる。In order to solve the above problems, the stream server of the present invention includes one or more transcoders, a cached database for storing data, and data requested for content or live, encoding scheme, and encoding rate. A hit / miss determination unit that controls the transcoder and the cache database so that the requested data is stored in the cache database when the cache is not stored in the cache database. A stream server characterized by having
That is, as usual, the transcoder converts the designated content or live into data of the designated coding rate of the designated coding method. This data is stored in the cache database.
The hit / miss determination unit is configured to store the requested data in the cache type database when the requested data regarding the encoding method and the encoding rate is not stored in the cache type database. Type database controls in cooperation.
Thereby, the cache type database stores, for example, the content or live requested from the user terminal as data of the requested encoding rate of the requested encoding method, and each user terminal stores the requested code. It is possible to realize content distribution or live distribution at a coding rate of the encoding method.
Note that the cache type database and transcoder referred to here are assumed to be included in the respective control / arbitration units described later. In the following, the cache type database is divided into a cache type database main body and its control / arbitration unit. A coder may be displayed separately for a transcoder and its control / arbiter.
In the present invention, the transcoder may be an encoder or a CODEC.
That is, in the present invention, the transcoder includes a CODEC and an encoder. For example, in the case of live distribution, an encoder can be used instead of a transcoder.
Further, according to the present invention, the cache database may have a plurality of lines each storing the data at different encoding rates for the same content or live and encoding schemes.
In other words, the cache database has a plurality of lines, and for example, data converted into different encoding rates for the same content and encoding scheme is stored in each of these lines.
As a result, multicast content distribution or live distribution is realized for an unspecified number of user terminals. That is, it is possible to realize one-source multi-use that distributes content or live, an encoding method, and an encoding rate corresponding to each user terminal.
Further, the present invention negotiates call control or start control, pause control, or rewind control of the data with the user terminal, and notifies the hit / miss determination unit of the result. It further includes a call control / negotiation processing unit, and the hit / miss determination unit can perform cooperative control on the transcoder and the cache database based on the result.
That is, the call control / negotiation processing unit performs call control or start control, suspension control, or rewind negotiation with the user terminal.
Based on this result, the hit / miss determination unit performs start, pause, or rewinding control of data stored in the cache database.
This enables start, pause, and rewind control for content distribution, and also enables start, pause, and rewind control for live distribution by performing live distribution after storing the data in a cache database. .
The present invention further monitors at least one of the network load with the user terminal, the congestion level of the content server, or the processing capability of the user terminal, and gives the monitoring result to the hit / miss determination unit. A network monitoring unit is included, and the hit / miss determination unit can determine an optimum encoding rate based on the monitoring result.
That is, the network monitoring unit monitors the network load with the user terminal, the congestion level of the content server, or the processing capability of the user terminal. Based on the monitoring result, the hit / miss determination unit determines an optimum encoding rate for each user terminal.
As a result, for example, content distribution or live distribution at an encoding rate considering the network load, the content server congestion level, the current processing capability of the user terminal, and the like in real time becomes possible.
That is, it becomes possible to control more comfortable content distribution or live distribution in real time for a user in a given environment.
Further, the present invention can further include a protocol implementation processing unit that implements a predetermined protocol and performs communication processing with the user terminal based on the predetermined protocol.
That is, the protocol implementation processing unit implements a protocol for performing communication processing between the stream server and the user terminal. Based on this implemented protocol, content distribution or live distribution and their control can be performed.
In the present invention, the protocol implementation processing unit may include at least one of an IP header processing unit, a UDP header processing unit, an RTP header processing unit, an RTCP header processing unit, and an RTSP header processing unit. it can.
This makes it possible to perform content distribution or live distribution and control thereof based on protocols such as IP, UDP, RTP, RTCP, and RTSP.
In the present invention, the protocol implementation processing unit can include an MPEG sequence header processing unit.
As a result, the change of the optimum coding rate and the resolution of the MPEG coding method, the cue function of an arbitrary video, and the like in consideration of the access line type, the network congestion level, or the user terminal capability are facilitated.
In the present invention, the transcoder converts at least one of the input material data, transcode data, and live data into data of a specified encoding rate of the specified encoding method. can do.
That is, the transcoder can input material data or transcode data from a source database device, for example, and can input live data from a video input device and convert it into the data.
The connection between the stream server, the source database device, and the video input device may be either a direct connection or a connection via a network.
Further, in the present invention, the hit / miss determination unit determines the order of the requested content or live search, the search for the encoding method, the search for the encoding rate, and the search for whether the data is valid. It is possible to perform hit / miss determination of request data in a predetermined order.
That is, the hit / miss determination unit, for example, searches for the requested content or live and its encoding scheme, searches for the encoding rate, and the hit / miss of the requested data in the search order of whether the data is valid. Make a mistake decision.
As a result, hit / miss determination is facilitated and the hardware can be greatly reduced.
In the present invention, the hit / miss determination unit determines whether the requested content or live, encoding method, and encoding rate data is stored in the cache database. It can be determined whether or not the conversion rate is within an allowable range.
That is, when the hit / miss determination unit determines whether or not the requested content or data converted to live, encoding method, and encoding rate is stored in the cache database, for example, Therefore, it is considered that data having an encoding rate that is not within the same encoding rate as the requested encoding rate but within an allowable range from the requested encoding rate is hit.
As a result, instead of the requested encoding rate, it is possible to distribute data of an encoding rate within an allowable range, and it is not necessary to store data of all the requested encoding rates, which is efficient. In addition, it is possible to operate a cache type database and realize stable content distribution and live distribution.
In the present invention, when the hit / miss determination unit does not store the requested content or live, encoding method, and encoding rate data in the cache database, the requested content or Live, requested encoding method, discarding data at an encoding rate close to the requested encoding rate, and storing the requested data at the location where the data was stored The transcoder and the cache database can be controlled in cooperation.
That is, when the requested content or live, encoding method, and encoding rate data is not stored in the cache database, the hit / miss determination unit requests the requested content or live and requests it. However, the data of the encoding rate close to the requested encoding rate is retrieved and discarded.
The hit / miss determination unit controls the transcoder and the cache database in cooperation with each other so as to store the requested data at the position where the data is stored.
This makes it possible to distribute the requested data to the user terminal.
Further, according to the present invention, the hit / miss determination unit can discard content data or live data with a low audience rating, or data with a coding rate with a low audience rating.
As a result, the size of the cache database can be reduced, and content with high audience rating or live data can be retained, and the hit rate of the cache database is also increased.
In the present invention, the cache type database stores the viewing start time information, stop time information, and change time information for the requested data given from the network monitoring unit, and the hit / miss information is stored. The determination unit can perform hit / miss determination based on the information.
That is, the cache type database stores the viewing start time information, stop time information, and change time information for the requested data given from the network monitoring unit. The hit / miss determination unit calculates, for example, a real-time audience rating based on the information, and performs hit / miss determination based on the audience rating.
Thereby, the hit / miss determination unit can perform hit / miss determination in consideration of, for example, a real-time audience rating.
In the present invention, the hit / miss determination unit discards at least one of content data or live data with low audience rating, encoding method with low audience rating, or data with encoding rate with low audience rating. And instructing the transcoder and cache database to store the requested content or live, encoding scheme, and encoding rate data at the location where the discarded data was stored. it can.
That is, the hit / miss determination unit, for example, when there is no location in the cache-type database to store the requested content or live, encoding method, and encoding rate data, the content data or live data with low audience rating The data of the encoding method of the low audience rating or the data of the encoding rate of the low audience rating is discarded.
Then, the requested content or live data, encoding method, and encoding rate data are stored in the location where the discarded data was stored.
This makes it possible to secure a location for storing the requested content or live, encoding method, and encoding rate data.
In addition, it is possible to reduce the size of the cache type database, and contents or live data with a high audience rating continue to be retained.
As a result, the hit rate of the cache database is also increased, and an efficient operation of the cache database can be realized.
Also, in the present invention, when there is an unused transcoder, the hit / miss determination unit controls the transcoder and the cache type database so that new content or new live can be encoded at a predetermined encoding rate. Can be stored in the cache type database.
That is, when there is new content or new live and there is a transcoder that is not used, the hit / miss determination unit converts the new content or new live into data of a predetermined encoding method at a predetermined encoding rate. The transcoder and the cache type database are controlled so as to be stored in the cache type database.
As a result, the transcoder, for example, converts the new content into data of a predetermined encoding rate with a predetermined encoding method in advance when the requested content is not converted and when the cache database is empty. It becomes possible. As a result, it is possible to avoid access conflict between the transcoder and the cache type database and realize effective use of resources. Further, in the present invention, the transcoder is based on spatial scalability, temporal scalability, or SNR scalability. In the hierarchical coding, only the encoded data of the coding rate change target layer and the one higher layer thereof is newly created, and the difference between the decoded data expanded from the new higher layer and the decoded data expanded from the current higher layer When the sum of absolute values is less than or equal to a predetermined threshold, the newly created change target hierarchy and higher hierarchy can be made the current hierarchy.
As a result, the target coding rate can be changed without affecting the coding rate data used elsewhere.
Moreover, it is not necessary to newly create all the upper layer data by simply creating the coding rate change target layer and its upper layer, and a huge amount of hardware is not required. Resource usage can be reduced.

図１は、本発明に係るストリーム・サーバの一実施例を示したブロック図である。
図２は、本発明に係るストリーム・サーバにおけるキャッシュ型データベースの一構成例を示したブロック図である。
図３は、本発明に係るストリーム・サーバにおける３段階検索手順例を示した図である。
図４は、本発明に係るストリーム・サーバのネゴシエーション時における動作手順を示したフローチャート図である。
図５は、本発明に係るストリーム・サーバのネットワーク監視時における動作手順を示したフローチャート図である。
図６は、本発明に係るストリーム・サーバにおける要求コンテンツ（又はライブ）及び符号化方式等のヒット／ミス判定及びその後の処理を示した図である。
図７は、本発明に係るストリーム・サーバにおける要求符号化レート等のヒット／ミス判定及びその後の処理を示した図である。
図８は、本発明に係るストリーム・サーバにおける階層符号化における符号化レート変更例（低符号化レート→高符号化レート）を示した図である。
図９は、本発明に係るストリーム・サーバにおける階層符号化における符号化レート変更法（高符号化レート→低符号化レート）を示した図である。
図１０は、従来のコンテンツ配信及びライブ配信を示したブロック図である。FIG. 1 is a block diagram showing an embodiment of a stream server according to the present invention.
FIG. 2 is a block diagram showing an example of the configuration of the cache database in the stream server according to the present invention.
FIG. 3 is a diagram showing an example of a three-stage search procedure in the stream server according to the present invention.
FIG. 4 is a flowchart showing an operation procedure at the time of negotiation of the stream server according to the present invention.
FIG. 5 is a flowchart showing an operation procedure during network monitoring of the stream server according to the present invention.
FIG. 6 is a diagram showing hit / miss determination and subsequent processing of requested content (or live) and encoding method in the stream server according to the present invention.
FIG. 7 is a diagram showing hit / miss determination such as a requested encoding rate and the subsequent processing in the stream server according to the present invention.
FIG. 8 is a diagram showing an example of changing the coding rate in the hierarchical coding in the stream server according to the present invention (low coding rate → high coding rate).
FIG. 9 is a diagram showing a coding rate changing method (high coding rate → low coding rate) in hierarchical coding in the stream server according to the present invention.
FIG. 10 is a block diagram showing conventional content distribution and live distribution.

符号の説明Explanation of symbols

Figure 2004040908
Figure 2004040908
Figure 2004040908
Figure 2004040908

図１は、本発明に係るストリーム・サーバ１００の一実施例を示している。このサーバ１００は、トランスコーダ制御／調停部１０、トランスコーダ２０＿１〜２０＿Ｌ（以下、符号２０で総称することがある。）、データベース制御／調停部３０、キャッシュ型データベース４０、ヒット／ミス判定部５０、ネットワーク監視部６０、呼制御／ネゴシエーション処理部７０、及びプロトコル実装処理部８０で構成されている。
キャッシュ型データベース４０は、コンテンツデータ又はライブデータ（以下、コンテンツデータ及びライブデータをコンテンツデータで総称することがある。）を格納するライン４３＿１〜４３＿Ｎ（以下、符号４３で総称することがある。）で構成されている。
プロトコル実装処理部８０は、ＩＰヘッダ処理部８１、ＵＤＰヘッダ処理部８２、ＲＴＰヘッダ処理部８３、ＭＰＥＧシーケンスヘッダ処理部８４、ＲＴＣＰヘッダ処理部８５、ＲＴＳＰヘッダ処理部８６で構成されている。
ヒット／ミス判定部５０は、キャッシュ型データベース４０に要求データが格納されているか否かの確認を行い、ネットワーク監視部６０はＲＴＣＰプロトコルでネットワークを監視し、呼制御／ネゴシエーション処理部７０は、ＲＴＳＰプロトコルで呼制御及びネゴシエーションを行う。
図２（５）は、図１に示した、キャッシュ型データベース４０のより詳細な構成例を示している。このデータベース４０は、タグラム（ＴＡＧ ＲＡＭ）４１、タグラム４２、及びキャッシュ４３で構成されている。
タグラム４１は、“ＭＲＵ（Ｍｏｓｔ Ｒｅｃｅｎｔｌｙ Ｕｓｅｄ）”、“コンテンヅ”、“符号化方式”、及び“タグラム４２のアドレス”のフィールドから成るタグラム４１＿１〜４１＿Ｍで構成されている。
タグラム４１は、“コンテンツ”及び“符号化方式”単位に管理され、“コンテンツ”及び“符号化方式”には、それぞれ、例えば、コンテンツ情報及びその符号化方式情報が格納される。
タグラム４１の“ＭＲＵ”には、ネゴシエーション時又はネットワーク監視（（ＲＲタイプのＲＴＣＰパケットフィードバック）時の符号化レート変更時における、視聴開始／停止／変更時刻情報等の視聴履歴情報（例えば、視聴率情報）が格納される。
タグラム４１の“タグラム４２のアドレス”には、“コンテンツ”及び“符号化方式”に対応するタグラム４２の先頭アドレスが格納される。
タグラム４２は、“ＭＲＵ”、“符号化レート”、及び“階層”のフィールドから成るタグラム４２＿１〜４２＿Ｎ（以下、符号４２で総称することがある。）で構成され、“符号化レート”単位に管理される。
タグラム４２の“ＭＲＵ”には、符号化レート変更時における、視聴開始／停止／変更時刻情報等の視聴履歴情報（視聴率情報）が格納される。
“符号化レート”、及び“階層”には、それぞれ、符号化レート情報及びその階層が格納される。
キャッシュ４３は、それぞれ、データ１〜データＸ１、…、データ１〜データＸＮから成るライン４３＿１〜４３＿Ｎ（以下、符号４３で総称することがある。）で構成されている。各ライン４３は、各データの有効／無効を示す有効フィールドをさらに含んでいる。各データ１〜Ｘ１等に格納される、コンテンツデータの管理単位はＭＰＥＧデータの場合は、ＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）である。
このライン４３＿１〜４３＿Ｎは、それぞれ、タグラム４２＿１〜４２＿Ｎに対応しており、この対応関係は、例えば、タグラム４２にライン４３の先頭アドレスを示すフィールド（図示せず）を設けて示す。
同図（２）は、同図（５）に示したタグラム４１＿１をより詳細に示しており、このタグラム４１＿１には、管理単位のコンテンツ及び符号化方式が、それぞれ「コンテンツ７１０＿１」及び「ＭＰＥＧ２」であり、そのＭＲＵが視聴履歴０１〜視聴履歴０ｘであることを示している。
さらに、タグラム４１＿１には、「コンテンツ７１０＿１」及び「ＭＰＥＧ２」に対応するタグラム４２（符号化レート）の先頭アドレスが、「０ｘ０」，「０ｘ１」，…，「０ｘｙ」であることが示されている。
同図（３）は、同図（５）に示したタグラム４２＿１，４２＿２，…のより詳細例を示している。この例では、タグラム４１＿１のタグラム４２アドレス＝“０ｘ０”で指定されたタグラム４２＿１が示されている。
このタグラム４２＿１は、符号化レート＝“１Ｍｂｐｓ”の階層が“１”であり、そのＭＲＵが視聴履歴１１〜１Ｘであることを示している。
ストリーム・サーバ１００の基本的動作として、ヒット／ミス判定部５０が、ユーザ端末からの契機〔１〕ネゴシエーション時、又は契機〔２〕ＲＲタイプのＲＴＣＰパケットフィードバック時（ネットワーク監視時）に、それぞれキャッシュ型データベース４０のヒット／ミス判定を行う。
また、ヒット／ミス判定部５０は、契機〔１〕又は〔２〕以外の契機〔３〕未使用のトランスコーダが存在し、且つ人気コンテンツがソースデータベースに新規格納され、キャッシュ型データベース４０には未格納の場合、自律的な連携動作でキャッシュ型データベース４０のヒット／ミス判定を行い、人気コンテンツの符号化データをキャッシュ型データベース４０に格納する。
これにより、例えば、人気コンテンツ配信開始時における不特定多数ユーザからの配信要求が競合した際においても、通常はキャッシュ型データベースより読み出すことができる。このように、有限数のトランスコーダ資源の有効活用ができるとともに、ユーザ端末（受信側）に対する配信サービスの即応性が実現できる。
図３は、ストリーム・サーバ１００のヒット／ミス判定部の基本的な動作手順を示している。ストリーミング技術においては、図２に示したように、例えば、コンテンツ（又はライブ）７１０＿１及び符号化方式（ＭＰＥＧ２）に対して複数の符号化レート（１Ｍｂｐｓ，５Ｍｂｐｓ，…，２０Ｍｂｐｓ）がサポートされる。
そこで、ヒット／ミス判定部５０は、キャッシュ型データベース４０のヒット／ミス判定を下記の（Ｔ１）〜（Ｔ３）の３段階で行う。
（Ｔ１）タグラム４１を検索して、要求コンテンツ又はライブ及び符号化方式が格納されているか否かを判定する（図２（１）の判定Ｔ１参照）。
（Ｔ２）次に、タグラム４２の検索を検索して、要求符号化レートが格納されているか否かを判定する（図２（１）の判定Ｔ２参照）。
（Ｔ３）最後に、キャッシュ４３の「有効（Ｖａｌｉｄ）フィールド」を検索して、要求データが格納されているか否かを判定する（図２（１）の判定Ｔ３参照）。
［１］ネゴシエーション時
図４は、本発明のストリーム・サーバ１００のネゴシエーション時（契機〔１〕）における動作手順例を示している。同図及び図１、図２を参照してネゴシエーション時における動作手順を以下に説明する。
なお、この説明においては、図１に示したソースデータベース７００に格納されているコンテンツ７１０をユーザ端末１７０が要求した場合について説明する。
ユーザ端末がライブ７２０を要求した場合も同様であるが、ライブ配信の場合、トランスコーダ２０としてエンコーダを用いることもでき、同図に示したトランスコーダ制御／調停部１０はエンコーダ制御／調停部１０になる。
図４において、破線で囲まれたステップＳ１００はヒット／ミス判定部５０のキャッシュ型データベース検索手順を示し、破線で囲まれたステップＳ２００はトランスコーダ制御／調停部１０、データベース制御／調停部３０、及びヒット／ミス判定部５０におけるトランスコーダエントリ手順を示し、破線で囲まれたステップＳ３００はプロトコル実装処理部８０のプロトコル実装処理手順を示している。
図１において、呼制御／ネゴシエーション処理部７０は、ユーザ端末１７０から呼制御／ネゴシエーション動作によりストリーム・サーバ１００とユーザ端末１７０との間のコネクションを確立する。
ステップＳ１１０〜Ｓ１３０：ヒット／ミス判定部５０は、ユーザ端末１７０が要求したコンテンツデータ、符号化方式、及び符号化レート、例えば、コンテンツ７１０＿１、ＭＰＥＧ２、及び５Ｍｂｐｓと一致するデータがキャッシュ型データベース４０に格納されているか否かを確認する。
すなわち、図２において、ヒット／ミス判定部５０は、ユーザ端末１７０から同図（１）に示した（Ｔ０）例えば、コンテンツ名＝コンテンツ７１０＿１、符号化方式＝“ＭＰＥＧ２”、及び符号化レート＝“５Ｍｂｐｓ”の要求を受ける。
なお、ネゴシエーション時には、同図（１）に示したＧＯＰ番号の要求はない。
そこで、ヒット／ミス判定部５０は、同図（２）において、タグラム４１から、コンテンツ７１０＿１及び符号化方式＝“ＭＰＥＧ２”を検索する同図（１）に示したヒット／ミス判定Ｔ１を行い、タグラム４１＿１にヒットする。
さらに、ヒット／ミス判定部５０は、タグラム４１＿１のタグラム４２アドレスフィールドに示された先頭アドレス＝０ｘ０，０ｘ１，…，０ｘｙにそれぞれ対応するタグラム４２＿１〜４２＿ｙの中から符号化レート＝“５Ｍｂｐｓ”を検索する同図（１）に示したヒット／ミス判定Ｔ２を行い、タグラム４２＿２にヒットする。
ステップＳ１８０：さらに、ヒット／ミス判定部５０は、ヒットしたタグラム４２＿２に対応するライン４３＿２のデータが有効であるか否かを判定するヒット／ミス判定Ｔ３（図２（４）参照）を行う。
符号化されたデータが有効である場合、ヒット／ミス判定部５０は、有効なデータ“１”をデータ８０２として読み出しプロトコル実装処理部８０に与える。この動作を繰り返すことにより、ライン４３＿２のデータ１〜データＸ２は、順次、プロトコル実装処理部８０に与えられることになる。
データが無効である場合、ヒット／ミス判定部５０は、トランスコーダエントリのステップＳ２１０に進む。
ステップＳ３１０〜Ｓ３４０：プロトコル実装処理部８０は、ＭＰＥＧシーケンスヘッダ、ＲＴＰヘッダ、ＵＤＰヘッダ、及びＩＰヘッダをデータ８０１に挿入した後、ＩＰネットワーク１４０を経由して、ユーザ端末１７０にライン４３＿２に格納されたコンテンツの配信を開始する（図２（１）のデータ配信Ｔ４）。
ステップＳ１４０〜Ｓ１７０：ステップＳ１１０、Ｓ１２０でミスした（データが存在しない）場合、ヒット／ミス判定部５０は、キャッシュ型データベース４０の内から、データ未格納ライン４３の検索、又は、予め設定された閾値ａより低い視聴率のコンテンツの検索、低視聴率の符号化方式の検索、低視聴率の符号化レートの検索を行う。
すなわち、ヒット／ミス判定部５０は、図２（５）において、データ未格納ライン４３を検索し、無い（ミス）場合、タグラム４１のＭＲＵの内で閾値ａより低い視聴率を示したコンテンツ／符号化方式を検索し、無い（ミス）場合、タグラム４２のＭＲＵの内で閾値ａより低い視聴率を示した符号化レートを検索する。
ステップＳ２１０：上記の検索の１つにヒットした（ヒットラインがある）場合、ヒット／ミス判定部５０は、トランスコーダ制御／調停部１０及びデータベース制御／調停部３０に対して、それぞれトランスコーダエントリ要求信号８００及び信号８０１与える。
トランスコーダ制御／調停部１０は、例えば、トランスコーダ２０＿２が未使用である場合、トランスコーダエントリ要求信号８００が示す、ユーザが要求したコンテンツ（素材又はトランスコード）７１０をソースデータベース７００からトランスコーダ２０＿２に与える。
未使用のトランスコーダが無い場合、ステップＳ２９０に進む。
ステップＳ２２０：トランスコーダ２０＿２は、コンテンツ７１０に対してリアルタイムエンコード処理したデータをデータベース制御／調停部３０に与える。データベース制御／調停部３０は、キャッシュ型データベース４０内の例えば未格納ライン（又は低視聴率ライン）４３＿１にエンコードされたデータを格納する（キャッシュフィル）。
ステップＳ２３０：ヒット／ミス判定部５０は、キャッシュフィルされたライン４３＿２からデータ８０２を読み出しプロトコル実装処理部８０に与える。
ステップＳ３１０〜Ｓ３４０：プロトコル実装処理部８０は、上記のステップＳ３１０〜Ｓ３４０と同様に、ＩＰネットワーク１４０を経由して、順次、ユーザ端末１７０に要求されたコンテンツ配信又はライブ配信を開始する。
ステップＳ２９０：上記のステップＳ１４０〜Ｓ１７０において、未格納ラインの検索、低視聴率のコンテンツの検索、低視聴率の符号化方式の検索、及び低視聴率の符号化レートの検索が全てミスの場合、又はステップＳ２１０において、未使用トランスコーダ２０が無い（トランスコーダエントリ要求に失敗した）場合、ユーザ端末１７０からのエントリ要求は失敗となる。
［２］ネットワーク監視時
図５は、ストリーム・サーバ１００が、ユーザ端末１７０に対してコンテンツ配信又はライブ配信を行っている時、ユーザ端末１７０（図１参照）からＲＲタイプＲＴＣＰパケットを受信した時の動作手順を示している。
この動作手順を、図２を参照して以下に説明する。図５においてステップＳ４００はネットワーク監視手順を示し、ステップＳ５００はキャッシュ型データベースの検索手順を示し、ステップＳ６００はトランスコーダへのエントリ手順を示し、ステップＳ８００は、プロトコル実装処理手順を示している。
ステップＳ４１０：呼制御／ネゴシエーション処理部７０は、ユーザ端末１７０から送信されたＲＲタイプのＲＴＣＰパケットを受信し、このパケットに含まれるフィードバック情報をヒット／ミス判定部５０に与える。
ＲＲタイプＲＴＣＰパケットは、ストリームを受信したユーザ端末がストリームの受信状態（パケットの廃棄率（Ｆｒａｃｔｉｏｎ Ｌｏｓｔ）、累積パケット廃棄率（Ｃｕｍｕｌａｔｉｖｅ Ｎｕｍｂｅｒ ｏｆ Ｐａｃｋｅｔ Ｌｏｓｔ）、パケット到着間のゆらぎ（Ｉｎｔｅｒａｒｒｉｖａｌ Ｊｉｔｔｅｒ））に関する情報をストリーム送信側にフィードバックするパケットである。
この情報に基づき、ヒット／ミス判定部５０は、視聴者数、視聴履歴、パケット廃棄率、累積パケット廃棄率、パケット到着間隔の揺らぎ等より、現在のネットワークの混雑度、ユーザ端末１７０の能力等を考慮した最適符号化レートを算出する。
すなわち、ヒット／ミス判定部５０は、図２（１）のＴ０、すなわち、ユーザ端末１７０に対して配信しているコンテンツ名、符号化方式、符号化レート、及びＧＯＰ番号を決定する。
ステップＳ５１０：ヒット／ミス判定部５０は、算出した最適符号化レートと一致するデータがキャッシュ型データベース４０に格納されているか否かの確認を行う。
すなわち、ヒット／ミス判定部５０は、図２（２）及び（３）において、要求されたコンテンツ及び符号化方式に対する最適な符号化レートがあるか否かのヒット／ミス判定Ｔ１，Ｔ２を行う。
ステップＳ５９０，Ｓ７１０：最適な符号化レートが存在する（ヒット）場合、ヒット／ミス判定部５０は、符号化レートに対応するラインのデータが有効か否かのヒット／ミス判定Ｔ３を行う（同図（１）参照）。
データがヒットした（有効の）場合、ヒット／ミス判定部５０は、ヒットしたライン４３から読み出したデータ８０２をプロトコル実装処理部８０に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、ＭＰＥＧシーケンスヘッダ、ＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダを挿入した最適符号化レートデータ８０２をユーザ端末１７０に、ＩＰネットワーク１４０を経由して順次配信する。これにより、前の符号化レートデータに継続して最適符号化レートデータ８０２が、ユーザ端末１７０に配信されることになる。
ステップＳ５９０，Ｓ７７０：データがミスした（無効の）場合は、キャッシュには要求する符号化レートは存在するが、対象となるデータ自体が存在しない状態を示す。
そこで、ヒット／ミス判定部５０は、信号８００及び信号８０１をそれぞれトランスコーダ制御／調停部１０及びデータベース制御／調停部３０に与える。
これらの信号８００及び信号８０１に基づき、現在使用中のトランスコーダは、要求されたコンテンツを、要求された符号化方式で要求された符号化レートのデータにエンコードし、このデータは、ステップＳ５１０でヒットしたライン４３に格納される（キャッシュフィル）。
ステップＳ７８０：ヒット／ミス判定部５０は、ヒットライン４３のデータを読み出して、プロトコル実装処理部８０に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、ＭＰＥＧシーケンスヘッダ、ＲＴＰヘッダ、ＵＤＰヘッダ、ＩＰヘッダを挿入したデータ８０２をユーザ端末１７０に、ＩＰネットワーク１４０を経由して順次配信する。
これにより、最適符号化レートのデータが、ユーザ端末１７０に配信されることになる。
ステップＳ５１０，Ｓ５２０：最適符号化レートのデータが存在しない（ミス）場合、ヒット／ミス判定部５０は、最適符号化レートに最も近い符号化データをキャッシュ型データベース４０から検索する。
すなわち、ヒット／ミス判定部５０は、図２（２）、（３）において、要求されたコンテンツ及び符号化方式に対応するタグラム４１に対応するタグラム４２の符号化レートの内で最適符号化ルートに最も近い符号化レート（比較対照符号化レート）を検索する。
ステップＳ５３０：差分絶対値ｘ＝｜最適符号化レート−比較対象符号化レート｜が予め設定された閾値ｂ以下の場合、ヒット／ミス判定部５０は、要求データが存在する（ヒット）とみなす。
ステップＳ５９０：そして、ヒット／ミス判定部５０は、ヒットとみなしたラインのデータが有効か否かのヒット／ミス判定Ｔ３を行い、有効である場合、データを読み出し、プロトコル実装処理部８０に与える。
すなわち、ヒット／ミス判定部５０は、図２（３）、（４）において、ヒットした符号化レートのタグラム４２に対応するライン４３から読み出した有効なデータ８０２をプロトコル実装処理部８０に与える。以後の動作は、上記のステップＳ８１０〜Ｓ８４０と同様である。
これにより、最適符号化レートのデータではないが、許容範囲内の符号化レートのデータ８０２が、ユーザ端末１７０に配信されることになる。
ステップＳ５４０：差分絶対値ｘが、設定された閾値ｂより大きく閾値ｃ以下である場合、ヒット／ミス判定部５０は、要求データが存在せず（図２（１）のヒット／ミス判定Ｔ１，Ｔ２におけるミス判定）且つキャッシュ型データベース４０に格納されている比較対象符号化レートのデータが不要である（ＲＲタイプのＲＴＣＰパケットによる符号化レートの変更要求がある）ため、トランスコーダ制御／調停部１０に対してトランスコーダエントリ要求信号８００を与える。
ステップＳ６１０，Ｓ６２０：トランスコーダ制御／調停部１０は、トランスコーダエントリ要求に対して、トランスコーダ２０の内に未使用トランスコーダ２０が存在する場合、素材データ又はトランスコードデータをソースとして、リアルタイムエンコード処理を行い、処理したデータをキャッシュ型データベース４０内の比較対象符号化レートライン（ミスライン）に格納する（キャッシュフィル）。
ステップＳ７２０：ヒット／ミス判定部５０は、このキャッシュフィルされたラインから読み出したデータ８０２をプロトコル実装処理部８０に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、データ８０１をＩＰネットワーク１４０を経由してユーザ端末１７０に順次配信する。
これにより、最適符号化レートとの差分絶対値が閾値ｂより大きく閾値ｃ以下の比較対象符号化レートのラインに最適符号化レートのデータをフィルすることが可能になる。このデータフィルによっても、比較対象符号化レートのラインのデータを使用するユーザ端末に対する映像及び音声への影響が少ない。
差分絶対値が設定された閾値ｃより大きい場合、比較対象データから要求データへの符号化レート変更を行うと、比較対象符号化レートのデータを使用するユーザに対する映像及び音声への影響が大きい。
そこで、ヒット／ミス判定部５０は以下の判定を行う。
ステップＳ５５０，Ｓ６３０：ヒット／ミス判定部５０は、比較対象符号化レートの差分絶対値が大きいため、キャッシュ型データベース４０の未格納ライン４３を検索し、対象となるラインが存在する（ヒット）場合、トランスコーダ制御／調停部１０に対してトランスコーダエントリ要求信号８００を与える。
ステップＳ６４０，Ｓ７３０：トランスコーダ制御／調停部１０は、トランスコーダエントリ要求に対して、未使用のトランスコーダ２０が存在する場合、素材データもしくはトランスコードデータを未使用トランスコーダ２０に与える。
このトランスコーダ２０は、与えられたデータに対してリアルタイムエンコード処理を行い、データベース制御／調停部３０を経由して未格納ライン４３に格納（キャッシュフィル）する。このフィルラインからデータ８０２が読み出されてユーザ端末に送信される。
ステップＳ５６０〜Ｓ５８０：ヒット／ミス判定部５０は、未格納ラインが無いため、キャッシュ型データベース４０から予め設定された閾値ａより低い視聴率のコンテンツ、符号化方式、又は符号化レートのライン４３を検索し、対象となるデータが存在する（ヒット）場合、トランスコーダ制御／調停部１０に対してトランスコーダエントリを要求する。
ステップＳ６５０，Ｓ６６０：トランスコーダ制御／調停部１０は、トランスコーダエントリ要求に対して、未使用のトランスコーダ２０が存在する場合、素材データもしくはトランスコードデータを未使用トランスコーダ２０に与える。
このトランスコーダ２０は、与えられたデータに対してリアルタイムエンコード処理を行いデータベース制御／調停部３０を経由してキャッシュ型データベース４０内の低視聴率ライン４３に格納する（キャッシュフィル）。
ステップＳ７４０：ヒット／ミス判定部５０は、キャッシュフィルされたライン４３からデータ８０２を読み出し、プロトコル実装処理部に与える。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、上記のヘッダを挿入したデータをユーザ端末に順次配信を継続する。
ステップＳ５８０，Ｓ６７０，Ｓ６８０，Ｓ７６０：上記キャッシュ型データベースに格納されている、未格納ライン及び閾値ａより低い視聴履歴ライン検索において、対象となるデータが存在しない場合、ヒット／ミス判定部５０はトランスコーダ制御／調停部１０に対してトランスコーダエントリ要求信号８００を与える。
未使用トランスコーダが存在する場合、素材データもしくはトランスコードデータに対してはリアルタイムエンコード処理が行われ、キャッシュ型データベース４０内の比較対象符号化レートライン４３に格納する（キャッシュフィル）。このキャッシュフィルされたライン４３から読み出されたデータがプロトコル実装処理部８０に与えられる。
ステップＳ８１０〜Ｓ８４０：プロトコル実装処理部８０は、ユーザ端末１７０に順次データ配信を継続する。
ステップＳ６１０，Ｓ６３０，Ｓ６５０，Ｓ６７０，Ｓ７５０：未使用トランスコーダ２０が存在しない場合、ＲＲタイプのＲＴＣＰパケットに基づく符号化レート変更要求は失敗となる。
ヒット／ミス判定部５０は、現在の符号化レートのデータの送信を継続し、次回符号化レート変更要求を待つ。
このようなトランスコーダ制御／調停部１０、トランスコーダ２０、データベース制御／調停部３０、キャッシュ型データベース４０、及びヒット／ミス判定部５０の連携動作により、ストリーム・サーバ１００は、ライブ配信のみならず、コンテンツ配信においても、リアルタイムにネットワーク負荷、ユーザ端末の処理能力等を考慮した、リアルタイムエンコード処理を行うことが可能になる。
また、ストリーム・サーバ１００は、低視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータを破棄することにより、高視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータのみが、キャッシュ型データベース４０に格納され続けることになる。
この結果、通常は、キャッシュ型データベース４０に格納されている高視聴率データを多くのユーザ端末に配信することができる。
すなわち、ストリーム・サーバ１００は、不特定多数ユーザに対して、それぞれ、リアルタイムのネットワーク負荷、ユーザ端末１７０の処理能力、ストリーム・サーバ１００の混雑度等を考慮した、快適なマルチキャスト型コンテンツ配信及びライブ配信が実現でき、コンテンツ及び符号化方式のみならず、符号化レートまでを範疇とした、“ワンソース・マルチユース化”を実現できる。
また、ストリーム・サーバ１００は、不特定多数ユーザに対するコンテンツ配信データ及びライブ配信データは、通常、高視聴率の符号化レートの符号化方式のコンテンツデータ及びライブデータを格納するキャッシュ型データベースより読み出すことができる（ヒットする）ため、ユーザ数分のトランスコーダを備える必要はなく、トランスコーダ数の大幅な削減が可能になる。
また、ストリーム・サーバ１００のキャッシュ型データベース４０は、常に、個人ユーザのみが視聴する低視聴率のコンテンツ及びライブは破棄され、多数のユーザが視聴する映画コンテンツ等の高視聴率コンテンツ及び高視聴率ライブのみが保存され続けるため、データベースサイズの大幅な削減が実現でき、且つストリーム・サーバ１００でのパーソナルデータベースの配信サービスも容易となる。
また、ストリーム・サーバ１００は、トランスコーダ２０の後段にキャッシュ型データベース４０を配置し、コンテンツデータ及びライブデータを一旦キャッシュ型データベース４０に格納後、ユーザに配信されるため、ライブ配信においても、ユーザ端末（受信側）からストリーム・サーバ（配信側）に対する巻戻し、一時停止要求といったコミュニケーション機能（選択性）の拡張が可能である。
すなわち、ユーザ端末（受信側）１７０は、ライブ配信とコンテンツ配信の区別することなく、サービスを享受することができ、ライブ配信とコンテンツ配信の融合が可能となる。
また、ストリーム・サーバ１００は、キャッシュ型データベース４０の後段に、ＭＰＥＧシーケンスヘッダ処理部８４を挿入することにより、シーケンスヘッダに実装されている、フレームレート及び解像度等を変更することが容易となり、ユーザ端末（受信側）任意の映像の頭出し機能、アクセス回線種別、ネットワークの混雑度、ユーザ端末の処理能力等を考慮した、最適符号化レート／解像度変更等が容易に実現できる。
このように、本発明のストリーム・サーバ１００は、トランスコーダ２０とキャッシュ型データベース４０との連携動作により、不特定多数ユーザ端末１７０に対する快適なマルチキャスト型通信によるワンソース・マルチユース化、ユーザ端末１７０とストリーム・サーバ１００間のコミュニティ環境の構築によるライブ配信とコンテンツ配信の融合、与えられた環境の中で、ストリーム・サーバ（配信側）は、リアルタイムかつ最適な制御を実現でき、ユーザ（受信側）は、より快適な配信サービスを享受できると共に、さらに大幅なハードウェア削減が可能になる。
図６は、本発明のストリーム・サーバ１００のヒット／ミス判定部５０における要求コンテンツ（又はライブ）及び符号化方式等のヒット／ミス判定法をより詳細に示している。なお、同図に示されているステップ符号は、図４のステップ符号に対応している。
〔１〕ネゴシエーション時におけるキャッシュ型データベース４０の３段階検索フローに基づくヒット／ミス判定（１）〜（５）を以下に説明する。
（１）ヒット／ミス判定部５０は、タグラム４１を検索して、要求コンテンツ（又はライブ）及び符号化方式のヒット／ミス判定Ｔ１を行う。要求データが存在する（ヒット）場合には、後述する図７の要求符号化レートのヒット／ミス判定Ｔ２へ遷移する（図４のステップＳ１１０〜Ｓ１３０参照）。
（２）要求データがタグラム４１に存在しない（ミス）場合、ヒット／ミス判定部５０は、タグラム４２の未格納ライン４３を検索し、要求データを未格納ライン４３に格納する（同ステップＳ１４０，Ｓ２１０，Ｓ２２０参照）。
（３）タグラム４２の検索において、未格納ラインが存在しない（ミス）場合、ヒット／ミス判定部５０は、低視聴率のコンテンツラインを検索し、対象となるデータが存在する（ヒット）場合、低視聴率のコンテンツラインのデータを破棄して、このラインに要求データを格納する（同ステップＳ１５０，Ｓ１６０，Ｓ２１０，Ｓ２２０参照）。
（４）タグラム４１の検索において、低視聴率のコンテンツラインが存在しない（ミス）場合、ヒット／ミス判定部５０は、タグラム４２のＭＲＵより低視聴率の符号化レートラインを検索し、対象となるデータが存在する（ヒット）場合、低視聴率の符号化レートラインのデータを破棄し、このラインに要求データを格納する（同ステップＳ１７０，Ｓ２１０，Ｓ２２０参照）。
（５）タグラム４１，４２の検索において、低視聴率のコンテンツ、及び低視聴率の符号化レートが存在しない場合、ヒット／ミス判定部５０は対象データ読み出し失敗となる（同ステップＳ１８０参照）。
〔３〕未使用トランスコーダが有る時のキャッシュ型データベース４０の自律動作によるヒット／ミス判定（６）〜（１０）を以下に説明する。この自律動作により、ソースデータベースに新規に格納された人気コンテンツが自動的にキャッシュ型データベースに格納される。（６）〜（１０）の動作は、それぞれ、上述した（１）〜（５）と同様ある。
（６）ヒット／ミス判定部５０は、要求（新規）符号化方式のコンテンツ（又はライブ）がある（ヒットした）場合、後述する図７の符号化レートのヒット／ミス判定Ｔ２に遷移する。
（７）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、且つ未格納ラインが有る場合、要求符号化方式のコンテンツ（又はライブ）を未格納ラインに追加する。
（８）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、且つ低視聴率のコンテンツが有る場合、低視聴率のコンテンツを破棄して、要求符号化方式のコンテンツ（又はライブ）を破棄した低視聴率のコンテンツラインに追加する。
（９）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、低視聴率のコンテンツが無く、且つ低視聴率の符号化レートが有る場合、低視聴率の符号化レートを破棄して、要求符号化方式のコンテンツ（又はライブ）を破棄した低視聴率の符号化レートラインに追加する。
（１０）要求符号化方式のコンテンツ（又はライブ）が無く（ミスし）、未格納ラインが無く、低視聴率のコンテンツが無く、且つ低視聴率の符号化レートが無い場合、新規コンテンツのエントリは失敗となる。
（７）〜（９）により、新規コンテンツが自律的にキャッシュ型データベースに格納されたことになる。
図７は、本発明のにおける要求符号化レートのヒット／ミス判定Ｔ２の例を示している。
この判定は冗長性をもたせている。すなわち、差分絶対値ｘ（現在配信しているキャッシュ型データベース４０に格納されている比較対象の符号化データの符号化レートと、要求データの符号化レートとの差分の絶対値ｘ）と、所定の閾値ｂ，ｃとの大小関係によって判定が異なる。
また、ネゴシエーション時とネットワーク監視（ＲＲタイプのＲＴＣＰパケットフィードバック）時とでは、判定動作が異なる。なお、同図に示されているステップ符号は、図４、図５のステップ符号に対応している。
〔１〕ネゴシエーション時における要求符号化レート等のヒット／ミス判定（１）〜（５）を以下に説明する。
（１）ヒット／ミス判定部５０は、差分絶対値ｘ≦閾値ｂである場合、要求符号化レートが存在する（ヒット）と判定し、要求符号化データに冗長を持ったヒット／ミス判定Ｔ３に遷移する。
（２）ヒット／ミス判定部５０は、閾値ｂ＜差分絶対値ｘである場合、要求符号化レートが存在しない（ミス）と判定し、タグラム４２のＭＲＵより未格納ラインを検索し未格納ラインが有る場合、要求データを未格納ラインに格納する。
（３）ヒット／ミス判定部５０は、上記の未格納ライン検索において、未格納ラインが存在しない（ミス）場合、要求符号化レートのヒット／ミス判定を強制ヒット判定し、次の要求符号化データのヒット／ミス判定Ｔ３へ遷移する。
〔３〕ネットワーク監視（ＲＲタイプのＲＴＣＰパケットフィードバック）時における要求符号化レートのヒット／ミス判定Ｔ２（４）〜（８）を以下に説明する。
（４）ヒット／ミス判定部５０は、差分絶対値ｘ≦閾値ｂである場合、要求符号化レートが存在する（みなしヒット）と判定し、要求符号化データのヒット／ミス判定Ｔ３に遷移する。
（５）ヒット／ミス判定部５０は、閾値ｂ＜差分絶対値ｘ≦閾値ｃである場合、要求符号化レートが存在しない（ミス）と判定し、比較対象符号化レートラインのデータを破棄した後、このラインに要求データを格納する。
（６）ヒット／ミス判定部５０は、閾値ｃ＜差分絶対値ｘである場合、要求符号化レートが存在しない（ミス）と判定し、タグラム４２のＭＲＵより未格納ラインを検索し未格納ラインが有り、且つ対象となるデータが存在する（ヒット）場合、要求データを未格納ラインに格納する。
（７）ヒット／ミス判定部５０は、上記の未格納ライン検索で未格納ラインが存在しない（ミス）場合、タグラム４２において、低視聴率の符号化レートラインが存在する（ヒット）場合、要求データを低視聴率の符号化レートラインに格納する。
（８）ヒット／ミス判定部５０は、上記の未格納ライン及び低視聴率の符号化レートラインが存在しない（ミス）場合、比較対象符号化レートのラインを破棄し、このラインに要求データを格納する。
なお、上記の（５）〜（８）は、使用するトランスコーダが有る場合の処理である。
また、符号化ＲＴＣＰパケット（ＲＲタイプ）フィードバックによるリアルタイムな符号化レート制御を行っているため、未使用トランスコーダ存在時における自律的な符号化レート制御（要求符号化レートのヒット／ミス判定Ｔ２）は基本的には不要である。
上記の要求符号化データのヒット／ミス判定Ｔ３に遷移した場合、ヒット／ミス判定部５０は、キャッシュ４３の検索においてヒット／ミス判定Ｔ３行い、要求データが存在する（ヒット）場合、ヒット判定し、要求データが存在しない（ミス）場合、要求データを対象インデックスに格納する。
上記のようにキャッシュ型データベース４０において、図２に示すようにタグラム４１のＭＲＵ及びタグラム４２のＭＲＵに、それぞれ、コンテンツ及び符号化方式単位並びに符号化レート単位の各ユーザの視聴開始／停止／変更時刻情報をキューイングすることにより、キャッシュ型データベースに格納されているデータに対する各ユーザの視聴開始／停止時刻、リアルタイムな視聴率を考慮したヒット／ミス判定を行うことができる。
また、上記のキャッシュ型データベース４０のヒット／ミス判定は、通常の判定契機［１］：或るユーザ端末（受信側）からの配信要求によるネゴシエーション時、通常の判定契機［２］：ＲＲタイプのＲＴＣＰパケットフィードバック時がある。さらに、ヒット／ミス判定は、判定契機［１］及び［２］以外に、未使用トランスコーダが存在する時を動作契機［３］とすることにより、ソースデータベースに新規格納され、かつキャッシュ型データベースに未格納である、人気コンテンツを事前に格納（キャッシュフィル）することができる。
また、ストリーミング技術においては、或る一つのコンテンツまたは、ライブ、符号化方式に対する、複数の符号化レートをサポートしている。
したがって、キャッシュ型データベース４０のヒット／ミス判定は、ユーザから配信要求に対して、要求コンテンツ又はライブ、符号化方式が対応するデータの検索（ヒット／ミス判定Ｔ１）を行い、次に要求符号化レートが対応するデータの検索（ヒット／ミス判定Ｔ２）を行い、最後に要求データの検索（ヒット／ミス判定Ｔ３）を行うといった３段階的な検索を行うことにより、判定の容易化／高速化が実現できるとともに、ヒット／ミス判定回路のハードウェア規模の大幅な削減が実現できる。
また、キャッシュ型データベース４０のヒット／ミス判定は、ユーザ（受信側）からの要求コンテンツ又はライブ、符号化方式、符号化レート、及び符号化データが存在しない（ミス）場合は、タグラム４１のＭＲＵ、タグラム４２のＭＲＵに格納されている視聴履歴を参照して、低視聴率のコンテンツ、符号化レートラインを破棄するため、不特定多数ユーザが要求する高視聴率のコンテンツ及び高視聴率の符号化レートのデータのみが格納され、効率的なキャッシュ運用を実現する。
また、キャッシュ型データベースのヒット／ミス判定は、ＲＲタイプのＲＴＣＰパケットによるフィードバック情報を基にしたネットワークの混雑度、ユーザ端末処理能力を考慮した最適な要求符号化レートに対する、現在使用されている符号化レートとの差分絶対値が、所定の閾値以下の場合は、冗長性をもたせたヒット／ミス判定を行うことにより、リアルタイムなネットワークの混雑度、ユーザ端末処理能力の急激な変化に追従しない。
また、所定の閾値以上の場合においても、キャッシュ型データベースに格納されているデータが、例えば全て高視聴率データの場合は、強制ヒット判定を行うことにより、他ユーザへの配信データに対して、影響を与えない。
上記の動作により、本発明のストリーム・サーバは、自律動作による自身の配信要求データ、及び他のユーザ端末へ配信データが実現できる。
図８、９は、本発明のストリーム・サーバ１００における階層化符号化方式例を示している。この階層符号化は、空間スケーラビリティ、時間スケーラビリティ、及びＳＮＲ（Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｒａｔｉｏ）スケーラビリティ等により階層化され、或る階層の符号化レートを変更する際に、符号化レート変更対象の階層及びこの階層の１つ上位の階層の符号化データのみ、新規符号化データを作成する。
図８は、低符号化レートを高符号化レートに変更する場合を示している。同図（１）において、各階層１，２，３，及び４の階層の符号化レートは、それぞれ、１Ｍｂｐｓ，５Ｍｂｐｓ、１０Ｍｂｐｓ、及び２０Ｍｂｐｓである。
同図（４）は、同図（１）に示した各階層１〜４の符号化レートが格納されているバンク９０を示しており、バンク９０＿１〜９０＿４には、それぞれ、符号化レート１Ｍｂｐｓ，５Ｍｂｐｓ，１０Ｍｂｐｓ，２０Ｍｂｐｓのデータが格納されている。
同図（２）、（５）において、階層２の符号化レートを５Ｍｂｐｓ（低符号化レート）から７Ｍｂｐｓ（高符号化レート）に変更する場合、新階層２新規符号化データ、及びこの新階層２をリファレンスとして伸長動作を行う新階層３（１０Ｍｂｐｓ）の新規符号化データを、それぞれバンク９０＿５，９０＿６に格納する。
同図（３）、（６）において、新階層３より伸長された復号フレームデータと現階層３により伸長された復号フレームデータの差分絶対値和が、或る閾値以下になった場合に、現階層２、３（バンク９０＿２，９０＿３）を破棄し、新階層２，３（バンク９０＿５，９０＿６）を現階層２，３とし、新しい階層構成に切り替える。
図９は、高符号化レートを低符号化レートに変更する場合を示している。同図（１）及び（４）は、それぞれ、図８（１）及び（４）と同様である。
図９（２）、（５）において、階層３の符号化レートを１０Ｍｂｐｓ（高符号化レート）から７Ｍｂｐｓ（低符号化レート）に変更する場合、新階層３（７Ｍｂｐｓ）、及びこの新階層３をリファレンスとして伸長動作を行う新階層４（２０Ｍｂｐｓ）の新規符号化データをバンク９０＿５，９０＿６に格納する。
同図（３）、（６）において、新階層４より伸長された復号フレームデータと現階層４により伸長された復号フレームデータの差分絶対値和が、或る閾値以下になった場合に、現階層３、４（バンク９０＿３，９０＿４）を破棄し、新階層３，４（バンク９０＿５，９０＿６）を現階層２，３とし、新しい階層構成に切り替える。
すなわち、上記階層符号化における、或る一つの階層の符号化レートを変更する場合に、この階層データをリファレンスデータとして使用する、以降の上位階層すべてのデータ変更を行うことなく、一つ上位の階層データのみの変更を行うことで、符号化レートを変更して新しい階層構成を構築することができる。
この符号化レート変更において、必要となるバンク数は、階層数＋２のみで実現でき、ハードウェア規模の削減が可能である。
以上説明したように、本発明のストリーム・サーバによれば、コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、ヒット／ミス判定部が、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するように構成したので、不特定多数ユーザ端末に対して、それぞれ与えられた環境、すなわち、ネットワーク負荷、ユーザ端末の処理能力、又はストリーム・サーバの混雑度にリアルタイムに対応したコンテンツ配信を行うこと、また、コンテンツ配信とライブ配信の融合することを、少ないハードウエアで実現することが可能になる。  FIG. 1 shows an embodiment of a stream server 100 according to the present invention. The server 100 includes a transcoder control / arbitration unit 10, transcoders 20_1 to 20_L (hereinafter, may be collectively referred to as reference numeral 20), a database control / arbitration unit 30, a cache database 40, and a hit / miss determination unit 50. , A network monitoring unit 60, a call control / negotiation processing unit 70, and a protocol implementation processing unit 80.
  The cache-type database 40 stores content data or live data (hereinafter, content data and live data may be collectively referred to as content data) 43_1 to 43_N (hereinafter, may be collectively referred to as reference numeral 43). It consists of
  The protocol implementation processing unit 80 includes an IP header processing unit 81, a UDP header processing unit 82, an RTP header processing unit 83, an MPEG sequence header processing unit 84, an RTCP header processing unit 85, and an RTSP header processing unit 86.
  The hit / miss determination unit 50 checks whether or not the request data is stored in the cache database 40, the network monitoring unit 60 monitors the network using the RTCP protocol, and the call control / negotiation processing unit 70 Call control and negotiation are performed using the protocol.
  FIG. 2 (5) shows a more detailed configuration example of the cache database 40 shown in FIG. The database 40 includes a taggram (TAG RAM) 41, a taggram 42, and a cache 43.
  The taggram 41 is composed of tagograms 41_1 to 41_M including fields of “MRU (Most Recently Used)”, “content”, “encoding scheme”, and “address of taggram 42”.
  The taggram 41 is managed in units of “content” and “encoding scheme”, and content information and encoding scheme information thereof are stored in the “content” and “encoding scheme”, respectively.
  “MRU” of the taggram 41 includes viewing history information (for example, viewing rate) such as viewing start / stop / change time information at the time of negotiation or when changing the encoding rate during network monitoring ((RR type RTCP packet feedback)). Information) is stored.
  In the “address of taggram 42” of the taggram 41, the head address of the taggram 42 corresponding to “content” and “encoding method” is stored.
  The taggram 42 is composed of taggrams 42_1 to 42_N (hereinafter, may be collectively referred to as reference numeral 42) composed of fields of “MRU”, “encoding rate”, and “hierarchy”, and is in units of “encoding rate”. Managed.
  “MRU” of the taggram 42 stores viewing history information (viewing rate information) such as viewing start / stop / change time information when the coding rate is changed.
  “Encoding rate” and “hierarchy” store encoding rate information and its hierarchy, respectively.
  The cache 43 is composed of lines 43_1 to 43_N (hereinafter may be collectively referred to as reference numeral 43) each including data 1 to data X1,..., Data 1 to data XN. Each line 43 further includes a valid field indicating valid / invalid of each data. In the case of MPEG data, the management unit of content data stored in each data 1 to X1 is GOP (Group Of Picture).
  The lines 43_1 to 43_N correspond to the tagograms 42_1 to 42_N, respectively. This correspondence relationship is shown by providing a field (not shown) indicating the head address of the line 43 in the taggram 42, for example.
  FIG. 2B shows in more detail the taggram 41_1 shown in FIG. 5B. In this taggram 41_1, the content of the management unit and the encoding method are “content 710_1” and “MPEG2”, respectively. The MRU is viewing history 01 to viewing history 0x.
  Further, the taggram 41_1 indicates that the head address of the taggram 42 (encoding rate) corresponding to “content 710_1” and “MPEG2” is “0x0”, “0x1”,..., “0xy”. Yes.
  FIG. 3 (3) shows a more detailed example of the tags 42_1, 42_2,... Shown in FIG. In this example, the taggram 42_1 designated by the taggram 42 address = “0x0” of the taggram 41_1 is shown.
  This taggram 42_1 indicates that the hierarchy of the coding rate = “1 Mbps” is “1” and that the MRU is the viewing history 11 to 1X.
  As a basic operation of the stream server 100, the hit / miss determination unit 50 caches each time when an opportunity [1] is negotiated from a user terminal or when an [2] RR type RTCP packet is fed back (at the time of network monitoring). The hit / miss determination of the type database 40 is performed.
  In addition, the hit / miss determination unit 50 has an opportunity [3] other than opportunity [1] or [2] [3] unused transcoders exist, and popular content is newly stored in the source database. When not stored, the hit / miss determination of the cache database 40 is performed by an autonomous cooperative operation, and the encoded data of the popular content is stored in the cache database 40.
  Thereby, for example, even when a distribution request from an unspecified number of users at the start of popular content distribution competes, it can usually be read from a cache database. In this way, a finite number of transcoder resources can be effectively used, and the responsiveness of the distribution service to the user terminal (receiving side) can be realized.
  FIG. 3 shows a basic operation procedure of the hit / miss determination unit of the stream server 100. In the streaming technology, as shown in FIG. 2, for example, a plurality of encoding rates (1 Mbps, 5 Mbps,..., 20 Mbps) are supported for the content (or live) 710_1 and the encoding method (MPEG2).
  Therefore, the hit / miss determination unit 50 performs hit / miss determination of the cache database 40 in the following three stages (T1) to (T3).
(T1) The taggram 41 is searched to determine whether the requested content or the live and encoding method is stored (see determination T1 in FIG. 2 (1)).
(T2) Next, the search for the taggram 42 is searched to determine whether or not the requested encoding rate is stored (see determination T2 in FIG. 2 (1)).
(T3) Finally, the “valid field” in the cache 43 is searched to determine whether or not the request data is stored (see determination T3 in FIG. 2A).
[1] During negotiation
  FIG. 4 shows an example of an operation procedure when the stream server 100 of the present invention is negotiated (trigger [1]). The operation procedure at the time of negotiation will be described below with reference to FIG.
  In this description, a case where the user terminal 170 requests the content 710 stored in the source database 700 shown in FIG. 1 will be described.
  The same applies when the user terminal requests live 720, but in the case of live distribution, an encoder may be used as the transcoder 20, and the transcoder control / arbiter 10 shown in FIG. become.
  In FIG. 4, step S100 surrounded by a broken line indicates a cache type database search procedure of the hit / miss determination unit 50, and step S200 surrounded by a broken line indicates the transcoder control / arbitration unit 10, the database control / arbitration unit 30, The transcoder entry procedure in the hit / miss determination unit 50 is shown, and step S300 surrounded by a broken line shows the protocol implementation processing procedure of the protocol implementation processing unit 80.
  In FIG. 1, a call control / negotiation processing unit 70 establishes a connection between the stream server 100 and the user terminal 170 by a call control / negotiation operation from the user terminal 170.
Steps S110 to S130: Whether the hit / miss determination unit 50 stores in the cache database 40 data that matches the content data, encoding method, and encoding rate requested by the user terminal 170, for example, the content 710_1, MPEG2, and 5 Mbps. Confirm whether or not.
  That is, in FIG. 2, the hit / miss determination unit 50 receives (T0), for example, content name = content 710_1, encoding method = “MPEG2”, and encoding rate = from the user terminal 170 shown in FIG. A request of “5 Mbps” is received.
  At the time of negotiation, there is no request for the GOP number shown in FIG.
  Therefore, the hit / miss determination unit 50 performs the hit / miss determination T1 shown in FIG. 1A to search the content 710_1 and the encoding method = “MPEG2” from the tag 41 in FIG. Hit the taggram 41_1.
  Further, the hit / miss determination unit 50 sets the encoding rate = “5 Mbps” from the tags 42_1 to 42_y corresponding to the top addresses = 0x0, 0x1,..., 0xy indicated in the taggram 42 address field of the taggram 41_1. The hit / miss determination T2 shown in FIG. 1A to be searched is performed, and the tag 42_2 is hit.
Step S180Further, the hit / miss determination unit 50 performs a hit / miss determination T3 (see FIG. 2 (4)) for determining whether or not the data of the line 43_2 corresponding to the hit tag 42_2 is valid.
  When the encoded data is valid, the hit / miss determination unit 50 reads the valid data “1” as data 802 and gives it to the protocol implementation processing unit 80. By repeating this operation, data 1 to data X2 of the line 43_2 are sequentially given to the protocol implementation processing unit 80.
  If the data is invalid, the hit / miss determination unit 50 proceeds to step S210 of the transcoder entry.
Steps S310 to S340The protocol implementation processing unit 80 inserts the MPEG sequence header, RTP header, UDP header, and IP header into the data 801, and then distributes the content stored in the line 43_2 to the user terminal 170 via the IP network 140. Is started (data distribution T4 in FIG. 2 (1)).
Steps S140 to S170: When a miss is made in step S110 or S120 (data does not exist), the hit / miss determination unit 50 searches the data unstored line 43 from the cache database 40 or is lower than a preset threshold value a. Search for contents with audience rating, search for encoding method with low audience rating, and search for encoding rate with low audience rating.
  That is, the hit / miss determination unit 50 searches the data unstored line 43 in FIG. 2 (5), and if there is no (miss), the content / showing the audience rating lower than the threshold value a in the MRU of the taggram 41. When the encoding method is searched and there is no (miss), the encoding rate indicating the audience rating lower than the threshold value a is searched for in the MRU of the taggram 42.
Step S210When one of the above searches is hit (there is a hit line), the hit / miss determination unit 50 sends a transcoder entry request signal to the transcoder control / arbitration unit 10 and the database control / arbitration unit 30, respectively. 800 and signal 801 are provided.
  For example, when the transcoder 20_2 is not used, the transcoder control / arbiter 10 transmits the content (material or transcode) 710 requested by the user indicated by the transcoder entry request signal 800 from the source database 700 to the transcoder 20_2. To give.
  If there is no unused transcoder, the process proceeds to step S290.
Step S220: The transcoder 20_2 gives the data real-time encoded with respect to the content 710 to the database control / arbiter 30. The database control / arbiter 30 stores the encoded data in, for example, an unstored line (or low audience rating line) 43_1 in the cache database 40 (cache fill).
Step S230: The hit / miss determination unit 50 reads the data 802 from the cache-filled line 43_2 and gives it to the protocol implementation processing unit 80.
Steps S310 to S340The protocol implementation processing unit 80 sequentially starts content distribution or live distribution requested to the user terminal 170 via the IP network 140 in the same manner as steps S310 to S340 described above.
Step S290: In the above-described steps S140 to S170, when the search for the unstored line, the search for the content with a low audience rating, the search for the encoding method with the low audience rating, and the search for the encoding rate with the low audience rating are all mistakes, or In step S210, if there is no unused transcoder 20 (transcoder entry request failed), the entry request from the user terminal 170 fails.
[2] During network monitoring
  FIG. 5 shows an operation procedure when the stream server 100 receives an RR type RTCP packet from the user terminal 170 (see FIG. 1) while performing content distribution or live distribution to the user terminal 170. Yes.
  This operation procedure will be described below with reference to FIG. In FIG. 5, step S400 shows a network monitoring procedure, step S500 shows a cache type database search procedure, step S600 shows a procedure for entry into a transcoder, and step S800 shows a protocol implementation processing procedure.
Step S410The call control / negotiation processing unit 70 receives the RR type RTCP packet transmitted from the user terminal 170, and provides the hit / miss determination unit 50 with the feedback information included in this packet.
  The RR type RTCP packet is related to the reception state of the stream (the packet discard rate (Fraction Lost), the cumulative packet discard rate (Cumulative Number of Packet Loss), and the fluctuation between the arrivals of the packet (International Jitter)). This packet feeds back information to the stream transmission side.
  Based on this information, the hit / miss determination unit 50 determines the current network congestion level, the capability of the user terminal 170, etc. from the number of viewers, viewing history, packet discard rate, cumulative packet discard rate, fluctuation of packet arrival interval, and the like. The optimum encoding rate is calculated in consideration of
  That is, the hit / miss determination unit 50 determines T0 in FIG. 2A, that is, the content name, the encoding method, the encoding rate, and the GOP number distributed to the user terminal 170.
Step S510: The hit / miss determination unit 50 checks whether or not data matching the calculated optimal encoding rate is stored in the cache database 40.
  That is, the hit / miss determination unit 50 performs hit / miss determinations T1 and T2 as to whether or not there is an optimum encoding rate for the requested content and encoding method in FIGS. .
Steps S590 and S710: When the optimum encoding rate exists (hit), the hit / miss determination unit 50 performs a hit / miss determination T3 as to whether or not the data of the line corresponding to the encoding rate is valid ((1) in the figure). reference).
  When the data is hit (valid), the hit / miss determination unit 50 gives the data 802 read from the hit line 43 to the protocol implementation processing unit 80.
Steps S810 to S840The protocol implementation processing unit 80 sequentially distributes the optimum coding rate data 802 with the MPEG sequence header, RTP header, UDP header, and IP header inserted to the user terminal 170 via the IP network 140. As a result, the optimum coding rate data 802 is delivered to the user terminal 170 following the previous coding rate data.
Steps S590 and S770: When data is missed (invalid), it indicates that the requested encoding rate exists in the cache but the target data itself does not exist.
  Therefore, the hit / miss determination unit 50 provides the signal 800 and the signal 801 to the transcoder control / arbitration unit 10 and the database control / arbitration unit 30, respectively.
  Based on these signals 800 and 801, the currently used transcoder encodes the requested content into data of the requested encoding rate in the requested encoding scheme, and this data is received in step S510. Stored in the hit line 43 (cache fill).
Step S780: The hit / miss determination unit 50 reads the data of the hit line 43 and gives it to the protocol implementation processing unit 80.
Steps S810 to S840The protocol implementation processing unit 80 sequentially distributes the data 802 with the MPEG sequence header, the RTP header, the UDP header, and the IP header inserted to the user terminal 170 via the IP network 140.
  Thereby, the data of the optimal encoding rate is distributed to the user terminal 170.
Steps S510 and S520When the data of the optimal encoding rate does not exist (miss), the hit / miss determination unit 50 searches the cache type database 40 for the encoded data closest to the optimal encoding rate.
  That is, the hit / miss determination unit 50 in FIGS. 2 (2) and 2 (3), the optimum encoding route within the encoding rate of the tag 42 corresponding to the tag 41 corresponding to the requested content and encoding method. The closest encoding rate (comparison encoding rate) is searched.
Step S530: Absolute difference x = | optimal coding rate−comparison target coding rate | is equal to or smaller than a preset threshold value b, the hit / miss determination unit 50 considers that the requested data exists (hit).
Step S590Then, the hit / miss determination unit 50 performs a hit / miss determination T3 as to whether or not the data of the line regarded as a hit is valid, and if it is valid, reads the data and gives it to the protocol implementation processing unit 80.
  That is, the hit / miss determination unit 50 provides the protocol implementation processing unit 80 with the valid data 802 read from the line 43 corresponding to the tag rate 42 of the hit coding rate in FIGS. 2 (3) and 2 (4). Subsequent operations are the same as steps S810 to S840 described above.
  Thereby, the data 802 having the coding rate within the allowable range, but not the data of the optimum coding rate, is distributed to the user terminal 170.
Step S540When the difference absolute value x is larger than the set threshold value b and equal to or less than the threshold value c, the hit / miss determination unit 50 does not have the request data (in the hit / miss determinations T1 and T2 in FIG. 2 (1)). Since the data of the comparison target encoding rate stored in the cache database 40 is unnecessary (there is a request for changing the encoding rate by the RR type RTCP packet), the transcoder control / arbitration unit 10 For this, a transcoder entry request signal 800 is given.
Steps S610 and S620: In response to the transcoder entry request, the transcoder control / arbiter 10 performs real-time encoding processing using raw data or transcoded data as a source when there is an unused transcoder 20 in the transcoder 20. The processed data is stored in the comparison target encoding rate line (miss line) in the cache database 40 (cache fill).
Step S720: The hit / miss determination unit 50 gives the data 802 read from the cache-filled line to the protocol implementation processing unit 80.
Steps S810 to S840The protocol implementation processing unit 80 sequentially distributes the data 801 to the user terminal 170 via the IP network 140.
  As a result, it is possible to fill the data of the optimum coding rate on the comparison coding rate line whose difference absolute value from the optimum coding rate is larger than the threshold value b and equal to or less than the threshold value c. This data fill also has little influence on the video and audio on the user terminal that uses the data of the comparison target coding rate line.
  When the difference absolute value is larger than the set threshold value c, if the coding rate change from the comparison target data to the request data is performed, the influence on the video and audio for the user who uses the data of the comparison target coding rate is large.
  Therefore, the hit / miss determination unit 50 performs the following determination.
Steps S550 and S630: Since the difference absolute value of the comparison target encoding rate is large, the hit / miss determination unit 50 searches the unstored line 43 of the cache database 40, and if the target line exists (hit), the transcoder control / The transcoder entry request signal 800 is given to the arbitration unit 10.
Steps S640 and S730The transcoder control / arbiter 10 gives the raw data or transcode data to the unused transcoder 20 when there is an unused transcoder 20 in response to the transcoder entry request.
  The transcoder 20 performs real-time encoding processing on the given data, and stores (cache fill) in the unstored line 43 via the database control / arbiter 30. Data 802 is read from this fill line and transmitted to the user terminal.
Steps S560 to S580: Since there is no unstored line, the hit / miss determination unit 50 searches the cache-type database 40 for content 43 with a rating lower than the preset threshold value a, the encoding method, or the encoding rate line 43, and the target When there is data to become (hit), the transcoder control / arbiter 10 is requested to make a transcoder entry.
Steps S650 and S660The transcoder control / arbiter 10 gives the raw data or transcode data to the unused transcoder 20 when there is an unused transcoder 20 in response to the transcoder entry request.
  The transcoder 20 performs real-time encoding processing on the given data and stores it in the low audience rating line 43 in the cache database 40 via the database control / arbiter 30 (cache fill).
Step S740: The hit / miss determination unit 50 reads the data 802 from the cache-filled line 43 and gives it to the protocol implementation processing unit.
Steps S810 to S840The protocol implementation processing unit 80 continues to sequentially distribute the data in which the header is inserted to the user terminal.
Steps S580, S670, S680, S760: In the search of unstored lines and viewing history lines lower than the threshold value a stored in the cache type database, when there is no target data, the hit / miss determination unit 50 determines whether or not the transcoder control / arbitration unit 10 Then, a transcoder entry request signal 800 is given.
  When there is an unused transcoder, real-time encoding processing is performed on the material data or transcoded data, and the data is stored in the comparison target coding rate line 43 in the cache database 40 (cache fill). Data read from the cache-filled line 43 is given to the protocol implementation processing unit 80.
Steps S810 to S840The protocol implementation processing unit 80 continues data distribution to the user terminal 170 sequentially.
Steps S610, S630, S650, S670, S750: When there is no unused transcoder 20, the encoding rate change request based on the RR type RTCP packet fails.
  The hit / miss determination unit 50 continues to transmit data at the current encoding rate and waits for a next encoding rate change request.
  By such cooperative operation of the transcoder control / arbitration unit 10, the transcoder 20, the database control / arbitration unit 30, the cache database 40, and the hit / miss determination unit 50, the stream server 100 can perform not only live distribution. Even in content distribution, real-time encoding processing can be performed in consideration of network load, processing capability of the user terminal, and the like in real time.
  In addition, the stream server 100 discards the content data and live data of the encoding method of the low audience rating encoding rate, so that only the content data and live data of the encoding method of the encoding rate of the high audience rating are stored. The data is continuously stored in the cache database 40.
  As a result, normally, the high audience rating data stored in the cache database 40 can be distributed to many user terminals.
  That is, the stream server 100 provides a comfortable multicast type content distribution and live performance to unspecified large number of users in consideration of the real-time network load, the processing capability of the user terminal 170, the congestion degree of the stream server 100, and the like. Distribution can be realized, and “one-source multi-use” can be realized not only for contents and encoding methods but also for encoding rates.
  Further, the stream server 100 reads content distribution data and live distribution data for an unspecified number of users from a cache database that normally stores content data and live data of an encoding method with an encoding rate of high audience rating. Therefore, it is not necessary to provide as many transcoders as the number of users, and the number of transcoders can be greatly reduced.
  Also, the cache database 40 of the stream server 100 always discards low-viewing content and live content that are viewed only by individual users, and high-viewing content and high-viewing rate such as movie content that many users view. Since only live data is continuously stored, the database size can be significantly reduced, and the distribution service of the personal database in the stream server 100 can be facilitated.
  In addition, since the stream server 100 arranges the cache database 40 after the transcoder 20, stores the content data and live data in the cache database 40, and then distributes them to the user. Communication functions (selectivity) such as rewinding from the terminal (receiving side) to the stream server (distributing side) and a pause request can be expanded.
  That is, the user terminal (reception side) 170 can enjoy the service without distinguishing between live distribution and content distribution, and fusion of live distribution and content distribution is possible.
  In addition, the stream server 100 can easily change the frame rate, resolution, and the like implemented in the sequence header by inserting the MPEG sequence header processing unit 84 in the subsequent stage of the cache database 40, and the user can change the frame rate and resolution. It is possible to easily realize an optimal coding rate / resolution change and the like taking into account the video search function of the terminal (reception side), the type of access line, the degree of network congestion, the processing capability of the user terminal, and the like.
  As described above, the stream server 100 according to the present invention is configured to be one-source multi-use by the comfortable multicast type communication to the unspecified number of user terminals 170 by the cooperative operation of the transcoder 20 and the cache type database 40, and the user terminal 170. Fusion of live distribution and content distribution by building a community environment between the server and the stream server 100. In the given environment, the stream server (distribution side) can realize real-time and optimal control, and the user (reception side) ) Can enjoy a more comfortable distribution service and can further reduce hardware.
  FIG. 6 shows the hit / miss determination method such as the requested content (or live) and encoding method in the hit / miss determination unit 50 of the stream server 100 of the present invention in more detail. In addition, the step code | symbol shown by the figure respond | corresponds to the step code | symbol of FIG.
  [1] Hit / miss determinations (1) to (5) based on the three-stage search flow of the cache type database 40 at the time of negotiation will be described below.
(1) The hit / miss determination unit 50 searches the taggram 41 and performs hit / miss determination T1 for the requested content (or live) and the encoding method. If the request data exists (hit), the process shifts to a hit / miss determination T2 of the request coding rate shown in FIG. 7 (see steps S110 to S130 in FIG. 4).
(2) If the request data does not exist in the taggram 41 (miss), the hit / miss determination unit 50 searches the unstored line 43 of the taggram 42 and stores the request data in the unstored line 43 (step S140, step S140). (See S210 and S220).
(3) In the search of the taggram 42, when there is no unstored line (miss), the hit / miss determination unit 50 searches for a content line with a low audience rating, and when target data exists (hit), The data of the low audience rating content line is discarded, and the request data is stored in this line (see steps S150, S160, S210, and S220).
(4) In the search for the taggram 41, if there is no content line with a low audience rating (miss), the hit / miss determination unit 50 searches for an encoding rate line with a lower audience rating than the MRU of the taggram 42, Is present (hit), the coding rate line data with a low audience rating is discarded, and the request data is stored in this line (see steps S170, S210, and S220).
(5) In the search of the taggrams 41 and 42, if there is no content with a low audience rating and an encoding rate with a low audience rating, the hit / miss determination unit 50 fails to read the target data (see step S180).
  [3] Hit / miss determinations (6) to (10) by autonomous operation of the cache database 40 when there is an unused transcoder will be described below. Due to this autonomous operation, popular content newly stored in the source database is automatically stored in the cache database. The operations (6) to (10) are the same as (1) to (5) described above.
(6) When there is a content (or live) of the requested (new) encoding method (hit), the hit / miss determination unit 50 transitions to an encoding rate hit / miss determination T2 in FIG.
(7) When there is no request coding content (or live) (miss) and there is an unstored line, the request coding content (or live) is added to the unstored line.
(8) When there is no content (or live) in the required encoding system (miss), there is no unstored line, and there is content with a low audience rating, the content with the low audience rating is discarded, and the requested encoding system Is added to the content line with a low audience rating.
(9) When there is no content (or live) in the required encoding method (miss), there is no unstored line, there is no content with a low audience rating, and there is an encoding rate with a low audience rating, The coding rate is discarded, and the requested coding method content (or live) is added to the discarded low coding rate coding rate line.
(10) If there is no content (or live) in the required encoding system (miss), there is no unstored line, no content with a low audience rating, and no encoding rate with a low audience rating, entry of a new content Fails.
  From (7) to (9), the new content is autonomously stored in the cache database.
  FIG. 7 shows an example of the requested coding rate hit / miss determination T2 in the present invention.
  This determination is redundant. That is, the absolute difference value x (the absolute value x of the difference between the encoding rate of the encoded data to be compared and the encoding rate of the request data stored in the currently distributed cache database 40), and a predetermined value The determination differs depending on the magnitude relationship with the threshold values b and c.
  Also, the determination operation differs between the time of negotiation and the time of network monitoring (RR type RTCP packet feedback). In addition, the step code | symbol shown in the figure respond | corresponds to the step code | symbol of FIG. 4, FIG.
  [1] Hit / miss determination (1) to (5) such as a required encoding rate at the time of negotiation will be described below.
(1) When the difference absolute value x ≦ threshold value b, the hit / miss determination unit 50 determines that the requested encoding rate exists (hit), and the hit / miss determination T3 has redundancy in the requested encoded data. Transition to.
(2) If the threshold value b <difference absolute value x, the hit / miss determination unit 50 determines that the requested encoding rate does not exist (miss), searches for an unstored line from the MRU in the tag 42, and stores the unstored line. If there is, the request data is stored in the unstored line.
(3) In the above-described unstored line search, if there is no unstored line (miss), the hit / miss determination unit 50 determines the hit / miss determination of the request encoding rate to determine the next request encoding. Transition to data hit / miss determination T3.
  [3] Request coding rate hit / miss determinations T2 (4) to (8) during network monitoring (RR type RTCP packet feedback) will be described below.
(4) When the difference absolute value x ≦ the threshold value b, the hit / miss determination unit 50 determines that the requested encoding rate exists (deemed hit), and transitions to the requested encoded data hit / miss determination T3. .
(5) If threshold value b <difference absolute value x ≦ threshold value c, hit / miss determination unit 50 determines that the requested encoding rate does not exist (miss), and discards the data of the comparison target encoding rate line Thereafter, the request data is stored in this line.
(6) When the threshold value c <difference absolute value x, the hit / miss determination unit 50 determines that the requested encoding rate does not exist (miss), searches for an unstored line from the MRU in the tag 42, and stores the unstored line. If the target data exists (hit), the request data is stored in the unstored line.
(7) The hit / miss determination unit 50 requests when an unstored line does not exist in the above-described unstored line search (miss), and an encoded rate line with a low audience rating exists in the tag 42 (hit). Store the data in the low audience rating coding rate line.
(8) When the above-mentioned unstored line and the low rating rating encoding rate line do not exist (miss), the hit / miss determination unit 50 discards the comparison target encoding rate line and puts the requested data in this line. Store.
  In addition, said (5)-(8) is a process in case there exists the transcoder to be used.
  Also, since real-time coding rate control is performed by means of coded RTCP packet (RR type) feedback, autonomous coding rate control when there is an unused transcoder (request coding rate hit / miss determination T2). Is basically unnecessary.
  When the transition to the request encoded data hit / miss determination T3 is made, the hit / miss determination unit 50 performs the hit / miss determination T3 in the search of the cache 43, and when the request data exists (hit), determines the hit. If the request data does not exist (miss), the request data is stored in the target index.
  As described above, in the cache-type database 40, as shown in FIG. 2, the viewing start / stop / change of each user in the content, coding method unit, and coding rate unit is added to the MRU of the taggram 41 and the MRU of the taggram 42, respectively. By queuing the time information, it is possible to perform hit / miss determination in consideration of each user's viewing start / stop time and real-time viewing rate for the data stored in the cache database.
  Further, the hit / miss determination of the cache database 40 is based on normal determination trigger [1]: normal determination trigger [2]: RR type at the time of negotiation by a delivery request from a certain user terminal (reception side). There is an RTCP packet feedback time. Further, the hit / miss determination is newly stored in the source database by using an operation timing [3] when there is an unused transcoder in addition to the determination triggers [1] and [2]. It is possible to store (cache fill) popular content that is not yet stored in
  In addition, the streaming technology supports a plurality of encoding rates for a certain content, live, or encoding scheme.
  Therefore, the hit / miss determination of the cache database 40 is performed by searching for the requested content or data corresponding to the live or encoding method (hit / miss determination T1) in response to the distribution request from the user, and then request encoding. Searching data corresponding to the rate (hit / miss determination T2) and finally request data (hit / miss determination T3) are performed in three stages, thereby facilitating / accelerating the determination. In addition, the hardware scale of the hit / miss determination circuit can be greatly reduced.
  Further, the hit / miss determination of the cache database 40 is performed when the requested content or live from the user (reception side), the encoding method, the encoding rate, and the encoded data do not exist (miss), and the MRU of the tag 41 , Referring to the viewing history stored in the MRU of the taggram 42, the content with low audience rating and the coding rate line are discarded, so the content with high audience rating and the code with high audience rating requested by an unspecified number of users Only the data of the conversion rate is stored, and efficient cache operation is realized.
  In addition, the hit / miss determination of the cache type database is performed based on the currently used code for the optimum requested coding rate in consideration of the congestion degree of the network and the user terminal processing capability based on the feedback information by the RR type RTCP packet. If the absolute value of the difference from the conversion rate is equal to or less than a predetermined threshold value, the hit / miss determination with redundancy is performed, so that the real-time network congestion level and the rapid change in the user terminal processing capability are not followed.
  In addition, even when the data stored in the cache type database is all high audience rating data, for example, if the data stored in the cache database is equal to or greater than the predetermined threshold, by performing forced hit determination, Does not affect.
  By the above operation, the stream server of the present invention can realize the distribution request data of its own by autonomous operation and the distribution data to other user terminals.
  8 and 9 show an example of the layered encoding method in the stream server 100 of the present invention. This hierarchical coding is hierarchized by spatial scalability, temporal scalability, SNR (Signal to Noise Ratio) scalability, etc., and when changing the coding rate of a certain layer, the layer of the coding rate change target and this layer New encoded data is created only for the encoded data of the next higher level.
  FIG. 8 shows a case where the low coding rate is changed to the high coding rate. In FIG. 1A, the encoding rates of the layers 1, 2, 3, and 4 are 1 Mbps, 5 Mbps, 10 Mbps, and 20 Mbps, respectively.
  FIG. 4 (4) shows a bank 90 in which the coding rates of the respective layers 1 to 4 shown in FIG. 1 (1) are stored. The banks 90_1 to 90_4 each have a coding rate of 1 Mbps, Data of 5 Mbps, 10 Mbps, and 20 Mbps are stored.
  When changing the encoding rate of layer 2 from 5 Mbps (low encoding rate) to 7 Mbps (high encoding rate) in FIGS. 2 (2) and (5), new layer 2 newly encoded data and the new layer The new encoded data of the new hierarchy 3 (10 Mbps) that performs the decompression operation with reference to 2 is stored in the banks 90_5 and 90_6, respectively.
  In (3) and (6) in the figure, when the sum of absolute differences between the decoded frame data expanded from the new layer 3 and the decoded frame data expanded from the current layer 3 is below a certain threshold, The hierarchies 2 and 3 (banks 90_2 and 90_3) are discarded, the new hierarchies 2 and 3 (banks 90_5 and 90_6) are changed to the current hierarchies 2 and 3, and the new hierarchies are switched.
  FIG. 9 shows a case where the high encoding rate is changed to the low encoding rate. (1) and (4) are the same as FIGS. 8 (1) and (4), respectively.
  9 (2) and (5), when the encoding rate of layer 3 is changed from 10 Mbps (high encoding rate) to 7 Mbps (low encoding rate), new layer 3 (7 Mbps) and this new layer 3 Are stored in the banks 90_5 and 90_6 as new reference data of the new hierarchy 4 (20 Mbps) that performs the decompression operation.
  In (3) and (6) in the figure, when the sum of absolute differences between the decoded frame data expanded from the new layer 4 and the decoded frame data expanded from the current layer 4 is below a certain threshold, The hierarchies 3 and 4 (banks 90_3 and 90_4) are discarded, the new hierarchies 3 and 4 (banks 90_5 and 90_6) are changed to the current hierarchies 2 and 3, and a new hierarchical structure is switched.
  That is, when changing the coding rate of a certain layer in the above-mentioned layered coding, this layer data is used as reference data, without changing the data of all the subsequent upper layers, one higher layer. By changing only the hierarchical data, it is possible to change the encoding rate and construct a new hierarchical structure.
  In this coding rate change, the required number of banks can be realized only by the number of layers +2, and the hardware scale can be reduced.
  As described above, according to the stream server of the present invention, when the requested data regarding the content or live, the encoding method, and the encoding rate is not stored in the cache database, the hit / miss determination unit Are configured to control the transcoder and the cache database so that the requested data is stored in the cache database, respectively. Realizes content distribution that corresponds to the real-time environment, that is, network load, user terminal processing capacity, or stream server congestion, and also integrates content distribution and live distribution with less hardware It becomes possible to do.

【特許請求の範囲】
【請求項１】１つ以上のトランスコーダと、
データを格納するキャッシュ型データベースと、
コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット/ミス判定部と、
を備えたことを特徴とするストリーム・サーバ。
【請求項２】請求項１において、
ユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻し制御に関するネゴシエーションを行い、その結果を該ヒット/ミス判定部に通知する呼制御/ネゴシエーション処理部をさらに有し、
該ヒット/ミス判定部が、該結果に基づき該トランスコーダ及び該キャッシュ型データベースに対する連携制御を行うことを特徴とするストリーム・サーバ。
【請求項３】請求項１において、
さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット/ミス判定部に与えるネットワーク監視部を有し、
該ヒット/ミス判定部が該監視結果に基づき最適符号化レートを決定することを特徴としたストリーム・サーバ。
【請求項４】請求項１において、
該ヒット/ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されているか否かの判定に、該符号化レートが許容範囲に入っている否かを判定することを特徴としたストリーム・サーバ。
【請求項５】請求項３において、
該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納し、
該ヒット/ミス判定部が、該情報に基づきヒット/ミス判定を行うことを特徴としたストリーム・サーバ。
【請求項６】請求項１において、
該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はSNRスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることを特徴とするストリーム・サーバ。 [Claims]
1. One or more transcoders;
A cache database that stores data;
When the requested data regarding content or live, encoding scheme, and encoding rate is not stored in the cache type database, the transcoder and the A hit / miss determination unit that controls a cache-type database in cooperation,
A stream server characterized by comprising:
2. In claim 1,
A call control / negotiation processing unit that negotiates call control or data distribution start control, pause control, or rewind control with a user terminal and notifies the hit / miss determination unit of the result. Further comprising
The stream server, wherein the hit / miss determination unit performs cooperative control on the transcoder and the cache database based on the result.
3. In claim 1,
And a network monitoring unit that monitors at least one of a network load with the user terminal, a congestion level of the content server, or a processing capability of the user terminal, and gives a monitoring result to the hit / miss determination unit. ,
A stream server, wherein the hit / miss determination unit determines an optimum encoding rate based on the monitoring result.
4. In claim 1,
When the hit / miss determination unit determines whether the requested content or live, encoding method, and encoding rate data is stored in the cache database, the encoding rate is within an allowable range. A stream server characterized by determining whether or not it is included.
5. In claim 3 ,
The cache type database stores the viewing start time information, stop time information, and change time information for the requested data given from the network monitoring unit,
A stream server, wherein the hit / miss determination unit performs hit / miss determination based on the information.
6. In claim 1,
In the hierarchical coding based on spatial scalability, temporal scalability, or SNR scalability, the transcoder newly creates only the coding data of the coding rate change target layer and the layer one level above it, and is expanded from the new higher layer. A stream that is characterized in that the newly created layer to be changed and the upper layer are made the current layer when the sum of absolute differences between the decoded data and the decoded data expanded from the current upper layer is below a predetermined threshold value. server.

Claims (17)

１つ以上のトランスコーダと、
データを格納するキャッシュ型データベースと、
コンテンツ又はライブ、符号化方式、及び符号化レートに関して要求されたデータが該キャッシュ型データベースに格納されていないとき、該キャッシュ型データベースに該要求されたデータが格納されるように該トランスコーダ及び該キャッシュ型データベースを連携して制御するヒット／ミス判定部と、
を備えたことを特徴とするストリーム・サーバ。One or more transcoders;
A cache database that stores data;
When the requested data regarding content or live, encoding scheme, and encoding rate is not stored in the cache type database, the transcoder and the A hit / miss determination unit that controls the cache-type database in cooperation with each other;
A stream server characterized by comprising: 請求の範囲１において、
該トランスコーダがエンコーダ又はＣＯＤＥＣであることを特徴したストリーム・サーバ。In claim 1,
A stream server, wherein the transcoder is an encoder or a CODEC. 請求の範囲１において、
該キャッシュ型データベースが、同一のコンテンツ又はライブ及び符号化方式に対して異なる符号化レートの該データをそれぞれ格納する複数のラインを有することを特徴としたストリーム・サーバ。In claim 1,
A stream server, wherein the cache database has a plurality of lines each storing the same content or the data at different encoding rates for live and encoding systems. 請求の範囲１において、
ユーザ端末との間で、呼制御、又は該データの配信の開始制御、一時停止制御、若しくは巻戻し制御に関するネゴシエーションを行い、その結果を該ヒット／ミス判定部に通知する呼制御／ネゴシエーション処理部をさらに有し、
該ヒット／ミス判定部が、該結果に基づき該トランスコーダ及び該キャッシュ型データベースに対する連携制御を行うことを特徴とするストリーム・サーバ。In claim 1,
A call control / negotiation processing unit that negotiates call control or data distribution start control, pause control, or rewind control with a user terminal and notifies the hit / miss determination unit of the result. Further comprising
The stream server, wherein the hit / miss determination unit performs cooperative control on the transcoder and the cache database based on the result. 請求の範囲１において、
さらに、ユーザ端末との間のネットワーク負荷、コンテンツサーバの混雑度、又はユーザ端末の処理能力の少なくともいずれか１つを監視し、監視結果を該ヒット／ミス判定部に与えるネットワーク監視部を有し、
該ヒット／ミス判定部が該監視結果に基づき最適符号化レートを決定することを特徴としたストリーム・サーバ。In claim 1,
And a network monitoring unit that monitors at least one of a network load with the user terminal, a congestion level of the content server, or a processing capability of the user terminal, and gives a monitoring result to the hit / miss determination unit. ,
A stream server, wherein the hit / miss determination unit determines an optimum encoding rate based on the monitoring result. 請求の範囲１において、
所定のプロトコルを実装し、該所定プロトコルに基づきユーザ端末との間の通信処理を行うプロトコル実装処理部をさらに有することを特徴としたストリーム・サーバ。In claim 1,
A stream server, further comprising a protocol implementation processing unit that implements a predetermined protocol and performs communication processing with a user terminal based on the predetermined protocol. 請求の範囲６において、
該プロトコル実装処理部が、少なくともＩＰヘッダ処理部、ＵＤＰヘッダ処理部、ＲＴＰヘッダ処理部、ＲＴＣＰヘッダ処理部、及びＲＴＳＰヘッダ処理部の中のいずれか１つを備えていることを特徴とするストリーム・サーバ。In claim 6,
The protocol implementation processing unit includes at least one of an IP header processing unit, a UDP header processing unit, an RTP header processing unit, an RTCP header processing unit, and an RTSP header processing unit. ·server. 請求の範囲６において、
該プロトコル実装処理部が、ＭＰＥＧシーケンスヘッダ処理部を備えていることを特徴としたストリーム・サーバ。In claim 6,
A stream server, wherein the protocol implementation processing unit includes an MPEG sequence header processing unit. 請求の範囲１において、
該トランスコーダが、入力した少なくとも素材データ、トランスコードデータ、及びライブデータの内のいずれか１つを該要求された符号化方式の指定された符号化レートのデータに変換することを特徴とするストリーム・サーバ。In claim 1,
The transcoder converts at least one of input material data, transcode data, and live data into data of a specified encoding rate of the requested encoding method. Stream server. 請求の範囲１において、
該ヒット／ミス判定部が、要求されたコンテンツ又はライブの検索、その符号化方式の検索、符号化レートの検索、及びデータが有効であるか否かの検索の順序を所定の順序で行い要求データのヒット／ミス判定を行うことを特徴としたストリーム・サーバ。In claim 1,
The hit / miss determination unit requests the requested content or live search, the search for the encoding method, the search for the encoding rate, and the search for whether the data is valid in a predetermined order. A stream server characterized by performing data hit / miss determination. 請求の範囲１において、
該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されているか否かの判定に、該符号化レートが許容範囲に入っている否かを判定することを特徴としたストリーム・サーバ。In claim 1,
When the hit / miss determination unit determines whether the requested content or live, encoding method, and encoding rate data is stored in the cache database, the encoding rate is within an allowable range. A stream server characterized by determining whether or not it is included. 請求の範囲１において、
該ヒット／ミス判定部が、該要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータが該キャッシュ型データベースに格納されていないとき、該要求されたコンテンツ又はライブ、要求された符号化方式であり、該要求された符号化レートに近い符号化レートのデータを破棄し、該データが格納されていた位置に、該要求されたデータを格納するように該トランスコーダ及び該キャッシュ型データベースを連携して制御することを特徴としたストリーム・サーバ。In claim 1,
When the hit / miss determination unit does not store the requested content or live, encoding method, and encoding rate data in the cache database, the requested content or live, the requested code The transcoder and the cache type so that the data of the encoding rate close to the requested encoding rate is discarded, and the requested data is stored at the position where the data is stored. A stream server characterized by controlling the database in cooperation. 請求の範囲１において、
該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、又は低視聴率の符号化レートのデータを破棄することを特徴とするストリーム・サーバ。In claim 1,
The stream server, wherein the hit / miss determination unit discards content data or live data with a low audience rating, or data with an encoding rate with a low audience rating. 請求の範囲５において、
該キャッシュ型データベースは、該ネットワーク監視部から与えられた、該要求されたデータについて、その視聴開始時刻情報、停止時刻情報、及び変更時刻情報を格納し、
該ヒット／ミス判定部が、該情報に基づきヒット／ミス判定を行うことを特徴としたストリーム・サーバ。In claim 5,
The cache type database stores the viewing start time information, stop time information, and change time information for the requested data given from the network monitoring unit,
A stream server, wherein the hit / miss determination unit performs hit / miss determination based on the information. 請求の範囲１において、
該ヒット／ミス判定部が、低視聴率のコンテンツデータ又はライブデータ、低視聴率の符号化方式、又は低視聴率の符号化レートのデータの内の少なくとも１つを破棄して、該破棄されたデータが格納されていた場所に、要求されたコンテンツ又はライブ、符号化方式、及び符号化レートのデータを格納するように該トランスコーダ及びキャッシュ型データベースに指示することを特徴とするストリーム・サーバ。In claim 1,
The hit / miss determination unit discards at least one of content data or live data with a low audience rating, encoding method with a low audience rating, or data with an encoding rate with a low audience rating, and the data is discarded. Stream server characterized by instructing the transcoder and cache type database to store data of requested content or live, encoding method, and encoding rate at a location where stored data was stored . 請求の範囲１において、
該ヒット／ミス判定部は、未使用トランスコーダがあるとき、このトランスコーダ及び該キャッシュ型データベースを制御して、新規コンテンツ又は新規ライブを所定符号化レートの所定符号化方式のデータに変換し、該キャッシュ型データベースに格納することを特徴としたストリーム・サーバ。In claim 1,
When there is an unused transcoder, the hit / miss determination unit controls the transcoder and the cache type database to convert new content or new live into data of a predetermined encoding method at a predetermined encoding rate, A stream server that is stored in the cache database. 請求の範囲１において、
該トランスコーダが、空間スケーラビリティ、時間スケーラビリティ、又はＳＮＲスケーラビリティによる階層符号化において、符号化レート変更対象階層及びその１つ上位の階層の符号化データのみ新規に作成し、該新規上位階層より伸長された復号データと現上位階層より伸長された復号データの差分絶対値の和が所定の閾値以下であるとき該新規作成された変更対象階層及び上位階層を現階層とすることを特徴とするストリーム・サーバ。In claim 1,
In the hierarchical coding based on spatial scalability, temporal scalability, or SNR scalability, the transcoder newly creates only the coding data of the coding rate change target layer and the layer one level above it, and is expanded from the new higher layer. A stream that is characterized in that the newly created layer to be changed and the upper layer are made the current layer when the sum of absolute differences between the decoded data and the decoded data expanded from the current upper layer is below a predetermined threshold value. server.
JP2004547993A 2002-10-30 2002-10-30 Stream server Expired - Fee Related JP4408811B2 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2002/011312 WO2004040908A1 (en) 2002-10-30 2002-10-30 Stream server

Publications (2)

Publication Number Publication Date
JPWO2004040908A1 true JPWO2004040908A1 (en) 2006-03-02
JP4408811B2 JP4408811B2 (en) 2010-02-03

Family

ID=32260019

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004547993A Expired - Fee Related JP4408811B2 (en) 2002-10-30 2002-10-30 Stream server

Country Status (2)

Country Link
JP (1) JP4408811B2 (en)
WO (1) WO2004040908A1 (en)

Families Citing this family (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060174314A1 (en) * 2004-07-21 2006-08-03 Jacobs Paul E Methods and apparatus for hybrid multimedia presentations
JP4598823B2 (en) * 2005-03-11 2010-12-15 パイオニア株式会社 Content data transmitting apparatus, content data transmitting method and remote reproduction system
JP4772375B2 (en) * 2005-04-28 2011-09-14 株式会社東芝 Electronic device and content management method
US7664856B2 (en) * 2005-07-28 2010-02-16 Microsoft Corporation Dynamically balancing user experiences in a multi-user computing system
JP5753341B2 (en) * 2006-03-03 2015-07-22 ヴィドヨ，インコーポレーテッド System and method for providing error resilience, random access, and rate control in scalable video communication
JP5478255B2 (en) * 2006-11-30 2014-04-23 コーニンクレッカ フィリップス エヌ ヴェ Driving method and electrophoresis apparatus for electrophoresis cell
WO2010134591A1 (en) * 2009-05-21 2010-11-25 日本電気株式会社 Content distribution system, content distribution device, content distribution method, and content distribution program
JP2010273298A (en) * 2009-05-25 2010-12-02 Broad Earth Inc Content distribution system, distribution control device, and distribution control program
WO2011010688A1 (en) * 2009-07-22 2011-01-27 日本電気株式会社 Content delivery system, content delivery method and content delivery programme
EP2469795B1 (en) * 2010-02-25 2013-04-17 Ntt Docomo, Inc. Method and apparatus for rate shaping
JP5675164B2 (en) * 2010-05-11 2015-02-25 キヤノン株式会社 Transmission device, transmission method, and program
JP6225446B2 (en) 2013-03-26 2017-11-08 富士通株式会社 Moving image data distribution apparatus, method, program, and system
JP2015065493A (en) * 2013-09-24 2015-04-09 日本電気株式会社 Content distribution system, content distribution device, content distribution method, and content distribution program
US10440080B2 (en) 2013-10-18 2019-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Software-defined media platform
US9516084B2 (en) * 2013-11-01 2016-12-06 Ericsson Ab System and method for pre-provisioning adaptive bitrate (ABR) assets in a content delivery network

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3321332B2 (en) * 1995-04-07 2002-09-03 シャープ株式会社 Image storage communication device
JP3653569B2 (en) * 1997-01-30 2005-05-25 マイクロソフト コーポレーション A VCR-like feature that renders video on demand
US6742043B1 (en) * 2000-01-14 2004-05-25 Webtv Networks, Inc. Reformatting with modular proxy server
JP2002084524A (en) * 2000-09-06 2002-03-22 Nippon Telegr & Teleph Corp <Ntt> Method for receiving, encoding, recording and transmitting video, sound or data broadcasting and broadcast recording/reproducing server device.
JP3830756B2 (en) * 2000-12-18 2006-10-11 シャープ株式会社 Broadcast data sharing server device
JP2002232860A (en) * 2001-02-01 2002-08-16 Toshiba Corp System and method for distributing contents, and program
JP2002305703A (en) * 2001-04-05 2002-10-18 Netyear Group Corp Broadcast program distribution device broadcast program distribution method, and its program and recording medium

Also Published As

Publication number Publication date
WO2004040908A1 (en) 2004-05-13
JP4408811B2 (en) 2010-02-03

Similar Documents

Publication Publication Date Title
JP4965059B2 (en) Switching video streams
US5761416A (en) Method and apparatus for distributing network bandwidth on a video server for transmission of bit streams across multiple network interfaces connected to a single internet protocol (IP) network
JP4408811B2 (en) Stream server
US20020131496A1 (en) System and method for adjusting bit rate and cost of delivery of digital data
US20100226444A1 (en) System and method for facilitating video quality of live broadcast information over a shared packet based network
US20100226428A1 (en) Encoder and decoder configuration for addressing latency of communications over a packet based network
US20050187960A1 (en) Stream server
US20110088076A1 (en) System and Method for Media Adaptation
JP5147278B2 (en) Video distribution apparatus and key frame distribution method
US20060167987A1 (en) Content delivery system, communicating apparatus, communicating method, and program
CN103843301A (en) Switching between representations during network streaming of coded multimedia data
JP2003281022A (en) Method of controlling terminal of mpeg-4 system using caching mechanism
WO2000072517A1 (en) System and method for streaming media over an internet protocol system
US7031259B1 (en) Method and system for scheduling a transmission of compressible and non-compressible packets
US7797451B2 (en) A/V stream-forwarding system and method for forwarding A/V streams from data network to IEEE1394 network
JP4998775B2 (en) Information distribution system and method, information distribution apparatus, receiving terminal, and information relay apparatus
KR100848309B1 (en) Apparaus and method of providing internet TV brodacasting service using fast buffering switch
US7505590B1 (en) Method and system for providing transcodability to frame coded streaming media
KR20020037124A (en) Unit and method for audio and video data transmission in network
US8401086B1 (en) System and method for increasing responsiveness to requests for streaming media
CA2657434A1 (en) Encoder and decoder configuration for addressing latency of communications over a packet based network
KR100805805B1 (en) Apparatus and method of dynamic processing of scalable information for scalable video coding
JP2008306273A (en) Moving image provision system, method, device, program
US20100031302A1 (en) Stream distribution system, stream receiving device, and stream reproduction method
KR20230121950A (en) Adaptive media streaming transmission method and apparatus for multi network

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20080304

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080507

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20090414

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20090713

A911 Transfer of reconsideration by examiner before appeal (zenchi)

Free format text: JAPANESE INTERMEDIATE CODE: A911

Effective date: 20090730

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20091110

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20091110

R150 Certificate of patent or registration of utility model

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121120

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121120

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20131120

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees