[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
thing.
> 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
loop
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,
Toby
--
style)KURVE - Fotografie mit Biss.
www.style-kurve.de - info at style-kurve.de
Tobias Bindhammer, Uhlandstrasse 8, 89278 Stra?
01577/1751761
-------------- 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