Bitrate calculation: should I always round up the result?

[SledgeHammer_999]

I need the help of the gurus obviously.

Let's say you do your magic and calculate the video bitrate to set in the encoder taking into account various aspects of the input files and desired results. Let's also assume that you come up with a fractional number. eg 580.370531 kbit/s

x264 takes an integer value for the bitrate(and probably other encoders too). So the above number should become 580(after rounding) or 581(after rounding up)?

Why I ask this?

Consider this->http://forum.doom9.org/showthread.php?t=162740
Yesterday night I sat down and stepped through every calculation and was able to locate the mistakes I made in porting the code logic from C# to C++. Anyway, now I am able to get the same values for Bits Per Pixel and Q Estimate that Megui outputs. But for bitrate it isn't the same. megui reports 581 and I get the above number. So I assumed that it rounds up. Is this considered an ok approach?

[Makaveli84]

I'm not a video encoding "guru" by no means, but i am a programmer (field of work not even remotely close to media programming), and i can tell you that if everything u say is true, then from a pure numerical perspective, MeGUI is at fault for always rounding up rather then rounding to the nearest integer. So if MeGUI is actually calculating 580.370531 and displaying 581, i'd say it's wrong that way, and you should not be too hung up on achieving the same result.

Note that me not being a video encoding "guru", i might be wrong in favoring the "rounding to the nearest integer" approach. Maybe from some encoding perspective, rounding up is the right way, though i can't see the logic behind that.

[Atak_Snajpera]

580 kbps or 581 kbps it does not matter. most likely final bitrate after encoding will be lower than 580 kbps or higher than 581 kbps.

[Selur]

I agree the 1kbit +/- hardly does anything, precision with overhead calculation is more of a problem,... + x264 not hitting the desired bit rate, but even that is normally only a problem for higher data rates,..
as a site node: when writing a bit rate calucator you normally round down, when calculation the bit rate for a given target size, because it normally is less of a problem to have too small than to big file sizes,..

Cu Selur

Ps.: If you are into bitrate calculation, try to figure out how to calculate the overhead caused by raw trueHD audio that get's muxed into an m2ts container,..

[kalehrl]

I see MeGUI mentioned and my experiences are that for target size of 700MB with h264 and 2 AAC audio tracks, the muxed encode always ends up at 696MB.
So I always set 704MB as desired size and hit 700MB bang on.
If I only have one AAC audio track, I set 703MB as the target.
The same "problem" was with xvid avi encoding but this has recently changed because some changes were made to bitrate calculator so now 700MB as target size hits 700MB right on.
The above small problem with h264 mkv and AAC audio remains.