|
From: Arne S. <ar...@sc...> - 2000-11-16 16:26:21
|
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
|