Well, I now have a much higher respect for pthreads and linux threads :)
The communication system I'm using for the majority of that player-proggy
delivers a message within 45 milliseconds on my computer...
Using a socketpair takes ~17000 milliseconds just to poll(..) to see if
there's data. Is there a better way?
I -need- to shave this ~17000 milliseconds off!
Incidentally, quicktimes take ~40000 milliseconds/frame to decode and
mpegs take ~200000+ milliseconds/frame.... 15fps only allows a maximum of
~66000 milliseconds per cycle. (I can understand with the quicktimes -
I'm using motion-jpeg compression and jpeg-style compression's never been
known to be efficient)
incidentally: (seperate threads)
sound playing: ~750us/frame
video rendering: ~7000us/frame unscaled; ~12000us/frame scaled
Basically, the movie decoders are too slow. Time to build new ones.
>From the license, Loki's plaympeg should do the trick *grin*.
BTW: Joysticks crash under GII/GGI. Any reason? (I -am- running a USB
joystick through the HID drivers, so it's entirely possible it's a kernel
bug - I'll look some more)
I haven't removed the code from the ggiplay (should I change the name?)
source.
Oh, and I quelled a -nasty- bug in the videorenderer where it would
continuously re-render graphics regardless of the queue... so folks who
found it too slow might find it works now. But if anyone can direct me to
a half-decent MPEG/2 library, tell me, eh? :)
G'day, eh? :)
- Teunis
