mcpField
L
livestream-event-production

livestream-event-production

github.com/calesthio创意与媒体219104 次安装15 周前更新
代码仓库

关于 livestream-event-production

面向实时或混合直播活动的供应商无关技能，可用于规划、彩排、执行、排障和交接。它围绕流程时间、人员、信号、网络传输、无障碍和事故响应组织制作计划。

主要功能

  1. 01定时节目流程规划
  2. 02人员职责与沟通渠道
  3. 03信号、音频和图形方案
  4. 04网络与传输规划
  5. 05彩排和事故处置流程

适用场景

  1. 01规划多位讲者参与的网络研讨会
  2. 02筹备混合形式的会议环节
  3. 03协调直播活动彩排
  4. 04制定备份与事故方案

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/calesthio/generative-media-skills --skill livestream-event-production

安装后在 Claude Code 中输入/livestream-event-production确认已加载。

附带文件EVAL.md

详细介绍

直播活动制作

当用户需要 AI Agent 策划、导演、彩排、执行、排障或交接直播或混合式直播活动时，使用此技能。活动可以是网络研讨会、会议环节、市政厅会议、发布会、圆桌讨论、课程、募款活动、礼拜仪式、演出、创作者节目、新闻发布会或多会场混合式活动。

这是一项与服务提供商无关的制作技能。它应产出实用的制作方案，而不是针对单个平台的集成指南。

以下情况不要使用此技能：

  • 事后重新剪辑、打包或编辑已录制的直播；
  • 单一服务提供商的 API 集成、账户设置或特定仪表板的点击路径；
  • 纯电影风格的预录视频制作，且不涉及现场切换、现场嘉宾、信号接入、监控或事件计划；
  • 通用社交短视频剪辑、播客剪辑或访谈视频重剪任务，除非产出内容是直播活动方案。

证据标签

提出主张时，请区分以下类别：

  • 有文档依据的事实： 有标准、第一方文档页面、监管机构页面或正式技术报告支持该主张。
  • 易变的平台事实： 特定平台的设置、编解码器表、码率建议、信号接入限制、功能可用性或仪表板行为。请注明核实日期。
  • 制作经验法则： 经实地验证但并非标准的操作指导。应将其作为决策参考，而非普遍要求。

操作模式

直播既是现场节目，也是实时网络服务。两者都要考虑。

Agent 应产出或索取以下材料：

  • 活动简介：受众、目标、平台去向、隐私级别、权利、语言、无障碍要求、时长、成功指标；
  • 节目流程表：具体环节、时间安排、提示、信号源、演讲者、幻灯片、图形、字幕条、视频、投票、问答、赞助商口播、休息、备用内容；
  • 工作人员计划：制片人、技术导演／切换员、音频工程师、图形操作员、流媒体工程师、舞台监督、版主、字幕负责人、嘉宾协调员、录制／媒体管理员、事件负责人；
  • 信号计划：摄像机、屏幕共享、远程嘉宾、播放内容、音频总线、图形、节目输出、干净信号、监看屏、通信、录制、平台信号接入；
  • 网络与传输计划：信号贡献、信号接入、分发、延迟配置、主用／备用路径、带宽余量、监控点；
  • 彩排与是否开播计划；
  • 事件计划与交接资料包。

接洽问题

只询问会改变制作风险的未知信息。如果用户只提供了部分简介，则基于假设继续，并标明这些假设。

关键问题：

  • 活动是仅直播、混合式，还是带有现场互动的录播？
  • 受众规模、播放平台列表、隐私模式和回放要求是什么？
  • 哪些互动必须具有实时感：聊天、问答、投票、来电提问、拍卖、捐赠环节、现场口译、后台演讲者切换？
  • 这些互动可接受的延迟是多少？
  • 谁会出镜、从哪里连线，以及网络和控制条件如何？
  • 是否需要字幕、手语、音频描述、翻译或满足合规义务？
  • 故障容忍度如何：节目能否暂停、切换到静态画面、改为纯音频、播放录制内容，还是必须不间断继续？
  • 必须录制哪些内容：节目输出、干净信号、独立摄像机画面、独立嘉宾信号、多轨音频、字幕、聊天／问答、幻灯片、遥测数据？

流程表

流程表是控制文档。它应标注时间、便于发出提示，并能在压力下派上用场。

包括：

  • 活动的绝对时间和节目相对时间；
  • 环节标题和负责人；
  • 节目中的当前信号源、预览中的下一信号源、音频信号源、图形状态、字幕／口译状态；
  • 主持人、制作人、技术导演、音频、图形、版主、舞台监督和远程嘉宾的准确提示用语；
  • 预计时长、硬性结束时间和超时方案；
  • 互动触发条件及其对延迟的影响；
  • 信号源不可用时的备用方案。

制作经验法则：任何需要工作人员记住画外依赖项的环节，都应在流程表中单独列出一行。幻灯片、视频、演讲者登场、赞助商口播、投票、字幕员交接、语言频道切换和主持审核交接都要单独列出，不能只靠口头记忆。

工作人员与通信

按职责分配角色，即使一人身兼多职也应如此。

  • **制作人：**负责节目意图、时间安排、是否开播的决策、客户／利益相关方沟通渠道和事件升级处理。
  • **技术导演／切换员：**负责节目切换、预览、宏、摄像机／信号源就绪情况、静帧，以及紧急画面备用方案。
  • **流媒体工程师：**负责编码器、信号接入、网络、冗余、平台状态、流媒体遥测和故障切换。
  • **音频工程师：**负责返送混音、增益级设置、响度一致性、防回声、音乐／播放路由、通话音频隔离和备用音频。
  • **图形操作员：**负责字幕条、标识、标题、计时器、待机静帧、适用时的字幕显示路由，以及赞助商／法律声明图形。
  • **舞台监督／嘉宾协调员：**负责演讲者签到、候场室、倒计时、静音纪律、镜头构图、同意确认，以及远程演讲者的备用方案。
  • **版主／社区负责人：**负责聊天规则、问答分流、升级处理、屏蔽词、链接政策、内容移除和安全干预。
  • **字幕／无障碍负责人：**负责实时字幕、口译窗口（如有）、字幕平台路径、文字稿交接和无障碍检查。
  • **录制／媒体管理员：**负责节目录制、独立录制轨道、文件命名、存储、备份、字幕／文字稿和活动后资料包。

使用单独的频道来处理：

  • 节目调度：制作人、技术导演、音频、图形、流媒体工程师、舞台监督；
  • 演讲者候场室：主持人、嘉宾、嘉宾协调员；
  • 利益相关方／客户备注：仅制作人，或制作人与客户负责人；
  • 事件升级处理：人数精简、指定明确且有决策能力的小组。

制作经验法则：除非演示者受过操作培训，否则不要让他们加入技术频道。大多数直播失误都会因太多人听到错误的倒计时而变得更严重。

采集、切换、音频和图形

摄像机和信号源

对每个画面信号源，记录：

  • 信号源名称和负责人；
  • 实体位置或远程位置；
  • 分辨率、帧率、色彩空间（如已知）和宽高比；
  • 预期镜头类型或屏幕内容；
  • 主路径和备用路径；
  • 是否需要与音频、幻灯片、字幕或其他摄像机同步。

制作经验法则：

  • 关键幻灯片或视频应优先使用稳定且有明确名称的信号源，而非临时屏幕共享。
  • 对混合式会场，要将现场观众和线上观众视为不同的受众。线上观众需要更近的镜头、清晰可懂的现场提问，以及明确的视觉背景信息。
  • 在彩排前加载待机静帧、活动标题卡、休息时循环画面、技术故障静帧和结束卡。
音频

音频故障通常比视频故障更具破坏性。

规划内容：

  • 麦克风列表、负责人和电池／供电计划；
  • 节目混音，以及任何纯净音频／混音减除馈送；
  • 远程嘉宾回传音频；
  • 播放和音乐音量；
  • 回声消除边界；
  • 混合活动中的场地扩音系统交互；
  • 备用音频路径，例如电话桥接、备用 USB 麦克风、环境音麦克风或辅助音频接口。

制作经验：

  • 远程访谈中，每位嘉宾都应佩戴耳机，除非已使用完全相同的平台和路由测试过回声消除。
  • 切勿将延迟的节目音频回传给参与者本人。
  • 测试静音／取消静音的控制权归属。如果嘉宾可以自行静音，舞台监督必须知道如何快速恢复音频。
  • 在故障预案中，将主持人音频列为最高优先级。画面黑屏但主持人音频清晰，尚可应对；音频无法听清则不行。
图形

将图形设计为可在直播中操作的状态：

  • 下三分之一字幕条和姓名发音备注；
  • 标题卡、议程卡、休息画面、等待画面、技术故障画面；
  • 计时器、倒计时、赞助商／法律声明标识、二维码／链接图形；
  • 投票／问答结果；
  • 为字幕／手语翻译布局提供适配。

图形不得遮挡字幕、手语翻译人员、法律要求披露的信息或幻灯片中的关键内容。

编码、信号接入、传输与分发

区分信号贡献、信号接入和观众分发。混淆这些环节会导致计划不当。

  • **信号贡献：**摄像机、场地、编码器或远程嘉宾将信号发送到制作系统。
  • **信号接入：**制作编码器将成品流或中间流发送到平台、CDN、云端切换器、打包器或中继。
  • **分发：**观众接收播放内容，通常通过 HTTP 自适应流媒体、平台播放器、应用或交互式实时服务实现。
RTMP 和 RTMPS

操作指南：RTMP 仍常用于将直播信号贡献／接入到流媒体平台和编码器。RTMPS 是通过 TLS 传输的 RTMP；如果目标平台支持加密信号接入，应优先使用 RTMPS。应将 RTMP(S) 主要视为信号贡献／接入协议，而非现代浏览器观众播放层。

截至 2026-07-11 核实的易变平台信息：YouTube 的直播编码器文档列出了 RTMP 和 RTMPS 信号接入，并推荐使用 RTMPS，因为流会在传输到 Google 服务器及通过服务器的过程中加密；文档还建议在直播前进行测试并监控流状态。同一页面列出了特定于平台的编解码器、关键帧、比特率和音频指南，制作前必须重新核实。来源：https://support.google.com/youtube/answer/2853702

制作经验：

  • 妥善保管流密钥，避免将其放入广泛共享的节目流程文档中。
  • 如果目标平台支持备用信号接入 URL／密钥，请准备备用方案。
  • 如果通过公共互联网使用 RTMP，应优先保障网络稳定性和编码器运行状态，因为重传行为和平台缓冲机制会因实现方式而异。
SRT

文档事实：SRT Internet-Draft《The SRT Protocol》将 SRT 描述为一种基于 UDP 的用户级协议，旨在为低延迟实时视频流提供可靠、安全的传输。该草案介绍了呼叫方—侦听方和会合连接配置、握手期间协商的 SRT 缓冲延迟（即对等方提出的最大延迟）、基于 ARQ/NAK 的数据包重传（实时流会丢弃过迟的数据包），以及通过交换密钥材料使用 AES-CTR 加密有效载荷。该草案已于 2021 年到期，因此应将其视为协议说明，并结合当前的实现文档使用。来源核实于 2026-07-11：https://datatracker.ietf.org/doc/html/draft-sharabayko-srt-00

文档事实：Haivision 的公开 SRT API 文档介绍了绑定、侦听和接受连接，通过 srt_connect 发起呼叫方连接，使用 SRTO_RENDEZVOUS 或 srt_rendezvous 设置会合连接，Live 传输默认值，SRTO_RCVLATENCY、SRTO_PEERLATENCY、SRTO_TLPKTDROP、SRTO_NAKREPORT、SRTO_PASSPHRASE、SRTO_PBKEYLEN 等套接字选项，以及密钥材料状态选项。来源核实于 2026-07-11：https://github.com/Haivision/srt/blob/master/docs/API/API.md 和 https://github.com/Haivision/srt/blob/master/docs/API/API-socket-options.md

操作指南：SRT 常用于网络状况不佳时的信号回传场景，此时低延迟、数据包恢复、加密选项以及呼叫方／侦听方／会合连接模式都可能很重要。具体行为取决于实现：编码器／解码器构建方式、开放的套接字选项、防火墙／NAT 行为、云端接收器策略和版本支持情况都会影响可配置和可监控的内容。

在以下情况下使用 SRT：

  • 场馆或远程摄像机必须通过公共互联网向制作控制室回传信号；
  • 网络状况不稳定，但可以接受配置缓冲延迟；
  • 团队可控制发送端和接收端的配置；
  • 可提前测试防火墙／NAT 角色。

制作经验：

  • 将 SRT 延迟作为制作方面的权衡来设置：值越低，体感越快，但恢复时间越短；值越高，稳定性越好，但延迟也越大。
  • 尽可能使用相同的网络路径和时段进行彩排。
  • 在演出当天之前，确认加密、密码策略、端口方向、呼叫方／侦听方／会合角色以及回退方案。
HLS

文档事实：HTTP Live Streaming（HLS）使用播放列表和媒体分段。RFC 8216 定义了媒体播放列表、主播放列表、媒体分段、变体流、呈现版本、目标时长、序列／不连续行为，以及 WebVTT 字幕承载方式。来源：RFC 8216，https://www.rfc-editor.org/rfc/rfc8216

当大规模分发、设备支持、CDN 分发和自适应码率播放比亚秒级交互更重要时，使用 HLS 面向广大观众提供内容。

规划影响：

  • HLS 交付延迟受编码器设置、分段时长、播放列表行为、打包器／源站行为、CDN、播放器缓冲区和播放器直播边缘策略影响。
  • 主播放列表允许播放器在多个变体／呈现版本之间进行选择；这些变体需要内容同步，才能无缝切换。
  • HLS 工作流可使用 WebVTT 提供字幕／隐藏式字幕，但必须确认特定平台的字幕接入和显示行为。

制作经验：如果聊天或问答环节依赖观众看到的准确时序，不要假设所有 HLS 观众看到的都是同一时刻。应为交互环节预留缓冲时间。

WebRTC

已记录事实：W3C WebRTC 1.0 规范定义了浏览器之间的实时通信，包括对等连接、媒体轨道、数据通道、ICE、DTLS 传输、RTP 媒体和统计接口。来源：W3C Recommendation，2025 年 3 月 13 日，https://www.w3.org/TR/webrtc/

已记录事实：RFC 8835 描述了 WebRTC 传输协议，包括 UDP/TCP 假设、用于 NAT 和防火墙穿透的 ICE/STUN/TURN、用于媒体密钥协商的 DTLS-SRTP、用于数据通道的基于 ICE 的 DTLS 上 SCTP，以及 QoS/优先级考量。来源：RFC 8835，https://www.rfc-editor.org/rfc/rfc8835

已记录事实：RFC 8834 描述了 WebRTC 中的媒体传输和 RTP 用法，包括 RTP/RTCP、SRTP/SRTCP、拥塞控制要求、RTCP 反馈，以及通过丢包和抖动统计进行性能监控。来源：RFC 8834，https://www.rfc-editor.org/rfc/rfc8834

以下情况适合使用 WebRTC：

  • 远程嘉宾需要自然交谈；
  • 观众互动需要极低延迟；
  • 工作流需要基于浏览器的内容贡献、数据通道或类似会议的拓扑；
  • 预期观众规模和架构能够支持。

规划注意事项：

  • WebRTC 并非自动适用于大规模广播分发。大型观众通常需要 SFU、中继、桥接，或转换为 HTTP 分发格式。
  • TURN 容量可能成为远程嘉宾和互动观众的隐性瓶颈。
  • 在实现提供相关数据的情况下，监控 ICE 状态、选定的候选对、往返时间、抖动、丢包数、丢帧数、质量受限原因、可用的出站比特率、音频电平和画面冻结情况。W3C WebRTC Statistics API 定义了许多此类标识符，但它目前是候选推荐草案；对于具体字段是否可用，应将其视为仍在制定中的内容。来源：https://www.w3.org/TR/webrtc-stats/

延迟与互动性

应根据观众互动需求选择延迟配置，而不是笼统地追求更快。

需求推荐配置说明
单向主题演讲、大量观众、优先考虑回放标准/普通延迟 HTTP 分发更稳定；聊天可以异步进行。
主持人从聊天中挑选问题的现场问答支持时使用低延迟 HTTP/平台模式加入审核延迟，并为提问预留时间缓冲。
双向讨论、远程来电、拍卖、在线课堂WebRTC/会议路径或专用低延迟服务需要更严格的嘉宾管理、TURN/网络规划和内容审核。
关键广播、合规要求、字幕、多家 CDN以稳定性为先的延迟配置使用经过排练的故障切换，并避免未经测试的低延迟模式。

平台易变事实，已于 2026-07-11 核实：YouTube 的编码器设置页面说明，4K/2160 内容不支持低延迟直播，并且针对普通延迟画质进行了优化。由于平台功能会变化，依赖此信息前请重新核实。来源：https://support.google.com/youtube/answer/2853702

制作经验法则：降低延迟会消耗可靠性余量。只在节目形式确实需要时才使用。

带宽与冗余

根据整个链路计算带宽，而不只是编码器码率。

包括：

  • 节目码率、音频和协议开销；
  • 同时使用的备用流；
  • 回传信号、通话、监看、字幕、远程嘉宾信号、云端切换和文件传输；
  • 场馆的其他网络流量及 Wi-Fi 争用；
  • 上传、下载、丢包、抖动和持续吞吐量。

制作经验法则：

  • 在受控网络上，持续上行带宽至少应达到计划总外发直播负载的 2 倍；在共享、无线、蜂窝或情况未知的链路上，应留出更多余量。
  • 如果备用链路与主链路共用相同的最后一公里故障点、电源、路由器、交换机、SIM 卡运营商或账户配额，就不能算作冗余链路。
  • 聚合链路和蜂窝链路很有用，但并非万能。要在负载下测试网络拥塞、数据上限、热表现、天线位置和故障切换。
  • 预先加载离线备用素材：技术故障提示画面、主持人拨入脚本、预录的紧急开场，或纯音频桥接方案。

冗余级别：

  • 级别 0： 一个编码器、一个网络、一个目标平台。仅用于低风险直播。
  • 级别 1： 主编码器配置加备用编码器配置，或同一网络上的备用接入点。可应对部分软件或配置故障。
  • 级别 2： 独立编码器或独立机器，加上独立网络链路。可应对更多本地故障。
  • 级别 3： 并行制作或云端故障切换，独立电源和网络、备用操作员、目标平台故障切换或多 CDN。适用于高风险公开活动。

彩排与是否开播的决策

至少进行三项检查：

  • 技术线路检查： 检查每个信号源、麦克风、图形、播放素材、字幕链路、远程嘉宾链路、录制链路和目标平台接入点。
  • 逐 cue 彩排： 演练转场、开场、休息环节、演讲者更换、互动环节、字幕条、视频播放和紧急提示画面。
  • 全流程彩排： 使用实际时长、实际操作员、实际网络、实际目标平台或私人测试目标平台，以及实际字幕/审核工作流。

是否开播的检查项应包括：

  • 主接入点和备用接入点均已上线/准备就绪；
  • 节目音频清晰易懂，电平表稳定；
  • 如有需要，已验证字幕链路；
  • 录制链路已就绪，并已检查存储空间；
  • 通话稳定；
  • 已确认嘉宾姓名、发音和字幕条；
  • 已确认权利、同意和许可；
  • 审核规则已启用；
  • 已指定事故负责人；
  • 利益相关方已批准最终开播。

制作经验法则：只有在有人实际演练过故障后，才算完成彩排：嘉宾掉线、麦克风故障、幻灯片信号源失效、编码器警告、平台运行状况警告，或启用紧急提示画面。

字幕、无障碍与包容性

已记录事实：WCAG 2.x 成功准则 1.2.4 要求在 AA 级别为同步媒体中的实时音频内容提供字幕。W3C WAI 说明，实时字幕通常由专业实时字幕员/CART 速记员提供；自动字幕除非经过确认且完全准确，否则并不足够。来源已于 2026-07-11 核实：https://www.w3.org/WAI/media/av/captions/ 和 https://www.w3.org/WAI/media/av/planning/

已记录事实：FCC 提供美国电视视频节目的隐藏式字幕规则以及质量和责任相关资源，其中包括 47 CFR 第 79 部分的参考内容。必须根据每种分发情境核实管辖权和适用性。来源已于 2026-07-11 核实，页面更新于 2026 年 4 月 8 日：https://www.fcc.gov/general/closed-captioning-video-programming-television

已记录事实：47 CFR § 79.4 涵盖通过互联网协议传送的视频节目的隐藏式字幕。该条款定义了通过 IP 传送的视频节目相关角色和要求，包括要求受该规则约束的视频节目所有者提供字幕，且字幕质量至少与同一节目在电视上的字幕质量相同；还要求受该规则约束的分发方/提供方启用所需字幕的渲染或直通传递，供最终用户使用。是否适用取决于节目是否属于该规则所涵盖且不享受豁免的视频节目。来源已于 2026-07-11 通过 eCFR 核实；第 47 篇显示为截至 2026-07-09 的现行版本：https://www.ecfr.gov/current/title-47/chapter-I/subchapter-C/part-79/section-79.4

计划内容：

  • 实时字幕服务提供方或经过验证、准确的自动字幕；
  • 字幕来源及其接入平台/播放器/录制内容的路径；
  • 不会被图形遮挡的字幕显示区域；
  • 活动结束后的文字稿交接；
  • 如有要求，提供语言口译、手语翻译画面或音频描述；
  • 提供无障碍幻灯片，确保字体易读、对比度合适，并口头描述仅以视觉形式呈现的内容；
  • 主持人处理直播期间无障碍请求的流程。

制作经验法则：

  • 如果要求提供字幕，就应将字幕中断视为节目事故，而非外观瑕疵。
  • 字幕员需要提前准备：姓名、行话、缩写、议程、演讲者名单、URL、赞助商名称和技术术语。
  • 手语翻译画面需要稳定的构图、在版式中拥有优先位置，并避免被下三分之一字幕条遮挡。

监管、同意、权利与安全

直播前计划好：

  • 谁可以出现在镜头中，以及是否记录了同意；
  • 观众聊天/问答是公开、私密、延迟显示还是经过审核；
  • 屏蔽词、链接政策、垃圾信息处理、升级处理流程和移除权限；
  • 演讲者授权、音乐权利、素材/媒体权利、赞助商/法律文案以及回放权利；
  • 如何处理涉及未成年人、患者、学生、员工、机密信息或受限活动的隐私问题；
  • 紧急停止条件，以及谁有权切断直播、将嘉宾静音、隐藏聊天内容或移除来电者。

制作经验法则：审核处理流程必须比事故发生得更快。如果出现有害消息、私人信息或不安全的来电者，主持人不应需要征求五个人的许可。

监控与事件响应

在多个节点进行监控：

  • 编码前的本地节目输出；
  • 编码器运行状况：CPU/GPU、丢帧、输出码率、关键帧间隔、音频采样率、重连情况；
  • 网络：上行吞吐量、丢包、抖动、路由变化、接口故障切换、蜂窝信号；
  • 推流接收端运行状况：平台/服务器接收情况、备用推流接收端状态、流状态消息；
  • 观众播放情况：使用非生产网络的独立观众、字幕、音画同步、聊天/Q&A；
  • 录制情况：节目录制、干净信号、各路独立信号、音频多轨、字幕/转录稿。

事件处理流程：

  1. 说明症状：发生了什么变化、谁能看到、何时开始，以及哪个监控节点发现了问题。
  2. 控制对观众的影响：切换到占位画面、让主持人即兴串场、静音异常信号源、切换到备用信号源、更换网络、降低码率、暂停互动，或改为纯音频。
  3. 保存证据：时间戳、截图/日志、平台运行状况消息、编码器统计数据、操作人员备注。
  4. 做出决定：继续、降级、故障切换、暂停、重启或中止。
  5. 沟通：向主持人、相关方、聊天区/版主发送一条经制作人批准的消息，并记录在活动后备注中。

制作经验：

  • 避免在节目输出中进行实时调试。先切换到稳定的信号源。
  • 如果音画不同步，应在观众成为监控系统之前决定修复、切换还是简化。
  • 使用客观、冷静的事件描述：“我们正在恢复远程嘉宾信号”比“一切都坏了”更合适。

录制、各路独立信号与交接

活动前定义要录制的内容：

  • 包含观众所见图形和字幕的节目输出；
  • 不含图形的干净信号；
  • 各路独立摄像机信号；
  • 各路独立远程嘉宾信号；
  • 多轨音频或分轨；
  • 幻灯片、播放文件、图形素材包、字幕文件、转录稿、聊天/Q&A 导出文件；
  • 遥测数据、事件日志、含实际时间的流程表。

交接包应包含：

  • 最终录制文件的位置，以及必要时的校验和；
  • 文件命名规则和存储负责人；
  • 已知问题及时间戳；
  • 权利/使用限制；
  • 字幕/转录稿状态；
  • 回放发布说明；
  • 复盘备注和建议的修复措施。

制作经验：尽可能在本地录制，即使平台也会录制。平台录制可能开始得太晚、缺少干净信号、漏掉各路独立信号、混缩音频，或不包含字幕/聊天内容。

示例：75 分钟混合式圆桌论坛方案

这只是一个示例，并非必须遵循的固定公式。

简介：

  • 受众：800 名线上观众，120 名现场观众。
  • 形式：混合式主题演讲、圆桌论坛和主持人引导的问答环节。
  • 要求：字幕、回放、赞助商下三分之一屏字幕、聊天提问。
  • 延迟：满足问答需求即可，无需支持观众视频双向互动。
  • 故障容忍度：直播可以切换到主持人画面或静态画面，但不能中断。

推荐方案：

  • 分发：如果目标平台支持，采用低延迟模式，通过平台/CDN 使用 HTTP 分发；避免使用 WebRTC 向观众分发，因为只有问答文字需要互动。
  • 信号输入：现场摄像机/切换台采用本地连接；远程嘉宾通过经过测试的会议/WebRTC 信号输入制作系统；为远程嘉宾准备备用电话音频。
  • 音频：现场领夹麦克风加观众提问麦克风；远程嘉宾使用混音减除；主持人麦克风优先；舞台上备用一支手持麦克风。
  • 图形：标题、议程、下三分之一屏字幕、赞助商标识、问答提示、休息/技术故障静态画面。
  • 工作人员：制作人、技术总监、音频师、直播工程师、舞台监督、主持人、字幕负责人、图形操作员、录制负责人。
  • 冗余：主用有线互联网加独立蜂窝/绑定备份；将备用编码器配置文件连接到备用接入点；本地录制节目输出并启用平台录制；如果远程嘉宾掉线，使用其备用幻灯片/视频。
  • 彩排：提前一天进行线路检查；为远程嘉宾安排 30 分钟技术检查；与主持人和主持人进行逐段走台；演练远程嘉宾掉线故障。

示例流程表行：

时间环节节目画面音频图形提示备用方案
-00:10等候动态静态画面低音量音乐活动标题 + 字幕提示直播工程师确认接入正常使用编码器输出静态画面
00:00开场摄像机 1 拍摄主持人主持人领夹麦克风主持人下三分之一屏字幕制作人：“主持人，5 秒后开始直播”保持静态画面，只播主持人音频
00:08远程嘉宾介绍主持人/嘉宾双画面主持人 + 嘉宾混音减除嘉宾下三分之一屏字幕舞台监督确认嘉宾已准备就绪主持人概述嘉宾观点
00:45问答主持人镜头、提问卡片主持人 + 现场麦克风问答下三分之一屏字幕主持人提供已审核的问题使用预先准备的备用问题
01:10结束摄像机 1 拍摄主持人主持人领夹麦克风致谢/结束卡片制作人：“2 分钟后准时结束”播放结束卡片和音乐

示例：故障事件决策树

这只是一个示例，并非必须遵循的固定公式。

症状：平台报告直播流不稳定，观众监看画面显示正在缓冲。

  1. 直播工程师检查编码器丢帧、输出码率、CPU/GPU 使用情况和网络上传状态。
  2. 如果编码器过载：降低输出配置文件规格，或切换到备用编码器场景/配置文件。
  3. 如果上传链路不稳定：切换到备用网络或绑定链路；在恢复稳定前保持保守码率。
  4. 如果平台接入状态异常，但本地和网络均稳定：如果已做好准备，则切换到备用接入点/目标平台。
  5. 如果只有观众播放受到影响：先检查独立观众监看、平台状态、CDN/播放器报告和聊天量，再决定是否中断节目。
  6. 制作人决定由主持人说明情况、由主持人发布状态通知，还是节目继续进行且不作说明。
  7. 录制负责人标记故障事件时间戳，并确认本地录制正常。

示例：传输方式选择总结

这只是一个示例，不是必须遵循的公式。

场景可能的选择原因
编码器向主流平台推流如果平台支持，则使用 RTMPS；否则使用平台认可的 RTMP/SRT 方案常见的平台推流模式；条件允许时对推流进行加密。
场馆摄像机连接远程控制室SRT 或托管贡献服务可调节延迟与恢复机制，并能控制端点。
大规模公众观众观看播放内容HLS 或平台/CDN 自适应传输可覆盖多种设备和 CDN 规模，并支持自适应码率。
远程嘉宾进行自然对话WebRTC/会议/SFU 方案低延迟交互式媒体，以及数据/控制接口。
主题演讲期间观众通过文本提问HLS/平台传输加经审核的聊天/问答如果设计好审核时间窗口，文本可以容忍传输延迟。
现场连线嘉宾加入节目通过 WebRTC/会议将连线内容接入切换后的节目需要审核、征得同意、IFB/返送音频，以及快速移除连线的方案。

来源说明（已于 2026-07-11 核实）

评论

支持 Markdown