视频打不开，客服先别急着让用户换网络或换浏览器。这次用户上传的是RMVB文件，问题很可能从文件进门那一刻就埋下了。RMVB是RealNetworks早年推出的封装格式，本地播放器时代很常见，但今天主流浏览器对它的支持几乎为零。网页端播不了，往往不是单一原因，得按层排查才能找到真正卡住的位置。
第一层：先看文件本身
RMVB是个封装容器，里面装着视频流和音频流。容器不被浏览器认，只是第一道门槛。就算把容器换成浏览器能识别的格式，如果内部视频编码还是早期的RealVideo，音频还是RealAudio或Cook，播放器照样解不出来。核对时别只看扩展名，用本地工具查清容器类型、视频编码、音频编码、分辨率和码率，再逐项对照目标浏览器的支持范围。
第二层：再查转码环节
不少网站维护方案会在服务端把上传文件转成通用格式，但转码任务可能因为超时、进程中断或磁盘空间不足只完成一半。这时输出文件存在，体积也不为零，却缺了完整的视频轨或音频轨。还要看转码参数是否合理——分辨率过高、码率过大、关键帧间隔过长，都会让部分设备解码吃力。转码日志里有没有失败重试记录，输出文件时长和原始文件是否一致，都是判断依据。
第三层：最后核对播放器与浏览器兼容性
桌面端和移动端的解码能力差异明显。桌面浏览器可能依赖系统解码器，移动端更多受限于硬件和系统版本。同一个输出文件，桌面能播、移动端黑屏，问题常出在编码档次或封装细节上。还要确认播放器组件是否加载成功——控制条出现但画面空白，和整个播放区域不渲染，指向的原因并不相同。
可执行的核对顺序
先看转码日志，确认任务是否成功结束、有无报错；再看输出文件属性，核对容器、编码、时长和音轨是否齐全；最后在目标浏览器实测，桌面端与移动端分别验证并记录具体表现。三步走完，问题基本能收敛到文件、转码或前端三者之一。
维护过程中应保留原始上传文件和转码记录，别因为输出文件已生成就删掉源文件。回溯时能对比原始属性与输出属性，快速判断是源文件特殊还是转码参数不当。it数运在网站维护中强调过程可追溯，正是为了让这类问题有据可查，而不是靠反复猜测。技术有章法，服务有回应，排查视频播放问题也一样，分层核对比凭经验猜更靠谱。
