Hightube-report/speech.typ

#set page(
  paper: "a4",
  margin: (x: 2cm, y: 2.5cm),
  header: align(right, text(8pt, fill: luma(120), font: "Noto Sans CJK SC")[开源跨平台个人直播系统项目最终汇报配套演讲稿 | Hightube]),
  footer: context {
    let page_number = counter(page).get().first()
    let total_pages = counter(page).final().first()
    align(center, text(9pt, fill: luma(120))[#page_number / #total_pages])
  }
)

#set text(
  font: ("Noto Serif CJK SC", "Times New Roman"),
  size: 10pt,
  lang: "zh"
)

#set par(
  justify: true,
  leading: 0.75em,
  first-line-indent: 2em
)

#align(center)[
  #v(0.2cm)
  #text(size: 20pt, weight: "bold", fill: rgb("#0f4c81"))[《Hightube 开源跨平台个人直播系统》验收汇报配套讲稿] \
  #v(0.1cm)
  #text(size: 11pt, style: "italic", fill: rgb("#526173"))[10 分钟精简版 | 约 2400 字逐字稿 + 答辩 FAQ]
  #v(0.4cm)
]

#block(
  fill: rgb("#f4f9ff"),
  inset: 10pt,
  radius: 6pt,
  stroke: 0.5pt + rgb("#0f4c81"),
)[
  #text(weight: "bold", fill: rgb("#0f4c81"))[10 分钟汇报时间分配] \
  #set text(size: 9pt)
  - *页面时间*：封面 ~20s / 目录 ~15s / 背景 ~45s / 架构 ~45s / 性能调优 ~55s / 总体架构 ~20s / 性能测试 ~50s / 部署拓扑 ~25s / 穿透反代 ~45s / Web展示 ~40s / 后台与App ~40s / 团队协作 ~40s / 挑战方案 ~65s / 总结展望 ~45s / 演示流程 ~45s / 致谢与Q&A ~20s。总计 610 秒 ≈ 10 分钟。
  - *精讲原则*：突出系统的端到端闭环和自研后端性能优化的“三驾马车”（SQLite调优、缓存、I/O缓冲），强调内网穿透部署的安全合规性以及多端拉流自适应追帧带来的优秀体验。
  - *语速*：中文约 240-250 字/分钟，本稿正文约 2460 字。
]

#v(0.3cm)

#show heading: it => block(below: 0.4em)[
  #set text(fill: rgb("#0f4c81"), weight: "bold")
  #it.body
]

= 逐页逐字稿（10 分钟精简版）

#block(width: 100%, breakable: true)[
  == 第 1 页：封面页（~20 秒）
  *【逐字演讲稿】* 各位老师、同学们，下午好！我是舒钰权。今天我代表我们小组——程景愉、舒钰权、李俊友、张钊源，汇报 Hightube 开源跨平台个人直播系统项目成果。针对传统直播平台对第三方生态依赖度高、敏感私密流经公有云存在合规和泄露风险，以及传统音视频组件部署门槛高这三大痛点，我们打造了 Hightube 平台。我们成功完成了“高并发推流、后端转码分发、多端拉流和公网穿透”的流媒体生态全链路闭环，发布了 v1.0.1-Release 版本并完成了公网部署验证。 \
  *【演讲技巧】* 语速平稳，声音洪亮，一句话讲明痛点，带出项目的最终闭环地位。
]

#block(width: 100%, breakable: true)[
  == 第 2 页：目录页（~15 秒）
  *【逐字演讲稿】* 本次汇报将分为以下七个方面进行展开：首先是项目背景与最终目标；第二部分介绍系统的整体架构和技术选型；第三部分重点剖析后端性能调优的核心技术；第四部分阐述我们的网络设计与公网隧道穿透部署方案；第五部分进行多端系统界面的实际效果展示；第六部分介绍团队的协作分工与工程规范；最后总结遇到的挑战并对项目的未来规划进行展望。 \
  *【演讲技巧】* 快速带过，不需要深入解释目录项，用时不超过 15 秒。
]

#block(width: 100%, breakable: true)[
  == 第 3 页：项目背景与目标（~45 秒）
  *【逐字演讲稿】* 首先来看项目背景。传统的直播平台规则限制多，商业抽成高，自主管理度极低。在内训、会议等私密场景下，敏感的音视频流如果流经公有云，存在合规和泄漏隐患。而在技术层面，RTMP 接收、编码转码、Web 播放适配链条冗长，使得自建平台的部署门槛非常高。
  为此，我们提出了 Hightube 的解决方案：Go 编译为单一的静态可执行文件，实现零外部依赖一键部署；打通推流、鉴权、转码、播放、弹幕的全链路闭环；支持反向隧道穿透，保障内网部署的安全性，并遵守开源 MIT 协议。我们的最终目标是：打造一个开箱即用、极速轻量、安全可控的跨平台私有化直播基座。 \
  *【演讲技巧】* 在“私有化与安全可控”上加重语气，突出私有部署的合规性。
]

#block(width: 100%, breakable: true)[
  == 第 4 页：系统架构总览（~45 秒）
  *【逐字演讲稿】* 接下来介绍系统架构总览。系统数据流从 OBS 推流开始，向嵌入式 RTMP 服务器（监听 1935 端口）发起请求。业务后端提取路径中的 `stream_key` 并在 SQLite 中实时鉴权。随后，系统会调用 FFmpeg 异步转码子进程管线产生多档流（原始/720p/480p），并在分发层利用 HTTP-FLV 低延迟长连接分发至客户端；定时截图程序每 12 秒捕获一次直播画面作为封面。
  业务层基于 Go 语言的 Gin 框架提供服务，使用 GORM + SQLite 承载轻量级持久化，JWT 访问令牌进行安全防护，Gorilla WebSocket 驱动高并发弹幕服务，并利用 SSE 异步流在管理后台滚动显示系统日志。整个应用充分解耦，并支持 Docker 容器化一键部署。 \
  *【演讲技巧】* 配合架构图的流向进行讲解，使听众脑海中建立清晰的链路模型。
]

#block(width: 100%, breakable: true)[
  == 第 5 页：后端性能优化：三驾马车（~55 秒）
  *【逐字演讲稿】* 在高并发场景下，如何保证 SQLite 数据库并发读写不锁死、Socket 写入开销低，是我们的优化重点。我们设计了性能调优的“三驾马车”。
  第一是 SQLite 调优。我们开启了 WAL 日志模式，实现读写互不互斥；将 synchronous 设为 NORMAL 以减少磁盘同步，将临时表存储到内存，并设置了 5 秒的 Busy Timeout 退避重试，彻底消除了写锁冲突报错。
  第二是内存线程安全缓存。我们在内存中封装了本地 Map 缓存，通过读写锁控制并发，在开播或状态变更时同步更新 Cache。当大厅并发轮询时直接读取内存，实现零 SQL 负载。
  第三是 I/O 缓冲与分组 Flush。我们为流媒体分发响应封装了 4KB 的 bufio 缓冲区，合并小碎包在一次系统调用发出，大大降低了上下文切换，并设计了在每帧写完后强制执行 `Flush()`，在降低 Socket 写入开销的同时，保持了超低延迟。 \
  *【演讲技巧】* 强调这三项优化的相辅相成，使并发写吞吐量取得了指数级的提速。
]

#block(width: 100%, breakable: true)[
  == 第 6 页：项目总体架构（~20 秒）
  *【逐字演讲稿】* 这是本项目的总体物理架构拓扑图。系统分为了前端和后端两个核心层级，左侧是推流端，中间是内网主机中运行的 Go 主程序与流媒体转码子进程，右侧则是用户侧的拉流客户端。我们可以直观地看到，除了传统的 HTTP API 和流分发之外，弹幕服务器与播放器是完全分离并独立并发运行的。通过公网穿透服务，使得整个流分发链路变得十分稳定和高效。 \
  *【演讲技巧】* 指向架构图，从左向右梳理一遍物理设备层级。
]

#block(width: 100%, breakable: true)[
  == 第 7 页：性能测试结果（~50 秒）
  *【逐字演讲稿】* 下面汇报后端的定量压测与物理延迟测试数据。
  首先在 SQLite 并发写吞吐量上，普通模式在 10 并发下由于频繁锁表超时，吞吐量跌至 9 TPS；而在开启 WAL 及参数调优后，10 并发吞吐量提升至 380 TPS，提升幅度高达 4122%。
  在流媒体播放延迟方面，同网直连 RTMP 仅 800 毫秒，公网 FRP 穿透后为 1250 毫秒；在网页端使用 HTTP-FLV 播放时，未开启追帧时为 2.6 秒，而开启追帧算法后延迟降低至 1.65 秒；在网络抖动积压达 6.2 秒时，追帧算法可在 15 秒内快速平滑收敛至 1.7 秒，在平滑过渡的同时实现了延迟的快速平抑。 \
  *【演讲技巧】* 强调“4122% 的写入性能提升”和“抖动积压下 15 秒内平滑收敛”两个关键指标。
]

#block(width: 100%, breakable: true)[
  == 第 8 页：公网部署方案：网络拓扑结构（~25 秒）
  *【逐字演讲稿】* 这是我们的公网部署网络拓扑。我们着重解决了“在零公网 IP 的内网环境下发布服务”的难题。我们租用了一台公网云服务器，在本地内网主机和公网服务器之间建立起 FRP 反向隧道。公网服务器负责反向隧道的接收与证书路由，而实际运行和媒体处理全部在内网机本地处理。观众所有的访问请求都会通过隧道无缝流向内网的 Hightube 进程。 \
  *【演讲技巧】* 说明这种拓扑在保障内网服务器隐蔽性的同时，极大地降低了公网服务器的带宽成本。
]

#block(width: 100%, breakable: true)[
  == 第 9 页：公网部署方案：隧道穿透与反向代理（~45 秒）
  *【逐字演讲稿】* 具体的隧道穿透与反代映射如下：我们在公网云服务器部署 frps 监听 7000 端口，内网主机部署 frpc 建立长连接。映射端口包括：本地 Caddy 网页 80 端口映射为公网 8080，本地 Go 后端 8081 映射为公网 8081，本地 RTMP 1935 映射为公网 1935。
  在公网端，Caddy 反向代理自动向 Let's Encrypt 申请 SSL 证书并开启 HTTPS 访问。我们配置了智能的路径分发策略：`/api/*` 和 `/live/*` 请求自动代理回内网的 8081 端口，其余访问在本地端进行静态分发，直接服务 Flutter 的编译网页，既高效又安全。 \
  *【演讲技巧】* 解释 HTTPS 证书自动化申请和 Caddy 路由对直播安全的保障作用。
]

#block(width: 100%, breakable: true)[
  == 第 10 页：界面展示：Web 端平台与播放效果（~40 秒）
  *【逐字演讲稿】* 这里展示的是我们的网页端界面。左边是项目主页，采用现代化卡片布局和响应式设计。主页上直观地展示了当前活跃的直播间列表，并集成了 12 秒的封面轮询机制，缩略图实时更新。
  右边是我们的网页端直播与弹幕互动页面。我们引入了 `flv.js` 进行低延迟的自适应拉流和追帧解码，右侧则是基于 WebSocket 建立的弹幕交互系统，弹幕消息在屏幕的上半区平滑画过，观众发弹幕的端到端网络延迟在 1.6 秒左右，互动效果非常优秀。 \
  *【演讲技巧】* 结合界面卡片图，向评委展示页面的精致视觉效果。
]

#block(width: 100%, breakable: true)[
  == 第 11 页：界面展示：管理后台与手机端（~40 秒）
  *【逐字演讲稿】* 这是我们的后端管理控制台与手机客户端。左边是控制台主面板，可以实时展示主机的各项健康指标、当前并发在线人数，并利用 SSE 异步流将系统日志无刷新推送到网页端显示。
  右边是我们的 Android 手机客户端，采用 Flutter 框架构建，不仅保证了高品质、多终端一致的自绘渲染 UI，而且通过调用底层的硬件解码器进行拉流，在节约手机 CPU 和电量的同时，保证了高帧率与低延迟。 \
  *【演讲技巧】* 强调 Flutter 自绘 UI 的跨平台一致性和 SSE 日志推送的高实时性。
]

#block(width: 100%, breakable: true)[
  == 第 12 页：开发规范与团队协作（~40 秒）
  *【逐字演讲稿】* 在协作规范上，我们坚持“契约先行”制定 RESTful API 接口规约，降低联调摩擦；采用 Git 分支开发工作流，合并必须经过 MR 与 Code Review；后端执行 `gofmt` 格式化，前端配置严格的分析检查。
  在成员分工上，程景愉总体负责系统架构设计、基础开发、Docker 容器化与穿透代理部署；我负责用户模块、WebSocket 弹幕引擎研发以及前端弹幕渲染裁剪；张钊源负责管理面板、Metrics 运行监控和日志审计；李俊友负责核心流媒体 API 实现与多端播放适配。 \
  *【演讲技巧】* 对团队四人的明确分工和敏捷协作进行肯定。
]

#block(width: 100%, breakable: true)[
  == 第 13 页：遇到的挑战与解决方案（~65 秒）
  *【逐字演讲稿】* 在整个开发生命周期中，我们共克坚了六大核心技术难题。
  一是推流安全：RTMP 默认无校验，我们路径剥离 `stream_key` 并在数据库实时鉴权拦截；
  二是僵尸转码进程：直播中断后转码进程残留，我们通过树状 `context.Context` 传导机制与 `defer cancel()`，在推流断开时自动强制回收 FFmpeg 进程；
  三是 Web 端直连失败：浏览器不支持 RTMP，引入了 HTTP-FLV 流并配合前端 `flv.js` 解码播放；
  四是积压延迟：开发了基于 `timeupdate` 的倍速（1.15倍）及强跳帧追帧算法；
  五是 SQLite 锁表：开启 WAL 日志模式并调优 Pragmas 解决；
  六是内网服务暴露：通过建立 FRP 隧道和 Caddy 反向代理实现了公网安全路由。 \
  *【演讲技巧】* 这页是开发技术含金量所在，声音要自信沉稳。
]

#block(width: 100%, breakable: true)[
  == 第 14 页：总结与展望（~45 秒）
  *【逐字演讲稿】* 总结我们的项目，Hightube 实现了从推流、鉴权、转码、分发到播放、弹幕的完整私有化流媒体闭环。通过后端优化，并发写性能提升了 40 倍，Web 端播放延迟控制在 1.6 秒内。所有依赖均符合 MIT/BSD/Apache 许可证，确保了商业友好与合规开源。
  未来我们计划在三个方向继续探索：一是低延迟升级，引入 WebRTC/Whip 直播协议以将延迟压缩到 500ms 以内；二是智能转码，引入 GPU 硬件转码代替现有的纯 CPU 转码；三是多节点负载，设计基于动态重定向的分发网络，满足更大并发的需求。 \
  *【演讲技巧】* 突出项目在开源与合规性上的完善，并阐述未来的具体优化路径。
]

#block(width: 100%, breakable: true)[
  == 第 15 页：演示流程预览（~45 秒）
  *【逐字演讲稿】* 这是稍后的现场演示流程，我们将分六步进行：第一，在服务器命令行执行可执行文件，一键部署并瞬间启动服务；第二，多端注册登录自动分配直播间；第三，配置 Stream Key 并在 OBS 中向公网发起直播推送；第四，在网页、手机 App 和 VLC 播放器中同时拉流对比，展示 1.6 秒左右的低延迟与追帧同步效果；第五，观众端实时发送互动弹幕；第六，在后台监控面板查看各项性能监控指标和实时滚动的 SSE 系统日志。整个演示突出“低延迟保障”、“多档清晰度无缝切换”、“出色的公网连通性”和“高度集成”的特点。 \
  *【演讲技巧】* 语速放慢，为接下来的系统 Demo 现场演示进行引导和铺垫。
]

#block(width: 100%, breakable: true)[
  == 第 16 页：致谢与 Q&A（~20 秒）
  *【逐字演讲稿】* 以上就是我们 Hightube 项目的验收汇报。我们已在 GitHub 完全开源，并提供了公网体验平台和项目主页，欢迎大家扫码或输入网址进行体验。非常感谢各位评委老师和同学的聆听！接下来是提问与答辩环节，请各位老师提问和指导，谢谢！ \
  *【演讲技巧】* 诚恳致谢，身体微微前倾，面带微笑。
]

#v(0.3cm)
#block(
  fill: rgb("#fff5f5"),
  inset: 10pt,
  radius: 6pt,
  stroke: 0.5pt + rgb("#b91c1c"),
)[
  #text(weight: "bold", fill: rgb("#b91c1c"), size: 11pt)[防答辩提问防线策略 (Q&A 环节 FAQ)] \
  #set text(size: 8.5pt)
  #v(0.2cm)

  #text(weight: "bold", fill: rgb("#b91c1c"), size: 9.5pt)[一、 评委老师专业提问] \
  #v(0.1cm)

  *问题一：为什么不采用主流的 HLS (HTTP Live Streaming) 协议，而选择 HTTP-FLV 协议？* \
  *应答*：HLS 基于分片文件传输，由于切片大小限制，通常延迟高达 10 到 30 秒，即使是 LL-HLS 也在 3 秒以上，不适合强互动直播。而 HTTP-FLV 是将流媒体数据封装在 FLV 格式中，通过 HTTP Chunked 长连接进行不间断的分块传输，既克服了浏览器不支持 RTMP 的缺陷，又继承了 RTMP 低延迟的优点，端到端延迟可控制在 1.5 到 2 秒内，性价比较高。

  #v(0.1cm)
  *问题二：SQLite 作为一个轻量级文件数据库，如何在大量弹幕写入并发下避免锁定问题？* \
  *应答*：普通的 SQLite 模式使用排他锁，并发写入会导致 `database is locked` 报错。我们开启了 WAL（Write-Ahead Log）日志模式，实现读写完全不互斥；同时我们将 `synchronous` 设为 `NORMAL`，减少了写磁盘的频次，并将 `temp_store` 改为 `MEMORY` 提高临时表效率。对于偶尔的极端写入竞争，我们设置了 5 秒的 `Busy Timeout` 退避重试，实测将并发写吞吐量由超时报错的 9 TPS 提升到了稳定的 380 TPS。

  #v(0.1cm)
  *问题三：你们是如何管理后台 FFmpeg 异步转码子进程的，如何避免僵尸进程积压？* \
  *应答*：每次客端主播推流成功时，Go 后端会调用 `os/exec` 异步启动一个 FFmpeg 转码子进程。为了防止主播网络异常中断后 FFmpeg 成为无人管理的僵尸进程，我们采用 Go 的 `context.Context` 树状管理机制。每个直播流关联一个带 `cancel` 函数的 context。一旦推流连接断开，我们立刻调用 `cancel()`。这个信号会沿着 Context 树向下传导，向对应的 FFmpeg 子进程发送杀进程信号，并在 `defer` 中捕获进程退出，确保操作系统资源 100% 被自动回收。

  #v(0.1cm)
  *问题四：追帧算法的具体逻辑是什么？* \
  *应答*：当浏览器由于网络抖动发生卡顿时，播放器会堆积缓冲区，导致画面延迟逐渐累积增加。我们基于 Web 端 HTMLVideoElement 的 `timeupdate` 事件进行监控。当检测到缓冲区深度（即 `buffered.end(0) - currentTime`）大于阈值（如 2.5 秒）时，我们会自动将播放速度（`playbackRate`）上调至 1.15 倍进行静音追帧；一旦延迟重新缩小到 1.5 秒以内，则恢复 1.0 倍速。若缓冲区堆积过大（如超过 5 秒），算法会执行强跳帧，直接将 `currentTime` 重新定位到当前缓冲区的最前端，确保高收敛速度。

  #v(0.3cm)
  #text(weight: "bold", fill: rgb("#0f4c81"), size: 9.5pt)[二、 现场同学互动提问] \
  #v(0.1cm)

  *问题五：为什么不直接选择 WebRTC 做流媒体传输？它延迟不是更低吗？* \
  *应答*：WebRTC 确实能将延迟做到 500 毫秒以内，但它架构非常复杂，需要 STUN/TURN 打洞服务器和信令服务器支持，且对服务器的 CPU 消耗和网络带宽开销极高。Hightube 的核心设计理念是“轻量化与单二进制一键部署”。使用 HTTP-FLV 协议不仅可以使用常规的 Caddy 进行证书路由与反代，而且服务器资源消耗极小，非常契合私有化与局域网部署的需求。在未来展望中，我们也列出了支持 WHIP/WHEP 标准 WebRTC 作为高性能后续开发方向。

  #v(0.1cm)
  *问题六：FRP 内网穿透是否会成为性能瓶颈？* \
  *应答*：FRP 确实会在公网中转时引入一定的网络往返时间（RTT）开销，测试表明会带来约 450 毫秒的延迟增加。然而，FRP 仅仅做网络数据包的四层或七层转发，并不进行媒体流的编解码转码，因而它的 CPU 消耗非常低。其主要瓶颈在于公网中转服务器的下行带宽。对于多用户的高并发场景，我们可以通过 Caddy 的反代与 HTTP 重定向机制，将播放流量分流至多个内网节点的 FRP 实例中，实现负载均衡。
]