(57)【要約】  画面キャプチャ方法、端末および記憶媒体を開示する。  方法は、実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されることと、第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることと、前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることと、を含む。
2021522721.tif 000002
【特許請求の範囲】
【請求項１】
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されることと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在するかどうかを判断することと、
存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む、
ことを特徴とする画面キャプチャ方法。
【請求項２】
第１のキャプチャポリシーまたは第２のキャプチャポリシーによってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定することと、
確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を具体的に含む、
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面を同時にキャプチャすることと、
前記第１の時間閾値の範囲内で、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャした場合、前記第２のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、同時に、前記第１のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止し、さもなければ、前記第１のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、同時に、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止することと、
を具体的に含む、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャする前に、
前記第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む、
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットすることをさらに含む、
ことを特徴とする請求項４または５に記載の方法。
【請求項７】
前記第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み、
前記第２のキャプチャ方式は、ゲームキャプチャを含む、
ことを特徴とする請求項４または５に記載の方法。
【請求項８】
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用される検出ユニットと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、前記第１のデータベースは、アプリケーションに関連する第１の情報と、前記アプリケーションによって出力された画面に関連するキャプチャ方式を含む判断ユニットと、
存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャするキャプチャユニットと、
を含む、
ことを特徴とする端末。
【請求項９】
プロセッサ、入力デバイス、出力デバイス、およびメモリを含み、前記プロセッサ、入力デバイス、出力デバイス、メモリは、互いに接続され、ここで、前記メモリは、アプリケーションコードを記憶するために使用され、前記プロセッサは、プログラムコードを呼び出し、請求項１から７のいずれか１項に記載の方法を実行するように構成されている、
ことを特徴とする端末。
【請求項１０】
コンピュータプログラムが記憶されたコンピュータ記憶媒体であって、
前記コンピュータプログラムは、プログラム指令を含み、前記プログラム指令は、プロセッサによって実行されるとき、請求項１から７のいずれか１項に記載の方法を前記プロセッサに実行させる、
ことを特徴とするコンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２０１８年０４月２８日に中国特許庁に提出された出願番号２０１８１０４１２０６９.３、発明の名称「画面キャプチャ方法および端末」の中国特許出願の優先権を主張し、その全ての内容は参照により本明細書に援用する。
【０００２】
本発明はビデオ処理技術の分野に属し、特に画面キャプチャ方法および端末に関するものである。
【背景技術】
【０００３】
動画ライブ配信ブームの高まりに伴い、ゲームのライブ配信を行うプラットフォームもますます多くなり、ライブ配信されたほとんどのゲームはＷｉｎｄｏｗｓ（登録商標）プラットフォームに基づいたものであり、１つのゲームをライブ配信するには、まずゲームの画面をキャプチャし、次に動画ストリームにエンコードして、ある方式でライブ配信プラットフォームのサーバにプッシュする必要がある。ただし、現在多くのゲームのライブ配信プラットフォームは、オープン・ブロードキャスター・ソフトウェア（Ｏｐｅｎ  Ｂｒｏａｄｃａｓｔｅｒ  Ｓｏｆｔｗａｒｅ、ＯＢＳ）を使って上記の機能を完成する。
【０００４】
しかしながら、ＯＢＳの利用は容易ではなく、１つのゲームをライブ配信する設定方式は複雑である。例えば、ＯＢＳは、ゲーム画面をキャプチャするための３つの設定方式を提供し、ＯＢＳを使用してゲーム画面をキャプチャしたばかりのユーザは、どのキャプチャ方式を選択すべきか分からず、キャプチャ方式が誤って選択されると、ゲーム画面をキャプチャすることができないため、ライブ配信中にブラックスクリーン問題を発生させる可能性があり、ユーザの体験がよくない場合がある。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明は、画面のキャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、ライブ配信中にブラックスクリーン問題が発生しないようにする画面キャプチャ方法および端末を提供する。
【０００６】
第１の側面において、本発明は、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されることと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、前記第１のデータベースは、アプリケーションに関連する第１の情報と、前記アプリケーションによって出力された画面に関連するキャプチャ方式とを含むことと、
存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む、
画面キャプチャ方法に関する。
【０００７】
第１の側面に関して、いくつかの可能な実施例において、
キャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。
【０００８】
第１の側面に関して、いくつかの可能な実施例において、前記第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定することと、
確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を具体的に含む。
【０００９】
第１の側面に関して、いくつかの可能な実施例において、前記第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面を同時にキャプチャすることと、
前記第１の時間閾値の範囲内で、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャした場合、前記第２のキャプチャ方式を採用して、前記第１のアプリケーションによって出力された画面をキャプチャし、同時に、前記第１のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止し、さもなければ、前記第１のキャプチャ方式を採用して、前記第１のアプリケーションによって出力された画面をキャプチャし、同時に、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止することと、
を具体的に含む。
【００１０】
第１の側面に関して、いくつかの可能な実施例において、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャする前に、
前記第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。
【００１１】
第１の側面に関して、いくつかの可能な実施例において、
前記第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットすることをさらに含む。
【００１２】
第１の側面に関して、いくつかの可能な実施例において、前記第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み、
前記第２のキャプチャ方式は、ゲームキャプチャを含む。
【００１３】
第２の側面において、本発明は、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用される検出ユニットと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、前記第１のデータベースは、アプリケーションに関連する第１の情報と、前記アプリケーションによって出力された画面に関連するキャプチャ方式を含む判断ユニットと、
存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャするキャプチャユニットと、
を含む、
端末に関する。
【００１４】
第２の側面に関して、いくつかの可能な実施例において、当該端末は、
上述した第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されるエンコードユニットと、
エンコードユニットによってエンコードされた第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用される送信ユニットと、
をさらに含む。
【００１５】
本発明では、当該サーバは、ライブ配信プラットフォームサーバーであってもよい。
【００１６】
エンコードユニットは、上述した第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャする前に、第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されてもよい。
【００１７】
送信ユニットは、上述したエンコードユニットによってエンコードされた第１のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用されてもよい。
【００１８】
第２の側面に関して、いくつかの可能な実施例において、当該端末は、
第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットするリセットユニットをさらに含む。
【００１９】
第３の側面において、本発明は、プロセッサ、入力デバイス、出力デバイス、およびメモリを含み、前記プロセッサ、入力デバイス、出力デバイス、メモリは、互いに接続され、ここで、前記メモリは、端末が上記の方法を実行するのをサポートするアプリケーションコードを記憶するために使用され、前記プロセッサは、上記の第１の側面に記載された方法を実行するように構成されている別の端末に関する。
【００２０】
第４の側面において、本発明は、コンピュータプログラムが記憶されたコンピュータ記憶媒体であって、前記コンピュータプログラムは、プログラム指令を含み、前記プログラム指令は、プロセッサによって実行されるとき、上記の第１の側面に記載された方法を前記プロセッサに実行させるコンピュータ可読記憶媒体に関する。
【００２１】
第５の側面において、本発明は、画面キャプチャ指令を含むコンピュータプログラムであって、当該コンピュータプログラムがコンピュータ上で実行されるとき、上述した画面捕捉指令は、上記の第１の側面に記載された画面キャプチャ方法を実行するために使用されるコンピュータプログラムに関する。
【００２２】
本発明は、画面キャプチャ方法および端末に関する。まず、実行された第１のアプリケーションに関連する第１の情報を検出し、第１の情報は、第１のアプリケーションの属性を表すために使用される。次に、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、第１のデータベースは、アプリケーションの名称と、当該アプリケーションによって出力された画面に関連するキャプチャ方式とを含む。最後に、存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。本発明を採用することにより、キャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、ライブ配信中にブラックスクリーン問題が発生しないようにする。したがって、本発明を採用することにより、ユーザ体験を大幅に向上させることができる。
【図面の簡単な説明】
【００２３】
【図１】本発明による画面キャプチャ方法の概略フローチャートである。
【図１Ａ】本発明によるウィンドウキャプチャ方式によって、ＧＤＩレンダリング技術を使用してレンダリングされた画像をキャプチャする概略フローチャートである。
【図１Ｂ】本発明による第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする概略フローチャートである。
【図１Ｃ】本発明による第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする概略フローチャートである。
【図２】本発明による端末の概略ブロック図である。
【図３】本発明による別の端末の概略ブロック図である。
【発明を実施するための形態】
【００２４】
以下、本発明の技術案について、本発明の図面を参照して明確かつ完全に説明し、説明された実施例は、全ての実施例ではなく、本発明の実施例の一部であることは明らかである。本発明の実施例に基づいて、当業者が創造的な労働をしないことを前提として取得された他のすべての実施例は、本発明の保護の範囲に属する。
【００２５】
本明細書および添付の特許請求の範囲で使用される場合、「含む」および「含有する」という用語は、説明された特徴、全体、ステップ、動作、要素および／またはコンポーネントの存在を示すが、１つ以上の他の特徴、全体、ステップ、動作、要素、コンポーネントおよび／またはそのセットの存在または追加を排除しないことを理解すべきである。
【００２６】
ここで、本発明の明細書で使用される用語は、特定の実施例を説明することのみを目的とし、本発明を限定するものではないことも理解すべきである。本発明の明細書および添付の特許請求の範囲で使用されるように、他の状況が文脈で明示されない限り、単数形の「１」、「１つ」および「当該」は、複数形を含むことが意図される。
【００２７】
本発明の明細書および添付の特許請求の範囲で使用される「および／または」という用語は、関連付けられた項目のうちの１つまたは複数の任意の組み合わせおよび可能なすべての組み合わせを意味し、これらの組み合わせを含むことをさらに理解すべきである。
【００２８】
本明細書および添付の特許請求の範囲で使用されるように、「場合」という用語は、文脈に応じて「…とき」、「一度」、「確定に応答する」または「検出に応答する」と解釈することができる。同様に、「確定した場合」または「「記述された条件またはイベント」が検出された場合」という句は、文脈に応じて「一度確定した」、「確定に応答する」、「一度「記述された条件またはイベント」が検出された」または「「記述された条件またはイベント」が検出されたことに応答する」を意味すると解釈することができる。
【００２９】
具体的には、本発明で説明された端末は、タッチセンシティブ表面（例えば、タッチパネルディスプレイおよび／またはタッチパネル）を有する携帯電話、ラップトップコンピュータまたはタブレットコンピュータなどの他の携帯機器を含むが、これらに限定されない。また、いくつかの実施例では、前記機器は、携帯通信機器ではなく、タッチセンシティブ表面（例えば、タッチパネルディスプレイおよび／またはタッチパッド）を有するデスクトップコンピュータであることも理解すべきである。
【００３０】
以下の議論では、ディスプレイおよびタッチセンシティブ表面を含む端末を説明する。しかしながら、端末は、物理キーボード、マウスおよび／またはジョイスティックなどの１つまたは複数の他の物理的ユーザインターフェースデバイスを含むことができることを理解すべきである。
【００３１】
端末は、様々なアプリケーションをサポートし、例えば、図形描画アプリケーション、デモンストレーションアプリケーション、文字処理アプリケーション、ウェブサイト作成アプリケーション、ディスク書き込みアプリケーション、スプレッドシートアプリケーション、ゲームアプリケーション、電話アプリケーション、ビデオ会議アプリケーション、電子メールアプリケーション、インスタントメッセージングアプリケーション、運動サポートアプリケーション、写真管理アプリケーション、デジタルカメラアプリケーション、デジタルビデオカメラアプリケーション、ウェブブラウズアプリケーション、デジタル音楽プレーヤーアプリケーションおよび/またはデジタルビデオプレーヤーアプリケーションのうちの１つまたは複数をサポートする。
【００３２】
端末上で実行可能な様々なアプリケーションは、タッチセンシティブ表面ような少なくとも１つの共通の物理ユーザインターフェースデバイスを使用することができる。タッチセンシティブ表面の１つまたは複数の機能および端末に表示された対応する情報は、アプリケーション間および／または対応するアプリケーション内で調整および／または変更されることができる。このように、端末の共通の物理的アーキテクチャ(例えば、タッチセンシティブ表面)は、ユーザにとって直観的かつ透明なユーザインターフェースを有する様々なアプリケーションをサポートすることができる。
【００３３】
図１を参照すると、本発明による画面キャプチャ方法の概略フローチャートであり、図１に示すように、当該方法は、以下のステップを含むが、これらに限定されない。
【００３４】
ステップＳ１０１において、実行された第１のアプリケーションに関連する第１の情報を検出し、第１の情報は、第１のアプリケーションの属性を表すために使用される。
【００３５】
本発明では、第１のアプリケーションは、ゲームアプリケーション、動画アプリケーション、またはテキストアプリケーションなどを含み得るが、これらに限定されない。本発明の実施例における第１の情報は、第１のアプリケーションの名前、開発者、リリース時間、バージョン番号、使用の説明、連絡先情報または連絡先アドレスなどを含み得るが、これらに限定されない。つまり、本発明の実施例における第１のアプリケーションの属性は、第１のアプリケーションの名前、開発者、またはリリース時間などであってもよい。
【００３６】
例えば、第１のアプリケーションがゲームアプリケーションである場合、第１の情報は、当該ゲームアプリケーションの名称（「リーグ・オブ・レジェンド」、「Ａｎｇｒｙ Ｂｉｒｄｓ」、「Ｓｕｐｅｒ Ｍａｒｉｏ Ｒｕｎ」、「Ｆｒｕｉｔ Ｎｉｎｊａ」、または「Ｒｕｌｅｓ ｏｆ Ｓｕｒｖｉｖａｌ」）、開発者、バージョン番号、リリース時間、または連絡先などを含み得るが、これらに限定されない。
【００３７】
ゲームアプリケーションが「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」アプリケーションであることを例にとると、第１の情報は、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」アプリケーションの中国語名称「リーグ・オブ・レジェンド」、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」の開発者（Ｒｉｏｔ Ｇａｍｅｓ）、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」のリリース時間（２０１１年９月２２日）などを含む。
【００３８】
ステップＳ１０２において、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、第１のデータベースは、アプリケーションに関連する第１の情報と、当該アプリケーションによって出力された画面に関連するキャプチャ方式とを含む。
【００３９】
本発明では、第１のデータベースを記憶することは、以下の２つの方式を含むことができるが、これらに限定されない。
【００４０】
第１の方式として、第１のデータベースを端末ローカルに記憶する。
【００４１】
第２の方式として、第１のデータベースを端末ローカルに接続されたクラウドサーバーに記憶する。
【００４２】
なお、記録された各アプリケーション（例えばゲームアプリケーション）によって出力された各画面を成功にキャプチャしたことに対応するキャプチャ方式に基づいて、第１のデータベースを作成することができ、ここで、異なる画面は、異なるキャプチャ方式に対応する。
【００４３】
具体的に、第１のアプリケーションに関連する第１の情報を第１のデータベースにおけるデータと比較することによって、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断することができる。
【００４４】
なお、アプリケーションによって出力された画面は、以下の２つのモードを含むことができるが、これらに限定されない。
【００４５】
第１のモードは、ウィンドウモードである。
【００４６】
第２のモードは、フルスクリーンモードである。
【００４７】
アプリケーションによって出力された画面に関連するキャプチャモードは、ウィンドウキャプチャモード、ディスプレイキャプチャモード、またはゲームキャプチャモードを含み得るが、これらに限定されない。
【００４８】
なお、異なるレンダリング技術（例えば、ＧＤＩ、Ｄ３Ｄ、ＤＤｒａｗまたはＯｐｅｎＧＬ）でレンダリング（描画）された画面は、異なるキャプチャ方式に対応することができる。
【００４９】
例えば、ウィンドウキャプチャとディスプレイキャプチャは、ＧＤＩレンダリングテクノロジーを使用してレンダリングされた画面をキャプチャすることができる。
【００５０】
ウィンドウキャプチャ方式でＧＤＩレンダリングテクノロジーによってレンダリングされた画面をキャプチャすることを例にとると、図１Ａに示すように、具体的には以下のステップを含み得るが、これらに限定されない。
【００５１】
ステップＳ１１において、関数ＧｅｔＤＣ(ｈｗｎｄ)を介して、指定されたウィンドウのデバイスコンテキストの環境を取得することができ、ここで、ｈｗｎｄは、指定されたウィンドウのハンドルを表すために使用され、つまり、ｈｗｎｄは、ウィンドウの属性（アイデンティティ）を表すために使用され、なお、当該デバイスコンテキストの環境には、当該ウィンドウのウィンドウテクスチャが保存されている。
【００５２】
ステップＳ１２において、関数ＢｉｔＢｉｔ（）を介して前述のウィンドウのデバイスコンテキストの環境内のウィンドウテクスチャをコピーすることによって、ＧＤＩレンダリングテクノロジーによってレンダリングされたウィンドウ画面のキャプチャを実現できる。
【００５３】
ディスプレイキャプチャ方式は、ＧＤＩレンダリングテクノロジーによってレンダリングされた画面をキャプチャし、実現方式は、ウィンドウキャプチャ方式によるＧＤＩレンダリングテクノロジーによってレンダリングされた画面のキャプチャと同様であり、ここで、関数ＧｅｔＤＣ(ｈｗｎｄ)のハンドルｈｗｎｄは、ＮＵＬＬに設定する必要があり、つまり、ディスプレイキャプチャモードは、関数ＧｅｔＤＣ(ＮＵＬＬ)関数を介して、ＧＤＩテクノロジによってレンダリングされたフルスクリーン画面のキャプチャを実現できる。
【００５４】
ゲームキャプチャは、Ｄ３Ｄ、ＤＤｒａｗまたはＯｐｅｎＧＬなどのレンダリングテクノロジーを使用してレンダリングされた画像をキャプチャすることができる。
【００５５】
Ｄ３Ｄレンダリングテクノロジーによってレンダリングされた画面をゲームキャプチャ方式でキャプチャすることを例とする。
【００５６】
具体的には、ＨＯＯＫアプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ、ＡＰＩ）を介して、Ｄ３Ｄテクノロジを使用してレンダリングされた画面のキャプチャを実現することができる。
【００５７】
以下、ゲームキャプチャ方式でＤ３Ｄレンダリングテクノロジーによりレンダリングされた画面をキャプチャするプロセスを詳しく説明する。
【００５８】
なお、Ｄ３Ｄレンダリングテクノロジーを使用して画面をレンダリングする場合、ｐｒｅｓｅｎｔ（）関数を呼び出す必要がある。
【００５９】
具体的なプロセスとして、第１のピクチャ取得関数をｐｒｅｓｅｎｔ（）関数に置き換え、Ｄ３Ｄレンダリングテクノロジーを使用して毎回ｐｒｅｓｅｎｔ（）関数を呼び出して画面をレンダリングする場合、毎回第１のピクチャ取得関数を呼び出すことによって、画面のキャプチャを実現する。ここで、第１のピクチャ取得関数は、バックバッファピクチャ（表示されようとするピクチャ）を取得するために使用されている。
【００６０】
また、第１のピクチャ取得関数が画面のキャプチャを実現した後、再度ｐｒｅｓｅｎｔ（）関数を呼び出してフロント・バックバッファピクチャの交換を実現し(画面のレンダリングを実現し)、ここで、ｐｒｅｓｅｎｔ（）関数は、フロントバッファピクチャ（表示中のピクチャ）とバックバッファピクチャ（表示されようとするピクチャ）を交換するために使用されている。
【００６１】
なお、ゲームキャプチャは、一定の不安定性を持っている。ゲームがＨＯＯＫアプリケーションプログラミングインターフェース（ＡＰＩ）をキャプチャするためには、ローカルな管理者権限を取得する必要があるため、管理者権限を取得できない場合、ゲームは第１のアプリケーションによって出力された画面をキャプチャすることができない。
【００６２】
ステップＳ１０３において、存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。
【００６３】
本発明では、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面をキャプチャし、図１Ｂに示すように、以下のステップを含み得るが、これらに限定されない。
【００６４】
ステップＳ２１において、前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定する。
【００６５】
以下、表１を参照して第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係を詳しく説明する。
【００６６】
【表１】
2021522721.tif 000003
【００６７】
ここで、０は、どのような適切なキャプチャ方式（ウィンドウキャプチャ、ウィンドウキャプチャ方式且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定すること、またはゲームキャプチャ）を採用するかを自動的に検出することを表し、１は、ウィンドウキャプチャ方式を強制的に採用し、且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定することを表し、２は、ウィンドウキャプチャ方式を強制的に採用することを表し、３は、ゲームキャプチャを強制的に採用することを表す。
【００６８】
表１を参照すると、ゲーム名称が「リーグ・オブ・レジェンド」であるゲームアプリケーションを例にとし、当該ゲームアプリケーションは、以下の３つのプロセスを含み得るが、これらに限定されない。
【００６９】
プロセス１として、ゲーム登録プロセス（Ｃｌｉｅｎｔ）である。
【００７０】
プロセス２として、ＰＶＰ.Ｎｅｔクライアントオープンプロセス（ＬｏｌＣｌｉｅｎｔ）である。
【００７１】
プロセス３として、ゲームプロセス（Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ）である。
【００７２】
表１から分かるように、プロセス１に関連（マッピング）するキャプチャ方式は、キャプチャ方式０であり、プロセス２に関連（マッピング）するキャプチャ方式は、キャプチャ方式０であり、プロセス３に関連（マッピング）するキャプチャ方式は、キャプチャ方式３である。
【００７３】
なお、プロセス１とプロセス２によって出力された画面がいずれもフルスクリーンモードになっていないため、ウィンドウキャプチャ、ウィンドウキャプチャ方式且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定すること、またはゲームキャプチャのいずれかを使用することで、プロセス１とプロセス２によって出力された画面をキャプチャすることができる。
【００７４】
特に、例えば、ライブ配信プラットフォームのライブ配信ルームのいくつかのウィンドウについて、当該ウィンドウは、ウィンドウＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を有するので、ＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定するウィンドウキャプチャ方式を採用する必要があり、具体的に、まず、関数ＧｅｔＤＣ(ｈｗｎｄ)を介して、指定されたウィンドウのデバイスコンテキストの環境を取得することができ、ここで、ｈｗｎｄは、指定されたウィンドウのハンドルを表すために使用されている。さらに、関数ＢｉｔＢｉｔ（ｃａｐｔｕｒｅＢｉｔ）を介して前述のウィンドウのデバイスコンテキストの環境内のウィンドウテクスチャをコピーすることによって、ＧＤＩレンダリングテクノロジーによってレンダリングされたＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を有するウィンドウ画面のキャプチャを実現できる。
【００７５】
また、プロセス３によって出力された画面が主にフルスクリーンモードであるため、ゲームキャプチャ方式(キャプチャ方式３)を使用して、プロセス３によって出力された画面をキャプチャする。
【００７６】
ステップＳ２２において、確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャする。
【００７７】
選択肢の一つとして、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャすることができ、図１Ｃに示すように、以下のステップを含み得るが、これらに限定されない。
【００７８】
ステップＳ３１において、第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面を同時にキャプチャする。
【００７９】
具体的に、第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み得るが、これらに限定されない。第２のキャプチャ方式は、ゲームキャプチャを含み得る。なお、ゲーム画面を描画する場合にのみ、ゲームキャプチャは画面をキャプチャすることができる。
【００８０】
ここで、第１の時間閾値は設定可能であり、好ましくは、第１の時間閾値は１５秒であってもよい。第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）に関連し、つまり、異なるアプリケーションに関連する第１の時間閾値は異なる。例えば、いくつかの簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、いくつかの比較的複雑な、メモリ使用量の大きいゲームアプリケーションに関連する第１の時間閾値は比較的に大きく、例えば１５.５秒、１６秒などである。これは、簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、上記の比較的複雑な、メモリ使用量の大きいゲームアプリケーションの起動時間が比較的に長いためである。
【００８１】
したがって、合理的なキャプチャ方式を採用する観点から、複雑な、メモリ使用量の大きいゲームアプリケーションについては、第１の時間閾値を比較的大きいものに設定することができ、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップ２を参照してください。
【００８２】
選択肢の一つとして、第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）を実行するデバイスに関連し、つまり、アプリケーションを実行する異なるデバイスに関連した第１の時間閾値は、異なっている。例えば、いくつかのハードウェア構成（例えば、ＣＰＵ周波数、ＣＰＵ数、またはＣＰＵ実行メモリサイズ）の高いアプリケーションを実行するデバイスと比較して、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスに関連する第１の時間閾値は比較的に大きく、例えば１５.５秒、１６秒などである。これは、いくつかのハードウェア構成の高いアプリケーションを実行するデバイスと比較して、上記のいくつかのハードウェア構成の低いアプリケーションを実行するデバイスでは、同一アプリケーションを起動する時間が比較的に長いためである。
【００８３】
したがって、合理的なキャプチャ方式を採用する観点から、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスについては、第１の時間閾値を比較的大きいものに設定することができ、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップＳ３２を参照してください。
【００８４】
ステップＳ３２において、第１の時間閾値の範囲内で、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャした場合、第２のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、同時に、第１のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止し、さもなければ、第１のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、同時に、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止する。
【００８５】
選択肢の一つとして、前記第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得し、ひいては、前記エンコードされた画面をサーバに送信してもよく、ここで、当該サーバは、ライブ配信プラットフォームのサーバであってもよい。
【００８６】
選択肢の一つとして、前記第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャする前に、
第１のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。
【００８７】
以下、アプリケーションの起動時に、第１のキャプチャ方式が第２のキャプチャ方式よりも先に第１のアプリケーションによって出力された画面をキャプチャできる理由について詳しく説明する。理由は、以下の通りである。
【００８８】
アプリケーションの起動時には多くのリソースをロードしてから、画像の描画を開始し、第２のキャプチャ方式は、アプリケーションがレンダリング（描画）を行うときにのみ、画面をキャプチャでき、しかし、第１のキャプチャ方式はアプリケーションの起動の最初から画面をキャプチャできるため、第１のキャプチャ方式は、第２のキャプチャ方式で画面をキャプチャした前に画面をキャプチャすることができる。
【００８９】
選択肢の一つとして、第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットする。
【００９０】
具体的に、第１のアプリケーションの出力画面のウィンドウが最小化された場合、第１の時間閾値をリセットすることができ、第１のアプリケーションの出力画面が最大化された場合、リセットされた第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式を採用して第１のアプリケーションの出力画面を同時にキャプチャする。
【００９１】
なお、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャした場合、第２のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、同時に、第１のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止することができる。理由は、以下の通りであり、第１のキャプチャ方式に対して、第２のキャプチャ方式のキャプチャ効率はより高い。また、第１のキャプチャ方式に対して、第２のキャプチャ方式は、第１のアプリケーションによって出力された画面をキャプチャする際に、プロセッサのより小さい実行メモリのみを占有することができる。
【００９２】
以上のように、本発明は、画面キャプチャ方法に関する。具体的に、本発明は、第１のキャプチャポリシーまたは第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャし、第１のアプリケーションによって出力された画面をほとんどうまくキャプチャすることができ、キャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、キャスターがライブ配信中にブラックスクリーンになるという問題を防止した。したがって、本発明を採用することにより、ユーザ体験を大幅に向上させることができる。
【００９３】
本発明の実施例を容易に実施するために、本発明では、図１の実施例に記載された方法を実現するための端末が提供される。図２は、本発明による端末の概略ブロック図である。図２に示すように、端末２００は、検出ユニット２０１、判断ユニット２０２、およびキャプチャユニット２０３を含む。
【００９４】
検出ユニット２０１は、実行された第１のアプリケーションに関連する第１の情報を検出するために使用され、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用される。
【００９５】
判断ユニット２０２は、第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、前記第１のデータベースは、アプリケーションに関連する第１の情報と、前記アプリケーションによって出力された画面に関連するキャプチャ方式を含む。
【００９６】
キャプチャユニット２０３は、存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャする。
【００９７】
判断ユニット２０２は、具体的に、
第１のアプリケーションに関連する第１の情報を第１のデータベースにおけるデータと比較することによって、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断することができる。
【００９８】
なお、記録された各アプリケーション（例えばゲームアプリケーション）によって出力された各画面を成功にキャプチャしたことに対応するキャプチャ方式に基づいて、第１のデータベースを作成することができ、ここで、異なる画面は、異なるキャプチャ方式に対応する。
【００９９】
なお、第１のデータベースを記憶する方式は、以下の２つの方式を含むことができるが、これらに限定されない。
【０１００】
第１の方式として、第１のデータベースを端末ローカルに記憶する。
【０１０１】
第２の方式として、第１のデータベースを端末ローカルに接続されたクラウドサーバーに記憶する。
【０１０２】
なお、記録された各アプリケーション（例えばゲームアプリケーション）によって出力された各画面を成功にキャプチャしたことに対応するキャプチャ方式に基づいて、第１のデータベースを作成することができ、ここで、異なる画面は、異なるキャプチャ方式に対応する。
【０１０３】
キャプチャユニット２０３は、具体的に、
第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、以下のステップを含み得るが、これらに限定されない。
【０１０４】
ステップ１において、前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定する。
【０１０５】
ステップ２において、確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャする。
【０１０６】
選択肢の一つとして、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャすることは、以下のステップを含み得るが、これらに限定されない。
【０１０７】
ステップ１において、第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面を同時にキャプチャする。
【０１０８】
なお、第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み得るが、これらに限定されない。第２のキャプチャ方式は、ゲームキャプチャを含み得る。ここで、第１の時間閾値は設定可能であり、好ましくは、第１の時間閾値は１５秒であってもよい。第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）に関連し、つまり、異なるアプリケーションに関連する第１の時間閾値は異なる。いくつかの簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、いくつかの比較的複雑な、メモリ使用量の大きいゲームアプリケーションに関連する第１の時間閾値は比較的に大きい。これは、簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、上記の比較的複雑な、メモリ使用量の大きいゲームアプリケーションの起動時間が比較的に長いためである。したがって、合理的なキャプチャ方式を採用する観点から、複雑な、メモリ使用量の大きいゲームアプリケーションについては、第１の時間閾値を比較的大きいものに設定すべきであり、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップ２を参照してください。
【０１０９】
選択肢の一つとして、第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）を実行するデバイスに関連し、つまり、アプリケーションを実行する異なるデバイスに関連した第１の時間閾値は、異なっている。いくつかのハードウェア構成（例えば、ＣＰＵ周波数、ＣＰＵ数、またはＣＰＵ実行メモリサイズ）の高いアプリケーションを実行するデバイスと比較して、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスに関連する第１の時間閾値は比較的に大きい。これは、いくつかのハードウェア構成の高いアプリケーションを実行するデバイスと比較して、上記のいくつかのハードウェア構成の低いアプリケーションを実行するデバイスでは、同一アプリケーションを起動する時間が比較的に長いためである。
【０１１０】
したがって、合理的なキャプチャ方式を採用する観点から、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスについては、第１の時間閾値を比較的大きいものに設定することができ、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップ２を参照してください。
【０１１１】
ステップ２において、第１の時間閾値の範囲内で、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャした場合、第２のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、同時に、第１のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止し、さもなければ、第１のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、同時に、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止する。
【０１１２】
端末２００は、検出ユニット２０１、判断ユニット２０２、およびキャプチャユニット２０３の他に、エンコードユニット、送信ユニットをさらに含むことができる。
【０１１３】
エンコードユニットは、上述した第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用される。
【０１１４】
送信ユニットは、エンコードユニットによってエンコードされた第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用され、本発明では、当該サーバは、ライブ配信プラットフォームサーバーであってもよい。
【０１１５】
エンコードユニットは、上述した第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャする前に、第１のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されてもよい。
【０１１６】
送信ユニットは、上述したエンコードユニットによってエンコードされた第１のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用されてもよい。
【０１１７】
以下、アプリケーションの起動時に、第１のキャプチャ方式が第２のキャプチャ方式よりも先に第１のアプリケーションによって出力された画面をキャプチャできる理由について詳しく説明する。理由は、以下の通りである。
【０１１８】
アプリケーションの起動時には多くのリソースをロードしてから、画像の描画を開始し、第２のキャプチャ方式は、アプリケーションがレンダリング（描画）を行うときにのみ、画面をキャプチャでき、しかし、第１のキャプチャ方式はアプリケーションの起動の最初から画面をキャプチャできるため、第１のキャプチャ方式は、第２のキャプチャ方式で画面をキャプチャした前に画面をキャプチャすることができる。
【０１１９】
端末２００は、検出ユニット２０１、判断ユニット２０２、およびキャプチャユニット２０３，エンコードユニット、送信ユニットの他に、リセットユニットをさらに含むことができる。
【０１２０】
リセットユニットは、第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットする。
【０１２１】
具体的に、第１のアプリケーションの出力画面のウィンドウが最小化された場合、第１の時間閾値をリセットすることができ、第１のアプリケーションの出力画面が最大化された場合、リセットされた第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式を採用して第１のアプリケーションの出力画面を同時にキャプチャする。
【０１２２】
図２の端末２００に含まれる機能モジュールの具体的な実施形態については、前述の実施形態を参照することができ、ここでは説明を省略することが理解できる。
【０１２３】
図３は、本発明による別の端末の概略構成図である。本発明の実施例では、端末は、携帯電話、タブレットコンピュータ、パーソナルデジタルアシスタント（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ、ＰＤＡ）、モバイルインターネットデバイス（Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｄｅｖｉｃｅ、ＭＩＤ）、スマートウェアラブルデバイス（例えば、スマート腕時計、スマートハンドヘルド）などの様々なデバイスを含むことができ、本発明の実施例はこれを限定しない。図３に示すように、端末３００は、ベースバンドチップ３０１と、メモリ３０２（１つまたは複数のコンピュータ可読記憶媒体）と、周辺システム８０３とを含むことができる。これらのコンポーネントは、１つまたは複数の通信バス３０４上で通信することができる。
【０１２４】
ベースバンドチップ３０１は、１つ以上のプロセッサ（ＣＰＵ）３０５、１つ以上のグラフィックプロセッサ（ＧＰＵ）３０６を含む。
【０１２５】
プロセッサ３０５は、第１のアプリケーションによって出力された画面をキャプチャするために使用されてもよいことが理解できる。グラフィックプロセッサ３０６は、第１のアプリケーションによって出力された画面をレンダリング（描画）するために使用されてもよい。
【０１２６】
メモリ３０２は、プロセッサ３０５とカップリングされ、様々なソフトウェアプログラムおよび／または複数セットの指令を記憶するために使用されることができる。具体的な実施形態では、メモリ３０２は、高速ランダムアクセスメモリを含み、且つ不揮発性メモリを含んでもよく、例えば、１つ以上の磁気ディスク記憶装置、フラッシュメモリ装置、または他の不揮発性ソリッドステートストレージデバイスが挙げられる。メモリ３０２は、ＡＮＤＲＯＩＤ（登録商標）、ＩＯＳ、ＷＩＮＤＯＷＳ（登録商標）、またはＬＩＮＵＸなどの埋め込みオペレーティングシステムなどのオペレーティングシステム（以下、簡単にシステムと呼ぶ）を記憶してもよい。メモリ３０２は、ネットワーク通信プログラムを記憶してもよく、当該ネットワーク通信プログラムは、１つ以上の追加デバイス、１つ以上の端末デバイス、１つ以上のネットワークデバイスと通信するために使用されてもよい。メモリ３０２は、ユーザインターフェースプログラムを記憶してもよく、当該ユーザインターフェースプログラムは、グラフィカル操作インターフェースを介して、アプリケーションのコンテンツをリアルに表示し、メニュー、ダイアログボックス、およびボタンなどの入力コントロールを介して、ユーザによるアプリケーションの制御操作を受信してもよい。
【０１２７】
メモリ３０２は、第１のアプリケーション、第１のアプリケーションに関連する第１の情報を記憶するために使用されてもよく、第１の情報は、第１のアプリケーションの属性を表すために使用されてもよいことが理解できる。
【０１２８】
メモリ３０２は、１つ以上のアプリケーションを記憶してもよい。図３に示すように、これらのアプリケーションには、ソーシャルアプリケーション（例えばＦａｃｅｂｏｏｋ）、画像管理アプリケーション（例えばフォトアルバム）、マップアプリケーション（例えばＧｏｏｇｌｅマップなど）、ブラウザ（例えばＳａｆａｒｉ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ）などが含まれている。
【０１２９】
周辺システム３０３は、主に端末３００とユーザ／外部環境との間のインタラクティブ機能を実現するために使用され、主に端末３００の入出力デバイスを含む。具体的な実施形態では、周辺システム３０３は、ディスプレイコントローラ８０７と、カメラコントローラ３０８と、マウス・キーボードコントローラ３０９と、オーディオコントローラ３１０とを含むことができる。ここで、各コントローラは、それぞれの対応する周辺デバイス（ディスプレイ３１１、カメラ３１２、マウス・キーボード３１３、およびオーディオ回路３１４など）とカップリングされてもよい。いくつかの実施例では、ディスプレイ３１１は、自己容量式のフローティングタッチパネルを配置したディスプレイであっても良いし、赤外線式のフローティングタッチパネルを配置したディスプレイであっても良い。いくつかの実施例では、カメラ３１２は、３Ｄカメラであってもよい。なお、周辺システム３０３は、他のＩ／Ｏ周辺機器をさらに含んでもよい。
【０１３０】
端末３００は、本発明の実施例による一例に過ぎず、端末３００は、図示された構成要素よりも多くまたは少ない構成要素を有してもよく、２つ以上の構成要素を組み合わせてもよく、または構成要素の異なる配置を有してもよいことが理解すべきである。
【０１３１】
図３の端末３００に含まれる機能モジュールの具体的な実施形態については、図１の方法の実施例を参照することができ、ここでは説明を省略することが理解できる。
【０１３２】
本発明は、コンピュータ可読記憶媒体に関し、当該コンピュータ可読記憶媒体には、コンピュータプログラムが記憶され、当該コンピュータプログラムは、プロセッサによって実行されるとき実現される。
【０１３３】
当該コンピュータ可読記憶媒体は、例えば端末のハードディスクやメモリなど、前述の実施形態のいずれかで説明された端末の内部記憶ユニットであってもよい。当該コンピュータ可読記憶媒体は、例えば端末に搭載されているプラグインハードディスク、スマートメモリカード（Ｓｍａｒｔ Ｍｅｄｉａ（登録商標） Ｃａｒｄ、ＳＭＣ）、セキュリティデジタル（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ、ＳＤ）カード、フラッシュカード（Ｆｌａｓｈ Ｃａｒｄ）などの端末の外部記憶装置であってもよい。さらに、当該コンピュータ可読記憶媒体は、端末の内部記憶ユニットおよび外部記憶装置の両方を含むこともできる。当該コンピュータ可読記憶媒体は、コンピュータプログラムおよび端末に必要な他のプログラムとデータを記憶するために使用される。当該コンピュータ可読記憶媒体は、出力されたデータまたは出力されようとするデータを一時的に記憶するために使用されてもよい。
【０１３４】
本発明は、コンピュータプログラム製品にさらに関し、当該コンピュータプログラム製品は、コンピュータプログラムを記憶する非一時的コンピュータ可読記憶媒体を含み、当該コンピュータプログラム製品は、上記の方法の実施例に記載された任意の方法の一部またはすべてをコンピュータに実行させるように動作可能である。当該コンピュータプログラム製品は、ソフトウェアインストールパッケージであってもよく、当該コンピュータは、電子デバイスを含む。
【０１３５】
当業者は、本明細書に開示された実施例を参照して説明された様々な例のユニットおよびアルゴリズムステップを、電子ハードウェア、コンピュータソフトウェア、または両方の組み合わせで実現することができることを認識することができ、ハードウェアとソフトウェアの互換性を明確に説明するために、上記の説明では、様々な例の構成およびステップが機能別に一般的に説明された。これらの機能がハードウェアで実行されるかソフトウェアで実行されるかは、技術案の特定の応用および設計制約条件に依存する。専門技術者は、特定の応用ごとに、異なる方法を使用することによって、説明された機能を実現することができるが、このような実現は、本願の範囲を超えていると考えてはならない。
【０１３６】
当業者は、説明の便宜および簡略化のために、上述の端末およびユニットの具体的な作動プロセスについては、前述の方法の実施例における対応するプロセスを参照できることを明確に理解でき、ここでは説明を省略する。
【０１３７】
本発明によるいくつかの実施例において、開示された端末および方法は、他の方式で実現されうることが理解すべきである。例えば、各例の構成およびステップを説明した。これらの機能がハードウェアで実行されるかソフトウェアで実行されるかは、技術案の特定の応用および設計制約条件に依存する。専門技術者は、特定の応用ごとに、異なる方法を使用することによって、説明された機能を実現することができるが、このような実現は、本発明の範囲を超えていると考えてはならない。
【０１３８】
以上で説明された端末の実施例は単なる例示であり、例えば、前記ユニットの分割は、論理的な機能の分割にすぎず、実際に実現するときに、他の分割方式が存在する場合があり、例えば、複数のユニットまたはコンポーネントを組み合わせたり、別のシステムに統合したり、いくつかの特徴を無視したり実行しないことができる。また、表示または説明される相互間のカップリングまたは直接カップリングまたは通信接続は、いくつかのインターフェース、端末またはユニットを介した間接カップリングまたは通信接続であってもよいし、電気的、機械的、または他の形で接続されてもよい。
【０１３９】
前記分離コンポーネントとして説明されたユニットは、物理的に分離されてもよいし、物理的に分離されていなくてもよいし、ユニットとして表示されたコンポーネントは、物理ユニットであってもよいし、物理ユニットでなくてもよいし、１つの場所に配置されてもよいし、複数のネットワークユニットに分散されてもよい。本発明の実施例の目的は、実際の必要に応じて、そのうちの一部または全部のユニットを選択することによって達成されることができる。
【０１４０】
また、本発明の各実施例における各機能ユニットが１つの処理ユニットに統合されてもよいし、各ユニットが物理的に単独で存在してもよいし、２つ以上のユニットが１つのユニットに統合されてもよい。上述した統合されたユニットは、ハードウェアの形で実現されてもよいし、ソフトウェア機能ユニットの形で実現されてもよい。
【０１４１】
上述した統合されたユニットがソフトウェア機能ユニットの形で実現され、且つ独立した製品として販売されたり、使用されたりする場合には、１つのコンピュータ可読記憶媒体に記憶されてもよい。このような理解に基づいて、本発明に記載された技術案に関し、本質的に、従来技術に貢献する部分、または当該技術案の全部または一部は、ソフトウェア製品の形で具現化されることができ、当該コンピュータソフトウェア製品は、１つの記憶媒体に記憶され、本発明の各実施例で説明された方法のステップのすべてまたは一部を１台のコンピュータデバイス（パーソナルコンピュータ、サーバ、またはネットワークデバイスなどであり得る）に実行させる若干の指令を含む。また、上述した記憶媒体は、Ｕディスク、リムーバブルハードディスク、読み取り専用メモリ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ、ＲＯＭ)、ランダムアクセスメモリ(Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ＲＡＭ)、磁気ディスク、光ディスクなど、プログラムコードを記憶することができる種々の媒体を含む。
【０１４２】
上記の説明は、本発明の具体的な実施例に過ぎないが、本発明の保護範囲はこれに限定されず、本技術分野に詳しい任意の技術者は、本発明で開示された技術の範囲内で、様々な等価的な修正または置換を容易に想到し、これら修正または置換は、本発明の保護範囲内に含まれるべきである。したがって、本発明の保護範囲は、請求項の保護範囲に準じるべきである。
【符号の説明】
【０１４３】
201  検出ユニット
202  判断ユニット
203  キャプチャユニット
301  ベースバンドチップ
302  メモリ
303  周辺システム
305  プロセッサ（ＣＰＵ）
306  グラフィックプロセッサ（ＧＰＵ）
307  ディスプレイコントローラ
308  カメラコントローラ
309  マウス・キーボードコントローラ
310  オーディオコントローラ
311  ディスプレイ（フローティングタッチ）
312  カメラ（例えば３Ｄカメラ）
313  マウス・キーボード
314  オーディオ回路
【図１】
2021522721.tif 000004
【図１Ａ】
2021522721.tif 000005
【図１Ｂ】
2021522721.tif 000006
【図１Ｃ】
2021522721.tif 000007
【図２】
2021522721.tif 000008
【図３】
2021522721.tif 000009
【手続補正書】
【提出日】令和2年10月29日(2020.10.29)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、２０１８年１２月２７日に出願された出願番号ＰＣＴ/ＣＮ２０１８/１２４５０６の国際出願の国家段階であり、２０１８年０４月２８日に出願された出願番号２０１８１０４１２０６９.３、発明の名称「画面キャプチャ方法および端末」の中国特許出願の優先権を主張し、その全ての内容は参照により本明細書に援用する。
【０００２】
本発明はビデオ処理技術の分野に属し、特に画面キャプチャ方法、端末および記憶媒体に関するものである。
【背景技術】
【０００３】
動画ライブ配信ブームの高まりに伴い、ゲームのライブ配信を行うプラットフォームもますます多くなり、ライブ配信されたほとんどのゲームはＷｉｎｄｏｗｓ（登録商標）プラットフォームに基づいたものであり、１つのゲームをライブ配信するには、まずゲームの画面をキャプチャし、次に動画ストリームにエンコードして、ある方式でライブ配信プラットフォームのサーバにプッシュする必要がある。ただし、現在多くのゲームのライブ配信プラットフォームは、オープン・ブロードキャスター・ソフトウェア（Ｏｐｅｎ  Ｂｒｏａｄｃａｓｔｅｒ  Ｓｏｆｔｗａｒｅ、ＯＢＳ）を使って上記の機能を完成する。
【０００４】
しかしながら、ＯＢＳの利用は容易ではなく、１つのゲームをライブ配信する設定方式は複雑である。例えば、ＯＢＳは、ゲーム画面をキャプチャするための３つの設定方式を提供し、ＯＢＳを使用してゲーム画面をキャプチャしたばかりのユーザは、どのキャプチャ方式を選択すべきか分からず、キャプチャ方式が誤って選択されると、ゲーム画面をキャプチャすることができないため、ライブ配信中にブラックスクリーン問題を発生させる可能性があり、ユーザの体験がよくない場合がある。
【発明の概要】
【課題を解決するための手段】
【０００５】
本発明は、画面のキャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、ライブ配信中にブラックスクリーン問題が発生しないようにする画面キャプチャ方法、端末および記憶媒体を提供する。
【０００６】
第１の側面において、本発明は、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されることと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む、
画面キャプチャ方法に関する。
【０００７】
第１の側面に関して、いくつかの可能な実施例において、
前記第１のキャプチャポリシーまたは前記第２のキャプチャポリシーによってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。
【０００８】
第１の側面に関して、いくつかの可能な実施例において、前記第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定することと、
確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む。
【０００９】
第１の側面に関して、いくつかの可能な実施例において、前記第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面を同時にキャプチャすることと、
前記第１の時間閾値の範囲内で、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされた場合、前記第２のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第１のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止し、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされない場合、前記第１のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止することと、
を含む。
【００１０】
第１の側面に関して、いくつかの可能な実施例において、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャする前に、
前記第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。
【００１１】
第１の側面に関して、いくつかの可能な実施例において、
前記第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットすることをさらに含む。
【００１２】
第１の側面に関して、いくつかの可能な実施例において、前記第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み、
前記第２のキャプチャ方式は、ゲームキャプチャを含む。
【００１３】
第２の側面において、本発明は、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用される検出ユニットと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャするために使用されるキャプチャユニットと、
を含み、
前記キャプチャユニットは、前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャするためにも使用される、
端末に関する。
【００１４】
第２の側面に関して、いくつかの可能な実施例において、当該端末は、
上述した前記第１のキャプチャ方式または前記第２のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されるエンコードユニットと、
エンコードユニットによってエンコードされた第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用される送信ユニットと、
をさらに含む。
【００１５】
本発明では、当該サーバは、ライブ配信プラットフォームサーバーであってもよい。
【００１６】
エンコードユニットは、上述した第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャする前に、第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されてもよい。
【００１７】
送信ユニットは、上述したエンコードユニットによってエンコードされた第１のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用されてもよい。
【００１８】
第２の側面に関して、いくつかの可能な実施例において、当該端末は、
第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットするリセットユニットをさらに含む。
【００１９】
第３の側面において、本発明は、プロセッサおよびメモリを含み、前記メモリは、アプリケーションコードを記憶するために使用され、前記プロセッサは、前記アプリケーションコードを呼び出すことにより、以下の方法を実行するように構成され、即ち、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されること、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすること、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることである、端末に関する。
【００２０】
第４の側面において、本発明は、コンピュータプログラムが記憶されたコンピュータ可読記憶媒体であって、前記コンピュータプログラムは、プログラム指令を含み、前記プログラム指令は、プロセッサによって実行されるとき、上記の第１の側面に記載された方法を前記プロセッサに実行させるコンピュータ可読記憶媒体に関する。
【００２１】
第５の側面において、本発明は、画面キャプチャ指令を含むコンピュータプログラムであって、当該コンピュータプログラムがコンピュータ上で実行されるとき、上述した画面捕捉指令は、上記の第１の側面に記載された画面キャプチャ方法を実行するために使用されるコンピュータプログラムに関する。
【００２２】
本発明は、画面キャプチャ方法および端末に関する。まず、実行された第１のアプリケーションに関連する第１の情報を検出し、第１の情報は、第１のアプリケーションの属性を表すために使用される。次に、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断し、ここで、第１のデータベースは、アプリケーションの名称と、当該アプリケーションによって出力された画面に関連するキャプチャ方式とを含む。最後に、存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。本発明を採用することにより、キャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、ライブ配信中にブラックスクリーン問題が発生しないようにする。したがって、本発明を採用することにより、ユーザ体験を大幅に向上させることができる。
【図面の簡単な説明】
【００２３】
【図１】本発明による画面キャプチャ方法の概略フローチャートである。
【図２】本発明によるウィンドウキャプチャ方式によって、ＧＤＩレンダリング技術を使用してレンダリングされた画像をキャプチャする概略フローチャートである。
【図３】本発明による第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする概略フローチャートである。
【図４】本発明による第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする概略フローチャートである。
【図５】本発明による端末の概略ブロック図である。
【図６】本発明による別の端末の概略ブロック図である。
【発明を実施するための形態】
【００２４】
以下、本発明の技術案について、本発明の図面を参照して明確かつ完全に説明し、説明された実施例は、全ての実施例ではなく、本発明の実施例の一部であることは明らかである。本発明の実施例に基づいて、当業者が創造的な労働をしないことを前提として取得された他のすべての実施例は、本発明の保護の範囲に属する。
【００２５】
本明細書および添付の特許請求の範囲で使用される場合、「含む」および「含有する」という用語は、説明された特徴、全体、ステップ、動作、要素および／またはコンポーネントの存在を示すが、１つ以上の他の特徴、全体、ステップ、動作、要素、コンポーネントおよび／またはそのセットの存在または追加を排除しないことを理解すべきである。
【００２６】
ここで、本発明の明細書で使用される用語は、特定の実施例を説明することのみを目的とし、本発明を限定するものではないことも理解すべきである。本発明の明細書および添付の特許請求の範囲で使用されるように、他の状況が文脈で明示されない限り、単数形の「１」、「１つ」および「当該」は、複数形を含むことが意図される。
【００２７】
本発明の明細書および添付の特許請求の範囲で使用される「および／または」という用語は、関連付けられた項目のうちの１つまたは複数の任意の組み合わせおよび可能なすべての組み合わせを意味し、これらの組み合わせを含むことをさらに理解すべきである。
【００２８】
本明細書および添付の特許請求の範囲で使用されるように、「場合」という用語は、文脈に応じて「…とき」、「一度」、「確定に応答する」または「検出に応答する」と解釈することができる。同様に、「確定した場合」または「「記述された条件またはイベント」が検出された場合」という句は、文脈に応じて「一度確定した」、「確定に応答する」、「一度「記述された条件またはイベント」が検出された」または「「記述された条件またはイベント」が検出されたことに応答する」を意味すると解釈することができる。
【００２９】
具体的には、本発明で説明された端末は、タッチセンシティブ表面（例えば、タッチパネルディスプレイおよび／またはタッチパネル）を有する携帯電話、ラップトップコンピュータまたはタブレットコンピュータなどの他の携帯機器を含むが、これらに限定されない。また、いくつかの実施例では、前記機器は、携帯通信機器ではなく、タッチセンシティブ表面（例えば、タッチパネルディスプレイおよび／またはタッチパッド）を有するデスクトップコンピュータであることも理解すべきである。
【００３０】
以下の議論では、ディスプレイおよびタッチセンシティブ表面を含む端末を説明する。しかしながら、端末は、物理キーボード、マウスおよび／またはジョイスティックなどの１つまたは複数の他の物理的ユーザインターフェースデバイスを含むことができることを理解すべきである。
【００３１】
端末は、様々なアプリケーションをサポートし、例えば、図形描画アプリケーション、デモンストレーションアプリケーション、文字処理アプリケーション、ウェブサイト作成アプリケーション、ディスク書き込みアプリケーション、スプレッドシートアプリケーション、ゲームアプリケーション、電話アプリケーション、ビデオ会議アプリケーション、電子メールアプリケーション、インスタントメッセージングアプリケーション、運動サポートアプリケーション、写真管理アプリケーション、デジタルカメラアプリケーション、デジタルビデオカメラアプリケーション、ｗｅｂ（ウェブ）ブラウズアプリケーション、デジタル音楽プレーヤーアプリケーションおよび/またはデジタルビデオプレーヤーアプリケーションのうちの１つまたは複数をサポートする。
【００３２】
端末上で実行可能な様々なアプリケーションは、タッチセンシティブ表面ような少なくとも１つの共通の物理ユーザインターフェースデバイスを使用することができる。タッチセンシティブ表面の１つまたは複数の機能および端末に表示された対応する情報は、アプリケーション間および／または対応するアプリケーション内で調整および／または変更されることができる。このように、端末の共通の物理的アーキテクチャ(例えば、タッチセンシティブ表面)は、ユーザにとって直観的かつ透明なユーザインターフェースを有する様々なアプリケーションをサポートすることができる。
【００３３】
図１を参照すると、本発明による画面キャプチャ方法の概略フローチャートであり、図１に示すように、当該方法は、以下のステップを含むが、これらに限定されない。
【００３４】
ステップＳ１０１において、実行された第１のアプリケーションに関連する第１の情報を検出し、第１の情報は、第１のアプリケーションの属性を表すために使用される。
【００３５】
本発明では、第１のアプリケーションは、ゲームアプリケーション、動画アプリケーション、またはテキストアプリケーションなどを含み得るが、これらに限定されない。本発明の実施例における第１の情報は、第１のアプリケーションの名前、開発者、リリース時間、バージョン番号、使用の説明、連絡先情報または連絡先アドレスなどを含み得るが、これらに限定されない。つまり、本発明の実施例における第１のアプリケーションの属性は、第１のアプリケーションの名前、開発者、またはリリース時間などであってもよい。
【００３６】
例えば、第１のアプリケーションがゲームアプリケーションである場合、第１の情報は、当該ゲームアプリケーションの名称（「リーグ・オブ・レジェンド」、「Ａｎｇｒｙ Ｂｉｒｄｓ」、「Ｓｕｐｅｒ Ｍａｒｉｏ Ｒｕｎ」、「Ｆｒｕｉｔ Ｎｉｎｊａ」、または「Ｒｕｌｅｓ ｏｆ Ｓｕｒｖｉｖａｌ」）、開発者、バージョン番号、リリース時間、または連絡先などを含み得るが、これらに限定されない。
【００３７】
ゲームアプリケーションが「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」アプリケーションであることを例にとると、第１の情報は、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」アプリケーションの中国語名称「リーグ・オブ・レジェンド」、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」の開発者（Ｒｉｏｔ Ｇａｍｅｓ）、「Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ」のリリース時間（２０１１年９月２２日）などを含む。
【００３８】
ステップＳ１０２において、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面をキャプチャする。
【００３９】
ステップＳ１０３において、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。
【００４０】
選択肢の一つとして、第１のアプリケーションに関連する第１の情報を取得した後、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断することができ、ここで、第１のデータベースは、アプリケーションに関連する第１の情報と、当該アプリケーションによって出力された画面に関連するキャプチャ方式とを含む。
【００４１】
本発明では、第１のデータベースを記憶することは、以下の２つの方式を含むことができるが、これらに限定されない。
【００４２】
第１の方式として、第１のデータベースを端末ローカルに記憶する。
【００４３】
第２の方式として、第１のデータベースを端末ローカルに接続されたクラウドサーバーに記憶する。
【００４４】
なお、記録された各アプリケーション（例えばゲームアプリケーション）によって出力された各画面を成功にキャプチャしたことに対応するキャプチャ方式に基づいて、第１のデータベースを作成することができ、ここで、異なる画面は、異なるキャプチャ方式に対応する。
【００４５】
具体的に、第１のアプリケーションに関連する第１の情報を第１のデータベースにおけるデータと比較することによって、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断することができる。
【００４６】
なお、アプリケーションによって出力された画面は、以下の２つのモードを含むことができるが、これらに限定されない。
【００４７】
第１のモードは、ウィンドウモードであり、
第２のモードは、フルスクリーンモードである。
【００４８】
アプリケーションによって出力された画面に関連するキャプチャモードは、ウィンドウキャプチャモード、ディスプレイキャプチャモード、またはゲームキャプチャモードを含み得るが、これらに限定されない。
【００４９】
なお、異なるレンダリング技術（例えば、ＧＤＩ（Ｇｒａｐｈｉｃｓ  Ｄｅｖｉｃｅ  Ｉｎｔｅｒｆａｃｅ、グラフィックス・デバイス・インターフェース）、Ｄ３Ｄ（Ｄｉｒｅｃｔ３Ｄ、３Ｄアクセラレータ）、ＤＤｒａｗ（ＤｉｒｅｃｔＤｒａｗ）またはＯｐｅｎＧＬ（Ｏｐｅｎ  Ｇｒａｐｈｉｃｓ  Ｌｉｂｒａｒｙ、オープンジーエル））でレンダリング（描画）された画面は、異なるキャプチャ方式に対応することができる。
【００５０】
例えば、ウィンドウキャプチャとディスプレイキャプチャは、ＧＤＩレンダリングテクノロジーを使用してレンダリングされた画面をキャプチャすることができる。
【００５１】
ウィンドウキャプチャ方式でＧＤＩレンダリングテクノロジーによってレンダリングされた画面をキャプチャすることを例にとると、図２に示すように、具体的には以下のステップを含み得るが、これらに限定されない。
【００５２】
ステップＳ１１において、関数ＧｅｔＤＣ(ｈｗｎｄ)を介して、指定されたウィンドウのデバイスコンテキストの環境を取得することができ、ここで、ｈｗｎｄは、指定されたウィンドウのハンドルを表すために使用され、つまり、ｈｗｎｄは、ウィンドウの属性（アイデンティティ）を表すために使用され、なお、当該デバイスコンテキストの環境には、当該ウィンドウのウィンドウテクスチャが保存されている。
【００５３】
ステップＳ１２において、関数ＢｉｔＢｉｔ（）を介して前述のウィンドウのデバイスコンテキストの環境内のウィンドウテクスチャをコピーすることによって、ＧＤＩレンダリングテクノロジーによってレンダリングされたウィンドウ画面のキャプチャを実現できる。
【００５４】
ディスプレイキャプチャ方式は、ＧＤＩレンダリングテクノロジーによってレンダリングされた画面をキャプチャし、実現方式は、ウィンドウキャプチャ方式によるＧＤＩレンダリングテクノロジーによってレンダリングされた画面のキャプチャと同様であり、ここで、関数ＧｅｔＤＣ(ｈｗｎｄ)のハンドルｈｗｎｄは、ＮＵＬＬに設定する必要があり、つまり、ディスプレイキャプチャモードは、関数ＧｅｔＤＣ(ＮＵＬＬ)関数を介して、ＧＤＩテクノロジによってレンダリングされたフルスクリーン画面のキャプチャを実現できる。
【００５５】
ゲームキャプチャは、Ｄ３Ｄ、ＤＤｒａｗまたはＯｐｅｎＧＬなどのレンダリングテクノロジーを使用してレンダリングされた画像をキャプチャすることができる。
【００５６】
Ｄ３Ｄレンダリングテクノロジーによってレンダリングされた画面をゲームキャプチャ方式でキャプチャすることを例とする。
【００５７】
具体的には、ＨＯＯＫアプリケーションプログラミングインターフェース（Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｇｒａｍｍｉｎｇ Ｉｎｔｅｒｆａｃｅ、ＡＰＩ）を介して、Ｄ３Ｄテクノロジを使用してレンダリングされた画面のキャプチャを実現することができる。
【００５８】
以下、ゲームキャプチャ方式でＤ３Ｄレンダリングテクノロジーによりレンダリングされた画面をキャプチャするプロセスを詳しく説明する。
【００５９】
なお、Ｄ３Ｄレンダリングテクノロジーを使用して画面をレンダリングする場合、ｐｒｅｓｅｎｔ（）関数を呼び出す必要がある。
【００６０】
具体的なプロセスとして、第１のピクチャ取得関数をｐｒｅｓｅｎｔ（）関数に置き換え、Ｄ３Ｄレンダリングテクノロジーを使用して毎回ｐｒｅｓｅｎｔ（）関数を呼び出して画面をレンダリングする場合、毎回第１のピクチャ取得関数を呼び出すことによって、画面のキャプチャを実現する。ここで、第１のピクチャ取得関数は、バックバッファピクチャ（表示されようとするピクチャ）を取得するために使用されている。
【００６１】
また、第１のピクチャ取得関数が画面のキャプチャを実現した後、再度ｐｒｅｓｅｎｔ（）関数を呼び出してフロント・バックバッファピクチャの交換を実現し(画面のレンダリングを実現し)、ここで、ｐｒｅｓｅｎｔ（）関数は、フロントバッファピクチャ（表示中のピクチャ）とバックバッファピクチャ（表示されようとするピクチャ）を交換するために使用されている。
【００６２】
なお、ゲームキャプチャは、一定の不安定性を持っている。ゲームがＨＯＯＫアプリケーションプログラミングインターフェース（ＡＰＩ）をキャプチャするためには、ローカルな管理者権限を取得する必要があるため、管理者権限を取得できない場合、ゲームは第１のアプリケーションによって出力された画面をキャプチャすることができない。
【００６３】
本発明では、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、存在しない場合、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャする。
【００６４】
本発明では、第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面をキャプチャし、図３に示すように、ステップ１０２は、以下のステップを含み得るが、これらに限定されない。
【００６５】
ステップＳ２１において、前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定する。
【００６６】
以下、表１を参照して第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係を詳しく説明する。
【００６７】
【表１】
2021522721.tif 000010
【００６８】
ここで、０は、どのような適切なキャプチャ方式（ウィンドウキャプチャ、ウィンドウキャプチャ方式且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定すること、またはゲームキャプチャ）を採用するかを自動的に検出することを表し、１は、ウィンドウキャプチャ方式を強制的に採用し、且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定することを表し、２は、ウィンドウキャプチャ方式を強制的に採用することを表し、３は、ゲームキャプチャを強制的に採用することを表す。
【００６９】
表１を参照すると、ゲーム名称が「リーグ・オブ・レジェンド」であるゲームアプリケーションを例にとし、当該ゲームアプリケーションは、以下の３つのプロセスを含み得るが、これらに限定されない。
【００７０】
プロセス１として、ゲーム登録プロセス（Ｃｌｉｅｎｔ）である。
【００７１】
プロセス２として、ＰＶＰ.Ｎｅｔクライアントオープンプロセス（ＬｏｌＣｌｉｅｎｔ）である。
【００７２】
プロセス３として、ゲームプロセス（Ｌｅａｇｕｅ ｏｆ Ｌｅｇｅｎｄｓ）である。
【００７３】
表１から分かるように、プロセス１に関連（マッピング）するキャプチャ方式は、キャプチャ方式０であり、プロセス２に関連（マッピング）するキャプチャ方式は、キャプチャ方式０であり、プロセス３に関連（マッピング）するキャプチャ方式は、キャプチャ方式３である。
【００７４】
なお、プロセス１とプロセス２によって出力された画面がいずれもフルスクリーンモードになっていないため、ウィンドウキャプチャ、ウィンドウキャプチャ方式且つＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定すること、またはゲームキャプチャのいずれかを使用することで、プロセス１とプロセス２によって出力された画面をキャプチャすることができる。
【００７５】
特に、例えば、ライブ配信プラットフォームのライブ配信ルームのいくつかのウィンドウについて、当該ウィンドウは、ウィンドウＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を有するので、ＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を設定するウィンドウキャプチャ方式を採用する必要があり、具体的に、まず、関数ＧｅｔＤＣ(ｈｗｎｄ)を介して、指定されたウィンドウのデバイスコンテキストの環境を取得することができ、ここで、ｈｗｎｄは、指定されたウィンドウのハンドルを表すために使用されている。さらに、関数ＢｉｔＢｉｔ（ｃａｐｔｕｒｅＢｉｔ）を介して前述のウィンドウのデバイスコンテキストの環境内のウィンドウテクスチャをコピーすることによって、ＧＤＩレンダリングテクノロジーによってレンダリングされたＷＳ_ＥＸ_ＬＡＹＥＲＥＤ属性を有するウィンドウ画面のキャプチャを実現できる。
【００７６】
また、プロセス３によって出力された画面が主にフルスクリーンモードであるため、ゲームキャプチャ方式(キャプチャ方式３)を使用して、プロセス３によって出力された画面をキャプチャする。
【００７７】
ステップＳ２２において、確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャする。
【００７８】
選択肢の一つとして、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャすることができ、図４に示すように、ステップ１０３は、以下のステップを含み得るが、これらに限定されない。
【００７９】
ステップＳ３１において、第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面を同時にキャプチャする。
【００８０】
具体的に、第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み得るが、これらに限定されない。第２のキャプチャ方式は、ゲームキャプチャを含み得る。なお、ゲーム画面を描画する場合にのみ、ゲームキャプチャは画面をキャプチャすることができる。
【００８１】
ここで、第１の時間閾値は設定可能であり、好ましくは、第１の時間閾値は１５秒であってもよい。第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）に関連し、つまり、異なるアプリケーションに関連する第１の時間閾値は異なる。例えば、いくつかの簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、いくつかの比較的複雑な、メモリ使用量の大きいゲームアプリケーションに関連する第１の時間閾値は比較的に大きく、例えば１５.５秒、１６秒などである。これは、簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、上記の比較的複雑な、メモリ使用量の大きいゲームアプリケーションの起動時間が比較的に長いためである。
【００８２】
したがって、合理的なキャプチャ方式を採用する観点から、複雑な、メモリ使用量の大きいゲームアプリケーションについては、第１の時間閾値を比較的大きいものに設定することができ、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップ２を参照してください。
【００８３】
選択肢の一つとして、第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）を実行するデバイスに関連し、つまり、アプリケーションを実行する異なるデバイスに関連した第１の時間閾値は、異なっている。例えば、いくつかのハードウェア構成（例えば、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、中央処理装置）周波数、ＣＰＵ数、またはＣＰＵ実行メモリサイズ）の高いアプリケーションを実行するデバイスと比較して、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスに関連する第１の時間閾値は比較的に大きく、例えば１５.５秒、１６秒などである。これは、いくつかのハードウェア構成の高いアプリケーションを実行するデバイスと比較して、上記のいくつかのハードウェア構成の低いアプリケーションを実行するデバイスでは、同一アプリケーションを起動する時間が比較的に長いためである。
【００８４】
したがって、合理的なキャプチャ方式を採用する観点から、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスについては、第１の時間閾値を比較的大きいものに設定することができ、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップＳ３２を参照してください。
【００８５】
ステップＳ３２において、第１の時間閾値の範囲内で、第１のアプリケーションによって出力された画面が第２のキャプチャ方式によってキャプチャされた場合、第２のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、および、第１のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止し、第１のアプリケーションによって出力された画面が第２のキャプチャ方式によってキャプチャされない場合、第１のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、および、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止する。
【００８６】
選択肢の一つとして、前記第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得し、ひいては、前記エンコードされた画面をサーバに送信してもよく、ここで、当該サーバは、ライブ配信プラットフォームのサーバであってもよい。
【００８７】
選択肢の一つとして、前記第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャする前に、
第１のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む。
【００８８】
以下、アプリケーションの起動時に、第１のキャプチャ方式が第２のキャプチャ方式よりも先に第１のアプリケーションによって出力された画面をキャプチャできる理由について詳しく説明する。理由は、以下の通りである。
【００８９】
アプリケーションの起動時には多くのリソースをロードしてから、画像の描画を開始し、第２のキャプチャ方式は、アプリケーションがレンダリング（描画）を行うときにのみ、画面をキャプチャでき、しかし、第１のキャプチャ方式はアプリケーションの起動の最初から画面をキャプチャできるため、第１のキャプチャ方式は、第２のキャプチャ方式で画面をキャプチャした前に画面をキャプチャすることができる。
【００９０】
選択肢の一つとして、第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットする。
【００９１】
具体的に、第１のアプリケーションの出力画面のウィンドウが最小化された場合、第１の時間閾値をリセットすることができ、第１のアプリケーションの出力画面が最大化された場合、リセットされた第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式を採用して第１のアプリケーションの出力画面を同時にキャプチャする。
【００９２】
なお、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャした場合、第２のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、同時に、第１のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止することができる。理由は、以下の通りであり、第１のキャプチャ方式に対して、第２のキャプチャ方式のキャプチャ効率はより高い。また、第１のキャプチャ方式に対して、第２のキャプチャ方式は、第１のアプリケーションによって出力された画面をキャプチャする際に、プロセッサのより小さい実行メモリのみを占有することができる。
【００９３】
以上のように、本発明は、画面キャプチャ方法に関する。具体的に、本発明は、第１のキャプチャポリシーまたは第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャし、第１のアプリケーションによって出力された画面をほとんどうまくキャプチャすることができ、キャプチャ方式が正しくないため画面をキャプチャすることができないという問題を解決し、キャスターがライブ配信中にブラックスクリーンになるという問題を防止した。したがって、本発明を採用することにより、ユーザ体験を大幅に向上させることができる。
【００９４】
本発明の実施例を容易に実施するために、本発明では、図１の実施例に記載された方法を実現するための端末が提供される。図５は、本発明による端末の概略ブロック図である。図５に示すように、端末２００は、検出ユニット２０１およびキャプチャユニット２０３を含む。
【００９５】
検出ユニット２０１は、実行された第１のアプリケーションに関連する第１の情報を検出するために使用され、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用される。
【００９６】
キャプチャユニット２０４は、第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャするために使用される。
【００９７】
前記キャプチャユニット２０４は、前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャするためにも使用される。
【００９８】
選択肢の一つとして、図５に示すように、端末２００は、第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在するかどうかを判断するために使用される判断ユニット２０２をさらに含み、ここで、前記第１のデータベースは、アプリケーションに関連する第１の情報と、前記アプリケーションによって出力された画面に関連するキャプチャ方式を含むことができる。
【００９９】
選択肢の一つとして、判断ユニット２０２は、具体的に、
第１のアプリケーションに関連する第１の情報を第１のデータベースにおけるデータと比較することによって、第１のデータベースに第１のアプリケーションに関連する第１の情報が存在するかどうかを判断するために使用されることができる。
【０１００】
なお、記録された各アプリケーション（例えばゲームアプリケーション）によって出力された各画面を成功にキャプチャしたことに対応するキャプチャ方式に基づいて、第１のデータベースを作成することができ、ここで、異なる画面は、異なるキャプチャ方式に対応する。
【０１０１】
なお、第１のデータベースを記憶する方式は、以下の２つの方式を含むことができるが、これらに限定されない。
【０１０２】
第１の方式として、第１のデータベースを端末ローカルに記憶する。
【０１０３】
第２の方式として、第１のデータベースを端末ローカルに接続されたクラウドサーバーに記憶する。
【０１０４】
なお、記録された各アプリケーション（例えばゲームアプリケーション）によって出力された各画面を成功にキャプチャしたことに対応するキャプチャ方式に基づいて、第１のデータベースを作成することができ、ここで、異なる画面は、異なるキャプチャ方式に対応する。
【０１０５】
キャプチャユニット２０３は、具体的に、
第１のキャプチャポリシーによって、第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、第１のアプリケーションによって出力された画面（動画画面）をキャプチャし、以下のステップを含み得るが、これらに限定されない。
【０１０６】
ステップ１において、前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連（マッピング）関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定する。
【０１０７】
ステップ２において、確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャする。
【０１０８】
選択肢の一つとして、第２のキャプチャポリシーによって、第１のアプリケーションによって出力された画面をキャプチャすることは、以下のステップを含み得るが、これらに限定されない。
【０１０９】
ステップ１において、第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面を同時にキャプチャする。
【０１１０】
なお、第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み得るが、これらに限定されない。第２のキャプチャ方式は、ゲームキャプチャを含み得る。
【０１１１】
ここで、第１の時間閾値は設定可能であり、好ましくは、第１の時間閾値は１５秒であってもよい。第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）に関連し、つまり、異なるアプリケーションに関連する第１の時間閾値は異なる。いくつかの簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、いくつかの比較的複雑な、メモリ使用量の大きいゲームアプリケーションに関連する第１の時間閾値は比較的に大きい。これは、簡単な、メモリ使用量の小さいゲームアプリケーションと比較して、上記の比較的複雑な、メモリ使用量の大きいゲームアプリケーションの起動時間が比較的に長いためである。したがって、合理的なキャプチャ方式を採用する観点から、複雑な、メモリ使用量の大きいゲームアプリケーションについては、第１の時間閾値を比較的大きいものに設定すべきであり、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップ２を参照してください。
【０１１２】
選択肢の一つとして、第１の時間閾値は、アプリケーション（例えば、ゲームアプリケーション）を実行するデバイスに関連し、つまり、アプリケーションを実行する異なるデバイスに関連した第１の時間閾値は、異なっている。いくつかのハードウェア構成（例えば、ＣＰＵ周波数、ＣＰＵ数、またはＣＰＵ実行メモリサイズ）の高いアプリケーションを実行するデバイスと比較して、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスに関連する第１の時間閾値は比較的に大きい。これは、いくつかのハードウェア構成の高いアプリケーションを実行するデバイスと比較して、上記のいくつかのハードウェア構成の低いアプリケーションを実行するデバイスでは、同一アプリケーションを起動する時間が比較的に長いためである。
【０１１３】
したがって、合理的なキャプチャ方式を採用する観点から、いくつかのハードウェア構成の低いアプリケーションを実行するデバイスについては、第１の時間閾値を比較的大きいものに設定することができ、さもなければ、アプリケーションによって出力された画面を第２のキャプチャ方式でキャプチャするのに適していたが、第１のキャプチャ方式を採用し、詳細について、以下のステップ２を参照してください。
【０１１４】
ステップ２において、第１の時間閾値の範囲内で、第１のアプリケーションによって出力された画面が第２のキャプチャ方式によってキャプチャされた場合、第２のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、および、第１のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止し、第１のアプリケーションによって出力された画面が第２のキャプチャ方式によってキャプチャされない場合、第１のキャプチャ方式を採用して、第１のアプリケーションによって出力された画面をキャプチャし、および、第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャすることを停止する。
【０１１５】
端末２００は、検出ユニット２０１、判断ユニット２０２、およびキャプチャユニット２０３の他に、エンコードユニット、送信ユニット（図５には図示せず）をさらに含むことができる。
【０１１６】
エンコードユニットは、上述した第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用される。
【０１１７】
送信ユニットは、エンコードユニットによってエンコードされた第１のキャプチャ方式または第２のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用され、本発明では、当該サーバは、ライブ配信プラットフォームサーバーであってもよい。
【０１１８】
エンコードユニットは、上述した第２のキャプチャ方式によって、第１のアプリケーションによって出力された画面をキャプチャする前に、第１のキャプチャ方式によってキャプチャされた第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得するために使用されてもよい。
【０１１９】
送信ユニットは、上述したエンコードユニットによってエンコードされた第１のキャプチャ方式によってキャプチャされた画面をサーバに送信するために使用されてもよい。
【０１２０】
以下、アプリケーションの起動時に、第１のキャプチャ方式が第２のキャプチャ方式よりも先に第１のアプリケーションによって出力された画面をキャプチャできる理由について詳しく説明する。理由は、以下の通りである。
【０１２１】
アプリケーションの起動時には多くのリソースをロードしてから、画像の描画を開始し、第２のキャプチャ方式は、アプリケーションがレンダリング（描画）を行うときにのみ、画面をキャプチャでき、しかし、第１のキャプチャ方式はアプリケーションの起動の最初から画面をキャプチャできるため、第１のキャプチャ方式は、第２のキャプチャ方式で画面をキャプチャした前に画面をキャプチャすることができる。
【０１２２】
端末２００は、検出ユニット２０１、判断ユニット２０２、およびキャプチャユニット２０３，エンコードユニット、送信ユニットの他に、リセットユニット（図５には図示せず）をさらに含むことができる。
【０１２３】
リセットユニットは、第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットする。
【０１２４】
具体的に、第１のアプリケーションの出力画面のウィンドウが最小化された場合、第１の時間閾値をリセットすることができ、第１のアプリケーションの出力画面が最大化された場合、リセットされた第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式を採用して第１のアプリケーションの出力画面を同時にキャプチャする。
【０１２５】
図５の端末２００に含まれる機能モジュールの具体的な実施形態については、前述の実施形態を参照することができ、ここでは説明を省略することが理解できる。
【０１２６】
図６は、本発明による別の端末の概略構成図である。本発明の実施例では、端末は、携帯電話、タブレットコンピュータ、パーソナルデジタルアシスタント（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔ、ＰＤＡ）、モバイルインターネットデバイス（Ｍｏｂｉｌｅ Ｉｎｔｅｒｎｅｔ Ｄｅｖｉｃｅ、ＭＩＤ）、スマートウェアラブルデバイス（例えば、スマート腕時計、スマートハンドヘルド）などの様々なデバイスを含むことができ、本発明の実施例はこれを限定しない。図６に示すように、端末３００は、ベースバンドチップ３０１と、メモリ３０２（１つまたは複数のコンピュータ可読記憶媒体）と、周辺システム３０３とを含むことができる。これらのコンポーネントは、１つまたは複数の通信バス３０４上で通信することができる。
【０１２７】
ベースバンドチップ３０１は、１つ以上のプロセッサ（ＣＰＵ）３０５、１つ以上のグラフィックプロセッサ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ、ＧＰＵ）３０６を含む。
【０１２８】
プロセッサ３０５は、第１のアプリケーションによって出力された画面をキャプチャするために使用されてもよいことが理解できる。グラフィックプロセッサ３０６は、第１のアプリケーションによって出力された画面をレンダリング（描画）するために使用されてもよい。
【０１２９】
メモリ３０２は、プロセッサ３０５とカップリングされ、様々なソフトウェアプログラムおよび／または複数セットの指令を記憶するために使用されることができる。具体的な実施形態では、メモリ３０２は、高速ランダムアクセスメモリを含み、且つ不揮発性メモリを含んでもよく、例えば、１つ以上の磁気ディスク記憶装置、フラッシュメモリ装置、または他の不揮発性ソリッドステートストレージデバイスが挙げられる。メモリ３０２は、ＡＮＤＲＯＩＤ（登録商標）、ＩＯＳ、ＷＩＮＤＯＷＳ（登録商標）、またはＬＩＮＵＸなどの埋め込みオペレーティングシステムなどのオペレーティングシステム（以下、簡単にシステムと呼ぶ）を記憶してもよい。メモリ３０２は、ネットワーク通信プログラムを記憶してもよく、当該ネットワーク通信プログラムは、１つ以上の追加デバイス、１つ以上の端末デバイス、１つ以上のネットワークデバイスと通信するために使用されてもよい。メモリ３０２は、ユーザインターフェースプログラムを記憶してもよく、当該ユーザインターフェースプログラムは、グラフィカル操作インターフェースを介して、アプリケーションのコンテンツをリアルに表示し、メニュー、ダイアログボックス、およびボタンなどの入力コントロールを介して、ユーザによるアプリケーションの制御操作を受信してもよい。
【０１３０】
メモリ３０２は、第１のアプリケーション、第１のアプリケーションに関連する第１の情報を記憶するために使用されてもよく、第１の情報は、第１のアプリケーションの属性を表すために使用されてもよいことが理解できる。
【０１３１】
メモリ３０２は、１つ以上のアプリケーションを記憶してもよい。図６に示すように、これらのアプリケーションには、ソーシャルアプリケーション（例えばＦａｃｅｂｏｏｋ）、画像管理アプリケーション（例えばフォトアルバム）、マップアプリケーション（例えばＧｏｏｇｌｅマップなど）、ブラウザ（例えばＳａｆａｒｉ、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ）などが含まれている。
【０１３２】
周辺システム３０３は、主に端末３００とユーザ／外部環境との間のインタラクティブ機能を実現するために使用され、主に端末３００の入出力デバイスを含む。具体的な実施形態では、周辺システム３０３は、ディスプレイコントローラ３０７と、カメラコントローラ３０８と、マウス・キーボードコントローラ３０９と、オーディオコントローラ３１０とを含むことができる。ここで、各コントローラは、それぞれの対応する周辺デバイス（ディスプレイ３１１、カメラ３１２、マウス・キーボード３１３、およびオーディオ回路３１４など）とカップリングされてもよい。いくつかの実施例では、ディスプレイ３１１は、自己容量式のフローティングタッチパネルを配置したディスプレイであっても良いし、赤外線式のフローティングタッチパネルを配置したディスプレイであっても良い。いくつかの実施例では、カメラ３１２は、３Ｄカメラであってもよい。なお、周辺システム３０３は、他のＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ、入出力）周辺機器をさらに含んでもよい。
【０１３３】
端末３００は、本発明の実施例による一例に過ぎず、端末３００は、図示された構成要素よりも多くまたは少ない構成要素を有してもよく、２つ以上の構成要素を組み合わせてもよく、または構成要素の異なる配置を有してもよいことが理解すべきである。
【０１３４】
図６の端末３００に含まれる機能モジュールの具体的な実施形態については、図１の方法の実施例を参照することができ、ここでは説明を省略することが理解できる。
【０１３５】
本発明は、コンピュータ可読記憶媒体に関し、当該コンピュータ可読記憶媒体には、コンピュータプログラムが記憶され、当該コンピュータプログラムがプロセッサによって実行されるとき、上記の画面キャプチャ方法が実現される。
【０１３６】
当該コンピュータ可読記憶媒体は、例えば端末のハードディスクやメモリなど、前述の実施形態のいずれかで説明された端末の内部記憶ユニットであってもよい。当該コンピュータ可読記憶媒体は、例えば端末に搭載されているプラグインハードディスク、スマートメモリカード（Ｓｍａｒｔ Ｍｅｄｉａ（登録商標） Ｃａｒｄ、ＳＭＣ）、セキュリティデジタル（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ、ＳＤ）カード、フラッシュカード（Ｆｌａｓｈ Ｃａｒｄ）などの端末の外部記憶装置であってもよい。さらに、当該コンピュータ可読記憶媒体は、端末の内部記憶ユニットおよび外部記憶装置の両方を含むこともできる。当該コンピュータ可読記憶媒体は、コンピュータプログラムおよび端末に必要な他のプログラムとデータを記憶するために使用される。当該コンピュータ可読記憶媒体は、出力されたデータまたは出力されようとするデータを一時的に記憶するために使用されてもよい。
【０１３７】
本発明は、コンピュータプログラム製品にさらに関し、当該コンピュータプログラム製品は、コンピュータプログラムを記憶する非一時的コンピュータ可読記憶媒体を含み、当該コンピュータプログラム製品は、上記の方法の実施例に記載された任意の方法の一部またはすべてをコンピュータに実行させるように動作可能である。当該コンピュータプログラム製品は、ソフトウェアインストールパッケージであってもよく、当該コンピュータは、電子デバイスを含む。
【０１３８】
当業者は、本明細書に開示された実施例を参照して説明された様々な例のユニットおよびアルゴリズムステップを、電子ハードウェア、コンピュータソフトウェア、または両方の組み合わせで実現することができることを認識することができ、ハードウェアとソフトウェアの互換性を明確に説明するために、上記の説明では、様々な例の構成およびステップが機能別に一般的に説明された。これらの機能がハードウェアで実行されるかソフトウェアで実行されるかは、技術案の特定の応用および設計制約条件に依存する。専門技術者は、特定の応用ごとに、異なる方法を使用することによって、説明された機能を実現することができるが、このような実現は、本願の範囲を超えていると考えてはならない。
【０１３９】
当業者は、説明の便宜および簡略化のために、上述の端末およびユニットの具体的な作動プロセスについては、前述の方法の実施例における対応するプロセスを参照できることを明確に理解でき、ここでは説明を省略する。
【０１４０】
本発明によるいくつかの実施例において、開示された端末および方法は、他の方式で実現されうることが理解すべきである。例えば、各例の構成およびステップを説明した。これらの機能がハードウェアで実行されるかソフトウェアで実行されるかは、技術案の特定の応用および設計制約条件に依存する。専門技術者は、特定の応用ごとに、異なる方法を使用することによって、説明された機能を実現することができるが、このような実現は、本発明の範囲を超えていると考えてはならない。
【０１４１】
以上で説明された端末の実施例は単なる例示であり、例えば、前記ユニットの分割は、論理的な機能の分割にすぎず、実際に実現するときに、他の分割方式が存在する場合があり、例えば、複数のユニットまたはコンポーネントを組み合わせたり、別のシステムに統合したり、いくつかの特徴を無視したり実行しないことができる。また、表示または説明される相互間のカップリングまたは直接カップリングまたは通信接続は、いくつかのインターフェース、端末またはユニットを介した間接カップリングまたは通信接続であってもよいし、電気的、機械的、または他の形で接続されてもよい。
【０１４２】
前記分離コンポーネントとして説明されたユニットは、物理的に分離されてもよいし、物理的に分離されていなくてもよいし、ユニットとして表示されたコンポーネントは、物理ユニットであってもよいし、物理ユニットでなくてもよいし、１つの場所に配置されてもよいし、複数のネットワークユニットに分散されてもよい。本発明の実施例の目的は、実際の必要に応じて、そのうちの一部または全部のユニットを選択することによって達成されることができる。
【０１４３】
また、本発明の各実施例における各機能ユニットが１つの処理ユニットに統合されてもよいし、各ユニットが物理的に単独で存在してもよいし、２つ以上のユニットが１つのユニットに統合されてもよい。上述した統合されたユニットは、ハードウェアの形で実現されてもよいし、ソフトウェア機能ユニットの形で実現されてもよい。
【０１４４】
上述した統合されたユニットがソフトウェア機能ユニットの形で実現され、且つ独立した製品として販売されたり、使用されたりする場合には、１つのコンピュータ可読記憶媒体に記憶されてもよい。このような理解に基づいて、本発明に記載された技術案に関し、本質的に、従来技術に貢献する部分、または当該技術案の全部または一部は、ソフトウェア製品の形で具現化されることができ、当該コンピュータソフトウェア製品は、１つの記憶媒体に記憶され、本発明の各実施例で説明された方法のステップのすべてまたは一部を１台のコンピュータデバイス（パーソナルコンピュータ、サーバ、またはネットワークデバイスなどであり得る）に実行させる若干の指令を含む。また、上述した記憶媒体は、Ｕディスク、リムーバブルハードディスク、読み取り専用メモリ（Ｒｅａｄ−Ｏｎｌｙ Ｍｅｍｏｒｙ、ＲＯＭ)、ランダムアクセスメモリ(Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ、ＲＡＭ)、磁気ディスク、光ディスクなど、プログラムコードを記憶することができる種々の媒体を含む。
【０１４５】
上記の説明は、本発明の具体的な実施例に過ぎないが、本発明の保護範囲はこれに限定されず、本技術分野に詳しい任意の技術者は、本発明で開示された技術の範囲内で、様々な等価的な修正または置換を容易に想到し、これら修正または置換は、本発明の保護範囲内に含まれるべきである。したがって、本発明の保護範囲は、請求項の保護範囲に準じるべきである。
【符号の説明】
【０１４６】
201  検出ユニット
202  判断ユニット
203  キャプチャユニット
301  ベースバンドチップ
302  メモリ
303  周辺システム
305  プロセッサ（ＣＰＵ）
306  グラフィックプロセッサ（ＧＰＵ）
307  ディスプレイコントローラ
308  カメラコントローラ
309  マウス・キーボードコントローラ
310  オーディオコントローラ
311  ディスプレイ（フローティングタッチ）
312  カメラ（例えば３Ｄカメラ）
313  マウス・キーボード
314  オーディオ回路
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されることと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、
第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む、
ことを特徴とする画面キャプチャ方法。
【請求項２】
前記第１のキャプチャポリシーまたは前記第２のキャプチャポリシーによってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む、
ことを特徴とする請求項１に記載の方法。
【請求項３】
前記第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
前記第１のデータベースにおけるプリセット画面とキャプチャ方式との関連関係に従って、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式を確定することと、
確定された前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式に基づいて、前記第１のアプリケーションによって出力された画面をキャプチャすることと、
を含む、
ことを特徴とする請求項１に記載の方法。
【請求項４】
前記第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることは、
第１の時間閾値の範囲内で、第１のキャプチャ方式と第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面を同時にキャプチャすることと、
前記第１の時間閾値の範囲内で、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされた場合、前記第２のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第１のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止し、前記第１のアプリケーションによって出力された画面が前記第２のキャプチャ方式によってキャプチャされない場合、前記第１のキャプチャ方式を採用し続けて、前記第１のアプリケーションによって出力された画面をキャプチャし、および、前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャすることを停止することと、
を含む、
ことを特徴とする請求項１に記載の方法。
【請求項５】
前記第２のキャプチャ方式によって、前記第１のアプリケーションによって出力された画面をキャプチャする前に、
前記第１のキャプチャ方式によってキャプチャされた前記第１のアプリケーションによって出力された画面をエンコードし、エンコードされた画面を取得することと、
前記エンコードされた画面をサーバに送信することと、
をさらに含む、
ことを特徴とする請求項４に記載の方法。
【請求項６】
前記第１のアプリケーションの出力画面のウィンドウが最小化された場合、前記第１の時間閾値をリセットすることをさらに含む、
ことを特徴とする請求項４または５に記載の方法。
【請求項７】
前記第１のキャプチャ方式は、ウィンドウキャプチャまたはディスプレイキャプチャを含み、
前記第２のキャプチャ方式は、ゲームキャプチャを含む、
ことを特徴とする請求項４または５に記載の方法。
【請求項８】
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用される検出ユニットと、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャするために使用されるキャプチャユニットと、
を含み、
前記キャプチャユニットは、前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャするためにも使用される、
ことを特徴とする端末。
【請求項９】
プロセッサおよびメモリを含み、前記メモリは、アプリケーションコードを記憶するために使用され、前記プロセッサは、前記アプリケーションコードを呼び出すことにより、以下の方法を実行するように構成され、即ち、
実行された第１のアプリケーションに関連する第１の情報を検出し、前記第１の情報は、前記第１のアプリケーションの属性を表すために使用されること、
第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在する場合、第１のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面に関連するキャプチャ方式で、前記第１のアプリケーションによって出力された画面をキャプチャすること、
前記第１のデータベースに前記第１のアプリケーションに関連する第１の情報が存在しない場合、第２のキャプチャポリシーによって、前記第１のアプリケーションによって出力された画面をキャプチャすることである、
ことを特徴とする端末。
【請求項１０】
コンピュータプログラムが記憶されたコンピュータ可読記憶媒体であって、
前記コンピュータプログラムは、プログラム指令を含み、前記プログラム指令は、プロセッサによって実行されるとき、請求項１から７のいずれか１項に記載の方法を前記プロセッサに実行させる、
ことを特徴とするコンピュータ可読記憶媒体。
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2021522721.tif 000011
【図２】
2021522721.tif 000012
【図３】
2021522721.tif 000013
【図４】
2021522721.tif 000014
【図５】
2021522721.tif 000015
【図６】
2021522721.tif 000016
【国際調査報告】
2021522721.tif 000017
2021522721.tif 000018
2021522721.tif 000019
2021522721.tif 000020