[Open-graphics] decoding video in real-time

[Vesa Solonen]

On Sun, 18 Mar 2007, Attila Kinali wrote:

> Date: Sun, 18 Mar 2007 14:34:05 +0100
> From: Attila Kinali <attila at kinali.ch>

> No. Implement fast DMA, upsampling and YUV->RGB support in
> hardware. Make those things easily availbale to user space
> programms. Make use of these and you'll get the needed performance.
>
> I also plan to have a look whether a deinterlacer and inverse telecine
> filter could be implemented reasonably well in hardware. Both would
> allow to skip one filter stage that is currently performed in
> software and leave it to the hardware.
>
> I think, properly designed, a deinterlacer should be possible to
> be done in OGA1 (needs to access a few lines in parallel, but i
> think it can be pipelined). I'm not so sure whether an inverse
> telecine filter can be done. But then again, inverse telecine
> isn't that CPU intensive as deinterlacing.

Have you thought about the problem of runtime synchronizing of vertical 
refresh to video frame/field rate? DVB and other externally timed streams 
would need this, to be playable at synchronous/coherent frame rate (50 
or 60 Hz). On local files the playback timebase might be video card, so 
this is not necessary.

One can easily test the results using local files on some laptops and 
mainboards which have only one clock oscillator and all the other clocks 
generated by PLLs. There are no clock drifts to compensate between system, 
audio and video. My IBM T30 with Ati 7500 seems to work fine as built-in 
panel works at 50 Hz. It's just on the verge being underpowered on 
Kubuntu's Kaffeine with GreedyH and color upsampling filters enabled (1.8 
GHz model). Main workstation (Gentoo) AMD64 3400 with Ati 9200 @ 50 Hz 
ViewSonic panel will drop fields more often even though Kaffeine uses 24% 
and X 19 % of cpu, so it is different clock domain problem. Test clips 
were DVB-grabs with real interlaced content and DV-video.

I'm eagerly waiting for the 'really working' (tm) video hardware...

-Vesa