swscale default alpha blending drops alpha

[Michael Niedermayer]

It was suggested by several developers to change the default to uniform_color (black). This would be slower but produce a more expected output for the sample from Ticket4746. It would produce a less expected output for laraShadow_dl.flv

I have no oppinon on which default is better. But having a seperate ticket for the default could avoid the dispute over #4746

[iive]

Using the alpha channel means that you allow the player and/or editing software to put any kind of background there.
This is the only reasonable assumption.

Black and white chessboard pattern is used by all editing software. We should do the same.

---

So far three default behaviors have been argued:

• Alpha channel should be ignored/dropped. There are encodes that signal existence of alpha channel, but it contains random garbage. Also this is the fastest way to handle the conversion.

• The image should be alpha blended with white background. Sample "laraShadow_dl.flv" looks correctly only with that assumption.

• The image should be alpha blended with black background. Sample from #4746 (prores) looks correctly only with that assumption.

All these behaviors are wrong. None of them could be enabled without breaking the other two. On top of that they would be breaking in quite obscure way.

---

The optimal solution would be to have format specific workarounds.

For the general case, I think that the default should be black&white chessboard pattern:

• It is already supported as mode for alpha blending.
• It is used by all editing software to signal the presence of alpha channel.
• The users would immediately recognize it and will know that the problem is related to alpha channels. Then they can set the desired behavior on their own and eventually demand format specific workaround from us.

[Carl Eugen Hoyos]

Replying to iive:

• The users would immediately recognize it and will know that the problem is related to alpha channels. Then they can set the desired behavior on their own and eventually demand format specific workaround from us.

While I was originally against this (for performance reasons), it is very difficult to argue against doing it.

[gjdfgh]

You forgot PNG, that essentially requires the same behavior as prores.

laraShadow_dl.flv unfortunately just shows black when blending against black, but have you considered that the result is not better AT ALL when just discarding the alpha channel?

From what I see, blending against black (or maybe blending against a checkerboard) is still the sanest default behavior.

I'd also like proof that there are files with garbage in the alpha channel, that work fine with their native software (i.e. the software that invented the format or is designed to work with the format, like QT for prores).

[dbuitenh]

My question is (regardless of what we chose the default blend pattern/colour to be):

Will the blend colour be settable via the CLI? If not, it's next to useless, since it won't actually be possible to make it match some reference software, depending on the default chosen.

[Carl Eugen Hoyos]

Replying to dbuitenh:

My question is (regardless of what we chose the default blend pattern/colour to be):

Will the blend colour be settable via the CLI? If not, it's next to useless, since it won't actually be possible to make it match some reference software, depending on the default chosen.

The interface was done in a way that allows to set the background colour in the future but it was not implemented yet.

[projectsymphony]

is there a benchmark related to the performance impact that @cehoyos and @michael suggest? At least we would understand what speed degradation we can expect.

Also, imho enabling this flag globally seems more like a workaround that many decoders would not need. It would probably be more appropriate to set it for decoders that actually needed it, with right CLI options to override it or change default background colour.

[gjdfgh]

Why would decoders, which don't need it, output alpha?

[Carl Eugen Hoyos]

Replying to projectsymphony:

is there a benchmark related to the performance impact that @cehoyos and @michael suggest?

You mean additional (per-pixel) code comes for free?

Maybe in avconv...

[projectsymphony]

Replying to cehoyos:

Replying to projectsymphony:

is there a benchmark related to the performance impact that @cehoyos and @michael suggest?

You mean additional (per-pixel) code comes for free?

Depends on how that code is written. Usually people run benchmarks for what a code change encompasses before claiming that something has a huge performance impact.

Maybe in avconv...

How is this comment related to anything here? Please go troll elsewhere.

[Carl Eugen Hoyos]

Replying to projectsymphony:

Replying to cehoyos:

Replying to projectsymphony:

is there a benchmark related to the performance impact that @cehoyos and @michael suggest?

You mean additional (per-pixel) code comes for free?

Depends on how that code is written. Usually people run benchmarks for what a code change encompasses before claiming that something has a huge performance impact.

Did I really say the impact is huge?

Maybe in avconv...

How is this comment related to anything here? Please go troll elsewhere.

Lol, that is a funny argument when it comes from you!

[projectsymphony]

Replying to cehoyos:

is there a benchmark related to the performance impact that @cehoyos and @michael suggest?

You mean additional (per-pixel) code comes for free?

Depends on how that code is written. Usually people run benchmarks for what a code change encompasses before claiming that something has a huge performance impact.

Did I really say the impact is huge?

From our other favourite bug:
"No, I don't think a default massive performance regression is acceptable."

huge and massive are synonyms.

Maybe in avconv...

How is this comment related to anything here? Please go troll elsewhere.

Lol, that is a funny argument when it comes from you!

Not really sure why I deserve this comment. I restate, please go troll elsewhere.

Any update on thig bug?

[Carl Eugen Hoyos]

Replying to projectsymphony:

Replying to cehoyos:

is there a benchmark related to the performance impact that @cehoyos and @michael suggest?

You mean additional (per-pixel) code comes for free?

Depends on how that code is written. Usually people run benchmarks for what a code change encompasses before claiming that something has a huge performance impact.

Did I really say the impact is huge?

From our other favourite bug:
"No, I don't think a default massive performance regression is acceptable."

huge and massive are synonyms.

You are right, sorry.

Maybe in avconv...

How is this comment related to anything here? Please go troll elsewhere.

Lol, that is a funny argument when it comes from you!

Not really sure why I deserve this comment. I restate, please go troll elsewhere.

If a developer exclusively working for a project that has done everything to destroy FFmpeg (although maybe using FFmpeg exclusively?) is opening tickets on our bugtracker under an alias personality, I think "trolling" is not exactly a wrong description.

Any update on thig bug?

A patch was posted on the development mailing list, please comment there. It makes no sense to discuss patches here on trac.