另外，这里推荐一个H.264 Codec相关的资料 h264 Codec
内容
开始
故障排查
开始
终端播放能力总览
这个部分简要的介绍了终端的播放能力和支持的流传输协议。
-
Android:大部分Android设备都支持RTSP/RTP协议。运行2.2及以上版本的新Android设备也支持Adobe Flash player 10.1，可以播放RTMP和Adobe HDS 流媒体。
Android设备不能通过RTSP/RTP播放任何音频为MP3格式的流(包括音视频和纯音频)。支持Flash player 10.1的Android设备可以通过RTMP或Adobe HDS播放MP3流。
当Android设备播放RTSP/RTP流时，RTP数据包必须通过UDP来传输。Android不支持RTSP/RTP交错模式(RTP over TCP)。这意味着如果不能用UDP来传输RTP数据包，那么你不可能用TCP来替代UDP传输RTP数据包，这样的流是无法播放的。
有客户曾报告过在DroidX 和 Droid 2上遇到RTSP/RTP播放的问题，看起来似乎在这些设备上只有下面的几个帧大小才能正常播放:
- 800x480
- 480x320
- 240x160
- Sony Ericsson:有客户曾报告过有些Sony Ericsson 的手机需要Baseline Profile Level 1.2 或更低才能正常播放。
- BlackBerry: 大部分黑莓终端都支持RTSP/RTP流传输协议。许多黑莓手机在RTP over UDP遇到问题时还支持RTSP/RTP交错模式(RTP over TCP)。
- iOS: iPhone、iPad、和iPod touch 设备只支持Apple HTTP Live Streaming。iOS设备不支持RTSP/RTP流媒体传输协议。
- Windows Phone: Windows手机可以通过在Microsoft Media Platform Player Framework上构建的应用支持Microsoft Smooth Streaming协议。
- 其它设备: 大部分其它支持媒体播放的移动终端，例如诺基亚、三星、索爱等都支持RTSP/RTP。但对于MP3 over RTSP/RTP的支持不如AAC-LC更广泛。
配置
下面介绍了对于VOD点播和直播的应用配置。
VOD点播
首先建立一个用于VOD点播的应用。
注意:Wowza Media Server在安装时已经包含了一个预先配置好的应用，应用名为vod。
直播
要建立一个用于直播的应用，请阅读下面的参考资料(基于不同的编码器类型):
- 如何通过RTSP将流推送(push)给Wowza Media Server?
- 如何通过RTMP将流推送(push)给Wowza Media Server?
- 如何从RTSP源将流拉到(pull)Wowza Media Server?
- 如何通过RTP over UDP将流推送(push)到Wowza Media Server?
- 如何通过MPEG-TS over UDP将流推送(push)到Wowza Media Server?
故障排查
编码
最好是将视频编码为较低的码率和帧率、以及较低的编码复杂度。对于移动终端，最好把总码率控制在64Kbps 到 250Kbps 之间。许多移动终端没有能力处理超过30帧/秒的视频。对于移动终端最好将帧率控制在15fps到24fps 之间，同时最好编码为较低的H.264复杂度。大部分移动终端只支持H.264 Baseline Profile。 关于H.264编码的复杂度和等级，在Wikipedia里有详细讨论。
网络配置(UDP 和 TCP)
UDP
最好为RTSP/RTP流播放打开所有UDP端口(0-65535)。在输入侧，Wowza Media Server使用的端口为6970到9999之间。在输出侧(流播放侧)，使用的UDP端口依赖于具体的终端设备。因此为了UDP输出流，最好是打开所有的UDP端口。 正确的配置好UDP网络有时候有些困难，它依赖你路由器和防火强的配置。如果Wowza Meida Server在NAT(network address translation)后面，要将所有的UDP端口映射到运行Wowza Media Server的服务器上，这一点非常重要。
Wowza提供了一个运行在Amazon EC2平台上的RTSP/RTP测试流，这些流可以在大部分移动终端/网络环境下正常播放。 Amazon EC2平台是一个实验RTSP/RTP流的绝好平台。要了解更多，请阅读Wowza for Amazon EC2.
有些移动网络运营商不允许RTP或UDP传输。这种情况下，许多移动终端将会转换到RTSP/RTP交错模式(RTP over TCP)上。 这样，当运营商网络不支持UDP时，这些终端将会正常播放。有些终端不支持RTSP/RTP交错模式，当UDP受阻时就无法正常播放。 因此在测试你的RTSP/RTP流之前，请先使用RTSP/RTP测试流来看看是否能正常播放。
TCP
RTSP流传输协议的默认TCP端口554。有些播放器只用这个端口。因此如果你的Wowza Media Server流播放URL中使用的端口为默认的1935，那么可能无法播放。 要使得Wowza Media Server 使用这个端口，请打开[install-dir]/conf/VHost.xml文件，并在HostPort/Ports列表中添加554和80:
<Port>1935,554,80</Port>请确认在同一个服务器上没有运行另一个RTSP/RTP流媒体服务器(例如Darwin Streaming Server)。 它可能也使用554端口，这样会引起端口冲突。当554端口启用后，在RTSP播放URL中你可以省略端口号(因为前面介绍了这个播放器默认只能使用554端口) 例如，在使用手册中我们建议使用下面的RTSP播放URL播放VOD内容:
rtsp://[wowza-ip-address]:1935/vod/mp4:sample.mp4554端口启用后，这个URL可以省略端口号，如下:
rtsp://[wowza-ip-address]/vod/mp4:sample.mp4
如何为RTSP调试增加更多的日志输出
你可以在[install-dir]/conf/[application]/Application.xml文件的MediaCaster/Properties容器中添加下面的属性，从而可以在日志中记录更多的关于RTSP/RTP源和Wowza Media Server之间RTSP握手时的debug信息:
<Property>
<Name>debugRTSPSession</Name>
<Value>true</Value>
<Type>Boolean</Type>
</Property>
你可以在[install-dir]/conf/[application]/Application.xml文件的RTP/Properties容器中添加debugRTSPSession属性，从而可以在日志中记录更多的关于RTSP/RTP播放客户端与Wowza Media Server之间RTSP握手时的debug信息:
RTSP 调用流程
在一个典型的RTSP会话中，其中RTP数据包通过UDP传输， uses a workflow described in the following client > server and server > client message exchanges:
-
客户端向服务器发出一个OPTIONS request以初始化与服务器的会话。服务器对这个请求进行回应告诉客户端它的支持范围以及能够接收什么类型的请求。
Client > Server: Request
OPTIONS rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov RTSP/1.0 CSeq: 2 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13)
Server > Client: Response
RTSP/1.0 200 OK Supported: play.basic, con.persistent Cseq: 2 Server: Wowza Media Server 3.6.2 build5334 Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE, RECORD, GET_PARAMETER Cache-Control: no-cache
-
客户端发出一个DESCRIBE 消息，服务器返回一个SDP文件，客户端可以用它获得更多这个服务器要发送的媒体内容的信息。
这个SDP文件包含了媒体流的音视频编码信息、时长、轨道ID(trackID)、profile 级别等信息。
在下面的例子中，音频轨道为trackID=1，视频轨道为trackID=2。
Client > Server
DESCRIBE rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov RTSP/1.0 CSeq: 3 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Accept: application/sdp
Server > Client
RTSP/1.0 200 OK Content-Base: rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/ Date: Tue, 23 Apr 2013 14:19:15 UTC Content-Length: 576 Session: 408754851;timeout=60 Expires: Tue, 23 Apr 2013 14:19:15 UTC Cseq: 3 Content-Type: application/sdp Server: Wowza Media Server 3.6.2 build5334 Cache-Control: no-cache v=0 o=- 408754851 408754851 IN IP4 127.0.0.1 s=BigBuckBunny_175k.mov c=IN IP4 0.0.0.0 t=0 0 a=sdplang:en a=range:npt=0- 596.458 a=control:* m=audio 0 RTP/AVP 96 a=rtpmap:96 mpeg4-generic/48000/2 a=fmtp:96 profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1190 a=control:trackID=1 m=video 0 RTP/AVP 97 a=rtpmap:97 H264/90000 a=fmtp:97 packetization-mode=1;profile-level-id=42C01E;sprop-parameter-sets=Z0LAHtkDxWhAAAADAEAAAAwDxYuS,aMuMsg== a=cliprect:0,0,160,240 a=framesize:97 240-160 a=framerate:24.0 a=control:trackID=2
-
客户端向服务器发送2个SETUP请求，一个用于视频轨道，一个用于音频轨道。客户端会在前面的DESCRIBE请求的应答中接收到这个轨道ID.
在SETUP消息交换过程中，客户端会向服务端宣告它将使用哪些UDP端口来接收音频和视频的RTP数据包以及RTCP消息。
服务端将向客户端响应说它知道了客户端用于RTP/RTCP通信的端口，并向客户端宣告服务端用到的在这个session中用到的UDP端口。
在下面的例子中，客户端将使用下面的端口:
音频
- 服务器将从UDP源(服务器)的7066端口向UDP目的地址(客户端播放器)的57780端口发送RTP数据包
- 服务器将从UDP源(服务器)的7067端口向UDP目的地址(客户端播放器)的57781端口发送RTCP发送方报告(sender reportion)
- 客户端将从UDP源(客户端播放器)的57781端口向USP目的地址(服务器)的7067端口发送接收方报告(receiver report)
视频
- 服务器将从UDP源(服务器)的7064端口向UDP目的地址(客户端播放器)的57782端口发送RTP数据包
- 服务器将从UDP源(服务器)的7065端口向UDP目的地址(客户端播放器)的57783端口发送RTCP发送方报告(sender report)
- 服务器将从UDP源(客户端播放器)的57783端口向UDP目的地址(服务器)的7065端口发送接收方报告(receiver report)
Client > Server: SETUP request for audio track
SETUP rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/trackID=1 RTSP/1.0 CSeq: 4 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Transport: RTP/AVP;unicast;client_port=57780-57781
Server > Client
RTSP/1.0 200 OK Date: Tue, 23 Apr 2013 14:19:15 UTC Transport: RTP/AVP;unicast;client_port=57780-57781;source=184.72.239.149;server_port=7066-7067;ssrc=07938AE3 Session: 408754851;timeout=60 Expires: Tue, 23 Apr 2013 14:19:15 UTC Cseq: 4 Server: Wowza Media Server 3.6.2 build5334 Cache-Control: no-cache
Client > Server: SETUP request for video track
SETUP rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/trackID=2 RTSP/1.0 CSeq: 5 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Transport: RTP/AVP;unicast;client_port=57782-57783 Session: 408754851
Server > Client
RTSP/1.0 200 OK Date: Tue, 23 Apr 2013 14:19:15 UTC Transport: RTP/AVP;unicast;client_port=57782-57783;source=184.72.239.149;server_port=7064-7065;ssrc=1206BD1C Session: 408754851;timeout=60 Expires: Tue, 23 Apr 2013 14:19:15 UTC Cseq: 5 Server: Wowza Media Server 3.6.2 build5334 Cache-Control: no-cache
-
当通信端口被建立后，客户端将会发送PLAY请求，它告诉服务端它已经准备好了，可以随时接收服务端发送的RTP数据包。当对请求做了应答后，服务端开始发送RTP数据包，并间歇性的发送发送方报告(sender report)。
服务端同时将收到客户端发送的接收方报告(receiver report)。从RTP数据包开始从服务端传输到客户端开始，接收方报告(receiver report)就是服务端从客户端接收到的关于通信状态的唯一反馈信息，通过它可以确认客户端正在接收RTP数据包。
Wowza 流媒体的应用配置文件[install-dir]/conf/[application]/Application.xml 中有一个参数定义了在停止发送RTP数据包之前要等待接收RTCP接收方报告(receiver report)的时间:
<MaxRTCPWaitTime>12000</MaxRTCPWaitTime>
如果没有来自客户端的接收方报告(receiver report)，这意味着客户端没有再接收RTP数据包了，可以停止发送RTP数据包了。
在进行RTSP故障排查时，你可以用Wireshark包分析器跟踪整个服务端和某一个客户端的通信过程，它可以呈现RTP/RTCP通信的端口信息并可以过滤出某一个源和目的IP地址的信息。
RTP包应该按顺序依次到达客户端。你可以分析服务端的发送方报告(sender report)来看看哪一个是服务端发出的最后的数据包并和客户端接收到数据包做比较。
如果在你服务端使用Wireshark，你可以检查是否可以收到接收方报告(receiver report)并获得客户端接收到的最后的数据包的信息。你也可以得到丢包率、客户端收到的最后一个数据包的序列号等等其它信息。
Client > Server
PLAY rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/ RTSP/1.0 CSeq: 6 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Session: 408754851 Range: npt=0.000-
Server > Client
RTSP/1.0 200 OK Range: npt=0.0-596.458 Session: 408754851;timeout=60 Cseq: 6 RTP-Info: url=rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/trackID=1;seq=1;rtptime=0,url=rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/trackID=2;seq=1;rtptime=0 Server: Wowza Media Server 3.6.2 build5332 Cache-Control: no-cache
-
当用户按了暂停按钮或者关闭了播放器，客户端将向服务端发送一个TEARDOWN请求以宣告它播放已经暂停。服务端将停止向客户端发送RTP数据并停止流传输会话(session)。
Client > Server
TEARDOWN rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov/ RTSP/1.0 CSeq: 7 User-Agent: LibVLC/2.0.5 (LIVE555 Streaming Media v2012.09.13) Session: 408754851
Problematic SDP files
许多RTSP源，尤其是IP摄像头，在向客户端发送Session Description Protocol (SDP)消息时会出现错误的H.264 profile-level-id。 这样会引起视频间断或被损坏。你可以配置Wowza Media Server忽略SDP信息中的profile-level-id而采用由sprop-parameter-sets定义的数值，你可以在[install-dir]/conf/[application]/Application.xml文件的RTP/Properties容器中添加下面的属性:
<Property> <Name>rtpIgnoreProfileLevelId</Name> <Value>true</Value> <Type>Boolean</Type> </Property>
在非iOS设备上使用Apple HTTP Live Streaming协议的播放器
在Android 4.0及以上版本使用(Cupertino/Apple HTTP Live Streaming)
http://[wowza-ip-address]:1935/vod/mystream/playlist.m3u8如果80端口被启用，这个播放URL可以改为:
http://[wowza-ip-address]/vod/mystream/playlist.m3u8在非iOS设备上支持Apple HTTP Live Streaming (HLS)流传输协议的播放器相关问题，请阅读How to turn off data event processing for Apple HTTP Live Streaming streams。
测试流播放URL
RTSP/RTP 测试流: http://www.wowzamedia.com/mobile.html
这是一个运行在Amazon EC2平台上的配置好的测试流。RTSP播放URL为 rtsp://184.72.239.149/vod/mp4:BigBuckBunny_175k.mov
测试H.264编码的VOD文件: http://www.wowzamedia.com/_h264/BigBuckBunny_175k.mov