Zenders en bronnen

Wat een zender is

Eén bron plus één bestemming. De bron is een URL waar Castmux van ophaalt; de bestemming is een IPv4-adres en poort waar het MPEG-TS naartoe stuurt. Al het andere op de zender — engine, resolutieprofiel, on-demand-gedrag, verwachte bitrate — bepaalt hoe die ene pijplijn draait, niet wat hij transporteert.

Zenders zijn onafhankelijk. Elke zender wordt afzonderlijk bewaakt, afzonderlijk herstart en afzonderlijk gemeten, dus een uitgevallen originserver bij één zender stoort de andere niet.

Brontypen

Via IP worden vandaag vier brontypen ondersteund: HLS, SRT, RTMP en gewone MPEG-TS, die laatste via UDP-multicast of via HTTP. De tabel hieronder toont wat verder wordt ondersteund en wat gepland is.

Bron	Status	Opmerkingen
HLS	Ondersteund	Masterplaylist of één mediaplaylist. Zie resolutieprofielen voor hoe een trede wordt gekozen.
SRT	Ondersteund	Caller-modus, volledig geconfigureerd via de URL. De latency wordt automatisch bepaald.
RTMP	Ondersteund	Alleen met de remux-engine. Meestal een lokale encoder die naar het netwerk van het apparaat pusht.
UDP-multicast (MPEG-TS)	Ondersteund	Een bestaande multicastfeed opnieuw ontvangen, zoals de uitvoer van een ander kopstation. Brontype mpegts met een udp://-URL. Zie MPEG-TS-bronnen.
HTTP MPEG-TS	Ondersteund	Een gewone transportstream via HTTP, zonder playlist. Brontype mpegts met een http://- of https://-URL.
RTP-multicast	Roadmap	Transportstream verpakt in RTP. Vandaag wordt alleen gewone MPEG-TS via UDP gelezen. roadmap
RTSP-camera's	Roadmap	Voor beelden uit de lobby, de kapel en van CCTV. roadmap
DVB-S/S2-tuneringang	Roadmap	Satellietzenders die uit de ether worden ontvangen in plaats van via IP. Vandaag niet beschikbaar: er is geen enkele tuneringang, dus koop hiervoor geen tunerkaart. roadmap
DVB-T-tuneringang	Roadmap	Terrestrische zenders die uit de ether worden ontvangen. roadmap
DVB-C-tuneringang	Roadmap	Zenders van een kabelnet ontvangen in plaats van via IP. roadmap

HLS-bronnen

Geef de zender de URL van een masterplaylist. Castmux leest de ladder die daarin wordt aangeboden en kiest één variant om aan de engine te geven, volgens het resolutieprofiel van de zender. Zonder profiel — de standaard, en wat elke bestaande zender heeft — wordt de masterplaylist ongewijzigd doorgegeven en beslist de volgorde van de originserver.

De startpositie ten opzichte van de live edge is instelbaar. Verder terug in de playlist beginnen levert robuustheid op tegen een originserver die onregelmatig segmenten publiceert, ten koste van een grotere achterstand op live en een trager eerste beeld na het wisselen van zender.

fMP4/CMAF-originservers vereisen de remux-engine

De HLS-lezer van de pass-through-engine verwerkt alleen MPEG-TS-segmenten. Publiceert de originserver gefragmenteerde MP4-segmenten (CMAF), dan moet die zender de remux-engine gebruiken. Dit is een eigenschap van de lezer, geen instelling — geen enkele combinatie van opties laat de pass-through-engine fMP4 verwerken. Zie Streaming-engines.

SRT-bronnen

SRT-zenders draaien in caller-modus: Castmux maakt zelf verbinding met de originserver. De volledige configuratie staat in de URL, en de volgende queryparameters worden naar de engine vertaald:

streamid, passphrase, transtype, latency, rcvlatency, peerlatency, rcvbuf, sndbuf, maxbw, pbkeylen, payloadsize, tlpktdrop, linger.

srt://origin.example.net:9000?streamid=play/news&passphrase=••••••••&transtype=live

Automatische latency

Castmux meet de round-trip time naar de originhost en stelt het SRT-latencybudget in op vier keer de gemeten RTT, met een ondergrens van 200 ms en een bovengrens van 4000 ms. Een latencywaarde in de URL wordt vervangen.

Dit bestaat omdat de gebruikelijke standaard van 120 ms fout is op elke verbinding met echte jitter, en omdat niemand de resulterende storing aan latency toeschrijft. Een te klein budget legt de zender niet plat; het veroorzaakt sporadische artefacten — af en toe een paar seconden blokvorming, zonder voorspelbaar interval, op een zender waarvan het dashboard volledig groen is. Locaties jagen wekenlang op de encoder, de switch en de televisie voordat iemand een transportinstelling verdenkt die is gekopieerd van een andere installatie met een korter pad.

De vermenigvuldiger is de gangbare SRT-aanbeveling: een ontvanger moet een hertransmissie kunnen afwachten, wat een volledige round trip kost, met ruimte voor een tweede poging. De ondergrens voorkomt dat een heel korte verbinding een budget krijgt dat te klein is om enig verlies op te vangen; de bovengrens voorkomt dat één slechte meting seconden vertraging aan een zender toevoegt.

Wilt u de waarde liever zelf vastleggen, schakel het gedrag dan uit met overwrite_srt_latency: false in de globale configuratie; de latency in de URL blijft dan ongemoeid.

Listener- en rendezvous-modus

Beide zijn vandaag bereikbaar door engineparameters in de URL mee te geven, maar ze zijn niet in de interface uitgewerkt: er is geen veld dat zegt “luister op deze poort”, en niets valideert wat u typt. Volwaardige ondersteuning voor listener- en rendezvous-zenders staat op de roadmap.

RTMP-bronnen

RTMP wordt ondersteund op de remux-engine en wordt normaal gebruikt voor een lokale encoder op hetzelfde netwerk als het apparaat, niet voor een feed die via internet binnenkomt.

RTMP werkt niet op de pass-through-engine

Dit is geen afstemmingsprobleem of ontbrekende optie. Zet u een RTMP-zender op de pass-through-engine, dan draait hij niet. Laat zulke zenders op de remux-engine staan, of stel op de zender een engine-overschrijving in als uw globale standaard pass-through is.

MPEG-TS-bronnen

Brontype mpegts neemt een transportstream aan zoals die binnenkomt, zonder playlist en zonder container eromheen. Het URL-schema bepaalt het transport:

# a multicast group, e.g. another headend's output
source:
  type: mpegts
  url: udp://239.20.0.5:1234?localaddr=192.168.10.4

# a continuous transport stream over HTTP
source:
  type: mpegts
  url: https://origin.example.net/news/mpegts

Via UDP meldt de zender zich bij de groep aan en leest hij transportstreamdatagrammen precies zoals ze binnenkomen. De URL accepteert drie optionele parameters, voor beide engines op dezelfde manier geschreven:

• localaddr is het lokale adres waarop de groep wordt ontvangen. Stel dit in op een apparaat met meerdere interfaces, zodat de join uitgaat via de interface die naar de afzender wijst.
• sources beperkt de ontvangst tot één afzender, voor source-specific multicast.
• buffer_size is de ontvangstbuffer van de kernel in bytes. De standaard is ruim, zodat een haperende scheduler geen datagrammen laat vallen.

Via HTTP leest de zender één eindeloos antwoord, zoals de /mpegts-uitvoer van een streamingserver. Sluit de originserver de verbinding, dan herstart de zender, net als bij elke andere bronstoring.

Enkele dingen verschillen van de andere brontypen:

• Resolutieprofielen zijn niet van toepassing. Een transportstream draagt één vaste weergave, en er is geen ladder om uit te kiezen.
• Een zender kan zijn eigen uitvoer niet ontvangen. Een udp://-bron die gelijk is aan het eigen bestemmingsadres en de eigen poort van de zender, wordt bij het opslaan geweigerd. Anders zou de engine eindeloos opnemen wat hij net had verzonden, terwijl de bitratemeter een gezonde zender meldde. De groep van een andere zender lezen is toegestaan, en is een bewuste manier om de ene zender aan de andere te koppelen.
• Alleen gewone transportstream wordt gelezen. Een multicastfeed verpakt in RTP wordt nog niet ondersteund.

De bestemming

Eén IPv4-adres en één poort. Het adres kan een multicastgroep zijn, het normale geval bij televisiedistributie, of een unicastadres voor één ontvanger of een test.

Gebruik voor multicast het administratief begrensde bereik 239.0.0.0/8. Dat is precies voor dit doel gereserveerd — privé gebruik binnen een organisatie — dus niets wat u daarbinnen kiest, kan botsen met een bekende toewijzing.

Gebruik 224.0.0.0/24 nooit voor content

Dat bereik is gereserveerd voor link-local-besturingsprotocollen: routeringsadjacency, IGMP zelf en neighbour discovery zitten daar allemaal. Pakketten die daaraan zijn geadresseerd, worden verzonden met een TTL van één en door elk apparaat op het segment verwerkt. Een televisiezender daar plaatsen overspoelt uw switches met control-plane-verkeer en verstoort het netwerk lang voordat iemand merkt dat het beeld ontbreekt.

Vandaag één bestemming per zender. Dezelfde zender naar meerdere groepen sturen — bijvoorbeeld één multicastgroep en één unicastprobe — vereist een tweede zender met dezelfde bron-URL. Meerdere bestemmingen per zender staan op de roadmap.

Instellingen per zender

active

Of de zender überhaupt wordt bewaakt. Een inactieve zender behoudt zijn configuratie, maar wordt nooit gestart en levert geen meetwaarden op.

force_always_on

Laat de zender draaien, of er nu iemand kijkt of niet. De standaard is uit, wat on-demand betekent: de zender draait alleen zolang er een kijker op zijn groep wordt gedetecteerd. Stel dit in voor zenders die bij het zappen nooit de koude-startvertraging mogen hebben. Zie On-demand streaming.

engine

Overschrijf voor deze zender de globale enginekeuze. Leeg betekent overnemen. Zie Streaming-engines.

resolution_profile

Welke trede van een HLS-ladder wordt genomen. Leeg betekent de masterplaylist ongewijzigd gebruiken. Wordt genegeerd voor SRT en RTMP, die geen ladder hebben. Zie Resolutieprofielen.

min_output_kbps

De uitgangsbitrate waaronder deze zender wordt beschouwd als een zender die niets oplevert, en die dus een herstart nodig heeft.

Radiozenders hebben een lagere bitrate-ondergrens nodig

De globale standaard voor de minimaal verwachte uitgangsbitrate gaat uit van video. Een service met alleen audio zit daar terecht ver onder — 128 kbps is een gewone radiobitrate — dus met de globale ondergrens wordt die bij elke controle stil verklaard en eindeloos herstart terwijl hij perfect werkt. Stel min_output_kbps op die zender in op een waarde die ruim onder de werkelijke rate ligt.

Een zender een naam geven

De zendernaam is niet alleen een label in de interface. Hij wordt de DVB-servicenaam in de SDT, en dat is wat een televisie in haar zenderlijst toont; en het is het label dat aan elke meetwaarde van de zender hangt.

Dat tweede gevolg is waar mensen over struikelen: een zender hernoemen hernoemt zijn meetreeksen. Historische gegevens volgen de nieuwe naam niet, dus een dashboard of alert op basis van de oude naam valt stil, en een grafiek van de zender lijkt vanaf nul te beginnen. Leg de namen vast voordat u dashboards bouwt, en behandel hernoemen als een handeling met kosten verderop in de keten, niet als een cosmetische wijziging.

Zenderidentiteit

Zenders worden geïdentificeerd met een geheel getal als id. Die id staat in het configuratiebestand, in de HTTP-API en overal waar van buitenaf naar een zender wordt verwezen.

Id’s worden momenteel na verwijdering hergebruikt. Verwijdert u zender 7 en voegt u daarna een nieuwe zender toe, dan kan de nieuwe id 7 krijgen. Het is in elk opzicht dat voor een beheerder telt een andere zender — andere naam, andere bron, andere bestemming — maar alles wat op de id is gebaseerd, ziet continuïteit waar die er niet is.

De praktische gevolgen zijn goed om te weten voordat u op id’s vertrouwt:

• Alles wat status per zender opslaat op basis van de id — een externe planner, een opgeslagen API-aanroep, een bladwijzer in de interface — kan na een cyclus van verwijderen en toevoegen naar de verkeerde zender wijzen.
• Browsers herstellen bij een gewone herlaadactie de status van formulierelementen, los van wat de server heeft gerenderd, dus een nieuw aangemaakte zender kan kort een instelling tonen die is overgenomen van de verwijderde zender die zijn id had. Wat de badge naast het element zegt, is de waarheid.
• Bij DVB-C wordt de service-identiteit afgeleid van de positie in een multiplex en niet van de zender-id, dus het herschikken of verwijderen van een zender verschuift de services eromheen.

Stabiele, niet-hergebruikte identificaties en vastgelegde service-identiteit staan op de roadmap. Tot die tijd is de veilige regel: een id identificeert een plaats, en een naam identificeert een zender.

Zenders die met de licentie worden geleverd

Een licentie kan naast toestemming om te streamen ook een zenderlijst bevatten. Bij elke licentiecontrole vergelijkt het apparaat die zenderlijst met zijn eigen zenders. Elke zender legt vast wie de eigenaar is (managed_by in het configuratiebestand), en daaruit volgen twee regels:

• Een zender die de licentie heeft geleverd, is van de licentieserver. Bij elke controle worden de bron, bestemming, het resolutieprofiel, de altijd-aan-modus en de aan/uit-status bijgewerkt naar wat de server stuurt, zodat een zender die verhuist zonder bezoek ter plaatse wordt gecorrigeerd. Vermeldt de server hem niet meer, dan wordt hij verwijderd. De webinterface markeert deze zenders en laat ze niet bewerken of verwijderen, omdat de volgende controle de wijziging ongedaan zou maken.
• Een zender die u zelf hebt toegevoegd, wordt nooit aangeraakt. De server wijzigt of verwijdert hem nooit, ook niet als de zenderlijst een zender met dezelfde naam bevat. De enige uitzondering is een zender die u hebt uitgeschakeld: die draait niets, dus een gelicentieerde zender met dezelfde naam of bestemming mag hem overnemen. Daardoor werkt het migreren van een ouder apparaat zonder eerst de oude zenders te verwijderen.

De licentie legt ook een maximum vast voor het aantal zenders dat tegelijk mag draaien. Een gelicentieerde zender boven die limiet wordt uitgeschakeld toegevoegd in plaats van weggelaten, zodat een groter abonnement later alleen een kwestie is van inschakelen, niet van opnieuw invoeren. De limiet geldt ook voor zenders die u zelf toevoegt: een zender die wordt toegevoegd terwijl de limiet al is bereikt, komt uitgeschakeld binnen, met een melding waarom.

Een gelicentieerde zender die zou verzenden naar een groep die een andere draaiende zender al gebruikt, wordt geweigerd in plaats van te mogen botsen, en hetzelfde geldt voor een zender die de server zonder bron-URL of bestemming heeft gestuurd. Weigeringen worden zowel in de webinterface getoond als gelogd, zodat “de server heeft niets gestuurd” te onderscheiden is van “het apparaat heeft geweigerd wat hij stuurde”.

Uitgewerkt voorbeeld

Twee zenders in config.yaml — één HLS-zender met een resolutieprofiel, één SRT-zender met een verlaagde bitrate-ondergrens omdat het een radioservice is:

streams:
  - id: 1
    name: BBC One
    description: Reception and lounge
    active: true
    source:
      type: hls
      url: https://origin.example.net/bbcone/master.m3u8
    destination:
      address: 239.1.1.10
      port: 5000
    # Televisions here are 720p panels; the origin lists 1080p first.
    resolution_profile: hd
    force_always_on: true

  - id: 2
    name: Classic FM
    description: Audio only
    active: true
    source:
      type: srt
      url: srt://origin.example.net:9000?streamid=play/classicfm&transtype=live
    destination:
      address: 239.1.1.11
      port: 5000
    # Radio: well under the video-oriented global floor, so lower it or the
    # channel is treated as silent and restarted forever.
    min_output_kbps: 64
    force_always_on: true

Op de SRT-URL staat geen latency, omdat Castmux die afleidt uit de gemeten round trip. Op geen van beide zenders staat een engine, dus beide nemen de globale standaard over.