To play the stream, double click [install-dir]/examples/LiveVideoStreaming/client/live.html enter the following information and click the Play button:
[b]Server[/b] to [b]rtmp://[server-ip-address]/rtplive[/b]
[b]Stream[/b] to [b][noparse]rtsp://[encoder-ip-address][/noparse][/b] (Example: [noparse]rtsp://192.168.1.8:554[/noparse])
Where [server-ip-address] is the ip address of the server running Wowza Pro and [encoder-ip-address] is the ip address of the RTSP device.
Note: Some cameras do not support RTSP/RTP interleaving (sending the RTP packet data over the RTSP TCP connection) If this is the case then set the forceInterleaved property above to false, restart Wowza Media Server and try to play the stream.
Note: Some cameras do not send RTCP packets. If you see the warning log message:
Waiting for RTCP packet. See docs for (Application.xml: RTP/AVSyncMethod and RTP/MaxRTCPWaitTime).
Edit [install-dir]/rtplive/Application.xml and change the RTP/AVSyncMethod to systemclock.
Note: If you are re-streaming an H.264 stream from an Axis Communications camera such as the following models (which natively support H.264): M1011(-W), M1031-W, P3301(-V), Q1755, Q6032 the RTSP url take the form:
where [camera-ip-address] is the ip adress of the Axis camera.
Note: By default Wowza Pro streams using UDP on ports 6970 - 9999 and TCP port 554. This can be a problem if you are streaming to a Wowza Pro server or Oscar that is behind a firewall on which these ports are blocked. To resolve this issue, you need to open up the UDP port range 6970 - 9999 and TCP port 554 on any firewalls between the Oscar encoder and Wowza Pro. You may also need to adjust the [oscar-ip-address] if the Oscar is behind a router that has provided a NAT address for the device.
Note: Many players will not accept stream names that look like urls. You can use the stream name alias package to create an alias for the stream name url. This package can also be used to secure Wowza Pro so that it will only be able to restream urls that you specify. This package can be downloaded from here: StreamNameAlias.
Note: There is an issue when re-streaming an RTSP/RTP stream that is hosted by Quicktime Streaming Server (Darwin, QTSS) that after 2 minutes of streaming the stream will be dropped by QTSS. This is caused by the fact that Wowza Pro does not send RTCP Receiver Report packets back to QTSS. This causes QTSS to timeout and disconnect the stream based on the rtp_timeout value defined in streamingserver.xml. The current workaround for this issue is to set the rtp_timeout property in QTSS to 0 (zero) which will disable this timeout feature. We are investigating supporting RTCP RR packets in a future release of Wowza Pro.
Note: If you experience problems getting either the audio or video to play through Flash, double check the version number of the Flash player (Flash player version 9.0.115.0 or above is required). If you still have problems, turn on Wowza Pro debug logging (edit [install-dir]/conf/log4j.properties and change the log4j.rootCategory on the first line from INFO to DEBUG), try the encoder several more times, zip up and send your [install-dir]/logs folder along with screen shots of the encoder setup screens and the LiveVideoStreaming player screen and send a detailed description of your problem to support@wowza.com.
I think I see the issue. I have never seen an RTSP session where the control name is a=control:rtsp://192.168.3.53/video. I have never seen it with the full url prefix. Let me think about this and get back to you.
It does only connect to the source once. It doesn’t connect to the source until the first client requests the stream. If a second client comes along and requests the same stream it will not create another connection to the source all future connections will be served from the single connection to the source. Once the last client drops off then the Wowza Pro will remain connected to the source for 10 seconds waiting for additional client. If no other client request the stream it will drop the connection.
I am actively working on a Flash based tool for managing these sessions so that they are not started/stopped on demand. Check the Useful Code and Live Encoder section over the next week for a tool that will either be called MediaCasterStreamStarter or MediaCasterStreamManager. It will give you better control when the stream is started and stopped.
You must use the rtp-live stream type. It is the only stream type that can be used to re-stream an rtsp stream. It looks like this camera is not support by Wowza Pro and Flash. Wowza Pro can only re-stream cameras that natively support H.264/AAC. Wowza Pro does not transcode the incoming stream.
You can change the starting port number. It is defined in [install-dir]/conf/Server.xml. The setting is RTP/DatagramStartingPort. I don’t think this is the problem since the port number are determined by the RTSP negotiation. But see if this helps.
It looks like it is connecting to the camera correctly but is not receiving the RTP packets over UDP. Be sure UDP ports 6970-9999 are open on your firewall and are properly flowing to the server running Wowza Media Server. Another option is to install the most recent patch from here:
Then be sure you have seen the most recent updates to the instructions which uses RTSP/RTP interleaving to enable the RTP packets to flow over the TCP connection.
I am not sure how you would do that and provide any type of decent lip sync. Wowza Media Server does not support taking an audio signal from one transport and joining it with a video signal from another transport. We expect the audio and video to be delivered to us in some type of joined transport stream (RTMP, RTSP/RTP, MPEG-TS, native RTP) where there is some kind of timecode synchronization system in place to put the audio and video in sync. You can certainly try just playing the audio and video in the player separately and see if this works well enough.
I don’t have specific info on this camera. I would be sure you can return what you buy. I have seen where a few of these cameras say they do RTSP/RTP but the RTP packet format is not one of the documented formats that we support. Specifically I have seen this with Sony cameras.
We do not support Windows Media Re-Streaming. At this time we only support H.264/AAC/MP3. It is a feature we may add in a future release of Wowza Media Server after the 2.0 release. There is no definitive timeline for this feature.
First, I would expect the url to be rtsp:// and not http://. Second, we have not had much luck with re-streaming Sony cameras. Most of them use a proprietary RTP packetization scheme that we do not support. So, first see if you can find the RTSP/RTP. Then give it a go. If you get a bunch of error messages then it may be the packetization scheme. If you have documentation that describes their RSTP/RTP format I can take a look at it to see if it contains info to determine if it will work or not (support@wowza.com).
Like I said, it is just the difference between UDP and TCP. Without interleaving the audio/video is sent over UDP which can have packet loss with interleaving it is sent over TCP. TCP requires more overhead and the encoder is responsible for dropping packets because of network congestion.