[Live-devel] problems moving to asynchronous rtsp interface

[Jeff Shanab]

In the hour+ it took for the post to go I found something even more "stupid" the Sink was not set due to a bad if condition. :)

I still have some errors but I am getting further now.

So it seems clear that  having one environment with a single scheduler the prefered method. The side effect is of course that things printed to the env get all jumbled up. (Windows console is over 100 times slower than a *nix one)  I can protect these with a mutex, but should we consider internally protecting the environment streaming calls?

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

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.

[...]


What did I miss?

My guess: You're forgetting to call "startPlaying() on each input source.  (You should do this between getting the response to "SETUP", and the sending of "PLAY".)

(Note that the RTSP "PLAY" command merely starts the streaming at the server end.  You still need to - at the client end - call "startPlaying()" on each input source, to actually receive the data.)

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/13c68d3f/attachment.html>