> they're written to be correct, not fast. AOM dev here. I'd love you to be right, but that's unfortunately not the case. They're written to improve VQ. Regar

> they're written to be correct, not fast. AOM dev here. I'd love you to be right, but that's unfortunately not the case. They're written to improve VQ. Regarding the "written to be correct" part of your sentence: There's no emphasis on correctness. For monthes, aomenc has been accidentaly using different transforms sets for 8 bit and 10 bits. It also used to compute its RDO based on the legacy probability model (non-CDF) although the result was binarized using the new one (CDF)). Moreover, serious regressions (decoder can't decode the encoder's output, lossy lossless) are introduced almost every day (!), fixed the next day. Now, regarding the "not fast" part of your sentence: There's been a lot of work on SIMD (Current aomenc performance is measured with SIMD optimizations). Actually, the code features complex mechanisms (C header file generation from Perl scripts at configure time) to handle the dispatching between the optimizations. To make the matter worse, almost all the pixel prediction code is physically duplicated in two versions: the generic code that uses 16-bit pixels, and the 8-bit optimized code that uses 8-bit pixels. All of these are actually huge hindrances to performance-unrelated developments.