p>realPix是新近发表的RealMeida文件格式的一部分,是允许直接将图片文件通过Internet流式传输到可户端。
通过将其它媒体如音频、文本捆绑到图片上可以制作出为了各种目的用途的多媒体文件。
只要需要懂简单的标志性文件就可以用文本编辑器制作出*.rp文件。
RealPix文件是可以用RealServer发送到RealPlayer直接播放的，但是由于这个是新出来的媒体标准格式，所以以前的版本如RealPlayer4.0and5.0是不能播放的。
*.rt（RealText）
realText也是新近发表的RealMeida文件格式的一部分，发布这种格式是为了让文本从文件或者直播源流式发放到客户端。
RealText文件即可以是单独的文本也可以文本的基础上加上媒体，何种形式完全由需要决定了。
由于RealText文件也是由标志性语言定义的，所以用简单的文本编辑器就可以制作。
RealText文件也是可以用RealPlayer流式播放。
*.asf（AdvancedStreamingformat）
*.asf文件是Microsoft为了和现在的Realplayer竞争而发展出来的一种可以直接在网上观看视频节目的文件压缩格式！
由于它是用MPEG—4的压缩算法，所以它的压缩质量如果不考虑文件大小的化，完全可以和VCD媲美，完全比同是视频格式的*.rm好很多。
关于这种格式说明Microsoft的帮助上有明确说明，在这里我简单的引用一下，“ASF是一种支持在各类网络和协议下进行数据传递的公开标准。
ASF用于排列、组织、同步多媒体数据以通过网络传输。
ASF是一种数据格式；然而，它也可用于指定实况演示的格式。
ASF不但最适于通过网络发送多媒体流，也同样适于在本地播放。
任何压缩-解压缩运算法则（编解码器）都可用以编码ASF流。
在ASF流中存储的信息可用于帮助客户决定应使用何种编解码器解压缩流。
另外，ASF流可按任何基础网络传输协议传输。
”
*.mov
QuickTime制定了其称作QuickTimeMovie的多媒体文件格式。
此一文件格式是极具弹性的储存格式。
虽然QuickTime并不强制要求用户将媒体资料存成QuickTimeMovie文件，但大部分的客户会发现QuickTimeMovie档案格式是一种方便而强大的多媒体文件格式。
它要比微软早期推出的AVI文件格式强很多。
此外QuickTimeMovie文件格式不限系统平台、系统开放性、且可延伸性的约束，所以用它作为分散式多媒体系统，是比较理想的环境。
以上这些特色已经促使许多主要的Web厂商改用QuickTimeMovie格式。
QuickTime电影在Windows系统平台上亦受到良好的支持。
Apple、Microsoft、Macromedia、Netscape、Adobe等著名厂商和大量其它的软件开发人员都开始使用QuickTime格式。
由于QuickTime能在这众多电脑平台上使用，所以QuickTime的跨平台能力是勿庸置疑的，目前QuickTimeMovie格式正日趋普及。
2.3常见的流媒体发布格式
流媒体发布格式不是压缩格式，也不是传输协议，其本身并不描述视听数据，也不提供编码方法。
在这里我更愿意把它说成是播放列表。
播放列表是您想观看或聆听的文件的自定义列表。
播放列表使您可以将不同媒体内容集中在一起，按您所指定的任意顺序播放。
而Real和Microsoft就各自定义了自己的播放列表格式。
媒体发布格式并不包括媒体的物理数据，仅仅说明了数据类型和安排方式，大多数的这种文件都可以用文本编辑器随意打开和修改。
这样就为应用不同压缩标准和媒体文件格式格式的媒体发布提供一个事实上的标准方法。
单个媒体发布格式能包含不同类型媒体的所有信息，如计时、多个流同步、版权和所有人信息。
实际视听数据可位于多个文件中，而由媒体发布文件包含的信息控制流的播放。
在这里介绍了常用了媒体发布格式。
*.ram
RAM文件是RealMeida文件的索引文件，我个人认为就是播放列表。
RAM文件不包括任何媒体数据，它标注的是媒体数据存放的位置，它会告诉浏览器启动RealPlayer来查看该超链接然后向服务断请求真正的媒体文件。
它的产生可以自己手工编写，编写的内容即超链接的内容，也可以通过RealProducer软件的Publish功能自动发布生成，最后发布到RealServer的时候需要把RAM文件和RealMeida文件一起放上服务器，再在自己的页面上做一个连接指想RAM文件就可以实现调用RealPlayer播放了。
*.asx
ASX元文件或.asx文件是MicrosoftMedia文件的的索引文件，也是一种播放列表。
播放列表将媒体内容集中在一起，并储存媒体内容的位置，无论位置是您的计算机、您网络中的另一台计算机或是Internet。
在其最简形式中包含了关于流的URL的信息。
MicrosoftWindowsMediaPlayer处理该信息，然后打开.asx文件中定义的内容。
*.smil（SynchronizedMultimediaIntegrationLanguage）
SMIL,同步多媒体集成语言是由W3C指定的有关流媒体技术的语言。
其作用是使Web上的多媒体应用保持同步，就像HTML在超链接文本中所起的作用一样。
SMIL是一种简单易用的标志性语言，是在XML基础上开发的，它的目的是使各个技术水平层次的Webbuilder，都能够通过编制一个时间序列表，对音频，视频，文本和图像文件出现的先后次序作出安排，而不需要再去掌握相应的开发工具或是复杂的编程语言。
播放SMIL可以使用REALPlayer，IE5。
5全面支持smil。
在实验五中，SMIL的完全制作将会是个重点，所以在在这里读者只要有个概念性的认识就可以了。
2.4点播与广播
在架设流媒体服务器后，可以通过Internet浏览流媒体文件。
HelixServer提供了多种类型服务，在这里，了解一些点播与广播的知识。
①点播：
点播是客户端与服务器之间的主动的连接，在点播连接中，用户通过选择内容项目来初始化客户端连接，一个客户端从服务器接收一个媒体流（这个连接是唯一的，其它用户不能占用），并且能够对媒体进行开始、停止、后退、快进或暂停等操作，客户端拥有流的控制权，就像在看影碟一样。
这种方式由于每个客户端各自连接服务器，服务器需要给每个用户建立连接，对服务器资源和网络带宽的需求都比较大。
②广播：
广播指的是用户被动接收流。
在广播过程中，客户端接收流，但不能控制流，用户不能暂停、快进或后退该流，广播使用的数据发送手段有单播与广播。
使用单播发送时，服务器需要将数据包复制多个拷贝，以多个点对点的方式分别发送到需要它的那些用户，而使用广播方式发送，数据包的单独一个拷贝将发送给网络上的所有用户，而不管用户是否需要，上述两种传输方式会非常浪费网络带宽和服务器资源，因此产生了——组播（多播）技术。
③单播与组播（多播）技术:
组播（多播）吸收了上述两种发送方式的长处，克服了上述两种发送方式的弱点，将数据包的单独一个拷贝发送给需要的那些客户，组播不会复制数据包的多个拷贝传输到网络上，也不会将数据包发送给不需要它的那些客户，保证了网络上多媒体应用占用网络的最小带宽。
但组播不仅需要服务器端支持，更需要有多播路由器乃至整个网络结构的支持。
点播与广播是一组概念，它们和客户端媒体交互的手段；单播和组播又是另外一组概念，它们是流媒体数据在服务器端和网络上的传输方式。
单播发送时，需要在客户端与媒体服务器之间需要建立一个单独的数据通道，从一台服务器送出的每个数据包只能传送给一个客户机，每个用户必须分别对媒体服务器发送单独的查询，而服务
升级会员 