请教视频转码边转边播技术

[albin504]

https://help.aliyun.com/zh/oss/live-transcoding

需求是这样：视频上传到对象存储之后，能够让用户尽快可播放。 这里涉及到视频转码，有两种主流方案：

1 、离线转码。 视频上传后，利用 ffmpeg 实现离线转码。特点是转码耗时太久，1 小时 1080P 视频完成转码要 45 秒以上（使用 GPU 硬件资源的情况下，如果使用 cpu 更慢）。意味着用户上传完视频之后不能立马播放

2 、实时转码。 用户边播边转，实现几乎零延迟。

目前遇到的问题是：在阿里云不提供服务的国家，像 aws 、google 这些云厂商不提供边转边播能力，只有离线转码。

问题： 1 、如果自建边转边播能力，难度大吗？ 有成熟的技术栈吗？ 2 、是否有一些其他的付费方案（比如购买一套实时转码服务）可选择？

[albin504]

@chengzhi 谢谢。 我看推荐 ZLMediaKit 的同学比较多，我详细看看

[HADB]

说实话我感觉有点搞复杂了，不要过度设计，看你项目到底是多大的项目，多少用户量。你就说 B 站吧，也不是上传完立马就能播的……

[albin504]

@chengzhi https://github.com/ZLMediaKit/ZLMediaKit/wiki/ZLMediaKit%E5%AE%9E%E7%8E%B0%E6%8C%89%E9%9C%80%E6%8B%89%E6%B5%81
看了 ZLMediaKit 的文档，感觉他主要定位是直播。

客户端需要 RTSP （ Real-Time Streaming Protocol ）实时流协议来使用。

但是目前我们客户端用的 HLS 协议播放视频。

--------
以下是 AI 回复：

RTSP 的特点

RTSP （ Real-Time Streaming Protocol ）是一种 实时流协议，主要用于低延迟点播/直播。

和 HLS 最大区别：

HLS 是基于 HTTP 文件切片（ m3u8 + ts ），播放器拉文件 → 支持快进/拖动。

RTSP 是持续的流，不是文件，不存在 m3u8/ts 文件。

RTSP 客户端想要拖动，必须由 服务器端支持 seek 。

[yuanxing008]

ts 内容肯定要挂 CDN 啊 万一恶意拉流了 你服务器 200M 的带宽都顶不住

[albin504]

@HADB 用户量很大，公司战略产品。
我看了下哈，B 站上传完视频之后，提示审核中，这应该是中国特殊国情决定的，我们是国外市场，没有审核的逻辑。
之前试过百度云盘，上传后网页中立马就能播放。

[albin504]

@albin504 这么说有点装逼。 或者说，公司很重视产品体验吧，咱程序员只能尽量满足需求

[albin504]

@yuanxing008 好。大佬

[guiyumin]

2 、实时转码。 用户边播边转，实现几乎零延迟。

应该有 1-5 秒的延迟

[guiyumin]

实时转码是不是可以打水印或者广告上去

[albin504]

@guiyumin 这个可估算的。1 小时的视频用 GPU 转码最快 45s ，10s 的视频（ 1 个分片）不到 1s

[albin504]

@guiyumin 理论上是，优酷视频右脚上的水印（优酷 logo ）估计就是转码时候加上去的吧

[yuanxing008]

@albin504 自信一点，就是的，当然如果你使用的是阿里 oss 的方案存储视频源的话，本身就有对应的水印服务可以使用，包括 ts 切片以及在线转码，你现在考虑的这套方案是我 17 年那阵子调研的时候用的了，在我现在的技术视角来看的话，当年的这套方案还是有很大的调整和优化空间（成本控制，技术实现复杂度，维护性等等）

[albin504]

@yuanxing008 谢谢，遇到大佬了。 你们自己实现了按需分片转码对吧？ 我们是多国家提供服务，阿里云支持的区域，目前用的是阿里云的在线实时转码方案。阿里云不支持的区域，在考虑用上面的自研方案

[yuanxing008]

@albin504 为何会有阿里云不支持的区域呢？播放源上层套了全球 CDN 的，无非就是客户端的部署问题而已，通过 LB 或者 DNS 进行分流到部署在不同地域的集群不就好了吗

[wnpllrzodiac]

@albin504 不转码的话，nginx-vod

[albin504]

@yuanxing008 政治原因，数据不能出境。如印度用户的数据必须存储在印度服务器

[guiyumin]

@albin504 这个要是能做成了，是很牛逼的
因为可以实时加不同的水印

[spritecn]

先上传..先直接用 OSS 地址看,或挂个 CDN,然后让阿里后台慢慢转,转好后新来看的用户换连接

[albin504]

@spritecn 这也是个思路。 只是对于高画质视频，网速不太快的情况下，播放会明显卡顿吧。另外，对于部分视频格式，会不会不支持拖动播放（用户拖动后云端 seek 到对应的流）？要不然为啥要发明 HLS 协议

[albin504]

播放源视频文件，AI 给的答案：

1. 播放体验问题

弱网卡顿严重
原始文件往往是高码率（比如 8Mbps 的 1080p ，甚至 30Mbps 的 4K ），用户网速达不到就会疯狂缓冲。相比之下，HLS/DASH 会给播放器多个码率，自动降级。

首屏延迟高
播放器需要先下载足够数据才能解码出画面，文件越大、I 帧（关键帧）越稀疏，等待越久。转成 HLS 的话，用户几乎秒开，因为只要下一个小 ts 分片就能播。

拖动不友好
原始 MP4 播放拖动时，必须等到文件的 moov box （元数据）正确并且索引可用。如果文件没“fast start”（ moov 在文件头），用户拖到结尾会触发整段数据拉取，浪费又慢。

2. 兼容性问题

不支持自适应码率 (ABR)
原始文件只有一个清晰度，不可能根据网络自动切换。

不同终端差异大
iOS Safari 、安卓浏览器、微信内置播放器，对 MP4 直链的 seek 支持各不相同；有的能拖，有的只能从头播。

直播/边录边播没法玩
原始文件是个完整包，没法像流协议那样边生产边消费。

3. 成本和运维问题

带宽成本高
用户全量拉高码率文件，对 OSS/CDN 是巨额流量消耗。如果用 HLS ，很多时候用户只拉 480p 的分片，成本能省一大截。

缓存利用率差
CDN 缓存原始大文件，不同用户拖不同位置时，命中率低；但如果是分片，大家都从 m3u8 的第 37 段开始，请求命中率就高很多。

转码延后体验割裂
前面一批用户看到的是原始文件，后面新来的用户切到 HLS ，会出现“同一个视频，两拨用户体验不一样”的情况。