- User Since
- Jun 30 2017, 2:20 AM (33 w, 5 d)
Oct 30 2017
Uploaded rendered video and project folder to Google Drive.
Oct 29 2017
This doesn't appear to happen in the betas. Working with a large file for a while might bring the issue back, but for now I wasn't able to cause it to happen with my largest project.
Oct 26 2017
Oct 23 2017
Sep 18 2017
Sep 4 2017
Mostly. I was just able to replicate this by loading other apps while Pitivi was still loading, which made it freeze, but clicking on "Wait" in the dialog window made Pitivi load right away. Other than that, I haven't seen the problem.
Aug 26 2017
Not sure if this is related or I should open a new bug:
Getting error on launch:
Aug 25 2017
Aug 19 2017
Will this be pushed into the flatpak-master build soon, or should I build from source to try it?
Aug 16 2017
It is updated from pitivi-master. Version shows as 0.98-227-g23c05ef
Is the fix pushed to the pitivi-master flatpak? Installed just now, still having problems.
Aug 8 2017
Here's a Google Drive link: https://drive.google.com/open?id=0B7gybbnD9E35ZHBNN1MyQjRPZEU
Aug 7 2017
I think mega wants you to use a Firefox extension to download larger files. That might help.
Are you able to consistently reproduce the freeze when loading the project?
Aug 3 2017
That seems to have fixed it.
That does seem to have fixed the crossfade issue...but did it break other transitions?
Aug 2 2017
I do indeed still get the error. Bug filed here: https://phabricator.freedesktop.org/T7805
Jul 25 2017
The project file you want to work with is sbcaltright.xges.
Here's the entire project: https://mega.nz/#!2dsX0TRQ!lhVB0vFgoqmlFLYYqT0muWqMBt8g7HfZhiNqGFFjS8I
Jul 24 2017
I am uploading the project as a 7.2 GB tar to mega.nz and will post the link here when the upload is complete...maybe a couple of hours from now.
Pitivi from latest flatpak has the same problem -- loads project, never generates preview, freezes and asks to either wait or force close.
Jul 20 2017
Has this been pushed to the flatpak builds? I am running the updated flatpak but still encountering this error.
Jul 17 2017
Jul 4 2017
Is there a workaround for this?
Jun 30 2017
I think there needs to be more thought put into this one. Even using two copies of the exact same image, the crossfade transition between the two darkens as the two images somehow don't add up to 100% alpha during the transition.
I think the previous behavior is more natural. The work-around is also easy in that case, since any background image the user doesn't want to show through when clips on top of it crossfade can simply be cut at that point and then each new clip dragged so that they are on either side of the crossfade.
That seems to have fixed the cross-fade allowing lower tracks to bleed through, but it does so by completely ignoring the lower tracks. This is an even bigger problem, because the background image is completely ignored during the transition, which is not desirable, nor is it what is visually presented to the user in the editor. Consider the following scenarios:
Actually, the screenshot you posted does show the bottom layer bleeding through. You can confirm this by using GIMP to examine the colors, or replace the green image in the bottom layer with an actual image of some sort so you can see it through the red.
The attached project archive demonstrates the phenomenon in the bug title -- the image in Layer 1 bleeds through as the images in Layer 0 transition.
Actually, it seems all transformations are handled horribly with any sort of layered clips.