实时流式数据传输总览

#实时流 #直播流 #视频流 #流媒体

Review

  1. 2024-03-30

本文调研的意义和价值 #

一、现状和发展趋势 #

  1. 现状:
    • 直播应用正在高速增长，涉足泛娱乐、远程教育、在线健康等多个垂直领域。
    • 流媒体协议正在从 RTMP 向 WebRTC 等更现代化协议过渡。
    • CDN分发基础设施得到了广泛部署，提供更好的分发能力。
    • 硬件编解码性能不断提升，特别是移动端设备支持更高分辨率。
  2. 传输协议趋势:
    • WebRTC有望成为统一的实时音视频通信协议标准。
    • QUIC等新型传输协议有望替代TCP/UDP，改善实时传输体验。
    • ==CMAF==统一码流格式或将被更广泛采用。
  3. 编解码趋势:
    • AV1等新一代开源编解码器正在渗透，提升压缩率和质量。
    • 硬件加速编解码能力不断提升，允许更高分辨率/更新编码。
    • AI视频编码技术有望进一步提高编码效率。
  4. 应用趋势:
    • VR/AR 直播应用逐步普及，对高分辨率/高码率提出新要求。
    • 边缘流媒体处理架构兴起，提高传输与编解码效率。
    • 实时流与大数据/人工智能技术融合，促进智能媒体应用。
  5. 基础设施趋势:
    • 5G网络带来更低时延、更高带宽，推动实时流媒体质量提升。
    • 云服务和边缘计算基础设施持续构建部署。
    • CDN网络全球覆盖范围不断扩大，提供低延迟高可用服务。

二、前置知识 #

2.1、直播 VS 点播 #

==点播(Video on Demand， VOD)==是指用户可以根据自己的需求，在任何时间点播放预先存储的视频内容。与传统的电视广播不同，点播技术赋予了用户主动选择权，使观看视频更加个性化和自主。

点播系统的主要特点包括:

  1. 按需观看 用户可以根据个人喜好和时间安排，选择想要观看的视频节目进行点播，而不受电视节目的编排限制。
  2. 非实时传输 点播视频通常是预先编码并存储在视频服务器上的，用户点播时从服务器获取并播放视频文件，不需要实时传输。
  3. 交互操作 用户可以对视频进行开始、暂停、快进、倒带、随机播放等交互操作，获得更好的观看体验。
  4. 自适应码率 基于HTTP的点播协议如HLS、DASH支持根据网络带宽动态调整视频码率，提供流畅观看体验。

主要的点播系统架构包括：内容准备、视频编码、内容分发网络、终端播放器等模块。常用的点播协议有 HLS、DASH、Smooth Streaming等。

点播服务被广泛应用于视频网站、网络电视、网络教育、企业培训等领域，满足了用户按需观看视频内容的需求，方便灵活且高度个性化。

==直播(Live Streaming)==是指将实时采集的视频音频数据经过编码直接传输到网络上，供观众实时观看的一种技术方式。

直播的主要特点包括:

  1. 实时性 直播数据从采集、编码到网络传输，整个过程都是实时进行的，观众可以实时观看到视频内容。时延较低，通常为几秒钟。
  2. 连续传输 直播数据是一个连续不间断的数据流，类似于传统电视信号，要求网络具有足够大的带宽支持。
  3. 即时互动 观众可以通过弹幕、实时评论等方式与主播实时互动，直播具有良好的现场沉浸感。
  4. 实时编码 直播视频需要经过实时编码处理，降低码率适应网络传输，编码复杂度高。

常见的直播系统架构包括：视频采集、编码器、流媒体服务器、CDN分发网络、播放器等模块。主要的直播协议有 RTMP、RTSP、HTTP-FLV、HLS 等。

直播技术广泛应用于新闻现场直播、在线教育、游戏直播、演出直播等领域。随着互联网和移动通信技术的发展，直播正成为重要的信息传播和互动方式。相比点播，直播对实时性、带宽等要求更高，技术实现复杂度也更大。

2.2、码率 #

==码率(Bit Rate)==是指数字视频或音频数据在单位时间内的比特量，单位通常为比特/秒(bit/s)。码率反映了视频/音频编码数据的精细程度和质量，是衡量视频压缩效率的重要指标。

码率主要由以下几个方面决定:

  1. 分辨率 分辨率越高，每一帧图像所包含的像素数就越多，对应需要更高的码率来承载。
  2. 帧率 每秒钟传输的视频帧数越多，所需的码率就越高。
  3. 图像复杂度 运动剧烈、细节丰富的画面相比简单的画面需要更高的码率。
  4. 编码器性能 编码算法和编码器性能的差异会影响相同质量所需的码率。
  5. 音频码率 音频码率占总码率的一小部分，但也会产生一定影响。

通常来说:

  • 720p视频的码率在1-4Mbps
  • 1080p视频的码率在3-8Mbps
  • 4K视频的码率在10-40Mbps

码率过低会导致画面质量下降、出现==马赫现象==等。码率过高则会浪费带宽和存储空间。因此需要根据具体应用场景，选择合理的码率范围，在视频质量和数据量之间权衡。码率控制也是视频编码中一个重要的优化点。

码率单位时间内取样率越大，精度就越高，处理出来的文件就越接近原始文件。
帧率对视频来说，帧率对应这观看卡顿。
帧率越高，流畅度越高，低帧率会造成视觉卡顿。
压缩率经过压缩后文件的大小 / 原始文件的大小 * 100% = 压缩率。
编码压缩越小越好，但压得越小，解压时间
分辨率用于度量图像内数据量多少的一个参数，和视频清晰度息息相关。
采样率音频采样率是指录音设备在一秒钟内对声音信号的采样次数，
采样频率越高声音的还原就越真实越自然。
采样大小一秒钟所采的样本数为比特率，每个样本中信息的比特数就是位深，
即采样精度，单位为Bit。

2.3、流媒体协议 vs 内容分发协议 #

  1. 实时性
    • 流媒体协议(RTMP、RTSP、WebRTC等)主要用于实时传输，对延时要求较高。
    • 内容分发协议(HLS、DASH等)通常用于点播场景，允许一定的延时。
  2. 传输方式
    • 流媒体协议直接在客户端和服务器之间建立连接进行数据流传输。
    • 内容分发协议通常基于HTTP，视频内容被切分为小文件，客户端拉取并缓存播放。
  3. 网络要求
    • 流媒体协议对网络环境要求较高，需要较低的延迟和较高的带宽。
    • 内容分发协议更适应动态网络环境，可根据带宽情况自适应调整码率。
  4. 应用场景
    • 流媒体协议主要应用于在线直播、视频会议等实时场景。
    • 内容分发协议更适用于视频点播、网课等可接受一定延迟的场景。
  5. 安全性
    • 传统流媒体协议如RTMP、RTSP一般没有安全传输机制。
    • 内容分发协议基于HTTP，可以利用加密等Web安全机制。
  6. 拓展性
    • 流媒体协议部署相对复杂，扩展能力较差。
    • 内容分发协议依赖于HTTP基础设施，扩展性和横向扩展能力更强。

三、视频传输协议调研 #

3.1、流媒体协议 #

  • RTSP(Real-Time Streaming Protocol)
    • 建立和控制流媒体会话
    • 客户端与服务器协作传输数据
  • RTP(Real-time Transport Protocol)
    • 定义封装格式
    • 数据源多路复用/解复用
  • RTCP(RTP Control Protocol)
    • 监控数据传输质量
    • 同步多媒体流
  • WebRTC（Web Real-Time Communication）
    • 提供网页浏览器之间的实时通信
    • 支持音视频、数据等多种通信
    • 采用VP8/H.264视频编解码
  • RTMP（Real-Time Messaging Protocol）推流端广泛使用，客户端不再支持。
  • HTTP-FLV：
    • HTTP-FLV是一种将FLV(Flash Video)格式的视频通过HTTP协议进行传输的技术方案。
    • HTTP长连接
    • 内容延迟 1 ~ 3S
  • HLS（HTTP Live Streaming）由苹果公司提出的基于 HTTP 的流媒体网络传输协议
  • MPEG-DASH (Dynamic Adaptive Streaming over HTTP)
  • Smooth Streaming

3.1.1、RTSP #

现在摄像头的实时视频流普遍采用的是 RTSP 协议，而前端并不能直接播放 RTSP 的视频流。

RTSP（Real-Time Stream Protocol），是 TCP/UDP 协议体系中的一个应用层协议，跟 HTTP 处在同一层。RTSP 在体系结构上位于 RTP 和RTCP 之上，它使用 TCP 或者 RTP 完成数据传输。RTSP 实时效果非常好，适合视频聊天、视频监控等方向。

目前实时流技术的几种方向：

  • RTSP -> RTMP
  • RTSP -> HLS
  • RTSP -> RTMP -> HTTP-FLV

各个直播平台基本上都放弃了以上这些比较传统的方式，使用了云服务商提供的 CDN

3.1.2、RTMP #

RTMP(Real-Time Messaging Protocol)是一种设计用于在Adobe Flash播放器和流媒体服务器之间传输音视频数据的专有协议。它的兼容性主要取决于以下几个方面:

  1. 浏览器支持
    • 由于安全性和专利问题，现代浏览器默认不再支持RTMP协议。
    • 但可以通过安装Flash插件或使用像WebRTC等新技术来支持RTMP流。
  2. 移动端支持
    • 原生Android和iOS系统均不支持RTMP，需要借助第三方播放器应用。
    • 部分播放器应用也逐步放弃对RTMP的支持。
  3. 服务器支持
    • 常见的RTMP服务器包括Nginx、Adobe Media Server、Red5等。
    • 由于RTMP协议的封闭性，服务器与客户端之间需要相互兼容，限制了灵活性。
  4. 编码支持
    • RTMP主要支持H.264、AAC等常见编码格式。
    • 但不支持较新的编码如H.265、AV1等，需要进行转码。

总的来说，作为一种专有协议，RTMP在现代Web环境中的兼容性正在逐步降低。未来更多场景会转向 WebRTC 或HTTP流媒体协议如 HLS 和 DASH，以获得更好的通用性和安全性。但RTMP在较为传统的视频直播系统中仍有一定应用。

H5实现拉流和解码方案 #
  1. 播放器插件 某些浏览器允许安装专有的插件，如Flash插件，从而使用ActionScript来加载RTMP流并进行解码播放。但这种做法在现代浏览器中越来越少见。
  2. WebAssembly + FFmpeg 使用WebAssembly将FFmpeg移植到浏览器，通过FFmpeg解码RTMP流。但性能较低，且需要复杂的编译流程。
  3. WebRTC 结合WebRTC等新技术,在服务器端将RTMP转换为WebRTC协议，在浏览器端通过WebRTC接收和播放。但这增加了系统复杂度。
  4. MSE + MP4 将服务器端的RTMP流转换为MP4容器的分段文件，通过Media Source Extension在H5播放这些分段文件。但无法做到真正意义上的实时播放。
Flutter实现拉流和解码方案 #

Flutter 作为一个跨平台的移动应用开发框架,本身并不提供直接解码 RTMP 流的能力。

  1. 使用平台视图集成原生播放器 在Flutter应用中集成原生的视频播放器控件，利用平台视图(Platform View)的机制在 Android 和 iOS 两端分别实现 RTMP 解码和播放。这种方式需要分别为两个平台编写原生代码，开发成本较高，但可定制性强。
  2. WebRTC 方案 实现实时音视频通信，可以考虑使用 WebRTC 技术。Flutter 有一些支持 WebRTC 的插件，如 flutter-webrtc。通过 WebRTC 可以实现点对点的 RTMP 传输。
  3. FFmpeg 方案 在 Flutter 应用中集成 FFmpeg，利用其强大的多媒体处理能力自行解码 RTMP 流。这需要对 FFmpeg 有一定了解，并使用 Flutter 的平台通道将其集成到应用中。

3.1.3、WebRTC #

WebRTC(Web Real-Time Communication)是一种支持网页浏览器进行实时语音/视频/数据通信的开放标准技术。关于WebRTC的浏览器兼容性，主要有以下几点:

  1. 桌面浏览器支持
    • 主流桌面浏览器均已原生支持WebRTC，包括Chrome、Firefox、Safari、Edge等。
    • 对于旧版本浏览器，需要检查具体的WebRTC支持情况。
  2. 移动浏览器支持
    • 主流移动端浏览器也基本都支持WebRTC，如Android浏览器(基于Chrome)、Safari(iOS)等。
    • 低端Android系统的兼容性可能会有所欠缺。
  3. 兼容性检测
    • 可以使用 navigator.getUserMedia 或 RTCPeerConnection 来检测浏览器对WebRTC的支持情况。
    • 也可使用一些开源库(如adapter.js)来自动适配不同浏览器的WebRTC实现差异。
  4. 防火墙/NAT穿越
    • WebRTC为了实现直连通信，需要一定的NAT穿越能力。
    • 不同浏览器对STUN/TURN服务器的支持程度不一，需要根据情况进行设置。
  5. 编解码器支持
    • 不同浏览器对视频/音频编解码器的支持也有所不同。
    • 通常情况下，最好使用正交的编解码器(如VP8/H.264)来确保最大限度的兼容性。

总的来说，主流桌面和移动端浏览器对WebRTC已有了很好的支持，但对于一些旧版本浏览器、特殊网络环境等，需要进行具体的兼容性测试和相应处理。与此同时，WebRTC作为开放标准也在不断进化中，向更广泛的终端和场景覆盖。

WebRTC在Android和iOS移动端的兼容性情况如下:

Android:

  • Android 4.0+版本基本上都支持WebRTC，但对较老版本的支持程度会逐渐降低。
  • Google自家的Chrome浏览器在Android上对WebRTC有很好的支持。
  • 其他第三方浏览器如Firefox、Opera等，WebRTC支持情况则需要具体检查。
  • 对于Android应用开发，可以使用WebRTC Native APIs进行音视频通信，兼容性较好。

iOS:

  • iOS 11.0+版本的Safari、Chrome、Firefox等主流浏览器都原生支持WebRTC。
  • 对于iOS应用开发，由于没有公开的WebRTC Native APIs，只能通过UIWebView/WKWebView来使用WebRTC。
  • 从iOS 12.1.1开始，苹果放开了H.264/AAC等视频/音频编码的硬件加速能力给第三方应用。
  • 但是对于更新的Codec如VP9/AV1等，仍需要手动实现软件解码。

3.1.4、MPEG-DASH #

Dynamic Adaptive Streaming over HTTP ( DASH) is an adaptive streaming protocol. This means that it allows for a video stream to switch between bit rates on the basis of network performance, in order to keep a video playing.

3.1.5、HLS #

HLS(HTTP Live Streaming)是一种适用于互联网的流媒体传输协议，它由Apple公司提出并实现。HLS主要特点如下:

  1. 基于HTTP协议 HLS通过HTTP协议在客户端和服务器之间传输数据，不再需要使用专用的流媒体协议。这使得它可以很好地适应现有的网络基础设施和防火墙。
  2. 自适应比特率 视频文件被编码为一系列不同码率的TS分片，客户端可以根据当前网络状况智能选择合适的码率播放，提高移动环境下的用户体验。
  3. 支持直播和点播 HLS既支持传统的点播播放，也可以支持直播流场景。
  4. 容错和重连能力 基于HTTP协议的分段传输和重试机制，使视频播放更容错，网络抖动时可自动重连。
  5. 简化部署 受益于HTTP协议的普及和CDN的支持，HLS在部署时更加简单且有良好的扩展性。

HLS工作流程简述:

  1. 视频内容根据码率被编码为包含元数据的 MPEG-TS 分片
  2. 生成描述视频的播放列表文件(.m3u8)
  3. 客户端下载播放列表，解析后根据当前带宽下载合适码率的TS分片进行播放
  4. 客户端可在直播或点播场景中无缝切换码率，适应网络变化

3.2、内容分发协议 #

  • HLS(HTTP Live Streaming)
    • 基于HTTP传输，HTTP短连接
    • 将视频分割成多个小文件缓存
    • 内容延迟 > 10S
  • DASH(Dynamic Adaptive Streaming over HTTP)
    • 基于HTTP传输
    • 根据网络条件自适应码率/分辨率

四、实现实时流整体架构 #

Common MIME types

Video TypeExtensionMIME Type
Flash.flvvideo/x-flv
MPEG-4.mp4video/mp4
iPhone Index.m3u8application/x-mpegURL
application/vnd.apple.mpegurl
iPhone Segment.tsvideo/mp2t
3GP Mobile.3gpvideo/3gpp
QuickTime.movvideo/quicktime
A/V Interleave.avivideo/x-msvideo
Windows Media.wmvvideo/x-ms-wmv

相关依赖 flv.js HTML5 FLV Player hls.js HLS.js is a JavaScript library that plays HLS in browsers with support for MSE. video.js open source HTML5 video player mux.js Lightweight utilities for inspecting and manipulating video container formats. shaka-player JavaScript player library / DASH & HLS client / MSE-EME player dash.js A reference client implementation for the playback of MPEG DASH via Javascript and compliant browsers. plyr A simple HTML5, YouTube and Vimeo player. plyr-react A simple, accessible and customisable react media player for Video, Audio, YouTube and Vimeo.

Deploying HTTP Live Streaming

4.1、点播场景 #

HLS + H.264 + MP4/AVI

生成 m3u8 文件和 ts 文件

ffmpeg -i input.mp4 -codec:v libx264 -codec:a aac -f hls -hls_time 6 -hls_playlist_type vod -hls_segment_filename "output-%03d.ts" output.m3u8

Server

router.get('/api/:id', function (req, res, next) {
  const { id } = req.params;
  console.log('id', id);
  const m3u8FilePath = path.join(__dirname, '../assets/ccc/', id);

  if (fs.existsSync(m3u8FilePath)) {
    console.log('exist')
  } else {
    console.log('not exist')
  }

  fs.readFile(m3u8FilePath, 'utf8', (err, data) => {
    if (err) {
      console.error('Error reading M3U8 file:', err);
      res.status(500).send('Error reading M3U8 file');
      return;
    }

    if (/\.m3u8$/.test(m3u8FilePath)) {
      // Send the M3U8 file
      res.set('Content-Type', 'application/vnd.apple.mpegurl');
      res.send(data);
    } else if (/\.ts$/.test(m3u8FilePath)) {
      res.setHeader('Content-Type', 'video/mp2t'); // TS 文件的 MIME 类型
      res.setHeader('Cache-Control', 'no-cache'); // 禁用浏览器缓存
      // res.send(data);
      const fileStream = fs.createReadStream(m3u8FilePath);
      fileStream.pipe(res);
    } else {
      res.send({
        code: 400,
        data: 'no',
        msg: 'not support'
      })
    }
  });
});

Client

import { useEffect, useRef } from 'react';
import Hls from 'hls.js';
import './App.css';
import Plyr, { PlyrProps } from 'plyr-react';
import 'plyr-react/plyr.css';

function App() {
  const videoRef = useRef(null);

  useEffect(() => {
    loadVideo();
  }, []);

  async function loadVideo() {
    const video = document.getElementById('plyr') as HTMLVideoElement;
    const hls = new Hls();
    hls.loadSource('http://localhost:3000/api/ccc.m3u8');
    // https://content.jwplatform.com/manifests/vM7nH0Kl.m3u8
    hls.attachMedia(video);

    // @ts-expect-error init error
    videoRef.current!.plyr.media = video;
  }

  return (
    <div>
      <h3>Video</h3>
      <Plyr
        id='plyr'
        options={{ volume: 0.1, muted: false }}
        source={{} as PlyrProps['source']}
        ref={videoRef}
      />
    </div>
  );
}

export default App;

4.2、直播/实时场景 #

  1. WebRTC + H.264 + WebM
  2. MPEG-DASH + AV1 + TS
  3. HTTP-HLV + H.264 + MP4

五、实时流优化方案 #

5.1、实时流缓存方案 #

  1. 边缘缓存
    • 在CDN边缘节点暂存直播流的一定时间窗口数据。
    • 优点是可降低回源流量，但存储空间和时间窗口有限。
  2. 服务端缓存
    • 在直播服务器端利用磁盘空间或内存缓存直播流数据。
    • 可支持较长时间回放，但服务器成本较高。
  3. 对象存储
    • 将直播流实时存入对象存储(如AWS S3)。
    • 可长期保存，成本较低，但实时性能有一定延迟。
  4. 设计缓存层
    • 在架构中单独设计缓存层，如Redis/Kafka集群。
    • 提供高效实时读写能力，但引入新的系统复杂度。
  5. 视频云服务
    • 利用第三方视频云的直播录制、时移等服务。
    • 简化开发，功能可扩展性强，但需付费。

5.2、加速实时流数据传输方案 #

  1. CDN分发加速
    • 利用CDN服务商的全球节点分发网络，将直播源站数据就近传递给用户。
    • 合理规划CDN边缘节点的存储和缓存策略，降低回源率。
  2. P2P传输协议
    • 采用P2P协议在用户之间转发流媒体数据，减轻源站和CDN的带宽压力。
    • 如WebRTC的数据通道可实现浏览器之间P2P传输。
  3. 多码率流适配
    • 根据用户网络情况，动态选择合适的码率流进行自适应传输。
    • 如MPEG-DASH、HLS支持切换不同码率的分辨率/码率。
  4. 传输协议优化
    • UDP比TCP在直播场景下有更低的时延和更高的吞吐率。
    • 如基于UDP的RTP/RTCP有时延和丢包补偿机制。
  5. 网络传输优化
    • 减少带宽抖动、降低网络延迟、避免网络拥塞等。
    • 可采用多线路/多码流传输等方案提高鲁棒性。
  6. 边缘节点分流
    • 在边缘节点进行并发分流，避免中心节点压力过大。
    • 部分场景可结合边缘转码功能，降低源站压力。
  7. 客户端优化
    • 减小客户端获取和解码视频数据的时延。
    • 提高缓存\预加载\渲染等策略的合理性。

六、扩展知识 #

6.1、主流视频容器/封装格式 #

  1. MP4
    • 基于ISO标准的通用多媒体容器
    • 支持多种视频编码(H.264/H.265/AV1等)和 AAC 音频编码
    • ==不支持流式传输==，具有流式传输的是 fMP4
    • 被广泛支持，适用于网络传输和本地播放
  2. MKV (Matroska)
    • 开放且高度扩展的多媒体容器格式
    • 支持任意视频/音频编解码器和元数据
    • 具备更好的章节/字幕等功能支持
    • 主要用于本地存储和播放
  3. WebM
    • 开放的基于 Matroska 的网络传输容器
    • 默认使用 VP9/VP8 视频和 Opus/Vorbis 音频编码
    • ==流式传输性能优秀==，适合Web应用
    • ==HTML5原生支持==
  4. FLV (Flash Video)
    • Adobe开发的用于网络传输的容器格式
    • 只支持 H.264/H.263 视频和 MP3/AAC 音频
    • 曾在Flash时代广泛使用
    • 现已被MP4和WebM等格式替代
    • 支持流式传输
  5. MPEG-TS (Transport Stream)
    • MPEG系列标准中定义的用于传输的容器
    • 支持多种编解码器和多路复用
    • 常用于数字电视/流媒体广播系统
    • 对延时和时间戳有严格要求
  6. AVI (Audio Video Interleaved)
    • 老牌的Microsoft多媒体容器
    • 支持多种旧式编解码器
    • 主要用于本地文件播放和存储
  7. Ogg 使用 Theora 视频编解码器和 Vorbis 音频编解码器，==不支持流式传输==。
  8. TS （Transport Stream）传输流，多个TS片段可以被播放器无缝拼接进行播放，无需等待重新载入。

6.2、主流视频编码格式 #

将视频像素数据压缩成为视频码流，从而降低视频的数据量。如果视频不经过压缩编码的话，体积通常是非常大的，一部电影可能就要上百G的空间

  1. H.264/AVC
    • 广泛应用的行业标准
    • 较高编码效率，适合中低码率场景
    • 支持多种编码Profile，可平衡质量和复杂度
    • 硬件解码支持较好，但专利费用较高
    • 目前最流行的编码格式
  2. H.265/HEVC
    • 较H.264节省40%-50%码率
    • 编码复杂度较高，硬件编码解码需求高
    • 逐步替代H.264在高分辨率、高码率场景
    • 专利费用较高，目前普及率较低
  3. VP9
    • 谷歌开源编码格式(VP9是WebM Project开发的下一代视频编码格式 )，免版税
    • 质量和压缩率接近H.265
    • WebRTC支持良好，硬件支持有限
    • AV1 将逐步替代其地位
  4. AV1 🥷
    • AOM（Alliance for Open Media，开放媒体联盟）制定的一个开源、免版权费的视频编码格式
    • 压缩率超H.265，适合4K/8K等高分辨率场景
    • 硬件解码支持正在开发中
    • 编码复杂度高，需先进硬件编码器
  5. AVC/AV2 🥷
    • MPEG最新视频编码探索项目
    • 旨在比AV1降低10%码率
    • 采用基于AI的编解码技术
    • 距离商用化尚需数年时间
  6. VP8/Theora
    • 早期的开源编码格式
    • VP8支持度好，Theora几乎被淘汰
    • 编码质量和效率均不如现代编码器

6.3、视频编解码转换工具 #

  1. FFmpeg 🥷
    • 跨平台的开源多媒体框架
    • 支持众多编解码器和容器格式
    • 命令行工具，功能强大但使用复杂
    • 支持流媒体、滤镜、GPU加速等特性
  2. HandBrake 🥷
    • 开源的视频转码工具
    • 界面友好，易于上手使用
    • 转码质量较高，支持批处理
    • 主要针对常见格式转换
  3. Adobe Media Encoder
    • Adobe多媒体套件的一部分
    • 支持各种专业级编解码器
    • 界面操作直观，功能插件丰富
    • 价格较高，需结合其他Adobe工具
  4. Vidcoder
    • 免费的视频编码、转码软件
    • 支持CUDA/AMD加速
    • 格式支持全面，操作简单
    • 缺乏高级编码特性
  5. Audacity — Free Audio Editor and Recorder
  6. Miro — Free, open-source music and video player
  7. Firefogg — Video and Audio encoding for Firefox
  8. Libav — Comprehensive command line encoder
  9. Vid.ly — Video player, transcoding and delivery
  10. Internet Archive — Free transcoding and storage

6.4、音频编码格式 #

PCM脉冲编码调制(Pulse Code Modulation,PCM)，PCM是数字通信的编码方式之一。
AAC-LC(MPEG AAC Low Complexity)低复杂度编码解码器（AAC-LC — 低复杂度高级音频编码）是低比特率、优质音频 的高性能音频编码解码器。
AAC-LD（又名AAC低延迟或MPEG-4低延迟音频编码器），为电话会议和OTT服务量身打造的低延迟音频编解码器
LAC（Free Lossless Audio Codec）免费无损音频编解码器。是一套著名的自由音频压缩编码，其特点是无损压缩。  2012年以来它已被很多软件及硬件音频产品（如CD等）所支持。

6.4、常用服务器  #

  1. SRS：一款国人开发的优秀开源流媒体服务器系统
  2. BMS: 也是一款流媒体服务器系统，但不开源，是SRS的商业版，比SRS功能更多
  3. Nginx: 免费开源Web服务器，常用来配置流媒体服务器。

6.5 解封装 #

demuxing（分离）：从视频流、音频流，字幕流合成的文件(容器格式（FLV，TS）)中， 分解出视频、音频或字幕，各自进行解码。

6.6、解码介绍 #

硬解码 用GPU来解码，减少CPU运算 优点：播放流畅、低功耗，解码速度快 缺点：兼容不好

软解码 用CPU来解码 优点：兼容好 缺点：加大CPU负担，耗电增加、没有硬解码流畅，解码速度相对慢

参考 #

  1. 前端实时流探索记
  2. Media Source Extensions
  3. https://github.com/pravega/pravega
  4. 前端流媒体播放从入门到入坑
  5. 做直播，我们是认真的：Web音视频串流与WebRTC
  6. 【前端】如何流畅地播放视频
  7. 一张图概括淘宝直播背后的前端技术