imgix.videoからImgix Videoへの移行

すべての.imgix.video参照を見つける

コードベース、CMS、またはテンプレート内で.imgix.videoドメイン文字列を検索してください。見つかったサブドメインはすべて移行してください — アカウントによっては複数のサブドメインを使用している場合があります(例: 本番用とステージング用で別のサブドメイン)。

サブドメインを変更する

各URLの.imgix.videoを.imgix.netに置き換えてください。パスとすべてのクエリパラメータはそのまま変わりません:

変更前: https://your-subdomain.imgix.video/path/to/video.mp4?fm=mp4
変更後: https://your-subdomain.imgix.net/path/to/video.mp4?fm=mp4

w、h、fit、auto、q、fm=mp4などの標準的なレンダリングパラメータは、Imgix Videoでも同一であり、変更の必要はありません。

imgix.video固有のパラメータを変換する

動画URLで以下のimgix.video固有のパラメータを使用している場合は、Imgix Videoの相当パラメータに変換してください:

これらのパラメータを使用していない場合は、このステップは不要です — 単純なサブドメイン変更だけで完了します。

res=medium と res=low の置き換え

res=high とは異なり、res=medium と res=low は一つの固定幅に対応しません。旧プラットフォームでは動画のアスペクト比に応じて各段階のスケーリングが異なっていたため、単一の w= 値(medium に w=1280 など)ではライブラリ全体で同じ出力サイズを再現できず、縦長や正方形の動画では res=medium が返していたサイズを大きく超えて拡大されることもあります。

代わりに、fit=max を使ったバウンディングボックスを使用し、片方の寸法だけでなく w と h の両方を設定してください:

w=1280&h=1280&fit=max

両方の寸法を設定することで、ソースの向きに関係なくボックスが正しく機能します。fit=max はアスペクト比を保ったまま動画をボックス内に収まるようにスケーリングし、ネイティブ解像度を超えて拡大することはないため、横長の動画も縦長の動画も、どちらかが想定外に大きくなることなく適切なサイズで出力されます。

動作に関するいくつかの注意点を確認する

移行したURLをテストする際に、以下の点に注意してください:

• HLS配信: fm=hlsはImgix Videoで完全にサポートされています — 特別なアクセス権は不要です。
• 動画の長さ: 最大30分の動画をサポートしています。
• 長い動画は非同期で処理されます: 2分を超える動画はバックグラウンドでエンコードされます。新しいURLへの最初のリクエストは、動画が準備されている間423ステータスを返します。以降のリクエストは、キャッシュから完成した動画を返します。これはエラーではなく想定された動作です — URLをポーリングするか、数分後に再度確認してください。

ファイルサイズを予測しやすくするために明示的なビットレートを設定する

デフォルトでは、Imgix は各動画の内容に基づいてエンコードのビットレートを自動的に選択します。便利な反面、同じ w/h/fit のボックスでも動画ごとにファイルサイズが大きく変わることがあります。シンプルで動きの少ないクリップと、動きの多い複雑なクリップでは、同じ寸法でもエンコード結果が大きく異なるためです。

ライブラリ全体で一貫した、予測しやすい出力サイズが必要な場合は、デフォルトに頼らず video-bitrate を明示的に設定してください:

w=1280&h=1280&fit=max&video-bitrate=2M

これにより、動画ごとにサイズが変動するのではなく、動画の内容や向きに関係なく同じように機能する一つの調整項目が得られます。video-bitrate には fm=mp4 が必要で、1M から 5M までの値を指定できます。

video-codec もあわせてテストする価値があります。デフォルトの h264 から h265 や av1 に切り替えると、同等の品質でファイルサイズを大幅に小さくできますが、これは明示的な video-bitrate を設定していない場合に限ります — ビットレートを固定すると、コーデックの選択はファイルサイズにほとんど影響せず、同じサイズでの品質とのトレードオフになります。また、h265 と av1 は h264 よりもブラウザやデバイスのサポートが限られているため、切り替える前にプレーヤーが対応していることを確認してください。

非常に大きなソースファイルはアップロード前に再エンコードする

非常に大きなマスターファイル、特にソースビットレートが高い数ギガバイト規模のカメラオリジナル素材は、処理に時間がかかったり、処理が完全に失敗したりすることがあります。ライブラリにこのようなマスターファイルがある場合は、オリジナルをそのまま配信するのではなく、より小さなバージョンに再エンコードして再アップロードしてください。40 Mbps 以上のカメラ出力に対して、ソースビットレートを 15〜20 Mbps 程度に抑えれば、通常は画質を保ちながら、ファイルサイズと処理時間を通常の範囲内に十分収めることができます。

大量配信のアカウントでは video-aq=enhanced を検討する

アカウントで通常の fm=mp4 リクエストを通じて大量の動画を配信している場合は、video-aq=enhanced を評価する価値があります。デフォルトのエンコードモード(video-aq=auto)は、追加の遅延がない高速なヒューリスティックを使用します。video-aq=enhanced は VMAF ベースのより詳細な分析を行い、目標の視覚品質を満たす最小のファイルを見つけます。通常、標準または動きの多いコンテンツで帯域幅を 15〜25%、複雑さの低いコンテンツで 40〜60% 削減できますが、その代わりに追加のレンダリングクレジットが発生し、最適化されたバージョンがキャッシュされるまで、最初のリクエストで短い非同期の遅延(およそ 15〜45 秒)が生じます。

帯域幅の削減効果はトラフィックに比例して大きくなるため、動画のリクエスト量が特に多いアカウントでテストする価値があります。最初のリクエストでの非同期の遅延を許容できないワークフローには適していません。

カットオーバー前にテストする

移行した各URLをリクエストし、200レスポンス(または最初のリクエストで想定される423)が返ることを確認してください。出力(サイズ、フォーマット、サムネイルのフレーム)を元のimgix.video URLと比較して、一致することを確認してください。

デプロイする

移行したURLを確認できたら、サブドメイン変更を本番環境へ展開してください。.imgix.videoのURLはサンセット日以降解決できなくなるため、スタック内にキャッシュされた古い参照が残っていないことを確認してください。