JP4087706B2 - オーディオおよび、またはビデオマテリアルの送信および受信 - Google Patents

オーディオおよび、またはビデオマテリアルの送信および受信 Download PDF

Info

Publication number
JP4087706B2
JP4087706B2 JP2002550714A JP2002550714A JP4087706B2 JP 4087706 B2 JP4087706 B2 JP 4087706B2 JP 2002550714 A JP2002550714 A JP 2002550714A JP 2002550714 A JP2002550714 A JP 2002550714A JP 4087706 B2 JP4087706 B2 JP 4087706B2
Authority
JP
Japan
Prior art keywords
file
station
subfile
server
files
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.)
Expired - Lifetime
Application number
JP2002550714A
Other languages
English (en)
Other versions
JP2004516717A (ja
JP2004516717A5 (ja
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.)
British Telecommunications PLC
Original Assignee
British Telecommunications PLC
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
Priority claimed from GBGB0030706.6A external-priority patent/GB0030706D0/en
Priority claimed from GB0108094A external-priority patent/GB0108094D0/en
Application filed by British Telecommunications PLC filed Critical British Telecommunications PLC
Publication of JP2004516717A publication Critical patent/JP2004516717A/ja
Publication of JP2004516717A5 publication Critical patent/JP2004516717A5/ja
Application granted granted Critical
Publication of JP4087706B2 publication Critical patent/JP4087706B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/23424—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for inserting or substituting an advertisement
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/234354—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements by altering signal-to-noise ratio parameters, e.g. requantization
    • 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/234—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439—Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • 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/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/266—Channel or content management, e.g. generation and management of keys and entitlement messages in a conditional access system, merging a VOD unicast channel into a multicast channel
    • H04N21/2662—Controlling the complexity of the video stream, e.g. by scaling the resolution or bitrate of the video stream based on the client capabilities
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/41—Structure of client; Structure of client peripherals
    • H04N21/414—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance
    • H04N21/4143—Specialised client platforms, e.g. receiver in car or embedded in a mobile appliance embedded in a Personal Computer [PC]
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/439—Processing of audio elementary streams
    • H04N21/4392—Processing of audio elementary streams involving audio buffer management
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/44—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs
    • H04N21/44016—Processing of video elementary streams, e.g. splicing a video clip retrieved from local storage with an incoming video stream or rendering scenes according to encoded video stream scene graphs involving splicing one content stream with another content stream, e.g. for substituting a video clip
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • 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/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/47—End-user applications
    • H04N21/472—End-user interface for requesting content, additional data or services; End-user interface for interacting with content, e.g. for content reservation or setting reminders, for requesting event notification, for manipulating displayed content
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6373—Control signals issued by the client directed to the server or network components for rate control, e.g. request to the server to modify its transmission rate
    • 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/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/81—Monomedia components thereof
    • H04N21/8106—Monomedia components thereof involving special audio data, e.g. different tracks for different languages
    • 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/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Signal Processing (AREA)
  • Multimedia (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Marketing (AREA)
  • Business, Economics & Management (AREA)
  • Human Computer Interaction (AREA)
  • General Engineering & Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Information Transfer Between Computers (AREA)
  • Television Signal Processing For Recording (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、デジタル符号化されたマテリアルの通信リンクによるユーザへの配信に関する。
【０００２】
【従来の技術】
このタイプの既知のシステムでは、しばしば“ストリーマ”と呼ばれる特別のサーバがユーザ端末へのマテリアルの受渡しを制御する。サーバではしばしば、送信されるべきマテリアルのアイテムは単一のファイルとして記憶される。米国特許第５６１０８４１号明細書にはビデオサーバが記載され、それは“メディアセグメントファイルに”セグメント化されたマテリアルを記憶する。別のそのようなシステムはヨーロッパ特許出願ＥＰ−Ａ−６６９５８７号明細書に記載され、それにおいてはネットワーク衝突はその受信バッファの内容を監視する端末によって行われ、そのビデオデータレートを調節するために適切にサーバにリクエストする。
【０００３】
【発明が解決しようとする課題】
本発明によれば、オーディオまたはビデオマテリアルの連続する時間的部分を表している１組のファイルとして遠隔サーバに記憶されているオーディオまたはビデオマテリアルを再生する端末が提供される。
【０００４】
【課題を解決するための手段】
本発明の１特徴によれば、オーディオまたはビデオマテリアルの連続する時間的部分を表している１組のファイルとして遠隔サーバに記憶されているオーディオまたはビデオマテリアルを再生する端末は、サーバと通信する通信インターフェースと、通信インターフェースからファイルを受取るバッファと、バッファの内容を再生する手段と、バッファの状態に応答してバッファの補充のためにさらに別のファイルに対してリクエストメッセージを生成するように動作する制御手段とを具備していることを特徴とする。
【０００５】
本発明の別の特徴によれば、本発明は、デジタル符号化されたオーディオまたはビデオマテリアルを送信する方法が提供され、その方法においては、前記マテリアルの連続する時間的部分をそれぞれ表している複数のディスクリートなファイルにマテリアルを分割し、それらのファイルを第１の局において記憶し、第２の局においては、
ａ）ファイルの連続するそれぞれに対するリクエストを第１の局に送信し、
ｂ）ファイルを受信し、
ｃ）マテリアルの再生のためにファイルをデコードすることを特徴とする。
【０００６】
本願発明のその他の随意的な特徴はその他の従属請求項に記載されている。
【０００７】
【発明の実施の形態】
添付図面を参照にして、本発明の実施形態について説明する。図１に示されたシステムは、デジタル符号化されたオーディオ信号を通信ネットワークを介して対応する音響がユーザに対して再生されるユーザ端末へ配信することを目的としている。しかしながら、以下詳細に説明するように、このシステムはオーディオ信号の代りに、或いはオーディオ信号に付加してビデオ信号を伝送するために使用することもできる。この例では、ネットワークは、原理的には他のデジタルリンクまたはネットワークを使用することが可能であるが、ハイパーテキスト転送プロトコル（詳細はＲＦＣ1945/2068 参照）にしたがって動作するインターネットまたは他のパケットネットワークである。オーディオ信号はＩＳＯ ＭＰＥＧ−１層III 標準方式（ＭＰ３標準方式）を使用する圧縮された形態で記録されていると仮定する。しかしながら、この特定のフォーマットの使用は本質的なことではない。事実、特に利用できるビットレートが制限され、或いは記憶スペースが限定されている場合には圧縮の使用は非常に望ましいことであるが、本質的に必要なことではない。図１ではサーバ1 はインターネット2 を介して１つしか示されていないユーザ端末3 に接続されている。サーバ1 の機能はデータファイルを記憶し、所望のデータファイルの配信のためのリクエストをユーザ端末から受信し、リクエストに応答してそのファイルをネットワークを介してユーザ端末に送信することである。通常そのようなリクエストはネットワーク配信機構（例えば、ハイパーテキスト転送プロトコルまたはファイル転送プロトコルに対してはそれぞれhttp：//またはファイル：//）を指示する第１の部分の形態を取り、それに続いてサーバのネットワークアドレス（例えばｗｗｗサーバ１.com）が付加され、さらにそれに続いてリクエストされているファイル名を付けられている。与えられた例ではそのような名称はタイプ上の理由で//で示されている。
【０００８】
これらの例では、ハイパーテキスト転送プロトコルを使用するものと仮定しており、これは本質的なことではないが、そのプロトコルによって与えられた承認およびセキュリティ特徴（秘密ソケット層のような）の使用を可能にする利点がある。
【０００９】
通常ＭＰ３ファイルの受渡し用のサーバはいわゆるストリーマの形態をとり、それはユーザ端末での応答要求に応じてデータが送信される速度をダイナミックに制御し、パケット損失によるエラーをマスクし、ユーザの介入が許容されている場合にはサーバとクライアントとの間のデータ流を制御する処理装置を含んでいる。しかしながら、ここではサーバ1 はそのような設備は含んでいない。したがって、それは通常の“ウエブサーバ”である。
【００１０】
データファイルがサーバ1 に記憶される方法について説明する。ＭＰ３フォーマットのファイルが生成されてサーバに記憶されると考える。それはＪ．Ｓ．バッハのトッカータとフーガＤ短調（ＢＷＶ565 ）の記録であり、典型的に９分の再生時間を有する。元来これは単一のデータファイルとして生成され、通常のストリーマではこれは１つの単一のファイルとして記憶される。しかしながら、ここではファイルはサーバ1 に記憶される前に小さいファイルに分割される。これらの各小さいファイルはそれぞれ固定された再生時間、恐らく４秒に対応する大きさである。ＭＰ３のような圧縮されたフォーマットにより、これはそれらのファイルが実際に含んでいるビットの数に対して異なった大きさであることを意味している。したがって９分の期間のバッハのファイルはそれぞれ４秒の再生時間の１３５の小さいファイルに分割される。この例では、これらは所定のファイル名を与えられ、それはもとのファイル中のそれらの順序を示す通し番号を含んでおり、例えば、
000000．ビン
000001．ビン
000002．ビン
000003．ビン
・
・
000134．ビンである。
【００１１】
ファイルのこれらの小さいサブファイルへの分割は典型的にウエブサーバ1 へロードするためのファイルを処理する人によって行われることができる（ここで使用されるサブファイルという用語は、全体の記録を含んでいるもとのファイルと区別するためにここで使用されているが、しかしながらサーバが関係される限りサブファイルは他のファイルと同様のファイルであることを強調しておく）。それらを生成する正確な方法について以下さらに十分に説明する。これらのサブファイルは、一度生成されると、任意の他のファイルがウエブサーバへロードされるのと同様の通常の方法でサーバにアップロードされる。もちろんファイル名は特定の記録を識別する文字を含むことができる（ＭＰ３ファイルを再生するときサブファイルは著者、著作権等の情報を得る付加的な情報のタグを付けられることもできる）が、この例においてはサブファイルはサーバ中で特定の記録、例えばｍｐ３ ｂｗｖ５６５に特定された名簿またはホルダー中に記憶される。したがってサブファイルは必要なとき次の形態でリクエストされることができる。
【００１２】
http：//ｗｗｗサーバ1 ．com/mp3 ｂｗｖ565/000003．ビン
ここで“ｗｗｗサーバ1 ．com ”はサーバ1 のＵＲＬである。
【００１３】
それはまた、各記録に対してリンクページ（典型的にはｈｔｍフォーマットで）を生成するためにサーバにロードするためのサブファイルを処理する人に対して都合がよい。このリンクページもまたサーバに記憶され（恐らくファイルネームｍｐ３ ｂｗｖ565/ｌｉｎｋ．ｈｔｍにより）、その構造および目的については後述する。
【００１４】
また、対応するリンクページに対するハイパーリンクを有する利用可能な記録リストを含む１以上の（ｈｔｍｌ）メニューページ（例えばｍｅｎｕ．ｈｔｍ）を記憶することも都合のよいことである。
【００１５】
次に、端末について説明すると、これは典型的に通常のデスクトップコンピュータの形態のものでよいが、前述したオーディオファイルの受信を処理するための付加的なソフトウエアを有している。所望ならば、端末は手持ち形のコンピュータの形態をとることができ、また、移動体電話機中に内蔵されてもよい。したがって、図２はそのような端末を示し、それは中央プロセッサ30、メモリ31、ディスク記憶装置32、キーボード33、ビデオディスプレイ34、通信インターフェース35、オーディオインターフェース（音響カード）36を備えている。ビデオ配信のためには、音響カード36の代りに或いはそれに追加してビデオカードが使用される。ディスク記憶装置32には通常の方法でプロセッサ30により実行されるためにメモリ中で検索されることのできるプログラムが記憶されている。これらのプログラムは呼出しおよびｈｔｍページの表示のための通信プログラム37、すなわちNetscape NavigatorまたはMicrosoft Explorerのような“ウエブブラウザ”プログラムおよび本発明のこの実施形態にしたがってオーディオファイルの再生のために必要な機能性を与えるここで“プレイヤープログラム”と呼ばれているような別のプログラム38を含んでいる。また、メモリ31の39で示される領域はバッファとして割当てられている。これは再生されるために待機しているデータを含む復調されたオーディオバッファである（典型的に、バッファの動作継続時間は１０秒である）。オーディオインターフェースまたは音響カード36は通常のカードであり、単にＰＣＭオーディオ信号を受信してそれをアナログオーディオ信号に変換するように、例えばスピーカにより再生するように機能する。最初に、ＨＴＴＰおよび内蔵またはプラグインされたクライアント装置を使用するとき、所望の記録を検索して再生する端末装置の動作の概要について簡単に説明する。
【００１６】
１．ユーザはブラウザを使用してサーバ1 からメニューページｍｅｎｕ．ｈｔｍを検索して表示する。
【００１７】
２．ユーザはメニューページ内のハイパーリンクの１つを選択し、それはブラウザにサーバを検索させ、この例ではファイルｍｐ３ ｂｗｖ565 ｌｉｎｋ．ｈｔｍのような所望の記録に対するリンクページを表示させる。このページの実際の表示は重要ではない（恐らくそれがシステムが正確に動作していることをユーザに再確認させるメッセージを含んでいることを除いて）。このページで重要なことは、プレイヤープログラム37が実行される第２のプロセスをプロセッサ30に開始させる命令（または埋設タグ）を含むことである。この方法における第２のプロセスの開始は実際によく知られている（そのようなプロセスはプラグインとしてＮｅｔｓｃａｐｅシステムで、また、アクチブＸとしてマイクロソフトシステムで知られている）。このような命令はまた第２のプロセスに送られるパラメータを含むこともでき、図１のシステムで命令は記録のサーバＵＲＬを含んでおり、それはバッハのピースに対してｈｔｔｐ//ｗｗｗ．サーバ1/ｍｐ３ ｂｗｖ565 である。
【００１８】
３．プレイヤープログラム37はＭＰ３デコーダを含み、その動作自体は通常のものである。この説明でさらに重要なことはプログラムの制御機能であり、それについて以下説明する。
【００１９】
４．ＵＲＬを受信したプレイヤープログラムはこれに第１のサブファイルのファイルネームを付加してサブファイルに対する完全なアドレスを生成する。すなわち、ｗｗｗ．サーバ1/ｍｐ３ ｂｗｖ565/000000．ｂｉｎを生成する。サブファイルが上に示した方法で名前を付けられことに基づいて、このシステムが組織化されることが観察され、その結果端末はファイルネームを報告する必要がない。このプログラムはこのＵＲＬを有するファイルに対するリクエストメッセージを構成し、それを通信インターフェース35およびインターネット2 を介してサーバ1 に送信する（ＵＲＬをＩＰアドレスに変換するプロセス、無効のエラー報告、不完全または利用できないＵＲＬは通常のものであり、ここでは説明しない）。プレイヤープログラムはブラウザを介するのではなく、直接通信インターフェースにリクエストを送信することが予想される。サーバはリクエストされたサブファイルを送信することによって応答する。
【００２０】
５．プレイヤープログラムはファイルからこのサブファイル中で使用されたオーディオ符号化を決定し、関係した標準方式にしたがって（この例ではＭＰ３）粗ＰＣＭ値にファイルをデコードして戻し、このサブファイルの再生時間のノートを作成する。一般にオーディオファイルは使用された符号化を説明するファイルの最初における識別子を含んでいる。デコードされたオーディオデータはその後オーディオバッファ38に記憶される。
【００２１】
６．プレイヤープログラムは再生終了時間Ｔp と呼ばれるパラメータを有している。この例ではそれは１０秒に設定されている（所望ならばユーザ選択可能にされることができる）。それは端末が行なうバッファの程度を決定する。
【００２２】
７．プレイヤープログラムはファイルネームを000001.binへインクリメントし、リクエストし、受信し、デコードして上記の（４）および（５）で記載したように第２のサブファイルを記憶する。このプロセスはバッファの内容がこの再生終了時間Ｔp に到達するか、または、それを越えるまで反復される。デコードがバッファの前に行なわれることは実際には重要なことではないが、簡単になることに注意すべきである。それはオーディオはデコードされて粗ＰＣＭに戻され、その後、バッファされたマテリアルの継続時間は明瞭に知られるからである。各サブファイルが同じオーディオ再生サイズであるならばオーディオバッファの制御は簡単にされる。
【００２３】
８．再生終了時間Ｔp に到達したとき、デコードされたデータはバッファからオーディオインターフェース36に送られ、それはスピーカ（図示せず）によって音を再生する。
【００２４】
９．上記（８）で音が再生される一方で、プレイヤープログラムは連続的にバッファの満杯の状態について監視し、これがＴp より小さくなったときファイルネームを再びインクリメントしてサーバからさらに別のサブファイルを得る。このプロセスは“ファイルはエラーを発見しない”が戻されるまで反復される。
【００２５】
１０．このプロセス中にバッファが空になった場合には、プレイヤープログラムはさらにデータが到着するまで演奏を停止する。
【００２６】
ここで使用される０で開始される数字の簡単な固定長のシーケンスのサブファイルネーミングは構成が簡単であり好ましいが、任意の他のネーミング方法が第１のサブファイルのネームおよび連続する１を計算することを可能にするアルゴリズムのいずれかを含むか（または送信される）プレイヤープログラムを与えるため或いはファイルネームのリストを送信するために使用することができる。
【００２７】
上述のシステムはユーザに再生プロセスに介入する機会を何等与えないことが認められるであろう。また、バッファのアンダーフロー（例えばネットワークの衝突によって）の可能性に対しても何等救済しない。それ故、第２のさらに精巧なこの発明の実施形態について以下説明し、それはさらに次のような特徴を提供する。
【００２８】
ａ）サーバは異なった圧縮率で記録された記録の２以上のバージョンを記憶し［例えば、それぞれ、8 ,16, 24, 32 キロビット／秒の（連続的な）データレートに対応する圧縮率で］、プレイヤープログラムは自動的にそれらの間で切換えることができる。
【００２９】
ｂ）プレイヤープログラムはユーザに対して制御パネルを表示し、それによりユーザは再生を開始し、それを中断し、それを再開し（最初から、或いは中止した点から）、または記録中の異なる点（後方または前方）にジャンプすることが可能になる。
【００３０】
これらの特徴は相互依存性ではなく、ユーザ制御はレートスイッチングなしに或いはその反対に行われることができる。
【００３１】
レートスイッチングを行なうために、サーバにロードするためにファイルを処理する人は、異なったレートで複数回同じＰＣＭファイルを符号化することによって幾つかのソースファイルを処理する。彼は各ソースファイルを前述したようにサブファイルに区分する。これらは異なったレートに対応する別々のディレクトリ（登録簿）でサーバにロードされる。例えば、次の例の構成ではディレクトリネーム中の“008k”“024k”は８キロビット／秒または２４キロビット／秒等のレートを示している。
【００３２】
彼はまたインデックスファイル（例えばindex.htm ）を生成し、その主目的は利用可能なデータレートのリストを提供することである。
【００３３】
【表１】
Figure 0004087706
サブファイルの長さは前に説明したように固定された時間長に対応しているから、サブファイルの数は各ディレクトリに対して同じである。サブディレクトリネームはキロビット／秒のデータレート（３デジット）プラス文字“ｋ”を含んでおり、この例ではオーディオサンプリングレート（11.025kHz ）の指示であって、モノとステレオのフラグが確認のために付加されている。
【００３４】
したがって、インデックスファイルは次の形態のステートメントである。
【００３５】
＜！オーディオ信号＝“024k 11 s 032k 11 s 018k 11 s 016k 11 m 018k 11 m ”…＞
（＜！…... …＞は単にステートメントがｈｔｍｌファイル中のコメント［または簡単なテキストファイルが使用可能である］として埋設されていることを示している。）典型的なインデックスファイルは図３に示されており、それには他の情報が含まれている。すなわち、ＬＦＩは最高のサブファイル数（すなわち４５のサブファイル）であり、ＳＬは全体の再生時間である（１７８秒）。“モード”は“記録された（ここで）”または“ライブ（以下説明する）”を示している。他のエントリは自明であり、或いは標準的なｈｔｍｌコマンドである。
【００３６】
最初に、プレイヤープログラムはリンクファイル、インデックスファイルで特定されたディレクトリからのリクエストにより開始し、将来の基準のために利用可能なデータレートのリストを局部的に記憶する。（このファイルまたは丁度特定したディレクトリの明瞭なリクエストであってもよく、大抵のサーバはファイルネームが特定されていなければindex.htm にデフォルトである。）。その後、インデックスファイル−viz.024k 11 s （または端末はその端末に局部的に設定されたデフォルトレートにこれに修正することによってこれに重ね書きされる）中の最初に挙げた“レート”ディレクトリから前述のようにオーディオサブファイルのリクエストが開始される。それからのプロセスは、プレイヤープログラムがサーバから受信されている実際のデータレートを測定して、ある期間にわたって（例えば３０秒）平均する。全てのＵＲＬリクエストをタイミング制御することによって、クライアントとサーバとの間で得られる転送レート（毎秒当たりのビット数）が決定される。この図の正確さはリクエスト数が増加するにしたがって改善される。プレイヤーは現在のレートと測定されたレートをそれぞれ示している２つの記憶されたパラメータを維持する。 レート変化の開始がトリガーされる。
ａ）バッファが空であり、かつ、測定されたレートが現在のレートよりも小さく、かつ、測定されたバッファロウ（Ｌｏｗ）％がステップダウンしきい値（以下説明する）を越える場合には、現在のレートを減少させる（バッファがすでに空であるとき、音響カードは何も再生しないのが有効であるので時間を変化させ、オーディオサンプリングレート、ステレオ−モノ設定、またはビット幅［サンプル当たりのビット数］が変化された場合にはそれは再構成することが必要である可能性がある）。
【００３７】
ｂ）測定されたレートが現在のレートを越えているだけではなく、所定の期間（例えば１２０秒：これは所望ならばユーザにより調整可能にされることができる）に対して次に高いレートを越えるならば、現在のレートを増加させる。
【００３８】
バッファロウ％はバッファの内容がプレイアウト時間（すなわち、バッファが空に近い状態）の２５％よりも小さい時間の割合である。ステップダウンしきい値が０％に設定され、そのときバッファは空であるならば、システムは他の条件が満足されたときには常にステップダウンする。ステップダウンしきい値を５％に設定する（これは我々の好ましいデフォルト値である）ことは、バッファは空であるが、測定されたバッファロウ％が５％よりも大きければステップダウンは行わないことを意味している。さらに、バッファの空はこの測定されたレートを明らかに増加させ、レートが持続できない場合には、バッファロウ％が５％を越えることにより再びバッファを最終的に空にする。値を１００％に設定することは、クライアントが決してステップダウンを行わないことを意味している。
【００３９】
実際のレート変化は、データレートを８ｋビット／秒から２４ｋビット／秒に増加するために“008k”を“024k”に変更するようにサブファイルアドレスの関係する部分を変更し、現在のレートのパラメータを整合するように変更するプレイヤープログラムによって簡単に行うことができる。その結果サーバに対する次のリクエストはより高い（またはより低い）レートに対するリクエストとなり、新しいディレクトリからサブファイルが受信され、デコードされてバッファに入力される。以上説明したプロセスは次のフローチャートに要約されている。
【００４０】
【表２】
Figure 0004087706
【表３】
Figure 0004087706
【表４】
Figure 0004087706
【表５】
Figure 0004087706
ユーザ制御は、キーボードまたはマウスのようなその他の入力装置を使用してユーザが選択できる以下のオプションをスクリーン上に提供するようにユーザにより行われる。
【００４１】
ａ）スタート：上記の与えられた番号のステップ４から実行される。記録が最初に選択されたとき、再生が自動的に開始されるか、またはユーザからのスタート指令が必要かは随意であり、事実、所望ならばその選択はリンクファイル中の“自動プレイ”パラメータにより行われることができる。
【００４２】
ｂ）中断：ＭＰ３デコーダへの命令によって実行され、バッファからのデータの読出しを中断する。
【００４３】
ｃ）再開：ＭＰ３デコーダへの命令によって実行され、バッファからのデータの読出しを再開する。
【００４４】
ｄ）ジャンプ：例えば、記録の全期間を表している表示されたバー上の所望の点にカーソルを移動させることによって、ユーザはその希望している記録の部分へジャンプする位置を示すことによってユーザにより実行される。その後、プレーヤはこの点がバーに沿ってｘ％であることを決定して、次のサブファイルが必要としている数を計算し、それは次のリクエストに対して使用される。前記のバッハの例では１２５のサブファイルがあり、２０％の点から再生することがリクエストされ、２６番目のサブファイル、すなわち、000025.binに対してリクエストを生成する。この計算は、各サブファイルが同じ固定した期間に対応している場合には著しく簡単になることは明らかである。ジャンプの場合には、新しいリクエストがすぐに送られるようにデコードを中断し、バッファをクリアすることが好ましいが、これは実際には重要なことではない。
【００４５】
その代りにユーザは、ジャンプを開始するために選択される（例えばマウスにより）ことのできるテキストラベルや指標のリストを与えられてもよい。これは次のように行われる。：
メモリ中に端末により保持されたｉｎｄｅｘ．ｈｔｍファイルは、この情報が文献内のコメントとして埋設されると仮定されている形態のリストを含む。
【００４６】
＜…！Ｏｄビットインデックス＝“0;01:44 無線”＞
ここで“Ｏｄビット”は後続するテキストがプログラムにより処理されるべきであるプレイヤープログラムに対するキーワード指示であり、“インデックス”はプレイヤープログラムが行う機能を示し、クォーテーションマークを有するテキストは再生が開始される記録の最初からの時間（時、分、秒）からなる。
【００４７】
プレイヤープログラムがｉｎｄｅｘ．ｈｔｍファイルを読取り、インデックスコマンドを認識してメッセージ（“イベント”）を生成してそれをリンクｈｔｍページへ与え、それはコマンドを含み（典型的にJavascript）、表示されるページ上の所望の位置にラベルを表示することによってそのようなイベントを処理し、プレイヤープログラムに対するジャンプ（対応する時間を含む）を生成することによりそれらのコマンドの選択に応答する。
【００４８】
もとのファイルをサブファイルに区分するプロセスについてさらに議論することは重要である。最初に、もしも、（前述した最初のバージョンのように）もとのシーケンス中にそれにすぐに後続している以外のサブファイルによってサブファイルが後続される場合には期待されるものはなく、サブファイル間の境界が位置している場所は重要ではない。その場合には、サブファイルの大きさは固定数のビットであるか、或いは固定された再生時間長であり（またはそれら両者が存在しない）、ただ一つの実際の決定はどのような大きさのサブファイルが存在しなければならないかである。ジャンプが予想される場合に（時間的、または異なったデータレートの間）他の考察も存在する。多数のタイプのスピーチまたはオーディオ符号化方式（ＭＰ３を含む）が存在する場合に、信号はフレームで符号化され、サブファイルはフレームの全体数を含んでいなければならない。レートスイッチングの場合には、実際には重要ではないが、サブファイル境界が各レートに対して同じであることは非常に望ましく、そのため、新しいレートで受信された第１のサブファイルは終了した古いレートの最後のサブファイルを記録する同じ地点から連続する。同じ固定時間長（例えば上述の４秒）を表さなければならない全てのサブファイルはこれを解決するただ１つの方法ではないが、たしかに最も便利である。しかしながら、使用する符号化システムに応じて、サブファイルがフレームの全数含んでいなければならないと言う要求は、サブファイルの再生期間が多少変化することを意味することもできる。本発明のこの実施形態では、利用できるデータレートは、異なった量子化程度を使用し、モノで符号化するかステレオで符号化するかで異なっているが、全て同じオーディオサンプリングレートを使用し、結果的に同じフレームサイズである。異なったフレームサイズが使用されるとき、アドレスされる必要について以下説明する。
【００４９】
実際のサブファイル長に対しては、過度に短いサブファイルは、（ａ）より多くのリクエストの形態で余分のネットワークトラヒックを生成するため、および（ｂ）ＩＰネットワークを含むある形式のパケットネットワークにおいて、小さいパケットにより伝送されなければならないので不経済であり、そのためリクエストプロセスにより与えられるオーバーヘッドおよびパケットヘッダが比例して大きくなるために避けることが好ましい。他方で、過度に大きいサブファイルでは、大きいバッファが必要であり、再生を開始するとき、および、またはジャンプ或いはレート変化が求められたときに余分の遅延を生じて不利である。プレイアウト時間の３０％乃至１３０％の範囲のサブファイルサイズ、または好ましくはプレイアウト時間のほぼ半分のサブファイルサイズ（上記の与えられた例のような）が満足できるものであることが認められた。
【００５０】
サブファイルを変換する実際のプロセスは論じられた基準にしたがいプログラムされたコンピュータにより実行されることができる。これはサブファイルがサーバへアップロードできる別のコンピュータで行うことが好ましい。
【００５１】
別の改善方法は、より複雑なサブファイルネーミング方法を置換できて、サブファイルを権限のない人がコピーして別のサーバにそれを提供することを困難にすることによりセキュリティを増加させる。１例は疑似ランダムシーケンス発生器を使用してファイルネームを生成することである。例えば、次の形態のファイルネームを生成する。
Figure 0004087706
この場合に、プレイヤープログラムは同一の疑似ランダムシーケンス発生器を含んでいる。サーバは第１のファイルネームまたは４つのデジットの“シード”を送り、プレイヤー中の発生器はそのときその発生器を同期して正確なシーケンスで要求されたサブファイルネームを生成する。
【００５２】
レートスイッチングの上記の例において、使用される全てのデータレートは同じフレームサイズであり、特に１１．０２５ＫＨｚでサンプリングされたＰＣＭオーディオのＭＰ３コード化および１１５２サンプルの（ＰＣＭ）フレームサイズである。もしも異なったフレームサイズを有するＭＰ３（または他の）記録との間でレートスイッチングを行うことが所望されるならば、フレーム境界がそのとき一致しないためにサブファイルが全体のフレーム数を含まなければならないと言う要求によって問題が生じる。この問題はサブファイルを生成するために以下の修正された手順によって解決することができる。特に、この手順は、レートスイッチングが要求され、上述した特定の受渡し方法に制限がない状態で使用されることができる。
【００５３】
図４はオーディオサンプルのシーケンスを概略的に示している。それにおいて連続する４秒のセグメントは境界マーク（図において）Ｂ1 ，Ｂ2 等によって規定される。１１．０２５ＫＨｚにおいて、各セグメントには４４，１００のサンプルがある。
【００５４】
１．オーディオ信号を符号化し、境界Ｂ1 でスタートし、フレーム毎に、ＭＰ３サブファイルを生成し、少なくとも４秒の全体の期間を有するフレームの全体数が符号化されるまで続けられる。１１５２サンプルのフレームサイズによれば４秒は３８．３フレームに対応し、そのため３９フレームを表すサブファイルＳ１は全体で４．０７５秒の期間を表し、正確に符号化される。
【００５５】
２．オーディオ信号を符号化し、同じように境界Ｂ2 でスタートする。
【００５６】
３．反復的に、４秒の境界でそれぞれスタートし、それ故この方法でオーバーラップするサブファイルのセットが符号化される全体のオーディオシーケンスに対して生成される。最後のセグメント（それは４秒よりも短くてよい）はもちろんそれに後続するものは何もなく、ゼロ（すなわち沈黙）を詰められる。
異なったフレームサイズを使用するその他のデータレートの符号化は同様な方法で行われる。
【００５７】
端末において、制御機構は変更されないが、デコードおよびバッファプロセスは変更される。：
１．サブファイルＳ１を受信する。；
２．サブファイルＳ１をデコードする。；
３．デコードされたオーディオサンプルの最初の４秒だけをバッファに書込む
（残りは廃棄する）；
４．サブファイルＳ２を受信する。；
５．サブファイルＳ２をデコードする。；
６．デコードされたオーディオサンプルの最初の４秒だけをバッファに書込む
（残りは廃棄する）；
７．サブファイルＳ３等について続ける。
このようにして、全てのレートに対するサブファイルセットはもとのＰＣＭシーケンスの同じ点に対応するサブファイル境界を有する。
【００５８】
したがって最後のものを除いて各４秒の期間は符号化に先立って次の４秒の期間からのオーディオサンプルを詰込まれ、それによりサブファイルサイズをＭＰ３フレームの全体数までにする。所望ならば、詰込むサンプルは後続するものの最初のものの代りに（或いはそれと同様に）先行する４秒の期間の終わりから取ることができる。
【００５９】
ＭＰ３標準はある情報が１つのオーディオフレームから他へキャリーオーバーされることを可能にする（ビット保存として知られている方式により）。これに関連してこれはサブファイル内に受入れることが可能であるが、サブファイル間で受入れ可能ではない。しかしながら、標準方式は当然記録の終わりまたは始めでそのようなキャリーオーバーを許容しないから、この問題は、あだかも単一の記録であるかのように各サブファイルを別々に符号化することによって容易に解決される。
【００６０】
サンプリングレートの変化（および事実モノとステレオの動作の切換え）はオーディオインターフェース36の動作に対して実際的な連携を有する。多くの通常の音響カードは、異なった設定範囲で動作可能であるが、サンプリングレートを変更するために再設定を必要とし、これはそのオーディオ出力に中断を生じさせる必要がある。したがって、さらに別の変形では、予想される最高のサンプリングレートで音響カードを連続的に動作させることを提案する。プレイヤープログラムが低いサンプリングレートでバッファにデータを供給しているとき、このデータはバッファの前、または後でこの最高のレートにアップサンプリングされる。同様に、カードが常にステレオモードで動作されるならば、デコードされたモノ信号は並列に音響カード入力の左右の両チヤンネルに供給される。再び、デコードされた信号のサンプル当たりのビット数がカードによって予測されたよりも低い場合には、ビット数は０を詰めることによって増加することができる。
【００６１】
自動データレートに対して最初に説明した基準を思い出すと、過方向のスイッチングはバッファのアンダーフローの場合にのみレート減少（それ故出力における中断を含む）を予想させ、この変形により、そのような中断は避けることができ、それ故、アンダーフローを期待する基準を使用することが好ましく、主要な場合にそれを避けることができる。この場合には上述した３つのアンド条件の最初のもの（すなわちバッファが空である）は省略される。
【００６２】
説明されたシステムのコンテキストで与えられる別の特徴は、サブタイトルまたは音響に伴う（スライドショーの性質を有する）静止画像のような可視情報を表示することである。これは次のように行われる。
【００６３】
（ａ）表示されている文献（ｌｉｎｋ．ｈｔｍ）は可視情報が現れるページ中の位置を特定するフォーマット情報を含んでいる。
【００６４】
（ｂ）ファイルｉｎｄｅｘ．ｈｔｍは（この情報が文献によるコメントとして埋設されていると仮定した）形態のラインを含んでいる。
【００６５】
＜！…Ｏｄビット：サブタイトル＝“0:1:01サブタイトルテキスト”…＞
＜！…Ｏｄビット：イメージ＝“0:2:04ｈｔｔｐ：//…／画像ｊｐｇ”…＞
ここで、“Ｏｄビット”は、後続するテキストがプログラムにより処理されるべきであることをプレイヤープログラムに示すキーワードであり、“サブタイトル”または“イメージ”はプレイヤープログラムが行う機能を示し、クォーテーションマークを有するテキストは、対応する表示が開始される記録の最初からの時間（時、分、秒）からなり、それに実際のサブタイトルまたは所望のイメージのＵＲＬが場合に応じて後続する。
【００６６】
（ｃ）プレイヤープログラムは、現在のサブファイルインデックスとサブファイルの長さの積である実際の時間を計算し、現在のサブファイルが再生している時間だけインクリメントされる。
【００６７】
（ｄ）プレイヤープログラムは、実際の時間をｉｎｄｅｘ．ｈｔｍファイル中に含まれている時間と比較し、整合した場合にはメッセージをｌｉｎｋ．ｈｔｍページに戻す（それはプレーヤーを元来求めている）。そのようなメッセージは“イベント”と呼ばれる。ｌｉｎｋ．ｈｔｍページがどのようにそのイベントを処理するかはｌｉｎｋ．ｈｔｍページを記載した人の判断にある。典型的に、
（ｅ）サブタイトルに対しては、ｌｉｎｋ．ｈｔｍページは実行可能なコマンド（典型的にＪａｖａｓｃｒｉｐｔで記載されている）を含み、それはｉｎｄｅｘ．ｈｔｍファイルからサブタイトルテキストを読取り、所望の場所にそれを表示することによってそのイベントに応答する。
【００６８】
（ｆ）イメージに対しては、ｌｉｎｋ．ｈｔｍページは、ｉｎｄｅｘ．ｈｔｍファイルからのイメージのＵＲＬを読取り、そのＵＲＬを有するイメージファイルをダウンロードするためにリクエストメッセージを生成し、ページ上の所望の位置にそれを表示することによってそのイベントに応答する。このダウンロードはイメージが要求されたときに行われることができる。その代りにユーザは予めロードされたイメージファイルを有するオプションを提供されることができる。もしもこのオプションを受けたならば、プレイヤープログラムは、オーディオ再生に先立って、リストされた全てのイメージファイルをダウンロードしてそれらをローカルキャッシュ中に記憶する。
【００６９】
同じ原理は、ビデオ記録または、もちろん添付された音響トラックを有するビデオ記録の受渡しに適用できる。簡単なバージョンでは、ただ１つの記録しかない場合に、システムはオーディオバージョンのみのときとは異なり、ファイルはビデオファイルであり（例えばＨ．２６１またはＭＰＥＧフォーマット）、プイヤープログラムはビデオデコーダを伴っている。ファイルをサブファイルに区分する方法は変更されない。
【００７０】
オーディオの場合のように、すでに説明したように制御機構により選択された異なったデータレートに対応する２以上の記録が存在する可能性がある。また、高速順方向または高速逆方向のような異なった再生モードに対応する付加的な記録を行うことができ、それらはすでに説明したようにユーザの制御装置の拡張によって選択されることができる。再び、ファイルおよびディレクトリネームの系統的なコンベンションにしたがうことができ、プイヤープログラムは、例えばサブファイルアドレスを訂正することによって高速順方向命令に応答することができる。
【００７１】
しかしながら、ビデオ記録の受渡しは、スイッチングまたはジャンプが許容されるならばファイル区分に対するさらに別の関係を有する。画像の各フレームが独立に符号化される記録の場合には、サブファイルが画像のフレームの全数を含んでいることで十分である。しかしながら、インターフレーム技術を含む圧縮が使用されている場合には、状態はもっと複雑になる。そのようなシステムの幾つかは（例えばＭＰＥＧ標準方式）独立に符号化されたフレームの混合したもの（“イントラフレーム”）および予測された符号化されたフレームを発生し、この場合には各サブファイルはイントラフレームで開始されることが好ましい。
【００７２】
頻繁で規則的なイントラフレームの含有に対して与えられていないＩＴＵ Ｈ．２６１標準方式のようなインターフレーム符号化システムの場合にはこれは可能ではない。これは例としてレートスイッチングを採用しているために、低いビットレート記録のサブファイルｎ＋１が後続する高いビットレート記録のサブファイルｎをリクエストした場合に、低いビットレートサブファイルの最初のフレームは低いビットレート記録のサブファイルｎの最後にデコードされたフレームを使用してインターフレームベースで符号化されるであろう。ちろん端末は勝手に処分はできない。それは高いビットレート記録のサブファイルｎ最後にデコードされたフレームを有している。したがってデコーダの重大なミストラッキングが発生する。
【００７３】
正常の再生と高速再生のモード切換えの場合には、実際の状態は少し異なっている。例えば正常な速度の５倍の高速順方向再生において、５番目毎のフレームだけを符号化する。その結果として、インターフレーム相関は著しく減少され、インターフレーム符号化は魅力的ではなくなり、そのため一般的にイントラフレームとして高速再生シーケンスを符号化することが望まれている。正常速度から高速への切換えはイントラフレームが困難なくデコードされるので問題を生じない。しかしながら、正常再生へ戻るときミストラッキングの問題が再び発生する。それは端末は先行するフレームでは有していない予測された符号化されたフレームを与えられるからである。
【００７４】
いずれの場合にも、問題は国際特許出願ＷＯ９８／２６６０４号（米国特許６００２４４０号として発行）に記載された原理を使用することによって解決することができる。これは先行するシーケンスの最後のフレームと新しいシーケンスの最初のフレームとの間のギャップをブリッジする中間のフレームシーケンスを符号化することを含んでいる。
【００７５】
この動作について高速順方向動作（高速まき戻しは類似しているが逆方向である）について説明する。この例では９分のビデオシーケンスがＨ．２６１標準方式にしたがって９６ｋビット／秒で符号化されており、Ｈ．２６１のインフラフレームで全体的に正常なレートの５倍の速度であり、結果的に得られたファイルは４秒のサブファイルに区分されていると仮定する。したがって４秒はもとのビデオ信号の期間と呼ばれ、高速順方向再生時間ではない。上述した使用に類似したネーミングコンベンションにしたがってサブファイルは次の表で示される。
【００７６】
【表６】
Figure 0004087706
ここで、“ネーム”は特定の記録を識別するための名前であり、“ｘ１”は正常なレートを示し、“ｘ５”は正常なレートの５倍を示す。すなわち高速順方向レートである。
【００７７】
正常速度の再生から高速順方向再生へ切換えるためにはプレイヤープログラムをポイントへのサブファイルアドレスを高速順方向再生シーケンスへ変更することだけが必要である。例えば、
Figure 0004087706
正常速度の再生へ戻すように切換えるために、ブリッジングシーケンスを構成するために、各可能な転移に対してブリッジサブファイルを構成することが必要である。前述の国際特許出願明細書に記載されているように、一般にブリッジングに対しては３または４フレームのシーケンスで十分であり、それ故、実行する簡単な方法は４フレーム期間だけのブリッジングサブファイルを構成することである。例えば、
Figure 0004087706
それ故、切換えは次のような１連のリクエストによって行われる。
【００７８】
Figure 0004087706
ブリッジングサブファイルは次のようにして生成される。
・高速順方向シーケンスをデコードしてサブファイル９９の最後のフレームのデコードされたバージョンを得る（毎秒２５フレームにおいて、これはもとのビデオ信号のフレーム100,000 である）。
【００７９】
・正常のシーケンスをデコードしてサブファイル１００の最初のフレームのデコードされたバージョンを得る（すなわちフレーム100,001 である）。最初の基準フレームとしてこの１フレームをデコードされたフレーム100,000 に基づいてＨ．２６１インターフレームコード化を使用して４回再符号化する。
【００８０】
・したがって、デコーダが高速順方向サブファイルをデコードしたとき、それに続いてサブファイルをブリッジすることによりフレーム100,000 が正確に再構成され、正常の（ｘ１）フレームをデコードする準備ができる。付随的に、この手順で同じフレームを複数回符号化する理由は、１度しか行わないとＨ．２６１の量的特性により生成される画像の品質が貧弱になるからである。
【００８１】
正確に同じプロセスがレート切換えに対しても使用できる（この場合にはサブファイルのブリッジングは両方向に必要であるが）。しかしながら、説明したようにブリッジングサブファイルは４フレーム期間、すなわち（毎秒２５フレームで）１６０ミリ秒のあいだ画像を凍結する。高速再生から正常再生への切換えにおいて、これは許容可能である。事実この時点でバッファのクリアを選択する可能性がある。それはレート切換えでは許容可能であっても可能でなくてもよい。それ故、代りに４秒ブリッジングシーケンスを構成してもよい。
【００８２】
リクエストシリーズは次のように表される。
【００８３】
Figure 0004087706
ブリッジングサブファイルはその場合に、基準フレームとしてデコードされた９６ｋビット／秒のフレーム100,000 によりスタートしてデコードされた４倍の１２８ｋビット／秒シーケンスの第５のデコードされたフレームを記録するか、或いは基準フレームとしてデコードされた９６ｋビット／秒のフレーム100,000 によりスタートしてデコードされた１２８ｋビット／秒シーケンスの第１、第４フレームを符号化するかのいずれかによって構成されることができる。両方の場合においてブリッジングサブファイルの残りの９６フレームは１２８ｋビット／秒サブファイルのコピーである。
【００８４】
受渡されるファイルは“記録”と呼ばれる。しかしながら、オーディオまたはビデオシーケンス全体が符号化されなければならないこと、または受渡しが開始される前に存在していることは必要ではない。すなわち、コンピュータはライブフィードを受信し、それを選択された符号化方式を使用して符号化してサブファイルを生成し、それらをサーバへアップロードし、それにより幾つかのサブファイルがサーバ上に存在すれば受渡しが開始される。
【００８５】
この受渡しシステムの１つの応用は、図５に示されているような音声メッセージシステムに対するものであり、それにおいては、サーパ1 、ネットワーク2 、および端末3 が示されている。音声メッセージインターフェース4 は例えば公共電話ネットワーク（ＰＳＴＮ）5 を介して電話呼を受信するように機能し、メッセージを記録し、符号化してそれをサブファイルに区分し、それらをサーパ1 へアップロードし、そこにおいてそれらは前述したようにアクセスされる。その代りに第２のインターフェース6 が設けられて、端末3 と同様に動作するが、遠隔の電話5 によってＰＳＴＮを介して遠隔的に制御されて、それに中継されたオーディオ信号が送信されてもよい。
【００８６】
同じシステムはライブオーディオ（またはビデオ）フィードに対して使用されることができる。それは意味的には依然として“記録された”であり、主要な相違点は受渡し、および再生が記録が終了する前に開始することである。もっとも当然ながら、固有の遅延が存在し、それにおいては少なくとも１サブファイルが記録されてサーバ1 にロードされるまで待機しなければならない。
【００８７】
システムは上述のように動作し、最初に再生がスタートすることを除いては全く満足すべきものであり、一方ユーザが最も望可能性があることは今スタートすること、すなわち、最も最近に生成されたサブファイルを有することである。
【００８８】
長いオーディオシーケンスに対して記憶量を節約するために古いサブファイルを消去することを選択できる。連続的なフィードにより（すなわち２４時間１日）これは不可避であり、さらに、サブファイルネームを再使用し（我々のプロトタイプのシステムでは、000000.bin乃至009768.binを使用し、それから000000.binでスタートする）、それによって古いサブファイルが一定して新しいもので重書きされる必要がある。最も最近のサブファイルによりスタートする受渡しを確実にする方法は、適当なサブファイルをリクエストすることによってスタートするためにプレイヤープログラムに命令する余分の命令をインデックスファイル中に含めることである。しかしながら、これはそのインデックスファイルが非常に頻繁に変更されなければならない欠点が有り、理想的には毎回新しいサブファイルが生成される都度行われなければならない。それ故、本発明ではプレイヤープログラムがサーバを走査する方法は次のようにしてスタートするサブファイルを発見する。インデックスファイルでは、モードパラメータは“ライブ”に設定され、プレイヤープログラムをトリガーしてこの方法を開始させる。ＬＦＩはサブファイルの最大数を示すように設定され、それは例えば9768として記憶される。この方法は次のようなステップを含み、（通常のように）各サブファイルの“最後に変更した”時間および日付が決定されたことを予想する。ＨＴＴＰプロトコルを使用するとき、これはヘッドリクエストを使用して達成されることができ、それはリクエストされたサブファイルの受渡しを生じるのではなく、サブファイルがサーバに書込まれた時間を示すヘッダ情報だけを生成し、或いはサブファイルが存在しない場合にはゼロを生成する。
【００８９】
この時間はＧｅｔＵＲＬ（ＬｉｖｅＩｎｄｅｘ）として以下に記載され、ここでＬｉｖｅＩｎｄｅｘは問題としているサブファイルのシーケンス番号である。コメントに先行して“//”が付けられている。
【００９０】
【表７】
Figure 0004087706
ＬｉｖｅＩｎｄｅｘを発見したとき、Ｔp （プレイアウト時間）に慎重にステップバックし、そこからオーディオバッファを満たすためにリクエストを行うことを開始する。再生は正常の方法で開始されることができる。
【００９１】
記録が実際に完了すると、インデックスファイルは所望ならば変更されてモードを“記録された”に設定し、任意の長さのパラメータにすることができる。
【００９２】
所望ならば、プレイヤープログラムは周期的に検査されてインデックスファイルが“ライブ”から“記録された”に変化したかどうかを観察し、変化していれば、“記録された”モード再生に切換える。
【００９３】
もっと簡単で、ずっと速い“最後のサブファイル”の識別方法について説明する。まず、単一の連続的なサブファイルナンバリングシーケンスと仮定する。
【００９４】
１．端末は最初のサブファイル（例えば000000.bin）に対してヘッドリクエストを発行する。
【００９５】
２．サーバはこのファイルのヘッダを送ることによって応答し、ファイルが最後に変更された日付と時間（ＭＯＤＴＩＭＥ）およびこの応答が送られた日付と時間（ＲＥＰＬＹＴＩＭＥ）が含まれる（これらの両者は標準のhttp. フィールドである）。
【００９６】
３．端末は２つを減算することによって経過時間（ＥＬＴＩＭＥ）を計算し（ＥＬＴＩＭＥ＝ＲＥＰＬＹＴＩＭＥ−ＭＯＤＴＩＭＥ）、これをサブファイルの再生時間（この例では４秒）で割算することによってＬＩＶＥＩＮＤＥＸ＝ＥＬＴＩＭＥ／４を得る。
【００９７】
４．端末はこのインデックスを有しているサブファイルのファイルネームを計算する。
【００９８】
５．端末はこのファイルネームによりヘッドリクエストを発行し、必要ならばゼロを受取るまで（ファイルは発見されない）、次のファイルネームのヘッドリクエストを発行し、“現在のサブファイル”として発見された最後のサブファイルに関するものである。
【００９９】
６．端末はファイルのリクエストを開始し、前に示したフローチャートのポイントＪ１でスタートする。
【０１００】
この方法は循環式にナンバーを付けたサブファイルに対して上記したものよりかなり速い。古いサブファイルは消去されてもよく、スタートサブファイルが維持されている限り記憶要求を減少させる。しかしながら、この方法はファイルネームの再使用に適合するように変更できるが、次のことが要求される。
（ｉ）スタートのサブファイルネーム（例えば00000000.bin）は再使用せず、そのため常にステップ２でヘッダ情報を供給するために利用できる。したがって、009768.binでラップすることにより、サブファイル009768.binはサブファイル000001.binによって後続される。
（ii）ステップ３で計算されたＬＩＶＥＩＮＤＥＸはモジュロ9768を取る（すなわちＥＬＴＩＭＥ／４が9768によって割算されたときの剰余）。
（iii)サブファイルの消去は常に新しいサブファイルの生成に導き、そのため最も新しいサブファイルと最も古い消されていないサブファイルとの間にいくつかのファイルネームは存在しない。そのためにステップ５で期待される“ファイルは発見されない”応答が生じる。 記録動作よりも少し速い、または少し遅い再生動作が行われる危険性が存在する可能性がある。前者に対して保護するために、プレイヤープログラムは以前のものよりも遅い時間でマークされたか否かを確認するために受信する各サブファイルを検査し、もしも、サブファイルが廃棄されていなければ、繰返してリクエストし（恐らく３回）、それに続いてこれらのリクエストが成功しないか否かインデックスファイルを検査する。
【０１０１】
もしも、プレーイングが記録プロセスの後であるならば、現在リクエストされているものよりもさらに最近サブファイルの可なりの数が存在したことについてサーバを検査するプレイヤープログラムによって識別され、そのようなサブファイルが存在していれば、例えば少量のデータを規則的に廃棄することによって“キャッチアップ”プロセスが開始される。
【図面の簡単な説明】
【図１】 記載されたシステムの全体のアーキテクチャを示す概略図。
【図２】 そのようなシステム端末のブロック図。
【図３】 典型的なインデックスファイルの内容を示す図。
【図４】 サブファイル生成の変形された方法を示すタイミング図。
【図５】 変形されたアーキテクチャを示す図。

Claims (10)

  1. オーディオまたはビデオマテリアルの連続する時間的部分を表している１組のファイルとして遠隔のサーバに記憶されているオーディオまたはビデオマテリアルを遠隔のサーバから受信して再生し、
    前記遠隔サーバと通信するための通信インターフェースと、
    前記通信インターフェースからファイルを受取るためのバッファと、
    前記バッファの内容を再生する手段とを具備している端末において、
    端末はさらに、
    バッファの状態に応じて動作し、サーバにリクエストしようとするファイルのアドレスを決定し、前記バッファに補充される前記リクエストしようとするファイルの前記決定されたアドレスを含むリクエストメッセージを生成してサーバに送信するために通信インターフェースに出力するように構成されている制御手段を具備していることを特徴とする端末。
  2. 最も最近のファイルを識別するために一連のトライアルリクエストを発生して識別されたサブファイルによりデコードのスタートを開始させるように動作する手段を含んでいる請求項１記載の端末。
  3. それぞれのセットが異なった配信モードに対応している複数のファイルのセットを記憶するサーバにより使用するために、端末はリクエストメッセージに続いて、そのセットと異なる、関係する直接先行するセットからファイルをリクエストすることによってモードスイッチングを行うように動作する手段を備え、
    ビデオ記録の形態で前記マテリアルを記憶しているサーバにより使用するために、前記ファイルの少なくとも幾つかは少なくとも幾つかのフレームに対してインターフレーム符号化を使用して符号化され、
    端末は異なったセットからのファイルに対してリクエストメッセージを生成する前にデコーダ追跡の補正のためにファイルに対するリクエストメッセージを発生するように構成されている請求項１または２記載の端末。
  4. ファイルは予め定められたアルゴリズムにしたがってアドレスを割当てられ、端末は前記リクエストメッセージに対して前記アルゴリズムにしたがってリクエストメッセージ中に含まれるアドレスを計算するように動作する手段を含んでいる請求項１乃至３のいずれか１項記載の端末。
  5. デジタル符号化されたオーディオまたはビデオマテリアルを送信する方法において、
    前記マテリアルの連続する時間的部分をそれぞれ表している複数のディスクリートなファイルにマテリアルを分割し、
    それらのファイルを第１の局において記憶し、
    第２の局において、
    ａ）第１の局に記憶されているファイルを要求するために要求しようとしているファイルのアドレスを決定し、
    ｂ）ファイルの連続するそれぞれに対するリクエストをそれぞれのファイルの前記決定されたアドレスと共に第１の局に送信し、
    ｃ）それに応答して第１の局から送られてきたファイルを受信し、
    ｄ）マテリアルの再生のためにファイルをデコードする送信方法。
  6. 第１の局から送られてきたマテリアルは第２の局のバッファ中に記憶され、リクエストメッセージは前記バッファの状態に応じて生成される請求項５記載の方法。
  7. 第２の局において、第１のファイルに対するトライアルリクエストを生成し、第１のファイルの発生時間を表しているデータを含んでいる回答を第１の局から受信し、これらのデータから第１の局における最も最近のファイルの評価された識別値を推定する請求項５または６記載の方法。
  8. 第２の局において、第１の局における最も最近のファイルを識別するために一連のトライアルリクエストを生成し、識別されたファイルにより前記デコードをスタートさせる請求項５乃至７のいずれか１項記載の方法。
  9. 複数のファイルのセットを記憶し、それらのセットはそれぞれ異なった配信モードに対応しており、第２の局において、リクエストメッセージに続いて、そのセットとは異なった、直接先行する関係するセットからファイルをリクエストすることによってモードスイッチングを行い、
    前記マテリアルはビデオ記録の形態であり、符号化されている前記ファイルの幾つかは少なくともその幾つかのフレームに対してインターフレーム符号化を使用して符号化され、第２の局において、異なったセットからファイルに対するリクエストメッセージを発生する前に、デコーダのトラッキングの補正のためにファイルに対するリクエストメッセージを発生する請求項５乃至８のいずれか１項記載の方法。
  10. ファイルは予め定められたアルゴリズムにしたがってアドレスを割当てられ、第２の局においては前記アルゴリズムにしたがってリクエストメッセージ中に含ませるためのアドレスを計算する請求項５乃至９のいずれか１項記載の方法。
JP2002550714A 2000-12-15 2001-12-14 オーディオおよび、またはビデオマテリアルの送信および受信 Expired - Lifetime JP4087706B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
GBGB0030706.6A GB0030706D0 (en) 2000-12-15 2000-12-15 Delivery of audio and or video material
GB0108094A GB0108094D0 (en) 2001-03-30 2001-03-30 Delivery of audio and or video material
PCT/GB2001/005090 WO2002049342A1 (en) 2000-12-15 2001-11-19 Delivery of audio and/or video material
PCT/GB2001/005543 WO2002049343A1 (en) 2000-12-15 2001-12-14 Transmission and reception of audio and/or video material

Publications (3)

Publication Number Publication Date
JP2004516717A JP2004516717A (ja) 2004-06-03
JP2004516717A5 JP2004516717A5 (ja) 2005-12-22
JP4087706B2 true JP4087706B2 (ja) 2008-05-21

Family

ID=27256012

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2002550714A Expired - Lifetime JP4087706B2 (ja) 2000-12-15 2001-12-14 オーディオおよび、またはビデオマテリアルの送信および受信

Country Status (5)

Country Link
EP (1) EP1342363B9 (ja)
JP (1) JP4087706B2 (ja)
AU (2) AU2092702A (ja)
CA (1) CA2429827C (ja)
WO (1) WO2002049343A1 (ja)

Families Citing this family (45)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
SE524679C2 (sv) * 2002-02-15 2004-09-14 Ericsson Telefon Ab L M System för broadcast/multicast-utsändning av datainformation emot en lokal del av ett trådlöst nät
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
JP2006501711A (ja) * 2002-09-25 2006-01-12 コーニンクレッカ　フィリップス　エレクトロニクス　エヌ　ヴィ ストリーミングセッションを管理する通信システム及び方法
CN100539439C (zh) 2002-10-05 2009-09-09 数字方敦股份有限公司 连锁反应码的系统编码和解码系统和方法
GB2395387B (en) * 2002-11-13 2005-02-16 Motorola Inc Video streaming device and method of control for switchable video streams
GB0306973D0 (en) 2003-03-26 2003-04-30 British Telecomm Transmitting video
JP2007528044A (ja) * 2003-07-04 2007-10-04 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ 配信ネットワークを介してブロードキャスト・マルチメディア・コンテンツをダウンロードする方法
CN1898962A (zh) * 2003-12-22 2007-01-17 皇家飞利浦电子股份有限公司 通过适配编码特性以传送内容的方法
GB0406901D0 (en) 2004-03-26 2004-04-28 British Telecomm Transmitting recorded material
US7818444B2 (en) 2004-04-30 2010-10-19 Move Networks, Inc. Apparatus, system, and method for multi-bitrate content streaming
CN101019326B (zh) 2004-05-07 2013-02-27 数字方敦股份有限公司 文件下载和流系统
AU2007236534B2 (en) * 2006-02-13 2012-09-06 Vividas Technologies Pty Ltd Method, system and software product for streaming content
US9136983B2 (en) 2006-02-13 2015-09-15 Digital Fountain, Inc. Streaming and buffering using variable FEC overhead and protection periods
US9270414B2 (en) 2006-02-21 2016-02-23 Digital Fountain, Inc. Multiple-field based code generator and decoder for communications systems
WO2007134196A2 (en) 2006-05-10 2007-11-22 Digital Fountain, Inc. Code generator and decoder using hybrid codes
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US9419749B2 (en) 2009-08-19 2016-08-16 Qualcomm Incorporated Methods and apparatus employing FEC codes with permanent inactivation of symbols for encoding and decoding processes
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
EP2203836A4 (en) 2007-09-12 2014-11-05 Digital Fountain Inc GENERATING AND COMMUNICATING SOURCE IDENTIFICATION INFORMATION TO ENABLE RELIABLE COMMUNICATIONS
EP2101503A1 (en) 2008-03-11 2009-09-16 British Telecommunications Public Limited Company Video coding
EP2200319A1 (en) 2008-12-10 2010-06-23 BRITISH TELECOMMUNICATIONS public limited company Multiplexed video streaming
EP2219342A1 (en) 2009-02-12 2010-08-18 BRITISH TELECOMMUNICATIONS public limited company Bandwidth allocation control in multiple video streaming
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US9917874B2 (en) 2009-09-22 2018-03-13 Qualcomm Incorporated Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
KR101786051B1 (ko) 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 제공 방법 및 장치와 데이터 수신 방법 및 장치
KR101750048B1 (ko) 2009-11-13 2017-07-03 삼성전자주식회사 변속 재생 서비스 제공 방법 및 장치
KR101777347B1 (ko) 2009-11-13 2017-09-11 삼성전자주식회사 부분화에 기초한 적응적인 스트리밍 방법 및 장치
KR101750049B1 (ko) 2009-11-13 2017-06-22 삼성전자주식회사 적응적인 스트리밍 방법 및 장치
KR101737084B1 (ko) 2009-12-07 2017-05-17 삼성전자주식회사 메인 콘텐트에 다른 콘텐트를 삽입하여 스트리밍하는 방법 및 장치
KR101777348B1 (ko) 2010-02-23 2017-09-11 삼성전자주식회사 데이터 전송 방법 및 장치와 데이터 수신 방법 및 장치
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
EP2410743A1 (en) * 2010-07-23 2012-01-25 Alcatel Lucent Method for transferring video chunks, server entity, client entity and intermediate network entity realizing such a method
US9319448B2 (en) 2010-08-10 2016-04-19 Qualcomm Incorporated Trick modes for network streaming of coded multimedia data
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US9253233B2 (en) 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US10021438B2 (en) 2015-12-09 2018-07-10 Comcast Cable Communications, Llc Synchronizing playback of segmented video content across multiple video playback devices
CN107480181B (zh) 2017-07-05 2020-11-24 百度在线网络技术（北京）有限公司 音频播放方法、装置、设备及服务器

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5610841A (en) * 1993-09-30 1997-03-11 Matsushita Electric Industrial Co., Ltd. Video server
CA2140850C (en) 1994-02-24 1999-09-21 Howard Paul Katseff Networked system for display of multimedia presentations
US6181867B1 (en) * 1995-06-07 2001-01-30 Intervu, Inc. Video storage and retrieval system
JP2000515692A (ja) * 1995-12-12 2000-11-21 ザ ボード オブ トラスティーズ オブ ザ ユニバーシティー オブ イリノイ 性質限定システム上でリアルタイムの動画及び音声情報を伝送し読み出すための方法及び装置
US6065050A (en) * 1996-06-05 2000-05-16 Sun Microsystems, Inc. System and method for indexing between trick play and normal play video streams in a video delivery system
US6118790A (en) * 1996-06-19 2000-09-12 Microsoft Corporation Audio server system for an unreliable network
EP0974110A2 (en) * 1997-10-30 2000-01-26 Koninklijke Philips Electronics N.V. Method for coding a presentation
EP1217557A3 (en) 1997-12-24 2005-11-02 Avid Technology, Inc. Computer system and method for transferring high bandwith streams of data from files which are segmented across multiple storage units
WO2000042773A1 (en) * 1999-01-19 2000-07-20 Sony Electronics Inc. System and method for implementing interactive video

Also Published As

Publication number Publication date
AU2092702A (en) 2002-06-24
EP1342363B1 (en) 2010-04-14
CA2429827A1 (en) 2002-06-20
EP1342363B9 (en) 2012-09-12
EP1342363A1 (en) 2003-09-10
JP2004516717A (ja) 2004-06-03
WO2002049343A1 (en) 2002-06-20
CA2429827C (en) 2009-08-25
AU2002220927B2 (en) 2006-03-16

Similar Documents

Publication Publication Date Title
JP4087706B2 (ja) オーディオおよび、またはビデオマテリアルの送信および受信
US7447791B2 (en) Transmission and reception of audio and/or video material
JP4270868B2 (ja) オーディオ信号の符号化
AU2002220927A1 (en) Transmission and reception of audio and/or video material
US10298639B2 (en) Streaming media delivery system
AU2002215122A1 (en) Encoding audio signals
EP2475149B1 (en) Method for streaming multimedia data over a non-streaming protocol
US8639832B2 (en) Variant streams for real-time or near real-time streaming to provide failover protection
US8762351B2 (en) Real-time or near real-time streaming with compressed playlists
JP4882441B2 (ja) 配信サーバ装置、クライアント装置、及びそれらに用いるプログラム
JP5135147B2 (ja) 動画ファイル送信サーバおよびその動作制御方法
WO2002049342A1 (en) Delivery of audio and/or video material
JP2005121693A (ja) ストリーミング配信システム及びストリーミング配信方法
AU2013202695B2 (en) Real-time or near real-time streaming
JP2004023548A (ja) ストリーミングサービスの配信レート変更方法及びストリーム配信サーバ並びにストリーム配信プログラム及びその情報記録媒体

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20041210

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20041210

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20061019

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20061114

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20070214

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20070221

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070514

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: 20080122

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080221

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

Free format text: PAYMENT UNTIL: 20110228

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4087706

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

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

Free format text: PAYMENT UNTIL: 20120229

Year of fee payment: 4

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20130228

Year of fee payment: 5

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

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

Free format text: PAYMENT UNTIL: 20140228

Year of fee payment: 6

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term