[Live-devel] problems moving to asynchronous rtsp interface

[Jeff Shanab]

I have almost gotten the migration to RTSP asynchronous working in my code.
I get to the point where the play command is send and I get a reply and it prints out the Receiving Streaming Data, but then it just sets there. Looping endlessly never detecting arrival of packets.

I have the identical checkForPacketArrival() as the openRTSP() and it finds one subsession and then src->receptionStatsDB().numActiveSourcesSinceLasteRest() is always zero so it exits the while, reschedules and tries again.

When I wireshark and follow the stream I have the full conversation and then a stream of binary data.

What did I miss?

From: live-devel-bounces at ns.live555.com [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
Sent: Saturday, November 26, 2011 4:13 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] problems moving to asynchronous rtsp interface

I think it is I who doesn't understand. :) If I ever get the time I really need to just sit down and read thru the live555 code.

Ideally, you'd need to read only the header files, and the example applications - not the library ".cpp" files.  (We don't live in an ideal world, though :-)



For me an instance is one rtsp connection to a source.

OK.  In LIVE555, this is encapsulated by a "RTSPClient" object.  But you can add more state as well (see below).



It has a statistics class that is updated and displayed thru a web console.
It has  some control, stop start pause, shutdown. Obviously the moment the eventloop is started it dictates another thread because otherwise it would be blocked to other requests.

So for example I had all the env setup and everthing in a start function. I am now trying to at least refactor that to a static env and scheduler for all connections (is that correct?)
I either need to have my class intercept the call back by having the callback more generic, or I need to make my class become a RTSPClient subclass.

Or your "RTSPClient" subclass can simply contain a member field that *points to* an object of your "instance" class.

That's all I'm suggesting.  Subclass "RTSPClient", and add a field called "fParentInstance" (or something) that points to an object of your existing "instance" (e.g.) class.  Then, in each of your response handlers, you just cast the first parameter to be a pointer to your "RTSPClient" subclass (because you know it is), and then access "fParentInstance". Voila!  You have your state back.



I am trying the subclass idea now with just the setBaseURL moved to the protected area.

I'll make this change in the next release of the software, because it's likely to be generally useful.

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/

________________________________
No virus found in this message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 2012.0.1873 / Virus Database: 2102/4648 - Release Date: 11/30/11
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20111130/ca39035a/attachment.html>