Trình Cắt và Tỉa Video

Cắt tệp video bằng cách đặt thời gian bắt đầu và kết thúc. Chế độ nhanh hoặc chính xác.

Tệp của bạn không bao giờ rời khỏi thiết bị

Kéo và thả tệp video tại đây

hoặc nhấp để duyệt · MP4, WebM, MOV, AVI, MKV (tối đa 2 GB)

Cách hoạt động

  1. Tải tệp video: chọn bất kỳ tệp MP4, WebM, MOV hoặc AVI nào từ thiết bị của bạn, không gửi đến máy chủ.
  2. Đặt các điểm cắt: sử dụng các tay cầm dòng thời gian hoặc nhập thời gian bắt đầu và kết thúc chính xác để xác định clip cần giữ.
  3. Xem trước phần cắt: phát đoạn đã chọn để xác nhận việc cắt trước khi xuất.
  4. Tải xuống clip: xuất video đã cắt trực tiếp đến thiết bị của bạn ở định dạng gốc.

Tại sao sử dụng trình cắt video?

Hầu hết các ứng dụng chỉnh sửa video yêu cầu cài đặt, đăng ký hoặc tải lên các máy chủ đám mây. Trình cắt dựa trên trình duyệt này xử lý video hoàn toàn trên thiết bị của bạn qua WebCodecs và FFmpeg.wasm, hình ảnh của bạn không bao giờ rời khỏi máy. Nó lý tưởng để cắt nhanh phần mở đầu và phần kết, tách các clip cho mạng xã hội, loại bỏ các đoạn không mong muốn từ một bản ghi và cắt trước khi chia sẻ. Không có mất chất lượng do mã hóa lại trừ khi bạn chọn một định dạng đầu ra khác, và không có giới hạn kích thước ngoài bộ nhớ khả dụng của thiết bị.

Định dạng được hỗ trợ

Cut, trim, split, và tại sao từ ngữ quan trọng

Trong giao tiếp thông thường "trim", "cut" và "split" có thể thay thế cho nhau. Trong công cụ video, chúng mô tả ba thao tác khác nhau. Trim loại bỏ nội dung từ đầu và/hoặc cuối và giữ mọi thứ ở giữa. Cut trong thuật ngữ biên tập là ranh giới giữa hai cảnh quay liền kề trong một bản chỉnh sửa hoàn thành. Split lấy một clip và chia nó thành hai clip tại một điểm được chọn. Từ quan điểm của người dùng, công cụ này thực hiện một trim, bạn đặt một điểm bắt đầu và một điểm kết thúc, và nó giữ những gì giữa chúng.

Câu hỏi thú vị là cách thế nào nó loại bỏ các byte không mong muốn. Hai cách tiếp cận khác nhau về cơ bản tạo ra các tệp khác nhau.

Nhanh (stream copy) vs Chính xác (re-encode)

Stream copy, chế độ "Nhanh", không nhìn vào hình ảnh chút nào. Nó mở container, tìm các phạm vi byte tương ứng với cửa sổ thời gian được yêu cầu, sao chép những byte đó nguyên văn vào một container mới, sửa chỉ mục và timestamp, và viết kết quả. Không có giải mã, không có re-encoding, không mất chất lượng. Trên một máy tính hiện đại, một tệp H.264 500 MB có thể được trim theo cách này trong dưới một giây vì công việc về cơ bản là file I/O, không phải số học. Cái bẫy: thao tác sao chép chỉ có thể bắt đầu và kết thúc trên các frame nhất định, đặc biệt là I-frame: và đó không nhất thiết là nơi bạn đã chỉ. Vì vậy điểm bắt đầu của clip kết quả có thể dịch chuyển về phía trước hoặc lùi từ đâu đó giữa không và mười giây, tùy thuộc vào cài đặt codec được sử dụng khi tệp ban đầu được mã hóa.

Chế độ re-encode, "Chính xác", giải mã toàn bộ phần bị ảnh hưởng thành pixel thô, vứt bỏ các frame trước điểm bắt đầu được yêu cầu và sau điểm kết thúc được yêu cầu, sau đó re-encode phần còn lại. Điều này tạo ra một clip bắt đầu và kết thúc chính xác tại frame được chọn (frame-accurate, trong thuật ngữ công nghiệp) với chi phí của một lần encode đầy đủ. Một lần encode đầy đủ chậm hàng trăm hoặc hàng nghìn lần so với stream copy và giới thiệu một thế hệ mất nén vì các codec lossy không idempotent: mã hóa, giải mã, và re-encoding cùng một hình ảnh không trả lại cho bạn chính xác cùng một hình ảnh. Mất mát là nhỏ ở bitrate cao nhưng không bằng không, và tích lũy nếu cùng một tệp được trim nhiều lần.

Đường đi Nhanh là đúng cho 95% trường hợp khi người dùng đang loại bỏ intro, outro, hoặc tài liệu đầu và cuối thô và không quan tâm liệu vết cắt có cách nửa giây so với nơi họ đã chỉ hay không. Đường đi Chính xác là công cụ phù hợp khi vết cắt cần phải đáp xuống một frame cụ thể, một câu chốt, một hiệu ứng âm thanh, một dấu sync cho một chỉnh sửa downstream.

I-frame, P-frame, B-frame, và GOP

Mọi codec video hiện đại (H.264, H.265 (HEVC), VP9, AV1) nén video bằng cách khai thác thực tế rằng các frame liên tiếp gần như cùng một hình ảnh. Thay vì mã hóa mỗi frame một cách độc lập, codec mã hóa một phần nhỏ các frame đầy đủ và phần còn lại như là sự khác biệt so với các láng giềng của chúng. Các frame đầy đủ là I-frame (intra-coded). Các frame chênh lệch có hai loại: P-frame (chỉ dự đoán từ các frame trước đó) và B-frame (được mã hóa song chiều, chúng có thể tham chiếu cả các frame trước đó và sau này). Chuỗi I, sau đó là một loạt các frame P và B, sau đó một I khác, được gọi là Group of Pictures, hoặc GOP. Bên trong một GOP, không có frame nào có thể được giải mã mà không tham chiếu đến I-frame ở đầu. Giữa các GOP không có sự phụ thuộc: một trình phát có thể nhảy vào tệp tại bất kỳ I-frame nào và bắt đầu giải mã từ đó.

Đây là lý do tại sao việc trim stream-copy bị giới hạn ở các ranh giới keyframe. Để bắt đầu một tệp mới tại một frame không phải I, bạn sẽ phải giải mã I-frame ở đầu GOP, sau đó giải mã mọi frame P và B đến điểm bạn đã chọn, sau đó bắt đầu viết, đó chính xác là những gì đường đi Chính xác làm. Một tệp H.264 điển hình sử dụng độ dài GOP từ hai đến bốn giây. libx264 của FFmpeg mặc định khoảng 250 frame (~10 giây ở 25 fps, ~8.3 giây ở 30 fps). Các nhà cung cấp streaming rút ngắn điều đó xuống còn hai giây để phù hợp với ranh giới đoạn HLS và DASH. H.265 dung nạp GOP dài hơn hiệu quả hơn và thường được cấu hình ở bốn đến mười giây. VP9 (libvpx) mặc định khoảng cách keyframe tối đa 240 frame. AV1 thường rơi vào phạm vi 2-6 giây. Hàm ý thực tế: một người dùng yêu cầu một vết cắt ở phút 1 giây 30 có thể, tùy thuộc vào tệp ban đầu được mã hóa với gì, kết thúc với một kết quả stream-copy bắt đầu ở đâu đó từ phút 1 giây 24 đến phút 1 giây 32.

Một lịch sử ngắn của FFmpeg

FFmpeg được bắt đầu vào ngày 20 tháng 12 năm 2000 bởi Fabrice Bellard, nhà khoa học máy tính người Pháp người trước đó đã viết bộ ảo hóa QEMU và trình biên dịch C TCC. Ông đã commit dưới bút danh Gérard Lantau. Tên đến từ "FF" cho fast forward và "mpeg" cho họ codec mà nó ban đầu được thiết kế để xử lý. Kiến trúc ngay từ đầu đã tách triển khai codec (libavcodec) khỏi parsing container (libavformat), đó là lý do tại sao FFmpeg đã được mở rộng dễ dàng qua nhiều năm. Bellard đã giao việc bảo trì cho Michael Niedermayer vào năm 2004. Dự án đã sống sót qua một fork nổi tiếng vào năm 2011 khi một nhóm các nhà phát triển tách ra một dự án có tên Libav vì những bất đồng về quản trị; hai dự án đã hợp nhất lại trong tinh thần (nếu không chính thức) vào năm 2018, với hầu hết các cải tiến của Libav được upstream trở lại vào FFmpeg.

Hôm nay FFmpeg là cơ sở hạ tầng thầm lặng bên dưới một phần lớn video của thế giới, YouTube, Netflix, VLC, OBS Studio, Audacity, HandBrake, Plex, và hầu hết các pipeline phát sóng chuyên nghiệp sử dụng nó ở đâu đó trong stack của họ. Bản phát hành ổn định hiện tại tính đến năm 2026 nằm trong series 8.x. Giấy phép là kép LGPL-2.1-or-later hoặc GPL-2.0-or-later tùy thuộc vào các thành phần tùy chọn nào được kích hoạt tại thời điểm biên dịch.

FFmpeg.wasm, FFmpeg trong trình duyệt

Vào tháng 11 năm 2020, một kỹ sư Đài Loan tên là Jerome Wu: đã được biết đến với port Tesseract.js của công cụ OCR Tesseract, đã xuất bản bản phát hành đầu tiên của FFmpeg.wasm, một bản biên dịch WebAssembly của FFmpeg chạy hoàn toàn bên trong trình duyệt. Ông đã công bố dự án vào ngày 4 tháng 11 năm 2020. Đến năm 2026 dự án đã trưởng thành đáng kể, với bản phát hành hiện tại trong series 0.12 và các fork cộng đồng hoạt động. Gói npm bây giờ đóng gói binary WebAssembly cốt lõi, một trình bao bọc JavaScript xử lý message-passing giữa thread chính và thread worker chạy WASM, và một hệ thống tệp ảo cho phép người dùng di chuyển tệp vào và ra bằng các đối tượng Blob và File JavaScript thông thường.

Dự án có một yêu cầu khét tiếng bắt mọi nhà phát triển cố gắng triển khai nó lần đầu tiên. FFmpeg.wasm sử dụng SharedArrayBuffer, API JavaScript để chia sẻ bộ nhớ giữa thread chính và các thread worker. Sau khi các lỗ hổng CPU Spectre và Meltdown được tiết lộ vào năm 2018, các trình duyệt thắt chặt các điều kiện: trang phải được phục vụ với hai header HTTP cụ thể, Cross-Origin-Opener-Policy: same-origin và Cross-Origin-Embedder-Policy: require-corp, và mọi tài nguyên cross-origin trên trang phải hoặc opt in qua CORS hoặc đến từ cùng một origin. Không có các header đó, SharedArrayBuffer là undefined và FFmpeg.wasm sẽ không khởi tạo. Chrome thực thi điều này nghiêm ngặt; Firefox và Edge theo dõi Chrome; Safari đã tham gia từ phiên bản 15.2 trở đi.

Định dạng container

Một container là wrapper tệp. Nó không mã hóa hình ảnh; nó đóng gói hình ảnh và âm thanh đã được mã hóa cùng với thời gian và metadata.

API video của trình duyệt, những gì thực sự có sẵn

Phần tử HTML5 trở thành W3C Recommendation vào ngày 28 tháng 10 năm 2014, sau khoảng một thập kỷ phát triển. Trước HTML5, nhúng video có nghĩa là Adobe Flash hoặc Microsoft Silverlight. Phần tử tự nó không có API chỉnh sửa, không có phương thức video.trim(start, end), không có video.cut(), không có cách tích hợp để trích xuất một đoạn. Để làm bất cứ điều gì ngoài phát, tạm dừng và seek, nhà phát triển phải tìm đến API cấp thấp hơn hoặc biên dịch FFmpeg vào trang.

Media Source Extensions (MSE) là một đặc tả W3C cho phép JavaScript xây dựng dòng byte cung cấp phần tử . Đạt Candidate Recommendation vào năm 2014; được sử dụng trong sản xuất bởi YouTube từ tháng 9 năm 2013 và bởi Netflix từ tháng 6 năm 2014. Trường hợp sử dụng chính của nó là streaming thích ứng (nó không phơi bày các frame đã giải mã, vì vậy nó không thể thực hiện re-encode một mình. WebCodecs là phương án thay thế cấp thấp hơn) phơi bày các triển khai codec video và âm thanh tích hợp của trình duyệt trực tiếp đến JavaScript, với các giao diện VideoDecoder và VideoEncoder. WebCodecs đã được vận chuyển chính thức trong Chrome 94 vào ngày 21 tháng 9 năm 2021 sau một thử nghiệm origin trong Chrome 93, và kể từ đó đã đạt đến Firefox và Safari. Trạng thái nghệ thuật hiện tại là các công cụ sử dụng WebCodecs khi có sẵn và codec được hỗ trợ, và fallback về FFmpeg.wasm nếu không. Công cụ này sử dụng cả hai.

Giới hạn độ dài nền tảng xã hội, tại sao mọi người mở trimmers

Một phần lớn nhu cầu trimming dựa trên trình duyệt đến từ việc chuẩn bị video để tải lên nền tảng xã hội, mỗi nền tảng có độ dài tối đa của riêng nó:

Những con số này thay đổi liên tục khi các nền tảng lặp lại, nhưng mẫu chung của "nền tảng X sẽ từ chối tải lên của bạn nếu nó vượt quá Y phút" là bền bỉ, và là một trong những lý do phổ biến nhất mà người dùng cuối mở trimmer ngay từ đầu.

Khi một trình chỉnh sửa desktop là công cụ tốt hơn

Đối với người dùng mà trimmer trình duyệt không đủ, hệ sinh thái chuyên nghiệp xoay quanh một vài ứng dụng desktop đã được thiết lập. Apple ProRes là một họ codec trung gian được Apple giới thiệu vào tháng 4 năm 2007 cùng với Final Cut Studio 2, được thiết kế cho chỉnh sửa, không phải phân phối. Final Cut Pro, ban đầu được phát hành vào năm 1999 bởi Macromedia và được Apple mua một năm sau đó, đã được xây dựng lại và phát hành lại với tên Final Cut Pro X vào ngày 21 tháng 6 năm 2011; chỉ macOS và là trình chỉnh sửa tiêu chuẩn trong nhiều thế giới phim tài liệu và phát sóng. DaVinci Resolve, ban đầu là một hệ thống color-grading cao cấp, đã được Blackmagic Design mua lại vào năm 2009 và dần dần được xây dựng lại thành một suite chỉnh sửa/post âm thanh/hiệu ứng hình ảnh/grading hoàn chỉnh, có sẵn cho macOS, Windows và Linux, với phiên bản cơ bản miễn phí đã thay đổi đáng kể kinh tế của thị trường chỉnh sửa. Adobe Premiere Pro là người chơi lớn thứ ba và thống trị phần lớn ngành công nghiệp phim và TV. Không có cái nào trong số này phù hợp cho người dùng muốn loại bỏ mười giây đầu tiên từ một clip được ghi bằng điện thoại trước khi đăng nó lên TikTok, đó chính xác là khoảng trống mà trimmer trình duyệt lấp đầy.

Tại sao "không tải lên" quan trọng ở đây cụ thể

Thuộc tính quan trọng nhất duy nhất của một trimmer video dựa trên trình duyệt là tệp không rời khỏi máy của người dùng. Dữ liệu video được tải từ một đầu vào File trực tiếp vào bộ nhớ JavaScript, được xử lý bởi WebAssembly bên trong tiến trình trình duyệt, và kết quả được cung cấp dưới dạng tải xuống. Không có tải lên, không có bên thứ ba có thể đọc tệp, không có hóa đơn đám mây mở rộng với số lượng người dùng, không có chính sách lưu giữ dữ liệu để viết hoặc kiểm toán. Đối với nội dung nhạy cảm (cuộc họp được ghi, cảnh quay cá nhân, bất cứ điều gì không thể tải lên bên thứ ba vì lý do pháp lý hoặc hợp đồng) đó là kiến trúc duy nhất có ý nghĩa.

Nhược điểm là người dùng trả chi phí tính toán. Một trimmer chạy trên một trang trại server có thể re-encode một clip 4K trong vài giây vì nó có quyền truy cập vào phần cứng mã hóa GPU; cùng một thao tác trong FFmpeg.wasm chạy trong phần mềm trên một CPU laptop có thể mất một hoặc hai phút. Đường đi Nhanh (stream copy) phần lớn tránh điều này bằng cách tránh hoàn toàn encode, đó là lý do tại sao đó là mặc định phù hợp cho hầu hết mọi trường hợp sử dụng trimming thông thường. Đường đi Chính xác (re-encode) là mặc định phù hợp chỉ khi người dùng rõ ràng cần độ chính xác frame với chi phí chờ đợi.

Thêm câu hỏi

Tại sao trim Nhanh của tôi bắt đầu sớm hơn hoặc muộn hơn so với những gì tôi yêu cầu?

Vì chế độ Nhanh (stream copy) chỉ có thể bắt đầu trên một keyframe (I-frame), và keyframe gần nhất trước điểm bắt đầu yêu cầu của bạn có thể là tới một GOP đầy đủ trước đó, ở đâu đó từ 2 đến 10 giây tùy thuộc vào cách nguồn được mã hóa. Nếu bạn cần vết cắt tại một frame cụ thể, chuyển sang chế độ Chính xác, nó re-encode và đáp xuống chính xác tại frame được chọn với chi phí của một thời gian chờ dài hơn và một thế hệ nhỏ mất nén.

Tại sao âm thanh bị mất sync sau khi trim Nhanh của tôi?

Thường vì điểm cắt đã đáp xuống bên trong một GOP video và frame âm thanh tại timestamp đó không thẳng hàng với một keyframe video. Chế độ Nhanh dịch chuyển điểm bắt đầu video đến keyframe gần nhất nhưng có thể mang theo các timestamp âm thanh không thay đổi, tạo ra một offset. Bản sửa lỗi FFmpeg tiêu chuẩn là cờ -avoid_negative_ts make_zero, mà rebase tất cả các timestamp để cái đầu tiên là không. Nếu sync quan trọng, chế độ Chính xác lấy mẫu lại âm thanh để thẳng hàng với điểm bắt đầu mới và tránh lớp vấn đề này.

Tôi có thể xuất sang một định dạng khác với đầu vào không?

Đối với chuyển đổi định dạng, công cụ Video Converter được xây dựng có mục đích và phơi bày nhiều tùy chọn hơn. Trimmer được tối ưu hóa cho trường hợp cùng-codec, cùng-container (chế độ Nhanh bảo toàn hoàn toàn mã hóa gốc) hoặc cho việc re-encoding sang một tập nhỏ các đầu ra thân thiện với web trong chế độ Chính xác. Re-encoding luôn tốn thời gian CPU và một thế hệ mất chất lượng; nếu bạn chỉ cần thay đổi container mà không re-encode hình ảnh, một ffmpeg -c copy tương đương là công cụ phù hợp.

Tại sao đầu vào AVI hoạt động nhưng đầu ra AVI không?

AVI có trước hầu hết các tính năng codec hiện đại (B-frame vụng về, đồng bộ âm thanh dễ vỡ vượt 4 GB, định dạng chỉ mục bị giới hạn), và công cụ hiện đại thường coi nó như định dạng đầu vào legacy mà thôi. Đầu vào trong AVI được đọc tốt; đầu ra mặc định về MP4 hoặc WebM, đó là các họ ISOBMFF/Matroska được duy trì tích cực và phát trong mọi trình duyệt và trình phát hiện đại.

Công cụ liên quan

Trình chuyển đổi video Trình tạo GIF Video → văn bản Trình cắt âm thanh