JP2017529726A - ストリーミングサービスのためのクライアント及びサーバの動作方法 - Google Patents

ストリーミングサービスのためのクライアント及びサーバの動作方法 Download PDF

Info

Publication number
JP2017529726A
JP2017529726A JP2017502886A JP2017502886A JP2017529726A JP 2017529726 A JP2017529726 A JP 2017529726A JP 2017502886 A JP2017502886 A JP 2017502886A JP 2017502886 A JP2017502886 A JP 2017502886A JP 2017529726 A JP2017529726 A JP 2017529726A
Authority
JP
Japan
Prior art keywords
file
data
client
parameter
key frame
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
JP2017502886A
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 JP2017529726A publication Critical patent/JP2017529726A/ja
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/60—Network structure or processes for video distribution between server and client or between remote clients; Control signalling between clients, server and network components; Transmission of management data between server and client, e.g. sending from server to client commands for recording incoming content stream; Communication details between server and client 
    • H04N21/61—Network physical structure; Signal processing
    • H04N21/6106—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network
    • H04N21/6125—Network physical structure; Signal processing specially adapted to the downstream path of the transmission network involving transmission via Internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04N—PICTORIAL COMMUNICATION, e.g. TELEVISION
    • H04N21/00—Selective content distribution, e.g. interactive television or video on demand [VOD]
    • H04N21/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/236—Assembling of a multiplex stream, e.g. transport stream, by combining a video stream with other content or additional data, e.g. inserting a URL [Uniform Resource Locator] into a video stream, multiplexing software data into a video stream; Remultiplexing of multiplex streams; Insertion of stuffing bits into the multiplex stream, e.g. to obtain a constant bit-rate; Assembling of a packetised elementary stream
    • 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/70—Media network packetisation
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • 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
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/22—Parsing or analysis of headers
    • 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/434—Disassembling of a multiplex stream, e.g. demultiplexing audio and video streams, extraction of additional data from a video stream; Remultiplexing of multiplex streams; Extraction or processing of SI; Disassembling of packetised elementary stream
    • 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/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
    • 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/65—Transmission of management data between client and server
    • H04N21/658—Transmission by the client directed to the server
    • H04N21/6587—Control parameters, e.g. trick play commands, viewpoint selection
    • 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/8455—Structuring of content, e.g. decomposing content into time segments involving pointers to the content, e.g. pointers to the I-frames of the video stream

Landscapes

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

Abstract

【課題】ストリーミングサービスのためのクライアント及びサーバの動作方法が開示される。【解決手段】一実施形態に係るクライアントはデータ要求を指示する媒介変数を含む要求パケットをサーバに送信する。一実施形態に係るサーバは、媒介変数に対応するアドレス範囲のデータを含む応答パケットをクライアントに送信する。

Description

実施形態は、ストリーミングサービスのためのクライアント及びサーバの動作方法に関する。
本発明の背景となる技術は特許文献１及び２に開示されている。
過去の数多いストリーミング技術は、リアルタイムストリーミングプロトコル（Ｒｅａｌ Ｔｉｍｅ Ｓｔｒｅａｍｉｎｇ Ｐｒｏｔｏｃｏｌ：ＲＴＳＰ）のようなストリーミング専用プロトコルを用いた。しかし、最近のストリーミング技術は、インターネットのように幅広く分布したＨＴＴＰネットワーク上で効率よく動作するように設計されている。例えば、可変ビットレートストリーミング（ａｄａｐｔｉｖｅ ｂｉｔｒａｔｅ ｓｔｒｅａｍｉｎｇ）は、ネットワークの状態或いは送信速度などに基づいて帯域幅を消化することのできる画質のコンテンツを送信するＨＴＴＰ基盤のストリーミング方式である。
可変ビットレートストリーミングは、ファイルを時間単位に分類して送信する。例えば、可変ビットレートストリーミングは、２〜１０秒のコンテンツを格納するチャンク（ｃｈｕｎｋ）を用いてストリーミングサービスを提供する。ここで、送信されるチャンクのそれぞれはＩ−ｆｒａｍｅなどの予め決定したキーフレームから開示されることが要求される。このような条件を満たすために、可変ビットレートストリーミングでは、映像ファイルをストリーミング用のファイルに変換する過程が必須的に求められる。このような変換過程で映像ファイルの画質は低下し、また、変換のための時間及びコンピューティングパワーが加えて消耗される。
また、可変ビットレートストリーミングはマニフェスト（ｍａｎｉｆｅｓｔ）ファイルを必須的に利用する。マニフェストファイルは、ストリーミング用ファイルの各チャンクに関する情報を格納するファイルである。マニフェストファイルは、映像ファイルがストリーミング用ファイルに変換されるとき生成される。可変ビットレートストリーミングによれば、クライアントは、ストリーミングサービスが提供されるためにマニフェストファイルを必須的に参照しなければならない。
韓国公開特許第２０１４−００５４１３８号 韓国公開特許第２０１２−０１１７３８４号
以下で説明する実施形態は、ストリーミング用ファイルフォーマットを用いることなく、映像ファイルフォーマットをそのまま使用するＨＴＴＰ基盤ストリーミング技術を提供する。実施形態は、映像ファイルを容量単位に分割して送信する技術を提供する。例えば、実施形態は、映像ファイルを実際に分割せずに映像ファイルの一部をバイトアドレス単位に送信するストリーミングサービスを提供する。実施形態によれば、送信されるチャンクは、キーフレームから開始することが求められず、映像ファイルをストリーミング用ファイルに変換する過程を省略し得る。
実施形態は、映像ファイルをストリーミング用ファイルに変換する過程を省略することによって、変換時に発生する画質の低下を防止してサーバの負荷を減少させ得る。また、実施形態によれば、映像ファイルがサーバにアップロードされた後に映像ファイルをストリーミング用ファイルに変換する時間が要求されないため、より迅速なストリーミングサービスを提供し得る。それだけではなく、実施形態によれば、ストリーミング用ファイルが別に生成されないため、ストリーミング用ファイルのチャンク情報を格納するマニフェストファイルが要求されることがない。
一側に係るストリーミングサービスのためのクライアントの動作方法は、ファイルＵＲＬ及び再生情報要求を指示する第１媒介変数を含む第１要求パケットを送信するステップと、前記ファイルＵＲＬに対応するファイルの再生情報を含む第１応答パケットを受信するステップと、前記ファイルＵＲＬ及びデータ要求を指示する第２媒介変数を含む第２要求パケットを送信するステップと、前記ファイル内の前記第２媒介変数に対応するアドレス範囲のデータを含む第２応答パケットを受信するステップとを含む。
前記クライアントの動作方法は、前記第１媒介変数を予め決定した第１指示子に設定するステップと、前記第１応答パケットから前記ファイルを分割するチャンク大きさ、前記チャンク個数、前記ファイルに格納されたコンテンツの解像度、前記解像度と異なる第２解像度のコンテンツを格納する第２ファイルＵＲＬ、及び前記第２解像度を抽出するステップとをさらに含み得る。
前記クライアントの動作方法は、前記第２媒介変数を最初インデックスに設定するステップと、前記第２応答パケットのデータをバッファに入力するステップとをさらに含み得る。前記クライアントの動作方法は、バッファの残量をチェックするステップと、前記バッファの残量が閾値以下になれば、前記第２媒介変数を次の再生するチャンクのインデックスに設定するステップと、前記第２応答パケットのデータを前記バッファに入力するステップとをさらに含み得る。
前記クライアントの動作方法は、前記第２媒介変数を最初インデックスに設定するステップと、前記第２応答パケットから前記ファイルのキーフレーム情報のためのオフセットアドレスを抽出するステップとをさらに含み得る。前記クライアントの動作方法は、前記オフセットアドレスのデータが前記第２応答パケットに含まれた場合、前記第２応答パケットから前記キーフレーム情報を抽出するステップをさらに含み得る。
前記クライアントの動作方法は、前記オフセットアドレスのデータが前記第２応答パケットに含まれない場合、データ要求を指示する第３媒介変数を前記オフセットアドレスに設定するステップと、前記ファイルＵＲＬ及び前記第３媒介変数を含む第３要求パケットを送信するステップと、前記ファイル内の前記第３媒介変数に対応するアドレス範囲のデータを含む第３応答パケットを受信するステップと、前記第３応答パケットから前記キーフレーム情報を抽出するステップとをさらに含み得る。
前記クライアントの動作方法は、前記第２応答パケットのデータをバッファに入力するステップと、前記データが再生される間に前記ファイルのキーフレームを抽出するステップと、前記キーフレームに基づいて前記ファイルのキーフレーム情報を生成するステップとをさらに含み得る。
前記クライアントの動作方法は、解像度の変更入力を受信するステップと、前記ファイルＵＲＬを前記解像度の変更入力に含まれた新しい解像度に対応する第２ファイルＵＲＬに設定するステップと、前記第１媒介変数を予め決定した第２指示子に設定するステップと、前記第１応答パケットから前記第２ファイルを分割するチャンク大きさ、及び前記チャンク個数を抽出するステップとをさらに含み得る。
前記クライアントの動作方法は、解像度の変更入力を受信するステップと、前記ファイルＵＲＬを前記解像度の変更入力に含まれた新しい解像度に対応する第２ファイルＵＲＬに設定するステップと、前記第２ファイルのキーフレーム情報に基づいて現在の再生時間に対応するキーフレームを検出するステップと、前記第２媒介変数を前記検出されたキーフレームのアドレスに設定するステップと、前記第２応答パケットのデータをバッファに入力するステップとをさらに含み得る。
前記クライアントの動作方法は、解像度の変更入力を受信するステップと、前記ファイルＵＲＬを前記解像度の変更入力に含まれた新しい解像度に対応する第２ファイルＵＲＬに設定するステップと、現在の再生時間及び全体再生時間に基づいて前記現在の再生時間に対応するチャンクを推定するステップと、前記第２媒介変数を前記推定されたチャンクのインデックスに設定するステップと、前記第２応答パケットの時間範囲が前記現在の再生時間を含む場合、前記第２応答パケットのデータから前記現在の再生時間に最も近いキーフレームを検出するステップと、前記検出されたキーフレーム以後のデータを前記バッファに入力するステップとをさらに含み得る。
前記クライアントの動作方法は、前記第２応答パケットの時間範囲が前記現在の再生時間を含まない場合、前記現在の再生時間に対応する新しいインデックスを推定するステップと、データ要求を指示する第３媒介変数を前記新しいインデックスに設定するステップと、前記ファイルＵＲＬ及び前記第３媒介変数を含む第３要求パケットを送信するステップと、前記ファイル内の前記第３媒介変数に対応するアドレス範囲のデータを含む第３応答パケットを受信するステップと、前記第３応答パケットのデータから前記現在の再生時間に最も近いキーフレームを検出するステップとをさらに含み得る。
前記クライアントの動作方法は、探索時間を受信するステップと、前記ファイルのキーフレーム情報を用いて前記探索時間に対応するキーフレームを検出するステップと、前記第２媒介変数を前記検出されたキーフレームのアドレスに設定するステップと、前記第２応答パケットのデータをバッファに入力するステップとをさらに含み得る。
前記クライアントの動作方法は、探索時間を受信するステップと、前記探索時間と前記ファイルの全体再生時間に基づいて前記探索時間に対応するチャンクを推定するステップと、前記第２媒介変数を前記推定されたチャンクのインデックスに設定するステップと、前記第２応答パケットの時間範囲が前記探索時間を含む場合、前記第２応答パケットのデータから前記探索時間に最も近いキーフレームを検出するステップと、前記検出されたキーフレーム以後のデータをバッファに入力するステップとをさらに含み得る。
前記クライアントの動作方法は、前記第２応答パケットの時間範囲が前記探索時間を含まない場合、前記探索時間に対応する新しいインデックスを推定するステップと、データ要求を指示する第３媒介変数を前記新しいインデックスに設定するステップと、前記ファイルＵＲＬ及び前記第３媒介変数を含む第３要求パケットを送信するステップと、前記ファイル内の前記第３媒介変数に対応するアドレス範囲のデータを含む第３応答パケットを受信するステップと、前記第３応答パケットのデータから前記探索時間に最も近いキーフレームを検出するステップとをさらに含み得る。
他の一実施形態に係るストリーミングサービスのためのサーバの動作方法は、ファイルＵＲＬ及び媒介変数を含む要求パケットを受信するステップと、前記媒介変数がデータ要求を指示する場合、前記ファイルＵＲＬに対応するファイル内の前記媒介変数に対応するアドレス範囲のデータを応答するステップと、前記媒介変数が再生情報要求を指示する場合、前記ファイルの再生情報を応答するステップとを含む。
前記データを応答するステップは、前記媒介変数がインデックスを含む場合、前記ファイル内の前記インデックスに対応するアドレス範囲のデータを応答するステップと、前記媒介変数がアドレスを含む場合、前記ファイル内の前記アドレスに対応するアドレス範囲のデータを応答するステップのうち少なくとも１つを含み得る。
前記アドレスに対応するアドレス範囲のデータを応答するステップは、前記媒介変数が２つのアドレスを含む場合、前記ファイル内の前記２つのアドレスの間のデータを応答するステップと、前記媒介変数が１つのアドレスを含む場合、前記ファイル内の前記１つのアドレスと前記ファイルの終了の間のデータを応答するステップのうち少なくとも１つを含み得る。
前記再生情報を応答するステップは、前記媒介変数が予め決定した第１指示子を含む場合、前記ファイルを分割するチャンク大きさ、前記チャンク個数、前記ファイルに格納されたコンテンツの解像度、前記解像度と異なる第２解像度のコンテンツを格納する第２ファイルＵＲＬ、及び前記第２解像度を応答するステップと、前記媒介変数が予め決定した第２指示子を含む場合、前記チャンク大きさ及び前記チャンク個数を応答するステップのうち少なくとも１つを含み得る。
一実施形態に係るクライアントの動作方法を説明する図である。 一実施形態に係るサーバの動作方法を説明する図である。 一実施形態に係るサーバの動作方法を説明する図である。 一実施形態に係るサーバの動作方法を説明する図である。 一実施形態に係るサーバの動作方法を説明する図である。 一実施形態に係るサーバの動作方法を説明する図である。 一実施形態に係るサーバの動作方法を説明する図である。 一実施形態に係るクライアントの基本動作を説明する図である。 一実施形態に係るキーフレーム情報を取得する動作を説明する図である。 一実施形態に係るキーフレーム情報を取得する動作を説明する図である。 一実施形態に係るキーフレーム情報を取得する動作を説明する図である。 一実施形態に係る解像度変更動作を説明する図である。 一実施形態に係る解像度変更動作を説明する図である。 一実施形態に係る解像度変更動作を説明する図である。 一実施形態に係る探索動作を説明する図である。 一実施形態に係る探索動作を説明する図である。 一実施形態に係る探索動作を説明する図である。 複数のｕｒｌストリームを用いるクライアントの動作を説明する図である。 複数のｕｒｌストリームを用いるクライアントの動作を説明する図である。
以下、実施形態を添付する図面を参照しながら詳細に説明する。各図面に提示された同一の参照符号は同一の部材を示す。下記で説明される実施形態は、ストリーミングサービスのためのクライアント、又はサーバに適用され得る。
一実施形態に係るクライアントは、ストリーミングサービスが提供されるコンピューティング装置であって、例えば、パーソナルコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、ＰＤＡ、スマートフォンなどを含む。クライアントには、ｈｔｔｐプロトコルを用いてサーバと通信するクライアントアプリケーション、例えば、ｓｗｆプレーヤーなどが設けられる。一実施形態に係るサーバは、ストリーミングサービスを提供するコンピューティング装置であって、例えば、ウェブサーバーなどを含む。サーバは、サーバ専用コンピューティング装置だけではなく、パーソナルコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、ＰＤＡ、スマートフォンなどでも構成し得る。サーバには、ｈｔｔｐプロトコルを用いてクライアントと通信するサーバアプリケーション、例えば、アパッチサーバなどが設けられ得る。
図１は、一実施形態に係るクライアントの動作方法を説明する図である。図１を参照すると、一実施形態に係るクライアント１１０は、第１要求パケットをサーバ１２０に送信する。第１要求パケットは、ファイルＵＲＬ及び再生情報要求を指示する第１媒介変数を含み得る。ここで、ファイルＵＲＬは、コンピュータネットワーク上のリソースを固有に指示する情報であって、例えば、ストリーミングサービスの対象となる映像ファイルを固有に指示する情報であり得る。再生情報要求を指示する第１媒介変数は、予め決定した文字又は文字列であり、例えば「ｉ」又は「ｒ」などであり得る。クライアント１１０は、第１要求パケットをサーバ１２０に送信することによりファイルＵＲＬに対応するファイルの再生情報を要求する。ファイルの再生情報は、ストリーミングサービスによってファイルを再生するための情報であって、例えば、送信のためにファイルが分割された情報などを含む。
クライアント１１０は、サーバ１２０から第１応答パケットを受信する。第１応答パケットは、ファイルＵＲＬに対応するファイルの再生情報を含む。上述したように、実施形態は、ファイルを容量単位に分割して送信するストリーミング技術を提供し得る。以下、ファイルを分割する個々の容量単位はチャンクのように指する。
一実施形態によれば、ファイルを分割するチャンク大きさはサーバ１２０によって決定される。サーバ１２０は、ファイルを分割するチャンク大きさに応じてファイルを分割するために必要なチャンク個数を算出する。この場合、第１応答パケットの再生情報はチャンク大きさ及びチャンク個数を含み得る。又は、サーバ１２０は、第１応答パケットにチャンク大きさ及びファイルの総大きさを含ませる。この場合、クライアント１１０は、チャンク大きさ及びファイルの総大きさに基づいてファイルを分割するために必要なチャンク個数を算出することができる。
他の実施形態によれば、ファイルを分割するチャンク大きさはクライアント１２０によって決定される。クライアント１２０は、チャンク大きさを第１媒介変数に含ませてサーバ１２０に送信する。サーバ１２０は、受信されたチャンク大きさに基づいてファイルを分割するために必要なチャンク個数を算出する。この場合、第１応答パケットの再生情報はチャンク個数を含み得る。又は、サーバ１２０は、第１応答パケットにファイルの総大きさを含ませる。この場合、クライアント１１０は、すでにチャンク大きさを知っているため、ファイルの総大きさに基づいてファイルを分割するために必要なチャンク個数を算出することができる。
クライアント１１０は、第２要求パケットをサーバ１２０に送信する。第２要求パケットは、ファイルＵＲＬ及びデータ要求を指示する第２媒介変数を含む。データ要求を指示する第２媒介変数は、ファイル内アドレスを指示する数字又は文字列であって、例えば「アドレスｒ」又は「アドレス１ｒアドレス２」などであってもよい。以下、ファイル内アドレスはバイトアドレスであり得る。クライアント１１０は、第２要求パケットをサーバ１２０に送信することで、ファイルＵＲＬに対応するファイルの少なくとも一部を容量単位に要求する。
クライアント１１０は、サーバ１２０から第２応答パケットを受信する。第２応答パケットは、ファイルＵＲＬに対応するファイル内第２媒介変数に対応するアドレス範囲のデータを含む。クライアント１１０は、第２応答パケットのデータをバッファに入力する。以下で詳細に説明するが、バッファに入力されたデータはデマルチプレクサ及び／又はデコーダによって再生され得る。
図２〜図７は、一実施形態に係るサーバの動作方法を説明する図である。図２を参照すると、一実施形態に係るサーバ２２０は、クライアント２１０から要求パケットを受信する。要求パケットはファイルＵＲＬ及び媒介変数を含み得る。ファイルＵＲＬは、コンピュータネットワーク上のリソースを固有に指示する情報であって、例えば、サーバ２２０に格納されたファイルを指示する情報であり得る。
サーバ２２０は媒介変数がデータ要求を指示するか、或いは再生情報要求を指示するかを判断する。例えば、サーバ２２０は、要求パケットに含まれた媒介変数が再生情報要求を指示する第１媒介変数であるか、或いはデータ要求を指示する第２媒介変数であるかを判断する。再生情報要求を指示する第１媒介変数及びデータ要求を指示する第２媒介変数は予め決定され、サーバ２２０とクライアント２１０は予め決定した第１媒介変数及び第２媒介変数を共有する。
媒介変数が再生情報要求を指示する場合、サーバ２２０はファイルの再生情報を応答する。一例として、図３を参照すると、サーバ３２０は、クライアント３１０からファイル１ＵＲＬ及び第１指示子を含む要求パケットを受信する。ここで、第１指示子は、予め決定した文字又は文字列として、例えば「ｒ」であってもよい。要求パケット内でファイル１ＵＲＬ及び第１指示子は予め決定した符号、例えば「？」に区分できる。サーバ３２０は、要求パケットに含まれた媒介変数が第１指示子を含むか否かを判断する。
要求パケットに含まれた媒介変数が第１指示子を含む場合、サーバ３２０は、ファイル１ＵＲＬに対応する第１ファイルを分割するチャンク大きさ（ｃｈｕｎｋ大きさ）、チャンク個数（ｃｈｕｎｋ個数）、及びファイルリストを応答する。ファイルリストは、第１ファイル解像度、及び第１ファイルに格納されたコンテンツの第１解像度と異なる解像度のコンテンツを格納している少なくとも１つのファイルＵＲＬ及び解像度を含む。例えば、ファイルリストは、第１ファイルに格納されたコンテンツの第１解像度（ファイル１解像度）、第１解像度と異なる第２解像度のコンテンツを格納する第２ファイルＵＲＬ（ファイル２ＵＲＬ）、及び第２解像度（ファイル２解像度）などを含み得る。第１解像度とは異なる解像度のコンテンツを格納しているファイルが複数である場合、ファイルリストは複数のファイルＵＲＬ及び解像度を含み得る。
サーバ３２０は、ファイル１ＵＲＬに対応する第１ファイルが格納されたディレクトリ内で第１解像度とは異なる解像度のコンテンツを格納する少なくとも１つのファイルを検索する。例えば、第１ファイルが格納されたディレクトリに表１のようなファイルが格納され、第１ファイルが「ミュージックビデオ．ｍｐ４」である場合、サーバ３２０は「ミュージックビデオ＿７２０ｐ．ｍｐ４」、「ミュージックビデオ＿４８０ｐ．ｍｐ４」、及び「ミュージックビデオ＿３６０ｐ．ｍｐ４」を検索する。
Figure 2017529726
この場合、サーバ３２０は、表２のような応答パケットを生成し、応答パケットをクライアント３１０に送信する。
Figure 2017529726
ここで、応答パケットの最初の元素はチャンク大きさであり、２番目の元素はチャンク個数であり、３番目の元素はファイル１解像度であり、４番目の元素はファイル２ＵＲＬであり、５番目の元素はファイル２解像度であり、６番目の元素はファイル３のＵＲＬであり、７番目の元素はファイル３の解像度であり、８番目の元素はファイル４のＵＲＬであり、９番目の元素はファイル４の解像度である。チャンク大きさはバイト単位であり得る。
場合に応じて、統一性のある資料構造のために、ファイルリストは同一のコンテンツに対応する全てのファイルＵＲＬ及び解像度を含み得る。例えば、ファイルリストは、第１ファイルＵＲＬ、第１ファイル解像度、及び第１ファイル解像度とは異なる解像度のコンテンツを格納する少なくとも１つのファイルＵＲＬ及び解像度を含む。この場合、サーバ３２０は、表３のような応答パケットを生成し、応答パケットをクライアント３１０に送信する。
Figure 2017529726
ここで、応答パケットの最初の元素はチャンク大きさであり、２番目の元素はチャンク個数であり、３番目の元素はファイル１ＵＲＬであり、４番目の元素はファイル１解像度であり、５番目の元素はファイル２ＵＲＬであり、６番目の元素はファイル２解像度であり、７番目の元素はファイル３のＵＲＬであり、８番目の元素はファイル３の解像度であり、９番目の元素はファイル４のＵＲＬであり、１０番目の元素はファイル４の解像度である。チャンク大きさはバイト単位であり得る。現在の要求されたファイル（第１ファイル）の解像度が１０８０（ファイル１解像度）であることを表示するために、ファイル１解像度の末に予め決定した文字又は文字列、例えば「ａ」が追加される。
それぞれのファイルはファイル名に解像度を含み得る。例えば、サーバ３２０は、オリジナル映像ファイルである「ミュージックビデオ．ｍｐ４」のアップロードが完了すると、「ミュージックビデオ．ｍｐ４」を新しい解像度にエンコーディングする。ここで、サーバ３２０は、オリジナル映像ファイルのファイル名に新しい解像度を付加し、新しい解像度のファイル名を決定し得る。この場合、サーバ３２０は、ファイル名に基づいて該当するファイルに格納されたコンテンツの解像度を取得できる。
他の例として、図４を参照すると、サーバ４２０は、クライアント４１０からファイルＵＲＬ及び第２指示子を含む要求パケットを受信する。ここで、第２指示子は予め決定した文字又は文字列として、例えば、「ｉ」であり得る。要求パケット内でファイルＵＲＬ及び第２指示子は予め決定した符号、例えば「？」に区分される。サーバ４２０は、要求パケットに含まれた媒介変数が第２指示子を含むか否かを判断する。要求パケットに含まれた媒介変数が第２指示子を含む場合、サーバ４２０は、ファイルＵＲＬに対応するファイルを分割するチャンク大きさ（チャンク大きさ）、及びチャンク個数（チャンク個数）を応答する。
例えば、要求パケットが「ファイル３のＵＲＬ？ｉ」である場合、サーバ４２０は表４のような応答パケットを生成し、応答パケットをクライアント４１０に送信する。
Figure 2017529726
ここで、応答パケットの最初の元素はチャンク大きさであり、２番目の元素はチャンク個数である。チャンク大きさはバイト単位であり得る。表１を参照すると、それぞれのファイルを分割するチャンク大きさはそれぞれ異なるように設定される。ただし、実施形態は、それぞれのファイルを分割するチャンク大きさがそれぞれ相異に設定されるよう制限することはない。例えば、それぞれのファイルを分割するチャンク大きさは互いに同一に設定されてもよい。
再び図２を参照すると、媒介変数がデータ要求を指示する場合、サーバ２２０は、ファイルＵＲＬに対応するファイル内の媒介変数に対応するアドレス範囲のデータを応答し得る。一例として、図５を参照すると、サーバ５２０は、クライアント５１０からファイルＵＲＬ及びインデックスを含む要求パケットを受信する。ここで、インデックスは０以上の整数であり得る。要求パケット内のファイルＵＲＬ及びインデックスは予め決定した符号、例えば「？」に区分する。サーバ５２０は、要求パケットに含まれた媒介変数がインデックスを含むか否かを判断する。要求パケットに含まれた媒介変数がインデックスを含む場合、サーバ５２０は、ファイルＵＲＬに対応するファイル内のインデックスに対応するアドレス範囲のデータを応答する。
例えば、要求パケットが「ファイルＵＲＬ？ｎ」である場合、サーバ５２０は、ファイルＵＲＬに対応するファイルを分割するチャンク大きさを取得する。ファイルのためのチャンク大きさが２０９７１５２バイトである場合、サーバ５２０は、表５のようなデータをクライアント５１０に送信する。表５のデータはチャンク−ｎのように称される。
Figure 2017529726
ここで、［第１バイトアドレス、第２バイトアドレス］は第１バイトアドレスから第２バイトアドレスまでのデータである。
異なる例として、ファイルＵＲＬ及びインデックスを含む要求パケットは、ヘッダを含む。ヘッダは、アドレス範囲パラメータを含み得る。ヘッダはｈｔｔｐヘッダであり得る。サーバ５２０は、要求パケットのヘッダに含まれたアドレス範囲パラメータを用いてインデックスに対応するチャンクの一部のデータをクライアント５１０に送信する。例えば、要求パケットに含まれたファイルＵＲＬに対応するファイルのためのチャンク大きさが２０９７１５２バイトであり、要求パケットに含まれたインデックスがｎであり、要求パケットのアドレス範囲パラメータが「ｓｔａｒｔ ｒａｎｇｅ、ｅｎｄ ｒａｎｇｅ」である場合、サーバ５２０は表６のようなデータをクライアント５１０に送信する。
Figure 2017529726
ここで、ｓｔａｒｔ ｒａｎｇｅ及びｅｎｄ ｒａｎｇｅの単位はバイトである。サーバ５２０はキャッシュサーバを含む。キャッシュサーバは、ファイルＵＲＬ及びインデックスに基づいてチャンクデータをキャッシュする。この場合、要求パケットのヘッダに含まれたアドレス範囲パラメータが異なっても、要求パケットに含まれたファイルＵＲＬ及びインデックスが同一であれば、キャッシュサーバにキャッシュされたチャンクデータを活用することができる。
更なる例として、図６を参照すると、サーバ６２０は、クライアント６１０からファイルＵＲＬ及びアドレスを含む要求パケットを受信する。ここで、アドレスはバイトアドレスである。要求パケット内のファイルＵＲＬ及びアドレスは、予め決定した符号、例えば「？」に区分する。アドレスとインデックスを区別するために、アドレスの後には予め決定した文字又は文字列、例えば、「ｒ」が追加され得る。サーバ６２０は、要求パケットに含まれた媒介変数がアドレスを含むか否かを判断する。要求パケットに含まれた媒介変数がアドレスを含む場合、サーバ６２０は、ファイルＵＲＬに対応するファイル内のアドレスに対応するアドレス範囲のデータを応答できる。
例えば、要求パケットが「ファイルＵＲＬ？アドレスｒ」である場合、サーバ６２０は表７のようなデータをクライアント６１０に送信する。
Figure 2017529726
ここで、［アドレス、ファイル終了］はアドレスからファイル終了までのデータである。
更なる例として、図７を参照すると、サーバ７２０は、クライアント７１０からファイルＵＲＬ及び複数のアドレス、例えば、第１アドレスと第２アドレスを含む要求パケットを受信する。ここで、複数のアドレスは、各バイトアドレスであり得る。要求パケット内ファイルＵＲＬ及び複数のアドレスは予め決定した符号、例えば、「？」に区分する。また、複数のアドレスを互いに区別するために、複数のアドレスの間に予め決定した文字又は文字列、例えば、「ｒ」が追加され得る。サーバ７２０は、要求パケットに含まれた媒介変数が複数のアドレスを含むか否かを判断する。要求パケットに含まれた媒介変数が複数のアドレスを含む場合、サーバ７２０は、ファイルＵＲＬに対応するファイル内の複数のアドレスに対応するアドレス範囲のデータを応答できる。
例えば、要求パケットが「ファイルＵＲＬ？アドレス１ｒアドレス２」である場合、サーバ７２０は表８のようなデータをクライアント７１０に送信する。
Figure 2017529726
ここで、［アドレス１、アドレス２］は第１アドレスから第２アドレスまでのデータである。
図８は、一実施形態に係るクライアントの基本動作を説明する図である。図８を参照すると、一実施形態に係るクライアント８１０は、ストリーミングサービスによって再生しようとする第１ファイルＵＲＬ、例えば、「ファイル１ＵＲＬ」を取得する。クライアント８１０は、第１ファイルの最初チャンクを要求する要求パケット、例えば、「ファイル１ＵＲＬ？０」をサーバ８２０に送信する。また、クライアント８１０は、第１ファイルの再生情報を要求する要求パケット、例えば、「ファイル１ＵＲＬ？ｒ」をサーバ８２０に送信する。
クライアント８１０は、サーバ８２０から第１ファイルの再生情報を含む応答パケットを受信する。例えば、第１ファイルの再生情報は、チャンク大きさ、チャンク個数、及びファイルリストを含み得る。ファイルリストは、ファイル１解像度、ファイル２ＵＲＬ、及びファイル２解像度などを含む。クライアント８１０は、応答パケットから第１ファイルの再生情報を抽出し得る。
クライアント８１０は、サーバ８２０から第１ファイルの最初チャンク、例えば、「チャンク−０」を含む応答パケットを受信する。クライアント８１０は、「チャンク−０」を再生することができる。例えば、クライアント８１０は、応答パケットに含まれた「チャンク−０」をバッファに入力する。バッファに入力されたデータは、デマルチプレクサ及び／又はデコーダによって再生され得る。
クライアント８１０は、バッファの残量をチェックする。例えば、バッファの残量が予め決定した閾値以下であるか否かを判断する。予め決定した閾値は、バイト単位又は時間単位であり得る。予め決定した閾値が時間単位である場合、再生中であるコンテンツの解像度に基づいて時間単位閾値がバイト単位閾値に換算され得る。
バッファの残量が予め決定した閾値以下である場合、クライアント８１０は、第１ファイルの次のチャンクを要求する要求パケットをサーバ８２０に送信する。例えば、クライアント８１０は、現在の再生中であるチャンクのインデックスに１を加えることで、次のチャンクのためのインデックスを算出できる。現在の再生中であるチャンクのインデックスが０である場合、クライアント８１０は「ファイル１ＵＲＬ？１」をサーバ８２０に送信する。
クライアント８１０は、サーバ８２０から次のチャンク、例えば、「チャンク−１」を含む応答パケットを受信する。クライアント８１０は、「チャンク−１」を再生することができる。例えば、クライアント８１０は、応答パケットに含まれた「チャンク−１」をバッファに入力する。バッファに入力されたデータは、デマルチプレクサ及び／又はデコーダによって再生され得る。
図９〜図１１は、一実施形態に係るキーフレーム情報を取得する動作を説明する図である。一実施形態に係るクライアントは、ストリーミングサービスによって再生しようとする第１ファイルのキーフレーム情報を取得できる。第１ファイルに格納されたコンテンツは、複数のフレームから構成される。複数のフレームは、画面の情報を完全に入れたフレームとその他のフレームを参照するフレームに分類される。画面の情報を完全に入れたフレームはキーフレームと称される。他のフレームを参照するフレームは、該当フレームの画面の情報を完全に入れないため、キーフレームに比べて小さい容量を有する。
第１ファイルのキーフレーム情報は、第１ファイルに格納されたコンテンツを構成している複数のフレームのうちキーフレームに関する情報を含み得る。例えば、キーフレーム情報は、キーフレームそれぞれのインデックス、バイトアドレス、及びタイムスタンプなどを含んでもよい。
一例として、第１ファイルは、キーフレーム情報を格納することができる。例えば、第１ファイルがｍｐ４ファイルの形式を有する場合、第１ファイルはキーフレーム情報を格納する。この場合、クライアントは、キーフレーム情報が格納されたアドレス範囲のデータをサーバから受信することでキーフレーム情報を取得できる。
より具体的に、図９を参照すると、クライアント９１０は、第１ファイルの最初チャンクを要求する要求パケット、例えば、「ファイル１ＵＲＬ？０」をサーバ９２０に送信し得る。クライアント９１０は、サーバ９２０から第１ファイルの最初チャンク、例えば、「チャンク−０」を含む応答パケットを受信する。クライアント９１０は、第１ファイルの最初チャンクからキーフレーム情報のオフセットアドレスを抽出することができる。
クライアント９１０は、オフセットアドレスが最初チャンクのアドレス範囲内に含まれるか否かを判断することで、オフセットアドレスのデータが最初チャンクに含まれているか否かを判断する。オフセットアドレスが最初チャンクのアドレス範囲内に含まれている場合、クライアント９１０はすでに受信された最初チャンクからキーフレーム情報を取得できる。
オフセットアドレスが最初チャンクのアドレス範囲に含まれていない場合、クライアント９１０は、オフセットアドレス以後のデータを要求する要求パケット、例えば、「ファイル１ＵＲＬ？オフセットアドレスｒ」をサーバ９２０に送信し得る。クライアント９１０は、オフセットアドレス以後のデータ、例えば、［オフセットアドレス、ファイル１終了］を含む応答パケットを受信する。クライアント９１０は、応答パケットからキーフレーム情報を抽出できる。
異なる例として、第１ファイルは、キーフレーム情報を格納しなくてもよい。例えば、第１ファイルがｆｌｖファイルの形式を有する場合、第１ファイルはキーフレーム情報を格納できないことがある。この場合、クライアントは第１ファイルを再生する途中キーフレーム情報を生成し得る。
より具体的に、図１０を参照すると、クライアント１０１０は第１ファイルの最初チャンクを要求する要求パケット、例えば「ファイル１ＵＲＬ？０」をサーバ１０２０に送信する。クライアント１０１０は、サーバ１０２０から第１ファイルの最初チャンク、例えば、「チャンク−０」を含む応答パケットを受信する。クライアント１０１０は、「チャンク−０」を再生する。例えば、クライアント１０１０は、応答パケットに含まれた「チャンク−０」をバッファに入力する。バッファに入力されたデータは、デマルチプレクサ及び／又はデコーダによって再生され得る。
クライアント１０１０は、「チャンク−０」が再生する間に「チャンク−０」に含まれたキーフレームを抽出する。クライアント１０１０は、抽出されたキーフレームに基づいて第１ファイルのためのキーフレーム情報を生成する。例えば、図１１を参照すると、クライアント１０１０は、キーフレーム情報を含む探索テーブル１１００を生成し得る。
図面に図示していないが、クライアント１０１０は、最初チャンクの他のチャンクを再生する途中にもキーフレーム情報を生成することができる。例えば、クライアント１０１０は、第１ファイルに格納されたコンテンツが再生する間に探索テーブル１１００を持続的にアップデートできる。
図１２〜図１４は、一実施形態に係る解像度変更動作を説明する図である。図１２を参照すると、一実施形態に係るクライアント１２１０は、ストリーミングサービスによって再生しようとする第１ファイルＵＲＬ、例えば、「ファイル１ＵＲＬ」を取得する。クライアント１２１０は、第１ファイルの最初チャンクを要求する要求パケット、例えば、「ファイル１ＵＲＬ？０」をサーバ１２２０に送信する。また、クライアント１２１０は、第１ファイルの再生情報を要求する要求パケット、例えば、「ファイル１ＵＲＬ？ｒ」をサーバ１２２０に送信する。
クライアント１２１０は、サーバ１２２０から第１ファイルの再生情報を含む応答パケットを受信する。例えば、第１ファイルの再生情報はチャンク大きさ、チャンク個数、ファイルリストを含み得る。ファイルリストは、ファイル１解像度、ファイル２ＵＲＬ、及びファイル２解像度などを含み得る。クライアント８１０は、応答パケットから第１ファイルの再生情報を抽出し得る。
クライアント１２１０は、サーバ１２２０から第１ファイルの最初チャンク、例えば、「ファイル１チャンク−０」を含む応答パケットを受信する。クライアント１２１０は、「ファイル１チャンク−０」を再生する。例えば、クライアント８１０は、応答パケットに含まれた「ファイル１チャンク−０」をバッファに入力する。バッファに入力されたデータはデマルチプレクサ及び／又はデコーダによって再生され得る。
クライアント１２１０は、解像度の変更入力を受信する。例えば、クライアント１２１０は、予め決定したインタフェースを介してユーザに現在の再生中であるコンテンツの解像度及び／又は変更可能な解像度を提供し得る。クライアント１２１０は、インタフェースを介して解像度の変更入力を受信する。
場合に応じて、クライアント１２１０は、自動で解像度変更の有無を決定することができる。例えば、クライアント１２１０は、通信状態、バッファリングの有無、通信費用などに基づいて解像度変更の有無を自動で決定できる。
以下、第１解像度から第２解像度に変更する実施形態について説明する。クライアント１２１０は、第２解像度に該当する第２ファイルの再生情報を要求する要求パケット、例えば、「ファイル２ＵＲＬ？ｉ」をサーバ１２２０に送信する。クライアント１２１０は、すでに解像度リストを有しているため第２指示子、例えば、「ｉ」を用いて第２ファイルの再生情報を要求する。クライアント１２１０は、サーバ１２２０から第２ファイルの再生情報を含む応答パケットを受信する。例えば、第２ファイルの再生情報は、チャンク大きさ、及びチャンク個数を含み得る。
クライアント１２１０は、第２ファイルの最初チャンクを要求する要求パケット、例えば、「ファイル２ＵＲＬ？０」をサーバ１２２０に送信する。クライアント１２１０は、サーバ１２２０から第２ファイルの最初チャンク、例えば「ファイル２チャンク−０」を含む応答パケットを受信する。図面に図示していないが、クライアント１２１０は、第２ファイルのキーフレーム情報を取得する。例えば、クライアント１２１０は、図９を参照して前述した実施形態に基づいて第２ファイルのキーフレーム情報を取得できる。
クライアント１２１０は、第２ファイルのキーフレーム情報に基づいて現在の再生時間に対応するキーフレームを検出する。一例として、クライアント１２１０は、現在の再生時間後に予め決定した時間、例えば、１秒、以後のフレームに最も近いキーフレームを検出し得る。異なる例として、クライアント１２１０は、第１ファイルのバッファ情報に基づいて現在の再生時間に対応するキーフレームを検出し得る。更なる例として、クライアント１２１０は、第１ファイルが現在のバッファに入力された分量以後の時間に該当するキーフレームを検出し得る。
クライアント１２１０は、検出されたキーフレームのアドレス後のデータを要求する要求パケット、例えば、「ファイル２ＵＲＬ？キーフレームアドレスｒ該当チャンク終了アドレス」をサーバ１２２０に送信する。「該当チャンク終了アドレス」は検出されたキーフレームが属するチャンクの終了アドレスであり、クライアント１２１０は第２ファイルの再生情報を用いて検出されたキーフレームが属するチャンクの終了アドレスを算出する。図面に図示していないが、クライアント１２１０は、検出されたキーフレームが属するチャンクを要求する要求パケット、例えば、「ファイル２ＵＲＬ？該当チャンクインデックス」をサーバ１２２０に送信しながら、要求パケットのヘッダに含まれたアドレス範囲パラメータを用いて［キーフレームアドレス、該当チャンク終了］のデータを要求する。他の実施形態によれば、クライアント１２１０は、「ファイル２ＵＲＬ？キーフレームアドレスｒ」をサーバ１２２０に送信することで、［キーフレームアドレス、ファイル終了］のデータを要求し得る。
クライアント１２１０は、キーフレームアドレス以後のデータ、例えば、［キーフレームアドレス、該当チャンク終了アドレス］を含む応答パケットを受信する。クライアント１２１０は、キーフレームアドレス以後のデータをバッファに入力することによって、新しい解像度を有する第２ファイルを再生し得る。
図１３を参照すると、他の実施形態に係るクライアント１３１０は、第１ファイルを再生中の解像度の変更入力を受信する。例えば、クライアント１３１０は、予め決定したインタフェースを介してユーザに現在の再生中であるコンテンツの解像度及び／又は変更可能な解像度を提供することができる。クライアント１３１０は、インタフェースを介して解像度の変更入力を受信する。場合に応じて、クライアント１３１０は、自動で解像度変更の有無を決定し得る。例えば、クライアント１３１０は、通信状態、バッファリングの有無、通信費用などに基づいて解像度変更の有無を自動決定できる。
以下、第１解像度から第２解像度に変更する実施形態について説明する。クライアント１３１０は、第２ファイルの再生情報を要求する要求パケット、例えば、「ファイル２ＵＲＬ？ｉ」をサーバ１３２０に送信する。クライアント１３１０は、すでに解像度リストを有しているため、第２指示子、例えば、「ｉ」を用いて第２ファイルの再生情報を要求する。クライアント１３１０は、サーバ１３２０から第２ファイルの再生情報を含む応答パケットを受信する。例えば、第２ファイルの再生情報はチャンク大きさ、及びチャンク個数を含み得る。
クライアント１３１０は、第２ファイルの最初チャンクを要求する要求パケット、例えば、「ファイル２ＵＲＬ？０」をサーバ１３２０に送信する。クライアント１３１０は、サーバ１３２０から第２ファイルの最初チャンク、例えば、「ファイル２チャンク−０」を含む応答パケットを受信する。
ここで、第２ファイルは、キーフレーム情報を格納しなくてもよい。この場合、クライアント１３１０は、現在の再生時間及び全体再生時間に基づいて、第２ファイルのチャンクのうち現在の再生時間に対応するチャンクを推定する。例えば、クライアント１３１０は、現在の再生時間対全体再生時間の比を用いて、第２ファイルのチャンクのうち現在の再生時間に対応するチャンクを推定できる。
クライアント１３１０は、推定されたチャンクのデータを要求する要求パケット、例えば、「ファイル２ＵＲＬ？ｍ」をサーバ１３２０に送信する。ここで、「ｍ」は推定されたチャンクのインデックスである。クライアント１３１０は、推定されたチャンクのデータ、例えば、「ファイル２チャンク−ｍ」を含む応答パケットを受信する。クライアント１３１０は、推定されたチャンクのデータを用いて推定成功の有無を判断する。例えば、クライアント１３１０は、推定されたチャンク内の初めてのフレームの時間と現在の再生時間とを比較することによって、推定成功の有無を判断できる。
推定が失敗と判断される場合、クライアント１３１０は新しいチャンクを推定する。推定が成功であると判断される場合、推定されたチャンク内のキーフレームを抽出する。クライアント１３１０は、現在の再生時間に最も近いキーフレームを検出する。クライアント１３１０は、検出されたキーフレーム以後のデータをバッファに入力する。
図１４を参照すると、一実施形態に係るクライアント１４１０は、様々なビットレートを用いてサーバ１４２０からチャンクを受信する。上述したように、実施形態によれば、チャンクがキーフレームから始めることが要求されることなく、さらに、チャンクはキーフレームを含まなくてもよい。そのため、サーバ１４２０は、チャンクに合わせてエンコーディングしなくてもよく、サーバ１４２０は、ｍｐ４、ｆｌｖなどの一般的な映像ファイルを容量単位に分類して送信できる。サーバ１４２０とクライアント１４１０との間で送信されるチャンクがキーフレームから始めることと、キーフレームを含む条件が要求されないため、実施形態はクローズドＧＯＰ（Ｃｌｏｓｅｄ ＧＯＰ）のみならず、オープンＧＯＰ（Ｏｐｅｎ ＧＯＰ）もサポートできる。
クライアント１４１０は、バッファの大きさだけチャンクを予めダウンロードする。クライアント１４１０は、再生したチャンクを格納することにより、格納されたチャンクに属するフレームを再び再生するとき該当のチャンクを重複してダウンロードしないようにする。
図１５〜図１７は、一実施形態に係る探索動作を説明する図である。探索動作は、コンテンツをランダムアクセスする動作である。図１５を参照すると、一実施形態に係るクライアント１５１０は、第１ファイルのｎ番目のチャンクを要求する要求パケット、例えば、「ファイル１ＵＲＬ？ｎ」をサーバ１５２０に送信する。クライアント１５１０は、サーバ１５２０から第１ファイルのｎ番目のチャンク、例えば、「チャンク−ｎ」を含んでいる応答パケットを受信する。クライアント１５１０は、「チャンク−ｎ」をバッファに入力する。バッファに入力されたデータはデマルチプレクサ及び／又はデコーダによって再生され得る。
クライアント１５１０は、「チャンク−ｎ」が再生する間に探索入力を受信する。例えば、クライアント１５１０は、予め決定したインタフェースを介して探索入力を受信し得る。探索入力は探索時間を含み得る。
クライアント１５１０は、第１ファイルのキーフレーム情報に基づいて探索時間に対応するキーフレームを検出する。例えば、クライアント１５１０は探索時間のフレームに最も近いキーフレームが検出される。
クライアント１５１０は、検出されたキーフレームのアドレス以後のデータを要求する要求パケット、例えば、「ファイル１ＵＲＬ？キーフレームアドレスｒ該当チャンク終了アドレス」をサーバ１５２０に送信する。「該当チャンク終了アドレス」は、検出されたキーフレームが属するチャンクの終了アドレスであり、クライアント１５１０は、第１ファイルの再生情報を用いて検出されたキーフレームが属するチャンクの終了アドレスを算出する。図面には図示していないが、クライアント１５１０は、検出されたキーフレームが属するチャンクを要求する要求パケット、例えば、「ファイル１ＵＲＬ？該当チャンクインデックス」をサーバ１５２０に送信しながら、要求パケットのヘッダに含まれたアドレス範囲パラメータを用いて［キーフレームアドレス、該当チャンク終了］のデータを要求する。
クライアント１５１０はキーフレームアドレス以後のデータ、例えば、［キーフレームアドレス、該当チャンク終了アドレス］を含む応答パケットを受信する。クライアント１５１０は、キーフレームアドレス以後のデータをバッファに入力することによって、第１ファイルを探索して再生し得る。
図１６を参照すると、他の実施形態に係るクライアント１６１０は「ファイル１ＵＲＬ？ｎ」をサーバ１６２０に送信する。クライアント１６１０は、サーバ１６２０から「チャンク−ｎ」を含む応答パケットを受信する。クライアント１６１０は「チャンク−ｎ」を再生する。
クライアント１６１０は、「チャンク−ｎ」が再生する間に探索入力を受信する。クライアント１６１０は、第１ファイルのキーフレーム情報に基づいて探索時間に対応するキーフレームを検出する。例えば、クライアント１６１０は探索時間のフレームに最も近いキーフレームを検出し得る。
クライアント１６１０は、検出されたキーフレームが属するチャンクのデータを要求する要求パケット、例えば、「ファイルＵＲＬ？ｋ」をサーバ１６２０に送信し得る。ここで「ｋ」は、検出されたキーフレームが属するチャンクのインデックスである。クライアント１６１０は、検出されたキーフレームが属するチャンクのデータ、例えば、「ファイル１チャンク−ｋ」を含む応答パケットを受信する。クライアント１６１０は、キーフレームアドレス以後のデータをバッファに入力することによって、第１ファイルを探索して再生され得る。
図１６に示す探索動作は図１５に示す探索動作に比べてキャッシュサーバの効率性を増大させ、図１５に示す探索動作は図１６に示す探索動作に比べて実際送信されるデータの量を減少させ得る。実施形態は、キャッシュサーバの効率性及び実際送信されるデータの量との間のトレード−オフ関係を考慮して、図１５に示す探索動作と図１６に示す探索動作のうちいずれか１つに基づいて動作することができる。
図１７を参照すると、更なる実施形態に係るクライアント１７１０は、「チャンク−ｎ」を再生中に探索入力を受信する。探索入力は探索時間を含み得る。現在再生中である第１ファイルはキーフレーム情報を格納しなくてもよい。この場合、クライアント１７１０は、図１０及び図１１を参照して前述した実施形態によりキーフレーム情報を生成することができる。しかし、探索時間に対応するキーフレームは、まだキーフレーム情報に含まれていないことがある。
クライアント１７１０は現在の再生時間及び全体再生時間に基づいて、第１ファイルのチャンクのうち現在の再生時間に対応するチャンクを推定する。例えば、クライアント１７１０は現在の再生時間対全体再生時間の比を用いて、第１ファイルのチャンクのうち現在の再生時間に対応するチャンクを推定できる。
クライアント１７１０は、推定されたチャンクのデータを要求する要求パケット、例えば、「ファイル１ＵＲＬ？ｍ」をサーバ１７２０に送信する。ここで、「ｍ」は推定されたチャンクのインデックスである。クライアント１７１０は推定されたチャンクのデータ、例えば、「ファイル１チャンク−ｍ」を含む応答パケットを受信する。クライアント１７１０は、推定されたチャンクのデータを用いて推定成功の有無を判断する。例えば、クライアント１７１０は、推定されたチャンク内の初めてのフレームの時間と現在の再生時間とを比較することによって、推定成功の有無を判断できる。
推定が失敗と判断される場合、クライアント１７１０は新しいチャンクを推定する。推定が成功であると判断される場合、推定されたチャンク内のキーフレームを抽出する。クライアント１７１０は、現在の再生時間に最も近いキーフレームを検出する。クライアント１７１０は、検出されたキーフレーム以後のデータをバッファに入力する。
図１８及び図１９は、複数のｕｒｌストリームを用いるクライアントの動作を説明する図である。図１８を参照すると、一実施形態に係るクライアントは、複数のｕｒｌストリームを用いて解像度変更動作及び／又は探索動作を行う。以下、クライアントが２つのｕｒｌストリームを用いる場合について説明する。
第１ｕｒｌストリーム及び第２ｕｒｌストリームのそれぞれは、要求パケットを生成してサーバに送信し、サーバから受信される応答パケットを処理する。第１ｕｒｌストリームのデータは、第１デマルチプレクサと第１デコーダによって再生される。第２ｕｒｌストリームのデータは、第２デマルチプレクサと第２デコーダによって再生される。
一実施形態によれば、第１デマルチプレクサと第２デマルチプレクサは単一デバイスにより実現される。例えば、第１デマルチプレクサと第２デマルチプレクサは同一のデマルチプレクサデバイスを用いる２つのスレッド形態に実現される。また、第１デコーダと第２デコーダも単一デバイスによって実現される。例えば、第１デコーダと第２デコーダは同一のデコーダデバイスを用いる２つのスレッド形態に実現される。
図面に図示していないが、他の実施形態により動画ファイルがＢ−フレームを含んでいない場合、クライアントは、１つのデマルチプレクサと１つのデコーダを用いて解像度変更動作及び／又は探索動作を行う。Ｂ−フレームは、以後のフレーム情報を参照して圧縮されたフレームである。例えば、Ｂ−フレームは、以前のフレーム情報及び以後のフレーム情報を参照して圧縮されたフレームであり得る。
第１ファイルにＢ−フレームが含まれている場合、第１ファイルのバッファの後に第２ファイルのバッファを続けて付けると、第１ファイルに含まれたＢ−フレームが第１ファイルではない第２ファイルを参照することになってエラーが発生する。一方、第１ファイルにＢ−フレームが含まれない場合、第１ファイルのバッファと第２ファイルのバッファを続けて付けることができるため、デコーダに入力されるバッファ入力ラインを区分する必要がない。そのため、クライアントは１つのデコーダを用いて解像度変更動作及び／又は探索動作を行うことができる。
クライアントは、動画ファイルにＢ−フレームが含まれているか否かを判断した後、動作モードを選択する。
クライアントは、第１デマルチプレクサを制御する信号ＥＮ＿ＤＥＭＵＸ＿１、第１デコーダを制御する信号ＥＮ＿ＤＥＣＯＤＥＲ＿１、第２デマルチプレクサを制御する信号ＥＮ＿ＤＥＭＵＸ＿２、第２デコーダを制御する信号ＥＮ＿ＤＥＣＯＤＥＲ＿２、及び出力モクスを制御する信号ＭＵＸ＿ＯＵＴのうち少なくとも１つを用いて、第１ｕｒｌストリームのデータ及び第２ｕｒｌストリームのデータのデータフロー（ｄａｔａ ｆｌｏｗ）を制御する。
一例として、図１９を参照すると、ストリーミングサービスの開始時にクライアントは第１ｕｒｌストリームを用いて第１ファイルの最初チャンクから順次再生する。ここで、クライアントは、第２ｕｒｌストリームを用いて第１ファイルの再生情報を受信する。
解像度変更の入力時にクライアントは、第１ｕｒｌストリームを用いて第１ファイルを再生しながら、第２ｕｒｌストリームを用いて第２ファイルのキーフレームのうち現在の再生時間に対応するキーフレームを検出する。クライアントは解像度変更のために、検出されたキーフレームが再生する時点に第１ｕｒｌストリームのデータフローと第２ｕｒｌストリームのデータフローを制御する。
例えば、クライアントは、第１ｕｒｌストリームのデータフローをスイッチＯＦＦし、第２ｕｒｌストリームのデータフローをスイッチＯＮする。場合に応じて、クライアントは、デマルチプレクサ及び／又はデコーダのディレイを考慮して第１ｕｒｌストリームのデータフロー及び第２ｕｒｌストリームのデータフローが一定時間、例えば、３０ｍｓの間に共にスイッチＯＮされるように制御し得る。
その後、クライアントは、第２ｕｒｌストリームを用いて検出されたキーフレーム以後データを再生する。クライアントは、第１ｕｒｌストリームのためのバッファをクリアする。図面に図示していないが、もし、追加的な解像度の変更入力が受信されれば、クライアントは前述した動作で第１ｕｒｌストリームと第２ｕｒｌストリームの役割のみを交替することにより、追加的な解像度の変更入力を処理できる。
図面に図示していないが、異なる例として、第１ファイルがＢ−フレームを含まない場合、クライアントは、解像度変更の入力時に第１ｕｒｌストリームを用いて第１ファイルを再生しながら、第２ｕｒｌストリームを用いて第２ファイルのキーフレームのうち現在のバッファ分量に対応するキーフレームを検出する。ここで、現在のバッファ分量は、第１ファイルが現在のバッファに入力された分量であり得る。クライアントは、現在のバッファ分量以後の時間に該当する第２ファイルのキーフレームを検出できる。
クライアントは、第１ファイルの再生中に第２ファイルへの解像度の変更入力が入ると、第１ファイルがデコーダのバッファに入っている分量以後の再生時間に該当する第２ファイルのキーフレームを検出する。クライアントは、検出された第２ファイルのキーフレームの再生時間以前まで第１ファイルのデータをバッファに入力し、第２ファイルのキーフレーム以後に第２ファイルのデータを同一のバッファに入力することにより、第１ファイルのバッファに続けて第２ファイルのバッファを入力できる。
この場合、クライアントが別途の動作しなくても第２ファイルのキーフレームに該当する再生時間で解像度変更及び／又は探索が実行される。例えば、クライアントは、別途のスイッチｏｎ／ｏｆｆ動作しなくてもよい。また、クライアントは、バッファをクリアする動作をしなくてもよい。第１ｕｒｌストリームは、第２ファイルのキーフレーム以前の時間に該当する第１ファイルのバッファを生成し、第２ｕｒｌストリームは第１ファイルのバッファ入力が完了すると、第２ファイルのバッファを第１ファイルのバッファに続いて付けることができる。
上述した実施形態は、ハードウェア構成要素、ソフトウェア構成要素、又はハードウェア構成要素及びソフトウェア構成要素の組合せで具現される。例えば、本実施形態で説明した装置及び構成要素は、例えば、プロセッサ、コントローラ、ＡＬＵ（ａｒｉｔｈｍｅｔｉｃ ｌｏｇｉｃ ｕｎｉｔ）、デジタル信号プロセッサ（ｄｉｇｉｔａｌ ｓｉｇｎａｌ ｐｒｏｃｅｓｓｏｒ）、マイクロコンピュータ、ＦＰＡ（ｆｉｅｌｄ ｐｒｏｇｒａｍｍａｂｌｅ ａｒｒａｙ）、ＰＬＵ（ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ｕｎｉｔ）、マイクロプロセッサー、又は命令（ｉｎｓｔｒｕｃｔｉｏｎ）を実行して応答する異なる装置のように、１つ以上の汎用コンピュータ又は特殊目的コンピュータを用いて具現される。処理装置は、オペレーティングシステム（ＯＳ）及びオペレーティングシステム上で実行される１つ以上のソフトウェアアプリケーションを実行する。また、処理装置は、ソフトウェアの実行に応答してデータをアクセス、格納、操作、処理、及び生成する。理解の便宜のために、処理装置は１つが使用されるものとして説明する場合もあるが、当該技術分野で通常の知識を有する者は、処理装置が複数の処理要素（ｐｒｏｃｅｓｓｉｎｇ ｅｌｅｍｅｎｔ）及び／又は複数類型の処理要素を含むことが分かる。例えば、処理装置は、複数のプロセッサ又は１つのプロセッサ及び１つのコントローラを含む。また、並列プロセッサ（ｐａｒａｌｌｅｌ ｐｒｏｃｅｓｓｏｒ）のような、他の処理構成も可能である。
ソフトウェアは、コンピュータプログラム、コード、命令、又はこれらのうちの１つ以上の組合せを含み、希望通りに動作するように処理装置を構成し、独立的又は結合的に処理装置に命令する。ソフトウェア及び／又はデータは、処理装置によって解釈され、処理装置に命令又はデータを提供するためのあらゆる類型の機械、構成要素、物理的装置、仮想装置、コンピュータ格納媒体又は装置、或いは送信される信号波を介して永久的又は一時的に具現化される。ソフトウェアは、ネットワークに接続されたコンピュータシステム上に分散され、分散された方法で格納されるか又は実行される。ソフトウェア及びデータは１つ以上のコンピュータ読み取り可能な記録媒体に格納される。
本実施形態による方法は、多様なコンピュータ手段を介して実施されるプログラム命令の形態で具現され、コンピュータ読み取り可能な記録媒体に記録される。記録媒体は、プログラム命令、データファイル、データ構造などを単独又は組合せて含む。記録媒体及びプログラム命令は、本発明の目的のために特別に設計して構成されたものでもよく、コンピュータソフトウェア分野の技術を有する当業者にとって公知のものであり使用可能なものであってもよい。コンピュータ読み取り可能な記録媒体の例としては、ハードディスク、フロッピー（登録商標）ディスク及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭ、ＤＶＤのような光記録媒体、フロプティカルディスクのような磁気−光媒体、及びＲＯＭ、ＲＡＭ、フラッシュメモリなどのようなプログラム命令を保存して実行するように特別に構成されたハードウェア装置を含む。プログラム命令の例としては、コンパイラによって生成されるような機械語コードだけでなく、インタプリタなどを用いてコンピュータによって実行される高級言語コードを含む。ハードウェア装置は、本発明の動作を実行するために１つ以上のソフトウェアモジュールとして作動するように構成してもよく、その逆も同様である。
上述したように実施形態をたとえ限定された図面によって説明したが、当技の術分野で通常の知識を有する者であれば、前記に基づいて様々な技術的な修正及び変形を適用することができる。例えば、説明された技術が説明された方法と異なる順序で実行されたり、及び／又は説明されたシステム、構造、装置、回路などの構成要素が説明された方法と異なる形態で結合又は組合わせられたり、他の構成要素又は均等物によって置き換えたり置換されても適切な結果を達成することができる。したがって、他の具現、他の実施形態、及び特許請求の範囲と均等なものも後述する特許請求の範囲に属する。

Claims (36)

  1. ストリーミングサービスのためのクライアントの動作方法において、
    ファイルＵＲＬ及び再生情報要求を指示する第１媒介変数を含む第１要求パケットを送信するステップと、
    前記ファイルＵＲＬに対応するファイルの再生情報を含む第１応答パケットを受信するステップと、
    前記ファイルＵＲＬ及びデータ要求を指示する第２媒介変数を含む第２要求パケットを送信するステップと、
    前記ファイル内の前記第２媒介変数に対応するアドレス範囲のデータを含む第２応答パケットを受信するステップと
    を含むクライアントの動作方法。
  2. 前記再生情報は、前記ファイルを分割するチャンク大きさ、及び前記チャンク個数のうち少なくとも１つを含む請求項１に記載のクライアントの動作方法。
  3. 前記第１媒介変数を予め決定した第１指示子に設定するステップと、
    前記第１応答パケットから前記ファイルを分割するチャンク大きさ、前記チャンク個数、前記ファイルに格納されたコンテンツの解像度、前記解像度と異なる第２解像度のコンテンツを格納する第２ファイルＵＲＬ、及び前記第２解像度を抽出するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  4. 前記第２媒介変数を最初インデックスに設定するステップと、
    前記第２応答パケットのデータをバッファに入力するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  5. バッファの残量をチェックするステップと、
    前記バッファの残量が閾値以下になれば、前記第２媒介変数を次の再生するチャンクのインデックスに設定するステップと、
    前記第２応答パケットのデータを前記バッファに入力するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  6. 前記第２媒介変数を最初インデックスに設定するステップと、
    前記第２応答パケットから前記ファイルのキーフレーム情報のためのオフセットアドレスを抽出するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  7. 前記オフセットアドレスのデータが前記第２応答パケットに含まれた場合、前記第２応答パケットから前記キーフレーム情報を抽出するステップをさらに含む請求項６に記載のクライアントの動作方法。
  8. 前記オフセットアドレスのデータが前記第２応答パケットに含まれない場合、データ要求を指示する第３媒介変数を前記オフセットアドレスに設定するステップと、
    前記ファイルＵＲＬ及び前記第３媒介変数を含む第３要求パケットを送信するステップと、
    前記ファイル内の前記第３媒介変数に対応するアドレス範囲のデータを含む第３応答パケットを受信するステップと、
    前記第３応答パケットから前記キーフレーム情報を抽出するステップと
    をさらに含む請求項６に記載のクライアントの動作方法。
  9. 前記第２応答パケットのデータをバッファに入力するステップと、
    前記データが再生される間に前記ファイルのキーフレームを抽出するステップと、
    前記キーフレームに基づいて前記ファイルのキーフレーム情報を生成するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  10. 解像度の変更入力を受信するステップと、
    前記ファイルＵＲＬを前記解像度の変更入力に含まれた新しい解像度に対応する第２ファイルＵＲＬに設定するステップと、
    前記第１媒介変数を予め決定した第２指示子に設定するステップと、
    前記第１応答パケットから前記第２ファイルを分割するチャンク大きさ、及び前記チャンク個数を抽出するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  11. 解像度の変更入力を受信するステップと、
    前記ファイルＵＲＬを前記解像度の変更入力に含まれた新しい解像度に対応する第２ファイルＵＲＬに設定するステップと、
    前記第２ファイルのキーフレーム情報に基づいて現在の再生時間に対応するキーフレームを検出するステップと、
    前記第２媒介変数を前記検出されたキーフレームのアドレスに設定するステップと、
    前記第２応答パケットのデータをバッファに入力するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  12. 前記第２媒介変数は、前記検出されたキーフレームのアドレス及び前記検出されたキーフレームが属するチャンクの終了アドレスを含む請求項１１に記載のクライアントの動作方法。
  13. 前記バッファは現在の利用中であるバッファと区別される第２バッファであり、
    前記検出されたキーフレームの時間後に前記第２バッファのデータが再生される請求項１１に記載のクライアントの動作方法。
  14. 解像度の変更入力を受信するステップと、
    前記ファイルＵＲＬを前記解像度の変更入力に含まれた新しい解像度に対応する第２ファイルＵＲＬに設定するステップと、
    現在の再生時間及び全体再生時間に基づいて前記現在の再生時間に対応するチャンクを推定するステップと、
    前記第２媒介変数を前記推定されたチャンクのインデックスに設定するステップと、
    前記第２応答パケットの時間範囲が前記現在の再生時間を含む場合、前記第２応答パケットのデータから前記現在の再生時間に最も近いキーフレームを検出するステップと、
    前記検出されたキーフレーム以後のデータを前記バッファに入力するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  15. 前記第２応答パケットの時間範囲が前記現在の再生時間を含まない場合、前記現在の再生時間に対応する新しいインデックスを推定するステップと、
    データ要求を指示する第３媒介変数を前記新しいインデックスに設定するステップと、
    前記ファイルＵＲＬ及び前記第３媒介変数を含む第３要求パケットを送信するステップと、
    前記ファイル内の前記第３媒介変数に対応するアドレス範囲のデータを含む第３応答パケットを受信するステップと、
    前記第３応答パケットのデータから前記現在の再生時間に最も近いキーフレームを検出するステップと
    をさらに含む請求項１４に記載のクライアントの動作方法。
  16. 前記バッファは現在の利用中であるバッファと区別される第２バッファであり、
    前記検出されたキーフレームの時間後に前記第２バッファのデータが再生される請求項１４に記載のクライアントの動作方法。
  17. 探索時間を受信するステップと、
    前記ファイルのキーフレーム情報を用いて前記探索時間に対応するキーフレームを検出するステップと、
    前記第２媒介変数を前記検出されたキーフレームのアドレスに設定するステップと、
    前記第２応答パケットのデータをバッファに入力するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  18. 前記第２媒介変数は、前記検出されたキーフレームのアドレス及び前記検出されたキーフレームが属するチャンクの終了アドレスを含む請求項１７に記載のクライアントの動作方法。
  19. 前記バッファは現在の利用中であるバッファと区別される第２バッファであり
    前記検出されたキーフレームの時間後に前記第２バッファのデータが再生される請求項１７に記載のクライアントの動作方法。
  20. 探索時間を受信するステップと、
    前記探索時間と前記ファイルの全体再生時間に基づいて前記探索時間に対応するチャンクを推定するステップと、
    前記第２媒介変数を前記推定されたチャンクのインデックスに設定するステップと、
    前記第２応答パケットの時間範囲が前記探索時間を含む場合、前記第２応答パケットのデータから前記探索時間に最も近いキーフレームを検出するステップと、
    前記検出されたキーフレーム以後のデータをバッファに入力するステップと
    をさらに含む請求項１に記載のクライアントの動作方法。
  21. 前記第２応答パケットの時間範囲が前記探索時間を含まない場合、前記探索時間に対応する新しいインデックスを推定するステップと、
    データ要求を指示する第３媒介変数を前記新しいインデックスに設定するステップと、
    前記ファイルＵＲＬ及び前記第３媒介変数を含む第３要求パケットを送信するステップと、
    前記ファイル内の前記第３媒介変数に対応するアドレス範囲のデータを含む第３応答パケットを受信するステップと、
    前記第３応答パケットのデータから前記探索時間に最も近いキーフレームを検出するステップと
    をさらに含む請求項２０に記載のクライアントの動作方法。
  22. 前記バッファは現在の利用中であるバッファと区別される第２バッファであり、
    前記検出されたキーフレームの時間後に前記第２バッファのデータが再生される請求項２０に記載のクライアントの動作方法。
  23. 前記クライアントはサーバとの通信のためにｈｔｔｐプロトコルを用いる請求項１に記載のクライアントの動作方法。
  24. 前記第１媒介変数は前記ファイルを分割するチャンク大きさを含み、
    前記再生情報は、前記チャンク個数及び前記ファイルの大きさのうち少なくとも１つを含む請求項１に記載のクライアントの動作方法。
  25. ストリーミングサービスのためのサーバの動作方法において、
    ファイルＵＲＬ及び媒介変数を含む要求パケットを受信するステップと、
    前記媒介変数がデータ要求を指示する場合、前記ファイルＵＲＬに対応するファイル内の前記媒介変数に対応するアドレス範囲のデータを応答するステップと、
    前記媒介変数が再生情報要求を指示する場合、前記ファイルの再生情報を応答するステップと
    を含むサーバの動作方法。
  26. 前記再生情報は、前記ファイルを分割するチャンク大きさ、及び前記チャンク個数のうち少なくとも１つを含む請求項２５に記載のサーバの動作方法。
  27. 前記データを応答するステップは、前記媒介変数がインデックス又はアドレスを含むか否かを判断するステップを含む請求項２５に記載のサーバの動作方法。
  28. 前記データを応答するステップは、
    前記媒介変数がインデックスを含む場合、前記ファイル内の前記インデックスに対応するアドレス範囲のデータを応答するステップと、
    前記媒介変数がアドレスを含む場合、前記ファイル内の前記アドレスに対応するアドレス範囲のデータを応答するステップと
    のうち少なくとも１つを含む請求項２５に記載のサーバの動作方法。
  29. 前記インデックスに対応するアドレス範囲は前記ファイルを分割するチャンク大きさに基づいて決定される請求項２５に記載のサーバの動作方法。
  30. 前記アドレスに対応するアドレス範囲のデータを応答するステップは、
    前記媒介変数が２つのアドレスを含む場合、前記ファイル内の前記２つのアドレスの間のデータを応答するステップと、
    前記媒介変数が１つのアドレスを含む場合、前記ファイル内の前記１つのアドレスと前記ファイルの終了の間のデータを応答するステップと
    のうち少なくとも１つを含む請求項２５に記載のサーバの動作方法。
  31. 前記再生情報を応答するステップは、
    前記媒介変数が予め決定した第１指示子を含む場合、前記ファイルを分割するチャンク大きさ、前記チャンク個数、前記ファイルに格納されたコンテンツの解像度、前記解像度と異なる第２解像度のコンテンツを格納する第２ファイルＵＲＬ、及び前記第２解像度を応答するステップと、
    前記媒介変数が予め決定した第２指示子を含む場合、前記チャンク大きさ及び前記チャンク個数を応答するステップと
    のうち少なくとも１つを含む請求項２５に記載のサーバの動作方法。
  32. 前記第２ファイルは、前記ファイルのファイル名及び前記ファイルが格納されたディレクトリのうち少なくとも１つに基づいて検索される請求項３１に記載のサーバの動作方法。
  33. 前記第２解像度は、前記第２ファイルのファイル名に基づいて取得される請求項３１に記載のサーバの動作方法。
  34. 前記サーバは、クライアントとの通信のためにｈｔｔｐプロトコルを用いる請求項２５に記載のサーバの動作方法。
  35. 前記ファイルを分割するチャンク大きさを受信するステップをさらに含み、
    前記再生情報は、前記チャンク個数、及び前記ファイルの大きさのうち少なくとも１つを含む請求項２５に記載のサーバの動作方法。
  36. ハードウェアと結合して請求項１乃至３５のいずれか一項に記載の方法を実行させるために媒体に格納されたコンピュータプログラム。
JP2017502886A 2014-07-16 2015-04-01 ストリーミングサービスのためのクライアント及びサーバの動作方法 Ceased JP2017529726A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR1020140089679A KR101600469B1 (ko) 2014-07-16 2014-07-16 스트리밍 서비스를 위한 클라이언트 및 서버의 동작 방법
KR10-2014-0089679 2014-07-16
PCT/KR2015/003230 WO2016010229A1 (ko) 2014-07-16 2015-04-01 스트리밍 서비스를 위한 클라이언트 및 서버의 동작 방법

Publications (1)

Publication Number Publication Date
JP2017529726A true JP2017529726A (ja) 2017-10-05

Family

ID=55078691

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2017502886A Ceased JP2017529726A (ja) 2014-07-16 2015-04-01 ストリーミングサービスのためのクライアント及びサーバの動作方法

Country Status (6)

Country Link
US (1) US20170134463A1 (ja)
EP (1) EP3171604A4 (ja)
JP (1) JP2017529726A (ja)
KR (1) KR101600469B1 (ja)
CN (1) CN106537924A (ja)
WO (1) WO2016010229A1 (ja)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8942543B1 (en) 2010-10-06 2015-01-27 Verint Video Solutions Inc. Systems, methods, and software for improved video data recovery effectiveness
US10033794B2 (en) * 2015-07-17 2018-07-24 Bio-Rad Laboratories, Inc. Network transfer of large files in unstable network environments
CN105828149A (zh) * 2016-04-28 2016-08-03 合智能科技（深圳）有限公司 播放优化方法和装置
KR101863598B1 (ko) * 2016-07-29 2018-06-01 주식회사 에어브로드 스트리밍 서비스를 위한 클라이언트의 동작 방법
US10873775B2 (en) * 2017-06-12 2020-12-22 Netflix, Inc. Staggered key frame video encoding
US11354164B1 (en) * 2018-04-20 2022-06-07 Automation Anywhere, Inc. Robotic process automation system with quality of service based automation
US10908950B1 (en) 2018-04-20 2021-02-02 Automation Anywhere, Inc. Robotic process automation system with queue orchestration and task prioritization
KR102500145B1 (ko) * 2018-07-13 2023-02-16 삼성전자주식회사 전자 장치 및 전자 장치의 컨텐트 전송 방법
CN110545492B (zh) * 2018-09-05 2020-07-31 北京开广信息技术有限公司 媒体流的实时递送方法及服务器
CN110881018B (zh) * 2018-09-05 2020-11-03 北京开广信息技术有限公司 媒体流的实时接收方法及客户端
CN110072128B (zh) * 2019-04-22 2021-01-15 北京开广信息技术有限公司 媒体流的实时推送方法及服务器
CN110113655B (zh) * 2019-05-05 2021-09-21 北京奇艺世纪科技有限公司 一种视频播放的方法、装置及用户终端
CN111314434B (zh) * 2020-01-20 2022-08-19 浪潮云信息技术股份公司 请求处理方法及服务端
KR102655215B1 (ko) * 2022-09-27 2024-04-05 (주)이노시뮬레이션 원격 유지보수를 위한 선박 및 지상 담당자 사이의 네트워크 연결 방법 및 이를 실행하는 시스템

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001242876A (ja) * 1999-12-20 2001-09-07 Matsushita Electric Ind Co Ltd データ受信再生方法、データ受信再生装置、データ送信方法、およびデータ送信装置
JP2005260283A (ja) * 2004-02-13 2005-09-22 Matsushita Electric Ind Co Ltd Ａｖコンテンツのネットワーク再生方法
EP2547062A1 (en) * 2011-07-14 2013-01-16 Nxp B.V. Media streaming with adaptation
US20130091297A1 (en) * 2011-10-05 2013-04-11 Qualcomm Incorporated Switching between representations during network streaming of coded multimedia data
JP2013518507A (ja) * 2010-03-05 2013-05-20 サムスン エレクトロニクス カンパニー リミテッド ファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置とその記録媒体
JP2013520865A (ja) * 2010-02-19 2013-06-06 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｈｔｔｐストリーミングにおける適応のための方法と装置
JP2013535866A (ja) * 2010-06-29 2013-09-12 クゥアルコム・インコーポレイテッド トリックモードビデオ表現のためのビデオサンプルを信号伝達すること
JP2013535886A (ja) * 2010-07-15 2013-09-12 クゥアルコム・インコーポレイテッド ビデオ構成要素を多重化するためのデータを信号伝達すること

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2002215516A (ja) * 2001-01-22 2002-08-02 Sony Corp 情報端末装置、ダウンロード制御方法およびコンピュータプログラム
KR101066872B1 (ko) * 2008-10-30 2011-09-26 에스케이텔레콤 주식회사 캐시서버를 이용한 컨텐츠 전송시스템 및 방법, 그 캐시서버
KR20100055296A (ko) * 2008-11-17 2010-05-26 에스케이텔레콤 주식회사 분산 저장된 컨텐츠의 리다이렉티드 ｕｒｌ을 이용한 순차적 멀티미디어 스트리밍 시스템 및 방법
CN102055773B (zh) * 2009-11-09 2013-10-09 华为技术有限公司 实现基于http的流媒体业务的方法、系统和网络设备
KR101361021B1 (ko) * 2009-11-09 2014-02-10 후아웨이 테크놀러지 컴퍼니 리미티드 Ｈｔｔｐ 기반의 스트리밍 미디어 서비스를 구현하는 방법, 시스템 및 네트워크장비
US9485546B2 (en) * 2010-06-29 2016-11-01 Qualcomm Incorporated Signaling video samples for trick mode video representations
US9462024B2 (en) * 2011-06-08 2016-10-04 Futurewei Technologies, Inc. System and method of media content streaming with a multiplexed representation

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001242876A (ja) * 1999-12-20 2001-09-07 Matsushita Electric Ind Co Ltd データ受信再生方法、データ受信再生装置、データ送信方法、およびデータ送信装置
JP2005260283A (ja) * 2004-02-13 2005-09-22 Matsushita Electric Ind Co Ltd Ａｖコンテンツのネットワーク再生方法
JP2013520865A (ja) * 2010-02-19 2013-06-06 テレフオンアクチーボラゲット エル エム エリクソン（パブル） Ｈｔｔｐストリーミングにおける適応のための方法と装置
JP2013518507A (ja) * 2010-03-05 2013-05-20 サムスン エレクトロニクス カンパニー リミテッド ファイルフォーマットベースの適応的ストリーム生成、再生方法及び装置とその記録媒体
JP2013535866A (ja) * 2010-06-29 2013-09-12 クゥアルコム・インコーポレイテッド トリックモードビデオ表現のためのビデオサンプルを信号伝達すること
JP2013535886A (ja) * 2010-07-15 2013-09-12 クゥアルコム・インコーポレイテッド ビデオ構成要素を多重化するためのデータを信号伝達すること
EP2547062A1 (en) * 2011-07-14 2013-01-16 Nxp B.V. Media streaming with adaptation
US20130091297A1 (en) * 2011-10-05 2013-04-11 Qualcomm Incorporated Switching between representations during network streaming of coded multimedia data

Also Published As

Publication number Publication date
KR20160009322A (ko) 2016-01-26
KR101600469B1 (ko) 2016-03-07
EP3171604A1 (en) 2017-05-24
CN106537924A (zh) 2017-03-22
US20170134463A1 (en) 2017-05-11
EP3171604A4 (en) 2018-04-11
WO2016010229A1 (ko) 2016-01-21

Similar Documents

Publication Publication Date Title
JP2017529726A (ja) ストリーミングサービスのためのクライアント及びサーバの動作方法
CN106464945B (zh) 增强型流媒体回放的方法、系统及计算机可读介质
US9529888B2 (en) System and method for efficiently providing media and associated metadata
US8732274B2 (en) Method and apparatus for generating and handling streaming media quality-of-experience metrics
US10397289B2 (en) HTTP live streaming (HLS) video client synchronization
CA3037307C (en) Methods and systems for instantaneous asynchronous media sharing
US9356985B2 (en) Streaming video to cellular phones
US10404828B2 (en) Streaming apparatus, streaming method, and streaming service system using the streaming apparatus
WO2015192683A1 (zh) 一种基于码流自适应技术的内容分发方法、装置及系统
US10673907B2 (en) Systems and methods for providing DLNA streaming to client devices
EP3175599A1 (en) Systems and methods for selective transport accelerator operation
KR101863598B1 (ko) 스트리밍 서비스를 위한 클라이언트의 동작 방법
US9607002B2 (en) File retrieval from multiple storage locations
KR20170018333A (ko) 클라이언트 단말기와 적어도 하나의 서버 간의 송신 경로를 따라 배열된 네트워크 장비를 동작하기 위한 방법, 및 대응하는 네트워크 장비
KR102237900B1 (ko) 클라이언트 단말에 의해 멀티미디어 콘텐츠의 콘텐츠 부분을 검색하기 위한 방법
CN111837405B (zh) 用于传递无清单流媒体内容的方法、系统和介质
KR20160031467A (ko) 스트리밍 서비스를 위한 클라이언트 및 서버의 동작 방법
TWI598743B (zh) 多媒體檔案下載方法與電子裝置

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20170117

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20180221

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20181017

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20181030

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20190125

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

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20190416

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

Free format text: JAPANESE INTERMEDIATE CODE: A045

Effective date: 20190827