浅聊视频技术及其背后的一些原理

       如今的互联网，视频音频等让人们的生活更加丰富，技术的发展也日新月异。从早期的电视，到各大视频播放平台如爱奇艺，腾讯，优酷等等。再到近两年，在新冠疫情和元宇宙等多种因素的促进作用下，音视频相关产业直接爆发，比如抖音，快手等平台上的短视频、直播带货、线上教学等。那么这些在APP上展现的视频是通过怎样的技术来呈现给用户的呢。本篇文章将给大家简单科普下关于视频方向的相关技术知识。

一、视频，视频流，播放平台间的关系

1、视频和视频流的关系

       百度百科上的解释，视频（Video）是泛指将一系列静态影像以电信号的方式加以捕捉、记录、处理、储存、传送与重现的各种技术。我们知道根据视觉暂留原理，当连续的图像变化每秒超过24帧（frame）画面以上时，人眼就会无法辨别出单幅的静态画面。所以看上去会产生平滑连续的视觉效果，这样连续的画面叫做视频。想必大家小时候都玩过各式各样的手翻书，它便是最早的动画模式，即是利用视觉暂留原理制成的“不插电”的动画。

图1 早期的手翻书（来源于网络）

       但是由于视频信息十分丰富且信息量大，按传统的处理方式来处理视频数据信息，将会非常麻烦。最早的时候我们观看电影需要首要将整个电影都下载下来，再通过视频播放器进行播放。假设观影者要看一部高清的电影，至少得等数十分钟到数小时，等视频文件下载完后才能看到。而且通常情况下，播放器处理文件是完整地进行处理的，也就是说文件在被处理的时候必须是完好无损的。文件一旦遭到损坏，或者只有一半的内容，那么播放器将认为该文件是坏的，是不可处理的。这显然让人难以接受。
       解决的办法是采用一种专用的流体化技术提取文件。这种流体化技术的原理可以这样理解：服务器在向用户传输视频文件时，不是一次将文件整体发送出去，而是先按播放的时间顺序将其分为小的片断，类似于图像中的帧，然后将这些片段依次发给用户。用户的网络播放工具接收到这些片段后，连续播放这些片段，就可以产生完整的声音和图像，只是开始时有些延迟。为了保证声音、图像的播放效果，对网络传输速度也有一定的要求。如果网络传输速度较慢，播放时就会出现卡顿的现象。应用中可以根据用户的实际带宽，提供用户不同清晰度的播放效果。这就是视频流技术。
       综上，所谓的视频流，就是一种视频数据信息的传输方式，使用这种方式，用户可以在没有接收到完整的数据信息前就能处理那些已接收的信息。这种一边接收，一边处理的方式，很好地解决了视频数据信息在网络上的传输问题。使用者可以不必等待太长的时间，就能收看到视频数据信息。

2、视频流和播放平台的关系

如上文所说我们在视频播放平台观看电影或者观看直播，本质上是你手机或者电脑的客户端一直在接收视频流数据。一边接收数据，一边将接收到的数据解码成连续的视频帧进行快速地播放。

由于最近短视频平台，直播带货等的兴起。大量的音视频播放的概念也逐渐被大众所熟知。总结下来视频播放场景主要可以分为三类：点播，直播，伪直播。

点播

视频点播播放的视频内容是非实时的视频画面，视频源是已经存在的视频文件或者媒体源，可以重复使用，也可以按需回退和快进。日常生活中的视频点播场景非常多，比如视频网站的电视剧、电影、短视频等。很多常见的视频app主要以提供点播功能为主。如：爱奇艺，优酷等等。

图2 某点播视频网站的主页

直播

视频直播播放的视频内容是实时的视频画面，视频源是实时的媒体流。视频直播的播放内容稍纵即逝，无法回退和快进。现在的视频直播场景也非常多，比如最早的球赛直播，央视的新闻联播，到现在的直播带货、视频会议等。现在最常见直播的app。如抖音，快手等等。

图3 抖音上李佳琪的直播间

伪直播

伪直播是介于视频直播和视频点播之间的一种视频播放形式。目前，它的使用场景也正在逐渐丰富起来，简单来说就是把视频点播以视频直播的形式展现出来。举个伪直播的使用场景，我们利用ffmpeg（一种视频制作工具） 把一个提前录制好的视频文件（比如 mp4 或者 flv ）重新推流成 rtmp 或者 rtp 媒体流，在直播场景中播放。让用户无法判断当前播放内容是直播还是点播。现在很多辅导的大班课场景中，他们的课程内容都是老师提前录制好的，授课的时候通过伪直播推流播放，老师则同时在聊天区域和提问的学生互动，让学生们以为教学内容是直播场景的实时画面。

伪直播 = 视频点播 -> 视频直播

二、视频传输的相关协议

从上面我们可以了解到，视频流就是一种视频数据信息的传输方式。传输方式的好坏直接决定了用户的观看体验。

下面从两个维度大致总结了下现在技术领域内，所用到的视频流传输相关协议。

交互方式维度：

• 直播：HLS，RTMP，http+flv，RTP+RTSP，webrtc等等
• 点播：http+MP4，http+flv，HLS等等.

业务场景维度：

• 视频直播：RTMP，HLS，http+flv等等
• 音视频通话：webrtc(RTP)，SIP＋RTP，RTCP+RTP等等
• 视频点播：http+MP4，http+flv，hls等等
• IPTV：RTSP+RTP等等
• 会议电视：RTP＋SIP，H323+RTP等等
• 视频监控：国标SIP+RTP，RTSP+RTP等等

其实上面有很多协议是可以既用来点播也可以用来直播的。这主要取决于现实场景的需求。

众所周知在网络传输层最基础的两个协议是TCP和UDP，他们之间最大的区别是：

• TCP面向有连接，能够对自己提供的连接实施控制。
• UDP面向无连接，不会对自己提供的连接实施控制。

鉴于TCP和UDP的特性，TCP适合应用于要求可靠的传输，UDP适合应用于实时应用。但在流媒体的实际使用场景中，如果直接用UDP来传输音视频，由于公网传输的不稳定，所以导致不可避免地丢包、乱序等情况，这会导致客户端无法解码。而如果直接TCP来传输音视频，那TCP自身的拥塞控制机制、传输数据延时大，队头阻塞等问题，会对音视频的实时传输造成一定的困扰。

这下我们可以明白了，这么多的传输协议本质上是为了解决TCP和UDP在不同场景下的问题而进行的高层次开发。

下面我们挑几个比较重要的协议简单介绍下：

RTP和RTCP：

RTP（Real-time Transport Protocol）实时传输协议是用于Internet上针对多媒体数据流的一种传输层协议。

RTCP(Real-time ControlProtocol)实时传输控制协议是和 RTP一起工作的控制协议。RTCP单独运行在低层协议上，由低层协议提供数据与控制包的复用。在RTP会话期间，每个会话参与者周期性地向所有其他参与者发送RTCP控制信息包。

RTP与RTCP基本都是成对使用，广泛应用于电话、视频会议、安防国标摄像头等等。

RTSP:

RTSP(Real-Time Stream Protocol)协议是一个基于文本的多媒体播放控制协议，属于应用层。RTSP以客户端方式工作，对流媒体提供播放、暂停、后退、前进等操作。

RTSP作为一个应用层协议，提供了一个可供扩展的框架，他使得流媒体的受控和点播变得可能，它主要用来控制具有实时特性的数据的发送，流媒体数据的传送还是基于RTP来完成。

使用RTSP协议传输流媒体数据需要有专门的媒体播放器和媒体服务器，也就是需要支持RTSP协议的客户端和服务器。

RTMP:

RTMP(Real Time Messaging Protocol)实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。RTMP是工作在TCP之上的协议,能够保持长连接，并为用户提供低延时通信。

RTMP目前广泛应用在低延时直播。

HLS:

HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。

HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。

HLS直播其实是以点播的技术方式来实现直播。HLS的本质是传输小分段。由于分段文件的时长很短，客户端可以很快地选择和切换码率，以适应不同带宽条件下的播放。不过小分段的这种技术本质，也决定了它的延迟一般总是会高于其他的流媒体直播协议。

三、总结

本文大致介绍了视频，视频流，播放平台间的关系。视频以不同形式进行传输，传输形成了视频流，播放平台以约定好的协议接收视频流，并进行解码等操作，形成可播放的快速连续帧，然后供用户观看。同时也大致总结了下现在一般交互方式和业务场景下所用的对应协议是什么。相信通过本文的介绍，大家对视频方向应该有了大致的了解。