DVB-C multiplexing
Why this matters
Section titled “Why this matters”Rewiring a hotel, a hospital ward or a care home is the most expensive thing anyone can propose in a refurbishment meeting. It means lifting floors, chasing walls, closing rooms and losing revenue for as long as the work takes. Very often the proposal is made not because the existing infrastructure is inadequate but because the new system does not speak to it.
The coaxial network is already there, in almost every building of this type, and it already reaches every room. Every television manufactured in roughly the last fifteen years has a DVB-C tuner built in. Putting the channels onto the coax means the estate works as it is: no per-room device to buy, power, mount, update or replace when a guest walks off with it, and no dependence on the wireless network that the same guests are already complaining about.
The trade-off is that a broadcast carrier is a shared, fixed-capacity pipe. Everything else on this page follows from that.
Hardware
Section titled “Hardware”A supported TBS modulator card in a PCIe slot in the appliance. The card does the modulation; Castmux produces the multiplexed transport stream and configures the carrier.
| Parameter | Range |
|---|---|
| Frequency | Approximately 47–1002 MHz, covering the VHF and UHF cable bands. |
| Constellation | QAM 16, 32, 64, 128 or 256. |
| Symbol rate | Approximately 1.0–7.14 MS/s. |
Multiple cards, or multiple outputs, mean multiple multiplexes. One modulator device drives one multiplex; see Limitations.
Capacity arithmetic
Section titled “Capacity arithmetic”A DVB-C carrier has a fixed net bitrate determined entirely by the symbol rate and the constellation:
# Net transport-stream bitrate of a DVB-C carriernet = symbol_rate × log2(QAM) × 188/204The 188/204 term is the Reed–Solomon outer code: each 188-byte transport packet is carried as 204 bytes on the wire, so about 7.8% of the raw capacity is forward error correction and is not available for video.
Net bitrate in Mbps for the combinations you are most likely to use:
| Symbol rate | QAM 16 | QAM 64 | QAM 128 | QAM 256 |
|---|---|---|---|---|
| 5.000 MS/s | 18.4 | 27.6 | 32.3 | 36.9 |
| 6.111 MS/s | 22.5 | 33.8 | 39.4 | 45.1 |
| 6.875 MS/s | 25.3 | 38.0 | 44.3 | 50.7 |
| 6.900 MS/s | 25.4 | 38.1 | 44.5 | 50.9 |
| 6.952 MS/s | 25.6 | 38.4 | 44.8 | 51.3 |
The two common working points are 6.9 MS/s at QAM64, giving about 38 Mbps, and 6.9 MS/s at QAM256, giving about 50.9 Mbps. A higher constellation buys capacity at the cost of noise margin: QAM256 needs a cleaner network than QAM64, and on old coax with corroded connectors and passive splitters that margin may not be there. If televisions at the far end of a run show intermittent blocking, drop the constellation before blaming the source.
Do not fill a multiplex to its limit
Section titled “Do not fill a multiplex to its limit”The arithmetic above gives a theoretical ceiling. Planning to it will produce a multiplex that breaks up at exactly the moments it matters.
Castmux does not transcode, so each service occupies whatever bitrate its source is producing, and sources of the kind used here are variable bitrate. A channel described as “7 Mbps HD” is quoting an average. On a static studio shot it may sit at 3 Mbps; on a crowd pan, confetti, a football pitch or an action sequence it can peak above 10. Several channels peaking at once is not unlikely — it is close to guaranteed at 8pm.
When the sum of the services exceeds the carrier’s capacity, the multiplexer has nowhere to put the excess and packets are dropped. The damage is not confined to the channel that overshot: whatever is dropped comes from the composite stream, so a single greedy service degrades the picture on every service in the multiplex simultaneously.
Setting up a multiplex
Section titled “Setting up a multiplex”A multiplex is defined by a frequency and the parameters of its carrier. Create one and fill in:
| Field | Notes |
|---|---|
| Frequency | Choose from the UHF and VHF channel presets, or enter a frequency directly. The presets exist because most installations are placing carriers on standard cable channel raster positions, and a television's automatic scan finds those faster. |
| Constellation | QAM 16, 32, 64, 128 or 256. See capacity. |
| Symbol rate | Within the card's range, approximately 1.0–7.14 MS/s. |
| Modulator device | Auto-discovered. Devices already assigned to another multiplex are excluded from the list, because a device can only carry one. |
| Network name | Carried in the NIT and displayed by some televisions during a scan. The name of the property is a reasonable choice. |
| Network ID | Identifies the network as a whole. Keep it the same across every multiplex in one building. |
| Transport stream ID | Identifies this multiplex within the network. Must differ between multiplexes. |
Assigning channels
Section titled “Assigning channels”Channels that exist in Castmux appear in an available pool. Drag one onto a multiplex card to add it, and drag within the card to reorder.
Order is not cosmetic. A channel’s position in the multiplex is its slot, and the slot determines both the block of PIDs the service is given and its service ID.
How PIDs are decided
Section titled “How PIDs are decided”Every elementary stream in a transport stream needs a unique packet identifier, and two services using the same PID produce a broken multiplex.
Castmux does not assume what a channel contains. Before building the multiplex it probes the channel’s own multicast output and reads what elementary streams it actually carries — video, each audio track, subtitle streams, teletext. Assuming a fixed layout would be simpler and would be wrong constantly: sources differ in how many audio tracks they carry, whether subtitles are present, and whether the ladder rung selected by a resolution profile carries the same streams as the master.
Each slot is then given a block of 16 PIDs. Sixteen is chosen to cover a realistic worst case — video, several audio languages, several subtitle tracks and teletext — with the blocks kept non-overlapping so that a change in one service can never collide with the next.
Two consequences follow, and both are deliberate:
- A service with more than 16 elementary streams has the excess dropped. The alternative would be to run into the next slot’s block, which corrupts a different channel entirely. Losing the seventeenth stream of one service is a smaller failure than breaking the one next to it, and it is a failure confined to where it started.
- A channel that cannot be probed is left out of the multiplex. It is not added with guessed PIDs. A guess that is wrong produces a service whose PMT points at streams that are not there, which televisions render as a channel that tunes and then shows nothing — a fault that looks like a broken television rather than a missing probe. An omitted channel is visible immediately.
What tables are generated
Section titled “What tables are generated”A DVB receiver needs service information to make sense of a carrier. Castmux generates:
| Table | Purpose | Status |
|---|---|---|
| PAT | Program Association Table. Lists the services in the multiplex and where to find each one's PMT. | generated |
| PMT | Program Map Table, one per service. Lists the elementary streams that make up the service and their PIDs. | generated |
| SDT-Actual | Service Description Table for this multiplex. Carries the name each service displays on the television. | generated |
| NIT-Actual | Network Information Table for this multiplex. Declares the network and this carrier's tuning parameters. | generated |
Not generated yet
Section titled “Not generated yet”Stated explicitly, because each of these is something an installer may reasonably expect and would otherwise discover at commissioning:
| Feature | Why it matters | Status |
|---|---|---|
| LCN | Logical channel numbers put channel 5 on button 5 on every set in the building, instead of whatever order each television happened to find them in. | roadmap |
| NIT cross-linking | A television that finds one multiplex learns from its NIT where the others are, instead of sweeping the whole band to find them. | roadmap |
| TDT / TOT | Time and Date Table and Time Offset Table set the clock on every guest television from the broadcast stream, so nobody has to set them by hand. | roadmap |
| EIT | Event Information Table is the on-screen programme guide. Without it, pressing the guide button produces an empty grid. | roadmap |
Hot-swap
Section titled “Hot-swap”A single slot can be re-pointed at a different source without dropping the carrier. The multiplex keeps running, the other services are undisturbed, and only the swapped service changes what it is showing.
This exists because the alternative is unacceptable in the environments this product serves. Changing one source by rebuilding the multiplex would blank every television in the building for the duration, and in the worst case would leave sets needing a rescan for a change that affected one channel. Swapping in place keeps the service identity intact, so televisions see the same service continuing with different content — which is exactly what a channel change is.
Suspend
Section titled “Suspend”An individual slot can be suspended and resumed without touching the rest of the multiplex. Useful for a channel whose source is being worked on, or one that is only wanted at certain times.
Restarts
Section titled “Restarts”A change to the line-up — adding a channel, removing one, reordering — restarts the whole multiplex. This is blunt and it is deliberate.
The reason is that the service information tables and the elementary streams have to agree. A multiplex that is still advertising a PAT and SDT describing the previous line-up, while carrying the new one, is worse than a multiplex that is briefly absent: televisions tuned to it show a service that exists in the tables and has no packets, or silently keep a stale name against new content, and neither state resolves without a rescan. A short, clean interruption leaves every receiver in a correct state afterwards.
A multiplex that restarts repeatedly in quick succession gives up rather than thrashing. A restart loop on a broadcast carrier is worse than a carrier that is down: each cycle puts every television in the building through re-acquisition, and a stopped multiplex is at least an unambiguous fault that gets investigated. Check the log view for what caused the restarts before resuming it.
A channel cannot be in two multiplexes
Section titled “A channel cannot be in two multiplexes”Each multiplex assigns a service ID from the slot the channel occupies. A channel placed in two multiplexes would need two service identities at once, and the tables generated for each carrier would describe the same content differently. The user interface prevents the assignment rather than resolving it arbitrarily.
If the same content genuinely needs to appear on two carriers, define it as two channels with separate destinations. Note the capacity cost: it is two full copies of the bitrate, not a shared one.
Limitations
Section titled “Limitations”Rescans, and why service identity matters
Section titled “Rescans, and why service identity matters”This is the operational pain that shapes several of the decisions above, so it is worth stating on its own.
A television stores the services it found during its last scan, keyed by identity. When the identity of a service changes, the stored entry no longer matches: the set may show the wrong name against the content, may show a service that no longer has any packets, or may simply lose the channel. The only reliable fix is a rescan, on every affected television.
In a two-hundred-room hotel, a rescan means someone walking into two hundred rooms with a remote control, or a maintenance window that displaces guests. It is measured in days of labour and is by a wide margin the most expensive consequence of any change made on this page.
Since service IDs are currently derived from slot order, any reordering triggers exactly this. The practical mitigation today is to plan the line-up before the building is tuned, leave gaps for channels you expect to add, and use hot-swap rather than reordering when a source changes.
Pinned service identity — a service ID that is fixed to the channel rather than to its position, and guarded against accidental change — is roadmap, and is the proper fix.