[MPlayer-users] To whom it may concern

[Julius Friedman]

More succinctly,

If a server does not send a response and does not close the connection
mplayer's rtsp layer will attempt to read on the socket until it's closed
by the remote party.

the request can't be cancelled, and it causes any UI used to become stuck
while the library is waiting for a response which is confirmed by 'rtsp:
read error' in the logs.

So, if a server takes longer than 30 seconds to respond MPLAYER will not
issue another request during this time and also will continue to read for
data which will never arrive.

This is exacerbated because MPLAYER sends an initial RTSP request with a a
'REAL CHALLENGE' to attempts to discern the compliance of the remote party,
if the response to the initial request is not received before the response
to the 'standards complaint' response MPLAYER WAITS FOR A RESPONSE WHICH
NEVER ARRIVES.

VLC and Other players don't have this problem because they don't have their
own RTSP handling code which incorrectly uses a 30 second timeout (which
also prevents people from closing their player without a kill- 9) until the
poll and read completes.

Anyway as you guys stated you should probably be using the ffmpeg or libav
rtsp code which has it's own set of issues which I have reported but you
should also probably replace that value with 1 second or the amount of time
the connection to to complete.

Sincerely,
Julius





On Sun, Jan 18, 2015 at 5:57 PM, Julius Friedman <juliusfriedman at gmail.com>
wrote:

> In short, If the session timeout is less than 30 seconds this can cause
> the connection to timeout.
>
> I only be able to seem to replicate when I force it to occur.
>
> And yes, I have reported separate issues to libav.
>
> Julius
> On Jan 18, 2015 5:45 PM, "Reimar Döffinger" <Reimar.Doeffinger at gmx.de>
> wrote:
>
>> On Sun, Jan 18, 2015 at 02:51:07PM -0500, Julius Friedman wrote:
>> > It appears that some code in MPlayers RTSP Layer is not configured
>> > correctly.
>> >
>> > The code I am using is svn r37343.
>> >
>> > VLC Handles this better as can be seen here but uses a more complicated
>> > mechanism  (Which also seems to check for polling on reading but not
>> > writing but is besides the point)
>> >
>> > The code in VLC can be found here for reference:
>> >
>> > http://ffmpeg.org/doxygen/trunk/rtsp_8c_source.html
>> >
>> > -----------------
>> >
>> > MPlayer's code (which I assume to be similar to as follows as of the
>> > current release)
>> >
>> > https://github.com/pigoz/mplayer-svn/blob/master/stream/librtsp/rtsp.c
>> >
>> > Line 109 sets timeout.tv_sec = 30;
>> >
>> > This may be longer than required as between two requests which occur
>> which
>> > may subsequently cause a server to disconnect a client if it does not
>> > monitor liveliness of the session via the transport profile (rtp or rtcp
>> > etc)
>>
>> Could you describe the actual _problem_ you are seeing?
>> "may be longer than required" to me sounds like a good thing, but
>> you obviously think it is wrong/bad.
>> Anyway that code is really old and you should try ffmpeg://rtsp://
>> instead (and we probably should make that the default at some point,
>> even though it has other problems).
>> _______________________________________________
>> MPlayer-users mailing list
>> MPlayer-users at mplayerhq.hu
>> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-users
>>
>