Transitions not working in composite mode with GPU enabled

Hi there,

first of all: fantastic software, I just love it!! Thank you so much. And also the support in the forum is great.

I’ve been successfully editing my first video and found enabling GPU working well.
However, when exporting the project the job fails in the middle. I tracked the culprit down to being transitions in composite mode. Without transitions it works just fine and transitions at time points where no second clip is in the other timeline works as well.
I know that GPU-support is experimental, so I don’t expect a fix…

But is there a way of converting all GPU-effects to CPU-once? Since I can’t open the project anymore without GPU-processing enabled…
Any suggestions would be appreciated! Thanks in advance.

At least it may be helpful for others to know this in advance :slight_smile:

In case you want to address this issue in the future here the error codes:
On export:
[Debug ] MeltJob::start “/opt/shotcut/bin/qmelt” ("-verbose", “-progress2”, “-abort”, “/tmp/shotcut-w16975.mlt”)
[Debug ] AbstractJob::onFinished job failed with 6

When seeking the transition in the timeline, shotcut crashes with the following message:
shotcut: filter_movit_convert.cpp:204: void build_fingerprint(mlt_service, mlt_frame, std::string*): Assertion `effect’ failed.
/usr/bin/shotcut-bin: line 15: 16975 Aborted (core dumped) bin/shotcut “$@”

I’m using shotcut version 17.01.02 on arch linux x64.

By the way: jack support works perfectly and makes videos running much smoother, thanks! :slight_smile:

1 Like

If you can load your old project with GPU processing turned on, turn it off and save it. Then open that project as a .mlt clip in a new project and export there. Go to File>Open MLT XML as Clip and select from there. If that doesn’t work you might have to start over. :frowning:

Thanks, Lauren, for the quick reply!
If I uncheck the GPU-option I get asked to restart shotcut in order for this to take effect.
When on the other hand opening (also as clip) with GPU disabled, I get prompted to restart shotcut: “The file you opened uses GPU effects, but GPU processing is not enabled. Do you want to enable GPU processing and restart?”

So, in summary, your solution unfortunately does not work. I am now trying to render every track separately and than compose them again…

Now, the latest versions of many functions do not support GPU, no effect.:困惑:

Oh okay, I’m sorry to hear that. Yes GPU processing has very little usability at the moment unfortunately.

Hi Lauren, now supports SWF files?

No, not at this time and not in the near term. Perhaps long term.

I noticed exactly the same. On Ubuntu Linux,
By the way, what is currently the difference when GPU is enabled?
I mean where is the trade-off? for example, in this topic I can either give up on compositing over a transition, or give up on GPU mode. If I give up on the GPU, and get my transition rendered properly, what do I use from the GPU mode? Rendering will become slower?

I have the same issue here!
I have a project with GPU enabled, but I shortly realized that the transitions doesn’t work, so I disabled the GPU, restarted the app, but then I still have GPU transitions.
Is there a way (workaround)? Maybe editing the mlt file by hand?

Its 2018 and GPU support is still crappy… If I try to export file with transitions it fails with exit code 11 (which Google haven’t heard of).
The GPU setting can’t be unset if it is once saved set for a project.
Also for some reason I can’t use Text effect with GPU enabled.

Which part of ‘experimental’ are you not understanding? :face_with_raised_eyebrow:


Personally I am in awe of folks who spend so much time, often with headache and frustration while bringing their vision and work to us for absolutely free. I’m pretty certain they have a life outside of Shotcut and I’m sure they’d also like the application to be perfect too.
Be a little more respectful, it goes a long way in helping the devs feel warm and fuzzy about what they do.


Just exported a file 3 times with different transitions and all exported fine.

The text issue was covered and solved here.

Which part of ‘experimental’ are you not understanding?

The “experimental” part. Usually it means the feature is working for most people AND it is not breaking the product for the others. I can live with it not working, BUT once enabled it can’t be disabled for a given project, virtually corrupting it.

Don’t get me wrong - I love Shotcut. I understand the amount of work behind it, because I’ve been involved in lots of FOSS projects myself. But if something is “free” it doesn’t mean we shouldn’t complain if it is not working.

Usually I would just file a bug report in the issue tracker, but I can’t find any for Shotcut. Thus - I’m ranting on the forum. Found the tracker, filed a bug report.

The text issue was covered and solved here.

Explanation “the text filter is not compatible with GPU processing” is not actually solving it.

Well I can’t agree with that in that slightest. In my view there are zero grounds for complaint here.
Expressing dissatisfaction or annoyance over something you are fully aware might very well cause problems is irrational.

You used a function which has known issues & caveats , which is labelled as (experimental) and you consider it a bug?

It’s not mean’t to be a solution, it’s an explanation.
Given time the developers will iron out the issues or disable it altogether

1 Like

It seems that the “experimental” label is not conveying the meaning we intend. Can anyone suggest a better label or message that will stop people from complaining when the GPU processing feature does not work for them?

Other people have had some success removing the GPU filters or even converting them to non-GPU filters. Please make a backup of your project file if you go down this path.


How about “Beware use at your own risk no guarantees. If things break don’t complain.”

I think the current label is fine & understood by most, Brian. In any case, one only needs to ‘experiment’ with GPU processing enabled once or twice on a non-critical edit.
You won’t prevent some people complaining if it’s in their nature.

I found this topic after Googling the same error 11 message following a failed export. For me it has nothing at all to do with the GPU processing option because I’ve never used that - I saw the ‘experimental’ tag in brackets and decided not to touch it with a barge pole.

As I understand topic, you guys talking about the same trouble I have.

I mean the problem of unexpected export results in frames where transition was used with other fragments placed above it.
In my case I got following example:
When something is placed above a transition, and in my case it not covers all the frame but placed in a right bottom angle with filter called “Size and Position”, I’m getting a bad exported frames on that position.
Exported example of mentioned above:
You can download or just preview on a host.

So my question for now is next. Is there any other way to prevent so crappy results besides of not using any other fragments above a transition???