マーケティング動画で買い手の無関心を解消する5つの方法

無関心とは、興味、熱意、関心の欠如である。無関心と同義である。B2Bセールスにとって、無関心は取引のキラーである。B2Bマーケティングにとって、無関心は非効率である。

無関心は、あらゆるB2B組織が直面する最大の脅威のひとつかもしれない。消費者は他に読むもの、見るものが豊富にあり、また、ほとんどすべての業界において、他に選ぶべき業者が山ほどある。

私の立場からすると、無関心は、エンゲージメントを生み出し、注目を集め、興味を駆り立て、忠誠心を築き、最終的には行動と変化を促すというマーケターとしての中核的責任を脅かすものであり、とても恐ろしい。買い手が私たちのコンテンツに身を乗り出し、関わり、消費しようとしない限り、そのようなことは不可能です。

要するに、バイヤーに構ってもらわなければならない。

マーケティング担当者は、買い手の無関心を解消するために動画をどのように活用しているのだろうか?

無関心への解毒剤は好奇心である。好奇心とは、人間に何かに注意を向けさせ、それに関与させ、最終的にはそのために行動を起こさせるものである。好奇心こそが変化に火をつけるのだ。

マーケティング担当者にとって、動画は購買者の好奇心を駆り立てるための標準的なツールとなっている。現在、企業の87%がマーケティングツールとして動画を使用しており、これまで以上に多くの企業(83%)が、動画は投資に対して良いリターンをもたらすと回答している。しかし、動画マーケティング担当者の90%は、この1年で競争とノイズのレベルが上がったと感じている。

動画を目立たせるには?B2B企業が無関心なバイヤーを突破するために動画マーケティングをどのように活用しているか?

数週間前、ボストンで開催されたPLAY 2019で、私は動画を使ってバイヤーの無気力を打破する方法をいくつか紹介した。以下に、これらのヒントのうち5つと関連する例、そしてそれらがなぜ効果的なのかについての私の見解を掲載する。

1.ニッチを知り、ニッチに貢献する

SiriusDecisionsによると、B2Bブランドの60%が、バイヤーを理解していないことを認めている。しかし、バイヤーは、自分にとって個人的な価値があると思ったり、自分のキャリアにプラスの影響があると思ったりすると、50%も購入する可能性が高くなる。

Eloquaがマーケティングオートメーション機能でオラクルに買収される前、同社はModern Markに関するビデオシリーズを放映しました。このビデオは、Eloquaというブランドがいかに視聴者を理解しているかを示すものであり、潜在的な購入者が、Eloquaのマーケティングテクノロジーから個人的に恩恵を受けているこの人物の目を通して、個人的な価値を知ることを可能にしました。

2.人間らしく話す

買い手があなたのビデオを聞かなくなる確実な方法のひとつは、私たちの会社の定型文がそうであるように話すことだ。

Lucidchartの製品デモは、単に人間のように話すことの力を見せてくれる。

Slackのカスタマーテスティモニアルは、同じようにシンプルで親しみやすく、最後まで見たくなるような魅力的なトーンを実現している。(顧客の声の動画を最後まで見たいと思ったのはいつ以来だろうか?)

3.ドライブ緊急度

確かに、私たちはFUD(恐怖、不確実性、疑念)に慣れ親しんでいる。セキュリティとリスク業界では、買い手の緊急性を高めるための標準的な手段だ。しかし、恐怖を煽るような表現は、その業界のすべてのベンダーが使っているため、古くなってしまう。また、大げさに感じられる傾向もある。

シスコのビデオは、ランサムウェア攻撃のストーリーをひっくり返し、ハッカー自身の視点から攻撃を探っている。その結末を見守るうちに胸がドキドキしてくるような脚本で、シスコがこの脅威の各角度をいかによく理解しているかを示している。

4.信頼を得る

エデルマンによると、バイヤーの42%が、どの会社を信用すべきかわからないという。これは、ランド・フィッシュキンが登場する前のSEOコンサルタントの世界では特に顕著だった。Mozの創設者であるランド・フィッシュキンは、SEOの知識を厳重に管理する代理店の中で、透明性のある教育的なリソースとして知られるようになった。

彼らにとって、企業秘密は秘伝のタレだった。ランドにとって、それは秘密の戦術や怪しげなビジネスが横行する業界で信頼を得る、ソート・リーダーシップ・プラットフォームの基盤となった。彼の誠実さは、彼をSEOの権威へと導き、彼のホワイトボード・フライデー・ビデオは、この透明性を毎週示すようになった。

著書『ロスト・アンド・ファウンダー』の中で、ランドはこう述べている:

「私たちは、ビジネスの仕組みについてあまりに多くを共有したため、クレイジーで愚かだと言われました。しかし、私たちは信頼されるようになり、特にSEOの分野や技術系スタートアップの広い世界では、不可解なほど秘密主義であることが多いため、それが功を奏したのです。"

5.顧客が求める場所にいる

無関心の主な要因のひとつは、単に見えないことだ。そもそも、あなたのビデオを見つけるのに多大な労力を要するのであれば、なぜ私はあなたのビデオを見なければならないのだろうか?

すべての動画コンテンツにゲートをかけていませんか?Eメールに頼りすぎていませんか?YouTubeに全力を注いでいませんか?サイトやブログ記事の目立たないページに隠していませんか?動画コンテンツを解放しましょう!

Content Marketing Instituteによると、B2Bマーケッターの70%がソーシャルメディア上でスポンサーコンテンツを利用している。彼らの調査では、これは有料コンテンツ配信方法の第1位だった。

B2B企業には、LinkedInで動画に投資することを強くお勧めする。このプラットフォームは現在5億人の会員を誇り、そのうち2億6000万人が毎月ログインしている。そのうちの40%が毎日このプラットフォームを利用している。注:これらは単なる求職者ではなく、61Mはシニアレベルのインフルエンサーである。

LinkedInによると、これらのユーザーは、静的なスポンサード・コンテンツよりも、動画広告の視聴に3倍近い時間を費やしている。「LinkedInのプロダクト・マネージメント・ディレクターであるピート・デイヴィスは、「動画は今、私たちのプラットフォームで最も急成長しているフォーマットであり、人々の話題になる可能性が最も高いものです。

このエンゲージメントを活用して、あなたの動画を後押しし、新しいライブ動画放送サービス、LinkedIn Liveを試してみることを検討してください。デスクトップでもモバイルでも美しいインターフェイスで、視聴者がいる場所に正確にいることができる素晴らしい方法です。

バイヤーの無関心を克服することは、B2Bマーケターが今後数ヶ月の間に直面する多くの課題の一つです。しかし、それは私たちの仕事をとてもエキサイティングなものにしている核心です。動画マーケティング戦略には、創造性と共感性が必要なのです。

ブライトコーブ製品のアップデート2019 年 6 月

今年は、NAB のためにラスベガスに行ったり、ここボストンで 9 回目の Brightcove PLAY を開催したりと、ブライトコーブ本社は大忙しでした。動画業界の主要イベントへの参加や開催だけでなく、製品チームは舞台裏で忙しく、製品のアップデートや改良を行ってきました。これらの新機能により、より豊かなインサイトの収集、カスタム購読オプションの提供などが可能になります。

フェイスブックに生中継

Brightcove Live to Social により、Brightcove Live ジョブを Facebook にストリーミングできるようになりました。この機能は、複数のソース(カメラ、エンコーダなど)と複数の配信先を 1 か所から接続するハブとして Brightcove を強化します。Brightcove ダッシュボードから Facebook にライブ配信を開始する方法をご覧ください。

OTT FLOWマルチティア・サブスクリプション

つまり、コンテンツ制作者は、潜在的な購入者に異なる価格帯のユニークなコンテンツパッケージを紹介したり、AVOD/SVOD戦略をブレンドしてユーザーをアップセルしたりすることができる。

UI FOR SSAI

ダイナミック配信とSSAIを有効にしたユーザーは、管理モジュールで広告設定を作成および管理できるようになりました。SSAIとライブを有効にしたダイナミック配信のユーザーは、ライブSSAIでも適切なコントロールを利用できます。このアップデートにより、すべての広告設定を単一のビューで確認できるようになり、ワークフローが改善されました。Brightcove Live にサーバーサイド広告を実装する方法をご覧ください。

ADメタデータ

Live Program and Ad Metadata APIを使用することで、お客様は放送プレイアウト・システムに統合したり、広告ターゲティングのために特定のデータを渡すことができます。より詳細な情報を提供することで、広告主にとって広告在庫がより魅力的になり、需要とCPMが増加します。

IMA SDKがオープン測定を含むようになった

このSDKはIABによって開発された業界標準であり、モバイルおよびデスクトップ環境に配信される広告のサードパーティによるビューアビリティおよび検証測定を可能にするように設計されています。オープン測定SDKは、動画コントロールをユーザーの体験に不可欠な友好的な障害物と見なし、広告のビューアビリティ測定から除外するための規定を設けています。

ブランドがソーシャルメディアでライブストリーミングを行うべき3つの理由

ここ数年、ソーシャル・チャンネルにおける動画の進化は急上昇している。当初はYouTubeにしか動画を投稿できず、ライブストリーミング機能は全くありませんでした。今では、あらゆるソーシャルネットワークに動画を投稿できるだけでなく、ほとんどすべてのソーシャルネットワークでライブストリーミングが可能です。 実際、CMSCMediaの『Social Media Trends to Watch and Capitalize on in 2019』レポートによると、2019年は今のところインターネットトラフィック全体の85%を動画が占めており、ライブストリーミング市場は2021年までに倍増すると予想されている。あなたのブランドのソーシャル・プロフィールへのライブ・ストリーミングは信じられないほど強力であり、今始めるべき3つの理由がここにある。

1.ソーシャルメディア上のライブストリーミングが視聴者のリーチを拡大

それぞれのソーシャル・チャンネルにはユニークなオーディエンスがいる。Twitterは、ニュース速報であれ、スポーツの素晴らしい瞬間であれ、リアルタイムのコンテンツを見るのに最適な場所です。ツイッターへのライブストリーミングは、最もタイムリーな情報を得たい視聴者を捉えます。Facebookは、視聴者がブランドや友人、家族とつながる場所です。Facebookにストリーミングする場合、あなたやあなたのブランドと直接関わりたいと思っている視聴者を捉えることができます。そして最後に、YouTubeは多くの視聴者が長編コンテンツを求める場所です。YouTubeは、ハウツーからチャプター形式のストーリーまで、新しいスキルや製品の改良を学ぶためのプラットフォームです。

2.ライブストリーミングはブランド認知度を高める

様々なソーシャル・プラットフォームで視聴者のリーチを広げることの自然な利点は、あなたのブランドが新しい人々に到達することです。さらに、ソーシャル・チャンネルへのライブ・ストリーミングは、あなたのブランドに信憑性をもたらします。ライブ配信では何が起こるか分からないので、視聴者にチャンネルを合わせる理由と、生身の人間を見ているという感覚を与えることができる。

3.ライブストリーミングはユニークなコンテンツを構築する

ソーシャル チャンネルにライブ ストリーミングすることで、イベントが終了した後に再び使用できる新しい動画資産を構築できます。最近の NAB での Live to Social の発表では、ブライトコーブのパートナーへのインタビュー 2 件、ブライトコーブの C レベル スタッフへのインタビュー 4 件、および製品マネージャへのインタビュー 4 件を含む、7 件の会場インタビューを Facebook でライブ配信しました。動画の進化と今後の方向性という、タイムリーかつエバーグリーンなトピックを取り上げたため、そのコンテンツは今後のキャンペーンで使用することができます。実際、NAB Showfloor からのライブ動画は、ブライトコーブのNAB Facebook Live プレイリストでオンデマンドでご覧いただけます。

有名ブランド担当者が語る、映像を使ったコミュニケーション形成

Brightcove ユーザでもあり、オウンドメディアやソーシャルメディアでも動画を活用されている東洋ゴム工業株式会社 ブランドコミュニケーション部 部長の森國様と、サッポロビール株式会社 マーケティング開発部 デジタルコミュニケーショングループ シニアマネージャーの山根様をお迎えし、パネルディスカッションを行いました。

テレビ番組のキャッチアップ・サービスを開始 - 日本テレビ Pt.

テレビ、新聞、インターネットのメディア業界における映像配信の歴史は、業界の黎明期から現在に至るまで、決して平坦なものではなかった。そこには無名の挑戦者 "Video Addict "たちが、さまざまな試行錯誤と失敗を乗り越えてきた歴史がある。本連載では、インタビュアーの土屋が12回にわたってさまざまな挑戦者たちの歴史を振り返る。

多階層のOTTモデル:観客に選択権を与える

OTTサービスを立ち上げる際、最初に決めなければならない大きな決断のひとつは、コンテンツのマネタイズ方法を決めることだ。

OTTコンテンツ・プロバイダーにとって、より古く確立された収益モデルが引き続き人気のある選択肢である一方、いくつかの新しい選択肢がますます目立つようになってきている。

多段階のOTT収益モデルを活用することで、この決定を視聴者に委ねることができ、視聴者がコンテンツに対する支払い方法を柔軟に選択できるようになる。

さまざまなマネタイズ・モデルと、多層的なアプローチの利点について、詳しくはこちらをお読みください。

一般的なマネタイズ・モデル

広告付きビデオ・オン・デマンド(AVOD)、サブスクリプション・ビデオ・オン・デマンド(SVOD)、ハイブリッドは、現在OTTコンテンツ・プロバイダーが一般的に使用している主な収益モデルである。

これらのモデルの違いを簡単に説明しよう:

  • AVOD。視聴者は広告を見る代わりに無料コンテンツにアクセスできる。

    • 有名な広告付き動画サービスには、YouTube、Pluto TV、Crackle、そしてConde NastやVice Mediaといった多くのパブリッシャーサイトがある。
  • SVOD。このモデルでは、視聴者はコンテンツを見るために購読料を支払う。

    • 加入者支援型ビデオサービスは、OTTの世界で最大のセグメントを構成しており、Netflix、Amazon Prime Video、HBO Now、Showtimeなどの超大手が含まれている。しかし、SVODには、Hallmark Movies NowやWWE Networkのような何百ものプロバイダーや、Curiosity StreamやCrunchyrollのような非常に小規模でニッチなプロバイダーも存在する。   
  • ハイブリッド。一部のOTTサービスは、ハイブリッド・アプローチを採用し始めている。これは、無料の広告付きサービスと、プレミアムなサブスクリプションサービスの両方を提供するものである。これにより、視聴者をサブスクリプションモデルに移行させるためのソフトな移行が可能になる。プロバイダーは、階層化された購読モデルを提供し、プレミアム料金を支払う意思のあるユーザーだけがアクセスできるように特定のコンテンツをゲート化することで、この戦略をさらに一歩進めることができる。

    • コンテンツ・コストの高騰が続く中、ハイブリッド・サービスが注目されており、小規模なサービスでは、プログラマティック広告が収益の増加源となる可能性がある。APACでは、通信事業者のPCCWがVie OTTサービスで成功を収め、消費者に広告付きの低額コンテンツと有料購読ベースのプレミアムコンテンツを幅広く提供している。米国では、CBS All-AccessとHuluが切り詰めたハイブリッド・モデルの良い例で、サブスクリプション・プラス広告に基づくサービス、または広告なしの高価格サブスクリプション・パッケージを提供している。その名が示すように、ハイブリッドモデルはかなり柔軟性がある。

AVODとSVODには、それぞれ独自の利点と課題がある。ビデオコンテンツを視聴するためにお金を払うことができない、または払いたくない視聴者にとっては、従来のAVODオプションは依然として人気があり、成功した収益化モデルである。AVODは、さまざまな属性やオンライン上の行動に基づいて、ユーザーレベルのターゲティングを正確に行うことができるため、広告主にとってますます魅力的な選択肢となっている。AVODはまた、視聴者獲得を促進し、サブスクリプション疲労と戦うための良い選択肢でもある。より確立された視聴者を持つサービスにとって、SVODはよりリニアで予測可能な収入の流れを提供する。また、SVODは、コンテンツに焦点を絞り、時間をかけて徐々に視聴者を増やしていこうとする小規模なサービスにとっては理想的なビジネスモデルである。

その他の収益化モデル

今日のOTTサービス・プロバイダーは、市場参入アプローチの柔軟性を求めており、以下のような新たな収益モデルを試したがっている:

  • トランザクション・ビデオ・オン・デマンド(TVOD)。このモデルでは、ユーザーは無料でサービスに登録またはダウンロードできるが、タイトルごとにコンテンツを購入する必要がある。TVODは、長編映画コンテンツや、スポーツ・イベントやコンサートなどのライブ・ペイ・パー・ビュー(PPV)コンテンツに人気がある。例えば、アップルやアマゾンは、タイトルを購入またはレンタルするオプションを顧客に提供しており、WWE、UFC、プロボクシングなどは、PPVを幅広く利用している。

  • 認証VOD(authvod)。このモデルでは、コンテンツにアクセスするために、別のプラットフォームやサービス、ケーブル(TVE)、携帯電話契約などの認証情報を使ってログインすることがユーザーに要求されることがよくあります。このため、AuthVODは、パートナーシップを調整したり、複数のプロパティやブランドサービスを管理したりする際に重宝されます。しかし、AuthVODは、視聴者が視聴するためにログインを作成する必要がある無料の広告付きサービスを指すこともある。エンド視聴者にとってのメリットは、コンテンツの「ウォッチリスト」を作成したり、デバイス間で「一時停止と再開」を行ったりできることである。サービス・プロバイダーにとってのメリットは、マーケティングや広告の目的でエンド視聴者についてより詳しく知ることができることである。

多段階価格モデルのメリット

多段階の価格設定モデルを提供することで、コンテンツ所有者は、視聴者が自分の視聴ニーズやコスト制限に最適なパッケージを柔軟に選択できるようになります。視聴者にコンテンツの支払い方法(およびその金額)を決定する権限を与えることで、OTTサービスをより多くの視聴者にアピールし、需要曲線に沿ったより多くのポイントを活用して収益を最適化することができます。

高額のチャンネルを積み重ねるモデルから、よりカスタムメイドの視聴へと進化するのは、ごく自然なことのように思われる。今日の視聴者は、多くの選択肢から選ぶことができ、価格に敏感で、自分が熱中できるコンテンツにお金を払うことを厭わない。最も人気のあるチャンネルの多くは大手ネットワークだが、消費者が最も喜んでお金を払う有料サービスの大半はニッチなものだ。したがって、多段階の価格設定は、現代の視聴者がビデオ・サービスを選択する際に、より自由で柔軟性を与えることになる。

ブライトコーブ・ビーコン

ブライトコーブでは、コンテンツ所有者が、異なる SVOD 層でコンテンツの価格設定とパッケージ化を行えることの価値を理解しています。Accedoおよび Cleeng との提携により、Brightcove Beacon に新しい複数パッケージ SVOD を追加しました。このような多階層の購読機能は、市場をリードする当社のソリューションに、追加費用なしで洗練性を付加します。

この機能により、ブライトコーブの顧客は、垂直または水平のサブスクリプション階層を提供できるようになります。垂直ティアでは、異なるタイプのコンテンツに対して別々のサブスクリプションを販売することができます。たとえば、映画とスポーツ コンテンツのバンドルを提供できます。水平階層は、コンテンツの量によって分けられ、しばしばゴールド、シルバー、ブロンズパッケージと呼ばれる。

視聴者が特定のアセットにアクセスできない場合、そのコンテンツにアクセスする権利がない旨のメッセージが表示され、当該アセットに関連する購入ページへのクリックが促されるため、アップセルの機会が促進される。

今日の混雑したOTT市場において、コンテンツ・プロバイダーは、ターゲットとする視聴者の利益を念頭に置いて、その提供物を構築し、規模を拡大しなければなりません。今日の視聴者は選択肢を重視し、魅力的で適切な価値提案を求めているため、多階層のOTT収益モデルは、サービスプロバイダーが検討すべきエキサイティングな新しい選択肢です。

OTTサービスを立ち上げ、成長させる方法

Today, more video is being consumed online than ever before. In fact, according to the findings from our 2018 Global Consumer Streaming Habits Survey, 58 percent of global consumers stream content at least once a week via a connected TV—while 51 percent stream at least once a week on a mobile device, and 50 percent do so on a computer or laptop.

このますます混雑するOTT環境で成功するためには、視聴者を十分に理解し、魅力的で適切な価値提案とともに、理想的なユーザー体験を提供する必要があります。

Are you ready to be a leader in the OTT space? Download our first OTT Essentials whitepaper, the ultimate guide to launching and growing an OTT service. Read on for a preview of what the white  paper covers; then download the asset for more insights and inspiration on how to provide the optimal user experience—and keep viewers coming back for more.

自信を持って発売

OTTサービスを開始する際には、独自の魅力的なコンテンツと配信戦略を確立しなければならない。

次のような質問を自分に投げかけて、戦略を明確にし、それをどのように実行すれば最良の結果が得られるかを判断しよう:

  • どのジャンルのコンテンツを提供しますか?

  • ターゲットは誰ですか?

  • 予算はいくらですか?

  • 接続されたテレビ、スマートフォン、タブレット、デスクトップコンピューターでの効率的でスケーラブルな画面体験をどのようにプログラムするのか?

  • どのようにして、あなたのコンテンツをターゲットとする視聴者の前に届けるか?

全体的な戦略を定めたら、コンテンツをどのように収益化するかを決定する必要がある。OTTコンテンツ・オーナーが採用している最も一般的なビジネス・モデルには、広告付きビデオ・オン・デマンド(AVOD)、サブスクリプション・ビデオ・オン・デマンド(SVOD)、そして、プレミアムなサブスクリプション・サービスと無料の広告付きサービスの両方を提供するハイブリッド・アプローチがある。どのモデルが自社のビジネスに最適かを判断する際には、コンテンツ・カタログ、視聴者の所在地、マーケティング予算などの要素を考慮する必要がある。

視聴者数の増加と収益性の向上

視聴者のネットワークが確立したら、視聴者を増やすために継続的に努力する必要があります。そして、そのためには、さまざまなOTT解約指標と解約率を下げる方法を理解する必要があります。結局のところ、新規ユーザーをどれだけ獲得しても、そのユーザーが早期に、あるいは頻繁に解約してしまっては意味がありません。ベストプラクティスとして、解約率とコンバージョン率を毎月比較する必要があります。このデータを使えば、新規ユーザーの獲得と既存ユーザーの維持、どちらに重点を置くべきかを判断することができます。

世界中の視聴者がテレビのようなプレミアムな視聴体験にますます慣れていく中、新しい機能を定期的にサービスに取り入れることも非常に重要です。そうすることで、視聴者のエンゲージメントを維持し、収益と利益率を向上させることができます。高度なキャスティングを可能にするにしても、ライブチャンネルをサービスに組み込むにしても、定期的にA/Bテストを実施し、視聴者の体験に関して何が有効で何が有効でないかをしっかりと理解するようにしてください。

動画が19秒後にクラッシュした場合

どんな複雑なソフトウェアにもバグは存在し、大規模なプロジェクトに携わっていると定期的に遭遇する。より印象的で興味深いバグは、単純な原因でありながら、普通ではない、時には奇妙な形で現れるものだ。このバグは、1本の動画が原因でプレーヤーがクラッシュしたことから始まった。それ自体はそれほど珍しい報告ではないが、次のような詳細が際立っていた:

  • 特定のビデオ1本で起きた
  • アンドロイドでのみ発生(ただしアンドロイドの特定のバージョンでのみ発生)
  • いつも再生開始19秒後にクラッシュする

動画自体は、m3uプレイリストフォーマットに基づく断片化された動画配信のためのAppleの標準規格であるHTTP Live Streamingを使用してAndroidデバイスに配信されていた。コンテンツ保護には、PKCS#7パディング付きのAES-128が使用されていた。これは一般にHLS Encryption(略して "HLSe")と呼ばれている。MPEG-DASHなど、コンテンツに利用可能な他のフォーマットではこの問題は発生せず、FairPlay DRM付きのHLSも(あるいはDRMなしも)発生しなかった。問題は、"このビデオ "よりもさらに具体的で、"HLSeを使ったこのビデオ "だった。

幸いなことに、このバグはGoogleのExoPlayerデモアプリで簡単に再現することができ、テスト用のデバイスもそれなりに揃っていたので、様々な主要Androidバージョンのエラーコードとスタックトレースをlogcatから取得するのに時間はかからなかった。具体的なエラーの内容は、デバイスのAndroidのバージョンによって異なるが、それらはすべて共通のテーマを持っていた。主な例外と、スタックトレースのさらに下にある最も興味深い "Caused by "例外は、すべてこの2つの亜種だった(テストしたAndroidのバージョンによって表現は異なる):

java.io.IOException: Error while finalizing cipher
        at javax.crypto.CipherInputStream.fillBuffer(CipherInputStream.java:104)
        at javax.crypto.CipherInputStream.read(CipherInputStream.java:155)
        at com.google.android.exoplayer2.source.hls.Aes128DataSource.read(Aes128DataSource.java:96)

Caused by: javax.crypto.BadPaddingException: error:1e06b065:Cipher functions:EVP_DecryptFinal_ex:BAD_DECRYPT
        at com.android.org.conscrypt.NativeCrypto.EVP_CipherFinal_ex(Native Method)
        at com.android.org.conscrypt.OpenSSLCipher$EVP_CIPHER.doFinalInternal(OpenSSLCipher.java:568)
        at com.android.org.conscrypt.OpenSSLCipher.engineDoFinal(OpenSSLCipher.java:385)
        at javax.crypto.Cipher.doFinal(Cipher.java:1476)

コード的に深く掘り下げると、ちょっとしたウサギの穴になる。核となる暗号コードはCで書かれており、慣れていないとかなり気後れしてしまう。幸運なことに、この "causeed by "には読みやすい型がある。 javax.crypto.BadPaddingException問題はパディングにあります。アップル社の仕様によると、HLSeで使用されているパディング・アルゴリズムはPKCS#7で、以下のように記述されています。 RFC-5652 第6.3節:

6.3.  Content-encryption Process

   The content-encryption key for the desired content-encryption
   algorithm is randomly generated.  The data to be protected is padded
   as described below, then the padded data is encrypted using the
   content-encryption key.  The encryption operation maps an arbitrary
   string of octets (the data) to another string of octets (the
   ciphertext) under control of a content-encryption key.  The encrypted
   data is included in the EnvelopedData encryptedContentInfo
   encryptedContent OCTET STRING.

   Some content-encryption algorithms assume the input length is a
   multiple of k octets, where k is greater than one.  For such
   algorithms, the input shall be padded at the trailing end with
   k-(lth mod k) octets all having value k-(lth mod k), where lth is
   the length of the input.  In other words, the input is padded at
   the trailing end with one of the following strings:

                     01 -- if lth mod k = k-1
                  02 02 -- if lth mod k = k-2
                      .
                      .
                      .
            k k ... k k -- if lth mod k = 0

   The padding can be removed unambiguously since all input is padded,
   including input values that are already a multiple of the block size,
   and no padding string is a suffix of another.  This padding method is
   well defined if and only if k is less than 256.

もしあなたが私のようなものなら、この説明を頭に思い浮かべるのは少し難しいだろう。そこで、いくつかの例を紹介しよう(すべて16バイトのブロックサイズにパディングしている):

  • 88 7c 46 66 9a 2f a2 59 4d 1e で埋められる。 06 06 06 06 06 06
  • 63 で埋められる。 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f 0f
  • f5 5c 6b 13 cf 54 f8 45 c1 ca 67 ec 50 20 12 で埋められる。 01

わかりやすく言えば、パディングされるバイト数は、使用されるブロックサイズまでのバイト数である。

パディングがどのように機能すべきかを理解し、不正なパディングを示すエラーを理解した上で、次のステップとして、動画のパディングを処理するコードをチェックした。問題のサービスはGoで書かれており、Goの標準ライブラリにはPKCS#7の実装がないため、サービスは独自の実装を持っている。これがそれだ:

PKCS7Pad(in []byte) []byte {
    padding := 16 - (len(in) % 16)
    for i := 0; i < padding; i++ {
        in = append(in, byte(padding))
    }
    return in
}

短くシンプルで...明らかな間違いもない。私たちが期待している通りの振る舞いをするユニットテストもある。だから、もう少し手がかりが必要なのかもしれない。この時点で、私たちのコードが生成しているものを他の実装と比較するために回り道をした。幸運なことに、HLSe セグメントに適用される AES-128 暗号化は、他のコンテンツ保護スキームで 起こりうるような、ファイルコンテンツの一部分に対してではなく、セグメントファイル全体に対して適用される。暗号化された代替セグメントを作成するのは、OpenSSLで簡単にできましたし、ダイナミックメディアパッケージャーを使って、暗号化するセグメントの保護されていないコピーを入手することもできました。平文でダウンロードされたセグメントと、AES-128 で暗号化されたセグメントを使って、以下のコマンドで暗号化された代替セグメントを生成した:

openssl aes-128-cbc -K $KEY -iv $IV -in clear.ts -out alt_protected.ts

OpenSSLからの暗号化の出力は、私たちのGoアプリからの出力(つまり1ブロック)よりちょうど16バイト大きかったのです。おそらく問題はパディングにあるのではなく、最後のブロックが追加されていない奇妙なエッジケースにあるのだろう。この新しい情報を念頭に置いてGoコードをもう一度見直すと、以下の条件が怪しく見えてきた:

// If this block does not match the AES block size we need to pad it out
if bytesRead != aes.BlockSize {

額面通り、このアルゴリズムは、入力バッファからブロックサイズに等しい長さのチャンクでデータを読み取るだけである。その後、いくつのブロックが読み込まれたかをチェックし、必要であれば16バイトにパッドする。最後に16バイトのバッファを暗号に渡し、出力を出力バッファにストリーミングする。現実的には、この条件がトリガーされるのは最後のブロックだけである。最終ブロックの長さがブロック・サイズと等しい場合はどうなるか?Goのコードは単に何もせず、パディングは必要ないと主張する。念のため、もう一度仕様を確認してみよう:

the input shall be padded at the trailing end with k-(lth mod k) octets all having value k-(lth mod k), where lth is the length of the input.

だから、もし k はブロックサイズであり lth は入力の長さである。 16-(0 mod 16) バイトのパディング。 16-(0 mod 16) イコール 16...だから実際には、これは最後にパディングのブロック全体があり、パディングされた各バイトの値は16に設定されているはずだ!最後に、リード!我々のGoコードは仕様に準拠していない!

問題を提示している同じコンテンツに対してパッチをテストすることで、多少前方へ飛ばし、ビデオの19秒を過ぎたあたりでようやく正常に再生できるようになった!最終的には、何バイト読み込まれたかに関係なく最後のブロックをパッドするように、欠陥のある条件を書き換えることで解決しました。これで問題は一挙に解決した!

要約すると、このバグ報告の奇妙な特徴はすべて、私たちのシステムでテストしたすべてのコンテンツの中で、ビデオ(断片化されたMP4として保存され、トランスポートストリームセグメントにmuxされた)が16で完全に割り切れる長さ(バイト単位)を持つセグメントを持った初めてのものであるという、ありそうもない現実に起因している。なぜ19秒なのか?セグメントの長さは10秒で、パディングが正しくないのは3番目のセグメントだからです。なぜクラッシュはアンドロイドのいくつかのバージョンでのみ発生し、他のデバイスでは発生しなかったのでしょうか?大半の実装はこのミスに強いようです。アンドロイドの古いバージョンは影響を受けやすかったが、最近のバージョンでは対処できた。

すべての疑問が解決し、バグも修正されたので、あとはいくつかの教訓を残すのみである:

  • 可能な限り、標準化されたアルゴリズムの、戦場でテストされた既存の実装を使用する。
  • もし自分で実装するのであれば、仕様に忠実でなければならない。エッジケースを見逃すと損をする!
  • 本当に楽しくて奇妙なバグでさえ、退屈な解決策がある。