共 3 篇相关文章
这篇讲的是HLS协议在直播与点播场景中的应用。作者从基本概念切入，梳理了推流与拉流的过程，并点明HLS是拉流环节的关键协议。 HLS由苹果提出，核心特点是将连续流切分为小段TS文件，通过m3u8索引文件进行分发。它的优势在于完全基于HTTP，易于利用CDN分发，且支持客户端根据网络状况自适应选择码率。不过，这种分段机制也带来了延迟较高的缺点。文章详细说明了其工作模式：客户端先下载m3u8索引，再按列表顺序请求并播放TS片段。对于点播，文件列表固定；对于直播，索引文件则持续更新。 在实践部分，文章给出了用ffmpeg创建HLS流的命令示例，并探讨了加密与防盗链。HLS支持AES-128加密，但静态密钥安全性不足，更可靠的方案是结合用户信息动态生成密钥。最后，文章将HLS与新兴的MPEG-DASH标准进行了对比，指出DASH使用MPD描述文件且更倾向于支持fMP4分片，是国内如B站等平台选用的方案之一。 整篇内容从原理到实践，清晰展现了HLS协议的工作全貌与技术权衡。
这篇讲的是直播技术里一个很实际的问题：如何实现低延时？作者从RTMP和HLS这两种主流协议入手，直接点明了核心差异——HLS延时通常在10秒以上，而RTMP则能实现秒级甚至更低的延时。 文章详细拆解了RTMP的“低延时”优势。在理想网络下，实测RTMP延时可以低至0.8秒左右，这对于互动直播、视频会议、监控等场景已经足够。但作者也坦诚地指出了RTMP的弱点，即基于TCP会导致“累积延迟”，在网络波动时缓冲区会像滚雪球一样增大。文中还深入探讨了一个关键技术点——GOP（关键帧间隔）缓存的影响：为了快速启动播放，服务器通常会缓存上一个GOP，这直接增加了延时；而通过调整编码器GOP长度或使用SRS关闭GOP缓存，则可以在这两者间进行权衡。 更难得的是，文章没有停留在理论对比，而是提供了具体的延时测量方法（如使用手机秒表），并分析了影响延时的多个实际因素，比如服务器性能、客户端缓冲区设置（如flash的bufferTime设为10秒则延时至少10秒）、以及不同流媒体服务器实现（如Nginx-Rtmp）的差异。这些细节让结论非常扎实，对需要搭建或优化直播系统的工程师来说，是一份清晰的实践参考。
这篇讲的是流媒体协议的选择问题，作者从常见的HTTP渐进下载和基于RTSP/RTP的实时流媒体这两种方案出发，对它们进行了对比。文章指出，虽然二者都能用于视频传输，但实现机制和适用场景有本质不同。作者倾向于推荐更便捷的HTTP渐进下载方式，并特别点明了苹果公司推出的HTTP Live Streaming（HLS）作为该领域的典型代表。 文章梳理了HLS的背景：它最初是为iPhone、iPad等移动设备量身定制的流媒体技术，但如今其应用场景已扩展到桌面端。一个重要的技术进展是，HLS已获得HTML5的原生支持，这意味着它在现代Web开发中具备了更广泛的基础和便利性。对于正在选型或学习视频流技术的读者来说，这篇文章厘清了主流协议间的差异，并给出了一个明确且实践性强的推荐方向。
