[FFmpeg-devel] a64 encoder
Jason Garrett-Glaser
darkshikari
Sat Jan 17 19:20:38 CET 2009
On Sat, Jan 17, 2009 at 1:20 PM, Jason Garrett-Glaser
<darkshikari at gmail.com> wrote:
> On Sat, Jan 17, 2009 at 11:21 AM, Michael Niedermayer <michaelni at gmx.at> wrote:
>> On Sat, Jan 17, 2009 at 04:52:00PM +0100, Bitbreaker/METALVOTZE wrote:
>>>
>>> > reducing the colors before seems quite suboptimal, id rather convert each
>>> > fullcolor "char" with dithering to what is available afterwards or even
>>> > during the elbg code.
>>> >
>>> I have tried converting to a charset beforehand already some time ago,
>>> it can lead to other problems therefore, depending on what area i
>>> calculate the error. If i do a pixelwise compare, i gotta stick to the
>>> ditherpatterns or error goes up.
>>
>> you shouldnt be comparing pixel wise, because if a minimal per pixel
>> difference where the goal dither would always be inferrior to taking the
>> closest color ...
>> A likely better comparission is in 2d dct domain, with the low frequency
>> coefficients more strongly weightet. But maybe some psychovissual
>> comparission (x264 has some code for this ...)
>
> Are these charsets 8x8? In this case, here's one method that can be
> done with existing ffmpeg code that is a bit similar to what x264
> does:
>
> define complexity( block ) = hadamard8_intra8x8
>
> score (lower is better) = bit cost * lambda^2 +
> abs(complexity(src)-complexity(dest)) * lambda + ssd(src,dest)
>
> for some lambda.
>
> Dark Shikari
>
Oh, and where "dest" is the reconstructed block after encoding->decoding.
Dark Shikari
More information about the ffmpeg-devel
mailing list