Wowza Logo Wowza Icon
Wowza Video Sign Out
Talk to an Expert Free Trial
Wowza Video Sign Out

Wowza Community

Using a native RTP encoder with Wowza Pro (native RTP)

Wowza Streaming Engine
#24

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

#25

Right, as I understand it, you could put h.264 encoded video into a flv container, but it is not best practice.

Richard

#26

It might help to set up the MediaCasterStreamManager app to start and stop streams.

Richard

#27

Use the “file” Flashvar in the html container:

Flashvars = “&file=http://yourdomain.com/myStream.sdp&streamer=rtmp://ip/app&provider=rtmp”;

Richard

#28

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!

#29

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,

#30

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.

#31

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. :frowning: Why would this be?

#32

How can it connect when Wowza isn’t even listening for it on the appropriate UDP port? Wireshark tells me that it is indeed sending the RTP data to that UDP port.

#33

Charlie,

I’m doing something similar and would like Wowza to start up and listen to a fixed unicast RTP stream from an encoder that cannot support RTSP. Can you point me at an example SDP file? Also, can Wowza support multicast?

Thanks a bunch!

Frobnoz

#34

Hi,

I’m sending IPP encoded H264 frames using RTP packets over UDP.

I try to play the stream on a Flash player with no buffering in “live” mode using SDP file through Wowza Media Server Pro 1.7.0 (the free version) with the “rtp-live-lowlatency” application in a 1GB Intranet.

I use a high performance computer for encoding and Wowza server is installed on a different server but they are both connected through a switch so the RTP transportation is not an issue.

I changed the Wowza configuration and tuned it up according to other posts here but i can’t seem to do better than 2-3 seconds of video latency.

(MaximumSetBufferTime is set to 0).

Is there any more buffering done on the server?

Is there a fixed latency on the free version?

Does anyone have any Idea how to drop this latency?

Thanks, Yoel

#35

Why is it called “rtp-live” if 2-3 seconds is normal?

how can you transfer real-time video with this kind of a delay?

Does chat has less latency?

I need REAL real-time video, any suggestions?

#36

Thanks for the quick replies.

As far as I know, flv is just a file format which (most of the times) encapsulates video encoded in h.264 and aac encoded audio. We don’t use audio and just transmit the video.

I don’t want to write it down to a file, i want to transmit it on-the-fly.

The whole encoder-server-client circle here is executed in 1GB Intranet, the network latency shouldn’t be noticeable.

How come file transmitting is faster than RTP push transmitting? Don’t i save the IO time?

Yoel.

#37

Hi.

I’m looking to do the following:

  1. Create and remove SDP files remotely (without writing them in local folder, for remote machines support).

  2. Refresh the SDP file contents, in case the source machine changes (both IP and RTP port).

I read above that Wowza 2 can support the 1st requirement via HTTPProvider, but is it supported in 1.7.2 version?

Also, how it’s possible to achieve the 2nd requirement, is there any command which can cause Wowza to re-read the SDP? Or it should just wait for time-out, then it will re-read the SDP by itself?

Thanks in advance.

#38

Hi.

Thanks for the advice - both of these are supported in 1.7.2 as well, correct?

Also, when reading the configuration file, I found the following setting:

sdpHTTPCheckFreqency

It’s explained that this setting will control how often Wowza would re-read the SDP returned via HTTP.

Does it mean Wowza support remote SDP retrieval, instead of reading it from the local file system? If yes, how it can be used?

Thanks again.

#39

Hi.

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

How exactly I specify this SDP? If I’m using JW Player, which parameter I should add for it?

Thanks.

#40

Hi.

Thanks for the example, will try it.

Is there any sense to use rtp-live-lowlatency? Or it only targeted to Sparks video conference?

#41

I have a video application that uses a custom encoder to encode video to H.264. The encoder can be configured to stream the video over RTP to an IP address. Normally I configure the encoder to stream it locally.

I am able to play the video in VLC and GStreamer using the SDP file generated by the encoder. While trying to access the stream with Wowza (installed on the same machine as the encoder) I get a java.net.BindException stating that the address is in use.

INFO server comment - RTPSessionDescriptionDataProviderBasic.getStreamInfo: /usr/local/WowzaMediaServerPro/content/streams/stream1.sdp

DEBUG server comment - cmd: setBufferTime

DEBUG server comment - sdp: v=0

DEBUG server comment - sdp: o=- 0 0 IN IP4 10.99.50.91

DEBUG server comment - sdp: s=RTP_H264_0

DEBUG server comment - sdp: c=IN IP4 0.0.0.0

DEBUG server comment - sdp: t=0 0

DEBUG server comment - sdp: m=video 8000 RTP/AVP 97

DEBUG session setbuffertime [114845166,1]: 750 750

DEBUG server comment - sdp: a=rtpmap:97 H264/90000

DEBUG server comment - sdp: a=fmtp:97 packetization-mode=0;profile-level-id=420033;sprop-parameter-sets=Z0IAM7kQFAX0IAAAfQAADqYQgA==,aM48gA==

INFO server comment - sortPackets[2]: sortBufferSize:500

DEBUG server comment - onFlushNotifyClients: true

DEBUG server comment - flushInterval: 50

DEBUG server comment - verboseDebug: false

INFO stream create - -

INFO stream create - -

DEBUG server comment - RTPDePacketizerRFC3984H264.init

INFO stream publish stream1.sdp -

INFO server comment - UDPTransport.bind: 0.0.0.0/0.0.0.0:8000

INFO server comment - UDPTransport.bind: 0.0.0.0/0.0.0.0:8001

ERROR server comment - RTPUDPListener.init: java.net.BindException: Address already in use

INFO server comment - UDPTransport.unbind: 0.0.0.0/0.0.0.0:8000

INFO server comment - RTPMediaCaster.Reconnector: stop

ERROR server comment - RTPUDPListener.init: java.net.BindException: Address already in use

INFO server comment - UDPTransport.unbind: 0.0.0.0/0.0.0.0:8001

I have found that if the encoder is configured to send the RTP stream to a different machine and I run Wowza on that machine, then I am able to play the video without any issues.

I have followed the NativeRTPVideoStreaming example, setting the stream type to rtp-live or rtp-live-lowlatency (i get the same error in either case).

Is there any other configuration needed to read an RTP stream?

#42

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

Charlie,

I tried your suggestion but it did not work - Wowza gives the same error. Is there anything else that I can do to debug this issue?

#43

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

Charlie,

You were right - the encoder was binding to the same port. We have modified the encoder and now Wowza is able to restream it. Thanks for the help.

© 2007–2024 Wowza Media Systems™, LLC. All rights reserved.   Security & Privacy PolicyLegalSystem Status