JP6240224B2 - ネットワークストリーミングのための利用可能なメディアデータの決定 - Google Patents

ネットワークストリーミングのための利用可能なメディアデータの決定 Download PDF

Info

Publication number
JP6240224B2
JP6240224B2 JP2015556017A JP2015556017A JP6240224B2 JP 6240224 B2 JP6240224 B2 JP 6240224B2 JP 2015556017 A JP2015556017 A JP 2015556017A JP 2015556017 A JP2015556017 A JP 2015556017A JP 6240224 B2 JP6240224 B2 JP 6240224B2
Authority
JP
Japan
Prior art keywords
segment
request
response
probe requests
client device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP2015556017A
Other languages
English (en)
Other versions
JP2016511575A (ja
JP2016511575A5 (ja
Inventor
マオ・イーニアン
ファティ・ウルピナール
ドナルド・ダブリュ・ギリーズ
Original Assignee
クアルコム，インコーポレイテッド
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 クアルコム，インコーポレイテッド filed Critical クアルコム，インコーポレイテッド
Publication of JP2016511575A publication Critical patent/JP2016511575A/ja
Publication of JP2016511575A5 publication Critical patent/JP2016511575A5/ja
Application granted granted Critical
Publication of JP6240224B2 publication Critical patent/JP6240224B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/4302—Content synchronisation processes, e.g. decoder synchronisation
    • H04N21/4305—Synchronising client clock from received content stream, e.g. locking decoder clock with encoder clock, extraction of the PCR packets
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L27/00—Modulated-carrier systems
    • H04L27/0012—Modulated-carrier systems arrangements for identifying the type of modulation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/40—Support for services or applications
    • H04L65/403—Arrangements for multi-party communication, e.g. for conferences
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/611—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for multicast or broadcast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/65—Network streaming protocols, e.g. real-time transport protocol [RTP] or real-time control protocol [RTCP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/762—Media network packet handling at the source 
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80—Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83—Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845—Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456—Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments

Description

本出願は、その内容全体が参照により本明細書に組み込まれている、2013年2月4日に出願した米国仮出願第61/760,382号の利益を主張するものである。
本開示は、符号化ビデオデータの移送に関する。
デジタルビデオ機能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップコンピュータまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲームデバイス、ビデオゲームコンソール、セルラー電話または衛星無線電話、ビデオ会議デバイスなどを含む、幅広いデバイスに組み込まれ得る。デジタルビデオデバイスは、MPEG-2、MPEG-4、ITU-T H.263またはITU-T H.264/MPEG-4、Part 10、Advanced Video Coding(AVC)、およびそのような規格の拡張によって定義される規格に記載されるような、ビデオ圧縮技法を実装して、デジタルビデオ情報をより効率的に送信および受信する。
ビデオ圧縮技法は、空間的予測および/または時間的予測を実行して、ビデオシーケンスに固有の冗長性を低減または除去する。ブロックベースのビデオコーディングの場合、ビデオフレームまたはスライスがマクロブロックに区分され得る。各マクロブロックはさらに区分され得る。イントラコード化(I)フレームまたはスライスにおけるマクロブロックは、近接マクロブロックに関する空間的予測を使用して符号化される。インターコード化(PまたはB)フレームまたはスライスにおけるマクロブロックは、同じフレームもしくはスライスにおける近接マクロブロックに関する空間的予測または他の参照フレームに関する時間的予測を使用し得る。
ビデオデータが符号化された後、ビデオデータは送信または記憶のためにパケット化され得る。ビデオデータは、AVCのような、国際標準化機構(ISO)によるメディアファイルのフォーマットおよびその拡張などの、種々の規格のいずれかに準拠するビデオファイルへと、組み立てられ得る。
ISO/IEC 23009-1:2012、「Information technology-Dynamic adaptive streaming over HTTP (DASH)-Part 1:Media presentation description and segment formats」、2012年4月1日 R. Fielding他による、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月
一般に、本開示は、表現のライブのネットワークストリーミングの間にメディアコンテンツの利用可能な表現のセグメントを判定するための技法を説明する。クライアントデバイスは、HTTP HEAD要求など、表現のセグメントのシーケンスに対する複数のプローブ要求を送信し、利用可能なセグメントと利用できないセグメントとの間の境界を判定するためにこれらの要求に対する応答を分析することができる。この境界は、セグメント利用可能性窓の「縁部」と呼ばれることがある。いくつかの例では、クライアントデバイスは、前の要求に対するHTTP 404エラーを含む応答の数に応答して、このプローブ要求のシーケンスを送信ことができる。HTTPエラーは、クライアントデバイスのクロックが、セグメントの広告された利用可能性に対して(たとえば、サーバデバイスのクロックに対して)ドリフトしたことを示すことができる。プローブ要求は、メディアデータの1つまたは複数のセグメントが取出しのために利用可能であるかどうかを、クライアントデバイスが判定することを可能にする。
一例では、メディアデータを取り出す方法は、ライブのストリーミングサービスを使用してメディアデータを提供するサーバデバイスにメディアデータのセグメントに対する複数のプローブ要求を送信するステップと、セグメント利用可能性窓の左縁部および右縁部を判定するために複数のプローブ要求に対する応答を分析するステップと、ライブのストリーミングサービスに従って、セグメント利用可能性窓の判定された左縁部および判定された右縁部に基づいてセグメント利用可能性窓内のセグメントに対する要求を送信するステップとを含む。
別の例では、メディアデータを取り出すためのデバイスは、ライブのストリーミングサービスを使用してメディアデータを提供するサーバデバイスにメディアデータのセグメントに対する複数のプローブ要求を送信することと、セグメント利用可能性窓の左縁部および右縁部を判定するために複数のプローブ要求に対する応答を分析することと、ライブのストリーミングサービスに従って、セグメント利用可能性窓の判定された左縁部および判定された右縁部に基づいてセグメント利用可能性窓内のセグメントに対する要求を送信することとを行うように構成された1つまたは複数のプロセッサを含む。
別の例では、メディアデータを取り出すためのデバイスは、ライブのストリーミングサービスを使用してメディアデータを提供するサーバデバイスにメディアデータのセグメントに対する複数のプローブ要求を送信するための手段と、セグメント利用可能性窓の左縁部および右縁部を判定するために複数のプローブ要求に対する応答を分析するための手段と、ライブのストリーミングサービスに従って、セグメント利用可能性窓の判定された左縁部および判定された右縁部に基づいてセグメント利用可能性窓内のセグメントに対する要求を送信するための手段とを含む。
別の例では、コンピュータ可読記憶媒体は命令を記憶しており、命令は、実行されると、ライブのストリーミングサービスを使用してメディアデータを提供するサーバデバイスにメディアデータのセグメントに対する複数のプローブ要求を送信することと、セグメント利用可能性窓の左縁部および右縁部を判定するために複数のプローブ要求に対する応答を分析することと、ライブのストリーミングサービスに従って、セグメント利用可能性窓の判定された左縁部および判定された右縁部に基づいてセグメント利用可能性窓内のセグメントに対する要求を送信することとをプロセッサに行わせる。
1つまたは複数の例の詳細が、以下の添付の図面および説明において述べられる。他の特徴、目的、および利点は、説明、図面、および特許請求の範囲から明らかになるであろう。
ネットワークを通じてメディアデータをストリーミングするための技法を実施する、例示的なシステムを示すブロック図である。 例示的なマルチディアコンテンツの要素を示す概念図である。 セグメントのセットに対する例示的なセグメント利用可能性窓を示す概念図である。 セグメント利用可能性窓を判定するためにプロービング要求が送信され得るセグメントを示す概念図である。 図4のプロービング要求に対する可能な応答パターンを示す概念図である。 図4のプロービング要求に対する可能な応答パターンを示す概念図である。 図4のプロービング要求に対する可能な応答パターンを示す概念図である。 図4のプロービング要求に対する可能な応答パターンを示す概念図である。 図4のプロービング要求に対する可能な応答パターンを示す概念図である。 不均一に離間したプロービングシーケンスの一例を示す概念図である。 本開示の技法による、セグメント利用可能性窓の1つまたは複数の縁部を判定するための例示的な方法を示すフローチャートである。
一般に、本開示は、動的適応ストリーミングオーバーHTTP(DASH)環境など、メディアデータをストリーミングするための環境において、利用可能なメディアデータを判定するための技法を説明する。これらの技法は、HTTPライブストリーミング(HLS)または他のライブのストリーミングサービスをサポートするために使用され得る。全体的にDASHおよびHLSに関して説明するが、本開示の技法は、他のネットワークストリーミングプロトコルに適用され得る。DASHは、http://standards.iso.org/ittf/PubliclyAvailableStandards/c057623_ISO_IEC_23009-1_2012.zipにおいて入手可能な、ISO/IEC 23009-1:2012、「Information technology-Dynamic adaptive streaming over HTTP (DASH)-Part 1: Media presentation description and segment formats」、2012年4月1日において指定される。
本開示の技法は、一般に、メディアデータが取出しのために利用可能であるかどうかを判定することに関する。いくつかの例では、メディアデータは、ある時刻において利用可能であるとして広告され得るが、クライアントデバイスのクロックが、メディアデータが利用可能になる時刻を広告するクロックと同期されていないことがある。たとえば、クライアントデバイスのクロックが、メディアデータが利用可能である時を示すために使用されるクロック(たとえば、サーバデバイスのクロックまたはコンテンツ準備エンティティのクロック)より進んでまたは遅れてドリフトしていることがある。
クライアントデバイスは、クライアントデバイスのクロックが、メディアデータが利用可能である時を表すクロック時刻に対してドリフトしているかどうかを判定するため、ならびにどのメディアデータが現在利用可能であるかを判定するために、本開示の技法を実施するように構成され得る。本開示の技法に従って、クライアントデバイスは、複数の要求をサーバデバイスに送信するように構成され得、そこにおいて、要求の各々は、メディアデータのセグメントのシーケンス内のそれぞれのセグメントに対応する。要求は、セグメントに対してほんの少量のデータを取り出すかまたはデータを取り出さないように編成され得る。たとえば、要求は、対応するセグメントの比較的小さい部分(たとえば、100バイト)に対するHTTP HEAD要求または部分GET要求を含むことができる。すなわち、要求は、セグメントに対するデータの全量より実質的に少ないセグメントのデータ量に対する要求を含むことができる。次いで、サーバデバイスは、要求されたデータまたはHTTP 404エラーのいずれかを用いてこれらの要求に応答することができる。応答を分析することによって、クライアントデバイスは、セグメントのシーケンスのどれが利用可能であり、セグメントのシーケンスのどれが利用できないかを判定することができる。
クライアントデバイスの内部クロックおよびセグメントに対する利用可能性の広告された時刻に基づいて複数の要求を構築することによって、クライアントデバイスは、クライアントデバイスの内部クロックがサーバデバイスの内部クロックに対してドリフトしているかどうかを判定することができる。このようにして、クライアントデバイスは、クライアントデバイスのクロックとサーバデバイスのクロックとの間のドリフトに基づいて、セグメントが利用可能になるようにセグメントを要求することができる。
言い換えれば、(たとえば、DASHによる)ライブのストリーミングにおいて、クライアントデバイスおよびサーバデバイスは、ほぼ同期され得る。しかしながら、クライアントデバイスのクロックとサーバデバイスのクロックとの間に数秒のプラスまたはマイナスの時間デルタが存在することがある。これにより、クライアントがセグメントを取り出すことができなくなることがある。時間シフトバッファ深さ(TSBD)が助けることはあるが、この助けは、限定的条件の下でのみ提供され得る。同じく、現在、クライアントデバイスとサーバデバイスとの間に、ミリ秒の精度の時間同期プロトコルは存在しない。そのようなプロトコルは達成が困難であり、DASHの範囲の外にある可能性がある。
本開示の技法によって提案される1つの実際的な解決法は、クライアントデバイスの挙動に基づいて時間デルタだけを推定し、次いで、後続の要求の作成に時間デルタを考慮に入れることができるクライアントデバイスを伴う。そのようなアルゴリズムは、初期セグメント要求が失敗したとき、または新しいライブのストリーミングセッションが開始されたときは常に、トリガされ得る。クライアントデバイスは、以下でより詳細に説明するように、通常のセグメント要求を使用して、セグメント利用可能性窓の縁部(たとえば、TSBDの左縁部または右縁部、それぞれ、TSBDの後縁および前縁とも呼ばれる)を探索することによって上記を行うことができる。
HTTPストリーミングにおいて、頻繁に使用される動作には、HEAD、GETおよび部分GETがある。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソース名(URN)と関連付けられたファイルのヘッダを取り出し、この場合、URLまたはURNと関連付けられたペイロードを取り出すことはない。GET動作は、所与のURLまたはURNと関連付けられたファイル全体を取り出す。部分GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続した数のバイトを取り出し、ここでバイトの数は受信されるバイト範囲に対応する。したがって、部分GET動作が、1つまたは複数の個々の動画フラグメントを取得できるので、動画フラグメントはHTTPストリーミングのために提供され得る。動画フラグメントにおいて、異なるトラックのいくつかのトラックフラグメントが存在し得る。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントにアクセス可能なデータの構造化された集合体であり得る。クライアントは、メディアデータ情報を要求およびダウンロードして、ユーザにストリーミングサービスを提示することができる。
HTTPストリーミングを使用して3GPPデータをストリーミングする例では、マルチメディアコンテンツのビデオデータおよび/またはオーディオデータに関して複数の表現が存在し得る。以下で説明するように、異なる表現は、異なるコーディング特性(たとえば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格もしくはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張など)、または異なるビットレートに対応することができる。そのような表現のマニフェストは、メディアプレゼンテーション記述(MPD)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにアクセス可能なデータの構造化された集合体に相当し得る。HTTPストリーミングクライアントデバイスは、メディアデータ情報を要求およびダウンロードして、クライアントデバイスのユーザにストリーミングサービスを提示することができる。メディアプレゼンテーションは、MPDの更新を含み得るMPDデータ構造で記述され得る。
メディア表現は、1つまたは複数の期間のシーケンスを格納し得る。期間は、MPDにおいてPeriod要素によって定義され得る。各期間は、MPDにおいて属性startを有し得る。MPDは、期間ごとにstart属性およびavailableStartTime属性を含み得る。ライブのサービスの場合、期間のstart属性とMPD属性availableStartTimeとの合計が、UTCフォーマットによる期間の利用可能時間、特に、対応する期間における各表現の第1のメディアセグメントを指定し得る。オンデマンドサービスの場合、第1の期間のstart属性は0であり得る。任意の他の期間では、start属性は、対応する期間の開始時間と第1の期間の開始時間との間の時間オフセットを指定し得る。各期間は、次の期間の開始まで、または最後の期間の場合にはメディアプレゼンテーションの終了まで及び得る。期間開始時間は、正確であり得る。期間開始時間は、すべての先行期間のメディアの再生から生じる実際のタイミングを反映することができる。
各期間は、同じメディアコンテンツのための1つまたは複数の表現を含み得る。表現は、オーディオデータまたはビデオデータの、多数の符号化バージョンの選択肢の1つであり得る。表現は、符号化のタイプ、たとえば、ビデオデータのビットレート、解像度、および/またはコーデック、ならびにオーディオデータのビットレート、言語、および/またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツのある特定の期間に対応し、ある特定の方法で符号化された、符号化オーディオデータまたは符号化ビデオデータのあるセクションを指すために使用され得る。
ある特定の期間の表現は、表現が属する適応セットを示すMPD中の属性によって示されるグループに割り当てられ得る。同じ適応セット内の表現は、一般に、クライアントデバイスが、たとえば帯域幅に適応するためにこれらの表現の間で動的かつシームレスに切り替わることができる点で、互いに対する代替物と見なされる。たとえば、ある特定の期間のビデオデータの各表現は、同じ適応セットに割り当てられ得るので、表現のうちのいずれもが、対応する期間のマルチメディアコンテンツの、ビデオデータまたはオーディオデータなど、メディアデータを提示するように復号するために、選択され得る。いくつかの例では、1つの期間内のメディアコンテンツは、存在する場合にはグループ0からの1つの表現、または各々の非ゼロのグループからの最大でも1つの表現の組合せのいずれかによって表され得る。ある期間の各表現のタイミングデータは、期間の開始時間に対して表され得る。
表現は、1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含んでよく、または表現の各セグメントは、自己初期化するものであってよい。初期化セグメントは、存在する場合、表現にアクセスするための初期化情報を含み得る。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、uniform resource locator(URL)、uniform resource name(URN)、またはuniform resource identifier(URI)のような、識別子によって一意に参照され得る。MPDは、セグメントごとに識別子を提供することができる。いくつかの例では、MPDはまた、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る、range属性の形式で、バイト範囲を提供することができる。
各表現はまた、1つまたは複数のメディアコンポーネントを含んでよく、この場合、各メディアコンポーネントは、オーディオ、ビデオ、または時限のテキスト(たとえば、クローズドキャプションのための)のような、1つの個々のメディアタイプの符号化バーションに相当し得る。メディアコンポーネントは、1つの表現内の連続的なメディアセグメントの境界にわたって、時間的に連続的であり得る。
一般に、DASHクライアントデバイスは、MPDにアクセスし、DASHサーバデバイスからMPDをダウンロードすることができる。すなわち、DASHクライアントデバイスは、ライブのセッションの開始に使用するためにMPDを取り出すことができる。このMPDに基づいて、および選択された表現の各々に対して、DASHクライアントデバイスは、どれがサーバデバイス上で利用可能な最新のセグメントであるかを判定すること、次のセグメントおよびおそらく将来のセグメントのセグメント利用可能性開始時間を判定すること、いつ、セグメント内のどのタイムラインから、セグメントのプレイアウトを開始するかを判定すること、ならびに新しいMPDをいつ取得する/フェッチするかを判定することを含む、いくつかの判定を行うことができる。サービスが実行されると、クライアントデバイスは、検出され、補償される必要がある、ライブのサービスとそれ自体のプレイアウトとの間のドリフトを追跡することができる。
HTTPライブストリーミング(HLS)は、これらの問題を次のように解決することを試行する。利用可能にされた各セグメントに対して、サーバデバイスは、新しいMPDを発行する。クライアントデバイスは、サービスに参加した後、最新のMPDを取り出し、プレイリストを分析し、次いで、最新のセグメントにアクセスすることができる。次いで、クライアントデバイスは、セグメントを実行することを開始し、最初からセグメントを再生するとき、時間的に次のセグメントに継続的にアクセスすることができるとの期待の下に構成される。新しいセグメントをフェッチする(または新しいセグメントをフェッチすることを要求する)前に、クライアントデバイスは、最新のセグメントを取得する場所を提供する新しいMPDをフェッチする。
SmoothStreamingは、これらの問題を次のように解決することを試行する。利用可能にされた各セグメントに対して、サーバデバイスは、新しいMPDを発行する。クライアントは、サービスに参加した後、最新のMPDを取り出し、最新のS要素のSegmentTimeLineの「@r」属性を取得することによって利用可能である最新のセグメントを分析する。これは、最新のセグメントを取得する場所を示す情報を提供する。次いで、クライアントデバイスは、セグメントを実行することを開始し、最初からセグメントを再生するとき、次の要求が、最後の要求の時刻にセグメント持続時間を加算した結果得られる時刻より前でない限り、時間的に次のセグメントに継続的にアクセスすることができるとの期待の下に構成される。それゆえ、クライアントは、現在のMPDがもはや使用できないことを示すインバンド信号を取得するまで、新しいMPDをフェッチすることなく最新のSegmentTimeline.S要素に基づいてセグメントを構築することを継続する。この時点で(すなわち、現在のMPDがもはや使用できないとの信号に応答して)、クライアントデバイスは新しいMPDを要求する。
MPEG-DASHは、ライブのメディアプレゼンテーションをセットアップする、MPD内に文書化された壁時計時刻を使用する。MPEG-DASHは、MPD生成プロセスが正確なクロックへアクセスするようにMPDが生成されると仮定する。これは、任意の手段によって壁時計時刻と同期されるクライアントデバイスが、ライブエッジ(前縁とも呼ばれる)のより近くで動作することを可能にする。具体的には、後続の情報は、番号テンプレートベースの表現を使用するときおよび@duration属性を使用するとき、MPD内で利用可能である。
・MPD@availabilityStartTime:開始時刻は、壁時計時刻におけるMPDに対するアンカである。値はASTとして示される。
・MPD@minimumUpdatePeriod:MPDの最小更新期間。値はMUPとして示される。
・MPD@suggestedPresentationDelay:セグメント利用可能性開始時刻に対するデルタとして示唆されたプレゼンテーション遅延。値はSPDとして示される。
・MPD@minBufferTime:各表現の@bandwidth属性と連携して使用される最小バッファ時間。値はMBTとして示される。
・MPD@timeShiftBufferDepth:メディアプレゼンテーションの時間シフトバッファ深さ。値はTSBとして示される。
・Period@start:MPD利用可能性開始時刻に対する期間の開始時刻。値はPSとして示される。
・SegmentTemplate@startNumber:期間中の第1のセグメントの番号。値はSSNとして示される。
・SegmentTemplate@duration:時間のユニット内のセグメントの持続時間。@timescaleの値で除された値が、dとして示される。
クライアントデバイスがフェッチ時刻FTにおいてMPDをフェッチしたものと仮定する。
次いで、クライアントにおける壁時計時刻がWTにおいて示されると仮定すると、クライアントデバイスは、次の情報を導出することができる。
・LSNとして示される最新のセグメント番号を必要とするサーバ上で利用可能な最新のセグメントのアドレス。
・番号LSN+1および任意の他のセグメントSNを有する次のセグメントのセグメント利用可能性開始時刻、SAST(SN)として示される。SNは1から開始することに留意されたい。
・ライブエッジに最も近く同期するセグメント内のメディアプレゼンテーション時刻、MPTL。
・他のクライアントと同期するセグメント内のメディアプレゼンテーション時刻、MPTS。
・現在のプレゼンテーション時刻に基づいて新しいMPDをフェッチする時刻。
MPEG-DASHの技法の一例を、以下に説明する。この例では、MPDに以下の情報を含ませる。
<MPD availabilityStartTime="2011-12-25T12:30:00"
minimumUpdatePeriod="30s" suggestedPresentationDelay="15s"
minBufferTime="5s"/>
<BaseURL>http://www.example.com/</BaseURL>
<Period start="PT0S"/>
...
</Period>
<Period start="PT0.10S>
...
<SegmentTemplate timescale="48000"startNumber="22"
presentationTimeOffset="2016000" duration="96000"
initialization="audio/fr/init.mp4a" media="audio/fr/$Number$.mp4"/>
...
</Period>
さらに、クライアントデバイスがMPDをフェッチし、壁時計時刻が、NTP="2011-12-25T12:30:27"であるものと仮定する。この値は、この例ではFTとして示される。
次いで、クライアントデバイスは、最新のセグメント番号を導出する。すなわち、クライアントデバイスは、AST+PS≦NTPとなる期間として最新の期間を取得する。NTP≧AST+PS+dである場合、この期間内の少なくとも1つのセグメントが利用可能であり、クライアントデバイスは、
LSN=floor(NTP-(AST+PS)-d)/d)+SSN=floor(15/2)+22=29 (1)
としてクライアント上で利用可能な最新のセグメント番号(LSN)を導出する。
それゆえ、得られたURLは、この例では、http://www.example.com/audio/fr/29.mp4として導出される。
次いで、クライアントデバイスは、番号SNを有するセグメントに対するセグメント利用可能性開始時刻(SAST)を、
SAST(SN)=AST+PST+(SN-SSN+1)*d (2)
として導出する。
これは、この例では、SN=30に対して、SAST(SN=30)=2011-12-25T12:30:28を意味する。
次いで、クライアントデバイスは、MPD内の利用可能情報に基づいてプレイアウトをスケジュールする。クライアントデバイスは、各表現に対する期間内のメディアプレゼンテーション時刻を、各表現に対して、存在する場合には、メディアセグメント内のプレゼンテーション時刻値マイナス@presentationTimeOffsetの値として決定する。セグメント番号SNを有する各セグメントは、EPT(SN)で示される最早のプレゼンテーション時刻を含む。
MPDを提供することによって、MPEG-DASH内で、以下を保証する。
1.この期間内の各セグメントは、その最早のプレゼンテーション時刻の前に利用可能である、すなわち、すべてのSNに対して、EPT(SN)≧SAST(SN)-(AST+PST)。
2.セグメント番号SNを有する各セグメントが、@bandwidth属性の値に等しいビットレートを有する一定のビットレートチャネルを介して、SAST(SN)から始めて配信される場合、各プレゼンテーション時刻PTは、最新で時刻PT+(AST+PST)+MBTにおいてクライアントにおいて利用可能である。
3.他のクライアントと同期して動作するプレゼンテーション時刻に対する推奨プレイアウト時刻MPTS(PT)は、MPTS(PT)=(AST+PST)+PT+SPDである。
4.この期間内の各セグメントは、少なくともSAST(SN)+TSB+dまで利用可能である。
この情報を使用して、クライアントデバイスは、MPD内の情報ならびにダウンロード速度を考慮に入れて、プレイアウトをスケジュールすることを開始することができる。属性@suggestedPresentationDelayが存在する場合、適切なプレイアウト時刻は、POT(PT)=MPTS(PT)である。@suggestedPresentationDelayが存在しない場合、適切なプレイアウト時刻は、上記の第1、第2、および第4の制約条件、すなわち、サーバにおけるセグメント利用可能性時刻ならびにメディアストリームのビットレート変動性を考慮に入れる。
クライアントデバイスは、MPDが有効である間、セグメントを構築するためにMPDを使用する。特に、クライアントデバイスは、メディア時刻FT+MUPまで、セグメントを構築するためにMPDを使用する。すなわち、構築され得る最大のセグメント番号(GSN)は、
GSN=ceil(FT+MUP-(AST+PS)-d)/d)+SSN=ceil(45/2)+22=45 (3)
である。
最新のセグメントは、他のセグメントより短いことがあることを理解されたい。上記の例において、セグメント番号45を超える任意のデータをフェッチする前に、クライアントデバイスは、MPEG-DASHに従って新しいMPDをフェッチする必要がある。
より一般的には、DASH内で同じ概念を異なるタイミングおよびアドレス指定方式で使用するために、以下の値が、ISO/IEC 23009-1に従って導入される。
・k=1,2,...であるkとして示される期間内のセグメントの位置
・MST(k)と呼ばれる、位置kにおけるセグメントのMPD開始時刻
・MD(k)と呼ばれる、位置kにおけるセグメントのMPD持続時間
次いで、クライアントデバイスにおける壁時計時刻がWTとして示されると仮定すると、クライアントデバイスは、以下の情報を導出することができる。
1.その期間開始時刻PST*によって示される、サーバ上の最新の利用可能期間
2.SAST(k)として示される、期間内の位置kにおける任意のセグメントのセグメント利用可能性開始時刻
3.k*と呼ばれる、期間内にサーバ上で利用可能な最新のセグメントの位置
4.サーバ上で利用可能な最新のセグメントのアドレス
5.現在のプレゼンテーション時刻に基づいて新しいMPDをフェッチする時刻、またはより具体的には、このMPDによって構築され得るこの期間内の最大のセグメント位置k'
6.ライブエッジに最も近く同期する表現内のメディアプレゼンテーション時刻、MPTL
7.他のクライアントと同期する表現内のメディアプレゼンテーション時刻、MPTS
これらの時刻を使用してクライアントデバイスは、上記から以下のように値を導出することができる。
1.最新の期間が、PST≦NTPとなる期間として取得される。
2.セグメント利用可能性開始時刻が、
SAST(k)=AST+PST+MST(k)+MD(k) (4)
として取得される。
3.この期間内でクライアントデバイス上で利用可能な最新のセグメントは、SAST(k*)に対する最大値をもたらし、同時にNTPより小さい、位置k*におけるセグメントである。
4.最新のセグメントのアドレスは、位置情報k*を使用することによって取得され、次いでセグメントアドレスが導出され得る。セグメントアドレスは、アドレス指定方法に依存する。
5.この期間内でこのMPDによって構築され得る最大のセグメント位置k'は、SAST(k')に対する最大値をもたらし、同時にFT+MUPより小さいセグメント位置である。
クライアントデバイスは、このデータを使用してMPD時刻を導出することができる。たとえば、@duration属性が存在し、@timescaleの値によって導出された値がdとして示される場合、クライアントデバイスは、従来のDASH技法を使用してMPD時刻を、
・MD(k)=d
・MST(k)=(k-1)*d
として導出する。
セグメントベースの情報が、s=1, ..., NSでインデックスされたNSS要素を有するSegmentTimeline要素を含む場合、(ISO/IEC 23009-1に従ってDASHにおいて)、
・t[s]は、s番目のS要素の@tを@timescale属性の値で除した値である。
・d[s]は、s番目のS要素の@dを@timescale属性の値で除した値である。
・r[s]は、s番目のS要素の@rの値である(@rの値が-1でない場合であり、ここで@r=-1は、値が未知であり、更新された情報が利用可能になるまで、@dが使用され得ることを意味する)。
したがって、クライアントデバイスは、MPD持続時間および開始時刻を、以下の
・K=0
・for s=1, ... Ns
〇 k=k+1
〇 MST(k)=t[s]
〇 MD(k)=d[s]
〇 for j=1, ... r[s]
・k=k+1
・MST(k)=MST(k-1)+d[s]
・MD(k)=d[s]
として導出することができる。
ISO/IEC 23009-1に従うDASHにおいて、アドレス指定方法は、タイムライン生成の使用とは無関係である。@startNumberの解釈は、アドレス指定方法に依存する。表現が、メディアセグメントに対する明示的URLのセットを提供する、1つまたは複数のSegmentList要素を含むかまたは継承する場合、クライアントデバイスは、@startNumberを使用してセグメントリスト内の第1のセグメントの位置を判定する。次いで、セグメントリストは、明示的URLを提供する。表現が、$Number$を有するSegmentTemplate要素を含むかまたは継承する場合、位置kにおけるメディアセグメントのURLが、$Number$識別子をSegmentTemplate@mediaストリング内の(k-1)+@startNumberで置き換えることによって取得される。表現が、$Time$を有するSegmentTemplate要素を含むかまたは継承する場合、クライアントデバイスは、$Time$識別子をSegmentTemplate@mediaストリング内のMST(k)(@timescale属性内の値で非正規化される)で置き換えることによって位置kにおけるメディアセグメントのURLを取得する。
さらに、ISO/IEC 23009-1に従うDASHにおいて、クライアントデバイスは、MPD内の利用可能な情報に基づいてプレイアウトをスケジュールする。クライアントデバイスは、各表現に対する期間内のメディアプレゼンテーション時刻を、各表現に対して、存在する場合には、メディアセグメント内のプレゼンテーション時刻値マイナス@presentationTimeOffsetの値として決定する。位置kにおける各セグメントは、最早のメディアプレゼンテーション時刻EPT(k)を割り当てている。
MPDを提供することによって、ISO/IEC 23009-1に従うDASHは、以下を保証する。
1.この期間内の各セグメントは、その最早のプレゼンテーション時刻およびその持続時間の前に利用可能である、すなわち、すべてのkに対して、
SAST(k)≦EPT(k)+(AST+PST)+MD(k) (5)
である。
2.セグメント番号kを有する各セグメントが、@bandwidth属性の値に等しいビットレートを有する一定のビットレートチャネルを介して、SAST(k)から始めて配信される場合、各プレゼンテーション時刻PTは、最新で時刻PT+(AST+PST)+MBT+MD(k)においてクライアントにおいて利用可能である。
3.他のクライアントと同期して動作するプレゼンテーション時刻に対する推奨プレイアウト時刻MPTS(PT)は、MPTS(PT)=(AST+PST)+PT+SPDである。
4.この期間内の各セグメントは、少なくともSAST(k)+TSB+MD(k)まで利用可能である。
この情報を使用して、クライアントデバイスは、MPD内の情報ならびにダウンロード速度を考慮に入れて、プレイアウトをスケジュールすることを開始することができる。属性@suggestedPresentationDelayが存在する場合、適切なプレイアウト時刻は、POT(PT)=MPTS(PT)である。属性@suggestedPresentationDelayが存在しない場合、適切なプレイアウト時刻は、第1、第2、および第4の制約条件、すなわち、サーバにおけるセグメント利用可能性時刻ならびにメディアストリームのビットレート変動性を考慮に入れる。
ISO/IEC 23009-1に従うDASHの下で、メディア時刻FT+MUPまで、クライアントデバイスは、セグメントを構築および要求するためにMPDを使用することができ、このMPDによって構築され得る最大セグメント位置k'は、SAST(k')に対する最大値をもたらすと同時にFT+MUPより小さいセグメント位置である。最新のセグメントは、他のセグメントより短いことがある。
@durationまたはSegmentTimeline.S@r="-1"を用いるテンプレート構築が使用される場合、ISO/IEC 23009-1に従うDASHの手法は、HLSおよびSmoothStreamingの手法と比較して、
1.MPDは、セグメント構築が継続され得る限り、サーバデバイス上で更新される必要はない。クライアントデバイスがMPDのフェッチ時刻を記録している限り、クライアントデバイスは、いくつかの異なるサービスに対して前もってMPDをダウンロードする(またはMPDをバッファ内に保持する)ことができる。
2.同じく、マルチキャスト環境において、MPDは、一度だけまたは少なくとも毎秒よりはるかに少ない頻度で分配され得る。
3.クライアントデバイスは、次のセグメントがサーバデバイス上で利用可能になる/発行される正確な時刻を示す情報を有する。これにより、セグメントが利用可能になるとすぐにクライアントデバイスがセグメントを要求するので、ライブエッジにより近い動作が可能になる。
4.クライアントデバイスは、クライアントデバイスがダウンロードする第1のセグメントのプレイアウトを正確に設置することができる。クライアントデバイスは、ライブエッジにより近い動作を可能にするために、セグメントの中間においてプレイアウトを開始することさえも可能である。
5.クライアントデバイスは、そのプレイアウトを他のクライアントデバイスと同期することができる。
6.サーバデバイス動作は簡単である、すなわち、専用のサーバデバイスは不要である。
など、いくつかの利点を提供することができる。
DASHライブストリーミングは、クライアントおよびサーバが時間的に同期されるものと仮定するが、現在の仕様は、時刻同期問題を除外しており、その問題はネットワーク時間プロトコル(NTP)などのプロトコルによって対処されることを仮定している。しかしながら、室内実験では、クライアントおよびサーバが初期に同期されているときでさえ、それらのクロックは、数十ミリ秒から数秒まで異なることがあることが観測されている。これには2つの理由がある。第1の理由は、NTPが、ミリ秒の精度を達成するように設計されたプロトコルではないことである。第2の理由は、クライアントおよびサーバのクロックが、初期同期の後でだんだん離れていくことがあることである。NTP同期の後、24時間の持続時間の中で最大20秒のクライアントおよびサーバの時間デルタが、発見的試験において観測されている。
クライアント-サーバの時間デルタの1つの潜在的な欠点は、メディアセグメントに対するセグメント利用可能性時間窓のクライアントのビューが、サーバのビューから斜めになることがあることである。クライアントのビューが実質的に斜めになる場合、クライアントは、メディアセグメントが利用可能になる前、またはメディアセグメントが利用可能性時間窓の外に出た後、メディアセグメント要求を送信することができる。両方の場合において、サーバは、HTTP 404エラーコードを用いて応答し、クライアントは、セグメントを成功裏に取り出すことができない。そのようなエラーは、始動不良または再生の中断を引き起こすことがある。DASHライブストリーミングシステムにおいて、第3のデバイス、符号化システムも存在し、そのデバイスは、符号化されたビデオセグメントを作成し、それらをウェブサーバ上に記憶し、それらを後で消去する。クライアントとウェブサーバとの間の頻繁な再同期をもってしても、クロックドリフトは、クライアントと符号化システムとの間に発生し得、そのことで、セグメントがフェッチされるときにHTTP 404エラーがもたらされ得る。
本開示は、クライアントデバイスのクロックと、サーバデバイスのクロックおよび符号化システムのクロックの一方または両方との間の時間デルタを推定するためのクライアントベースの方法を説明する。推定された時間デルタは、後続のメディアセグメント要求を送信するための時刻を調整するために、クライアントデバイスによって使用され得る。したがって、本開示によって説明する技法を実施することで、よりロバストなプレイアウトエクスペリエンスがもたらされ得る。
一例では、クライアントデバイスは、時間デルタ推定アルゴリズムに基づいてクライアントデバイスの内部クロックとサーバデバイスの内部クロックとの間の時間差(ドリフトまたは時間デルタとも呼ばれる)を推定するように構成され得る。時間デルタはまた、(追加または代替として)クライアントデバイスのクロックと、特定のセグメントが利用可能にされる時刻(したがって、必ずしもサーバデバイスのクロックによって示される時刻に対するものとは限らない)との間の差を表す。特定のセグメント(またはデータの他のユニット)が利用可能になる時刻は、本明細書では利用可能性時刻と呼ばれることがある。本開示の同じ時間デルタ推定アルゴリズムが、一方または両方のシナリオにおいて適用され得る。
本開示の時間デルタ推定アルゴリズムは、以下の仮定の下に使用され得る。第1の仮定は、クライアントとサーバとの間の時間デルタ(またはセグメント利用可能性時刻)が、B秒以内によって制限されることである。実際の時間デルタが仮定された値Bより大きい場合、このアルゴリズムは、場合によっては時間デルタを推定することができない。第2の仮定は、ウェブサーバデバイスが、パイプライン要求をサポートすることである。そうでない場合、推定手順は、設計された制度を達成するように修正される必要があることがある。第3の仮定は、クライアントとサーバとの間の利用可能な帯域幅が、最小しきい値、たとえば、およそダイヤルアップ接続の速度である50kbpsを超えることである。非常に遅いネットワーク速度は、推定の不正確さを増大させることがある。第4の仮定は、ウェブサーバデバイスが、無視できる時間内(たとえば、1秒未満内)にクライアントデバイスからの最大数十にのぼるHTTP HEAD要求を処理することができることである。
さらに、本開示の技法を実施するために、クライアントデバイスは、クライアントデバイスとサーバデバイスとの間の時間デルタを、最大1セグメント持続時間の粒度(たとえば、1秒)で推定することができるように構成され得る。推定はまた、5秒または10往復時間(RTT)のいずれか大きい方以内で作成されるべきである。実際の時間デルタが設計された時間デルタ限界を超えるときに、時間デルタ推定アルゴリズムが自動的に内部パラメータを調整して、低下した精度または延長された推定時間という代償を払って推定を得ることができる場合に、有利であり得る。
クライアントデバイスはまた、初期にサーバデバイスとおおよその同期を達成するように構成され得る。これは、ネットワークタイムプロトコル(NTP)など、いくつかの時刻同期プロトコルのうちの1つを介して行われ得る。しかしながら、正確に、クライアントデバイスがサーバデバイスと初期時刻同期をどのように達成するかについての制約はない。本開示において導入される時間デルタ推定の粒度は、セグメント持続時間によって、およびウェブサーバデバイスによるすべてのプロービング要求の処理遅延によって制限され得る。言い換えれば、粒度は、1セグメント持続時間または総処理遅延のいずれか大きい方より細かい必要はない。一般に、処理遅延は、1セグメント時間と比較すると極めて小さく無視できると仮定される。
図1は、ネットワークを通じてメディアデータをストリーミングするための技法を実施する、例示的なシステム10を示すブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、インターネットを含み得るネットワーク74によって通信可能に結合される。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60も、ネットワーク74もしくは別のネットワークによって結合されてよく、または直接通信可能に結合されてよい。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを含み得る。
図1の例では、コンテンツ準備デバイス20は、オーディオソース22およびビデオソース24を含む。オーディオソース22は、たとえば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成する、マイクロフォンを含み得る。あるいは、オーディオソース22は、以前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザのようなオーディオデータ生成器、またはオーディオデータの任意の他のソースを含み得る。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、以前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースのようなビデオデータ生成ユニット、またはビデオデータの任意の他のソースを含み得る。コンテンツ準備デバイス20は必ずしも、すべての例においてサーバデバイス60に通信可能に結合されるとは限らないが、サーバデバイス60によって読み取られる別個の媒体に、マルチメディアコンテンツを記憶することができる。
生のオーディオデータおよびビデオデータは、アナログデータまたはデジタルデータを含み得る。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前にデジタル化され得る。オーディオソース22は、話している参加者から、その参加者が話している間オーディオデータを取得することができ、ビデオソース24は、話している参加者のビデオデータを同時に取得することができる。他の例では、オーディオソース22は、記憶されたオーディオデータを含むコンピュータ可読記憶媒体を含んでよく、ビデオソース24は、記憶されたビデオデータを含むコンピュータ可読記憶媒体を含み得る。このようにして、本開示で説明される技法は、生の、ストリーミングの、リアルタイムのオーディオデータおよびビデオデータに、または、保管された、以前に記録されたオーディオデータおよびビデオデータに、適用され得る。
ビデオフレームに対応するオーディオフレームは一般に、ビデオフレーム内に含まれるビデオソース24によってキャプチャ(または生成)されたビデオデータと同時に、オーディオソース22によってキャプチャ(または生成)されたオーディオデータを含む、オーディオフレームである。たとえば、話している参加者が一般に話すことによってオーディオデータを生成している間、オーディオソース22はオーディオデータをキャプチャし、ビデオソース24は同時に、すなわちオーディオソース22がオーディオデータをキャプチャしている間に、話している参加者のビデオデータをキャプチャする。したがって、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。したがって、ビデオフレームに対応するオーディオフレームは一般に、オーディオデータおよびビデオデータが同時にキャプチャされた状況に対応し、その状況に対して、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを含む。
いくつかの例では、オーディオエンコーダ26は、各符号化オーディオフレームにおいて、符号化オーディオフレームのオーディオデータが記録された時間を表すタイムスタンプを符号化することができ、同様に、ビデオエンコーダ28は、各符号化ビデオフレームにおいて、符号化ビデオフレームのビデオデータが記録された時間を表すタイムスタンプを符号化することができる。そのような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを含むオーディオフレームおよび同じタイムスタンプを含むビデオフレームを含み得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成し得るようにする、またはオーディオソース22およびビデオソース24がそれぞれオーディオデータおよびビデオデータをタイムスタンプと関連付けるために使用し得る、内部クロックを含み得る。
いくつかの例では、オーディオソース22は、オーディオデータが記録された時間に対応するデータをオーディオエンコーダ26に送ることができ、ビデオソース24は、ビデオデータが記録された時間に対応するデータをビデオエンコーダ28に送ることができる。いくつかの例では、オーディオエンコーダ26は、符号化オーディオデータにおいて、符号化オーディオデータの相対的な時間順序を示すために、オーディオデータが記録された絶対的な時間を必ずしも示すとは限らないが、シーケンス識別子を符号化することができ、同様に、ビデオエンコーダ28も、符号化ビデオデータの相対的な時間順序を示すためにシーケンス識別子を使用することができる。同様に、いくつかの例では、シーケンス識別子がタイムスタンプとともにマップされるか、あるいはタイムスタンプと相関することがある。
オーディオエンコーダ26は一般に、符号化オーディオデータのストリームを生成する一方、ビデオエンコーダ28は、符号化ビデオデータのストリームを生成する。データの各々の個別のストリーム(オーディオかビデオかにかかわらず)は、エレメンタリストリームと呼ばれ得る。エレメンタリストリームは、表現の、単一のデジタル的にコード化された(場合によっては圧縮された)構成要素である。たとえば、表現のコード化されたビデオまたはオーディオの部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内にカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、ストリームIDが、あるエレメンタリストリームに属するPESパケットを他のエレメンタリストリームに属するPESパケットと区別するために使用され得る。エレメンタリストリームのデータの基本単位は、パケット化されたエレメンタリストリーム(PES)パケットである。したがって、コード化ビデオデータは一般に、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
ITU-T H.264/AVCおよび今度の高効率ビデオコーディング(HEVC)規格など、多くのビデオコーディング規格は、エラーのないビットストリームのためのシンタックス、意味論、および復号プロセスを定義し、それらのいずれもが、一定のプロファイルまたはレベルに準拠する。ビデオコーディング規格は、一般的にエンコーダを規定しないが、エンコーダは、生成されたビットストリームがデコーダのための規格に準拠することを保証する役割を課される。ビデオコーディング規格の文脈では、「プロファイル」は、アルゴリズム、機能、またはツールのサブセット、およびこれらに適用される制約に相当する。H.264規格によって定義されるように、たとえば、「プロファイル」は、H.264規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル」は、たとえば、デコーダメモリおよび計算のような、デコーダのリソース消費の制限に相当し、これは、ピクチャの解像度、ビットレート、およびブロック処理速度に関連する。プロファイルは、profile_idc(プロファイルインジケータ)値によってシグナリングされ得るが、レベルは、level_idc(レベルインジケータ)値によってシグナリングされ得る。
たとえば、所与のプロファイルのシンタックスによって課される範囲内で、復号されるピクチャの規定されるサイズのようなビットストリーム中のシンタックス要素のとる値に応じて、エンコーダおよびデコーダの性能に大きい変動を要求することが依然として可能であることを、H.264規格は認める。多くの用途において、ある特定のプロファイル内でのシンタックスのすべての仮想的な使用を扱うことが可能なデコーダを実装するのは、現実的でも経済的でもないことを、H.264規格はさらに認める。したがって、H.264規格は、ビットストリーム中のシンタックス要素の値に課される制約の規定されたセットとして、「レベル」を定義する。これらの制約は、値に対する単純な制限であり得る。あるいは、これらの制約は、値の算術的な組合せの制約の形式(たとえば、1秒当たりに復号されるピクチャの数と、ピクチャの高さと、ピクチャの幅との積)をとり得る。個々の実装形態が、サポートされる各プロファイルに対して異なるレベルをサポートできることを、H.264規格はさらに実現する。
プロファイルに準拠するデコーダは普通、プロファイル中で定義されるすべての機能をサポートする。たとえば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされないが、H.264/AVCの他のプロファイルではサポートされる。あるレベルに準拠するデコーダは、レベル中で定義された制限を超えるリソースを要求しない、あらゆるビットストリームを復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈力のために有用であり得る。たとえば、ビデオ送信の間、プロファイルとレベルの定義のペアが、送信セッション全体に対して取り決められ合意され得る。より具体的には、H.264/AVCにおいて、レベルは、処理される必要があるマクロブロックの数、復号されたピクチャバッファ(DPB:decoded picture buffer)のサイズ、コード化ピクチャバッファ(CPB:coded picture buffer)のサイズ、垂直方向の運動ベクトルの範囲、2つの連続するMBあたりの運動ベクトルの最大の数に対する制限、および、Bブロックが8×8ピクセルよりも小さいサブマクロブロック区画を有し得るかどうかを定義することができる。このようにして、デコーダは、デコーダが適切にビットストリームを復号できるかどうかを判定することができる。
図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコード化ビデオデータを含むエレメンタリストリームと、オーディオエンコーダ26からのコード化オーディオデータを含むエレメンタリストリームとを受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのパケタイザを含み得る。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケタイザとインターフェースをとり得る。さらに他の例では、カプセル化ユニット30は、符号化オーディオデータおよび符号化ビデオデータからPESパケットを形成するためのパケタイザを含み得る。
ビデオエンコーダ28は、種々の方法でマルチメディアコンテンツのビデオデータを符号化して、ピクセル解像度、フレームレート、様々なコーディング規格に対する準拠、様々なコーディング規格のための様々なプロファイルおよび/もしくはプロファイルのレベルに対する準拠、1つもしくは複数の表示を有する表現(たとえば、2次元または3次元の再生用)、または他のそのような特性などの、様々な特性を有する様々なビットレートのマルチメディアコンテンツの様々な表現を生成することができる。本開示で使用されるような表現は、オーディオデータとビデオデータとの組合せ、たとえば、1つまたは複数のオーディオエレメンタリストリームと1つまたは複数のビデオエレメンタリストリームとを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを特定する、stream_idを含み得る。カプセル化ユニット30は、様々な表現のビデオファイルへとエレメンタリストリームを組み立てる役割を担う。
カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28からの表現のエレメンタリストリームのためのPESパケットを受信し、PESパケットから対応するネットワーク抽象化層(NAL)ユニットを形成する。H.264/AVC(Advanced Video Coding)の例では、コード化ビデオセグメントはNALユニットへと編成され、NALユニットは、ビデオ電話、記憶、ブロードキャスト、またはストリーミングのような、「ネットワークフレンドリ」なビデオ表現のアドレッシング適用(addressing application)を実現する。NALユニットは、ビデオコーディング層(VCL)NALユニットおよび非VCL NALユニットに分類され得る。VCLユニットは、コア圧縮エンジンを含んでよく、ブロック、マクロブロック、および/またはスライスレベルのデータを含んでよい。他のNALユニットは、非VCL NALユニットであり得る。いくつかの例では、1つの時間インスタンスにおけるコード化ピクチャは、通常は一次コード化ピクチャとして提示され、1つまたは複数のNALユニットを含み得るアクセスユニットに含まれ得る。
非VCL NALユニットは特に、パラメータセットのNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)中に)シーケンスレベルヘッダ情報を含み、(ピクチャパラメータセット(PPS)中に)頻繁には変化しないピクチャレベルヘッダ情報を含み得る。パラメータセット(たとえば、PPSおよびSPS)があれば、この頻繁には変化しない情報は、各シーケンスまたはピクチャに対して繰り返される必要がなく、したがってコーディング効率が向上し得る。さらに、パラメータセットの使用が、重要なヘッダ情報の帯域外送信を可能にでき、エラーの復元のための冗長な送信の必要がなくなる。帯域外送信の例では、パラメータセットのNALユニットが、SEI NALユニットなどの他のNALユニットとは異なるチャネルで送信され得る。
補足エンハンスメント情報(SEI)は、VCL NALユニットからコード化ピクチャサンプルを復号するために必要ではない情報を含み得るが、復号、表示、エラーの復元、および他の目的に関係するプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに含まれ得る。SEIメッセージは、いくつかの標準仕様の規範的部分であり、したがって、規格に準拠するデコーダの実装において常に必須であるとは限らない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。いくつかのシーケンスレベル情報は、SVCの例におけるスケーラビリティ情報SEIメッセージおよびMVCにおける表示スケーラビリティ情報SEIメッセージなどのSEIメッセージに含まれ得る。これらの例示的なSEIメッセージは、たとえば動作点の抽出および動作点の特性に関する情報を伝達することができる。加えて、カプセル化ユニット30は、表現の特性を記述するmedia presentation descriptor (MPD)などのマニフェストファイルを形成することができる。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットすることができる。
カプセル化ユニット30は、マニフェストファイル(たとえば、MPD)とともに、マルチメディアコンテンツの1つまたは複数の表現のためのデータを、出力インターフェース32に提供することができる。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェースのような記憶媒体へ書き込むためのネットワークインターフェースもしくはインターフェース、CDもしくはDVDのライターもしくはバーナー、磁気記憶媒体もしくはフラッシュ記憶媒体へのインターフェース、または、メディアデータを記憶もしくは送信するための他のインターフェースを含み得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを出力インターフェース32に提供することができ、出力インターフェース32は、ネットワーク送信または記憶媒体を介してデータをサーバデバイス60に送信することができる。図1の例では、サーバデバイス60は、各々がそれぞれのマニフェストファイル66および1つまたは複数の表現68A〜68N(表現68)を含む様々なマルチメディアコンテンツ64を記憶する、記憶媒体62を含む。いくつかの例では、出力インターフェース32はネットワーク74にデータを直接送信することもできる。
いくつかの例では、表現68は、適応セットへと分割され得る。すなわち、表現68の様々なサブセットは、コーデック、プロファイルおよびレベル、解像度、表示の数、セグメントのファイルフォーマット、たとえば話者による、復号され提示されるべき表現および/またはオーディオデータとともに表示されるべきテキストの言語または他の特性を特定し得るテキストタイプ情報、カメラの角度または適応セット中の表現の風景の現実世界のカメラの視野を表し得るカメラ角度情報、特定の視聴者に対するコンテンツの適切性を表すレーティング情報のような、特性のそれぞれの共通のセットを含み得る。
マニフェストファイル66は、特定の適応セットに対応する表現68のサブセットを示すデータ、さらには、適応セットの共通の特性を含み得る。マニフェストファイル66はまた、適応セットの個々の表現のための、ビットレートのような個々の特性を表すデータを含み得る。このようにして、適応セットは、簡略化されたネットワーク帯域幅の適応を行うことができる。適応セット中の表現は、マニフェストファイル66の適応セット要素の子要素を使用して示され得る。
サーバデバイス60は、要求処理ユニット70およびネットワークインターフェース72を含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の機能のいずれかまたはすべてが、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスのような、コンテンツ配信ネットワークの他のデバイス上で実装され得る。いくつかの例では、コンテンツ配信ネットワークの中間デバイスは、マルチメディアコンテンツ64のデータをキャッシュし、サーバデバイス60の構成要素に実質的に準拠する構成要素を含み得る。一般に、ネットワークインターフェース72は、ネットワーク74を介してデータを送信および受信するように構成される。
要求処理ユニット70は、記憶媒体62のデータに対するネットワーク要求を、クライアントデバイス40のようなクライアントデバイスから受信するように構成される。たとえば、要求処理ユニット70は、R. Fieldingらによる、RFC 2616、「Hypertext Transfer Protocol-HTTP/1.1」、Network Working Group、IETF、1999年6月で説明されるような、ハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装することができる。すなわち、要求処理ユニット70は、HTTP GET要求または部分GET要求を受信して、それらの要求に応答してマルチメディアコンテンツ64のデータを提供するように構成され得る。要求は、たとえば、セグメントのURLを使用して、表現68のうちの1つのセグメントを指定することができる。いくつかの例では、要求はまた、セグメントの1つまたは複数のバイト範囲を指定することができ、したがって、部分GET要求を含む。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するために、HTTP HEAD要求に対応するように構成され得る。いずれの場合でも、要求処理ユニット70は、クライアントデバイス40のような要求デバイスに、要求されたデータを提供するために、要求を処理するように構成され得る。
追加または代替として、要求処理ユニット70は、ブロードキャストまたはマルチキャストのプロトコル、たとえばeMBMSを介してメディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、DASHセグメントおよび/またはサブセグメントを、説明したものと実質的に同じ方法で作成することができるが、サーバデバイス60は、これらのセグメントまたはサブセグメントを、eMBMSまたは別のブロードキャストもしくはマルチキャストのネットワークトランスポートプロトコルを使用して配信することができる。たとえば、要求処理ユニット70は、クライアントデバイス40からマルチキャストグループ参加要求を受信するように構成され得る。すなわち、サーバデバイス60は、マルチキャストグループに関連するインターネットプロトコル(IP)アドレスを、クライアントデバイス40を含む、特定のメディアコンテンツ(たとえば、生の事象のブロードキャスト)に関連するクライアントデバイスに通知することができる。次にクライアントデバイス40は、マルチキャストグループに参加することを求める要求を提出することができる。この要求は、ネットワーク74、たとえばネットワーク74を構成するルータを通じて伝搬され、それによりルータに、マルチキャストグループに関連するIPアドレス宛のトラフィックを、クライアントデバイス40などの加入側クライアントデバイスに向けさせることができる。
図1の例で示されるように、マルチメディアコンテンツ64は、メディアプレゼンテーション記述(MPD)に対応し得る、マニフェストファイル66を含む。マニフェストファイル66は、様々な代替の表現68(たとえば、品質が異なるビデオサービス)の説明を含んでよく、この説明は、たとえば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の説明のための特性を含み得る。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、表現68のセグメントにどのようにアクセスするかを決定することができる。
特に、取出しユニット52は、クライアントデバイス40の構成データ(図示せず)を取り出して、ビデオデコーダ48の復号能力およびビデオ出力44のレンダリング能力を判定することができる。構成データはまた、クライアントデバイス40のユーザによって選択される言語の選好、クライアントデバイス40のユーザによって設定される深さの選好に対応する1つもしくは複数のカメラ視野、および/または、クライアントデバイス40のユーザによって選択されるレーティングの選好のいずれかまたはすべてを含み得る。取出しユニット52は、たとえば、HTTP GET要求および部分GET要求を提出するように構成されたウェブブラウザまたはメディアクライアントを含み得る。取出しユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行される、ソフトウェア命令に対応し得る。いくつかの例では、取出しユニット52に関して説明された機能のすべてまたは一部は、ハードウェア、ハードウェアの組合せ、ソフトウェア、および/またはファームウェアで実装されてよく、この場合、必須のハードウェアは、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
取出しユニット52は、クライアントデバイス40の復号能力およびレンダリング能力を、マニフェストファイル66の情報によって示される表現68の特性と比較することができる。取出しユニット52は最初に、マニフェストファイル66の少なくとも一部分を取り出して、表現68の特性を判定することができる。たとえば、取出しユニット52は、本開示の技法に従って、1つまたは複数の適応セットの特性を説明する、マニフェストファイル66の一部分を要求することができる。取出しユニット52は、クライアントデバイス40のコーディング能力およびレンダリング能力によって満たされ得る特性を有する、表現68のサブセット(たとえば、適応セット)を選択することができる。取出しユニット52は次いで、適応セット中の表現に対するビットレートを判定し、ネットワーク帯域幅の現在利用可能な量を判定し、ネットワーク帯域幅によって満たされ得るビットレートを有する表現のうちの1つからセグメントを取り出すことができる。
一般に、表現のビットレートが高くなると、ビデオ再生の品質が高くなる一方、表現のビットレートが低くなると、利用可能なネットワーク帯域幅が縮小したときに、ビデオ再生の品質が十分なものになり得る。したがって、利用可能なネットワーク帯域幅が比較的広いときには、取出しユニット52は、ビットレートが比較的高い表現からデータを取り出すことができ、利用可能なネットワーク帯域幅が狭いときには、取出しユニット52は、ビットレートが比較的低い表現からデータを取り出すことができる。このようにして、クライアントデバイス40は、ネットワーク74を通じてマルチメディアデータをストリーミングすることができる一方、ネットワーク74の変化するネットワーク帯域幅の利用可能性に適応することもできる。
追加または代替として、取出しユニット52は、ブロードキャストまたはマルチキャストのネットワークプロトコル、たとえばeMBMSまたはIPのマルチキャストに従ってデータを受信するように構成され得る。そのような例では、取出しユニット52は、特定のメディアコンテンツに関連するマルチキャストネットワークグループに参加することを求める要求を提出することができる。取出しユニット52はマルチキャストグループに参加した後、サーバデバイス60またはコンテンツ準備デバイス20にさらなる要求を出すことなしに、マルチキャストグループのデータを受信することができる。取出しユニット52は、マルチキャストグループのデータが必要ではなくなったときにマルチキャストグループを離れること、たとえば再生を止めること、または異なるマルチキャストグループにチャネルを変えることを求める要求を出すことができる。
ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、取出しユニット52に提供することができ、次に取出しユニット52は、セグメントをカプセル化解除ユニット50に提供することができる。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送信することができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送信し、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数の表示を含み得る復号したビデオデータを、ビデオ出力44に送信する。
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、およびカプセル化解除ユニット50は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せのような、種々の適切な処理回路のいずれかとして、適宜実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、取出しユニット52、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/または携帯電話のようなワイヤレス通信デバイスを含み得る。
クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、本開示の技法に従って動作するように構成され得る。例として、本開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技法を説明する。しかしながら、コンテンツ準備デバイス20は、サーバデバイス60の代わりにこれらの技法を実行するように構成され得ることを理解されたい。
カプセル化ユニット30は、NALユニットが属するプログラム、ならびにペイロード、たとえばオーディオデータ、ビデオデータ、またはNALユニットが対応するトランスポートまたはプログラムストリームの記述データを特定するヘッダを含むNALユニットを形成することができる。たとえば、H.264/AVCにおいて、NALユニットは、1バイトのヘッダおよび可変サイズのペイロードを含む。そのペイロード内にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベルを含むことができる。たとえば、NALユニットは、ビデオデータのブロック、複数のブロック、ビデオデータのスライス、またはビデオデータの全ピクチャを含むことができる。カプセル化ユニット30は、ビデオエンコーダ28からの符号化ビデオデータをエレメンタリストリームのPESパケットの形で受信することができる。カプセル化ユニット30は、各エレメンタリストリームを対応するプログラムと関連付けることができる。
カプセル化ユニット30はまた、複数のNALユニットからアクセスユニットを組み立てることができる。一般に、アクセスユニットは、ビデオデータのフレームならびにそのようなオーディオデータが利用可能であるときにそのフレームに対応するオーディオデータを表すために1つまたは複数のNALユニットを含むことができる。アクセスユニットは、一般に、1つの出力時間インスタンスに対するすべてのNALユニット、たとえば1つの時間インスタンスに対するすべてのオーディオデータおよびビデオデータを含む。たとえば、各ビューが20フレーム毎秒(fps)のフレームレートを有する場合、各時間インスタンスは、0.05秒の時間間隔に対応することができる。この時間間隔の間、同じアクセスユニット(同じ時間インスタンス)のすべてのビューに対する特定のフレームは、同時にレンダリングされ得る。一例では、アクセスユニットは、一次コード化ピクチャとして提示され得る、1つの時間インスタンス内のコード化ピクチャを含むことができる。したがって、アクセスユニットは、共通の時間インスタンスのすべてのオーディオフレームおよびビデオフレーム、たとえば時刻Xに対応するすべてのビューを含むことができる。本開示はまた、特定のビューの符号化ピクチャを「ビューコンポーネント(view component)」と呼ぶ。すなわち、ビューコンポーネントは、特定の時刻における特定のビューに対する符号化ピクチャ(またはフレーム)を含むことができる。したがって、アクセスユニットは、共通の時間インスタンスのすべてのビューコンポーネントを含むものとして定義され得る。アクセスユニットの復号順序は、必ずしも出力または表示の順序と同じである必要はない。
メディアプレゼンテーションは、異なる代替表現(たとえば、異なる品質を有するビデオサービス)の記述を含み得るメディアプレゼンテーション記述(MPD)を含むことができ、記述は、たとえばコーデック情報、プロファイル値、およびレベル値を含むことができる。MPDは、マニフェストファイル66など、マニフェストファイルの一例である。クライアントデバイス40は、メディアプレゼンテーションのMPDを取り出して、様々なプレゼンテーションの動画フラグメントにどのようにアクセスするかを決定することができる。動画フラグメントは、ビデオファイルの動画フラグメントボックス(ムーフボックス(moof box))内に配置され得る。
マニフェストファイル66(たとえば、MPDを含むことができる)は、表現68のセグメントの利用可能性を広告することができる。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になる壁時計時刻を示す情報、ならびに表現68内のセグメントの持続時間を示す情報を含むことができる。このようにして、クライアントデバイス40の取出しユニット52は、開始時刻ならびに特定のセグメントに先行するセグメントの持続時間に基づいて、各セグメントが利用可能になる時を判定することができる。取出しユニット52は、初期に、クライアントデバイス40の内部クロックをサーバデバイス60(またはコンテンツ準備デバイス20)のクロックと同期させ、次いで、(たとえば、適用によって)、セグメントが利用可能になるとすぐに表現68のうちの1つまたは複数からセグメントを要求することができる。
いくつかの場合には、しかしながら、クライアントデバイス40の内部クロックは、サーバデバイス60のクロックに対してドリフトすることがある。取出しユニット52は、クライアントデバイス40のクロックを同期させてそのようなドリフトに対処するために、本開示の技法を利用するように構成され得る。このようにして、取出しユニット52は、表現68のうちの1つまたは複数の特定のファイルが取出しのために利用可能であるかどうかを判定するために、クライアントデバイス40の再同期されたクロックおよびマニフェストファイル66のデータを使用することができる。
一般に、本開示の技法は、セグメント利用可能性窓の片方または両方の「縁部」を検出するために、複数のプロービング要求(たとえば、メディアセグメントに対するHTTP HEAD要求)を送信するクライアントデバイス40を伴う。セグメント利用可能性窓は、取出しのために現在の利用可能なセグメントのセットに対応することができる。「最も古い」縁部(時々「左」縁部とも呼ばれる)は、セグメント利用可能性窓の最早のセグメントの始端に対応する一方、「最も新しい」縁部(時々「右」縁部とも呼ばれる)は、セグメント利用可能性窓の最新のセグメントの終端に対応し得る。これらの縁部に基づいて、クライアントデバイス40の取出しユニット52は、クライアントデバイス40のクロックとサーバデバイス60のクロックとの間の時間デルタを推測することができる。言い換えれば、取出しユニット52は、サーバデバイス60によって与えられたプロービング要求に対する応答に基づいてセグメント利用可能性窓の左および右の縁部を判定することができる。プロービング要求に対するこれらの応答は、サーバデバイス60のセグメント利用可能性窓の理解に基づくことができる。
一般に、セグメント利用可能性窓の右縁部は、リアルタイムビデオ作成遅延によって限定されるので、より有用であると見なされ得る。右縁部を推定することは、成功するセグメントの取出しと不要なエンドツーエンドレイテンシの最小化との間のよいトレードオフの達成を助けることができる。セグメント利用可能性窓の左縁部は、利用可能性開始時刻と時間シフトバッファ深さ(TSBD)の両方によって制御される。TSBDは、MPD内の随意の属性(たとえば、マニフェストファイル66)である。「動的」MPDタイプに対して、TSBDは、MPDから失われるとき「無限」であると解釈されるべきである。TSBDが無限であるとき、セグメント要求時刻がセグメント利用可能性開始時刻の後である限り、セグメントは、常に利用可能である。
時間デルタ推定アルゴリズムは、始動時刻におけるセグメント取出しの間に複数の失敗が発生するときに後方プロービング方法をトリガすることができる始動トリガ論理など、いくつかの部品を含むことができる。後方プロービング方法は、セグメント利用可能性窓の右縁部を検出するように設計される。別の方法は、前方プロービング方法と呼ばれ、それは、後方プロービングが不確定な応答を取得したとき、またはセグメント利用可能性窓の右縁部が検出されかつクライアントデバイス40の取出しユニット52が時間の経過と共に右縁部を追跡することを望むときに使用され得る。
セグメント利用可能性窓に対するいくつかの概念が、本開示の技法のよりよい理解のために役立ち得る。DASHライブストリーミングにおいて、セグメントは、所与のセグメントに対する(たとえば、コンテンツ準備デバイス20による)メディア作成が完了し、メディアセグメントがサーバデバイス60上に記憶されるときに利用可能になる。MPDからの情報(図1の例のマニフェストファイル66)を使用するセグメントタイムライン計算を介して、クライアントデバイス40の取出しユニット52は、セグメントが利用可能になる最早の時刻を計算することができる。これは、セグメント利用可能性開始時刻と呼ばれる。加えて、時間シフトバッファを介して、取出しユニット52は、どのくらい長くセグメントが利用可能性開始時刻から利用可能であるかを判定することができる。ストリーミングアプリケーションの要求に基づいて、取出しユニット52は、セグメントが利用可能になるとすぐにセグメントを取り出すように、または最新の利用可能なセグメントから時間的にいくらかさかのぼってセグメントを取り出すように構成され得る。
これら2つの戦略は、各々、利点と欠点とを有することがある。前者は、可能な限り最後の1秒までのコンテンツをビューアに提示しようと努力する一方、特にビデオ作成および配信プロセスにおけるタイミングジッタに遭遇するとき、ビデオ配信における安定性を潜在的に犠牲にする。後者は、一般的に、より高いエンドツーエンドレイテンシという犠牲を払う可能性の下で、全体的によりよいユーザエクスペリエンスを達成することができる。セグメントタイムラインおよびTSBDを使用して、取出しユニット52は、任意の所与の壁時計時刻において、どのセグメントが利用可能であるかを判定することができる。セグメント利用可能性窓の例については、以下の図3を参照して説明する。
取出しユニット52は、様々な理由でセグメント利用可能性窓(またはセグメント利用可能性窓の少なくとも1つの縁部)を判定するように構成され得る。たとえば、取出しユニット52は、特定のライブストリームを開始するために最初にセグメント利用可能性窓を判定するように構成され得る。加えてまたは代替として、取出しユニット52は、一定の数(または割合)のサーバデバイス60からのエラーメッセージ、たとえばHTTP 404エラーメッセージを受信した後、セグメント利用可能性窓を判定するように構成され得る。
そのようなエラーは、クライアントデバイス40のクロックがサーバデバイス60のクロックから(または広告された利用可能性の時刻から)逸脱するときに発生することがある。すなわち、そのようなクロックドリフトに応答して、クライアントデバイス40は、セグメント利用可能性タイムラインを正確に判定しない。ある場合には、クライアントデバイス40のクロックは、サーバデバイス60のクロックより進んでいることがある。クライアントデバイス40のクロックがサーバデバイス60のクロックより進んでいるときに、(クライアントデバイス40のクロックおよびセグメント利用可能性開始時刻を使用して)セグメントが利用可能になったと取出しユニット52が判定するとすぐに、取出しユニット52がメディアセグメントを取り出すことを試みる場合、クライアントは、メディアセグメント要求に応答するHTTP 404 Not Availableエラーメッセージを受信する。取出しユニット52が無難な始動戦略を使用する場合、取出しユニット52は、TSBD(すなわち、セグメント利用可能性窓)の左縁部からメディアセグメントを要求することができ、したがって、セグメント取出しは成功し得る。しかし、その場合でも、クロックデルタは、取出しユニット52が、予想した量のメディアバッファを構築するのを妨げることがある。
セグメント要求失敗トリガ機構は、セグメント利用可能性窓判定プロセスを開始するために使用され得る。セグメント要求失敗トリガは、ビデオ再生が開始され、クライアントデバイス40がメディアセグメント要求に対して繰り返し404エラーメッセージを受信した後でアクティブになることができる。クライアントデバイス40は、送信された連続的なメディアセグメント要求の数と、それらの要求に対して得られた404エラーメッセージ応答の数とについて実行中のカウント(running count)を維持することができる。クライアントが、最後のNr個のメディアセグメント要求に対してNf個以上の404応答コードを受信する場合、プロービング方法がトリガされ、ここでNfは404エラーコードを有する応答の数を定義する設定可能パラメータであり、Nrは送信された連続的なメディアセグメント要求の数を定義する設定可能パラメータである。いくつかの例では、Nrは5の値を有し、Nfは2の値を有することがある。
追加の制御パラメータ、最小時間間隔(MTI)が、どれくらいの頻度でプロービング試験が実行されるかを制御するために使用され得る。MTIは、プローブ要求のセットの間の最小時間間隔を記述することができる。このパラメータは、プロービングが、高いオーバーヘッドを招くほどの頻度で実行されないことを確保するように使用され得る。MTIの初期値の一例は、1分である。MTIの他の値が、たとえば、受信されたエラーの頻度に基づいて初期値または動的に調整される値として使用され得る。
取出しユニット52がプロービング結果を取得した後、取出しユニット52は、推定されたクロック差に基づいて取出し挙動を調整することができる。様々なアクションが実行されてよく、これらのアクションは、元のプロービングを生じたトリガに基づくことができる。
いくつかの例では、再生を開始することに失敗すると、プロービングを生じることができる。最初にビデオデータの再生を開始することに失敗した後でプロービングを生じる場合、またはプロービングアルゴリズムが終了する前にクライアントデバイス40がすでに停止している場合、(取出しユニット52に対応し得る)クライアントデバイス40のDASHクライアントは、アイドル状態にあると見なされ得る。この場合、取出しユニット52は、調整されたサーバ時刻を判定するために、クライアントデバイス40のローカルクロックに時間デルタを適用することができる。調整されたサーバ時刻を使用して、取出しユニット52は、判定された時点からダウンロードを開始することができる。これは、(適当なバッファを構築するために)最新の利用可能セグメントより数秒遅れたセグメントを要求するために、取出しユニット52が時間的にさかのぼることを伴うことがある。
別の例として、不正確なクライアントクロックを用いて成功した再生が、プロービングを促すことがある。クライアントデバイス40がビデオストリームをすでに再生しているとき、時間デルタ推定アルゴリズムを使用することによって、クライアントデバイス40は、クライアントデバイス40のローカルクロックとサーバデバイス60のクロックとの間に時間デルタが存在すると判定することができる。この場合、クライアントデバイス40は、以下の3つの方法のうちの1つにおいて動作することができる。これらのクライアントアクションを、以下の例に従って説明する。クライアントデバイス40は、10秒バッファを構築し、10秒レイテンシを達成するために、最新の利用可能セグメントから10秒戻ってメディアコンテンツを要求することによって、メディアバッファとエンドツーエンドレイテンシとの間の最適なトレードオフを達成しようと試みていると仮定する。しかしながら、第1の場合、クライアントデバイス40のローカルクロックは、サーバデバイス60のクロックより5秒だけ進んでいる。その結果、クライアントデバイス40は、最大で5秒のメディアバッファしか構築できず、かつ最大で5秒のレイテンシを有する。第2の場合、クライアントデバイス40のローカルクロックは、サーバデバイス60のクロックより5秒だけ遅れている。その結果、クライアントデバイス40は、15秒のレイテンシを有するという犠牲を払って、15秒のバッファを構築できる。
一例では、クライアントデバイス40は、特別なアクションをとることなく、成功する再生に応答することができる。クライアントデバイス40の実際のメディアバッファおよびレイテンシは、最適なトレードオフから5秒ずれているので、クライアントデバイス40は、時間デルタの検出に応答して、いかなる追加の動作も実行することはないと判定することができる。いくつかの例では、クライアントデバイス40内の異なるメディアバッファが、レート選択アルゴリズムにおいて異なるレベルのアグレッシブネスをもたらすことがある。それゆえ、時間デルタ(クライアントデバイス40のローカルクロックがサーバデバイス60のクロックより進んでいるかまたは遅れているかのいずれか)、および正確な情報が、レート切替えアルゴリズムに与えられると、レート切替えアルゴリズムは、当然、レート判定アグレッシブネスのために内部パラメータを調整することができる。
別の例では、クライアントデバイス40は、メディアデータの再生の煩わしい調整を実行することがある。たとえば、10秒メディアバッファと10秒レイテンシとのより最適なトレードオフを達成するために、クライアントデバイス40は、ビューイングエクスペリエンスを一時的に低下させるという犠牲を払って徹底的に動作することがある。第1の場合、クライアントデバイス40のローカルクロックが進んでいるとき、クライアントデバイス40は、ビデオ再生を5秒間停止して、目標の10秒バッファを構築することができる。バッファレベルが10秒に到達すると、クライアントデバイス40は、バッファレベルとレイテンシとが目標の値になるように再生を再開することができる。クライアントデバイス40のローカルクロックが遅れている場合には、クライアントデバイス40は、5秒のビデオコンテンツをスキップし、プレゼンテーション時刻を5秒だけ飛び越して目標のプレゼンテーション時刻(t-10)に到達させる。このようにして、クライアントデバイス40は、より短いレイテンシを達成することができる。一般に、停止またはスキップのいずれも、よいユーザエクスペリエンスをもたらさない。しかし、そのような動作がさらなる停止の低減またはリアルタイムに近いビューイングエクスペリエンスの提供を目的として一度だけ実行される場合は、この徹底的な動作が正当化され得る。
このようにして、クライアントデバイス40のローカルクロックとサーバデバイス60のクロックとの間の時間差が、ローカルクロックがサーバデバイス60のクロックより進んでいることを示すとき、クライアントデバイス40は、時間差に等しい時間期間の間、メディア再生を停止することがある。他方では、クライアントデバイス40のローカルクロックとサーバデバイス60のクロックとの間の時間差が、ローカルクロックがサーバデバイス60のクロックより遅れていることを示すとき、クライアントデバイス40は、時間差に等しい時間期間の間、メディア再生をスキップすることがある。
さらに別の例では、クライアントデバイス40は、メディアデータの再生の煩わしくない調整を実行することがある。たとえば、上記で説明したように停止またはスキップを導入するような煩わしい動作を使用する代わりに、より精通したクライアントは、同じ目的を達成するために煩わしくない動作を使用することができる。クライアントデバイス40のローカルクロックが時間的に進んでいるとき、クライアントデバイス40は、1秒の符号化メディアが、毎回、(1+α)秒で再生されるように、再生速度を少しスローダウンすることができ、ここでαは0.03などの小さい値である。再生速度をスローダウンすることによって、クライアントデバイス40は、徐々により多くのメディアバッファを構築し、レイテンシを増大することができる。同様に、クライアントデバイス40のローカルクロックがサーバデバイス60のクロックより時間的に遅れているとき、クライアントデバイス40は、再生速度をわずかに加速することができる。そうすることによって、クライアントは、徐々に、メディアバッファを消費し、レイテンシを低減することができる。クライアントデバイス40が目標のメディアバッファおよびレイテンシレベルに到達すると、クライアントデバイス40は、バッファレベルおよびレイテンシを維持するために、通常の再生速度に切り替えて戻すことができる。この例は、ビューアが、クライアントがとる調整に気づくこともないという利点を有する。それゆえ、クライアントデバイス40がそのような複雑な動作をサポートし得る限り、よりよいユーザエクスペリエンスが提供され得る。
このようにして、時間差が、クライアントデバイス40のローカルクロックがサーバデバイス60のクロックより進んでいることを示すとき、クライアントデバイス40は、時間差がゼロになるまで通常再生速度より少し速い速度でメディアデータを再生することができる。他方では、時間差が、クライアントデバイス40のローカルクロックがサーバデバイス60のクロックより遅れていることを示すとき、クライアントデバイス40は、時間差がゼロになるまで通常再生速度より少し遅い速度でメディアデータを再生することができる。
ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、およびカプセル化解除ユニット50は各々、1つまたは複数のマイクロプロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、ディスクリート論理回路、ソフトウェア、ハードウェア、ファームウェア、またはこれらの任意の組合せのような、種々の適切な処理回路のいずれかとして、適宜実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたビデオエンコーダ/デコーダ(コーデック)の一部として統合され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれてよく、これらのいずれもが、結合されたコーデックの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、および/またはカプセル化解除ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/または携帯電話のようなワイヤレス通信デバイスを含み得る。
カプセル化ユニット30が、受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルに統合した後、カプセル化ユニット30は、ビデオファイルを出力のために出力インターフェース32に渡す。いくつかの例では、カプセル化ユニット30は、ビデオファイルを直接クライアントデバイス40に送信する代わりに、ビデオファイルをローカルに記憶するかまたはビデオファイルを出力インターフェース32を介してリモートサーバに送信することができる。出力インターフェース32は、たとえば、送信機、トランシーバ、たとえばオプティカルドライブ、磁気媒体ドライブ(たとえば、フロッピー（登録商標）ドライブ)などのコンピュータ可読媒体にデータを書き込むためのデバイス、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースを含むことができる。出力インターフェース32は、たとえば送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体など、コンピュータ可読媒体34にビデオファイルを出力する。
ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、NALユニットまたはアクセスユニットを取出しユニット52を介してカプセル化解除ユニット50に提供する。カプセル化解除ユニット50は、ビデオファイルの要素を、構成要素であるPESストリームへとカプセル化解除し、PESストリームをパケット化解除して符号化データを取り出し、たとえば、ストリームのPESパケットヘッダによって示されるように、符号化データがオーディオストリームの一部かビデオストリームの一部かに応じて、符号化データをオーディオデコーダ46またはビデオデコーダ48のいずれかに送信することができる。オーディオデコーダ46は、符号化オーディオデータを復号し、復号したオーディオデータをオーディオ出力42に送信し、一方でビデオデコーダ48は、符号化ビデオデータを復号し、ストリームの複数の表示を含み得る復号したビデオデータを、ビデオ出力44に送信する。
このようにして、クライアントデバイス40は、メディアデータを取り出すためのデバイスの一例を表し、デバイスは、ライブのストリーミングサービスを使用してメディアデータを提供するサーバデバイスにメディアデータのセグメントに対する複数のプローブ要求を送信することと、セグメント利用可能性窓の左縁部および右縁部を判定するために複数のプローブ要求に対する応答を分析することと、ライブのストリーミングサービスに従って、セグメント利用可能性窓の判定された左縁部および判定された右縁部に基づいてセグメント利用可能性窓内のセグメントに対する要求を送信することとを行うように構成された1つまたは複数のプロセッサを含む。
図2は、例示的なマルチメディアコンテンツ102の要素を示す概念図である。マルチメディアコンテンツ102は、マルチメディアコンテンツ64(図1)、または記憶媒体62に記憶された別のマルチメディアコンテンツに対応し得る。図2の例では、マルチメディアコンテンツ102は、メディアプレゼンテーション記述(MPD)104および複数の表現110〜120を含む。表現110は、任意選択のヘッダデータ112およびセグメント114A〜114N(セグメント114)を含み、一方で表現120は、任意選択のヘッダデータ122およびセグメント124A〜124N(セグメント124)を含む。文字Nが、便宜的に、表現110、120の各々の最後の動画フラグメントを指定するために使用される。いくつかの例では、表現110、120の間に、異なる数の動画フラグメントがあり得る。
MPD104は、表現110〜120とは別個のデータ構造を含み得る。MPD104は、図1のマニフェストファイル66に対応し得る。同様に、表現110〜120は、図1の表現68に対応し得る。一般に、MPD104は、コーディングおよびレンダリングの特性、適応セット、MPD104が対応するプロファイル、テキストタイプ情報、カメラ角度情報、レーティング情報、トリックモード情報(たとえば、時間的なサブシーケンスを含む表現を示す情報)、および/または離れた期間を取り出すための情報(たとえば、再生中のメディアコンテンツへの、ターゲットを定めた広告の挿入)のような、表現110〜120の特性を一般に表す、データを含み得る。本開示の技法によれば、MPD 104は、図1を参照して上記で説明したように、UTCTiming情報を含むことができる。
ヘッダデータ112は、存在する場合、セグメント114の特性、たとえば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間ロケーション、セグメント114のいずれがランダムアクセスポイントを含むか、セグメント114内のランダムアクセスポイントに対するバイトオフセット、セグメント114のユニフォームリソースロケータ(URL)、またはセグメント114の他の側面を表すことができる。ヘッダデータ122は、存在する場合、セグメント124の同様の特性を表すことができる。加えて、または代替的に、そのような特性はMPD104内に完全に含まれ得る。
セグメント114、124は、1つまたは複数のコード化ビデオサンプルを含み、ビデオサンプルの各々が、ビデオデータのフレームまたはスライスを含み得る。セグメント114のコード化ビデオサンプルの各々は、同様の特性、たとえば、高さ、幅、および帯域幅の要件を有し得る。そのような特性は、MPD104のデータによって表され得るが、そのようなデータは図2の例には示されていない。MPD104は、本開示で説明されるシグナリングされた情報のいずれかまたはすべてが加えられた、3GPP仕様によって表されるような特性を含み得る。
セグメント114、124の各々は、固有のユニフォームリソースロケータ(URL)に関連付けられ得る。したがって、セグメント114、124の各々は、DASHのようなストリーミングネットワークプロトコルを使用して、独立して取出し可能であり得る。このようにして、クライアントデバイス40のような宛先デバイスは、HTTP GET要求を使用して、セグメント114または124を取り出すことができる。いくつかの例では、クライアントデバイス40は、HTTP部分GET要求を使用して、セグメント114または124の特定のバイト範囲を取り出すことができる。
上記で説明したように、MPD104は、表現110、120の第1のセグメントが利用可能になった時を広告する情報をさらに含むことができる。この例では、MPD104は、セグメント114A、124Aが最初に利用可能になった時を示す情報を含むことができる。したがって、クライアントデバイス40などのクライアントデバイスは、示された時刻にセグメント114A、124Aのいずれかを取り出すことができる。その上、MPD 104は、再生時間に関してセグメント114、124の持続時間を示す情報を含むことができる。したがって、クライアントデバイス40は、セグメント114A、124Aが利用可能になる時刻(MPD104によって示される)およびセグメント114A、124Aの持続時間(同じく、MPD104によって示される)に基づいて、セグメント114B、124Bが利用可能になる時刻を判定することができる。セグメント114、124は、同じ持続時間(再生時間に関して)を有することがあり、その場合には、MPD104は単一の持続時間の値を示すことができ、またはセグメント114、124は、異なる持続時間を有することがあり、その場合には、MPD104は、セグメント114、124の各々に対して個別の持続時間の値を示すことができる。代替として、セグメント114、124が時間的に整列されて異なる持続時間を有すると仮定すると、MPD104は、対応するセグメントに対して個別の持続時間の値(たとえば、セグメント114A、114Bに適用可能な持続時間の値、セグメント114B、124Bに適用可能な別の持続時間の値、など)を通知する(signal)ことができる。
加えて、マルチメディアコンテンツ102がライブでストリーミングされると仮定すると、セグメント114、124のうちのいくつかのセグメントは、一定の時間量の後、特にデータの記録、符号化、およびカプセル化の後にだけ利用可能になることがある。クライアントデバイス40は、様々な例において、セグメント114、124の任意のシーケンスを含むことができるセグメント利用可能性窓を判定するために本開示の技法を使用することができる。すなわち、セグメント利用可能性窓は、広告された利用可能性の時刻およびクロックの同時性に厳格に基づくのではなく、セグメントに対する要求への応答によって示される、セグメントが実際に利用可能になった時に基づいて判定され得る。これらの技法について、図3〜図9に関して以下でより詳細に説明する。
図3は、セグメントのセット150に対する例示的なセグメント利用可能性窓152を示す概念図である。セグメントは、図3に三角形として表されている。この例では、時間シフトバッファ深さ(TSBD)にW個のセグメントの幅を持たせている。さらに、クライアントデバイス40は、壁時計時刻tに基づいて、最新の利用可能セグメントが図3の「i」と標示されたセグメントに対応すると判定したものと仮定する。これらの仮定に基づいて、図3は、利用可能セグメントのスナップショット、すなわち、セグメント利用可能性窓152を示す。特に、セグメント利用可能性窓は、位置i-W+1(i-(W-1))におけるセグメントで始まる左縁部154と、現在のセグメントiで終わる右縁部156とを含む。左縁部154(すなわち、位置i-W+1におけるセグメント)を定義するセグメントは、図3の点線の外形線を使用して示される。
言い換えれば、クライアントデバイス40は、メディアセグメントに対する、HTTP HEAD要求などのプロービング要求を送信することができる。特に、クライアントデバイス40は、(クライアントデバイス40のクロックに従って判定された)最新の利用可能セグメントから開始して時間的にさかのぼるW個のプロービング要求を実質的に同時に送信することができる。これらのプロービング要求によってカバーされる時間間隔はW*Dであり得、ここでDはセグメントの持続時間であり、セグメントは(再生時間に関して)等しい持続時間を有すると仮定する。本開示は、DASH内の大半のHTTP 404エラーが、クライアントデバイスのクロックがサーバデバイスのクロックより進んでいることによって引き起こされるものと認識している。このように時間的にさかのぼってプロービングすることは、TSBD窓の右縁部を発見するために使用され得る。
代替として、クライアントデバイス40は、時間的に進めてのみプロービングすることができる。これは、後方プロービングと同様であるが、クライアントデバイス40のクロックが、TSBD持続時間より長く、サーバデバイス60のクロックより遅れている場合の問題に対処するために使用されることがある。TSBDの左縁部は、たとえば、以下の図6および図7に示すいくつかのパターンによって発見され得る。さらに別の例として、以下でより詳細に説明する図4に示すように、前方と後方の両方のプローブ要求が送信されてもよい。
図4は、セグメント利用可能性窓を判定するためにプロービング要求が送信され得るセグメントを示す概念図である。上記のように、クライアントデバイス40の取出しユニット52は、サーバデバイス60から一定の数の404エラーメッセージを受信すること、またはストリーム始動においてなど、様々な基準に基づいてセグメント利用可能性窓を判定するためのプロセスを開始するように構成され得る。いずれの場合も、取出しユニット52は、本開示の技法に従って、いくつかの連続セグメントに向けられたプローブ要求のシーケンスを送信することができる。図4の例では、取出しユニット52は、クライアントデバイス40のクロックによる最新の利用可能セグメントであるセグメントi付近に中心を置くセグメントに対するプローブ要求(たとえば、HTTP HEAD要求)を送信する。この例では、プローブ要求のシーケンスは、セグメントi-N〜i+Nの各々に対する個別の要求を含み、ここでNは整数値である。しかしながら、他の例では、プローブ要求のシーケンスは、セグメントi-M〜i+Nに対する個別の要求を含むことがあり、ここでMおよびNは等しくても等しくなくてもよく、MまたはNのいずれかがゼロであってもよい。
言い換えれば、プロービング方法が開始されると、クライアントデバイス40は、メディアセグメントに対するいくつかのプロービング要求を相次いで(すなわち、パイプラインで)送信することができる。いくつかの例では、プロービング要求は、セグメントの利用可能性の検出を目的とする、所与のメディアセグメントに対するHTTP HEAD要求である。他の例では、比較的少量のデータ(たとえば、100バイト)に対するHTTP部分GET要求など、他のタイプの要求が使用され得る。時刻tにおいて、クライアントデバイス40の取出しユニット52は、クライアントデバイス40のクロックに基づいて最新の利用可能セグメント番号iを計算することができる。プロービング要求方法が、始動トリガによって開始される場合、クライアントデバイス40は、セグメントiに対する要求が失敗する可能性があると予測することができる。したがって、取出しユニット52は、セグメントiおよびその付近のセグメントに対して、セグメント(i-N)〜セグメント(i+N)に及ぶ、(2N+1)個のプロービング要求を送信することができる。これらは、応答メッセージ本体の中にデータをほとんど持たない、非常に小さいHTTP要求であるので、比較的短い時間量、たとえば1秒の間隔の中ですべての要求がサーバによって受信されることが予想され得、比較的短い時間量、たとえば1秒の間隔の中ですべての応答がクライアントデバイス40によって受信されることが予想され得る。言い換えれば、応答の集合が、セグメント利用可能性窓のサーバデバイス60のビューのスナップショットとして見られ得る。
クライアントデバイス40の取出しユニット52は、セグメント利用可能性窓の左および/または右の縁部を判定するためにプローブ要求に対する応答を使用することができる。加えてまたは代替として、取出しユニット52は、クライアントデバイス40のクロックとサーバデバイス60のクロックとの間の差(時間デルタとも呼ばれる)を判定することができる。特に、クライアントデバイス40とサーバデバイス60との間の時間デルタは、プローブ要求に対するサーバデバイス60からの応答パターンに基づいて推測され得る。
図5〜図9は、取出しユニット52によって送信された図4のプロービング要求に対する様々な可能な応答パターンを示す概念図である。図5〜図9において、黒く陰った三角形は、利用可能セグメント、すなわちプロービング要求がエラーのない応答(たとえば、HTTP 200応答)を有していたセグメントを表す。図5〜図9において、陰のない三角形は、利用できないセグメント、すなわちプロービング要求がエラー応答(たとえば、HTTP 404応答)を有していたセグメントを表す。
図5は、クライアントデバイス40のクロックがサーバデバイス60のクロック(またはより一般的には、セグメントiの利用可能性に対して広告された時刻)より進んでドリフトしたときの例示的なエラーパターンを表す。この例では、クライアントデバイス40のクロックは、セグメントiが利用可能であることを示す。すなわち、クライアントデバイス40のクロックは、たとえば、マニフェストファイル66など、MPD内で広告されるような、セグメントiに対して広告された利用可能時刻に等しいかまたはそれを超える。しかしながら、応答パターンは、セグメントi-k-1までのセグメントだけが利用可能であることを示す。すなわち、セグメント(i-k)〜iに対する要求への応答は、HTTP 404エラーを示す。それゆえ、セグメントi-k-1は、セグメント利用可能性窓の右縁部を表す。成功した応答と失敗した応答との間の境界に基づいて、クライアントデバイス40の取出しユニット52は、クライアントデバイス40のクロックの間の時間デルタを推定することができる。セグメントi〜(i-k)に対して応答が404エラーコードであるが、セグメント(i-k-1)〜(i-N)に対して応答が200コードである場合、取出しユニット52は、以下の式(6)
Figure 0006240224
に従って時間デルタを推定することができる。
セグメントが等しい持続時間Dを有するとき、推定された時間デルタは、単に、(k+1)*Dであり得る。
図6は、クライアントデバイス40のクロックがサーバデバイス60のクロック(またはより一般的には、セグメントiの利用可能性に対して広告された時刻)より遅れているときの例示的なエラーパターンを表す。クライアントデバイス40のクロックが、セグメントiに対する利用可能性の広告された時刻より遅れており(たとえば、サーバデバイス60のクロックより遅れており)、この時間差がセグメント要求不良を生じるとき、セグメント要求時刻がTSBD(すなわち、セグメント利用可能性窓)の左縁部から外れたのは、一般的に、クライアントデバイス40のクロックが、それまでに、サーバデバイス60のクロックより遅れていたからである。この例では、クライアントデバイス40のクロックは、セグメントiが利用可能であることを示す。すなわち、クライアントデバイス40のクロックは、セグメントiの利用可能性に対して広告された時刻に等しいかまたはそれより後であるが、セグメントiがセグメント利用可能性窓から除去されることを広告される時刻より前の時刻を示すことができる。しかしながら、図6の応答パターンは、セグメントi+kに続くセグメントだけが利用可能であることを示す。
応答パターンが、セグメントiからセグメント(i+k)まで404エラーコードを示し、セグメント(i+k+1)より前方で成功コードを示すとき、成功応答コードと失敗応答コードとの間(すなわち、(i+k)と(i+k+1)との間)の境界が、TSBD(すなわち、セグメント利用可能性窓)の左縁部であると見なされる。クライアントデバイス40の取出しユニット52は、クライアントデバイス40のクロックとサーバデバイス60のクロックとの間のデルタを、以下の式(7)
Figure 0006240224
に従って推測することができる。
図7は、クライアントデバイス40のクロックがセグメント利用可能性窓の中にあるが、サーバデバイス60(またはより一般的には、セグメントiの利用可能性に対して広告された時刻)と完全に同期しているとは限らないときの例示的なエラーパターンを表す。上記のように、プローブ要求プロセスを開始するトリガは随意である。したがって、取出しユニット52は、失敗した応答トリガなしにプローブ要求プロセスを開始することができる。取出しユニット52は、さらに、初期の失敗セグメント要求からのトリガなしに時間デルタ推定を実行することができる。これは、クライアントデバイス40がメディアセグメントを成功裏に取り出すことができる時を示す。そのようなケースは、クライアントが要求したメディアセグメントがTSBD(すなわち、セグメント利用可能性窓)の中に入るが、クライアントデバイス40のクロックとセグメントが実際に利用可能になる時刻(たとえば、サーバデバイス60のクロックによって示される)との間の時間デルタが依然として存在する可能性があるときに発生することがある。
クライアントが、図7に示すプロービング要求に対する応答を受信すると仮定する。セグメント(i-g)とセグメント(i+k)との間で、応答コードは成功(たとえば、HTTPコード200)である。この範囲の外では、応答コードはHTTP 404「利用できない」である。この場合、クライアントデバイス40の取出しユニット52は、セグメント(i-g)〜セグメント(i+k)の範囲内のセグメントは、TSBD(すなわち、利用可能性窓)に対応すると結論付けることができる。取出しユニット52は、クライアントデバイス40のクロックがサーバデバイス60のクロックより遅れていると判定し、以下の式(8)
Figure 0006240224
に従って時間デルタを推定することができる。
図8および図9は、時間デルタを推定するためには不確定なエラーパターンの例を表す。図8および図9に示すパターンなど、様々な応答パターンは、不確定であると見なされ、送信されるべき追加のプローブ要求を必要とすることがあるか、またはクライアントデバイス40とサーバデバイス60との間の同期されないクロック以外のエラーを示すことがある。
特に、図8は、成功応答と失敗応答との混合の一例を表す。この場合、応答パターンは、成功と失敗が交互に配置されている。これは、失敗した応答の理由が、すべてクロックの同期とセグメント要求時刻とに基づくとは限らないことを示す。たとえば、失敗した応答のうちの少なくともいくつかは、エンコーダもしくはサーバにおけるエラー、またはサーバとクライアントとの間のネットワーク経路に沿ったデバイスにおけるエラーによることがある。そのようなパターンが発生すると、クライアントは、必ずしも、応答だけに基づいて時間デルタを推定することができるとは限らない。クライアントは、依然として、十分なセグメントが取り出され得る限り、ライブビデオをストリーミングすることを継続することができる。
図9は、プロービング要求に対するすべての応答が404エラーである一例を表す。この場合、TSBD(すなわち、セグメント利用可能性窓)の左縁部も右縁部も発見され得ない。したがって、取出しユニット52は、これらのプローブ要求だけに基づいて時間デルタを推定することはできない。この応答パターンは、クライアントのクロックがサーバのクロックから大きくずれることによって、同期外れに陥っていることで発生することがある。すべての404応答パターンがターミナル不良(terminal failure)であるとは限らない。それは、単に、プロービング要求のセットによってカバーされる時間間隔が、TSBDの縁部を発見するには十分に大きくないことを意味する。そのような応答パターンが発生すると、取出しユニット52は、プロービング要求のセットがより粗い粒度を有する大きい時間間隔をカバーするように、隣接するプロービング要求の間隔を調整することができる。階層的探索方法を以下で説明するが、実装複雑性は基本推定方式より高い。
この例では、セグメント持続時間Dが、すべてのセグメントに対して固定されると仮定する。階層的探索は、Dに等しいプロービングセグメント間隔から開始することができる。以下の疑似コードは、階層的探索の一例を記述する。
初期化:プロービング間隔PI=D、最大プロービング間隔=M*D (M=2kおよびM*D<TSBD)
メイン手順
while (PI<M*D)
{
現在のクライアント時刻tおよびプロービング間隔Dに基づいてプロービング要求を形成する
プロービング要求のセットを用いて基本的デルタ推定方式を実行する
TSBDの縁部が発見された場合はループを抜ける、それ以外はPI=PI*2
}
If(TSBDの縁部が発見された){
while (PI>D){
新しく推定されたTSBDの縁部に中心を置くようにクライアントのクロックを調整する
より正確なTSBDの縁部の推定値を取得するために時間デルタ推定を再実行する
PI=PI/2
}
}
else{
探索失敗を宣言する
}
取出しユニット52が時間デルタを推定すると、取出しユニット52は、調整された時刻を使用してメディアセグメント要求を送信するために時間デルタ値を記録することができる。以下の例は、そのようなプロセスを概説する。期間開始時刻は15:30:00であり、ライブのメディアセグメントは、各メディアセグメントが(再生持続時間に関して)1秒の長さであるセグメント番号ベースのテンプレートを使用すると仮定する。MPDに基づいて、第1のメディアセグメントの利用可能性開始時刻は15:30:01である。しかしながら、DASHクライアント(たとえば、取出しユニット52)は、そのローカルクロックに基づく始動時刻においてメディアセグメントを成功裏に取り出すことはできない。したがって、DASHクライアントは、時間デルタ推定アルゴリズムを実行し、そのクロックが、サーバのクロック(または、要求したセグメントが実際に利用可能になる時刻)より3秒進んでいると推定する。現在のクライアントクロックが15:30:35であることを考慮する。クライアントは、最初に、推定された時間デルタ使用して、15:30:32であるサーバクロックの推定値を計算する。次いで、セグメント利用可能性タイムラインに基づいて、クライアントは、最新の利用可能セグメント番号を、セグメント#32(クライアントのローカルクロックに基づく#35の代わり)として計算する。その後、クライアントは、メディアセグメント#32に対する要求を送信し、サーバが、セグメントデータとともに200コードを返す。
時間デルタ推定を取得した後、取出しユニット52は、TSBD(すなわち、セグメント利用可能性窓)の右縁部を追跡して、将来のクロックドリフトを回避することができる。取出しユニット52は、TSBDの右縁部を追跡するために様々な技法を実施することができる。一例では、取出しユニット52は、プロービング要求を周期的に(たとえば、1分ごとに)送信し、上記で説明したように時間デルタ推定を実行することができる。初期時間デルタ推定の後、クライアントは、TSBDの右縁部の良好な近似を有する。後続のプロービング要求は、TSBDの右縁部の古い推定に中心を置かれ得る。これは、ほぼ、後続の時間デルタ推定の成功を保証し、送信されるプロービング要求の数を低減する。たいていの場合、後続の時間デルタ推定は、古い推定を再確認するか、または古い推定をわずかな値だけ調整するかのいずれかを行う。この方法は、DASHクライアント(たとえば、取出しユニット52)によって維持されるために必要な最小の状態(古い時間デルタ)なので、実施するのは比較的容易である。しかし、この方法は、粒度がセグメント持続時間によって依然として制限されているので、必ずしも、時間デルタ推定の精度を改善するとは限らない。
別の手法は、取出しユニット52に対して、TSBDの正確な縁部(たとえば、TSBDの正確な右縁部)を試験することに関して境界をプッシュすることである。クライアントデバイス40のクロックは壁時計時刻tを示し、初期時間デルタ推定結果は、デルタ値dであると仮定する。境界をプッシュするために、クライアントは、推定されたサーバ時刻における小さい時間オフセットである新しい状態変数pを導入することができる。サーバ時刻の推定値としてサーバ時刻(t+d)を使用する代わりに、クライアントは、推定されたサーバ時刻(t+d+p)を使用することができる。境界をプッシュする方法は、以下で説明するようにいくつかの段階に進むことができる。
境界プッシュ方法の初期化段階において、取出しユニット52は、初期時間デルタ推定値からのdを使用し、pを0に等しく設定し、uを100ミリ秒に等しく設定する(ここでuは、各ステップにおいてpに対する固定された増分値である)、かつDをセグメント持続時間値として設定する。p段階の付加的増加オフセット(成功したメディアセグメント要求の各々から開始される)において、取出しユニット52は、p=p+uに設定し、サーバデバイス60に対して推定された時刻がt+d+pであると判定する。p段階の指数関数的減少オフセット(失敗したメディアセグメント要求の各々から開始される)において、取出しユニット52は、p<uまでp=p/2に設定し、p<uの時点で取出しユニット52はdを再推定することができる。時間デルタdを再推定するために(たとえば、p段階の指数関数的減少オフセットの間に再推定がトリガされるときに)、取出しユニット52は、(プロービング要求を使用して)上記で説明したように完全な時間デルタ推定手順を実行することができる。プロービング要求は、TSBDの右縁部の古い推定に中心を置かれ得る。これは、推定の成功をほぼ保証する。新しく推定された時間デルタd'が、古い時間デルタ値dを置き換える。この方法は、増加したクライアント側の複雑性という犠牲を払って、はるかに高い精度で時間デルタ推定を微調整する可能性を有する。特に、クライアントデバイス40は、この例ではより多い状態情報を維持する。
取出しユニット52は、単独でまたは任意の組合せで、これらの技法に対する1つまたは複数の最適化を実施することができる。たとえば、取出しユニット52は、サーバデバイス60に送信されるプロービング要求の特定の順序を維持することができる。クライアントは、プロービング要求を連続的に相次いで送信するので、たいていのメディア取出し不良は、サーバデバイス60のクロックより進んでいる(またはセグメントが利用可能になる時刻より進んでいる)クライアントデバイス40のクロックによって引き起こされることに留意することが重要である。それゆえ、クライアントデバイス40は、時間的に前から時間的に後に、たとえばセグメント(i-N)に対するプロービング要求から開始して(i+N)まで、プロービング要求を送信することができる。時間デルタ推定の仮定は、TSBD(すなわち、セグメント利用可能性窓)の縁部に隣接するプロービング要求をほとんど同時に処理することに基づくので、たとえサーバが限られた数のプロービング要求を適時に処理することしかできなくても、そのような要求順序は、成功する推定の見込みを改善することができる。
別の例として、取出しユニット52は、応答パターンを特徴づけることができる。プロービング要求に対する応答パターンを特徴づけるための1つの実際的な方法は、最も前の要求に対する応答から開始して応答メッセージタイプが変化した回数を数えることである。たとえば、図5、図6および図7において、応答コード変化の数は、それぞれ1、1および2である。しかしながら、図8および図9において、応答コード変化の数は、それぞれ6および0である。応答コード変化の数が1または2のときだけ、応答パターンが、TSBDの縁部を推測するために使用され得ることが観察され得る。
別の例として、取出しユニット52は、「1セグメント前」ルールに従って構成され得る。すなわち、時間デルタ推定は、1セグメントの持続時間の粒度を有するので、時間デルタを用いてクライアントデバイス40のクロックを調整した後で、取出しユニット52が要求すべき最も進んだメディアセグメントは、最新の利用可能なメディアセグメントの前に利用可能であったメディアセグメントであることが勧告される。言い換えれば、取出しユニット52は、TSBDの右縁部を追跡するようにではなく、1セグメントだけ後退して時間デルタ推定における不正確さに対応するように構成され得る。
上記で説明した変数Nは、構成を介して修正され得る。いくつかの例では、Nは、取出しユニット52が最新の利用可能セグメントと判定する、iから各方向(後方および前方)に送信することを求めるプローブ要求の数に対応する。クライアントデバイスとサーバデバイスとの間のNTP同期の後、クライアントデバイスのクロックは、1時間以内に最大数秒まで、24時間の期間内に最大20秒までサーバデバイスのクロックからドリフトすることがあることを、実証的試験が示している。それゆえ、パラメータNは、クライアントデバイスが最後にネットワークタイムソースと同期して以来経過した時間に依存し得る。たとえば、取出しユニット52は、サーバデバイス60との最後の同期以来経過した時間に基づいてNの値を決定するために、以下のTable 1(表1)に従ってデータを使用するように構成され得る。クライアントデバイス40は、周期的にならびに/あるいはいくつかの規定された時間に、たとえば1日1回(または24時間周期)、ストリーミングセッションの開始において、および/またはストリーミングセッションの間に周期的(たとえば、数分ごと)に、サーバデバイス60と同期することができる。
Figure 0006240224
図10は、不均一に離間したプロービングシーケンスの一例を示す概念図である。プレゼンテーション時間に関してセグメントの間隔がTSBD(すなわち、セグメント利用可能性窓)より小さい限り、プロービングシーケンスは、隣接するプロービングパケットが、固定された数のセグメントだけ離れている2つのセグメントを対象とするように、均一に離間されるか、または、隣接するプロービングパケットが、それらの間に変化する数のセグメントを有する2つのセグメントを対象とし得るように、不均一に離間されるかのいずれでもよい。不均一に離間されたプロービングシーケンスの1つのパターンを、図10の例に示す。プロービングシーケンスの中心において、プロービングパケットによって対象とされるセグメントの間の間隔は小さい。プロービングパケットが中心から離れてより遠くに移動するにつれて、対象とされるセグメントの間の間隔が増加する。そのような設計は、プロービングシーケンスによって時間カバレージを大きくするのに役立つ一方、プロービングシーケンスの中心付近でよい時間粒度を維持することができる。
図11は、本開示の技法による、セグメント利用可能性窓の1つまたは複数の縁部を判定するための例示的な方法を示すフローチャートである。図11の方法は、クライアントデバイス(たとえば、クライアントデバイス40)およびサーバデバイス(たとえば、サーバデバイス60)によって実行されるように示されている。図1のクライアントデバイス40およびサーバデバイス60に関して説明するが、他のデバイスが、図11の方法に実質的に類似する方法を実行するように構成されてもよいことを理解されたい。さらに、追加または代替のステップが図11の方法と一致する方法で実行されてもよいことを理解されたい。
図11の方法は、クライアントデバイス40が、特定のメディアコンテンツに対してサーバデバイス60からMPDまたは他のマニフェストファイルを受信した後に実行されるものと仮定する。その上、MPDは、メディアコンテンツのセグメントが取出しのために利用可能になる時刻を定義するデータを含むことができる。これらの時刻は、サーバデバイス60のクロックに関して、またはコンテンツ準備デバイス20など、別のデバイスもしくはエンティティのクロックに関して広告され得る。したがって、クライアントデバイス40は、メディアコンテンツのセグメントが利用可能になる時刻、ならびにセグメントがもはや取出しのために利用可能でなくなる時刻を判定することができる。
MPDは、適応セット内の表現および適応セット内の表現の帯域幅など、様々な表現の特性を定義する情報をさらに含むことができる。クライアントデバイス40は、たとえば、適応セットの特性、利用可能な表現のビットレート、および現在の推定された利用可能な帯域幅に基づいて表現の1つを選択する(200)ことができる。クライアントデバイス40はまた、ローカルクロック、すなわちクライアントデバイス40のクロックから現在の時刻を判定する(202)ことができる。たとえば、クライアントデバイス40は、ローカルクロックによって示された現在の時刻と、セグメントが利用可能になったことを広告された時刻とを比較することができる。次いで、クライアントデバイス40は、最新の利用可能時刻、すなわちローカルクロックによって示される現在の時刻以前であるが選択された表現のすべての他のセグメントより後の利用可能性の時刻を有するセグメントiを判定することができる。このセグメントiは、クライアントデバイス40のローカルクロックによって示される最新の利用可能セグメントと呼ばれることがある。
この判定に基づいて、クライアントデバイス40は、最新の利用可能セグメント(たとえば、セグメントi)に対する要求をサーバデバイス60から送信する(204)ことができる。この要求は、たとえば、HTTP GET要求または部分GET要求に対応することができる。サーバデバイス60は、このセグメント要求をクライアントデバイス40から受信する(206)ことができる。しかしながら、クライアントデバイス40のローカルクロックが、セグメントが利用可能になる実際の時刻に対して(たとえば、サーバデバイス60、コンテンツ準備デバイス20、または別のそのようなデバイスのクロックに対して)ドリフトしていると仮定すると、セグメントiはまだ実際に利用可能になっていないことがある。図11の例では、セグメントiは、サーバデバイス60が要求を受信した時刻において利用可能でないと仮定され、したがってサーバデバイス60は、要求されたセグメントが利用可能でないと判定し(208)、HTTP 404エラーなどのエラーをクライアントデバイス40に送信する(210)。
クライアントデバイス40は、エラーを受信し(212)、そのエラーに基づいて、セグメントiが利用可能になる(または、なった)実際の時刻に対して、クライアントデバイス40のローカルクロックがドリフトしていると判定することができる。したがって、クライアントデバイス40は、本開示の技法に従って、プローブ要求をサーバデバイス60に送信する(214)ことができる。プローブ要求は、非常に少量のデータ、たとえば最大100バイトまでのデータに対するHTTP HEAD要求または部分GET要求に対応することができる。クライアントデバイス40は、図4に関して上記で説明したように、プローブ要求を送信することができる。たとえば、クライアントデバイス40は、1つまたは複数のプローブ要求がセグメントiより前のセグメントに向けられ、1つまたは複数のプローブ要求がセグメントiより後のセグメントに向けられるようにプローブ要求を送信することができる。
次いで、サーバデバイス60は、要求を受信し(216)、要求に対する応答を送信する(218)ことができる。プローブ要求がHTTP HEAD要求であると仮定すると、サーバデバイス60は、現在利用可能であるそれらのセグメントに対してヘッダ情報(以下、「成功した」プローブ応答と呼ばれる)を送信し、現在利用可能でないそれらのセグメントに対してエラーメッセージ(たとえば、HTTP 404エラー)を送信することができる。
クライアントデバイス40は、応答を受信し(220)、セグメント利用可能性窓の1つまたは複数の縁部を判定するために応答を分析する(222)ことができる。たとえば、成功したプローブ応答およびエラーメッセージのパターンが、上記で説明したように、図5に示すパターンに似ている場合、クライアントデバイス40は、成功したプローブ応答を有する最新のセグメント(たとえば、セグメントi-k-1)をセグメント利用可能性窓の右縁部として特定することができる。その上、クライアントデバイス40は、セグメントに対する後続の要求へのエラー応答を回避するために、セグメントiとセグメント利用可能性窓の右縁部(この場合、k+1)との間の時間デルタを判定して、ローカルクロックに適用されるべきオフセットを決定することができる。クライアントデバイス40は、この例では、上記で説明したように式(6)を使用して時間デルタを判定することができる。
別の例として、成功したプローブ応答およびエラーメッセージのパターンが図6に示すパターンと似ている場合、クライアントデバイス40は、セグメント利用可能性窓の左縁部を判定することができる。この例では、クライアントデバイス40はまた、たとえば、上記で説明したように式(7)を使用して時間デルタを計算することができる。さらに別の例として、成功したプローブ応答およびエラーメッセージのパターンが図7に示すパターンと似ている場合、クライアントデバイス40は、セグメント利用可能性窓の左縁部と右縁部の両方を判定することができる。この例では、クライアントデバイス40はまた、たとえば、上記で説明したように式(8)を使用して時間デルタを計算することができる。成功したプローブ応答およびエラーメッセージが図9に示すパターンに似ている場合、クライアントデバイス40は、階層的探索方法を実行してセグメント利用可能性窓の左および/または右の縁部を特定することができる。さらに、左または右の縁部の一方だけが発見された場合、クライアントデバイス40は、セグメント利用可能性窓(図11に示さず)の他方の縁部を発見するために追加のプローブパケットを送信することができる。
いずれの場合でも、セグメント利用可能性窓の少なくとも1つの縁部を判定した後、クライアントデバイス40は、セグメント利用可能性窓内のセグメントに対する要求を送信する(224)ことができる。たとえば、上記で説明した例では、クライアントデバイス40は、セグメントi-k-1に対する要求を送信することができる。次いで、サーバデバイス60は、要求を受信し(226)、要求されたセグメントをクライアントデバイス40に送信する(228)ことができる。
クライアントデバイス40は、セグメントに対する1つまたは複数のエラーが(たとえば、連続して)受信されたとき、初期に開始したストリーミングセッションに応答して、最後のプローブパケットのセットが送信されて以来経過した時間量(送信されるべきプローブパケットの数に影響することもある)、これらのトリガの任意の組合せ、および他の追加または代替のトリガなど、様々なトリガに応答して図11で説明したプローブパケット方法を実行することができることを理解されたい。
このようにして、図11の方法は、メディアデータを取り出す方法の一例を表し、方法は、ライブのストリーミングサービスを使用してメディアデータを提供するサーバデバイスにメディアデータのセグメントに対する複数のプローブ要求を送信するステップと、セグメント利用可能性窓の左縁部および右縁部を判定するために複数のプローブ要求に対する応答を分析するステップと、ライブのストリーミングサービスに従って、セグメント利用可能性窓の判定された左縁部および判定された右縁部に基づいてセグメント利用可能性窓内のセグメントに対する要求を送信するステップとを含む。
1つまたは複数の例では、説明される機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、1つまたは複数の命令またはコードとしてコンピュータ可読媒体上に記憶され、あるいはコンピュータ可読媒体を介して送信されてよく、かつハードウェアに基づく処理ユニットによって実行されてよい。コンピュータ可読媒体は、データ記憶媒体のような有形媒体、または、たとえば通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの転送を容易にする任意の媒体を含む通信媒体に相当する、コンピュータ可読記憶媒体を含み得る。このようにして、コンピュータ可読媒体は一般に、(1)非一時的な有形コンピュータ可読記憶媒体または(2)信号波もしくは搬送波のような通信媒体に相当し得る。データ記憶媒体は、本開示で説明される技法を実装するための、命令、コード、および/またはデータ構造を取り出すために、1つもしくは複数のコンピュータまたは1つもしくは複数のプロセッサによってアクセスされ得る、任意の利用可能な媒体であってよい。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
限定ではなく例として、そのようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、フラッシュメモリ、または、命令もしくはデータ構造の形式の所望のプログラムコードを記憶するために使用され、コンピュータによってアクセスされ得る任意の他の媒体を含み得る。また、当然、あらゆる接続がコンピュータ可読媒体と呼ばれる。たとえば、命令が、同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体は、接続、搬送波、信号、または他の一時的な媒体を含まず、代わりに非一時的な有形記憶媒体を指すことを理解されたい。本明細書で使用する場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク（登録商標）、光ディスク、デジタル多用途ディスク(DVD)、フロッピー（登録商標）ディスク、およびブルーレイディスクを含み、ディスク(disk)は、通常、磁気的にデータを再生するが、ディスク(disc)は、レーザーで光学的にデータを再生する。上記の組合せもコンピュータ可読媒体の範囲の中に含まれるべきである。
命令は、1つまたは複数のデジタル信号プロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブル論理アレイ(FPGA)、または他の等価の集積論理回路もしくはディスクリート論理回路のような、1つまたは複数のプロセッサによって実行され得る。したがって、本明細書で使用される「プロセッサ」という用語は、前述の構造、または、本明細書で説明される技法の実装に適した任意の他の構造の、いずれも指し得る。加えて、いくつかの態様では、本明細書で説明される機能は、符号化および復号のために構成された、専用のハードウェアモジュールおよび/またはソフトウェアモジュール内で提供されてよく、または、結合されたコーデックに組み込まれてよい。また、技法は、1つまたは複数の回路素子または論理素子において完全に実装されてもよい。
本開示の技法は、ワイヤレスハンドセット、集積回路(IC)、またはICのセット(たとえば、チップセット)を含む、多様なデバイスまたは装置において実装され得る。様々な構成要素、モジュール、またはユニットが、開示される技法を実行するように構成されるデバイスの機能的な側面を強調するために、本開示において説明されるが、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ上で説明されたように、様々なユニットは、コーデックハードウェアユニットへと結合されてよく、または、適切なソフトウェアおよび/またはファームウェアとともに、上で説明されたような1つまたは複数のプロセッサを含む相互動作可能なハードウェアユニットの集合体によって与えられてよい。
様々な例について説明した。これらの例および他の例は、以下の特許請求の範囲内に入る。
10 システム
20 コンテンツ準備デバイス
22 オーディオソース
24 ビデオソース
26 オーディオエンコーダ
28 ビデオエンコーダ
30 カプセル化ユニット
32 出力インターフェース
40 クライアントデバイス
42 オーディオ出力
44 ビデオ出力
46 オーディオデコーダ
48 ビデオデコーダ
50 カプセル化解除ユニット
52 取出しユニット
54 ネットワークインターフェース
60 サーバデバイス
62 記憶媒体
64 マルチメディアコンテンツ
66 マニフェストファイル
68 表現
68A 表現
68N 表現
70 要求処理ユニット
72 ネットワークインターフェース
74 ネットワーク
102 マルチメディアコンテンツ
104 メディアプレゼンテーション記述(MPD)
110 表現
112 任意選択のヘッダデータ
114 セグメント
114A セグメント
114B セグメント
114N セグメント
120 表現
122 任意選択のヘッダデータ
124 セグメント
124A セグメント
124B セグメント
124N セグメント
150 セグメントのセット
152 セグメント利用可能性窓
154 セグメント利用可能性窓の左縁部
156 セグメント利用可能性窓の右縁部

Claims (53)

  1. メディアデータを取り出す方法であって、
    前記メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信するステップであって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、ステップと、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析するステップであって、前記分析することが、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定すること、および
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出することを含む、ステップと、
    クライアントデバイスのローカルクロックとサーバデバイスのクロックとの時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのローカルクロックに基づき推定される利用可能なセグメントとに少なくとも部分的に基づいて判定するステップと、
    前記ライブのストリーミングサービスに従って、前記検出された左縁部または前記検出された右縁部に少なくとも部分的に基づく前記判定された時間差に少なくとも部分的に基づいてセグメントに対する要求を送信するステップと
    を含む、方法。
  2. 前記プローブ要求が、前記セグメントに対するデータの全量より少ない前記セグメントのデータ量に対する要求を含む、請求項1に記載の方法。
  3. 前記プローブ要求が、HTTP HEAD要求を含む、請求項1に記載の方法。
  4. 前記プローブ要求が、HTTP部分GET要求を含む、請求項1に記載の方法。
  5. 前記セグメント利用可能性窓は更新されたセグメント利用可能性窓を含み、前記方法はさらに、前記複数のプローブ要求を送信する前に、
    最初に検出されたセグメント利用可能性窓内のセグメントに対する複数の要求を送信するステップと、
    前記最初に検出されたセグメント利用可能性窓内のセグメントに対する前記要求に対する応答が、ある数のHTTP 404エラーを含むと判定するステップと、
    を含み、
    前記複数のプローブ要求を送信するステップは、前記最初に検出されたセグメント利用可能性窓内のセグメントに対する前記要求に対する応答の中のHTTP 404エラーの数に基づいて前記複数のプローブ要求を送信するステップを含む、請求項1に記載の方法。
  6. 前記複数のプローブ要求を送信するステップが、前記メディアデータを取り出すためにHTTPストリーミングセッションを開始するときに前記複数のプローブ要求を送信するステップを含む、請求項1に記載の方法。
  7. 前記応答を分析するステップが、
    より前のセグメントに対する要求への応答が成功を示し、より後のセグメントに対する要求への応答が失敗を示したと判定するステップと、
    より前のセグメントに対する前記要求への前記応答が成功を示し、より後のセグメントに対する前記要求への前記応答が失敗を示したとの前記判定に基づいて、前記セグメント利用可能性窓の前記右縁部が、前記応答が成功を示した前記セグメントと前記応答が失敗を示した前記セグメントとの間にあると判定するステップとを含む、請求項1に記載の方法。
  8. 前記時間差を
    Figure 0006240224
     に従って計算するステップをさらに含み、ここでD(j)がセグメントjの持続時間を定義し、iがクライアントデバイスのクロックに基づいて推定された利用可能セグメントを表し、kが、セグメントiと前記応答が成功を示した最新のセグメントとの間のセグメントの数を表す、請求項7に記載の方法。
  9. 前記応答を分析するステップが、
    より後のセグメントに対する要求への応答が成功を示し、より前のセグメントに対する要求への応答が失敗を示したと判定するステップと、
    前記判定に基づいて、前記セグメント利用可能性窓の前記左縁部が、前記応答が成功を示した前記セグメントと前記応答が失敗を示した前記セグメントとの間にあると判定するステップとを含む、請求項1に記載の方法。
  10. 前記時間差を
    Figure 0006240224
     に従って計算するステップをさらに含み、ここでD(j)がセグメントjの持続時間を定義し、iがクライアントデバイスのクロックに基づいて推定された利用可能なセグメントを表し、TSBDが時間シフトバッファ深さを表し、kが、セグメントiと前記応答が成功を示した最も早いセグメントとの間のセグメントの数を表す、請求項9に記載の方法。
  11. 前記応答を分析するステップが、
    より前のセグメントに対する要求への応答が失敗を示し、より後のセグメントに対する要求への応答が失敗を示し、前記より前のセグメントと前記より後のセグメントとの間の中間のセグメントに対する要求への応答が成功を示したと判定するステップと、
    前記判定に基づいて、前記セグメント利用可能性窓の前記左縁部が、前記より前のセグメントと前記中間のセグメントとの間にあり、前記セグメント利用可能性窓の前記右縁部が、前記中間のセグメントと前記より後のセグメントとの間にあると判定するステップとを含む、請求項1に記載の方法。
  12. 前記時間差を
    Figure 0006240224
     に従って計算するステップをさらに含み、ここでD(j)がセグメントjの持続時間を定義し、iがクライアントデバイスのクロックに基づいて推定された利用可能セグメントを表し、kが、セグメントiと前記応答が成功を示した最新のセグメントとの間のセグメントの数を表す、請求項11に記載の方法。
  13. 前記複数のプローブ要求が第2の複数のプローブ要求を含み、前記方法が、前記第2の複数のプローブ要求を送信する前に、第1の再生時間をカバーする第1の複数のプローブ要求を送信するステップをさらに含み、前記第2の複数のプローブ要求を送信するステップが、前記第1の複数のプローブ要求に対する応答が失敗を示したと判定した後で前記第2の複数のプローブ要求を送信するステップを含み、前記第2の複数のプローブ要求が、前記第1の再生時間より長い第2の再生時間をカバーする、請求項1に記載の方法。
  14. メディアデータを取り出す方法であって、
    前記メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信するステップであって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、ステップと、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析するステップであって、前記分析することが、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定すること、および
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出することを含む、ステップと、
    セグメントが実際に利用可能である時刻と、前記セグメントが利用可能であることをクライアントデバイスのクロックが示す時刻との間の差を表す時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのクロックに基づき推定される利用可能なセグメントとに基づき判定するステップと、
    前記時間差に基づいて前記セグメントの1つまたは複数を要求するステップであって、前記要求するステップは、前記ライブのストリーミングサービスに従って、前記セグメント利用可能性窓の前記検出された左縁部または前記検出された右縁部に基づいてセグメントに対する要求を送信するステップを含む、ステップと、
    含む、方法。
  15. 後続の複数のプローブパケットを使用して前記時間差を周期的に更新するステップをさらに含む、請求項14に記載の方法。
  16. 前記セグメント利用可能性窓の正確な右縁部を検出することを試行するために、1つまたは複数の小さい増分だけ前記時間差を増加するステップをさらに含む、請求項14に記載の方法。
  17. 前記複数のプローブ要求を送信するステップが、より前のプローブ要求がより前のセグメントに対応し、より後のプローブ要求がより後のセグメントに対応するように前記複数のプローブ要求を送信するステップを含む、請求項1に記載の方法。
  18. 前記応答を分析するステップが、応答のタイプの間の変化の数を計算するステップを含み、第1のタイプの応答は対応するセグメントが利用可能であることを示し、第2のタイプの応答は前記対応するセグメントが利用可能でないことを示す、請求項1に記載の方法。
  19. 前記計算された応答のタイプの間の変化の数が1または2に等しいと判定された後にのみ、前記セグメント利用可能性窓の前記左縁部と前記右縁部を検出するステップをさらに含む、請求項18に記載の方法。
  20. 前記セグメントに対する前記要求を送信するステップが、前記右縁部より1セグメント遅れたセグメントに対する要求を送信するステップを含む、請求項1に記載の方法。
  21. 前記サーバデバイスとの最後の時刻同期以来経過した時間量に基づいて、前記複数のプローブ要求内に含めるためのプローブ要求の数を決定するステップをさらに含む、請求項1に記載の方法。
  22. 前記プローブ要求の数を決定するステップが、前記プローブ要求の数が、前記経過した時間が1分以下であるときに10、前記経過した時間量が1分より長く10分以下であるときに15、前記経過した時間量が10分より長いが1時間以下であるときに20、前記経過した時間量が1時間より長いときに25に等しいことを決定するステップを含む、請求項21に記載の方法。
  23. 前記メディアデータを要求するためにストリーミングセッションを開始する前に、クライアントデバイスのクロックを前記サーバデバイスと同期させるステップをさらに含む、請求項1に記載の方法。
  24. 同期させるステップが、ネットワーク時間プロトコル(NTP)を使用して同期させるステップを含む、請求項23に記載の方法。
  25. クライアントデバイスのクロックを前記サーバデバイスと周期的に同期させるステップをさらに含む、請求項1に記載の方法。
  26. 周期的に同期させるステップが、N分ごとに前記クライアントデバイスの前記クロックを前記サーバデバイスと同期させるステップを含む、請求項25に記載の方法。
  27. 前記要求を送信するステップが、ライブの動的適応ストリーミングオーバーHTTP(DASH)に従って前記要求を送信するステップを含む、請求項1に記載の方法。
  28. 前記複数のプローブ要求を送信するステップが、前記メディアデータに対する要求を送信した後、前記メディアデータの再生の失敗に応答して前記複数のプローブ要求を送信するステップを含み、前記方法が、
    前記判定された左縁部または前記判定された右縁部に少なくとも部分的に基づいて、クライアントデバイスのローカルクロックとサーバデバイスのクロックとの間の時間差を判定するステップと、
    前記判定された時間差に基づいて前記ローカルクロックを調整するステップとをさらに含み、
    前記要求を送信するステップが、前記調整されたローカルクロックに基づいて前記要求を送信するステップを含む、請求項1に記載の方法。
  29. 前記時間差が、前記ローカルクロックが前記サーバデバイスの前記クロックより進んでいることを示し、前記方法が、前記時間差に等しい時間期間の間メディア再生を停止するステップをさらに含む、請求項1に記載の方法。
  30. 前記時間差が、前記ローカルクロックが前記サーバデバイスの前記クロックより遅れていることを示し、前記方法が、前記時間差に等しい時間期間の間メディア再生をスキップするステップをさらに含む、請求項1に記載の方法。
  31. 前記時間差が、前記ローカルクロックが前記サーバデバイスの前記クロックより進んでいることを示し、前記方法が、前記時間差がゼロになるまで通常再生速度より少し速い速度で前記メディアデータを再生するステップをさらに含む、請求項1に記載の方法。
  32. 前記時間差が、前記ローカルクロックが前記サーバデバイスの前記クロックより遅れていることを示し、前記方法が、前記時間差がゼロになるまで通常再生速度より少し遅い速度で前記メディアデータを再生するステップをさらに含む、請求項1に記載の方法。
  33. メディアデータを取り出すためのデバイスであって、
    前記メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信することであって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、ことと、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析することであって、前記分析することが、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定すること、および
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出することを含む、ことと、
    クライアントデバイスのローカルクロックとサーバデバイスのクロックとの時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのローカルクロックに基づき推定される利用可能なセグメントとに少なくとも部分的に基づいて判定することと、
    前記ライブのストリーミングサービスに従って、前記検出された左縁部または前記検出された右縁部に少なくとも部分的に基づく前記判定された時間差に少なくとも部分的に基づいてセグメントに対する要求を送信することと
    を行うように構成された1つまたは複数のプロセッサを備える、デバイス。
  34. 前記プローブ要求が、HTTP HEAD要求およびHTTP部分GET要求のうちの一方を含む、請求項33に記載のデバイス。
  35. 前の要求に対する応答が、ある数のHTTP 404エラーを含んでいたとの判定とHTTPストリーミングセッションの開始とのうちの少なくとも一方に基づいて、前記複数のプローブ要求を送信するように、前記1つまたは複数のプロセッサが構成される、請求項33に記載のデバイス。
  36. 前記応答を分析するために、より前のセグメントに対する要求への応答が失敗を示し、より後のセグメントに対する要求への応答が失敗を示し、前記より前のセグメントと前記より後のセグメントとの間の中間のセグメントに対する要求への応答が成功を示したと判定することと、前記判定に基づいて、前記セグメント利用可能性窓の前記左縁部が前記より前のセグメントと前記中間のセグメントとの間にあり、前記セグメント利用可能性窓の前記右縁部が前記中間のセグメントと前記より後のセグメントとの間にあると判定することとを行うように、前記1つまたは複数のプロセッサが構成される、請求項33に記載のデバイス。
  37. 前記1つまたは複数のプロセッサが、前記時間差を
    Figure 0006240224
     に従って計算するように構成され、ここでD(j)がセグメントjの持続時間を定義し、iがクライアントデバイスのクロックに基づいて推定された利用可能セグメントを表し、kが、セグメントiと前記応答が成功を示した最新のセグメントとの間のセグメントの数を表す、請求項36に記載のデバイス。
  38. 前記複数のプローブ要求が第2の複数のプローブ要求を含み、前記1つまたは複数のプロセッサが、前記第2の複数のプローブ要求を送信する前に、前記第2の複数のプローブ要求より少ないプローブ要求を含む第1の複数のプローブ要求を送信することと、前記第1の複数のプローブ要求に対する応答が失敗を示したと判定した後で前記第2の複数のプローブ要求を送信することとを行うように構成される、請求項33に記載のデバイス。
  39. メディアデータを取り出すためのデバイスであって、
    前記メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信することであって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、ことと、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析することであって、前記分析することが、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定すること、および
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出することを含む、ことと、
    セグメントが実際に利用可能である時刻と、前記セグメントが利用可能であることをクライアントデバイスのクロックが示す時刻との間の差を表す時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのクロックに基づき推定される利用可能なセグメントとに基づき判定することと、
    前記時間差に基づいて前記セグメントの1つまたは複数を要求することと
    を行うように構成された1つまたは複数のプロセッサを備え、
    前記1つまたは複数のセグメントを要求するために、前記1つまたは複数のプロセッサは、前記ライブのストリーミングサービスに従って、前記セグメント利用可能性窓の前記検出された左縁部または前記検出された右縁部に基づいてセグメントに対する要求を送信するように構成される、
    デバイス。
  40. メディアデータを取り出すためのデバイスであって、
    前記メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信するための手段であって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、手段と、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析するための手段であって、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定するための手段と、
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出するための手段とを含む手段と、
    クライアントデバイスのローカルクロックとサーバデバイスのクロックとの時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのローカルクロックに基づき推定される利用可能なセグメントとに少なくとも部分的に基づいて判定するための手段と、
    前記ライブのストリーミングサービスに従って、前記検出された左縁部または前記検出された右縁部に少なくとも部分的に基づく前記判定された時間差に少なくとも部分的に基づいてセグメントに対する要求を送信するための手段と、
    を備える、デバイス。
  41. 前記プローブ要求が、HTTP HEAD要求およびHTTP部分GET要求のうちの一方を含む、請求項40に記載のデバイス。
  42. 前記複数のプローブ要求を送信するための前記手段が、前の要求に対する応答内で受信されたHTTP 404エラーの数に基づいて前記複数のプローブ要求を送信するための手段と、HTTPストリーミングセッションの開始に基づいて前記複数のプローブ要求を送信するための手段とのうちの少なくとも一方を含む、請求項40に記載のデバイス。
  43. 前記応答を分析するための前記手段が、
    より前のセグメントに対する要求への応答が失敗を示し、より後のセグメントに対する要求への応答が失敗を示し、前記より前のセグメントと前記より後のセグメントとの間の中間のセグメントに対する要求への応答が成功を示したと判定するための手段と、
    前記判定に基づいて、前記セグメント利用可能性窓の前記左縁部が前記より前のセグメントと前記中間のセグメントとの間にあり、前記セグメント利用可能性窓の前記右縁部が前記中間のセグメントと前記より後のセグメントとの間にあると判定するための手段とを含む、請求項40に記載のデバイス。
  44. 前記時間差を
    Figure 0006240224
     に従って計算するための手段をさらに含み、ここでD(j)がセグメントjの持続時間を定義し、iがクライアントデバイスのクロックに基づいて推定された利用可能セグメントを表し、kが、セグメントiと前記応答が成功を示した最新のセグメントとの間のセグメントの数を表す、請求項43に記載のデバイス。
  45. 前記複数のプローブ要求が第2の複数のプローブ要求を含み、前記第2の複数のプローブ要求を送信する前に、前記第2の複数のプローブ要求より少ないプローブ要求を含む第1の複数のプローブ要求を送信するための手段をさらに含み、前記第2の複数のプローブ要求を送信するための前記手段が、前記第1の複数のプローブ要求に対する応答が失敗を示したと判定した後で前記第2の複数のプローブ要求を送信するための手段を含む、請求項40に記載のデバイス。
  46. メディアデータを取り出すデバイスであって、
    前記メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信するための手段であって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、手段と、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析するための手段であって、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定するための手段と、
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出するための手段とを含む手段と、
    セグメントが実際に利用可能である時刻と、前記セグメントが利用可能であることをクライアントデバイスのクロックが示す時刻との間の差を表す時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのクロックに基づき推定される利用可能なセグメントとに基づき判定するための手段と、
    前記時間差に基づいて前記セグメントの1つまたは複数を要求するための手段であって、前記1つまたは複数のセグメントを要求するための手段は、前記ライブのストリーミングサービスに従って、前記セグメント利用可能性窓の前記検出された左縁部または右縁部に基づいてセグメントに対する要求を送信するための手段を含む、手段と、
    を備える、デバイス。
  47. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令が、実行されると、
    メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信することであって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、ことと、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析することであって、前記分析することが、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定すること、および
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出することを含む、ことと、
    クライアントデバイスのローカルクロックとサーバデバイスのクロックとの時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのローカルクロックに基づき推定される利用可能なセグメントとに少なくとも部分的に基づいて判定することと、
    前記ライブのストリーミングサービスに従って、前記検出された左縁部または前記検出された右縁部に少なくとも部分的に基づく前記判定された時間差に少なくとも部分的に基づいて前記セグメント利用可能性窓内のセグメントに対する要求を送信することと
    をプロセッサに行わせる、コンピュータ可読記憶媒体。
  48. 前記プローブ要求が、HTTP HEAD要求およびHTTP部分GET要求のうちの一方を含む、請求項47に記載のコンピュータ可読記憶媒体。
  49. 前記複数のプローブ要求を前記プロセッサに送信させる前記命令が、前の要求に応答して受信されたHTTP 404エラーの数およびHTTPストリーミングセッションの開始のうちの少なくとも一方に基づいて、前記複数のプローブ要求を前記プロセッサに送信させる命令を含む、請求項47に記載のコンピュータ可読記憶媒体。
  50. 前記応答を前記プロセッサに分析させる前記命令が、
    より前のセグメントに対する要求への応答が失敗を示し、より後のセグメントに対する要求への応答が失敗を示し、前記より前のセグメントと前記より後のセグメントとの間の中間のセグメントに対する要求への応答が成功を示したと判定することと、
    前記判定に基づいて、前記セグメント利用可能性窓の前記左縁部が前記より前のセグメントと前記中間のセグメントとの間にあり、前記セグメント利用可能性窓の前記右縁部が前記中間のセグメントと前記より後のセグメントとの間にあると判定することとを前記プロセッサに行わせる命令を含む、請求項47に記載のコンピュータ可読記憶媒体。
  51. 前記時間差を
    Figure 0006240224
     に従って前記プロセッサに計算させる命令をさらに含み、ここでD(j)がセグメントjの持続時間を定義し、iがクライアントデバイスのクロックに基づいて推定された利用可能セグメントを表し、kが、セグメントiと前記応答が成功を示した最新のセグメントとの間のセグメントの数を表す、請求項50に記載のコンピュータ可読記憶媒体。
  52. 前記複数のプローブ要求が第2の複数のプローブ要求を含み、前記第2の複数のプローブ要求を送信する前に、前記第2の複数のプローブ要求より少ないプローブ要求を含む第1の複数のプローブ要求を前記プロセッサに送信させる命令をさらに含み、前記第2の複数のプローブ要求を前記プロセッサに送信させる前記命令が、前記第1の複数のプローブ要求に対する応答が失敗を示したと判定した後で前記第2の複数のプローブ要求を前記プロセッサに送信させる命令を含む、請求項47に記載のコンピュータ可読記憶媒体。
  53. 命令を記憶したコンピュータ可読記憶媒体であって、前記命令が、実行されると、
    メディアデータのセグメントに対する複数のプローブ要求を、ライブのストリーミングサービスを使用して前記メディアデータを提供するサーバデバイスに送信することであって、前記プローブ要求が、対応するセグメントの少なくとも一部のデータ量に対する要求を含む、ことと、
    セグメント利用可能性窓の左縁部または右縁部を検出するために前記複数のプローブ要求に対する応答を分析することであって、前記分析することが、
    前記応答の各々が、前記要求に対する成功応答であるか、失敗応答であるかを判定すること、および
    前記セグメントに対応する前記成功応答と前記失敗応答の境界に基づいて、セグメント利用可能性窓の左縁部または右縁部を検出することを含む、ことと、
    セグメントが実際に利用可能である時刻と、前記セグメントが利用可能であることをクライアントデバイスのクロックが示す時刻との間の差を表す時間差を、前記検出された左縁部または前記検出された右縁部と、前記クライアントデバイスのクロックに基づき推定される利用可能なセグメントとに基づき判定することと、
    前記時間差に基づいて前記セグメントの1つまたは複数を要求することと
    をプロセッサに行わせ、
    前記1つまたは複数のセグメントを前記プロセッサに要求させる前記命令は、前記ライブのストリーミングサービスに従って、前記セグメント利用可能性窓の前記検出された左縁部または前記検出された右縁部に基づいてセグメントに対する要求を前記プロセッサに送信させる命令を含む、
    コンピュータ可読記憶媒体。
JP2015556017A 2013-02-04 2013-12-31 ネットワークストリーミングのための利用可能なメディアデータの決定 Expired - Fee Related JP6240224B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201361760382P 2013-02-04 2013-02-04
US61/760,382 2013-02-04
US14/041,724 US9432426B2 (en) 2013-02-04 2013-09-30 Determining available media data for network streaming
US14/041,724 2013-09-30
PCT/US2013/078471 WO2014120377A1 (en) 2013-02-04 2013-12-31 Determining available media data for network streaming

Publications (3)

Publication Number Publication Date
JP2016511575A JP2016511575A (ja) 2016-04-14
JP2016511575A5 JP2016511575A5 (ja) 2017-02-09
JP6240224B2 true JP6240224B2 (ja) 2017-11-29

Family

ID=51260260

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2015556017A Expired - Fee Related JP6240224B2 (ja) 2013-02-04 2013-12-31 ネットワークストリーミングのための利用可能なメディアデータの決定

Country Status (6)

Country Link
US (1) US9432426B2 (ja)
EP (1) EP2952006B1 (ja)
JP (1) JP6240224B2 (ja)
KR (1) KR101704619B1 (ja)
CN (1) CN104969560B (ja)
WO (1) WO2014120377A1 (ja)

Families Citing this family (48)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6033541B2 (ja) * 2011-11-24 2016-11-30 シャープ株式会社 再生装置、再生方法、制御プログラム、および記録媒体
CN105075276B (zh) * 2013-01-11 2019-04-16 瑞典爱立信有限公司 在广播通信网络中操作客户端设备和服务器设备的技术
EP2954653B1 (en) * 2013-02-06 2018-11-28 Telefonaktiebolaget LM Ericsson (publ) Technique for detecting an encoder functionality issue
US9734194B1 (en) * 2013-03-14 2017-08-15 Google Inc. Encoding time interval information
US9215569B2 (en) * 2013-03-15 2015-12-15 Cellco Partnership Broadcast media content to subscriber group
US9705955B2 (en) * 2013-04-18 2017-07-11 Futurewei Technologies, Inc. Period labeling in dynamic adaptive streaming over hypertext transfer protocol
US9438654B2 (en) * 2013-04-18 2016-09-06 Futurewei Technologies, Inc. Fragment interface into dynamic adaptive streaming over hypertext transfer protocol presentations
US9973559B2 (en) * 2013-05-29 2018-05-15 Avago Technologies General Ip (Singapore) Pte. Ltd. Systems and methods for presenting content streams to a client device
US20150095964A1 (en) * 2013-10-01 2015-04-02 Opentv, Inc. Bumper video carousel for digital video delivery
KR20150065289A (ko) * 2013-12-05 2015-06-15 삼성전자주식회사 데이터 재사용 방법 및 전자장치
KR102154800B1 (ko) * 2014-01-10 2020-09-10 삼성전자주식회사 전자 장치의 데이터 스트리밍 방법 및 그 전자 장치
JP2015136057A (ja) * 2014-01-17 2015-07-27 ソニー株式会社 通信装置、通信データ生成方法、および通信データ処理方法
US20150256600A1 (en) * 2014-03-05 2015-09-10 Citrix Systems, Inc. Systems and methods for media format substitution
EP2924595A1 (en) * 2014-03-28 2015-09-30 Acast AB Method for associating media files with additional content
US9973345B2 (en) 2014-09-10 2018-05-15 Qualcomm Incorporated Calculating and signaling segment availability times for segments of media data
WO2016099354A1 (en) * 2014-12-18 2016-06-23 Telefonaktiebolaget Lm Ericsson (Publ) Request scheduling for streamed media
CN105991469B (zh) * 2015-02-06 2018-01-19 上海交通大学 一种异构网络传输下的动态时间窗口及缓存机制
CN106572062B (zh) * 2015-10-10 2019-08-09 上海交通大学 一种异构媒体传输网络下的资源动态请求方法
JP6472892B2 (ja) * 2015-02-06 2019-02-20 上海交通大学Ｓｈａｎｇｈａｉ Ｊｉａｏ Ｔｏｎｇ Ｕｎｉｖｅｒｓｉｔｙ 異種ネットワーク伝送における動的時間窓およびキャッシュメカニズム
CN106330751B (zh) * 2015-06-18 2019-07-26 上海交通大学 异构网络传输下的资源动态请求时间窗口及终端缓存方法
DE102015001622A1 (de) 2015-02-09 2016-08-11 Unify Gmbh & Co. Kg Verfahren zur Übertragung von Daten in einem Multimedia-System, sowie Softwareprodukt und Vorrichtung zur Steuerung der Übertragung von Daten in einem Multimedia-System
CN107810625B (zh) * 2015-06-30 2020-12-08 英国电讯有限公司 通过客户端从服务器流传输媒体序列的方法和装置
WO2017010720A1 (ko) * 2015-07-10 2017-01-19 (주) 프람트 데이터 구조화를 통한 직관적인 동영상콘텐츠 재생산 방법 및 이를 위한 사용자 인터페이스 장치
WO2017063189A1 (en) * 2015-10-16 2017-04-20 Qualcomm Incorporated Deadline signaling for streaming of media data
CN110809174B (zh) * 2015-10-23 2022-03-04 上海交通大学 一种异构媒体网络传输下动态提供资源可获取时间的方法
EP3384674A1 (en) * 2015-12-04 2018-10-10 Telefonaktiebolaget LM Ericsson (publ) Technique for adaptive streaming of temporally scaling media segment levels
KR20170093637A (ko) * 2016-02-05 2017-08-16 한국전자통신연구원 이종 네트워크 환경에서 미디어 전송 스트림 버퍼링 방법 및 이를 이용한 영상 수신 장치
US10382511B2 (en) * 2016-02-25 2019-08-13 Amp Me Inc. Synchronizing playback of digital media content
JP6247782B1 (ja) * 2017-02-15 2017-12-13 パナソニック株式会社 端末装置、映像配信システムおよび映像配信方法
US9872062B1 (en) * 2017-02-22 2018-01-16 Wyse Technology L.L.C. Enforcing synchronization by embedding audio within video frame data
EP3410728A1 (en) * 2017-05-30 2018-12-05 Vestel Elektronik Sanayi ve Ticaret A.S. Methods and apparatus for streaming data
US10972515B2 (en) * 2017-07-31 2021-04-06 Verizon Digital Media Services Inc. Server assisted live stream failover
US10715880B2 (en) 2017-08-24 2020-07-14 Skitter, Inc. Method for creation and distribution of segmented video over distributed multicast-aware sparse networks with low latency
US10986001B2 (en) * 2018-01-25 2021-04-20 Nokia Solutions And Networks Oy System and method for quality of service detection of encrypted packet flows
US11039206B2 (en) * 2018-04-09 2021-06-15 Hulu, LLC Differential media presentation descriptions for video streaming
CN110545492B (zh) * 2018-09-05 2020-07-31 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
CN110958681B (zh) * 2018-09-27 2023-09-05 中兴通讯股份有限公司 业务传输方法及装置
US11379355B2 (en) * 2018-10-30 2022-07-05 Micron Technology, Inc. Power-on-time based data relocation
US20200204621A1 (en) * 2018-12-21 2020-06-25 York Telecom Corporation Management of live media connections
US11349764B2 (en) 2019-02-15 2022-05-31 Qualcomm Incorporated Methods and apparatus for signaling offset in a wireless communication system
US11172501B2 (en) 2019-09-05 2021-11-09 Qualcomm Incorporated Methods and apparatus for signaling offset in a wireless communication system
US11564018B2 (en) 2019-10-02 2023-01-24 Qualcomm Incorporated Random access at resync points of dash segments
KR20210065604A (ko) * 2019-11-27 2021-06-04 한국전자통신연구원 분산 네트워크 기반 멀티미디어 스트리밍 서비스에서 스트림을 선택하여 수신하는 방법 및 장치
US11570509B2 (en) * 2020-01-06 2023-01-31 Tencent America LLC Session-based information for dynamic adaptive streaming over HTTP
CN111221572B (zh) * 2020-01-13 2023-09-01 北京字节跳动网络技术有限公司 一种自动适配运行环境的方法、装置、介质和设备
US20210306703A1 (en) * 2020-03-25 2021-09-30 Qualcomm Incorporated Determination of availability of chunks of data for network streaming media data
US11546406B2 (en) * 2020-04-13 2023-01-03 Tencent America LLC Media systems and methods including mixed event message tracks
US11570246B1 (en) 2021-11-17 2023-01-31 Saudi Arabian Oil Company Layer 7 health check automated execution framework

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7363361B2 (en) 2000-08-18 2008-04-22 Akamai Technologies, Inc. Secure content delivery system
US7720983B2 (en) 2004-05-03 2010-05-18 Microsoft Corporation Fast startup for streaming media
US9432433B2 (en) 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
DE102007026531A1 (de) * 2006-10-31 2008-05-08 Siemens Ag Verfahren zur Synchronisierung von Szene-Datenfiles und Mediendatenströmen in einem unidirektionalen Datenübertragungssystem
US10007668B2 (en) * 2008-08-01 2018-06-26 Vantrix Corporation Method and system for triggering ingestion of remote content by a streaming server using uniform resource locator folder mapping
US8621044B2 (en) * 2009-03-16 2013-12-31 Microsoft Corporation Smooth, stateless client media streaming
US8909806B2 (en) * 2009-03-16 2014-12-09 Microsoft Corporation Delivering cacheable streaming media presentations
US8914835B2 (en) * 2009-10-28 2014-12-16 Qualcomm Incorporated Streaming encoded video data
US8849950B2 (en) 2011-04-07 2014-09-30 Qualcomm Incorporated Network streaming of video data using byte range requests
US8478890B2 (en) * 2011-07-15 2013-07-02 Damaka, Inc. System and method for reliable virtual bi-directional data stream communications with single socket point-to-multipoint capability
US9357275B2 (en) 2011-09-06 2016-05-31 Qualcomm Incorporated Network streaming of coded video data
US9954717B2 (en) * 2012-07-11 2018-04-24 Futurewei Technologies, Inc. Dynamic adaptive streaming over hypertext transfer protocol as hybrid multirate media description, delivery, and storage format

Also Published As

Publication number Publication date
JP2016511575A (ja) 2016-04-14
EP2952006A1 (en) 2015-12-09
WO2014120377A1 (en) 2014-08-07
US20140222962A1 (en) 2014-08-07
US9432426B2 (en) 2016-08-30
CN104969560B (zh) 2018-07-17
KR20150114997A (ko) 2015-10-13
CN104969560A (zh) 2015-10-07
EP2952006B1 (en) 2017-08-23
KR101704619B1 (ko) 2017-02-08

Similar Documents

Publication Publication Date Title
JP6240224B2 (ja) ネットワークストリーミングのための利用可能なメディアデータの決定
EP2941892B1 (en) Live timing for dynamic adaptive streaming over http (dash)
AU2016226206B2 (en) File format based streaming with dash formats based on LCT
KR101741484B1 (ko) 저-레이턴시 스트림을 처리하기 위한 개선된 블록-요청 스트리밍 시스템
CA2807157C (en) Manifest file updates for network streaming of coded video data
KR101480828B1 (ko) Ｕｒｌ 템플릿들 및 구성 규칙들을 이용하는 향상된 블록-요청 스트리밍
KR101395193B1 (ko) 시그널링 또는 블록 생성을 이용하는 개선된 블록-요청 스트리밍 시스템
EP3095247B1 (en) Robust live operation of dash
KR20170116027A (ko) 저 레이턴시 비디오 스트리밍
US20150312303A1 (en) Determining whether to use sidx information when streaming media data

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170104

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20170104

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20170104

A975 Report on accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A971005

Effective date: 20170413

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20170413

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20170522

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170725

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20171102

R150 Certificate of patent or registration of utility model

Ref document number: 6240224

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees