No, it does not establish an RTSP connection. Wowza Pro in this case reads the SDP file and opens the ports defined in the SDP file and begins listening for incoming UDP packets.
Charlie
Do you see the player connecting to Wowza Pro to play the stream? It sounds like the player is not connecting.
Charlie
With the Flash player if you set the NetStream.setBufferTime to zero, install the most recent patch from here (http://www.wowza.com/devbuild.html) and use the rtp-live-lowlatency stream type you will see the best latency out of Flash and Wowza Pro. With the Haivision Mako hardware H.264 encoders the latency is less then 1 second. If you are seeing numbers greater than this then it is most likely on the encoding side. If you set NetStream.setBufferTime to anything greater then 0 with H.264/AAC video the latency will jump up to 2-3 seconds. So do be sure you have set this property set correctly.
Charlie
Putting it in an FLV container will not effect the playback performance.
Charlie
One thing to try is to edit the SDP file and change this line:
c=IN IP4 0.0.0.0
to point to the local ip address on the machine to which the stream is being sent.
Charlie
Can you post back the error message you got when you modified the SDP file. The problem is that the encoder is most likely binding to the same port as Wowza Media Server is binding to. So there is a conflict. If you can modify the encoder so that it uses two different port numbers on either side of the communication it would help.
Charlie
I think I get what you are trying to do.
This might be easier to do in Wowza 2.0. In Wowza 2.0 we have a thing called a .stream file. The .stream file is an alias for a stream. It is a simple text file that can contain a complex RTSP or MPEG-TS URL. You could create a simple HTTPProvider that would write a .stream file in the content folder to enable a stream for re-streaming. When the stream was no longer available it would remove the .stream file.
The client would then request the stream using the .stream filename. The MediaCaster system would maintain the connection to the RTSP based encoder and the data could be interleaved over the RTSP connection.
I hope this makes sense.
Charlie
You can use HTTPProviders to read and write SDP file to the [install-dir]/content folder. This is pretty straight forward. If you set the MediaCaster/Properties property sdpFileCheckFrequency the Wowza will check to see if the SDP file has changed based on this time value (in milliseconds). It it changes it will re-start the stream and re-read the SDP file. The sdpFileCheckFrequency property is covered in the User’s Guide.
Charlie
Yes, in both 1.7 and 2.0 (we did not remove any functionality).
Yes, you can host the SDP file at a web server and address it with http url. Really no magic. Just use the URL to the SDP file rather then copying file to content folder and using filename.
Charlie
The url should be:
rtsp://localhost:1935/rtplive/myStream-osprey240e.sdp
Not 1934.
Charlie
Hi.
I’m using the FFMPEG command-line application for testing, with the following command params:
ffmpeg -i testmedia.mov -vcodec libx264 -an -flags +loop -f rtp rtp://127.0.0.1:6000
I’ve sent you the logs of 2 playback sessions - one works perectly, and the second one doesn’t work at all.
The prevailing debug warning in logs is this one (and it appear to happen on the second playback):
DEBUG server comment - rtp[video:77] {80 e0 1b 68 00 d7 80 73 00 00 00 00 41 9a b5 b0 }
DEBUG server comment - myStream.sdp: 23:15:06: latepacket: curr:72552 last:72558
DEBUG server comment - rtp[video:35] {80 60 1b 69 00 d7 8c 2e 00 00 00 00 67 42 c0 1e }
DEBUG server comment - myStream.sdp: 23:15:06: latepacket: curr:72553 last:725
I should mention, that only restarting both the RTP encoder and Wowza server seems to resolve the issue (until the next hang).
Thanks.
I think you can set the client-side buffer to 0. But this can create other playback issues.
So 2 to 3 second delay for h.264 is normal.
Richard
It is “live” if it is trasmitted directly. The delay is encoding and transmission time. The encoder and Flash player are big factors, Wowza is just in the middle.
The fastest StreamType is “live-lowlatency”, which is what you want for chat applications. If everyone has a good connection, the latency is close to a phone call. But it uses a regular flv file over rtmp, not h.264 over rtp.
There is also a “rtp-live-lowlatency” StreamType. I’m not sure how much faster it is, I think it will still have most of the delay associated with h.264.
I think this is the state-of-the-art at present. Maybe it will be faster next year.
Richard
Right, as I understand it, you could put h.264 encoded video into a flv container, but it is not best practice.
Richard
Use the “file” Flashvar in the html container:
Flashvars = “&file=http://yourdomain.com/myStream.sdp&streamer=rtmp://ip/app&provider=rtmp”;
Richard
Thanks - I have been very successful (and quite pleased) with previous pre-release and QuickTime broadcaster.
Upgraded to full release - now responding to a few new items like changed administrator XML etc.
SDP was not required in previous pre-release - or I was able to slip by without it. Now my logs are filling up with errors not able to locate an SDP file. Stream works - just that 100 viewers makes for messy logs.
I saw nothing in the link to other thread on this specific (SDP).
I will look at the QT broadcaster export in the morning.
Thanks!
I want the wowza RTP live-encoder to receive audio/video packets over RTP from a remote server and send them over RTMP to a flash player, AND receive audio/video packets over RTMP from the flashplayer and send them over RTP to a the remote RTP server.
Wowza 2.0.0-preview9 build22657 runs on winXP. All apps run on localLAN, actually VM. The flashplayer is version 10.
I set the netstream.buffertime = 0 for flash app.
I first choose RTP-live-lowlatency for both play and publish, then rtp-live-record-lowlatency because I want to verify the audio/video contents.
I added rtp-jitter-buffer, changes the properties for streams and mediaCaster based on the suggestion from the forum and userguide. and use http:URL for the SDP access.
sortPackets
true
Boolean
sortBufferSize
500
Integer
streamTimeout
15000
Integer
sdpFileCheckFreqency
2000
Integer
sdpHTTPCheckFreqency
10000
Integer
Here are the issues after I ran the code,
(1) I wait for a while (10-15 seconds) to hear the sound. It means that the play actually works but with a long delay.
why did it take so long to forward the audio to the flash client?
(2) I got broken/stuttering voice, electric streaming background voice, missing sound.
how to improve the audio / video quality and remove the noise in the background?
(3) the wireshark didnot show the RTP packet from wowze to the remote RTP server. That means there was an issue in publishing. Can the publish stream use the same stream type to receive the A/V packets over RTMP and send the A/V packets over RTP? Is is the right way?
(4) the FLVs generated under /content cannot recoginzed/read by VLC with the complaint for "not suitable decoder module: vlc doesnot support the audio and video format "undf "
I emailed you and support group with the SDP files, server logs and app config file.
Please let me know what I need to do next to fix the above 4 issues. Thanks a bunch,
No, it does not establish an RTSP connection. Wowza Pro in this case reads the SDP file and opens the ports defined in the SDP file and begins listening for incoming UDP packets.
Charlie
Well in that case I can’t understand why it’s not working. I followed the instructions above. Here’s the SDP file I’m putting in the content folder. When I then start Wowza, though, netstat -a tells me that nothing is listening on port 6015.
Did you set the stream type to rtp-live?
Yes.
What is showing up in the Wowza Pro logs? If you run Wowza Pro standalone then you can watch the log entries. You should see the bind statements and a firstPacket log statement when the first UDP package arrives.
Charlie
The only bind lines i see in the /logs directory are these:
INFO vhost comment 2009-02-26 14:57:25 - - - - - 1.406 - - - - - - _defaultVHost_ RTMP/RTMPT bind attempt ([any]:1935)
INFO vhost comment 2009-02-26 14:57:25 - - - - - 1.422 - - - - - - _defaultVHost_ Bind successful ([any]:1935)
So it seems to be binding OK to the RTMP port but not even trying to bind to the port in my SDP. 
Why would this be?
