VLC transcoding - bitrate peaks [hard bitrate limit?]

[woj]

Hi,

I am using VLC with following options:

vlc -vv v4l:/dev/video0:adev=/dev/dsp:channel=0:norm=auto:size=720x576 --sout #transcode{vcodec=mp4v,acodec=mpga,vb=3000,ab=128,scale=1,enc=ffmpeg{keyint=80,hurry-up,vt=256},deinterlace}:std{access=udp,mux=ts,dst=239.255.1.1:1234} --ttl 13 -I dumy --daemon

As You can see I'm encoding analog input. It is very important to me to not exceed 400Mbit of multicast output. But vlc is generating peaks from time to time (>5Mbit). This is not a CPU issue (usage is normal). How can I hard-shape output traffic? I tried to play with vt= option, but it did not help.

Any suggestions?

[woj]

As You can see I'm encoding analog input. It is very important to me to not exceed 400Mbit of multicast output.

I ment 4Mbit of course


regards

[woj]

Huh, it is not cool, that there is no answer for this problem. Maybe I can give You some extra information...

1. I noticed, that peak problem is connected to dynamic screen changes. I think that encoder tries to keep fps and quality, that why there is a peak.
Peak are not very often, I can notice them at decoder as disorder on screen (squares on picture, wheeze sound). Also, peaks are very short, but annoying.

2. Cpu usage is always at the same level - 30-40%. It's P4 2.8Ghz with 512MB RAM, and it is only doing encoding. System is Debian Unstable, vlc 0.9.0-svn (deb build), but the same problem was on 0.85 series.).

3. Regarding documentation there are two possibilities:

venc=ffmpeg allows to set the encoder to use, where:
*keyint=80 is the maximal amount of frames between two key frames
*hurry-up allows the encoder to decrease the quality of the stream if the CPU can't keep up with the encoding rate
*vt=800000 is the tolerance in kbit/s for the bitrate of the outputted video

--> I tried it, it does not help.
or

bitrate=3000000 is the average bitrate of the stream ,
maxbitrate=4000000 is the maximum bitrate of the stream

-->but I think this works only for hardware encoding cards...


Please help. This is simple video IN stream, from analog source, and I just can't keep it stable, I fought, that vb parameter is enough... I have only 4Mbit upload, so when the peak is happens there is disaster at decoding site.

[woj]

One more thing

4. I have rrd graphs from this server, basically the output is always at correct (fixed level) - 3 - 3.5Mbit. I was monitoring VLC encoder with iftop tool (it shows traffic to some src) and the peaks are sometimes at 8-9Mbits. - because this is only 4Mbit link, You can imagine what is happening.

[woj]

5. When vlc is restarted at the moment of peak, everything goes back to normal.

6. I think (I am not sure yet) - the peaks occur more often, if VLC process is working for a long time (couple of hours). At fresh vlc process problem is not so frequent....

7. there is no info about stream peaks in vlc.log (-vvv)

[woj]

LOL - only my replies in topic

I did some reading and started to play with ffmpeg tweak options:
vlc -p ffmpeg --advanced --help-verbose

here are topics created by people with similar problem:

viewtopic.php?t=19240&highlight=variable+bitrate+codec
viewtopic.php?t=9295&highlight=strictrc
viewtopic.php?t=27079&highlight=bitrate+transcode
viewtopic.php?t=18147&highlight=strictrc
etc..

As we can see problem is not so trivial.

I will let know at forum if there is a solution, but mybe someone got one?

[ssm]

I'm experiencing same problem as you are - I've tried everything.

I belive there must be a bug in the VLC. When I stream same file directly without transcoding it works without any problem.

Hopefully someone will find a solution fast.

[redsox_mark]

I just posted to one of the other threads mentioned in this one.
This is still a problem in the latest version. It is only a problem with low bitrates. Select a bitrate of 2048 and that's more or less what you get. Select 1024 and you get that. But select anything under 1024, and I get more or less the same as 1024. Even if I select 16k as the rate, I get a real rate of about 1000k. That can't be VBR not being strict enough (and I've tried the strict option).

I've found many posts raising this problem. Most of the replies say "that's the way VBR works". Now I know how VBR works and that it is a target rate...but with a target of 16k I should not be getting 1000k!

[mrLenin]

Hah, I am disappointed in VLC

[redsox_mark]

I posted some followps to this issue on this thread
viewtopic.php?t=19240

I switched to using Microsoft Media Encoder and that worked perfectly.

[mrLenin]

Dees it have many advantages in compare?

[redsox_mark]

For me it had a big advantage, as I could not get VLC to encode at a low enough bitrate.

What I was doing was streaming some live TV from one PC to another over the internet, using DSL. This meant I was limited by the DSL upload speed (which is around 400 kbps). We needed software which could:

- capture from the TV card
- encode to a low enough bitrate (< 400kbps) on the fly
- stream this over the internet

On paper VLC should be able to do this, but as my post in the referenced thread detail, it would not encode at a rate < approx 1000k, no matter what the setting. Because the bitrate was too high this didn't work. In fact VLC (on the receving end) would just freeze up.

With Windows Media Encoder, when we select a rate of 340k (for example), that is what we get, and it worked perfectly.

Again it may be that there is some setting I missed - it may be possible to get VLC to do low bitrate encoding. But I couldn't get it to work. With Windows Media Encoder it worked first time.

Mark

[mrLenin]

Oh, thanks a lot. Gonna test it soon!