(57)【特許請求の範囲】
【請求項１】
ネットワーク機器によって実行されるデータバッファリング方法であって、
マルチメディアデータと、前記マルチメディアデータを前記ネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得するステップと、
前記端末機器に対応する、前記マルチメディアデータを再生するための再生パラメータを取得するステップと、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定するステップと、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定するステップと、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信するステップと、
を含み、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定するステップは、
前記再生パラメータの重みと、前記通信ネットワークのネットワーク特徴情報の重みとを取得するステップ、
取得された前記重みに基づいて、前記再生パラメータ及び前記通信ネットワークのネットワーク特徴情報をそれぞれ重み付け処理するステップ、
重み付け処理された前記再生パラメータ及び前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定するステップと、
を含む、方法。
【請求項２】
前記再生パラメータに基づいて、前記端末機器に対応する所定データ量を決定するステップと、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータの、データ量が前記所定データ量である第２バッファリングデータを決定するステップと、
前記端末機器及び前記ネットワーク機器によって前記第２通信ネットワークが確立されると、データ量が前記再生パラメータとマッチングする前記第２バッファリングデータを前記端末機器に送信するステップと、
をさらに含む請求項１に記載の方法。
【請求項３】
前記再生パラメータに基づいて、前記端末機器に対応する所定データ量を決定するステップとは、
前記再生パラメータの重みと、前記端末機器のバッファ容量の重みとを取得するステップと、
取得された前記重みに基づいて、前記再生パラメータ及び前記バッファ容量をそれぞれ重み付け処理するステップと、
重み付け処理された前記再生パラメータ及び前記バッファ容量に基づいて、前記端末機器とマッチングする所定データ量を決定するステップと、を含む、
請求項２に記載の方法。
【請求項４】
前記目標データ量は、ＧＯＰの数量で表され、
前記端末機器に対応する目標データ量を決定するステップは、
バッファリングを必要とする前記端末機器のＧＯＰの第１数量を決定するステップと、
前記第１数量のＧＯＰの総データ量を、前記端末機器に対応する目標データ量として決定するステップと、を含む、
請求項１又は２に記載の方法。
【請求項５】
前記通信ネットワークのネットワーク特徴情報に基づいて、前記第１バッファリングデータに対してフレームドロップ処理を行うと決定した場合、音声フレーム及び／又は映像フレームのフレームタイプの優先順位を取得するステップと、
前記フレームタイプの優先順位にしたがって、前記第１バッファリングデータにおける音声フレーム及び／又は映像フレームに対してフレームドロップ処理を行うステップと、
をさらに含む請求項１又は２に記載の方法。
【請求項６】
ネットワーク機器であって、
マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報と、前記端末機器に対応する、前記マルチメディアデータを再生するための再生パラメータと、を取得するように構成される取得手段と、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定するように構成される処理手段と、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータの、前記目標データ量を有する第１バッファリングデータを決定するように構成されるバッファリング手段と、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信するように構成される送信手段と、
を備え、
前記処理手段は、さらに、前記再生パラメータの重みと、前記通信ネットワークのネットワーク特徴情報の重みとを取得し、
取得された前記重みに基づいて、前記再生パラメータ及び前記通信ネットワークのネットワーク特徴情報をそれぞれ重み付け処理し、
重み付け処理された前記再生パラメータ及び前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定する、ように構成される、ネットワーク機器。
【請求項７】
前記処理手段は、さらに、前記再生パラメータに基づいて、前記端末機器に対応する所定データ量を決定するように構成され、
前記バッファリング手段は、さらに、取得された前記マルチメディアデータに基づいて、前記マルチメディアデータの、データ量が前記所定データ量である第２バッファリングデータを決定するように構成され、
前記送信手段は、さらに、前記端末機器及び前記ネットワーク機器によって前記第２通信ネットワークが確立される際に前記端末機器により生成された目標指示を検出すると、データ量が前記再生パラメータとマッチングする前記第２バッファリングデータを前記端末機器に送信するように構成される、
請求項６に記載のネットワーク機器。
【請求項８】
前記処理手段は、さらに、前記再生パラメータの重みと、前記端末機器のバッファ容量の重みとを取得し、
取得された前記重みに基づいて、前記再生パラメータ及び前記バッファ容量をそれぞれ重み付け処理し、
重み付け処理された前記再生パラメータ及び前記バッファ容量に基づいて、前記端末機器とマッチングする所定データ量を決定する、ように構成される、
請求項７に記載のネットワーク機器。
【請求項９】
前記目標データ量は、ＧＯＰの数量で表され、
前記処理手段は、さらに、バッファリングを必要とする前記端末機器のＧＯＰの第１数量を決定し、
前記第１数量のＧＯＰの総データ量を、前記端末機器に対応する目標データ量として決定する、ように構成される、
請求項６又は７に記載のネットワーク機器。
【請求項１０】
前記処理手段は、さらに、前記通信ネットワークのネットワーク特徴情報に基づいて、前記第１バッファリングデータに対してフレームドロップ処理を行うと決定した場合、音声フレーム及び／又は映像フレームのフレームタイプの優先順位を取得し、
前記フレームタイプの優先順位にしたがって、前記第１バッファリングデータにおける音声フレーム及び／又は映像フレームに対してフレームドロップ処理を行う、ように構成される、
請求項６又は７に記載のネットワーク機器。
【請求項１１】
ネットワーク機器によって実行されるデータバッファリング方法であって、前記ネットワーク機器が、１つ又は複数のプロセッサと、メモリと、１つ以上のプログラムと、を備え、前記１つ以上のプログラムがメモリに記憶され、前記プログラムには、それぞれが１組の命令に対応する１つ以上のユニットが含まれることが可能であり、前記１つ又は複数のプロセッサが、命令を実行するように構成され、
マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報と、前記端末機器に対応する、前記マルチメディアデータを再生するための再生パラメータと、を取得し、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定し、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定し、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信する、
ことを含み、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定することは、
前記再生パラメータの重みと、前記通信ネットワークのネットワーク特徴情報の重みとを取得し、
取得された前記重みに基づいて、前記再生パラメータ及び前記通信ネットワークのネットワーク特徴情報をそれぞれ重み付け処理し、
重み付け処理された前記再生パラメータ及び前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定する、ことを含む、方法。
【請求項１２】
前記再生パラメータに基づいて、前記端末機器に対応する所定データ量を決定し、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータの、データ量が前記所定データ量である第２バッファリングデータを決定し、
前記端末機器及び前記ネットワーク機器によって前記第２通信ネットワークが確立される際に前記端末機器により生成された目標指示を検出し、
前記目標指示にしたがって、データ量が前記再生パラメータとマッチングする前記第２バッファリングデータを前記端末機器に送信する、
ことをさらに含む請求項１１に記載の方法。
【請求項１３】
前記再生パラメータに基づいて、前記端末機器に対応する所定データ量を決定することは、
前記再生パラメータの重みと、前記端末機器のバッファ容量の重みとを取得し、
取得された前記重みに基づいて、前記再生パラメータ及び前記バッファ容量をそれぞれ重み付け処理し、
重み付け処理された前記再生パラメータ及び前記バッファ容量に基づいて、前記端末機器とマッチングする所定データ量を決定する、ことを含む、
請求項１２に記載の方法。
【請求項１４】
前記目標データ量は、ＧＯＰの数量で表され、
前記端末機器に対応する目標データ量を決定することは、
バッファリングを必要とする前記端末機器のＧＯＰの第１数量を決定し、
前記第１数量のＧＯＰの総データ量を、前記端末機器に対応する目標データ量として決定する、ことを含む、
請求項１１又は１２に記載の方法。
【請求項１５】
前記通信ネットワークのネットワーク特徴情報に基づいて、前記第１バッファリングデータに対してフレームドロップ処理を行うと決定した場合、音声フレーム及び／又は映像フレームのフレームタイプの優先順位を取得し、
前記フレームタイプの優先順位にしたがって、前記第１バッファリングデータにおける音声フレーム及び／又は映像フレームに対してフレームドロップ処理を行う、
ことをさらに含む請求項１１又は１２に記載の方法。
【請求項１６】
プロセッサと、プロセッサで実行可能なコンピュータプログラムを記憶するように構成されるメモリと、を備えるネットワーク機器であって、
前記プロセッサが、前記コンピュータプログラムが実行されると、請求項１乃至５のいずれか１項に記載のデータバッファリング方法を実行するように構成される、
ネットワーク機器。
【請求項１７】
コンピュータに請求項１乃至５のいずれか１項に記載のデータバッファリング方法を実行させるコンピュータ実行可能命令が記憶されたコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本願は、出願番号が２０１７１０３４５０７０．４であって、出願日が２０１７年５月１６日である中国特許出願に基づいて提出し、この中国特許出願の優先権を主張し、ここで参照としてこの中国特許出願のすべての内容を本願に援用する。
【０００２】
本発明は、通信技術に関し、特にデータバッファリング方法、ネットワーク機器、及び記憶媒体に関する。
【背景技術】
【０００３】
従来のライブ配信において、コンテンツ配信ネットワーク（ＣＤＮ：Ｃｏｎｔｅｎｔ  Ｄｅｌｉｖｅｒｙ  Ｎｅｔｗｏｒｋ）ノードは、ユーザの要求（例えば、遅延要求など）に応じて、ユーザに対して、配信者の音声／映像データ（バッファリングデータと呼ばれてもよい）を記憶するためのバッファ領域を設定する。さらに、該ユーザがＣＤＮノードにアクセスすると、前記ＣＤＮノードは、設定された該バッファ領域にバッファリングされている配信者の音声／映像データをユーザに１回で全部送信する。ユーザは、ライブ配信の視聴中に、ＣＤＮノードからリアルタイムに送信された配信者の音声／映像データを受信することができる。ここで、ユーザがＣＤＮノードにアクセスすると、ＣＤＮノードは、バッファ領域にバッファリングされている配信者の音声／映像データをユーザに１回で全部送信するので、ユーザによる再生の際にカクカク（コマ落ち）する場合がある。
【発明の概要】
【発明が解決しようとする課題】
【０００４】
本発明の実施例では、ライブ配信時のデータの滑らかな再生を実現することが可能なデータバッファリング方法及びネットワーク機器を提供することが期待される。
【課題を解決するための手段】
【０００５】
本発明の実施例の解決手段は、次のように構成される。
【０００６】
第１方面で、本発明の実施例は、データバッファリング方法を提供している。前記方法は、
ネットワーク機器が、マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得し、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定し、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定し、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信する、ことを含む。
【０００７】
第２方面で、本発明の実施例は、ネットワーク機器を提供している。前記ネットワーク機器は、
マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得するように構成される取得手段と、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定するように構成される処理手段と、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータの、前記目標データ量を有する第１バッファリングデータを決定するように構成されるバッファリング手段と、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信するように構成される送信手段と、を備える。
【０００８】
第３方面で、本発明の実施例は、もう１つのデータバッファリング方法を提供している。前記方法は、ネットワーク機器によって実行され、前記ネットワーク機器が、１つ又は複数のプロセッサと、メモリと、１つ以上のプログラムと、を備え、前記１つ以上のプログラムがメモリに記憶され、前記プログラムには、それぞれが１組の命令に対応する１つ以上のユニットが含まれることが可能であり、前記１つ又は複数のプロセッサが、命令を実行するように構成され、前記方法は、
マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得し、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定し、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定し、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信する、ことを含む。
【０００９】
第４方面で、本発明の実施例は、もう１つのネットワーク機器を提供している。前記ネットワーク機器は、プロセッサと、プロセッサで実行可能なコンピュータプログラムを記憶するように構成されるメモリと、を備え、
前記プロセッサが、前記コンピュータプログラムが実行されると、上記のデータバッファリング方法を実行するように構成される。
【００１０】
第５方面で、本発明の実施例は、コンピュータに上記のデータバッファリング方法を実行させるコンピュータ実行可能命令が記憶されたコンピュータ可読記憶媒体も提供している。
【発明の効果】
【００１１】
本発明の実施例におけるデータバッファリング方法、ネットワーク機器、及び記憶媒体によれば、少なくとも以下の有益な技術的効果を奏する。
【００１２】
端末機器に対応する目標データ量は、ネットワーク機器が実際のネットワーク状況に基づいて決定したものであるので、ネットワーク機器により決定された目標データ量を有する第１バッファリングデータは、実際のネットワーク状況とマッチングすることが可能になり、さらにバッファリングデータ量が一定であることによるカクカク現象を低減させ、再生の滑らかさを向上させることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施例のデータバッファリング方法を実現する手順の模式図である。
【図２】本発明の実施例のデータバッファリング方法の適用シナリオの模式図である。
【図３】本発明の実施例のデータバッファリング方法の手順の模式図である。
【図４】本発明の実施例のデータバッファリング方法を実現する手順の模式図である。
【図５】本発明の実施例のデータバッファリング方法の適用中の枠組みの模式図である。
【図６】本発明の実施例のデータバッファリング方法におけるネットワーク機器と端末機器とのやり取り図である。
【図７】本発明の実施例のネットワーク機器の機能構成の模式図である。
【図８】本発明の実施例のネットワーク機器のハードウェア構成の模式図である。
【発明を実施するための形態】
【００１４】
図面及び実施例を参照しながら、本発明をさらに詳しく説明する。理解すべきものとして、ここで説明される具体的な実施例は、本発明を解釈するためのものにすぎず、本発明を限定するものではない。
【００１５】
実際の適用では、関連技術において、ＣＤＮノードが、バッファ領域にバッファリングされている配信者の音声／映像データを該ユーザに１回で全部送信するので、次のような問題がある。
【００１６】
第一に、ネットワーク輻輳の場合、ライブ配信される音声／映像のデータ量が大きい。ある一部の高ビットレートの音声／映像データの上り伝送に２メガバイト毎秒（Ｍｂｐｓ：Ｍｅｇａｂｙｔｅｓ  Ｐｅｒ  Ｓｅｃｏｎｄ）の帯域幅さえ要求される。あるユーザに対して５秒のバッファリング時間が設定される場合、対応するデータ量が１０Ｍである。これは、該ユーザがＣＤＮノードにアクセスすると、１０Ｍのデータが送信されることに相当する。このため、ネットワークのアクセス条件が悪いことで、上り／下り速度ジッタや頻繁な回線落ちなど、ネットワークが不安定な状況が引き起こされるユーザにとっては、ネットワーク輻輳や伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）ゼロウィンドウ現象が発生しやすい。
【００１７】
第二に、高ビットレートのライブ配信のシナリオでは、バッファ容量を一定にすれば、端末のスペックが悪いユーザにとっては、ＣＤＮノードにアクセスして送信された固定サイズのバッファリングデータが、端末で設定されたバッファ容量を超える場合、コマ落ちが発生することで、画面が黒点滅する現象を引き起こす。
【００１８】
第三に、バッファ容量を一定にしたので、ライブ配信の視聴中において、配信者側にカクカク・再接続の問題が発生する場合、カクカクに耐える能力を低下させる。ここで、端末のカクカクに耐える最大能力は、該端末に対して設定されるバッファリング周期である。
【００１９】
そこで、上記の問題を解決するために、本発明の実施例は、ユーザのネットワーク環境及び端末のスペック（能力）に応じて、ＣＤＮノードの音声／映像のバッファリングデータを動的に調整することができ、さらにカクカクの回数を低減させるための基礎を定めるとともに、ライブ配信の視聴体験を向上させるための基礎も定めるデータバッファリング方法及びネットワーク機器を提供している。
【００２０】
図１は、本発明の実施例のデータバッファリング方法を実現する手順の模式図である。該方法は、ネットワーク機器、例えば、ＣＤＮノードに適用可能である。図１に示すように、本発明の実施例のデータバッファリング方法は、以下のステップを含む。
【００２１】
ステップ１０１で、ネットワーク機器は、マルチメディアデータと、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得する。
【００２２】
前記通信ネットワークは、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む。
【００２３】
本実施例では、前記マルチメディアデータは、音声データ及び／又は映像データであってもよい。
【００２４】
ここで、前記第１通信ネットワークは、送信側の端末とネットワーク機器との間の通信ネットワークであってもよい。
【００２５】
例えば、ライブ配信シナリオでは、前記第１通信ネットワークは、配信者の機器とＣＤＮノードとの間の通信ネットワークであってもよく、或いは、前記第１通信ネットワークは、ネットワーク機器（例えば、ＣＤＮノード）とオリジンとの間の通信ネットワークであってもよい。前記オリジンは、ライブ配信の配信者によりアップロードされたオリジナルの音声／映像データを記憶するサーバである。
【００２６】
実際の適用では、前記第１通信ネットワークは、ネットワーク機器によるマルチメディアデータの取得に係る通信ネットワークであってもよい。これに応じて、前記第２通信ネットワークは、ネットワーク機器と、ライブ配信されたマルチメディアデータを受信する受信側の端末（即ち、本実施例における端末機器）との間の通信ネットワーク、例えば、ＣＤＮノードと、ライブ配信を視聴するユーザ機器との間の通信ネットワークである。
【００２７】
図２は、本発明の実施例のデータバッファリング方法の適用シナリオの模式図である。図２に示すように、本実施例は、ライブ配信シナリオに適用可能である。ライブ配信シナリオでは、ＣＤＮノードは、方式１及び方式２の２つの方式によって、配信者の端末の音声／映像データを取得してもよい。
【００２８】
例えば、方式１で、ＣＤＮノードは、第１通信ネットワークを介して、配信者の端末から、配信者の端末によりリアルタイムに採取された音声／映像データ（即ち、ライブ配信データ）を直接に取得し、さらに、取得された音声／映像データを、第２通信ネットワークを介して、受信側の端末に伝送することにより、ライブ配信視聴手順を実現してもよい。
【００２９】
また、例えば、方式２で、ＣＤＮノードは、第１通信ネットワークを介して、オリジンから、該配信者の端末に対応する音声／映像データ（即ち、ライブ配信データ）を取得し、さらに、取得された音声／映像データを、第２通信ネットワークを介して、受信側の端末に伝送する。ここで、ＣＤＮノードがオリジンから音声／映像データを取得する前に、配信者の端末は、自局によりリアルタイムに採取された音声／映像データをオリジンにアップロードして記憶させる（配信者の端末とオリジンとの接続関係は図２に示されていない）。このように、ライブ配信視聴手順を実現する。もちろん、実際の適用では、実際の状況に応じて、例えば、ネットワーク輻輳状態に応じて、ＣＤＮノードによる音声／映像データの取得の経路を決定してもよい。
【００３０】
実際の適用では、前記ネットワーク特徴情報は、遅延、帯域幅、遅延変化（即ち、ジッタ）、トラフィックなどのうち少なくとも１つを含むが、これらに限定されない。ここで、前記ネットワーク特徴情報によって、ネットワーク性能を評価することができ、例えば、ネットワーク特徴情報を用いて、ネットワーク輻輳であるか否かなどを決定することができる。
【００３１】
ステップ１０２で、前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定する。
【００３２】
一実施例では、前記ネットワーク機器は、目標データ量を決定する際に、端末機器のバッファ状況を参照してもよい。これにより、決定される目標データ量と端末機器（例えば、端末機器に対応する実際のネットワーク環境や、端末機器の実際のバッファ容量など）とのマッチング度をさらに向上させる。一実施例では、前記ネットワーク機器は、前記端末機器のバッファ容量を取得し、さらに、少なくとも前記バッファ容量と、前記通信ネットワークに含まれる第１通信ネットワーク及び／又は第２通信ネットワークのネットワーク特徴情報とに基づいて、前記端末機器に対応する目標データ量を決定する。例えば、再生パラメータの重み、及び、前記端末機器のバッファ容量の重みを設定して、再生パラメータ及び前記バッファ容量を重み付け処理し、重み付け処理された再生パラメータ及びバッファ容量に基づいて、端末機器とマッチングする所定データ量を決定してもよい。実際の適用では、前記バッファ容量のタイプは、バッファのオリジナル容量及び残り容量のうち少なくとも１つを含む。
【００３３】
一実施例では、前記目標データ量は、所定画像ユニットの数量で表される。例えば、前記目標データ量は、ＧＯＰ（Ｇｒｏｕｐ  ｏｆ  Ｐｉｃｔｕｒｅ）の数量で表される。この場合、ステップ１０２における前記端末機器に対応する目標データ量を決定することは、前記ネットワーク機器が、バッファリングを必要とする前記端末機器に対応する所定画像ユニットの第１数量を決定し、前記第１数量の所定画像ユニットの総データ量を、前記端末機器に対応する目標データ量とする、ことを含んでもよい。
【００３４】
ここで、前記ＧＯＰは、固定モードの一連のＩフレーム、Ｐフレーム、Ｂフレームによって構成される。ここで、前記Ｉフレームは、キーフレームを表すイントラフレームである。これは、Ｉフレームの画像が完全であり、復号時に自フレームのデータだけで済むと理解されてもよい。前記Ｐフレームは、前方向予測符号化フレームであり、このフレームと前のキーフレーム又は前のＰフレームとの差分を表し、復号時に、その前にバッファリングされた画像に、自フレームで定義された差分を重ね合わせて、最終的な画像を生成する必要がある。前記Ｂフレームは、双方向予測補間符号化フレームであり、双方向差分フレームを表す。つまり、Ｂフレームは、自フレームと前後のフレームとの差分を記録し、圧縮率が高い。Ｐフレーム、Ｂフレームの復号には、Ｉフレームの復号よりも多いハードウェアリソース、例えば中央処理装置（ＣＰＵ）が消費される。
【００３５】
一実施例では、リアルタイム性の要求について映像遅延が遅延閾値（即ち、感知可能な著しい遅延の時間、例えば１０秒）より大きいことを受け入れられるユーザにとって、前記目標データ量は、少なくとも１つのＧＯＰに設定してもよい。ＧＯＰの数量は、ユーザのネットワーク状況に応じて、リアルタイムで動的に調整してもよい。もちろん、ネットワーク機器は、目標データ量を設定しなくてもよく、即ちバッファリングしなくてもよい。例えば、
シナリオ１で、配信者の端末の映像遅延のジッタがジッタ閾値より小さくて、即ち、上りが安定であって、視聴ユーザ（即ち、受信側の端末）のネットワーク環境が輻輳である場合、該目標データ量は、最も新しい１つのＧＯＰのデータ量であり、つまり、第１バッファリングデータは、最も新しい１つのＧＯＰである。
【００３６】
シナリオ２で、配信者の端末の上りが安定であって、視聴ユーザのネットワーク環境が正常である場合、該目標データ量は、ゼロであり、或いは、多くとも最も新しい１つのＧＯＰのデータ量であり、つまり、第１バッファリングデータは、保存されなく、或いは、多くとも最も新しい１つのＧＯＰがバッファリングされる。
【００３７】
シナリオ３で、配信者の端末の映像遅延のジッタがジッタ閾値より大きくて、即ち、上りが不安定であって、視聴ユーザのネットワーク環境が輻輳である場合、該目標データ量は、最も新しい２つ以上のＧＯＰに対応するデータ量であり、つまり、第１バッファリングデータは、最も新しい２つ以上のＧＯＰである。
【００３８】
シナリオ４で、配信者の端末の上りが不安定であって、視聴ユーザのネットワーク環境が正常である場合、該目標データ量は、最も新しい３つ以上のＧＯＰに対応するデータ量であり、つまり、第１バッファリングデータは、最も新しい３つ以上のＧＯＰである。
【００３９】
ここで、注意すべきものとして、上記に示されたシナリオは、例示的なものにすぎず、ＧＯＰの数量は、実際の状況に応じて調整してもよい。実際の適用では、ライブ配信のユーザの視聴遅延が長すぎることを回避するために、前記目標データ量は、上限があり、即ち、大きくとも所定数のＧＯＰのデータ量を超えてはいけない。さもないと、ライブ配信のユーザの視聴遅延を増加させることになる。
【００４０】
ステップ１０３で、取得されたマルチメディアデータに基づいて、マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定する。
【００４１】
ステップ１０４で、前記第２通信ネットワークを介して、前記第１バッファリングデータを前記端末機器に送信する。
【００４２】
前記第１バッファリングデータのデータ量は、ネットワーク特徴情報とマッチングする。
【００４３】
例えば、図３は、本発明の実施例のデータバッファリング方法の手順の模式図である。図３に示すように、該方法は、
ネットワーク機器がマルチメディアデータを取得するステップ３０１と、
ネットワーク機器が、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報を取得するステップ３０２と、
ネットワーク機器が、ネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定するステップ３０３と、
ネットワーク機器が、マルチメディアデータの、前記目標データ量を有する第１バッファリングデータを決定するステップ３０４と、
ネットワーク機器が第１バッファリングデータを端末機器に送信するステップ３０５と、
第１バッファリングデータに対応するマルチメディアデータを再生するステップ３０６と、を含む。
【００４４】
前記ネットワーク機器は、目標データ量を決定し、該目標データ量を有する第１バッファリングデータを決定した後に、第２通信ネットワークを用いて、前記第１バッファリングデータを前記端末機器に送信してもよい。これにより、前記端末機器は、前記第１バッファリングデータに対応するマルチメディアデータを再生することができる。ここで、目標データ量が実際のネットワーク状況に応じて決定されたので、端末機器で受信された第１バッファリングデータのデータ量は、実際のネットワーク状況とマッチングすることが可能である。このように、バッファリングデータ量が一定であることでカクカク現象を引き起こすリスクを低減させ、さらにユーザ体験を向上させるための基礎を定める。
【００４５】
実際の適用では、ユーザのネットワーク環境が輻輳であり、或いは、ＣＤＮノードからオリジンへアクセスするためのネットワークが輻輳である場合、バッファリングデータ量（即ち、目標データ量）の大きさに応じて、バッファリング履歴データを淘汰して、最も新しいＧＯＰデータをバッファリングしてもよい。これにより、滑らかなライブ配信を確保する。一実施例では、前記ネットワーク機器は、前記通信ネットワークに含まれる第１通信ネットワーク及び／又は第２通信ネットワークのネットワーク特徴情報に基づいて、前記第１バッファリングデータに対してフレームドロップ処理を行う必要があるか否かを決定し、前記第１バッファリングデータに対してフレームドロップ処理を行う必要がある場合、音声フレーム及び／又は映像フレームのフレームタイプの優先順位を取得し、フレームタイプの優先順位にしたがって、前記第１バッファリングデータにおける音声フレーム及び／又は映像フレームに対してフレームドロップ処理を行うことにより、前記第１バッファリングデータのデータ量を減少し、第１バッファリングデータに最も新しいＧＯＰデータを追加することを便利にする。例えば、映像フレームを優先してドロップしてから、音声フレームをドロップする。ここで、映像フレームのうち、Ｂフレームを優先してドロップする。Ｂフレームは、双方向予測符号化フレームであり、圧縮率が高く、符号化・復号で消費されるＣＰＵ遅延が大きい。Ｐフレームを二番目に優先してドロップし、最後にＩフレームをドロップする。
【００４６】
本実施例では、注意すべきものとして、本実施例における方法によって決定された、目標データ量を有する第１バッファリングデータは、ユーザの端末機器が前記ネットワーク機器にアクセスした後、即ち、前記ネットワーク機器及び前記端末機器が前記第２通信ネットワークを確立完了した後、前記第２通信ネットワークを用いて前記端末機器に送信されたものであってもよい。例えば、一実施例では、前記ネットワーク機器は、前記端末機器に対応する第１バッファリングデータを決定して、前記第２通信ネットワークのネットワーク確立成功情報を検出した後、前記第２通信ネットワークを用いて、前記第１バッファリングデータを前記端末機器に送信する。この場合、前記目標データ量の決定は、端末機器に対応する、マルチメディアデータを再生するための再生パラメータを参照してもよい。ここでの再生パラメータは、端末機器によるマルチメディアデータの再生の再生性能を表すものであり、例えば、端末機器の許容可能な最大遅延又は許容可能なカクカクの程度である。端末機器の許容可能な最大遅延又は許容可能なカクカクの程度をさらに参照して、最終的に目標データ量を決定する。さらに、端末機器がネットワーク機器にアクセスした後、ネットワーク機器は、まず端末機器に第１バッファリングデータを送信してもよい。ここで、前記第１バッファリングデータは、端末のスペックに基づいて生成されたものであるので、第１バッファリングデータによって、視聴ユーザのプレーヤが一定のバッファを有するようにすることができる。例えば、端末機器がネットワーク機器にアクセスすると、前記ネットワーク機器は、設定された第１バッファリングデータを１回で該端末機器に送信することができる。このように、ユーザの視聴中の例えばネットワークジッタ、配信者の上り音声／映像データの不安定、ＣＤＮノードのバックツーオリジン用のネットワーク（即ち、ＣＤＮノードとオリジンとの間のネットワーク）などの異常によるユーザの視聴中のライブ配信のカクカクを減少させることができる。実際の適用では、目標データ量は、大きければ大きいほど良いわけではなく、大きすぎると、ユーザのライブ配信の視聴遅延を増加させることになる。
【００４７】
或いは、目標データ量を有する第１バッファリングデータは、第２通信ネットワークの確立完了後に、前記ネットワーク機器が前記第２通信ネットワークを用いて前記端末機器に送信したものであってもよい。例えば、ライブ配信を例として、前記第１バッファリングデータは、ユーザの端末機器がネットワーク機器にアクセスした直後に、前記ネットワーク機器から端末機器へ送信されたものであってもよく、或いは、ライブ配信中に前記ネットワーク機器から端末機器へ送信されたものであってもよい。
【００４８】
一実施例では、前記第１バッファリングのデータ量は、実際のネットワーク状況に応じて決定されたものであるので、前記第１バッファリングは、ライブ配信の確立の最初に端末機器に送信されたものであっても、ライブ配信中に端末機器に送信されたものであっても、ネットワーク輻輳によるカクカク問題を回避することができる。また、ネットワーク輻輳である場合、本実施例における方法によれば、データ量の小さい第１バッファリングデータを決定することができる。このように、ネットワークにさらに大きな負担をもたらすことが回避される。
【００４９】
このように、本発明の実施例における方法では、端末機器に対応する目標データ量は、ネットワーク機器が実際のネットワーク状況に応じて決定したものであるので、ネットワーク機器により決定された、目標データ量を有する第１バッファリングデータは、実際のネットワーク状況とマッチングすることが可能である。このため、本発明の実施例によれば、バッファリングデータ量が一定であることでカクカク現象を引き起こすリスクを低減させ、カクカクに耐える能力を向上させ、さらにユーザ体験を向上させるための基礎を定める。
【００５０】
一実施例では、２段階バッファリング方法によって、バッファリングデータ量が一定であることによるカクカク現象を解決してもよい。図４は、本発明の実施例のデータバッファリング方法を実現する手順の模式図である。図４に示すように、該方法は、以下のステップを含む。
【００５１】
ステップ４０１で、ネットワーク機器は、マルチメディアデータと、端末機器に対応する、マルチメディアデータを再生するための再生パラメータとを取得する。
【００５２】
一実施例では、再生パラメータは、端末機器の許容可能な最大遅延又は許容可能なカクカクの程度であってもよい。
【００５３】
ステップ４０２で、ネットワーク機器は、前記再生パラメータに基づいて、端末機器に対応する所定データ量を決定し、取得された前記マルチメディアデータに基づいて、マルチメディアデータの第２バッファリングデータを決定する。
【００５４】
第２バッファリングデータは、前記所定データ量を有する。
【００５５】
ステップ４０３で、ネットワーク機器は、端末機器と第２通信ネットワークを確立する。
【００５６】
第２通信ネットワークの確立に成功した後、端末機器は、ネットワーク機器に第２バッファリングデータの送信を指示する目標指示を生成する。
【００５７】
ステップ４０４で、ネットワーク機器は、目標指示を検出すると、第２バッファリングデータを端末機器に送信する。
【００５８】
前記端末機器で取得された第２バッファリングデータのデータ量は、再生パラメータとマッチングする。
【００５９】
ステップ４０５で、端末機器は、第２バッファリングデータに対応するマルチメディアデータを再生する。
【００６０】
本発明の実施例では、前記目標指示は、少なくとも、前記端末機器及び前記ネットワーク機器による前記第２通信ネットワークの確立のネットワーク確立成功情報に基づいて生成されたものである。つまり、前記目標指示は、少なくとも、端末機器が端末機器からネットワーク機器へのアクセスのアクセス成功情報に基づいて生成したものである。このように、端末機器がネットワーク機器にアクセスした後、ネットワーク機器は、まず端末機器に第１段階のバッファリングデータ、即ち、第２バッファリングデータを送信することができる。ここで、前記第２バッファリングデータは、端末のスペックに応じて生成されたものであるので、第１段階のバッファリングデータによって、視聴ユーザのプレーヤが一定のバッファを有するようにすることができる。例えば、端末機器がネットワーク機器にアクセスすると、前記ネットワーク機器は、設定された第２バッファリングデータを１回で該端末機器に送信することができる。このように、ユーザの視聴中の例えばネットワークジッタ、配信者の上り音声／映像データの不安定、ＣＤＮノードのバックツーオリジン用のネットワーク（即ち、ＣＤＮノードとオリジンとの間のネットワーク）などの異常によるユーザの視聴中のライブ配信のカクカクを減少させることができる。ここで、所定データ量も、大きければ大きいほど良いわけではなく、大きすぎると、ユーザのライブ配信の視聴遅延を増加させることになる。
【００６１】
本実施例では、前記所定データ量も、所定画像ユニットの数量で表されてもよい。例えば、前記所定データ量は、少なくとも１つのＧＯＰに設定してもよい。ＧＯＰの数量は、ユーザのネットワーク状況に応じて、リアルタイムで動的に調整してもよい。
【００６２】
一実施例では、前記ネットワーク機器は、端末機器に、第１段階のバッファリングデータ（即ち、第２バッファリングデータ）を送信した後、ネットワークの実際状況に応じて第２段階のバッファリングデータも送信する。
【００６３】
ステップ４０６で、ネットワーク機器は、マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報を取得する。
【００６４】
ステップ４０７で、ネットワーク機器は、通信ネットワークのネットワーク特徴情報に基づいて、端末機器に対応する目標データ量と、マルチメディアデータの、目標データ量を有する第１バッファリングデータとを決定する。
【００６５】
ステップ４０８で、ネットワーク機器は第１バッファリングデータを端末機器に送信する。
【００６６】
ステップ４０９で、端末機器は、第１バッファリングデータに対応するマルチメディアデータを再生する。
【００６７】
つまり、前記第１バッファリングデータは、第２段階のバッファリングデータである。ここで、第２段階のバッファリングデータは、ライブ配信中にネットワークの実際状況に応じて決定されたものであるので、本実施例では、２段階バッファリングの方式によって、ライブ配信がカクカクするリスクを最大限に低減させることができる。
【００６８】
ここで、目標データ量及び第１バッファリングデータを決定する手順は、前述した実施例における方式によってもよい。
【００６９】
ネットワーク機器は、第１段階のバッファリングデータを決定する際に、端末機器のバッファ容量を参照してもよい。一実施例では、前記端末機器は、前記端末機器のバッファ容量を取得し、さらに、前記再生パラメータ及び前記バッファ容量に基づいて、前記端末機器にマッチングする所定データ量を決定する。このように、端末のスペックが悪くてバッファリングデータ量が大きいことによる黒点滅現象を回避するための基礎を定め、さらにユーザのライブ配信の視聴体験を向上させるための基礎を定める。
【００７０】
もちろん、実際の適用では、前記所定データ量は、前記通信ネットワークに含まれる第１通信ネットワーク及び／又は第２通信ネットワークのネットワーク特徴情報に基づいて決定されてもよい。決定手順は、前述した目標データ量の決定手順を参照してもよい。
【００７１】
以下、適用シナリオを参照して、本発明の実施例を詳しく説明する。図５に示すように、ライブ配信端末機器（例えば、デスクトップコンピュータやスマートフォンなどのようなカメラ付き端末）は、音声／映像データに対して採取、量子化、符号化、カプセル化を行ったものを、リアルタイムメッセージングプロトコル（ＲＴＭＰ：Ｒｅａｌ  Ｔｉｍｅ  Ｍｅｓｓａｇｉｎｇ  Ｐｒｏｔｏｃｏｌ）を介して、ライブ配信プラットフォームのアップロード（ｕｐｌｏａｄ）アクセスモジュールにアップロードする。ｕｐｌｏａｄアクセスモジュールは、ユーザによりアップロードされたものに付けられた認証情報パラメータに基づいて、認証センターによって、該ライブ配信端末機器がライブ配信権限を有するか否かを認証し、該ライブ配信端末機器がライブ配信権限を有する場合、該ライブ配信端末機器に対応する音声／映像データをトランスコードモジュールに伝送する。トランスコードモジュールは、下りのユーザ（例えば、受信側の端末）により視聴される音声／映像のフォーマットに応じてトランスコードを行い、トランスコードされた音声／映像データを各ＣＤＮクラスタに配信する。実際の適用では、前記ＣＤＮクラスタは、少なくとも２つのＣＤＮノードを含む。ここで、下りのユーザのサポート可能な音声／映像のフォーマットがＲＴＭＰ／ＦＬＶ（Ｆｌａｓｈ  Ｖｉｄｅｏ）である場合、トランスコードモジュールは、直接に音声／映像データを配信モジュールによってＣＤＮクラスタに送信し、ＣＤＮクラスタの特定のＣＤＮノード（例えば、下りのユーザに最も近いＣＤＮノード）を介して、音声／映像データを下りのユーザに配信する。下りのユーザのサポート可能な音声／映像のフォーマットがＨＬＳ（ＨｙｐｅｒＴｅｘｔ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ  Ｌｉｖｅ  Ｓｔｒｅａｍｉｎｇ）である場合、トランスコードモジュールは、レコーディング、画面キャプチャ、スライスによって、音声／映像データを分散ファイルシステムに送信し、分散ファイルシステムを介して、音声／映像データをＣＤＮクラスタに送信し、さらにＣＤＮクラスタの特定のＣＤＮノード（例えば、下りのユーザに最も近いＣＤＮノード）を介して、音声／映像データを下りのユーザに配信する。ここで、下りのユーザのサポート可能な音声／映像のフォーマットがＨＬＳである限り、トランスコードモジュールは、音声／映像データをスライス処理し、さらにスライス処理された音声／映像データを分散ファイルシステムに送信する。レコーディングや画面キャプチャ処理を行う必要があるか否かは、ユーザ要求に応じて決定してもよい。一実施例では、前記ライブ配信プラットフォームには、違法コンテンツ監視モジュールがさらに設けられている（図５に示されていない）。この違法コンテンツ監視モジュールによって、分散ファイルシステムにおけるキャプチャ画面に対して違法コンテンツ鑑定を行うことができる。違法映像である場合、リアルタイムに認証センターに対し、配信者のライブ配信を禁止するとともに、ユーザの視聴を禁止するよう通知する。同様に、認証センターによってライブ配信のユーザを認証すると同時に、ライブ配信のユーザによりアップロードされた音声／映像データに対して違法��ンテンツ鑑定を行ってもよい。このように、違法映像の伝播を回避する。最後に、下りのユーザは、自身の要求に応じて音声／映像のフォーマットを選択し、ＣＤＮクラスタにおける近くのＣＤＮノードにアクセスして、ライブ配信を視聴する。
【００７２】
図６には、図５の枠組みを基に本発明の実施例における方法を実現する例が示されている。一実施例では、視聴ユーザは、ＣＤＮクラスタにおける近くのＣＤＮノードにアクセスする。該ＣＤＮノードは、視聴ユーザ（即ち、下りのユーザ）のスペック要求（例えば、アプリケーションプログラムＡＰＰのスペック要求）に応じて、最初のフレームで送信するバッファリングデータ量（即ち、第１段階のバッファリングデータ量であり、少なくとも１つのＧＯＰを含むべきである）を決定する。視聴ユーザが該ＣＤＮノードにアクセスした後、ＣＤＮノードは、第１段階のバッファリングデータ量を有するように設定された最初のフレームのバッファリングデータ（即ち、第１段階のバッファリングデータ）を１回で視聴ユーザに送信する。ここで、最初のフレームのバッファリングデータは、主にユーザのプレーヤにバッファリングされる。バッファリングされたデータを用いて再生し、さらに、例えばネットワークジッタ、配信者の上り音声／映像データの不安定、ＣＤＮノードのバックツーオリジン用のネットワークの異常などによるユーザの視聴中のライブ配信のカクカクを回避することができる。
【００７３】
実際の適用では、最初のフレームのバッファ（最初のフレームのバッファリングデータの記憶に用いられる）の容量は、端末に設定されたバッファ容量及びネットワーク特徴情報（例えば、帯域幅、遅延やジッタ）に基づいて、総合的に決定される。例えば、対応する重みを設定するような方式によって、最初のフレームのバッファの容量を決定する。ここで、バッファ容量の重みは、再生の滑らかさの制御に用いられ、ネットワーク特徴情報の重みは、遅延の制御に用いられる。これにより、重みは、遅延時間と再生の滑らかさとのバランスがとれ、単純に大きなバッファ容量を設定することでユーザのライブ配信の視聴遅延が大きいことを克服することができる。
【００７４】
一実施例では、ＣＤＮノードは、視聴ユーザに第２段階のバッファリングデータを送信する。ここで、前記第２段階のバッファリングデータのデータ量、即ち、第２段階のバッファリングデータ量は、動的なバッファリングデータ量である。実際の適用では、視聴ユーザは、映像遅延が遅延閾値（即ち、感知可能な著しい遅延の時間、例えば１０秒）より大きいことを受け入れられる場合、ＣＤＮノードは、第２段階のバッファリングデータ量を設定してもよく、例えば、少なくとも１つのＧＯＰを含むように設定する。ＧＯＰの数量は、ユーザのネットワーク状況に応じて、リアルタイムで動的に調整してもよく、例えば、上りが安定であるか否かに応じて動的に調整してもよい。以下で、例示的に説明する。
【００７５】
Ａ． 配信者の上りが安定であって、視聴ユーザのネットワーク環境が輻輳である場合、第２段階のバッファリングデータは、最も新しい１つのＧＯＰである。
【００７６】
Ｂ． 配信者の上りが安定であって、視聴ユーザのネットワーク環境が正常である場合、第２段階のバッファリングデータは、ゼロ又は多くとも１つの最も新しいＧＯＰである。
【００７７】
Ｃ． 配信者の上りが不安定であって、視聴ユーザのネットワーク環境が輻輳である場合、第２段階のバッファリングデータは、最も新しい２つ以上のＧＯＰである。
【００７８】
Ｄ． 配信者の上りが不安定であって、視聴ユーザのネットワーク環境が正常である場合、第２段階のバッファリングデータは、最も新しい３つ以上のＧＯＰである。
【００７９】
一実施例では、ネットワーク輻輳である場合、バッファリングデータにおける映像フレーム及び／又は音声フレームを淘汰してもよい。
【００８０】
例を挙げて説明すると、下りのユーザのネットワーク環境、又はＣＤＮからオリジンへアクセスするためのバックツーオリジン用のネットワークが輻輳である場合、このシナリオでは、バッファリングデータ量の大きさに応じて古いバッファリングデータを淘汰し、最も新しいＧＯＰデータをバッファリングしてもよい。これにより、カクカクを低減させるための基礎を定める。例えば、映像フレームを優先してドロップしてから、音声フレームをドロップしてもよい。一実施例では、映像フレームのうち、Ｂフレームを優先してドロップしてもよい。ここで、Ｂフレームは、双方向予測符号化フレームであり、圧縮率が高く、符号化・復号で消費されるＣＰＵ遅延が大きい。Ｐフレームを二番目に優先してドロップし、最後にＩフレームをドロップする。
【００８１】
このように、本実施例によれば、バッファリングデータ量が一定であることでカクカク現象を引き起こすリスクを低減させ、ユーザ体験を向上させるための基礎を定める。
【００８２】
また、本実施例は、ネットワーク機器を提供している。図７に示すように、前記ネットワーク機器は、
マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得するように構成される取得手段７１と、
少なくとも前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定するように構成される処理手段７２と、
取得された前記マルチメディアデータに基づいて、マルチメディアデータの、前記目標データ量を有する第１バッファリングデータを決定するように構成されるバッファリング手段７３と、
前記第２通信ネットワークを介して前記第１バッファリングデータを前記端末機器に送信し、前記端末機器で取得された第１バッファリングデータのデータ量をネットワーク特徴情報とマッチングさせるように構成される送信手段７４と、を備える。
【００８３】
一実施例では、前記取得手段７１は、さらに、前記端末機器に対応する、前記マルチメディアデータを再生するための再生パラメータを取得するように構成され、
前記処理手段７２は、さらに、少なくとも前記再生パラメータに基づいて、前記端末機器に対応する所定データ量を決定するように構成され、
前記バッファリング手段７３は、さらに、取得された前記マルチメディアデータに基づいて、前記マルチメディアデータの、前記所定データ量を有する第２バッファリングデータを決定するように構成され、
前記送信手段７４は、さらに、目標指示を検出すると、前記目標指示にしたがって前記第２バッファリングデータを前記端末機器に送信し、前記端末機器で取得された第２バッファリングデータのデータ量を再生パラメータとマッチングさせるように構成され、前記目標指示は、少なくとも、前記端末機器及び前記ネットワーク機器による前記第２通信ネットワークの確立のネットワーク確立成功情報に基づいて生成されたものである。
【００８４】
一実施例では、前記取得手段７１は、さらに、前記端末機器のバッファ容量を取得するように構成され、これに応じて、
前記処理手段７２は、さらに、前記再生パラメータ及び前記バッファ容量に基づいて、前記端末機器とマッチングする所定データ量を決定するように構成される。
【００８５】
一実施例では、前記取得手段７１は、さらに、前記端末機器のバッファ容量を取得するように構成され、
これに応じて、前記処理手段７２は、さらに、少なくとも、前記バッファ容量と、前記通信ネットワークに含まれる第１通信ネットワーク及び／又は第２通信ネットワークのネットワーク特徴情報とに基づいて、前記端末機器に対応する目標データ量を決定するように構成される。
【００８６】
一実施例では、前記目標データ量は、所定画像ユニットの数量で表され、これに応じて、
前記処理手段７２は、さらに、バッファリングを必要とする前記端末機器に対応する所定画像ユニットの第１数量を決定し、前記第１数量の所定画像ユニットの総データ量を、前記端末機器に対応する目標データ量とするように構成される。
【００８７】
他の実施例では、前記処理手段７２は、さらに、前記通信ネットワークに含まれる第１通信ネットワーク及び／又は第２通信ネットワークのネットワーク特徴情報に基づいて、前記第１バッファリングデータに対してフレームドロップ処理を行うか否かを決定し、前記第１バッファリングデータに対してフレームドロップ処理を行うと決定した場合、音声フレーム及び／又は映像フレームのフレームタイプの優先順位を取得し、フレームタイプの優先順位にしたがって、前記第１バッファリングデータにおける音声フレーム及び／又は映像フレームに対してフレームドロップ処理を行うことにより、前記第１バッファリングデータのデータ量を減少するように構成される。
【００８８】
本発明の実施例は、もう１つのネットワーク機器を提供している。前記ネットワーク機器は、プロセッサと、プロセッサで実行可能なコンピュータプログラムを記憶するように構成されるメモリと、を備える。
【００８９】
ここで、前記プロセッサは、前記コンピュータプログラムが実行されると、
マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得し、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定し、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定し、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信する、ことを実行するように構成される。
【００９０】
また、本発明の各実施例における各機能ユニットをすべて１つの処理ユニットに組み入れてもよいし、各ユニットそれぞれを個別に１つのユニットとしてもよいし、２つ以上のユニットを１つのユニットに組み入れてもよい。上述した組み入れたユニットは、ハードウェアの形で実現されてもよいし、ソフトウェアの形で実現されてもよい。
【００９１】
以上に説明した機器は、模式的なものにすぎない。例えば、前記ユニットの分割は、論理的な機能の分割にすぎず、実際に実現する際に別の分割方式であってもよい。例えば、複数のユニットまたはコンポーネントを組み合わせたり、他のシステムに組み入れたりしてもよいし、一部の構成を無視したり、実行しなかったりしてもよい。また、示されまたは説明された各構成部分の互いの結合、または直接結合、または通信接続は、若干のインターフェースを介するものであってもよく、機器またはユニットの間接結合または通信接続は、電気的、機械的、または他の形式であってもよい。
【００９２】
上記に分離した部品として説明されたユニットは、物理的に分離したものであってもなくてもよい。ユニットとして示された部品は、物理的なユニットであってもなくてもよく、即ち、１つの場所に位置してもよいし、ネットワーク上の複数のユニットに分散してもよい。実際の必要に応じて、その中の一部又は全部のユニットを選択して、本実施例に係る発明の目的を達成してもよい。
【００９３】
また、本実施例は、上記ネットワーク機器のハードウェア構成を提供している。図８に示すように、前記ネットワーク機器は、送信器８１と、受信器８２と、記憶媒体８３と、プロセッサ８４と、を備える。前記プロセッサ８４は、マイクロプロセッサ、中央処理装置、デジタル信号プロセッサやプログラマブルロジックアレイなどの、処理機能を有する電子部品であってもよい。記憶媒体８３は、モバイルストレージデバイス、ランダムアクセスメモリ（ＲＡＭ：Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）、読み出し専用メモリ（ＲＯＭ：Ｒｅａｄ−Ｏｎｌｙ  Ｍｅｍｏｒｙ）、磁気ディスクや光ディスクなどの、プログラムコードを記憶可能な各種の媒体を含む。前記記憶媒体８３には、上記のデータバッファリング方法を実行するためのコンピュータ実行可能コードが記憶される。
【００９４】
これに応じて、本発明の実施例は、コンピュータ命令が記憶された記憶媒体も提供している。該命令は、プロセッサで実行されると、
マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得し、
前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定し、
取得された前記マルチメディアデータに基づいて、前記マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定し、
前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信する、ことを実現させる。
【００９５】
上記は本発明の具体的な実施形態にすぎないが、本発明の保護範囲はこれに限定されない。本発明に掲示された技術範囲内で当業者が容易に想到し得たいかなる変更又は置換えも、本発明の保護範囲内に含まれるべきである。それゆえ、本発明の保護範囲は、記載された特許請求の範囲に従うべきである。
【産業上の利用可能性】
【００９６】
本発明の実施例では、ネットワーク機器が、マルチメディアデータと、前記マルチメディアデータをネットワーク機器に伝送するための第１通信ネットワーク、前記マルチメディアデータを端末機器に伝送するための第２通信ネットワークのうち１つを含む、前記マルチメディアデータを伝送するための通信ネットワークのネットワーク特徴情報とを取得し、少なくとも前記通信ネットワークのネットワーク特徴情報に基づいて、前記端末機器に対応する目標データ量を決定し、取得された前記マルチメディアデータに基づいて、前記マルチメディアデータを表す前記目標データ量を有する第１バッファリングデータを決定し、前記第２通信ネットワークを介して、データ量が前記ネットワーク特徴情報とマッチングする前記第１バッファリングデータを前記端末機器に送信する。このように、バッファリングデータ量が一定であることでカクカク現象を引き起こすリスクを低減させ、カクカクに耐える能力を向上させ、さらにユーザ体験を向上させるための基礎を定める。
【符号の説明】
【００９７】
７１  取得手段
７２  処理手段
７３  バッファリング手段
７４  送信手段
８１  送信器
８２  受信器
８３  記憶媒体
８４  プロセッサ
【図１】
0006876131.tif 000002
【図２】
0006876131.tif 000003
【図３】
0006876131.tif 000004
【図４】
0006876131.tif 000005
【図５】
0006876131.tif 000006
【図６】
0006876131.tif 000007
【図７】
0006876131.tif 000008
【図８】
0006876131.tif 000009