[FFmpeg-devel] SWS cleanup / SPI Funding Suggestion

[Vittorio Giovara]

On Fri, Oct 13, 2023 at 6:55 PM Niklas Haas <ffmpeg at haasn.xyz> wrote:

> On Fri, 13 Oct 2023 19:42:44 -0300 James Almer <jamrial at gmail.com> wrote:
> > Anton wrote and pushed an AVFrame based API. It can surely be
> > improved/extended to use AVFrame metadata.
>
> Yes, this is actually a good idea. This API endpoint already has the
> "correct" signature, so we could definitely re-use it (and SwsContext)
> instead of introducing a new header file.
>
> But to be clear, even with this sws_scale_frame API, you currently still
> need to configure the SwsContext up-front - and that is the source of
> problems IMO. I think the entire family of
> sws_getContext/sws_init_context/sws_setColorspaceDetails are buggy,
> unmaintainable nightmares.
>
> Starting from scratch, this context would not exist at all. All required
> metadata is available in the AVFrame itself, and it's trivial to
> invalidate the internal state when something changes. The function
> itself should be effectively stateless, with the SwsContext serving as a
> mere cache.
>
> So maybe a good path forwards is:
>
> 1. Make sws_scale_frame explicitly ignore the configured colorspace
>    details in favor of AVFrame metadata.
> 2. Allow using sws_scale_frame with an SwsContext that has not been
>    initialized, but merely allocated.
> 3. Deprecate sws_scale and the old configuration API
>
> Then SwsContext would be serving double-duty between being the
> configuration struct for the legacy API, while also being a cache for
> the new API, until eventually being just the latter.
>

TBF this is in part why i was suggesting a new library - I feel like sws is
affected by bad brading because of these caching issues and imprecise
conversion, and a new clean api in a new library would make a lot of sense
in my opinion.
-- 
Vittorio