Math is not my strong point. I'll go ahead and admit this up front. I'm a college-educated journalist, with strong computer and online background and self-taught in the hobbies of video and Web design (and I also offer freelancing in all these topics). Math was never needed in any of these things.
What I can say in this respect, is that I know what the constants and the variables are, in regards to how they affect the final video files. How the math added up actually never quite came to the focus of what I looked at. I just know that under or over a certain bitrates, problems develop, and I know what those problems are. One of my biggests mottos in videos is that experience and actual occurences are more important than the theory or science, which is sort of where this is leading. But I can admire trying to understand "why" so I'll try to answer to the best of my ability.
Know that I mainly experimented to get the numbers I needed for "time x bitrate = final DVD size" .. and then I sought out the pros for agreement and advice. All of them agreed with my findings for the most part.
I think the problem here is the math is larger than you're calculating, and quite honestly more complex of a problem than I know how to deal with, having little more than high school pre-calculus as my highest math, and barely passing at that. Again, I'm a writer and designer, not heavy on the math skills beyond financial usage.
You have to consider that bitrate is per second. Each second is so many fields (not really frames with interlacing like DV-fed source, but we'll stick to frame anyway as it's calculated the same with two field sharing the frame bitrate), and a bitrate is parceled out at an average, as the DC (discreet cosine) is not perfect. It's just a great big calculus equation, pumping out 30 or more answers per second.
What I can say in response to the question is think of bitrate allocation in a bell-curve. You cannot have too much, else you'll get macroblocks.
An MPEG is essentially an image made up of sectors calculated by the motion compensation. It has more blocks inside these larger block sectors. Here's a quick-n-dirty image:
You have intrablock and innerblock motion to consider. Intrablock is the interaction between surrounding blocks. Innerblock is the stuff changing within a blocks. When something moves, these are affected. The bitrate is pumped up in the areas alone. This is where I-P-B compression takes hold. Areas that do not change are left alone in the IPB compression. Only the areas of movement get the bitrate in the IPB compressed areas.
When there is enough bitrate, motion is smooth, with zero errors. When bitrate is too low, you can see the blocks. It needs adequate data to maintain both the color quality AND the fluidity of movement.
Macroblocks being this:
While this was a blow-up of the image, on a tv screen, you can see the blocks, as they tend to change shade/quality several times per second. It become noise or what's called an "artifact".
The bell-curves are as follows:
You'll notice that 1800, 3500, and 7000 are good quality. For slight better, go for the gold at 2000, 4000-5000, and 8000-9000. Anything more is on the plateau until it hits a sharp spike at the overhead number of 9800 where a DVD player rejects it. I forget the max for MPEG1.
Also notice the poor quality of VCD at 1150k MPEG1. Had MPEG1 been 1850 (the max MPEG1 allowed by DVD is 1856k), then VCD would never be known as "bad quality". Only issue would have been proper deinterlacing (not that deinterlacing is good, but some methods are better than others).
Here's my quick calculation table. This is done in terms of 23-minute episodes since tv is my main hobby. Take 23xep count to get total running time.
On my APEX DRX-900 using 4-hour mode:
11 eps = 370MB = 2520k bitrate
On my ATI AIW card using ATI MMC MPEG2:
9 eps = 477MB = 2610k bitrate
8 = 537 = 2967
7 = 614 = 3426
6 = 716 = 4033
5 = 860 = 4890
Different IPB configurations, different MPEG encoders, different DC, and different hardware can affect these numbers (as you may notice between the ATI AIW and the APEX).