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

Hi.

I tried Wowza with my custom RTP encoder, and it’s working fine for 20 seconds, and then the Flash movie begins to stutter.

I’m not sure it’s entirely Wowza issue, though using the RTP encoder with Apple server works just fine.

Therefore I have the following questions:

  1. Is anyone familiar with this symptom, where video has good start and then suddenly slows-down?

  2. Any idea how many different Live H.264 concurrent streams can Wowza server handle, provided the fact I do the encoding on other machines? Does Wowza simply repackage the RTP into RTMP, or it does other processing as well?

Thanks.

#7

New to this step - anyone help with a “push start” would be appreciated.

… From the encoder generate a Session Description Protocol (SDP) file that describes the native stream (consult your encoders documentation for instructions on how to do this) use the filename myStream.sdp

I understand to put the file in the location - also - it errors out BIG TIME if this file is not in place.

I need help building the SDP file - or - where to find documentation. Using QuickTime broadcaster - cannot locate this step.

Thanks!

#8

As I understand it, this will cause Wowza to use the SDP file info to go out and connect to another host via RTSP to try and retrieve a stream when someone connects to the rtplive application, right? Please correct me if I’m wrong.

If this is the case, is there any way to just get Wowza to open ports on the local machine to listen for incoming RTP traffic to act as a source? Then that source could be used somehow by an application?

#9

Hi, I’m evaluating Wowza for use as a RTMP/RTP+RTCP bridge in a Flash video phone application. I’d like to leverage Wowza’s RTP capabilities as much as possible.

The application has several RTP streams that come and go all the time; could I dynamically create and delete SDP files in [install-dir]/content?

The audio and video are transmitted in separate RTP streams; can Wowza mux the 2 streams into a single RTMP stream?

The bridge needs to do some lightweight video & audio transcoding, from Flash’s SVQ1 to standard H.263, and from Nellymoser Asao to uLaw or aLaw PCM. If I write the transcoders, does Wowza have hooks for plugging them in?

If there’s no better solution, I can probably cobble something together using the VideoPassthru example as a starting point; can you steer me towards a converse example that takes audio/video from an external source and publishes it as an RTMP stream?

Thanks for your advice!

David

#10

Check out this forum post which goes through the specific steps for QuickTime Broadcaster:

http://www.wowza.com/community/t/-/42

If you still want to use the other method then I believe you can generate an SDP file from the File->Export menu in QuickTime Broadcaster.

Charlie

#11

Follow these instructions and you no longer will need the .sdp file (the instructions in this forum thread are for connecting to a native RTP stream that does not use RTSP announce - QuickTime Broadcaster supports RTSP annouce - please, please follow the instructions in the first post of the thread at the URL below):

http://www.wowza.com/community/t/-/42

In the next patch I will change it so it only reports the missing file error once when using the native RTP method covered in this thread.

Charlie

#12

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

#13

Do you see the player connecting to Wowza Pro to play the stream? It sounds like the player is not connecting.

Charlie

#14

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

#15

Putting it in an FLV container will not effect the playback performance.

Charlie

#16

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

#17

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

#18

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

#19

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

#20

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

#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

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