JP2016163131A - 情報処理装置および画像データ配信方法 - Google Patents

Abstract

【課題】様々な配信形態でコンテンツ画像データをストリーミング配信する技術を提供する。
【解決手段】実行部１１４は、操作情報に応じてゲームの画像データを生成する。受付部１１２は、画像データの配信形態の指定を受け付ける。受付部１１２が第１の配信形態の指定を受け付けると、エンコーダ１１８が、実行中のコンテンツの画像データをエンコードした第１エンコードデータを生成する。受付部１１２が第２の配信形態の指定を受け付けると、エンコーダ１１８が、実行中のコンテンツの画像データをエンコードした第２エンコードデータを生成する。受付部１１２が第１の配信形態の指定と第２の配信形態の指定を受け付けた場合に、送信処理部１２２は、第１エンコードデータおよび第２エンコードデータを、それぞれの配信先に送信する。
【選択図】図７

Description

本発明は、コンテンツの画像データを配信する技術に関する。

近年、ユーザが作成またはキャプチャした動画を共有サイトを介して共有するサービスが普及している。またユーザの端末同士がピアトーピア（Ｐ２Ｐ）で接続して、互いに直接通信することも可能となっている。このような仕組みを利用して、ユーザは様々なデータを他のユーザと共有できるようになっている。特許文献１は、配信元のゲーム装置が、受信側のゲーム装置に対してゲームのプレイ状況に関する情報を配信し、受信側のユーザが、配信元のゲーム装置で実行中のゲームに参加できるゲーム配信システムを提案している。

特許文献２は、ユーザが、離れたところにある情報処理装置にゲームの操作情報を送信し、また情報処理装置から、操作情報がゲーム進行に反映されたゲーム画像を受信する「リモートプレイ」を開示する。

特開２０１２−３４７９３号公報 国際公開第２０１３／１１１２４７号

本発明者は、情報処理装置でゲームなどのコンテンツを実行しつつ、コンテンツ画像を別の端末装置にストリーミング配信する技術の可能性に注目した。画像配信システムにおいて情報処理装置が様々な形態でコンテンツ画像データを配信できることは、システムの有用性を高め、結果としてシステムの価値を高めることになる。

そこで本発明は、様々な配信形態でコンテンツ画像データをストリーミング配信する技術を提供することを目的とする。

上記課題を解決するために、本発明のある態様の情報処理装置は、操作情報に応じてコンテンツの画像データを生成する実行部と、画像データの配信形態の指定を受け付ける受付部と、画像データを配信先に送信する送信処理部とを備える。受付部が第１の配信形態の指定と第２の配信形態の指定を受け付けた場合に、送信処理部は、第１の画像データおよび第２の画像データをそれぞれの配信先に送信する。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、記録媒体、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によると、様々な配信形態でコンテンツ画像データをストリーミング配信する技術を提供する。

情報処理装置の使用環境の例を示す図である。 （ａ）は、入力装置上面の外観構成を示し、（ｂ）は、入力装置背面の外観構成を示す図である。 情報処理装置の機能ブロックを示す図である。 情報処理装置によるゲーム画像データの配信形態の第１態様を説明するための図である。 情報処理装置によるゲーム画像データの配信形態の第２態様を説明するための図である。 情報処理装置によるゲーム画像データの配信形態の第３態様を説明するための図である。 情報処理装置の構成を示す図である。 出力装置に表示されるゲーム画面の例を示す図である。 ゲーム画像共有の選択肢を示す選択画面の例を示す図である。 ライブ中継される配信画面の例を示す図である。 ゲーム録画停止を問い合わせる確認画面の例を示す図である。 配信用画像の画質設定画面の例を示す図である。

図１は、情報処理装置１０の使用環境の例を示す。情報処理装置１０は、ユーザが操作する入力装置６と無線または有線で接続し、入力装置６はユーザの操作結果を示す操作情報を情報処理装置１０に提供する。情報処理装置１０は入力装置６から操作情報を受け付けるとシステムソフトウェアやアプリケーションソフトウェアの処理に反映し、出力装置４から処理結果を出力させる。実施例において情報処理装置１０はゲームを実行するゲーム装置であり、入力装置６はゲームコントローラなど情報処理装置１０に対してユーザの操作情報を供給する機器であってよい。

補助記憶装置２はＨＤＤ（ハードディスクドライブ）やフラッシュメモリなどの大容量記憶装置であり、ＵＳＢ（Universal Serial Bus）などによって情報処理装置１０と接続する外部記憶装置であってよく、内蔵型記憶装置であってもよい。出力装置４は画像を出力するディスプレイおよび音声を出力するスピーカを有するテレビであってよく、またコンピュータディスプレイであってもよい。出力装置４は、情報処理装置１０に有線ケーブルで接続されてよく、無線接続されてもよい。

アクセスポイント（以下、「ＡＰ」とよぶ）８は、無線アクセスポイントおよびルータの機能を有し、情報処理装置１０は、無線または有線経由でＡＰ８に接続して、外部ネットワークに接続する。

撮像装置であるカメラ７は出力装置４の近傍に設けられ、出力装置４周辺の空間を撮像する。図１ではカメラ７が出力装置４の上部に取り付けられている例を示しているが、出力装置４の側方に配置されてもよく、いずれにしても出力装置４の前方でゲームをプレイするユーザを撮像できる位置に配置される。なおカメラ７は、ステレオカメラであってよい。

ユーザは情報処理装置１０を操作するために、情報処理装置１０のＯＳ（システムソフトウェア）にログインする必要がある。システムソフトウェアにログインするユーザは、情報処理装置１０において登録されているユーザアカウントによって管理される。

以下、ゲームコントローラである入力装置６の構成を説明する。
図２（ａ）は、入力装置上面の外観構成を示す。ユーザは左手で左側把持部７８ｂを把持し、右手で右側把持部７８ａを把持して、入力装置６を操作する。入力装置６の筐体上面には、入力部である方向キー７１、アナログスティック７７ａ、７７ｂと、４種の操作ボタン７６が設けられている。４種のボタン７２〜７５には、それぞれを区別するために、異なる色で異なる図形が記されている。すなわち、○ボタン７２には赤色の丸、×ボタン７３には青色のバツ、□ボタン７４には紫色の四角形、△ボタン７５には緑色の三角形が記されている。筐体上面上において、方向キー７１と操作ボタン７６の間の平坦な領域には、タッチパッド７９が設けられる。タッチパッド７９は、ユーザが押すことで下方に沈み込み、またユーザが手を離すと元の位置に復帰する押下式ボタンとしても機能する。

２つのアナログスティック７７ａ、７７ｂの間に機能ボタン８０が設けられる。機能ボタン８０は、入力装置６の電源をオンし、同時に入力装置６と情報処理装置１０とを接続する通信機能をアクティブにするために使用される。入力装置６が情報処理装置１０と接続した後は、機能ボタン８０は、情報処理装置１０にメニュー画面を表示させるためにも使用される。

ＳＨＡＲＥボタン８１は、タッチパッド７９と方向キー７１の間に設けられる。ＳＨＡＲＥボタン８１は、情報処理装置１０におけるＯＳないしはシステムソフトウェアに対するユーザからの指示を入力するために利用される。ＯＰＴＩＯＮＳボタン８２は、タッチパッド７９と操作ボタン７６の間に設けられる。ＯＰＴＩＯＮＳボタン８２は、情報処理装置１０において実行されるアプリケーション（ゲーム）に対するユーザからの指示を入力するために利用される。ＳＨＡＲＥボタン８１およびＯＰＴＩＯＮＳボタン８２は、いずれもプッシュ式ボタンとして形成されてよい。

図２（ｂ）は、入力装置背面の外観構成を示す。入力装置６の筐体背面の上側には、タッチパッド７９が筐体上面から延設されており、筐体背面の下側には、横長の発光部８５が設けられる。発光部８５は、赤（Ｒ）、緑（Ｇ）、青（Ｂ）のＬＥＤを有し、情報処理装置１０から送信される発光色情報にしたがって点灯する。筐体背面において、上側ボタン８３ａ、下側ボタン８４ａと、上側ボタン８３ｂ、下側ボタン８４ｂとが長手方向の左右対称な位置に設けられる。上側ボタン８３ａ、下側ボタン８４ａは、それぞれユーザ右手の人差し指、中指により操作され、上側ボタン８３ｂ、下側ボタン８４ｂは、それぞれユーザ左手の人差し指、中指により操作される。上側ボタン８３はプッシュ式ボタンとして構成され、下側ボタン８４は回動支持されたトリガー式のボタンとして構成されてよい。

図３は、情報処理装置１０の機能ブロック図を示す。情報処理装置１０は、メイン電源ボタン２０、電源ＯＮ用ＬＥＤ２１、スタンバイ用ＬＥＤ２２、システムコントローラ２４、クロック２６、デバイスコントローラ３０、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０を有して構成される。

メインシステム６０は、メインＣＰＵ（Central Processing Unit）、主記憶装置であるメモリおよびメモリコントローラ、ＧＰＵ（Graphics Processing Unit）などを備える。ＧＰＵはゲームプログラムの演算処理に主として利用される。これらの機能はシステムオンチップとして構成されて、１つのチップ上に形成されてよい。メインＣＰＵは補助記憶装置２またはＲＯＭ媒体４４に記録されたゲームプログラムを実行する機能をもつ。

サブシステム５０は、サブＣＰＵ、主記憶装置であるメモリおよびメモリコントローラなどを備え、ＧＰＵを備えず、ゲームプログラムを実行する機能をもたない。サブＣＰＵの回路ゲート数は、メインＣＰＵの回路ゲート数よりも少なく、サブＣＰＵの動作消費電力は、メインＣＰＵの動作消費電力よりも少ない。サブＣＰＵは、メインＣＰＵがスタンバイ状態にある間においても動作し、消費電力を低く抑えるべく、その処理機能を制限されている。

メイン電源ボタン２０は、ユーザからの操作入力が行われる入力部であって、情報処理装置１０の筐体の前面に設けられ、情報処理装置１０のメインシステム６０への電源供給をオンまたはオフするために操作される。電源ＯＮ用ＬＥＤ２１は、メイン電源ボタン２０がオンされたときに点灯し、スタンバイ用ＬＥＤ２２は、メイン電源ボタン２０がオフされたときに点灯する。

システムコントローラ２４は、ユーザによるメイン電源ボタン２０の押下を検出する。メイン電源がオフ状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オン指示」として取得し、一方で、メイン電源がオン状態にあるときにメイン電源ボタン２０が押下されると、システムコントローラ２４は、その押下操作を「オフ指示」として取得する。

クロック２６はリアルタイムクロックであって、現在の日時情報を生成し、システムコントローラ２４やサブシステム５０およびメインシステム６０に供給する。デバイスコントローラ３０は、サウスブリッジのようにデバイス間の情報の受け渡しを実行するＬＳＩ（Large-Scale Integrated Circuit）として構成される。図示のように、デバイスコントローラ３０には、システムコントローラ２４、メディアドライブ３２、ＵＳＢモジュール３４、フラッシュメモリ３６、無線通信モジュール３８、有線通信モジュール４０、サブシステム５０およびメインシステム６０などのデバイスが接続される。デバイスコントローラ３０は、それぞれのデバイスの電気特性の違いやデータ転送速度の差を吸収し、データ転送のタイミングを制御する。

メディアドライブ３２は、ゲームなどのアプリケーションソフトウェア、およびライセンス情報を記録したＲＯＭ媒体４４を装着して駆動し、ＲＯＭ媒体４４からプログラムやデータなどを読み出すドライブ装置である。ＲＯＭ媒体４４は、光ディスクや光磁気ディスク、ブルーレイディスクなどの読出専用の記録メディアである。

ＵＳＢモジュール３４は、外部機器とＵＳＢケーブルで接続するモジュールである。ＵＳＢモジュール３４は補助記憶装置２およびカメラ７とＵＳＢケーブルで接続してもよい。フラッシュメモリ３６は、内部ストレージを構成する補助記憶装置である。無線通信モジュール３８は、Bluetooth（登録商標）プロトコルやIEEE802.11プロトコルなどの通信プロトコルで、たとえば入力装置６と無線通信する。なお無線通信モジュール３８は、ＩＴＵ（International Telecommunication Union；国際電気通信連合）によって定められたＩＭＴ−２０００（International Mobile Telecommunication 2000）規格に準拠した第３世代（3rd Generation）デジタル携帯電話方式に対応してもよく、さらには別の世代のデジタル携帯電話方式に対応してもよい。有線通信モジュール４０は、外部機器と有線通信し、たとえばＡＰ８を介して外部ネットワークに接続する。

実施例の情報処理装置１０は、ゲームなどのコンテンツを実行し、実行中のコンテンツの画像データを、様々な形態で他の端末装置にストリーミング配信する機能をもつ。情報処理装置１０は複数の配信形態を有し、ユーザにより指定された配信形態に応じてコンテンツ画像データをエンコードし、配信形態により特定される配信先に、エンコードした画像データを送信する。

図４〜図６を参照して、ゲーム画像配信システム１における情報処理装置１０が提供可能な３つの配信形態について説明する。いずれの配信形態においても情報処理装置１０は、エンコードしたコンテンツ画像データをストリーミング配信する画像配信装置として動作する。以下ではゲーム画像を、コンテンツ画像の一例として示す。

図４は、情報処理装置１０によるゲーム画像データの配信形態の第１態様を説明するための図である。なお図４〜図６において、ネットワーク３に接続する管理サーバ５が示される。管理サーバ５は、ゲーム画像配信システム１のユーザに対してゲームのネットワークサービスを提供する。管理サーバ５はユーザを識別するネットワークアカウントを管理しており、ユーザは、ネットワークアカウントを用いて、管理サーバ５が提供するネットワークサービスにサインインする。

ユーザはネットワークサービスにサインインすることで、管理サーバ５に、ゲームのセーブデータや、またゲームプレイ中に獲得した仮想的な表彰品（トロフィ）を登録できる。情報処理装置１０が他の端末装置やサーバと通信するためには、ユーザが管理サーバ５にサインインする必要がある。

図４に示す第１態様によるゲーム画像の配信形態を「シェアプレイ」と呼ぶ。シェアプレイでは、情報処理装置１０が、他のユーザが操作する端末装置１２に対して、プレイ中のゲーム画像をストリーミング配信し、ゲーム画像が複数ユーザにより共有される。ゲーム画像の配信元のユーザを「ホスト」ないしは「ホストユーザ」、配信先のユーザを「ゲスト」ないしは「ゲストユーザ」と呼ぶ。

シェプレイではゲストユーザの端末装置１２がホストユーザの情報処理装置１０からゲーム画像を提供されるため、ゲストユーザは当該ゲームソフトウェアを持っていなくてもゲームをプレイできる。なお実施例におけるシェアプレイを実行するためには、情報処理装置１０および端末装置１２がそれぞれチャットアプリケーションを実行して、両者がチャット接続していることが前提となっており、これによりユーザＡとユーザＢは、同じゲーム画像を共有しつつ、ボイスチャットやテキストチャットでコミュニケーションをとることができる。

図４に示す例ではユーザＡがホストユーザであり、ユーザＢがゲストユーザである。ユーザＡの情報処理装置１０とユーザＢの端末装置１２とはＰ２Ｐ通信で互いに接続され、端末装置１２は、情報処理装置１０と同じ機能を備えたゲーム装置であってよいが、他の種類のゲーム装置であってもよく、またスマートフォンやタブレットであってもよい。

シェアプレイには複数のモードが用意され、ホストユーザはモードを選択できる。
シェアプレイの１つめのモードは“Ｓｈａｒｅ Ｓｃｒｅｅｎ”と呼ばれ、ホストユーザがゲーム画像をゲストユーザと共有する。“Ｓｈａｒｅ Ｓｃｒｅｅｎ”はシェアプレイの基本モードであり、シェアプレイの開始時には、まず共有モードとして“Ｓｈａｒｅ Ｓｃｒｅｅｎ”が設定される。“Ｓｈａｒｅ Ｓｃｒｅｅｎ”モードでは、ゲストユーザは、ホストユーザのゲーム画像を視聴できるが、ゲーム操作をすることはできない。

シェアプレイの２つめのモードは“Ｈａｎｄ ｏｖｅｒ ｍｙ ｃｏｎｔｒｏｌｌｅｒ”と呼ばれ、ホストユーザがゲーム画像をゲストユーザと共有しつつ、ゲストユーザがホストユーザの代わりにゲーム操作を行う。“Ｈａｎｄ ｏｖｅｒ ｍｙ ｃｏｎｔｒｏｌｌｅｒ”モードでは、ホストユーザが自身のゲームの操作権をゲストユーザに渡し、したがってホストユーザは、ゲームを操作することができず、ゲストユーザのみが、ゲーム操作を行える。

シェアプレイの３つめのモードは“Ｈａｎｄ ｏｖｅｒ ａｎｏｔｈｅｒ ｃｏｎｔｒｏｌｌｅｒ”と呼ばれ、ホストユーザがゲーム画像をゲストユーザと共有しつつ、ゲストユーザが新たなプレイヤーとして参加して、ホストユーザと一緒にゲームをプレイする。つまり“Ｈａｎｄ ｏｖｅｒ ａｎｏｔｈｅｒ ｃｏｎｔｒｏｌｌｅｒ”モードでは、ホストユーザ側のゲームリソースを利用して、ホストユーザがプレイヤー１、ゲストユーザがプレイヤー２としてゲームに参加して、ホストユーザとゲストユーザとが一緒にゲーム操作を行う。

図５は、情報処理装置１０によるゲーム画像データの配信形態の第２態様を説明するための図である。第２態様によるゲーム画像の配信形態を「リモートプレイ」と呼ぶ。リモートプレイでは、ユーザＡが屋外から、自宅にある情報処理装置１０を操作して、ゲームをプレイする。

ユーザＡはリモートプレイを実行するために、端末装置１４を操作して、情報処理装置１０に接続要求を送信する。このとき情報処理装置１０のメイン電源がオフ状態にあれば、接続要求に基づいてメインシステム６０が起動される。メインシステム６０は、ゲームアイコンを配列したメニュー画像データを生成して端末装置１４に送信し、端末装置１４は、メニュー画面を表示装置に表示する。ユーザＡがメニュー画面上で所望のゲームアイコンを選択すると、端末装置１４が、その操作情報を情報処理装置１０に送信する。情報処理装置１０は、選択されたゲームを起動し、ゲーム画像データを生成して、端末装置１４に送信し、端末装置１４は、ゲームの起動画面を表示装置に表示する。

情報処理装置１０は、リモートプレイにおいて、端末装置１４からの操作情報をゲームに対する入力として受け付け、また出力装置４に出力していた出力データを端末装置１４に送信する。これにより端末装置１４は、ユーザＡの操作が反映されたゲーム画像を表示装置に表示できるようになる。端末装置１４は情報処理装置であって、たとえば携帯型のゲーム装置であってよく、またスマートフォンやタブレットであってよい。情報処理装置１０と端末装置１４とはＰ２Ｐ通信で互いに接続される。リモートプレイにおいても、情報処理装置１０と端末装置１４とが通信するためには、ユーザＡが管理サーバ５にサインインする必要がある。

図６は、情報処理装置１０によるゲーム画像データの配信形態の第３態様を説明するための図である。第３態様によるゲーム画像の配信形態を「ライブ中継」と呼ぶ。共有サーバ１１は動画共有サービスを提供し、ライブ中継では、ユーザＡがプレイしているゲーム画像データが動画の共有サーバ１１に、他のユーザが視聴できるようにストリーミング配信され、視聴ユーザは、端末装置１６、１８から共有サーバ１１にアクセスすることで、ライブ配信されているゲーム画像を視聴できる。ここでは端末装置１６がパーソナルコンピュータであって、ＡＰ８経由で共有サーバ１１に接続し、また端末装置１８がスマートフォンなどのモバイル機器であって、基地局９を経由して共有サーバ１１に接続している様子を示しているが、視聴ユーザは、情報処理装置１０と同じ端末装置でゲーム画像のライブ配信を受けてもよい。

図７は、情報処理装置１０の構成を示す。情報処理装置１０は、処理部１００および通信部１０２を備え、処理部１００は、実行しているゲームの画像をエンコードして、指定された配信形態でエンコードデータをストリーミング配信する機能をもつ。処理部１００は、操作入力部１１０、受付部１１２、実行部１１４、画像データ生成部１１６、エンコーダ１１８、制御部１２０、送信処理部１２２および出力部１２４を有する。通信部１０２は図３に示す無線通信モジュール３８および有線通信モジュール４０の機能を併せ持つ構成として表現している。

図７において、さまざまな処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、回路ブロック、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、メモリにロードされたプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

実行部１１４は、ユーザの操作情報に応じてゲームを実行して、ゲームの画像データを生成する。ゲーム画像配信システム１において、基本的に実行部１１４は、ユーザＡからの操作情報に応じてゲームを実行するが、シェアプレイの“Ｈａｎｄ ｏｖｅｒ ｍｙ ｃｏｎｔｒｏｌｌｅｒ”モードでは、ユーザＢからの操作情報に応じてゲームを実行し、またシェアプレイの“Ｈａｎｄ ｏｖｅｒ ａｎｏｔｈｅｒ ｃｏｎｔｒｏｌｌｅｒ”モードでは、ユーザＡとユーザＢからの操作情報に応じてゲームを実行することになる。

実行部１１４は、仮想空間においてゲームキャラクタを動かす演算処理を行う。実行部１１４はレンダリング処理などを行うＧＰＵ（Graphics Processing Unit）を含み、ゲームプログラムの処理結果を受けて、出力装置４に表示するゲームの画像データを生成する。実施例では、６０ｆｐｓ（フレーム／秒）のフレームレートで処理可能なゲームプログラムが実行部１１４により実行される。出力部１２４は、実行部１１４で生成されたゲーム画像を、表示画像として出力装置４から出力する。図８は、出力装置４に表示されるゲーム画面の例を示す。

エンコーダ１１８は、生成された画像データをエンコードする。メインＣＰＵの負荷を抑制するために、実施例ではハードウェアエンコーダを採用するが、ソフトウェアエンコーダを用いてもよい。エンコーダ１１８は、第１フレームレートと、第１フレームレートよりも高い第２フレームレートで画像データをエンコードする機能を有する。

実施例においてエンコーダ１１８は、最大フレームレートを６０ｆｐｓとするハードウェアエンコーダであり、第１フレームレートが３０ｆｐｓ、第２フレームレートが第１フレームレートの倍の６０ｆｐｓに設定される。そのためエンコーダ１１８は、１つの画像データを６０ｆｐｓでエンコードでき、また２つの画像データをそれぞれ３０ｆｐｓでエンコードできる。

ユーザのゲームプレイ中、エンコーダ１１８は、６０ｆｐｓで生成されるゲーム画像データを間引いて３０ｆｐｓでエンコードし、補助記憶装置２に録画している。なおゲーム画像データが３０ｆｐｓで生成されている場合には、間引くことなく３０ｆｐｓでエンコードして補助記憶装置２に録画する。この録画機能は、エンコーダ１１８に対してデフォルト設定された機能であり、ユーザは補助記憶装置２に録画したゲーム動画を、後で見て楽しんだり、また共有サーバ１１にアップロードできる。

受付部１１２は、ユーザからゲーム画像データの配信形態の指定を受け付ける。ゲーム画像配信システム１では、配信形態として、「シェアプレイ」、「リモートプレイ」、「ライブ中継」の３種類が用意されており、ユーザにより配信形態が選択されると、エンコーダ１１８が、実行中のゲーム画像データを第１フレームレート（３０ｆｐｓ）または第２フレームレート（６０ｆｐｓ）でエンコードして、送信処理部１２２が、エンコードした画像データを配信先に送信する。

画像データ生成部１１６は、受付部１１２が所定の配信形態の指定を受け付けると、所定の配信形態に合わせて加工したゲームの画像データを生成してよい。このときエンコーダ１１８は、画像データ生成部１１６により加工された画像データをエンコードする。

「シェアプレイ」、「ライブ中継」の配信形態は、ユーザが入力装置６に設けられた特定の入力部、ここではＳＨＡＲＥボタン８１を操作したことを契機として選択可能とされる。ゲームプレイ中、受付部１１２がＳＨＡＲＥボタン８１の操作情報を受け付けると、制御部１２０が、画像データの共有に関する選択肢を示す選択画像を生成して、出力部１２４が選択画面を出力装置４に表示する。

図９は、ゲーム画像共有の選択肢を示す選択画面の例を示す。この選択画面には４つの選択肢が示される。“ビデオクリップをアップロードする”は、補助記憶装置２に録画されたゲーム画像データを共有サーバ１１にアップロードすることを指定するＧＵＩ、“スクリーンショットをアップロードする”は、スクリーンショットの画像データを共有サーバ１１にアップロードすることを指定するＧＵＩ、“ゲームプレイをブロードキャストする”は、ゲームのプレイ映像を共有サーバ１１を介してライブ中継すること（図６参照）を指定するＧＵＩ、“シェアプレイをはじめる”は、ゲームのプレイ映像をＰ２Ｐ通信で他のユーザと共有すること（図４参照）を指定するＧＵＩである。この４つの選択肢のうち、“ゲームプレイをブロードキャストする”と“シェアプレイをはじめる”の２つが、情報処理装置１０において用意されているストリーミング配信の形態に対応する。

ユーザＡが指定枠２００を動かして“ゲームプレイをブロードキャストする”のＧＵＩを選択して決定ボタンを操作すると、受付部１１２が「ライブ中継」の指定を受け付け、制御部１２０は「ライブ中継」が指定されたことを画像データ生成部１１６、エンコーダ１１８および送信処理部１２２に通知する。この通知を受けて画像データ生成部１１６は、ゲーム画像とカメラ映像とを合成した表示画像データを生成して、出力部１２４が出力装置４に出力する。エンコーダ１１８は、合成した表示画像データを第１フレームレート（３０ｆｐｓ）でエンコードして、送信処理部１２２が、共有サーバ１１にエンコードデータを送信する。図６を参照して、視聴ユーザは端末装置１６、１８を操作して共有サーバ１１にアクセスすることで、ユーザＡのライブプレイを視聴する。
図１０は、ライブ中継される配信画面の例を示す。配信画面の右上のカメラ領域２１０に、カメラ７で撮像したカメラ映像が重畳されている。

図９に示す選択画面において、ユーザＡが指定枠２００を動かして“シェアプレイをはじめる”を選択して決定ボタンを操作すると、受付部１１２が「シェアプレイ」の指定を受け付け、制御部１２０は「シェアプレイ」が指定されたことを画像データ生成部１１６、エンコーダ１１８および送信処理部１２２に通知するとともに、チャットアプリケーションを起動する。ユーザＡがチャットルームにユーザＢを招待し、その後、ユーザＢがシェアプレイにゲストとして参加することで、情報処理装置１０と端末装置１２とがＰ２Ｐ通信で接続され、ユーザＡとユーザＢとがシェアプレイを開始する（図４参照）。画像データ生成部１１６は、シェアプレイ用の画像データを生成してよい。シェアプレイが開始されると、エンコーダ１１８は、ゲーム画像データを第１フレームレート（３０ｆｐｓ）でエンコードして、送信処理部１２２が、Ｐ２Ｐ通信でユーザＢの端末装置１２にエンコードデータを送信する。

以上は、ゲーム画像を他のユーザと共有する配信形態であるが、リモートプレイを実行する場合には、ユーザＡが、自身の端末装置１４でリモートプレイ用のアプリケーションを起動し、情報処理装置１０にアクセスしてゲームを起動する（図５参照）。情報処理装置１０において、受付部１１２が端末装置１４から「リモートプレイ」の指定を受け付けると、制御部１２０は「リモートプレイ」が指定されたことを画像データ生成部１１６、エンコーダ１１８および送信処理部１２２に通知する。画像データ生成部１１６は、リモートプレイ用の画像データを生成してよい。

リモートプレイでは、操作入力部１１０が、端末装置１４からの操作情報を、ゲームに対する入力として受け付ける。実行部１１４がゲームを開始すると、エンコーダ１１８は、ゲーム画像データを第１フレームレート（３０ｆｐｓ）でエンコードして、送信処理部１２２が、Ｐ２Ｐ通信でユーザＡの端末装置１４にエンコードデータを送信する。

以上のストリーミング配信においては、エンコーダ１１８のエンコード能力を２つに分け、ゲーム録画のために３０ｆｐｓで録画用データをエンコードしつつ、ゲーム画像配信のために３０ｆｐｓで配信用データをエンコードしている。情報処理装置１０は、デフォルト設定されていたエンコーダ１１８の録画機能を、他の用途に割り当て可能とすることで、ゲーム画像配信システム１の有用性を高めることができる。

具体的には、ユーザが２つの配信形態を指定した場合に、制御部１２０がエンコーダ１１８の録画用データのエンコードを停止して、２つの配信用データをエンコードするように制御する。なお実施例では、エンコーダ１１８が２つの画像データをそれぞれ３０ｆｐｓでエンコードすることを前提としているが、２０ｆｐｓの配信画像の画質が許容されるのであれば、３つの配信用データをそれぞれ２０ｆｐｓでエンコードすることも可能である。この場合、エンコーダ１１８は、ユーザが３つ以上の配信形態を指定した場合に、指定された数の配信用データをエンコードできる。

ゲームの実行中、エンコーダ１１８は録画用の画像データをエンコードして、補助記憶装置２に記録している。ゲーム実行中にＳＨＡＲＥボタン８１が操作され、「シェアプレイ」のＧＵＩが選択され（図９参照）、ユーザＡとユーザＢとの間でシェアプレイが開始されると、受付部１１２がシェアプレイの指定を受け付け、制御部１２０がエンコーダ１１８に、シェアプレイ用の画像データをエンコードするように指示する。これを受けてエンコーダ１１８は、実行中のゲームの画像データを第１フレームレート（３０ｆｐｓ）でエンコードした第１エンコードデータを生成する。第１エンコードデータは、送信処理部１２２により、ユーザＢの端末装置１２に送信される（図４参照）。

シェアプレイ中、ＳＨＡＲＥボタン８１が操作され、「ライブ中継」のＧＵＩが選択されると（図９参照）、制御部１２０は、エンコーダ１１８が録画用画像データとシェアプレイ用画像データのエンコードに使用されており、エンコード能力に空きがないことを判定する。そのため制御部１２０は、ゲーム録画を止めてよいか確認するための確認画像データを生成して、出力部１２４が確認画面を出力装置４に表示する。

図１１は、ゲーム録画停止を問い合わせる確認画面の例を示す。情報処理装置１０ではゲーム録画が標準設定されているため、ユーザに知らせることなくゲーム録画を止めることは好ましくない。そこで制御部１２０は、ゲーム画像配信のためにゲーム録画を停止する必要があるときには、その旨をユーザに知らせるようにする。

確認画面においてユーザが「はい」を選択すると、受付部１１２がライブ中継の指定を受け付け、制御部１２０が、エンコーダ１１８に、録画のためのエンコードを中止させ、ライブ中継用の画像データをエンコードするように指示する。これを受けてエンコーダ１１８は、実行中のゲームの画像データを第１フレームレート（３０ｆｐｓ）でエンコードした第２エンコードデータを生成する。第２エンコードデータは、送信処理部１２２により、共有サーバ１１に送信される（図６参照）。

このように受付部１１２が２種類の配信形態の指定を重複して受け付けた場合に、送信処理部１２２は、第１エンコードデータおよび第２エンコードデータを、それぞれの配信先に送信する。なおライブ中継用の第２エンコードデータは、カメラ領域２１０にカメラ映像が重畳されたものである一方で（図１０参照）、シェアプレイ用の第１エンコードデータにはカメラ映像が含まれてなくてよい。このように処理部１００が、複数種類の配信形態で同時に画像データをストリーミング配信できることで、ゲーム画像配信システム１の価値を高められる。

以上は、画像データの配信形態として最初にシェアプレイが選択され、次にライブ中継が選択された場合の動作であるが、最初にライブ中継が選択されて、次にシェアプレイが選択された場合の動作も同様である。なおシェアプレイは、ユーザＢがゲストとして参加を表明し、ホストであるユーザＡがユーザＢの参加を承諾することで開始されるため、ユーザＡが承諾したときに、図１１に示すような確認画面が出力装置４に表示されることが好ましい。

以下、画像データの配信形態として、最初にリモートプレイが選択された例を示す。ユーザが端末装置１４を操作して、リモートプレイを開始すると、受付部１１２がリモートプレイの指定を受け付け、制御部１２０がエンコーダ１１８に、録画用の画像データおよびリモートプレイ用の画像データをエンコードするように指示する。これを受けてエンコーダ１１８は、実行中のゲームの画像データを、それぞれ第１フレームレート（３０ｆｐｓ）でエンコードし、録画用にエンコードした画像データを補助記憶装置２に記録し、リモートプレイ用にエンコードした画像データを送信処理部１２２に提供する。送信処理部１２２は、エンコードデータを、ユーザの端末装置１４に送信する（図５参照）。

リモートプレイ中、ＳＨＡＲＥボタン８１が操作され、「ライブ中継」のＧＵＩが選択されると（図９参照）、制御部１２０は、エンコーダ１１８が録画用画像データとリモートプレイ用画像データのエンコードに使用されており、エンコード能力に空きがないことを判定する。そのため制御部１２０は、ゲーム録画を止めてよいか確認するための確認画像データを生成して、出力部１２４が確認画面を出力装置４に表示する。表示される確認画面は、図１１に示すような画面であってよい。

確認画面においてユーザが「はい」を選択すると、受付部１１２がライブ中継の指定を受け付け、制御部１２０が、エンコーダ１１８に、録画のためのエンコードを中止させ、ライブ中継用の画像データをエンコードするように指示する。これを受けてエンコーダ１１８は、実行中のゲームの画像データを第１フレームレート（３０ｆｐｓ）でエンコードしたエンコードデータを生成する。エンコードデータは、送信処理部１２２により、共有サーバ１１に送信される（図６参照）。

この例では、画像データの配信形態として、最初にリモートプレイが選択され、次にライブ中継が選択された場合の動作を示したが、最初にリモートプレイが選択され、次にシェアプレイが選択された場合の動作も同様である。

以上のように受付部１１２が２つの配信形態の指定を重複して受け付けると、エンコーダ１１８は、録画用データのエンコードを中止して、エンコードリソースを解放する。これによりエンコーダ１１８のエンコード能力をフルに利用して、２つの配信用の画像データをエンコードすることが可能となる。

なお受付部１１２が１つの配信形態の指定のみを受け付けている場合、制御部１２０は、エンコーダ１１８に、画像データを第２フレームレートでエンコードさせてもよい。配信用画像データのフレームレートはユーザＡにより予め設定され、制御部１２０は、設定されたフレームレートにしたがってエンコーダ１１８を制御する。

図１２は、配信用画像の画質設定画面の例を示す。ユーザは、出力装置４に表示された画質設定画面から画質を設定するが、リモートプレイの場合には、端末装置１４に画質設定画面が表示されてよい。ユーザはフレームレートを「高」または「標準」のいずれかに設定する。「高」を選択すると、配信用画像のフレームレートが６０ｆｐｓに設定され、「標準」を選択すると、配信用画像のフレームレートが３０ｆｐｓに設定される。この画面では「高」を選択した場合に、ゲーム録画ができなくなることをユーザに知らせている。なおユーザは、画質設定画面から配信用画像データの解像度も設定できる。

ユーザは配信用画像の画質を、配信形態ごとに設定してもよい。なおシェアプレイではゲストユーザもプレイに参加するため、ゲストユーザに画質の設定権限を与えることも可能である。しかしながらゲストユーザが「高」のフレームレートを選択すると、ホストユーザの情報処理装置１０がゲーム録画をできなくなる不利益を受けることから、シェアプレイにおいても、ホストユーザのみが画質を設定できるようにする。なおシェアプレイでは、ホストユーザとゲストユーザとがチャットでコミュニケーションできるため、チャットでゲストユーザがホストユーザに、フレームレートを「高」に変更してもらうよう頼むことは自由である。

受付部１１２が、フレームレートが「高」に設定されている配信形態の指定のみを受け付けている場合に、制御部１２０はエンコーダ１１８に、第２フレームレート（６０ｆｐｓ）で配信用画像データをエンコードするように指示する。これによりエンコーダ１１８は、６０ｆｐｓでエンコードデータを生成し、送信処理部１２２が、配信先にエンコードデータを送信する。なお、この状態で受付部１１２が、別の配信形態の指定を受け付けると、制御部１２０は、２つの配信形態での配信を可能とするべく、配信中の画像データのフレームレートを３０ｆｐｓに落とし、新たに指定された配信用画像データを３０ｆｐｓでエンコードするようにエンコーダ１１８に指示してよい。

このように配信形態のフレームレートが「高」に設定されている場合であっても、２つの配信形態の指定が重複した場合には、制御部１２０は、それぞれの配信用画像データを第１フレームレートでエンコードするようにエンコーダ１１８を制御する。なお一方の配信が終了すると、残りの配信形態に設定されているフレームレートにしたがって制御部１２０がエンコーダ１１８を制御してよい。たとえば残りの配信形態のフレームレートが「高」に設定されていれば、制御部１２０は、残りの配信形態の画像データを第２フレームレートでエンコードするようにエンコーダ１１８を制御し、残りの配信形態のフレームレートが「標準」に設定されていれば、制御部１２０は、残りの配信形態の画像データ、および録画用の画像データを、それぞれ第１フレームレートでエンコードするようにエンコーダ１１８を制御してよい。

以上、本発明を実施例をもとに説明した。この実施例は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。実施例で実行部１１４が実行するゲームは、コンテンツの一例であり、実行部１１４は、映画などの動画を実行（再生）するものであってもよい。

実施例では、３つの配信形態のうちの２つが指定されたときに、エンコーダ１１８がエンコード能力をフルに使って、２つの配信用画像データをそれぞれ３０ｆｐｓでエンコードすることを説明した。変形例では３つの配信形態に優先順位を設定し、全ての配信形態が指定された場合には、制御部１２０が、優先順位の高い２つの配信形態の画像データをエンコードするようにエンコーダ１１８を制御してもよい。

また実施例では、エンコーダ１１８が第１フレームレートと第２フレームレートとで画像データをエンコードする機能を有することを説明したが、変形例ではエンコーダ１１８が画像データを、第１の解像度と、第１の解像度よりも高い第２の解像度でエンコードする機能を有してもよい。たとえば受付部１１２が１つの配信形態の指定を受け付けたときには、エンコーダ１１８が第２の解像度で画像データをエンコード可能とし、受付部１１２が２つ以上の配信形態の指定を受け付けたときには、エンコーダ１１８が第１の解像度で画像データをエンコードしてもよい。

１・・・ゲーム画像配信システム、１０・・・情報処理装置、１１・・・共有サーバ、１２，１４，１６，１８・・・端末装置、１００・・・処理部、１０２・・・通信部、１１０・・・操作入力部、１１２・・・受付部、１１４・・・実行部、１１６・・・画像データ生成部、１１８・・・エンコーダ、１２０・・・制御部、１２２・・・送信処理部、１２４・・・出力部。

Claims (10)

1. 操作情報に応じてコンテンツの画像データを生成する実行部と、
   画像データの配信形態の指定を受け付ける受付部と、
   画像データを、配信先に送信する送信処理部と、を備え、
   前記受付部が第１の配信形態の指定と第２の配信形態の指定を受け付けた場合に、前記送信処理部は、第１の画像データおよび第２の画像データを、それぞれの配信先に送信する、
   ことを特徴とする情報処理装置。
2. ユーザにより指定可能な配信形態の１つは、１つ以上の端末装置とＰ２Ｐ通信で接続して、画像データをストリーミング配信する形態であり、
   ユーザにより指定可能な配信形態の１つは、動画の共有サーバに、画像データを他のユーザが視聴できるようにストリーミング配信する形態である、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記受付部が所定の配信形態の指定を受け付けると、所定の配信形態に合わせて加工したコンテンツの画像データを生成する画像データ生成部を、さらに備えることを特徴とする請求項１または２に記載の情報処理装置。
4. 端末装置から提供される操作情報を受け付ける操作入力部を、さらに備え、
   前記実行部は、端末装置から提供された操作情報に応じてコンテンツの画像データを生成する、
   ことを特徴とする請求項１から３のいずれかに記載の情報処理装置。
5. 第１の画像データおよび第２の画像データは、エンコードされたデータであることを特徴とする請求項１から４のいずれかに記載の情報処理装置。
6. 生成された画像データをエンコードするエンコーダを、さらに備え、
   前記受付部が第１の配信形態の指定を受け付けると、前記エンコーダが、実行中のコンテンツの画像データをエンコードした第１エンコードデータを生成し、
   前記受付部が第２の配信形態の指定を受け付けると、前記エンコーダが、実行中のコンテンツの画像データをエンコードした第２エンコードデータを生成し、
   前記受付部が第１の配信形態の指定と第２の配信形態の指定を受け付けた場合に、前記送信処理部は、第１エンコードデータおよび第２エンコードデータを、それぞれの配信先に送信する、
   ことを特徴とする請求項１から５のいずれかに記載の情報処理装置。
7. 前記エンコーダは、第１フレームレートと、第１フレームレートよりも高い第２フレームレートで画像データをエンコードする機能を有し、
   前記受付部が第１の配信形態の指定と第２の配信形態の指定を受け付けた場合に、前記エンコーダは、第１フレームレートで第１エンコードデータおよび第２エンコードデータを生成し、
   前記受付部が第１の配信形態の指定のみを受け付けた場合に、前記エンコーダは、第２フレームレートで第１エンコードデータを生成可能とする、
   ことを特徴とする請求項６に記載の情報処理装置。
8. 画像データを配信する方法であって、
   コンテンツの画像データを生成するステップと、
   画像データの配信形態の指定を受け付けるステップと、
   画像データを、配信先に送信するステップと、を備え、
   指定受付ステップが第１の配信形態の指定と第２の配信形態の指定を受け付けた場合に、送信ステップが、第１の画像データおよび第２の画像データを、それぞれの配信先に送信する、
   ことを特徴とする画像データ配信方法。
9. コンピュータに、
   コンテンツの画像データを生成する機能と、
   画像データの配信形態の指定を受け付ける機能と、
   画像データを、配信先に送信する機能と、を実現させるためのプログラムであって、
   指定受付機能が第１の配信形態の指定と第２の配信形態の指定を受け付けた場合に、送信機能が、第１の画像データおよび第２の画像データを、それぞれの配信先に送信する、
   ことを特徴とするプログラム。
10. 請求項９に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。

Images