[MPlayer-dev-eng] fixing "librtsp: buffer overflow in rtsp_get" (mplayer exit)

[Bernhard Kaindl]

On Sun, 3 Aug 2003, Roberto Togni wrote:
> > I also did a small change to *rtsp_get() which was aborting mplayer
> > with
> > the message "librtsp: buffer overflow in rtsp_get\n" when playing an
> > rtsp:// stream over UDP in combination with a server which does not
> > get even a single answer to mplayer for a few seconds. The cause was
> > that the for loop loops pretty quick and ran quickly over it's
> > treshold.
> >
> > It would likely be best to run the recv() using an timeout, with this
> > change it loops untis a newline is received from the server.
> If i understand it correctly, you're saying that it will never exit the
> loop if it doesn't get data from the server. This is not good IMHO.

Yes, the unpatched function is not good because in the event that the
server does not get a quick answer thru in this place, the function just
exits mplayer with the "librtsp: buffer overflow in rtsp_get\n" message.

OTOH, the change I attached is not really better because does not stop
looping at at 100% CPU until an answer is received, while it stops looping
and exits mplayer after reaching the buffer size in the current code.

> Can some network guru comment on this?

I'm not a guru of the network code in mplayer, but generally a function
should not loop at 100% CPU when waiting for remote input.

Incrementall changing the new code I added by adding else/usleep():

   if (r>0)
     n++; /* move buffer index only if we got input for the buffer */
+  else
+    usleep(100000);

to have mplayer sleeping 10ms if there was no input changes the
function to not consume CPU time if there is no input without adding
noticeable delay(at least in my two tests).

It could be done using a -EAGAIN timeout, but it's not worth to do bigger
changes, I think and this only changes this function and does not touch
anything outside.

Bernhard