On Wed, 6 Mar 2002, ZN wrote:
> I doubt that the Q60, GF etc. could be able to do it - not even come close,
> in fact. On a PC you need not merely 200+ MHz, make that 300+ (usually in
> the 350MHz region) to be sure there are no skipped frames for any of the
> commonly used data streams, and that's ONLY if there is considerable
> hardware support on the video side (scaling, triple buffering, etc.) and on
> the drive access side (DMA...). On emulated QLs, the required functions
On a multi-tasking OS, yes, because all the context switches, certainty
that the other task will be running in a different page than the page the
decoder will be running in, etc, causes significant problems when decoding
the stream. However....
...on a single tasking OS, or in this case an embedded app that does not
multitask, it is perfectly possible to get consistent sight and sound from
a DV to an output with no dropped frames, artefacts or clipping. This was
done on a 206MHz SA-1110. It would not have worked with for example linux
unless the speed was raised to 320MHz to compensate (which an SA-1110 can
do, if you put a heatsink on both sides by putting a cute lil hole in the
PCB right under it - no fans allowed!
> Using a tecnique called 'data stream decimation' it may be possible to
> decode a MPEG stream in a smaller resolution thus considerably simplifying
> the amount of calulation involved. With that approach, one thing is for
> sure: a decoding engine would have to be written from scratch and by
> someone very much knowledeable of DSP matters - so no recompiling here! The
> only question is how appealing it would be to play a DVD in a postage stamp
> sized window :-)
I know just the man for the job - my friend Hedley. He worked at OWL (a
division of Panasonic) and wrote the CODEC for the Replay TV.
However, the Goldfire and ARM-QL will not have the potential to do it. The
Goldfire would come closest though...
Dave
ql.spodmail.com
