Problem with persistent scaling/shifting in RADEONDisplayVideo()
Thomas Hilber
xorg-driver-ati at toh.cx
Tue Jul 29 04:47:15 PDT 2008
[something went wrong with my last post - 'From' as first word
in a line broke it?!]
On Tue, Jul 29, 2008 at 08:11:21AM +0200, Michel Dänzer wrote:
> On Tue, 2008-07-29 at 01:43 +0200, Roland Scheidegger wrote:
> > "high quality" and "RGB/PAL" doesn't really fit in the same sentence if
> > you ask me...
>
> Probably nothing beats a good TV when it comes to de-interlacing etc.,
> so it makes sense to preserve the broadcast signal as much as possible.
> I assume that's what 'high quality' refers to in this context.
that's exactly what I wanted to say. Of course our solution can't be
better than RGB-SCART itself.
But until now almost all VGA-based softdecoder solutions had to
deinterlace in software.
What makes not much sense if right after this the VGA CRT controller
re-interlaces the frame again. By doing so considerable CPU power is
wasted for getting even worse picture quality.
As mentioned above here are some further explanations:
http://linuxtv.org/pipermail/vdr/2008-July/017347.html
With my patch we can grab the untouched fields right after the software
decoder and route them straight through to the VGA port.
You then ideally display the fields on a native-interlace-capable
device like a CRT.
I've heard that more recent LCD displays also produce attractive picture
quality on SCART input. Though at the expense of huge amount of signal
processing circuitry.
On Tue, Jul 29, 2008 at 01:43:51AM +0200, Roland Scheidegger wrote:
> you ask me... Decent TV hardware should have at least VGA inputs, and
> if
> it's not CRT based it doesn't make sense in the first place...
for building a linux based PAL satellite recorder SCART is still
superior to VGA. That's why we want to play SCART over VGA. Of course
this changes if HDTV comes into play.
-Thomas
More information about the xorg-driver-ati
mailing list