Een klant vroeg me ooit om een korte schermopname van een bug. De opname was 212 MB gedurende vier minuten, wat een Retina-display met 60 frames per seconde kost, en hun mailserver stuiterde het twee keer voordat ik erachter kwam dat de limiet van 25 MB in de foutmelding niet het nummer was dat ik moest verslaan. Bijlagen zijn Base64-gecodeerd, dus het bestand komt ongeveer een derde groter aan dan het is gebleven. Ik moest onder de 18 MB zitten, niet 25. De opname ging uit met 6 MB, 720p, geen audio, en zag er perfect scherp uit, omdat een schermopname van een bug meestal een statische pagina is met een cursor die eroverheen beweegt en die prachtig comprimeert. De nuttige les was geen setting. Het was dat elk van deze banen dezelfde berekening van drie regels is, en als je het eenmaal kunt doen, stop je met gissen.
tl;dr: Een kwaliteitsniveau geeft je geen bestandsgrootte, omdat een factor met constante snelheid een kwaliteitsdoel is en de resulterende grootte afhankelijk is van hoeveel beweging de beelden vervoeren. Om een harde limiet te bereiken, werk er achteruit van: doelbitsnelheid in kilobits per seconde is de grootte in bytes maal 8, gedeeld door de duur in seconden, gedeeld door 1000. Kies vervolgens de resolutie waarvan de normale bitrate onder dat getal zit. Door 1080p naar 720p te laten vallen, bespaart u meer dan welke kwaliteitsschuifregelaar dan ook, en als u audio laat vallen, hoeft u niet meer te besparen dan mensen verwachten. de videocompressor Op Toolz.dev voert de codering uit via FFmpeg die is gecompileerd naar Webassembly op uw eigen browsertab, de schatting wordt weergegeven voordat het begint en uploadt het bestand nooit.
Waarom belooft een kwaliteitsinstelling je nooit een maat?
Omdat de twee meest voorkomende manieren om een video te comprimeren verschillende vragen beantwoorden, en degene die betere resultaten oplevert, is degene die u de grootte niet van tevoren kan vertellen.
Doelbitsnelheid De modus zegt: gebruik 2 megabits per seconde, wat dat ook duurt. De grootte is dan rekenkundig, precies voorspelbaar, en de kwaliteit zwaait wild. Een stille titelkaart en een handheld regenbui krijgen beide 2 Mbps, dus de titelkaart verspilt het meeste en de regen ziet eruit als nat grind.
Constante snelheidsfactor De modus zegt: houd deze kwaliteit vast, besteed wat er nodig is. Gemakkelijke frames krijgen een paar stukjes, harde frames krijgen er veel en de foto blijft visueel van begin tot eind. De maat is wat het ook is.
Elke moderne encoder beveelt de tweede aan voor alles wat niet live wordt gestreamd, en het is wat de compressor hier gebruikt. De kosten zijn dat het nummer op de pagina voordat u op de knop drukt een schatting is, afgeleid van de typische bitrate voor die resolutie en kwaliteit, en de echte figuur beweegt mee met de beelden. Een statische schermopname komt routinematig op de helft van de schatting. Handheld beelden van bewegend water kunnen er overheen landen. Confetti, sneeuw, gebladerte in wind en camerakorrel zijn de vier dingen die voorbij elke schatting blazen, omdat ze allemaal dicht bij willekeurige ruis zijn en ruis het enige waar compressie niets mee kan.
Wat kiest CRF als je een niveau kiest?
De schaal loopt 0 tot 51 voor 8-bit H.264, waarbij 0 verliesloos is en 51 niet-kijkbaar is, en de FFMPEG H.264 Coderingsgids Zet de standaard op 23 en het Sane Working-bereik op ongeveer 17 tot 28. Het onthouden waard is dat de schaal logaritmisch is: een verandering van 6 helften of verdubbelt de bitrate. Dat enkele feit vertelt je wat elk niveau doet voordat je het probeert.
De compressor biedt drie, geen slider, omdat het verschil tussen CRF 26 en 27 onzichtbaar is, terwijl het verschil tussen 23 en 33 het hele punt is.
| gelijk maken | H.264 CRF | VP9 CRF | Audio | Waar het voor is |
|---|---|---|---|---|
| Light | 23 | 31 | 160 kbps | Archief kopieën en beeldmateriaal dat u opnieuw zult bewerken. Bijna genoeg visueel verliesloos. |
| Evenwichtig | 28 | 36 | 128 kbps | het gewone antwoord. Ongeveer de helft van de bitrate van licht, en op een laptopscherm moet je naar het verschil zoeken. |
| Sterk | 33 | 42 | 96 kbps | een harde limiet halen. Artefacten beginnen te worden weergegeven op gedetailleerde beelden, en niemand vindt het erg bij een chatupload. |
De VP9-nummers zijn een aparte schaal, daarom zien ze er niets van verwant. Het lichtniveau 31 is precies wat Google's precies VP9-coderingsaanbevelingen voor video on demand Lijst als de doelkwaliteit voor 1080p, en de rest van die tabel is de moeite waard om een bladwijzer te houden: 32 voor 720p, 33 of 34 voor 480p, 15 voor 4K.
Wat bespaart meer ruimte, minder of minder pixels?
Minder pixels, met een ruime marge, en het is niet dichtbij.
Resolutie is een tweedimensionale hoeveelheid. Van 1080p naar 720p gaan is geen derde af, het is 2,07 miljoen pixels tot 0,92 miljoen, dus de encoder heeft 56% minder pixels om te beschrijven voordat hij een beslissing van één kwaliteit neemt. Het bestand volgt, ongeveer. Van 4K naar 1080p gaan verwijdert drie kwart van hen.
Dit is waar een clip van één minuut op belandt, op bronhoogte en -niveau, met behulp van de typische bittrates waarvan de tool wordt geschat. Audio is inbegrepen.
| Bron | Light | Evenwichtig | Sterk |
|---|---|---|---|
| 4K (2160p) | 106 MB | 61 MB | 35 MB |
| 1080p | 35 MB | 20 MB | 11 MB |
| 720p | 20 MB | 12 MB | 7 MB |
| 480p | 10 MB | 6 MB | 4 MB |
Lees het over en naar beneden. Een stap naar beneden door de kwaliteitskolom heen, bespaart ongeveer 43%. Als u een stap naar beneden in de resolutiekolom gaat, bespaart u ook ongeveer 42%, wat eruitziet als een gelijkspel totdat u merkt dat kwaliteitsstappen na drie opraken en u zichtbare artefacten kosten, terwijl een resolutiestap helemaal niets op het scherm kost waar de meeste mensen op zullen kijken. Een 1080p-clip die in een slack-bericht wordt weergegeven, wordt weergegeven in een doos van ongeveer 400 pixels breed.
De volgorde om te proberen, dan: laat de resolutie vallen naar wat de kijker realistisch gezien zal gebruiken, houd de kwaliteit in evenwicht en reik alleen naar sterk als je het nog steeds niet hebt gehaald.
Hoe beland je onder een harde limiet van 8 MB?
achteruit werken. De hele berekening is één regel, en het is het enige stukje videorealisatie dat het leren waard is.
# total bitrate (kbps) = target size (bytes) x 8 / duration (s) / 1000
#
# 8 MB, 45-second clip:
# 8,000,000 x 8 / 45 / 1000 = 1,422 kbps total
# minus 96 kbps of audio = 1,326 kbps for video
#
# 1080p strong is ~1,400 kbps video -> about 8.4 MB. Just over.
# 720p strong is ~800 kbps video -> about 5.0 MB. Comfortable.
#
# the equivalent single pass, if you have ffmpeg installed:
ffmpeg -i input.mp4 -c:v libx264 -crf 33 -preset fast \
-vf scale=-2:720 -c:a aac -b:a 96k \
-movflags +faststart -pix_fmt yuv420p output.mp4
Drie dingen maken dit in de praktijk betrouwbaar.
- Laat hoofdruimte. Streef naar 80% van de limiet. CRF bereikt geen doel van grootte, en de enige keer dat het doorschiet, is de tijd dat u het bestand verzendt.
- Tel de coderingsoverhead als deze per e-mail gaat. base64 staat voor elke 24 bits invoer als 4 tekens, door RFC 2045, dus een bijlage wordt opgeblazen met een derde op de draad. Een mailboxlimiet van 25 MB is ongeveer 18 MB aan het werkelijke bestand.
- Vertrouw geen nummer dat je je herinnerde. Discord's gratis uploadlimiet is 8 MB, dan 25 MB, dan 10 MB, dan 20 MB vanaf augustus 2026. Gmail heeft jarenlang 25 MB gehouden. WhatsApp comprimeert alles wat je verzendt, ongeacht. Controleer de limiet van de dag die u nodig heeft en doe dan de rekenkunde.
Als de clip langer is dan wat je wilt laten zien, is de betere zet om hem te knippen in plaats van hem te knijpen. Halveren van de duur halveert de maat op volledige kwaliteit, die geen enkele instelling kan evenaren. de Videomaaier Zal het bereik uitschakelen zonder opnieuw te coderen wanneer de snede in de buurt van een keyframe landt, en het resultaat is byte-identieke beelden van de helft van de grootte.
Helpt het verlagen van de framesnelheid?
Minder dan je zou denken, en het ziet er erger uit dan al het andere op de lijst.
De reden is dat opeenvolgende frames al tegen elkaar worden gecomprimeerd. Een videocodec slaat één full frame op en beschrijft vervolgens de verschillen, dus frame 31 in een 60 fps clip is bijna gratis, omdat het bijna identiek is aan frame 30. Het weggooien slaat niet de stukjes op die je je voorstelt. Tegen typische tarieven is de besparing dichter bij lineair dan gratis, dus 60 fps tot 30 fps stijgt misschien een derde in plaats van de helft, en 30 fps tot 15 fps geeft je zichtbaar trilling bij elke camerabeweging.
Er zijn twee gevallen waarin het de juiste oproep is. Een schermopname van meestal statische inhoud verliest niets leesbaar met 15 fps, en dat is precies het geval waarin u meestal het uiterste doet om onder een limiet te komen. En beelden die je converteert naar een animatie voor een pagina, waar de kijker niet zozeer naar beweging kijkt als wel opmerkt, overleeft 12 tot 15 fps prima.
Voor alles met een persoon of een camerabeweging erin, laat de framesnelheid met rust en neem in plaats daarvan de resolutie lager.
Moet de audio overleven?
Vraag waar de audio voor is, want het is niet gratis.
Een opname van 10 minuten met audio met 128 kbps heeft 9,6 MB geluid voordat het beeld een enkel bit krijgt. Als die audio een stille schermopname is met kamergebrom erin, of muziek die je gaat vervangen, of een spraaktrack die je al hebt getranscribeerd, het laten vallen is de gemakkelijkste besparing die beschikbaar is en het kost de kijker niets. De compressor heeft een schakelaar voor precies dat, die passeert -an en laat de audiostream volledig weg.
Wanneer het geluid ertoe doet, dalen de niveaus het van 160 naar 128 naar 96 kbps, wat de conventionele punten zijn. 96 kbps AAC is voldoende voor spraak en hoorbaar dun op muziek. Als u de audio alleen wilt, als een bestand om te transcriberen of te bewerken, audio-extractor trekt de track naar buiten zonder de video aan te raken, en de audio-omzetter zal het op zijn eigen voorwaarden opnieuw coderen.
Eén detail grijpt mensen uit. Een video zonder audiotrack speelt bij de meeste spelers geruisloos af en slaagt er niet in om automatisch af te spelen in een paar oude mobiele browsers die verwachten dat een nummer dempt. Als de clip een webpagina binnengaat, is een stille 8 kbps-track soms veiliger dan geen, hoewel elke browser die vandaag wordt verzonden, een video-only MP4 correct afhandelt.
Is WebM het extra wachten waard?
Het hangt helemaal af van wie het bestand opent.
VP9 in een WebM-container landt ongeveer een kwart kleiner dan H.264 tegen een vergelijkbare zichtbare kwaliteit. Dat is een echte winst, en op uw eigen site, waar de enige vereiste is dat een browser het kan afspelen, is WebM meestal het betere bestand. Chrome, Firefox en Edge ondersteunen VP9 al tien jaar en Safari heeft sinds versie 14.
De kosten komen twee keer voor. VP9-codering is langzamer dan x264, in hoofdzaak dus in een browser, en één detail schakelt iedereen uit die het commando met de hand uitvoert: VP9 eert alleen een kwaliteitsdoel wanneer de bitrate expliciet nul is. voorbijlopen -crf 36 Op zichzelf en de encoder gebruikt in plaats daarvan stilletjes een standaardbittrate en negeert u. het heeft nodig -crf 36 -b:v 0, wat de tool stuurt.
De tweede kosten zijn alles wat geen browser is. Chat-apps, CMS-uploadvelden, video-editors, PowerPoint, het voorbeeldvenster in een bestandsbeheer, de telefoon van uw klant: veel van deze accepteren MP4 en halen hun schouders op bij WebM. Als het bestand naar een persoon gaat, stuur MP4 met H.264. Als het een pagina binnengaat die u bestuurt, Webm. Diezelfde splitsing loopt door de hele formaatvraag, die de Remux-gids Dekt vanaf de conversiezijde.
Waarom weigert een gecomprimeerde MP4 soms te beginnen met spelen?
Vanwege waar de index is beland, en het is de enige vlag die je nooit mag weglaten.
Een MP4 houdt een inhoudsopgave bij die beschrijft waar elk frame begint. Normaal geschreven, ontdekt de encoder dat allemaal terwijl het gaat en schrijft de tabel aan het einde van het bestand. Voor weergave vanaf een schijf die prima is. Geserveerd via HTTP, betekent dit dat de speler pas kan beginnen als hij het hele bestand heeft, dus een video van 40 MB in een chat-app of een CMS zit daar niets te doen terwijl het downloadt en begint dan.
-movflags +faststart Geeft een tweede doorgang over het voltooide bestand en verplaatst die tabel naar voren. De codering duurt even en de video begint na een seconde af te spelen. Elke MP4 die de compressor produceert, heeft het.
Er zijn nog twee vlaggen in dat commando voor compatibiliteit in plaats van grootte. -pix_fmt yuv420p Krachten 4:2:0 Chroma subsampling, omdat een 4:2:2 of 4:4:4 MP4 geldig is en weigert te spelen op een lange lijst van hardwaredecoders. en het schaalfilter is geschreven scale=-2:720 eerder scale=-1:720, omdat H.264 zelfs pixelafmetingen vereist en -2 Rondt de berekende breedte af op een even getal. Vraag om een oneven breedte en de codering mislukt met "breedte niet deelbaar door 2" in plaats van naar iets dichtbij te schuiven.
Waarom ziet het comprimeren twee keer zo veel slechter?
Generatieverlies, en het is steiler dan mensen verwachten, omdat compressie met verlies geen idempotent is.
De eerste code gooit details weg die het oog niet zal missen en laat zijn eigen artefacten achter: lichte blokkering aan randen, gladde hellingen, rinkelend rond hoog contrast. De tweede codering heeft geen manier om te weten dat die artefacten niet de afbeelding zijn. Het behandelt ze als inhoud die het waard is om te behouden, besteedt stukjes aan het beschrijven ervan en voegt er zijn eigen bovenop. Drie gebalanceerde compressierondes op dezelfde clip zien er slechter uit dan één ronde van sterke, op een grotere bestandsgrootte.
Dus de praktische regels zijn kort. Comprimeer elke keer van het origineel, nooit uit het exemplaar dat u al hebt gemaakt. Als u zowel een lichte archiefversie als een kleine versie nodig hebt om te verzenden, maak dan beide vanaf de bron. En als een bestand al via een platform is dat opnieuw samendrukt bij het uploaden, wat de meeste is, behandel dan wat je al hebt gedownload als een tweede generatie.
Dit is dezelfde rekenkunde die regeert Afbeelding compressie en de reden waarom een JPEG gered herhaaldelijk in modder verandert, en dezelfde reden waarom de PDF compressor Werkt op de afbeeldingen in een document in plaats van op het document als geheel.
Verlaat het bestand uw machine?
Nee, en voor video verandert dat waar de tool voor bruikbaar is.
De codering loopt door FFMPEG gecompileerd voor Webassembly, uitvoeren op het tabblad Browser. Het bestand wordt vanaf uw schijf in het paginageheugen gelezen, daar gecodeerd en teruggegeven als download. Open DevTools, schakel over naar het netwerkpaneel, comprimeer iets en kijk: Geen verzoek draagt de video.
Drie gevolgen volgen.
Er wordt niets geüpload, dus niets wordt bewaard. Geen enkele kopie staat op een server die wacht op een bewaarbeleid om het te verwijderen, omdat er geen kopie is gemaakt. Voor een niet-uitgebrachte productdemo, beeldmateriaal onder NDA, of iets met een persoon erin die niet akkoord ging met een upload van derden, is dat het verschil tussen bruikbaar en niet.
De limieten zijn de browsers, geen plan. Het hele bestand gaat naar het tabbladgeheugen, dus de pagina accepteert tot 500 MB en sluit een enkele doorgang af met 30 minuten, en het controleert beide wanneer u het bestand kiest in plaats van na een download van vier megabyte-engines en twee minuten coderen. Er is geen wachtrij, geen watermerk, geen account en geen grootte om te kopen.
De eerste run is langzamer. De FFMPEG WebAssembly-bundel downloadt één keer, wat een paar seconden duurt en daarna in de cache wordt opgeslagen. Het gereedschap laadt het op de eerste compressie in plaats van wanneer de pagina wordt geopend, dus de pagina zelf blijft snel.
Wanneer is een desktop-encoder de juiste tool?
Wanneer de bovenstaande nummers niet langer de beperking zijn. Een browsertabblad is een redelijke encoder en een slechte videopijplijn, en het is de moeite waard om duidelijk te zijn over waar de lijn valt.
Ga native voor bestanden van meer dan 500 MB of clips meer dan een half uur, waarbij het tabgeheugen de echte limiet is. Ga native voor een batch, want 40 clips door een lus in een shell verslaat 40 ritten door elke interface. Ga native wanneer u twee-pass-codering nodig heeft om een exacte maat te krijgen, wat een enkele CRF-pas niet kan beloven. En ga native voor hardwarecodering, waar een GPU in 20 seconden zal doen wat Webassembly vier minuten duurt.
Voor één clip die de komende vijf minuten onder een limiet moet komen, op een laptop, zonder iets te installeren of de beelden aan een vreemde over te geven, is de browser het snellere pad over een afstand. Dat is de baan die compressor is gebouwd voor, naast bekeerder voor het veranderen van formaat en de beeldcompressor Voor hetzelfde probleem één dimensie naar beneden.
