[FFmpeg-devel] a64 encoder 5th round

[Bitbreaker/METALVOTZE]

>> +                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 
AVCodecContext.

Thanks for the further advices and hints so far!

Kindest regards,

Toby