グーグル・コンピュート・エンジンを使ったビデオのトランスコーディング

クラウド・コンピューティングの世界にいる我々にとって、2012年のGoogle I/Oで最もエキサイティングだったのは、スカイダイバーがグラスを着用することでも、新しいタブレットでもなかった。大きなニュースは、グーグルが現在アマゾン・ウェブ・サービス(AWS)が独占しているクラウド・インフラストラクチャ・アズ・ア・サービスの分野に参入するというものだった。具体的には、GoogleはAmazon EC2に対抗するため、Google Compute Engineと呼ばれる新しいサービスを開始した。

これはエキサイティングだ。世界はもう1つ、堅牢でパフォーマンスが高く、よく設計されたクラウド仮想マシンサービスを必要としている。Rackspaceなどには申し訳ないが、この分野は長い間EC2が独走してきた。Googleは明らかに専門知識と規模を持っており、彼らがそれに固執するならば、深刻な競争相手となるだろう。

どうですか?初期の報告はポジティブだ。Google Compute Engine(GCE)はよく設計され、よく実行され、グーグルが長年使ってきたインフラをベースにしている。パフォーマンスは良好で、特にディスクI/O、ブート時間、一貫性は、歴史的にEC2の得意分野ではなかった。しかし、GCEはクラウド・ビデオ・トランスコーディングにどの程度適しているのだろうか?より多くのテストが必要であることは認めつつ、いくつかの予備的な結果を得た。以下は、GCEとEC2の両方でZencoderソフトウェアを使用したビデオ・トランスコードとファイル転送の基本的なテストである。

生のトランスコード速度

パフォーマンスは私たちの最優先事項ですので、Zencoderは当社が見つけることができる最速のサーバーを使用しています。EC2では、2つのサイズの高速デュアルCPUマシンであるCluster Computeインスタンスを使用しています:4XLと8XLです。これらのインスタンスを、現在シングルCPUの8コア・サーバーである最速のGCEインスタンス・タイプと比較しました。

サーバーCPU
GCE 8コアインテル Xeon (Sandy Bridge - おそらく E5-2670) - 8コア @ 2.60GHz
EC2 cc1.4xラージデュアルIntel Xeon X5570 - 8コア@2.93GHz/コア
EC2 cc2.8xラージデュアルIntel Xeon E5-2670 - 16コア@2.60GHz/コア

これらのテストは、640×360および1280×720解像度のH.264ソースビデオを使用し、同じシングルパス出力トランスコード設定(H.264ベースラインプロファイル、AAC、ワンパス一定品質トランスコードなど)を使用してZencoderでエンコードした。

Google Compute EngineとAmazon EC2の比較

サーバー決議同時エンコード時間(秒)1,000人当たりのコスト
EC2 cc1.4xラージ640×360615.87$0.96
EC2 cc2.8xラージ640×36069.93$1.10
GCE 8コア640×360621.05$1.13
GCE 8コア640×36016.01$1.94
EC2 cc1.4xラージ640×36015.96$2.15
EC2 cc1.4xラージ1280×720648.58$2.92
EC2 cc2.8xラージ640×36014.99$3.33
EC2 cc2.8xラージ1280×720630.74$3.42
GCE 8コア1280×720668.15$3.66
EC2 cc1.4xラージ1280×720112.89$4.65
GCE 8コア1280×720116.01$5.16
EC2 cc2.8xラージ1280×720110.92$7.28

デフォルトのZencoder設定を使用すると、どちらのタイプのEC2インスタンスもGCEよりも高速である。経済性はもう少し近く、4XL EC2インスタンスとGCEの間に明確な勝者はいない。AWSの顧客は、リザーブドインスタンスやスポットインスタンスを利用することで、さらなるコスト削減を図ることができるが、GCEは、生の速度よりもコストを優先するトランスコードには有効な選択肢だ。16コアのEC2インスタンスは、GCEの8コアインスタンスに比べ、同時6トランスコードで負荷がかかった場合、およそ2倍高速であることがわかった。

同じようなクロック速度だが、コア数が半分であることを考えると、これは予想通りだ。しかし、グーグルが同様の16コアのマシンを追加すれば、同等のトランスコード速度になる可能性がある。

転送速度

クラウドでビデオをトランスコードする場合、ネットワークI/OはCPUと同じくらい重要です。これは、高ビットレートのコンテンツを扱う顧客(放送局、スタジオ、クリエイター)には特に当てはまる。では、GCEの転送速度はEC2と比較してどうだろうか。これをテストするため、4組のベンチマークを実行した:

  • アマゾンS3からアマゾンEC2へ
  • Amazon S3からGoogle Compute Engineへ
  • グーグル・クラウド・ストレージからアマゾンEC2へ
  • Google Cloud StorageからGoogle Compute Engineへ

Googleクラウドストレージ(GCS)とAmazon S3に保存された同じ1GBの動画ファイルをテストした。転送には10回のHTTP接続を使用した(Zencoderは転送速度を最適化するためにデフォルトでこのようにしており、HTTPでの大容量ファイル転送を劇的に高速化することができる)。

GCEとEC2の転送速度比較

 転送速度(Mbps)サーバー帯域幅
S3からGCEへ470.961 Gbps
S3からEC2へ c1.xlarge644.291 Gbps
S3からEC2へcc2.8xlarge1458.3210 Gbps
GCSからGCEへ202.601 Gbps
GCSからEC2へ c1.xlarge378.281 Gbps
GCSからEC2へcc2.8xlarge641.3410 Gbps

これは興味深い。アマゾンからアマゾンへの転送は速いと予想していた。しかし、GoogleからGoogleへの転送も速いと予想していたが、そうではなかった。実際、GCSはS3より遅く、GCEの転送はEC2より遅いようだ。たとえGoogleをコンピュート用に使っていても、ストレージにはS3を使った方がいいかもしれない。S3からGCEへの転送は、GCSからGCEへの転送よりも2.3倍速かった。

さらなる検査が必要

これらの結果は予備的なものである。より多くの変数を考慮したさらなるテストが必要である。

  • インスタンス間の差異。これは特にファイル転送に当てはまり、ネットワーク条件やインスタンスのばらつきによって大きく異なる可能性があります。
  • その他のアプリケーション。これらのベンチマークは、CPUに縛られるベンチマークであるトランスコーディングのみを対象としている。その他のアプリケーションは、ディスクやメモリーなどによって制限されるため、これらのテストはトランスコーディング以外のことには関係ない。
  • スケーラビリティ。スケーラビリティは、ビデオトランスコーディングにクラウドを使用する人にとって非常に重要である。数万台(またはそれ以上)のサーバーという巨大なスケールに関して、GCEがEC2と比較してどうなのかを確認するためには、さらなるテストが必要だ。ユーザーはどの時点で容量の問題に直面するのか?パフォーマンスの問題?設計の限界?不安定性?

クラウドインフラの未来

この初期のテストではEC2が勝っているが、我々はGoogle Compute Engineに期待している。高性能トランスコーディングの本格的な競争相手になるためには、グーグルはより高速なCPUを搭載したより大規模なインスタンスを追加する必要がある。しかし、新しいインスタンスタイプを追加するのは簡単だ。グーグルを妨げるものは何もない。難しいのは、堅牢で性能が高く、機能が完全でスケーラブルなクラウドプラットフォームを構築することであり、グーグルはそれに成功しているようだ。グーグルが長期的にこの製品と開発者にコミットするならば、クラウド仮想化の世界は2番目の正当なプレーヤーを得たことになるかもしれない。

ウェブ、モバイル、コネクテッドTVのためのクローズドキャプション

クローズド・キャプションは、アクセシビリティとユーザビリティにとって良いことであり、インターネット・ビデオが成熟に向かって前進するための、また新たなマイルストーンである。残念ながら、クローズド・キャプションは、単一の技術やビデオの「機能」として「オン」にできるものではありません。多くのフォーマット、標準、アプローチがある。

クローズドキャプションは、デジタルビデオの他の部分と同様、厄介なもので、マルチスクリーンパブリッシャーにとっては特に難しいものです。今日、ウェブ、モバイル、コネクテッドTV向けに動画を配信したい場合、クローズドキャプションについて何を知っておく必要があるでしょうか?

この記事では、クローズド・キャプションの仕組み、知っておくべきフォーマット、すべての画面でクローズド・キャプションを有効にする方法など、基本的なことを概説します。

クローズド・キャプションの仕組み

まず理解しなければならないのは、クローズド・キャプションがどのように配信され、保存され、読まれるかである。現在、主に2つのアプローチがある。

  • ビデオ内に埋め込む。CEA-608、CEA-708、DVB-T、DVB-S、WST。これらのキャプション・フォーマットは、データ・トラックとして、またはビデオ・ストリーム自体に埋め込まれて、ビデオ・ファイルに直接書き込まれる。放送テレビは、iOSと同様にこの方法を採用している。
  • 別ファイルとして保存。DFXP、SAMI、SMPTE-TT、TTML、EBU-TT(XML)、WebVTT、SRT(テキスト)、SCC、EBU-STL(バイナリ)。これらのフォーマットは、動画自体に埋め込まれるのではなく、動画と一緒にプレーヤーにキャプション情報を渡します。この方式は通常、ブラウザベースの動画再生で使用される。

字幕とクローズドキャプションの違い

字幕についてはどうですか?クローズド・キャプションと同じものなのでしょうか?主な違いは3つあります。

  • 目標クローズド・キャプションはアクセシビリティ機能のひとつで、耳の不自由な方でもビデオを視聴できるようにするものです。字幕は国際化機能であり、話し言葉を理解できない人々がビデオを利用できるようにします。言い換えれば、ミュートでビデオを見るには字幕を使い、理解できない言語のビデオを見るには字幕を使うということです。注:この区別は北米では通用しますが、世界の多くの国ではクローズド・キャプションと字幕を区別していません。

  • 保存。歴史的に、キャプションはビデオに埋め込まれ、字幕は外部に保存されてきました(下記のCEA-608を参照)。なぜなら、字幕は常にビデオとともに提供されるべきものであり、難聴者のための100%のアクセシビリティが法律で義務付けられているからです。ドイツで放送されるドイツ語のビデオにはドイツ語の字幕は必要ありませんが、フランスで放送される同じビデオには字幕が必要なのです。

  • 再生。キャプションはビデオと一緒に渡され、テレビやその他のコンシューマー機器によって解釈/表示されるため、視聴者はテレビ自体を使っていつでも自分でオン/オフを切り替えることができますが、言語を選択するオプションがあることはほとんどありません。このような状況で、翻訳目的で字幕が追加される場合、一般的にハード・サブタイトル(下記参照)であるため、無効にすることはできません。しかし、DVD/ブルーレイ/VODビデオを見る場合、字幕を表示するかどうか、またどの言語で表示するかは、再生機器がコントロールします。

フォーマットと規格

クローズドキャプションや字幕のフォーマットや規格は何十種類もあります。ここでは、インターネット動画で最も重要なものを紹介します。

  • CEA-608。ライン21とも呼ばれるCEA-608キャプションは、米国とカナダのアナログテレビで使用されているNTSC規格である。ライン21キャプションは、放送のプレイアウト機器によって、ビデオストリームの隠れた領域に直接エンコードされます。番組の上部に白いバーやドットが表示されているのを見たことがあれば、それがライン21キャプションです。
  • SCC。このファイルには、Scenarist Closed Captionフォーマットのキャプションが含まれています。CEA-608データの表現として、SMTPEタイムコードと対応するエンコードされたキャプションデータが含まれています。
  • CEA-708。これは、米国とカナダにおけるATSCデジタルテレビ(DTV)ストリームのクローズドキャプションの標準である。現在、ビデオストリームとは別にCEA-708キャプションを保存するための標準ファイル形式はありません。
  • TTML。Timed Text Markup Languageは、テキストとオーディオやビデオなどの他のメディアの同期を記述します。詳しくはW3C TTML勧告をご覧ください。
  • DFXP。これはW3Cによって定義されたTTMLのプロファイルです。DFXPファイルには、キャプションデータをいつ、どのように表示するかを定義したTTMLが含まれています。DFXPは、Distribution Format Exchange Profileの略です。DFXPとTTMLはしばしば同義語として使われます。
  • SMPTE-TT。Society of Motion Picture and Television Engineers - Timed Textは、DFXPプロファイルの拡張で、他のキャプションフォーマットや情報項目にはあるが、DFXPにはない3つの拡張子のサポートを追加したものである:#data、#image、#informationです。SMPTE-TTは、FCCセーフハーバーフォーマットでもあります。ビデオコンテンツ制作者がこのフォーマットで配信者にキャプションを提供すれば、アクセシブルなフォーマットでキャプションを提供する義務を果たしたことになります。ただし、ビデオコンテンツ制作者と配信事業者は、別のフォーマットで合意する自由があります。
  • SAMI。Synchronized Accessible Media InterchangeはHTMLをベースにしており、Microsoft Encarta EncyclopediaやWindows Media Playerなどの製品用にMicrosoft社によって開発された。SAMIは、多くのデスクトップビデオプレーヤーでサポートされています。
  • EBU-STL。これはEBU規格で使用されているバイナリ形式で、個別の.STLファイルに格納されている。
  • EBU-TT。これはEBUがサポートする新しいフォーマットで、TTMLに基づいている。EBU-TTはTTMLの厳密なサブセットであり、EBU-TT文書は有効なTTML文書であるが、一部のTTML文書はEBU-TTでサポートされていない機能を含むため、有効なEBU-TT文書ではない。
  • SRT。これは、動画から字幕やキャプションを抽出するためのWindowsベースのオープンソースツールであるSubRipによって作成されたフォーマットです。SRTは、デスクトップのビデオプレーヤーで広くサポートされています。
  • WebVTT。これはSRTに似たテキスト形式である。Web Hypertext Application Technology Working Group(WHATWG)は、HTML5ビデオ・クローズド・キャプションの標準としてWebVTTを提案している。
  • ハード字幕。ハードサブタイトルは定義上、クローズドキャプションではありません。ハードサブタイトルはビデオ自体にエンコードされたオーバーレイテキストであるため、クローズドキャプションやソフトサブタイトルとは異なり、オン/オフを切り替えることはできません。可能な限り、一般的にはソフト字幕またはクローズドキャプションが好まれますが、クローズドキャプションに対応していないデバイスやプレーヤーをターゲットにする場合は、ハード字幕が便利です。

あらゆるデバイスに対応するキャプション

どのようなフォーマットが、どのような機器やプレーヤーで使われているのか?

  • HTML5。キャプションはまだブラウザによって広くサポートされていませんが、時間の経過とともに変わっていくでしょう。競合する2つの標準があります:W3Cが提案したTTMLと、WHATWGが提案したWebVTTです。現時点では、ChromeはWebVTTを限定的にサポートしており、Safari、Firefox、OperaはすべてWebVTTのサポートに取り組んでいます。ブラウザがネイティブでフォーマットをサポートするまで、Video.jsのようなHTML5プレーヤ・フレームワークは、外部ファイルを解析することにより、Javascriptを介してキャプションをサポートすることができます(Video.jsは現在WebVTTキャプションをサポートしています)。
  • iOS。アップルは異なるアプローチを取っており、CEA-708/ATSCレガシーエンコーディングの修正版を使用してCEA-608キャプションを使用しています。つまり、HTML5 とは異なり、トランスコード時にキャプションを追加する必要があります。Brightcove Zencoder は、iOS 用 HTTP ライブ ストリーミング動画にキャプションを追加できます。
  • アンドロイド。ビデオプレーヤーのサポートはまだ断片的で問題がある。キャプションのサポートは、明らかにOSのバージョンと使用するプレーヤーに依存します。
  • その他のモバイル機器。クローズド・キャプションにまったく対応していないものもあり、ハード・サブタイトルが唯一の選択肢となる場合もあります。
  • Roku。外部SRTファイルによるキャプションをサポート。
  • その他のコネクテッドTVプラットフォーム。まだクローズドキャプションに対応していないものもある。しかし、すぐに対応するだろう。現在市場に出回っているすべてのテレビ、コンソール、ケーブルボックス、ブルーレイプレーヤーは、インターネットコンテンツのストリーミングを望んでおり、今後1年半の間に、クローズドキャプションは必須となるだろう。そのため、ソニー、サムスン、ヴィジオ、グーグルTVなどは、いずれキャプション・サポートをアプリケーション開発フレームワークの一部にすることになるだろう。残念ながら、どのようなフォーマットが使用されるかはまだ明らかではない。おそらく、今後何年にもわたって、さまざまなプラットフォームが互換性のないさまざまなフォーマットをサポートし続けるだろう。

クローズド・キャプションの要件

クローズド・キャプションの状況は時間とともに変化し、成熟していきますが、2012年現在、一般的なデバイスでクローズド・キャプションをサポートするための最も一般的な要件は以下のとおりです。

  • クローズドキャプションの有効・無効をプレーヤー側でコントロールできるウェブプレーヤー。
  • WebVTT、TTML、またはSRTのようなフォーマットを使用した、キャプションデータの外部ファイル。複数のファイルが必要な場合もあります(Roku用のSRTとHTML5用のWebVTTなど)。
  • Zencoderのように、iPad/iPhone配信用のHTTPライブストリーミングにクローズドキャプションを埋め込むことをサポートするトランスコーダ。Zencoderは、TTMLを含むさまざまな形式のキャプション情報を受け入れることができるため、パブリッシャーは1つのTTMLファイルをウェブ再生とiOSビデオ用Zencoderへの入力の両方に使用することができます。

それ以上は難しくなります。他のデバイスには他の入力フォーマットが必要になるかもしれないし、レガシーデバイス間で100%の互換性を保つには、おそらく焼き込みの字幕が必要になることでしょう。

Brightcove Zencoder とキャプション

Brightcove Zencoderは、2 つの形式のクローズド キャプションをサポートします:HLS を使用した iOS 機器用の CEA-608 スタイルのキャプションと、CEA-608 キャプション トラックを含む MP4 ファイルです。入力側では、MP4 ファイルの SCC、SAMI、DFXP/TTML/SMPTE-TT、および CEA-608 キャプション トラックをサポートします。

これらのフォーマットは、トランスコードの時点でビデオファイルに追加されるためです。そのため、iPadやiPhone向けのキャプションをサポートしていなければ、これらのデバイス向けにパブリッシングするお客様はクローズドキャプションを使用できません。将来的には、受け入れるキャプション形式の範囲を拡大し、外部キャプションファイルの形式変換(TTMLからWebVTTなど)などのサービスを提供する予定です。

一方、1 つのキャプション ファイルと適切な HTML5 プレーヤがあれば、ブライトコーブの顧客は、Web、モバイル、Connected TV 機器向けにキャプション付き動画を作成するために必要なすべてを手に入れることができます。

アプリクラウド:ウェブ開発者の体験レポート

ウェブ開発者兼デザイナーとして13年間、Javaから始まり、PHP、そしてRubyと、新しいテクノロジーに難なく適応してきました。長い間「Flashスチーマー」に没頭し、PrototypeやjQueryのような主要なUIライブラリを探求しながら、急速に進化するウェブ標準に対応してきました。

しかし、多くのウェブ開発者がそうであるように、私はモバイル・アプリケーションへの飛躍に乗り遅れた。C++やObjective-Cのような低レベル言語の経験がなく、それらを学ぶ時間もなかった。Javaで "小さな "アプリケーションを作るというアイデアも、私が嵩張り広範な言語だと感じたJavaも同様に魅力的ではなかった。

私はいくつかのクロスプラットフォーム開発ツールを検討したが、それらは一貫して期待を下回っていた:

  • RSSフィードをあらかじめ用意されたテンプレートで包むアプリ「ファクトリー」は、一般的でセンスのないアプリを生み出した。
  • JavaScriptやActionScriptをネイティブコードに変換するフレームワークでは、アプリの作成とコンパイルに複雑なツールチェーンが必要だった。
  • ウェブページをネイティブシェルでラップするフレームワークは、本番環境でデータ駆動型アプリをデプロイするためのインフラをほとんど提供していなかった。

HTML、CSS、JavaScript を使用してネイティブ モバイル アプリを作成するフレームワークである App Cloud を発見したとき、私は懐疑的でした。他のものと何か違うのだろうか?約束を果たせるのか?最初のアプリを開発した後、その答えは自信を持って「イエス!」と言えます。その理由はこうだ。

アプリクラウドは開発者の言葉を話す

App Cloud はウェブ開発者のコアスキルに依存しています:HTML でコンテンツを構造化し、CSS で形を整え、JavaScript で編集します。コンテンツ主導のリッチなアプリを作成するために新しい言語を学ぶ必要はありません。ウェブテクノロジーは常にシンプルであることに優れている。iOSでテーブル・ビューを作成する複雑さと、基本的なHTMLリストを作成する簡単さを比べてみてください!

App Cloud SDK はほぼすべての JavaScript ライブラリもサポートしており、長年のウェブ開発で習得したトリックを適用することができます。

アプリクラウドで高速レーンへ

私はコーディングの際、BBEdit と vim を頻繁に切り替えて使用しています。App Cloud では、これらの使い慣れたエディタを使い続けることができます。標準的なウェブ技術に依存しているので、Chrome Developer Tools でコードをデバッグしてテストすることもできます。XCode や Eclipse に縛られた煩雑なシステムとは異なり、App Cloud は柔軟性と自由を提供してくれます。

ワークショップアプリで迅速な反復作業

iOS および Android 用の App Cloud ワークショップ アプリは、開発中のリアルタイム テストを可能にします。コードを変更した後、"Refresh" をクリックするだけですぐに更新を確認できます。コード、更新、繰り返しという反復プロセスに慣れているウェブ開発者にとって、この機能は非常に貴重です。

多くのテストはデスクトップブラウザ上で行うことができますが、実際のデバイス上でアプリがどのように動作するかを確認することに勝るものはありません。ワークショップアプリはこれを簡単かつシームレスにします。

デバイス固有の機能の活用

App Cloud は、カメラやフォト ライブラリなど、デバイス固有の機能にアクセスするためのわかりやすい JavaScript API を提供します。たとえば、QR コードのスキャンは次のように簡単です:

bc.device.getQRCode(
function (data) { /* handle success */ },
function (error) { bc.device.alert("Oops! " + error.errorMessage); }
);

簡易アプリコンパイル

Android 開発者キットのような他のツールでアプリをコンパイルするのは、IKEA の家具を組み立てるように面倒でイライラすることがよくあります。App Cloud Studio を使えば、アプリはクラウド上で数回クリックするだけでコンパイルできます。特別なツールは必要なく、アプリは数分でダウンロードでき、さまざまなアプリストアにデプロイできます。

コンテンツの最適化:少ないことは多いことだ

コンテンツ主導のアプリケーションでは、コンテンツ自体がボトルネックになることがよくあります。App Cloud は以下の方法でパフォーマンスを最適化します:

  • 不要なデータの削除、フィードの圧縮、コンテンツのキャッシュ。例えば、私のブログのフィードは39KBから4KBに縮小された。
  • 画像をトランスコードしてファイルサイズを縮小。ある画像は、幅425ピクセルの125KBから、幅200ピクセルの8KBになり、94%の削減となった。

これらの最適化により、ユーザーのエンゲージメントに不可欠なロード時間が大幅に改善された。

配備を超えた柔軟性

他のツールとは異なり、App Cloud Studio では、アプリを再コンパイルまたは再配布する必要なく、デプロイ後にデータ、デザイン、設定を変更できます。この柔軟性により、データ フィードを交換したり設定を調整したりすることで、1 つのテンプレートから複数のアプリを作成できます。

コラボレーションを容易に

App Cloud を使用すると、同僚とアプリを簡単に共有できます。スクリーンショットをワークショップ アプリから直接共有したり、テンプレートを URL や QR コードで配布したりできるので、効率的なコラボレーションやテストが可能になります。

包括的なクラウド管理

App Cloud は、ネイティブ広告の配信からリアルタイムの分析まで、アプリケーションの管理と収益化に必要なすべてを提供してくれます。インストール、使用時間、その他の重要な指標を追跡できます。

さらに、App Cloud はパフォーマンスの向上と機能のアップデートを無料で提供します。プッシュ通知やアプリ内課金などの今後の改良により、このプラットフォームはさらに強力になります。

App Cloud はウェブ開発のシンプルさとネイティブ アプリの機能性を兼ね備えており、効率的でスケーラブル、かつ魅力的なモバイル アプリを作成したい開発者にとって不可欠なツールです。

完璧なIPAD/IPHONEビデオのためのエンコーディング設定

本格的な動画配信事業者であれば、すでにiPadとiPhoneをサポートしているか、サポートの追加を真剣に考える必要がある。一部の大手パブリッシャーにとって、iPad配信は動画視聴総数の3分の1以上に相当する。

しかし、iOS向けのエンコーディングは少し厄介だ。これらのデバイスは何世代も技術的な進歩を遂げており、iPhone 4の理想的なビデオ設定がiPhone 3GSやiPadの理想的な設定ではありません。

幸いなことに、いくつかのエンコーディング・プロファイルを使うだけで、初代iPhoneからiPad 2まで、あらゆるiOSデバイスに高品質のビデオをストリーミングすることができ、さらに将来の世代のモバイル・ハードウェアに備えることもできる。

一般設定

現在のほとんどのビデオと同様、iOSをターゲットにする場合はh.264ビデオとAACオーディオを使用する。

On the audio side, consider using HE-AAC at <64kbps, for App Store compliance. HE-AAC sounds reasonably good at these bitrates, even for complex audio.

ビデオ側では、各デバイスをターゲットに複数のプロファイルを使用します。iPhone 3GS以前はh.264のベースライン・プロファイル、レベル3.0のみをサポートしています(それよりも制約の多いバージョンをサポートしているものもあります)が、新しいデバイスはメイン・プロファイルとハイ・プロファイルをサポートしています。

最高のユーザー体験のためには、HTTPライブストリーミング(HLS)は必須です。アップルは、App Storeで10分以上のコンテンツを再生するビデオアプリにHLSを要求しており、iOSがサポートする唯一の真のストリーミングフォーマットである。HLSは、Android(バージョン3以上)、Roku、その他の様々な配信先でも採用されている。

一般的なアプローチ

決議プロフィールビットレート@ 16:9@ 4:3オーディオコメント
1024×768[email protected]2Mbps1024×5761024×76856kbps HE-AAC 
960×640[email protected]1.5Mbps960×540854×64056kbps HE-AAC 
640×432[email protected]1Mbps640×360576×43256kbps HE-AAC 
480×320[email protected]600kbps480×272426×32056kbps HE-AAC 
400×288[email protected]400kbps400×224384×28856kbps HE-AAC 
400×288[email protected]200kbps400×224384×28856kbps HE-AACフレームレートを低下させる
該当なし(オーディオのみ)    56kbps HE-AAC 

なぜ、このような提言なのか?

  • これらは単なる推奨事項だ。異なる解像度とビットレートは完全に有効であり、状況によっては実際に望ましい場合もある。例えば、非常に複雑なコンテンツは、より高いビットレートを保証するかもしれません。
  • iPad 1とiPhone 4では720pが最大で、iPad 2/iPhone 4Sでは1080pまで再生できる。しかし、ネイティブ・ディスプレイの幅は1024ピクセルしかないため、720pや1080pにすることは重要ではない。720pはフルスクリーンのウェブ再生に最適な解像度であり、1080pはコネクテッドTVに最適だ。将来のiPadは現行iPadの4倍の解像度になると噂されているので、将来を見据えて720pを追加することも検討しよう。
  • h.264プロファイルは重要だ。iPad 1とiPhone 4はどちらもMainプロファイルをサポートしている。iPad 2/iPhone 4SはHighプロファイルをサポートしており、Mainよりもわずかに優れていますが、iPad 1のデバイスの数を考えると、Mainプロファイルにこだわる方がよいでしょう。本当に最適なデバイスをターゲットにするには、MainとHighの両方にエンコードしてください。
  • これら6つの解像度とビットレートは、さまざまな帯域幅を適度にカバーしている。もっといろいろなことができるはずなので、必要に応じて解像度やプロファイルを足したり引いたりしてください。
  • レガシーiPhone/iPod Touchユーザーは、480×320の高画質ビデオ(これらのデバイスの画面解像度)を含む3つのストリームを利用できる。iPadとiPhone 4のユーザーは、6つのストリームすべてを利用できる。
  • iPadの解像度スケーラーはかなり優秀なので、リスケーリングされた動画は一般的にきれいに見える。
  • 可能な限り、これらの設定は16で割り切れる解像度の寸法を許容する。これにより、より効率的な圧縮が可能になります。特に高解像度では効率の向上は小さいが、低解像度では差が出始める。
  • 各ビデオでオーディオを同一に保つようにしてください。オーディオの仕様がバージョンによって異なる場合、ストリームを切り替えたときに再生中にポップ音やクリック音が聞こえることがあります。

その他の設定

  • 希望するターンアラウンドタイムに基づいて速度を設定します。ここでは、ベースラインより少し圧縮率が向上するものの、それなりに高速なスピード2を推奨する。
  • 各セグメントがほぼ同じサイズになるように、ピークを使用する。 bitrate\_cap ただし、目標ビットレートの150%以内でなければならない。 buffer\_size (例えば、5秒、または5倍)。 bitrate\_cap).
  • タイプを "分割" に設定すると、ブライトコーブは自動的に適切なキーフレーム配置を選択します。HLS に分割するために MP4 にエンコードする場合は、次のように設定します。 forced\_keyframe\_rate を "0.2 "または "0.1"(それぞれ5秒または10秒のキーフレーム間隔)に設定する。
  • 多少予測不可能なビットレートを受け入れることができるなら、ミックスにクオリティを加え、変更することができる。 video\_bitrate に max\_video\_bitrate でファイルサイズを最適化します。エンコーダーは必要に応じて最大ビットレートを使用し、より少ないビット数で望ましい品質を達成できる場合はより低いビットレートを使用する。
  • を設定する。 max\_frame\_rate を30に、そして max\_audio\_sample\_rate から48000まで。
  • iOSデバイスの第一世代では、h.264は1つしか使えません。 reference\_frameそのため、ベースライン・ストリームでは、互換性を最大にするためにこの機能を有効にする。

Brightcove Video Cloud と Google Analytics の統合

今回は、Googleアナリティクスを使って動画を計測できるGoogleアナリティクス連携プログラムをご紹介します。Google Analytics統合プログラムは、Video Cloudを契約しており、すでにGoogle Analyticsを導入している場合に使用できます。

オンラインビデオを使ってDIY VS.ソーシャル VS.OVP

ユーザーからの絶大な人気、感動を呼び起こす能力、優れたマーケティング機会、製品販売の大幅な後押し、さらには検索エンジンランキングの向上など、オンライン動画の多様な可能性を発見する企業が増えている。しかし、動画を効果的に活用するためのユニークな課題やハードルを見落としている企業も少なくありません。

首尾一貫したビデオコンセプトとプロが制作したクリップがあっても、ひとつの重大な疑問が残る:それは、ビデオを会社のウェブサイトにどのように組み込むかということです。主な選択肢は3つある。

1.DIYソリューション

最初の選択肢は、個人的なソリューションである。できれば)熟練した従業員がビデオをエンコードし、Flashプレーヤーをプログラムするか、自由に利用できるプレーヤーを設定し、ビデオをHTTPサーバーにアップロードし、ウェブサイトに統合する。

この方法は、再生回数が限られた少数の動画には有効かもしれませんが、より多くの動画や高いトラフィックを扱う場合には、すぐに実用的ではなくなります。このDIYソリューションは、無秩序で、エラーが起こりやすく、メンテナンスに手間がかかり、時間がかかります。

2.ソーシャル動画サイト

もうひとつは、YouTubeのようなソーシャル・ビデオ・サイトを利用する方法だ。これらのプラットフォームに動画をアップロードすることで、企業は自社のウェブサイトに動画を組み込むための埋め込みコードを受け取ることができる。これらのサイトでは、動画の利用状況について比較的しっかりとした統計を取ることができ、動画は企業のウェブサイトだけでなく、YouTubeの検索からも発見することができる。

しかし、この解決策には大きな欠点がある。YouTubeに動画をアップロードすることで、企業は部分的に権利を放棄し、YouTubeが動画を販売できるようになる。さらに、ユーチューブは動画の外観や技術仕様を管理するため、企業はユーチューブの決定に依存することになる。このシナリオでは、企業はユーチューブにコントロールを委ね、どのような変更や制限も受け入れなければならない。

3.オンライン・ビデオ・プラットフォーム(OVPS)

そこで、3 番目の、最もプロフェッショナルなオプションとして Brightcove が登場します。OVP は、DIY ソリューションのカスタマイズとソーシャル動画サイトの技術的機能を組み合わせると同時に、法的なセキュリティと完全な制御を提供します。

もちろん、OVPには投資が必要だが、企業が日常的に使用している他の専門的なツールやシステムと何ら変わりはない。比較的少額の費用で、顧客は包括的でメンテナンスが行き届き、継続的に改善されるシステムを利用することができます。

OVPSの主な利点

  • 信頼性の高い配信:動画はコンテンツ・デリバリー・ネットワーク(CDN)を介して配信されるため、企業のサーバーに負担をかけることなくパフォーマンスを確保できます。
  • 詳細な分析:OVPは動画視聴に関する詳細な統計を提供するため、企業は効果を測定し、将来の制作のための洞察を得ることができる。
  • 完全なコントロール:動画は、広告サーバーや広告ネットワークに接続することで収益化を統合することができる。
  • ワークフローの最適化:OVPは技術的なタスクとリスクを最小限に抑え、ビデオ制作と配信のプロセスを合理化します。

オンライン・ビデオ・プラットフォームは、プロフェッショナルなビデオ利用のために特別に設計されています。これにより、企業はワークフローを最適化し、技術的な課題を軽減し、インターネット上で動画を効果的、安全かつコスト効率よく使用することができます。OVPに投資することで、企業はオンライン動画の可能性を最大限に引き出すことができ、同時に完全なコントロールを維持し、長期的な成功を確実にすることができます。

エンコードと高品質ビデオ再生のための10のヒント

コミュニティとナレッジチームは、皆様がどのようなトピックを検索し、どのような質問をしているのかを知るために、サポートサイトでの検索傾向、カスタマーサポートチームへの数多くのお問い合わせ、そしてフォーラムを調査しました。その結果、エンコーディングのベストプラクティスや高画質ビデオ再生のヒントに関する質問がトレンドのひとつであることがわかりました。

エンコードは非常に幅広いトピックですが、Brightcove に動画をアップロードするためにエンコードする際の注意点トップ 10 をまとめました。

1.幅広いデバイスをサポートするエンコード

幅広いデバイスを確実にサポートするために、動画を h.264 にエンコードすることをお勧めします。h.264 動画をアップロードすると、ブライトコーブ コンテンツをカスタマイズする方法が増え、他の多くのエンコーディングよりも高画質かつ低帯域幅で配信されます。

H.264は、モバイル動画配信に最適なオプションを提供し、当社のHTML5スマートプレーヤで再生できる唯一のフォーマットであるため、幅広いデバイスのサポートが可能です。スマート プレーヤは、視聴者のデバイス機能に応じて、Flash または HTML5 で動画を配信します。これにより、Flash または HTML5 で動画を配信できる 1 つの Brightcove プレーヤを使用することができ、視聴者環境ごとにプレーヤを作成および管理する必要がなくなります。

2.マルチビットレート・ストリーミングを使用する

帯域幅やインターネット接続に大きな差がある世界中のさまざまな視聴者があなたのビデオを視聴する場合、マルチビットレート・ストリーミングの使用は必須です。

帯域幅の広い視聴者には、高画質(あなたのソースである可能性もあります)の動画が自動的に配信されます。帯域幅の狭い視聴者は、長いバッファリング時間を我慢する必要はなく、代わりに少し低画質のビデオを即座に見ることができます。

一方、例えばインターネット接続が非常に強力な社内ネットワークで動画を厳密に視聴するのであれば、単純に高画質の動画を1本だけアップロードするのがよいでしょう。

3.ソースファイルをレンディションとして保存する

ソース動画ファイルが h.264 形式の場合、利用可能なレンディションとして元のソース ファイルを保持することができます。このオプションを使用すると、ブライトコーブの最高品質のレンディションよりもさらに高品質な h.264 マスターを保持できます。

さらに、このオプションを選択すると、h.264 ソース動画はアップロードが完了するとすぐに利用できるようになり、Media モジュールやプレーヤーで利用できるようになるまで、動画がトランスコードされるのを待つ必要がなくなります。

4.一定のフレームレートでビデオをキャプチャする

再生時のスタッターを避けるため、ビデオは毎秒25~30コマの一定フレームレートで記録し、フィルムは毎秒約24コマの一定フレームレートで撮影する。

5.アップロードするコンテンツを考える

事実やニュースタイプのビデオは、アクション満載の長編ビデオや魅力的なネイチャー・フィルムに比べ、一般的にクオリティが低い。

時々スライドが変わるだけで、ほとんど動きのないスクリーンキャストビデオを作成する場合は、録画と同じアスペクト比でh.264でビデオをエクスポートし、プレーヤーを設定するためにこれらのテクニックのいくつかを使用するようにしてください。

ワンパスエンコードとツーパスエンコードの比較

一般的に、2パスは1パスよりも優れたトランスコードを生成する。しかし、2パスエンコードを実行するには、より多くの時間がかかります。動きの多い動画の場合は、余分な時間をかけて2パスで書き出すことをお勧めします。また、比較テストを行って、顕著な違いがあるかどうかを判断し、トランジションや動きの多い部分に注意してください。顕著な違いが見られない場合は、ワンパスにこだわり、時間を節約してください。

6.最高品質のソースファイルをアップロードする

ブライトコーブは確かにソース ファイルの品質を保持し、複数の異なるレベルのレンディションを作成できますが、提供されたソース ファイルよりも高品質なレンディションを作成することはできません。Brightcove アカウントにアップロードする最高品質のソース ファイルを作成するのに役立つ、ソース ファイルの推奨リストとエクスポート設定があります。

7.オーディオ品質を無視しない

ほとんどの人は、動画の画質をできるだけ高くすることに集中し、音声は完全に無視しています。しかし、ビデオの視聴者は、ビデオの画質が少し低い場合よりも、オーディオの画質が落ちたり、途切れ途切れになったりすると、視聴をやめてしまう可能性が高くなります。

ほとんどの場合、ユーザーがビデオの中で何を言っているのか聞き取れなければ、見続ける意味はありません。ビデオを録画する際は、必ず良いマイクを使い、私たちの推奨するサウンド設定を考慮してください。

オーディオ設定のベストプラクティス

  • コーデック。h.264ビデオをエンコードする場合は、"AAC "を選択します。
  • サンプルレート。迷ったら44.1 kHzか48 kHzを選ぶ。
  • ビットレート。128~160kbps、オーディオが多いコンテンツには192kbps以上を使用する。

8.アナログビデオのインターレース解除

テープで撮影されたコンテンツを扱う場合、Brightcove コンテンツへのインターレース効果を避けるため、エクスポート時に [ソース動画のインターレース解除] チェックボックスを選択することを強くお勧めします。コンテンツがデジタル形式で撮影され、現在インターレースされていない場合は、インターレース解除の必要はありません。

9.トランスコード設定を変更する

プロフェッショナル版またはエンタープライズ版のアカウントをお持ちの場合は、ブライトコーブ スタジオで直接トランスコード設定を変更できます。デフォルトでは、トランスコード プロファイルで 6 つのレンディションを使用できます。ただし、動画をさまざまなデバイスや接続速度で視聴する顧客が特に多い場合は、レンディションを追加できます(最大 10)。ブライトコーブのデフォルトのトランスコード設定は、ほとんどのパブリッシャと視聴者のニーズを満たす、レンディションの優れた基本セットを提供します。

10.ビデオスムージングを許可する

Brightcove プレーヤは、動画スムージングを使用して動画再生の知覚品質を向上させることができます。ただし、動画スムージングを使用することで得られるかもしれない追加品質と、動画スムージングがクライアントに課す追加の CPU 負荷との間には、トレードオフがあります。

ビデオのビットレートが高くなると、ビデオスムージングの利点は目立たなくなります。視聴者、特に性能の低いコンピュータを使用している視聴者は、フレームドロップのために、より途切れ途切れのビデオ品質を知覚する可能性があり、これはビデオスムージングの利点を上回る可能性があります。

デフォルトでは、Brightcove は、ビット レートが 950 kbps 未満の動画に動画スムージングを使用し、ビット レートが 950 kbps 以上の動画には動画スムージングを使用しません。

オプションの videoSmoothing プレーヤのパブリッシング コードで設定パラメータを指定し、「true」(ビデオ スムージングを常に使用)または「false」(ビデオ スムージングを使用しない)のいずれかに設定します。

高品質のHDビデオ配信のためのエンコーディング設定

Brightcove を使用すると、パブリッシャは HD コンテンツを Web にストリーミングできます。しかし、ブライトコーブの高品質ストリーミング機能を利用するには、ソース ファイルを正しくエンコードする必要があります。4:2:2プルダウン」が外国語のように聞こえる人にとって、真の高解像度動画ストリーミングの配信方法について簡単な説明があると便利です。

ステップ1:仕組みを知る

ブライトコーブは、マルチビットレート ストリーミング テクノロジーを使用して、視聴者のインターネット速度が処理できる最高の動画品質を提供します。つまり、超高速の T3 オフィス回線から時々不安定な 3G モバイル接続まで、さまざまなインターネット接続に対応するために、さまざまな解像度とビットレートで最大 6 つのレンディションを作成します。当社のビデオプレーヤーは、視聴者のインターネット速度を検出し、適切なレンディションのビデオを提供します。

Brightcove のデフォルト設定を使用する場合は、手持ちの最高解像度とビットレートでファイルをアップロードします。デフォルト設定は、現在使用されているほぼすべての動画コーデックとコンテナをサポートし、最高品質のレンディションは、約 1.8 Mbps で 1280×960(16:9 フォーマットの場合は 1280×720)です。とはいえ、いくつかの特別な手順を踏めば、Brightcove を通じて真の HD 動画コンテンツを配信することができます。

ステップ2:H.264でアップロードし、ソースファイルをレンディションとして保存する

ブライトコーブのトランスコード処理では、最高画質は 1280×960 で 1.8 Mbps に制限されているため、ブライトコーブから最高画質を引き出すには、トランスコードを必要とせずにプレーヤで配信できる形式で動画をアップロードすることが重要です。このフォーマットが h.264 です。

H.264 動画は、PC、iOS 機器、Android 機器で再生できます。デバイスやオペレーティング システム間で幅広い互換性があるため、ブライトコーブが推奨する動画形式です。そのため、Brightcove では、H.264 ソースを保存し、動画の利用可能なレンディション リストに追加するオプションを提供しています。最終的な結果は、Brightcove の 6 つのデフォルト レンディションと、マシンでエンコードしたままのソース ファイルです。

ステップ3:ソースファイルをウェブフレンドリーなHDでエンコードする

Brightcove 用に動画をエンコードする際に考慮すべき点は、品質と再生アクセシビリティです。10 Mbps の動画をストリーミングするのに十分なインターネット速度を持つエンド ユーザーがほとんどいない場合、10 Mbps のソース レンディションを含める理由はありません。同様に、2 Mbps のソース ファイルは、ブライトコーブの 1.8 Mbps のレンディションとほとんど区別がつきません。

1920×1080の動画コンテンツを鮮明に表示するには、非常に高いビットレート(6-8Mbps以上)が必要なので、動画は1280×960か1280×720の解像度にこだわるのがベストです。35インチより小さい画面では、ほとんどの視聴者は違いがわからないでしょう。

最後に、エンコードのビットレートを決める必要があります。3~6Mbpsのビットレートをお勧めします。この範囲のどちら側に傾くかは、より高いアクセシビリティのために品質を少し犠牲にするか、あるいはその逆かによって決まります。ただ、これだけは覚えておいてください:視聴者がソースのレンディションを表示するのに十分な強力なインターネット接続を持っていなくても、それは世界の終わりではありません。ブライトコーブは、エンコーディング エンジンが作成した低レンディションのいずれかを視聴者に提供できます。

ビデオをモバイル用にエンコードする方法

世の中には何百というモバイル・デバイスがあり、そのすべてに対応することは基本的に不可能です。しかし、良いニュースもあります。

最近のスマートフォンは実際に高画質のビデオを再生することがでるため、スマートフォンの利用は増えています。3GPが終わったとか、誰もがスマートフォンを持っていると言っているわけではありません。しかし、スマートフォンの利用は増加しており、驚くことではないが、スマートフォンユーザーは携帯電話でビデオを見る傾向が強いです。

つまり、90%以上のモバイルデバイスをサポートしたいのであれば、少なくとも2つのビデオタイプが必要です:洗練されていないデバイスには3GP + MPEG-4、スマートフォンにはh.264 + MP4を使います。これは良い傾向で、1つの出力ビデオで、iPhone/iPad/iPod、Android、(ほとんどの場合)Blackberryなど、すべてのスマートフォンユーザーをカバーできます。PSP、PS3、Xbox 360を含めることもできます。

もちろん、1つのユニバーサル・スマートフォン出力でほとんどのスマートフォンユーザーに対応できますが、複数のモバイル出力があればもっと良いことができます。例えば、iPadのネイティブ解像度は1024×768で、以前のiPhoneの480×320の5倍です。そのため、480×320でビデオをエンコードすると、iPadの高解像度機能を無駄にしてしまうことになります。

幸いなことに、わずかな標準的なエンコード・プロファイルを使って、モバイルデバイスをうまくターゲットにすることができます。幅広い互換性のためにUniversal Smartphone Profileから始めてみましょう。次に、より高度なデバイスのためのAdvanced Smartphone Profileバージョンを追加し、最も幅広い互換性のためのレガシープロファイル(下記のLegacy Smartphone Profile、またはさらに幅広い互換性のための3GPビデオのいずれか)でモバイルリストを完成させます。

以下のデフォルトのプロファイルは、最初に使用することを推奨している設定になります。Brightcove Zencoderはデフォルトでこれらの設定を使用しますが、他のいかなるエンコード ツールでも簡単に再現できます。

デフォルト

  • ビデオ:h.264、レベル3.0
  • Baseline Profile Audio : AAC、1-2チャンネル

1.ユニバーサル・スマートフォン・プロファイル

これは、最新のスマートフォンとの幅広い互換性のための素晴らしいスタートプロファイルです。最新のデバイスで可能な高解像度と複雑なコーデックは利用できませんが、ほぼすべてのデバイスで再生できます。

再生可能

  • iOS:iPhone、iPad、Apple TV、iPod Touch、iPod Classic、iPod 5.5G
  • Blackberry:Bold 9000、Curve 8910、8900、8520、Peral 9XXX、Storm、Storm2、Torch、Tour、Bold 9650 + 9700
  • Android すべて
  • その他PSP(3.30+)、PS3、Xbox 360、Web

再生不可

  • iPod 5G
  • PSP (3.30以前)
  • Blackberry Curve 9330、9300、8530、83XX
  • Pearl 8XXX, 88XX

設定

デフォルト設定(と追加設定):

  • オーディオビットレート128(またはそれ以下)
  • オーディオのサンプルレート44100(またはそれ以下)
  • サイズ480×320
  • 最大フレームレート30
  • ビデオビットレート1500(またはそれ以下)

1b.ユニバーサル・スマートフォン・プロファイルB:高解像度

このプロファイルは、ビデオの解像度を上げることで、iPhone 4G、iPad、Apple TV、新しいiPod Touch、Droid、PS3、Xboxでよりよく再生されます。しかし、古いiPhoneではピクセルを増やしても無駄になり、
Blackberryや一部のAndroid携帯では再生できないビデオになります。

再生可能

上記のすべてから、Blackberryと、おそらく一部のAndroid端末を除いたものです。

設定

ユニバーサル・スマートフォン・プロファイル(上記)プラス :

  • サイズ640×480

2.高度なスマートフォンプロファイル

新しいiOSデバイスは、より高い解像度と、より複雑なエンコード(より良い圧縮を意味する)を可能にします。特に、iPadやApple TVのユーザーは、その美しい画面で480×320のビデオを見る必要はないはずなので、これらのユーザーに良い体験を提供したいのであれば、より高品質のバージョンを提供することは理にかなっています。

再生可能

  • iOS:iPhone 4G、iPad、Apple TV*、新しいiPod Touch
  • アンドロイドNexus One、Droid、その他(注:720pビデオで問題が発生するとの報告もある)
  • その他 : PS3、ウェブ

再生不可

  • iOS:iPod5G/5.5G/Classic、iPhone 3GS以前、旧型iPod Touch PSP、旧型Apple TV*。
  • Blackberry:すべて
  • Android:その他
  • その他 :PSP、PS3、Xbox 360、ウェブ

設定

デフォルト設定(と追加設定):

  • H264_profile: Main
  • H264_レベル3.1
  • オーディオビットレート160(またはそれ以下)
  • オーディオ・サンプル・レート48000
  • サイズ1280×720(最大)または960×640(iPhone 4ネイティブ)
  • 最大フレームレート30
  • ビデオビットレート5000(またはそれ以下)

*2b.アドバンスド・スマートフォン・プロファイル B:旧Apple TV対応

古いApple TVデバイスをサポートするには、Advanced Smartphone Profile設定に加え、以下のいずれかを使用します。

設定

アドバンスド・スマートフォン・プロファイル(上記)に加え、以下のいずれかを選択:

  • サイズ:960×540
  • 最大フレームレート24

3.レガシースマートフォンプロファイル

このプロファイルは、H.264ベースのモバイルデバイスの最後の主要なセット、特に古いiPodと一部のBlackberry機種で利用されます。こちらの機種では、ビデオは320×240、768kbps以下でかなり小さいサイズになります。

再生可能

上記のすべて、プラス:

  • iPod 5G、PSP(3.30以前)
  • Blackberry Curve 9330、9300、8530、83XX
  • Pearl 8XXX, 88XX

設定

デフォルト設定(と追加設定):

  • オーディオビットレート128(またはそれ以下)
  • オーディオのサンプルレート44100(またはそれ以下)
  • サイズ:320×240
  • 最大フレームレート30
  • ビデオビットレート768(またはそれ以下)
  • H264_level:1.3

4.レガシー3GPプロファイルAおよびB

最後に、1つか2つの3GPプロファイルは、残りの多くのモバイルデバイスへのサポートを拡張します。特に、レガシー・スマートフォン・プロファイルでは、上記でサポートされているのと同じデバイスのほとんどで使用できます。そのため、3GPビデオを320×240でエンコードする場合、別のH.264ビデオを320×240でエンコードする必要はないかもしれません。Zencoderでは、3GPビデオのサポートはまだベータ版であることに注意してください。最後に、これらのビデオのクオリティは悪く見えてしまいますが、それは3GP携帯電話をサポートするためのコストであることに注意してください。

再生可能

難しいですね。3GPデバイスは何千種類もあり、それぞれ少しずつ違います。これらを出発点として考えてみてください。

 プロフィールAプロフィールB
フォーマット3gp3gp
ビデオコーデックmpeg4mpeg4
サイズ320×240176×144
アスペクトモードPadPad
フレームレート155
アップスケールtruetrue
ビデオビットレート19252
ビットレート・キャップ19258
バッファサイズ該当なし16
オーディオ・ビットレート2416
オーディオ・チャンネル11
オーディオ・サンプル・レート1600016000

概要

モバイルビデオを作成したい場合は、Universal Smartphone Profileの使用から始めてください。より良い品質を求めるなら、Advanced Smartphone Profileのビデオでこれを補います。より幅広い互換性を求めるなら、MP4または3GPを使ってレガシー・プロファイルを1つか2つ追加します。1~3個のプロファイルを追加するだけで、ほとんどのモバイルデバイスに対応できます。

編集

古いiPhone/iPodデバイスは「H.264 Baseline Low Complexity 」プロファイルを要求します。「Low Complexity」はH.264の標準ではなく、実際には "1参照フレームのみ "を意味します。Appleのデバイスが本当にこれを強制しているかはまだ分かりませんが、真の互換性のためには、おそらくBaselineプロファイルを使用し、参照フレームを1に制限する必要があります。 h264_reference_frames 設定:

2010年11月23日(追記):Palm Preのビデオについて何人かの方から質問がありました。Palm Preの公表されているスペックは、他のスマートフォンと非常によく似ています:

  • 480×320のネイティブ解像度(640×480に対応)
  • H.264、H.263、またはMPEG-4ビデオ
  • MP3およびAACオーディオ(他のいくつかのコーデックも含む)

これらのスペックが正確で包括的であれば、上記のユニバーサルとレガシーのプロファイルはPalm Preで動作するはずです。

2011年1月24日(追記): 3GPビデオをRTMPストリームとして配信するには、"hinted"の追加が必要です。 "hint": 1 をAPIリクエストに追加して有効にしてください。