指南

这里介绍 Kiln 的完整数据流：如何接收上游、在何处封装媒体、怎样生成播放地址，以及每组接口接受哪类凭据。如果还没有运行服务，请先阅读快速开始。

数据流

一条频道从上游到播放器要经过四步，每一步都可以单独配置：

上游（HLS / DASH）
      │
      ▼
  拉流  pull       按需启动，无人观看时回收上游连接
      │
      ▼
  打包  packager   HLS 同源分片代理；DASH 本地解密后重封装为 HLS
      │
      ▼
  分发             播放地址、M3U 播放列表、EPG、管理控制台

拉流与打包的生命周期由会话管理器统一持有：同一个频道无论有多少观众，只维持一份上游连接和一份打包产出。

四种凭据

每种凭据只覆盖自己的那一段，互相之间不能提权。

• 公开端点：不需要凭据，覆盖 /healthz、/readyz、/metrics、/v1/epg.xml、/v1/logo/{id} 以及做了限流的 POST /v1/auth/login。
• 登录会话 JWT：口令登录换取的 Ed25519 签名令牌，服务管理控制台以及只认会话的 /v1/playlist.m3u。
• 管理员 API 令牌：供脚本和命令行使用的长期凭据。明文只显示一次，可分别授予 read、write、delete、refresh 权限，并且只能访问已登记的管理路由。
• 路径式播放密钥：写在 URL 路径里的 /p/{token}/...，可限定频道范围、随时撤销，专门用来把播放列表交给播放器。

完整的路由与权限矩阵见 接口参考，凭据的签发与轮换见 鉴权与凭据。

引擎与变体

打包引擎有 native、ffmpeg 与 auto 三种：native 全程由 Go 原生实现，不需要外部依赖；ffmpeg 调用外部二进制；auto 优先原生并在源不受支持时回退。频道级的 packager 字段可以单独覆盖全局取值。

运行时另有 lite、core 与 full 三个发行变体，能力边界不同但共用同一套配置模型：显式写在配置里的引擎取值始终优先，同一份配置不会因为换了变体而改变行为。

继续阅读