JP2018519694A - Ｄａｓｈオーバーブロードキャストをサポートするためのさらなるデバイスタイミング調整および方法 - Google Patents

Ｄａｓｈオーバーブロードキャストをサポートするためのさらなるデバイスタイミング調整および方法 Download PDF

Info

Publication number
JP2018519694A
JP2018519694A JP2017554447A JP2017554447A JP2018519694A JP 2018519694 A JP2018519694 A JP 2018519694A JP 2017554447 A JP2017554447 A JP 2017554447A JP 2017554447 A JP2017554447 A JP 2017554447A JP 2018519694 A JP2018519694 A JP 2018519694A
Authority
JP
Japan
Prior art keywords
segment
start time
client
receiver device
mpd
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.)
Pending
Application number
JP2017554447A
Other languages
English (en)
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 JP2018519694A publication Critical patent/JP2018519694A/ja
Pending legal-status Critical Current

Links

Classifications

    • 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
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/28—Flow control; Congestion control in relation to timing considerations
    • H04L47/283—Flow control; Congestion control in relation to timing considerations in response to processing delays, e.g. caused by jitter or round trip time [RTT]
    • 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/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
    • 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/756—Media network packet handling adapting media to device capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/80—Responding to QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/62—Establishing a time schedule for servicing the requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/28—Timers or timing mechanisms used in protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/40—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass for recovering from a failure of a protocol instance or entity, e.g. service redundancy protocols, protocol state redundancy or protocol service redirection
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2402—Monitoring of the downstream path of the transmission network, e.g. bandwidth available
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2407—Monitoring of transmitted content, e.g. distribution time, number of downloads
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/23—Processing of content or additional data; Elementary server operations; Server middleware
    • H04N21/24—Monitoring of processes or resources, e.g. monitoring of server load, available bandwidth, upstream requests
    • H04N21/2408—Monitoring of the upstream path of the transmission network, e.g. client requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/20—Servers specifically adapted for the distribution of content, e.g. VOD servers; Operations thereof
    • H04N21/25—Management operations performed by the server for facilitating the content distribution or administrating data related to end-users or client devices, e.g. end-user or client device authentication, learning user preferences for recommending movies
    • H04N21/262—Content 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/26258—Content 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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/40—Client devices specifically adapted for the reception of or interaction with content, e.g. set-top-box [STB]; Operations thereof
    • H04N21/43—Processing of content or additional data, e.g. demultiplexing additional data from a digital video stream; Elementary client operations, e.g. monitoring of home network or synchronising decoder's clock; Client middleware
    • H04N21/442—Monitoring of processes or resources, e.g. detecting the failure of a recording device, monitoring the downstream bandwidth, the number of times a movie has been viewed, the storage space available from the internal hard disk
    • H04N21/44209—Monitoring of downstream path of the transmission network originating from a server, e.g. bandwidth variations of a wireless network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/63—Control signaling related to video distribution between client, server and network components; Network processes for video distribution between server and clients or between remote clients, e.g. transmitting basic layer and enhancement layers over different transmission paths, setting up a peer-to-peer communication via Internet between remote STB's; Communication protocols; Addressing
    • H04N21/637—Control signals issued by the client directed to the server or network components
    • H04N21/6377—Control signals issued by the client directed to the server or network components directed to server
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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
    • 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 

Landscapes

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

Abstract

様々な実施形態のシステム、方法、およびデバイスは、受信機デバイスが修正されたセグメント利用可能時間を使用することを可能にする。様々な実施形態では、受信機デバイスは、セグメントがDASHクライアントに利用可能になるとき、実際の時間を考慮するために、メディアプレゼンテーション記述(MPD)など、セグメント利用可能性タイムライン内のセグメントに対する利用可能開始時間を修正することが可能にされ得る。

Description

関連出願
本出願は、2015年4月20日に出願した「Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast」という表題の米国仮特許出願第62/149,776号の優先権の利益を主張し、この仮特許出願の内容全体が参照によって本明細書に組み込まれる。
ハイパーテキスト転送プロトコル(HTTP)ストリーミングは現在、インターネットを通じてコンテンツを配信する最も一般的な方法である。生のイベントでは、コンテンツは、一定の持続時間のセグメントを通じて徐々に利用可能にされる。セグメントの利用可能性は、各々の連続するセグメントがHTTPサーバにおいていつ利用可能になるかを示す、タイムラインに従う。
動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH:Dynamic Adaptive Streaming Over Hypertext Transfer Protocol)は、HTTPストリーミングを実装する規格である。DASHは、メディアプレゼンテーション記述(MPD:Media Presentation Description)内でセグメントの利用可能性を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。
現在のシステムでは、MPDは、オーバージエア(OTA)配信を介して受信機デバイスに提供される。提供されたMPD内で、セグメント利用可能開始時間は、セグメントを生成するネットワーク側エンコーダのエンコーダ出力時間に対応し得る。セグメント利用可能開始時間はエンコーダ出力時間に対応し得るので、利用可能開始時間は、配信経路の遅延、受信機デバイスの処理遅延、または受信機デバイスのクロックドリフトのような、受信機デバイス上で実行されるDASHクライアントに対する実際のセグメントの利用可能性の差を考慮しないことがある。したがって、現在のMPD内で告知される利用可能開始時間は、セグメントがDASHクライアントに対して利用可能となる実際の時間に対応しないことがある。
様々な実施形態のシステム、方法、およびデバイスは、受信機デバイスが修正されたセグメント利用可能時間を使用することを可能にする。様々な実施形態では、受信機デバイスは、セグメントがDASHクライアントに利用可能になるとき、実際の時間を考慮するために、メディアプレゼンテーション記述(MPD)など、セグメント利用可能性タイムライン内のセグメントに対する利用可能開始時間を修正することが可能にされ得る。
いくつかの実施形態では、受信機デバイスのタイミングドリフトを考慮するための方法は、URLマッチングによってセグメントインデックスを決定するステップと、利用可能性タイムライン内のマッチング期間および表現結合に基づいて、セグメントの利用可能開始時間を決定するステップと、利用可能性タイムラインからセグメント持続時間を決定するステップと、セグメントに関する復号時間を決定するステップと、セグメントに関する復号時間からセグメントの利用可能開始時間を減じたものがセグメント持続時間の比率よりも大きいかどうかを決定するステップと、セグメントに関する復号時間からセグメントの利用可能開始時間を減じたものがセグメント持続時間の比率よりも大きいとの決定に応じて、利用可能開始時間の再計算をトリガするステップとを含み得る。
いくつかの実施形態では、受信機デバイスのタイミングドリフトを考慮するための方法は、URLマッチングによって、受信されたセグメントに関するセグメントインデックスを決定するステップと、受信されたセグメントから生じる利用可能開始時間の変更を決定するステップと、利用可能開始時間の変更がしきい値よりも大きいかどうかを決定するステップと、利用可能開始時間の変更がしきい値よりも大きいとの決定に応じて、利用可能開始時間再計算をトリガするステップとを含み得る。
さらなる実施形態は、上記で要約したいずれかの方法の動作を実行するように構成されたプロセッサを備えた受信機デバイスを含み得る。
本明細書に組み込まれ、本明細書の一部を構成する添付の図面は、本発明の例示的な実施形態を示し、上記の一般的な説明および以下の発明を実施するための形態とともに、本発明の特徴を説明するのに役立つ。
様々な実施形態とともに使用するのに好適なネットワークの通信システムブロック図である。 一実施形態による受信機デバイスのアーキテクチャを示すブロック図である。 一実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。 別の実施形態による、セグメント配信経路とMPDの配信調整との関係を示す図である。 一実施形態による、ネットワークの種々の部分における配信経路遅延間の関係を示す図である。 決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法を示すプロセスフロー図である。 決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、遅延調整メッセージを生成するための一実施形態の方法を示すプロセスフロー図である。 決定された第1のFDT受信時間に基づくベースURL変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法を示すプロセスフロー図である。 決定された第1のFDT受信時間に基づくベースURL変更に応じて、遅延調整メッセージを生成するための一実施形態の方法を示すプロセスフロー図である。 一実施形態による、利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す図である。 いずれかの決定されたFDT受信時間に基づいてユニキャストモードでセグメント利用可能開始時間を修正するための一実施形態の方法を示すプロセスフロー図である。 いずれかの決定されたFDT受信時間に基づいてユニキャストモードで遅延調整メッセージを生成するための一実施形態の方法を示すプロセスフロー図である。 一実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。 別の実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。 遅延調整メッセージに基づいて利用可能開始時間を調整するための一実施形態の方法を示すプロセスフロー図である。 MPD更新を処理するための一実施形態方法を示すプロセスフロー図である。 MPD更新を処理するための別の実施形態方法を示すプロセスフロー図である。 別の実施形態による、利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す図である。 受信機デバイスタイミングドリフトを考慮するための一実施形態の方法を示すプロセスフロー図である。 失敗したHTTP記録をマークするための一実施形態の方法を示すプロセスフロー図である。 受信機デバイスタイミングドリフトを考慮するための別の実施形態の方法を示すプロセスフロー図である。 受信機デバイスタイミングドリフトを考慮するための第3の実施形態の方法を示すプロセスフロー図である。 URLマッチングによってセグメントインデックスを決定するための一実施形態の方法を示すプロセスフロー図である。 一実施形態による例示的なMPDの要素のブロック図である。 一実施形態による例示的なMPDの要素のブロック図である。 一実施形態による例示的なMPDの要素のブロック図である。 一実施形態による例示的なMPDのXMLツリーのブロック図である。 一例よるセグメントの利用可能性タイムラインを示す図である。 一実施形態による単一のセグメント持続時間MPDの例示的なスキーマ部分を示す図である。 一実施形態による、MPDをクロールし、期間および表現結合(period and representation couples)内のURLをマッチさせる様々な結果を示すブロック図である。 一実施形態によるセグメントの利用可能性タイムラインを示す図である。 一実施形態による2セグメント持続時間MPDの例示的なスキーマ部分を示す図である。 別の実施形態による、MPDをクロールし、期間および表現結合内のURLをマッチさせる様々な結果を示すブロック図である。 URLマッチングによってセグメントインデックスを決定するための別の実施形態の方法を示すプロセスフロー図である。 一実施形態による反復セグメントの利用可能性タイムラインを示す図である。 URLマッチングに基づいて受信機デバイスタイミングドリフトを考慮するための一実施形態の方法を示すプロセスフロー図である。 URLマッチングに基づいて受信機デバイスタイミングドリフトを考慮するための別の実施形態の方法を示すプロセスフロー図である。 URLマッチングに基づいて受信機デバイスタイミングドリフトを考慮するための第3の実施形態の方法を示すプロセスフロー図である。 様々な実施形態とともに使用するのに好適な例示的なモバイルデバイスの構成要素図である。 様々な実施形態とともに使用するのに好適な例示的なサーバの構成要素図である。
添付の図面を参照して、様々な実施形態が詳細に説明される。可能な場合はいつでも、同じまた同様の部分を指すために、図面全体を通して同じ参照番号が使用される。具体的な例および実装形態への言及は説明のためであり、本発明の範囲または特許請求の範囲を限定するものではない。
様々な実施形態は、受信機デバイスが、受信機デバイス上で使用するために、データストリーム中のデータセグメントの利用可能性(「セグメント利用可能性」)の遅延を考慮することを可能にする。一実施形態では、受信機デバイスは、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤアプリケーションのためのセグメントを取り出す動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)クライアント)に対して利用可能になる実際の時間に基づいて修正されたメディアプレゼンテーション記述(MPD)の列挙を生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、ブロードキャストマルチメディアサービスセンター(BMSC)サーバからオーバージエア(OTA)で受信されるMPD)中の利用可能開始時間を調整することができる。様々な実施形態は、ネットワークおよび受信機デバイスのクロックが同期されているときまたは同期されていないときに、修正されたMPDが生成されることを可能にし得る。
「例示的な」という単語は、本明細書では、「例、実例、または例証として機能する」を意味するために使用される。「例示的な」として本明細書で説明するいかなる実装形態も、他の実装形態よりも好ましいか、または有利であると必ずしも解釈されるべきでない。
本明細書で使用される場合、「モバイルデバイス」および「受信機デバイス」という用語は、セルラー電話、スマートフォン、個人用マルチメディアプレーヤまたはモバイルマルチメディアプレーヤ、携帯情報端末(PDA)、ラップトップコンピュータ、タブレットコンピュータ、スマートブック、パームトップコンピュータ、ワイヤレス電子メール受信機、マルチメディアインターネット対応セルラー電話、ワイヤレスゲームコントローラ、スマートテレビジョン、セットトップボックス、デジタルビデオレコーダ(DVR)、および、MPDを受信しMPDをDASHクライアントに対して利用可能にするためのプログラム可能プロセッサとメモリと回路とを含む同様の個人用電子デバイスの、いずれか1つまたはすべてを指すように、本明細書において交換可能に使用される。
DASHはHTTPストリーミングを実装する規格である。DASHは、MPD内でセグメントの利用可能性を告知する。MPDは、セグメント、セグメントが利用可能である時間、およびセグメントのサイズを告知する、セグメント利用可能性タイムラインである。現在のシステムでは、MPDは、OTA配信を介して受信機デバイスに提供される。第3世代パートナーシッププロジェクト(3GPP)は、ロングタームエボリューション(LTE)(すなわち、発展型マルチメディアブロードキャストマルチキャストサービス(eMBMS:evolved Multimedia Broadcast Multicast Services))を通じたブロードキャスト使用してHTTPストリーミングを提供するために使用されるべき方法として、ダウンロード配信を通じたDASHを標準化した。
異なるアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルの様々な例、特に、DASHクライアント、マルチキャストサービスデバイスクライアント(MSDC)、MPD、eMBMS、およびHTTPについて本明細書で論じる。DASHクライアント、マルチキャストサービスデバイスクライアント、MPD、eMBMS、およびHTTPの議論は、様々な実施形態の態様をより良好に示すための例としてのみ与えられ、いかなる方法でも様々な実施形態を限定することは意図されない。他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、様々な実施形態とともに使用されてもよく、他のアプリケーション/クライアント、ミドルウェア、セグメント利用可能性タイムライン、無線技術、および転送プロトコルが、本発明の趣旨または範囲から逸脱することなく、様々な例において置換されてもよい。
一実施形態では、受信機デバイスは、受信機デバイス上のクライアントアプリケーションに対するセグメントの利用可能性の遅延を考慮するように、遅延調整値を決定することができる。一実施形態では、遅延調整値は遅延調整メッセージ内で提供され得る。遅延調整メッセージは、遅延調整値を含むファイルのような、遅延調整値のパラメータおよび/または指示であり得る。一実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションが、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいて修正されたMPDの列挙を生成するように、ネットワークから受信されるセグメント利用可能性タイムライン(たとえば、BMSCサーバからOTAで受信されるMPD)など、セグメント利用可能性を記述するマニフェストファイル内の利用可能開始時間を修正することを可能にし得る。様々な実施形態がセグメント利用可能性タイムラインおよび/またはMPDの点で論じられる場合があるが、セグメント利用可能性タイムラインおよび/またはMPDは、セグメント利用可能性を記述するマニフェストファイルの単なる例であり、本明細書で論じるセグメント利用可能性タイムラインおよび/またはMPDに関する様々な例において、セグメント利用可能性を記述するいずれのマニフェストファイルも置換され得る。様々な実施形態は、ネットワークおよび受信機デバイスのクロックが同期されているときまたは同期されていないときに、遅延調整メッセージおよび修正されたMPDが生成されることを可能にし得る。別の実施形態では、遅延調整メッセージは、受信機デバイス上のクライアントアプリケーションが、セグメント利用可能性タイムライン自体を修正することなく、受信されたセグメントが受信機デバイス上のアプリケーション/クライアント(たとえば、メディアプレーヤアプリケーションのためのセグメントを取り出すDASHクライアント)に対して利用可能になる実際の時間に基づいてセグメントに対するその要求のタイミングを調整することを可能にし得る。
様々な実施形態では、受信機デバイスプロセッサは、セグメントフラグメントが受信されるにつれて、セグメントフラグメントのセグメントインデックス番号またはベースユニフォームリソース識別子(URI)を監視し、連続的に受信されたセグメントのセグメントインデックス番号またはベースURIを互いと比較することができる。最近のセグメントフラグメントのセグメントインデックス番号またはベースURLが前のセグメントフラグメントのセグメントインデックス番号またはベースURIと異なる(たとえば、セグメントインデックス番号またはベースURIの変更が検出される)とき、最近のセグメントフラグメントは、タイムライン内の次のセグメントの第1のファイル配信オーバー単方向トランスポート(FLUTE:File Delivery Over Unidirectional Transport)ファイル配信テーブル(FDT)など、タイムライン内の次のセグメントの第1のパケットであり得る。受信機デバイスプロセッサ(たとえば、プロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、次のセグメントをベースセグメントとして識別することができ、第1のFDTなど、第1のパケットの到着時間を使用して、ライムライン内のベースセグメントの利用可能開始時間を修正し、修正された利用可能開始時間に基づいて、後続のセグメントに関するすべての後続の利用可能開始時間をシフトすることができる。このようにして、受信機デバイスプロセッサは、タイムライン内の利用可能開始時間(たとえば、MPD内のAST)を修正して、セグメントの実際の到着時間を考慮することができる。
様々な実施形態では、受信機デバイスプロセッサは、受信されたMPDをクロールし(たとえば、パースし)、すべての期間および表現ペアに対応するURLフォーマットを決定することができる。たとえば、URLフォーマットはフォーマット「XXX$number$YYY」であってよく、ここで、XXXはプレフィックスであり得、YYYはサフィックスであり得、$number$は、セグメントのインデックス番号(たとえば、DASH内のセグメント番号)であり得る。受信機デバイスプロセッサは、この情報を使用して、まず、受信されたセグメントのURLが特定の期間および表現ペアのセグメントURLフォーマットにマッチするかどうかを決定し、次いで、セグメント番号を決定することができる。受信機デバイスプロセッサは、セグメント番号がその期間および表現ペアに対応するセグメントをもたらすかどうかを決定することもでき、実際のセグメント番号を決定することができる。セグメント番号が決定されると、受信機デバイスプロセッサは、そのセグメント番号を前に検出されたセグメント番号と比較することができる。一実施形態では、URLフォーマットは番号ベースのURL方式であってよい。さらなる実施形態では、ベースURLは常に絶対URLであってよい。一実施形態では、利用可能時間計算に調整を加えることによって、baseURL@availabilityTimeOffsetがサポートされ得る。一実施形態では、URLフォーマットまたはURLテンプレートは、セグメント番号ベースではなく、時間ベースであり得る。たとえば、同じ時間持続時間に対応するオーディオセグメントおよびビデオセグメントは、テンプレート内に同じ$time$タグを有し得る。受信機デバイスプロセッサは、各着信セグメントの利用可能開始時間を決定し、各着信セグメントの利用可能開始時間の変更に基づいてベースセグメントを決定することができる。
様々な実施形態では、ベースセグメントの修正された利用可能開始時間は、第1のFDT到着時間+(セグメントごとのセグメントフラグメント(SF)数×マルチキャストチャネル(MCH)スケジューリング期間(MSP))+マージン(M)、または修正された利用可能開始時間=第1のFDT到着時間+(SF*MSP)+Mとして決定され得る。一実施形態では、MSPの値は、受信機デバイスに対して事前プロビジョニングされたデフォルト値であり得る。別の実施形態では、MSPは、セグメントを受信するための一時的モバイルグループ識別子(TMGI)に関連する可変値であり得る。マージン(M)は、受信機デバイスによる処理遅延を考慮するための追加のマージンであってよく、受信機デバイスのメモリ内で事前プロビジョニングされた値として構成され得る。一実施形態では、SFはセルセグメント持続時間/MSPに等しくてよい。SFは、エンコーダおよびブロードキャストシステムにおけるスケジューリング方法において生成されるセグメントサイズの可変性を考慮するために、乗法係数(たとえば、0.8、0.9、1.1、1.2など、1より小さいかまたは大きいが、値の点で0よりも大きい値)によって調整され得る。
様々な実施形態では、同じベアラ上で同時にブロードキャストされる、オーディオおよびビデオなどの複数の表現は、インデックス変更を識別して、セグメント利用可能開始時間を修正するための受信機デバイスプロセッサの能力に影響を与えない場合がある。いくつかの実施形態では、2つ以上の表現は、同じ開始インデックスおよび同じセグメント持続時間を有し得る。いくつかの実施形態では、2つ以上の表現は、異なる開始インデックスおよび/または異なるセグメント持続時間を有し得る。別個のオーディオ表現およびビデオ表現は、インデックス値を依然として含んでよく、2つのセグメントがオーディオおよび/またはビデオセグメントであるかどうかにかかわらず、受信機デバイスプロセッサは、次のセグメントのFDT到着時間を追跡するための指示として、インデックス値変更を処理することができる。
一実施形態では、受信機デバイスプロセッサは、セグメントフラグメントが受信されるにつれて、セグメントフラグメントのセグメント利用可能時間を監視し、連続的に受信されたセグメントのセグメント利用可能開始時間を互いと比較することができる。最近のセグメントフラグメントのセグメント利用可能開始時間が前のセグメントフラグメントのセグメント利用可能開始時間と異なるとき、最近のセグメントフラグメントは、タイムライン内の次のセグメントの第1のファイル配信オーバー単方向トランスポート(FLUTE)ファイル配信テーブル(FDT)であり得る。受信機デバイスプロセッサ(たとえば、プロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、次のセグメントをベースセグメントとして識別することができ、その第1のFDTの到着時間を使用して、ライムライン内のベースセグメントの利用可能開始時間を修正し、修正された利用可能開始時間に基づいて、後続のセグメントに関するすべての後続の利用可能開始時間をシフトすることができる。
一実施形態では、異なるブロードキャスト表現(たとえば、2sセグメント持続時間におけるオーディオおよび1sセグメント持続時間におけるビデオ)に対するセグメント持続時間が異なるとき、受信機デバイスプロセッサは、調整値を決定するためにのみビデオ表現を使用することができる。受信機デバイスプロセッサは、表現にわたってより高いセグメント持続時間を使用して、その利用可能性が整合され得、かつ同じ計算を適用することができるスーパーセグメントを決定することもできる。受信機デバイスプロセッサは、セグメント持続時間が互いの倍数であるときに調整値を決定するためのみビデオ表現を使用することができる。受信機デバイスプロセッサは、セグメント持続時間が互いの倍数でないとき、セグメント持続時間の最低共通倍数を使用することができる。
様々な実施形態では、受信機デバイスプロセッサが、ユニキャストフェッチがアクティブであると決定するとき、受信機デバイスプロセッサ(たとえば、プロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、受信機デバイスにおいて受信されたいずれかのセグメントのいずれかのFDTの受信時間を決定することができ、FDTの受信時間に基づいて、そのセグメントの利用可能開始時間を修正することができる。このようにして、次のセグメントが受信されることまたはセグメントインデックス変更を待たずに、MPD内の利用可能時間を速やかにシフトすることができ、より厳密なタイムラインを活用して、より早期にユニキャストを通してセグメント要求するためにユニキャストフェッチが使用されることを可能にし得る。セグメントを記述する第1のブロードキャストFDTに基づいて利用可能性タイムラインを設定することは、セグメントを記述するいずれかのFDTを使用して決定されたタイムラインよりもより厳密なタイムラインを確実にすることができる。たとえば、セグメントを記述する最後のFDTは、概算的に、そのセグメントを記述する第1のFDTよりも遅いセグメント持続時間であり得、セグメント利用可能開始時間を設定するためにそれを使用することは、同じ持続時間の分だけ、セグメントの利用可能性を遅延させ得る。したがって、FDTに遭遇するとすぐにMPDが利用可能にされ得、次のセグメントが受信されることまたはセグメントインデックス変更を待つよりも早期に開始するようにプレイアウトすることを可能にする。一実施形態では、第1の1つまたは複数のセグメントはユニキャストを通してフェッチされ得る。
DASH規格単位のメディアセグメントの利用可能時間は、MPDの利用可能開始時間(AST)(たとえば、MPD内で記述されるすべてのセグメントの利用可能性に関するアンカータイム(anchor time)を表すMPD要素「MPD@availabilityStartTime」内に示された時間)+含有期間のPeriodStart時間+メディアセグメントのMPD利用可能開始時間(AST)(たとえば、そのセグメント自体のAST)+セグメント持続時間の値として決定され得る。様々な実施形態では、識別されたベースセグメントのURIに基づいて、受信機デバイスプロセッサ(たとえば、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアント)は、MPD内のすべての残りのセグメントの対応する利用可能開始時間を決定することができる。一実施形態では、受信機デバイスプロセッサは、第1のFDT到着時間に基づいて決定されたベースセグメントの修正された利用可能開始時間に基づいて、MPDの利用可能開始時間(AST)を修正することができる。たとえば、MPDのASTは、ベースセグメントの期間((セグメント持続時間)×(セグメント数-開始セグメント数))内の修正された利用可能開始時間-PeriodStart時間-利用可能開始時間に等しくなるように修正され得る。様々な実施形態では、前のMPDと同じASTを有するMPD更新を受信するとすぐに、受信機デバイスプロセッサは、前のMPDに関して決定された、修正されたASTにマッチするように、MPD更新のASTを調整することができる。様々な実施形態では、前のMPDとは異なるASTを有するMPD更新を受信するとすぐに、受信機デバイスプロセッサは、第1のFDT到着時間に基づいて決定されたベースセグメントの修正された利用可能開始時間を使用して、MPD更新のASTを調整することができる。様々な実施形態では、異なるASTを有するMPD更新の受信は、新しい利用可能開始時間決定をトリガし得る。
別の実施形態では、受信機デバイスプロセッサは、受信されたセグメントに対応するbaseURL要素のsegmentAvailabilityOffset属性を調整することができる。segmentAvailabilityOffsetパラメータは、計算された利用可能開始時間を修正することができ、利用可能開始時間の代わりに自ら調整され得る。
様々な実施形態では、受信機デバイスプロセッサは、ベースセグメントを2つの異なる期間および表現ペアにマッチさせることができる。正確なマッチはより小さないタイムライン調整をもたらす期間および表現ペアであり得るが、これは、その期間および表現ペアはライブストリーミングシステムにおけるタイムライン調整である可能性が高い場合がある。
様々な実施形態では、受信機デバイスにおけるタイミングドリフトを追跡することができ、タイミングドリフトの検出に応じて、受信機デバイスプロセッサはそのMPDに関する新しい利用可能開始時間を決定することができる。様々な実施形態では、受信機デバイスプロセッサ(たとえば、受信機デバイスプロセッサ上で実行されるマルチキャストサービスデバイスクライアント)によって、DASHクライアントによる失敗したHTTP要求に関連するセグメント番号またはセグメントURIを追跡することができる。セグメント番号またはセグメントURIが追跡されると、受信機デバイスプロセッサは、DASHクライアントによる各後続のHTTP要求が同じセグメント番号またはセグメントURIに関するか、または異なるセグメント番号またはセグメントURIに関するかを決定することができる。
異なるセグメント番号またはセグメントURIに対するHTTP要求を受信するとすぐに、受信機デバイスプロセッサは、失敗したHTTP要求が消去されたか、または依然として未解決であるかどうか、および要求されたセグメントが現在キャッシュ内に存在するかどうかを決定することができる。失敗したHTTP要求が依然として未解決であり、要求されたセグメントがキャッシュ内にあるとき、受信機デバイス上にタイミングドリフトが生じ、DASHクライアントがそのセグメントの要求を断念した可能性がある(すなわち、ドリフト条件が満たされた)後にそのセグメントを到着させる場合がある。タイミングドリフトが検出された(すなわち、ドリフト条件が満たされた)とき、利用可能開始時間を再計算することができ、タイミングドリフトを考慮するために、受信機デバイスはMPDを修正することができる。
一実施形態では、DASHクライアントが多数のHTTP要求を同時に発行するとき(たとえば、メディアストリームのラインエッジを決定するためのスタートアップ時に)セグメントの追跡を回避するために、セグメント持続時間の90%に等しい時間にわたってなど、次のセグメントの追跡を遅延させることができる。さらなる実施形態では、次のセグメント番号が現在の追跡されたセグメントよりも1つ大きいセグメントインデックスであるときのみ、ドリフト条件に対する検査を適用することができる。いくつかの実施形態では、一度に1つのセグメントのみを追跡することができる。他の実施形態では、一度に複数のセグメントを追跡することができる。
様々な実施形態では、MPDにおける対応する期間および表現結合に対するセグメントのURLのURLマッチングを利用して、タイミングドリフトが生じたかどうかを決定することができる。一実施形態では、セグメントに関する復号時間からマッチする期間および表現結合に基づくMPDごとのセグメントの利用可能開始時間を減じたものがセグメント持続時間の半分よりも大きいとの決定に応じて、受信機デバイスプロセッサは、タイミングドリフトが生じたと決定し、利用可能開始時間の再計算をトリガすること(すなわち、利用可能開始時間再計算をトリガすること)ができる。別の実施形態では、URLマッチングに少なくとも部分的に基づいてセグメントインデックス変更が生じたとの決定に応じて、タイミングドリフトが決定され得る。一実施形態では、受信されたセグメントから生じるAST変更は、URLマッチングに少なくとも部分的に基づいて決定され得る。AST変更が、1つのセグメント持続時間など、しきい値より大きいことに応じて、受信機デバイスプロセッサは、タイミングドリフトが生じたと決定し、利用可能開始時間再計算をトリガすることができる。
図1は、様々な実施形態とともに使用するのに好適なセルラーネットワークシステム100を示す。セルラーネットワークシステム100は、受信機デバイス102、1つまたは複数のセルラータワーまたは基地局104、ならびに、インターネット110に接続されたサーバ108および112のような、複数のデバイスを含み得る。受信機デバイス102は、CDMA、TDMA、GSM（登録商標）、PCS、3G、4G、LTE、または任意の他のタイプの接続を含む、1つまたは複数のセルラー接続106を介して、セルラータワーまたは基地局104とデータを交換することができる。セルラータワーまたは基地局104は、インターネット110に接続し得るルータと通信していてよい。このようにして、セルラータワーまたは基地局104への接続、および/あるいはインターネット110を介して、受信機デバイス102とサーバ108および112との間でデータが交換され得る。一実施形態では、サーバ108は、DASHクライアントを介した出力のためにMPDおよびセグメントを提供する、コンテンツプロバイダサーバまたはエンコーダであり得る。一実施形態では、サーバ112は、エンコーダからMPDおよびセグメントの出力を受信し、受信機デバイス102へのMPDおよびセグメントのOTA送信を制御できる、ブロードキャストマルチメディアサービスセンター(BMSC)サーバであり得る。もちろん、本明細書で説明する受信機デバイスの機能はOTA送信を参照して説明されることがあるが、これらの機能は、有線送信、ワイヤレス送信、または有線送信とワイヤレス送信の組合せとともに使用されてよい。したがって、OTA送信は必須でない。
図2は、一実施形態による、簡略化された受信機デバイス202のアーキテクチャを示す。受信機デバイス202は、取得、ハンドオフ、リンク維持などのような、受信機デバイス202のすべての無線の態様を管理する、モデムレイヤ208を含み得る。モデムレイヤ208は、受信されたeMBMSベアラ信号を復号し、インターネットプロトコル(IP)パケットをマルチキャストサービスデバイスクライアント(MSDC)206に配信することができる。
マルチキャストサービスデバイスクライアント206は、配信されたIPパケットからセグメントを復元し、アプリケーション/DASHクライアント204のようなアプリケーション/クライアントに対してセグメントを利用可能にする、受信機デバイス202のサービスレイヤであり得る。例として、マルチキャストサービスデバイスクライアント206は、受信機デバイス202のオペレーティングシステムの一部であるサービスレイヤであり得る。マルチキャストサービスデバイスクライアント206はまた、配信されたIPパケットからMPDを復元することができる。マルチキャストサービスデバイスクライアント206は、受信機デバイスのメモリ内に受信されたセグメントを記憶することができる。
一実施形態では、マルチキャストサービスデバイスクライアント206は、MPDを調整して、修正されたMPDを生成し、受信機デバイスのメモリ内に修正されたMPDを記憶することができ、修正されたMPDをアプリケーション/DASHクライアント204に配信することができる。別の実施形態では、マルチキャストサービスデバイスクライアント206は、MPDに対する遅延調整値を決定し、受信機デバイスのメモリ内に(たとえば、遅延調整メッセージ内に)MPDに対する遅延調整値を記憶し、受信機デバイスのメモリ内にMPDを記憶することができ、MPDとMPDに対する遅延調整値とをアプリケーション/DASHクライアント204に配信することができる。
アプリケーション/DASHクライアント204は、DASH対応アプリケーション、および/または、(直接、かつ/または、メディアプレーヤのような別のアプリケーションを介して)メディアを表示するためにDASHクライアントを起動するアプリケーションであり得る。一実施形態では、アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206から修正されたMPDの位置(たとえば、ユニフォームリソースロケータ(URL))を取得し、マルチキャストサービスデバイスクライアント206から修正されたMPDを要求し受信することができ、修正されたMPD内の利用可能性タイムラインごとに、マルチキャストサービスデバイスクライアント206からのセグメントを要求することができる。別の実施形態では、アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206からMPDの位置(たとえば、ユニフォームリソースロケータ(URL))とMPDの位置(たとえば、URL)に対する遅延調整値とを取得し、マルチキャストサービスデバイスクライアント206からMPDとMPDに対する遅延調整値とを要求して受信し、MPDに対する遅延調整値に従ってMPDを修正して修正されたMPDを生成することができ、修正されたMPD内の利用可能性タイムラインごとにマルチキャストサービスデバイスクライアント206からのセグメントを要求することができる。アプリケーション/DASHクライアント204は、マルチキャストサービスデバイスクライアント206から要求されたセグメントを受信することができ、セグメントのコンテンツを(直接、かつ/または、メディアプレーヤのような別のアプリケーションを介して)レンダリングすることができる。
一実施形態では、MPDに対する遅延調整値を決定するために使用されるマルチキャストサービスデバイスクライアント206の機能は、クライアント206に統合されてよく、クライアント206は、遅延調整値を決定し、かつ/または、MPD自体を修正することができる。
図3Aは、一実施形態による、セグメント配信経路に沿った、MPDのようなセグメント利用可能性タイムラインに対して行われ得る、配信調整を示す。セグメント配信経路は、エンコーダ302、BMSC 304、受信機デバイスのマルチキャストサービスデバイスクライアント306、および受信機デバイスのDASHクライアント308を含み得る。エンコーダ302は、メディアコンテンツをセグメントへと符号化し、セグメントを定期的にBMSC 304に配信することができる。たとえば、セグメントは、eMBMSゲートウェイを介して、エンコーダ302からBMSC 304に定期的に配信され得る。BMSC 304は、ベアラを通じて(たとえば、OTAブロードキャストを介して)セグメントを受信し、セグメントをブロードキャストすることができる。一実施形態では、ヘッドエンドのレイテンシおよびジッタは知られていることがある。受信機デバイス内に存在するマルチキャストサービスデバイスクライアント306はモデムを介してセグメントを受信することができ、マルチキャストサービスデバイスクライアント306は、セグメントを処理して(たとえば、セグメントを復号して、FECを適用してなど)、セグメントを受信機デバイス上に存在するDASHクライアント308に利用可能にすることができる。DASHクライアント308は、セグメントを受信機デバイスのアプリケーション(たとえば、メディアプレーヤ)またはコーデックに提供して、受信機デバイスによるメディアコンテンツの出力を可能にし得る。
セグメントを生成することに加えて、エンコーダ302は、MPD 310を生成することができる。エンコーダにより生成されたMPD 310は、エンコーダ302によって生成された、かつ/または生成されることになるセグメント、セグメントの長さ(たとえば、サイズ)、およびセグメントの利用可能開始時間を列挙し得る。一実施形態では、エンコーダにより生成されるMPD 310の中の利用可能開始時間は、エンコーダ302により生成されるセグメントの出力時間に対応し得る。エンコーダ302は、生成されたMPD 310をBMSC 304に提供することができる。一実施形態では、BMSC 304は、生成されたMPD 310を受信し、あらゆるOTA配信遅延(たとえば、ネットワークジッタ)を考慮するようにセグメント利用可能性タイムラインを調整して、MPD 312を生成することができる。BMSC 304は、MPD 312を受信機デバイスに送信することができる。MPD 312は、セグメントのOTA利用可能開始時間に対応するセグメント利用可能開始時間を列挙し得る。
一実施形態では、受信機デバイスはMPD 312を受信することができ、受信機デバイスのマルチキャストサービスデバイスクライアント306は、受信機デバイスの遅延(たとえば、処理遅延、受信機デバイスのクロックドリフトのマージンなど)に基づいて、ローカル受信機デバイスのクロックごとに利用可能開始時間を調整して、受信機デバイスにおけるセグメントに対する実際の推定される利用可能開始時間を列挙する修正されたMPD 314を生成することができる。マルチキャストサービスデバイスクライアント306は、修正されたMPD 314をDASHクライアント308に提供することができ、DASHクライアントは、MPD内のセグメント利用可能開始時間を使用して、受信機デバイスのクロックを使用して受信機デバイスのローカルHTTPサーバからのセグメントを要求することができる。別の実施形態では、受信機デバイスのマルチキャストサービスデバイスクライアント306は、受信機デバイスの遅延(たとえば、処理遅延、クロックドリフトなど)に基づいて、ローカル受信機デバイスのクロックごとにMPD 312内の利用可能開始時間を調整し、DASHクライアント308に送られるあらゆるMPDとは別個に、利用可能開始時間に対する調整をDASHクライアント308に通信することができる。さらなる実施形態では、マルチキャストサービスデバイスクライアント306によって行われる調整は、表示がユニキャスト送信を介して受信されたかブロードキャスト送信を介して受信されたか、および/または、各表示のセグメントサイズに基づいて変化し得る。
図3Bは、別の実施形態による、セグメント配信経路に沿った、MPDのようなセグメント利用可能性タイムラインに対して行われ得る、配信調整を示す。図3Bに示される配信調整は、図3Bではマルチキャストサービスデバイスクライアント306がDASHクライアント308に送信する前にMPDを修正できないことを除き、図3Aを参照して上記で説明したものと同様である。
一実施形態では、受信機デバイスはMPD 312を受信することができ、受信機デバイスのマルチキャストサービスデバイスクライアント306はセグメント利用可能開始時間を修正することなくMPD 312をDASHクライアント308に提供することができる。一実施形態では、マルチキャストサービスデバイスクライアント306は、受信機デバイスの遅延(たとえば、処理遅延、クロックドリフトなど)に基づいてローカル受信機のデバイスのクロックごとに利用可能開始時間を調整し遅延調整値を列挙する遅延調整メッセージ316を生成するために使用され得る、遅延調整値を決定することができる。マルチキャストサービスデバイスクライアント306は、遅延調整メッセージをDASHクライアント308に提供することができる。
一実施形態では、DASHクライアント308は、遅延調整メッセージ316内の遅延調整指示を使用して、MPD 312内のセグメント利用可能開始時間を修正して、修正されたMPD 314を生成することができる。DASHクライアント308は、受信機デバイスのクロックを使用して、受信機デバイスのローカルHTTPサーバからセグメントを要求することができる。別の実施形態では、DASHクライアント308は、遅延調整メッセージ316を受信し、遅延調整メッセージ316を使用して、修正されたMPD 314を生成することなく受信機デバイスのローカルHTTPサーバからのセグメントに対する要求を修正することができる。
図4は、ネットワーク400の種々の部分における2つの例示的な配信経路遅延Δ1およびΔ2間の関係を示す。エンコーダ402からのコンテンツは、エンコーダ402からセグメンタ404へと流れ、種々のBMSC、すなわちBMSC1およびBMSC2、ならびにそれぞれのeノードB、すなわちeNB1.1、eNB1.2、eNB1.n、eNB2.1、eNB2.2、eNB2.nなどによってサービスされるネットワーク406、408の2つの異なる部分に提供され得る。eノードBのeNB1.2は、第1の部分406において受信機デバイス1(410)にコンテンツを提供することができ、eノードBのeNB2.2は第2の部分408において受信機デバイス2(412)にコンテンツを提供することができる。ネットワーク400の展開において、ネットワーク部分406および408は、異なるインフラストラクチャベンダーによって管理可能であり、かつ/または異なるマルチキャストブロードキャスト単一周波数ネットワーク(MBSFN:Multicast-broadcast single-frequency network)であり得る。
経路遅延Δ1は、BMSC1に関する処理遅延であり得、BMSC1からそれぞれのeノードB、すなわちeNB1.1、eNB1.2、eNB1.nを通して受信機デバイス1(410)にセグメントを提供する際にこの遅延を経験し得る。経路遅延Δ2は、BMSC2に関する処理遅延であり得、BMSC2からそれぞれのeノードB、すなわちeNB2.1、eNB2.2、eNB2.nを通して受信機デバイス2(412)にセグメントを提供する際にこの遅延を経験し得る。第1の部分406における経路遅延Δ1は、第2の部分408における経路遅延Δ2とは異なり得る。したがって、コンテンツの同じセグメントは、異なる部分406、408における異なる経路遅延Δ1およびΔ2のために、コンテンツが受信機デバイス2(412)において利用可能となり得るのとは異なる時間に、受信機デバイス1(410)において利用可能となり得る。異なる経路遅延Δ1およびΔ2は、複数のインフラストラクチャベンダーによるネットワーク展開および/または同じコンテンツに関して異なるMSPを使用する異なるMBSFN間の受信機デバイスモビリティを含めて、様々な要因によって引き起こされる可能性がある。
経路遅延がネットワーク400に対する推定最悪状況遅延よりも小さいとき、受信機デバイス1(410)または受信機デバイス2(412)におけるコンテンツのセグメントの実際の利用可能開始時間は、受信機デバイスに提供されるMPDに列挙された利用可能開始時間よりも早いものとなり得る。たとえば、いくつかの同期ネットワーク展開では、経路遅延Δ1は、経路遅延Δ2より短い場合があり、ネットワーク内の最長経路遅延(たとえば、Δ2)を考慮するために、ネットワーク内のMPDは、利用可能開始時間を同期させて、より長い経路遅延Δ2に相当する利用可能開始時間にマッチさせることができる。そのような例では、受信機デバイス2(412)内のセグメント利用可能性タイムラインは、ほぼΔ2〜Δ1によってオフセット可能であり、受信機デバイス1(410)は、再生開始の前に少なくともΔ2〜Δ1に対する第1の受信されたセグメントを不必要に記憶する場合がある。様々な実施形態によって、受信機デバイス1(410)および/または受信機デバイス2(412)は、それらの実際に経験する経路遅延Δ1および/またはΔ2を考慮し、コンテンツのセグメントが実際に利用可能となり得るときにそれらを要求することが可能となり得る。
図5Aは、決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法500aを示す。一実施形態では、方法500aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。
ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDを受信することができる。一実施形態では、受信機デバイスは、OTA送信を介してMPDを受信することができる。一実施形態では、MPDは、ネットワークから受信されてよく、ヘッドエンドは、MPD内にセグメントの利用可能開始時間を設定することができる。一実施形態では、MPD内の利用可能開始時間は、ネットワークによって設定されてよく、セグメントを生成するエンコーダから受信機デバイスまでの最悪の場合のエンドツーエンドの転送遅延を考慮し得る。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介してMPDを受信することができる。ブロック504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD内で記述される1つまたは複数のセグメントに関する1つまたは複数のセグメントフラグメントを受信することができる。たとえば、セグメントフラグメントは、マルチキャストチャネル(MCH)スケジューリング期間(MSP)中に受信されたOTAであり得る。
決定ブロック506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントインデックス変更が生じたかどうかを決定することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、2つの連続的に受信されたセグメントフラグメント内に示されたセグメントインデックスを互いに比較することによって、セグメントインデックス変更が生じたかどうかを決定することができ、セグメントインデックス変更は、連続的に受信されたセグメントフラグメントのセグメントインデックス間のミスマッチによって示すことができる。様々な実施形態では、各々が関連付けられるセグメントのタイプ(たとえば、ビデオまたはオーディオ)にかかわらず、受信されたセグメントフラグメントを互いと比較することができる。セグメントインデックス変更が生じていないとの決定(すなわち、決定ブロック506=「No」)に応じて、ブロック504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントフラグメントを受信し続けることができる。
セグメントインデックス変更が生じたとの決定(すなわち、決定ブロック506=「Yes」)に応じて、ブロック508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信された最新セグメントをベースセグメントとして設定することができる。一実施形態では、受信された最新セグメントは、最高インデックス番号を有するセグメントであり得る。ブロック510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに関する第1のFDTを受信することができる。ブロック512において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のFDT受信時間(1stFDTArrivalTimeBaseSegment)を決定することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、第1のFDT受信時間(1stFDTArrivalTimeBaseSegment)としてベースセグメントに関する第1のFDT内で記述されたように、ベースセグメントに対応するオブジェクトの第1のパケットの受信時間を決定することができる。
ブロック514において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、
AvailabilitySBASE=1stFDTArrivalTimeBaseSegment+(SF*MSP)+M
など、第1のFDT受信時間(たとえば、((1stFDTArrivalTimeBaseSegment)+(セグメントごとのセグメントフラグメント(SF)の数×MSP)+マージン(M)として、ベースセグメントに関して調整された利用可能開始時間(たとえば、AvailabilitySBASE))を決定することができる。一実施形態では、MSPの値は、受信機デバイスに対して事前に準備されたデフォルト値であり得る。別の実施形態では、MSPは、セグメントを受信するための一時的モバイルグループ識別子(TMGI)に関連する可変値であり得る。マージン(M)は、受信機デバイスによる処理遅延を考慮するための追加のマージンであってよく、受信機デバイスのメモリ内で事前に準備され得る。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに対応するオブジェクトの第1のパケットの受信時間に少なくとも部分的に基づいて、ベースセグメントの調整された利用可能開始時間を決定することができる。
ブロック516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに関する調整された利用可能開始時間(AvailabilitySBASE)と受信されたMPD内のベースセグメントの利用可能開始時間との間の差として遅延調整値を決定することができる。ブロック518において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、処理遅延調整値の分だけ、MPD内のセグメントの利用可能開始時間をシフトすることができる。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間をシフトして、セグメントが受信機デバイスにおいて実際にいつ利用可能であり得るかを反映することができる。
任意選択のブロック520において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに対して利用可能なメモリ内に、修正されたMPDを記憶することができる。一実施形態では、修正されたMPDを記憶するステップは、いくつかまたはすべてのMPDが記憶されるURLと関連付けられる受信機デバイス上のメモリ位置内に、修正されたMPDを記憶するステップを含み得る。別の実施形態では、クライアントアプリケーションは、修正されたMPDを別個のメモリ位置に特に記憶しなくてよい。むしろ、任意選択のブロック522において、クライアントアプリケーションは、修正されたMPDを使用して、シフトされた利用可能開始時間においてセグメントを要求するだけであってよい。
図5Bは、決定された第1のFDT受信時間に基づくセグメントインデックス変更に応じて、遅延調整メッセージを生成するための一実施形態の方法500bを示す。方法500bは、セグメント利用可能性タイムラインのシフトを示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図5Aを参照して上記で説明した方法500aと同様である。一実施形態では、方法500bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法500bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、504、506、508、510、512、514、および516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上で説明した方法500aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。
ブロック524において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整メッセージ内に遅延調整の指示を記憶することができる。一実施形態では、遅延調整メッセージは、クライアントアプリケーションが、受信機デバイスにおけるセグメント利用可能性を考慮するように、1つまたは複数のセグメントの利用可能開始時間をシフトするために使用され得る遅延調整値を決定するのに使用できる、データファイルであり得る。一実施形態では、遅延調整メッセージは、いくつかまたはすべての遅延調整メッセージが記憶されるURLと関連付けられる受信機デバイス上のメモリ位置内に記憶され得る。任意選択のブロック526において、マルチキャストサービスデバイスクライアントは、1つまたは複数のセグメントの利用可能開始時間をシフトする際にクライアントアプリケーションが使用するために、遅延調整メッセージをクライアントアプリケーションに送ることができる。別の実施形態では、遅延調整メッセージは送信されなくてよく、むしろ、クライアントアプリケーションによって必要に応じて、その記憶されたメモリ位置においてアクセスされてよく、またはそこから要求されてよい。
図6Aは、決定された第1のFDT受信時間に基づくベースURL変更に応じて、セグメント利用可能開始時間を修正するための一実施形態の方法600aを示す。方法600aは、新しいセグメントからのセグメントフラグメントを示すセグメントインデックス変更が受信されるのではなく、セグメント間のbaseURL変更は、新しいセグメントに関するセグメントフラグメントが受信されていることを示し得ることを除いて、図5Aを参照して上記で説明した方法500aと同様である。一実施形態では、方法600aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502および504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上記で説明した方法500aの同様に番号付けされたブロックの動作を実行することができる。
ブロック507において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、baseURL変更が生じたかどうかを決定することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、2つの連続的に受信されたセグメントフラグメント内に示されたbaseURLを互いに比較することによって、baseURL変更が生じたかどうかを決定することができ、baseURL変更は、連続的に受信されたセグメントフラグメントのbaseURL間のミスマッチによって示すことができる。たとえば、セグメントの各セグメントフラグメントに関するURL全体は一意であり得るが、URLの初期部分を形成するbaseURLは共通のセグメントの各セグメントフラグメントに関して同じであり得る。したがって、baseURL(たとえば、URLの初期部分)の変更は、新しいセグメントのフラグメントが受信されていることを示し得る。baseURLが変更していないとの決定(すなわち、決定ブロック507=「No」)に応じて、ブロック504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントフラグメントを受信し続けることができる。baseURLが変更したとの決定(すなわち、決定ブロック507=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上記で説明した方法500aの同様に番号付けされたブロック508、510、512、514、516、518、520、および522の動作を実行することができる。
図6Bは、決定された第1のFDT受信時間に基づくベースURL変更に応じて、遅延調整メッセージを生成するための一実施形態の方法600bを示す。実施形態の方法600bは、セグメント利用可能性タイムライン内のシフトを示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図6Aを参照して上記で説明した方法600aと同様である。一実施形態では、方法600bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法600bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック502、504、507、508、510、512、514、および516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図6Aを参照して上記で説明した方法600aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。ブロック524および526において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整ファイルを記憶して、送るために、図5Bを参照して上記で説明した方法500bの同様に番号付けされたブロックの動作を実行することができる。一実施形態では、方法600bの動作は、それぞれ、図5Aおよび図5Bを参照して上述した方法500aおよび500bの動作と平行してマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって実行され得る。
図7は、一実施形態による利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す。図7に示すように、セグメント1、2、3、4、および5はソースからBMSCに送られてよく、BMSCはセグメント1、2、3、4、および5を、ブロードキャストされる一連のセグメントフラグメントに分けることができる各MSP持続時間。BMSC処理および同期スケジューリング動作は、受信機デバイスに対するセグメントフラグメントのOTA送信を遅延させる場合があり、2つ以上のセグメントからのフラグメントはMSP持続時間ごとに送られ得る。セグメントは、復号され、BMSCによるそのOTA送信の後の何らかの期間に受信機デバイスにおいて利用可能にされ得る。
図5A、図5B、図6A、および図6Bを参照して上記で論じた様々な実施形態では、獲得開始後、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、新しいセグメントに関するセグメントフラグメントが属性内のミスマッチによって識別されるまで、セグメントフラグメントが受信されるにつれて、セグメントフラグメントの属性(たとえば、セグメントインデックスまたはbaseURL)を比較することができる。図7に示すように、ミスマッチは、セグメント2に関する最後のFDTおよびセグメント3に関する最初のFDTが受信されるときに生じ得る。セグメント3に関する第1のFDTの到着時間に基づいて、図5A、図5B、図6A、および図6Bを参照して上記で説明した方法500a、500b、600a、および600bに従って、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、(FDT到着時間+セグメントごとのセグメントフラグメント(SF)の数)×(MSP+マージン(M)(たとえば、(SF*MSP)+M)))として、セグメント3の利用可能開始時間を示すことができる。修正されたMPDは、それに応じて、セグメント3に関する利用可能開始時間を示すことができ、セグメント4の利用可能開始時間など、各後続のセグメントの利用可能開始時間は、修正されたMPD内のセグメント3に関する示された利用可能開始時間からの連続的なセグメント持続期間であり得る。したがって、ベースセグメントの利用可能開始時間を第1のステップで決定することができ、MPD内のベースセグメントの利用可能開始時間が第1のステップにおいて決定された利用可能開始時間にマッチするように、MPDを第2のステップで調整することができる。
図8Aは、いずれかの決定されたFDT受信時間に基づいてユニキャストモードでセグメント利用可能開始時間を修正するための一実施形態の方法800aを示す。一実施形態では、方法800aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。上記で論じたように、ブロック502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDを受信することができる。さらに別の実施形態では、FDTを使用して、セグメントインデックスまたはbaseURL内の変更を決定することができ、実際の到着時間は、ファイルの識別子(たとえば、FLUTEの場合、トランスオートオブジェクト識別子、TOI)を搬送する第1のパケットが受信された時間であり得る。
決定ブロック802において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ユニキャストフェッチがアクティブかどうかを決定することができる。一実施形態では、ユニキャストフェッチは、モード1で(たとえば、起動時にセグメントを要求するためにユニキャストを使用して)またはモード2で(たとえば、いずれかの時点でユニキャストを使用して)アクティブであり得る。モード1またはモード2において、ユニキャストフェッチは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントのブロードキャスト/マルチキャスト受信を待たずに、ユニキャストを介してセグメントを要求することを可能にし得る。アクティブまたは非アクティブであるユニキャストフェッチは、受信機デバイスのメモリ内のユニキャストフェッチに関連するフラグ設定によってなど、任意の方法で示されてよい。ユニキャストフェッチがアクティブでないとの決定(すなわち、決定ブロック802=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aのブロック502に進み、方法500aの動作を実行することができる。
ユニキャストフェッチがアクティブであるとの決定(すなわち、決定ブロック802=「Yes」)に応じて、ブロック806において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ブロードキャスト送信またはマルチキャスト送信を介してFDTを受信することができる。FDTは、受信されたOTAであってよく、第1のFDT、最後のFDT、または中間FDTなど、セグメントに関するいずれかのFDTであってよい。ブロック808において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたFDTに関連するセグメントをベースセグメントとして設定することができる。ブロック810において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたFDT受信時間(FDTArrivalTimeBaseSegment)を決定することができる。
ブロック812において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、
AvailabilitySBASE=FDTArrivalTimeBaseSegment+(SF*MSP)+M)
など、FDT受信時間(たとえば、FDTArrivalTimeBaseSegment)+(セグメントごとのセグメントフラグメント(SF)の数×MSP)+マージン(M)として、ベースセグメントに関して調整された利用可能開始時間(たとえば、AvailabilitySBASE)を決定することができる。一実施形態では、MSPの値は、受信機デバイスに対して事前に準備されたデフォルト値であり得る。別の実施形態では、MSPは、セグメントを受信するための一時的モバイルグループ識別子(TMGI)に関連する可変値であり得る。マージン(M)は、受信機デバイスによる処理遅延を考慮するための追加のマージンであってよく、受信機デバイスのメモリ内で事前に準備された値として構成され得る。ブロック516、518、520、および522において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図6Aを参照して上記で説明した方法600aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。
図8Bは、いずれかの決定されたFDT受信時間に基づいてユニキャストモードで遅延調整メッセージを生成するための一実施形態の方法800bを示す。方法800bは、セグメント利用可能性タイムライン内のシフトを示す遅延調整メッセージがセグメント利用可能性タイムラインを必ずしもシフトすることなく生成され得ることを除き、図8Aを参照して上記で説明した方法800aと同様である。一実施形態では、方法800bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法800bの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。
ブロック502、802、804、806、808、810、812、および516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図8Aを参照して上記で説明した方法800aの同様に番号が付けられたブロックの動作を実行して、遅延調整値を決定することができる。ブロック524および526において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延調整ファイルを記憶して、送るために、図5Bを参照して上記で説明した方法500bの同様に番号付けされたブロックの動作を実行することができる。
図9Aは、一実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。アプリケーション/DASHクライアントは、マルチキャストサービスデバイスクライアントのサービス発見機能に対する要求を送ることによって、サービスがアクティブ化されることを要求することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、サービス要求を受信し、サービスが有効であると決定し、サービス情報をマルチキャストサービスデバイスクライアントのストリーミング機能に送ってサービスをアクティブ化することができる。マルチキャストサービスデバイスのストリーミング機能は、サービスが有効であると決定し、サービスの一時モバイルグループ識別子(TMGI)をアクティブ化するための要求をマルチキャストサービスデバイスクライアントのモデムインターフェースに送ることができる。マルチキャストサービスデバイスクライアントのストリーミング機能はまた、マルチキャストサービスデバイスクライアントのデータ配信機能がFLUTEセッションをアクティブ化することを要求し、マルチキャストサービスデバイスクライアントのデータ配信機能がセグメントURLを獲得することを要求することができる。
一時モバイルグループ識別子がモバイル制御チャネル(MCCH)においてアクティブになり、デバイスがメディア転送チャネル(MTCH)を復号できるようになると、モデムによって受信されるIPパケットは、マルチキャストサービスデバイスクライアントのモデムインターフェースからマルチキャストサービスデバイスクライアントのデータ配信機能に配信され得る。任意選択で、MSDモデムインターフェースは、更新されたベアラ記述をMSPストリーミング機能に配信することができる。マルチキャストサービスデバイスクライアントのデータ配信機能は、ファイル捕捉要求をMSPストリーミング機能に送ることができる。セグメントN、すなわちN+1、N+2などが受信され復号されるにつれて、それらは、マルチキャストサービスデバイスクライアントのDASHゲートウェイに送信され得る。
一実施形態では、マルチキャストサービスデバイスクライアントのストリーミング機能が、受信されたセグメントフラグメント間のインデックス変更を決定するとき、マルチキャストサービスデバイスクライアントのサービス発見機能は、ベースセグメントFDTの受信時間およびインデックス番号をマルチキャストサービスデバイスのサービス発見機能に示すことができ、マルチキャストサービスデバイスのサービス発見機能は、上記で論じたように、MPDを修正して、利用可能開始時間を調整することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、修正されたMPDをマルチキャストサービスデバイスクライアントのDASHゲートウェイに送ることができる。マルチキャストサービスデバイスクライアントのストリーミング機能は、サービスが開始したことをアプリケーション/DASHクライアントに示すことができる。
アプリケーション/DASHクライアントは、メディアプレーヤを起動し、メディアプレーヤを修正されたMPDのURLに向けることができる。アプリケーション/DASHクライアントは、修正されたMPD URLにおいて修正されたMPDに対するHTTP Get()要求を送ることができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、修正されたMPDによって応答することができる。アプリケーション/DASHクライアントは、初期セグメント(IS)のURLにおいてISに対するHTTP Get()要求を送ることができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、ISによって応答することができる。アプリケーション/DASHクライアントは、セグメントN-1に対するHTTP Get()要求を送ることができる。セグメントN-1は利用可能ではないことがあり、マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントが見つからなかったと応答し得る(たとえば、404 Not Found)。アプリケーション/DASHクライアントは、セグメントN+1に対するHTTP Get()要求を送ることができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、セグメントN+1によって応答することができる。
図9Bは、別の実施形態による、受信機デバイス上でのマルチキャストサービスデバイスクライアントとアプリケーション/DASHクライアントとの対話を示すメッセージフロー図である。図9Bでは、ビデオセグメントおよびオーディオセグメントが独立して捕捉され得ることを除いて、図9Bに示すフローは、図9Aを参照して上記で説明したフローと同様である。マルチキャストサービスデバイスクライアントのデータ配信機能がMとインデックス付けされたビデオセグメントおよびMとインデックス付けされたオーディオセグメントに対する捕捉要求を送るにつれて、マルチキャストサービスデバイスクライアントのデータ配信機能は、M+1とインデックス付けされた次のビデオセグメントに対する捕捉要求も送ることができる。一実施形態では、マルチキャストサービスデバイスクライアントのストリーミング機能が、受信されたビデオセグメントMとビデオセグメントM+1との間のインデックス変更を決定するとき、マルチキャストサービスデバイスクライアントのサービス発見機能は、ビデオセグメントM+1がベースセグメントであることを示し、ベースセグメントFDTの受信時間およびインデックス番号をマルチキャストサービスデバイスのサービス発見機能に示すことができ、マルチキャストサービスデバイスのサービス発見機能は、上記で論じたように、MPDを修正して、利用可能開始時間を調整することができる。マルチキャストサービスデバイスクライアントのサービス発見機能は、修正されたMPDをマルチキャストサービスデバイスクライアントのDASHゲートウェイに送ることができる。マルチキャストサービスデバイスクライアントのストリーミング機能は、サービスが開始したことをアプリケーション/DASHクライアントに示すことができる。
アプリケーション/DASHクライアントは、メディアプレーヤを起動し、メディアプレーヤを修正されたMPDのURLに向けることができる。アプリケーション/DASHクライアントは、修正されたMPD URLにおいて修正されたMPDに対するHTTP Get()要求を送ることができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、修正されたMPDによって応答することができる。アプリケーション/DASHクライアントは、初期セグメント(IS)のURLにおいてISに対するHTTP Get()要求を送ることができる。マルチキャストサービスデバイスクライアントのDASHゲートウェイは、ISによって応答することができる。アプリケーション/DASHクライアントは、オーディオセグメントMに対するHTTP Get()要求を送り、オーディオセグメントMを受信することができる。一実施形態では、ビデオセグメントMは、アクティブなとき、ユニキャストフェッチを介して受信可能であり、マルチキャストサービスデバイスのストリーミング機能は、ビデオセグメントM+1およびオーディオセグメントM+1がブロードキャストまたはマルチキャストを介して利用可能になるとき、それらの利用可能性について通知され得る。
図9Aおよび図9Bは、マルチキャストサービスデバイスのサービス発見機能がMPDを修正することを示すが、他の実施形態では、マルチキャストサービスデバイスのサービス発見機能は、その時間が、セグメントが受信機デバイス上のアプリケーション/DASHクライアントに対して実際にいつ利用可能になるかを反映するように、MPD内の利用可能開始時間をシフトするために使用され得る遅延調整値の表示を含む遅延調整メッセージまたはファイルを生成することができる。したがって、マルチキャストサービスデバイスクライアントまたはアプリケーション/DASHクライアントは、セグメントが受信機デバイス上のアプリケーション/DASHクライアントに実際に利用可能になるとき、遅延調整メッセージまたはファイルを使用して、MPD内の利用可能開始時間をシフトすること、および/またはセグメントを要求することができる。
図10は、遅延調整メッセージに基づいて利用可能開始時間を調整するための一実施形態の方法を示すプロセスフロー図である。一実施形態では、方法1000の動作は、DASHクライアントのような、スマートフォンのような受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。ブロック1002において、クライアントアプリケーションは、MPDを受信することができる。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介してMPDを受信することができる。ブロック1004において、クライアントアプリケーションは、遅延調整メッセージを受信することができる。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介して受信機デバイス上でHTTPサーバを介して遅延調整メッセージを受信することができる。
ブロック1006において、クライアントアプリケーションは、遅延調整メッセージに基づいて、MPD内のいくつかまたはすべてのセグメントの利用可能開始時間をシフトすることができる。一実施形態では、遅延調整メッセージに基づいて利用可能開始時間をシフトするステップは、遅延調整値および/または他の値の指示を使用して、各セグメントが受信機デバイス上で利用可能になる時間を調整するステップを含み得る。一実施形態では、利用可能開始時間をシフトするステップは、MPD自体を修正して修正されたMPDを生成するステップを含み得る。別の実施形態では、利用可能開始時間をシフトするステップは、MPD自体を修正することなく、セグメントが受信機デバイス上で利用可能になるときの指示を変更するステップを伴い得る。MPDが修正される実施形態では、任意選択のブロック1008において、クライアントアプリケーションは、クライアントアプリケーションに対して利用可能なメモリ内に、修正されたMPDを記憶することができる。ブロック1010において、クライアントアプリケーションが、シフトされた利用可能開始時間においてセグメントを要求することができる。
図11Aは、MPD更新を処理するための一実施形態方法を示すプロセスフロー図である。一実施形態では、方法1100aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1100aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。
ブロック1102において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD更新を受信することができる。一実施形態では、MPD更新は、ネットワークから受信されてよく、ヘッドエンドは、MPD更新内にセグメントの利用可能開始時間を設定することができる。一実施形態では、MPD更新内の利用可能開始時間は、ネットワークによって設定されてよく、セグメントを生成するエンコーダから受信機デバイスまでの最悪の場合のエンドツーエンドの転送遅延を考慮し得る。一実施形態では、クライアントアプリケーションは、マルチキャストサービスデバイスクライアントを介してMPD更新を受信することができる。
ブロック1104において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD更新内に設定された利用可能開始時間(AST)を決定することができる。決定ブロック1106において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最初に受信されたMPDとMPD更新との間にAST変更が生じたかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDのいずれかの修正の前に元のMPD内で示されたASTをMPD更新内のASTと比較することができる。
MPD更新内のASTが元のASTと同じであるとの決定(すなわち、決定ブロック1106=「No」)に応じて、ブロック1108において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD更新内のASTを調整して、前に修正されたMPD内の修正されたASTにマッチさせることができる。ASTがマッチしないとの決定(すなわち、決定ブロック1106=「Yes」)に応じて、ブロック1110において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ベースセグメントに関する決定された、調整された利用可能開始時間(AvailabilitySBase)と修正に先立つ元のASTとの間の差の分だけ、MPD更新内のASTを修正することができる。
図11Bは、MPD更新を処理するための一実施形態の方法1100bを示す。MPD更新内のASTの変更が利用可能開始時間再計算をトリガし得ることを除いて、方法1100bは、図11Aを参照して上記で説明した方法1100aと同様である。一実施形態では、方法1100bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1100bの動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。ブロック1102、1104、1106、および1108において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図11Aを参照して上記で説明した方法1100aの同様に番号付けされたブロックの動作を実行することができる。
ASTがマッチしないとの決定(すなわち、決定ブロック1106=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD更新内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。さらなる例として、利用可能開始時間再計算のトリガは、そのセグメントに関連するサービスをアクティブ化したアプリケーションに対する通知の発行を含み得る。
図12は、別の実施形態による、利用可能性タイムライン、MPD利用可能開始時間、送信時間、および到達時間を示す。図12は、経時的に、セグメント3などのセグメントの利用可能開始時間を決定することができ、(たとえば、その第1のFDTの受信時間に基づいて)セグメントが受信機デバイスにおいて実際にいつ利用可能になり得るかを考慮するために利用可能開始時間がシフトされることを示すが、受信機デバイス上のタイミングドリフトは、修正されたMPD内の利用可能開始時間を無効にする場合がある。
何らかの時間Nの後で、利用可能開始時間、AvailabilitytimeS4+Nを修正されたMPD内で示すことができ、DASHクライアントは、セグメントS4+Nに対するHTTP要求を発行することができる。しかしながら、受信機デバイスのタイミングドリフトにより、HTTP再試行は、セグメントS4+Nを受信せずに、DASHクライアントによって試し尽くされる場合がある。したがって、受信機デバイスのタイミングドリフトにより、DASHクライアントがセグメントS4+N要求の試行を中断した後でセグメントS4+Nは利用可能になり得る。様々な実施形態では、DASHクライアントのHTTP再試行が試し尽くされた後の(たとえば、セグメントS4+N+1が要求されると)セグメントS4+Nの受信は、利用可能開始時間の再計算をトリガし得る。このようにして、利用可能開始時間再計算は受信機デバイスのタイミングドリフトを考慮することができる。
図13は、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法1300を示す。一実施形態では、方法1300の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1300の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
ブロック1302において、マルチキャストサービスデバイスクライアントは、セグメントに対するHTTP要求を受信することができるか、またはクライアントアプリケーションはHTTP要求を生成することができる。HTTP要求は、セグメントのURIおよびセグメント番号を示し得る。決定ブロック1304において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントが現在追跡されているかどうかを決定することができる。様々な実施形態では、セグメントに関連するHTTP要求が失敗したとき、そのセグメントを追跡することができる。
何のセグメントも追跡されていないとの決定(すなわち、決定ブロック1304=「No」)に応じて、ブロック1306において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定するために、要求されたセグメントが利用不可能であったことを示す400シリーズHTTP応答が受信されたか否かを決定することができる。要求が成功したとの決定(すなわち、決定ブロック1306=「Yes」)に応じて、ブロック1308において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、追跡記録を消去することができ、ブロック1302において、次のセグメントに対する次のHTTP要求を受信または生成することができる。
要求が失敗したとの決定(すなわち、決定ブロック1306=「No」)に応じて、ブロック1310において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求されたセグメントを追跡することができ、ブロック1302において、同じセグメントに対するHTTP要求を再度受信または生成することができる。
セグメントが追跡されているとの決定(すなわち、決定ブロック1304=「Yes」)に応じて、決定ブロック1312において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求されたセグメントが追跡されているかどうかを決定することができる。要求されたセグメントが追跡されているとの決定(すなわち、決定ブロック1312=「Yes」)に応じて、上記で論じたように、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ブロック1306、1308、および1310において、要求が成功したかどうかを決定し、追跡記録を消去するか、またはセグメントを追跡し続けることができる。
追跡されているセグメントが要求されたセグメントではないとの決定(すなわち、決定ブロック1312=「No」)に応じて、ブロック1314において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、追跡されたセグメントがキャッシュ内(たとえば、受信されたセグメントストレージに割り振られたメモリ位置内)にあるかどうかを決定することができる。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが前に要求したが、受信に失敗したセグメントがその後受信されたかどうかを検査することができる。
追跡されたセグメントがキャッシュ内にないとの決定(すなわち、決定ブロック1314=「No」)に応じて、ブロック1316において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、追跡記録を消去することができる。任意選択の実施形態で、ブロック1318において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最後の新しいセグメント番号が要求されてから、セグメント持続時間の90%(たとえば、9*SD)が経過したかどうかを決定することができる。このようにして、複数のセグメントが一度に要求され得る起動シナリオを、ほぼすべてのセグメント持続時間に生じる定期的にタイミングがとられた要求と区別することができる。そのような任意選択の実施形態では、セグメント持続時間の90%が経過していないとの決定(すなわち、決定ブロック1318=「No」)に応じて、ブロック1302において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントに対するHTTP要求を受信または生成することができる。セグメント持続時間の90%(たとえば、9*SD)として示されているが、任意の割合値のセグメント持続時間を選択することができる。本明細書で説明する例における90%のセグメント持続時間に対して、たとえば、10%、50%、95%、または任意の他の割合値のセグメント持続時間を代用することができる。
ブロック1316において追跡記録を消去するとすぐに、または任意選択の実施形態では、セグメント持続時間の90%が経過したとの決定(すなわち、決定ブロック1318=「Yes」)に応じて、ブロック1306、1308、および1310において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定し、追跡記録を消去するか、またはセグメントを追跡し続けることができる。
追跡されたセグメントがキャッシュ内にあるとの決定(すなわち、決定ブロック1314=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。このようにして、受信機デバイスにおけるタイミングドリフトはセグメントの遅い到着によって識別可能であり、タイミングドリフトがマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって考慮され得る。
図14は、失敗したHTTP記録をマークするための一実施形態の方法1400を示す。一実施形態では、方法1400の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1400の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。様々な実施形態では、方法1400の動作は、図15Aおよび図15Bを参照して下記で説明する方法1500aおよび/または1500bの動作とともに実行され得る。
ブロック1402において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、セグメントを受信することができる。たとえば、セグメントはブロードキャストOTA送信またはマルチキャストOTA送信を介して受信され得る。決定ブロック1404において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントが追跡されているかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURIおよび/またはセグメントインデックスに関連する、失敗したHTTP記録が存在するかどうかを決定することができる。セグメントが追跡されていないとの決定(すなわち、決定ブロック1404=「No」)に応じて、ブロック1406において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、何の措置も講じなくてよい。セグメントが追跡されているとの決定(すなわち、決定ブロック1408=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、失敗したHTTP記録を「受信されたセグメント」とマークすることができる。このようにして、後に受信されたセグメントに関連する、失敗したHTTP要求を識別し、受信されていないセグメントに関連する、失敗したHTTP要求と区別することができる。
図15Aは、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法1500aを示す。一実施形態では、方法1500aの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1500aの動作は、DASHクライアントのような、受信機デバイスのプロセッサ上で実行されるクライアントアプリケーションによって実行され得る。様々な実施形態では、方法1500aの動作は、図14を参照して上記で説明した方法1400の動作とともに実行され得る。
ブロック1502において、マルチキャストサービスデバイスクライアントは、セグメントに対するHTTP要求を受信することができるか、またはクライアントアプリケーションはHTTP要求を生成することができる。HTTP要求は、セグメントのURIおよびセグメント番号を示し得る。決定ブロック1504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求内に新しいURIが示されているかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、HTTP要求内のURIを前のHTTP要求内のURIと比較して、URIが新しいかどうかを決定することができる。
URIが新しくないとの決定(すなわち、決定ブロック1504=「No」)に応じて、ブロック1506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定するために、要求されたセグメントが利用不可能であったことを示す400シリーズHTTP応答が受信されたか否かを決定することができる。要求が成功したとの決定(すなわち、決定ブロック1506=「Yes」)に応じて、ブロック1508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URIに関するいずれかの失敗したHTTP記録を消去することができる。
URIが新しいとの決定(すなわち、決定ブロック1504=「Yes」)に応じて、ブロック1510において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、要求が成功したかどうかを決定するために、要求されたセグメントが利用不可能であったことを示す400シリーズHTTP応答が受信されたか否かを決定することができる。要求が失敗したとの決定(すなわち、決定ブロック1510=「No」)に応じて、ブロック1512において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URIに関する失敗したHTTP記録を追加し、失敗したURI記録内の最初のタイムスタンプを現在の時間に設定することができる。
要求が成功しなかったとの決定(すなわち、決定ブロック1506=「No」)に応じて、またはブロック1512において、URIに関する失敗したHTTP記録を追加するとすぐに、ブロック1516において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URIに関する失敗したHTTP記録内の最後のタイムスタンプを現在の時間に設定することができる。このようにして、URIに関する失敗したHTTP記録内の最初のタイムスタンプから最後のタイムスタンプまでの時間は、その失敗したHTTP記録に関する追跡期間を示し得る。
ブロック1508において、URIに関する失敗したHTTP記録の消去、ブロック1516における、最後のタイムスタンプの設定、または要求が成功したとの決定(すなわち、決定ブロック1510=「Yes」)に応じて、ブロック1520において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最大記録追跡期間よりも長く記録されているいずれの失敗したHTTP記録も消去することができる。たとえば、最大記録追跡期間は、10秒など、FFR_periodの2倍であってよい。最大記録追跡期間よりも長い、失敗したHTTP記録内の最初のタイムスタンプから最後のタイムスタンプまでの失敗したHTTP記録を消去すること(たとえば、削除すること)ができる。
決定ブロック1522において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、最後のタイムスタンプを有する「受信されたセグメント」とマークされたいずれかの失敗したHTTP記録が、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに利用可能なメモリ内に存在する現在の時間の前の1つのセグメント持続時間よりも古いかどうかを決定する。「受信されたセグメント」とマークされたいずれの失敗したHTTP記録も1つのセグメント持続時間よりも古くないとの決定(すなわち、決定ブロック1522=「No」)に応じて、ブロック1502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のHTTP要求を受信または生成することができる。
「受信されたセグメント」とマークされた失敗したHTTP記録が1つのセグメント持続時間よりも古いとの決定(すなわち、決定ブロック1522=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。このようにして、受信機デバイスにおけるタイミングドリフトはセグメントの遅い到着によって識別可能であり、タイミングドリフトがマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって考慮され得る。
図15Bは、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法1500bを示す。利用可能開始時間再計算をトリガする前に遅延が導入され得ることを除いて、実施形態の方法1500bは、図15Aを参照して上記で説明した方法1500aと同様である。一実施形態では、方法1500bの動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1500bの動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。ブロック1502、1504、1506、1508、1510、1512、1516、1518、1520、および1522において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図15Aを参照して上記で説明した方法1500aの同様に番号が付けられたブロックの動作を実行することができる。
「受信されたセグメント」とマークされた失敗したHTTP記録が1つのセグメント持続時間よりも古いとの決定(すなわち、決定ブロック1522=「Yes」)に応じて、決定ブロック1524において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、遅延がすでに導入されていると決定することができる。遅延が導入されていないとの決定(すなわち、決定ブロック1524=「No」)に応じて、ブロック1528において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、90%のセグメント持続時間(0.9*SD)の遅延を導入し、すべての失敗したHTTP記録をマーク解除することができる。このようにして、利用可能開始時間再計算が速やかにトリガされなくてよく、失敗したHTTP記録に関するセグメントは、それらのセグメントが「受信されたセグメント」と再度マークされ得る前に2回目に受信されなければならない場合がある。セグメントの強制された再要求は、そのそれぞれの利用可能開始時間の終了に先立ってセグメントが受信され得るとき、利用可能開始時間の再計算が回避されることを可能にし得る。ブロック1502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のHTTP要求を受信または生成することができる。
遅延がすでに導入されているとの決定(すなわち、決定ブロック1524=「Yes」)に応じて、ブロック1526において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、2つのセグメント持続時間より前に遅延が導入されたかどうかを決定することができる。2つのセグメント持続時間より前に遅延が導入されなかったとの決定(すなわち、決定ブロック1526=「No」)に応じて、ブロック1502において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次のHTTP要求を受信または生成することができる。
2つのセグメント持続時間より前に遅延が導入されたとの決定(すなわち、決定ブロック1526=「Yes」)に応じて、ブロック1112において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間の再計算をトリガすることができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションに、MPD内の利用可能開始時間を修正するために、図5A、図5B、図6A、図6B、図8A、または図8Bを参照して上記で説明した方法500a、500b、600a、600b、800a、または800bのうちの1つの動作を実行させる割込みを送ることができる。このようにして、受信機デバイスにおけるタイミングドリフトはセグメントの遅い到着によって識別可能であり、タイミングドリフトがマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって考慮され得る。
図16は、URLマッチングによってセグメントインデックスを決定するための一実施形態の方法1600を示す。一実施形態では、方法1600の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法1600の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。様々な実施形態では、方法1600の動作は、それぞれ、図5Aおよび図5Bを参照して上記で説明した方法500aまたは500bの動作とともに実行され得る。たとえば、方法1600の動作は、MPDの受信(図5Aまたは図5Bのブロック502)およびセグメントフラグメントの受信(図5Aまたは図5Bのブロック504)の後、かつセグメントインデックス変更が生じたかどうかの決定(図5Aまたは図5Bのブロック506)の前に実行され得る。
ブロック1602において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURLを決定することができる。たとえば、受信されたセグメントに関するURLは、URLテンプレート「xxx$number$yyy」に続いてよい。別の例では、同じ時間持続時間に対応するオーディオセグメントおよびビデオセグメントは、URLテンプレート内に同じ$time$タグを有し得る。ブロック1604において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の最初の期間および表現結合を見つけ、最初の期間および表現結合を現在の期間および表現結合として設定することができる。様々なMPDにおいて、MPDをクロールすることは、MPDを表す、XMLファイルなどのファイルをパースすることを含み得る。本明細書で論じるように、期間および表現結合は、MPDによって定義される一意表現であり得る。MPD内で定義された各期間は、1つまたは複数の表現に関する属性、たとえば、1つまたは複数の適応セットを含んでよく、期間と1つまたは複数の表現からの個々の表現との組合せは、期間および表現結合を構成し得る。MPD内の期間および表現結合は、期間境界、URLフォーマット、セグメント持続時間、セグメントタイムスケール、開始番号、帯域幅、期間識別子などを含めて、サービスに関する各期間および表現を記述する属性を含み得る。
ブロック1606において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントの決定されたURLをMPD内の現在の期間および表現結合と比較することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメント内のURLを期間および表現結合内に示されたURLと比較することができる。
決定ブロック1608において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントに関する決定されたURLが現在の期間および表現結合内のURLにマッチするかどうかを決定することができる。URLがマッチしないとの決定(すなわち、決定ブロック1608=「No」)に応じて、ブロック1614において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の次の期間および表現結合を見つけ、次の期間および表現結合を現在の期間および表現結合として設定することができる。ブロック1606において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、決定されたURLをMPD内の新しい現在の期間および表現結合と比較することができる。
URLがマッチするとの決定(すなわち、決定ブロック1608=「Yes」)に応じて、ブロック1610において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、現在の期間および表現結合内のURLと決定されたURLとに少なくとも部分的に基づいて潜在的なセグメント番号マッチを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、少なくとも非数字、および任意選択で、その後にファイル拡張が続く非数字が先行する、セグメントURLの最後におけるセグメントインデックスを識別することによって、URLに少なくとも基づいて潜在的なセグメント番号を決定することができる。
決定ブロック1612において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、潜在的なセグメント番号が現在の期間および表現結合のセグメント境界に対応するかどうかを決定することができる。期間の境界は、MPDのperiod@start属性またはperiod@duration属性のいずれかに基づいて、または次の期間開始属性と現在の期間開始属性との間の差を決定することによって、決定され得る。このようにして、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメント番号が現在の期間の境界内のセグメントに対応することを検証することができる。
セグメント番号が現在の期間の境界内にないとの決定(すなわち、決定ブロック1612=「No」)に応じて、ブロック1614において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の次の期間および表現結合を見つけ、次の期間および表現結合を現在の期間および表現結合として設定することができる。何のマッチも見つからない可能性がある場合、手順は失敗し、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、いずれかの調整をMPDに適用しないこと、またはある調整としてマージンMをASTに単に加えることのいずれかが可能である。
セグメント番号が現在の期間の境界内にあるとの決定(すなわち、決定ブロック1612=「Yes」)に応じて、ブロック1616において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントに関するセグメントインデックスを潜在的なセグメント番号に等しく設定することができる。
図17A、図17B、および図17Cは、一実施形態による例示的なMPD1700の要素のブロック図である。図17A、図17B、および図17Cに示すように、MPDをクロールして、期間および表現結合を識別するにつれて、MPDの重要な属性はマルチキャストサービスデバイスクライアントまたはクライアントアプリケーションによって識別され得る。これらの重要な要素は、利用可能開始時間、メディアプレゼンテーション持続時間、期間、期間開始、期間持続時間、期間ベースURL、期間セグメントテンプレート、適応セット、適応セットベースURL、適応セットセグメントテンプレート、表現、表現識別子、表現帯域幅、表現ベースURL、および表現セグメントテンプレートを含み得る。
図18は、一実施形態による例示的なMPD1800のXMLツリーのブロック図である。図18に示すように、MPD1800は、複数の期間、適応セット、および表現を含み得る。様々な実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、各期間からそのそれぞれの適応セットに、かつそれらの適応の各それぞれの表現にツリーの各リーフに沿って連続的にMPD1800のXMLツリーをクロールすることができる。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD1800をクロールするにつれて、テンプレート「xxx$number$yyy」にマッチするURLのベース部分など、URLを識別して、受信されたセグメントのURLに対するマッチを決定することができる。
図19は、一実施形態によるセグメントの利用可能性タイムラインを示す。具体的には、図19は、受信機デバイス上のセグメントの実際の利用可能開始時間にわたる、その関連するMPD内に列挙されたビデオサービス表現(R1)のセグメントの利用可能開始時間を示す。図19に示すように、単一のセグメント持続時間ビデオサービスは、0.5秒の短い持続時間セグメントで終了する第1の期間S36を有し得る。セグメントS1が1秒で期間1に利用可能になると仮定すると、セグメントS36は36秒で期間1に利用可能になり得る。セグメントS36および期間1の利用可能終了時間は、その場合、セグメントS36に対する0.5秒のセグメント持続時間に基づいて、36.5秒であり得る。
図20は、各々が、各々、その独自の表現1を有する、その独自のそれぞれの適応セット1および2を有する期間1および2を示す一実施形態による単一のセグメント持続時間MPD2000の1つの例示的なスキーマ部分である。MPDは、図19に示すタイムラインごとのセグメントの利用可能開始を示す。
図21は、一実施形態による、図20に示したMPD2000をクロールし、期間および表現結合内のURLをマッチさせた様々な結果を示すブロック図である。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURL2102が「/video150000/0/chunk_41.mp4」であると決定し、URL2102を期間および表現結合2106にマッチさせて、マッチを見つけることを試行することができる。期間2適応セット1表現1に対する期間および表現結合はURL2102にマッチし得るが、これは帯域幅15000がマッチし得、id 0がURL2102内の要素にマッチし得るためである。セグメントの利用可能開始時間は、利用可能開始時間が、36.5秒から無限大の期間境界内にあり得る37.5秒になり得るように、期間の開始時間35.5秒+1000msのセグメント持続時間+セグメントインデックスN=41-セグメント開始番号40として決定され得る。このようにして、マッチは有効であり得、受信されたセグメントに関するセグメントインデックスは41と確認され得る。
図22は、複数のセグメント持続時間がMPD内に記述される一実施形態による、セグメントの利用可能性タイムラインを示す。コンテンツは、2つの表現、すなわち、1秒のセグメント持続時間を有する第1の表現(R1)および2秒のセグメント持続時間を有する第2の表現(R2)を有し得る。具体的には、図22は、受信機デバイス上のセグメントの実際の利用可能開始時間にわたる、その関連するMPD内に列挙された、表現R1およびR2のセグメントの利用可能開始時間を示す。図22に示すように、表現R1またはR2の第1のセグメントの利用可能開始時間は、そのセグメントが属し得る表現に関するセグメント持続時間に依存する。これらの表現のうちの1つは、1つのサービスエリア内で任意の所与の時点でブロードキャストされることが予想され得る。
図23は、期間1および2を示す一実施形態による、各々が、各々、それぞれ異なるセグメント持続時間、すなわち、1秒および2秒を有する2つの表現0および1を有するその独自のそれぞれの適応セット1を有し、2つのセグメント持続時間MPD2300のある例示的なスキーマ部分である。この例示的なMPDは図22に示したタイムラインに対応する。
図24は、一実施形態による、図23に示したMPD2300をクロールし、期間および表現結合内のURLをマッチさせた様々な結果を示すブロック図である。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントのURL2402が「/audio30000/1/chunk_6.mp4」であると決定し、URL2402を期間および表現結合2406にマッチさせて、マッチを見つけることを試行することができる。期間2適応セット1表現2に対する期間および表現結合はURL2402をマッチさせることができるが、これは帯域幅30000がマッチすることができ、id 1がURL2402内の要素にマッチし得るためである。セグメントの利用可能開始時間は、利用可能開始時間が、10秒から無限大の期間境界内にあり得る12秒になり得るように、期間の開始時間8秒+2000msのセグメント持続時間+セグメントインデックスN=6-開始セグメント番号5の開始時間として決定され得る。このようにして、マッチは有効であり得、受信されたセグメントに関するセグメントインデックスは6と確認され得る。
図25は、2つ以上の期間および表現結合がセグメントのURLにマッチし、セグメントに関する有効な境界を有するとき、URLマッチングによってセグメントインデックスを決定するための一実施形態の方法2500を示す。たとえば、図26の利用可能性タイムラインにおいて示すように、いくつかのサービスは、広告など、反復セグメントを含む場合があり、A3などの反復セグメントが受信されるとき、セグメントURLは2つ以上の期間および表現結合のURLを有効な期間にマッチさせることができる。最良の候補マッチング期間および表現結合を選択するために、方法2500の動作は、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションが、最小AST変更をもたらす期間および表現結合に対応するセグメント番号としてセグメント番号を選択することを可能にし得る。一実施形態では、方法2500の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2500の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。様々な実施形態では、方法2500の動作は、それぞれ、図5Aおよび図5Bを参照して上記で説明した方法500aまたは500bの動作とともに実行され得る。たとえば、方法2500の動作は、MPDの受信(図5Aまたは図5Bのブロック502)およびセグメントフラグメントの受信(図5Aまたは図5Bのブロック504)の後、かつセグメントインデックス変更が生じたかどうかの決定(図5Aまたは図5Bのブロック506)の前に実行され得る。
ブロック1602〜1612において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図16を参照して上記で説明した方法1600の同様に番号付けされたブロックの動作を実行することができる。潜在的なセグメント番号が現在の期間および表現結合のセグメント境界内になるとの決定(すなわち、決定ブロック1612=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、ブロック2502において、現在の期間および表現結合および潜在的なセグメント番号を考えられるマッチとして記憶することができる。
決定ブロック2504において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD全体がクロールされているかどうかを決定することができる。MPD全体がクロールされていないとの決定(すなわち、決定ブロック2504=「No」)に応じて、ブロック1614において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDをクロールして、MPD内の次の期間および表現結合を見つけ、次の期間および表現結合を現在の期間および表現結合として設定することができる。
MPD全体がクロールされているとの決定(すなわち、決定ブロック2504=「Yes」)に応じて、ブロック2506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、すべての考えられる記憶されたマッチから生じるAST変更を決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントの受信から生じるASTを計算することができる。セグメントの受信から生じるASTは、図5A〜図15Bのうちのいずれかを参照して上記で説明した方法、または任意の他の方法に基づいてなど、任意の方法で計算され得る。たとえば、セグメントインデックス変更が生じると、方法2500は、ブロック2506の一部として、図5Aまたは図5Bの手順を適用して、MPDタイムライン修正を決定することができる。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次いで、各考えられる記憶されたマッチに関する元のASTをセグメントの受信から生じた計算されたASTから減じて、各考えられる記憶されたマッチに関して生じるAST変更を決定することができる。
ブロック2508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントに関するセグメントインデックスをAST内の最小変更を伴う考えられるマッチの潜在的なセグメント番号に等しく設定することができる。たとえば、各個々の考えられる記憶されたマッチに関して決定されたAST変更を一緒に比較することによって、決定された最小AST変更を識別することができ、受信されたセグメントに関するセグメントインデックスは、識別された、決定された最小AST変更を伴う考えられるマッチに関連するセグメントインデックスであり得る。このようにして、ブロック2508において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPD内の既存のタイムラインに対してより小さい時間修正をもたらすMPDタイムライン調整(たとえば、最小AST変更をもたらすMPDタイムライン調整)を選択することができる。一実施形態では、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、利用可能開始時間内に最小変更(すなわち、最小利用可能開始時間変更)をもたらす遅延調整値を記憶することができる。
図27は、URLマッチングに基づいて、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法2700を示す。一実施形態では、方法2700の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2700の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
ブロック2702において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、URLマッチングによって受信されたセグメントのセグメントインデックスを決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、それぞれ、図16および図25を参照して上記で説明した方法1600または方法2500の動作を実行して、URLマッチングによってセグメントインデックスを決定することができる。
ブロック2704において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、マッチング期間および表現結合に基づいて、決定されたセグメントインデックスを有するセグメントに関するMPDごとの利用可能開始時間(AvailPerMPD)を決定することができる。ブロック2706において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、MPDからセグメント持続時間(SD)を決定することができる。ブロック2708において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントに関する復号時間(DT)を決定することができる。復号時間(DT)は、セグメントが受信機デバイス上で実際に利用可能になる時間であり得る。
決定ブロック2710において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、復号時間(DT)-MPDごとの利用可能開始時間(AvailPerMPD)がセグメント持続時間(SD)の0.5倍よりも大きいかどうかを決定することができる。セグメント持続時間の半分(たとえば、0.5*SD)として示されるが、復号時間(DT)-MPDごとの利用可能開始時間(AvailPerMPD)がセグメント持続時間(SD)の0.5倍よりも大きいかどうかを決定することは、復号時間(DT)とMPDごとの利用可能開始時間(AvailPerMPD)との間の差を比較することができるしきい値の単なる1つの例示的な比較である。本明細書で論じるセグメント持続時間(SD)の0.5倍のしきい値に対して、1*SD、.6*SD、.9*SDなど、セグメント持続時間の比率、またはセグメント持続時間の任意の他の比率としての固定値のしきい値またはしきい値セットを含めて、他のしきい値を代用することができる。DT-AvailPerMPDが0.5*SDより大きくないとの決定(すなわち、決定ブロック2710=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、何のタイミングドリフトも生じなかったと決定することができ、ブロック2712において何の措置も講じなくてよい。係数(0.5など)がデバイス上に準備され得るか、またはネットワークによってブロードキャストされた構成ファイルの一部として受信され得る。
DT-AvailPerMPDが0.5*SDより大きいとの決定(すなわち、決定ブロック2710=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、タイミングドリフトが生じたと決定し、図11Bを参照して上記で説明したように、ブロック1112において、利用可能開始時間の再計算をトリガすることができる。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションはまた、MPDが修正されていることをアプリケーションに通知することができる。
図28は、URLマッチングに基づいて、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法2800を示す。方法2800は、セグメントインデックス変更に応じて、利用可能開始時間の再計算がトリガされ得ることを除いて、図27を参照して上記で説明した方法2700と同様である。一実施形態では、方法2800の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2800の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
ブロック2702において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明した方法2700の同様に番号付けされたブロックの動作を実行することができる。決定ブロック506において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図5Aを参照して上記で説明したように、セグメントインデックス変更が生じたかどうかを決定することができる。セグメントインデックスが変更されていないとの決定(すなわち、決定ブロック506=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明したように、ブロック2712において何の措置も講じなくてよい。
セグメントインデックスが変更されたとの決定(すなわち、決定ブロック506=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明した方法2700の同様に番号付けされたブロック2704、2706、2708、2710、2712、および1112の動作を実行することができる。
図29は、URLマッチングに基づいて、受信機デバイスのタイミングドリフトを考慮するための一実施形態の方法2900を示す。AST変更が、1つのセグメント持続時間など、しきい値を超えることになるとの決定に応じて、利用可能開始時間再計算がトリガされ得ることを除いて、方法2900は、図27を参照して上記で説明した方法2700と同様である。一実施形態では、方法2900の動作は、スマートフォンのような、受信機デバイスのプロセッサ上で実行されるマルチキャストサービスデバイスクライアントによって実行され得る。別の実施形態では、方法2900の動作は、受信機デバイスのプロセッサ上で実行される、DASHクライアントのようなクライアントアプリケーションによって実行され得る。
ブロック2702において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明した方法2700の同様に番号付けされたブロックの動作を実行することができる。
ブロック2902において、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、受信されたセグメントから生じたAST変更を決定することができる。たとえば、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、セグメントの受信から生じるASTを計算することができる。セグメントの受信から生じるASTは、図5A〜図15Bのうちのいずれかを参照して上記で説明した方法、または任意の他の方法に基づいてなど、任意の方法で計算され得る。マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、次いで、セグメントに関する元のASTをセグメントの受信から生じる計算されたASTから減じて、セグメントから生じるAST変更を決定することができる。
決定ブロック2904において、プロセッサは、AST変更がしきい値よりも大きいかどうかを決定することができる。しきい値は、受信機デバイスのメモリ内に記憶された値であってよく、セグメント持続時間に等しい、1つのセグメント持続時間に満たない、1つのセグメント持続時間を超えるなど、(事前に準備された、ユーザ定義可能な、MPD内で定義されるなど)任意の値であってよい。AST変更がしきい値以下であるとの決定(すなわち、決定ブロック2904=「No」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明したように、ブロック2712において、何の措置も講じなくてよい。AST変更がしきい値より大きいとの決定(すなわち、決定ブロック2904=「Yes」)に応じて、マルチキャストサービスデバイスクライアントまたはクライアントアプリケーションは、図27を参照して上記で説明したように、ブロック1112において、利用可能開始時間再計算をトリガすることができる。
様々な実施形態では、図27、図28、および図29を参照して上記で説明した方法2700、2800、および2900の動作は、それぞれ、一定の時間間隔または一定のセグメント計数間隔において周期的に適用され得る。
様々な実施形態(限定はしないが、図3A〜図29を参照して上記で説明した実施形態を含む)は、様々なモバイルデバイス(すなわち、受信機デバイス)のいずれかにおいて実装されてよく、その一例が図30に示される。たとえば、モバイルデバイス3000は、タッチスクリーンコントローラ3004および内部メモリ3002に結合されたプロセッサ3001を含み得る。プロセッサ3001は、汎用または特定の処理タスクに対して指定された1つまたは複数のマルチコア集積回路(IC)であってよい。内部メモリ3002は、揮発性メモリまたは不揮発性メモリであってよく、またセキュアメモリおよび/もしくは暗号化メモリ、または非セキュアメモリおよび/もしくは非暗号化メモリ、あるいはそれらの任意の組合せであってもよい。タッチスクリーンコントローラ3004およびプロセッサ3001は、抵抗感知タッチスクリーン、静電容量感知タッチスクリーン、赤外線感知タッチスクリーンなどのタッチスクリーンパネル3012にも結合され得る。モバイルコンピューティングデバイス3000は、1つまたは複数の無線信号トランシーバ3008(たとえば、Peanut(登録商標)、Bluetooth(登録商標)、Zigbee(登録商標)、Wi-Fi、RF、セルラーなど)と、互いにおよび/またはプロセッサ3001に結合された、送受信するためのアンテナ3010とを有し得る。トランシーバ3008およびアンテナ3010は、様々なワイヤレス送信プロトコルスタックおよびインターフェースを実装するために、上述の回路とともに使用され得る。モバイルコンピューティングデバイス3000は、セルラーネットワークを介した通信を可能にし、プロセッサに結合されたセルラーネットワークワイヤレスモデムチップ3016を含み得る。モバイルコンピューティングデバイス3000は、プロセッサ3001に結合された周辺デバイス接続インターフェース3018を含み得る。周辺デバイス接続インターフェース3018は、1つのタイプの接続を受け入れるように単独で構成され得るか、あるいはUSB、FireWire、Thunderbolt、またはPCIeなどの、共通またはプロプライエタリの様々なタイプの物理接続および通信接続を受け入れるように複合的に構成され得る。周辺デバイス接続インターフェース3018はまた、同様に構成された周辺デバイス接続ポート(図示せず)に結合され得る。モバイルコンピューティングデバイス3000はまた、オーディオ出力を提供するためのスピーカー3014を含み得る。モバイルコンピューティングデバイス3000はまた、本明細書で論じる構成要素のうちのすべてまたはいくつかを収容するための、プラスチック、金属、または材料の組合せで構成されたハウジング3020を含み得る。モバイルコンピューティングデバイス3000は、使い捨てバッテリーまたは充電式バッテリーなどの、プロセッサ3001に結合された電源3022を含み得る。充電式バッテリーはまた、モバイルコンピューティングデバイス3000の外部にあるソースから充電電流を受けるために周辺デバイス接続ポートに結合され得る。
様々な実施形態(限定はしないが、図3A〜図29を参照しながら上記で説明した実施形態を含む)はまた、図31に示すサーバ3100などの様々な市販のサーバデバイスのいずれかで実装されてよい。そのようなサーバ3100は、通常、揮発性メモリ3102、およびディスクドライブ3104などの大容量の不揮発性メモリに結合されたプロセッサ3101を含む。サーバ3100はまた、プロセッサ3101に結合された、フロッピーディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ3106を含む場合がある。サーバ3100はまた、他の告知システムコンピュータおよびサーバに結合されたローカルエリアネットワーク、インターネット、公衆交換電話網、ならびに/またはセルラーネットワーク(たとえば、CDMA、TDMA、GSM（登録商標）、PCS、3G、4G、LTE、または任意の他のタイプのセルラーネットワーク)などの通信ネットワーク3107とのネットワークインターフェース接続を確立するためにプロセッサ3101に結合された、ネットワークアクセスポートなどの1つまたは複数のネットワークトランシーバ3103を含み得る。
プロセッサ3001および3101は、上記で説明した様々な実施形態の機能を含む様々な機能を実行するようにソフトウェア命令(アプリケーション)によって構成され得る任意のプログラマブルマイクロプロセッサ、マイクロコンピュータ、または1つもしくは複数の多重プロセッサチップであってよい。いくつかのデバイスでは、ワイヤレス通信機能専用の1つのプロセッサ、および他のアプリケーションの実行専用の1つのプロセッサなどの、複数のプロセッサが設けられてもよい。通常、ソフトウェアアプリケーションは、それらがアクセスされプロセッサ3001および3101にロードされる前に、内部メモリ内に記憶され得る。プロセッサ3001および3101は、アプリケーションソフトウェア命令を記憶するのに十分な内部メモリを含み得る。多くのデバイスでは、内部メモリは、揮発性メモリ、もしくはフラッシュメモリなどの不揮発性メモリ、またはその両方の混合物であってよい。この説明の目的のために、メモリへの一般的な言及は、内部メモリ、またはデバイスに差し込まれるリムーバブルメモリ、ならびにプロセッサ3001および3101自体の中のメモリを含む、プロセッサ3001および3101によってアクセス可能なメモリを指す。
前述の方法の説明およびプロセスフロー図は、例示的な例として与えられるにすぎず、様々な実施形態のステップが、提示された順序で実行されなければならないことを要求または示唆するものではない。当業者なら諒解するように、上記の実施形態におけるステップの順序は、任意の順序で実行されてよい。「その後」、「次いで」、「次に」などの単語は、ステップの順序を限定するものではなく、これらの単語は単に、方法の説明を通じて読者を案内するために使用される。さらに、たとえば、冠詞「a」、「an」または「the」を使用する、単数形での請求項の要素へのいかなる言及も、要素を単数形に限定するものとして解釈されるべきではない。
本明細書で開示した実施形態に関して説明した様々な例示的な論理ブロック、モジュール、回路、およびアルゴリズムステップは、電子ハードウェア、コンピュータソフトウェア、または両方の組合せとして実装され得る。ハードウェアとソフトウェアのこの互換性を明確に示すために、様々な例示的な構成要素、ブロック、モジュール、回路、およびステップが、概してそれらの機能性に関して上記で説明された。そのような機能がハードウェアとして実装されるか、またはソフトウェアとして実装されるかは、特定の適用例およびシステム全体に課される設計制約に依存する。当業者は、説明した機能を特定のアプリケーションごとに様々な方法で実装し得るが、そのような実装決定は、本発明の範囲からの逸脱を引き起こすものと解釈されるべきではない。
本明細書で開示された態様に関して説明した様々な例示的な論理、論理ブロック、モジュール、および回路を実装するために使用されるハードウェアは、汎用プロセッサ、デジタル信号プロセッサ(DSP)、特定用途向け集積回路(ASIC)、フィールドプログラマブルゲートアレイ(FPGA)もしくは他のプログラマブル論理デバイス、個別ゲートもしくはトランジスタ論理、個別ハードウェア構成要素、または本明細書で説明する機能を実施するように設計されたそれらの組合せを用いて実装または実行され得る。汎用プロセッサはマイクロプロセッサであってよいが、代替として、プロセッサは、任意の従来のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであってもよい。プロセッサはまた、コンピューティングデバイスの組合せ、たとえば、DPCとマイクロプロセッサの組合せ、複数のマイクロプロセッサ、DPCコアと連携した1つもしくは複数のマイクロプロセッサ、または任意の他のそのような構成として実装されてよい。代替的に、いくつかのステップまたは方法は、所与の機能に専用の回路構成によって実行されてよい。
1つまたは複数の例示的な態様では、説明する機能は、ハードウェア、ソフトウェア、ファームウェア、またはそれらの任意の組合せで実装され得る。ソフトウェアで実装される場合、機能は、非一時的コンピュータ可読媒体上または非一時的プロセッサ可読媒体上の1つまたは複数のプロセッサ実行可能命令またはコードとして記憶されてもよい。本明細書で開示した方法またはアルゴリズムのステップは、非一時的コンピュータ可読またはプロセッサ可読記憶媒体上に存在し得るプロセッサ実行可能ソフトウェアモジュールにおいて具現化され得る。非一時的サーバ可読記憶媒体、非一時的コンピュータ可読記憶媒体、または非一時的プロセッサ可読記憶媒体は、コンピュータまたはプロセッサによってアクセスされ得る任意の記憶媒体であってよい。限定ではなく例として、そのような非一時的サーバ可読媒体、非一時的コンピュータ可読媒体、または非一時的プロセッサ可読媒体は、RAM、ROM、EEPROM、フラッシュメモリ、CD-ROMもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気記憶デバイス、または命令もしくはデータ構造の形態で所望のプログラムコードを記憶するために使用され得るとともにコンピュータによってアクセスされ得る任意の他の媒体を含み得る。ディスク(disk)およびディスク(disc)は、本明細書で使用するとき、コンパクトディスク(disc)(CD)、レーザーディスク（登録商標）(disc)、光ディスク(disc)、デジタル多用途ディスク(disc)(DVD)、フロッピーディスク(disk)、およびBlu-ray(登録商標）ディスク(disc)を含み、ディスク(disk)は、通常、データを磁気的に再生し、ディスク(disc)は、データをレーザーで光学的に再生する。上記の組合せも、非一時的サーバ可読媒体、非一時的コンピュータ可読媒体、および非一時的プロセッサ可読媒体の範囲内に含まれる。追加として、方法またはアルゴリズムの動作は、コンピュータプログラム製品に組み込まれ得る、非一時的サーバ可読媒体、非一時的プロセッサ可読媒体、および/または非一時的コンピュータ可読媒体上のコードおよび/または命令の1つまたは任意の組合せまたはセットとして存在してもよい。
開示された実施形態の前述の説明は、いかなる当業者も本発明を作成または使用することができるように記載されている。これらの実施形態に対する様々な変更は当業者には容易に明らかとなり、本明細書で定義した一般原理は、本発明の趣旨または範囲から逸脱することなく、他の実施形態に適用され得る。したがって、本発明は、本明細書に示す実施形態に限定されるものではなく、以下の特許請求の範囲、ならびに本明細書で開示する原理および新規の特徴と一致する最も広い範囲を与えられるべきである。
100 セルラーネットワークシステム
102 受信機デバイス
104 セルラータワーまたは基地局
106 セルラー接続
108 サーバ
110 インターネット
112 サーバ
202 受信機デバイス
204 アプリケーション/DASHクライアント
206 マルチキャストサービスデバイスクライアント(MSDC)
208 モデムレイヤ
302 エンコーダ
304 BMSC
306 マルチキャストサービスデバイスクライアント
308 DASHクライアント
310 MPD
312 MPD
314 MPD
400 ネットワーク
402 エンコーダ
404 セグメンタ
406 ネットワーク、第1の部分、ネットワーク部分、部分
408 ネットワーク、第2の部分、ネットワーク部分、部分
410 受信機デバイス1
412 受信機デバイス2
500a 方法
500b 方法
600a 方法
600b 方法
800a 方法
800b 方法
1000 方法
1100a 方法
1100b 方法
1300 方法
1400 方法
1500a 方法
1500b 方法
1600 方法
1170 MPD
1180 MPD
2000 MPD
2102 URL
2106 期間および表現結合
2402 URL
2406 期間および表現結合
2300 MPD
2500 方法
2700 方法
2800 方法
2900 方法
3000 モバイルデバイス
3001 プロセッサ
3002 内部メモリ
3004 タッチスクリーンコントローラ
3008 無線信号トランシーバ
3010 アンテナ
3012 タッチスクリーンパネル
3014 スピーカー
3016 セルラーネットワークワイヤレスモデムチップ
3018 周辺デバイス接続インターフェース
3020 ハウジング
3022 電源
3100 サーバ
3101 プロセッサ
3102 揮発性メモリ
3103 ネットワークトランシーバ
3104 ディスクドライブ
3106 フロッピーディスクドライブ、コンパクトディスク(CD)またはDVDディスクドライブ

Claims (16)

  1. 受信機デバイスのタイミングドリフトを考慮するための方法であって、
    ユニフォームリソース識別子(URL)マッチングによってセグメントのインデックスを決定するステップと、
    利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの利用可能開始時間を決定するステップと、
    前記利用可能性タイムラインからセグメント持続時間を決定するステップと、
    前記セグメントに関する復号時間を決定するステップと、
    前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを決定するステップと、
    前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガするステップと
    を含む、方法。
  2. 前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを前記決定するステップが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の比率よりも大きいかどうかを決定するステップを含み、
    前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始開始時間の再計算を前記トリガするステップが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の前記比率よりも大きいとの決定に応じて、前記利用可能開始開始時間の再計算をトリガするステップを含む
    請求項1に記載の方法。
  3. 前記セグメント持続時間の前記比率が2分の1である、請求項2に記載の方法。
  4. 前記受信機デバイスにおいて2つの受信されたセグメントフラグメント間でセグメントインデックス変更が生じるかどうかを決定するステップをさらに含み、
    前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を前記決定するステップが、前記受信機デバイスにおける前記2つの受信されたセグメントフラグメント間で前記セグメントインデックス変更が生じたとの決定に応じて、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を決定するステップを含む
    請求項1に記載の方法。
  5. 前記利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項4に記載の方法。
  6. 受信機デバイスのタイミングドリフトを考慮するための方法であって、
    ユニフォームリソース識別子(URL)マッチングによって、受信されたセグメントに関するセグメントインデックスを決定するステップと、
    前記受信されたセグメントから生じる利用可能開始時間の変更を決定するステップと、
    前記利用可能開始時間の前記変更がしきい値よりも大きいかどうかを決定するステップと、
    前記利用可能開始時間の前記変更が前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガするステップと
    を含む、方法。
  7. 前記しきい値がセグメント持続時間である、請求項6に記載の方法。
  8. 利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項7に記載の方法。
  9. 受信機デバイスであって、
    動作を実行するためのプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作が、
    ユニフォームリソース識別子(URL)マッチングによってセグメントのインデックスを決定することと、
    利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの利用可能開始時間を決定することと、
    前記利用可能性タイムラインからセグメント持続時間を決定することと、
    前記セグメントに関する復号時間を決定することと、
    前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを決定することと、
    前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることと
    を含む、受信機デバイス。
  10. 前記プロセッサが、
    前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものがしきい値よりも大きいかどうかを前記決定することが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の比率よりも大きいかどうかを決定することを含み、
    前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算を前記トリガすることが、前記セグメントに関する前記復号時間から前記セグメントの前記利用可能開始時間を減じたものが前記セグメント持続時間の前記比率よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることを含む
    ような動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載の受信機デバイス。
  11. 前記セグメント持続時間の前記比率が2分の1である、請求項10に記載の受信機デバイス。
  12. 前記プロセッサが、2つの受信されたセグメントフラグメント間でセグメントインデックス変更が生じるかどうかを決定することをさらに含む動作を実行するためのプロセッサ実行可能命令で構成され、
    前記プロセッサが、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を前記決定することが、前記2つの受信されたセグメントフラグメント間で前記セグメントインデックス変更が生じたとの決定に応じて、前記利用可能性タイムライン内のマッチング期間および表現結合に基づいて、前記セグメントの前記利用可能開始時間を決定することを含むような動作を実行するためのプロセッサ実行可能命令で構成される、請求項9に記載の受信機デバイス。
  13. 前記利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項12に記載の受信機デバイス。
  14. 受信機デバイスであって、
    動作を実行するためのプロセッサ実行可能命令で構成されたプロセッサを備え、前記動作が、
    ユニフォームリソース識別子(URL)マッチングによって、受信されたセグメントに関するセグメントインデックスを決定することと、
    前記受信されたセグメントから生じる利用可能開始時間の変更を決定することと、
    前記利用可能開始時間の前記変更がしきい値よりも大きいかどうかを決定することと、
    前記利用可能開始時間の前記変更が前記しきい値よりも大きいとの決定に応じて、前記利用可能開始時間の再計算をトリガすることと
    を含む、受信機デバイス。
  15. 前記しきい値がセグメント持続時間である、請求項14に記載の受信機デバイス。
  16. 利用可能性タイムラインが、動的適応ストリーミングオーバーハイパーテキスト転送プロトコル(DASH)メディアプレゼンテーション記述(MPD)である、請求項15に記載の受信機デバイス。
JP2017554447A 2015-04-20 2016-02-26 Ｄａｓｈオーバーブロードキャストをサポートするためのさらなるデバイスタイミング調整および方法 Pending JP2018519694A (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562149776P 2015-04-20 2015-04-20
US62/149,776 2015-04-20
US14/812,535 US20160308927A1 (en) 2015-04-20 2015-07-29 Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast
US14/812,535 2015-07-29
PCT/US2016/019795 WO2016171793A1 (en) 2015-04-20 2016-02-26 Further device timing adjustments and methods for supporting dash over broadcast

Publications (1)

Publication Number Publication Date
JP2018519694A true JP2018519694A (ja) 2018-07-19

Family

ID=57129070

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2017554462A Pending JP2018519695A (ja) 2015-04-20 2016-02-26 Ｄａｓｈオーバーブロードキャストをサポートするためのさらなるデバイスタイミング調整および方法
JP2017554447A Pending JP2018519694A (ja) 2015-04-20 2016-02-26 Ｄａｓｈオーバーブロードキャストをサポートするためのさらなるデバイスタイミング調整および方法

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2017554462A Pending JP2018519695A (ja) 2015-04-20 2016-02-26 Ｄａｓｈオーバーブロードキャストをサポートするためのさらなるデバイスタイミング調整および方法

Country Status (5)

Country Link
US (3) US20160308927A1 (ja)
EP (2) EP3286902A1 (ja)
JP (2) JP2018519695A (ja)
CN (2) CN107534680A (ja)
WO (3) WO2016171792A1 (ja)

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10440084B2 (en) * 2013-02-06 2019-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Technique for detecting an encoder functionality issue
US9998477B2 (en) 2015-03-31 2018-06-12 Comcast Cable Communications, Llc Digital content access control
US20160308927A1 (en) 2015-04-20 2016-10-20 Qualcomm Incorporated Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast
CN107710712B (zh) * 2015-06-19 2020-06-26 华为技术有限公司 一种集群通信方法、装置及设备
US9883249B2 (en) 2015-06-26 2018-01-30 Amazon Technologies, Inc. Broadcaster tools for interactive shopping interfaces
US10021458B1 (en) 2015-06-26 2018-07-10 Amazon Technologies, Inc. Electronic commerce functionality in video overlays
US10440436B1 (en) * 2015-06-26 2019-10-08 Amazon Technologies, Inc. Synchronizing interactive content with a live video stream
US9973819B1 (en) 2015-06-26 2018-05-15 Amazon Technologies, Inc. Live video stream with interactive shopping interface
US10152080B2 (en) 2015-09-23 2018-12-11 Adobe Systems Incorporated Power efficient multimedia content streaming based on media segment duration
US10158682B2 (en) * 2015-09-23 2018-12-18 Adobe Systems Incorporated Power efficient multimedia content streaming based on a server push
KR101916022B1 (ko) * 2015-10-06 2018-11-07 한국전자통신연구원 세그먼트 기반의 방송 콘텐츠 반복 전송 방법 및 장치
US10531146B2 (en) * 2017-06-02 2020-01-07 Mobitv, Inc. Lean private copy of media content within network-based digital video recordings
US10477286B2 (en) * 2017-06-19 2019-11-12 Wangsu Science & Technology Co., Ltd. Streaming media file processing method and live streaming system
US10652166B2 (en) * 2017-06-27 2020-05-12 Cisco Technology, Inc. Non-real time adaptive bitrate recording scheduler
JP6271072B1 (ja) * 2017-10-10 2018-01-31 パナソニック株式会社 端末装置、映像配信システムおよび映像配信方法
CN111031354B (zh) * 2019-12-09 2020-12-01 腾讯科技（深圳）有限公司 一种多媒体播放方法、装置及存储介质
US20230336604A1 (en) * 2020-03-24 2023-10-19 Telefonaktiebolaget Lm Ericsson (Publ) Devices and methods for provision of resource representations
US11490153B2 (en) * 2020-12-07 2022-11-01 Rovi Guides, Inc. Systems and methods for dynamically syncing from time-shifted frame to live stream of content
US11490167B2 (en) 2020-12-07 2022-11-01 Rovi Guides, Inc. Systems and methods for dynamically syncing from time-shifted frame to live stream of content
US11770588B2 (en) 2020-12-07 2023-09-26 Rovi Guides, Inc. Systems and methods for dynamically syncing from time-shifted frame to live stream of content
CN117478942A (zh) * 2022-07-20 2024-01-30 联发科技（新加坡）私人有限公司 流媒体播放方法和电子设备

Family Cites Families (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7583955B2 (en) * 2003-07-24 2009-09-01 Lg Electronics Inc. System for and method of reproducing multimedia contents in mobile communication terminal
US20060059256A1 (en) * 2004-09-10 2006-03-16 Nokia Corporation Signaling a state of a transmission link via a transport control protocol
CN101194453A (zh) * 2005-04-29 2008-06-04 诺基亚公司 用于动态地调整例如媒体接入控制（mac）层的协议层处的分段的方法、设备和计算机程序
US20070101394A1 (en) * 2005-11-01 2007-05-03 Yesvideo, Inc. Indexing a recording of audiovisual content to enable rich navigation
KR100946902B1 (ko) * 2006-05-06 2010-03-09 삼성전자주식회사 이동 통신 시스템에서 자원 운용 장치 및 방법
US9432433B2 (en) * 2006-06-09 2016-08-30 Qualcomm Incorporated Enhanced block-request streaming system using signaling or block creation
CA2842842C (en) * 2011-07-26 2020-09-15 United Parcel Service Of America, Inc. Systems and methods for assessing mobile asset efficiencies
US9590814B2 (en) * 2011-08-01 2017-03-07 Qualcomm Incorporated Method and apparatus for transport of dynamic adaptive streaming over HTTP (DASH) initialization segment description fragments as user service description fragments
US9253233B2 (en) * 2011-08-31 2016-02-02 Qualcomm Incorporated Switch signaling methods providing improved switching between representations for adaptive HTTP streaming
US9088583B2 (en) 2011-10-31 2015-07-21 Interdigital Patent Holdings, Inc. Method and apparatus for enabling multimedia synchronization
US8843596B2 (en) * 2011-11-30 2014-09-23 Adobe Systems Incorporated Conversion between streaming media communication protocols
US9503490B2 (en) * 2012-02-27 2016-11-22 Qualcomm Incorporated Dash client and receiver with buffer water-level decision-making
US8661491B1 (en) * 2012-08-02 2014-02-25 Ericsson Television Inc. Methods using base content and additive content and related client devices and network server devices
DK2920938T3 (en) 2012-11-13 2017-04-10 ERICSSON TELEFON AB L M (publ) MULTIMEDIA DATA PROCESSING
US9386062B2 (en) * 2012-12-28 2016-07-05 Qualcomm Incorporated Elastic response time to hypertext transfer protocol (HTTP) requests
US9426196B2 (en) 2013-01-04 2016-08-23 Qualcomm Incorporated Live timing for dynamic adaptive streaming over HTTP (DASH)
CN105075276B (zh) * 2013-01-11 2019-04-16 瑞典爱立信有限公司 在广播通信网络中操作客户端设备和服务器设备的技术
US10440084B2 (en) * 2013-02-06 2019-10-08 Telefonaktiebolaget Lm Ericsson (Publ) Technique for detecting an encoder functionality issue
CN103973662B (zh) * 2013-02-06 2017-06-20 华为技术有限公司 流媒体请求方法及控制器
US9438654B2 (en) 2013-04-18 2016-09-06 Futurewei Technologies, Inc. Fragment interface into dynamic adaptive streaming over hypertext transfer protocol presentations
CN105659614B (zh) * 2013-10-30 2019-09-03 索尼公司 内容供给设备、内容供给方法、程序、终端设备与内容供给系统
US20150172066A1 (en) * 2013-12-13 2015-06-18 Qualcomm Incorporated Practical implementation aspects of unicast fetch for http streaming over embms
KR102273757B1 (ko) * 2014-01-03 2021-07-06 엘지전자 주식회사 방송 신호를 송신하는 장치, 방송 신호를 수신하는 장치, 방송 신호를 송신하는 방법 및 방송 신호를 수신하는 방법
US9491239B2 (en) * 2014-01-31 2016-11-08 Comcast Cable Communications, Llc Methods and systems for processing data requests
KR101737849B1 (ko) * 2014-02-24 2017-05-19 엘지전자 주식회사 방송 신호 송신 장치, 방송 신호 수신 장치, 방송 신호 송신 방법, 및 방송 신호 수신 방법
CN103974147A (zh) * 2014-03-07 2014-08-06 北京邮电大学 一种基于mpeg-dash协议的带有码率切换控制和静态摘要技术的在线视频播控系统
US9706572B2 (en) * 2014-04-30 2017-07-11 Qualcomm Incorporated Techniques for obtaining and maintaining access to a wireless communication medium
US20160308927A1 (en) 2015-04-20 2016-10-20 Qualcomm Incorporated Further Device Timing Adjustments and Methods for Supporting DASH Over Broadcast

Also Published As

Publication number Publication date
US20160308927A1 (en) 2016-10-20
EP3286902A1 (en) 2018-02-28
WO2016171791A1 (en) 2016-10-27
WO2016171793A1 (en) 2016-10-27
WO2016171792A1 (en) 2016-10-27
US10051031B2 (en) 2018-08-14
CN107534680A (zh) 2018-01-02
US20160308928A1 (en) 2016-10-20
US20160308934A1 (en) 2016-10-20
CN107534663A (zh) 2018-01-02
JP2018519695A (ja) 2018-07-19
EP3254445A1 (en) 2017-12-13

Similar Documents

Publication Publication Date Title
JP2018519694A (ja) Ｄａｓｈオーバーブロードキャストをサポートするためのさらなるデバイスタイミング調整および方法
US20200128058A1 (en) Device timing adjustments and methods for supporting dash over broadcast
JP5588517B2 (ja) データセグメントのオプションのブロードキャスト配信によるストリーミング
JP6301456B2 (ja) サービスに関する多重ファイルデリバリオーバーユニディレクショナルトランスポートプロトコルセッション
JP2016504797A (ja) マルチメディアデータの処理
JP6655093B2 (ja) 部分的セグメント用の表示
US20160248829A1 (en) Availability Start Time Adjustment By Device For DASH Over Broadcast
CN107258085B (zh) 针对广播自适应比特率流式传输的延时补偿
JP2018514106A (ja) 部分的セグメント用の表示
US20160295245A1 (en) A method, node and computer programe for providing live content streaming
US10142385B2 (en) Multi-service initialization for adaptive media streaming
US8700900B2 (en) Communicating admission decisions and status information to a client
JP6009501B2 (ja) データセグメントのオプションのブロードキャスト配信によるストリーミング