Ik heb ooit een antwoord van veertig seconden uit een interview gesneden, het in een kaartspel laten vallen en de spreker zeven seconden voor het stukje dat ik wilde, halverwege de zin zien beginnen. Ik had de start zorgvuldig ingesteld. De trimmer had me genegeerd, althans zo zag het eruit. Het had niet gedaan: het had het enige gedaan wat een snelle snede kan doen, namelijk beginnen bij het dichtstbijzijnde sleutelframe vóór het punt waar ik om vroeg. Als je dat eenmaal weet, is het gedrag geen bug meer en wordt het een keuze met twee opties, en het kiezen van de juiste neemt een tweede.
tl;dr: Een snelle trim kopieert de bestaande videostream in plaats van deze opnieuw te coderen, en een kopie kan alleen beginnen bij een keyframe. Vraag om om 0:07 te beginnen op een bestand waarvan de keyframes tien seconden uit elkaar liggen en de snede begint om 0:00, want dat is het laatste punt waar de decoder vanaf kan beginnen. Het einde landt waar je vroeg; alleen het begin drijft, en het drijft naar achteren. De oplossing wanneer u het exacte frame nodig heeft, is om opnieuw te coderen, wat langzamer is en een beetje kwaliteit kost. de Videomaaier Biedt zowel als standaardinstellingen aan de snelle.
Waarom begint de snede eerder dan je vroeg?
Omdat bijna geen frame in een video een compleet beeld is.
Videocompressie werkt door één volledig frame op te slaan en vervolgens de wijzigingen te beschrijven. een keyframe, correct een IDR-frame in H.264, houdt een heel beeld vast en hangt van niets af. De frames nadat het verschillen vasthield: dit blok bewoog vier pixels naar links, dit gebied is ongewijzigd, deze pixels werden iets donkerder. Een frame halverwege die reeks is op zichzelf zinloos, de manier waarop een diff zinloos is zonder het bestand waarop het van toepassing is.
Dus als je vraagt om te beginnen om 0:07 en de tool de stream kopieert zonder deze te decoderen, is er niets om 0:07 om te kopiëren. Er is een beschrijving van hoe 0:07 verschilt van iets eerder. De enige plaatsen waar een speler kan beginnen zijn de keyframes, en de enige veilige is het laatste keyframe op of voor je startpunt.
Het alternatief is om de video tot 0:07 te decoderen, weg te gooien wat er eerder was en wat er overblijft te comprimeren in een nieuw bestand dat begint met een nieuw keyframe. Dat is precies, en het is het langzame pad, omdat het echt werk doet aan elk frame in plaats van bytes te kopiëren.
Hoe ver uit elkaar liggen keyframes, echt?
Verder dan de meeste mensen aannemen, en de kloof bepaalt hoe verkeerd een snel snijden eruit ziet.
Ik heb het gemeten in plaats van te raden. Codeer van dertig seconden testbeelden met x264 bij de standaardinstellingen, en vervolgens de keyframes op een rij te zetten:
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
Eén keyframe per tien seconden. Dat is de standaard van x264's standaard van 250 frames tussen keyframes, met 25 frames per seconde. Op een bestand dat is gecodeerd met die standaardinstellingen, kan een snelle trim beginnen tot tien seconden voordat het punt dat u hebt gekozen.
De meeste beelden die je behandelt, zijn vriendelijker, omdat het meeste is gemaakt voor streaming, waar spelers regelmatig toegangspunten nodig hebben om van kwaliteit te wisselen. Hier is het assortiment dat het waard is om te weten:
| Bron | Typische keyframe-gap | Worst-case drift op een snelle snit |
|---|---|---|
| telefoon opnemen | 1 tot 2 seconden | Nauwelijks merkbaar |
| Streaming video, HLS of Dash | 2 tot 6 seconden | Opvallend op een korte clip |
| x264 of ffmpeg standaard | 10 seconden bij 25 fps | verpest een kortere weg |
| Schermrecorder, lage beweging | 10 seconden of meer | verpest een kortere weg |
Het patroon: alles wat voor een speler is gecodeerd, heeft keyframes en alles wat eenmaal is gecodeerd voor opslag niet.
Wat doet de drift met het bestand?
Het beweegt het begin en laat het einde met rust, wat de moeite waard is om precies over te zijn, omdat het gemakkelijk is om aan te nemen dat het hele raam glijdt.
Dezelfde clip vragen voor 0:07 tot 0:15, een venster van acht seconden, met een stream-kopie:
| gevraagd | keyframes in bron | Resultaat | Wat is er gebeurd? |
|---|---|---|---|
| 7s tot 15s | 0, 10, 20 | 0s tot 15,08s | start viel terug naar het keyframe om 0 |
| 12s tot 20s | 0, 10, 20 | 10s tot 20.08s | Start viel terug naar het keyframe om 10 |
| 7s tot 15s | Elke 2s | 6s tot 15.08s | start viel terug één keyframe |
Het einde is in alle drie goed. Ik heb gecontroleerd dat door frames te hashen in plaats van de duur te vertrouwen: het laatste frame van de uitvoer is byte-identiek voor het bronframe op 15,04 seconden, wat het frame is na het frame waar ik om heb gevraagd en de juiste plaats om te stoppen. Wat is veranderd, is waar het begint.
Daarom is het bestand langer dan het venster dat u hebt geselecteerd. Een snee waarvan je dacht dat het acht seconden was, komt als vijftien, niet omdat er iets overtrad, maar omdat er zeven seconden aan inbraak kwam. Op een clip waar de keyframes twee seconden uit elkaar liggen, arriveert dezelfde snit als negen seconden en niemand merkt het op.
Wanneer moet u in plaats daarvan opnieuw coderen?
Drie gevallen, en daarbuiten is het snelle pad het betere hulpmiddel.
Je hebt een specifiek frame nodig. Een woord afsnijden, op een gebaar, op het moment dat een bal een knuppel raakt. De nauwkeurigheid van het keyframe is niet goed genoeg en geen enkele zorg met de schuifregelaar zal helpen, omdat de limiet in het bestand zit in plaats van in de interface.
De clip is kort. Een inloop van zeven seconden op een snit van dertig seconden is hinderlijk. Bij een snede van vier seconden is het het hele ding.
U snijdt een bestand uit met spaarzame keyframes. Schermopnames en alles wat een keer wordt geëxporteerd voor archief, zoals de bovenstaande metingen laten zien.
De kosten zijn reëel, maar kleiner dan mensen vrezen. Een hercodering decodeert elk frame in het venster en comprimeert het opnieuw, dus het kost tijd die evenredig is met de lengte van de snede in plaats van de grootte van het bestand, en het verliest een generatie kwaliteit. Bij een factor 23 met constante snelheid, wat de trimmer gebruikt voor zijn nauwkeurige modus, is dat verlies bijna onzichtbaar met één pas. Het is een tweede doorgangsbeeld dat al een keer is gecomprimeerd, wat hetzelfde is Generatieverlies dat de compressie regelt algemeen.
Hoe vind je de keyframes in je eigen bestand?
Eén commando, en het vertelt je van tevoren of het snelle pad zal werken.
# 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
Als de gaten een of twee seconden zijn, trim dan snel en stop met erover na te denken. Als ze tien zijn, en uw knipsel ertoe doet, codeert u opnieuw.
Hiervoor is een tweede gebruik. Als u beelden produceert die andere mensen zullen knippen, maakt het coderen met een korter keyframe-interval hun leven veel gemakkelijker, tegen een kleine prijs in bestandsgrootte. Een keyframe is een volledig beeld, dus meer van hen betekent meer bytes, en dat is precies waarom encoders ze opruimen als niemand om iets anders vroeg.
Verliest trimmen kwaliteit?
Het snelle pad doet dat niet, in strikte zin. Niets is gedecodeerd, dus niets wordt opnieuw gecomprimeerd: de frames in de uitvoer zijn dezelfde gecomprimeerde frames die in de invoer, byte voor byte, in een nieuwe container waren. Trim een bestand tien keer op deze manier en de tiende is qua kwaliteit identiek aan de eerste.
Het nauwkeurige pad doet dat, een keer. Het venster wordt gedecodeerd en opnieuw gecomprimeerd, dus het pikt één generatie verlies op. Op een goed gecodeerde bron bij een verstandig kwaliteitsdoel is dit moeilijk te zien, en de verstandige regel is om de bezuiniging die je nodig hebt in één keer van het origineel te maken in plaats van een trim van een trim te trimmen.
Noch pad upscale, verscherpt of verbetert iets. Een trimmer verwijdert de tijd, wat de hele klus is.
Waarom begint mijn bijgesneden clip niet onmiddellijk te spelen?
Vanwege waar de index terechtkomt, en het is dezelfde vlag die ertoe doet bij het comprimeren.
Een MP4 bevat een tabel die beschrijft waar elk frame begint. Die tabel staat in de voor de hand liggende volgorde, die tabel aan het einde van het bestand eindigt, omdat de encoder de inhoud pas kent als deze klaar is. Gespeeld vanaf een schijf, prima. Geserveerd via HTTP, kan een speler pas starten als het hele bestand is aangekomen.
De trimmer gaat voorbij -movflags +faststart, die een snelle tweede doorgang doet en die tafel naar voren verplaatst. De snede begint dan te spelen terwijl hij downloadt, wat je wilt als het bestand naar een chat-app, een CMS of een dia gaat die het uit een URL haalt.
Wat gebeurt er met de audio?
Audio wordt op zijn eigen framegrenzen geknipt, en die zijn veel korter dan video-keyframe-intervallen, zodat de audio dichter bij uw markering kan beginnen dan de afbeelding.
Die mismatch is de bron van de andere klassieke trimfout: een clip waarvan het geluid iets voor de foto ligt, of dat begint met een fragment van een woord. De fix zit in de argumenten in plaats van in de bewerking, en de trimmer geeft het door: -avoid_negative_ts make_zero Herbased de tijdstempels van beide streams, zodat de output bij nul begint met de stromen nog steeds uitgelijnd ten opzichte van elkaar. Zonder dit kan een stream-kopie negatieve tijdstempels uitzenden voor de frames tussen het keyframe en je snijpunt, en spelers zijn het er niet mee eens wat ze ermee moeten doen. Sommige slaan, sommige kraam, sommige spelen de audio vroeg af.
Als je alleen het geluid wilt, snij dan eerst de video en dan Het geluid extraheren is de verkeerde volgorde. Pak eerst uit en snijd de audio, omdat audio-uitsnijdingen frame-accuraat en goedkoop zijn.
Is het beter om de foto-app van de telefoon te trimmen?
Voor een snelle persoonlijke clip is het prima en het is er. Voor alles wat je gaat publiceren, nee, en de reden is niet duidelijk.
Telefooneditors herkennen over het algemeen opnieuw bij export, en ze doen het met instellingen die zijn gekozen voor snelheid en voor een voorspelbare bestandsgrootte in plaats van voor betrouwbaarheid. Je betaalt een generatie verlies bij elke trim. Erger nog, sommigen van hen trimmen niet-destructief, waarbij je in- en uitpunten als metadata naast het origineel worden opgeslagen, wat eruitziet als een trim op de telefoon en helemaal geen trim is zodra het bestand het verlaat: de ontvanger krijgt de volledige clip of een bewerkingslijst die zijn speler negeert.
Een kopieermodus trim voorkomt beide problemen. Het bestand dat je krijgt is het bestand dat iedereen krijgt, en de frames erin zijn nooit gedecodeerd.
Verlaat de video mijn machine?
heel weinig . De snede loopt door FFMPEG gecompileerd voor Webassembly Binnen het tabblad Browser: het bestand wordt gelezen van schijf in het paginageheugen, daar bijgesneden en teruggegeven als download. Het netwerkpaneel in DevTools blijft leeg van de video terwijl dit gebeurt.
Voor beeldmateriaal is dat belangrijker dan voor de meeste bestandstypen. Een clip is meestal het grootste en meest persoonlijke dat iemand bewerkt, en de normale regeling voor een gratis online trimmer is dat je je beeldmateriaal uploadt naar een vreemde en vertrouwt op het bewaarbeleid op een pagina die je niet hebt gelezen. Hier is geen exemplaar om te bewaren.
De limieten zijn de tabs in plaats van een plan: een enkele snede is beperkt tot dertig minuten en de hele bron moet in het browsergeheugen passen. Voorbij is een desktoptool zowel sneller als betrouwbaarder, en zeggen dat het beter is dan je een tabblad te geven dat op minuut negen geen geheugen meer heeft.
Wanneer is een desktop-editor de juiste tool?
Wanneer u meer doet dan het verwijderen van tijd. Voeg verschillende clips toe, voeg titels, kleur, muziek toe of knippen op een golfvorm die je op sampleniveau moet zien. Dat is een bewerkingstijdlijn, geen trimmer, en het juiste antwoord is een echte editor.
Binnen de browser is de scheidslijn bijna net zo schoon. Het verwijderen van één rek uit één clip is een trim. Het samenvoegen van stukken is de Video-editor. Het resultaat kleiner maken is de compressor, en het wijzigen van de container of codec is de bekeerder, dat is een Verschillende bediening van compressie Ook al raken de twee constant in de war.
Waarom zijn de preview en het geëxporteerde bestand het daar niet mee eens?
Omdat een triminterface hetzelfde nummer verzamelt van drie plaatsen die het niet eens zijn over wat een getal is, en het op één waarde krijgen is het meeste werk in een trimmer.
Een tekstveld geeft je wat iemand heeft getypt, wat zou kunnen zijn 7, 0:07, 00:00:07 of 7.25. Een slider geeft een vlotter met meer precisie dan iemand wil. Een video-element's currentTime Geeft nog een float, wat niet noodzakelijk het tijdstempel van een frame is: browsers mogen een positie tussen frames rapporteren, en dat doen ze ook.
Als die drie op iets verschillende seconden terechtkomen, laat het voorbeeld het ene zien en de export produceert het andere, wat de specifieke bug is die een trimmer doet aanvoelen, zelfs als de snede correct is. De parser hier accepteert alle drie de tijdcodevormen, lost ze op, zodat het laatste deel altijd seconden is, ongeacht de lengte, en geeft een enkele waarde aan zowel het voorbeeld als de export. Een half getypt veld retourneert niets in plaats van gooien, zodat de invoer niet ontploft op elke toetsaanslag terwijl u typt 0:0.
Het praktische advies: typ de tijdcode in plaats van slepen, wanneer de exacte tweede er toe doet. Een slider is om het moment te vinden, een veld is om het te benoemen.
Hoe knip ik een gedeelte uit het midden?
Twee sneden en een join, en geen enkele trimmer doet het in één stap, wat mensen redelijk vaak verrast.
Het verwijderen van het midden van een clip betekent dat het onderdeel vóór uw selectie en het deel ernaast, wat twee afzonderlijke vensters zijn, houdt en ze vervolgens weer in elkaar zet. De trimmer produceert hier één venster per run, dus de volgorde is: trim vanaf het begin tot het begin van het slechte gedeelte, trim vanaf het einde van het slechte gedeelte tot het einde en voeg dan de twee samen in de Video-editor.
Twee dingen om naar te kijken als je dat doet. De join werkt netjes wanneer beide stukken een codec, een resolutie en een framesnelheid delen, wat ze zullen doen als beide uit hetzelfde bronbestand kwamen via kopieermodusversieringen. En de naad landt aan beide kanten op een keyframegrens, dus het tweede stuk begint iets eerder dan je hebt gemarkeerd, precies zoals hierboven beschreven. Als het snijpunt van belang is, gebruik dan de nauwkeurige modus voor het tweede stuk.
De andere optie is om te stoppen voordat je begint: als wat je wilt een hoogtepunt is in plaats van een redactie, zijn twee afzonderlijke clips vaak nuttiger dan één clip met een opening die eruit is gestikt.
