[MPlayer-dev-eng] Re: Forgotten patches/bugreports/etc

[Anssi Saari]

On Fri, Aug 18, 2000 at 10:59:01PM +0200, Arpi wrote:

> the mpeg demuxer use sthe nominal bitrate from the file header.
> if the nominal bitrate in header is valid, ie. it's the real average
> bitrate of teh file, then it will report the right length, and -ss will
> work ok. 

So I'd have to assume then the information is bad as I've noticed this
mostly with VCD format mpeg1 files that are cbr?

I assume the values for video and audio bitrate that mplayer prints on
startup are from the headers? I get this from a VCD:

VIDEO:  MPEG1  352x240  (aspect 12)  29.97 fps  1150.0 kbps (143.8 kbyte/s)
[V] filefmt:2  fourcc:0x10000001  size:352x240  fps:29.97  ftime:=0.0334

MPEG 1.0, Layer II, 44100 Hz 224 kbit Stereo, BPF: 731
Channels: 2, copyright: No, original: No, CRC: Yes, emphasis: 0
AUDIO: 44100 Hz, 2 ch, 16 bit (0x10), ratio: 28000->176400 (224.0 kbit)

For this file, file size is 448938328 bytes, length 2579.4 seconds
(according to mplayer output). So the bitrates known by mplayer
should lead to the almost correct length and seeking should work as
448938328/2579.4*8 is 1392.38 kbps.  Not exactly 1374 kbps, but close. But
mplayer shows length as 52:03 instead and seeks accordingly.

> as svcd is very constrained cbr stream, i guess this value is correct then.
> for random vbr encodes it may be totally false.

I found two svcds where the value isn't correct, the length shown is
much less than it should be and -ss works accordingly wrong. Here the
video bitrate shown by mplayer probably is the max bitrate.  As I recall,
svcd has vbr video? So your explanation above fits this case.

But really, with CBR VCDs seeking and length should be correct, shouldn't
they?