作为自己的专业知识领域，我决定更新本答案。
版权保留，不得商用，转载必须在开始位置注明作者、出处。
凭借印象完成，错漏地方，还请大家指正。
----
视频相关的协议有很多，不同的公司，甚至有自己的协议标准。本文尽量涵盖目前常见的视频相关的协议。
1，RTSP/RTP/RTCP协议族
本协议族是最早的视频传输协议。其中RTSP协议用于视频点播的会话控制，例如发起点播请求的SETUP请求，进行具体播放操作的PLAY、PAUSE请求，视频的跳转也是通过PLAY请求的参数支持的。而RTP协议用于具体的视频数据流的传输。RTCP协议中的C是控制的意思，用于在视频流数据之外，丢包或者码率之类的控制。
该协议族RTSP是建立在TCP之上的，RTP、RTCP建立在UDP之上。不过也可以通过interleave的方式，将RTP和RTSP一起在同一个TCP连接上传输。
RTSP协议族，是最早被提出来的，因此很多考虑的地方，都还带有早期的特征。比如使用UDP，是考虑到传输的效率，以及视频协议本身对丢包就有一定的容忍度。但是UDP协议，显然不能用于更大规模的网络，而且复杂网络下路由器的穿透也是问题。
从视频角度而言，RTSP协议族的优势，在于可以控制到视频帧，因此可以承载实时性很高的应用。这个优点是相对于HTTP方式的最大优点。H.323视频会议协议，底层一般采用RTSP协议。RTSP协议族的复杂度主要集中在服务器端，因为服务器端需要parse视频文件，seek到具体的视频帧，而且可能还需要进行倍速播放（就是老旧的DVD带的那种2倍速，4倍速播放的功能），倍速播放功能是RTSP协议独有的，其他视频协议都无法支持。
缺点，就是服务器端的复杂度也比较高，实现起来也比较复杂。
2，HTTP协议
HTTP的视频协议，主要是在互联网普及之后。在互联网上看视频的需求下形成的。
2.1
最初的HTTP视频协议，没有任何特别之处，就是通用的HTTP文件渐进式下载。本质就是下载视频文件，而利用视频文件本身的特点，就是存在头部信息，和部分视频帧数据，就完全可以解码播放了。显然这种方式需要将视频文件的头部信息放在文件的前面。有些例如faststart工具，就是专门做这个功能的。
但是最为原始的状态下，视频无法进行快进或者跳转播放到文件尚未被下载到的部分。这个时候对HTTP协议提出了range-request的要求。这个目前几乎所有HTTP的服务器都支持了。range-request，是请求文件的部分数据，指定偏移字节数。在视频客户端解析出视频文件的头部后，就可以判断后续视频相应的帧的位置了。或者根据码率等信息，计算相应的为位置。
2.2
支持HTTP range-request的服务器，目前就可以支持我们一般网络看视频的要求了。但是，这种方式，无法支持实时视频流，或者准实时视频流。因为视频流，是不存在一个视频文件的概念的。HTTP协议播放视频的好处，就是简单。采取通用的HTTP服务器，就可以提供服务，不需要专门类型的服务器，也不需要特别的网络端口，穿过路由器防火墙一点都没有问题。而且还可以利用通用的CDN来简化视频的部署分发的工作，减少带宽的使用。
这个是目前用于PC端或者网页端，视频点播业务，最常见的解决方案。客户端的实现，一般采用flash完成，flash本是的videoplayer或者videodisplay控件就可以完成。资源一般采用flv格式，也可以使用mp4格式。
在此基础上，多家公司推出了自己的解决方法。
2.3 HLS HDS MSS DASH
苹果推出的HTTP Live Streaming，就是随着苹果设备的普及得以广泛应用的一种。从名词就可以判断出来，HLS支持Live直播式的视频传输。HTTP采用m3u8作为索引文件，视频为MPEG2-TS格式的片段文件。如果为直播视频流，则采取更新m3u8文件，从而更新视频索引列表，达到视频直播的目的。但是这种方法，因为最终视频是片段文件，所以必然存在片段视频长度的延迟。因此只可以用于对实时性要求没有那么高的准实时视频流。但是HLS方式，因为采用了较早的MPEG2-TS格式，这种格式的overhead，也就是头部信息占据总文件的比例比较大，也就是效率不够高。之所以没有使用其他格式，主要是商业竞争和版权的问题。
相应的，adobe公司，推出相似的HTTP dynamic streaming。这种方式本质和HLS的策略是类似的，就是通过索引文件+视频片段的方式。但是显然采用的索引格式和视频片段格式都不一样的。HDS采用的是视频格式是flv或者f4v，索引格式记不清楚了。
类似的，微软也推出了Microsoft Smooth Streaming，也即是mss的视频播出方式，采用的视频格式是分段mp4格式。
MPEG标准组则推出了Dynamic Adaptive Streaming over HTTP,DASH.采用的视频格式为3GPP吧。
显然，这个目前是百花齐放的状态，虽然最常用的的是HLS，谁叫苹果这么霸气呢。而安卓和苹果上面对于flash都有限制，而HDS是adobe推出在adobe平台上面的。mss，只有在少数几个地方见到过。dash，目前仅仅是论文里面的产物。
以上的协议，主要是解决一个问题，就是自适应码率切换，上面的dynamic，adaptive都是类似的意思。主要是利用索引文件中同时给出不同码率的视频文件的地址，这样播放器端，可以根据带宽情况，自适应选择不同码率的视频文件。
同时在视频直播方面，在安卓和iOS平台以外，还有很多视频服务器提供厂商，自己开发协议，一般采用方式为固定时间片段的flv文件的方式（采用flv，是因为flash上方便播放）
2.4 HTML5
同时HTML制定厂商也不寂寞，推出HTML5这种方式，这种方式本质上，和前面的HTTP视频协议没有任何区别。但是播放器端，不再依赖于特定的插件如flash，或者其他播放软件，而是可以支持浏览器的直接视频播放。采用的是html中嵌入video标签，同时直接指明视频的url。不过，不同的浏览器，对于音视频的格式支持不完全相同。比较通用的是视频H。264格式，音频AAC格式，封装格式MP4。
2.5其他
在HTTP协议的基础上，各家公司，针对自己的业务特性，也可能开发自己的专有的数据格式，或者协议。但是都是在上述的基本上做出一些细微的修改而已。毕竟国内的技术体系，还完全无法提出一个新的技术的程度。（google，就提出新的编码格式替换H.264,SPDY协议，这个国内做不到的）。
一般只会做到例如HTTP特殊字段或者特殊参数，传递到flash中做出一定的解释。或者在原有的视频文件格式基础上添加一些特殊意义的头部等等。
3，RTMP
这个是adobe公司自己推出的视频播放协议。需要专用的服务器，如FMS，开源的有red5.这种协议也是flash默认支持的。
----
总体来看，视频相关的协议发展，是从专用的协议、服务器，逐渐向HTTP过渡的过程。而且逐渐适应网络的发展和需求，复杂多变的网络环境，才催生了http的视频协议。
----
应邀更新.
上面已经对不同协议的应用场景分别解释了.
单纯的协议,http非常简单,rtsp族比较复杂,rtmp没有深入了解过.
如果你只是要做个应用,或者使用它,那么http就够了,非常之简单,非常之快捷.
但是如果你真的想学习这个方面,必然不能仅仅注重于视频的网络协议,还有其他的很多点.比如网络基础的细节点,音视频的编码格式基础知识等等.这里面的每个点,都充满了趣味.你可以深入挖掘.但这是一个长期的技术学习的投入,基本论年计.产出我就不了解了,因为我到现在还没有真正意义的产出.