[FFmpeg-devel] a64 encoder 5th round
Sat Jan 24 11:02:45 CET 2009
>> + row1 <<= 2;
>> + if (prep_dither_patterns[dither][y & 3][x & 3])
>> + row1 |= vals[index2];
>> + else
>> + row1 |= vals[index1];
>> + }
>> + charset[y] = row1;
> could be simplified slightly with put_bits()
Yes, that would indeed look nice here, but can only do so as long as the
pointer for charset stays untouched by put_bits (as i might do this part
of code twice in 5col mode, see charpos-- a few lines below that). I'll
figure out and change it if applicable.
> besides the way you do dithering is uncommon ...
> i assume you have a reason why you dont use ordered dither, or one of the
> error diffusion dithers? last should be vastly better except maybe some
> flickering between frames and the need to consider already set patterns
> of neighborin blocks ...
On the one hand, pixels have a aspect ratio of 2:1 in that mode. Also
those dither patterns i use are more or less best practice on c64
regarding doing for e.g. handpixeled graphics. Error diffusion dither
can look good in hi resolution modes at times when i can make use of
full 320x200. As you mentioned already as well, i face additional
problems regarding neighbour blocks when using that kind of dither. So
worse case is to have a 4:1 big pixel. In that way, the fixed patterns i
use might have the smaller footprint regarding complexity and codesize?
Flickering is not too much of a problem in this mode, but on the
upcoming ecmh mode (but let's finish this first :-) ) where i interlace
the symbols and place the same amount of pixels on each frame of the
interlace to avoid a change in luminance areawise. Also c64 displays
things in PAL (at least in Europe, NTSC versions are also available) and
some other "nice" features are added to the resulting pic (for e.g.
pixels nearly vanishing after a black pixel). So that are things that
can only be seen on the real machine, they don't appear in the
Emulators, though there is PAL emulation available for output.
> A muxer cannot access the private contxt of the encoder
I'll strip the muxer of as suggested, however this issue can be fixed
anyway, as i can get the needed values also from quality set in
Thanks for the further advices and hints so far!
More information about the ffmpeg-devel