Het plaatsen van twee videobestanden van begin tot eind klinkt als de goedkoopste operatie ter wereld, en ongeveer vijf minuten geloofde ik het. Daarna sloot ik me aan bij een clip van 1280x720 bij 30 fps tot een clip van 640x480 bij 25 fps met behulp van de snelste beschikbare methode, die de streams kopieert en niets herschrijft. Het heeft een bestand geproduceerd. Het bestand beweerde elf komma negen zes seconden lang te zijn, wanneer de twee clips optellen tot elf, de container zei 1280x720, terwijl de tweede helft van de stroom 640x480 was, en de muxer drukte een waarschuwing over herschreven tijdstempels voor elk frame van de tweede clip. Alles over het deelnemen aan video volgt uit waarom dat gebeurt.
tl;dr: De goedkope join werkt alleen als beide bestanden het al eens zijn over codec, resolutie, framesnelheid en tijdbasis, wat beelden van twee apparaten dat nooit doen. De eerlijke route decodeert beide en codeert één nieuw bestand, dat langzamer is en iets produceert dat speelt. Hier gemeten: de kopieermethode rapporteerde 11,996 seconden gedurende 11 seconden aan beeldmateriaal en verklaarde de verkeerde resolutie; de re-codering produceerde precies 11.000 seconden met een enkele consistente 1280x720 in 0,63 seconden. Clips van verschillende afmetingen moeten eerst in één frame worden gemonteerd, of de verbinding wordt ronduit geweigerd. de Video-editor Doet het allemaal in de browser, tot acht clips en dertig minuten.
Waarom kunnen twee clips niet gewoon aan elkaar worden geplakt?
Omdat een videobestand geen stroom van foto's is met een koptekst erop. Het is een container die gecodeerde stromen bevat en de codering draagt de staat.
H.264 comprimeert door de meeste frames te beschrijven als verschillen met andere frames. Een keyframe staat op zichzelf; alles nadat het is gedefinieerd in verhouding tot wat eerder was, tot het volgende keyframe. De decoder heeft ook de parametersets van de stream nodig, die de resolutie, het kleurformaat en het profiel beschrijven, en het bevat een tijdbasis die de getallen op elk pakket omzet in seconden.
Twee bestanden gemaakt door twee apparaten zijn het daar over eens. Verschillende resolutie betekent verschillende parametersets. Verschillende framerate betekent meestal een andere tijdbasis. Zelfs twee clips van dezelfde telefoon, die een jaar uit elkaar zijn opgenomen, kunnen verschillen omdat de camera-app de encoderinstellingen heeft gewijzigd.
Door de bytes aan elkaar te koppelen, krijg je een stream waarvan de decoder het ene ding in de kop wordt verteld en halverwege een ander wordt gegeven. Soms gaat een speler mee. Vaak toont het de eerste clip en stopt, of speelt de tweede als gekleurde ruis.
Wat levert de snelle methode op?
Een bestand, een stapel waarschuwingen en een verkeerde duur.
ffmpeg's verknochte demuxer Bij stream-kopie is de methode elke "Just Just Med Them's Answer Online Recommends, en het is echt de juiste tool wanneer de ingangen overeenkomen. Gewezen op mijn twee niet-overeenkomende clips die het met succes verlaat, en dit is wat het terug handen geeft:
| Measure | verwachtend | vervaardigt |
|---|---|---|
| duur | 11.000 s | 11.996 s |
| verklaarde resolutie | één waarde, correct | 1280x720 voor een stream die 640x480 wordt |
| Tijdstempelwaarschuwingen | geen | Eén per frame van de tweede clip |
De waarschuwingen zeggen allemaal hetzelfde:
Non-monotonic DTS; previous: 90981, current: 76133; changing to 90982.
This may result in incorrect timestamps in the output file.
De tijdstempels van de tweede clip herstarten vanaf nul, zoals ze zouden moeten in hun eigen bestand, en de Muxer zal geen stream schrijven waarvan de tijdstempels achteruit gaan. Dus het verzint nieuwe, één frame per keer, en het geaccumuleerde verschil tussen de echte timing en de uitgevonden timing is waar de extra seconde vandaan komt.
FFmpeg kan beide helften achteraf nog decoderen, omdat FFmpeg ongewoon tolerant is. Een browser is dat niet. Dit is het bestand dat prima op uw machine speelt en een zwarte rechthoek voor een kijker laat zien.
Wat kost het samenvoegen via een filtergrafiek en wat koopt het?
Het kost een volledige decodering en codering. Het koopt een bestand dat correct is.
In plaats van streams te kopiëren, wordt elke invoer gedecodeerd in frames, worden de frames bijgesneden en samengevoegd in een filtergrafiek en wordt er een nieuwe stroom gecodeerd uit het resultaat. Elk frame gaat door een decoder en een encoder, wat echt werk is.
Wat het koopt, is dat de uitvoer één codec, één resolutie, één framesnelheid en één doorlopende set tijdstempels heeft, omdat het allemaal tegelijk vanaf het begin was gecodeerd. Op dezelfde twee clips:
| Measure | Kopieer methode | Filtergrafiek |
|---|---|---|
| duur | 11.996 s | 11.000 s |
| Resolution | verklaarde 1280x720, wordt 640x480 | 1280x720 overal |
| broeddecor | 305 | 305 |
| exporttijd | nadrukkelijk | 0,63 s |
| Maat | kleiner | 2,1 MB |
0,63 seconden werk gedurende 11 seconden uitvoer, op een bureaublad met FFMPEG-native. In een browsertabblad via WebAssembly is het meerdere keren langzamer, wat de eerlijke handel is en de reden waarom het aantal clips is gemaximeerd.
Waarom heeft elke clip zijn tijdstempels opnieuw gebaseerd?
Omdat aaneenschakeling in een filtergrafiek samen streams vormt, en een stream tijdstempels absoluut zijn.
De frames van elke clip komen aan vanaf het begin van hun eigen bestand met de draagtijden. Trim een gedeelte uit het midden van een clip en die frames zeggen nog steeds "Dit gebeurt op 42 seconden". Sluit je aan bij een clip die eindigt op 6 seconden en je hebt een stream die van 6 naar 42 springt, met 36 seconden ertussenin.
setpts=PTS-STARTPTS Trekt de eigen start van elke clip af van elk frame, dus elke clip begint bij nul voordat deze wordt samengevoegd. Het audio-equivalent is asetpts. Zonder hen speelt de output de eerste clip af, dan een lange bevriezing, dan de tweede. Het is de meest voorkomende fout in met de hand geschreven FFmpeg-join-opdrachten, en het is stil: het bestand is geldig en de duur is gewoon verkeerd.
Wat gebeurt er als de clips verschillende maten hebben?
De join wordt geweigerd, en tot voor kort was die weigering hier het hele verhaal.
de verbindfilter Vergelijkt de invoer en wordt niet uitgevoerd als de videodimensies of de sample-aspect ratio het niet eens zijn:
Input link in0:v0 parameters (size 640x480, SAR 1:1) do not match the
corresponding output link in0:v0 parameters (1280x720, SAR 1:1)
Failed to configure output pad on Parsed_concat_8
Dat is een afbreken, geen waarschuwing: er wordt geen bestand geproduceerd. Twee telefoons, of een telefoonclip en een schermopname, is precies het geval dat het activeert, en het is de gewone reden waarom iemand clips bij elkaar voegt.
Audio heeft dergelijke hulp niet nodig, wat de moeite waard is om te weten omdat het contra-intuïtief is. Dezelfde grafiek voegde een 44,1 kHz monotrack samen met een 48 kHz stereo zonder te klagen en produceerde een exact bestand van 11.000 seconden. Alleen de videokant is streng.
De oplossing is om één frame voor de hele tijdlijn te regelen en elke clip erin te passen voordat je je aansluit. De hoogte komt van de uitvoerresolutie die je hebt gekozen, of van de eerste clip wanneer je de bronresolutie behoudt, en de breedte volgt dat de beeldverhouding van de clip, zodat een tijdlijn van portretbeelden portretteert. Elke clip wordt vervolgens geschaald om in dat frame te passen en opgevuld om het te vullen:
scale=1280:720:force_original_aspect_ratio=decrease,
pad=1280:720:(ow-iw)/2:(oh-ih)/2,setsar=1
In plaats van vullen betekent dat een clip van een andere vorm een letterbox is in plaats van uitgerekt, wat de minste is van twee kwaden wanneer een 4:3-clip een 16:9-tijdlijn ontmoet. setsar=1 Is geen decoratie: het filter vergelijkt de aspectverhouding van het voorbeeld en de pixelafmetingen, dus twee clips kunnen dezelfde grootte hebben en toch worden afgewezen.
Beide afmetingen zijn afgerond op even getallen, omdat H.264 in 4:2:0 kleur in elke richting in elke richting opslaat en niet kan coderen voor een oneven breedte of hoogte.
Waarom slechts acht clips en dertig minuten?
Omdat elke clip een decodeerpass binnen een browsertab kost en het tabblad een vaste hoeveelheid geheugen heeft.
Acht ingangen betekenen acht decoders die tegen dezelfde filtergrafiek lopen, plus de encoder, plus elk bronbestand dat in het geheugen wordt vastgehouden omdat er geen schijf is om van te streamen. Dertig minuten uitvoer is het punt waar de codering lang genoeg over doet dat mensen aannemen dat de pagina is opgehangen.
Geen van beide limieten is een wet van het formaat. Beide zijn de lijn die de browser bouwt niet meer aangenaam, en ze worden van tevoren vermeld in plaats van ontdekt wanneer een tabblad veertig minuten in een export crasht. Een clip die korter is dan een tiende van een seconde wordt ook geweigerd, omdat het hieronder geen frames en ffmpeg-fouten bijdraagt in plaats van waarschuwt.
Voor alles wat groter is, is dit de verkeerde tool en een desktop-editor is de juiste.
Hoe verschilt trimmen hier van de trimmer?
Trimmen in een join is frame nauwkeurig en het kost niets extra.
De toegewijde Videomaaier Biedt een snelle modus die de stream kopieert en alleen op een keyframe kan snijden, daarom landt het begin van een trim soms tot tien seconden eerder. zijn gids Dekt waarom in detail.
Die handel bestaat hier niet, want de export codeert toch alles opnieuw. De trim vindt plaats in de filtergrafiek, op gedecodeerde frames, dus een snede na 4,3 seconden is een snede na 4,3 seconden. U krijgt framenauwkeurigheid gratis, als bijwerking van de kosten die u al betaalt.
Dus als je één clip wilt bijsnijden en niets anders, is de snelle modus van de trimmer veel sneller. Als je ergens mee aan de slag gaat, trim dan hier.
Wat doet een snelheidsverandering met de audio?
Het moet afzonderlijk worden afgehandeld en de rekenkunde is niet hetzelfde als voor video.
Videosnelheid is een timestamp-bewerking: setpts=PTS/2 Halveer de presentatietijd van elk frame en de frames zelf zijn onaangeroerd. Audio kan niet op die manier werken, omdat het twee keer zo snel spelen van samples de toonhoogte een octaaf verhoogt. de atempo Filter in plaats daarvan resamples, behoud de toonhoogte en verander de duur.
atempo Geaccepteerd slechts 0,5 tot 2,0 in een enkele pas voor het grootste deel van zijn leven, dus een 4x wissel wordt gebouwd als twee 2x passen en een 0,25x verandering als twee 0,5x passeert. De huidige builds hebben het plafond verhoogd en FFMPEG 8.1 meldt een bereik van 0,5 tot 100. gemeten op één clip, een enkele atempo=4 en een geketend atempo=2,atempo=2 Landde 11 milliseconden uit elkaar.
De keten is nog steeds wat er wordt gebouwd, omdat de WebAssembly-kern tijdens runtime wordt opgehaald in plaats van vast te pinnen, en vermenigvuldigen is correct bij elke build die ooit het filter heeft verzonden. Het aangeboden snelheidsbereik, 0,25x tot 4x, is waar het resultaat nog steeds een bewerking is in plaats van een nieuwigheid.
mp4 of webm?
MP4 Tenzij je een specifieke reden hebt, en de reden is bijna altijd een licentie in plaats van een kwaliteitsargument.
| mp4 | weer | |
|---|---|---|
| videocodec | H.264 | VP9 |
| audiocodec | AC | struintje |
| speelt in | alles | Browsers, de meeste moderne spelers |
| Codeer snelheid in een tabblad | sneller | aanzienlijk langzamer |
| Maat bij vergelijkbare kwaliteit | groter | kleiner |
VP9 produceert kleinere bestanden voor dezelfde waargenomen kwaliteit, en het is royaltyvrij, wat voor sommige projecten van belang is en helemaal niet voor andere. ffmpeg's eigen VP9-coderingsgids is bot over de snelheidskosten. Wat het niet is, is snel. Het WebM-pad loopt hier op een hogere CRF met een realtime deadline en cpu-used 5, dit zijn instellingen die een desktop-codering zou beschouwen als onvoorzichtig, want zonder hen duurt het lang genoeg om een VP9-codering in een tabblad te coderen om zich gebroken te voelen.
Het MP4-pad gebruikt -preset veryfast Bij CRF 23 met yuv420p, plus -movflags +faststart, die de index naar de voorkant van het bestand verplaatst, zodat het wordt afgespeeld tijdens het downloaden in plaats van alleen daarna.
Hoe groot wordt de export en hoe lang duurt het?
Grootte is voorspelbaar vanuit de resolutie. Tijd is nergens voor te voorspelbaar.
Omdat de export altijd opnieuw codeert, vertelt het formaat van het bronbestand u heel weinig over het resultaat. De getoonde schatting komt in plaats daarvan van de uitgangshoogte: ongeveer 5 Mbps bij 1080p, 2,5 bij 720p, 1,2 daaronder, met WebM die ongeveer 70% van het MP4-cijfer en audio toevoegt, 128 kbps toevoegen, tenzij gedempt.
Dat is een schatting en wordt als één gelabeld, omdat inhoud belangrijker is dan welke formule dan ook. Een statisch interviewopname en een draagbare pan door bomen met dezelfde resolutie en dezelfde CRF verschillen verschillende keren, aangezien CRF zich richt op een kwaliteitsniveau en elke bitrate uitgeeft die nodig is.
De tijd hangt af van uw machine, de resolutie, het aantal clips en of het tabblad iets anders te doen heeft. De native FFMPEG-run hierboven beheerde 11 seconden uitvoer in 0,63 seconden; verwacht dat de browser meerdere keren langzamer is dan dat en verwacht dat het webM weer langzamer zal zijn.
Wat dit niet doet
Het voegt zich bij, trimt, herschikt, schalen, verandert snelheid en laat audio vallen. Dat is de hele functieset, en de kloof tussen het en een video-editor is het waard om duidelijk over te zijn.
Er zijn geen overgangen, geen titels, geen muzieknummer, geen kleurcorrectie, geen bijsnijd, geen volume per clip, geen keyframed, geen voorbeeld van de voltooide tijdlijn. Elke clip wordt bijgesneden en geplaatst, één set uitvoerinstellingen is van toepassing op alle clips en het resultaat is gecodeerd.
Dat omvat een echte en gemeenschappelijke taak: verschillende opnames die één bestand moeten worden, bijgesneden tot de nuttige delen, in de juiste volgorde, op een grootte die iets zal accepteren. Gebruik een editor voor alles wat met een creatieve beslissing te maken heeft.
In welke volgorde gaan de clips en kun je deze veranderen?
De volgorde waarin je ze hebt toegevoegd, en ja, met de knoppen op en neer op elke clip.
Herordenen is een lijstbewerking in plaats van een video: het verplaatsen van een clip verandert welke invoerindex deze in de filtergrafiek inneemt, en niets wordt opnieuw gelezen of opnieuw gedecodeerd totdat de export wordt uitgevoerd. Dus een verhuizing is direct hoe groot de bestanden ook zijn, en u kunt een tijdlijn zo vaak als u wilt gratis herschikken.
Knoppen in plaats van slepen en neerzetten is een bewuste keuze voor een lijst met maximaal acht items. Elk draagt een label met de naam van de clip die hij beweegt, dus de volgorde kan worden gewijzigd door het toetsenbord en leesbaar door een schermlezer, die geen van beide geeft je zonder veel extra werk.
Het ding dat de moeite waard is om te controleren voordat je gaat exporteren, is de richting van de reeks. Verschillende opnamen van dezelfde gebeurtenis komen meestal uit een bestandskiezer in alfabetische volgorde, wat de volgorde is van de bestandsnamen van een camera die toevallig produceren en niet altijd de volgorde waarin de opnames zijn gemaakt.
Waarom wordt dit uitgevoerd in de browser?
Omdat de beelden meestal het soort zijn dat je liever niet uploadt, en de baan heeft geen server nodig.
Elke operatie hier is ffmpeg, en ffmpeg Compileert naar Webassembly. De bestanden worden vanaf uw schijf in het tabblad gelezen, daar gedecodeerd, daar samengevoegd, daar gecodeerd en teruggegeven als download. Er wordt niets geüpload, geen wachtrij houdt uw beeldmateriaal vast en er is geen kopie op een machine die u niet beheert.
De clips waar mensen bij zijn, zijn interviews, consultaties, familie-opnames, schermafbeeldingen van interne software, concepten onder embargo. Het gebruikelijke alternatief uploadt enkele honderden megabytes naar een gratis service, converteert het op hardware waar je niets vanaf weet en houdt het onder voorwaarden die niemand leest.
De kosten zijn de acht clips en dertig minuten durende plafonds, en een codering die langzamer is dan een desktop. Beide worden vermeld voordat u begint, wat de transactie waard is.
