> 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 the same TaskScheduler, UsageEnvironment, > eventLoopWatchVariable and there is one doEventLoop() running (as in the > testRTSPClient project).
Correct. Those are the only two choices, *if* you have also chosen to use just one process. (Note below.) > I've current implemented design 1, while I see option 2 being the intended > choice. The reason for picking 1 is the added "security" of keeping each > stream entirely independent, i.e. if an exception occurs for any reason only > one stream should be affected. Well, it depends on what you mean by "exception". If one thread has a memory access error, then it will kill the entire process. And there's nothing to prevent one thread (due to a bug somewhere) from stepping all over memory that's used by another thread. So there's really not much 'security' here at all. If your streams really are "entirely independent", then why not use one process for each stream? That is by far the safest and most reliable approach. But for some odd reason, here in the 21st century, the idea of structuring an application as multiple processes seems to have fallen our of favor... Ross Finlayson Live Networks, Inc. http://www.live555.com/
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
