Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: Niklas Haas <ffmpeg@haasn.xyz>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH 2/3] swscale/utils: correctly return from sws_init_single_context
Date: Tue, 14 Nov 2023 14:14:37 +0100
Message-ID: <20231114141437.GB16959@haasn.xyz> (raw)
In-Reply-To: <20231113183008.GK3543730@pb2>

On Mon, 13 Nov 2023 19:30:08 +0100 Michael Niedermayer <michael@niedermayer.cc> wrote:
> but i dont feel like i fully understand the issue here so maybe iam missing
> the goal of this patchset somewhat

So, to summarize the main problem:

1. sws_init_single_context() previously hard-coded decisions based on
   c->srcRange and c->dstRange. This is fundamentally broken, as
   srcRange/dstRange can change at any time with
   sws_setColorspaceDetails.

2. To fix this, this function was made to not early-return, and instead
   run the rest of the init code just in case range conversion is needed
   later. (With the check for whether or not the special converter can
   be used being moved to the callsite instead of the setup site)

3. This caused problems for non-YUV inputs, because previously these
   would always early return, but now they run the rest of the code,
   which triggers at least one assertion for float32 formats.

4. To fix this, this commit restores the early-return for non-YUV,
   preserving the status quo of existing behavior w.r.t not hitting the
   rest of the init function.

5. Separately, this commit fixes an error in previous condition (2) at
   the callsite, which relied on c->lumConvertRange being unset when no
   range conversion is needed. However, that condition did not match the
   condition used in the setup check before.

> * convert_unscaled should only be set when used
> OR
> * if these are set "always" if not alphablend and convert_unscaled should be
>   two seperate fields. But i have not at all looked at what consequences that
>   would have so maybe that has issues

convert_unscaled cannot be set only when used because we don't yet know
if it will be used or not. There is also no advantage I see to splitting
the fields, as they have basically the same logic attached to them
- being dependent only on whether or not range conversion is needed.

> Also if some range convert should not be used/set for some cases then
> the check should maybe be where the range convert is setup not far away
> from it. I mean a check close to the related code is easier to understand
> 

One alternative that would make this possible would be to re-run whole
context init from sws_setColorspaceDetails, if the srcRange/dstRange
change.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

  reply	other threads:[~2023-11-14 13:14 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-13 15:32 [FFmpeg-devel] [PATCH 1/3] swscale: don't assign range converters for float Niklas Haas
2023-11-13 15:32 ` [FFmpeg-devel] [PATCH 2/3] swscale/utils: correctly return from sws_init_single_context Niklas Haas
2023-11-13 18:30   ` Michael Niedermayer
2023-11-14 13:14     ` Niklas Haas [this message]
2023-11-14 22:52       ` Michael Niedermayer
2023-11-22 12:45         ` Niklas Haas
2023-11-22 13:16           ` Michael Niedermayer
2023-11-13 15:32 ` [FFmpeg-devel] [PATCH 3/3] swscale/utils: don't early return in yuv alpha blendaway Niklas Haas
2023-11-14  2:27 ` [FFmpeg-devel] [PATCH 1/3] swscale: don't assign range converters for float Chen, Wenbin
2023-11-27  2:10   ` Chen, Wenbin
2023-12-12  7:54     ` Chen, Wenbin
2024-01-10 13:15     ` Niklas Haas
2024-01-11  2:59       ` Chen, Wenbin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231114141437.GB16959@haasn.xyz \
    --to=ffmpeg@haasn.xyz \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git