Wowza Community

Using VLC with Wowza Pro (native RTP)

The stream cannot start until it hits a key frame. So that is most likely the cause of the long delay. It is waiting for a key frame. See if there is a way in VLC in increase the key frame interval.

Second, the rtp-live system is a pull based on demand method. So the stream is not started util the first client connects. It then remains running until the last client disconnects then it waits 10 seconds for additional connections and shuts down if no connections are made. So this long delay start will only occur for the first viewer of the stream.

We do have a module to allow you to control when the stream starts/stops. Take a look at this package:


Yes, the player also needs a key frame. So if the key frame interval is huge then it is going to be a problem. VLC is not a great choice. I would find your self a better encoder.


Then try the following. Install the most recent patch:

This improves UDP performance and adds a few RTP features.

Set the key frame interval to 2 seconds (keyint=2,idrint=2). See if this improves the startup time. Test both the initial connection startup time as well as the second connection startup time. Use our example player (examples/LiveVideoStreaming).

If this does not improve the startup time then turn on debug logging and send me the debug logs files (


Basicall this:

vlc -vvv -I rc dshow:// :dshow-adev="Logitech Mic (Notebooks Pro)" --sout "#transcode{acodec=mp4a,ab=32,channels=2,samplerate=22050}:rtp{dst=,sdp=file://%WMSCONFIG_HOME%/content/vlc.sdp}"

Of course different devices but that is basically it.


You can see if it is a transport issue by turning on a jitter buffer and logging packet loss. See this forum post:

You will see log statements if there are holes in the packet delivery.


You certainly can set the ttl in vlc. Not sure how to do it. I have seen the “packet sent too late” messages as well. Not sure what this means. It has never caused any problems for me on the playback side.


That might help. I would suggest between 2-5 seconds of buffer. Are you seeing packet loss? This can also lead to buffering issues.


If you are seeing packet loss on a local lan this is usually some kind of hardware issue (router, firewall, switch, network card). There are really not magic software bullets for fixing this. I might try to see if you can figure out where the packets are being dropped.


My understanding is that H.264 encoding has been broken in VLC for quite some time. The most recent version that works is 0.8.6i. You will see in one of the Notes paragraphs in the first post of this thread it points you to the most recent version that works. This feature has been broken in VLC for quite some time. I think it has been over a year.


Please do send or post the error messages (


Yes, they need to be 2 different SDP files and use different ports. Yes, Wowza Media Server can handle them both at the same time.


Please post the contents of the two SDP files.


Yes, as long as all the UDP ports that are being used to send the stream from VLC to Wowza are open it should work.


I edited the first post. You will see that I now surround the file name in double quotes. This should fix this error.


I have some success with the above examples and also was able to re-size the picture using the following command line, as an example which squeezes the video to dial-up compatible bandwidths and streams it to Wowza…

[PHP]vlc test.flv --sout ‘#transcode{width=160,height=120,venc=x264,vcodec=x264,vb=16,acodec=mp4a,ab=16,channels=1,samplerate=11025}:duplicate{dst=rtp{dst=,sdp=file:///usr/local/WowzaMediaServerPro/content/vlc.sdp}}’ vlc:quit[/PHP]

I am using a file source rather that live source (which also works), just to keep things simple for testing. I am using VLC version 0.8.6f compiled by PLF on Mandriva 2008.1.

Now I would like to send three streams at different bandwidths so that the client can choose a low, medium or high bandwidth stream. I did a test saving to files with VLC and found it was possible to run three concurrent transcodes as in the example below…

[PHP]vlc test.flv --sout ‘#duplicate{dst=“transcode{width=640,height=480,venc=x264,vcodec=x264,vb=300,acodec=mp4a,ab=128,channels=2,samplerate=44100}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst=test1.mp4}}”,dst=“transcode{width=320,height=240,venc=x264,vcodec=x264,vb=96,acodec=mp4a,ab=96,channels=2,samplerate=44100}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst=test2.mp4}}”,dst=“transcode{width=160,height=120,venc=x264,vcodec=x264,vb=16,acodec=mp4a,ab=16,channels=2,samplerate=11025}:duplicate{dst=display,dst=std{access=file,mux=mp4,dst=test3.mp4}}”}’ vlc:quit[/PHP]

Finally, I tried sending three RTP streams to the Wowza server running on the same machine. However I couldn’t view anything except once when I got a few frames of scrawl from the vlc2.sdp stream…

[PHP]vlc test.flv --sout ‘#duplicate{dst=“transcode{width=640,height=480,venc=x264,vcodec=x264,vb=300,acodec=mp4a,ab=128,channels=2,samplerate=44100}:duplicate{dst=rtp{dst=,sdp=file:///usr/local/WowzaMediaServerPro/content/vlc1.sdp}}”,dst=“transcode{width=320,height=240,venc=x264,vcodec=x264,vb=96,acodec=mp4a,ab=96,channels=2,samplerate=44100}:duplicate{dst=rtp{dst=,sdp=file:///usr/local/WowzaMediaServerPro/content/vlc2.sdp}}”,dst=“transcode{width=160,height=120,venc=x264,vcodec=x264,vb=16,acodec=mp4a,ab=16,channels=2,samplerate=11025}:duplicate{dst=rtp{dst=,sdp=file:///usr/local/WowzaMediaServerPro/content/vlc3.sdp}}”}’ vlc:quit[/PHP]

I also tried running three concurrent instances of VLC as shown below with the same result…

[PHP]vlc test.flv --sout ‘#transcode{width=160,height=120,venc=x264,vcodec=x264,vb=16,acodec=mp4a,ab=16,channels=1,samplerate=11025}:duplicate{dst=rtp{dst=,sdp=file:///usr/local/WowzaMediaServerPro/content/vlc3.sdp}}’ vlc:quit &>/dev/null &

vlc test.flv --sout ‘#transcode{width=320,height=240,venc=x264,vcodec=x264,vb=96,acodec=mp4a,ab=96,channels=2,samplerate=44100}:duplicate{dst=rtp{dst=,sdp=file:///usr/local/WowzaMediaServerPro/content/vlc2.sdp}}’ vlc:quit &>/dev/null &

vlc test.flv --sout ‘#transcode{width=640,height=480,venc=x264,vcodec=x264,vb=300,acodec=mp4a,ab=128,channels=2,samplerate=44100}:duplicate{dst=rtp{dst=,sdp=file:///usr/local/WowzaMediaServerPro/content/vlc1.sdp}}’ vlc:quit &>/dev/null &[/PHP]

CPU usage was about 60% each of two CPU cores. It didn’t seem to max out.

I have a feeling I am missing something quite fundamental about how RTP streams work and that the three streams may all be munged together as far as the Wowza server and client are concerned. If this is the case then how do I separate the streams so that they play correctly?


I am new to flash video servers but I need to learn quick! (isn’t that always the way?)

I want to try a test setup where VLC streams a web stream to the wowza server and then I view this in a flash player. I know it’s more complicated than it needs to be but I’m just trying to prove the concept at the moment.

When I try the above code with the dshow code replaced with the URL VLC simply crashes (badly!) Can you offer any advice?

Forgot to mention, the VLC and wowza are on different machines. Is it possible to get wowza to retransmit a unicast stream?


Hi all,

I’m experimenting the following issue with this configuration working on linux system. The steps we’re doing:

  • Following the instructions of this thread, set an rtp-live stream in Wowza, configured with rtptimecode syncronization method.

  • Using the shell script ‘’, start Wowza (in debug mode).

  • Start the A/V transcoding process with an VLC instance. Our source is an hardware encoder that provides an MPEG4-SP video stream, optionally with a synchronized a-law encoded audio stream.

  • Using the html flash visor client provided by Wowza examples (nativertp), connect to the created rtp-live stream. We observed in wowza traces the incoming connection and how audio/video frames are been sending to the flash client:

DEBUG server comment -   FU-A: end:false tc:com.wowza.util.RolloverLong@6460029d st:false
DEBUG server comment - send[243388523]: size:29423 filter:7 time:292 tOffset:-760
DEBUG server comment - rtp[video:1101] {80 e1 61 66 ca c8 94 0f 2e 20 c7 f1 5c 41 2c 71 }
DEBUG server comment -   FU-A: end:true tc:com.wowza.util.RolloverLong@6460029d st:false
DEBUG server comment -   writePacket[vid]: sz:3969 tc:37801586:3402142735:1227005150481 key:false
DEBUG server comment - flush: notify:false tSize:1 dataObjs:201 time:40 tOffset:-37748189
DEBUG server comment - rtp[video:1450] {80 61 61 67 ca c8 a2 23 2e 20 c7 f1 5c 81 9a 58 }
DEBUG server comment -   FU-A: end:false tc:com.wowza.util.RolloverLong@6460029d st:true
DEBUG server comment - rtp[video:1450] {80 61 61 68 ca c8 a2 23 2e 20 c7 f1 5c 01 f4 11 }
DEBUG server comment -   FU-A: end:false tc:com.wowza.util.RolloverLong@6460029d st:false
DEBUG server comment - rtp[video:1450] {80 61 61 69 ca c8 a2 23 2e 20 c7 f1 5c 01 c5 7e }
  • In some cases, some seconds after the start of transcoding process, VLC launch the following error:
access_output_udp private debug: mmh, hole (1201583811163631 > 2s) -> drop

and we observed in wowza traces that seems to stop sending a/v frames, only the following messages appears with a lower frequency than the previous messages:

DEBUG server comment - send[141566447]: size:0 filter:7 time:284 tOffset:0

It seems that the error causes Wowza to stop sending a/v frames cause a lost of sync, timeline information on incorrect/not present values in incoming rtp packets from VLC. However, we test with another VLC as client and it continues managing correctly the connetion when the drop occurs (a/v is playing ok).

We’re working with version 1.5.3 of Wowza and vlc 0.8.6d version. Also try with most recent release version of Wowza (1.6) but the problem still happens. We will try with recent version of VLC (0.9.6). In VLC forums there are some persons with similar problem in VLC ( …> 2s ->drop) without help results.

Finally, we try to change the steps of the connection process. Doing the following, we reach to Wowza step over the drop error in VLC:

  • Launch Wowza.

  • Connect with a flash client to the stream/sdp. The SDP file was previosly created in other session. We observed in Wowza traces that no a/v frames are been sending to client.

  • Launch VLC. Transcoding process start. We observed in Wowza traces that is sending a/v frames to flash client but it doesn’t play nothing at all.

  • Connect with a second flash client to the same stream/sdp. It works ok.

As I mentioned, this issue only appear in linux system. We’ve tried with RHEL5 and Ubuntu Server 8.04 (32 and 64 bits versions). JVM is 1.6 from Sun.

Your help would be highly appreciated.

I am using VLC player 0.9.2 and i followed the instructions as mentioned by Charlie.

I want to stream my Webcam through VLC player on RTP. I used the following example and create the following command line

vlc -vvv -I rc dshow:// :dshow-vdev=“VIMICRO USB PC Camera (ZC0301PLH)” :dshow-adev=“SigmaTel Audio” :dshow-size=“320x240” --sout “#transcode{venc=x264{keyint=30},vcodec=x264,vb=500,scale=1,acodec=mp4a,ab=32,channels=2,samplerate=22050}:rtp{dst=,sdp=file://C:\vlc.sdp}”

But, whenever i am running VLC from commandline with above options, it starts and then shutdown abnormally.

I am using Windows XP. Tell me what to do

Please help me m stuck :frowning:

I created the directory /usr/local/WowzaMediaPro/applications/rtplive and /usr/local/WowzaMediaPro/conf/rtplive directories on my Wowza Media Server 2 installation. Then copied the Application.xml file to /usr/local/WowzaMediaPro/conf/rtplive and made all the necessary edits.

I have VLC v.1.05 running on my XP workstation. There is a Logitech webcam attached to this workstation. I am using the following command to invoke vlc:

vlc -vvv -I rc dshow:// :dshow-vdev=“USB Video Device” :dshow-adev=“USB Audio Device” :dshow-size=“320x240” --sout “#transcode{venc=x264{keyint=60,profile=baseline,level=3.0,nocabac,qpmax=36,qpmin=10,me=hex,merange=24,subme=9,qcomp=0.6},vcodec=x264,vb=500,scale=1,acodec=mp4a,ab=96,channels=2,sample=48000} :rtp{dst=,port-video=10000,port-audio=10002,sdp= file://c:\temp\myStream.sdp}”

I then copied the file c:\temp\myStream.sdp from my workstation to the /usr/local/WowzaMediaPro/content directory on my Wowza server and changed the IP address on this file so it points to my XP workstation:


o=- 14931650499380875003 14931650499380875003 IN IP4 G180-3099



c=IN IP4

t=0 0

a=tool:vlc 1.0.5




m=audio 10002 RTP/AVP 96


a=rtpmap:96 mpeg4-generic/44100/2

a=fmtp:96 streamtype=5; profile-level-id=15; mode=AAC-hbr; config=1210; SizeLength=13; IndexLength=3; IndexDeltaLength=3; Profile=1;

m=video 10000 RTP/AVP 97


a=rtpmap:97 H264/90000

a=fmtp:97 packetization-mode=1;profile-level-id=42c01e;sprop-parameter-sets=Z0LAHpJSAoP2AiAAosKgExLQAeLFyQ==,aM4yyA==;

I then connect to the webserver where I have loaded the rtplive test example code. I enter the following values where appropriate:

server: rtmp://wowzaserver/rtplive

stream: myStream.sdp

But the page shows nothing.

I tried both VLC 1.0.2 and VLC 1.0.3 with the settings in the first topic and it won’t work on the iPhone device (but it works in the simulator). It tells me “video format not supported”, when opening the link in Safari. The stream is correctly requested from Wowza.

With VLC 0.9.4 I got it working on the device, too. Has anyone experienced the same problems ? I want to switch to 1.x because the streaming quality is much better than in earlier versions.

EDIT: using VLC 1.0.1 everything is fine !