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