http协议的流媒体服务器Word文档下载推荐.docx

http协议的流媒体服务器Word文档下载推荐.docx

《http协议的流媒体服务器Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《http协议的流媒体服务器Word文档下载推荐.docx（9页珍藏版）》请在冰豆网上搜索。

他们充满着满腔的热情，但不可否认的是，中国网民先天技术上的不足，让他们在建设这样的站点时遇到重重险阻，以至于放弃。

如何将这种热情在技术的引导下成为动力，这正是我们家用电脑所要做的，所以，在今天，在这里，我就将给大家介绍如何打造属于自己的流媒体服务器。

　　不过，在开始正式的流媒体服务器架设之前，请让我们先了解一下流媒体服务器的基础知识。

　　二、流媒体基础知识

　　什么是流媒体？

　　目前，在网络上传输音/视频等多媒体信息有两种解决方案，即http或ftp下载以及流式传输。

http或ftp下载使用标准的http和ftp协议，但由于多媒体信息个头巨大，下载一个多媒体文件一般需要几分钟或几小时的时间，这就造成为了看一个并不知道内容的视频，首先需要耗费可能比整个视频都要长的时间来完成下载。

这些被下载的文件还必须在下载前制作完成，放在网络服务器上，这样造成的直接后果就是：

网络带宽不断提高，人们下载的等待时间越来越少，但最终还是不能观看网上现场直播。

　　流式传输时，声音、影像或动画等多媒体信息由流媒体服务器向用户计算机连续、实时传送，它首先在使用者端的电脑上创建一个缓冲区，于播放前预先下载一段资料作为缓冲，用户不必等到整个文件全部下载完毕，而只需经过几秒或十数秒的启动延时即可进行观看。

当多媒体信息在客户机上播放时，文件的剩余部分将在后台从服务器内继续下载。

如果网络连接速度小于播放的多媒体信息需要的速度时，播放程序就会取用先前建立的一小段缓冲区内的资料，避免播放的中断，使得播放品质得以维持。

　　流式传输除了能够发送已经制作完成的文件外，还可以通过采集服务器实时采集现场音视频，推送到流媒体服务器端，实时提供给用户。

因此，流媒体除了能够更好的承担如下载一样的多媒体点播服务外，更能够应用在现场直播、电视转播、突发事件报道等多种对实时性传输要求较高的领域。

有关流媒体的厂商

　　流媒体的市场巨大，世界上许多优秀的厂商都加入此行列，现阶段更是系统集成商竞争的风水宝地。

而在通用市场上，竞争的公司主要有三个：

microsoft、Realnetworks、apple，而相应的产品就是：

windowsmedia、Realmedia、quicktime。

而近来，以开发winamp著名的nullsoft公司也在自己的mp3服务器中加入了视频支持，欲在流媒体市场分一杯羹。

　　由于apple的服务器和编辑软件一般都以mac为操作平台，nullsoft的流媒体服务器属于新生不成熟事务，所以今天在这里我主要给大家介绍一下microsoft和Realnetworks的产品。

　　流媒体的传输协议

　　大家在观看网上电影或者电视时，一般都会注意到这些文件的连接都不是用http或者ftp开头，而是一些rtsp或者mms开头的东西，为什么是这样呢？

实际上，这些和http和ftp一样，都是数据在网络上传输的协议，只是它们是专门用来传输流式媒体的协议而已。

下面，让我们来看一下现在使用的主要的流媒体协议：

　　1.Rtsp（Realtimestreamingprotocol），实时流媒体协议，它是由Realnetworks和netscape共同提出的，现在用于Realnetworks的Realmedia产品中；

　　2.pnm（progressivenetworksaudio），这也是Real专用的实时传输协议，它一般采用udp协议，并占用7070端口，但当你的服务器在防火墙内且7070端口被挡，且你的服务器把smartingnetwork设为真时，则采用http协议，并占用默认的80端口；

　　3.mms（microsoftmediaserverprotocol），这是微软的流媒体服务器协议，mms是连接windowsmedia单播服务的默认方法。

　　介绍了主要的三个，可能您还会问，apple的quicktime使用哪种协议呢？

在多数情况下，quicktime使用http协议，但实际上它也由标准的流媒体传输协议，这就是标准Rtsp协议，而Real公司使用的Rtsp是自己经过开发的。

　　在流媒体传输中，标准的协议就是Rtp（Realtimetransportprotocol，实时传输协议）、Rtcp（Real-timetransportcontrolprotocol，实时传输控制协议）、Rtsp（Realtimestreaming

　　protocol，实时流媒体协议）和RsVp（ResourceReserveprotocol,资源预订协议），厂商们的产品都是在这些协议的基础上进行研究与开发，限于篇幅，在这里我们就不再深入讨论了。

流媒体文件和发布格式

　　有了实时的传输协议，我们应该还能够想到，只有较小的文件才适合网络实时传输，那么，流媒体文件采用了什么样的压缩算法呢？

　　而使用windows操作系统的朋友可以看到，我们观看网上流节目时，它们的后缀名一般是rm、asf、wmv等，这些就是流媒体的格式。

流媒体文件格式经过特殊编（http协议的流媒体服务器）码，不仅采用较高的压缩比，还加入了许多控制信息，使其适合在网络上边下载边播放，而不是等到下载完整个文件才能播放。

常见的流媒体格式大致有以下几种：

　　流媒体文件格式扩展（Video/audio）媒体类型与名称

　　asfadvancedstreamingformat.（microsoft）.

　　rmRealVideo/audio文件（progressivenetworks）.

　　raRealaudio文件（progressivenetworks）.

　　rpRealpix文件（progressivenetworks）.

　　rtRealtext文件（progressivenetworks）.

　　swfshockwaveFlash（macromedia）.

　　movquicktime（apple公司格式）

　　vivVivomovie文件（Vivosoftware）.

　　另外还有一个wmv格式，是windowsmediaVideo的简称，它与asf文件有稍许区别，wmv一般采用windowmediavideo/audio格式，asf视频部分一般采用microsoftmpg4V（3/2/1），音频部分是windowsmediaaudiov2/1，不过现在很多制作软件都没有把它们分开，所以直接更改后缀名就能够互相转换为对方格式。

　　制作完成的流媒体文件需要发布到网络上才能够被别人使用，这就需要以特定方式安排压缩好的流媒体文件，而安排流媒体文件的格式就被成为流媒体发布格式。

常见的发布格式主要有以下几种：

流媒体发布格式扩展媒体类型和名称

　　asfadvancedstreamingformat.

　　smilsynchronisedmultimediaintegrationlanguage.

　　ramRamFile.

　　rpmembeddedRamFile.

　　asxasFstreamRedirector/asF流转向器文件

　　xmlextensiblemarkuplanguage

　　mpeg-4与流媒体

　　说到流媒体就不能不提及mpeg-4。

mpeg-4是当前讨论的焦点之一，只因为它能够在大的压缩比下实现近似dVd品质的视频和音频效果，这也是许多朋友认为mpeg-4格式肯定比rm清晰的原因。

但事实上并不是如此，mpeg-4只是一种视频编码技术，它的清晰度也根据压缩时所选择的码率的不同有较大的改变（我们见到的mpeg-4格式文件通常为500kbps压缩生成，质量当然高了），并且，mpeg-4还有多种压缩标准，如microsoft的asf视频部分就是基于mpeg-4的discretecosinetransform（dct），另外还有divx的免费mpeg-4版本（开始是破解微软的格式而来）。

至于音频部分，更是混乱，microsoft采用windowsmediaaudiov2/1，divx采用mp3或者更高质量的ac3等。

相比而言，Real或者apple的格式使用的是自己开发的编码，在相同码率，特别是低码率下，不见得就比mpeg-4差，采取高码率的rm格式照样清晰可人，所以大家以后说rm格式清晰度差的观念要改变一下：

），至少也要加上条件。

而且，最新的helixproducer中的RealVideo9采用Vp5压缩格式进行编码，这可比divx优秀多了！

　　不过，流媒体服务器开始向mpeg-4格式靠拢是不争的事实，Real最新的helix就开始支持mp4格式文件的服务，而Realoneplayer更是只需安装一个插件便可实现mpeg-4格式的播放。

　　点播与广播

　　在架设流媒体服务器之前，我们一定要了解一些点播与广播的知识。

　　点播是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，一个客户端从服务器接收一个媒体流（这个连接是唯一的，其它用户不能占用），并且能够对媒体进行开始、停止、后退、快进或暂停等操作，客户端拥有流的控制权，就像在看影碟一样。

这种方式由于每个客户端各自连接服务器，服务器需要给每个用户建立连接，对服务器资源和网络带宽的需求都比较大。

　　广播指的是用户被动接收流。

在广播过程中，客户端接收流，但不能控制流，用户不能暂停、快进或后退该流，广播使用的数据发送手段有单播与广播。

使用单播发送时，服务器需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个

　　拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽和服务器资源，因此产生了组播（多播）技术。

　　组播（多播）吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户，组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。

但组播不仅需要服务器端支持，更需要有多播路由器乃至整个网络结构的支持。

　　单播与组播（多播）

　　在上面我们已经了解了一些单播和组播的概念，这也是现在流媒体方面讨论的焦点之一。

以我的认识，点播与广播是一组概念，它们和客户端媒体交互的手段；

单播和组播又是另外一组概念，它们是流媒体数据在服务器端和网络上的传输方式。

　　单播发送时，需要在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机，每个用户必须分别对媒体服务器发送单独的查询，而服务器必须向每个用户发送所申请的数据包拷贝。

这种巨大冗余会造成服务器沉重和网络带宽的沉重负担，响应需要很长时间，甚至出现不能服务的情况。

单播可以用在点播和广播上。

　　组播发送时，服务器将一组客户请求的流媒体数据发送到支持组播技术的路由器上，然后由路由器一次将数据包根据路由表复制到多个通道上，再向用户发送。

这时候，媒体服务器只需要发送一个信息包，所有发出请求的客户端都共享同一信息包，并且信息可以发送到任意地址的客户机，没有请求的客户机不会收到信