1.流媒体：实时流媒体 顺序流媒体
格式、协议参见百度百科 流媒体
2.android多媒体框架:基于openCore，只能解码mp4、3gp
http://developer.android.com/guide/appendix/media-formats.html

3.开源多媒体框架：
VLC FFMPEG
4.Google开源项目：dolphin player 基于ffmpeg
编译：按照教程（http://blog.csdn.net/u012481275/article/details/12851695） 使用android-ndk-r5b 成功编译，android-ndk-r9反而不行，会出现make: *** [obj/local/armeabi/**.so] Error 1的错误。这是因为dolphin
 player最后更新在2012年左右，属于比较早期。如果编译最近的VLC项目，则需要r8以上。
编译时注意：jni文件夹下Application.mk文件中设置编译版本 部分老版android手机，不能使用armv7 需要armeabi。
编译完成后将.\p\native\ffmpeg\ffmpeg-0.11.1\android文件夹下对应的版本拷入到android工程的libs\armeabi或armeabi-v7a文件夹下，包括include文件夹等
下载地址：git clone https://code.google.com/p/dolphin-player/

Supports subtitles from various subtitle file formats(srt, sub, utf, utf8..)

Supports player on screen controls (play, pause, forward, rewind, aspect ratio buttons)

Supports unicode subtitles(Languages like Chinese, Japanese, French are supported)
Supports Http live streaming (m3u8) 

Supports web mp3 links


5.http://blog.appdevp.com/archives/336
HTTP Live Streaming（缩写是 HLS）是一个由苹果公司提出的基于HTTP的流媒体 网络传输协议。是苹果公司QuickTime X和iPhone软件系统的一部分。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended
 M3U (m3u8) playlist文件，用于寻找可用的媒体流。

HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。苹果公司把HLS协议作为一个互联网草案（逐步提交），在第一阶段中已作为一个非正式的标准提交到IETF。但是，即使苹果偶尔地提交一些小的更新，IETF却没有关于制定此标准的有关进一步的动作。


6.m3u8

现在所有视频网站基本都是通过m3u8的方式来播放视频的
http://www.the5fire.com/m3u8-web-player.html


7.待补充

本文档主要介绍海康威视设备直播预览RTSP、录像回放RTSP、流媒体取流的RTSP URL和IE直接预览、回放的HTTP URL。

RTSP为取流协议，取到码流后需要解码显示，可以通过VLC播放器或者EasyPlayer播放器进行测试，IE等浏览器网页不支持RTSP协议直接取流预览或者回放，需要安装OCX插件，这也是目前大部分安防厂家的做法。


目前也有很多支持RTSP进行网页无插件直播的流媒体服务，例如EasyNVR就是专门做这种安防RTSP转互联网RTMP/HLS（m3u8）/FLV无插件H5直播的流媒体服务中间件；


网页上需要跳过登录界面直接访问我们设备的预览或者回放画面，可以使用文档中所述的HTTP的URL实现。

注：

1）URL中“:”“?”“&”等符号均为英文半角。

2）RTSP取流和HTTP 访问URL都需要设备支持，如下所示两种控件的设备均可支持。

 



一、海康RTSP取流URL地址规则

1.1 预览取流

设备预览取流的RTSP URL有新老版本，2012年之前的设备（比如V2.0版本的Netra设备）支持老的取流格式，之后的设备新老取流格式都支持（这里不得不再说一下海康是国内视频硬件独一档）。

【海康老版本，目前已经非常少见了】
URL规定：

rtsp://username:password@<ipaddress>/<videotype>/ch<number>/<streamtype>


注：VLC或者EasyPlayer可以支持解析URL里的用户名密码，实际发给设备的RTSP请求URL不支持带用户名密码。


详细描述：



 

举例说明：

DS-9016HF-ST的IP通道01主码流：

rtsp://admin:12345@172.6.22.106:554/h264/ch33/main/av_stream

DS-9016HF-ST的模拟通道01子码流：

rtsp://admin:12345@172.6.22.106:554/h264/ch1/sub/av_stream

DS-9016HF-ST的零通道主码流（零通道无子码流）：

rtsp://admin:12345@172.6.22.106:554/h264/ch0/main/av_stream

DS-2DF7274-A的第三码流：

 rtsp://admin:12345@172.6.10.11:554/h264/ch1/stream3/av_stream

 

【海康新版本，DS系列】
URL规定：

rtsp://username:password@<address>:<port>/Streaming/Channels/<id>(?parm1=value1&parm2-=value2…)


注：VLC或者EasyPlayer可以支持解析URL里的用户名密码，实际发给设备的RTSP请求不支持带用户名密码。


详细描述：



 

举例说明：

DS-9632N-ST的IP通道01主码流：

rtsp://admin:12345@172.6.22.234:554/Streaming/Channels/101?transportmode=unicast

DS-9016HF-ST的IP通道01主码流：

rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/1701?transportmode=unicast

DS-9016HF-ST的模拟通道01子码流：

rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/102?transportmode=unicast  (单播)

rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/102?transportmode=multicast (多播)

rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/102 (?后面可省略，默认单播)

DS-9016HF-ST的零通道主码流（零通道无子码流）：

rtsp://admin:12345@172.6.22.106:554/Streaming/Channels/001

DS-2DF7274-A的第三码流：

rtsp://admin:12345@172.6.10.11:554/Streaming/Channels/103


注：前面老URL，NVR（>=64路的除外）的IP通道从33开始；新URL，通道号全部按顺序从1开始。


 

1.2 录像回放取流RTSP规则

URL规定：

rtsp://username:password@<address>:<port>/Streaming/tracks/<id>(?parm1=value1&parm2-=value2…)


注：VLC或者EasyPlayer可以支持解析URL里的用户名密码，实际发给设备的RTSP请求不支持带用户名密码。


详细描述：



 

举例说明：

DS-9016HF-ST的模拟通道01：

rtsp://admin:12345@172.6.22.106:554/Streaming/tracks/101?starttime=20120802t063812z&endtime=20120802t064816z

DS-9016HF-ST的IP通道01：

rtsp://admin:12345@172.6.22.106:554/Streaming/tracks/1701?starttime=20131013t093812z&endtime=20131013t104816z

表示以单播形式回放指定设备的通道中的录像文件，时间范围是starttime到endtime，其中starttime和endtime的格式要符合ISO 8601。具体格式是YYYYMMDD”T”HHmmSS.fraction”Z”，Y是年，M是月，D是日，T是时间分格符，H是小时，M是分，S是秒，Z是可选的、表示Zulu(GMT) 时间。


注意：很多时候我们用命令行来验证RTSP回放流的时候，一定要将整个RTSP-URL用双引号包括起来，“RTSP-URL”，因为CMD里面&符号是特殊字符，不用双引号包起来，整个地址会被切割分成几个部分；


 

1.3 海康流媒体服务取流RTSP规则

【流媒体V4.0】iVMS-4200 V2.0配套流媒体服务器
URL描述：



注：Devicehc8为固定字符，不可更改。

 

举例说明：

通过流媒体服务器172.6.24.15从设备172.6.22.106取通道01主码流：

rtsp://172.6.24.15:554/Devicehc8://172.6.22.106:8000:0:0?username=admin&password=12345

 

【流媒体V2.0】
URL描述：



举例说明：

rtsp://172.6.24.15:554/172.6.22.106:8000:HIK-DS8000HC:2:0:admin:12345/av_stream

注：流媒体2.0的取流URL不是标准的RTSP协议，必须使用流媒体SDK（客户端）才支持取流的，放在这里只是为了给流媒体4.0做参照的。

 

二、通用摄像机RTSP取流URL地址规则

现在实际上现在已经不用再这么复杂地获取RTSP的取流地址了，因为大部分的IPC或者NVR都基本支持了Onvif协议，通过Onvif Device Test Tool或者EasyNVR这样的工具，可以直接发现到设备的RTSP流地址，不用再自己来根据不同厂家的规则拼接了，以EasyNVR为例：





 



 

✈ 更多视频解决方案资源汇总


	
流媒体技术：

	© EasyDarwin开源流媒体服务器：http://www.easydarwin.org

	© TSINGSEE视频开放平台：http://open.tsingsee.com
	
	

	
视频云服务

	© EasyDSS互联网视频云服务：http://www.easydss.com

	© EasyCVR安防视频云服务：http://www.easycvr.com

	© EasyGBS国标视频云服务：http://www.easygbs.com

	© EasyRTC在线视频会议平台：http://www.easyrtc.cn

	© EasyRTS即时通信云服务：http://www.easyrts.com
	
	

	
边缘计算：

	© EasyNVR视频边缘计算网关：http://www.easynvr.com

	© EasyNTS上云网关：http://www.easynts.com
	
© TSINGSEE Team：http://www.tsingsee.com

一、流媒体协议
1.1 RTP (Real-time Transport Protocol)
1.1.1 RTP特征
实时传输协议（Real-time Transport Protocol）是一个网络传输层协议，它是由IETF的多媒体传输工作小组1996年在RFC 1889中公布的，它作为因特网标准在RFC 3550（该文档的旧版本是RFC 1889）有详细说明，RTP标准定义了两个子协议：RTP和RTCP。
RTP协议是建立在UDP协议上的。 RTP协议详细说明了在互联网上传递音频和视频的标准数据包格式。RTP协议常用于流媒体系统（配合RTCP协议）、视频会议和视频电话系统（配合H.263或SIP）。
RTP标准由两个紧密链接部分组成：
RTP ---- 传送具有实时属性的数据；
RTP控制协议（RTCP）----监控服务质量并传送正在进行的会话参与者的相关信息。
RTP本身并没有提供按时发送机制或其他服务质量（QoS）保证，它依赖于底层服务去实现这一过程。RTP并不保证传送或防止无序传送，也不确定底层网络的可靠性。RTP实行有序传送，RTP中的序列号允许接收方重组发送方的包序列，同时序列号也能用于决定适当的包位置，例如：在视频解码中，就不需要顺序解码。
1.1.2 RTP报头
RTP报头格式如下：

V：RTP协议的版本号，占2位，当前协议版本号为2。
P：填充标志，占1位，如果P=1，则在该报文的尾部填充一个或多个额外的八位组，它们不是有效载荷的一部分。
X：扩展标志，占1位，如果X=1，则在RTP报头后跟有一个扩展报头。
CC：CSRC计数器，占4位，指示CSRC 标识符的个数。
M: 标记，占1位，不同的有效载荷有不同的含义，对于视频，标记一帧的结束；对于音频，标记会话的开始。
PT: 有效载荷类型，占7位，用于说明RTP报文中有效载荷的类型，如GSM音频、JPEM图像等。
序列号：占16位，用于标识发送者所发送的RTP报文的序列号，每发送一个报文，序列号增1。接收者通过序列号来检测报文丢失情况，重新排序报文，恢复数据。
时戳(Timestamp)：占32位，时戳反映了该RTP报文的第一个八位组的采样时刻。接收者使用时戳来计算延迟和延迟抖动，并进行同步控制。
同步信源(SSRC)标识符：占32位，用于标识同步信源。该标识符是随机选择的，参加同一视频会议的两个同步信源不能有相同的SSRC。
特约信源(CSRC)标识符：每个CSRC标识符占32位，可以有0～15个。每个CSRC标识了包含在该RTP报文有效载荷中的所有特约信源。
这里的同步信源是指产生媒体流的信源，它通过RTP报头中的一个32位数字SSRC标识符来标识，而不依赖于网络地址，接收者将根据SSRC标识符来区分不同的信源，进行RTP报文的分组。特约信源是指当混合器接收到一个或多个同步信源的RTP报文后，经过混合处理产生一个新的组合RTP报文，并把混合器作为组合RTP报文的SSRC，而将原来所有的SSRC都作为CSRC传送给接收者，使接收者知道组成组合报文的各个SSRC。
1.2 RTCP (Real-time Transport Control Protocol)
实时传输控制协议（Real-time Transport Control Protocol,RTCP）是实时传输协议（RTP）的一个姐妹协议。
RTCP为RTP媒体流提供信道外控制。RTCP定期在多媒体流会话参加者之间传输控制数据。RTCP的主要功能是为RTP所提供的服务质量提供反馈。
RTCP收集相关媒体连接的统计信息，例如：传输字节数，传输分组数，丢失分组数，时延抖动，单向和双向网络延迟等等。网络应用程序可以利用RTCP所提供的信息试图提高服务质量，比如限制信息流量或改用压缩比较小的编解码器。RTCP本身不提供数据加密或身份认证，其伴生协议SRTCP（安全实时传输控制协议）则可用于此类用途。

WebRTC内部采用的是RTC+RTCP

1.3 SRTP & SRTCP
SRTP = Secure Real-time Transport Protocol

SRTCP = Secure Real-time Transport Control Protocol

SRTP是在实时传输协议RTP基础上所定义的一个协议，旨在为单播和多播应用程序中的实时传输协议的数据提供加密、消息认证、完整性保证和重放保护。它是由 David Oran（思科）和Rolf Blom（爱立信）开发的，并最早由IETF于2004年3月作为RFC 3711发布。
1.4 RTSP (Real-time Transport Streaming Protocol)
RTSP（Real Time Streaming Protocol），RFC2326，实时流传输协议。RTSP在体系结构上位于RTP和RTCP之上，它使用TCP或UDP完成数据传输。
RTSP是一种基于文本的应用层协议，在语法及一些消息参数等方面与HTTP协议类似。
RTSP被用于建立的控制媒体流的传输，它为多媒体服务扮演“网络远程控制”的角色。尽管有时可以把RTSP控制信息和媒体数据流交织在一起传送，但一般情况RTSP本身并不用于传送媒体流数据，媒体数据的传送可通过RTP/RTCP等协议来完成。

1.5 SDP (Session Description Protocol)
会话描述协议（Session Description Protocol或简写SDP）描述的是流媒体的初始化参数。此协议由IETF发表为 RFC 2327。
SDP完全是一种会话描述格式，它不属于传输协议。
SDP用于描述多媒体通信会话，包括会话建立、会话请求和参数协商。SDP不用于传输媒体数据，只能用于两个通信终端的参数协商，包括媒体类型、格式以及所有其他和会话相关的属性。SDP以字符串的形式描述上述初始化参数。

可以参考《WebRTC – SDP格式解析》

1.6 SIP (Session Initiation Protocol)
SIP(Session Initiation Protocol)是一个应用层的信令控制协议。
SIP用于初始化一个Session，并负责传输SDP包；而SDP包中描述了一个Session中包含哪些媒体数据，邀请的人等等；当需要被邀请的人都通过各自的终端设备被通知到后，就可以使用RTSP来控制特定Media的通信，比如RTSP控制信息要求开始Video的播放，那么就开始使用RTP（或者TCP）实时传输数据，在传输过程中，RTCP要负责QoS等。
1.7 RTMP (Real Time Messaging Protocol)
RTMP(Real-Time Messaging Protocol实时消息传送协议)的缩写，它是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的一个基于TCP的应用层传输协议。这是一个标准的、未加密的实时消息传递协议，默认端口是1935。
RTMP是一种有状态协议。
RTMP协议有效的保证了媒体传输质量，使用户可以观看到高质量的多媒体。RTMP采用TCP协议作为其在传输层的协议，避免了多媒体数据在广域网传输过程中的丢包对质量造成的损失。此外RTMP协议传输的FLV封装格式支持的H．264视频编码方式可以在很低的码率下显示质量还不错的画面，非常适合网络带宽不足的情况下收看流媒体。
当然RTMP协议也有一些局限，RTMP基于TCP协议，而TCP协议实时性不如UDP，也非常占用带宽。目前基于UDP的RTMFP协议能很好的解决这些问题。

RTMPT封装在HTTP请求之中，可穿越防火墙;

RTMPS类似RTMPT，但使用的是HTTPS连接;

1.8 RTMFP (Real Time Media Flow Protocol)
RTMFP是Adobe公司开发的一套新的通信协议。
RTMFP是基于UDP的，RTMP是基于TCP的。UDP在传送直播数据方面比TCP还是有较多优势的，比如减少延时，对丢包的容忍，虽然在可靠性上有所损失。与RTMP不同, RTMFP支持Flash Player直接发送数据给另一个，而不经过Server。
1.9 RSVP (Resource ReSerVation Protocol)
使用RSVP预留一部分网络资源（即带宽），能在一定程度上为流媒体的传输提供QoS。通常 RSVP 请求将会引起每个节点数据路径上的资源预留。
RSVP 只在单方向上进行资源请求，因此，尽管相同的应用程序，同时可能既担当发送者也担当接受者，但 RSVP 对发送者与接受者在逻辑上是有区别的。 RSVP 属于网络层协议。 RSVP 不传输应用数据，但支持因特网控制协议，如 ICMP、IGMP 或者路由选择协议。
1.10 MMS (Microsoft Media Server Protocol)
MMS(Microsoft Media Server Protocol)，微软媒体服务器协议，用来访问接收 Windows Media 服务器中 .asf 文件的一种协议。MMS 协议用于访问 Windows Media 发布点上的单播内容。
MMS的默认端口是1755.
1.11 HLS (HTTP Live Streaming)
HTTP Live Streaming（缩写是HLS）是一个由苹果公司提出的基于HTTP的流媒体网络传输协议。它的工作原理是把整个流分成一个个小的基于HTTP的文件来下载，每次只下载一些。当媒体流正在播放时，客户端可以选择从许多不同的备用源中以不同的速率下载同样的资源，允许流媒体会话适应不同的数据速率。在开始一个流媒体会话时，客户端会下载一个包含元数据的extended M3U (m3u8)playlist文件，用于寻找可用的媒体流。
HLS只请求基本的HTTP报文，与实时传输协议（RTP)不同，HLS可以穿过任何允许HTTP数据通过的防火墙或者代理服务器。它也很容易使用内容分发网络来传输媒体流。
HLS协议规定：
视频的封装格式是TS。
视频的编码格式为H264,音频编码格式为MP3、AAC或者AC-3。
除了TS视频文件本身，还定义了用来控制播放的m3u8文件（文本文件）。
二、封装格式

名称
推出机构
流媒体支持
支持的视频编码
支持的音频编码
AVI
Microsoft Inc.
否
几乎所有格式
几乎所有格式
MP4
MPEG
是
MPEG-2, MPEG-4, H.264, H.263等
AAC, MPEG-1 Layers I, II, III, AC-3等
TS
MPEG
是
MPEG-1, MPEG-2, MPEG-4, H.264
MPEG-1 Layers I, II, III, AAC
FLV
Adobe Inc.
是
Sorenson, VP6, H.264
MP3, ADPCM, Linear PCM, AAC等
MKV
CoreCodec Inc.
是
几乎所有格式
几乎所有格式
RMVB
Real Network Inc.
是
RealVideo 8, 9, 10
AAC, Cook Codec, RealAudio Lossless
三、视频编码格式

名称
推出机构
推出时间
HEVC(h.265)
MPEG/ITU-T
2013
H.264
MPEG/ITU-T
2003
MPEG4
MPEG
2001
MPEG2
MPEG
1994
VP9
Google
2013
VP8
Google
2008
VC-1
Microsoft Inc.
2006
四、音频编码格式

名称
推出机构
推出时间
AAC
MPEG
1997
AC-3
Dolby Inc.
1992
MP3
MPEG
1993
WMA
Microsoft Inc.
1999


目前，直播服务普通采用RTMP作为流媒体协议，FLV作为封装格式，H.264作为视频编码格式，AAC作为音频编码格式化。点播服务普通采用HTTP作为流媒体协议，H.264作为视频编码格式，AAC作为音频编码格式，而封装格式有多种，如MP4，FLV，F4V等。

在EasyDSS流媒体服务器的客户反馈中，我们遇到这样一个现象，在chrome中经常会出现RTMP/HLS流无法播放的问题：

这个问题复现的几率比较低，因为chrome禁止了flash的加载，这也从另一个角度反应了H5势在必行，各家浏览器对flash的支持也越来越严苛了：

只要在加载中将flash插件支持加上就可以了
通用前端做法
后来我观察了一下各家视频网站的大体做法，发现基本上现在都采用自动检测的方法了，很少再会出现报“no compatible source was found for this media”的错误，以企鹅直播为例：


前端都会自动加上flash检测的功能，如果flash没安装，就会跳转到flash下载的页面上，于是后续的EasyDSS前端也采用了这种方式，很好滴解决了“no compatible source was found for this media”问题的出现：


关于搜索解决“no compatible source was found for this media”的同学比较多，希望本篇博客是能够帮助大家解决问题的，如果还有其他方案或者问题情况，感谢大家能够将解决方案留言出来，帮助更多的人解决问题；


✈ 更多视频解决方案资源汇总

流媒体技术：

© EasyDarwin开源流媒体服务器：http://www.easydarwin.org

© TSINGSEE视频开放平台：http://open.tsingsee.com


视频云服务

© EasyDSS互联网视频云服务：http://www.easydss.com

© EasyCVR安防视频云服务：http://www.easycvr.com

© EasyGBS国标视频云服务：http://www.easygbs.com

© EasyRTC在线视频会议平台：http://www.easyrtc.cn

© EasyRTS即时通信云服务：http://www.easyrts.com


边缘计算：

© EasyNVR视频边缘计算网关：http://www.easynvr.com

© EasyNTS上云网关：http://www.easynts.com

© TSINGSEE Team：http://www.tsingsee.com