知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-05
(45)【発行日】2024-08-14
(54)【発明の名称】オンラインオーディオ／ビデオ再生方法および電子デバイス
(51)【国際特許分類】
H04N 21/438 20110101AFI20240806BHJP
H04N 21/44 20110101ALI20240806BHJP
【ＦＩ】
H04N21/438
H04N21/44
【請求項の数】
12
(21)【出願番号】P 2023524568
(86)(22)【出願日】2021-09-02
(65)【公表番号】
(43)【公表日】2023-11-08
(86)【国際出願番号】 CN2021116181
(87)【国際公開番号】W WO2022083308
(87)【国際公開日】2022-04-28
【審査請求日】2023-05-30
(31)【優先権主張番号】202011138720.6
(32)【優先日】2020-10-22
(33)【優先権主張国・地域又は機関】CN
(73)【特許権者】
【識別番号】503433420
【氏名又は名称】華為技術有限公司
【氏名又は名称原語表記】ＨＵＡＷＥＩ ＴＥＣＨＮＯＬＯＧＩＥＳ ＣＯ．，ＬＴＤ．
【住所又は居所原語表記】Ｈｕａｗｅｉ Ａｄｍｉｎｉｓｔｒａｔｉｏｎ Ｂｕｉｌｄｉｎｇ， Ｂａｎｔｉａｎ， Ｌｏｎｇｇａｎｇ Ｄｉｓｔｒｉｃｔ， Ｓｈｅｎｚｈｅｎ， Ｇｕａｎｇｄｏｎｇ ５１８１２９， Ｐ．Ｒ． Ｃｈｉｎａ
(74)【代理人】
【識別番号】100107766
【弁理士】
【氏名又は名称】伊東 忠重
(74)【代理人】
【識別番号】100070150
【弁理士】
【氏名又は名称】伊東 忠彦
(74)【代理人】
【識別番号】100135079
【弁理士】
【氏名又は名称】宮崎 修
(72)【発明者】
【氏名】ジョウ，エルフ
【審査官】鈴木 隆夫
(56)【参考文献】
【文献】中国特許出願公開第１１０４１８１８６（ＣＮ，Ａ）
【文献】中国特許出願公開第１１０２４８２３３（ＣＮ，Ａ）
【文献】中国特許出願公開第１０５２８０２０５（ＣＮ，Ａ）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｎ ２１／００－２１／８５８
(57)【特許請求の範囲】
【請求項1】
オンラインでのオーディオ/ビデオ再生方法であって、ネットワークデバイスに第一の要求を送信するステップと、
前記第一の要求に基づいて前記ネットワークデバイスによってフィードバックされるオーディオ/ビデオストリームの第一のセグメントを受信し、第一のバッファユニットに前記オーディオ/ビデオストリームの第一のセグメントを格納するステップであって、前記オーディオ/ビデオストリームの第一のセグメントは事前に設定された数のデータパケットを含み、前記オーディオ/ビデオストリームの第一のセグメントの前記データパケットは、オーディオパケットおよび/またはビデオパケットを含む、ステップと、
前記オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたオーディオ/ビデオストリームである場合に、前記第一のバッファユニットからM個のデータパケットを読み取り、第二のバッファユニットに前記M個のデータパケットを格納するステップであって、Mは1より大きい正の整数であり、前記非一様にインターリーブされたオーディオ/ビデオストリームとは、前記オーディオ/ビデオストリームの第一のセグメントに含まれ、プレゼンテーションタイムスタンプPTSが同じであり、格納場所が指定された距離のしきい値を超えるオーディオパケットおよびビデオパケットの数が指定された数のしきい値を超えるということを意味し、
前記第一のバッファユニットの前記オーディオ/ビデオストリームの第一のセグメントをクリアし、前記ネットワークデバイスに第二の要求を送信するステップと、
前記第二の要求に基づいて、前記ネットワークデバイスによってフィードバックされるオーディオ/ビデオストリームの第二のセグメントを受信し、前記第一のバッファユニットに前記オーディオ/ビデオストリームの第二のセグメントを格納するステップであって、前記オーディオ/ビデオストリームの第二のセグメントは、事前に設定された数のデータパケットを含み、前記オーディオ/ビデオストリームの第二のセグメントの前記データパケットは、オーディオパケットおよび/またはビデオパケットを含む、ステップと、
前記第一のバッファユニットからY個のデータパケットを読み取り、第三のバッファユニットに前記Y個のデータパケットを格納するステップであって、Yは1より大きい正の整数である、ステップと、
前記第二のバッファユニットのデータパケットと前記第三のバッファユニットのデータパケットを照合し、PTSが同じであるオーディオパケットとビデオパケットのペアが見つかった後に、前記PTSが同じであるオーディオパケットとビデオパケットのペアを再生するように再生機を制御するステップと、を含む、方法。
【請求項2】
前記オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたオーディオ/ビデオストリームであると決定するステップは、前記オーディオ/ビデオストリームの第一のセグメントの各オーディオパケットについて、前記オーディオ/ビデオストリームの第一のセグメントに、前記オーディオパケットと同じPTSを持つビデオパケットがあるかどうかを検出し、前記オーディオ/ビデオストリームの第一のセグメントに、オーディオパケットと同じPTSを持つビデオパケットがある場合、前記オーディオパケットをインターリーブされたオーディオパケットa1として記録し、あるいは前記オーディオ/ビデオストリームの第一のセグメントに、前記オーディオパケットと同じPTSを持つビデオパケットがない場合、前記オーディオパケットをインターリーブされていないオーディオパケットa2として記録し、および前記オーディオ/ビデオストリームの第一のセグメントの各ビデオパケットについて、前記オーディオ/ビデオストリームの第一のセグメントに、前記ビデオパケットと同じPTSを持つオーディオパケットがあるかどうかを検出し、前記オーディオ/ビデオストリームの第一のセグメントに、前記ビデオパケットと同じPTSを持つオーディオパケットがある場合、ビデオパケットをインターリーブされたビデオパケットv1として記録し、あるいは前記オーディオ/ビデオストリームの第一のセグメントに、前記ビデオパケットと同じPTSを持つオーディオパケットがない場合、前記ビデオパケットをインターリーブされていないビデオパケットv2として記録するステップと、
前記オーディオ/ビデオストリームの第一のセグメントにおけるa1、v1、a2、およびv2の合計数に対するa1とv1の合計数の比率が事前に設定された値n未満である場合、前記オーディオ/ビデオストリームの第一のセグメントは非一様にインターリーブされたオーディオ/ビデオストリームであると決定するステップと、を含む、請求項１に記載の方法。
【請求項3】
前記再生機が履歴のオーディオ/ビデオストリームを再生する再生ステータスに基づいてnの値を決定するステップであって、前記履歴のオーディオ/ビデオストリーム内のa1、v1、a2、およびv2の合計数に対するa1とv1の合計数の比率がn未満の場合、前記再生機の前記再生ステータスはフレームフリーズである、ステップをさらに含む、請求項２に記載の方法。
【請求項4】
前記ネットワークデバイスに第二の要求を送信する前記ステップは、前記オーディオ/ビデオストリームの第一のセグメントに第一のオーディオパケットが含まれている場合、オーディオ/ビデオストリームの第一のセグメントに前記第一のオーディオパケットと同じPTSを持つビデオパケットが含まれていないと決定するステップと、
前記ネットワークデバイスに前記第二の要求を送信するステップであって、前記第二の要求は、前記第一のオーディオパケットと同じPTSを持つビデオパケットを要求するために使用されるステップと、を含む、請求項１～３のいずれか一項に記載の方法。
【請求項5】
前記M個のデータパケットはすべてオーディオパケットであり、前記Y個のデータパケットはすべてビデオパケットであるか、あるいは前記M個のデータパケットはすべてビデオパケットであり、前記Y個のデータパケットはすべてオーディオパケットであるか、あるいは
前記M個のデータパケットは、前記オーディオ/ビデオストリームの第一のセグメントの最初のM個のデータパケットであり、前記Y個のデータパケットは、前記オーディオ/ビデオストリームの第二のセグメントの最初のY個のデータパケットである、請求項１～４のいずれか一項に記載の方法。
【請求項6】
前記第一のバッファユニットからM個のデータパケットを読み取る前記ステップの前に、前記第一のバッファユニットのデータパケットに対して照合を実行し、同じPTSを持つオーディオパケットとビデオパケットのペアが見つかった後に、前記再生機が前記同じPTSを持つオーディオパケットとビデオパケットのペアを再生するように制御するステップをさらに含み、
前記第一のバッファユニットからM個のデータパケットを読み取る前記ステップは、
前記第一のバッファユニットにあり、前記オーディオパケットと同じPTSを持つマッチしたビデオパケットを持たないオーディオパケットを、前記第二のバッファユニットに格納し、または、前記第一のバッファユニットにあり、前記ビデオパケットと同じPTSを持つマッチしたオーディオパケットを持たないビデオパケットを、前記第二のバッファユニットに格納するステップを含む、請求項１～５のいずれか一項に記載の方法。
【請求項7】
M=Yである、請求項１～６のいずれか一項に記載の方法。
【請求項8】
前記オーディオ/ビデオストリームの第一のセグメントが一様にインターリーブされたオーディオ/ビデオストリームである場合に、ストリームシーケンスに基づいて前記第一のバッファユニットの前記データパケットを順番に読み取り、同じPTSを持つオーディオパケットとビデオパケットのペアが読み取られた後、前記同じPTSを持つオーディオパケットとビデオパケットのペアを再生するように前記再生機を制御するステップをさらに含む、請求項１～７のいずれか一項に記載の方法。
【請求項9】
電子デバイスであって、前記電子デバイスは、プロセッサとメモリを含み、
前記メモリは、プログラム命令を格納し、
前記プログラム命令が実行されると、前記電子デバイスは、請求項１～８のいずれか一項に記載の方法を実行することが可能になる、電子デバイス。
【請求項10】
コンピュータ可読記憶媒体であって、前記コンピュータ可読記憶媒体は、プログラム命令を含み、
前記プログラム命令が電子デバイス上で実行されると、前記電子デバイスは、請求項１～８のいずれか一項に記載の方法を実行することが可能になる、コンピュータ可読記憶媒体。
【請求項11】
チップであって、
前記チップは、デバイス内のメモリと結合しているので、前記チップは、動作時に、前記メモリに格納されたプログラム命令を呼び出して、請求項１～８のいずれか一項に記載の方法を実施する、チップ。
【請求項12】
コンピュータプログラムであって、前記コンピュータプログラムが電子デバイス上で実行されると、前記電子デバイスは、請求項１～８のいずれか一項に記載の方法を実行することが可能になる、コンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願への相互参照
本出願は、2020年10月22日に中国国家知識産権局に出願された 「ONLINE AUDIO/VIDEO PLAY METHOD AND ELECTRONIC DEVICE」 と題された中国特許出願第202011138720.6号の優先権を主張しており、その全体が参照により本明細書に組み込まれる。
本出願は、2020年10月22日に中国国家知識産権局に出願された 「ONLINE AUDIO/VIDEO PLAY METHOD AND ELECTRONIC DEVICE」 と題された中国特許出願第202011138720.6号の優先権を主張しており、その全体が参照により本明細書に組み込まれる。
【0002】
本出願は、インターネット技術の分野、特にオンラインオーディオ/ビデオ再生方法と電子デバイスに関する。
【背景技術】
【0003】
オンライン再生 (play online) は、オンラインオーディオ/ビデオ再生方法であり、ユーザが、ローカルデバイスにオーディオおよびビデオファイルをダウンロードすることなく、ファイルをオンラインで直接再生できる方法である。オンライン再生技術を使用することにより、ユーザはいつでもクライアントを介してサーバにネットワーク接続を確立することができ、サーバからオーディオおよびビデオファイルを要求して、サーバから提供されたオーディオおよびビデオを再生する。しかしながら、クライアントによって要求されたオーディオおよびビデオファイルが非一様にインターリーブされたオーディオ/ビデオストリームである場合、クライアントでの再生中にかなりのフレームフリーズが発生する。その結果、ユーザエクスペリエンスが影響を受ける。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本出願の実施形態は、オンラインオーディオ/ビデオ再生方法と電子デバイスを提供し、オーディオ/ビデオストリームの同期効率を向上させ、オンラインオーディオ/ビデオ再生中のフレームフリーズを削減する。
【課題を解決するための手段】
【0005】
第1の態様によると、オンラインオーディオ/ビデオ再生方法が提供される。この方法は、以下を含む：電子デバイスはネットワークデバイスに第一の要求を送信する。電子デバイスは、第一の要求に基づいてネットワークデバイスによってフィードバックされるオーディオ/ビデオストリームの第一のセグメントを受信し、第一のバッファユニットにオーディオ/ビデオストリームの第一のセグメントを格納する。ここで、オーディオ/ビデオストリームの第一のセグメントは事前に設定された数のデータパケットを含み、オーディオ/ビデオストリームの第一のセグメントのデータパケットはオーディオパケットおよび/またはビデオパケットを含む。オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたオーディオ/ビデオストリームである場合、電子デバイスは第一のバッファユニットからM個のデータパケットを読み取り、M個のデータパケットを第二のバッファユニットに格納する。ここで、Mは1より大きい正の整数であり、非一様にインターリーブされたオーディオ/ビデオストリームとは、オーディオ/ビデオストリームの第一のセグメントに含まれ、プレゼンテーションタイムスタンプPTSが同じであり、格納位置が指定された距離のしきい値を超えるオーディオパケットおよびビデオパケットの数が指定された数のしきい値を超えるということを意味する。電子デバイスは、第一のバッファユニットのデータパケットをクリアし、ネットワークデバイスに第二の要求を送信する。電子デバイスは、第二の要求に基づいて、ネットワークデバイスによってフィードバックされるオーディオ/ビデオストリームの第二のセグメントを受信し、第一のバッファユニットにオーディオ/ビデオストリームの第二のセグメントを格納する。ここで、オーディオ/ビデオストリームの第二のセグメントは、事前に設定された数のデータパケットを含み、オーディオ/ビデオストリームの第二のセグメントのデータパケットは、オーディオパケットおよび/またはビデオパケットを含む。電子デバイスは、第一のバッファユニットからY個のデータパケットを読み取り、第三のバッファユニットにY個のデータパケットを格納する。ここで、Yは1より大きい正の整数である。電子デバイスは、第二のバッファユニットのデータパケットと第三のバッファユニットのデータパケットを照合し、PTSが同じであるオーディオパケットとビデオパケットのペアを見つけた後に、PTSが同じであるオーディオパケットとビデオパケットのペアを再生するようにプレーヤを制御する。
【0006】
本出願のこの実施形態では、電子デバイスは、2回ダウンロードされたデータパケットを格納するために2つのバッファ(つまり、第二のバッファユニットと第三のバッファユニット)を割り当て、2つのバッファ内のデータパケットに対してオーディオとビデオの同期をバッチで実行する。ストリーム内のデータパケットを複数回繰り返しダウンロードすることによってオーディオとビデオの同期を実行する従来の解決策と比較して、本出願の実施形態では、(プレーヤなどの)クライアントのオーディオとビデオの同期効率を向上させることができる。ローカルバッファを使用する技術的な解決策と比較して、本出願のこの実施形態ではバッファ時間を短縮することができる。したがって、本出願のこの実施形態は、任意のサイズのオーディオとビデオのオンライン再生に適用でき、すべてのオーディオとビデオのオンライン再生中のフレームフリーズを減らすことができる。
【0007】
可能な設計では、電子デバイスは、オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたオーディオ/ビデオストリームであるかどうかを検出するために、以下の方法を使用できる：電子デバイスは、オーディオ/ビデオストリームの第一のセグメントの各オーディオパケットについて、オーディオ/ビデオストリームの第一のセグメントに、オーディオパケットと同じPTSを持つビデオパケットがあるかどうかを検出する。オーディオ/ビデオストリームの第一のセグメントに、オーディオパケットと同じPTSを持つビデオパケットがある場合、電子デバイスは、オーディオパケットをインターリーブされたオーディオパケットa1として記録する。オーディオ/ビデオストリームの第一のセグメントに、オーディオパケットと同じPTSを持つビデオパケットがない場合、電子デバイスは、オーディオパケットを非インターリーブされたオーディオパケットa2として記録する。電子デバイスは、オーディオ/ビデオストリームの第一のセグメントの各ビデオパケットについて、オーディオ/ビデオストリームの第一のセグメントに、ビデオパケットと同じPTSを持つオーディオパケットがあるかどうかを検出する。オーディオ/ビデオストリームの第一のセグメントに、ビデオパケットと同じPTSを持つオーディオパケットがある場合、電子デバイスは、ビデオパケットをインターリーブされたビデオパケットv1として記録する。オーディオ/ビデオストリームの第一のセグメントに、ビデオパケットと同じPTSを持つオーディオパケットがない場合、電子デバイスは、ビデオパケットを非インターリーブされたビデオパケットv2として記録する。オーディオ/ビデオストリームの第一のセグメントにおけるa1、v1、a2、およびv2の合計数に対するa1とv1の合計数の比が事前に設定された値n未満である場合、電子デバイスは、オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたオーディオ/ビデオストリームであると決定する。この設計方法により、電子デバイスは、非一様にインターリーブされたストリームをより正確に検出できる。
【0008】
可能な設計では、電子デバイスは、プレーヤが履歴のオーディオ/ビデオストリームを再生する再生ステータスに基づいてnの値を決定してもよい。履歴のオーディオ/ビデオストリーム内のa1、v1、a2、およびv2の合計数に対するa1とv1の合計数の比がn未満の場合、プレーヤの再生ステータスはフレームフリーズであってもよい。nの値は、プレーヤごとに異なっていてもよく、あるいは同じプレーヤで再生されるオーディオ/ビデオストリームごとに異なっていてもよいことを理解すべきである。
【0009】
この設計方法では、電子デバイスは、異なるインターリーブ度を持つストリームの実際の再生効果に基づいて規制係数nの値を決定して、一定の決定条件が異なるインターリーブ度を持つオーディオ/ビデオストリームに対して異なる再生効果を引き起こすことを防ぐことができる。
【0010】
可能な設計では、オーディオ/ビデオストリームの第一のセグメントに第一のオーディオパケットが含まれている場合、電子デバイスは、オーディオ/ビデオストリームの第一のセグメントに第一のオーディオパケットと同じPTSを持つビデオパケットが含まれていないと決定し、第二の要求をネットワークデバイスに送信する。ここで、第二の要求は、第一のオーディオパケットと同じPTSを持つビデオパケットを要求するために使用される。
【0011】
この設計方法では、電子デバイスは、オーディオ/ビデオストリームの第一のセグメント内のオーディオパケットとビデオパケットの間の照合ステータスに基づいて、オーディオ/ビデオストリームの第二のセグメントを要求してもよく、オーディオ/ビデオストリームの第二のセグメントには、オーディオ/ビデオストリームの第一のセグメントにないビデオパケットが含まれる。そのため、プレーヤのオーディオとビデオの同期効率がさらに向上する。
【0012】
可能な設計では、M個のデータパケットはすべてオーディオパケットであり、Y個のデータパケットはすべてビデオパケットである。代替的にM個のデータパケットはすべてビデオパケットであり、Y個のデータパケットはすべてオーディオパケットである。代替的に、M個のデータパケットは、オーディオ/ビデオストリームの第一のセグメントの最初のM個のデータパケットであり、Y個のデータパケットは、オーディオ/ビデオストリームの第二のセグメントの最初のY個のデータパケットである。
【0013】
この設計方法では、オーディオとビデオの同期効率をさらに向上させることができる。
【0014】
可能な設計では、電子デバイスは、第一のバッファユニットからM個のデータパケットを読み取る前に、まず第一のバッファユニットのデータパケットに対して照合を実行し、同じPTSを持つオーディオパケットとビデオパケットのペアを見つけた後に、プレーヤが同じPTSを持つオーディオパケットとビデオパケットのペアを再生するように制御することができる。次に、電子デバイスは、第一のバッファユニットにあり、オーディオパケットと同じPTSを持つマッチしたビデオパケットを持たないオーディオパケットを、第二のバッファユニットに格納する。または、第一のバッファユニットにあり、ビデオパケットと同じPTSを持つマッチしたオーディオパケットを持たないビデオパケットを、第二のバッファユニットに格納する。
【0015】
可能な設計では、Ｍは、Ｙに等しくてもよい。
【0016】
可能な設計では、この方法は、さらに以下を含む：オーディオ/ビデオストリームの第一のセグメントが一様にインターリーブされたオーディオ/ビデオストリームである場合、電子デバイスは、ストリームシーケンスに基づいて第一のバッファユニットのデータパケットを順番に読み取り、同じPTSを持つオーディオパケットとビデオパケットのペアが読み取られた後、同じPTSを持つオーディオパケットとビデオパケットのペアを再生するようにプレーヤを制御する。
【0017】
この設計方法では、電子デバイスは、一様にインターリーブされたオーディオ/ビデオストリームと非一様にインターリーブされたオーディオ/ビデオストリームに対して、オーディオとビデオの同期の異なる方法を使用してもよい。そのため、プレーヤのオーディオとビデオの同期効率をさらに向上させることができる。
【0018】
第2の態様によると、本出願の一実施形態は、1つ以上のプロセッサとメモリを含む電子デバイスを提供する。メモリはプログラム命令を格納する。電子デバイスによってプログラム命令が実行されると、本出願の実施形態における第1の態様および第1の態様の任意の可能な設計に従った方法が実現される。
【0019】
第３の態様によると、本出願の一実施形態は、チップを提供する。チップはデバイス内のメモリに結合されているため、チップは実行時にメモリに格納されたプログラム命令を呼び出し、本出願の実施形態における第1の態様および第1の態様の任意の可能な設計に従った方法を実現する。
【0020】
第４の態様によると、本出願の一実施形態は、コンピュータ可読記憶媒体を提供し、ここで、コンピュータ可読記憶媒体はプログラム命令を格納する。プログラム命令が電子デバイス上で実行されると、電子デバイスは、本出願の実施形態における第1の態様および第1の態様の任意の可能な設計に従った方法を実行できるようになる。
【0021】
第５の態様によると、本出願の一実施形態は、コンピュータプログラム製品を提供する。コンピュータプログラム製品が電子デバイス上で実行されると、電子デバイスは、本出願の実施形態における第1の態様および第1の態様の任意の可能な設計に従った方法を実行することができるようになる。
【0022】
また、第2の態様から第5の態様での任意の可能な設計方法によってもたらされる技術的効果については、方法パートにおける異なる設計方法によってもたらされる技術的効果を参照されたい。詳細はここには記載しない。
【図面の簡単な説明】
【0023】
【図1】一様にインターリーブされたオーディオ/ビデオストリームの可能な概略図である。
【図2】非一様にインターリーブされたオーディオ/ビデオストリームの可能な概略図の例である。
【図3】非一様にインターリーブされたオーディオ/ビデオストリームのオーディオとビデオの同期方法の可能なフローチャートである。
【図4】本出願の一実施形態に適用可能なオンライン再生システムの概略的なアーキテクチャ図である。
【図5】本出願の一実施形態に適用可能な別のオンライン再生システムの概略的なアーキテクチャ図である。
【図6】本出願の一実施形態による電子デバイス200のハードウェア構造を示す概略図である。
【図7】本出願の一実施形態による電子デバイス200のソフトウェア構造を示すブロック図である。
【図8】本出願の一実施形態によるオンラインオーディオ/ビデオ再生方法のフローチャートである。
【図9】本出願の一実施形態による非一様にインターリーブされたストリームを検出する方法のフローチャートである。
【図10】オーディオ/ビデオストリームの概略図である。
【図11】オーディオとビデオの同期の具体的な方法の概略図である。
【図12】オーディオとビデオの同期の別の具体的な方法の概略図である。
【図13】本出願の一実施形態によるオンラインオーディオ/ビデオ再生方法の別のフローチャートである。
【図14】本出願の一実施形態による電子デバイス1400の構造を示す概略図である。
【図15】本出願の一実施形態による電子デバイス1500の構造を示す概略図である。
【発明を実施するための形態】
【0024】
オンライン再生用のオーディオストリームとビデオストリーム (簡単にオーディオ/ビデオストリームと呼ぶ) は、通常、一様にインターリーブされた方法でMP4メディアファイルに格納される。図1は、一様にインターリーブされたオーディオ/ビデオストリームの可能な概略図である。Aはオーディオ (Audio) データパケット (簡単にオーディオパケットと呼ぶ) を表し、Vはビデオ (Video) データパケット (簡単にビデオパケットと呼ぶ) を表す。図1では、オーディオパケットとビデオパケット (簡単にオーディオおよびビデオパケットと呼ぶ) は、第1のオーディオパケットA0、第1のビデオパケットV0、第2のオーディオパケットA1、第2のビデオパケットV1、第3のオーディオパケットA2、第3のビデオパケットV2、…などの順序でインターリーブされている。ストリーム内で同じ再生時間を持つオーディオパケットとビデオパケットは隣接している。同じ再生時間を持つオーディオパケットとビデオパケットは、同じプレゼンテーションタイムスタンプ(Presentation Timestamp、PTS)を持つ。PTSは、いつクライアントがデータを表示 (またはエクスポートまたは再生) するかを示すために使用される。つまり、同じPTSを持つオーディオパケットとビデオパケットは、同期して再生 (またはエクスポートまたは表示) する必要がある。
【0025】
たとえば、図1では、第一のオーディオパケットA0が第一のビデオパケットV0に隣接している。第一のオーディオパケットA0と第一のビデオパケットV0は同じPTSを持ち、同期して再生する必要がある。第二のオーディオパケットA1は、第二のビデオパケットV1に隣接している。第二のオーディオパケットA1と第二のビデオパケットV1は同じPTSを持っており、同期して再生する必要がある。A1とV1のPTSは、A0とV0のPTSよりも後である。
【0026】
クライアントは、セグメント単位でサーバからオーディオ/ビデオストリームをダウンロードする。具体的には、クライアントは毎回(事前に設定された数のオーディオパケットとビデオパケットを含む)オーディオ/ビデオストリームのセグメントをダウンロードする。クライアントは、オーディオ/ビデオストリームの各セグメントのデータを前から後ろに順番に読み取りる。これにより、オーディオデータとビデオデータを同期して読み取り、同期して再生できる。
【0027】
ただし、オンライン再生技術の長期的な開発の後、特定のオーディオ/ビデオウェブサイトによって提供されるMP4メディアファイル内のオーディオストリームとビデオストリームは、非一様にインターリーブされる。たとえば、(TikTok、Kwaiなどのような)一部のショートビデオポータルサイトでは、ユーザがクライアントを使用してビデオを作成およびアップロードしてもよいし、別のユーザによってアップロードされたビデオを見てもよい。通常、ユーザはビデオを作成するときに、ビデオ再生効果を強化するためにビデオに(シェイク、ズーム、時間反転、アクションの繰り返しなどの)効果を適用する。その結果、ビデオに対してユーザが実行する操作によって、オーディオストリームとビデオストリームが非一様にインターリーブされ得る。
【0028】
非一様にインターリーブされたオーディオ/ビデオストリームを検出する技術では、クライアントはオーディオ/ビデオストリームを再生する前にオーディオ/ビデオストリームに対して位置分析を実行し、PTSが同じオーディオパケットとビデオパケットの格納位置間の距離が特定の距離を超えているかどうかを確認する。検出されたオーディオパケットとビデオパケットのうち、同じPTSを持つオーディオパケットとビデオパケットのほとんどのペアの格納位置間の距離が指定された距離を超えている場合、オーディオ/ビデオストリームのインターリーブ性能は比較的低い。この場合、オーディオ/ビデオストリームは非一様にインターリーブされたオーディオ/ビデオストリームである(非一様にインターリーブされたオーディオ/ビデオストリームは、代替的に、非一様にインターリーブされているオーディオ/ビデオストリーム、非一様にインターリーブされたストリーム、非一様にインターリーブされているストリーム、一様にインターリーブされていないストリーム、非インターリーブされたオーディオ/ビデオストリーム、非インターリーブされたストリームなどとも呼ばれる。本出願では、明細書において名前は限定されない。)。検出されたオーディオパケットとビデオパケットのうち、同じPTSを持つオーディオパケットとビデオパケットのほとんどのペアの格納位置間の距離が指定された距離を超えていない場合、オーディオ/ビデオストリームのインターリーブ性能は比較的良好である。この場合、オーディオ/ビデオストリームは一様にインターリーブされたオーディオ/ビデオストリームである(一様にインターリーブされたオーディオ/ビデオストリームは、代替的に、一様にインターリーブされているオーディオ/ビデオストリーム、一様にインターリーブされたストリーム、一様にインターリーブされているストリーム、インターリーブされたオーディオ/ビデオストリーム、インターリーブされたストリームなどとも呼ばれる。本出願では名前は限定されない。)。
【0029】
図2は、非一様にインターリーブされたオーディオ/ビデオストリームの可能な概略図である。図2では、オーディオパケットとビデオパケットは、第一のオーディオパケットA0、第二のオーディオパケットA1、第三のオーディオパケットA2、第四のオーディオパケットA3、第五のオーディオパケットA4、第一のビデオパケットV0、第二のビデオパケットV1、第三のビデオパケットV2、…などの順序でインターリーブされている。オーディオパケットとオーディオパケットは交互には現れない。そのため、同じPTSを持つオーディオパケットとビデオパケットが離れている場合があり得る。たとえば、 「指定された距離」 は2つのデータパケットの距離である。この場合、A0とV0は4つのデータパケット、A1とV1は4つのデータパケット、A2とV2は4つのデータパケットだけ離れており、2つのデータパケットの指定された距離をすべて超えている。したがって、オーディオ/ビデオストリームは非一様にインターリーブされている。
【0030】
ただし、前述の解決策の 「特定の距離」 と 「ほとんど」 は、手動で設定された経験値である。「特定の距離」 と 「ほとんど」 の値を設定すると、それらの値は固定の決定基準になる。しかし、実際の適用では、一様にインターリーブされたストリームと非一様にインターリーブされたストリームの明確な定義 (または明確な境界) はない。異なるインターリーブ状態のストリームは、クライアントの性能が異なるため、クライアントごとに再生効果が異なる。したがって、固定基準では、異なるインターリーブ状態のすべてのストリームの望ましい再生効果を保証できない。
【0031】
さらに、クライアントがサーバから非一様にインターリーブされたオーディオ/ビデオストリームをダウンロードし、しかし依然として一様にインターリーブされたオーディオ/ビデオストリームの読み取り方法を使用することによって、つまりストリームシーケンスに基づいてストリーム内のデータを前から後ろに順に読み取ることによって、ストリームからデータを読み取った後は、オーディオとビデオの同期要件は、読み取り中に満たされ得ない。
【0032】
非一様にインターリーブされたオーディオ/ビデオストリームのオーディオとビデオの同期の解決策は、ストリームのデータパケットを繰り返しダウンロードすることである。
【0033】
図3は、非一様にインターリーブされたオーディオ/ビデオストリームのオーディオとビデオの同期の方法の可能なフローチャートである。
【0034】
ステップ1:クライアントは、サーバへの第一のハイパーテキスト転送プロトコル(Hypertext Transfer Protocol、HTTP)要求 (HTTP1として記録される) を開始し、第一のデータセグメントを取得し (データセグメントのデータサイズは、クライアント上のバッファのサイズ以下である) 、第一のデータセグメントをバッファに格納する。ここで、第一のデータセグメントは、A1、A2、およびA3の3つのオーディオパケットを含む。クライアントは、バッファから第一のオーディオパケットA1を読み取り、PTSがA1と同じビデオパケットをバッファから検索する。第一のデータセグメントにPTSがA1と同じビデオパケットが含まれていない場合は、ステップ2が実行される。
【0035】
ステップ2:クライアントは、現在バッファに格納されている第一のデータセグメントをクリアし、サーバへの第二のHTTP要求 (HTTP2として記録) を開始し、第二のデータセグメントを取得して、第二のデータセグメントをバッファに格納する。ここで、第二のデータセグメントには、V1、V2、およびV3の3つのビデオパケットが含まれる。クライアントは、PTSがA1と同じビデオパケットV1をバッファから読み取る。A1がV1とアラインされた後、クライアントは次のデータパケット、つまりビデオパケットV2をバッファから読み取り続け、PTSがV2と同じオーディオパケットをバッファから検索する。PTSがV2と同じオーディオパケットが第二のデータセグメントに含まれていないことがわかった場合、ステップ3が実行される。
【0036】
ステップ3:クライアントは、現在バッファに格納されている第二のデータセグメントをクリアし、サーバへの第三のHTTP要求 (HTTP3として記録される) を開始し、第三のデータセグメントを取得して、第三のデータセグメントをバッファに格納する。第三のデータセグメントには、A2、A3、およびA4の3つのオーディオパケットが含まれる。クライアントは、PTSがV2と同じオーディオパケットA2をバッファから読み取る。A2がV2とアラインされた後、クライアントは次のデータパケット、つまりオーディオパケットA3をバッファから読み取り続け、PTSがA3と同じビデオパケットをバッファから検索する。PTSがA3と同じビデオパケットが第三のデータセグメントに含まれていないことが判明した場合、ステップ4が実行される。
【0037】
ステップ4:クライアントは、現在バッファに格納されている第三のデータセグメントをクリアし、サーバへの第四のHTTP要求 (HTTP4として記録される) を開始し、第四のデータセグメントを取得して、第四のデータセグメントをバッファに格納する。ここで、第四のデータセグメントには、V2、V3、およびV4の3つのビデオパケットが含まれる。クライアントは、PTSがA3と同じビデオパケットV3をバッファから読み取る。A3がV3とアラインされた後、クライアントは次のデータパケット、つまりビデオパケットV4をバッファから読み取り続け、PTSがV4と同じオーディオパケットをバッファから検索する。PTSがV4と同じオーディオパケットが第四のデータセグメントに含まれていないことが判明した場合は、ステップ5を実行する。
【0038】
上記の処理は、すべてのオーディオとビデオが再生されるまでポーリングモードで実行される。
【0039】
上記のプロセスから、この解決策では、クライアントはオーディオとビデオの同期のためにストリームのデータパケットを繰り返しダウンロードする必要があり、それは時間がかかり、読み取り効率が比較的低いことを学ぶことができる。また、同期して再生する必要があるオーディオとビデオのデータを適時に読み取ることができない。そのため、オーディオ/ビデオの再生中にフレームフリーズが発生する。
【0040】
非一様にインターリーブされたオーディオ/ビデオストリームのオーディオとビデオの同期の別の解決策は、ローカルバッファ技術を使用することである。この解決策では、オーディオ/ビデオの再生の前に、クライアントはHTTP要求を使用してオーディオ/ビデオストリームのサイズを取得し、サイズが特定の範囲内にあるすべてのオーディオ/ビデオストリームをダウンロードしてバッファし、オーディオ/ビデオストリームがローカルデバイスにダウンロードされた後にローカルデバイス上でオーディオ/ビデオストリームを再生する。この技術は、クライアントがオーディオ/ビデオストリームのダウンロードしながらオーディオ/ビデオストリームを再生している場合のオーディオとビデオの同期のために複数のHTTP要求を開始する際に消費される時間を短縮する。そのため、フレームフリーズが減少する。
【0041】
ただし、オーディオ/ビデオストリームをローカルデバイスにバッファリングするこの解決策は、比較的時間がかかる。そのため、再生はゆっくり開始される。つまり、ユーザは再生が開始されるまで比較的長い時間待つ必要がある。ユーザエクスペリエンスは貧弱である。また、この解決策は、データサイズがしきい値の範囲内(たとえば、データサイズが2G未満)の非一様にインターリーブされたオーディオ/ビデオストリームの再生中に発生するフレームフリーズにのみ適用可能である。この解決策は、データサイズがしきい値の範囲外にある非一様にインターリーブされたオーディオ/ビデオストリームの再生中に発生するフレームフリーズには適用不可のため、すべての非一様にインターリーブされたオーディオ/ビデオストリームの再生中に発生するフレームフリーズの問題を根本的に解決することはできない。
【0042】
前述の1つ以上の技術的問題を解決するために、本出願の実施形態は、オンラインオーディオ/ビデオ再生方法と電子デバイスを提供する。この解決策では、クライアントが各回に要求するバッファ (buffer)されるデータのサイズを、同じPTSを検出するための距離として使用する。これは、非一様にインターリーブされているオーディオパケットとビデオパケットの間の距離を正確に定義する。非一様にインターリーブされたオーディオ/ビデオストリームを決定する基準は、規制係数nによって規制され、nは異なるビデオ状態に基づいてクライアントによって動的に調整され得る。これにより、一定の決定条件が、異なるインターリーブ度を持つオーディオ/ビデオストリームに対して異なる再生効果を発生させることを防止する。さらに、クライアントは、HTTP要求を使用して複数回ダウンロードされるデータパケットを格納する少なくとも2つのバッファを割り当てる。次に、クライアントは、少なくとも2つのバッファ内のデータパケットに対してオーディオとビデオの同期をバッチで実行する。これにより、クライアントのオーディオとビデオの同期効率が向上し、オンラインオーディオ/ビデオ再生中のフレームフリーズが軽減される。
【0043】
以下では、本出願の実施形態での技術的な解決策について、本出願の実施形態における添付図面を参照して説明する。
【0044】
本出願の実施形態の説明において、「第一の」 および 「第二の」 という用語は、単に説明の目的で使用されているだけであり、相対的な重要性の表示または暗示、または示された技術的特徴の数の暗黙的な表示としては理解されないものとする。したがって、 「第一の」 または 「第二の」 によって限定される特徴は、明示的または暗黙的に1つ以上の特徴を含む場合があり得る。本出願の実施形態の説明において、特に断りのない限り、 「複数」 は2つ以上を意味する。
【0045】
図4は、本出願の実施形態に適用可能なオンライン再生システムの概略的なアーキテクチャ図である。システムは、サーバ101と電子デバイス102を含む。
【0046】
サーバ101はメディアファイルを格納する。メディアファイルはMP4形式でもよいし、別の形式でもよく、それは、本出願では限定されないサーバ101は、例えば、映画、テレビ、短いビデオなどの様々なメディアストリームといったオーディオ/ビデオストリームを電子デバイス102に提供してもよい。サーバ101は、タブレット、ノートパソコン、サーバ、ウェアラブルデバイス、またはオーディオ/ビデオ再生デバイスなどの計算能力を持つ任意の電子デバイスであってもよいし、または複数のそのような電子デバイスを含む電子デバイスシステムであってもよい。これは、本発明のこの実施形態において特に限定されない。
【0047】
電子デバイス102には、サーバ101に対応するクライアント (Client) がインストールされている。クライアントは、ユーザエンドとも呼ばれ、サーバに対応するプログラムであり、ユーザに対してローカルのオーディオおよびビデオサービスを提供する。たとえば、サーバ101がHuaweiサーバである場合、クライアントは電子デバイス102にインストールされた 「HUAWEI Video」 アプリであってもよい。電子デバイス102は、クライアントを実行することによってサーバ101との通信接続を確立し、サーバ101からオーディオ/ビデオストリームなどをデコードして再生することができる。いくつかの可能な実装では、クライアントは、具体的には、メディアプレーヤ(Media Renderer、MR)であってもよい。
【0048】
例えば、電子デバイス102は、クライアントを介してサーバ101からのオーディオ/ビデオストリームを要求し、本出願で提供される技術的解決策を使用して、非一様にインターリーブされたストリームを検出し、オーディオとビデオをオンラインで再生することができる。
【0049】
図4では、一例として、一つの電子デバイス102を使用している。実際の適用では、オンライン再生システムに複数の電子デバイス102が存在する場合がある。
【0050】
図5は、本出願の一実施形態に適用可能な別のオンライン再生システムの概略的なアーキテクチャ図である。このシステムは、サーバ、携帯電話、およびスマートテレビを含む。サーバは、オーディオ/ビデオストリームを提供することができる。携帯電話には、サーバに対応したクライアント (プレーヤなど) がインストールされている。携帯電話は、クライアントを介してサーバからのオーディオ/ビデオストリームを要求し、本出願で提供される技術的な解決策を使用して、非一様にインターリーブされたストリームを検出し、オーディオとビデオをオンラインで再生することができる。
【0051】
携帯電話とスマートテレビが同じローカルエリアネットワークに存在する場合、たとえば、携帯電話とスマートテレビが同じワイヤレス忠実度(Wireless Fidelity、Wi-Fi)に接続されている場合、携帯電話は画面投影プロトコルを使用してスマートテレビにデータを送信し、オーディオとビデオを再生するようにスマートテレビを制御することができる。画面投影プロトコルは、デジタルリビングネットワークアライアンス(Digital Living Network Alliance, DLNA)プロトコル、AirPlayプッシュプロトコル、Lelinkプロトコルなどであってもよい。このことは、本出願では限定されない。
【0052】
例えば、サーバから取得したオーディオ/ビデオストリームを再生する場合、携帯電話は画面投影操作を検出する。携帯電話は、画面投影操作に応じて、Wi-Fiネットワーク内で画面投影サービスに対応した電子デバイスを探す。スマートテレビを見つけた後に、携帯電話は、現在再生されているオーディオ/ビデオストリームのビデオアドレスをスマートテレビに送信する。アドレスを受信したスマートテレビは、アドレスに基づいてサーバに対応するオーディオ/ビデオストリームを要求し、オーディオ/ビデオストリームを再生する。このようにして、携帯電話からスマートテレビへの画面投影が実現される。
【0053】
画面投影中、携帯電話はスマートテレビの再生進行を制御できる。例えば、携帯電話は、再生の一時停止、次のエピソードの再生、音量の調整などをスマートテレビに命令することができる。携帯電話は画面投影プロセスにおける制御ポイントとして機能すると理解することができる。携帯電話は、スマートテレビとサーバとの間の接続を初期化および設定するが、本当の意味ではコンテンツ送信に直接関与しない。コンテンツ送信は、サーバとスマートテレビによって実現される。
【0054】
画面投影プロセスでは、スマートテレビは、オーディオ/ビデオストリームをダウンロードした後、さらに、本出願で提供される技術的な解決策を使用して、非一様にインターリーブされたストリームを検出し、オーディオとビデオをオンラインで再生することができる。
【0055】
本出願の実施形態における電子デバイスは、ネットワークに接続する機能と、オーディオとビデオを再生する機能を持つ任意の電子デバイスであることを理解すべきである。例えば、本出願の実施形態における電子デバイスは、携帯電話 (mobile phone) 、タブレット (tablet) 、無線トランシーバ機能を備えたコンピュータ、仮想現実(virtual reality、VR)デバイス、拡張現実(augmented reality、AR)デバイス、産業制御 (industrial control) における無線デバイス、無人運転 (unmanned driving) における無線デバイス、遠隔医療 (telemedicine) における無線デバイス、スマートグリッド (smart grid) における無線デバイス、交通安全 (transportation safety) における無線デバイス、スマートシティ (smart city) における無線デバイス、スマートホーム (smart home) における無線デバイスなどであってもよい。
【0056】
以下では、電子デバイスが携帯電話である例を用いて、本出願の一実施形態に適用される電子デバイスの構造の概略図を説明する。
【0057】
図6は、本出願の一実施形態に係る電子デバイス200のハードウェア構造を示す概略図である。
【0058】
電子デバイス200は、プロセッサ210、外部メモリインターフェイス220、内部メモリ221、ユニバーサルシリアルバス(universal serial bus、USB)インターフェイス230、充電管理モジュール240、電力管理モジュール241、バッテリ242、アンテナ1、アンテナ2、移動通信モジュール250、無線通信モジュール260、オーディオモジュール270、スピーカ270A、レシーバ270B、マイク270C、ヘッドセットインターフェイス270D、センサモジュール280、ボタン290、モータ291、インジケータ292、カメラ293、表示画面294、加入者識別モジュール(subscriber identification module、SIM)カードインターフェイス295などを含むことができる。センサモジュール280は、圧力センサ280A、ジャイロセンサ280B、気圧センサ280C、磁気センサ280D、加速度センサ280E、距離センサ280F、光学近接センサ280G、指紋センサ280H、温度センサ280J、タッチセンサ280K、周囲光センサ280L、骨伝導センサ280Mなどを含むことができる。
【0059】
本出願のこの実施形態に示されている構造は、電子デバイス200の限定を構成しないと理解してよい。本出願の他のいくつかの実施形態において、電子デバイス200は、図に示されている構成要素よりも多くの、または少ない構成要素を含んでもよいし、いくつかの構成要素を組み合わせてもよいし、いくつかの構成要素を分割してもよいし、または異なる構成要素配置を有してもよい。図に示されている構成要素は、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアの組み合わせによって実現されてもよい。
【0060】
プロセッサ210は、一つ以上の処理ユニットを含む場合がある。例えば、プロセッサ210は、アプリケーションプロセッサ(application processor、AP)、モデムプロセッサ、グラフィックス処理ユニット(graphics processing unit、GPU)、画像信号プロセッサ(image signal processor、ISP)、コントローラ、ビデオコーデック、デジタル信号プロセッサ(digital signal processor、DSP)、ベースバンドプロセッサ、および/または神経処理ユニット(neural processing unit、NPU)を含んでもよい。異なる処理ユニットは、独立した構成要素である場合もあれば、1つ以上のプロセッサに統合されている場合もあり得る。本出願のこの実施形態では、オンラインオーディオ/ビデオ再生方法の実行は、プロセッサ210によって制御される場合もあれば、別の構成要素を呼び出すことによってプロセッサ210によって完了される場合もあり得る。たとえば、プロセッサ210は、本出願のこの実施形態における内部メモリ221に格納されている処理プログラムを呼び出すか、または外部メモリインターフェイス220を使用して、本出願のこの実施形態におけるサードパーティのデバイスに格納されている処理プログラムを呼び出して、非一様にインターリーブされたストリームの決定要因を動的に調整する。これにより、固定された決定条件が、異なるインターリーブ度を持つオーディオ/ビデオストリームに対して異なる再生効果を引き起こすことが防止される。さらに、プロセッサ210は、ダウンロードされたデータのビデオおよびオーディオパケットをバッチで読み取るために、クライアントに2つのバッファを割り当てる。これにより、クライアントのオーディオとビデオの同期効率が向上する。
【0061】
内部メモリ221には、プログラム格納領域とデータ格納領域を含めることができる。プログラム格納領域には、オペレーティングシステム、少なくとも一つの機能 (オーディオ再生機能やビデオ再生機能など) に必要なアプリケーションなどを格納することができる。データ格納領域には、電子デバイス200を使用するプロセスで作成された(オーディオデータ、ビデオデータ、再生ログなどの)データなどを格納することができる。さらに、内部メモリ221は、高速ランダムアクセスメモリを含むことができ、さらに不揮発性メモリ、例えば、少なくとも一つの磁気ディスク記憶装置、フラッシュメモリ、またはユニバーサルフラッシュ記憶装置(universal flash storage、UFS)を含むことができる。内部メモリ221は、本出願のこの実施形態で提供されるオンラインオーディオ/ビデオ再生解決策のコンピュータ実行可能プログラムコードを格納するように構成することができ、ここで、実行可能プログラムコードは、命令を含む。プロセッサ210は、インターフェイススイッチング解決策であり、内部メモリ221に格納されているコンピュータ実行プログラムコードを実行することができ、本出願のこの実施形態で提供されるオンラインオーディオ/ビデオ再生解決策を電子デバイス200が実現することができる。
【0062】
電子デバイス200は、GPU、表示画面294、アプリケーションプロセッサなどを使用して表示機能を実現する。例えば、電子デバイス200は、サーバから取得したオーディオ/ビデオストリームにビデオデータを表示する。GPUは画像処理用のマイクロプロセッサであり、表示画面294とアプリケーションプロセッサに接続されている。GPUは数学的および幾何学的計算を実行し、画像をレンダリングするように構成されている。プロセッサ210は、表示情報を生成または変更するようにとのプログラム命令を実行する一つ以上のGPUを含むことができる。
【0063】
電子デバイス200は、ISP、カメラ293、ビデオコーデック、GPU、表示画面294、アプリケーションプロセッサなどを使用して、さらに撮影機能を実現することができる。
【0064】
SIMカードインターフェース295は、SIMカードに接続するように構成されている。SIMカードは、SIMカードインターフェース295に挿入されるか、SIMカードインターフェース295から取り外されるかして、電子デバイス200と接触または分離することができる。電子デバイス200は、1つまたはN個のSIMカードインターフェイスをサポートすることができ、ここで、Nは1より大きい正の整数である 。SIMカードインターフェイス295は、ナノSIMカード、マイクロSIMカード、SIMカードなどをサポートできる。同じSIMカードインターフェイス295に複数のカードを同時に挿入できる。複数のカードは同じ種類の場合も、異なる種類の場合もあり得る。SIMカードインターフェース295は、異なる種類のSIMカードと互換性があり得る。SIMカードインターフェース295は、外部ストレージカードと互換性があり得る。電子デバイス200は、SIMカードを使用することによってネットワークと相互に作用し、通話機能やデータ通信機能などを実装する。いくつかの実施形態では、電子デバイス200はeSIM、つまり埋め込まれたSIMカードを使用する。
【0065】
電子デバイス200の無線通信機能は、アンテナ1、アンテナ2、移動通信モジュール250、無線通信モジュール260、モデムプロセッサ、ベースバンドプロセッサなどを使用して実装することができる。アンテナ1とアンテナ2は、電磁波信号を送受信するように構成されている。電子デバイス200の各アンテナは、一つ以上の通信周波数帯をカバーするように構成することができる。アンテナの利用率を改善するために、異なるアンテナをさらに多重化することができる。例えば、アンテナ1を無線ローカルエリアネットワークのダイバーシティアンテナとして多重化することができる。他のいくつかの実施形態では、アンテナをチューニングスイッチと組み合わせて使用することができる。
【0066】
移動通信モジュール250は、電子デバイス200に適用される無線通信解決策、例えば、2G/3G/4G/5G通信解決策などを提供することができる。移動通信モジュール250は、少なくとも一つのフィルタ、スイッチ、電力増幅器、低雑音増幅器(low noise amplifier、LNA)などを含むことができる。移動通信モジュール250は、アンテナ1を介して電磁波を受信し、受信した電磁波に対してフィルタリングや増幅などの処理を行い、処理した電磁波をモデムプロセッサに送信して復調することができる。移動通信モジュール250は、モデムプロセッサによって変調された信号をさらに増幅し、アンテナ1を介して電磁波に変換して放射することができる。いくつかの実施形態では、移動通信モジュール250内の少なくともいくつかの機能モジュールをプロセッサ210内に配置することができる。いくつかの実施形態では、移動通信モジュール250の少なくともいくつかの機能モジュールをプロセッサ210の少なくともいくつかのモジュールと同じ構成要素内に配置することができる。
【0067】
無線通信モジュール260は、電子デバイス200に適用され、(無線忠実度(wireless fidelity、Wi-Fi)ネットワークなどの)無線ローカルエリアネットワーク(wireless local area network、WLAN)、Bluetooth (Bluetooth、BT)、全地球航法衛星システム(global navigation satellite system、GNSS)、周波数変調(frequency modulation、FM)、近距離無線通信(near field communication、NFC)技術、および赤外線放射(infrared radiation、IR)技術を含む無線通信解決策を提供することができる。無線通信モジュール260は、少なくとも一つの通信プロセッサモジュールを統合する一つ以上の構成要素であってもよい。無線通信モジュール260は、アンテナ2を介して電磁波を受信し、電磁波信号に対して周波数変調およびフィルタリング処理を行い、処理された信号をプロセッサ210に送信する。無線通信モジュール260は、さらにプロセッサ210から送信される信号を受信し、その信号に対して周波数変調および増幅を行い、アンテナ2を介して電磁波に変換して放射することができる。
【0068】
いくつかの実施形態では、電子デバイス200において、アンテナ1と移動通信モジュール250が結合され、アンテナ2と無線通信モジュール260が結合される。このようにして、電子デバイス200は、無線通信技術を用いて、ネットワークや他の機器と通信することができる。無線通信技術には、移動通信のためのグローバルシステム(global system for mobile communications、GSM)、一般的なパケット無線サービス(general packet radio service、GPRS)、符号分割多元接続(code division multiple access、CDMA)、広帯域符号分割多元接続(wideband code division multiple access、WCDMA)、時分割符号分割多元接続(time-division code division multiple access、TD-SCDMA)、長期的な進化(long term evolution、LTE)、BT、GNSS、WLAN、NFC、FM、IR技術などが含まれる。
【0069】
本出願の他のいくつかの実施形態では、電子デバイス200は、図に示されているものよりも多くのまたは少数の構成要素を含むか、いくつかの構成要素を結合するか、いくつかの構成要素を分割するか、または異なる構成要素の配置を持つことができる。図に示されている構成要素は、ハードウェア、ソフトウェア、またはソフトウェアとハードウェアの組み合わせによって実装されることがある。
【0070】
電子デバイス200のソフトウェアシステムは、階層化アーキテクチャ、イベント駆動アーキテクチャ、マイクロカーネルアーキテクチャ、マイクロサービスアーキテクチャ、またはクラウドアーキテクチャを使用することができる。本出願の実施形態では、電子デバイス200のソフトウェア構造を記述するために、階層化アーキテクチャのAndroidシステムの例を使用する。
【0071】
図7は、本出願の実施形態による電子デバイス200のソフトウェア構造を示すブロック図である。ソフトウェアモジュールおよび/またはソフトウェア構造のコードを内部メモリ221に格納してもよい。プロセッサ210は、ソフトウェアモジュールまたはコードを実行すると、本出願の実施形態で提供されるオンラインオーディオ/ビデオ再生方法を実行する。
【0072】
階層化アーキテクチャでは、ソフトウェアはいくつかのレイヤーに分割され、各レイヤーは明確な役割とタスクを持っている。レイヤーはソフトウェアインターフェイスを介して互いと通信する。いくつかの実施形態では、Androidシステムは上から下に、アプリケーション層、アプリケーションフレームワーク層、Androidランタイム (Android runtime) とシステムライブラリ、およびカーネル層の4つのレイヤーに分割される。
【0073】
アプリケーション層には、一連のアプリケーションパッケージが含まれ得る。
【0074】
図7に示すように、アプリケーションパッケージには、電話、カメラ、ギャラリー、カレンダー、通話、地図、ナビゲーション、WLAN、Bluetooth、音楽、ビデオ、メッセージなどのアプリケーションが含まれ得る。
【0075】
アプリケーションフレームワーク層は、アプリケーションプログラミングインターフェイス(application programming interface、API)と、アプリケーション層でのアプリケーションのプログラミングフレームワークを提供する。アプリケーションフレームワーク層には、いくつかの事前に定義された関数が含まれている。
【0076】
図7に示すように、アプリケーションフレームワーク層には、ウィンドウマネージャ、コンテンツプロバイダ、ビューシステム、電話マネージャ、リソースマネージャ、通知マネージャなどが含まれ得る。
【0077】
ウィンドウマネージャは、ウィンドウプログラムを管理するように構成されている。ウィンドウマネージャは、表示画面のサイズを取得したり、ステータスバーがあるかどうかを判断したり、画面ロックを実行したり、スクリーンショットを撮ったりすることができる。
【0078】
コンテンツプロバイダーは、データを格納して取得し、アプリケーションがデータにアクセスできるように構成されている。たとえば、データには、サーバから取得したオーディオデータとビデオデータ、および電子デバイスの閲覧履歴とブックマークが含まれる。
【0079】
ビューシステムには、テキストを表示する制御や画像を表示する制御などの視覚的な制御が含まれる。ビューシステムは、アプリケーションを構築するように構成できる。表示インターフェイスには、1つ以上のビューが含まれ得る。たとえば、SMSメッセージの通知アイコンを含む表示インターフェイスには、テキストを表示するビューとイメージを表示するビューが含まれ得る。
【0080】
電話マネージャは、例えばサーバへの接続のステータス管理などのような電子デバイスの通信機能を提供するように構成されている。
【0081】
リソースマネージャは、ローカライズされた文字列、アイコン、画像、ビデオファイルなど、アプリケーションのさまざまなリソースを提供する。
【0082】
通知マネージャは、アプリケーションが、ステータスバーに通知情報を表示することを可能にし、そして通知メッセージを伝達するように構成されてもよい。表示された通知情報は、ユーザの操作なしに、少しした後、自動的に消えてもよい。たとえば、通知マネージャは、オーディオまたはビデオがダウンロードされたことを通知したり、メッセージ通知を提供したりなどするように構成されている。また、通知マネージャーは、例えばバックグラウンドで実行されているアプリケーションの通知をグラフまたはスクロール可能なテキストの形式でシステムの上部ステータスバーに通知を表示してもよいし、またはダイアログボックスの形式で画面に現れる通知を表示してもよい。たとえば、テキスト情報が、ステータスバーに表示されたり、プロンプトトーンが表示されたり、電子デバイスが振動したり、またはインジケータライトが点滅したりする。
【0083】
Androidランタイムには、カーネルライブラリと仮想マシンが含まれている。Androidランタイムは、Androidシステムのスケジュールと管理を担当する。
【0084】
カーネルライブラリには、Javaで呼び出す必要がある関数と、Androidのカーネルライブラリの2つの部分が含まれている。
【0085】
アプリケーション層とアプリケーションフレームワーク層は仮想マシン上で動作する。仮想マシンは、アプリケーション層とアプリケーションフレームワーク層のJavaファイルをバイナリファイルとして実行する。仮想マシンは、オブジェクトライフサイクル管理、スタック管理、スレッド管理、セキュリティおよび例外管理、ガベージコレクションなどの機能を実装するように構成されている。
【0086】
システムライブラリは、例えば、サーフェスマネージャ (surface manager) 、メディアライブラリ (Media Libraries) 、(OpenGL ESなどの)3Dグラフィックス処理ライブラリ、(SGLなどの) 2Dグラフィックスエンジンのような複数の機能モジュールを含むことができる。
【0087】
サーフェスマネージャは、表示サブシステムを管理し、複数のアプリケーションに対して2Dレイヤーと3Dレイヤーの融合を提供するように構成されている。
【0088】
メディアライブラリは、一般的に使用される複数のオーディオおよびビデオ形式、および静的イメージファイルでの再生と記録をサポートしている。メディアライブラリは、MPEG-4、H.264、MP3、AAC、AMR、JPG、PNGなどの複数のオーディオおよびビデオコーディング形式をサポートしている場合があり得る。
【0089】
3Dグラフィックス処理ライブラリは、3Dグラフィックス描画、画像レンダリング、合成、レイヤー処理などを実装するように構成されている。
【0090】
2Dグラフィックスエンジンは、2D描画用の描画エンジンである。
【0091】
カーネル層は、ハードウェアとソフトウェアの間の層である。カーネル層は、少なくとも一つの表示ドライバ、カメラドライバ、オーディオドライバ、およびセンサドライバ含む。本出願の実施形態では、ハードウェアは、例えば、加速度センサ、ジャイロセンサ、タッチセンサ、および圧力センサなど、さまざまなタイプのセンサを指す場合があり得る。
【0092】
【0093】
以下では、本出願の実施形態を電子デバイス200に適用した場合の例を用いて、本出願の実施形態で提供される解決策を詳細に説明する。
【0094】
図8は、本出願の一実施形態によるオンラインオーディオ/ビデオ再生方法を示している。この方法は、以下のようなステップを含む：
【0095】
S801:電子デバイスは、クライアントを介して、サーバに第一のHTTP要求を送信し、サーバは、第一のHTTP要求を受信する。
【0096】
本出願のこの実施形態はクライアントがHTTPプロトコルに基づいてサーバと通信する例を使用していると理解され得る。したがって、電子デバイスがクライアントを介してサーバに送信する要求の種類はHTTP要求である。ただし、実際の適用では、クライアントは別のプロトコルに基づいてサーバと代替的に通信する場合がある。つまり、クライアントは別のタイプの要求をサーバに送信することもできる。これは、本出願では限定されない。
【0097】
S802:サーバは、第一のHTTP要求に応答して、オーディオ/ビデオストリームの第一のセグメントを電子デバイスに返す。電子デバイスは、オーディオ/ビデオストリームの第一のセグメントを受信し、オーディオ/ビデオストリームの第一のセグメントを第一のバッファユニットに格納する。
【0098】
第一のバッファユニットは、ダウンロードされたオーディオ/ビデオストリームを格納するために電子デバイスによって割り当てられたバッファ (Buffer) である。毎回HTTP要求を使用してダウンロードされるデータパケットは、まず第一のバッファユニットに格納される。なお、電子デバイスがHTTP要求を送信する前に毎回、電子デバイスは、HTTP要求を使用してダウンロードされたデータパケットを格納するために第一のバッファユニットのデータをクリアする必要があることを理解すべきである。第一のバッファユニットは、電子デバイスの内部メモリの記憶空間の一部であってもよいことを理解すべきである。
【0099】
本出願の実施形態では、電子デバイスが毎回HTTP要求を使用して要求するオーディオ/ビデオストリームのデータサイズは、例えば1回の伝送でバッファされるデータサイズであって、HTTPプロトコルで指定されるサイズに事前に設定されている。事前設定されたサイズは、電子デバイスがダウンロードされるオーディオ/ビデオストリームを格納するために割り当てた第一のバッファユニットのサイズを超えない。
【0100】
わかりやすくするために、オーディオ/ビデオストリームの第一のセグメントはBuffer-1として記録され、Buffer-1には少なくとも2つのデータパケットが含まれている。本出願のこの実施形態では、データパケットはオーディオとビデオの2つのデータ型である。オーディオデータ型のデータパケットはオーディオパケットとも呼ばれ、ビデオデータ型のデータパケットはビデオパケットとも呼ばれる。
【0101】
オーディオ/ビデオストリームの第一のセグメントには、オーディオパケットのみが含まれる場合もあれば、ビデオパケットのみが含まれる場合もあり、オーディオパケットとビデオパケットの両方が含まれる場合もあると理解できる。オーディオ/ビデオストリームの第一のセグメントのデータパケットの特定のデータ型は、サーバに格納されているメディアファイルの形式によって決定される。
【0102】
S803:電子デバイスは、第一のバッファユニットにバッファされたオーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたストリームであるかどうかを検出する。
【0103】
オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたストリームでない(つまり、オーディオ/ビデオストリームの第一のセグメントが一様にインターリーブされたストリームである)場合、S804が実行される。
【0104】
オーディオ/ビデオストリームの第一のセグメントが非一様インターリーブストリームである場合、S805からS810が実行される。
【0105】
S804:電子デバイスは、ストリームシーケンスに基づいて第一のバッファユニット内のデータパケットを順次読み取り、PTSが同じオーディオパケットとビデオパケットのペアを読み取った後、PTSが同じオーディオパケットとビデオパケットのペアを再生する。
【0106】
例えば、図9に示す方法を使用して、図10に示す実施形態のHTTP3に対応するストリームが一様にインターリーブされたストリームであると判断した後、電子デバイスは、ストリームシーケンスのA9とV9、A10とV10、A11とV11、およびA12とV12を前から後ろに順に読み取って再生してもよい。なお、図9および図10については後述する。
【0107】
S804が実行された後、オンライン再生用の現在のメディアファイルが完全に再生されなかった場合、電子デバイスはS801に戻り、次のHTTP要求を送信し、新しいオーディオ/ビデオストリームを取得し、オンライン再生用の現在のメディアファイル内のすべてのオーディオ/ビデオストリームが取得されて再生されるまで、新しいオーディオ/ビデオストリームに対して前述の操作プロセスを実行する。
【0108】
新しいオーディオ/ビデオストリームは、一様にインターリーブされる場合も、非一様にインターリーブされる場合もあり、新しいオーディオ/ビデオストリームの特定のタイプも、サーバに格納されているメディアファイルの形式によって決定されることを理解しておく必要があり得る。
【0109】
S805:電子デバイスは、第一のバッファユニットからM個のデータパケットを読み取り、M個のデータパケットを第二のバッファユニット (Mは1より大きい正の整数) に格納する。Mには、30、50、100などのプリセット値を指定できる。本出願では限定されない。
【0110】
本出願のこの実施形態では、第一のバッファユニットに加えて、N個の隣接するHTTP要求を使用してダウンロードされたデータを格納するために、別のN個のバッファユニットが電子デバイスにさらに配置される。Nは1より大きい正の整数であり、N個のバッファユニットはN個のHTTP要求を使用してダウンロードされたデータと1対1で対応している。N個のバッファユニットは、代わりに電子デバイスの内部メモリ内の異なる記憶空間であってもよいことを理解しておく必要があり得る。
【0111】
以下の実施形態では、例えばN=2である。具体的には、第二のバッファユニットと第三のバッファユニットをさらに電子デバイス内に配置し、隣接する2つのHTTP要求(たとえば、次の説明の第一のHTTP要求と第二のHTTP要求)を使用して取得したデータパケットを格納する構成とする。第二のバッファユニットと第三のバッファユニットは、2つの異なるバッファ空間として理解される場合もあれば、同じバッファ空間内の2つの異なるバッファ領域として理解される場合もある。これは本出願では限定されない。
【0112】
電子デバイスは、第一のバッファユニット(つまり、オーディオ/ビデオストリームの第一のセグメントからM個のデータパケットを読み取る。)からM個のデータパケットを読み取り、第二のバッファユニットに格納する。第二のバッファユニットのデータパケット(つまり、M個のデータパケット)は、オーディオパケットとビデオパケットを含む場合もあれば、オーディオ/ビデオストリームの第一のセグメントのインターリーブ方法に依存するオーディオパケットのみまたはビデオパケットのみを含む場合もあることを理解する必要がある。
【0113】
任意で、M個のデータパケットのPTSは連続している。
【0114】
任意で、オーディオ/ビデオストリームの第一のセグメントには、合計S個のデータパケットが含まれる。ここで、S≧Mである。M個のデータパケットは、オーディオ/ビデオストリームの第一のセグメントの最初のM個のデータパケット(具体的には、データパケット1～M)または最後のM個のデータパケット(具体的には、データパケット(S－
M+1)～S)である。
M+1)～S)である。
【0115】
任意で、S805では、電子デバイスが第一のバッファユニットからM個のデータパケットを読み取る前に、電子デバイスは最初にオーディオパケットを第一のバッファユニットのオーディオ/ビデオストリームの第一のセグメントのビデオパケットと一致させることができます(つまり、PTSが同じオーディオパケットとビデオパケットを検出する。)。PTSが同じオーディオパケットとビデオパケットのペアが読み込まれた後、電子デバイスはPTSが同じオーディオパケットとビデオパケットのペアを再生する。そして、電子デバイスは、PTSがオーディオパケットと同じビデオパケットに一致しないM個のオーディオパケットだけを第二のバッファユニットに格納します(つまり、第二のバッファユニット内のM個のデータパケットはすべてオーディオパケットである)。あるいは、PTSがビデオパケットと同じオーディオパケットに一致しないM個のビデオパケットを第二のバッファユニットに格納する(つまり、第二のバッファユニットのM個のデータパケットはすべてビデオパケットである)。これにより、オンライン再生の効率をさらに向上させることができる。
【0116】
S806:電子デバイスは、M個のデータパケット内の第一のオーディオパケットとPTSが同じビデオパケット(たとえば、第一のビデオパケット)がM個のデータパケットに含まれていないことを検出する。
【0117】
第一のオーディオパケットは、M個のデータパケット内の任意のオーディオパケットであってもよい。
【0118】
任意で、電子デバイスは、PTSシーケンスに基づいて、M個のデータパケット内の各オーディオパケットが対応するビデオパケット(つまり、PTSがオーディオパケットと同じビデオパケット)を持つかどうかを順次検出してもよい。
【0119】
S807:電子デバイスは、クライアントを介してサーバに第二のHTTP要求を送信し、PTSが第一のオーディオパケットと同じビデオパケットを要求する。サーバは、第二のHTTP要求を受信する。
【0120】
S808:サーバは、第二のHTTP要求に応答して、オーディオ/ビデオストリームの第二のセグメントを電子デバイスに返す。オーディオ/ビデオストリームの第二のセグメントには、PTSが第一のオーディオパケットと同じビデオパケット(つまり、第一のビデオパケット)が含まれる。電子デバイスは、オーディオ/ビデオストリームの第二のセグメントを受信し、オーディオ/ビデオストリームの第二のセグメントを第一のバッファユニットに格納する。
【0121】
S809:電子デバイスは、第一のバッファユニットからY個のデータパケットを読み取り、Y個のデータパケットを第三のバッファユニットに格納する (Y個のデータパケットには第一のビデオパケットが含まれる) 。
【0122】
Yは正の整数である。任意でY=Mである。
【0123】
なお、前述のS806～S809は、オーディオパケット(つまり、第一のオーディオパケット)に対応するビデオパケット(つまり、第一のビデオパケット)がないことを検出した後、オーディオパケットに対応するビデオパケットを取得するために、第二のHTTP要求を開始する例を用いて説明する。ただし、実際のアプリケーションでは、複数のオーディオパケットに対応するビデオパケットがないことを検出した後、複数のオーディオパケットに対応するビデオパケットを取得するために、第二のHTTP要求を開始することもできる。
【0124】
または、M個のデータパケットにA個のオーディオパケットが含まれており、Aが1より大きい正の整数であるA個のオーディオパケットと同じPTSを持つビデオパケットがM個のデータパケットに含まれていないことを電子デバイスが検出した場合、S806～S809を次の手順で置き換えることもできる。電子デバイスは、クライアントを介して第二のHTTP要求をサーバに送信し、そこで第二のHTTP要求を使用して、PTSがA個のオーディオパケットと同じであるビデオパケットを要求する。サーバは、第二のHTTP要求を受信し、第二のHTTP要求に応答してオーディオ/ビデオストリームの第二のセグメントを電子デバイスに返する。ここで、オーディオ/ビデオストリームの第二のセグメントには、PTSがA個のオーディオパケットと同じであるビデオパケットが含まれます(たとえば、オーディオ/ビデオストリームの第二のセグメントにはB個のビデオパケットが含まれる。B≧Aであり、B個のビデオパケットには、A個のオーディオパケットと1対1で対応するAビデオパケットが含まれる。)。電子デバイスは、第一のバッファユニットからY個のデータパケットを読み取り、Y個のデータパケットを第三のバッファユニットに格納する。
【0125】
場合によっては、M個のデータパケット内の各オーディオパケットに同じPTSのビデオパケットが含まれていないことがあり得る。この場合、電子デバイスはクライアントを介して第二のHTTP要求をサーバに送信し、M個のデータパケット内のすべてのオーディオパケットと同じPTSのビデオパケットを要求する。
【0126】
また、M個のデータパケット内の一部のオーディオパケットだけが、同じPTSを持つビデオパケットを持たない場合もあり得る。この場合、電子デバイスはクライアントを介して第二のHTTP要求をサーバに送信し、PTSがオーディオパケットと同じであるビデオパケットを要求する。
【0127】
たとえば、M個のデータパケットには合計7つのオーディオパケット (M≧7) が含まれ、そのうち3つのオーディオパケットには、M個のデータパケット内の3つのオーディオパケットとPTSが同じであるビデオパケットが含まれている。この場合、第二のHTTP要求を使用して、PTSが他の4つのオーディオパケットと同じであるビデオパケットを要求する。ここで、Yは4以上である。
【0128】
また、M個のデータパケット内にオーディオパケットと同じPTSのビデオパケットがあるかどうかを検出する例として、S806～S809が提供されていることに注意してください。ただし、具体的な実装では、M個のデータパケット内にビデオパケットと同じPTSのオーディオパケットがあるかどうかも検出される場合があり得る。例えば、M個のデータパケット内の第一のビデオパケットと同じPTSのオーディオパケット(たとえば、第一のオーディオパケット)がM個のデータパケットに含まれていないことを検出した電子デバイスは、HTTP要求を送信して、第一のビデオパケットと同じPTSのオーディオパケットを要求する。
【0129】
S810:電子デバイスは、第二のバッファユニット内のデータパケットと第三のバッファユニット(つまり、PTSが同じであるオーディオパケットとビデオパケットを検出する。)内のデータパケットを照合し、PTSが同じオーディオパケットとビデオパケット(たとえば、第一のオーディオパケットと第一のビデオパケット)のいずれかのペアを読み込んだ後、PTSが同じオーディオパケットとビデオパケットのペアを再生する。
【0130】
その後、電子デバイスは、第二のバッファユニットと第三のバッファユニット内のデータパケットをクリアし、その後新しいデータパケットを格納することができる。
【0131】
オンライン再生用の現在のメディアファイルが完全に再生されていない場合、電子デバイスはS801に戻り、次のHTTP要求を送信し、新しいオーディオ/ビデオストリームを取得し、オンライン再生用の現在のメディアファイル内のすべてのオーディオ/ビデオストリームが取得されて再生されるまで、新しいオーディオ/ビデオストリームでS801からS810を実行する。
【0132】
前述の技術的解決策をよりよく理解するために、詳細な例をここに示し、前述の技術的解決策をさらに説明する。
【0133】
図11を参照されたい。例えば、M=Y=5とする。
【0134】
ステップ1:クライアントは、第一のHTTP要求(HTTP1として記録される)をサーバに開始し、第一のデータセグメントをダウンロードする(データセグメントのデータサイズは、クライアント上のダウンロードバッファ、つまり第一のバッファユニットのサイズ以下である)。ここで、第一のデータセグメントには、A0、A1、A2、A3、およびA4が含まれる。クライアントは、ダウンロードバッファ(つまり、第一のバッファユニット)からA0、A1、A2、A3、およびA4を読み取り、第一のデータセグメントが非一様にインターリーブされたオーディオ/ビデオストリームであって、A0、A1、A2、A3、およびA4は対応するビデオパケットがないと決定し、第一のデータセグメントのオーディオパケットA0、A1、A2、A3、およびA4を第二のバッファユニットに格納する。
【0135】
ステップ2:クライアントは、第二のHTTP要求(HTTP2として記録される)をサーバに開始し、第二のデータセグメントをダウンロードする(データセグメントのデータサイズは、クライアント上のダウンロードバッファ、つまり第一のバッファユニットのサイズ以下である)。ここで、第二のデータセグメントには、（A0、A1、A2、A3、およびA4にそれぞれ対応する）V0、V1、V2、V3、およびV4が含まれる。クライアントは、ダウンロードバッファからV0、V1、V2、V3、およびV4を読み取り、第二のデータセグメントが非一様にインターリーブされたオーディオ/ビデオストリームであると決定し、第二のデータセグメントのビデオパケットV0、V1、V2、V3、およびV4を第三のバッファユニットに格納する。
【0136】
ステップ3:電子デバイスは、PTSが同じであるオーディオパケットとビデオパケットをそれぞれ第二のバッファユニットと第三のバッファユニットから読み取り、PTSが同じであるオーディオパケットとビデオパケットの任意のペアが読み取られた後、PTSが同じであるオーディオパケットとビデオパケットの当該ペアを再生する。
【0137】
たとえば、A0とV0のPTSが同じであると判断した場合、電子デバイスはA0とV0を同期して再生する。A1とV1のPTSが同じであると判断した場合、電子デバイスはA1とV1を同期して再生する。A2とV2のPTSが同じであると判断した場合、電子デバイスはA2とV2を同期して再生する。A3とV3のPTSが同じであると判断した場合、電子デバイスはA3とV3を同期して再生する。A4とV4のPTSが同じであると判断した場合、電子デバイスはA4とV4を同期して再生する。
【0138】
ステップ4:クライアントは、第三のHTTP要求(HTTP3として記録される)をサーバに開始し、第三のデータセグメントをダウンロードし(データセグメントのデータサイズは、クライアントのダウンロードバッファのサイズ以下)、第三のデータセグメントに対して上述の手順を引き続き実行する。具体的な手順については、ステップ1から3を参照されたく、詳細はここでは述べない。
【0139】
なお、上記の実施形態では、隣接する2つのHTTP要求(つまり、N=2)を使用して得られたデータパケットに対してマッチングが行われることを理解しておく必要がある。実際のアプリケーションでは、3つ、4つ、または5つの隣接するHTTP要求(つまり、Nは代わりに2、3、4などに等しい場合がある)を使用して得られたデータパケットに対してもマッチングが行われる場合がある。これは本出願では限定されない。
【0140】
本出願のこの実施形態では、非一様にインターリーブされたオーディオ/ビデオストリームに対して、電子デバイスは、クライアントがHTTP要求を使用して複数回ダウンロードされるデータパケットを格納するために少なくとも2つの追加バッファを割り当てることができ、その後、バッチで少なくとも2つのバッファ内のデータパケットに対してオーディオとビデオの同期を実行する。ストリームのデータパケットを複数回繰り返しダウンロードしてオーディオとビデオの同期を実行する解決策と比較して、本出願のこの実施形態は、クライアントのオーディオとビデオの同期効率を向上させることができる。ローカルバッファを使用する技術的な解決策と比較して、本出願の実施形態はバッファ時間を短縮することができる。本出願の実施形態は、任意のサイズのオーディオおよびビデオのオンライン再生に適用でき、すべてのオーディオおよびビデオのオンライン再生中のフレームフリーズの問題を根本的に解決できる。
【0141】
図12を参照されたい。例えば、M=6、Y=5とする。
【0142】
ステップ1:クライアントは、第一のHTTP要求（HTTP1として記録される）をサーバに開始し、第一のデータセグメントをダウンロードする(データセグメントのデータサイズは、クライアント上のダウンロードバッファ、つまり第一のバッファユニットのサイズ以下である)。ここで、第一のデータセグメントには、A0、V0、A1、A2、A3、およびA4が含まれる。クライアントは、ダウンロードバッファ(つまり、第一のバッファユニット)からA0、V0、A1、A2、A3、およびA4を読み取り、第一のデータセグメントが非一様にインターリーブされたオーディオ/ビデオストリームであると判断し、A0がV0とマッチする（A0とV0のPTSが同じである）ためA0とV0を再生し、A1、A2、A3、およびA4には対応するビデオパケットがないためA1、A2、A3、およびA4を第二のバッファユニットに格納する。
【0143】
ステップ2:クライアントは、第二のHTTP要求（HTTP2として記録される）サーバに開始し、第二のデータセグメントをダウンロードする(データセグメントのデータサイズは、クライアント上のダウンロードバッファ、つまり第一のバッファユニットのサイズ以下である)。ここで、第一のデータセグメントには、(A1、A2、A3、およびA4にそれぞれ対応する)V1、V2、V3、およびV4が含まれる。クライアントは、ダウンロードバッファからV1、V2、V3、およびV4を読み取り、第二のデータセグメントが非一様にインターリーブされたオーディオ/ビデオストリームであると判断し、第二のデータセグメントのビデオパケットV1、V2、V3、およびV4を第三のバッファユニットに格納する。
【0144】
ステップ3:電子デバイスは、PTSが同じオーディオパケットとビデオパケットをそれぞれ第二のバッファユニットと第三のバッファユニットから読み取り、PTSが同じオーディオパケットとビデオパケットの任意のペアを読み取られた後、PTSが同じオーディオパケットとビデオパケットの当該ペアを再生する。
【0145】
たとえば、A1とV1のPTSが同じであると判断した場合、電子デバイスはA1とV1を同期して再生する。A2とV2のPTSが同じであると判断した場合、電子デバイスはA2とV2を同期して再生する。A3とV3のPTSが同じであると判断した場合、電子デバイスはA3とV3を同期して再生する。A4とV4のPTSが同じであると判断した場合、電子デバイスはA4とV4を同期して再生する。
【0146】
ステップ4:クライアントは、第三のHTTP要求(HTTP3として記録される)をサーバに開始し、第三のデータセグメントをダウンロードし(データセグメントのデータサイズがクライアントのダウンロードバッファのサイズ以下)、第三のデータセグメントに対して上述の手順を引き続き実行する。具体的な手順については、ステップ1から3を参照されたく、詳細はここでは述べない。
【0147】
任意で、特定の実装では、S806からS809を代替的に以下の手順に置き換えることもできる：S805が実行された後、電子デバイスは直接第二のHTTP要求を送信し、第二のHTTP要求を使用してオーディオ/ビデオストリームの第二のセグメントを取得し、オーディオ/ビデオストリームの第一のセグメントの第一のPTS範囲とオーディオ/ビデオストリームの第二のセグメントの第二のPTS範囲が事前設定された条件を満たする。サーバは、第二のHTTP要求に応答してオーディオ/ビデオストリームの第二のセグメントを返する。電子デバイスは、オーディオ/ビデオストリームの第二のセグメントを受信し、第三のバッファユニットのオーディオ/ビデオストリームの第二のセグメントにY個のデータパケットを格納する。第一のPTS範囲は、オーディオ/ビデオストリームの第一のセグメントのデータパケットの最小PTSから最大PTSまでの範囲であり、第二のPTS範囲は、オーディオ/ビデオストリームの第二のセグメントのデータパケットの最小PTSから最大PTSまでの範囲である。
【0148】
第一の PTSレンジと第二の PTSレンジが一部重複している、第一の PTSレンジが第二の PTSレンジに含まれている、第一の PTSレンジが第二の PTSレンジに含まれている、第一の PTSレンジと第二の PTSレンジが近接している(例えば、あらかじめ設定された距離を超えないようにする)などのプリセット条件が考えられる。
【0149】
つまり、本出願のこの実施形態の電子デバイスは、M個のデータパケット内のオーディオパケットとビデオパケットの正確な一致状態(つまり、S806を実行できない可能性がある)を知る必要はなく、オーディオ/ビデオストリームの第一のセグメントの第一のPTS範囲に基づいて、オーディオ/ビデオストリームの第二のセグメントを直接要求する。
【0150】
これにより、少なくとも2つのバッファ内のデータパケットに対して、オーディオとビデオの同期をバッチで実行することができる。そのため、クライアントのオーディオとビデオの同期効率が向上する。
【0151】
この用途に応じて、非一様にインターリーブされたストリームを検出する方法について説明する。図9に示すように、この方法には次のステップが含まれる。
【0152】
S901:電子デバイスは、同じPTSを検出するための距離として、オーディオ/ビデオストリームの第一のセグメントのサイズ (Buffer-1) など、クライアントが毎回要求するバッファデータのサイズを使用する。は、各オーディオパケットに対応し、オーディオ/ビデオストリームの第一のセグメントのオーディオパケットと同じPTSを持つビデオパケットがBuffer-1に含まれるかどうかを決定し、ビデオパケットがBuffer-1に含まれる場合は、オーディオパケットをインターリーブオーディオパケットa1として記録し、ビデオパケットがBuffer-1に含まれない場合は、オーディオパケットを非インターリーブパケットa2として記録する。は、各ビデオパケットに対応し、オーディオ/ビデオストリームの第一のセグメントの動画パケットと同じPTSを持つオーディオパケットが同期ウィンドウBuffer-1の長さ距離内にあるかどうかを決定し、オーディオパケットが同期ウィンドウBuffer-1の長さ距離内にある場合は、動画パケットをインターリーブ動画パケットV1として記録し、オーディオパケットが同期ウィンドウBuffer-1の長さ距離内にない場合は、動画パケットを非インターリーブ動画パケットV2として記録する。
【0153】
S902:電子デバイスは、オーディオ/ビデオストリームの第一のセグメントのa1,v1,a2,v2の合計数に対するa1,v1の合計数の比((a1+v1)(a1+v1+a2+v2)として記録される)が、あらかじめ設定された比nより大きいかどうかを判断する。オーディオ/ビデオストリームの第一のセグメントのa1, v1, a2, v2の合計数に対するa1, v1の合計数の比があらかじめ設定された比nより大きい場合、オーディオ/ビデオストリームの第一のセグメントは、一様にインターリーブされたオーディオ/ビデオストリームになる。オーディオ/ビデオストリームの第一のセグメントのa1, v1, a2, v2の合計数に対するa1, v1の合計数の比があらかじめ設定された比nより大きくない場合、オーディオ/ビデオストリームの第一のセグメントは、非一様にインターリーブされたオーディオ/ビデオストリームになる。
【0154】
nは調整係数であり、係数とも呼ばれるか、さらに別の名前である場合もある。これは、本出願のこの実施形態に限定されない。
【0155】
さらに、電子デバイスは、履歴オーディオ/ビデオストリームが再生されるときに、クライアントの再生ステータス(たとえば、フレームフリーズが発生するかどうか)に基づいてnを調整することができる。たとえば、履歴オーディオ/ビデオストリームの場合、 (a1+v1) / (a1+v1+a2+v2) <pの場合、クライアントでの再生中にフレームフリーズが発生し、 (a1+v1) / (a1+v1+a2+v2) ≧pの場合、クライアントでの再生中にフレームフリーズは発生しない。n=pと決定される。例えば (a1+v1) / (a1+v1+a2+v2) ≦qの場合、クライアントでの再生中にフレームフリーズが発生し、 (a1+v1) / (a1+v1+a2+v2)> qの場合、クライアントでの再生中にフレームフリーズは発生しない。n=qと判断される。
【0156】
確かに、前述のnを調整するための式は限定ではなく単なる例であり、実際の適用ではさらに拡張される可能性があり得る。例えば、 (a1+v1) / (a1+v1+a2+v2) <pの場合、クライアントでの再生中にフレームフリーズが発生し、 (a1+v1) / (a1+v1+a2+v2) ≧pの場合、クライアントでの再生中にフレームフリーズは発生しない。n=p+Δpであると判定される。ここで、Δpは事前に設定された係数であり、1－p>Δp≧0である。あるいは、例えば (a1+v1) / (a1+v1+a2+v2) ≦qの場合、クライアントでの再生中にフレームフリーズが発生し、 (a1+v1) / (a1+v1+a2+v2) >qの場合、クライアントでの再生中にフレームフリーズは発生しない。n=q+Δq であると判定される。ここで、Δqは事前に設定された係数であり、1－q>Δq≧0である。
【0157】
任意で、nの初期値は0.4、0.5、0.6などとすることができる。これはここでは限定されない。ΔpまたはΔqは、0.01、0.05、0.1のように指定された値にすることができる。これはここでは限定されない。
【0158】
また、電子デバイスは、クライアントがサーバからダウンロードしたオーディオ/ビデオストリームの各セグメントに対して、個別にインターリーブ型検出を実行する。図10を例とする。クライアントのnが0.7であるとする。HTTP1を使用して要求されたオーディオ/ビデオストリームの場合、 (a1+v1) / (a1+v1+a2+v2) =2/9<0.7であれば、電子デバイスはHTTP1を使用して要求されたオーディオ/ビデオストリームが非一様にインターリーブされたオーディオ/ビデオストリームであると判断する。HTTP2を使用して要求されたオーディオ/ビデオストリームの場合、 (a1+v1) / (a1+v1+a2+v2) =2/9 <0.7では、電子デバイスはHTTP2を使用して要求されたオーディオ/ビデオストリームが非一様にインターリーブされたオーディオ/ビデオストリームであると判断する。HTTP3を使用して要求されたオーディオ/ビデオストリームの場合、 (a1+v1) / (a1+v1+a2+v2) =8/9> 0.7であれば、電子デバイスはHTTP3を使用して要求されたオーディオ/ビデオストリームが一様にインターリーブされたオーディオ/ビデオストリームであると判断する。
【0159】
以上のことから、本出願のこの実施形態の電子デバイスは、異なるインターリーブ度を持つオーディオ/ビデオストリームに対して一定の決定条件が異なる再生効果を引き起こすことを防止するために、異なるインターリーブ度を持つストリームの実際の再生効果に基づいて規制係数nの値を決定することができることがわかる。
【0160】
上記の実施形態に基づいて、図13は、本出願の実施形態によるオンラインオーディオ/ビデオ再生方法を示す。この方法は、以下のステップを含む。
【0161】
S1301:電子デバイスがネットワーク機器に第一の要求を送信する。
【0162】
S1302:電子デバイスは、第一の要求に基づいてネットワーク機器からフィードバックされるオーディオ/ビデオストリームの第一のセグメントを受信し、オーディオ/ビデオストリームの第一のセグメントを第一のバッファユニットに格納する。オーディオ/ビデオストリームの第一のセグメントにはあらかじめ設定された数のデータパケットが含まれ、オーディオ/ビデオストリームの第一のセグメントのデータパケットにはオーディオパケットおよび/またはビデオパケットが含まれる。
【0163】
S1303:オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたオーディオ/ビデオストリームである場合、電子デバイスは第一のバッファユニットからM個のデータパケットを読み取り、M個のデータパケットを第二のバッファユニットに格納する (Mは1より大きい正の整数) 。
【0164】
非一様にインターリーブされたオーディオ/ビデオストリームは、オーディオ/ビデオストリームの第一のセグメントに含まれ、再生ゼンテーションタイムスタンプPTSが同じで、格納位置が指定された距離のしきい値を超えるオーディオパケットとビデオパケットの数を意味する。
【0165】
S1304:電子デバイスは、第一のバッファユニットのデータパケットをクリアし、ネットワーク機器に第二の要求を送信する。
【0166】
S1305:電子デバイスは、第二の要求に基づいてネットワーク機器からフィードバックされるオーディオ/ビデオストリームの第二のセグメントを受信し、オーディオ/ビデオストリームの第二のセグメントを第一のバッファユニットに格納する。オーディオ/ビデオストリームの第二のセグメントには、あらかじめ設定された数のデータパケットが含まれ、オーディオ/ビデオストリームの第二のセグメントのデータパケットには、オーディオパケットおよび/またはビデオパケットが含まれる。
【0167】
S1306:電子デバイスは、第一のバッファユニットからY個のデータパケットを読み取り、Y個のデータパケットを第三のバッファユニット (Yは1より大きい正の整数) に格納する。
【0168】
S1307:電子デバイスは、第二のバッファユニットのデータパケットと第三のバッファユニットのデータパケットを照合し、PTSが同じオーディオパケットとビデオパケットのペアを見つけた後、PTSが同じオーディオパケットとビデオパケットのペアを再生するように制御する。
【0169】
図13に示す方法の具体的な関連実装については、前述の各実施形態の関連説明を参照のこと。詳細はここでは説明しない。
【0170】
本出願における上記の実施形態は、異なる技術的効果を達成するために、別々に使用することも、組み合わせて使用することもできる。
【0171】
本出願において提供される上記の実施形態において、本出願の実施形態で提供される方法は、実行主体となる電子デバイスの観点から記述される。本出願の上記の実施形態で提供される方法で機能を実装するために、電子デバイスは、ハードウェア構造および/またはソフトウェアモジュールを含み、ハードウェア構造、ソフトウェアモジュール、またはハードウェア構造とソフトウェアモジュールの組み合わせの形式で機能を実装することができる。上記の機能の機能が、ハードウェア構造、ソフトウェアモジュール、またはハードウェア構造とソフトウェアモジュールの組み合わせを使用して実装されるかどうかは、技術的解決策および設計上の制約の特定の用途に依存する。
【0172】
同じ概念に基づき、図14は、この用途で提供される電子デバイス1400を示す。電子デバイス1400は、図8、図9、または図13に示す方法を実行するように構成される。例えば、電子デバイス1400は、通信モジュール1401と処理モジュール1402を含む。
【0173】
例えば、通信モジュール1401は、ネットワークデバイスに第一の要求を送信し、第一の要求に基づいてネットワークデバイスによってフィードバックされるオーディオ/ビデオストリームの第一のセグメントを受信し、オーディオ/ビデオストリームの第一のセグメントを第一のバッファユニットに格納するように構成される。オーディオ/ビデオストリームの第一のセグメントには事前に設定された数のデータパケットが含まれ、オーディオ/ビデオストリームの第一のセグメントのデータパケットにはオーディオパケットおよび/またはビデオパケットが含まれる。
【0174】
処理モジュール1402は、オーディオ/ビデオストリームの第一のセグメントが非一様にインターリーブされたオーディオ/ビデオストリームである場合、第一のバッファユニットからM個のデータパケットを読み取り、M個のデータパケットを第二のバッファユニットに格納するように構成されている。ここで、Mは1より大きい正の整数である。および第一のバッファユニットのデータパケットをクリアする。
【0175】
非一様にインターリーブされたオーディオ/ビデオストリームは、オーディオ/ビデオストリームの第一のセグメントに含まれ、再生ゼンテーションタイムスタンプPTSが同じで、格納位置が指定された距離のしきい値を超えるオーディオパケットとビデオパケットの数を意味する。
【0176】
通信モジュール1401は、ネットワークデバイスに第二の要求を送信し、第二の要求に基づいてネットワークデバイスによってフィードバックされるオーディオ/ビデオストリームの第二のセグメントを受信するようにさらに構成されている。
【0177】
処理モジュール1402は、オーディオ/ビデオストリームの第二のセグメントを第一のバッファユニットに格納するようにさらに構成されており、オーディオ/ビデオストリームの第二のセグメントには事前設定された数のデータパケットが含まれ、オーディオ/ビデオストリームの第二のセグメントのデータパケットにはオーディオパケットおよび/またはビデオパケットが含まれている。は、第一のバッファユニットからY個のデータパケットを読み取り、Y個のデータパケットを第三のバッファユニットに格納します (Yは1より大きい正の整数) 。そして、第二のバッファユニットのデータパケットと第三のバッファユニットのデータパケットを照合し、PTSが同じであるオーディオパケットとビデオパケットのペアが見つかった後、PTSが同じであるオーディオパケットとビデオパケットのペアを再生するプレーヤを制御する。
【0178】
同じ概念に基づき、図15に本出願で提供される電子デバイス1500を示す。電子デバイス1500はプロセッサ1510とメモリ1520を含む。メモリ1520はプログラム命令を格納する。プログラム命令が実行されると、電子デバイス1500は図8、図9または図13に示す方法を実行できるようになる。
【0179】
本出願のこの実施形態では、プロセッサ1510は、汎用プロセッサ、デジタルシグナルプロセッサ(digital signal processor、DSP)、特定用途向け集積回路(application-specific integrated circuit、ASIC)、フィールドプログラマブルゲートアレイ(field-programmable gate array、FPGA)または別のプログラマブルロジックデバイス、離散ゲートまたはトランジスタロジックデバイス、または離散ハードウェア構成要素であってもよい。本出願の実施形態で開示されているメソッド、ステップ、および論理ブロック図を実装または実行することができる。汎用プロセッサはマイクロプロセッサであってもよく、プロセッサは従来のプロセッサなどであってもよい。本出願の実施形態を参照して開示された方法のステップは、ハードウェア・デコード・プロセッサを介して直接実行され、達成されてもよく、またはデコード・プロセッサ内のハードウェアとソフトウェア・モジュールの組み合わせを使用して実行され、達成されてもよい。ソフトウェア・モジュールは、ランダムアクセス・メモリ(random access memory、RAM)、フラッシュ・メモリ、読み取り専用メモリ(read-only memory、ROM)、プログラム可能なリードオンリー・メモリ、電気的に消去可能なプログラム可能なメモリ、またはレジスタなどの、当技術分野の成熟した記憶媒体に配置されていてもよい。記憶媒体はメモリ内に配置され、プロセッサはメモリ内の命令を読み取り、プロセッサのハードウェアと組み合わせて前述の方法のステップを完了する。
【0180】
本出願のこの実施形態では、メモリ1520は、ハードディスクドライブ(hard disk drive、HDD)やソリッドステートドライブ(solid-state drive、SSD)のような不揮発性メモリであってもよく、ランダムアクセスメモリ(random access memory、RAM)のような揮発性メモリ (volatile memory) であってもよい。メモリは、予想されるプログラムコードを命令またはデータ構造の形で保持または格納することができ、コンピュータがアクセスできるその他の媒体であるが、これに限定されない。本出願の実施形態におけるメモリは、記憶機能を実装できる回路またはその他の装置であってもよく、プログラム命令および/またはデータを格納するように構成されている。
【0181】
装置の特定の実装の関連する機能については、前述の方法の部分を参照のこと。詳細はここでは説明しない。
【0182】
本出願における上記の実施形態は、異なる技術的効果を達成するために、別々に使用することも、組み合わせて使用することもできる。
【0183】
上記のように、上記の各実施形態は、本出願の技術的解決策を詳細に説明するために使用されるに過ぎない。ただし、上記の各実施形態の説明は、本出願の実施形態における方法を理解するために使用されるに過ぎず、本出願の実施形態に対する限定として解釈されるべきではない。当業者が容易に理解できるバリエーションまたは交換品は、本出願の実施形態の保護範囲に含まれるものとする。
【0184】
文脈によれば、上記の実施形態で使用される 「いつ」 という用語は、 「if」 、 「after」 、 「決定に応答して」 、または 「検出に応答して」 の意味として解釈される場合がある。同様に、文脈によれば、 「when it is determined that」 または 「if (述べられた条件または事象) is detected」 という語句は、 「if it is determined that」 または 「in response to determined」 または 「when (述べられた条件または事象) is detected」 または 「in response to detecting (述べられた条件または事象) 」 の意味として解釈される場合がある。
【0185】
上記の実施形態の全部または一部は、ソフトウェア、ハードウェア、ファームウェア、またはそれらの任意の組み合わせを使用して実装することができる。ソフトウェアを使用して実施形態を実装する場合、実施形態の全部または一部をコンピュータプログラム製品の形で実装することができる。コンピュータプログラム製品は、1つ以上のコンピュータ命令を含む。コンピュータプログラム命令がコンピュータにロードされて実行されると、本出願の実施形態に従った手順または機能が全部または一部生成される。コンピュータは、汎用コンピュータ、専用コンピュータ、コンピュータネットワーク、またはその他のプログラム可能な装置である。コンピュータの命令は、コンピュータが読み取り可能な記憶媒体に格納される場合もあれば、コンピュータが読み取り可能な記憶媒体から別のコンピュータが読み取り可能な記憶媒体に送信される場合もある。例えば、コンピュータの命令は、ウェブサイト、コンピュータ、サーバ、またはデータセンターから別のウェブサイト、コンピュータ、サーバ、またはデータセンターに有線(たとえば、同軸ケーブル、光ファイバ、デジタル加入者線など)または無線(赤外線、ラジオ、マイクロ波など)で送信される場合がある。コンピュータが読み取り可能な記憶媒体は、コンピュータがアクセス可能な任意の使用可能な媒体、または1つ以上の使用可能な媒体を統合したデータ記憶装置、例えば、サーバまたはデータセンターであってもよい。使用可能な媒体は、磁気媒体(たとえば、フロッピーディスク、ハードディスク、磁気テープなど)、光媒体(例えばDVD)、半導体媒体(たとえば、ソリッドステートドライブ)などであってもよい。
【0186】
説明のため、具体的な実施形態を参照して説明する。ただし、前述の例の説明は、詳細に説明することを意図したものではなく、本出願を開示された正確な形式に限定することを意図したものではない。前述の教育内容に基づいて、多くの修正形式やバリエーション形式が可能である。本出願の原理および原理の実際的な適用を十分に説明するために、本出願および着想された特定の用途に適用可能な様々な修正を加えた様々な実施形態を、当業者が十分に活用できるように、実施形態が選択および記述される。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】