MLT clip's alpha channel

What is your operating system?
Debian GNU/Linux: SMP Debian 5.14.16-1 (2021-11-03) x86_64 GNU/Linux.

What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?

$ git describe

Can you repeat the problem? If so, what are the steps?
I have patched frei0r and now I can use a multi-track .mlt file as a clip without loosing its transparency. :slight_smile:

But then, there are two problems:

  1. When I add an MLT clip and it has the global “Output” with “opacity filter”, shotcut automatically copies this “opacity filter” in-track. Probably, this is a little hack to bypass this restriction. If frei0r gets patched, this workaround can be removed. :slight_smile:
  2. It seems that the XML producer is messing a little with transparency. When the alpha value is low, it uses the alpha value to darken the colors (multiplication) and then, it looks like it sets the alpha value to 0.
  1. This is not due to that specific filter or any sort of workaround. It is simply some quirky bug with how filters are loaded into the UI.

  2. The XML producer does not do any image processing. You seem to be referring to some premultiplied alpha. Images in MLT frames are not supposed to be pre-multiplied. There is an Unpremultiply Alpha video filter one can use in case their source is premultiplied.

Well… the bug was working like a charm, for me. :slight_smile:

I think so. I want to know “who” is multiplying it! :slight_smile:
The weird thing, IMO, is that “solid transparency” is preserved. But when there is some blending with colors, it seems to “pre-multiply”.

I know. I don’t really know the source of the problem, but it loads and connects lots of stuff… I don’t really think the producer is the problem. Maybe, it is something in the XML generated by Shotcut. I do not really understand MLT, right now. So, I am just chasing the problem. It does not happen with the producer for the png files. But it happens with Shotcut/MLT files.

I would love to know who is “pre-multiplying” the color and alpha…

I will try it as a workaround. But I do not really need to solve this problem. It is just a little “not so nice”. I just want to know who is causing this problem, and if is is a “bug”.

If I add a V1 track and put the video directly inside the MLT file, transparency is just fine. And this suggests that the problem is “below V1”. Filters or transitions are being applied “below V1”. It could be the “blank” track, for example. I don’t know how blank and V1 are merged together… or if they are…

I think the tractor is doing something with the alpha channel. Garbage appears when they “leave” the tractor.

Inside the tractor, the problem does not appear. Since frei0r.cairoblend is making the remaining 1 track completely opaque, the problem does not show up.


If you re-enable transparency in frei0r.cairoblend, no problem happens as long as you:

  1. Have only one visible track; or
  2. Has a completely opaque V1.

After frei0r.cairoblending all tracks (except for track 0), if you have transparency on track 1, the tractor inserts garbage in the image.

All the frei0r.cairoblend inside the tractor are just fine. And since Shotcut does not use two tractors, the problem only appears when you export / preview the video, or when you nest Shotcut MLT files.

I do not really know what tractors do, besides merging the tracks. Do they allocate memory? Do they process the image? Does it free some buffer that is already in use?

When interpolation/conversion is done… does it ignore color information when alpha is high, leaving the garbage on the buffer untouched? Does it “deinterlace” (I don’t really know what this is) things? Does this “deinterlacing” takes into account (optimizes, leaving garbage) the alpha channel?

Sorry for making lots of crazy questions. I do not really know what MLT does on the inside. :slight_smile:

The tractor does not do any image processing either.