Cannot export anything, error code -1073741819

I cannot export anything from the timeline, except with the default settings that Shotcut comes up with when I open the project file. I have tried every possible combination of encoder, hardware encoding options, parallel processing, quality, audio format, and NONE of them work. Every time I try something, the export progress gets stuck on 0%, and eventually throws the -1073741819 error.

I’ve updated my graphics drivers, I’ve monitored the memory usage, I’ve excluded melt.exe from my antivius, I’ve restarted my computer, I’ve checked for Shotcut updates, I’ve tried exporting from a previously functional backup, I’ve tried reinstalling Shotcut. It still throws -1073741819. My export settings worked on previous videos.

One thing that I have noticed though, is that if I copy my timeline into source, I can export using a limited set of settings. However, this causes some strange and seemingly random audio clipping.

Also, having recounted what I did before these issues started, I think that me setting the project’s video mode from automatic to HD 1080p60 is what caused these issues. I noticed that my main video track and my audio track were no longer in sync, because every single clip that I had added in was a tiny bit shorter. Setting the project’s video mode back to automatic does not undo this change. My guess is that the clips had a framerate higher/lower than 60 fps, and were shortened to compensate for this.

Is there any way for me to revert, or apply some sort of filter/setting onto my project to set my clips to their original length? Is there some way to prevent the -1073741819 error?

I’m on Windows 10 build 19042.985
I’m on Shotcut 21.05.18, 64-bit
My system specs are included in the attached ZIP.

I’ve included several job logs, as well as an XML for my export.

logs.zip (87.6 KB)

I simple search of this forum for “1073741819” will yield a plethora of discussions of this error.

One example:

I already tried looking online, I searched maybe 20 different discussions, in fact I saw that very post you’ve mentioned there. But it appears that my case is very different for some reason.
If you take a look at the logs, they dont show any timecodes, or any information which I could really use. The only thing that looks like it may be a problem is “missing hwaccel parameters. skipping hardware initialization” showing up frequently in the logs, but I don’t see how no hardware acceleration might cause it to stop exporting.

This (I have learned recently) is irrelevant, as it refers to GPU decode, which Shotcut does not use at this time.

The main gist of the responses to previous 1073741819 is that Windows recently tightened its security protocols, and frequently melt.exe, which runs during Export, gets caught in the Windows security dragnet.

So, I excepted the entire Shotcut folder from any security features, and nothing’s changed. I don’t think that this is an issue with security, because I can still render things (but only if I copy timeline to source).

In other words, if melt.exe was getting caught by security features, I wouldn’t be able to export, even if I copied my timeline to source.

Never exporting directly from my timeline does sound like a reasonable fix, but when I do that the end product contains a lot of stuttering, both with the video and the audio.

I suspect that it’s either the video mode causing issues, or some corruption/bug with the timeline/project’s .mlt file. I’ll have at it with my delete key to see if it fixes itself.

Do a Save As to preserve your original MLT.

When your export fails in the window where it shows the progress of the file, that’s where it gives you the timestamp. Go to that exact spot in your timeline, and start eliminating filters one by one to see which filter is stopping your export. It may be as simple as deleting a filter, then reapplying.

Despite your excellent effort in providing logs, only you can see that timecode at the time of the export fail. An example of where to look for the timecode is shown in the post provided for by @kagsundaram.

When you export, just use default settings.

Usually, when the export crashes because of a wacky filter, the job log includes the frame number of the part that caused it to crash. Very helpful when trying to find the problematic filter. However, in my case, no frame numbers show up in the logs, because the export fails before even a single frame gets rendered (the size of the exported file is always 0 bytes).
I have included a before/after failing screenshot as well as the file associated with it.
I had to put the file into a ZIP because you can’t upload files which are “empty”

sc
timecode3.zip (124 Bytes)

I’ve found out that when I export using a resolution that isn’t 1920x1080, the export can get past 0%. However, the export still fails once it reaches 100% on the export progress bar, regardless of my settings. The output file only contains metadata describing what the video is supposed to be. The job logs still don’t offer any useful information.

I did find that this is an issue relating to this project specifically, and to the entire project, not just one or two tracks. I tried exporting without audio and without video, both attempts failed. Because other projects export just fine, I think that my .mlt file was somehow corrupted/altered in a way that prevents export. I’ll see if I can somehow patch the file using my existing projects and backups

I want to say that you did an impressive amount of research and troubleshooting before asking for help. I’m impressed. I think you are on the right track that there is something specific about this file that is causing the problem. I hope we figure out what it is so that we can fix it for other people.

I agree with this subtractive strategy. If you can not identify a troublesome timecode, then I suggest to just start deleting things from right to left until the problem goes away. Then, open up a new copy of the original and try to just delete that one thing and see if it also works.

The key is to never troubleshoot in this way on your original file - always make a COPY.

AHA!
It WAS a problem with the project’s MLT file!
I took the MLT of a video I worked on a couple years back, opened it in npp, and copied over the first line of options, changing

<profile description="automatic" width="1920" height="1080" progressive="1" sample_aspect_num="1" sample_aspect_den="1" display_aspect_num="16" display_aspect_den="9" frame_rate_num="60" frame_rate_den="1" colorspace="709"/>

to

<profile description="automatic" width="1920" height="1080" progressive="1" sample_aspect_num="1" sample_aspect_den="1" display_aspect_num="1920" display_aspect_den="1080" frame_rate_num="405157500" frame_rate_den="6752617" colorspace="601"/>

and it appears that this has fixed the issue. I might do some further testing, but I’m pretty sure that this is a conclusive fix for my scenario. I can export from my timeline, using any settings I want.

I’m pretty sure it was “display_aspect_num” and “display_aspect_den” causing the problems, because they weren’t equal to the resolution of all my clips. I really don’t know how those values ended up changing, either.

I am so glad you were able to make it work. I see that you changed two things in your file: display_aspect and frame_rate. If you are able to take some time, it would be good to determine which change solved the problem.

Intuitively, I can’t explain why either one of those would cause a problem.

There was also a change to colorspace. That one kinda worries me more than the others.

This one doesn’t work:

<profile description="automatic" width="1920" height="1080" progressive="1" sample_aspect_num="1" sample_aspect_den="1" display_aspect_num="1920" display_aspect_den="1080" frame_rate_num="60" frame_rate_den="1" colorspace="709"/>

Abridged: display_aspect: 1920x1080, frame_rate: 60x1, colorspace: 709


These two work:

<profile description="automatic" width="1920" height="1080" progressive="1" sample_aspect_num="1" sample_aspect_den="1" display_aspect_num="16" display_aspect_den="9" frame_rate_num="60" frame_rate_den="1" colorspace="601"/>

Abridged: display_aspect: 16x9, frame_rate: 60x1, colorspace: 601

and

<profile description="automatic" width="1920" height="1080" progressive="1" sample_aspect_num="1" sample_aspect_den="1" display_aspect_num="16" display_aspect_den="9" frame_rate_num="60" frame_rate_den="1" colorspace="709"/>

Abridged: display_aspect: 1920x1080, frame_rate: 405157500x6752617, colorspace: 709


So, it appears that when I change either frame_rate OR colorspace, the export can work. Very strange, I was expecting only one of the variables to be interfering. Let me know if you’d like more data.

Thank you for taking the time to collect that data. Unfortunately, it is not very conclusive.

I would be willing to try the export on my computer if you want to zip up the entire project and share it. But maybe that is not worth the effort for you now that you have a work-around.

Melt is the name of the procedure for hardware data cracking in processors. I’m not surprised that the antivirus responds to it. It is probably worth changing the name of the process if the developer wants it.

1 Like

That bug is called Meltdown and is unrelated to the name of the executable. Changing the name would have no effect. Windows Defender or other anti-virus scanners would still likely say “I’ve never seen this program before so I’m blacklisting it out of caution” or at least prompting the user to continue.

2 Likes