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
#21

The url should be:

rtsp://localhost:1935/rtplive/myStream-osprey240e.sdp

Not 1934.

Charlie

#22

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.

#23

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

#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?

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