# サーバーサイドコンポジションの概要
<a name="ssc-overview"></a>

この図は、サーバーサイドコンポジションの仕組みを示しています。

![\[サーバーサイドコンポジションを使用したステージのブロードキャスト。\]](http://docs.aws.amazon.com/ja_jp/ivs/latest/RealTimeUserGuide/images/ssc_Intro_Composite_Recording.png)


## 利点
<a name="ssc-benefits"></a>

クライアントサイドのコンポジションと比較すると、サーバーサイドコンポジションには以下の利点があります。
+ **クライアント負荷の軽減** – サーバーサイドコンポジションを使用すると、音声と動画のソースを処理および結合する負担が、個々のクライアントデバイスからサーバー側に移転します。サーバーサイドコンポジションにより、ビューを合成してIVS に送信するクライアントデバイスは、CPU とネットワークリソースを使用しなくても良くなります。つまり、視聴者のデバイスでは、リソースを大量に消費するタスクを処理しなくてもブロードキャストの視聴が可能になり、より長いバッテリー寿命と、よりスムーズな視聴体験が実現されます。
+ **一貫した品質** – サーバーサイドコンポジションでは、最終的なストリームの品質、解像度、ビットレートを正確に制御することができます。これにより、個々のデバイスの性能に関係なく、すべての視聴者に対し一貫した視聴体験が保証されます。
+ **レジリエンス** – コンポジションプロセスをサーバー上で一元化することで、ブロードキャストをより堅牢にできます。パブリッシャーのデバイスに技術的な制限がかかっていたり、変動が発生していたりしても、サーバーはそれに適応するので、すべての視聴者にスムーズなストリームを提供できます。
+ **帯域幅の効率** – コンポジションの処理はサーバーで実行されるため、ステージパブリッシャーは、ビデオを IVS にブロードキャストする帯域幅を余分に消費する必要がありません。

あるいは、クライアント側でコンポジションを実行し、ステージを IVS チャネルにブロードキャストすることもできます。「*IVS 低レイテンシーストリーミングユーザーガイド*」の「[Amazon IVS ストリームで複数ホストを有効にする](https://docs.aws.amazon.com//ivs/latest/LowLatencyUserGuide/multiple-hosts.html)」を参照してください。

## Composition のライフサイクル
<a name="ssc-composition-endpoint"></a>

下の図は、コンポジションの状態遷移を示します。

![\[サーバーサイドコンポジションリソースのライフサイクル。\]](http://docs.aws.amazon.com/ja_jp/ivs/latest/RealTimeUserGuide/images/ssc_Composition_Lifecycle.png)


概観的には、コンポジションのライフサイクルは次のとおりです。

1. ユーザーが StartComposition オペレーションを呼び出したとき、コンポジションリソースが作成されます。

1. IVS が Composition の開始に成功すると、「IVS Composition State Change (Session Start)」の EventBridge イベントが送信されます。イベントの詳細については、「[IVS Real-Time Streaming で EventBridge を使用する](eventbridge.md)」を参照してください。

1. Composition がアクティブ状態になった後は、以下のことが発生します。
   + ユーザーがコンポジションを停止 – StopComposition オペレーションが呼び出された場合、IVS によってコンポジションの適切なシャットダウンが開始され、「Destination End」イベントの後に「Session End」イベントが送信されます。
   + コンポジションが自動シャットダウンを実行 – IVS ステージが削除された、または IVS ステージにアクティブに配信する参加者がいない状態が 60 秒続いた場合、コンポジションが自動的にファイナライズされ、EventBridge イベントが送信されます。
   + 送信先の障害 – 送信先で (IVS チャネルが削除されるなどの) 予期しない障害が発生すると、その送信先は `RECONNECTING` 状態に遷移し、「Destination Reconnecting」イベントが送信されます。復旧が不可能な場合、IVS が対象の送信先を `FAILED` 状態に遷移させ、「Destination Failure」イベントが送信されます。少なくとも 1 つの送信先がアクティブであれば、IVS はコンポジションを維持します。

1. `STOPPED` あるいは `FAILED` 状態になったコンポジションは、その 5 分後に自動的にクリーンアップされます。(それ以降は、ListCompositions や GetComposition によって取得されなくなります)。

## IVS API
<a name="ssc-api"></a>

サーバーサイドコンポジションでは、主要な API 要素として以下を使用します。
+ *EncoderConfiguration* オブジェクトは、生成する動画の形式 (高さ、幅、ビットレート、その他のストリーミングパラメータ) をカスタマイズできるようにします。StartComposition オペレーションを呼び出すたびに、EncoderConfiguration を再利用できます。
+ *コンポジション*オペレーションはビデオコンポジションを追跡し、IVS チャネルに出力します。
+ *StorageConfiguration* は、コンポジションが記録されている S3 バケットを追跡します。

サーバーサイドコンポジションを使用するには、EncoderConfiguration を作成して StartComposition オペレーションを呼び出すときにアタッチする必要があります。この例では、SquareVideo EncoderConfiguration が 2 つのコンポジションで使用されています。

![\[サーバーサイドコンポジションでは 2 つの主要な API 要素を使用します。\]](http://docs.aws.amazon.com/ja_jp/ivs/latest/RealTimeUserGuide/images/ssc_IVS_API_Composite_Recording.png)


詳細については、「[IVS Real-Time Streaming API リファレンス](https://docs.aws.amazon.com//ivs/latest/RealTimeAPIReference/Welcome.html)」を参照してください。

## Layouts
<a name="ssc-api-layouts"></a>

StartComposition オペレーションには、グリッドおよび PiP (ピクチャーインピクチャー) の 2 つのレイアウトオプションがあります。

### グリッドレイアウト
<a name="ssc-api-layouts-grid"></a>

グリッドレイアウトは、ステージ参加者を等サイズのスロットのグリッドに配置します。カスタマイズ可能なプロパティがいくつか用意されています。
+ `videoAspectRatio` は、ビデオタイルのアスペクト比を制御するように参加者表示モードを設定します。
+ `videoFillMode` は、ビデオコンテンツが参加者タイルにどのように適合するかを定義します。
+ `gridGap` は、参加者タイル間の間隔をピクセル単位で指定します。
+ `omitStoppedVideo` では、停止したビデオストリームをコンポジションから除外できます。
+ `featuredParticipantAttribute` は、注目のスロットを識別します。これを設定すると、注目の参加者はメイン画面の大きなスロットに表示され、他の参加者はその下に表示されます。
+ `participantOrderAttribute` は、参加者トークンの属性値に基づきカスタム参加者の順序付けを有効にします。指定した場合、参加者は属性値で数値順に並べられ、属性がない参加者は到着時刻の順序にフォールバックします。これにより、決定論的な配置がオプションで実施でき、ロールベースのレイアウトが可能になります。

グリッドレイアウト (すべてのフィールドの有効な値とデフォルトを含む) の詳細については、「[GridConfiguration](https://docs.aws.amazon.com//ivs/latest/RealTimeAPIReference/API_GridConfiguration.html) データ型」を参照してください。

![\[サーバーサイドコンポジションのグリッドレイアウト。\]](http://docs.aws.amazon.com/ja_jp/ivs/latest/RealTimeUserGuide/images/ssc_Grid_Layout.png)


### ピクチャインピクチャ (PiP ) レイアウト
<a name="ssc-api-layouts-pip"></a>

PiP レイアウトでは、参加者をオーバーレイウィンドウに表示することができ、そのサイズ、位置、動作を設定できます。これらのプロパティには、次のものがあります。
+ `pipParticipantAttribute` は PiP ウィンドウの参加者を指定します。
+ `pipPosition` は PiP ウィンドウのコーナー位置を決定します。
+ `pipWidth` および `pipHeight` は、PiP ウィンドウの幅と高さを設定します。
+ `pipOffset` は、PiP ウィンドウのオフセット位置を、最も近いエッジからのピクセル単位で設定します。
+ `pipBehavior` は、他のすべての参加者が退出したときの PiP 動作を定義します。

グリッドレイアウトと同様に、PiP レイアウトは構成をさらにカスタマイズするための `featuredParticipantAttribute`、`omitStoppedVideo`、`videoFillMode`、`gridGap`、`participantOrderAttribute` をサポートします。`participantOrderAttribute` は、PiP ウィンドウの参加者を選択する、参加者トークンの属性値に基づきグリッド参加者を配置するという両方のカスタム参加者の順序付けを有効にします。

PiP レイアウト (すべてのフィールドの有効な値とデフォルトを含む) の詳細については、「[PipConfiguration](https://docs.aws.amazon.com//ivs/latest/RealTimeAPIReference/API_PipConfiguration.html) データ型」を参照してください。

![\[サーバーサイドコンポジションのピクチャインピクチャ (PiP) レイアウト\]](http://docs.aws.amazon.com/ja_jp/ivs/latest/RealTimeUserGuide/images/ssc_PiP_Layout.png)


**注**: サーバーサイドコンポジションのステージパブリッシャーでサポートされる最大の解像度は 1080p です。1080p を超える動画を送信するパブリッシャーは、音声のみの参加者としてレンダリングされます。

**重要**: アプリケーションが、タイルのサイズや位置など、現在のレイアウトの特定の機能に依存していないことを確認してください。*レイアウトの視覚的な改善は、いつでも導入できます*。