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: [email protected] 
[mailto:[email protected]] 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
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel

Reply via email to