本文介绍流媒体技术的相关知识。
 
1 概述
 
流媒体（streaming media）技术，是指将一连串的多媒体数据压缩后，经过互联网分段发送数据，在互联网上即时传输影音，以供用户观赏的一种技术。
 
在流媒体技术出现之前，人们必须要先下载多媒体内容到本地计算机，等待完整的多媒体内容下载完成之后，才能够欣赏多媒体的内容。流媒体技术的出现，使人们只需经过几秒或十几秒的启动延时即可欣赏媒体内容，而无需再等待媒体内容完全下载完成了。
 
流媒体技术使得数据包可以像流水一样发送，如果不使用此技术，用户就必须先下载整个媒体文件，而后才能使用多媒体数据。通过流媒体技术，可将现场或预存于服务器上的影音传送至观看者端，当影音数据传送至观看者的计算机后，即可立即通过特定的播放软件欣赏影音数据。
 
如果将媒体文件的传输看作是一次接水的过程，那么过去的媒体传输方式就像是对用户做了一个规定：必须等到一桶水接满才能使用它，“接满一桶水”这个过程等待的时间就要受到水流量大小和桶大小的影响了。而流媒体传输则是，打开水头龙后，稍等一小会儿，水就会源源不断地流出来了，此时即可随接随用。因此，不管水流量的大小、也不管桶的大小，用户都可以随时用上水。从这个角度来看，“流媒体”这个词是非常形象的。
 
2 流媒体（技术）的特征
 
流媒体包括声音流、视频流、文本流、图像流、动画流等，在时间上连续的媒体数据。
 
1. 流媒体具有较强的实时性和交互性；
 
2. 通过利用流媒体技术，用户侧的媒体启动时间大幅度缩短，用户不必像以往那样“等到所有媒体内容都下载完成后上才能浏览”，而是经过一段启动延时后，立即就能欣赏媒体内容。
 
3. 与传统的媒体传输方式相比，流媒体技术对客户端（用户计算机）的缓存容量要求大大降低。
 Internet 是以包传输为基础进行的异步传输，因此数据会被分解成许多包进行传输，由于每个数据包可能选择不同的路由（进行传输），所以这些数据包到达客户端（用户计算机）的时间延迟就会不同，因此在客户端就需要缓存系统来消减延迟和抖动的影响，以及保证接收到数据包的传输顺序的准确性。与传统的（完整）媒体传输方式相比，在流媒体文件的播放过程中，由于不再需要把所有的文件都放入缓存系统，因此对缓存容量的要求是很低的。
 
3 流式传输
 
流媒体技术的特征就是流式传输，它使得流媒体数据可以像流水一样传输。
 
流式传输主要包括两种实现方式：顺序流式传输（progressive streaming）和实时流式传输（real time streaming）。需要根据具体需求决定采用哪种方式进行流式传输，下面就对这两种传输方式进行简单介绍。
 
3.1 顺序流式传输
 
在顺序流式传输模式下，用户在观看在线媒体的同时，也在下载文件。在这个过程中，用户只能观看已经下载完成的媒体内容，而不能直接观看未下载的部分。因此，用户会在一段延时后，才能看到服务器传送过来的媒体内容。由于标准的HTTP服务器就可以发送这种形式的媒体文件，因此流式传输也经常被称为HTTP流式传输。
 
由于顺序流式传输能够较好地保证节目的播放质量，因此比较适合在网站上发布的、可供用户点播的、高质量的视频。
 
顺序流式传输的文件存放在标准HTTP或FTP服务器上，易于管理，基本上与防火墙无关。
 
根据以上信息，能够知道“顺序流式传输”主要提现了流媒体技术的基本功能：无需下载完整的媒体文件，即可欣赏媒体内容。
 
3.2 实时流式传输
 
使用实时流式传输时，必须要保证与流媒体对应的带宽，以使媒体内容可以被用户实时观看到。用户在观看过程中，可以任意观看当前媒体内容之前或后面的内容。但是在这种传输方式中，如果网络状况不理想，会导致收到的图像质量比较差。
 
实时流式传输需要特定的服务器（如 Windows Media Server），这些服务器可以对媒体进行更多的控制，所以系统设置、管理比标准HTTP服务器更加复杂。
 
实时流式传输还需要特殊的网络协议，如 RTSP(realtime streaming protocol) 或 MMS(microsoft media server)。防火墙有时会对这些协议进行屏蔽，导致用户看不到不实时内容。
 
根据以上信息，能够知道“实时流式传输”更强度的是媒体传输的“实时性”，因此目前流行的视频直播行业，应属于“实时流式传输”功能的应用。
 
4 流媒体传输的网络协议
 
流媒体传输一般采用HTTP/TCP(RTCP)协议来传输控制信息，而用UDP(RTP)协议来传输实时媒体数据（TCP开销相对较大，所以不太适合传输实时数据）。
 
4.1 RTP（实时传输协议）
 
RTP（实时传输协议）通常用于实时数据的传输工作（一般使用UDP来传送数据）。
 
当应用程序开始一个RTP会话时，将开启两个端口：一个给RTP，一个给RTCP。RTP本身并不能为“按顺序传输数据包”提供可靠的传输送制，也不提供流量控制和拥塞控制服务，而是依赖RTCP提供这些服务。通常RTP算法并不作为一个独立的网络层来实现，而是作为应用程序代码的一部分来实现的。
 
4.2 RTCP（实时传输控制协议）
 
RTCP（实时传输控制协议）在RTP传输实时数据时，提供流量控制和拥塞控制服务。在RTP会话期间各参与者会周期性地传送RTCP包，RTCP包中含有已发送的数据包的数量、丢失的数据包数量等统计资料，因此，服务器可以利用这些信息动态地改变传输速率，甚至改变有效载荷类型。
 
RTP和RTCP配合使用，能通过有效的反馈和最小的开销，使传输效率最佳化，因此特别适合在互联网上传输实时数据。
 
4.3 RTSP（实时流协议）
 
RTSP（实时流协议）定义了一对多模式下如何有效地通过IP网络传送多媒体数据。
 
RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP(RTP)协议完成数据传输，如下图4.3-1（RTSP在网络体系结构中的位置）所示。
 
 
5 流媒体系统组成
 
流媒体系统包括以下五个内容：
 
1. 编码工具：用于创建、捕捉和编辑多媒体数据，形成流媒体格式；
 2. 流媒体数据；
 3. 服务器：存放和控制流媒体的数据；
 4. 网络：适合多媒体传输协议（甚至是实时传输协议）的网络；
 5. 播放器：客户端通过播放器浏览流媒体文件。
 
以上五个部分有些是服务器需要的，有些是客户端需要的，而且不同的流媒体标准和不同公司的解决方案中，会在有些内容上有所不同。
 
6 流媒体技术涉及到的关键技术
 
流媒体技术不是一个单一的技术，它是网络技术与视音频技术的有机结合。
 
实现流媒体技术，需要解决流媒体的制作、发布、传输和播放等方面的问题，这些问题的解决需要利用到视音频技术和网络技术。下面具体讨论一下流媒体的这几个问题。
 
6.1 流媒体的制作
 
只有适合流媒体传输的流媒体格式文件才能在互联网上传输。因为一般的多媒体格式文件体积很大，因此在网络上传输时需要花费较长的时间，如果遇到网络繁忙等情况，还会造成传输中断。另外，一般格式的媒体文件也不能通过流媒体传输协议进行传输。
 
因此，需要先对待传输的文件进行预处理，将文件压缩成流媒体格式文件。此处主要包括两个要点：一是选用适当的压缩算法进行压缩，确保生成的文件体积较小；二是需要向文件中添加流式信息。
 
6.2 流媒体的传输
 
流媒体的传输需要合适的传输协议，在Internet上进行的文件传输大部分都建立在TCP协议的基础上，也有一些是通过FTP进行传输，但采用这些传输协议都不能满足流媒体的实时传输要求。
 
随着流媒体技术的深入研究，比较成熟的流媒体传输一般都是采用建立在UDP协议上的RTP/RTSP等实时传输协议。
 
为何要在UDP而不在TCP上进行实时数据的传输呢？因为两者在数据传输的速度和可靠性方面有很大的区别。TCP协议中包含了专门的数据传送校验机制，当数据接收方收到数据后，会自动向发送方发出确认信息，发送方在接收到该确认信息后，才会继续传送数据，否则将一直处于等待状态；而UDP协议则不同，UDP协议本身并不做任何数据传输校验。由此可以看出：TCP协议注重传输质量，而UDP协议则注重传输速度。因此，对于那些对传输质量要求不是很高，而对传输速度有很高要求的流媒体文件来说，采用UDP协议传输更为合适。
 
用户通过Web浏览器播放流媒体时，主要的交互过程如下：
 
用户选择流媒体服务后，Web浏览器与Web服务器之间使用 HTTP/TCP 交换控制信息，以便把需要传输的实时数据从原始信息中检索出来；
Web浏览器启动A/V Helper程序，使用 HTTP 从Web服务器检索相关参数，然后对Helper程序初始化。这些参数可能包括目录信息、A/V数据的编码类型，或与A/V检索相关的服务器地址；
A/V Helper程序及A/V服务器运行RTSP协议，以交换A/V传输所需的控制信息。与CD播放机或VCRs所提供的功能类似，RTSP提供了控制播放、快进、快倒、暂停及录制等命令的方法；
A/V服务器使用RTP/UDP协议，将A/V数据传输给A/V客户程序（一般可认为客户程序等同于A/V Helper程序）；
当A/V数据抵达客户端时，A/V客户程序即可播放A/V数据了。
需要说明的是，在流媒体传输过程中，使用RTP/UDP和RTSP/TCP两种不同的通信协议与A/V服务器建立联系，是为了能够把服务器的输出重定向到一个不同于运行A/V Helper程序所在客户端的目的地址。实现流式传输一般都需要专用服务器和播放器。
 
6.3 流媒体数据在客户端的缓存
 
在流媒体传输和播放过程中，客户端的缓存技术能够确保视音频数据正确、连续地播放。
 
6.3.1 纠正数据包顺序的缓存技术
 
因为Interent是以包为单位进行异步传输的，因此多媒体数据在传输中要被分解成许多包，由于网络传输的不稳定性，各个包选择的路由可能不同，所以到达客户端的时间次序就可能发生改变，甚至出现丢包的现象。因此，必须采用缓存技术来纠正数据包到达次序混乱的情况，利用缓存技术对到达的数据包进行正确排序，从而使视音频数据能正确地播放。
 
从技术角度来讲，纠正数据包顺序的缓存技术，属于流媒体传输过程接收侧的功能，主要目的是保证视音频内容可以正确地播放。
 
6.3.2 播放缓冲区
 
流媒体技术需要在客户端的计算机上创建一个缓冲区，在播放前预先下载一段多媒体数据作为缓冲，在网络实际传输速度小于媒体播放所需的速度时，播放程序就会取用一小段缓冲区内预先存储的数据，这样就可以避免播放内容的中断，保证了视频播放品质。
 
在流媒体传输模式下，缓存中存储的是某一段时间内的数据，数据在缓存中存放的时间是暂时的，缓存中的数据也是动态的、不断更新的，流媒体在播放时不断读取缓存中的数据，播放完成后该数据就会被立即清除，新的数据又将存入到缓存中。因此，在播放流媒体文件时并不需要占用太大的缓存空间。
 
从技术角度来讲，播放缓冲区技术，属于客户端播放器的功能，主要目的是（在不太损失实时性的前提下）保证视音频内容可以连续地播放。
 
6.4 流媒体的播放
 
流媒体只能在支持对应的流媒体格式的播放器（浏览器）中正常播放。
 
7 流媒体服务器
 
流媒体服务器是流媒体应用的核心系统，主要包括流媒体的编码、转码、分发、存储等功能，是向用户提供视频服务的关键平台。
 
从播放模式方面来看，流媒体服务器的主要包括以下两种模式：
 
以流式协议（RTP/RTSP、MMS、RTMP等）将视频文件传输到客户端，供用户在线观看，即“点播模式”；
从视频采集、压缩软件接收实时视频流，再以流式协议直播给客户端，即“直播模式”。
流媒体应用的主要性能取决于媒体服务器的性能和服务质量。因此，流媒体服务器既是流媒体应用系统的基础，也是最主要的组成部分。
 
8 流媒体与传统媒体
 
流媒体与传统媒体相比，区别如下：
 
欣赏媒体内容的即时性：因为视音频文件（特别是视频文件）容量一般都很大，受到网络带宽的限制，下载一个视音频文件可能需要几分钟甚至几小时，因此导致传输媒体的欣赏时延很大；而通过利用流媒体技术，多媒体文件一边被下载一边被播放，用户可以即时地欣赏到多媒体内容了（即点即看）。此外，目前流行的视频直播相关行业，也是流媒体技术非常重要的应用场景。
对客户端的存储容量要求：传统媒体需要下载完整的媒体文件，而媒体文件的容量一般都很大，所以需要占用客户端较大的存储空间；而通过利用流媒体技术，不需要占用客户端太大的缓存容量，也可以欣赏到媒体内容了。
9 流媒体技术的应用前景
 
互联网的迅猛发展和普及，为流媒体业务的发展提供了强大的市场动力，流媒体行业正在蓬勃发展。流媒体技术（及流媒体直播技术）广泛用于多媒体新闻发布、在线直播、网络广告、电子商务、视频点播、远程教育、远程医疗、网络电台、实时视频会议等互联网信息服务的方方面面。不难看出，在未来，流媒体技术的应用将会为网络信息交流带来革命性的变化，也将对人们的工作和生活产生深远的影响。
 
 

流媒体(streaming media)：是指将一连串的媒体数据压缩后，经过网上分段发送数据，在网上即时传输影音以供观赏的一种技术与过程，此技术使得数据包得以像流水一样发送；如果不使用此技术，就必须在使用前下载整个媒体文件。
 
多媒体兼指多媒体信息和多媒体技术，并以后者居多。多媒体信息是指集数据、文字、图形与图像为一体的综合媒体信息；多媒体技术则是将计算机技术与通信传播技术融为一体，综合处理、传送和储存多媒体信息的数字技术，它提供了良好的人机交互功能和可编程环境，极大的拓展了计算机的应用领域。流媒体的实质是一种多媒体文件，由于在网络上传输的过程中应用了流技术而命名。所谓流技术，就会把连续的影像和声音信息经过压缩处理后放到网站服务器，让用户一边下载一边观看、收听，而不需要等整个压缩文件下载到自己的机器后才可以观看的网络传输技术。这个过程的一系列相关的包称为”流”。流媒体实际指的是一种新的媒体传送方式，而非一种新的媒体。
 
在网络上传输音/视频等多媒体信息，主要有下载和流式传输两种方案。音频/视频(A/V)文件一般都较大，所以需要的存储容量也较大；同时由于网络带宽的限制，下载常常要花数分钟甚至数小时，所以这种处理方法延迟也很大。流式传输时，声音、影像或动画等时基媒体由音视频服务器向用户计算机的连续、实时传送，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看。当声音等时基媒体在客户机上播放时，文件的剩余部分将在后台从服务器内继续下载。流式不仅使启动延时成十倍、百倍地缩短，而且不需要太大的缓存容量。流式传输避免了用户必须等待整个文件全部从Internet上下载才能观看的缺点。
 
流式传输方式则是将整个A/V及3D等多媒体文件经过特殊的压缩方式分成一个个压缩包，由视频服务器向用户计算机连续、实时传送。在采用流式传输方式的系统中，用户不必像采用下载方式那样等到整个文件全部下载完毕，而是只需经过几秒或几十秒的启动延时即可在用户的计算机上利用解压设备(硬件或软件)对压缩的A/V、3D等多媒体文件解压后进行播放和观看。此时多媒体文件的剩余部分将在后台的服务器内继续下载。与单纯的下载方式相比，这种对多媒体文件边下载边播放的流式传输方式，不仅使启动延时大幅度地缩短，而且对系统缓存容量的需求也大大降低。
 
流媒体指在Internet/Intranet中使用流式传输技术的连续时基媒体，如：音频、视频或多媒体文件。流式媒体在播放前并不下载整个文件，只将开始部分内容存入内存，流式媒体的数据流随时传送随时播放，只是在开始时有一些延迟。流媒体实现的关键技术就是流式传输。
 
流式传输定义很广泛，主要指通过网络传送媒体(如视频、音频)的技术总称。其特定含义为通过Internet 将影视节目传送到PC机。实现流式传输有两种方法：实时流式传输(Real time streaming)和顺序流式传输(progressive streaming)。顺序流式传输是顺序下载，在下载文件的同时用户可观看在线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部分，在传输期间不根据用户连接的速度对下载顺序做调整。实时流式传输指保证媒体信号带宽与网络连接匹配，使媒体可被实时观看到。实时流式传输根据网络情况调整输出音视频的质量从而实现媒体的持续的实时传送，用户可快进或后退以观看前面或后面的内容。
 
一般说来，如视频为实时广播，或使用流式传输媒体服务器，或应用如RTSP的实时协议，即为实时流式传输。如使用HTTP服务器，文件即通过顺序流发送。采用哪种传输方法依赖你的需求。当然，流式文件也支持在播放前完全下载到硬盘。
 
顺序流式传输：是顺序下载，在下载文件的同时用户可观看在线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部分，顺序流式传输不像实时流式传输在传输期间根据用户连接的速度做调整。由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，它经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段，如片头、片尾和广告，由于该文件在播放前观看的部分是无损下载的，这种方法保证电影播放的最终质量。这意味着用户在观看前，必须经历延迟，对较慢的连接尤其如此。对通过调制解调器发布短片段，顺序流式传输显得很实用，它允许用比调制解调器更高的数据速率创建视频片段。尽管有延迟，毕竟可让你发布较高质量的视频片段。顺序流式文件是放在标准HTTP或FTP服务器上，易于管理，基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频，如：讲座、演说与演示。它也不支持现场广播，严格说来，它是一种点播技术。
 
实时流式传输：指保证媒体信号带宽与网络连接匹配，使媒体可被实时观看到。实时流与HTTP流式传输不同，他需要专用的流媒体服务器与传输协议。实时流式传输总是实时传送，特别适合现场事件，也支持随机访问，用户可快进或后退以观看前面或后面的内容。理论上，实时流一经播放就可不停止，但实际上，可能发生周期暂停。实时流式传输必须匹配连接带宽，这意味着在以调制解调器速度连接时图象质量较差。而且，由于出错丢失的信息被忽略掉，网络拥挤或出现问题时，视频质量很差。如欲保证视频质量，顺序流式传输也许更好。实时流式传输需要特定服务器，如：QuickTime Streaming Server、RealServer与Windows Media Server。这些服务器允许你对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议，如：RTSP (RealTime Streaming Protocol)或MMS (Microsoft Media Server)。这些协议在有防火墙时有时会出现问题，导致用户不能看到一些地点的实时内容。
 
流式传输的实现需要缓存：因为Internet以包传输为基础进行断续的异步传输，对一个实时A/V源或存储的A/V文件，在传输中它们要被分解为许多包，由于网络是动态变化的，各个包选择的路由可能不尽相同，故到达客户端的时间延迟也就不等，甚至先发的数据包还有可能后到。为此，使用缓存系统来弥补延迟和抖动的影响，并保证数据包的顺序正确，从而使媒体数据能连续输出，而不会因为网络暂时拥塞使播放出现停顿。通常高速缓存所需容量并不大，因为高速缓存使用环形链表结构来存储数据：通过丢弃已经播放的内容，流可以重新利用空出的高速缓存空间来缓存后续尚未播放的内容。流式传输的实现需要合适的传输协议。由于TCP需要较多的开销，故不太适合传输实时数据。
 
流式传输的过程一般是这样的：用户选择某一流媒体服务后，Web浏览器与Web服务器之间使用HTTP/TCP交换控制信息，以便把需要传输的实时数据从原始信息中检索出来；然后客户机上的Web浏览器启动A/V Helper程序，使用HTTP从Web服务器检索相关参数对Helper程序初始化。这些参数可能包括目录信息、A/V数据的编码类型或与A/V检索相关的服务器地址。A/V Helper程序及A/V服务器运行实时流控制协议(RTSP)，以交换A/V传输所需的控制信息。与CD播放机或VCRs所提供的功能相似，RTSP提供了操纵播放、快进、快倒、暂停及录制等命令的方法。A/V服务器使用RTP/UDP协议将A/V数据传输给A/V客户程序(一般可认为客户程序等同于Helper程序)，一旦A/V数据抵达客户端，A/V客户程序即可播放输出。需要说明的是，在流式传输中，使用RTP/UDP和RTSP/TCP两种不同的通信协议与A/V服务器建立联系，是为了能够把服务器的输出重定向到一个不同于运行A/V Helper程序所在客户机的目的地址。实现流式传输一般都需要专用服务器和播放器。
 
流媒体格式：声音流、视频流、文本流、图像流、动画流
 
(1). RA：实时声音。
 
(2). RM：实时视频或音频的实时媒体。
 
(3). RT：实时文本。
 
(4). RP：实时图像。
 
(5). SMIL：同步的多重数据类型综合设计文件。
 
(6). SWF：macromedia的real flash和shockwave flash动画文件。
 
(7). RPM：HTML文件的插件。
 
(8). RAM：流媒体的元文件，是包含RA、RM、SMIL文件地址(URL地址)的文本文件。
 
(9). CSF：一种类似媒体容器的文件格式，可以将非常多的媒体格式包含在其中，而不仅仅限于音、视频。
 
流媒体传输协议：
 
(1). RSVP(Resource Reservation Protocol, 资源预留协议)：最初是IETF为QoS的综合服务模型定义的一个信令协议，用于在流(flow)所经路径上为该流进行资源预留，从而满足该流的QoS要求。资源预留的过程从应用程序流的源节点发送Path消息开始，该消息会沿着流所经路径传到流的目的节点，并沿途建立路径状态；目的节点收到该Path消息后，会向源节点回送Resv消息，沿途建立预留状态，如果源节点成功收到预期的Resv消息，则认为在整条路径上资源预留成功。RSVP是一个在ip上承载的信令协议，它允许路由器网络任何一端上终端系统或主机在彼此之间建立保留带宽路径，为网络上的数据传输预定和保证Qos。它对于需要保证带宽和时延的业务，如语音传输，视频会议等具有十分重要的作用。
 
(2). RTP(Real-time Transport Protocol, 实时传输协议)：是一个网络传输协议，详细说明了在互联网上传递音频和视频的标准数据包格式。它一开始被设计为一个多播协议，但后来被用在很多单播应用中。RTP协议常用于流媒体系统(配合RTSP协议)，视频会议和一键通(Push to Talk)系统(配合H.323或SIP)，使它成为IP电话产业的技术基础。RTP协议和RTP控制协议RTCP一起使用，而且它是创建在UDP协议上的。RTP为数据提供了具有实时特征的端对端传送服务，如在组播或单播网络服务下的交互式视频音频或模拟数据。应用程序通常在 UDP上运行RTP以便使用其多路结点和校验服务；这两种协议都提供了传输层协议的功能。但是RTP可以与其它适合的底层网络或传输协议一起使用。如果底层网络提供组播方式，那么RTP可以使用该组播表传输数据到多个目的地。
 
RTP本身并没有提供按时发送机制或其它服务质量(QoS)保证，它依赖于底层服务去实现这一过程。 RTP并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如在视频解码中，就不需要顺序解码。
 
(3). RTCP(Real-time Transport Control Protocol, 实时传输控制协议)：是实时传输协议(RTP)的一个姐妹协议。RTP使用一个偶数UDP port，而RTCP则使用RTP的下一个port，也就是一个奇数port。RTCP与RTP联合工作，RTP实施实际数据的传输，RTCP则负责将控制包送至电话中的每个人。RTCP为RTP媒体流提供信道外(out-of-band)控制。RTCP本身并不传输数据，但和RTP一起协作将多媒体数据打包和发送。RTCP定期在流多媒体会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量(Quality of Service)提供反馈。
 
RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，jitter，单向和双向网络延迟等等，网络应用程序即可利用RTCP的统计信息来控制传输的品质，比如当网络带宽高负载时限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证。
 
(4). MMS(Microsoft Media Server Protocol, 微软媒体服务协议)：用来访问并流式接收 Windows Media服务器中.asf文件的一种协议。MMS协议用于访问Windows Media发布点上的单播内容。MMS是连接Windows Media单播服务的默认方法。若观众在Windows Media Player中键入一个URL以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS 协议引用该流。MMS的预设埠(端口)是1755。当使用MMS协议连接到发布点时，使用协议翻转以获得最佳连接。”协议翻转”始于试图通过MMSU连接客户端。MMSU是MMS协议结合UDP数据传送。如果MMSU连接不成功，则服务器试图使用MMST。MMST是MMS协议结合TCP数据传送。
 
(5). RTSP(Real-Time Streaming Protocol, 实时流传输协议)：是由Real Network和Netscape共同提出的如何有效地在IP网络上传输流媒体数据的应用层协议。RTSP对流媒体提供了诸如暂停，快进等控制，而它本身并不传输数据，RTSP的作用相当于流媒体服务器的远程控制。服务器端可以自行选择使用TCP或UDP来传送串流内容，它的语法和运作跟HTTP 1.1类似，但并不特别强调时间同步，所以比较能容忍网络延迟。RTSP是应用级协议，控制实时数据的发送。RTSP提供了一个可扩展框架，使实时数据，如音频与视频的受控点播成为可能。数据源包括现场数据与存储在剪辑中数据。该协议目的在于控制多个数据发送连接，为选择发送通道，如UDP、组播UDP与TCP，提供途径，并为选择基于RTP上发送机制提供方法。RTSP建立并控制一个或几个时间同步的连续流媒体。尽管连续媒体流与控制流交换是可能的，通常它本身并不发送连续流。换言之，RTSP充当多媒体服务器的网络远程控制。RTSP连接没有绑定到传输层连接，如TCP。在RTSP连接期间，RTSP用户可打开或关闭多个对服务器的可传输连接以发出RTSP请求。此外，可使用无连接传输协议，如UDP。RTSP流控制的流可能用到RTP，但RTSP操作并不依赖用于携带连续媒体的传输机制。更详细介绍可参考：https://blog.csdn.net/fengbingchun/article/details/90546484
 
(6). MIME(Multipurpose Internet Mail Extensions, 多用途互联网邮件扩展类型)：是设定某种扩展名的文件用一种应用程序来打开的方式类型，当该扩展名文件被访问的时候，浏览器会自动使用指定应用程序来打开。多用于指定一些客户端自定义的文件名，以及一些媒体文件打开方式。它是一个互联网标准，扩展了电子邮件标准，使其能够支持：非ASCII字符文本；非文本格式附件(二进制、声音、图像等)；由多部分(multiple parts)组成的消息体；包含非ASCII字符的头信息(Header information)。
 
(7). RTMP(Real Time Messaging Protocol, 实时消息传输协议)：是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的开放协议。该协议基于TCP，是一个协议族，包括RTMP基本协议及RTMPT/RTMPS/RTMPE等多种变种。RTMP是一种设计用来进行实时数据通信的网络协议，主要用来在Flash/AIR平台和支持RTMP协议的流媒体/交互服务器之间进行音视频和数据通信。支持该协议的软件包括Adobe Media Server/Ultrant Media Server/red5等。
 
(8). RTMFP(Secure Real-Time Media Flow Protocol)：是Adobe公司开发的一套新的通信协议，该协议可以让使用Adobe Flash Player的终端用户之间进行直接通信。用Adobe AIR框架开发的程序也可以用此协议来发布直播、实时信息。
 
(9). HLS(HTTP Live Streaming)：是Apple的动态码率自适应技术。主要用于PC和Apple终端的音视频服务。包括一个m3u(8)的索引文件，TS媒体分片文件和key加密串文件。
 
流媒体播放方式：
 
(1). 单播：在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机，这种传送方式称为单播。每个用户必须分别对媒体服务器发送单独的查询，而媒体服务器必须向每个用户发送所申请的数据包拷贝。这种巨大冗余首先造成服务器沉重的负担，响应需要很长时间，甚至停止播放；管理人员也被迫购买硬件和带宽来保证一定的服务质量。
 
(2). 组播：IP组播技术构建一种具有组播能力的网络，允许路由器一次将数据包复制到多个通道上。采用组播方式，单台服务器能够对几十万台客户机同时发送连续数据流而无延时。媒体服务器只需要发送一个信息包，而不是多个；所有发出请求的客户端共享同一信息包。信息可以发送到任意地址的客户机，减少网络上传输的信息包的总量。网络利用效率大大提高，成本大为下降。
 
(3). 点播：点播连接是客户端与服务器之间的主动的连接。在点播连接中，用户通过选择内容项目来初始化客户端连接。用户可以开始、停止、后退、快进或暂停流。点播连接提供了对流的最大控制，但这种方式由于每个客户端各自连接服务器，却会迅速用完网络带宽。
 
(4). 广播：指的是用户被动接收流。在广播过程中，客户端接收流，但不能控制流。例如，用户不能暂停、快进或后退该流。广播方式中数据包的单独一个拷贝将发送给网络上的所有用户。使用单播发送时，需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽。组播吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户。组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。
 
流媒体技术应用：流媒体技术广泛用于多媒体新闻发布、在线直播、网络广告、电子商务、视频点播、远程教育、远程医疗、网络电台、实时视频会议等互联网信息服务的方方面面。流媒体技术的应用将为网络信息交流带来革命性的变化，对人们的工作和生活将产生深远的影响。一个完整的流媒体解决方案应是相关软硬件的完美集成，它大致包括下面几个方面的内容：内容采集、视音频捕获和压缩编码、内容编辑、内容存储和播放、应用服务器内容管理发布及用户管理等。流媒体技术和声音信息经过压缩处理后放上网站服务器，让用户一边下载一边观看、收听，而不要等整个压缩文件下载到自己的计算机上才可以观看的网络传输技术。该技术先在使用者端的计算机上创建一个缓冲区，在播放前预先下一段数据作为缓冲，在网路实际连线速度小于播放所耗的速度时，播放程序就会取用一小段缓冲区内的数据，这样可以避免播放的中断，也使得播放品质得以保证。
 
流媒体传输流程：在流式传输的实现方案中，一般采用HTTP/TCP来传输控制信息，而用RTP/UDP来传输实时声音数据。具体的传输流程如下：
 
(1). Web浏览器与Web服务器之间使用HTTP/TCP交换控制信息，以便把需要传输的实时数据从原始信息中检索出来。
 
(2). 用HTTP从Web服务器检索相关数据，由A/V播放器进行初始化。
 
(3). 从Web服务器检索出来的相关服务器的地址定位A/V服务器。
 
(4). A/V播放器与A/V服务器之间交换A/V传输所需要的实时控制协议。
 
(5). 一旦A/V数据抵达客户端，A/V播放器就可播放。
 
主流的流媒体技术有三种：分别是RealNetworks公司的RealMedia、Microsoft公司的WindowsMediaTechnology和Apple公司的QuickTime。这三家的技术都有自己的专利算法、专利文件格式甚至专利传输控制协议。
 
UDP和TCP协议在实现数据传输时的可靠性有很大的区别：TCP协议中包含了专门的数据传送校验机制，当数据接受方收到数据后，将自动向发送方发出确认信息，发送方在接收到确认信息后才继续传送数据，否则将一直处于等待状态。而UDP协议则不同，UDP协议本身并不能做任何校验。由此可以看出，TCP协议注重传输质量，而UDP协议则注重传输速度。因此，对于对传输质量要求不是很高，而对传输速度则有很高的要求的视音频流媒体文件来说，采用UDP协议则更合适。
 
流媒体的传输过程中需要缓存的支持：因为Interent是以包为单位进行异步传输的，因此多媒体数据在传输中要被分解成许多包，由于网络传输的不稳定性，各个包选择的路由不同，所以到达客户端的时间次序可能发生改变，甚至产生丢包的现象。为此，必须采用缓存技术来纠正由于数据到达次序发生改变而产生的混乱状况，利用缓存对到达的数据包进行正确排序，从而使视音频数据能连续正确地播放。缓存中存储的是某一段时间内的数据，数据在缓存中存放的时间是暂时的，缓存中的数据也是动态的，不断更新的。流媒体在播放时不断读取缓存中的数据进行播放，播放完后该数据便被立即清除，新的数据将存入到缓存中。因此，在播放流媒体文件时并不需占用太大的缓存空间。
 
一些术语：
 
直播过程：[采样] --> [编码] --> [推流] --> [接流] -->[流处理] --> [分发] -->[拉流] --> [解码] -->[播放]。
 
编码：就是对视频/音频数据进行压缩的过程。视频压缩算法中通常会将视频帧分为不同类型，常见的有I帧、P帧、B帧三种。视频是一张张图片的序列，但如果每张图片都完整，就太大了，因而会将视频序列分成三种帧：(1). I帧：也称关键帧。里面是完整的图片，只需要本帧数据，就可以完成解码。(2). P帧：前向预测编码帧。P帧表示的是这一帧跟之前一个关键帧(或P帧)的差别，解码时需要用之前缓存的画面，叠加上和本帧定义的差别，生成最终画面。(3). B帧：双向预测内插编码帧。B帧记录的是本帧与前后帧的差别。要解码B帧，不仅要取得之前的缓存画面，还要解码之后的画面，通过前后画面的数据与本帧数据的叠加，取得最终的画面。I帧最完整，B帧压缩率最高，而压缩后帧的序列，应该是IBBP间隔出现。这就是通过时序进行编码。
 
I帧：帧内编码帧，特点：
 
(1). 它是一个全帧压缩编码帧。它将全帧图像信息进行JPEG压缩编码及传输;
 
(2). 解码时仅用I帧的数据就可重构完整图像;
 
(3). I帧描述了图像背景和运动主体的详情;
 
(4). I帧不需要参考其他画面而生成;
 
(5). I帧是P帧和B帧的参考帧(其质量直接影响到同组中以后各帧的质量);
 
(6). I帧是帧组GOP的基础帧(第一帧),在一组中只有一个I帧;
 
(7). I帧不需要考虑运动矢量;
 
(8). I帧所占数据的信息量比较大。
 
P帧：前向预测编码帧，P帧的预测与重构：P帧是以I帧为参考帧,在I帧中找出P帧”某点”的预测值和运动矢量,取预测差值和运动矢量一起传送。在接收端根据运动矢量从I帧中找出P帧”某点”的预测值并与差值相加以得到P帧”某点”样值,从而可得到完整的P帧。又称predictive-frame，通过充分将低于图像序列中前面已编码帧的时间冗余信息来压缩传输数据量的编码图像，也叫预测帧。特点：
 
(1). P帧是I帧后面相隔1~2帧的编码帧;
 
(2). P帧采用运动补偿的方法传送它与前面的I或P帧的差值及运动矢量(预测误差);
 
(3). 解码时必须将I帧中的预测值与预测误差求和后才能重构完整的P帧图像;
 
(4). P帧属于前向预测的帧间编码。它只参考前面最靠近它的I帧或P帧;
 
(5). P帧可以是其后面P帧的参考帧,也可以是其前后的B帧的参考帧;
 
(6). 由于P帧是参考帧,它可能造成解码错误的扩散;
 
(7). 由于是差值传送,P帧的压缩比较高。
 
B帧：双向预测内插编码帧。B帧的预测与重构：B帧以前面的I或P帧和后面的P帧为参考帧,”找出”B帧”某点”的预测值和两个运动矢量,并取预测差值和运动矢量传送。接收端根据运动矢量在两个参考帧中”找出(算出)”预测值并与差值求和,得到B帧”某点”样值,从而可得到完整的B帧。又称bi-directional interpolated prediction frame，既考虑与源图像序列前面已编码帧，也顾及源图像序列后面已编码帧之间的时间冗余信息来压缩传输数据量的编码图像，也叫双向预测帧。特点：
 
(1). B帧是由前面的I或P帧和后面的P帧来进行预测的;
 
(2). B帧传送的是它与前面的I或P帧和后面的P帧之间的预测误差及运动矢量;
 
(3). B帧是双向预测编码帧;
 
(4). B帧压缩比最高,因为它只反映丙参考帧间运动主体的变化情况,预测比较准确;
 
(5). B帧不是参考帧,不会造成解码错误的扩散。
 
GOP：视频流中两个I帧的时间距离。
 
音频编码格式有：AAC、AMR、PCM、ogg、AC3、DTS、APE、AU、WMA。
 
视频编码格式有：Xvid(MPEG4)、H264、H263、MPEG1、MPEG2、AC-1、RM、RMVB、H.265。
 
码率：码流(Data Rate)是指视频文件在单位时间内使用的数据流量，也叫码率或码流率，通俗一点的理解就是取样率，是视频编码中画面质量控制中最重要的部分，一般我们用的单位是kb/s或者Mb/s。一般来说同样分辨率下，视频文件的码流越大，压缩比就越小，画面质量就越高。码流越大，说明单位时间内采样率越大，数据流，精度就越高，处理出来的文件就越接近原始文件，图像质量越好，画质越清晰，要求播放设备的解码能力也越高。当然，码率越大，文件体积也越大。
 
通常来说，一个视频文件包括了画面(视频)及声音(音频)，例如一个RMVB的视频文件，里面包含了视频信息和音频信息，音频及视频都有各自不同的采样方式和比特率，也就是说，同一个视频文件音频和视频的比特率并不是一样的。而我们所说的一个视频文件码流率大小，一般是指视频文件中音频及视频信息码流率的总和。
 
帧率：也称为FPS(Frames Per Second，帧/秒)，是指每秒钟刷新的图片的帧数，也可以理解为图形处理器每秒钟能够刷新几次。越高的帧速率可以得到更流畅、更逼真的动画。每秒钟帧数(FPS)越多，所显示的动作就会越流畅。
 
分辨率：视频分辨率是指视频成像产品所成图像的大小或尺寸。常见的视像分辨率有640*480，1024*768。在成像的两组数字中，前者为图片长度，后者为图片的宽度，两者相乘得出的是图片的像素，长宽比一般为4：3。480P：640*480个像素点；720P：1280*720个像素点；1080P：1920*1080个像素点。
 
YUV格式有两大类：planar和packed。对于planar的YUV格式，先连续存储所有像素点的Y，紧接着存储所有像素点的U，随后是所有像素点的V。对于packed的YUV格式，每个像素点的Y,U,V是连续交替存储的。YUV也是一种颜色编码方法，主要用于电视系统以及模拟视频领域，它将亮度信息(Y)与色彩信息(UV)分离，没有UV信息一样可以显示完整的图像，只不过是黑白的，这样的设计很好地解决了彩色电视机与黑白电视的兼容问题。并且，YUV不像RGB那样要求三个独立的视频信号同时传输，所以用YUV方式传送占用极少的频宽。YUV分为三个分量，”Y”表示明亮度(Luminance或Luma)，也就是灰度值；而”U”和”V” 表示的则是色度(Chrominance或Chroma)，作用是描述影像色彩及饱和度，用于指定像素的颜色。
 
硬编解码：通过硬件实现编解码，减轻CPU计算的负担，如GPU等。
 
软编解码：如H264、H265、MPEG-4等编解码算法，更消耗CPU。
 
流：一般指通过网络传输的有序数据序列，如直播流，点播流。
 
推流：指的是把采集阶段封包(将音频，视频打包成packet)好的内容传输到流媒体服务器的过程。
 
接流：网络协议将编码好的视频流，从主播端推送到服务器，在服务器上有个运行了同样协议的服务端来接收这些网络数据包，从而得到里面的视频流，这个过程称为接流。
 
拉流(抓流)：指流媒体服务器已有直播内容，用指定地址进行拉取的过程。
 
解码：把获取到的数据解压缩，恢复成原始数据。
 
以上内容均来自网络整理，主要参考：
 
1. https://baike.baidu.com/item/%E6%B5%81%E5%AA%92%E4%BD%93
 
2. https://juejin.im/post/5a6873fd51882573497916bb
 
3. https://blog.csdn.net/tttyd/article/details/12032357
 
4. https://segmentfault.com/a/1190000017431963
 
GitHub：https://github.com/fengbingchun/OpenCV_Test

一、流媒体定义
 
所谓流媒体，是指采用流式传输的方式在Iternet播放的媒体格式。流媒体又称流式媒体，是将普通多媒体，如音频、视频、动画等，经过特殊编码，使其成为在网络中使用流式传输的连续时基媒体，以适应在网络上边下载边播放的方式。其具有连续性、实时性、时序性三个特点。在这个过程中，网络上传输的一系列相关的数据包称为流（Stream）。
 
二、流媒体特点
 
1.启动延时大幅度地缩短
 用户不用等待所有内容下载到硬盘上才开始浏览，启动延时大幅度缩短，一般在带宽足够的情况下，影片片段基本在一分钟以内就显示在客户端上，而且在播放过程基本不会出现断续的情况。另外，全屏播放对播放速度几乎无影响，但快进、快倒时需要时间等待。
 
2.对系统缓存容量的需求大大降低
 Internet是以包传输为基础进行断续的异步传输，数据被分解为许多包进行传输，动态变化的网络使各个包可能选择不同的路由，故到达用户计算机的时间延迟也就不同。所以，在客户端需要缓存系统来弥补延迟和抖动的影响及保证数据包传输顺序的正确，使媒体数据能连续输出，不会因网络暂时拥堵而使播放出现停顿。虽然流媒体仍需要缓存，但由于不需要把所有的动画、视音频内容都下载到缓存中，因此，对缓存的容量要求大大降低。
 
3.流式传输的实现有特定的实时传输协议
 流媒体的流式告的过程采用RTSP、RTP、RTCP等实时传输协议，更加适合动画、音视频等流媒体文件在互联网上传输。
 
三、流媒体组成
 
一个基本的流媒体系统必须包括编码器（Encoder）、流媒体服务器（Server）和客户端播放器（Player）三个组成部分。各组成部分之间通过特定的协议互相通信，并按照特定格式互相交换文件数据。其中编码器用于将原始的音/视频转换成合适的流格式文件，服务器向客户端发送编码后的媒体流，客户端播放器则负责解码和播放接收到的媒体数据。
 
 1.编码器
 编码器的功能是对输入的原始音、视频信号进行压缩编码。不同的流媒体业务，对编码器有不同的性能要求。目前常用的视频编码方案有MPEG-4、H.264和Microsoft公司的Windows Media Video采用的AC-1；音频编码方案有MP3、MPEG-2、AAC、AMR和AMR-WB等。多媒体编码器所生成的码流只包含了解码该码流所必需的信息，不包含媒体间的同步、随机访间等系统信息，因此编码后的多媒体数据仍要被组织成为流媒体文件格式用于传输或存储。
 2.流媒体服务器
 流媒体服务器用来存储和控制流媒体数据，并向客户端发送流媒体文件。
 流媒体服务器的主要功能有：
 （1）响应客户的请求，把媒体数据传送给客户。流媒体服务器在流媒体传送期间必须与客户的播放器保持双向通信（这种通信 是必需的，因为客户可能随时暂停或快放一个文件）。
 （2）响应广播的同时能够及时处理新接收的实时广播数据，并将其编码。
 （3）可提供其他额外功能，如数字权限管理（DRM）、插播广告、分割或镜像其他服务器的流，还有组播。
 3.客户端播放器
 音/视频数据包经网络传输到客户端后，先进入一个缓冲队列等待，这个缓冲队列中的所有数据包按照包头的序列号排序，如果有迟到的包，则按序列号重新插入正确的位置上，这样就避免了乱序的问题。
 客户端每次从队列头部读取一帧数据，从包头的时间标记中解出该顿的播放时间，然后进行音/视频同步处理。同步后的数据将送入解码器进行解码，解码后的数据被送人一个循环读取的缓冲中等待。一旦该帧的播放时间到达，就将解码数据从缓冲中取出，送入播放模块进行显示或播放。
 
四、流媒体实现
 
在网络上传输音/视频等多媒体信息，目前主要有下载列流式传输两种方案。流式媒体在播放前并不下载整个文件，只将开始部分内容存人内存，流式媒体的数据流随时传送随时播放，只在开始时有一些延迟。流媒体实现的关键技术就是流式传输。
 实现流式传输需要使用缓存机制。因为音频或视频数据在网络中是以包的形式传输的，而网络是动态变化的，各个数据包选择的路由可能不尽相同，到达客户端所需的时间也就不一样，有可能会出现先发的数据包后到。因此，客户端如果按照包到达的次序播放数据，必然会得到不正确的结果。使用缓存机制就可以解决这个问题，客户端收到数据包后先缓存起来，播放器再从缓存中按次序读取数据。
 
客户端的流媒体播放器与流媒体服务器之间交换控制信息时使用的是RTSP协议，它是基于TCP协议的一种应用层协议，默认使用的是554端口。RTSP协议提供了有关流媒体播放、快进、快倒、暂停及录制等操作的命令和方法。通过RTSP协议，客户端向服务器提出了播放某一流媒体资源的请求，服务器响应了这个请求后，就可以把流媒体数据传输给客户端。
 需要注意的是，RTSP协议并不具备传输流媒体数据的功能，承担流媒体数据传输任务的是另一种基于UDP的RTP协议，但在RTP协议传输流媒体数据的过程中，RTSP连接是一直存在的，并且控制着流媒体数据的传输。一旦流媒体数据到达了客户端，流媒体播放器就可以播放输出。流媒体的数据和控制信息使用不同的协议和连接时，还可以带来一个好处，就是播放流媒体的客户机和控制流媒体播放的客户机可以是不同的计算机。
 
实现流式传输有两种方式：实时流式传输（Realtime Streaming）和顺序流式传输（Progressive Streaming）。一般说来，如视频为实时广播，或使用流式传输媒体服务器，或应用如RTSP的实时协议，即为实时流式传输。如使用HTTP服务器，文件即通过顺序流发送。流式文件也支持在播放前完全下载到硬盘。
 
1.顺序流式传输
 顺序流式传输是顺序下载，在下载文件的同时用户可观看在线媒体，在给定时刻，用户只能观看已下载的那部分，而不能跳到还未下载的前头部分，顺序流式传输不像实时流式传输在传输期间根据用户连接的速度做调整。由于标准的HTTP服务器可发送这种形式的文件，也不需要其他特殊协议，它经常被称作HTTP流式传输。顺序流式传输比较适合高质量的短片段，如片头、片尾和广告，由于该文件在播放前观看的部分是无损下载的，这种方法保证电影播放的最终质量。这意味着用户在观看前，必须经历延迟，对较慢的连接尤其如此。对通过调制解调器发布短片段，顺序流式传输显得很实用，它允许用比调制解调器更高的数据速率创建视频片段。尽管有延迟，但可以发布较高质量的视频片段。
 顺序流式文件是放在标准HTTP或FTP服务器上，易于管理，基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频，如讲座、演说与演示。它也不支持现场广播，严格说来，它是一种点播技术。
 
2.实时流式传输
 实时流式传输指保证媒体信号带宽与网络连接匹配，使媒体可被实时观看到。实时流与HTTP流式传输不同，它需要专用的流媒体服务器与传输协议。
 实时流式传输总是实时传送，特别适合现场事件，也支持随机访问，用户可快进或后退以观看前面或后面的内容。理论上，实时流一经播放就可不停止，但实际上，可能发生周期暂停。
 实时流式传输必须匹配连接带宽，这意味着在以调制解调器速度连接时图像质量较差。而且，由于出错丢失的信息被忽略掉，网络拥挤或出现问题时，视频质量很差。若要保证视频质量，应选择顺序流式传输。
 实时流式传输需要特定服务器，如QuickTime Streaming Server、RealSermer与品你务MGdiasaner。这些服务器允许对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。
 实时流式传输还需要特殊网络协议，如RTSP（Realtlime Streaming Protocol）或MMS（Microsoft Media Server）。这些协议在有防火墙时会出现问题，导致用户不能看到一些地点的实时内容。
 
五、流媒体播放
 
从不同的角度来看，流媒体播放方式的含义不同。
 
（1）从用户参与的角度来看，可分为点播和广播两种方式。
 
点播指用户主动与服务器进行连接，发出选择节目内容的请求，服务器应用户请求将节目内容传输给用户。在播放过程中，用户可以对播放的流进行开始、停止、后退、快进或暂停流。点播连接提供了对流的最大控制，但这种方式由于每个客户端各自连接服务器，会迅速用完网络带宽。
 广播指的是媒体服务器主动发送流数据，用户被动接收流数据的方式。在广播过程中，客户端只能接收流，但不能控制流，例如，用户不能进行暂停、快进或后退操作。这种方式类似于电台广播或电视直播，用户可选择频道接收所需的广播节目，但是在收听收看节目时，不能随意控制节目的播放流程，在有些流媒体产品中将此称为直播。
 
（2）从服务器端传输数据的方式来看，可以分为单播、多播和广播3种发布方式。
 
IP协议支持单播、广播和多播（组播）3种地址类型。由于流媒体服务是在IP网络中实现的，因此流媒体在网上传输也有相应的三种方式。
 单播指在客户端与媒体服务器之间需要建立一个单独的数据通道，即从一台服务器发送的每个数据包只能传送给一个客户机。单播是一种典型的点对点传输方式。每个用户必须分别对媒体服务器发送单独的请求，而媒体服务器必须向每个用户发送所请求的数据包复制，每份数据复制都要经过网络传输，占用带宽和资源，如果请求的用户多起来，网络和服务器将不堪重负。
 多播又称组播，是一对多连接，多个客户端可以从服务器接收相同的流数据，即所有发出请求的客户端共享同一流数据，从而节省带宽资源。多播将一个数据流发送给多个客户端，而不是分别发送给每个客户端，客户端直接连接到多播流，而不是服务器。采用这种方式，一台服务器甚至能够对数万台客户机同时发送连续的数据流，而无延时的现象发生。
 还有一种传输方式称为广播，在广播过程中，数据包的单独一个复制将发送给网络上的所有用户。不管用户是否需要，都进行广播传输，浪费了网络资源。为阻止广播风暴，一般将广播限制在一个子网中，流媒体传输中并不采用这种方式。这里的广播是指传输方式，而前面讲述的广播（直播）则指用户被动接收的播放方式。
 
在实际应用中，播放方式一般将上述方式结合起来，如点播单播、广播单播和广播多播。
 
六、流媒体传输质量控制
 
传输质量控制是制约流媒体服务性能的最重要因素。影响流媒体传输质量的因素主要包含以下几个。
 （1）端到端的延迟：包括传输时延、传播时延、排队时延。它是影响流媒体质量最重要的因素之一。必须根据网络的负载情况，控制在一个合理的范围之内。
 （2）时延抖动：是两个相邻分组的数据在网络传输过程中由于经过不同的网络延迟产生的。由于网络传输的不确定性，时延抖动是无法避免的，解决的方法通常是在接收端设置缓冲区，在数据流到达后，并不立即播放，而是保存在缓冲区，等到规定播放时间到来才进行播放。
 （3）丢包率：是指网络拥塞时，数据流没有及时到达接收端。这时丢失的数据包将直接影响到接收播放的质量，一般情况下，丢包率不得超过1%。
 （4）数据包的失序：每个数据帧都有一个序列号，以标记在流中正确的序号。在网络传输过程中，由于数据包经过不同的线路或丢包等原因，致使数据的顺序发生变化。解决的方法也是在接收端设置缓冲区，将接收到的数据进行重新组合，恢复原来的顺序。
 
流媒体是一种宽带业务，对于网络带宽、时延、延迟、和丢包率都有较高要求。目前流媒体领域已经发展了几种较为成熟的带宽适应和质量控制技术。
 （1）缓存（Caching）技术。由于互联网是以断续的异步包传输为基础，一个实时媒体流或媒体文件在传输中将被分成多个包传输。由于网络的延时、抖动等因素，包到达客户端的顺序和延迟可能不一样，可能出现先发的包后到的情况，因此需要缓存系统来弥补网络延迟和抖动的影响，以保证数据包的顺序正确以及不会因为网络暂时拥塞而出现播放停顿的现象。缓存技术一般采用环形链表结构存储数据，丢弃已发送或已播放内容并利用空出的空间存储将要发送或将要播放的内容，所以一般缓存不会很大。目前主要用到的缓存技术有正向缓存、反向缓存和透明代理缓存技术。微软Media Services 和RealSystem都提供服务器端和播放器端的缓存设定。
 （2）分流（spliting）技术。分流技术一般用在网络直播时。发送服务器通过UDP单播、UDP组播等方式将直播媒体流发送到分布在各地的多个接收服务器，客户端可以就近访问服务器获得较高质量的媒体流，同时减少带宽使用。发送服务器与接收服务器之间由高速链路连接。分流技术分推（Push）和拉（Pull）两种模式，目前微软Media Services 和RealSystem都支持分流技术。
 （3）内容分发网络（CDN）技术。CDN是近几年才发展起来的新技术，它作为基础IP网络之上的一个内容叠加网，通过引入主动内容管理、全局负载均衡和内容缓存等技术，可以将用户请求的流媒体内容发布到距离用户最近的网络边缘，从而提高用户访间的响应速度，并有效解决网络拥塞，最大限度地减轻骨干网络流量。CDN为在WAN或MAN范围开展流媒体业务提供了有效的QoS保证。
 （4）智能流技术。智能流技术出现之前，“视频流瘦化”方法以及“带宽协调”方法是解决流媒体传送速率的基本方法。

     声明：本博客提供免费软件仅可用于学习研究使用，不可用于传播非法媒体信息，否则自行承担法律后果
 
        自己从事流媒体近20载, 从没有可用的流媒体服务器到现在服务器遍地开花.  但尽管开源服务器众多,功能强大, 但却没有可以直接拿来使用的. 原因是配置安装困难,没有自己想要的接口,很难与现有系统对接.
 
       为解决这个问题, 自己就做了一个简单的安装包, 并且提供了众多的接口可以与WEB进行对接, 这样配置管理大大简化, 安装使用都非常简单.
 
       服务器单机下保守至少可以大码流3000并发, 性能非常不错.性能超CRtmpServer\FMS, 可以与NGINX-RTMP 相媲美. 比SRS使用更方便. 你可以做集群.提供HTTP RTMP 协议, 支持HLS.   rtmp协议做直播时能保证服务器产生的延迟不大于100毫秒,   目前有一家公司就是使用此服务做书法教学会议互动. 详细可以看下面的使用说明文档.
 
       我以前就是做流媒体这行的, 现在出于爱好,把核心重新升级完善, 免费贡献给大家使用. 目前北京还有4家公司在使用这个服务器核心做产品, 成都一家, 深圳一家.
 
      此流媒体服务有Windows版,  但Windows版有诸多的弊端且效率低, 后期我也都没有做同步更新, 你能在网上搜到的AMS KMS 都windows版的产品, 此处我只提供LINUX版流媒体服务核心, 你可以用它来做你自己的产品.
 
      它是CENTOS6.5中开发, 7.0也能正常运行.       其它系统版自己测试吧, 呵呵!
 
       欢迎大家来下载使用, 功能完全没有限制, 完全免费. 有问题可以留言.可以提出你宝贵的建议. 
 
大家有问题留言我会继续修改完善, 然后重新发布, 所以你要是使用, 可以定期上来看看, 下载资源看看版本号是不是改变了,反正我设的是0分  :- )
 
 
资源下载(独立使用版)  old-ams-nodependents.rar-直播技术文档类资源-CSDN下载
 
2021-03-21更新
 
说明： 如果你只是使用流媒体服务器请下载这个版本, 如果你之前下载过不能用，请重下载，之前传错了版本。有问题请留言。
 
 
新版下载
 
资源下载(平台版) ：ams-server-2021-8-17.rar-直播技术文档类资源-CSDN下载
 
 注意：新版本必须要安装完整平台(要把WEB安装完成)才能运行，只装一部分不能正常使用。
 
    说明：这个版本是配合WEB来形成一套流媒体平台的版本，如果你想自己搭一套完整的流媒体平台，请下载此版版本，其它相关的模块请参考其它博文。我建意大家都下载使用这个版本，你如果只使用流媒体服器可以从WEB后设置一下就可以，不会设置请留言。 这个版本修改了很多的BUG。
 
2021-4-6 更新
 
修改图片生成BUG
修改点播更新BUG             
2021-8-8更新
 
修改了无法生成连续剧的节目的BUG
加入了对中控的认证， 所有中控的相关认证都在此，这个认证授权是建立交互通道的过程。所以如果出现授权的情况，都是由于软件配置有问题。
 
 
现在屏幕采集\录像\rtmp推流工具也完成了第二版,所以同步更新一下博文. 
 
(第二版) 完全免费的屏幕采集\录屏\直播推流的一体化工具_wanghaisheng的专栏-CSDN博客
 
至此我们离毫秒级延迟又近了一步!! 大家给点鼓励呀, 让我能感觉到自己的价值. 呵呵
 
 
                                                                  AMS-SERVER安装与使用说明
 
                                                                                      MARK
 
 
环境与安装
LINUX环境目前在CentOS6.5.x86_64下测试通过.
 
安装
ams-server-2.14.2-2.x86_64.rpm 为安装文件.
 
ffmpeg-4.1.3-5.x86_64.rpm为AMS指定依赖文件,此FFMPEG不是通用FFMPEG
 
将两文件放入到LINUX下,在同级目录下执行命令完成安装.
 
命令如下
 
> rpm -ivh ams-server-2.14.2-6.x86_64.rpm
 
> rpm -ivh ffmpeg-4.1.3-5.x86_64.rpm
 
如果是系统是MINI CENTOS版本ffmpeg安装有可能会出现依赖项缺失的情况, 此时可以运行 yum install libxcb* 后再安装ffmpeg, 注意要配好网络.
 
安装完成后可以在控制台执行如下命令进行操作:
 
       ams start       启动AMS服务器
 
ams stop        退出AMS服务器
 
ams restart     重启AMS服务器
 
ams reset       恢复运行配置到初始状态, 但通过接口看到的是最后的配置内容, 只有通过接口再次再次运行 set 命令后才会写入到运行配置.
 
ams reload      重新加载配置文件, 通常在使用接口配置完成服务器后再用此命令重新加载一下,当然也可以直接通过接口直接进行加载.
 
ams status     可以查看服务器是否在运行.
 
提供返回值可解析的命令, 可以完成启动停止和状态获取三个功能.
 
ams if_start    启动AMS服务器,  成功输出0, 失败输出1, 如果是已经启动返回是PID值
 
ams if_stop     退出AMS服务器,  成功输出0, 失败输出1.
 
ams if_status  可以查看服务器是否在运行.  正在运行返回0, 失败返回1.
 
卸载
执行如下命令完成卸载
 
>ams stop
 
> rpm -e ams-server
 
> rpm -e ffmpeg
 
服务基本使用
服务器安装完成后,默认HTTP 端口为89, RTMP默认端口为1935.为了保证服务能正常在外部访问,请先关闭防火墙.
 
使用 http://IP:89/ 进行测试,如果能访问到服务器,那么会出现如下页面内容:
 
 
 
服务器提供两种协议的点播直播服务
 
直播
上传直播数据的地址连接形式如下:
 
rtmp://{ip}:{rtmp_port}/{app}/{streamname},
 
{app}  为应用名, 当为源服务器时 app 是　live; 若为边缘服务器时 app 是 publish. 是否为源服务器的角色可以在设置中把”org”变量设为1.
 
{streamname}为流名称.
 
在上传数据后可以使用两种协议进行观看:
 
RTMP    rtmp://{ip}:{rtmp_port}/live/{streamname}
 
HTTP    http://{ip}:{http_port}/{streamname}/index.m3u8
 
点播
对于点播只支持MP4, 点播的地址格如下
 
RTMP   rtmp://{ip}:{rtmp_port}/vod/{name }
 
HTTP    http://{ip}:{http_port}/{name }
 
HTTP播放连接有两个固定参数, 这两个参数可以指播放文件的某一段, 连接的形式如下: http://192.168.1.200:89/1.mp4?start=20&end=40 这说明是只播放第20秒到40秒, 对于播放器来说就相当于是一个小文件, 时长为20秒.  Start参数没有默认为开始0, end参数没有为播放至文件结束.
 
服务内部已经内置了一个点播节目,名称为1.mp4,可以直接进行访问测试
 
服务器配置
服务器配置接口格式:
 
http://{ip}:{http_port}/cfg/{cmd}
 
所有的请求方法都要使用POST,否则内部不会进行处理,并且目前密码认证还没有加入,参数传递暂时使用POST参数的形式,后面会修改为JSON.
 
其中的{cmd}命令变量有三个如下:
 
get     此命令是查看当前服务器的配置情况
 返回值为POST参数串如下:
 
hls_fragment=2&hls_playlist_length=4&rtmp_port=1935&http_port=88&http_notify=http://192.168.1.65:80/onplay.php&rtmp_notify=http://192.168.1.65:80/onplay.php&enable_http_vod_s_notify=1&enable_http_vod_e_notify=0&enable_http_live_s_notify=0&enable_http_live_e_notify=0&enable_rtmp_vod_s_notify=0&enable_rtmp_vod_e_notify=0&enable_rtmp_live_s_notify=0&enable_rtmp_live_e_notify=0&enable_rtmp_publish_s_notify=1&enable_rtmp_publish_e_notify=1&enable_rtmp_update_notify=0& allow_addr=192.169.1.65&record_path=/var/ams &upload_path=/var/ams/upload&enable_rtmp_record_process=1&enable_rtmp_record_manual=0&enable_http_upload_process=1&update_interval=30&org=0&rtmp_org_addr=rtmp://192.168.20.142:1935/live&http_org_addr=http://192.168.20.142:89"
 
set             是设置服务的配置
设置时可以设置某一个参数,也可同时设置多个参数,当多个参数时同样也用POST参数格式进行发送.
 
reload   在重设配置后,配置是不会立即生效的,只是做了配置的保存.要想生效只有重启服务器或使用此命令来加载配置.在重启的之后,原来提供服务的连接不会立刻断开,但不会再接受新连接.
参数说明
 
hls_fragment                  hls单切片时长,单位秒           
 
hls_playlist_length       HLS总切片时长,单位秒
 
rtmp_port                           RTMP协议监听端口
 
http_port                          HTTP协议监听端口
 
http_notify                          HTTP事件通知接口
 
rtmp_notify                        RTMP事件通知接口
 
enable_http_vod_s_notify       是否启用HTTP点播播放通知认证,1为是0为否
 
enable_http_vod_e_notify   是否启用HTTP点播结束通知,1为是0为否
 
enable_http_live_s_notify   是否启用HTTP直播播放通知认证,1为是0为否
 
enable_http_live_e_notify   是否启用HTTP直播播放结束通知,1为是0为否
 
enable_rtmp_vod_s_notify      是否启用rtmp点播播放通知认证,1为是0为否
 
enable_rtmp_vod_e_notify   是否启用rtmp点播结束通知,1为是0为否
 
enable_rtmp_live_s_notify   是否启用rtmp直播播放通知认证,1为是0为否
 
enable_rtmp_live_e_notify   是否启用rtmp直播播放结束通知,1为是0为否
 
enable_rtmp_publish_s_notify 是否启用RTMP发布开始通知
 
enable_rtmp_publish_e_notify 是否启用RTMP发布结束通知
 
enable_rtmp_update_notify   是否启用 RTMP 直播点播动态通知
 
allow_addr                                                  对于配置和控制接口调用时的允许地址.默认值为 all .   可以为一个单一的IP址值,也可是一个段 如 192.168.1.0/24 . 但无论何 127.0.0.1是可以使用的
 
record_path                                               录生成时的保存路路径,默认值为/var/ams,这个也是默认媒体库的位置. 如果是想直接用文件名进行播放时,请不要修改此变量.
 
upload_path                                               文件上传时的保存路径,默认值为/var/ams/upload
 
enable_rtmp_record_process               是否启用录像文件的处理过程,当启用之后会在录像完成后再对录像文件转封装为MP4, 并向通过接口向接口服务器发送类型为record_transfer_done的文件信息通知,默认开启,值为1, 0为不开启.
 
注意: 开启时rtmp_notify要正确的接口地址设值,否则无法向外发送通知.
 
enable_rtmp_record_manual       是否启用手动录像模式, 默认是自动,即有流上传就自动开始录像. 如果开启那么只用调用相应接口来启动停止某一路录像. 0为自动, 1为手动.
 
enable_http_upload_process                 是否启用上传文件的处理过程,当启用之后会在上传完成后再对上传文件转码为MP4, 如果是MP4文件那么将对文件进行快速播放处理. 并向通过接口向接口服务器发送类型为upload_transfer_done的文件信息通知,默认开启,值为1, 0为不开启. (这一部分功能好像没有实现完成,  大家可以先自己试一下, 时间太长了我自己都忘了 )
 
update_interval                                         直播发布的信息更新时间间隔
 
org                                                                默认为1,
 
表示是源服务器, 当单机使用时就是为源服务器,
 
rtmp_org_addr                                          当org的值为0时,即作边缘服务器时一定设置源服务器的拉推流址. 格式如前面示例.
 
http_org_addr                                           当org的值为0时,即作边缘服务器时一定设置源服务器的文件获取地址. 在此为点播文件的获取地址
 
 
注意: 对于HTTP的直点播的开始通知都是可以使用的,都是可以进行认证操作.但对于直播结束的通知由于受HTTP协议的限制,很可能是不断的断开重连,所以时间和流量要不断的累加计算, 使用起来效率并不是很高. 点播时只要文件下载完毕连接就会断开,所以结束时时间参数并不是用户的真正观看时间,最好是使用流量来统计.
 
鉴于HTTP连接的不确定性,推荐使用RTMP连接协议,只有在必须使用HTTP连接的再使用HTTP协议
 
回调接口说明
对于所有的接口返回的都是POST form参数,如果客户端请求时带有参数,比如用户名密码认证信息之类的,那么也会被在回调参数中出现, 参数对于RTMP及HTTP又略有不同.请看后面详细说明.
 
设置 RTMP/HTTP 流发布或播放回调。每次一个客户连接执行任务时，一个 HTTP 请求异步发送，命令处理会挂起 - 直到它返回结果码。之后再解析 HTTP 结果码。
 
* HTTP 2XX 返回码继续 RTMP/HTTP 会话。
 
* 其他返回码RTMP/HTTP 连接丢弃。终止客户端的连接
 
当客户断开连接时也会发起一个异步通知,连同其它通知一样回调后无论返回何HTTP CODE 都会认为是成功了. 但最好是返回200,这样内部能正常结束这个通知连接.
 
点播播放文件的指定
点播两种协议,在通知回复时要加入下面的http头信息,如
 
'Filename:{path}'  例: 'Filename:/var/ams/1.mp4'
 
要确保这个路径能被核心服务器读取,否则不能播放.
 
如果不使用Filename 的HTTP头,那么服务器会自动到默认媒体库中寻找文件进行播放.
 
录像控制
录像可能通过设置接口设为自动或手动,但此时是统一设置, 不能具体到每一上传流. 如果想对每路发布流进行控制,请在服务器设置中把enable_rtmp_record_manual设为1. 然后在流发布回调的回复中加入http协议头信息进行指定. 如下:
 
rec_path:/var/media       用来指定录像文件的存储位置, 注意路径必须存在,并且不以’/’结尾; 只要此流进行录像就会保存在这个路径下.
 
rec_name:myrecfile       用来指定录像时的文件名称, 不需要文件扩展名. 生成的文件名格式如下myrecfile_20190625004733.mp4
 
is_rec:1                                      指定是否录像, 如果为1则此流录像,否则不会录像.
 
RTMP 回调接口返回值
RTMP通知公共回调参数, 在上传播放开始时都会存在的参数如下
"app"                                 表示当前应用 ,当前应用类型如下
 
"Live"   直播
 
"vod"        点播
 
"clientid"                            客户端连接ID,在控制接口中可能会使用此参数指定客户端
 
"call"                                   回调类型 目前支持如下类型
 
"publish"                            直播节目上传开始
 
"publish_done"                  直播节目上传结束
 
"play"                                  播放开始
 
"play_done"                        播放结束
 
"record_transfer_done"           录像处理结束
 
"update_publish"   直播上传时的动态更新
 
"name"                               当前频道的名字 或 点播文件名称
 
"addr"                                 连接客户端的IP
 
 
在流发布或播放结束时或者动态更新通知时会出现如下的参数
"time"                       当前客户端的连接时长, 单位是秒
 
"timestamp"     当前客户端上传或播放的时间戳, 单位是毫秒
 
"totlebyte"              当前客户端的使用流量,字节为单位
 
在动态更新时的线路质量参数
“dropped”      当前线路的丢包数       
 
录像处理结束(record_transfer_done),参数如下
"duration"     文件时长, 单位秒
 
"size"         文件大小, 字节BYTE
 
"fps"          帧率
 
"bitrate"      平均码流, 单位bit
 
"wh"           宽高
 
" filepath"     生成录像文件的全路径,包括文件名称. 如果文件不存在值为”NONE”, 当录像文件有问题时可能是FLV文件,正常为MP4.
 
“filename”   录像文件的名字.当录像文件有问题时可能是FLV文件,正常为MP4.
 
“streamname”  录像文件的数据源,即流名称
 
"jpgpath"          生成录像截图文件的全路径, 如果截图失败值为”NONE”
 
“error”      是否过程中出现错误, 正确时值为0, 错误时为错误码.                      
 
录像结束后进行文件分析转储过程,在分析转存完成后才进行回调通知, 此时已经生了MP4文件以及相关的信息截图等.
 
此外此回调中的公共参数只有”call”一个,可以以此来辨别处理过程.
 
record_transfer_done是通过rtmp_notify进行的, 如果需要获悉此文件的关联信息,回调中有相关的参数.   
 
此回调是模拟了FORM提交的方式进行的POST数据传输, 因此除携带了POST参数信息外还提交了一个”file”的截图文件, 此回调在服务器请求失败时会隔5  10  15   20秒各请求一次,总共4次.
 
 
HTTP 回调接口返回值
HTTP通知公共回调参数, 在上传播放开始时都会存在的参数如下
"app"                                 表示当前应用 ,当前应用类型如下
 
"http_Live"   直播
 
"http_vod"       点播
 
"clientid"                           客户端连接ID,在控制接口中可能会使用此参数指定客户端
 
"call"                                   回调类型 目前支持如下类型
 
"play"                                  播放开始
 
"play_done"                        播放结束
 
“upload_transfer_done” 文件上传处理结束通知
 
"name"                              当前频道URI或点播文件名称 只会在通知开始时出现
 
"addr"                                连接客户端的IP
 
"curTime"                          指当前通知产生的时间
 
播放结束通知时会出现如下的参数
"time"                                 当前客户端的连接时长, 单位是秒
 
"totlebyte"                       当前客户端的使用流量,字节为单位
 
文件上传处理结束(upload_transfer_done ),参数如下   
"duration"             文件时长, 单位秒
 
"size"               文件大小, 字节BYTE
 
"fps"               帧率
 
"bitrate"            平均码流, 单位bit
 
"wh"               宽高
 
"file"                上传最终生成文件的全路径,上传文件正确处理完成后,原上传文件将被删除,只剩处理完成后MP4文件,此时参数值为MP4文件的路径, 当处理错误时此变量的值可能就是上传时的文件, 文件格式就是上传时的格式.
 
“filename”          文件名称
 
"jpgpath"               生成录像截图文件的全路径,如果截图失败值为”NONE”
 
“error”             是否过程中出现错误, 正确时值为0, 错误时为错误码.
 
注意此回调中的公共参数只有”call”一个,可以以此来辨别处理过程.
 
        upload_transfer_done是通过http_notify进行的,请在相应接口通知中进行处理.此回调是模拟了FORM提交的方式进行的POST数据传输, 因此除携带了POST参数信息外还提交了一个”file”的截图文件, 此回调在服务器请求失败时会隔5秒请求一次,总共4次.
 
控制接口说明
控制接口都是http的get方法
 
录像控制接口
格式如下:
 
http://{IP}:{HTTP_PORT}/control/record/start|stop?app=live&rec=rec&name={NAME}
 
start|stop     可以选择一个即可, start为启动录像, stop为停止录像, 录像模块
app=live      目前这个被固化, 照样设置就可以,预留扩展
rec=rec       目前这个被固化, 照样设置就可以,预留扩展
name={NAME}     这个是录像时生成的文件名称, 最终生成时会在后面追加一个时间 如{NAME}为 live1  那么录像生成的文件名称可能为live1_20190321173926.flv
成功返回录像文件地址
 
踢除客户端
RTMP客户端踢除接口格式如下:
http://{IP}:{HTTP_PORT}/control/drop/publisher|client? name={NAME}&addr={ADDR}&clientid={CLIENTID}
 
参数说明
 
publisher|client - publisher只能操作发布者, client可以操作所有客户端包含                               发布端.命令操作完成后会返回断开的连接数.
name         – 通知是指路踢除直播客户端使用, 如果不指定addr和clientid那么踢除这个直播通道下的所有客户端.对于点播不起效
addr          – 客户端的连接地址,如果此项不指定并且clientid也不指定将是所有.此项是指更为具体的描述客户端,只用在drop/client命令中生效.
clientid        – 用户连接后返回的clientId, 如果此项不指定并且addr也不指定将是所有.
返回值
 
执行后会返回当前被踢掉的客户端个数
 
例子
 
 
踢除名为live1且地址为192.168.1.65的所有客户端
 
http://192.168.1.144:89/control/drop/client?name=live1&addr=192.168.1.65
 
 
踢除名为live1的发布端,同时把所有名字为live1的所有播放端一并删除,返回值只有publisher的连接数
 
http://192.168.1.144:89/control/drop/publisher?name=live1
 
 
踢除clientid=985的发布端
 
http://192.168.1.144:89/control/drop/publisher?clientid=985
 
 
踢除所有发布端,同时把所有名字为live1的所有播放端一并删除
 
http://192.168.1.144:89/control/drop/publisher
 
 
踢除所有客户端,包含发布端和接收端
 
http://192.168.1.144:89/control/drop/client
 
 
 
踢除频道live1的所有客户端,包括上传端和播放端
 
http://192.168.1.144:89/control/drop/client?name=live1
 
 
踢除指定的客户端, 不管是上传端还是播放端
 
http://192.168.1.144:89/control/drop/client?clientid=737
 
 
HTTP客户端踢除接口格式如下
http://{IP}:{HTTP_PORT}/cfg/drop?clientid={CLIENTID}
 
参数说明
 
clientid – 用户连接后返回的clientId
 
对于HTTP客户端的删除都是一对一的,没有其它复杂的参数选项.
 
返回值:
 
成功返回 result=OK
 
失败返回 result=FAILED
 
 
HTTP媒体文件删除接口格式如下
http://{IP}:{HTTP_PORT}/cfg/delf?flie={filepath}
 
参数说明
 
filepath– 将要删除的媒体文件全路径
 
 
返回值:
 
成功返回 result=OK
 
失败返回 result=FAILED
 
 
系统运行状态信息
系统运行信息查看接口
接口:
http://{IP}:{89}/stat
 
说明:
此接口可以直接在浏览器中打开,以图表的方式进行当前过行信息的展示,如下:
 
 
 
 
系统运行概要信息获取接口
接口:
http://{IP}:{89}/stat/sys
 
说明
该接口仅支持GET方法, 正确返回200状态码并返回 xml字符串如下:
 
<?xml version="1.0" encoding="UTF-8"?>
 
<sta max_client="10000" max_stream="10000" http_kbps="0" http_live_cn="0" http_vod_cn="0" rtmp_out_kbps="0" rtmp_in_kbps="678" rtmp_vod_cn="0" rtmp_live_cn="0" rtmp_publish_cn="2"/>
 
参数说明
 
rtmp_publish_cn:    当前rtmp发布的流数目, 同时会对应一路的HTTP直播发布
 
rtmp_play_cn         RTMP 当前的播放连接数目
 
rtmp_in_kbps        RTMP 当前入口带宽
 
rtmp_out_kbps       RTMP 当前出口带宽
 
http_vod_cn         HTTP 当前点播连接数
 
http_live_cn        HTTP 当前直播的连接数
 
http_kbps           HTTP 当前的带宽情况
 
max_stream          最大发布流数
 
max_client          最大播放客户端数
 
 
 
获取当前会话连接的详情
接口:
http://{IP}:{89}/stat/all|channel|live|vod
 
说明
该接口仅支持GET方法, 正确返回200状态码并返回 xml字符串,如下:
 
 
标签<live>中的子元素<stream>是直播流, 有多少个上传发布就会有多少个<stream>, <stream>中子元素<client>是当前流中的所有连接客户端的信息,这里面的连接有两种, 当属性publishing=1时说明是发布连接,这种连接在一个流中只会存在一个, 当publishing=0时说明是接收连接,这种连接会有多个,有多少个用户在接收观看就会产生多少个.
 
标签<play>中的子元素<stream>是点播流, 当前用户正在观看几个文件就会产生几个流. <stream>中子元素<client>是当前流中的所有连接客户端的信息,即有几个用户在观看这个节目就会产生几个<client>.
 
在服务器设计原则中可能会有多个服务<server>(目前只有一个服务),每个<server>会有多个<application> , 目前只会有一个name=”live”和name=”vod”的两个应用.每个<application>可能会有<live>或<play>,也可能两者都有,目前每个应用中只会有其一.
 
<stream>标签属性
 
name="live22"          当前节目名称
 
active="1"                             当前状态, 目前此值只为1.
 
time="65298"                      节目服务时间, 直播标签专用
 
bw_in="1653288"               输入带宽, 直播标签专用
 
bytes_in="11182307"        输入字节, 直播标签专用
 
bw_out="0"                          输出带宽, 直播标签专用
 
bytes_out="0"                     输出字节, 直播标签专用
 
bw_audio="247728"          音频带宽, 直播标签专用
 
bw_video="1405560"        视频带宽, 直播标签专用
 
publishing="1"                     说明是直播发布, 直播标签专用
 
 
<client>标签属性
 
id="1"                                           客户端ID
 
address="192.168.20.34"   客户端地址
 
time="65300"                        客户端的连接时间
 
totlebyte="11220500"           客户端总计发送字节
 
timestamp="65199"               当前发送数据的时间截
 
dropped="0"                              发送丢包数量, 点播不存在丢包值所以没有此属性
 
 
publishing="1"                   直播连接属性, 当为0时说明是播放连接, 1是发布连接
 
active="1"                             当前此值常量值1.
 
在标签中出现的多余属性是上传或播放地址后的附加参数, 你在地址后加入几个值,在属性中就会出现几个值.
 
 
系统平台已经有初级版本，请大家关注导航博客，我会不断的更新内容，请大家跟我一起走，给大家一个流媒体平台。*_*