Movie File Sizes

[Rio]

Originally Posted by Shadowself

One little nit pick... your Mbps numbers appear to be based upon the definition of Mbps using a 1024 x 1024 definition for M. This is incorrect. The M represents 1,000,000. Thus your Mbps numbers are about 5% low.

My calculation for "M" is based on 1,000,000, not 1024 x 1024. The reason why you see 5% low number is I'm subtracting overhead rate - assuming 5% -, like subtitle data, TS/PES header information from AV rate which is simply calculated by dividing file size by run time.

[Shadowself]

Originally Posted by Rio

My calculation for "M" is based on 1,000,000, not 1024 x 1024. The reason why you see 5% low number is I'm subtracting overhead rate - assuming 5% -, like subtitle data, TS/PES header information from AV rate which is simply calculated by dividing file size by run time.

I understand your rationale but disagree with it.

Are you saying this overhead is not necessary for the video file to be utilized properly? If the overhead is necessary then I would propose that the overhead should be included in the data rate. If it won't play properly without it then it should be included. While such things as subtitle data (if indeed subtitles are included on the disks for these features) might not be necessary for proper operation, TS/PES overhead (or similar header overhead) is most likely necessary and things such as this must be included in the data rate to not do so gives a false impression of the minimum data rate.

However, if subtitle data is included (it is common) then I would suggest that this should be included too since it is indeed part of the data stream (and is quite common).

[Rio]

Originally Posted by Shadowself

Are you saying this overhead is not necessary for the video file to be utilized properly? If the overhead is necessary then I would propose that the overhead should be included in the data rate. If it won't play properly without it then it should be included.

Video stream (elementary stream) doesn't require those overhead data for playback correctly. TS/PES header are required for multiplexed stream, those are not used for video decoding, so I subtracted those rate. If the overhead asumption is really correct, that number will fit near the actual video file size directly coming from video encoder. If the overhead is not considered, we never get correct video file size. Anyway, if the lossless audio codec or PiP stream gets included in muxed stream, we have no way to assume average video bit rate any more...

Originally Posted by Shadowself

However, if subtitle data is included (it is common) then I would suggest that this should be included too since it is indeed part of the data stream (and is quite common).

"Ave.V Rate" in the table I posted is intended to stand for video elementry only. If you don't like this way, you can pick your number as you like.

[Shadowself]

Originally Posted by Rio

Video stream (elementary stream) doesn't require those overhead data for playback correctly. TS/PES header are required for multiplexed stream, those are not used for video decoding, so I subtracted those rate. If the overhead asumption is really correct, that number will fit near the actual video file size directly coming from video encoder. If the overhead is not considered, we never get correct video file size. Anyway, if the lossless audio codec or PiP stream gets included in muxed stream, we have no way to assume average video bit rate any more...

"Ave.V Rate" in the table I posted is intended to stand for video elementry only. If you don't like this way, you can pick your number as you like.

In this series of posts you have very adequately (maybe even more than adequately for some readers) explained your rationales for doing the data file sizes and data stream rates the way you did. Thanks.

My concern is that this may still be misunderstood by many readers and when taken out of the context of your explanations if very likely to be misrepresented.

My thoughts are like this: If the data on a HD DVD or Blu-ray disk will always have some level of overhead then we should count that overhead as part of the file size and necessary data rate. Otherwise people will be quoting the video only file size (without the overhead) and think it includes everything necessary.

While I never have dug into the relevant specs deeply enough to know how much and what kind of overhead is required in the two disk formats (and I'm too lazy at the moment to go dig them up and check), I'm absolutely certain some level of overhead is required. I doubt a studio can put raw MPEG2/4 or VC-1 files on either a HD DVD or Blu-ray disk and have the players be able to properly read them. I believe at the very least you should include that minimum overhead in your file sizes and data rates.

I think of it basically like this: When I do satellite communications analyses (and not beating on imaging and image analysis systems) I work with a minimum of two different communications rates. One is the "data rate" that includes all the forward error correction coding, all the handshaking bits, all the packeting headers, channellization bits, spreading chip rates, etc. I do this because it defines the necessary bandwidth of the system. This defines the "capacity" of the system: how many bits actually get shuffled around and how fast. The other is the "information rate". This one includes ONLY the information being transported and aboslutely none of the overhead. In some cases the information rate can be as little as one fourth (or less) of the data rate -- and in some extreme cases as little as 0.1% of the data rate.

By analogy you are giving the "information" and "information rate" of the systems. This may have very little to do with the actually capabilities of the overall systems.

As an example of the systems at point here... suppose for a moment that one of the two formats required significantly more overhead than the other (say one required 2% overhead and the other required 6% overhead). Removing that overhead from the file sizes and data rates would be misleading when trying to compare the two different formats.

Another way to look at it is with regard to modulation techniques and forward error correction coding. Higher order modulation techniques allow for more bits per Hz of bandwidth but require more and more robust forward error correction coding. When the two are combined the final information bandwidth had decreased significantly, but the final data rate and overall bandwidth may only marginally be decreased, if at all -- all the while greatly increasing the processing power required at both ends of the communications links. So if you look at only the information bandwidth it is very misleading as to what is really happening.