FYI I have found a problem with recent builds of VLC. Support for AAC encoding has been removed due to licensing issues.
http://mailman.videolan.org/pipermail/vlc-devel/2009-August/065277.html
http://mailman.videolan.org/pipermail/vlc-devel/2009-April/058995.html
I am using the PLF build of VLC version 1.0.4 on Mandriva 2010.0 and it sort of encodes AAC but the --sout-ffmpeg-aac-profile option now does nothing so it sounds awful. Not sure how it is still managing to encode now, I’m still working through the source trying to reverse patches, but it is definitely not as usable as it was.
It would be really nice if it was possible to send MP3 via RTP to Wowza and I could forget about AAC. I’ve cound that faac sounds worse for the same bitrate than LAME anyway.
Wowza 2.0 can accept incoming MP3 streams over RTP. It has been tested with VLC. Wowza 1.7.x does not support MP3.
Charlie
Thanks Charlie. That’s useful to know.
From your VLC command line, I can see “dst=127.0.0.1”. This would send the packets to localhost, not your Wowza server. You are running VLC on a Windows machine and the Wowza paths look like Linux, so I assume they are actually on different machines.
Try changing the destination address to be that of your Wowza server.
Great to hear it’s working for you 
I have had problems with the latest version of VLC with the motion stop-starting with live capture both on Windows and Linux builds of VLC.
It may be worth trying older version of VLC until you find one that works. They can be downloaded from here…
http://download.videolan.org/pub/videolan/vlc/
Unfortunately, VLC isn’t entirely stable yet and new versions tend to break as many things as they fix. I still struggle with it because it can encode different bitrates at once and it runs on Linux, unlike Adobe’s encoder.
Another issue with later versions of VLC is that the audio AAC (FAAC) encoding library has been dropped due to licensing issues. If you are using Wowza 2.x then you may find you get better results changing from MP4A to MP3.
Ah, good point
vlc -vvv http://url/url/.asx --sout "#transcode{venc=x264,vcodec=x264,vb=500,scale=1,acodec=mp4a,ab=32,channels=2,samplerate=22100}:rtp{dst=172.16.0.15,sdp=file://172.16.0.15/c$/vlc.sdp}"
Like I said, I’m new :S
Also, is there a way to just get wowza to stream http://url/file.asx without the VLC stage?
Sorry, I meant http://url/file.asx
I have changed it from the real URL as it’s a test url for my boss’ company so I don’t want to post it. I have tried opening it in VLC and it works fine.
I’ve read that transcoding to flv is a bit hit and miss in VLC. Would I be better off doing it to h.264?
Excellent! you were right. It’s all working now thank you.
Hi,
Is it possible to use VLC to encode on a computer with an Osprey 530 card and then stream it to rtmp://ipaddress/app and streamname like you would with Flash Media Encoder? I’m trying to use H.264 and FME seems to be rubbish at it.
Or, if you have any other suggestions then please let me know
Thanks in advance
Andrew.
Hi,
just new here, but I can confirm that this all works. I have VLC transcoding my tv signal from a Dreambox to a H264 video and MP4A audio rtsp stream. And that is than pickuped by wowza with the rptlive application.
Had the same problem with generatin the sdp file. So the http://.. option did do the trick!
And now I can watch my tv in H264 with flash… which is quite nice 
TheYOSH
Hi,
We’ve been evaluating FME/FMS and for our requeriments (rtp stream as source) now we’re moving to this solution. For us, it works well (only with an not desirable long delay). The onlye problem is that we need to add metadata in the rtmp stream. Before, we setted the metadata info (author, etc.) from FME side easily, but now we don’t know how to set this in the server side (we assume that in this case, VLC is out of the solution).
How we can configure the rtplive stream setted from the vlc source to add this static metadata?
Pd. We use metadata to detect stream presence from flash client side.
Thanks for the quick reply.
We will try to tell VLC to create the sdp file in a temporary folder, edit it and copy the modified file in the /content folder of Wowza.
We will publish the results
Hi again,
It’s seem that vlc is including some metadata elements in the generated session descriptor ( exactly, the attribute tool:vlc…) so we suppose that would enough to detect the start of the stream after the connection in the flash client side.
However, in our testings, we’ve observed that the solution it’s working with VLC versions 0.8.6d and above. We connect with vlc to a video input source (MPEG4-SP over RTP) via RTSP protocol, but newests versions of vlc doesn’t work correctly with this (the connection is suddenly closed over 30 seconds before it has been been established). So we can only use vlc 0.8.6d version as an intermediate solution.
Anyone with this issue or similar?
Hi,
First of all, you’re trying with VLC to stream via RTP from an h264 file as source (the Wowza example video file), I’ve tried similar scene but it seems that VLC cannot do it (look at the VLC forum). VLC can play h264 files but can’t transmit it via RTP. Try with diferent video encoded file (p.e. an MPEG-2 file), it should work.
Anyway, the purpose of this thread is to retransmit an encoded h264/AAC stream via RTP from VLC to Wowza. Yoy can directly stream an h264 file with default stream of Wowza (see simplevideostreaming example).
@charlie
I tested new 0.9.6 version of VLC. The problem of ‘hole’->drop seems to be resolved and the data flow to Wowza doesn’t stop but I observed that this release it’s quite stable, has a notable increase of cpu power consumption compares to previous version I was testing (0.8.6d) and the new libraries for AAC encoding doesn’t works fine yet. So it’s still not a solution.
@rogerlittin
Try to capture network traffic between VLC and your camera during the RTSP negotiation process. I had a similar problem cause my source doesn’t inform VLC that support GET_PARAMETER method in the OPTIONS reply, and VLC uses it periodically after the session is established to demand the source to keep the session active. I modified vlc source code to send anyway this message periodically (old version of VLC do that and works fine with this source, and the source really supports this feature). You can try directly with an older version of VLC (0.8.6d i.e.). Apart the issue I describe above, it works almost fine.
So I have VLC Almost working, but not quite.
Using this command:
vlc -vvv /usr/local/WowzaMediaServerPro/content/Extremists.flv --sout "#transcode{venc=x264,vcodec=x264,vb=500,scale=1,acodec=mp4a,ab=32,channels=2,samplerate=22100}:rtp{dst=127.0.0.1,sdp=file:///usr/local/WowzaMediaServerPro/content/myStream.sdp}"
It looks like it’s working well, then I get a bunch of these:
[00000451] ffmpeg decoder warning: cannot decode one frame (50 bytes)
[00000451] ffmpeg decoder warning: cannot decode one frame (50 bytes)
Then it does some more stuff, like output the sdp to the terminal window, then I get these:
[00000450] access_output_udp private warning: send error: Connection refused
[00000454] access_output_udp private warning: send error: Connection refused
[00000454] access_output_udp private warning: send error: Connection refused
and occasionally one of these:
[00000327] stream_out_transcode private debug: late picture skipped (6993)
until I abort the program.
So, why would the server be refusing the connection? I can connect and generate a stream find from Quicktime broadcaster on my mac, but streaming from VLC seems to be causing problems.
It doesn’t, I tried that first.
So I just tried again with the real IP address, just for kicks, and it seems to output more “late picture skipped” than with 127.0.0.1.
Do you know if it’s possible to duplicate the Unicast (Announce) method that Quicktime Broadcaster uses?
I got it working. It turns out that I didn’t have write permission for the content folder, and the server doesn’t accept connections unless someone’s actually trying to view the media, so VLC outputs a “connection refused” message.
Finally i can stream live video with VLC 0.9.9 to wowza in h264 and play in nativeRTP player.
There is no bug in VLC > 0.9, that is a linux distribution restricition (ffmpeg codecs). There is a way how to download codecs to make h264 video working.
I was wondering if I can play this video in other player (non web based). Can I somehow play RTP video from wowza?
we made HD live rtp stream with vlc 0.9.9 with H264. it works on 4 core CPU quite well but sometimes with broken elements.
wowza gave us errors after while but streaming was working - do you want to send these errors messages?
is here anybody who want to try and test linux hd live streaming?
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.
Charlie