Appleが、WWDC22において、まったく新しい高性能なスクリーンキャプチャフレームワークについて紹介する「Take ScreenCaptureKit to the next level」を公開しています。

スクリーンキャプチャは、Zoom、Google Meet、SharePlay、さらにはTwitchのような人気のゲームストリーミングサービスなどの画面共有アプリケーションの中心にあり、過去数年の間に私たちの仕事、勉強、コラボレーション、交流方法の新しい標準となりました。

macOS Monterey 12.3以降で利用可能になった「ScreenCaptureKit」は、強力な機能セットを備えてゼロから構築された、まったく新しい高性能なスクリーンキャプチャフレームワークです。

最初の例として、おそらく最も一般的な使用例である、単一ウィンドウのキャプチャから紹介します。

どのディスプレイに表示されているかに依存しない単一のウィンドウをキャプチャするには、まず単一ウィンドウ フィルターを使用して、1 つのウィンドウだけでフィルターを初期化することができます。

この例では、Safari ウィンドウを 1 つだけ含むようにフィルタを設定しています。
ビデオ出力にはそのウィンドウだけが含まれ、他には何も含まれません。

Safariの子ウィンドウ、ポップアップウィンドウ、その他のウィンドウは含まれません。

一方、ScreenCaptureKit のオーディオキャプチャポリシーは、常にアプリレベルで動作します。

シングルウィンドウフィルタを使用すると、ウィンドウを含むアプリケーションからのすべてのオーディオコンテンツがキャプチャされ、ビデオ出力に存在しないウィンドウからもキャプチャされます。

次にストリーム出力を見てみましょう。

この例では、左側がソース表示で、右側がストリーム出力で、ストリームフィルターには、Safariのウィンドウが1つ含まれています。

これから、キャプチャされたSafariウィンドウをスクロールしていきます。

ストリーム出力には、単一のSafariウィンドウからのライブコンテンツが含まれ、ソースディスプレイのネイティブフレームレートまで、ソースウィンドウと同じテンポで更新されます。

たとえば、120Hzのディスプレイでソースウィンドウが常に更新されている場合、ストリーム出力は最大120fpsの更新を実現できます。

ウィンドウのサイズを変更するとどうなるのか、気になる方もいらっしゃるでしょう、ストリームの出力寸法を頻繁に変更すると、メモリの追加割り当てにつながるので、推奨しません。

ストリームの出力寸法はほぼ固定されており、ソース・ウィンドウのサイズに合わせて変更されることはありません。

ソースウィンドウをリサイズした場合、ScreenCaptureKitは常にキャプチャされたウィンドウに対してハードウェアスケーリングを行うため、ソースウィンドウのサイズ変更に伴ってフレーム出力を超えることはありません。

他のウィンドウに覆われているウィンドウは、ソースウィンドウがオクルードまたは部分的にオクルードされている場合、ストリーム出力には常にウィンドウのフルコンテンツが含まれます。

また、ウィンドウが完全に画面外に出ている場合や、他のディスプレイに移動している場合にも適用されます。

また、最小化されたウィンドウの場合、ソースウィンドウが最小化されると、ストリーム出力は一時停止し、ソースウィンドウが最小化されなくなると再開されます。

次に、オーディオ出力の例では、オーディオトラックがあるSafariのウィンドウが2つあり、左側のウィンドウをキャプチャしています。

ビデオ出力には最初のウィンドウだけが含まれ、両方のSafariウィンドウのオーディオトラックがオーディオ出力に含まれることになります。

ダーティレクトは、前のフレームから新しいコンテンツがある場所を示します。

この例では、フレーム更新の領域を示すためにダーティレクトをハイライトしています。

フレーム全体を常にエンコードしたり、エンコーダーで 2 つのフレーム間の差分を計算したりする代わりに、ダーティレクトを使用して新しい更新がある領域のみをエンコードして送信し、受信側で更新を前のフレームにコピーして新しいフレームを生成することが簡単にできます。

コンテンツ形とコンテンツスケールは、キャプチャされるソースウィンドウは左側、ストリーム出力は右側にあります。

ウィンドウはサイズ変更できるため、ソースウィンドウのネイティブなバッキングサーフェスサイズはストリーム出力の寸法と一致しないことがよくあります。

この例では、キャプチャしたウィンドウはフレームの出力とアスペクト比が異なり、大きくなっています。

キャプチャされたウィンドウは、出力にフィットするように縮小されます。ここで緑色で表示されているコンテンツ矩形は、キャプチャしたコンテンツのストリーム出力上の関心領域を示しています。

また、コンテンツ スケールは、コンテンツがフィットするようにスケーリングされる量を示しています。ここでは、キャプチャされたSafariのウィンドウが0.77倍縮小されています。

77%で縮小され、フレーム内に収まっています。ここで、先ほど説明したメタデータを使用して、キャプチャしたウィンドウをできるだけ本来の姿に近づけて正しく表示することができます。

次に、コンテンツスケールを分割して、コンテンツをスケールアップし直します。

これで、キャプチャしたコンテンツは、ソースウィンドウとピクセルサイズが1対1で一致するようにスケーリングされます。

しかし、キャプチャしたウィンドウは、ターゲットディスプレイ上でどのように見えるのでしょうか？その疑問に答えるために、まずスケールファクターの仕組みから説明したいと思います。

ディスプレイのスケールファクターとは、ディスプレイやウィンドウの論理的なポイントサイズと、その裏面のピクセルサイズとの間の縮尺比を示します。

スケールファクター2、つまり2倍モードは、画面上の1点がバッキングサーフェス上の4ピクセルに相当することを意味します。

この例のようにスケールファクター2のRetinaディスプレイから、キャプチャ中にスケールファクター1の非Retinaディスプレイにウィンドウを移動させることができます。

スケールファクター1では、画面上の各1論理点が、バッキングサーフェス上の1ピクセルに対応します。

さらに、ソースディスプレイは、キャプチャされたコンテンツが表示されるターゲットディスプレイとスケールファクターが不一致である可能性があります。

キャプチャしたウィンドウを、1ポイント1ピクセルマッピングでターゲットの非Retinaディスプレイにスケーリングせずにそのまま表示すると、ウィンドウは4倍の大きさに見えます。

これを解決するには、フレームのメタデータにあるスケールファクターを、ターゲットディスプレイのスケールファクターと常に照合する必要があります。

不一致の場合、キャプチャしたコンテンツのサイズを表示する前にスケールファクターでスケーリングします。

要約すると、シングルウィンドウフィルタは、ソースウィンドウが画面外やオクルージョンにある場合でも、常にフルウィンドウのコンテンツを含めます。

これはディスプレイやスペースに依存しません。

出力は常に左上隅でオフセットされます。

ポップアップウィンドウや子ウィンドウは含まれません。

コンテンツを最適に表示するために、メタデータの使用を考慮します。

そして、オーディオには、含まれているアプリ全体のトラックが含まれています。

次は、ストリーム出力からコンテンツを削除する方法で、この例では、ビデオ会議アプリをエミュレートするテストアプリが含まれており、共有されているディスプレイのプレビューが含まれています。

このテストアプリは、プレビューに自分自身を再帰的に表示するため、いわゆるミラーホール効果が発生しています。

フルディスプレイ共有の場合でも、画面共有アプリケーションは、ミラーホール効果を避けるために、自身のウィンドウ、キャプチャプレビュー、参加者のカメラビュー、または通知ウィンドウなどの他のシステムUIを削除することが一般的です。

ScreenCaptureKit は、ディスプレイキャプチャからコンテンツをすばやく削除できる一連の除外ベースのフィルタを提供します。

除外ベースのディスプレイフィルタは、デフォルトで指定されたディスプレイからすべてのウィンドウをキャプチャします。

その後、個々のウィンドウやアプリを除外フィルタに追加して、削除を開始することができます。

設定プロパティの出力サイズですが、これは幅と高さをピクセル単位で指定します。

ソースディスプレイの寸法とアスペクト比は、必ずしも出力寸法と一致するとは限りません。フルディスプレイをキャプチャしているときにこのミスマッチが起こると、ストリーム出力にピラーやレターボックスが発生します。

また、キャプチャする領域を定義するソース矩形を指定すると、結果はフレーム出力上のデスティネーション矩形にレンダリングおよびスケーリングされます。

ScreenCaptureKit は、ハードウェアアクセラレーションによる色空間、カラーマトリックス、およびピクセルフォーマットの変換をサポートしていて、一般的な BGRA および YUV フォーマットがサポートされています。

カーソル表示が有効な場合、ストリーム出力はフレームにプリレンダリングされたカーソルを含んでいます。

これは、すべてのシステムカーソルに適用され、ここにあるカメラ型のようなカスタムカーソルにも適用されます。

画面コンテンツには、常に更新されるビデオ、ゲーム、アニメーションが含まれ、高いフレームレートが必要なものがあります。

一方、Keynoteウィンドウのように、フレームレートよりも高解像度を優先する静的なテキストを含むものもありますが、共有するコンテンツやネットワークの状況に応じて、ストリームの設定をライブで調整することができます。

Web 会議用の画面共有アプリでは、共有する正確なウィンドウを選択するオプションをユーザに提供するのが一般的です。

ScreenCaptureKit は、ライブコンテンツの更新で多数のサムネイル サイズのストリームを作成するための効率的で高性能なソリューションを提供し、実装は簡単です。

オープンソースのアプリケーション「OBS Studio」を使用しての画面と音声のキャプチャ体験をどのように変化させたかのデモを行いながら説明が行われています。

Appleは、2022年春からOBS StudioにScreenCaptureKitを実装するプロジェクト行っているそうです。（OBS Studio 28.0）

ScreenCaptureKitは、OBSの既存のCGDisplayStreamベースのキャプチャと同様のコードを利用しているため、簡単に実装することができたと説明しています。

ScreenCaptureKitは、OBSのCGWindowListCreateImageベースのキャプチャよりもオーバーヘッドが低くなっています。

つまり、画面の一部をキャプチャする場合、コンテンツ制作に使えるリソースが増えることになります。

左側は、OBSのウィンドウキャプチャの最悪の例で、このキャプチャは、CGWindowListCreateImage APIを使用しており、著しいスタッタリングがあり、テストでは、フレームレートが7fpsまで落ちました。

一方、右側のScreenCaptureKitの実装では、より滑らかな結果が得られ、かなり滑らかな動きのある出力ビデオを得ることができており、この場合、60fpsを実現しています。

OBSのRAM使用量はWindow Captureより最大15%少なくなっています。

ScreenCaptureKitのおかげで、ゲームから直接オーディオストリームをキャプチャできるようになったので、Macに通知が来ても、録画のオーディオやビデオが台無しになることはありません。

しかも、オーディオルーティングのソフトウェアを追加インストールすることなく、これが可能です。

Apple Silicon の ScreenCaptureKit が提供するすべての機能拡張を使用して「太鼓の達人 Pop Tap Beat」などのゲームを Mac から人気のストリーミングサービスにストリーミングできるようになりました。