在柬埔寨做 OTT：拿 IPTV 面板当后端，前端自己写 APK

后端为什么不自研#

成熟的 IPTV 管理面板，把 OTT 后端该有的东西基本都有了：

这些没有一样是有创新空间的，全是”行业里早就定型”的功能。自研的唯一结果是用两年时间做一个更差的版本。

真正需要投入的是运维：直播源不稳定要能自动切备源、转码机 CPU 打满要能扩容、边缘节点挂了要能摘掉。这些是配置和监控的活，不是写代码的活。

前端为什么必须自研#

面板自带的播放页可以用，但不能拿来当产品。原因有三个：

1. 品牌是电视台的核心资产。 CDTV 是有牌照的持牌电视机构，APP 上打谁的 logo、用什么配色、频道怎么排序，这些不能交给一个通用面板决定。

2. 本地化不是翻译。 柬埔寨用户的使用习惯、高棉语字体渲染、当地支付方式，通用模板全都覆盖不到。高棉文的字形和换行规则跟拉丁文差别很大，字体没选对整个界面就是乱的。

3. 电视端和手机端是两种交互。 手机是触摸，机顶盒和电视是遥控器——焦点怎么移动、返回键怎么处理、大屏上字号多大能看清，这些必须自己控制。

所以前端是自己做的 Android APK，通过面板的接口拿频道列表、鉴权和播放地址，播放器和整个交互层自己实现。

踩过的地方#

转码档位不能贪多。 每多一档就多一份 CPU 和存储。柬埔寨的移动网络质量参差，一开始想多切几档覆盖全，结果转码机先扛不住。后来收敛到三档，按实际用户网络分布定，够用。

直播源比想象中脆弱。 卫星接收、编码器、上联链路，任何一环抖动都会表现成”用户说卡”。所以必须有源侧监控——不能等用户投诉才知道某个频道已经黑屏半小时了。

并发数限制要真的执行。 一个账号被全家甚至全楼共用，是这类业务的常态。面板支持并发限制，但要结合实际调——卡太死用户骂，放太松收入漏。

APK 分发是个独立问题。 不是所有用户都能上 Google Play。要准备好官网直接下载 APK、以及版本升级提示的通道。

同期的另外一条线#

OTT 之外还维护着一带一路的 DTMB 平台（地面数字电视），以及和柬埔寨新闻部合建的机房——UPS、发射机、服务器、卫星接收器、转码器、冷循环系统。

OTT 和 DTMB 是同一批内容的两种送达方式：一个走互联网，一个走地面广播。同时管这两条线，好处是对”内容从演播室到用户屏幕”的完整链路有了体感——哪一段是带宽问题、哪一段是编码问题、哪一段是设备问题，判断起来快很多。

这段经历给我留下的#

在成熟领域，“用现成的”往往是更专业的判断，而不是偷懒。 关键是分清哪部分是通用能力（后端面板），哪部分是你的差异化（品牌、本地化、终端体验）——前者用现成的成熟方案，后者必须自己攥在手里。

这个判断方法后来一直在用：在 Jeepay 上接支付通道是同一个思路，在 Xboard 上做二次开发也是。不动核心、只加自己要的能力，上游升级还能跟。