GNOME Bugzilla – Bug 629808
Transparency / alpha channel for PNG or SVG images won't work unless you set the clip opacity to less than 100 percent
Last modified: 2013-09-30 19:17:17 UTC
Transparent images are not transparent.
Created attachment 170390 [details] CBC logo Actually, this is quite interesting: - the PNG transparency works in thiblahute's effects branch - it doesn't work in master Here's a sample transparent PNG file to test.
It's working for me using the PPA version
Created attachment 170391 [details] screenshots Yay for heisenbugs. In pitivi git master, this sometimes happens, sometimes not, and here's two screenshots (fail/pass).
Same thing happens here: Not transparent: http://img168.imageshack.us/img168/3835/nottrans.png Is transparent: http://img695.imageshack.us/img695/9585/istrans.png Steps to reproduce: 1. Import video and png file (any order). 2. Position png over image. 3. seek to spot during png or render. Steps to workaround: 1. Change alpha (that is, mess with the red level bar) for *any* video track. 2. Re-seek to verify. The workaround should not be necessary once this bug is fixed. The workaround will trigger another bug where gstreamer crashes (on my machine anyway) and a few extra timeline seeks/clicks are necessary to get it to wake up but that's outside of the scope of this bug and I'll file another.
commit 5289ebd332277160bdb44a24debe58c7ada3d5fd Author: Volker Sobek <reklov@live.com> Date: Thu Sep 16 16:33:37 2010 +0200 Fix wrong positions of keyframe value labels Fixes #629811
oops, wrong tab :)
*** Bug 634951 has been marked as a duplicate of this bug. ***
I'm seeing this failure pretty reliably with the transparent .mkv movie in attachment 174536 [details], as documented in #634951 (dupe). Preview is usually wrong (unless I wiggle the alpha slider, as suggested here), and render is always wrong. In contrast, when working with PNGs things mostly seem to behave correctly (so I must be on the lucky side of that race).
Actually, this might be because we operate in "passthrough" when the clip's alpha is 100% (to not destroy performance)
I have this bug on 0.13.5, both with the previewer and with the rendering.
Is this report a duplicate of bug 611749 ?
Not sure if this is new, but the render button seems to reset gstreamer. This means that the work around doesn't work if you adjusted the alpha levels as suggested in Comment #4 and then moved them back to 100% after gstreamer restarted. In order for this to work, there must be a part of the clip that is not set to 100% at the time of rendering. Either adjusting alpha level for the entire clip, or having it fade out or in. Either way, leads to Bug 644372
Using Ogg Theora as format for the input file (on the bottom layer, at least!) gets around this and 644372 entirely!
Okay, tested again on pitivi git (since many things changed). Everything works *if* you set the clip's opacity curve to something else than 100%, because it will operate in passthrough mode otherwise. Maybe there would be a way to detect if the source media (ex: the PNG image) has a built-in alpha channel and not use passthrough in those cases... but then maybe there are some video or image formats that always say they have an alpha channel? Retitling for clarity.
If the video or image format advertises an alpha channel it should be honored. Better to be correct and slow than wrong and fast. In the special case of still images it might be worthwhile to detect if the alpha channel is fully opaque, but at the moment this would be a premature optimization.
From what I've been told, GES will handle that automatically, so retargetting.
This *should* be fixed now, please reopen if it isn't.