2つのビデオを自動的に比較し共通のコンテンツを探し出す

2つのビデオを比較し、共通している点、異なっている点を特定することはさまざまに役立ちます。2つのビデオソースの間で共通のコンテンツを探し出すことは、次のような多くの興味深いアプリケーションへと可能性を広げます。

• 自身のコンテンツの、サードパーティビデオによる不正使用を調査する
• 1組（2つ）のビデオストリームについて、コマーシャルが異なる場合でも確実に同じ番組が流れていることを確認
• 2つのビデオを比較して、どれくらい共通のコンテンツが存在するかを調べる

通常、放送局ではこのような比較は手動で行われていますが、その場合1人の担当者が同時に2つのビデオをモニターする必要があります。この手作業のアプローチは面倒で時間がかかり、ミスが発生しやすいものです。

このブログでは、このタイプのビデオ比較を行うための自動プロセスについて解説します。このアプローチは、保存されたビデオ、またはビデオストリームの比較に使用でき、さまざまなユースケースに導入できる柔軟性があります。

ソリューションで考慮すべき様々な課題

ビデオを比較する際によく検討される選択肢は、両方のソースから得られるスクリーンキャプチャまたはフレーム画像を評価することです。概念的には単純ですが、いくつかの細かい点によりこのアプローチの実装は複雑になります。

まず、多くの場合、2つのビデオソースのフレームは、画面上の放送局のロゴが異なるため、完全には一致しません。たとえば、あるテレビ番組が番組販売され放送されている場合、一方のビデオにはある放送局のロゴが表示され、もう一方のビデオには別の放送局のロゴが表示されます。これらの画面上のロゴ（またはバグ）は、放送局を識別するために使用され、通常、プログラム放映中は常に表示されます。つまり、フレーム画像は2つのビデオソース間で常に異なるのです。

次に、コンテンツレーティングのアイコン（「TV14」など）や、放送局ごとに異なるクローズドキャプションの標識など、画面上には他にも違いがある場合があります。この状況は、異なる国で放映されたビデオを比較する際に最もよく見られます。たとえば、米国で制作され、カナダのテレビ局で放映された番組などの場合です。

さらに、画面上のオーバーレイ広告やバナー広告が画像の上部または下部に数秒間表示される場合があります。番組放送中の広告同様、これらの広告には地域性があり、放送局によって異なる場合があります。

さらに、各ソースでキャプチャされたフレームは、おそらく、わずかに異なる時点から取られたものであり、視覚上のわずかな違いが生じます。座って話している人のシーンであっても、時間の経過とともに表情が変化し、手の位置や姿勢も変化します。画面が急速に変化する状況（一部のオープニングクレジットシーケンスやスポーツイベントなど）では、まったく異なるフレーム画像一式になってしまうことがあります。このため、あるビデオのフレームと別のビデオのフレームを単純に比較してもうまくいきません。完全に一致することはあり得ないのです。

最後に、2つのビデオの本編が同じであっても、2つのビデオソース間で広告の配置が異なる場合があります。たとえば、ある特定の広告タイミングで、1つの放送では広告が2分間あり、もう1つの放送では1分30秒間しかない場合があります。その状況を次の図に表します。

同じ放送コンテンツ内の、異なる配置の広告時間を示した図

このようにコマーシャルの配置にバラツキがあると、一致するコンテンツがどこにあるか推測することはできません。

ファジーマッチングと中央3分の1（middle third）の使用

幸いなことに、これらの懸念点すべてに解決策があります。

まず、画面上のロゴとアイコンが異なるビデオについては、各フレーム画像の一部分だけを扱うことができます。各フレーム画像の上部3分の1と下部3分の1を取り除くことで、バナーやオーバーレイ広告だけでなく、すべてのロゴやアイコンが取り除かれます。その操作を次の例で示します。

左側がフルスクリーン画像、右側が同じ画像の中央3分の1

Pythonと、Pillowというポピュラーなオープンソース画像操作ライブラリを使用すると、この操作は次のように実行できます。

from PIL import Image
with Image.open(f) as im_pil:
    crop_x1 = 0
    crop_x2 = im_pil.width
    crop_y1 = int(im_pil.height * 0.333)
    crop_y2 = int(im_pil.height * 0.666)
    middle_third = im_pil.crop((crop_x1, crop_y1, crop_x2, crop_y2))

次に、画面上のロゴを排除したとしても、画像はビデオソース間でわずかに異なる可能性が高いので、正確に一致するものを探すのではなく、画像が互いにどの程度似ているかを判断する方法が必要となります。 Perceptual Hashは、これを達成する良い方法です。

Perceptual Hashは、ある画像に対して、それに対応した値を返すアルゴリズムです。Perceptual Hashにはさまざまな種類がありますが、大まかには、イメージのサイズが変更されていようと、ある特定のイメージには同じハッシュ値を返す、ということです。

異なる画像からのハッシュ値は、互いに比較し、画像同士の類似性を評価するために使用することができます。以下は2つの例です。左側には、2つの連続したフレームが表示されています。非常によく似ていますが、いくつかの微妙な違いがあります。右側には、非常に異なる2つの画像が表示されています。ここで、フレームペア間のパーセンテージの違いに注目してください。

左側は、非常に類似した2つのフレームで、その差異は9%。右側は、異なる2つのフレームで、その差異は53%。

Perceptual Hash値を使用して、2つのフレーム画像の差異が所定のしきい値以下となった場合に、一致すると見なすことができます。我々の検証に基づき、画像の変化が25%以下であれば、一致と見なせることがわかりました。

Perceptual Hash化は、ImageHashいうPythonオープンソースライブラリでサポートされています。そのライブラリを利用してイメージからハッシュを取得する方法は、次のとおりです。

hashval = imagehash.phash(middle_third)

フレーム画像の中央3分の1にPerceptual Hashを適用し、所定のしきい値より小さい差を探し出すことによって、2つのビデオソース間で一致するフレームを見つけることができます。ただし、一致するコンテンツの存在を断定するにはまだ十分ではありません。

テレビ番組のクレジットや広告の間には黒フレームが頻繁に現れます。黒フレーム画像は、両方のビデオソースにありますが、一つのフレームが一致するだけでは、コンテンツの一致を示す正確な指標にはなりません。正確な結果を得るには、フレーム画像のグループ同士を一度に比較する必要があります。そのためには、ファジーマッチングと呼ばれる手法を使います。

ファジーマッチングは、完全一致を探すのではなく、定められた一致のしきい値を対象に探す手法です。我々の検証によると、2つのグループのフレーム画像を比較し、グループ間でフレームの75%が一致することが判明した場合、一致と見なせることがわかりました。これは、フレーム画像によってキャプチャされた瞬間がグループ間で異なるために、一部のフレームが両方のグループで同じようには現れない、という場合に役立つテクニックです。

フレームのグループ同士を比較するために、評価対象とするフレームを特定する2つのスライディングウィンドウを使います。この概念を下の図で表します。それぞれのスライディングウィンドウは一度に4つのフレームを評価の対象としています。太い矢印は高い一致と見なされるフレームを示します。

2つのグループのフレーム画像。矢印は、上下のグループ間で一致するフレームを示す

これらのスライディングウィンドウは、両方のビデオ全体を評価対象とすることができます。また、常に互いに特定の秒数以内に収まるように制限することもできます。たとえば、5分の枠内で一致するコンテンツを確認する場合は、スライディングウィンドウを互いに5分以上離さないように制限します。

下記は、前述したファジーマッチングの手法により2グループのPerceptual Hashを比較する方法を示すPythonコードの例です。hashes1とhashes2は、各スライディングウィンドウのハッシュ値のリストです。

    num_matches = 0
    for hash1 in hashes1:
        for hash2 in hashes2:
            # subtracting hashes returns the # bits difference
            hash_diff = hash1 - hash2
            if hash_diff <= config.MAX_DIFFERENT_BITS:
                num_matches += 1
                hashes2.remove(hash2)  # only count each matching item once
                break  # skip the rest since we've found a match

    # how many of hashes_1 were found in hashes_2, and vice versa?
    num_compared = len(hashes1)
    percentage_match = num_matches / num_compared
    matched = (percentage_match >= config.MIN_MATCH_PERCENTAGE)
    return not matched

このコードでは、いくつか定数の設定が前提となっています。たとえば、フレームマッチングの許容差を25%にしたい場合、MAX_DIFFERENT_BITS値は16にします（比較されるビット数の合計が64であるため）。同様にMIN_MATCH_PERCENTAGEは0.7のようになります。これは、スライディングウィンドウ内で70％以上のフレームが一致した場合にコンテンツが一致したと判定します。

さらに、スライディングウィンドウの動きは、目的に応じて変えられます。一致するコンテンツがあるかどうかだけ知りたい場合は、最初に一致するコンテンツが見つかった時点で検索を終了できます。2つのビデオに共通するすべてのコンテンツのリストを取得したい場合は、このプロセスを使用して、コンテンツ全体にわたってスライディングウィンドウを移動させ、ビデオのコンテンツ全体を検索できます。

まとめると、各フレーム画像の中央3分の1を分離し、Perceptual Hashを使用してフレーム画像を比較し、スライディングウィンドウを使ったファジーマッチングを使用することで、2つのビデオソースに一致するコンテンツがあるかどうか、確信を持って判定し、その一致するコンテンツが発生する場所も特定できます。

AWSでのデプロイ

ここまでで、2つのビデオソース間で一致するコンテンツがあるかチェックする方法がわかりました。次のステップは、AWSでそのソリューションを実装するアーキテクチャを作成することです。実装の例を下図に示します。

フレーム画像がMediaLiveによって生成され、S3バケットに格納、Lambda関数によって処理されるアーキテクチャの図。出力はDynamoDBまたはSNSに送られる

ビデオコンテンツからフレーム画像を取得するには、AWS Elemental MediaLiveを使用します。MediaLiveは、ブロードキャストグレードのライブビデオ処理を提供するAWSサービスです。入力には、保存されたビデオファイル、ビデオストリームのどちらでも使用することができ、フレームキャプチャを含むさまざまなタイプの出力ができます。

出力されたフレーム画像は、Amazon Simple Storage Service（Amazon　S3）バケットに格納されます。S3は、業界トップクラスのデータ可用性、セキュリティ、パフォーマンスを備えた、実質的に無制限の容量を提供するオプジェクトストレージサービスです。さらに、S3ライフサイクルポリシーを作成して、一定期間後にフレーム画像を自動的にアーカイブまたは削除できるため、長期的なコストを大幅に削減できます。

両方のビデオソースのフレーム画像がS3バケットに格納された後、AWS Lambdaを使用してダウンロードし、Perceptual Hash値を計算して比較を行います。Lambdaは、拡張性（スケーリング）と可用性（レジリエンシー）を備えており、このようなタスクによく適したサーバーレスコンピューティングサービスです。Lambdaを使用すれば、コードを実行するためにサーバーをプロビジョニングや管理する必要はありません。実行時間は15分に制限されていますが、ビデオストリームの比較のような短時間のタスクには理想的な選択肢です。

Lambdaのさらなる利点は、さまざまな方法で呼び出せることです。上記のアーキテクチャ図では、次の3つの選択肢が示されています。Amazon API Gatewayへのコールによる呼び出し、Amazon EventBridgeを使用したスケジュールに基づく呼び出し、コマンドラインまたはAPI経由の直接呼び出しです。EventBridge経由のスケジュールされたイベントとしての呼び出しは、比較を定期的に実行する必要がある場合にとても適しています。一方、APIゲートウェイ経由でAPIコールを介してプロセスを呼び出す方法は、必要な場合にのみ比較を実行するのに適しています。

最後に、Lambdaの結果は、さまざまな方法で保存または処理できます。上記のアーキテクチャ図には、Amazon DynamoDBに結果が書き込まれる場合が示してあります。Amazon DynamoDBは、規模に関係なく数ミリ秒台のパフォーマンスを実現する、キーバリューおよびドキュメントデータベースで、セキュリティと耐久性が組み込まれています。また、お客様のビデオ処理パイプラインのニーズに応じて、結果をリレーショナルデータベースに保存したり、ログに書き込んだりすることもできます。

より早急なアクションが求められる場合には、Lambdaは、Amazon Simple Notification Service (SNS) を介してコンテンツの一致を通知できます。SNSはアプリケーション間とアプリケーションから個人への通知の両方に使用できる、フルマネージド型メッセージングサービスです。この場合、SNSは、同期に不一致が検出されたことをモニタリングの担当者にテキストメッセージまたはEメール送信することで、担当者が即座に状況に対処できます。

まとめ

ビデオの比較は複雑な問題ですが、フレーム画像の中央3分の1を抽出し、Perceptual Hashを用いて比較し、スライディングウィンドウを使用して単一の画像ではなくフレームのグループ同士を確実に評価対象にするという、手法の組み合わせを用いて解決することができます。この方法により、異なる放送局のロゴ、画面上の広告、クローズドキャプションやその他の情報アイコンなど、フレーム間の細かい違いに対処できます。

AWSでソリューションをデプロイすることで、お客様は、拡張性、パフォーマンス、セキュリティ、耐久性のメリットを享受することができます。MediaLiveを使用すると簡単に必要なフレーム画像を生成することができます。そして、実質的に無制限の容量のS3は、これらのイメージの保存に最適です。Lambdaは比較用のコードをパッケージ化するのに効果的な方法であり、スケジュール、APIコール、または直接コールで呼び出すことができます。比較結果の詳細情報はDynamoDBに書き込み、LambdaではSNSを用いて一致した動画や一致しなかった動画を通知することができます。

このようなビデオを比較するためのアイデアを、お客様のビジネスに適用することにご興味がある場合は、AWS チームにお問い合わせください。

参考リンク

AWS Media Services
AWS Media & Entertainment Blog　(日本語)
AWS Media & Entertainment Blog　(英語)

AWSのメディアチームの問い合わせ先: awsmedia@amazon.co.jp
※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。

翻訳は BD山口とSA金目が担当しました。原文はこちらをご覧ください。