学习旅程 | 学习旅程

浏览器直播点播系列

navigator.mediaDevices.getUserMedia就可以调用笔记本摄像头，在把得到的数据给到video标签即可

视频采集，比如安防行业一般用的rtmp协议推流，浏览器不支持直接接收（直接对接摄像头的推流有安全风险），需要用到中间服务器转换为fmp4、flv、hls等

中间服务器

前面采集到的视频直接通过mediaRecorder，然后设置编码和封装格式就可以转为可下载的文件了，chrome一般只支持导出为webm，vp8/vp9编码。可以自行用web版的ffmpeg转码。chrome如果内置h264编码器可能会有专利问题

常用编码格式

常用封装格式

mp4/fmp4: 兼容性最强也是最常用的，苹果和微软主导，编码格式一般是h264/h265; 音频acc。fmp4是MP4的一种进化变体，可以更好的分片，适合直播，后缀依然是.mp4
webm: google主导，专为web设计，一般是vp8/vp9/av1, 音频opus/vorbis
mkv: 几乎支持所有编码格式，支持封装多国语音和特效字幕，适合高清电影，体积大，且因为功能多，有些旧电视不支持
mov: 苹果的标准，视频编码为Apple ProRes/H264，体积偏大
flv: 直播常用，因为其延迟较低。早期只支持h264，后来非官方支持了h265

常用直播协议

rtmp(tcp): adobe开发，曾配合flash使用，推流端（主播端）的绝对标准，基于tcp协议，低延迟，浏览器并不支持
http(hls/dash): hls苹果开发的，dash是google主导的，把文件切成小片分别下载，hls的文件后缀一般是.m3u8。视频片段有.ts，.m4s
- .ts：最早的切片格式，独立可播放，但是文件头部内容较多，占用空间大，单个ts文件可以直接播放
- .m4s: apple 2016年推出的改进方案，此切片可以同时用于hls和dash，通常需要先加载一个init.mp4，没有init.mp4文件，单个m4s文件播不了
websocket/http-flv: 国内特色，利用http长连接或者websocket传输数据
webrtc(udp): 延迟极低，服务器端架构复杂，一般用于在线会议/在线教育
webtransport(http3): 最新api, 比 WebRTC 简单，比 WebSocket 快

mp4/ws-fmp4：特殊的fmp4浏览器可以直接用video标签播放

flv/ws-flv: 浏览器不能直接播放flv, 需要先把flv解封装(demux)，但是视频编码不动，然后重新封装为fmp4(remux)，再把这个fmp4加载进MediaSourceExtension，喂给video标签。重新封装一般使用flv.js

hls/dash: hls地址后缀通常是.m3u8，苹果safari直接可以video播放，chrome一般先用hls.js进行demux,remux为fmp4，再喂给mediaSource，再喂给video

ts/ws-ts: 直接的.ts文件，可以配合B站的mpegts.js播放，延迟比flv还低一些

video直接播放：fmp4
mse: mediaSourceExtension, 把文件转封装(remux)为fmp4，先喂给mediaSource，再给video
wcs: webcodecs, 先解封装(demux)，获取h264/h265视频数据，然后用VideoDecoder调用硬件解码获取视频帧VideoFrame，再直接通过canvas画出来，canvas2d就是cpu画，canvas3d(webgl)就是主要gpu运算。另外wcs还需要手动处理音视频同步
- 对比mse: mse就是视频片段，黑盒子。而wcs可以处理每一帧，常用于云游戏，视频编辑等
wasm: h264/h265解码由软件完成，比如ffmpeg(c语言编写，精简后编译为.wasm文件)，然后由canvas2d/webgl播放
wasm-simd: 多线程软解

直播技术协议列表

WebRTC 低延迟交互式直播
- 常用插件：simple-peer
HLS/FLV http拉流
- 常用插件：video.js 支持HLS/DASH
- hls.js支持HLS
- flv.js支持FLV
- Clappr支持HLS/RTMP
MPEG-DASH 和hls类似

播放器

开源版本只支持http-flv/ws-flv直播流