I have a similar situation, although the original program had only a sink that wrote MJPEG to disk. I now have a sink that allows subscribers. The sink in my case calls add datablock with a boost::shared pointer to the frame (after my filter) on all subscribers.
Each subscriber has a ring buffer for the shared pointers and the one to disk does not throw away if poorly serviced where as the ones to display customers can drop up to the next keyframe if the data "backs up". The addition of the pointer is very fast so the overall delay of a list of subscribers is minimal. I know this deviates from the pull model. but it is a thin line when you look at the code in depth. The main thing here is the frame is allocated once and only shared pointers are moved around. With many sources and many subscribers, I could not actually afford to be copying data more than once. From: live-devel-boun...@ns.live555.com [mailto:live-devel-boun...@ns.live555.com] On Behalf Of Ross Finlayson Sent: Tuesday, November 22, 2011 2:41 PM To: LIVE555 Streaming Media - development & use Subject: Re: [Live-devel] Another question about connecting a single source to multiple sinks (eg file output and decoder) using a Frame Duplicator / Tee Sink 1. Would having a fully implemented Tee-sink / Frame Duplicator class offer significant advantages over ad-hoc methods of replicating a stream (eg. inside filters)? It depends on what you want to do with each 'replica'. If you just need two 'replicas' - one going to a LIVE555 "MediaSink" (as normal); the other just being written to a file - then the simplest solution would be to just do the file writing normally (without using LIVE555 objects). What specifically do *you* want to do with the replicated streams? 2. How difficult would it be to implement this class (any gotchas, or should it be straightforward)? Unfortunately, if it were easy, I probably would have done it already. The only real advice I can give right now is here: http://lists.live555.com/pipermail/live-devel/2006-May/004454.html As I look closely at this, it looks to me like a challenge may be that inheriting from both MediaSink and FramedSource could result in some clashes. No, this is definitely 'barking up the wrong tree'. Multiple inheritance in C++ is (generally speaking) a bad idea, and not relevant here anyway, because a general 'frame duplicator' mechanism would not contain (or create) any "MediaSink" objects at all. 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
