動画トリマー

開始と終了を設定して動画ファイルをトリミングします。高速モードまたは精密モード。

ファイルがデバイスを離れることはありません

ここに動画ファイルをドラッグ&ドロップ

またはクリックして参照 · MP4、WebM、MOV、AVI、MKV(最大2 GB)

仕組み

  1. 動画ファイルを読み込み: デバイスから任意のMP4、WebM、MOV、AVIファイルを選択, サーバーへのアップロードなし。
  2. トリミングポイントを設定: タイムラインのハンドルを使用するか、保持するクリップを定義するために正確な開始時刻と終了時刻を入力します。
  3. トリミングをプレビュー: 選択したセグメントを再生して、エクスポート前にカットを確認します。
  4. クリップをダウンロード: トリミングされた動画を元の形式でデバイスに直接エクスポートします。

なぜ動画トリマーを使うのか?

ほとんどの動画編集アプリケーションは、インストール、サブスクリプション、またはクラウドサーバーへのアップロードを必要とします。このブラウザベースのトリマーは、WebCodecsとFFmpeg.wasmを介して完全にデバイスで動画を処理します, 映像がマシンを離れることはありません。イントロとアウトロを素早くカット、ソーシャルメディア用にクリップを分離、録画から不要なセグメントを削除、共有前にトリミングするのに最適です。異なる出力形式を選択しない限り、再エンコーディングによる品質の損失はなく、デバイスの利用可能なメモリを超えるサイズ制限もありません。

サポートされている形式

Cut、trim、split、そしてなぜ言葉が重要なのか

カジュアルな会話では「trim」、「cut」、「split」は交換可能です。ビデオツーリングでは、これらは3つの異なる操作を記述します。trimは最初と/または最後からコンテンツを取り除き、中間のすべてを保持します。編集用語でのcutは、完成した編集における2つの隣接ショット間の境界です。splitは1つのクリップを取り、選択した点で2つのクリップに分割します。ユーザーの観点から、このツールはトリムを実行します、開始と終了を設定すると、その間にあるものを保持します。

興味深い質問は、不要なバイトをどのように削除するかです。2つの根本的に異なるアプローチが異なるファイルを生成します。

高速(ストリームコピー)対精密(再エンコード)

ストリームコピー、「高速」モードは、画像をまったく見ません。コンテナを開き、要求された時間ウィンドウに対応するバイト範囲を見つけ、それらのバイトを逐語的に新しいコンテナにコピーし、インデックスとタイムスタンプを修正し、結果を書き込みます。デコードもなく、再エンコードもなく、品質損失もありません。現代のマシンでは、500 MBのH.264ファイルをこの方法で1秒未満でトリムできます、なぜなら作業は基本的にファイルI/Oであり、算術ではないからです。落とし穴: コピー操作は特定のフレーム、特にI-フレームでのみ開始および終了できます: そしてそれらは必ずしもあなたがポイントした場所ではありません。したがって、結果のクリップの開始は、ファイルが最初にエンコードされたときに使用されたコーデック設定に応じて、ゼロから10秒のどこかで前後にシフトする可能性があります。

再エンコード、「精密」モードは、影響を受ける全セクションを生のピクセルにデコードし、要求された開始前と要求された終了後のフレームを破棄してから、残りを再エンコードします。これにより、選択したフレームでまさに開始および終了するクリップが生成されます(業界用語でフレーム正確)、完全なエンコードのコストで。完全なエンコードはストリームコピーよりも数百倍または数千倍遅く、ロッシーコーデックは冪等ではないため、圧縮損失の世代を導入します: 同じ画像をエンコード、デコード、再エンコードしても、まったく同じ画像は戻ってきません。損失は高ビットレートでは小さいですが、ゼロではなく、同じファイルが繰り返しトリムされると蓄積します。

高速パスは、ユーザーがイントロ、アウトロ、または粗い先頭および末尾の素材を削除し、カットがポイントした場所から半秒離れているかどうかを気にしない95%のケースで正しいです。精密パスは、カットが特定のフレーム、パンチライン、効果音、下流の編集のための同期マークに着地する必要がある場合の正しいツールです。

I-フレーム、P-フレーム、B-フレーム、そしてGOP

あらゆる現代のビデオコーデック(H.264、H.265 (HEVC)、VP9、AV1)は、連続するフレームがほぼ同じ画像であるという事実を利用してビデオを圧縮します。各フレームを独立してエンコードするのではなく、コーデックはフレームの小さな部分を完全にエンコードし、残りを近隣との違いとしてエンコードします。完全なフレームはI-フレーム(イントラコード化)です。差分フレームには2種類あります: P-フレーム(以前のフレームからのみ予測)とB-フレーム(双方向予測コード化、以前と後のフレームの両方を参照できる)。I、次にPとBフレームのラン、そして別のIのシーケンスはGroup of Pictures、またはGOPと呼ばれます。GOP内では、開始時のI-フレームへの参照なしにフレームをデコードできません。GOPを越えて依存関係はありません: プレーヤーは任意のI-フレームでファイルにドロップインし、そこからデコードを開始できます。

これがストリームコピートリミングがキーフレーム境界に制約される理由です。非I-フレームで新しいファイルを開始するには、GOPの開始時にI-フレームをデコードし、選択した点まですべてのPとBフレームをデコードしてから書き込みを開始する必要があります、これはまさに精密パスが行うことです。典型的なH.264ファイルは2から4秒のGOP長を使用します。FFmpegのlibx264はデフォルトで約250フレーム(25 fpsで~10秒、30 fpsで~8.3秒)です。ストリーミングプロバイダーはこれをHLSとDASHセグメント境界に合わせるために2秒に短縮します。H.265はより長いGOPをより効率的に許容し、しばしば4-10秒に構成されます。VP9(libvpx)はデフォルトで最大キーフレーム距離240フレームです。AV1は通常2-6秒の範囲に着地します。実用的な意味合い: 1分30秒でカットを要求するユーザーは、ファイルが最初にエンコードされた内容に応じて、ストリームコピー結果が1分24秒から1分32秒のどこかで開始することになる可能性があります。

FFmpegの簡単な歴史

FFmpegは2000年12月20日にFabrice Bellardによって開始されました、彼はQEMU仮想化機とTCC Cコンパイラを以前に書いていたフランスのコンピュータ科学者です。彼はGérard Lantauというペンネームでコミットしました。名前はfast forwardの「FF」と、それが元々扱うように設計されていたコーデックファミリーの「mpeg」から来ています。最初からアーキテクチャはコーデック実装(libavcodec)をコンテナパース(libavformat)から分離していました、これがFFmpegが何年にもわたって簡単に拡張されてきた理由です。Bellardは2004年にMichael Niedermayerにメンテナーシップを渡しました。プロジェクトは2011年に祝賀されたフォークを生き延びました、開発者グループがガバナンスの意見の相違でLibavというプロジェクトに分離したとき; 2つのプロジェクトは2018年までに精神的に(正式ではないにしても)再融合し、Libavの改善のほとんどがFFmpegにアップストリームに戻されました。

今日FFmpegは世界のビデオの膨大な部分の下にある沈黙のインフラストラクチャです、YouTube、Netflix、VLC、OBS Studio、Audacity、HandBrake、Plex、そしてほとんどのプロ放送パイプラインがスタックのどこかでそれを使用しています。2026年時点での現在の安定リリースは8.xシリーズです。ライセンスはコンパイル時にどのオプションコンポーネントが有効になっているかに応じてデュアルLGPL-2.1-or-laterまたはGPL-2.0-or-laterです。

FFmpeg.wasm、ブラウザでのFFmpeg

2020年11月、Tesseract OCRエンジンのTesseract.jsポートですでに知られていた台湾のエンジニアJerome Wuは、ブラウザ内で完全に実行されるFFmpegのWebAssemblyコンパイレーションであるFFmpeg.wasmの最初のリリースを公開しました。彼は2020年11月4日にプロジェクトを発表しました。2026年までにプロジェクトは大幅に成熟しており、現在のリリースは0.12シリーズとアクティブなコミュニティフォークです。npmパッケージは現在、コアWebAssemblyバイナリ、メインスレッドとWASMを実行するワーカースレッド間のメッセージパッシングを処理するJavaScriptラッパー、およびユーザーが通常のJavaScript BlobとFileオブジェクトを使用してファイルを出し入れできる仮想ファイルシステムをバンドルしています。

プロジェクトには、初めてデプロイしようとするすべての開発者を捕まえる悪名高い要件が1つあります。FFmpeg.wasmはSharedArrayBuffer、メインスレッドとワーカースレッド間でメモリを共有するためのJavaScript APIを使用します。SpectreとMeltdownのCPU脆弱性が2018年に開示された後、ブラウザは条件を厳しくしました: ページは2つの特定のHTTPヘッダー、Cross-Origin-Opener-Policy: same-originとCross-Origin-Embedder-Policy: require-corpと共に提供される必要があり、ページ上のすべてのクロスオリジンリソースはCORSを介してオプトインするか、同じオリジンから来る必要があります。これらのヘッダーがなければ、SharedArrayBufferはundefinedであり、FFmpeg.wasmは初期化しません。Chromeはこれを厳格に強制します; FirefoxとEdgeはChromeに従います; Safariはバージョン15.2以降から参加しました。

コンテナフォーマット

コンテナはファイルのラッパーです。画像をエンコードしません; エンコードされた画像とオーディオをタイミングとメタデータと一緒にパッケージ化します。

ブラウザビデオAPI、実際に利用可能なもの

HTML5の要素は約10年の開発の後、2014年10月28日にW3C Recommendationになりました。HTML5以前は、ビデオを埋め込むことはAdobe FlashまたはMicrosoft Silverlightを意味しました。要素自体には編集APIがありません、video.trim(start, end)メソッドも、video.cut()も、セグメントを抽出する組み込みの方法もありません。再生、一時停止、シーク以外のことを行うには、開発者はより低レベルのAPIに手を伸ばすか、ページにFFmpegをコンパイルする必要があります。

Media Source Extensions (MSE)は、JavaScriptが要素にフィードするバイトストリームを構築できるW3C仕様です。2014年にCandidate Recommendationに達しました; YouTubeで2013年9月、Netflixで2014年6月から本番で使用されています。主な使用例はアダプティブストリーミングです(デコードされたフレームを公開しないので、単独で再エンコードを実行できません。WebCodecsはより低レベルの代替案です)はブラウザの組み込みビデオおよびオーディオコーデック実装を直接JavaScriptに公開し、VideoDecoderとVideoEncoderインターフェースを持ちます。WebCodecsはChrome 93でのオリジントライアルの後、2021年9月21日にChrome 94で正式に出荷され、その後FirefoxとSafariに達しました。現在の最先端は、ツールが利用可能でコーデックがサポートされているときにWebCodecsを使用し、それ以外の場合はFFmpeg.wasmにフォールバックすることです。このツールは両方を使用します。

ソーシャルプラットフォームの長さ制限、人々がトリマーを開く理由

ブラウザベースのトリミングへの需要の大部分は、ソーシャルプラットフォームへのアップロード用にビデオを準備することから来ており、それぞれに独自の最大長があります:

これらの数字はプラットフォームが反復するにつれて絶えず変化しますが、「プラットフォームXはYミニッツを超えるとアップロードを拒否する」という一般的なパターンは耐久性があり、エンドユーザーがそもそもトリマーを開く最も一般的な理由の1つです。

デスクトップエディタがより良いツールである場合

ブラウザトリマーが不十分なユーザーにとって、プロフェッショナルエコシステムはいくつかの確立されたデスクトップアプリケーションを中心に展開します。Apple ProResは、Final Cut Studio 2と一緒に2007年4月にAppleによって導入された中間コーデックのファミリーで、配信ではなく編集用に設計されています。Final Cut Proは、1999年にMacromediaによって最初にリリースされ、1年後にAppleが取得し、2011年6月21日にFinal Cut Pro Xとして再構築および再リリースされました; macOS専用で、ドキュメンタリーと放送の世界の多くで標準エディタです。DaVinci Resolveは、元々ハイエンドのカラーグレーディングシステムで、2009年にBlackmagic Designに買収され、徐々に完全な編集/オーディオポスト/ビジュアルエフェクト/グレーディングスイートに再構築されました、macOS、Windows、Linuxで利用可能で、編集市場の経済を実質的に変えた無料のベースバージョンがあります。Adobe Premiere Proは3番目の主要なプレーヤーで、映画とTV業界の多くを支配しています。これらのいずれも、TikTokに投稿する前に電話で録画されたクリップから最初の10秒を削除したいユーザーには適切ではなく、これがまさにブラウザトリマーが埋めるギャップです。

ここで"no upload"が特に重要な理由

ブラウザベースのビデオトリマーの最も重要な単一の特性は、ファイルがユーザーのマシンを離れないことです。ビデオデータはFile入力から直接JavaScriptメモリにロードされ、ブラウザプロセス内のWebAssemblyによって処理され、結果はダウンロードとして提供されます。アップロードはなく、ファイルを読むことができる第三者もなく、ユーザー数に応じてスケールするクラウド請求書もなく、書く必要のあるデータ保持ポリシーも監査する必要のあるものもありません。機密コンテンツ(録画されたミーティング、個人映像、法的または契約上の理由で第三者にアップロードできないもの)については、それが唯一意味のあるアーキテクチャです。

欠点は、ユーザーが計算コストを支払うことです。サーバーファームで実行されるトリマーは、GPUエンコーディングハードウェアにアクセスできるため、4Kクリップを数秒で再エンコードできます; ラップトップCPUのソフトウェアで実行されているFFmpeg.wasmでの同じ操作は、1分または2分かかる場合があります。高速(ストリームコピー)パスは、エンコードを完全に回避することでこれを大幅に回避し、これがほぼすべてのカジュアルなトリミング使用例の正しいデフォルトである理由です。精密(再エンコード)パスは、ユーザーが待つことの代償としてフレーム精度を明示的に必要とする場合にのみ正しいデフォルトです。

さらなる質問

なぜ高速トリムが要求したよりも早くまたは遅く始まっているのですか?

なぜなら、高速モード(ストリームコピー)はキーフレーム(I-フレーム)でのみ開始でき、要求された開始の前に最も近いキーフレームは完全なGOPまで前にある可能性があり、ソースのエンコード方法に応じて2秒から10秒のどこかです。特定のフレームでカットが必要な場合は、より長い待ち時間と小さな圧縮損失の世代の代償として、再エンコードして選択したフレームに正確に着地する精密モードに切り替えてください。

なぜ高速トリムの後でオーディオが同期外れですか?

通常、カットポイントがビデオGOP内に着地し、そのタイムスタンプのオーディオフレームがビデオキーフレームと整列していないためです。高速モードはビデオの開始を最も近いキーフレームにシフトしますが、オーディオタイムスタンプを変更せずに運ぶことがあり、オフセットを生成します。標準のFFmpeg修正は-avoid_negative_ts make_zeroフラグで、最初のタイムスタンプがゼロになるようにすべてのタイムスタンプを再ベースします。同期が重要な場合、精密モードは新しい開始に合わせるためにオーディオを再サンプリングし、このクラスの問題を回避します。

入力とは異なるフォーマットにエクスポートできますか?

フォーマット変換には、Video Converterツールが目的別に構築されており、より多くのオプションを公開しています。トリマーは同じコーデック、同じコンテナのケース(高速モードは元のエンコーディングを完全に保持します)、または精密モードでweb-friendlyな出力の小さなセットに再エンコードするために最適化されています。再エンコードは常にCPU時間と品質損失の世代を費やします; 画像を再エンコードせずにコンテナだけを変更する必要がある場合、ffmpeg -c copy相当が適切なツールです。

なぜAVI入力は機能するがAVI出力は機能しないのですか?

AVIはほとんどの現代コーデック機能に先行しており(B-フレームはぎこちなく、オーディオ同期は4 GBを超えると脆弱で、インデックスフォーマットは限定的)、現代のツーリングは一般的にそれをレガシー入力フォーマットのみとして扱います。AVI入力は正常に読み込まれます; 出力はMP4またはWebMにデフォルトで、これらは積極的にメンテナンスされているISOBMFF/Matroskaファミリーで、すべての現代のブラウザとプレーヤーで再生されます。

関連ツール

動画コンバーター GIFメーカー 動画 → テキスト オーディオトリマー