[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 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:
> > On Fri, Jan 22, 2010 at 03:27:27AM +0300, Yuriy Kaminskiy wrote:
> > > Index: MPlayer-20100104+lavc-mt/stream/stream_ffmpeg.c
> > > ===================================================================
> > > --- MPlayer-20100104+lavc-mt.orig/stream/stream_ffmpeg.c	2010-01-20 19:57:02.000000000 +0300
> > > +++ MPlayer-20100104+lavc-mt/stream/stream_ffmpeg.c	2010-01-20 19:58:25.000000000 +0300
> > > @@ -31,7 +31,7 @@ static const struct m_struct_st stream_o
> > >  
> > >  static int fill_buffer(stream_t *s, char *buffer, int max_len)
> > >  {
> > > -    int r = url_read_complete(s->priv, buffer, max_len);
> > > +    int r = url_read(s->priv, buffer, max_len);
> > >      return (r <= 0) ? -1 : r;
> > >  }
> > 
> > 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.