On Thu, May 21, 2015 at 2:04 PM, Tom Butterworth <[email protected]> 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
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
