[FFmpeg-devel] a64 encoder 7th round

[Bitbreaker/METALVOTZE]

>> 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 
>> option?
>>     
>
> 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 
ordered mode.
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:

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

> 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 :-)

Kindest regards,

Toby