The Technical Stack — What It Actually Takes to Run a FAST Channel

Most editorial coverage of FAST channels focuses on content and business model. The technical stack is treated as a commodity — pick a platform, upload your content, done. This framing misses how much the technical decisions affect viewer experience, ad revenue, and platform distribution eligibility. This episode is a practical breakdown of the FAST technical stack for operators who want to understand what they're running.

---

The pieces

A live FAST channel has six major technical components:

1. Content ingest and transcoding — your video files converted into streaming-compatible formats
2. Content storage — where your transcoded files live
3. Playout engine — the software that assembles your schedule into a live stream
4. HLS packaging and delivery — the live stream formatted for distribution
5. SSAI (Server-Side Ad Insertion) — ads stitched into the live stream
6. EPG (Electronic Program Guide) — schedule metadata delivered to platforms and viewers

You can build any of these yourself. You can use third-party services for any of them. Most independent operators use some combination of a platform that bundles these (like Vidiyo) and their own tools for specific workflows. Understanding what each piece does helps you evaluate platforms, debug problems, and make better decisions about where to invest.

---

Content ingest and transcoding

Raw video files — whatever format they're in from your camera, editing software, or acquisition source — need to be converted into a specific format and bitrate ladder for streaming.

What good transcoding produces:

An adaptive bitrate (ABR) ladder: multiple renditions of the same content at different resolutions and bitrates. A standard FAST ladder:

• 1080p @ 4–6 Mbps
• 720p @ 2.5–3.5 Mbps
• 540p @ 1.5–2 Mbps
• 360p @ 0.8–1 Mbps

The streaming player on the viewer's device selects the appropriate rendition based on their connection quality and switches between renditions as conditions change. This is why HLS content doesn't buffer when your internet slows down — it just switches to a lower bitrate.

What bad transcoding does to your channel:

Incorrect encoding settings create symptoms that are hard to diagnose. Common problems:

• Wrong keyframe interval → SSAI ad insertion breaks at unexpected places
• Incorrect audio normalization → ads are louder than content (or vice versa)
• Variable frame rate → player stuttering at rendition switch points
• Missing closed caption track → fails FCC accessibility requirements and some platform eligibility checks
• Non-standard container format → some platforms simply won't ingest the content

Transcoding is infrastructure work that most operators correctly want someone else to handle. But understanding what the output should look like means you can verify it and catch problems before they show up in platform reviews.

---

Content storage

Transcoded content needs to be stored somewhere that your playout engine can access it reliably and CDN can deliver it to viewers.

Object storage (S3, Cloudflare R2, etc.) is the standard for FAST content storage. Transcoded HLS segments and manifests are files — they live in object storage and get served through a CDN.

Storage cost considerations:

At typical FAST bitrates, 1 hour of content at an ABR ladder costs roughly 2–4 GB of storage. A 1,000-hour catalog costs 2–4 TB. Object storage at major providers costs approximately $0.02–0.04/GB/month, so a 1,000-hour catalog costs $40–$160/month in storage alone.

At Cloudflare R2 (which Vidiyo uses), egress is free for content served through Cloudflare's network, which eliminates the egress cost that makes AWS S3 expensive at scale. For a large catalog with high viewership, the difference in monthly bills between R2 and S3 can be thousands of dollars.

CDN delivery:

Your transcoded segments need to be delivered through a CDN so that viewers globally get fast, low-latency segment delivery. Without CDN, every viewer is pulling segments directly from your origin storage. For more than a handful of concurrent viewers, this becomes an origin capacity problem.

CDN selection affects viewer experience in ways that matter to ad revenue: segment delivery latency affects player rebuffering, which affects completion rates, which affects CPMs.

---

The playout engine

The playout engine is the piece that turns a schedule — "episode A at 9am, episode B at 9:30am, commercial break at 9:15am and 9:28am" — into a live HLS stream.

What the playout engine actually does:

1. Reads the current schedule
2. Identifies what should be playing right now
3. Generates an HLS manifest pointing to the correct segments
4. Inserts SCTE-35 markers at scheduled ad break points
5. Handles transitions between pieces of content
6. Regenerates the manifest every few seconds as the live position advances

This sounds simple but the implementation details matter significantly:

Manifest accuracy. An HLS manifest that gets stale — doesn't update frequently enough, or has incorrect segment URLs — causes player errors. Some playout implementations regenerate manifests on-demand (per-request); others regenerate on a timer. On-demand is generally more accurate but requires more playout engine capacity.

SCTE-35 marker accuracy. SCTE-35 markers tell the SSAI system "there's an ad break here." If the markers are wrong — wrong duration, wrong cue point timing, missing — the ad system either inserts ads at wrong places or misses breaks entirely. This directly affects revenue.

Seamless transitions. When one piece of content ends and another begins, the playout engine needs to produce a seamless HLS stream. This requires understanding the audio/video format of each piece (sample rate, codec, frame rate) and handling mismatches gracefully. Format mismatches at transitions are a common source of player errors.

Loop handling. When your schedule repeats content, the playout engine needs to handle the transition from the end of the last scheduled item back to the beginning of the next occurrence correctly. Many playout engines have subtle bugs in loop handling that only surface after the channel has been running for a few days.

---

SSAI: how ads actually get into your stream

SSAI (Server-Side Ad Insertion) is the technology that allows ads to be inserted into your live stream without visible buffering, ad blockers circumventing them, or the jarring experience of client-side ad insertion.

How SSAI works:

1. At an ad break, your playout engine emits a SCTE-35 marker in the HLS stream
2. The SSAI system intercepts this marker
3. The SSAI system calls a VAST endpoint (your SSP's ad server) to request an ad
4. The VAST response includes a URL to an ad creative
5. The SSAI system transcodes/packages the ad creative into the same format as your content
6. The SSAI system stitches the ad segments into the HLS manifest in place of content segments
7. The viewer's player sees a continuous HLS stream — it has no way to distinguish ad segments from content segments
8. As the viewer watches the ad, the SSAI system fires tracking beacons (impression, first quartile, midpoint, third quartile, complete) back to the ad server

Why SSAI matters for revenue:

Client-side ad insertion (CSAI) is the older approach where the player pauses, makes an ad request, loads the ad, plays it, then resumes content. CSAI has two major problems:

• Ad blockers can easily intercept the separate ad request. On desktop this removes 30–50% of inventory.
• The buffering during the ad-to-content switch is a bad viewer experience. Completion rates are lower.

SSAI eliminates both problems. The ad is part of the stream — it can't be blocked without blocking the entire video. The switch from content to ad and back is seamless.

For FAST channels, SSAI is essentially mandatory. All major FAST platforms require it. Any playout platform that's offering FAST channel hosting without SSAI is not production-ready.

VAST compliance:

The standard protocol for ad serving in SSAI is VAST (Video Ad Serving Template). VAST is a specification for how an ad server communicates an ad creative and its tracking requirements to the SSAI system. Current standard is VAST 4.2, though many systems still use VAST 3.0.

VAST implementation details matter for revenue. Common VAST problems:

• Ad creative bitrate incompatible with your HLS ladder → SSAI can't transcode fast enough, ad break is missed
• VAST wrapper chains too deep → timeout before ad fills → empty break
• Tracking beacon failures → impressions not counted → lower reported fill rates → reduced bid prices on future impressions

---

EPG: the metadata layer that drives discovery and CPMs

The Electronic Program Guide is how viewers (and platforms) know what's on your channel. But EPG data does more than show a schedule.

EPG affects platform placement. Platforms like Samsung TV Plus and Roku Channel use EPG metadata for channel discovery and content categorization. A channel with rich, accurate EPG data (program titles, descriptions, genres, content ratings) gets placed more accurately in platform discovery UIs and gets surfaced in relevant search results. A channel with sparse or inaccurate EPG (just repeating the channel name as every program, or missing descriptions) gets default generic placement.

EPG affects programmatic CPMs. SSAI systems use EPG metadata to provide context signals to the demand side. When a DSP is bidding on your inventory, contextual signals from the EPG (this is a cooking show in a health-and-wellness segment) are used to determine bid price. Better EPG data means more precise contextual targeting, which means higher CPMs from brand-safety-conscious advertisers.

EPG format standards:

The two dominant formats are:

• XMLTV — XML-based format, widely used for older platforms
• JSON EPG — various JSON schemas, used by newer platforms

Most platforms accept either. The content of the EPG matters more than the format. A 14-day rolling EPG feed with full program descriptions, genres, and content ratings is the standard.

EPG update frequency:

EPG data needs to be updated before the schedule it describes. If you update your schedule and don't update the EPG immediately, platforms may not show the correct programming — or may show your channel as having no programming, which hides it in some discovery UIs.

Automated EPG generation from your scheduling system is strongly preferable to manual EPG creation. Any system where EPG is a separate manual step is a system where EPG gets out of sync with reality.

---

The self-build vs. platform decision

Understanding the stack makes it easier to evaluate the build-vs-buy decision:

Building your own playout:

• Full control over playout logic, SSAI configuration, manifest generation
• Requires engineering resources with HLS and SSAI expertise
• Realistic timeline: 3–6 months to a production-quality implementation
• Ongoing maintenance: significant
• Cost at scale: significant (server infrastructure, CDN, engineering)

Using Vidiyo or similar:

• Playout, SSAI, EPG, transcoding, CDN all managed
• No engineering resources required for infrastructure
• Realistic timeline: 1–2 weeks from upload to live channel
• Ongoing maintenance: handled by platform
• Cost at scale: depends on platform pricing

For most independent operators, the decision is clear: don't build your own playout stack unless your channel volume or specific technical requirements justify the engineering investment. A single-channel independent operator building their own playout stack is spending 3–6 months of engineering time on infrastructure that a platform can provide, while their actual business — content and audience development — waits.

The edge cases where self-building makes sense: multiple channels at significant scale, unique SSAI requirements that commercial platforms can't accommodate, or specific technical requirements around content protection (DRM).

---

The things that go wrong

In rough order of how often they happen:

SCTE-35 marker misalignment. Your schedule says the break is at 14:32 into episode X. The actual SCTE-35 marker fires at 14:45 because the playout engine is miscounting frame duration. Result: SSAI inserts the ad mid-sentence or cuts off content. Fix: verify SCTE-35 marker timing against your scheduling metadata before going live.

Segment duration inconsistency. Your content has some segments that are 2 seconds and some that are 6 seconds because the transcoder used variable segment duration. Most players handle this fine; some platforms' ingest systems reject it or produce manifest errors. Fix: enforce consistent target segment duration in your transcoder settings.

EPG desync. Your schedule has been updated but the EPG feed hasn't been regenerated. Viewers see the wrong program title; platform search indexes reflect stale data. Fix: EPG regeneration should be triggered automatically when schedule changes.

VAST timeout cascades. During high-traffic periods, your VAST endpoint takes longer to respond than the SSAI system's timeout allows. Result: empty ad breaks, lost revenue. Fix: monitor VAST response times; configure SSAI timeout settings to match your demand partner's actual latency characteristics.

Closed caption sync drift. Closed captions get out of sync with audio during long playback sessions. Common in playout systems that treat captions as a separate stream rather than muxed into the content. Fix: verify caption sync across the full content duration, not just at the start.

---

The technical stack for a FAST channel is genuinely learnable in a week of study. You don't need to understand every implementation detail — but knowing what each piece does means you can evaluate platforms critically, debug problems when they happen, and have informed conversations with technical partners.

Next episode we'll close this first arc with the first 90 days — what to actually do, in order, when you're launching a FAST channel from scratch.

If you're debugging a FAST stack issue or evaluating playout platforms, reach out at signal@vidiyo.com.

—The Vidiyo team