Una volta ho interrotto una risposta di quaranta secondi da un'intervista, l'ho lasciata in un mazzo e ho visto l'altoparlante iniziare a metà frase sette secondi prima del bit che volevo. Avevo impostato l'inizio con attenzione. Il trimmer mi aveva ignorato, o almeno così sembrava. Non l'aveva fatto: aveva fatto l'unica cosa che un taglio veloce può fare, che è iniziare dal fotogramma chiave più vicino prima del punto che ho chiesto. Una volta che lo sai, il comportamento smette di essere un bug e diventa una scelta con due opzioni, e scegliere quello giusto richiede un secondo.
tl; dr: Un taglio veloce copia il flusso video esistente anziché ricodificarlo e una copia può iniziare solo da un fotogramma chiave. Chiedi di iniziare alle 0:07 su un file i cui fotogrammi chiave sono a dieci secondi di distanza e il taglio inizia alle 0:00, perché quello è l'ultimo punto da cui può partire il decoder. La fine atterra dove hai chiesto, solo l'inizio va alla deriva e si sposta all'indietro. La soluzione quando hai bisogno del frame esatto è ricodificare, che è più lento e costa un po' di qualità. la videosaccolo Offre entrambi e predefiniti su quello veloce.
Perché il taglio inizia prima di quanto hai chiesto?
Perché quasi nessun fotogramma in un video è un quadro completo.
La compressione video funziona memorizzando un full frame e quindi descrivendo le modifiche. un fotogramma chiave, propriamente un frame IDR H.264, detiene un'intera immagine e non dipende dal nulla. I fotogrammi dopo aver mantenuto le differenze: questo blocco si è spostato di quattro pixel a sinistra, questa regione è invariata, questi pixel sono diventati leggermente più scuri. Un fotogramma a metà di quella sequenza non ha senso di per sé, il modo in cui un differenziale non ha significato senza il file a cui si applica.
Quindi, quando chiedi di iniziare alle 0:07 e lo strumento copia il flusso senza decodificarlo, non c'è nulla a 0:07 da copiare. C'è una descrizione di come 0:07 differisce da qualcosa di precedente. Gli unici posti in cui un giocatore può iniziare sono i fotogrammi chiave e l'unico sicuro è l'ultimo fotogramma chiave al o prima del punto di partenza.
L'alternativa è decodificare il video fino a 0:07, buttare via ciò che è venuto prima e comprimere ciò che rimane in un nuovo file che inizia con un nuovo keyframe. Questo è esatto, ed è il percorso lento, perché fa un vero lavoro su ogni frame piuttosto che copiare byte.
Quanto sono distanti i fotogrammi chiave, davvero?
Più lontano di quanto la maggior parte delle persone presupponga, e il divario è ciò che decide quanto sia sbagliato un taglio veloce.
L'ho misurato piuttosto che indovinare. Codifica di trenta secondi di filmati di prova con x264 ai valori predefiniti, quindi elencando i fotogrammi chiave:
ffmpeg -f lavfi -i "testsrc=duration=30:size=640x360:rate=25" -c:v libx264 clip.mp4
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 clip.mp4 \
| awk -F, '$2 ~ /K/ {print $1}'
# 0.000000
# 10.000000
# 20.000000
un fotogramma chiave ogni dieci secondi. Questo è l'impostazione predefinita di x264 di 250 fotogrammi tra i fotogrammi chiave, a 25 fotogrammi al secondo. Su un file codificato con quelle impostazioni predefinite, un assetto veloce può iniziare fino a dieci secondi prima del punto selezionato.
La maggior parte dei filmati che gestisci è più amichevole, perché la maggior parte è stata realizzata per lo streaming, in cui i giocatori hanno bisogno di frequenti punti di ingresso per cambiare la qualità. Ecco la gamma che vale la pena conoscere:
| Fonte | Tipico divario tra i fotogrammi | Deriva peggiore su un taglio veloce |
|---|---|---|
| registrazione telefonica | da 1 a 2 secondi | appena percettibile |
| Streaming video, HLS o Dash | Da 2 a 6 secondi | evidente su una breve clip |
| predefinite x264 o ffmpeg | 10 secondi a 25 fps | rovina una scorciatoia |
| Registratore dello schermo, movimento basso | 10 secondi o più | rovina una scorciatoia |
Il modello: qualsiasi cosa codificata per un giocatore ha fotogrammi chiave chiusi e qualsiasi cosa codificata una volta per l'archiviazione no.
Cosa fa la deriva sul file?
Sposta l'inizio e lascia da solo, il che vale la pena essere precisi perché è facile presumere che l'intera finestra scivoli.
Chiedere la stessa clip per 0:07 a 0:15, una finestra di otto secondi, con una copia del flusso:
| richiesto | fotogrammi chiave nella fonte | Risultato | COSA È SUCCESS |
|---|---|---|---|
| dai 7 ai 15 secondi | 0, 10, 20 | Dalle 0 al 15.08s | inizia a tornare al fotogramma chiave a 0 |
| dai 12 ai 20 anni | 0, 10, 20 | 10-20.08s | iniziare a tornare al fotogramma chiave a 10 |
| dai 7 ai 15 secondi | Ogni 2s | Dal 6 al 15.08s | Inizia Ripiegato di un fotogramma chiave |
La fine è giusta in tutti e tre. L'ho verificato aggiustando i frame anziché confidando nella durata: l'ultimo frame dell'output è identico al byte rispetto al frame di origine a 15,04 secondi, che è il frame dopo quello che ho chiesto e il posto corretto per fermarsi. Ciò che è cambiato è dove inizia.
Ecco perché il file è più lungo della finestra selezionata. Un taglio che pensavi fosse di otto secondi arriva a quindici, non perché qualcosa invaso, ma perché è arrivato sette secondi di vantaggio. In una clip in cui i fotogrammi chiave sono a due secondi di distanza, arriva lo stesso taglio di nove secondi e nessuno se ne accorge.
Quando invece dovresti ricodificare?
Tre casi, e al di fuori di essi il percorso veloce è lo strumento migliore.
Hai bisogno di una cornice specifica. Tagliando una parola, su un gesto, sul momento una palla colpisce una mazza. La precisione del keyframe non è sufficiente e nessuna cura con il cursore aiuterà, perché il limite è nel file anziché nell'interfaccia.
La clip è breve. Un vantaggio di sette secondi su un taglio di trenta secondi è una seccatura. Su un taglio di quattro secondi è tutto.
Stai ritagliando un file con fotogrammi chiave sparsi. Registrazioni dello schermo e qualsiasi cosa esportata una volta per l'archivio, come mostrano le misurazioni sopra.
Il costo è reale ma più piccolo di quanto la gente temo. Una ricodifica decodifica ogni fotogramma della finestra e lo comprime di nuovo, quindi richiede tempo proporzionale alla lunghezza del taglio anziché alle dimensioni del file e perde una generazione di qualità. Ad un fattore di velocità costante di 23, che è ciò che il trimmer utilizza per la sua modalità accurata, quella perdita è quasi invisibile su un passaggio. è un secondo passaggio su filmato che è già stato compresso una volta, che è lo stesso Perdita di generazione che governa la compressione In genere.
Come trovi i fotogrammi chiave nel tuo file?
un comando e ti dice in anticipo se il percorso veloce andrà bene.
# the first ten keyframe timestamps, in seconds
ffprobe -select_streams v -show_entries packet=pts_time,flags -of csv=p=0 input.mp4 \
| awk -F, '$2 ~ /K/ {print $1}' | head -10
Se gli spazi vuoti sono uno o due secondi, taglia velocemente e smetti di pensarci. Se sono dieci, e il tuo taglio è importante, ricodifica.
C'è un secondo uso per questo. Se stai producendo filmati che altre persone taglieranno, la codifica con un intervallo di fotogrammi chiave più breve rende la loro vita molto più semplice, a un costo ridotto in termini di file. Un fotogramma chiave è un'immagine completa, quindi più di loro significano più byte, motivo per cui gli encoder li distanziano quando nessuno ha chiesto nient'altro.
Il taglio perde qualità?
Il percorso veloce non lo fa, in senso stretto. Nulla viene decodificato, quindi nulla viene ricompresso: i frame nell'output sono gli stessi frame compressi che erano nell'input, byte per byte, in un nuovo contenitore. Taglia un file dieci volte in questo modo e il decimo è identico in qualità al primo.
Il percorso accurato lo fa, una volta. La finestra viene decodificata e compressa di nuovo, quindi raccoglie una generazione di perdite. Su una sorgente ben codificata a un obiettivo di qualità ragionevole, questo è difficile da vedere e la regola ragionevole è quella di effettuare il taglio di cui hai bisogno in un passaggio dall'originale piuttosto che tagliare un taglio di un assetto.
Nessuno dei due percorsi aumenta, affina o migliora qualsiasi cosa. Un trimmer rimuove il tempo, che è l'intero lavoro.
Perché la mia clip tagliata non inizia a suonare immediatamente?
A causa di dove atterra l'indice, ed è lo stesso flag che conta durante la compressione.
Un MP4 contiene una tabella che descrive dove inizia ogni fotogramma. Scritto nell'ordine ovvio, quella tabella finisce alla fine del file, perché l'encoder ne conosce il contenuto solo quando ha finito. riprodotto da un disco, bene. Servito su HTTP, un giocatore non può iniziare fino all'arrivo dell'intero file.
Il trimmer passa -movflags +faststart, che fa un secondo passaggio veloce e sposta quel tavolo in primo piano. Il taglio inizia quindi a riprodurlo durante il download, che è quello che vuoi quando il file entra in un'app di chat, un CMS o una diapositiva che lo estrae da un URL.
Cosa succede all'audio?
L'audio viene tagliato sui propri limiti del frame e quelli sono molto più brevi degli intervalli di fotogrammi chiave video, quindi l'audio può iniziare più vicino al tuo segno rispetto all'immagine.
Quella discrepanza è la fonte dell'altro classico errore di taglio: una clip il cui suono è leggermente più avanti dell'immagine, o che inizia con un frammento di parola. La correzione è negli argomenti anziché nell'editing e il trimmer lo supera: -avoid_negative_ts make_zero Ribasa i timestamp di entrambi i flussi in modo che l'output inizi a zero con i flussi ancora allineati l'uno all'altro. Senza di essa, una copia del flusso può emettere timestamp negativi per i frame tra il fotogramma chiave e il punto di taglio, e i giocatori non sono d'accordo su cosa fare con quelli. Alcuni saltano, altri si bloccano, altri riproducono l'audio in anticipo.
Se vuoi solo il suono, tagliando prima il video e poi Estrazione dell'audio è l'ordine sbagliato. Estrai prima e taglia l'audio, perché i tagli audio sono precisi per la cornice ed economici.
È meglio tagliare l'app per foto del telefono?
Per una rapida clip personale, va bene ed è proprio lì. Per qualsiasi cosa pubblicherai, no, e il motivo non è ovvio.
Gli editor telefonici generalmente ricodificano all'esportazione e lo fanno con le impostazioni scelte per la velocità e per una dimensione del file prevedibile piuttosto che per fedeltà. Paghi una generazione di perdite ad ogni assetto. Peggio ancora, alcuni di loro ritagliano in modo non distruttivo, memorizzando i tuoi punti di inserimento come metadati accanto all'originale, che sembra un assetto sul telefono e non è affatto un taglio una volta che il file lo lascia: il destinatario ottiene la clip completa o un elenco di modifiche che il suo giocatore ignora.
Un trim in modalità copia evita entrambi i problemi. Il file che ottieni è il file che tutti ottengono e i frame in esso non sono mai stati decodificato.
Il video lascia la mia macchina?
no . Il taglio scorre FFmpeg compilato in WebAssembly All'interno della scheda del browser: il file viene letto da disco in memoria di pagina, tagliato lì e restituito come download. Il pannello di rete in DevTools rimane vuoto del video mentre ciò accade.
Per i filmati, questo conta più che per la maggior parte dei tipi di file. Una clip è solitamente la cosa più grande e personale che chiunque modifica e la normale disposizione per un trimmer online gratuito è che carichi il tuo filmato su uno sconosciuto e ti fidi della politica di conservazione su una pagina che non hai letto. Qui non esiste una copia da conservare.
I limiti sono le schede anziché un piano: un singolo taglio viene limitato a trenta minuti e l'intera sorgente deve adattarsi alla memoria del browser. Oltre a ciò, uno strumento desktop è sia più veloce che più affidabile, e dirlo è meglio che porgerti una scheda che esaurisce la memoria al nono minuto.
Quando un editor desktop è lo strumento giusto?
Quando stai facendo di più che rimuovere il tempo. Partecipazione a diverse clip, aggiunta di titoli, colori, musica o taglio su una forma d'onda che devi vedere a livello di campione. Questa è una sequenza temporale di editing, non un trimmer, e la risposta giusta è un vero editore.
All'interno del browser, la linea di divisione è quasi altrettanto pulita. Rimuovere un tratto da una clip è un taglio. unire i pezzi insieme è il videorenante. Ridurre il risultato è il compressore, e la modifica del contenitore o del codec è il convertitore, che è un Operazione diversa dalla compressione Anche se i due si confondono costantemente.
Perché l'anteprima e il file esportato non sono d'accordo?
Perché un'interfaccia di trim raccoglie lo stesso numero da tre posizioni che non concordano su cosa sia un numero e portarli su un valore è la maggior parte del lavoro in un trimmer.
Un campo di testo ti dà qualunque cosa qualcuno abbia digitato, che potrebbe essere 7, 0:07, 00:00:07 oppure 7.25. Un cursore fornisce un galleggiante con più precisione di quanto chiunque voglia. un elemento video currentTime Fornisce un altro float, che non è necessariamente il timestamp di un frame: i browser possono segnalare una posizione tra i frame, e lo fanno.
Se quei tre atterrano in secondi leggermente diversi, l'anteprima mostra una cosa e l'esportazione ne produce un'altra, che è il bug specifico che fa sentire un trimmer rotto anche quando il taglio è corretto. Il parser qui accetta tutte e tre le forme del timecode, le risolve in modo allineato a destra in modo che l'ultima parte sia sempre secondi qualunque sia la lunghezza e porge un valore singolo sia all'anteprima che all'esportazione. Un campo a metà digitato non restituisce nulla invece di lanciare, quindi l'input non esplode su ogni battitura durante la digitazione 0:0.
Il consiglio pratico: digitare il timecode anziché trascinare, quando il secondo esatto conta. Un cursore serve per trovare il momento, un campo serve per nominarlo.
Come faccio a tagliare una sezione fuori dal centro?
Due tagli e un join, e nessun trimmer lo fa in un unico passaggio, il che sorprende le persone ragionevolmente spesso.
Rimuovere il centro di una clip significa tenere la parte prima della selezione e la parte dopo di essa, che è due finestre separate, quindi rimontarle. Il trimmer qui produce una finestra per corsa, quindi la sequenza è: Trim dall'inizio all'inizio della sezione difettosa, taglia dalla fine della sezione difettosa alla fine, quindi unisci i due nel videorenante.
Due cose da guardare quando lo fai. Il join funziona in modo pulito quando entrambi i pezzi condividono un codec, una risoluzione e un frame rate, che proverranno entrambi dallo stesso file di origine tramite trim in modalità copia. E la cucitura atterra su un confine del fotogramma chiave su entrambi i lati, quindi il secondo pezzo inizia leggermente prima di quanto hai contrassegnato, esattamente come descritto sopra. Se il punto di taglio è importante, utilizzare la modalità accurata per il secondo pezzo.
L'altra opzione è fermarsi prima di iniziare: se quello che vuoi è un punto culminante piuttosto che una redazione, due clip separate sono spesso più utili di una clip con uno spazio cucito fuori.
