[Live-devel] Live.Com and DirectShow implementation

[Ross Finlayson]

>In this implementation i created QueueSource class
>derived from
>FramedSource, it has std::queue type member variable
>to store data from
>previous filter( audio encoder or video encoder), and
>i use windows
>mutex as locking mechanism.

Note that the LIVE.COM library code is designed to run within a single 
thread (see  <http://www.live.com/liveMedia/faq.html#threads>).  So, if you 
have a second thread that delivers data to the first (using mutexes for 
locking), then that's probably OK, provided that the second thread does not 
actually call any LIVE.COM library code.

>I also created AudioQueueSource and VideoQueueSource
>derived from
>QueueSource and implemented their own doGetNextFrame.
>I also created AudioQueueServerMediaSubsession class
>derived from
>OnDemandServerMediaSubsession, it has AudioQueueSource
>to read from.
>
>The program worked like this(audio only):
>1. data from previous directshow filter are stored to
>std::queue inside
>AudioQueueSource through insert function from
>AudioQueueServerMediaSubsession.
>2. doGetNextFrame will read this std::queue and the
>send the data to the
>world.
>
>Is this implementation correct?

You didn't really explain what you want your program to do, but if your 
goal is to build a RTSP server that will stream - via unicast, on demand - 
audio and/or video streams that come from a Windows 'DirectShow' source, 
then what you've described sounds correct.

One thing to note, though: It is possible for more than one RTSP client to 
be playing the stream simultaneously.  So, it's possible for more than 
"QueueSource" to be reading from the same input stream.  So, your 
implementation should take that into account.


	Ross Finlayson
	LIVE.COM
	<http://www.live.com/>