[FFmpeg-devel] a64 encoder 7th round

[Michael Niedermayer]

On Tue, Jan 27, 2009 at 03:38:58PM +0100, Bitbreaker/METALVOTZE wrote:
> > why do you need so much space to store a single bit per char?
> > also if the chars take much space, why not simply reuse them from
> > the previous frame and just update some?
> 
> We discussed about similar things already. On c64 side the easiest, 
> smallest (we have 64k ram, including video memory and so on) and fastest 
> way is to just load a fixed size per frame continously. Shifting bits 
> back to reconstruct the colors is way more expensive, same will go for 
> delta on a charset. In that cases i can't hold good framerates.

so you claim that copying 256 chars is faster than copying none ?
if not a system that choose per frame if it used the last or used new
ones would be better, a fixed 4frame pattern hardly is optimal.

now if copying nothing is faster than copying all what about copying 2
or 5 or 10 ... there is a cross over point of course where the per char update
would be worse and at that point you just switch to updating all.

besides this, when nothing changes in a row and the used chars are still
available there similarly is no point in storing it twice.
and no, i really dont see any shifting here, its just a copy from a different
point or am i misunderstanding something, i know very little about the c64


> 
> > from this i assume you use the 4color per block 160x200 mode, cant this
> > allow any 4 out of 5 colors, i mean not just the 4 darkest/4 lightest?
> > also i think your code should not downscale 320->160 but rather require
> > 160x200 as input.
> 
> Multicol is natively 160x200 yes. But best would be then to require half 
> the width being offered to keep it open for the user to choose a proper 
> aspect ratio. If that is possible i'd implement it. Also if croping to a 
> certain size is possible natively, i could save code of course. However 
> when being displayed the multicolorpic of course has the same width than 
> a normal 320x200 pixel pic again. So i am not too unhappy with the yet 
> solution. It is a few lines of code and in its yet state with using 
> elbg, it really performs more than fast (encodes ~120fps on a AMD X2 4000+).

160x200 with display aspect 4:3 is no problem, just see sample_aspect_ratio



> 
> Back to the mode: what i use is charset, in that case you can choose 3 
> fixed colors for the whole frame, not per block.

didnt i read somewhere that there was some kind or interrupt per row/line
from which various things could be changed?


> Just the 4th color can 
> be chosen per attribute cell (colorram). Here also restrictions apply 
> when using a charset instead of a bitmap: the highest bit indicates 
> wether the current char is displayed as multicolor or 2 color (then 
> hires) char.

so why do you force it always to multicolor?
if you just copy the stuff anyway, the encoder could choose per attribute
cell which is better ...


> So i can only use colors 0..7 for colorram.

with this limitation a pure multicolor encoder should do the following
   for each frame try all 3 fixed color triplets out of 16 that are
   560 full frame encodes, isnt going to be terribly fast but it should
   be easy to skip some of these triplets.
   for each block try all of the 8 colors and then from the 4 choosen
   colors select per pixel colors with error diffusion dither choosing
   the best block with sum of abs diff in dct domain.

this encoder could support rgb24 and gray input, for gray it would
limit itself to a subset of colors and be faster ...


> Making things 
> colorful gets really hard then and usually the result looks very blocky.

did you try above? :)


> if i'd use bitmap i could choose one background color out of 16 per 
> frame and 3 out of 16 per attribute cell. But a whole multicolorpicture 
> is 10kb in size. Loading speed is too low to achive a high framerate 
> then. Compression? See above, even slower :-)

I dont know the C64 internals so its difficult for me to judge what is doable
and what not but i do not entirely belive you :)

if i took a wild and likely wrong guess that things where stored in
4 bytes (char index, 1. color, 2. color, 3. color)
then some decompression in C could look like

uint8_t color[3], index;
for(){
    count= read_byte;
    color= read_3bytes;
    for(count--){
        *dst++= read_byte;
        *dst++= color[0];
        *dst++= color[1];
        *dst++= color[2];
    }
}

this would be too slow?

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I wish the Xiph folks would stop pretending they've got something they
do not.  Somehow I fear this will remain a wish. -- M?ns Rullg?rd
-------------- 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/20090127/ff152dda/attachment.pgp>