流媒体这个概念出现很久了，应该近10年了。直觉上，流媒体就是可以边下载边播放的媒体。现在，上网的人都有这种体验了，例如看播客短片，看pplive等，都是边下载边播放的。其实，这些都不是真正的流媒体，看到这个结论，你可能会吃惊，但看完这篇文章后，你就会明白了。
首先，来看一下流媒体从制作到播放的整个过程吧。
流媒体需要什么样的源数据？几乎是任何数据，你手头的avi,rm等文件，甚至磁带，或者刚从采集设备得到的模拟信号。
有源数据了，怎么处理呢？首先，如果是模拟信号，就要先转换成数字信号（直播往往是把刚采集到的模拟信号转换成数字信号），然后就是按照需要的码率进行编码。编码需要编码器，即codec。需要什么编码器，就看你想要什么格式的文件。当前流行的流媒体格式有三种：quick time, windows media technology（简称wmt）, real system。三种格式分属不同的公司：quick time是苹果公司的，后缀名是什么我也不清楚，因为不常接触；wmt是微软的，一般以asf为后缀名；real system是real公司的，这种格式大家接触得最多，rm、rmvb文件很常见。编码成某种格式，还要看服务器上有没有支持这种格式的服务端软件，客户端的播放器也要支持这种格式的播放，流媒体才能流起来。
编码生成流媒体文件后，需要流媒体服务器进行媒体的传输，主要是用特定的流媒体协议封装数据包。
在列举流媒体协议前，先看一下两种通用的传输协议：tcp和udp。要问流媒体的数据传输和文件下载的数据传输有何不同，就是传输协议的不同。文件下载用的是tcp协议，tcp是有连接的协议，数据传输之前要建立连接，数据传输完后，连接才会断开。tcp支持确认重传，能保证数据的完整性，因此只要下载完成，下载到客户端的文件和服务器上的文件是一样的，不会丢失了其中的某些数据。流媒体不能使用tcp协议，因为tcp的重传机制不能满足流媒体对时间的要求，对流媒体来说，丢包也不会比视频中断的后果严重。流媒体使用udp协议。udp是无连接的协议，而且不需要确认重传，udp包发出之后，不需要等待接收方的确认，虽然可能丢失某些数据，但能保证实时性。有种情况下，用udp传输的流媒体不得不转换成tcp传输，是什么情况呢？如果你是内网用户，或处在公司的防火墙之后，就只能通过tcp来接收数据，因为udp包会被防火墙拒收的。只不过这个tcp连接即使丢包也不重传。
流媒体数据需要流媒体协议的封装，根据格式不同，使用的协议也不同。有名的流媒体协议有四种：rtp, rtsp, rdp和mms。rtp以udp为基础，扩展了sequence number和time stamp等域。rtsp是rtp协议的扩展，当传输数据时，使用rtp协议，当传输控制数据时，使用tcp连接。而rdp又是rtsp的扩展，只是加强了控制协议。quick time就是使用rtp/rtsp传输媒体文件，而real system使用rtsp/rdp传输媒体文件。mms是微软专用的协议，一开始，使用mmsu建立连接（mms和udp的结合），如果建立连接不成功，则转用mmst（mms和tcp的结合）建立连接。wmt使用mms传输媒体文件。
如果没有流媒体服务器，能不能实现边下载边播放的效果呢？答案是可以，就使用tcp上的http连接就可以。先把一些数据下载到缓冲区中，然后边下载新的数据到缓冲区，边播放缓冲区已有的数据。这种流叫做http流，也叫假流。这就回到了我们开始提到的问题，我们看到的播客短片和pplive上的节目等其实都是http流，而不是真正的流媒体。
http流和真正的媒体流有什么区别呢？区别在很多方面：(1)首先看服务器，http流只需要web server就可以了，而真正的媒体流需要专用的媒体服务器。(2)再看协议，http流需要的协议从下到上为ip, tcp, http，而真正的媒体流需要ip, udp和专用的流媒体协议。(3)还有，因为http流使用的是tcp连接，所以如果丢包会重传，而真正的媒体流不会重传。也正是这个原因，如果撇开中断等影响，我们通过http流看到的视频质量和服务器上的视频质量是一样的，而通过真正的媒体流，其质量会随网络状况的不同而不同。(4)从启动延迟上看，http流的启动延迟要视网络连接状况，媒体码率而定；而真正的媒体流启动延迟不会多于几秒。(5)看http流的时候，你只能在已经下载的视频范围内拖动，而真正的流媒体可以在全片范围内拖动。(6)最后，http流会把下载的媒体数据存入硬盘，而真正的媒体流不会，它播放过的数据马上丢弃了，这样刚好保护了媒体作品的版权。
14:31 2007-5-30
