RE: [libdv-dev] Re: [libdv - Open Discussion] Quality

[Arne S. <ar...@sc...>]

Applications using libdv, such as my Kino program, would need both speed 
and best quality (not necessarily at the same time though).

During editing the user want speed and during conversion to other formats 
the user wants best quality images as an input, so this should be user 
defineable in my opinion (a parameter).

I'm not even close to conversion things with Kino right now, so currently 
I'm most interested in speed. I tried the quality parameter in playdv.c a 
while ago but it did not improve the speed more than some ten percent (I 
was expecting powers of ten :-).

What about half or quarter size image areas? The 720 * 576 player area in 
Kino is way too big anyway. Many Windows programs use only half the size.

Arne

-----Original Message-----
From:	Charles 'Buck' Krasic
Sent:	Wednesday, November 15, 2000 9:54 PM
To:	rb...@us...
Cc:	lib...@li...
Subject:	[libdv-dev] Re: [libdv - Open Discussion] Quality


In the libdv - Open Discussion form, rb...@us... writes:

> Firsts off, hats off to you folks for the endevour, I have been
> waiting for something like this lib for a long time.

> I am looking to get super high quality frames from a DV stream and
> the playback speed is not important. I started to play around with
> some of the settings, but have been unsuccessful so far (a little
> rusty on my DCTs).

> Is is possible to get the image quality up to par with a hardware
> decoder with libdv? Is so, how could this be accomplished?

First, are you using a current version of libdv from CVS?

There were some major bugs fixed recently that have significant impact
on quality.  If yes, and it's _really_ high quality you want, read on...

If you don't care about speed at all, the easy way is to turn off
assembly and MMX.  Set USE_MMX_ASM=0 in the Makefile.  It will be
run about 10x slower, but you should get full quality.  Except
perhaps, for the color conversion.

>From there, we have two major issues to discuss:

  A) How do we build diagnostic harness that allows us to measure
     the quality of our results?

  B) What are the sources of quality loss?

I won't go into A just yet.  For B, here are some thoughts off the top
of my head:

1) DCT.  The MMX version we are using is imprecise.  Intel published
   an app-note on how to do better (i.e. meet IEEE DCT tolerance), and
   GPL versions of the newer, more precise, DCT have appeared in
   source code distributions for VirtualDub and Flask.  We should be
   able to integrate these quite easily.

   The 248 IDCT appears to be unique to DV, and so I coded that
   myself.  At the moment, I don't believe there is a quality
   sacrifice there, as it is still quite slow.  But it needs to
   be verified.

2) Weighting.  With ASM enabled, libdv merges the DV un-weighting
   with the first stage of the DCT calculation.  This saves
   computation, but sacrifices precision.

3) Color conversion (YV12.c, YUY2.c, rgb.c).  Except for the case of
   IEC PAL DV (4:2:0 sampled), we have to do some kind of color
   conversion before display.  Our code generally favours speed over
   accuracy.  The difference occurs when a target value is logically
   derived from some combination of source values.  Our code generally
   takes the approach of using one of the source values directly.  For
   example, if a target color value is logically defined ocr = 1/4
   icr0 + 3/4 icr1, our code does ocr = icr1.

Now, how much do these things affect quality.  To really know, we need
to address A.

-- Buck

ps I've moved this discussion from the forum to the mailing list.  I'm
   thinking about removing the libdv forums actually, as they are low
   traffic, and pretty redundent given the mailing list.















> many thanks,
> Roman

_______________________________________________
libdv-dev mailing list
lib...@li...
http://lists.sourceforge.net/mailman/listinfo/libdv-dev