本文主要是介绍【Stream】流媒体从入门到入土 (1)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
最近工作需要学了很多流媒体相关的知识，谁能想象一个月前还是只听说过 HLS 的快乐小屁孩，现在已经背负了巨大的知识的重担了，头发也秃了几根，发际线严重后移
H.264 (AVC) vs H.265 (HEVC)
H.264 和 H.265 是两种视频编码，或者用英语叫 Video Codec / Video encoding。这和 HLS、Dash 不是一层的，HLS Dash 是属于视频传输协议，Protocol。和 FMp4、TS 也不是一层的，虽然都是协议的下一级，但它俩不一样，FMp4 TS 叫视频格式，Format，还有另一个更专业的名称叫 Container，它俩是传输时候传输的东西的外在表现，格式，后缀名，找了一张图描述编码和格式的关系：
265 > 264，H.265 肯定是要比 H.264 先进一点，先进在哪里呢，先进在它的压缩率高，H.265 是有一点算法在身上的
具体高到什么程度，放个表格对比一下：
| H.264 | H.265 | |
|---|---|---|
| HD | 640x360 at 1 Mbps 960x540 at 2 Mbps 1280x720 at 3.5 Mbps 1920x1080 at 6.5 Mbps | 640x360 at 500 Kbps 960x540 at 1 Mbps 1280x720 at 1.7 Mbps 1920x1080 at 3.2 Mbps |
| UHD | 支持但是商业上一般不用 | 1280x720 at 1.5 Mbps 1920x1080 at 3 Mbps 2560x1440 at 6.5 Mbps 3840x2160 at 12.5 Mbps |
HD 是高清，1080p，UHD 是超清，4K。这俩叫 Resolution 分辨率。里面有这么多不同的 Resolution 是因为在一个 m3u8 里面不止一条路，一般好几条，链接到第二级的 m3u8，player 根据网络情况切换不同的二级 m3u8。具体切换的边界就是上面写的 xx Mbps
可以看到，想播 1080p 的视频，H.265 只要 3.2M 就够了，H.264 得 6.5M，需求要高一倍，所以可以看作平均来说 H.265 的压缩率比 H.264 高一倍
H.265 虽然先进，但先进的东西一般兼容性不大行，尤其是老东西还能用的情况下，这点在开发中是需要仔细考虑的。不过现在好多了，至少 Chrome 终于是支持了。H.265 兼容性：https://caniuse.com/?search=AVC
Anamorphic pixels
Anamorphic pixels 的出现是有一定的历史背景的。在上世纪 90 年代那会基本 720×480，也就是 4:3，后来出现了 1920×1080，纵横比变成了 16:9 了。为了统一这俩发明了这个东西，在 4:3 上选择 0.9 pixel aspect ratio，在 16:9 上选择 1.3 pixel aspect ratio，使得它俩都能充满屏幕，最后显示的效果有点小拉伸，不过问题不大。那么为啥选择这个不上不下的数值作为基准呢，因为当时录像带是 MiniDV 标准的，后来发展到 HDV，它的分辨率是 1440×1080，以这个纵横比作为标准
但是现在基本很少用到这种东西了，设备基本不接收说你给我一个标准纵横比的，我帮你拉伸一下显示给用户，这需要一定的底层支持，不是每台设备都行的。拉伸也可以拉伸，在视频的导出前进行，导出前怎么拉伸都行，但导出出来的都要是方形像素
Framerate
帧率在不同国家有不同的标准：
- 美国和加拿大：29.97 fps
- 欧洲和澳大利亚：25 fps
- 日本：23.976 fps
- 中国：24 fps
Menifest
用 HLS 协议播放流媒体时，一般拿到的是一个 stream url，它指向一个 m3u8 文件，这个文件就称为 Master Menifest。它会写明 BANDWIDTH，CODECS，RESOLUTION 这些内容，这个一般不需要改动
在 Master Menifest 中会包含一些 Variant Manifest，也是 .m3u8，表示不同编码或尺寸的流。
Variant Manifest 里有一串 xxx.ts，这是视频的本体，称为 Media Segment Manifest。一个 Segment Manifest 一般就 5~6s，而一个 Variant Manifest 中视频加起来要大于 60s
此外，还有 Subtitle Manifest，加载字幕用，放在 Master Menifest 里
HLS
协议 RFC 8216 (https://tools.ietf.org/html/rfc8216)
HLS 是 Sessionless 的，也就是说，每次请求都是独立的，没有持久连接。这样设计的目的是为了更好地利用 HTTP 缓存和代理服务器，提高传输效率。由于没有 Session，因此 HLS 协议可以很好地支持断点续传功能。当然，这也意味着 HLS 协议需要在每次请求时重新建立 TCP 连接，可能会带来一定的开销
关于 ts 片段的时间同步，有两个概念
- PTS（Presentation Time Stamp），表示视频帧在播放时应该被呈现的时间。
- DTS（Decoding Time Stamp），表示视频帧在解码时应该被解码的时间。
PTS 和 DTS 的差异可以用来衡量视频帧的延迟，从而确保了视频帧在客户端上的正确排序和同步。
CMAF
CMAF 旨在用一种通用媒体格式来对 TS 和 FMP4 这样的视频分片进行统一
虽然有 CMAF 在，仍然还有很多 HLS 的 CP 使用 TS
LKFS / LUFS
LKFS / LUFS 代表响度，两个是一回事。LKFS 全称 Loudness K-weighted Full Scale。1 LKFS = 1 dB，不是说它俩数值一样嗷，是说它俩的“一格”一样
为什么二者单位一样但是有两个名称呢，这是因为制定这俩标准的两家组织在统一这件事上没有谈拢。。。
先写这么多，下班了，还有其他的到时候出 2
这篇关于【Stream】流媒体从入门到入土 (1)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
