SPICA NetworksTalk to Engineering

CDN++ / Distributed Media Delivery

One segment. The right delivery mode.

CDN++ controls the media path from SRT contribution and per-program routing through GPU or CPU ABR transcoding, HLS packaging and the WCPP origin layer—then extends toward distributed and operator-local delivery when the network supports it. HLS2SRT provides the complementary no-re-encode path from adaptive HLS inputs into contribution-grade MPEG-TS over SRT or UDP.

Compare delivery modes Review the transcoding path Open HLS2SRT
LIVE CHANNEL / ACTIVEPOLICY CONTROLLED
SOURCE + PROCESSLive / FAST / VODSRT · NVENC / x264 · HLS
ONE HOT OBJECTSPICA EDGEWCPP origin · Cache · Policy
01HTTP/3Universal unicast
02Private edgeOperator-local
035MBSNetwork fan-out
ONE MEDIA OBJECTTHREE DELIVERY PROFILES
SRT + UDPControlled contribution
GPU + CPUTwo ABR processing paths
HLSReviewed live packaging path
HTTP + 5MBSMulti-mode delivery design

Controlled delivery chain

From contribution signal to the subscriber edge.

CDN++ is not an isolated cache. It is a vertically integrated operating path in which each layer has a defined responsibility for quality, protection, latency, routing and cost.

  1. 01SOURCE

    Ingest + inspect

    Receive SRT, UDP, HLS and MPEG-TS sources, probe their streams and select the service or program that belongs in the processing path.

  2. 02PROCESS

    Separate programs

    Discover programs, preserve their elementary streams and fan an MPTS into isolated SPTS or UDP workers without re-encoding the contribution feed.

  3. 03TRANSCODE

    Build the ABR ladder

    Use CUDA and NVENC for accelerated renditions or a libx264 CPU path, with one supervised processing lane for each selected program.

  4. 04PACKAGE

    Package + control

    Create HLS master, video and audio playlists with MPEG-TS segments. CMAF, DASH, DRM and deterministic SCTE-35 splicing remain explicit integration tracks.

  5. 05SERVE

    Origin + deliver

    Expose media and catalog data through WCPP, keep hot objects close to the network path and select HTTP edge, operator-local or 5MBS delivery.

Transcoding fabric / Source reviewed

IMPLEMENTATION EVIDENCE IN SUPPLIED CODE

The real processing path, from contribution to CDN origin.

The supplied projects now connect the complete working model: contribution gateway, program discovery, MPTS separation, per-program transcode workers, HLS packaging and WCPP media services. The diagram distinguishes that reviewed path from the SCTE-35 and SSAI work that still needs production hardening.

MEDIA PATH / SOURCE REVIEWEDONE SUPERVISED LANE PER PROGRAM
  1. 01CONTRIBUTION

    Ingest + probe

    SRT caller/listener, managed UDP and HLS or MPEG-TS intake with stream and program inspection.

    SRT · UDP · HLS · TS
  2. 02PROGRAM ROUTER

    MPTS to SPTS

    PAT/PMT-aware selection and per-program UDP fan-out keep video, audio and data streams together.

    PROGRAM MAP · PID FILTER
  3. 03ABR WORKERS

    GPU + CPU ladder

    CUDA deinterlace and scale with NVENC, plus a separate libx264 path for three-rendition processing.

    NVENC · CUDA · X264
  4. 04PACKAGER

    HLS output

    Master, variant and audio playlists use MPEG-TS segments with a reviewed six-second live profile.

    MASTER · VIDEO · AUDIO
  5. 05ORIGIN + EDGE

    WCPP + CDN++

    The C++ media API, catalog and controlled asset roots connect the packaged stream to edge-delivery policy.

    API · ORIGIN · DELIVERY
CONTROL PLANEProgram discovery · worker lifecycle · restart · manifest health
SCTE-35 / AD+ LANECue schedule + carriage → policy decision → deterministic spliceTransport exists in the supplied work; the splice boundary remains under hardening.
CURRENT REVIEWED OUTPUT: HLS WITH MPEG-TS SEGMENTSCMAF · DASH · DRM remain platform integration tracks
SOURCE REVIEWED

Accelerated ladder

The supplied orchestration builds 720p and 540p H.264 renditions with CUDA filtering and NVIDIA NVENC while retaining the source video lane.

720P / 3 Mb/s · 540P / 1.6 Mb/s
SOURCE REVIEWED

CPU ladder

An independent libavcodec and libavfilter implementation decodes once, splits the frame graph and encodes three x264 renditions.

1080P / 6.5 · 720P / 3.5 · 480P / 1.5 Mb/s
SOURCE REVIEWED

Program supervision

One demultiplexer discovers services and launches isolated encoder and packager workers, with restart and manifest-freshness logic represented in the supplied supervisor variants.

PROGRAM DISCOVERY · WORKER CONTROL
HARDENING TRACK

SCTE-35 + SSAI

Cue fixtures, scheduling, transport and HLS ad markers are present. Deterministic timestamp handling and single-owner playlist generation are still required before production splicing.

CUE CARRIAGE · AD+ POLICY
PRODUCTION BOUNDARY

Working media code still needs deterministic operations.

The implementation proves the architecture and its component responsibilities. These are the specific engineering gates that separate the reviewed prototype and deployment scripts from a supportable 24×7 transcoding service.

  • Normalize timestamps across demux, filter, encoder and muxer time bases
  • Align GOP and IDR boundaries across every rendition in the ABR set
  • Preserve SCTE-35 data through transcode paths instead of dropping it
  • Give one component ownership of each manifest during SSAI updates
  • Add bounded restart backoff, per-rendition freshness checks and metrics
  • Externalize source URLs, port ranges and GPU mapping; run unprivileged
Concept visualization of CDN++ distributed media infrastructure
CDN++ / DISTRIBUTED MEDIA FABRICIngest · Process · Protect · Cache · Deliver

BossTV / CDN++ engineering lineage

CREATOR-OWNED SOFTWARE + INFRASTRUCTURE

Built in software. Operated on real head-end infrastructure.

BossTV is the OTT application created by Diego Cardona—not a separate project in this portfolio. These published videos document the application across phone, tablet and television, together with the head-end and datacenter equipment he owns and operated for transcoding and media distribution.

The footage is presented here as operational evidence behind CDN++: application experience, media control, physical infrastructure and delivery engineering connected as one system.

01 / APPLICATION

BossTV across the viewer experience.

Five published views—from mobile interaction to the living-room interface.

MOBILE APPLICATION / IPHONE

BossTV on iPhone

A short product view of the BossTV experience running on iPhone.

Open on YouTube
TABLET APPLICATION / IPAD

BossTV on iPad

The same owned application experience presented for the larger iPad interface.

Open on YouTube
INTERACTIVE VIDEO / COMMERCE

Swipe-to-commerce workflow

A viewer moves from the active channel into an in-video purchase workflow using a swipe interaction.

Open on YouTube
MOBILE APPLICATION / ANDROID

BossTV on Android

A product view of the BossTV television experience on an Android phone.

Open on YouTube
LIVING ROOM APPLICATION / APPLE TV

BossTV on Apple TV

A longer walkthrough of the large-screen BossTV interface and navigation model.

Open on YouTube
02 / INFRASTRUCTURE

Head-ends and datacenter operations.

Owned equipment and operational environments used for transcoding, control and distribution.

DATACENTER / OPERATIONS

BossTV LA operations

Operational footage from the environment used to manage video services and media workflows.

Open on YouTube
HEAD-END / VIDEO STREAMING

Kings Mountain head-end

Equipment racks and the physical head-end environment behind video acquisition and distribution.

Open on YouTube
HEAD-END / TRANSCODING + DELIVERY

BossTV head-end 02

A second infrastructure walkthrough showing the owned equipment, cabling and operational media environment.

Open on YouTube

WCPP / CableKiller media service

SOURCE REVIEWED / IMPLEMENTED SERVICE

A real C++ backend now grounds the media-control layer.

The supplied WCPP source is not a presentation mockup. It implements a multithreaded Crow service that connects media applications to a MongoDB program catalog, local artwork and HLS/MP4 assets. This validates an important CDN++ building block while keeping its production boundary explicit.

01MONGODB

Program data

MongoDB-backed station and airing collections expose schedule, title, TMS identifier and local artwork metadata to client applications.

02REST / JSON

Discovery API

Crow routes support station, time-window, title and program-ID queries plus bounded catalog retrieval and airing counts.

03HLS / MP4

Media + artwork

The service resolves local program images and delivers HLS playlists, MPEG-TS segments and MP4 assets from controlled filesystem roots.

04C++20 / CROW

Concurrent service

A C++20 executable uses Crow's multithreaded server model and the MongoDB C++ driver as a compact backend for media applications.

MEDIA SERVICE / ROUTE MAPHTTP : 3000
RUNTIMEC++20 + Crow
DATAMongoDB / JSON
MEDIAHLS · TS · MP4
CATALOGStations · Airings
MethodRouteImplemented purpose
GET/stationsList station records
GET/airingsReturn a bounded airing catalog
GET/airings/imagesResolve program artwork by TMS ID and start time
GET/airings/by-station-timeQuery selected stations inside a time window
GET/airings/by-timeQuery all airings inside a time window
GET/airings/by-station/:stationIdRetrieve one station's airings
GET/airings/searchSearch program titles
GET/airings/tms/:tmsIdFind airings by program identifier
GET/airings/count/:stationIdCount airings for one station
GET/streaming/<path>Serve HLS, MPEG-TS and MP4 media
GET/images/stations/<path>Serve locally managed program artwork
DELETE/airings/:stationIdAdministrative station-airing cleanup
PRODUCTION BOUNDARY

Implemented service does not mean finished public API.

The reviewed source proves working routes, data access and media delivery. Before an Internet-facing deployment, the service still needs a formal security, streaming-efficiency and operations pass.

  • Authenticated and role-separated administrative operations
  • Canonical filesystem containment and normalized asset paths
  • Byte-range or chunked responses instead of whole-file buffering
  • Validated queries, escaped search input, pagination and database indexes
  • Consistent TLS, CORS, observability, quotas and rate controls

AD+ / Interactive monetization

PRODUCT ARCHITECTURE / IN DEVELOPMENT

The delivery path can also carry a controlled interaction path.

AD+ is the interactive advertising product architecture built on CDN++. It combines stream timing, publisher policy and efficient 3D assets so viewers can deliberately explore, respond or continue to commerce across Live and VOD.

Explore AD+
CDN++ MEDIA / ACTIVEPLAYER CONTROLLED
LIVE / VOD
SCTE-35
AD+ EXPERIENCE MANIFESTPolicy · Consent · Device · Campaign
01OverlayPoll / offer
02glTF3D product
03HandoffSecond screen

SSAI may stitch media; the interactive layer stays in the publisher-controlled player.

  1. 01

    Timed opportunity

    SCTE-35 and application metadata identify an eligible moment without embedding viewer-interface logic in the media object.

  2. 02

    Policy resolution

    AD+ evaluates publisher rules, consent state, device capability and campaign eligibility before resolving an experience manifest.

  3. 03

    Player interaction

    A compatible player retains playback authority while rendering an opt-in overlay, poll, offer or optimized glTF product asset.

  4. 04

    Measured outcome

    Documented events connect impression, open, close, selection, device handoff and commerce outcomes to an auditable workflow.

Hybrid by design

Do not force every audience through the same path.

A sparse VOD audience and a stadium-scale live audience are different network problems. CDN++ preserves a universal HTTP path while defining increasingly integrated options for operators.

MODE / 01DEPLOYABLE PATH

Distributed HTTP edge

The universal path for current televisions, phones, browsers and OTT applications. Every viewer receives an independent HLS or DASH flow from the closest available cache.

  • HTTP/3 + QUIC
  • Live, FAST and VOD
  • HLS / DASH / CMAF
  • Works across public IP networks
MODE / 02OPERATOR INTEGRATION

Operator-local delivery

Place CDN++ nodes on a private interconnect or near an operator user plane so popular media avoids unnecessary public-transit distance and remains under a defined service boundary.

  • Private peering or VRF
  • Regional or on-premises edge
  • Local breakout proximity
  • Operator-defined routing + QoS
MODE / 035MBS ROADMAP

Network-assisted fan-out

For dense audiences watching the same live rendition, a 5G SA operator may use 5MBS so one MBS session feeds multiple radio nodes and point-to-multipoint radio resources.

  • MB-SMF + MB-UPF
  • IP multicast / SSM where available
  • 5MBS-capable RAN
  • MBS-aware device delivery
WHAT CDN++ DOES NOT CLAIM

An ordinary UPF is not a broadcast cache.

Content storage stays in the media edge. The user plane handles forwarding, tunneling, QoS and—when explicitly supported—MBS-session distribution. Exact vendor feature support must be confirmed for the operator's deployed product and software release.

Operator-integrated edge

Store once. Move deliberately. Replicate in the right layer.

The control plane decides what should happen. The application plane owns media and policy. The accelerated dataplane moves packets. The mobile core and RAN create network and radio fan-out.

01SPICA media infrastructure

CDN++ application plane

Stores media objects, authorizes access, manages manifests, DRM, cache state and delivery policy.

02NIC / SmartNIC / DPU / switch

Accelerated dataplane

Moves, classifies, encapsulates and—where the network design permits—replicates packets with minimal CPU copying.

03UPF / MB-UPF

Mobile user plane

Applies forwarding, tunneling, QoS and MBS-session treatment. It is not treated as a general-purpose content library.

04gNB / UE integration

RAN + receiver

Creates the real radio-efficiency gain through point-to-multipoint delivery and presents received media to the player workflow.

Reference live stream

A small object becomes a very large concurrency problem.

At a 5 Mb/s reference bitrate, one three-second segment contains approximately 1.875 MB before protocol overhead. The bytes are not the hard part; repeating the same bytes across many independent subscriber and radio paths is.

5 Mb/s × 3 s ÷ 8≈ 1.875 MBper viewer, every three seconds
HTTP UNICASTN viewers × one independent flow
5MBS SERVICE AREAOne MBS session × participating areas

Conceptual comparison; actual capacity depends on renditions, service areas, radio configuration and implementation.

Demand-aware control

Switch by service area—not by guesswork.

  1. 01
    Measure local demand

    Count viewers by channel, rendition, service area, device capability and current network path—not only at national level.

  2. 02
    Compare delivery cost

    Evaluate aggregate unicast traffic against the cost of establishing and operating an MBS bearer in that area.

  3. 03
    Activate the efficient path

    Keep sparse audiences on unicast and move dense, synchronized audiences to the operator-assisted path when every prerequisite is met.

  4. 04
    Return without disruption

    Fall back to unicast as demand, coverage or device support changes. Thresholds belong to operator policy and radio planning.

Carrier prerequisites

5MBS is an integration program, not a CDN switch.

A private access circuit alone does not prove access to a mobile core. The production design requires confirmed interconnection, network functions, transport, RAN features and a compatible receiver path.

LayerUniversal baselineOperator-assisted path
InterconnectionInternet transit or conventional peeringPrivate VRF / NNI terminating near the operator service network
Mobile coreConventional EPC or 5GC unicast user plane5G SA with confirmed MB-SMF and MB-UPF feature support
TransportIndependent unicast tunnels and HTTP flowsIP multicast / SSM where supported, with defined unicast fallback
Radio accessOne radio flow per subscriber5MBS point-to-multipoint resources in selected service areas
Device pathStandard HLS / DASH request-responseMBS-aware reception with a player-compatible local delivery abstraction

Technical basis

Standards first. Vendor release second.

3GPP defines MB-SMF and MB-UPF as network functions. Public vendor portfolio pages describe user-plane product families, but they do not by themselves confirm MB-UPF support in a specific operator deployment. That confirmation belongs in engineering discovery.

3GPP 5G multicast and broadcast overview

Official overview of the 5MBS architecture and service model.

3GPP TS 23.247 archive

Normative architecture family for 5G multicast-broadcast services.

Ericsson Packet Core Gateway

Public product information for Ericsson's cloud-native user-plane gateway.

Ericsson Local Packet Gateway

Public product information for an integrated edge user-plane deployment.

Reference distribution model

Economics that remain explicit.

The existing planning model compares a $0.004/GB CDN++ delivery rate with an illustrative $0.04/GB conventional-CDN benchmark. It is a scenario model, not a quotation or guaranteed saving.

SPICA CDN++ PLANNING RATE$0.004/GB

HTTP/3 routing, caching and distributed edge delivery.

ILLUSTRATIVE BENCHMARK$0.04/GB

Comparison value only; not attributed to a named provider.

ILLUSTRATIVE DIFFERENCE≈90%

Before scope, geography, commitment and interconnection adjustments.

Monthly trafficDelivered dataCDN++ modelBenchmark
10 TB10,000 GB$40$400
1 PB1,000,000 GB$4,000$40,000
10 PB10,000,000 GB$40,000$400,000
100 PB100,000,000 GB$400,000$4,000,000
UNICAST DIMENSIONINGbitrate × concurrent viewers

Every active viewer remains an independent network and radio flow.

5MBS DIMENSIONINGchannels × renditions × service areas

The scale unit changes, but bearer, device and operator constraints remain.

Reference planning model only. Final pricing depends on committed traffic, geography, concurrency, peering and transit, redundancy, node placement and service scope. Contribution, transcoding, DRM, applications, dedicated connectivity and operator 5MBS integration are scoped separately. Decimal units are used.

Capability status

What belongs to CDN++ now—and what requires the carrier.

CDN++ PLATFORMSOURCE REVIEWED + ARCHITECTED

Media processing and HTTP edge

  • C++20 / Crow media and program-guide service
  • MongoDB-backed station and airing discovery
  • SRT, UDP, HLS and MPEG-TS contribution paths
  • PAT/PMT-aware filtering and per-program fan-out
  • CUDA / NVENC accelerated ABR processing
  • Three-rendition libx264 CPU processing path
  • HLS MPEG-TS master, variant and audio packaging
  • Supervised per-program encoder and packager workers
  • CDN++ origin, HTTP edge and delivery-policy architecture
JOINT ENGINEERINGOPERATOR ROADMAP

Carrier-integrated distribution

  • Private operator VRF / NNI
  • Regional edge or local-breakout proximity
  • IP multicast and Source-Specific Multicast
  • SmartNIC / DPU / ASIC packet offload
  • 5G SA MB-SMF / MB-UPF integration
  • 5MBS-capable RAN and receiver path
  • Demand-aware unicast / MBS switching

SPICA Networks engineering

Design the delivery path before scaling the audience.

Talk to Engineering