Native C++ command plane
WCPP, Crow and MongoDB hold channel intent, catalog state, policy and operational APIs while agents reconcile that intent on the media nodes.
CDN++ / Private Real-Time Media Infrastructure
One media fabric. From signal to every screen.
CDN++ connects resilient contribution, Cisco high-speed networking, NVIDIA media processing, protected packaging, WCPP native C++ control, RAM/NVMe origin and HTTP/3 edge delivery as one observable operating path. HLS2SRT supplies the complementary no-re-encode gateway into SRT or UDP transport.
CHANNEL OBJECT / ACTIVEEND-TO-END CONTROL
ACQUIRE + NORMALIZE + PROCESSLive / FAST / VODSRT · MPEG-TS · NVIDIA · CMAF
CONTROL + ORIGINWCPP + SPICA EDGEC++20 · Crow · RAM/NVMe · Policy
01HTTP/3Universal unicast
02Private edgeOperator-local
035MBSNetwork fan-out
96Documented Cisco UCS servers
216NVIDIA A16 cards
100 GbEPer documented Ethernet port
2.21 PBRaw NVMe in the C220 tier
North-star architecture
Six media stages. Three operating planes. One accountable channel.
CDN++ is designed as a private media cloud rather than a collection of unrelated transcoders and caches. Media moves through explicit high-throughput stages; commands, evidence and trust follow separate planes so no application UI becomes the source of operational truth.
- 01ACQUIRE
Contribution intake
Receive primary and backup satellite or IP feeds and establish an authenticated, observable source boundary.
SRT · RIST · UDP/RTP · HLS - 02NORMALIZE
Media gateway
Demultiplex MPTS, create independent SPTS services and normalize program maps, clocks and timed metadata without an unnecessary re-encode.
PAT/PMT · PCR/PTS/DTS · SCTE-35 - 03PROCESS
GPU media factory
Decode once, build the ABR ladder and process audio, captions, thumbnails and quality signals in supervised workers.
CUDA · NVENC · CPU - 04PACKAGE
Protect + package
Create a common segment layer, publish HLS and DASH manifests and apply rights, encryption and advertising policy at explicit boundaries.
CMAF · HLS · DASH · DRM - 05ORIGIN
Hot media tier
Keep live manifests and hot segments in RAM/NVMe, replicate origin state and tier longer retention into durable storage.
RAM · NVMe · DVR/VOD - 06DELIVER
CDN++ edge
Authorize and route each request through the universal HTTP path, a private edge or an operator-assisted delivery profile.
NGINX · HTTP/3 · QUIC
Design rule: media packets remain on the media plane; lifecycle commands, business state and telemetry travel through bounded control and observability interfaces.
Physical foundation / Documented configuration
The architecture is grounded in real Cisco and NVIDIA capacity.
The March 2023 CCI/Cisco bills of material describe two deliberately different server pools: GPU-rich C240 M7 media compute and RAM/NVMe- dense C220 M7 origin and cache. Redundant 100 GbE paths connect those roles without collapsing the complete platform into one machine type.
Cisco media fabric
Cisco routing and redundant high-speed paths separate contribution, processing, origin, delivery and management traffic.
- 100 GbE per documented port
- Redundant fabric design
- QoS · VRF · common time
72 × UCS C240 M7
The processing pool pairs dual 40-core CPUs with three NVIDIA A16 cards per server for parallel media workloads.
- 216 NVIDIA A16 cards
- 864 GPU processors
- 36 TB aggregate RAM
- AVC / HEVC NVENC baseline
24 × UCS C220 M7
High-memory, NVMe-dense nodes provide the physical foundation for hot origin, shield cache and delivery services.
- 96 TB aggregate RAM
- 2.21 PB raw NVMe
- 4 × 100G port capacity / node
96Cisco UCS servers
7,680Physical CPU cores
132 TBAggregate system RAM
216NVIDIA A16 cards
WHAT THESE NUMBERS MEAN
They establish the class and scale of the physical platform. They do not replace profile-specific tests for streams per GPU, sustained network throughput, cache hit ratio, protected storage capacity, failure reserve, power or cooling. CDN++ publishes measured capacity only after those variables are fixed.
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.
- 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.
- 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.
- 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.
- 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.
- 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
IMPLEMENTED AND RUNNINGThe real processing path, from contribution to CDN origin.
The implemented components 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
- 01CONTRIBUTION
Ingest + probe
SRT caller/listener, managed UDP and HLS or MPEG-TS intake with stream and program inspection.
SRT · UDP · HLS · TS - 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 - 03ABR WORKERS
GPU + CPU ladder
CUDA deinterlace and scale with NVENC, plus a separate libx264 path for three-rendition processing.
NVENC · CUDA · X264 - 04PACKAGER
HLS output
Master, variant and audio playlists use MPEG-TS segments with a reviewed six-second live profile.
MASTER · VIDEO · AUDIO - 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 is implemented; the splice boundary remains under hardening.
Accelerated ladder
The transcoding 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/sCPU 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/sProgram supervision
One demultiplexer discovers services and launches isolated encoder and packager workers, with restart and manifest-freshness logic handled by the supervisor variants.
PROGRAM DISCOVERY · WORKER CONTROLSCTE-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+ POLICYPRODUCTION 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
BossTV / CDN++ engineering lineage
CREATOR-OWNED SOFTWARE + INFRASTRUCTUREBuilt 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.
BossTV on iPhone
A short product view of the BossTV experience running on iPhone.
BossTV on iPad
The same owned application experience presented for the larger iPad interface.
Swipe-to-commerce workflow
A viewer moves from the active channel into an in-video purchase workflow using a swipe interaction.
BossTV on Android
A product view of the BossTV television experience on an Android phone.
BossTV on Apple TV
A longer walkthrough of the large-screen BossTV interface and navigation model.
BossTV on Android TV
The BossTV television experience running natively in an Android TV environment, including large-screen navigation and channel presentation.
BossTV in-app purchase on tvOS
A purchase workflow demonstrated on physical tvOS hardware, connecting the television experience with an actionable commerce path.
BossTV on iPad — application demo
A detailed iPad demonstration of the BossTV interface, content discovery and viewing experience.
02 / INFRASTRUCTURE
Head-ends and datacenter operations.
Owned equipment and operational environments used for transcoding, control and distribution.
BossTV LA operations
Operational footage from the environment used to manage video services and media workflows.
Kings Mountain head-end
Equipment racks and the physical head-end environment behind video acquisition and distribution.
BossTV head-end 02
A second infrastructure walkthrough showing the owned equipment, cabling and operational media environment.
03 / RECEIVER
The client that consumes the delivery.
A native HLS player written to exercise the delivery path end to end.
A delivery architecture is only as good as what the receiver can actually do with it. This C++20 player was written to test that side directly: it demuxes HLS with FFmpeg on a dedicated decode thread, uploads the YUV planes to the GPU and converts them to RGB in a GLSL shader, keeping I420, NV12 and NV21 on the fast path with a CPU sws_scale fallback for anything else.
Audio runs through SDL2 with an EMA-smoothed A/V clock, so the HUD reports the audio clock, the video PTS and the drift between them while the stream plays.
- Three buffer profilesLow-latency, balanced and robust — 24, 60 or 120 queued frames, switchable while playing.
- Master playlist parsingReads master.m3u8 and offers Auto (ABR) or a pinned rendition, with hot switching and no restart.
- Audio track switchingAny track in any mode, with a short grace window after the switch and the preference kept across reconnections.
- Controlled reconnectionBackoff from 250 ms up to 5 s, and a fall back to software decoding when hardware acceleration keeps failing.
Proprietary SPICA software. The screenshot shows the player running an open test stream.
WCPP / CableKiller media service
SOURCE REVIEWED / IMPLEMENTED SERVICENative C++ grounds the application and control layer.
The WCPP media service 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 the native backend direction for CDN++ while keeping a strict production boundary between application decisions and high-volume media-byte delivery.
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.
NATIVE SOFTWARE BOUNDARYNO SCRIPT RUNTIME IN THE MEDIA HOT PATH
C++20 · Crow · mongocxx
Program catalog, application API, authorization and control-plane evolution.
C++ · FFmpeg · CUDA/NVENC
Program routing, decode, filters, ABR encode, audio and quality-control work.
NGINX · HTTP/3 · QUIC
Efficient byte delivery, range handling, cache policy and protection of the application tier.
MongoDB · agents · systemd
Persistent metadata, bounded process lifecycle, health reporting and recovery.
WCPP owns APIs and decisions. NGINX owns efficient segment delivery. C++/FFmpeg/NVENC workers own media processing. That separation keeps Crow out of bulk file copying while preserving a completely native operational stack.
MEDIA SERVICE / ROUTE MAPHTTP : 3000
RUNTIMEC++20 + Crow
DATAMongoDB / JSON
MEDIAHLS · TS · MP4
CATALOGStations · Airings
MethodRouteImplemented purpose
GET
/stationsList station recordsGET
/airingsReturn a bounded airing catalogGET
/airings/imagesResolve program artwork by TMS ID and start timeGET
/airings/by-station-timeQuery selected stations inside a time windowGET
/airings/by-timeQuery all airings inside a time windowGET
/airings/by-station/:stationIdRetrieve one station's airingsGET
/airings/searchSearch program titlesGET
/airings/tms/:tmsIdFind airings by program identifierGET
/airings/count/:stationIdCount airings for one stationGET
/streaming/<path>Serve HLS, MPEG-TS and MP4 mediaGET
/images/stations/<path>Serve locally managed program artworkDELETE
/airings/:stationIdAdministrative station-airing cleanupPRODUCTION 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
- A mongocxx client pool sized for Crow's concurrent request workers
- Canonical filesystem containment and normalized asset paths
- NGINX/sendfile media delivery instead of whole-file application buffering
- Validated queries, escaped search input, pagination and database indexes
- Health, readiness, metrics, TLS, CORS, quotas and rate controls
AD+ / Interactive monetization
PRODUCT ARCHITECTURE / IN DEVELOPMENTThe 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.
- 01
Timed opportunity
SCTE-35 and application metadata identify an eligible moment without embedding viewer-interface logic in the media object.
- 02
Policy resolution
AD+ evaluates publisher rules, consent state, device capability and campaign eligibility before resolving an experience manifest.
- 03
Player interaction
A compatible player retains playback authority while rendering an opt-in overlay, poll, offer or optimized glTF product asset.
- 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.
CDN++ application plane
Stores media objects, authorizes access, manages manifests, DRM, cache state and delivery policy.
Accelerated dataplane
Moves, classifies, encapsulates and—where the network design permits—replicates packets with minimal CPU copying.
Mobile user plane
Applies forwarding, tunneling, QoS and MBS-session treatment. It is not treated as a general-purpose content library.
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
Conceptual comparison. Actual capacity depends on renditions, service areas, radio configuration and implementation.
Demand-aware control
Switch by service area—not by guesswork.
- 01Measure local demand
Count viewers by channel, rendition, service area, device capability and current network path—not only at national level.
- 02Compare delivery cost
Evaluate aggregate unicast traffic against the cost of establishing and operating an MBS bearer in that area.
- 03Activate the efficient path
Keep sparse audiences on unicast and move dense, synchronized audiences to the operator-assisted path when every prerequisite is met.
- 04Return 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 archiveNormative architecture family for 5G multicast-broadcast services.
↗Ericsson Packet Core GatewayPublic product information for Ericsson's cloud-native user-plane gateway.
↗Ericsson Local Packet GatewayPublic 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.
HTTP/3 routing, caching and distributed edge delivery.
Comparison value only; not attributed to a named provider.
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.
Engineering roadmap
Build the operating system before multiplying the nodes.
The roadmap starts with deterministic media behavior, turns the existing gateway and WCPP work into supportable services and only then expands across cells and regions. Each phase has an observable production outcome—not a feature-count milestone.
- 01FOUNDATION / ACTIVE
Define the media contract
Version the input, output, clock, continuity, PSI/SI, SCTE-35 and error behavior expected from every channel.
- 02HARDENING
Productize the gateway
Unify the HLS2SRT and SPTS/MPTS paths around one bounded C++ media core with soak, fault and conformance tests.
- 03NEXT CELL
Operate one complete cell
Schedule resilient ingest, GPU workers, packaging, hot origin and telemetry as one deployable failure domain with N+1 reserve.
- 04PRODUCT SCALE
Make CDN++ declarative
Let WCPP define desired channel state while agents, security policy and observability prove actual state end to end.
- 05EXPANSION
Multi-cell + multi-region
Add active-active routing, regional recovery, operator integration and a future GPU pool when AV1 encoding becomes a product requirement.
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
- Documented Cisco UCS and NVIDIA A16 platform
- 100 GbE-per-port media-network foundation
- 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