Ross Finlayson wrote:
So while I debate the merits of changing RTSPClient I went ahead and
with my original idea of creating a second TCP connection once the
first is taken over for streaming and by golly it works (with the
server mods I mentioned before). I don't have all the kinks and
corn
So while I debate the merits of changing RTSPClient I went ahead and
with my original idea of creating a second TCP connection once the
first is taken over for streaming and by golly it works (with the
server mods I mentioned before). I don't have all the kinks and
corner cases worked out yet
Ah yes now I see how the routing to the correct stream handlers work,
that's a peace of work. Took me a while to see the statics in
RTPInterface.cpp and see how all the routing works.
So once I figured that out I started to plumb in a callback so that the
SocketDescriptor could notify a non RT
I'm starting think that the problem is even more insidious than just
RTSP replys don't get recognized by the client. I think the current
implementation prevents multiple streams in the same session from
being received using RTP over TCP, I think I experienced this the
first time I tried it. Doe
Matt Schuckmann wrote:
I need to make RTSP commands work when streaming RTP over TCP because
I need to be able to use the SET_PARAMETER and GET_PARAMETER commands
to control my live camera during the session.
The way I thought I understood the problem with the current
implementation is that o
I need to make RTSP commands work when streaming RTP over TCP because I
need to be able to use the SET_PARAMETER and GET_PARAMETER commands to
control my live camera during the session.
The way I thought I understood the problem with the current
implementation is that once the PLAY command is