@albin504 肯定有同学要说：腾讯股票再跌一半都有可能。 确实有可能。
长期看，股价最终会反应公司的价值。 投资股票容易、但也难，需要一些定力

1 、如果要买标普，伯克希尔大概率比标普更值得买。

2 、评论区没人从投资回报角度分析投资房子和投资股票（公司）的区别。
拿上海举例，次新房的租金回报率大部分不到 2%（ 700 万的房子，一年租金不到 12 万）。
投资房子，本金 700 万，要五六十年回本，年回报率低于 2%，和银行定期存款相当。
当然，考虑到房子能扛通胀（钞票可以无限印，但房子的地段造不出来），买房子大概率比存银行强。

然后说说投资公司（买股票就是买公司）的回报率。
以腾讯股票为例，现在市值 5 万亿，每年净利润 2500 亿。并且公司护城河很深，公司基本不用投资扩大生产，大部分利润都可以留存，回购股票或者分红。

买腾讯股票，就等于买了腾讯这家公司，投入的是 5 万亿本金，每年 5%回报（ 2500 亿）。
另外，腾讯的利润大概率每年还会有 10%左右的增长，也就是说，投入 10 年后，每年的回报肯定超过 10%

另外，港股现在大巴市盈率 10 左右的红利股（如中国移动、中国海洋石油）。

因此，从投资回报的角度，毫无疑问应该卖房炒股。如果是自住的话，就当是买车了，也很有幸福价值。

播放源视频文件，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 ，会出现“同一个视频，两拨用户体验不一样”的情况。

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

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

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

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

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

@yuanxing008 好。大佬

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

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

@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 。

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

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

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

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

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

@ETiV rtmp 模块，我问了 chatgpt：

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

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

@wnpllrzodiac 了解。动态生成 ts 切片，有成熟的开源方案推荐吗

@wzy44944 谢谢！思路很好能满足需求，如果有来源实现就好了

@wangxiaoer 支持转成 hls ，问题是这个过程太慢（转成 hls 前要先转码，因为 hls 支持的编码有限，对于不支持的编码必须先转码）