UDP-multicastuitgang

Adressering

Gebruik voor distributie binnen een gebouw het administratief begrensde bereik, 239.0.0.0/8. Dat is het multicast-equivalent van 10.0.0.0/8: gereserveerd voor lokaal gebruik, nooit gerouteerd naar het openbare internet, en veilig toe te wijzen zonder een register te raadplegen. Wijs per zender een groep toe en houd de toewijzing schriftelijk bij, want een botsing tussen twee zenders is dezelfde storing als een dubbele zender en ziet er ook zo uit.

Gebruik 224.0.0.0/24 niet. Dat blok is gereserveerd voor link-local-besturingsprotocollen — routeringsadjacencies, IGMP zelf en neighbour discovery op sommige apparatuur. Video die daarnaartoe wordt gestuurd, wordt afgeleverd bij elk apparaat op het segment en verwerkt door control-plane-code die geen 38 Mbps verwachtte. Castmux waarschuwt wanneer een bestemming in dat bereik valt in plaats van die direct te weigeren, in de veronderstelling dat u misschien bewust iets test, maar in productie moet u die waarschuwing als een fout behandelen.

Unicastbestemmingen worden geaccepteerd en zijn de juiste keuze voor een punt-tot-puntverbinding: een ander kopstation voeden over een gerouteerd pad, een zender aanleveren aan een recorder of compliance-logger, of testen vanaf een laptop die niet op het televisie-VLAN zit. Achter een unicastzender zit geen IGMP-membership, dus on-demand streaming kan er geen kijkers voor detecteren en de zender moet altijd aan blijven.

Bereik	Gebruik
239.0.0.0/8	aanbevolen Administratief begrensd. De juiste keuze voor distributie binnen het gebouw.
224.0.0.0/24	vermijden Gereserveerd voor link-local-besturingsprotocollen. Castmux waarschuwt als een zender hiernaar verwijst.
Unicastadres	punt-tot-punt Geaccepteerd. Geschikt voor een ander kopstation of een recorder. Geen kijkerdetectie, dus laat de zender altijd aan staan.

Datagramgrootte

De payload van elk datagram is 1316 bytes, precies zeven transportpakketten van 188 bytes. Dat getal is niet willekeurig, en het loont om te begrijpen waarom het de enige verstandige keuze is.

Een transportpakket is 188 bytes en kan niet over datagrammen worden verdeeld zonder dat een ontvanger het weer moet samenvoegen. Zeven ervan zijn 1316 bytes; met 8 bytes UDP-header en 20 bytes IPv4-header komt dat op 1344 — ruim binnen een Ethernet-MTU van 1500 bytes, met ruimte voor een VLAN-tag. Acht pakketten zouden 1504 bytes payload zijn en zouden worden gefragmenteerd.

Minder dan zeven pakketten per datagram versturen is toegestaan, maar op twee manieren verspillend. Elk datagram draagt dezelfde 28 bytes header, hoe vol het ook is, dus een stream met halfgevulde datagrammen besteedt voor dezelfde video ongeveer twee keer zoveel aan headeroverhead en twee keer zoveel verwerking per pakket op het ontvangende apparaat. Belangrijker nog: sommige settopboxen gaan slecht om met onvolledige datagrammen. Een decoder die uitgaat van zeven pakketten per datagram, of die buffert op aantal datagrammen in plaats van op aantal bytes, geeft sporadische artefacten die alleen op sommige modellen optreden en op een pc-speler vrijwel niet te reproduceren zijn.

Hier verschillen de twee engines. De pass-through-engine verstuurt 100% van de tijd volledige datagrammen van 1316 bytes. De remux-engine vult ze ongeveer 85% van de tijd, en verstuurt een kort datagram telkens wanneer zijn interne muxer een framegrens bereikt. Daarom legt Castmux de pakketgrootte op HLS-zenders expliciet vast in plaats van de standaardwaarde van de engine te accepteren — zie Streaming-engines voor de volledige vergelijking.

TTL

De standaard is 16. De TTL van een multicastdatagram wordt verlaagd door elke router die het doorstuurt, en begrenst dus hoe ver het verkeer kan reizen.

TTL 1

Het datagram verlaat het lokale segment nooit. In één gebouw met het apparaat en de televisies op hetzelfde VLAN is dit meestal de juiste waarde, en het is een nuttig vangnet: een configuratiefout kan geen video naar de rest van het netwerk laten lekken.

TTL 16 (standaard)

Maakt doorsturen over een handvol routerhops mogelijk. Gekozen als standaard omdat het zowel in het platte als in het gerouteerde geval werkt, en omdat een stream die niet aankomt een lastiger te diagnosticeren storing is dan een die iets verder reist dan nodig.

Hogere waarden

Alleen nodig waar een router bewust multicast tussen VLAN’s doorstuurt, wat vereist dat de netwerkbeheerder PIM of een equivalent heeft geconfigureerd. Het verhogen van de TTL laat multicast op zichzelf niet door een router gaan.

Uitgaande interface

Een zender kan een bronadres krijgen, en de engine bindt zijn socket daaraan. Dat is nuttig om het bronadres van het verkeer voorspelbaar te maken, voor firewallregels en om op een segment met meer dan één apparaat te herkennen van welk apparaat een stream afkomstig is.

Het bronadres binden kiest niet de uitgaande interface

Dit is het duurste misverstand bij multicastinstallaties. Een socket binden aan 192.168.10.5 betekent niet dat de pakketten de NIC verlaten die 192.168.10.5 heeft. De kernel raadpleegt nog steeds de routeringstabel om de uitgaande interface te bepalen, en voor multicast wordt die beslissing genomen door de route voor 224.0.0.0/4. Wijst die route naar de verkeerde NIC, dan verlaat het verkeer de verkeerde NIC, welk bronadres u ook hebt gebonden.

Erger nog: niets binnen het proces kan het detecteren. sendto() naar een bestemming die naar een nutteloze plek wordt gerouteerd, slaagt gewoon, dus elke teller in de gebruikersinterface staat op gezond terwijl geen enkele televisie iets ontvangt. Castmux controleert de routeringstabel van buiten het streamingpad en meldt de situatie, maar kan die niet oplossen.

Zie Probleemoplossing → multicastroutering voor het lezen en corrigeren van de routeringstabel, en Installatie om de correctie een herstart te laten overleven.

Uit hetzelfde feit volgen nog twee punten. Corrigeer het bereik, 224.0.0.0/4, niet afzonderlijke groepen: een hostroute per groep repareert de zenders die u vandaag toevallig hebt en laat elke later toegevoegde zender ongemerkt onrouteerbaar. En routewijzigingen met ip route overleven geen herstart, dus ze moeten worden geïnstalleerd als een unit die bij het opstarten draait.

Constante bitrate

Sommige apparatuur verderop in de keten, en sommige oudere settopboxen, werken beter met een transportstream met constante bitrate dan met een die de bron volgt. Opvullen tot CBR betekent null-pakketten invoegen zodat de rate op de lijn vlak is, wat de video ook doet.

De remux-engine kan dit, omdat hij zijn eigen transportstream bouwt en kan bepalen hoeveel daarvan opvulling is. De pass-through-engine kan het niet: hij stuurt de pakketten van de bron ongewijzigd door en heeft geen mechanisme om null-pakketten in te voegen — dezelfde eigenschap waardoor hij de oorspronkelijke PID’s behoudt en verlies aan de bronzijde getrouw meldt. U kunt niet beide hebben.

Op het DVB-C-pad speelt deze vraag niet. Een DVB-C-draaggolf heeft per definitie een constante bitrate en de multiplexer vult die op, dus een zender die voor een multiplex bestemd is, heeft geen CBR op zijn UDP-uitgang nodig.

Constante bitrate per zender op gewone UDP-uitgang, los van de engine instelbaar, staat op de roadmap.

Servicenamen

Een televisie of settopbox die een multicastgroep scant, toont de naam die de transportstream in zijn Service Description Table opgeeft. Op de pass-through-engine schrijft Castmux de zendernaam in de SDT, dus de naam die u in de webinterface typt, is de naam die op het scherm verschijnt.

De remux-engine schrijft geen SDT. Zenders op die engine verschijnen onder de naam die het ontvangende apparaat verzint, meestal het groepsadres of een generieke placeholder. Is de naam op het scherm belangrijk en staat de bron het toe, gebruik dan de pass-through-engine.

Dubbele zenders

Twee processen die naar dezelfde groep en poort verzenden, leveren een stream op die een verweving van beide is. Continuity counters spreken elkaar tegen, PID’s botsen, en op het scherm ziet u blokvorming en haperend geluid dat komt en gaat.

Deze storing is ongewoon lastig te diagnosticeren, omdat beide zenders er volkomen gezond uitzien. Elk levert een geldige stream op de juiste bitrate; bij elk staan de meetwaarden op groen. De op de lijn gemeten bitrate is ongeveer het dubbele van wat hij zou moeten zijn; dat is de enige aanwijzing, en die wordt makkelijk aan iets anders toegeschreven.

Castmux zoekt daarom vóór het starten van een zender naar andere zenders op het bestemmingsadres en de poort, en meldt de situatie in plaats van er bovenop te starten. De klassieke oorzaak is niet twee Castmux-zenders — de gebruikersinterface voorkomt dat — maar een oudere service die naast een nieuwe installatie is blijven draaien: een vorige streamer die uitgeschakeld maar niet gestopt is, of een systemd-unit die elke nacht door een cron-regel wordt herstart.

Een unit uitschakelen houdt cron niet tegen om hem te starten

systemctl disable verwijdert alleen de symlink voor het opstarten. Een regel systemctl restart in de crontab van root start de oude service nog steeds, volgens schema, voor altijd. Migreert u een apparaat van een pakketinstallatie naar een container, controleer dan de crontab en gebruik systemctl mask.

Dummy-listeners

Wanneer niets op het netwerk zich bij een multicastgroep heeft aangemeld, is er geen ontvanger die tegendruk geeft, en bij sommige combinaties van kernel en driver kan de verzendbuffer van de socket overlopen in plaats van simpelweg pakketten weg te gooien. Het symptoom is sporadische verzendfouten op een zender waar niemand eens naar kijkt.

Castmux kan voor elke groep een lokale afnemer in stand houden die zich bij de groep aanmeldt en het verkeer leest en weggooit. Zo blijven de groepsmembership en het buffergedrag gelijk, of er nu echte kijkers zijn of niet. Dit staat standaard aan en kost heel weinig; er is geen reden om het uit te schakelen, tenzij u iets meet en de groep echt zonder aanmeldingen wilt hebben.

Let op de wisselwerking met on-demand streaming: de dummy-listener telt bewust niet als kijker. Zou hij dat wel doen, dan zou geen enkele on-demand-zender ooit stoppen.

De uitvoer controleren

Drie controles, oplopend in hoeveel ze bewijzen.

Speel eerst de groep af vanaf een machine op hetzelfde segment:

# ffplay, on a host in the same VLAN as the appliance
ffplay udp://@239.10.0.1:1234

# The @ is required. Without it ffplay listens on a unicast socket
# and never joins the group, so you will see nothing and blame the encoder.

Gebruik in VLC Media → Open Network Stream (Netwerkstroom openen) en voer dezelfde URL in:

udp://@239.10.0.1:1234

Gebruik daarna de browserpreview in de webinterface. Die bevestigt dat de bron binnenkomt en correct wordt voorbereid, maar bewijst niets over het multicastpad, omdat de preview daar niet overheen loopt.

Lees ten derde, en dat is het nuttigst, de tegel UDP-bitrate op de zenderkaart. Die waarde wordt gemeten met pakketcapture op de interface, van de lijn af, en niet door de engine gemeld. Het is daarmee het enige signaal dat er niet van afhangt of de engine de waarheid over zichzelf vertelt, en het is voor beide engines dezelfde meting. Een zender waarvan de engine beweert te draaien maar waarvan de UDP-bitrate nul is, is niet in de lucht.

Beeld op een laptop is geen bewijs

Zit uw laptop op dezelfde switch als het apparaat en zitten de televisies achter een uplink, dan vertelt een geslaagde ffplay u dat de stream bestaat, maar niets over of IGMP-snooping op de tussenliggende switch hem doorstuurt. Test vanaf het segment waar de televisies op zitten, of vanaf een televisie.