Wowza Community

problem with VLC "late buffer for mux input"

I have Sony IP Camera which has h264 video codec and G.711 or G.726 for audio. Playing only video (without transcoding) in flowplayer works perfectly. I followed this tutorial How to re-stream video from an IP camera (RTSP/RTP re-streaming)

Wowza can’t transcode G.711 od G.726 to AAC needed for Flash player so I had to use use VLC to transcode the audo.

This is how I’m running vlc

vlc -vvv "rtsp://192.168.0.10/media/video1" --intf dummy --sout "#transcode{acodec=mp4a,ab=30,channels=1,samplerate=48000}:rtp{dst=127.0.0.1,port=10000,mux=ts}"

And then play it according to instructions in How to publish and play a live stream (MPEG-TS based encoder)

Audio works almost fine but the screen stops all the time. I get errors on Wowza and VLC console. However when I play the rtsp directly form the camera VLC works fine(audio and video) also recording to file works.

[0x833d044] main mux warning: late buffer for mux input (4990325)
[0x833d044] mux_ts mux warning: packet with too strange dts (dts=74317756051,old=74317768265,pcr=74317768265)

And Wowza shows smth like this

WARN server comment - RTPPacket.write: Bad packet: Incomplete NAL Units.

I use VLC version 1.1.8 The Luggage on Ubuntu LTS 10.04 server.

Maybe there should be some other options for VLC?

Is there some other transcoder I could try?

Take a look at this guide:

https://www.wowza.com/docs/troubleshoot-live-streaming

Richard

I am using VLC 1.1.5.

The ModuleMediaCasterStreamMonitorAdvanced by be useful:

https://www.wowza.com/docs/how-to-enable-advanced-monitoring-and-resetting-of-mediacaster-streams)

Richard

Why 5544? The default rtsp port is 554.

Richard

Hello p4trykx,

I ran into the exact same problem as you trying to play the sample.mp4 using VLC 1.1.4 on Kubuntu 10.10. I was able to get it working by using the VLC GUI to stream, using both HTTP and RTSP. I then copied part of the string that VLC provides and used that to create a stream on the command line like this:

cvlc -vvv sample.mp4 --sout “#transcode{vcodec=h264,vb=0,scale=0}:rtp{sdp=rtsp://:5544/mystream}”

Which I can then play in VLC using:

rtsp://localhost:5544/mystream

It appears that recent Debian based OSs are not able to use that VLC command mentioned in the VLC with Wowza Server (native-RTP) Guide So, there must be something in that VLC command that is breaking it. I don’t know what it is.

I compiled ffmpeg and the AAC codec from the latest git sources.

I also tried looking up the error “late buffer for mux input” on google where I found suggestions for various methods of “increasing the buffer size” in VLC. But those solutions did not solve the problem. It’s got to be something else in those VLC command line options.

Yeah, the forums inserted a space there for some reason.

You really can’t play the stream like I posted by running the VLC gui, choosing open network stream, and entering: “rtsp://localhost:5544/mystream”? (without the quotes)

Works for me:

@Richard “why 5544?”

That’s just what VLC 1.14 defaults to in the gui when you make an rtsp stream.

@p4trykx Do you get any errors when you run the cvlc command? Maybe codec related errors? VLC uses ffmpeg. Did you compile ffmpeg from scratch or did you just use apt? I think in Ubuntu 10.x you have to compile it from scratch to use AAC and MP3 codecs.

Maybe you will gain some insight if you play around with creating a stream using the VLC GUI. Try HTTP. For example:

  1. Do Advanced File Open -> add the sample.mp4 -> in the “Play” drop down box choose “Stream”

  2. Click Next

  3. Under Destinations, check “display locally” then choose “HTTP” in the drop down box. Click Add.

  4. Put “/mystream” for the path.

  5. Click Stream.

You should see that it’s working/streaming since you clicked “display locally”.

Open a new instance of VLC.

  1. Do Media -> Open Network Stream

  2. Enter "http://localhost:8080/mystream

You should see the HTTP stream in the new VLC instance. Play with different protocols, and you may be able to come up with a CLI command that will allow you to transcode to Wowza. Let’s get to the bottom of this.

I had success following the How to play a live stream (mpegts) how-to.

Using the following vlc command line:

cvlc -vvv sample.mp4 --sout “#transcode{venc=x264{keyint=30},vcodec=h264,vb=0,scale=0.5}:rtp{dst=127.0.0.1,port=10000,mux=ts}”

Plays just fine in [Wowza]/examples/LiveVideoStreaming/client/live.html using:

Server: rtmp://localhost/live

Stream: mpegts.stream

Note: using “acodec=mp4a” in the vlc command line gave nothing but problems. Lots of “late buffer” errors, and very choppy audio when it did play.

FYI, I’ve been able to figure out that the VLC error “late buffer for mux input” is computational/CPU related.

Doing a VLC transcode can saturate a whole processor on my 2Ghz dual core. The vlc console output will be fine, until I try to do other things that use up CPU resources. Such as, running Wowza, a web browser, a game, etc… VLC can’t keep up so it starts skipping frames and you get VLC errors like this:

[0x8eb79dc] stream_out_transcode stream out debug: late picture skipped (4033)

[0x8eb6b14] main mux warning: late buffer for mux input (495973)

And you’ll get errors in the Wowza console like this:

WARN server comment - RTPDePacketizerMPEGTS.handleRTPPacket: Out of sync: 0x80

Then when you play the Wowza stream in your flash player you’ll get problems like jittering, skipping frames.

All of these problems are related to pushing the computer beyond it’s performance capabilities. Ways to mitigate these issues would be:

  1. Faster CPUs.

  2. Less processor intensive transcoding. 60% CPU usage seems to work fine. 90%-100%+ exhibits problems.

  3. Eliminate unnecessary processes from your server, such as not using a GUI.

  4. Set CPU affinity to bind your transcode operations to certain CPUs, and other processes to other CPUs.

I looked at that guide but those changes (MPEG-TS/RTP UDP Packet Loss Remedies) doesn’t have any effect.

I think that it is unlikely to have packets loses form VLC to Wowza when they are running on the same machine. The CPU load is about 10% for Wowza and 1-5 % for VLC (just transcoding audio)

I also tried to play sample.mp4 from Wowza/content/ through VLC to rule out packet loss form the camera. But the I get errors form VLC

[0xa472d0] main mux warning: late buffer for mux input (1342960)

I use the exact same command as in the VLC guide

vlc -vvv "sample.mp4" --sout "#transcode{venc=x264{keyint=60,profile=baseline,level=3.0,nocabac},vcodec=x264,vb=150,scale=0.5,acodec=mp4a,ab=96,channels=2,samplerate=48000}:rtp{dst=127.0.0.1,port=10000,mux=ts}"

Is there any particular version of VLC that is stable and You have tested with Wowza?

Or could you recommend some other software instead of VLC that I could try.

I noticed that newer VLCs need to have “–intf dummy” parameter if running without GUI.

The command you gave me does not work. However if I delete the space between “rtsp ://” vlc starts but I can’t connect to it with another VLC.

I also tried all sorts of cache parameters

--rtsp-caching=2600 \
--gnutls-cache-size=30000 \
--udp-caching=3000 \
--sout-mux-caching=5000 \
--http-caching=30000

The video stream which goes directly form IP camera to Wowza plays OK all the time.

Maybe there is some performance issue. When I run it at night when the load is low video+audio plays smoothly.

However I’m just transcoding audio which takes about 1% of CPU time. Another explanation is that the h264 codec in the camera works better with more dark video input. I really can’t understand that.

It seems like VLC cant play it’s own output :confused:

The 5544 TCP port is open and the CPU usage is high so the first command works.

Which version of VLC do you have?

open of `rtsp://localhost:5544/mystream' failed: (null)
main debug: thread ended
main debug: dead input
main debug: changing item without a request (current 1/2)
main debug: nothing to play
qt4 debug: IM: Deleting the input

I tried 5544 and 554 and both of them does not work.