DVB service ID mapping for OTT packages starts at ingest
DVB service ID mapping for OTT packages sounds like housekeeping until a channel lands in the wrong slot, the guide shows yesterday's schedule, or a regional bundle points viewers to the wrong language feed. The problem rarely starts inside the app. It usually starts at ingest, where satellite metadata is read, renamed, normalized, and passed downstream as if every identifier meant the same thing.
For licensed satellite sourced channels, your platform needs a stable identity chain. The service found in the transport stream has one set of identifiers. Your catalog may use another. The EPG provider may use a third. Your app API may expose a public channel ID that must not change every time an upstream feed moves. If the mapping is loose, one transponder update can turn into a catalog incident.
Treat identifiers from the satellite feed as source evidence, not as your public product IDs. The platform should preserve them, compare them, and alert on changes, but your catalog needs its own stable channel identity.
ETSI EN 300 468 defines Service Information for DVB systems and includes tables such as PAT, PMT, SDT, NIT, and EIT. MPEG transport streams commonly use 188-byte packets. The Program Association Table is carried on PID 0x0000, the Service Description Table is associated with PID 0x0011, and the Event Information Table is associated with PID 0x0012 in DVB SI workflows. Those numbers are not trivia. They are the signals your ingest and monitoring chain reads before a channel becomes a clean OTT catalog item.
The practical job is to keep those identifiers visible without letting them leak into customer-facing naming. A channel can change transponder or update descriptors while the public channel entry remains stable. That split saves your support team from explaining why a familiar channel suddenly changed ID in the app because an upstream service table moved.
Which identifiers to capture before catalog handoff
Start with the fields that help your team prove what changed. At minimum, capture original network ID, transport stream ID, service ID, service name, provider name, PMT PID, video PID, audio PID list, subtitle or caption references when present, and EIT availability. If your receiver or monitoring system exposes signal readings and table version numbers, store those too.
DVB service ID mapping for OTT packages becomes easier when every field has an owner. The ingest engineer owns what appears in the incoming transport stream. The catalog owner decides the public name, package placement, and app grouping. The EPG owner maps schedules and time zones. The operations lead signs off before a source identifier change is allowed to modify a live package.
A simple mapping table prevents most incidents:
| Layer | Example field | Why it matters | Who should approve changes |
|---|---|---|---|
| Satellite source | Original network ID, TS ID, service ID | Confirms the service actually received at ingest | Ingest operations |
| Program map | Video, audio, subtitle PIDs | Prevents silent audio or wrong language selection | Engineering QA |
| Catalog | Internal channel UUID | Keeps apps stable when upstream identifiers move | Catalog owner |
| Guide | EPG station ID and timezone | Controls schedule accuracy and replay labels | EPG operations |
| Package | Region and tier assignment | Protects commercial and territory rules | Content operations |
The internal channel UUID is the one field that should not be casually regenerated. Once apps, watchlists, recommendations, and support tools depend on it, changing it can create more damage than the original feed update. Preserve the UUID and update the source mapping behind it unless the channel is genuinely being retired.
Write down naming rules as well. Do not let one operator write "Channel HD", another write "ChannelHD", and a third use the provider's temporary descriptor. Those small differences become duplicate rows in the catalog, mismatched EPG entries, and confused monitoring alerts.
Change detection that catches real feed moves
Satellite channel packages change. A provider may move a service to a new transport stream, add an alternate audio track, rename a descriptor, adjust EIT behavior, or replace an SD feed with an HD version. Your workflow should detect the change, but it should not automatically rewrite the public catalog without review.
Set alerts for the changes that matter. A service ID change on the same expected source should trigger a review. A missing PMT should raise a high-severity incident because the receiver may not have enough program information to decode the service. A changed audio PID list should trigger QA, especially for regional packages where language tracks drive customer satisfaction. A service name descriptor change should create a ticket, not an instant public rename.
Use thresholds that fit channel operations. For example, one missed table read during a receiver restart is noise. A service missing for three consecutive monitoring intervals is different. A provider name change may be harmless. A new video PID with no matching test playback is not harmless. The rules should match the kind of failure your team can act on.
Real-world example: a 40-channel regional package can look fine from a lineup count perspective while still hiding five risky changes. One channel may have a new service ID, two may have swapped audio priority, one may have lost EIT present/following data, and one may have changed provider descriptors after a source maintenance window. If the launch checklist only asks "do all 40 channels play," the package passes. If the mapping diff is reviewed, the risky channels get tested before customers see them.
Keep raw source snapshots for at least the last known good state and the current state. The storage footprint is tiny compared with video, and the operational value is high. When a partner asks what changed, your team can point to the source metadata diff instead of arguing from memory.
EPG and API handoff rules for stable apps
The app should not have to understand every upstream satellite identifier. It needs a stable channel ID, a display name, a logo reference, package availability, playback URL, and guide data that matches the service. That is the handoff contract. Everything else is evidence behind the scenes.
DVB EIT data can support schedule workflows, but many OTT operators still rely on a separate EPG provider or a curated schedule feed. That creates a mapping problem: the satellite service ID must line up with the guide station ID, the catalog channel UUID, and the regional package. A mistake in any one of those joins can create a visible issue even when the video plays perfectly.
Use an ordered handoff before a new package goes live:
- Lock the source mapping after ingest QA confirms the service IDs, program maps, and expected audio tracks.
- Create or update the internal channel UUID without changing it for routine source moves.
- Match the EPG station ID and timezone to the catalog entry, then test at least current, next, and next-day schedule entries.
- Verify API output for the channel in every package where it appears, including unavailable regions.
- Run playback from the same URL path the app will receive, not a temporary engineering link.
- Record the approver and timestamp before the package is released to customers.
The third step deserves extra attention. Timezone mismatches do not always show up as obvious failures. A guide can look populated but still be offset by one hour. Daylight saving changes make this worse in multinational packages. Test using events with known start times, not only whether the guide row exists.
API caching can also hide mapping mistakes. If your backend caches channel objects for several minutes, a correction may appear in the admin tool before it appears in apps. Build cache purge or version checks into the launch workflow so the person approving the package sees the same data a viewer receives.
QA checks before a regional package launch
Regional packages make DVB service ID mapping more sensitive because similar channel names may appear in multiple language, country, or time-shifted versions. A one-character suffix may be the only visible difference between two services in the source table. Your catalog should not depend on a human spotting that difference at 2 a.m.
Build a QA sheet that compares expected package entries with actual source mappings. Include the public channel name, internal channel UUID, source service ID, TS ID, EPG station ID, primary audio language, backup audio language, captions, region, and playback status. For a 25-channel launch, the sheet is manageable. For a 200-channel catalog, it becomes a necessary control.
Three benchmarks are worth using during QA. First, MPEG TS packet size is commonly 188 bytes, so transport-level analysis tools should report the expected packet structure before higher-level checks matter. Second, PAT on PID 0x0000 should be readable when analyzing program associations. Third, DVB SI workflows rely on tables such as SDT and EIT to describe services and events; if your monitoring cannot read them reliably, it is working blind for catalog verification. These benchmarks come from MPEG-TS and DVB SI practice, with ETSI EN 300 468 defining the DVB service information layer.
Do not let QA stop at a spreadsheet. Play the channel from the app path, check the guide row, switch audio tracks where available, open the same channel from another regional package if it appears twice, and confirm that an unavailable region does not receive a playable entitlement. The boring checks are the ones that catch embarrassing launch mistakes.
Support also needs a mapping lookup. If a customer reports "Channel 18 has the wrong schedule," the agent should be able to find the public channel, internal UUID, source service ID, EPG station ID, and current package within one tool or one documented path. Without that lookup, every ticket becomes an engineering investigation.
What to do when source identifiers change
When a provider changes source identifiers, slow down the catalog update. The correct response is not always to mirror the upstream change. Sometimes the public channel stays the same and only the source mapping changes. Sometimes the provider has replaced the service with a different regional feed, and the catalog must be reviewed. Sometimes the feed is wrong and should not be published at all.
Use a three-step decision. First, confirm whether the new identifiers carry the expected video, audio, and schedule evidence. Second, compare the rights and package rules attached to the old service. Third, decide whether the public channel UUID remains, is remapped, or is retired. That decision should be logged because it affects app history, user favorites, reporting, and support references.
If the change is urgent, avoid editing multiple systems manually. Update the source mapping in the system of record, trigger API refresh, purge relevant cache, and run a narrow QA pass. Manual changes in the receiver, catalog, and EPG tool may fix the screen for an hour but leave the platform inconsistent the next time automation runs.
DVB service ID mapping for OTT packages is not glamorous work. Good mapping rarely gets praise because nothing appears to happen. The guide stays correct, the app opens the right channel, regional packages remain clean, and support can trace a complaint without guessing. That is the point. Stable channel identity is part of the product, even when customers never see the identifiers behind it.