On 3 maj 2014, at 00:35, Ross Finlayson <finlay...@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.ekh...@d-pointer.com
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
