JP2019523600A - メディアストリーミングのためのセグメントチャンクの検索およびアクセス - Google Patents

メディアストリーミングのためのセグメントチャンクの検索およびアクセス Download PDF

Info

Publication number
JP2019523600A
JP2019523600A JP2019504133A JP2019504133A JP2019523600A JP 2019523600 A JP2019523600 A JP 2019523600A JP 2019504133 A JP2019504133 A JP 2019504133A JP 2019504133 A JP2019504133 A JP 2019504133A JP 2019523600 A JP2019523600 A JP 2019523600A
Authority
JP
Japan
Prior art keywords
segment
chunks
identifier
data
media
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2019504133A
Other languages
English (en)
Other versions
JP2019523600A5 (ja
JP7142626B2 (ja
Inventor
ストックハマー、トーマス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Publication of JP2019523600A publication Critical patent/JP2019523600A/ja
Publication of JP2019523600A5 publication Critical patent/JP2019523600A5/ja
Application granted granted Critical
Publication of JP7142626B2 publication Critical patent/JP7142626B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8456Structuring of content, e.g. decomposing content into time segments by decomposing the content in the time domain, e.g. in time segments
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/61Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60Network streaming of media packets
    • H04L65/75Media network packet handling
    • H04L65/762Media network packet handling at the source 
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/01Protocols
    • H04L67/02Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/14Session management
    • H04L67/146Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/234Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs
    • H04N21/2343Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements
    • H04N21/23439Processing of video elementary streams, e.g. splicing of video streams or manipulating encoded video stream scene graphs involving reformatting operations of video signals for distribution or compliance with end-user requests or end-user device requirements for generating different versions
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists
    • H04N21/26258Content or additional data distribution scheduling, e.g. sending additional data at off-peak times, updating software modules, calculating the carousel transmission frequency, delaying a video stream transmission, generating play-lists for generating a list of items to be played back in a given order, e.g. playlist, or scheduling item distribution according to such list
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60Network 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/63Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637Control signals issued by the client directed to the server or network components
    • H04N21/6377Control signals issued by the client directed to the server or network components directed to server
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/83Generation or processing of protective or descriptive data associated with content; Content structuring
    • H04N21/845Structuring of content, e.g. decomposing content into time segments
    • H04N21/8455Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04NPICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/80Generation or processing of content or additional data by content creator independently of the distribution process; Content per se
    • H04N21/85Assembly of content; Generation of multimedia applications
    • H04N21/858Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot
    • H04N21/8586Linking data to content, e.g. by linking an URL to a video object, by creating a hotspot by using a URL

Landscapes

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

Abstract

メディアデータを検索するための例示的なデバイスは、回路に実装され、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの1つのための識別子を決定することと、サーバデバイスに、チャンクのうちの1つのための識別子を指定する要求を送ることと、を行うように構成された1つまたは複数のプロセッサを含む。

Description

[0001] 本願は、その内容全体が参照により本明細書に組み込まれた、2016年7月28日付で出願された米国仮特許出願第62/368,099号の利益を主張する。
[0002] 本開示は、符号化されたメディアデータの搬送に関する。
[0003] デジタルビデオ性能は、デジタルテレビ、デジタルダイレクトブロードキャストシステム、ワイヤレスブロードキャストシステム、携帯情報端末(PDA)、ラップトップまたはデスクトップコンピュータ、デジタルカメラ、デジタル記録デバイス、デジタルメディアプレーヤ、ビデオゲーミングデバイス、ビデオゲーム機、セルラまたは衛星無線電話、ビデオ電話会議デバイスなどを含む、幅広いデバイスに組み込まれることができる。デジタルビデオデバイスは、デジタルビデオ情報をより効率的に送信および受信するために、MPEG−2、MPEG−4、ITU−T H.263、ITU−T H.264/MPEG−4,Part10、アドバンストビデオコーディング(AVC)、ITU−T H.265(高効率ビデオコーディング(HEVC)とも呼ばれる)、およびこのような規格の拡張によって定義される規格において説明されるもののようなビデオ圧縮技法を実装する。
[0004] ビデオデータが符号化された後に、そのビデオデータは、送信または記憶のためにパケット化され得る。ビデオデータは、AVCなどの国際標準化機構(ISO:International Organization for Standardization)ベースメディアファイルフォーマットおよびその拡張のような、様々な規格のうちのいずれかに準拠するビデオファイルにアセンブルされ得る。
[0005] 概して、本開示は、セグメントチャンク(segment chunks)を使用するための技法を説明する。本開示の技法は、例えば、1つのフルセグメント(a full segment)に利用可能なチャンクの数(a number of)をシグナリングすることを含む。本開示の技法はまた、例えば、検索(retrieval)のためにチャンクを要求するための、チャンクをアドレスするアドレッシング方式(addressing scheme)(例えば、ネーミング方式(naming schemes))を含む。
[0006] 一例では、メディアデータを検索する方法は、メディアデータの表現(representation)のセグメントに利用可能なセグメントチャンクの数(a number of segment chunks available for a segment)を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して(independently)検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの1つのための識別子を決定することと、サーバデバイスに、チャンクのうちの1つのための識別子を指定する(specifying)要求を送ることと、を含む。
[0007] 別の例では、メディアデータを検索するためのデバイスは、回路に実装され、かつ、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの1つのための識別子を決定することと、サーバデバイスに、チャンクのうちの1つのための識別子を指定する要求を送ることと、を行うように構成された1つまたは複数のプロセッサを含む。
[0008] 別の例では、メディアデータを検索するためのデバイスは、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信するための手段と、セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの1つのための識別子を決定するための手段と、サーバデバイスに、チャンクのうちの1つのための識別子を指定する要求を送るための手段と、を含む。
[0009] 別の例では、コンピュータ可読記憶媒体は、実行されたとき、プロセッサに、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの1つのための識別子を決定することと、サーバデバイスに、チャンクのうちの1つのための識別子を指定する要求を送ることと、を行わせる命令を記憶する。
[0010] 1つまたは複数の例の詳細が、添付の図面および以下の記述に記載されている。他の特徴、目的、および利点は、その記述および図面から、並びに、特許請求の範囲から明らかになるだろう。
[0011] 図1は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステムを図示するブロック図である。 [0012] 図2は、図1の検索ユニットのコンポーネントの例示的なセットをより詳細に図示するブロック図である。 [0013] 図3は、例示的なマルチメディアコンテンツの要素を図示する概念図である。 [0014] 図4は、例示的なビデオファイルの要素を図示するブロック図であり、それは、表現のセグメント(segment of a representation)に対応し得る。 [0015] 図5は、通常のセグメント提供(regular segment offerings)と、より短い複数のセグメントを用いた提供(offerings with shorter segments)との例を図示する概念図である。 [0016] 図6は、通常のセグメント提供と、より短い複数のセグメントを用いた提供とを介して利用可能なセグメントのためのユニフォームリソースロケータ(URL)を図示する概念図である。 [0017] 図7は、本開示の技法によってシグナリングされ得るデータの例示的なセットを図示する概念図である。 [0018] 図8は、本開示の技法に従った、セグメントのための階層型ナンバリング(hierarchical numbering)を使用するための技法の例を図示する。 [0019] 図9は、本開示の技法に従った、セグメントのための階層型ナンバリングを使用するための技法の別の例を図示する。 [0020] 図10は、本開示の技法によるメディアデータを搬送(送信および受信)する(transporting)例示的な方法を図示するフローチャートである。
発明の詳細な説明
[0021] 概して、本開示は、セグメントのシーケンス、例えば、従来のセグメントと比較すると比較的短い再生持続時間のデータを含むセグメントを使用するための技法を説明する。すなわち、1つまたは複数のセグメントは、ランダムアクセスポイント(RAP:random access point)を欠いている可能性がある(may)。よって、N秒(または、マイクロ秒、ミリ秒などのような他の時間単位)の再生持続時間のデータを有している単一のセグメント、RAPを有しかつセグメント利用可能開始時間(SAST:segment availability start time)に関連付けられている単一の(single)セグメントではなく、N秒の再生持続時間のデータと、RAPを含む複数のセグメントのうちの1つのみと、それぞれのSASTに関連付けられている複数のセグメントの各々と、を有する複数のセグメントが提供され得る。このようなより短いセグメントを使用することによって、従来の長いセグメントを使用するよりも早く再生を始めることができる。
[0022] より短いセグメントを使用した解決法(solution)を提供するために、単独で、または組み合わせで、様々なオプションが使用され得る。例えば、セグメントチャンクについてのセグメントタイムラインの間の明確な(accurate)持続時間が通知され(advertised)得る。しかしながら、正確な持続時間を通知することは行き過ぎ(overkill)であり得、多くのマニフェストファイル(例えば、メディアプレゼンテーション記述(MPD))更新を必要とし得る。階層型アドレッシング方式が使用され得る。しかしながら、階層型アドレッシング方式を使用するために十分な時間があるか否かは不明である。
[0023] 本開示の技法は、ISOベースのメディアファイルフォーマット、スケーラブルビデオコーディング(SVC)ファイルフォーマット、アドバンストビデオコーディング(AVC)ファイルフォーマット、第3世代パートナーシッププロジェクト(3GPP(登録商標))ファイルフォーマット、および/またはマルチビュービデオコーディング(MVC)ファイルフォーマット、または他の同様のビデオファイルフォーマットのうちの任意のものに従ってカプセル化されたメディアデータに準拠するメディアファイル(ビデオファイルなど)に適用され得る。
[0024] HTTPストリーミングでは、頻繁に使用される動作は、HEAD、GET、および部分的GETを含む。HEAD動作は、所与のユニフォームリソースロケータ(URL)またはユニフォームリソースネーム(URN)に関連付けられたファイルのヘッダを、そのURLまたはURNに関連付けられたペイロードを検索することなく、検索する。GET動作は、所与のURLまたはURNに関連付けられたファイル全体を検索する。部分的GET動作は、入力パラメータとしてバイト範囲を受信し、ファイルの連続的バイト数を検索し、ここで、そのバイト数は、受信したバイト範囲に対応する。よって、部分的GET動作が1つまたは複数の個々の動画フラグメントを得ることができるため、動画フラグメントは、HTTPストリーミングのために提供され得る。動画フラグメントでは、異なるトラックのいくつかのトラックフラグメントが存在し得る。HTTPストリーミングでは、メディアプレゼンテーションは、クライアントにとって(to)アクセス可能なデータの構造化された収集であり得る。クライアントは、ストリーミングサービスをユーザに提示(present)するために、メディアデータ情報を要求およびダウンロードし得る。
[0025] HTTPストリーミングを使用する3GPPデータのストリーミングの例では、マルチメディアコンテンツのビデオおよび/またはオーディオデータについて複数の表現が存在し得る。以下に説明されるように、異なる表現は、異なるコーディング特性(例えば、ビデオコーディング規格の異なるプロファイルまたはレベル)、異なるコーディング規格またはコーディング規格の拡張(マルチビューおよび/またはスケーラブル拡張などの)、または異なるビットレートに対応し得る。このような表現のマニフェストは、メディアプレゼンテーション記述(MPD:Media Presentation Description)データ構造において定義され得る。メディアプレゼンテーションは、HTTPストリーミングクライアントデバイスにとってアクセス可能なデータの構造化された収集に対応し得る。HTTPストリーミングクライアントデバイスは、クライアントデバイスのユーザにストリーミングサービスを提示するために、メディアデータ情報を要求およびダウンロードし得る。メディアプレゼンテーションは、MPDデータ構造において記述され得、それは、MPDの更新を含み得る。
[0026] メディアプレゼンテーションは、1つまたは複数の期間のシーケンス(a sequence of one or more periods)を含み得る。各期間は、次の期間の開始まで、または最後の期間の場合はメディアプレゼンテーションの終了まで、拡張し得る。各期間は、同じメディアコンテンツのための1つまたは複数の表現を含み得る。表現は、オーディオ、ビデオ、タイムドテキスト(timed text)、または他のこのようなデータの、いくつかの(a number of)代替的な符号化されたバージョンのうちの1つであり得る。表現は、符号化の(encoding)タイプによって、例えば、ビデオデータについてのビットレート、解像度、および/またはコーデック、並びに、オーディオデータについてのビットレート、言語、および/またはコーデックによって異なり得る。表現という用語は、マルチメディアコンテンツの特定の期間に対応しかつ特定の方法で符号化された、符号化オーディオまたはビデオデータの1つの区分(a section)を指すために使用され得る。
[0027] 特定の期間の表現は、その表現が属する適合セット(adaptation set)を示すMPD中の属性によって示されるグループに割り当てられ得る。同じ適合セット中の表現は、概して、クライアントデバイスが、例えば、帯域幅適合を行うためにこれらの表現間を(between these representations)動的およびシームレスに切り替えることができるという点において、互いに対して代替であると考えられる。例えば、特定の期間のビデオデータの各表現は、対応する期間のためのマルチメディアコンテンツの、ビデオデータまたはオーディオデータなどのメディアデータを提示する復号のために、それら表現のうちのいずれかが選択され得るように、同じ適合セットに割り当てられ得る。1つの期間(one period)内のメディアコンテンツは、存在する場合、グループ0からの1つの表現か、または、いくつかの(some)例では、各非ゼログループからの多くとも1つの表現の組合せか、のいずれかで表現され得る。ある期間(a period)の各表現のためのタイミングデータが、その期間の開始時間に関して表され(be expressed)得る。
[0028] 表現は、1つまたは複数のセグメントを含み得る。各表現は、初期化セグメントを含み得るか、または表現の各セグメントは、自己初期化し(self-initializing)得る。存在する場合、初期化セグメントは、表現にアクセスするための初期化情報を含み得る。一般に、初期化セグメントは、メディアデータを含まない。セグメントは、ユニフォームリソースロケータ(URL)、ユニフォームリソースネーム(URN)、またはユニフォームリソース識別子(URI)などの識別子によって一意に参照され得る。MPDは、各セグメントに識別子を提供し得る。いくつかの例では、MPDはまた、範囲属性(range attribute)の形式でバイト範囲を提供し得、それは、URL、URN、またはURIによってアクセス可能なファイル内のセグメントのためのデータに対応し得る。
[0029] 異なるタイプのメディアデータについて実質的に同時な検索のために、異なる表現が選択され得る。例えば、クライアントデバイスは、セグメントを検索するためのオーディオ表現、ビデオ表現、およびタイムドテキスト表現を選択し得る。いくつかの例では、クライアントデバイスは、帯域幅適合を行うために、特定の適合セットを選択し得る。すなわち、クライアントデバイスは、ビデオ表現を含む適合セット、オーディオ表現を含む適合セット、および/またはタイムドテキストを含む適合セット、を選択し得る。代替的に、クライアントデバイスは、あるタイプのメディア(例えば、ビデオ)についての適合セットを選択し得、他のタイプのメディア(例えば、オーディオおよび/またはタイムドテキスト)のための表現を直接選択し得る。
[0030]図1は、ネットワークを介してメディアデータをストリーミングするための技法を実装する例示的なシステム10を図示するブロック図である。この例では、システム10は、コンテンツ準備デバイス20、サーバデバイス60、およびクライアントデバイス40を含む。クライアントデバイス40およびサーバデバイス60は、ネットワーク74によって通信可能に結合され、それはインターネットを備え得る。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60もまた、ネットワーク74または別のネットワークによって結合され得るか、または直接、通信的に結合され得る。いくつかの例では、コンテンツ準備デバイス20およびサーバデバイス60は、同じデバイスを備え得る。
[0031] コンテンツ準備デバイス20は、図1の例では、オーディオソース22およびビデオソース24を備える。オーディオソース22は、例えば、オーディオエンコーダ26によって符号化されるべきキャプチャされたオーディオデータを表す電気信号を生成するマイクロフォンを備え得る。代替的に、オーディオソース22は、前に記録されたオーディオデータを記憶する記憶媒体、コンピュータ化されたシンセサイザなどのオーディオデータ生成器、またはオーディオデータの任意の他のソースを備え得る。ビデオソース24は、ビデオエンコーダ28によって符号化されるべきビデオデータを生成するビデオカメラ、前に記録されたビデオデータで符号化された記憶媒体、コンピュータグラフィックスソースなどのビデオデータ生成ユニット、またはビデオデータの任意の他のソースを備え得る。コンテンツ準備デバイス20は、必ずしも全ての例においてサーバデバイス60に通信可能に結合されるわけではなく、サーバデバイス60によって読み出される別個の媒体にマルチメディアコンテンツを記憶し得る。
[0032] ローオーディオ(Raw audio)およびビデオデータは、アナログまたはデジタルデータを備え得る。アナログデータは、オーディオエンコーダ26および/またはビデオエンコーダ28によって符号化される前に、デジタル化され得る。オーディオソース22は、会話の参加者(speaking participant)から、その会話の参加者が話している間オーディオデータを取得し得、ビデオソース24は、同時に会話の参加者のビデオデータを取得し得る。他の例では、オーディオソース22は、記憶されたオーディオデータを備えるコンピュータ可読記憶媒体を備え得、ビデオソース24は、記憶されたビデオデータを備えるコンピュータ可読記憶媒体を備え得る。このように、本開示で説明される技法は、ライブの、ストリーミングの、リアルタイムのオーディオおよびビデオデータに、あるいは、アーカイブされた、事前に記録されたオーディオおよびビデオデータに、適用され得る。
[0033] ビデオフレームに対応するオーディオフレームは、概して、ビデオフレーム内に含まれるビデオソース24によってキャプチャされた(または生成された)ビデオデータと同時に(contemporaneously)オーディオソース22によってキャプチャされた(または生成された)オーディオデータを含むオーディオフレームである。例えば、会話の参加者が概して話すことによってオーディオデータを生成する間、オーディオソース22は、オーディオデータをキャプチャし、ビデオソース24は、同時に、すなわち、オーディオソース22がオーディオデータをキャプチャしている間に、会話の参加者のビデオデータをキャプチャする。ゆえに、オーディオフレームは、1つまたは複数の特定のビデオフレームに時間的に対応し得る。従って、ビデオフレームに対応するオーディオフレームは、概して、オーディオデータおよびビデオデータが同時にキャプチャされ、オーディオフレームおよびビデオフレームがそれぞれ、同時にキャプチャされたオーディオデータおよびビデオデータを備えた状況に対応する。
[0034] いくつかの例では、オーディオエンコーダ26は、その符号化オーディオフレームに関するオーディオデータが記録された時間を表現する、各符号化オーディオフレーム中のタイムスタンプを符号化し得、同様に、ビデオエンコーダ28は、符号化されたビデオフレームに関するビデオデータが記録された時間を表す、各符号化されたビデオフレーム中のタイムスタンプを符号化し得る。このような例では、ビデオフレームに対応するオーディオフレームは、タイムスタンプを備えるオーディオフレームと、同じタイムスタンプを備えるビデオフレームとを備え得る。コンテンツ準備デバイス20は、オーディオエンコーダ26および/またはビデオエンコーダ28がタイムスタンプを生成し得る、または、オーディオソース22およびビデオソース24がオーディオおよびビデオデータをそれぞれタイムスタンプと関連付けるために使用し得る、内部クロックを含み得る。
[0035] いくつかの例では、オーディオソース22は、オーディオエンコーダ26に、オーディオデータが記録された時間に対応するデータを送り得、ビデオソース24は、ビデオエンコーダ28に、ビデオデータが記録された時間に対応するデータを送り得る。いくつかの例では、オーディオエンコーダ26は、符号化オーディオデータ(encoded audio data)の相対時間的順序(a relative temporal ordering)を示すために、しかしオーディオデータが記録された絶対時間を必ずしも示すことなく、符号化オーディオデータ中のシーケンス識別子を符号化し、同様に、ビデオエンコーダ28もまた、符号化ビデオデータの相対時間的順序を示すために、シーケンス識別子を使用し得る。同様に、いくつかの例では、シーケンス識別子は、マッピングされ得るか、またはそうでなければ(otherwise)タイムスタンプと互いに関連付けられ(correlated with)得る。
[0036] オーディオエンコーダ26は、概して、符号化オーディオデータのストリームを生成し、一方、ビデオエンコーダ28は、符号化ビデオデータのストリームを生じさせる(produces)。(オーディオであろうとビデオであろうと)データの各個々のストリームは、エレメンタリストリームと呼ばれ得る。エレメンタリストリームは、単一の、デジタル的にコーディングされた(場合によっては圧縮された)表現のコンポーネントである。例えば、表現のコーディングされたビデオまたはオーディオ部分は、エレメンタリストリームであり得る。エレメンタリストリームは、ビデオファイル内でカプセル化される前に、パケット化されたエレメンタリストリーム(PES:packetized elementary stream)に変換され得る。同じ表現内で、1つのエレメンタリストリームに属するPESパケットを、他と区別するために、ストリームIDが使用され得る。エレメンタリストリームのデータの基本ユニットは、1つのパケット化されたエレメンタリストリーム(PES)パケットである。よって、コーディングされたビデオデータは、概して、エレメンタリビデオストリームに対応する。同様に、オーディオデータは、1つまたは複数のそれぞれのエレメンタリストリームに対応する。
[0037] ITU−T H.264/AVCおよび来たる高効率ビデオコーディング(HEVC)規格などの多くのビデオコーディング規格は、エラーのない(error-free)ビットストリームのための、復号処理、セマンティクス(semantics)、およびシンタックスを定義し、それらのうちのいずれも、ある(certain)プロファイルまたはレベルに準拠する。ビデオコーディング規格は通常、エンコーダを指定しないが、エンコーダは、生成されるビットストリームがデコーダに関する規格に準拠することを保証する役割を課せられる(is tasked with)。ビデオコーディング規格のコンテキストでは、「プロファイル」は、アルゴリズム、特徴、またはツールのサブセット、およびこれらに適用される制約条件に対応する。H.264規格によって定義されるように、例えば、「プロファイル」は、H.264規格によって規定される全体のビットストリームシンタックスのサブセットである。「レベル」は、例えばデコーダメモリおよび計算などのデコーダリソース消費の制限に対応し、それらは、ピクチャの解像度、ビットレート、およびブロック処理レートに関連する。プロファイルは、profile_idc(プロファイルインジケータ)値を用いてシグナリングされ得、一方、レベルは、level_idc(レベルインジケータ)値を用いてシグナリングされ得る。
[0038] 例えば、所与の(given)プロファイルのシンタックスによって課せられる範囲(bounds)内で、復号されたピクチャの指定されたサイズなどのビットストリーム中のシンタックス要素によってとられる(taken)値に応じて、エンコーダおよびデコーダのパフォーマンスにおいて大きな変動を要する(require)ことが未だ(still)あり得ることを、H.264規格は認識している(recognizes)。多くのアプリケーションにおいて、特定のプロファイル内のシンタックスの全ての仮想的な(hypothetical)使用に対処することが可能なデコーダを実装することは実用的でも経済的でもないことを、H.264規格はさらに認識している。従って、H.264規格は、「レベル」を、ビットストリーム中のシンタックス要素の値に課せられた制約条件の指定されたセットと定義している。これらの制約条件は、値に対する単純な制限であり得る。代替的に、これらの制約条件は、(例えば、ピクチャ幅×ピクチャの高さ×1秒あたりに復号されるピクチャの数等の)値の算術的な組合せに対する(on)制約条件の形をとり得る。H.264規格は、個々の実装が、サポートされるプロファイルごとに異なるレベルをサポートし得るとさらに規定している(provides)。
[0039] プロファイルに適合するデコーダは通常、プロファイルで定義される全ての機能をサポートする。例えば、コーディング機能として、Bピクチャコーディングは、H.264/AVCのベースラインプロファイルではサポートされていないが、H.264/AVCの他のプロファイルでサポートされている。あるレベルに適合するデコーダは、そのレベルに定義された制限を超えるリソースを必要としない、いかなる(any)ビットストリームも復号することが可能であるべきである。プロファイルおよびレベルの定義は、解釈能力(interpretability)に関して役立ち得る。例えば、ビデオ送信の間に、プロファイルおよびレベルの定義のペアが、送信セッション全体について交渉され合意され得る。より具体的には、H.264/AVCにおいて、レベルは、処理される必要があるマクロブロック数(the number of macroblocks)、復号されたピクチャバッファ(DPB:decoded picture buffer)サイズ、コーディングされたピクチャバッファ(CPB:coded picture buffer)サイズ、垂直動きベクトル範囲、2つの連続するMBあたりの動きベクトルの最大数、およびBブロックが8×8ピクセルに満たない(less than)サブマクロブロック区分を有することができるか否か、に対する(on)制限を定義し得る。このように、デコーダは、そのデコーダがビットストリームを適切に復号することが可能か否かを決定し得る。
[0040] 図1の例では、コンテンツ準備デバイス20のカプセル化ユニット30は、ビデオエンコーダ28からのコーディングされたビデオデータを備えるエレメンタリストリームと、オーディオエンコーダ26からのコーディングされたオーディオデータを備えるエレメンタリストリームと、を受信する。いくつかの例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データから(from)PESパケットを形成するためのパケタイザを含み得る。他の例では、ビデオエンコーダ28およびオーディオエンコーダ26は各々、符号化データからPESパケットを形成するためのそれぞれのパケタイザとインターフェースし得る。さらに他の例では、カプセル化ユニット30は、符号化オーディオおよびビデオデータからPESパケットを形成するためのパケタイザを含み得る。
[0041] ビデオエンコーダ28は、ピクセル解像度、フレームレート、様々なコーディング規格への準拠、様々なコーディング規格についての様々なプロファイルおよび/またはプロファイルのレベルへの準拠、(例えば、2次元または3次元の再生のための)1つのまたは複数のビューを有する表現、または他のこのような特性などの、様々な特性を有する、および様々なビットレートにおける、マルチメディアコンテンツの異なる表現を生成する(produce)ために、マルチメディアコンテンツのビデオデータを様々な方法で符号化し得る。本開示で使用される場合、表現は、オーディオデータ、ビデオデータ、(例えば字幕のための)テキストデータ、または他のこのようなデータのうちの1つを備え得る。表現は、オーディオエレメンタリストリームまたはビデオエレメンタリストリームなどのエレメンタリストリームを含み得る。各PESパケットは、PESパケットが属するエレメンタリストリームを識別するstream_idを含み得る。カプセル化ユニット30は、エレメンタリストリームを様々な表現のビデオファイル(例えば、セグメント)にアセンブルする役割を担う。
[0042] カプセル化ユニット30は、オーディオエンコーダ26およびビデオエンコーダ28から表現のエレメンタリストリームに関するPESパケットを受信し、それらPESパケットから、対応するネットワーク抽象化レイヤ(NAL:network abstraction layer)ユニットを形成する。H.264/AVC(Advanced Video Coding)の例では、コーディングされたビデオセグメントは、NALユニットへと編成され、それらは、ビデオ電話、ストレージ、ブロードキャスト、またはストリーミングなどのアプリケーションをアドレスする「ネットワークフレンドリーな(network-friendly)」ビデオ表現を提供する。NALユニットは、ビデオコーディングレイヤ(VCL:Video Coding Layer)NALユニットおよび非VCL NALユニットに分類され得る。VCLユニットは、コア圧縮エンジンを含み得、ブロック、マクロブロック、および/またはスライスレベルのデータを含み得る。他のNALユニットは、非VCL NALユニットであり得る。いくつかの例では通常、プライマリコーディングピクチャとして提示される1つの時間インスタンス(one time instance)においてコーディングされたピクチャは、アクセスユニットに含まれ得、それは、1つまたは複数のNALユニットを含み得る。
[0043] 非VCL NALユニットは、とりわけ(among others)、パラメータセットNALユニットおよびSEI NALユニットを含み得る。パラメータセットは、(シーケンスパラメータセット(SPS)中に)シーケンスレベルヘッダ情報、および(ピクチャパラメータセット(PPS)中に)頻繁には変化しない(infrequently changing)ピクチャレベルヘッダ情報を含み得る。パラメータセット(例えば、PPSおよびSPS)を用いることで、頻繁には変化しない情報は、シーケンスまたはピクチャごとに(for each)繰り返される必要がなく、よってコーディング効率が改善され得る。さらに、パラメータセットの使用は、重要なヘッダ情報の帯域外送信を可能にし得、エラー耐性(error resilience)のための冗長な送信の必要が無くなる(avoiding)。帯域外送信の例では、パラメータセットNALユニットは、SEI NALユニットなどの他のNALユニットとは異なるチャネル上で送信され得る。
[0044] 付加拡張情報(SEI:Supplemental Enhancement Information)は、VCL NALユニットからのコーディングされたピクチャサンプルを復号するために必要ではない情報を含み得るが、復号、表示、誤り耐性、および他の目的に関連したプロセスを支援し得る。SEIメッセージは、非VCL NALユニットに含まれ得る。SEIメッセージは、いくつかの規格仕様書(standard specifications)の規範的(normative)部分であり、従って、規格準拠のデコーダ実装のために必ずしも必須ではない。SEIメッセージは、シーケンスレベルSEIメッセージまたはピクチャレベルSEIメッセージであり得る。何らかのシーケンスレベル情報が、SVCの例におけるスケーラビリティ情報SEIメッセージ、およびMVC中でのビュースケーラビリティ情報SEIメッセージなどのSEIメッセージに含まれ得る。これらの例示的なSEIメッセージは、例えば、動作点の抽出および動作点の特性に関する(on)情報を伝達し得る。加えて、カプセル化ユニット30は、表現の特性を説明するメディアプレゼンテーション記述子(MPD:media presentation descriptor)などのマニフェストファイルを形成し得る。カプセル化ユニット30は、拡張可能マークアップ言語(XML)に従ってMPDをフォーマットし得る。
[0045] カプセル化ユニット30は、出力インターフェース32へ、マニフェストファイル(例えば、MPD)とともに(along with)マルチメディアコンテンツの1つまたは複数の表現についての(for)データを提供し得る。出力インターフェース32は、ユニバーサルシリアルバス(USB)インターフェース、CDまたはDVDライタまたはバーナ、磁気またはフラッシュ記憶媒体へのインターフェース、あるいはメディアデータを記憶または送信するための他のインターフェースなどの、記憶媒体に書き込みするためのインターフェースまたはネットワークインターフェースを備え得る。カプセル化ユニット30は、マルチメディアコンテンツの表現の各々のデータを、出力インターフェース32に提供し得、それは、そのデータをネットワーク送信または記憶媒体を介してサーバデバイス60に送り得る。図1の例では、サーバデバイス60は、それぞれのマニフェストファイル66および1つまたは複数の表現68A〜68N(表現68)を各々が含む、様々なマルチメディアコンテンツ64を記憶する記憶媒体62を含む。いくつかの例では、出力インターフェース32はまた、データをネットワーク74に直接送り得る。
[0046] いくつかの例では、表現68は、適合セットに分けられ得る。すなわち、表現68の様々なサブセットは、復号されかつ例えばスピーカによって提示されるべきオーディオデータおよび/または表現を用いて(with)表示される(to be displayed)テキストの言語または他の特性を識別し得るテキストタイプ情報、適合セット中の表現に関するシーンの現実世界のカメラの視点(real-world camera perspective)またはカメラアングルを説明し得るカメラアングル情報、特定の視聴者(audiences)に対するコンテンツの適合性を説明するレーティング情報、コーデック、プロファイルおよびレベル、解像度、ビューの数、セグメントに関するファイルフォーマット、あるいは同様のもの、のような特性の各共通のセット、を含み得る。
[0047] マニフェストファイル66は、特定の適合セットのための共通の特性と同様に(as well as)、その適合セットに対応する表現68のサブセットを示すデータを含み得る。マニフェストファイル66はまた、適合セットの個々の表現のために、ビットレートなどの個々の特性を表すデータを含み得る。このように、適合セットは、簡略化されたネットワーク帯域幅適合を提供し得る。適合セット中の表現は、マニフェストファイル66の適合セット要素の子要素(child elements)を使用して示され得る。
[0048] サーバデバイス60は、要求処理ユニット70およびネットワークインターフェース72を含む。いくつかの例では、サーバデバイス60は、複数のネットワークインターフェースを含み得る。さらに、サーバデバイス60の特徴のうちの任意のものまたは全ては、ルータ、ブリッジ、プロキシデバイス、スイッチ、または他のデバイスなどのコンテンツ配信ネットワークの他のデバイスにおいて実装され得る。いくつかの例では、コンテンツ配信ネットワークの仲介デバイス(intermediate devices)は、マルチメディアコンテンツ64のデータをキャッシュし得、サーバデバイス60のものに実質的に準拠するコンポーネントを含み得る。概して、ネットワークインターフェース72は、ネットワーク74を介してデータを送るおよび受信するように構成される。
[0049] 要求処理ユニット70は、記憶媒体62のデータのための、クライアントデバイス40などのクライアントデバイスから(from)ネットワーク要求を受信するように構成される。例えば、要求処理ユニット70は、1999年6月のFielding et alによる「Hypertext Transfer Protocol - HTTP/1. 1」ネットワークワーキンググループ、IETF、RFC 2616において説明されているようなハイパーテキスト転送プロトコル(HTTP)バージョン1.1を実装し得る。すなわち、要求処理ユニット70は、HTTP GETまたは部分的GET要求を受信し、それら要求に応答して、マルチメディアコンテンツ64のデータを提供するように構成され得る。それら要求は、例えばセグメントのURLを使用して、表現68のうちの1つの表現のセグメントを指定し得る。いくつかの例では、それら要求はまた、セグメントの1つまたは複数のバイト範囲を指定し得、よって、部分的GET要求を備える。要求処理ユニット70はさらに、表現68のうちの1つのセグメントのヘッダデータを提供するためにHTTP HEAD要求をサービスするように構成され得る。いずれの場合も、要求処理ユニット70は、要求されたデータをクライアントデバイス40などの要求しているデバイスに提供するために、それら要求を処理するように構成され得る。
[0050] 加えてまたは代替として、要求処理ユニット70は、eMBMSなどのブロードキャストまたはマルチキャストプロトコルを介して、メディアデータを配信するように構成され得る。コンテンツ準備デバイス20は、説明されたものと実質的に同じ方法でDASHセグメントおよび/またはサブセグメントを作成し得るが、サーバデバイス60は、eMBMSあるいは別のブロードキャストまたはマルチキャストネットワークトランスポートプロトコルを使用してこれらのセグメントまたはサブセグメントを配信し得る。例えば、要求処理ユニット70は、クライアントデバイス40から(from)マルチキャストグループ参加要求(multicast group join request)を受信するように構成され得る。すなわち、サーバデバイス60は、(例えば、ライブイベントのブロードキャストなどの)特定のメディアコンテンツに関連付けられた、クライアントデバイス40を含むクライアントデバイスに、マルチキャストグループに関連付けられたインターネットプロトコル(IP:Internet protocol)アドレスを通知し(advertise)得る。クライアントデバイス40は順に(in turn)、そのマルチキャストグループに参加するための(to)要求をサブミット(submit)し得る。この要求は、マルチキャストグループに関連付けられたIPアドレスを宛先とした(destined for)トラフィックを、クライアントデバイス40などの加入しているクライアントデバイスへとルータが向け(derect)させるように、例えばネットワーク74を構成するルータなどのネットワーク74全体に伝播され(be propagated throughout)得る。
[0051] 図1の例に例示されるように、マルチメディアコンテンツ64は、マニフェストファイル66を含み、それは、メディアプレゼンテーション記述(MPD)に対応し得る。マニフェストファイル66は、異なる代替の表現68の記述(例えば、異なる品質を有するビデオサービス)を含み得、その記述は、例えば、コーデック情報、プロファイル値、レベル値、ビットレート、および表現68の他の記述的特性を含み得る。クライアントデバイス40は、表現68のセグメントにどのようにアクセスするかを決定するために、メディアプレゼンテーションのMPDを検索し得る。
[0052] 具体的には(In particular)、検索ユニット52は、ビデオデコーダ48の復号性能とビデオ出力44のレンダリング性能とを決定するために、クライアントデバイス40の構成データ(図示せず)を検索し得る。構成データはまた、クライアントデバイス40のユーザによって選択された言語選好、クライアントデバイス40のユーザによって設定された深度選好に対応する1つまたは複数のカメラパースペクティブ、および/またはクライアントデバイス40のユーザによって選択されたレーティング選好のうちの任意のものまたは全てを含み得る。検索ユニット52は、例えば、HTTP GETおよび部分的GET要求をサブミットするように構成されるウェブブラウザまたはメディアクライアントを備え得る。検索ユニット52は、クライアントデバイス40の1つまたは複数のプロセッサまたは処理ユニット(図示せず)によって実行されるソフトウェア命令に対応し得る。いくつかの例では、検索ユニット52に関して説明される機能性の全てまたは一部は、ハードウェアにおいて、あるいは、ハードウェア、ソフトウェア、および/またはファームウェアの組合せにおいて実装され得、ここで、必須ハードウェアが、ソフトウェアまたはファームウェアのための命令を実行するために提供され得る。
[0053] 検索ユニット52は、クライアントデバイス40のレンダリング性能(capabilities)および復号を、マニフェストファイル66の情報によって示される表現68の特性と比較し得る。検索ユニット52は初めに、表現68の特性を決定するためにマニフェストファイル66の少なくとも一部分を検索し得る。例えば、検索ユニット52は、1つまたは複数の適合セットの特性を説明するマニフェストファイル66の一部を要求し得る。検索ユニット52は、クライアントデバイス40のレンダリング性能およびコーディングによって満足され得る特性を有する(例えば適合セットなどの)表現68のサブセットを選択し得る。検索ユニット52は次に、適合セット中の表現のためのビットレートを決定し、ネットワーク帯域幅の現在利用可能な量を決定し、および、ネットワーク帯域幅によって満足され得るビットレートを有する表現のうちの1つから(from)セグメントを検索し得る。
[0054] 一般に、より高いビットレートの表現は、より高い品質のビデオ再生をもたらし得、一方、より低いビットレートの表現は、利用可能なネットワーク帯域幅が減少するときに十分な品質のビデオ再生を提供し得る。従って、利用可能なネットワーク帯域幅が比較的高いとき、検索ユニット52は、比較的高いビットレートの表現から(from)データを検索し得、それに対して(whereas)、利用可能なネットワーク帯域幅が低いとき、検索ユニット52は、比較的低いビットレートの表現からデータを検索し得る。このように、クライアントデバイス40は、ネットワーク74のネットワーク帯域幅の利用可能性を変化することに適応しつつ(while)、ネットワーク74を介してマルチメディアデータをストリーミングし得る。
[0055] 加えてまたは代替として、検索ユニット52は、eMBMSまたはIPマルチキャストなどのブロードキャストまたはマルチキャストネットワークプロトコルに従ってデータを受信するように構成され得る。このような例では、検索ユニット52は、特定のメディアコンテンツに関連付けられたマルチキャストネットワークグループに参加するための要求をサブミットし得る。マルチキャストグループに参加した後に、検索ユニット52は、さらなる要求がサーバデバイス60またはコンテンツ準備デバイス20に出される(issued to)ことなく、マルチキャストグループのデータを受信し得る。検索ユニット52は、例えば、再生を停止するために(to)、または異なるマルチキャストグループにチャネルを変更するために、そのマルチキャストグループのデータがもはや必要ではないとき、そのマルチキャストグループを離れるための要求(a request to leave)をサブミットし得る。
[0056] ネットワークインターフェース54は、選択された表現のセグメントのデータを受信し、それを検索ユニット52に提供し得、それは順に、非カプセル化(decapsulation)ユニット50にセグメントを提供し得る。非カプセル化ユニット50は、構成要素PESストリームへとビデオファイルの要素を非カプセル化し、符号化データを検索するためのPESストリームを非パケット化(depacketize)し、例えば、ストリームのPESパケットヘッダによって示されているように、符号化データがオーディオストリームの一部であるか、またはビデオストリームの一部であるかに依存して、オーディオデコーダ46またはビデオデコーダ48のいずれかに符号化データを送り得る。オーディオデコーダ46は、符号化オーディオデータを復号し、その復号オーディオデータをオーディオ出力42に送り、一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ビデオ出力44に、ストリームの複数のビューを含み得るその復号ビデオデータを送る。
[0057] ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、検索ユニット52、および非カプセル化ユニット50は各々、適宜(as applicable)、1つまたは複数のマイクロプロセッサ、デジタルシグナルプロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)、離散(discrete)論理回路、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせなどの、様々な適切な処理回路の任意のものとして実装され得る。ビデオエンコーダ28およびビデオデコーダ48の各々は、1つまたは複数のエンコーダまたはデコーダに含まれ得、それらのうちのいずれも(either)、組み合わされたビデオエンコーダ/デコーダ(CODEC)の一部として一体化され得る。同様に、オーディオエンコーダ26およびオーディオデコーダ46の各々は、1つまたは複数のエンコーダまたはデコーダに含まれ得、それらのいずれも、組み合わせられたCODECの一部として統合され得る。ビデオエンコーダ28、ビデオデコーダ48、オーディオエンコーダ26、オーディオデコーダ46、カプセル化ユニット30、検索ユニット52、および/または非カプセル化ユニット50を含む装置は、集積回路、マイクロプロセッサ、および/またはセルラ電話などのワイヤレス通信デバイスを備え得る。
[0058] クライアントデバイス40、サーバデバイス60、および/またはコンテンツ準備デバイス20は、この開示の技法に従って動作するように構成され得る。例示のために、この開示は、クライアントデバイス40およびサーバデバイス60に関するこれらの技法を説明している。しかしながら、サーバデバイス60の代わりに(またはそれに加えて)、コンテンツ準備デバイス20が、これらの技法を行うように構成され得ることが理解されるべきである。
[0059] カプセル化ユニット30は、NALユニットが属するプログラムを識別するヘッダ、並びにペイロード、例えば、NALユニットが対応するトランスポートまたはプログラムストリームを説明する(describes)データ、オーディオデータ、あるいは、ビデオデータ、を備えるNALユニットを形成し得る。例えば、H.264/AVCでは、NALユニットは、サイズが可変のペイロードと1バイトのヘッダを含む。そのペイロード中にビデオデータを含むNALユニットは、ビデオデータの様々な粒度レベル(granularity levels)を備え得る。例えば、NALユニットは、ビデオデータの1つのブロック(a block of)、複数のブロック、ビデオデータの1つのスライス(a slice of)、またはビデオデータの全体のピクチャを備え得る。カプセル化ユニット30は、エレメンタリストリームのPESパケットの形式で、ビデオエンコーダ28から(from)符号化ビデオデータを受信し得る。カプセル化ユニット30は、対応するプログラムと各エレメンタリストリームを関連付け得る。
[0060] カプセル化ユニット30はまた、複数のNALユニットから(from)アクセスユニットをアセンブルし得る。一般に、アクセスユニットは、ビデオデータのフレーム、並びに、このようなオーディオデータが利用可能なときにはそのフレームに対応するオーディオデータ、を表現するための1つまたは複数のNALユニットを備え得る。あるアクセスユニットは、概して、1つの出力時間インスタンスに関する(for)全てのNALユニット、例えば、1つの時間インスタンスに関する全てのオーディオおよびビデオデータを含む。例えば、各ビューが1秒あたり20フレームのフレームレート(fps:frames per second)を有する場合、各時間インスタンスは、0.05秒の時間間隔に対応し得る。この時間間隔の間に、同じアクセスユニット(同じ時間インスタンス)の全てのビューのための特定のフレームが同時にレンダリングされ得る。一例では、あるアクセスユニットは、1つの時間インスタンスにおけるあるコーディングされたピクチャ(a coded picture)を備え得、それは、プライマリコーディングピクチャとして提示され得る。
[0061] 従って、アクセスユニット(an access unit)は、共通の時間的インスタンスの全てのオーディオおよびビデオフレーム、例えば時間Xに対応する全てのビューを備え得る。本開示はまた、特定のビューの符号化されたピクチャを「ビューコンポーネント」と呼ぶ。すなわち、ビューコンポーネントは、特定の時間における特定のビューに関する符号化されたピクチャ(またはフレーム)を備え得る。従って、アクセスユニットは、共通の時間的インスタンスの全てのビューコンポーネントを備えるものとして定義され得る。アクセスユニットの復号順序は、出力または表示順序と必ずしも同じである必要はない。
[0062] メディアプレゼンテーションは、メディアプレゼンテーション記述(MPD)を含み得、それは、異なる代替の表現(例えば、異なる品質を有するビデオサービス)の説明を包含し、記述は、例えば、コーデック情報、プロファイル値、およびレベル値を含み得る。MPDは、マニフェストファイル66などのマニフェストファイルの一例である。クライアントデバイス40は、様々なプレゼンテーションの動画フラグメント(movie fragments)にどのようにアクセスするかを決定するために、メディアプレゼンテーションのMPDを検索し得る。動画フラグメントは、ビデオファイルの動画フラグメントボックス(moof box)に位置し得る。
[0063] (例えば、MPDを備え得る)マニフェストファイル66は、表現68のセグメントの利用可能性を通知し得る。すなわち、MPDは、表現68のうちの1つの第1のセグメントが利用可能になるウォールクロック時間(the wall-clock time)を示す情報、並びに、表現68内のセグメントの持続時間を示す情報を含み得る。このように、クライアントデバイス40の検索ユニット52は、特定のセグメントに先行するセグメントの開始時間並びに持続時間に基づいて、各セグメントがいつ利用可能になるかを決定し得る。
[0064] カプセル化ユニット30が受信されたデータに基づいてNALユニットおよび/またはアクセスユニットをビデオファイルへとアセンブルした後に、カプセル化ユニット30は、出力のために出力インターフェース32にビデオファイルを渡す。いくつかの例では、カプセル化ユニット30は、直接クライアントデバイス40にビデオファイルを送るのではなく、ビデオファイルをローカルに記憶し得るか、または出力インターフェース32を介してリモートサーバにビデオファイルを送り得る。出力インターフェース32は、例えば、送信機、トランシーバ、コンピュータ可読媒体にデータを書き込みするためのデバイス、例えば、光学式ドライブ、磁気媒体ドライブ(例えば、フロッピー(登録商標)ドライブ)、ユニバーサルシリアルバス(USB)ポート、ネットワークインターフェース、または他の出力インターフェースなどを備え得る。出力インターフェース32は、ビデオファイルを、例えば、送信信号、磁気媒体、光学媒体、メモリ、フラッシュドライブ、または他のコンピュータ可読媒体などのコンピュータ可読媒体に出力する。
[0065] ネットワークインターフェース54は、ネットワーク74を介してNALユニットまたはアクセスユニットを受信し、検索ユニット52を介して非カプセル化ユニット50にNALユニットまたはアクセスユニットを提供し得る。非カプセル化ユニット50は、構成要素PESストリームへとビデオファイルの要素を非カプセル化し、符号化データを検索するために(to)PESストリームを非パケット化し、例えば、ストリームのPESパケットヘッダによって示されているように、符号化データがオーディオストリームの一部であるか、またはビデオストリームの一部であるか否かに依存して、オーディオデコーダ46またはビデオデコーダ48のいずれかに符号化データを送り得る。オーディオデコーダ46は、符号化オーディオデータを復号し、その復号オーディオデータをオーディオ出力42に送り、一方、ビデオデコーダ48は、符号化ビデオデータを復号し、ビデオ出力44に、ストリームの複数のビューを含み得るその復号ビデオデータを送る。
[0066] 本開示の技法に従って、マニフェストファイル66は、任意のまたは全ての表現68のセグメントが利用可能である「チャンク」の数をシグナリングする属性を含むように修正され(be modified)得る。例えば、マニフェストファイル66は、下記でより詳細に論じられるように、「@k」属性を含むMPDを表現し得る。さらに、検索ユニット52および/または要求処理ユニット70は、セグメントチャンクをアドレスするために、本開示の技法に従って構成され得る。具体的には、アドレッシング方式は、例えばセグメントのチャンクのための単純なナンバリングテンプレート(「$Number$」)、または少なくとも2つの部分を含む階層型アドレッシング方式の使用を含み得る。第1の部分は、対応するセグメントについてのフルセグメント番号、または対応するセグメントのタイミング情報に対応し得る。タイミング情報は、例えば、対応するセグメントがプレイされ始めるべき再生時間を示し得る。第2の部分は、チャンクの通常の識別番号(ordinal numeric identifier)に対応し得る。例えば、階層型アドレッシング方式は、「$Number$. $ChunkNumber$」フォーマットまたは「$Time$. $ChunkNumber$」フォーマットを使用し得る。
[0067] このように、クライアントデバイス40は、回路に実装され、かつ、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備え、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの1つのための識別子を決定することと、サーバデバイスに、チャンクのうちの1つのための識別子を指定する要求を送ることと、を行うように構成された1つまたは複数のプロセッサを含む、メディアデータを検索するためのデバイスの例を表現する。
[0068] 図2は、図1の検索ユニット52のコンポーネントの例示的なセットをより詳細に図示するブロック図である。この例では、検索ユニット52は、eMBMSミドルウェアユニット100、DASHクライアント110、およびメディアアプリケーション112を含む。
[0069] この例では、eMBMSミドルウェアユニット100はさらに、eMBMS受信ユニット106、キャッシュ104、およびサーバユニット102を含む。この例では、eMBMS受信ユニット106は、例えば、http://tools. ietf. org/html/rfc6726で利用可能な、2012年11月のPaila et al.による「FLUTE-File Delivery over Unidirectional Transport」、ネットワークワーキンググループ、RFC 6726において説明されているような、単一方向の搬送を介するファイル配信(FLUTE:File Delivery over Unidirectional Transport)に従って、eMBMSを介してデータを受信するように構成される。すなわち、eMBMS受信ユニット106は、BM−SCとして機能し得るサーバデバイス60などから、ブロードキャストを介してファイルを受信し得る。
[0070] eMBMSミドルウェアユニット100がファイルに関するデータを受信するとき(As)、eMBMSミドルウェアユニットは、その受信したデータをキャッシュ104に記憶し得る。キャッシュ104は、フラッシュメモリ、ハードディスク、RAM、または任意の他の適切な記憶媒体などのコンピュータ可読記憶媒体を備え得る。
[0071] ローカルサーバユニット102は、DASHクライアント110のためのサーバとして機能し得る。例えば、ローカルサーバユニット102は、DASHクライアント110に、MPDファイルまたは他のマニフェストファイルを提供し得る。ローカルサーバユニット102は、MPDファイル中のセグメントのための利用可能時間、並びに、セグメントが検索されることができるハイパーリンクを通知し得る。これらのハイパーリンクは、(例えば、IPv4に関する127.0.0.1などの)クライアントデバイス40に対応するローカルホストアドレスプレフィックス(localhost address prefix)を含み得る。このように、DASHクライアント110は、HTTP GETまたは部分的GET要求を使用して、ローカルサーバユニット102からセグメントを要求し得る。例えば、リンクhttp://127. 0. 0. 1/rep1/seg3からの利用可能なセグメントについて、DASHクライアント110は、http://127. 0. 0. 1/rep1/seg3を求める要求を含むHTTP GET要求を構築し得、その要求をローカルサーバユニット102にサブミットし得る。ローカルサーバユニット102は、このような要求に応答して、要求されたデータをキャッシュ104から検索し(retrieve requested data from cache 104)得、そのデータをDASHクライアント110に提供し得る。
[0072] DASHクライアント110は、本開示のネーミング規定(naming conventions)を使用して、プロキシサーバ102から(from)セグメントを要求するために、本開示の技法に従って構成され得る。同じように、DASHクライアント110は、プロキシサーバ102から受信したマニフェストファイルを使用してセグメントの名前を決定するように構成され得、ここで、マニフェストファイルは、下記でより詳細に説明されるように、例えば「@k」属性の形式で、フルセグメントごとに利用可能な「チャンク」の数をシグナリングし得る。同様に、プロキシサーバ102はまた、本開示の技法に従って構成され得る。
[0073] 例えば、DASHクライアント110とプロキシサーバ102とは、単純な(simple)$Number$テンプレートを使用してセグメントチャンクに名前を付ける(name)ように構成され得る。代替的に、DASHクライアント110とプロキシサーバ102とは、2つの部分を含み得る階層型ネーミング(またはアドレッシング)方式に従って、セグメントチャンクに名前を付けるように構成され得る。第1の部分は、対応するセグメントについての(for)フルセグメント番号、または対応するセグメントのタイミング情報に対応し得る。タイミング情報は、例えば、対応するセグメントがプレイされ始めるべき再生時間を示し得る。第2の部分は、特定のフルセグメントのチャンクのための通常の識別子に対応し得る。
[0074] 図3は、例示的なマルチメディアコンテンツの要素を図示する概念図である。マルチメディアコンテンツ120は、マルチメディアコンテンツ64(図1)、または記憶媒体62中に記憶された別のマルチメディアコンテンツに対応し得る。図3の例では、マルチメディアコンテンツ120は、メディアプレゼンテーション記述(MPD)122と複数の表現124A〜124N(表現124)とを含む。表現124Aは、オプションのヘッダデータ126およびセグメント128A〜128N(セグメント128)を含み、一方、表現124Nは、オプションのヘッダデータ130およびセグメント132A〜132N(セグメント132)を含む。文字Nは、便宜上、表現124の各々における最後の動画フラグメントを指定するために使用される。いくつかの例では、表現124間で異なる数の動画フラグメントが存在し得る。
[0075] MPD122は、表現124とは別個の(separate)データ構造を備え得る。MPD122は、図1のマニフェストファイル66に対応し得る。同様に、表現124は、図2の表現68に対応し得る。一般に、MPD122は、コーディングおよびレンダリング特性、適合セット、MPD122が対応するプロファイル、テキストタイプ情報、カメラアングル情報、レーティング情報、トリックモード情報(例えば、時間的サブシーケンス(temporal sub-sequences)を含む表現を示す情報)および/または(例えば、再生中のメディアコンテンツへの、目標とされる(targeted)通知の挿入のための)遠隔の期間(remote periods)を検索するための情報などの、表現124の特性を概して記述するデータを含み得る。
[0076] ヘッダデータ126は、存在するとき、セグメント128の特性、例えば、ランダムアクセスポイント(RAP、ストリームアクセスポイント(SAP)とも呼ばれる)の時間的ロケーション、セグメント128のうちのどれがランダムアクセスポイントを含むか、セグメント128内の(within)ランダムアクセスポイントに対する(to)バイトオフセット、セグメント128のユニフォームリソースロケータ(URL)、またはセグメント128の他の態様を記述し得る。ヘッダデータ130は、存在するとき、セグメント132のための同様の特性を記述し得る。加えてまたは代替として、このような特性は、MPD122内に完全に含まれ得る。
[0077] セグメント128、132は、1つまたは複数のコーディングビデオサンプル(coded video samples)を含み、それらの各々は、ビデオデータのフレームまたはスライスを含み得る。セグメント128のコーディングビデオサンプルの各々は、同様の特性、例えば、高さ、幅、および帯域幅要件を有し得る。このような特性は、MPD122のデータによって記述され得るが(though)、このようなデータは図3の例には例示されていない。MPD122は、本開示に説明される、シグナリングされる情報のうちの任意のものまたは全てを追加して、3GPP仕様書によって記述されるような特性を含み得る。
[0078] セグメント128、132の各々は、ユニークユニフォームリソースロケータ(URL)に関連付けられ得る。よって、セグメント128、132の各々は、DASHなどのストリーミングネットワークプロトコルを使用して、独立して検索可能であり得る。このように、クライアントデバイス40などの宛先デバイスは、セグメント128または132を検索するために、HTTP GET要求を使用し得る。いくつかの例では、クライアントデバイス40は、セグメント128または132の特定のバイト範囲を検索するために、HTTP部分的GET要求を使用し得る。
[0079] 本開示の技法に従って、MPD122は、特定のセグメントに利用可能なセグメントチャンクの数をシグナリングする属性を含み得る。例えば、下記でより詳細に論じられるように、MPD122は、「@k」要素を含み得る。MPD122は、セグメントチャンクをアドレスする(address)ために使用されるべきネーミング方式(またはアドレッシング方式)をさらにシグナリングし得る。このようなネーミング/アドレッシング方式は、下記でより詳細に論じられるように、通常の情報および/またはタイミング情報に基づき得る。
[0080] 図4は、例示的なビデオファイル150の要素を図示するブロック図であり、それは、図3のセグメント114、124のうちの1つなどの表現のセグメントに対応し得る。セグメント128、132の各々は、図4の例で図示されているデータの配列に実質的に一致するデータを含み得る。ビデオファイル150は、セグメントをカプセル化すると言うことができる(may be said to)。上述したように、ISOベースのメディアファイルフォーマットおよびその拡張に従ったビデオファイルは、「ボックス(boxes)」と呼ばれる一連のオブジェクトにデータを記憶する。図4の例では、ビデオファイル150は、ファイルタイプ(FTYP)ボックス152、動画(MOOV)ボックス154、セグメントインデックス(sidx)ボックス162、動画フラグメント(MOOF)ボックス164、および動画フラグメントランダムアクセス(MFRA)ボックス166を含む。図4は、ビデオファイルの例を表すが、他のメディアファイルは、ISOベースのメディアファイルフォーマットおよびその拡張に従った、ビデオファイル150のデータと同様に構造化された他のタイプのメディアデータ(例えば、オーディオデータ、タイムドテキストデータ、または同様のもの)を含み得ることが、理解されるべきである。
[0081] ファイルタイプ(FTYP)ボックス152は、概して、ビデオファイル150のためのファイルタイプを記述する。ファイルタイプボックス152は、ビデオファイル150のための最善の使用を記述する規格書(specification)を識別するデータを含み得る。ファイルタイプボックス152は、代替的に、MOOVボックス154、動画フラグメントボックス164、および/またはMFRAボックス166の前に配置され得る。
[0082] いくつかの例では、ビデオファイル150などのセグメントは、FTYPボックス152の前にMPD更新ボックス(図示せず)を含み得る。MPD更新ボックスは、ビデオファイル150を含む表現に対応するMPDが更新されるべきであることを示す情報を、MPDを更新するための情報とともに含み得る。例えば、MPD更新ボックスは、MPDを更新するために使用されることになるリソースのためのURIまたはURLを提供し得る。別の例として、MPD更新ボックスは、MPDを更新するためのデータを含み得る。いくつかの例では、MPD更新ボックスは、ビデオファイル150のセグメントタイプ(STYP)ボックス(図示されない)の直後に続き(immediately follow)得、ここで、STYPボックスは、ビデオファイル150のためのセグメントタイプを定義し得る。図7は、下記でより詳細に説明されるように、MPD更新ボックスに関する追加の情報を提供する。
[0083] MOOVボックス154は、図4の例では、動画ヘッダ(MVHD)ボックス156、トラック(TRAK)ボックス158、および1つまたは複数の動画拡張(MVEX)ボックス160を含む。概して、MVHDボックス156は、ビデオファイル150の一般的な特性を記述し得る。例えば、MVHDボックス156は、ビデオファイル150が最初に(originally)生成されたのはいつか、ビデオファイル150が最後に修正されたのはいつか、ビデオファイル150のための時間スケール、ビデオファイル150のための再生の持続時間、またはビデオファイル150を一般的に記述する他のデータ、を記述するデータを含み得る。
[0084] TRAKボックス158は、ビデオファイル150のトラックのためのデータを含み得る。TRAKボックス158は、TRAKボックス158に対応するトラックの特性を記述するトラックヘッダ(TKHD)ボックスを含み得る。いくつかの例では、TRAKボックス158は、コーディングされたビデオピクチャを含み得、一方、他の例では、トラックのコーディングされたビデオピクチャは、動画フラグメント164に含まれ得、それは、TRAKボックス158および/またはsidxボックス162のデータによって参照され得る。
[0085] いくつかの例では、ビデオファイル150は、1より多くのトラックを含み得る。従って、MOOVボックス154は、ビデオファイル150中のトラックの数(the number of tracks)に等しいいくつかのTRAKボックス(a number of TRAK boxes)を含み得る。TRAKボックス158は、ビデオファイル150の対応するトラックの特性を記述し得る。例えば、TRAKボックス158は、対応するトラックのための時間的および/または空間的情報を記述し得る。MOOVボックス154のTRAKボックス158と同様なTRAKボックスは、カプセル化ユニット30(図3)がビデオファイル150などのビデオファイル中にパラメータセットトラックを含めるとき、パラメータセットトラックの特性を記述し得る。カプセル化ユニット30は、パラメータセットトラックを記述するTRAKボックス内でパラメータセットトラック中のシーケンスレベルSEIメッセージの存在をシグナリングし得る。
[0086] MVEXボックス160は、例えば、もしあれば(if any)、MOOVボックス154内に含まれるビデオデータに加えて、ビデオファイル150が動画フラグメント164を含むことをシグナリングするために、対応する動画フラグメント164の特性を記述し得る。ビデオデータをストリーミングすることのコンテキストでは(In the context of streaming video data)、コーディングされたビデオピクチャは、MOOVボックス154ではなく動画フラグメント164に含まれ得る。従って、全てのコーディングされたビデオサンプルは、MOOVボックス154ではなく、動画フラグメント164に含まれ得る。
[0087] MOOVボックス154は、ビデオファイル150中の動画フラグメント164の数に等しいいくつかのMVEXボックス160を含み得る。MVEXボックス160の各々は、動画フラグメント164のうちの対応するもの(corresponding one)の特性を記述し得る。例えば、各MVEXボックスは、動画フラグメント164のうちの対応するもののための時間的な持続時間を記述する動画拡張ヘッダボックス(MEHD)ボックスを含み得る。
[0088] 上記のように、カプセル化ユニット30は、実際のコーディングされたビデオデータを含まないビデオサンプル中にシーケンスデータセットを記憶し得る。ビデオサンプルは概して、アクセスニットに対応し得、それは、特定の時間インスタンスにおけるコーディングされたピクチャの表現である。AVCのコンテキストでは、コーディングされたピクチャは、アクセスユニットの全てのピクセルを構築する(construct)ための情報を含む1つまたは複数のVCL NALユニットおよびSEIメッセージなどの他の関連した非VCL NALユニットを含む。従って、カプセル化ユニット30は、動画フラグメント164のうちの1つに、シーケンスレベルSEIメッセージを含み得る、シーケンスデータセットを含め得る。カプセル化ユニット30はさらに、動画フラグメント164のうちの1つに対応するMVEXボックス160のうちの1つ内で、動画フラグメント164のうちの1つに存在するものとして、シーケンスレベルSEIメッセージおよび/またはシーケンスデータセットの存在をシグナリングし得る。
[0089] SIDXボックス162は、ビデオファイル150のオプションの要素である。すなわち、3GPPファイルフォーマット、または他のこのようなファイルフォーマットに準拠するビデオファイルは、必ずしもSIDXボックス162を含まない。3GPPファイルフォーマットの例に従って、SIDXボックスは、セグメント(例えば、ビデオファイル150内に含まれるセグメント)のサブセグメント(a sub-segment of a segment(e.g., a segment contained within video file 150))を識別するために使用され得る。3GPPファイルフォーマットは、サブセグメントを「動画フラグメントボックスの後に続き(follow)、および同じトラックについての情報を含む次の動画フラグメントボックスの前に来(precede)なければならない、動画フラグメントボックスによって参照されるデータを含むメディアデータボックスおよび対応するメディアデータボックス(1つまたは複数)(Media Data box(es)))を有する(with)1つまたは複数の連続する動画フラグメントボックスの自己充足型セット(a self-contained set)」と定義する。3GPPファイルフォーマットはまた、SIDXボックスが、「ボックスによって記録される(documented)(サブ)セグメントのサブセグメント(subsegments)への参照のシーケンスを含む」ことを示す。参照されるサブセグメントは、プレゼンテーション時間において連続的である。同様に、セグメントインデックスボックス(Segment Index box)によって参照される(referred to by)バイトは、常に(always)セグメント内で連続的である。参照されるサイズは、参照される素材におけるバイトの数のカウントを与える。
[0090] SIDXボックス162は概して、ビデオファイル150中に含まれるセグメントの1つまたは複数のサブセグメントを表す(representative of)情報を提供する。例えば、このような情報は、サブセグメントが開始および/または終了する再生時間、サブセグメントのためのバイトオフセット、サブセグメントがストリームアクセスポイント(SAP)を含む(例えば、ストリームアクセスポイント(SAP)から始まる)か否か、SAPのためのタイプ(例えば、SAPが瞬時デコーダリフレッシュ(IDR:instantaneous decoder refresh)ピクチャ、クリーンランダムアクセス(CRA)ピクチャ、ブロークンリンクアクセス(BLA)ピクチャ、または同様のものであるか)、サブセグメント中の(再生時間および/またはバイトオフセットの観点からの)SAPの位置、および同様のもの、を含み得る。
[0091] 動画フラグメント164は、1つまたは複数のコーディングされたビデオピクチャを含み得る。いくつかの例では、動画フラグメント164は、1つまたは複数のピクチャのグループ(GOP:group of pictures)を含み得、それらの各々は、いくつかの(a number of)コーディングされたビデオピクチャ、例えばフレームまたはピクチャを含み得る。加えて、上述したように、動画フラグメント164は、いくつかの例では、シーケンスデータセットを含み得る。動画フラグメント164の各々は、動画フラグメントヘッダボックス(MFHD、図4には図示されない)を含み得る。MFHDボックスは、動画フラグメントのためのシーケンス番号などの対応する動画フラグメントの特性を記述し得る。動画フラグメント164は、ビデオファイル150に(in)シーケンス番号の順番で含まれ得る。
[0092] MFRAボックス166は、ビデオファイル150の動画フラグメント164内のランダムアクセスポイントを記述し得る。これは、ビデオファイル150によってカプセル化されたセグメント内の特定の時間的ロケーション(すなわち、再生時間)への探索(seeks)を実施すること(performing)等の、トリックモードを行うことを支援し得る。MFRAボックス166は、概して、オプションであり、いくつかの例では、ビデオファイルに含まれる必要はない。同様に、クライアントデバイス40などのクライアントデバイスは、必ずしも、ビデオファイル150のビデオデータを正確に復号および表示するためにMFRAボックス166を参照する必要はない。MFRAボックス166は、ビデオファイル150のトラックの数と等しいか、またはいくつかの例では、ビデオファイル150のメディアトラック(例えば、非ヒントトラック)の数と等しい、いくつかのトラックフラグメントランダムアクセス(TFRA)ボックス(図示せず)を含み得る。
[0093] いくつかの例では、動画フラグメント164は、IDRピクチャなどの1つまたは複数のストリームアクセスポイント(SAP)を含み得る。同様に、MFRAボックス166は、SAPのビデオファイル150内のロケーションのインジケーションを提供し得る。従って、ビデオファイル150の時間的サブシーケンスは、ビデオファイル150のSAPから形成され得る。時間的サブシーケンスはまた、SAPに従属する(depend from)Bフレームおよび/またはPフレームなどの他のピクチャを含み得る。時間的サブシーケンスのフレームおよび/またはスライスは、サブシーケンスの他のフレーム/スライスに依存する時間的サブシーケンスのフレーム/スライスが適切に復号されることができるように、セグメント内に配列され得る。例えば、データの階層配列において、他のデータに関する予測のために使用されるデータもまた、時間的サブシーケンスに含まれ得る。
[0094] 図5は、通常のセグメント提供(regular segment offerings)と、より短い複数のセグメントを用いた提供(offerings with shorter segments)との例を図示する概念図である。すなわち、図5は、通常のセグメント提供180例と、より短い複数のセグメントを用いた提供190(offering with shorter segments 190)例とを図示する。図5に示されるように、より短いセグメントは、再生開始遅延を低減し得る。
[0095] 通常のセグメント提供180のような通常のDASH提供では、セグメント182A、182B、182Cは、切り替え(switching)、ランダムアクセス、および同じ粒度での配信(delivery)を許可するように提供される。セグメント182A、182B、182Cは、ビットストリーム切り替え、例えば、表現間の切り替えを可能にする、それぞれのランダムアクセスポイント(RAP)184A、184B、184Cを含む。コンテンツ生成器(例えば、図1のコンテンツ準備デバイス20)が、パブリッシング(publishing)の前にフルセグメント182A、182B、182Cを生成することが必要であり得るとき(As)、セグメント182A、182B、182Cのためのセグメント利用可能開始時間(SAST)は、セグメント182A、182B、182Cのフルのそれぞれのもの(full respective one)が生成された時点で(once)のみ、利用可能である。より短い複数のセグメントを用いた提供190は、セグメント192A〜192Kを含んでおり、セグメント192A、192Gのみが、それぞれのRAP194A、194Bを含んでいる。このようなより短いセグメントを用いると、セグメント利用可能性がより早くなることができ、全体的な遅延が低減され得る。
[0096] しかしながら、通常のセグメント提供180およびより短い複数のセグメントを用いた提供190の両方について、SAST並びにセグメントアドレスURLは、コーディングにおける不要な制限または頻繁なMPD更新のないコンパクトな方法でMPDにおいてシグナリングされ、生成される必要がある。あるもの(One)は、より短い(smaller)セグメントのためのセグメントタイムラインを用いた明確な持続時間を使用し得る(下記の図6参照)が、これは、場合によっては(possibly)不明瞭なシグナリングおよび複雑なシグナリング、並びに(as well as)多くのMPD更新をもたらし得る。ビデオ中の予測チェーンのために、正確なプレゼンテーション持続時間(従って、アドレス)は決定されることができない(cannot)。
[0097] 図6は、通常のセグメント提供200と、より短い複数のセグメントを用いた提供210(offering with shorter segments 210)とを介して利用可能なセグメントのためのユニフォームリソースロケータ(URL)アドレスを図示する概念図である。この例では、通常のセグメント提供200は、セグメント202A、202B、202Cを含んでおり、各々がそれぞれのRAP204A、204B、204Cを含んでいる。より短い複数のセグメントを用いた提供210は、セグメント212A〜212Kを含んでおり、セグメント212Aと212Gのみが、それぞれ、RAP214A、214Bを含んでいる。
[0098] 図6に示されるように、より短いセグメント提供の使用は、より短いセグメントの間のプレゼンテーション持続時間を決定することを困難にし(make presentation durations for shorter segments difficult to determine)、従って、それらセグメントのためのURLアドレスもまた決定することが困難であり得る。従って、正確なセグメント持続時間を用いた$Time$アドレッシングは、現実的ではない可能性がある(may)。
[0099] 図7は、本開示の技法によってシグナリングされ得るデータの例示的なセットを図示する概念図である。図7は、例示的な通常のセグメント提供220と、複数のセグメントシーケンスおよび$Number$属性を用いた提供230とを図示する。通常のセグメント提供220は、セグメント222A、222B、222Cを含んでおり、各々が、それぞれのRAP224A、224B、224Cを含んでいる。この例では、複数のセグメントシーケンスおよび$Number$属性を用いた提供230は、セグメント232A〜232Pを含んでおり、セグメント232A、232G、232Lは、それぞれのRAP234A、234B、234Cを含んでいる。
[0100] 本開示の技法は、概して、セグメントシーケンスに含まれるセグメントの数を指定するメディアプレゼンテーション記述(MPD)ファイルなどのマニフェストファイルにおける属性をシグナリングすることを含む。例えば、MPDファイルに関して、「@k」属性は、MPDファイル中のセグメントタイムラインのS要素に追加され得る。
[0101] 図7の例で示されるように、属性は、複数のセグメントシーケンスおよび$Number$属性を用いた提供230のためにシグナリングされる。具体的には、図7における複数のセグメントシーケンスおよび$Number$属性を用いた提供230の例では、属性のセットが以下のようにシグナリングされる:media=“http://ab. com/$Time$_$SubNumber$. m4s”, S (t=1000; d=1000; k=6), S (t=2010; d=1000; k=5; r=1)
[0102] 図1のクライアントデバイス40は、図7に示されるように、$Number$テンプレートを使用することによって、単に(simply)セグメント番号を増加させ得る。すなわち、図1のクライアントデバイス40は、「1」ずつセグメント番号を増分すること(incrementing)によって、より短いセグメントの各々をアドレスし得る(例えば、HTTP GETまたは部分的GET要求などの要求において指定し得る)。図7の例では、例えば、通常のセグメント提供220のセグメント222Aは、より短い複数のセグメントを用いた提供230のセグメント232A〜232Fに対応し、通常のセグメント提供220のセグメント222Bは、より短い複数のセグメントを用いた提供230のセグメント232G〜232Kに対応し、通常のセグメント提供220のセグメント222Cは、より短い複数のセグメントを用いた提供230のセグメント232L〜232Pに対応する。
[0103] セグメント232A〜232Pは、増分ネーミング方式(incremental naming scheme)に従って名付けられ、ここで、この例では、セグメントの名前は、数に続く(a number followed by)「.m4s.」に対応する。例えば、セグメント232Aは、「2.m4s」と名付けられ、セグメント232Bは、「3.m4s」と名付けられ、以下同様に繰り返される(and so on)。図1のクライアントデバイス40(具体的には(in particular)、検索ユニット52)は、対応するセグメントの名前を使用して、セグメント232A〜232Pのうちの所望の1つ(desired one)のための識別子を指定し得る。例えば、セグメント232Aを検索するために、クライアントデバイス40は、URL「ab.com/2.m4s」を指定する要求をサーバデバイス60に送り得る。このセグメントネーミング方式(または、アドレッシング方式)は、ある(certain)使用ケースについては、セグメント番号が単に1ずつ増加するため、うまく機能する(works well)。よって、これは、例えば、ROUTE(Real-Time Object Delivery over Unidirectional Transport)を用いたATSC(Advanced Television Systems Committee)に関して有効になり得る。この方式はまた、DASHにおけるテンプレート方式(templating scheme)への更新を必要としない。
[0104] 他の使用ケースに関しては、このシンプルな数に基づくシグナリング(simple number based signaling)が、十分ではない可能性がある。その理由は、それが$Time$を用いて、または通常の提供が低レイテンシ提供とともに提供される使用ケースを用いて、機能しないからであり、セグメント番号が枝分かれ(diverge)するからである。これらの議論および$Time$に基づいて、$Number$および$Time$ベースのシグナリングの両方についての階層型ナンバリングが有益であり得る。
[0105] 図8は、本開示の技法に従った、セグメントのための階層型ナンバリングを使用するための技法の例を図示する。この例では、通常のセグメント提供240は、セグメント242A、242B、242Cを含んでおり、その各々がそれぞれのRAP244A、244B、244Cを含んでいる。複数のセグメントシーケンスを用いた提供250は、この例では、階層的に識別されたセグメント、すなわち、セグメント252A〜252Pを含んでおり、およびセグメント252A、252G、252Lは、それぞれのRAP254A、254B、254Cを含んでいる。
[0106] 図8の例では、より短いセグメント252A〜252Pは、階層型シグナリング方式を使用してアドレスされる。具体的には、図8の例では、通常のセグメント提供240のセグメント242Aは、複数のセグメントシーケンスを用いた提供250の(この例では、「2_1.m4s」〜「2_6.m4s」と名付けられた)セグメント252A〜252Fに対応し、通常の提供240のセグメント242Bは、複数のセグメントシーケンスを用いた提供250の(この例では、「3_1.m4s」〜「3_5.m4s」と名付けられた)セグメント252G〜252Kに対応し、通常の提供240のセグメント242Cは、複数のセグメントシーケンスを用いた提供250の(この例では、「4_1.m4s」〜「4_5.m4s」と名付けられた)セグメント252L〜252Pに対応する。セグメント242A、242B、242Cは、この例では、それぞれ、「2.m4s」、「3.m4s」、「4.m4s」と名付けられている。このように、ネーミング方式は、セグメント252A〜252Pがセグメント242A〜242Cのうちの対応するものの名前を表す第1の部分と、セグメント242A〜242Cのうちの同じものに対応しているセグメントシーケンス内のセグメント252A〜252Pの相対的順序(relative order)を表す第2の部分と、の2部分形式で(in two-part form)名付けられるという点で、階層的であると言われることができる(can be said to)。
[0107] よって、通常のセグメント提供240のセグメント242A〜242Cの各々は、複数のセグメントシーケンスを用いた提供250のうちの1つの対応するセグメントシーケンス(a corresponding segment sequence)を有し得る。セグメント252A〜252Pは、「M_N.m4s」に続く(followed by)ベースURLを指定するURLを要求すること(例えば、HTTP GETまたは部分的GET要求を使用すること)によってアドレスされ得、ここで、「M」はセグメント242A〜242Cのうちの対応するものの名前を表し、「N」はセグメント242A〜242Cのうちの1つに対応するセグメントシーケンスにおけるセグメントの通常の識別子を表す。よって、セグメント252Jを検索するために、クライアントデバイス40は、セグメント252Jがセグメント242Bに対応し、およびセグメントシーケンス中の4番目のセグメントであることを決定し得る。従って、クライアントデバイス40は、セグメント252Jを検索するために「ab.com/3_4.m4s」を指定する要求を送り得る。
[0108] このように、階層型シグナリングは、シンプルな切り替えと同様に、単一のMPDにおける異なるサイズのセグメントの配置(deployment)を可能にし得る。このように、階層型シグナリングはまた、セグメントシーケンス中のセグメントのための持続時間の明確なシグナリングの必要性(need)を回避し得る。
[0109] 図9は、本開示の技法に従った、セグメントのための階層型ナンバリングを使用するための技法の別の例を図示する。この例では、セグメント番号によってセグメントをアドレスするのではなく、持続時間を表す情報によって、通常の提供のセグメントがアクセス可能となり得る。この例では、通常のセグメント提供260は、セグメント262A〜262Cを含んでおり、各々がそれぞれのRAP264A、264B、264Cを含んでいる。セグメント262A〜262Cは、以前のセグメント(earlier segments)の蓄積された持続時間に加えて、それぞれのセグメントの持続時間に従って名付けられる。この例では、セグメント262Aは1010の持続時間を有し、セグメント262Bは1000の持続時間を有する。さらに、セグメント262Aは、全体で(total)1000のセグメント持続時間を有する1つまたは複数のセグメントの後に続く(follows)。よって、セグメント262Aは「1000.m4s」と名付けられ、セグメント262Bは「2010.m4s」(1000+1010)と名付けられ、セグメント262Cは「3010.m4s」(2010+1000)と名付けられる。
[0110] 複数のセグメントシーケンスを用いた提供270は、より短い複数のセグメント272A〜272Pを含む。しかしながら、この例では、セグメント272A〜272Pは、持続時間コンポーネントとサブナンバコンポーネントとによってアドレス可能であり得る。持続時間コンポーネントは、上述したように、通常のセグメント提供260中のセグメント262A〜262Cのうちの対応するものの名前を表す。サブナンバコンポーネントは、複数のセグメントシーケンスを用いた提供270のセグメント272A〜272Pのうちの1つについてのセグメント番号を表し得る。
[0111] よって、図9の例では、通常のセグメント提供260の(「1000.m4s」と名付けられた)セグメント262Aは、複数のセグメントシーケンスを用いた提供270の(それぞれ、「1000_1.m4s」〜「1000_6.m4s」と名付けられた)セグメント272A〜272Fに対応し、通常のセグメント提供260の(「2010. m4s」と名付けられた)セグメント262Bは、複数のセグメントシーケンスを用いた提供270の(それぞれ、「2010_1.m4s」〜「2010_5.m4s」と名付けられた)セグメント272G〜272Kに対応し、通常のセグメント提供260の(「3010.m4s」と名付けられた)セグメント262Cは、複数のセグメントシーケンスを用いた提供270の(それぞれ、「3010_1.m4s」〜「3010_5.m4s」と名付けられた)セグメント272L〜272Pに対応する。
[0112] 従って、クライアントデバイス40は、上述したように、これらのセグメントの蓄積された持続時間に基づいて、セグメント262A〜262Cの名前を決定し得る。さらに、クライアントデバイス40は、セグメント262A〜262Cのうちの対応するものについての名前を決定することによって、セグメント272A〜272Pの名前/識別子を決定し得、そして(then)、セグメント262A〜262Cのうちの1つに対応するセグメントのシーケンス内でセグメント272A〜272Pのうちの1つの位置を決定する。例えば、図1のクライアントデバイス40は、通常のセグメント提供260中の(in)対応するセグメント262Bの名前が「2010.m4s」であると決定することによって、およびセグメント272Jがセグメント262Bに対応するセグメントシーケンス中の4番目のセグメントであると決定することによって、セグメント272Jに関する名前が「2010_4.m4s」であると決定し得る。従って、要求セグメント272Jのために、クライアントデバイス40は、セグメント272JのURLとして「ab.com/2010_4.m4s」を指定する部分的GET要求またはHTTP GETをサブミットし得る。
[0113] 図9の例の1つの潜在的なアドバンテージは、同じ表現中の次のセグメントシーケンス(例えば、セグメント262Bに対応するセグメントシーケンス)の最も早いプレゼンテーション時間が、1つの(a)セグメントシーケンス中の全てのメディアセグメントの結合(concatenation)の結果として生じるセグメントの持続時間と、現在のセグメントシーケンス(1000)の最も早いプレゼンテーションとの和(sum)から導出され得る、ということである。ISO BMFFのケースでは、これは、セグメントシーケンス中のセグメントのトラックラン(track runs)を合計することによって達成され得る。
[0114] このように、クライアントデバイス40は、第1の部分と第2の部分とを含む2部分形式ネーミング方式を使用して、より短いセグメント提供の複数のセグメントをアドレスし得る。第1の部分は、(図8の例による(per))通常のセグメント提供240の対応するセグメント242A〜242Cのセグメント番号または、(図9の例による)通常のセグメント提供260の対応するセグメント262A〜262Cについてのタイミング情報を表し得る。タイミング情報は、例えば、対応するセグメントがプレイされ始めるべき再生時間を示し得る。第2の部分は、(図8および図9の例による)シンプルな数的増分(numeric increments)を表し得る。具体的には、2部分ネーミング方式は、それぞれ、「$Number$. $Chunk$」および「$Time$. $Chunk$」と呼ばれ得る。代替的に、2部分ネーミング方式は、それぞれ、「$Number$. $ChunkNumber$」と「$Time$. $ChunkNumber$」と呼ばれ得る。
[0115] 代替的に、(図1のクライアントデバイス40、サーバデバイス60、およびコンテンツ準備デバイス20などの)DASHを使用するデバイスは、より短いセグメント提供において利用可能なセグメント「チャンク」の数を示す属性(例えば、属性「@k」)などの、本明細書で説明されるデータを含むマニフェストファイルを処理(例えば、形成または解析および解釈)するために、並びに、上記で言及したマニフェストファイルの属性を使用して本明細書で説明される技法の任意のものまたは全てに従ってセグメントをアドレスするために、本開示の技法を使用するように構成され得る。
[0116] ISO/IEC 23009−1で規定されるようなDASHの例に関して、DASHのセクション5.3.9.4.4は、下記に示すように修正され得、ここで、開始および終了(begin and end)の追加記号「||+>||」と「||+<||」とによって囲まれた文(text surrounded)は追加を表現しており、開始および終了の削除記号「−>」と「||−<||」とによって囲まれた文は削除を表現しており、他の部分は変わっていない。
[0117] 5.3.9.4.4 テンプレートベースのセグメントURL構築
[0118] SegmentTemplate@media属性、SegmentTemplate@index属性、SegmentTemplate@initialization属性、およびSegmentTemplate@bitstreamSwitching属性は、表16中にリストされた識別子のうちの1つまたは複数を含み得る文字列を各々含む。
[0119] 各URLでは、表16の(from)識別子は、表16に定義された置換パラメータ(substitution parameter)によって置き換えられるべきである。識別子マッチングは、大文字と小文字を区別する(case-sensitive)。有効な識別子を含まない(do not enclose)アンエスケープされた$シンボルをURLが含む場合、URL形成の結果は、定義されない。この場合、DASHクライアントは表現要素を含む全体を無視し、およびMPDの処理があたかも(as if)この表現要素が存在しなかったかのように継続することが期待される。識別子のフォーマットもまた、表16で指定されている。
[0120] 各識別子は、このプロトタイプの後に(following)、IEEE 1003.1−2008[10]で定義されるように、printfフォーマットタグにアラインされた追加のフォーマットタグを(with)、「$」で囲まれた文字内に(within)付加され得る:
[0121] %0 [width]d
[0122] 幅パラメータ(width parameter)は、表示される(to be printed)文字の最小数を提供する符号なし整数(unsigned integer)である。表示される値がこの数よりも小さい(shorter)場合、結果はゼロで埋められる(padded)ものとする(shall)。値は、結果が大きくなったとしても切り捨てされない。
[0123] メディアプレゼンテーションは、置換プロセスの適用が有効なセグメントURLをもたらすように作成される(authored)ものとする。
[0124] 識別子外の文字列は、RFC 3986に従ってURL内で許可される文字のみを含むものとする。
[0125] 5.3.9.6の変更 セグメントタイムライン(SISSI変更||+>||6||+<|| ||−>|| 5||−<||)
[0126] 5.3.9.6.1 概要
[0127] SegmentTimeline要素は、表現中の各セグメントに関する(@timescale属性に基づくユニット中の)プレゼンテーション持続時間および最も早いプレゼンテーション時間を表現する。この使用は、@duration属性を提供することに代わるものであり、3つの追加の特徴を提供する。
・任意のセグメント持続時間の規格(specification)
・持続時間がセグメントのプレゼンテーション持続時間を表す1つのメディアストリームの間の(for)明確な(accurate)セグメント持続時間の規格
・特定の表現中にセグメントデータが存在しないメディアプレゼンテーションタイムラインの不連続性のシグナリング
・セグメントシーケンスをシグナリングするための能力。さらなる詳細については、5.3.9.6.4を参照。セグメントシーケンスは、使用中のプロファイルによって明示的に許可されている場合にのみ、使用されるものとする。
[0128] 簡潔化のために、この要素のシンタックスは、一定の持続時間を有するセグメントのシーケンスを表現するためのランレングス圧縮を含む。
[0129] SegmentTimeline(以下、原文にて太字の箇所に下線を付す)要素は、要素のリストを含むものとし、その各々が同一のMPD持続時間の連続的なセグメントのシーケンスを説明する。要素は、MPD持続時間を指定する必須@d属性、任意の(optional)@t時間属性、および、1をマイナスした、同一のMPD持続時間を用いた(with)連続的なセグメントの数を指定するオプションの@r繰り返しカウント属性を含む。@presentationTimeOffsetの値をマイナスした(minus)@t属性の値は、系列内の(in the series)第1のセグメントのMPD開始時間を指定する。
[0130] 存在しない時(when)、@r属性は、ゼロのデフォルト値(すなわち、系列(series)内の単一のセグメント)を有する。例えば、3の繰り返しカウント(a repeat count of three)は、各々が同じMPD持続時間を有する4つの連続的なセグメントがあることを意味する。要素の@r属性の値は、次の要素の@tまで、あるいは、それが、期間の終了またはMPDの次の更新まで、SegmentTimeline要素中の最後の要素である場合、@dに示された持続時間が繰り返すことが約束されていることを示す負の値に設定され得、すなわち、それは、全期間の間(for)@duration属性と同じ方法で処理される。任意の@d値は、MPD@maxSegmentDurationの値を超えないものとする。
[0131] SegmentTimeline要素内の要素のテキストの順序は、対応するメディアセグメントのナンバリング(ひいては(and thus)、時間)順序と一致する(match)ものとする。
[0132] SegmentTemplateが使用中であり、および$Time$識別子がSegmentTemplate@media中に存在するとき:
・セグメントインデックス(「sidx」)ボックスが存在する場合、SegmentTimelineの値は、各メディアセグメントの正確なタイミングを記述するものとする。具体的には、これらの値は、セグメントインデックス(「sidx」)ボックスに提供される情報を反映する(reflect)ものとする。すなわち: ・@timescaleの値は、第1の「sidx」ボックス中のタイムスケールフィールドの値と一致するものとする
・S@tの値は、Sで説明されるメディアセグメントの第1の「sidx」ボックス中のearliest_presentation_timeの値と一致するものとする
・S@dの値は、Sで説明されるメディアセグメントの第1の「sidx」ボックス中の全てのSubsegment_durationフィールドの値の和と一致するものとする
・セグメントインデックス(「sidx」)ボックスが存在しない場合、最も早いプレゼンテーション時間の導出は、メディア内部データに基づくものとする。詳細は、使用中のセグメントフォーマットに従い(depend on)、セグメントフォーマットにおけるさらなる制限が適用され得る
・メディアセグメントのためのセグメントURLは、SegmentTimelineから取得された最も早いプレゼンテーション時間によって、$Time$識別子を置き換えることによって取得される
[0133] ノート:同じ表現における次のメディアセグメントの最も早いプレゼンテーション時間が、例えば、セグメントインデックスの使用によって、実際のメディアセグメントから導出され得るとき(As)、セグメントURLは、セグメントタイムラインへの更新を含む更新されたMPDを読み取ることなく(without reading of)生成され得る。
[0134] セグメントタイムラインについての属性および要素のセマンティクスが、表17の5.3.9.6.2に提供されている。セグメントタイムラインのXMLシンタックスが、5.3.9.6.3で提供されている。
[0135] 5.3.9.6.2 セマンティクス
[0136] 5.3.9.6.3 XMLシンタックス
||+>||5.3.9.6.4 セグメントシーケンス
[0137] セグメントタイムライン中のセグメントシーケンスは、SegmentTimeline要素中に@k属性を含むことで(with)シグナリングされ得る。@kは、下記の要件の全てが満たされる場合にのみ、存在するものとする。
・関連付けられた表現についてのアドレッシング方式が、5.3.9.6.5で定義されるように、$Number$または階層テンプレート化およびサブナンバリングのいずれかでセグメントテンプレートを使用している
・プロファイルがセグメントシーケンスの使用を明示的に可能にする。
[0138] @kが存在しおよび1よりも大きい場合、それは、@dによって記述されたシーケンスがタイミングは正確だが、@kセグメントを含むことを指定する。
[0139] セグメントのMPD持続時間は、@kの値で除算された@dの値として決定され、MPD開始時間、ひいては(and therefore)セグメント利用可能開始時間を決定する。セグメントのMPD持続時間がセグメントのメディア持続時間と正確に一致する必要はないことに留意されたい。
[0140] セグメントシーケンス中の全てのセグメントの連結は、@dの値に従って正確なセグメント持続時間を有するものとする。
[0141] 5.3.9.6.5 階層型テンプレートおよびサブナンバリング
[0142] セグメントテンプレートが$SubNumber$値を含み、およびセグメントシーケンスを有する(with)セグメントタイムラインシグナリングが使用される場合、そして(then)
・$Time$が存在する場合、$Time$は、セグメントシーケンス中の全てのセグメントについてのセグメントシーケンスの最も早いプレゼンテーション時間と置き換えられる
・$Number$が存在する場合、$Number$は、セグメントシーケンスの数と、すなわち、セグメントタイムライン中の全てのセグメントシーケンスが単一のセグメントとして扱われるかのように(as)その数と置き換えられる
・両方のケースでは、$SubNumber$は、セグメントシーケンスのセグメント番号を、シーケンス中の第1のセグメントの数である1と置き換えられる
[0143] ノート:同じ表現中の次のセグメントシーケンスの最も早いプレゼンテーション時間は、現在のセグメントシーケンスの最も早いプレゼンテーションと、セグメントシーケンス中の全てのメディアセグメントの連結から生じるセグメントの持続時間との和から導出され得る。ISO BMFFのケースでは、これは、セグメントシーケンス中のセグメントのトラックランを合計することによって達成され得る。||+<||
[0144] 図10は、本開示の技法によるメディアデータを搬送(送信および受信)する例示的な方法を図示するフローチャートである。図10の方法は、図1のサーバデバイス60とクライアントデバイス40とによって行われているように表現されている。しかしながら、追加のまたは代替のデバイスがこれをまたは同様の方法を行うように構成され得ることが理解されるだろう。例えば、コンテンツ準備デバイス20は、サーバデバイス60と連動して、またはそれに変わって、サーバデバイスに起因する(attributed)方法の一部分(portions)を行い得る。
[0145] 始めに、サーバデバイス60は、メディアデータのセグメントのチャンクの利用可能性を決定し得る(300)。例えば、サーバデバイス60は、メディアデータの表現または適用セットの複数のセグメントの各々の(for)チャンクの数(a number of chunks)を決定し得る。サーバデバイス60は次に、メディアプレゼンテーション記述(MPD)などのマニフェストファイル中の利用可能データを指定し得る(302)。例えば、上述したように、サーバデバイス60は、マニフェストファイルのセグメントタイムライン要素中のS要素の「@k」要素をシグナリングし得る。@k要素は、セグメントシーケンスに含まれるセグメントの数を表現し得る。このようなセグメントの数は、1つのセグメントのチャンクとして認識され(be understood)得、セグメントシーケンスは、対応するセグメントのためのチャンクのシーケンスに対応し得る。サーバデバイス60は次に、例えば、マニフェストファイルのためのクライアントデバイス40からの要求に応答して、クライアントデバイス40にマニフェストファイルを送り得る(304)。
[0146] クライアントデバイス40は、マニフェストファイルを受信し得る(306)。クライアントデバイス40は次に、マニフェストファイルからのチャンク利用可能データを決定し得る(308)。例えば、クライアントデバイス40の検索ユニット52(図1)は、セグメント中のチャンクの数を決定するために、マニフェストファイルから「@k」要素を抽出し得る。クライアントデバイス40は次に、チャンクのための識別子を、その塊(hunks)のための利用可能データを使用して決定し得る(310)。例えば、図8および図9に関して上述したように、クライアントデバイス40は、(上述したように、通常の識別子または持続時間に基づく識別子であり得る)通常のセグメント提供において対応するセグメントの名前を表現する第1の部分と、(同様に、上述したように)セグメントに対応するチャンクのシーケンス中のチャンクの通常の識別子を表現する第2の部分と、のチャンクのための2つの部分の識別子を決定し得る。
[0147] 検索されるべきチャンクのための識別子を決定した後、クライアントデバイス40は、チャンクのための識別子を指定する要求を送り得る(312)。例えば、クライアントデバイス40は、要求のためのURLの一部として、チャンクのための識別子を指定するHTTP GETまたは部分的GET要求を構築し得る。クライアントデバイス40は次に、サーバデバイス60にその要求を送り得る。
[0148] サーバデバイス60は次に、その要求を受信し得る(314)。サーバデバイス60は、例えば、チャンクのためのURLなどの、要求において指定されるような識別子を使用して、要求されたチャンクを決定し得る(316)。サーバデバイス60は次に、クライアントデバイス40に、要求されたチャンクを送り得る(318)。
[0149] クライアントデバイス40は次に、チャンクを順に(in turn)受信し得(320)、チャンクのメディアデータを復号および提示し得る(322)。例えば、(代替的に、ファイル処理または構文解析ユニットと呼ばれ得る)非カプセル化ユニット50は、符号化されたメディアデータをチャンクから抽出し、メディアデータのタイプに依存して、符号化メディアデータをオーディオデコーダ46またはビデオデコーダ48に送り得る。オーディオデコーダ46/ビデオデコーダ48は、メディアデータを復号し、復号されたメディアデータを、プレゼンテーションのためにオーディオ出力42/ビデオ出力44に送り得る。
[0150] このように、図10の方法は、メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、セグメントに利用可能なチャンクの数を示すデータを使用して、チャンクのうちの1つのための識別子を決定することと、サーバデバイスに、チャンクのうちの1つのための識別子を指定する要求を送ることと、を含む方法の例を表す。
[0151] 1つまたは複数の例では、記述された機能は、ハードウェア、ソフトウェア、ファームウェア、またはこれらのあらゆる組み合わせで実装され得る。ソフトウェアにおいて実装される場合、それら機能は、コンピュータ可読媒体上で1つまたは複数の命令またはコードとして記憶あるいは送信され、ハードウェアベースの処理ユニットによって実行され得る。コンピュータ可読媒体は、例えば、通信プロトコルに従って、ある場所から別の場所へのコンピュータプログラムの移送を容易にする任意の媒体を含む通信媒体またはデータ記憶媒体などの有形の媒体に対応するコンピュータ可読記憶媒体を含み得る。このように、コンピュータ可読媒体は概して、(1)非一時的な有形のコンピュータ可読記憶媒体または(2)信号または搬送波などの通信媒体に対応し得る。データ記憶媒体は、本開示で説明される技法の実装のための命令、コード、および/またはデータ構造を検索するために、1つまたは複数のコンピュータあるいは1つまたは複数のプロセッサによってアクセスされ得る任意の利用可能な媒体であり得る。コンピュータプログラム製品は、コンピュータ可読媒体を含み得る。
[0152] 限定ではなく例として、このようなコンピュータ可読記憶媒体は、RAM、ROM、EEPROM(登録商標)、CD−ROMまたは他の光ディスク記憶装置、磁気ディスク記憶装置、または他の磁気記憶デバイス、フラッシュメモリ、あるいは、データ構造または命令の形態で所望されるプログラムコードを記憶するために使用されることができ、かつコンピュータによってアクセスされることができる任意の他の媒体を備えることができる。また、いかなる接続もコンピュータ可読媒体と適切に呼ばれる。例えば、命令が、同軸ケーブル、光ファイバーケーブル、ツイストペア、デジタル加入者回線(DSL)、または赤外線、無線、およびマイクロ波などのワイヤレス技術を使用して、ウェブサイト、サーバ、または他のリモートソースから送信される場合、同軸ケーブル、光ファイバーケーブル、ツイストペア、DSL、または赤外線、無線、およびマイクロ波などのワイヤレス技術は、媒体の定義に含まれる。しかしながら、コンピュータ可読記憶媒体およびデータ記憶媒体が、接続、搬送波、信号、または他の一時的な媒体を含むのではなく、代わりに、非一時的な有形の記憶媒体を対象としていることは理解されるべきである。本明細書で使用される場合、ディスク(disk)およびディスク(disc)は、コンパクトディスク(CD)、レーザーディスク(登録商標)、光ディスク、デジタル多用途ディスク(DVD)、フロッピー(登録商標)ディスク(登録商標)およびブルーレイ(登録商標)ディスクを含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザで光学的に再生する。上記の組み合わせもまたコンピュータ可読媒体の範囲内に含めるべきである。
[0153] 命令は、1つまたは複数のデジタルシグナルプロセッサ(DSP)、汎用マイクロプロセッサ、特定用途向け集積回路(ASIC)、フィールドプログラマブルロジックアレイ(FPGA)、あるいは他の同等な集積またはディスクリートロジック回路などの1つまたは複数のプロセッサによって実行され得る。従って、本明細書で使用されるとき、「プロセッサ」という用語は、任意の前述の構造または本明細書で説明された技法の実装に適した任意の他の構造を指し得る。加えて、いくつかの態様では、本明細書で説明された機能性は、符号化および復号のために構成された専用ハードウェアおよび/またはソフトウェアモジュール内に提供され得るか、複合コーデックに組み込まれ得る。また、本技法は、1つまたは複数の回路または論理要素で十分に実装され得る。
[0154] この開示の技法は、ワイヤレスハンドセット、集積回路(IC)またはICのセット(例えば、チップセット)を含む、幅広い多様なデバイスまたは装置内に実装され得る。本開示では、開示される技法を実行するように構成されたデバイスの機能的態様を強調するために、様々なコンポーネントまたはユニットが説明されたが、それらは、必ずしも異なるハードウェアユニットによる実現を必要としない。むしろ、上述したように、様々なユニットは、コーデックハードウェアユニットへと組み合わせられるか、適切なソフトウェアおよび/またはファームウェアと併せて、上述したような1つまたは複数のプロセッサを含む、相互動作するハードウェアユニットの集合によって提供され得る。
[0155] 様々な例が説明された。これらの例および他の例は、以下の請求項の範囲内にある。
[0155] 様々な例が説明された。これらの例および他の例は、以下の請求項の範囲内にある。
以下に本願の出願当初の特許請求の範囲に記載された発明を付記する。
[C1]
メディアデータを検索する方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送ることと
を備える、方法。
[C2]
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、C1に記載の方法。
[C3]
前記チャンクのうちの前記1つのための前記識別子を決定することは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを備える、C1に記載の方法。
[C4]
前記チャンクのうちの前記1つのための前記識別子を決定することは、階層型アドレッシング方式に従って前記識別子を決定することを備える、C1に記載の方法。
[C5]
前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、C4に記載の方法。
[C6]
前記第1の部分は、前記セグメントのための識別番号を指定する、C5に記載の方法。
[C7]
前記第1の部分は、前記セグメントのためのタイミング情報を指定する、C5に記載の方法。
[C8]
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、C7に記載の方法。
[C9]
前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、C5に記載の方法。
[C10]
前記要求を送ることは、HTTP GET要求またはHTTP部分的GET要求のうちの1つを送ることを備える、C1に記載の方法。
[C11]
前記セグメントチャンクは、それぞれのURLを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記方法は、URLテンプレートに従って前記URLを決定することをさらに備える、C1に記載の方法。
[C12]
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、C1に記載の方法。
[C13]
前記識別子を決定することは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを備える、C1に記載の方法。
[C14]
前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することをさらに備える、C1に記載の方法。
[C15]
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
をさらに備える、C1に記載の方法。
[C16]
メディアデータを検索するためのデバイスであって、前記デバイスは、回路に実装され、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送ることと
を行うように構成された1つまたは複数のプロセッサを備える、デバイス。
[C17]
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、C16に記載のデバイス。
[C18]
前記1つまたは複数のプロセッサは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することのように構成される、C16に記載のデバイス。
[C19]
前記1つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記識別子を決定するように構成される、C16に記載のデバイス。
[C20]
前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、C19に記載のデバイス。
[C21]
前記第1の部分は、前記セグメントのための識別番号を指定する、C20に記載のデバイス。
[C22]
前記第1の部分は、前記セグメントのためのタイミング情報を指定する、C20に記載のデバイス。
[C23]
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、C22に記載のデバイス。
[C24]
前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、C20に記載のデバイス。
[C25]
前記要求を送るために、前記1つまたは複数のプロセッサは、HTTP GET要求またはHTTP部分的GET要求のうちの1つを送るように構成される、C16に記載のデバイス。
[C26]
前記セグメントチャンクは、それぞれのURLを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記1つまたは複数のプロセッサは、URLテンプレートに従って前記URLを決定するようにさらに構成される、C16に記載のデバイス。
[C27]
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、C16に記載のデバイス。
[C28]
前記1つまたは複数のプロセッサは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定するように構成される、C16に記載のデバイス。
[C29]
前記1つまたは複数のプロセッサは、前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定するようにさらに構成される、C16に記載のデバイス。
[C30]
前記1つまたは複数のプロセッサは、
前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を行うようにさらに構成される、C16に記載のデバイス。
[C31]
メディアデータを検索するためのデバイスであって、前記デバイスは、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信するための手段と、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定するための手段と、
サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送るための手段と
を備える、デバイス。
[C32]
命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定することと、
サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送ることと
を行わせる、コンピュータ可読記憶媒体。
[C33]
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、C32に記載のコンピュータ可読記憶媒体。
[C34]
前記チャンクのうちの前記1つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、C32に記載のコンピュータ可読記憶媒体。
[C35]
前記チャンクのうちの前記1つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、階層型アドレッシング方式に従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、C32に記載のコンピュータ可読記憶媒体。
[C36]
前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、C35に記載のコンピュータ可読記憶媒体。
[C37]
前記第1の部分は、前記セグメントのための識別番号を指定する、C36に記載のコンピュータ可読記憶媒体。
[C38]
前記第1の部分は、前記セグメントのためのタイミング情報を指定する、C36に記載のコンピュータ可読記憶媒体。
[C39]
前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、C38に記載のコンピュータ可読記憶媒体。
[C40]
前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、C36に記載のコンピュータ可読記憶媒体。
[C41]
前記要求を送ることを前記プロセッサに行わせる前記命令は、HTTP GET要求またはHTTP部分的GET要求のうちの1つを送ることを前記プロセッサに行わせる命令を備える、C32に記載のコンピュータ可読記憶媒体。
[C42]
前記セグメントチャンクは、それぞれのURLを有する複数のセグメントを備えるセグメントシーケンスとして提供され、URLテンプレートに従って前記URLを決定することを前記プロセッサに行わせる命令をさらに備える、C32に記載のコンピュータ可読記憶媒体。
[C43]
前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、C32に記載のコンピュータ可読記憶媒体。
[C44]
前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを前記プロセッサに行わせる命令を備える、C32に記載のコンピュータ可読記憶媒体。
[C45]
前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することを前記プロセッサに行わせる命令をさらに備える、C32に記載のコンピュータ可読記憶媒体。
[C46]
前記マニフェストファイルからの前記セグメントのための持続時間値を決定することと、
前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
を前記プロセッサに行わせる命令をさらに備える、C32に記載のコンピュータ可読記憶媒体。
[C47]
メディアデータを送る方法であって、前記方法は、
メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの1つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された1つを送ることと、
を備える、方法。
[C48]
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、C47に記載の方法。
[C49]
前記チャンクのうちの前記1つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための$Number$テンプレートを定義するデータを送ることをさらに備える、C47に記載の方法。
[C50]
階層型アドレッシング方式に従って前記チャンクのうちの前記1つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、階層型アドレッシング方式を定義するデータを送ることをさらに備える、C47に記載の方法。
[C51]
前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、C50に記載の方法。
[C52]
前記第1の部分は、前記セグメントのための識別番号を指定する、C51に記載の方法。
[C53]
前記第1の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、C51に記載の方法。
[C54]
前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、C51に記載の方法。
[C55]
メディアデータを送るためのサーバデバイスであって、前記サーバデバイスは、
マニフェストファイルと前記メディアデータとを記憶するように構成されたメモリと、
回路に実装され、
前記メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むように前記マニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
クライアントデバイスに前記マニフェストファイルを送ることと、
前記クライアントデバイスから、前記チャンクのうちの1つのための識別子を指定する要求を受信することと、
前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された1つを送ることと、
を行うように構成された1つまたは複数のプロセッサと
を備える、サーバデバイス。
[C56]
セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、C55に記載のデバイス。
[C57]
前記1つまたは複数のプロセッサは、前記チャンクのうちの前記1つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための前記$Number$テンプレートを定義するデータを送るように構成される、C55に記載のデバイス。
[C58]
前記1つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記チャンクのうちの前記1つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記階層型アドレッシング方式を定義するデータを送るように構成される、C55に記載のデバイス。
[C59]
前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、C58に記載のデバイス。
[C60]
前記第1の部分は、前記セグメントのための識別番号を指定する、C59に記載のデバイス。
[C61]
前記第1の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、C59に記載のデバイス。
[C62]
前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、C59に記載のデバイス。

Claims (62)

  1. メディアデータを検索する方法であって、前記方法は、
    メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
    前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定することと、
    サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送ることと
    を備える、方法。
  2. セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、請求項1に記載の方法。
  3. 前記チャンクのうちの前記1つのための前記識別子を決定することは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを備える、請求項1に記載の方法。
  4. 前記チャンクのうちの前記1つのための前記識別子を決定することは、階層型アドレッシング方式に従って前記識別子を決定することを備える、請求項1に記載の方法。
  5. 前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、請求項4に記載の方法。
  6. 前記第1の部分は、前記セグメントのための識別番号を指定する、請求項5に記載の方法。
  7. 前記第1の部分は、前記セグメントのためのタイミング情報を指定する、請求項5に記載の方法。
  8. 前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項7に記載の方法。
  9. 前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、請求項5に記載の方法。
  10. 前記要求を送ることは、HTTP GET要求またはHTTP部分的GET要求のうちの1つを送ることを備える、請求項1に記載の方法。
  11. 前記セグメントチャンクは、それぞれのURLを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記方法は、URLテンプレートに従って前記URLを決定することをさらに備える、請求項1に記載の方法。
  12. 前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項1に記載の方法。
  13. 前記識別子を決定することは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを備える、請求項1に記載の方法。
  14. 前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することをさらに備える、請求項1に記載の方法。
  15. 前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
    前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
    をさらに備える、請求項1に記載の方法。
  16. メディアデータを検索するためのデバイスであって、前記デバイスは、回路に実装され、
    メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
    前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定することと、
    サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送ることと
    を行うように構成された1つまたは複数のプロセッサを備える、デバイス。
  17. セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、請求項16に記載のデバイス。
  18. 前記1つまたは複数のプロセッサは、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することのように構成される、請求項16に記載のデバイス。
  19. 前記1つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記識別子を決定するように構成される、請求項16に記載のデバイス。
  20. 前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、請求項19に記載のデバイス。
  21. 前記第1の部分は、前記セグメントのための識別番号を指定する、請求項20に記載のデバイス。
  22. 前記第1の部分は、前記セグメントのためのタイミング情報を指定する、請求項20に記載のデバイス。
  23. 前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項22に記載のデバイス。
  24. 前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、請求項20に記載のデバイス。
  25. 前記要求を送るために、前記1つまたは複数のプロセッサは、HTTP GET要求またはHTTP部分的GET要求のうちの1つを送るように構成される、請求項16に記載のデバイス。
  26. 前記セグメントチャンクは、それぞれのURLを有する複数のセグメントを備えるセグメントシーケンスとして提供され、前記1つまたは複数のプロセッサは、URLテンプレートに従って前記URLを決定するようにさらに構成される、請求項16に記載のデバイス。
  27. 前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項16に記載のデバイス。
  28. 前記1つまたは複数のプロセッサは、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定するように構成される、請求項16に記載のデバイス。
  29. 前記1つまたは複数のプロセッサは、前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定するようにさらに構成される、請求項16に記載のデバイス。
  30. 前記1つまたは複数のプロセッサは、
    前記マニフェストファイルから前記セグメントのための持続時間値を決定することと、
    前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
    を行うようにさらに構成される、請求項16に記載のデバイス。
  31. メディアデータを検索するためのデバイスであって、前記デバイスは、
    メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信するための手段と、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
    前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定するための手段と、
    サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送るための手段と
    を備える、デバイス。
  32. 命令を記憶するコンピュータ可読記憶媒体であって、前記命令は、実行されると、プロセッサに、
    メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを受信することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
    前記セグメントに利用可能なチャンクの前記数を示す前記データを使用して、前記チャンクのうちの1つのための識別子を決定することと、
    サーバデバイスに、前記チャンクのうちの前記1つのための前記識別子を指定する要求を送ることと
    を行わせる、コンピュータ可読記憶媒体。
  33. セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、請求項32に記載のコンピュータ可読記憶媒体。
  34. 前記チャンクのうちの前記1つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための$Number$テンプレートに従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項32に記載のコンピュータ可読記憶媒体。
  35. 前記チャンクのうちの前記1つのための前記識別子を決定することを前記プロセッサに行わせる前記命令は、階層型アドレッシング方式に従って前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項32に記載のコンピュータ可読記憶媒体。
  36. 前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、請求項35に記載のコンピュータ可読記憶媒体。
  37. 前記第1の部分は、前記セグメントのための識別番号を指定する、請求項36に記載のコンピュータ可読記憶媒体。
  38. 前記第1の部分は、前記セグメントのためのタイミング情報を指定する、請求項36に記載のコンピュータ可読記憶媒体。
  39. 前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項38に記載のコンピュータ可読記憶媒体。
  40. 前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、請求項36に記載のコンピュータ可読記憶媒体。
  41. 前記要求を送ることを前記プロセッサに行わせる前記命令は、HTTP GET要求またはHTTP部分的GET要求のうちの1つを送ることを前記プロセッサに行わせる命令を備える、請求項32に記載のコンピュータ可読記憶媒体。
  42. 前記セグメントチャンクは、それぞれのURLを有する複数のセグメントを備えるセグメントシーケンスとして提供され、URLテンプレートに従って前記URLを決定することを前記プロセッサに行わせる命令をさらに備える、請求項32に記載のコンピュータ可読記憶媒体。
  43. 前記マニフェストファイルは、前記セグメントチャンクのための正確なセグメント持続時間を表現しない、請求項32に記載のコンピュータ可読記憶媒体。
  44. 前記識別子を決定することを前記プロセッサに行わせる前記命令は、前記セグメントチャンクのための持続時間を決定することなく、前記識別子を決定することを前記プロセッサに行わせる命令を備える、請求項32に記載のコンピュータ可読記憶媒体。
  45. 前記セグメントのための開始時間、前記セグメントの持続時間、およびセグメントチャンクの前記数を示す前記マニフェストファイルのデータを使用して、前記セグメントチャンクのためのセグメント利用可能開始時間を決定することを前記プロセッサに行わせる命令をさらに備える、請求項32に記載のコンピュータ可読記憶媒体。
  46. 前記マニフェストファイルからの前記セグメントのための持続時間値を決定することと、
    前記セグメントチャンクのための持続時間値を決定するために、前記持続時間値をセグメントチャンクの前記数で除算することと、
    を前記プロセッサに行わせる命令をさらに備える、請求項32に記載のコンピュータ可読記憶媒体。
  47. メディアデータを送る方法であって、前記方法は、
    メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むマニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
    クライアントデバイスに前記マニフェストファイルを送ることと、
    前記クライアントデバイスから、前記チャンクのうちの1つのための識別子を指定する要求を受信することと、
    前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された1つを送ることと、
    を備える、方法。
  48. セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、請求項47に記載の方法。
  49. 前記チャンクのうちの前記1つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための$Number$テンプレートを定義するデータを送ることをさらに備える、請求項47に記載の方法。
  50. 階層型アドレッシング方式に従って前記チャンクのうちの前記1つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、階層型アドレッシング方式を定義するデータを送ることをさらに備える、請求項47に記載の方法。
  51. 前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、請求項50に記載の方法。
  52. 前記第1の部分は、前記セグメントのための識別番号を指定する、請求項51に記載の方法。
  53. 前記第1の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項51に記載の方法。
  54. 前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、請求項51に記載の方法。
  55. メディアデータを送るためのサーバデバイスであって、前記サーバデバイスは、
    マニフェストファイルと前記メディアデータとを記憶するように構成されたメモリと、
    回路に実装され、
    前記メディアデータの表現のセグメントに利用可能なセグメントチャンクの数を示すデータを含むように前記マニフェストファイルを生成することと、前記セグメントは、ユニークユニフォームリソースロケータ(URL)を有する独立して検索可能なメディアファイルを備える、
    クライアントデバイスに前記マニフェストファイルを送ることと、
    前記クライアントデバイスから、前記チャンクのうちの1つのための識別子を指定する要求を受信することと、
    前記要求に応答して、前記クライアントデバイスに、前記識別子によって示される前記チャンクのうちの前記要求された1つを送ることと、
    を行うように構成された1つまたは複数のプロセッサと
    を備える、サーバデバイス。
  56. セグメントチャンクの前記数を示す前記データは、メディアプレゼンテーション記述(MPD)のSegmentTimeline要素のS要素に含まれる@k属性を備える、請求項55に記載のデバイス。
  57. 前記1つまたは複数のプロセッサは、前記チャンクのうちの前記1つのための前記識別子を決定するために$Number$テンプレートを使用することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記セグメントチャンクのための前記$Number$テンプレートを定義するデータを送るように構成される、請求項55に記載のデバイス。
  58. 前記1つまたは複数のプロセッサは、階層型アドレッシング方式に従って前記チャンクのうちの前記1つのための前記識別子を決定することを前記クライアントデバイスに行わせるように、前記クライアントデバイスに、前記階層型アドレッシング方式を定義するデータを送るように構成される、請求項55に記載のデバイス。
  59. 前記階層型アドレッシング方式は、前記識別子のための第1の部分と第2の部分とを指定する、請求項58に記載のデバイス。
  60. 前記第1の部分は、前記セグメントのための識別番号を指定する、請求項59に記載のデバイス。
  61. 前記第1の部分は、前記セグメントのためのタイミング情報を指定し、前記タイミング情報は、前記セグメントがプレイされ始めるべき再生時間を示す、請求項59に記載のデバイス。
  62. 前記第2の部分は、前記チャンクのうちの前記1つの通常の識別子を示す、請求項59に記載のデバイス。
JP2019504133A 2016-07-28 2017-07-28 メディアストリーミングのためのセグメントチャンクの検索およびアクセス Active JP7142626B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201662368099P 2016-07-28 2016-07-28
US62/368,099 2016-07-28
US15/661,789 US11617019B2 (en) 2016-07-28 2017-07-27 Retrieving and accessing segment chunks for media streaming
US15/661,789 2017-07-27
PCT/US2017/044353 WO2018022984A1 (en) 2016-07-28 2017-07-28 Retrieving and accessing segment chunks for media streaming

Publications (3)

Publication Number Publication Date
JP2019523600A true JP2019523600A (ja) 2019-08-22
JP2019523600A5 JP2019523600A5 (ja) 2020-08-13
JP7142626B2 JP7142626B2 (ja) 2022-09-27

Family

ID=61010779

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019504133A Active JP7142626B2 (ja) 2016-07-28 2017-07-28 メディアストリーミングのためのセグメントチャンクの検索およびアクセス

Country Status (10)

Country Link
US (2) US11617019B2 (ja)
EP (1) EP3491827B1 (ja)
JP (1) JP7142626B2 (ja)
KR (1) KR102454839B1 (ja)
CN (1) CN109479158B (ja)
BR (1) BR112019001323A2 (ja)
CA (1) CA3029026A1 (ja)
ES (1) ES2854936T3 (ja)
TW (1) TWI780063B (ja)
WO (1) WO2018022984A1 (ja)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022526162A (ja) * 2020-01-07 2022-05-23 テンセント・アメリカ・エルエルシー セッションベースdash動作のためのパターン指定
JP7483919B2 (ja) 2021-01-05 2024-05-15 テンセント・アメリカ・エルエルシー Httpによる動的適応ストリーミングのための方法及び装置

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
TWI599218B (zh) * 2016-07-29 2017-09-11 元智大學 即時影音傳輸系統
GB201721847D0 (en) * 2017-12-22 2018-02-07 Telecom Paris Tech Priority map for media files
US20210021659A1 (en) * 2018-04-06 2021-01-21 Sony Corporation Delivery apparatus, delivery method, and program
US11146852B2 (en) * 2018-05-11 2021-10-12 Qualcomm Incorporated Signaling missing sections of media data for network streaming in a segment
US10674166B2 (en) 2018-08-22 2020-06-02 Purdue Research Foundation Method and system for scalable video streaming
US10893303B1 (en) 2019-01-31 2021-01-12 Amazon Technologies, Inc. Streaming chunked media segments
US11063997B1 (en) * 2019-03-28 2021-07-13 Amazon Technologies, Inc. Higher order manifest data compression
US10893310B1 (en) * 2019-05-31 2021-01-12 Amazon Technologies, Inc. Managing playback bitrate selection
GB2586442B (en) * 2019-06-26 2024-03-27 Univ Dublin City A method and system for encoding and decoding to enable adaptive delivery of mulsemedia streams
US11509949B2 (en) * 2019-09-13 2022-11-22 Disney Enterprises, Inc. Packager for segmenter fluidity
US11310303B2 (en) * 2019-10-01 2022-04-19 Tencent America LLC Methods and apparatuses for dynamic adaptive streaming over HTTP
US20210306703A1 (en) * 2020-03-25 2021-09-30 Qualcomm Incorporated Determination of availability of chunks of data for network streaming media data
US11463746B2 (en) 2021-02-12 2022-10-04 Netflix, Inc. Techniques for composite media storage and retrieval
DE102021006419A1 (de) 2021-12-30 2023-07-06 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung eingetragener Verein Streaming-Techniken

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014529970A (ja) * 2011-08-31 2014-11-13 クゥアルコム・インコーポレイテッドQualcomm Incorporated 適応httpストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法
WO2015115171A1 (ja) * 2014-01-31 2015-08-06 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US20150286369A1 (en) * 2014-04-07 2015-10-08 The Directv Group, Inc. Method and system for transferring the display of content from a first device to a second device

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8434135B2 (en) 2010-06-11 2013-04-30 Microsoft Corporation Creating and launching a web application with credentials
US8849950B2 (en) * 2011-04-07 2014-09-30 Qualcomm Incorporated Network streaming of video data using byte range requests
US9357275B2 (en) 2011-09-06 2016-05-31 Qualcomm Incorporated Network streaming of coded video data
CA2869311C (en) 2012-04-26 2018-02-13 Michael G. Luby Enhanced block-request streaming system for handling low-latency streaming
BR122015005210A2 (pt) * 2012-06-28 2019-08-20 Ericsson Ab Método e sistema para inserção de anúncio em entrega de mídia ao vivo over the top
US9294531B2 (en) * 2012-07-12 2016-03-22 Futurewei Technologies, Inc. Signaling and processing content with variable bitrates for adaptive streaming
US9584573B2 (en) * 2012-08-29 2017-02-28 Ericsson Ab Streaming policy management system and method
EP2908535A4 (en) * 2012-10-09 2016-07-06 Sharp Kk Content transfer device, content playback device, content distribution system, method for controlling a content transfer device, method for controlling a content playback device, control program and recording medium
US20140282792A1 (en) * 2013-03-15 2014-09-18 Cygnus Broadband, Inc. Video streaming with buffer occupancy prediction based quality adaptation
US9710469B2 (en) * 2013-03-15 2017-07-18 Comcast Cable Communications, Llc Efficient data distribution to multiple devices
CN105532013B (zh) * 2013-07-12 2018-12-28 佳能株式会社 利用推送消息控制的自适应数据流传输方法
US9584577B2 (en) * 2014-04-03 2017-02-28 Cisco Technology, Inc. Method for enabling use of HLS as a common intermediate format
US9930427B2 (en) * 2015-12-21 2018-03-27 Comcast Cable Communications Management, Llc Providing advanced playback and control functionality to video client

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014529970A (ja) * 2011-08-31 2014-11-13 クゥアルコム・インコーポレイテッドQualcomm Incorporated 適応httpストリーミングのための表示の改善された切り替えを提供する切替シグナリング方法
WO2015115171A1 (ja) * 2014-01-31 2015-08-06 ソニー株式会社 送信装置、送信方法、受信装置および受信方法
US20150286369A1 (en) * 2014-04-07 2015-10-08 The Directv Group, Inc. Method and system for transferring the display of content from a first device to a second device

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2022526162A (ja) * 2020-01-07 2022-05-23 テンセント・アメリカ・エルエルシー セッションベースdash動作のためのパターン指定
JP7190589B2 (ja) 2020-01-07 2022-12-15 テンセント・アメリカ・エルエルシー セッションベースdash動作のためのパターン指定
JP7483919B2 (ja) 2021-01-05 2024-05-15 テンセント・アメリカ・エルエルシー Httpによる動的適応ストリーミングのための方法及び装置

Also Published As

Publication number Publication date
US11617019B2 (en) 2023-03-28
US20180035176A1 (en) 2018-02-01
KR20190031490A (ko) 2019-03-26
CN109479158A (zh) 2019-03-15
TWI780063B (zh) 2022-10-11
TW201806397A (zh) 2018-02-16
EP3491827A1 (en) 2019-06-05
CA3029026A1 (en) 2018-02-01
KR102454839B1 (ko) 2022-10-13
BR112019001323A2 (pt) 2019-04-30
CN109479158B (zh) 2021-06-18
WO2018022984A1 (en) 2018-02-01
EP3491827B1 (en) 2020-11-18
ES2854936T3 (es) 2021-09-23
JP7142626B2 (ja) 2022-09-27
US20230283863A1 (en) 2023-09-07

Similar Documents

Publication Publication Date Title
JP7142626B2 (ja) メディアストリーミングのためのセグメントチャンクの検索およびアクセス
CN110447234B (zh) 用于处理媒体数据及产生位流的方法、装置及存储媒体
US20160337424A1 (en) Transferring media data using a websocket subprotocol
CN112154672B (zh) 一种检索媒体数据的方法、设备及可读存储介质
JP6903688B2 (ja) サンプルエントリーおよびランダムアクセス
JP2017528022A (ja) ネットワークを介して交換されたファイルのためのエラー処理
KR102549656B1 (ko) 미디어 데이터 스트리밍을 위한 sei 트랙들의 시스템 레벨 시그널링
JP2019520742A (ja) サンプルエントリーおよびランダムアクセス
US11184665B2 (en) Initialization set for network streaming of media data
US20210306703A1 (en) Determination of availability of chunks of data for network streaming media data
US20210344992A1 (en) Calculating start time availability for streamed media data

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190409

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20200701

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20200701

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20210622

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20210706

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20211005

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220301

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220412

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

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20220913

R150 Certificate of patent or registration of utility model

Ref document number: 7142626

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150