[MPlayer-users] To whom it may concern
Julius Friedman
juliusfriedman at gmail.com
Sun Jan 18 20:51:07 CET 2015
Hello Guys,
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)
My server is @
http://net7mma.codeplex.com/
And you can test this by intentionally generating a long running response
to a request which then causes this timer to start over again at 30.
I also notice that Mplayer doesn't do anything with the initial 'probe'
connection which checks if the server was 'REAL' compatible or not.
Wouldn't it be beneficial to steal the sessionId from the active
RtspSession, and then use that other connection to send "GET_PARAMETERS"?
This would also allow for an average RTT of those 'keep alives' to be
calculated and used in place of the the 30 SECOND poll timeout.
Sincerely,
Julius
More information about the MPlayer-users
mailing list