Roadmap
The principle
Section titled “The principle”Headend documentation has an unhappy tradition of describing the product the vendor intends to have. That is expensive for the reader, because the gap is discovered at commissioning, on site, with the installer’s van outside and the coax already run. This page exists so the gap is discovered while you are still choosing.
Four groups follow. Now is being written at the moment. Next is committed and specified. Later is planned but not specified in detail, and the ordering within it is the part most likely to move. Not planned is a deliberate refusal, with the reason, so you can rule the product out on it rather than waiting for it.
Now — in development
Section titled “Now — in development”Work in progress. The concentration on DVB-C signalling is not arbitrary: these are the items that decide whether a guest experiences a professional television service or an obviously improvised one, and they are the ones customers ask about first.
| Feature | Why it matters | Notes |
|---|---|---|
| DVB-C | ||
| Logical channel numbers (LCN) | Channel 5 on button 5, on every set in the building, without anyone touching a remote. Without LCN signalling, each television numbers the line-up in whatever order its own scan found the services, so no two rooms agree and no printed channel card can be correct. This is the most requested DVB-C feature by a clear margin. | in development |
| TDT/TOT clock | Sets the time on every guest television from the transport stream. Sets with no clock source show the wrong time on screen, mis-schedule their own timers, and in some models refuse to display any programme information at all. | in development |
| NIT cross-linking between multiplexes | A set that finds one of the site's multiplexes learns about the others from it, instead of sweeping the whole band to find them. On a site with several carriers this is the difference between a scan that takes seconds and one that takes minutes and sometimes misses a carrier entirely. | in development |
| Pinned, guarded service identity | Change the line-up without a building-wide re-tune. Service identifiers are derived from position today, so inserting a channel renumbers everything after it and every television in the building disagrees with the new line-up until it is re-scanned. Pinning fixes an identifier to a channel and guards against a change that would invalidate existing tunings. | in development |
| Operations | ||
| Email and webhook alerting | Channel down, source switched to a backup, multicast route dead. Today these are visible in the interface, which means somebody has to be looking at it. An appliance in a plant room needs to be able to raise its hand. | in development |
| Per-channel restart counter and monthly availability report | Restart frequency is the earliest signal that a source is deteriorating, and it can currently only be recovered by reading logs. A counter per channel makes a marginal origin visible before it fails outright, and a monthly report gives an operator something to take to their content provider. | in development |
Next — committed
Section titled “Next — committed”Specified and scheduled, not yet started or not yet finished. These are commitments rather than aspirations.
| Feature | Why it matters | Notes |
|---|---|---|
| Sources | ||
| RTP multicast input | Take a channel from a multicast group that carries RTP-wrapped transport stream. Plain MPEG-TS over UDP multicast is already supported — see MPEG-TS sources — and covers sitting behind another headend that sends raw TS. What is missing is the RTP framing some encoders and contribution links use. | committed |
| Ordered backup sources with automatic failover and return | A list of sources per channel rather than one, tried in order, with an automatic return to the primary once it is healthy again. Today a failed origin means a failed channel until somebody edits it. | committed |
| Per-channel audio track ordering and language forcing | Decide which language a set selects by default, and in what order the alternatives are offered. Relevant wherever guests do not share one language, and currently determined entirely by the order the origin happens to use. | committed |
| Delivery | ||
| HTTP MPEG-TS and HLS output with access control | Serve the same channels to guest phones and tablets on the site's wireless network, with control over who may watch. Multicast does not cross a typical guest wireless network, so televisions and personal devices need different delivery of identical content. | committed |
| Programme guide | ||
| Programme guide on remux-engine channels | The guide itself ships: XMLTV sources, channel mapping and EIT on the television's own guide — see Programme guide (EPG). The EIT is currently added only to channels on the pass-through engine. A channel that has to use the remux engine, such as an RTMP or fMP4 source, is mapped and shows now-and-next in the interface, but sends no guide to the televisions. | committed |
| Reliability | ||
| Built-in "technical difficulties" slate | Generated automatically to match the primary source's format, so a failed channel shows an explanation instead of a black screen. Black screens generate calls to reception; a caption does not. | committed |
| Per-PID transport-stream breakdown | The transport-stream analyser ships — continuity errors, transport errors, PCR accuracy and bitrate per channel, graphed and exported; see Transport-stream quality. What is still to come is the breakdown by PID, and PES-level errors. Today a channel's counts are summed across its PIDs, so they show that a channel is damaged but not whether it is the video or one audio track. | committed |
| Operations | ||
| Configuration export, import and site cloning | One click to take a working site's configuration and use it as the basis for the next. Today this is a file copy and a careful hand edit, which is workable for one site and tedious across twenty. | committed |
| Users and roles | Reception staff need to see whether a channel is up and restart it. Installers need to change RF parameters. One shared password grants both, which means either the wrong people can break the multiplex or the right people cannot fix a channel at midnight. | committed |
| Prometheus endpoint and supplied dashboard | Metrics in a form existing monitoring already understands, with a dashboard shipped rather than left as an exercise. The metric labels for this are already in the configuration file as location_name and re_seller. | committed |
Later — planned
Section titled “Later — planned”Intended, but not specified in detail and not scheduled. Customer demand moves items up this list, which is the main reason it is published.
| Feature | Why it matters | Notes |
|---|---|---|
| Content services | ||
| In-house information channel generator | A channel the site produces itself: activities, menus, notices, on-site services, a camera view. For care homes this is the highest-value item on the whole list — a resident who cannot easily reach a noticeboard can read today's lunch and this afternoon's activity from an armchair. It is also the feature most often built badly today, with a laptop and a spare HDMI modulator. | planned |
| Sources | ||
| RTSP camera input | Site cameras — entrance, car park, garden — as ordinary channels. Complements the information channel and is frequently asked for alongside it. | planned |
| Tuner input: DVB-S/S2, DVB-T and DVB-C | Take channels off air — from satellite, a terrestrial aerial or an existing cable network — rather than from an IP provider. Every source today arrives over IP, so a site with a dish or an aerial and no IP provider cannot use Castmux yet. Tuner input would remove the dependency on an IP provider for the channels that do not need one, which several sites would prefer. | planned |
| Delivery | ||
| Per-channel constant bitrate on UDP output | Null-pad a channel to a fixed rate. Some set-top boxes and some network equipment behave better with a constant rate, and capacity planning against a variable rate is guesswork with a safety margin bolted on. | planned |
| Multiple destinations per channel | Send one channel to more than one group or unicast address without configuring it twice. Duplicating a channel to achieve this doubles the source bandwidth, which is usually the constrained resource. | planned |
| SAP/SDP announcements | Announce the multicast line-up so compatible receivers and software players discover channels rather than being configured with addresses by hand. | planned |
| DVB-C | ||
| BISS scrambling | Lightweight scrambling for content whose provider requires that it not be received in the clear on a shared cable network. This is not a conditional access system and is not intended to become one. | planned |
| Radio services typed as radio | Audio-only channels signalled with the correct service type, so televisions file them under radio rather than presenting them as television channels with a permanently blank picture. | planned |
| Operations | ||
| Multi-site fleet management | One view across every appliance a reseller has installed, with configuration pushed from it. The natural continuation of export, import and cloning, and dependent on them. | planned |
Not planned
Section titled “Not planned”These will not be built, and the reason is given so you can act on it. Some are exclusions that make the rest of the product possible; the others belong to a different class of equipment.
| Feature | Why it matters | Notes |
|---|---|---|
| Processing | ||
| Transcoding | Not an omission — it is the decision the rest of the product is built on. Passing video through untouched is what allows 25 channels on a fanless 2 GB appliance and what guarantees the picture is exactly what the provider sent. Adding an encoder would cost an order of magnitude in hardware and put a quality loss in every channel to serve a minority that needs one. | not planned |
| DVB-C | ||
| Full conditional access (DVB Simulcrypt) | A CA system with an ECMG, entitlement management and smartcard logistics is a different product sold to a different customer. Attempting it would compromise the simplicity that makes this one installable by one engineer in an afternoon. | not planned |
| DVB-CI descrambling | No CAM support. Sources must arrive in the clear. Descrambling somebody else's encrypted service brings hardware, licensing and contractual obligations that do not fit an appliance of this size. | not planned |
| Delivery | ||
| DVB-T modulator output | The buildings this product is installed in are cabled for DVB-C, so the demand has not appeared. This one is a matter of demand rather than principle: if customers ask for it in numbers, it moves onto the list. | not planned |
| CDN-scale distribution | The target is one building. Origin shielding, edge caching and multi-region distribution are a different architecture, and pretending otherwise would produce a product that is mediocre at both. | not planned |
Influencing priority
Section titled “Influencing priority”The ordering here reflects what customers have asked for, and it changes when they ask for something else. If an item in Later is the one that decides whether Castmux fits your site, say so — a concrete site with a concrete requirement moves an item further than any amount of internal opinion. Write to [email protected] or raise it at your next review.
No dates are given, and that is deliberate rather than evasive. A date attached to an item nobody has started is a guess presented as a commitment, and it decays into an apology. An ordered list, honestly maintained, tells you what will arrive before what — which is the question that actually matters when you are deciding whether to install now or wait.