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 RTP entity (i.e. the RTSPClient
object) that non RTP data had come in. That seemed to be going well
until I got out to the RTSPClient class and realized that it assumes it
owns the TCP stream and whenever it sends data it immediately pends on
the socket for the reply, throwing away any RTP data it encounters while
waiting (I'm actually puzzled why this doesn't work). This poses a
problem for my nonRTPCallback solution because the SocketDescriptor in
the RTPInstance will never get a chance to see the data and do the
forwarding. I think to make this work we'd have to change the way most
of the RTSPClient commands work, it would have to be a little more event
driven, i.e. RTSPClient sends the command then lets the TaskScheduler
take over when the data arrives the RTPSClient::incomingRequestHandler
would get called (via a callback from the SocketDescriptor) and the
RTSPClient could parse the response and notify it's client of the result
via a callback. This would probably be a breaking change with how
RTSPClient works now but it would certainly simplify getting this
feature working. I suppose one could provide 2 RTSPClient classes; the
current one and a new one that is event driven and works well with
RTPovertTCP. What would you prefer to see a radical breaking change in
how RTSPClient works or a second event driven RTSPClient class perhaps
with the common code between the two re-factored out to a base class? Or
can you see yet another solution?
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 but it does work. Would this be something you'd want to have in
the library.
Thanks,
Matt S.
Ross Finlayson wrote:
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. Does this sound correct?
No, that's not correct. There is no problem having multiple streams
(e.g., audio + video) in a single RTP-over-TCP connection. (The data
format includes a tag which identifies each sub-stream, and our
receiving software handles this OK.)
Is the problem that the RTPSource that is created for the first
stream now owns the TCP socket and it has no way to forward data
that's not for it on to the other interested parties (other
RTPSources and the RTSPClient)?
Basically, yes.
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
