I've spent way too much time trying to figure out the formula for calculating the amount of overhead in an multiplexed audio-video MPEG file. It seems to vary by audio bitrate, video bitrate, plus some other magic stuff I don't know of. Even encoding the same file at assorted bitrates yields a very strange-looking graph of overhead/bitrate distribution.

The only reason I'm actually interested in this is because I need to be able to calculate the overall file bitrate, but I've only figured out how to pull out the bitrates of the component video and audio portions, but the ~1-5% overhead is throwing off all my playtime calculations by an unacceptable amount.

So - I guess my real question is "How do I calculate the correct playtime for a multiplexed MPEG video+audio file?"

Please forgive me if I sound stupid... but one simple idea just pop up.
Do you know how to find the frame rate of the video?
If you know the amount of frames and the frame rate, it should be very simple to calculate the playtime.

I know the frame rate, yes, but I don't know how many frames there are total. That would be too easy

Right now I'm assuming that total_bitrate == video_bitrate + audio_bitrate + multiplexing_overhead, where multiplexing_overhead is calculated by a convoluted interpolation/lookup formula based on observed bitrate deviations, but I still can't get better than 98% accuracy in some cases.

It would be difficult to pinpoint your problem without knowing the details of your implementations.. Are you multiplexing a pre-encoded video and audio stream?

are you trying to mux a .mpeg/.mpg file or .mp4?

if you mux into .mp4 you can be sure that the resulting mp4 is smaller than the source avi for example (well mp4 is the native container, especially designed for mpeg-4 content)

No, you dont. a MPEG2 video file can change the framerate in the middle of the file, the headers tells you nothing about that ....