[FFmpeg-devel] a64 encoder 7th round

Michael Niedermayer michaelni
Fri Jan 30 19:13:32 CET 2009


On Fri, Jan 30, 2009 at 06:15:36PM +0100, Bitbreaker/METALVOTZE wrote:
[...]
> >> Btw.: The reason why black pixels consume a part of the following pixel is 
> >> due to the type of transistors used in the video chip. There are 
> >> NMOS/HMOS-transistors that need too long to reach the desired output level. 
> >> So actually that phenomenon happens on every pixel, but as black has the 
> >> way biggest luminance distance to all other colors used on that machine, 
> >> here it gets very visible. So that more a c64 thing than a PAL thing.
> >>     
> >
> > C64 or PAL doesnt matter, these things should be considered IMHO
> >   
> That is and i do already by using a slightly brighter color as second 
> color. Also with twice as big pixels it is not as noticable as in hires 
> mode. In hiresmode however one should then dither/interlace always two 
> pixels wide, when it is about to mix with black. I considered that 
> already with a comment in my code. Still, it is not the main problem, 
> just as the dithering and such. Problem is the detail depth and size i 
> have to cope with such modes.
> > well, i see the problem but its not a problem because you can
> > * change the coefficients used in the ED dither
> > * do the dither in columns instead of rows (would produce horizontal lines)
> > * do it diagonally (might produce diagonal lines)
> > * use another form of dither, ED is not the only one, from the page i provided
> >   the anticorrelation dither is free of line artifacts but i dont know what
> >   this algo does so cant speak for it.
> >   
> * add your own dither table and be happy as well.
> I somehow have the feeling you seek for someone implementing all kind of 
> dither methods for ffmpeg/elbg? :-)

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 ...

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



> However digonally might work out, producing lines horizontally is no 
> option as well.

you can even decide pixel values in some random order

or look at dither as an optimization problem, that is to choose
pixels(x,y) so that a lowpassed pixels image is most similar to
the input picture.
with this you can just pick 2x2 pixel cells and bruteforce try to set
them to all values and pick the best and keep doing that until no
change in any cell leads to an improvment.


[...]

> > Well, i dont belive it is unreaistic :)
> > the code i provided above is supposed to write 4 equal elements (like one of
> > the colors of 4 consecutive chars)
> > depending on internal organization of bytes this maybe can even be changed to
> > write to 2x2 chars that is a square
> > A similar routine could write 4 different colors or indexes or other stuff to
> > 4 consecutive chars (my terminology is crap i know and i know i dont know the
> > mem layout ...)
> >   
> Memory layout looks like this:
> 
> char1
> byte1   line1 of char
> byte2   ...
> byte3
> byte4
> byte5
> byte6
> byte7   line 7 of char.
> 
> This repeats 255 times so we have 0x800 bytes used for the charset
> 
> then the charmaps follow:
> 0x28 bytes charmap for first row
> 0x28 bytes charmap for second row ...
> this repeats 25 times for 25 rows. -> 1000 bytes
> 
> 24 bytes padding (yet unused, but will be good for future use liek e.g. 
> sound)
> 
> next charmap
> Each byte in charmap represents the position within the charset * 8. Or 
> better to say it is a direct index to the block number.
> 
> in 5 col mode each charmap is followed by 1000 bytes color information 
> (only low nibble used) + 24 bytes padding

first, thank you for this explanation, could you put this on the multimedia
wiki? we collect information about all codecs there ...

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];
...

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?


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

There will always be a question for which you do not know the correct awnser.
-------------- 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/42957f52/attachment.pgp>



More information about the ffmpeg-devel mailing list