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

[albin504]

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

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

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

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

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

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

[BlueSkyXN]

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


不是哥们，这都算慢？？？？？？？？ 那只能切片处理，更不好

[keepongjl]

@BlueSkyXN 感觉这转码的速度还是比较快的，而且业务系统上传的视频可定会有转码、审核的流程

[npe]

m3u8 或者 fmp4 就可以了

[albin504]

@ETiV rtmp 模块，我问了 chatgpt：

Nginx-rtmp 侧重“直播式”产 HLS：它是线性往前切片。若希望“用户拖到 10 分钟处就从那里开始即时打包”，并且不用实时等，建议引入：
• nginx-vod-module （ Kaltura 开源）：对 H.264/AAC 的 MP4 做 按需打包成 HLS/DASH （不转码，只重打包，几乎秒开与秒拖）。
• 若上传编码不统一，需要 后台转码一版通用 H.264/AAC ，再由 nginx-vod 做即时打包 —— 这是很多点播平台的常见组合。

他这个回复对不？ rtmp 无法实现用户拖到 10 分钟处就从那里开始即时播放。

[jackOff]

转码分片缓存呢？比如有些资源几乎无人访问就只保留源文件，热资源就长期保存 ffmpeg 转码好的不同规格的分片，这是服务器，或者你让客户端自己去 ffmpeg 去转

[jiames1969]

先给原视频播放，转码成功换成新视频。

[wangtian2020]

不要转码！不要转码！ 原格式转发，客户自己转去

[8355]

可以了解一下火山引擎的智能转码策略
播放量高才触发异步转码，转码的意义有 2 个 一个是降低播放卡顿和一个是省播放流量。
转码和尽快可播放并不冲突，你的 1 和 2 都需要考虑到业务高峰期的算力，估计你是达不到的。
高清直播业务也是用客户端硬件做视频流编码预处理，既然无法做到客户端预处理只能考虑异步转码，cdn 顶住未转码这部分事件的播放流量。

[zhmouV2]

只有我的想法是，，，显示上传进度的时候，延长 45s 吗？

[Admstor]

希望程序员永远不要只用技术脑袋思考业务问题

第一
用户上传进度条并不一定需要用真实进度条，可以在最后加入编码时间的进度等待，这里用户并不需要知道，只需要告诉用户正在上传，请保持在上传页面，你 1 小时视频转码只要 45 秒，但是对于用户来说，上传用 1 分钟还是 1 分 45 秒，都可以接受。

第二
现在设备端解码能力很强，如果你再编码只是解决宽带和存储压力，那么客户本身预览就可以直接给预览原文件，但是稍后正式推送给其他客户的时候，使用重编码的文件

切片等细节楼上很多朋友都说了

[lance07]

为什么必须要先转码才能放？刚上传不会立马大量访问吧

[onebitbank]

有一个开源的工具，实现了浏览器端视频转码，https://github.com/Vanilagy/mediabunny ，你可以试试

[chengzhi]

ZLMediaKit

[newbie111]

ffmpeg 先切一个两分钟的出来给用户播放（ mp4 或 m3u8 ）的同时进行转码，播放过程中请求 api 查询完整 m3u8 是否已切片号，api 确认切片完成后返回地址，播放器根据已播放时间跳转到指定 ts 文件位置。

[dusu]

你要的是 ngx_vod_module

[ragnaroks]

https://bunny.net/stream/ 实时谈不上，大概几分钟的延迟

[COW]

可以上传后，先提供低清晰度的版本，这样转码速度很快，不需要几十秒；高清晰度的后台异步处理就行了

[albin504]

@Admstor 谢谢。
第一，是目前产品从交互层面认同的方案，可采纳。但不是完美的方案，会导致用户上传视频明显变慢。

第二： 上传视频文件后在客户端播放是可以利用本地设备的解码能力。 但是，产品层面支持用户上传文件后，通过 h5 链接把视频分享给其他用户，其他用户打开链接后，需要跳转回客户端进行播放。 这里如果使用重编码的文件，同样也是需要用户等待转码完成才允许分享

[pc10201]

用实时音视频或超低延时直播，支持边放边播边录

[albin504]

@Admstor 谢谢大家的建议，综合大家的信息，目前倾向于这么解决：
以下方案结合起来使用：
（ 1 ）上传进度条中，加入编码时间的进度等待。 这样，不管后续云端是对视频内容全部转码，还是切片按需转码，用户体验上都是整体没问题的
（ 2 ）云端转码方案：会实现一套离线转码（目前已开发完成）作为兜底方案。同时，再去开发一套
@wzy44944 这位老哥提供的按需切片转码的方案。 项目上线后，如果按需转码效果还可以，就切到按需转码方案。否则就切换到"内容全部转码"方案。 从客户端的角度，播放 API 是一致的，都是获取到 m3u8 链接就可以了，请求 ts 文件时云端直接返回，或者按需转码分片后返回。

这里再请教下： 转码的场景下，ts 文件的内容，后续是否也需要走 cdn ？