辛辛苦苦的完成了截屏、解码、转换、编码、显示之后，迎来了最后的难题——网络流媒体传输。
本来我是想当然的以为直接通过UDP传就行了。，但是感觉不太行，我没想到网络流媒体传输是一块这么复杂的内容。之前我还以为就用UDP就完了，没想到还有这么多听都没听过的新词：RTP、RTSP，。。实时传输、顺序传输之类的。
我本来写了一个P2P的UDP传输小例子，想着直接拿来用吧。但是遇到了几个棘手的问题：
1、编码之后的H264的package大小非常不固定，十几到十几万的B都有。
2、遇到特别大的package，一包UDP传输我还没试，但是一个15W长的buf直接sendto感觉十分不靠谱，可能要拆包
3、次序不固定，需要弄一个顺序的serialid，这比较麻烦
4、定时发送，定时接受，保证匀速。这个不知道有没有必要，还有发的太快来不接接收并显示，是不是还要找个东西缓存一下。，真的很麻烦、
5、UDP这么麻烦，如果还要做到P2P，那岂不是更麻烦了
所以我想着在先看看RTP这些究竟是些什么东西。
(1)内容主要是时间上连续的媒体数据(音频、视频、动画、多媒体等)。 [3]
(2)内容可以不经过转换就采用流式传输技术传输。 [3]
(3)具有较强的实时性，交互性。 [3]
(4)启动延时大幅度缩短，缩短了用户的等待时间；用户不用等到所有内容都下载到硬盘上才能开始浏览，在经过一段启动延时后就能开始观看。 [3]
(5)对系统缓存容量的要求大大降低
顺序流式传输
顺序流式传输是顺序下载，用户在观看在线媒体的同时下载文件，在这一过程中，用户只能观看下载完的部分，而不能直接观看未下载部分。也就是说，用户总是在一段延时后才能看到服务器传送过来的信息。由于标准的HTTP服务器就可以发送这种形式的文件，它经常被称为HTTP流式传输。 [3]
由于顺序流式传输能够较好地保证节目播放的质量，因此比较适合在网站上发布的、可供用户点播的、高质量的视频。 [3]
顺序流式文件是放在标准HTTP或FTP服务器上，易于管理，基本上与防火墙无关。顺序流式传输不适合长片段和有随机访问要求的视频，如:讲座、演说与演示。它也不支持现场广播。 [3]
实时流式传输
实时流式传输必须保证匹配连接带宽，使媒体可以被实时观看到。在观看过程中用户可以任意观看媒体前面或后面的内容，但在这种传输方式中，如果网络传输状况不理想，则收到的图像质量就会比较差实时流式传输需要特定服务器，如 Quick Time Streaming Server、 Realserver或 Windows Media server。这些服务器允许对媒体发送进行更多级别的控制，因而系统设置、管理比标准HTTP服务器更复杂。实时流式传输还需要特殊网络协议，如:RTSP( realtime streaming protocol)或MMS(microsoft media server)。在有防火墙时，有时会对这些协议进行屏闭，导致用户不能看到一些地点的实时内容，实时流式传输总是实时传送，因此特别适合现场事件。 [3]