[FFmpeg-devel] a64 encoder 7th round
Fri Jan 30 18:15:36 CET 2009
>> The decoder?! You mean i should avoid flicker on c64 side? How is that
> i meant the encoder of course, sorry
Okay, it does in ecmh mode, where flicker may appear.
>> How big is the improvement you expect when all this is implemented? I guess
>> keeeping it easy to achieve nearly the same result would also be a good
> i dont know at all by how much things can be improved with these ...
> but not considering something isnt going to make the result better
The problem is the restrictions i have in size and in the mode. If i'd
be able to transfer frames with 33kb each at a framerate of 25, i could
do quite amazing graphics on the c64, with 16/16 colors per attribute
cell, hires resolution and ~ 77 goodlooking interlaced color
combinations. In that case one might think about tricks like exchanging
colors with other of same luminance in certain cases, or doing just
single pixels of ugly combinations that add not too much flicker. That
improves quality, but i'd say in a range of ~5%, if at all. Then also
certain tricks are applicable to do even more deflickering and such. I
added all that to that to a converter for a new c64 graphics mode. But
that mode uses even more memory. Btw. that here we tried also error
diffusion on some samples, there was only one pic where we were unsure
which version looks better, the rest was all dithered in a kind of
However i have only 4 colors out of 16 for the whole frame + chunky
pixels in the yet case. So most of all one would wish more colors and
details, the rest i'd say is negligible.
>> 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? :-)
However digonally might work out, producing lines horizontally is no
option as well.
> I think dither should be done during ELBG, that way the dither pattern of
> blocks where known and other blocks could be dithered in a way considering
> their surroundings
I made some tests what happens when i dither after albg, and in seldom
cases it can happen i end up with 2 similar chars in my charset.
Something i can live with :-) I don't think i'll touch that elbg, though
i have downloaded the respective paper for that i'd say i have catched
the overall idea, but not much else.
> 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:
byte1 line1 of char
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.
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
> 1. you can set any goup of 4 bytes to arbitrary values (relatively fast but
> slower than currently)
> 2. you can set any group of 4 byes to equal values (likely a little faster
> than currently and needs 1/2 the bitrate)
> 3. you can leave any group of 4 bytes equal to what it was 4 frames ago (VERY
> important because in normal videos things likely dont change that much from
> frame to frame)
In a frame you can use ~ 18700 cpu cycles. So that is about the amount
you need to save by you algorithm permanently compared to plain loading
for 0xa00 bytes. Go for it :-)
More information about the ffmpeg-devel