挑战
该平台之前 exclusively 使用 SSAI（服务器端广告插入），SSAI 在变现方面表现良好，但在互动广告体验方面存在显著限制：
- SSAI 拼接的广告不支持可点击的叠加层、伴随横幅或互动广告单元
- 无法跟踪高端广告买家要求的客户端广告事件（四分位进度、可见性、点击率）
- 联网电视平台 (Roku, Fire TV, Apple TV) 要求使用 CSAI 来满足其原生广告框架和认证要求
- HLS/DASH manifests 中的 SCTE-35 标记需要在客户端解析，但每个 player SDK 处理 cue 事件的方式不同
- 广告 pod 管理（用多个广告填充多槽广告位）需要客户端编排
- 需要广告拦截器检测和回退逻辑以保护网络平台上的收入
- 在不中断内容缓冲的情况下预加载广告需要精心的播放器生命周期管理
我们的解决方案
我们构建了一个跨平台 CSAI 框架，它具有统一的广告编排层，可以从 HLS/DASH manifest 中解析 SCTE-35 标记，与 VAST/VMAP 广告服务器通信，并管理网络 (Video.js/Shaka)、iOS (AVPlayer)、Android (ExoPlayer) 和联网电视播放器上的广告播放生命周期。
架构
- 内容分发：通过 AWS MediaPackage + CloudFront 传输带有 SCTE-35 标记的 HLS/DASH 流
- 广告决策服务器：支持 VAST 4.2 和 VMAP 的 Google Ad Manager (GAM) / SpotX
- 网络播放器：Video.js 集成自定义 SCTE-35 cue 解析器和 Google IMA SDK
- iOS 播放器：带有
AVDateRangeMetadataGroup监听器和 IMA iOS SDK 的 AVPlayer - Android 播放器：带有
MetadataOutput监听器和 IMA Android SDK 的 ExoPlayer - 联网电视：带有广告框架适配器的平台原生播放器 (Roku RAF, Fire TV IMA, Apple TV AVKit)
- 广告分析：用于曝光、四分位、完成、点击和可见性跟踪的自定义事件管道
- 回退：当广告填充不可用或检测到广告拦截器时，投放静止画面/自营广告
SCTE-35 客户端解析
HLS Manifest 标记
SCTE-35 信号以两种格式出现在 HLS manifests 中，均由客户端解析：
EXT-X-DATERANGE (HLS v7+)- 播放器监听带有
SCTE35-OUT和SCTE35-IN属性的#EXT-X-DATERANGE标签 - 属性包括用于广告插播长度的
PLANNED-DURATION和用于事件关联的ID - 现代播放器 (AVPlayer, ExoPlayer, Shaka) 的首选格式
#EXT-X-CUE-OUT:DURATION=标记广告插播开始#EXT-X-CUE-IN标记返回内容- 支持与旧版播放器和编码器向后兼容
DASH Manifest 标记
- SCTE-35 信号作为 DASH MPD 中的
schemeIdUri="urn:scte:scte35:2013:xml" presentationTime、duration和 base64 编码的 SCTE-35 二进制负载- Shaka Player 和 ExoPlayer 通过其事件监听器 API 本地解析这些内容
标记处理流程
- 检测 — 播放器元数据监听器在 manifest 解析期间检测到 SCTE-35 cue 事件
- 提取 — 从标记中提取插播时长、事件 ID 和分段类型
- 广告请求 — 向广告决策服务器发送 VAST/VMAP 请求，包含 targeting 参数（内容 ID、类型、设备类型、用户细分、地理位置）
- Pod 规划 — 解析广告响应以构建广告 pod（按顺序排列的广告创意列表，填充插播时长）
- 预加载 — 在内容播放期间预加载广告创意，以消除广告插播开始时的延迟
- 暂停与切换 — 在 cue point 暂停内容播放，播放器切换到广告播放
- 广告播放 — 广告按顺序播放，带有四分位跟踪、伴随横幅显示和点击处理
- 恢复 — 在 pod 完成后，内容播放从 cue point 之后的精确帧恢复
特定平台实现
Web (Video.js + IMA SDK)
- 自定义 Video.js 插件通过
textTrackcue change 事件拦截#EXT-X-DATERANGE元数据 - Google IMA HTML5 SDK 管理 VAST 广告请求、广告播放和伴随广告渲染
- 广告容器叠加层位于视频元素上方，支持点击和跳过按钮
- 通过 canary 请求进行广告拦截器检测 — 检测到时回退到自营广告或内容恢复
- 通过 VMAP 或手动 cue-point 调度支持 preroll、midroll 和 postroll
iOS (AVPlayer + IMA SDK)
AVPlayerItem.navigationMarkerGroups和AVDateRangeMetadataGroup用于检测 SCTE-35 cuesAVPlayerItemMetadataOutput代理在每个 cue 事件上触发，带有解析后的时序和 payload- Google IMA iOS SDK 在单独的
AVPlayer实例中处理 VAST 请求和广告播放 - 根据平台广告政策，Picture-in-Picture (PiP) 在广告插播期间暂停
- 处理背景音频 — 广告在背景模式下不播放
Android (ExoPlayer + IMA SDK)
Player.Listener.onMetadata()和MetadataOutput从 HLS/DASH 捕获 SCTE-35 事件- Google IMA Android SDK 通过 ExoPlayer 的
ImaAdsLoader扩展集成 - 广告播放使用单独的
MediaSource以避免污染内容缓冲区 - 处理 Activity 生命周期 — 广告状态在配置更改和后台运行时保留
- Android TV 和移动设备共享相同的广告逻辑，并进行 UI 层适配
联网电视平台
Roku (RAF — Roku 广告框架)- Roku 的原生 RAF 库直接从 HLS manifest 中解析 SCTE-35 标记
RAF.setAdUrl()配置 VAST endpoint；RAF 处理广告请求、pod 构建和播放- 通过 RAF 的
renderStitchedAd和renderTrackingEvent回调支持伴随广告 - Roku 认证要求使用 RAF — 自定义广告播放器在审核期间会被拒绝
- 使用适用于 Fire TV 的 Leanback UI 的 Android ExoPlayer + IMA SDK 实现
- 广告叠加层上的跳过按钮和“了解更多”点击通过的 D-pad 导航
- Fire TV Ad ID 用于 VAST 请求中的广告定位
- 带有
interstitialTimeRanges的AVPlayerViewController用于原生广告插播 UI 指示器 - 通过
AVPlayerItemMetadataCollector解析 SCTE-35 cues - 广告播放在一个单独的
AVQueuePlayer中管理，以实现内容/广告的清晰分离 - tvOS 遥控器点击处理程序用于互动广告元素
广告 Pod 管理
- Pod 填充 — 组装多个 VAST 广告以填充信号指示的插播时长
- 瀑布流 — 如果主要广告服务器返回 no-fill，则按顺序查询次要/三级需求来源
- 时长匹配 — Pod 构建器选择符合插播时长（±0.5s 容差）的广告组合
- 去重 — 同一个广告创意不会在同一个 pod 中显示两次
- 频次限制 — 在客户端强制执行每个用户、每个会话的频次限制，以避免广告疲劳
- 缓冲广告 — 短的缓冲创意（“我们马上回来”/“欢迎回来”）包裹广告 pods
广告事件跟踪与分析
- 标准 VAST 事件 —
impression（曝光）、start（开始）、firstQuartile（第一四分位）、midpoint（中点）、thirdQuartile（第三四分位）、complete（完成）、skip（跳过）、clickThrough（点击） - 可见性 — 根据广告视口可见性和持续时间阈值触发 MOAT/IAS 可见性像素
- 自定义事件 — 应用级事件（广告插播开始/结束、pod 填充率、预加载时序、回退触发）
- 服务器管道 — 客户端将事件发送到轻量级事件收集器，该收集器再分发到 GAM、MOAT 和内部分析仓库
- 对账 — 服务器端日志与客户端事件对账，用于差异检测
广告拦截器处理（Web）
- 检测 — 向已知广告域发送 canary VAST 请求；超时或被阻止表示广告拦截器
- 回退策略 — 从第一方 CDN 域提供自营广告或宣传片
- 内容门控 — 可选的软门控：在内容播放前提示用户将网站列入白名单
- 分析 — 跟踪每个浏览器、地理位置和页面的广告拦截器检测率
主要特点
- 跨平台 CSAI — 跨网络、iOS、Android、Roku, Fire TV 和 Apple TV 的统一广告插入
- SCTE-35 客户端解析 — HLS
EXT-X-DATERANGE,CUE-OUT/IN和 DASHEventStream解析 - 互动广告 — 所有平台上的可点击叠加层、伴随横幅和跳过按钮
- 广告 Pod 编排 — 带有瀑布流、时长匹配和去重的多广告插播填充
- 预加载 — 在内容播放期间预加载广告创意，实现零延迟广告过渡
- 可见性跟踪 — 为满足高端广告买家可见性要求而集成 MOAT/IAS
- 联网电视合规性 — 满足认证要求的 Roku RAF, Fire TV IMA 和 Apple TV AVKit 集成
- 广告拦截器弹性 — 在网络上检测并回退到第一方自营广告
成果
技术栈
caseStudyDetail.more 案例研究
探索更多我们的技术实施案例
SCTE-35 广告标记信令与媒体预告片插入管道
一家流媒体公司需要一个强大、自动化的管道，用于将 SCTE-35 广告标记注入直播和 VOD 流中，并能将宣传预告片（前贴片、中贴片和后贴片）精确地插入指定位置——从而实现跨 FAST 频道、直播活动和点播内容库的变现。
利用 AWS 媒体服务通过 SRT 传输 FAST 频道流媒体
一家媒体公司需要使用 Secure Reliable Transport (SRT) 协议，为其 FAST 频道建立可靠、低延迟的贡献源，从而能够通过不稳定的互联网连接，从远程工作室、云播放系统和联合发行合作伙伴摄取高质量内容。
常见问题
MicrocosmWorks implemented a manifest parser that extracts EXT-X-DATERANGE tags containing base64-encoded SCTE-35 splice_info_section data, decodes the splice commands, and triggers the ad decision request to the VAST/VMAP ad server with the appropriate break duration. The parser handles both time_signal and splice_insert command types across live and VOD manifests.
MicrocosmWorks built a shared ad playback SDK with platform-specific adapters for AVPlayer on iOS, ExoPlayer on Android, hls.js on web, and native players on Roku and Fire TV. The SDK normalizes ad lifecycle events like impression, quartile tracking, and completion across all platforms, ensuring unified reporting regardless of the playback device.
MicrocosmWorks implemented a timeout and fallback strategy where the player waits a maximum of 3 seconds for an ad server response before playing a default slate or skipping to the next content segment. The SDK also pre-fetches upcoming ad break VAST responses during content playback to minimize latency at the actual break point.
MicrocosmWorks integrated Open Measurement SDK (OM SDK) for viewability verification compatible with MOAT, IAS, and DoubleVerify, and the tracking implementation follows IAB VAST 4.2 specifications for impression counting and quartile events. The system also supports IAB's Video Ad Serving Template measurement guidelines for accurate ad completion rate reporting.
MicrocosmWorks delivers ad technology implementations at rates of $30-$50/hr, with a full CSAI system including SCTE-35 parsing, VAST/VMAP integration, and multi-platform player SDKs for iOS, Android, web, and CTV typically requiring 600-900 development hours. Each additional platform adapter adds approximately 80-120 hours to the base implementation.