On Fri, May 15, 2015 at 4:09 PM, Vittorio Giovara <[email protected]> wrote: > Hi, > following the positive trend as of late, here is a shared discussion > on a proposed API. > > > There are a couple of formats that are based on texture compression, > usually called DXTn or BCn, and described here: > http://en.wikipedia.org/wiki/S3_Texture_Compression. Currently in > libavcodec only txd uses this style, but there are others I am working > on, namely Hap and DSS. > > What I thought while working on them (and later found out actually > being of commercial interest) is that the texture could be potentially > left intact and rather than being decoded (or encoded) internally by > libavcodec. The user might want to skip decoding the texture > altogether and decode it him or herself, possibly exploiting gpu > acceleration. > > Unfortunately these formats often employ additional compression or add > custom headers so the user can't just demux and accelerate the output > frame as is. Interested codecs could let the user choose this with a > private option. > > > There are a couple of strategies here. > 1. Introduce a pixel format for each texture: this has the advantage > of getting appropriately-sized buffers, but in the end it would > require having a different pixel format for each variant of each > texture compression. Our users tend to dislike this option and I am > afraid this would require us of constantly adding new texture formats > when support is added. > 2. Introduce a single opaque pixel format: this has the advantage of > not having to update API at every new format, but leaves users in the > dark to what the texture actually is, and requires to know what he or > she is actually doing. > 3. Introduce a single opaque pixel format and a side data: as a > variant of above, the side data would contain which variant of of the > texture and would let the user know how to deal with data without > anything special.
Users knowing what they are doing is usually a good thing! Instead of littering the list with pixel formats for various obscure texture formats, I would greatly favor #2/#3 > 4. Write in the normal data buffers: instead of filling in rgba > buffers with decoded data, the raw texture could be written in > data[0], and the side data would help understand how to interpret it. > This could be somewhat hacky since it's not something users would > normally expect. > 5. Introduce refcounted side data: just write everything in a side > data buffer and let the user act upon it on demand. Similar to idea 3, > but without introducing new pixel formats. Could be potentially > 6. Write in the 'special' data buffer : similar to what is done for > paletted formats, write the texture in data[1], so that normal users > don't have to worry about anything and special users might just access > the appropriate buffers. > > > Every idea has some drawbacks and some benefits, we should try to > trade off between new APIs, maintenance and actual use cases. In my > opinion 5 is interesting but probably overkill for this usecase. I > like 3 for it simplicity and ease of use. > What would other lavc devs think is the more appropriate one? What > about our API users? _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
