[Live-devel] Non Blocking doGetNextFrame

[Drew Ostheimer]

Hello,

 

Sorry for this not being in a thread. I have officially turned off digest to
allow individual replies, so this should be the last time a new thread is
opened for the same question.

 

Ross, I read the suggested archived response and it did explain slightly
what is required to be done, however I am still a little unsure of how I can
achieve this. I will explain a little more detail about how I have things
setup and maybe this will help you to point me in the right direction.

 

I have a filter design where information is captured from a camera,
processed and then streamed out to the network using RTSP and multicast. We
are trying to use multiple cameras as well as multiple streams. With one
stream our while loop which constantly polls inside the doGetNextFrame()
function worked fine, however with two streams running, one of the streams
gets a distorted which we believe is due to our polling (high CPU usage).
Our class which is a subclass of both FramedSource and our own Filter class,
which implements threading, has an input queue associated with it. The queue
is designed such that if nothing is present it will return null. In all the
classes implementing filter, we have a wait() call to our pthread wrapper
class. Where the problem occurs is live is not using our threading model and
therefore this design will not work. How we did set it up was to just not
call our start() and allow live to take care of everything with a simple:

 

while(pkt != null)

            pkt = buffer->getPacket();

deliverFrame();

 

within the doGetNextFrame. As you can see this is a serious polling problem.
So we attempted to just read the packet test if null and if so return.
However this does not reschedule the calling of doGetNextFrame. What I can
do and think may work is implement the run() function of our threading
model, have a wait, which will be signaled when something is added to the
buffer. However I do not know how to schedule the calling of the next
doGetNextFrame. I am assuming the code is something similar to:

 

next() = envir.taskScheduler().scheduleDelayedTask(0,
(TaskFunc*)afterGetting,this);

 

No mater what I try it does not seem to work. Is there a simple way my run
function can schedule the calling of doGetNextFrame? As well would it be an
issue in the code if I call the scheduling more then once when one is
already scheduled? For instance if I get two frames, I schedule the
doGetNextFrame for the first frame and schedule the second before the first
is completed or even started? Also should the frame be processed and a
afterGetting be scheduled and my code schedule a doGetNextFrame, would any
problems ensue?

 

Hope this gives you a little more insight into my requirements and what I
hope to accomplish. I am sure it is something small I am missing, or looking
over to schedule it. Once again thanks for all your help and timely reply to
my queries.

 

______________________________________

Drew Ostheimer

 

Computer Engineering Undergraduate Student,

Concordia University,

Montreal Canada.

 

Quote: "I've seen recently on a software package: Requires

Windows 2000 or better. So I installed Linux."

______________________________________

 

 

>In a current school project I am using FFMPEG and LIVE to stream an
>MPEG-4 stream. As each component is connected with Buffers, the
>doGetNextFrame retrieves the next frame to send from there. If no frame
>exists NULL is returned.
> 
>If within the doGetNextFrame function there is a loop such that it
>waits for a non null value (Polling the buffer), everything streams
>okay with high CPU loads. What I would like to do is make this a non
>Blocking piece of code as is suggested by the comments in FramedSource.
 
Basically, you need to make the arrival of new data an 'event', and 
process it within the event loop.
 
Without knowing more about how your data arrives, it's hard to say 
more.  But the following answer (from last November) should help you:
http://lists.live555.com/pipermail/live-devel/2005-November/003543.html
 
 
        Ross Finlayson
        Live Networks, Inc. (LIVE555.COM)
        <http://www.live555.com/>

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.live555.com/pipermail/live-devel/attachments/20060331/bff9e3fe/attachment.html