Android中的音视频(2)|青训营笔记这是我参与「第四届青训营」笔记创作活动的的第8天文章记录音视频内容的第二部

这是我参与「第四届青训营」笔记创作活动的的第8天

直播推拉流

封装格式

按照一定的规则，把视频数据、音频数据放到一个文件中

MP4

容器协议

Moov：Movie Box，存储 mp4 的 metadata，一般位于mp4文件的开头。(为达到秒播效果，会记录很多信息在该文件)

mvhd：Movie Header Box，mp4文件的整体信息，比如创建时间、文件时长等

trak：Track Box，一个mp4可以包含一个或多个轨道（比如视频轨道、音频轨道）

Stbl：Sample Table Box

包含了这些媒体数据的索引以及时间信息

较大的层级结构

FLV

流式文件

FLV是一个二进制文件，由文件头（FLV header）和很多tag组成。

tag又可以分成三类:audio,video,script，分别代表音频流，视频流，脚本流（关键字或者文件信息之类）

由于没有一个记录信息的头的结构，所以在一开始不知道会播多久，且数据是链式可以一节节用Tag拼装起来，那么就可以用cdn不断分发下去，所以非常适合直播时候使用。

由于缺少头信息，所以在一般的播放器中，Flv是不支持拖拽的。需要支持拖拽的话就得遍历所有Tag之后记录其时间戳才能实现拖拽

CDN转发网络

定义：建立并覆盖在Internet 之上，由分布在不同区域的边缘节点服务器群组成的分布式网络。通过智能调度将用户请求到最接近用户的服务节点，降低用户访问延迟，提升可用性。

边缘节点：指在靠近用户的网络边缘侧构建的业务平台，提供存储、计算、网络等资源，将部分关键业务应用下沉到接入网络边缘，以减少网络传输和多级转发带来的宽度和时延损耗

点播：视频播放
直播看播：观众观看直播
推流：主播将数据发送到CDN网络
拉流：观众从CDN拉去直播数据

通信方案

推拉流协议方案

RTMP

推流

RTMP：实时消息协议（Real-Time Messaging Protocol）

也称实时消息传输协议，是最初由Macromedia为通过互联网在Flash播放器与一个服务器之间传输流媒体、音频、视频和数据而开发的一个专有协议。后被 Adobe公司收购。

优势：

•基于 tcp 协议

•技术成熟，FFmpeg 项目中有 rtmp 库

•低延迟(5-10s)

劣势：

•停止更新

•规范上没有支持 H265

•使用 1935 端口，会被防火墙阻碍

当我们获取到RTMP数据的时候，褪去协议层，就可以很方便的直接得到FLV视频数据

拉流

为解决上述的缺点问题，拉流端使用下面的协议，该协议的封装可以在CDN完成然后再供用户拉流

HTTP-FLV Flash Video（简称FLV），是一种网络视频格式，用作流媒体格式。

协议友好，格式简单，便于分发。由于几乎所有设备都会支持HTTP请求协议，那么这个协议对拉流极为友好，也是业内使用最多的协议。

不转码的情况下直接转发即可，延迟较低

HLS

HTTP Live Streaming，缩写为HLS，是由苹果公司提出基于HTTP的流媒体网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。

在开始一个流媒体会话时，客户端会下载一个包含元数据的扩展 M3U (m3u8) 播放列表文件，用于寻找可用的媒体流。