Wat is een M3U-playlist? Formaat, voorbeelden en spelerinstellingen

Een M3U-playlist is een platte-tekstbestand. Dat is de hele definitie. De verwarring eromheen komt voort uit twee verschillende gemeenschappen die datzelfde eenvoudige formaat elk in hun eigen richting uitbreiden.

Streamingtechnici gebruiken M3U8 precies zoals RFC 8216 het definieert: als het playlistformaat achter HLS-videostreaming. IPTV-providers gebruiken gewone M3U informeel en voegen hun eigen tags toe voor zendernamen en logo's die nooit onderdeel waren van een officiële specificatie. Beide zijn correcte toepassingen van het formaat. Deze gids scheidt de twee duidelijk, toont van elk een geannoteerd voorbeeld en legt uit waar het bestand past zodra je het wilt laden in een speler.

Belangrijkste punten

• Een M3U-playlist is een platte-tekstlijst met streamvermeldingen die begint met de tag #EXTM3U.
• M3U8 betekent specifiek dat het bestand UTF-8-gecodeerd is, volgens RFC 8216 sectie 4.1. Dat is het praktische verschil met gewone M3U.
• IPTV-achtige tags zoals tvg-id en group-title zijn een veelgebruikte conventie, geen onderdeel van de officiële HLS-specificatie.

Wat is een M3U-playlist precies?

Een M3U-playlist is een tekstbestand dat een mediaspeler vertelt wat er afgespeeld moet worden en in welke volgorde, één vermelding per regel. In de uitgebreide vorm begint het bestand met #EXTM3U als allereerste regel, een vereiste die is vastgelegd in RFC 8216, sectie 4.3.1.1.

Elke vermelding kan worden voorafgegaan door een #EXTINF-tag, die dezelfde RFC in sectie 4.3.2.1 definieert als #EXTINF:<duration>,[<title>]: een duurwaarde gevolgd door een optionele titel. Dat is het hele kernformaat: een headerregel, gevolgd door paren van metadata en URL's. Al het andere dat je in een echte playlist tegenkomt, is een uitbreiding bovenop deze minimale structuur.

M3U versus M3U8: wat is het echte verschil?

M3U8 betekent specifiek dat de playlist UTF-8-gecodeerd is, een vereiste die RFC 8216 rechtstreeks stelt in sectie 4.1. Gewone M3U kent daarentegen geen vaste coderingsconventie. Het formaat dateert van vóór enige formele eis en werd historisch behandeld als Latin-1 of wat de lokale systeemstandaard toevallig was.

Je merkt het coderingsverschil het duidelijkst als een zendernaam accenten of een niet-Latijns schrift gebruikt. Als een speler UTF-8 verwacht maar een anders gecodeerd bestand ontvangt, kunnen die tekens als onleesbare symbolen worden weergegeven, ook al werkt de playlist verder prima. Zie je kapotte tekens in zendernamen terwijl alles verder gewoon afspeelt, dan ligt de oorzaak meestal bij de codering, niet bij de playliststructuur zelf.

Geannoteerd voorbeeld — een standaard HLS M3U8-playlist

RFC 8216 definieert dit formaat rechtstreeks: een playlist opgebouwd uit segmentverwijzingen, elk met een eigen #EXTINF-duur, gebruikt om één stream in stukken af te leveren. Dit is het formaat dat in de specificatie zelf daadwerkelijk de naam "M3U8" draagt.

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXTINF:9.009,
segment-000.ts
#EXTINF:9.009,
segment-001.ts
#EXTINF:9.009,
segment-002.ts
#EXT-X-ENDLIST

Elke regel doet er hier toe. #EXT-X-VERSION en #EXT-X-TARGETDURATION zijn HLS-specifieke tags uit dezelfde RFC, en elk .ts-bestand is een kort videosegment dat de speler achter elkaar ophaalt. Dit is het formaat waarop de webvideo-infrastructuur daadwerkelijk draait. Een IPTV-provider geeft je dit zelden rechtstreeks, maar het is vaak wel wat je speler op de achtergrond ophaalt zodra een bron aan het afspelen is.

Echte HLS-implementaties voegen meestal nog een laag toe: een masterplaylist, getagd met #EXT-X-STREAM-INF, die meerdere versies van dezelfde stream op verschillende bitrates of resoluties vermeldt en de speler daartussen laat schakelen naarmate de netwerkomstandigheden veranderen. Eén URL die je krijgt, kan naar die masterplaylist verwijzen in plaats van rechtstreeks naar de hierboven getoonde segmentlijst; de speler lost de rest automatisch op.

De meeste IPTV-gerichte uitleggidsen slaan deze gelaagde structuur volledig over, omdat IPTV-playlists die zelden gebruiken. Toch is het relevant: het is de daadwerkelijke structuur waarop een videospeler is gebouwd om te begrijpen, ook als het M3U-bestand dat je krijgt er totaal niet op lijkt.

Geannoteerd voorbeeld — een typische IPTV-stijl M3U-playlist

IPTV-providers breiden het basisformaat informeel uit door attributen zoals tvg-id, tvg-logo en group-title aan elke vermelding toe te voegen. Geen van deze zijn gedefinieerd in RFC 8216. Het is een de-factoconventie die zich verspreidde over IPTV-spelers en providers omdat ze nuttig zijn, niet omdat een standaardisatie-instantie ze heeft vastgelegd.

#EXTM3U
#EXTINF:-1 tvg-id="channel.one" tvg-logo="https://example-provider.test/logo1.png" group-title="News",Channel One
https://example-provider.test/stream/CHANNEL_TOKEN_1
#EXTINF:-1 tvg-id="channel.two" tvg-logo="https://example-provider.test/logo2.png" group-title="Sports",Channel Two
https://example-provider.test/stream/CHANNEL_TOKEN_2

De URL's en tokens hierboven zijn plaatshouders — deel of publiceer nooit een echte playlist-URL. Iedereen met de werkelijke link kan je bron gebruiken, op dezelfde manier als iedereen met een wachtwoord op een account kan inloggen.

Let op de duur -1: dat is een livestreamconventie voor "geen vaste lengte", anders dan de eindige segmentduren in het HLS-voorbeeld hierboven. Dezelfde tag, maar met een andere praktische betekenis afhankelijk van welke van de twee tradities het bestand heeft voortgebracht.

Waar past de EPG in?

Sommige M3U-bestanden bevatten een url-tvg=-header die verwijst naar een apart programmagidsbestand, maar de gidsgegevens zelf staan buiten de playlist. De playlist vertelt een speler welke streams er bestaan; een apart XMLTV-bestand vertelt welk programma op elke stream wordt uitgezonden.

Dat is een bewuste scheiding, geen beperking. Providers kunnen gidsgegevens op hun eigen schema bijwerken, meerdere keren per dag als de programmering wijzigt, zonder de playlist zelf aan te raken. De zenderlijst en het schema zijn twee onafhankelijk onderhouden bestanden die toevallig samenwerken.

Bevat je M3U een url-tvg=-header, dan kan een speler die dit ondersteunt automatisch gidsgegevens ophalen zonder dat je handmatig een tweede URL invoert. Is dat niet het geval, dan moet de gids apart worden toegevoegd, wat een andere instapstap is dan het toevoegen van de playlist zelf en buiten het bestek van dit artikel valt.

Hoe gebruikt een speler zoals IPTV Expert een M3U-bestand?

Een speler heeft maar twee dingen nodig om een M3U-bron te gebruiken: een naam die je zelf kiest, en de playlist-URL zelf. Dat is precies de invoer die het formulier voor het toevoegen van een bron in IPTV Expert vraagt, niets meer, en er is geen aparte stap om tags zoals tvg-logo handmatig te verwerken.

Zodra je die twee velden opslaat, downloadt de app het bestand op die URL en verwerkt het voordat de bron als actief wordt behandeld. De app leest de #EXTINF-vermeldingen, neemt onderweg eventuele group-title- en tvg-logo-metadata mee en bouwt je zenderlijst op basis van wat hij vindt. Wil je de exacte stap-voor-stap instructies voor jouw apparaat, dan behandelt Hoe voeg je een M3U-playlist toe aan IPTV Expert Android, iOS, Windows, Mac, Linux, Android TV en Fire TV afzonderlijk.

Heb je IPTV Expert nog niet geïnstalleerd, ga dan naar de volledige downloadkeuze en kies de versie voor je apparaat, of bekijk De beste gratis IPTV-spelers in 2026 als je nog aan het vergelijken bent.

Conclusie

Drie dingen komen overal in dit artikel terug: een M3U-playlist is platte tekst opgebouwd rond #EXTM3U en #EXTINF; M3U8 betekent specifiek UTF-8-codering; en de IPTV-stijl tags die je in echte playlists tegenkomt — tvg-id, tvg-logo, group-title — zijn een breed toegepaste conventie bovenop het formaat, niet iets dat RFC 8216 definieert. Zodra dat duidelijk is, komt het instellen ervan in een speler neer op maar twee velden: een naam en een URL.