[FFmpeg-devel] [RFC] Swscale refactor progress and feedback

[Michael Niedermayer]

Hi

On Fri, Sep 27, 2024 at 04:49:58PM +0200, Niklas Haas wrote:
> Hi all,
> 
> After a bit of a hiatus due to delays in negotioting the appropriate
> contracts, I've finally been able to resume work on the swscale refactor
> and have my current draft to demonstrate and gather critique on.
> 
> Rather than the initial goal of introducing a new AVScale header, I have
> updated my proposal to instead directly reuse the sws_* namespace. For now,
> this unfortunately requires postfixing some colliding functions with a `2`

> suffix, e.g. sws_alloc_context2, sws_scale_frame2 and so on.

sws_context_alloc()
sws_frame_scale()
and you have no conflicts and no 2 postfix


[...]
> So, all that being said, here are the biggest pain points I want feedback on:
> 
> 1. How do we resolve the abiguity between SwsContext and SwsContext2?

We arent using a AVCodecContext2 yet nor a AVFormatContext2, so i would
expect given that SwsContext is not public that adding needed fields and
deprecating and removing what becomes obsolete should work, unless the struct
plays a different role in a new design.


[...]
>
> 2. How detailed / accurate do we want to preserve back compat with "legacy"
>    swscale semantics? For example, swscale currently has some obscure flags
>    and modes that I don't see as a high priority to maintain support for. But
>    if we want the new API to be a strict improvement, we ought to maintain
>    backwards compatibility in some form for all of these obscure modes.
>    OTOH, now might be our biggest chance to revise what is actually needed.
> 
>    For example, things I currently omit / imply, or could:
>     - SWS_FULL_CHR_H_INP: I added a new flag SWS_FLAG_ALIAS which roughly
>         corresponds to similar semantics, but in a more generalized fashion.

>     - SWS_FULL_CHR_H_INT: turned on by default now, unless the user requests
>         chroma point sampling. (Thought this does trigger a slow path in
>         the underlying swscale legacy implementation for bgr8 etc)

quality by default makes sense in 2024

and flags like this should correspond to the implementation obviously. I mean
if we have code that can do 2:1 downsampling by droping every 2nd sample
(or something like that)
then a flag to access this makes sense. If we dont have such code (anymore)
then obviously such a flag should be deprecated.
Such code should not be kept "because" of the flag. But it should be
kept if it serves a purpose like being faster


>     - Some of the more obscure scaling and dithering modes, such as
>         "experimental", arithmatic dither, area scaling, etc.

"experimental" can be droped unless its something that is used by a real group of
real people.
"area scaling" should just be different coefficients, so i dont see the benefit
in droping it



>     - Support for setting custom yuv matrices or filter weights.

why not ?
if we have a well optimized codepath to apply such a matrix or filter,
it should be accessable to the user for other purposes

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20240928/f05d91f6/attachment.sig>