Re: [Mjpeg-developer] clamping policy difference between `lav2yuv` and `smilutils`

[Stefan M. F. <st...@sf...>]

Hi,

>> There's a speed/quality difference between decoders.
>
Sorry for this, I know we're not on the Kino-devel-list... But I hope
I'm not the only one using it...

I have had the chance to do the following: Encode and Decode a DV-Stream
using several encoders/decoder multiple times. That is decode it after
that encode it again with the same codec (This forms "one step"). After
reaching 10 Steps I compared the quality I got in the final .DV-file to
the original (visualy only).

Canopus DV-Codec   : no(!) visual degration when viewed unzoomed
                   : degration only visable when 2x zooming and
                   : comparing pixels... slightly blurred(??)

ffmpeg DV-Codec    : rather hefty degration but remains usable
                   : you can't see the difference on a TV-screen...

Kino-2pass(libdv?) : extremly ugly, blocks over blocks.
                   : unusable, even on a TV-screen...
                   : Was ugly after two(!) steps, already.
                   : I should have been stopping there.

Kino-1pass(libdv?) : absolutely unusable after two iterations.
                   : I decided to stop there. I did not wan't
                   : to know how bad it is after 10 iterations.

This leads to a question: As the Canopus-Codec is not available under
linux, can kino be forced to either use uncompressed-raw-data for
intermediate frame storage (FX-Processing) or at least to use the ffmpeg
DV-Codec?

Stefan

PS: why isn't ffmpeg the default encoder/decoder for kino? Does this
have a reason?

-- 
Gnomemeeting/Netmeeting: callto:ils.seconix.com/st...@sf...
ICQ: 131490319