上传完成先返回成功，文件落到对象存储，元数据写库，通过消息队列触发转码任务，转码完成后回调业务方更新播放地址，前端用轮询或推送感知状态即可，全程不阻塞用户操作。
短视频上传后异步转码流程怎么编排
上传阶段：先落盘再响应
用户点击发布后,客户端把视频文件直传到对象存储，而不是经过业务服务器转发，这样可以避免大文件把业务带宽占满，上传成功后客户端拿到文件key就能返回，不用等转码。
具体步骤：
- 客户端向业务后端申请上传凭证,拿到临时密钥和存储路径。
- 客户端用分片上传把视频推到对象存储,弱网环境可以断点续传。
- 上传完成后客户端把文件key、标题、封面信息提交给业务后端。
- 业务后端写入一条视频记录,状态标记为
TRANSCODING_PENDING，同时投递一条消息到转码队列。 - 客户端页面此时显示“转码中”，但用户可以继续做其他操作。
上传凭证接口一般长这样：POST /api/v1/upload/token，后端返回临时密钥、bucket名称、object前缀，客户端拿到后直接传，不经过业务服务器中转。
转码队列：异步任务的交通枢纽
队列选择直接影响流程稳定程度,多数中小团队用消息队列做中转，转码服务作为消费者拉取任务，任务消息里至少包含视频ID、源文件key、转码模板ID、回调地址。
- 如果转码节点暂时打满,消息可以在队列里堆积，不会丢任务。
- 消费确认机制保证每条任务至少被执行一次。
- 死信队列用来接住反复失败的任务,避免卡死主流程。
一条典型的任务消息结构：
{
"videoId": "20260201_xxxx",
"sourceKey": "videos/source/uuid.mp4",
"templateId": "h264_720p",
"callbackUrl": "https://api.example.com/transcode/callback"
}行业共识认为,异步转码的稳定性取决于消息队列的消费确认机制，消费者必须在转码成功并回传输出文件后，才向队列发送ack，如果先ack再上传，上传失败会导致任务永久丢失。
转码执行：ffmpeg命令与多清晰度输出
转码节点从对象存储拉取源文件到本地临时目录,然后按模板生成不同清晰度版本，以常用的ffmpeg为例，生成720p H.264版本可以执行：
ffmpeg -i input.mp4 -c:v libx264 -preset fast -b:v 1500k -c:a aac -b:a 128k -vf scale=-2:720 output_720p.mp4
生成1080p、480p版本只需调整-vf scale和码率参数，转码完成后把输出文件再上传回对象存储，路径建议按清晰度分目录，比如videos/output/{videoId}/720p.mp4。
- 源文件较大时,拉取和回传都建议走内网加速。
- 输出模板通常包含高清、标清、低清三档，App根据用户网络自动切换。
- 切片和封装可以在这一步同时完成,生成HLS的m3u8和ts文件。
HLS切片命令
如果播放端需要HLS,可以在转码后追加切片参数：
ffmpeg -i input.mp4 -c:v libx264 -preset fast -b:v 1500k -c:a aac -b:a 128k -vf scale=-2:720 -f hls -hls_time 4 -hls_playlist_type vod output_720p.m3u8这条命令会生成一个m3u8索引和多个ts切片,短视频场景下，切片时长设为4秒即可，太短会生成过多小文件，太长首屏加载会慢。
回调与状态更新：前端怎么知道好了
转码任务完成后,转码服务调用业务后端回调接口，把输出文件地址和状态写回数据库，业务后端再把视频状态改为READY，前端通过轮询或WebSocket拿到最新状态，替换播放地址。
- 回调失败要设置重试,一般重试3到5次，间隔递增。
- 前端轮询时间建议控制在2到5秒,避免频繁请求。
- 播放地址尽量使用CDN加速域名,不要直接暴露对象存储源站地址。
回调接口可以是POST /api/v1/transcode/callback，body里带上视频ID和输出文件列表，业务后端收到后先校验签名，再更新数据库，签名校验不能省，否则可能被伪造回调注入非法播放地址。
异步转码与同步转码区别在哪个环节
同步转码是上传后阻塞等待转码完成再返回结果,异步转码是先返回上传成功，转码在后台慢慢跑，两者差别不在ffmpeg本身，而在任务调度和响应时序。
| 对比项 | 同步转码 | 异步转码 |
|---|---|---|
| 用户体验 | 上传进度条长时间卡住 | 上传完成即返回，转码中可继续操作 |
| 服务压力 | 请求线程被长时间占用 | 转码节点独立扩容 |
| 失败处理 | 客户端直接看到失败 | 需要回调通知和重试机制 |
| 适用场景 | 企业内部小视频、低并发 | 短视频平台、UGC内容 |
短视频平台绝大多数选择异步转码,因为用户上传完马上离开，如果同步等待，几十秒的转码时间会造成大批超时和差评。
为什么短视频平台不用同步转码
同步转码还有一个隐藏问题：线程占用，一个视频转码耗时10秒，100个并发上传就占满100个业务线程，业务服务器被转码任务拖垮，其他接口也跟着超时，异步转码把压力转移到独立的转码集群，业务服务器只处理轻量级请求，扩容也灵活得多。
短视频云转码价格按什么算
很多团队在自建转码和云转码之间犹豫,价格主要看四个变量：输出分辨率、转码时长、模板数量、地域带宽。
- 输出分辨率越高,单价越贵，4K转码通常比1080p高出一大截。
- 转码时长按源视频时长计费,而不是按CPU占用时间。
- 模板数量越多,生成的版本越多，费用自然翻倍。
- 地域不同价格也有差异,华东、华北的转码节点资源充足，部分西部地域可能更便宜但延迟略高。
业内专家指出,影响云转码报价的核心不是单纯时长，而是输出规格和模板数量的组合，中小团队如果每天上传量不大，用云转码比自建更划算；当单日转码时长持续超过某个量级，自建GPU转码集群才值得考虑。
云转码按什么计费更划算
如果要用云转码,控制成本有三个实操方向：
- 源视频上传前先在客户端做一次压缩,降低源文件时长和码率。
- 模板不要无脑开三档,低清模板只在弱网场景启用，可以减少相当一部分输出费用。
- 批量任务用队列调度到低峰时段执行,云厂商的闲时转码价格通常更友好。
短视频转码失败怎么排查
转码失败的原因通常集中在源文件、参数模板、存储权限和队列配置四个位置，按下面顺序排查，多数问题能在半小时内定位。
-
先用ffprobe检查源文件完整性
ffprobe -v error -show_entries format=duration,size -of default=noprint_wrappers=1 input.mp4如果duration为空或报错,说明源文件本身损坏，需要让用户重新上传。
-
检查转码模板参数是否越界
比如源视频高度只有480,模板却强制输出1080p，ffmpeg会报缩放错误，可以在命令前用
ffprobe读取源分辨率，动态选择模板。 -
检查对象存储读写权限
转码节点拉取源文件时如果返回403,多半是临时密钥过期或路径错误，确认task消息里的key和实际存储路径一致。
-
检查死信队列
如果任务频繁进入死信队列,打开队列监控看消费失败堆栈，通常能直接定位到具体错误行。
-
用小程序复现
拿一条失败任务的消息体,在本地环境手动执行一次转码命令，能验证是代码问题还是环境问题。
华东和华南短视频团队怎么选转码节点
不同地域的团队部署异步转码时,优先考虑源文件上传加速和转码输出回源速度。
- 华东团队可以选择上海或杭州的BGP机房,对移动、联通、电信用户都比较友好。
- 华南团队可以优先选广州或深圳节点,离短视频用户密集区更近。
- 如果团队分布在北京和深圳两地,建议把转码服务部署在双地域，用消息队列做就近消费，降低拉流延迟。
部署双地域时,源文件可以通过对象存储跨地域复制，转码完成后各自写回本地域存储，最后同步播放地址到业务数据库，这样北京用户看北京节点转出来的视频，深圳用户看深圳节点的，CDN回源距离更短。
短视频上传后异步转码的流程编排,本质上是一套上传、队列、转码、回调的状态机，只要前两步落盘和消息不丢，后面转码失败都可以通过死信和日志快速找回，把状态字段设计清楚，把回调签名校验做好，这套流程在中小团队里跑起来并不复杂。
短视频上传后异步转码流程编排常见问题
短视频上传后多久能转码完成？
转码时长主要看源视频时长、分辨率和转码模板数量，多数情况下，一个3分钟以内的1080p视频在GPU转码节点上完成三档输出，耗时通常明显低于源视频时长，具体时间受队列堆积程度和节点负载影响，没有固定值。
短视频异步转码和同步转码价格差多少？
云厂商通常按转码时长计费,异步和同步在单价上没有本质区别，异步的好处是能错峰调度，比如夜间用竞价实例跑批量转码，综合成本会比高峰期同步转码低不少，价格差来自资源调度策略，不是计费规则本身。
自己搭建短视频转码服务需要什么配置？
至少需要一台CPU或GPU服务器、一个消息队列、一个对象存储，CPU服务器适合低并发，较多核心的处理器可以跑H.264转码，GPU则适合高并发H.265或4K场景，系统环境建议Ubuntu 22.04加ffmpeg 6.x，队列用RabbitMQ或云托管队列均可。