Ubuntu服务器视频播放失败排查：从编解码器到ffmpeg转码与HLS

在云上跑 Ubuntu 的人迟早会撞上这个场景 ssh 进去一切正常进程跑得好好的可一旦想“看个视频”——不管是想确认素材有没有转码成功、想用无头浏览器录一段页面、还是想给非技术同事演示一段生成结果——就会发现根本播不了。要么播放器一打开就黑屏要么提示缺少解码器要么干脆连个能弹出窗口的地方都没有。Ubuntu 服务器无法播放视频这件事表面看是一个问题实际上背后至少藏着四类完全不同的原因而且其中大部分并不是“坏了”而是服务器这个物种本来就不该承担播放器的职责。这篇内容我把这几年在云主机上处理视频的排查路径、参数计算、可复制的命令以及那些文档里不会写的坑一次性摊开讲清楚。适合两类人看一类是刚买了云主机、准备在上面做视频相关开发的同学另一类是已经在用无头浏览器、ffmpeg 做事但被“黑屏”“无声音”“转圈”卡住的运维和测试。哪怕你只会敲几条命令照着走也能把问题定性。1. 先把“播不了”拆成四类别一上来就重装系统1.1 无显示器、无声卡、无显卡服务器天生不是播放器这是最根本的一层。云厂商给你开通的那台 Ubuntu 实例出厂时是一台“纯计算设备”没有 X 图形服务器没有 ALSA 声卡设备节点也没有独立显卡。你 ssh 登录进去是一个字符终端echo $DISPLAY大概率是空的。任何依赖图形界面输出的播放器——无论 VLC、mpv 还是浏览器里的video标签——第一件事都是找一块能画的“画布”找不到就直接退出。很多人第一次遇到这个问题的反应是“装个播放器不就行了”于是apt install vlc装完再运行报的是cannot open display。这不是 VLC 的问题是你缺了那层图形栈。同理音频这条路也一样aplay -l会返回no soundcards found因为没有声卡硬件内核也就没有对应的设备节点。播放器解码到音频轨时找不到输出设备有些会静默跳过有些会直接抛错退出。所以判断的第一步非常简单先问自己“我是要处理视频还是要观看视频”。处理转码、抽帧、切片、截图比对完全不需要图形栈一条 ffmpeg 命令搞定观看才需要把图形栈、声卡模拟、远程桌面这一整套补齐。我见过太多人为了“看一眼视频”在一台 2 核 4G 的机器上装了完整的 GNOME 桌面结果内存被吃掉一半SSH 都变卡。这个取舍必须先想清楚。1.2 编解码器缺失能打开窗口但画面是黑的第二类问题出现在你已经把桌面装好了的情况下。播放器能启动、界面能出来、进度条也在走但画面一片漆黑或者声音有、图像没有。这种情况基本可以锁定为解码器缺失尤其是 H.264 和 H.265 这两个。原因在于版权许可。Ubuntu 官方主仓库为了合规默认不带某些受限的编解码实现libavcodec的完整版要装libavcodec-extraGStreamer 那套需要gstreamer1.0-libav和一堆-plugins-bad/-ugly的包。如果你只装了vlc而没装ubuntu-restricted-extrasH.264 的 mp4 很可能就是黑屏。反过来如果你的视频是 VP9 或 AV1 编码的 webm反而是开箱即用的因为它们没有那层专利包袱。这里有个很实用的判断手法用ffprobe把文件的实际编码格式打出来别靠文件后缀猜。.mp4只是容器里面可能是 H.264、H.265甚至 AV1。命令行输出里的Stream #0:0: Video: h264 (High)才是真相。很多“播不了”的案子最后发现是用户拿了个 H.265 的文件在没装对应解码器的环境里硬播。1.3 远程桌面协议和色彩格式带来的“次生故障”第三类最阴。你已经装了桌面、装了 VNC 服务、也装了编解码器客户端连上去能看见桌面但一打开视频窗口就是灰屏、雪花、或者只有一块纯色方块。这种情况问题往往不在视频而在远程桌面本身的传输方式。传统 VNC 的机制是“把屏幕像素抓下来压缩后发给你”它对静态画面很友好对每秒变化几十次的视频画面极其吃力。服务端为了省带宽会做帧率限制和区域比对结果就是视频区域刷新跟不上表现为卡顿、撕裂、颜色错乱。深度色深设置不对比如服务端 24 位、客户端按 16 位解释还会导致整屏偏色。这些现象特别容易被误判成“显卡驱动有问题”然后一头扎进去装驱动装到天亮也没用因为云主机根本没有能装驱动的物理显卡。我的经验是不要把远程桌面当成视频播放器用。真要给别人看正确的做法是把视频在服务端转成一张张关键帧或者压成低分辨率的小片段走 HTTP 给对面看而不是让他盯着 VNC 窗口里的实时画面。这个思路转换能省掉 90% 的调试时间。1.4 网络与带宽能播但一直转圈第四类看似和“播放”无关其实是最高频的线上问题。视频文件放在对象存储上网页里用video src...引过去结果一直转圈或者播两秒卡三秒。这时候你 ssh 上去curl一下速度飞快于是怀疑人生。差别在于curl是把整个文件拉完而浏览器播放器以及大多数流式播放器需要边下边播这就要求 mp4 文件的元数据moov box在文件头部而不是尾部。如果你的视频是用某些工具直接导出的moov 在文件末尾播放器就必须先下载完整个文件才能开始播几秒钟的视频没感觉几百兆的视频就是灾难。解决办法是在转码时加-movflags faststart让 ffmpeg 在封装完成后把 moov 挪到前面去。另一个高频原因是公网带宽。云主机默认的公网带宽通常是按兆比特计费的1 Mbps 大概是 125 KB/s一段 1080p、码率 5 Mbps 的片子光传输就需要 5 Mbps 的持续带宽。你在本地局域网看着流畅的视频放到云上给外部访问卡是必然的。这时候要么降码率转码要么走 CDN要么就用 HLS 把片子切成小片按需加载。这不是播放器的问题是物理带宽的问题。2. 排查思路与工具选型先定性再动手2.1 三步定性法五条命令锁定方向我不喜欢一上来就翻日志效率太低。处理这类问题我有一个固定的五条命令序列跑完基本能确定方向。# 1. 看有没有图形环境 echo DISPLAY$DISPLAY; ls /tmp/.X11-unix/ 2/dev/null # 2. 看有没有声卡 cat /proc/asound/cards 2/dev/null || echo 无 ALSA 声卡 # 3. 看视频文件的真实编码 ffprobe -v error -show_entries streamcodec_name,codec_type,width,height,r_frame_rate \ -of defaultnoprint_wrappers1 input.mp4 # 4. 看解码器是否装全 ffmpeg -codecs 2/dev/null | grep -E h264|hevc # 5. 看公网带宽和实际下载速度 curl -o /dev/null -s -w %{speed_download} B/s\n 视频文件的公开地址第一条命令告诉你有没有 X 环境没有就说明任何 GUI 播放器都别想了。第二条告诉你音频输出有没有落脚点。第三条是最容易被跳过但最关键的编码格式决定了后面所有决策。第四条看ffmpeg -codecs输出里 h264 前面是DEV.LS还是D.V.LS只要带D可解码就没问题如果这一行压根没有说明你得补包。第五条用真实速度除以 8 换个单位就能算出实际可用带宽和视频码率一比够不够一目了然。2.2 必装的诊断工具箱我建议每台要做视频处理的机器上都常驻这几个包加起来不到 100 MB但能省下无数次“再装一下试试”。工具包名用途优先级ffmpeg / ffprobeffmpeg转码、抽帧、探测编码信息必装完整解码库libavcodec-extra补上受限编解码实现必装媒体信息查看mediainfo比 ffprobe 输出更直观推荐带宽观测nload/iftop实时看网卡吞吐推荐虚拟屏幕xvfb无显示器时提供虚拟画布按需浏览器chromium需要渲染页面时按需装的时候有一个细节libavcodec-extra装上之后要确认 ffmpeg 真的用上了它。ffmpeg -version输出里会列出编译配置含有--enable-libx264之类的字样说明编码器可用。有些老镜像里的 ffmpeg 是从更老的源装的和 extra 库版本对不上会出现“库装了但 ffmpeg 找不到”的怪现象这时候统一用apt install --reinstall ffmpeg libavcodec-extra把两者对齐。注意ubuntu-restricted-extras这个包会把一堆受限编解码实现和字体打包装进来装的过程中会弹出一个许可确认的交互界面在脚本里批量执行时记得加DEBIAN_FRONTENDnoninteractive否则会卡在那里等输入看起来像“命令挂住了”。2.3 什么时候该果断放弃“播放”这条路这一点我想强调一下因为它能帮你省下大量时间。判断标准其实就一句话如果观看者不是你本人、且不是实时需求就别在服务器上播。具体拆开说如果目标是“确认这段视频生成得对不对”抽三帧图片看一眼就够了比播一遍快十倍如果目标是“让用户能在网页上看”那就该走转码 分片 HTTP 分发这条路而不是让人连 VNC如果目标是“自动化测试里验证播放行为”用无头浏览器加载页面、监听play事件和currentTime变化配合截图比真看屏幕可靠得多。反过来说只有一种情况值得把图形栈和播放器搬上服务器你需要做交互式的人工操作比如调试一个只能在 GUI 里跑的采集工具。这种场景我的建议是——临时用完就关掉别把它做成常驻服务。3. 实操一用 ffmpeg 完成“播放”真正想做的事3.1 安装、验证与第一帧假设我们在一台干净的 Ubuntu 22.04 上目标是把“看视频”变成“看关键帧”。先装工具并验证sudo apt update sudo apt install -y ffmpeg mediainfo ffmpeg -version | head -n 1 ffprobe -v error -select_streams v:0 \ -show_entries streamcodec_name,width,height,avg_frame_rate,duration \ -of defaultnoprint_wrappers1 input.mp4输出里你会拿到类似codec_nameh264、width1920、avg_frame_rate30/1的信息。这三个数字决定了后面所有的参数选择编码格式决定编码器分辨率决定缩放目标帧率决定抽帧密度。抽第一帧是最常用的操作用来快速确认“这个文件到底有没有画面”ffmpeg -y -ss 00:00:02 -i input.mp4 -vframes 1 -q:v 2 preview.jpg这里-ss放在-i前面是关键帧定位速度极快毫秒级但可能不准会跳到最近的 I 帧放在-i后面是逐帧解码定位精确但慢。日常预览用前者做精确截图比如截取某个字幕出现的瞬间用后者。我个人的习惯是先快速抽一张看有没有画面需要精确再补一次慢的。3.2 批量抽帧与缩略图拼接如果目的是“一眼看完整段视频”抽一张不够抽一百张又太多。我的做法是按时长分档一分钟以内的片子每 2 秒抽一帧五分钟以内每 10 秒超过十五分钟每 30 秒。可以用一条命令自适应# 每 10 秒抽一帧并缩放到宽 320 ffmpeg -y -i input.mp4 -vf fps1/10,scale320:-2 -q:v 3 thumb_%03d.jpgscale320:-2里的-2是个小技巧高度按比例自动算并且保证是偶数。为什么必须是偶数因为 H.264 在 4:2:0 色度采样下要求宽高都能被 2 整除奇数会在编码时报错这个坑我踩过不止一次。抽完之后用 ffmpeg 自带的 tile 滤镜拼成一张九宫格比一张张点开看效率高得多ffmpeg -y -i thumb_%03d.jpg -vf tile4x3 -frames:v 1 contact_sheet.jpg这张拼图在很多场景下就是“播放”的完美替代品素材审核、转码效果比对、生成结果的快速质检一张图看完。3.3 转码参数怎么算CRF、码率与分辨率的三角关系转码是这套流程里最容易翻车的一环因为参数选错会导致“转完更卡”或者“转完糊成一片”。先把三个核心概念理清楚。CRF恒定质量因子是 x264/x265 的质量控制参数范围 0-51数字越小质量越高、文件越大。经验值是18 肉眼无损23 是默认甜点28 开始明显可见压缩痕迹32 以上适合纯预览。它的好处是不用管码率复杂画面自动多给比特简单画面自动少给。码率估算用在需要控制文件大小的场合。粗略公式是目标码率(bps) ≈ 目标文件大小(MB) × 8 × 1024 × 1024 / 时长(秒)举个实际的例子一段 180 秒的视频我希望最终不超过 30 MB那么目标码率是30 × 8 × 1024 × 1024 / 180 ≈ 1.4 Mbps再减去音轨的 128 kbps视频轨大约给 1.27 Mbps。这个码率配 720p 是合理的配 1080p 就偏低了会有明显的块状感。分辨率与码率的匹配有个经验表我平时直接照着选分辨率帧率推荐视频码率适用场景640×36025/30400–600 kbps移动端预览、缩略预览1280×72025/301.5–2.5 Mbps网页内嵌播放1920×108025/304–6 Mbps常规高清1920×1080607–9 Mbps高动态画面基于这张表一条稳妥的转码命令长这样ffmpeg -y -i input.mp4 \ -c:v libx264 -preset medium -crf 23 \ -vf scale1280:-2 \ -c:a aac -b:a 128k -ac 2 \ -movflags faststart \ output_720p.mp4参数背后的意图值得说清楚。-preset medium是编码速度与压缩效率的平衡点veryfast能快 2-3 倍但文件大 20%slow反之在云主机按小时计费的情况下medium通常性价比最高。-ac 2强制双声道因为有些源是 5.1 声道浏览器在部分环境下对它支持不好会直接导致“有画面没声音”。-movflags faststart前面说过了是把索引挪到文件头让边下边播成为可能。提示如果源文件本身有旋转元数据手机竖拍视频常见ffmpeg 默认会保留 rotate 标记但不真正旋转导致转出来的画面方向不对。加-vf scale...,transpose...手动纠正或者用-noautorotate配合明确的滤镜链别指望自动搞定。3.4 切成 HLS把“播不动”变成“边下边播”当视频要给外部用户看而单文件又比较大的时候HLS 是投入产出比最高的方案。它把视频切成 6 秒左右的小片段配一个索引文件播放器按需拉取首屏时间从“下载完整个文件”降到“下载第一个片段”用户几乎立刻就能看到画面。ffmpeg -y -i input.mp4 \ -c:v libx264 -preset medium -crf 23 -g 48 -keyint_min 48 -sc_threshold 0 \ -c:a aac -b:a 128k -ac 2 \ -f hls -hls_time 6 -hls_list_size 0 \ -hls_segment_filename seg_%03d.ts \ index.m3u8-g 48和-keyint_min 48是在强制关键帧间隔固定为 48 帧30fps 下约 1.6 秒-sc_threshold 0关掉场景切换自动插关键帧。这三个参数为什么必须加因为 HLS 切片只能在关键帧处切如果关键帧分布不均匀切出来的片段时长就会忽长忽短播放器切换时会出现卡顿和音画不同步。这是我自己踩过的一个很隐蔽的坑不加这几个参数视频本身能播但一到片段边界就顿一下很难定位。切完之后怎么验证不需要浏览器用 ffprobe 检查每个片段时长是否接近 6 秒即可for f in seg_*.ts; do d$(ffprobe -v error -show_entries formatduration -of csvp0 $f) echo $f $d done如果所有片段都在 5.9–6.1 秒之间说明切片正常。这个方法比打开播放器看可靠得多而且能写进自动化脚本里做回归。4. 实操二确需图形界面时最小可用方案怎么搭4.1 轻量桌面加虚拟屏幕别装全家桶有些工具确实离不开图形环境比如某些基于 Qt 的采集程序、需要渲染字体的报告生成器。这时候的正确姿势是“只装必需的”而不是apt install ubuntu-desktop。完整桌面会拉进来几百个包、吃掉 1 GB 以上内存在 2 GB 的实例上直接 OOM。我的标准组合是xvfb提供虚拟屏幕xfce4提供轻量桌面可选很多时候用不上加上x11vnc做远程查看。安装大概是这样sudo apt install -y xvfb x11vnc xfce4-terminal # 起一块 1280x720、24 位色的虚拟屏幕编号 99 Xvfb :99 -screen 0 1280x720x24 -nolisten tcp export DISPLAY:99为什么是 24 位色而不是 16 位因为 16 位色下很多渲染引擎会走低质量的色彩路径截图出来偏色做像素级比对会失败。为什么-nolisten tcp因为虚拟屏幕本来就不需要监听网络端口关掉减少暴露面这个习惯在云主机上很重要。这时候再跑需要图形环境的程序就不会报cannot open display了。验证方法很简单DISPLAY:99 xdpyinfo | grep dimensions DISPLAY:99 import -window root /tmp/screen.png # 需要 imagemagick能截出一张 1280×720 的全黑图就说明虚拟屏幕工作正常。4.2 无头浏览器里让视频真的“跑起来”自动化测试里最常见的需求是网页里有个视频我想验证它确实在播放。直接用chromium --headless打开页面往往会发现currentTime一直是 0。原因有几个层次。第一层是解码支持。Chromium 的开源构建默认不带 H.264 解码许可原因遇到 H.264 视频会直接显示为不可播。验证方法是查chrome://media-internals或者干脆换个 VP9/WebM 格式的测试素材。如果非要用 H.264得确认装的是带完整编解码的构建版本。第二层是渲染后端。无头模式下没有 GPUChromium 会退到软件渲染。默认的软件渲染路径在某些版本下不初始化视频合成层导致视频解码了但不推进时间。这时候要显式指定chromium --headlessnew --no-sandbox \ --use-glswiftshader --autoplay-policyno-user-gesture-required \ --window-size1280,720 \ --virtual-time-budget8000 \ --screenshot/tmp/render.png \ http://127.0.0.1:8080/player.html--use-glswiftshader是强制走软件 GL 实现虽然慢但能保证渲染管线完整跑通。--autoplay-policyno-user-gesture-required关掉自动播放限制——浏览器默认要求用户交互后才允许播放这个策略在无头环境里是致命的它会让视频永远停在第一帧而你以为是自己代码写错了。这个坑我调了整整一个下午才发现页面在本地手动点一下就能播一上无头就静止问题就在这条策略上。--virtual-time-budget8000是给页面 8 秒的虚拟时间预算让它自己“快进”跑完否则截图会在视频还没开始播的时候就截下来出来的是一张黑图。第三层是容器环境里的沙箱。--no-sandbox在很多镜像里是必需的但要注意这降低了隔离级别只在可信的内网环境用。4.3 VNC 到底该怎么用什么时候不该用如果你确实需要人工看一眼桌面x11vnc能连着刚才那块虚拟屏幕x11vnc -display :99 -forever -shared -rfbport 5900 -localhost 加了-localhost之后它只监听本地回环外部连不进来。想看怎么办用 SSH 端口转发临时开一条通道用完即关。这个做法比直接把 5900 端口暴露到公网安全得多也省去了担心别人扫端口的焦虑。关于 VNC 看视频这件事我前面已经说过它的传输机制了这里补一个实测数据在 1280×720、24 位色的配置下一段滚动字幕的页面x11vnc 的带宽占用能到 2-4 Mbps而同一块屏幕静止时只有 30-50 kbps。差了近百倍。这解释了为什么很多人一开视频窗口远程连接就糊了——不是网络差是 VNC 这个协议本来就不为高帧率内容设计。所以我的结论很明确VNC 用来操作界面不用来观看内容。要看内容走第 3 节那条路把它变成图片或者分片。5. 常见问题与排查速查表5.1 报错信息对照表下面这张表是我这几年攒下来的基本上覆盖了九成的报错。遇到不认识的报错先在这里找一遍比搜索快。报错 / 现象根因处理方式cannot open display没有 X 环境设DISPLAY:99并起 Xvfb或改用无图形方案no soundcards found无音频设备播放时加-an或装 dummy 声卡模拟画面黑、声音正常缺 H.264/H.265 解码器装libavcodec-extra及相关 GStreamer 插件video一直转圈moov 在文件尾部转码时加-movflags faststart播放两秒停一下HLS 关键帧间隔不均强制-g固定 GOP 并关掉场景切换插帧无头浏览器画面静止自动播放策略拦截加--autoplay-policyno-user-gesture-required视频区域花屏/灰块远程桌面像素传输跟不上不在远程桌面里播视频改走截图或分片Unknown encoder libx264ffmpeg 构建不含 x264换发行版自带的 ffmpeg 包别自己乱编转码后方向错误旋转元数据未处理滤镜链里显式transpose纠正转码后文件比原文件还大CRF 设得太低CRF 调到 23-26或改用两遍码率控制5.2 三个踩过的坑说明书上不会写第一个坑磁盘空间被临时文件吃光。ffmpeg 在转码大文件时如果中途失败会在当前目录留下一个未完成的输出文件如果你写了循环批量处理几十个半成品文件轻松占满系统盘然后所有操作莫名其妙失败。我的习惯是在命令里显式-y覆盖并且在循环开始时先rm -f目标文件同时给/tmp设一个定期清理的定时任务。第二个坑编码速度和计费的隐藏关系。云主机按小时算钱-preset slow比medium慢 2.5 倍左右压缩率只提升不到 10%。如果你的处理量是每天几千条选medium甚至fast的总成本反而更低因为机器可以早点释放。这个账很多人不算觉得“压得更小就是更省”其实省的是存储亏的是算力多数情况下算力更贵。第三个坑字体缺失导致字幕烧录变成方块。用subtitles滤镜把字幕刻进画面时如果系统里没有对应的中文字体输出会是满屏的方块。装fonts-wqy-zenhei这类中文字体包并fc-cache -fv刷新缓存就能解决。判定方法也简单fc-list :langzh输出为空就是没装中文字体。6. 参数选择、带宽估算与运维层面的几条经验6.1 带宽和并发怎么估给外部提供视频时最容易低估的就是带宽。一个粗略的估算方法是所需带宽(Mbps) ≈ 视频码率(Mbps) × 并发数 × 1.3那个 1.3 是缓冲系数用来吸收码率波动和重传。举例720p、2 Mbps 的片子预计 20 人同时看需要2 × 20 × 1.3 52 Mbps。一台按流量计费的云主机公网带宽通常只有几 Mbps这个数字明显撑不住。解决办法有三条按性价比排序降低码率把片子压到 1 Mbps 以下画质损失可接受、用 HLS 分片首屏快用户感知好但不解决总带宽、走对象存储加内容分发把带宽压力转移出去。我通常先做第一条因为它零成本且立竿见影再考虑第三条。还有一个细节容易被忽略出网方向和入网方向的带宽往往不对称。你的机器下载很快不代表对外提供也快。测的时候一定要从外部机器发起请求来测本地curl自己测出来的数字没有意义。6.2 规格选择多少核才够转码转码是典型的 CPU 密集型任务。以 x264medium预设、1080p 输入为例单核实测大约能跑到 0.3-0.5 倍速也就是说一个 10 分钟的视频单核要处理 20-30 分钟。4 核并行下大概 6-8 分钟。所以选规格的判断逻辑是先算出你的日均处理量和可接受的处理时间再倒推核数。如果只是偶尔转一两个文件2 核足够用-preset veryfast能明显缩短等待。如果需要批量处理几百条与其加核不如开几台小机器并行分发因为转码任务之间的独立性很好横向扩展比纵向升级更划算。内存这块1080p 转码单进程大约占 300-500 MB4K 会到 1.5 GB 以上。2 GB 内存的机器跑一个 4K 转码任务就要开始用 swap 了速度会掉一半这时候应该先加内存而不是加核。6.3 权限面收窄的几个习惯云主机上做视频处理经常需要临时起 HTTP 服务方便自己预览。这里有几个习惯我强烈建议养成。服务只监听回环地址需要外部访问时用 SSH 隧道临时打通用完立刻停掉。生成的文件放在固定目录定期清理别让半成品堆满磁盘。跑 ffmpeg 时用nice降一下优先级避免它把 CPU 吃满导致 SSH 会话卡死——这个体验非常糟糕我遇到过一次机器 4 核全被转码占满ssh 敲一个字符要等三秒最后只能从控制台强制重启。nice -n 10 ffmpeg -y -i input.mp4 -c:v libx264 -preset medium -crf 23 out.mp4nice -n 10让转码进程在有其他任务时主动让出 CPU代价是转码慢一点换来的是机器始终能操作。对于长期跑批量任务的机器这个参数基本是必加的。7. 最后聊聊思路上的转变写到这里其实核心观点已经很清楚了Ubuntu 服务器“无法播放视频”绝大多数情况下不是一个需要修复的故障而是一个需要重新定义的需求。这台机器的设计目标是执行计算、承载服务、处理数据它的强项在 CPU、在内存、在磁盘 IO而不在显示、音频和图形加速。你硬要把它改造成一台播放器投入产出比极低而且改完之后运维复杂度会成倍上升。我自己在这条路上走过最弯的一段是早期在一台 2 GB 内存的实例上折腾桌面环境加远程桌面装了删、删了装前后花了两个周末最后也没能得到一个“能流畅看视频”的环境。后来想明白了我要的其实不是“看”而是“确认内容对不对”和“让别人能看到”。前者用抽帧加拼图解决一条命令、三秒钟后者用转码加分片解决用户打开网页就能看体验还更好。前后加起来不到半天。如果你现在正卡在这个问题上我建议先花五分钟回答三个问题这个视频最终是给谁看的是实时看还是事后看是看内容还是验证内容答案会直接把你导向不同的技术路径而且大概率其中没有一条需要在服务器上装播放器。剩下的就是照着第 2 节的五条命令定性再用第 3 节的命令把事情做完。中间那些参数第一次照着抄跑通之后再逐条改改成什么样自己心里就有数了。