简介EasyDSS-windows-2.2.7-1912281435.zip 面向需要在 Windows 环境快速部署流媒体服务的开发者、运维人员及视频应用搭建者提供一套可本地安装运行的视频管理与分发工具可用于直播推流、视频转码、回放、嵌入分享及多屏播放等场景。压缩包共收录 207 个文件约 55.93MB内容以 js 前端脚本、lua 业务脚本、dll 与 so 依赖库、css/html 页面资源及 exe 安装程序为主并附带 conf 配置、pem 证书、pdf 文档与字体图标等配套文件基本覆盖运行所需组件。已有 708 人学习或下载说明该版本在 Windows 部署实践中具有一定参考价值。读者可借此了解 EasyDSS 的目录组织、前后端资源构成与依赖关系并用于搭建测试环境、验证直播与回放流程、排查部署依赖问题也可作为二次开发和接口联调的样本。1. EasyDSS Windows 2.2.7 拆包一个视频管理安装包到底管哪几件事EasyDSS-windows-2.2.7-1912281435.zip这个文件名信息量其实不小windows说明是 Windows 平台打包2.2.7是版本号后面那串1912281435是构建时间戳按yymmddHHMM读就是 2019 年 12 月 28 日 14:35。它不是一个播放器也不是一个转码工具而是一套跑在 Windows 上的视频管理服务端安装包设备或推流端把 RTMP 流推进来服务端负责接入、转封装、切片、录像、回放和分发对外吐出 HLS 与 HTTP-FLV 这类浏览器和播放器都能直接吃的流。适合谁用手里有一批网络摄像机、想在局域网或内网做一套直播加录像回看、又不想从零写流媒体服务的人。下面按我拆包和跑通的顺序写从解压、起服务、推拉流验证一路写到磁盘和排查。2. 解压到首次启动目录结构、端口占用与三个探活动作拿到安装包第一件事不是双击而是先看它解出来长什么样。这一步看着琐碎实际决定了后面出问题能不能定位——流媒体服务端的故障有大半是路径、端口、权限这三件事而这三件事在解压那一刻就定型了。2.1 解压后的目录里哪些能动、哪些别碰我一般先把 zip 解到一个纯英文、无空格、层级浅的路径比如D:\dss\easydss。中文路径和带空格的路径在 Windows 上是老生常谈但对这类服务端程序尤其致命配置文件里写的是相对路径程序内部再拼接一次绝对路径中间只要有一次编码没处理好录像目录就写不进去现象是能推流、能看直播、就是没有录像文件查半天查不到原因。解压之后目录大致是这么几类具体名称以你手上这版为准但角色分工基本固定目录/文件作用能不能动主程序 exe服务入口双击或命令行启动别改名改名后快捷方式和脚本全失效conf/config一类端口、录像路径、切片参数都在这能动改前先备份一份logs运行日志排障第一现场别删出问题全靠它www/web一类管理页面静态资源别动动了页面打不开record/data一类录像与索引落盘位置能动建议改到大容量盘运行时依赖 dll编解码、网络库别动缺一个就闪退提示解压完先整目录复制一份做冷备份。这类服务端的配置文件往往被程序回写改崩了没有后悔药一份原始副本能省掉重新找包的麻烦。配置文件我一般先全文扫一遍重点盯四个值HTTP 监听端口、RTMP 监听端口、录像根目录、日志级别。日志级别默认往往是 info第一次跑通之前可以临时调到 debug跑通后调回去否则日志涨得比录像还快。2.2 启动前先把 1935 和 HTTP 端口占没占查清楚Windows 上最常见的启动失败原因不是程序坏了是端口被别的进程占了。RTMP 的通用端口是 1935HTTP 一般是 8080 段或者 80具体以配置文件为准。启动前用 PowerShell 查一遍# 查 RTMP 常用端口 1935 和 HTTP 端口是否已被监听 netstat -ano | findstr :1935 netstat -ano | findstr :8080 # 如果有输出拿到最后一列的 PID反查是哪个进程 Get-Process -Id 上一步查到的PID | Select-Object Id, ProcessName, Path这段的逻辑很直白netstat -ano列出所有监听端口和对应 PIDfindstr过滤出你关心的两个端口第二段用 PID 反查进程名和可执行文件路径。参数说明-a显示所有连接和监听-n用数字显示地址和端口不做 DNS 反解快-o显示所属进程 PID。如果 1935 被占要么停掉占用方要么改配置里的 RTMP 端口——但改端口意味着后面所有推流地址都得跟着改团队里其他人手上的推流工具也要同步这个成本要提前算。端口空着接着确认防火墙。Windows Defender 防火墙默认拦入站本机推流拉流不受影响但局域网里其他机器推不进来。加规则的命令# 放行 RTMP 与 HTTP 入站仅限内网使用时建议加上 -Profile Private netsh advfirewall firewall add rule namedss-rtmp dirin actionallow protocolTCP localport1935 netsh advfirewall firewall add rule namedss-http dirin actionallow protocolTCP localport8080 # 确认规则已生效 netsh advfirewall firewall show rule namedss-rtmpdirin表示入站actionallow放行protocolTCP和localport指定端口。生产环境别图省事直接关防火墙那等于把整台机器的所有端口都敞开出事之后连排查范围都收不回来。2.3 服务起来没有进程、端口、页面三层探活启动之后别急着开播放器按三层顺序确认出错时能立刻知道断在哪一层。第一层进程还在不在。有些版本双击后窗口一闪就没了说明启动阶段就挂了通常是缺运行库或者配置解析失败。用命令行启动能看到报错输出# 切到安装目录用命令行启动把标准输出和错误都留在窗口里 cd D:\dss\easydss .\EasyDSS.exe # 另开一个窗口确认进程还在 Get-Process | Where-Object { $_.ProcessName -like *dss* } | Select-Object Id, ProcessName, StartTime命令行启动和双击启动的差别在于前者把 stderr 留在控制台里。闪退类问题九成能在这一屏输出里看到线索比如找不到 xxx.dll、端口绑定失败、配置文件第 N 行解析错误。第二层端口有没有真的监听上。进程活着但端口没起说明服务初始化到一半卡住了# 只显示处于 Listen 状态的 TCP 连接确认 1935 和 HTTP 端口在列 Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -in 1935, 8080 } | Select-Object LocalAddress, LocalPort, OwningProcess注意LocalAddress这一列如果是0.0.0.0或::说明对外监听局域网能连如果只有127.0.0.1那只有本机能访问别的机器推不进来——这个差别在本机测试一切正常、同事那边连不上的场景里非常典型。第三层管理页面能不能打开。浏览器访问http://127.0.0.1:8080端口按你的配置能出登录页说明 HTTP 服务、静态资源、后端接口这条链路是通的。页面转圈但不出内容多半是前端资源路径不对或者后端接口 500这时候去翻logs目录下当天的日志找第一个 ERROR 而不是最后一个第一个才是根因。三层都过了再进下一步的推拉流。顺序反了的话推流失败你根本分不清是推流端的问题还是服务端没起来白白多花一小时。3. RTMP 进、HLS 出的链路用 ffmpeg 造一路测试流把推拉跑通服务起起来只是空壳真正的验证要有一条完整的流从进到出。这一章用 ffmpeg 造一路可控的测试流把推流地址、拉流地址、延迟量级这三件事一次讲透后面接真实摄像机就是换个地址的事。3.1 推流地址怎么拼端口、app 名与流名RTMP 推流地址的通用结构是rtmp://host:port/app/streamName四段各有用处host服务端 IP。本机测试用127.0.0.1局域网用实际内网地址。这里有个坑——有些环境里localhost会先解析到 IPv6 的::1而服务只监听了 IPv4结果就是localhost 推不进去、127.0.0.1 可以。我一般统一写127.0.0.1绕开这个玄学。port默认 1935改过就跟着改。app应用名常见是live也可能按业务分live、vod之类。这个名字填错现象是推流直接被服务端拒绝日志里能看到 app 不存在。streamName流名相当于这路流的唯一 ID。建议用设备编号_通道号这种有规律的命名后面录像检索、权限分配都靠它。服务端侧一般还要配一个是否允许推流或者推流鉴权的开关。第一次跑通建议先关掉鉴权把链路走通再接鉴权——同时开鉴权和推流出问题时你要同时怀疑两套东西。3.2 用 ffmpeg 造一路可控的测试流不用真摄像机一个本地视频文件循环推就行# 用本地 mp4 循环推一路测试流到服务端 ffmpeg -re ^ -stream_loop -1 ^ -i D:\media\test.mp4 ^ -c:v libx264 -preset veryfast -tune zerolatency ^ -b:v 1500k -maxrate 1500k -bufsize 3000k ^ -g 50 -keyint_min 50 -sc_threshold 0 ^ -c:a aac -b:a 128k -ar 44100 -ac 2 ^ -f flv rtmp://127.0.0.1:1935/live/test01Windows 的 cmd 里续行符是^PowerShell 里换成反引号或者干脆写成一行。逐项说明-re按原始帧率读取模拟实时流。不加这个参数ffmpeg 会以最快速度把文件推完服务端瞬间收到几倍速的流切片和缓冲全乱你看到的现象是推流成功但播放器一卡一卡。-stream_loop -1无限循环输入文件测试可以一直挂着。-c:v libx264 -preset veryfast编码器用软件 x264veryfast 是在画质和 CPU 之间取个平衡。测试机 CPU 弱就换ultrafast。-b:v 1500k -maxrate -bufsize码率三件套。maxrate限制峰值bufsize一般取两倍码率给编码器留缓冲余量。这三个值不设编码器会按画质自由发挥带宽瞬间打满。-g 50GOP 长度 50 帧。这个参数和后面的 HLS 切片强相关切片时长要靠关键帧对齐GOP 不固定会导致切片时长忽长忽短。-sc_threshold 0关掉场景切换自动插关键帧让 GOP 严格固定。-c:a aac -b:a 128k -ar 44100 -ac 2音频统一转 AAC采样率 44.1k、双声道。真实摄像机的音频五花八门G.711、AAC-LC、各种采样率不转码直接推服务端可能不支持。-f flv输出封装必须是 FLVRTMP 只吃这个。推上去之后 ffmpeg 窗口会持续滚动帧率和码率speed1x说明节奏正常speed3x说明-re没生效。这一步的验证方法很简单窗口不报错、速度稳定在 1x 附近就算推流端没问题剩下的锅在服务端或拉流端。3.3 拉流端验证HLS 与 HTTP-FLV 的延迟量级差推流成功不等于能看。拉流地址按协议不同分两类用 curl 先做无播放器的裸检# 检查 HLS 索引文件是否存在且返回 200 curl -I http://127.0.0.1:8080/live/test01.m3u8 # 把索引拉下来看切片列表确认 ts 分片在持续增加 curl http://127.0.0.1:8080/live/test01.m3u8 # 检查 HTTP-FLV 是否可拉只看响应头 curl -I http://127.0.0.1:8080/live/test01.flv-I只发 HEAD 请求拿响应头用来确认路径和状态码不下载流本体——直接curl一个 FLV 地址会把二进制流打到终端上刷屏还停不下来。m3u8是 HLS 的索引文件里面按顺序列出一串.ts切片。刚推流时索引里可能只有一两个切片过十几秒再拉一次切片数量应该增加、最早的被移出列表。如果索引一直是空的或者 404说明服务端没把这路流识别成需要切片的状态。延迟量级上两者不是一个档位协议典型延迟适用场景代价HLS切片时长 × 2~3常见 6~15 秒网页无插件播放、兼容性优先延迟大切片文件多HTTP-FLV1~3 秒监控预览、对实时性有要求依赖长连接部分 CDN 不友好RTMP 直拉1 秒以内内部调试、二次转推浏览器不支持需专用播放器想让 HLS 快一点就把切片时长压到 2 秒、列表长度压到 3~5 片代价是切片请求数翻几倍、磁盘 IO 压力上升。这个取舍在下一章讲录像时会再遇到一次因为录像切片和直播切片常常共用同一套参数。浏览器端验证用一个支持 FLV 的播放器页面或者直接用 ffplay 拉# 用 ffplay 拉 HTTP-FLV窗口能出画面即链路通 ffplay -fflags nobuffer -flags low_delay -i http://127.0.0.1:8080/live/test01.flv-fflags nobuffer关掉输入缓冲-flags low_delay走低延迟解码路径这两个参数是调试时用的能更快暴露流推上去了但时间戳不对这类问题——时间戳乱掉的表现是画面疯狂快进或卡住不动日志里一般不会有明显报错属于比较难查的一类。4. 录像与回放切片时长、存储路径和磁盘清理的取舍直播看通了接下来是这类视频管理平台真正的价值点录像和回放。很多人在这一步翻车不是因为功能不会开而是没算过磁盘账——一路 1080p、2 Mbps 的流24 小时不间断录像一天就是 20 GB 出头十路就是 200 GB一周就上 TB。开录制之前先把参数和清理策略定下来。4.1 录像切片时长、封装与索引三件事录像在服务端不是一个大文件而是按时间切成若干片段再配一份索引。这么设计的原因很实际一个大文件在写入过程中被异常中断断电、进程被杀整个文件可能直接损坏不可播切片方式最多丢最后一片前面的都能救回来。三个参数决定了录像的形态参数常见取值影响单片段时长5~30 分钟太短则文件数量爆炸、索引压力大太长则丢片损失大、回放拖动粒度粗封装格式MP4 / TSMP4 兼容性好、拖动方便TS 抗损坏强、适合边录边写索引方式数据库 / 文件清单数据库查询快但多一个依赖文件清单简单但要自己扫我的习惯是单片段 10 分钟、封装走 MP4、索引入库。10 分钟是个折中——一天 144 个文件一路流一个月四千多个文件系统扛得住真要断电最多丢 10 分钟。监控场景对丢片敏感就压到 5 分钟代价是文件数翻倍。切片时长还必须和编码的 GOP 对齐。前一章推流时设了-g 5025 fps 下就是 2 秒一个关键帧切片边界只有落在关键帧上才能无缝衔接。如果 GOP 是 2 秒而切片设 10 分钟那是 300 个 GOP没问题但如果 GOP 设成 10 秒、切片设 15 秒切片边界就会落在两个关键帧中间播放器拖动时会花屏或者跳帧。这类问题不报错只是回放体验有点怪很难归因属于典型的隐性坑。录像开关一般在两种粒度上全局默认策略和按流单独覆盖。批量接入的设备建议走全局策略个别重要的流比如出入口单独调长保留天数、调短切片时长。# 用 ffmpeg 直接验证服务端的录像落盘是否正常推流 3 分钟后停止去录像目录看文件 ffmpeg -re -i D:\media\test.mp4 -t 180 -c copy -f flv rtmp://127.0.0.1:1935/live/rec_test # 录像目录按修改时间倒序列出最近生成的文件确认切片在持续写入 Get-ChildItem -Path D:\dss\easydss\record -Recurse -File | Sort-Object LastWriteTime -Descending | Select-Object -First 10 Name, Length, LastWriteTime第一段用-c copy直接转封装不重编码-t 180推 3 分钟后自动停这样能精确控制测试时长不用手动掐。第二段按时间倒序列出最近写的文件Length持续增长说明在写一直不动说明写失败——写失败最常见的原因是目录权限或者磁盘满了日志里通常有对应的 IO 错误。4.2 存储路径与清理策略录像根目录默认往往在安装目录下这是最不该放的位置程序盘通常不大系统盘写满会导致整台机器出各种莫名其妙的问题包括但不限于服务起不来、日志写不进、Windows 更新失败。第一件事就是把录像路径改到独立的数据盘。改路径有三个地方要同步配置文件里的录像根目录、服务运行账号对该目录的读写权限、以及备份或清理脚本里的路径。三处漏一处现象就是配置改了但录像还在老地方或者新目录没权限、录像静默失败。第二处最容易被忽略——服务如果以系统账号跑和你的登录账号权限不一样你手动能写不代表它能写。清理策略按容量倒推别按天数拍脑袋。算法很简单可用容量 数据盘容量 × 0.8留 20% 余量给索引、日志、临时切片 单路日增 码率(Mbps) × 3600 × 24 ÷ 8 ÷ 1024 (GB) 保留天数 可用容量 ÷ (单路日增 × 路数)2 Mbps 一路日增约 21 GB。4 TB 盘留 20% 余量是 3.2 TB十路的话只够存 15 天。算完这个数再决定保留策略比开了录制跑一周发现盘满了要主动得多。清理动作我一般做成两个层次服务端自带的按天/按容量轮转如果有加一个 Windows 计划任务兜底扫老文件。兜底脚本只删超过保留期的、且不在当前写入中的文件别用「删整个目录」这种粗暴写法# 兜底清理删除录像根目录下超过 15 天未修改的 mp4先 dry-run 打印 $root D:\record\easydss $cut (Get-Date).AddDays(-15) Get-ChildItem -Path $root -Recurse -File -Include *.mp4 | Where-Object { $_.LastWriteTime -lt $cut } | ForEach-Object { # 先注释掉 Remove-Item 跑一遍确认名单没问题再放开 # Remove-Item $_.FullName -Force {0}t{1:N1} MB -f $_.FullName, ($_.Length / 1MB) }-Include *.mp4限定文件类型LastWriteTime -lt $cut用最后修改时间而不是创建时间——录像文件是边写边长的创建时间可能很早但一直在写用创建时间会误删正在录的片段。先跑 dry-run 打印名单确认无误再把Remove-Item那行放开这个习惯救过我一次早期脚本把索引文件也匹配进去了删完录像还在但列表全空等于全部废掉。注意清理脚本和录像服务同时操作同一批文件时Windows 上可能出现文件占用导致的删除失败。脚本里加-ErrorAction SilentlyContinue跳过被占用的文件让下一轮再处理比整个任务报错退出要稳。4.3 回放时间轴对不上时先看什么回放列表里有记录、点开也能播但时间轴错位——比如列表显示 10:00-10:10实际播出来是 09:58 的内容。这类问题排查顺序我固定为三步第一步看服务端和推流端的时间源。录像时间戳一般取流里的 PTS 或者服务端收到首帧的系统时间。如果推流端的系统时间和服务器差了几分钟两条时间线就错开了。内网里没有统一时间源的环境很常见各台机器的时钟各走各的。第二步看切片索引记录的是起始时间还是结束时间。有的实现按切片的第一帧时间入库有的按写完时刻入库差一个切片时长。列表和实际内容整体偏移一个固定值基本就是这个原因。第三步看是否跨了 GOP 边界。切片没有对齐关键帧时播放器为了找可解码的起点会往前或往后跳表现出来就是点 10:05 播的是 10:04 或 10:06。三步里前两步是配置问题改完重启生效第三步要回头改编码参数让 GOP 整除切片时长。真正难查的是第一种因为现象是有时候准有时候不准取决于两台机器时钟漂移的速度。5. 避坑与排查Windows 上跑这套视频管理的五个翻车点前面几章是顺利路径这一章专门写不顺利的。下面五条都是我实际遇到过或者帮人定位过的按「现象 → 原因 → 解决」写遇到对应症状可以直接对号入座。5.1 双击启动一闪而过命令行启动才看到报错现象双击主程序窗口闪一下就没了任务管理器里也找不到进程。没有任何提示。原因启动阶段异常退出。Windows 上双击启动时控制台窗口在进程退出后立即关闭stderr 里的报错根本没机会看。常见根因有三类缺少 VC 运行库报找不到某个msvcp140.dll之类、配置文件语法错误JSON 少个逗号、路径里有未转义的反斜杠、端口被占用导致绑定失败。解决一律用命令行启动把输出留在窗口里。如果报缺 dll装对应的 Visual C 运行库x86 和 x64 都装很多流媒体组件是 32 位的如果报配置解析错误按提示的行号去看路径里的\在部分配置格式里要写成\\或者/如果报端口占用回到 2.2 节查 PID。定位到具体原因之后再决定是修配置还是换端口。5.2 推流端显示成功拉流地址却 404现象ffmpeg 推流窗口一切正常帧率码率都在滚没有报错。但curl -I拉m3u8或flv返回 404。原因推流成功只代表 RTMP 握手和收流成功不代表服务端把这路流登记成了可分发状态。三个高频原因一是app名或流名对不上推的是live/test01拉的时候写成了live/test1或者大小写不一致部分实现区分大小写二是服务端配置里这路流没有开启分发只录不播三是流推上来了但一直没有关键帧切片器启动不了——这种情况推流端看着正常但服务端拿不到可切的边界。解决先在服务端的管理页面或日志里确认这路流是否出现在在线流列表里。出现了但拉不到查拉流地址的每一段没出现查推流地址的 app 和流名。确认是没关键帧的话在推流命令里显式加-g固定 GOP并确认-sc_threshold 0。另外检查一下推流是不是推到了127.0.0.1而拉流用的是内网 IP中间隔着 NAT 或防火墙策略两个方向不通的情况也会造成这种不对称现象。5.3 HLS 延迟越看越大跑了半天积了半分钟现象刚开始看延迟几秒挂着一两个小时后延迟越来越大最后能积到几十秒刷新页面才恢复。原因播放器侧的缓冲策略 服务端切片列表过长。HLS 的播放器一般会预缓冲几个切片列表越长、切片越短累积的缓冲越多。另外服务端如果保留了大量历史切片在列表里播放器可能从头开始播而不是从最新的播。网络抖动时播放器倾向于等而不是丢延迟只会增不会减。解决把 HLS 列表长度压到 3~5 片切片时长压到 2 秒同时在播放器侧开启追帧或者跳到最新的策略。对实时性要求高的场景直接换 HTTP-FLV别在 HLS 上死磕——协议本身的设计目标就是兼容性优先不是低延迟。改完参数要重启服务很多实现是启动时读一次配置。5.4 录像文件明明在回放列表却是空的现象去录像目录看mp4 文件一个不少大小也正常但管理页面的回放列表里一条记录都没有。原因录像文件和索引是两套东西。文件写成功只说明落盘了索引没写进去列表就是空的。常见诱因数据库连接失败或者磁盘满导致索引写入报错但录像写入是另一条路径照常成功索引表被清理脚本误删服务异常退出导致最后一批索引没提交。解决先查日志里有没有索引写入相关的错误重点看数据库连接和磁盘空间。确认索引服务正常后把录像文件按命名规则重新扫一遍入库——多数平台提供扫描/重建索引的功能没有的话按文件时间戳和流名手工补记录。这一步之后一定要回头改清理脚本把索引文件排除在删除范围之外否则下次还会重演。5.5 跑一夜之后 CPU 打满或者内存持续上涨现象白天测试正常挂一晚上第二天来发现 CPU 占用 90% 以上或者内存从几百 MB 涨到几个 GB最后服务被系统杀掉。原因分两种。CPU 打满通常是某一路流的时间戳异常导致转封装陷入死循环重试或者切片器在反复重建内存上涨多半是长连接没释放——每一路拉流都是一个长连接客户端异常断开拔网线、进程被杀时如果服务端没做超时回收连接对象会一直挂着越积越多。日志级别开到 debug 也会显著放大资源消耗。解决先把日志级别调回 info观察 CPU 是否回落。然后查当前连接数和服务端配置里的最大连接数、超时时间对照。给拉流连接配一个合理的空闲超时比如 30 秒没有数据就断开别设成无限。时间戳异常的流要单独隔离在推流端统一转码成标准时间基-vsync cfr强制恒定帧率别让各种奇怪的时间基直接进服务端。做完这些再加一个最简单的守护计划任务每小时检查进程存活和内存占用超阈值重启。6. 进阶收尾把服务做成开机自启的后台进程附一份上线验收清单测试阶段双击启动没问题但真要长期跑双击启动是撑不住的用户一注销进程就没了远程桌面断开也可能影响会话机器重启之后没人记得去点那一下。我一般用计划任务把主程序托管成开机自启的后台任务比装成 Windows 服务省事也比放启动文件夹可控。# 创建开机自启任务以最高权限运行工作目录设为安装目录 $action New-ScheduledTaskAction -Execute D:\dss\easydss\EasyDSS.exe -WorkingDirectory D:\dss\easydss $trigger New-ScheduledTaskTrigger -AtStartup $set New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -DontStopIfGoingOnBatteries -RestartCount 3 -RestartInterval (New-TimeSpan -Minutes 1) -ExecutionTimeLimit (New-TimeSpan -Days 0) Register-ScheduledTask -TaskName dss-service -Action $action -Trigger $trigger -Settings $set -RunLevel Highest -User SYSTEM关键点有三个-WorkingDirectory必须设成安装目录否则程序按当前目录找配置文件和静态资源一启动就报错-ExecutionTimeLimit (New-TimeSpan -Days 0)表示不限运行时长默认值会在跑满三天后把进程掐掉这个默认坑过一次-RestartCount 3 -RestartInterval让它在崩溃后自动重试三次比完全不管强。-RunLevel Highest和-User SYSTEM是为了避开权限问题——用 SYSTEM 跑意味着录像目录的权限要给到 SYSTEM这一条和 4.2 节说的是同一件事。托管方式定了上线前照这张表过一遍每一项都对应一个已经踩过的坑检查项合格标准对应问题安装路径纯英文、无空格、非系统盘中文路径导致录像写不进端口1935 与 HTTP 端口空闲防火墙已放行局域网推不进来监听地址需要对外时为0.0.0.0只有本机能访问录像目录独立数据盘SYSTEM 账号有写权限录像静默失败GOP 与切片GOP 整除切片时长回放拖动跳帧磁盘余量按码率算过保留天数留 20% 余量跑一周盘满日志级别生产环境为 info日志涨得比录像快进程托管计划任务开机自启崩溃自动重启重启后服务没了清理脚本dry-run 验证过不误删索引列表全空最后说个血泪经验。早期我图快测试环境跑通就直接上了生产结果第二天早上来发现录制全停——磁盘满了而清理脚本因为把索引目录也匹配进去删完之后回放列表是空的。从那以后我每次上线这套东西都强制走一遍先按码率算出保留天数写进备注再让清理脚本 dry-run 打印名单人工过一遍最后才放开定时任务。这三步加起来不到十分钟比事后恢复数据便宜太多。希望帮到你。本文还有配套的精品资源点击获取