https://help.aliyun.com/zh/oss/live-transcoding
需求是这样：视频上传到对象存储之后，能够让用户尽快可播放。 这里涉及到视频转码，有两种主流方案：
1 、离线转码。 视频上传后，利用 ffmpeg 实现离线转码。特点是转码耗时太久，1 小时 1080P 视频完成转码要 45 秒以上（使用 GPU 硬件资源的情况下，如果使用 cpu 更慢）。意味着用户上传完视频之后不能立马播放
2 、实时转码。 用户边播边转，实现几乎零延迟。
目前遇到的问题是：在阿里云不提供服务的国家，像 aws 、google 这些云厂商不提供边转边播能力，只有离线转码。
问题： 1 、如果自建边转边播能力，难度大吗？ 有成熟的技术栈吗？ 2 、是否有一些其他的付费方案（比如购买一套实时转码服务）可选择？
 |
1
cheng6563 2 天前
ffmpeg 本身就能开端口在线转码啊
|
 |
2
lpe234 2 天前
有些想法可能不太适合，可以参考下：
1. 是否可以通过非技术手段，让用户等待下。比如 提示用户转码/审核中？ 2. 是否可以先转码几分钟，用来做视频预览。等全部转码完毕后，再提供完整播放 3. m3u8 那个也不算特别实时吧。之前有个需求要在网页播放 RTSP 视频流，我就用 ffmpeg 转码成 ts 文件播放的。 `自建边转边播能力，难度大` 这个我感觉难度可能在于并发量和计算资源使用率上面。 我那需求就几个摄像头，CPU 转也没太大压力 |
 |
3
cccn 2 天前
|
 |
4
ningxing 2 天前
搜索下分片技术，可以实现你要的效果
|
 |
5
ETiV 2 天前 via iPhone
没看懂你这个场景到底是直播还是点播
nginx 有个 rtmp 模块，用它入门最简单了 |
 |
6
wzy44944 2 天前
实现上不复杂，你发的那个链接里就有技术细节，就是生成 hls 格式让播放器播放。
需要在存储系统和播放器之间加一层代理，做 m3u8 的生成和触发 ffmpeg 转 ts 1. 播放开始时，根据视频时长，预先把 m3u8 生成吐出来给播放器 2. 播放到哪个 ts 就计算下在视频中的位置，触发这个位置之后的转码 可以把 ts 的大小调到 10s ～ 15s 左右，这样保证每次拖动进度，开播时间在 1s 甚至几百 ms 以内。 |
 |
7
wang9571 2 天前
AWS 不是有 MediaLive 服务可以转码吗
|
 |
8
wjx0912 2 天前
plex 的用户量可能最多，个人喜欢 jellyfin 。看你用户量有多大
|
 |
9
lambdaq 2 天前
楼上说的 m3u8 就是你要的吧。原理是 1 小时 1080P 视频完成转码要 45 秒以上，但是你截取 10s 一小段转码上传不需要 45 秒啊。你就一小段一小段的转
|
 |
10
capric 2 天前
mediamtx 和 ZLMediaKit 可以支持很多协议实时转码
https://github.com/bluenviron/mediamtx https://github.com/ZLMediaKit/ZLMediaKit |
 |
11
wangxiaoer 2 天前 via iPhone
把视频文件转成直播格式是不是算边转边播，ffmpeg 支持把视屏转成 hls 吧
|
 |
14
albin504 OP @wang9571 谢谢提供的信息。
AWS Elemental MediaLive 是 AWS 提供的一项 实时视频处理服务，主要用于将实时视频流（ live video ）进行编码、转码和打包，然后分发给观众。它属于 AWS 媒体服务（ AWS Media Services ） 生态的一部分，常用于 直播（ live streaming ）场景。 说这个常用于直播场景，我们的需求是在线点播，不知道是否是同一种技术？ |
|
16
albin504 OP @wangxiaoer 支持转成 hls ，问题是这个过程太慢（转成 hls 前要先转码，因为 hls 支持的编码有限，对于不支持的编码必须先转码）
|
 |
18
xmumiffy 2 天前 via Android
先切片再转，如果改不了 m3u8 ，那就转完再合并
|
 |
19
wnpllrzodiac 2 天前 via Android
网盘支持在线播放都是这么搞的。动态生成 ts 切片。
|
|
20
albin504 OP @wnpllrzodiac 了解。动态生成 ts 切片，有成熟的开源方案推荐吗
|
 |
21
BlueSkyXN 2 天前
“1 、离线转码。 视频上传后，利用 ffmpeg 实现离线转码。特点是转码耗时太久，1 小时 1080P 视频完成转码要 45 秒以上（使用 GPU 硬件资源的情况下，如果使用 cpu 更慢）。意味着用户上传完视频之后不能立马播放”
不是哥们，这都算慢？？？？？？？？ 那只能切片处理，更不好 |
 |
23
npe 2 天前
m3u8 或者 fmp4 就可以了
|
|
24
albin504 OP @ETiV rtmp 模块，我问了 chatgpt：
Nginx-rtmp 侧重“直播式”产 HLS：它是线性往前切片。若希望“用户拖到 10 分钟处就从那里开始即时打包”，并且不用实时等，建议引入： • nginx-vod-module （ Kaltura 开源）：对 H.264/AAC 的 MP4 做 按需打包成 HLS/DASH （不转码，只重打包，几乎秒开与秒拖）。 • 若上传编码不统一，需要 后台转码一版通用 H.264/AAC ，再由 nginx-vod 做即时打包 —— 这是很多点播平台的常见组合。 他这个回复对不？ rtmp 无法实现用户拖到 10 分钟处就从那里开始即时播放。 |
 |
25
jackOff 2 天前
转码分片缓存呢？比如有些资源几乎无人访问就只保留源文件，热资源就长期保存 ffmpeg 转码好的不同规格的分片，这是服务器，或者你让客户端自己去 ffmpeg 去转
|
 |
26
jiames1969 2 天前
先给原视频播放，转码成功换成新视频。
|
 |
27
wangtian2020 2 天前
不要转码！不要转码！ 原格式转发，客户自己转去
|
 |
28
8355 2 天前  1
可以了解一下火山引擎的智能转码策略
播放量高才触发异步转码，转码的意义有 2 个 一个是降低播放卡顿和一个是省播放流量。 转码和尽快可播放并不冲突，你的 1 和 2 都需要考虑到业务高峰期的算力，估计你是达不到的。 高清直播业务也是用客户端硬件做视频流编码预处理，既然无法做到客户端预处理只能考虑异步转码，cdn 顶住未转码这部分事件的播放流量。 |
 |
29
zhmouV2 2 天前 1
只有我的想法是，，，显示上传进度的时候，延长 45s 吗？
|
 |
30
Admstor 2 天前 3
希望程序员永远不要只用技术脑袋思考业务问题
第一 用户上传进度条并不一定需要用真实进度条，可以在最后加入编码时间的进度等待，这里用户并不需要知道，只需要告诉用户正在上传，请保持在上传页面，你 1 小时视频转码只要 45 秒，但是对于用户来说，上传用 1 分钟还是 1 分 45 秒，都可以接受。 第二 现在设备端解码能力很强，如果你再编码只是解决宽带和存储压力，那么客户本身预览就可以直接给预览原文件，但是稍后正式推送给其他客户的时候，使用重编码的文件 切片等细节楼上很多朋友都说了 |
 |
31
lance07 2 天前
为什么必须要先转码才能放？刚上传不会立马大量访问吧
|
 |
32
onebitbank 2 天前
有一个开源的工具，实现了浏览器端视频转码，https://github.com/Vanilagy/mediabunny ，你可以试试
|
 |
33
chengzhi 1 天前
ZLMediaKit
|
 |
34
newbie111 1 天前
ffmpeg 先切一个两分钟的出来给用户播放（ mp4 或 m3u8 ）的同时进行转码，播放过程中请求 api 查询完整 m3u8 是否已切片号，api 确认切片完成后返回地址，播放器根据已播放时间跳转到指定 ts 文件位置。
|
 |
35
dusu 1 天前 via iPhone
你要的是 ngx_vod_module
|
 |
36
ragnaroks 1 天前
https://bunny.net/stream/ 实时谈不上，大概几分钟的延迟
|
 |
37
COW 1 天前
可以上传后，先提供低清晰度的版本，这样转码速度很快，不需要几十秒；高清晰度的后台异步处理就行了
|
|
38
albin504 OP @Admstor 谢谢。
第一，是目前产品从交互层面认同的方案，可采纳。但不是完美的方案，会导致用户上传视频明显变慢。 第二： 上传视频文件后在客户端播放是可以利用本地设备的解码能力。 但是，产品层面支持用户上传文件后，通过 h5 链接把视频分享给其他用户，其他用户打开链接后，需要跳转回客户端进行播放。 这里如果使用重编码的文件，同样也是需要用户等待转码完成才允许分享 |
 |
39
pc10201 1 天前
用实时音视频或超低延时直播，支持边放边播边录
|
|
40
albin504 OP @Admstor 谢谢大家的建议，综合大家的信息，目前倾向于这么解决：
以下方案结合起来使用： （ 1 ）上传进度条中，加入编码时间的进度等待。 这样，不管后续云端是对视频内容全部转码，还是切片按需转码，用户体验上都是整体没问题的 （ 2 ）云端转码方案：会实现一套离线转码（目前已开发完成）作为兜底方案。同时，再去开发一套 @wzy44944 这位老哥提供的按需切片转码的方案。 项目上线后，如果按需转码效果还可以，就切到按需转码方案。否则就切换到"内容全部转码"方案。 从客户端的角度，播放 API 是一致的，都是获取到 m3u8 链接就可以了，请求 ts 文件时云端直接返回，或者按需转码分片后返回。 这里再请教下： 转码的场景下，ts 文件的内容，后续是否也需要走 cdn ？ |
 |
42
HADB 1 天前
说实话我感觉有点搞复杂了，不要过度设计，看你项目到底是多大的项目，多少用户量。你就说 B 站吧，也不是上传完立马就能播的……
|
|
43
albin504 OP @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 。 |
 |
44
yuanxing008 1 天前
ts 内容肯定要挂 CDN 啊 万一恶意拉流了 你服务器 200M 的带宽都顶不住
|
|
45
albin504 OP |
|
47
albin504 OP @yuanxing008 好。大佬
|
 |
48
guiyumin 1 天前
2 、实时转码。 用户边播边转，实现几乎零延迟。
应该有 1-5 秒的延迟 |
|
49
guiyumin 1 天前
实时转码是不是可以打水印或者广告上去
|
|
52
yuanxing008 1 天前
@albin504 自信一点，就是的，当然如果你使用的是阿里 oss 的方案存储视频源的话，本身就有对应的水印服务可以使用，包括 ts 切片以及在线转码，你现在考虑的这套方案是我 17 年那阵子调研的时候用的了，在我现在的技术视角来看的话，当年的这套方案还是有很大的调整和优化空间（成本控制，技术实现复杂度，维护性等等）
|
|
53
albin504 OP @yuanxing008 谢谢，遇到大佬了。 你们自己实现了按需分片转码对吧？ 我们是多国家提供服务，阿里云支持的区域，目前用的是阿里云的在线实时转码方案。阿里云不支持的区域，在考虑用上面的自研方案
|
|
54
yuanxing008 1 天前
@albin504 为何会有阿里云不支持的区域呢？播放源上层套了全球 CDN 的，无非就是客户端的部署问题而已，通过 LB 或者 DNS 进行分流到部署在不同地域的集群不就好了吗
|
|
55
wnpllrzodiac 1 天前 via Android
@albin504 不转码的话，nginx-vod
|
|
56
albin504 OP @yuanxing008 政治原因，数据不能出境。如印度用户的数据必须存储在印度服务器
|
 |
58
spritecn 9 小时 3 分钟前
先上传..先直接用 OSS 地址看,或挂个 CDN,然后让阿里后台慢慢转,转好后新来看的用户换连接
|
|
59
albin504 OP @spritecn 这也是个思路。 只是对于高画质视频，网速不太快的情况下，播放会明显卡顿吧。另外，对于部分视频格式，会不会不支持拖动播放（用户拖动后云端 seek 到对应的流）？要不然为啥要发明 HLS 协议
|
|
60
albin504 OP 播放源视频文件，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 ，会出现“同一个视频，两拨用户体验不一样”的情况。 |
Select Language