On Thu, May 21, 2015 at 2:04 PM, Tom Butterworth <bangno...@gmail.com> wrote: > Hi Vittorio > > +++ b/libavcodec/dxtc_dec.c >> > > Couldn't the existing s3tc.c be refactored and extended instead of > rewritten from scratch?
there are a lot of limitations in s3tc, and it's quite unmaintained I went for the rewrite so that I could learn a bit about these formats, I could write it so that they don't depend on bytestream.h, and I employed the "dsp" style, so that whoever is interested may write asm in an organized manner (eg by putting an adequate implementation in lavc/x86 and adding the proper if (ARCH_xx) in the init function). >> +static av_always_inline void dxt13_block_internal(uint8_t *dst, >> + const uint8_t *block, >> + ptrdiff_t stride, >> + const uint8_t >> *alpha_tab) >> +{ >> > <snip> > >> + >> + if (color0 > color1) { >> > > No - add a parameter to indicate when the block is DXT1 and only perform > this check for DXT1: DXT3 always uses the 4 colour version. Interesting, there is indeed some code duplication. > As the treatment of colour is identical for DXT1, 3 and 5 with the > exception of the check for transparent black in DXT1, dxt13_block_internal > and dxt5_block_internal could share a common function to unpack the 4 > colours rather than duplicating quite so much code. I think you are right, which approach would you consider more effective? - all implementations should use dxt1_block_internal, leaving the 4 colour version intact - split dxt1 and dxt3/5 in two different groups - split and have one of the inner loops (the (color0 > color1)) in a separate function Thanks -- Vittorio _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel