[MPlayer-dev-eng] [PATCH] stream seek eof handling

[Laurent]

Hi,

On 9/25/08, Laurent <laurent.aml at gmail.com> wrote:
> Hi,
>
> I've been tracking an issue with mp4 file header parsing that created
> an infinite loop in libavformat (in mov.c).
> The infinite loop has been prevented in libavformat, though, the root
> cause of this issue seems to come from MPlayer, as ffmpeg is not
> impacted by it.
>
> I have been pointed to the bug #1267, that may be the issue I encountered.
>
> Basically, stream/stream.c:stream_seek_long() behavior is inconsistent
> regarding eof handling.
> In my case, stream_seek_long() fails to move the stream position
> because eof has been reached in a previous stream_fill_buffer() call.
> As the stream position never moves forward, libavformat reads in an
> infinite loop.
>
> This issue comes from the handling of position at or after EOF in streams.
> Sometimes, it is considered as a valid position, sometimes not.
> Sometimes, eof flag is cleared during a seek, sometimes not.
>
> Does someone knows what should be the right behavior in stream/stream.c:
> * Shall the stream eof flag be cleared when seek succeeds?
> * Shall EOF be a valid position for seek?
> * Shall positions past EOF be valid for seek?
>
> As a comparison, the system lseek has such behavior.
>

Here is an attempt to clean this issue.

* stream_t->eof flag is cleared when seek succeeds.

* EOF and past EOF positions are valid for seek. Though, following
read will fail.
At least, this allows lavc to detect end of streams by checking if the
current stream position is equal or past the EOF position (what lavc
does).


Thanks,

Laurent
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: stream-stream.c-eoffix.patch
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20081017/13e73501/attachment.txt>