Bitrate Viewer

Home | Features | Zoom mode | Properties | Commands | Download | Changelog | Problems | FAQ | Thanks | Forum


The bitrate of a video track is measured in bits per second which is considered as the physical unit. In a metrical system we usually supply exponential coefficients as prefixes to a value. With bitrate values are normally growing above the first three ten based exponents, so we have k for kilo = 1,000 and M for Mega = 1,000,000 as multiplicands. Even higher values as you can find in binary transfer speeds are prefixed with G for Giga = 1,000,000,000. We wouldn't have that kind of value for a video track (not yet ;-) - but you can see one thing here: it is always a multiplicand based on ten ... not on 2, 8 or 1,024 as for computer memory devices. The reason for that maybe found in the fundamental history of data processing. In the very beginning things like a byte or a kilobyte were not existent while data transfer via serial lines did exist already. So the unit for bitrates is metrical, not binary.

Remark: In the Bitrate Viewer tool that comes with DVD-Lab PRO you can switch between metrical and binary display of the bitrate - here with this tool you can't per author's decision!


File load progress bar

From version 2.0 onwards you'll see a load progress bar at the bottom of the viewer window. So especially in cases like those of which you see the screenshot on the right side where the pre-load frame count estimated doesn't match the file size in progress. The percent value shown on the window bar is based on the frames read vs. frame count estimated and the progress status bar on the bottom is based on percentage of the file size already read vs. total file size. The example here is taken from a demuxed VOB file that has only GOP timecode because it's an elementary stream now ... and the original file was cut-edited with a raw MPEG editor, so the timecode stamps in the file are not correct which leads to a wrong frame count estimation. The last GOP timecode is of about 12 minutes and the real frame count makes up only 3 minutes.
Experimentally as of version 2.0 a cross check of the estimated frame count (for GOP timecode analyzed files) against the file size and current file position read is done which should avoid the shown effect of this screenshot. Therefore the preview of a file loaded should be more in sync to the final view when the file is fully analyzed. A feedback to this behaviour is kindly appreciated and requested.