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

#44

I was wondering if it might ever be possible for a combination of RTSP and Native RTP modes. In other words I would like to be able to ANNOUNCE the sdp file from a random outside location (webcaster on the move) but only go as far as to store the xxx.sdp file in the content folder on the WMS. Next I would like a client to be able to request the Stream by xxx.sdp name, but rather than expecting the stream to be on its way already as part of the ANNOUNCE, I would like for WMS to retrieve the Stream via RTSP once requested, or using a MediaCaster on a timer loop that can start the stream when the xxx.sdp file arrives or check until it succeeds.

The benefit I am trying to gain from this goofy hybrid mode is to allow the Stream to be initiated from the outside by the webcaster encoder, but I want to have the stream data interleaved over TCP for firewall and packet loss issues, and the only way it seems that I can make that happen is when the WMS initiates the connection and I have interleavedTCP set to true in my Application.xml file.

It works fine when I use normal RTSP mode, but I am worried that this will not be a workable solution in our webcasting world as the Remote WMS would need hands on configuration for each external location and all activity would have to be started from thereā€¦ this might be too difficult for our more ā€œsimpleā€ customers.

To be perfectly clear it is not a WMS limitation why I cannot initiate Interleaved data from the encoder side, it is an encoder limitation because it is based on a spoofed connectionā€¦ I was only hoping that I might be able to get a work around from the Wowza side, because you guys seem to be able to make everything else work without too much trouble.

thanks

-Pat

#45

Hello,

Iā€™m following the instruction ā€œHow to publish and play a live stream (native RTP encoder with SDP file)ā€ in the quickstart.html. The Adobe Flash player plays fine on both local PC with WowzaMediaServer and remote PC.

But, on the local PC, the VLC canā€™t play the stream by opening: rtsp://localhost:1945/rtplive/myStream-osprey240e.sdp

The VLC complained:

Your input canā€™t be opened:

VLC is unable to open the MRL ā€˜rtsp://localhost:1945/rtplive/myStream-osprey240e.sdpā€™. Check the log for details.

The myStream-osprey240e.sdp is generated by a RTP broadcaster that broadcasts H.264 and AAC video/audio streams. The content is:

v=0

o=RTSPStreaming_pack_v.2.3.0.6 3475421789 0 IN IP4 38.113.166.154

s=vsofts

c=IN IP4 72.172.164.152/30

a=x-broadcastcontrol:RTSP

a=control:*

m=video 1945 RTP/AVP 36

a=rtpmap:36 H264/90000

a=control:trackID=1

a=cliprect:0,0,320,240

a=framesize:36 320-240

b=AS:250

a=fmtp:36 packetization-mode=1;profile-level-id=42801E;sprop-parameter-sets=J0LgHpZUCg/QgAATiAAEkrRC,KM4GDMg=

There should be no UDP and Firewall issues because the VLC is on the same machine of WMS. I canā€™t figure it out whatā€™s going wrong. And I will test if the MPET-TS works with VLC.

Thanks

#46

Thanks Charlie,

Yes itā€™s None

#47

Thanks Charlie. rtsp://localhost:1935/rtplive/myStream-osprey240e.sdp works well. I misunderstood this 1935 port with the port No. in SDP file.:frowning:

Ā© 2007ā€“2024 Wowza Media Systemsā„¢, LLC. All rights reserved. ā€ƒ Security & Privacy PolicyLegalSystem Status