> I have an application that has its own event loop when manipulating/reading
> sockets, however, I'd like to use live555 to do the rtsp negotiation process
> with the cameras.
Unfortunately, I’m not quite sure what you mean when you say that your
application “has its own event loop when manipulating/reading sockets”, because
the LIVE555 code - when it implements RTSP/RTP/RTCP - does so by ‘reading and
writing sockets’. Therefore, if you want to implement RTSP/RTP/RTCP using the
“LIVE555 Streaming Media” code, then you *must* do so using the LIVE555 event
loop, which you will enter by calling “doEventLoop()” within your application.
Perhaps your application already has its own event loop (e.g., to implement a
GUI)? In that case, you *could* try to arrange for these other ‘GUI’ events to
be handled as part of the LIVE555 event loop - i.e., so that your application
has just a single event loop. Most people, however, find it simpler to run all
of the LIVE555 code (including its event loop) in a separate thread, with the
other ‘main’ event loop thread communicating with the LIVE555 event loop thread
via shared variables (e.g. event loop ‘watch variables’) or by calling
“triggerEvent()” (the *only* LIVE555 function that you may call from the
non-LIVE555 event loop thread).
> I also need my own step-to-step control over the rtsp negotiation process,
> i.e.
>
> 1) describe+setup => port numbers
> (do something within my own event loop)
> 2) play
> (do something within my own event loop)
> 3) teardown
> (do something within my own event loop)
This is easy to do - except that instead of doing ‘something’ within your ‘own'
event loop, you will do it within the LIVE555 event loop. Note that each
LIVE555 function that implements the sending of a RTSP command - i.e.,
“sendDescribeCommand()”, “sendSetupCommand()”, “sendPlayCommand()” etc. -
takes, as a parameter, a function that will get called, automatically (by the
LIVE555 event loop), after the RTSP command has completed. It is within this
function that you would do your ‘something’ in each case.
> 1) I understand that in the rtsp "response handlers" and in the callbacks
> within them, we create the necessary logic, but how does the program actually
> run? .. does the event loop explicitly execute the "response handlers"..?
> where in the code this takes place?
All of this (the LIVE555 event loop) takes place inside the call to
“doEventLoop()”; see
http://live555.com/liveMedia/faq.html#control-flow
The LIVE555 code handles each RTSP response by handling a ‘new data is
available’ event on the RTSP command socket. In doing so, it will read and
parse the RTSP response, and call the appropriate ‘response handler’. It does
all of this automatically (within the LIVE555 event loop), and you don’t need
to concern yourself with how this is implemented (i.e., you should treat the
LIVE555 libraries as being a ‘black box’).
> 3) Is there any better way to access the subsession data, other than always
> creating a *new* MediaSubsessionIterator and then using the "next()" method ?
> .. iterators should have also "begin()", "previous()", etc. methods, but
> these seem to me missing in the code..? i.e. one must create a new object
> and then, after using "next" couple of times, the object becomes useless and
> throwing segfaults if you try to access data, for example, clientPortNums.
I don’t really understand what you’re asking here, but I don’t think you
understand how the “testRTSPClient” code (for example) works. Note, in
particular, how this code defines a class “StreamClientState”, which includes a
“MediaSubsessionIterator” and a pointer to a “MediaSubsession”. An object of
this class is used to represent the current state of the RTSP client. Note
that a “MediaSubsessionIterator” is created only once (for each RTSP client).
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
