Action & Vision Appの探求

こんにちは WWDCへようこそ

“Action & Visionアプリケーションの探求” フランク･ドープクです ブレント･ディミックと一緒に Action & Visionアプリケーションを 紹介します 本日のテーマはスマートフォンを― オブザーバーとして使った ユーザーへのフィードバックです 説明しましょう 多くのスポーツイベントで 人々はスマートフォンで 撮影して 記録しています そこで iPhoneやiPadを コーチとして― 使えないでしょうか？ ジムにまで スマートフォンを持っていき 様々なことをチェックしています しかし逆に カメラとセンサーで ユーザーの動きをチェックし リアルタイムのフィードバックを 与えましょう すでに完璧なツールが ポケットに入っています 高性能のカメラと 高速のCPUとGPUと ニューラルエンジンを搭載 包括的で 連携したAPIを 備えているので ハードウェアを活用しやすくなりました 重要なことですが すべてがデバイス上で可能です 重要である理由は２つ １つ目は すべてのデータを デバイスに保存することで ユーザーのプライバシーを保護します ２つ目は クラウドでの 分析にかかる待ち時間を なくすことができます スポーツとフィットネスで見ていきます デバイスによる分析が あらゆる人の改善に役立ちます 分析を活用する プロのアスリートをはじめ― 大勢がスポーツに熱中しています 私たちは普段 デバイスで調べ物をしたり やり方を動画で見ています しかしスポーツとフィットネスで― 次のレベルへ進みたいと思います まず共通分析を行うことが可能です 最初に 体を使って何をしたのか？ どう動いたのか？ 次に 動いていた物を調べます 例えば サッカーやテニスのボールです 場所の情報も必要です テニスのコートや サッカーのゴールなど そして どんなプレーだったか― ユーザーへのフィードバックが必要です このセッションで取り上げるのは― シンプルで理解しやすいスポーツです サンプルのアプリケーションがあるので ダウンロードしてから 話を聞いてください Action & Visionアプリケーションを 紹介します ビーンバッグトスを例に進めましょう 誰でもプレーできる シンプルなゲームです ８メートル離して ボードを２つ置きます ボードのサイズは 横60センチに縦１メートルです 端の中央に 直径15センチの穴があります プレーヤーはビーンバッグを ボードに投げます 次に対戦相手が投げて 得点を競います ボードに乗れば 得点が入り 穴に入れば さらに得点が入ります 単なる遊びかもしれませんが みんな 勝負に勝ちたいと思うものです そこで 狙いが外れた理由を 考えるでしょう そのために バッグの飛び方を見たいですよね バッグを投げた時の体勢や 投げた速さも知りたい

得点を記録する必要もあります 違うショットを 友人に見せたいかもしれない それでは 実際にゲームをしましょう スマートフォンをセットしました カメラを動画モードにして 録画します まずボードの認識が必要です カメラをパンして 固定します プレーヤーを待ちます あれは私です プレーを始めます では見ていきましょう

どのようにバッグを投げているかを 確認できます ボールの軌跡が オレンジの線で表示されます ラッキーなショットでしたね

注目してもらいたい点は プレーヤーを囲んでいる枠です プレーヤーの動きの 重要点が分かります

バッグを投げた時の角度が 表示されます

どんな投げ方をしたかも表示されます “上手投げ”や“下手投げ”と

脚の下から投げた時も “脚の下から”と出ます ビーンバッグの速度も 表示されています 得点は左下に表示され これまでの投げ方が 右下に表示されます 全部で８回 投げ終わると 集計を見られます すべての軌跡が表示され ベストショットが分かります バッグを投げた速さと角度も― 平均値が出ています もちろん最終得点も これがAction & Visionアプリケーションです 楽しんでください 次にアプリケーションの作り方です 一緒に実行すべき 重要なアルゴリズムがあります 準備段階から始めます カメラを三脚などで 固定する必要があります 次にゲームのセットアップ プレー場所を認識します そしてゲームの開始です 準備段階はボードの認識です 最初にカメラをパンしましたね 次にシーンを安定させる必要があります 例えば カメラを三脚に乗せたり 他の方法で安定させます ゲームのセットアップを 進めていきます ボードのサイズを測り プレーヤーを認識します 準備万端です ゲームが始まり すべてのプレーが見られます 上手投げ 下手投げ 脚の下からなど 投げ方を分析します 大事なことですが速さも測ります では どのアルゴリズムを使いますか？ トレーニングしたカスタムモデルで ボードを認識します VNCoreMLRequestを使って このモデルで予測を行います ボードの場所が示されます ボードを認識すると VNTranslationalImageRequestで シーンの安定性を分析します VNDetectContourRequestを実行して ボードのサイズを測ります VNDetectHumanBodyPoseRequestは 新しいリクエストで 人間を認識します VNDetectTrajectoriesRequestを使い 投げたバッグの軌跡を認識します Create MLでトレーニングした 新しいモデルが構築され― CoreMLを使って 投げ方を分類します ボードのサイズの測定と ボールの軌跡の分析を使って 投げる速さを計測します 各段階を示すために 役立つアイコンを用意しました ご覧のとおり“準備段階”に “ゲームのセットアップ”と “ゲームの開始”です 詳しく見ましょう 最初にボードを認識する必要があります Custom Object Detection Modelを作りました オブジェクト検出のテンプレートと一緒に Create MLを使いました 独自のトレーニングデータがあります ボードが写っている画像と ボードが写っていない画像です 最後がモデルのトレーニングです トレーニングについては 後ほど お話しします モデルが構築されると Visionで予測を行えます なぜカメラを 固定しなければならないのでしょう アルゴリズムに 安定したシーンが必要だからです 他の利点もあります プレー場所の分析が一度で済みます 場所に変化はないからです 他にも よい点は― 撮影する意思が ユーザーにはっきりあることです スタートボタンは不要です スクリーンでの操作もありません 画像登録によって シーンを安定させます VNTranslationalImageRegistrationRequestを 使います 言いにくい言葉ですね あるフレームから次のフレームへの 動きを分析します カメラがパンしていた時― 各フレームの間に 10ピクセルの動きがありました カメラが止まると― その動きはゼロになりました しきい値以下になり シーンは安定しています カメラは もう動きません 次は輪郭の認識です VNDetectContourRequestを使います オブジェクト検出の バウンディングボックスを 関心領域として使います 分析のために輪郭を簡略にします この２つの技術によって シーン全体でなく ボードの輪郭だけが見られます 輪郭の認識について詳しくは “Explore Computer Vision APIs”で 次はプレーヤーです VNDetectHumanBodyPoseRequestを使います 体の各関節のポイントが示されます ひじ 肩 手首 脚です これらのポイントから 関節の間の角度を分析するので 腕が曲がってることなどが 分かります BodyPoseRequestの 詳しい使い方については “Understand Body and Hand Pose Using Vision”で この部分は覚えておいてください 動作分類でも使います そろそろコードを見たいでしょう ここからはブレントが説明します ブレントです どうも CoreMLチームのブレントです フランクが話していたコードを 見てみましょう 説明に使うアプリケーションは ダウンロードすることも可能です よかったら一時停止して ダウンロードしてみてください リソースセクションにリンクがあります では始めましょう

まずゲームの各ステートでの アプリケーションの進行について ステートはGameManagerで管理し ViewControllerと通信します アプリケーションを進めると ステートがいくつか現れます ステートの変更は ViewControllerに通知されます GameManagerは１つだけで 常にこれを使います メインのストーリーボードを見ましょう 最初に使う時には スタートと設定の指示画面が出ます

次にソースピッカーでライブカメラか 動画のアップロードから選び入力します SourcePickerViewControllerを 使いましょう

次はRootViewControllerです

これは２つの役割を担います 詳しく見ましょう

１つはCameraViewControllerの ホストとなること ロード後 CameraViewControllerの インスタンスを作成し カメラ または動画からの フレームのバッファを管理します CameraViewControllerは OutputDelegateを備え バッファを代わりのViewControllerに 与えます CameraViewControllerの設定が終わると startObservingStateChangesを呼び出し GameManagerからステート変更の通知を 受けるようにします これが２つ目の役割です 複数のViewControllerを ゲームのステートに基づき開閉します RootViewControllerはGameStateChange プロトコルに合う拡張子を有します GameManagerからの ステート変更の通知に応じて― RootViewControllerが 他に表示するViewControllerを決めます SetupViewControllerやGameViewController SummaryViewControllerなど SetupViewControllerや GameViewControllerの拡張子は CameraViewControllerOutputDelegateや GameStateChangeObserverに対応します RootViewControllerで表示された いずれかのViewControllerは GameStateChangeObserverとして 追加されます そして CameraViewControllerOutputDelegateと なります ここまでがステートの進め方と ViewControllerへのバッファの与え方です フランクが話していた主要な機能について 詳しく触れましょう SetupViewControllerに入ります 最初に表示されるViewControllerです SetupViewControllerが現れると VNCoreMLRequestを作成します 使うのはCreate MLで作ったボードを検知する オブジェクト検出モデル 新しいオブジェクト検出遷移学習アルゴリズムを テンプレートにしました そして SetupViewController CameraViewControllerOutputDelegateの CameraViewControllerから バッファの受け取りを開始します detectBoardの各バッファで VisionRequestの実行を開始 結果として検知された対象物から 信頼性の低いものを除去します この場合 対象物はゲームボードですね 信頼性の十分な結果が出れば 対象物の周りをバウンディングボックスで囲み ボードの検知からボード配置の検出へ移ります ユーザーに指示しバウンディングボックスを 画面上のboardLocationGuideと整列させます boardLocationGuide内に入れば シーンの安定性の決定へと移ります ボードをboardLocationGuideへ移す指示は ライブカメラモード時のみ出します 動画再生時には この指示を出しません 動画再生時にはボードの位置が正しいと 仮定するからです ゲームボードの検出とカメラモード使用時の ボード配置の指示について説明しました 次にシーンの安定性の判断法を 見ていきましょう

SetupViewControllerのCameraView ControllerOutputDelegateの拡張子は VNSequenceRequestHandlerを用います 連続するフレームでVisionRequestを実行し 安定性を判断するからです このアプリケーションでは15フレーム分 反復し安定性を確認します バッファを受けたSetupViewControllerは VNTranslationalImageRegistration Requestを実行し 各バッファと直前のバッファが 整列しているかを判断します 結果を受けたViewControllerは 変形により得た点を― sceneStabilityHistoryPointsアレイに 付加します そして再びSetupStateを更新 SetupStateがプレーヤーのステートを 検知すると 計算型プロパティのsceneStabilityで シーンの安定性を算出します sceneStabilityHistoryPoints内の 点の動きの平均を出すのです 平均移動距離が10ピクセル未満であれば シーンは安定していると判断します シーンの安定性が判明すれば 次はゲームボートの輪郭の検出です この検出方法を説明します CameraViewControllerOutputDelegate 拡張子に戻りましょう ViewControllerのバッファ受信時 setupStageはdetectingBoardContours ここでdetectBoardContoursを呼び出します この関数は新しい VNDetectContoursRequestを使います ボード検出時に見つけた boardBoundingBoxを用いて― この要求に対する regionOfInterestを設定します 該当領域のみで要求を実行するためです それから検出した輪郭を分析し ボードの端と穴を見つけます 輪郭の検出後 DetectedBoardStateへ移行します SetupViewControllerも GameStateChangeObserverなので GameStateChangesで 次のコードが実行されます このケースでのステートは DetectedBoardStateです ユーザーにはボードの検出が知らされ― ステートはDetectingPlayerStateに 変わります この時点でボードが正しい位置にあると 確認したので シーンが安定していると判断し ボードの輪郭を検出しました 以上がSetupViewControllerの仕事です 次のViewControllerに移ります ステートがDetectingPlayerStateなので RootViewControllerが見えます 次に表示されるViewControllerは GameViewControllerです これはGameStateChangeObserverとして 加えられます そして CameraViewControllerOutputDelegateに なります もはやGameViewControllerではなく CameraViewControllerからバッファを受け コードを実行します GameViewControllerは detectPlayerRequestを実行 VNDetectHumanBodyPoseRequestの インスタンスです ViewControllerが受けた結果は humanBoundingBox関数へ ここで信頼性の低い観測結果を除去し フレームを入力した人の バウンディングボックスを返却します そしてゲームのステートは 次の段階へ進みます humanBoundingBox関数は また登場するので覚えましょう 次にプレー中のビーンバッグの軌道検出について フランクが説明します フランク では プレー中の軌道検出について 見てみましょう VNDetectTrajectoriesRequestが シーン中で動く対象物を検出し 無関係の動きからの 不要なノイズを除去します これを実際に活用するには 理解を深める必要があります 見ていきましょう 投げる瞬間の映像ですね この映像の表面を少しめくって 裏側の解析の様子を見たいと思います 今 投げました しかしアルゴリズムが見るのは 動きでなく“フレームの差分”です これはフレームごとに変化するので 対象物が見えやすいですね ノイズも除去しました シーケンス全体の中から ビーンバッグを飛ばしている場面を見ます 使うのは新しい VNDetectTrajectoryRequestですが 今年 Visionに新しく加わったのが StatefulRequestです Visionの他のrequestでは不要ですが このrequestは置いておきます 経時的にステートを構築するからです 最初のフレームを与えても 何も起こりません 引き続きフレームを与えます ４つ入りました 次は５番目のフレームです ここで十分なエビデンスが得られたため 軌道を検出します １つのフレームで 動きを検出することはできません 経時的なエビデンスが必要です これがStatefulRequestです 投げる様子はVNTrajectoryObservationへ 報告します しかし投げ始めは もっと前です 観測時のタイムレンジを使うと 投げ始めた時が分かります フレームを与え続けると 時間が経つにつれ 軌道が修正されます 軌道の観測結果を 詳しく見てみましょう これは投げる動作全体のフレーム差分を 合成したものです 対象物の中心軌跡を通る点が得られます これらが検出された点です さらに投影点も与えられます 対象物が移動した放物線を 完璧に示す５つの点です また この放物線を表す EquationCoefficientsも得ます y＝axの２乗＋bx＋cの等式です この等式を用いると 美しく滑らかな放物線を描くことができます 下に もう１つ放物線がありますね これはビーンバッグ飛行時の影によるものです 複数の軌道を同時に取得し UUIDを用いて区別することができます 下側の放物線は足元近くにあり ビーンバッグの軌道とは思えないので 下側は無視して上側の線のみ考慮します ではVNDetectTrajectoriesRequestの 使用法は？ 作成時にframeAnalysisSpacingを与えます 画像を再度 確認しましょう スペースをゼロにセットすれば すべてのフレームが解析されます このスペースに他の数値を入れると― 解析するフレームの数は少なくなります 計算コストを削減できるので 旧式のデバイスには特に重要な点です 次に求めるtrajectoryLengthも 特定できるので 無関係の小さな動きを フィルタリングにより除去できます さらにVisionのcompletionHandlerで 結果に対処します またプロパティも２つあります シーン中の対象物を見ると サイズが異なりますね 左側には投げている腕が見えます そして飛ぶビーンバッグ 右端にあるのはノイズのようです 対象物を円で囲むことで それらの要素を示しました minimumObjectSizeの設定で 小さな要素のノイズを除去できます ビーンバッグの大きさは 知っていますからね 逆に大きすぎる対象物も除去したいので maximumObjectSizeを用います そうすれば他の軌道に邪魔されず ビーンバッグのみに集中できます 軌道検出で注意する点を まとめましょう まず安定したシーンが必須です 必要に応じて撮影時に三脚を使うなどして カメラを固定しましょう 軌道は放物線を描く必要があります 直線も一種の放物線ですが― これは無関係の動きを 除去するために使えます タイムスタンプを使うので タイムスタンプ付きSampleBuffersも必要です ボールが跳ねたりフレームから出たら その都度 新しい軌道が作成されます この場合 直前の軌道の最終点を見ることで 簡単に軌道を合成できます 新たな軌道の最初の点と合えばよいのです こうして関心領域のみ使用します 動きが生じる場所を予測できれば 多くの背景ノイズを除去することが可能です 最後に重要なのがビジネスロジックです この例では投げるプレーヤーからのみ 軌道が作られると分かっていました プレーヤーへ投げ返すという動きは ありませんでした

続いてブレントがコードの説明をします ブレント ありがとう 軌道の検出手順を見ましょう CameraViewControllerからの各バッファで VNDetectTrajectoryRequestsを実行 GameViewControllerで処理します バッファごとに実行する detectTrajectoryRequestは― VNDetectTrajectoriesRequestの インスタンスです detectTrajectoryRequestは 自身のキューで実行されます CameraOutputQueueとは別です detectTrajectoryRequestから 得た結果を― processTrajectoryObservationsで 処理します この関数により 各軌道の持続時間や 検出点などの情報を得ることができます 軌道関心領域の更新も行い 飛行中か否かを確認します 検出された軌道点が20フレームより長く 関心領域の外にあれば終了と判断します 点のプロパティはdidSetObserverで updatePathLayerを呼び出します

この関数でTrajectoryViewの軌道を更新し 点が関心領域内か否かを確認します また軌道のリリース速度も 計算する関数ですが― これは後で詳しく説明します 次に投げ方の検出について フランクがお話しします ありがとう ブレント 次に見ていくのは 投げ方を識別する方法です カスタムの動作分類モデルを 作成しました Create MLで独自の トレーニングデータを使ってです 集めた動画には 投げ方を分類する対象だけでなく― 歩いたりバッグを拾ったりという部分もあるので それらを除外します モデルのトレーニング方法の詳細は 後でブレントが話します 動作分類はVisionで Bodyposeを使って行います 軌道の検出同様 時間の経過と共に エビデンスが蓄積されます どう機能するか見てみましょう これが投げる動作のシーケンスで まずプレーヤーの体の動きがあります その後 軌道検出から 投げる瞬間を検出します VNDetectHumanBodyPoseRequestから 体勢を蓄積しました そして投げる動きが検出されたポイント近くの 45フレーム取ります ウインドウは 完全な投げる動作を含みます 45コマの体勢を １つのMLMultiArrayに統合し― CoreMLモデルにフィードします それからラベルを取得します 投げ方と信頼値です コードで どのように見えるか ブレントが説明します ありがとう フランク プレーヤーが投げ終わったのを どう判断するか見ましょう GameViewControllerのCameraViewController OutputDelegate拡張子を見ていきます

受信したバッファごとにGameViewControllerが 軌道を追跡するだけではありません VNDetectHumanBodyPoseRequestで プレーヤーのキーポイントも検出し― これらのポイントを 観測値として保存しています humanBoundingBox関数について また触れると言いましたが― 体勢の観測結果は ここに保存されます 体勢の観測はCreate MLの 動作分類モデルのインプットで プレーヤーの投げ方を予測するように トレーニングされています 投げ終わると updatePlayerStats関数が呼び出されます この関数内でgetLastThrowTypeが playerStatsオブジェクトで呼び出されます playerStatsオブジェクトは playerStats構造体のインスタンスで― ゲーム中に プレーヤーに関する統計を記録します

getLastThrowType関数は 保存されていた体勢の観測を使用し― 動作分類モデルの入力を準備しています

prepareInputWithObservations関数は ヘルパー関数で― 体勢の観測を動作分類モデルで 必要とされる入力形式に変換します このヘルパー関数は完全な投げる動作を 捉えるために必要なフレーム数も設定し― それらのフレームが 分類のためにモデルに渡されます 入力の準備ができたら アプリケーションは動作分類予測を行い 最も確率の高い投げ方が返されます 各軌道を計算するメトリクスについては フランクが説明します ありがとう ブレント 次に行うのはプレー場所の測定です ボードは規定サイズなので 大きさが分かっています ボードの輪郭を測定したら― 横60センチに縦１メートルのサイズに対する 画像のピクセル数が分かります それが画像から現実世界へ 対応する基準となるわけです 投げる時の軌道は ボードと同じ平面で発生しているので これで速度を計算できます 軌道と所要時間と 現実世界でのサイズが分かるからです あと測定したいのはリリース角度です そこで私が実際にバッグを 投げ始めた時の体勢を探します 私のひじから手首 つまり前腕の角度を 地平線を基準にして測ります 再びブレントに交代し コードで見てもらいます ブレント ありがとう フランク プレーヤーの最後の投げ方の取得に加え updatePlayerStats関数は― 軌道のリリース速度と スローのリリース角度も取得します 前述のとおり 軌道のリリース速度は updatePathLayer関数で計算されます アプリケーションが最初に軌道の観測を行うと 軌道の長さをピクセル単位で計算し― ゲームボードの長さを参考にし 実際の距離に変換できます アプリケーションは その長さを 軌道観測の継続時間で割り― 軌道のリリース速度を取得します スローのリリース角度は getReleaseAngle関数で計算されます この関数は 手首とひじのポイントを使用します バッファにある体勢の観測で ビーンバッグが放たれた所で角度を出しています このアプリケーションの 多くのコンポーネントを見て― Create MLで作成した ２つの機械学習モデルについて話しました １つ目はボードの検出に使った オブジェクト検出モデルで― ２つ目はプレーヤーの投げ方の検出に 使った動作分類モデルです いずれの場合もモデルを作成している間 いくつか重要な点を書き留めました オブジェクト検出モデルから始めます それが動作すると予想される条件のデータで トレーニングしたかったのです データはiPhoneでキャプチャされ そこでアプリケーションが実行されます モデルはiPhoneカメラから フレームを予測します ボードの画像をデータに含めたのは― アプリケーションで扱いたいタイプの ボードだと知っていたからです 外でゲームをするつもりなので 外のボードの画像も含めました しかし最初は いくつか モデルが混乱したことがありました

元のデータはすべて 画像に人や ビーンバッグを入れずに収集されました 最初のモデルはフレームに 人とビーンバッグが 入るとボードの検出に手こずることがあり 人とビーンバッグを含む画像を追加すると モデルが改善されました またデータ収集の最初のラウンドの後― 様々な距離と角度からの画像を追加したのも モデルの改善に役立ちました 携帯がボードに垂直でなかったからです 次に動作分類モデルを見てみましょう これも動作すると予想される条件から データでトレーニングしたかったのです 動作分類データもiPhoneでキャプチャしました 様々な距離と角度で キャプチャしたデータを含めました モデルのデータを取得した時とプレー時で iPhoneが別の位置にあることを考慮してです

モデルの最初の回について指摘したい点は それが３つのクラスで作成されていたことです 下手投げ 上手投げ 脚の下からです しかし それではビーンバッグを拾うなどの すべての動作が― これら３つの動作の１つと認識されました これらの追加の状況を考慮し― 別のクラスを追加しました “ネガティブクラス”または“他のクラス”です ３種のショットに当てはまらない 様々な動作を含めました これでモデルの能率が 大幅に向上しました もう１つの指摘点は 予測ウインドウを正しく設定することです 目標動作全体を含ませるのが 正しい予測ウインドウの設定です ビーンバッグを投げるなど 動作の種類により― キャプチャするフレームが 多かったり少なかったりします モデルがうまく機能するには 予測ウインドウが 動作全体を捉える必要があります またアプリケーションで モデルを使うなら 予測を実行するタイミングと頻度を 決めねばなりません このアプリケーションでは 予測を継続的に実行したくありませんでした 代わりに動画の一部分を選出して モデルに送信し― 投げている間の動作を分類したかった 手順ですが スローが完了したら 既定のイベントはスロー終了です その時 投げ始めからの全フレームを モデルに送信し― 実行された動作を分類させます 次はフランクがライブ処理の 最善の措置について話します ありがとう ブレント このアプリケーションについて 留意したいことがあります リアルタイム･フィードバックが肝心なので ライブ処理の最善の措置に従うべきです ライブストリームをする際 いくつかの課題があります 我々のカメラには 限られた数のバッファしかなく― バッファを分析の作業に回せば カメラでは使用できません カメラは すぐに バッファが枯渇してしまいます 従ってバッファを 速やかにカメラに戻し― カメラが作業できるように することが重要です アルゴリズムが どれだけ 時間をとるかも気になります フレーム･デュレーションより 短ければ問題ないはず しかし常にそうとは限りません システムの負荷は変化します バックグラウンドで通知を受け取ったり 他のネットワーク･トラフィックが発生したら アルゴリズムの所要時間は延びます フレームレートに追いつくのが 難しい場合― didDropのCaptureOutputメソッドが 役立ちます カメラがバッファを提供できなかった理由の 通知を受け取ることができます ライブストリームを処理する時 作業の分割もすべきです フレームごとに分析するものが 複数あることは分かるので― 異なるキューを使用します キューごとに作業を分担し フレームにフィードします それらと並行して カメラは別の仕事ができます 分析結果がレンダーされるまで 待つことはありません 通常はメインキューで 行う必要があり― バッファを解放してから メインキューに非同期でレンダーします 今は すべてのバッファがカメラに戻り カメラのフィードは停止しません ライブプレイバックにおける課題も似ています ライブプレイバックを扱う際は― 分析を行っている間も 動画が途切れることなく再生されるべきです ここでも すべてのフレームを 正しく処理できることが肝心です 事後分析を行うなら フレームごとに処理しますが― ライブプレイバックでは フレームごとに処理したくありません そこでAVPlayerItemVideoOutputを CADisplayLinkと使用します 利用可能な新しいピクセルバッファがあれば 通知してくれます その時間を少し使って 画面に到着する動画フレームと同期します 次に出力ピクセルバッファをコピーし それに基づいて分析を行います さあ　まとめましょう アクションやスポーツの分析は 面白いことが分かったでしょう ビーンバッグのゲームだけでなく テニスにも使えます ボールは小さくて見づらいですが 我々のアルゴリズムでは検出できます サッカーでは どうでしょう？ ボールが どう飛んだか 軌跡を見ることができます 次世代のクリケット選手を 指導したい人もいるかも クリケット･ボールの軌道も よく見えます この技術で他に何を構築できるか 考えてみてください ユーザーにどんな洞察を もたらせるのか 我々のテクノロジーを 皆さんのイノベーションで― 発展させてくれることに 期待しています ご視聴 ありがとうございました 残りのWWDCもお楽しみください