JP2014529970A - 適応httpストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法 - Google Patents

適応httpストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法 Download PDF

Info

Publication number
JP2014529970A
JP2014529970A JP2014528652A JP2014528652A JP2014529970A JP 2014529970 A JP2014529970 A JP 2014529970A JP 2014528652 A JP2014528652 A JP 2014528652A JP 2014528652 A JP2014528652 A JP 2014528652A JP 2014529970 A JP2014529970 A JP 2014529970A
Authority
JP
Japan
Prior art keywords
segment
presentation
time
display
content
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2014528652A
Other languages
English (en)
Other versions
JP6054398B2 (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.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
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 Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2014529970A publication Critical patent/JP2014529970A/ja
Application granted granted Critical
Publication of JP6054398B2 publication Critical patent/JP6054398B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/65Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/70Media network packetisation
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/762Media network packet handling at the source 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80Responding to QoS
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing 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/23439Processing 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
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Landscapes

  • Engineering & Computer Science (AREA)
  • Multimedia (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Two-Way Televisions, Distribution Of Moving Picture Or The Like (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

本明細書で説明される適応HTTPストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法は、セグメントデータが暗号化されている場合でも、適応HTTPストリーミング解決法に対するユーザ体験と帯域幅の効率との改善を可能にする。シグナリング方法は、セグメントマップを表示のセグメントに関連付けることを含み、セグメントマップは、バイトオフセット情報および場合によって他のセグメント情報と共に、関連付けられたセグメント内の時間的な開始点と時間的な終了点の両方を備え、セグメントマップは、関連付けられるセグメントの時間スパンとは独立の予測可能な時間スパンパターンで生成され得る。これら実施形態は、既存のコンテンツの符号化処理とフォーマット処理とを変更する必要がないように、既存の展開を改善するために使用され得るので、コンテンツを受信し再生する既存のクライアントは影響を受けない。【選択図】図15

Description

関連出願
同時係属特許出願の参照
本出願は、2011年8月31日に出願され、「Switch Signaling Methods Providing Improved Switching Between Representations For Adaptive HTTP Streaming」と題され、その全体が引用によりここにほとんど組み込まれる米国仮特許出願第61/529,656号の非仮出願であって、これによる優先権を主張する。
本開示は、同一出願人による下記の出願/特許を、本文書にほとんど全て記載されるかのように引用によって本出願に組み込む。
2009年9月22日に出願され、「Enhanced Block−Request Streaming System」と題された米国特許出願第61/244,767号(以後「Luby A1」)、
2009年11月3日に出願され、「Enhanced Block−Request Streaming System」と題された米国特許出願第61/257,719号(以後「Luby A2」)、
2009年11月4日に出願され、「Enhanced Block−Request Streaming System」と題された米国特許出願第61/258,088号(以後「Luby A3」)、
2009年12月11日に出願され、「Enhanced Block−Request Streaming System」と題された米国特許出願第61/285,779号(以後「Luby A4」)、
2010年1月20日に出願され、「Enhanced Block−Request Streaming System」と題された米国特許出願第61/296,725号(以後「Luby A5」)、
2010年9月21日に出願され、「Enhanced Block−Request Streaming System」と題された米国特許出願第12/887,476号(以後「Luby B」)、
2008年4月15日に出願され、「Dynamic Stream Interleaving and Sub−Stream Based Delivery」と題され、Luby他を挙げる米国特許出願第12/103,605号、および、
2010年2月12日に出願され、「Block Partitioning for a Data Stream」と題され、Pakzad他を挙げる米国特許出願第12/705,202号(以後「Pakzad」)。
本発明は、改善されたメディアストリーミングシステムと方法に関し、より詳細には、ストリームされたメディアの提示を最適化し、ストリームされたメディアデータの効率的な同時または適時分配の配信を提供現するためにネットワークおよびバッファ条件に適応するシステムと方法に関する。
高品質のオーディオおよびビデオが、インターネットのようなパケットベースのネットワーク、セルラーおよびワイヤレスネットワーク、電力線ネットワーク、並びに他のタイプのネットワークを通じて配信されることがより一般的になるにつれて、ストリーミングメディア配信がますます重要になり得る。配信されるストリーミングメディアが提示され得る際の品質は、元のコンテンツの解像度(または他の属性)、元のコンテンツの符号化品質、受信デバイスがメディアを復号し提示する能力、受信機で受信された信号の適時性および品質などを含む、いくつかの要因に依存し得る。知覚される良好なストリーミングメディア体験を作り出すには、受信機で受信される信号の転送および適時性が特に重要であり得る。良好な転送は、送信者が送信したものに対して受信機で受信されるストリームの忠実さを提供できる一方で、適時性は、あるコンテンツに対する最初の要求の後で受信機がどれだけ迅速にそのコンテンツの再生(play out)を開始できるかに相当し得る。
メディア配信システムは、メディアソース、メディア送付先、並びにソースおよび送付先を分離する(時間および/または空間で)チャネルを有するシステムとして特徴付けられ得る。通常、ソースは、電子的に管理可能な形式のメディアへのアクセス権を有する送信機と、メディア(またはその類似物)の受信を電子的に制御し、メディアをメディア消費者(例えば、受信機、記憶デバイスまたは素子、別のチャネルなどに何らかの方法で結合されたディスプレイデバイスを有するユーザ)に提供する能力を伴った受信機とを含む。
「消費」は、何らかの方法で消費されるメディアを提示などのために使用する送付先での処理である。例えば、モバイルビデオプレーヤは、しばしばビデオの再生レートでビデオデータを「消費する」。通常の速さの再生レートを有するビデオのように、メディアがある再生レートを有する場合、「提示時間」が定義され得る。例えば、メディア提示の開始から2:00.00分の通常の中断されない再生の後に視聴者が達するメディアストリームの点は、2:00.00の提示時間(「PT」)を有すると呼ばれる。
多くの変形が可能であるが、一般的な例では、メディア配信システムは電子的な形式のメディアコンテンツに対するアクセス権を有する1つまたは複数のサーバを有し、1つまたは複数のクライアントシステムまたはデバイスはメディアに対する要求をサーバに対して行い、サーバはサーバの一部として送信機を使用してメディアを伝え、受信されたメディアが何らかの方法でクライアントによって消費され得るようにクライアントの受信機に送信する。単純な例では、1つのサーバと1つのクライアントが所与の要求および応答に対してあるが、必ずしもそうではなくてよい。
従来、メディア配信システムは、「ダウンロード」モデルまたは「ストリーミング」モデルのいずれかとして特徴付けられ得る。「ダウンロード」モデルは、メディアデータの配信とユーザまたは受信者デバイスに対するメディアの再生との間のタイミング独立性によって特徴付けられ得る。
一例として、ダウンロードモデルすなわちダウンロード構成において、メディアプレーヤまたは他のメディア消費者およびメディアに結合された受信機は、メディアがプレーヤ/消費者により必要とされるとき、あるいは使用されようとするときよりも十分前にダウンロードされる。メディアが使用される(消費される)とき、必要とされるほどの量が受信者において既に利用可能となっていることが好ましい。ダウンロードコンテキスト(download context)での配信は、HTTP、FTP、または、File Delivery over Unidirectional Transport(「FLUTE」)のようなファイル転送プロトコルを使用して実行されることが多く、配信レートは、TCP/IPのような混雑制御プロトコル(congestion control protocol)および/または背後フロー(underlying flow)によって決定され得る。フローまたは混雑制御プロトコルの動作は、ユーザまたは送付先デバイスに対するメディアの再生とは独立であってよく、この再生は、ダウンロードと同時に、または何らかの他の時点で行われ得る。
「ストリーミング」モードは、メディアデータの配信のタイミングと、ユーザまたは受信者デバイスに対するメディアの再生のタイミングとの密接な結合(tight coupling)によって特徴付けられ得る。このコンテキスト(context)での配信は、制御のためのリアルタイムストリーミングプロトコル(「RTSP」)およびメディアデータのためのリアルタイム転送プロトコル(「RTP」)のような、ストリーミングプロトコルを使用して実行されることが多い。配信レートはストリーミングサーバにより決めることができ、データの再生レートと一致することが多い。
「ダウンロード」モデルのいくつかの欠点は、配信と再生とのタイミング独立性により、メディアデータが再生のために必要な時に利用可能でないことが(例えば、利用可能な帯域幅がメディアデータレートに満たないことにより)あり、再生が一時的に停止し(「ストール(stalling)」)、これにより貧しいユーザ体験をもたらすこと、あるいはメディアデータが再生のはるか前にダウンロードされるように要求されることが(例えば、利用可能な帯域幅がメディアデータレートを超えることにより)あり、乏しいかもしれない受信デバイスの記憶リソースを消費し、コンテンツが最終的に再生されなかったり、他の方法で使用されなかったりすると無駄になってしまう、配信のための貴重なネットワークリソースを消費することであり得る。加えて、多くの場合において最も快いユーザ体験は、ユーザが何を見るかを決めてからほぼ直ぐにビデオを見られることであり、これは、ユーザが何を見るか決めてからビデオを注文し、見ることが可能になるまでに数分、数時間、またはことにより数日待たなければならないモデルとは対照的である。
「ダウンロード」モデルの利点は、そのようなダウンロードを行うために必要な技術、例えばHTTP、が非常に成熟し、広く展開され、広範囲の用途にわたって適用可能なことであり得る。そのようなファイルのダウンロードの高度なスケーラビリティのためのダウンロードサーバおよび解決法(例えば、HTTPウェブサーバおよびコンテンツ配信ネットワーク)は容易に利用可能であって、この技術に基づくサービスの展開を簡単かつ低コストにする。
「ストリーミング」モデルのいくつかの欠点は、一般に、メディアデータの配信のレートが、サーバからクライアントへの接続で利用可能な帯域幅に適合せず、帯域幅と遅延とを保証する特別なストリーミングサーバまたはより複雑なネットワークアーキテクチャが必要とされることであり得る。利用可能な帯域幅に従って配信データレートの変動をサポートするストリーミングシステムが存在する(例えば、Adobe Flash Adaptive Streaming)が、これらは一般に、全ての利用可能な帯域幅を利用することについて、TCPのようなダウンロード転送フロー制御プロトコルほど効率的ではなく、サーバ/クライアントストリーミングセッションをサポートするために特別なサーバ設備を必要とする。
最近では、「ストリーミング」モデルと「ダウンロード」モデルの組合せに基づく新たなメディア配信システムが開発され展開されている。そのようなモデルの例は、本明細書では「適応HTTPストリーミング」(本明細書では「AHS」と呼ばれる)と呼ばれる。通常、同じマルチメディアコンテンツは、例えば、異なる復号およびレンダリング能力を持つクライアントデバイスを考慮して帯域幅適合をさせるために、様々な異なる方法で符号化され得る。例えば、同じマルチメディアコンテンツ(同じ映画など)が、異なるコーデック、異なるフレームレート、異なるビットレート、あるいは異なる解像度に従って符号化されたり、異なるファイルフォーマットを使用してカプセル化されたりなどできる。特性の各ユニークな組合せがマルチメディアコンテンツの「表示(representation)」を構成する。
様々な表示(variety of representations)が、類似の復号およびレンダリング要件(similar decoding and rendering requirements)(例えば、類似のコーデック(similar codecs)、関連の解像度(related resolutions)、類似のファイルフォーマット(similar file formats)など)を有し得るが、同一マルチメディアコンテンツの異なる品質の表示を提供する異なるビットレートをもたらし得る。「適応セット」は1グループの表示であって、そのうちの1表示をクライアントが選択し得るものである。表示の所与の期間に対して、ビデオ適応セットおよびオーディオ適応セットのような複数の適応セットが存在できるが、本明細書の例では、単一の適応セットが一般性を損なわずに検討され得る。
表示は、例えば各セグメントがマルチメディアコンテンツのためのある期間、例えば10秒、1秒、30秒などに対応する複数のセグメントに分割されてよい。クライアントデバイスは現在利用可能な帯域幅の量を求め、次いで、表示のビットレートおよび現在利用可能な帯域幅に基づいて表示のうちの1つからの1つまたは複数の後続セグメントを要求できる。このようにして、帯域幅の量が増えると、クライアントデバイスは、比較的品質の高い表示からの(1つまたは複数の)セグメントを要求できるが、帯域幅の量が減ると、クライアントデバイスはその量の帯域幅が対応できる比較的品質の低い表示からの(1つまたは複数の)セグメントを要求できる。
表示の各セグメントはファイルに格納されてよく、URLはそのような各ファイルに関連付けられるので、URLは、標準的なHTTPウェブサーバからのセグメントファイルのHTTPダウンロードを要求するために、AHSクライアントによって使用され得る。この手法を使用すると、特定の開始点からメディアコンテンツを再生するためのユーザ要求に応答して、AHSクライアントは、セグメントをダウンロードするためのHTTP要求を発し、要求されたセグメントを再生のために受信できる。理想的には、ユーザによって要求された開始点からのメディアコンテンツの再生は、ユーザ要求後すぐにデバイスにおいて開始でき、メディアコンテンツの再生はその後この開始点からリアルタイムで、すなわち、追加のメディアデータが到着するのを待機する間メディア再生が一時的にストールするストール事象を伴わずに継続できる。いくつかのAHSシステムでは、HTTPバイト範囲要求もセグメントの部分を要求するために使用され得る。
AHSの1つの利点は、AHSが、標準的なHTTPウェブサーバ、すなわち、他のインターネットコンテンツを配信するために使用されるものと同一の設備を使用して展開できることである。AHSの別の潜在的利点は、複数の異なるタイプのネットワーク上で複数の異なるデバイスにわたって展開されているAHSクライアントが、再生デバイスの特性、ダウンロードに利用可能な帯域幅などのネットワーク条件、および他の要因に応じて再生を要求するためにどの表示が適しているかを動的に決めることが可能なことである。この最後の利点は特にモバイルデバイスについて重要であり、利用可能なネットワーク帯域幅は短い時間軸で大きく変動することがあるので、ストールを回避しつつ同時に所与のネットワーク条件に対して可能な最高品質の再生を提供するために、AHSクライアントは、1つの表示の複数のセグメントを要求することから、別の表示の複数のセグメントを要求することへと高速に変更する必要があり得る。さらに、他の特性、例えば、バッテリにおける残り電荷の量、または再生のディスプレイサイズなどが、モバイルデバイス上で高速に変更し得る。
表示の切り替えに使用されると考えるのに適切であろうフレーム、例えばIフレーム、は、PまたはBフレームのような他のタイプのフレームほどのビデオ圧縮を提供し得ない。しかしながら、切り替えがあまり頻繁ではない点で、表示の切り替えを試みるクライアントデバイスは、切り替えが可能になるまで長期間待たなくてはならないことがあり、これは、(例えば、最初に表示のための再生の開始が遅延するとか、表示の切り替えの後における再生イベントの再バッファ/詰まりとかにより)ユーザ体験を悪化させ得る。従って、マルチメディアコンテンツの表示の切り替えのために使用され得るフレームをどの程度頻繁に含めるかに関して、戦略的な決定が通常行われる。
1つの一般的なAHS解決法は、「HTTP Live Streaming」と題されたIETF草案において説明され、ドメイン「tools.ietf.org」を有するURLおよびそこにある「/html/draft−pantos−http−live−streaming−06」という名称のファイルにおいて見出され得る、Apple Inc.により最初に開発されたHTTP Live Streamingプロトコル(以後「HLS」と呼ばれる)であり、これはApple Live Streaming(本明細書では「ALS」と省略される)とも呼ばれることもある。別の一般的なAHS解決法は、例えば、ISO/IEC23009−1:2012において規定されるような、MPEG DASH規格(本明細書では「MPEG DASH」または「MPEG DASH規格」と省略される)で説明されている。
従って、必要とされるのは、表示の切り替えの間にシームレスなユーザビデオ体験を提供し、表示の切り替えの間のネットワークリソースの効率的な使用も可能にする、改善されたシグナリング方法とそのようなシグナリング方法の使用法である。
本明細書で説明される切替シグナリング方法は、本明細書で説明される適応HTTPストリーミングのための表示(representations for adaptive HTTP streaming)の改善された切り替えを提供し、適応HTTPストリーミング解決法(adaptive HTTP streaming solutions)に対するユーザ体験(user experience)と帯域幅の効率(bandwidth efficiency)との改善を可能にする。シグナリング方法は、セグメントマップを表示の各セグメントに関連付けることを含み、セグメントマップは、バイトオフセット情報(byte offset information)および場合によって(potentially)このセグメントについての他の情報と共に、関連するセグメント内の時間的な開始点および時間的な終了点(temporal start and temporal exit points)の両方を備える。セグメントマップは、適応ストリーミング解決法の表現のより高速な切り替えを提供すると同時に、切り替えの間にネットワークを通じてより少量のデータをダウンロードし、ビデオプレーヤによってある表示から別の表示に切り替える時のより円滑なビデオ再生(video playout)を可能にするために、クライアントによって有利に使用され得る。
これら実施形態は、表示切替情報をシグナリングすること、並びにこのような情報を使用してより良いユーザ視聴体験およびよりネットワーク効率の良い表示の切り替えとを提供することのために使用される方法に対する新たな改善を含む。新たな切替情報の例は、時間的な開始点、時間的な終了点、および関連するセグメントのセグメントマップ内のこれら点に関連するバイトオフセットを含む。開始点は、表示が切り替えられてこの表示の任意の後続終了点までシームレスに再生し続けることのできる時間的な点を示し、開始点に関連付けられるバイトオフセットはセグメント内のバイトの位置を示し、ダウンロードはその開始点から再生させるであろうデータを受信し始めることができる。同様に、終了点は、再生が終了点以前の表示の任意開始点で開始できて終了点までシームレスに再生させることのできる時間的な点を示し、終了点に関連付けられるバイトオフセットはセグメント内のバイトの位置を示し、ダウンロードはその終了点まで再生させるであろうデータを受信することを終えることができる。セグメント自体が暗号化されている場合でも、表示のシームレスな切り替えおよびネットワークリソースの効率的な使用をさせるために、十分な情報がセグメントマップに与えられる。
いくつかの実施形態では、異なる表示がセグメント化され、「SAP整列(SAP alignment)」が適応セットの異なる表示の間に存在する。異なる表示は複数の表示にまたがって一致する開始時間および終了時間を有し得る。いくつかの実施形態では、異なる表示がセグメント化され、「重複パッチ整列(overlap patch alignment)」が異なる表示の間に存在する。ここにおいて、開始点である提示開始時間および終了点である提示終了時間とが一致する。整列のタイプと、それが一部の、無しの、または全ての表示、もしくはペアまたはグループの表示に対して存在するかどうかとが1つのプロファイルでシグナリングされ得る。
これら実施形態は、既存のコンテンツの符号化処理とフォーマット処理とを変更する必要がないように、既存の展開を改善するために使用され得るので、コンテンツを受信し再生する既存のクライアントは影響を受けない。これら実施形態は、符号化されフォーマットされたコンテンツに関連付けられる、セグメントマップのような強化情報へのアクセス権を、生成し与える。これら実施形態はまた、生成された強化情報にアクセスするために拡張クライアントによって、利用されて上で説明された利益を提供できる方法を提供する。
以下の発明を実施するための形態は、添付の図面と共に、本発明の本質および利点のより良い理解をもたらすであろう。
提示時間順序(presentation time order)、フレーム依存構造(frame dependency structure)、およびクローズドGOP構造(closed GOP structure)を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の例を示す図。 提示時間順序、フレーム依存構造、およびオープンGOP構造を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の別の例を示す図。 提示時間順序、フレーム依存構造、および代替的なオープンGOP構造を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の別の例を示す図。 提示時間順序、フレーム依存構造、および代替的なGOP構造を有する符号化されたデータビデオストリームのためのファイルフォーマット順序の別の例を示す図。 図1に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。 図2に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示すもので、ファイルフォーマット順序が復号順序である例を示す図。 図2に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示すもので、ファイルフォーマット順序が提示順序である例を示す図。 図3に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。 図4に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。 図1に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す図。 図2に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示すもので、ファイルフォーマット順序が復号順序である例を示す図。 図2に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示すもので、ファイルフォーマット順序が提示順序である例を示す図。 図3に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示す図。 図4に示されるものと同じ構造を有するフレームを備える、表示のための終了点リストを示す図。 図4に示されるものと同じフレーム依存構造を有するフレームを備えるが、ファイルフォーマット順序が図4に示される復号順序ではなく提示時間順序である、表示のための開始点リストを示す図。 図4に示されるものと同じフレーム依存構造を有するフレームを備えるが、ファイルフォーマット順序が図4に示される復号順序ではなく提示時間順序である、表示のための終了点リストを示す図。 Dynamic Adaptive Streaming over HTTP(DASH)システムにおけるセグメントタイムラインファイルのシグナリングの例を示す図。 時間ベースとインデックスベースの混合されたセグメントURLテンプレートの生成の例を示す図。 セグメントURL交差規則の構築の例を示す図。 本発明の実施形態によるブロック要求ストリーミングシステムの要素を示す図。 コンテンツ取込システムによって処理されるデータを受信するためのブロックサービング設備(「BSI」)に結合されるクライアントシステムの要素をより詳しく示す、図18のブロック要求ストリーミングシステムを示す図。 取込システムのハードウェア/ソフトウェアの実装形態を示す図。 クライアントシステムのハードウェア/ソフトウェアの実装形態を示す図。 図18に示されるコンテンツ記憶装置に格納され得る、典型的なソースセグメントの詳細を示す図。 複数のバージョンのメディアストリームにわたる整列された探索点(seek points)を有する可変ブロックサイジングを示す図。 複数のバージョンのメディアストリームにわたる整列されていない探索点を有する可変ブロックサイジングを示す図。 図18に示されるコンテンツ記憶装置の可能な構造を示し、セグメントおよびmedia presentation descriptor(「MPD」)ファイル、並びにMPDファイル内のセグメント、タイミングおよび他の構造の内訳を含む図。 メタデータテーブルを示す図。 サーバからクライアントへのブロックおよびメタデータテーブルの送信を示す図。 複数のセグメントわたる連続的なタイミングと非連続的(discontinuous)なタイミングとを示す図。
図面において、同様の項目は同様の番号によって参照され、同様のまたは同一の項目の複数のインスタンスを示すために、括弧内でサブインデックスが与えられる。別段示されない限り、最後のサブインデックス(例えば、「N」または「M」)は、任意の特定の値に限定されることは意図されず、ある項目のインスタンスの数は、同じ数が例示されサブインデックスが再使用される場合であっても、別の項目のインスタンスの数と異なっていてよい。
詳細な説明
本明細書で説明されるように、ストリーミングシステムの目標は、メディアを、メディアの格納位置(あるいは、メディアが生成される位置)から、メディアが消費される位置、すなわち、クライアントによってユーザに対して提示されるか、人もしくは電子的な消費者によって他の方法で「使い果たされる」、位置へ移動させることである。理想的には、ストリーミングシステムは、受信端において中断されない再生(またはより一般的には、中断されない「消費」)を実現でき、クライアントは、ユーザが1つまたは複数のストリームを要求した後すぐにストリームまたはストリームの集合体を再生することを開始できる。効率性の理由のために、例えば、サーバとクライアントとの間の帯域幅の利用可能な量の変動によって、クライアントがあるストリームから別のストリームに切り替えるなどして、ストリームがもはや必要ではないことをユーザが示せば、各ストリームが中止されることも望ましい。ビデオのようなメディアコンテンツはシームレスに再生されるべきであるが、このメディアコンテンツを再生するために異なるストリームがクライアントによって選択される場合、限られた帯域幅を新たなストリームによって占有し、古いストリームを停止するのが好ましいことが多い。
本明細書で説明される実施形態による方法は、多くの利益を提供する。一部の適用形態は、本明細書で説明される特徴の全てよりも少ない特徴で、適切に満足のいく体験を提供し得るので、実行可能なシステムは本明細書で説明された特徴の全てを含む必要はないことを理解されたい。
所々でソフトウェア、命令、ステップ、処理、または手順などに関して説明されるが、説明される発明は、有形媒体に格納されるソフトウェアとして実装されてよく、かつ/または、本明細書で説明されるもの、もしくは他のもののような、メディアの送信と受信と消費とを支援するための適切なハードウェアを有する、コンピューティングデバイス、送信機、受信機などとして実装されてよいことを理解されたい。
適応HTTPストリーミング
適応HTTPストリーミング(「AHS」)は、特定タイプのストリーミングである。AHSでは、ソースが標準的なウェブサーバおよびコンテンツ配信ネットワーク(「CDN」)であってよく、標準的なHTTPを使用してよい。この技法はストリームのセグメント化および複数のストリームの使用に関与し、全てが標準化されたHTTP要求のコンテキスト(context)内にあり得る。ビデオのようなメディアは異なるバージョンまたは表示を形成するために複数のビットレートで符号化され得る。「バージョン(version)」および「表示(representation)」という用語は、本文書で同義に使用される。各バージョンすなわち表示は、場合によって各々数秒のオーダーのより小さな断片(pieces)へ分割され、セグメントを形成し得る。各セグメントは次いで、ファイルに関連付けられるURLを使用して要求される、別個のファイルとしてウェブサーバまたはCDN上に格納され得る。表示の提示時間の長さは全てのセグメントに対して同一でなくてよい。
クライアント側では、次にクライアントによって一緒にシームレスに継がれる個々のセグメントに対し、HTTPを使用して、要求が行われ得る。クライアントは、利用可能な帯域幅に基づいて異なるデータレートに切り替えることができる。クライアントはまた、各々が異なるメディアコンポーネント(media components)を提示する複数の表示を要求でき、これら表示においてメディアを一緒にかつ同期して提示できる。切り替えのためのトリガは、例えば、バッファ占有率およびネットワーク測定結果を含み得る。安定状態で動作している時、クライアントは目標のバッファ占有率を維持するようにサーバに対する要求を調整し得る。
AHSの利点は、ビットレートの適応、高速な始動と探索、および最小の不要配信を含み得る。これら利点は、配信を再生の前の短時間のみに制御することと、利用可能な帯域幅を最大限に使用する(可変ビットレートのメディアを通じて)ことと、ストリームのセグメント化およびインテリジェントなクライアント手順を最適化することとに由来する。
これらAHS解決法は多くの良好な特徴を有するが、改善できることがある。例えば、HLS解決法は、ある表示への切替点や複数の表示の切替点をシグナリングできる能力から利益を得るはずである。別の例として、MPEG DASHは、より効率的な切り替えおよびネットワークリソースのより効率的な使用をさせるオープンGOPビデオ符号化が利用される場合に、ある表示への切り替えや複数の表示の切り替えのより詳細なシグナリングから利益を得るはずである。別の例として、ストリームへ容易につながったり、ライブストリーミングセッションに再びつながったりすることをAHSクライアントにさせる自動化された方式でセグメントのURLを生成するための追加の方法が有益であろう。
本明細書で説明されるのは、表示の切り替えの間のシームレスなユーザビデオ体験を提供し、表示の切り替えの間のネットワークリソースの効率的な使用も可能にする、改善されたシグナリング方法とそのようなシグナリング方法の使用法である。
media presentation descriptionがAHSクライアントに提供されて、クライアントがストリーミングサービスをユーザに提供するために複数のファイルの集合体(例えば、本明細書で「3gpセグメント」と呼ばれる3GPPによって規定されるフォーマットにある)を使用できるようにし得る。media presentation description、並びに場合によってこのmedia presentation descriptionの更新は、クライアントが包含メディアを同期方式で提示でき、かつ探索、ビットレートの切り替え、および異なる表示におけるメディアコンポーネント(media components)を一緒に提示することのような高度な機能も提供できるように各々複数のメディアコンポーネントを含む複数のセグメントの構造化された集合体であるメディア提示を記述する。クライアントは、サービスの準備のために異なる方法でmedia presentation description情報を使用し得る。具体的には、AHSクライアントは、データがクライアント能力およびストリーミングサービス内のユーザに対して有用となるように集合体におけるどのセグメントにアクセスできるかをmedia presentation descriptionから判定できる。
いくつかの実施形態では、media presentation descriptionは静的であり得るが、セグメントは動的に生成され得る。media presentation descriptionは、サービスのアクセス時間およびダウンロード時間を最小にできるほどコンパクトであり得る。他の専用サーバ接続、例えば、クライアントとサーバとの間の定期的なまたは頻繁なタイミングの同期が最小になり得る。
メディア提示は、異なるタイプのアクセスネットワークへのアクセス権、異なる現在のネットワーク条件、ディスプレイサイズ、アクセスビットレート、およびコーデックのサポートのような、異なる能力を有する端末によるアクセスを許容するように構築され得る。クライアントは次いで、適切な情報を抽出して、ストリーミングサービスをユーザに提供できる。
media presentation descriptionはまた、要件に従って展開の柔軟性と小型化を許容し得る。
最も単純な場合には、代替的な各表示が、単一の3GPファイル、すなわち3GPP TS26.244において定義されるものに準拠するファイル、または、ISO/IEC14496−12または派生した規格において定義されるようなISOベースのメディアファイルフォーマット(3GPP Technical Specification26.244において説明される3GPファイルフォーマットなど)に準拠する任意の他のファイルに格納され得る。本文書の残りでは、3GPファイルに言及する場合、ISO/IEC14496−12および派生した規格が、ISO/IEC14496−12または任意の派生した規格において定義されるような、より一般的なISOベースのメディアファイルフォーマットに対して、全ての説明された機能を割り当てることができることを理解されたい。クライアントは次いで、ファイルの最初の部分を要求して、動画フラグメントの時間およびバイトオフセットと共に、メディアメタデータ(「moov」ボックスとも呼ばれるMovieヘッダボックスに通常格納される)を知ることができる。クライアントは次いで、HTTP partial get要求を発して、要求に応じて動画フラグメントを取得できる。
いくつかの実施形態では、各表示をいくつかのセグメントに分割するのが望ましいことがある。セグメントフォーマットが3GPファイルフォーマットに基づく場合、セグメントは、「時間的分割(time-wise splitting)」と呼ばれる、動画フラグメントの重複しない時間スライスを含む。これらセグメントの各々は複数の動画フラグメントを含んでよく、各々がそれ自体で有効な3GPファイルであり得る。別の実施形態では、表示がメタデータ(通常はMovieヘッダ「moov」ボックス)を含む初期セグメントとメディアセグメントのセットとに分割され、表示の各々は、メディアデータと初期セグメントの連結物とを含み、任意のメディアセグメントは有効な3GPファイルを形成し、さらに、初期セグメントの連結物およびある表示の全てのメディアセグメントは有効な3GPファイルを形成する。全体の提示は、各セグメントを再生し、次いで、各表示の開始時間に従ってファイル内のローカルのタイムスタンプをグローバルな提示時間にマッピングすることによって、形成され得る。
この説明全体で、「セグメント(segment)」への言及は、記憶媒体から完全にまたは部分的に構築されもしくは読み取られる、または、例えばHTTP要求を含むファイルダウンロードプロトコル要求の結果として他の方法で取得される任意のデータオブジェクトを含むものと理解されるべきであることに留意されたい。例えば、HTTPの場合、データオブジェクトは、ディスク上、またはHTTPサーバに接続されもしくはHTTPサーバの一部を形成する他の記憶媒体上に存在する実際のファイルに格納されてよく、またはデータオブジェクトは、HTTP要求に応答して実行されるCGIスクリプトや他の動的に実行されるプログラムによって構築されてよい。「ファイル(file)」および「セグメント(segment)」という用語は、別段規定されない限り、本文書では同義に使用される。HTTPの場合、セグメントは、HTTP要求応答の本体であると考えられ得る。
「提示(presentation)」および「コンテンツ項目(content item)」という用語は、本文書では同義に使用される。多くの例で、提示は、定められた「再生(playout)」時間を有する、オーディオ、ビデオ、または他のメディア提示であるが、他の変形も可能である。
「ブロック(block)」および「フラグメント(fragment)」という用語は、別段規定されない限り、本文書では同義に使用され、全般に、インデックスを付されたデータの最小の集合体(aggregation)を指す。利用可能なインデックス付けに基づいて、クライアントは、異なるHTTP要求において、フラグメントの異なる部分を要求でき、または、1つのHTTP要求において、1つまたは複数の連続するフラグメントまたはフラグメントの部分を要求できる。ISOベースのメディアファイルフォーマットに基づくセグメントまたは3GPファイルフォーマットに基づくセグメントが使用される場合、フラグメントは通常、動画フラグメントヘッダ(「moof」)ボックスとメディアデータ(「mdat」)ボックスの組合せとして定義される動画フラグメントを指す。
本明細書では、データを搬送するネットワークは、本明細書の説明を簡単にするためにパケットベースであることが仮定され、本開示を読めば、当業者が明細書で説明される本発明の実施形態を連続的なビットストリームネットワークのような他のタイプの送信ネットワークに適用できることが認識される。
これら例の多くでは、クライアントがメディアサーバまたは複数のメディアサーバに結合され、クライアントがメディアサーバまたは複数のメディアサーバからチャネルまたは複数のチャネルを通じてストリーミングメディアを要求すると仮定される。しかしながら、より複雑な構成も可能である。
シーケンスにおけるキーフレーム
ビデオコーディングでは、ビデオデータのいくつかのフレーム(「Iフレーム」として知られているイントラ予測モード符号化されたフレームなど)がビデオデータの他のフレームを参照することなく独立にコーディングされる。フレーム間の時間的な冗長性を利用するために、他のフレーム(すなわち、PおよびBフレームのようなインター予測モード符号化されたフレーム)は、以前のまたは後続のコーディングされたフレーム(参照フレームと呼ばれる)に対してコーディングされる。AHSの潜在的な障害の1つは、フレーム(または一般的には、他のデータ)が以前のフレームまたは後続のフレームに対してコーディングされる時にどのようにある表示から別の表示へシームレスに切り替えるかである。潜在的な障害とは、コンテンツの異なる表示が異なる表示において同時に提示されるべきフレームに対する異なるフレーム依存フレーム構造を使用して符号化されるビデオであり得ることである。依存フレーム構造が異なる表示にまたがって同じである場合でも、表示は異なる解像度を使用することがあり、品質が異なるので、ある表示におけるフレームを使用して他の表示のフレームを復号することは、一般に、ビデオのシームレスな再生にはつながらず、すなわち、劣悪なユーザ視聴体験をもたらし得る。従って、AHSに関する課題は、表示をどのようにシームレスに切り替えるかである。
キーフレームは、クライアントデバイスが、表示のより以前のデータにアクセスすることなく表示の復号を開始できるようになる時点の表示のフレームであり、すなわち、キーフレームは、Iフレームより後のフレームがIフレームより前のいずれのフレームにも依存しないような、Iフレームである。その上、キーフレームは、表示のための表示アクセス点、すなわち、ビデオのダウンロードおよび再生が開始し得る場所として機能し得る。さらに、そのようなキーフレームは、第1の表示から第2の表示に切り替える時に有用であることがあり、それは、第2の表示におけるキーフレームは、第2の表示における再生の開始点であり得るからである。例えば、クライアントデバイスは、第2の表示におけるキーフレームの時間的な位置により決まる第1の表示におけるデータを取り出し、次いで、第2の表示のキーフレームにおいて開始するデータを取り出すことによって、第1の表示から第2の表示に切り替えることができる。いくつかの限られた場合には、この戦略が表示の切り替えにおいてシームレスなユーザ体験を提供できるが、他の状況(situations)では、この単純な戦略が表示の切り替えにおいてシームレスなユーザ体験を提供することに失敗することがあり、それは、例えば、第2の表示におけるキーフレームよりも時間的に前にある第1の表示におけるフレームが、第2の表示のキーフレームよりも時間的に後にある第1の表示における他のフレームに依存するからである。
さらに、デジタル著作権管理(DRM)システムおよび/または暗号化の使用により、フレーム依存構造が、表示の切り替えおよびダウンロードの決定を行う受信クライアントの一部において利用可能ではなくなることが多い。
データ依存構造
MPEG1、MPEG2、またはH.264AVC符号化ビデオのような、一般のビデオ符号化技術では、単一の表示を有するフレームの提示時間順序は、フレームの復号順序とは異なり得る。提示時間順序は、フレームが他のフレームに対して表示される、連続的な順序である。
提示時間順序は、各フレームに関連付けられる提示時間によってより正確に決定され、2つのフレームの提示時間の差は、2つのフレームが表示されるべき時間の差である。本開示では、提示時間はより広く解釈されるべきである。例えば、コンテンツのある点における提示時間は、コンテンツの始まりの意図される再生開始時間である0から、上記の点までの時間として測定されてよく、例えば、上記の点がコンテンツの開始の20秒後に再生されることが意図される場合、その点に関連付けられる提示時間は20秒である。あるいは、当業者が認識するように、提示時間は、実時間またはUTC時間または他の等価な時間尺度に関して測定され得る。
復号順序は、フレームが様々なフレーム間の相互依存性を考慮して復号され得るフレームの順序である。各フレームに対して、そのフレームに依存する全てのフレームがそのフレームに対して順序的に後にある場合、フレームの順序は復号順序であると言われる。これは、復号されるべき次のフレームを既に復号されたフレームに基づいて復号させる。ストリーミング配信システムでは、フレームが簡単に復号され得るように順序通りにフレームが到達するのを確実にするために、フレームの送信順序は復号順序であることが普通である。以下の説明では、ファイルフォーマット順序がクライアントに配信されるべき表示のファイルまたはセグメント内のフレームの順序であると定義されるので、複数のファイルまたはファイルの複数の部分がクライアントによって要求される場合、ファイルフォーマット順序は、表示の部分がクライアントに配信される順序であることが多い。AHSシステムにおいて、表示内におけるフレームの順序、すなわちファイルフォーマット順序は復号順序であることが普通である。
図1は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのためのファイルフォーマット順序の例を示す。提示時間順序フレーム番号は、フレームに一意に番号を付けるために使用され、以後「提示時間順序フレーム番号(presentation time order frame number)」は「フレーム番号」と省略される。例えば、提示時間における最初のフレームは、以後フレーム1と呼ばれる。各フレームは、タイプ「I」(イントラコード (Intra-code))、「P」(予測 (Predictive))または「B」(双予測(Bi-predictive))と標識される。図1のフレーム依存構造は、フレーム間の弓状の線によって示される。2つのフレーム間の弓状の点線は、提示時間順序における後のフレームが前のフレームに依存することを示し、2つのフレーム間の弓状の実線は、提示時間順序における前のフレームが後のフレームに依存することを示す。「復号順序(decode order)」は、各フレームが、それに依存するあらゆるフレームより前にあるような順序である。
図1に示される例では、フレーム1はIフレームなので、フレーム1は、フレーム1に対して受信されたデータに基づいて復号可能である。フレーム2は、フレーム2に対して受信されたデータと共に(フレーム2はBフレームである)フレーム1および5に対して受信されたデータに基づいて、復号可能である。同様に、フレーム3はフレーム1、3、5を使用し、フレーム4はフレーム1、4、5を使用し、フレーム5はフレーム1、5を使用し、フレーム6はフレーム5、6を使用し、フレーム7はフレーム5、7を使用し、フレーム8はフレーム5、8を使用するので、フレーム1〜8は、フレーム1〜8のコンテンツが受信されると復号され得る。しかしながら、フレーム2はフレーム5がないと完全に復号できないので、フレームが「復号順序」で受信される場合、フレーム2は、5個のフレームの受信を待機しなければならないのではなく、わずか3個のフレーム(1,2,5)を受信した後で復号され得る。
図1に示される例では、フレームのフォーマット順序は、示される復号順序と同じである。ピクチャのグループ(または「GOP」)は、Iフレームにおいて開始し、シーケンスにおける次のIフレームの1つ前のフレームまでの、連続的なフレームのセットとして定義され得る。図1では、フレーム1〜8は1つのGOPを備え、フレーム9〜16は第2のGOPを備え、フレーム17は第3のGOPの始まりである。図1に示されるGOP構造は、GOPを備えるフレームの各々が他のGOPのフレームに依存しないので、「クローズドGOP構造(closed-GOP structure)」と呼ばれることがある。
図2は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのファイルフォーマット順序の別の例を示し、図1で説明されたものと同じ用語の用例に従う。この場合、提示時間順序において、GOPの最後のPフレームと次のGOPのIフレームとの間のBフレームは、次のGOPのIフレームに全て依存し得るので、GOPを備えるフレームの一部は他のGOPのフレームに依存し得る。図2に示されるGOP構造は、「オープンGOP構造(open-GOP structure)」と呼ばれることがある。
図3は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのファイルフォーマット順序の別の例を示し、図1で説明されたものと同じ用語の用例に従う。この場合、フレーム間にはより複雑な依存構造があり、すなわち、Bフレーム6、7、8はそれぞれ、提示時間順序で次のGOPの始まりにおけるIフレーム9の後にあるPフレーム13に依存する。
図4は、提示時間順序、フレーム依存構造、および符号化されたデータビデオストリームのファイルフォーマット順序の別の例を示し、図1で説明されたものと同じ用語の用例に従う。この場合、Bフレーム14、15、16はそれぞれ、次のGOPの始まりにおけるIフレーム17に依存するが、提示時間順序でそれらの前にあるいずれのフレームにも依存しない。
開始点および終了点
一般にストリーミングコンテンツに関して、コンテンツの表示のフレーム依存構造と、メディアコンテンツの表示を切り替えるために使用される方法、特に表示の切り替えができる時点をどのようにシグナリングするかとの間には関係がある。以下で説明されるような、開始点情報および終了点情報と一般に呼ばれる簡潔なフォーマットで生成されクライアントに伝えられ得る。コンテンツの1つの表示しかない場合、すなわち、別の表示への切り替えがサポートされない場合であっても、開始点情報および終了点情報は、他の目的でも、例えば、表示のどの部分を単一の要求でダウンロードすべきかを判定するために、使用され得る。
この議論では、フレームの提示時間は、コンテンツの他のフレームの表示開始時間に対する、フレームが表示を開始するようにされている時間であり、すなわち、フレームの提示開始時間であり、各フレームは、提示時間順序において次の連続するフレームのちょうど提示開始時間において表示を終了するようにされており、すなわち、フレームの提示終了時間は、提示時間順序において次のフレームの提示開始時間、または単に提示時間である。
以下の開始点および終了点の定義では、バイトオフセットは常に、フレームの始まりに対するバイトオフセットであると仮定され、提示時間は常に、フレームの提示開始時間(前のフレームの提示終了時間に等しい)であると仮定されるが、当業者が認識するようにこれら制約は緩められてよい。例えば、他の代替的な定義および説明では、データストリームにおける任意の点に対するバイトオフセット、例えば、ビデオのフレームを備えるデータの中心に対するバイトオフセットが考えられてよく、任意の有効な提示時間、例えば、フレームの提示開始時間と提示終了時間の中間にある提示時間が考えられてよい。
本明細書で使用される場合、開始点は、例えば、「(提示開始時間(entry presentation time),開始バイトオフセット(entry byte offset))」またはより簡潔に「(PT,BO)」の形式で開始の時間およびバイトオフセットの指示(indication)を使用して表されまたは示され得る。表示の開始点(PT,BO)は、表示のダウンロードがバイトオフセットBOから開始され終わりに進むように続く場合に、表示におけるコンテンツのビデオフレームが提示時間PTで開始して終わりに至る提示時間順序でシームレスに再生され得る、点である。従って、本明細書での説明では、開始点は2次元の点を規定し、一方の次元はファイルフォーマット順序に対応し、他方の次元は提示時間順序に対応する。本明細書において以下でより詳しく説明されるように、表示のためのそのような点のシグナリングは、表示の開始点として使用されてよく、すなわち、表示のダウンロードと再生をどこで開始するかを判定するために使用されてよい。
開始点(PT,BO)の定義によって、少なくともPTの提示開始時間を有する全てのフレームと、これらフレームが直接的または間接的のいずれかに依存する全てのフレームとが、表示内の少なくともBOであるバイトオフセットで開始することに留意されたい。
表示内の可能な各バイトオフセットBOに対して、(PT,BO)が開始点となり、全てのそのような可能な開始点のうちで提示時間PTが最小の提示時間となるようなユニークなPTが存在し、関数TentryB()は、TentryB(BO)=PTとなるように定義される。全ての可能なバイトオフセットBOに対するそのような開始点のリストは、「バイトオフセット開始点リスト(byte offset entry point list)」と本明細書では呼ばれる。
ファイルフォーマットが2つ以上のメディア、例えばオーディオデータおよびビデオデータの組合せ(mixture)を含む場合、開始点は、異なるメディアを考慮しなければならないことがあることに留意されたい。例えば、バイトオフセットBOに関連付けられる提示時間PTはPT1とPT2の大きい方として定義されてよく、PT1は第1のメディアのバイトオフセットBOについて達成され得る最小の提示時間であり、PT2は第2のメディアについて達成され得る最小の提示時間である。同様のコメントが、開始点および終了点に関連して以後説明される、全てのさらなる定義および方法に対して有効である。
同様に、可能な各提示時間PTに対して、(PT,BO)が開始点となり、バイトオフセットBOが全てのそのような開始点のうちで最大のバイトオフセットとなるようなユニークなBOが存在し、BentryT(PT)=BOと定義する。全ての可能な提示時間(possible presentation times)PTに対するそのような開始点のリストが本明細書で「提示時間開始点リスト(presentation time entry point list)」と呼ばれる。
異なるバイトオフセットを有するが同じ提示時間を有するバイトオフセット開始点リスト内に複数の開始点があり、異なる提示時間を有するが同じバイトオフセットを有する提示時間開始点リスト内に複数の開始点があることがあり得る。さらに、バイトオフセット開始点リスト内の開始点(PT,BO)が、PT’=PTかつBO’>BOである他の開始点(PT’,BO’)がバイトオフセット開始点リスト内にないようなものである場合、開始点(PT,BO)は、提示時間開始点リスト内にもあり、BO’=BOかつPT’<PTである他の開始点(PT’,BO’)が提示時間開始点リスト内にないという性質を有する。同様に、提示時間開始点リスト内の開始点(PT,BO)が、BO’=BOかつPT’<PTである他の開始点(PT’,BO’)が提示時間開始点リスト内にないようなものである場合、開始点(PT,BO)は、バイトオフセット開始点リスト内にもあり、PT’=PTかつBO’>BOである他の開始点(PT’,BO’)がバイトオフセット開始点リスト内にないという性質を有する。
バイトオフセット開始点リストと提示時間開始点リストの両方にある開始点を「主開始点(major entry point)」と分類し、これら開始点リストのうちの1つにしかない残りの開始点(entry point)を「副開始点(minor entry points)」と分類する。(PT,BO)が主開始点である場合、(PT,BO)=(TentryB(BO),BentryT(PT))であることに留意されたい。各副開始点(PT,BO)に対して、BO’>BOである主開始点(PT,BO’)またはPT>PT’である主開始点(PT’,BO)のいずれかが存在し、前者の場合、同じ提示時間で開始する同じコンテンツの再生が、主開始点を有するより後のバイトオフセットで開始され得るので、主開始点は副開始点より優れており、後者の場合、より多くのコンテンツの再生が主開始点を有する同じバイトオフセットで開始され得るので、主開始点は副開始点より優れている。
これら定義は、表示内におけるフレームの順序に関係なく、すなわち、ファイルフォーマット順序が表示内におけるフレームの提示時間順序、復号順序、あるいは何か他の順序かどうかにかかわらず有効であることに留意されたい。
同様に、形式「(提示終了時間(exit presentation time)、終了バイトフセット(exit byte offset))」の終了点(exit point)を定義する、ここで表示の終了点(PT,BO)の意味は、表示が始まりからバイトオフセットBOまでダウンロードされれば、表示におけるコンテンツのビデオフレームが、始まりから開始して提示時間PTまで表示時間順序でシームレスに再生され得ることである。従って、本明細書での説明では、終了点は2次元の点を規定し、一方の次元はファイルフォーマット順序に対応し、他方の次元は提示時間順序に対応する。本明細書において以下でより詳しく説明するように、表示のためのそのような点のシグナリングは、表示からの終了点として使用されてよく、すなわち、表示のダウンロードと再生をどこで終了するかを判定するために使用されてよい。
終了点(PT,BO)の定義によって、大きくともPTの提示終了時間を有する全てのフレームと、これらフレームが直接的または間接的のいずれかに依存する全てのフレームとは、表示内の大きくともBOであるバイトオフセットで終了することに留意されたい。
表示内の可能な各バイトオフセットBOに対して、(PT,BO)が終了点となり、全てのそのような可能な終了点のうちで提示時間PTが最大の提示時間となるようなユニークなPTが存在し、TexitB(BO)=PTと定義する。全ての可能なバイトオフセットBOに対するそのような終了点のリストを「バイトオフセット終了点リスト(presentation time exit point list)」として定義する。
同様に、可能な各提示時間PTに対して、(PT,BO)が終了点となり、バイトオフセットBOが全てのそのような終了点のうちで最小のバイトオフセットとなるようなユニークなBOが存在し、BexitT(PT)=BOと定義する。全ての可能な提示時間PTに対するそのような終了点のリストを「提示時間終了点リスト(presentation time exit point list)」として定義する。
異なるバイトオフセットを有するが同じ提示時間を有するバイトオフセット終了点リストに複数の終了点があり、異なる提示時間を有するが同じバイトオフセットを有する提示時間終了点リストに複数の終了点があることがあり得る。さらに、バイトオフセット終了点リスト内の終了点(PT,BO)が、PT’=PTかつBO’<BOである他の終了点(PT’,BO’)がバイトオフセット終了点リスト内にないようなものである場合、終了点(PT,BO)は、提示時間終了点リスト内にもあり、BO’=BOかつPT’>PTである他の終了点(PT’,BO’)が提示時間終了点リスト内にないという性質を有する。同様に、提示時間終了点リスト内の終了点(PT,BO)が、BO’=BOかつPT’>PTである他の終了点(PT’,BO’)が提示時間終了点リスト内にないようなものである場合、終了点(PT,BO)は、バイトオフセット終了点リスト内にもあり、PT’=PTかつBO’<BOである他の終了点(PT’,BO’)がバイトオフセット終了点リスト内にないという性質を有する。
バイトオフセット終了点リストと提示時間終了点リストの両方にある終了点を「主終了点(major exit point)」と分類し、これら終了点リストのうちの1つにしかない残りの終了点を「副終了点(minor exit points)」と分類する。(PT,BO)が主終了点である場合、(PT,BO)=(TexitB(BO),BexitT(PT))であることに留意されたい。各副終了点(PT,BO)に対して、BO’<BOである主終了点(PT,BO’)またはPT<PT’である主終了点(PT’,BO)のいずれかが存在し、前者の場合、同じ提示時間で終了する同じコンテンツの再生が、主終了点を有するより早いバイトオフセットで終了し得るので、主終了点は副終了点より優れており、後者の場合、より多くのコンテンツの再生が主終了点を有する同じバイトオフセットで終了し得るので、主終了点は副終了点より優れている。
これら定義は、表示内におけるフレームの順序とは関係なく、すなわち、ファイルフォーマット順序が表示内におけるフレームの提示時間順序、復号順序、あるいは何か他の順序かどうかにかかわらず有効であることに留意されたい。
図5は、図1に示されるものと同じ構造を有するフレームを備える、表示のための開始点リストを示す。図5に示される第1の表は、フレーム番号に従ってファイルフォーマット順序でリストされたフレームを、各フレームの始まりに対するバイトオフセットと共に示す。図5に示される第2の表は、提示時間開始点リストを示す。図5に示される第3の表は、バイトオフセット開始点リストを示す。図5に示される第4の表は、主開始点のリストである。これら最後の3つの表では、開始提示時間は再生され得る最初のフレームのフレーム番号であり、以後「開始フレーム(entry frame)」と呼ばれる。図5では、主開始点が、(1,0)、(9,27537)、および(17,54523)である。全ての主開始点に対し、ファイルフォーマット順序で開始フレームの後にある全てのフレームが再生されることになり、これはクローズドGOP構造の結果であることに留意されたい。フレーム番号を使用して提示時間を示すことは、提示時間を表すための唯一の方法であり、一般に再生されるべきメディアまたはデータをフレームのような別々の時間ステップにおいて表すことのできないフォーマットを含む、他の多くの提示時間フォーマットが存在することに留意されたい。
図6、図7、および図8は、図2、図3、および図4にそれぞれ示される構造と同じ構造を有するフレームを備える、表示の開始点リストをそれぞれ示す。図6(a)、図6(b)、図7、および図8の各々に示される5つの表は、図5について上で説明されたものと同じフォーマットと意味とを有するが、図6(a)はファイルフォーマットの復号順序を使用し、一方図6(b)は提示順序をファイルフォーマット順序として使用する。
図6(a)では、主開始点が、(1,0)、(9,22033)、および(17,41993)である。主開始点(9,22033)に対しては、ファイルフォーマット順序で開始フレーム9の後にある全てのフレーム、例えば、フレーム6、7、および8が再生されるとは限らないことに留意されたい。これは、オープンGOP構造の結果である。
図7では、主開始点が、(1,0)、(9,22031)、および(17,48303)である。主開始点(9,22031)に対しては、ファイルフォーマット順序における最初のダウンロードされるフレームはフレーム9ではなくフレーム13であるので、ダウンロードされる最初のフレームは、この主開始点に対して再生される最初のフレームではないことに留意されたい。さらに、ファイルフォーマット順序でフレーム13の後にあるフレーム6、7、および8は、この主開始点からダウンロードされるべきであるが、再生されるべきではない。これは、この代替的なオープンGOP構造の結果である。
図8では、主開始点は、(1,0)、(9,27537)、および(14,48303)である。主開始点(14,48303)に対しては、ファイルフォーマット順序における最初のダウンロードされるフレームはフレーム14ではなくフレーム17であるので、ダウンロードされる最初のフレームは、この主開始点に対して再生される最初のフレームではないことに留意されたい。これは、この代替的なGOP構造の結果である。
図9、図10、図11、および図12は、図1、図2、図3、および図4にそれぞれ示される構造と同じ構造を有するフレームを備える、表示の終了点リストをそれぞれ示す。図9、図10(a)、図10(b)、図11、および図12の各々に示される5つの表は、図5について上で説明されたものと同様のフォーマットと意味とを有する。違いは、終了点が開始点の代わりに示され、提示終了時間が再生され得る最後のフレームのフレーム番号であることにあり、以後「終了フレーム(exit frame)」と呼ばれる。図10(a)はファイルフォーマットの復号順序を使用し、図10(b)はファイルフォーマット順序として提示順序を使用する。
別の例として、図13は、図4に示されるものと同じ依存フレーム構造を有するフレームを備えるが、ファイルフォーマット順序が図4に示される復号順序でなく提示時間順序である、表示のための開始点リストを示し、図14は、対応する終了点リストを示す。
表示の各主開始点および主終了点をシグナリングすることが適切である場合があるが、一方で他の場合には、この量のシグナリングは、大量のシグナリングオーバーヘッドを示し得るので、選択された主開始点および主終了点のみがシグナリングされる。他の場合には、副開始点と副終了点の一部をシグナリングすることも適切である。
開始点と終了点とを生成するための方法
実装において、開始点生成器と終了点生成器の実装形態は、入力のメディア符号化フォーマットに依存し得る。例えば、入力はMPEG2TSフォーマットへとカプセル化されるMPEG2符号化コンテンツであってよく、入力はMPEG2TSフォーマットへとカプセル化されるH.264AVCコンテンツであってよく、または入力はISOファイルフォーマットへとカプセル化されるH.264AVCコンテンツであってよい。他のより詳細な例として、H.264AVCコンテンツは「クローズドGOP」を使用して符号化されてよく、または「オープンGOP」を使用して符号化されてよく、または非常に汎用的なビデオフレーム間の依存構造にせさるように符号化されてよい。他の例として、Bフレームが除外されたり、Bフレームが許容されたりしてよい。
好ましくは、異なる開始点生成器および終了点生成器の実装形態の出力フォーマットは、それぞれ、方法に対する特定のメディア符号化フォーマットの入力とは独立の、同じ開始点フォーマットおよび終了点フォーマットである。これは、元のコンテンツのメディア符号化フォーマットとは独立にセグメントマップを生成するためにセグメントマップ生成器が使用され得るので有利であり、すなわち、同じセグメントマップ生成器は、元のメディア符号化フォーマットがISOファイルフォーマットで搬送される「オープンGOP」を伴うH.264AVCかどうかにかかわらず、または、メディア符号化フォーマットがMPEG TSフォーマットで搬送される「クローズドGOP」を伴うがBフレームを伴わないMPEG2TSであるかどうかにかかわらず使用され得る。
好ましくは、開始点生成器および終了点生成器の出力は開始点と終了点の十分に濃密なセットをそれぞれ含み、セグメントマップ生成器がクライアントによって使用され得るセグメントマップを生成するために選択対象である十分な開始点と終了点とを有し、エンドユーザに素晴らしいストリーミング体験を提供するようにすべきである。これは、開始点生成器および終了点生成器がAHSストリーミング方法の仕様を考慮する必要がなく、代わりにAHSストリーミング論理の仕様がセグメントマップ生成器によって考慮され得るので、好ましい。
任意のフレームFに対して、フレームFが依存する全てのフレームがファイルフォーマット順序でフレームFよりも前にある場合、表示内におけるフレームのファイルフォーマット順序が復号順序にあると言われる。
以下で説明される開始点および終了点を生成する実施形態および方法では、バイトオフセットは常に、フレームの始まりに対するバイトオフセットであると仮定され、提示時間は常に、フレームの提示開始時間(以前のフレームの提示終了時間に等しい)であると仮定されるが、当業者が認識するようにこれら制約は緩められてよい。
ファイルフォーマット順序が復号順序である場合における終了点生成方法の第1の実施形態は次の通りである。ファイルフォーマット順序における各フレームの提示時間と各フレームに対するバイトオフセットとを決定する。各提示時間PTに対して、PTよりも厳密に短い提示時間を有する全てのフレームよりもファイルフォーマット順序で後にある全てのフレームのうちで最小のバイトオフセットを有する、フレームに対するバイトオフセットBOを決定する。決定された終了点は(PT,BO)である。(ファイルフォーマット順序においてそのようなフレームがない場合、BOは、表示の終わりに対するバイトオフセットである。)BO=BexitT(PT)であることに留意されたい。この実施形態では、終了点生成方法は、背後にあるフレーム依存構造を分析して、終了点のリストを生成する必要がないことに留意されたい。これは、ファイルフォーマット順序が復号順序であるという特性が、ファイルフォーマット順序およびフレームの提示時間に基づいて終了点を効率的に決定するのに、十分なフレーム依存構造を表すからである。
第1の実施形態によって生成されたリスト内の複数の連続する終了点が同じ終了バイトオフセットBOを有する場合、提示時間順序における最後の終了点、すなわち、同じ終了バイトオフセットBOを有するこれら連続する終了点のうちで最大の提示時間PTを有する終了点が主終了点であり、残りが副終了点である。
表示のファイルフォーマット順序が復号順序である場合の、終了点生成方法の第2の実施形態は次の通りである。ファイルフォーマット順序における各フレームの提示時間と各フレームに対するバイトオフセットとを決定する。各バイトオフセットBOに対して、BOでまたはその後に開始するファイルフォーマット順序における全てのフレームのうちで最早の提示時間PTを決定する。決定された終了点は(PT,BO)である。(1つの追加の終了点(PT,BO)が存在し、BOは表示の終わりに対するバイトオフセットであり、PTは表示の提示終了時間である。)PT=TexitB(BO)であることに留意されたい。この実施形態では、終了点生成方法は、背後にあるフレーム依存構造を分析して、終了点のリストを生成する必要がないことに留意されたい。これは、ファイルフォーマット順序が復号順序であるという特性が、ファイルフォーマット順序およびフレームの提示時間に基づいて終了点を効率的に決定するのに、十分なフレーム依存構造を表すからである。
第2の実施形態によって生成されたリスト内の複数の連続する終了点が同じ提示終了時間PTを有する場合、ファイルフォーマット順序における最早の終了点、すなわち、同じ提示終了時間PTを有するこれら連続する終了点のうちで最小のバイトオフセットBOを有する終了点が主終了点であり、残りが副終了点である。
図5〜図14は、開始点と終了点とを生成するための例と可能なフォーマットとを示す。ファイルフォーマット順序は、図5〜図12に示される例に対して示される復号順序であるので、上で説明された終了点生成方法は、図9〜図12に示される終了点リストを生成するために使用されてよく、第1の実施形態は、これら例の各々において第2の表を生成するために使用されてよく、第2の実施形態は、これら例の各々において第3の表を生成するために使用されてよく、これら例の各々において主終了点の第4の表は、上で説明された2つの実施形態のいずれかを使用して生成され得る。
終了点生成器に対する多くの代替形態および拡張がある。例えば、終了点生成方法の第2の実施形態は、ファイルフォーマットが連続的に生成される時のように、すなわち各バイトオフセットBOに対して、オンラインの方法で終了点を生成でき、方法は、ファイルフォーマット順序でBOよりも前に開始する全てのフレームのうちで欠落フレームの最早の提示時間PTを決定でき、終了点は(PT,BO)である。例えば、図1において、バイトオフセットBOがフレーム5の始まりに対するものである場合、ファイルフォーマット順序でBOよりも前に開始するフレームはフレーム1なので、欠落フレームの最早の提示時間PTはフレーム2の提示時間であり、これは、提示終了時間がフレーム1の提示終了時間であることを意味する。別の例として、図1において、バイトオフセットBOがフレーム13の始まりに対するものである場合、ファイルフォーマット順序でBOよりも前に開始するフレームはフレーム1、5、2、3、4、6、7、8および9なので、このリスト内の欠落フレームの最早の提示時間PTはフレーム10の提示時間であり、これは、提示終了時間がフレーム9の提示終了時間であることを意味する。BOでまたはその後に開始するファイルフォーマットにおけるフレームについての情報は必要とされないことに、留意されたい。当業者が認識するように、ファイルフォーマット順序でBOよりも前にある全てのフレームの提示時間からのPTの効率的な決定をさせる標準的データ構造と方法とが存在する。
図13および図14に示される例では、ファイルフォーマット順序は、図4に示される復号順序ではないが、ファイルフォーマット順序は提示時間順序であることに留意されたい。ファイルフォーマット順序が復号順序ではないので、終了点生成方法の第1の実施形態は図14に示される第2の表を生成せず、同様に、終了点生成方法の第2の実施形態は、図14に示される第3の表を生成しないことを、立証できる。しかしながら、以下で説明される終了点生成方法の第3の実施形態は、図14に示される表を生成するために使用され得る。
背後にあるファイルフォーマット順序およびフレーム依存構造とは独立に使用され得る終了点生成方法の第3の実施形態は、次のように説明され得る。各バイトオフセットBOに対して、大きくともPTの提示終了時間を有する全てのフレームが、ファイルフォーマット順序でBOよりも前に開始するフレームのみに、直接的または間接的のいずれかに依存するように、最遅の提示時間PTを決定する。次いで、決定された終了点は(PT,BO)である。PT=TexitB(BO)であることに留意されたい。終了点生成方法の第3の実施形態は、ファイルフォーマットが連続的に生成される時のように、すなわち各バイトオフセットBOに対して、オンラインの方法で終了点を生成し、ファイルフォーマット順序でBOよりも前にあるフレームの提示時間およびフレーム依存構造のみに基づいて、BOに関連付けられる提示終了時間を決定できる。
BOに関連付けられる提示終了時間を決定するための1つの処理は、BOよりも前に開始するフレームの第1のリストを決定し、BOでまたはBOを過ぎて開始するフレームに直接的または間接的のいずれかに依存する全てのフレームを、フレームの第1のリストから除去することによって、フレームの第1のリストからフレームの第2のリストを決定することであり、PTは、フレームの第2のリストにない全てのフレームのうちで最小のフレーム番号を有するフレームの提示時間である。フレームの第2のリストが次のように決定され得ることに、留意されたい。BOでまたはBOを過ぎて開始するフレームに直接依存する全てのフレームを、フレームの第1のリストから選択することによって、フレームの第3のリストを決定する。フレームの第2のリストが次いで、フレームの第1のリスト内のフレームのうちのフレーム依存構造から、かつフレームの第3のリストから決定され得る。
当業者が認識するように、上で説明された実施形態に対して可能な多くの代替形態および最適化が存在する。例えば、特定のバイトオフセットBOに関連付けられる提示終了時間を決定するための、上で説明された処理は、BOのための情報とリストとを決定するための、BOの前のバイトオフセットからの情報とリストとを保持する全体の処理に統合され得る。別の最適化として、リストフォーマット以外のデータ構造が使用されてよく、リストの一部分のみについての詳細な情報が、明示的に表されてよい。例えば、フレーム依存構造が、ファイルフォーマット順序でそのフレームの後または前にある多くともD個のフレームであるフレームに、各フレームが直接的または間接的のいずれかに依存するようなものであることが知られている場合、BOよりも前または後に開始するD個のフレームに対する詳細な情報が保持されてよく、フレームについてのあらゆる他の情報が、暗黙的に、または圧縮されたフォーマットで表され得る。
開始点発生方法の第1の実施形態は、次の通りである。よくあるように、次のような特性を有する、IDRフレームと省略されることの多いIndependent Data Refreshフレームと以後呼ばれるタイプのフレームがあると、仮定する。フレームFがいずれの他のフレームにも依存せず、フレームFの提示時間よりも長い提示時間を有する全てのフレームF’、および、そのようなフレームF’が依存する全てのフレームが全て、ファイルフォーマット順序でフレームFの後にある場合、フレームFはIDRフレームである。
開始点生成方法の第1の実施形態は、IDRフレームを識別でき、そのような各IDRフレームFに対して、ファイルフォーマット順序におけるフレームFに対するバイトオフセットBOを決定でき、次いで、開始点を(PT,BO)として決定でき、PTはフレームFの提示時間である。この第1の実施形態では、開始点生成方法は、背後にあるフレーム依存構造を分析して、開始点のリストを生成する必要がないことに留意されたい。これは、IDRフレームの定義が、開始点を効率的に決定するのに十分なフレーム依存性とファイルフォーマット構造とを表すからである。
開始点生成方法の第1の実施形態に対する、多くの代替形態および拡張が存在する。例えば、開始点生成方法の第1の実施形態は、ファイルフォーマットが連続的に生成される時のように、すなわちファイルフォーマット順序におけるフレームFに対する各バイトオフセットBOに対して、オンラインの方法で開始点を生成し、FがIDRフレームであるかどうかを判定し、IDRフレームである場合、フレームFの提示時間PTを決定し、開始点(PT,BO)を決定できる。フレームFの後にあるファイルフォーマットにおけるフレームについての情報は必要とされないことに、留意されたい。
背後にあるファイルフォーマット順序およびフレーム依存構造とは独立に使用され得る終了点開始方法の第2の実施形態は、次のように説明され得る。各バイトオフセットBOに対して、少なくともPTの提示時間を有する全てのフレームが、ファイルフォーマット順序でBOでまたはBOよりも後に開始するフレームのみに、直接的または間接的のいずれかに依存するように、最早の提示時間PTを決定する。次いで、決定された終了点は(PT,BO)である。PT=TentryB(BO)であることに留意されたい。
図5、図6(a)、図7、および図8は、それぞれ図1、図2、図3、および図4に示されるフレーム依存構造に対応する、ファイルフォーマット順序と、対応する生成された開始点リストとの、異なる例を示す。図6(b)および図13は、ファイルフォーマット順序が提示時間順序である場合の、それぞれ図2および図4に示されるフレーム依存構造に対応する、ファイルフォーマット順序と対応する生成された開始点リストとの別の例を示す。これら開始点の特性の一部は、上で既に説明されている。
図5、図6(a)、図6(b)、図8、および図13において、フレーム依存構造およびファイルフォーマット順序は、各々のIフレームがIDRフレームであり、従って開始点生成方法の第1の実施形態が開始点のリストを生成できるようなものである。第1の実施形態によって生成される開始点リストは、図5、図6(a)、および図6(b)に対する主開始点リストの第4の表に対応する。第1の実施形態によって生成される開始点リストは、図8に対する主開始点リストの第4の表とは異なり、具体的には、図8に示される主開始点(14,48303)は、第1の実施形態が生成するであろう開始点(17,48303)よりも好ましい。第1の実施形態によって生成される開始点リストは、図13に対する主開始点リストの第4の表のサブセットであり、具体的には、図13に示される3個の主開始点(14,48303)、(15,51032)および(16,54523)は、第1の実施形態によっては生成されないであろう。
図7では、ラベル9を有するIフレームはIDRフレームではなく、ラベル10、11、および12を有するフレームはファイルフォーマット順序においてIフレームの後に続くので、それらのフレームは全て、Iフレームに先行するラベル13を有するフレームに依存することに留意されたい。
第2の実施形態によって生成される開始点リストは、図5、図6(a)、図6(b)、図7、図8、および図13に対する主開始点リストの第3の表に対応する。
第2の実施形態によって生成されたリスト内の複数の連続する開始点が同じ提示開始時間PTを有する場合、ファイルフォーマット順序における最遅の開始点、すなわち、同じ提示開始時間PTを有するこれら連続する開始点のうちで最大のバイトオフセットBOを有する開始点が主開始点であり、残りが副開始点である。図5、図6(a)、図6(b)、図7、図8、および図13における第4の表に示されている主開始点リストは、一般に、第2の実施形態によって生成される開始点リストに基づいて、この主開始点選択処理から生成され得る。

フレームが、ファイルフォーマット順序に関してD個よりも多くのフレーム分だけ離れているいずれのフレームにも、直接的または間接的のいずれかに依存しないようにフレーム依存構造が限定されるような、いくつかの正の整数値Dがあると仮定する。次いで、開始点生成方法の第2の実施形態は、ファイルフォーマットが次のように連続的に生成される時のように、すなわち各バイトオフセットBOに対して、オンラインの方法で生成されてよく、ファイルフォーマット順序でBOよりも前にあるフレームからBOよりも後の多くともD個のフレームまでの、提示時間およびフレーム依存構造のみに基づいて、BOに関連付けられる提示開始時間を決定できる。
BOに関連付けられる提示開始時間を決定するための1つの処理は、BOよりも前に開始する最大のフレーム番号を有するフレームと共にファイルフォーマット順序においてバイトオフセットBOで開始するD個の連続するフレームとを備える、D+1個のフレームの第1のリストを決定し、BOよりも前に開始するフレームに直接的または間接的のいずれかに依存するフレームの第1のリスト内のフレームのうちで、フレームの最大のフレーム番号である第1のフレーム番号を決定することであり、PTは、第1のフレーム番号よりも大きなフレーム番号を有するフレームの提示時間である。ファイルフォーマット順序においてフレームの第1のリストよりも先にあるいずれのフレームも、BOよりも前に開始する任意のフレームに、直接的または間接的のいずれかに依存し得ないことを留意されたい。第1のフレーム番号は、次のように決定され得る。BOよりも前に開始するフレームに直接依存する全てのフレームを、フレームの第1のリストから選択することによって、フレームの第2のリストを決定する。第1のフレーム番号が次いで、フレームの第1のリスト内のフレームのうちのフレーム依存構造から、かつフレームの第2のリストから決定され得る。
当業者が認識するように、上で説明された実施形態に対して可能な多くの代替形態および最適化が存在する。例えば、特定のバイトオフセットBOに関連付けられる提示開始時間を決定するための、上で説明された第2の実施形態は、BOのための情報とリストとを決定するための、BOの前のバイトオフセットからの情報とリストとを保持する全体の処理に統合され得る。別の最適化として、リストフォーマット以外のデータ構造が使用されてよく、リストの一部分のみについての詳細な情報が、明示的に表されてよい。例えば、BOで開始するD個の連続するフレームのための詳細な情報が保持されてよく、フレームについての任意の他の情報は、暗黙的に、または圧縮されたフォーマットで表され得る。
シームレスな切替方法
1.開始点と終了点とを使用したシームレスな切替方法
表示に関連付けられる開始点と終了点の特性は、次の通りである。開始点と共にリストされた提示開始時間は再生を開始して、表示の終了点と共にリストされた任意の後続の提示終了時間までシームレスに継続できる表示でのデータの提示時間を示し、開始点に関連付けられるバイトオフセットはその提示時間で再生を開始させるであろうデータを受信するダウンロードが開始できるセグメント内のバイト位置を示す。同様に、終了点と共にリストされた提示終了時間は、表示の開始点と共にリストされた任意の以前の提示開始時間で開始したシームレスな再生を終了できる表示でのデータの提示時間を示し、終了点に関連付けられるバイトオフセットはその提示時間で再生を終了させるであろうデータを受信するダウンロードが終了できるセグメント内のバイト位置を示す。
第1の表示から第2の表示に切り替えるためのクライアント方法の概要は、次の通りである。クライアントが提示時間Tの後の可能な最早の提示時間においてシームレスな切り替えを行うことを望むと決定したと仮定し、ここで例えばTは、メディアバッファにおいて既に利用可能な第1の表示、または、メディアバッファへダウンロードされるように既に要求されている第1の表示からの最遅の提示時間である。第2の表示に対する利用可能な開始点から、クライアントは、少なくともTである第2の表示の全ての提示開始時間のうちでTSが最早となるように開始点(TS,BOS)を選択できる。第1の表示に対する利用可能な終了点から、クライアントは、少なくともTSである第1の表示の全ての提示終了時間のうちでTEが最早となるように、終了点(TE,BOE)を選択できる。クライアントは、第1の表示から終了バイトオフセットBOEまでのデータをダウンロードでき、開始バイトオフセットBOSで開始する第2の表示からのデータをダウンロードできる。クライアントは、第1の表示および第2の表示からのダウンロードされたデータをメディアプレーヤに提供し、第1の表示から時刻TEまで(時刻TEを含む)をビデオ復号し、時刻TSで開始しそこから継続する第2の表示をビデオ復号するように、メディアプレーヤに命令できる。TSがTEに等しくない場合、すなわちTE>TSである場合、メディアプレーヤは、第1の表示から何らかの提示時間TUまで、ディスプレイに対してビデオをレンダリングして、次いで、提示時間TUで開始する第2の提示からの表示を継続すると決定でき、TUは、TSからTEまでの間にある。いくつかの実施形態では、TU=TSであれば好ましく、それは、開始点における第2の表示の再生の新たな開始が可能になるからである。
第1の代替的なクライアント切替方法として、クライアントが提示時間Tの前の可能な最遅の提示時間においてシームレスな切り替えを行うことを望むと決定したと仮定する。第1の表示に対する利用可能な終了点から、クライアントは、大きくともTである第1の表示に対する全ての提示終了時間のうちでTEが最遅となるように終了点(TE,BOE)を選択できる。第2の表示に対する利用可能な開始点から、クライアントは、大きくともTEである第2の表示に対する全ての提示開始時間のうちでTSが最遅となるように、開始点(TS,BOS)を選択できる。開始点および終了点が選択されると、第1の代替的なクライアント方法の残りは、上で説明されたようなものであり得る。
第2の代替的なクライアント切替方法として、クライアントが提示時間Tに可能な限り近い提示時間においてシームレスな切り替えを行うことを望むと決定したと仮定する。第1の表示に対する利用可能な終了点から、クライアントは、少なくともTである第1の表示に対する全ての提示終了時間のうちでTEが最早となるように終了点(TE,BOE)を選択できる。第2の表示に対する利用可能な開始点から、クライアントは、大きくともTEである第2の表示に対する全ての提示開始時間のうちでTSが最遅となるように開始点(TS,BOS)を選択できる。開始点および終了点が選択されると、第2の代替的なクライアント方法の残りは、上で説明されたようなものであり得る。
第3の代替的なクライアント切替方法として、クライアントは、大きくともTである第2の表示の全ての開始点のうちでTSが最遅の提示開始時間となるように、第2の提示に対して利用可能な開始点から開始点(TS,BOS)を選択できる。第1の表示に対する利用可能な終了点から、クライアントは、TSの後である第1の表示の全ての提示終了時間のうちでTEが最早となるように、終了点(TE,BOE)を選択できる。
第4の代替的なクライアント切替方法として、クライアントが、例えば、第1の表示からダウンロードしたバッファに既にあるメディアに基づいて、第1の表示におけるバイトオフセットBOよりも前の可能な最遅の提示時間において、第1の表示から第2の表示へシームレスな切り替えを行うことを望むと決定したと仮定し、BOは、メディアバッファに既にダウンロードされている第1の表示の一部分の終わりのバイトオフセットであってよく、または、メディアバッファへのダウンロードを既に要求されている第1の表示の終わりのバイトオフセットであってよい。第1の表示に対して利用可能な終了点から、クライアントは、大きくともBOである第1の表示に対する全ての終了バイトオフセットのうちでBOEが最遅となるように終了点(TE,BOE)を選択できる。第2の表示に対して利用可能な開始点から、クライアントは、大きくともTEである第2の表示に対する全ての提示開始時間のうちでTSが最遅となるように開始点(TS,BOS)を選択できる。開始点および終了点が選択されると、第4の代替的なクライアント方法の残りは、上で説明されたようなものであり得る。当業者が認識するように、例えば、第4の代替形態のように、第1の表現に対する初期バイトオフセットに基づく切り替えの決定に基づき、第2の代替形態で説明されたように、これに基づいて開始点と終了点とを決定する、上記の組合せである他の代替的なクライアント切替方法がある。
第1、第2、および第4の代替的なクライアント切替方法に対して、第1の表示のために選ばれた終了点は、第2の表示のために選ばれた開始点とは独立であることに留意されたい。従って、これら代替形態は、切り替え先として考えられ得る2つ以上の第2の表示の選択肢があり得る場合に、魅力的な方法を提供し、クライアントは、可能性のある第2の表示のいずれを選ぶかを決める前に、第1の表示のダウンロードをどこで完了するかを決めることができる。所与の提示時間TまたはバイトオフセットBOの前に、第1の表示に対する終了点を選ぶ代替形態は、利用可能な帯域幅が減少したことが原因でクライアントがレートの低い第2の表示に下がる必要がある場合に適用可能であることがあり、この場合、提示時間TまたはバイトオフセットBOは、最遅の利用可能な提示時間、または第1の表示に対して利用可能なもしくはまもなく利用可能になるバイトオフセットであってよく、利用可能な帯域幅が減少した場合に、よりレートの高い第1の表示から追加のデータをダウンロードする必要がなく、それは、このことが、再生をシームレスに継続することを可能にするのに十分なデータが第2の表示から届く前に、メディアバッファが使い果たされる確率を最小にする傾向があるからである。
2.開始点および終了点に基づくダウンロード部分の選択
本開示を読んだ後に当業者が認識するように、クライアントが開始点および終了点情報を利用できる多くの方法がある。例えば、ユーザ体験に関する決定的な要因は、ユーザが、例えば、ウェブページにおけるリンクをクリックすることによって、または、マウスを使用してビデオの再生位置を異なる再生時間へとドラッグすることによって、ビデオの再生を要求した時から、ビデオの再生が開始するまでにかかる時間である。この時間が短いほど、一般にユーザ体験は良好になり、特にユーザが異なるコンテンツを試しに見ている場合、すなわち、あるコンテンツから別のコンテンツへとかなり頻繁に移動している場合、または、特定のコンテンツ内の異なる開始位置を探している場合、特に良好になる。従って、この始動時間を最小にすることは、重要な問題である。
開始点情報および終了点情報へのアクセス権を有するクライアントは、再生がコンテンツの単一の表示からのものである場合、すなわち、ある表示から別の表示への切り替えがない場合でも、この情報を使用して、始動時間を最小にできるので、クライアントは必ずしもAHSクライアントではない。例えば、クライアントは、再生を開始すべき第1の開始点と、後続の第1の終了点、第2の終了点、第3の終了点などのリストとを与えられ得る。クライアントは、後続の終了点を使用して、第1の要求においてコンテンツのどの部分を要求するかを決めることができ、この部分は、第1の開始点のバイトオフセットから第1の終了点のバイトオフセットまでであり得る。クライアントは次いで、第1のダウンロード要求が満たされている時、再生が開始した後のストールまたは再バッファを避ける技法を好ましくは使用して、ビデオの再生をいつ開始すべきかについて決めることができる。クライアントはまた、後続の要求の開始バイトオフセットおよび終了バイトオフセットとして、後続の終了点のバイトオフセットを使用して、コンテンツの後続の部分に対するダウンロード要求を発することができるので、好ましくは、これら後続の要求は、ストールまたは再バッファを回避するような方法で発せられる。メディアバッファが満ちると、クライアントは、メディアが満ちていない場合よりもコンテンツの大きな部分にわたるコンテンツの部分に対する要求を発する可能性があり、ここで、より大きいとは、提示時間がより長いこと、バイトがより多いこと、またはこれら両方を意味する。
別の代替形態として、AHSクライアントは、上で説明され次のように拡張される方法を使用できる。コンテンツのただ1つの表示ではなく、複数の表示がある。AHSクライアントは、第1の表示のコンテンツの再生を開始すべき第1の開始点と、この第1の表示に対する第1の後続の終了点とを取得し、またはそれらを与えられてよく、また、第1の開始点の後にある代替的な表示に対する開始点も与えられてよい。この場合、AHSクライアントは、前の段落において説明されたクライアント方法と同様に、しかし部分を決定するために代替的な表示における可能な開始点も場合によって使用して、第1の表示のどの部分をダウンロードすべきかを決めることができる。例えば、これは普通であることが多いが、終了点の頻度は開始点の頻度よりも高くてよく、例えば、表示の連続的な開始点の各ペアの間に設けられる、複数の、例えば5個以上の終了点が存在し得る。この場合、AHSクライアントは、前のように、例えば、第1の表示の開始点から第1の後続の終了点までの、比較的短いダウンロード部分で開始すると決めることができ、メディアバッファは、例えば、ある終了点から、その後の2つ以上の終了点である終了点までの、より大きな部分のダウンロードを開始するために拡大する。しかしながら、AHSクライアントは、第1の表示のどの部分をダウンロードすべきかについて決定を行う際に、他の代替的な表示に対する開始点を考慮して、例えば、レート切替が必要である場合に、AHSクライアントが、第1の表示からダウンロードされ場合によって第2の表示に切り替えられる重複するコンテンツの量を最小にするために、第1の表示から適切な部分をダウンロードすることを、確実にできる。例えば、第1の表示から部分をダウンロードする時、AHSクライアントは、切り替えが選ばれ得る第2の表示の可能な第2の開始点の提示時間にある、またはそれをわずかに過ぎた終了点に関連付けられるバイトオフセットで終了する第1の表示から、現在のダウンロード部分を選ぶことができ、すなわち、現在のダウンロード部分の後に選ばれる次のダウンロード部分は、第2の開始点に関連付けられるバイトオフセットで開始する、第2の表示からのものであり得る。
別の代替形態として、Luby A5において開示されるように、クライアントは、複数の同時のHTTP接続を使用して表示をダウンロードでき、加えてFECを使用できる。この代替形態では、Luby A5において開示されるように、高速な始動時間を確実にしつつ、同時にダウンロード要求の数を最小にするような方法で、複数の接続がコンテンツをダウンロードするようにスケジューリングされることが重要である。従って、最初に始動する時、クライアントは、複数の接続にわたって、第1の開始点から第1の後続の終了点まで、コンテンツの部分のダウンロードを区分でき、例えば、4つの接続のうちの第1の接続は、この部分の最初の1/4のダウンロードを要求でき、第2の接続は、次の1/4のダウンロードを要求できる、などである。このようにして、接続は、再生のために最初に必要とされるコンテンツの部分の断片を全てダウンロードしている。さらに、Luby A5において開示されるように、コンテンツに対する追加のFECデータは、別個のファイルにおいて利用可能にされてよく、このFECデータに対するダウンロード要求が、再生のために必要であるコンテンツの配信をさらに高速化するために行われ得る。前の代替形態のように、メディアバッファが満ちるに従い、ダウンロード要求部分の断片は大きくなることがあり、AHSクライアントの場合、第1の表示に対して選ばれたダウンロード部分(複数の接続を通じて要求されるべき複数の断片へと続いて区分される)の開始および終了が、切り替えの行われ得る可能な代替的な表示に対する開始点に基づいて行われ得る。
3.切替情報を生成するための処理の概要
セグメントマップは、適応ストリーミング方法の表示のより高速な切り替えを提供すると同時に、切り替えの間にネットワークを通じてより少量のデータをダウンロードし、ビデオプレーヤによってある表示から別の表示に切り替える時のより円滑なビデオ再生を可能にするために、クライアントによって有利に使用され得る。やはり本明細書で説明されるように、セグメントマップは、例えば始動時間の改善と、再バッファ/ストール事象に対する回復力の改善とを可能にすることのような、他の使用法を有する。
例として、セグメントマップは、開始点リストと、終了点リストと、任意選択で、表示のセグメントに関連付けられる他のメタデータとを備え得る。開始点リストは、開始点のリストを備え、開始点のリストは、そのような各開始点、提示開始時間、および開始バイトオフセットに関連付けられる。終了点リストは、終了点のリストを備え、終了点のリストは、そのような各終了点、提示終了時間、および終了バイトオフセットに関連付けられる。
セグメントマップを生成することは、2つの方法の部分へと機能的に区分され得る。第1の方法の部分に関連付けられるのは、本明細書では開始点生成器および終了点生成器と呼ばれる、2つのタイプの方法であり、開始点生成器および終了点生成器は、特定のフォーマットで符号化されるメディアのファイルまたはストリームを入力として取り込み、そのメディアに対する開始点および終了点の詳細なリストをそれぞれ生成する。本明細書ではセグメントマップ生成器と呼ばれる第2の方法の部分は、セグメントマップを生成するための開始点および終了点の詳細なリストを、入力として取り込む。
セグメントマップ生成器の実施形態は、セグメントマップを生成するために、開始点生成器および終了点生成器の出力を使用できる。セグメントマップ生成器は、メディアフォーマットに依存しないものであってよく、セグメントマップにおいて、最適化された開始点および終了点のリストを提供でき、ここで、最適化されているとは、開始点および終了点が小型な方法で選択され表されることを意味するので、セグメントマップは、クライアントが表示を開始し終了するのに良好な場所の豊富なセットを提供する。セグメントマップの生成は、メディアコンテンツの各表示に対して独立に実行されてよく、または協調して実行されてよい。
多くの変形が可能である。例えば、特にライブストリーミングコンテンツでは、開始点生成器と終了点生成器とセグメントマップ生成器とを緊密に統合する方法が好ましく、また、オンデマンドストリーミングコンテンツにおいても好ましいことがある。
Pakzadにおいて開示される方法は、AHSクライアントによって効率的かつ効果的に使用され得る開始点と終了点のセットから、簡潔なセグメントマップを生成するために使用されてよく、すなわち、Pakzadは、表示のセグメントを好ましいフラグメントへと区分するための方法を含む、セグメントマップ生成器のいくつかの実施形態を開示する。方法を、本明細書で説明される方法および処理によって拡張でき、具体的には、各フラグメントが、それぞれ主開始点における開始または主終了点における終了を可能にするように開始または終了するのであれば、好ましい。
例として、図1は、クローズドGOPフレーム依存構造を示し、この場合、第1のフラグメントはフレーム1と、5と、2と、3と、4とを備えてよく、第2のフラグメントはフレーム6と、7と、8とを備えてよく、第3のフラグメントはフレーム9と、13と、10と、11と、12とを備えてよく、第4のフラグメントはフレーム14と、15と、16とを備えてよい、などである。このフラグメント構造は、全ての主開始点がフラグメントの始まりにあるので、かつ、クライアントが表示を開始しまたは切り替える時に部分的なGOPのダウンロードを可能にし、従って、GOP全体がダウンロードされるより前にコンテンツに相当する部分的なGOPの再生を可能にするので、好ましいことがある。GOPの終わりにある特定の主終了点も好ましく、それは、一般にBフレームがIフレームまたはPフレームよりも小さく、従って、大きなフレームと同じ量の再生時間を可能にする小さなフレームをダウンロードすることが、一般に有利であるからである。GOP構造が異なる表示の間で整列される場合、この例では、フラグメント構造が、再生されないフレームのダウンロードを何ら伴わない表示の切り替えを可能にする。
別の例として、図2は、オープンGOPフレーム依存構造を示し、この場合、第1のフラグメントはフレーム1を備えてよく、第2のフラグメントはフレーム5と、2と、3と、4とを備えてよく、第3のフラグメントはフレーム9と、6と、7と、8とを備えてよく、第4のフラグメントはフレーム13と、10と、11と、12とを備えてよく、第5のフラグメントは、フレーム17と、14と、15と、16とを備えてよい、などである。この場合、第1のフラグメントは、それより後のパターンとは異なるフレームのパターンを伴って形成される。このフラグメント構造は、前の段落の例について説明されたのと同じ利点の多くを有する。GOP構造が異なる表示の間で整列される場合、このフラグメント構造が、再生されない4個の重複するフレーム、すなわち、1個のIフレームおよび3個のBフレームの最小限のダウンロードを伴う表示の切り替えを可能にする。
MPEG DASHシグナリングに基づくマッピングの変化
1.開始点および終了点のMPEG DASH規格シグナリング
MPEG DASH規格は、以下の表1に示されるような、セグメント内のフラグメントを表すための大まかなセグメントマップ構造を有する。
Figure 2014529970
上のセグメントマップ構造の解釈は、次の通りである。ESPTの値は、セグメント内の最早の提示時間を伴うフレームの提示時間である。
Timescaleの値は、表示のこのセグメントに対する、時間をティック単位で測定するために使用される1秒当たりのティックの数である。例えば、Timescale=30000である場合、表示のこのセグメントに対して、1秒当たり30000個のティックがあるので、90000ティックとして表される時間は、90000/30000秒、すなわち3秒という長さを示す。通常、時間の全ての単位、例えば、ESPT、Delta、およびRAP−deltaが、セグメント内のティックで表される。フレームの通常の長さは1001ティックであることがあり、これは、1秒当たり約29.97個のフレームがあることを意味する。
Nの値は、セグメント内のフラグメントの数である。
SB(i)の値は、セグメントのフラグメントiのバイト単位のサイズである。従って、セグメント内のフラグメントiの始まりに対するバイトオフセットは、i未満の全てのjにわたるSB(j)の和である。
Delta(i)の値は、フラグメントi+1内の任意のフレームの最早の提示時間と、フラグメントi内の任意のフレームの最早の提示時間との差である。従って、フラグメントiの後の次のフラグメント内のフレームの最早の提示時間は、ESPTに、j≦iである全てのjにわたるDelta(j)の和を足したものである。
RAP−present−flag(i)の値は、フラグメントi内に表示アクセスポイント(RAP)があるかどうかを示す。
フラグメントi内でシグナリングされるRAPがある場合、RAP−delta(i)の値は、フラグメントi内のRAP提示時間と、フラグメントi内のフレームの最早の提示時間との差である。従って、フラグメントi内にRAPがある場合、フラグメントi内のRAP提示時間は、ESPTと、RAP−delta(i)と、j<iである全てのjにわたるDelta(j)の和とを足したものである。
MPEG DASHセグメント構造の背後にある基本的な考えは、HTTP1.1バイト範囲要求を使用してセグメント内のフラグメントをダウンロードでき、フラグメントは通常、ダウンロードのために要求されるエンティティのうちで最小であることである。表示のシームレスな切り替えをサポートするような方法でフラグメント構造を整列することは理にかなっており、特に、フラグメントの境界を開始点および終了点と揃え、セグメント内で開始点と終了点とをシグナリングし、効率的かつシームレスな切り替えをサポートすることは、有益である。
MPEG DASHセグメントマップフォーマットは、セグメントの開始点のシグナリングをサポートするために、次のように使用され得る。MPEG DASH規格は、次のように関連付けられる(本明細書で使用される用語に変換される)、バイトオフセット、すなわちIRAPと、提示時間、すなわちTRAPとを備えるものとして、RAPを定義する。(1)表示のダウンロードがバイトオフセットIRAPから開始され終わりに進むように続く場合、TRAPは、表示におけるコンテンツのビデオフレームが、提示時間TRAPで開始する提示順序でシームレスに再生され得るような、最早の提示時間であり、(2)表示のダウンロードがバイトオフセットIRAPから開始され終わりに進むように続く場合、IRAPは、表示におけるコンテンツのビデオフレームが、提示時間TRAPで開始する提示順序でシームレスに再生され得るような、最大のバイトオフセットである。
従って、MPEG DASH規格で定義されるRAPは、本開示で定義される主開始点と等価であり、すなわち、(TRAP,IRAP)=(TentryB(IRAP),BentryT(TRAP))である。そのRAPに対するバイトオフセットがフラグメント内にある場合、フラグメントはRAPを含んでいると言われる。
MPEG DASH規格は、次のようにRAPをシグナリングできる。フラグメントiが少なくとも1つのRAPを含み、BOを、フラグメントiが含む全てのRAPのバイトオフセットのうちで最小のRAPのバイトオフセットとし、PT=TentryB(O)を、BOに対応するRAPの提示時間とする。RAP−present−flag(i)の値は、RAPの存在を示すために設定されてよく、RAP−delta(i)の値は、PTから、ESPTと、j<iである全てのjにわたるDelta(j)の和とを引いたものに設定され得る。RAPフレームを含まない各フラグメントiに対して、RAP−present−flag(i)の値は、RAPがないことを示すために設定され得る。従って、MPEG DASH規格は、フラグメント内で主開始点をシグナリングすることをサポートする。
BO(i)を、セグメント内でのフラグメントiの最初のバイトに対するバイトオフセットとする。フラグメントiがRAPを含む場合、TentryB(BO(i))は、フラグメントi内で最早の提示時間を有するRAPのRAP提示時間であることに留意されたい。
いくつかの場合には、MPEG DASHセグメントマップフォーマットは、セグメントの終了点のシグナリングをサポートするために、次のように使用され得る。全てのフラグメントiに対して、フラグメントi+1の最初のバイトに対するバイトオフセットBO(i+1)は、フラグメントiの終わりで終了することに対応するバイトオフセットである。以下に説明される環境(circumstances)では、フラグメントiの終わりで終了することに関連付けられる提示終了時間TexitB(BO(i+1))が、MPEG DASHセグメントマップフォーマットに基づいて、次のように正確に決定され得る。EPT(i)の値を、ESPTに、j≦iである全てのjにわたるDelta(j)の和を足したものに設定する。前に説明されたように、EPT(i)は、フラグメントi+1内の任意のフレームの最早の提示時間である。EPT(i)は、次の2つの条件が満たされれば、TexitB(BO(i+1))に等しいことが保証される。
2.終了点の正しいシグナリングのための2つの条件
終了点の正しいシグナリングのための2つの条件は、(1)ファイルフォーマット順序が復号順序であることと、(2)フラグメント内の任意のフレームの最早の提示時間の数列が、連続的なフラグメントにわたって厳密に増加していくこと、すなわち、EPT(1)<EPT(2)<EPT(3)などとなることである。
第1の条件は、必ずではないが、ファイルフォーマットにおいて一般に真であり得る。さらに、ファイルフォーマットが復号順序ではない場合、通常は、上で説明されたシグナリングは、フラグメントの提示終了時間を正確にシグナリングしない。図4に示されるフレーム依存構造に対応するが、ファイルフォーマット順序が復号順序ではなく提示時間順序である、図14は、第1の条件が真ではない例である。この例では、第1のフラグメントがフレーム1と、2と、3と、4とを含み、第2のフラグメントがフレーム5と、6と、7と、8とを含む場合、EPT(1)の値は、フレーム5の提示時間に対するものであり、これは、第1のフラグメントの提示終了時間として使用されると、最初の4個のフレーム1、2、3、および4が第1のフラグメントを受信することで再生され得ることを示す。しかしながら、フレーム1のみが、第1のフラグメントを受信することで再生され得るので、EPT(1)の値は、第1のフラグメントに対する提示終了時間を正確にシグナリングしない。
第2の条件は真であることが多いが、セグメントのフラグメント構造に依存し、第1の条件が真であっても第2の条件が真ではない例がある。例えば、図9を参照すると、第1のフラグメントが最初の13244バイトを備えフレーム1を搬送し、第2のフラグメントが次の5150バイトを備えフレーム5を搬送し、第3のフラグメントが次の3637バイトを備えフレーム2、3、4を搬送すると仮定する。この例では、最初の3個のフラグメントに対して上で計算されたような提示終了時間EPT(1)、EPT(2)、およびEPT(3)は、それぞれ、フレーム5、2、6の提示時間である。具体的には、第1のフラグメントに関連付けられる提示終了時間EPT(1)は、提示時間順序における最初の4個のフレームを示し、すなわち、フレーム1、2、3、および4を、第1のフラグメントをダウンロードすることで再生できることを示すが、これは明らかに当てはまらない。
従って、全体的に、MPEG DASH規格は、フラグメント内の開始点をシグナリングすることをサポートするが、終了点をシグナリングすることのサポートは、それほど一般的ではない。
3.第1のセグメントマップ方法:改善された終了点シグナリング
前に述べられたように、終了点がMPEG DASH規格によって常に正しくシグナリングされ得るとは限らない。具体的には、終了点が正しくシグナリングされるために、前に説明された終了点の正しいシグナリングのための2つの条件が、通常は必要とされる。第2の条件を除去できる1つの方法は、終了点のシグナリングの改善のためにMPEG DASHを拡張するための、このセクションで説明される方法を使用することである。
この手法では、ESPTは、表示の残りにある、以前のセグメントよりも後の任意のフレームの最早の提示時間として再定義される。また、Delta(i)の値は、表示の残りにある、フラグメントiよりも後の任意のフレームの最早の提示時間と、表示の残りにある、フラグメントi−1よりも後の任意のフレームの最早の提示時間との間の差として再定義される。
そして、RAP−delta(i)の値を、フラグメントi内のシグナリングされたRAPのRAP提示時間と、表示の残りにある、フラグメントi−1よりも後の任意のフレームの最早の提示時間との間の差として再定義する。
第1の条件が満たされる、すなわちファイルフォーマット順序が復号順序である場合、上記のパラメータの再定義によって、これら再定義された値に基づいて計算されたようなEPT(i)は、第2の条件が満たされない場合でも、フラグメントiに対する正しい提示終了時間であることが保証される。例として、図9を参照すると、上で説明された例のように、第1のフラグメントが最初の13244バイトを備えフレーム1を搬送し、第2のフラグメントが次の5150バイトを備えフレーム5を搬送し、第3のフラグメントが次の3637バイトを備えフレーム2、3、および4とを搬送すると仮定する。この例では、ESPTの値は前と同じであり、すなわち、フレーム1の提示時間である。しかしながら、最初の3個のフラグメントに関連付けられる上記の再定義に基づいて計算されたような提示終了時間EPT(1)、EPT(2)、およびEPT(3)は、それぞれ、フレーム2、2、6の提示時間である。具体的には、第1のフラグメントに関連付けられる提示終了時間EPT(1)は、提示時間順序における最初のフレーム、すなわちフレーム1が、第1のフラグメントをダウンロードすることで再生され得ることを示す。さらに、第2のフラグメントに関連付けられる提示終了時間EPT(2)は、フレーム1のみが最初の2個のフラグメントをダウンロードすることで再生され得ることを示し、第3のフラグメントに関連付けられる提示終了時間EPT(3)は、最初の5個のフレーム1、2、3、4、および5が最初の3個のフラグメントをダウンロードすることで再生され得ることを示す。
第2の条件に対応できる別の方法は、フラグメント内の任意のフレームの最早の提示時間の数列が連続的なフラグメントにわたって厳密に増加するような方法で、フラグメント構造が形成される場合である。例えば、各フラグメントが主終了点を含む場合、第2の条件が満たされる。
フラグメント構造を決定することが可能である場合、主開始点を含む各フラグメントは、主開始点がフラグメントの始まりの近くにあるようなものであれば好ましい。また、主終了点を含む各フラグメントは、主終了点がフラグメントの終わりの近くにあるようなものであれば好ましい。
両方の条件が除去され得る1つの方法は、現在のMPEG DASHセグメントマップで搬送されるパラメータの定義を次のように修正することであり、これは、MPEG DASHセグメントマップシグナリングの好ましい方法である。
4.第2のセグメントマップ方法:MPEG DASHセグメントマップ方法の修正
BOを、表示のセグメントの始まりに対するバイトオフセットとし、BO(i)を、フラグメントiの始まりに対するバイトオフセットとする。
ESPTの値を、TexitB(BO)と再定義する。
Delta(i)の値を、TexitB(BO(i+1))−TexitB(BO(i))と再定義する。
RAP−delta(i)の値を、TentryB(BO(i))−TexitB(BO(i))と再定義する。
MPEG DASHセグメントマップ方法の第2の修正は、上で説明された終了点の正しいシグナリングのための2つの条件のうちの第1の条件が満たされる場合、上で説明された第1の修正と実質的に等価であることに留意されたい。すなわち、第1の条件が満たされる場合、TexitB(BO)は、表示の残りにある以前のセグメントよりも後の任意のフレームの最早の提示時間であり、TexitB(BO(i+1))−TexitB(BO(i))は、表示の残りにあるフラグメントiよりも後の任意のフレームの最早の提示時間と、表示の残りにあるフラグメントi−1よりも後の任意のフレームの最早の提示時間との差であり、TentryB(BO(i))−TexitB(BO(i))は、フラグメントi内のシグナリングされたRAPのRAP提示時間と、表示の残りにあるフラグメントi−1よりも後の任意のフレームの最早の提示時間との差である。しかしながら、第2の修正は、あらゆる条件と無関係に終了時間を計算するために正確に使用されてよく、MPEG DASH規格内のRAPの現在の定義と調和するためのさらなる事項である。
TexitB(BO(i+1))は少なくともTexitB(BO(i))であるので、Delta(i)は、各フラグメントiに対して負ではないことが保証される。さらに、主終了点の提示終了時間の数列は、終了バイトオフセットが増加する順で厳密に増加しているので、Delta(i)は、各フラグメントが少なくとも1つの主終了点を含む場合、各フラグメントiに対して0より大きいことが保証され、Delta(i)=0は、フラグメントiが主終了点を何ら含まないことを示す。さらに、フラグメントiが少なくとも1つの主終了点を含む場合、TexitB(BO(i+1))は、フラグメントi内の最後の主終了点の提示終了時間である。また、TentryB(BO(i))は少なくともTexitB(BO(i))なので、RAP−delta(i)は0以上であることが保証される。
開始点および終了点は、AHSシステムにおいて表示の切り替えを行う際には等しく重要なので、MPEG DASH規格をさらに拡張することを考えることができる。
RXPと省略される「表示終了点(representation exit point)」の定義をMPEG DASH規格に導入でき、RAPが主開始点として定義される方法と同様に、RXPが主終了点として定義される。
新たなパラメータRXP−present−flag(i)が、各フラグメントiに対して導入されてよく、RXP−present−flag(i)の値は、フラグメントi内に表示終了点(RXP)があるかどうかを示す。RXP−present−flagの値は、MPEG DASHセグメントマップにおいて明示的にシグナリングされる必要はないが、代わりに、他のパラメータから次のように計算され得る。RXP−present−flag(i)の値は、Delta(i)>0である場合、フラグメントi内にRXPがあることを示し、Delta(i)=0である場合、フラグメントi内にRXPがないことを示す。
フラグメントi内にRXPがある場合、フラグメントiに対するRXP提示時間は、ESPTに、Delta(i)と、j<iである全てのjにわたるDelta(j)の和とを足したものである。
MPEG DASH規格におけるように、RAP−present−flag(i)の値は、フラグメントi内に表示アクセスポイント(RAP)があるかどうかを示す。
フラグメントi内にRAPがある場合、フラグメントiに対するRAP提示時間は、ESPTに、RAP−delta(i)と、j<iである全てのjにわたるDelta(j)の和とを足したものである。
バイトオフセットについての情報も含むフラグメント内の複数の主開始点および/または主終了点を示すことを含む、MPEG DASH規格の他の拡張も可能である。
セグメントマップに含まれ得る他の情報は、例えばAESによって提供されるCBCスタイルのブロック暗号化が使用される場合に復号を助けるために使用され得る情報であり、データの各ブロックは例えば16バイトであり、ブロックが連鎖的に暗号化され、すなわち、次のブロックを暗号化するために、前のブロックの暗号化されたものはまず、次のブロックとの排他的論理和をとられて新たなブロックを形成し、そして、新たなブロックの暗号化されたものは、次のブロックの暗号化された値となる。従って、前のブロックの暗号化された値は、次のブロックを復号するために必要とされ、すなわち、次のブロックの値は、次のブロックの暗号化されたものを復号し、それと、前のブロックの暗号化された値との排他的論理和をとることによって、形成される。従って、フラグメントの最初の暗号化されたブロックを復号するのに必要な、または、セグメントマップ内のRAPまたはRXPの最初の暗号化されたブロックを復号するのに必要な、以前の暗号化されたブロックに対するバイトオフセットを提供することは、有益である可能性がある。あるいは、セグメントマップ自体において以前の暗号化されたブロックを提供することが、有益である可能性がある。
セグメントマップは、関連するセグメントから別個のファイルとして提供されてよく、セグメントマップのURLは、セグメントファイルのURLから導出され、例えば、セグメントマップのURLは、セグメントのURLの末尾に「.segment_map」が追加されたものである。この変形形態には、セグメントファイルが変更されないので、セグメントマップファイルの存在を認識しないクライアントがその存在の影響を受けないという利点があり、一方セグメントインデックスファイルを認識しそれを利用できるクライアントは、セグメントインデックスファイルをダウンロードし使用して、表示切替の体験を改善できる。
別の変形形態として、セグメントマップは、セグメントを拡張するためにセグメントの先頭に追加されてよく、次いでクライアントは、拡張セグメントの短いプレフィックスをダウンロードしてファイルのセグメントマップを取得することによって、セグメントマップをダウンロードできる。この変形形態には、第1の変形形態よりも、管理すべきファイルおよび関連するURLが少ないという利点があるが、先頭に追加されたセグメントマップを解析または使用するように構成されていない既存のクライアントがある場合には、問題となり得る。別の変形形態として、セグメントマップは、セグメントを拡張するためにセグメントの末尾に追加され得る。他の変形形態として、いくつかのセグメントおよび/または表示のセグメントマップは、1つのファイルに統合され得る。別の変形形態では、1つのセグメントのセグメントマップが、複数のファイルに区分されてよく、これらセグメントマップのURLは、例えば、テンプレートに基づくURLの生成を使用して、セグメントのURLから自動的に導出され得る。この変形形態は、セグメントが多くのフラグメント/ブロックを備える場合、例えば、セグメントが2時間の映画であり、各フラグメントの長さが500ミリ秒前後である場合には、特に有用であることがある。
上記の実施形態の多くの変形形態がある。例えば、フラグメント/ブロック当たり多くとも1つの開始点と終了点とをリストするのではなく、フラグメント当たり複数の開始点および/または終了点がリストされてよい。コンテンツが暗号化される場合、セグメントマップは、後続の部分を復号するための暗号化されたコンテンツのダウンロードをどこで開始するかを示すための、暗号化バイトオフセットを含み得る。例えば、コンテンツがAESによって提供されるCBC暗号化を使用して暗号化され、暗号化されたデータの一部分を復号するために、データのストリームにおける暗号化されたデータの以前の部分が必要である場合、セグメントマップは、暗号化されたデータのこれら以前の部分に対するバイトオフセットを提供できる。
セグメントマップはまた、ビデオのシームレスな切り替えと再生とを支援するための、クライアントおよび/またはメディアプレーヤに関連する他の情報を含み得る。例えば、表示がオーディオデータを備えるか、またはビデオデータとオーディオデータの組合せを備えるかを示す情報を、セグメントマップに追加することが可能である。また、FEC修復セグメントが利用可能かどうかを示すものと、利用可能である場合、FEC修復セグメントを使用するためにクライアントによって使用され得るFECセグメントマップのシグナリングとを追加することが可能である。
5.第3のセグメントマップ方法:ALSストリーミングのためのセグメントマップの生成およびフォーマット
一部のAHSストリーミングシステムでは、セグメントマップを、セグメント自体とは別個のファイルとして生成し提供することが有用である。後方互換性が、一式の論拠を与える。セグメントマップは、何らかの既存のAHSシステム、または今後展開されるAHSシステムに対して、規定も考慮もされていない。後方互換性を保ったまま、セグメントマップによってそのようなシステムを拡張することは、多くの価値をもたらすことができ、すなわち、セグメントマップの利用可能性を利用できる拡張AHSクライアントに対する、改善された切り替えおよび始動のエンドユーザ体験とネットワーク効率とを提供でき、非拡張AHSクライアントの性能に対して何ら負の影響を与え得ない。他の論拠は、本開示の他の部分で説明される。このセクションで開示されるセグメントマップは、セグメント自体とは別個のファイルとして説明されるが、これらセグメントマップはまた、セグメントファイルの一部であってよく、例えば、セグメントマップは、セグメントの先頭に追加され、セグメントの末尾に追加され、または、セグメント全体に散りばめられてよい。
特定のセグメントについての情報を提供するためのセグメントマップの単純なフォーマットは、セグメントの選択された主開始点および選択された主終了点のリストを含むことであり、選択された主開始点は、セグメント内で開始する、主開始点の全てまたは主開始点の選択されたサブセットであってよく、選択された主終了点についても同様である。従って、セグメントマップにおいて特定のセグメントについての情報を生成し提供するための1つの可能なフォーマットは、次の通りである。
BOを、表示のセグメントの始まりに対するバイトオフセットとし、APT(0)=TentryB(BO)、ABO(0)=BO、XPT(0)=TexitB(BO)、かつXBO(0)=BOとする。ANを、選択された主開始点の数とし、XNを、選択された主終了点の数とする。全てのi=1,…,ANに対して、(APT(i),ABO(i))を、バイトオフセットが増加する順序でi番目の選択された主開始点とし、同様に、i=1,…,XNに対して、(XPT(i),XBO(i))を、バイトオフセットが増加する順序で選択された主終了点の始まりに対するバイトオフセットとする。そして、このセグメントに付随するセグメントマップの部分のフォーマットは、以下の表2に示されるようなデータ構造であり得る。
Figure 2014529970
表2のセグメントマップ構造の解釈は、次の通りである。Timescaleの値は、MPEG DASH規格について説明された通りである。セグメント内の選択された主開始点iのバイトオフセットは、全てのj=0,…,iにわたるABO(j)の和であり、セグメント内の選択された主終了点iのバイトオフセットは、全てのj=0,…,iにわたるXBO(j)の和である。同様に、セグメント内の選択された主開始点iの提示時間は、全てのj=0,…,iにわたるAPT(j)の和であり、セグメント内の選択された主終了点iの提示時間は、全てのj=0,…,iにわたるXPT(j)の和である。
セグメントマップにおいてセグメント内の選択された主開始点と選択された主終了点とを示すための代替的なフォーマットは、次の通りである。
6.第4のセグメントマップ方法
Lを、組み合わされた、選択された主開始点と選択された主終了点とのリストとし、このとき、点は(バイトオフセット,提示時間)のペアとしてリストされ、点はバイトオフセットが増加する順序でリストされ、このリスト内の開始点および終了点は、それらが同じ(バイトオフセット,提示時間)の値を有する場合、重複していると考えられる。Nを、リストL内のユニークな点の数とする。全てのi=1,…,Nに対して、(PT(i),BO(i))を、リストL内のi番目の点とする。BOを、表示のセグメントの始まりに対するバイトオフセットとし、PT(0)=TexitB(BO)かつBO(0)=BOとする。そして、このセグメントに付随するセグメントマップの部分のフォーマットは、表3のリストに示されるようなものであり得る。
Figure 2014529970
表3のセグメントマップ構造の解釈は、次の通りである。表示タイプは、どのタイプのデータが参照されるセグメントに含まれるかを示し、0は、データがオーディオのみであることを示し、1は、データがビデオのみであることを示し、2は、データがオーディオとビデオの両方の組合せであることを示す。従って、クライアントは、セグメントマップをダウンロードすることで表示タイプを判定できる。Timescaleの値は、MPEG DASH規格について説明された通りである。セグメント内の点iのバイトオフセットは、全てのj=0,…,iにわたるBO(j)の和であり、セグメント内の点iの提示時間は、全てのj=0,…,iにわたるPT(j)の和である。一部のファイルフォーマット順序およびフレーム依存構造では、PT(i)−PT(i−1)が0よりも小さくなり得ることが可能であり、一方他のファイルフォーマット順序およびフレーム依存構造では、PT(i)−PT(i−1)は常に少なくとも0であることに留意されたい。RP(i)の値は、点iが開始点か、終了点か、または開始点と終了点の両方かを示す。
上記に対する多くの拡張がある。例えば、セグメントマップは、部分的なセグメントまたは複数のセグメントについての情報を含み得る。セグメントマップは、URLと、どのセグメントについての情報をセグメントマップが含むかを示すためのバイト範囲とを含み得る。
上で説明された第4のセグメントマップ方法も、MPEG DASHフラグメント構造を決定するために使用され得ることに留意されたい。例えば、各i=1,…,Nに対して、バイトオフセットBO(i−1)で開始しバイトオフセットBO(i)−1で終了するものとして定義されるフラグメントが存在し得る。この場合、各フラグメントの開始および終了は、選択された主開始点、選択された主終了点、または、選択された主開始点と選択された主終了点の両方のいずれかに対応する。
MPEG DASHによって使用されるセグメントマップシグナリング方法と協調するために、ファイルフォーマット順序が復号順序である場合、代替的な実施形態が使用され得る。この代替的な実施形態では、各フラグメントが少なくとも1つの主終了点を含むように、すなわち、各i=1,…,Nに対して、BO(i−1)<BO≦BO(i)である少なくとも1つの主終了点(PT,BO)が存在するように、フラグメント構造が形成され、前に説明されたような「MPEG DASH規格の開始点および終了点のシグナリング」というセグメントマップシグナリング方法が使用され得る。前に説明されたように、この方法のDelta(i)の値は、フラグメントi+1内の任意のフレームの最早の提示時間と、フラグメントi内の任意のフレームの最早の提示時間との差である。従って、フラグメントiの後の次のフラグメント内のフレームの最早の提示時間は、ESPTに、j≦iである全てのjにわたるDelta(j)の和を足したものである。この場合、「終了点の正しいシグナリングのための2つの条件」は両方とも満たされるので、各フラグメントは終了点を含み、フラグメントiの後の次のフラグメント内のフレームの最早の提示時間は、フラグメントiの終わりに関連付けられる提示終了時間である。従って、各フラグメントの終わりは、セグメントマップ内のシグナリング情報に基づいて計算され得る、提示終了時間を有する終了点である。
多くの他の拡張および代替形態も可能である。例えば、前に説明されたMPEG DASHの代替形態および拡張の全ても、このセクションで説明された実施形態に適用される。例えば、選択された主開始点は、場合によって副開始点を含むように拡張されてよく、選択された主終了点は、場合によって副終了点を含むように拡張されてよい。
切替パッチを使用してデータをシグナリングし並べ替えるための方法
いくつかの場合には、より効率的なビデオ符号化を可能にするために、データ依存構造がより複雑であることがあり、AHSクライアントが、ある表示から出てSAPにおいて第2の表示に参加することは簡単ではないことがある。例えば、前に説明されたように、図1に示されるクローズドGOP構造はそのような移行を容易にするが、図2に示されるオープンGOP構造は、そのような移行をより難しくする。開始点および終了点が揃えられた場合の、クローズドGOP移行とオープンGOP移行の差の1つの例は、次の通りである。
終了点(PT,BO)における第1の表示から開始点(PT’,BO’)における第2の表示に移行するとき、クローズドGOPでは、提示時間PTとPT’が等しく、これら表示からダウンロードされたコンテンツには重複がなく、2つの表示からのコンテンツは、メディアプレーヤが再生するのに有効なコンテンツを表すように連結でき、シームレスな移行を可能にすることがわかる。クローズドGOP移行の例として、2つの表示が、図1、図5、および図9に示されるものと同じデータ依存構造とファイルフォーマットとを共有すると仮定する。この場合、図9に示されるように、第1の表示からの移行は、終了点(8,27537)で行われてよく、これは、第1の表示がバイトオフセット27537までダウンロードされ、表示終了時間がフレーム8の再生のすぐ後であることを示す。
図5を参照すると、第2の表示への対応する移行は、開始点(9,27537)で行われてよく、これは、第2の表示がバイトオフセット27537においてダウンロードを開始し、表示開始時間がフレーム9の再生と共に開始することを示す。この例では、同じフレームの重複するダウンロードはなく、すなわち、第1の表示からダウンロードされた全てのフレームは、第2の表示からダウンロードされた全てのフレームとは異なる。この例では、第1の表示の終了点のバイトオフセットおよび第2の表示の開始点のバイトオフセットは等しく、それは、これら両方の表示が、同じ表示点および終了点に対してちょうど同じバイトオフセットを有するからであるが、一般的には、移行前後の2つの表示は、異なる品質およびレートで符号化されるので、同じ表示時間に対するバイトオフセットは一般的には等しくない。
終了点(PT,BO)における第1の表示から開始点(PT’,BO’)における第2の表示に移行するとき、オープンGOPでは、提示時間PTとPT’が等しいとは限らず、これら表示からダウンロードされたコンテンツには重複があることがあり、2つの表示からのコンテンツは、メディアプレーヤが再生するのに有効なコンテンツを表すように簡単に連結できない。これら場合には、AHSクライアントが、メディアプレーヤに対する重複コンテンツをメディアプレーヤに提供する時に、どのコンテンツが重複しているかをメディアプレーヤにシグナリングすることが有用であり、それは、シームレスな方式で重複コンテンツを再生するのに、このことがメディアプレーヤにとって有用であり得るからである。他の場合には、メディアプレーヤは、重複コンテンツがいつメディアプレーヤに提供されるかを理解し、可能な限りシームレスにコンテンツの再生を処理するための、論理と方法とを備える。
オープンGOP移行の例として、2つの表示が、図2、図6(a)、および図10(a)に示されるものと同じデータ依存構造とファイルフォーマットとを共有すると仮定する。この場合、図10(a)に示されるように、第1の表示からの移行は、終了点(9,31043)で行われてよく、これは、第1の表示がバイトオフセット31043までダウンロードされること、すなわち、クライアントが示されるファイルフォーマット順序におけるフレーム8まで、フレーム8を含めてダウンロードすることと、提示終了時間がフレーム9の再生のすぐ後であることとを示す。図6(a)を参照すると、第2の表示への対応する移行は、開始点(9,22033)で行われてよく、これは、第2の表示がバイトオフセット22033においてダウンロードを開始すること、すなわち、クライアントが示されるファイルフォーマット順序におけるフレーム9でダウンロードを開始することと、提示開始時間がフレーム9の再生と共に開始することとを示す。
このオープンGOPの例では、上のクローズドGOPの例とは対照的に、両方の表示が、全体として同じ開始点および終了点に対してちょうど同じバイトオフセットを有していても、両方の表示が、移行の開始点および終了点に対して異なるバイトオフセットを有することに留意されたい。このオープンGOPの例では、この移行においてダウンロードされる重複フレームのセットがあり、すなわち、フレーム9、6、7、および8が、この移行において、各表示に対して1回ずつダウンロードされる。好ましくは、エンドユーザに対する時間的にシームレスな移行の体験を提供するために、フレームのこれらセットのうちの1つのみが、メディアプレーヤによる再生などのためにメディア消費者によって使用される。
本明細書では、フレームのこの重複するセットは「重複パッチ(overlap patch)」と呼ばれる。上の例では、各重複パッチは、31043−22033=9010バイトである。いくつかの例では、バイトの数は、ある表示の重複パッチと別の表示の重複パッチとでは異なり得る。しかしながら、この例では、これらは同じである。クライアントは次いで、2×(31043−22033)=18020バイト、すなわち2つの表示の重複パッチをダウンロードし、これら重複パッチのうちの1つのみを使用して、フレーム6、7、8、および9とを再生する。従って、この例では、9010バイトのオーバーヘッドがある。
一般に、移行の前後の2つの表示は、通常は異なる品質およびレートで符号化されるので、同じ提示時間に対するバイトオフセットは一般に等しくなく、従って、重複パッチのためにダウンロードされたバイトの総数、すなわち2つの表示の各々における重複パッチのバイトサイズの合計は、必ずしも2倍ではない。重複パッチから再生されるフレームのサイズは、メディアプレーヤが、ある表示から、重複パッチ内のフレームのうちの他の表示へと再生を移行することを、どのように決めるかに依存し得る。
オープンGOPデータ依存性と他のより高度なデータ依存構造とを使用する時の、シームレスな移行の効率性と簡易性とを拡張するために、本明細書で説明されるいくつかの方法が使用され得る。第1は、例えばセグメントマップ内で、重複パッチ構造をシグナリングするための方法、すなわち、ある表示から別の表示に切り替えるために使用され得る、または、表示内における開始点でコンテンツの再生を開始するために使用され得る、または、表示の終了点でコンテンツの再生を停止するために使用され得る、可能な重複パッチに対応する開始点と終了点のペアをシグナリングするための方法である。
セグメントマップ内で重複パッチをシグナリングするための可能なフォーマットが、様々なフォーマットでクライアントに伝えられ得るデータ構造として、表4に示される。
Figure 2014529970
クライアントは次いで、セグメントマップからのこのデータ構造を解釈して、重複パッチがどこで発生しているかを判定する。この例示的なデータ構造では、Timescaleの値は、MPEG DASH規格に対して説明された通りであり得る。OPの値は、このセグメントマップにおいてシグナリングされる重複パッチの数である。タイプフィールドは、重複パッチがシグナリングされていることをシグナリングする。ペア(APT(i),ABO(i))は、i番目の重複パッチの開始点であり、ペア(XPT(i),XBO(i))は、i番目の重複パッチの終了点である。
上記のシグナリング方法には多数の変形形態が存在する。例えば、重複パッチのシグナリングは、セグメントマップ内で、他のSAP、開始点、および終了点のシグナリングと共に、シグナリングされ得る。別の例として、シグナリングの厳密な詳細は変化し得る。
別の変形形態として、OPの値は一定でありシグナリングされなくてもよい。例えば、セグメントのセグメントマップがセグメントの先頭に追加され、セグメント当たり1つのみの重複パッチがあるということがあってよく、セグメントは、開始点で開始し終了点で終了する。この場合、OPの値は1である。別の変形形態として、重複パッチのシグナリングは、セグメントマップ内の別のフラグによってシグナリングされてよく、フラグが0に設定されている場合、セグメントにおいてシグナリングされる重複パッチはなく、フラグが1に設定されている場合、セグメント内でシグナリングされるちょうど1つの重複パッチがある。
既存のMPEG DASHプロファイルの一部では、適応セットの異なる表示の間でSAP整列が存在する。MPEG DASHまたは他のAHS技法の標準的なプロファイルの変形形態では、適応セットの異なる表示の間での重複パッチの整列の、または一般的には、異なるビットレートおよび品質で同じコンテンツを表すグループの間での重複パッチの整列が、所与のプロファイルに対してシグナリングされるか常に真であるかのいずれかであり得る場合、プロファイルは許容され得る。異なる表示の間での重複パッチの整列とは、かなりの部分または全ての重複パッチに対して、特定の表示が開始点(APT,ABO)を有するシグナリングされる重複パッチと対応する終了点(XPT,XBO)とを有する場合、適応セットまたはグループ内の他の表示も、形式(APT,ABO’)の開始点と形式(XPT,XBO’)の終了点とを有するシグナリングされる重複パッチを有すること、すなわち、開始点である提示開始時間と終了点である提示終了時間とが一致することを意味する。バイトオフセットは一致する必要はなく、一致しないことが多いことに留意されたい。
シグナリングされる重複パッチを表示の間で揃えていることは、AHSクライアントにとって非常に有益であり得る。例えば、これによって、AHSクライアントは、第1の表示のセグメントマップ情報から、現在の第1の表示から別の第2の表示へ切り替えるための戦略、すなわち、第2の表示のダウンロードを開始する提示開始時間と、第1の表示の提示終了時間とを決定することが可能になる。このことは有益であることがあり、それは、AHSクライアントが、どの提示時間において切り替えを行うかを決定するために、第2の提示のセグメントマップ情報をダウンロードまたは入手するのを避けることができるからである。別の利点は、AHSクライアントが、第2の表示から情報をダウンロードする前でも、重複パッチの提示開始時間と提示終了時間とをメディアプレーヤにシグナリングでき、従って、重複コンテンツについてのヒントを前もってメディアプレーヤに提供できることである。
実施形態では、メディアコンテンツのソースは、重複パッチと共にセグメント内のデータを配置するように構成されてよく、クライアントは、存在するかどうかにかかわらず、重複パッチの存在を仮定してデータを処理するように構成されてよい。いくつかの実施形態では、そのようなソースは、重複パッチを認識または認知しないクライアントによって使用され得る。
同じ適応セットまたはグループにおける表示の間での重複パッチの整列のための1つの可能な方法は、異なる表示の間で整列されたセグメントを有することと、重複パッチであるセグメント、すなわち、重複パッチの開始点のバイトオフセットで開始し、重複パッチの終了点のバイトオフセットで終了するセグメントを表示内に有することであり、すなわち、(PT,BO)が重複パッチの開始点であり(PT’,BO’)が重複パッチの終了点である場合、セグメントは、表示内におけるバイトオフセットBOで開始し、表示内におけるバイトオフセットBO’で終了する。
重複パッチと一致するセグメントも、重複パッチを備えるセグメントとしてシグナリングされ得る。この場合、AHSクライアントが第1の表示から第2の表示への移行を望む場合、AHSクライアント方法は、例えば開始点(APT,ABO)と終了点(XPT,XBO)とを有する重複パッチであるセグメントを、第1の表示において見出し、XBO−ABOバイトのコンテンツ備えるそのセグメントをダウンロードし、第2の表示における対応する重複パッチであるセグメント、すなわち、開始点(APT,ABO’)および終了点(XPT,XBO’)に対応する第2の表示からのXBO’−ABO’バイトのコンテンツを有する第2の表示におけるセグメントをダウンロードし、提示時間間隔APTからXPTのうちで、第1の表示から第2の表示への移行を行うようにメディアプレーヤにシグナリングすることであり得る。
別の変形形態は、重複パッチが完全にセグメント内に完全に含まれるように制限し、セグメント内の重複パッチの位置をシグナリングすることである。この変形形態は、例えば、セグメント期間が重複パッチの期間よりも全般にはるかに長い場合、例えば、オンデマンドコンテンツでは、表示当たり1セグメントしか存在し得ない場合、または、ライブコンテンツでは、セグメント期間が数秒であり得る一方で重複パッチ期間が数十ミリ秒または数百ミリ秒であり得る場合に、好ましいことがある。この場合、AHSクライアントが第1の表示から第2の表示に移行する時、AHSクライアントは、第1の表示における重複パッチの終わりで終了する第1の表示におけるセグメントをダウンロードし、第2の表示における重複パッチの始まりで開始する第2の表示におけるセグメントをダウンロードでき、これによって、再生されるべきではないこれらセグメントの他の部分のダウンロードを避ける。
上で説明されたように、いくつかの冗長なコンテンツおよび/または使用されないコンテンツが、重複パッチに基づいて要求され送信され得る。従って、第1の表示から第2の表示に切り替える時、コンテンツの2つの異なるバージョンが重複パッチにおいてダウンロードされ、また、メディアプレーヤは、重複パッチ内のコンテンツの各部分の2つのバージョンのうちの1つのみを再生するので、冗長なコンテンツがダウンロードされる。従って、重複パッチサイズが最小になるようにデバイスを構成することには、良い理由がある。
クライアントが、重複パッチの開始点で開始する表示からのコンテンツを再生し始めている場合、または、重複パッチの終了点で終了する表示からのコンテンツの再生を終了しつつある場合にも、重複パッチサイズが小さいことに利益があり、それは、上記のいずれの場合でも、決して再生されないコンテンツがダウンロードされることがあるからである。
例えば、図2と、図6(a)と、図10(a)とを再び参照して、示されるファイルフォーマット順序におけるフレーム9と、6と、7と、8とを備える重複パッチを考える。この重複パッチにおいて表示を切り替える時、フレーム9、6、7、および8は2回、すなわち第1の表示に対して1回、第2の表示に対して1回ダウンロードされる。この重複パッチの開始点を使用して再生を開始するとき、すなわち、フレーム9において再生を開始するためにフレーム9の始まりにおいてダウンロードを開始するとき、フレーム6、7、および8は、ダウンロードされないフレーム5にも依存するので、ダウンロードされるが再生できない。
重複パッチのサイズと期間とを最小にするために、復号順序とは限らない他のファイルフォーマット順序を考えることが有用である。次の方法を考える。サーバが、復号順序ではなく提示順序としてファイルフォーマット順序を使用して、セグメントを形成する。セグメントに関連付けられるセグメントマップ内のシグナリングは、セグメント内のコンテンツを復号順序へとどのように並べ替えるかをシグナリングできる。AHSクライアントは、セグメントまたはセグメントの部分をダウンロードし、受信されたコンテンツを復号順序へと並べ替え、コンテンツを復号順序でメディアプレーヤに提供できる。このことは、AHSクライアントが、コンテンツの部分をメディアプレーヤに提供する前に、コンテンツの部分を場合によって並べ替えることを必要とするが、いくつかの場合には、メディアプレーヤは、コンテンツを復号順序で受信する必要はないことがある。また、AHSクライアントは、復号順序でコンテンツをメディアプレーヤに提供するために、コンテンツをメディアプレーヤに提供する前にわずかにより多くのコンテンツをバッファリングする必要があり得る。しかしながら、この方法には多くの利点がある。
この例では、ファイルフォーマット順序が提示順序であるという指示が、例えばMPDにおいてシグナリングされ得る。ファイルフォーマット順序が提示順序であることをシグナリングされた表示に対して、主開始点および主終了点および復号順序が、シグナリングされた各フレームに対して次のフォーマットを使用してシグナリングされ得る。
Figure 2014529970
上式において、SBOはファイルフォーマット順序におけるフレームの開始バイトオフセットであり、キーワード「start_BO」によって開始バイトオフセットであるものとしてシグナリングされる。同様に、EBOは、フレームの終了バイトオフセットであり、キーワード「end_BO」によってそのようなものとしてシグナリングされる。キーワード「decode_BO」によってシグナリングされるDBOは、フレームを復号順序にするためにこのフレームが挿入されるべきである、ファイルフォーマット順序におけるバイトオフセットである。任意選択のキーワード「entry」は、フレームの始まりが開始点である場合に含まれ、同様に任意選択のキーワード「exit」は、フレームの終わりが終了点である場合に含まれる。
例として、図2に示されるフレーム依存構造を考えるが、代わりに、ファイルフォーマット順序が復号順序ではなく提示順序であり、すなわち、ファイルフォーマット順序が図6(b)および図10(b)に示されるようであると仮定する。そして、この例の上で説明されたシグナリングは次のようであり得る。
Figure 2014529970
上式の第1のエントリは、フレーム1に対応し、フレーム1がバイトオフセット0で開始しバイトオフセット13244で終了することと、このフレームが復号順序においてdecode_BO=start_BO=0によって示されるような位置にあるべきであることと、フレーム1の始まりが開始点であることと、フレーム1の終わりが終了点であることとをシグナリングする。上式の第2のエントリは、フレーム5に対応し、フレーム5がバイトオフセット16583で開始しバイトオフセット22033で終了することと、フレーム5が復号順序においてバイトオフセット13244に、すなわちフレーム2のすぐ前に挿入されるべきであることと、フレーム5の終わりが終了点であることとをシグナリングする。上式の第3のエントリは、フレーム9に対応し、フレーム9がバイトオフセット25013で開始しバイトオフセット31043で終了することと、フレーム9が復号順序においてバイトオフセット22033に、すなわちフレーム6のすぐ前に挿入されるべきであることと、フレーム9の始まりが開始点であることと、フレーム9の終わりが終了点であることとをシグナリングする。次の2つのエントリは、フレーム13および17に対する同様の情報をシグナリングする。
上の例では、各重複パッチは1フレームのみであり、すなわち、フレーム1、9、および17が各々、重複パッチであることに留意されたい。例えば、第1の表示からの移行は、フレーム9の終わりにある終了点で行われ得るので、第1の表示はバイトオフセット31043までダウンロードされ、すなわち、クライアントは、提示順序ファイルフォーマットで、フレーム9の終わりまでダウンロードする。第2の表示への対応する移行は、フレーム9の始まりにおいて行われ得るので、第2の表示は、バイトオフセット25013においてダウンロードを開始し、すなわち、クライアントは、フレーム9の始まりにおいてダウンロードを開始する。重複パッチはフレーム9であり、フレーム9は、両方の表示に対してダウンロードされる唯一のフレームであり、すなわち、2×6030=12060バイトが、2つの表示に対するフレーム9を備える重複パッチからダウンロードされることに留意されたい。
この同じフレーム依存構造を有するがファイルフォーマットとして復号順序を伴う上記の前の例では、フレーム6、7、8、および9と、全体で18020バイトとを備える重複パッチが、2つの表示に対する重複パッチからダウンロードされることに留意されたい。従って、この例においてファイルフォーマット順序としての提示順序はより小さな重複パッチを有し、これは、ある表示から別の表示への移行を実施するためにAHSクライアントがダウンロードする必要のあるコンテンツが少なくなるので、AHSクライアントにとって有益である。従って、移行のために使用されるネットワーク容量をより少なくでき、また、移行を可能にするためにダウンロードされるデータの量がより少なくなることにより、AHSクライアントがストールまたは再バッファを強いられる確率が低くなる。
さらに、上記の方法は、フレームをメディアプレーヤに提供する前にフレームを復号順序へと並べ替えるのに十分な情報をAHSクライアントに提供し、AHSクライアントはまた、重複パッチの指示をメディアプレーヤに与えることができる。さらに、このファイルフォーマット順序では、例えばフレーム9で開始する表示からコンテンツの再生を開始することを望むAHSクライアントは、再生されないフレームを何らダウンロードせず、これは、フレーム6、7、および8もダウンロードされるが再生されない、同じフレーム依存構造を有するがファイルフォーマット順序として復号順序を伴う以前の例とは対照的である。
上記の多数の変形形態が存在する。例えば、キーワードは、開始点バイトオフセットおよび終了点バイトオフセットおよび復号バイトオフセットの記述に含まれず、代わりに、各フィールドの意味は、その順序または何らかの他のインジケータによって決定される。別の例として、フラグメントまたはセグメントへの表示の区分は、主開始点および主終了点の数列として定義されてよく、すなわち、新たなセグメントは各開始点で開始し、セグメントは各終了点で終了する。上記の例では、開始点と終了点の両方を有するという指示を伴うフレーム1を備えるフラグメントまたはセグメントと、終了点を有するという指示を伴うフレーム2と、3と、4と、5とを備えるフラグメントまたはセグメントと、開始点も終了点も含まないという指示を伴うフレーム6と、7と、8とを備えるフラグメントまたはセグメントと、開始点と終了点の両方を有するという指示を伴うフレーム9を備えるフラグメントまたはセグメントと、終了点を有するという指示を伴うフレーム10と、11と、12と、13とを備えるフラグメントまたはセグメントと、開始点も終了点も含まないという指示を伴うフレーム14と、15と、16とを備えるフラグメントまたはセグメントと、フレーム17を備えるフラグメントまたはセグメントとが存在し得る。この例では、終了点はセグメントの終わりにあり、開始点はセグメントの始まりにある。さらに、各終了フレームは、復号順序を取得するために、前の終了フレームのすぐ後に移動されるべきである。従って、各終了点フレームの開始バイトオフセットと共に上記の情報をシグナリングされたAHSクライアントは、フレームを復号順序へと自動的に並べ替え、フレームを復号順序でメディアプレーヤに提供できる。
上記の方法の多数の変形形態が存在する。例えば、コンテンツのある部分では、ファイルフォーマット順序は復号順序であってよく、コンテンツの他の部分では、ファイルフォーマットは提示順序であってよい。一例として、図2を再び参照すると、ファイルフォーマット順序は、1、5、2、3、4、6、7、8、9、13、10、11、12、13、14、15、16、17であり得る。この順序のパターンは、順序が、次のオープンGOPを開始するIフレームに依存するBフレームの最後の数列までは復号順序となり、そしてオープンGOP IフレームがBフレームのこの最後の数列に先行するのではなく、Bフレームがファイルフォーマット順序でオープンGOP Iフレームに先行するというものである。この変形形態では、オープンGOP Iフレームは、重複パッチとしてシグナリングされてよく、また、復号順序を取得するためにオープンGOP Iフレームがファイルフォーマット順序において配置されるべき箇所のバイトオフセットと共に、オープンGOP Iフレームの始まりおよび終わりのバイトオフセットをシグナリングされ得る。この変形形態では、シグナリングされてもされなくてもよい他の終了点は、ファイルフォーマット順序において復号順序である。
セグメントマップのURLを構築し導出するための方法
クライアントは、どうにかしてセグメントマップを取得する必要があり得る。セグメントマップを取得または入手するための方法のいくつかの好ましい特性は、AHSクライアントの既存の展開および/またはAHSフォーマットへと符号化されたコンテンツに対する変更を必要としない。例えば、セグメントマップに対するアクセス権を提供するための方法は、セグメントマップを使用しないAHSクライアント、および/または、自身がダウンロードし再生しているメディアコンテンツのセグメントマップが利用可能であることをまったく認識しないAHSクライアントが、セグメントマップが提供された時に影響を受けないように、後方互換性を伴って提供されることが望ましい。さらに、セグメントマップを提供しないメディアAHSメディアコンテンツを符号化し、フォーマットし、提供するための方法は、セグメントマップがそのAHSメディアコンテンツに対して利用可能にされる時に、変更される必要がないことが望ましい。
ALSのようなAHSストリーミングシステムに対して、メディアデータを含む各セグメントが、関連するURLを伴うファイルとして利用可能にされる。セグメントのURLは、例えばHTTP1.1を使用して、セグメントまたはセグメントの部分にアクセスしそれをダウンロードするために使用され得る。
セグメントに関連付けられる各セグメントマップも、関連するURLを伴うファイルとして利用可能にされ、セグメントマップのURLは、関連するセグメントのURLから自動的に生成され得る。例えば、セグメントマップのURLは、「.segment_map」が末尾に追加された、関連するセグメントのURLであり得る。
セグメントマップのスパンは、1つまたは複数のセグメントの部分として定義され、セグメントマップはその1つまたは複数のセグメントの部分についての情報を提供する。上で説明された実施形態では、セグメントマップのスパンは、セグメントマップが関連するセグメント全体である。他の実施形態では、セグメントマップのスパンとセグメントとの他の関係が可能である。
例えば、セグメントマップは、セグメントのセットに対して利用可能にされてよく、例えば、セグメントマップのスパンは、複数の連続するセグメントであってよく、この場合、セグメントマップのURLは、例えば、「.segment_map」をそのURLの末尾に追加することによって、連続的なセグメントの最初のURLから導出され得る。
別の代替形態として、セグメントマップはセグメントの複数の部分にわたってよく、この場合、セグメントマップのURLは、「.segment_map.X」を関連するセグメントのURLの末尾に追加することによって導出されてよく、「X」は、そのスパンがセグメントの複数の部分であるセグメントマップのシーケンス番号であってよく、例えば、そのスパンがセグメント複数の部分である10個のセグメントマップがある場合、これらセグメントマップのURLは、「.segment_map.0」、「.segment_map.1」、…、「.segment_map.9」をそれぞれ末尾に追加することによって、セグメントのURLから導出され得る。
上記の代替形態の改善は、セグメントの異なる期間にわたるセグメントマップを提供することである。例えば、複数のセグメントマップが存在してよく、各セグメントマップは、1時間のメディアデータを含むセグメントの、1分の提示時間にわたる。この場合、セグメント切り替えのためのURLは、「.segment_map.T」を末尾に追加することによってセグメントのURLから導出されてよく、「T」は0と59との間の整数値であり、これは、そのセグメントマップがわたる1分の期間のセグメント内の大まかな開始時分を示す。例えば、セグメントのURLが「the_movie_of_the_year」である場合、セグメント内の6分において開始するセグメントの1分の期間にわたるセグメントマップは、URL「the_movie_of_the_year.segment_map.6」を有し得る。
この代替形態および他の代替形態において、セグメントマップは、1つまたは複数のセグメントの重複部分にわたり得る。例えば、各セグメントマップは、セグメント中の30秒ごとのスパン開始点を有するセグメントマップが存在するように、1分のセグメントにわたり得るので、この例では、各セグメントマップのスパンは、2つの他のセグメントマップのスパンと30秒重複する。
第2の例として、セグメントの異なる長さにわたるセグメントマップ、例えば、1分の期間にわたるあるセグメント、2分の期間にわたる他のセグメント、および4分の期間にわたる他のセグメントが存在してよい。セグメントマップを備える情報の詳細は、そのスパンによって変わり得る。例えば、より長い期間または長さにわたるセグメントマップは、より短い期間または長さにわたるセグメントマップよりも離れた、開始点と終了点とを含み得る。
これら代替形態では、セグメントマップは、セグメントマップがどのセグメントまたはセグメントの部分に関連するかについての情報も含み得る。
セグメントマップの存在を認識しない、またはセグメントマップが利用可能であることを利用するように拡張されていないAHSクライアントは、上で説明されたように、セグメントマップが利用可能であることによって影響を受けない。
拡張AHSクライアントは、利用可能なセグメントマップを生成し作成することに関して上で説明されたもの以外に、AHS配信システムに対する追加の変更を伴うことなく、セグメントマップが利用可能であることを利用できる。拡張AHSクライアントは、例えば、「.segment_map」をセグメントのURLの末尾に追加することによって、セグメントのURLを使用してセグメントマップのURLを自動的に生成し、セグメントマップのURLに対するHTTP1.1要求を行い、セグメントマップをダウンロードし入手できる。
上で説明されたものに対する、URL生成のための代替的な方法が、表示のセグメントに関連する他のファイルに対して使用され得る。例えば、Luby A5は、セグメントからFEC修復データを生成し提供するための方法を教示し、FEC修復データの生成元のセグメントのURLの末尾に「.fec_repair」を追加することを提案する。
セグメントファイルと独立にセグメントマップファイルを構築するための方法
本明細書では、2レベルの構造を使用した、セグメントマップファイルを提供する異なる手法を説明する。第1のレベルにおいて、各セグメントマップファイルが、本明細書ではセグメントマップファイルの提示時間スパンと呼ばれる指定された期間の提示時間を概ねカバーするマッピング情報を含むように、セグメントマップファイルが編成され、指定された提示時間スパンは、各セグメントマップファイルに関連付けられるURLへと、暗黙的または明示的のいずれかに埋め込まれ、セグメントマップファイルに関連付けられる提示時間スパンの利用可能な指定されたシーケンスは、暗黙的に、または提示時間スパンを生成するための簡単な規則のいずれかに従うことによって推測され得る、規則的なパターンに従う。例えば、ALSシステムでは、提示時間スパンおよび提示開始時間オフセットは、表示のセグメントのALSシグナリングされた長さから推測され得る。例えば、セグメントの長さがT秒であることを、ALSがある表示に対してシグナリングすると、セグメントマップの提示開始時間オフセットのパターンは、0、T、2×T、3×T、4×T、5×Tなどであってよく、各セグメントマップがカバーする対応する時間スパンの長さは、2×T秒であり得る。
MPEG DASHシステムにおいてこれら方法を使用するために、「MPD」としても知られているMedia Presentation Descriptionが、URLテンプレート構築規則を介してセグメントマップのURLをシグナリングするように、MPEG DASH規格が強化されてよく、URLセグメントマップ構築規則は、提示開始時間オフセットパターンとセグメントマップの時間スパンの長さとを含む、セグメントマップのURLパターンを規定する。そのような強化MPDにおいてセグメントマップのURLパターンを表すために使用されるURLテンプレート構築規則は、MPEG DASH規格においてセグメントURLのパターンを規定するためのMPD URLテンプレート構築規則と同様であり得る。この場合、セグメントマップは、セグメントファイルの一部ではない別個のファイルであってよく、MPDにおいてセグメントのURLをシグナリングする代わりに、セグメントのためのURL構築規則を明示的または暗黙的のいずれかに使用して、セグメントのURLが、以下でより詳しく説明されるように、セグメントマップで搬送され得る。
第2のレベルにおいて、各セグメントマップファイルは、セグメントマップファイルに関連付けられるURLに埋め込まれた提示時間スパン内の、セグメント、セグメントの部分、または複数のセグメントについての詳細なマッピング情報を含む。このようにして、セグメントマップファイルの構造は、セグメントマップファイルがそれについてのマッピング情報を含む関連するセグメントファイルの構造とは独立にされ得る。
AHSクライアントを含むクライアントは、そのような2レベルの構造を次のように使用できる。ある提示時間PTを仮定すると、クライアントは、PTがセグメントマップファイルの提示時間スパン内にあるようにセグメントマップファイルのURLを決定し、このURLを使用してセグメントマップファイルにアクセスし、そして、セグメントマップファイル内の詳細なマッピング情報を使用して、PTの直前または直後の提示時間を伴うメディアデータと、PTの直前または直後の開始点および終了点のような関連するマッピング情報とをどのセグメントが含むかを判定できる。クライアントは、ある特定の提示時間で開始するコンテンツを再生するための、または、ある特定の提示時間に向かってコンテンツ内を探索するための、または、コンテンツのある表示から別の表示に切り替えるための、または様々な他の目的のための要求に応答して、どのセグメントをローカル記憶装置から入手すべきか、かつ/またはネットワークを通じてダウンロードすべきかを決めることができる。
可能なセグメントマップのURLフォーマットは、「content_ID.representation_ID.SPT_X.Dur_Y.segment_map」であり、「content_ID」はコンテンツを識別し、「representation_ID」はコンテンツの表示を識別し、「SPT_X」はスパンの提示開始時間がXであることを識別し、「Dur_Y」はスパンの提示終了時間がX+Yであることを識別する。セグメントファイルマップ内に含まれるマッピング情報の実際の提示時間スパンが、規定された提示時間スパンと完全に一致することは必要とされず、例えば、セグメントマップファイル内のマッピング情報が、X−dからX+Y+eの提示時間をカバーし、dおよびeは提示時間の小さな正の増分であるということがあり得ることに留意されたい。あるいは、dまたはeは、正の増分ではなく負の増分であってよい。
関連するセグメントマップファイルの集合体が、単一のエンティティとして利用可能にされてよく、例えば、同じcontent_IDとrepresentation_IDとを伴うセグメントマップファイルは一緒に収集され、例えば、同じcontent_IDおよびrepresentation_IDに関連付けられる全てのセグメントマップファイルが単一のファイルに含まれる場合、形式「content_ID.representation_ID.segment_map.zip」のURLを伴う単一のファイルとして提供されてよく、または別の例として、期間XからX+Yの提示時間スパンを伴う全てのセグメントマップファイルが単一のファイルに含まれる場合、形式「content_ID.representation_ID.SPT_X.Dur_Y.segment_map.zip」のURLを伴う単一のファイルとして提供され得る。よく知られている「ファイル圧縮」処理のような標準的な処理が、セグメントマップファイルを単一のファイルにまとめるために使用され得る。
別の可能なセグメントマップのURLフォーマットは、「content_ID.representation_ID.SPT_X.segment_map」であり、すなわち、提示開始時間はURLに含まれるが長さは含まれず、この場合、長さは各セグメントマップに対して同じであってよく、または異なるセグメントマップの間で変化してよい。
他の代替的なセグメントマップのURLフォーマットは、提示開始時間または長さに加えて、またはその代わりに、URL内でシグナリングされる提示終了時間を有することを含む。
セグメントマップファイルは、セグメントの部分または複数のセグメントにわたってよく、セグメントマップファイルの提示時間スパンは、セグメントマップファイルがそれについてのマッピング情報を提供するセグメントの提示時間スパンとは独立であってよい。従って、セグメントマップファイルは、セグメントマップファイルがそれについてのマッピング情報を含むセグメントまたはセグメントの部分のURLを、明示的または暗黙的のいずれかに含み得る。より一般的には、セグメントマップファイルは、セグメントの一部分を参照するために、URLと規定されたバイト範囲とを含み得る。例えば、提示時間が10秒から30秒の提示時間スパンを伴うセグメントマップファイルが存在し、5秒から15秒までの提示時間にわたるメディアデータを含むURL A_IDを伴う第1のセグメントがあり、10秒で開始するメディアデータが第1のセグメント内でA_ID.BOのバイトオフセットを有し、15秒から20秒までの提示時間にわたるメディアデータを含むURL B_IDを伴う第2のセグメントがあり、20秒から40秒までの提示時間にわたるメディアデータを含むURL C_IDを伴う第3のセグメントがあり、30秒で終了するメディアデータが第3のセグメント内でC_ID.BOのバイトオフセットを有する、と仮定する。そうすると、セグメントマップファイルは、第1のセグメントのために、開始バイトオフセットA_ID.BOに関連するマッピング情報と共にURL A_IDを含んでよく、第2のセグメントのために、URL B_IDに関連するマッピング情報とを含んでよく、第3のセグメントのために、終了バイトオフセットC_ID.BOに関連するマッピング情報と共にURL C_IDを含んでよい。セグメントマップファイルは、他の情報、例えば、セグメントの各々のサイズおよびセグメントの各々の総提示時間スパンも含み得る。ある提示時間における告知の挿入の指示、どのようなタイプおよびフォーマットのメディアがセグメントマップファイルの参照するセグメントの各々で搬送されるかの指示のような、他の情報もセグメントマップファイルに含まれ得る。
例えば、どのセグメントファイルについての情報をセグメントマップが含むかを示すための、セグメントマップのための可能な方法は次の通りである。
セグメントマップによるセグメントの参照の方法
Mを、セグメントマップによって参照される(部分的なまたは完全な)セグメントファイルの数とする。i=1,…,Mに対して、URL(i)を、提示時間の順序で並べられた、セグメントマップにおいて参照されるi番目のセグメントファイルのURLとし、BS(i)およびBE(i)をそれぞれ、バイト範囲の開始バイトオフセットおよび終了バイトオフセットとし、セグメントマップは、このバイト範囲についての情報を、i番目のセグメントファイルに対して含む。そして、これらセグメントを参照するためのセグメントマップフォーマットは、表5のようであってよい。
Figure 2014529970
上式は、i=1,…,Mに対する、URL(i)を伴うセグメントのバイト範囲BS(i)からBE(i)の連結物である「仮想セグメント(virtual segment)」を定義する。この「仮想セグメント」についてのセグメントマップ内の点の詳細なリストは、例えば、第4のセグメントマップ方法で説明されたフォーマットであってよく、リストされた点のバイトオフセットは、この仮想セグメントに関して計算される。従って、例えば、セグメントマップ内の2つの連続する点の間の仮想セグメントデータの部分が、部分的に一方のセグメント内にあり、部分的にもう一方のセグメント内にあるということがあり得る。BS(i)とBE(i)の1つまたは両方が、例えば、値の欠損を示すものとして−1を使用して、iの値の全てまたは一部に対する範囲から省略されてよい。例えば、[−1,BE(i)]は、セグメントの始まりからバイトオフセットBE(i)までの、URL(i)によって参照されるセグメントを示し、[BS(i),−1]は、バイトオフセットBS(i)からセグメントの終わりまでの、URL(i)によって参照されるセグメントを示し、[−1,−1]は、URL(i)によって参照されるセグメント全体を示す。
セグメントマップファイルは、一定のまたは予測可能な提示時間スパンに対して利用可能にされ得る。例えば、0modulo10秒に等しい可能性のある各提示開始時間スパンに対するセグメントマップファイルが存在することを示す、提示時間スパン規則が存在してよく、すなわち、セグメントマップファイルの提示開始時間は、コンテンツの終わりまで(終わりがあれば)、0秒、10秒、20秒、30秒、40秒、50秒などであり、各セグメントマップファイルの提示時間スパンの長さは20秒である。この場合、mouse_16543として識別され得るコンテンツに対し、rep_38934として識別され得るそのコンテンツの表示について、セグメントマップのURLのシーケンスは次の通りであり得る。
Figure 2014529970
この例では、提示時間スパンに対する規則を仮定すると、セグメントマップファイルのURLは、コンテンツ識別子mouse_16543および表示識別子rep_38934から決定されてよく、seg_mapは、ファイルをセグメントマップとして識別する。
別の代替形態として、セグメントマップファイルは、2つ以上の表示に対するマッピング情報を含み得る。例えば、セグメントマップファイルは、コンテンツの全ての表示についてのマッピング情報を含み得る。この場合、代替的な可能なセグメントマップのURLのフォーマットは、「content_ID.SPT_X.Dur_Y.seg_map」であり、「content_ID」はコンテンツを識別し、「SPT_X」はスパンの提示開始時間がXであることを識別し、「Dur_Y」はスパンの提示終了時間がX+Yであることを識別し、「seg_map」はこれをセグメントマップとして識別する。セグメントマップファイル内に含まれるマッピング情報の実際の提示時間スパンが、規定された提示時間スパンと完全に一致することは必要とされず、例えば、セグメントマップファイル内の各表示のためのマッピング情報が、X−dからX+Y+eまでの提示時間をカバーし、dおよびeが提示時間の小さな正の増分であるということがあり得ることに留意されたい。この場合、セグメントマップファイルは、コンテンツの複数の表示のための、セグメント、セグメントの部分、または複数のセグメントを参照し得る。
上記の実施形態では、セグメントマップファイルのURLは、コンテンツおよび表示のための何らかの基本URLから導出されてよく、セグメントマップファイル内のマップ情報は、ある一定の(大まかに一定、丸めは許容される)長さの提示時間、例えば、提示時間の開始の秒数および終了の秒数、または、提示時間の開始の秒数および長さの秒数、または、提示時間の開始の「ティック(ticks)」および長さの「ティック」で表される提示時間スパンをカバーし得る。「ティック」という単位が提示時間を表すために使用されることがあり、「ティック毎秒」が表示に関連する時間の単位である。各表示の「ティック単位」は、セグメントマップファイルに含まれ得る他の情報の例である。例えば、毎秒30000ティックは、各ティックが1秒の1/30000の部分であることを示す。上記の各場合において、提示時間スパンは、提示の始まりからの、または何らかの他の一定の基準時間までの、時間の累積的な尺度を使用して示される。
セグメントタイムラインファイルを使用する方法
このセクションにおいて説明される方法は、以前の方法に基づくが、MPEG DASH規格の変更の量がより少ない全体の構造を提供し、好ましい全体的な解決法を提供できる。
今後「セグメントタイムライン(segment timeline)」ファイルと呼ばれる、上で説明されたセグメントマップの特徴の一部を有する新たなタイプのファイルが、導入され得る。セグメントタイムラインファイルのURLは、セグメントマップについて上で説明されたものと同様に、提示時間の長さに基づいてURL構築規則を使用して生成されてよく、例えば、可能なフォーマットは、「content_ID.representation_ID.Dur_X.EPT_Y.segment_timeline」であり、「content_ID」および「representation_ID」はそれぞれコンテンツおよびコンテンツの表示を識別し、「X」はセグメントタイムラインによってカバーされる提示時間スパンの概略的な長さであり、「Y」は提示時間スパンの概略的な提示終了時間であり、「segment_timeline」はファイルをセグメントタイムラインファイルとして識別する。セグメントタイムラインファイルの存在、およびセグメントタイムラインファイルに対するURL構築規則は、MPD内でシグナリングされてよく、例えば、構築規則は、10秒の倍数からコンテンツの長さまでのYの全ての値に対するファイルが存在し、かつX=30であることを規定でき、XおよびYの値は単位が秒である。
セグメントのMPEG DASHフォーマットおよびセグメントのセグメントマップは、ISOファイルフォーマットにおいてセグメントのために使用されてよく、すなわち、セグメントマップ(Sidx)は、セグメントの先頭に追加され、そのセグメントで搬送されるデータの提示時間の長さをカバーする。MPEG2TSファイルフォーマットでは、セグメントマップ(Sidx)は、MPEG DASH規格において説明されるフォーマットで、セグメントとは別個のファイル内にあり、セグメントURLから導出されるURLを伴う、セグメント当たり1つのセグメントマップがある。セグメントのURLおよびセグメントマップ(これらが異なるファイル内にある場合)は、MPEG DASH規格における既存のURL構築規則を使用してシグナリングされることが推奨され、連続するセグメント(または別個のファイルとして搬送される場合はセグメントマップ)は、順番にインデックスを付されたURLを有することが推奨され、すなわち、セグメントのURLは、「content_ID.representation_ID.Index_X.segment」と同様のパターンに従ってよく、Xの値のシーケンスは、例えば0、1、2、3、4などであり、すなわち、提示時間において順次的であるセグメントに対する連続的な整数である。従って、セグメントのURLは、提示時間内のセグメントのシーケンスを示すが、シーケンスにおける異なるセグメントの長さは表示内において変動してよく、また、異なる長さであってよく、複数の表示の間で変動してよい。従って、セグメントマップのURLに割り当てられるインデックスは、提示時間スパンの順序に関して順次的であってよく、セグメントマップのURLに割り当てられるインデックスは、提示時間スパンの長さに依存しない。代替形態として、URLは、ALSシステムのための既存のALSのようにシグナリングされてよく、対応するセグメントマップのURLは、セグメントマップが関連するセグメントのURLから、簡単な規則によって導出されてよく、例えば、セグメントマップのURLは、「.seg_map」が末尾に追加された関連するセグメントのURLであり得る。
セグメントタイムラインファイルに関するセグメントのセットは、セグメントタイムラインファイルがカバーする提示スパンと重複する提示時間スパンをカバーする、セグメントのセットであると定義される。例えば、セグメントタイムラインファイルのURLが、「content_ID.representation_ID.Dur_15.EPT_60.segment_timeline」である場合、そのURLは、提示時間45で開始し提示時間60で終了する15秒の提示時間スパンの長さをカバーするので、45秒から60秒の期間内に提示開始時間または提示終了時間を有する全てのセグメントは、セグメントタイムラインファイルに関連すると言われる。セグメントタイムラインファイルに関連するセグメントマップの同様の定義を行うことができ、この定義は、提示時間の副範囲およびバイトの副範囲によって定義されるセグメントの部分またはセグメントマップを含むように拡張され得る。
セグメントタイムラインファイルは、セグメントタイムラインファイルに関連する、URLのリストとセグメントの提示開始時間(別個のファイルとして搬送される場合、セグメントマップも)とを含み得る。あるいは、セグメントタイムラインファイルは、セグメントURLを構築するもとになり得る情報、例えば、セグメントのインデックスの範囲を含んでよく、例えば、インデックスは、MPD内のセグメントに対するURLセグメント構築規則によって暗黙的に定義されるものに由来する。
MPDはまた、最大セグメント提示時間スパンTSmaxを規定でき、Timescaleも規定でき、Timescaleは、セグメントタイムラインのURLにおいて提示時間を表すために使用され得る。最大セグメント提示時間スパンTSmaxは、任意のセグメントの提示開始時間と、そのセグメントの前のセグメントの提示開始時間との差が大きくともTSmaxとなるように、定義され得る。例えば、TSmax=2秒である場合、セグメントiの提示開始時間と、提示時間の順序ですぐ前にあるセグメントi−1の提示開始時間との差は、大きくとも2秒である。
代替形態として、セグメントタイムラインファイルはまた、セグメントマップ、またはセグメントの提示終了時間、または他の関連情報を含み得る。
セグメントタイムラインファイルの指示は、ALSシステムによっても使用されてよく、URLの導出元の提示時間スパンは、例えば一定の長さを有し一定の提示終了時間にあり、例えば、提示終了時間は各々10秒でありスパンの全てが20秒の長さを有し、または、提示終了時間および長さは、一定の規則を使用してALSメタデータによって通知されるセグメントの長さから導出されてよく、例えば、セグメントの通知された長さがT秒である場合、セグメントタイムラインファイルは各々T秒で終了してよく、各々が2×Tの長さを有する。
セグメントマップファイルとセグメントタイムラインファイルとを使用するためのクライアント方法
セグメントマップファイルの1つの利点は、セグメントマップファイル無しに、クライアントがセグメントのセグメントマップ構造、例えば有効な開始点および終了点を実質的に決定できないことであり、これは、そのような情報がセグメント自体内で直接与えられないからである。そのようなセグメントマップ情報は、場合によってセグメントから導出され得るが、通常は、この情報を導出するためにセグメントがクライアントによってダウンロードされる必要があり、この情報は、メディアデータの構造を決定するためにメディアデータ自体がダウンロードされる必要があるので有効ではないことがあり、セグメントマップ情報を決定する主な目的の1つは、セグメントのどの部分をダウンロードするかを決定することである。さらに、セグメントマップ情報が導出され得る場所のクライアントアーキテクチャは通常、クライアントの表示選択方法の部分とは隔離されており、すなわち、セグメントマップ情報がクライアントによって導出され得る場所は、メディアが再生される場所に近いクライアントのメディア処理部分の奥深くにあり、一方、クライアントのクライアント表示選択部分は、メディアがネットワークを通じてクライアントに入る場所に近く、通常、クライアントのこれら2つの部分の間には良好なインターフェースがない。また、セグメントは暗号化され得るもので、マップ情報が導出され得るよりも前にセグメントが復号される必要があり、これは通常、表示選択論理と対話しないクライアントの隔離された部分にあるので、問題を悪化させる。
さらに、セグメントファイルがメディアデータを含む提示時間の長さは正確にシグナリングされないことがあり、例えば、ALSでは、各セグメントが10秒の長さとしてシグナリングされる場合、各セグメントは実際には、最も近い秒への丸めが原因で、9.5秒と10.5秒との間のどこかにあることがある。ALS/HLS規格では、セグメントの長さのみがシグナリングされるので、累積提示時間はシグナリングされず、クライアントは、最大で100秒の誤差、すなわち、200個のセグメントにわたる最大で200×0.5秒の累積推定誤差を有する、200番目の連続セグメントに対する、セグメント開始提示時間の推定を行い得る。さらに、コンテンツの符号化およびセグメントファイルへのセグメント化は、各表示に対して異なる長さを有する各ALS表示に対して、独立に実行されることがある。異なる表示のセグメントの長さは、ALSでは異なり得るので、これは、ある表示に長期間とどまった後で、ある表示から別の表示に切り替えようとする時に、特に問題となる。それは、切り替え先の表示において正しい提示時間を伴うセグメントを決定することが難しく、正しいセグメントを決定することは、いくつかの試行的なセグメントをダウンロードすることと、それらの提示時間を決定するためにそれらを詳しく調査する必要性とを伴い得るからである。当業者が認識するように、これら問題は、再生されないデータをダウンロードすること、再生されるべき次のメディアの部分をどのセグメントが含むかを決定するためにセグメントをダウンロードする間にメディアバッファ内の再生可能なメディアが完全になくなることによる、詰まり、再バッファまたはストールのようなユーザ体験の問題を引き起こすこと、および、開始点および終了点についての情報を有さないことにより、ある表示から別の表示へのシームレスな切り替えを提供しないことなどに関する、大きな非効率性をもたらし得る。これら問題および関連する問題の少なくとも一部は、表示の切り替えを試みないクライアントでも起こり得る。
上で説明された実施形態では、クライアントは、暗黙的なURL構築およびアクセスの規則を使用してセグメントマップにアクセスでき、例えば、クライアントは、コンテンツのために取得されたメタデータから、「content_ID」と「representation_ID」とを生成し、次いで、セグメントマップに対して可能な提示開始時間の期間は何かということについての提示スパン規則へのアクセス権を有し、例えば、提示スパン規則は、0、10、20、30、40、…、およびセグメントマップに対して可能な長さの期間、というパターンに従い、例えば、常に20である。このことから、クライアントは、セグメントマップのURLを形成してそれを要求でき、これによって、本明細書で開示される切替方法と高速始動方法に関連する方法とを実施する時に、どのセグメントをダウンロードしセグメントのどの部分をダウンロードするかを決定するために使用され得るマッピング情報を取得できる。セグメントマップファイル提示時間スパンが同様である場合、クライアントは、ある時間スパンの長さの間にある表示から別の表示にどのように切り替えるかを決めるために、異なる表示に対するセグメントマップファイルの同じ提示時間スパンを要求できる。しかしながら、セグメントマップファイルの提示時間スパンが異なる表示に対して異なる場合でも、基本的には同じ利点が提供される。あるいは、セグメントマップファイルが2つ以上の表示についての情報を含む場合、クライアントは、同じセグメントマップファイルからの表示の全てに対する、同じ提示時間スパンマッピング情報に関連する情報とにアクセスできる。また、セグメントマップの提示時間スパンは、例えば上の例のように重複していることがあるので、クライアントは境界条件に至らず、例えば、提示時間内の20秒前後で切り替えが起きるべきであるとクライアントが決定し、セグメントマップファイルの時間スパンが0〜10秒、その次が10〜20秒、その次が20〜30秒などである場合、クライアントは、10〜20秒にわたるセグメントマップファイルと、さらに、20〜30秒にわたるセグメントマップファイルとをダウンロードする必要があり得る。一方、各々10秒で開始するが各々20秒にわたるセグメントマップファイルもある場合は、クライアントは、例えば10〜30秒にわたるセグメントマップファイルをダウンロードし、20秒という目標の提示時間の前と後の両方のマッピング情報をファイルが含んでいることを確実にでき、これは、時間スパンが重複しない場合と比べて、時間スパンが重複する場合はこの例では2倍のセグメントマップファイルを有することと引き換えである可能性がある。一般に、マッピング情報はメディアコンテンツデータ自体と比較すると概ね小さいので、提示時間スパンが重複するのが好ましいことが多い。さらに、重複ははるかに小さくてよく、例えば、連続するセグメントマップファイルは、10秒の間隔で開始する期間をカバーし、各々のスパンは11秒であり、この場合、連続するセグメントマップの間の重複は1秒である。
これら実施形態は、既存のALSクライアントが負の影響を受けず修正されることなく動作できるように、既存のALSコンテンツの生成を拡張するために使用され得る。上で説明されたように具現化される追加の処理が、上で説明されたような関連するURLを伴うセグメントマップファイルを生成し、例えばHTTP1.1を使用してURLに基づいてアクセスするコンテンツ配信ネットワークにおいて、これらセグメントマップファイルを利用可能にするために、ALSシステムに加えられ得る。本明細書で説明される方法と処理とを伴う拡張クライアントは、表示のセグメントマップファイルのための適切なURLを形成し、適切なセグメントマップファイルを要求し、これらセグメントマップファイルを使用して始動および切替選択の方法を案内し、より良好なユーザ体験を提供できる。これら拡張クライアント方法は、簡単な方法でマッピング情報を使用でき、例えば、クライアントはそれでも、バイト範囲要求を伴わずにHTTPに基づいてセグメントファイル全体をダウンロードできるが、切り替えのための適切な開始点と終了点とを伴う切り替えのための正しい提示時間を有する、ダウンロードすべき正しいセグメントを、セグメントマップファイルから正確に決定することが少なくとも可能であり得る。HTTPバイト範囲要求がサポートされる場合、より高度なクライアントは、セグメントマップファイルに含まれるマッピング情報をより効率的に使用して、例えば、表示を切り替える時、またはコンテンツ内の規定された提示時間で開始する時に、ALSセグメントのどの部分をダウンロードするかを厳密に選択することによって、表示の切り替えと高速な始動とを可能にし得る。
拡張AHSクライアントは、そのようなセグメントマップが所与のコンテンツに対して利用可能であるという明示的なシグナリングを何ら伴わずに、セグメントマップファイルをダウンロードするのを試みることができる。セグメントマップが利用可能ではないコンテンツでは、クライアントのダウンロード要求は失敗し、例えば、HTTP応答は、例えば「HTTP error 404−file not found」を返し、この例では、拡張AHSクライアントは、セグメントマップがこのコンテンツでは利用可能ではないと推測し、非拡張ALSクライアントの挙動に戻ることができる。
本明細書で説明されるシステムおよび方法の拡張は、セグメントマップが特定の各コンテンツに対して利用可能かどうかを、各コンテンツに対して、例えばMPEG DASH MPDメタデータファイルにおいて明示的に示すことである。この場合、拡張AHSクライアントは、これを使用してセグメントマップが利用可能かどうかを判定できるので、例えば、セグメントマップに対するHTTP要求をそれが利用可能ではない場合に行い、「file not found」応答を受信するという余分なオーバーヘッドを避けることができる。この場合、拡張AHSクライアントは、セグメントマップが利用可能ではない場合、非拡張ALSクライアント方法と論理とを直ちに使用できる。さらに、セグメントマップが利用可能であると示されるが、何らかの理由でセグメントマップの全てが利用可能ではない(例えば、全体のコンテンツ配信ネットワークの一部における何らかの障害により)場合、拡張AHSクライアント方法は、「file not found」応答が何らかの要求に対して返ってきた場合に何をすべきかを知っているという意味でより堅牢(robust)であり得る。すなわち、一部のセグメントマップが利用可能ではない場合でも、他の表示および期間に対する他のセグメントマップは依然として利用可能であり得ると共に、拡張AHSクライアントは利用可能であり得るセグメントマップを依然として要求し続け得る。
別の可能な拡張は、背後にあるフレーム依存構造およびファイルフォーマット順序、すなわち、良好に選択された開始点における開始セグメントおよび良好に選択された終了点における終了セグメントなどとより良好に揃うように、セグメント構造を生成することである。例えば、セグメントは、ある主開始点から次の連続する主開始点にわたるように構築され得る。セグメントマップファイルはそれでも、セグメントファイルの時間スパンとは独立である、時間スパンの規則的なパターンを有し得る。これによって、HTTP1.1バイト範囲要求の使用の大部分または全てを回避でき、それでも、開始点で開始し終了点で終了する部分における表示からコンテンツをダウンロードできるという利益を受けることができる、セグメントをダウンロードするための拡張AHSクライアント向けの簡単なアルゴリズムを提供する。HTTPバイト範囲要求は広くサポートされないことがあるので、上記のことは有利であり得る。
セグメントマップは、他の関連情報も含み得る。例えば、セグメントマップは、特定の表示がオーディオのみか、オーディオとビデオの組合せか、またはビデオのみかを示し得る。別の例として、セグメントマップは、FEC修復セグメントのURLと、FEC修復セグメントのセグメントマッピング情報、例えば、Luby A4で開示されるフォーマットまたは同様の代替的なフォーマットのセグメントマッピング情報とを含み得る。セグメントファイルに関しては、セグメントマップは、セグメントマップファイル構造とは独立の構造を伴う、複数のまたは部分的なFEC修復セグメントのためのURLおよび/または関連するマッピング情報を含んでよく、AHSクライアントは、セグメントマップのURL構造に基づいてこれらセグメントマップにアクセスし、次いで、セグメントマップに含まれる情報を使用してどのFEC修復セグメントにアクセスすべきかを決定し、FEC修復セグメントの構造を決定できる。
セグメントタイムラインファイルを使用する上で説明されたシステムに対して、AHSクライアントは次のように動作し得る。MPDから、AHSクライアントは、セグメントタイムラインファイルの提示時間スパンも示す、セグメントタイムラインファイルのURLのリストを構築できる。AHSクライアントはまた、URL構築規則から、または、前に説明されたような他の手段のいずれかで、セグメントのURLのリストを構築できる。AHSクライアントは、セグメントタイムラインファイルがいつ利用可能かということと、セグメントタイムラインファイルをいつダウンロードすべきかということとを、現在の実時間と、見られているコンテンツの提示タイムラインに対する現在の実時間の関係とに基づいて、決めることができる。セグメントタイムラインファイルから、AHSクライアントは、関連するセグメントデータとセグメントマッピング情報とを含むどのセグメントとセグメントマップとをダウンロードすべきかを決定できる。セグメントタイムラインファイルにおいてリストされる最後のセグメントに対して、AHSクライアントは、その最後のセグメントのダウンロードがいつ可能になるかを、セグメントタイムラインファイルにおいてリストされた提示開始時間から、かつ、任意のセグメントの最長の提示時間スパンである値TSmaxから、決定できる。従って、コンテンツが利用可能になってから、コンテンツがAHSによりダウンロードされ見られるまでの、全体のエンドツーエンドの遅延は、セグメントタイムラインファイルの追加による影響を受けず、一方、セグメントタイムラインファイルは、ある表示から別の表示に切り替える時、または、コンテンツの最中のある提示時間からコンテンツを開始する時、どのセグメントとセグメントマップとをダウンロードすべきかということについて、AHSクライアントに価値のあるヒントを与える。従って、AHSクライアントの性能をよくするために、セグメントタイムラインファイルを提供することには、多くの利点がある。
図15は、DASHシステムにおけるセグメントタイムラインファイルのシグナリングの例を示す。図15の左側は、コンテンツに対して利用可能にされ得るMedia Presentation Description(MPD)の何らかの関連のある部分を示し、この例では、MPDにおいて表される2つの表示がある。第1の表示では、ビデオが約500Kbpsで640×480の解像度で符号化されることが可能であり、第2の表示では、ビデオが約250Kbpsで符号化されることが可能であり解像度はやはり640×480であり、両方の表示が、コンテンツ中の100秒で開始する期間内で利用可能である。この例におけるコンテンツの全てに対する基本URLは、http://www.example.com/である。
図15に示されるように、第1の表示に対するセグメントタイムラインファイルの時間軸は、毎秒1ティックであり、これらセグメントタイムラインファイルのURLテンプレートパターンは、./ahs−5−DUR4.EPT$2*Tind$.timeであり、完全なURLは、基本URLとこのテンプレートにより定義されるURL部分との連結物である。ここで、DUR4は、セグメントタイムラインによってカバーされる提示時間のスパンが4ティック、すなわちtimescale=1なので等価的に4秒であることを示し、EPT$2*Tind$は、スパンの提示終了時間が2×Tindティック、すなわちtimescale=1なので等価的に2×Tind秒であることを示し、Tindはセグメントタイムラインファイルのインデックスを示す。従って、第1のセグメントタイムラインファイル(Tind=1である)の完全なURLは、http://www.example.com/ahs−5−DUR4.EPT2.timeであり、第2のセグメントタイムラインファイル(Tind=2である)の完全なURLは、http://www.example.com/ahs−5−DUR4.EPT4.timeであり、以下同様である。これは、全てのセグメントタイムラインファイルが4秒のスパンをカバーし、第1のセグメントタイムラインファイルのスパンが提示時間2秒で終了し(従って、スパンの最初の2秒は実際には存在しない)、第2のセグメントタイムラインのスパンが提示時間4秒で終了し、以下同様であることを示す。
図15に示されるように、第1の表示のセグメントファイルの時間軸は、毎秒30000ティックであり、これらセグメントファイルのURLテンプレートパターンは、./ahs−5−$Sind$.3gsであり、完全なURLは、基本URLとこのテンプレートにより定義されるURL部分との連結物である。ここで、Sindはセグメントファイルのインデックスを示す。従って、第1のセグメントファイル(Sind=1である)の完全なURLは、http://www.example.com/ahs−5−1.3gsであり、第2のセグメントファイル(Sind=2である)の完全なURLは、http://www.example.com/ahs−5−2.3gsであり、以下同様である。
図15の中央部に示されるセグメントタイムラインファイルは、セグメントタイムラインファイルによってカバーされる提示時間スパン内に提示開始時間を有するセグメントファイルの各々に対するSindを搬送し、そのセグメントファイルで搬送されるメディアの対応するSPT(提示開始時間)も搬送し、SPTの単位はセグメント時間軸のティックであり、すなわち毎秒30000ティックである。例えば、Sind=5かつSPT=79079である第5のセグメントについての情報は、第2のセグメントタイムラインファイル(Tind=2)と第3のセグメントタイムラインファイル(Tind=3)の両方で搬送され、それは、79079ティックのSPTが79079/30000秒に対応し、すなわち約2.64秒が第2のセグメントタイムラインファイルと第3のセグメントタイムラインファイルの両方のタイムスパン内にあるからである。いくつかの実施形態では、他のデータも、セグメントタイムラインファイル、例えば、セグメントに対するセグメントマップなどで搬送される。
図15の右側に示されるセグメントファイルは、示されるSPTで開始するメディアデータを搬送し、これらセグメントファイルの各々のURLが示される。セグメントファイルで搬送されるデータの大部分、例えば、メディアデータ自体、および場合によってセグメントに関連するセグメントマップなどは、図15に示されていない。
図15の左側に示されるMPDはまた、第2の表示に関連付けられる、セグメントタイムラインファイルとセグメントファイル情報とを示す。対応するセグメントタイムラインファイルおよびセグメントファイルは、この第2の表示について、図15に示されない。図15に示されるように、第2の表示に対するセグメントタイムラインファイルの時間軸は、毎秒1ティックであり、これらセグメントタイムラインファイルのURLテンプレートパターンは、./ahs−2−DUR7.EPT$3*Tind$.timeであり、完全なURLは、基本URLとこのテンプレートにより定義されるURL部分との連結物である。ここで、DUR7は、セグメントタイムラインによってカバーされる提示時間のスパンが7ティック、すなわちtimescale=1なので等価的に7秒であることを示し、EPT$3*Tind$は、スパンの提示終了時間が3×Tindティック、すなわちtimescale=1なので等価的に3×Tind秒であることを示し、Tindはセグメントタイムラインファイルのインデックスを示す。従って、第1のセグメントタイムラインファイル(Tind=1である)の完全なURLは、http://www.example.com/ahs−2−DUR7.EPT3.timeであり、第2のセグメントタイムラインファイル(Tind=2である)の完全なURLは、http://www.example.com/ahs−2−DUR7.EPT6.timeであり、以下同様である。これは、全てのセグメントタイムラインファイルが7秒のスパンをカバーし、第1のセグメントタイムラインファイルのスパンが提示時間3秒で終了し(従って、スパンの最初の4秒は実際には存在しない)、第2のセグメントタイムラインのスパンが提示時間6秒で終了し、以下同様であることを示す。図15に示されるように、第2の表示のセグメントタイムラインファイルの時間軸は、毎秒30000ティックであり、これらセグメントファイルのURLテンプレートパターンは、./ahs−2−$Sind$.3gsであり、完全なURLは、基本URLとこのテンプレートにより定義されるURL部分との連結物である。ここで、Sindはセグメントファイルのインデックスを示す。従って、第1のセグメントファイル(Sind=1である)の完全なURLは、http://www.example.com/ahs−2−1.3gsであり、第2のセグメントファイル(Sind=2である)の完全なURLは、http://www.example.com/ahs−2−2.3gsであり、以下同様である。
図15に示される例では、AHSクライアントは次のように動作し得る。AHSクライアントは、MPDのURLを使用してMPDをダウンロードし、MPD内の情報を使用して、上で説明されたようなセグメントタイムラインファイルとセグメントファイル情報とを決定できる。AHSクライアントが、毎秒30000ティックのセグメント時間軸において、提示時間約110000ティックで第1の表示へ切り替えることを望むと仮定する。110000/30000は約3.67秒なので、AHSクライアントは、3.67秒がセグメントタイムラインによってカバーされる時間スパンの最中のどこかとなるように、セグメントタイムラインのURLを形成することを選ぶことができ、例えば、6秒のEPTと4秒の時間スパンの長さとを有するTind=3であるセグメントタイムラインファイルが良好な選択であることがあり、AHSクライアントは、MPD内の第1の表示に対するセグメントタイムラインURLテンプレート構築規則を使用して、このセグメントタイムラインファイルのURLを、http://www.example.com/ahs−5−DUR4.EPT6.timeと決定できる。AHSクライアントは、このURLを使用して、次のデータ要素を含むこのセグメントタイムラインファイルをダウンロードできる。
Figure 2014529970
79079<110000<125125なので、AHSクライアントは、AHSクライアントが第1の表示に切り替えることを望む地点が、Sind=5であるセグメントファイル内にあると判定できる。MPD内のセグメントURLテンプレート構築規則と、セグメントインデックスSind=5とに基づいて、AHSクライアントは、このセグメントのURLをhttp://www.example.com/ahs−5−5.3gsとして形成でき、AHSクライアントは、このURLを使用してこのセグメントをダウンロードできる。
上記の多数の変形形態が存在する。例えば、ライブストリーミングサービスでは、AHSクライアントは、現在の提示時間に基づいて、ファイルのダウンロードがいつ利用可能になるかを判定できる。例えば、セグメントタイムラインファイルは、直ちに、または、現在の提示時間がセグメントタイムラインファイルの提示終了時間(EPT)に達したすぐ後に、ダウンロードが可能になってよく、AHSクライアントは、セグメントタイムラインのURLテンプレート構築規則および現在の提示時間に基づいて、どのセグメントタイムラインファイルのダウンロードが可能かを判定できる。別の例として、セグメントファイルのダウンロードは、直ちに、または現在の提示時間が後続のセグメントファイルのSPTに達してからすぐ後に、可能になってよい。従って、AHSクライアントは、セグメントタイムラインファイルで搬送されるセグメントインデックスおよびそれらの対応するSPTに基づいて、どのセグメントファイルのダウンロードが可能かを判定できる。例えば、AHSクライアントがEPT=Zまでの時間スパンをカバーするセグメントタイムラインファイルをダウンロードしており、セグメントタイムラインファイルが長くともZである最大提示時間を伴うメディアデータを搬送するSind=iであるセグメントファイルについての情報を搬送する場合、AHSクライアントは、Sind=iであるセグメントファイルのダウンロードが可能である、またはまもなく可能になると判定できる。別の例として、Sind=iかつSPT=Yであるセグメントファイルがセグメントタイムラインファイルにおいてリストされる最後のセグメントファイルである場合、AHSクライアントは、利用可能なメディア提示時間が提示時間Y+TSmaxかそれよりも後である時、Sind=iであるセグメントファイルのダウンロードが可能であると判定でき、TSmaxは、セグメントファイルの時間スパンの上限を上回るものとして定義される。
AHSクライアントは、特定の提示時間Tのメディアデータをどのセグメントファイルが含むかを、次のように決定できる。AHSクライアントは、Tを含む提示時間スパンを伴うセグメントタイムラインファイルのURL、すなわち、提示時間Z−Aで開始し提示時間Zで終了する(ここでZ−A≦T≦Z)長さAの提示時間スパンを伴うセグメントタイムラインファイルのURLを決定できる。これは、Tの値を使用してZとAとを計算する、セグメントタイムラインURLテンプレート構築規則を使用して行われ得る。いくつかのそのようなセグメントタイムラインファイルが存在することがあり、Tが提示時間スパンの中心に最も近いようなセグメントタイムラインファイルが好ましいことがあることに、留意されたい。AHSクライアントは、構築されたURLを使用して、セグメントタイムラインファイルをダウンロードできる。次いで、セグメントタイムラインファイルにおける情報に基づいて、AHSクライアントは、どのセグメントファイルがTを含むかを次のように決定できる。Y_1、Y_2、…、Y_kを、セグメントタイムラインファイルが情報を含むk個のセグメントファイルのSPTとし、i+1、i+2、・・・、i+kを、これらセグメントファイルのインデックスとし、kの値もパラメータとしてセグメントタイムラインマップで搬送されてよく、Z−A≦Y_1<Y_2<…<Y_k≦Zである。Z−A≦T<Y_1である場合、インデックスiを伴うセグメントファイルは提示時間Tを含み、2とkとの間の何らかのjに対してY_(j−1)≦T<Y_jである場合、インデックスj−1を伴うセグメントファイルは提示時間Tを含み、Y_k≦T<Zである場合、インデックスkを伴うセグメントファイルは提示時間Tを含む。
時間ベースとインデックスベースの混合されたセグメントURLテンプレートの生成
セグメントURLテンプレート構築規則は、時間ベースの要素とインデックスベースの要素の両方を含むように、次のように強化され得る。TimescaleSegURLを、表示の全てのセグメントのセグメントURLに含まれる時間ベースの情報に対する、1秒当たりのティックの数を表すために使用される時間軸とし、TindおよびSindを正の整数のインデックスとし、TMを正の整数の定数とする。すると、セグメントURLテンプレート構築規則は、次の形式となり得る。
1.Content_ID.Representation_ID.PT$Tind$.SEG$Sind$
TMの値は、TM/TimescaleSegURLが少なくともTSmaxとなるように設定されるべきであり、TSmaxは、この表示内における任意のセグメントの最大提示時間スパンである。例えば、TSmax=2.2秒でありTimescaleSegURL=10である場合、TM/TimescaleSegURL=22/10秒≧TSmaxなので、TMは22と等しく設定され得る。このことは、TM×Tindが大きくとも表示の総提示時間スパンであるような各正の整数に対して、少なくとも1つのセグメントがTM×(Tind−1)とTM×Tindとの間の提示時間の期間に開始することを保証し、ここで全ての時間が、時間軸TimescaleSegURLに対するものである。
各セグメントに対して、そのセグメントのTindおよびSindの値は、上記のセグメントURLテンプレート構築規則に従って、そのセグメントのURLを完全に定義する。セグメントのTindおよびSindの値は、次のように決定され得る。セグメントのTindの値は、TM×(Tind−1)≦SPT<TM×Tindを満たし、SPTは、TimescaleSegURLの時間軸における、セグメントの提示開始時間SPTである。上で説明されたように、Tind×TMが大きくとも表示の総提示時間スパンであるような各正のTindに対して、値Tindを割り当てられた少なくとも1つのセグメントである。値Tindを割り当てられたセグメントうち、最早のSPTを伴うセグメントは値Sind=1を割り当てられ、その次に早いSPTを伴うセグメントは値Sind=2を割り当てられ、その次に早いSPTを伴うセグメントは値Sind=3を割り当てられ、ここで、セグメントの数はTindの異なる値に対して変化するので、Sindの最大の使用される値は、Tindの異なる値に対して変化し得る。
図16は、DASHシステムにおける、時間ベースとインデックスベースの混合されたセグメントURLテンプレートの生成の例を示す。図16の左側は、コンテンツに対して利用可能にされ得るMedia Presentation Description(MPD)の何らかの関連のある部分を示し、この例では、MPDにおいて表される2つの表示がある。第1の表示では、ビデオが約500Kbpsで640×480の解像度で符号化されることが可能であり、第2の表示では、ビデオが約250Kbpsで符号化されることが可能であり解像度はやはり640×480であり、両方の表示が、コンテンツ中の100秒で開始する期間内で利用可能である。この例におけるコンテンツの全てに対する基本URLは、http://www.example.com/である。
図16に示されるように、第1の表示のセグメントURLのTimescaleSegURLは、毎秒10ティックであり、TMの値は22ティックであり、これらセグメントファイルのURLテンプレートパターンは、./ahs−5−$Tind$.$Sind$.3gsであり、セグメントの完全なURLは、基本URLとこのテンプレートにより定義されるURL部分との連結物である。TM=22かつTimescaleSegURL=10なので、第1の表示の任意セグメントの最大提示時間スパンは、22/10=2.2秒であることに留意されたい。TM×Tindは、Tindの所与の値を伴うセグメントの提示開始時間のスパンが、TimescaleSegURLの時間軸においてTM×Tindティックであることを示し、すなわち、第1の表示に対して、Tindの各値は、セグメント提示開始時間の2.2秒をカバーする。TM×(Tind−1)とTindとの間で最早の提示開始時間を伴うセグメントはSind=1を有し、TM×(Tind−1)とTindとの間で2番目に早い提示開始時間を伴うセグメントは、そのようなセグメントがあれば、Sind=2を有し、以下同様である。従って、Tind=1である第1のセグメントファイルの完全なURLは、http://www.example.com/ahs−5−1.1.3gsであり、Tind=1である第2のセグメントファイルの完全なURLは、http://www.example.com/ahs−5−1.2.3gsであり、Tind=2である第1のセグメントファイルは、http://www.example.com/ahs−5−2.1.3gsである。
図16に示されるように、第1の表示のTimescaleSegは、毎秒30000ティックであり、これは、セグメント内のメディアフレームに対して表される提示時間が、毎秒30000ティックの単位であることを示す。従って、例えば、セグメント内のフレームの提示時間が10010である場合、秒単位での提示時間は10010/30000、すなわち約0.33秒である。
図16の中心に示される第1の表示のセグメントファイルは、TimescaleSegの単位で、セグメントの提示開始時間SPTを示し、セグメントのURLも示す。例えば、第5のセグメントはSPT=79079を有し、これは、79079/30000秒、すなわち約2.636秒に対応する。このSPTは、TimescaleSegURL=毎秒10ティックの単位で22ティックと44ティックとの間、すなわち2.2秒と4.4秒との間にあるので、このセグメントではTind=2である。さらに、これは、TimescaleSegURL=毎秒10ティックの単位で22ティックと44ティックとの間にある最早のSPTを伴うセグメントなので、このセグメントではSind=1である。従って、セグメント5のセグメントURLは、図16に示されるように、http://www.example.com/ahs−5−2.1.3gsである。図16は、あったとしても、セグメントファイルで搬送されるメディアデータまたはセグメントマップ情報を示さない。
図16に示されるように、第2の表示のセグメントURLのTimescaleSegURLは、毎秒20ティックであり、TMの値は30ティックであり、これらセグメントファイルのURLテンプレートパターンは、./ahs−2−$Tind$.$Sind$.3gsであり、セグメントの完全なURLは、基本URLとこのテンプレートにより定義されるURL部分との連結物である。TM=30かつTimescaleSegURL=20なので、第1の表示の任意セグメントの最大提示時間スパンは、30/20=1.5秒であることに留意されたい。TM×Tindは、Tindの所与の値を伴うセグメントの提示開始時間のスパンが、TimescaleSegURLの時間軸においてTM×Tindティックであることを示し、すなわち、第1の表示に対して、Tindの各値は、セグメント提示開始時間の1.5秒をカバーする。TM×(Tind−1)とTindとの間で最早の提示開始時間を伴うセグメントはSind=1を有し、TM×(Tind−1)とTindとの間で2番目に早い提示開始時間を伴うセグメントは、そのようなセグメントがあれば、Sind=2を有し、以下同様である。従って、Tind=1である第1のセグメントファイルの完全なURLは、http://www.example.com/ahs−5−1.1.3gsであり、Tind=1である第2のセグメントファイルの完全なURLは、http://www.example.com/ahs−5−1.2.3gsであり、Tind=2である第1のセグメントファイルは、http://www.example.com/ahs−5−2.1.3gsである。
図16に示されるように、第2の表示のTimescaleSegは、毎秒30000ティックであり、これは、セグメント内のメディアフレームに対して表される提示時間が、毎秒30000ティックの単位であることを示す。従って、例えば、セグメント内のフレームの提示時間が11011である場合、秒単位での提示時間は11011/30000、すなわち約0.367秒である。
図16の右側に示される第2の表示のセグメントファイルは、TimescaleSegの単位で、セグメントの提示開始時間SPTを示し、セグメントのURLも示す。例えば、第8のセグメントはSPT=175175を有し、これは、175175/30000秒、すなわち約5.84秒に対応する。このSPTは、TimescaleSegURL=毎秒20ティックの単位で90ティックと120ティックとの間、すなわち4.5秒と6秒との間にあるので、このセグメントではTind=4である。さらに、これは、TimescaleSegURL=毎秒20ティックの単位で90ティックと120ティックとの間にある2番目に早いSPTを伴うセグメントなので、このセグメントではSind=2である。セグメント8のセグメントURLは、図16に示されるように、http://www.example.com/ahs−2−4.2.3gsである。
表示のセグメント化を実行するサーバによる、上記のセグメントURLテンプレート構築規則に従ったセグメントURLの生成は単純である。セグメントURLのTindは、セグメントの提示開始時間のみに依存し、URLのSindは、同じTindを有する以前に生成されたセグメントの数のみに依存する。従って、セグメントURLは、そのようなサーバによってリアルタイムに生成されてよく、セグメントで搬送されるメディアが利用可能になる前に、かつ、セグメントで搬送されるメディアの提示時間が利用可能になる前に、利用可能にされてよい。
上で説明されたような、時間ベースとインデックスベースの混合されたセグメントURLテンプレートの生成の利点は、セグメントが可変の提示時間スパンを有し得る一方で、同時に、AHSクライアントがセグメントURLを構築でき、正確なセグメント提示時間スパンについての事前の情報を伴うことなく、かつ、セグメントURLリストまたはMPDに対する複雑な更新を伴うことなく、セグメントをダウンロードできることである。すなわち、AHSクライアントは、簡単なセグメントURLテンプレート構築規則を使用して、関心のあるセグメントのURLを構築できる。可変の提示時間スパンを伴うセグメントの利点は、以前に説明されており、例えば、このことは、セグメントが主開始点で開始することを可能にし、最良の圧縮と再生の品質とを提供する自然な提示時間の境界にビデオ圧縮が主開始点を柔軟に配置することを可能にし、これら境界は、コンテンツ自体内の、シーンの変化または動作のシーケンスによって決定され得る。
AHSクライアントは、時間ベースとインデックスベースの混合されたセグメントURLテンプレートの生成に基づいて、ライブシステムに対して次のように動作できる。AHSクライアントは、MPDのURLを使用してMPDをダウンロードし、MPD内の情報を使用して、上で説明されたようなセグメントURLテンプレート構築規則とMPD内の他の情報とを決定できる。例えば、AHSクライアントは、クライアントが要求し得る可能性のある表示のTMおよびTimescaleSegURLの値を使用して、任意のこれら関連する表示の任意のセグメントの提示時間スパンの上限TSmaxを決定できる。例えば、2つの表示がある図16では、いずれの表示の選択もクライアントに可能であると仮定すると、クライアントは、22/10と30/20の大きい方、すなわち、2.2秒と1.5秒の大きい方として、TSmaxを計算できる。
AHSクライアントが、何らかの実時間Tにおいてライブストリームからの表示の要求と再生とを開始することを決めると仮定し、Tは、表示のTimescaleSegURLティックの単位で表される。AHSクライアントが要求し再生することを望む表示のTおよびTMに基づいて、クライアントは、M=floor(T/TM)を計算でき、floorは、その変数以下の最大の整数を出力する関数である。クライアントは、Tind=M−1およびSind=1に対応するURLを伴う、セグメントIと呼ぶセグメントを要求できる。時間Tにおいて、セグメントIは利用可能であることが保証され、それは、Tind=M−1である任意のセグメントの提示開始時間がTimescaleSegURLの単位で少なくともTMティックだけTよりも前にあり、かつ、セグメントIの提示時間スパンがTimescaleSegURLの単位で長くともTMティックであり、セグメントIの終わりがTよりも前であり従ってセグメントIが利用可能であるからである。さらに、Tind=M−1である少なくとも1つのセグメントがあるので、Tind=M−1およびSind=1であるセグメントIがある。AHSクライアントは、現在の実時間TとセグメントIの提示開始時間との差が、例えばTSmaxの何らかの倍数であれば、例えば、差が少なくともTSmaxまたは少なくとも2×TSmaxであれば、セグメントIの再生を開始できる。
多くの可能性のあるAHSクライアント戦略が可能である。例えば、クライアントは、さらに過去のメディアのダウンロードを開始し、再生のためにメディアのバッファを構築でき、これには、ダウンロード遅延に対する回復力を向上させ、最初のダウンロードレートが最初の再生レートよりも高い場合に始動時間を低減するかもしれない潜在的利益を伴う。
上では、かつ以下では、「実時間(real-time)」、「Tの値(the value of T)」、および「利用可能である(available)」という用語は一般に、コンテンツが作成された時とコンテンツの再生が可能になった時との間の遅延が可能な限り少ない状態で、クライアントがライブコンテンツの再生を実時間で試みている時の状況(situation)を表すコンテキスト(context)で使用される。上で説明されたように、クライアントは、メディアバッファを構築するために、ライブコンテンツの提示時間においてさらに後にあるコンテンツを再生することを選ぶことができ、オンデマンドコンテンツでは、コンテンツの全てが、始めからクライアントに利用可能であり得るので、これらコンテキスト(context)では、「実時間」は、クライアントが現在ダウンロードを望んでいるメディアの所望の提示時間としてより一般的に見られ、「Tの値」は、クライアントが現在ダウンロードを試みているコンテンツの概略的な提示時間であり、クライアントがダウンロードを試みているコンテンツの全てが利用可能である。
AHSクライアントがセグメントIをダウンロードすると、または、セグメントIの提示終了時間へのアクセス権を有すると、AHSクライアントは、次のセグメントI+1の提示開始時間も知る。セグメントI+1の提示開始時間は、セグメントI+1がTind=M−1とSind=2とを有するかどうか、すなわち、セグメントI+1の提示開始時間がTimescaleSegURLの単位でTM×(M−1)未満であるかどうかを判定し、または、セグメントI+1がTind=MとSind=1とを有するかどうか、すなわち、セグメントI+1の提示開始時間がTimescaleSegURLの単位でTM×(M−1)以上であるかどうかを判定するために、使用され得る。このように続けて、AHSクライアントは常に、表示内において現在のセグメントの後のセグメントのTindとSindとを決定でき、従って次のセグメントのURLを決定できる。
何らかの理由で、AHSクライアントが、Tind=M−1である、表示の特定のセグメントにアクセスできない場合、または特定のセグメントについての情報にアクセスできない場合、AHSクライアントは、前の段落で説明された手順を使用して、欠落セグメントの後の後続のセグメントのURLを決定することが可能ではないことがある。しかしながら、AHSクライアントは、Tind=MかつSind=1であるセグメントのURLを決定でき、それは、各Tindに対して少なくとも1つのセグメントがあり、Tind=MかつSind=1であるセグメントが何らかの点で利用可能であるはずであるからである。従って、AHSクライアントが、例えばサーバまたはネットワーク配信のエラーにより、表示からのあるセグメントを欠いている場合、AHSクライアントは、次に大きいTind値を伴う最初のセグメントへとスキップすることがあり、これによって、メディアコンテンツの長くとも2×TM/TimescaleSegURLのスパンの提示時間の再生を欠くことがある。
AHSクライアントは、次のような戦略を使用して、第1の表示から第2の表示に切り替えることができる。TMおよびTimescaleSegURLを、切り替え先の第2の表示に対するものとし、Tを、切り替えの決定が行われた実時間をTimescaleSegURLのティック単位で表したものとする。TがTMによって等しく分割可能である次の値に達すると、すなわち、M=T/TMが整数になるとすぐに、AHSクライアントは、第2の表示からのセグメントIと呼ぶセグメントに対して、Tind=M−1およびSind=1に対応するURLを生成し、セグメントIの提示開始時間において第2の表示に切り替えることができる。一方、AHSクライアントは、第2の表示のセグメントIの少なくとも提示開始時間まで再生できるようになるまで、第1の表示からのセグメントのダウンロードを続けて、次いで、第2の表示のセグメントIの再生に切り替えることができる。この段落で説明された方法を使用して、実時間と再生された提示時間との差が少なくとも2×TSmaxである場合、セグメントのダウンロードが要求される時と、セグメントの再生を開始するのに少なくとも十分なセグメントがAHSクライアントに到達した時との間の時間を考慮せずに、第1の表示から第2の表示への切り替えを、詰まりまたは休止を何ら伴わずに実行できる。
AHSクライアント方法の例として、図16を考える。MPDから、クライアントは、これら2つの表示に対して、TSmax=max{22/10,30/20}=2.2秒であると決定できる。クライアントが、TimescaleSegURL=毎秒10ティックの単位で実時間T=52において、すなわち、実時間5.2秒において、第1の表示に参加することを決めると仮定する。第1のクライアント戦略は、クライアントがM=floor(T/TM)を計算することであり、ここでTM=22なのでM=2である。これに基づいて、クライアントは、Tind=M−1=1およびSind=1に対応するセグメント、すなわちセグメント1のURLを生成し、次いで、セグメント1を要求しダウンロードできる。セグメント1はこの時点で利用可能であり、それは、セグメント1の提示終了時間は大きくともセグメント2の提示開始時間であり、セグメント2の提示開始時間は10010/30000すなわち約0.333秒であるからである。クライアントは、セグメント1の少なくとも一部を受信すると、メディアコンテンツの再生を開始でき、従って、実時間と提示時間との間のラグは、この例では約5.2−0.33=4.87秒であり、一般にこの第1のクライアント戦略を使用すると大きくとも3×TSmaxである。
第1のクライアント戦略を使用して上の例を続けると、セグメント1についての情報、具体的にはその提示終了時間が利用可能になると、次のセグメントの提示開始時間、すなわち19019/30000を計算でき、これから、この次のセグメント2のTind=1かつSind=2を決定でき、そのURLは、URLテンプレート構築規則に従って構築され、セグメント2はそのURLに基づいて要求され得る。何らかの理由で、Tind=1かつSind=2に対応するセグメント2が利用可能ではないと仮定する。次いで、AHSクライアントは、セグメント3および4のURLを決定できることもできないこともあるが、AHSクライアントは、Tind=2かつSind=1であるセグメント5のURLを決定し、表示1のセグメント5と後続のセグメントとを要求し再生できる。この例では、AHSクライアントは、セグメント1を再生し、セグメント2、3、および4の再生をスキップし、次いで、セグメント5および後続のセグメントの再生へと続くことができるので、全体で(79079−10010)/30000、すなわち約2.3秒のメディアコンテンツの再生をスキップし、これは一般に、この第3のクライアント戦略を使用すると大きくとも2×Tmaxである。
上記のように、クライアントが、TimescaleSegURL=毎秒10ティックの単位で実時間T=52において、すなわち、実時間5.2秒において、第1の表示に参加することを決めると仮定する。第2の代替的なクライアント戦略は、クライアントが、実時間がTMティックの倍数となるまで、すなわち、実時間Tが3×TM/TimescaleSegURL=6.6秒に達するまで待機し、次いで上記のように進んで、M=T/TM=3を計算し、次いでTind=M−1=2かつSind=1、すなわちセグメント5に対応するURLを形成し、次いで79079/30000すなわち約2.636秒の提示開始時間を伴ってセグメント5から要求し再生を開始するというものである。この場合、再生は、クライアントが表示1からの再生を決めた時から、少なくとも6.6−5.2秒=1.4秒だけ遅れ、すなわち一般には、この第2のクライアント戦略を使用すると最大でTSmax秒遅れるが、実時間と提示開始時間とのラグは、6.6−2.636=3.964秒改善され、このラグは一般には、この第2のクライアント戦略を使用すると最大で2×TSmaxである。この場合、クライアントは、ラグが2×TSmaxと等しくなるように、再生を遅らせると決めることができ、すなわち、提示時間2.636秒で開始するコンテンツは、実時間2.636+2×2.2=7.036秒で開始するので、同じ表示のセグメントに対する後続の表示の切り替えまたは要求による、詰まりまたは休止はない。
上記の例を続けると、AHSクライアントは、実時間T=10秒で第1の表示から第2の表示に切り替えると決める。TM=30かつTimescaleSegURL=20が、第2の表示に対して規定されるものとする。TimescaleSegURLの単位のTMによって等しく分割できる次の値にTが達するとすぐに、すなわち、M=T×TimescaleSegURL/TMが整数になると、これはM=7ではT=10.5秒において起きるが、AHSクライアントは、第2の表示のセグメント10のTind=6かつSind=1に対応するURLを生成してこのセグメントを要求でき、このセグメントの提示開始時間は、230230/30000すなわち約7.674秒である。再生されているものの実時間と提示時間とのラグが、この例について前の段落で説明されたように4.4秒である場合、このセグメントの再生は、実時間の約12.0743秒で開始する。一方、AHSクライアントは、第2の表示のセグメント10の少なくとも提示開始時間まで再生できるようになるまで、第1の表示からのセグメントのダウンロードを続け、次いで、第2の表示のセグメント10の再生の開始に切り替えることができる。
上記の方法の多数の変形形態が存在する。例えば、表示のTMおよびTimescaleSegURLの値は、TM/TimescaleSegURLがその表示のセグメントの最大提示時間スパン未満となるようなものであり得る。この代替形態では、TimescaleSegURLのティック単位でTM×(M−1)とTM×Mとの間に提示開始時間を有する、表示のセグメントが存在しないような、何らかの正の整数値Mがあり得る。そのような場合、クライアントがTind=MかつSind=1に対応するセグメントのURLを形成する場合、そのURLに対応する表示のセグメントは存在しないことがある。この場合、クライアントが、HTTPを使用して、形成されたURLに基づいてセグメントを要求すると決める場合、クライアントは、「HTTP 404 file not found」エラー応答を受信することがあり、クライアントはこの応答を使用して、形成されたURLに対応するセグメントがないと解釈できる。
変形形態の別の例として、同じTindインデックスを有するセグメントに対して、セグメントのSindインデックスは、セグメントの提示開始時間が大きくなる順序ではなく、セグメントの提示開始時間が小さくなる順序で、増えていってよい。例えば、セグメント1の提示開始時間が1.1秒であり、セグメント2の提示開始時間が1.3秒であり、セグメント3の提示開始時間が2.4秒であり、これら全ての3個のセグメントが同じTind値を有する場合、セグメント3のSind値は1であってよく、セグメント2のSind値は2であってよく、セグメント1のSind値は3であってよい。
変形形態の他の例として、セグメントに関連付けられるTind値は、提示開始時間ではなくセグメントの提示終了時間に基づいてよく、または、セグメントに関連付けられるTind値は、セグメントの平均提示時間に基づいてよく、または、セグメントの中心バイト位置にあるフレームの提示時間に基づいてよい。
変形形態の別の例として、セグメントURLテンプレート構築規則は、セグメントマップURLテンプレート構築規則に、または、セグメントマップとメディアデータの組合せを含むセグメントに適用されるように、修正され得る。
時間ベースとインデックスベースの複数URLバージョンのセグメントURLテンプレートの生成
時間ベースの要素とインデックスベースの要素の両方を含むセグメントURLテンプレート構築規則はさらに、次のように強化され得る。URLテンプレート構築規則は、1つのセグメントに対して2つ以上のURLを規定するために使用されてよく、すなわち、同じセグメントは複数のURLに対応してよく、複数のURLのいずれもが、セグメントを識別するために、例えば、セグメントを要求しダウンロードするために使用され得る。
前のように、TimescaleSegURLを、表示の全てのセグメントのセグメントURLに含まれる時間ベースの情報に対する、1秒当たりのティックの数を表すために使用される時間軸とし、TindおよびSindを正の整数のインデックスとし、TMを正の整数の定数とする。すると、セグメントURLテンプレート構築規則は、次の形式となり得る。
1.Content_ID.Representation_ID.$Tind$.$Sind$
この代替形態では、場合によって、各セグメントに対して、TindおよびSindの複数の値が決定されてよく、そのセグメントに対する各(Tind,Sind)ペアは、そのセグメントのURLを定義する。セグメントに対応するURLを構築するための規則は、以後セグメントURL交差規則構築と呼ばれ、次の通りである。SPTおよびEPTを、TimescaleSegURLのティック時間軸でのセグメントの提示開始時間および提示終了時間とし、セグメントの提示終了時間は、後続のセグメントの提示開始時間である。そして、次の3つの条件のうちのいずれか1つまたは複数が満たされる場合、セグメントに割り当てられたTind=Mに対応するURLがある。
Figure 2014529970
言い換えると、[SPT,EPT]によって定義された提示時間スパンが、Tind=Mを伴うURLテンプレート構築規則によって定義される時間スパン[TM×(M−1),TM×M]との非空の交差部分を有する場合、セグメントに割り当てられたTind=Mに対応するURLがある。セグメントは、3つの条件のうちの2つ以上を満たすことがあり、例えば、SPT≦TM×(M−1)かつEPT≧TM×Mである場合、条件1と3の両方が満たされることに留意されたい。セグメントに割り当てられた各Tind=Mに対して、セグメントに割り当てられたSind値は、同じTind=Mを割り当てられている表示内におけるセグメントの順序に従ったものであり得る。従って、EPTi=SPTi+1となるように、提示開始時間および提示終了時間(SPT1,EPT1)、(SPT2,EPT2)、…、(SPTN,EPTN)に従って並べられたURL時間スパン[TM×(M−1),TM×M]との提示時間の交差を伴うN個のセグメント1、2、…、Nがある場合、Tind=Mに対するこれらN個のセグメントのSind値は、それぞれ、1、2、…、Nである。
セグメントURL交差規則構築を使用すると、セグメントに割り当てられるURLの数は、セグメントの提示時間スパンが交差する、形式[TM×(M−1),TM×M]のURL時間スパンの数である。この構築は、各々のMに対して、TM×Mが大きくとも、ティック時間軸TimescaleSegURLでの表示の提示終了時間となるような性質を有し、Tind=Mに割り当てられた少なくとも1つのセグメントがあり、従って、Tind=Mおよびそのような各Mに対するSind=1に対応するURLを伴うセグメントが常にある。
セグメントURL交差規則構築を使用すると、各セグメントは、少なくとも1つのURL時間スパンに割り当てられる。具体的には、URL時間スパン[TM×(M−1),TM×M]が、セグメントが交差する最初のURL時間スパンであり、セグメントが全体でN個のURL時間スパンと交差する場合、N個のURLがセグメントに割り当てられ、第1のURLは、何らかのI≧1に対するTind=MおよびSind=1に対応し、第2から第NのURLは、それぞれ、(Tind=M+1,Sind=1)、(Tind=M+2,Sind=1)、…、(Tind=M+N−1,Sind=1)に対応する。従って、セグメントに対応するURLの全てが、Mを最小のTind値としてURLの(Tind=M,Sind=I)の値から、かつ、セグメントに割り当てられるURLの数Nから、決定され得る。
図17は、セグメントURL交差規則構築の例を示す。URL時間スパンおよび各URL時間スパンに割り当てられた値Tind=Mは、図17の底部に沿って示され、各URL時間スパンに対して示されるTind値は、TimescaleSegURLの時間軸単位でのスパンの終わりの提示時間M×TMである。セグメントの開始点および終了点は、URL時間スパンのすぐ上に示され、垂直な線はあるセグメントの終わりと次のセグメントの始まりを示し、すなわち、垂直な線は連続するセグメントの間の境界を示す。各セグメントの開始点と終了点の間に、そのセグメントに割り当てられたURLに対応する(Tind,Sind)値のセットがリストされている。例えば、値(1,2)、(2,1)、(3,1)が、第2のセグメントに対してリストされており、これは、第2のセグメントに対応するURLが次の形式であることを示す。
Figure 2014529970
セグメントURL交差規則構築のAHSクライアントによる使用の例として、AHSクライアントが、何らかの実時間Tにおいてライブストリームからの表示の要求と再生とを開始することを決めると仮定し、Tは、表示のTimescaleSegURLティックの単位で表される。TSmaxは、TimescaleSegURLの時間軸単位でのTMの正の整数MM倍であり、すなわち、TSmax=TM×MMであると仮定する。AHSクライアントが要求し再生することを望む表示のTおよびTMに基づいて、クライアントは、M=floor(T/TM)を計算でき、floorは、その変数以下の最大の整数を出力する関数である。クライアントは、Tind=M−MM+1に対応するURL時間スパンの開始側の境界と交差する、Tind=M−MM+1かつSind=1に対応するURLを伴う、セグメントIと呼ぶセグメントを要求できる。時間Tにおいて、セグメントIは利用可能であることが保証され、それは、Tind=M−MM+1に対応するURL時間スパンの境界の始まりがTimescaleSegURLの単位で少なくともTM×MMティックだけTよりも前にあり、かつ、セグメントIの提示時間スパンがTimescaleSegURLの単位で長くともTM×MMティックであり、セグメントIの終わりがTよりも前であり、従ってセグメントIが利用可能であるからである。セグメントIの提示開始時間は、最大でもTよりも2×TSmaxティック前にあることも、立証できる。AHSクライアントは、現在の実時間Tと、セグメントIの提示開始時間との差が、例えば少なくとも2×TSmaxになると、セグメントIの再生を開始できる。
AHSクライアントがセグメントIをダウンロードすると、または、セグメントIの提示終了時間へのアクセス権を有すると、AHSクライアントは、セグメントIのすぐ後の次のセグメントI+1の提示開始時間を決定でき、AHSクライアントは、セグメントI+1がTind=M−MM+1かつSind=2を有するかどうか、または、セグメントI+1がTind=M−MM+2かつSind=1を有するかどうか、すなわち、次のセグメントの提示開始時間がTimescaleSegURLの単位でTM×(M−MM+1)未満か、それに等しいか、それより大きいかを判定できる。このように続けて、AHSクライアントは常に、表示内で現在のセグメントの後のセグメントのTindとSindとを決定でき、従って次のセグメントのURLを決定できる。
何らかの理由で、AHSクライアントが、Tind=Mであるセグメントに対する有効に形成されたURL要求に対して「not found」応答を受信し、ここでURL要求がセグメントURL交差規則構築に基づいて形成されている場合、AHSクライアントは、その欠落セグメントの後の後続のセグメントのURLを決定できないことがある。しかしながら、AHSクライアントは、利用可能なセグメントが見つかるまで、N=M+1、M+2などに対し、Tind=NかつSind=1に対応するURLを伴うセグメントに対する要求を発することができる。当然、AHSクライアントは、例えばセグメントが生成されライブで利用可能にされている場合、対応するセグメントが要求の時点で利用可能となるように、これら要求の時間を決めるべきである。従って、AHSクライアントが、例えばサーバまたはネットワーク配信のエラーにより、表示からのあるセグメントを欠いている場合、AHSクライアントは、利用可能な次に大きいTind=Nの値を伴う最初のセグメントへとスキップでき、これによって、欠落セグメントが原因の、可能な提示時間の再生の欠けの量が、TM/TimescaleSegURL秒という追加の因子のうちで最小限となる。
AHSクライアントは、次のような戦略を使用して、第1の表示から第2の表示に切り替えることができる。TMおよびTimescaleSegURLを、切り替え先となる第2の表示に対するものとし、何らかの正の整数MMに対してTSmax=TM×MMとし、Tを、切り替えの決定が行われた実時間をTimescaleSegURLのティック単位で表したものとする。TがTMによって等しく分割可能である次の値に達すると、すなわち、M=T/TMが整数になるとすぐに、AHSクライアントは、第2の表示からのセグメントIと呼ぶセグメントに対して、Tind=M−MM+1およびSind=1に対応するURLを生成し、セグメントIの提示開始時間において第2の表示に切り替えることができる。一方、AHSクライアントは、第2の表示のセグメントIの少なくとも提示開始時間まで再生できるようになるまで、第1の表示からのセグメントのダウンロードを続けて、次いで、第2の表示のセグメントIの再生に切り替えることができる。この段落で説明された方法を使用して、実時間と再生された提示時間との差が少なくとも2×TSmaxである場合、セグメントのダウンロードが要求される時と、セグメントの再生を開始するのに少なくとも十分なセグメントがAHSクライアントに到達した時との間の時間を考慮せずに、第1の表示から第2の表示への切り替えを、詰まりまたは休止を何ら伴わずに実行できる。
例として、セグメントURL交差規則構築は、当業者が認識するように、拡張ALSクライアントに対する多くの利点を伴って、既存のALSシステムに次のように適用され得る。TimescaleSegURL値は1に設定されてよく、すなわち、常に毎秒1つのティックがある。TMの値は、コンテンツの表示におけるセグメントの通知された長さから決定されてよく、例えば、セグメントの長さがコンテンツの表示に対して10秒として通知された場合、TMは、コンテンツのその表示に対しては10に設定され、セグメントの長さがコンテンツの表示に対して6秒として通知された場合、TMは、コンテンツのその表示に対しては6に設定される。セグメントURL交差規則構築を組み込む、拡張ALSクライアントおよび拡張セグメントURL生成器は、コンテンツの各表示に対して、同じTimescaleSegURL値とTM値とを使用すべきである。前に説明されたように、拡張セグメントURL生成器は、セグメントURL交差規則構築を使用して、ALSコンテンツのセグメントのURLを生成し関連付けるべきであり、一方拡張ALSクライアントは、セグメントURL交差規則構築を使用して、要求すべきセグメントのURLを決定すべきである。これら方法が既存のALSシステムに適用される場合、拡張セグメントURL生成器はまた、既存のALSクライアントが修正されずに動作し続けることができるように、既存のセグメントURLによりコンテンツのセグメントURLのリストにおいて生成され明示的に提供されるようなURLを、追加で生成し関連付けることができる。あるいは、拡張セグメントURL生成器は、セグメントURL交差規則構築を使用して、ALSコンテンツのセグメントのURLを生成し関連付け、現在のALSセグメントURLリストフォーマット内のリストにおいて、各セグメントの最初のURLを追加で提供できるので、既存のALSクライアントは、これら明示的なセグメントURLリストを使用して、修正されずに動作できる。
セグメントの少なくとも一部に割り当てられた2つ以上のURLが存在する可能性のある、セグメントURLテンプレート構築規則の多くの変形形態がある。例えば、セグメントの提示時間が増加する順序で同じTind値を有するセグメントのSind値を割り当てるのではなく、Sind値は、セグメントの提示時間の減少する順序で割り当てられてよい。
セグメントURL交差規則構造の変形形態として、規則は、EPTi=SPTi+1となるように、提示開始時間および提示終了時間(SPT1,EPT1)、(SPT2,EPT2)、…、(SPTN,EPTN)に従って並べられたURL時間スパン[TM×M,TM×(M+1)]との提示時間の交差を伴うN個のセグメント1、2、…、Nがある場合、Tind=Mに対するこれらN個のセグメントのSind値は、それぞれ、0、1、…、N−1であるというものであり得る。
セグメントURL交差規則構築の別の変形形態は、あるセグメントに割り当てられる2つ以上のURLがある場合、例えばN>1個のURLがあるセグメントに割り当てられる場合、セグメントの2つ以上のコピーが利用可能にされるというものであり得る。例えば、別個のファイルとして利用可能にされるセグメントのN個の別個のコピーが存在することがあり、各コピーは、そのコピーを参照しダウンロードするために使用されるそのコピーに割り当てられたちょうど1つのURLを有するということを除いて、他の各コピーと同一である。別の例として、セグメントの各コピーは同一ではなくてよく、すなわち、各コピーは、他の各コピーとちょうど同じ時間スパンを有し同じ表示に対するものであり得るが、異なるコピーは、異なる方法で符号化されたビデオであり得る。例えば、表示における切り替え先のセグメントとして使用され得るSind=1を有するコピーは、それらがRAPで開始するように符号化されてよく、一方、同じ表示の前のセグメントから継続するように使用されるSind>1を有するコピーは、RAPではなく、代わりに同じ表示の前のセグメントからの参照フレームであるフレームを使用して、より効率的に符号化されてよい。
別の変形形態として、2つ以上のURL構築規則が同じ表示に対して規定されてよく、例えば、Sindのインデクシングがセグメント提示時間の増加する順序であるURL時間スパンと交差するセグメント時間スパンに基づく規則、Sindのインデクシングがセグメント提示時間の減少する順序であるURL時間スパンと交差するセグメント時間スパンに基づく規則、Sindのインデクシングがセグメント提示開始時間の増加するまたは減少する順序であるURL時間スパンに含まれるセグメント提示開始時間に基づく規則、Sindのインデクシングがセグメント提示終了時間の増加するまたは減少する順序であるURL時間スパンに含まれるセグメント提示終了時間に基づく規則、同じ表示に対して異なる値のTMまたはTimescaleSegURLを伴う規則、セグメント、セグメントマップ、または、セグメントもしくはセグメントマップの組合せに対する異なる規則であり得る。
例えば、一般的なセグメントURLテンプレート構築規則は、次の形式であってよく、「Content_ID」はコンテンツを識別し、「Representation_ID」は表示を識別し、「Type」は、「SPT」、「EPT」、または「INT」のいずれかであり、「Direction」は「I」または「D」のいずれかである。
Figure 2014529970
上のデータ構造では、「Type」は規則のタイプを示し、すなわち、タイプが「SPT」である場合、規則はセグメント提示開始時間に基づき、タイプが「EPT」である場合、規則はセグメント提示終了時間に基づき、タイプが「INT」である場合、規則はセグメント交差に基づく。「Direction」はSindのインデクシングの方向を示し、「Direction」が「I」である場合、Sindのインデクシングはセグメント提示時間が増加する順序であり、「Direction」が「D」である場合、Sindのインデクシングはセグメント提示時間が減少する順序である。
一例として、URLテンプレート構築規則
Figure 2014529970
は、コンテンツおよび表示が「http://www.example.com/ahs−5−1.1.3gs」によって識別される規則を示し、「INT」は、規則が前に定義されたようなセグメント交差規則であることを示し、「I」は、Sindのインデクシングがセグメント提示時間に関して増加することを示す。TimescaleSegURL=1かつTM=20なので、この規則によって定義される各URL時間スパンは、長さが20秒である。
簡単なセグメントURLテンプレートの生成
セグメントURLは、テンプレートに従って生成されてよく、この場合、テンプレートおよび/または構築規則は、セグメント要求を行うクライアントに対してコンパクトに搬送される。これらテンプレート/規則は、簡単であってもよく複雑であってもよい。セグメントURLの生成およびURLテンプレートの生成のための簡単な処理が、例としてここで説明される。
前のセクションで説明された表記を維持し、TMは、ティックの単位で表される提示時間のパラメータであり、TimescaleSegURLは、1秒当たりのティックの数である。URLテンプレートの生成のために(および場合によって他の目的のために)、両方がティックの単位で表される提示時間のパラメータである、2つの追加のパラメータDeltaMinusおよびDeltaPlusがある。従って、URLテンプレート構築規則の例は、次のデータ構造を使用し得る。
Figure 2014529970
上のデータ構造では、Sindは、クライアントに渡される可能性があり、または他の方法でクライアントによって取得される可能性があり、Sindは、次のように解釈されるべきであるURLテンプレート構築規則に対する正の整数の変数である。Sind=iであるセグメントに対して、URL http://www.example.com/ahs−8.i.3gpを有するセグメントでは、セグメントの提示開始時間SPTは、値(TM×I−DeltaMinus)/TimescaleSegURLによって規定される時間(秒単位の)で開始し、値(TM×I+DeltaPlus)/TimescaleSegURLによって規定される時間(秒単位の)で終了する、提示時間間隔内にある。
例えば、上の例でSind=17である場合、URL http://www.example.com/ahs−8.17.3gpを有するセグメントの提示開始時間SPTは、50×17−4ティックと50×17+6ティックとの間にあり、または等価的に、提示時間84.6秒と提示時間85.6秒との間にある。従って、この例では、セグメントの開始時間は、1秒の提示時間間隔内に入り、一方、平均のセグメントの長さはおよそ、TM/TimescaleSegURL=5秒である。所望の提示開始時間から、クライアントは、計算を簡単に実行して、要求すべきセグメントを厳密に導出でき、または、そうではなくても効率的であるように十分近いセグメントを導出できる。
常にではないが通常、DeltaMinusおよびDeltaPlusはTMより小さい。しかしながら、TMよりも大きなDeltaMinusまたはDeltaPlusを許容することで利益が得られる場合がある。
上の方法の1つの利益は、ビデオ符号化処理に柔軟性を与えるということであり、すなわち、セグメントの提示開始時間に柔軟性を与えることは、いくつかの場合には各セグメントの始まりにあるSAPの提示時間に、柔軟性を与える。SAPは多くの場合IDRフレームなので、ビデオ符号化処理によって生成されるIDRフレームの提示時間に柔軟性があることで、ビデオ符号化処理は、一定の提示時間間隔において生成されたIDRフレームを伴うビデオ圧縮と比較して、同じストリームレートに対してより良好な圧縮を提供することが可能になる。
さらなる利益は、方法が、TM+DeltaMinus+DeltaPlus以下であり得るエンドツーエンドのレイテンシと、IDRフレームの位置についてのビデオ圧縮の柔軟性とのトレードオフに対する制御を提供することである。さらなる利益は、AHSクライアントが、(DeltaMinus+DeltaPlus)/TimescaleSegURL秒という設定可能な精度の範囲内で、前のまたは後のセグメントについての情報を参照することなく、大まかな提示時間の推定に基づいて、AHSクライアントの要求すべきセグメントのURLを生成することが可能になることである。
さらなる利益は、方法が、前のまたは後のセグメントまたはURLについての情報を参照することなく、セグメントに関連するURLとをサーバが生成することを可能にすることである。これは特に、冗長サーバによるライブストリーミング解決法をサポートする際に有益であることがある。セグメントとURLとを生成する第1のサーバがクラッシュし、新たな第2のサーバがオンラインとなり前のファイルサーバを置き換える場合、第2のサーバは、クラッシュした第1のサーバの状態とは無関係に、後続のセグメントとURLとを生成できる。ビデオコンテンツおよびセグメントおよび第2のサーバにより生成されるURLの断絶を短くでき、この断絶の長さは、第1のサーバがクラッシュしてから第2のサーバが第1のサーバを置き換えるまでの時間間隔に、(DeltaMinus+DeltaPlus)/TimescaleSegURLに比例する時間間隔を足したものに関連する。
上の方法の1つの変形形態では、所定の時間間隔内に入るというセグメントの提示開始時間に対する制約は、セグメントの始まりにあるSAPを伴うセグメントにのみ適用される。上の方法の別の変形形態では、セグメントの提示開始時間に対する制約は、何らかの一定の正の整数SAP_FREQの倍数であるインデックスSindを有するセグメントのみに対して適用され、SAP_FREQの倍数であるインデックスSindを有するセグメントのみが、シグナリングされたSAP内で開始することを要求される。
本開示を読んだ当業者が認識するように、上の方法には多くの他の変形形態が存在する。例として、DeltaMinusおよびDeltaPlusの値は、各適合セットに対するMPDにおいてシグナリングされてよく、または、適合セット内の表示ごとにシグナリングされてよく、または、全ての適合セットに対して全体的にシグナリングされてよい。他の例として、DeltaMinusとDeltaPlusの値の1つまたは両方は、明示的にシグナリングされなくてよく、例えば事前に定義されたプロファイルに基づいて、所定の値に設定されてよい。例えば、事前に定義されたプロファイルに対して、DeltaMinusは0と定義されてよく、DeltaPlusはTM/2と定義されてよい。別の例として、DeltaMinusおよびDeltaPlusは、DeltaMinusおよびDeltaPlusの値がMPDにおいて明示的に与えられる場合にのみ覆される、所定のデフォルト値を有し得る。他の例として、単一のシグナリングされるパラメータDeltaしかなくてよく、DeltaMinusおよびDeltaPlusの値は両方ともDeltaに設定され、または、DeltaMinusは0に設定されDeltaPlusはDeltaに設定される。別の例として、DeltaMinusおよびDeltaPlusは、他のパラメータから導出されてよく、例えば、DeltaMinusおよびDeltaPlusの代わりにシグナリングされるFracDeltaMinusおよびFracDeltaPlusという2つのパラメータがあり、DeltaMinusはFracDeltaMinus×TMに設定され、DeltaPlusはFracDeltaPlus×TMに設定される。
ハードウェアシステムの概要
様々なプラットフォームで動作できる様々な実施形態、特徴、方法などが、上で説明された。このセクションは、上の教示と共に使用され得るいくつかの具体的なハードウェアプラットフォームを詳しく説明する。
図18において、ブロックサービング設備(「BSI」)1801を備えるブロックストリーミングシステム1800が示され、BSI1801は、コンテンツ1802を取り込み、そのコンテンツを準備し、HTTPストリーミングサーバ1804によるサービスのためにそのコンテンツをパッケージングするための取込システム1803を備え、上記のパッケージングは、取込システム1803とHTTPストリーミングサーバ1804の両方にアクセス可能なコンテンツ記憶装置1810にコンテンツを格納することによって行われる。示されるように、システム1800は、HTTPキャッシュ1806も含み得る。動作において、HTTPストリーミングクライアントのようなクライアント1808は、要求1812をHTTPストリーミングサーバ1804に送信し、HTTPストリーミングサーバ1804またはHTTPキャッシュ1806から応答1814を受信する。各場合において、図18に示される要素は、少なくとも一部、ソフトウェアで実装されてよく、そのソフトウェア内に、プロセッサまたは他の電子機器上で実行されるプログラムコードを備える。
コンテンツは、動画、オーディオ、2D平面ビデオ、3Dビデオ、他のタイプのビデオ、画像、時間指定されたテキスト、時間指定されたメタデータなどを備え得る。いくつかのコンテンツは、時間指定された方式で提示または消費されるべきデータ、例えば、再生されている他のメディアと共に補助的な情報を提示するためのデータ(通信局識別、広告、株式市況、Flash(商標)シーケンスなど)を伴い得る。他のメディアを結合し、かつ/または単なるオーディオおよびビデオを越える、他のハイブリッド提示も使用され得る。
図19に示されるように、メディアブロックは、ブロックサービング設備1801(1)内に格納されてよく、ブロックサービング設備1801(1)は例えば、HTTPサーバ、コンテンツ配信ネットワークデバイス、HTTPプロキシ、FTPプロキシまたはサーバ、または何らかの他のメディアサーバもしくはシステムであり得る。ブロックサービング設備1801(1)はネットワーク1822に接続され、ネットワーク1822は例えば、インターネットのようなインターネットプロトコル(「IP」)ネットワークであり得る。6個の機能コンポーネント、すなわち、上で説明されたメタデータを与えられ、メタデータによって示される複数の利用可能なブロックのうちから要求されるべきブロックまたは部分的なブロックを選択する機能を実行する、ブロック選択器1823と、ブロック選択器1823から要求命令を受信し、規定されたブロック、ブロックの一部、または複数のブロックに対する要求を、ネットワーク1822を通じてブロックサービング設備1801(1)に送信し、返答としてブロックを備えるデータを受信する必要のある動作を実行する、ブロック要求器1824と、さらに、ブロックバッファ1825と、バッファモニタ1826と、メディアデコーダ1827と、メディア消費を支援する1つまたは複数のメディアトランスデューサ1828とを有する、ブロック要求ストリーミングシステムクライアントが示される。
ブロック要求器1824によって受信されるブロックデータは、メディアデータを格納するブロックバッファ1825に、一時的な格納のために渡される。あるいは、受信されたブロックデータは、図18に示されるように、ブロックバッファ1825に直接格納され得る。メディアデコーダ1827は、ブロックバッファ1825によってメディアデータを与えられ、メディアトランスデューサ1828に適切な入力を提供するのに必要な変換をこのデータに対して実行し、メディアトランスデューサ1828は、メディアを、ユーザまたは他の消費に対して適した形式にする。メディアトランスデューサの例は、携帯電話、コンピュータシステム、またはテレビジョンにおいて見出されるような視覚ディスプレイデバイスを含み、スピーカまたはヘッドフォンのようなオーディオレンダリングデバイスも含み得る。
メディアデコーダの例は、H.264ビデオコーディング規格で表されたフォーマットのデータを、ビデオフレームのアナログまたはデジタルの表現、例えば、各フレームまたはサンプルに対する関連する提示タイムスタンプを伴うYUVフォーマットのピクセルマップへと変換する、関数である。
バッファモニタ1826は、ブロックバッファ1825のコンテンツに関する情報を受信し、この情報および場合によって他の情報に基づいて、ブロック選択器1823に対する入力を提供し、ブロック選択器1823は、本明細書で説明されるように、要求すべきブロックの選択を決定するために使用される。
本明細書で使用される用語法では、各ブロックは、そのブロックに含まれるメディアを受信機が通常の速度で再生するのにかかる時間を表す、「再生時間(playout time)」または「長さ(duration)」を有する。いくつかの場合には、ブロック内のメディアの再生は、前のブロックからのデータを既に受信していることに依存し得る。まれに、ブロック内のメディアの一部の再生は、後続のブロックに依存することがあり、この場合、ブロックの再生時間は、後続のブロックを参照せずにブロック内で再生され得るメディアに関して定義され、後続のブロックの再生時間は、後続のブロックを受信した後にのみ再生できるこのブロック内のメディアの再生時間の分、増加する。後続のブロックに依存するメディアをブロック内に含むことはまれであるので、本開示の残りでは、あるブロック内のメディアは後続のブロックに依存しないと仮定するが、この変形形態は以下で説明される実施形態に容易に追加され得ることを当業者は認識するであろうことに、留意されたい。
受信機は、ブロックを異なるレートの再生により消費させ得る、「一時停止(pause)」、「早送り(fast forward)」、「巻き戻し(fast forward)」などのような制御機能を有し得るが、受信機が、シーケンスにおける最後のブロックを除く総再生時間以下の、全体の時間のうちの各々の連続するブロックのシーケンスを取得し復号できれば、受信機は、ストールすることなくメディアをユーザに提示できる。本明細書の説明の一部では、メディアストリームにおける特定の位置は、メディアにおける特定の「時間(time)」と呼ばれ、これは、メディア再生の始まりと、ビデオストリームのその特定の位置に達した時間との間で経過した時間に対応する。メディアストリームにおける時間または位置は、従来からある概念である。例えば、ビデオストリームが毎秒24フレームを備える場合、最初のフレームはt=0.0秒の位置あるいは時間を有すると言うことができ、241番目のフレームは、t=10.0秒の位置あるいは時間を有すると言うことができる。当然、フレームに基づくビデオストリームにおいて、位置または時間は連続的である必要はなく、それは、241番目のフレームの最初のビットから242番目のフレームの最初のビットのすぐ前までのストリームにおけるビットの各々は、全て同じ時間の値を有し得るからである。
上記の用語法を採用すると、ブロック要求ストリーミングシステム(BRSS)は、1つまたは複数のコンテンツサーバ(例えば、HTTPサーバ、FTPサーバなど)に対して要求を行う1つまたは複数のクライアントを備える。取込システムは、1つまたは複数の取込プロセッサを備え、取込プロセッサは、コンテンツを受信し(リアルタイムで、または非リアルタイムで)、BRSSによる使用のためにコンテンツを処理し、場合によって取込プロセッサによって生成されたメタデータと共に、コンテンツサーバがアクセス可能な記憶装置へとコンテンツを格納する。
BRSSはまた、コンテンツサーバと協調するコンテンツキャッシュを含み得る。コンテンツサーバおよびコンテンツキャッシュは、HTTP要求の形式で、ファイルまたはセグメントに対する要求を受信する、従来のHTTPサーバおよびHTTPキャッシュであってよく、HTTP要求は、URLを含み、URLによって示されるファイルまたはセグメントの全てよりも少ないファイルまたはセグメントを要求するために、あるバイト範囲も含み得る。クライアントは、HTTPサーバの要求を行いそれらの要求に対する応答を処理する、従来のHTTPクライアントを含んでよく、HTTPクライアントは、新規のクライアントシステムによって駆動され、新規のクライアントシステムは、要求を編成し、要求をHTTPクライアントに渡し、HTTPクライアントから応答を得て、クライアントデバイスによる再生のために提示プレーヤに要求を提供するために要求を処理(または格納、変換など)する。通常、クライアントシステムは、どのメディアが必要とされるであろうかを前もって知らず(需要は、ユーザの入力、ユーザの入力の変化などに依存し得るので)、よって、メディアが受信されるとすぐに、またはメディアが受信されてからまもなく、メディアが「消費される」という点で、クライアントシステムは「ストリーミング」システムであると言われる。その結果、応答の遅延および帯域幅の制約は、提示の遅延を引き起こすことがあり、例えば、ユーザが提示を消費している箇所にストリームが追いつくと、提示の停止が発生する。
良好な品質であると知覚される提示を提供するために、BRSSにおいて、クライアント側で、取り込み側で、またはこれら両方のいずれかで、多数の項目が実装され得る。いくつかの場合には、実装される項目は、ネットワークにおけるクライアントとサーバのインターフェースを考慮して、かつそれを扱うように行われる。いくつかの実施形態では、クライアントシステムと取込システムの両方が拡張を認識し、一方他の実施形態では、一方の側のみが拡張を認識する。そのような場合、一方が拡張を認識しない場合でも、システム全体は拡張による利益を受け、他の場合には、両方が拡張を認識する場合にのみ利益は発生するが、一方が認識しなくても、障害を起こすことなく動作する。
図20に示されるように、取込システムは、様々な実施形態によれば、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。取込システムは、本明細書で論じられる方法の任意の1つまたは複数をシステムに実行させるように実行され得る、命令のセットを備え得る。システムは、コンピュータの形式の特定の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ(PC)、または、そのシステムによってとられるべき動作を規定する(順次的なまたは他の方式の)命令のセットを実行することが可能な任意のシステムであってよい。さらに、単一のシステムのみが示されるが、「システム」という用語はまた、命令のセット(または複数のセット)を個々にまたは一緒に実行して、本明細書で論じられる方法の任意の1つまたは複数を実行する、システムの任意の集合体を含むものと解釈されるべきである。
取込システムは、取込プロセッサ2002(例えば、中央処理装置(CPU))と、実行の間プログラムコードを格納し得るメモリ2004と、ディスク記憶装置2006とを含んでよく、これら全てが、バス2000を介して互いに通信する。システムはさらに、ビデオディスプレイユニット2008(例えば、液晶ディスプレイ(LCD)または陰極線管(CRT))を含み得る。システムはまた、英数字入力デバイス2010(例えば、キーボード)と、コンテンツソースを受信しコンテンツ記憶装置を送達するためのネットワークインターフェースデバイス2012とを含み得る。
ディスク記憶装置ユニット2006は、本明細書で説明される方法または機能の任意の1つまたは複数を具現化する命令(例えば、ソフトウェア)の1つまたは複数のセットが格納され得る、機械可読媒体を含み得る。命令はまた、システムによる命令の実行の間、完全に、または少なくとも部分的に、メモリ2004および/または取込プロセッサ2002内に存在してよく、メモリ2004および取込プロセッサ2002も、機械可読媒体を構成する。
図21に示されるように、クライアントシステムは、様々な実施形態によれば、ハードウェアコンポーネントとソフトウェアコンポーネントの組合せとして実装され得る。クライアントシステムは、本明細書で論じられる方法の任意の1つまたは複数をシステムに実行させるように実行され得る、命令のセットを備え得る。システムは、コンピュータの形式の特定の機械として実現され得る。システムは、サーバコンピュータ、パーソナルコンピュータ(PC)、または、そのシステムによってとられるべき動作を規定する(順次的なまたは他の方式の)命令のセットを実行することが可能な任意のシステムであってよい。さらに、単一のシステムのみが示されるが、「システム」という用語はまた、命令のセット(または複数のセット)を個々にまたは一緒に実行して、本明細書で論じられる方法の任意の1つまたは複数を実行する、システムの任意の集合体を含むものと解釈されるべきである。
クライアントシステムは、クライアントプロセッサ2102(例えば、中央処理装置(CPU))と、実行の間プログラムコードを格納し得るメモリ2104と、ディスク記憶装置2106とを含んでよく、これら全てが、バス2100を介して互いに通信する。システムはさらに、ビデオディスプレイユニット2108(例えば、液晶ディスプレイ(LCD)または陰極線管(CRT))を含み得る。システムはまた、英数字入力デバイス2110(例えば、キーボード)と、要求を送信し応答を受信するためのネットワークインターフェースデバイス2112とを含み得る。
ディスク記憶装置ユニット2106は、本明細書で説明される方法または機能の任意の1つまたは複数を具現化する命令(例えば、ソフトウェア)の1つまたは複数のセットが格納され得る、機械可読媒体を含み得る。命令はまた、システムによる命令の実行の間、完全に、または少なくとも部分的に、メモリ2104および/またはクライアントプロセッサ2102内に存在してよく、メモリ2104およびクライアントプロセッサ2102も、機械可読媒体を構成する。
高度な方法の概要
次のセクションでは、改善されたブロック要求ストリーミングシステムのための方法が説明される。これら改善の一部は、適用形態における必要性に応じて、これら改善のうちの他のものと共に、またはそれらを伴わずに使用され得ることを理解されたい。一般的な動作では、受信機は、データの特定のブロックまたはブロックの部分に対する、サーバまたは他の送信機への要求を行う。セグメントとも呼ばれるファイルは、複数のブロックを含んでよく、メディア提示の1つの表示に関連付けられる。
好ましくは、再生時間または復号時間から、セグメント内の対応するブロックまたはフラグメントのバイトオフセットへのマッピングを提供する、「セグメントインデクシング(segment indexing)」または「セグメントマップ(segment map)」とも呼ばれるインデックス情報が生成される。このセグメントインデクシングは、セグメント内に、通常はセグメントの始めに含まれることがあり(セグメントマップの少なくとも一部は始めにある)、小さいことが多い。セグメントインデックスはまた、別個のインデックスセグメントまたはファイルにおいて提供されることがある。セグメントインデックスがセグメント内に含まれる場合は特に、受信機は、このセグメントマップの一部または全てを高速にダウンロードし、続いてこれを使用して、時間オフセットと、ファイル内でのその時間オフセットに関連付けられるフラグメントの対応するバイト位置とのマッピングを決定できる。
受信機は、バイトオフセットを使用して、関心のある時間オフセットに関連付けられない他のフラグメントに関連付けられるデータの全てをダウンロードする必要なく、特定の時間オフセットに関連付けられるフラグメントからのデータを要求できる。このようにして、セグメントマップまたはセグメントインデクシングは、関心のある現在の時間オフセットに関連するセグメントの部分に直接アクセスするための受信機の能力を大きく向上させることができ、コンテンツザッピング時間が改善することと、ネットワーク条件が変化するに従ってある表示から別の表示へ高速に変更できることと、受信機で再生されないメディアをダウンロードすることでネットワークリソースを無駄にすることが減ることとを含む利益を伴う。
ある表示(本明細書では「切り替え前の(switch-from)」表示と呼ばれる)から別の表示(本明細書では「切り替え先の(switch-to)」表示と呼ばれる)への切り替えを考える場合、セグメントインデックスはまた、切り替え先の表示におけるランダムアクセスポイントの開始時間を識別し、切り替え前の表示において要求されることになるデータの量を識別し、切り替え先の表示の再生がランダムアクセスポイントからシームレスに開始できるように切り替え前の表示におけるメディアが提示時間までダウンロードされるという意味で、シームレスな切り替えが可能になることを確実にするために、使用され得る。
それらのブロックは、受信機のユーザに対する出力を生成するために要求側の受信機が必要とする、ビデオメディアまたは他のメディアのセグメントを表す。メディアの受信機は、例えば受信機がコンテンツを送信するサーバからコンテンツを受信する場合、クライアントデバイスであってよい。例には、セットトップボックス、コンピュータ、ゲームコンソール、特別に装備されたテレビジョン、ハンドヘルドデバイス、特別に装備された携帯電話、または他のクライアント受信機がある。
多くの高度なバッファ管理方法が本明細書で説明される。例えば、バッファ管理方法は、時間内に受信され得る最高のメディア品質のブロックが連続して再生されるように、クライアントが要求することを可能にする。可変ブロックサイズ機構が、圧縮の効率を改善する。要求するデバイスにブロックを送信しつつ要求の頻度を制限するための複数の接続を得る能力が改善された送信性能を提供する。部分的に受信されたブロックのデータが、メディア提示を継続するために使用され得る。接続は、ブロックの特定のセットへの接続を最初から約束する必要なく、複数のブロックに対して再使用され得る。複数のクライアントによる複数の可能性のあるサーバのうちからのサーバの選択の一貫性が改善され、これによって、近くのサーバにおけるコンテンツの重複の頻度が下がり、サーバがファイル全体を含む確率が上がる。クライアントは、メディアブロックを含むファイルのURLに埋め込まれるメタデータ(利用可能なメディア符号化物など)に基づいて、メディアブロックを要求できる。システムは、今後メディア再生の停止を引き起こすことなくコンテンツの再生が開始できるようになるまでに必要なバッファリング時間を計算し、それを最小化できる。利用可能な帯域幅は、複数のメディアブロックの間で共有されてよく、各ブロックの再生時間が近づくと調整されてよいので、必要であれば、利用可能な帯域幅のうちより大きな割合が、最も近い再生時間を有するブロックに割り当てられ得る。
HTTPストリーミングは、メタデータを利用し得る。提示レベルメタデータは、例えば、ストリームの長さ、利用可能な符号化(ビットレート、コーデック、空間解像度、フレームレート、言語、メディアタイプ)、各符号化物のためのストリームメタデータに対するポインタ、および、コンテンツ保護(デジタル著作権管理(DRM)情報)を含む。ストリームメタデータは、セグメントファイルに対するURLであり得る。
セグメントメタデータは、セグメント内の要求に対するバイト範囲対時間の情報と、ランダムアクセスポイント(RAP)または他の探索点の識別情報とを含んでよく、この情報の一部または全てが、セグメントインデクシングまたはセグメントマップの一部であり得る。
ストリームは、同じコンテンツの複数の符号化物を備え得る。各符号化物は次いで、セグメントへと分割されてよく、各セグメントは、記憶単位またはファイルに対応する。HTTPの場合、セグメントは通常、URLによって参照され得るリソースであり、そのようなURLの要求は、要求応答メッセージのエンティティ本体として、セグメントの返信をもたらす。セグメントは、複数のピクチャのグループ(GoP)を備え得る。各GoPはさらに、複数のフラグメントを備えてよく、セグメントインデクシングは、各フラグメントの時間/バイトオフセット情報を提供し、すなわち、インデクシングの単位はフラグメントである。
フラグメントまたはフラグメントの部分は、スループットを向上させるために、並列TCP接続を通じて要求され得る。このことは、ボトルネックリンク上の接続を共有する時、または、混雑により接続が失われた時に発生する問題を軽減できるので、全体の配信の速度と信頼性とを高め、コンテンツザッピング時間の速度と信頼性とをかなり高めることができる。帯域幅は、過剰な要求によるレイテンシと引き換えであり得るが、帯域幅窮乏のリスクを高め得る、遠すぎる未来に対する要求の実行を避けるように、留意しなければならない。
同じサーバ上でのセグメントに対する複数の要求は、反復的なTCP始動遅延を避けるために、パイプライン化され得る(現在の要求が完了する前に次の要求を行う)。連続するフラグメントに対する要求は、1つの要求に統合され得る。
一部のCDNは、大きなファイルを好み、範囲要求を最初に見た時に、元のサーバからのファイル全体のバックグラウンドフェッチをトリガし得る。しかしながら、大半のCDNは、データが利用可能である場合に、キャッシュからの範囲要求に応対する。従って、クライアント要求の一部分をセグメントファイル全体に対するものとすることが、有利であり得る。これら要求は、必要であれば後で取り消され得る。
有効な切替点は、目標のストリームにおける探索点、具体的には例えばRAPであり得る。複数のストリームにわたる一定のGoP構造またはRAPの整列(メディアの始まりに基づく、またはGoPに基づく)のような、異なる実装形態が可能である。
一実施形態では、セグメントおよびGoPは、異なるレートのストリームにわたって揃えられ得る。この実施形態では、GoPは、可変のサイズであってよく、複数のフラグメントを含んでよいが、フラグメントは、異なるレートのストリームの間で揃えられない。
いくつかの実施形態では、ファイル冗長性が、利益を得るために利用され得る。これら実施形態では、データの冗長なバージョンを生成するために、消去コードが各フラグメントに適用される。好ましくは、ソースのフォーマットは、FECの使用により変化せず、例えば、元の表示の従属する表示として、FEC修復データを含む追加の修復セグメントが、取込システムにおいて追加のステップとして生成され利用可能にされる。そのフラグメントのソースデータのみを使用してフラグメントを再構築することが可能なクライアントは、セグメント内のフラグメントのソースデータのみを、サーバから要求できる。サーバが利用不可能である場合、またはサーバに対する接続が遅い場合、これはソースデータに対する要求の前または後のいずれかで判定され得るが、追加の修復データが、修復セグメントからのフラグメントに対して要求されてよく、これは、フラグメントを復元するのに十分なデータを信頼性をもって送達するための時間を短縮し、場合によってFECの復号を使用して、受信されたソースと修復データの組合せを使用しフラグメントのソースデータを回復する。さらに、フラグメントが差し迫ると、すなわち、その再生時間が差し迫ると、フラグメントの復元を可能にするための追加の修復データが要求されてよく、これは、リンク上でのそのフラグメントのためのデータの割合を高めるが、帯域幅を空けるためにリンク上の他の接続を切断するよりも効率的である。これはまた、並列接続の使用による窮乏のリスクを軽減し得る。
フラグメントフォーマットは、リアルタイム転送制御プロトコルRTCPを通じて達成されたオーディオ/ビデオの同期を伴う、リアルタイム転送プロトコル(RTP)パケットの格納ストリームであり得る。
セグメントフォーマットはまた、MPEG−2TS内部タイミングにより達成されたオーディオ/ビデオの同期を伴う、MPEG−2TSパケットの格納ストリームであり得る。
1.ストリーミングをより効率的にするためのシグナリングおよび/またはブロック作成の使用
改善された性能を提供するために、ブロック要求ストリーミングシステムにおいて、多数の特徴が使用されてもされなくてもよい。性能は、ストールすることなく提示を再生し、帯域幅の制約の範囲内でメディアデータを取得し、かつ/または、クライアント、サーバ、および/もしくは取込システムにおける限られたプロセッサリソースの範囲内でそのようにすることの、能力に関連し得る。これら特徴の一部が、ここで説明される。
2.セグメント内でのインデクシング
動画フラグメントに対するpartial GET requestを編成するために、クライアントは、ファイルまたはセグメント内のフラグメントに含まれる全てのメディアコンポーネントの復号時間または提示時間内の、バイトオフセットおよび開始時間を知らされてよく、また、どのフラグメントがランダムアクセスポイントを開始し含むか(かつ、従ってどのフラグメントが代替的な表示の切替点として使用されるのに適しているか)を知らされてよく、この情報は、セグメントインデクシングまたはセグメントマップと呼ばれることが多い。復号時間または提示時間内の開始時間は、直接表されてよく、または、基準時間に対する差分として表されてよい。
この時間およびバイトオフセットのインデクシング情報は、動画フラグメント当たり少なくとも8バイトのデータを必要とし得る。例として、500msの動画フラグメントを伴う、単一のファイル内に含まれる2時間の動画では、これは全体で約112キロバイトのデータとなる。提示を開始する時にこのデータの全てをダウンロードすることは、大きな追加の始動遅延をもたらし得る。しかしながら、クライアントが、開始を望む提示の時点に関連する時間およびオフセットのデータの小さなかたまりを迅速に発見できるように、時間およびバイトオフセットのデータは、階層的に符号化され得る。この情報はまた、セグメントインデックスの何らかの改良版がメディアデータと交互になるように配置され得るように、セグメント内で分布していてよい。
各セグメントに対する完全な時間およびオフセットのデータは、既に非常に小さいことがあるので、表示が時間方向に複数のセグメントへとセグメント化される場合、この階層的なコーディングの使用は必要ではないことがあることに留意されたい。例えば、上の例でセグメントが2時間ではなく1分である場合、時間とバイトオフセットのインデクシング情報は、1キロバイト前後のデータであり、これは通常、単一のTCP/IPパケット内に収まり得る。
3.フラグメントの時間およびバイトオフセットのデータを3GPPファイルに追加するために、異なる選択肢が可能である。
第1に、Movie Fragment Random Access Box(「MFRA」)が、この目的で使用され得る。MFRAは、動画フラグメントを使用するファイルにおいてランダムアクセスポイントを見つける際に読者を支援し得る、表を提供する。この機能を支援するために、MFRAは、ランダムアクセスポイントを含むMFRAボックスのバイトオフセットを付随して含む。MFRAは、ファイルの終わりにおいて、またはその近くに配置され得るが、そうであるとは限らない。Movie Fragment Random Access Offset Boxに対するファイルの終わりからスキャンし、その中のサイズ情報を使用することによって、Movie Fragment Random Access Boxの始まりを見つけることが可能になり得る。しかしながら、HTTPストリーミングの終わりにMFRAを配置すると、通常、所望のデータにアクセスするために、少なくとも1つはファイルの終わりからのMFRAを要求するための要求、1つはMFRAを取得するための要求、そして最後の1つはファイルにおける所望のフラグメントを取得するための要求という、少なくとも3〜4個のHTTP要求が必要となる。従って、始めに配置することが、MFRAを単一の要求で第1のメディアデータと共にダウンロードできるので、望ましいことがある。また、HTTPストリーミングに対してMFRAを使用することは非効率であることがあり、それは、時間およびmoof_offset以外の「MFRA」内の情報のいずれもが必要とされず、長さの代わりにオフセットを規定することはより多くのビットを必要とし得るからである。
第2に、Item Location Box(「ILOC」)が使用され得る。「ILOC」は、メタデータリソースを含むファイルと、そのファイル内でのメタデータリソースのオフセットと、メタデータリソースの長さとを特定することによって、このファイルまたは他のファイルにおけるメタデータリソースのディレクトリを与える。例えば、システムは、全ての外部から参照されたメタデータリソースを1つのファイルに統合でき、それに従って、ファイルのオフセットとファイルの参照とを再調整する。しかしながら、「ILOC」は、メタデータの位置を与えることが意図されているので、実際のメタデータと共存するのは難しいことがある。
最後は、最も適切である可能性があるが、Time Index Box(「TIDX」)と呼ばれる新たなボックスを規定することであり、TIDXは、正確なフラグメントの時間または長さとバイトオフセットとを効率的に与えるための専用のボックスである。これは、次のセクションでより詳しく説明される。同じ機能を有する代替的なボックスは、Segment Index Box(「SIDX」)であり得る。本明細書では、別段示されない限り、これら2つは交換可能であってよく、それは、両方のボックスが、正確なフラグメントの時間または長さとバイトオフセットとを効率的に与える能力を提供するからである。TIDXとSIDXとの差が、以下で与えられる。両方のボックスがセグメントインデックスを実装するので、TIDXボックスとSIDXボックスをどのように置き換えるべきかは明らかであろう。
4.セグメントインデクシング
セグメントは、識別された開始時間と識別された数のバイトとを有する。複数のフラグメントが単一のセグメントへと連結されてよく、クライアントは、要求されたフラグメントまたはフラグメントのサブセットに対応するセグメント内の特定のバイト範囲を識別する要求を発し得る。例えば、HTTPが要求プロトコルとして使用される場合、HTTP Rangeヘッダがこの目的で使用され得る。この手法は、クライアントが、異なるフラグメントのセグメント内での位置を規定するセグメントの「セグメントインデックス(segment index)」に対するアクセス権を有することを必要とする。この「セグメントインデックス」は、メタデータの一部として与えられ得る。この手法は、全てのブロックが別個のファイル内に保存されている手法と比較して、作成され管理される必要のあるファイルがはるかに少ないという結果をもたらす。非常に多数(例えば、1時間の提示では何千何万にも及び得る)のファイルの作成、転送、および格納の管理は、複雑でエラーを生みやすいことがあるので、ファイルの数を減らすことが利益となる。
クライアントが、セグメントのより小さな部分の所望の開始時間のみを知っている場合、クライアントはファイル全体を要求し、ファイル全体を読み取って適切な再生開始位置を決定し得る。帯域幅の使用率を改善するために、セグメントは、メタデータとしてインデックスファイルを含んでよく、インデックスファイルは、個々のブロックのバイト範囲をブロックが対応する時間範囲へとマッピングし、これはセグメントインデクシングまたはセグメントマップと呼ばれる。このメタデータは、XMLデータとしてフォーマットされてよく、または、例えば3GPPファイルフォーマットのatom and box構造に従う、バイナリであってよい。インデクシングは簡単であってよく、各ブロックの時間範囲およびバイト範囲は、ファイルの始まりに対する絶対値であり、または、時間範囲およびバイト範囲は階層的であってよく、この場合、いくつかのブロックが親ブロックへとグループ化され(そして親ブロックは親の親ブロックへとグループ化される、など)、所与のブロックの時間範囲およびバイト範囲は、ブロックの親ブロックの時間範囲および/またはバイト範囲に対して表される。
5.例示的なインデクシングマップ構造
一実施形態では、メディアストリームの1つの表示に対する元のソースデータは、本明細書では「メディアセグメント(media segment)」と呼ばれる1つまたは複数のメディアファイルに含まれてよく、各メディアセグメントは、メディアの連続的な時間セグメントを再生するために使用されるメディアデータ、例えば5分のメディア再生のためのメディアデータを含む。
図22は、メディアセグメントの例示的な全体の構造を示す。各セグメント内で、ソースセグメントの始めにおいて、またはソースセグメント全体に広がって、時間/バイトオフセットセグメントマップを備えるインデクシング情報も存在し得る。一実施形態における時間/バイトオフセットセグメントマップは、時間/バイトオフセットのペア(T(0),B(0))、(T(1),B(1))、…、(T(i),B(i))、…、(T(n),B(n))というリストであってよく、T(i−1)は、全てのメディアセグメントのうちでメディアの最初の開始時間に対する、メディアのi番目のフラグメントの再生のためのセグメント内の開始時間を表し、T(i)は、i番目のフラグメントの終了時間(かつ、従って、次のフラグメントの開始時間)を表し、バイトオフセットB(i−1)は、ソースセグメントの始まりに対する、メディアのi番目のフラグメントが開始するこのソースセグメント内のデータの始まりの対応するバイトインデックスであり、B(i)は、i番目のフラグメントの対応する終了バイトインデックス(かつ、従って、次のセグメントの最初のバイトのインデックス)である。セグメントが複数のメディアコンポーネントを含む場合、T(i)およびB(i)は、絶対的な方法でセグメント内の各コンポーネントに対して与えられてよく、または、基準メディアコンポーネントとして機能する別のメディアコンポーネントに対して表されてよい。
この実施形態では、ソースセグメント内のフラグメントの数はnであり、nはセグメントによって異なり得る。
別の実施形態では、各フラグメントのセグメントインデックスにおける時間オフセットは、最初のフラグメントの絶対的な開始時間と、各フラグメントの長さとによって決定され得る。この場合、セグメントインデックスは、最初のフラグメントの開始時間と、セグメントに含まれる全てのセグメントの長さとを記録し得る。セグメントインデックスはまた、フラグメントのサブセットのみを記録してよい。その場合、セグメントインデックスは、それを含むセグメントの終わりで終了するか、次のサブセグメントの始まりで終了するかのいずれかである、1つまたは複数の連続するフラグメントとして定義されるサブセグメントの長さを記録する。
各フラグメントに対して、探索点、すなわち、その点より後のメディアがその点よりも前の任意のメディアに依存しない点で、フラグメントが開始するかどうか、または探索点をフラグメントが含むかどうかを示す値も存在し得るので、そのフラグメントから先のメディアは、前のフラグメントとは無関係に再生され得る。一般に、探索点は、再生が全ての以前のメディアとは無関係に開始できる、メディア内の点である。図22はまた、ソースセグメントのための可能なセグメントインデクシングの簡単な例を示す。その例では、時間オフセットの値はミリ秒の単位であるので、このソースセグメントの第1のフラグメントは、メディアの始まりから20秒で開始し、第1のフラグメントは485ミリ秒の再生時間を有する。第1のフラグメントの始まりのバイトオフセットは0であり、第1のフラグメントの終わり/第2のフラグメントの始まりのバイトオフセットは50245であるので、第1のフラグメントのサイズは50245バイトである。フラグメントまたはサブセグメントがランダムアクセスポイントと共に開始しないが、ランダムアクセスポイントがフラグメントまたはサブセグメントに含まれる場合、開始時間と実際のRAP時間との間の復号時間または提示時間の差が、与えられ得る。これによって、このメディアセグメントへ切り替える場合に、表示からの切り替えが提示されなければならなくなるまでの時間を、クライアントが正確に知ることができる。
簡単な、または階層的なインデクシングに加えて、またはそれらの代わりに、デイジーチェーンインデクシングおよび/またはハイブリッドインデクシングが使用され得る。
異なるトラックに対するサンプルの長さは同じではないことがあるので(例えば、ビデオサンプルは33ms表示され得るが、一方オーディオサンプルは80ms続き得る)、動画フラグメント内の異なるトラックは、厳密には同時に開始および終了しないことがあり、すなわち、オーディオはビデオよりもわずかに前またはわずかに後に開始することがあり、これに対応して、反対のことが先行するフラグメントに成り立つ。曖昧さをなくすために、時間およびバイトオフセットのデータにおいて規定されるタイムスタンプは、特定のトラックに対して規定されてよく、この特定のトラックは、各表示に対して同じトラックであってよい。通常、これはビデオトラックである。これによって、クライアントは、表示を切り替えている時に次のビデオフレームを厳密に識別することが可能になる。
提示の間、トラックの時間軸と提示時間との間の厳密な関係を維持して、上記の問題にもかかわらず円滑な再生とオーディオ/ビデオの同期の維持とを確実にするように、注意が払われなければならない。
セグメントマップを含むボックスの2つの具体的な例が以下で与えられ、1つはtime index box(「TIDX」)と呼ばれ、1つは(「SIDX」)と呼ばれる。定義は、ISOベースのメディアファイルフォーマットによるボックス構造に従う。同様のシンタックスを定義するための、同じ意味と機能とを伴うそのようなボックスの他の設計が、読者に明らかとなるであろう。
6.Time Index BOX
定義
ボックスタイプ:「tidx」
コンテナ:ファイル
必須性:いいえ
量:0または1のいずれかの数
Time Index Boxは、ファイルのある領域を提示のある時間間隔に関連付ける、時間とバイトオフセットのインデックスのセットを提供できる。Time Index Boxは、targettypeフィールドを含んでよく、これは、参照されるデータのタイプを示す。例えば、targettype「moof」を伴うTime Index Boxは、時間とバイトオフセットの両方に関してファイルに含まれるメディアフラグメントに対するインデックスを提供する。Time Index Boxのtargettypeを伴うTime Index Boxは、階層的な時間インデックスを構築するために使用されてよく、ファイルのユーザがインデックスの必要な部分を高速に見進めることを可能にする。
セグメントインデックスは、例えば、次のシンタックスを含み得る。
Figure 2014529970
意味
targettype:このTime Index Boxによって参照されるボックスデータのタイプである。これは、Movie Fragment Header(「moof」)またはTime Index Box(「tidx」)のいずれかであり得る。
time−reference_track_id:このインデックスにおける時間オフセットが規定される対象のトラックを示す。
number_of_elements:このTime Index Boxによってインデックスを付与される要素の数。
first_element_offset:最初にインデックスを付与された要素の、ファイルの始まりからのバイトオフセット。
first_element_time:time_reference_track_idによって識別されるトラックのMedia Headerボックスにおいて規定される時間軸を使用した、最初にインデックスを付与された要素の開始時間。
random_access_flag:要素の開始時間がランダムアクセスポイントであれば1である。そうでなければ0である。
length:インデックスを付与された要素のバイト単位での長さ。
deltaT:この要素の開始時間と次の要素の開始時間との間の、time_reference_track_idによって識別されたトラックのMedia Headerボックスにおいて規定される時間軸による差。
7.Segment Index Box
Segment Index Box(「sidx」)は、動画フラグメントの小型のインデックスと、セグメント内の他のSegment Index Boxとを提供する。Segment Index Boxには2つのループ構造がある。第1のループは、サブセグメントの最初のサンプル、すなわち、第2のループによって参照される最初の動画フラグメント内のサンプルを記録する。第2のループは、サブセグメントのインデックスを提供する。「sidx」ボックスのコンテナは、ファイル、または直接的にセグメントである。シンタックスは次の通りであり得る。
Figure 2014529970
意味:
reference_track_IDは、参照トラックのtrack_IDを与える。
track_count:次のループにおいてインデックスを付与されるトラックの数(1またはそれ以上)。
reference_count:第2のループにおいてインデックスを付与される要素の数(1またはそれ以上)。
track_ID:このインデックスによって識別される最初の動画フラグメントにトラックフラグメントが含まれる、トラックのID。このループにおけるちょうど1つのtrack_IDは、reference_track_IDに等しい。
decoding_time:第2のループにおける最初の項目によって参照される動画フラグメントにおけるtrack_IDによって識別されるトラック内の、最初のサンプルの復号時間であり、(トラックのMedia Header Boxのtimescaleフィールドにおいて記録されるような)トラックの時間軸で表される。
reference_type:0に設定される場合、movie fragment(「moof」)boxが参照されることを示し、1に設定される場合、segment index(「sidx」)boxが参照されることを示す。
reference_offset:これを含むSegment Index Boxの次の最初のバイトから、参照されるボックスの最初のバイトまでの、バイト単位での距離。
subsegment_duration:Segment Index Boxが参照される場合、このフィールドは、そのボックスの第2のループにおけるsubsegment_durationフィールドの合計を有し、動画フラグメントが参照される場合、このフィールドは、示される動画フラグメントと、ループにおける次のエントリにより記録される最初の動画フラグメントおよびサブセグメントの終わりのうちの早い方までの後続の動画フラグメントとにおける、参照トラック内のサンプルのサンプル長さの合計を有し、長さは、(トラックのMedia Header Boxのtimescaleフィールド内に記録されるような)トラックの時間軸で表される。
contains_RAP:動画フラグメントが参照される場合、reference_track_IDに等しいtrack_IDを有するトラックに対する、その動画フラグメント内のトラックフラグメントが、少なくとも1つのランダムアクセスポイントを含めば、このビットは1であってよく、それ以外の場合、このビットは0に設定される。セグメントインデックスが参照される場合、そのセグメントインデックスにおける参照のいずれもが1に設定されたこのビットを有する時のみ、このビットは1に設定され、それ以外の場合は0である。
RAP_delta_time:contains_RAPが1である場合、ランダムアクセスポイント(RAP)の提示(合成)時間を与える。contains_RAPが0である場合、値0を用意される。時間は、reference_track_IDに等しいtrack_IDを有するトラックにおける、このエントリによって記録されるサブセグメントの最初のサンプルの復号時間と、ランダムアクセスポイントの提示(合成)時間との差として表される。
8.TIDXとSIDXとの差
SIDXおよびSIDXは、インデクシングに関して同じ機能を提供する。SIDXの第1のループは、最初の動画フラグメントのためのグローバルなタイミングを追加で与えるが、グローバルなタイミングは、絶対的に、または基準トラックに対して、動画フラグメント自体にも含まれ得る。
SIDXの第2のループは、TIDXの機能を実装する。具体的には、SIDXは、reference_typeによって参照される各インデックスの参照の対象の組合せを有することを許容し、一方TIDXは、TIDXのみ、またはMOOFのみを参照する。TIDXにおけるnumber_of_elementsは、SIDXにおけるreference_countに対応し、TIDXにおけるtime−reference_track_idは、SIDXにおけるreference_track_IDに対応し、TIDXにおけるtfirst_element_offsetは、第2のループの第1のエントリにおけるreference_offsetに対応し、TIDXにおけるfirst_element_timeは、第1のループにおけるreference_trackのdecoding_timeに対応し、TIDXにおけるrandom_access_flagは、SIDXにおけるcontains_RAPに対応し、SIDXではRAPが必ずしもフラグメントの始めに配置されるとは限らないという追加の自由度を伴うので、RAP_delta_timeを必要とし、TIDXにおけるlengthは、SIDXにおけるreference_offsetに対応し、最後に、TIDXにおけるdeltaTは、SIDXにおけるsubsegment_durationに対応する。従って、2つのボックスの機能は等価である。
9.可変ブロックサイジングおよびサブGoPブロック
ビデオメディアでは、ビデオ符号化構造と要求のブロック構造との関係は重要であり得る。例えば、各ブロックがランダムアクセスポイント(「RAP」)のような探索点で開始し、各ブロックのビデオ時間が等しい期間である場合、ビデオメディアにおける少なくともいくつかの探索点の配置は固定され、探索点は、ビデオ符号化の範囲内で一定の間隔で発生する。ビデオ符号化技術の当業者にはよく知られているように、探索点がビデオフレーム間の関係に従って配置される場合、特に、探索点が前のフレームとの共通部分がほとんどないフレームに配置される場合、圧縮効率は向上し得る。従って、ブロックの時間の長さが等しいというこの要件は、圧縮が準最適となり得るように、ビデオ符号化に対して制約を課す。
探索点の位置を固定することを求めるのではなく、ビデオ提示内の探索点の位置が、ビデオ符号化システムによって選ばれるのを許容することが望ましい。ビデオ符号化システムが探索点を選ぶのを許容することで、ビデオ圧縮が改善されるので、より高品質のビデオメディアを、所与の利用可能な帯域幅を使用して提供でき、ユーザ体験の改善をもたらす。現在のブロック要求ストリーミングシステムは、全てのブロックが同じ長さ(ビデオ時間において)であることと、各ブロックが探索点で開始しなければならないこととを要求することがあるので、これは、既存のシステムの欠点である。

上記に対する利点を提供する新規のブロック要求ストリーミングシステムが、ここで説明される。一実施形態では、第1のバージョンのビデオコンポーネントのビデオ符号化処理は、圧縮効率を最適化するように、複数の探索点の位置を選ぶように構成され得るが、複数の探索点の間の長さが最大であるという要件を伴う。この後者の要件は、符号化処理による探索点の選択を制約するので、圧縮効率を下げる。しかしながら、複数の探索点の間の長さの最大値が小さすぎなければ(例えば、約1秒よりも大きければ)、圧縮効率の低下は、規則的かつ固定された位置が探索点に対して要求される場合に引き起こされるものと比較すると小さい。さらに、複数の探索点の間の長さの最大値が数秒である場合、探索点の配置が完全に自由である場合と比較すると、圧縮効率の低下は一般に非常に小さい。
この実施形態を含む多くの実施形態では、いくつかのRAPが探索点ではないことがあり、すなわち、探索点として選ばれない2つの連続する探索点の間のRAPであるフレームが存在することがあり、それは、例えば、RAPが周囲の探索点と時間的に近すぎるため、または、RAPの前もしくは後の探索点とRAPとの間のメディアデータの量が少なすぎるためである。
メディア提示の全ての他のバージョン内の探索点の位置は、第1の(例えば、メディアデータレートが最高の)バージョンにおける探索点と同じように制約され得る。これは、エンコーダに探索点の自由な選択を許容する場合と比較して、これら他のバージョンの圧縮効率を低下させ得る。
探索点の使用は通常、フレームが独立に復号可能であることを必要とし、これは一般に、そのフレームの圧縮効率を低くする。独立に復号可能であることが必要とされないフレームは、他のフレームにおけるデータを参照して符号化されてよく、これは一般に、符号化されるべきフレームと参照フレームとの共通部分の量に依存する量だけ、そのフレームの圧縮効率を向上させる。探索点の位置の効率的な選択は、前のフレームとの共通部分が少ないフレームを、優先的に探索点フレームとして選び、これによって、独立に復号可能な方法でフレームを符号化することによって引き起こされる、圧縮効率の低下を最小にする。
しかしながら、元のコンテンツが同じなので、フレームと可能性のある参照フレームとの共通性のレベルは、コンテンツの異なる表示にわたって大きく相関する。その結果、他の変形形態の探索点を第1の変形形態の探索点と同じにするという制約は、圧縮効率に大きな差を生まないことがある。
探索点構造は、好ましくは、ブロック構造を決定するために使用される。好ましくは、各探索点はブロックの始まりを決定し、2つの連続する探索点の間のデータを包含する、1つまたは複数のブロックがあり得る。探索点の間の長さは、良好な圧縮を伴う符号化では一定ではないので、全てのブロックが同じ再生の長さを有することが必要であるとは限らない。いくつかの実施形態では、ブロックはコンテンツのバージョンの間で揃えられる。すなわち、コンテンツのあるバージョン内にフレームの特定のグループにわたるブロックがある場合、コンテンツの別のバージョン内に、フレームの同じグループにわたるブロックがある。コンテンツの所与のバージョンのブロックは重複せず、コンテンツの全てのフレームが、各バージョンのちょうど1つのブロック内に含まれる。他の実施形態では、探索点を含むブロックのみが、異なるバージョンにわたって揃えられる。
探索点の間の可変の長さ、従って可変長GoPを効率的に使用するのを許容する、可能にする特徴は、セグメント内に含まれ他の手段によってクライアントに提供され得る、セグメントインデクシングまたはセグメントマップであり、すなわち、これは、提示の各ブロックの開始時間と長さとを備える、提供され得るこの表示におけるこのセグメントに関連付けられるメタデータである。クライアントは、セグメント内の特定の点で提示が開始することをユーザが要求した場合、提示を開始すべきブロックを判定する時に、このセグメントインデクシングデータを使用できる。そのようなメタデータが提供されない場合、提示は、コンテンツの始まりのみ、または、所望の点に近いランダムなまたは概略的な点のみで(例えば、開始ブロックのインデックスを与えるために、要求された開始点(時間的な)を平均のブロック長で除算して開始ブロックを選ぶことによって)、開始できる。
一実施形態では、各ブロックは別個のファイルとして提供され得る。別の実施形態では、複数の連続するブロックは、単一のファイルへと統合されてセグメントを形成し得る。この第2の実施形態では、各ブロックの開始時間および長さと、ブロックが開始するファイル内のバイトオフセットとを備える、各バージョンのメタデータが提供され得る。このメタデータは、最初のプロトコル要求に対する応答として提供されてよく、すなわち、セグメントまたはファイルとは別々に利用可能であってよく、または、例えばファイルの始まりにおいて、ブロック自体として、同じファイルまたはセグメント内に含まれてよい。当業者には明らかなように、このメタデータは、メタデータをクライアントに転送するのに必要なネットワークリソースを減らすために、gzipまたはデルタ符号化またはバイナリ形式のような、圧縮された形式で符号化され得る。
図22は、ブロックが可変サイズであり、かつ、ブロックの範囲が部分的なGoPである、すなわち、あるRAPと次のRAPとの間の部分的な量のメディアデータである、セグメントインデクシングの例を示す。この例では、探索点はRAPインジケータによって示され、1というRAPインジケータの値は、ブロックがRAPまたは探索点で開始すること、もしくはそれらを含むことを示し、0というRAPインジケータは、ブロックがRAPまたは探索点を含まないことを示す。この例では、最初の3個のブロック、すなわちバイト0から157033は第1のGoPを備え、これは、提示の長さが1.623秒であり、提示時間はコンテンツ中の20秒から21.623秒である。この例では、最初の3個のブロックのうちの最初のブロックは、提示時間が0.485秒であり、セグメント内のメディアデータの最初の50245バイトを備える。この例では、ブロック4、5、および6は第2のGoPを備え、ブロック7および8は第3のGoPを備え、ブロック9、10、および11は第4のGoPを備える。探索点として指定されない、従ってセグメントマップにおいてRAPとしてシグナリングされない、メディアデータ内の他のRAPが存在し得ることに留意されたい。
再び図22を参照すると、クライアントまたは受信機が、メディア提示中の約22秒の時間オフセットで開始するコンテンツにアクセスすることを望む場合、クライアントは、後でより詳しく説明されるMPDのような、他の情報をまず使用して、関連するメディアデータがこのセグメント内にあるとまず判定できる。クライアントは、例えばHTTPバイト範囲要求を使用して、セグメントの第1の部分をダウンロードして、この場合にはわずか数バイトであるセグメントインデクシングを取得できる。セグメントインデクシングを使用して、クライアントは、ダウンロードすべき最初のブロックが、大きくとも22秒の時間オフセットを伴いRAPで開始する最初のブロック、すなわち探索点であると判定できる。この例では、ブロック5は22秒よりも小さな時間オフセットを有するが、すなわち時間オフセットは21.965秒であるが、セグメントインデクシングは、ブロック5がRAPで開始しないことを示すので、代わりに、セグメントインデクシングに基づいて、クライアントはブロック4をダウンロードすることを選択する。それは、ブロック4の開始時間が大きくとも22秒であり、すなわちその時間オフセットが21.623秒であり、ブロック4がRAPで開始するからである。従って、セグメントインデクシングに基づいて、クライアントは、バイトオフセット157034で開始するHTTP範囲要求を行う。
セグメントインデクシングが利用可能でなければ、クライアントは、このデータをダウンロードする前に、全ての以前の157034バイトのデータをダウンロードする必要がある可能性があり、これは、はるかに長い始動時間またはチャネルザッピング時間と、有用ではないデータの無駄なダウンロードとにつながる。あるいは、セグメントインデクシングが利用可能でなければ、クライアントは、所望のデータがセグメント内で開始する箇所を概算し得るが、この概算は不正確であることがあり、適切な時間が得られないことがあり、手順を戻すことをクライアントに要求し、これも始動遅延を増やす。
一般に、各ブロックは、前のブロックと共にメディアプレーヤによって再生され得る、メディアデータの部分を包含する。従って、セグメント内に含まれるか、または他の手段を通じてクライアントに提供されるかのいずれかである、構造のブロック化およびセグメントインデクシングブロック化構造のクライアントへのシグナリングは、高速なチャネルザッピングと、ネットワークの変動および混乱に直面した時のシームレスな再生とを、クライアントが実現する能力を大きく改善できる。セグメントインデクシングによって可能にされるような、可変長ブロックと、GoPの一部のみを包含するブロックとのサポートは、ストリーミング体験を大きく改善できる。例えば、図22を再び参照すると、クライアントが提示中の約22秒において再生の開始を望む、上で説明された例では、クライアントは、1つまたは複数の要求を通じて、ブロック4内でデータを要求し、メディアプレーヤが再生を開始できるようになるとすぐに、メディアプレーヤにデータを供給できる。従って、この例では、再生は、ブロック4の41011バイトがクライアントにおいて受信されるとすぐに開始し、従って、高速なチャネルザッピング時間を可能にする。そうではなく、再生が開始すべき時より前にクライアントがGoP全体を要求する必要があったとすると、チャネルザッピング時間は144211バイトのデータであるのでより長くなる。
他の実施形態では、RAPまたは探索点は、ブロックの中心にも発生することがあり、そのRAPまたは探索点がブロックまたはフラグメント内のどこにあるかを示すデータが、セグメントインデクシング内に存在し得る。他の実施形態では、時間オフセットは、ブロック内の最初のフレームの提示時間ではなく、ブロック内の最初のフレームの復号時間であり得る。
図23(a)および図23(b)は、複数のバージョンまたは表示にわたる、揃えられた探索点構造を可変ブロックサイジングする例を示す。図23(a)は、メディアストリームの複数のバージョンにわたる、揃えられた探索点を伴う可変ブロックサイジングを示し、一方図23(b)は、メディアストリームの複数のバージョンにわたる、揃えられていない探索点を伴う可変ブロックサイジングを示す。
時間は、秒単位で頂部に示され、2つの表示に対する2つのセグメントのブロックおよび探索点は、このタイムラインに対するそれらのタイミングに関して左から右に示され、従って、示される各ブロックの長さは、再生時間に比例し、ブロックにおけるバイトの数に比例しない。この例では、2つの表示の両方のセグメントに対するセグメントインデクシングは、探索点に対して同じ時間オフセットを有するが、ブロックまたはフラグメントの数は探索点の間で異なる可能性があり、各ブロックにおけるメディアデータの量が異なることにより、ブロックに対するバイトオフセットは異なる。この例では、クライアントが約23秒の提示時間において表示1から表示2に切り替えることを望む場合、クライアントは、表示1のセグメント内のブロック1.2まで要求し、ブロック2.2で開始する表示2のセグメントの要求を開始し得るので、切り替えは、表示2における探索点2.2と同じ時間である、表示1における探索点1.2と一致する提示時間において発生し得る。
前述のことから明らかであるはずだが、説明されるブロック要求ストリーミングシステムは、ビデオ符号化物を、コンテンツ内の特定の位置にある探索点に配置するように制約せず、これは、既存のシステムの問題の1つを軽減する。
上で説明された実施形態では、同じコンテンツ提示の様々な表示の探索点が揃えられるように、それは編成される。しかしながら、多くの場合、この整列の要件を緩めることが好ましい。例えば、探索点が揃えられた表示を生成する能力を有さない符号化ツールが、表示を生成するために使用されていることがある。別の例として、コンテンツ表示は、異なる表示の間での探索点の整列を伴わずに、異なる表示において独立に符号化されることがある。別の例として、表示は、レートが低いほど多くの探索点を含むことがあり、より一般的には、早送りまたは巻き戻しまたは高速な探索のようなトリックモードをサポートするために、表示は切り替えられる必要があり、または表示は探索点を含む。従って、コンテンツ提示のための様々な表示にわたる揃えられていない探索点を効率的かつシームレスに処理することが可能な、ブロック要求ストリーミングシステムを作成する方法を提供することが望ましい。
この実施形態では、複数の表示にわたって探索点の位置は揃っていないことがある。新たなブロックが各探索点で開始するようにブロックが構築されるので、提示の異なるバージョンのブロックの間に、整列が存在しないことがある。異なる表示の間で、そのような揃えられていない探索点の構造の例が、図23(b)に示される。時間は、秒単位で頂部に示され、2つの表示に対する2つのセグメントのブロックおよび探索点は、このタイムラインに対するそれらのタイミングに関して左から右に示され、従って、示される各ブロックの長さは、再生時間に比例し、ブロックにおけるバイトの数に比例しない。この例では、2つの表示の両方のセグメントに対するセグメントインデクシングは、探索点に対して異なる時間オフセットを有する可能性があるが、ブロックまたはフラグメントの数も探索点の間で異なる可能性があり、各ブロックにおけるメディアデータの量が異なることにより、ブロックに対するバイトオフセットは異なる。この例では、クライアントが約25秒の提示時間において表示1から表示2に切り替えることを望む場合、クライアントは、表示1のセグメント内のブロック1.3まで要求し、ブロック2.3で開始する表示2のセグメントの要求を開始し得るので、切り替えは、表示1におけるブロック1.3の再生の中心にある、表示2における探索点2.3と一致する提示において発生し、従って、ブロック1.2に対するメディアの一部は再生されない(しかし、再生されないブロック1.3のフレームに対するメディアデータは、再生されるブロック1.3の他のフレームを復号するために、受信機バッファにロードされる必要があり得る)。
この実施形態では、以前に選択されたバージョンとは異なる表示からのブロックを選択することを要求された場合には常に、最後に選択されたブロックの最後のフレームの後続のフレームよりも後ではない最初のフレームを有する、最遅のブロックが選ばれるように、ブロック選択器1823の動作が修正され得る。
この最後に説明された実施形態は、第1のバージョン以外のバージョン内の探索点の位置を制約するという要件をなくし得るので、これらバージョンの圧縮効率を向上させて、所与の利用可能な帯域幅に対するより高品質の表示をもたらし、これは改善されたユーザ体験を提供する。さらなる考慮事項は、コンテンツの複数の符号化物(バージョン)にわたる探索点の整列という機能を実行するビデオ符号化ツールが、広く利用可能ではないことがあるということであり、従って、この最後に説明された実施形態の利点は、現在利用可能なビデオ符号化ツールが使用できるということである。別の利点は、コンテンツの異なるバージョンの符号化が、異なるバージョンに対する符号化処理の間の協調を何ら必要とせずに、並列に進行し得るということである。別の利点は、特定の探索点の位置のリストを符号化ツールに提供する必要なく、コンテンツの追加のバージョンが、符号化され後の時点で提示に追加され得るということである。
一般に、ピクチャがピクチャのグループ(GoP)として符号化される場合、シーケンスにおける最初のピクチャは探索点であり得るが、常にそうであるとは限らない。
メディア提示データモデル
図24は、図18に示されるコンテンツ記憶装置の可能な構造を示し、セグメントおよびmedia presentation description(「MPD」)ファイル、並びにMPDファイル内のセグメント、タイミングおよび他の構造の内訳を含む。MPD構造またはファイルの可能な実装形態の詳細が、ここで説明される。多くの例において、MPDはファイルとして説明されるが、非ファイル構造も使用され得る。
示されるように、コンテンツ記憶装置1810は、複数のソースセグメント2410と、MPD2400と、修復セグメント2412とを保持する。MPDは、期間記録2401を備えてよく、期間記録2401は表示記録2402を備えてよく、表示記録2402は、初期化セグメント2404およびメディアセグメント2405への参照のようなセグメント情報2403を含む。
図25は、例示的なメタデータテーブル2500を示すが、図26は、HTTPストリーミングクライアント2602が、HTTPストリーミングサーバ2606への接続を通じて、メタデータテーブル2500とメディアブロック2604とをどのように取得するかの例を示す。
本明細書で説明される方法では、クライアントに利用可能なメディア提示の表示に関する情報を備える、「Media Presentation Description」が提供される。表示は、クライアントが異なる選択肢から1つを選択するという意味で、複数の選択肢であってよく、または、表示は、クライアントが、各々が選択肢のセットからのものであり得る表示のいくつかを選択し、それらを一緒に提示するという意味で、相補的であってよい。表示は、有利なことにグループに割り当てられてよく、あるグループにおける複数の表示に対して、それらが互いに各々代替物であり、一方異なるグループからの表示は、2つ以上の表示が一緒に提示されるべきであるようなものであるということを理解するように、クライアントはプログラムされまたは構成される。言い換えると、2つ以上の表示がグループ内にある場合、クライアントは、そのグループから1つの表示を選び、次のグループから1つのグループを選ぶなどして、1つの表示を形成する。
表示を表す情報は、有利なことに、表示を復号するために必要なコーデックのプロファイルおよびレベルと、ビデオフレームレートと、ビデオ解像度と、データレートとを含む、適用されたメディアコーデックの詳細情報を含み得る。Media Presentation Descriptionを受信するクライアントは、この情報を使用して、表示が復号または提示に適しているかどうかを前もって判定できる。これは利点であり、それは、違いのある情報が表示のバイナリデータにのみ含まれる場合、全ての表示からバイナリデータを要求し、その適格性についての情報を見つけるために関連する情報を解析し抽出することが必要であるからである。これら複数の要求と、データの追加の抽出を解析することは、長い時間がかかることがあり、これは長い始動時間をもたらし、従ってユーザ体験の低下をもたらす。
加えて、Media Presentation Descriptionは、時間帯に基づいてクライアントの要求を制約する情報を備え得る。例えば、ライブサービスでは、クライアントは、「現在のブロードキャスト時間」に近い提示の部分を要求することに制約され得る。これは利点であり、それは、ライブブロードキャストでは、現在のブロードキャスト時間よりも前に与えられた閾値よりも多くブロードキャストされたコンテンツに対するデータを、サービング設備から除去するのが望ましいことがあるからである。これは、サービング設備内での記憶リソースの再使用のために望ましいことがある。これはまた、提供されるサービスのタイプに応じて望ましいことがあり、例えば、いくつかの場合には、受信側のクライアントデバイスの何らかの加入モデルが原因で、提示がライブのみで可能にされることがあり、一方、他のメディア提示は、ライブおよびオンデマンドで可能にされることがあり、他の提示は、第1のクラスのクライアントデバイスに対してはライブのみで可能にされ、第2のクラスのクライアントデバイスに対してはオンデマンドのみで可能にされ、第3のクラスのクライアントデバイスに対してはライブまたはオンデマンドのいずれかの組合せで可能にされることがある。(以下の)Media Presentation Data Modelで説明される方法は、クライアントが、そのような方針を知らされることを可能にするので、クライアントは、サービング設備において利用可能ではない可能性のあるデータについて、要求を行い、ユーザに対する提供を調整することを避けることができる。代替形態として、例えば、クライアントは、このデータが利用可能ではないという通知を、ユーザに提示できる。
本発明のさらなる実施形態では、メディアセグメントは、ISO/IEC14496−12で説明されるISO Base Media File Formatに準拠してよく、または、派生した規格(3GPP Technical Specification26.244において説明された3GPファイルフォーマットのような)に準拠してよい。(上記の)The Usage of 3GPP File Formatというセクションは、ブロック要求ストリーミングシステム内でのこのファイルフォーマットのデータ構造の効率的な使用を可能にする、ISO Base Media File Formatに対する新規の拡張を説明する。この参照文献で説明されるように、メディア提示の時間セグメントとファイル内のバイト範囲との高速かつ効率的なマッピングを可能にする情報が、ファイル内で提供され得る。メディアデータ自体が、ISO/IEC14496−12において定義される動画フラグメントの構築に従って構造化され得る。時間とバイトオフセットとを提供するこの情報は、階層的に構造化されてよく、または情報の単一のブロックとして構造化されてよい。この情報は、ファイルの始まりにおいて提供され得る。Usage of 3GPP File Formatにおいて説明されるような効率的な符号化を使用したこの情報の準備によって、ブロック要求ストリーミングシステムによって使用されるファイルダウンロードプロトコルがHTTPである場合、クライアントは、例えばHTTP partial GET要求を使用して、この情報を迅速に取り出すことが可能になり、これによって、始動、探索、またはストリームの切り替えの時間が短くなるので、ユーザ体験が改善される。
メディア提示における表示は、グローバルなタイムラインにおいて同期され、通常は選択肢である複数の表示のシームレスな切り替えを確実にし、2つ以上の表示の同期した提示を確実にする。従って、適応HTTPストリーミングメディア提示内の表示内に含まれるメディアのサンプルのタイミングは、複数のセグメントにわたる連続的なグローバルなタイムラインに関連し得る。
複数のタイプのメディア、例えばオーディオおよびビデオを含む、符号化されたメディアのブロックは、異なるタイプのメディアに対して、異なる提示終了時間を有し得る。ブロック要求ストリーミングシステムでは、そのようなメディアブロックは、各メディアタイプが連続的に再生されるような方法で連続的に再生され得るので、1つのブロックからの1つのタイプのメディアサンプルは、先行するブロックの別のタイプのメディアサンプルよりも前に再生されてよく、これは、本明細書では「連続ブロックスプライシング(continuous block splicing)」と呼ばれる。ある代替形態として、そのようなメディアブロックは、任意のタイプの1つのブロックの最早のサンプルが、任意のタイプの先行するブロックの最遅のサンプルよりも後に再生されるような方法で再生されてよく、これは、本明細書では「非連続ブロックスプライシング(discontinuous block splicing)」と呼ばれる。連続ブロックスプライシングは、両方のブロックが、シーケンスにおいて符号化された、同じコンテンツ項目および同じ表示からのメディアを含む場合、または他の場合に、適切であり得る。通常、1つの表示内で、2つのブロックを接合する場合、連続ブロックスプライシングが適用され得る。これは、既存の符号化を適用でき、ブロック境界においてメディアトラックを揃える必要なくセグメント化を行うことができるので、有利である。
1.Media Presentation Description
メディア提示は、HTTPストリーミングサーバ上のファイルの構造化された集合体として見ることができる。HTTPストリーミングクライアントは、十分な情報をダウンロードして、ストリーミングサービスをユーザに提示できる。代替的な表示は、3GPPファイルフォーマットに準拠する、または、3GPファイルからもしくは3GPファイルへ簡単に変換され得るデータ構造の良好に定義されたセットに少なくとも準拠する、1つまたは複数の3GPファイルまたは3GPファイルの一部を備え得る。
メディア提示は、media presentation descriptionによって表され得る。Media Presentation Description(MPD)は、適切なファイル要求、例えばHTTP GET要求を構築して、適切な時間にデータにアクセスし、ストリーミングサービスをユーザに提供するためにクライアントが使用できる、メタデータを含み得る。media presentation descriptionは、HTTPストリーミングクライアントに対して十分な情報を提供して、適切な3GPPファイルとファイルの断片とを選択できる。アクセス可能であるものとしてクライアントにシグナリングされているユニットは、セグメントと呼ばれる。
media presentation descriptionはとりわけ、次のような要素と属性とを含み得る。
2.MediaPresentationDescriptionの要素
ストリーミングサービスをエンドユーザに提供するために、HTTPストリーミングクライアントによって使用されるメタデータをカプセル化する要素。MediaPresentationDescriptionの要素は、次の属性および要素の1つまたは複数を含み得る。
Version:拡張性を確保するためのプロトコルのバージョン番号。
PresentationIdentifier:他の提示のうちから提示を一意に識別できるような情報。固有のフィールドまたは名前も含み得る。
UpdateFrequency:media presentation descriptionの更新頻度。すなわち、クライアントが実際のmedia presentation descriptionをリロードし得る頻度。存在しない場合、メディア提示は静的であり得る。メディア提示を更新することは、メディア提示をキャッシュできないことを意味し得る。
MediaPresentationDescriptionURI:media presentation descriptionに日付を付けるためのURI。
Stream:ストリームまたはメディア提示のタイプ、すなわち、ビデオか、オーディオか、またはテキストかを表す。ビデオストリームタイプは、オーディオを含んでよく、テキストを含んでよい。
Service:追加の属性を伴うサービスタイプを表す。サービスタイプは、ライブおよびオンデマンドであり得る。これは、何らかの現在の時間を超えた探索およびアクセスが許可されないことをクライアントに知らせるために、使用され得る。
MaximumClientPreBufferTime:クライアントがメディアストリームをプリバッファできる最長の時間。このタイミングは、クライアントがこの最大のプリバッファ時間を超えてダウンロードすることに制約される場合、ストリーミングを進行的なダウンロードと区別し得る。プリバッファリングに関する制約が適用され得ないことを示す値は、存在しなくてよい。
SafetyGuardIntervalLiveService:サーバにおけるライブサービスの最大の転換時間についての情報。情報の何が現在の時間において既にアクセス可能かを示すものをクライアントに提供する。この情報は、クライアントおよびサーバがUTC時間で動作することが予測され、厳密な時間的な同期が提供されない場合には、必要であり得る。
TimeShiftBufferDepth:クライアントが、現在の時間に対して、ライブサービスにおいてどの程度遠くに戻れるかについての情報。この深さの拡張によって、タイムシフト試聴および追いつきサービスが、サービスの準備における特別な変更を伴うことなく、許容され得る。
LocalCachingPermitted: このフラグは、HTTPクライアントが、ダウンロードされたデータが再生された後にそのデータをローカルにキャッシュできるかどうかを示す。
LivePresentationInterval:提示がStartTimeとEndTimeとを規定することによって利用可能にされ得る、時間間隔を含む。StartTimeはサービスの開始時間を示し、EndTimeはサービスの終了時間を示す。EndTimeが規定されない場合、終了時間は現在の時間では未知であり、UpdateFrequencyが、サービスの実際の終了時間よりも前にクライアントが終了時間を入手することを保証し得る。
OnDemandAvailabilityInterval:提示間隔は、ネットワーク上でのサービスの利用可能性を示す。複数の提示間隔が与えられ得る。HTTPクライアントは、任意の規定された時間枠の外ではサービスにアクセスすることが可能ではないことがある。OnDemand Intervalを準備することによって、追加のタイムシフト試聴が規定され得る。この属性は、ライブサービスのためにも存在し得る。それがライブサービスのために存在する場合、サーバは、クライアントが、全ての与えられた利用可能な間隔において、オンデマンドサービスとしてサービスにアクセスできることを保証し得る。従って、LivePresentationIntervalは、いずれのOnDemandAvailabilityIntervalとも重複し得ない。
MPDFileInfoDynamic:メディア提示におけるファイルのデフォルトの動的な構築を表す。さらなる詳細が以下で与えられる。MPDレベルでのデフォルトの仕様は、いくつかのまたは全ての代替的な表示に対して同じ規則が使用される場合に、不必要な繰り返しを省き得る。
MPDCodecDescription:メディア提示における主要なデフォルトのコーデックを表す。さらなる詳細が以下で与えられる。MPDレベルでのデフォルトの仕様は、いくつかのまたは全ての表示に対して同じコーデックが使用される場合に、不必要な繰り返しを省き得る。
MPDMoveBoxHeaderSizeDoesNotChange:MoveBox Headerのサイズが、メディア提示全体のうちの個々のファイルの間で変化するかどうかを示すためのフラグ。このフラグは、ダウンロードを最適化するために使用されてよく、特定のセグメントフォーマットの場合にのみ、特に、セグメントがmoovヘッダを含むセグメントフォーマットの場合にのみ存在し得る。
FileURIPattern:メディア提示内のファイルに対して要求メッセージを生成するためにクライアントによって使用されるパターン。異なる属性は、メディア提示内のファイルの各々のユニークなURIの生成を可能にする。基本URIはHTTP URIであり得る。
代替的な表示:表示のリストを表す。
1.AlternativeRepresentationの要素:
1つの表示に対する全てのメタデータをカプセル化するXML要素。AlternativeRepresentationの要素は、次の属性と要素とを含み得る。
RepresentationID:メディア提示内のこの特定のAlternativeRepresentationに対するユニークなID。
FilesInfoStatic:1つの代替的な表示の全てのファイルの開始時間およびURIの明示的なリストを提供する。ファイルのリストの静的な準備は、メディア提示の正確なタイミングの記述という利点を提供し得るが、特に代替的な表示が多くのファイルを含む場合は、さほど小型ではないことがある。また、ファイル名は任意の名前を有し得る。
FilesInfoDynamic:1つの代替的な提示の開始時間およびURIのリストを構築するための暗黙的な方法を提供する。ファイルのリストの動的な準備は、より小型な表示という利点を提供し得る。開始時間のシーケンスのみが提供される場合、ここでもタイミングの利点が成り立つが、ファイル名は、FilePatternURIに基づいて動的に構築されることになる。各セグメントの長さのみが提供される場合、表示は小型であり、ライブサービスにおいて使用するのに適している可能性があるが、ファイルの生成はグローバルなタイミングによって支配され得る。
APMoveBoxHeaderSizeDoesNotChange:MoveBox Headerのサイズが、Alternative Description内の個々のファイルのうちで変化するかどうかを示すフラグ。このフラグは、ダウンロードを最適化するために使用されてよく、特定のセグメントフォーマットの場合にのみ、特に、セグメントがmoovヘッダを含むセグメントフォーマットの場合にのみ存在し得る。
APCodecDescription:代替的な提示におけるファイルの主要なコーデックを表す。
Media Descriptionの要素
MediaDescription:この表示内に含まれるメディアに対する全てのメタデータをカプセル化できる要素。具体的には、この代替的な提示におけるトラックについての情報、さらには、可能であれば、トラックの推奨されるグルーピングについての情報を含み得る。MediaDescriptionの属性は、次の属性を含む。
TrackDescription:この表示内に含まれるメディアに対する全てのメタデータをカプセル化するXML属性。TrackDescriptionの属性は、次の属性を含む。
TrackID:代替的な表示内におけるトラックに対するユニークなID。これは、トラックがグルーピングの説明の一部である場合に使用され得る。
Bitrate:トラックのビットレート。
TrackCodecDescription:このトラックにおいて使用されるコーデックの全ての属性を含むXML属性。TrackCodecDescriptionの属性は、次の属性を含む。
MediaName:メディアタイプを定義する属性。メディアタイプは、「オーディオ」と、「ビデオ」と、「テキスト」と、「アプリケーション」と、「メッセージ」とを含む。
Codec:プロファイルとレベルとを含むコーデックタイプ。
LanguageTag:適用可能な場合、言語タグ。
MaxWidth、MaxHeight:ビデオに対する、含まれるビデオのピクセル単位での高さおよび幅。
SamplingRate:オーディオに対するサンプリングレート。
GroupDescription:異なるパラメータに基づく適切なグルーピングのための推奨をクライアントに提供する属性。
GroupType:トラックをどのようにグループ化するかをクライアントが決める際の基礎となり得る、タイプ。
media presentation descriptionにおける情報は、有利には、適切な時間にファイル/セグメントまたはその一部に対する要求を実行するために、HTTPストリーミングクライアントによって使用され、例えば、アクセス帯域幅、ディスプレイ能力、コーデック能力など、さらには言語などのようなユーザの選考に関して、能力と一致する適切な表示からセグメントを選択する。さらに、Media Presentation descriptionは、時間的に揃えられグローバルなタイムラインにマッピングされる表示を表すので、クライアントはまた、表示を切り替えるために、表示を一緒に提示するために、またはメディア提示内を探索するために適切な動作を開始するために、進行中のメディア提示の間にMPD内の情報を使用できる。
1.セグメント開始時間のシグナリング
表示は、時間方向に、複数のセグメントへと分割され得る。あるセグメントの最後のフラグメントと次のセグメントの次のフラグメントとの間には、トラック間のタイミングの問題が存在する。加えて、一定の長さのセグメントが使用される場合、別のタイミング問題が存在する。
各セグメントに対して同じ長さを使用することは、MPDが小型かつ静的であるという利点を有し得る。しかしながら、各セグメントは依然として、ランダムアクセスポイントで開始し得る。従って、ビデオ符号化は、これら特定の点でランダムアクセスポイントを提供するように制約されることがあり、または、実際のセグメントの長さは、MPDにおいて規定されるほど正確ではないことがある。ストリーミングシステムが、ビデオ符号化処理に不必要な制約を課さないことが望ましいことがあるので、第2の選択肢が好適であり得る。
具体的には、ファイルの長さがMPDにおいてd秒と規定される場合、n番目のファイルは、ランダムアクセスポイントで、または、時間(n−1)dの直後に、開始できる。
この手法では、各ファイルは、グローバルな提示時間を単位とするセグメントの正確な開始時間についての情報を含み得る。これをシグナリングするための3つの可能な方法は、以下を含む。
(1)第1に、各セグメントの開始時間を、MPDにおいて規定されるような正確なタイミングに制約する。しかしそうすると、メディアエンコーダは、IDRフレームの配置について柔軟性をまったく有することができず、ファイルストリーミングのために特別な符号化を必要とし得る。
(2)第2に、各セグメントのMPDに正確な開始時間を追加する。オンデマンドの場合、MPDの小型性が低下し得る。ライブの場合、これは、MPDの定期的な更新を必要とすることがあり、スケーラビリティを下げ得る。
(3)第3に、表示の告知された開始時間またはMPDにおけるセグメントの告知された開始時間に対する、グローバルな時間または正確な開始時間を、セグメントに追加し、ある意味ではセグメントがこの情報を含む。これは、適応ストリーミングに専用の新たなボックスに追加され得る。このボックスはまた、「TIDX」または「SIDX」ボックスによって提供されるような情報も含み得る。この第3の手法の結果は、セグメントの1つの始まりの近くの特定の位置を探す時に、クライアントが、MPDに基づいて、要求された探索点を含むセグメントの後続のセグメントを選ぶことができる、というものである。この場合の簡単な応答は、取り出されるセグメントの始まりに(すなわち、探索点の後の次のランダムアクセスポイントに)探索点を進めるように移動することであり得る。通常、ランダムアクセスポイントは、少なくとも数秒ごとに提供されるので(かつ、ランダムアクセスポイントの頻度を低くすることによる符号化の利益はほとんどないことが多いので)、最悪の場合、探索点は規定された箇所よりも数秒後に移動され得る。あるいは、クライアントは、セグメントのためのヘッダ情報を取り出す際に、要求された探索点が実際には前のセグメントにあると判定し、代わりにそのセグメント要求できる。これは、探索動作を実行するのに必要な時間の偶発的な増加をもたらし得る。
2.アクセス可能なセグメントのリスト
メディア提示は、元のメディアコンテンツの符号化物の何らかの異なるバージョンを各々提供する、表示のセットを備える。有利なことに、表示自体が、他のパラメータと比較して表示を差別化するパラメータについての情報を含む。表示はまた、明示的にまたは暗黙的に、アクセス可能なセグメントのリストを含む。

セグメントは、メタデータを含む時間に無関係のセグメント、および、メディアデータを主に含むメディアセグメントにおいて、差別化され得る。Media Presentation Description(「MPD」)は、有利なことに、暗黙的または明示的のいずれかに、異なる属性を識別しセグメントの各々へ割り当てる。各セグメントへと有利に割り当てられた属性は、セグメントがアクセス可能な期間と、それらを通じてセグメントがアクセス可能であるリソースとプロトコルとを備える。加えて、メディアセグメントは、有利なことに、メディア提示におけるセグメントの開始時間、およびメディア提示におけるセグメントの長さのような属性を、割り当てられる。
OnDemandAvailabilityIntervalのようなmedia presentation descriptionにおける属性によって有利に示されるように、メディア提示が「オンデマンド」のタイプである場合、media presentation descriptionは通常、セグメント全体を表し、セグメントがいつアクセス可能でセグメントがいつアクセス可能ではないかということの指示も提供する。同じメディア提示の再生を、しかし異なる時間に開始する2つのクライアントが、同じmedia presentation description、さらには同じメディアセグメントを使用できるように、セグメントの開始時間は有利なことに、メディア提示の始まりに対して表される。これは有利なことに、セグメントをキャッシュする能力を改善する。
属性Serviceのようなmedia presentation descriptionにおける属性によって有利に示されるように、メディア提示が「ライブ」のタイプである場合、実時間で1日を超えるメディア提示を備えるセグメントは、一般に、セグメントがMPDにおいて完全に表されていても、生成されず、または少なくともアクセス可能ではない。しかしながら、メディア提示サービスが「ライブ」のタイプであるという指示によって、クライアントは、MPDに含まれる情報およびMPDのダウンロード時間に基づいて、実時間でクライアント内部時間NOWに対するタイミング属性と共に、アクセス可能なセグメントのリストを生成できる。実時間NOWにおけるMPDのインスタンスと共に動作する参照クライアントがリソースにアクセスできるように、サーバがリソースをアクセス可能にするという意味で、サーバは有利に動作する。
具体的には、参照クライアントは、MPDに含まれる情報およびMPDのダウンロード時間に基づいて、実時間でクライアント内部時間NOWに対するタイミング属性と共に、アクセス可能なセグメントのリストを生成する。時間が進むと、クライアントは、同じMPDを使用して、メディア提示を連続的に再生するために使用され得る新たなアクセス可能なセグメントのリストを作成する。従って、サーバは、これらセグメントが実際にアクセス可能になる前に、MPD内でセグメントを告知できる。これは有利であり、それは、MPDの頻繁な更新とダウンロードとを減らすからである。
各々の開始時間がtSであるセグメントのリストが、FileInfoStaticのような要素における再生リストによって明示的に表され、または、FileInfoDynamicのような要素を使用して暗黙的に表されると仮定する。FileInfoDynamicを使用してセグメントリストを生成するための有利な方法が、以下で説明される。この構築規則に基づいて、クライアントは、インデックスiを有する各セグメントに対し、本明細書ではFileURI(r,I)と呼ばれる各表示rのURIのリストと、開始時間tS(r,i)とを入手する。
セグメントのアクセス可能な時間枠を作成するために、MPDにおける情報を使用することは、次の規則を使用して実行され得る。
Serviceのような属性によって有利に示されるような、「オンデマンド」のタイプのサービスについて、クライアントにおける現在の実時間NOWが、OnDemandAvailabilityIntervalのようなMPD要素によって有利に表される利用可能な任意の範囲内にある場合、このオンデマンドの提示の全ての説明されるセグメントはアクセス可能である。クライアントにおける現在の実時間NOWが利用可能な任意の範囲の外にある場合、このオンデマンドの提示の説明されるセグメントはいずれもアクセス可能ではない。
Serviceのような属性によって有利に示されるような、「ライブ」のタイプのサービスについて、開始時間tS(r,i)は有利なことに、実時間における利用可能な時間を表す。利用可能な開始時間は、イベントのライブサービス時間と、キャプチャ、符号化、および公開のためのサーバにおける何らかの転換時間との組合せとして、導出され得る。例えば、この処理のための時間は、例えば、MPDにおけるSafetyGuardIntervalLiveServiceとして規定される、安全ガード間隔tGを例えば使用して、MPD内で規定され得る。これは、UTC時間と、HTTPストリーミングサーバ上でのデータの利用可能性との、最小の差を与える。別の実施形態では、MPDは、イベントのライブ時間と転換時間との差として転換時間を提供することなく、MPDにおいてセグメントの利用可能な時間を明示的に規定する。以下の説明では、利用可能な時間として、任意のグローバルな時間が規定されることが仮定される。ライブメディアブロードキャスティングの当業者は、この説明を読んだ後、media presentation descriptionにおける適切な情報から、この情報を導出できる。
クライアントにおける現在の実時間NOWが、LivePresentationIntervalのようなMPD要素によって有利に表されるライブ提示間隔の任意の範囲の外にある場合、このライブ提示の説明されるセグメントはいずれもアクセス可能ではない。クライアントにおける現在の実時間NOWがライブ提示間隔内にある場合、このライブ提示の説明されるセグメントの少なくともいくつかのセグメントはアクセス可能であり得る。
アクセス可能なセグメントの制約は、次の値によって支配される。
(クライアントに利用可能な)実時間NOW
例えばmedia presentation descriptionにおけるTimeShiftBufferDepthとして規定される、許容される時間シフトバッファ深度tTSB。
相対的なイベント時間t1におけるクライアントは、(NOW−tTSB)とNOWとの間隔に、または、長さdのセグメントの終了時間も含まれるような間隔、すなわち(NOW−tTSB−d)とNOWとの間隔に開始時間tS(r,i)を伴うセグメントのみを、要求することが許可され得る。
3.MPDの更新
いくつかの実施形態では、サーバは、ファイルまたはセグメントロケータとセグメントの開始時間とを、前もって知らない。それは、例えば、サーバの位置か変わるため、または、メディア提示が異なるサーバからのいくつかの告知を含むため、または、メディア提示の長さが未知であるため、または、サーバが以後のセグメントのロケータを不明瞭にするのを望むためである。
そのような実施形態では、サーバは、既にアクセス可能な、または、MPDのこのインスタンスが公開されたすぐ後にアクセス可能になるセグメントのみを、表し得る。さらに、いくつかの実施形態では、ユーザがメディアコンテンツの生成から可能な限り近くで含まれるメディアプログラムを体験するように、クライアントは、有利なことに、MPDにおいて表されるメディアの近くでメディアを消費する。クライアントがMPD内で表されたメディアセグメントの終わりに達するとクライアントが予測するとすぐに、クライアントは、有利なことに、MPDの新たなインスタントを要求して、新たなメディアセグメントを表す新たなMPDをサーバが公開したという予測のもとで、連続的な再生を継続する。サーバは、有利なことに、クライアントが連続的な更新のための手順を利用できるように、MPDの新たなインスタンスを生成し、MPDを更新する。サーバは、セグメントの生成および公開と共に、サーバのMPD更新手順を、共通のクライアントが動作し得るように動作する参照クライアントの手順に適応させることができる。
MPDの新たなインスタンスが事前の短時間しか表さない場合、クライアントは、MPDの新たなインスタンスを頻繁に要求する必要がある。これは、スケーラビリティの問題と、不必要かつ頻繁な要求による不必要なアップリンクおよびダウンリンクのトラフィックとをもたらし得る。
従って、一方では、セグメントを必ずしもまだアクセス可能にすることなくできる限り未来のセグメントを表すことに関係があり、もう一方では、新たなサーバの位置を表し、広告のような新たなコンテンツの挿入を許容し、またはコーデックパラメータの変更を提供するために、MPD内で予測されない更新を可能にすることに関係がある。
さらに、いくつかの実施形態では、メディアセグメントの長さは短いことがあり、例えば数秒の範囲内であり得る。メディアセグメントの長さは、有利なことに、配信またはキャッシュの特性に最適化され得る適切なセグメントサイズに調整するために、ライブサービスにおけるエンドツーエンドの遅延またはセグメントの格納もしくは配信に関連する他の様相を補償するために、または他の理由で、柔軟である。セグメントがメディア提示の長さと比較して短い場合は特に、大量のメディアセグメントリソースおよび開始時間が、media presentation descriptionにおいて表される必要がある。その結果、media presentation descriptionのサイズは大きくなることがあり、これは、media presentation descriptionのダウンリンク時間に悪影響を与えることがあり、従って、メディア提示の始動遅延に、さらにアクセスリンク上での帯域幅の使用率に影響を与えることがある。従って、再生リストを使用したメディアセグメントのリストの表現を許容するだけではなく、テンプレートまたはURL構築規則を使用することによる表現も許容することが有利である。テンプレートおよびURI構築規則は、この説明では同義に使用される。
加えて、ライブの場合に現在時刻を超えてセグメントロケータを表すために、テンプレートが有利に使用され得る。そのような場合、ロケータ、さらにはセグメントリストが、テンプレートによって表されるので、MPDの更新自体は不必要である。しかしながら、表示またはセグメントの記述の変更を必要とする、予測されない事象は依然として起こり得る。複数の異なるソースからのコンテンツが一緒に接合される場合、例えば、広告が挿入された場合、適応HTTPストリーミングのmedia presentation descriptionの変更が必要であり得る。異なるソースからのコンテンツは、様々な方式で異なり得る。別の理由は、ライブ提示の間に、コンテンツファイルに使用されるURLを変更して、1つのライブの元のサーバから別のサーバへのフェイルオーバーを提供する必要があり得る、ということである。
いくつかの実施形態では、MPDが更新される場合、更新されたMPDが次のような意味で前のMPDに適合するように、MPDに対する更新が実行されることが有利である。すなわち、参照クライアントと、従って任意の実装されるクライアントは、それがMPDの前のインスタンスから生成していたように、アクセス可能なセグメントの同じように機能するリストを、前のMPDの有効時間までの任意の時間、更新されたMPDから生成する。この要件は、(a)クライアントが、更新時間の前の古いMPDと適合するので、古いMPDとの同期を伴わずに、新たなMPDを使用して直ちに開始できることと、(b)更新時間が、MPDに対する実際の変更が発生する時間と同期する必要がないこととを、保証する。言い換えると、MPDに対する更新は、前もって告知されてよく、サーバは、MPDの異なるバージョンを維持する必要なく、新たな情報が利用可能になると、MPDの古いインスタンスを置き換えることができる。
表示のセットまたは全ての表示に対するMPD更新にわたるメディアのタイミングについて、2つの可能性が存在し得る。(a)既存のグローバルなタイムラインがMPD更新にわたって継続する(本明細書では「連続MPD更新」と呼ばれる)か、または(b)現在のタイムラインが終了し、新たなタイムラインが変更の後のセグメントで開始する(本明細書では「非連続MPD更新と呼ばれる」)のいずれかである。
これら選択肢の違いは、メディアフラグメントのトラック、従ってセグメントのトラックが、一般に、トラック間のサンプル粒度の違いによって同時に開始および終了しないということを考えると、明らかであり得る。通常の提示の間、フラグメントの1つのトラックのサンプルは、前のフラグメントの別のトラックのいくつかのサンプルの前にレンダリングされてよく、すなわち、複数のフラグメントの間にはある種の重複が存在するが、単一のトラック内での重複はないことがある。
(a)と(b)の違いは、そのような重複がMPD更新にまたがって可能にされ得るかどうかである。MPD更新が、完全に別個のコンテンツの接合によるものである場合、そのような重複は一般に達成することが難しく、それは、前のコンテンツと接合されるために新たなコンテンツが新たな符号化を必要とするからである。従って、いくつかのセグメントのタイムラインを再始動することによってメディア提示を非連続的に更新するための能力を提供し、場合によって更新の後に表示の新たなセットも定義することが、有利である。また、コンテンツが独立に符号化されセグメント化されている場合、コンテンツの前の断片のグローバルなタイムライン内で適合するようにタイムスタンプを調整することも回避される。
更新が、表されたメディアセグメントのリストに新たなメディアセグメントを追加するためだけなどの、より小さな理由によるものである場合、または、URLの位置が変更された場合、重複および連続的な更新が許容され得る。
非連続MPD更新の場合、前の表示の最後のセグメントのタイムラインは、セグメントにおける任意のサンプルの最遅の提示終了時間で終了する。次の表示のタイムライン(またはより正確には、新たな期間とも呼ばれる、メディア提示の新たな部分の最初のメディアセグメントの最初の提示時間)は、通常かつ有利には、シームレスかつ連続的な再生が保証されるように、最後の期間の提示の終わりと同じこの瞬間に開始する。
2つの場合が、図27に示されている。
MPD更新を、セグメントの境界に制約することが、好適であり有利である。変更または更新をセグメントの境界へとそのように制約する論拠は、次の通りである。第1に、通常は動画ヘッダである、各表示のバイナリメタデータに対する変更は、少なくともセグメントの境界で起こり得る。第2に、Media Presentation Descriptionは、セグメントに対するポインタ(URL)を含み得る。ある意味では、MPDは、メディア提示に関連付けられる全てのセグメントファイルを一緒にグループ化する、「傘の(umbrella)」データ構造である。この包含関係を維持するために、各セグメントは単一のMPDによって参照されてよく、MPDが更新される場合、MPDは有利にはセグメントの境界のみにおいて更新される。
セグメントの境界は、一般には揃えられる必要はないが、異なるソースから接合されたコンテンツの場合、また、非連続MPD更新の場合には一般に、セグメントの境界を揃えることが理にかなう(具体的には、各表示の最後のセグメントは、同じビデオフレームで終了してよく、そのフレームの提示時間よりも遅い提示開始時間を伴うオーディオサンプルを含まなくてよい)。そして、非連続的な更新は、期間と呼ばれる共通の時間的な瞬間において表示の新たなセットを開始できる。表示のこの新たなセットが有効となる開始時間は、例えば、期間開始時間によって与えられる。各表示の相対的な開始時間は0にリセットされ、期間の開始時間は、グローバルなメディア提示タイムラインにおけるこの新たな期間に表示のセットを配置する。
連続MPD更新では、セグメントの境界は揃えられる必要はない。各代替的な表示の各セグメントは、単一のMedia Presentation Descriptionによって支配され得るので、追加のメディアセグメントが動作しているMPDにおいて表されていないという予測によって一般にトリガされる、Media Presentation Descriptionの新たなインスタンスに対する更新の要求は、消費されると予測される表示のセットを含む表示の消費されるセットに応じて、異なる時間に起こり得る。
より一般的な場合において、MPDの要素と属性の更新をサポートするために、表示または表示のセットだけではなく、任意の要素が有効時間に関連付けられ得る。よって、MPDのいくつかの要素が更新される必要がある場合、例えば、表示の数が変更された、またはURL構築規則が変更された場合、これら要素は各々、要素の複数のコピーをつながっていない複数の有効時間に提供することによって、規定された時間において個々に更新され得る。
有効時間に関連付けられる説明された要素が、メディア提示のグローバルなタイムラインのある期間において有効であるように、有効性は、有利なことに、グローバルなメディア時間に関連付けられる。
上で論じられたように、一実施形態では、有効時間は、表示の完全なセットにのみ追加される。次いで、完全な各セットは期間を形成する。次いで、有効時間は期間の開始時間を形成する。言い換えると、有効性要素を使用する特定の場合には、表示の完全なセットは、表示のセットに対するグローバルな有効時間によって示される、ある期間において有効であり得る。表示のセットの有効時間は、期間と呼ばれる。新たな期間の始まりにおいて、前のセットの表示の有効性はなくなり、表示の新たなセットが有効になる。期間の複数の有効時間は、好ましくはつながっていないことに再び留意されたい。
上で述べられたように、Media Presentation Descriptionに対する変更は、セグメントの境界で起こるので、各表示に対して、要素に対する変更は、実際には次のセグメントの境界において起こる。クライアントは次いで、メディアの提示時間内の時間の各瞬間に対するセグメントのリストを含む、有効MPDを形成し得る。
ブロックが、異なる表示からの、または異なるコンテンツからの、例えば、コンテンツのセグメントおよび広告からの、メディアデータを含む場合、または他の場合、非連続ブロックスプライシングが適切であり得る。ブロック要求ストリーミングシステムでは、提示メタデータに対する変更はブロックの境界のみにおいて起こることが、必要とされ得る。これは、ブロック内でのメディアデコーダパラメータを更新することが、それらをブロックの間でのみ更新することよりも複雑であることがあるので、実装上の理由により有利であり得る。この場合、規定された有効間隔の始まりよりも前にない第1のブロックの境界から、規定された有効間隔の終わりよりも前にない第1のブロックの境界まで、要素が有効であると考えられるように、上で説明されたような有効間隔が概略的に解釈され得ることが、有利なことに規定され得る。
上述されたブロック要求ストリーミングシステムに対する新規の拡張の例示的な実施形態について、メディア提示への変更と題された後で提示されるセクションにおいて説明する。
4.セグメント期間のシグナリング
非連続的な更新は、期間と呼ばれる一連のつながっていない間隔へと、提示を実質的に分割する。各期間は、メディアサンプルタイミングのための固有のタイムラインを有する。期間内における表示のメディアタイミングは、有利なことに、各期間、または期間内の各表示に対する、セグメントの長さの別個の小型のリストを規定することによって指示され得る。
MPD内の要素に関連付けられる、例えば期間開始時間と呼ばれる属性は、メディア提示時間内のいくつかの要素の有効時間を規定し得る。この属性は、MPDの任意の要素(有効性を割り当てられ得る属性は要素へと変更され得る)に追加され得る。
非連続MPD更新では、全ての表示のセグメントは、断絶で終了し得る。これは一般に、断絶の前の最後のセグメントが、前のセグメントとは異なる長さを有することを、少なくとも示唆する。セグメントの長さをシグナリングすることは、全てのセグメントが同じ長さを有することを示すこと、または各セグメントに対して別個の長さを示すことのいずれかを伴い得る。セグメントの長さのリストのための小型の表示を有することが望ましいことがあり、これは、セグメントの長さの多くが同じ長さを有さない場合に効率的である。
1つの表示または表示のセットにおける各セグメントの長さは、非連続的な更新の開始、すなわち、MPD内で表される最後のメディアセグメントまでの期間の開始からの、単一の間隔に対する全てのセグメントの長さを規定する単一の文字列を伴って有利に実行され得る。一実施形態では、この要素のフォーマットは、セグメントの長さのエントリのリストを含む生成物に準拠するテキスト文字列であり、各エントリは、長さの属性durと属性の任意選択の乗算子multとを含み、multは、この表示が、第1のエントリの長さ<dur>の第1のエントリセグメントの<mult>個を含み、第2のエントリの長さ<dur>の第2のエントリセグメントの<mult>個を含み、以下同様であることを示す。
各長さのエントリは、1つまたは複数のセグメントの長さを規定する。<dur>値の後に文字「*」および数字が続く場合、この数字は、秒単位でこの長さを有する連続的なセグメントの数を規定する。乗算子の記号「*」がない場合、セグメントの数は1つである。「*」があり後ろに続く数字がない場合、全ての後続のセグメントは規定された長さを有し、リスト内にはさらなるエントリはなくてよい。例えば、文字列「30*」は、全てのセグメントが30秒の長さを有することを意味する。文字列「30*12 10.5」は、30秒の長さの12個のセグメントと、その後に続く1つの10.5秒の長さとを示す。
セグメントの長さが各代替的な表示に対して別々に規定される場合、各間隔内におけるセグメントの長さの合計は、各表示に対して同じであり得る。ビデオトラックの場合、間隔は、各代替的な表示における同じフレームで終了し得る。
当業者は、本開示を読めば、セグメントの長さを小型な方式で表現するための、同様かつ等価な方法を見出し得る。
別の実施形態では、セグメントの長さは、単一の長さの属性<duration>による最後の1つを除いて、表示における全てのセグメントに対して一定であるとシグナリングされる。非連続的な更新の前の最後のセグメントの長さは、次の非連続的な更新の開始点または新たな期間の始まりが提供される限りより短くてよく、これは、最後のセグメントの長さが次の期間の始まりに達することを示唆する。
さらなる実施形態が、本開示を読んだ後に、当業者に想起され得る。他の実施形態では、上で開示された発明の組合せまたは副次的な組合せが、有利に行われ得る。コンポーネントの例示的な構成は例示を目的に示され、組合せ、追加、再構成などが、本発明の代替的な実施形態において考えられることを理解されたい。従って、本発明は、例示的な実施形態に関して説明されてきたが、多数の修正が可能であることを当業者は認識するだろう。
例えば、本明細書で説明される処理は、ハードウェアコンポーネント、ソフトウェアコンポーネント、および/またはこれらの任意の組合せを使用して実施され得る。いくつかの場合には、ソフトウェアコンポーネントは、媒体と共に提供される、または媒体と別個のハードウェア上での実行のために、有形な非一時的媒体上で提供され得る。従って、本明細書および図面は、限定的な意味ではなく例示的であると解釈されるべきである。しかしながら、特許請求の範囲において述べられるような本発明のより広い趣旨および範囲から逸脱することなく、様々な修正および変更を行うことができ、本発明は、以下の特許請求の範囲内にある全ての修正と等価物とを包含することが意図されることは、明らかである。

Claims (21)

  1. サーバからクライアントに送信されるメディアストリームにおいて、適応HTTPストリーミングのための表示を切り替えるためのシグナリングの方法であって、
    セグメントマップを表示のセグメントに関連付けることと、ここにおいてセグメントマップが、バイトオフセット情報と共に、関連付けられたセグメント内の時間的な開始点と時間的な終了点の両方を備える、
    前記関連付けられたセグメントの時間スパンとは独立の予測可能な時間スパンのパターンを伴うセグメントマップを生成することとを備える、方法。
  2. 複数の表示としてストリーミングされるコンテンツをフォーマットする方法であって、ここにおいて前記複数の表示の各々はコンテンツの項目に対する選択肢であり、前記コンテンツは、前記コンテンツが使用される提示内での時間を定義した定義済みの提示時間を有する、
    各表示を前記表示の複数のセグメントとして編成することと、ここにおいてセグメントが、前記表示の他のセグメントのうちでの時間的な順序を有する前記コンテンツの一部分に関連するデータを備え、前記セグメントは、前のセグメントへのアクセス権を有さない受信機によって使用できるようなものであり、セグメントの時間的な開始点および時間的な終了点が、前記セグメントのデータを使用して提示可能な前記提示の期間を表す、
    前記コンテンツ内の提示時間と表示内のバイトオフセットとをマッピングするバイトオフセット情報と共に、前記コンテンツ内の提示時間に対応する時間的な移行点を備えるセグメントマップを生成することと、
    前記時間的な開始点の少なくとも一部と前記時間的な終了点の少なくとも一部を揃えることと、ここにおいて揃えることが、第1の表示内のセグメントの時間的な開始点の提示時間と第2の表示内のセグメントの時間的な終了点の提示時間との一致をもたらし、かつ揃えることが、複数の一致をもたらす、
    を備える、方法。
  3. 各セグメントに対してファイル名を決定することと、
    各セグメントのコンテンツを、各セグメントの前記ファイル名を使用して、複数のファイルとして格納することとをさらに備える、請求項2に記載の方法。
  4. コンテンツを消費するクライアントにおいて、コンテンツ要求を決定することと、ここにおいて前記コンテンツ要求が少なくとも1つの表示と提示時間範囲とを規定する、
    前記コンテンツ要求に対応する前記セグメントを表す前記複数のファイルのうちのファイルの1つまたは複数のURLのセットを決定することと、
    URLの前記セットを使用してセグメントを要求することと、
    前記セグメントを受信することと、
    前記セグメントからのコンテンツを前記クライアントでコンテンツ消費者に提供することとをさらに備える、請求項3に記載の方法。
  5. ネットワークに接続可能で、前記ネットワークを通じて要求可能で、0でない再生時間を有するコンテンツを提示可能なクライアントデバイスを使用してコンテンツを要求する方法であって、
    コンテンツ要求を決定することと、ここにおいて前記コンテンツ要求は少なくとも1つの提示と提示時間範囲とを規定し、前記提示時間範囲は要求されている前記提示の一部または全ての一部分を定義する、
    格納されたメディア提示データセットから、要求フォーマットのテンプレート、セグメント時間長、および可変セグメント範囲を読み取ることと、前記可変セグメント範囲はセグメントの提示時間範囲の変動を定義し、前記変動は前記メディア提示データセットに格納される前記セグメント時間長に関係する、
    セグメント時間長の値を前記提示時間範囲の始まりに対応する時間的な開始点と比較して、初期セグメントインデックスを決定することと、
    前記初期セグメントインデックス、前記可変セグメント範囲、前記セグメント時間長、および前記可変セグメント範囲とを評価して、所望のセグメントインデックスを決定することと、
    前記所望のセグメントインデックスおよび前記要求フォーマットのテンプレートに基づいて、前記コンテンツ要求に対応するファイル要求を生成することと、
    前記ファイル要求を使用して少なくとも1つのファイルを要求することとを備える、方法。
  6. 前記ファイル要求はURLであり、少なくとも1つのファイルを要求することが、前記URLを使用したHTTP要求を使用して実行される、請求項5に記載の方法。
  7. 前記初期セグメントインデックスは前記時間的な開始点を前記セグメント時間長で除算することによって決定され、前記所望のセグメントインデックスは前記除算の余りが前記可変セグメント範囲より小さい場合に前記初期セグメントインデックスとして決定され、前記除算の余りは前記可変セグメント範囲以上である場合に前記初期セグメントのすぐ前のセグメントインデックスとして決定される、請求項5に記載の方法。
  8. 前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すことをさらに備える、請求項5に記載の方法。
  9. 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長から、前記セグメント時間長に前記変動の時間範囲を足した時間長までの間となるような前記時間範囲である、請求項5に記載の方法。
  10. 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長の1.0倍から前記セグメント時間長の1+P倍までの間となるような比率Pである、請求項5に記載の方法。
  11. 前記セグメント時間長に関係のある前記変動は、前記変動の時間範囲にわたる前記セグメント時間長よりもセグメント提示時間が大きくまたは小さくなり得るような前記時間範囲である、請求項5に記載の方法。
  12. 前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すことをさらに備える、請求項11に記載の方法。
  13. セグメントが複数の表示のうちの1つから要求され、前記複数の表示の各々がコンテンツの項目に対する選択肢である、請求項5に記載の方法。
  14. ネットワークを通じて要求可能で、前記ネットワークを通じて取り出され0でない再生時間を有するコンテンツを提示可能なクライアントデバイスであって、
    格納された命令を実行することが可能な処理要素と、
    データを格納可能なメモリと、
    命令を格納可能なメモリと、
    コンテンツ要求を決定するためのプログラムコードと、ここにおいて前記コンテンツ要求は少なくとも1つの提示と提示時間範囲とを規定し、前記提示時間範囲は要求されている前記提示の一部または全ての一部分を定義する、
    格納されたメディア提示データセットから、要求フォーマットのテンプレート、セグメント時間長、および可変セグメント範囲を読み取るためのプログラムコードと、ここにおいて前記可変セグメント範囲はセグメントの提示時間範囲の変動を定義し、前記変動は前記メディア提示データセットに格納される前記セグメント時間長に関係する、
    セグメント時間長の値を前記提示時間範囲の始まりに対応する時間的な開始点と比較して、初期セグメントインデックスを決定するためのプログラムコードと、
    前記初期セグメントインデックス、前記可変セグメント範囲、前記セグメント時間長、および前記可変セグメント範囲を評価して、所望のセグメントインデックスを決定するためのプログラムコードと、
    前記所望のセグメントインデックスおよび前記要求フォーマットのテンプレートに基づいて、前記コンテンツ要求に対応するファイル要求を生成するためのプログラムコードと、
    前記ネットワークにメッセージを送信し前記ネットワークからメッセージを受信するためのネットワークインターフェースと、
    前記ファイル要求を使用して少なくとも1つのファイルを要求するためのプログラムコードとを備える、クライアントデバイス。
  15. 前記ネットワークインターフェースはワイヤレスネットワークインターフェースである、請求項14に記載のクライアントデバイス。
  16. 前記ネットワークインターフェースは有線ネットワークインターフェースである、請求項14に記載のクライアントデバイス。
  17. 前記ファイル要求はURLであり、要求が前記URLを使用したHTTP要求である、請求項14に記載のクライアントデバイス。
  18. 前記提示時間範囲の終わりに対応する、または前記終わりよりも遅い、時間的な終了点を伴うコンテンツを含むセグメントが受信されるまで、ファイル要求を繰り返すためのプログラムコードをさらに備える、請求項14に記載のクライアントデバイス。
  19. 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長から、前記セグメント時間長に前記変動の時間範囲を足した時間長までの間となるような、前記時間範囲である、請求項14に記載のクライアントデバイス。
  20. 前記セグメント時間長に関係のある前記変動は、セグメント提示時間が前記セグメント時間長の1.0倍から前記セグメント時間長の1+P倍までの間となるような比率Pである、請求項14に記載のクライアントデバイス。
  21. 前記セグメント時間長に対するものである前記変動は、セグメント提示時間が前記変動の時間範囲にわたる前記セグメント時間長よりも大きくまたは小さくなり得るような前記時間範囲である、請求項14に記載のクライアントデバイス。
JP2014528652A 2011-08-31 2012-08-31 適応httpストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法 Expired - Fee Related JP6054398B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201161529656P 2011-08-31 2011-08-31
US61/529,656 2011-08-31
US13/545,697 US9253233B2 (en) 2011-08-31 2012-07-10 Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US13/545,697 2012-07-10
PCT/US2012/053394 WO2013033565A1 (en) 2011-08-31 2012-08-31 Switch signaling methods providing improved switching between representations for adaptive http streaming

Publications (2)

Publication Number Publication Date
JP2014529970A true JP2014529970A (ja) 2014-11-13
JP6054398B2 JP6054398B2 (ja) 2016-12-27

Family

ID=46852386

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2014528652A Expired - Fee Related JP6054398B2 (ja) 2011-08-31 2012-08-31 適応httpストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法

Country Status (6)

Country Link
US (1) US9253233B2 (ja)
EP (1) EP2752025A1 (ja)
JP (1) JP6054398B2 (ja)
KR (1) KR101575740B1 (ja)
CN (1) CN103858440B (ja)
WO (1) WO2013033565A1 (ja)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2019523600A (ja) * 2016-07-28 2019-08-22 クゥアルコム・インコーポレイテッドQualcomm Incorporated メディアストリーミングのためのセグメントチャンクの検索およびアクセス
JP2019537897A (ja) * 2016-11-10 2019-12-26 テレフオンアクチーボラゲット エルエム エリクソン(パブル) 配信性能を改善するためのリソースセグメント化
JP2021145343A (ja) * 2016-02-16 2021-09-24 フラウンホッファー−ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー.ファオ 効率的な適応ストリーミング
JP2022524871A (ja) * 2019-03-14 2022-05-10 ノキア テクノロジーズ オサケユイチア メディアコンテンツにおけるレイトバインディングのための方法および装置
JP2023505474A (ja) * 2019-12-03 2023-02-09 華為技術有限公司 Httpリクエスト伝送方法及びデバイス

Families Citing this family (150)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6307487B1 (en) 1998-09-23 2001-10-23 Digital Fountain, Inc. Information additive code generator and decoder for communication systems
US7068729B2 (en) 2001-12-21 2006-06-27 Digital Fountain, Inc. Multi-stage code generator and decoder for communication systems
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
KR101143282B1 (ko) 2002-10-05 2012-05-08 디지털 파운튼, 인크. 연쇄 반응 코드의 체계적 인코딩 및 디코딩
JP4773356B2 (ja) * 2003-10-06 2011-09-14 デジタル ファウンテン, インコーポレイテッド 単一の送信機または多数の送信機を有する通信システムのためのエラー訂正マルチステージ符号生成器および復号器
EP1743431A4 (en) 2004-05-07 2007-05-02 Digital Fountain Inc SYSTEM FOR DOWNLOADING AND RECORDING AND CONTINUOUS READING OF FILES
WO2006020826A2 (en) * 2004-08-11 2006-02-23 Digital Fountain, Inc. Method and apparatus for fast encoding of data symbols according to half-weight codes
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
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
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
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
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
US8335873B2 (en) * 2006-09-14 2012-12-18 Opentv, Inc. Method and systems for data transmission
US11303684B2 (en) 2006-09-14 2022-04-12 Opentv, Inc. Methods and systems for data transmission
CN101802797B (zh) 2007-09-12 2013-07-17 数字方敦股份有限公司 生成和传达源标识信息以实现可靠的通信
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
WO2011132883A2 (ko) * 2010-04-19 2011-10-27 엘지전자 주식회사 인터넷 기반 컨텐츠 송수신 방법 및 그를 이용한 송수신 장치
US9485546B2 (en) 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
US8938619B2 (en) 2010-12-29 2015-01-20 Adobe Systems Incorporated System and method for decrypting content samples including distinct encryption chains
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US9264508B2 (en) 2011-08-19 2016-02-16 Time Warner Cable Enterprises Llc Apparatus and methods for reduced switching delays in a content distribution network
US9843844B2 (en) 2011-10-05 2017-12-12 Qualcomm Incorporated Network streaming of media data
WO2013058684A1 (en) * 2011-10-17 2013-04-25 Telefonaktiebolaget L M Ericsson (Publ) Method for adaptive streaming, local storing and post-storing quality increase of a content file
KR101922552B1 (ko) * 2011-12-06 2018-11-29 삼성전자주식회사 멀티미디어 컨텐트 전송 시스템에서 적응적 스트리밍을 이용한 트래픽 제어 방법 및 장치
US9930379B2 (en) 2012-01-31 2018-03-27 Comcast Cable Communications, Llc System and method for data stream fragmentation
WO2013138894A1 (en) * 2012-03-21 2013-09-26 Irdeto Canada Corporation Method and system for chain transformation
US9294226B2 (en) 2012-03-26 2016-03-22 Qualcomm Incorporated Universal object delivery and template-based file delivery
US9438883B2 (en) * 2012-04-09 2016-09-06 Intel Corporation Quality of experience reporting for combined unicast-multicast/broadcast streaming of media content
EP2834984B1 (en) * 2012-04-27 2016-03-30 Huawei Technologies Co., Ltd. Support for short cryptoperiods in template mode
BR112014032829A2 (pt) * 2012-06-28 2018-05-15 Ericsson Ab método e sistema para inserção de anúncio em entrega de mídia ao vivo over the top
KR101629748B1 (ko) 2012-07-09 2016-06-13 후아웨이 테크놀러지 컴퍼니 리미티드 Dash 클라이언트 행위 프레임워크 및 세션 관리의 실현
US9998764B2 (en) * 2012-07-09 2018-06-12 Vid Scale, Inc. Codec architecture for multiple layer video coding
US9813740B2 (en) * 2012-08-24 2017-11-07 Google Inc. Method and apparatus for streaming multimedia data with access point positioning information
CN103702237A (zh) * 2012-09-28 2014-04-02 北京大学 Http流媒体的速率自适方法及装置
FR2996715A1 (fr) * 2012-10-09 2014-04-11 France Telecom Heritage de parametres d'identifiant universel de ressource (uri)
US9883011B2 (en) * 2012-10-12 2018-01-30 Canon Kabushiki Kaisha Method and corresponding device for streaming video data
US9762938B2 (en) 2012-10-26 2017-09-12 Intel Corporation Multimedia adaptation based on video orientation
EP2912851B1 (en) 2012-10-26 2020-04-22 Intel Corporation Streaming with coordination of video orientation (cvo)
US9357239B2 (en) * 2012-11-16 2016-05-31 Adobe Systems Incorporated Converting live streaming content to video-on-demand streaming content
US8868964B2 (en) * 2012-11-20 2014-10-21 Adobe Systems Incorporated Method and apparatus for supporting failover for live streaming video
CN103873926B (zh) * 2012-12-13 2017-03-22 腾讯科技(深圳)有限公司 下载并播放媒体文件的方法及系统
US20150172340A1 (en) * 2013-01-11 2015-06-18 Telefonaktiebolaget L M Ericsson (Publ) Technique for Operating Client and Server Devices in a Broadcast Communication Network
WO2014113604A1 (en) * 2013-01-16 2014-07-24 Huawei Technologies Co., Ltd. Url parameter insertion and addition in adaptive streaming
EP2896189B1 (en) * 2013-01-16 2016-09-14 Huawei Technologies Co., Ltd. Storing and transmitting content for downloading and streaming
US9258289B2 (en) * 2013-04-29 2016-02-09 Arbor Networks Authentication of IP source addresses
FR3005820B1 (fr) * 2013-05-17 2015-05-29 Envivio France Procede de gestion de listes de lecture personnalisees du type comprenant un gabarit d'uri et une liste d'identifiants de segments.
US9722852B2 (en) 2013-05-24 2017-08-01 Cisco Technology, Inc. On-demand encapsulating of timed metadata in a network environment
JP2015012305A (ja) * 2013-06-26 2015-01-19 ソニー株式会社 コンテンツ供給装置、コンテンツ供給方法、プログラム、端末装置、およびコンテンツ供給システム
US9814037B2 (en) * 2013-06-28 2017-11-07 Intel Corporation Method for efficient channel estimation and beamforming in FDD system by exploiting uplink-downlink correspondence
JP6149562B2 (ja) * 2013-07-12 2017-06-21 富士通株式会社 ストリーム配信システム、ストリーム作成装置、ストリーム配信方法およびストリーム作成方法
BR112016000427B1 (pt) * 2013-07-17 2023-05-09 Sony Corporation Dispositivo, método e sistema de suprimento de conteúdo, e, dispositivo terminal
JP6498882B2 (ja) 2013-07-22 2019-04-10 パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカPanasonic Intellectual Property Corporation of America 蓄積方法、再生方法、蓄積装置、および再生装置
FR3009161B1 (fr) * 2013-07-24 2015-09-11 Expway Procede de synchronisation lors du traitement par un lecteur multimedia d'un contenu multimedia transmis par un service mbms
US8718445B1 (en) 2013-09-03 2014-05-06 Penthera Partners, Inc. Commercials on mobile devices
US9444856B2 (en) 2013-09-25 2016-09-13 Ericsson Ab System and method for managing adjacent channels in an adaptive streaming environment
US20150089073A1 (en) * 2013-09-25 2015-03-26 Ericsson Television Inc System and method for effectuating fast channel change in an adpative streaming environment
US9244916B2 (en) * 2013-10-01 2016-01-26 Penthera Partners, Inc. Downloading media objects
TWI595777B (zh) * 2013-10-02 2017-08-11 杜比實驗室特許公司 透過hdmi發送顯示管理元數據
US9270721B2 (en) * 2013-10-08 2016-02-23 Qualcomm Incorporated Switching between adaptation sets during media streaming
US10116943B2 (en) * 2013-10-16 2018-10-30 Nvidia Corporation Adaptive video compression for latency control
KR101766696B1 (ko) * 2013-10-25 2017-08-09 후아웨이 테크놀러지 컴퍼니 리미티드 적응 스트리밍에서의 레프리젠테이션 연계
US9621613B1 (en) * 2013-11-05 2017-04-11 Visualon, Inc. Bitrate adaptation transitioning using key frames
CN105900434A (zh) * 2013-11-27 2016-08-24 交互数字专利控股公司 媒体呈现描述
US11657109B2 (en) 2013-11-28 2023-05-23 Patrick Faulwetter Platform device for providing quantitative collective knowledge
CN105874486B (zh) * 2013-11-28 2020-10-27 帕特里克·弗尔韦特 用于提供定性的集群知识的平台设备
GB2521845B (en) * 2014-01-03 2021-07-07 British Broadcasting Corp Content delivery
US9210207B2 (en) * 2014-02-13 2015-12-08 Ericsson Ab Time-sensitive content manipulation in adaptive streaming buffer
US20150261753A1 (en) * 2014-03-13 2015-09-17 Verance Corporation Metadata acquisition using embedded codes
US10504200B2 (en) 2014-03-13 2019-12-10 Verance Corporation Metadata acquisition using embedded watermarks
KR101731770B1 (ko) 2014-03-13 2017-04-28 베란스 코오포레이션 임베디드 코드를 사용한 양방향 콘텐츠 획득
US9350484B2 (en) 2014-03-18 2016-05-24 Qualcomm Incorporated Transport accelerator implementing selective utilization of redundant encoded content data functionality
US9596281B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing request manager and connection manager functionality
US9794311B2 (en) 2014-03-18 2017-10-17 Qualcomm Incorporated Transport accelerator implementing extended transmission control functionality
US9596323B2 (en) 2014-03-18 2017-03-14 Qualcomm Incorporated Transport accelerator implementing client side transmission functionality
US9860612B2 (en) * 2014-04-10 2018-01-02 Wowza Media Systems, LLC Manifest generation and segment packetization
CN105100887A (zh) * 2014-05-15 2015-11-25 中兴通讯股份有限公司 节目播放控制方法及装置
US20150350622A1 (en) * 2014-05-30 2015-12-03 Apple Inc. Packed i-frames
CN105594219B (zh) * 2014-07-31 2019-08-20 Lg 电子株式会社 用于广播信号的发射/接收处理的设备和方法
EP3183882A4 (en) 2014-08-20 2018-07-04 Verance Corporation Content management based on dither-like watermark embedding
US9596285B2 (en) * 2014-09-11 2017-03-14 Harman International Industries, Incorporated Methods and systems for AVB networks
US9986007B2 (en) * 2014-09-23 2018-05-29 Futurewei Technologies, Inc. Ownership identification, signaling, and handling of content components in streaming media
US10187680B2 (en) * 2014-11-11 2019-01-22 Cisco Technology, Inc. Adaptive bit rate system architectures using named domain networking
US10735293B2 (en) * 2014-11-27 2020-08-04 Cellos Software Ltd Method and network monitoring device for estimating web page download time on a user device
WO2016100916A1 (en) 2014-12-18 2016-06-23 Verance Corporation Service signaling recovery for multimedia content using embedded watermarks
KR102326282B1 (ko) 2015-02-09 2021-11-15 한국전자통신연구원 대역폭에 적응적인 대쉬 기반 컨텐츠 제공 장치 및 방법
US10270823B2 (en) * 2015-02-10 2019-04-23 Qualcomm Incorporated Low latency video streaming
EP3062474B1 (en) * 2015-02-24 2018-09-26 Alcatel-Lucent España, S.A. Method, device, computer program product and storage medium for distributing file requests in adaptive streaming systems
US10659507B2 (en) * 2015-03-02 2020-05-19 Qualcomm Incorporated Indication for partial segment
KR102269929B1 (ko) * 2015-03-04 2021-06-28 주식회사 알티캐스트 영상 서비스 제공 방법, 사용자 단말기 및 컴퓨터 프로그램
CN106034262B (zh) * 2015-03-13 2021-01-22 中兴通讯股份有限公司 自适应流媒体处理方法及装置
US9883221B1 (en) 2015-03-25 2018-01-30 Concurrent Computer Corporation System and method for optimizing real-time video-on-demand recording in a content delivery network
WO2016155800A1 (en) * 2015-03-31 2016-10-06 Irdeto B.V. Accessing content
US9973562B2 (en) 2015-04-17 2018-05-15 Microsoft Technology Licensing, Llc Split processing of encoded video in streaming segments
US20160308934A1 (en) * 2015-04-20 2016-10-20 Qualcomm Incorporated Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast
CN104869477A (zh) * 2015-05-14 2015-08-26 无锡天脉聚源传媒科技有限公司 一种视频分段播放的方法及装置
US11057446B2 (en) * 2015-05-14 2021-07-06 Bright Data Ltd. System and method for streaming content from multiple servers
GB2538997A (en) * 2015-06-03 2016-12-07 Nokia Technologies Oy A method, an apparatus, a computer program for video coding
DE112015006733T5 (de) * 2015-08-27 2018-04-19 Intel IP Corporation Angabe der TDD-Uplink- und Downlinkkonfigurationen
US10027733B2 (en) * 2015-09-11 2018-07-17 YipTV, Inc. Method and apparatus for viewing and filtering media content
US10152080B2 (en) * 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
US10158682B2 (en) 2015-09-23 2018-12-18 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
CN105898392A (zh) * 2015-11-24 2016-08-24 乐视云计算有限公司 在线直播视频播放器及方法
US11017022B2 (en) * 2016-01-28 2021-05-25 Subply Solutions Ltd. Method and system for providing audio content
US10652594B2 (en) 2016-07-07 2020-05-12 Time Warner Cable Enterprises Llc Apparatus and methods for presentation of key frames in encrypted content
CN106303562B (zh) * 2016-09-20 2019-03-01 天津大学 基于pi控制的多视点视频自适应传输控制算法
CN107888993B (zh) * 2016-09-30 2020-11-06 华为技术有限公司 一种视频数据的处理方法及装置
US20180109577A1 (en) * 2016-10-13 2018-04-19 Sharp Laboratories Of America, Inc. Systems and methods for enabling communications associated with digital media distribution
US10642917B2 (en) * 2016-11-14 2020-05-05 Triton Us Vp Acquisition Co. Method and device for sharing segmented video content across multiple manifests
US10666707B2 (en) * 2017-01-11 2020-05-26 Microsoft Technology Licensing, Llc Nonconsecutive file downloading
US10225603B2 (en) * 2017-03-13 2019-03-05 Wipro Limited Methods and systems for rendering multimedia content on a user device
CN108668179B (zh) * 2017-03-27 2021-05-14 华为技术有限公司 媒体索引文件的传输方法及相关设备
US10499066B2 (en) * 2017-04-14 2019-12-03 Nokia Technologies Oy Method and apparatus for improving efficiency of content delivery based on consumption data relative to spatial data
US10873775B2 (en) * 2017-06-12 2020-12-22 Netflix, Inc. Staggered key frame video encoding
CN107426629B (zh) * 2017-06-19 2020-06-23 网宿科技股份有限公司 一种流媒体文件处理方法及直播系统
US10652166B2 (en) * 2017-06-27 2020-05-12 Cisco Technology, Inc. Non-real time adaptive bitrate recording scheduler
US10958948B2 (en) * 2017-08-29 2021-03-23 Charter Communications Operating, Llc Apparatus and methods for latency reduction in digital content switching operations
US10939142B2 (en) 2018-02-27 2021-03-02 Charter Communications Operating, Llc Apparatus and methods for content storage, distribution and security within a content distribution network
US11146852B2 (en) 2018-05-11 2021-10-12 Qualcomm Incorporated Signaling missing sections of media data for network streaming in a segment
WO2019236296A1 (en) 2018-06-07 2019-12-12 Sony Corporation Network controlled uplink media transmission for a collaborative media production in network capacity constrained scenarios
FR3082386A1 (fr) * 2018-06-08 2019-12-13 Orange Adaptation de debit d'une session de communication en voix sur ip
WO2020040940A1 (en) 2018-08-20 2020-02-27 Sony Corporation Method and system for utilizing network conditions feedback for improving quality of a collaborative media production
WO2020040939A1 (en) 2018-08-20 2020-02-27 Sony Corporation Method and system for utilizing event specific priority in a network controlled uplink media transmission for a collaborative media production
CN115460184A (zh) 2018-09-17 2022-12-09 谷歌有限责任公司 用于传递无清单流媒体内容的方法、系统和介质
CN109274696A (zh) * 2018-09-20 2019-01-25 青岛海信电器股份有限公司 基于dash协议的流媒体播放方法及装置
US10986387B1 (en) 2018-09-26 2021-04-20 Amazon Technologies, Inc. Content management for a distributed cache of a wireless mesh network
US11089103B1 (en) * 2018-09-26 2021-08-10 Amazon Technologies, Inc. Content management in a distributed cache of a wireless mesh network
JP6485935B1 (ja) * 2018-10-18 2019-03-20 ベルフェイス株式会社 オンラインコミュニケーションのレビューシステム、方法、及びコンピュータプログラム
US11356715B2 (en) * 2018-12-28 2022-06-07 Tencent America LLC Dynamic shortening of advertisement duration during live streaming
US11176269B2 (en) * 2019-03-08 2021-11-16 International Business Machines Corporation Access control of specific encrypted data segment
JP7287454B2 (ja) * 2019-03-11 2023-06-06 ソニーグループ株式会社 情報処理装置、再生処理装置、情報処理方法及び再生処理方法
US11956845B2 (en) 2019-07-22 2024-04-09 Nokia Technologies Oy Transmission of segments of information
US11564018B2 (en) 2019-10-02 2023-01-24 Qualcomm Incorporated Random access at resync points of dash segments
US11128688B2 (en) * 2019-10-16 2021-09-21 Disney Enterprises, Inc. Transcoder conditioning for segment fluidity
CN110995788B (zh) * 2019-11-13 2022-02-22 广州辰河质检技术有限公司 一种http服务器断点续传上传文件存储的实现方法
US11228796B2 (en) * 2020-01-07 2022-01-18 Tencent America LLC Pattern addressing for session-based dash operations
KR102287429B1 (ko) * 2020-02-03 2021-08-06 주식회사 엘지유플러스 스트리밍 서비스를 통한 동영상 출력 방법 및 장치
US11722741B2 (en) 2021-02-08 2023-08-08 Verance Corporation System and method for tracking content timeline in the presence of playback rate changes
US11531660B2 (en) * 2021-04-20 2022-12-20 Cisco Technology, Inc. Analyzing data module versions for aliases and backwards compatibility
US11799700B1 (en) * 2022-08-31 2023-10-24 Qualcomm Incorporated Decoding multi-level coded (MLC) systems

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009528002A (ja) * 2006-02-21 2009-07-30 クゥアルコム・インコーポレイテッド マルチメディアアプリケーションにおける高速同調
WO2011038013A2 (en) * 2009-09-22 2011-03-31 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
JP2011087103A (ja) * 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
WO2011070552A1 (en) * 2009-12-11 2011-06-16 Nokia Corporation Apparatus and methods for describing and timing representations in streaming media files
WO2011102792A1 (en) * 2010-02-19 2011-08-25 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for adaption in http streaming

Family Cites Families (549)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3909721A (en) 1972-01-31 1975-09-30 Signatron Signal processing system
US4365338A (en) 1980-06-27 1982-12-21 Harris Corporation Technique for high rate digital transmission over a dynamic dispersive channel
US4965825A (en) 1981-11-03 1990-10-23 The Personalized Mass Media Corporation Signal processing apparatus and methods
US4589112A (en) 1984-01-26 1986-05-13 International Business Machines Corporation System for multiple error detection with single and double bit error correction
US4901319A (en) 1988-03-18 1990-02-13 General Electric Company Transmission system with adaptive interleaving
GB8815978D0 (en) 1988-07-05 1988-08-10 British Telecomm Method & apparatus for encoding decoding & transmitting data in compressed form
US5136592A (en) 1989-06-28 1992-08-04 Digital Equipment Corporation Error detection and correction system for long burst errors
US7594250B2 (en) 1992-04-02 2009-09-22 Debey Henry C Method and system of program transmission optimization using a redundant transmission sequence
US5701582A (en) 1989-08-23 1997-12-23 Delta Beta Pty. Ltd. Method and apparatus for efficient transmissions of programs
US5421031A (en) 1989-08-23 1995-05-30 Delta Beta Pty. Ltd. Program transmission optimisation
US5329369A (en) 1990-06-01 1994-07-12 Thomson Consumer Electronics, Inc. Asymmetric picture compression
US5455823A (en) 1990-11-06 1995-10-03 Radio Satellite Corporation Integrated communications terminal
US5164963A (en) 1990-11-07 1992-11-17 At&T Bell Laboratories Coding for digital transmission
US5465318A (en) 1991-03-28 1995-11-07 Kurzweil Applied Intelligence, Inc. Method for generating a speech recognition model for a non-vocabulary utterance
US5379297A (en) 1992-04-09 1995-01-03 Network Equipment Technologies, Inc. Concurrent multi-channel segmentation and reassembly processors for asynchronous transfer mode
EP0543070A1 (en) 1991-11-21 1993-05-26 International Business Machines Corporation Coding system and method using quaternary codes
US5371532A (en) 1992-05-15 1994-12-06 Bell Communications Research, Inc. Communications architecture and method for distributing information services
US5425050A (en) 1992-10-23 1995-06-13 Massachusetts Institute Of Technology Television transmission system using spread spectrum and orthogonal frequency-division multiplex
US5372532A (en) 1993-01-26 1994-12-13 Robertson, Jr.; George W. Swivel head cap connector
EP0613249A1 (en) 1993-02-12 1994-08-31 Altera Corporation Custom look-up table with reduced number of architecture bits
DE4316297C1 (de) 1993-05-14 1994-04-07 Fraunhofer Ges Forschung Frequenzanalyseverfahren
AU665716B2 (en) 1993-07-05 1996-01-11 Mitsubishi Denki Kabushiki Kaisha A transmitter for encoding error correction codes and a receiver for decoding error correction codes on a transmission frame
US5590405A (en) 1993-10-29 1996-12-31 Lucent Technologies Inc. Communication technique employing variable information transmission
JP2576776B2 (ja) 1993-11-10 1997-01-29 日本電気株式会社 パケット伝送方法・パケット伝送装置
US5517508A (en) 1994-01-26 1996-05-14 Sony Corporation Method and apparatus for detection and error correction of packetized digital data
CA2140850C (en) 1994-02-24 1999-09-21 Howard Paul Katseff Networked system for display of multimedia presentations
US5566208A (en) 1994-03-17 1996-10-15 Philips Electronics North America Corp. Encoder buffer having an effective size which varies automatically with the channel bit-rate
US5432787A (en) 1994-03-24 1995-07-11 Loral Aerospace Corporation Packet data transmission system with adaptive data recovery method
US5757415A (en) 1994-05-26 1998-05-26 Sony Corporation On-demand data transmission by dividing input data into blocks and each block into sub-blocks such that the sub-blocks are re-arranged for storage to data storage means
US5802394A (en) 1994-06-06 1998-09-01 Starlight Networks, Inc. Method for accessing one or more streams in a video storage system using multiple queues and maintaining continuity thereof
US5739864A (en) 1994-08-24 1998-04-14 Macrovision Corporation Apparatus for inserting blanked formatted fingerprint data (source ID, time/date) in to a video signal
US5568614A (en) 1994-07-29 1996-10-22 International Business Machines Corporation Data streaming between peer subsystems of a computer system
US5668948A (en) 1994-09-08 1997-09-16 International Business Machines Corporation Media streamer with control node enabling same isochronous streams to appear simultaneously at output ports or different streams to appear simultaneously at output ports
US5926205A (en) 1994-10-19 1999-07-20 Imedia Corporation Method and apparatus for encoding and formatting data representing a video program to provide multiple overlapping presentations of the video program
US5659614A (en) 1994-11-28 1997-08-19 Bailey, Iii; John E. Method and system for creating and storing a backup copy of file data stored on a computer
US5617541A (en) 1994-12-21 1997-04-01 International Computer Science Institute System for packetizing data encoded corresponding to priority levels where reconstructed data corresponds to fractionalized priority level and received fractionalized packets
JP3614907B2 (ja) 1994-12-28 2005-01-26 株式会社東芝 データ再送制御方法及びデータ再送制御システム
CA2219379A1 (en) 1995-04-27 1996-10-31 Cadathur V. Chakravarthy High integrity transport for time critical multimedia networking applications
US5835165A (en) 1995-06-07 1998-11-10 Lsi Logic Corporation Reduction of false locking code words in concatenated decoders
US5805825A (en) 1995-07-26 1998-09-08 Intel Corporation Method for semi-reliable, unidirectional broadcast information services
US6079041A (en) 1995-08-04 2000-06-20 Sanyo Electric Co., Ltd. Digital modulation circuit and digital demodulation circuit
US5754563A (en) 1995-09-11 1998-05-19 Ecc Technologies, Inc. Byte-parallel system for implementing reed-solomon error-correcting codes
KR0170298B1 (ko) 1995-10-10 1999-04-15 김광호 디지탈 비디오 테이프의 기록 방법
US5751336A (en) 1995-10-12 1998-05-12 International Business Machines Corporation Permutation based pyramid block transmission scheme for broadcasting in video-on-demand storage systems
JP3305183B2 (ja) 1996-01-12 2002-07-22 株式会社東芝 ディジタル放送受信端末装置
US6012159A (en) 1996-01-17 2000-01-04 Kencast, Inc. Method and system for error-free data transfer
US5852565A (en) 1996-01-30 1998-12-22 Demografx Temporal and resolution layering in advanced television
US5936659A (en) 1996-01-31 1999-08-10 Telcordia Technologies, Inc. Method for video delivery using pyramid broadcasting
US5903775A (en) 1996-06-06 1999-05-11 International Business Machines Corporation Method for the sequential transmission of compressed video information at varying data rates
US5745504A (en) 1996-06-25 1998-04-28 Telefonaktiebolaget Lm Ericsson Bit error resilient variable length code
US5940863A (en) 1996-07-26 1999-08-17 Zenith Electronics Corporation Apparatus for de-rotating and de-interleaving data including plural memory devices and plural modulo memory address generators
US5936949A (en) 1996-09-05 1999-08-10 Netro Corporation Wireless ATM metropolitan area network
KR100261706B1 (ko) 1996-12-17 2000-07-15 가나이 쓰도무 디지탈방송신호의 수신장치와 수신 및 기록재생장치
US6044485A (en) 1997-01-03 2000-03-28 Ericsson Inc. Transmitter method and transmission system using adaptive coding based on channel characteristics
US6141053A (en) 1997-01-03 2000-10-31 Saukkonen; Jukka I. Method of optimizing bandwidth for transmitting compressed video data streams
US6011590A (en) 1997-01-03 2000-01-04 Ncr Corporation Method of transmitting compressed information to minimize buffer space
EP0854650A3 (en) 1997-01-17 2001-05-02 NOKIA TECHNOLOGY GmbH Method for addressing a service in digital video broadcasting
US5983383A (en) 1997-01-17 1999-11-09 Qualcom Incorporated Method and apparatus for transmitting and receiving concatenated code data
US5946357A (en) 1997-01-17 1999-08-31 Telefonaktiebolaget L M Ericsson Apparatus, and associated method, for transmitting and receiving a multi-stage, encoded and interleaved digital communication signal
US6014706A (en) 1997-01-30 2000-01-11 Microsoft Corporation Methods and apparatus for implementing control functions in a streamed video display system
KR20000075982A (ko) 1997-03-07 2000-12-26 다카노 야스아키 디지탈 방송 수신기 및 디스플레이 장치
US6115420A (en) 1997-03-14 2000-09-05 Microsoft Corporation Digital video signal encoder and encoding method
DE19716011A1 (de) 1997-04-17 1998-10-22 Abb Research Ltd Verfahren und Vorrichtung zur Informationsübertragung über Stromversorgungsleitungen
US6226259B1 (en) 1997-04-29 2001-05-01 Canon Kabushiki Kaisha Device and method for transmitting information device and method for processing information
US5970098A (en) 1997-05-02 1999-10-19 Globespan Technologies, Inc. Multilevel encoder
US5844636A (en) 1997-05-13 1998-12-01 Hughes Electronics Corporation Method and apparatus for receiving and recording digital packet data
JPH1141211A (ja) 1997-05-19 1999-02-12 Sanyo Electric Co Ltd ディジタル変調回路と変調方法、ディジタル復調回路と復調方法
JP4110593B2 (ja) 1997-05-19 2008-07-02 ソニー株式会社 信号記録方法及び信号記録装置
EP0933768A4 (en) 1997-05-19 2000-10-04 Sanyo Electric Co DIGITAL MODULATION AND DEMODULATION
US6128649A (en) 1997-06-02 2000-10-03 Nortel Networks Limited Dynamic selection of media streams for display
US6081907A (en) 1997-06-09 2000-06-27 Microsoft Corporation Data delivery system and method for delivering data and redundant information over a unidirectional network
US5917852A (en) 1997-06-11 1999-06-29 L-3 Communications Corporation Data scrambling system and method and communications system incorporating same
KR100240869B1 (ko) 1997-06-25 2000-01-15 윤종용 이중 다이버서티 시스템을 위한 데이터 전송 방법
US6175944B1 (en) 1997-07-15 2001-01-16 Lucent Technologies Inc. Methods and apparatus for packetizing data for transmission through an erasure broadcast channel
US5933056A (en) 1997-07-15 1999-08-03 Exar Corporation Single pole current mode common-mode feedback circuit
US6047069A (en) 1997-07-17 2000-04-04 Hewlett-Packard Company Method and apparatus for preserving error correction capabilities during data encryption/decryption
US6904110B2 (en) 1997-07-31 2005-06-07 Francois Trans Channel equalization system and method
US6178536B1 (en) 1997-08-14 2001-01-23 International Business Machines Corporation Coding scheme for file backup and systems based thereon
FR2767940A1 (fr) 1997-08-29 1999-02-26 Canon Kk Procedes et dispositifs de codage et de decodage et appareils les mettant en oeuvre
EP0903955A1 (en) 1997-09-04 1999-03-24 STMicroelectronics S.r.l. Modular architecture PET decoder for ATM networks
US6088330A (en) 1997-09-09 2000-07-11 Bruck; Joshua Reliable array of distributed computing nodes
US6134596A (en) 1997-09-18 2000-10-17 Microsoft Corporation Continuous media file server system and method for scheduling network resources to play multiple files having different data transmission rates
US6272658B1 (en) 1997-10-27 2001-08-07 Kencast, Inc. Method and system for reliable broadcasting of data files and streams
US6081909A (en) 1997-11-06 2000-06-27 Digital Equipment Corporation Irregularly graphed encoding technique
US6195777B1 (en) 1997-11-06 2001-02-27 Compaq Computer Corporation Loss resilient code with double heavy tailed series of redundant layers
US6073250A (en) 1997-11-06 2000-06-06 Luby; Michael G. Loss resilient decoding technique
US6163870A (en) 1997-11-06 2000-12-19 Compaq Computer Corporation Message encoding with irregular graphing
US6081918A (en) 1997-11-06 2000-06-27 Spielman; Daniel A. Loss resilient code with cascading series of redundant layers
JP3472115B2 (ja) 1997-11-25 2003-12-02 Kddi株式会社 マルチチャンネルを用いるビデオデータ伝送方法及びその装置
US5870412A (en) 1997-12-12 1999-02-09 3Com Corporation Forward error correction system for packet based real time media
US6243846B1 (en) 1997-12-12 2001-06-05 3Com Corporation Forward error correction system for packet based data and real time media, using cross-wise parity calculation
US6849803B1 (en) 1998-01-15 2005-02-01 Arlington Industries, Inc. Electrical connector
US6097320A (en) 1998-01-20 2000-08-01 Silicon Systems, Inc. Encoder/decoder system with suppressed error propagation
US6226301B1 (en) 1998-02-19 2001-05-01 Nokia Mobile Phones Ltd Method and apparatus for segmentation and assembly of data frames for retransmission in a telecommunications system
US6141788A (en) 1998-03-13 2000-10-31 Lucent Technologies Inc. Method and apparatus for forward error correction in packet networks
US6278716B1 (en) 1998-03-23 2001-08-21 University Of Massachusetts Multicast with proactive forward error correction
EP1075762A1 (en) 1998-04-02 2001-02-14 Sarnoff Corporation Bursty data transmission of compressed video data
US6185265B1 (en) 1998-04-07 2001-02-06 Worldspace Management Corp. System for time division multiplexing broadcast channels with R-1/2 or R-3/4 convolutional coding for satellite transmission via on-board baseband processing payload or transparent payload
US6067646A (en) 1998-04-17 2000-05-23 Ameritech Corporation Method and system for adaptive interleaving
US6018359A (en) 1998-04-24 2000-01-25 Massachusetts Institute Of Technology System and method for multicast video-on-demand delivery system
US6445717B1 (en) 1998-05-01 2002-09-03 Niwot Networks, Inc. System for recovering lost information in a data stream
US6421387B1 (en) 1998-05-15 2002-07-16 North Carolina State University Methods and systems for forward error correction based loss recovery for interactive video transmission
US6937618B1 (en) 1998-05-20 2005-08-30 Sony Corporation Separating device and method and signal receiving device and method
US6333926B1 (en) 1998-08-11 2001-12-25 Nortel Networks Limited Multiple user CDMA basestation modem
EP1110344A1 (en) 1998-09-04 2001-06-27 AT&T Corp. Combined channel coding and space-block coding in a multi-antenna arrangement
US6415326B1 (en) 1998-09-15 2002-07-02 Microsoft Corporation Timeline correlation between multiple timeline-altered media streams
US6320520B1 (en) 1998-09-23 2001-11-20 Digital Fountain Information additive group code generator and decoder for communications systems
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
US7243285B2 (en) 1998-09-23 2007-07-10 Digital Fountain, Inc. Systems and methods for broadcasting information additive codes
US6704370B1 (en) 1998-10-09 2004-03-09 Nortel Networks Limited Interleaving methodology and apparatus for CDMA
IT1303735B1 (it) 1998-11-11 2001-02-23 Falorni Italia Farmaceutici S Acidi ialuronici reticolati e loro usi medici.
US6408128B1 (en) 1998-11-12 2002-06-18 Max Abecassis Replaying with supplementary information a segment of a video
US7157314B2 (en) 1998-11-16 2007-01-02 Sandisk Corporation Vertically stacked field programmable nonvolatile memory and method of fabrication
JP2000151426A (ja) 1998-11-17 2000-05-30 Toshiba Corp インターリーブ・デインターリーブ回路
US6166544A (en) 1998-11-25 2000-12-26 General Electric Company MR imaging system with interactive image contrast control
US6876623B1 (en) 1998-12-02 2005-04-05 Agere Systems Inc. Tuning scheme for code division multiplex broadcasting system
WO2000036783A1 (en) 1998-12-03 2000-06-22 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Apparatus and method for transmitting information and apparatus and method for receiving information
US6637031B1 (en) 1998-12-04 2003-10-21 Microsoft Corporation Multimedia presentation latency minimization
US6496980B1 (en) 1998-12-07 2002-12-17 Intel Corporation Method of providing replay on demand for streaming digital multimedia
US6223324B1 (en) 1999-01-05 2001-04-24 Agere Systems Guardian Corp. Multiple program unequal error protection for digital audio broadcasting and other applications
JP3926499B2 (ja) 1999-01-22 2007-06-06 株式会社日立国際電気 畳み込み符号軟判定復号方式の受信装置
US6618451B1 (en) 1999-02-13 2003-09-09 Altocom Inc Efficient reduced state maximum likelihood sequence estimator
US6041001A (en) 1999-02-25 2000-03-21 Lexar Media, Inc. Method of increasing data reliability of a flash memory device without compromising compatibility
EP1083496A1 (en) 1999-03-03 2001-03-14 Sony Corporation Transmitter, receiver, transmitter/receiver system, transmission method and reception method
US6785323B1 (en) 1999-11-22 2004-08-31 Ipr Licensing, Inc. Variable rate coding for forward link
US6466698B1 (en) 1999-03-25 2002-10-15 The United States Of America As Represented By The Secretary Of The Navy Efficient embedded image and video compression system using lifted wavelets
US6535920B1 (en) 1999-04-06 2003-03-18 Microsoft Corporation Analyzing, indexing and seeking of streaming information
JP3256517B2 (ja) 1999-04-06 2002-02-12 インターナショナル・ビジネス・マシーンズ・コーポレーション 符号化回路、回路、パリティ生成方法及び記憶媒体
US6609223B1 (en) 1999-04-06 2003-08-19 Kencast, Inc. Method for packet-level fec encoding, in which on a source packet-by-source packet basis, the error correction contributions of a source packet to a plurality of wildcard packets are computed, and the source packet is transmitted thereafter
US6804202B1 (en) 1999-04-08 2004-10-12 Lg Information And Communications, Ltd. Radio protocol for mobile communication system and method
US7885340B2 (en) 1999-04-27 2011-02-08 Realnetworks, Inc. System and method for generating multiple synchronized encoded representations of media data
FI113124B (fi) 1999-04-29 2004-02-27 Nokia Corp Tiedonsiirto
MY130203A (en) 1999-05-06 2007-06-29 Sony Corp Methods and apparatus for data processing, methods and apparatus for data reproducing and recording media
KR100416996B1 (ko) 1999-05-10 2004-02-05 삼성전자주식회사 이동 통신시스템에서 라디오링크프로토콜에 따른 가변 길이의 데이터 송수신 장치 및 방법
US6154452A (en) 1999-05-26 2000-11-28 Xm Satellite Radio Inc. Method and apparatus for continuous cross-channel interleaving
AU5140200A (en) 1999-05-26 2000-12-18 Enounce, Incorporated Method and apparatus for controlling time-scale modification during multi-media broadcasts
US6229824B1 (en) 1999-05-26 2001-05-08 Xm Satellite Radio Inc. Method and apparatus for concatenated convolutional endcoding and interleaving
JP2000353969A (ja) 1999-06-11 2000-12-19 Sony Corp デジタル音声放送の受信機
US6577599B1 (en) 1999-06-30 2003-06-10 Sun Microsystems, Inc. Small-scale reliable multicasting
IL141800A0 (en) 1999-07-06 2002-03-10 Samsung Electronics Co Ltd Rate matching device and method for a data communication system
US6643332B1 (en) 1999-07-09 2003-11-04 Lsi Logic Corporation Method and apparatus for multi-level coding of digital signals
JP3451221B2 (ja) 1999-07-22 2003-09-29 日本無線株式会社 誤り訂正符号化装置、方法及び媒体、並びに誤り訂正符号復号装置、方法及び媒体
US6279072B1 (en) 1999-07-22 2001-08-21 Micron Technology, Inc. Reconfigurable memory with selectable error correction storage
US6453440B1 (en) 1999-08-04 2002-09-17 Sun Microsystems, Inc. System and method for detecting double-bit errors and for correcting errors due to component failures
JP2001060934A (ja) 1999-08-20 2001-03-06 Matsushita Electric Ind Co Ltd Ofdm通信装置
US6430233B1 (en) 1999-08-30 2002-08-06 Hughes Electronics Corporation Single-LNB satellite data receiver
US6332163B1 (en) 1999-09-01 2001-12-18 Accenture, Llp Method for providing communication services over a computer network system
JP4284774B2 (ja) 1999-09-07 2009-06-24 ソニー株式会社 送信装置、受信装置、通信システム、送信方法及び通信方法
JP2001094625A (ja) 1999-09-27 2001-04-06 Canon Inc データ通信装置、データ通信方法及び記憶媒体
EP1131930B1 (en) 1999-09-27 2007-01-17 Koninklijke Philips Electronics N.V. Partitioning of file for emulating streaming
US7529806B1 (en) 1999-11-04 2009-05-05 Koninklijke Philips Electronics N.V. Partitioning of MP3 content file for emulating streaming
US20050160272A1 (en) 1999-10-28 2005-07-21 Timecertain, Llc System and method for providing trusted time in content of digital data files
US6523147B1 (en) 1999-11-11 2003-02-18 Ibiquity Digital Corporation Method and apparatus for forward error correction coding for an AM in-band on-channel digital audio broadcasting system
US6678855B1 (en) 1999-12-02 2004-01-13 Microsoft Corporation Selecting K in a data transmission carousel using (N,K) forward error correction
US6748441B1 (en) 1999-12-02 2004-06-08 Microsoft Corporation Data carousel receiving and caching
US6798791B1 (en) 1999-12-16 2004-09-28 Agere Systems Inc Cluster frame synchronization scheme for a satellite digital audio radio system
US6487692B1 (en) 1999-12-21 2002-11-26 Lsi Logic Corporation Reed-Solomon decoder
US6965636B1 (en) 2000-02-01 2005-11-15 2Wire, Inc. System and method for block error correction in packet-based digital communications
US20020009137A1 (en) 2000-02-01 2002-01-24 Nelson John E. Three-dimensional video broadcasting system
US7304990B2 (en) 2000-02-03 2007-12-04 Bandwiz Inc. Method of encoding and transmitting data over a communication medium through division and segmentation
IL140504A0 (en) 2000-02-03 2002-02-10 Bandwiz Inc Broadcast system
WO2001057667A1 (en) 2000-02-03 2001-08-09 Bandwiz, Inc. Data streaming
JP2001251287A (ja) 2000-02-24 2001-09-14 Geneticware Corp Ltd ハードウエア保護内部秘匿鍵及び可変パスコードを利用する機密データ伝送方法
US6765866B1 (en) 2000-02-29 2004-07-20 Mosaid Technologies, Inc. Link aggregation
DE10009443A1 (de) 2000-02-29 2001-08-30 Philips Corp Intellectual Pty Empfänger und Verfahren zum Detektieren und Dekodieren eines DQPSK-modulierten und kanalkodierten Empfangssignals
US6384750B1 (en) 2000-03-23 2002-05-07 Mosaid Technologies, Inc. Multi-stage lookup for translating between signals of different bit lengths
US6510177B1 (en) 2000-03-24 2003-01-21 Microsoft Corporation System and method for layered video coding enhancement
JP2001274776A (ja) 2000-03-24 2001-10-05 Toshiba Corp 情報データ伝送システムとその送信装置及び受信装置
US6851086B2 (en) 2000-03-31 2005-02-01 Ted Szymanski Transmitter, receiver, and coding scheme to increase data rate and decrease bit error rate of an optical data link
US6473010B1 (en) 2000-04-04 2002-10-29 Marvell International, Ltd. Method and apparatus for determining error correction code failure rate for iterative decoding algorithms
US8572646B2 (en) 2000-04-07 2013-10-29 Visible World Inc. System and method for simultaneous broadcast for personalized messages
JP4640723B2 (ja) 2000-04-08 2011-03-02 オラクル・アメリカ・インコーポレイテッド 複数クライアントへの単一メディア・トラックのストリーミング
US6631172B1 (en) 2000-05-01 2003-10-07 Lucent Technologies Inc. Efficient list decoding of Reed-Solomon codes for message recovery in the presence of high noise levels
US6742154B1 (en) 2000-05-25 2004-05-25 Ciena Corporation Forward error correction codes for digital optical network optimization
US6694476B1 (en) 2000-06-02 2004-02-17 Vitesse Semiconductor Corporation Reed-solomon encoder and decoder
US6738942B1 (en) 2000-06-02 2004-05-18 Vitesse Semiconductor Corporation Product code based forward error correction system
GB2366159B (en) 2000-08-10 2003-10-08 Mitel Corp Combination reed-solomon and turbo coding
US6834342B2 (en) 2000-08-16 2004-12-21 Eecad, Inc. Method and system for secure communication over unstable public connections
KR100447162B1 (ko) 2000-08-19 2004-09-04 엘지전자 주식회사 래디오 링크 콘트롤(rlc)에서 프로토콜 데이터 유닛(pdu) 정보의 길이 지시자(li) 처리방법
JP2002073625A (ja) 2000-08-24 2002-03-12 Nippon Hoso Kyokai <Nhk> 放送番組に同期した情報提供の方法、サーバ及び媒体
US7340664B2 (en) 2000-09-20 2008-03-04 Lsi Logic Corporation Single engine turbo decoder with single frame size buffer for interleaving/deinterleaving
US6486803B1 (en) 2000-09-22 2002-11-26 Digital Fountain, Inc. On demand encoding with a window
US7151754B1 (en) 2000-09-22 2006-12-19 Lucent Technologies Inc. Complete user datagram protocol (CUDP) for wireless multimedia packet networks using improved packet level forward error correction (FEC) coding
US7031257B1 (en) 2000-09-22 2006-04-18 Lucent Technologies Inc. Radio link protocol (RLP)/point-to-point protocol (PPP) design that passes corrupted data and error location information among layers in a wireless data transmission protocol
US7490344B2 (en) 2000-09-29 2009-02-10 Visible World, Inc. System and method for seamless switching
US6411223B1 (en) 2000-10-18 2002-06-25 Digital Fountain, Inc. Generating high weight encoding symbols using a basis
US7613183B1 (en) 2000-10-31 2009-11-03 Foundry Networks, Inc. System and method for router data aggregation and delivery
US6694478B1 (en) 2000-11-07 2004-02-17 Agere Systems Inc. Low delay channel codes for correcting bursts of lost packets
US6732325B1 (en) 2000-11-08 2004-05-04 Digeo, Inc. Error-correction with limited working storage
US20020133247A1 (en) 2000-11-11 2002-09-19 Smith Robert D. System and method for seamlessly switching between media streams
US7072971B2 (en) 2000-11-13 2006-07-04 Digital Foundation, Inc. Scheduling of multiple files for serving on a server
US7240358B2 (en) 2000-12-08 2007-07-03 Digital Fountain, Inc. Methods and apparatus for scheduling, serving, receiving media-on demand for clients, servers arranged according to constraints on resources
ES2342357T3 (es) 2000-12-15 2010-07-06 British Telecommunications Public Limited Company Transmision y recepcion de material de audio y/o video.
CA2429827C (en) 2000-12-15 2009-08-25 British Telecommunications Public Limited Company Transmission and reception of audio and/or video material
US6850736B2 (en) 2000-12-21 2005-02-01 Tropian, Inc. Method and apparatus for reception quality indication in wireless communication
US7143433B1 (en) 2000-12-27 2006-11-28 Infovalve Computing Inc. Video distribution system using dynamic segmenting of video data files
US20020085013A1 (en) 2000-12-29 2002-07-04 Lippincott Louis A. Scan synchronized dual frame buffer graphics subsystem
NO315887B1 (no) 2001-01-04 2003-11-03 Fast Search & Transfer As Fremgangsmater ved overforing og soking av videoinformasjon
US20080059532A1 (en) 2001-01-18 2008-03-06 Kazmi Syed N Method and system for managing digital content, including streaming media
DE10103387A1 (de) 2001-01-26 2002-08-01 Thorsten Nordhoff Windkraftanlage mit einer Einrichtung zur Hindernisbefeuerung bzw. Nachtkennzeichnung
FI118830B (fi) 2001-02-08 2008-03-31 Nokia Corp Tietovirran toisto
US6868083B2 (en) 2001-02-16 2005-03-15 Hewlett-Packard Development Company, L.P. Method and system for packet communication employing path diversity
US20020129159A1 (en) 2001-03-09 2002-09-12 Michael Luby Multi-output packet server with independent streams
KR100464360B1 (ko) 2001-03-30 2005-01-03 삼성전자주식회사 고속 패킷 데이터 전송 이동통신시스템에서 패킷 데이터채널에 대한 효율적인 에너지 분배 장치 및 방법
US20020143953A1 (en) 2001-04-03 2002-10-03 International Business Machines Corporation Automatic affinity within networks performing workload balancing
US6785836B2 (en) 2001-04-11 2004-08-31 Broadcom Corporation In-place data transformation for fault-tolerant disk storage systems
US6820221B2 (en) 2001-04-13 2004-11-16 Hewlett-Packard Development Company, L.P. System and method for detecting process and network failures in a distributed system
US7010052B2 (en) 2001-04-16 2006-03-07 The Ohio University Apparatus and method of CTCM encoding and decoding for a digital communication system
US7035468B2 (en) 2001-04-20 2006-04-25 Front Porch Digital Inc. Methods and apparatus for archiving, indexing and accessing audio and video data
US20020191116A1 (en) 2001-04-24 2002-12-19 Damien Kessler System and data format for providing seamless stream switching in a digital video recorder
US6497479B1 (en) 2001-04-27 2002-12-24 Hewlett-Packard Company Higher organic inks with good reliability and drytime
US7962482B2 (en) 2001-05-16 2011-06-14 Pandora Media, Inc. Methods and systems for utilizing contextual feedback to generate and modify playlists
US6633856B2 (en) 2001-06-15 2003-10-14 Flarion Technologies, Inc. Methods and apparatus for decoding LDPC codes
US7076478B2 (en) 2001-06-26 2006-07-11 Microsoft Corporation Wrapper playlists on streaming media services
US6745364B2 (en) 2001-06-28 2004-06-01 Microsoft Corporation Negotiated/dynamic error correction for streamed media
JP2003018568A (ja) 2001-06-29 2003-01-17 Matsushita Electric Ind Co Ltd 再生システム、サーバ装置及び再生装置
US6895547B2 (en) 2001-07-11 2005-05-17 International Business Machines Corporation Method and apparatus for low density parity check encoding of data
US6928603B1 (en) 2001-07-19 2005-08-09 Adaptix, Inc. System and method for interference mitigation using adaptive forward error correction in a wireless RF data transmission system
US6961890B2 (en) 2001-08-16 2005-11-01 Hewlett-Packard Development Company, L.P. Dynamic variable-length error correction code
US7110412B2 (en) 2001-09-18 2006-09-19 Sbc Technology Resources, Inc. Method and system to transport high-quality video signals
FI115418B (fi) 2001-09-20 2005-04-29 Oplayo Oy Adaptiivinen mediavirta
US6990624B2 (en) 2001-10-12 2006-01-24 Agere Systems Inc. High speed syndrome-based FEC encoder and decoder and system using same
US7480703B2 (en) 2001-11-09 2009-01-20 Sony Corporation System, method, and computer program product for remotely determining the configuration of a multi-media content user based on response of the user
US7003712B2 (en) 2001-11-29 2006-02-21 Emin Martinian Apparatus and method for adaptive, multimode decoding
US7363354B2 (en) 2001-11-29 2008-04-22 Nokia Corporation System and method for identifying and accessing network services
JP2003174489A (ja) 2001-12-05 2003-06-20 Ntt Docomo Inc ストリーミング配信装置、ストリーミング配信方法
FI114527B (fi) 2002-01-23 2004-10-29 Nokia Corp Kuvakehysten ryhmittely videokoodauksessa
EP1670259A3 (en) 2002-01-23 2010-03-03 Nokia Corporation Grouping of image frames in video coding
WO2003065683A1 (en) 2002-01-30 2003-08-07 Koninklijke Philips Electronics N.V. Streaming multimedia data over a network having a variable bandwidth
US7249291B2 (en) 2002-02-15 2007-07-24 Digital Fountain, Inc. System and method for reliably communicating the content of a live data stream
JP4126928B2 (ja) 2002-02-28 2008-07-30 日本電気株式会社 プロキシサーバ及びプロキシ制御プログラム
JP4116470B2 (ja) 2002-03-06 2008-07-09 ヒューレット・パッカード・カンパニー メディア・ストリーミング配信システム
FR2837332A1 (fr) 2002-03-15 2003-09-19 Thomson Licensing Sa Dispositif et procede d'insertion de codes de correction d'erreurs et de reconstitution de flux de donnees, et produits correspondants
RU2321953C2 (ru) 2002-04-15 2008-04-10 Нокиа Корпорейшн Логический уровень rlp станции связи
US6677864B2 (en) 2002-04-18 2004-01-13 Telefonaktiebolaget L.M. Ericsson Method for multicast over wireless networks
JP3689063B2 (ja) 2002-04-19 2005-08-31 松下電器産業株式会社 データ受信装置及びデータ配信システム
JP3629008B2 (ja) 2002-04-19 2005-03-16 松下電器産業株式会社 データ受信装置及びデータ配信システム
KR100693200B1 (ko) 2002-04-25 2007-03-13 샤프 가부시키가이샤 화상 부호화 장치, 화상 복호 장치, 기록 매체 및 화상기록 장치
US20030204602A1 (en) 2002-04-26 2003-10-30 Hudson Michael D. Mediated multi-source peer content delivery network architecture
US7177658B2 (en) 2002-05-06 2007-02-13 Qualcomm, Incorporated Multi-media broadcast and multicast service (MBMS) in a wireless communications system
US7200388B2 (en) 2002-05-31 2007-04-03 Nokia Corporation Fragmented delivery of multimedia
EP2306652B1 (en) 2002-06-11 2014-03-19 Digital Fountain, Inc. Decoding of chain reaction codes through inactivation
WO2003105484A1 (en) 2002-06-11 2003-12-18 Telefonaktiebolaget L M Ericsson (Publ) Generation of mixed media streams
US9240810B2 (en) 2002-06-11 2016-01-19 Digital Fountain, Inc. Systems and processes for decoding chain reaction codes through inactivation
US6956875B2 (en) 2002-06-19 2005-10-18 Atlinks Usa, Inc. Technique for communicating variable bit rate data over a constant bit rate link
JP4154569B2 (ja) 2002-07-10 2008-09-24 日本電気株式会社 画像圧縮伸長装置
JP4120461B2 (ja) 2002-07-12 2008-07-16 住友電気工業株式会社 伝送データ生成方法及び伝送データ生成装置
EP3177020B1 (en) 2002-07-16 2023-04-19 Nokia Technologies Oy A method for random access and gradual picture refresh in video coding
AU2003252347A1 (en) 2002-07-31 2004-03-11 Sharp Kabushiki Kaisha Data communication device, its intermittent communication method, program describing its method, and recording medium on which program is recorded
JP2004070712A (ja) 2002-08-07 2004-03-04 Nippon Telegr & Teleph Corp <Ntt> データ配信方法,データ配信システム,分割配信データ受信方法,分割配信データ受信装置および分割配信データ受信プログラム
AU2002319335B2 (en) 2002-08-13 2008-12-04 Nokia Corporation Symbol interleaving
US6985459B2 (en) 2002-08-21 2006-01-10 Qualcomm Incorporated Early transmission and playout of packets in wireless communication systems
JP3836858B2 (ja) 2002-09-27 2006-10-25 富士通株式会社 データ配信方法、システム、伝送方法及びプログラム
JP3534742B1 (ja) 2002-10-03 2004-06-07 株式会社エヌ・ティ・ティ・ドコモ 動画像復号方法、動画像復号装置、及び動画像復号プログラム
KR101143282B1 (ko) 2002-10-05 2012-05-08 디지털 파운튼, 인크. 연쇄 반응 코드의 체계적 인코딩 및 디코딩
JP2004135013A (ja) 2002-10-10 2004-04-30 Matsushita Electric Ind Co Ltd 伝送装置及び伝送方法
FI116816B (fi) 2002-10-14 2006-02-28 Nokia Corp Median suoratoisto
US8320301B2 (en) 2002-10-25 2012-11-27 Qualcomm Incorporated MIMO WLAN system
US7289451B2 (en) 2002-10-25 2007-10-30 Telefonaktiebolaget Lm Ericsson (Publ) Delay trading between communication links
KR101021071B1 (ko) 2002-10-30 2011-03-14 코닌클리케 필립스 일렉트로닉스 엔.브이. 적응 순방향 에러 제어 구조
JP2004165922A (ja) 2002-11-12 2004-06-10 Sony Corp 情報処理装置および方法、並びにプログラム
EP1563689B1 (en) 2002-11-18 2008-10-01 British Telecommunications Public Limited Company Transmission of video
GB0226872D0 (en) 2002-11-18 2002-12-24 British Telecomm Video transmission
KR100502609B1 (ko) 2002-11-21 2005-07-20 한국전자통신연구원 Ldpc 코드를 이용한 부호화기 및 부호화 방법
US7086718B2 (en) 2002-11-23 2006-08-08 Silverbrook Research Pty Ltd Thermal ink jet printhead with high nozzle areal density
JP2004192140A (ja) 2002-12-09 2004-07-08 Sony Corp データ通信システム、データ送信装置、データ受信装置、および方法、並びにコンピュータ・プログラム
JP2004193992A (ja) 2002-12-11 2004-07-08 Sony Corp 情報処理システム、情報処理装置および方法、記録媒体、並びにプログラム
US8135073B2 (en) 2002-12-19 2012-03-13 Trident Microsystems (Far East) Ltd Enhancing video images depending on prior image enhancements
US7164882B2 (en) 2002-12-24 2007-01-16 Poltorak Alexander I Apparatus and method for facilitating a purchase using information provided on a media playing device
WO2004068715A2 (en) 2003-01-29 2004-08-12 Digital Fountain, Inc. Systems and processes for fast encoding of hamming codes
US7756002B2 (en) 2003-01-30 2010-07-13 Texas Instruments Incorporated Time-frequency interleaved orthogonal frequency division multiplexing ultra wide band physical layer
US7525994B2 (en) 2003-01-30 2009-04-28 Avaya Inc. Packet data flow identification for multiplexing
US7231404B2 (en) 2003-01-31 2007-06-12 Nokia Corporation Datacast file transmission with meta-data retention
US7062272B2 (en) 2003-02-18 2006-06-13 Qualcomm Incorporated Method and apparatus to track count of broadcast content recipients in a wireless telephone network
EP1455504B1 (en) 2003-03-07 2014-11-12 Samsung Electronics Co., Ltd. Apparatus and method for processing audio signal and computer readable recording medium storing computer program for the method
JP4173755B2 (ja) 2003-03-24 2008-10-29 富士通株式会社 データ伝送サーバ
US7610487B2 (en) 2003-03-27 2009-10-27 Microsoft Corporation Human input security codes
US7266147B2 (en) 2003-03-31 2007-09-04 Sharp Laboratories Of America, Inc. Hypothetical reference decoder
US7526565B2 (en) * 2003-04-03 2009-04-28 International Business Machines Corporation Multiple description hinting and switching for adaptive media services
US7408486B2 (en) 2003-04-21 2008-08-05 Qbit Corporation System and method for using a microlet-based modem
JP2004343701A (ja) 2003-04-21 2004-12-02 Matsushita Electric Ind Co Ltd データ受信再生装置、データ受信再生方法及びデータ受信再生処理プログラム
US20050041736A1 (en) 2003-05-07 2005-02-24 Bernie Butler-Smith Stereoscopic television signal processing method, transmission system and viewer enhancements
KR100492567B1 (ko) 2003-05-13 2005-06-03 엘지전자 주식회사 이동통신 시스템의 http 기반 비디오 스트리밍 장치및 방법
US7113773B2 (en) 2003-05-16 2006-09-26 Qualcomm Incorporated Reliable reception of broadcast/multicast content
JP2004348824A (ja) 2003-05-21 2004-12-09 Toshiba Corp Eccエンコード方法、eccエンコード装置
US7277697B2 (en) 2003-05-23 2007-10-02 Adesh Desai Method and system for establishing a teleconference over a telephony network
JP2004362099A (ja) 2003-06-03 2004-12-24 Sony Corp サーバ装置、情報処理装置、および情報処理方法、並びにコンピュータ・プログラム
RU2312390C2 (ru) 2003-06-07 2007-12-10 Самсунг Электроникс Ко., Лтд. Устройство и способ организации и интерпретации мультимедийных данных на записываемом носителе информации
KR101003413B1 (ko) 2003-06-12 2010-12-23 엘지전자 주식회사 이동통신 단말기의 전송데이터 압축/해제 방법
US7603689B2 (en) 2003-06-13 2009-10-13 Microsoft Corporation Fast start-up for digital video streams
RU2265960C2 (ru) 2003-06-16 2005-12-10 Федеральное государственное унитарное предприятие "Калужский научно-исследовательский институт телемеханических устройств" Способ передачи информации с использованием адаптивного перемежения
US7391717B2 (en) 2003-06-30 2008-06-24 Microsoft Corporation Streaming of variable bit rate multimedia content
US20050004997A1 (en) 2003-07-01 2005-01-06 Nokia Corporation Progressive downloading of timed multimedia content
US8149939B2 (en) 2003-07-07 2012-04-03 Samsung Electronics Co., Ltd. System of robust DTV signal transmissions that legacy DTV receivers will disregard
US7254754B2 (en) 2003-07-14 2007-08-07 International Business Machines Corporation Raid 3+3
KR100532450B1 (ko) 2003-07-16 2005-11-30 삼성전자주식회사 에러에 대해 강인한 특성을 가지는 데이터 기록 방법,이에 적합한 데이터 재생 방법, 그리고 이에 적합한 장치들
US20050028067A1 (en) 2003-07-31 2005-02-03 Weirauch Charles R. Data with multiple sets of error correction codes
CN1864359B (zh) 2003-08-21 2012-04-18 高通股份有限公司 用于广播和组播内容跨小区边界和/或不同传送方案之间的无缝传送的方法和相关装置
US8694869B2 (en) 2003-08-21 2014-04-08 QUALCIMM Incorporated Methods for forward error correction coding above a radio link control layer and related apparatus
IL157886A0 (en) 2003-09-11 2009-02-11 Bamboo Mediacasting Ltd Secure multicast transmission
IL157885A0 (en) 2003-09-11 2004-03-28 Bamboo Mediacasting Ltd Iterative forward error correction
JP4183586B2 (ja) 2003-09-12 2008-11-19 三洋電機株式会社 映像表示装置
WO2005029237A2 (en) 2003-09-15 2005-03-31 Digital Networks North America, Inc. Method and system for adaptive transcoding and transrating in a video network
KR100608715B1 (ko) 2003-09-27 2006-08-04 엘지전자 주식회사 QoS보장형 멀티미디어 스트리밍 서비스 시스템 및 방법
DE60307852D1 (de) 2003-09-30 2006-10-05 Ericsson Telefon Ab L M In-place Entschachtelung von Daten
US7559004B1 (en) 2003-10-01 2009-07-07 Sandisk Corporation Dynamic redundant area configuration in a non-volatile memory system
JP4773356B2 (ja) 2003-10-06 2011-09-14 デジタル ファウンテン, インコーポレイテッド 単一の送信機または多数の送信機を有する通信システムのためのエラー訂正マルチステージ符号生成器および復号器
US7614071B2 (en) 2003-10-10 2009-11-03 Microsoft Corporation Architecture for distributed sending of media data
US7516232B2 (en) 2003-10-10 2009-04-07 Microsoft Corporation Media organization for distributed sending of media data
ATE479142T1 (de) 2003-10-14 2010-09-15 Panasonic Corp Datenumsetzer
US7650036B2 (en) 2003-10-16 2010-01-19 Sharp Laboratories Of America, Inc. System and method for three-dimensional video coding
US7168030B2 (en) 2003-10-17 2007-01-23 Telefonaktiebolaget Lm Ericsson (Publ) Turbo code decoder with parity information update
US8132215B2 (en) 2003-10-27 2012-03-06 Panasonic Corporation Apparatus for receiving broadcast signal
JP2005136546A (ja) 2003-10-29 2005-05-26 Sony Corp 送信装置および方法、記録媒体、並びにプログラム
EP1528702B1 (en) 2003-11-03 2008-01-23 Broadcom Corporation FEC (forward error correction) decoding with dynamic parameters
US20050102371A1 (en) 2003-11-07 2005-05-12 Emre Aksu Streaming from a server to a client
EP1706946A4 (en) 2003-12-01 2006-10-18 Digital Fountain Inc PROCESSING DATA AGAINST ERASURES USING SUB-SYMBOL CODES
US7428669B2 (en) 2003-12-07 2008-09-23 Adaptive Spectrum And Signal Alignment, Inc. Adaptive FEC codeword management
US7574706B2 (en) 2003-12-15 2009-08-11 Microsoft Corporation System and method for managing and communicating software updates
US7590118B2 (en) 2003-12-23 2009-09-15 Agere Systems Inc. Frame aggregation format
JP4536383B2 (ja) 2004-01-16 2010-09-01 株式会社エヌ・ティ・ティ・ドコモ データ受信装置およびデータ受信方法
KR100770902B1 (ko) 2004-01-20 2007-10-26 삼성전자주식회사 고속 무선 데이터 시스템을 위한 가변 부호율의 오류 정정부호 생성 및 복호 장치 및 방법
KR100834750B1 (ko) 2004-01-29 2008-06-05 삼성전자주식회사 엔코더 단에서 스케일러빌리티를 제공하는 스케일러블비디오 코딩 장치 및 방법
JP4321284B2 (ja) 2004-02-03 2009-08-26 株式会社デンソー ストリーミングデータ送信装置、および情報配信システム
US7599294B2 (en) 2004-02-13 2009-10-06 Nokia Corporation Identification and re-transmission of missing parts
KR100586883B1 (ko) 2004-03-04 2006-06-08 삼성전자주식회사 비디오 스트리밍 서비스를 위한 비디오 코딩방법, 프리디코딩방법, 비디오 디코딩방법, 및 이를 위한 장치와, 이미지 필터링방법
KR100596705B1 (ko) 2004-03-04 2006-07-04 삼성전자주식회사 비디오 스트리밍 서비스를 위한 비디오 코딩 방법과 비디오 인코딩 시스템, 및 비디오 디코딩 방법과 비디오 디코딩 시스템
US7609653B2 (en) 2004-03-08 2009-10-27 Microsoft Corporation Resolving partial media topologies
WO2005094020A1 (en) 2004-03-19 2005-10-06 Telefonaktiebolaget Lm Ericsson (Publ) Higher layer packet framing using rlp
US7240236B2 (en) 2004-03-23 2007-07-03 Archivas, Inc. Fixed content distributed data storage using permutation ring encoding
JP4433287B2 (ja) 2004-03-25 2010-03-17 ソニー株式会社 受信装置および方法、並びにプログラム
US8842175B2 (en) 2004-03-26 2014-09-23 Broadcom Corporation Anticipatory video signal reception and processing
US20050216472A1 (en) 2004-03-29 2005-09-29 David Leon Efficient multicast/broadcast distribution of formatted data
US20080243918A1 (en) 2004-03-30 2008-10-02 Koninklijke Philips Electronic, N.V. System and Method For Supporting Improved Trick Mode Performance For Disc Based Multimedia Content
TW200534875A (en) 2004-04-23 2005-11-01 Lonza Ag Personal care compositions and concentrates for making the same
FR2869744A1 (fr) 2004-04-29 2005-11-04 Thomson Licensing Sa Methode de transmission de paquets de donnees numeriques et appareil implementant la methode
EP1743431A4 (en) 2004-05-07 2007-05-02 Digital Fountain Inc SYSTEM FOR DOWNLOADING AND RECORDING AND CONTINUOUS READING OF FILES
US7633970B2 (en) 2004-05-07 2009-12-15 Agere Systems Inc. MAC header compression for use with frame aggregation
US20050254575A1 (en) 2004-05-12 2005-11-17 Nokia Corporation Multiple interoperability points for scalable media coding and transmission
US20060037057A1 (en) 2004-05-24 2006-02-16 Sharp Laboratories Of America, Inc. Method and system of enabling trick play modes using HTTP GET
US8331445B2 (en) 2004-06-01 2012-12-11 Qualcomm Incorporated Method, apparatus, and system for enhancing robustness of predictive video codecs using a side-channel based on distributed source coding techniques
US20070110074A1 (en) 2004-06-04 2007-05-17 Bob Bradley System and Method for Synchronizing Media Presentation at Multiple Recipients
US7139660B2 (en) 2004-07-14 2006-11-21 General Motors Corporation System and method for changing motor vehicle personalization settings
US8112531B2 (en) 2004-07-14 2012-02-07 Nokia Corporation Grouping of session objects
US8544043B2 (en) 2004-07-21 2013-09-24 Qualcomm Incorporated Methods and apparatus for providing content information to content servers
US7409626B1 (en) 2004-07-28 2008-08-05 Ikanos Communications Inc Method and apparatus for determining codeword interleaver parameters
US7590922B2 (en) 2004-07-30 2009-09-15 Nokia Corporation Point-to-point repair request mechanism for point-to-multipoint transmission systems
US7376150B2 (en) 2004-07-30 2008-05-20 Nokia Corporation Point-to-point repair response mechanism for point-to-multipoint transmission systems
US7930184B2 (en) 2004-08-04 2011-04-19 Dts, Inc. Multi-channel audio coding/decoding of random access points and transients
WO2006020826A2 (en) 2004-08-11 2006-02-23 Digital Fountain, Inc. Method and apparatus for fast encoding of data symbols according to half-weight codes
JP4405875B2 (ja) 2004-08-25 2010-01-27 富士通株式会社 エラー訂正用データの生成方法及び生成装置並びに生成プログラム及び同プログラムを格納したコンピュータ読み取り可能な記録媒体
JP2006074335A (ja) 2004-09-01 2006-03-16 Nippon Telegr & Teleph Corp <Ntt> 伝送方法、伝送システム及び伝送装置
JP4576936B2 (ja) 2004-09-02 2010-11-10 ソニー株式会社 情報処理装置、情報記録媒体、コンテンツ管理システム、およびデータ処理方法、並びにコンピュータ・プログラム
JP2006115104A (ja) 2004-10-13 2006-04-27 Daiichikosho Co Ltd 高能率符号化された時系列情報をパケット化してリアルタイム・ストリーミング送信し受信再生する方法および装置
US7529984B2 (en) 2004-11-16 2009-05-05 Infineon Technologies Ag Seamless change of depth of a general convolutional interleaver during transmission without loss of data
US7751324B2 (en) 2004-11-19 2010-07-06 Nokia Corporation Packet stream arrangement in multimedia transmission
WO2006057938A2 (en) 2004-11-22 2006-06-01 Thomson Research Funding Corporation Method and apparatus for channel change in dsl system
CN101061659B (zh) 2004-12-02 2015-04-29 汤姆逊许可公司 自适应前向纠错的方法和设备
KR20060065482A (ko) 2004-12-10 2006-06-14 마이크로소프트 코포레이션 스트리밍 미디어 데이터의 코딩 비트 레이트의 제어 시스템및 프로세스
JP2006174032A (ja) 2004-12-15 2006-06-29 Sanyo Electric Co Ltd 画像データ伝送システム、画像データ受信装置及び画像データ送信装置
JP2006174045A (ja) 2004-12-15 2006-06-29 Ntt Communications Kk 画像配信装置、プログラム及び方法
US7398454B2 (en) 2004-12-21 2008-07-08 Tyco Telecommunications (Us) Inc. System and method for forward error correction decoding using soft information
JP4391409B2 (ja) 2004-12-24 2009-12-24 株式会社第一興商 高能率符号化された時系列情報をリアルタイム・ストリーミング送信し受信再生する方法と受信装置
JP2008530835A (ja) 2005-02-08 2008-08-07 テレフオンアクチーボラゲット エル エム エリクソン(パブル) パケット交換ネットワーク上のオンデマンドマルチチャネルストリーミングセッション
US7925097B2 (en) 2005-02-18 2011-04-12 Sanyo Electric Co., Ltd. Image display method, image coding apparatus, and image decoding apparatus
US7822139B2 (en) 2005-03-02 2010-10-26 Rohde & Schwarz Gmbh & Co. Kg Apparatus, systems, methods and computer products for providing a virtual enhanced training sequence
WO2006096104A1 (en) 2005-03-07 2006-09-14 Telefonaktiebolaget Lm Ericsson (Publ) Multimedia channel switching
US8028322B2 (en) 2005-03-14 2011-09-27 Time Warner Cable Inc. Method and apparatus for network content download and recording
US7219289B2 (en) 2005-03-15 2007-05-15 Tandberg Data Corporation Multiply redundant raid system and XOR-efficient method and apparatus for implementing the same
US7418649B2 (en) 2005-03-15 2008-08-26 Microsoft Corporation Efficient implementation of reed-solomon erasure resilient codes in high-rate applications
US7450064B2 (en) 2005-03-22 2008-11-11 Qualcomm, Incorporated Methods and systems for deriving seed position of a subscriber station in support of unassisted GPS-type position determination in a wireless communication system
JP4487028B2 (ja) 2005-03-31 2010-06-23 ブラザー工業株式会社 配信速度制御装置、配信システム、配信速度制御方法、及び配信速度制御用プログラム
US7715842B2 (en) 2005-04-09 2010-05-11 Lg Electronics Inc. Supporting handover of mobile terminal
WO2006108917A1 (en) 2005-04-13 2006-10-19 Nokia Corporation Coding, storage and signalling of scalability information
JP4515319B2 (ja) 2005-04-27 2010-07-28 株式会社日立製作所 コンピュータシステム
US7961700B2 (en) 2005-04-28 2011-06-14 Qualcomm Incorporated Multi-carrier operation in data transmission systems
US8683066B2 (en) 2007-08-06 2014-03-25 DISH Digital L.L.C. Apparatus, system, and method for multi-bitrate content streaming
JP2006319743A (ja) 2005-05-13 2006-11-24 Toshiba Corp 受信装置
US8228994B2 (en) 2005-05-20 2012-07-24 Microsoft Corporation Multi-view video coding based on temporal and view decomposition
CN101180831A (zh) 2005-05-24 2008-05-14 诺基亚公司 用于数字广播中分级传输/接收的方法和装置
US7676735B2 (en) 2005-06-10 2010-03-09 Digital Fountain Inc. Forward error-correcting (FEC) coding and streaming
US7644335B2 (en) 2005-06-10 2010-01-05 Qualcomm Incorporated In-place transformations with applications to encoding and decoding various classes of codes
JP2007013436A (ja) 2005-06-29 2007-01-18 Toshiba Corp 符号化ストリーム再生装置
JP2007013675A (ja) 2005-06-30 2007-01-18 Sanyo Electric Co Ltd ストリーミング配信システム及びサーバ
US20070006274A1 (en) 2005-06-30 2007-01-04 Toni Paila Transmission and reception of session packets
US7725593B2 (en) 2005-07-15 2010-05-25 Sony Corporation Scalable video coding (SVC) file format
US20070022215A1 (en) 2005-07-19 2007-01-25 Singer David W Method and apparatus for media data transmission
EP1755248B1 (en) 2005-08-19 2011-06-22 Hewlett-Packard Development Company, L.P. Indication of lost segments across layer boundaries
JP3996631B2 (ja) 2005-09-09 2007-10-24 松下電器産業株式会社 画像処理方法、画像記録方法、画像処理装置および画像ファイルフォーマット
US7924913B2 (en) 2005-09-15 2011-04-12 Microsoft Corporation Non-realtime data transcoding of multimedia content
US20070067480A1 (en) 2005-09-19 2007-03-22 Sharp Laboratories Of America, Inc. Adaptive media playout by server media processing for robust streaming
US8879857B2 (en) 2005-09-27 2014-11-04 Qualcomm Incorporated Redundant data encoding methods and device
US20070078876A1 (en) 2005-09-30 2007-04-05 Yahoo! Inc. Generating a stream of media data containing portions of media files using location tags
US7720062B2 (en) 2005-10-05 2010-05-18 Lg Electronics Inc. Method of processing traffic information and digital broadcasting system
US7164370B1 (en) 2005-10-06 2007-01-16 Analog Devices, Inc. System and method for decoding data compressed in accordance with dictionary-based compression schemes
MY147530A (en) 2005-10-11 2012-12-31 Nokia Corp System and method for efficient scalable stream adaptation
CN100442858C (zh) 2005-10-11 2008-12-10 华为技术有限公司 分组网络中多媒体实时传输的唇同步方法及其装置
US7720096B2 (en) 2005-10-13 2010-05-18 Microsoft Corporation RTP payload format for VC-1
MY159176A (en) 2005-10-19 2016-12-30 Thomson Licensing Multi-view video coding using scalable video coding
JP4727401B2 (ja) 2005-12-02 2011-07-20 日本電信電話株式会社 無線マルチキャスト伝送システム、無線送信装置及び無線マルチキャスト伝送方法
FR2894421B1 (fr) 2005-12-07 2008-01-18 Canon Kk Procede et dispositif de decodage d'un flux video code suivant un codage hierarchique
KR100759823B1 (ko) 2005-12-08 2007-09-18 한국전자통신연구원 제로 복귀 신호 발생 장치 및 그 방법
JP4456064B2 (ja) 2005-12-21 2010-04-28 日本電信電話株式会社 パケット送信装置、受信装置、システム、およびプログラム
US20070157267A1 (en) 2005-12-30 2007-07-05 Intel Corporation Techniques to improve time seek operations
WO2007078253A2 (en) 2006-01-05 2007-07-12 Telefonaktiebolaget Lm Ericsson (Publ) Media container file management
US8214516B2 (en) 2006-01-06 2012-07-03 Google Inc. Dynamic media serving infrastructure
TWI432035B (zh) 2006-01-11 2014-03-21 Nokia Corp 可縮放視訊編碼之圖像反向相容聚合技術
JP5199123B2 (ja) 2006-01-12 2013-05-15 エルジー エレクトロニクス インコーポレイティド 多視点ビデオの処理
WO2007086654A1 (en) 2006-01-25 2007-08-02 Lg Electronics Inc. Digital broadcasting system and method of processing data
RU2290768C1 (ru) 2006-01-30 2006-12-27 Общество с ограниченной ответственностью "Трафиклэнд" Система медиавещания в инфраструктуре оператора мобильной связи
US7262719B2 (en) 2006-01-30 2007-08-28 International Business Machines Corporation Fast data stream decoding using apriori information
GB0602314D0 (en) 2006-02-06 2006-03-15 Ericsson Telefon Ab L M Transporting packets
US8990153B2 (en) 2006-02-07 2015-03-24 Dot Hill Systems Corporation Pull data replication model
EP1985022B1 (en) 2006-02-08 2011-06-08 Thomson Licensing Decoding of raptor codes
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
JP2007228205A (ja) 2006-02-23 2007-09-06 Funai Electric Co Ltd ネットワークサーバ
US8320450B2 (en) 2006-03-29 2012-11-27 Vidyo, Inc. System and method for transcoding between scalable and non-scalable video codecs
WO2007127741A2 (en) 2006-04-24 2007-11-08 Sun Microsystems, Inc. Media server system
US20080010153A1 (en) 2006-04-24 2008-01-10 Pugh-O'connor Archie Computer network provided digital content under an advertising and revenue sharing basis, such as music provided via the internet with time-shifted advertisements presented by a client resident application
US7640353B2 (en) 2006-04-27 2009-12-29 Microsoft Corporation Guided random seek support for media streaming
WO2007134196A2 (en) 2006-05-10 2007-11-22 Digital Fountain, Inc. Code generator and decoder using hybrid codes
US7525993B2 (en) 2006-05-24 2009-04-28 Newport Media, Inc. Robust transmission system and method for mobile television applications
US9209934B2 (en) 2006-06-09 2015-12-08 Qualcomm Incorporated Enhanced block-request streaming using cooperative parallel HTTP and forward error correction
TWM302355U (en) 2006-06-09 2006-12-11 Jia-Bau Jeng Fixation and cushion structure of knee joint
US9380096B2 (en) 2006-06-09 2016-06-28 Qualcomm Incorporated Enhanced block-request streaming system for handling low-latency streaming
US20100211690A1 (en) 2009-02-13 2010-08-19 Digital Fountain, Inc. Block partitioning for a data stream
US9178535B2 (en) 2006-06-09 2015-11-03 Digital Fountain, Inc. Dynamic stream interleaving and sub-stream based delivery
US9386064B2 (en) 2006-06-09 2016-07-05 Qualcomm Incorporated Enhanced block-request streaming using URL templates and construction rules
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
JP2008011404A (ja) 2006-06-30 2008-01-17 Toshiba Corp コンテンツ処理装置及びコンテンツ処理方法
JP4392004B2 (ja) 2006-07-03 2009-12-24 インターナショナル・ビジネス・マシーンズ・コーポレーション パケット回復のための符号化および復号化技術
EP2044528A4 (en) 2006-07-20 2013-03-06 Sandisk Technologies Inc CONTENT DISTRIBUTION SYSTEM
US7711797B1 (en) 2006-07-31 2010-05-04 Juniper Networks, Inc. Optimizing batch size for prefetching data over wide area networks
JP4241781B2 (ja) * 2006-08-10 2009-03-18 エプソンイメージングデバイス株式会社 電気光学装置、駆動回路および電子機器
US8209736B2 (en) 2006-08-23 2012-06-26 Mediatek Inc. Systems and methods for managing television (TV) signals
US20080066136A1 (en) 2006-08-24 2008-03-13 International Business Machines Corporation System and method for detecting topic shift boundaries in multimedia streams using joint audio, visual and text cues
WO2008023328A2 (en) 2006-08-24 2008-02-28 Nokia Corporation System and method for indicating track relationships in media files
JP2008109637A (ja) 2006-09-25 2008-05-08 Toshiba Corp 動画像符号化装置及びその方法
US8428013B2 (en) 2006-10-30 2013-04-23 Lg Electronics Inc. Method of performing random access in a wireless communcation system
JP2008118221A (ja) 2006-10-31 2008-05-22 Toshiba Corp 復号装置及び復号方法
WO2008054100A1 (en) 2006-11-01 2008-05-08 Electronics And Telecommunications Research Institute Method and apparatus for decoding metadata used for playing stereoscopic contents
EP2095641A2 (en) 2006-11-14 2009-09-02 QUALCOMM Incorporated Systems and methods for channel switching
US8027328B2 (en) 2006-12-26 2011-09-27 Alcatel Lucent Header compression in a wireless communication network
CN103561278B (zh) 2007-01-05 2017-04-12 索尼克知识产权股份有限公司 包含连续播放的视频分配系统
US20080168516A1 (en) 2007-01-08 2008-07-10 Christopher Lance Flick Facilitating Random Access In Streaming Content
RU2009127603A (ru) 2007-01-09 2011-02-20 Нокиа Корпорейшн (Fi) Способ поддержки контроля версий файлов при исправлении файлов в mbms
US20080172430A1 (en) 2007-01-11 2008-07-17 Andrew Thomas Thorstensen Fragmentation Compression Management
CA2656144A1 (en) 2007-01-11 2008-07-17 Panasonic Corporation Method for trick playing on streamed and encrypted multimedia
KR20080066408A (ko) 2007-01-12 2008-07-16 삼성전자주식회사 3차원 영상 처리 장치 및 방법
EP3041195A1 (en) 2007-01-12 2016-07-06 University-Industry Cooperation Group Of Kyung Hee University Packet format of network abstraction layer unit, and algorithm and apparatus for video encoding and decoding using the format
US7949195B2 (en) 2007-01-16 2011-05-24 Cisco Technology, Inc. Per block breakpoint determining for hybrid variable length coding
US7721003B2 (en) 2007-02-02 2010-05-18 International Business Machines Corporation System and method to synchronize OSGi bundle inventories between an OSGi bundle server and a client
KR101385190B1 (ko) * 2007-02-07 2014-04-15 삼성디스플레이 주식회사 액정 표시 패널 및 이의 제조 방법
US20080192818A1 (en) 2007-02-09 2008-08-14 Dipietro Donald Vincent Systems and methods for securing media
US20080232357A1 (en) 2007-03-19 2008-09-25 Legend Silicon Corp. Ls digital fountain code
JP4838191B2 (ja) 2007-05-08 2011-12-14 シャープ株式会社 ファイル再生装置、ファイル再生方法、ファイル再生を実行させるプログラム及びそのプログラムを記録した記録媒体
US20080278415A1 (en) * 2007-05-09 2008-11-13 Pioneer Corporation Method for driving plasma display panel
JP2008283571A (ja) 2007-05-11 2008-11-20 Ntt Docomo Inc コンテンツ配信装置、コンテンツ配信システム、およびコンテンツ配信方法
US8275002B2 (en) 2007-05-14 2012-09-25 Samsung Electronics Co., Ltd. Broadcasting service transmitting apparatus and method and broadcasting service receiving apparatus and method for effectively accessing broadcasting service
MX2009012392A (es) 2007-05-16 2009-12-01 Thomson Licensing Aparato y metodo para codificar y descodificar señales.
FR2917262A1 (fr) 2007-06-05 2008-12-12 Thomson Licensing Sas Dispositif et procede de codage d'un contenu video sous la forme d'un flux scalable.
US8487982B2 (en) 2007-06-07 2013-07-16 Reald Inc. Stereoplexing for film and video applications
EP2393301A1 (en) 2007-06-11 2011-12-07 Samsung Electronics Co., Ltd. Method and apparatus for generating header information of stereoscopic image
CN101690118B (zh) 2007-06-20 2013-08-28 艾利森电话股份有限公司 用于改进的媒体会话管理的方法和设备
CN101690229A (zh) 2007-06-26 2010-03-31 诺基亚公司 用于指示时间层切换点的系统和方法
US7917702B2 (en) 2007-07-10 2011-03-29 Qualcomm Incorporated Data prefetch throttle
JP2009027598A (ja) 2007-07-23 2009-02-05 Hitachi Ltd 映像配信サーバおよび映像配信方法
US8327403B1 (en) 2007-09-07 2012-12-04 United Video Properties, Inc. Systems and methods for providing remote program ordering on a user device via a web server
CN101802797B (zh) 2007-09-12 2013-07-17 数字方敦股份有限公司 生成和传达源标识信息以实现可靠的通信
US8233532B2 (en) 2007-09-21 2012-07-31 Fraunhofer-Gesellschaft Zur Foerderung Der Angewandten Forschung E.V. Information signal, apparatus and method for encoding an information content, and apparatus and method for error correcting an information signal
US8346959B2 (en) 2007-09-28 2013-01-01 Sharp Laboratories Of America, Inc. Client-controlled adaptive streaming
EP2046044B1 (en) 2007-10-01 2017-01-18 Cabot Communications Ltd A method and apparatus for streaming digital media content and a communication system
JP4975868B2 (ja) 2007-10-09 2012-07-11 サムスン エレクトロニクス カンパニー リミテッド 移動通信システムにおけるmacpduの生成・解析装置及び方法
US8706907B2 (en) 2007-10-19 2014-04-22 Voxer Ip Llc Telecommunication and multimedia management method and apparatus
US8635360B2 (en) 2007-10-19 2014-01-21 Google Inc. Media playback point seeking using data range requests
US20090125636A1 (en) 2007-11-13 2009-05-14 Qiong Li Payload allocation methods for scalable multimedia servers
WO2009065526A1 (en) 2007-11-23 2009-05-28 Media Patents S.L. A process for the on-line distribution of audiovisual contents with advertisements, advertisement management system, digital rights management system and audiovisual content player provided with said systems
WO2009075766A2 (en) 2007-12-05 2009-06-18 Swarmcast, Inc. Dynamic bit rate scaling
JP5385598B2 (ja) 2007-12-17 2014-01-08 キヤノン株式会社 画像処理装置及び画像管理サーバ装置及びそれらの制御方法及びプログラム
US9313245B2 (en) 2007-12-24 2016-04-12 Qualcomm Incorporated Adaptive streaming for on demand wireless services
KR101506217B1 (ko) 2008-01-31 2015-03-26 삼성전자주식회사 스테레오스코픽 영상의 부분 데이터 구간 재생을 위한스테레오스코픽 영상 데이터스트림 생성 방법과 장치, 및스테레오스코픽 영상의 부분 데이터 구간 재생 방법과 장치
EP2086237B1 (en) 2008-02-04 2012-06-27 Alcatel Lucent Method and device for reordering and multiplexing multimedia packets from multimedia streams pertaining to interrelated sessions
US8151174B2 (en) 2008-02-13 2012-04-03 Sunrise IP, LLC Block modulus coding (BMC) systems and methods for block coding with non-binary modulus
US20090219985A1 (en) 2008-02-28 2009-09-03 Vasanth Swaminathan Systems and Methods for Processing Multiple Projections of Video Data in a Single Video File
US7984097B2 (en) 2008-03-18 2011-07-19 Media Patents, S.L. Methods for transmitting multimedia files and advertisements
US8606996B2 (en) 2008-03-31 2013-12-10 Amazon Technologies, Inc. Cache optimization
US20090257508A1 (en) 2008-04-10 2009-10-15 Gaurav Aggarwal Method and system for enabling video trick modes
JP5221753B2 (ja) 2008-04-14 2013-06-26 エルジー エレクトロニクス インコーポレイティド ランダムアクセス手順を行う方法及び装置
US20100049865A1 (en) 2008-04-16 2010-02-25 Nokia Corporation Decoding Order Recovery in Session Multiplexing
WO2009130561A1 (en) 2008-04-21 2009-10-29 Nokia Corporation Method and device for video coding and decoding
JP5847577B2 (ja) 2008-05-07 2016-01-27 デジタル ファウンテン, インコーポレイテッド より低いレベルのパケット構造から導かれる記号識別子を用いた放送チャネル上の高品質ストリーム保護
WO2009140208A2 (en) 2008-05-12 2009-11-19 Swarmcast, Inc. Live media delivery over a packet-based computer network
JP5022301B2 (ja) 2008-05-19 2012-09-12 株式会社エヌ・ティ・ティ・ドコモ プロキシサーバおよび通信中継プログラム、並びに通信中継方法
CN101287107B (zh) 2008-05-29 2010-10-13 腾讯科技(深圳)有限公司 媒体文件的点播方法、系统和设备
US7925774B2 (en) 2008-05-30 2011-04-12 Microsoft Corporation Media streaming using an index file
US20100011274A1 (en) 2008-06-12 2010-01-14 Qualcomm Incorporated Hypothetical fec decoder and signalling for decoding control
US8775566B2 (en) 2008-06-21 2014-07-08 Microsoft Corporation File format for media distribution and presentation
US8387150B2 (en) 2008-06-27 2013-02-26 Microsoft Corporation Segmented media content rights management
US8468426B2 (en) 2008-07-02 2013-06-18 Apple Inc. Multimedia-aware quality-of-service and error correction provisioning
US8539092B2 (en) 2008-07-09 2013-09-17 Apple Inc. Video streaming using multiple channels
US20100153578A1 (en) 2008-07-16 2010-06-17 Nokia Corporation Method and Apparatus for Peer to Peer Streaming
US8638796B2 (en) 2008-08-22 2014-01-28 Cisco Technology, Inc. Re-ordering segments of a large number of segmented service flows
KR101019634B1 (ko) 2008-09-04 2011-03-07 에스케이 텔레콤주식회사 미디어 전송 시스템 및 방법
US8325796B2 (en) 2008-09-11 2012-12-04 Google Inc. System and method for video coding using adaptive segmentation
US8370520B2 (en) 2008-11-24 2013-02-05 Juniper Networks, Inc. Adaptive network content delivery system
US8099473B2 (en) 2008-12-31 2012-01-17 Apple Inc. Variant streams for real-time or near real-time streaming
US8743906B2 (en) 2009-01-23 2014-06-03 Akamai Technologies, Inc. Scalable seamless digital video stream splicing
CN104768031B (zh) 2009-01-26 2018-02-09 汤姆森特许公司 用于视频解码的装置
CN105357533B (zh) 2009-01-29 2018-10-19 杜比实验室特许公司 视频编码方法及视频装置
US9281847B2 (en) 2009-02-27 2016-03-08 Qualcomm Incorporated Mobile reception of digital video broadcasting—terrestrial services
US8909806B2 (en) 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
US8621044B2 (en) 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
WO2010120804A1 (en) 2009-04-13 2010-10-21 Reald Inc. Encoding, decoding, and distributing enhanced resolution stereoscopic video
US9807468B2 (en) 2009-06-16 2017-10-31 Microsoft Technology Licensing, Llc Byte range caching
US8903895B2 (en) 2009-07-22 2014-12-02 Xinlab, Inc. Method of streaming media to heterogeneous client devices
US8355433B2 (en) * 2009-08-18 2013-01-15 Netflix, Inc. Encoding video streams for adaptive video streaming
US9288010B2 (en) 2009-08-19 2016-03-15 Qualcomm Incorporated Universal file delivery methods for providing unequal error protection and bundled file delivery services
US20120151302A1 (en) 2010-12-10 2012-06-14 Qualcomm Incorporated Broadcast multimedia storage and access using page maps when asymmetric memory is used
KR101598247B1 (ko) 2009-09-02 2016-02-26 애플 인크. 무선 시스템들의 mac 패킷 데이터 유닛 구성
US20110096828A1 (en) 2009-09-22 2011-04-28 Qualcomm Incorporated Enhanced block-request streaming using scalable encoding
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
US9438861B2 (en) 2009-10-06 2016-09-06 Microsoft Technology Licensing, Llc Integrating continuous and sparse streaming data
CN107911332B (zh) 2009-11-04 2021-01-08 阿莫泰克有限公司 媒体内容流播的方法、系统和计算机可读介质
KR101786051B1 (ko) 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 제공 방법 및 장치와 데이터 수신 방법 및 장치
KR101786050B1 (ko) 2009-11-13 2017-10-16 삼성전자 주식회사 데이터 전송 방법 및 장치
CN101729857A (zh) 2009-11-24 2010-06-09 中兴通讯股份有限公司 一种接入视频服务的方法及视频播放系统
EP2537318A4 (en) * 2010-02-19 2013-08-14 Ericsson Telefon Ab L M METHOD AND ARRANGEMENT FOR DISPLAY SWITCHING IN AN HTTP STREAMING
JP5071495B2 (ja) 2010-03-04 2012-11-14 ウシオ電機株式会社 光源装置
CA2792925C (en) 2010-03-11 2016-05-24 Electronics And Telecommunications Research Institute Method and apparatus for transceiving data in a mimo system
US20110280311A1 (en) 2010-05-13 2011-11-17 Qualcomm Incorporated One-stream coding for asymmetric stereo video
US9497290B2 (en) 2010-06-14 2016-11-15 Blackberry Limited Media presentation description delta file for HTTP streaming
US8918533B2 (en) 2010-07-13 2014-12-23 Qualcomm Incorporated Video switching for streaming video data
US9185439B2 (en) 2010-07-15 2015-11-10 Qualcomm Incorporated Signaling data for multiplexing video components
KR20120010089A (ko) 2010-07-20 2012-02-02 삼성전자주식회사 Http 기반의 멀티미디어 스트리밍 서비스의 품질 향상을 위한 방법 및 장치
US9131033B2 (en) 2010-07-20 2015-09-08 Qualcomm Incoporated Providing sequence data sets for streaming video data
US9596447B2 (en) 2010-07-21 2017-03-14 Qualcomm Incorporated Providing frame packing type information for video coding
US8711933B2 (en) 2010-08-09 2014-04-29 Sony Computer Entertainment Inc. Random access point (RAP) formation using intra refreshing technique in video coding
US9456015B2 (en) 2010-08-10 2016-09-27 Qualcomm Incorporated Representation groups for network streaming of coded multimedia data
KR101737325B1 (ko) 2010-08-19 2017-05-22 삼성전자주식회사 멀티미디어 시스템에서 멀티미디어 서비스의 경험 품질 감소를 줄이는 방법 및 장치
US8615023B2 (en) 2010-10-27 2013-12-24 Electronics And Telecommunications Research Institute Apparatus and method for transmitting/receiving data in communication system
US9270299B2 (en) 2011-02-11 2016-02-23 Qualcomm Incorporated Encoding and decoding using elastic codes with flexible source block mapping
US8958375B2 (en) 2011-02-11 2015-02-17 Qualcomm Incorporated Framing for an improved radio link protocol including FEC
US20120208580A1 (en) 2011-02-11 2012-08-16 Qualcomm Incorporated Forward error correction scheduling for an improved radio link protocol
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
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
US9129214B1 (en) 2013-03-14 2015-09-08 Netflix, Inc. Personalized markov chains

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2009528002A (ja) * 2006-02-21 2009-07-30 クゥアルコム・インコーポレイテッド マルチメディアアプリケーションにおける高速同調
WO2011038013A2 (en) * 2009-09-22 2011-03-31 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
JP2011087103A (ja) * 2009-10-15 2011-04-28 Sony Corp コンテンツ再生システム、コンテンツ再生装置、プログラム、コンテンツ再生方法、およびコンテンツサーバを提供
WO2011070552A1 (en) * 2009-12-11 2011-06-16 Nokia Corporation Apparatus and methods for describing and timing representations in streaming media files
WO2011102792A1 (en) * 2010-02-19 2011-08-25 Telefonaktiebolaget L M Ericsson (Publ) Method and arrangement for adaption in http streaming

Cited By (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP7483657B2 (ja) 2016-02-16 2024-05-15 フラウンホッファー-ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー.ファオ 効率的な適応ストリーミング
JP2021145343A (ja) * 2016-02-16 2021-09-24 フラウンホッファー−ゲゼルシャフト ツァ フェルダールング デァ アンゲヴァンテン フォアシュンク エー.ファオ 効率的な適応ストリーミング
JP7142626B2 (ja) 2016-07-28 2022-09-27 クゥアルコム・インコーポレイテッド メディアストリーミングのためのセグメントチャンクの検索およびアクセス
JP2019523600A (ja) * 2016-07-28 2019-08-22 クゥアルコム・インコーポレイテッドQualcomm Incorporated メディアストリーミングのためのセグメントチャンクの検索およびアクセス
US11558677B2 (en) 2016-11-10 2023-01-17 Telefonaktiebolaget Lm Ericsson (Publ) Resource segmentation to improve delivery performance
JP7061121B2 (ja) 2016-11-10 2022-04-27 テレフオンアクチーボラゲット エルエム エリクソン(パブル) 配信性能を改善するためのリソースセグメント化
US11722752B2 (en) 2016-11-10 2023-08-08 Telefonaktiebolaget Lm Ericsson (Publ) Resource segmentation to improve delivery performance
JP2019537897A (ja) * 2016-11-10 2019-12-26 テレフオンアクチーボラゲット エルエム エリクソン(パブル) 配信性能を改善するためのリソースセグメント化
JP2022524871A (ja) * 2019-03-14 2022-05-10 ノキア テクノロジーズ オサケユイチア メディアコンテンツにおけるレイトバインディングのための方法および装置
US11653054B2 (en) 2019-03-14 2023-05-16 Nokia Technologies Oy Method and apparatus for late binding in media content
JP7373581B2 (ja) 2019-03-14 2023-11-02 ノキア テクノロジーズ オサケユイチア メディアコンテンツにおけるレイトバインディングのための方法および装置
JP2023505474A (ja) * 2019-12-03 2023-02-09 華為技術有限公司 Httpリクエスト伝送方法及びデバイス
JP7300067B2 (ja) 2019-12-03 2023-06-28 華為技術有限公司 Httpリクエスト伝送方法及びデバイス
US11997328B2 (en) 2019-12-03 2024-05-28 Huawei Technologies Co., Ltd. HTTP request transmission method and device

Also Published As

Publication number Publication date
JP6054398B2 (ja) 2016-12-27
US9253233B2 (en) 2016-02-02
US20130246643A1 (en) 2013-09-19
KR20140054400A (ko) 2014-05-08
WO2013033565A1 (en) 2013-03-07
CN103858440B (zh) 2017-10-31
KR101575740B1 (ko) 2015-12-08
EP2752025A1 (en) 2014-07-09
CN103858440A (zh) 2014-06-11

Similar Documents

Publication Publication Date Title
JP6054398B2 (ja) 適応httpストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法
US11770432B2 (en) Enhanced block-request streaming system for handling low-latency streaming
EP2481195B1 (en) Enhanced block-request streaming using url templates and construction rules
EP2481199B1 (en) Enhanced block-request streaming using cooperative parallel http and forward error correction
US20180152498A1 (en) Enhanced block-request streaming using block partitioning or request controls for improved client-side handling
EP2481198B1 (en) Enhanced block-request streaming using scalable encoding
PH12014502203B1 (en) Enhanced block-request streaming system for handling low-latency streaming

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150205

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150331

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20150630

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150728

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20160223

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160523

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20161130

R150 Certificate of patent or registration of utility model

Ref document number: 6054398

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees