インターハイで同時100本のライブ配信を実現

ライブ放送にミッドロール広告を

運動通信社は、インターネットスポーツメディア「SPORTS BULL(略称:スポブル)」を運営する企業だ。60 を超える媒体と提携し、40 以上のスポーツをカバーする。野球やサッカーなど広くファンを抱えるスポーツだけでなく、いまはマイナーであってもファン層を拡大したいと考えている競技のきめ細かな情報まできちんと拾い上げ、ユーザーは急増している。イベント時には一気に視聴・訪問者数が増え、2018 年夏の高校野球では300 万超DAU(1 日あたりのアクティブユーザー数)を記録している。高校野球同様、夏の大型コンテンツがインターハイだ。同社 取締役 熊谷裕佑氏は、「アマチュアスポーツは、とても裾野の広いターゲットを抱えています。地域に根付いていますし、現役世代からも、その親世代、祖父母の世代からも観てもらえます。実は、弊社でプロスポーツを観る習慣のある人は半数くらい。それでもみんなアマチュアスポーツには引き込まれます。不思議な魅力があって、学生時代に部活動の経験をもつ人が多い日本人が持つ原体験なのかもしれません」と話す。あらゆるスポーツ分野の情報配信に取り組む同社にとって、そしてスポブルのファンにとって、高校生の日本一を決めるこの大会は、大きなイベントになる。

そのインターハイをライブ配信したいという思いが、同社に動画プラットフォームの採用を決断させた。創業以来、動画コンテンツはいくつか配信してきており、視聴者からの反応は良かった。しかし、配信にあたってコンテンツ管理者側の負担は大きく、スタートアップ企業が少ない人員で本格的に動画に取り組むことは難しかった。ライブ配信となると、さらに負担は増し、常駐する人員も必要になる。そうした課題を解決できる仕組みとして、インターハイを生中継したいという思いから、同社は動画プラットフォームの採用を決めた。同社は創業以来、いくつかの動画コンテンツを配信しており、視聴者からの反響も上々だった。しかし、コンテンツ担当者の負担は大きく、少人数のスタートアップ企業が動画に本格的に取り組むのは難しかった。生放送となるとさらに負担は増え、専任のスタッフを置く必要がある。このような問題を解決できるシステムとして、Brightcove Video Cloud は最適だった。

開発1 部 部長 熊谷 太樹氏は、「ライブ配信にプリロールミッドロール広告を入れて安定運用できるソリューションは、Brightcove Video Cloud しかありません。ITの 知識が必須となる作業が不要で、操作を覚えればいいだけになる点も魅力的で、これなら当時の体制でもインハイ.tv(インターハイ)やBIG6.tv(東京六大学野球)のライブ配信を実現できると確信できました」と当時を振り返る。

インターハイ期間に700本のライブ配信を実現

ブライトコーブの採用は 2018年。当時の社員数は約 10人だった。夏のインターハイに向けてテストを進め、実際に試合を撮影してくれる現地のパートナー企業との打ち合わせも重ねた。そして、動画の撮影から Brightcove Video Cloud への取り込み、配信へと至るプロセスを規定。専用アカウントを発行して現地から動画プラットフォームに直接アクセスして納品してもらうこととし、動画のアップロード、ダウンロード、再アップロードという手間をなくした。こうして、最小の管理工数で試合をライブで視聴者に届けることができた。

まもなく、5G の時代を迎えます。動画へのニーズはいままで以上に膨れ上がるでしょう。それに先立ってプラットフォームを整え、配信プロセスを整備したことは、私たちのビジネスにとっても大きなメリットがあったと感じています。

熊谷 裕佑氏

株式会社運動通信社 取締役

配信は大規模なものだった。1 日当たり 100 本以上の動画を視聴者へ届ける。うち、ライブ中継も複数の競技で同時に走らせ、期間内に 700 もの試合がライブ中継された。最終的には、編集を加えて長尺・短尺を合わせて約 1 万 2000 本の動画コンテンツとして公開されている。

「すべての作業を動画プラットフォーム上で完結できるようになったことで、体感として全体の工数を約30%に減らせた印象です。Brightcove Video Cloud がなければ、この規模の配信は実現できなかったと断言できます」(熊谷 太樹氏)。

“濃いユーザー” により楽しんでもらえるコンテンツを

アマチュアスポーツには、“濃いユーザー”が多いという。滞留時間が長く、じっくりと見てくれる。何度も訪問してくれるユーザーも多い。インプレッション数はメジャーなスポーツにかなわないが、競技への熱い思いを持つユーザーが確実に存在する。同社はそうしたユーザーに、より楽しんでもらえるコンテンツを届けていこうとしている。

熊谷 裕佑氏は、「私たちの目指すところは、スポーツを  “観る”、“する”、“支える” 存在になる ことです。いまは、動画を使って “観る” に注力しながら、“する” ことによる体験創出も支援しようとしています。」と話す。

将来は、支える存在へ。興味を持ってくれる層を開拓・育成しながら、より良い情報発信の支援やマネタイズ手法のコンサルティングなど、より直接的にかかわってくことが目標だ。その際にも、あらゆる競技団体に対して、優れた動画コンテンツとそれが生み出す広告収益を、大きな魅力として伝えられるかもしれない。

「まもなく、5G の時代を迎えます。通信がより高速になり、大容量なデータを高速にやり取りできるようになれば、動画へのニーズはいままで以上に膨れ上がるでしょう。それに先立ってプラットフォームを整え、配信プロセスを整備したことは、私たちのビジネスにとっても大きなメリットがあったと感じています」と話している。

エンドツーエンドの暗号化トランスコーディング・パイプラインの設定

多くのZencoderのお客様にとって、トランスコーディングのプロセスにおいてコンテンツの安全性を確保することは最優先事項です。Zencoderが暗号化入力をサポートするようになったことで、お客様はZencoderを経由するデータが決して暗号化が適用されていない状態に保存されないようにすることができます。つまり、Zencoderは暗号化された入力を受け入れ、トランスコードするために復号化し、出力ビデオをストレージに書き込む前に再暗号化することができます。このワークフローの重要性は、入力と出力の両方が保護されることです。もし権限のないユーザーがこれらの暗号化されたファイルにアクセスできたとしても、暗号化に使われたキーとIV(Initialization vector)のペアがなければ見ることはできません。このプロセスがどのように見えるかを見ていきましょう。始める前に、暗号化された入力が必要になります。この例では、OpenSSLを使用してローカルでファイルを暗号化し、トランスコード・ジョブを作成する前にS3にアップロードします。

$ openssl aes-256-cbc -k zencoderisawesome -in trailer_test.mp4 -out trailer_test.mp4.enc -p

について -k フラグは使用したい秘密で、この場合は "zencoderisawesome"になります。この場合 -p フラグはOpenSSLに、終了時にキーを出力するよう指示します。当社の場合、出力は以下のようになりました。

salt=9E7E90A964768A2F
key=DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66
iv =375FDBBB213C062D544FCB5A6ACBA44E

これでファイルは暗号化されたので、以前のようにファイルを再生することはできないはずです。Zencoderがアクセスできるように、ファイルをS3かFTPサーバーにアップロードする必要があります。ここではS3のアップロード・インターフェースを使うことにします。S3アップロードリクエストを作る時間です。リクエストの作成には Node.jsライブラリ のような別のツールを使ってリクエストを送ることもできます。 リクエストビルダー入力には、上記で使用した暗号化キーとIVを指定する必要があります。

var zencoder = require('zencoder')();
zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome"
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

これは、標準的なh.264出力を作成するのに十分ですが、どのような方法でも暗号化されません。暗号化されたメザニンファイル(他の低品質出力を作成するために使用される非常に高品質な中間ファイル)は、透かし入りの出力や低品質出力に使用して配布したい場合などに、このファイルがあると便利です。1つのメザニンファイルを3つの異なるサービスにアップロードしたいとしましょう。1つの出力は透かしの入った暗号化されていない低品質バージョンで、残りの2つは2つの異なるキーを使って暗号化し、1つは識別用の透かし入り、もう1つは透かしなしのファイルに出力したいと思います。このリクエストを作成する前に、使用する2つのキーを生成する必要があります。OpenSSLをもう一度使って、新しい鍵を作ります。

$ openssl enc -aes-256-cbc -k supersecret -P
salt=12B83BBF81DFA5B7
key=48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08
iv =2B3CABAB503198DB32394245F54E2A34

$ openssl enc -aes-256-cbc -k anothersecret -P salt=DE2DE044EA5FEB2A key=3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D iv =169C3DE53C56E74130CDA57BA85F8255

これで、トランスコード処理中に出力を暗号化するときに、これらのキーを使うことができます。

zencoder.Job.create({
  input: "s3://zencoder-demo/trailer_test.mp4.enc",
  decryption_method: "aes-256",
  decryption_key: "DAFF64EAE3B3AB9C7905871E407293D4987E16DE76578372E161B1261F39CD66",
  decryption_password: "zencoderisawesome",
  outputs: [
    {
      url: 's3://some-bucket/decrypted.mp4',
      quality: 3,
      width: 320,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }]
    },
    {
      url: 's3://some-other-bucket/encrypted-watermarked.mp4',
      width: 720,
      watermarks: [{
        url: 's3://zencoder-live/test-job-watermark.png'
      }],
      encryption_method: "aes-256",
      encryption_key: '48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08',
      encryption_iv: '2B3CABAB503198DB32394245F54E2A34'
    },
    {
      url: 's3://some-bucket/encrypted-out.mp4',
      width: 720,
      encryption_method: "aes-256",
      encryption_key: '3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D',
      encryption_iv: '169C3DE53C56E74130CDA57BA85F8255'
    }
  ]
}, function(err, data) {
  if (err) {
    console.log("Job wasn't created…");
    return console.log(err);
  }
  console.log("Woo!");
  console.log(data);
});

1つの出力から暗号化を省き、他の2つの出力を別々に暗号化するというのは、奇抜なことのように思えるかもしれませんが、使用例を考えてみてください。低画質の出力はサンプルとして使うことができます(この目的のために短いクリップを作成することもできます)。高画質バージョンの1つには、動画をアップロードする相手を特定する透かしが入っているので、その相手に解読して視聴するためのキーを提供することができます。3つ目の透かしのないコピーは、私たちが管理するバケットにアップロードし直します。ローカルに暗号化されたファイルがあれば、最初に暗号化したときと同じような手順で復号化することができます。透かし入りファイルの暗号化を解除するには $ openssl enc -aes-256-cbc -d -K 48A9E3FA8A629AEBA5B4F1FAC962920F0D7084E306E0D01A0ED01C920BBCBD08 -iv 2B3CABAB503198DB32394245F54E2A34 -in encrypted-watermarked.mp4 -out decrypted-watermarked.mp4 透かしなしでファイルの暗号化を解除する: $ openssl enc -aes-256-cbc -d -K 3AAE9D6E5212224BB9F76E328D2BD826F17B4FC292845B6E3B72634D2C28052D -iv 169C3DE53C56E74130CDA57BA85F8255 -in encrypted-out.mp4 -out decrypted-out.mp4 これでエンド・ツー・エンドの暗号化エンコーディング・パイプラインができました。これらの例で使用されている暗号化されたファイルは、こちらの場所から入手可能です。実際にこの認証情報を使って暗号化されているので、テストファイルとして自由にご使用ください。 メモしかし、これはデジタル著作権管理(DRM)と混同してはなりません。適切なDRMソリューションは、コンテンツへのアクセス権を扱うようなもので、特定のデバイスやユーザーまで、より細かく設定することができます。暗号化されたファイルは、暗号化キーと関連するパスワードを使用してのみ見ることができますが、それが唯一の基準です。

プレイブック:スポーツ動画戦略の作り方

スポーツの価値は、試合、リーグ、チーム、選手を超えたところにある。根本的に、スポーツは瞬間で構成されている。そして、人はその瞬間を覚えているだけでなく、どこにいたか、誰といたか、何を食べていたかまで覚えている。スポーツは感情によって成長し、繁栄する。喜びであれ、絶望であれ、羨望であれ、スポーツは1秒、100分の1秒、あるいは10年後にさまざまな感情を呼び起こす。

出版社がスポーツを映像の文脈で考えるとき、視聴者を引きつけ、特別な体験を創出する機会があることを理解すべきです。それは、ニュースの即興性、物語映画のドラマチックな展開、そして試合やシーズンを重ねるごとに蓄積される膨大なデータを融合させる体験です。

スポーツの4つのS

出版社が映像を活用して視聴者とのエンゲージメントを高めるための機会は、次の4つのカテゴリに分類できます。

  • 統計とスコア
  • ソーシャルと共有
  • 自発性
  • ストーリー

統計とスコア

統計とスコアは、スポーツを記録し、測定し、分析し、追跡する手段です。最終的には、誰かまたはあるチームが「勝利(W)」を手にし、少なくとも一人または一つのチームが「敗北(L)」を受け入れることになります。時には引き分けが生じることもあります。

映像は、あらゆる種類のリアルタイム統計に対してコンテキストを提供できます。

スポーツイベントでは、「ビッグプレー」を取り上げることが一般的ですが、得点に結びつかない瞬間も、試合、チーム、選手の流れやリズムを理解するうえで同様に重要です。

  • ペナルティー(または物議を醸すような、または見逃されたコール)
  • 一見些細な瞬間(例:中継交換時の迷い、選手の交代など)
  • 戦略(例:サッカーのセットプレー、バレーボール)
  • パフォーマンス(選手のスプリットや球速の変化など)

ある人にとって、スポーツそのものは、さらに大きな情熱を運ぶ手段に過ぎません。その情熱は試合だけでなく、シーズン、仕事、街、そして友情にまで広がっていきます。

ファンタジースポーツゲームは野球やアメリカンフットボールで最も人気がありますが、サッカー、バスケットボール、自動車レース、ゴルフなどのファンタジーゲームも珍しくありません。

ファンタジースポーツのシーズン中や個々のゲーム中に、ビデオは最近のゲームや進行中のゲームから収集したリアルタイムのデータを補強するために使用することができ、タッチダウン、ゴール、三振、ビッグヤーデージゲインなど、あらゆるタイプのファンタジースポーツの「得点」を強調します。

しかし、ファンタジースポーツの参加者は、リアルタイムデータの流れを受け身で眺めている時間も多くあります。出版社は、このデータ主導の体験を映像体験へと拡張できます。ハイライト映像を集約・統合・シリーズ化し、ファンタジーチームや選手に関する「ビデオストーリー」を作成することで、統計やスコアをまとめた仮想的な「シズルリール(魅力的なダイジェスト)」を提供できるのです。

リアルタイムまたは最近のデータとビデオを同期させることよりもさらに魅力的なのは、チームや選手の統計を調査する際に、ビデオを利用して追加のコンテキストを作成する可能性です。出版社は、消費者が統計を単に視聴するだけでなく、ビデオを通じて調査できるようにすることで、魅力的な体験を提供できます。

ソーシャルとシェアリング

スポーツは一般的に、参加、出席、観戦のための社会的活動です。

動画は試合そのものを見るだけでなく、重要な役割を果たすことができます。

パーソナル・ネットワーク(Eメールやテキスト)であれ、ソーシャル・ネットワーク(フェイスブックやツイッター)であれ、スポーツはその瞬間を超え、再生価値を高めます。

ソーシャルメディアでは、出版社は動画を活用することができます:

  • 特定の瞬間について会話を始める(得点、「あと少し」の得点、熱狂的なファン、苛立つコーチ)。
  • 視聴者が特定の瞬間について会話を始めたり、自分自身の一連の瞬間を「リミックス」したり、独自のスポーツセンタースタイルの総集編を作成したりできるようにする。
  • スポンサードされたテーマのコンテンツで新たな収益化の機会を創出する。

スポーツクラブやリーグは、動画を次のように活用できます:

  • シーズンチケットホルダーや観客を誘致するためのスタジアムの変更点の告知(食事オプション、観客席やスイートルームからの眺め、試合当日の特別イベントや景品の予告など)
  • ファン層を強化し、そのオーディエンスを動員して長期的なブランド価値を築くために、ユーザー生成コンテンツを活用する(例:看板、歓声、"アットホーム "なファン、テールゲートパーティー、食べ物などの "ベスト "な例)。

自発性

パブリッシャーは、デスクトップからモバイル、コネクテッドTVに至るまで、すべてのビデオ体験が、コンテンツを発見したいという視聴者の欲求に適応するようにしなければならない。スポーツコンテンツには、次のような特徴がある:

  • 生演奏、タイムシフト、録音済みの両方で消費される
  • リーグ、チーム、選手、そしてファンの視点から見る
  • データとは切っても切れない関係

こうしたあらゆる側面から、出版社はエンゲージメントと収益化を高めるためにディスカバリーとプロモーションを最適化する機会があります

動画消費のリラックスモードでは、出版社はコンテンツを自然に感じさせるべきです。視聴者は、マイケル・フェルプスがわずか0.01秒差で金メダルを獲得した再放送を最初に見るかもしれません。この「接戦」というビデオのコンセプトに基づいて、動画体験は自動的に似たようなコンテンツのダイナミックなプレイリストをプログラムすることができます。例えば、クリスチャン・レイトナーのケンタッキー戦でのターンアラウンドジャンパー、ジミー・ジョンソンのタレデガでの0.0002秒差での勝利、またはブラックホークスのカップを勝ち取るためのラストミニットラリーなどです。

ストーリー

動画は6秒でも6時間でもストーリーを伝えることができます。スポーツコンテンツに注力する出版社にとって、すべての動画は、リーグ、チーム、選手、コーチ、ファンに関するストーリーです。しかし、スポーツのストーリーは、あらゆる要素を包含することができるため、組織化されたリーグという伝統的な範囲を超えることができます。

GoProを手にすれば、釣り人が950ポンドのカジキと格闘したり、クライマーがエル・キャピタンを登ったり、ジオキャッシングに興じたり、都市探検家がパリの石畳の下を駆け回ったりするのを見ることができます。

出版社には、消費者の感情に訴えるまたとない機会があります。ニュース・コンテンツは一過性のものであり、即時性と歴史的アーカイブの両方から価値を得ますが、スポーツの瞬間は何度でも同じレベルのドラマを見ることができます。

スポーツは、参加者として、あるいはファンとして、人々が情熱を傾けることを可能にし、勝ち負けや引き分けのたびに、その体験を高めることができる重要な役割をビデオが担っています。

ルクセンブルガー・ヴォルト紙がツール・ド・フランスを配信する方法

ルクセンブルクの人口とツール・ド・フランスで活躍した選手たちを比較すると、なぜ自転車競技がこの小さな国の国民的スポーツとなったのかがすぐに理解できます。最初の「グラン・ブークル」が始まってから100年、15人のルクセンブルク出身の自転車競技者がツール・ド・フランスで70回のステージ勝利を収めました。5人のルクセンブルク人が世界で最も有名な自転車レースで優勝し、3週間の過酷な戦いの末、黄ジャージを持ち帰ることができました。だからこそ、自転車競技がルクセンブルクで最も重要な日刊紙のひとつである『ルクセンブルガー・ヴォルト』紙が、サイクリングを最近最もホットな話題のひとつにしているのも不思議ではありません。

ルクセンブルガー・ヴォルト紙のニュース ポータル wort.lu では、ジャーナリストとカメラマンからなる独自のチームが、毎日更新される動画報道を読者に提供しています。Brightcove を使用して、少人数のチームが wort.lu のニュースルームから直接、サイトの動画コンテンツ全体を管理し、オンライン動画、1~5 分の小規模な動画レポート、長い動画インタビューなどのその他の形式を提供しています。ツール期間中、サイクリングファンはwort.luのツールライブティッカーで最新情報をチェックすることができ、主催者であるAmaury Sport Organization (ASO)からの公式ビデオサマリーにも毎晩アクセスすることができます。もちろん、ヴェルラーク・サン・ポール・ルクセンブルグS.A.が発行し、1日85,000部の部数を誇るこの新聞は、ツール記念の年にルクセンブルクのサイクリストたちが再びレースの最前線に立つことを願っています。

出版社が 2012 年に Brightcove の導入を決定した主な要因の 1 つは、ルクセンブルクのモバイル利用率が欧州で最も高い国の 1 つであることでした。住民が移動中にニュースにアクセスする機会が増えているこの国では、幅広いプラットフォームで信頼性の高い高品質の動画配信が不可欠です。Video Cloud SDK を使用することで、wort.lu の開発チームは、2 週間の導入後すぐに wort.lu サイト用のモバイル アプリケーションを開発することができました。スムーズな実装は、当社の豊富なドキュメントとサポート チームとの協力に基づいて行われました。

DMEXCO 2012 では、wort.lu がツール・ド・フランスの報道と編集コンテンツ全体をドイツ語、フランス語、英語、ポルトガル語で提供しているため、ローカライゼーションも出版業界の意思決定者の注目を集めました。つまり、編集チームは Brightcove を使用して、字幕などの動画コンテンツのラベルやその他の標準テキストを、複数の言語で自動化することができます。

ルクセンブルガー・ヴォルト紙の編集長、Marc Thill 氏にとって、動画部門における wort.lu の戦略的方向性は明確です。「オンラインと印刷の編集チームは徐々に一緒に成長しており、そのためには、確実に増加する将来の動画ニーズに合わせて成長できる Brightcove のようなソリューションが必要でした。特に、当社のインターネット ニュース ポータル wort.lu のトラフィック生成に関して言えば、毎年恒例のツール・ド・フランスの報道は、伝統的にサイクリングに熱心な読者にとって、1 年の固定されたハイライトです。」

この出版社は、ルクセンブルクのニュース市場における wort.lu の主導的地位を維持・拡大するために、このような主要なスポーツ イベント以外にも、インターネットの覇権をめぐる競争が激化する中で、デジタル サービスも日々その実力を証明しなければならないと認識しています。Brightcove によって、出版社は必要な技術的条件を満たしたと Marc Thill 氏は言います。wort.lu のニュースルーム チームは、技術的な労力をかけずに、オンライン動画コンテンツをさまざまなモバイルおよびオンライン ユーザ グループに、毎日、動的かつ確実に配信できるようになりました。出版社はまた、Brightcove の使用により、動画広告オプションの新たな範囲を提供することで、オンライン分野での緊密な協力を求める wort.lu の広告パートナーからの着実に増加する需要に応えることができます。動画市場で収益化を成功させるために重要な分析機能は、Brightcove パッケージに含まれています。

MPEG-DASH:相互運用性、エンド・ツー・エンド配信のための標準の作成

メディアに携わる人なら、MPEG-DASHという言葉を耳にしたことがあるだろう。MPEG-DASHはコーデックでもプロトコルでもシステムでもフォーマットでもない。その代わり、相互運用性のための規格であり、基本的にはHTTP上でのエンド・ツー・エンドの動画配信のための規格である。

MPEG-DASHの主な目標の一つであり、パブリッシャーにとっての表向きの主な利点は、既存のインフラ上でオープンスタンダードを使用してライブおよび録画済みのプレミアムビデオ体験を配信するためのコストと労力を削減できることです。今日のプレミアムビデオ体験には通常、広告、セキュリティ(DRMなど)、アダプティブ・ビットレート再生、キャプション、多言語サポートなどの要件が含まれる。断片化されたデバイス環境において、ライブおよび録画済みコンテンツにこれらの要件を適用することは、パブリッシャーのエンコーディング、パッケージング、ストレージ、および配信ワークフローを複雑化(コスト増)させます。

MPEG-DASHによって、業界のプレーヤーは、動画配信のための3つのデファクトプロトコル(アップルのHTTPライブストリーミング、アドビのHTTPダイナミックストリーミング、マイクロソフトのスムーズストリーミング)を論理的に「進化」させ、複合標準にしようとしている。これは理にかなっている。これら3つのプロトコルは、HTTPネットワーク上でアダプティブ・ビットレート再生用のコンテンツを効率的かつ安全に配信するという点で、達成しようとしていることが非常によく似ている。しかし、互いに互換性はない。

今日、ほとんどのパブリッシャーは、デスクトップ、モバイル、コネクテッドTV、ゲーム機など、さまざまなデバイスをサポートし、コンテンツのユビキタスを目指しています。その結果、パブリッシャーがアダプティブ・ビットレート・ストリーミングをサポートしたい場合、複数のフォーマット、プロトコル、コンテンツ保護オプションをサポートし、デバイスやプラットフォーム間でより広範なサポートを提供するか、標準化してデバイスやプラットフォームのフットプリントを制限する必要があります。

どちらも魅力的ではない。コンテンツ制作(複数のフォーマットや言語に対応したエンコーディング、複数のコンテンツ保護方式に対応したパッケージング)、重複するストレージ、複数のコンテンツ配信プロトコル、能力の異なる複数のプレーヤー、一貫性のない広告フォーマットなど、誰もが非効率的な運用をしている。

MPEG-DASHの目標は、パブリッシャーがビデオワークフローを効率的に管理し、あらゆるプラットフォームやデバイスに配信できるように、ビデオワークフローを合理化することである。

MPEG-DASHは万能か?

MPEG-DASHは実装の詳細を定義しておらず、代わりに以下のタスクと決定を業界全体に委ねている。

  • エンド・ツー・エンドDRM
  • コーデック
  • ファイル形式と下位互換性
  • 現在および将来の知的財産をめぐるロイヤリティの検討と問題点

パブリッシャーが移行を急いだ場合、エコシステム内の個々のベンダーのサポートが限定的であったり、一貫性がなかったり、エコシステム内のベンダー間の相互運用性が欠如しているために、テクノロジーやワークフローの決定が左右される可能性がまだあります。パブリッシャーは、エンドツーエンドのワークフローを真に解決するために、コンテンツ配信、広告、分析、エンコーディング、DRMパッケージングとライセンス管理、プレイバックなど、スタックのすべてのパーツを組み合わせる必要があります。

実際、HTML5の "標準 "で見られた断片化は、MPEG-DASHで遭遇するであろうことを示唆しているかもしれない。

アップルには何があるのか?

また、アップルがMPEG-DASHを推進する理由も明確ではない。彼らはHLSに多大な努力を払い、それを事実上の標準にまで高めてきた。多くのシステムや企業がこのプロトコルを中心に構築されており、私の考えでは、アップルがHLSで得た優位性を犠牲にし、代わりに彼らの提供するものに代わるものの標準化を推し進めるよう説得するのは、おそらく苦しい戦いになるだろう。

歴史は繰り返す...か?

新しい基準やプロセスの実行可能性を評価する際には、歴史的な比較レンズを通して検討するのが有効だ。

かつて企業がどのように商品を輸送していたかを考えてみよう。1950年代以前は、簡単で効率的な方法はなかった。しかし、50年代半ばに、複合一貫輸送とコンテナの概念が導入された。貨物を船、鉄道、トラックで標準的な形式で輸送できるようにすることで、近代的なサプライチェーンが誕生した。プロセスの標準化に合意することが、重要な第一歩だった。MPEG-DASHは同様の「大変革」を成し遂げようとしているが、実装の詳細を避けているため、最終的に分断が方程式に入り込む危険性が大きい。
以下は、我々が遭遇する可能性のある問題である。

  • MPEG-DASHの実装に後方互換性がない場合、MPEG-DASHとHLSの両方をサポートする必要が出てきます。もしHLS(あるいはHDSとスムース)が後方互換性を非効率にする道を歩み続ければ、パブリッシャーはMPEG-DASHとHLS、スムースストリーミングとHDSを考慮することを余儀なくされます。
  • クライアント側のプレーヤー(デスクトップ、モバイル、コネクテッドTVS、ゲーム機)がMPEG-DASHを広くサポートできなければ、パブリッシャーはプレーヤーの断片化に直面することになります。プレーヤーの断片化は上流に流れます。これは、再生から配信、パッケージング、エンコーディングに至るまで、コンテンツのワークフロー全体がMPEG-DASHのワークフローと重複することを意味します。多くのパブリッシャーにとって、採用のコストは増分利益に見合わないかもしれない。

ブライトコーブの見解

パブリッシャーはすでに、複数のフォーマットと関連する配信プロトコルをサポートする運用上の複雑さに直面しています。複数のフォーマットのコンテンツ取り込み、クロスプラットフォーム再生やクロスプラットフォームDRMに必要な複数のレンディションやフォーマット用のトランスコードやパッケージング、デスクトップ、モバイルウェブ、モバイルアプリ、コネクテッドTV向けのアダプティブ・ビットレート・ストリーミングなど、ワークフローのすべてのステップで必要な摩擦や労力を軽減するために、私たちは今後も能力を向上させていきます。

私たちは標準化のコンセプトを支持していますが、エンド・ツー・エンドのMPEG-DASHシナリオを優先するために、他のすべてのサポートを排除できる段階には至っていません。MPEG-DASHは、ビデオ・エコシステムの広さと深さを完全に考慮していないため、早期の採用はベンダー依存やロックダウンにつながる可能性があり、当社の顧客にとって不利になります。

最終的には、MPEG-DASHとエコシステム内のベンダーが、ベンダー依存や標準の不完全な実装をもたらす独自の実装を強要するのではなく、パブリッシャーに柔軟性を提供するために、その機能を迅速に強化することを願っています。それまでは、MPEG-DASHのエコシステムの中で私たちのデジタルな役割に取り組むために、袖をまくり、キーワードに指をくわえているところです。

VIDEO.JS 4.0でパフォーマンスと安定性が向上

Video.js 4.0 は 2013 年にリリースされ、Github でダウンロード可能で、ブライトコーブの CDN で無料でホストされています。背景として、Video.jsは、ブライトコーブが 2012 年に買収した Zencoder のチームによって作成されたオープンソースの HTML5 動画プレーヤです。

Video.jsは、オープンソースの動画プレーヤ技術の市場を破壊し、わずか数年で驚異的な普及と市場シェアを達成しました。無料の Video.js プレーヤーは、モンブラン、ドルチェ&ガッバーナ、ディーゼル、イリー、アップルビーズ、マテル、ケロッグ、レゼコー、米国海軍、エトナ、トランスアメリカ、ワシントン州立大学など、何万もの組織で使用されています。

バージョン4.0は、これまでのどのバージョンよりもコミュニティの協力が得られた。これは、JavaScriptコミュニティの強さが増していること、HTML5ビデオの人気が高まっていること、Video.jsの利用が増加していることを物語っている。2012年から2013年にかけて、Video.jsを使用するサイトの数は2倍以上に増加し、CDNホスト版だけでも毎月2億以上のアクセスがあります。

Video.js 4.0には多くの新機能がある。

  • アドバンスモードでGoogle Closure Compilerを使用することにより、サイズを18%削減し、パフォーマンスを向上。
  • TravisCI、Bunyip、Browserstackを使用した自動化されたクロスブラウザ/デバイスのテストスイートによる安定性の向上。
  • Video.jsを拡張するための新しいプラグイン・インターフェイスとプラグイン一覧
  • フォントアイコンを使用した新しいデフォルトスキンデザインにより、カスタマイズ性が向上
  • レスポンシブデザインとレティナディスプレイ対応
  • より良いARIAサポートによるアクセシビリティの向上
  • Apache 2.0ライセンスに移行
  • Gruntを含む100%JavaScript開発ツールセット

2013年はVideo.jsにとってエキサイティングな年になり、パフォーマンス、マルチプラットフォームの安定性、プラグインやスキンによるカスタマイズ性がさらに向上します。コミュニティのメンバーは、プレイリスト、アナリティクス、広告など、要望の多かった機能のプラグインにすでに着手しています。

トラフィックを増やす7つの動画SEOベストプラクティス

動画のSEOを改善し、サイトへのトラフィックを増やしたいとお考えですか?役立つ7つの簡単なヒントをご紹介します。

1.動画のタイトルと説明文を書く

Googleは「人々のために書く」ことを重視し、動画のタイトルや説明文にキーワードを詰め込むことを嫌います。キーワードを詰め込むのではなく、魅力的で視聴者に関連するタイトルや説明文を書くようにしましょう。

2.動画サイトマップがある場合はタグを追加する

動画にタグを追加することは、ブライトコーブのオンライン動画プラットフォーム内でコンテンツを整理する素晴らしい方法です。簡単な動画サイト マップを作成する開発リソースがあれば、投資する価値は十分にあります。

3.スキーマ・マークアップを使う

スキーマは、ウェブマスターが主要な検索プロバイダーが認識する方法でページをマークアップするために使用できるHTMLタグのコレクションです。検索エンジンは、検索結果の表示を改善し、人々が適切なウェブページを見つけやすくするために、これらのスキーマタグに依存しています。itemscope属性を使用して検索エンジンにコンテンツを動画として識別させれば、SEO効果が高まります。Schemaには、itemscope属性の使用方法に関する説明と、動画を識別するためのhtmlタグの使用に関する一般的な説明があります。

4.高品質のサムネイル画像を選ぶ

サムネイルの編集品質は画像の品質に勝る。別の言い方をすれば、コンテンツに魅力的なサムネイルを選ぶことで、ユーザーのクリック数を増やすことができます。ユーザーのエンゲージメントが高まれば、SEOの結果にも影響します。また、一般的な動画アイコンや「動画はこちら」のテキストリンクよりも、画像サムネイルの方が常にトラフィックの結果が良くなることも注目に値する。

5.動画検索結果を返す上位検索語を取り入れる

動画のタイトルや説明文に「キーワードを詰め込む」べきではありませんが、特定の単語は検索エンジンに見つかる可能性を高めます。ビデオ"、"ショー"、"ハウツー"、"レビュー"、"約 "のような単語はすべて、あなたのコンテンツがビデオのサムネイルの結果を返す可能性を高めるトップ用語です。不自然なことは禁物ですが、タイトルや説明文にこれらの言葉を組み込めば(例:「アロフト・ブルックリンのビデオツアー」)、違いを生み出すことができます。

6.ウェブサイトの最適化

どんなに完璧な動画SEOも、サイトが最適化されていなければ意味がない。動画の設定を微調整する前に、ウェブサイトのSEOが最適化されていることを確認するのは、常に良いベストプラクティスです。

7.動画をページのトップに配置する

動画がある場合は、ページの一番上に掲載しましょう。そうすることで、検索エンジンはそれが動画コンテンツであることを理解することができます。この小さな変更でどんな結果が得られるか、驚くばかりです。

ダイナミック・マニフェストとHLSプレイリストの柔軟性

何年もの間、インターネット・ストリーミングには、RTMPのようなサーバーベースの独自技術と、プログレッシブ・ダウンロードという2つの基本モデルがあった。サーバーベースのストリーミングは、オンデマンドで切り替え可能なマルチビットレート・ストリームを配信できるが、高価なソフトウェアのライセンスが必要だ。プログレッシブ・ダウンロードはApache上で可能だが、ビットレートを切り替えるには再生を停止する必要がある。

HLSやSmooth StreamingのようなHTTPベースのストリーミング・プロトコルの登場は、Apacheのようなコモディティ・サーバー・テクノロジーを使って、標準的なHTTP接続でストリーミング配信が可能になることを意味した。シームレスなビットレートの切り替えは一般的になり、CDN経由の配信は、HTTP経由であらゆるファイルを配信するのと基本的に同じであったため、簡単だった。HTTPストリーミングは、ストリーミングメディアの配信に革命をもたらし、高品質のストリーミングのコストと複雑さを大幅に削減しました。

動画プラットフォームを設計する際には、考慮すべきことが無数にあります。しかし、最も重要で見過ごされがちな決定事項の 1 つは、HTTP ベースのマニフェスト ファイルをどのように扱うかです。

静的マニフェスト・ファイル

物理的な世界では、ビデオを購入するとき、パッケージを見て、箱を手に取り、レジに向かい、レジで支払いを済ませ、家に帰り、プレーヤーに挿入する。

ほとんどのビデオプラットフォームは、かなり似たような構造になっています。基本的に、メタデータのグループ(ボックス)は、再生可能なメディアアイテム(ビデオ)に関連付けられます。ほとんどの動画プラットフォームは、メタデータを単一の mp4 動画に接続する単一の URL という概念から始まります。動画プラットフォームがより複雑になると、複数のビットレート、解像度、またはプレビューや特別な機能など、メインアイテムに関連する他のメディアを表すメタデータに接続された複数のURLが存在する可能性があります。

物理モデルを、HLS のような HTTP ベースのストリーミング プロトコルを含むオンライン ストリーミングの世界に拡張しようとすると、事態はより複雑になります。HLS は、マニフェストと呼ばれるテキスト ファイルによってリンクされた、動画ファイルの多くのフラグメントに基づいています。HLS を実装する場合、最も簡単な方法は、マニフェスト、つまり m3u8 ファイルにリンクする URL を追加することです。これは非常に簡単で、基本的に既存のモデルに適合するという利点があります。

欠点は、HLS が静的なメディアアイテムとは似て非なるものであることだ。例えば、MP4 は DVD のビデオトラックのようなもので、単一の解像度とビットレートの単一のビデオです。HLS マニフェストは、おそらく複数のビットレート、解像度、断片化された何千もの動画から構成されています。HLS は MP4 よりもはるかに多くのことができるのに、なぜ同じように扱うのでしょうか?

HLSプレイリスト

HLS のプレイリストには、ストリームの基本的な要素を記述するメタデータと、動画の断片へのリンクの並びが含まれる。動画の各フラグメント(セグメント)をダウンロードし、それらを順番に再生することで、ユーザは単一の連続した動画のように見えるものを見ることができる。

  • EXTM3U
  • #EXT-X-PLAYLIST-TYPE:VOD
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10、
  • ファイル-0001.ts
  • #EXTINF:10、
  • ファイル-0002.ts
  • #EXTINF:10、
  • ファイル0003.ts
  • #EXTINF:10、
  • ファイル0003.ts
  • #EXT-X-ENDLIST

上記は基本的なm3u8プレイリストです。これは 4 つの動画セグメントにリンクしています。このデータをプログラムで生成するために必要なのは、最初のアイテムのファイル名、セグメントの目標持続時間 (この場合は 10) 、そしてセグメントの総数です。

HLSマニフェスト

HLS マニフェストは、プレイリストへのリンクの並び順のないシリーズです。複数のプレイリストを持つ理由は 2 つあります:さまざまなビットレートを提供するためと、プレイリストのバックアップのためです。以下は典型的なプレイリストで、.m3u8 のそれぞれが別の HLS プレイリストへの相対リンクになっています。

  • #EXTM3U
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2040000
  • ファイル-2040k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1540000
  • ファイル-1540k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1040000
  • ファイル-1040k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=640000
  • ファイル-640k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=440000
  • ファイル-440k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=240000
  • ファイル-240k.m3u8
  • #EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=64000
  • ファイル-64k.m3u8

プレイリストは、ネットワークの状態に関係なくスムーズな再生を提供するために、さまざまなビットレートと解像度を持ちます。マニフェストを生成するために必要なのは、各プレイリストのビットレートとそれらの相対パスだけです。

空白を埋める

動画コーデック、音声コーデック、コンテナ、総ビットレートなど、オンライン動画プラットフォームがエンコードされた動画アセットごとに取得すべき重要な情報は他にもたくさんある。1つの動画アイテムに保存されるデータは、視聴者にとって意味のあるもの(説明、評価、キャスト)、プラットフォームにとって意味のあるもの(視聴時間、視聴回数、エンゲージメント)、アプリケーションにとって意味のあるもの(フォーマット、解像度、ビットレート)でなければなりません。このデータがあれば、視聴者は何を見るかを決め、システムはどのようにプログラムするかを決め、アプリケーションはどのように再生するかを決めることができる。

プレイリスト、マニフェスト、および各プレイリストのコーデック情報をプログラムで生成するために必要なデータをキャプチャすることにより、マニフェストとプレイリストがリクエストごとに生成されるシステムを持つことが可能になります。

例 - 最初のプレイリスト

HLS の仕様では、マニフェストで最初に来るプレイリストのどれが最初に再生されるかを決定します。前のセクションの例では、リストの最初の項目は、最高品質のトラックでもありました。高速で安定したインターネット接続を持つユーザーにとっては問題ありませんが、低速の接続を持つユーザーにとっては、再生開始までに時間がかかります。

デバイスが良好なインターネット接続を持っているように見えるかどうかを判断し、それに応じてプレイリストをカスタマイズする方が良いでしょう。幸運なことに、ダイナミック・マニフェスト生成によって、システムはまさにそれを達成するように設定されている。

この演習では、マニフェストのリクエストがビットレートの順序付き配列で行われると仮定します。たとえば、[2040,1540,1040,640,440,240,64] というリクエストは、前のセクションのものと同じプレイリストを返します。iOSでは、ユーザーがWiFi接続かセルラー接続かを判断することができる。ビットレート、解像度、その他のパラメータを含む各プレイリストに関するデータが取得されているため、アプリはマニフェストの順序をインテリジェントに決定することができます。

例えば、ユーザーがWiFiを使用している場合は800-1200kbpsの間、セルラー接続の場合は200-600kbpsの間で開始するのがベストだと判断されるかもしれない。ユーザーが無線LANを利用している場合、アプリは以下のような配列をリクエストする:[1040,2040,1540,640,440,240,64].アプリがセルラー接続のみを検出した場合は、[440,2040,1540,1040,640,240,64]を要求する。

例 - レガシー・デバイス

Androidでは、動画サポートはちょっとしたブラックボックスだ。何年もの間、Android の公式ドキュメントでは、640×480 のベースライン h.264 mp4 ビデオの使用しかサポートしていなかった。HLSの場合、サポートはさらに断片的で、理解するのが難しい。

幸運なことに、Androidは一握りの主要なデバイスによって支配されている。ダイナミック・マニフェストを使えば、アプリはどのプレイリストから始めるのがベストかをターゲットにできるだけでなく、互換性がないと判断されたプレイリストを除外することもできる。

メディアアイテムは解像度やコーデック情報などのデータも取得しているため、特定のデバイスをターゲットにしたサポートも可能だ。アプリは、すべてのレンディションを送信することを決定することができます:[2040,1540,1040,640,440,240,64].あるいは、720pまでしかサポートしていない古いデバイスは、最も高いレンディションを削除することができます:[1540,1040,640,440,240,64].さらに、モバイルデバイスの世界を超えて、アプリがコネクテッドTVであれば、最低画質のレンディションを削除することができる:[2040,1540,1040,640].

動的または静的

静的マニフェストモデルを選択することはまったく問題ありません。ある程度の柔軟性は失われますが、シンプルであることに問題はありません。多くのユースケース、特にユーザー生成コンテンツの世界では、動的生成に伴う複雑さを必要としません。しかし、動的マニフェスト生成は、積極的に取り組もうとするユーザーにとって多くの扉を開くものです。

マニフェストをどのように扱うかは、動画プラットフォームの長期的な柔軟性に大きな影響を与えるため、専属の圧縮担当者と話し合う必要があります。

ファイルピッカーを使ったビデオのアップロードとエンコード

動画のアップロード方法は、新規のお客様からよくいただく質問の一つです。開発者にとって、ファイル・アップロードの実装は何度かやったことがあることでしょうが、大変な作業です。

Filepickerを使用する

Filepicker(現在はFilestack)はファイルのアップロードを簡単にします。本当に簡単なのです。ローカルファイルだけに限らず、DropboxやGoogleからや、ウェブカメラからの直接ビデオ録画まで、幅広いソースをサポートしています。何より素晴らしいのは、フロントエンドを離れることなく、これらすべてを行えることです。

何か作業をする前に、Filepickerアカウントにサインアップする必要があります。登録が完了したら、ダッシュボードに新しいアプリを作成してください。表示されるAPIキーをメモしておいてください。FilepickerはS3バケットを提供してくれますが、アップロード先のS3バケットを設定するのに少し時間がかかります。

基本的なHTML5テンプレートで同じページから始めましょう。シンプルにするためにjQueryを使うつもりなので、Filepickerライブラリと一緒にボイラープレートにもjQueryを含めます。

<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US">
<head>
    <meta http-equiv="content-type" content="text/html; charset=utf-8" />
    <title>Zencoder Dropzone</title>

    <!-- jQuery Include -->
    <script src="//ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js"></script>

    <!-- Filepicker.io Include -->
    <script type="text/javascript" src="//api.filepicker.io/v1/filepicker.js"></script>
</head>

<body>
    <div id="content">
        <h1>Upload all the things!</h1>
    </div>
</body>
</html>

Filepicker JavaScript APIを使って、ユーザーがファイルを選択してS3バケットに保存できるようにしよう。また、ユーザーがクリックできるように、本文中にリンクを関連付ける必要があります。これを Filepicker JavaScript include の下に追加します。最初にアップロードリンクを追加しましょう。すでに大きくて目立つ h1 タグにリンクを追加しましょう。

<h1><a href="#" id="upload-link">Upload all the things!</a></h1>

では、そのリンクを使って filepicker.pickAndStore をクリックします。ここで、先ほどメモしたAPIキーを使います。このスニペットを、ページのheadにあるFilepicker JavaScript includeの下に置きます。

<script type="text/javascript">
    $(function() {
      filepicker.setKey('The_Key_From_Your_Dashboard');

      $('a').click(function(e) {
        e.preventDefault(); // This keeps the normal link behavior from happening

        filepicker.pickAndStore({},{location: 's3'},function(fpfiles){
            console.log(JSON.stringify(fpfiles));
        });
      });
    });
</script>

何らかのウェブサーバーを使って HTML を提供しないと、外部の JavaScript ファイルを読み込むことができません。http-server のようなものを使うこともできますが、GitHub リポジトリの静的ファイルを配信する基本的な Node アプリケーションがあります。

任意のファイル(比較的小さいものを選ぶとよいでしょう)を選んでアップロードしてください。 fpfiles ファイルをアップロードしたら、コンソールを見てみてください。すべてが計画通りに進んでいれば、新しくアップロードしたファイルに関する情報を持ったオブジェクトがあるはずです。

あなたは、シンプルなHTMLマークアップを含む、合計わずか27行のコードで、コンピュータからファイルをアップロードしただけです。しかし、ただファイルをアップロードして置いておくだけでは役に立たないので、ユーザーが動画をアップロードしてエンコードできるようにしましょう。

Zencoderの追加

まず、アップローダーを動画ファイルのみ受け付けるように変更しましょう。Filepickerでは、mimetypeで制限することができます。 {mimetype: 'video/*'}.これはChromeでは問題なく動作しますが、Safariユーザーにはアップロードできるファイルのサブセットがかなり少なく表示されます。動画の場合は、拡張子で制限する方がはるかに信頼性が高いので、その方法を取りましょう。

$('a').click(function(e) {
  e.preventDefault(); // This keeps the normal link behavior from happening
  var acceptedExtensions = ['3g2','3gp','3gp2','3gpp','3gpp2','aac','ac3','eac3','ec3','f4a','f4b','f4v','flv','highwinds','m4a','m4b','m4r','m4v','mkv','mov','mp3','mp4','oga','ogg','ogv','ogx','ts','webm','wma','wmv'];
  filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
      console.log(JSON.stringify(fpfiles));
  });
});

私は簡単な方法で、Zencoderのフォーマット・ドキュメントにある有効な出力フォーマットのリストを使いました。この中には音声ファイルも含まれていますが、Zencoderは音声のみのエンコードをサポートしているので、そのままにしておくことができます。リンクをクリックしてローカルファイルをブラウズすると、リストにある拡張子を持つファイルしか選択できないことに気づくはずです。選択できないファイルをドラッグ&ドロップしようとすると、エラーになります。

Zencoderがサポートするファイルのみをアップロードできるということがわかったので、アップロードに成功したら、そのファイルをZencoderに送信してエンコードするようにしましょう。その前に、Zencoder APIキーを設定する必要があります。これはFilepickerキーのすぐ下に記述してください。

filepicker.setKey('The_Key_From_Your_Dashboard');
var zenKey = 'Zencoder_API_Key';

jQueryの $.ajax アップロードに成功したら、API リクエストを Zencoder に送信します。

filepicker.pickAndStore({extensions: acceptedExtensions},{location: 's3'},function(fpfiles){
  // This is the simplest Zencoder API call you can make. This will output an h.264 mp4 with AAC audio and
  // save it to Zencoder's temporary storage on S3.
  var request = {
    "input": fpfiles[0].url
  }
  // Let's use $.ajax instead of $.post so we can specify custom headers.
  $.ajax({
      url: 'https://app.zencoder.com/api/v2/jobs',
      type: 'POST',
      data: JSON.stringify(request),
      headers: { "Zencoder-Api-Key": zenKey },
      dataType: 'json',
      success: function(data) {
        $('body').append('Job created! <a href="https://app.zencoder.com/jobs/'+ data.id +'">View Job</a>')
      },
      error: function(data) {
        console.log(data);
      }
  });
});

ページを更新し、ビデオをアップロードしてください。すべてが計画通りに進んでいれば、新しく作成したジョブへのリンクとともに成功のメッセージが表示されるはずです。

わずか47行のコードで、ビデオをアップロードしてエンコードするためのウェブページが完成できます。

注意と警告

ZencoderのAPIキーをJavaScriptの中にプレーンテキストで記述するのはよくありません。もう一度言いますが、他の人がアクセスできる可能性のあるコードは使用しないでください。他の人がアクセスできる可能性のあるコードでこのキーを使用しないでください。

ここでのより良いアイデアは、説明したようにFilepickerを使用することですが、実際にはAPIキーが詮索されないように安全なバックエンドでZencoder APIコールを行うことです。

さらなるステップへ

ドラッグ&ドロップは本当に素晴らしいものなので、Filepickerの makeDropPaneユーザーは何か作業をする前にAPIキーを入力しなければなりません。 デモの依頼 はネットに載せても安全です。

このバージョンでは、APIキーの検証を行い、最近のZencoderジョブの履歴を含み、リクエスト・テンプレートを変更することができます。これらの設定はすべてブラウザのlocalStorageに保存されるので、更新時にすべてを失うことはありません。