特許 7361399 画面キャプチャ方法、端末および記憶媒体

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

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

(11)【特許番号】

(24)【登録日】2023-10-05

(45)【発行日】2023-10-16

(54)【発明の名称】画面キャプチャ方法、端末および記憶媒体

(51)【国際特許分類】

   H04N 21/234 20110101AFI20231006BHJP

   H04N 21/24 20110101ALI20231006BHJP

   A63F 13/49 20140101ALI20231006BHJP

   A63F 13/30 20140101ALI20231006BHJP

【ＦＩ】

H04N21/234

H04N21/24

A63F13/49

A63F13/30

【請求項の数】 10

(21)【出願番号】P 2020560147

(86)(22)【出願日】2018-12-27

(65)【公表番号】

(43)【公表日】2021-08-30

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

(87)【国際公開番号】W WO2019205703

(87)【国際公開日】2019-10-31

【審査請求日】2021-12-24

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

(32)【優先日】2018-04-28

(33)【優先権主張国・地域又は機関】CN

(73)【特許権者】

【識別番号】320010240

【氏名又は名称】ビゴ テクノロジー ピーティーイー． リミテッド

【住所又は居所原語表記】３０ ＰＡＳＩＲ ＰＡＮＪＡＮＧ ＲＯＡＤ，＃１５－３１Ａ，ＭＡＰＬＥＴＲＥＥ ＢＵＳＩＮＥＳＳ ＣＩＴＹ，ＳＩＮＧＡＰＯＲＥ １１７４４０

(74)【代理人】

【識別番号】100108453

【弁理士】

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

(74)【代理人】

【識別番号】100110364

【弁理士】

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

(74)【代理人】

【識別番号】100133400

【弁理士】

【氏名又は名称】阿部 達彦

(72)【発明者】

【氏名】高 盛

(72)【発明者】

【氏名】▲劉▼ ▲麗▼

(72)【発明者】

【氏名】▲馬▼ ▲躍▼

(72)【発明者】

【氏名】成 家雄

(72)【発明者】

【氏名】同 ▲シン▼

(72)【発明者】

【氏名】▲馬▼ 杰波

【審査官】鈴木 順三

(56)【参考文献】

【文献】特表２００８－５３２６８７（ＪＰ，Ａ）

【文献】特開２００９－１８７０８１（ＪＰ，Ａ）

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

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

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

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

Ａ６３Ｆ １３／００ － １３／９８

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

【請求項1】

実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されることと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、
第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む、
ことを特徴とする画面キャプチャ方法。

【請求項2】

前記第１のキャプチャポリシーまたは前記第２のキャプチャポリシーによってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む、
ことを特徴とする請求項１に記載の方法。

【請求項3】

前記第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定することと、
確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含み、
前記プリセット画面は、アプリケーションによって出力された画面である、
ことを特徴とする請求項１に記載の方法。

【請求項4】

前記第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面を同時にキャプチャすることと、
前記第１の時間閾値の範囲内で、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされた場合、前記第２のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第１のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止し、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされない場合、前記第１のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止することと、
を含む、
ことを特徴とする請求項１に記載の方法。

【請求項5】

前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャする前に、
前記第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む、
ことを特徴とする請求項４に記載の方法。

【請求項6】

前記第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットすることをさらに含む、
ことを特徴とする請求項４または５に記載の方法。

【請求項7】

前記第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み、
前記第２のキャプチャ方式は、ゲームキャプチャを含む、
ことを特徴とする請求項４または５に記載の方法。

【請求項8】

実行された第１のアプリケーションに関連する第１の情報を検出するために使用される検出ユニットと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャするために使用されるキャプチャユニットと、
を含み、
前記第１の情報は、前記第１のアプリケーションの属性を表すために使用され、
前記キャプチャユニットは、前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャするためにも使用される、
ことを特徴とする端末。

【請求項9】

プロセッサおよびメモリを含み、前記メモリは、アプリケーションコードを記憶するために使用され、前記プロセッサは、前記アプリケーションコードを呼び出すことにより、以下の方法を実行するように構成され、即ち、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されること、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすること、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることである、
ことを特徴とする端末。

【請求項10】

コンピュータプログラムが記憶されたコンピュータ可読記憶媒体であって、
前記コンピュータプログラムは、プログラム指令を含み、前記プログラム指令は、プロセッサによって実行されるとき、請求項１から７のいずれか１項に記載の方法を前記プロセッサに実行させる、
ことを特徴とするコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、２０１８年１２月２７日に出願された出願番号ＰＣＴ/ＣＮ２０１８/１２４５０６の国際出願の国家段階であり、２０１８年０４月２８日に出願された出願番号２０１８１０４１２０６９.３、発明の名称「画面キャプチャ方法および端末」の中国特許出願の優先権を主張し、その全ての内容は参照により本明細書に援用する。

【0002】

本発明はビデオ処理技術の分野に属し、特に画面キャプチャ方法、端末および記憶媒体に関するものである。

【背景技術】

【0003】

動画ライブ配信ブームの高まりに伴い、ゲームのライブ配信を行うプラットフォームもますます多くなり、ライブ配信されたほとんどのゲームはＷｉｎｄｏｗｓ（登録商標）プラットフォームに基づいたものであり、１つのゲームをライブ配信するには、まずゲームの画面をキャプチャし、次に動画ストリームにエンコードして、ある方式でライブ配信プラットフォームのサーバにプッシュする必要がある。ただし、現在多くのゲームのライブ配信プラットフォームは、オープン・ブロードキャスター・ソフトウェア（Ｏｐｅｎ Ｂｒｏａｄｃａｓｔｅｒ Ｓｏｆｔｗａｒｅ、ＯＢＳ）を使って上記の機能を完成する。

【0004】

しかしながら、ＯＢＳの利用は容易ではなく、１つのゲームをライブ配信する設定方式は複雑である。例えば、ＯＢＳは、ゲーム画面をキャプチャするための３つの設定方式を提供し、ＯＢＳを使用してゲーム画面をキャプチャしたばかりのユーザは、どのキャプチャ方式を選択すべきか分からず、キャプチャ方式が誤って選択されると、ゲーム画面をキャプチャすることができないため、ライブ配信中にブラックスクリーン問題を発生させる可能性があり、ユーザの体験がよくない場合がある。

【発明の概要】

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

【0005】

本発明は、画面のキャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、ライブ配信中にブラックスクリーン問題が発生しないようにする画面キャプチャ方法、端末および記憶媒体を提供する。

【0006】

第１の側面において、本発明は、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されることと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む、
画面キャプチャ方法に関する。

【0007】

第１の側面に関して、いくつかの可能な実施例において、
前記第１のキャプチャポリシーまたは前記第２のキャプチャポリシーによってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。

【0008】

第１の側面に関して、いくつかの可能な実施例において、前記第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定することと、
確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む。

【0009】

第１の側面に関して、いくつかの可能な実施例において、前記第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面を同時にキャプチャすることと、
前記第１の時間閾値の範囲内で、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされた場合、前記第２のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第１のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止し、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされない場合、前記第１のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止することと、
を含む。

【0010】

第１の側面に関して、いくつかの可能な実施例において、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャする前に、
前記第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。

【0011】

第１の側面に関して、いくつかの可能な実施例において、
前記第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットすることをさらに含む。

【0012】

第１の側面に関して、いくつかの可能な実施例において、前記第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み、
前記第２のキャプチャ方式は、ゲームキャプチャを含む。

【0013】

第２の側面において、本発明は、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用される検出ユニットと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャするために使用されるキャプチャユニットと、
を含み、
前記キャプチャユニットは、前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャするためにも使用される、
端末に関する。

【0014】

第２の側面に関して、いくつかの可能な実施例において、当該端末は、
上述した前記第１のキャプチャ方式または前記第２のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されるエンコードユニットと、
エンコードユニットによってエンコードされた第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用される送信ユニットと、
をさらに含む。

【0015】

本発明では、当該サーバは、ライブ配信プラットフォームサーバーであってもよい。

【0016】

エンコードユニットは、上述した第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャする前に、第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されてもよい。

【0017】

送信ユニットは、上述したエンコードユニットによってエンコードされた第１のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用されてもよい。

【0018】

第２の側面に関して、いくつかの可能な実施例において、当該端末は、
第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットするリセットユニットをさらに含む。

【0019】

第３の側面において、本発明は、プロセッサおよびメモリを含み、前記メモリは、アプリケーションコードを記憶するために使用され、前記プロセッサは、前記アプリケーションコードを呼び出すことにより、以下の方法を実行するように構成され、即ち、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されること、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすること、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることである、端末に関する。

【0020】

第４の側面において、本発明は、コンピュータプログラムが記憶されたコンピュータ可読記憶媒体であって、前記コンピュータプログラムは、プログラム指令を含み、前記プログラム指令は、プロセッサによって実行されるとき、上記の第１の側面に記載された方法を前記プロセッサに実行させるコンピュータ可読記憶媒体に関する。

【0021】

第５の側面において、本発明は、画面キャプチャ指令を含むコンピュータプログラムであって、当該コンピュータプログラムがコンピュータ上で実行されるとき、上述した画面捕捉指令は、上記の第１の側面に記載された画面キャプチャ方法を実行するために使用されるコンピュータプログラムに関する。

【0022】

本発明は、画面キャプチャ方法および端末に関する。まず、実行された第１のアプリケーションに関連する第１の情報を検出し、第１の情報は、第１のアプリケーションの属性を表すために使用される。次に、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、第１のデータベースは、アプリケーションの名称と、当該アプリケーションによって出力された画面に関連するキャプチャ方式とを含む。最後に、存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。本発明を採用することにより、キャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、ライブ配信中にブラックスクリーン問題が発生しないようにする。したがって、本発明を採用することにより、ユーザ体験を大幅に向上させることができる。

【図面の簡単な説明】

【0023】

【図1】本発明による画面キャプチャ方法の概略フローチャートである。

【図2】本発明によるウィンドウキャプチャ方式によって、ＧＤＩレンダリング技術を使用してレンダリングされた画像をキャプチャする概略フローチャートである。

【図3】本発明による第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする概略フローチャートである。

【図4】本発明による第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする概略フローチャートである。

【図5】本発明による端末の概略ブロック図である。

【図6】本発明による別の端末の概略ブロック図である。

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

【0024】

以下、本発明の技術案について、本発明の図面を参照して明確かつ完全に説明し、説明された実施例は、全ての実施例ではなく、本発明の実施例の一部であることは明らかである。本発明の実施例に基づいて、当業者が創造的な労働をしないことを前提として取得された他のすべての実施例は、本発明の保護の範囲に属する。

【0025】

本明細書および添付の特許請求の範囲で使用される場合、「含む」および「含有する」という用語は、説明された特徴、全体、ステップ、動作、要素および／またはコンポーネントの存在を示すが、１つ以上の他の特徴、全体、ステップ、動作、要素、コンポーネントおよび／またはそのセットの存在または追加を排除しないことを理解すべきである。

【0026】

ここで、本発明の明細書で使用される用語は、特定の実施例を説明することのみを目的とし、本発明を限定するものではないことも理解すべきである。本発明の明細書および添付の特許請求の範囲で使用されるように、他の状況が文脈で明示されない限り、単数形の「１」、「１つ」および「当該」は、複数形を含むことが意図される。

【0027】

本発明の明細書および添付の特許請求の範囲で使用される「および／または」という用語は、関連付けられた項目のうちの１つまたは複数の任意の組み合わせおよび可能なすべての組み合わせを意味し、これらの組み合わせを含むことをさらに理解すべきである。

【0028】

本明細書および添付の特許請求の範囲で使用されるように、「場合」という用語は、文脈に応じて「…とき」、「一度」、「確定に応答する」または「検出に応答する」と解釈することができる。同様に、「確定した場合」または「「記述された条件またはイベント」が検出された場合」という句は、文脈に応じて「一度確定した」、「確定に応答する」、「一度「記述された条件またはイベント」が検出された」または「「記述された条件またはイベント」が検出されたことに応答する」を意味すると解釈することができる。

【0029】

具体的には、本発明で説明された端末は、タッチセンシティブ表面（例えば、タッチパネルディスプレイおよび／またはタッチパネル）を有する携帯電話、ラップトップコンピュータまたはタブレットコンピュータなどの他の携帯機器を含むが、これらに限定されない。また、いくつかの実施例では、前記機器は、携帯通信機器ではなく、タッチセンシティブ表面（例えば、タッチパネルディスプレイおよび／またはタッチパッド）を有するデスクトップコンピュータであることも理解すべきである。

【0030】

以下の議論では、ディスプレイおよびタッチセンシティブ表面を含む端末を説明する。しかしながら、端末は、物理キーボード、マウスおよび／またはジョイスティックなどの１つまたは複数の他の物理的ユーザインターフェースデバイスを含むことができることを理解すべきである。

【0031】

端末は、様々なアプリケーションをサポートし、例えば、図形描画アプリケーション、デモンストレーションアプリケーション、文字処理アプリケーション、ウェブサイト作成アプリケーション、ディスク書き込みアプリケーション、スプレッドシートアプリケーション、ゲームアプリケーション、電話アプリケーション、ビデオ会議アプリケーション、電子メールアプリケーション、インスタントメッセージングアプリケーション、運動サポートアプリケーション、写真管理アプリケーション、デジタルカメラアプリケーション、デジタルビデオカメラアプリケーション、ｗｅｂ（ウェブ）ブラウズアプリケーション、デジタル音楽プレーヤーアプリケーションおよび/またはデジタルビデオプレーヤーアプリケーションのうちの１つまたは複数をサポートする。

【0032】

端末上で実行可能な様々なアプリケーションは、タッチセンシティブ表面ような少なくとも１つの共通の物理ユーザインターフェースデバイスを使用することができる。タッチセンシティブ表面の１つまたは複数の機能および端末に表示された対応する情報は、アプリケーション間および／または対応するアプリケーション内で調整および／または変更されることができる。このように、端末の共通の物理的アーキテクチャ(例えば、タッチセンシティブ表面)は、ユーザにとって直観的かつ透明なユーザインターフェースを有する様々なアプリケーションをサポートすることができる。

【0033】

図１を参照すると、本発明による画面キャプチャ方法の概略フローチャートであり、図１に示すように、当該方法は、以下のステップを含むが、これらに限定されない。

【0034】

ステップＳ１０１において、実行された第１のアプリケーションに関連する第１の情報を検出し、第１の情報は、第１のアプリケーションの属性を表すために使用される。

【0035】

本発明では、第１のアプリケーションは、ゲームアプリケーション、動画アプリケーション、またはテキストアプリケーションなどを含み得るが、これらに限定されない。本発明の実施例における第１の情報は、第１のアプリケーションの名前、開発者、リリース時間、バージョン番号、使用の説明、連絡先情報または連絡先アドレスなどを含み得るが、これらに限定されない。つまり、本発明の実施例における第１のアプリケーションの属性は、第１のアプリケーションの名前、開発者、またはリリース時間などであってもよい。

【0036】

例えば、第１のアプリケーションがゲームアプリケーションである場合、第１の情報は、当該ゲームアプリケーションの名称（「リーグ・オブ・レジェンド」、「Ａｎｇｒｙ Ｂｉｒｄｓ」、「Ｓｕｐｅｒ Ｍａｒｉｏ Ｒｕｎ」、「Ｆｒｕｉｔ Ｎｉｎｊａ」、または「Ｒｕｌｅｓ ｏｆ Ｓｕｒｖｉｖａｌ」）、開発者、バージョン番号、リリース時間、または連絡先などを含み得るが、これらに限定されない。

【0037】

ゲームアプリケーションが「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」アプリケーションであることを例にとると、第１の情報は、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」アプリケーションの中国語名称「リーグ・オブ・レジェンド」、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」の開発者（Ｒｉｏｔ Ｇａｍｅｓ）、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」のリリース時間（２０１１年９月２２日）などを含む。

【0038】

ステップＳ１０２において、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面をキャプチャする。

【0039】

ステップＳ１０３において、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。

【0040】

選択肢の一つとして、第１のアプリケーションに関連する第１の情報を取得した後、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断することができ、ここで、第１のデータベースは、アプリケーションに関連する第１の情報と、当該アプリケーションによって出力された画面に関連するキャプチャ方式とを含む。

【0041】

本発明では、第１のデータベースを記憶することは、以下の２つの方式を含むことができるが、これらに限定されない。

【0042】

第１の方式として、第１のデータベースを端末ローカルに記憶する。

【0043】

第２の方式として、第１のデータベースを端末ローカルに接続されたクラウドサーバーに記憶する。

【0044】

なお、記録された各アプリケーション（例えばゲームアプリケーション）によって出力された各画面を成功にキャプチャしたことに対応するキャプチャ方式に基づいて、第１のデータベースを作成することができ、ここで、異なる画面は、異なるキャプチャ方式に対応する。

【0045】

具体的に、第１のアプリケーションに関連する第１の情報を第１のデータベースにおけるデータと比較することによって、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断することができる。

【0046】

なお、アプリケーションによって出力された画面は、以下の２つのモードを含むことができるが、これらに限定されない。

【0047】

第１のモードは、ウィンドウモードであり、
第２のモードは、フルスクリーンモードである。

【0048】

アプリケーションによって出力された画面に関連するキャプチャモードは、ウィンドウキャプチャモード、ディスプレイキャプチャモード、またはゲームキャプチャモードを含み得るが、これらに限定されない。

【0049】

なお、異なるレンダリング技術（例えば、ＧＤＩ（Ｇｒａｐｈｉｃｓ Ｄｅｖｉｃｅ Ｉｎｔｅｒｆａｃｅ、グラフィックス・デバイス・インターフェース）、Ｄ３Ｄ（Ｄｉｒｅｃｔ３Ｄ、３Ｄアクセラレータ）、ＤＤｒａｗ（ＤｉｒｅｃｔＤｒａｗ）またはＯｐｅｎＧＬ（Ｏｐｅｎ Ｇｒａｐｈｉｃｓ Ｌｉｂｒａｒｙ、オープンジーエル））でレンダリング（描画）された画面は、異なるキャプチャ方式に対応することができる。

【0050】

例えば、ウィンドウキャプチャとディスプレイキャプチャは、ＧＤＩレンダリングテクノロジーを使用してレンダリングされた画面をキャプチャすることができる。

【0051】

ウィンドウキャプチャ方式でＧＤＩレンダリングテクノロジーによってレンダリングされた画面をキャプチャすることを例にとると、図２に示すように、具体的には以下のステップを含み得るが、これらに限定されない。

【0052】

ステップＳ１１において、関数ＧｅｔＤＣ(ｈｗｎｄ)を介して、指定されたウィンドウのデバイスコンテキストの環境を取得することができ、ここで、ｈｗｎｄは、指定されたウィンドウのハンドルを表すために使用され、つまり、ｈｗｎｄは、ウィンドウの属性（アイデンティティ）を表すために使用され、なお、当該デバイスコンテキストの環境には、当該ウィンドウのウィンドウテクスチャが保存されている。

【0053】

ステップＳ１２において、関数ＢｉｔＢｉｔ（）を介して前述のウィンドウのデバイスコンテキストの環境内のウィンドウテクスチャをコピーすることによって、ＧＤＩレンダリングテクノロジーによってレンダリングされたウィンドウ画面のキャプチャを実現できる。

【0054】

ディスプレイキャプチャ方式は、ＧＤＩレンダリングテクノロジーによってレンダリングされた画面をキャプチャし、実現方式は、ウィンドウキャプチャ方式によるＧＤＩレンダリングテクノロジーによってレンダリングされた画面のキャプチャと同様であり、ここで、関数ＧｅｔＤＣ(ｈｗｎｄ)のハンドルｈｗｎｄは、ＮＵＬＬに設定する必要があり、つまり、ディスプレイキャプチャモードは、関数ＧｅｔＤＣ(ＮＵＬＬ)関数を介して、ＧＤＩテクノロジによってレンダリングされたフルスクリーン画面のキャプチャを実現できる。

【0055】

ゲームキャプチャは、Ｄ３Ｄ、ＤＤｒａｗまたはＯｐｅｎＧＬなどのレンダリングテクノロジーを使用してレンダリングされた画像をキャプチャすることができる。

【0056】

Ｄ３Ｄレンダリングテクノロジーによってレンダリングされた画面をゲームキャプチャ方式でキャプチャすることを例とする。

【0057】

具体的には、ＨＯＯＫアプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ、ＡＰＩ）を介して、Ｄ３Ｄテクノロジを使用してレンダリングされた画面のキャプチャを実現することができる。

【0058】

以下、ゲームキャプチャ方式でＤ３Ｄレンダリングテクノロジーによりレンダリングされた画面をキャプチャするプロセスを詳しく説明する。

【0059】

なお、Ｄ３Ｄレンダリングテクノロジーを使用して画面をレンダリングする場合、ｐｒｅｓｅｎｔ（）関数を呼び出す必要がある。

【0060】

具体的なプロセスとして、第１のピクチャ取得関数をｐｒｅｓｅｎｔ（）関数に置き換え、Ｄ３Ｄレンダリングテクノロジーを使用して毎回ｐｒｅｓｅｎｔ（）関数を呼び出して画面をレンダリングする場合、毎回第１のピクチャ取得関数を呼び出すことによって、画面のキャプチャを実現する。ここで、第１のピクチャ取得関数は、バックバッファピクチャ（表示されようとするピクチャ）を取得するために使用されている。

【0061】

また、第１のピクチャ取得関数が画面のキャプチャを実現した後、再度ｐｒｅｓｅｎｔ（）関数を呼び出してフロント・バックバッファピクチャの交換を実現し(画面のレンダリングを実現し)、ここで、ｐｒｅｓｅｎｔ（）関数は、フロントバッファピクチャ（表示中のピクチャ）とバックバッファピクチャ（表示されようとするピクチャ）を交換するために使用されている。

【0062】

なお、ゲームキャプチャは、一定の不安定性を持っている。ゲームがＨＯＯＫアプリケーションプログラミングインターフェース（ＡＰＩ）をキャプチャするためには、ローカルな管理者権限を取得する必要があるため、管理者権限を取得できない場合、ゲームは第１のアプリケーションによって出力された画面をキャプチャすることができない。

【0063】

本発明では、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。

【0064】

本発明では、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面をキャプチャし、図３に示すように、ステップ１０２は、以下のステップを含み得るが、これらに限定されない。

【0065】

ステップＳ２１において、前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定する。

【0066】

以下、表１を参照して第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係を詳しく説明する。

【0067】

【表1】

【0068】

ここで、０は、どのような適切なキャプチャ方式（ウィンドウキャプチャ、ウィンドウキャプチャ方式且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定すること、またはゲームキャプチャ）を採用するかを自動的に検出することを表し、１は、ウィンドウキャプチャ方式を強制的に採用し、且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定することを表し、２は、ウィンドウキャプチャ方式を強制的に採用することを表し、３は、ゲームキャプチャを強制的に採用することを表す。

【0069】

表１を参照すると、ゲーム名称が「リーグ・オブ・レジェンド」であるゲームアプリケーションを例にとし、当該ゲームアプリケーションは、以下の３つのプロセスを含み得るが、これらに限定されない。

【0070】

プロセス１として、ゲーム登録プロセス（Ｃｌｉｅｎｔ）である。

【0071】

プロセス２として、ＰＶＰ.Ｎｅｔクライアントオープンプロセス（ＬｏｌＣｌｉｅｎｔ）である。

【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】

当業者は、説明の便宜および簡略化のために、上述の端末およびユニットの具体的な作動プロセスについては、前述の方法の実施例における対応するプロセスを参照できることを明確に理解でき、ここでは説明を省略する。

【0140】

本発明によるいくつかの実施例において、開示された端末および方法は、他の方式で実現されうることが理解すべきである。例えば、各例の構成およびステップを説明した。これらの機能がハードウェアで実行されるかソフトウェアで実行されるかは、技術案の特定の応用および設計制約条件に依存する。専門技術者は、特定の応用ごとに、異なる方法を使用することによって、説明された機能を実現することができるが、このような実現は、本発明の範囲を超えていると考えてはならない。

【0141】

以上で説明された端末の実施例は単なる例示であり、例えば、前記ユニットの分割は、論理的な機能の分割にすぎず、実際に実現するときに、他の分割方式が存在する場合があり、例えば、複数のユニットまたはコンポーネントを組み合わせたり、別のシステムに統合したり、いくつかの特徴を無視したり実行しないことができる。また、表示または説明される相互間のカップリングまたは直接カップリングまたは通信接続は、いくつかのインターフェース、端末またはユニットを介した間接カップリングまたは通信接続であってもよいし、電気的、機械的、または他の形で接続されてもよい。

【0142】

前記分離コンポーネントとして説明されたユニットは、物理的に分離されてもよいし、物理的に分離されていなくてもよいし、ユニットとして表示されたコンポーネントは、物理ユニットであってもよいし、物理ユニットでなくてもよいし、１つの場所に配置されてもよいし、複数のネットワークユニットに分散されてもよい。本発明の実施例の目的は、実際の必要に応じて、そのうちの一部または全部のユニットを選択することによって達成されることができる。

【0143】

また、本発明の各実施例における各機能ユニットが１つの処理ユニットに統合されてもよいし、各ユニットが物理的に単独で存在してもよいし、２つ以上のユニットが１つのユニットに統合されてもよい。上述した統合されたユニットは、ハードウェアの形で実現されてもよいし、ソフトウェア機能ユニットの形で実現されてもよい。

【0144】

上述した統合されたユニットがソフトウェア機能ユニットの形で実現され、且つ独立した製品として販売されたり、使用されたりする場合には、１つのコンピュータ可読記憶媒体に記憶されてもよい。このような理解に基づいて、本発明に記載された技術案に関し、本質的に、従来技術に貢献する部分、または当該技術案の全部または一部は、ソフトウェア製品の形で具現化されることができ、当該コンピュータソフトウェア製品は、１つの記憶媒体に記憶され、本発明の各実施例で説明された方法のステップのすべてまたは一部を１台のコンピュータデバイス（パーソナルコンピュータ、サーバ、またはネットワークデバイスなどであり得る）に実行させる若干の指令を含む。また、上述した記憶媒体は、Ｕディスク、リムーバブルハードディスク、読み取り専用メモリ（Ｒｅａｄ－Ｏｎｌｙ Ｍｅｍｏｒｙ、ＲＯＭ)、ランダムアクセスメモリ(Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ＲＡＭ)、磁気ディスク、光ディスクなど、プログラムコードを記憶することができる種々の媒体を含む。

【0145】

上記の説明は、本発明の具体的な実施例に過ぎないが、本発明の保護範囲はこれに限定されず、本技術分野に詳しい任意の技術者は、本発明で開示された技術の範囲内で、様々な等価的な修正または置換を容易に想到し、これら修正または置換は、本発明の保護範囲内に含まれるべきである。したがって、本発明の保護範囲は、請求項の保護範囲に準じるべきである。

【符号の説明】

【0146】

201 検出ユニット
202 判断ユニット
203 キャプチャユニット
301 ベースバンドチップ
302 メモリ
303 周辺システム
305 プロセッサ（ＣＰＵ）
306 グラフィックプロセッサ（ＧＰＵ）
307 ディスプレイコントローラ
308 カメラコントローラ
309 マウス・キーボードコントローラ
310 オーディオコントローラ
311 ディスプレイ（フローティングタッチ）
312 カメラ（例えば３Ｄカメラ）
313 マウス・キーボード
314 オーディオ回路

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】