JP2006525730A - プログラムの冗長伝送 - Google Patents

プログラムの冗長伝送 Download PDF

Info

Publication number
JP2006525730A
JP2006525730A JP2006506922A JP2006506922A JP2006525730A JP 2006525730 A JP2006525730 A JP 2006525730A JP 2006506922 A JP2006506922 A JP 2006506922A JP 2006506922 A JP2006506922 A JP 2006506922A JP 2006525730 A JP2006525730 A JP 2006525730A
Authority
JP
Japan
Prior art keywords
sequence
blocks
block
program
time interval
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.)
Withdrawn
Application number
JP2006506922A
Other languages
English (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.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
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 Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Publication of JP2006525730A publication Critical patent/JP2006525730A/ja
Withdrawn 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/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
    • 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/70—Media network packetisation
    • 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/1066—Session management
    • H04L65/1101—Session protocols
    • 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/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • 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/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • 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
    • 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/426—Internal components of the client ; Characteristics thereof
    • H04N21/42607—Internal components of the client ; Characteristics thereof for processing the incoming bitstream
    • H04N21/4263—Internal components of the client ; Characteristics thereof for processing the incoming bitstream involving specific tuning arrangements, e.g. two tuners
    • 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/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/4402—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 reformatting operations of video signals for household redistribution, storage or real-time display
    • H04N21/440245—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 reformatting operations of video signals for household redistribution, storage or real-time display the reformatting operation being performed only on part of the stream, e.g. a region of the image or a time segment
    • 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/45—Management operations performed by the client for facilitating the reception of or the interaction with the content or administrating data related to the end-user or to the client device itself, e.g. learning user preferences for recommending movies, resolving scheduling conflicts
    • H04N21/462—Content or additional data management, e.g. creating a master electronic program guide from data received from the Internet and a Head-end, controlling the complexity of a video stream by scaling the resolution or bit-rate based on the client capabilities
    • H04N21/4622—Retrieving content or additional data from different sources, e.g. from a broadcast channel and the Internet

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Databases & Information Systems (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Compression Or Coding Systems Of Tv Signals (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)

Abstract

圧縮システム110は、対応のブロックの第１及び第２のシーケンスにプログラムを圧縮する。送信システム120は、所定のリアルタイム配信スケジュールに従って第２のシーケンスのブロックを送信する。送信システムは、第２のシーケンスの対応のブロックより早く第１のシーケンスのブロックを送信する。受信機135は、第２のシーケンス及び第１のシーケンスのブロックを受信する。バッファ140は、配信スケジュールがまだ終了していない第２のシーケンスのブロックに対応する第１のシーケンスのブロックを一時的に格納する。コントローラ169は、配信スケジュールの時間間隔毎に、第２のシーケンスのブロックが時間間隔でうまく受信された場合にこのようなブロックの表示を出力155に指示し、又は第２のシーケンスのブロックが時間間隔でうまく受信されなかった場合にバッファに格納されている対応のブロックの表示を出力155に指示する。

Description

本発明は、コンテンツ部分のシーケンスを有するプログラムのストリーム配信用の配信システムに関する。
デジタルコンテンツのストリーム配信は、特にオーディオ及び／又はビデオ（A/V）プログラムでは、急速にプログラムの配信の主要な形式になってきている。配信システムは、例えば衛星放送、デジタル地上波放送又はデジタルケーブル放送に基づくデジタル放送システムでもよい。このようなデジタル放送システム及び受信機は、例えばヨーロッパDVB/MHP（Multi-media Home Platform）及びUS DASEプラットフォームの形式で定められている。
また、インターネットも、急速にオーディオ／ビデオプログラムのストリーム配信用の主な配信システムになってきている。インターネットは、複数の無線媒体を含み、多数の媒体をサポートする。特に、移動体装置へのストリーミングが注目を集めている。
ハードディスクやCDやDVDやBlue-RayやフラッシュメモリやMRAMやFRAM等のような低コストの高容量記憶システムの更なる可用性で、家庭内の配信システムも利用可能になってきている。例えば、ユニバーサル・プラグ・アンド・プレイ（UPnP：Universal Plug and Play）アーキテクチャでは、メディアサーバが記述されている。これらの標準の現在公的に利用可能なバージョンは、以下の通りである。
−2000年6月8日のUniversal Plug and Play (UPnP) Version 1.0
−2002年6月12日のUPnP Audio/Video (A/V) Architecture Version 0.83 for UPnP Version 1.0 Status: Preliminary Design (TPD)、未完了
−2002年6月25日のMediaServer:1 Device Template Version 1.01, for Universal Plug and Play Version 1.0, Status: Standardized DCP
UPnP準拠のネットワークのメディアサーバは、ネットワークの他の装置がアクセスしようとする様々なコンテンツ（例えば、音楽、ビデオ、静止画像等）を有し得る。ユーザは、メディアサーバに格納されているオブジェクトを選択し、それが適切な処理装置（例えば、音楽オブジェクトではオーディオプレイヤ、ビデオコンテンツではTV、静止画像では電子写真フレーム（Electronic Picture Frame））で“再生”されるようにすることができる。UPnP A/Vアーキテクチャにより、装置がエンターテインメントコンテンツについての異なる種類のフォーマット（MPEG2、MPEG4、DIVX、JPEG、JPEG2000、MP3、ATRAC、Windows(登録商標) Media Architecture（WMA）、bitmaps（BMP）、NTSC、PAL、ATSC等）と、複数の種類の伝送プロトコル（IEC-61883/IEEE-1394、HTTP GET、RTP、HTTP PUT/POST、TCP/IP等）とをサポートすることが可能になる。メディアサーバの例には、VCRやCDプレイヤやDVDプレイヤやオーディオテーププレイヤや静止画カメラやビデオカメラやラジオやTVチューナやセットトップボックスのような従来型の装置が含まれる。メディアサーバの更なる例にはまた、MP3サーバやパーソナルビデオレコーダ（PVR）やPC等のホームメディアサーバのような新しいデジタル装置が含まれる。
前述の配信システムの全ては、プログラム（タイトルとも呼ばれる）のストリーム配信をサポートする。プログラムは、例えば音楽や主言語の解説のようなオーディオストリームを有してもよい。更なるオーディオストリームもまた、例えば異なる言語の更なる解説のように、プログラムに存在してもよい。プログラムはまた、ビデオストリームを有してもよい（例えばマルチカメラのプログラムでは１つより多くてもよい）。一般的に、プログラムは、例えばMPEG2、MPEG4又はDIVX形式で圧縮されている。ストリーム配信とは、（圧縮された）プログラムの連続するコンテンツ部分が、通常では配信での限られたジッタで連続ストリームのブロックとして伝送されることを意味する。ブロックは、リアルタイム解凍を可能にするレートで供給され、受信機に含まれ又は受信機に取り付けられた処理装置により処理される。受信機は、配信のジッタを補うために、数ブロックを格納する小さいバッファを一般的に有する。配信が中断された場合（１つ以上のブロックが受信されない場合又は訂正可能なエラーを有している場合）、処理も中断される（又は中断が非常に短い場合には少なくとも劣化する）。ストリームが処理装置へのリアルタイム配信を目的としているため、伝送におけるブロックの損失を訂正する時間がない（また、使用されるネットワーキングプロトコルに対策がない）。
ネットワークの輻輳は、パケットの一時的な損失の主な要因である。更に、多数の配信システムは、無線配信に基づき、又は無線配信を可能にする。このことは、ストリームブロックの一時的な損失の可能性を増加させる。特に、車内デジタルラジオ／ビデオのような移動体処理装置は、例えば受信がビルやトンネル等により一時的に中断された場合に、損失を受ける。同じことが、内蔵の移動体受信機能を備えた携帯電話やPDA（Personal Digital Assistant）のようなハンドヘルド装置にも当てはまる。また、例えばIEEE802.11ファミリーのプロトコルに基づいた家庭内無線配信システムが重要になると予想される。これらのシステムはまた、配信の一時的な中断を非常に受けやすい（例えば電子レンジの起動は一時的な中断を引き起こし、それは異なる受信チャネル又はモードに切り替えることで回復され得る）。多数の前述の中断／障害は、受信の中断を処理するためではなく、主に受信ジッタを処理するために使用されている現在使用中の受信バッファで補われ得ない。
受信での１つ以上の中断をより良く処理することができるプログラムのストリーム配信用の配信システムを提供することが、本発明の目的である。
本発明の目的を満たすため、コンテンツ部分のシーケンスを有するプログラムのストリーム配信用の配信システムは、
プログラムをブロックの第１のシーケンスとブロックの第２のシーケンスとに圧縮し、第１及び第２のシーケンスのブロック間の対応は、同一視可能なプログラムの同じコンテンツ部分に関係する第１のシーケンス及び第２のシーケンスのブロックにより定められる圧縮システムと、
所定のリアルタイム配信スケジュールの各時間間隔に従って受信システムに第２のシーケンスのブロックを配信し、受信システムにブロックの第１のシーケンスを配信し、第１のシーケンスのブロックは、第２のシーケンスの対応のブロックより早く送信される送信システムと、
ブロックの第２のシーケンスをストリーム受信し、ブロックの第１のシーケンスを受信する受信機と、配信スケジュールが終了していない第２のシーケンスのブロックに対応するブロックの第１のシーケンスのブロックを一時的に格納するバッファと、プログラムのコンテンツ部分を供給する出力と、配信スケジュールの時間間隔毎に、第２のシーケンスのブロックが時間間隔でうまく受信された場合にこのようなブロックの表示を出力に指示し、又は第２のシーケンスのブロックが時間間隔でうまく受信されなかった場合にバッファに格納されている対応のブロックの表示を出力に指示するように動作可能なコントローラとを有する受信システムとを有する。
本発明によれば、プログラムは、ブロックの第１及び第２のシーケンスの形式で、受信システムに２回配信される。通常の動作中では、受信システムは、処理装置のような宛先装置に第２のシーケンスをリアルタイムに提供する。第２のシーケンスはストリーム伝送を用いて伝送される。双方のシーケンスの送信は、相互に時間シフトされている。第１のシーケンスは少なくとも１ブロック先に送信される。第１のシーケンスはフォールバックとして動作する。第２のシーケンスのストリーム受信が１つ以上のブロックについて成功しなかった場合（例えば、第２のシーケンスの１つ以上のブロックがリアルタイムに受信されない場合及びされる予定にない場合、又は欠落した場合）、受信システムは、第１のシーケンスのブロックの表示をその出力に供給する。このため、第１のシーケンスの１つ以上のブロックは、圧縮又は解凍した形式で受信システムに一時的にバッファされる。
従属項２に記載された好ましい実施例では、第１のシーケンスは高度の圧縮（すなわち低ビットレート）を有する。このように、固定サイズのバッファで、第２のシーケンスの受信の長期間の中断（又は完全な損失）が埋められ得る。その他に、完全品質のストリームがバッファされるより小さいバッファが使用され得る。一般的に、従来技術のシステムは受信の中断中に全く信号を処理することができない。本発明によるシステムでは、低品質であっても、このような中断の間にプログラムの処理は継続する。
従属項３の手段によれば、第１及び第２のシーケンスは、異なる伝送チャネルを使用して伝送される。このように、双方のシーケンスが受信できないという可能性が減少する。第２のシーケンスの受信が中断された場合（例えば第２のストリームの特定のブロックが損失した場合又は欠落した場合）、受信システムは、バッファから対応のブロック（すなわち第１のシーケンスのブロック）を提供する。第１のシーケンスの受信が中断されない場合、バッファは継続して処理されることが可能になり、第２のシーケンスの受信の非常に長い（又は完全な）中断を克服することが可能になる。
従属項４に記載のように、ブロックの第１のシーケンスは、ストリーム（例えば放送）として配信されることが好ましい。衛星又はデジタル地上波放送のように、如何なる適切な形式のストリーミングが使用されてもよい。従属項５に記載のように、双方のシーケンスがストリームされると、シーケンスは同じトランスポートストリームに多重化されてもよい。１つのみのトランスポートストリームが受信に対してユーザにより特定される必要があり、コストを減少させるため（唯一のチューナが必要である）、受信を簡潔にする。
従属項７に記載のように、ブロックの第１のシーケンスはオンデマンドでダウンロードされてもよい。これは、冗長が必要であるか否かを受信システムが決定するような柔軟性のあるシステムを提供する。冗長シーケンスのダウンロードは、ダウンロードシステム（又はそのユーザ）の役目でもよい。
従属項８に記載のように、第２のシーケンスの送信の開始の前に（又は送信の開始段階に）、まずバッファは第１のシーケンスのブロックで充填され、第１のシーケンスの処理ブロックにフォールバックすることが可能になる。プログラムの開始時点で少なくとも最小のフォールバック位置が既に実現されるように、部分的にのみバッファを充填することも可能である。バッファは、何らかの予備の伝送容量を使用することにより、更に次第に充填されてもよい。
従属項９に記載のように、受信システムは、ブロックの第１及び第２のシーケンスのブロックを解凍する解凍器と、実質的にブロックの受信に応じて第２のシーケンスのブロックの解凍を行わせ、実質的に第２のシーケンスの対応のブロックの解凍と同期して第１のシーケンスのブロックの解凍を行わせるように動作可能なコントローラとを有する。従って、第１のシーケンスは第２のシーケンスと同期して解凍され、それにより、例えばビデオフレームのレベルで、第２のシーケンスの処理から第１のシーケンスへの‘シームレス’な切換が実現され得る。消費者電化製品で使用されている多数の解凍器では、まだ解凍されていないストリームへの切換が生じると、顕著な遅延が生じることがある。例えば、MPEG2エンコードストリームでは、Iフレームに依存するフレームが解凍され得る前に、まずIフレームが見つけられて解凍されなければならない。最悪の場合、これは、所望のフレームが利用可能になる一般的に15フレーム前の全グループオブピクチャ（GOP：Group of Picture）をデコードすることを有することがある。ほとんどの解凍器は、１つのフレームを処理するために利用可能な時間間隔でGOPをデコードするように（すなわち、処理より15倍速いデコードをするように）設計されていない。（第２のシーケンスと同期して）第１のシーケンスを常に解凍することにより、（使用されなくても）デコードされたフレームが常に利用可能になる。
本発明の前記及び他の態様は、以下に記載の実施例から明らかであり、実施例を参照して明らかになる
図１は、本発明による好ましい配信システム100のブロック図を示している。１つ以上のプログラムは、デジタル形式で受信機に配信される。基本的には、プログラムは、デジタルストリームとして供給及び処理され得る如何なるコンテンツでもよい。一般的には、プログラムはオーディオ及び／又はビデオを有する。プログラムは冗長形式で配信される。プログラムの主な配信の正確な受信において起こり得るかなりのギャップを克服することができるように、プログラムは、双方の配信の間でかなりの時間シフトを備えて２回配信される。時間シフトは、少なくとも20秒であることが好ましい（以下に詳細に説明するように、送信の開始時に時間シフトはより小さくてもよく、存在しなくてもよい）第１の配信はフォールバックとして動作する。少なくとも主な配信はストリーミングの形式である。ストリーミングプロトコルは周知であり、ここでは更に説明しない。ストリームデジタル配信では、ストリームが例えばMPEG2圧縮を使用して圧縮されることが通常である。このため、システム100は、プログラム105をブロックの主シーケンス（Seq.2と呼ぶ）に圧縮する圧縮器110を有する。基本的には、プログラムを非圧縮形式で提供することも可能であるが、これは送信システムの負荷を増加させるため、通常の場合ではない。フォールバック配信Seq.1は主配信Seq.2より低ビットレートのエンコードで供給されることが好ましい。このように、受信機での記憶装置の要件が低減され、ネットワークの負荷が低減される。このため、同じプログラムは圧縮器110で２回エンコードされ、ブロックの主シーケンスSeq.2とフォールバックシーケンスSeq.1とを提供する。同じ原理が繰り返されてもよいことがわかる。すなわち、（好ましくは更に低ビットレートで更に早い）第３のシーケンスが第１のシーケンスのフォールバックを提供する等である。
基本的には、圧縮器110は、リアルタイムで動作してもよい（すなわち、圧縮器110から供給されるブロックが‘即座に’受信システム130に送信される）。圧縮器は２つのプログラムをリアルタイムでエンコードする機能を有することが好ましい。代替として、それぞれシーケンスの１つを生成するように割り当てられた２つの圧縮器が使用されてもよい。通常は、圧縮はオフライン（すなわち非リアルタイム）に行われる。圧縮シーケンスは、送信前にハードディスクのような記憶装置115に格納される。
圧縮シーケンスは、送信機120を使用して送信される。図面では１つの送信機120及び１つのネットワーク125が図示されている。基本的には、シーケンスは異なる送信機及び／又は異なるネットワークを使用して送信されてもよい。受信システムは受信機135を有する。この場合も同様に、前記のような場合には、シーケンス毎に所望の異なる受信機が使用されてもよい。以下では、１つの送信機と１つのネットワークと１つの受信システムとを備えたシステムに焦点を置く。一般的に、システムは、複数の受信システム（例えば家毎に１つ以上、車毎に１つ等）を有してもよい。シーケンス1は受信機135からバッファ140に供給される。バッファは、例えば循環バッファの形式のFIFOでもよい。それはSeq.1のブロックを格納することができる。その容量は、Seq.1がSeq.2より先になる時間間隔の間にSeq.1について送信されるデータ量に制限され得る。従って、Seq.1がSeq.2より5分先である場合、Seq.1の5分のデータがバッファされなければならない。コントローラ160は、シーケンスのうちどれからブロックが出力155に送信されるかを選択する。このため、コントローラはスイッチ150を制御してもよい。選択は、単にメモリから正しいブロックを選択してそれを出力に導くことにより、ソフトウェアで実行されてもよい。通常は、更なる処理のためにデータはSeq.2から供給される。出力されるべき時点でSeq.2の（正確な）ブロックが利用可能でない場合、その代わりにSeq.1の対応のブロックが出力される。データは処理装置又は記憶装置のような外部装置に供給されてもよい。このような機能はまた、受信システム130に具現されてもよい。任意選択で、出力に供給されるブロックは、出力に供給される前に、解凍器145により解凍されてもよい。解凍器は、バッファ140の後に連続して配置されることが好ましく、それにより、Seq.1のブロックが圧縮形式で格納され、バッファの要件を低減する。以下に詳細に説明するように、Seq.1のデータの何らかの部分は、Seq.2の（正確な）データが利用可能でない場合にSeq.2からSeq.1への‘シームレス’な切換を可能にするために、事前に解凍される必要があってもよい。出力されるブロックの選択を制御することに加えて、コントローラ160はまた、ハードウェアに具現された機能（例えば受信機135及び解凍器145）を制御し、更なるソフトウェア機能を提供してもよい。
図２及び図３は、本発明が使用可能なデジタルテレビシステムの詳細を提供する。一例として、オーディオ／ビデオ（A/V）信号を圧縮するためにMPEG-2圧縮を使用してA/V信号（プログラム）がデジタル配信されるシステムが記載されている。システムは、MPEG-2圧縮器210（通常は放送センタに配置されている）を有する。圧縮器はデジタル信号ストリーム（一般的にはデジタル化済アナログ又はデジタルビデオ信号のストリーム）を受信する。元の信号は、サービスプロバイダによりリンク205を介して供給されてもよい。プログラムは、ハードディスク、CD-ROM、DVD又は固体メモリのようなA/Vデータを格納する記憶媒体295からロードされることも可能である。通常は、タイトルは例えばMPEG-2コーディングを使用して圧縮形式で受信される。送信については、タイトルは変更されてもよく、例えば長さを減少させるために例えば何らかの部分が除去されてもよく、コマーシャルのようなその他の部分が追加されてもよい。従って、通常ではタイトルは圧縮器／コーダ210で再符号化される。圧縮器210は、任意選択のスクランブル機能を備えたマルチプレクサ220に接続されている。スクランブル器は、コンテンツ鍵の制御で暗号化することにより、データストリームのデジタル信号をスクランブルする。マルチプレクサ220は、１つ以上のスクランブル又は非スクランブルデータストリームに加えて、更にデジタル信号を受信してもよい。マルチプレクサ220は、全ての信号を集めて、トランスポートストリームにストリーミングし、放送センタの送信機230に圧縮及び多重化された信号を供給する。スクランブル及び多重化機能は異なるユニットで（所望の場合は異なる場所で）実行されてもよい。多重化トランスポートストリームは、通信リンクを含む如何なる適切な形式のリンクを使用して、スクランブル器／マルチプレクサ220から送信機230に供給されてもよい。送信機230は、衛星トランスポンダ240へのアップリンクを介して電磁気信号を送信し、そこで電磁気信号が電子的に処理され、従来のエンドユーザのパラボラアンテナの形式の地上衛星受信機250へのダウンリンクを介して放送される。図面では、衛星受信機250は統合受信システム260に接続されている。受信システム260の動作について、図３を参照して更に詳細に説明する。受信システムは、所望の信号を選択し、それを適切な形式で処理装置（テレビ270等）に提示する。信号はまた、テープ、光ディスク若しくはハードディスクレコーダ又は他の適切なレコーダを使用して記録されてもよい。信号は、CATVケーブル又はIEEE1394のような周知の配信システムを使用して、アナログ形式又はデジタル形式で処理／記録装置に供給されてもよい。デジタル配信では、トランスポートストリームの部分的なデコードのみが必要であり、逆多重化された信号は、部分トランスポートストリームを使用したMPEG-2コーディングに供給される。A/V信号の主配信は衛星を介して行われる必要がないことがわかる。その代わりに、地上波放送、ケーブル伝送、衛星／ケーブルの結合、又は移動体通信ベールの放送のように、他の配信システム（すなわち、１つ以上の多重化が送信される物理媒体）が使用されてもよい。配信システムを介してプログラムを配信する関係者は、場合によってはネットワークプロバイダと呼ばれる。受信機／デコーダ260が処理又は記録装置に統合されてもよいこともわかる。特に、受信／処理システム260は、車のラジオ／TVシステム、携帯電話又は移動体PDAのような移動体システムの一部でもよい。
一般的なシステムは複数チャネルシステムとして動作する。これは、マルチプレクサ220が複数の（並行の）ソースから受信したA/V情報を処理することができ、対応の数のチャネルで情報を放送するために送信機230と相互作用し、又は異なるトランスポートストリームに多重化されたA/V情報を処理することができることを意味する。A/V信号に加えて、メッセージ若しくはアプリケーション又はその他の種類のデジタルデータは、送信デジタルオーディオ及びビデオ情報でインターレースされて、これらのサービス／チャネルの一部又は全部に導入されてもよい。従って、トランスポートストリームは、それぞれ１つ以上のサービス構成要素を備えた１つ以上のサービスを有する。サービス構成要素は、単一媒体の要素である。サービス構成要素の例には、ビデオエレメンタリーストリーム、オーディオエレメンタリーストリーム、Java(登録商標)アプリケーション（Xlet）又はその他のデータ形式がある。トランスポートストリームは、１つ以上のエレメンタリーストリーム及び／又はデータを時間多重することで作られる。好ましい実施例では、双方のシーケンス（Seq.1及びSeq.2）は、相互に時間シフトされた同じトランスポートストリームに多重化される。ただし、Seq.1はSeq.2より（部分的に）先になる。
図２の放送システムでは、少なくとも主プログラム配信（Seq.2）が放送される。システムはまた、例えば、インタラクティブビデオ、電子商取引等のような双方向アプリケーションを促進するために、及び受信機がサーバ290から更なる情報／機能を取得することを可能にするために、双方向通信をサポートすることが好ましい。広域ネットワーク280（好ましくはオープンインターネット）が図示されており、更なる機能及びインタラクティブ性がウェブサーバ290のウェブサイトにより提供される。本発明による実施例では、第１のシーケンスはサーバ290からオンデマンドでダウンロードされ得る。このため、サーバ290はまた、コーダ／トランスコーダ／再エンコーダ210との接続を有している。これは直接のリンクでもよいが、インターネットを介してもよい。このように、サーバは第１のシーケンスSeq.1を受信し、受信機260へのオンデマンドのダウンロードのためにそれを格納する。サーバはまた、スクランブル機能220によりスクランブルされた後に、第１のシーケンスを受信してもよい。サーバは、Seq.1のダウンロードの管理をしてもよい。その管理は加入に基づいてもよく、実際の使用に基づいてもよい。スクランブルを使用することにより、例えばダウンロードシーケンスを支払った受信機より多い受信機に配信することによるような、システムの未払いの使用の可能性が減少する。
インターネット又は同様の通信システムの通信機能は、如何なる適切な形式で提供されてもよいことがわかる。例えば、受信機はインターネットプロトコルを直接使用してケーブルネットワーク又は衛星接続を介して通信してもよい。代替として、受信機は、インターネットへのアクセスを提供するアクセスプロバイダに対して電話ベースのダイヤルイン接続を有してもよい。受信機はインターネットプロトコルを使用してもよいが、必ずしも使用しなくてもよい。サーバ290がインターネットプロトコルを使用する場合、例えばゲートウェイを使用して、プロトコル変換が行われてもよい。
図２のシステムはデジタル放送システムについて記載しているが、基本的には本発明は非放送伝送にも適用可能である。例えば、プログラムが（例えばペイ・パー・ビューに基づいて）個々の受信機に供給される場合にも、同じ概念が容易に適用され得る。送信は、一般的な（直接指定された）放送システムを介して行われてもよく、高帯域インターネット接続のような他の適切なシステムを介して行われてもよい。
図３は、一般的な放送受信機の詳細を示している。放送受信機は、ヨーロッパMHP（Multi-media Home Platform）又はUS DASEプラットフォームのような所定のプラットフォームに準拠することが好ましい。放送受信機はチューナ310を有する。チューナ310は、異なるチューナブル無線周波数（RF）帯域を抽出し、通常はMPEG-2トランスポートストリームを生じる。デマルチプレクサ320（De-MUX）により、一定のキャリア信号から様々なデータ信号が分離される。その結果は、しばしばオーディオ、ビデオ及びデータ出力である。前述のように、好ましい実施例で双方のシーケンスが同じトランスポートストリームに多重化されている場合、双方のシーケンスは、デマルチプレクサ320により別々に供給される。シーケンスがオーディオ及びビデオエレメンタリーストリームを有している場合、デマルチプレクサは４つのエレメンタリーストリームを並行して供給してもよい。ストリームは、アクセス権を決定してデータを解読し得る限定受信サブシステム330を通じて供給されてもよい。
主シーケンス（seq.2）は、一般的にデコーダ340に直接供給され、そのデコーダ340はビデオ及びオーディオ処理又は記憶装置に適した信号にストリームを変換する。これは完全又は部分的なMPEG2デコードを有してもよい。まず、シーケンス1はバッファ335に一時的にバッファされる。このストリームを処理する時間が来た場合にのみ、その時点で処理に必要なデータがデコーダ340を通じて供給される。セレクタ345は、どのストリームが出力に提供されるべきかを選択するために使用される。通常は、これは主シーケンスSeq.2のデータである。しかし、このシーケンスのデータが利用可能でない場合、Seq.1のデータが使用される。第１のシーケンスSeq.1もまた異なるトランスポートストリームで放送され、シーケンス2の代わりに使用され得ることがわかる。この場合、双方のトランスポートストリームを同時に受信するために、‘ダブル’チューナが使用されてもよい。同様に、２つのデマルチプレクサが使用されてもよく、２つのトランスポートストリームを並行して逆多重化することができるデマルチプレクサが使用されてもよい。同様に、２つの逆スクランブル器が必要でもよい。
図３はまた、第１のシーケンスを供給する代替構成を示している。この実施例では、受信機はまた、サーバ290との双方向通信用の通信インタフェース380を有する。このため、標準的な通信回線用の従来型のモデム（例えばPOTS又はISDN）又はブロードバンドモデム（例えばADSL）を含み、如何なる適切な通信ハードウェア／ソフトウェアが使用されてもよい。双方向通信チャネルは、図２のサーバ290からSeq.1をダウンロードすることを促進する。ダウンロードされたブロックは、Seq.1が放送された場合に前述のようにデコーダに供給するため、バッファ335に一時的に格納される。例えばMHPの“Internet Access Profile”に記載されたもののように、双方向通信用にインターネットプロトコルが使用されることが好ましい。デコーダの出力は、その後の処理のため、処理装置又は記憶装置に供給され得る。一般的に、出力は後に処理／記憶装置に供給するため、まずビデオフレームバッファ370のようなバッファに格納される。特定の用途では、受信機は部分的にエンコードされた出力ストリームを提供し、デコーダ340をバイパスしてもよい。次に、処理装置がデコーダ機能を有してもよく、また、エンコードされたストリームが更なるデコードのために受信機に後に再供給されてもよい。エンコードされたデータストリームはまた、後の処理のために記憶システムに記録されてもよい。受信機のユーザインタフェース395により、受信機がユーザとインタラクトすることが可能になる。ユーザインタフェース395は、IRリモコンから信号を受信する赤外線受信機、キーボード又は音声制御用のマイクロフォンのように、如何なる適切なユーザ入力手段を有してもよい。出力についても、小型LCDディスプレイの使用、テレビのディスプレイの使用又は可聴フィードバックのように、如何なる適切な形式が使用されてもよい。
チューナ機能310や、デマルチプレクサ機能320や、任意選択の逆スクランブル／解読機能330や、デコーダ機能340のように、様々な機能が専用のハードウェアを使用して実行されてもよいことがわかる。何らかの機能又は機能の一部はまた、例えば適切なプログラムをロードしたデジタルシグナルプロセッサ（DSP：digital signal processor）又はメディアプロセッサ（例えばTriMedia）若しくはプログラム可能ロジック（例えばFPGA）を使用して、プログラム可能処理機能により実行されてもよい。受信システム内の様々な機能はコントローラ350の制御で動作し、そのコントローラ350は一般的に内蔵マイクロプロセッサ又はマイクロコントローラを有する。コントローラは、制御機能を実行するプログラムをロードされる。一般的に、プログラムはROM又はフラッシュのような不揮発性固体メモリからロードされる。
図４は、プログラムの家庭内配信向けの更なる例示的なシステムのブロック図である。図面には、ネットワークの階層が示されている。この例では、主ネットワーク410はUPnPアーキテクチャに基づいてもよい（基本的には他の適切な技術が使用されてもよい）ホームネットワークである。図４の説明ではUPnPネットワークに焦点を置く。UPnPは、IP技術に基づいており、多数のネットワーク媒体及び上位レベルのプロトコルをサポートする。媒体は、例えばEthernet（登録商標）ファミリーの媒体からの有線でもよく、IEEE802.11ファミリーの媒体に基づくような無線でもよい。ゲートウェイ／ルータ420は、ホームネットワーク410を外部ネットワーク430（オープンインターネット等）に結合するために使用され得る。外部ネットワークはまた、インターネットサーバでもよい装置470のような装置を有してもよい。特にA/Vデータのストリーミング転送のために、第３のネットワーク440が存在してもよい。このようなネットワークは、等時性通信をサポートするIEEE1394（又はUSB）のような技術に基づいてもよい。ストリーミング技術は有線でもよく、無線でもよい。システムは、ネットワークを介して通信可能な複数の装置を有する。主な役目はUPnPに定められたコンテンツディレクトリサービス（以下“CDS”という）を有し得るサーバ装置450に与えられる。簡単のために、CDSを備えた唯一の装置が図示されている。装置460、462、464、466のような他の装置も相互に及び／又はサーバ450と通信することができる。装置は同じ役目を有してもよく、異なる役目を有してもよい。装置460及び462は、システムの他の装置を制御することができる。UPnPでは、このような装置はコントロールポイントと呼ばれている。サーバ450のような装置は、処理装置464及び466のようなこのようなコンテンツのシンクにコンテンツを供給することができてもよい。これらの様々な役目は自由に結合されてもよい。例えば、コントロールポイント460はまた、サーバ450に格納された映画を処理することが可能でもよい。如何なる装置も、従来のハードウェア及びソフトウェアを使用して実装されてもよい。例えば、サーバ450は、所望の場合にはCDSを格納するためにRAIDシステム又は再書込み可能DVDのような信頼性のあるバックグラウンド記憶装置を備えて、パーソナルコンピュータプラットフォームに実装されてもよい。サーバ450はまた、統合したハードディスクを備えた受信機（例えばセットトップボックス）のような家庭用電子（CE：Consumer Electronics）装置に実装されてもよい。処理装置は、TVやオーディオ増幅器等のようなCE装置でもよい。UI装置はまた、TVのようなCE装置でもよいが、PDAや高度プログラム可能リモコンやゲームコンソール（XBOX等）等のようなハンドヘルド装置でもよい。システムの各装置は、ネットワークを通じて他の装置と通信するために必要なハードウェア及び／又はソフトウェアを有する。処理装置は、図１の受信システム130について説明したような機能を有してもよい。図４のシステムは、サーバから処理装置にシーケンスを供給する様々な機能を有してもよい。例えば、双方のシーケンスはネットワーク440を介してストリームされてもよい。代替として、２つのシーケンスはそれぞれのネットワーク410及び440を介して（例えばシーケンス2がA/Vストリーミングについて適したネットワーク440を介して、シーケンス1がネットワーク410を介して）ストリームされてもよい。好ましくはネットワーク410を介して、ストリーミングでない方法でシーケンス1を供給することも可能である。
前述のように、プログラムはブロックSeq.1及びSeq.2の各シーケンスに対して２回圧縮されることが好ましい。フォールバックシーケンスSeq.1は主シーケンスSeq.2より高い圧縮率を有することが好ましい。基本的には、シーケンス毎に異なる圧縮技術が使用されてもよい。本発明では、受信機がシーケンスのブロック間の対応について認識していることが必要である。簡単なブロックのマッチングのため、追加情報（MPEG2ビデオストリームにユーザデータとして埋め込まれる増加ピクチャ番号等）がストリームに埋め込まれてもよく、２つのストリームのタイムスタンプ（PCR、PTS、DTS）間の関係から導かれてもよい。シーケンス2のデータが受信機で利用可能でない場合（全て受信されない場合、欠落した場合、又は回復不可能な場合）、コントローラは、正しく利用可能である場合にはシーケンス1の対応のデータを供給するべきである。双方のシーケンスについて同じ圧縮技術（及びGOPサイズ等のような設定）を使用することで、ブロック毎のビット数の違いのみで、一般的に同じ構造シーケンスを生じる。異なる技術が使用される場合には、対応があまり明白ではないことがある。双方のシーケンスが同じプログラムから圧縮され同じプログラムに解凍されることでリンク付けされているため、対応は常に定められ得ることがわかる。この対応が受信システムによりリアルタイムに定めることが困難である場合、双方のシーケンスの間の対応を記述した圧縮器からの情報を使用して、送信システムでファイルを生成することが可能である。このリンク付けファイルは、例えばストリームに埋め込まれて受信システムに送信され、図１のコントローラにより使用され得る。通常は、非圧縮のプログラムは、同時に処理されるブロックの時間的シーケンスで構成される。例えば、ビデオの場合、そのようなプログラムブロックはビデオフィールド、ビデオフレーム又はフレームのグループでもよい（MPEG2について以下に詳細に説明する）。オーディオの場合、それは１つのオーディオのサンプルでもよいが、複数（例えば12又は36）のオーディオのサンプルがオーディオフレームにグループ化されてユニットとして符号化されることが好ましい。圧縮は、ブロックの圧縮シーケンスの１ブロックについて１つより多い時間的プログラムブロックの情報を使用してもよい。このことは、ブロックを処理するために非圧縮プログラムの１ブロックを生成するために、受信システムが送信シーケンスの複数のブロックで動作することを要してもよいという効果を有し得る。従って、シーケンス2からシーケンス1へのシームレスな切換を得るために、複数のブロックのシーケンス1が解凍形式でバッファされることを要してもよい。
好ましい実施例では、例えば周期的冗長検査（CRC：Cyclic Redundancy Check）を検査することにより、まず第２のシーケンスのブロック（又はブロック群のシーケンス）が正確に受信されたか否かが検査される。正確である場合、ブロック（又はブロック群）がデコードされる。そうでない場合、シーケンス1の交換ブロックがデコーダに送信される。双方のシーケンスの対応のブロックが対応のブロック番号を有し、交換ブロックを迅速に識別可能にすることが好ましい。
前述のように、オーディオでは、ブロックは１つのオーディオのサンプルでもよい。しかし、MPEG1レイヤの1/2/3の場合に一般的なように、複数の連続するオーディオのサンプル（例えば12又は36）をグループ化し、各フレームを個別に符号化することが好ましい。従って、サンプルレートがフレームの持続時間を決定する。受信機は、シーケンス1及び2について受信した符号化フレームのそれぞれに、シーケンス番号（又は同様に再生時間間隔（シーケンス番号×フレーム持続時間））を容易に割り当てることができる。それは、シーケンス2の正確なフレームが利用可能でない場合にシーケンス1の交換フレームを選択するために、この情報を使用することができる。
前述の機構について、ビデオプログラムのMPEG2圧縮に関して詳細に説明する。当業者は同じ原理を他の圧縮機構に適用することができる。MPEG-1及びMPEG-2のそれぞれは、ビデオ入力信号（一般的にはピクチャの連続的な発生）をピクチャのシーケンス又はグループ（“GOP”）に分割する。各GOPのピクチャは特定の形式にエンコードされる。一般的に、ビデオデータに適用され得る3つの異なるエンコード形式が存在する。イントラ符号化は“I”ピクチャを作り、エンコードはピクチャ内の情報のみに依存する。インター符号化は“P”ピクチャ又は“B”ピクチャを作ってもよい。“P”ピクチャでは、エンコードは前のビデオフレーム（Iフレーム又はPフレーム、以下では併せて“参照フレーム”と呼ぶ）で検出された情報のブロックに基づく予測に依存する。“B”ピクチャでは、エンコードは、せいぜい２つの側近のビデオフレーム（すなわちビデオデータの前の参照フレーム及び／又は後の参照フレーム）からのデータのブロックに基づく予測に依存する。基本的には、２つの参照フレーム（Iフレーム又はPフレーム）の間に、複数のフレームがBフレームとして符号化され得る。しかし、その間に複数のフレームが存在する場合には、参照フレームでの時間差が増加する傾向にあるため（その結果、Bフレームの符号化サイズが増加する）、実際には、参照フレームの間に最大で２つのBフレームのみが使用され、それぞれ同じ２つの側近の参照フレームに依存するように、MPEG符号化が使用される。フレーム対フレームの冗長度を除去するため、ビデオ画像の移動オブジェクトのずれがPフレーム及びBフレームについて推定され、フレームからフレームへのそのような移動を表す動きベクトルに符号化される。
図５Ａは、MPEG-2符号化によるフレームの例示的なシーケンスを示しており、矢印を使用してフレーム間の依存関係を示している。Bフレームの前方依存に起因して、図５Ａに示すようなシーケンスでフレームを送信することは、受信したBフレームがその後の参照フレームが受信（及びデコード）された後にのみデコードされ得るという影響を有する。デコード中にシーケンスを通じて‘ジャンプ’する必要を回避するため、通常ではフレームは図５Ａの表示シーケンスで格納又は送信されず、図５Ｂに示す対応の送信シーケンスで格納又は送信される。この送信シーケンスでは、参照フレームは、それに依存するBフレームの前に送信される。このことは、フレームが受信したシーケンスでデコードされ得ることを意味する。デコード済の前方参照（P）フレームに依存したBフレームが表示されるまで、その表示が遅れることがわかる。従って、このような圧縮機構では、数フレームが解凍形式で一時的にバッファされる。
図５に示すMPEG2エンコード機構を参照すると、通常ではデコーダは、Iフレームで開始して一般的に15の連続フレームを有するグループオブピクチャ（GOP）で動作する。特別の手段がなければ、Seq.2からSeq.1（又はその逆）への切換は、ほとんど１つのGOPの処理時間（約0.5秒）の最悪の遅延を生じることがある。例えば、シーケンス2のGOPの最後のフレームが欠落している場合、このフレームはシーケンス1のフレームにより交換されることが好ましい。このフレームをデコードされた形式で提供することができるように、シーケンス1の全体の関与するGOPがデコードされなければならない。デコードがリアルタイムである場合、唯一の時間間隔が利用可能である一方で、このことは15の時間間隔を要する。従って、14の時間間隔の遅延が生じ得る。本発明による好ましい実施例では、解凍器（図１の解凍器145又は図３のデコーダ340等）は、双方のシーケンスを並行してデコードすることができる。本発明では、二重のハードウェア／ソフトウェアを有するという意味で並行が実際に並行であるか、又は並行が時間多重のような他の方法で実現されているかは無関係である。２つのストリームについてリアルタイム解凍（すなわち処理レートでの解凍）が可能なデコーダを使用して、コントローラは、第２のシーケンスの対応のブロックの供給と同期して、第１のシーケンスのブロックがデコーダに供給されることを確保する。このように、第１のシーケンスの所望のブロックもデコード形式で常に利用可能である。一例として、本発明によるメインバッファが100のGOP(すなわち1500フレーム)を格納しており、‘最も古い’GOPがシーケンス2について現在受信されているGOPに対応する場合、コントローラは、この最も古いGOPのフレームのデコードが現在受信されているシーケンス2の対応のフレームに同期して生じることを確保する。このように、シーケンス1は、出力に供給されなくても常にデコードされる。
前記の例は、Seq.1及びSeq.2の受信ブロックが双方共に完全にデコード（解凍）されていることを仮定している。ほとんどのシステムでは、このような完全なデコードが使用され、結果の出力は、処理に直接使用されるプログラムブロック（フレーム等）を表すデジタル（又は適切なD/A変換を使用したアナログ）である。あるシステムでは、ブロックがエンコードされた形式又は部分的にデコードされた形式で供給されることが受け入れられることがあり、又はそれが望ましいことがあることがわかる。MPEG2の場合、このことは、１つのフレームがシーケンス2で欠落している場合に、全体の関与するGOPがシーケンス1の対応のGOPで交換されることを意味し得る。従って、システムにより供給されるブロックの表示は、如何なる適切な表示（例えばアナログ形式での完全なデコードから完全なデコードまで）でもよい。同様に、ブロックは、受信システムがシーケンス間を切り換えることができるデータの如何なる意味のユニットを表してもよい。前述のように、MPEG2ビデオでは、これは例えばフレーム又はGOPでもよい。一般的に、受信システムのコントローラは、受信機によるブロックの受信に応じて第２のシーケンスのブロックを解凍器に供給することにより、第２のシーケンスのブロックの表示が生成されることを確保する。例えば送信のジッタを克服するために、実際の受信とデコーダへの供給との間にある程度の小さい遅延が生じてもよい。第２のシーケンスの配信は、処理／格納機能への出力を介して、送信機から受信機、デコーダに、１つのスムースなストリームで生じることが好ましい。従って、第２のシーケンスのブロックは、所定のストリーミング時間スケジュールの各時間間隔に従って受信システムに配信される。例えば、毎秒25フレームのMPEG2エンコードビデオを使用して、フレームは1/25秒毎に送信される。本発明では、ストリーミングがプッシュ形式（送信機が時間スケジュールを決定する）で行われるか、プル形式（処理装置がスケジュールを決定する）で行われるかは無関係である。第２のシーケンスのブロック（例えばビデオフレーム）が受信システムで利用可能でなく、処理装置が必要な時間間隔に出力を通じて供給されないことを、コントローラが検出した場合、それは、第２のシーケンスの損失／欠落したブロックに対応する第１のシーケンスのブロックが出力に供給されることを確保する。基本的には、第２のシーケンスのブロックが受信される時間間隔が終了し、ブロックが受信されていない場合又は欠落して回復不可能な形式で受信した場合、コントローラは、第１のシーケンスの対応のブロックを出力に指示する。送信機から処理装置への全体経路において、通常では、１つ以上の処理機能の間に（例えば１つのビデオフレームを格納するための）何らかの小型バッファが存在することがわかる。従って、受信システムを通じた全体チェーンでは、複数フレームの遅延が存在してもよい。従って、コントローラは、第２のシーケンスのブロックが使用不可能であり、第１のシーケンスの対応のブロックを使用するために迅速に対策を取る必要があることを、一般的に事前に知ることができる。
本発明によれば、シーケンス1のブロックは、シーケンス2の対応のブロックの前に送信される。特に、シーケンス1がオンデマンドで送信される場合、コントローラは、バッファの所定の充填度を維持するために、送信システムから第１のシーケンスのブロックのオンデマンドのダウンロードを行わせる。このことは、所望の充填度が実現されている限り、コントローラは新しいブロックのダウンロードを要求し続けることを意味する。要求は個々のブロックについてでもよく、ブロックのグループについてでもよい。コントローラは、シーケンス2の送信が開始されるとすぐに、要求を開始してもよい。このような場合では、最初にフォールバックの位置は存在しない。シーケンス1のブロックはシーケンス2のブロックより早く到達するため、所望の充填度が実現されるまで、バッファが充填される。所望の充填度は‘全部’でもよい。特に、ブロックのグループが要求される場合、所望の充填度は、ブロックの全体グループが依然として格納され得るほどでもよい。シーケンス2の開始時にダウンロードを開始する代替として、ダウンロードはより早く開始されてもよい。このような場合では、最初の所望の充填度はより小さくてもよく（例えば1ブロックのみ）、時間の経過と共に、ほとんどのバッファが充填されるまで増加してもよい。
シーケンス1もストリーミング形式で送信されるシステムでは特に、バッファを充填することについて様々な形式が可能である。例えば、バッファがシーケンス1の1分のリアルタイムブロックを保持することができる場合、シーケンス1の送信は、Seq.1の標準ビットレートでシーケンス2の1分前に開始され得る。代替として、シーケンス2の送信が開始していない限り、シーケンス1のより高速な送信（すなわちリアルタイムの処理レートより高速）のために、異なる伝送容量が使用されてもよい。一例として、シーケンス1がシーケンス2のサイズの25%まで圧縮されている場合、通常の動作中に、時間間隔毎に（シーケンス2のサイズの）1.25ブロックのプログラムを送信する容量が存在する。従って、シーケンス2がまだ送信されていない開始時点では、シーケンス1の1分のリアルタイム送信は、12秒で送信され得る。これが図６に示されている。時間間隔610の間に、Seq.2は送信されておらず、Seq.1はシステムで利用可能な全伝送ビットレート（BR：bit-rate）（一般的にSeq.2及びSeq.1を並行してリアルタイム配信するために必要なビットレート）で送信されている。間隔620の間に、（時間間隔cまで）Seq.2が送信される。Seq.1が先であるため、Seq.1の送信も早く終了し、時間インスタンスbで示されている。図６Ｂは、このスケジュールの間のバッファの充填度（FD：filling degree）を示している。
図７は代替を示している。開始間隔710の間に、Seq.1は全伝送ビットレートで送信され、最初の充填を迅速に実現する。この時間間隔を低減するために、バッファは完全に充填されない。その代わりに、インスタンスaでSeq.2の送信が開始する。最大まで更にバッファを充填することを可能にするため、バッファがいっぱいになるまで（インスタンスd）の期間中に、Seq.2は、減少した伝送ビットレートで送信される（Seq.2の送信はリアルタイムであるため、このことはより高い圧縮を意味する）。その例では、全利用可能伝送ビットレートは、シーケンス間でほぼ均等に分割される。Seq.1の品質（圧縮率）は同じに保持されるため、リアルタイム（Seq.1の標準的な伝送ビットレートの場合）よりSeq.1の多くのブロックが送信され得る。図７Ｂでわかるように、このようにバッファが更に充填される。バッファが充填されると、Seq.1はデフォルト品質の符号化及び対応の伝送ビットレートで送信される。
図８は更なる代替を示している。この例では、間隔610及び710のような開始段階は存在しない。その代わりに、Seq.1及びSeq.2の送信が同時に開始する。必要な伝送容量より大きい伝送容量（時間間隔毎のシーケンス2のブロックの1.3倍）を確保することにより、バッファがいっぱいになるまで、この余分の容量がシーケンス1の更なるブロックを送信するために使用され得る。図８は、全体伝送容量は増加しないが、その代わりに時間間隔dまでSeq.2がより高い圧縮で送信されることを代替として示している。これは、Seq.1の更なる伝送容量を提供する。Seq.1の圧縮品質を増加させないことにより、更なる伝送容量はSeq.1のブロックを送信するために使用され、リアルタイムより早くバッファを充填する。バッファがインスタンスdでいっぱいになると、システムは前述と同じになる。
前述の実施例は本発明を限定するのではなく、説明するものであり、当業者は特許請求の範囲を逸脱することなく多数の代替実施例を設計することができることに留意すべきである。特許請求の範囲において、括弧の間の如何なる参照符号も特許請求の範囲を限定するものとして解釈されるべきではない。“有する”という動詞及びその活用の使用は、請求項に記載以外の要素又はステップの存在を除外するものではない。単数の要素は、そのような要素の複数の存在を除外するものではない。本発明は、複数の異なる要素を有するハードウェアを用いて、及び適切にプログラムされたコンピュータを用いて実装され得る。複数の手段を列挙した装置の請求項において、これらの手段の複数が同一のハードウェアのアイテムに具現されてもよい。特定の手段が相互に異なる従属項に記載されているという単なる事実は、これらの手段の組み合わせが有利に使用できないことを意味するのではない。
本発明によるシステムのブロック図である。 本発明によるシステムを有するデジタル放送システムのブロック図である。 デジタル放送受信システムのブロック図である。 家庭内配信システムのブロック図である。 フレームのMPEG2シーケンスである。 本発明に従ってバッファを充填する方法である。 本発明に従ってバッファを充填する方法である。 本発明に従ってバッファを充填する方法である。

Claims (14)

  1. コンテンツ部分のシーケンスを有するプログラムのストリーム配信用の配信システムであって、
    前記プログラムをブロックの第１のシーケンスとブロックの第２のシーケンスとに圧縮し、前記第１及び第２のシーケンスのブロック間の対応は、同一視可能な前記プログラムの同じコンテンツ部分に関係する第１のシーケンス及び第２のシーケンスのブロックにより定められる圧縮システムと、
    所定のリアルタイム配信スケジュールの各時間間隔に従って受信システムに前記第２のシーケンスのブロックを配信し、前記受信システムにブロックの前記第１のシーケンスを配信し、前記第１のシーケンスのブロックは、前記第２のシーケンスの対応のブロックより早く送信される送信システムと、
    ブロックの前記第２のシーケンスをストリーム受信し、ブロックの前記第１のシーケンスを受信する受信機と；前記配信スケジュールが終了していない第２のシーケンスのブロックに対応するブロックの第１のシーケンスのブロックを一時的に格納するバッファと；前記プログラムのコンテンツ部分を供給する出力と；前記配信スケジュールの時間間隔毎に、前記第２のシーケンスのブロックが前記時間間隔でうまく受信された場合にこのようなブロックの表示を前記出力に指示し、又は前記第２のシーケンスのブロックが前記時間間隔でうまく受信されなかった場合に前記バッファに格納されている対応のブロックの表示を前記出力に指示するように動作可能なコントローラとを有する受信システムと
    を有するシステム。
  2. 請求項１に記載のシステムであって、
    ブロックの前記第１のシーケンスは、第１のビットレートを有し、
    ブロックの前記第２のシーケンスは、前記第１のビットレートより大きい第２のビットレートを有するシステム。
  3. 請求項１に記載のシステムであって、
    ブロックの前記第１及び第２ンシーケンスは、異なる伝送チャネルで伝送されるシステム。
  4. 請求項１に記載のシステムであって、
    ブロックの前記第１のシーケンスは、ストリーム配信を使用して配信されるシステム。
  5. 請求項４に記載のシステムであって、
    ブロックの前記第１及び第２のシーケンスは、同じストリーミングチャネルに多重化されるシステム。
  6. 請求項１に記載のシステムであって、
    ブロックの前記第２のシーケンスは、放送されるシステム。
  7. 請求項１に記載のシステムであって、
    前記コントローラは、前記バッファの所定の充填度を維持するために、前記送信システムから前記第１のシーケンスのブロックのオンデマンドでのダウンロードを行わせるように動作可能なシステム。
  8. 請求項１に記載のシステムであって、
    前記配信システムは、ブロックの前記第２のシーケンスのストリーム伝送を開始する前に、所定の充填度までバッファを充填するように動作可能であるシステム。
  9. 請求項１に記載のシステムであって、
    前記受信システムは、ブロックの前記第１及び第２のシーケンスのブロックを解凍する解凍器を有し、
    前記コントローラは、実質的に前記ブロックの受信に応じて前記第２のシーケンスのブロックの解凍を行わせ、実質的に前記第２のシーケンスの対応のブロックの解凍と同期して前記第１のシーケンスのブロックの解凍を行わせるように動作可能なシステム。
  10. 請求項１に記載のシステムであって、
    前記第１のシーケンスのビットレートは、前記第２のシーケンスのビットレートの25%未満であるシステム。
  11. コンテンツ部分のシーケンスを有するプログラムのストリーム配信用の送信システムであって、
    前記プログラムをブロックの第１のシーケンスとブロックの第２のシーケンスとに圧縮し、第１及び第２のシーケンスのブロック間の対応は、同一視可能な前記プログラムの同じコンテンツ部分に関係する第１のシーケンス及び第２のシーケンスのブロックにより定められる圧縮システムと、
    所定のリアルタイム配信スケジュールの各時間間隔に従って受信システムに前記第２のシーケンスのブロックを配信し、前記受信システムにブロックの前記第１のシーケンスを配信し、前記第１のシーケンスのブロックは、前記第２のシーケンスの対応のブロックより早く送信される送信機と
    を有する送信システム。
  12. ブロックの第１のシーケンスを受信し、ブロックの第２のシーケンスをストリーム受信する受信機を有し、
    ブロックの前記第１のシーケンスは、圧縮形式のプログラムを有し、
    ブロックの前記第２のシーケンスは、圧縮形式の同じプログラムを有し、
    前記第１及び第２のシーケンスのブロック間の対応は、同一視可能な前記プログラムの同じコンテンツ部分に関係する第１のシーケンス及び第２のシーケンスのブロックにより定められ、
    前記第２のシーケンスのブロックは、所定のリアルタイム配信スケジュールの各時間間隔に従って送信され、
    前記第１のシーケンスのブロックは、前記第２のシーケンスの対応のブロックより早く送信される受信システムであって、
    前記配信スケジュールが終了していない第２のシーケンスのブロックに対応するブロックの第１のシーケンスのブロックを一時的に格納するバッファと、
    前記プログラムのコンテンツ部分を供給する出力と、
    前記配信スケジュールの時間間隔毎に、前記第２のシーケンスのブロックが前記時間間隔でうまく受信された場合にこのようなブロックの表示を前記出力に指示し、前記第２のシーケンスのブロックが前記時間間隔でうまく受信されなかった場合に前記バッファに格納されている対応のブロックの表示を前記出力に指示するように動作可能なコントローラと
    を有する受信システム。
  13. コンテンツ部分のシーケンスを有するプログラムのストリーム受信の方法であって、
    ブロックの第１のシーケンスを受信し、ストリーミングでブロックの第２のシーケンスを受信し、ブロックの前記第１のシーケンスは圧縮形式のプログラムを有し、ブロックの前記第２のシーケンスは、圧縮形式の同じプログラムを有し、前記第１及び第２のシーケンスのブロック間の対応は、同一視可能な前記プログラムの同じコンテンツ部分に関係する第１のシーケンス及び第２のシーケンスのブロックにより定められ、前記第２のシーケンスのブロックは、所定のリアルタイム配信スケジュールの各時間間隔に従って送信され、前記第１のシーケンスのブロックは、前記第２のシーケンスの対応のブロックより早く送信され、
    ストリーミング時間スケジュールが終了していない第２のシーケンスのブロックに対応するブロックの第１のシーケンスのブロックを一時的に格納し、
    前記配信スケジュールの時間間隔毎に、前記第２のシーケンスのブロックが前記時間間隔でうまく受信された場合にこのようなブロックの表示を提供し、又は前記第２のシーケンスのブロックが前記時間間隔でうまく受信されなかった場合に前記第１のシーケンスの格納されている対応のブロックの表示を提供することにより、前記プログラムのコンテンツ部分を供給することを有する方法。
  14. プロセッサに請求項１３に記載の方法を実行させるように動作可能なコンピュータプログラム。
JP2006506922A 2003-05-02 2004-04-29 プログラムの冗長伝送 Withdrawn JP2006525730A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP03101230 2003-05-02
PCT/IB2004/050545 WO2004098149A1 (en) 2003-05-02 2004-04-29 Redundant transmission of programmes

Publications (1)

Publication Number Publication Date
JP2006525730A true JP2006525730A (ja) 2006-11-09

Family

ID=33395973

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2006506922A Withdrawn JP2006525730A (ja) 2003-05-02 2004-04-29 プログラムの冗長伝送

Country Status (6)

Country Link
US (1) US20070101378A1 (ja)
EP (1) EP1623555A1 (ja)
JP (1) JP2006525730A (ja)
KR (1) KR20060010777A (ja)
CN (1) CN1781295A (ja)
WO (1) WO2004098149A1 (ja)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100636147B1 (ko) * 2004-06-24 2006-10-18 삼성전자주식회사 네트워크를 통한 컨텐츠의 제어 방법 및 장치, 컨텐츠제공 방법 및 장치
US7673063B2 (en) * 2004-10-15 2010-03-02 Motorola, Inc. Methods for streaming media data
US7944967B2 (en) * 2005-07-28 2011-05-17 Delphi Technologies, Inc. Technique for addressing frame loss in a video stream
US8229983B2 (en) * 2005-09-27 2012-07-24 Qualcomm Incorporated Channel switch frame
NZ566935A (en) * 2005-09-27 2010-02-26 Qualcomm Inc Methods and apparatus for service acquisition
KR100750135B1 (ko) * 2005-10-25 2007-08-21 삼성전자주식회사 ＵＰｎＰ 디바이스의 ＩＰ 주소 변경으로 인한 네트워크연결 중단을 신속하게 복구하는 방법 및 시스템
JP4794623B2 (ja) * 2006-06-01 2011-10-19 シャープ株式会社 コンテンツ再生装置
US7912454B2 (en) * 2006-08-15 2011-03-22 Reqall, Inc. Method and system for archiving data in real-time communications
US8276180B1 (en) * 2006-08-29 2012-09-25 Nvidia Corporation System, method, and computer program product for transcoding or transrating video content for delivery over a wide area network
KR101089072B1 (ko) * 2006-11-14 2011-12-09 퀄컴 인코포레이티드 채널 전환용 시스템 및 방법
RU2009122503A (ru) * 2006-11-15 2010-12-20 Квэлкомм Инкорпорейтед (US) Системы и способы для приложений, использующих кадры переключения каналов
US8245262B2 (en) * 2008-04-07 2012-08-14 Samsung Electronics Co., Ltd. System and method for synchronization of television signals associated with multiple broadcast networks
JP5544806B2 (ja) * 2009-09-29 2014-07-09 ソニー株式会社 情報処理装置、及び情報処理方法
US8843594B2 (en) 2010-03-26 2014-09-23 Dan Fiul Time shifted transcoded streaming (TSTS) system and method
EP2425627B1 (de) * 2010-07-23 2020-12-30 Unify GmbH & Co. KG Verfahren zur zeitlichen synchronisierung der intrakodierung von verschiedenen unterbildern bei der erzeugung einer mischbildervideosequenz
EP2754300A1 (en) * 2011-08-10 2014-07-16 Telefonaktiebolaget LM Ericsson (PUBL) Media stream handling
CN104041061A (zh) * 2011-08-10 2014-09-10 瑞典爱立信有限公司 媒体流处置
US20160105689A1 (en) * 2014-10-13 2016-04-14 Vigor Systems Inc. Replacing a corrupted video frame
US10602139B2 (en) * 2017-12-27 2020-03-24 Omnivision Technologies, Inc. Embedded multimedia systems with adaptive rate control for power efficient video streaming
US10779017B2 (en) * 2018-12-10 2020-09-15 Warner Bros. Entertainment Inc. Method and system for reducing drop-outs during video stream playback
US11792472B2 (en) * 2019-09-18 2023-10-17 Wayne Fueling Systems Llc Schedule-based uninterrupted buffering and streaming

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1995022194A1 (en) * 1994-02-10 1995-08-17 Philips Electronics N.V. High frequency ac/ac converter with power factor correction
DE69626796T2 (de) * 1995-12-08 2004-02-12 Koninklijke Philips Electronics N.V. Vorschaltgerät
US5932976A (en) * 1997-01-14 1999-08-03 Matsushita Electric Works R&D Laboratory, Inc. Discharge lamp driving
CA2206276C (en) * 1997-04-18 2000-06-27 Matsushita Electric Works, Ltd. Discharge lamp lighting device
CA2206200C (en) * 1997-04-18 2000-06-27 Matsushita Electric Works, Ltd. Discharge lamp lighting device
US6034489A (en) * 1997-12-04 2000-03-07 Matsushita Electric Works R&D Laboratory, Inc. Electronic ballast circuit
JP3974712B2 (ja) * 1998-08-31 2007-09-12 富士通株式会社 ディジタル放送用送信・受信再生方法及びディジタル放送用送信・受信再生システム並びにディジタル放送用送信装置及びディジタル放送用受信再生装置
ATE221715T1 (de) * 1998-09-18 2002-08-15 Knobel Lichttech Schaltungsanordnung zum betreiben von gasentladungslampen
US7003794B2 (en) * 2000-06-27 2006-02-21 Bamboo Mediacasting, Inc. Multicasting transmission of multimedia information
US20020191116A1 (en) * 2001-04-24 2002-12-19 Damien Kessler System and data format for providing seamless stream switching in a digital video recorder
US6593703B2 (en) * 2001-06-15 2003-07-15 Matsushita Electric Works, Ltd. Apparatus and method for driving a high intensity discharge lamp
FI115418B (fi) * 2001-09-20 2005-04-29 Oplayo Oy Adaptiivinen mediavirta
US6670779B2 (en) * 2001-12-05 2003-12-30 Koninklijke Philips Electronics N.V. High power factor electronic ballast with lossless switching
DE10296991T5 (de) * 2001-12-25 2004-11-04 Matsushita Electric Works, Ltd. Entladelampen-Betätigungsvorrichtung

Also Published As

Publication number Publication date
CN1781295A (zh) 2006-05-31
US20070101378A1 (en) 2007-05-03
KR20060010777A (ko) 2006-02-02
WO2004098149A1 (en) 2004-11-11
EP1623555A1 (en) 2006-02-08

Similar Documents

Publication Publication Date Title
JP2006525730A (ja) プログラムの冗長伝送
US10097607B2 (en) Bit rate stream switching
US8793749B2 (en) Source frame adaptation and matching optimally to suit a recipient video device
US9565471B2 (en) Method and system for PVR on internet enabled televisions (TVs)
US9426335B2 (en) Preserving synchronized playout of auxiliary audio transmission
US8355452B2 (en) Selective frame dropping for initial buffer delay reduction
US7093274B2 (en) Apparatus and method for accommodating fast change of digital streaming sources and formats
US20060143669A1 (en) Fast channel switching for digital TV
US20090064242A1 (en) Fast channel switching for digital tv
US20070143800A1 (en) Audio-visual content transmission
US20070121629A1 (en) Accelerated channel change
US9185335B2 (en) Method and device for reception of video contents and services broadcast with prior transmission of data
JP2005505210A (ja) ストリーミングされたコンテンツのインテリジェント配信方法
US20030070181A1 (en) Interactive TV client device with integrated removable storage system
JP2017520940A (ja) 階層符号化されたコンテンツを多重化するための方法および装置
JP5881219B2 (ja) 単一の復号器でチャンネル変更を可能にする受信機および該受信機での方法
CA2439377A1 (en) System and method for receiving and storing a transport stream
JP4491918B2 (ja) データ配信装置及び方法、データ配信システム
TWI673999B (zh) 供視聽內容及／或資料傳輸的方法
Yang et al. AVS trick modes for PVR and VOD services
JP6425590B2 (ja) 番組配信システム
EP2733953A1 (en) Content compression system

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070426

A761 Written withdrawal of application

Free format text: JAPANESE INTERMEDIATE CODE: A761

Effective date: 20090227