* [FFmpeg-devel] The patch series about premultiplied alpha
@ 2025-08-02 15:18 Nicolas George
2025-08-02 18:03 ` Nicolas George
0 siblings, 1 reply; 2+ messages in thread
From: Nicolas George @ 2025-08-02 15:18 UTC (permalink / raw)
To: tc; +Cc: ffmpeg-devel
Hi.
I write this mail to the technical committee to state that since Niklas
Haas has stated intent to stop discussing on the mailing-list, I am
asking the technical committee to make a decision on the subject.
It will take me a little time, at least several hours, maybe a few days,
to properly express my arguments clearly and cross-reference them for
your convenience, but I can already give the gist of them:
- The patch series lacks transverse user documentation.
- The patch series increases the risk of data corruption due to user
negligence and should include at least some guardrails against that.
I will develop both these points as soon as possible.
In the meantime, it should go without saying but I am afraid it needs to
be said, (1) Niklas Haas cannot be part of the decision, or even private
discussion if there is one, since he is already part of the
disagreement, and (2) the patch series cannot be pushed until the
decision is made.
Regards,
--
Nicolas George
_______________________________________________
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".
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [FFmpeg-devel] The patch series about premultiplied alpha
2025-08-02 15:18 [FFmpeg-devel] The patch series about premultiplied alpha Nicolas George
@ 2025-08-02 18:03 ` Nicolas George
0 siblings, 0 replies; 2+ messages in thread
From: Nicolas George @ 2025-08-02 18:03 UTC (permalink / raw)
To: tc; +Cc: FFmpeg development discussions and patches
Nicolas George (HE12025-08-02):
> - The patch series lacks transverse user documentation.
>
> - The patch series increases the risk of data corruption due to user
> negligence and should include at least some guardrails against that.
Here is the situation before this patch series:
- All alpha is supposed to be straight by default.
- A few niche decoders (EXR, JPEG XL) would silently output
premultiplied alpha.
- A few niche encoders (the same) would silently assume their input is
premultiplied alpha.
- There is a pair of filters premultiply / unpremultiply.
- The overlay filter supports premultiplied alpha if enabled with an
undocumented option.
- There is no protection at all: if a command connects input with one
kind of alpha with out expecting the other kind at any point, it will
produce invalid output without so much as a warning.
- There is barely any documentation at all. The filters are documented
for what they do and that is all.
(IIRC, I would have fought the inclusion of the filters, but with Paul
one must choose one's battles.)
This patch series makes support for premultiplied alpha official.
Ideally, official support should include transparent automatic
conversion, but that would require too much work. But I think that
before inclusion it must fix the two worst problems:
- lack of documentation;
- risk of creating invalid output without any warning,
considering that the work to achieve it is a moderate fraction of the
work already invested in the patch series.
Documentation is easy: just write a few paragraphs to explain what
premultiplied alpha is, where it likely to occur (what did motivate the
writing of this series?) and how to deal with it (links to the
conversion filters).
Protection against creating invalid output, now. As I mentioned above,
full negotiation and automatic conversion, which would be ideal, is too
much work and therefore too much to ask. Niklas agree on that.
On the other hand, protection, i.e. emitting an error and letting the
user deal with it, is not much work:
- add a flag to filters that support premultiplied input;
- add a check for that flag in the framework.
In total, maybe two lines in a header, four lines in framework code and
one line per filter that will not damage the output. Similar work has
already be done for encoders.
Such limited work would make the feature much less dangerous for users,
it should be done before the feature reaches the public.
Regards,
--
Nicolas George
_______________________________________________
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".
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2025-08-02 18:03 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-08-02 15:18 [FFmpeg-devel] The patch series about premultiplied alpha Nicolas George
2025-08-02 18:03 ` Nicolas George
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