WebM naar AVIF omzetten

AVIF is zijn omslachtigheid alleen waard als de omvang van een afbeelding een getal is dat iemand echt bekijkt: een largest-contentful-paint-cijfer dat niet daalt, een gewichtsbudget, een Lighthouse-score waarover in een pull request wordt gediscussieerd. Speelt niets daarvan, dan is de WebP-versie van hetzelfde beeld kleiner dan een JPG, codeert direct en heeft geen fallback nodig.

Is het budget echt, dan is AVIF de sterkste optie beschikbaar en is het verschil op een heldenafbeelding of een groot posterbeeld niet marginaal. De kosten worden tweemaal betaald: nu in codeertijd, en later in een fallback in je opmaak.

AVIF is geen nieuwe beeldcodec. Het is een AV1-intraframe — een enkel keyframe uit de videocodec — verpakt in dezelfde containerfamilie als HEIC. En AV1 is een van de codecs die een WebM kan dragen: nieuwere browserrecorders en veel moderne webvideo gebruiken het.

Is de bron dus een AV1-WebM, dan decodeert deze omzetting een beeld dat AV1 codeerde en geeft het terug aan AV1 om opnieuw als still te coderen. De rondgang is ongewoon gunstig, want de artefacten van de eerste passage zijn precies de vormen waar de tweede passage efficiënt in is.

Een JPG of WebP verschijnt vrijwel meteen. Een AVIF kost seconden, en op een 4K-beeld op een gemiddelde laptop kan dat behoorlijk wat meer zijn. Dat is de pagina niet die traag is; dat is wat AV1-codering kost.

De reden is de zoektocht: AV1 haalt zijn efficiëntie uit een enorm aantal manieren om elk blok pixels te beschrijven, en de encoder probeert er veel voordat hij kiest. Merk je dat je dertig beelden omzet en wacht, dan is dat het signaal om WebP te gebruiken voor de miniaturen en AVIF te bewaren voor het ene beeld bovenaan de pagina.

Het beeld komt eruit op de eigen pixelafmetingen van de video, ongeschaald, gecodeerd op een vaste kwaliteit van 82. Een 1080p-opname geeft een AVIF van 1920 bij 1080; een 4K-opname geeft er een vier keer zo groot en aanmerkelijk trager om te maken.

Verklein achteraf, niet hier. Wat je responsieve bronnen ook genereert, kent de breedtes die je layout nodig heeft en werkt beter vanaf het volledige beeld dan vanaf een verkleind beeld. Het is ook de plek om te beslissen hoeveel formaten de codeertijd waard zijn.

Elke huidige grote browser decodeert AVIF, maar ondersteuning kwam jaren na WebP en oudere installaties blijven bestaan — vooral op apparaten die geen updates meer krijgen. AVIF alleen serveren is een keuze om die bezoekers hun afbeeldingen te ontnemen in plaats van ze te vertragen.

De oplossing is een `<picture>`-element met een AVIF-bron, een WebP-bron en een JPG als laatste `<img>`. Drie regels, geen JavaScript, en de browser kiest de eerste die hij begrijpt.

Een still uit gecomprimeerde video getrokken, draagt alles wat de videocodec ermee deed. Er zijn bits besteed aan beweging, kleur is met halve resolutie opgeslagen in elke richting, en een beeld genomen tijdens een scroll of een pan was nooit scherp gecodeerd om te beginnen. AVIF bewaart dat allemaal heel efficiënt; het herstelt niets.

Het praktische gevolg is dat het tijdstip meer telt dan het formaat. Een beeld genomen op een stil moment en opgeslagen als JPG verslaat een beeld genomen midden in beweging en opgeslagen als AVIF ruim, op elke maat inclusief omvang.

Alles dat geen webpagina is. E-mailclients renderen het niet. Kantoorsoftware grotendeels ook niet. Drukworkflows niet. Uploadformulieren op andermans sites weigeren de extensie vaak ronduit.

Zijn hele bestaansrecht rust op het gedecodeerd worden door een browser en geserveerd worden over een netwerk waar jij voor betaalt. Voor een dia, een document of een bericht: neem de JPG; voor een archief of een drukwerk: neem de TIFF.

AVIF-codering is duur genoeg dat diensten die het aanbieden ervoor rekenen, het in een wachtrij zetten, of het aantal beperken. Hier draait het in je browser, dus de enige plafonds zijn de genoemde — honderd bestanden per batch, 100 MB per bestand — zonder dagelijkse toewijzing.

Het betekent ook dat de video de machine niet verlaat. Dat is het gebruikelijke privacyargument en het heeft hier een praktische kant: een grote opname uploaden om een afbeelding van 40 KB terug te krijgen, is een absurde hoeveelheid netwerkverkeer voor het resultaat.