[FFmpeg-devel] a64 encoder 7th round

Bitbreaker/METALVOTZE bitbreaker
Fri Jan 30 12:38:47 CET 2009

> simple example:
> scene1          | scene2
>  F0 F1 F2 F3 F4  F5 F6 F7 
> your encoder will choose a charset for F0-F3 and another for F4-F7
> the second clearly is a very poor choice. F0-F4 F5-F8 would be better
> at no point is there more data to deal with

Scene cuts, fades and all that, they all look really nice with a static 
lifetime, i have encoded several videos and watched them. I exepcted 
problems here as well, but reality showed that it doesn't matter at all, 
i was surprised how even charset wasting wiperlike fades appear very 
smooth. That is also the reason why i didn't bother about such things, 
unlike other things like dithering. When switching over to 8 dithersteps 
things really improved a lot (compared to 4 steps).
At such low resolutions there are other things to take care. Also, so 
far the mode is rather generic on c64 side, whatever charset i send to 
c64, it will be displayed, no matter if i do any dither, do error 
diffusion, have a bad algo or a good algo to find optimal blocks, it 
will just be displayed. All i changed so far on the displayer over the 
last years was adding improved code for loading largers blocks from the 
net, and give it a pause and slow motion function. Same goes for the 
ecmh mode, all i need to do is sending/setting the charset being used 
and then go on as usual. Thus i am rather free in my way i encode things.

> so if your input flickers your decoder will remove it
> and if it doesnt flicker it needs a hardcoded list of color pairs to
> avoid generating flicker

The decoder?! You mean i should avoid flicker on c64 side? How is that 
going to happen, while we try already to squeeze out cycles in the 
discussion fuerther on? I better avoid producing flicker during 
encoding, by using a list of suitable color pairs, yes. And to make them 
suit even more, i "transform" the picture, else fitting colors get rare 
and gradients may get sharp edges. And before you ask: I tried (see 
attachment noprep.jpg) colors appear nice, but infact it is flickering 
excessively, as well as quite some blocks/edges are formed.

> you consider gamma?
> flicker?
> luma chroma crosstalk from PAL?
> lowpass filter effects the probably somewhet  primitive electronics used to
> modulate PAL likely cause?

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

> You did not show an example of a properly done comparission on the C64
> nor did you provide any theoretic explanation why it would be worse

See attached .gif. I expanded it to double width, just as it would be 
displayed in multicolor mode. There are lots of vertical structures that 
build lines/blocks and those get very visible and distracting, even on 
my TFT. Even more when you zoom in a bit (remember, 320x200 on a 14" 
screen, so pixels are BIG). Having a pattern of alternating vertical 
lines is no good idea for another reason. Due to the PAL signal on every 
colorchange a bit of distortion (depending on the color combination) is 
added, so the lines appear even more pronounced. It is a bit like a 
sharpening filter (btw, this looks even worse in hires mode).
Also, if doing error diffusion beforehand, that would mean a waste of 
blocks, if i do it afterwards, it would mean a lot of blocks would not 
fit in regards to their dither pattern. There might of course be 
algorithms to work around these problems, but alas, why should i bother 
if it looks worse?

> You dont have to of course and it of course is a lot of work but then
> designing a codec or encoder is alot of work if done well.
> If you think its ok to just write something that you belive is best
> without any testing that it actually is, well thats fine but keep in

Without testing? As said, I do graphics on a c64 since decades now, i 
know how to handle that few colors and how they appear, how to do proper 
antialiasing, gradients and dithering with them, so it looks good on a 
c64. And i also know what will definitely look ugly and hurt ones eyes. 
Even if i can't proof every detail of my collected experience, i still 
have that experience and can take advantage of it, and thus exclude 
certain methods from the beginning to save time.

> just to clarify i meant
> dst= get_from_net()<<8;
> x= get_from_net();
> do{
>     a= get_from_net();
>     dst[x+0x0] = a;
>     dst[x+0x4] = a;
>     dst[x+0x8] = a;
>     dst[x+0xC] = a;
>     x= get_from_net();
> }while(x)
> i dont think your code is equivalent to that

Then let's give it another try:

    lda $de00
    sta a1+1
    sta a2+1
    sta a3+1
    sta a4+1
    ldx $de01
;24 cycles setup
    lda $de00
a1 sta $0000,x
a2 sta $0004,x
a3 sta $0008,x
a4 sta $000c,x
    ldx $de01
    bne loop
;+ 31 cycles per loop

And what shall i do with that kind of loop now? It can most of all fill 
bigger areas (mininum 16 bytes) with the same value/pattern, yes. As for 
the charset you will most likely have 8 consecutive bytes like $00 or 
$ff, in lucky cases maybe 15, as due to optimal charset usage the same 
block will not appear more than once. Same goes usually for the charmap, 
and as for the colorram (if used at all) i tried RLE already, by using 
the unused highnibble for the amount. It did not perform better.
In addition, you still need a decision wether your loop or normal 
loading shall be used. How will that look like? Comparing every byte to 
find an escape sequence? (so that is expensive). So your loading routine 
must best be able to decode a complete block (whole charset/whole 
charmap/whole colorram) at once to save such overhead.
All that would only be worth the effort if it saves ~1/50s in time. That 
is where i could switch to a higher framerate and wait for one less vsync.
So i don't know what you want to achieve. Frames are already small, 
loading is already very fast and more than sufficient for the modes i 
use. In case of bigger frames (for e.g. when sending whole bitmaps) 
loading as well as decoding will be too slow anyway to obtain a good 
framerate. It is just the wrong direction to search for improvements. It 
simply is, that not a few more bytes bring better quality, but huge 
steps would. The next quality step after multicolor charset would be 
sending a whole bitmap instead, but that would be 8kb. If you are able 
to load+decode it in the time i would normally load 3kb, that would be 
awsome. But i'd just say, it is unrealistic :-)

Oh, attached you also find a snapshot from a video loop that i put 
together, it shows multicolor mode at a charset lifetime of 6 (else i 
have alignment issues with the video banks when i play things directly 
out of RAM). It can be loaded/started as snapshot in VICE c64 emulator 
(http://www.viceteam.org/). Maybe you get a better impression then on 
how things look like.

Kindest regards,


      style)KURVE - Fotografie mit Biss.
   www.style-kurve.de - info at style-kurve.de
Tobias Bindhammer, Uhlandstrasse 8, 89278 Stra?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.gif
Type: image/gif
Size: 772 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090130/9f806e09/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: testvideo.vsf
Type: application/octet-stream
Size: 69708 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090130/9f806e09/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noprep.jpg
Type: image/jpeg
Size: 18351 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090130/9f806e09/attachment.jpg>

More information about the ffmpeg-devel mailing list