[Ffmpeg-devel] size of encoded file not continous parameter of 'vqscale'
Fri Jun 9 15:00:23 CEST 2006
Darko Veberic wrote:
> Stefan Gehrer wrote:
>> Darko Veberic wrote:
>>> i am usually encoding video with the following mencoder options:
>>> -lavcopts vcodec=mpeg4:vqscale=$vq:vhq:v4mv:trell:autoaspect:threads=4
>>> i have observed strange non-continuous behavior of the resulting file
>>> size with respect to the vbr quality parameter $vq.
>>> for example, the file size for vq=4.49 is 911M and for vq=792M (while
>>> keeping the audio settings constant). i have noticed the jumps occur
>>> around the x.5 values for the vbr quality... in such cases it is almost
>>> impossible to get the file size right (ie, close to 700M)...
>>> is this a bug (or a feature) ?
>> vqscale in MPEG4 is whole numbers only (2-31 I believe), and unfortunately
>> the range of reasonable quality encodes is in the range somewhere like 2
>> to 6.
>> So a step from one vqscale to the next has a huge impact on both quality
>> file size. If you need to hit a certain file size, do not use vqscale
>> but instead
>> make use of rate control.
>> Stefan Gehrer
> on the contrary, the vqscale is a floating point number (reported by
> mencoder with 6 decimal places). i am attaching a plot of file size vs
> vqscale value for some small movie chunk. as you can clearly see, the
> file size is a nice and continuous function of vqscale except around x.5
> points where you get large jumps.
Okay, I rephrase a little: you can specify a floating point number as
but the major influence on file size is the quantizer of the MPEG4
is a whole number and accounts for the steps. Other decisions during the
process seem to honor the fractional part of vqscale, hence the nice
slopes in between.
> if this jump is occuring around 700M
> we are unable to tweak the file size to match the cd size unless
> satisfied with substantially smaller size...
As I said, the solution is to use rate control, which chooses a
quantizer for each frame.
More information about the ffmpeg-devel