I went with a 1 thread per rtsp client and regret it from a scaling
perspective. The stack mem needed plus the overhead of having a thread gets to
be too much when you get into a large amounts of streams.
The library is _very_ well written to be non blocking and given the speed of
your slowes
On 7/27/2012 5:07 PM, Ross Finlayson wrote:
I'm
puzzled by why so many programmers these days seem afraid (or unaware)
to do this.
I think it's a legacy of 1990s Windows and Mac OS: poor IPC, poor
process management, etc. But they had threads, which avoids the need
for either.
Now we've g
> This is fascinating but I can't picture it. What would the design look like
> for multiple processes (one per stream as you describe)?
>
> Are there any examples of this that I can take a look at?
Sure. For a (very) simple example, imagine a shell script like the following:
#! /bin/
Ross,
This is fascinating but I can't picture it. What would the design look
like for multiple processes (one per stream as you describe)?
Are there any examples of this that I can take a look at?
Thanks,
Tim
On Fri, Jul 27, 2012 at 1:23 PM, Ross Finlayson wrote:
> When implementing liveMedia
> When implementing liveMedia using multiple streams in one process I see two
> choices:
>
> 1. Each stream is kept totally separate. I.e. each stream have their own
> TaskScheduler, UsageEnvironment, eventLoopWatchVariable and each
> doEventLoop() is running in a separate thread.
>
> 2. The rtsp
When implementing liveMedia using multiple streams in one process I see two
choices:
1. Each stream is kept totally separate. I.e. each stream have their own
TaskScheduler, UsageEnvironment, eventLoopWatchVariable and each
doEventLoop() is running in a separate thread.
2. The rtspClient's share
