[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)

[Reimar Döffinger]

On Sat, Jan 23, 2010 at 12:29:50AM +0200, Uoti Urpala wrote:
> 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.

Probably I'm wrong. Still, I changed FFmpeg, that should at least mean EAGAIN
handling for free.