Media Tools
← ブログに戻る
YouTube動画コンバーター：フォーマットと画質に関する完全ガイド

YouTube動画コンバーター：フォーマットと画質に関する完全ガイド

May 27, 2026

YouTube動画コンバーター：フォーマットと品質の完全ガイド

YouTube動画をダウンロードしたのに、スマートフォンで再生できない。あるいは、ポッドキャスト編集のために音声だけが必要なのに、ファイルは不要な動画データで800MBもある。あるいは、クライアントにチュートリアルクリップをメールで送ろうとしているのに、メールサーバーが添付ファイルを拒否し続ける。どのシナリオも行き着く先は同じです。ファイルを破壊せず、他人のサーバーにコンテンツをアップロードせず、怪しいものをインストールするよう求めないyoutube動画コンバーターを探すことになります。

実務者が実際に抱える疑問は「最高のコンバーターは何か」ではありません。それは3つの積み重なった疑問です。どのフォーマットが品質を保つのか、どれが下流のデバイスやプラットフォームで動作するのか、そしてその過程で世代劣化をどう避けるのか。このガイドでは、フォーマットの選択、コーデックとビットレートの設定、5つの一般的なユースケースにわたるワークフローの互換性、そしてローカルのブラウザベースの変換がプライバシーの計算をどう変えるのかを取り上げます。

Hero shot — over-the-shoulder view of a laptop screen showing a YouTube video paused in one browser tab and a media converter interface open in another tab, with a format dropdown (MP4, MOV, WebM, MP3) partially visible. Desk has headphones and a pho

目次

YouTubeのネイティブダウンロードオプションが不十分な理由

YouTubeは動画をダウンロードする公式の方法を3つ提供していますが、3つすべてが厳しく制限されています。YouTube PremiumのオフラインダウンロードはYouTubeモバイルアプリ内に存在します。ファイルシステムにエクスポートできず、オフラインのまま30日経つと期限切れになり、一部のコンテンツは地域制限されています。YouTube Studioのダウンロードはクリエイター専用で、しばしば720pに制限され、自分が所有する動画でのみ利用可能です。個別動画の「ダウンロード」ボタンは、クリエイティブ・コモンズまたはクリエイターが有効化したごく一部の動画にのみ表示され、それ以外には表示されません。

こうした制限的な仕様こそが、サードパーティ製コンバーターが存在する理由です。フォーマットの選択、コーデックの選択、音声のみの抽出、あるいはデバイス間の移植性が必要になった瞬間、YouTubeのネイティブツールは機能しなくなります。

ネイティブオプションが本当に十分な3つのシナリオがあります。

  1. フライト中の気軽なモバイル視聴。 Premiumのオフラインで問題なく、変換は不要です。
  2. 自分のクリエイターコンテンツをバックアップドライブに再アップロードする。 Studioのダウンロードが最もクリーンな方法です。
  3. クリエイティブ・コモンズクリップの一時的な視聴。 組み込みのダウンロードボタンで対応できます。

それ以外のすべてには、コンテナ、コーデック、解像度、ビットレートを制御できるyoutube動画コンバーターが必要です。コンバーターが必要なシナリオは簡単に列挙できます。

  • TikTokやReels向けにクリップを再利用する — 9:16のアスペクト比が必要で、ほぼ常にトリミングが必要、そしてMP4/H.264 + AACが求められます。これを定期的に行うなら、オンライン動画トリマーが変換前のカットとアスペクト比の準備を処理します。
  • 動画インタビューからポッドキャスト音声を抽出する — MP3またはAACが必要で、通常は無音やイントロ音楽を除去するためのカットポイントが必要です。オンライン音声カッターがトリミングに適したツールで、その後配信用ビットレートでエクスポートします。
  • NASやメディアサーバーが期待するコーデックでチュートリアルをアーカイブする — 通常、ストレージコストを半分にするためにH.265のMKVを使用します。
  • ポートフォリオサイトに動画を埋め込む — 完全なブラウザ互換性のためにWebM/VP9 + MP4/H.264をデュアルソースとして必要とします。

法的な問題は明確で中立的な枠組みに値します。YouTubeの利用規約は、ダウンロードリンクが明示的に提供されている場合を除き、ダウンロードを禁止しています。電子フロンティア財団は、youtube-dl論争に関する論評の中で、個人的なタイムシフトのためのコンテンツのダウンロードは一部の法域でフェアユースに該当しうる一方で、著作権で保護された素材の再配布は明らかにそうではないと主張しています。これは法域とユースケースに依存する個人の判断にかかわる問題です。コンバーターは中立的なツールであり、与えられたファイルが何であれそれを処理します。

このガイドの残りの部分は、あなたが手元に動画ファイルを持っていて、フォーマット、コーデック、ビットレート、ワークフローを決める必要があることを前提としています。

コンテナ対コーデック — あなたが実際に下している2つの決定

最も一般的な変換ミスは、ある誤解から始まります。ユーザーは「MP4」が品質設定だと考えています。違います。MP4はコンテナです。ラッパーであり、概念的にはZIPファイルに似ていますが、タイムコード付きメディア用のものです。品質はコンテナ内のコーデック（H.264、H.265、AV1、VP9）と、そのコーデックがエンコードするビットレートに存在します。

Netflixが公開したVMAFベースの最適化に関する研究は、主観的品質がファイル名のコンテナ拡張子ではなく、コーデックの効率とビットレートと相関することを示しています。2つのMP4ファイルは、その中身次第で知覚品質が桁違いに異なることがあります。

フォーマットコンテナ規格一般的なコーデック非可逆/可逆ブラウザサポート
MP4ISO/IEC 14496-14H.264, H.265, AAC非可逆すべての主要ブラウザ
MOVQuickTimeH.264, H.265, ProRes非可逆またはほぼ可逆Safariネイティブ；その他は限定的
WebMWebM（Matroskaのサブセット）VP9, AV1, Opus非可逆Chrome, Firefox, Edge；Safariは部分的
MKVMatroska（EBML）H.264, H.265, VP9, AV1非可逆または可逆ネイティブではなし
MP3音声のみ（MPEG-1 Layer III）MP3非可逆ユニバーサル
WAV音声のみ（RIFF）PCM（非圧縮）可逆ユニバーサル
FLAC音声のみFLAC可逆ほとんどの最新ブラウザ

この表は2つの決定のロジックに集約されます。

決定その1はコンテナです。 問いかけてみましょう。このファイルはどこに置かれ、再生されるのか。ブラウザ内か、スマートフォン上か、エディタ内か、NAS上か。MDNのメディアフォーマット互換性表によれば、MP4は実質的にすべての現行主要ブラウザで再生されますが、WebM/VP9は古いSafariではサポートされていません。MKVは本質的にどのモバイルデバイスでもネイティブには再生されません。Matroska仕様は、MKVが単一ファイル内で複数の動画・音声トラック、字幕ストリーム、チャプターをサポートすることを文書化しています。それこそがMKVをアーカイブの選択肢たらしめるものであり、まさにそれがカジュアルな再生には無用なものとしている理由です。

決定その2はコーデックです。 問いかけてみましょう。望む品質対サイズのトレードオフは何か。IEEE Transactions on Circuits and Systems for Video Technologyで発表された査読済みのコーデック比較研究によれば、H.265/HEVCはH.264のビットレートのおよそ50〜60%で同等のVMAFおよびPSNR品質を維持します。これは現実的で測定可能な利点ですが、後述するハードウェアデコードの注意点が伴います。

実用的な経験則として、互換性が制約であれば、まずコンテナを選び、次にターゲットデバイスがサポートする最も効率的なコーデックを選びます。ファイルサイズが制約であれば、まずコーデックを選び（H.265またはAV1）、デバイスサポートのトレードオフを受け入れます。送り先がまだわからないときは、H.264 + AACでYouTube動画をMP4に変換するのが最も安全なデフォルトです。なぜならどこでも再生できるからです。

品質はフォーマットの属性ではありません。2つのMP4ファイルは、その中のコーデックとビットレート次第で品質が10倍も異なることがあります。

ソースを破壊せずに解像度とビットレートを選ぶ

あらゆる変換は新たなエンコードであり、あらゆる非可逆の再エンコードは世代劣化をもたらします。これは動画圧縮の専門家Jan OzerがStreaming Media向けのコーデック分析で繰り返し指摘してきた点です。目標は完璧さではありません。後で擁護できる、情報に基づいたトレードオフを行うことです。

ステップ1：ソース品質を特定する

ダウンロードしたYouTubeファイルには特定の解像度（360p、480p、720p、1080p、1440p、または2160p）があり、すでにYouTubeの推奨ビットレート範囲でエンコードされています。YouTubeの推奨アップロードエンコード設定によれば、プラットフォームの目標値はおおよそ720p SDR H.264で2.5〜5 Mbps、1080p SDR H.264で5〜8 Mbps、1440pで8〜16 Mbps、4K SDRで13〜34 Mbpsです。

ほとんどのブラウザコンバーターは、変換前にソースの解像度とビットレートを表示するファイル情報パネルを備えています。設定を確定する前にそれを読みましょう。

絶対的なルール：YouTubeが配信した品質を超えて品質を回復することはできません。 アップスケーリングはディテールを再現しません。すでにファイルにある圧縮アーティファクトを増幅させるだけです。

ステップ2：出力解像度を最終用途に合わせる

  • ソーシャルメディアへの再投稿（TikTok、Reels、Shorts）： 9:16で最大1080×1920、MP4/H.264 + AAC。
  • Web埋め込み（ブログ、ポートフォリオ、ドキュメントサイト）： 720p〜1080p。ブログプレーヤーでの4Kは帯域幅を浪費し、誰の役にも立ちません。
  • ポッドキャスト音声の抽出： 解像度は完全に無視します。動画ストリームを破棄するのですから。
  • さらなる作業のための編集ソース： ソース解像度を保持します。
  • 個人的なアーカイブ： ソース解像度に正確に合わせます。

ステップ3：選んだコーデックに合わせてビットレートを設定する

ここで最も品質の損失が起こります。コーデックを適切なビットレートに合わせましょう。

  • 1080pのH.264： 5〜8 Mbpsが視認できる品質についてのYouTube自身の推奨に合致します。3〜4 Mbpsは一般的なWeb再生には許容できます。
  • 1080pのH.265： 3〜5 MbpsでH.264の5〜8 Mbpsと知覚的に同等の品質を達成します。これはIEEEのHEVC対AVC研究とNetflixのVMAF評価によるものです。
  • VP9： Google自身のエンジニアリングデータは、VP9がH.264と比べて同等の知覚品質でビットレートを31〜43%削減することを示しています。YouTubeが配信側でこれを多用しているのはそのためです。
  • AAC音声： ステレオで約96〜128 kbpsで知覚的透明性に達します。
  • MP3音声： ステレオで約160〜192 kbpsで透明性を達成します。HydrogenAudioのリスニングテストによれば、音声のみのコンテンツは64〜96 kbpsまで最小限の劣化できれいに下げられます。

コンバーターが固定品質係数（CRF）のコントロールを公開している場合（ほとんどのFFmpegベースのツールはそうです）、HandBrakeとFFmpegのドキュメントによれば、H.264にはCRF 18〜23、H.265にはCRF 22〜28を品質対サイズの標準的なスイートスポットとして使用します。CRFが低いほど品質が高く、ファイルが大きくなります。

ステップ4：確定する前に30秒のクリップでテストする

選んだ設定で30秒を変換します。編集用モニターではなく、実際の送り先デバイスで再生します。ファイルサイズを品質と比較します。テストクリップとソースを横並びで再生して違いがわからない場合、ビットレートが高すぎたのです。約20%下げて再テストしましょう。この一つの習慣が、他のどんなワークフローの変更よりも、無駄なディスク容量と品質の不満を防ぎます。

Side-by-side comparison on a phone screen — same video frame displayed twice, one labeled "1080p at 8 Mbps H.264" and one labeled "1080p at 3 Mbps H.264," shot close enough to see compression blocking in the lower-bitrate version.

5つの一般的なワークフローにおけるフォーマットの互換性

適切なフォーマットは、その後ファイルに何が起こるかに完全に依存します。5つのワークフロー、5つの異なる答えです。

ソーシャルメディアへの再投稿（TikTok、Instagram Reels、YouTube Shorts）

  • 最適なフォーマット： MP4コンテナ、H.264動画、AAC音声。プラットフォームに応じて1080×1920（9:16）の縦型または1920×1080（16:9）の横型。
  • 理由： 3つのプラットフォームすべてが、アップロード要件でMP4/H.264 + AACを指定しています。これらは自分たちの側で積極的に再エンコードするため、パイプラインが約4 Mbpsを目標としているときに10 Mbpsでエクスポートすると、最終的に配信される品質を改善せずにアップロード時間を浪費します。
  • 落とし穴： アスペクト比です。16:9のYouTubeソースをTikTokに縦型でアップロードするとレターボックス化され、プラットフォームはアルゴリズムでレターボックス化されたコンテンツにペナルティを与えます。変換前にクロップまたはパディングするか、同じパスでアスペクト比を扱うトリマーを使いましょう。

ポッドキャスト音声の抽出

  • 最適なフォーマット： 192 kbpsステレオのMP3、または128 kbpsステレオのAAC。音声のみのコンテンツには96 kbps AACまで下げます。
  • 理由： HydrogenAudioのリスニングテストデータによれば、これらのビットレートは音声コンテンツに対して知覚的透明性に達します。主要なホスティングプラットフォーム（Libsyn、Buzzsprout、Megaphone）は両方を受け入れます。ファイルサイズは、セルラーデータでダウンロードするリスナーにとって管理可能なまま保たれます。
  • 落とし穴： エピソードをWAVやFLACでホストしないでください。WAVの60分のエピソードはおよそ600MBですが、同じコンテンツを192 kbps MP3にすると約85MBです。リスナーは知覚上の利益をまったく得られず、帯域幅のコストを支払うことになります。

動画編集（DaVinci Resolve、Premiere Pro、Final Cut Pro）

  • 最適なフォーマット： 一般的な編集にはH.264のMOVまたはMP4。さらなるカラーやVFX作業を目的とした完成マスターにはProRes（MOVコンテナ内）。
  • 理由： 編集ソフトウェアはH.264とProResを効率的にキャッシュおよびスクラブします。なぜなら基盤となるGPUデコードブロックがそれらを念頭に設計されているからです。
  • 落とし穴： ハードウェアデコードのサポートがCPUとGPU間で一貫していないため、長尺のタイムラインでのH.265は多くのシステムでスクラブの遅延を引き起こします。WebM内のVP9はさらに悪く、古いPremiereバージョンはそれを完全に拒否します。編集ソースはH.264に保ち、サイズが重要な場合のみ最終エクスポート時にH.265にトランスコードしましょう。

Web埋め込み（ブログ、ポートフォリオ、ドキュメントサイト）

  • 最適なフォーマット： HTML5の<video>要素によるデュアルソース — フォールバックとしてMP4/H.264、最新ブラウザ向けにWebM/VP9。
  • 理由： MDNの互換性表は、MP4/H.264 + AACがあらゆる現行ブラウザで再生されることを確認しています。WebM/VP9はChrome、Firefox、Edgeで同等の品質においてより小さいですが、古いSafariバージョンでは動作しません。
  • 落とし穴： 600ピクセル幅のブログプレーヤーでの4Kは、4倍の帯域幅コストをかけても見えない品質です。埋め込み動画は1080pに制限しましょう。ほとんどのユースケースでは720pがベストプラクティスです。

ローカルアーカイブ

  • 最適なフォーマット： ソース解像度でH.265動画のMKVコンテナ。あるいは、放送スタイルのマスターにはProResのMOV。
  • 理由： Matroska仕様によれば、MKVは単一ファイル内で複数の音声トラック、字幕ストリーム、チャプターマーカーをサポートします。IEEEのコーデック研究によれば、H.265は同等の品質でH.264に対してファイルサイズを半分にします。数百時間を保存している場合、これは意味のある違いです。
  • 落とし穴： MKVは本質的にどのモバイルデバイスでもネイティブに再生されず、VLCなしではどのAppleデバイスでも再生されません。これはストレージのフォーマット互換性の選択であり、再生のための選択ではありません。アーカイブと移植性の両方が必要な場合は、MOVでアーカイブしましょう。

ブラウザ内変換がプライバシーの方程式を変える理由

アーキテクチャは、ほとんどのユーザーが認識しているよりも重要です。クラウドコンバーターとブラウザベースのコンバーターは外から見れば同じように見えます。どちらもファイルピッカーと「変換」ボタンを持っています。しかしデータの流れはまったく異なります。

クラウドコンバーターの流れ：

  1. ユーザーがブラウザでファイルを選択する。
  2. ファイルがコンバーターのサーバーにアップロードされる（家庭用ブロードバンドで100MBを超えるファイルの場合、これはしばしば変換そのものより長くかかります）。
  3. サーバーが他のユーザーの後ろにジョブをキューイングする。
  4. サーバーがFFmpegや類似のツールでファイルを処理する。
  5. サーバーが結果を一時的に保存する。
  6. ユーザーが結果をダウンロードする。
  7. サーバーがスケジュールに従ってファイルを削除するとされている。

ローカルブラウザコンバーターの流れ（WebAssembly）：

  1. ユーザーがファイルを選択する。
  2. ブラウザがWebAssemblyにコンパイルされたFFmpegをロードする（Wasmバイナリの一度きりのダウンロードで、その後はキャッシュされる）。
  3. ファイルがブラウザタブのメモリに読み込まれる。
  4. FFmpeg.wasmがユーザーのCPU上でローカルに処理する。
  5. 出力がブラウザメモリに書き込まれ、ダウンロードとして提供される。
  6. ファイルは決してデバイスを離れない。

WebAssemblyは計算負荷の高いメディアワークロードに対してほぼネイティブのパフォーマンスを可能にします。FFmpeg/Wasmのデモを取り上げたMozilla HacksとChrome Developersのエンジニアリング投稿によれば、典型的にはネイティブ速度の1.2倍〜2倍以内です。

プライバシーへの影響は曖昧ではなく具体的です。

  • ファイル内容のサーバーログがない。 ループにサーバーが存在しません。ログに記録するものが何もありません。
  • ISPによるファイルの可視性がない。 ISPに見えるのはコンバーターページをロードした接続だけで、処理されているファイルは見えません。
  • 保持リスクがない。 ファイルはブラウザタブのメモリ内にのみ存在します。タブを閉じればそれが削除されます。
  • チェーンにサードパーティの処理者がいない。 これは機密性の高い映像を扱うユーザーにとって重要です。医療コンテンツ、法的証拠、ジャーナリズムのソース素材、NDAに縛られたクリエイティブ作業、未成年者の映像、企業内部のコンテンツなどです。

セキュリティの側面もあります。Malwarebytes Labsやその他のセキュリティ研究者は、多くの人気のある「無料YouTube to MP3」サイトがマルウェアの配布経路として機能していることを文書化しています。攻撃的な広告ネットワーク、抱き合わせインストーラー、ドライブバイダウンロード、そして場合によってはコンバーターページ自体に注入された暗号通貨マイニングスクリプトを通じてです。インストーラーを必要とせず、攻撃的な広告収益化に依存しないブラウザローカルのツールは、そのリスクのカテゴリ全体を回避します。

ローカル変換の正直な制限は、直接述べる価値があります。

  • デバイスに依存するパフォーマンス。 処理速度はユーザーのCPUによって制限されます。2015年のラップトップは最新のクラウドGPUファームより遅くなります。
  • メモリの上限。 MozillaとChromeのドキュメントによれば、ブラウザはタブごとのWebAssemblyメモリに上限を設けています。非常に大きな4Kソースファイルや数十のファイルのバッチはそれらの上限に達する可能性があります。
  • バックグラウンド処理がない。 タブを閉じるとジョブが終了します。クラウドサービスは長いジョブが終わったときにメールで知らせることができますが、ブラウザツールはできません。

正直な枠組みとして、プライバシーが懸念事項でない場合、低速デバイス上の非常に大きなファイルにはクラウド変換が理にかなっています。ブラウザローカルの変換はそれ以外のほぼすべてに理にかなっています。

最新のブラウザは、ブラウザ内で直接GPUアクセラレーションによるエンコードを可能にするWebCodecsとWebGPUのAPIを公開し始めており、WebCodecsに関するChrome Developersのドキュメントによれば、速度差をさらに狭めています。クラウドベースの処理のパフォーマンス上の論拠は毎年縮小しています。

Media Tools Suiteはこのアーキテクチャの一実装です。FFmpeg、ImageMagick、PandocはすべてWebAssemblyにコンパイルされており、あらゆる変換（動画、音声、画像、ドキュメント）がブラウザタブ内で実行され、それ以外のどこでも実行されません。

コンバーターがブラウザ内で実行されるとき、ファイルは決してサードパーティのサーバーに触れません。それは便利さではありません。プライバシーの境界線です。

品質を破壊する6つの変換ミス

以下のすべてのミスは実際のユーザーファイルで観察されています。それぞれに具体的で実行可能な修正方法があります。

1. ターゲットデバイスがサポートしていないコーデックに変換する

実情： Apple Developerのドキュメントによれば、H.265/HEVCは最近のiPhoneとMacにハードウェアデコードのサポートがありますが、ローエンドや古いAndroidデバイスではサポートが一貫していません。VP9は古いSafariバージョンでサポートされていません。AV1はまだデバイスエコシステム全体に展開中です。

修正： 迷ったら、MP4内のH.264を使いましょう。過去10年間に出荷されたスマートフォン、タブレット、ブラウザ、テレビにわたって実質的に普遍的なハードウェアデコードサポートを持つ唯一のコーデックです。

2. 高いビットレートが優れた品質に等しいと思い込む

実情： 1080pでの8 MbpsのH.264と10 MbpsのH.264は、横並びのテストでほとんどの視聴者にとって知覚的に同一ですが、10 Mbpsのファイルはおよそ25%大きくなります。

修正： より高くする前に、YouTubeの推奨ビットレート（1080p H.264で5〜8 Mbps）でテストしましょう。違いがわからないなら、バイト数のために支払うのはやめましょう。特にセルラーデータで配信したり多数のファイルを保存したりする場合は。

3. 480pのソースを1080pにアップスケールする

実情： 失われたピクセルは戻ってきません。アップスケーリングは既存の圧縮アーティファクト（ブロッキング、バンディング、エッジのリンギング）を増幅させ、情報の利得なしにファイルを肥大化させます。一部の消費者向けツールは静止画像でより良い結果を出せる「AIアップスケーリング」を売り込んでいますが、すでに圧縮されたYouTube動画での利得はせいぜいわずかなものです。

修正： 出力解像度をソース解像度に合わせましょう。ソースが480pなら、480pで出力します。送り先がより小さい場合はダウンスケールします。

4. ポッドキャスト音声をWAVやFLACでホストする

実情： 60分のWAVファイルはおよそ600MBですが、同じコンテンツを192 kbps MP3にするとおよそ85MBです。HydrogenAudioの透明性閾値は、192 kbps MP3がほとんどの話し言葉コンテンツでほとんどのリスナーにとって透明であることを確認しています。

修正： 可逆形式は編集マスターにのみ使いましょう。オンライン音声カッターでイントロ、アウトロ、無音を除去するためにトリミングした後、MP3またはAACで配信します。

5. 変換前にアスペクト比を無視する

実情： YouTubeのソースは通常16:9です。TikTokとReelsは9:16を望みます。クロップやパディングなしで変換すると、プラットフォームのアルゴリズムが配信で格下げするレターボックス化された動画が生成されます。

修正： 変換前にターゲットのアスペクト比を決めましょう。コンバーターのクロップまたはスケール設定を使うか、アスペクト比を明示的に制御できる専用ツールで事前トリミングします。

6. 出力ファイルサイズをアップロード制限と照合し忘れる

実情： TikTokはモバイルアップロードで287.6MBに制限されています。Instagram Reelsは4GBに制限されていますが、ファイルを100MB未満に保つことを推奨しています。ほとんどのメール添付制限は25MBです。何も受け入れない「完璧な」ファイルを作ってしまうこともあります。

修正： 変換前に見積もりましょう。大まかな計算式：Mbps単位の総ビットレート × 秒単位の長さ ÷ 8 = MB単位のファイルサイズ。8 Mbpsの5分の動画はおよそ300MBになります。エンコードした後ではなく、する前にビットレートまたは長さを調整しましょう。

コンバーターユーザーが最もよく尋ねる5つの質問

Q1：YouTube動画を変換するのは合法ですか？

YouTubeの利用規約は、ダウンロードリンクが明示的に提供されている場合を除き、ダウンロードを禁止しています。youtube-dl論争に関する電子フロンティア財団の分析は、個人的なタイムシフトは一部の法域でフェアユースに該当しうる一方で、著作権で保護されたコンテンツの再配布は明らかにそうではないと指摘しています。境界線は法域に依存し、用途に固有のものです。ツールがあなたに代わって答えられる問題ではありません。コンバーターは与えられたファイルが何であれそれを処理します。

Q2：MP4からWebMへの変換で品質は失われますか？

コンテナ変換だけでは、ツールがリマックスする場合、品質は失われません。つまり、再エンコードせずに既存のストリームを新しいコンテナにコピーするということです。しかしコンバーターが再エンコードする場合（コーデックを変更するとき、たとえばMP4内のH.264をWebM内のVP9に変えるときなど、ほとんどがそうします）、1世代の非可逆圧縮を取り込みます。同等以上のビットレートでは知覚上の違いは小さいです。出力ビットレートをソースと同じかわずかに上に設定しましょう。

Q3：変換したファイルがラップトップでは再生できるのにスマートフォンでは再生できないのはなぜですか？

ほとんど常にコーデックの互換性の問題です。最も一般的なケース：H.265/HEVCは最新のMacでは再生できますが、古いAndroidスマートフォンでは再生できません。AAC音声でMP4内のH.264でファイルを再エクスポートしましょう。Apple DeveloperのドキュメントとMDN Web Docsの互換性表によれば、この組み合わせは過去10年間に出荷された実質的にすべてのデバイスで再生されます。

Q4：変換にはどれくらい時間がかかるべきですか？

最新のラップトップでの5分の1080pクリップのブラウザローカル変換は、CPU次第で通常30秒から3分で完了します。クラウド変換は処理の上にアップロードとダウンロードの時間が加わります。家庭用ブロードバンドで100MBを超えるファイルの場合、アップロードだけでもしばしばローカル処理の全体時間を超えます。これはブラウザベンダーのエンジニアリングチームがMozilla Hacksでクライアント側のメディアツールについて主張する速度の論拠です。

Q5：複数の動画を一度にバッチ変換できますか？

ほとんどのブラウザベースのコンバーターは、MozillaとChromeが文書化したタブごとのWebAssemblyメモリ制限のため、タブごとに一度に1ファイルを処理します。大量のバッチ（数十または数百のファイル）の場合、HandBrakeやFFmpegスクリプトのようなデスクトップツールの方が速く動作します。一回限りの作業や小規模なバッチ作業では、ループにアップロードステップがないため、ブラウザ変換の方がエンドツーエンドで速いです。