JP2017517221A - Ｈｔｔｐストリーミングを使用するｄａｓｈストリーミングのための方法及び装置 - Google Patents

Ｈｔｔｐストリーミングを使用するｄａｓｈストリーミングのための方法及び装置 Download PDF

Info

Publication number
JP2017517221A
JP2017517221A JP2017500785A JP2017500785A JP2017517221A JP 2017517221 A JP2017517221 A JP 2017517221A JP 2017500785 A JP2017500785 A JP 2017500785A JP 2017500785 A JP2017500785 A JP 2017500785A JP 2017517221 A JP2017517221 A JP 2017517221A
Authority
JP
Japan
Prior art keywords
server
client device
streaming
http
processing circuit
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.)
Ceased
Application number
JP2017500785A
Other languages
English (en)
Inventor
イメド，ブアジジ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Samsung Electronics Co Ltd
Original Assignee
Samsung Electronics Co Ltd
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
Priority claimed from US14/661,668 external-priority patent/US20150271233A1/en
Application filed by Samsung Electronics Co Ltd filed Critical Samsung Electronics Co Ltd
Publication of JP2017517221A publication Critical patent/JP2017517221A/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H04L65/612—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio for unicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/1066—Session management
    • H04L65/1069—Session establishment or de-establishment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/75—Media network packet handling
    • H04L65/752—Media network packet handling adapting media to network capabilities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • 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/643—Communication protocols
    • H04N21/64322—IP
    • 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

Landscapes

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

Abstract

本発明は、クライアント装置がメディアストリーミングを受信するためにサーバと通信する。クライアント装置は、サーバがウェブソケットを通じて適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングをサポートするか否かを判定する。例えば、サーバは、ウェブソケットを通じて適応ＨＴＴＰストリーミングがサポートされるという指示を少なくとも一つのクライアント装置に伝送できる。クライアント装置は、ＨＴＴＰストリーミングの際に速度適応動作を実行するためにサーバに命令を伝送する。応答で、サーバは、ＨＴＴＰストリーミングの際に速度適応動作を遂行するためにクライアント装置から受信される命令に応答してクライアント装置と受信ウェブソケット接続を確立するステップを有する。クライアント装置は、トリガイベントが発生するまでメディアセグメントを継続して受信する。

Description

本発明は一般的に伝送システムでのメディアデータ配信に関するもので、より具体的には、プッシュベースの適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングに関する。
従来、伝送制御プロトコル(ＴＣＰ）は、オーディオ及びビデオコンテンツのようなリアルタイムメディアの配信に適合しないと見なされてきた。これは、主にＴＣＰを実現する再伝送手順及び攻撃的な混雑制御アルゴリズムのためである。ＴＣＰにおいて、送信器は、一般にパケット損失又は過度な伝送遅延を通じて認識される混雑イベントの検出時に伝送速度を大幅に(一般的に、半分に)減少させる。その結果、ＴＣＰの伝送スループットは、一般的によく知られている歯形状として特徴づけられる。ＴＣＰは、高信頼で混雑を意識した伝送のために配信遅延を犠牲にする一方、ストリーミングアプリケーションは遅延に敏感であるが、相対的に損失に対して耐性を有するため、このような特性は、ストリーミングアプリケーションに有害である。
最近、インターネットを介してマルチメディアコンテンツを配信するための好ましいプロトコルとしてのトレンドは、ハイパーテキスト転送プロトコル(ＨＴＴＰ）を使用する方向に変化している。ＨＴＴＰは、ＴＣＰの上位で実行され、テキスト形式プロトコルである。このような変化は、プロトコルの配置(deployment)が容易であることが寄与している。コンテンツを配信する専用サーバを使用する必要がない。さらに、ＨＴＴＰは、一般的にファイヤーウォール及びＮＡＴを通してアクセスできる権限が与えられ、これは、配置を大きく単純化する。
上記のような目的を達成するために、本発明の一態様によれば、装置が提供される。この装置は、サーバとの通信接続を確立するように構成されるアンテナを含む。また、装置は、ウェブソケット（ＷｅｂＳｏｃｋｅｔ）を通じて適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングをサポートするサーバの能力を決定し、ＨＴＴＰストリーミング中にストリーミングオペレーションを実行するようにサーバに命令を送信し、ストリーミングセッションでサーバから情報を受信するように構成される処理回路を含む。
本発明の他の態様によれば、サーバが提供される。このサーバは、ウェブソケットを通じて適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングがサポートされるという指示を少なくとも一つのクライアント装置に送信し、アップグレードに対するリクエストを受信し、このアップグレードを受諾するかあるいは拒否するかを判定し、ＨＴＴＰストリーミング中にストリーミングオペレーションを遂行するために少なくとも一つのクライアント装置から受信された命令に応答して少なくとも一つのクライアント装置と受信ウェブソケット接続を確立するように構成される処理回路を含む。
さらに、本発明の他の態様によれば、クライアント装置のための方法が提供される。この方法は、サーバとの通信接続を確立するステップを有する。また、この方法は、ウェブソケットを通じて適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングをサポートするサーバの能力を決定するステップを有する。さらに、この方法は、ＨＴＴＰストリーミング中にストリーミングオペレーションを実行するためにサーバに命令を伝送するステップを有する。
他の技術的特徴は、次の図面、記述、及び請求の範囲から当業者には明らかである。その他の技術的特徴は、下記の図面、詳細な説明、及び請求の範囲から当該技術分野における通常の知識を持つ者には明らかである。
本発明の詳細な説明に先立って、本明細書の全般にわたって使用される特定の単語及び語句の定義を説明することが好ましい。“接続（結合）する(couple)”という語句とその派生語は、２個以上の構成要素の間で、相互に物理的な接触状態にあるか否か、それら間の任意の直接的又は間接的通信を称する。“送信する(transmit)”、“受信する(receive)”、及び“通信する(communicate)”という用語だけでなく、その派生語は、直接的及び間接的な通信の両方ともを含む 。“含む（include）”及び “備える（comprise）”という語句だけではなく、その派生語（derivatives thereof）は、限定ではなく、含みを意味する。“又は（or）”という用語は、“及び／又は（and/or）”の意味を包括する。“関連した（associated with）”及び“それと関連した（associated therewith）”という語句だけではなく、その派生語句は、“含む（include）”、“含まれる（be included within）”、“相互に連結する（interconnect with）”、“包含する（contain）”、“包含される（be contained within）”、“接続する（connect to or with）”、“結合する（couple to or with）”、“疎通する（be communicable with）”、“協力する（cooperate with）”、“相互配置する（interleave）”、“並置する（juxtapose）”、“近接する（be proximate to）”、“接する（be bound to or with）”、“有する（have）”、及び“特性を有する（have a property of）”などを意味することができる。“制御部(controller)”は、少なくとも１つの動作を制御する装置、システム又はその部分を意味するもので、ハードウェア、ファームウェア、ソフトウェア、又は、それらのうちの２つ以上の組合せで実現することができる。ある特定の制御器に関連した機能性は、ローカルでも遠隔でも、集中するか又は分散することができることに留意しなければならない。“少なくとも一つの(at least one of)”という語句は、項目のリストとともに使用される時に、リストされた項目のうち一つ以上の異なる組み合せが使用され、そのリスト内の一つの項目のみが必要とされることができることを意味する。例えば、“Ａ、Ｂ、及びＣのうち少なくとも一つは、Ａ、Ｂ、Ｃ、Ａ及びＢ、Ａ及びＣ、Ｂ及びＣ、そしてＡとＢとＣ”のような組み合せのうちいずれか一つを含む。
さらに、以下に記述される様々な機能は、１つ以上のコンピュータプログラムにより具現されるか又はサポートされ、そのプログラムの各々は、コンピュータ読み取り可能なプログラムコードで構成され、コンピュータ読み取り可能な媒体で実施される。“アプリケーション”及び“プログラム”という用語は、一つ以上のコンピュータプログラム、ソフトウェアコンポーネント、命令語セット、手順、関数、オブジェクト、クラス、インスタンス、関連データ、又は適したコンピュータ読み取り可能なプログラムコードの実現に適合したそれらの一部を称する。“コンピュータ読み取り可能なプログラムコード”という語句は、ソースコード、オブジェクトコード、及び実行コードを含むすべてのタイプのコンピュータコードを含む。“コンピュータ読み取り可能な媒体”という語句は、ＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ハードディスクドライブ、ＣＤ（Compact Disc）、ＤＶＤ（Digital Video Disc）、又は任意の他のタイプのメモリのように、コンピュータによりアクセス可能なすべてのタイプの媒体を含む。“非一時的(non-transitory)”なコンピュータ読み取り可能な媒体は、一時的な電気又は他の信号を転送する有線、無線、光学、又は他の通信リンクを除外する。非一時的なコンピュータ読み取り可能な媒体は、データが永久的に記憶されることができる媒体、及び再記録可能な光学ディスクや削除可能なメモリ装置のようにデータが記憶され、後でオーバーライティングされ得る媒体を含む。
特定の用語及び語句は本明細書の全体で使用されるが、当業者は多くの場合に上述したような定義が過去だけでなく未来の使用にも適用されることを理解しなければならない。
本発明のより完全な理解及びそれに従う多くの利点は、添付された図面との結合を考慮すれば、後述する詳細な説明を参照してより容易に理解でき、上記図で同一の参照シンボルは同一又は類似した構成要素を示す。
本発明による例示的なコンピュータシステムを示す図である。 本発明によるコンピュータシステムの例示的な装置を示す図である。 本発明によるコンピュータシステムの例示的な装置を示す図である。 本発明の実施形態による適応ＨＴＴＰストリーミングアーキテクチャを示す図である。 本発明の実施形態によるＭＰＤ構造を示す図である。 本発明によるＨＴＴＰ１.０とＨＴＴＰ１.１との差を示す図である。 本発明によるＨＴＴＰ１.０とＨＴＴＰ１.１との差を示す図である。 本発明の実施形態によるウェブソケットサポートネットワークを示す図である。 本発明の実施形態によるクライアント装置にウェブソケットを使用する適応ＨＴＴＰストリーミングプロセスを示す図である。 本発明の実施形態によるサーバにウェブソケットを使用する適応ＨＴＴＰストリーミングプロセスを示す図である。
後述される図１〜図１０及び本願で本発明の原理を説明するために使用される多様な実施形態は、単にその実施例を示すものに過ぎず、本発明の範囲を限定するものとして捉えてはならない。本発明の原理が適切に配列された装置又はシステムで実現できることは、当該技術分野における通常の知識を有する者には明らかである。
図１は、本発明による例示的なコンピュータシステム１００を示す。図１に示すコンピュータシステム１００の実施形態は、単に例示のためのものである。本発明の範囲から逸脱することなく、コンピュータシステム１００の他の実施形態が使用され得る。
図１に示すように、システム１００は、システム１００の多様な構成要素間の通信を容易にするネットワーク１０２を含む。例えば、ネットワーク１０２は、ネットワークアドレスの間でインターネットプロトコル(ＩＰ)パケット、フレーム中継フレーム、非同期式転送モード(ＡＴＭ)セル、又は他の情報を通信できる。ネットワーク１０２には、一つ以上の近距離ネットワーク(ＬＡＮ)、大都市ネットワーク(ＭＡＮ)、広帯域ネットワーク(ＷＡＮ)、インターネットのようなグローバルネットワークの全部又は一部、又は一つ以上の位置にあるすべての他の通信システム又はシステムを含めることができる。
ネットワーク１０２は、少なくとも一つのサーバ１０４と多様なクライアント装置１０６-１１４との間の通信を容易にする。各々のサーバ１０４は、一つ以上のクライアント装置にコンピュータサービスを提供できるすべての適合したコンピュータ又は処理装置を含む。それぞれのサーバ１０４は、例えば一つ以上の処理装置、指示及びデータを格納する一つ以上のメモリ、及びネットワーク１０２を通じて通信を容易にする一つ以上のネットワークインターフェースを含むことができる。
各々のクライアント装置１０６-１１４は、ネットワーク１０２を介して少なくとも一つのサーバ又は他のコンピュータ装置と相互作用するすべての適合したコンピュータ又は処理装置である。この実施形態では、クライアント装置１０６-１１４は、デスクトップコンピュータ１０６、携帯電話又はスマートフォン１０８、個人携帯用情報端末(ＰＤＡ)１１０、ラップトップコンピュータ１１２、及びタブレットコンピュータ１１４を含む。しかしながら、すべての他の又は追加クライアント装置がコンピュータシステム１００で使用可能である。
この実施形態において、一部クライアント装置１０８−１１４は、ネットワーク１０２と間接通信する。例えば、クライアント装置１０８-１１０は、セルラー基地局又はｅＮｏｄｅＢのような一つ以上の基地局１１６を通じて通信する。また、クライアント装置１１２-１１４は、ＩＥＥＥ８０２.１１の無線アクセスポイントのような一つ以上の無線アクセスポイント１１８を通じて通信する。これらは、単に例示のためのもので、各々のクライアント装置は、ネットワーク１０２と直接に又はすべての適合した中間装置又はネットワークを介してネットワーク１０２と間接に通信できることに留意しなければならない。
より詳細に後述するように、ネットワーク１０２は、ＨＴＴＰを通じて効率的なプッシュベースのメディアストリーミングを容易にする。一つ以上のサーバ１０４は、ウェブソケットを通じてメディアストリーミングをサポートする。一つ以上のクライアント装置１０６-１１４は、サーバ１０４がウェブソケットを通じてメディアストリーミングをサポートするときに感知できる。サーバ１０４がウェブソケットを通じてメディアストリーミングをサポートする場合、一つ以上のクライアント装置１０６-１１４は、サーバにウェブソケット接続を確立してストリームでの位置及び選択されたリプレゼンテーションを表示する初期リクエストを提案できる。以後、それぞれのクライアント装置１０６-１１４は、サーバ１０４によりプッシュされるメディアセグメントを順次に受信する。
図１は、コンピュータシステム１００の一例を示すが、多様な変更が図１になされ得る。例えば、システム１００は、すべての適合した配置で各々の構成要素をいくらでも含むことができる。一般的に、コンピュータ及び通信システムは、多様な構成で提供され、図１は、任意の特定構成に本発明の範囲を限定しない。図１は、本願に開示される多様な特徴が使用される一つのオペレーティング環境を示すが、これら特徴は、すべての他の適合したシステムで使用できる。
図２及び図３は、本発明によるコンピュータシステムの例示的な装置を示す。特に、図２は例示的なサーバ２００を示し、図３は例示的なクライアント装置３００を示す。サーバ２００は、図１のサーバ１０４を示し、クライアント装置３００は図１のクライアント装置１０６-１１４のうち一つ以上を示す。
図２に示すように、サーバ２００は、少なくとも一つの処理装置２１０、少なくとも一つの格納装置２１５、少なくとも一つの通信ユニット２２０、及び少なくとも一つの入力/出力(Ｉ/Ｏ)ユニット２２５間の通信をサポートするバスシステム２０５を含む。サーバ１０４は、サーバ２００と同一又は類似に構成できる。サーバ２００は、ウェブソケットを通じてメディアストリーミングをサポートできる。
処理装置２１０は、メモリ２３０にローディングされる指示を実行する。処理装置２１０は、すべての適合した配置ですべての適合した個数及びタイプのプロセッサ又は他の装置を含む。例示的なタイプの処理装置２１０は、マイクロプロセッサ、マイクロ制御器、デジタル信号プロセッサ、フィールドプログラマブルゲートアレイ、特定アプリケーション集積回路、及び離散回路を含む。
メモリ２３０及び永続記憶装置(persistent storage)２３５は、(データ、プログラムコード、及び/又は一時的又は永久的な他の適合した情報のような)情報を格納して情報の検索を容易にする構成を示す格納装置２１５の例である。メモリ２３０は、ランダムアクセスメモリ又はすべての他の適合した揮発性又は非揮発性記憶装置とできる。永続記憶装置２３５は、読み取り専用メモリ、ハードドライブ、フラッシュメモリ、又は光ディスクのようにデータの長期格納をサポートする一つ以上の構成要素又は装置を含む。
通信ユニット２２０は、他のシステム又は装置との通信をサポートする。例えば、通信ユニット２２０は、処理回路、ネットワークインターフェースカード又はネットワーク１０２を介して通信を容易にする無線送受信器を含む。通信ユニット２２０は、すべての適合した物理的又は無線通信リンクを通じて通信をサポートできる。通信ユニット２２０は、一つ以上のクライアント装置に接続できる。すなわち、通信ユニット２２０は、少なくとも一つのクライアント装置に接続するように構成されるインターフェースを提供する。
Ｉ/Ｏユニット２２５は、データの入力及び出力を許容する。例えば、Ｉ/Ｏユニット２２５は、キーボード、マウス、キーパッド、タッチスクリーン、又は他の適合した入力装置を通じてユーザー入力のための接続を提供する。また、Ｉ/Ｏユニット２２５は、ディスプレイ、プリンタ、又は他の適合した出力装置に出力を伝送できる。
図２は図１のサーバ１０４を示すとされたが、同一又は類似の構造がクライアント装置１０６-１１４のうち一つ以上で使用されることに留意しなければならない。例えば、ラップトップ又はデスクトップコンピュータが図２に示す構造と同一であり、あるいは類似した構成を有することができる。
図３は、本発明による例示的なＳＴＡ３００を示す。図２に示したＳＴＡ３００の実施形態は、単に例示のためのものであり、図１のＳＴＡ１０４-１１２は、同一又は類似の構成を有することができる。しかしながら、ＳＴＡは、多様な構成で提供され、図３は、ＳＴＡの任意の特定実現で本発明の範囲を限定しない。
ＳＴＡ３００は、複数のアンテナ３０５ａ-３０５ｎ、複数の無線周波数(ＲＦ)送受信器３１０ａ-３１０ｎ、送信(ＴＸ)処理回路３１５、マイクロホン３２０、及び受信(ＲＸ)処理回路３２５を含む。ＴＸ処理回路３１５及びＲＸ処理回路３２５は、ＲＦ送受信器３１０ａ-３１０ｎの各々に、例えば、アンテナ３０５ａ、アンテナ３０５ｂ-Ｎ番目のアンテナ３０５ｎに各々接続されるＲＦ送受信器３１０ａ、ＲＦ送受信器３１０ｂ乃至Ｎ番目のＲＦ送受信器３１０ｎに各々接続される。特定の実施形態において、ＳＴＡ１０４は、一つのアンテナ３０５ａ及び一つのＲＦ送受信器３１０ａを含む。また、ＳＴＡ３００は、スピーカ３３０、メインプロセッサ３４０、入力/出力(Ｉ/Ｏ)インターフェース(ＩＦ)３４５、キーパッド３５０、ディスプレイ３５５、及びメモリ３６０を含む。メモリ２６０は、基本オぺレーティングシステム(ＯＳ)プログラム２６１及び一つ以上のアプリケーション２６２を含む。
ＲＦ送受信器３１０ａ-３１０ｎは、ネットワーク１００のＡＰ１０２により伝送される入力ＲＦ信号を各々のアンテナ３０５ａ-３０５ｎから受信する。ＲＦ送受信器３１０ａ-３１０ｎは、中間周波数(ＩＦ)又はベースバンド信号を生成するために入力ＲＦ信号をダウンコンバーティングする。ＩＦ又はベースバンド信号は、ベースバンド又はＩＦ信号をフィルタリング、復号化、及び/又はデジタル化することにより処理されたベースバンド信号を生成するＲＦ処理回路３２５に伝送される。ＲＸ処理回路３２５は、(ウェブブラウジングデータ向けのような)追加処理のためにメインプロセッサ３４０に又は(音声データむけのような)スピーカ３３０に処理されたベースバンドを伝送する。
ＴＸ処理回路３１５は、マイクロホン３２０からアナログ又はデジタル音声データを受信したり、メインプロセッサ３４０から(Ｗｅｂデータ、Ｅメール、又はインタラクティブビデオゲームデータのような)他の出力ベースバンドデータを受信する。ＴＸ処理回路３１５は、処理されたベースバンド又はＩＦ信号を生成するために出力ベースバンドデータを符号化、多重化、及び/又はデジタル化する。ＲＦ送受信器３１０ａ-３１０ｎは、ＴＸ処理回路３１５から出力処理されたベースバンド又はＩＦ信号を受信し、アンテナ３０５ａ乃至３０５ｎのうち一つ以上を通じて伝送されるＲＦ信号にベースバンド又はＩＦ信号をアップコンバーティングする。
メインプロセッサ３４０は、一つ以上のプロセッサ又は他の処理装置を含むことができ、ＳＴＡ３００の全体オペレーションを制御するためにメモリ３６０に格納されている基本ＯＳプログラム３６１を実行できる。例えば、メインプロセッサ３４０は、よく知らされている原理によりＲＦ送受信器３１０ａ乃至３１０ｎ、ＲＸ処理回路３２５、及びＴＸ処理回路３１５により逆方向チャンネル信号等の受信及び逆方向チャンネル信号等の伝送を制御できる。一部実施形態で、メインプロセッサ３４０は、少なくとも一つのマイクロプロセッサ又はマイクロ制御器を含む。
また、メインプロセッサ３４０は、ウェブソケットを通じてメディアをストリーミングするためのオペレーションのように、メモリ３６０に常駐する他のプロセス及びプログラムを実行できる。メインプロセッサ３４０は、実行するプロセスにより必要に従ってメモリ３６０の内に又は外にデータを移動させ得る。一部実施形態で、メインプロセッサ３４０は、オペレータ又はＡＰ１０２から受信された信号に応答して、又はＯＳプログラム３６１に基づいてアプリケーション３６２を実行するように構成される。また、メインプロセッサ３４０は、ＳＴＡ３００にラップトップコンピュータ及びハンドヘルドコンピュータのような他の装置に接続する能力を提供するＩ/Ｏインターフェース３４５に接続される。Ｉ/Ｏインターフェース３４５は、メイン制御器３４０とその付属装置との間の通信経路である。
また、メインプロセッサ３４０は、キーパッド３５０及びディスプレイユニット３５５に接続される。ＳＴＡ３００のオペレータは、ＳＴＡ３００にデータを入力するためにキーパッド３５０を使用できる。ディスプレイ３５５は、例えばウェブサイトからテキスト及び/又は少なくとも制限されたグラフィックをレンダリングできる液晶ディスプレイ又は他のディスプレイであり得る。
メモリ３６０は、メインプロセッサ３４０に接続される。メモリ３６０の一部は、ランダムアクセスメモリ(ＲＡＭ)を含み、メモリ３６０の他の一部はフラッシュメモリ又は他の読み取り専用メモリ(ＲＯＭ)を含むことができる。
図２及び図３はコンピュータシステム内の装置の一例を示すが、多様な変更を図２及び図３に対して実行できる。例えば、図２及び図３の多様な構成要素は、組み合わせ、より細分化し、又は省略することができ、追加構成要素は、特定要求に応じて追加され得る。特定実施形態では、メインプロセッサ３４０は、一つ以上の中央処理ユニット(ＣＰＵ)及び一つ以上のグラフィック処理ユニット(ＧＰＵ）のように、複数のプロセッサに分けられる。また、図３は、移動電話又はスマートフォンで構成されるクライアント装置３００を示すが、クライアント装置は、他のタイプの移動装置又は固定装置として動作するように構成される。また、コンピュータ及び通信ネットワークと同様に、クライアント装置及びサーバも、多様な構成で提供され、図２及び図３は、本発明を特定のクラアント装置又はサーバに限定するものではない。
ＨＴＴＰによる動的適応ストリーミング(ＤＡＳＨ）は、最近、３ＧＰＰ及びＭＰＥＧにより標準化された。マイクロソフト(登録商標)によるスムーズストリーミング及びＡＰＰＬＥ(登録商標)によるＨＴＴＰライブストリーミング(ＨＬＳ）といった適応ＨＴＴＰストリーミングに対するいくつかの他のプロプリエタリなソリューションが現在商業的に展開されている。一方、ＤＡＳＨは、完全にオープンで標準化されたメディアストリーミングソリューションであり、その結果、異なる装置で相互動作可能である。
図４は、本発明の実施形態による適応ＨＴＴＰストリーミングアーキテクチャを示す。図４に示すＨＴＴＰストリーミングアーキテクチャ４００の実施形態は、単に例示のためのものである。本発明の範囲から逸脱することなく、他の実施形態を使用できる。
ＨＴＴＰストリーミングアーキテクチャ４００で、コンテンツは、コンテンツ準備４０５のステップで用意される。コンテンツは、ＨＴＴＰストリーミングサーバ４１０により配信される。ＨＴＴＰストリーミングサーバ４１０は、サーバ１０４と同一又は類似に構成できる。ストリーミングで、コンテンツは、ＨＴＴＰキャッシュ４１５においてキャッシュ又はバッファされ、さらに、ＨＴＴＰストリーミングクライアント４２０にストリーミングされる。ＨＴＴＰストリーミングクライアント４２０は、クライアント１０６−１１４のうちいずれか一つとできる。
ＤＡＳＨでは、コンテンツが複数のセグメントに分割されるコンテンツ準備のステップ４０５が実行されなければならない。初期化セグメントは、メディアプレーヤーを構成するために必要な情報を配信するために生成される。そのときにのみ、メディアセグメントを消費できる。コンテンツは、一般的に複数の変形、一般的にいろいろなビット伝送率で符号化される。それぞれの変形は、コンテンツのリプレゼンテーションに対応する。コンテンツリプレゼンテーションは、相互に補完できる。前者の場合、クライアントは代替リプレゼンテーションのグループの中から一つの代替のみを選択する。代替リプレゼンテーションは、適応セットとしてともにグループ化される。クライアントは、追加的なメディア構成要素を含む補完リプレゼンテーションを継続して追加できる。
ＤＡＳＨストリーミングのために提供されるコンテンツをクライアント４２０に記述する必要がある。これは、メディアプレゼンテーション記述(ＭＰＤ)ファイルを用いて実行される。ＭＰＤは、コンテンツの記述と、コンテンツの期間と、適応セットと、コンテンツのリプレゼンテーションと、そして、最も重要なコンテンツの各部分にアクセスする方法と、を含むＸＭＬファイルである。ＭＰＤ要素は、ＭＰＤファイルの主要素である。ＭＰＤ要素は、コンテンツのタイプ及びコンテンツを使用可能な時間ウィンドウといった、コンテンツに関する一般的な情報を含む。ＭＰＤは、一つ以上の期間を含み、それぞれの期間は、コンテンツの時間セグメントを記述する。
それぞれの期間には、一つ以上の適応セットにグループ化される一つ以上のコンテンツのリプレゼンテーションを含めることができる。それぞれのリプレゼンテーションは、一つ以上のコンテンツ構成要素のエンコーディングであり、特定構成を有する。リプレゼンテーションは、主にそれらの帯域幅要件、それらが含むメディア構成要素、使用しているコーデック、言語などが相異なる。
図５は、本発明の実施形態によるＭＰＤ構造を示す。図５に示すＭＰＤ構造５００の実施形態は、単に例示のためのものである。本発明の範囲から逸脱することなく、他の実施形態が使用され得る。
図５に示す実施形態では、ＭＰＤ構造５００は、複数の期間５１０を有するメディアプレゼンテーション５０５を含む。各期間５１０は、複数の適応セット５１５を含む。それぞれの適応セット５１５は、複数のリプレゼンテーション５２０を含む。各リプレゼンテーション５２０は、セグメント情報５２５を含む。セグメント情報５２５は、初期セグメント５３０及び複数のメディアセグメント５３５を含む。
ＤＡＳＨの一つの配置(deployment)シナリオにおいて、ＩＳＯベースのファイルフォーマット及びその派生形式(ＭＰ４及び３ＧＰファイルフォーマット）が使用される。コンテンツは、いわゆるムービーフラグメントに格納される。それぞれのムービーフラグメントは、メディアデータ及び該当メタデータを包含する。メディアデータは、一般的にリプレゼンテーションのすべてのメディア構成要素からのメディアサンプルのコレクションである。各々のメディア構成要素は、ファイルのトラックとして記述される。
ＨＴＴＰストリーミング
ＨＴＴＰは、リクエスト/応答ベースのプロトコルである。クライアント装置３００は、そのＨＴＴＰリクエストを送信するためにサーバ２００との接続を確立する。サーバ２００は、ＨＴＴＰリクエストを受信しクライアント装置３００に応答を送信するために、クライアント装置３００からの接続を受諾する。標準ＨＴＴＰモデルにおいて、サーバ２００は、クライアントに対する接続を開始することも、要請されないＨＴＴＰ応答を送信することもできない。従って、クライアント装置３００は、ＨＴＴＰにてメディアストリーミングを実行するためには、セグメント５０５毎にメディアデータをリクエストしなければならない。これは、追加的な終端間(end-to-end)遅延だけでなく、リクエストに対する著しいアップストリームトラフィックを発生する。
ウェブアプリケーションに対する状況を改善するために、いくつかのいわゆるＨＴＴＰストリーミングメカニズムがコミュニティにより開発された。これらのメカニズムにより、ウェブサーバ２００は、クライアント装置３００からのポールリクエストを待つことなくデータをクライアント装置３００に送信できる。(一般的にＣＯＭＥＴとして表示される)ＨＴＴＰストリーミングに対する主なアプローチは、データを使用可能になるまでリクエストを保留状態に維持するか、あるいは応答を無期限にオープン状態に維持するかのいずれかである。最初の場合、応答が受信された後に新たなリクエストを送信する必要がある。ＨＴＴＰストリーミングでは、リクエストは終了せず、接続はクローズされない。従って、使用可能となっているときにはいつも、データはクライアント装置３００にプッシュされる。
ＨＴＴＰロングポーリング
従来のリクエストとともに、クライアントは、サーバ２００に一般的なリクエストを送信し、それぞれのリクエストは、すべての使用可能なデータを取得することを試みる。使用可能なデータがない場合、サーバ２００は、空応答又はエラーメッセージを返す。クライアント装置３００は、以後にポーリングを実行する。ポーリング頻度は、アプリケーションによる。ＤＡＳＨでは、これはセグメント使用可能開始時間により決定されるが、クライアントとサーバとの間でクロックの同期化が必要である。
ロングポーリングにおいて、サーバ２００は、リクエストしたリソースを使用できるまでリクエストを保留状態に維持することにより、待ち時間及びポーリング頻度を最小化することを試みる。ＤＡＳＨに適用する場合には、リクエストされたＤＡＳＨセグメントが使用可能となるまでいかなる応答も送信されない。一方、現在のデフォルト動作は、使用可能でないセグメントに対するリクエストは“４０４エラー”応答である。
しかしながら、クライアント装置３００がすべてのセグメントに対するＨＴＴＰリクエストを送信しなければならないため、ロングポーリングは、ＤＡＳＨに対して最適でないこともある。また、セグメントＵＲＬは、優先的に知られていない可能性が高いため、クライアント装置３００は、まずＭＰＤを獲得し、これをパーシングして現在セグメントの位置を発見しなければならない。これにより、追加的な遅延が発生する。
ＨＴＴＰストリーミング
ＨＴＴＰストリーミングメカニズムは、リクエストを無期限オープン状態に維持する。ＨＴＴＰストリーミングメカニズムは、いくつかのデータがクライアントに送信された後も、リクエストを終了せず、接続をクローズしない。クライアント及びサーバが接続をオープンしたりクローズしたりする必要がないため、このメカニズムは、待ち時間を大きく短縮させる。手順は、クライアント装置３００が最初のリクエストを作成することにより開始される。その後、クライアント装置３００は、応答を待つ。サーバ２００は、データが使用可能となるまで応答を保留する。データが使用可能となったらいつでも、サーバは、部分応答としてクライアント装置３００にデータを送信する。これは、ＨＴＴＰ/１.１とＨＴＴＰ/１.０の両方にてサポートされる。この場合、Ｃｏｎｔｅｎｔ−Ｌｅｎｇｔｈヘッダーフィールドは、優先的に知られていないため、応答で提供されない。その代わりに、応答長さは、接続をクローズすることにより決定される。このようなＨＴＴＰストリーミングアプローチの主な問題は、このような接続に対する中間ノードの挙動を保証できないことである。例えば、中間ノードは、部分応答を直ちに伝送しない場合がある。中間ノードは、応答をバッファリングし、後でこれを送信すると決定する場合がある。
図６及び図７は、本発明によるＨＴＴＰ１.０とＨＴＴＰ１．１の差を示す。このフローチャートは、順次的な一連の信号を示すが、明示的に言及しない限り、実行の特定順序、重複方式で又は同時よりは順次にステップ又はその部分の実行、又は介入又は中間ステップの発生なしに独占的に示すステップの実行に関するシーケンスからいかなる推論も導出されてはならない。図示した例に示すプロセスは、例えばサーバ又はクライアント装置で処理回路により実現される。
ＨＴＴＰ/２及びウェブソケット
ＨＴＴＰプロトコルにより多くのフレキシビリティーが必要であることは以前より認識されていたが、コミュニティは、最も人気のあり、多く使用されるプロトコルのうちいずれか一つを変更することを渋っている。図６に示す実施形態では、ＨＴＴＰ１.０ ６００が接続ごとに一つのリクエストのみを許容することにより、ＴＣＰ接続を増加及び減少させるために遅延を招く可能性があることが示されている。クライアント装置３００による各々の“ＧＥＴ”リクエストに対して、連続的応答がサーバ２００により送信される。すなわち、クライアント装置３００による第１の“ＧＥＴ”リクエスト６０５ａに対して、連続的応答６１０ａがサーバ２００により送信される。クライアント装置３００による第２の“ＧＥＴ”リクエスト６０５ｂに対して、連続的応答６１０ｂがサーバ２００により送信される。図７に示す実施形態では、ＨＴＴＰ１.１ ７００が永続的接続及びリクエストパイプライン方式を導入していることが示されている。クライアント装置３００による複数の“ＧＥＴ”リクエストの後に、サーバ２００により送信される複数の対応する応答が続く。すなわち、第１の“ＧＥＴ”リクエスト７０５ａ、第２の“ＧＥＴ”リクエスト７０５ｂ、及び第３の“ＧＥＴ”リクエスト７０５ｃがクライアント装置３００により送信される。その応答として、対応する第１の応答７１０ａ、第２の応答７１０ｂ、及び第３の応答７１０ｃが、サーバ２００により送信される。永続接続により、同一のＴＣＰ接続を複数のリクエストを送信し、その応答を受信するために使用できる。これにより、ＴＣＰの接続設定とＴＣＰの遅い開始フェーズとを経ることを回避できる。リクエストパイプライン方式では、クライアントが以前のリクエストに対する応答を受信する前に複数のリクエストを送信できる。図６及び図７の実施形態は、ＨＴＴＰ１.０及びＨＴＴＰ１.１の異なるメッセージ交換シーケンスを示しており、遅延及びリンク利用の側面で潜在的な利得を示している。
しかしながら、ＨＴＴＰ１.１ ７００は、パイプライン方式及び永続接続の導入によってもすべてのアプリケーションのニーズを満たさない。例えば、パイプライン方式を使用した場合であっても、サーバ２００からの応答は、クライアント装置３００のリクエストと同一の順序でなければならなく、一つのリクエストが遮断されると、後続のリクエストも遮断される。すなわち、第１の“ＧＥＴ”リクエスト７０５ａが遮断されると、第２の“ＧＥＴ”リクエスト７０５ｂ及び第３の“ＧＥＴ”リクエスト７０５ｃも遮断される。ＨＴＴＰ１.１ ７００は、サーバ２００からクライアント装置３００へコンテンツのプッシュもサポートしない。したがって、クライアント装置３００は、クライアント装置３００が実際にリクエストしたリソースを取得するだけである。一般的なウェブサイトの場合、リンクされているリソースの集合は、それら全部をリンクするメインＨＴＭＬ文書をリクエストした後にリクエストされる可能性が非常に高い。その結果、クライアント装置３００は、リンクされたリソースをリクエストする前に、メインファイルが受信されパーシングされるまで待機しなければならない。これにより、ウェブサイトをレンダリングする過程で相当な遅延を招く。
次の実施形態において、ＨＴＴＰ/２及びウェブソケットにより提供される新たな特徴が開示される。本発明の特定実施形態では、ＨＴＴＰ/２及びウェブソケットを通じてＤＡＳＨを可能にする。
ＨＴＴＰ２.０
ここで、“ＨＴＴＰ/２”とも称されるＨＴＴＰ２.０は、同時にすべての機能を変更せずに維持しつつ、ＨＴＴＰ１.１の以前の制限事項を解決しようとする国際インターネット技術委員会(ＩＥＴＦ）の作業草案である。
ＨＴＴＰ/２は、クライアント装置３００及びサーバ２００により独立的に処理されるストリームの概念を導入する。ストリームは、リクエストの搬送と該当リクエストに対する応答の受信とに使用され、その後にクローズされる。メッセージ交換はフレームにて実行され、このフレームは、フレームのペイロードに従ってＨＥＡＤＥＲＳ又はＤＡＴＡの形式とできる。加えて、制御フレームの集合も定義される。これらフレームは、進行中であるストリームを取消したり(ＲＳＴ_ＳＴＲＥＡＭ)、他のストリームと比較した場合のストリームの優先度を示したり(ＰＲＩＯＲＩＴＹ)、ストリーム設定を通信したり(ＳＥＴＴＮＧＳ）、現在のＴＣＰ接続ではストリームがこれ以上生成されないことを示したり(ＧＯＡＷＡＹ)、ピン/ポン動作を実行したり(ＰＩＮＧ及びＰＯＮＧ)、サーバからクライアントにデータをプッシュする約束をしたり(ＰＵＳＨ_ＰＲＯＭＩＳＥ)、又は以前のフレームの継続(ＣＯＮＴＩＮＵＡＴＩＯＮ）を提供したりするために使用される。特定の実施形態では、フレームの長さは最大１６３８３バイトである。
また、ＨＴＴＰ/２は、ヘッダー圧縮を通じてワイヤー効率を改善しようと試みる。使用される場合、ヘッダー圧縮は、ヘッダーフィールド名称のインデックスを作り、使用されるヘッダーフィールドを示すために数値識別子を使用する。大部分のヘッダーフィールドは、静的ｉｄ値が割り当てられるが、ヘッダー圧縮は、動的に他のヘッダーフィールドに値を割り当てるようにする。
ウェブソケット
ＨＴＴＰ/２と類似して、特定の実施形態では、ハンドシェーク動作で開始され、その間に両末端がウェブソケットに対する接続のアップグレードに同意する完壁な整合(conformant)ＨＴＴＰプロトコルアップグレードとして、ウェブソケットが実現される。ウェブソケット接続に対する接続のアップグレードに成功した後に、データは両方向に同時に流れることが可能となり、その結果、全二重接続が可能となる。サーバ２００は、クライアントのリクエストを必要とすることなくクライアント装置３００にデータを送信すると決定できる。また、クライアント装置３００は、サーバからの応答を待つ必要なしに複数のリクエストを送信できる。
実際に、ＨＴＴＰ/２は、(データ、継続、ピン及びポンといった)いくつかのフレームタイプを含み、ハンドシェイク手順及びフレーム化手順といった多くの概念をウェブソケットから借用している。ウェブソケットは、アプリケーションデータのフォーマットに関するさらなる詳細を定義せず、アプリケーションにそれを任せている。実際のフォーマットは、両側のエンドポイントがＳｅｃ-ＷｅｂＳｏｃｋｅｔ-Ｐｒｏｔｏｃｏｌヘッダーフィールドを交換することによって使用すべきサブプロトコルに同意するハンドシェイクフェーズ中にネゴシエートされる。
本発明の特定実施形態によれば、
クライアント装置３００は、継続してデータをプル(pull)することを回避し、
クライアント装置３００は、同期化問題及びリソースフェッチエラーを回避し、
クライアント装置３００は、セッションの制御中にあり、
サーバ２００は、セッションを通じていくつかの制御を得る。
その結果、本発明の特定実施形態では、遅延の発生及びネットワークトラフィックを減少させる。
特定実施形態において、ＨＴＴＰストリーミングソリューションを通じてプッシュベースの適応ＨＴＴＰストリーミングを可能にするフレームプロトコルが定義される。フレームプロトコルは、クライアント装置３００がサーバに命令を送信してストリーミングセッション中に速度適応オペレーションを実行できる。
図８は、本発明の実施形態によるウェブソケットサポートネットワークを示す。図８に示すウェブソケットサポートネットワーク８００の実施形態は、単に例示のためのものである。本発明の範囲から逸脱することなく他の実施形態を使用できる。
ウェブソケットサポートネットワーク８００は、元サーバ(origin server)８０５、一つ以上のコンテンツ配信ネットワーク(ＣＤＮ)プロキシサーバ８１０、及び複数のクライアント装置８１５を含む。元サーバ８０５は、サーバ２００と類似又は同一に構成されてもよい。一つ以上のＣＤＮプロキシサーバ８１０は、サーバ２００と類似又は同一に構成されてもよい。クライアント装置８１５のうち一つ以上は、クライアント装置３００と同一又は類似に構成されてもよい。ＣＤＮプロキシサーバ８１０は、インターネット８２０を介して元サーバ８０５と通信する。インターネット８２０は、ネットワーク１０２と同一又は類似に構成できる。クライアント装置８１５ａは、クライアント装置８１５ａが元サーバ８０５からコンテンツを受信するＣＤＮプロキシサーバ８１０ａとの通信接続を確立する。クライアント装置８１５ｂは、クライアント装置８１５ｂが元サーバ８０５からコンテンツを受信するＣＤＮプロキシサーバ８１０ｂとの通信接続を確立する。クライアント装置８１５ｃは、クライアント装置８１５ｃが元サーバ８０５からコンテンツを受信できるＣＤＮプロキシサーバ８１０ｂとの通信接続を確立する。図８に示す実施形態で、ウェブソケットは、ＣＤＮからクライアントにコンテンツをストリーミングする最後のホップ(hop)で使われる。すなわち、クライアント装置８１５ｂ又はクライアント装置８１５ｃ、又はその両方は、元サーバ８０５にＣＤＮプロキシサーバ８１５ｂを通じる各々の接続を通じてウェブソケット８２５を介して適応ＨＴＴＰストリーミングを確立する。
特定の実施形態において、クライアント装置８１５ｂは、元サーバ８０５又はＣＤＮプロキシサーバ８１０ｂがウェブソケットを通じたメディアストリーミングをサポートするか否かをまず検出する。クライアント装置８１５ｂ又はクライアント装置８１５ｂを追加的に含んだ実施形態について示しているが、本発明から逸脱しない範囲で、クライアント装置８１５ｃ又はクライアント装置８１５ａへのストリーミングに対応する実施形態も用いることができる。第１の装置が元サーバ８０５又はＣＤＮプロキシサーバ８１０ｂを決定する場合、クライアント装置８１５ｂは、ＣＤＮプロキシサーバ８１０ｂを通じて元サーバ８０５に対してウェブソケット接続を確立し、ストリームでの位置及び選択されたリプレゼンテーションを示す初期リクエストを送信する。以後、クライアント装置８１５ｂは、元サーバ８０５によりプッシュされるメディアセグメントを順次受信する。クライアント装置８１５ｂが、
代替リプレゼンテーションを選択し、あるいは代替リプレゼンテーションに切り替えることを決定し、
トリックモードオペレーションを実行すると決定し、
マニフェストファイルアップデート又はクライアント動作を必要とするとの指示を受信し、
ストリームの終了又はサービス指示の終了を受信し、
次のセグメントに対するリクエストを送信するためにサーバからリクエストを受信するまで、このプロセスは継続する。
クライアント装置８１５ｂの決定又は受信に基づき、クライアント装置８１５ｂは、どのような命令を生成して元サーバ８０５に送信すべきかを決定する。
図９は、本発明の実施形態によるクライアント装置にウェブソケットを利用する適応ＨＴＴＰストリーミングプロセス９００を示す。フローチャートは、順次的な一連のステップを示すが、明示しない限り、性能の特定順序、重複方式で又は同時よりは順次にステップ又はその部分の性能、又は介入又は中間ステップの発生なしに独占的に示すステップの性能に関するシーケンスからいかなる推論も導出されてはならない。図示した例に示すプロセスは、例えばクライアント装置の処理回路により実現される。
ステップ９０５において、クライアント装置３００は、サーバ２００がウェブソケットをサポートするとの指示を受信する。サーバ２００は、クライアント装置３００にメディアストリーミングセッションを提供するために、ウェブソケットにアップグレードしようとすることをクライアント装置３００に示す。クライアント装置３００に対する接続を確立した後に、サーバ２００は、ステップ９１０において、セグメントに対する初期リクエストを受信する。クライアント装置３００は、リプレゼンテーション及び位置を選択するためにサーバ２００に命令又はリクエストを送信する。サーバ２００は、フレームでセグメントをカプセル化してこれを送信する。ステップ９１５において、クライアント装置３００は、サーバ２００からセグメントを受信する。サーバ２００は、クライアント装置３００により決定が要求されるか、あるいは新たな命令が受信されるまで、例えばセグメント数を一つずつ増加させることによって、次のセグメントを継続して送信する。すなわち、ステップ９２０において、ＭＰＤファイルアップデートが使用できる場合のように、動作が要求されると表示されるか、あるいは命令が送信される。ステップ９２０で必要とする動作がない場合、クライアント装置３００は、例えばステップ９１５に戻ることによってセグメントを継続して受信する。ステップ９１０で動作が必要である場合、クライアント装置３００は、ステップ９２５で、セッションを終了するか否かを判定する。クライアント装置３００がステップ９２５でセッションを終了しないと判定する場合、クライアント装置３００は、ステップ９１０で、サーバにもう一つの命令を送信してリプレゼンテーション及び位置を選択する。あるいは、クライアント装置３００がステップ９２５でセッションを終了すると判定する場合、クライアント装置３００は、ステップ９３０でセッションを終了し、あるいは他のサーバに切り替える。
図１０は、本発明の実施形態によるサーバに対してウェブソケットを活用する適応ＨＴＴＰストリーミングプロセス１０００を示す。このフローチャートが順次的な一連のステップを示すが、明示しない限り、性能の特定順序、重複方式で又は同時よりは順次にステップあるいはそれらの部分の性能、又は介在あるいは中間ステップの発生なしに独占的に示すステップの性能に関するシーケンスからいかなる推論も導出されてはならない。本実施形態で示すプロセスは、例えばサーバの処理回路により実現される。
ステップ１００５において、サーバ２００は、サーバ２００がクライアント装置３００にメディアストリーミングセッションを提供するためにウェブソケットにアップグレードしようとすることをクライアント装置３００に指示する。クライアント装置３００は、サーバ２００がウェブソケットをサポートするとの指示を受信した後、サーバ２００は、ステップ１０１０で、クライアント装置３００と受信(incoming)ウェブソケット接続を確立する。クライアント装置３００に対する接続の確立後に、サーバ２００は、ステップ１０１５で、セグメントに対するリクエスト、又は初期命令を受信する。すなわち、リプレゼンテーション及び位置を選択するためにサーバ２００に命令又はリクエストを送信するクライアント装置３００に応答して、サーバ２００は、フレームでセグメントをカプセル化してクライアント装置３００にこのセグメントを送信することで、ストリーミング命令を処理する。ステップ１０２０において、サーバ２００は、クライアント装置３００に次のセグメントを送信する。サーバ２００は、クライアント装置３００により決定が要求され、あるいは新たな命令が受信されるまで、例えばセグメント数を一つずつ増加させることにより、次のセグメントを継続して送信する。すなわち、ステップ１０２５において、サーバ２００は、ＭＰＤファイルアップデートが使用可能になる場合のように、クライアント動作が必要であるか否かを判定する。ステップ１０２５で動作が必要でない場合、サーバ２００は、例えばステップ１０２０に戻ることにより、セグメントを継続して送信する。ステップ１０２５でクライアント装置動作が必要である場合、ステップ１０３０で、サーバ２００は、ＭＰＤファイルアップデートが使用可能になる場合のように、各々の動作を示す命令２００をクライアント装置３００に送信する。
特定の実施形態において、ウェブソケットを通じた適応ＨＴＴＰストリーミングは、ウェブソケットプロトコルのサブプロトコルとして実現される。命令は、ウェブソケットフレームヘッダーで拡張データとして定義される。以下は、クライアント装置３００からサーバ２００への可能な命令である。
初期(init)セグメント及び特定セグメントの数から開始される特定リプレゼンテーションからのデータのストリーミングリクエスト。リクエストは、第１のセグメントのＵＲＬ(Uniform Resource Locator)であるか、あるいはプレゼンテーション識別子、リプレゼンテーション識別子、及び開始セグメント数とできる。
サーバからのストリーミング中止のリクエスト。
以下は、サーバ２００からクライアント装置３００への可能な命令である。
ＭＰＤアップデートに関する情報。
クライアントに送信されるセグメントの識別子。各セグメントは、別途にフレーム化され、そのＵＲＬ又は他の識別が先行する。
新たな期間による、クライアント選択のためのリクエスト。この命令は、クライアント選択が要請される理由に関する他の情報だけでなくタイムラインでの現在位置を含む。
早期のセッション終了又はストリーミングセッション終了に関する情報。
セグメント及びＭＰＤアップデートはクライアント装置がそれぞれのセグメントを別に識別するようにフレーム化される。セグメントは各々のムービーフラグメントが固有フラグメントとして送信されるようにフラグメント化できる。
ＨＴＴＰ/２及びウェブソケットを通じたＤＡＳＨ
新たなプロトコルＨＴＴＰ/２及びウェブソケットの完全な潜在力を利用するために、ＤＡＳＨアプリケーションは、アップグレードされた接続上で使用される新たなサブプロトコルを定義しなければならない。この場合、サブプロトコルは、ＨＴＴＰ１.１機能と等しいことを意味するので、ＨＴＴＰ/２は、ウェブソケットより多くの機能を定義するため、ＨＴＴＰ/２の場合ではより少ない作業を実行する必要がある。
本発明の特定実施形態は、ＤＡＳＨアプリケーションに対して使用可能な機能を示す。
ＤＡＳＨクライアント装置は、サーバに対するリクエストの量を最小化できる。
ＤＡＳＨクライアント装置は、迅速な速度適応が可能である。
ＤＡＳＨクライアント装置は、コンテンツがすぐさま生成されるライブストリーミングの場合のように遅延を最小化できる。
ＤＡＳＨ/ウェブサーバは、再生(playback)に対するそれらの重要性に基づいて異なるリプレゼンテーションからのデータを優先順位化できる。
このようなターゲットに基づいて、ＨＴＴＰ/２及びウェブソケットに対する新たなサブプロトコルが定義される。
ウェブソケットに対するＤＡＳＨサブプロトコル
サブプロトコルは、名称“ｄａｓｈ”により識別される。ＤＡＳＨストリーミングのためにウェブソケットを使用することを所望するクライアント装置は、プロトコルアップグレードリクエストとともにＳｅｃ-ＷｅｂＳｏｃｋｅｔ-Ｐｒｏｔｏｃｏｌヘッダーフィールドの一部としてキーワード“ｄａｓｈ”を含む。
ウェブソケットに対するプロトコルのアップグレードに成功した後に、クライアント及びサーバは、ＤＡＳＨデータフレーム(演算コードの‘テキスト’又は‘バイナリ’又はそれらの ‘継続’フレーム）を交換する。ＤＡＳＨフレームフォーマットは、以下のように定義される。
Figure 2017517221
 ＳＴＲＥＡＭ_ＩＤ（８ビット）は、同一のウェブソケット接続を通じた多重リクエスト/応答を多重化する現在ストリームの識別子である。
ＣＭＤ_ＣＯＤＥ（８ビット）は、このようなリクエスト/応答により送信されるＤＡＳＨ命令を示す。以下の命令が現在定義されている。
Figure 2017517221
Figure 2017517221
Ｆ（３ビット）：このフィールドは、命令に基づいて設定され、解析されるべきフラグ集合を提供する。
ＥＸＴ_ＬＥＮＧＴＨ（１３ビット）：アプリケーションデータに先行する拡張データのバイト長さを提供する。
ＨＴＴＰ/２に対するＤＡＳＨサブプロトコル
上記したように、ＨＴＴＰ/２は、ＨＴＴＰ１.１プロトコルと等価なサブプロトコルを提供するウェブソケットの上位集合と見なすことができる。ＰＵＳＨ_ＰＲＯＭＩＳＥフレームを用いてクライアントにデータをプッシュする機能、特定ストリームで現在の伝送を取り消す機能、複数ストリームをサポートする機能といったウェブソケットＤＡＳＨサブプロトコルに対して提案される機能のいくつかは、既にＨＴＴＰ/２プロトコルにより提供されている。
ＨＴＴＰ/２との下位互換を維持するために、ＤＡＳＨサブプロトコルは、ＤＡＳＨ関連情報及び命令を配信するために、ＨＥＡＤＥＲＳフレームを使用する。この目的のために、「コンマ区切り名称＝値」ペアの集合を有する新たなヘッダーフィールドが定義される。ＤＡＳＨヘッダーフィールドは、“Ｄａｓｈ”と称される。以下の命令が導入される。
(ａ)ＤＡＳＨサブプロトコルのサポートをネゴシエートする。
(ｂ)特定のリプレゼンテーションの連続ストリーミングをリクエストする。
(ｃ)クライアントの決定をリクエストする。
(ｄ)ＭＰＤアップデートを通報する。
以上、本発明の詳細な説明においては具体的な実施形態に関して説明したが、特許請求の範囲を外れない限り、様々な変更が可能であることは、当該技術分野における通常の知識を持つ者には明らかである。したがって、本発明の範囲は、前述の実施形態に限定されるものではなく、特許請求の範囲の記載及びこれと均等なものに基づいて定められるべきである。
ＳＴＡ３００は、複数のアンテナ３０５ａ-３０５ｎ、複数の無線周波数(ＲＦ)送受信器３１０ａ-３１０ｎ、送信(ＴＸ)処理回路３１５、マイクロホン３２０、及び受信(ＲＸ)処理回路３２５を含む。ＴＸ処理回路３１５及びＲＸ処理回路３２５は、ＲＦ送受信器３１０ａ-３１０ｎの各々に、例えば、アンテナ３０５ａ、アンテナ３０５ｂ-Ｎ番目のアンテナ３０５ｎに各々接続されるＲＦ送受信器３１０ａ、ＲＦ送受信器３１０ｂ乃至Ｎ番目のＲＦ送受信器３１０ｎに各々接続される。特定の実施形態において、ＳＴＡ３００は、一つのアンテナ３０５ａ及び一つのＲＦ送受信器３１０ａを含む。また、ＳＴＡ３００は、スピーカ３３０、メインプロセッサ３４０、入力/出力(Ｉ/Ｏ)インターフェース(ＩＦ)３４５、キーパッド３５０、ディスプレイ３５５、及びメモリ３６０を含む。メモリ３６０は、基本オぺレーティングシステム(ＯＳ)プログラム３６１及び一つ以上のアプリケーション３６２を含む。
ＲＦ送受信器３１０ａ-３１０ｎは、ネットワーク１０２のアクセスポイント１１８により伝送される入力ＲＦ信号を各々のアンテナ３０５ａ-３０５ｎから受信する。ＲＦ送受信器３１０ａ-３１０ｎは、中間周波数(ＩＦ)又はベースバンド信号を生成するために入力ＲＦ信号をダウンコンバーティングする。ＩＦ又はベースバンド信号は、ベースバンド又はＩＦ信号をフィルタリング、復号化、及び/又はデジタル化することにより処理されたベースバンド信号を生成するＲＸ処理回路３２５に伝送される。ＲＸ処理回路３２５は、(ウェブブラウジングデータ向けのような)追加処理のためにメインプロセッサ３４０に又は(音声データむけのような)スピーカ３３０に処理されたベースバンドを伝送する。
また、メインプロセッサ３４０は、ウェブソケットを通じてメディアをストリーミングするためのオペレーションのように、メモリ３６０に常駐する他のプロセス及びプログラムを実行できる。メインプロセッサ３４０は、実行するプロセスにより必要に従ってメモリ３６０の内に又は外にデータを移動させ得る。一部実施形態で、メインプロセッサ３４０は、オペレータ又はアクセスポイント１１８から受信された信号に応答して、又はＯＳプログラム３６１に基づいてアプリケーション３６２を実行するように構成される。また、メインプロセッサ３４０は、ＳＴＡ３００にラップトップコンピュータ及びハンドヘルドコンピュータのような他の装置に接続する能力を提供するＩ/Ｏインターフェース３４５に接続される。Ｉ/Ｏインターフェース３４５は、メイン制御器３４０とその付属装置との間の通信経路である。
特定の実施形態において、クライアント装置８１５ｂは、元サーバ８０５又はＣＤＮプロキシサーバ８１０ｂがウェブソケットを通じたメディアストリーミングをサポートするか否かをまず検出する。クライアント装置８１５ｂ又はクライアント装置８１５ｂを追加的に含んだ実施形態について示しているが、本発明から逸脱しない範囲で、クライアント装置８１５ｃ又はクライアント装置８１５ａへのストリーミングに対応する実施形態も用いることができる。元サーバ８０５又はＣＤＮプロキシサーバ８１０ｂがウェブソケットを通じてメディアストリーミングをサポートすることと決定される場合、クライアント装置８１５ｂは、ＣＤＮプロキシサーバ８１０ｂを通じて元サーバ８０５に対してウェブソケット接続を確立し、ストリームでの位置及び選択されたリプレゼンテーションを示す初期リクエストを送信する。以後、クライアント装置８１５ｂは、元サーバ８０５によりプッシュされるメディアセグメントを順次受信する。クライアント装置８１５ｂが、
代替リプレゼンテーションを選択し、あるいは代替リプレゼンテーションに切り替えることを決定し、
トリックモードオペレーションを実行すると決定し、
マニフェストファイルアップデート又はクライアント動作を必要とするとの指示を受信し、
ストリームの終了又はサービス指示の終了を受信し、
次のセグメントに対するリクエストを送信するためにサーバからリクエストを受信するまで、このプロセスは継続する。
ステップ９０５において、クライアント装置３００は、サーバ２００がウェブソケットをサポートするとの指示を受信する。サーバ２００は、クライアント装置３００にメディアストリーミングセッションを提供するために、ウェブソケットにアップグレードしようとすることをクライアント装置３００に示す。クライアント装置３００に対する接続を確立した後に、サーバ２００は、ステップ９１０において、セグメントに対する初期リクエストを受信する。クライアント装置３００は、リプレゼンテーション及び位置を選択するためにサーバ２００に命令又はリクエストを送信する。サーバ２００は、フレームでセグメントをカプセル化してこれを送信する。ステップ９１５において、クライアント装置３００は、サーバ２００からセグメントを受信する。サーバ２００は、クライアント装置３００により決定が要求されるか、あるいは新たな命令が受信されるまで、例えばセグメント数を一つずつ増加させることによって、次のセグメントを継続して送信する。すなわち、ステップ９２０において、ＭＰＤファイルアップデートが使用できる場合のように、動作が要求されると表示されるか、あるいは命令が送信される。ステップ９２０で必要とする動作がない場合、クライアント装置３００は、例えばステップ９１５に戻ることによってセグメントを継続して受信する。ステップ９２０で動作が必要である場合、クライアント装置３００は、ステップ９２５で、セッションを終了するか否かを判定する。クライアント装置３００がステップ９２５でセッションを終了しないと判定する場合、クライアント装置３００は、ステップ９１０で、サーバにもう一つの命令を送信してリプレゼンテーション及び位置を選択する。あるいは、クライアント装置３００がステップ９２５でセッションを終了すると判定する場合、クライアント装置３００は、ステップ９３０でセッションを終了し、あるいは他のサーバに切り替える。

Claims (16)

  1. サーバとの通信接続を確立するように構成されるインターフェースと、
    ウェブソケットを通じて適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングをサポートする前記サーバの能力を決定し、
    前記ＨＴＴＰストリーミング中にストリーミングオペレーションを実行するように前記サーバに命令を送信し、
    前記ストリーミングセッションで前記サーバから情報を受信するように構成される処理回路と、
    を含むことを特徴とする装置。
  2. 前記処理回路は、トリガイベントが発生するまでメディアセグメントを受信するように構成されることを特徴とする請求項１に記載の装置。
  3. 前記トリガイベントは、帯域幅測定の変化、マニフェストファイルのアップデートを使用できる前記サーバによる指示、一つ以上のリプレゼンテーションに対する前記サーバによる推薦のうちいずれか一つを含み、前記処理回路は、前記処理回路により要求される動作に対する指示を受信し、前記処理回路は、ストリームの終了又はサービスの終了を受信することを特徴とする請求項２に記載の装置。
  4. ストリームの終了又はサービスの終了のうち一つを受信するステップに応答して、前記処理回路は、前記ＨＴＴＰストリーミングの終了又は他のサーバへの切り替えのうち少なくとも一つを実行するように構成されることを特徴とする請求項２に記載の装置。
  5. 前記トリガイベントに応答して、前記処理回路は、前記サーバに命令を送信するように構成されることを特徴とする請求項２に記載の装置。
  6. 前記トリガイベントに応答して、前記処理回路は、
    代替リプレゼンテーションを選択し、あるいはトリックモードオペレーションを実行するように構成されることを特徴とする請求項２に記載の装置。
  7. 少なくとも一つのクライアント装置と接続するように構成されるインターフェースと、
    ウェブソケットを通じて適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングがサポートされるという指示を前記少なくとも一つのクライアント装置に送信し、
    前記ＨＴＴＰストリーミング中にストリーミングオペレーションを実行するために前記少なくとも一つのクライアント装置から受信される命令に応答して前記少なくとも一つのクライアント装置と受信ウェブソケット接続を確立するように構成される処理回路と、
    を含むことを特徴とするサーバ。
  8. 前記処理回路は、
    前記ＨＴＴＰストリーミング中にストリーミングオペレーションを実行するために命令を受信及び処理し、
    前記少なくとも一つのクライアント装置にメディアセグメントを送信するように構成されることを特徴とする請求項７に記載のサーバ。
  9. 前記処理回路は、トリガイベントが発生するまでメディアセグメントを継続して送信するように構成されることを特徴とする請求項７に記載のサーバ。
  10. 前記トリガイベントは、
    帯域幅測定の変化、
    マニフェストファイルのアップデートを使用できる決定、又は
    前記少なくとも一つのクライアント装置から受信される命令、及び一つ以上のリプレゼンテーションに対する前記サーバによる推薦を前記少なくとも一つのクライアント装置に送信するための決定のうちいずれか一つを含むことを特徴とする請求項９に記載のサーバ。
  11. 前記処理回路は、追加動作が前記少なくとも一つのクライアント装置により要求される場合を決定するように構成され、前記トリガイベントは、追加動作が前記少なくとも一つのクライアント装置により要求されるという決定を含むことを特徴とする請求項１０に記載のサーバ。
  12. 前記処理回路は、ストリームの終了又はサービスの終了のうちいずれか一つを送信するように構成されることを特徴とする請求項１０に記載のサーバ。
  13. 前記処理回路は、他のセグメントに対するリクエストを伝送するために前記少なくとも一つのクライアント装置にリクエストを伝送するように構成されることを特徴とする請求項７に記載のサーバ。
  14. クライアント装置のための方法であって、
    サーバとの通信接続を確立するステップと、
    ウェブソケットを通じて適応ハイパーテキスト転送プロトコル(ＨＴＴＰ)ストリーミングをサポートする前記サーバの能力を決定するステップと、
    ＨＴＴＰストリーミング中にストリーミングオペレーションを実行するために前記サーバに命令を送信するステップと、
    前記ストリーミングセッションで前記サーバからの情報を受信するステップと、
    を有することを特徴とする方法。
  15. トリガイベントが発生するまでメディアセグメントを受信するステップをさらに有し、前記トリガイベントは、
    帯域幅測定の変化、
    マニフェストファイルのアップデートが使用できるという前記サーバによる指示、
    一つ以上のリプレゼンテーションに対して前記サーバによる推薦、
    次のセグメントに対するリクエストを送信するために前記サーバから受信されたリクエストを受信すること、
    前記クライアント装置により要求される動作に対する指示を受信するステップと、
    ストリームの終了又はサービスの終了を受信すること、または、
    次のセグメントに対するリクエストを送信するために前記サーバからリクエストを受信することのうちいずれか一つを有することを特徴とする請求項１４に記載の方法。
  16. ストリームの終了又はサービスの終了のうちいずれか一つを受信するステップに応答して、
    前記ＨＴＴＰストリーミングを終了するステップ又は他のサーバに切り替えるステップのうち少なくとも一つ、又は
    前記トリガイベントに応答して、
    前記サーバに命令を送信するステップ、代替リプレゼンテーションを前記クライアント装置により選択するステップ、あるいはトリックモードオペレーションを前記クライアント装置により実行するステップのうち少なくとも一つをさらに有することを特徴とする請求項１５に記載の方法。
JP2017500785A 2014-03-20 2015-03-20 Ｈｔｔｐストリーミングを使用するｄａｓｈストリーミングのための方法及び装置 Ceased JP2017517221A (ja)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
US201461968204P 2014-03-20 2014-03-20
US61/968,204 2014-03-20
US201462008904P 2014-06-06 2014-06-06
US62/008,904 2014-06-06
US14/661,668 2015-03-18
US14/661,668 US20150271233A1 (en) 2014-03-20 2015-03-18 Method and apparatus for dash streaming using http streaming
PCT/KR2015/002728 WO2015142102A1 (en) 2014-03-20 2015-03-20 Method and apparatus for dash streaming using http streaming

Publications (1)

Publication Number Publication Date
JP2017517221A true JP2017517221A (ja) 2017-06-22

Family

ID=54144976

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017500785A Ceased JP2017517221A (ja) 2014-03-20 2015-03-20 Ｈｔｔｐストリーミングを使用するｄａｓｈストリーミングのための方法及び装置

Country Status (4)

Country Link
JP (1) JP2017517221A (ja)
KR (1) KR20160135811A (ja)
CN (1) CN106416198A (ja)
WO (1) WO2015142102A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220174521A1 (en) * 2019-05-31 2022-06-02 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6700981B2 (ja) * 2016-05-31 2020-05-27 キヤノン株式会社 通信装置、通信方法、通信システムおよびプログラム
KR102335670B1 (ko) * 2017-09-13 2021-12-06 한화테크윈 주식회사 웹소켓을 이용하여 중간 서버를 경유하는 미디어 스트리밍 방법
CN110830541B (zh) 2018-08-14 2021-07-16 华为技术有限公司 一种消息处理方法、装置及系统
CN109413187A (zh) * 2018-11-01 2019-03-01 中国科学院计算机网络信息中心 一种通用的图数据在线交互式浏览分析方法
CN111447262A (zh) * 2020-03-23 2020-07-24 北京达佳互联信息技术有限公司 请求发送方法及客户端、存储介质
CN113938475B (zh) * 2021-12-16 2022-03-29 深圳市大头兄弟科技有限公司 一种数据传输方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2012096372A1 (ja) * 2011-01-14 2012-07-19 シャープ株式会社 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造
WO2013098317A1 (en) * 2011-12-29 2013-07-04 Koninklijke Kpn N.V. Network-initiated content streaming control
JP2013538507A (ja) * 2010-08-10 2013-10-10 クゥアルコム・インコーポレイテッド コード化ビデオデータのネットワークストリーミングのためのトリックモード
WO2014005053A1 (en) * 2012-06-29 2014-01-03 Avocent Huntsville Corp. System and method for single kvm client accommodating multiple different video compression technologies

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6704790B1 (en) * 1998-09-16 2004-03-09 Microsoft Corporation Server-side stream switching
US7392316B2 (en) * 2003-06-30 2008-06-24 Microsoft Corporation Client to server streaming of multimedia content using HTTP
US20120207088A1 (en) * 2011-02-11 2012-08-16 Interdigital Patent Holdings, Inc. Method and apparatus for updating metadata
EP2685742A4 (en) * 2011-04-07 2014-03-05 Huawei Tech Co Ltd METHOD, DEVICE AND SYSTEM FOR SENDING AND PROCESSING MEDIA CONTENT

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2013538507A (ja) * 2010-08-10 2013-10-10 クゥアルコム・インコーポレイテッド コード化ビデオデータのネットワークストリーミングのためのトリックモード
WO2012096372A1 (ja) * 2011-01-14 2012-07-19 シャープ株式会社 コンテンツ再生装置、コンテンツ再生方法、配信システム、コンテンツ再生プログラム、記録媒体、およびデータ構造
WO2013098317A1 (en) * 2011-12-29 2013-07-04 Koninklijke Kpn N.V. Network-initiated content streaming control
WO2014005053A1 (en) * 2012-06-29 2014-01-03 Avocent Huntsville Corp. System and method for single kvm client accommodating multiple different video compression technologies

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
IIS SMOOTH STREAMING TECHNICAL OVERVIEW, JPN6019013618, March 2009 (2009-03-01), ISSN: 0004018069 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220174521A1 (en) * 2019-05-31 2022-06-02 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring
US12022306B2 (en) * 2019-05-31 2024-06-25 Apple Inc. Systems and methods for performance data streaming, performance data file reporting, and performance threshold monitoring

Also Published As

Publication number Publication date
KR20160135811A (ko) 2016-11-28
WO2015142102A1 (en) 2015-09-24
CN106416198A (zh) 2017-02-15

Similar Documents

Publication Publication Date Title
US20150271233A1 (en) Method and apparatus for dash streaming using http streaming
US8732274B2 (en) Method and apparatus for generating and handling streaming media quality-of-experience metrics
JP2017517221A (ja) Ｈｔｔｐストリーミングを使用するｄａｓｈストリーミングのための方法及び装置
JP6618552B2 (ja) 多重経路メディア伝達のための方法及び装置
EP2936742B1 (en) Low-latency streaming
EP2805471B1 (en) Method and apparatus for enabling pre-fetching of media
US20090125634A1 (en) Network media streaming with partial syncing
CN105379295A (zh) 分段内容的流送
CN108600789A (zh) 用于多媒体自适应流传输的装置和机器可读存储介质
US20240223832A1 (en) Video stream bitrate adjustment method and apparatus, computer device, and storage medium
US10044831B2 (en) Method and apparatus for transmitting messages to a dash client
WO2017202373A1 (zh) 流媒体快速启动方法、装置和系统
WO2019128800A1 (zh) 一种内容服务的实现方法、装置及内容分发网络节点
CN103190097B (zh) 发送和接收用于http流送的媒体信息文件的方法
KR20170101192A (ko) 링크 인식 스트리밍 적응
US8000339B2 (en) Method and system for transparently transcoding a multicast stream
EP3175599A1 (en) Systems and methods for selective transport accelerator operation
CN114363667A (zh) 客户端、服务器、接收方法及发送方法
CN106604077A (zh) 自适应流媒体传输方法及装置
JP6059820B2 (ja) 低レイテンシ・ストリーミング
US11082474B2 (en) Data buffering method and apparatus in adaptive streaming service
Tabari et al. Low latency live video streaming on android devices using web-socket
HK1244121B (zh) 链路感知流送自适应

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20160921

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20171117

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20180830

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181002

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20181226

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20190416

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190716

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190806

A045 Written measure of dismissal of application [lapsed due to lack of payment]

Free format text: JAPANESE INTERMEDIATE CODE: A045

Effective date: 20191224