On colourspaces and such
I think current situation with pixel formats is brain-damaged as well. You have a list of pixel formats longer than two arms and yet it’s insufficient for many use cases (e.g. Canopus HQX needs 12-bit YUVA422 but there’s no such format supported and thus 16-bit had to be used instead or ProRes with 8- or 16-bit alpha channel and 10-bit YUV). In this case it’s much better to have pixel format descriptor with all essential properties covered and all exotic stuff (e.g. Bayer to RGB conversion coefficients) in options. Why introduce a dozen IDs for packed raw formats when you can describe them in uniform way (i.e. read it as big/little-endian, use these shifts and masks to extract components etc.)? Even if you need to convert YUV with different subsampling for chroma planes (can happen in JPEG) into some special packed 10-bit RGB format you can simply pass those pixel format descriptors to the library and it will handle it despite encountering such formats for the first time.
P.S. I actually wrote some test code to demonstrate that idea but no-one got interested in it.
The foundation library for your prototype is being prototyped =)
i imagine kostya on a horse attacking the windmill in don quixote.
i thought about splitting swscale into a billion pieces (one file per colorspace) and then only compiling in whats needed. but no one seemed to like that idea, and it would limit the colorspaces output. so probably not a good idea.
IMO swscale is hopeless and it needs a proper replacement with a completely different design. I had my proposal as well but it was ignored and I don’t think it will ever happen, in Libav because there’s nobody to work on it and in FFmpeg for the same reason plus one of core swscale authors will be against it.