MP4 versus WebM in 2026: het juiste videoformaat, de codec en de compressiekwaliteit kiezen

Als je video's maakt, bestaande bestanden omzet of videomateriaal voor een website voorbereidt, is de keuze van het juiste formaat en de juiste compressie-instellingen een van de belangrijkste beslissingen. Het kleinst mogelijke bestand is niet per se het beste bestand. Het moet ook betrouwbaar afspelen in browsers, werken op smartphones, efficiënt te decoderen zijn en genoeg beeldkwaliteit behouden voor het beoogde gebruik.

Ik heb MP4, WebM, H.264, H.265/HEVC, VP9, AV1, FFmpeg, de encoderpresets van x264, browsercompatibiliteit, hardwarematige decodering op mobiele apparaten en metingen van videokwaliteit onderzocht. Daarnaast heb ik praktische compressieproeven uitgevoerd: ik codeerde dezelfde bronvideo met verschillende CRF-waarden en vergeleek de resultaten zowel visueel als met objectieve metingen.

Uiteindelijk besloot ik de voorkeur te geven aan MP4 met H.264 wanneer één videobestand op een zo breed mogelijke reeks browsers, telefoons en externe toepassingen moet werken.

Voor korte video's die vooral op mobiele apparaten worden bekeken en waarbij snel laden en kleine bestanden belangrijker zijn dan het behoud van elk klein detail, koos ik x264 CRF 30. Bij normaal afspelen zag ik namelijk geen betekenisvol verschil tussen CRF 22 en 30, zelfs niet op een grote desktopmonitor.

Daarbij hoort wel een belangrijke kanttekening: CRF 30 is geen aanbeveling voor speelfilms, hoogwaardige videoproducties of beelden waarbij maximale getrouwheid aan de bron belangrijk is. Voor zulke toepassingen kan een aanzienlijk behoudender waarde, vaak rond CRF 20, een beter uitgangspunt zijn. Ik heb geen vergelijkbaar onderzoek uitgevoerd met speelfilms of hoogwaardig filmmateriaal. Deze instellingen zijn dus slechts beginpunten voor afzonderlijke tests.

In dit artikel leg ik de technische afwegingen, de daadwerkelijke compressieresultaten en hun beperkingen uit. Ook bespreek ik hoe je voor je eigen project een geschikt videoformaat en een passende kwaliteitsinstelling kiest.

1. Videocontainers en codecs zijn verschillende dingen

Voordat je MP4 en WebM vergelijkt, moet je het verschil begrijpen tussen een container en een codec.

Een container bewaart video, audio, tijdstempels en metagegevens samen in één bestand. Een videocodec bepaalt hoe de videoframes worden gecomprimeerd en gedecodeerd.

Een MP4-bestand kan bijvoorbeeld video bevatten die is gecodeerd met H.264, HEVC of AV1. Hoewel de bestandsextensie hetzelfde is, verschillen deze combinaties in compressie-eigenschappen en apparaateisen.

Onderdeel	Voorbeelden	Functie
Videocontainer	MP4, WebM, MOV, MKV	Bundelt video, audio en tijdgegevens
Videocodec	H.264, HEVC, VP9, AV1	Comprimeert en decomprimeert videoframes
Audiocodec	AAC, Opus, MP3	Comprimeert en decomprimeert audio
Video-encoder	x264, x265, SVT-AV1, libvpx-vp9	Voert de videocompressie uit

Een bestandsnaam van .webm naar .mp4 veranderen, zet de videocodec niet om. Andersom wordt AV1 in een MP4-container niet plots afspeelbaar op apparaten zonder ondersteuning voor AV1-decodering.

Beoordeel voor videocompatibiliteit altijd de hele combinatie: container, videocodec, audiocodec, codecprofiel, bitdiepte en afspeelomgeving.

2. MP4 versus WebM: wat is beter voor video op het web?

MP4 en WebM zijn allebei volwaardige moderne videocontainers. Geen van beide is altijd beter: hun praktische eigenschappen hangen af van de codecs die erin worden gebruikt.

MP4 met H.264: de breedste praktische compatibiliteit

MP4 met H.264-video en AAC-audio kent een bijzonder lange geschiedenis van brede ondersteuning. Gangbare desktop- en mobiele browsers, videospelers van besturingssystemen en veel externe toepassingen kunnen ermee overweg.

Ook hardwaredecoders in smartphones en computers ondersteunen deze combinatie vaak. Vergeleken met decodering via software kan hardwarematige decodering het CPU-gebruik verminderen, het afspelen efficiënter maken en minder energie verbruiken.

Het grootste nadeel is de compressie-efficiëntie. Nieuwere codecs kunnen bij een vergelijkbare waargenomen beeldkwaliteit vaak met een lagere bitsnelheid toe.

Toch blijft H.264 een uitstekende keuze wanneer betrouwbaar afspelen belangrijker is dan een zo klein mogelijk bestand.

WebM met VP9: efficiënt en geschikt voor browsers

WebM bevat meestal VP8-, VP9- of AV1-video, met audio die doorgaans in Opus of Vorbis is gecodeerd.

VP9 comprimeert bij vergelijkbare visuele kwaliteit vaak efficiënter dan H.264. Huidige browsers ondersteunen het breed, waaronder moderne versies van Safari.

Het is onjuist om te zeggen dat Safari WebM of VP9 per definitie niet ondersteunt. De browsercompatibiliteit is in de loop van de tijd aanzienlijk verbeterd.

De belangrijkste beperking zit buiten de browser. Systeemeigen toepassingen, oudere apparaten en software van derden kunnen minder consequent met WebM omgaan dan met een gebruikelijk H.264-MP4-bestand.

Voor een toepassing die uitsluitend in de browser draait en waarbij je de afspeelmogelijkheden kunt beheersen, is WebM een sterke optie. Mogen bezoekers video's downloaden en in willekeurige programma's openen, dan is MP4/H.264 voorspelbaarder.

Het verschil in de praktijk

Vereiste	MP4 + H.264	WebM + VP9
Afspelen in moderne browsers	Uitstekend	Zeer goed
Ondersteuning door oudere browsers en apparaten	Over het algemeen beter	Meer afhankelijk van de omgeving
Compatibiliteit van gedownloade bestanden	Over het algemeen beter	Minder voorspelbaar in systeemeigen apps
Compressie-efficiëntie	Goed	Vaak beter
Hardwarematige decodering	Zeer wijdverspreid	Gebruikelijk, maar apparaatafhankelijk
Meest geschikt voor	Eén breed compatibel bestand	Efficiënte levering via het web aan bekende clients

De vraag is niet of WebM een goed formaat is. Het gaat erom of de voordelen bij compressie in jouw specifieke omgeving opwegen tegen de nadelen voor compatibiliteit.

3. H.264, H.265, VP9 of AV1: welke codec kies je?

Elke belangrijke videocodec biedt een andere afweging tussen compressie-efficiëntie, rekentijd bij het coderen, hardwareondersteuning, softwarecompatibiliteit en licenties.

Codec	Compressie-efficiëntie	Praktische compatibiliteit	Gebruikelijke toepassing
H.264 / AVC	Goed	Uitstekend	Algemene webvideo, mobiel afspelen en downloads
H.265 / HEVC	Over het algemeen beter dan H.264	Afhankelijk van de omgeving	Geschikte Apple-apparaten, gecontroleerde omgevingen, video met hoge resolutie
VP9	Over het algemeen beter dan H.264	Zeer goed in moderne browsers	Videolevering via browsers
AV1	Potentieel uitstekend	Steeds beter, met beperkingen op oudere apparaten	Moderne streaming en geschikte apparaten

Dit zijn kwalitatieve vergelijkingen, geen universele ranglijst van bitsnelheden. De werkelijke efficiëntie hangt af van de video-inhoud, de gebruikte encoder, het kwaliteitsdoel, de coderingspreset en de meetmethode.

H.264: volwassen, snel te decoderen en breed ondersteund

H.264 is sterk geoptimaliseerd en wordt ondersteund door een enorm aanbod aan hardware en software. Die volwassenheid is een voordeel wanneer een video betrouwbaar moet werken zonder een speciale videospeler.

Het nadeel is dat nieuwere codecs video vaak efficiënter kunnen comprimeren. Bij H.264 spelen bovendien octrooien en licenties een rol; voor relevante commerciële distributievormen moet je die aspecten beoordelen.

H.265 / HEVC: betere compressie met compromissen in compatibiliteit

HEVC kan bij vergelijkbare kwaliteit de bitsnelheid ten opzichte van H.264 aanzienlijk verlagen. Het is vooral aantrekkelijk voor video's met hoge resolutie en omgevingen waarin de compatibiliteit van apparaten beheersbaar is.

Veel Apple-apparaten ondersteunen HEVC uitstekend. De ondersteuning in browsers en externe toepassingen verschilt echter per besturingssysteem en per geïnstalleerde decoder. Ook licenties zijn een aandachtspunt.

HEVC kan een uitstekende keuze zijn, maar ik zou het niet automatisch als enige downloadformaat aanbieden op een algemene website.

VP9: een praktisch open alternatief

VP9 biedt goede compressie en brede compatibiliteit met moderne browsers. Het is een aantrekkelijke optie als video's binnen de browser blijven en de afspeelomgeving voorspelbaar is.

Voor mijn toepassing was het grootste nadeel de onzekerheid wanneer gebruikers video's downloaden of openen in systeemeigen toepassingen die WebM of VP9 mogelijk niet consequent ondersteunen.

AV1: uitstekende efficiëntie, maar nog geen universele hardwareondersteuning

AV1 is een van de veelbelovendste moderne videocodecs. Het kan ten opzichte van oudere codecs aanzienlijk besparen op bitsnelheid, terwijl de ondersteuning voor hardwarematige decodering blijft groeien.

Oudere apparaten beschikken echter mogelijk niet over een AV1-decoder en zijn dan aangewezen op decodering via software. Bij hoge resoluties kan dat meer CPU-capaciteit en accuvermogen vergen en op zwakkere apparaten afspeelproblemen veroorzaken.

Als je de afspeelomgeving beheerst, verdient AV1 serieuze overweging. Moet één bestand op oude én nieuwe apparaten en in gewone externe videospelers werken, dan blijft H.264 de veiligere standaardkeuze.

De MDN-handleiding voor videocodecs geeft nuttige informatie over deze codecs en hun vereisten in browsers.

4. Eén videoformaat of meerdere versies?

Dit is een van de belangrijkste architectuurkeuzes bij het aanbieden van video.

Als meerdere versies mogelijk zijn, kan een website AV1 of VP9 leveren aan geschikte apparaten en terugvallen op H.264 in andere omgevingen. Zo kun je efficiënter comprimeren en toch een brede ondersteuning behouden.

Het beheren van meerdere versies zorgt echter ook voor extra werk bij het coderen, opslaan, cachen, valideren en selecteren van de juiste afspeelversie.

Als je precies één definitief videobestand per bron nodig hebt, is een aanpak die compatibiliteit vooropstelt vaak beter.

Ik koos MP4/H.264 omdat ik één bestand wilde dat afspeelt in de belangrijkste browsers, op smartphones en na het downloaden in gangbare videospelers, zonder afhankelijk te zijn van alternatieve formaten.

Daarmee zeg ik niet dat MP4/H.264 de beste compressie biedt. Ik geef voorspelbaar afspelen simpelweg voorrang boven het mogelijke groottevoordeel van een nieuwere codec.

5. Waarom mobiele video andere prioriteiten heeft

Bij videocompressie moet je uitgaan van de manier waarop het materiaal daadwerkelijk wordt bekeken.

Een kort filmpje dat vooral op een smartphone wordt bekeken, stelt andere eisen dan een speelfilm op een grote televisie. In het eerste geval kunnen snel laden en weinig mobiele data gebruiken waardevoller zijn dan het behoud van subtiele details. In het tweede geval kan de beeldkwaliteit juist het belangrijkste doel zijn.

Bij korte video's voor mobiele apparaten hebben kleinere bestanden verschillende voordelen:

Er hoeven minder gegevens te worden overgedragen voordat het afspelen begint.
Downloads kunnen op beperkte verbindingen sneller klaar zijn.
Er is minder opslagruimte op het apparaat nodig.
Gebruikers verbruiken minder mobiele data.
Bij een lagere gecodeerde bitsnelheid kan de video beter blijven afspelen wanneer de beschikbare doorvoersnelheid beperkt is.

Maar een kleiner bestand garandeert niet dat een video nooit hoeft te bufferen of zal haperen. Ook wisselende netwerkomstandigheden, pieken in de bitsnelheid, servergedrag, afspeelbuffers en de decodeerprestaties van het apparaat zijn van belang.

Voor mobiele compatibiliteit telt meer dan de bestandsextensie: hardwarematige decodering, codecprofiel en -niveau, bitdiepte, chroma-subsampling, resolutie, framerate en piekbitsnelheid spelen allemaal mee. Een video die 390 CSS-pixels breed wordt weergegeven, kan op een smartphone met hoge pixeldichtheid aanzienlijk meer fysieke pixels beslaan. Een frame terugschalen tot 390 pixels breed en dat bekijken, is dus niet noodzakelijk gelijk aan de oorspronkelijke video op die telefoon bekijken. Test op echte apparaten en onder werkelijke afspeelomstandigheden.

CRF regelt de kwaliteit, maar legt geen exacte maximale bitsnelheid op. Een complexe video kan ondanks een relatief kleine totale bestandsgrootte nog steeds forse pieken in bitsnelheid hebben. Is betrouwbaar afspelen op bijzonder trage verbindingen essentieel, overweeg dan expliciete grenzen voor de bitsnelheid of VBV, geschikte resolutielimieten en tests onder realistische netwerkomstandigheden.

Het uitgangspunt is eenvoudig: optimaliseer voor de beoogde kijkervaring, niet voor een abstract streven naar maximale kwaliteit.

6. CRF bij x264 begrijpen: lager is betere kwaliteit, hoger is een kleiner bestand

Na de keuze voor H.264 moet je bepalen hoe sterk je de video wilt comprimeren.

Bij x264 bepaalt de Constant Rate Factor, kortweg CRF, de afweging tussen de hoeveelheid behouden beelddetail en de bestandsgrootte.

Een lagere CRF levert doorgaans grotere bestanden met hogere kwaliteit op. Een hogere CRF levert doorgaans kleinere bestanden op, maar met meer compressieverlies.

CRF stelt geen exacte bitsnelheid of uitvoergrootte vast. De encoder verdeelt bits afhankelijk van het bronmateriaal, waardoor een eenvoudige scène en een scène vol details bij dezelfde CRF sterk verschillende bestandsgroottes kunnen opleveren.

CRF bepaalt ook niet de fundamentele compatibiliteit met decoders. Twee correct gecodeerde H.264-video's met CRF 22 en CRF 30 kunnen dezelfde codec, hetzelfde profiel en niveau, hetzelfde pixelformaat, dezelfde afmetingen en dezelfde framerate hebben.

Het verschil zit vooral in de compressiekwaliteit en de eigenschappen van de bitsnelheid.

Belangrijk: CRF-waarden zijn niet rechtstreeks vergelijkbaar tussen verschillende codecimplementaties. CRF 30 in x264 staat niet gelijk aan dezelfde visuele kwaliteit als CRF 30 in een AV1-encoder.

7. Mijn echte compressieproef: CRF 22 tot en met 32

Ik wilde ontdekken hoe sterk ik een video kon comprimeren voordat het verschil bij normaal afspelen belangrijk werd.

Ik gebruikte één kort, al eerder gecomprimeerd filmpje en maakte H.264-vergelijkingsbestanden met CRF 22, 24, 26, 28, 29, 30, 31 en 32.

Belangrijke eigenschappen van de video bleven behouden, waaronder resolutie, framerate, speelduur en aantal frames. Ook gebruikte ik consistente encoderinstellingen, zodat het effect van het veranderen van CRF beoordeeld kon worden.

De resultaten lieten aanzienlijke verschillen in bestandsgrootte zien.

CRF	Geschatte grootte ten opzichte van het origineel	Betekenis
22	63%	Voorzichtiger compressie met beter behoud van details
24	49%	Kleiner bestand met enig extra kwaliteitsverlies
26	38%	Verdere besparing met behoud van veel details
28	30%	Compact resultaat dat relatief sterk op de bron lijkt
29	26%	Agressievere compressie
30	23%	Mijn voorkeurscompromis voor dit testmateriaal
31	21%	Extra besparing met minder getrouwheid aan de bron
32	19%	Kleinste geteste resultaat en grootste gemeten kwaliteitsverlies

Deze percentages zijn gebaseerd op de geteste bron en zijn geen representatieve besparingen voor willekeurige video's. De waarden in de tabel zijn onafhankelijk van elkaar afgerond. Bereken exacte relatieve besparingen daarom op basis van de oorspronkelijke bestandsgroottes en niet door de afgeronde percentages op elkaar te delen.

Het verrassendste resultaat was dat ik bij normaal afspelen geen betekenisvol zichtbaar verschil zag tussen CRF 22 en CRF 30, zelfs niet op een grote desktopmonitor.

Ik bekeek ook sterker gecomprimeerde versies, waaronder CRF 32, zonder bij het normaal afspelen van dat specifieke filmpje een duidelijk verschil op te merken.

Dat was belangrijk omdat die video's vooral bedoeld waren voor kleinere mobiele schermen. Als het kwaliteitsverlies me op mijn desktopmonitor niet stoorde, zag ik weinig reden om aanzienlijk grotere bestanden te maken voor extra details die mijn beoogde kijkervaring niet verbeterden.

Dit was echter een subjectieve waarneming bij één soort bronmateriaal. Ze bewijst niet dat alle gebruikers, smartphones of video's hetzelfde resultaat opleveren. Schermen met een hoge pixeldichtheid en een korte kijkafstand kunnen artefacten zichtbaar maken, vooral in fijne details of kleurverlopen.

8. Objectieve metingen bevestigden dat er echt kwaliteitsverlies was

Als je tijdens het afspelen geen verschil ziet, wil dat niet zeggen dat twee video's wiskundig identiek zijn.

Ik heb de gecodeerde bestanden ook met objectieve maatstaven voor beeldkwaliteit vergeleken. Naarmate CRF hoger werd, nam de overeenkomst met de bron af.

Bij een vergelijking waarbij alles op dezelfde manier werd verkleind om een scherm met hoge pixeldichtheid te benaderen, waren de representatieve SSIM-metingen als volgt:

CRF	SSIM bij benadering	Uitvoergrootte ten opzichte van CRF 28
22	0.9934	2.13×
28	0.9869	1.00×
30	0.9837	0.79×
32	0.9795	0.63×

De trend is duidelijk: sterkere compressie verminderde de gemeten getrouwheid van de gecodeerde video. Bij nauwkeurige inspectie waren ook kleine verschillen in fijne lijnen en texturen zichtbaar.

Toch bleef de normale kijkervaring bij de geteste bron vrijwel hetzelfde. Daarom moet je objectieve metingen en een subjectieve beoordeling samen gebruiken.

SSIM meet beeldgelijkenis, niet de volledige menselijke kijkervaring. De maatstaf houdt niet volledig rekening met artefacten in de tijd, ervaren scherpte, de weergave van beweging of het subjectieve belang van afzonderlijke details.

VMAF is een andere nuttige maatstaf voor de waargenomen kwaliteit. Netflix publiceerde in juni 2026 de VMAF-v1-modellen, waaronder een model dat is afgestemd op het kijken op telefoons. Deze modellen erkennen expliciet dat de ervaren kwaliteit mede afhangt van de schermgrootte en de relatieve kijkafstand.

Een voorzichtig gecodeerd testbestand had in het onderzoek een gerapporteerde gemiddelde VMAF-score van ongeveer 95. Er was echter geen consistente reeks VMAF-metingen beschikbaar voor alle agressieve CRF-instellingen. Daarom heb ik VMAF niet gebruikt om te beweren dat CRF 30 of 32 een universele kwaliteitsdrempel haalde.

De praktische conclusie is beperkter: de geteste korte video verdroeg zeer sterke H.264-compressie bij normaal afspelen bijzonder goed.

9. Waarom ik CRF 30 koos voor korte mobiele video's

Na vergelijking van de bestanden besloot ik tot CRF 30 voor vergelijkbare korte video's die vooral op mobiele apparaten worden bekeken.

De redenen waren eenvoudig:

De video's waren kort en niet bedoeld voor beeldkwaliteit op bioscoopniveau.
Snel laden en kleinere downloads waren belangrijk.
Ik zag op een grote desktopmonitor geen betekenisvol verschil tussen CRF 22 en 30.
CRF 30 leverde veel kleinere bestanden op dan voorzichtiger instellingen.
Ook CRF 32 zag er bij het geteste voorbeeld acceptabel uit, maar gaf me minder vertrouwen voor complexer materiaal.

Vergeleken met CRF 28 verkleinde CRF 30 het geteste uitvoerbestand met ongeveer 21%. Vergeleken met CRF 22 was de uitvoer meer dan 60% kleiner.

Voor korte mobiele filmpjes waarbij een prettig beeld, snel laden en redelijk bandbreedteverbruik centraal staan, vond ik dat een goede afweging.

De voorwaarde is echter essentieel: ik koos 30 vanwege het daadwerkelijke kijkdoel en de resultaten met het geteste materiaal, niet omdat 30 van nature de beste CRF voor smartphones is.

Een mobiel apparaat heeft CRF 30 niet nodig. Het kan ook veel getrouwer gecodeerde video prima weergeven. CRF 30 is een bewuste keuze om enige brongetrouwheid in te ruilen voor kleinere bestanden, wanneer die afweging acceptabel is.

Voordat ik deze instelling zou toepassen op een verzameling met sterk uiteenlopende inhoud, zou ik meerdere representatieve filmpjes testen, waaronder lastige bewegingen, donkere scènes, kleurverlopen, tekst en fijne texturen.

10. Waarom ik CRF 30 niet aanbeveel voor films of video's van hoge kwaliteit

Dit is de belangrijkste beperking van het experiment.

Neem mijn resultaat met CRF 30 niet klakkeloos over voor speelfilms, hoogwaardige videocontent, professionele opnamen of video's die bedoeld zijn voor grote schermen.

Dit soort materiaal kan subtiele kleurverlopen, filmkorrel, donkere scènes, complexe bewegingen, oppervlakken met fijne structuren en zorgvuldig gecorrigeerde kleuren bevatten. Het behoud van die details kan belangrijker zijn dan een betrekkelijk kleine besparing op bandbreedte.

Voor gewone 1080p-video van hoge kwaliteit zou ik beginnen met een veel behoudender x264-instelling, rond CRF 20, en afhankelijk van het materiaal waarden daarboven en daaronder beoordelen.

Als visuele getrouwheid belangrijk is, kan CRF 18–22 een praktisch startbereik zijn. De geschikte waarde kan echter buiten dat bereik vallen, afhankelijk van de resolutie, inhoud en eisen.

Dit advies komt overeen met gangbare richtlijnen voor het coderen van video. Zo beveelt de kwaliteitsdocumentatie van HandBrake voor veel 1080p-toepassingen met x264 ongeveer RF 20–24 aan.

Ik heb niet hetzelfde gecontroleerde onderzoek uitgevoerd met speelfilms of hoogwaardig filmmateriaal. Daarom kan ik niet beweren dat CRF 20 altijd optimaal is, dat CRF 22 altijd voldoende is of dat een bepaalde film er bij CRF 30 onacceptabel uit zou zien.

De juiste werkwijze is om representatieve scènes te kiezen, meerdere kwaliteitsniveaus te coderen, deze te vergelijken op het beoogde scherm en te bepalen vanaf welk punt extra compressie zichtbaar schadelijk wordt.

Als de video wordt gearchiveerd, opnieuw bewerkt of als bron voor toekomstige coderingen gebruikt, bewaar dan naast de gecomprimeerde versie voor publicatie ook een hoogwaardig masterbestand.

11. Waarom ik de x264-preset veryslow gebruikte

CRF regelt één aspect van compressiekwaliteit, terwijl de x264-preset bepaalt hoeveel moeite de encoder doet om efficiënte coderingskeuzes te vinden.

x264 biedt presets van zeer snel tot zeer langzaam. Langzamere presets vragen over het algemeen meer CPU-tijd, maar kunnen bij vergelijkbare visuele kwaliteit een betere compressie-efficiëntie opleveren.

Ik vergeleek de presets medium en veryslow met hetzelfde bronmateriaal. Bij de geteste kwaliteitsinstelling leverde veryslow een kleiner bestand op.

Als je een video één keer offline codeert en vervolgens vaak opnieuw gebruikt, kan die extra verwerkingstijd de moeite waard zijn.

Daarom koos ik -preset veryslow.

Het is echter niet voor alle situaties optimaal. Als video's onmiddellijk verwerkt moeten worden, CPU-capaciteit duur is of er een enorme wachtrij moet worden weggewerkt, kunnen slow of medium operationeel een betere balans bieden.

De preset verandert vooral de complexiteit van het coderen en de compressie-efficiëntie. H.264 verandert daardoor niet in een andere codec, en het bestand wordt niet vanzelf ongeschikt voor mobiele apparaten.

12. Voor animevideo's gebruik ik de animatieafstemming van x264

Wanneer het bronmateriaal getekende animatie of beelden in animestijl bevat, gebruik ik bij x264 -tune animation.

Dat is iets anders dan CRF. Een tune verandert bepaalde keuzes van de encoder om beter aan te sluiten op specifieke beeldkenmerken. De animatieafstemming is bedoeld voor getekende contouren, egale kleurvlakken en gestileerde bewegingen.

Mijn voorkeur is daarom:

Anime of getekende animatie: -preset veryslow -tune animation.
Gewone liveactionbeelden: zet de animatieafstemming niet automatisch aan; begin met de standaardinstellingen van de encoder of beoordeel een geschikte tune afzonderlijk.

Het is belangrijk de werking van een tune niet verkeerd te begrijpen. -tune animation garandeert geen zichtbaar betere kwaliteit of kleinere bestanden. De instelling verandert het gedrag van de encoder en het resultaat hangt af van het materiaal.

Ik heb de animatieafstemming apart getest bij een vaste CRF. In die specifieke vergelijking werd het bestand door inschakeling van de tune ongeveer 6% groter, terwijl de gemeten beeldgelijkenis iets verbeterde. Het zichtbare verschil was klein.

De belangrijkste vergelijking van bestandsgroottes bij CRF 22–32 werd uitgevoerd zonder de animatieafstemming. Je kunt er dus niet van uitgaan dat de exacte groottes en compressieverhoudingen uit dat experiment hetzelfde blijven wanneer -tune animation is ingeschakeld.

Toch gebruik ik deze specifieke tune bij voorkeur voor animebeelden en beoordeel ik de uiteindelijke grootte en kwaliteit als onderdeel van het coderingsprofiel voor die inhoud.

Het afstemmen van een encoder moet je altijd zien als een aanpassing aan het bronmateriaal, niet als een universele kwaliteitsverbetering.

13. Mijn aanbevolen FFmpeg-instellingen voor korte animevideo's op mobiele apparaten

Voor een gewone SDR-animevideo die echt opnieuw gecodeerd moet worden, zou ik het volgende commando als uitgangspunt gebruiken:

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c:v libx264 \
  -preset veryslow \
  -tune animation \
  -crf 30 \
  -profile:v high \
  -pix_fmt yuv420p \
  -c:a aac -b:a 128k \
  -movflags +faststart \
  output.mp4

Met dit commando leg ik de belangrijkste keuzes expliciet vast:

-c:v libx264 gebruikt de H.264-software-encoder.
-preset veryslow geeft compressie-efficiëntie voorrang boven coderingssnelheid.
-tune animation schakelt encoderinstellingen voor animatie in.
-crf 30 past de agressieve constante-kwaliteitsdoelstelling toe die ik voor dit type korte video koos.
-profile:v high kiest een H.264-profiel dat door moderne apparaten vaak wordt ondersteund.
-pix_fmt yuv420p levert 8-bits video met 4:2:0-chroma-subsampling.
-map 0:v:0 selecteert de eerste videostream.
-map '0:a:0?' selecteert optioneel de eerste audiostream.
-c:a aac -b:a 128k codeert eventueel aanwezige audio als gebruikelijke AAC-audio.
-movflags +faststart verplaatst de initialisatiemetadata van MP4 naar het begin van het bestand.

Dit is een voorbeeld, geen universeel commando voor elke invoer. Het bronmateriaal kan om aanvullende verwerking vragen.

Met name HDR- en 10-bits materiaal mag je niet zomaar zonder geschikt kleurbeheer omzetten naar 8-bits SDR. Dat kan leiden tot verkeerde kleuren, verlies van details in lichte delen of zichtbare banden in kleurverlopen. Ook rotatiemetadata, variabele framerates, pixelbeeldverhoudingen, geïnterlinieerde bronnen, ongebruikelijke audiokanaalindelingen en niet-ondersteunde resoluties verdienen aandacht.

Als de framerate en afmetingen van de bron al geschikt zijn, maakt het behoud ervan vergelijkingen meestal eenvoudiger en voorkom je onnodig schalen of veranderen van de beweging. Dwing bronnen met een variabele framerate niet zonder noodzaak naar een constante framerate: daarbij kunnen frames worden verdubbeld of weggelaten. Houd bij het schalen de beeldverhouding op het scherm intact en zorg voor afmetingen die passen bij het gekozen 4:2:0-pixelformaat. Zeer hoge resoluties, framerates of H.264-niveaus kunnen de decodeerlimieten van oudere apparaten overschrijden. Voor compatibiliteit moet je soms dus bewust de resolutie of framerate verlagen.

14. Een behoudender FFmpeg-uitgangspunt voor video van hoge kwaliteit

Als getrouwheid aan de bron veel belangrijker is dan bestandsgrootte, begin dan met een lagere CRF en beoordeel het resultaat.

Voor conventionele liveactionvideo in SDR is het volgende commando bijvoorbeeld een redelijk experimenteel uitgangspunt:

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c:v libx264 \
  -preset slow \
  -crf 20 \
  -profile:v high \
  -pix_fmt yuv420p \
  -c:a aac -b:a 192k \
  -movflags +faststart \
  output.mp4

De preset slow is hier een praktisch algemeen uitgangspunt, geen bewering dat deze beter presteert dan veryslow. Als extra codeertijd acceptabel is, kan ook veryslow een goede keuze zijn.

Dit profiel voor hoge kwaliteit is een voorstel om te testen, geen configuratie die door mijn experiment met korte video's is bewezen.

Test voor hoogwaardige video's CRF-waarden rond 18, 20 en 22 en kies op basis van wat je ziet. Lastige filmkorrel of beweging kan andere instellingen vragen, en voor archiefmasters kan veel minder agressieve compressie nodig zijn.

15. Codeer een video niet opnieuw zonder reden

Compressie met kwaliteitsverlies is niet gratis. Een bestand dat al gecomprimeerd is opnieuw coderen, kan extra artefacten introduceren, zelfs wanneer de nieuwe versie op de bron lijkt.

Vraag je voordat je opnieuw codeert af of het originele bestand niet al voldoet aan je eisen voor compatibiliteit, grootte en kwaliteit.

Als de bestaande video al compatibele H.264-video en AAC-audio bevat en geen visuele aanpassing nodig heeft, is het kopiëren van de streams mogelijk beter dan nog een codering met kwaliteitsverlies.

ffmpeg -i input.mp4 \
  -map 0:v:0 -map '0:a:0?' \
  -c copy \
  -movflags +faststart \
  output.mp4

Dit kopieert de gecomprimeerde streams zonder ze opnieuw te coderen. De indeling van de container kan veranderen, terwijl je een extra generatie compressieverlies voorkomt.

Normaal gesproken levert dit niet dezelfde vermindering van de bestandsgrootte op als een nieuwe codering met lagere kwaliteit.

Als je bestaande video al compact en compatibel is en er goed uitziet, kan niets veranderen de beste optimalisatie zijn.

16. Controleer gecodeerde video's in plaats van alleen op bestandsgrootte te vertrouwen

Een geslaagde FFmpeg-uitvoering bewijst niet automatisch dat een video aan alle eisen voldoet.

Begin met het bekijken van de uitvoerstreams via FFprobe:

ffprobe -v error \
  -show_entries stream=codec_name,profile,pix_fmt,width,height,avg_frame_rate,nb_frames:format=duration,size \
  -of json output.mp4

Controleer de codec, het pixelformaat, de afmetingen, de framerate, de speelduur en de audiostreams.

Decodeer daarna het hele uitvoerbestand om bepaalde beschadigingen of decodeerfouten op te sporen:

ffmpeg -v error -xerror -i output.mp4 -f null -

Vergelijk bij compressieproeven bestanden die uit dezelfde bron zijn gemaakt. Houd de belangrijke variabelen gelijk en verander telkens maar één grote instelling.

Bekijk de video terwijl die afspeelt, inspecteer fijne details en let op kleurverlopen, donkere gebieden, bewegende objecten en tekst.

Vul visuele vergelijkingen waar mogelijk aan met objectieve maatstaven zoals SSIM, PSNR of VMAF. Een enkele hoge score bewijst niet dat alle artefacten onzichtbaar zijn.

Test de video ten slotte op representatieve apparaten en ook na het downloaden. Informatie over browserondersteuning is waardevol, maar echte afspeeltests zijn extra belangrijk wanneer compatibiliteit vooropstaat.

17. Zorg dat je MP4-bestanden correct worden geleverd

Goede coderingsinstellingen kunnen slechte levering via het web niet compenseren.

Stel voor gewone progressieve MP4-weergave de juiste header Content-Type: video/mp4 in en ondersteun HTTP-byte-range-verzoeken wanneer gedeeltelijk ophalen en vooruit- of terugspoelen nodig zijn.

De FFmpeg-optie +faststart verplaatst de initialisatiegegevens van een gewoon MP4-bestand naar het begin. Dat helpt bij progressief laden, maar verbetert de beeldkwaliteit niet en verlaagt de bitsnelheid niet.

Met een eenvoudig HTML-video-element kun je één H.264-MP4 aanbieden:

<video controls playsinline preload="metadata">
  <source src="/media/video.mp4" type="video/mp4">
</video>

Het attribuut preload is een aanwijzing voor de browser en geen strikte downloadlimiet. Door de regels voor automatisch afspelen kan het ook nodig zijn dat de video gedempt is of geen audio bevat.

Als een pagina meerdere video's bevat, voorkom dan dat ze allemaal meteen worden gedownload. Video's pas laden wanneer ze nodig zijn, kan het mobiele dataverbruik verminderen en de pagina sneller laten aanvoelen.

Bij korte mobiele filmpjes kan een slimme planning van downloads even belangrijk zijn als het verkleinen van de gecodeerde bestanden.

18. Welk videoformaat en welke kwaliteit kies je?

Het juiste antwoord hangt af van wat je wilt optimaliseren.

Je doel	Aanbevolen uitgangspunt
Eén breed compatibel bestand voor web en downloads	MP4 + H.264 + AAC als er audio is
Moderne browsers met meerdere formaten	AV1 of VP9, met H.264 als terugvaloptie
Maximale compressie op ondersteunde apparaten	AV1 beoordelen
Gecontroleerde afspeelomgeving met HEVC-ondersteuning	MP4 + HEVC overwegen
Korte mobiele filmpjes waarbij bestandsgrootte het belangrijkst is	x264 CRF 30 overwegen na representatieve tests
Anime of getekende animatie	x264 met `-tune animation` beoordelen
Hoogwaardige films of andere premiumvideo's	Met een behoudender CRF rond 20 beginnen en testen
Offline coderen waarbij CPU-tijd minder belangrijk is	x264 `slow` of `veryslow` overwegen
Snelle verwerking met beperkte CPU-capaciteit	x264 `medium` of `slow` overwegen
Bestaande video voldoet al aan je eisen	Behouden of zonder opnieuw coderen in een andere container plaatsen
Archivering of later opnieuw bewerken	Een hoogwaardige master bewaren naast de bestanden voor publicatie

19. Mijn uiteindelijke keuze en wat het experiment daadwerkelijk aantoonde

Na onderzoek naar videoformaten, compatibiliteit, codeerefficiëntie en daadwerkelijke compressieresultaten koos ik een praktisch profiel voor het aanbieden van korte mobiele video's.

Ik koos MP4 met H.264 als formaat, omdat voorspelbare compatibiliteit met browsers, telefoons, gedownloade bestanden en externe toepassingen belangrijker voor me was dan met een nieuwere codec het kleinst mogelijke bestand maken.

Ik koos libx264 met de preset veryslow als encoder, omdat ik de video's offline kon coderen en de extra verwerkingstijd acceptabel was.

Voor animevideo's gebruik ik de animatieafstemming, met het besef dat die het gedrag van de encoder verandert, maar geen kleinere bestanden of altijd betere beelden garandeert.

Voor korte mobiele video's koos ik CRF 30, omdat mijn vergelijking een forse vermindering van bestandsgrootte liet zien zonder een betekenisvol zichtbaar verschil bij normaal afspelen, zelfs op een grote desktopmonitor.

Dat betekent niet dat CRF 30 ideaal is voor films of hoogwaardige opnamen. Bij materiaal waarbij fijne details, kleurverlopen, filmkorrel en algemene beeldgetrouwheid belangrijker zijn, zou ik beginnen met testen rond CRF 20 of een andere passende, behoudende waarde. Ik heb geen vergelijkbaar gecontroleerd onderzoek gedaan met filmmateriaal en presenteer dat getal dus niet als een experimenteel bewezen optimum.

De belangrijkste conclusie is dat er geen codec, formaat of CRF-waarde bestaat die voor alle video's universeel het beste is.

Als je maximale compatibiliteit wilt en maar één bestand wilt aanbieden, is MP4/H.264 een goede standaard. Kun je alternatieve formaten aanbieden en wil je efficiënter comprimeren, onderzoek dan VP9 en AV1. Codeer je korte video's die vooral op telefoons worden bekeken, test dan of een hogere CRF voldoende kleine bestanden oplevert zonder de beoogde kijkervaring te schaden. Codeer je films of hoogwaardige opnamen, gebruik dan behoudender kwaliteitsinstellingen en controleer het resultaat zorgvuldig.

Bepaal eerst de vereisten voor het afspelen, kies daarna de codec en pas als laatste de compressiekwaliteit. Test vervolgens het resultaat op de apparaten en onder de omstandigheden die er werkelijk toe doen. Dat is betrouwbaarder dan blind een codec of CRF-waarde overnemen omdat die nieuwer of efficiënter is of vaak wordt aanbevolen.