What player are you using? Have you tried VLC?
Richard
You are publishing to an application named “live”, then in Flash you are trying to play from an application named “rtplive”.
On IPhone, it doesn’t work because the stream is encoded with h.264 main profile. It should be baseline profile:
WARN 200 - LiveStreamPacketizerCupertino.handlePacket: Video encoding settings are beyond iPhone/iPod touch recommendations (Baseline/3.0) [live/definst/myStream.sdp]: {H264CodecConfigInfo: profile: “Main”, level: 1.0, frameSize: 160x120, aspect: 0/1, crop: l:0 r:0 t:0 b:4} - - - 91.01
Richaard
Wirecast is a very good choice. AAC is included. It works great for this application.
Richard
Try something like:
Format Flash/h.264, 320X240, FPS 15 (24,30), Average bitrate 500, Limit peak bit rate checked, Profile baseline, keyframes (5 x fps), AAC audio checked.
As a starting place.
Richard
Yes, audio is about the same as video, in most cases (doesn’t work in Silverlight)
Yes, multi-bitrate works with FMLE. See the “Multi-bitrate Video Streaming” section of the live tutorial:
https://www.wowza.com/docs/how-to-set-up-live-streaming-using-an-rtmp-based-encoder
Richard
No, it’s not support. (it’s not necessary to double post).
Richard
The stream doesn’t seem to be live anymore. But make sure you have LiveSteamPacketizers set to “cupertinostreamingpacketizers”
<LiveStreamPacketizers>cupertinostreamingpacketizer</LiveStreamPacketizers>
Also, I don’t think QTB has a way to set Profile to Baseline 3. So it might not work on all apple devices. Should work on IPad and maybe on IPhone 4, or IPhones with iOS 4.0s
Richard
Make sure you are trying to play the stream you are publishing. Your application name has changed from “rtplive” to "live. Use the same application name that you are using in the encoder, and same stream name. Check the encoder settings, and align with the url you are forming to play the stream.
It would be easier to debug the application without “DEBUG” logging turned on. You should see a publish event from the encoder and each play attempt.
Richard
Take a look at this guide:
http://www.wowza.com/forums/showthread.php?t=7870
It played here for me with Quicktime player 7.6.7 on Windows.
Richard
Oh, sorry, that guide is specific to Windows.
Richard
Flash is the still the best way to get through to the most people, and there is no player configuration on the user end necessary.
Richard
Quicktime player will work iif you open up all UDP ports and add TCP port 554 to /conf/VHost.xml /HostPort /Port “1935”, change that to “1935,554”
QT player is different on Mac and Windows. For example cupertino live streaming is supported in QT on Mac but not Windows. This is player/platform issue, and it is one reason why Flash is still the recommended client for the desktop.
Richard
Looks like I forgot to point you to this:
http://www.wowza.com/community/t/-/97
Sorry about that. That could help.
Opening UDP ports 6970 - 9999 is good. The Mobile Trouble Shooting Guide suggest all UDP ports (I know this is not a mobile device issue, but I’m just putting that out there)
Richard
That’s great, glad it’s working. Thanks for the update.
Richard
The bitrate is very high: 2mbs and higher.
I have very fast connection and it is pretty good VLC and Quicktime. I have seen some “max headroom” affect, but very slight.
You have to get the bitrate down.
Richard
It has been my experience that QuickTime doesn’t play nice on RTSP coming from Wowza. I’ve seen a number of forum posts here from people with similar experiences.
We saw the “Max Headroom” effect a lot on RTSP when it goes over UDP via the internet to/from a Wowza instance on EC2. This happened both when encoding using WireCast (before it did RTMP), and when playing back RTSP with an Amino STB.
My strong suspicion is that this is an artifact related to UDP over a network without end-to-end QoS.
When I use this method (QT Broadcaster --> Wowza), the audio and video are attempting to bind to the same UDP ports. Thus I only get audio (which binds first), and no video. Here is the SDP code from the debugging log:
v=0
o=- 11 4293238381 IN IP4 127.0.0.0
s=QuickTime
c=IN IP4 [server ip]
t=0 0
a=range:npt=now-
a=isma-compliance:2,2.0,2
m=audio 6970 RTP/AVP 96
b=AS:63
a=rtpmap:96 mpeg4-generic/44100/1
a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1208
a=mpeg4-esid:101
a=control:trackid=1
m=video 6970 RTP/AVP 97
b=AS:643
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=4D4016;sprop-parameter-sets=J01AFqkYFAe2ANQYBBrbCte98BA=,KN4JF6A=
a=mpeg4-esid:201
a=cliprect:0,0,480,640
a=framesize:97 640-480
a=control:trackid=2
I used “netstat -a” and determined there were no other programs using the 6970-9999 UDP port range prior to starting my broadcast. Once I start my broadcast in QT Broadcaster, Wowza binds on 6970 and 6971 first, then throws these errors:
WARN 200 - RTPUDPTransport.bind[live/definst]: Address already in use: 0.0.0.0/0.0.0.0:6970
WARN 200 - RTPUDPTransport.bind[live/definst]: Address already in use: 0.0.0.0/0.0.0.0:6971
Which seem to confirm that it’s trying to use the same two ports for video, instead of moving up to 6972 and 6973. Using Wirecast via RTSP works fine – it binds to four consecutive ports (i.e. 6970-6973) and I see the following SDP in the logs:
v=0
o=- 412523967 412523967 IN IP4 127.0.0.0
s=Wirecast
c=IN IP4 [server ip]
t=0 0
a=range:npt=now-
m=audio 0 RTP/AVP 96
a=rtpmap:96 mpeg4-generic/44100/1
a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1208
a=control:trackid=1
m=video 0 RTP/AVP 97
a=rtpmap:97 H264/90000
a=fmtp:97 packetization-mode=1;profile-level-id=4D4016;sprop-parameter-sets=J01AFqkYFAe2ANQYBBrbCte98BA=,KN4JyA==
a=cliprect:0,0,480,640
a=framesize:97 640-480
b=AS:627
a=control:trackid=2
Any ideas? I can turn on the “Broadcast over TCP” option in Broadcaster, but then the audio and video are very choppy and blocky, so I’d rather get the UDP method working correctly. (Both the UDP and TCP methods play fine through Wirecast.)
I’m using WMS 2 with the new patch11 applied, server tuned, and firewall off.
Ah yes – forceInterleaved fixed the TCP blockiness. Don’t know why I didn’t think of that.
As for the “start at a higher port” suggestion, this is the Automatic Unicast (Announce) method, so no port is specified by me. I presume Wowza is generating those?
I just sent an email to the support address with the requested files.
EDIT: Forgot to add that QuickTime Broadcaster is version 1.5.3 (the most recent version).
A helpful hint (posted elsewhere too, but relevant to this method):
In QuickTime Broadcaster, uncheck the “Frame Reordering” option under the Video tab. This will keep your audio and video in sync through any user interface slowdown in a flash video player.
