广告屏在大堂刚挂上去的那天下午，甲方负责人站在屏幕前等着看自己的片子上屏。演示设备接上网络，后台点了下发。等了大概半分钟，屏幕右上角出了个旋转的加载圈，然后直接黑屏，主机风扇倒是转得挺欢。那一刻我就知道，问题根本不是网络，也不是板子，而是物料在送到屏幕之前做的那道“ffmpeg播放准备”没做好。

这台广告屏要接入的系统叫“智梯云枢・全维管控广告系统”，整个系统负责把电梯轿厢、楼宇大堂里的广告屏，从素材上传、内容审核、广告编排、内容下发、屏端播放到状态上报全部管起来。我主要负责的是媒体播出准备这一层，说直白一点，就是用FFmpeg把原始广告素材加工成所有屏端设备都能稳定播放的文件。很多做播放系统的朋友一开始会忽略这一层，觉得“放个视频而已，能有什么难度”，但在我把原素材直接推给设备、吃了几次黑屏和花屏的亏之后，我确定这道工序绕不过去。

这篇不打算讲大而全的架构，就聚焦“播放准备”这一段，把素材为什么不能用原始文件直接推、FFmpeg怎么做转码和分段、怎么校验和灰度上线，以及我实际踩过的几个坑，一次性讲清楚。如果你正在做类似的广告投放系统，或者只是想让自己的视频在各种终端上都播得稳定，这篇应该能帮你少走不少弯路。

1. 播放链路里最容易被低估的一环：为什么所有物料都要过一遍FFmpeg

在智梯云枢这个项目里，一段广告从进入系统到出现在电梯屏上，链路大概是这样的：素材上传、内容审核、广告编排、播放准备、内容分发、屏端下载与解码、播放与监看、效果数据回传。很多人把注意力放在审核、编排和数据回传上，因为这几块看起来有“业务价值”，但真正决定视频能不能顺利播出来的，其实是播放准备这一步。后面那些环节出了问题，至少能拿到报错日志；播放准备出了问题，屏端往往只有一个黑屏等着你。

1.1 播放准备在系统里到底负责什么

播放准备承担的任务可以拆成四块。第一是格式统一，把上传上来的MP4、MOV、AVI，甚至某些甲方从设计公司拿到的奇怪封装格式，全部转成屏端解码器确定能处理的编码格式和容器格式。第二是参数锁定，分辨率、码率、帧率、像素格式、音频采样率这些参数全部按规范校准，避免同一批素材在不同屏幕上出现画质差异，或者干脆播不出来。第三是流化和分段，对大文件做切片、生成索引，让屏端在弱网环境下也能边下边播。第四是物料完整性校验，确认转出来的文件没有黑场、静音、花屏、时长异常这些问题，才能进入发布队列。

这四块工作听起来是逐层递进的，但实际做起来要反复交叉。比如一个素材转码之后发现时长不对，有可能是源文件本身就有问题，也可能是转码参数导致帧数计算偏差，这时候你得回头重新检查原始文件和转码日志，而不是直接在输出文件上打补丁。播放准备不是一个“执行一次就完事”的步骤，它在整个系统里更像一个加工车间，每一条物料都要在车间里被检验、修正、包装，最后才准出门。

1.2 不经历这道工序，会出什么结果

如果你直接把原始素材推给屏端播放器，会遇到三类典型问题。第一类是物理上的不兼容，有些屏的芯片和播放器只支持H.264的Main Profile，你给一个H.265或者H.264 High Profile的文件，播放器要么弹出“不支持”提示，要么在解码的时候直接卡死，表现就是黑屏或者一直转圈。第二类是容量问题，原始素材码率动辄几十Mbps，几十个点位同时拉取文件，网络带宽根本扛不住，屏端那点存储也撑不了几天。第三类是异常素材，有些文件看起来能播，但中间有损坏的帧，播到一半卡住，这在广告场景里就属于播出事故，比黑屏还让人头疼。

我们系统上线初期的黑屏事件，就是这三种问题的叠加。原始素材在一台高配开发机上播得好好的，下发到低端屏上直接黑屏，排查到最后才发现是编码级别太高、像素格式还是yuv444，屏端解码器根本不认。从那以后，播放准备就成了所有物料上屏前必须经过的一道硬性工序，谁想跳过它，谁就要做好第二天被点位上的电话打爆的准备。

2. 屏端硬件能力的真实约束：先摸清播放边界，再定转码规范

搞播放准备，第一步不是写FFmpeg命令，而是去摸清楚屏端解码器的上限。这个“上限”不是拿芯片手册测算出来的，而是用测试物料一台台实弹打出来的。我去对接的第一批设备里，就有用了好几年的老安卓主板，处理器性能弱，视频解码全靠芯片里固化的硬件模块。这类设备有一个共性特点：你给它一个低码率、兼容性好的H.264文件，它能连续播七天不重启；你给它一个参数稍微“前卫”一点的文件，它可能当场给你表演一个卡死。

2.1 把屏端能力归纳成一张准入矩阵

我在项目里做了一张“素材准入矩阵”，把不同设备的硬解能力、系统版本、最大支持分辨率、良好兼容的编码格式全部列出来，然后取了一个交集作为系统级的默认转码规范。这张表看起来简单，实际价值很高，因为它是所有FFmpeg参数决策的依据。

表里最关键的一行是“避免H.265”那行。很多开发者觉得H.265省码率，就不假思索开启了，结果老设备直接歇菜。就算新设备支持H.265，也要评估屏端播放器用的解码库是哪一代，是完整支持HEVC Main Profile，还是只支持到某个子集。这里有一个很容易踩的坑：不少屏端系统虽然号称支持H.265，但只支持8bit主档，遇到10bit色深的片源直接黑屏或者花屏。所以我在默认转码链路里，一律锁H.264，只在确认特定型号设备支持后才放开H.265。

为了摸清这些能力，我没有只看资料，而是做了一批专门的压力测试片。每种编码组合生成一个小文件，在每类屏上循环播放，记录什么时候花屏、什么时候黑屏、什么时候温度异常。这个过程很枯燥，但非常值得，因为最终生成的准入矩阵是拿真实屏幕一颗一颗试出来的，而不是靠PPT上的参数猜的。

2.2 分辨率与码率的取舍逻辑

确定分辨率的时候，有一条很现实的原则：不是越高越好，也不是越清晰越好。电梯广告屏有它的独特观看场景——屏体面积不大、观看距离近、循环播放，单支片长一般在10秒到30秒。在这个场景下，1080p和720p的观感差异其实没那么明显，但低分辨率在弱网环境下的加载速度差异非常明显。我最终把默认分辨率定为1080x1920竖屏，对应电梯轿厢内侧的竖屏广告位，以及1920x1080横屏，对应大堂里的横屏广告位，码率统一控制在3Mbps到5Mbps之间。

这个码率区间是我反复测试后定的。3Mbps跑普通素材够用，画面里若有大段快速运动的镜头，比如汽车广告的行驶画面，我会单独提升到5Mbps。但一般不会再高了，因为广告屏不是家庭影院，观众不会盯着细节看，核心诉求是文字和产品画面要清楚，色彩要正。把码率控在3到5M的另一个好处是屏端解码压力小，本地存储也能多存好几天的广告量，这在后面做缓存策略时帮了大忙。

3. FFmpeg转码与封装实践：从原始素材到屏端可播文件的关键参数

确定了准入矩阵之后，就进入核心实操环节，也就是用FFmpeg把原始素材加工成符合规范的文件。这一节我把三件事讲透：默认转码命令怎么选参数、音轨怎么处理、竖屏横屏素材怎么归一化。

3.1 一套默认转码命令的拆解

我先给出在智梯云枢项目里最常用的一套竖屏转码命令，这套参数在大多数设备上都实测过，稳定程度很高。

ffmpeg -y -i input.mp4 \ -vf "scale=1080:1920:force_original_aspect_ratio=decrease,pad=1080:1920:(ow-iw)/2:(oh-ih)/2,setsar=1,format=yuv420p" \ -c:v libx264 -profile:v main -level 4.0 -preset veryfast -crf 22 \ -maxrate 5M -bufsize 8M \ -c:a aac -b:a 96k -ar 48000 -ac 2 \ -movflags +faststart \ -r 30 \ -force_key_frames "expr:gte(t,n_forced*2)" \ output.mp4

逐项解释一下关键参数，这段值得你反复对照自己的命令看。

scale和pad这一组：先把画面等比缩放到不超过1080x1920的范围内，再用黑边补成精确的1080x1920画布。这样不管原始素材是横的还是竖的，最后输出都是统一尺寸，屏端播放器不用做任何自适应，自然也就不会出现拉伸变形。这里我加了setsar=1，保证像素宽高比标准化，避免个别播放器上画面被横向拉宽。

-profile:v main -level 4.0：锁定H.264主档级别4.0。选这个组合的原因很简单，它覆盖了绝大多数廉价解码芯片；不选High是因为老解码器对High档多出来的部分语法支持不稳定。Level 4.0对1080p@30fps这个规格是足够的，如果你要跑到60fps或者4K，级别就得往上提，但广告屏场景通常用不着。

-pix_fmt yuv420p：这个参数最容易被忽略，但我敢说一半以上的黑屏问题都跟它有关。原始素材如果是10bit色深或者yuv444采样，很多屏端解码器直接不认。yuv420p是普适性最强的像素格式，转码时锁死它，可以提前规避大量兼容性问题。

-preset veryfast：服务端转码量大，用veryfast能大幅提升吞吐量，代价是压缩效率略低，但配合crf 22和5Mbps的maxrate，画面质量已经足够。如果你对画质有更高要求，可以降到medium，但一定要考虑转码机的并发压力。

-c:a aac -b:a 96k -ar 48000：广告片几乎都是配乐加配音，96k的AAC完全够清晰。采样率统一到48000很重要，后面我会专门讲这个坑。

-movflags +faststart：把moov元数据块挪到文件头部。这样播放器不需要下载完整个文件就能开始播放，对边下边播场景非常重要。

-force_key_frames：强制每2秒一个关键帧。广告系统经常需要从中间切入或者循环播放，关键帧对齐会让这些操作顺滑很多，后面做分段时这个参数也帮了大忙。

如果你是横屏投放，只需要把scale和pad的目标分辨率改成1920x1080，其他参数保持不变。这套命令在我后来做服务化封装时，变成了一个可配置模板，按屏幕方向、目标分辨率、码率档位生成不同的FFmpeg参数组合。

3.2 音轨处理：不是每条片都要有声音

广告屏分布在电梯轿厢和大堂，这两个场景对声音的要求完全不同。大堂可能需要声音来吸引注意力，轿厢里声音开大了会打扰乘客，而且很多老点位根本没有音箱。所以音轨处理要准备两套策略：有声版本和静音版本。

需要静音的片源，直接在转码时丢弃音轨：

ffmpeg -y -i input.mp4 -an -c:v libx264 ... output.mp4

需要替换背景音乐的，则先提取原片音轨，做电平分析和响度归一化，再与音乐轨道混合。这里要提醒一句：混合音轨时记得统一采样率。我见过不少素材是44100Hz采样率，而屏端音频播放器默认按48000Hz处理，结果声音直接变成“快进+变调”，就是因为没有在转码时把采样率统一成48000。这个问题的症状很不明显，你电脑上听一切正常，到屏上就变味，排查起来很耗时间。

3.3 素材归一化的边界：不要动不动就重编码

有的素材上传上来，本身已经是规范内的H.264+AAC，这种情况就不要完整重编码了。用FFmpeg的stream copy直接改容器和元数据，能省掉大量的转码资源。比如只是需要把moov挪到文件头部，可以这样做：

ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4

这个操作不改变画质，CPU几乎零负载，但效果立竿见影。判断要不要重编码，其实有个简单标准：先用ffprobe看素材编码信息，如果编码、分辨率、码率、像素格式全部落在准入矩阵范围内，就stream copy；只有某项不达标才走完整转码。这道判断在我系统里做成了一个自动决策模块，能显著降低整体转码压力。毕竟你每天要处理几十上百条广告素材，省下来的一次转码成本，累积起来非常可观。

4. 分段与本地缓存：广告不会断播的边下边播方案

广告屏不比家里的电视，它经常处在电梯井这种信号不太稳定的环境里，还要被频繁开关门、强电干扰。如果把整支视频当成一个MP4让屏端先下载再播，下载中段一下就得整个重来；如果边下边播，又必须保证文件结构适合分段读取。这一章讲的是我如何用FFmpeg分段，以及分段之后下发策略怎么设计。

4.1 为什么整文件单播会让点位死一片

项目初期，我踩过直接推完整MP4的坑。上线头几天还算平稳，点位一多问题就暴露了：早高峰时段，几十个点位同时拉取几百MB的视频，中心带宽直接被挤爆，部分点位下载超时，屏上就一直转圈。还有更现实的场景——电梯里的网络信号时好时坏，下载到一半断了，文件不完整，播放器直接罢工。后来我换成分段思路后，整个逻辑就不一样了：屏端根据编排表，按需下载对应片段，缺哪段补哪段，而不是每次都拉取完整文件。

我当时用的是HLS的思路，但并不完全是跑HLS协议，而是借用HLS的分片方法和m3u8索引结构做分发。屏端播放器内部读取的就是一个分片列表，逐个去拉TS片段。每个片段只有几百KB，某个片段没拉下来就补哪个，拉下来就缓存到本地。断网重连后只需要补零头，不需要重新下载整个广告包。这一套机制落地后，点位卡死率下降得非常明显。

4.2 用FFmpeg生成对齐关键帧的分片

分段播放对源文件有一个硬性要求：每个分片必须从一个关键帧开始，否则播放器在拼接多个片段的时候，画面会出现瞬间的马赛克或者卡顿。这个要求在转码阶段其实已经提前满足了，因为我每2秒强制一个关键帧，现在切分片只是把这段序列按时间切开。

ffmpeg -y -i output.mp4 \ -c copy \ -f hls -hls_time 6 -hls_list_size 0 -hls_segment_filename seg_%03d.ts \ playlist.m3u8

这里-c copy是直接复制视频流和音频流，不重新编码，速度快到基本秒级。关键点是前面转码阶段已经做了关键帧对齐，现在每6秒切一个分片，每个分片必然以关键帧开头，播放器切换时足够平滑。-hls_list_size 0的意思是m3u8索引文件里保留全部分片条目，不自动清理旧的，方便播放器回溯播放。如果源文件没有做过关键帧对齐，我提醒你一句：宁可回炉重新转码一遍，也不要用-force_key_frames去硬切，因为copy模式下这个参数对视频流是不生效的，你只会得到一堆断裂的片段。

4.3 分片生成后的落盘与下发策略

分片生成后，系统里会得到一份m3u8索引文件和一堆ts分片。在智梯云枢中，这些文件会进入内容分发服务，按点位和行政区划打上标签，下发到各个区域的边缘缓存节点，或者直接由屏端主动拉取。屏端本地会维护一块固定大小的缓存空间，存满后按最久没播放的顺序淘汰旧内容，保证新广告有地方落。

我特别要强调一个避坑建议：千万别在广告排期变更的瞬间集中触发全量下载。我们踩过一次，排期一改，全城屏端同时发起拉取请求，中心带宽瞬间吃满。后来的做法是把下载任务打散，每个点位在播放间隙下载，并加上随机延迟，这样中心带宽不会出现尖峰。分段机制配合这套策略之后，原来的“几百MB大文件整包下载”彻底变成了“按需拉取几百KB片段”，整个下发链路的稳定性上了一个台阶。

5. 上线前的最后一道闸：用ffprobe和FFmpeg做自动化质检

播放准备不只是“转完码就算完”。在把片子上屏之前，还要做一道自动化的媒体质检，否则你永远不知道哪个环节会出错。这一章不聊大原则，直接说我在系统里做的三道检查。

5.1 用ffprobe做文件信息核验

第一步是先读取文件元数据，核对关键字段是否落在规范内。我在校验模块里写了一个脚本，用ffprobe输出JSON格式的格式信息和流信息，再逐项比对。

ffprobe -v error -print_format json -show_format -show_streams output.mp4

检查的字段包括：视频流的编码、宽度、高度、像素格式、帧率，音频流的编码、采样率、声道数，以及整体文件的时长和大小。任何一项不符合准入矩阵，直接打回重新转码。这一步看着简单，但它把“屏端播放时突然报错”变成“文件在发布前就被拦截”，问题处理成本是完全不同的量级。屏端报错你连日志都很难抓，而校验阶段出问题几分钟就能定位。我不允许任何未经校验的文件流到发布队列，这条规则没有任何商量的余地。

5.2 黑帧与静音检测：这些一眼能看出的问题不能靠人眼

还有一种问题是偶发的帧损坏，ffprobe看不出来，但播放器会卡顿或者画面闪烁。我会用两个过滤器做启发式检测。黑帧检测用blackdetect，第5章探索与调试：

ffmpeg -i output.mp4 -vf blackdetect=d=0.5:pic_th=0.95 -f null - 2>&1 | grep blackdetect

如果检测出连续0.5秒以上几乎全黑的画面，就会被标记为质量异常。静音检测用siledetect：

ffmpeg -i output.mp4 -af silencedetect=noise=-35dB:d=0.5 -f null - 2>&1 | grep silencedetect

这里要小心误报：如果素材本身设计就是渐黑转场，那么出现短暂黑场是正常现象。所以质检结果不会直接拦截文件，而是进入人工复核队列，由审核员快速看片确认。我把自动检测定位成辅助筛选，而不是绝对判决，这套机制上线后误伤率很低。音画同步问题我会用生成参考帧配合音频波形对比的方式抽查，广告片虽然短，但出一次不同步就非常致命。

5.3 灰度上屏：准备得再好，也永远要留一个试错窗口

质检全部通过不代表一定没问题，因为屏端播放器、网络环境、点位配置这些变量太多，不可能在测试环境全部覆盖。所以发布环节我设计了灰度模式：默认先推给5%的点位，观察30分钟内的播放成功率、卡顿率和上报延迟，指标正常后再把剩余点位分批次推送。

灰度逻辑非常依赖数据反馈。如果播放器没有把播放状态、卡顿和异常上报回来，灰度就变成盲人摸象。智梯云枢的屏端有状态采集模块，每次播放开始、暂停、异常都会打点回传，而我的播放准备发布流程，正是依赖这些回传数据来做节奏判断。一个点位卡顿率突然上涨，我能在几分钟内定位到是哪个片子、哪个编码参数出了问题，然后马上回滚或替换片段，而不是等甲方打电话来投诉。

6. 我在这个项目里踩过的FFmpeg坑：一条条说给你听

最后写几个我实际踩过、且不止一次踩到的坑。这些坑单个看起来都很小，但组合起来就能决定一次发布成不成功。

6.1 黑屏不一定是你转码错了，可能是profile和level组合的问题

我之前一直以为黑屏都是文件损坏或者编码不兼容，后来发现有一个很隐蔽的案例：一段素材是H.264 High Profile Level 5.1，屏端芯片其实支持H.264，但支持的Level只到4.1，结果硬解失败直接黑屏。ffprobe出来编码格式并没有异常，因为你没有看level字段。从那以后，我的准入矩阵里专门加了一列level，转码时统一限制在-level 4.0，宁可牺牲一点极端高帧率高码率的支持，也要保证解码器的绝对兼容。

6.2 时间戳异常引发的音画不同步

有一次批量转码之后，发现总有几条片子在屏端音画不同步，而在电脑上看又是正常的。后来用-vsync和-fps_mode反复排查，才定位到问题出在源素材自身的时间戳乱序。有些素材采集段没有标准时间码，或者封装工具生成的时间戳递增不规律，FFmpeg按默认方式处理时会把异常时间戳也一并保留下来。最后的解法是在转码时强制固定帧率，对输出流时间戳做归一化处理，相当于告诉FFmpeg不要信源文件的时间戳，按我指定的帧率重新排列。加上-r 30并配合-fps_mode cfr之后，这个问题彻底消失。

6.3 FFmpeg版本差异能坑死人

这是最容易被忽视的坑：服务器上如果用系统自带的FFmpeg，版本往往很老，某些滤镜和参数的名字跟新版完全不同。比如新版用-fps_mode，老版本还叫-vsync；blackdetect在不同版本里的参数单位也有差异。我最后在团队内部固定使用同一个版本的静态构建FFmpeg，所有转码机都用同一份二进制，彻底避免版本不一致带来的行为差异。针对这个问题我还定了个规矩：升级FFmpeg版本属于重大变更，不能直接替换生产环境，必须先转码一批样本素材，和旧版本输出做逐帧对比，确认无差异才能上线。

还有一点顺带提醒：不要在生产环境随手装来自不明渠道的二进制，尽量从官方渠道获取或者自己完整构建一遍。转码这种事，一个细微的库函数差异都可能导致批量素材出问题，版本锁定和来源可靠比什么都重要。

这个项目做到后期，我自己最大的体会是，播放准备不是一个“做完就可以不管”的技术环节，它是一个需要持续维护的标准化体系。素材源在变，屏端硬件在升级，网络环境在波动，只有不断用真实设备、真实素材去验证转码策略，才能保证投放链路一直稳定。你要是也正在做类似的系统，建议从准入矩阵入手，先把你手上的屏端能力摸清楚，然后再一条一条调FFmpeg参数，这样比我当初从零开始靠黑屏排错要高效得多。