GIF naar MKV omzetten

Mediaservers sorteren wat ze vinden in films, afleveringen, muziek en afbeeldingen, en ze beslissen op basis van de container. Een GIF valt aan de verkeerde kant: het is een afbeeldingsbestand, dus Jellyfin en Kodi slaan het over of behandelen het als artwork, ongeacht de bestandsnaam.

Een MKV is ondubbelzinnig. De scanner leest een duur, een videospoor en een resolutie, en het item verschijnt in de bibliotheek met een miniatuur en een voortgangsbalk zoals al het andere. Dat is het hele argument voor deze omzetting — niet de bestandsgrootte, die elke videocontainer zou leveren.

MKV werd in 2002 gepubliceerd als open container, ontworpen om van alles te bevatten zolang je maar wilt: elk aantal video-, audio- en ondertitelsporen, hoofdstukken, bijlagen en metadata die verplaatsing tussen machines overleeft. In dit register staat het genoteerd voor archivering en levering, en de archiveringskant is de eerlijke.

Wat het niet is, is een webformaat. De browserondersteuning staat op geen enkele — niet gedeeltelijk, geen enkele — en het is niet ontworpen voor progressief streamen zoals WebM. Bestaat er een kans dat deze animatie ooit op een webpagina komt, dan brengt omzetten naar MKV dat verder weg, niet dichterbij.

Matroska kan vrijwel elke codec dragen, wat de keuze een echte keuze maakt. Deze omzetting schrijft H.264 in het High-profiel, omdat wie een bestand in een zelfgehoste bibliotheek zet meestal een televisie, een streamingbox of een telefoon-app voedt, en H.264 het enige is dat al die hardware zonder transcoderen decodeert.

Het alternatief was VP9 of AV1 geweest, beide kleiner bij dezelfde zichtbare kwaliteit en beide een gok aan de ontvangende kant. Een mediaserver die bij afspelen moet transcoderen, maakt van een stille animatie van vijf minuten een taak voor een processor die meestal ook al iets anders doet.

Het Matroska-bestand dat hieruit komt bevat één videospoor en verder niets, precies wat een GIF te geven heeft. Wat daarvan een startpunt maakt in plaats van een beperking, is dat MKVToolNix er later iets aan kan toevoegen zonder opnieuw te coderen: een commentaarspoor, een ondertitelbestand, hoofdstukmarkeringen, een omslagafbeelding.

Remuxen kopieert de videostream ongewijzigd over, dus er gaat niets verloren en het duurt seconden in plaats van minuten. Wordt deze animatie later onderdeel van iets groters, dan is elke volgende stap een containerbewerking in plaats van weer een generatie compressie.

Het GIF-formaat kent geen bewegingscompensatie. Frame twaalf wordt als een compleet beeld opgeslagen, ook al verschilt het maar op vier pixels van frame elf, en de enige compressie is LZW over een geïndexeerd palet. Dat ontwerp dateert uit 1989 en is nooit veranderd.

H.264 slaat één volledig beeld op en daarna, per volgend frame, alleen het verschil. Bij materiaal dat als GIF in een bibliotheek eindigt — een opgenomen terminalsessie, een langzaam draaiend rendering — blijft het grootste deel van het beeld van frame op frame gelijk, precies het geval waarvoor de codec gebouwd is.

Een GIF-frame draagt hoogstens 256 kleuren. Wat de oorspronkelijke opname ook had, die reductie gebeurde toen de GIF geschreven werd, en zit al vast in de frames die de encoder krijgt. Een verloop dat vloeiend was, is nu getrapt, en een gediderd gebied is nu een veld afwisselende pixels.

De video-encoder voegt daar niets aan toe, maar dithering is een echte complicatie: het is hoogfrequente ruis, en dat is het duurste wat een videocodec kan worden gevraagd op te slaan. Een zwaar geditherde GIF wordt een grotere MKV dan een vlakke van dezelfde afmetingen en lengte.

Een GIF heeft geen geluid, dus de MKV bevat alleen een videospoor. De meeste spelers verwerken dat zonder commentaar — VLC en MPV tonen geen audio-apparaat, Kodi speelt het stil af.

Sommige bibliotheek-front-ends zijn strenger en tonen een item zonder audiostream als onbekend of beschadigd formaat. Is jouw opzet er zo een, dan kan MKVToolNix in één stap een stil audiospoor in het bestand mengen zonder het beeld opnieuw te coderen.

De stopregel is het waard om ronduit te zeggen. Duurt de animatie drie seconden en is het doel om ergens geplaatst te worden, dan is omzetten naar Matroska moeite in de verkeerde richting — het bestand zal in de bibliotheek staan als een item waar niemand naartoe wil bladeren, en MP4 of WebM had het echte gebruik beter gediend.

Deze omzetting loont wanneer de GIF lang is, wordt bewaard in plaats van gedeeld, en de rest van de plank al Matroska is. Consistentie binnen een bibliotheek is op zichzelf waardevol.

De frames worden gelezen door de eigen afbeeldingsdecoder van de browser en samengevoegd tot Matroska in hetzelfde tabblad. Geen enkel deel van het bestand wordt ergens naartoe gestuurd, er is geen account en geen wachtrij.

Die decoder is niet in elke browser aanwezig. Ontbreekt hij, dan zegt de pagina dat en noemt browsers die hem wel hebben, in plaats van het bestand stilzwijgend naar een server te sturen.