首次用LIVE Studio，怎样完整验收？

首次用LIVE Studio，不要只看主播端预览正常就直接正式开播。完整验收的关键是：用同一台电脑、同一套采集设备、同一个网络、同一个LIVE Studio实际版本做一次推流确认，并把版本、分辨率与码率、编码状态、观众端反馈、运行时间、日志六项记录下来。

AI生成示意图

有一项关键前提：如果你的测试直播会被外部看到，要把它当作公开开播处理，提前确认平台账号状态、可见范围和开播时间，不能把公开测试误当成“只有自己可见”的预览。主播端预览正常，不等于观众端播放正常。

首播验收记录表

这张表建议在正式开播前填写，不要只在心里打勾。记录表的价值是：以后改了码率、摄像头、网络或电脑，还能知道当前方案是否重新验证过。

验收项
首播时要记录什么
合格判断
1. 版本与软件信息
LIVE Studio版本号；操作系统；电脑型号；摄像头/采集卡；麦克风；网络类型（有线/Wi-Fi/热点）
软件能正常启动、识别设备；版本号与测试时一致，测试后若升级需重测
存档模板
版本号填在“LIVE Studio版本号”列；操作系统、电脑型号、摄像头/采集卡、麦克风分别填入后列；网络类型填写实际连接方式
首栏只填版本号，后两栏按表格列对应填写，不用把多项写在同一格
2. 分辨率与码率
实际输出分辨率；视频码率；帧率；选择的清晰度档位
设置已保存；推流后参数没有被自动改回；分辨率、码率、帧率与所选档位一致
3. 编码状态
编码器名称或硬编/软编状态；CPU/GPU占用；是否有丢帧、编码过载、警告提示
推流过程中没有持续编码警告、过载或大量丢帧；偶发提示要写进日志并复测
4. 观众端反馈
用另一台手机或账号观看：画面、声音、延迟、卡顿、黑屏、音画不同步；记录观看网络
观众端能看到画面、听到声音；没有持续卡顿、黑屏、无声或明显音画不同步
5. 运行时间
开始推流时间、结束时间、连续运行时长；测试期间是否切换网络或改动设置
覆盖正式直播预计时长中的关键阶段；中途不要靠重开软件“刷新”结果
6. 日志留存
截图或导出日志；记录警告出现时间、处理动作、处理结果、复测结果
日志和记录表一起归档；任何改动后能对应到一次新的复测结果
1. 版本：先确认你验收的是哪一套环境

在记录表顶部写下LIVE Studio的实际版本号，以及电脑系统、摄像头、采集卡、麦克风和网络类型。这样做不是形式，而是因为首播验收只对“当次环境”负责。版本号可写成 v；系统、设备、网络按实际填：。

比如，测试时用的是家里的有线网络，正式开播换成商场Wi-Fi；或者测试后软件自动升级、换了采集卡，旧的验收结果就不能直接沿用。只要下面任何一项变化，都应重新检查相关项目：

• LIVE Studio升级或更换安装版本；

• 电脑、摄像头、采集卡、麦克风更换；

• 从有线网络换成Wi-Fi、热点或另一个宽带；

• 改动输出分辨率、码率、帧率或编码器；

• 测试时关闭了后台软件，正式开播时又打开上传、网盘同步、游戏或大型程序。

2. 分辨率与码率：记录“实际输出”，不要套用别的平台参数

在LIVE Studio里记录当前选择的清晰度档位、输出分辨率、视频码率和帧率。重点是看软件实际版本中显示的参数，而不是把其他直播平台或网上教程里的参数搬过来。

火山引擎《直播伴侣常见问题》说明，直播伴侣当前最高支持1080P（蓝光），不支持4K；4K摄像机采集的画面最终会被压缩到1080P。蓝光档位的分辨率固定为1920×1080 px，默认视频码率为3000 kbps，默认帧率为30 fps。这个信息适用于文档所述的当前版本，并未给出具体软件版本号，所以你仍应以自己LIVE Studio界面显示的参数为准。

记录时不要只写“1080P”。建议写成完整一行：

清晰度档位：蓝光；输出分辨率：1920×1080；视频码率：3000 kbps；帧率：30 fps。

如果软件界面显示的数值与上述文档不同，不要强行改成某个教程数值，也不要把YouTube、OBS或其他平台的推荐码率直接填进去。先确认当前LIVE Studio版本提供哪些档位，再用同一网络推流验证。

3. 编码状态：看的是推流过程中有没有持续异常

编码状态不能只在开播前看一眼。开始推流后，要观察编码器是否正常工作，以及有没有编码过载、丢帧、帧率下降、警告弹窗或异常重启。不同版本界面里的名称可能不同，可以记录软件中显示的编码器信息，以及电脑CPU/GPU占用情况。

这里不建议凭一个固定占用率数字判断合格，因为不同电脑、摄像头、画面复杂度和后台程序都会影响结果。更可靠的判断方式是：

• 画面在观众端保持流畅，没有持续模糊、卡顿或掉帧；

• LIVE Studio没有反复提示编码过载、编码器错误或推流失败；

• CPU/GPU占用没有持续处在导致软件警告或画面丢帧的状态；

• 加入美颜、贴纸、游戏画面或多个素材后，问题没有重新出现。

如果只在简单摄像头画面下正常，一加入正式直播要用的素材就卡顿，验收仍不能算通过。

4. 观众端反馈：必须用另一个设备看

主播端预览只能说明本地画面和声音可能正常，不能证明观众已经收到稳定画面。验收时要用另一台手机或其他账号进入直播间观看，最好再让一位同事或朋友在不同网络下观看。

观众端至少记录这些内容：

• 是否能看到画面，是否黑屏或停在封面；

• 是否能听到主播声音，是否有杂音、回声或无声；

• 画面是否持续卡顿、模糊、缓冲；

• 口型和声音是否明显不同步；

• 观看设备使用的是Wi-Fi、移动网络还是其他网络；

• 问题从什么时间开始，是否持续，切换清晰度后有没有变化。

如果测试直播可能公开可见，应提前确认平台的可见范围和账号权限。没有确认私域或测试权限时，不要假设存在“只有自己能看”的隐藏开播按钮。

5. 运行时间：按正式直播的真实节奏测

运行时间不是越短越好，也不需要机械规定一个固定时长。关键是覆盖你正式直播会遇到的负载和持续时间：

• 如果正式直播只讲30分钟，就按30分钟左右的完整流程走一遍；

• 如果正式直播连续数小时，短测只能发现明显配置问题，不能替代长时间稳定性验证；

• 如果直播中会播放视频、连麦、展示商品、切换素材或使用美颜，测试时也要做同样动作；

• 如果开播时段网络使用高峰明显不同，应尽量安排在接近正式直播的时段测试。

记录表中要写清“开始推流时间、结束时间、连续运行时长”。中途如果重启LIVE Studio、切换网络、重新插拔摄像头，应重新计时，不能把前后两段时间加在一起当成连续稳定运行。

6. 日志：把问题、处理动作和结果连起来

日志不是只在出问题时才保留。首播时就应保存日志或关键截图，文件名可以包含日期、账号或直播间编号、测试版本。

每条异常至少记录四件事：

1. 出现时间；

2. LIVE Studio显示的警告或现象；

3. 你做了什么处理，例如降低素材复杂度、切换编码器、关闭后台上传、改用有线网络；

4. 处理后是否复测，结果如何。

这种记录方式参考了开播测试日志的通用做法：记录编码器设置、连接时间、警告、采取的操作和结果；当码率、信号源、网络或编码方案改变后，应重复相关检查并更新记录，避免把旧的成功测试当成新配置仍然有效的证明。该日志方法来自YouTube私有直播测试流程，只能作为记录方法参考，不能把其中的参数搬到LIVE Studio。

建议的验收顺序

第一步：开播前做本地静态核对。 先打开首播记录模板，把版本、系统和网络信息填入第一项，再把分辨率码率和编码信息填入第二、三项，确认摄像头、麦克风、采集卡都被软件识别。

第二步：进入推流测试。 使用正式直播要用的全部素材和功能，不要只开一个空白摄像头画面。测试前再次确认直播是否公开可见。

第三步：用观众端核对。 至少用另一台设备观看画面和声音，有条件时增加不同网络的观看者。把反馈写入表格，而不是只口头说“有点卡”。

第四步：持续运行并观察编码状态。 按正式直播流程运行，记录开始和结束时间、警告、卡顿、素材切换和网络变化。

第五步：结束后保存日志。 将记录表、截图或日志放在同一个文件夹；统一命名，例如账号日期_测试版本_首播验收表。若测试中改动过设置，在记录表中注明改动时间，并说明改动后是否重新测试。

常见不合格项怎么处理

现象
先记录什么
处理方向
观众端黑屏或看不到直播
发生时间、主播端是否正常、观众端提示、网络类型
先确认推流状态和直播可见范围；不要只凭黑屏断定是网络故障
画面持续卡顿
卡顿时间段、观众网络、编码警告、码率和帧率
关闭其他占用上传的程序，简化素材或改回LIVE Studio推荐档位；改完后复测
声音异常或音画不同步
麦克风型号、观众端现象、是否使用采集卡音频
重新确认音频输入设备，检查采集卡声音来源；用观众端复测，不只看本地音量条
编码过载或大量丢帧
编码器状态、CPU/GPU占用、当时使用的素材
减少高负载素材、关闭无关程序或尝试软件当前可用的编码选项；任何更改后重新测试
运行一段时间后异常
已运行多久、异常前做过什么、日志提示
不要把短测正常当作长期稳定；按正式直播时长复测，并保留完整日志
两路或多路画面同时出问题，关掉一路后恢复
当时设备负载、素材数量、网络和编码状态
这只能说明问题与并发条件有关，不能直接断定是运营商带宽上限；还要排查设备编码负载、局域网和推流链路
一次测试通过，只代表本次设备、网络、软件版本和设置下没有发现问题，不代表以后更换环境也一定稳定。正式开播前最稳妥的做法，是把这张首播记录表归档；之后只要升级软件、更换网络或调整音视频设置，就针对变化项重新验收。