[FFmpeg-devel] a64 encoder 7th round

[Michael Niedermayer]

On Fri, Jan 30, 2009 at 08:08:30PM +0100, Bitbreaker/METALVOTZE wrote:
> 
> > I always try to hmm convince patch authors to contribute as much usefull
> > code as possible :)
> > swscale still does ordered dither, i know other variants look much
> > better as single images (i tried it) but i had some problems with videos
> > on TFTs, also my code was not clean and just doing grayscale, no color, not
> > considering gamma ...
> >   
> Pfew. I am not sure if i am the right man for that. Useful code will be 
> submitted, more modes, a64 container, isn't that enough? ;-)
> > gamma is very important when dithering with few colors no matter if ordered
> > or others, the reason is
> > a 50/50 mix of black and white pixels just doesnt produce a shade similar
> > to 50% gray but dither code generally assumes it does
> >   
> i mix black with dark gray, dark grey with middle gray and so on at 
> least. Better than black/white, isn't it?

of course but thats 4 colors over  1D, the color cube has 3D and you
know better than me what limitations there are with selecting colors
the distances of the colors will thus be larger thus the non linearity
error will grow


[...]
> > first, thank you for this explanation, could you put this on the multimedia
> > wiki? we collect information about all codecs there ...
> >   
> I'll do so, but need an account first. No idea if i can just register 
> one, am a bit in a hurry.Will also add information about the other 
> formats that might help as well.

for wiki accounts you need to "talk" to mike melanson


> 
> > now a few questions, i hope iam not too annoying
> > the low nibble is either 15 or 8 if i did RTFS correctly
> > do you have 64 byte left for a LUT?
> > if so you can do some code equivalent to
> >
> > x= read_net();
> > dst[0]=lut[x  ];
> > dst[1]=lut[x+1];
> > dst[2]=lut[x+2];
> > dst[3]=lut[x+3];
> > x= read_net();
> > dst[4]=lut[x  ];
> > dst[5]=lut[x+1];
> > dst[6]=lut[x+2];
> > dst[7]=lut[x+3];
> > ...
> >
> >   
> Gotta see tomorrow if that works...


btw, if it does allow reducing bitrate without loosing framerate i know
how to extend this to 8 instead of 4 elements with just 263 bytes of LUT
and actually we need just 19 bytes LUT for the 4 element case
more precissely
15,15,15,15, 8,15,15, 8, 8,15, 8,15, 8, 8, 8, 8,15,15,15



> 
> > this of course can also be done as loop and using that y register, in that
> > respect do you maybe have a link to docs listing the number of cycles per
> > instruction?
> >   
> For example here: http://www.metalvotze.de/content/c64_internal4.php

danke

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090130/c896a85e/attachment.pgp>