[MPlayer-users] Skew between seek and get_time_pos

[Joey Parrish]

On 8/16/07, Peter Seibel <peter at gigamonkeys.com> wrote:
> Reimar Döffinger wrote:
> > Hello,
> > On Thu, Aug 16, 2007 at 09:48:26AM -0700, Peter Seibel wrote:
> > [...]
> >> As I seek farther and farther into the file the get_time_pos value gets
> >> more and more behind the seek value.
> >>
> >> Is this a bug or am I misunderstanding how things are supposed to work?
> >
> > Well, the first step would be to find out whether seek or get_time_pos
> > are wrong.
> > Then the next step is to find when the problem happens (i.e. with all
> > file formats, only some, with lavf demuxer or native?)
>
> Okay, so I think the problem is with seek and it happens with .wma files
> but not with .wav or .mp3. That is, if I'm playing an .wma file and I
> seek to a particular timestamp it actually seeks to somewhere earlier in
> the file. The timestamp returned by get_time_pos then accurately
> represents where it seeked to. The difference between where I asked it
> to seek and where it actually went gets larger the farther I am into the
> file. This does not happen, as I say, with .wav or .mp3 files.

The same happens (IIRC) for VBR mp3's.  So I think it's a limitation
of seeking into VBR streams without an index.  It may be seeking to
(average bitrate according to header * time position) or some such.

--Joey