Uploadsnelheid voor streaming: wat een snelle download niet vertelt

De vergelijking is vooral nuttig bij hogere downloadsnelheden. Op 1 oktober 2026 had bijna een kwart van de behouden meetparen met een download van 100 tot minder dan 300 Mbps een upload onder 14,128 Mbps. Een week later lag het aandeel iets lager: 23,4%. Zelfs vanaf 300 Mbps waren de aandelen 9,6% en 8,8%.

Deze percentages hebben per bereik en datum een andere noemer. De tabel toont alle vier de bereiken, zodat je de snellere resultaten in hun context ziet. Het gaat om gemeten downloadsnelheden, niet om de geadverteerde snelheid van een internetabonnement.

Op beide dagen kwamen uploads onder 14,128 Mbps minder vaak voor naarmate het downloadbereik hoger lag. Dat verband is nuttig, maar de resterende aandelen laten zien waarom alleen de download controleren niet volstaat. Een hoger downloadbereik betekende niet dat elke bijbehorende upload boven de gekozen bitrate voor beeld en geluid lag.

Voor het bedrijf dat zijn demo voorbereidt, is de volgende stap eenvoudig: bewaar beide cijfers uit de snelheidstest. Ligt de upload veel lager dan de download, onderzoek de geplande uitzending dan met de echte opstelling voordat je besluit de vorm te wijzigen of geld uit te geven aan een andere verbinding.

De gekozen vergelijking doet ertoe. YouTube adviseert voor H.264-video in 1080p met 30 beelden per seconde een videobitrate van 14 Mbps, plus 128 Kbps voor stereogeluid. Samen is dat 14,128 Mbps. Dezelfde richtlijn noemt voor die resolutie en beeldsnelheid een lagere minimale H.264-videobitrate van 5 Mbps.^[2]

Een aanbeveling voor gecodeerd beeld en geluid is iets anders dan een minimale internetsnelheid. Onze meting beschrijft weer iets anders: een korte overdracht naar een M-Lab-server. De snelheid uit de bron wordt berekend met TCP-bytes aan de serverkant en de verstreken tijd, niet met een doorlopende uitzending naar YouTube.^[3][6][7]

De tabel vergelijkt dus twee grootheden; het is geen test waarvoor een verbinding slaagt of zakt. Een uitslag onder de gekozen bitrate is aanleiding om de geplande opstelling te onderzoeken. Die uitslag toont niet aan dat een specifieke stream zou mislukken. Een uitslag erboven garandeert evenmin een geslaagd evenement. De route naar de streamingdienst, veranderingen tijdens het evenement, ander netwerkverkeer en het apparaat waarop de encoder draait blijven van belang.

Dat onderscheid helpt ook bij budgetkeuzes. Wie 14,128 Mbps als algemene aankoopvoorwaarde ziet, geeft mogelijk geld uit voordat de werkelijke instellingen en prestaties zijn gecontroleerd. Wie een hogere uitslag als garantie ziet, slaat misschien de proefuitzending over. Geen van beide conclusies volgt uit deze metingen.

Een nuttigere volgorde is: kies de gewenste instellingen voor beeld, beweging en geluid, noteer de bijbehorende hoeveelheid data per seconde en test de echte uitzending. Deze analyse geeft geen vaste vermenigvuldigingsfactor voor bandbreedte en geen advies om een duurder abonnement te nemen.

We controleerden of de bevinding afhing van één vergelijkingswaarde. Vooraf legden we ook 10,128 Mbps en 17,128 Mbps vast, afgeleid van andere aanbevolen encoderinstellingen in dezelfde YouTube-tabel.^[2] De volledige resultaten staan in de downloadbare analyse.

In het downloadbereik van 100 tot minder dan 300 Mbps leverde de lagere vergelijkingswaarde aandelen op van 18,9% op 1 oktober en 18,1% op 8 oktober. Bij de hogere waarde waren dat 28,0% en 26,8%. De noemers bleven 212.675 en 194.290 meetparen. Vanaf 300 Mbps liepen de bijbehorende aandelen van 7,9% tot 11,0% op 1 oktober en van 7,1% tot 10,2% op 8 oktober, op basis van 237.588 en 221.617 meetparen. De instelling verandert de vergelijking. Er bestaat dus geen enkel percentage voor ‘streaming’.

We herhaalden de berekening ook zonder meetparen waarvan de upload- of downloadsamenvatting nul was. In sommige verwerkingspaden kan nul ontstaan als eindmetingen ontbreken. Een nul in de bron bewijst daarom niet automatisch dat er niets is overgedragen.^[6] In het bereik van 100 tot minder dan 300 Mbps werd de uitkomst 51.313 van 212.136 meetparen (24,2%) op 1 oktober en 45.047 van 193.832 (23,2%) op 8 oktober. Vanaf 300 Mbps waren dat respectievelijk 22.122 van 236.909 (9,3%) en 18.764 van 220.928 (8,5%). Door nullen weg te laten veranderde elk van de vier hoofdpercentages op beide dagen met minder dan 0,3 procentpunt. Het praktische verschil bleef bestaan.

Binnen één serversoftwaregroep was de verandering groter. Voor versie v0.25.2 in het bereik vanaf 300 Mbps daalde het aandeel uploads onder 14,128 Mbps van 4.803 van 26.338 meetparen (18,24%) op 1 oktober naar 1.418 van 21.217 (6,68%) op 8 oktober. Dat verschil hoort naast het hoofdresultaat te staan. Het laat zien waarom een percentage uit deze analyse geen algemene planningsregel mag worden.

Dit bewijst niet dat de software de verandering veroorzaakte. De samenstelling van netwerken, apparaten, routes en meetclients kan per dag verschillen. Dezelfde client kan ook vaker voorkomen, waaronder op beide datums. Daarom publiceren we alle uitsplitsingen naar dagdeel, clientbibliotheek en serverversie. Zo kunnen lezers die variatie bekijken en hoeven ze niet alleen op één totaalcijfer af te gaan.^[1]

Begin met het zichtbaar houden van de uploaduitslag. Noteer waar en wanneer je de controle deed, met welk apparaat en welke verbinding, en wat er verder op het netwerk gebeurde. Dat maakt de uitslag later beter te begrijpen. Het helpt ook voorkomen dat een meting op één plek als bewijs voor een andere locatie wordt gebruikt.

Oefen daarna het deel van de demo dat het meest van de echte opstelling vraagt. Bij een productrondleiding kan dat schermdelen zijn terwijl je praat en wisselt tussen camera en product. Bij een fysieke demonstratie kunnen beweging en gedetailleerde close-ups belangrijk zijn. Gebruik de geplande encoder, het account, het platform en de verbinding, zodat de proefuitzending antwoord geeft op de vraag voor dit evenement. YouTube adviseert zelf te testen met representatief geluid en beweging en de streamstatus te volgen.^[2]

Geef elke representatieve scène een naam in je notities: openingsbeeld, demonstratie van dichtbij, rondleiding met schermdelen, vragen uit het publiek. Noteer wanneer elke scène begint en welke details een waarnemer moet kunnen zien of horen. Treedt er een probleem op, leg dan de scène, het tijdstip en het zichtbare of hoorbare verschijnsel vast. Zo kunnen presentator en waarnemer hun notities vergelijken.

Houd waarnemingen en verklaringen uit elkaar. ‘Het beeld haperde tijdens het schermdelen’ is een waarneming die het noteren waard is. ‘Onze internetprovider veroorzaakte het’ is een diagnose waarvoor meer bewijs nodig is. Een korte M-Lab-meting kan niet de oorzaak vaststellen van een probleem op een andere route naar een streamingdienst.

Laat de proefuitzending een probleem zien, verander dan één onderdeel van de geplande opstelling en test opnieuw. Herhaal dezelfde scène en noteer welke instelling veranderde, welke omstandigheden gelijk bleven en wat iedere waarnemer zag. Noteer ook onvermijdelijke verschillen, zoals een ander apparaat dat het netwerk ging gebruiken. Een betere hertest zegt iets nuttigs over die poging, maar isoleert geen oorzaak als ook andere omstandigheden veranderden. Verandert de vorm van de uitzending, test die nieuwe vorm dan in plaats van op de eerdere uitslag te vertrouwen.

Bepaal ten slotte wat het publiek krijgt als de live demonstratie wordt onderbroken. Een vooraf gemaakte video of schriftelijke uitleg kan het verhaal overbrengen terwijl het team de onderbreking oplost. Wijs iemand aan die dit materiaal tijdens het evenement beschikbaar houdt. Ons videoscriptsjabloon kan helpen bij de voorbereiding. Ons onderzoek naar marketing voor ontwikkelaars en documentatie behandelt een verwante vraag: welk nuttig materiaal zet je naast een video?

Neem een fictief softwarebedrijf met vijf medewerkers dat een live demonstratie voor nieuwe gebruikers voorbereidt. De veronderstelde snelheidstest geeft 180 Mbps download en 11 Mbps upload. Deze cijfers verduidelijken het werkblad; ze beschrijven geen waargenomen bedrijf in de M-Lab-data.

Het team wil H.264-video in 1080p met 30 beelden per seconde en stereogeluid gebruiken. De gemeten upload in dit voorbeeld ligt onder de aanbevolen bitrate van 14,128 Mbps die we in dit onderzoek als vergelijking gebruiken. Het team noteert de upload naast de geplande encoderinstellingen, zodat het die kan vergelijken met de waarnemingen tijdens de demonstratie.

Het team plant een proefuitzending met dezelfde laptop, verbinding, encoder en presentatievolgorde als voor het evenement. Eén collega presenteert, een tweede kijkt mee als toeschouwer en een derde noteert de streamstatus van het platform en eventuele zichtbare of hoorbare onderbrekingen. Ze nemen ook het schermdelen op waarbij klanten kleine details in de interface moeten kunnen lezen.

Vooraf spreken ze af wat ze doen als de proefuitzending niet voldoet: een bewust gekozen alternatieve opstelling proberen, opnieuw testen en een korte video met schriftelijke stappen voorbereiden voor het geval een andere vorm nodig is. We veronderstellen hier geen geslaagde proefuitzending of betere prestaties. Het voorbeeld eindigt met een concreet plan om het ontbrekende bewijs te verzamelen.

Begin met het evenement. Kopieer het volledige voorbereidingsblad zonder registratie naar je evenementnotities en bewaar het bij het script. Noteer het publiek, de locatie, de geplande datum en begintijd, de presentator en de collega die meekijkt als toeschouwer. Benoem het moment dat kijkers het duidelijkst moeten kunnen zien of horen.

Beschrijf de geplande opstelling. Noteer streamingplatform, apparaat, encoder en verbinding, gevolgd door resolutie, beeldsnelheid, videocodec en ingestelde video- en audiobitrates. Vermeld welke andere activiteit je op het apparaat of netwerk verwacht. Zo beschrijven de notities de bedoelde omstandigheden.

Bewaar de aparte snelheidstest. Noteer datum, tijd, locatie en hulpmiddel en daarna zowel download als upload, met eenheden. Beschrijf waarin die controle verschilt van de geplande uitzendopstelling. Zonder context is een uitslag later moeilijker te begrijpen voor een collega.

Leg de proefuitzending vast. Benoem de werkelijk geteste volgorde, inclusief beweging, geluid en schermdelen. Bewaar waarnemingen vanuit het publiek samen met de streamstatus van het platform. Veranderde je een instelling, noteer dan wat er bij de volgende test gebeurde. Vul deze velden na het testen in. Laat onafgeronde controles als onafgerond staan en wijs voor elke controle iemand aan.

Beslis hoe je de demo gaat geven. Noteer welke vorm en instellingen je na de proefuitzending kiest en waarom. Benoem welk alternatief materiaal klaarstaat bij een onderbreking en wie het publiek over een wijziging informeert. Houd de nuttige uitleg ook na het evenement beschikbaar. Een sjabloon voor YouTube-beschrijvingen helpt om de video en bijbehorende links te ordenen voor klanten die er niet bij konden zijn.

We gebruikten de openbare M-Lab NDT7-unionweergave voor records met een geolocatie in de VS op 1 en 8 oktober 2026. Elk opgenomen meetpaar bestond uit precies één upload- en één downloadrecord met hetzelfde autorisatietoken en dezelfde serveridentiteit. Beide metingen begonnen binnen de gekozen UTC-dag, met maximaal 60 seconden ertussen. Aanvullende controles betroffen de klokken, verbindingsidentificatoren en bronversies.^[1][3]

Na deze controles en het uitsluiten van ongeldige snelheden bleven 745.186 meetparen over op 1 oktober en 698.882 op 8 oktober. Ontbrak de bijbehorende upload of download, dan werd het paar uitgesloten; ontbrekende metingen kregen nooit nul als waarde. Elk tabelpercentage deelt het aantal onder de vergelijkingswaarde door het aantal behouden meetparen in dat downloadbereik op die datum.

Eerder onderzoek koppelde al M-Lab-upload- en downloadmetingen en onderzocht hun context.^[4] Onze bijdrage is deze gedateerde, reproduceerbare vergelijking voor een praktische vraag over uitzendplanning. Ze beschrijft de geselecteerde metingen, niet hoe vaak trage uploads voorkomen onder Amerikaanse bedrijven of makers.

De download zonder registratie bevat het vastgelegde protocol, de exacte query's, bronnotities, alle selectieaantallen en alle 264 vooraf geplande resultaatcellen per dag.^[8] Daarin zitten overlappende uitsplitsingen, geen 264 onafhankelijke onderzoeken. Het offlinescript reproduceert de berekeningen op geaggregeerde data; de bronquery's opnieuw uitvoeren is een aparte stap. Voor de volgende demo is de praktische actie kleiner: bewaar de uploaduitslag, oefen de echte presentatie en kies op basis van wat het team waarneemt hoe je die gaat geven.