2026/9/3 4:04:06
FEATURED · 精选文章 
这次我们来看一个直播场景的硬需求多选手淘汰赛直播。标题是《爱jigTV 新版本寄生体内卷大乱斗8进4淘汰赛》这种节目如果只靠一个主摄像推流很容易变成灾难多路视频源来回切、计分板更新靠手动、弹幕互动跟不上节奏、赛前素材堆积成山。真正能稳定跑下来的背后通常是一套“直播互动赛事系统”。先说明一点这不是某个能直接下载的软件而是一套可以自己搭建的技术方案。文章内容会围绕四个核心需求展开多路视频源接入、实时计分与弹幕投票、接口化控制、批量素材处理。下面会给出可复用的代码、命令和资源占用观察方法。就算你的节目不是“寄生体内卷大乱斗”而是一个普通的 8 进 4 比赛、K 歌淘汰赛、连麦闯关直播这套思路也一样能用。这套方案的核心不是堆显卡也不依赖大模型。计分服务、浏览器源、批量转码脚本都不需要很高的配置真正的瓶颈通常在视频解码和推流编码。所以我会从简单的本地计分面板开始再逐步接到 OBS最后把批量任务和接口控制连起来。整个过程不需要专业导播台一台能跑 OBS 的电脑就可以完成。1. 核心能力速览能力项说明直播结构主控 OBS 本地计分 Web 服务 多路视频源核心功能弹幕投票、实时计分、批量转码、对阵表生成、低延迟状态推送运行平台Windows / macOS / Linux 均可OBS 负责推流推荐硬件4 核以上 CPU、16GB 内存带 NVENC 的 N 卡或核显编码更稳软件依赖OBS Studio、Python 3.9、FFmpeg、flask-socketio、obs-websocket 插件接口能力提供 HTTP 投票接口、WebSocket 状态推送、OBS 远程切换场景批量任务支持批量转码、批量生成赛程 JSON、批量生成预览图上手难度中等需要会改少量 Python 代码和 HTML应用场景电竞淘汰赛、综艺娱乐赛、K 歌大赛、答题闯关直播等合规边界素材、人脸、音乐、直播素材需确认授权本地服务不要公网裸奔从这个表能看出来它不是一个大模型项目而是一套“直播自动化”方案。核心优势是廉价、可控、能接接口。直播过程中主持人只需要关注节奏计分和切换可以由脚本或副控完成。2. 适用场景与使用边界这类方案适合谁如果你的直播内容经常有“多名选手依次出场”“观众投票影响结果”“赛程紧凑需要不停切换画面”这些情况那就很值得搭一套。比如街舞比赛、翻唱比赛、游戏 8 进 4、答题闯关、选秀综艺甚至晚会抽奖本质都是同一个逻辑多个来源 实时状态 切换展示。把这套逻辑抽出来做成系统比每次直播手动改文本和切换画面要可靠得多。它能解决的问题也很明确多路视频源不用反复拖放文件到 OBS而是提前批量转化好。计分板不只是显示数字还能收到投票请求后自动更新。弹幕、网页、遥控器、第二机位都可以通过 HTTP 或 WebSocket 触发场景切换。赛前素材准备从“手动改几十条文件名”变成“跑一遍脚本”。同时也要说清楚边界。这套方案不适合广电级正式节目因为 OBS 本身的稳定性依赖操作系统和网络没有专业导播台那种物理切换容错。也不适合需要多人协同编辑的高安全场景我建议把权限收敛在本地。另外凡是涉及选手肖像、音乐素材、视频片段、直播间画面都必须确认授权。特别是“寄生体内卷大乱斗”这类娱乐企划很可能包含二创、剪辑、配音素材用之前一定要把来源理清楚。技术上的边界也要注意弹幕平台通常有延迟不是本地 WebSocket 能解决的。投票工具适合做参考、互动和现场辅助如果涉及奖金、赛事结果需要加人工复核流程不能完全让脚本决定。3. 环境准备与前置条件3.1 硬件与带宽先给一套通用配置建议CPU4 核以上尽量选 6 核或更高。内存16GB 起步。OBS 打开一个浏览器源就会多开一个 Chromium 进程用的内存不小。显卡NVIDIA 显卡优先开启 NVENC 硬件编码后可以显著降低 OBS 的 CPU 占用。上行带宽至少 8 Mbps 到 10 Mbps。B 站推流常见码率是 6000 Kbps如果同时还要上传素材带宽需要预留更多。存储按“原始素材 转码素材 录播文件”分目录建议预留 50GB 以上空间。3.2 软件清单OBS Studio负责视频合成和推流。FFmpeg负责批量转码、裁剪、截图。Python 3.9运行投票服务和计分服务。Node.js 可选如果后续要写更复杂的 WebSocket 网关。obs-websocket 插件新版 OBS 已内置旧版需要单独安装用于远程切换场景。3.3 推荐目录结构live-event/ ├── raw/ # 原始素材不轻易改动 ├── clips/ # 统一转码后的片段 ├── preview/ # 预览图 ├── output/ # 录播或最终文件 ├── schedule.json # 赛程/对阵表 ├── score_server.py # 计分投票服务 └── static/ └── scoreboard.html # 计分板页面这个结构可以避免直播时到处找文件。所有素材、脚本、结果都按固定目录放后续写批量任务也更方便。4. 弹幕投票与计分面板搭建先做一个最小的“本地计分面板”。它不推流只负责接收投票、累计分数并通过 WebSocket 推送给 OBS 浏览器源。4.1 项目结构与依赖mkdir -p live-event/static cd live-event python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install flask flask-socketio eventlet服务端使用 Flask Flask-SocketIO前端使用 SocketIO 客户端。这个方案在本地跑很稳不需要额外数据库数据放内存里即可。4.2 启动计分服务创建score_server.pyfrom flask import Flask, render_template, request from flask_socketio import SocketIO, emit app Flask(__name__) app.config[SECRET_KEY] live-score socketio SocketIO(app, cors_allowed_origins*) players { A: {name: 选手A, score: 0, alive: True}, B: {name: 选手B, score: 0, alive: True}, } app.route(/) def index(): return {status: live-scoreboard} app.route(/scoreboard) def scoreboard(): return render_template(scoreboard.html) app.route(/vote, methods[POST]) def vote(): data request.get_json(forceTrue) if not data or player not in data: return {error: player required}, 400 player data[player].upper() if player not in players: return {error: unknown player}, 404 players[player][score] 1 socketio.emit(score_update, players) return {ok: True, players: players} socketio.on(connect) def on_connect(): emit(score_update, players) if __name__ __main__: socketio.run(app, host127.0.0.1, port5000, debugFalse)这里监听的是127.0.0.1只允许本机访问。OBS 浏览器源也在本机所以够用。如果你需要从另一台电脑投票可以把host改成0.0.0.0但建议放在受信的内网环境里不要暴露到公网。创建模板static/scoreboard.html!DOCTYPE html html langzh-CN head meta charsetUTF-8 script srchttps://cdn.socket.io/4.6.1/socket.io.min.js/script /head body div idboard等待数据.../div script const socket io(); socket.on(score_update, function(data) { document.getElementById(board).innerText JSON.stringify(data); }); /script /body /html然后在项目根目录建一个templates目录把scoreboard.html放进去否则 Flask 的render_template找不到文件。mkdir templates mv static/scoreboard.html templates/scoreboard.html启动服务python score_server.py正常会看到WebSocket server running类似的日志。先不要急着接 OBS用浏览器打开http://127.0.0.1:5000/scoreboard确认页面能显示 JSON。如果页面显示空白优先检查开发者工具里的网络请求和 WebSocket 连接是否成功。4.3 接成 OBS 浏览器源在 OBS 中新建一个场景然后添加“浏览器”源URLhttp://127.0.0.1:5000/scoreboard宽度建议按计分板的实际尺寸设置高度同上刷新浏览器默认不自动刷新保留即可浏览器源加入到 OBS 后它会持续连接 WebSocket。计分数据变化时页面内容自动更新。4.4 验证计分是否生效打开另一个终端用 curl 模拟投票curl -X POST http://127.0.0.1:5000/vote \ -H Content-Type: application/json \ -d {player: A}响应会返回一个 JSON{ ok: true, players: { A: {name: 选手A, score: 1, alive: true}, B: {name: 选手B, score: 0, alive: true} } }此时回 OBS 看浏览器源里的数字如果从 0 变成 1说明整个链路已经通了HTTP 投票接口 - SocketIO 推送 - 浏览器源渲染。这是整套系统中最基础、也最值得先跑通的一个环节。5. 多路选手流接入与自动切换8 进 4 淘汰赛意味着至少有 8 个参赛对象。如果提前把 8 段素材准备好直播时切换起来会轻松很多。5.1 素材统一转码不同手机、不同软件录出来的视频编码和分辨率差异很大直接拖进 OBS 可能导致卡顿或声画不同步。建议先统一转成 H.264 AAC分辨率固定为 1280x720 或 1920x1080。for f in ./raw/*.mp4; do ffmpeg -i $f \ -vf scale1280:720:force_original_aspect_ratiodecrease,pad1280:720:(ow-iw)/2:(oh-ih)/2 \ -c:v libx264 -preset veryfast -crf 23 \ -c:a aac -ar 44100 -ac 2 \ ./clips/$(basename $f) done这段命令会把raw目录下所有mp4转成统一尺寸并居中黑边。如果你对画质要求更高可以把crf降到 18。批量转码时建议先拿一个文件测试确认输出没问题再跑全量。5.2 视频源接入方式进入正式直播时可以使用 8 个“媒体源”分别指向clips目录里的文件然后通过 OBS 场景切换来控制显示哪个选手。这种方式最稳定因为素材文件是已经转好的解码压力比实时摄像头或窗口捕获更小。每个媒体源可以设置“显示暂停”或“未源可见时暂停”这样不会在后台持续空转。推荐的做法一个选手对应一个场景。每个场景里只放该选手的媒体源和对应的计分信息。主控场景负责串场和全局布局。5.3 使用 WebSocket 控制切换OBS 新版内置 obs-websocket但需要手动开启。打开 OBS 设置 - 脚本/WebSocket 服务器设置启用后设置一个端口和密码。之后可以用 Python 脚本远程切换场景。先安装依赖pip install obs-websocket-py示例代码import obsws_python as obs ws obs.ReqClient(host127.0.0.1, port4455, passwordyour_password) # 切到选手A场景 ws.set_current_program_scene(场景-选手A) # 切到选手B场景 ws.set_current_program_scene(场景-选手B)注意不同版本的 obs-websocket-py 可能在方法名上有细微差别以你安装的版本文档为准。但思路是一致的就是通过本地 WebSocket 遥控 OBS 场景。这样弹幕投票、导播按钮、网页控制点都可以触发同一个“切换场景”动作。5.4 批量生成对阵表8 进 4 的赛程最好用脚本生成而不是手写。手写容易漏人也容易在直播时看不清。import json players [选手A, 选手B, 选手C, 选手D, 选手E, 选手F, 选手G, 选手H] matchups [(players[i], players[i 1]) for i in range(0, len(players), 2)] schedule { round: 8进4, matchups: [{left: a, right: b} for a, b in matchups] } with open(schedule.json, w, encodingutf-8) as f: json.dump(schedule, f, ensure_asciiFalse, indent2)生成的schedule.json可以直接给计分面板用也可以转成 OBS 里的文本源。这样只要改一次选手名单赛程和展示信息同步更新。6. 接口 API 与批量任务整套方案里最有价值的部分是把“人工操作”变成“接口调用”。下面集中讲接口和批量。6.1 弹幕投票接口设计前面已经写了一个/vote接口。实际使用中可以加两个保护逻辑同一个来源在短时间内不能重复投票。每位选手的得分变化需要记录到本地日志方便赛后复核。完整一点的接口设计可以这样接口作用请求方式/scoreboard返回计分板页面GET/vote为选手投票POST JSON/reset本轮分数清零POST JSON/state获取当前所有选手状态GET/vote请求参数示例{ player: A, source: danmaku_12345, token: local-test }服务端收到后可以对source做去重防止一个人狂刷。直播连麦场景下弹幕并不是真正的实时所以如果要做“观众投票决定淘汰”建议提前说明统计时间窗口比如“每轮投票只开放 30 秒”避免开播时间不一致导致争议。6.2 批量任务脚本淘汰赛的准备工作大多可以写成脚本。除了批量转码还可以批量生成选手预览图ffmpeg -i ./clips/playerA.mp4 -ss 1 -frames:v 1 -q:v 2 ./preview/playerA.jpg写成一个 Python 脚本遍历所有选手文件import subprocess from pathlib import Path clips_dir Path(./clips) preview_dir Path(./preview) preview_dir.mkdir(exist_okTrue) for clip in clips_dir.glob(*.mp4): out_file preview_dir / (clip.stem .jpg) cmd [ ffmpeg, -y, -i, str(clip), -ss, 1, -frames:v, 1, -q:v, 2, str(out_file) ] subprocess.run(cmd, checkTrue) print(out_file)这类脚本可以放在开播前跑节省大量手动截图时间。还可以继续扩展成“生成字幕”“生成片头文字”“统一添加角标”等批量任务。只要流程固定就能脚本化。6.3 接入平台弹幕的注意事项如果要把 B 站弹幕直接接进投票服务需要申请开放平台权限并且严格按照官方文档接入。本地测试时不要直接挂生产弹幕可以先写一个模拟来源curl -X POST http://127.0.0.1:5000/vote \ -H Content-Type: application/json \ -d {player: B, source: danmaku_test_001}平台弹幕是有延迟的具体延迟取决于观众到平台再转发的链路。这个不是本地服务能压下去的。如果你的节目要“实时互动”建议把投票窗口稍微拉长并且提前说明统计规则。7. 资源占用与性能观察7.1 本机资源占用这里的计分服务非常轻。一个 Flask SocketIO 服务在没有高并发的情况下占用可以忽略不计。真正吃资源的是 OBS 里的浏览器源和媒体源。OBS 中每添加一个浏览器源就可能额外启动一个 Chromium 渲染进程。如果你在 OBS 里放了三四个浏览器源内存增加可能从几百 MB 到 1GB 以上。具体数字和网页复杂度有关需要在本机任务管理器里观察。媒体源方面clips里的视频如果统一转成 720p H.264解码压力会小很多。如果原始素材是 4K 高码率视频哪怕只是播放也会明显拖慢系统。所以批量转码不是可选项而是正式开播前的必要准备。7.2 延迟观察浏览器源通过 WebSocket 接收计分数据本地网络下延迟通常很低。从 curl 发投票到 OBS 页面数字变化可以按“秒级”内刷新来衡量。观众看到的弹幕延迟来自平台链路不是本地服务能控制的。OBS 推流到平台本身也有几秒延迟。做测试时可以在 OBS 里放一个“本地时间码”用来确认实际推送延迟。7.3 降载策略如果开播后 OBS 帧率不稳优先做三件事降低媒体源分辨率统一为 1280x720。少放浏览器源尽量把一个页面内完成计分和状态展示。开启硬件编码。NVIDIA 显卡选择 NVENC H.264AMD 显卡选择 AMFIntel 核显选择 QSV。查看编码器占用Windows 可以看任务管理器里的 GPU Video Encode 和 GPU Video DecodeLinux 可以用nvidia-smi观察显存占用只是其中一项更关键的是 Video Encode 利用率。如果编码利用率接近 100%就得降码率或者关掉多余的插件。8. 常见问题与排查方法问题现象可能原因排查方式解决方案OBS 浏览器源白屏本地服务未启动 / 地址错误 / CORS 阻断用浏览器直接访问http://127.0.0.1:5000/scoreboard确认服务启动检查端口将 Flask-SocketIO 的cors_allowed_origins设置为*投票接口返回 404路径写错 / 大小写不一致检查路由定义和请求路径使用一致的/vote确认 POST 请求体是 JSON计分服务启动失败端口被占用或依赖缺失查看终端报错检查pip list换端口如 5001重新安装依赖OBS 切换场景失败obs-websocket 未启用或密码错误在 OBS 设置里确认 WebSocket 状态重新设置端口和密码脚本里使用对应的 host 和 password多路视频卡顿素材分辨率过高 / 编码不统一查看任务管理器中的 GPU 解码占用用 FFmpeg 批量转成 720p H.264降低媒体源数量画音不同步原始文件帧率不一致 / 播放暂停逻辑设置不对先单独播放素材观察是否同步转码时统一-r 30或-fps_mode cfr并在媒体源中取消暂停推流断流上行带宽不足 / 网络波动查看 OBS 日志和码率曲线降低码率到 4500 Kbps备用推流地址弹幕投票刷票没有去重逻辑检查日志中同一source出现次数服务端增加短时间窗口去重和 token 校验批量任务中途崩溃某个文件损坏或编码器不支持单独跑该文件的 FFmpeg 命令查看错误码更换源文件或跳过该文件遇到问题时先看日志再看端口再看网络。不要一上来就重装 OBS。本地小系统的排错顺序一般是服务是否启动 - 页面是否能访问 - 接口返回什么 - OBS 拉取的是不是同一地址。9. 最佳实践与使用建议第一第一次用的时候先小参数测试。不要等到 8 进 4 直播当天才完整跑一遍。提前花半个小时做一次“1 进 1”模拟赛确认计分、切换、推流都正常再放真实名单。第二保留一套最小可运行配置。把已经调好的score_server.py、scoreboard.html、OB场景集合打包备份。下次再做类似的综艺、赛事直接复制一份改一改选手名字就能用。第三目录要严格区分。原始素材、转码素材、预览图、输出文件不要混在一起。批量脚本按目录扫描时混在一起会很容易把旧文件也带上。第四批量任务要加日志。无论是转码还是生成预览图每个文件处理完都打印一行状态。如果一批 100 个文件有 3 个失败你能直接看到而不是等到直播时才发现。第五接口和本地服务要注意访问权限。监听127.0.0.1是默认安全做法。如果需要多人投票设置简单的 token 或只在内网开放。不要把这个服务直接暴露到公网否则容易被刷接口。第六素材授权和肖像权问题必须前置。8 进 4 综艺里会有选手照片、视频、声音、二创剪辑一定要确认来源和授权。涉及“寄生体”“内卷”这类可能包含二次创作的题材更要在活动说明里写清楚素材使用范围。现场直播前还要确认背景音乐是否有版权避免平台断流或侵权风险。第七重要结果要人工复核。脚本可以自动计票、自动切换但淘汰选手这类关键决定最好有一名人工确认。技术辅助可以提升效率但不能替代人对结果的判断。10. 总结与下一步这套直播赛事系统最值得尝试的点是把“手动改字、手动切换、手动转码”变成“接口调用、脚本执行、WebSocket 推送”。最应该先验证的是计分面板能不能在 OBS 里正常显示并且用 curl 模拟投票后数字会跳。这个链路跑通之后后面的多路素材切换和批量任务都是在水磨工夫。最容易踩的坑有两个一是浏览器源和媒体源同时开太多导致 OBS 帧率不稳二是弹幕投票没有做去重结果被刷票刷乱。先控制素材码率再限制投票来源基本能避免大多数问题。后续可以继续扩展的方向包括接弹幕平台真实投票、用数据库保存历史赛果、加一个简单的导播控制页面、把转码和预览图生成做成开机自动执行。这套思路跑顺之后8 进 4 也好16 进 8 也好其实都只是在名单文件里多写几行数据而已。
从零搭建直播互动赛事系统：OBS多路视频源与弹幕投票实战指南
这次我们来看一个直播场景的硬需求多选手淘汰赛直播。标题是《爱jigTV 新版本寄生体内卷大乱斗8进4淘汰赛》这种节目如果只靠一个主摄像推流很容易变成灾难多路视频源来回切、计分板更新靠手动、弹幕互动跟不上节奏、赛前素材堆积成山。真正能稳定跑下来的背后通常是一套“直播互动赛事系统”。先说明一点这不是某个能直接下载的软件而是一套可以自己搭建的技术方案。文章内容会围绕四个核心需求展开多路视频源接入、实时计分与弹幕投票、接口化控制、批量素材处理。下面会给出可复用的代码、命令和资源占用观察方法。就算你的节目不是“寄生体内卷大乱斗”而是一个普通的 8 进 4 比赛、K 歌淘汰赛、连麦闯关直播这套思路也一样能用。这套方案的核心不是堆显卡也不依赖大模型。计分服务、浏览器源、批量转码脚本都不需要很高的配置真正的瓶颈通常在视频解码和推流编码。所以我会从简单的本地计分面板开始再逐步接到 OBS最后把批量任务和接口控制连起来。整个过程不需要专业导播台一台能跑 OBS 的电脑就可以完成。1. 核心能力速览能力项说明直播结构主控 OBS 本地计分 Web 服务 多路视频源核心功能弹幕投票、实时计分、批量转码、对阵表生成、低延迟状态推送运行平台Windows / macOS / Linux 均可OBS 负责推流推荐硬件4 核以上 CPU、16GB 内存带 NVENC 的 N 卡或核显编码更稳软件依赖OBS Studio、Python 3.9、FFmpeg、flask-socketio、obs-websocket 插件接口能力提供 HTTP 投票接口、WebSocket 状态推送、OBS 远程切换场景批量任务支持批量转码、批量生成赛程 JSON、批量生成预览图上手难度中等需要会改少量 Python 代码和 HTML应用场景电竞淘汰赛、综艺娱乐赛、K 歌大赛、答题闯关直播等合规边界素材、人脸、音乐、直播素材需确认授权本地服务不要公网裸奔从这个表能看出来它不是一个大模型项目而是一套“直播自动化”方案。核心优势是廉价、可控、能接接口。直播过程中主持人只需要关注节奏计分和切换可以由脚本或副控完成。2. 适用场景与使用边界这类方案适合谁如果你的直播内容经常有“多名选手依次出场”“观众投票影响结果”“赛程紧凑需要不停切换画面”这些情况那就很值得搭一套。比如街舞比赛、翻唱比赛、游戏 8 进 4、答题闯关、选秀综艺甚至晚会抽奖本质都是同一个逻辑多个来源 实时状态 切换展示。把这套逻辑抽出来做成系统比每次直播手动改文本和切换画面要可靠得多。它能解决的问题也很明确多路视频源不用反复拖放文件到 OBS而是提前批量转化好。计分板不只是显示数字还能收到投票请求后自动更新。弹幕、网页、遥控器、第二机位都可以通过 HTTP 或 WebSocket 触发场景切换。赛前素材准备从“手动改几十条文件名”变成“跑一遍脚本”。同时也要说清楚边界。这套方案不适合广电级正式节目因为 OBS 本身的稳定性依赖操作系统和网络没有专业导播台那种物理切换容错。也不适合需要多人协同编辑的高安全场景我建议把权限收敛在本地。另外凡是涉及选手肖像、音乐素材、视频片段、直播间画面都必须确认授权。特别是“寄生体内卷大乱斗”这类娱乐企划很可能包含二创、剪辑、配音素材用之前一定要把来源理清楚。技术上的边界也要注意弹幕平台通常有延迟不是本地 WebSocket 能解决的。投票工具适合做参考、互动和现场辅助如果涉及奖金、赛事结果需要加人工复核流程不能完全让脚本决定。3. 环境准备与前置条件3.1 硬件与带宽先给一套通用配置建议CPU4 核以上尽量选 6 核或更高。内存16GB 起步。OBS 打开一个浏览器源就会多开一个 Chromium 进程用的内存不小。显卡NVIDIA 显卡优先开启 NVENC 硬件编码后可以显著降低 OBS 的 CPU 占用。上行带宽至少 8 Mbps 到 10 Mbps。B 站推流常见码率是 6000 Kbps如果同时还要上传素材带宽需要预留更多。存储按“原始素材 转码素材 录播文件”分目录建议预留 50GB 以上空间。3.2 软件清单OBS Studio负责视频合成和推流。FFmpeg负责批量转码、裁剪、截图。Python 3.9运行投票服务和计分服务。Node.js 可选如果后续要写更复杂的 WebSocket 网关。obs-websocket 插件新版 OBS 已内置旧版需要单独安装用于远程切换场景。3.3 推荐目录结构live-event/ ├── raw/ # 原始素材不轻易改动 ├── clips/ # 统一转码后的片段 ├── preview/ # 预览图 ├── output/ # 录播或最终文件 ├── schedule.json # 赛程/对阵表 ├── score_server.py # 计分投票服务 └── static/ └── scoreboard.html # 计分板页面这个结构可以避免直播时到处找文件。所有素材、脚本、结果都按固定目录放后续写批量任务也更方便。4. 弹幕投票与计分面板搭建先做一个最小的“本地计分面板”。它不推流只负责接收投票、累计分数并通过 WebSocket 推送给 OBS 浏览器源。4.1 项目结构与依赖mkdir -p live-event/static cd live-event python -m venv venv source venv/bin/activate # Windows 使用 venv\Scripts\activate pip install flask flask-socketio eventlet服务端使用 Flask Flask-SocketIO前端使用 SocketIO 客户端。这个方案在本地跑很稳不需要额外数据库数据放内存里即可。4.2 启动计分服务创建score_server.pyfrom flask import Flask, render_template, request from flask_socketio import SocketIO, emit app Flask(__name__) app.config[SECRET_KEY] live-score socketio SocketIO(app, cors_allowed_origins*) players { A: {name: 选手A, score: 0, alive: True}, B: {name: 选手B, score: 0, alive: True}, } app.route(/) def index(): return {status: live-scoreboard} app.route(/scoreboard) def scoreboard(): return render_template(scoreboard.html) app.route(/vote, methods[POST]) def vote(): data request.get_json(forceTrue) if not data or player not in data: return {error: player required}, 400 player data[player].upper() if player not in players: return {error: unknown player}, 404 players[player][score] 1 socketio.emit(score_update, players) return {ok: True, players: players} socketio.on(connect) def on_connect(): emit(score_update, players) if __name__ __main__: socketio.run(app, host127.0.0.1, port5000, debugFalse)这里监听的是127.0.0.1只允许本机访问。OBS 浏览器源也在本机所以够用。如果你需要从另一台电脑投票可以把host改成0.0.0.0但建议放在受信的内网环境里不要暴露到公网。创建模板static/scoreboard.html!DOCTYPE html html langzh-CN head meta charsetUTF-8 script srchttps://cdn.socket.io/4.6.1/socket.io.min.js/script /head body div idboard等待数据.../div script const socket io(); socket.on(score_update, function(data) { document.getElementById(board).innerText JSON.stringify(data); }); /script /body /html然后在项目根目录建一个templates目录把scoreboard.html放进去否则 Flask 的render_template找不到文件。mkdir templates mv static/scoreboard.html templates/scoreboard.html启动服务python score_server.py正常会看到WebSocket server running类似的日志。先不要急着接 OBS用浏览器打开http://127.0.0.1:5000/scoreboard确认页面能显示 JSON。如果页面显示空白优先检查开发者工具里的网络请求和 WebSocket 连接是否成功。4.3 接成 OBS 浏览器源在 OBS 中新建一个场景然后添加“浏览器”源URLhttp://127.0.0.1:5000/scoreboard宽度建议按计分板的实际尺寸设置高度同上刷新浏览器默认不自动刷新保留即可浏览器源加入到 OBS 后它会持续连接 WebSocket。计分数据变化时页面内容自动更新。4.4 验证计分是否生效打开另一个终端用 curl 模拟投票curl -X POST http://127.0.0.1:5000/vote \ -H Content-Type: application/json \ -d {player: A}响应会返回一个 JSON{ ok: true, players: { A: {name: 选手A, score: 1, alive: true}, B: {name: 选手B, score: 0, alive: true} } }此时回 OBS 看浏览器源里的数字如果从 0 变成 1说明整个链路已经通了HTTP 投票接口 - SocketIO 推送 - 浏览器源渲染。这是整套系统中最基础、也最值得先跑通的一个环节。5. 多路选手流接入与自动切换8 进 4 淘汰赛意味着至少有 8 个参赛对象。如果提前把 8 段素材准备好直播时切换起来会轻松很多。5.1 素材统一转码不同手机、不同软件录出来的视频编码和分辨率差异很大直接拖进 OBS 可能导致卡顿或声画不同步。建议先统一转成 H.264 AAC分辨率固定为 1280x720 或 1920x1080。for f in ./raw/*.mp4; do ffmpeg -i $f \ -vf scale1280:720:force_original_aspect_ratiodecrease,pad1280:720:(ow-iw)/2:(oh-ih)/2 \ -c:v libx264 -preset veryfast -crf 23 \ -c:a aac -ar 44100 -ac 2 \ ./clips/$(basename $f) done这段命令会把raw目录下所有mp4转成统一尺寸并居中黑边。如果你对画质要求更高可以把crf降到 18。批量转码时建议先拿一个文件测试确认输出没问题再跑全量。5.2 视频源接入方式进入正式直播时可以使用 8 个“媒体源”分别指向clips目录里的文件然后通过 OBS 场景切换来控制显示哪个选手。这种方式最稳定因为素材文件是已经转好的解码压力比实时摄像头或窗口捕获更小。每个媒体源可以设置“显示暂停”或“未源可见时暂停”这样不会在后台持续空转。推荐的做法一个选手对应一个场景。每个场景里只放该选手的媒体源和对应的计分信息。主控场景负责串场和全局布局。5.3 使用 WebSocket 控制切换OBS 新版内置 obs-websocket但需要手动开启。打开 OBS 设置 - 脚本/WebSocket 服务器设置启用后设置一个端口和密码。之后可以用 Python 脚本远程切换场景。先安装依赖pip install obs-websocket-py示例代码import obsws_python as obs ws obs.ReqClient(host127.0.0.1, port4455, passwordyour_password) # 切到选手A场景 ws.set_current_program_scene(场景-选手A) # 切到选手B场景 ws.set_current_program_scene(场景-选手B)注意不同版本的 obs-websocket-py 可能在方法名上有细微差别以你安装的版本文档为准。但思路是一致的就是通过本地 WebSocket 遥控 OBS 场景。这样弹幕投票、导播按钮、网页控制点都可以触发同一个“切换场景”动作。5.4 批量生成对阵表8 进 4 的赛程最好用脚本生成而不是手写。手写容易漏人也容易在直播时看不清。import json players [选手A, 选手B, 选手C, 选手D, 选手E, 选手F, 选手G, 选手H] matchups [(players[i], players[i 1]) for i in range(0, len(players), 2)] schedule { round: 8进4, matchups: [{left: a, right: b} for a, b in matchups] } with open(schedule.json, w, encodingutf-8) as f: json.dump(schedule, f, ensure_asciiFalse, indent2)生成的schedule.json可以直接给计分面板用也可以转成 OBS 里的文本源。这样只要改一次选手名单赛程和展示信息同步更新。6. 接口 API 与批量任务整套方案里最有价值的部分是把“人工操作”变成“接口调用”。下面集中讲接口和批量。6.1 弹幕投票接口设计前面已经写了一个/vote接口。实际使用中可以加两个保护逻辑同一个来源在短时间内不能重复投票。每位选手的得分变化需要记录到本地日志方便赛后复核。完整一点的接口设计可以这样接口作用请求方式/scoreboard返回计分板页面GET/vote为选手投票POST JSON/reset本轮分数清零POST JSON/state获取当前所有选手状态GET/vote请求参数示例{ player: A, source: danmaku_12345, token: local-test }服务端收到后可以对source做去重防止一个人狂刷。直播连麦场景下弹幕并不是真正的实时所以如果要做“观众投票决定淘汰”建议提前说明统计时间窗口比如“每轮投票只开放 30 秒”避免开播时间不一致导致争议。6.2 批量任务脚本淘汰赛的准备工作大多可以写成脚本。除了批量转码还可以批量生成选手预览图ffmpeg -i ./clips/playerA.mp4 -ss 1 -frames:v 1 -q:v 2 ./preview/playerA.jpg写成一个 Python 脚本遍历所有选手文件import subprocess from pathlib import Path clips_dir Path(./clips) preview_dir Path(./preview) preview_dir.mkdir(exist_okTrue) for clip in clips_dir.glob(*.mp4): out_file preview_dir / (clip.stem .jpg) cmd [ ffmpeg, -y, -i, str(clip), -ss, 1, -frames:v, 1, -q:v, 2, str(out_file) ] subprocess.run(cmd, checkTrue) print(out_file)这类脚本可以放在开播前跑节省大量手动截图时间。还可以继续扩展成“生成字幕”“生成片头文字”“统一添加角标”等批量任务。只要流程固定就能脚本化。6.3 接入平台弹幕的注意事项如果要把 B 站弹幕直接接进投票服务需要申请开放平台权限并且严格按照官方文档接入。本地测试时不要直接挂生产弹幕可以先写一个模拟来源curl -X POST http://127.0.0.1:5000/vote \ -H Content-Type: application/json \ -d {player: B, source: danmaku_test_001}平台弹幕是有延迟的具体延迟取决于观众到平台再转发的链路。这个不是本地服务能压下去的。如果你的节目要“实时互动”建议把投票窗口稍微拉长并且提前说明统计规则。7. 资源占用与性能观察7.1 本机资源占用这里的计分服务非常轻。一个 Flask SocketIO 服务在没有高并发的情况下占用可以忽略不计。真正吃资源的是 OBS 里的浏览器源和媒体源。OBS 中每添加一个浏览器源就可能额外启动一个 Chromium 渲染进程。如果你在 OBS 里放了三四个浏览器源内存增加可能从几百 MB 到 1GB 以上。具体数字和网页复杂度有关需要在本机任务管理器里观察。媒体源方面clips里的视频如果统一转成 720p H.264解码压力会小很多。如果原始素材是 4K 高码率视频哪怕只是播放也会明显拖慢系统。所以批量转码不是可选项而是正式开播前的必要准备。7.2 延迟观察浏览器源通过 WebSocket 接收计分数据本地网络下延迟通常很低。从 curl 发投票到 OBS 页面数字变化可以按“秒级”内刷新来衡量。观众看到的弹幕延迟来自平台链路不是本地服务能控制的。OBS 推流到平台本身也有几秒延迟。做测试时可以在 OBS 里放一个“本地时间码”用来确认实际推送延迟。7.3 降载策略如果开播后 OBS 帧率不稳优先做三件事降低媒体源分辨率统一为 1280x720。少放浏览器源尽量把一个页面内完成计分和状态展示。开启硬件编码。NVIDIA 显卡选择 NVENC H.264AMD 显卡选择 AMFIntel 核显选择 QSV。查看编码器占用Windows 可以看任务管理器里的 GPU Video Encode 和 GPU Video DecodeLinux 可以用nvidia-smi观察显存占用只是其中一项更关键的是 Video Encode 利用率。如果编码利用率接近 100%就得降码率或者关掉多余的插件。8. 常见问题与排查方法问题现象可能原因排查方式解决方案OBS 浏览器源白屏本地服务未启动 / 地址错误 / CORS 阻断用浏览器直接访问http://127.0.0.1:5000/scoreboard确认服务启动检查端口将 Flask-SocketIO 的cors_allowed_origins设置为*投票接口返回 404路径写错 / 大小写不一致检查路由定义和请求路径使用一致的/vote确认 POST 请求体是 JSON计分服务启动失败端口被占用或依赖缺失查看终端报错检查pip list换端口如 5001重新安装依赖OBS 切换场景失败obs-websocket 未启用或密码错误在 OBS 设置里确认 WebSocket 状态重新设置端口和密码脚本里使用对应的 host 和 password多路视频卡顿素材分辨率过高 / 编码不统一查看任务管理器中的 GPU 解码占用用 FFmpeg 批量转成 720p H.264降低媒体源数量画音不同步原始文件帧率不一致 / 播放暂停逻辑设置不对先单独播放素材观察是否同步转码时统一-r 30或-fps_mode cfr并在媒体源中取消暂停推流断流上行带宽不足 / 网络波动查看 OBS 日志和码率曲线降低码率到 4500 Kbps备用推流地址弹幕投票刷票没有去重逻辑检查日志中同一source出现次数服务端增加短时间窗口去重和 token 校验批量任务中途崩溃某个文件损坏或编码器不支持单独跑该文件的 FFmpeg 命令查看错误码更换源文件或跳过该文件遇到问题时先看日志再看端口再看网络。不要一上来就重装 OBS。本地小系统的排错顺序一般是服务是否启动 - 页面是否能访问 - 接口返回什么 - OBS 拉取的是不是同一地址。9. 最佳实践与使用建议第一第一次用的时候先小参数测试。不要等到 8 进 4 直播当天才完整跑一遍。提前花半个小时做一次“1 进 1”模拟赛确认计分、切换、推流都正常再放真实名单。第二保留一套最小可运行配置。把已经调好的score_server.py、scoreboard.html、OB场景集合打包备份。下次再做类似的综艺、赛事直接复制一份改一改选手名字就能用。第三目录要严格区分。原始素材、转码素材、预览图、输出文件不要混在一起。批量脚本按目录扫描时混在一起会很容易把旧文件也带上。第四批量任务要加日志。无论是转码还是生成预览图每个文件处理完都打印一行状态。如果一批 100 个文件有 3 个失败你能直接看到而不是等到直播时才发现。第五接口和本地服务要注意访问权限。监听127.0.0.1是默认安全做法。如果需要多人投票设置简单的 token 或只在内网开放。不要把这个服务直接暴露到公网否则容易被刷接口。第六素材授权和肖像权问题必须前置。8 进 4 综艺里会有选手照片、视频、声音、二创剪辑一定要确认来源和授权。涉及“寄生体”“内卷”这类可能包含二次创作的题材更要在活动说明里写清楚素材使用范围。现场直播前还要确认背景音乐是否有版权避免平台断流或侵权风险。第七重要结果要人工复核。脚本可以自动计票、自动切换但淘汰选手这类关键决定最好有一名人工确认。技术辅助可以提升效率但不能替代人对结果的判断。10. 总结与下一步这套直播赛事系统最值得尝试的点是把“手动改字、手动切换、手动转码”变成“接口调用、脚本执行、WebSocket 推送”。最应该先验证的是计分面板能不能在 OBS 里正常显示并且用 curl 模拟投票后数字会跳。这个链路跑通之后后面的多路素材切换和批量任务都是在水磨工夫。最容易踩的坑有两个一是浏览器源和媒体源同时开太多导致 OBS 帧率不稳二是弹幕投票没有做去重结果被刷票刷乱。先控制素材码率再限制投票来源基本能避免大多数问题。后续可以继续扩展的方向包括接弹幕平台真实投票、用数据库保存历史赛果、加一个简单的导播控制页面、把转码和预览图生成做成开机自动执行。这套思路跑顺之后8 进 4 也好16 进 8 也好其实都只是在名单文件里多写几行数据而已。 
