あらゆる動画をオンラインで無料でHD 1080pに変換する方法
どんな動画でも無料でオンラインでHD 1080pに変換する方法
スマホからクリップを書き出した、ノートパソコンから画面録画を取り出した、あるいは古いビデオカメラの変換データをフォルダから掘り出した——そして今、それは次に必要な場所に対して間違った解像度、間違ったコーデック、間違ったコンテナになっています。あなたは動画を無料でオンラインでHD 1080pに変換したいのです。見知らぬ人のサーバーにファイルをアップロードすることなく、月額9.99ドルを支払うことなく、大切な映像にウォーターマークが押されるのを見ることもなく。
この問題は抽象的なものではありません。SandvineのGlobal Internet Phenomenaレポートによると、ストリーミング動画はダウンストリームインターネットトラフィックの65%以上を占めています。そしてStatcounter Global Statsによると、1920×1080は依然として世界で最も一般的なデスクトップ画面解像度であり、約18〜20%のシェアを占めています。これにより、1080pは動画を公開するほぼ誰にとっても実用的な万能ターゲットとなっています——デスクトップモニターやテレビに十分なほど鮮明で、無料のオンライン動画コンバーターがブラウザのタブ内で作業を完了できるほど軽量です。
この記事を読み終える頃には、特定のプラットフォームに対してどのビットレート、コーデック、アスペクト比を選択すべきか正確にわかり、ローカルで変換を実行できるようになります——登録不要、アップロード不要、ウォーターマークなしで。
目次
- 「HD 1080p」が実際に意味すること——そしてそれが正しいターゲットとなるとき
- ブラウザベース vs クラウドコンバーター：ファイルが実際にどこに存在するか
- 変換ウォークスルー：ファイルを開いてから1080pをダウンロードするまで
- 人々を最初のステップに戻す6つの変換失敗
- 同じソース、異なる設定：ビットレートとコーデックのコスト
- YouTube、TikTok、Twitch、Vimeo、共有のための1080p設定チートシート
- 変換前チェックリスト：「変換」をクリックする前の決定
「HD 1080p」が実際に意味すること——そしてそれが正しいターゲットとなるとき
動画をHD 1080pに変換するとき、あなたは特定の空間寸法を持つファイルを生成しています：1920×1080ピクセル、つまりフレームあたり約2.07メガピクセルです。この数値は、解像度のラダー上の隣人と比較するときに重要になります。720pは1280×720（≈0.92 MP）です。480pは854×480（≈0.41 MP）です。4K UHDは3840×2160（≈8.29 MP）——1080pの約4倍のピクセル数です。これらの寸法とそれを取り巻くカラーシステムは、HD向けのITU-R BT.709とUHD/HDR向けのBT.2020に由来します。
SDR 1080pの基準色空間はRec. 709です。これはHDTVシステムの色の原色、伝達特性、マトリックス係数を定義しています。ソースが別の色空間でマスタリングされていた場合——たとえばHDRコンテンツ向けのRec. 2020など——1080p SDRへの素朴な変換はハイライトを白飛びさせ、彩度をずらす可能性があります。色空間は問題が起きるまで見えません。
1080pは、YouTube、Vimeo、ウェブサイト、クライアントのポートフォリオへの配信、または標準モニターやテレビでの再生時に正しいターゲットとなります。受信者がセルラー回線で視聴する場合は過剰です：Netflixは1080p配信にわずか5 Mbpsを推奨している一方、4Kは15 Mbpsを必要とし、多くのモバイル環境では720pでも依然としてクリーンに見えます。ソースが480pまたは720pで、宛先が1080pを必要としない場合は無意味です——アップスケーリングは実際のディテールを追加せずにファイルサイズを増やすだけです。
アップスケーリングの計算は厳しいものです。480pから1080pにすると、アルゴリズムはソースが実際に含むよりも約5倍多いピクセルを発明します（0.41 MP → 2.07 MP）。CVPR 2016でのShiらによって説明されたサブピクセル畳み込みアプローチを含む最新の超解像ネットワークは、もっともらしいテクスチャを幻覚することはできますが、本当に失われたディテールを再構築することはできません。Topaz Labs自身の製品ドキュメントは、アップスケーリングの結果がソース品質に依存し、強く圧縮された元データからディテールを復元できないことを認めています。VQEG / NTIA画質プログラムによる主観的テストは一貫して、視聴者が積極的な圧縮でのアップスケール解像度よりも高ビットレートでのネイティブ解像度を好むことを発見しています。
これにより、出力品質を実際に決定する3つの変数が残ります：解像度、コーデック、ビットレートです。解像度だけでは品質と等しくありません。Anne AaronとNetflixのエンコーディングチームは、タイトル単位エンコード最適化の投稿でこれを明確にしています：Netflixは固定ラダーを使用するのではなく各アセットを分析することで、知覚的に同等な1080pを大幅に低いビットレートで配信しています。トーキングヘッドのクリップと高速モーションのスポーツストリームは、1080pで「透明」に見えるために同じビットレートを必要としません。その考え——ビットレートはコンテンツ依存である——を心に留めておいてください。これは、同じ長さの2つの1080pファイルが、同じメガバイト数で根本的に異なって見える理由を説明しています。
低解像度の動画を1080pにアップスケーリングしてもディテールは追加されません。すでに存在するものを引き伸ばし、残りを推測するようアルゴリズムに求めるだけです。変換する前にソースを把握しましょう。
ブラウザベース vs クラウドコンバーター：ファイルが実際にどこに存在するか
サーバーベースのコンバーターに動画をアップロードすると、そのファイルはデバイスを離れ、処理が行われている間——そして保持ポリシーによってはそれ以上の間——他人のインフラ上に存在します。電子フロンティア財団（EFF）は、アップロードされたコンテンツをめぐる繰り返し起きる懸念をカタログ化しています：データ保持、モデルトレーニングへの再利用、漏洩での露出です。プロバイダーが自動削除を主張していても、あなたが信頼しているのはアーキテクチャではなくポリシーです。
ブラウザベースの処理はその構造を逆転させます。WebAssembly上に構築されたツール——通常はブラウザ内で実行するためにコンパイルされたFFmpegまたはImageMagickの移植版——は、CPUとRAMを使用してローカルで変換を実行します。ファイルはブラウザメモリに読み込まれ、その場で処理され、ダウンロードに書き出されます。ネットワークを通過することは決してありません。ezyZipのようなベンダーは、このブラウザ内ワークフローを「ソフトウェアインストール不要」と説明しています。なぜなら作業を行うサーバーが存在しないからです。
| 基準 | ブラウザベース（WebAssembly） | クラウド / サーバーベース |
|---|---|---|
| ファイルの場所 | デバイス上のブラウザメモリ | リモートサーバーにアップロード |
| 速度の制限要因 | あなたのCPU + RAM | サーバーキュー + アップロード帯域幅 |
| 一般的なファイル上限 | RAM依存（実用的に約1〜4 GB） | 無料プランで約200 MB〜約2 GB |
| 登録 | なし | 多くの場合必要 |
| ウォーターマーク | なし | 無料プランでは一般的 |
プライバシーに配慮が必要なコンテンツ——法的証拠、医療画像、社内企業映像、未成年者の映像、未公開のクリエイティブ作品——については、ブラウザベースが唯一の擁護可能な選択肢です。ベンダーのファイル上限も重要です。Pixazoの無料プランはアップロードを約200 MBに制限しています。WondershareのオンラインUniConverterはより幅広いですが、彼らのインフラを経由します。ローカルで実行される無料のオンライン動画コンバーターには、マシンがRAMに保持できる範囲を超えるそのような上限はありません。
正直なエッジケースもあります。非常に大きなファイル（4 GB超）はブラウザのRAM上限に達する可能性があり、HandBrakeやFFmpeg CLIのようなデスクトップエンコーダーの方が信頼性が高くなります。50以上のファイルを無人でバッチ処理する場合、キュー型のサーバーはアップロード時間を費やしても注意を節約できるかもしれません。それ以外のすべて——最新のノートパソコンで一度に1つか2つのクリップを扱う90%のケース——については、アップロードを考慮すると速度でローカル処理が勝り、無料であることからコストで勝り、ファイルが移動しないことからプライバシーで勝ります。
ファイルがデバイスを離れないとき、コンバーターのプライバシーポリシーは重要でなくなります。それがブラウザベース処理の全要点です。
変換ウォークスルー：ファイルを開いてから1080pをダウンロードするまで
以下の各ステップは、設定とその背後にある理由を明示しています。理由を飛ばすことが、ソースよりも悪く見える900 MBのファイルになってしまう原因です。
ステップ1——まずソースを検査する。 ファイルを右クリック→プロパティ（Windows）または情報を見る（Mac）、あるいはVLCにドロップしてメディア情報を開きます。解像度、コーデック、コンテナ、長さ、ビットレートを記録します。ソースがすでに1920×1080 H.264であれば、アップスケーリングではなくトランスコーディングをしています。720p以下であれば、アップスケーリングがファイルサイズの増加に値するかどうかを判断します。検査なしの変換は当て推量です。
ステップ2——ブラウザのタブで変換ツールを開く。 インストーラー不要、管理者権限不要、アカウント不要です。WebAssemblyは数秒で初期化されます。Media Tools Suiteのブラウザベース動画コンバーターはこのパターンの一例です。ローカルで処理するツールはどれも同様に動作します。
ステップ3——ファイルを読み込む。 ドラッグ＆ドロップするか、クリックして選択します。表示されると予想されるプログレスバーは、実際には読み込みのプログレスバーです——ブラウザはバイトをディスクからメモリに移動しているのであって、どこかにアップロードしているわけではありません。高速SSDでは、これはほぼ瞬時です。
ステップ4——出力解像度を1920×1080に設定する。 ソースのアスペクト比が4:3（古いコンテンツ）または9:16（スマホ縦型）の場合、レターボックス化（黒帯でコンテンツを保持）、クロップ（フレームを埋めるために端を失う）、またはパディングの間で選択します。ネイティブ16:9ソースの場合は、直接設定して次に進みます。
ステップ5——コーデックを選択する：H.264またはH.265。 Bitmovin Video Developer Report——ストリーミング専門家のベンダー調査——は、本番ワークフローで約82%の開発者がH.264/AVCを使用し、約42%がHEVC/H.265を使用していることを発見しています。万能な互換性のためにH.264 High Profileをデフォルトにします。再生環境を制御できる場合、またはファイルサイズが拘束条件である場合のみH.265を選択します。H.265はSullivanらのHEVC概要によると、同等の主観的品質で約50%のビットレート節約を提供しますが、古いブラウザ、古いAndroid、一部のアップロードパイプラインは依然としてそれを無言で拒否します。
ステップ6——ビットレートを設定する。 1080p30の場合、H.264の知覚的「透明品質」範囲はおおよそ6〜8 Mbpsです（NTIAの主観的テスト研究による）。YouTubeの公式エンコーディングガイダンスは、1080p30アップロードに8 Mbps、1080p60に12 Mbpsを推奨しています。バランスの取れた共有には5〜6 Mbps、アーカイブまたはプロ配信には8〜12 Mbps、モーションのディテールよりもファイルサイズが本当に重要な場合のみ3 Mbpsを使用します。
ステップ7——フレームレートをソースに合わせる。 意図しない限り、24 fpsを60 fpsに「変換」しないでください。フレームレート変換はフレームを複製します。モーションのスムーズさを追加するわけではありません。ソース——24、30、または60 fps——に合わせ、チェーンの次のステップ（プラットフォームのプレーヤー）に他のことを処理させます。
ステップ8——音声を設定する。 128〜192 kbpsのAACがYouTube推奨のベースラインです。音声を別途編集する必要がある場合——冒頭の無音をトリミングする、背景ノイズを除去する、音楽ベッドを置き換える——は、専用のオンライン音声カッターを使用してまずその作業を行い、その後クリーンになった音声を変換に再ミックスします。動画コンバーター内で音声を修正しようとするのは遅いループです。
ステップ9——処理を開始してダウンロードする。 プログレスバーは今やローカルのCPU作業を反映しています——あなたのマシンがエンコーディングを行っています。完了すると、ブラウザは直接ファイルダウンロードをトリガーします。メールリンク、待合室、確認ページはありません。ソースを変換前にトリミングする必要がある場合（死んだイントロをカットする、最後の90秒の無音を除去する）は、まずオンライン動画トリマーを使用します。4分だけ必要なのに30分のクリップを変換すると、必要のないRAM、時間、ストレージを浪費します。
人々を最初のステップに戻す6つの変換失敗
これらは繰り返し起きる失敗モード——根本原因を突き止める前に人々が変換を3回繰り返してしまうものです。それぞれに具体的な技術的修正があります。
- 「私の1080p出力がソースよりも柔らかく見える。」 根本原因：ソースが1080p未満で、ツールがアップスケールした。720p → 1080pは軽度の引き伸ばしで、通常は許容できます。480p → 1080pは元のピクセルデータの5倍を発明し、目に見える柔らかさ、またはJonny Elwynのようなレビュアーが「AIのにじみ」と表現するもの——プラスチックのような肌の質感、ハードエッジ周りのハロー、フレーム間の時間的不整合——を生み出します。修正：ソース解像度が720p未満であればそれを維持するか、AI強化が独自のアーティファクトを追加することを受け入れます。
- 「出力ファイルが巨大——元のファイルより大きい。」 根本原因：強く圧縮されたソースを元のビットレートより高いビットレートで再エンコードした。2 Mbpsのソースを8 Mbpsで保存しても失われた品質は回復しません。すでに圧縮された結果をより大きなコンテナに詰め込むだけです。修正：ソースが上方に再エンコードする価値のある高ビットレートマスターであると確信していない限り（まれです）、ソースに対してビットレートを一致させるかわずかに減らします。
圧縮されたファイルをより高いビットレートで再エンコードしても品質は回復しません。同じ圧縮された結果をより大きなコンテナの中に保存するだけです。
- 「5分のクリップに処理が20分かかっている。」 根本原因：H.265エンコーディングはそのアルゴリズムの複雑さのために、H.264より約5〜10倍遅い（HEVCの計算コストについてのSullivanらを参照）。ブラウザベースの処理は他のすべてのタブともRAMを競合します。修正：ファイルサイズがH.265を要求しない限りH.264を使用し、他のブラウザタブを閉じ、まずトリミングしてより短いクリップを変換します。
- 「変換後、色が白飛びしたり過度に彩度が高く見えたりする。」 根本原因：色空間の不一致。Rec. 2020（HDR）でマスタリングされたソースをトーンマッピングなしでRec. 709（SDR 1080p）に変換すると、ハイライトのディテールが失われ、中間調の彩度がずれる可能性があります。修正：ソースがSDR Rec. 709であることを確認します。HDRの場合は、明示的なトーンマッピングオプションのあるツールを使用するか、色のずれが予想され、グレーディングパスが必要になる可能性があることを認識した上で変換します。
- 「変換後、音声が同期していないか、こもって聞こえる。」 根本原因：音声コーデックの不一致、またはサンプルレート変換の処理が不適切。ツールが適切なリサンプリングなしで音声を48 kHzから44.1 kHzに再エンコードした場合、長いクリップにわたってドリフトが蓄積します。修正：変換中に音声をソースのサンプルレートに保ちます。独立した音声作業が必要な場合——ノイズ除去、冒頭の無音のトリミング、音楽ベッドの除去——は、オンライン音声カッターで別途処理し、その後クリーンになったトラックをミックス用に戻します。
- 「私のスマホの縦型動画が、1920×1080フレームの中に巨大な黒帯を伴って出力された。」 根本原因：9:16のソースが16:9の出力コンテナに強制された。ピクセル寸法は技術的には正しいですが、コンテンツは中央のストリップしか埋めません。修正：TikTokとInstagram Reelsには1080×1920の縦型出力を選択します——どちらのプラットフォームも仕様を明示的に公開しています（TikTokアップロード要件、Meta Reels仕様）。宛先が本当に横型1080pを必要とする場合のみレターボックス化を受け入れます。
同じソース、異なる設定：ビットレートとコーデックのコスト
同じ10分の1080pソースの4つのバージョンを想像してください。それぞれ異なる設定で変換されています。ファイルサイズ、コーデック、ビットレートは予測可能な形で連動して動き、ここでの目標は選択のためのメンタルモデルを提供することです——唯一の「正しい」答えではありません。
計算は単純です。MB単位のファイルサイズ ≈ （Mbps単位のビットレート × 秒単位の長さ）÷ 8 ÷ 1024。6 Mbpsの10分クリップは約（6 × 600）/ 8 / 1024 ≈ 440 MBになります。変換前に自分の数値を入れれば、出力サイズに驚くことは二度とありません。
| シナリオ | コーデック | ビットレート | ファイルサイズ（10分） | 最適な用途 |
|---|---|---|---|---|
| アーカイブ / マスタリング | H.264 High | 10〜12 Mbps | 約750〜900 MB | 長期保存、クライアントマスター |
| バランスの取れた共有 | H.264 High | 5〜6 Mbps | 約375〜450 MB | YouTube、ウェブ埋め込み、ポートフォリオ |
| モバイル / 低帯域幅 | H.265 (HEVC) | 2〜3 Mbps | 約150〜225 MB | チャット共有、セルラー、メール |
| 480pからアップスケール | H.264 High | 5 Mbps | 約375 MB | 1080pコンテナが必須の場合 |
バランスの取れた行が、ほとんどの人にとってほとんどの場合の正しい答えです。NTIAの主観的テストは、「透明な」1080p24品質がH.264で6〜8 Mbpsの範囲でしばしば達成可能であることを発見しました。Streaming Learning CenterでのJan Ozerの実用的なガイダンスも同じゾーンに着地します：H.264の4〜6 Mbpsは、典型的な1080pストリーミングの品質とアクセシビリティのバランスを取ります。先に参照したNetflixのタイトル単位の取り組みは、別の方向からそれを補強します——静的なアニメーションコンテンツは高速スポーツよりもはるかに少ないビットレートを必要とし、タイトル単位エンコーディングがそのギャップを利用するため、Netflixは知覚的に同等な1080pを約5 Mbpsで配信できます。
H.265のトレードオフは正直なフレーミングに値します。HEVCは同等の品質で約50%のビットレート節約を提供します。しかしH.264は本番ワークフローの82%にあるのに対し、HEVCは42%です。つまりH.265ファイルは古いデバイスで再生に失敗したり、H.264を前提とするアップロードパイプラインに拒否されたり、単に受信者の古いブラウザでデコードされなかったりする可能性があります。再生環境を制御できる場合、またはファイルサイズが拘束条件である場合のみH.265を選択してください——一般的な共有のための「デフォルトの最新コーデック」の選択肢としては決して選ばないでください。
アップスケーリングの行は一つの点を強調するために存在します：480p → 1080pのアップスケールのファイルサイズは、同じビットレートでのネイティブ1080pとほぼ同じですが、品質の上限はコンテナではなくソースによって設定されます。ビットレートは名目上の解像度よりも重要です。5 Mbpsのネイティブ720pクリップは、後者が紙面上では「1080pである」にもかかわらず、同じビットレートでのアップスケールした480p → 1080pクリップよりも鮮明に見えます。解像度はラベルです。ビットレートとソース品質が、あなたの目が実際に見るものです。
YouTube、TikTok、Twitch、Vimeo、共有のための1080p設定チートシート
正しい設定で一度だけ変換してください。雑な入力を与えることで、プラットフォームの再エンコードパイプラインに決定を委ねてはいけません。
| プラットフォーム | 解像度 | フレームレート | コーデック | ビットレート |
|---|---|---|---|---|
| YouTube 1080p SDR | 1920×1080 | 24/30/60 | H.264 High | 8 Mbps @ 30、12 Mbps @ 60 |
| Vimeoマスターアップロード | 1920×1080 | ソースに合わせる | H.264 | 10〜20 Mbps |
| TikTok | 1080×1920 | 30 | H.264 | 3〜6 Mbps |
| Instagram Reels | 1080×1920 | 30 | H.264 | 3〜6 Mbps |
| Twitchライブ/VOD | 1920×1080 | 60 | H.264 | 4,500〜6,000 kbps |
| Apple HLS / ウェブ | 1920×1080 | 30/60 | H.264 High L4.0/4.1 | 6〜8 / 8〜10 Mbps |
| Discord / Slack | 1920×1080 | ソースに合わせる | H.264 | 2〜3 Mbps（ファイル上限拘束） |
上記の仕様はプラットフォームのドキュメントから直接引用されています：YouTubeヘルプ、Vimeoの圧縮ガイド、TikTokとMetaの縦型動画要件（上記ですでにリンク済み）、Twitch配信要件、AppleのHLSオーサリング仕様。すべての行の音声はAACをデフォルトとし、短編やチャットには128〜192 kbps、Vimeoマスターには320 kbps、Twitchには160 kbpsです。
表が完全には伝えきれない3つの現実：
すべてのプラットフォームはアップロード後に再エンコードします。 YouTubeが推奨する8〜12 Mbpsは、最小限の品質損失で彼らの再エンコードを生き延びる入力ビットレートです。視聴者が実際に見る配信ビットレートははるかに低いものです——YouTubeは内部でVP9とAV1を使用しており、Netflixスタイルのタイトル単位の取り組みは、多くの視聴者が5 Mbpsを大きく下回る1080pを受信することを意味します。推奨ビットレート未満でアップロードすると、プラットフォームがすでに圧縮されたソースを再圧縮するため、圧縮アーティファクトが複合します。高くアップロードし、プラットフォームに圧縮させましょう。
縦型プラットフォームは事後のクロップではなく縦型エクスポートを必要とします。 横型1080p映像を変換し、その後TikTokに16:9 → 9:16の変換を処理させると、巨大な黒帯か、頭や字幕を切り落とす積極的な自動クロップのいずれかが生じます。撮影が縦型だった場合は直接1080×1920に変換してください。意図的に再フォーマットしている場合は変換前に横型映像を事前クロップしてください——アスペクト比の決定をレコメンデーションアルゴリズムに委ねてはいけません。
チャットプラットフォーム共有では、ファイルサイズがコーデックの優雅さに勝ります。 Discordの無料プランは添付ファイルを25 MB（Nitroで500 MB）に制限しています。ほとんどの企業メールゲートウェイは25 MB近くで止まります。Discordの無料上限を狙う60秒の1080pクリップでは、コーデックの好みに関係なく最大ビットレートは約3 Mbpsです。H.265は受信者のデバイスがデコードする場合のみここで役立ちます。そうでなければ再生不可能なファイルを送ったことになります。迷ったら、低ビットレートのH.264の方が小さいファイルサイズのH.265に勝ります。
エンコード前にソースをトリミングまたはアスペクト比でクロップする必要がある場合は、破棄する映像に変換時間を費やすのではなく、まずオンライン動画トリマーでそのステップを行ってください。
変換前チェックリスト：「変換」をクリックする前の決定
これをワークシートとして使用してください。各項目は二者択一または短答式の決定であり、8つすべてを2分以内にチェックできるはずです。
- ソース解像度チェック——自分が何から始めているか把握しているか？ ソースが720p未満であれば、ツールの高度さに関係なくアップスケーリングが柔らかさを引き起こすことを受け入れます。ソースがすでに1080pであれば、アップスケーリングではなくトランスコーディング（コーデックまたはビットレートの変更）をしています。この決定が、ネイティブ解像度を維持するか、1080p出力コンテナで進むかを決定します。
- 宛先プラットフォーム——この動画はどこに存在する必要があるか？ プラットフォームのチートシートに戻って参照します。YouTube、Vimeo、TikTok、Twitch、ダイレクトシェアはそれぞれ異なる最適な仕様を持っています。最初に宛先を選択することで、解像度、アスペクト比、ビットレートの下限が固定されます。
- プライバシー要件——このファイルは法的または倫理的にサードパーティのサーバーに送れるか？ 未成年者を含む映像、医療コンテンツ、社内企業資料、未公開のクリエイティブ作品は、ローカル処理を行うブラウザベースのツールに属します。データ保持と再利用に関するEFFのガイダンスは、「完了時に削除」するサービスにも適用されます——ポリシーはアーキテクチャではありません。
- ファイルサイズの上限——満たす必要のあるアップロード上限はあるか？ Discord無料プラン：25 MB。標準メール：通常25 MB。クライアントポータル：クライアントに尋ねます。この数値が、長さの計算から逆算してステップ6のビットレート選択を駆動します。
- コーデック互換性——受信者のデバイスはH.265をデコードするか？ H.264は普遍的にサポートされています（先に引用したBitmovin調査による本番ワークフローの82%）。H.265はファイルサイズを約50%節約しますが、古いAndroid、一部のブラウザ、一部のアップロードパイプラインで無言で失敗します。確認していない限りH.264をデフォルトにします。
- ビットレートターゲット——品質、ファイルサイズ、速度：それらをランク付けする。 品質優先 → 8〜12 Mbps H.264。バランス → 5〜6 Mbps H.264。ファイルサイズ優先 → 2〜3 Mbps H.265。3つのうち1つが常に勝ちます。3つすべてを最適化できるふりをすると、すべての指標で凡庸な出力になります。
完璧な1080p変換は存在しません。あなたのプラットフォーム、プライバシーニーズ、ファイルサイズ上限に正しいものは間違いなく存在します。
- 音声処理——音声に別途の処理が必要か？ 背景ノイズを除去する、冒頭の無音をカットする、または音声トラックを完全に置き換える必要がある場合は、動画変換の前にオンライン音声カッターでその作業を行います。そうでなければ、コンバーターに128〜192 kbpsのAACをインラインで処理させて次に進みます。
- トリミングの決定——必要以上の映像を変換していないか？ 30分のファイルのうち3分だけが使える場合は、まずオンライン動画トリマーでトリミングします。破棄する映像を変換すると、RAM、時間、ダウンロード帯域幅を浪費します——そしてブラウザベースのツールでは、サーバー時間ではなくRAMが拘束条件です。
これら8つの答えを手にすれば、変換そのものは90秒のブラウザ作業です。