動画アスペクト比一括判定 — 解像度・尺・GCD 比・1080p / TikTok 規格マッチ

アスペクト比の確認だけでも、動画ファイル全体が処理対象になる

動画のアスペクト比・解像度・尺を確認したい場面は、SNS 投稿前に「この動画は 16:9 か 9:16 か」を確認する、クライアントから受け取った素材が要件を満たしているか確認する、複数の動画素材を一覧して統一性を確認する、動画編集ソフトのシーケンス設定を確認してから取り込む、などです。確認作業自体は数秒ですが、確認対象の動画は撮影直後の未公開映像・クライアントから受け取った素材・社内向けの研修映像などである場合があります。

オンラインで動画のメタ情報を確認するサービスは、動画ファイルをサーバーへアップロードしてからメタデータを返す実装が大半です。アスペクト比・解像度という軽い情報を得るために、数百 MB〜数 GB の動画ファイル全体がサーバーへ到達します。「メタ情報を確認するだけ」という用途の軽さと、転送されるデータ量のギャップは video カテゴリの中で最も顕著な部類です。

解像度・尺・GCD 比という「軽い情報」は、動画なしでも取れる

動画ファイルのアスペクト比・解像度・尺は、コンテンツをデコードしなくても取得できるメタ情報です。MP4 / MOV / WebM / MKV などの主要なコンテナは、ファイルの先頭から数百バイト〜数 KB の範囲にあるヘッダ部分に、解像度・フレームレート・尺を記録しています。実際に再生・デコードする必要はありません。HTMLVideoElement の loadedmetadata イベントは、ブラウザが動画のヘッダを読み込んだ時点でこれらの情報を返します。

つまり、アスペクト比・解像度・尺の確認は、動画の映像データを一切処理せずに実行できます。動画全体をサーバーへアップロードする必要はなく、ブラウザが自前でヘッダを読んで返す情報で十分です。オンラインサービスへの丸ごとアップロードは、技術的に必要ないにもかかわらず行われている過剰な転送です。

HTMLVideoElement の loadedmetadata イベントのみ — ネットワーク通信ゼロ

このツールは動画ファイルを URL.createObjectURL(file) でオブジェクト URL に変換し、非表示の HTMLVideoElement の src に設定します。loadedmetadata イベントが発火した時点で video.videoWidth・video.videoHeight・video.duration を読み取ります。GCD (最大公約数) は gcd(width, height) で計算して比を約分します。最近接規格の判定は、decimal ratio (width/height) を 17 プリセット (16:9・9:16・21:9・4:5 など) と比較し ±1% 誤差内のものを選択します。

動画ファイルの映像データは一切デコードされず、ヘッダの読み取りのみで処理が完結します。サーバーへのアップロードは発生せず、DevTools の Network タブでも動画ファイルに関するリクエストは確認できません。結果の CSV 出力もブラウザ内の JavaScript で生成されます。

動画素材の仕様確認は、素材を手放さずに完結させる

撮影済みの動画素材・クライアントから受け取った映像・編集中のプロジェクトファイルの仕様確認は、プロダクション業務の日常です。その確認作業がブラウザ内で完結することで、未公開映像・機密映像・クライアント素材が確認作業のためだけに外部サービスへ渡ることを防げます。アスペクト比の確認という軽い用途から、素材管理のプライバシー意識を定着させられます。

MP4 / MOV / WebM コンテナのヘッダ構造と HTMLVideoElement の役割

ISO/IEC 14496-12 (MP4 / MOV) のコンテナは「box」と呼ばれる階層構造で、ftyp (ファイル種別)・moov (映像音声のメタデータ)・mdat (実際のサンプルデータ) の順で並びます。解像度・尺・フレームレート・コーデックといったメタ情報はすべて moov atom 内の mvhd (movie header)・trak (track) → tkhd (track header) → mdia → minf → stbl → stsd (sample description) に格納され、ファイル全体のごく一部 (数 KB〜数十 KB) を読むだけで取得可能です。WebM / MKV は EBML (Extensible Binary Meta Language) というバイナリ XML 形式で、Segment → Info・Tracks 要素にメタ情報が並びます。

ブラウザの HTMLVideoElement は内部で libavformat 相当のデマクサを持ち、src を設定すると Range Request または Blob からヘッダ部分のみを読み込んで loadedmetadata を発火します。movflags faststart で moov atom が先頭にあるファイル は videoWidth / videoHeight / duration が即座に取れますが、moov が末尾にある場合 (ファイル書き出し直後の状態) は末尾までシークが必要で、ローカル Blob では問題なく動作するものの HTTP Range で取得する Web 配信では遅延が出ます。VP9 / AV1 でも WebM コンテナの Tracks 要素は同じく先頭近傍にあり、ブラウザは media data 全体をデコードせずにメタ情報だけを取り出せます。

配信プラットフォーム別アスペクト比要件

YouTube は 16:9 (横) を標準とし、Shorts は 9:16 (縦) を要求します。1:1 や 4:5 はサイドバーが付くため不推奨。TikTok は 9:16 (1080×1920) が標準で、16:9 横動画は中央クロップされ表示領域が狭くなります。Instagram Reels は 9:16 (1080×1920)、Feed 投稿は 1:1 (1080×1080) または 4:5 (1080×1350)、Stories は 9:16 と複数仕様が混在します。X (旧 Twitter) は 16:9 / 1:1 / 9:16 / 4:5 などすべて受け入れますが、タイムライン表示は 16:9 にクロップされて表示されることがあります。

LinkedIn は 16:9 / 1:1 / 9:16 を受け入れ、フィード上では 1:1 が最も画面占有率が高くエンゲージメント率が高いという研究があります。Facebook は 16:9 / 1:1 / 4:5 / 9:16 をサポート、Pinterest は 2:3 (1000×1500) の縦動画が pin として最適化されます。映画館 (DCP) は Flat 1.85:1 と Scope 2.39:1 が標準で、4K HDR 映画は 17:9 (DCI 4K、4096×2160) の場合もあります。同じ素材を複数プラットフォームに出す場合、本ツールで現状確認 → video-crop で各プラットフォーム用の中央クロップを切り出す、または短辺だけ縮める用途なら video-resize を使う、というワークフローが一般的です。