Re: [Deinterlace-discuss] dTV eating 100% of the cpu

[Mark R. <ma...@ot...>]

Hi,

Try dTV version 2.0.2 to see if it fixes the problem with 
2.0.1 not running with dTVdrv.dll ...

We did sleep 0 on purpose.  Doing sleep_interval of 0 makes dTV 
work more smoothly on some systems (including mine).  Normally,
you don't multitask with dTV.   It does drive some CPU monitors
crazy though!

We're open to new ideas, but performance is top priority as you
always know :)  ....  Some of us talked about interrupts, and we 
were unable to find a suitable interrupt.   Did you read about
the scan line counter ideas that was bandied about a few weeks
ago in the mailing list 
(Mailing List Arhives - http://sourceforge.net/mail/?group_id=7420)

One of the high priority changes to timing/sycnhronization is
being able to synchronize 24fps movie material properly to output
refresh rate.   At 72 Hz, 96 Hz, and 120 Hz, it is not properly
repeating each frame consistently 3 times each, 4 times each,
or 5 times each.  At 120 Hz refresh, the 3:2 pulldown is
doubled into 6:4 pulldown where movie frame are repeated
alternately 6 times then the next movie frame is repeated
4 times.   Ideally, at 120 Hz, movie frames should be repeated
5 times consistently.   

We've been thinking of synchronizing to 2.5 field time of
input (60 divided by 2.5 equals 24).  Basically, we want to 
synchronize output of a movie frame once every 2.5 input fields.
That will solve the judder problem at 72 Hz, 96 Hz, and 120 Hz.

This future update (by whomever decides to do this - perhaps you?)
will demand super-high precision.  We cannot afford to use a
non-zero sleep at all.   We need sub-millisecond level scheduling, 
so we will likely need 100% CPU time to ourselves for this.

Any ideas?   If you want me to forward you select previous emails 
from the mailing list, let me know, so I can get you up to speed
on the synchronization issues.

I'm also very sensitive to synchronization.  The CNBC stock ticker
is a great example.  Input refresh rate never "exactly" matches
output refresh rate.   So when output refresh is 60 Hz, the
CNBC ticker does a brief (hard to notice) jump once every few
seconds, since the input refresh is a fraction of a hertz
from the output refresh.   This synchronization gets slightly
worse if we use non-zero sleeps - noticeable to the trained
eye.



> the while loop scan the BT chip if a new frame is availlable. 
> You can see a Sleep with a parameter Sleep_Interval.
> By default (in dTV.ini), sleep_interval is 0.
> So all the cpu is eaten by this loop !
> By putting a value in Sleep_Interval (like 10ms), all the cpu is released.


_______________________________________________________________________ 
                                          ____ 
Mark D. Rejhon         Win2k.Linux.Win98  \  /  mailto:ma...@ot... 
http://www.marky.com/    C.C++.VB.Shell    \/   AlphaWorld Home 10S 15W 

"A friend is someone who will be there without asking anything of you. 
 A friend is someone you know that knows you, and accepts you." 
_______________________________________________________________________