[vdr] VDR with S2API (update)

Nicolas Huillard nicolas at huillard.net
Thu Dec 11 09:55:28 CET 2008


Karl Glatz a écrit :
> Of couse you can, either with xineliboutput, xine-vdr or softdevice.
> But the disadvantages are clear: Modern GPUs support more than the OSD
> provided by VDR (even older gpus do that).
> So none of these Output-Plugins will face the real problem: The OSD is
> (mostly) limited to work with FF cards.
> Many problems occour if you plaing a .avi file with xineliboutput, which has
> a lower res than the TV - the OSD gets stretched and is nearly unreadable.
> But thats only one of the problems with the OSD - its OK for TV, but it
> could be mutch better.

Softdevice can already do a clean transparent OSD, independent of the 
video resolution, using hardware blending. Xineliboutput too.
The dirty software transparency is an output problem (specially a Xine 
architecture problem).
OSD is really clean on a cheap CLE266.

I think the only OSD limitations in the core VDR are :
* size of the OSD : pixel width/height
* a single OSD per VDR instance
I specially like the way the OSD is treated : an overlay over the live 
video.
VDR limitations will go away with current improvements. OSD on recent 
graphic cards will also improve as hardware video decoding is 
implemented at the driver level. For instance, the HUD OSD display in 
xineliboutput requires a compositing window manager, really new 
hardware, X, etc. etc. This is absurdly complex, when you know that 
DirectFB can do that since many years on really cheap hardware, with 
much less code. Xine's XXMC can also do that for free.

KISS has always been VDR moto. I'm waiting for the rest of the display 
chain to downgrade to the same level of simplicity, then I'll switch to HD.
BTW : I never owner a FF card, and I'm perfectly happy with it. Hardware 
decoding wih a software device plugin has always been OK for me (say, 
since 2004).

-- 
NH



More information about the vdr mailing list