spartazhc's blog

0%

Streaming Tech

发表于 分类于 阅读次数： Valine：
本文字数： 10k 阅读时长 ≈ 9 分钟

因为这周在Tech Forum的Presentation，查找了很多关于Streaming的资料，特别是关于协议的选择，还是学到了很多知识的。这篇Blog一部分是当时准备讲稿的留存，另一部分是之后的完善。因为Bitmovin和WOWZA他们的Blog和Report的质量都相当高，所以这篇某种意义上其只是拾人牙慧的收集整理而已。

Streaming System

image-20191127131654775

一个常规的直播系统（仅考虑音视频内容相关）有以下部分构成：

  • 采集端：采集音视频、前处理、编码、封装、推流到服务端
  • 服务端：转码、推送到边缘端、CDN
  • 客户端：拉流、解码播放
  • 一般来说，在采集端选择RTMP之类的传统协议推流到媒体服务器，转码后，用基于HTTP的技术推给客户端。

Streaming Types

流媒体的解决方案主要与延迟要求相关，不同应用场景对延迟要求不同，极大影响了实现的技术构成。

应用按延迟要求分类：

  • 点播：对延迟没有要求
  • 直播
    • 普通直播：延迟要求低
    • 体育赛事直播：延迟要求较高，与广播延迟在同一级别
    • 互动直播：延迟要求高
  • 电话会议：延迟要求最严格
  • 来自EX MACHINA的一张图

0_sjCFsr2rLPitGrka

Streaming Protocols

img

Traditional Stateful Streaming Protocols

RTMP (Real-Time Messaging Protocol)

  • 将音视频文件分拆成小包，基于TCP传输。

  • 是Adobe 的私有协议，Adobe暂停了对FLV与RTMP标准的更新

  • 一般传输的是 flv，f4v 格式流

  • RTMP+flv的组合对Codec有限制，只支持到h.264

  • RTMP根本无法应对当今的贡献挑战。（参考alternatives-rtmp-getting-streams-internet）原因如下：

    • 对RTMP的支持正在减弱，CDN 正在淘汰RTMP入口点，转而使用HLS和MPEG-DASH
    • RTMP 不支持 HEVC 编码的流，当然更不可能支持AV1。
    • RTMP 无法优雅地支持高分辨率以及VR，360视频等，原因有：
      • 缺乏HEVC等高级Codec支持。
      • 由于带宽限制，RTMP无法以高比特率使用 。
    • RTMP 使用TCP端口，通过防火墙不便。
    • RTMP 遇到安全性，多语言支持和广告插入支持方面的问题。

RTSP (Real Time Streaming Protocol)

  • 网络控制协议，专为娱乐和通信系统的使用，以控制流媒体服务器该协议用于在端点之间建立和控制媒体会话。媒体服务器的客户端发出VHS样式的命令，例如播放，录制和暂停，以促进对从服务器到客户端（视频点播）或从客户端到服务器（语音录制）的媒体流进行实时控制。（不是很懂，可能要看一点具体的才知道）
  • RTSP标准由IETF制定，1998年发布了RFC 2326，2016年发布了RTSP 2.0 RFC 7826, RTSP 2.0给予RTSP 1.0但是不向后兼容。
  • RTSP只是作为协议，具体的RTSP server实现使用 Real-time Transport Protocol (RTP) 和 Real-time Control Protocol (RTCP) 实现媒体流的交付。RTP和RTCP也是IETF系列。
    • RTP基于UDP，用于媒体流（音视频）的传输。
    • RTCP作为控制流用于监控传输状态、QOS及同步。
  • RTSP是一种协议，允许创建流会话并配置RTP传递的详细信息，是控制协议。RTP是具体打包音频和视频帧并将其发送到客户端的协议。
  • 作为标准，RTSP支持可以用SDP (Session Description Protocol) 描述的所有视频格式。
    • 所以问题在于特定RTSP服务器实现是否支持所有这些格式
    • SDP对视频格式的支持性
  • 整体感觉是RTSP现在在直播上用的比较少，并不清楚RTSP 2.0的使用。

New Technologies

SRT (Secure Reliable Transport)

由Haivision 和 Wowza共同创建，并于2017开源。SRT通过动态适应传输端点之间的实时网络状况，优化了跨不可预测的网络（例如Internet）的流传输性能。这有助于最小化抖动和带宽变化的影响，而纠错机制有助于最大程度地减少数据包丢失。

它具备以下特点：

  • 编解码器无关

  • 旨在解决视频在公共互联网（网络质量不好）的分发挑战

  • 安全方面：SRT支持AES加密，保障端到端的视频传输安全;

  • 可靠性方面：SRT通过前向纠正技术(FEC)保证传输的稳定性;

  • 低延迟方面：SRT底层使用UDT协议，UDT协议是一个老牌的基于UDP的可靠传输协议，当然原生的UDT传输延迟是比较高的，SRT在此基础上做了不少的拥塞控制策略的相关优化以降低传输延时。

SRT协议的缺陷：

  • 协议复杂度较高
  • 丢包场景下速度退避较大

WebRTC

HTTP-Based Adaptive Streaming Protocols

所有现有的自适应HTTP流技术，例如专有的 Adobe HTTP动态流（HDS），Apple HTTP实时流（HLS），Microsoft平滑流（MSS），以及唯一的国际标准化解决方案 MPEG动态HTTP自适应流（MPEG-DASH） 遵循几乎相同的原则。

基本思想是生成相同内容的多个版本（例如，不同的比特率或空间分辨率），并将这些版本划分为片段（例如，两秒钟）。片段在Web服务器上提供，可以通过与HTTP标准兼容的方式下载GET请求。通常，不同版本之间的关系由清单描述，该清单在流传输会话之前提供给客户端。清单使用HTTP统一资源定位符（URL）表示媒体内容的不同质量以及每种质量的各个部分。这种结构提供了片段与比特率（分辨率等）之间的绑定（例如，开始时间，片段的持续时间）。作为结果，在每个段的客户端都对比特率或空间分辨率进行调整，例如，如果带宽允许，客户端可以在每个段的基础上切换到更高的比特率，或者在带宽减少的情况下切换到更低的比特率。这具有几个优点，因为客户端最了解其功能，例如接收的吞吐量，延迟，设备功能（例如，屏幕分辨率）等。

FeatureAdobe HDSApple HLSMS Smooth StreamingMPEG–DASH
Deployment on Ordinary HTTP Serverstick_green_sm2tick_green_sm2
Official International Standard (e.g., ISO/IEC MPEG)tick_green_sm2
Multiple Audio Channels (e.g., Languages, Comments, etc.)tick_green_sm2tick_green_sm2tick_green_sm2
Flexible Content Protection with Common Encryption (DRM)tick_green_sm2tick_green_sm2tick_green_sm2tick_green_sm2
Closed Captions / Subtitlestick_green_sm2tick_green_sm2tick_green_sm2tick_green_sm2
Efficent Ad Insertiontick_green_sm2
Fast Channel Switchingtick_green_sm2tick_green_sm2tick_green_sm2
Protocol Support’s multiple CDNs in paralleltick_green_sm2
HTML5 Supporttick_green_sm2
Support in HbbTV (version 1.5)tick_green_sm2
HEVC Ready (UHD/4K)tick_green_sm2
Agnostic to Video Codecstick_green_sm2
Agnostic to Audio Codecstick_green_sm2
ISO Base Media File Format Segmentstick_green_sm2tick_green_sm2tick_green_sm2
MPEG-2 TS Segmentstick_green_sm2tick_green_sm2
Segment Format Extensions beyond MPEGtick_green_sm2
Support for multiplexed (Audio + Video) Contenttick_green_sm2tick_green_sm2tick_green_sm2
Support for non-multiplexed (separate Audio, Video) Contenttick_green_sm2tick_green_sm2tick_green_sm2
Definition of Quality Metricstick_green_sm2
Client Logging & Reportingtick_green_sm2
Client Failovertick_green_sm2
Remove and add Quality Levels during Streamingtick_green_sm2
Multiple Video Viewstick_green_sm2
Efficient Trick Modestick_green_sm2

HLS (HTTP Live Streaming)

  • HLS 的延时包含了 TCP 握手、m3u8 文件下载与解析、ts 文件下载与解析等多个步骤。可以缩短列表的长度和单个 ts 文件的大小来降低延迟，极致来说可以缩减列表长度为 1，并且 ts 的时长为 1s，但是这样会造成请求次数增加，增大服务器压力，当网速慢时回造成更多的缓冲，所以苹果官方推荐的 ts 时长时 10s，所以这样就会大改有 30s 的延迟。

  • HLS 由两部分构成，一个是 .m3u8 文件，一个是 .ts 视频文件；每一个 .m3u8 文件，分别对应若干个 ts 文件，这些 ts 文件才是真正存放视频的数据，m3u8 文件只是存放了一些 ts 文件的配置信息和相关路径，当视频播放时，.m3u8 是动态改变的，video 标签会解析这个文件，并找到对应的 ts 文件来播放，所以一般为了加快速度，.m3u8 放在 web 服务器上，ts 文件放在 CDN 上。 HLS 协议视频支持 H.264 格式的编码，支持的音频编码方式是 AAC 编码。

  • 以下是.m3u8文件的示例，处于对ABR的支持，如果HLS编多个不同分辨率和码率的流，会有两级目录：master.m3u8定义了子流的各项信息，子流中才是具体的.ts段信息。

1
2
3
4
5
6
7
8
9
10
11
# master.m3u8
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=2855600,CODECS="avc1.4d001f,mp4a.40.2",RESOLUTION=960x540
live/medium.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=5605600,CODECS="avc1.640028,mp4a.40.2",RESOLUTION=1280x720
live/high.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=1755600,CODECS="avc1.42001f,mp4a.40.2",RESOLUTION=640x360
live/low.m3u8
#EXT-X-STREAM-INF:PROGRAM-ID=1,BANDWIDTH=545600,CODECS="avc1.42001e,mp4a.40.2",RESOLUTION=416x234
live/cellular.m3u8
1
2
3
4
5
6
7
8
9
10
# http://ivi.bupt.edu.cn/hls/cctv1hd.m3u8
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-MEDIA-SEQUENCE:58846
#EXT-X-TARGETDURATION:10
#EXTINF:10.000,
cctv1hd-1574835047000.ts
#EXTINF:10.000,
cctv1hd-1574835057000.ts
...
LHLS (Low-Latency HLS)

  • 详见：Introducing Low-Latency HLS

  • spec: https://developer.apple.com/documentation/http_live_streaming/protocol_extension_for_low_latency_hls

  • LHLS的主要优化在于（来自上述演讲的PPT）：

    • Reduce Publishing Latency
      • Partial Segments
        • Partial segment rather than regular segment
          • CMAF Chunks, or short TS, audio or VTT
          • Less than a full GOP
        • Playlists update every Partial Segment
        • Publishing latency becomes the Partial Segment duration
        • Partial Segments appear in parallel to regular Segments in Playlist
      • Partial Segments Disappear Quickly
        • Partial Segments only at live edge of Playlist
          • Removed once Parent Segments are established
          • Keeps Playlists small
    • Optimize Discovery
      • Optimize Segment Discovery
      • Improve Caching Behvior
      • Blocking Playlist Reload
        • Clients ask for its next Playlist update in advance
        • Server holds request until next Segment or Partial Segment appears
    • Eliminate Segment Round Trip
      • HTTP/2 is required for LHLS
        • HTTP/2 GET response can include secondary resources
      • Segment Push
        • GET of Playlist also pushes new Segment
    • Reduce Playlist Transer Overhead
      • Playlist Delta Updates
        • Clients asks for Delta Update explicitly
        • Update skips the earlier part of Playlist client already has
    • Switch Tiers Quickly
      • Rendition Reports
        • Playlist updates can carry up-to-date reports on peer Playlists
          • Last Media Sequence Number and last Partial Segment number
          • Allows client to load latest Playlist when switching bit rates

  • 一点解释来自：DASH和HLS：低延迟OTT交付的更新

    与今天广泛部署和使用的HLS规范相比，新的HLS更新提供了一些显着的增强：

    • 部分分段：先前的HLS规范非常简单，交付分段为6秒。低延迟HLS将提供在媒体播放列表的实时边缘传送媒体的工具，在媒体播放列表中，媒体被分成大量较小的文件，例如持续时间为250-300ms的CMAF块（很少帧，但没有完整的GOP ）。这些较小的文件称为HLS局部段。部分片段的持续时间较短，可以比其父片段更早地打包并添加到媒体播放列表。第一个部分片段可能在前一个片段发布后仅250毫秒后发布。为了避免播放列表太大，一旦部分片段比实时边缘的三个目标时长长，它们就会自动从媒体播放列表中删除。
    • HTTP / 2推送段：传统上，对于每个段，HLS播放器都会轮询播放列表文件以检查是否有新的可用段，然后使用第二个HTTP请求来检索媒体段。当需要低延迟交付时，这些传统HTTP请求的开销在延迟方面会成为问题。苹果公司的新规范使用HTTP / 2推送来推送较短的媒体“部分”，以响应播放列表请求。但是，播放列表必须非常频繁地获取，因为每秒最多可能会发生3-4次。
    • 阻止播放列表请求：在媒体播放列表更新中，播放器可以添加查询参数以指定其希望播放列表响应包含将来的片段。然后，服务器可以保留该请求（阻止），直到包含该片段的播放列表的版本可用为止。客户端还可以要求服务器将指示的片段与播放列表响应一起推送到客户端。阻止播放列表重载可消除轮询，而服务器推送可消除请求往返。
    • 播放列表增量更新：对于长时间运行的事件，播放列表大小可能会成为问题。随着更短的片段和片段的引入，这将变得更加关键，因为将发出更频繁的播放列表更新请求。在此HLS更新中，Apple提供了一种生成“增量”播放列表的方法，这意味着播放列表仅包含完整播放列表中的某些片段。这允许玩家一次请求完整的播放列表，将其存储并使用较小的增量播放列表添加到其中，该播放列表仅包含最新的几个片段以及播放列表顶部的低延迟“部分”。
    • 更快的比特率切换：通过低延迟交付，播放器对网络状况变化做出反应的时间更少。低延迟HLS允许特定格式的播放列表响应包含有关另一个格式中可用的最新块和段的信息。这样就可以跳入另一个表示形式，而无需在启动切换之前发出完整的播放列表请求。

MPEG-DASH (Dynamic Adaptive Streaming over HTTP, ISO/IEC 23009-1)

  • Netflix使用了MPEG-DASH
  • MPEG-DASH是和编码标准无关的
  • MPEG-DASH是MPEG开发的，与其他三个以厂商为中心的解决方案对比，相当于是国际标准
  • MPEG-DASH (Dynamic Adaptive Streaming over HTTP)这篇博客已经讲的很好了，我觉得我没有必要献丑了，再贴一些MPEG-DASH的资源就罢。

HDS (HTTP Dynamic Streaming)

  • Adobe的技术，没怎么看到有用的。

MSS (Microsoft Smooth Streaming)

  • 感觉是过气技术了。

CMAF (Common Media Application Format)

  • 来自：What is CMAF?

  • Purpose:

    • Use a common media format for video streams — thereby reducing costs, complexity, and latency.

  • Goals:

    • Eliminate investments associated with encoding and storing multiple copies of the same content.
    • Simplify workflows and improve CDN efficiency.
    • Decrease video lag by with chunked-encoded and chunked-transfer CMAF.

  • Timeline:

    • February 2016: Apple and Microsoft proposed CMAF to the Moving Pictures Expert Group (MPEG).
    • June 2016: Apple announced support of fMP4 format.
    • July 2017: Specifications finalized.
    • January 2018: CMAF standard officially published.

  • 这样，对于apple的HLS，现在有两个低延迟方案了：LHLS和CMAF

  • 参考：Low-Latency CMAF for Live Streaming at Scale

  • HLS之前使用的是.ts格式，使用CMAF会转到.mp4，有助于降低成本，提高CDN效率

img

How to choose Steaming Protols

  • 协议基于TCP / UDP可以反映一些信息：

    • 基于TCP的协议更可靠，更消耗资源？
    • 基于UDP更注重传输实时性

  • 协议基于HTTP意味着：

    • 从HTTP走流量，无需担心端口、防火墙等问题
    • 可以使用HTTP cache
    • 移动端无需APP，兼容HTML5的浏览器就可以看
    • 将多个帧一起打包传输，实时性欠缺
    • 在CDN上的伸缩性好

  • 因此，在实际应用中，一般在采集端推流到媒体服务器会使用一些传统的协议，RTMP、RTSP，或者是SRT（也有很多厂商自己定制的私有协议），之后的分发会使用给予HTTP的自适应流媒体技术。

  • 想要低延迟可以定制化私有协议。

AV1 Streaming

AV1 Current Status

  • 编码复杂度高，编码优化不够完善：慢！
    • 只有较强的服务器上可以实时编码1080p及以上
    • 因此，很难用于极端低延迟条件的应用场景，不考虑这一使用场景
  • 不应该用于极端低延迟应用场景
    • 此类应用场景，如电话会议，参与人数较少，（这类场景没有那么流量成本敏感？）
    • AV1既然有高复杂度的特性，使用AV1的主要目的在于传输同等质量的视频时，降低比特率，降低带宽的使用，从而降低流量成本。
    • 因此AV1的用武之地不在这里。
  • 协议支持不够完善
    • MPEG-DASH是Codec无关的协议，可以使用
    • HLS限制Codec，似乎还没支持AV1，但Apple也是AOM的成员，后续肯定会加入AV1.
    • RTMP不能支持（也不应该考虑了）
  • 一般延迟要求的直播10s，差不多是HLS和DASH的延迟范围，可以达到。
  • 当前实现：pc: RTSP+x264 -> server: dash+svtav1 -> client

AV1 Prospect

  • from twitch: we are hoping 2022-2023 we are going to release AV1 for the head content. But for the head content, we will continue to stream dual-format, AV1, H.264. But for the tail content, we are hoping towards five years from now to AV1, whole eco, every five-year-old device supports AV1. Then, we will be switching to AV1 100%.
  • 因为免版税，又有Netflix、YouTube等大厂，AV1未来在互联网媒体肯定是最重要的编码标准。

AV1 Streaming Implement

  • Web server: Nginx

  • Codec: libx264, libsvt_av1

  • Server: Intel Xeon Platinum 8280

  • Protocol: RTSP, MPEG-DASH (RTSP can be replaced by RTMP or SRT)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# pc ------------> server -------------------> client
#	  rtsp+h264  |transcode| dash+libsvt_av1
# pc side
ffmpeg -s 1920x1080 -r 30 -f x11grab -i :0.0+0,0 \
-c:v libx264 -tune zerolatency -preset ultrafast -crf 0 \
-f rtsp -muxdelay 0 -rtsp_transport tcp     \
rtsp://your-serverIP/live.sdp
-----------------------------------
# server side
ffmpeg -rtsp_flags listen -i rtsp://your-serverIP:8888 \
-map 0 -map 0\
-c:a aac -c:v libsvt_av1 -preset 8 -forced-idr 1  \
-b:v:0 5000k -s:v:0 1920x1080  \
-b:v:1 2000k -s:v:1 1280x720  \
-sc_threshold 0 -b_strategy 0 -ar:a:1 22050 \
-use_timeline 1 -use_template 1  -window_size 5 \
-adaptation_sets "id=0,streams=v id=1,streams=a" \
-hls_playlist 1 -seg_duration 2 -streaming 1   \
-dash_segment_type 2 -strict experimental -lhls 1  \
-f dash manifest.mpd
-----------------------------------
# play
mpv http://your-serverIP/master.m3u8

Appendix

Report

Some Protocol Implements

欢迎关注我的其它发布渠道