当前流媒体播放中常用到的协议有rtmp，rtsp和http等。各个协议适用于不同的场景。各有优点。具体的区别可参见：
<a href="http://blog.csdn.net/aflyeaglenku/article/details/53929028">http://blog.csdn.net/aflyeaglenku/article/details/53929028</a>
<a href="http://www.jianshu.com/p/5b0fa403b3ce">http://www.jianshu.com/p/5b0fa403b3ce</a>
rtsp和rtmp协议需要搭建专门的流媒体服务器。有一定的使用成本。如果通过http协议下载视频资源，可以缓存到一定程度后在通过播放器播放。这样实现方式可以算是一种伪流媒体传输方式。对于常规的在线视频播放需求来说也能满足。
Android的VideoView是通过http协议实现边下边播的。设置VideoView远程在线资源的http url，调用start操作ViewView就可以直接边下载边播放。
具体代码参见如下：
调用start操作后，通过http get请求下载文件。得到文件的metedata之后，解析出该文件的编码、帧率、时长等信息。然后边下载边送入软/硬解码器进行解码，最后通过SurfaceView将解码后的数据显示出来，比较复杂，相当于自己做流媒体播放器了。
看似简单的代码。其实系统帮我们实现了下载，解析，解码，播放等一系列操作。
使用系统播放器简单，方便。看起来一切都是很完美的。直到客户发现一个问题。
用android 系统自带的 videoview 播放存储在oss的大视频（播放时长超过3分钟）。会提示java.net.ProtocolException: unexpected end of stream。但相同的视频存储在七牛云上播放却不会出现问题。
这个问题一开始很迷茫。丝毫没有查找思路。经过反复抓包测试后，发现VideoView下载到一定缓存后就不下载了。
具体表现如下：
这时候我们一个同事猜测是不是服务器主动断开链接？
经过进一步大胆假设和验证。发现VideoView的缓存是有上限的。并且到达缓存上限后不会主动向服务器请求获取更多内容。
如果视频文件播放帧率较底，缓存的文件播放时间比较长。那么这段时间内客户端都不会向服务器请求更多的数据。服务端因为长时间没收到客户端请求，从而主动断开和客户端的连接。
找到问题的原因就好^_^。在CDN服务器上更改服务器和客户端连接超时时间。一切完美解决。等等，真的完美吗？刚刚说的，用VideoView播放存储在某友商云存储平台的视频一切正常。为什么？继续抓包。发现VideoView访问友商平台上的视频资源时因为速度的问题，缓存10m内容需要的时间是oss的5倍以上。这样客户端和存储平台服务器一直有数据交互。从而服务器不会主动断开和客户端的连接。另，VideoView在播放缓存内容完成后，没有主动去重新创建连接，从而无法播放完整的视频。这也是一个系统issue。