[MPlayer-dev-eng] [PATCH] fix seeking in demux_lavf

[Aurelien Jacobs]

Reimar Doeffinger wrote:

> On Wed, Aug 06, 2008 at 01:12:56AM +0200, Aurelien Jacobs wrote:
> > The call to stream_seek() fails, and streem_seek()
> > trash the stream cache as a side effect. Then the demuxer
> > try to seek back to it's original position. At that point,
> > url_fseek() don't know that the cache was trashed, and
> > thus, think it can just point into current buffer without
> > actually seeking.
> 
> ??? mp_seek does not even have access to the ByteIOContext buffer,
> so how can it trash it?

It's not the ByteIOContext buffer which is trashed, but the stream
cache internal state. And so, when the ByteIOContext try to read
further in the file (after a seek failure), the stream cache is
not able to read the data which it would have read if there were
no seek tentative.

I will try to put it more clearly.
url_fseek expect that the actual seek function won't change the
state of the stream reader in case of failure.
On the other end, the stream_seek() function will trash it's
internal state when seeking past the end of the file (it set
s->eof and modify various other internal pointers, including
s->pos). It is then unable to continue reading stream as if no
seek happened.
So stream_seek() don't meet the expectation of url_fseek()
in case of failure.

Now I recognize that my patch was somewhat hackish (it touched
some ByteIOContext internal vars to force a specific url_fseek()
reaction which shouldn't be needed at first).
So here is a better patch that just reset stream cache to it's
previous state after a stream_seek() failure, thus making
mp_seek meet url_fseek() expectation.

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer_lavf_seek_fix_2.diff
Type: text/x-patch
Size: 858 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20080806/f26fc6bc/attachment.bin>