buffer size 25000 in ripbot

[miss]

hi

in ripbot I would like to know what that means buffer 25000

tanks

[poisondeathray]

it's the maximum size for the VBV buffer

eg. so if you set the default:
-vbv-bufsize 25000 --vbv-maxrate 25000
this would mean 1sec of a 25000kbps peak

[miss]

vbv buffer ?

[poisondeathray]

yes , it's needed for buffered device playback. Overflows and underflows can cause skipping or stop playback

For pc playback, not necessarily required

[miss]

it s the max bitrate for the video ?

ex

10000 -25000

= variable bitrate ?

25000 = kbs max ?

[poisondeathray]

it s the max bitrate for the video ?

No it is not the local instantaneous max bitrate

It's the max buffer size

Think of it as a safety pool of already decoded data. If you have bitrate peaks (spikes) that exceed that buffered pool, you have a buffer underflow (the buffer supply will be exhausted), and playback will stop. It buffers the instantaneous input/output data rates, so playback will be smooth

This is only required for devices that need it (e.g. media players like popcorn hour, wdtv, psp, iphone , blu-ray players, etc..)

[ronnylov]

I also have some problems understanding this.
So the -vbv-bufsize is the size of the buffer in bits?
And --vbv-maxrate is maximum rate in bits/s that the buffer can be filled with (like the bandwidth from the storage medium)?

So the stream is read into the buffer as fast as possible but the decoder may drain the buffer with a temporarily higher speed (at a bitrate peak). This would not cause any playback problem as long as the peak bitrate of the stream is short enough to not drain the buffer completely and then the buffer can be filled again when the decoder drain the buffer with a lower rate than the filling rate? So here the buffer size makes a difference, it depends how much data is preloaded in the buffer before playback starts.

So by setting these values to something that corresponds to a real situation, perhaps reading the stream from a DVD disc with a limited reading speed you can actually have bitrate peaks above the DVD reading speed as long as the buffer is not drained completely. The storage medium is read in advance to fill the buffer before the actual playback takes place. The limits set by the encoder would then be kept within the set values to make everything work with this playback device.

Now the problem is to find values that correspond to the real playback device. Personally I am doing some encodings that will be streamed over internet (progressively played) with a maximum connection bandwidth of 1500 kbit/s. Considering audio bitrate of 128 kbit/s and some muxing overhead I can set the vbv_maxrate to maybe 1350 kbit/s. But how can I determine the buffer size of the adobe flash player? I know it does not buffer the complete file before playback starts but there seems be no limit of the buffer size (because it can preload the complete file if I press pause). I want to avoid buffering pauses of the playback. Of cource there may be internet congestion but I want to encode it to make it work when there is a good connection to the server. It is not fun if the video always will start buffering even when you have a good connection...

Maybe one way to test the buffer size would be taking a stopwatch and measure the time from pressing play until it actually starts the playback. taking the bitrate of the medium as a parameter you know the maximum buffer size they use. But there may be other delays before the buffer actually starts to fill. I guess some experimenting with different values can determine something usable...

[poisondeathray]

That's a good clarification of what's going on ronnylov; if you want more info, read through this thread, especially towards the end:
http://forum.doom9.org/showthread.php?t=146182

Over a period of time T, if the buffer starts empty and ends full, you'll have encoded bufsize + T * maxrate bits. That gives the formula for max bitrate over the period T : (bufsize + T * maxrate) / T, ie maxrate + bufsize / T. If we define buf_duration by bufsize / maxrate, then we have max bitrate over T = maxrate * (1 + buf_duration / T). So the max bitrate over a period that lasts the VBV duration is double the maxrate.

A VBV can become empty if locally the bitrate is low enough for a long enough time. It can become full if the bitrate is high enough for a long enough time. And the formula I gave to compute the maximum bitrate over a period T is correct. Basically, it says the shorter T is (in comparison to the VBV duration), the larger the maximum bitrate (over T) can be. And the longer T is, the closer to the VBV maxrate the maximum bitrate will be.

The vbv buffer doesn't play a large role when you use progressive http download; it can when you use true rtsp streaming. I suspect you are using the former

Usually either the internet connection (up or down), or the overhead from being fed through the flash interface is the bottleneck and the buffer doesn't help. The Flash 10 is very poorly multithreaded, this is usually the bottleneck. So videos that play well locally (they are 100% downloaded), often choke when fed through flash, and the buffer doesn't seem help

For progressive http download, you can set a server side delay before initial playback. In this case the preload is the buffer (i.e the amount downloaded to your temp internet directory) , but this only helps if bandwith was the bottleneck. If the client CPU is too slow, it still won't help much

You can do your VBV tests locally in the absense of bandwith limitations confounding the testing; just make sure you set up an html page, and play it locally through the flash interface. (essentially, the entire file has been "downloaded", you are testing the flash player)