[Live-devel] FW: LiveMedia in a Directshow Filter

Ross Finlayson finlayson at live555.com
Sun Nov 28 01:14:07 PST 2010


I discovered (and, I hope, fixed) a bug in our mailing list software 
that was apparently causing the list's digesting and archiving 
mechanism to choke on some Unicode characters that were in Eyal's 
message (and quoted in my response).

Therefore, I'm sending my response again, in the hope that it will 
get through to everyone this time.  (This may be the third time that 
some of you have seen this message; if so, my apologies.)

------------------
>Question #1:  How should  Notify MPEG4LiveSource::doGetNextFrame ?
>while(true)
>{
>fWatchVariable = 0;
>dummyTask(NULL);  // 100 ms to awake a sleeping server.
>env->taskScheduler().doEventLoop(&fWatchVariable);
>if (fWatchVariable =1)
>{
>                 // How to Invoke MPEG4LiveSource::doGetNextFrame?
>printf("\nEventThrown=%d,",fWatchVariable);
>}
>}

Assuming that "fWatchVariable" gets set when new data arrives for 
your "MPEG4LiveSource" object, then you would handle this event by 
calling whatever function - in your "MPEG4LIVESource" class - you 
have defined to handle the arrival of new data.

(E.g, if you were to use our "DeviceSource" code as a model 
("liveMedia/DeviceSource.cpp"), this would be the "deliverFrame()" 
member function.)


>Question #2: Is It ok to use MPEG4VideoStreamFramer or should I use 
>MPEG4VideoStreamDiscreteFramer in order to parse test.m4e file.?

".m4e" files should always be streamed using the 
"MPEG4VideoStreamFramer" class (because files deliver a byte stream - 
not a stream of discrete frames).


>void MPEG4LiveSource::doGetNextFrame() {
>
>                 if (!isCurrentlyAwaitingData())
>                                   return; // we're not ready for the data yet
>
>                 // WaitForSingleObject( hEvent, INFINITE ); // 
>Question #3:  Try to sync both thread Ignoring 
><http://www.live555.com/liveMedia/doxygen/html/classTaskScheduler.html>TaskScheduler::doEventLoop() 
>, is that recommendable?

No!  Your "doGetNextFrame()" function should never block.  If no data 
is immediately available for delivery, then "doGetNextFrame()" should 
just return.  (Again, see the "DeviceSource" code for an 
illustration.)


>nextTask() = 
>envir().taskScheduler().scheduleDelayedTask(0,(TaskFunc*)FramedSource::afterGetting, 
>this);     // Question #4:  Is that good to call suitable here?

Yes.  This tells the downstream object that data has been delivered to it.


>Question #5:  Run over the Mailing list I could not found any 
>example of streaming from DirectShopw filter, Is there a problem 
>with that approach?

No.  Several other people have done this.  (However, I personally do 
not use 'DirectShow'.)
-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20101128/4ee9611b/attachment.html>


More information about the live-devel mailing list