[Live-devel] controlling the rtsp negotiation with custom event loop

[Ross Finlayson]

> 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/