编程技术笔记

音视频技术1:基础介绍

#

本文主要介绍了流媒体的概念、协议与编码技术，并对点播与直播场景的差异，以及Web端支持与限制展开分析，为满足实时互动与低延迟需求提供参考。

基础概念

什么是流媒体？

流媒体是一种通过互联网实时传输音频、视频或其他多媒体内容的技术。与传统的下载模式不同，流媒体允许用户在内容未完全下载的情况下，即时播放或观看内容。它的核心特点是数据会以连续的流形式传输到用户的设备上，而不是一次性下载整个文件。

常见的流媒体应用包括视频流媒体（如 Netflix、YouTube）、音频流媒体（如 Spotify、Apple Music）以及实时直播（如 Twitch、抖音直播）。流媒体技术的优势在于节省存储空间、减少等待时间，并能够支持实时互动和广播。

流媒体指通过网络实时传输音频和视频内容。

流媒体业务可分为两类：点播（VOD, Video on Demand）与直播（Live Streaming）。

点播（VOD）指用户按需观看电影、电视剧等内容，强调高分辨率和画质，可接受一定延迟；直播（Live Streaming）则是如抖音、快手等平台的实时互动视频，更注重低延迟，对画质要求相对较低。

流媒体关键技术

在选择流媒体方案时，需要关注以下要点：

  • 传输协议（Transmission Protocol）
  • 编解码（Codec）

传输环节可分为前端（用户展示端）与后端（数据采集与处理端）。前端应优先选择设备支持广泛的协议，如 WebSocket、HTTP、WebRTC；后端则应侧重传输效率高的协议，如 RTSP、RTMP。

应用层传输协议的关键点在于时序对齐（矫正）、声画对齐，比如点播场景的暂停、播放、拖动控制；直播不存在暂停和拖动，但仍然有流控，客户端播放的画面应该是流媒体服务推送较新的帧。

当数据触达到用户后然后选择编码方式，编码影响画质、传输速度，对于特定的编码一般只有部分客户端支持。首要的选择条件是用户设备支持的编码，常见的编码有 h.264,h.265,av1。

当你选择了一个合适的传输协议和编码后，然后选择对应的工具库和组件就可以实现自己的流媒体服务了。以直播场景为例，可以选择使用 ffmpeg 采集摄像头、麦克风数据流，然后通过 rtsp 协议推送到流媒体服务器（后端），然后前端可通过 rtsp 拉流并使用 flv 组件播放。

这里的要点是：传输协议/传输控制协议并不和音视频编码强绑定，数据侧触达后选择合适的编码，最后确定具体实现的工具库和软件。

流采集软件：

  • ffmpeg
  • opencv
  • 自己实现

传输协议：数据传输方式

  • UDP、TCP
  • Websocket、HTTP、WebRTC

传输控制协议：流控制方式

  • RTMP
  • WebRTC

https://ossrs.net/lts/zh-cn/docs/v5/doc/rtmp

视频编码：

  • h.264：常见的比如 jepg 图像
  • h.265：场景的比如 heif、heic 格式的图像
  • av1
  • VP8、VP9：google 开源的图片视频编码

https://www.cnblogs.com/eguid/p/16015446.html https://zhuanlan.zhihu.com/p/534490577

直播基本架构

上传流： 音视频采集–>音视频处理–>编码–>缓存队列–>推流–>「流媒体服务器」

下载流： 请求「流媒体服务器」–>拉流–>缓存队列–>解码/转码–>音视频播放

流媒体方案

整体上后端较为通用，可以通过 ffmpeg/obs/opencv 推流到流媒体服务器，常见的客户端使用 OBS，。我们看下播放端，由于用户使用的设备影响传输协议和流控协议，不同端有不同的解决方案。

直播场景：

  1. 客户端 Android/IOS/桌面端
    1. 使用 RTMP 传输+VLC 播放器进行播放。VLC 是夸平台的播放器，通用性较好；但普遍有 2 秒左右的延迟；支持主流的编码，比如 h.264
  2. Web 客户端
    1. HTTP-FLV+flvjs。HTTP-FLV 利用 HTTP 协议传输数据，flvjs 是 bilibili 开源的 javascript 视频播放组件；支持主流的编码 h.264、aac；支持主流的浏览器；由于 HTTP 每次拉取一个视频 chunk 进行播放，存在 2 秒左右的延迟。
    2. WebRTC+HTML video 标签。比较原生的实现方式，但须自己实现 TURN Server（信令服务器）；仍然需要流媒体服务器这样的中央服务进行数据分发，否则只能实现点对点传输。延迟在 1 秒以内。
  3. 本地局域网的 Web 端，本地监看场景
    1. 如果仅仅是视频播放 MJPEG 也是一种不错的方式，但是没有声音。1）可以选择 HTTP SSE + MJPEG。利用 HTTP 长链接推送 JPEG 图片流，使用 img 标签回显画面，其原理是不断刷新 img 标签的图片；延迟可以做到 200 毫秒以下。2）也可以使用 WebSocket + MJPEG，这种方式将 HTTP PUSH 流换成 WebSocket 传输，但效果不如 HTTP SSE。
    2. WebRTC+HTML video 标签

点播场景：

  1. HLS 是比较通用方案
    1. HLS 将离线视频切割为一个个的数秒的片段，客户端可以通过 HTTP 或者 WebSocket 方式请求到
    2. 该方案有 30 秒左右的延迟，如果是实时场景请选择 RTMP 或 HTTP-FLV
    3. 其优点是通用且便于 CDN 和缓存

总结

Web 端不像客户端（Android/IOS/Windows）支持多种播放器，原因有两方面。

  1. 浏览器对于实时流传输协议支持不足，浏览器只能使用 HTTP、Websocket、WebRTC 这类应用层传输协议
  2. 浏览器内核对视频解码器的支持不足，许多工具库使用 js 自行解析，效率不高且无法充分利用 GPU。

展望，在 Web 端逐渐流行的当下，Web 端对高质量视频和 3D 场景消费需求日益增加，也涌现了一批好的工具例如threejs/webGPU/Web Assembly，未来这些工具也会让浏览器图像渲染更加高效，使用体验更加 Native。

参考：

  1. https://blog.csdn.net/Daniel_Leung/article/details/130456035
  2. https://www.ruanyifeng.com/blog/2017/05/server-sent_events.html
  3. https://ffmpeg.org
  4. https://opencv.org
Top↑