[vdr] Re: Deinterlacing

["Reinhard Walter Buchner" <rw.buchner@freenet.de>]

Hi Emil,

> On Fri, 18 Jun 2004 21:56:21 +0200, "Reinhard Walter Buchner"
> <rw.buchner@freenet.de> wrote:
>
> > Sorry, but S-Video is about the worst way to transfer video signal. Even
> > FBAS is a much more robust way of sending video across a line. Long
> > Y/C lines introduce a delay between Y&C and if you don't have a
> > GOOD way to compensate this, you'll never have a quality signal. You'll
> > see this as color smearing and edge overblend, plus if you watch a test
> > picture, you will notice a LOT of flickering. Any O-scope can prove
> > this ;o))

> Be sure that the Y/C delay is compensated in the lumagen. I have
> absolute no problem with this. Not at my setup.

The problem is that ANY kind of "fiddeling" with the video signal
will degrade its performance. This introduces background noise
at least. At worst it starts smearing colors or causes pixel shift
(a problem of the digital display units). The problem is that a
digital PJ isn't good enough (sorry) to truely show the problems
in the video chain. A digital PJ for example needs to rasterize the
picture information to fit the LCD panel. This rastering step is
what leads to the effect known as screendoor. Exactly because of
the reproduction quality and the minimal amount of "fiddeling"
that is done to a video signal in a CRT is what makes them highly
desireable for HT geeks. CRTs are still in use by the NASA or
Lufthansa training centers for exactly those reasons. My 8500
Ultra costs in excess of 50 000 Euro if I had bought it new. I had
a look at several digital models beforehand (price range up to 10K
Euro) and none provided really satisifing pictures.

I know you are a VDR geek (meant in the nicest of ways!), so I
really wonder why you bought a digital display unit ;o))

> > RGB is the only way to go.

> Don't agree, especially not when you have cable runs of 10+ meters and
> with the output of the DVB-S card. The image is just to noisy.

Emil, I was talking in general here (but including the DVB ;o)). RGBHV or
RGBs (DVB) is the best way to go in ANY video setup, simply because
this has the least amount of transcodings done to the signal. Any output
device on this world (be it TV, CRT, DLP, D-ILA, LCD or computer
monitor) is an RGB device. You minimize crosstalk because you are
running a dedicated line for each color and a seperate (or 2) lines for
the sync signals. This is the cleanest way to transport video. Even YUV
is worse, although the difference may be subtle, since the human eye
can compensate the losses of YUV..

I WILL believe you that for you, S-Video is better. However, this
depends on how your PJ processes the signal AND what is in the
video signal path inside your PJ. I have seen a lot of DLPs with
internal scalers that can be bypassed, but they use electronic
switches (chips instead of relays) which reduce bandwidth and
degrade video quality

> > Of course you'll need a viewing unit
> > that is capable of displaying the problems in the first place
> > (and a digital unit isn't one ;o)) Of course, I realize that
> > we are talking about lowly DVB
> > transmissions, so it might not make that big a difference.

> That is exactly what I am saying. Anyway, the DVB-S card is extended
> with a SDI interface all problems are gone. ;-)

No ;o)) because transponder bandwith is expensive. That's why a lot
of films are shown in 352 x 288 and you can hardly call that quality ;o))
Secondly the MPEG-2 algo simply introduces artifacts, because it
cuts down on the information in the stream. Adding a digital
transmission path to the DVB output stage won't change this root
problem. HDTV, once introduced, will change some of this, but our
beloved FF cards (actually the AV711x chip) can't handle HDTV,
causing it to crash. So we will need to rely on Convergence or
some other company to write a firmware for newer, HDTV capable,
DVB-S cards. I don't know if *that* will ever happen.

Greets,
Reinhard


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.704 / Virus Database: 460 - Release Date: 12.06.2004