[Live-devel] Logging or debug info

[Jan Ekholm]

On 3 maj 2014, at 00:35, Ross Finlayson <finlayson at live555.com> wrote:

>> I have a case where I develop both the RTSP server (based on Live555)
>> and the client (based on libav).
> 
> Why not use our library for your client as well (and use "libav" just for the decoding)?  I wouldn't be surprised if "libav's" implementation of RTSP/RTP/RTCP were imperfect.  (E.g., if it were to (incorrectly) fail to send RTCP "RR" reports, then that could cause your server to time out the connection.)
> 
> 
>> I'd like to rule out the server side in this equation by
>> getting a bit more information about what it's doing
> 
> You could add
> 
> #define DEBUG 1
> 
> to the start of "liveMedia/RTSPServer.cpp", and recompile.
> 
> Alternatively, I suggest using "testRTSPClient" (and/or "openRTSP") as your client.  That should tell you if the problem is with your server, or with your client.

Testing with:

	./testRTSPClient rtsp://192.168.1.12:8554/camera0

it seems to work ok until the 65 second timeout occurs on the server side. Perhaps it does not handle the
needed RTSP conversation? Same happens with ./openRTSP. I see from my server logs that the camera
I stream gets deallocated. I have done nothing custom on the Live555 side for the low level RTSP handling,
so I assume the clients don't do the needed talking. Live555 says as much too after enabling the DEBUG
variable:

RTSP client session (id "2FBE732F", stream name "camera0") has timed out (due to inactivity)

Other applications like VLC or avconc work fine for longer periods of time (hours), even my own libav based 
client often works fine for long periods of time.

It seems to be something related to when several clients connect to the server and some clients time out.
My own client is controlled in a somewhat silly manner, so it gets killed and restarted when there are changes 
in the video window size. This seems to leave the old sockets open and these time out after a while. When
these time outs occur there seems to be a bigger risk for my client to freeze. I haven't found out why, but it
only happens when the server is Live555-based.

I also now see that the server always streams over TCP, not UDP as I would have expected. Is there any 
way to control what transport is actually used for the video streams? The control stream is TCP of course.

-- 
Jan Ekholm
jan.ekholm at d-pointer.com