特許 6563424 ストリームメディアデータ伝送方法、クライアント及びサーバ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6563424

(24)【登録日】2019年8月2日

(45)【発行日】2019年8月21日

(54)【発明の名称】ストリームメディアデータ伝送方法、クライアント及びサーバ

(51)【国際特許分類】

   H04N 21/438 20110101AFI20190808BHJP

   H04N 21/24 20110101ALI20190808BHJP

   G06F 13/00 20060101ALI20190808BHJP

【ＦＩ】

   H04N21/438

   H04N21/24

   G06F13/00 520B

【請求項の数】19

【全頁数】25

(21)【出願番号】特願2016-569038(P2016-569038)

(86)(22)【出願日】2015年6月18日

(65)【公表番号】特表2018-509010(P2018-509010A)

(43)【公表日】2018年3月29日

(86)【国際出願番号】CN2015081737

(87)【国際公開番号】WO2016112639

(87)【国際公開日】20160721

【審査請求日】2018年6月15日

(31)【優先権主張番号】201510024568.1

(32)【優先日】2015年1月16日

(33)【優先権主張国】CN

(73)【特許権者】

【識別番号】510280589

【氏名又は名称】京東方科技集團股▲ふん▼有限公司

【氏名又は名称原語表記】ＢＯＥ ＴＥＣＨＮＯＬＯＧＹ ＧＲＯＵＰ ＣＯ．，ＬＴＤ．

(74)【代理人】

【識別番号】100108453

【弁理士】

【氏名又は名称】村山 靖彦

(74)【代理人】

【識別番号】100110364

【弁理士】

【氏名又は名称】実広 信哉

(72)【発明者】

【氏名】▲張▼ 楚雄

【審査官】 長谷川 素直

(56)【参考文献】

【文献】 特開２００９−２０６５６４（ＪＰ，Ａ）

【文献】 特開２００７−２１４６７５（ＪＰ，Ａ）

【文献】 特開２０１０−１１４８１５（ＪＰ，Ａ）

【文献】 国際公開第２０１４／０４５７６８（ＷＯ，Ａ１）

【文献】 米国特許出願公開第２０１３／０１１１０２８（ＵＳ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｈ０４Ｎ ２１／００−２１／８５８

Ｇ０６Ｆ １３／００

Ｈ０４Ｎ ２１／２４

(57)【特許請求の範囲】

【請求項1】

クライアントであって、
サーバが同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断するための第１の処理モジュールと、
前記第１の処理モジュールにより、前記サーバが同じ内容であり異なるビットレートである複数のセグメントを送信すると判断する場合に、前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを、前記クライアント自身によって、または前記サーバによって送信される第１の指示情報に従って判断する第２の処理モジュールと、を備えるクライアント。

【請求項2】

前記第２の処理モジュールにより前記サーバが優先的に高ビットレートのセグメントを送信すると判断する場合に、高ビットレートのセグメントの受信を始める第１の送受信モジュールを更に備える請求項１に記載のクライアント。

【請求項3】

前記第２の処理モジュールは、更に、
前記第１の送受信モジュールが高ビットレートのセグメントの受信を始めた後、前記第１の送受信モジュールが当該高ビットレートのセグメントの受信を始めてから第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したかどうかを判断し、
前記第１の送受信モジュールが前記第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、前記第１の送受信モジュールが当該高ビットレートのセグメントの受信をあきらめるように制御し、且つ低ビットレートのセグメントの受信を始める請求項２に記載のクライアント。

【請求項4】

前記第２の処理モジュールは更に、
前記第１の送受信モジュールが前記第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成すると、前記第１の送受信モジュールが前記サーバへ、前記サーバが低ビットレートのセグメントを送信する必要がないことを通知する第２の指示情報を送信するように制御する請求項３に記載のクライアント。

【請求項5】

前記第２の処理モジュールにより、前記サーバが優先的に低ビットレートのセグメントを送信すると判断する場合に、低ビットレートのセグメントの受信を始め、且つ低ビットレートのセグメントを受信した後、引き続いて高ビットレートのセグメントの受信を始めるための第２の送受信モジュールを更に含む請求項１に記載のクライアント。

【請求項6】

前記第２の送受信モジュールが当該高ビットレートのセグメントの受信を始めた後、前記第２の処理モジュールは更に、
前記第２の送受信モジュールが当該高ビットレートのセグメントの受信を始めてから第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したかどうかを判断し、
前記第２の送受信モジュールが前記第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、前記第２の送受信モジュールに受信を完成した低ビットレートのセグメントを復号化させるように制御する請求項５に記載のクライアント。

【請求項7】

前記第２の処理モジュールは、更に、前記第２の送受信モジュールが前記第２の時間閾値内に、当該高ビットレートのセグメントに対する受信を完成していないと、前記第２の送受信モジュールに当該高ビットレートのセグメントに対する受信をあきらめさせるように制御する請求項６に記載のクライアント。

【請求項8】

前記第２の処理モジュールは具体的に、前記サーバにより送信された前記サーバが高ビットレートのセグメントを優先的に送信するかどうかを指示するための前記第１の指示情報に基づいて、前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断することを特徴とする請求項１〜７のいずれかに記載のクライアント。

【請求項9】

サーバであって、
クライアントへ同じ内容であり異なるビットレートである複数のセグメントを送信する際、優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを確定するための処理モジュールと、
高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報を前記クライアントに送信する送受信モジュールと、を備えるサーバ。

【請求項10】

前記送受信モジュールは、更に、
前記第１の指示情報を前記クライアントに送信した後、前記クライアントより送信した、前記サーバが前記クライアントへ低ビットレートのセグメントを送信する必要がないことを指示する第２の指示情報を受信し、
前記第２の指示情報により前記クライアントへの低ビットレートのセグメントの送信を停止する請求項９に記載のサーバ。

【請求項11】

クライアントによって実行されるストリームメディアデータ伝送方法であって、
サーバが同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断するステップと、
前記サーバが同じ内容であり異なるビットレートである複数のセグメントを送信すると、前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを、前記クライアント自身によって、または前記サーバによって送信される第１の指示情報に従って判断するステップと、を含むストリームメディアデータ伝送方法。

【請求項12】

前記サーバが優先的に高ビットレートのセグメントを送信すると、高ビットレートのセグメントの受信を始めるステップと、
当該高ビットレートのセグメントの受信を始めてから第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したかどうかを判断するステップと、
前記第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、当該高ビットレートのセグメントの受信をあきらめ、且つ低ビットレートのセグメントの受信を始めるステップと、を含む請求項１１に記載の方法。

【請求項13】

前記第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成すると、前記サーバへ前記サーバが低ビットレートのセグメントを送信する必要がないことを通知する第２の指示情報を送信するステップを更に含む請求項１２に記載の方法。

【請求項14】

前記サーバが優先的に低ビットレートのセグメントを送信すると、低ビットレートのセグメントの受信を始め、且つ低ビットレートのセグメントを受信した後、引き続いて高ビットレートのセグメントの受信を始めるステップを更に含む請求項１１に記載の方法。

【請求項15】

当該高ビットレートのセグメントの受信を始めた後、
当該高ビットレートのセグメントの受信を始めてから第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したかどうかを判断するステップと、
前記第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、受信が完成された低ビットレートのセグメントを復号化するステップとを更に含む請求項１４に記載の方法。

【請求項16】

前記第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していな
いと、当該高ビットレートのセグメントに対する受信をあきらめるステップを更に含む請求項１５に記載の方法。

【請求項17】

前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断することは、
前記サーバにより送信した前記サーバが高ビットレートのセグメントを優先的に送信するかどうかを指示するための前記第１の指示情報を受信するステップと、
受信された前記第１の指示情報により、前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断するステップとを含む請求項１１〜１６のいずれかに記載の方法。

【請求項18】

サーバによって実行されるストリームメディアデータ伝送方法であって、
クライアントへ同じ内容であり異なるビットレートである複数のセグメントを送信する際、優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを確定するステップと、
高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報を前記クライアントに送信するステップと、を含むストリームメディアデータ伝送方法。

【請求項19】

前記第１の指示情報を前記クライアントに送信した後、更に、
前記クライアントにより送信した前記サーバが前記クライアントへ低ビットレートのセグメントを送信する必要がないことを指示する第２の指示情報を受信するステップと、
前記第２の指示情報により前記クライアントへの低ビットレートのセグメントの送信を停止するステップとを含む請求項１８に記載の方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はストリームメディア技術に関し、特にストリームメディアデータ伝送装置、方法及びシステムに関する。

【背景技術】

【0002】

従来のストリームメディア技術を採用する場合に、伝送したストリームメディアデータはファイアウォール、専門的なメディアサーバによってストリームメディア技術をサポートする必要があり、且つ従来のストリームメディア技術の実現方式は複雑である。従来、インターネットによってストリームメディアデータを伝送するインターネットストリームメディア技術が出現し、従来のインターネット体系に対して追加の要求を提出しなく、メディアファイルの記憶、情報記述方式を修正することができ、従来のＨＴＴＰプロトコルによってストリームメディアデータを伝送させることができる。

【0003】

動画専門家集団（Ｍｏｖｉｎｇ Ｐｉｃｔｕｒｅｓ Ｅｘｐｅｒｔｓ Ｇｒｏｕｐ、ＭＰＥＧ）が制定したダイナミックアダプティブストリームメディア （Ｄｙｎａｍｉｃ Ａｄａｐｔｉｖｅ Ｓｔｒｅａｍｉｎｇ ｏｖｅｒ ＨＴＴＰ、ＤＡＳＨ）標準は、ＭＰＥＧ ＤＡＳＨ標準と略称し、インターネットストリームメディア技術を採用してストリームメディアデータを伝送する標準化方案を提供する。

【0004】

ＭＰＥＧ ＤＡＳＨ標準で定義されたメディア表現記述（Ｍｅｄｉａ Ｐｒｅｓｅｎｔａｔｉｏｎ Ｄｅｓｃｒｉｐｔｉｏｎ、ＭＰＤ）の階層構造モデルを図１に示す。

【0005】

当該階層構造モデルにおいて、ピリオド（Ｐｅｒｉｏｄ）は一定の時間再生できるメディア内容を記述することに用いられ、隣接配列するピリオドが記述するメディア内容は時間的に連続である。１つのピリオドは複数のアダプテーションセット（Ａｄａｐｔａｔｉｏｎ Ｓｅｔ）を含み、各アダプテーションセットは複数のビットレートにアダプテーションするメディア内容を記述し、各ビットレートは１つの表現（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎ）に対応する。表現はメディア内容の具体的なパッケージフォーマット、ビットレート、符号化および復号化パラメータ等の情報を記述する。１つの表現は複数のセグメント（Ｓｅｇｍｅｎｔ）のユニフォームリソースロケータ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｅｃｅ Ｌｏｃａｔｏｒ、ＵＲＬ）を含み、対応したセグメントの記憶位置を指示することに用いられ、セグメントは具体的なメディア内容、即ちオーディオ、ビデオ、字幕、多重化されたオーディオ及びビデオ等を含む。

【0006】

上記ＭＰＥＧ ＤＡＳＨ標準に基づいて、インターネットによってストリームメディアデータを伝送する選択的な方案は、まず、ＷｅｂＳｏｃｋｅｔ双方向接続を確立して、ＷｅｂＳｏｃｋｅｔテキストフレームによってＭＰＥＧ ＤＡＳＨ標準の制御情報を伝送し、ＷｅｂＳｏｃｋｅｔバイナリフレームによってセグメントを伝送する。

【0007】

図１に示すようなフレームでクライアントにメディア内容を表示する過程は図２を参照し、図１に示すようなフレームでクライアントにメディア内容を表示する過程は、以下のステップを含む。

【0008】

ステップＳ２０１において、クライアントはサーバにＯｐｅｎＭｅｄｉａメッセージを送信する。クライアントは当該メッセージにＭＰＤのＵＲＬアドレスを携えることによって、再生する必要があるメディアをサーバに指示する。

【0009】

ステップＳ２０２において、クライアントにメディアの情報、例えば、メディアは準備ができるたか否かを知らせるように、サーバはクライアントにＭｅｄｉａＩｎｆｏメッセージを送信する。

【0010】

ステップＳ２０３において、サーバにメディアの送信を要求するように、クライアントはサーバにＳｔａｒｔＳｔｒｅａｍメッセージを送信する。

【0011】

ステップＳ２０４において、クライアントにメディアストリームの情報を知らせるように、サーバはクライアントにＳｔｒｅａｍＩｎｆｏメッセージを送信する。

【0012】

ステップＳ２０５において、サーバはメディアセグメントの送信を始める。

【0013】

クライアントはサーバにメディアの再生を起動することを要求した後に、サーバは図２におけるステップＳ２０４によって、クライアントに送信したＳｔｒｅａｍＩｎｆｏメッセージに、サーバが同じ内容であり異なるビットレートである複数の表現を送信するか否かを指示するための指示情報ｍｕｌｔｉｐｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎを携える。当該指示情報が、サーバが同じ内容であり異なるビットレートである複数の表現を送信するのを指示すると、サーバはセグメントを送信する際に、クライアントに同時に複数の同じ内容であり異なるビットレートであるセグメント、即ち前記複数の表現に含まれた同じ内容であり異なるビットレートであるセグメントを送信する。

【0014】

上記過程に関するＯｐｅｎＭｅｄｉａメッセージ、ＭｅｄｉａＩｎｆｏメッセージ、ＳｔａｒｔＳｔｒｅａｍメッセージとＳｔｒｅａｍＩｎｆｏメッセージを、ＭＰＥＧ ＤＡＳＨ標準についてＷｅｂＳｏｃｋｅｔプロトコルにおいて拡張される、ＷｅｂＳｏｃｋｅｔのテキストフレームによって伝送されるメッセージと見なすことができる。

【0015】

しかしながら、クライアントはサーバがまず送信したセグメントは高いビットレートのものであるか、低いビットレートのものであるかを分からない。

【0016】

従来の一つの実現方式は、クライアントは１つのセグメントを受信した後に、所定の待ち時間で、より高いビットレートのセグメントを受信したか否かを判断し、より高いビットレートのセグメントを受信すると、当該より高いビットレートのセグメントを復号化して表示し、より高いビットレートのセグメントを受信していないと、前に受信したセグメントを復号化して表示することである。

【0017】

サーバがまず高いビットレートのセグメントを送信する場合に対して、上記実現方式において、クライアントは高いビットレートのセグメントを受信した後に、サーバが後続送信した同じ内容であり異なるビットレートであるセグメントがより高いビットレートのセグメントであるか、より低いビットレートのセグメントであるかを分からないと、依然として上記所定の待ち時間で待ち、クライアントの復号化の遅延が増加されてしまう。

【発明の開示】

【発明が解決しようとする課題】

【0018】

本発明が解決しようとする技術的課題は、クライアントがより高いビットレートのセグメントを待ち、復号化の遅延が長い問題を解決するためのストリームメディアデータ伝送装置、方法及びシステムを提供することである。

【課題を解決するための手段】

【0019】

本発明の第１の様態によれば、サーバが同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断する第１の処理モジュールと、前記第１の処理モジュールにより前記サーバが同じ内容であり異なるビットレートである複数のセグメントを送信すると判断する場合に、前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する第２の処理モジュールと、を備えるクライアントを提供する。

【0020】

本発明の第２の様態によれば、クライアントへ同じ内容であり異なるビットレートである複数のセグメントを送信する場合に優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを確定する処理モジュールと、高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報を前記クライアントに送信する送受信モジュールと、を備えるサーバを提供する。

【0021】

本発明の第３の様態によれば、サーバが同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断するステップと、前記サーバが同じ内容であり異なるビットレートである複数のセグメントを送信すると、前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断するステップと、を含むストリームメディアデータ伝送方法を提供する。

【0022】

本発明の第４の様態によれば、クライアントへ同じ内容であり異なるビットレートである複数のセグメントを送信する場合に優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを確定するステップと、高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報を前記クライアントに送信するステップと、を含む他のストリームメディアデータ伝送方法を提供する。

【0023】

本発明の第５の様態によれば、クライアント及びサーバを備えるストリームメディアデータ伝送システムを提供し、前記クライアントは、前記サーバが同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断し、前記サーバが同じ内容であり異なるビットレートである複数のセグメントを送信すると、前記サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断し、前記サーバは、前記クライアントへメディアセグメントを送信する。

【発明の効果】

【0024】

以上のように、本発明の実施例において、クライアントはサーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断することができ、このため、クライアントはサーバが高ビットレートのセグメントを優先的に送信すると判断する場合、サーバがより高いビットレートのセグメントを送信することを待つ必要がなく、受信されたセグメントを直接に復号化し、クライアントが復号化する遅延を短縮したことを実現する。

【図面の簡単な説明】

【0025】

【図1】ＭＰＥＧ ＤＡＳＨ標準で定義されたＭＰＤ階層構造のモデル図である。

【図2】図１に示すフレームでクライアントがメディア内容を表示する過程の模式的なフローチャートである。

【図3】本発明の実施例によるストリームメディアデータ伝送システムの構造模式図である。

【図4】ＷｅｂＳｏｃｋｅｔのフレーム構造の模式図である。

【図5】ビットレート切り替え方式の模式図である。

【図6】本発明の実施例１によるクライアントのストリームメディアデータ伝送の処理のフローチャートである。

【図7A】本発明の実施例によるクライアントの第１の構造模式図である。

【図7B】本発明の実施例によるクライアントの第２の構造模式図である。

【図7C】本発明の実施例によるクライアントの第３の構造模式図である。

【図7D】本発明の実施例によるクライアントの第４の構造模式図である。

【図8】本発明の実施例によるサーバの構造模式図である。

【図9】本発明の実施例によるストリームメディアデータ伝送方法のフローチャートである。

【図10】本発明の実施例による他のストリームメディアデータ伝送方法のフローチャートである。

【発明を実施するための形態】

【0026】

本発明の実施例は、クライアントがより高いビットレートのセグメントを待ち、復号化の遅延が長い問題を解決するためのストリームメディアデータ伝送装置及び方法を提供する。

【0027】

以下、本発明の実施例を図面を参照しながら詳しく説明する。まず、本発明の実施例によるストリームメディアデータ伝送システムを説明し、そして、本発明の実施例によるクライアント及びサーバをそれぞれ説明し、最後、本発明の実施例による二つのストリームメディアデータ伝送方法を説明する。

【0028】

図３は本発明の実施例によるストリームメディアデータ伝送システムの構造模式図である。図３に示すように、当該システムはクライアント３０１及びサーバ３０２を含む。

【0029】

クライアント３０１はサーバ３０２が同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断する。サーバ３０２が同じ内容であり異なるビットレートである複数のセグメントを送信すると判断する場合に、クライアント３０１は更にサーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する。

【0030】

サーバ３０２はクライアント３０１へメディアを送信する。

【0031】

図３において、簡単に模式的に示すために、一つのクライアント３０１及び一つのサーバ３０２のみを示したが、実際に、１つのサーバ３０２は複数のクライアント３０１へメディアを送信することができ、１つのクライアント３０１もそれぞれ複数のサーバ３０２へメディアの送信を要求できる。

【0032】

本発明の実施例において、選択的に、クライアント３０１はサーバ３０２とＷｅｂＳｏｃｋｅｔ双方向接続を確立しており、確立された当該ＷｅｂＳｏｃｋｅｔ双方向接続に基づいてストリームメディア伝送を行う。クライアント３０１は図２におけるステップＳ２０３により、サーバ３０２のメディアの送信を要求することができ、即ちクライアント３０１はサーバ３０２へＳｔａｒｔＳｔｒｅａｍメッセージを送信して、メディアストリームを要求する。

【0033】

例えば、クライアント３０１はサーバ３０２のメディアの送信を要求した後且つサーバ３０２がクライアント３０１へ各セグメントを送信する前に、サーバ３０２が優先的に優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断することができる。代わりに、クライアント３０１はサーバ３０２のメディアの送信の過程において、サーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断してもよい。

【0034】

具体的には、サーバ３０２はクライアント３０１へ送信されたＳｔｒｅａｍＩｎｆｏメッセージにおけるｍｕｌｔｉｐｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎキーにより、クライアント３０１へサーバ３０２が同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを指示する。当該キーの取り値が「ｔｒｕｅ」である場合、クライアント３０１へサーバ３０２が同じ内容であり異なるビットレートである複数のセグメントを送信すると指示する。

【0035】

現在、ＳｔｒｅａｍＩｎｆｏメッセージのフォーマットを表１に示す。

【0036】

【表1】

【0037】

具体的には、クライアント３０１が、サーバ３０２のメディアの送信の過程においてサーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する場合に、クライアント３０１は以下の形態１又は形態２によりサーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する。クライアント３０１が、サーバ３０２が各セグメントを送信する前にサーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する場合に、クライアント３０１は以下形態２によりサーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する。

【0038】

形態１、クライアント３０１自体で判断を実現する。

【0039】

クライアント３０１が、サーバ３０２のメディアの送信を要求した後受信されたサーバ３０２により送信した一つ目のセグメントのビットレートが所定のビットレート上限（例えば、クライアント３０１は予めサーバ３０２がクライアント３０１へ送信する各セグメントの最高ビットレートを知っていると、当該最高ビットレートを所定のビットレート上限とする）であると、クライアント３０１はサーバ３０２が優先的に高ビットレートのセグメントを送信すると判断する。クライアント３０１がサーバ３０２のメディアの送信を要求した後受信されたサーバ３０２により送信した一つ目のセグメントのビットレートが所定のビットレート下限（例えば、クライアント３０１は予めサーバ３０２がクライアント３０１へ送信した各セグメントの最低ビットレートを知っていると、当該最低ビットレートを所定のビットレート下限とする）であると、クライアント３０１はサーバ３０２が優先的に低ビットレートのセグメントを送信すると判断する。

【0040】

クライアント３０１は、サーバ３０２のメディアの送信を要求した後、まずサーバ３０２により送信した高ビットレートのセグメントを受信し、次にサーバ３０２により送信した低ビットレートのセグメントを受信すると、サーバ３０２が優先的に高ビットレートのセグメントを送信すると判断する。まずサーバ３０２が送信した低ビットレートのセグメントを受信し、次にサーバ３０２が送信した高ビットレートのセグメントを受信すると、サーバ３０２が優先的に低ビットレートのセグメントを送信すると判断する。

【0041】

具体的には、クライアント３０１が、サーバ３０２のメディアの送信を要求した後受信されたサーバ３０２により送信した一つ目のセグメントのビットレートが所定のビットレート上限よりも小さくて且つ所定のビットレート下限よりも大きいと、クライアント３０１は次のセグメントの受信を待ち、受信された次のセグメントのビットレートが一つ目のセグメントのビットレートよりも低いと、サーバ３０２が優先的に高ビットレートのセグメントを送信すると判断する。受信された次のセグメントのビットレートが一つ目のセグメントのビットレートよりも高いと、サーバ３０２が優先的に低ビットレートのセグメントを送信すると判断する。

【0042】

クライアント３０１自体で判断する形態はいろいろあり、以上のものは単に例示である。

【0043】

形態２、クライアント３０１はサーバ３０２が送信した第１の指示情報により判断する。

【0044】

当該第１の指示情報はサーバ３０２が高ビットレートのセグメントを優先的に送信するかどうかを指示するためのものである。選択的に、クライアント３０１とサーバ３０２がＷｅｂＳｏｃｋｅｔ双方向接続を確立したと、確立された当該ＷｅｂＳｏｃｋｅｔ双方向接続に基づいてストリームメディアの伝送を行い、表１に示すＳｔｒｅａｍＩｎｆｏメッセージを修正することができ、これによりＳｔｒｅａｍＩｎｆｏメッセージで当該第１の指示情報を提供する。例えば、以下の表２に示すように、表１に示すＳｔｒｅａｍＩｎｆｏメッセージでキー「ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙ」を増加し、且つ当該キー「ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙ」により当該第１の指示情報を提供することができる。例えば、表２において、「ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙ」がキー「ｍｕｌｔｉｐｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎ」の後にあるが、実際に実現する際、位置が表２に示す位置に限定されず、例えば、メッセージ全体の最後にあってもよい。

【0045】

表２において、「ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙ」の値がＢｏｏｌｅａｎタイプであり、取り値が「ｔｒｕｅ」であるとサーバ３０２が優先的に高ビットレートのセグメントを送信することを示し、取り値が「ｆａｌｓｅ」であるとサーバ３０２が優先的に低ビットレートのセグメントを送信することを示す。実際に実現する際、その他のタイプ、例えば、数値型であってもよく、取り値が１である場合サーバ３０２が優先的に高ビットレートのセグメントを送信することを示し、取り値が０である場合サーバ３０２が優先的に低ビットレートのセグメントを送信することを示す。具体的な実現形態は以上の例に限定されず、クライアント３０１にサーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断させることができれば良い。

【0046】

【表2】

【0047】

選択的に、クライアント３０１が確実にセグメントを受信することを実現するために、サーバ３０２が優先的に高ビットレートのセグメントを送信すると判断した場合、高ビットレートのセグメントを受信し始めた後、クライアント３０１は更に高ビットレートのセグメントを受信し始めた後の第１の時間閾値内に当該高速率のセグメントに対する受信を完成したかどうかを判断することができる。当該第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、クライアント３０１は当該高ビットレートのセグメントの受信をあきらめて、低ビットレートのセグメントの受信を始めることができる。

【0048】

選択的に、前記クライアント３０１は高ビットレートのセグメントを受信し始めた後計時を始めることができ、代わりに、サーバ３０２が優先的に高ビットレートのセグメントを送信すると判断した後計時を始めてもよい。

【0049】

選択的に、クライアント３０１がサーバ３０２のメディアの送信を要求した後且つサーバ３０２がクライアント３０１へ各セグメントを送信する前に、サーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断すると、クライアント３０１は更にサーバ３０２のメディアの送信を要求してから計時を始めてもよい。

【0050】

選択的に、ネットワークの伝送リソースを節約し、クライアント３０１とサーバ３０２との間のセグメント伝送効率を向上させるために、クライアント３０１が上記第１の時間閾値内に当該高ビットレートのセグメントの受信を完成すると、クライアント３０１はサーバ３０２へ第２の指示情報を送信し、当該第２の指示情報はサーバ３０２に低ビットレートのセグメントを送信する必要がないことを通知するためのものである。

【0051】

選択的に、クライアント３０１とサーバ３０２がＷｅｂＳｏｃｋｅｔ双方向接続を確立し、確立された当該ＷｅｂＳｏｃｋｅｔ双方向接続に基づいてストリームメディア伝送を行うと、クライアント３０１はＷｅｂＳｏｃｋｅｔフレームにおける指示情報によりセグメントの受信を完成したかどうかを判断することができる。

【0052】

ＷｅｂＳｏｃｋｅｔのフレーム構造を図４に示す。オペコードが４ビット（ｂｉｔ）であり、以下、オペコードの取り値とオペコードが示す意味との間の対応関係である。
０：エンドマーカとともに、セクションフレームの中間セグメントを示す
１ ：テキストフレーム
２ ：バイナリフレーム
３〜７：保留
８：接続オフ
９：Ｐｉｎｇ命令
Ａ ：Ｐｏｎｇ命令
Ｂ〜Ｆ：保留

【0053】

伝送するデータが大きすぎて、１つのＷｅｂＳｏｃｋｅｔバイナリフレームでパッケージできないと、ＷｅｂＳｏｃｋｅｔプロトコルにより、伝送しようとするデータをセクション化することができる。
セクション化されないフレームについて、エンドマーカ＝１ オペコード≠０
セクション化されたフレームについて：
一つ目のセクション：エンドマーカ＝０，オペコード≠０
二つ〜（Ｎ−１）次目のセクション：エンドマーカ＝０，オペコード＝０
Ｎ次目のセクション、即ち最後１つのセクション：エンドマーカ＝１，オペコード＝０

【0054】

クライアント３０１はサーバ３０２が送信したＳｔｒｅａｍＩｎｆｏメッセージを含むテキストフレームを受信した後、サーバ３０２が送信するセグメントの受信を始める。１つのセグメントが大きすぎると、当該セグメントを複数のセクションに分割することができ、前記複数のセクションはそれぞれ複数のＷｅｂＳｏｃｋｅｔバイナリフレームに置いて伝送され、具体的には、１つのＷｅｂＳｏｃｋｅｔバイナリフレームにおいて１つのセクションを伝送する。

【0055】

サーバ３０２は１つのセグメントを１つ又は複数のバイナリフレームにより送信する。クライアント３０１は、受信されたバイナリフレームのエンドマーカが「０」で、オペコードが 「０」ではない場合、現在セグメントがセクションで送信された（即ち１つのセグメントが複数のバイナリフレームによって送信される）ものであり、当該バイナリフレームは当該セグメントの第１のセクションを含み、且つ後続に更に当該セグメントの他のセクションを含むバイナリフレームを受信する必要があることを確定する。クライアント３０１は、受信されたバイナリフレームのエンドマーカが「０」であり、オペコードが「０」であるまで、後続のバイナリフレームの受信を引く続いて、既に当該セグメントの受信を完成したと確定する。

【0056】

以上のように、クライアント３０１が第１の時間閾値内に高ビットレートのセグメントの受信を完成すると、クライアント３０１はサーバ３０２へ第２の指示情報を送信し、第２の指示情報はサーバ３０２が更に低ビットレートのセグメントを送信する必要がないことを通知するに用いられる。以下の新たなメッセージＲｅｃｅｉｖｅＲｅｐｏｒｔを定義することで、表３に示すように、当該新しく定義されたメッセージで当該第２の指示情報を送信することができる。

【0057】

【表3】

【0058】

選択的に、当該メッセージは以下の表４で挙げたキー値ペアを含むことができる。

【0059】

【表4】

【0060】

上記第１の時間閾値内に、クライアント３０１が高ビットレートのセグメントの受信を完成すると、クライアント３０１はサーバへ上記ＲｅｃｅｉｖｅＲｅｐｏｒｔメッセージを送信し、当該メッセージのＲｅｃｅｉｖｅＳｔａｔｕｓがＴｒｕｅである。サーバ３０２は当該メッセージを受信した後、クライアント３０１へさらに低ビットレートのセグメントを送信しない。

【0061】

上記第１の時間閾値内に、クライアント３０１が高ビットレートのセグメントの受信を完成しないと、クライアント３０１はサーバ３０２へ上記ＲｅｃｅｉｖｅＲｅｐｏｒｔメッセージを送信し、当該メッセージのＲｅｃｅｉｖｅＳｔａｔｕｓがＦａｌｓｅである。サーバ３０２は高ビットレートのセグメントを送信することを終止し、低ビットレートのセグメントの送信を始める。

【0062】

以上、具体的にクライアント３０１が、サーバ３０２が優先的に高ビットレートのセグメントを送信することを確定する場合の処理方案を記述した。以下、クライアント３０１はサーバ３０２が優先的に低ビットレートのセグメントを送信することを確定する場合の処理方案を説明する。

【0063】

サーバ３０２が優先的に低ビットレートのセグメントを送信すると判断すると、クライアント３０１は低ビットレートのセグメントを受信し始めた後、引き続いて高ビットレートのセグメントを受信する。

【0064】

選択的に、クライアント３０１は、複数の高ビットレートのセグメントがあるかどうかを判断する。複数の高ビットレートのセグメントが存在すると、クライアント３０１はサーバ３０２との間のネットワーク帯域幅により、存在する複数の高ビットレートのセグメントから１つの高ビットレートのセグメントを選択して受信を始める。

【0065】

クライアント３０１は高ビットレートのセグメントを受信し始めった後、当該高ビットレートのセグメントを受信し始めてから第２の時間閾値内に当該高ビットレートのセグメントの受信を完成したかどうかを判断する。クライアント３０１が当該高ビットレートのセグメントを受信し始めてから第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと判断すると、クライアント３０１は受信を完成した低ビットレートのセグメントを復号化する。

【0066】

選択的に、クライアント３０１はサーバ３０２が優先的に低ビットレートのセグメントを送信すると判断してから計時を始めてもよい。

【0067】

選択的に、以上のように、クライアント３０１はサーバ３０２のメディアの送信を要求した後且つサーバ３０２がクライアント３０１へ各セグメントを送信する前に、サーバ３０２が優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断すると、クライアント３０１は更にサーバ３０２のメディアの送信を要求した後計時を始めてもよい。

【0068】

当該選択可能な方案において、クライアント３０１はまず低ビットレートのセグメントを受信した後、受信された低ビットレートのセグメントをまだ復号化しなく、高ビットレートのセグメントの受信を待つ。クライアント３０１がサーバ３０２のメディアの送信を要求した後の第２の時間閾値内に、当該高ビットレートのセグメントに対する受信を完成すると、当該高ビットレートのセグメントを復号化し、先に受信された低ビットレートのセグメントをあきらめる。サーバ３０２のメディアの送信を要求した後の第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、受信を完成した低ビットレートのセグメントを復号化し、これによりセグメント受信の信頼性を保証する。

【0069】

上記第１の時間閾値、第２の時間閾値は、以下の形態を含む多種の形態で確定することができる。
形態１、所定の時間長さであり、例えば、クライアント３０１とサーバ３０２との間のネットワークトポロジーにより予め配置する。
形態２、クライアント３０１はＭＰＤにおけるセグメントのＵＲＬに含まれたセグメントバイト数とセグメントの属する表現のｂａｎｄｗｉｄｔｈプロパティの値とを除算して、当該セグメントの伝送に必要な時間長さを算出し、算出された当該時間長さにより第１の時間閾値及び第２の時間閾値を確定する。
形態３、セグメントの再生時間長さにより確定する。例えば、当該第１の時間閾値及び／又は第２の時間閾値をセグメントの再生時間長さ、即ちセグメントの属する表現のｄｕｒａｔｉｏｎプロパティの値に設定するか、又は当該値の半分等に設定する。
形態４、リアルタイムに取得したクライアント３０１とサーバ３０２との間のネットワーク状況（例えば、ネットワーク輻輳状況、内容取得時間長さ、復号化時間長さ、キャッシュメディアの再生可能な時間等）によりリアルタイムに調整する。

【0070】

ＭＰＤに記述されたセグメントの属する表現のプロパティは以下の表５を参照することができる。

【0071】

【表5】

【0072】

本発明の実施例において、クライアント３０１は図５に示す形態によりビットレートの切り替えを行うことができる。

【0073】

クライアント３０１はＭＰＤにおいて現在再生しているセグメントの属する表現（明らかに記述するために、ここで「表現１」と標記する）を見付けて、表現１におけるｓｔａｒｔＮｕｍｂｅｒプロパティの値及びセグメントに対応するＳｅｇｍｅｎｔＵＲＬ要素の配列シリアルナンバー（Ｎと標記する）により、現在セグメントのシリアルナンバーとしてｓｔａｒｔＮｕｍｂｅｒ＋Ｎを算出する。次に、同一のアダプター集合に属する、同じ内容を含むとともに異なるビットレートを有する、切り替え先とする表現（「表現２」と標記する）を見付けて、且つ表現２においてシリアルナンバーがｓｔａｒｔＮｕｍｂｅｒ＋Ｎ＋１であるセグメント（セグメントＮ＋１と標記する）を見付ける。その後、クライアント３０１はサーバ３０２へ表現２におけるセグメントＮ＋１を要求する。

【0074】

以上、本発明の実施例によるストリームメディア伝送システム及びビットレートきりええの方案を詳しく説明した。クライアントとサーバを互いに組み合わせる視点から、ストリームメディアデータ伝送の方案を説明したが、クライアントとサーバを相互に組み合わせなければならないという意味ではなく、実際に、クライアントとサーバとをそれぞれ独立に実施する場合においても、クライアント側及びサーバ側に存在する問題をそれぞれ解決しており、ただ、２つのものを組み合わせて使用する場合、より良い技術効果を取得することができる。

【0075】

以下、それぞれ本発明の実施例によるクライアント、サーバ及び二つのストリームメディアデータ伝送方法を説明し、その技術問題を解決する原理は、本発明の実施例によるストリームメディアデータ伝送システムと類似するので、その実施は当該システムの実施を参照することができ、繰り返し部分を再び説明しない。

【0076】

以下、本発明の実施例１によるクライアント３０１のストリームメディアデータ伝送の処理例を図６を参照して説明する。

【0077】

ステップＳ６００では、クライアント３０１がサーバ３０２にメディアの送信を要求する。

【0078】

ステップＳ６０１では、クライアント３０１はサーバ３０２が送信したＳｔｒｅａｍＩｎｆｏメッセージを受信する。

【0079】

ステップＳ６０２では、クライアント３０１はＳｔｒｅａｍＩｎｆｏメッセージにおける指示情報ｍｕｌｔｉｐｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎにより、サーバ３０２が複数の同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断する。ｍｕｌｔｉｐｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎの取り値がｆａｌｓｅであると、クライアント３０１はサーバ３０２が１つのビットレートのセグメントのみを送信することを確定し、次にステップＳ６０９を実行する。ｍｕｌｔｉｐｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎの取り値がｔｒｕｅであると、クライアント３０１はサーバ３０２が同じ内容であり異なるビットレートである複数のセグメントを送信することを確定し、次にステップＳ６０３を実行する。

【0080】

ステップＳ６０３では、クライアント３０１はＳｔｒｅａｍＩｎｆｏメッセージにおける指示情報ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙにより、サーバ３０２が高ビットレートのセグメントを優先的に送信するかどうかを判断する。ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙの取り値がｔｒｕｅであると、クライアント３０１はサーバ３０２が優先的に高ビットレートのセグメントを送信することを確定し、次にステップＳ６１１を実行する。ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙの取り値がｆａｌｓｅであると、クライアント３０１はサーバ３０２が優先的に低ビットレートのセグメントを送信することを確定し、次にステップＳ６０４を実行する。

【0081】

ステップＳ６０４では、クライアント３０１は低ビットレートのセグメントの受信を始める。

【0082】

ステップＳ６０５では、クライアント３０１は高ビットレートのセグメントの受信を始める。

【0083】

ステップＳ６０６では、クライアント３０１はサーバ３０２にメディアの送信を要求してから第２の時間閾値内に高ビットレートのセグメントに対する受信を完成したかどうかを判断する。そうであると、ステップＳ６１５を実行する。そうではないと、ステップＳ６０７を実行する。

【0084】

ステップＳ６０７では、受信が完成された低ビットレートのセグメントを復号化する。

【0085】

ステップＳ６０８では、セグメントを再生する。

【0086】

クライアント３０１がステップＳ６０２においてＳｔｒｅａｍＩｎｆｏメッセージにおける指示情報ｍｕｌｔｉｐｌｅＲｅｐｒｅｓｅｎｔａｔｉｏｎにより、サーバ３０２が１つのビットレートのセグメントのみを送信することを確定した場合には、ステップＳ６０９では、クライアント３０１はサーバ３０２が送信したメディアセグメントを受信する。

【0087】

そして、ステップＳ６１０において、受信が完成されたセグメントを復号化し、次にステップＳ６０８を実行する。

【0088】

クライアント３０１がステップＳ６０３においてＳｔｒｅａｍＩｎｆｏメッセージにおける指示情報ｂｉｔｒａｔｅＰｒｉｏｒｉｔｙにより、サーバ３０２が優先的に高ビットレートのセグメントを送信すると判断した場合に、ステップＳ６１１では、クライアント３０１は高ビットレートのセグメントの受信を始める。

【0089】

そして、ステップＳ６１２では、クライアント３０１はサーバ３０２にメディアの送信を要求してから第１の時間閾値内に高ビットレートのセグメントに対する受信を完成したかどうかを判断する。そうであると、ステップＳ６１５を実行する。そうではないとステップＳ６１３を実行する。

【0090】

ステップＳ６１３では、クライアント３０１は高ビットレートのセグメントの受信をあきらめる。

【0091】

ステップＳ６１４では、クライアント３０１は低ビットレートのセグメントの受信を始め、次にステップＳ６０７を実行する。

【0092】

ステップＳ６１５では、クライアント３０１は受信が完成された高ビットレートのセグメントを復号化する。

【0093】

図７Ａは本発明の実施例によるクライアントの一つの構造模式図である。図７Ａに示すように、当該クライアントは、第１の処理モジュール７０１及び第２の処理モジュール７０２を備える。

【0094】

第１の処理モジュール７０１はサーバが同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断する。

【0095】

第２の処理モジュール７０２は、第１の処理モジュール７０１によりサーバが同じ内容であり異なるビットレートである複数のセグメントを送信すると判断した場合に、サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する。

【0096】

選択的に、図７Ｂに示すように、当該クライアントは、第２の処理モジュール７０２によりサーバが優先的に高ビットレートのセグメントを送信すると判断した場合、高ビットレートのセグメントの受信を始める第１の送受信モジュール７０３を更に備えてよい。

【0097】

選択的に、図７Ｂに示すクライアントに対して、第２の処理モジュール７０２は更に第１の送受信モジュール７０３が高ビットレートのセグメントを受信の始めてから、第１の送受信モジュール７０３が当該高ビットレートのセグメントの受信を始めてから第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したかどうかを判断することに用いられる。

【0098】

第１の送受信モジュール７０３は第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、前記第２の処理モジュール７０２は第１の送受信モジュール７０３を制御して当該高ビットレートのセグメントの受信をあきらめ、且つ低ビットレートのセグメントの受信を始める。

【0099】

更に、第２の処理モジュール７０２は更に、第１の送受信モジュール７０３が第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成すると、サーバへ低ビットレートのセグメントを送信する必要がないことを通知するための第２の指示情報を送信するように、第１の送受信モジュール７０３を制御することに用いられる。

【0100】

選択的に、図７Ｃに示すように、当該クライアントは更に、第２の処理モジュール７０２が、サーバは優先的に低ビットレートのセグメントを送信すると判断した場合、低ビットレートのセグメントの受信を始め、且つ低ビットレートのセグメントを受信した後、引き続いて高ビットレートのセグメントの受信を始めるための第２の送受信モジュール７０４を備えてよい。

【0101】

選択的に、第２の送受信モジュール７０４は当該低ビットレートのセグメントを受信した後、受信された当該低ビットレートのセグメントを直接に復号化することではなく、第２の処理モジュール７０２の制御により、受信された当該低ビットレートのセグメントを復号化するかどうかを確定する。

【0102】

選択的に、図７Ｃに示すクライアントに対して、第２の処理モジュール７０２はさらに、第２の送受信モジュール７０４が当該高ビットレートのセグメントの受信を始めた後、第２の送受信モジュール７０４が当該高ビットレートのセグメントの受信を始めてから第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したかどうかを判断することに用いられる。

【0103】

第２の送受信モジュール７０４が第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、第２の処理モジュール７０２は、受信が完成された低ビットレートのセグメントを復号化するように、第２の送受信モジュール７０４を制御する。

【0104】

更に、第２の処理モジュール７０２は更に、第２の送受信モジュール７０４が第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、当該高ビットレートのセグメントに対する受信をあきらめるように、第２の送受信モジュール７０４を制御することに用いられる。

【0105】

選択的に、本発明の実施例によるクライアントは更に図７Ｄに示す構造を有することができ、第１の処理モジュール７０１、第２の処理モジュール７０２、第１の送受信モジュール７０３及び第２の送受信モジュール７０４を備え、第１の処理モジュール７０１と第２の処理モジュール７０２の処理は上記図７Ａ〜図７Ｃに示すクライアントにおける同じモジュールの処理を参照できる。第１の送受信モジュール７０３と第２の処理モジュール７０２との間のインタラクションは、上記図７Ｂに示すクライアントにおける処理を参照でき、第２の送受信モジュール７０４と第２の処理モジュール７０２との間のインタラクションは、上記図７Ｃに示すクライアントにおける処理を参照でき、ここで繰り返して説明しない。

【0106】

選択的に、図７Ａ〜図７Ｄのいずれかに示すクライアントに対して、第２の処理モジュール７０２は具体的に、サーバにより送信されるサーバが高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報に基づいて、サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断することに用いられる。

【0107】

選択的に、当該第１の指示情報はＳｔｒｅａｍＩｎｆｏメッセージにある。

【0108】

図８は、本発明の実施例によるサーバの構造模式図である。図８に示すように、当該サーバは処理モジュール８０１及び送受信モジュール８０２を備える。

【0109】

処理モジュール８０１は、クライアントへ同じ内容であり異なるビットレートである複数のセグメントを送信する場合優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを確定する。

【0110】

送受信モジュール８０２は、高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報をクライアントに送信する。

【0111】

選択的に、送受信モジュール８０２は更に、第１の指示情報をクライアントに送信した後、クライアントから送信された、クライアントへ低ビットレートのセグメントを送信する必要がないことをサーバに指示するための第２の指示情報を受信し、且つ第２の指示情報にもとづいて、クライアントへ低ビットレートのセグメントを送信することを停止することに用いられる。

【0112】

図９は、本発明の実施例によるストリームメディアデータ伝送方法のフローチャートである。図９に示す前記ストリームメディアデータ伝送方法はクライアントに適用されることができる。

【0113】

ステップＳ９０１では、サーバが同じ内容であり異なるビットレートである複数のセグメントを送信するかどうかを判断する。

【0114】

ステップＳ９０２では、前記サーバが同じ内容であり異なるビットレートである複数のセグメントを送信すると、サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断する。

【0115】

選択的に、ステップＳ９０２でサーバが優先的に高ビットレートのセグメントを送信すると判断すれば、高ビットレートのセグメントの受信を始める。

【0116】

選択的に、高ビットレートのセグメントの受信を始めた後、前記ストリームメディアデータ伝送方法は更に、当該高ビットレートのセグメントの受信を始めてから第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したかどうかを判断するステップと、第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと判断すると、当該高ビットレートのセグメントの受信をあきらめ、且つ低ビットレートのセグメントの受信を始めるステップと、を含む。

【0117】

選択的に、前記ストリームメディアデータ伝送方法は更に、第１の時間閾値内に当該高ビットレートのセグメントに対する受信を完成したと判断すると、サーバへ低ビットレートのセグメントを送信する必要がないことを通知する第２の指示情報を送信するステップを含む。

【0118】

選択的に、ステップＳ９０２において、サーバが優先的に低ビットレートのセグメントを送信すると判断すると、低ビットレートのセグメントを受信した後、引き続いて高ビットレートのセグメントの受信を始める。

【0119】

選択的に、当該低ビットレートのセグメントを受信した後、前記ストリームメディアデータ伝送方法はさらに、受信された当該低ビットレートのセグメントを直接に復号化せず、高ビットレートのセグメントの受信状況によって受信された当該低ビットレートのセグメントを復号化するかどうかを判断するステップを含む。

【0120】

選択的に、当該高ビットレートのセグメントの受信を始めた後、前記ストリームメディアデータ伝送方法は更に、当該高ビットレートのセグメントの受信を始めてから第２の時間閾値内に、当該高ビットレートのセグメントに対する受信を完成したかどうかを判断するステップと、第２の時間閾値内に当該高ビットレートのセグメントに対する受信を完成していないと、受信が完成された低ビットレートのセグメントを復号化するステップとを含む。

【0121】

選択的に、前記ストリームメディアデータ伝送方法は更に、第２の時間閾値内に当該高ビットレートのセグメントに対する受信が完成されていないと、当該高ビットレートのセグメントに対する受信をあきらめるステップを含む。

【0122】

選択的に、ステップＳ９０２でサーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断することは、具体的に、サーバにより送信されたサーバが高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報を受信するステップと、受信された第１の指示情報により、サーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断するステップと、を含むことができる。

【0123】

選択的に、第１の指示情報は、ＳｔｒｅａｍＩｎｆｏメッセージにある。

【0124】

図１０は、本発明の実施例による他のストリームメディアデータ伝送方法のフローチャートである。図１０に示すストリームメディアデータ伝送方法はサーバに適用されることができる。

【0125】

ステップＳ１００１では、クライアントへ同じ内容であり異なるビットレートである複数のセグメントを送信する場合、優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを確定する。

【0126】

ステップＳ１００２では、高ビットレートのセグメントを優先的に送信するかどうかを指示するための第１の指示情報をクライアントに送信する。

【0127】

選択的に、ステップＳ１００２において第１の指示情報をクライアントに送信した後、前記ストリームメディアデータ伝送方法は、クライアントより送信されたサーバがクライアントへ低ビットレートのセグメントを送信する必要がないことを指示するための第２の指示情報を受信し、第２の指示情報に基づいてクライアントへの低ビットレートのセグメントの送信を停止するステップを更に含む。

【0128】

以上のように、本発明の実施例はストリームメディアデータ伝送装置、方法及びシステムを提供する。クライアントはサーバが同じ内容であり異なるビットレートである複数のセグメントを送信する場合優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断することができ、サーバが優先的に高ビットレートのセグメントを送信すると判断する際、サーバがより高いビットレートのセグメントを送信することを待つ必要がなくて、受信されたセグメントを直接に復号化し、クライアント復号化の遅延を短縮する。

【0129】

更に、クライアントはサーバが送信した各ビットレートのセグメントに基づいてサーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断するか、又はクライアントはサーバが送信した第１の指示情報によりサーバが優先的に高ビットレートのセグメントを送信するか、優先的に低ビットレートのセグメントを送信するかを判断し、二つのクライアント判断の具体的な形態を提供した。

【0130】

なお、クライアントは所定の時間閾値内に高ビットレートのセグメントに対する受信を完成することができると、サーバに低ビットレートのセグメントの送信を停止することを指示し、サーバがセグメントを送信する効率を向上させ、ネットワークの伝送リソースを節約する。

【0131】

一方、クライアントは所定の時間閾値内に高ビットレートのセグメントに対する受信を完成できないと、低ビットレートのセグメントを受信して復号化することによって、ストリームメディアデータ伝送の信頼性及びメディア再生のコヒーレンスを保証し、ユーザ体験を向上させる。

【0132】

当業者にとって、本発明の実施例を方法、システム、又はコンピュータプログラム製品として提供できることを理解すべきである。このため、本発明は全体ハードウェア実施例、全体ソフトウェア実施例、又はソフトウェア及びハードウェア様態の実施例を組み合わせる形式を採用できる。且つ、本発明は１つ又は複数のコンピュータ使用可能プログラムコードが含まれたコンピュータ使用可能な記憶媒体（ディスク、メモリ、ＣＤ−ＲＯＭ、光記憶装置等を含むがこれらに限定されない）で実施するコンピュータプログラム製品の形式を採用できる。

【0133】

本発明は、本発明の実施例による方法、設備（システム）、及びコンピュータプログラム製品のフローチャート及び／又はブロック図を参照して記述した。コンピュータプログラム指令でフローチャート及び／又はブロック図における各工程及び／又はブロック、及びフローチャート及び／又はブロック図における工程及び／又はブロックとの組み合わせを実現することを理解すべきである。コンピュータ又はその他のプログラム可能なデータ処理設備のプロセッサにより実行された指令で、フローチャートの１つの工程又は複数の工程及び／又はブロック図の１つのブロック又は複数のブロックに指定された機能を実現するための装置を発生させるように、これらのコンピュータプログラム指令を共用コンピュータ、専用コンピュータ、組み込みプロセッサ又はその他のプログラム可能なデータ処理設備のプロセッサに提供することにより１つの机器を生成する。

【0134】

これらのコンピュータプログラム指令はコンピュータ又はその他のプログラム可能なデータ処理設備は特定形態で作動するコンピュータ読み取り可能な記憶装置に記憶されてもよく、これにより当該コンピュータ読み取り可能な記憶装置に記憶された指令は指令装置を含む製造品を生成し、当該指令装置はフローチャートの１つの工程又は複数の工程及び／又はブロック図１つのブロック又は複数のブロックに指定された機能を実現する。

【0135】

これらのコンピュータプログラム指令もコンピュータ又はその他のプログラム可能なデータ処理設備に載せられてもよく、これによりコンピュータ又はその他のプログラム可能な設備では一連の操作ステップを実行してコンピュータの実現可能な処理を生成することにより、コンピュータ又はその他のプログラム可能な設備で実行された指令はフローチャートの１つの工程又は複数の工程及び／又はブロック図の１つのブロック又は複数のブロックに指定された機能を実現するためのステップを提供する。

【0136】

本発明の好ましい実施例を説明したが、当業者は一旦に基本的な創造的概念を了解すると、これらの実施例に他の変更及び修正を行うことができる。このため、付属する請求の範囲は好ましい実施例を含むとともに本発明の範囲に落ちるすべての変更及び修正と解釈すべきである。

【0137】

明らかに、当業者は本発明に各種の修正及び変形を行うが本発明の精神及び範囲を逸脱しないことができる。このように、本発明のこれらの修正及び変形は本発明の請求の範囲及びその等同技術の範囲に属すると、本発明もこれらの修正及び変形を含むことを意図とする。

【0138】

本出願は２０１５年１月１６日に提出した出願番号が２０１５１００２４５６８．１で発明名称が「ストリームメディアデータ伝送装置、方法及びシステム」の中国の優先出願の優先権を要求し、引用によりそのすべての内容をここに併合する。

【符号の説明】

【0139】

３０１ クライアント
３０２ サーバ
７０１ 第１の処理モジュール
７０２ 第２の処理モジュール
７０３ 第１の送受信モジュール
７０４ 第２の送受信モジュール
８０１ 処理モジュール
８０２ 送受信モジュール

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7A】

【図7B】

【図7C】

【図7D】

【図8】

【図9】

【図10】