If it was Erlang, I'd say go ahead and create a process per frame, and
you'll see tremendous speed, especially with multicore machines. But
as Norm points out RB is not thread safe, and only uses once core. So
you're probably stuck with optimizing your processing code :-)
--
dda
On Thu, Jul 31, 2008 at 9:26 PM, Daniel Stenning <d0stenning@msn.com> wrote:
> I don't know much about movie "vsp" but in the audio world one generally
> tries to work on as big a block of audio "frames" as one can get away with
> as opposed to single frames wherever this is feasible.
>
> Depending on how much latency your app can get away with it is always better
> to send as big a number of frames in one go to the processor, so I would
> avoid a "one-by one" scheme unless it is absolutely necessary. Better to
> figure how many frames you can get away with sending to your de-interlacer
> in one go and do that.
>
> You might also want to consider the MBS pre-emptive MT classes if you need
> the power that this gives you, but writing code for pre-emptive threads is
> fraught with dangers so beware :)
>
>
> On 31/7/08 14:01, "Eric de La Rochette" <rblists@edlr.fr> wrote:
>
>> Hi there,
>>
>> I'm currently trying to implement a video image deinterlacing process.
>> After a short brainstorm I came out with to solutions.
>>
>> 1/ Handling this from the movie point of view only.
>> I subclass a thread and then put all the deinterlace process inside.
>>
>> 2/ Splitting this in two classes.
>> I create a 'deinterlacer' class that handles the deinterlacing of a
>> picture and send it back to the caller.
>> I subclass a thread that extracts the picture one by one and send it
>> to the deinterlacer to process it.
>>
>> What I currently need is the most efficient balance beetween speed of
>> process and maintanability of the code as I will need to refine the
>> deinterlace process in the future and may be rewrite the thread code
>> if enhancements have been done the the built-in thread model ;-)....
>>
>> My guess at this point is that the solution #2 would provide the best
>> balance, but I'm also wondering if the solution #1 will really be
>> tricky to maintain.
>>
>> Am I correct ?
>>
>> Eric.
>>
>>
>> _______________________________________________
>> Unsubscribe or switch delivery mode:
>> <http://www.realsoftware.com/support/listmanager/>
>>
>> Search the archives:
>> <http://support.realsoftware.com/listarchives/lists.html>
>>
>
> Cheers,
> Dan
>
>
>
>
>
> _______________________________________________
> Unsubscribe or switch delivery mode:
> <http://www.realsoftware.com/support/listmanager/>
>
> Search the archives:
> <http://support.realsoftware.com/listarchives/lists.html>
>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|