Tagliatore video

Taglia file video impostando l'inizio e la fine. Modalità rapida o precisa.

I tuoi file non lasciano mai il tuo dispositivo

Trascina e rilascia qui un file video

o clicca per sfogliare · MP4, WebM, MOV, AVI, MKV (max 2 GB)

Come funziona

  1. Carica un file video: seleziona qualsiasi file MP4, WebM, MOV o AVI dal tuo dispositivo, nessun invio a un server.
  2. Imposta i punti di taglio: usa le maniglie della timeline o inserisci orari precisi di inizio e fine per definire il clip da conservare.
  3. Visualizza l'anteprima del taglio: riproduci il segmento selezionato per confermare il taglio prima dell'esportazione.
  4. Scarica il clip: esporta il video tagliato direttamente sul tuo dispositivo nel formato originale.

Perché usare il taglierino video?

La maggior parte delle applicazioni di editing video richiede un'installazione, un abbonamento o un invio a server cloud. Questo taglierino basato su browser elabora il video interamente sul tuo dispositivo tramite WebCodecs e FFmpeg.wasm, i tuoi filmati non lasciano mai la tua macchina. È ideale per tagliare rapidamente intro e outro, isolare clip per i social network, rimuovere segmenti indesiderati da una registrazione e tagliare prima della condivisione. Nessuna perdita di qualità per ricodifica a meno che tu non scelga un formato di uscita diverso, e nessun limite di dimensione oltre la memoria disponibile del tuo dispositivo.

Formati supportati

Cut, trim, split, e perché le parole contano

Nel linguaggio comune "trim", "cut" e "split" sono intercambiabili. Negli strumenti video descrivono tre operazioni diverse. Un trim rimuove contenuto dall'inizio e/o dalla fine e mantiene tutto al centro. Un cut nella terminologia editoriale è il confine tra due inquadrature adiacenti in un montaggio finito. Uno split prende una clip e la divide in due clip a un punto scelto. Dal punto di vista dell'utente, questo strumento esegue un trim, imposti un inizio e una fine, e mantiene quello che c'è tra di loro.

La domanda interessante è come rimuove i byte indesiderati. Due approcci fondamentalmente diversi producono file diversi.

Veloce (stream copy) vs Preciso (ricodifica)

Stream copy, la modalità "Veloce", non guarda affatto l'immagine. Apre il container, trova gli intervalli di byte che corrispondono alla finestra temporale richiesta, copia quei byte verbatim in un nuovo container, sistema l'indice e i timestamp, e scrive il risultato. Non c'è decodifica, nessuna ricodifica, nessuna perdita di qualità. Su una macchina moderna un file H.264 da 500 MB può essere ritagliato in questo modo in ben meno di un secondo perché il lavoro è essenzialmente I/O su file, non aritmetica. La fregatura: l'operazione di copia può iniziare e finire solo su certi frame, specificamente I-frame: e quelli non sono necessariamente dove hai puntato. Quindi l'inizio della clip risultante può spostarsi avanti o indietro di qualunque cosa tra zero e dieci secondi, a seconda delle impostazioni del codec usate quando il file è stato originariamente codificato.

La modalità ricodifica, "Preciso", decodifica l'intera sezione interessata in pixel grezzi, scarta i frame prima dell'inizio richiesto e dopo la fine richiesta, poi ricodifica il resto. Questo produce una clip che inizia e finisce esattamente al frame scelto (frame-accurate, in terminologia industriale) al costo di una codifica completa. Una codifica completa è centinaia o migliaia di volte più lenta di una stream copy e introduce una generazione di perdita di compressione perché i codec lossy non sono idempotenti: codificare, decodificare, e ricodificare la stessa immagine non ti restituisce esattamente la stessa immagine. La perdita è piccola a bitrate alti ma è non-zero, e si accumula se lo stesso file viene ritagliato ripetutamente.

Il percorso Veloce è corretto per il 95% dei casi dove l'utente sta rimuovendo intro, outro, o materiale grezzo di testa e coda e non gli importa se il taglio è mezzo secondo da dove ha puntato. Il percorso Preciso è lo strumento giusto quando il taglio deve atterrare su uno specifico frame, una battuta, un effetto sonoro, un punto di sync per un montaggio a valle.

I-frame, P-frame, B-frame, e il GOP

Ogni codec video moderno (H.264, H.265 (HEVC), VP9, AV1) comprime il video sfruttando il fatto che frame consecutivi sono quasi la stessa immagine. Piuttosto che codificare ogni frame indipendentemente, il codec codifica una piccola frazione di frame completi e il resto come differenze dai loro vicini. I frame completi sono I-frame (intra-coded). I frame di differenza vengono in due varietà: P-frame (predetti solo da frame precedenti) e B-frame (codificati bi-predittivamente, possono fare riferimento sia a frame precedenti che successivi). La sequenza I, poi una serie di frame P e B, poi un altro I, è chiamata Group of Pictures, o GOP. Dentro un GOP, nessun frame può essere decodificato senza riferimento all'I-frame all'inizio. Tra GOP non c'è dipendenza: un player può entrare nel file a qualsiasi I-frame e iniziare a decodificare da lì.

Questo è il motivo per cui il trim stream-copy è vincolato ai confini di keyframe. Per iniziare un nuovo file a un frame non-I dovresti decodificare l'I-frame all'inizio del GOP, poi decodificare ogni frame P e B fino al punto scelto, poi iniziare a scrivere, che è esattamente quello che fa il percorso Preciso. Un tipico file H.264 usa una lunghezza GOP di due a quattro secondi. libx264 di FFmpeg ha come default circa 250 frame (~10 secondi a 25 fps, ~8.3 secondi a 30 fps). I provider di streaming accorciano questo a due secondi per allinearsi con i confini dei segmenti HLS e DASH. H.265 tollera GOP più lunghi più efficientemente ed è spesso configurato a quattro-dieci secondi. VP9 (libvpx) ha come default una distanza massima keyframe di 240 frame. AV1 tipicamente atterra nell'intervallo 2-6 secondi. L'implicazione pratica: un utente che chiede un taglio al minuto 1 secondo 30 può, a seconda di con cosa il file è stato originariamente codificato, finire con un risultato stream-copy che inizia ovunque tra il minuto 1 secondo 24 e il minuto 1 secondo 32.

Una breve storia di FFmpeg

FFmpeg è stato iniziato il 20 dicembre 2000 da Fabrice Bellard, lo scienziato informatico francese che aveva precedentemente scritto il virtualizzatore QEMU e il compilatore C TCC. Ha committato sotto lo pseudonimo Gérard Lantau. Il nome viene da "FF" per fast forward e "mpeg" per la famiglia di codec che era originariamente progettato per gestire. L'architettura fin dall'inizio ha separato l'implementazione del codec (libavcodec) dal parsing del container (libavformat), che è il motivo per cui FFmpeg è stato così facilmente esteso nel corso degli anni. Bellard ha consegnato la manutenzione a Michael Niedermayer nel 2004. Il progetto è sopravvissuto a un fork celebrato nel 2011 quando un gruppo di sviluppatori si è separato in un progetto chiamato Libav per disaccordi sulla governance; i due progetti si sono ri-fusi nello spirito (se non formalmente) entro il 2018, con la maggior parte dei miglioramenti di Libav riportati upstream in FFmpeg.

Oggi FFmpeg è l'infrastruttura silenziosa sotto un'enorme frazione del video del mondo, YouTube, Netflix, VLC, OBS Studio, Audacity, HandBrake, Plex, e la maggior parte delle pipeline di broadcast professionale lo usano da qualche parte nel loro stack. L'attuale rilascio stabile al 2026 è nella serie 8.x. La licenza è dual LGPL-2.1-or-later o GPL-2.0-or-later a seconda di quali componenti opzionali sono abilitati al momento della compilazione.

FFmpeg.wasm, FFmpeg nel browser

Nel novembre 2020 un ingegnere taiwanese di nome Jerome Wu: già conosciuto per il port Tesseract.js del motore OCR Tesseract, ha pubblicato il primo rilascio di FFmpeg.wasm, una compilazione WebAssembly di FFmpeg che gira interamente dentro il browser. Ha annunciato il progetto il 4 novembre 2020. Entro il 2026 il progetto è maturato significativamente, con l'attuale rilascio nella serie 0.12 e fork attivi della community. Il pacchetto npm ora include il binary WebAssembly core, un wrapper JavaScript che gestisce il passaggio di messaggi tra il thread principale e il thread worker che esegue il WASM, e un file system virtuale che permette all'utente di muovere file dentro e fuori usando ordinari oggetti Blob e File JavaScript.

Il progetto ha un requisito notorio che cattura ogni sviluppatore che prova a deployarlo per la prima volta. FFmpeg.wasm usa SharedArrayBuffer, l'API JavaScript per condividere memoria tra il thread principale e i thread worker. Dopo che le vulnerabilità Spectre e Meltdown della CPU sono state divulgate nel 2018, i browser hanno stretto le condizioni: la pagina deve essere servita con due header HTTP specifici, Cross-Origin-Opener-Policy: same-origin e Cross-Origin-Embedder-Policy: require-corp, e ogni risorsa cross-origin sulla pagina deve o optare tramite CORS o venire dalla stessa origine. Senza quegli header, SharedArrayBuffer è undefined e FFmpeg.wasm non si inizializza. Chrome impone questo strettamente; Firefox ed Edge seguono Chrome; Safari si è unito dalla versione 15.2 in poi.

Formati container

Un container è il wrapper del file. Non codifica l'immagine; impacchetta immagini e audio codificati insieme con timing e metadati.

API video del browser, cosa è effettivamente disponibile

L'elemento HTML5 è diventato W3C Recommendation il 28 ottobre 2014, dopo circa un decennio di sviluppo. Prima di HTML5, incorporare video significava Adobe Flash o Microsoft Silverlight. L'elemento da solo non ha API di editing, non c'è metodo video.trim(start, end), nessun video.cut(), nessun modo integrato per estrarre un segmento. Per fare qualsiasi cosa oltre play, pause e seek, lo sviluppatore deve rivolgersi a un'API di livello più basso o compilare FFmpeg nella pagina.

Media Source Extensions (MSE) è una specifica W3C che permette a JavaScript di costruire il byte stream che alimenta l'elemento . Ha raggiunto Candidate Recommendation nel 2014; usato in produzione da YouTube già dal settembre 2013 e da Netflix dal giugno 2014. Il suo caso d'uso primario è lo streaming adattivo (non espone i frame decodificati, quindi non può eseguire una ricodifica da solo. WebCodecs è l'alternativa di livello più basso) espone le implementazioni di codec video e audio integrate del browser direttamente a JavaScript, con interfacce VideoDecoder e VideoEncoder. WebCodecs è arrivato ufficialmente in Chrome 94 il 21 settembre 2021 dopo una origin trial in Chrome 93, e da allora ha raggiunto Firefox e Safari. Lo stato dell'arte attuale è che gli strumenti usino WebCodecs quando è disponibile e il codec è supportato, e ricadano su FFmpeg.wasm altrimenti. Questo strumento usa entrambi.

Limiti di lunghezza delle piattaforme social, perché la gente apre i trimmer

Una grande parte della domanda di trim basato su browser viene dalla preparazione di video per l'upload su piattaforme social, ognuna con la propria lunghezza massima:

Questi numeri cambiano costantemente man mano che le piattaforme iterano, ma il pattern generale di "la piattaforma X rifiuterà il tuo upload se supera Y minuti" è duraturo, ed è una delle ragioni più comuni per cui un utente finale apre un trimmer in primo luogo.

Quando un editor desktop è lo strumento migliore

Per gli utenti per i quali un trimmer browser è insufficiente, l'ecosistema professionale ruota attorno a qualche applicazione desktop affermata. Apple ProRes è una famiglia di codec intermedi introdotta da Apple nell'aprile 2007 insieme a Final Cut Studio 2, progettata per l'editing, non per la consegna. Final Cut Pro, originariamente rilasciato nel 1999 da Macromedia e acquisito da Apple un anno dopo, è stato ricostruito e ri-rilasciato come Final Cut Pro X il 21 giugno 2011; solo macOS e l'editor standard in gran parte del mondo del documentario e del broadcast. DaVinci Resolve, originariamente un sistema di color-grading di fascia alta, è stato acquisito da Blackmagic Design nel 2009 e progressivamente ricostruito in una suite completa di editing/audio post/effetti visivi/grading, disponibile per macOS, Windows e Linux, con una versione base gratuita che ha cambiato sostanzialmente l'economia del mercato dell'editing. Adobe Premiere Pro è il terzo grande giocatore e domina gran parte dell'industria del cinema e della TV. Nessuno di questi è appropriato per l'utente che vuole rimuovere i primi dieci secondi da una clip registrata col telefono prima di postarla su TikTok, che è esattamente il gap che un trimmer browser riempie.

Perché "no upload" conta qui specificamente

La singola proprietà più importante di un trimmer video basato su browser è che il file non lascia la macchina dell'utente. I dati video vengono caricati da un input File direttamente nella memoria JavaScript, processati da WebAssembly dentro il processo del browser, e il risultato è offerto come download. Non c'è upload, nessuna terza parte che può leggere il file, nessuna bolletta cloud che scala con il numero di utenti, nessuna policy di data retention da scrivere o auditare. Per contenuti sensibili (meeting registrati, riprese personali, qualsiasi cosa che non potrebbe essere caricata a una terza parte per ragioni legali o contrattuali) quella è l'unica architettura che ha senso.

Lo svantaggio è che l'utente paga il costo computazionale. Un trimmer che gira su un server farm può ricodificare una clip 4K in pochi secondi perché ha accesso a hardware di codifica GPU; la stessa operazione in FFmpeg.wasm che gira in software su una CPU laptop può richiedere uno o due minuti. Il percorso Veloce (stream copy) elude in gran parte questo evitando del tutto la codifica, che è il motivo per cui è il default giusto per quasi ogni caso d'uso di trim casuale. Il percorso Preciso (ricodifica) è il default giusto solo quando l'utente ha esplicitamente bisogno di precisione frame al costo dell'attesa.

Altre domande

Perché il mio trim Veloce sta iniziando prima o dopo di quanto ho richiesto?

Perché la modalità Veloce (stream copy) può iniziare solo su un keyframe (I-frame), e il keyframe più vicino prima del tuo inizio richiesto può essere fino a un GOP completo prima, ovunque da 2 a 10 secondi a seconda di come è stata codificata la sorgente. Se hai bisogno del taglio a uno specifico frame, passa alla modalità Precisa, che ricodifica e atterra esattamente al frame scelto al costo di un'attesa più lunga e una piccola generazione di perdita di compressione.

Perché l'audio è fuori sync dopo il mio trim Veloce?

Solitamente perché il punto di taglio è atterrato dentro un GOP video e il frame audio a quel timestamp non si allinea con un keyframe video. La modalità Veloce sposta l'inizio del video al keyframe più vicino ma può portare i timestamp audio invariati, producendo un offset. La correzione FFmpeg standard è il flag -avoid_negative_ts make_zero, che ribasa tutti i timestamp così il primo è zero. Se la sync è critica, la modalità Precisa ricampiona l'audio per allinearsi con il nuovo inizio ed evita questa classe di problema.

Posso esportare in un formato diverso dall'input?

Per la conversione di formato, lo strumento Video Converter è costruito apposta ed espone più opzioni. Il trimmer è ottimizzato per il caso stesso-codec, stesso-container (la modalità Veloce preserva la codifica originale interamente) o per la ricodifica a un piccolo set di output web-friendly in modalità Precisa. La ricodifica costa sempre tempo CPU e una generazione di perdita di qualità; se hai bisogno solo di cambiare il container senza ricodificare l'immagine, un equivalente ffmpeg -c copy è lo strumento giusto.

Perché l'input AVI funziona ma l'output AVI no?

AVI precede la maggior parte delle feature dei codec moderni (i B-frame sono goffi, la sync audio è fragile oltre i 4 GB, il formato dell'indice è limitato), e il tooling moderno generalmente lo tratta come formato di input legacy solo. Gli input in AVI vengono letti bene; gli output ricadono di default su MP4 o WebM, che sono le famiglie ISOBMFF/Matroska attivamente mantenute e si riproducono in ogni browser e player moderno.

Strumenti correlati

Convertitore video Creatore di GIF Video → testo Taglierino audio