[MPlayer-dev-eng] [patch 02] Fix stream_ffmpeg read near EOF (was: mplayer fails to seek large file (>2G) over http due to misparsed Content-Length)

[Uoti Urpala]

On Fri, 2010-01-22 at 23:15 +0100, Reimar Döffinger wrote:
> On Fri, Jan 22, 2010 at 10:19:53PM +0200, Uoti Urpala wrote:
> > On Fri, 2010-01-22 at 20:31 +0100, Reimar Döffinger wrote:
> > > I'll try to get this changed in FFmpeg if possible. MPlayer at least in
> > > the past could behave rather badly if fill_buffer returns only very
> > > little data, so url_read really should be tried more than once.
> > 
> > Behave badly how? There aren't that many places that care about the
> > STREAM_BUFFER_SIZE setting, and I don't see any obvious breakage (I
> > checked for that earlier when fixing the issue in git). Other code
> > shouldn't care since any sizes it specifies in read calls are not used
> > directly in fill_buffer anyway. The seek function shows the code tries
> > to align the read boundaries at multiples of STREAM_BUFFER_SIZE and that
> > alignment could be lost, but I don't see how that'd cause any real
> > breakage. I haven't checked so carefully that I could be 100% sure I
> > didn't miss anything, but your "at least in the past" doesn't sound like
> > you'd have identified any problem for certain either.
> 
> What I remember (not well enough to be certain) is speed issues with forked cache.

The cache process reads data with stream_read(), which implements its
own loop to read the total specified amount. Looping at that level or
inside ->fill_buffer() shouldn't make a difference.