0

I'm trying to get a videos exact size by using the following.

(size in bytes*8)/(total bit rate(audio+video bitrates) * 1024)

ex:

(1,136,992*8)/(7128*1024) which comes out to 1.24617705 seconds

But in windows movie maker live, it was saying that the actual length in seconds was about 1.87 seconds. Am I doing something wrong, or is windows live movie maker off? I'm guessing it's the former.

I've been using a video recorded with Easycap then put into Windows live movie maker to trim, then finally converted to ogv format. So that makes sense that it would be completely messed up. I don't know how to access the metadata header of an ogv video file, I've looked around but don't see any answers.

Simon Hayter
  • 3,131
  • 27
  • 53
Riveascore
  • 1,724
  • 4
  • 26
  • 46
  • 1
    Files containing video and audio are unlikely to be raw data. What format is the file? Any compression will throw off your calculation. – Steve C Dec 22 '11 at 20:58

3 Answers3

1

Are you dividing the file size with the bit rate? If so, you're including headers and other overhead in your calculation.

But the main reason that this calculation doesn't work is simply that bit rates aren't that exact. Think about it: If bit rate was exact, every single video frame (and the audio that goes with it) would have to be compressed to the exact same number of bytes. Most compressors just don't work like that. (One exception is the DV codec. Since DV is a tape format, it has to produce data at a constant rate.)

Think of bit rate more like the average number of bits used per second.

To get the length of a video file, you'd have to read the file's metadata. How to do this differs from format to format. For an ogv file, the oggLength program seems to be what you need (included in oggvideotools).

Martin Vilcans
  • 5,428
  • 5
  • 22
  • 17
0

Video files often have metadata and headers which increase the total file size. To get a reliable measurement, you would need to calculate the size of the non-video/non-audio data and subtract it off before doing your calculation. Not only that, but you would also have to account for the possible variable bit rate of the audio and video data. This is generally not going to be easy unless you are looking at a very simple file type with a constant bit rate or you already have deep knowledge of the video format (or else you already have a library that understands and parses the format).

bobbymcr
  • 23,769
  • 3
  • 56
  • 67
0

That particular calculation would only work if every frame is the same size. The only way that would happen is if you're using an uncompressed video AND audio stream. These types of files become huge and impractical very quickly, therefore it's likely that you're using compression. In compressed video files, bitrate is NOT a guarantee, it's just an average. Furthermore, the size of each frame changes since there are different types of frames.

Most video container formats (avi, ogm, mkv, etc) all embed the length of the file in the metadata (as part of the header). It would be far more accurate to simply read this value.

Chris Eberle
  • 47,994
  • 12
  • 82
  • 119