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