Pemotong & Pemangkas Video

Potong berkas video dengan menetapkan waktu mulai dan akhir. Mode cepat atau presisi.

Berkas Anda tidak pernah meninggalkan perangkat Anda

Seret dan letakkan berkas video di sini

atau klik untuk menelusuri · MP4, WebM, MOV, AVI, MKV (maks 2 GB)

Cara kerja

  1. Muat berkas video: pilih berkas MP4, WebM, MOV, atau AVI apa pun dari perangkat Anda, tidak ada pengiriman ke server.
  2. Tetapkan titik pemotongan: gunakan pegangan timeline atau masukkan waktu awal dan akhir yang presisi untuk mendefinisikan klip yang akan dipertahankan.
  3. Pratinjau pemotongan: putar segmen yang dipilih untuk mengonfirmasi pemotongan sebelum ekspor.
  4. Unduh klip: ekspor video yang dipotong langsung ke perangkat Anda dalam format aslinya.

Mengapa menggunakan pemotong video?

Sebagian besar aplikasi pengeditan video memerlukan instalasi, langganan, atau pengiriman ke server cloud. Pemotong berbasis peramban ini memproses video sepenuhnya di perangkat Anda melalui WebCodecs dan FFmpeg.wasm, gambar Anda tidak pernah meninggalkan mesin Anda. Sangat ideal untuk memotong intro dan outro dengan cepat, mengisolasi klip untuk media sosial, menghapus segmen yang tidak diinginkan dari rekaman, dan memotong sebelum berbagi. Tidak ada kehilangan kualitas dari encoding ulang kecuali Anda memilih format keluaran yang berbeda, dan tidak ada batas ukuran di luar memori yang tersedia di perangkat Anda.

Format yang didukung

Cut, trim, split, dan mengapa kata-kata penting

Dalam percakapan biasa "trim", "cut" dan "split" bisa dipertukarkan. Dalam tooling video, mereka menggambarkan tiga operasi berbeda. Trim menghapus konten dari awal dan/atau akhir dan menyimpan semuanya di tengah. Cut dalam terminologi editorial adalah batas antara dua shot yang berdekatan dalam edit yang sudah jadi. Split mengambil satu klip dan membaginya menjadi dua klip pada titik yang dipilih. Dari sudut pandang pengguna, alat ini melakukan trim, Anda mengatur awal dan akhir, dan menyimpan apa yang ada di antara mereka.

Pertanyaan menariknya adalah bagaimana ia menghapus byte yang tidak diinginkan. Dua pendekatan yang berbeda secara fundamental menghasilkan file yang berbeda.

Cepat (stream copy) vs Presisi (re-encode)

Stream copy, mode "Cepat", tidak melihat gambar sama sekali. Ia membuka container, menemukan rentang byte yang sesuai dengan jendela waktu yang diminta, menyalin byte-byte tersebut secara verbatim ke container baru, memperbaiki indeks dan timestamp, dan menulis hasilnya. Tidak ada decoding, tidak ada re-encoding, tidak ada kehilangan kualitas. Pada mesin modern, file H.264 500 MB dapat di-trim dengan cara ini dalam waktu kurang dari satu detik karena pekerjaannya pada dasarnya adalah file I/O, bukan aritmatika. Tangkapannya: operasi salin hanya dapat dimulai dan berakhir pada frame tertentu, khususnya I-frame: dan itu tidak selalu di mana Anda menunjuk. Jadi awal klip yang dihasilkan dapat bergeser ke depan atau ke belakang dari mana saja antara nol hingga sepuluh detik, tergantung pada pengaturan codec yang digunakan ketika file awalnya dikodekan.

Mode re-encode, "Presisi", mendekode seluruh bagian yang terpengaruh kembali ke piksel mentah, membuang frame sebelum awal yang diminta dan setelah akhir yang diminta, kemudian mengkode ulang sisanya. Ini menghasilkan klip yang dimulai dan berakhir tepat pada frame yang dipilih (frame-accurate, dalam terminologi industri) dengan biaya encode penuh. Encode penuh ratusan atau ribuan kali lebih lambat daripada stream copy dan memperkenalkan satu generasi kehilangan kompresi karena codec lossy tidak idempoten: mengkode, mendekode, dan mengkode ulang gambar yang sama tidak memberi Anda kembali gambar yang persis sama. Kehilangan kecil pada bitrate tinggi tetapi bukan nol, dan menumpuk jika file yang sama di-trim berulang kali.

Jalur Cepat benar untuk 95% kasus di mana pengguna menghapus intro, outro, atau materi awal dan akhir yang kasar dan tidak peduli apakah potongan setengah detik dari tempat mereka menunjuk. Jalur Presisi adalah alat yang tepat ketika potongan perlu mendarat di frame tertentu, punchline, efek suara, tanda sync untuk edit downstream.

I-frame, P-frame, B-frame, dan GOP

Setiap codec video modern (H.264, H.265 (HEVC), VP9, AV1) mengompres video dengan memanfaatkan fakta bahwa frame berturut-turut hampir gambar yang sama. Daripada mengkode setiap frame secara independen, codec mengkode sebagian kecil frame secara penuh dan sisanya sebagai perbedaan dari tetangga mereka. Frame penuh adalah I-frame (intra-coded). Frame perbedaan datang dalam dua varietas: P-frame (diprediksi hanya dari frame sebelumnya) dan B-frame (dikode dua arah, mereka dapat mereferensikan frame sebelumnya dan setelahnya). Urutan I, kemudian deretan frame P dan B, kemudian I lagi, disebut Group of Pictures, atau GOP. Di dalam GOP, tidak ada frame yang dapat didekode tanpa referensi ke I-frame di awal. Antar GOP tidak ada ketergantungan: pemain dapat masuk ke file pada I-frame mana pun dan mulai mendekode dari sana.

Inilah mengapa trimming stream-copy dibatasi pada batas keyframe. Untuk memulai file baru pada frame non-I, Anda harus mendekode I-frame di awal GOP, kemudian mendekode setiap frame P dan B hingga titik yang dipilih, kemudian mulai menulis, yang persis dilakukan jalur Presisi. File H.264 tipikal menggunakan panjang GOP dua hingga empat detik. libx264 FFmpeg default ke sekitar 250 frame (~10 detik pada 25 fps, ~8,3 detik pada 30 fps). Penyedia streaming memperpendek itu menjadi dua detik untuk menyelaraskan dengan batas segmen HLS dan DASH. H.265 mentoleransi GOP yang lebih panjang lebih efisien dan sering dikonfigurasi pada empat hingga sepuluh detik. VP9 (libvpx) default ke jarak keyframe maksimum 240 frame. AV1 biasanya mendarat dalam rentang 2-6 detik. Implikasi praktis: pengguna yang meminta potongan pada menit 1 detik 30 mungkin, tergantung pada apa yang awalnya dikodekan file dengan, berakhir dengan hasil stream-copy yang dimulai di mana saja dari menit 1 detik 24 hingga menit 1 detik 32.

Sejarah singkat FFmpeg

FFmpeg dimulai pada 20 Desember 2000 oleh Fabrice Bellard, ilmuwan komputer Prancis yang sebelumnya telah menulis virtualizer QEMU dan kompiler C TCC. Dia melakukan commit dengan nama samaran Gérard Lantau. Nama berasal dari "FF" untuk fast forward dan "mpeg" untuk keluarga codec yang awalnya dirancang untuk ditangani. Arsitektur sejak awal memisahkan implementasi codec (libavcodec) dari parsing container (libavformat), itulah sebabnya FFmpeg telah dengan mudah diperluas selama bertahun-tahun. Bellard menyerahkan pemeliharaan kepada Michael Niedermayer pada 2004. Proyek bertahan dari fork yang dirayakan pada 2011 ketika sekelompok pengembang memisahkan proyek bernama Libav karena ketidaksepakatan tata kelola; kedua proyek bergabung kembali dalam semangat (jika tidak secara formal) pada 2018, dengan sebagian besar perbaikan Libav di-upstream kembali ke FFmpeg.

Hari ini FFmpeg adalah infrastruktur diam di bawah sebagian besar video dunia, YouTube, Netflix, VLC, OBS Studio, Audacity, HandBrake, Plex, dan sebagian besar pipeline broadcast profesional menggunakannya di suatu tempat di stack mereka. Rilis stabil saat ini pada 2026 ada di seri 8.x. Lisensinya adalah dual LGPL-2.1-or-later atau GPL-2.0-or-later tergantung pada komponen opsional mana yang diaktifkan pada waktu kompilasi.

FFmpeg.wasm, FFmpeg di browser

Pada November 2020, seorang insinyur Taiwan bernama Jerome Wu: yang sudah dikenal dengan port Tesseract.js dari mesin OCR Tesseract, menerbitkan rilis pertama FFmpeg.wasm, kompilasi WebAssembly dari FFmpeg yang berjalan sepenuhnya di dalam browser. Dia mengumumkan proyek pada 4 November 2020. Pada 2026 proyek telah matang secara signifikan, dengan rilis saat ini di seri 0.12 dan fork komunitas yang aktif. Paket npm sekarang menggabungkan binary WebAssembly inti, pembungkus JavaScript yang menangani message-passing antara thread utama dan thread worker yang menjalankan WASM, dan sistem file virtual yang memungkinkan pengguna memindahkan file masuk dan keluar menggunakan objek Blob dan File JavaScript biasa.

Proyek memiliki satu persyaratan terkenal yang menangkap setiap pengembang yang mencoba mendeploynya untuk pertama kalinya. FFmpeg.wasm menggunakan SharedArrayBuffer, API JavaScript untuk berbagi memori antara thread utama dan thread worker. Setelah kerentanan CPU Spectre dan Meltdown diungkapkan pada 2018, browser memperketat kondisi: halaman harus disajikan dengan dua header HTTP spesifik, Cross-Origin-Opener-Policy: same-origin dan Cross-Origin-Embedder-Policy: require-corp, dan setiap sumber daya cross-origin di halaman harus baik opt in melalui CORS atau datang dari asal yang sama. Tanpa header tersebut, SharedArrayBuffer adalah undefined dan FFmpeg.wasm tidak akan diinisialisasi. Chrome menegakkan ini dengan ketat; Firefox dan Edge mengikuti Chrome; Safari bergabung dari versi 15.2 dan seterusnya.

Format container

Container adalah pembungkus file. Itu tidak mengkode gambar; ia mengemas gambar dan audio yang dikodekan bersama dengan timing dan metadata.

API video browser, apa yang sebenarnya tersedia

Elemen HTML5 <video> menjadi W3C Recommendation pada 28 Oktober 2014, setelah sekitar satu dekade pengembangan. Sebelum HTML5, menyematkan video berarti Adobe Flash atau Microsoft Silverlight. Elemen itu sendiri tidak memiliki API pengeditan, tidak ada metode video.trim(start, end), tidak ada video.cut(), tidak ada cara bawaan untuk mengekstrak segmen. Untuk melakukan apa pun di luar play, pause dan seek, pengembang harus mencapai API tingkat lebih rendah atau mengkompilasi FFmpeg ke dalam halaman.

Media Source Extensions (MSE) adalah spesifikasi W3C yang memungkinkan JavaScript membangun aliran byte yang memberi makan elemen <video>. Mencapai Candidate Recommendation pada 2014; digunakan dalam produksi oleh YouTube sejak September 2013 dan oleh Netflix dari Juni 2014. Use case utamanya adalah streaming adaptif (itu tidak mengekspos frame yang didekode, jadi tidak dapat melakukan re-encode sendiri. WebCodecs adalah alternatif tingkat lebih rendah) mengekspos implementasi codec video dan audio bawaan browser langsung ke JavaScript, dengan antarmuka VideoDecoder dan VideoEncoder. WebCodecs dikirim secara resmi di Chrome 94 pada 21 September 2021 setelah uji coba asal di Chrome 93, dan sejak itu telah mencapai Firefox dan Safari. State of the art saat ini adalah agar alat menggunakan WebCodecs ketika tersedia dan codec didukung, dan fallback ke FFmpeg.wasm sebaliknya. Alat ini menggunakan keduanya.

Batas panjang platform sosial, mengapa orang membuka trimmer

Sebagian besar permintaan untuk trimming berbasis browser berasal dari mempersiapkan video untuk unggahan platform sosial, masing-masing dengan panjang maksimum sendiri:

Angka-angka ini terus bergeser saat platform berulang, tetapi pola umum "platform X akan menolak unggahan Anda jika melebihi Y menit" bertahan, dan merupakan salah satu alasan paling umum pengguna akhir membuka trimmer sejak awal.

Ketika editor desktop adalah alat yang lebih baik

Untuk pengguna yang trimmer browser tidak cukup, ekosistem profesional berputar di sekitar beberapa aplikasi desktop yang sudah mapan. Apple ProRes adalah keluarga codec antara yang diperkenalkan oleh Apple pada April 2007 bersama dengan Final Cut Studio 2, dirancang untuk pengeditan, bukan pengiriman. Final Cut Pro, awalnya dirilis pada 1999 oleh Macromedia dan diakuisisi oleh Apple setahun kemudian, dibangun kembali dan dirilis ulang sebagai Final Cut Pro X pada 21 Juni 2011; hanya macOS dan editor standar di banyak dunia dokumenter dan broadcast. DaVinci Resolve, awalnya sistem color-grading kelas atas, diakuisisi oleh Blackmagic Design pada 2009 dan secara progresif dibangun kembali menjadi suite editing/audio post/efek visual/grading lengkap, tersedia untuk macOS, Windows dan Linux, dengan versi dasar gratis yang telah mengubah ekonomi pasar pengeditan secara substansial. Adobe Premiere Pro adalah pemain besar ketiga dan mendominasi sebagian besar industri film dan TV. Tak satu pun dari ini yang sesuai untuk pengguna yang ingin menghapus sepuluh detik pertama dari klip yang direkam dengan telepon sebelum mempostingnya ke TikTok, yang persis celah yang diisi trimmer browser.

Mengapa "tanpa unggah" penting di sini secara khusus

Properti tunggal terpenting dari trimmer video berbasis browser adalah bahwa file tidak meninggalkan mesin pengguna. Data video dimuat dari input File langsung ke memori JavaScript, diproses oleh WebAssembly di dalam proses browser, dan hasilnya ditawarkan sebagai unduhan. Tidak ada unggah, tidak ada pihak ketiga yang dapat membaca file, tidak ada tagihan cloud yang skala dengan jumlah pengguna, tidak ada kebijakan retensi data untuk ditulis atau diaudit. Untuk konten sensitif (rapat yang direkam, rekaman pribadi, apa pun yang tidak dapat diunggah ke pihak ketiga karena alasan hukum atau kontraktual) itulah satu-satunya arsitektur yang masuk akal.

Kekurangannya adalah pengguna membayar biaya komputasi. Trimmer yang berjalan di server farm dapat me-re-encode klip 4K dalam beberapa detik karena memiliki akses ke hardware encoding GPU; operasi yang sama di FFmpeg.wasm yang berjalan dalam perangkat lunak di CPU laptop mungkin memakan waktu satu atau dua menit. Jalur Cepat (stream copy) sebagian besar menghindari ini dengan menghindari encode sepenuhnya, itulah sebabnya itu adalah default yang tepat untuk hampir setiap use case trimming kasual. Jalur Presisi (re-encode) adalah default yang tepat hanya ketika pengguna secara eksplisit memerlukan akurasi frame dengan biaya menunggu.

Lebih banyak pertanyaan

Mengapa trim Cepat saya dimulai lebih awal atau lebih lambat dari yang saya minta?

Karena mode Cepat (stream copy) hanya dapat dimulai pada keyframe (I-frame), dan keyframe terdekat sebelum awal yang diminta dapat hingga GOP penuh lebih awal, di mana saja dari 2 hingga 10 detik tergantung pada bagaimana sumbernya dikodekan. Jika Anda membutuhkan potongan pada frame tertentu, beralih ke mode Presisi, yang me-re-encode dan mendarat tepat pada frame yang dipilih dengan biaya tunggu yang lebih lama dan generasi kecil kehilangan kompresi.

Mengapa audio tidak sinkron setelah trim Cepat saya?

Biasanya karena titik potong mendarat di dalam GOP video dan frame audio pada timestamp itu tidak sejajar dengan keyframe video. Mode Cepat menggeser awal video ke keyframe terdekat tetapi mungkin membawa timestamp audio tidak berubah, menghasilkan offset. Perbaikan FFmpeg standar adalah flag -avoid_negative_ts make_zero, yang me-rebase semua timestamp sehingga yang pertama adalah nol. Jika sync kritis, mode Presisi me-resample audio untuk menyelaraskan dengan awal baru dan menghindari kelas masalah ini.

Bisakah saya mengekspor ke format yang berbeda dari input?

Untuk konversi format, alat Video Converter dibangun khusus dan mengekspos lebih banyak opsi. Trimmer dioptimalkan untuk case codec-sama, container-sama (mode Cepat sepenuhnya melestarikan encoding asli) atau untuk re-encoding ke set kecil output web-friendly dalam mode Presisi. Re-encoding selalu menelan biaya waktu CPU dan satu generasi kehilangan kualitas; jika Anda hanya perlu mengubah container tanpa me-re-encode gambar, ekuivalen ffmpeg -c copy adalah alat yang tepat.

Mengapa input AVI berfungsi tetapi output AVI tidak?

AVI mendahului sebagian besar fitur codec modern (B-frame canggung, sinkronisasi audio rapuh di atas 4 GB, format indeks terbatas), dan tooling modern umumnya memperlakukannya sebagai format input legacy saja. Input dalam AVI dibaca dengan baik; output default ke MP4 atau WebM, yang merupakan keluarga ISOBMFF/Matroska yang dipelihara secara aktif dan diputar di setiap browser dan pemain modern.

Alat terkait

Konverter video Pembuat GIF Video → teks Pemotong audio