视频的传输方式【转】

概述

搜索“视频传输协议”,一般会搜出来RTP,RTSP,UDP等等。光看这些协议,可能有些人会觉得奇怪为什么要把udp也往上放一起,rtp不是可以基于udp?!同时,很多文章主要去讲解各个协议之间的差异,而没有从更为宏观的角度来考虑。本文将结合OSI的分层思路,将不同协议之间的关系都梳理清楚;同时也从视频传输与组网角度进行介绍。
再者,视频有很多封装格式,比如m3u8,mp4等;也有很多音视频编码格式,比如h264,h265等,那为何有这么多的封装格式类型和音视频编码格式类型呢?一方面是解决存储的问题;另一方面是支持不同播放器的解析;但更重要的是不同的传输协议可以支持的音视频编码格式有差异,这也是由于不同的应用场景下形成的历史原因。

1.流媒体

流媒体(streaming media),是指将一连串的媒体数据包从服务器端发送到客户端,可以实现边下边播,此技术使得数据包可以像流水一样发送。传统的方式需要在使用前下载整个文件,存储到本地后才能进行播放;而流媒体只允许下载一小部分(存在视频关键帧)就能进行播放。

流媒体技术不是一种单一的技术,它将网络技术、音视频技术还有终端缓存技术等有机地结合。也就是说,在网络上要实现流媒体技术,必须要先制作、发布、传输和播放等,这需要服务器端、终端以及网络都要能支持。当前很多的视频软件或者网站都是用到了这种技术。归结下来是:

  • 1.内容的产生。这里是指将视频源制作成为可以对外发布的视频格式,以及适合在网络上传播的分辨率和码率。这主要用到了视频的编解码技术。考虑的输出参数,如分辨率、码率、音视频编码格式、封装格式等都需要结合应用场景和传输方式统一考虑。

  • 2.对外发布。这里主要是指能够支撑服务器对外输出视频资源的技术,常见的有各种流媒体网络传输协议技术及其需要服务器端支撑的技术。这里的流媒体网络传输协议比如:

    • HLS
      服务端支持Adobe Flash media server,Nginx,vlc等等。
    • DASH
      服务器端支持Nginx等
    • RTMP
    • Adobe Flash 服务器,Nginx-rtmp
  • 3.组网和传输。
    这里的传输还得考虑一个概念,是服务器对外主动推数据,还是等待终端到服务器端拉数据,这是两个完全相反的处理方式。对于组播或者广播的组网方式,往往采用的是服务器主动对外推送数据;而对于单播来说主要是终端向服务器端主动拉数据。

    这里涉及到的IP组网方式中的传输类型有:广播、单播、组播。

    不管是什么类型的组网方式,在传输层就有UDP和TCP。下面也将从OSI等层面讲讲这些底层传输协议之间的关系。

  • 4.视频播放。这里主要是从终端侧角度说,在不同操作系统中能够进行播放视频的播放器,比如vlc等,不同的播放器支持对不同类型的视频数据进行播放。

2.TCP/IP、OSI与视频传输协议之间的关系

从图中也可以看到IP层(网络层)的上层是传输层,通过TCP和UDP等方式进行数据包的传输。
(PS:下图为网络中所找https://blog.csdn.net/yaopeng_2005/article/details/7064869)
在这里插入图片描述
结合上图,再补一个wiki上的互联网协议套组图,一看就更明白了。
在这里插入图片描述
从上面两个图中也可以很清楚地看到,TCP和UDP在接下去的内容有很重要的地位,这里也简单介绍下,深度知识请自行搜索。

  • 1)TCP(Transmission Control Protocol)传输控制协议
    是一种面向连接的、可靠的、基于字节流的传输层协议。也就是说,它在收发数据之前,必须先和对方建立可靠的连接。有兴趣地可以了解TCP的三次握手过程。当TCP检测到数据包丢失时,它将限制其数据速率使用率,因此也说TCP是靠谱的,但是对于实时类型的业务,可能不那么适合。
  • 2)UDP(User Datagram Protocol)用户数据报协议
    是一种简单的面向数据报的通信协议。UDP只提供数据的不可靠传递,它将数据发送出去后,就不保留备份,它仅仅在IP数据报的头部加入了复用和数据校验字段。由于不需要多长校验,UDP的速度比TCP快,但是有数据丢失风险,因此比较适用于实时性要求高的场景,比如实时语音或视频通话。广电网络场景中,以前多用UDP进行传输,而且是组播或广播的方式,这结合组网能够将流量成本较大地控制下来。
  • 3)IP层(Internet Protocol)
    IP是网络层的主要协议,将根据源主机和目的主机的地址进行数据传输。定义了寻址方法和数据报的封装结构。其最为复杂的就是寻址和路由了。寻址就是将IP地址分配给各个终端节点,并如何进行划分和组网。而路由主要是内部和外部网关协议,决定了怎么发送IP数据包。下面提到的组播和广播等,其实主要是针对IP多播来说的。
  • 4)在不同层之间的数据的术语称呼
    数据在TCP层称为流(Stream),数据分组称为分段(Segment)
    数据在IP层称为Datagram,数据分组称为分片(Fragment)
    在UDP中,分组称为Message

3.组播、单播和广播

  • 组播(multicast)
    又称为多点广播或群播,或多播,主要是指将信息同时传递给一组目的地址。消息在每个网络链路上只需传递一次,而且只有在链路分叉时,消息才会被复制,使用的效率是最高的。也正是因为这个原因,以前的广电网络中,针对直播多采用组播方式,流量的传输成本明显降低很多。

  • 单播:
    其实是组播的一种特殊方式,即常规的点到点信息传递。如果所有传输中是以单播的方式传递给多个接收方,必须向每个接收者都发送一份数据副本这么多。

  • 广播
    其实也算是组播的一种特殊方式,就是一对所有的通信方式,对每一台主机发出的信号都进行无条件复制并转发,所有的接收点都可以收到所有信息。

注意,组播一般指的是IP组播,常与RTP等音视频协议相结合。虽然组播的设计理念很好,但是它需要对网络内部的状态比单播要多得多。实际商用中,组播主要应用在较为简单的、只有单个源断的情况,如之前提到广电网络内部用到的组播方式,UDP组播。

以上是不同类型的IP组播方式,实际在采用中要结合具体情况进行调整。比如,如果非要使用广播,但是采用的场景不合适,也有可能产生广播风暴。

组播、广播、单播也介绍了基本的概念,但是他们与视频传输有什么关系呢?

文章上面也提到了,组播是从IP层面的传输策略,而所有的视频传输协议其数据包大部分都经过UDP和TCP,经由IP层进行传输到目的地。因此不同的IP传输策略与传输协议进行结合,就能够落地到具体的应用场景。

同时需要注意的是,采用组播方式可以通过设置网卡为混杂模式或为多播模式,具体也是根据网卡的特性进行差异处理。如果处理方式不当,比如设置成了广播,可能会导致在同网络下,你在播放视频,然后其他相同网络下接收端也将有相应的流量,而导致他们的对外服务网口的流量被占满。

4.视频传输协议

从下图中可以看到,标红色的就是大家经常说的视频传输协议。但是从图中可以看到他们其实是有基于的关系,比如HLS都是基于HTTP进行传输,而HTTP在传输层都是依赖tcp数据包,再经由ip层进行分发。
在这里插入图片描述

  • 1)UDP

    • 基于UDP传输的视频数据,比如udp://238.123.45.1:3001,在网络可达的情况下,即可进行播放。可以采用vlc等播放器进行播放。

    • UDP视频数据传输可以采用单播,组播或广播的方式,具体采用哪种方式根据具体的组网情况进行控制。

    • 上面也有提到过,广电网络中多采用组播的方式进行直播数据传输,这也是得益于广电网络的专网特性以及视频源输出可以控制到单一等特性。

    • UDP的组播大部分是采用MPEG TS流,广电网络中很多视频,其视频编码格式也大部分是mepg2

  • 2)RTP
    整个RTP协议包括RTP数据协议和RTP控制协议(RTCP)。此外,这里也将经常一起提的RTSP介绍下。

    • RTP(实时传输协议,Real-time Transport Protocol),是一种网络传输协议

    • RTP协议说明了传递音频和视频的标准数据包的格式。最早是作为多播协议的,后来主要应用在单播中。RTP是创建在UDP协议之上的,主要应用于流媒体、视频会议等系统业务上。

    • RTP为端到端的数据传输提供了时间信息和流同步,但不保证服务质量,而是由服务质量由RTCP。
      在RTP的数据包封装中,包含了时间戳、标记位、同步源标识等信息。

    • RTP从上层接收到流媒体的数据(如H264),封装成RTP数据包,并将其发往UDP端口中的偶数端口。

    • RTCP(实时传输控制协议,Real-time Transport Control Protocol或RTP Control Protocol)

    • RTP的姐妹协议。RTP使用的是偶数UDP端口,RTCP采用的是RTP下一个端口,也就是下一个奇数的端口。RTCP也是基于UDP进行传输的。

    • RTCP本身不做数据传输,主要与RTP协作,将视频媒体数据打包和发送,并定期在流媒体会话参与者之间传输控制数据,并为RTP提供QoS反馈,简单点说是主要保证音视频的同步。

    • RTCP接收到控制信息后,封装为RTCP控制包,并发往RTP端口下一个偶数端口。

    • RTSP(实时流协议,Real Time Streaming Protocol)
      RTSP是一种网络应用协议,主要来创建和控制流媒体服务器与终端之间的会话。控制类的请求主要走TCP协议。

    • 通过RTSP对流媒体数据进行控制和播放,比如进行播放、暂停、快进等操作,它定义了具体的控制消息、操作方法和状态码等。

    • 与RTP、RTCP配合,在广电网络内部主要应用在点播场景比较多,而直播主要走UDP组播。在互联网场景下,也有用于直播和点播的,但是相对来说使用较少。

    • 请求的url为:rtsp://testdomain/test.mp4/streamid=0

    • 需要服务器端和客户端都能够支持RTSP的控制。一般客户端采用vlc即可,而服务器端采用Darwin Streaming Server,ffmpeg等建立流媒体服务。

  • 3)RTMP(实时消息协议,Real-Time Messaging Protocol)
    包括RTMP、RTMPT等一系列的协议,Adobe为flash播放器和服务器之间音视频数据传输的协议。

    • RTMP
      1)主要基于TCP协议进行数据包传输,默认使用1935端口。
      2)服务器端采用Nginx,支持rtmp模块的即可支持对外rtmp视频数据服务。
      3)支持rtmp模块,可以支持直播rtmp输出,也能够支持hls访问。
      4)RTMP支持mp4,flv等封装格式的视频对外输出
    • RTMPS
      通过SSL加密的RTMP协议
    • RTMPE
      RTMPE是一个加密版本的RTMP,和RTMPS不同的是RTMPE不采用SSL加密,RTMPE加密快于SSL,并且不需要认证管理
    • RTMPT
      采用HTTP封装以穿透防火墙,通常用80和443端口。
    • RTMFP
      使用UDP进行数据传输

4)HTTP
而基于HTTP协议的就更多了,如上图。如果服务器部署了流媒体的服务,如Nginx等,就可以对外提供视频播放服务了。

这里也需要说明,视频的播放一般分为点播和直播,有些协议作为直播的传输协议反而是更好的,比如RTMP,时延就比较低,但RTMP做CDN成本相对较高。CDN支持很好的HTTP如果能支持直播,当前也有很多协议能支持通过HTTP的方式实现直播流媒体。

5.自适应流媒体

自适性流媒体(adaptive bitrate streaming,ABS)也叫码流自适应,是流媒体服务器准备各种码流的视频流,所有的视频码流都是相同时段完全统一图像的音视频数据,客户端根据网络情况和CPU使用情况等进行动态调整。

主要有MPEG-DASH、HLS、HDS、MSS等技术方案,这几个也是上图中最上层的流媒体传输协议技术。通过这些传输协议封装的视频源,可以支持有多种码率,并支持播放器客户端在播放时,根据带宽情况自动调整码率以适应用户的最佳观看效果——不卡顿,不重新加载等。

  • 1) DASH(MPEG-DASH)
    MPEG-DASH是基于HTTP的自适应码流方案中唯一国际标准,它采用TCP传输协议。
  • 2)HLS
    Apple提出的,将.m3u8作为索引文件,分片格式为ts,支持直播和时移。
  • 3)HDS
    采用支持RTMP和HTTP协议,HTTP协议类似于HLS,也可以叫渐进式下载。
  • 4)MSS
    是微软提出的,文件切片格式为mp4,索引文件为ism、ismc,也支持直播和时移。

这里也仅仅对码流自适应技术做了简单介绍,由于现在这种技术应用相当广泛,后面将详细介绍这种技术。

【说明】
文章转自,华为云社区,作者Higeeon,相关版权解释权归原作者所有。https://bbs.huaweicloud.com/blogs/fed3df04b1e011e9b759fa163e330718

  • 11
    点赞
  • 112
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值