動画の共有のベスト プラクティス

多くのユーザーは Android デバイスで動画を共有しています。受信したメッセージの品質は 行われた処理が原因で、多くの場合、元の動画よりも劣ります できません。このドキュメントでは、Google Cloud で 共有動画と、動画処理におけるよくある問題をいくつか紹介します。最適化 HDR 動画コンテンツの共有について詳しくは、 このページの Transformer モジュールを使用して HDR を SDR にコード変換するをご覧ください。

必要なのは、解像度を一定に保ち、動画の品質を維持することです 動画を共有するときは、できるだけ高く設定しましょう。

共有パイプライン

図 1 は、動画を共有する一般的なフローを示しています。

動画パイプラインの共有 図 1. 動画共有パイプライン。

このパイプラインには次のステップがあります。

  1. 動画のキャプチャとエンコードを行い、キャプチャ中にエフェクトを追加する。 この手順をスキップして、ストレージから動画を選択することもできます。 別のアプリで録画した動画などです
  2. 動画の編集、フィルタ、レタッチなどの処理を行います。
  3. コード変換の準備として、動画を拡大縮小またはサイズ変更します。
  4. 共有用に動画をコード変換する。多くの場合、ステップ 2 のフィルタリングは、 行います。

パイプラインには 2 つのステップがあり 動画の品質を決定するパラメータがあります。初期値のエンコード コーディングする必要があります。また、必要に応じて 最後のコード変換ステップの前に動画のサイズを変更します。これは品質にも影響する場合があります。

推奨事項

表 1 は、動画品質に関する 5 つの主要パラメータを示しています。 使用できるステップを示します。

パラメータ キャプチャ 共有
プロフィール Y Y
解像度 Y Y
ビットレート Y Y
量子化パラメータ（QP） （まれに） Y
B フレーム × Y

表 1. 動画の品質を決定する主なパラメータ

プロフィール

より適切な結果を得るには、各モジュールで提供されているより高度なプロファイルを あります。AVC エンコードの場合は、ハイ プロファイル、レベル 4 を選択します。

解像度、切り抜き、スケーリング

スケーリング ステップでキャプチャした動画の初期解像度を変更できます 認識する必要がありますが、スケーリングによってコードの品質が 動画をご覧ください。スケーリングを避け、初期解像度の解像度を選択することをおすすめします。 パイプライン全体で使用できますまた、非常に高度な 特に切り抜き範囲をアップスケールした場合、トリミングすると画像が低画質になる 説明します。次のガイドラインに沿って対応してください。

  • 最終的な共有解像度以上の解像度を選択します。

  • キャプチャ解像度が共有解像度を大幅に超えないようにしてください ただし、すべての中間ステップが、より大規模な 解像度を上げることができます（初期キャプチャ時のビットレートが高いなど）。

    • 共有エンコードで解像度が 720x1280 になる場合は、 720x1280 のキャプチャ解像度。
    • キャプチャと共有の間の中間ステップに切り抜きが含まれる場合は、 解像度を上げて 1080x1920 など、高い解像度に キャプチャしてビットレートを調整し 余分なピクセルを処理します

  • 過度な切り抜きは、特に切り抜かれた場合に画質が低下する 画像が拡大されます。

  • 低解像度から高解像度にアップスケーリングしないようにします。アップスケーリングの試行 ここには存在しない詳細情報が作成されます希望する高解像度を使用する 見ていきましょう

  • アップスケールする必要がある場合は、エンコード パラメータを調整します。たとえば、 ピクセル数が 2 倍、ビットレートが 2 倍です

解像度とビットレートは相互に関連しています。たとえば、高解像度の高解像度画像 最終的に低ビットレートにコード変換する 共有パイプラインに動画が送信されます 低解像度から始めるよりも低画質の画像が生成されます。 ビットレートが低下すると、解像度が下がるポイントが交差します。 次のような方法があります。

ビットレート 解像度
5 Mbps 以上 1,080 x 1,920
1.5 ～ 5 Mbps 720×1280
1.5 Mbps 以下 SD と同等。アスペクト比 9:16 の同じピクセル数は約 416x736 です。

表 2. ビットレートと解像度

多くの人気アプリでは 720p 以下の解像度で動画が共有されています。このデータは、 解像度 720p が、1.5 ～ 1.5 のビットレート ターゲットに対して適切な選択であることを確認しました。 5 Mbps です

ビットレート

記録

エンコードのビットレートを高くすると、動画が大幅に改善されます。 向上しますネイティブのカメラアプリと一致するビットレートを選択することをおすすめします。1 つの 解像度は 720x1280 ですが、キャプチャのビットレートは 10 Mbps を推奨します。

キャプチャ エンコードはデバイス上で行われるため、より高いビットレートを使用して、 ほぼすべての共有ステップの変換を補正し、 あります。サイズの大きいファイルはデバイス上の操作にのみ使用されます。

表 2 に示すように、最後のコード変換ステップでビットレートを下げることができます。

共有

ビットレートは、共有時に最も大きな影響を与えます。 アップロードする動画のサイズを指定します。動画と動画にはトレードオフの関係がある クラウドストレージの費用です

エンコード プロファイル、B フレーム、QP 境界値の選択も、 撮影時よりもこの段階で重要になります

画質を高くするために、ビットレートは 4 ～ 5 Mbps（解像度 720x1280）を推奨します。 画質の改善に役立ちます。

量子化パラメータ（QP）

Android 12 以降では、QP キーは標準化されており、 MediaFormat API と NDK メディア ライブラリ。 それより前のバージョンの Android では、QP 操作はフレームワークからのみ利用できます。 MediaFormat 構成でベンダー固有のキーを使用して関数を呼び出す。

記録

動画のキャプチャ中は、QP 設定ではなくビットレート制御を使用します。 常に利用できるとは限りません。

キャプチャ ビットレートが 10 Mbps の QP 設定の調整はおすすめしません （720x1280 用）。キャプチャのビットレートが大幅に低い場合は、 720x1280（QP 設定を 40）にすると、画質と画質のバランスが コーデックがターゲット ビットレートを頻繁にオーバーシュートすることなく、

共有

特にビットレートが 4 Mbps 未満の場合は、最大 QP を 40 に設定することをおすすめします。 これにより、エンコードされた動画の品質は最低限に抑えられますが、 ビットレートは高くなりますビットレートの増加は、 説明します。共有アプリは多少の誤差は許容されますが、 最大ビットレートであるため、100 秒を超える値は許容されない 特定のしきい値を超えた場合に

他のユーザーと共有するために動画を再エンコードすることで、ビットレートの引き上げを制限できます。 制限が緩やかな（高い）最大 QP 境界。これにより、コーデックの自由度が増し、 画質を犠牲にし、動画の他の部分は残します。元の画像を再エンコードして コード変換オペレーションであるため、共有可能な動画すでに 編集する必要があります。

この方法の欠点は、コード変換ステップを別々のコードで 動画の共有に要する時間が長くなります。この問題を軽減する方法の一つは、 このレイテンシは、部分的にコード変換された動画を確認し、 ビットレートの超過を許容する範囲内でそうでない場合は、 より適切な QP パラメータでもう一度お試しください。

B フレームとエンコード プロファイル

B フレームは、共有ステップでのみ、かつ実行中の場合にのみ使用することを検討する Android 10 以降。

アプリは、サポートされているエンコード プロファイルを CodecCapabilities すべてのデバイスがメイン プロファイルまたはハイ プロファイルをサポートしているわけではないためです。一番高いプロファイルを使用する AVC エンコーダが対応しているかどうか: 高 >メイン >ベースライン。最も安全な結果を得るために、 B フレームを設定する （KEY_LATENCY または KEY_MAX_B_FRAMES) ベースラインを使用する場合、 エンコーダの設定に失敗するエンコーダもあります。

次のコード セグメントでは、VM に 'MediaFormat format'、 AVC エンコーダを設定する

Android 10

API 29 以降

サポートされている最も高いプロファイルを使用し、B-frame パラメータを 1 に設定します。

format.setInt32(KEY_PROFILE, AVCProfileHigh);
format.setInt32(KEY_MAX_B_FRAMES, 1);

この場合、KEY_LATENCY を設定しないでください。

Android 8、8.1、9

API 26、27、28

サポートされている最も高いプロファイルを使用しますが、B フレームの生成を無効にします。この いくつかの制限に MediaMuxer（これらのシステム バージョンの場合）

format.setInt32(KEY_PROFILE, AVCProfileHigh);
format.setInt32(KEY_LATENCY, 1);

KEY_LATENCY 値により、コーデックは B フレームを生成できなくなりますが、 他のコーデックの効率を利用します。

アプリで MediaMuxer を使用して最終的な出力ファイルをアセンブルしない場合は、 KEY_LATENCY の値を 1 ではなく 2 に設定して B フレームを有効にします。これにより、 B フレームを生成できます。

Android 7.1 以前

API 25 以前

最も安全な結果を得るには、ベースライン プロファイルを使用します。

format.setInt32(KEY_PROFILE, AVCProfileBaseline);

バージョン 7 より前の Android AOSP では、ベースライン プロファイルのみがサポートされます。ただし、 OEM が一部のデバイスでメイン/ハイ プロファイルを、おそらく ベンダー固有のプロファイルを指定します

アプリで MediaMuxer を使用しない場合は、次の場合にメイン プロファイルまたはハイ プロファイルを使用できます。 コーデックがサポートしているかどうかを確認します。B の数を制御するための公開フォーマット キーがない 使用できます。

Transformer モジュールを使用して HDR を SDR にコード変換する

Android 13（API レベル 33）以降では、Jetpack Media3 の Transformer 共有されていないアプリ、サービス、デバイスとは、HDR コンテンツを HDR に対応する必要がありますTransformer モジュールは、エンコーダの HDR 動画ストリームを SDR に入力し、結果を MP4 として保存することで、 画質の低下や画像の明るさを損なわずに正常に再生できる

注: Android 12（API レベル 32）以前のシステム バージョンをターゲットとするデバイスの場合 Android 7.0（API レベル 24）まででは、Transformer モジュールの動作が異なります。条件 デバイスが HDR をサポートしている場合、アプリでトーン マッピングなしでコンテンツが再生されます。 デバイスが HDR をサポートしていない場合は、HDR がサポートされていることを示すエラーがスローされます。 トーン マッピングはサポートされていません。

次のコードは、入力を SDR にトーンマッピングし、 入力形式（H.264/AVC など）に再エンコードします。

Kotlin

val transformer = Transformer.Builder(context)
    .setTransformationRequest(
        TransformationRequest.Builder()
            .setHdrMode(TransformationRequest.HDR_MODE_TONE_MAP_HDR_TO_SDR)
            .build())
    .addListener(/* ... */)
    .build()

Java

Transformer transformer = new Transformer.Builder(context)
    .setTransformationRequest(
        new TransformationRequest.Builder()
            .setHdrMode(TransformationRequest.HDR_MODE_TONE_MAP_HDR_TO_SDR)
            .build())
    .addListener(/* ... */)
    .build();

トーン マッピング機能を試すには、 Transformer デモアプリ。

トーン マッピングを設定するには、 MediaCodec。ただし、実装は 複雑になります。詳しくは、 MediaCodec リファレンス ドキュメント。