客户第一次自己在云直播控制台上开流，最常问的一句是：这三个有什么区别，我该点哪个。
标准直播、快直播、慢直播。名字确实容易误导，让人以为是画质或者速度的等级划分，选最好的那个就行。实际上它们是三条不同的技术路线，各有各的代价。
三条路各是什么逻辑
标准直播走的是HLS或者FLV这类基于HTTP的分发，延迟通常在三到十秒。它的优势是CDN节点覆盖最广、成本最低、并发能力最强。几万人同时在线也不慌，因为整个互联网的缓存体系都在帮它分担。
快直播走的是低延迟协议，延迟能压到一秒以内，好的时候几百毫秒。代价是单位成本明显高一截，而且对客户端有要求——观众用的播放器得支持这个协议。并发能力也不如标准直播，超大规模场次要谨慎。
慢直播是另一个维度的东西，它跟延迟无关。慢直播指的是长时间连续、低码率、无人值守的那种直播形态，比如一个固定机位对着工地拍三个月。它的设计目标是长期稳定和低成本，不是实时性。
把这三个放一起理解会容易些：标准直播是省钱靠谱的默认选项，快直播是花钱买实时性，慢直播是花时间换持续存在感。
会议什么时候真的需要快直播
我的看法可能跟销售不太一样：大部分会议不需要快直播。
一场三小时的行业峰会，专家在台上讲，观众在线听。延迟五秒还是零点五秒，观众感知不到任何差别——他们又不需要跟台上抢话。这种场次上标准直播，省下来的钱够加一个机位。
真正需要压延迟的，是有实时互动的环节。
连麦问答是最典型的。远端专家和现场主持人一问一答，如果走标准直播，远端听到问题已经过了五六秒，答完再回来又是五六秒，现场就会出现那种尴尬的空档，主持人不知道该不该往下说。这种场次必须上快直播，或者至少给连麦这一路单独开低延迟通道。
抽奖、投票、答题这类也一样。观众在手机上点了，结果要在几秒内反映到大屏上，延迟一高整个节奏就乱。
还有一类是多会场联动。主会场和三个分会场互相要看到对方，任何一路延迟大了，主持人交接时就会撞车。这种我们一般把会场之间的互传走快直播，对外的观众分发走标准直播，两套并行。
混着用才是常态
实际项目里很少只用一种。我们比较常见的排法是这样：
- 对外的大规模观看：标准直播，成本可控，并发不怕
- 连麦、多会场互传：快直播，把延迟压在一秒内
- 会后的长期回放窗口：转点播，不再占直播资源
有个细节容易漏——两路并行的时候，观众端可能出现“隔壁同事的画面比我快五秒”的情况。会议室里两个人各自用手机看，一个走了快直播一个走了标准，这体验挺奇怪的。所以对外分发最好统一成一种，别让观众自己撞上不同的延迟。
码率上也别一刀切。标准直播那路可以给到四到六兆，画质从容；快直播为了压延迟，缓冲区小，码率反而建议保守一点，三到四兆更稳。这跟直觉相反，但低延迟协议对码率抖动的容忍度更低。
选之前先问三个问题
我一般让客户先回答三件事，答案出来了选项自然就定了。
一，这场会有没有需要来回接话的环节？没有，标准直播就够。
二，预计峰值多少人在线？上万人的话，快直播的成本和稳定性都要重新算，可能得混着用。
三，这个内容会后还有多长的生命周期？如果要长期挂着给人看，重点其实在转点播和封面标题上，直播协议选哪个都不影响。
云直播这几年铺得很快，工信部在今年四月还专门提到要促进云直播等服务应用来帮中小企业；广东省二月的数字社会建设实施意见里，也把云直播列进了要拓展的数字文化新业态。技术能力和政策环境都不缺了，剩下的就是别把工具用错——花快直播的钱去播一场没人需要互动的报告会，这笔预算本来可以变成一位调色师。
