OK, the encoder errors concur with the out-of-memory issue. I do not get the ROM Exceptions either, and maybe that is due to lack of memory too. There could be a memory usage issue. I am running a test with your project, just using export defaults (not HEVC) with parallel processing turned on, and this will take some time. So far, I do not see a big memory consumption issue. The export process (qmelt.exe) at 15% is using only 505 MB after starting with slightly less. It has been at around that level for the past several minutes. While this was running, I played the project in fast forward, and Shotcut used up an additional 2 GB, which is not too extreme considering the filters being used. BTW, the Crop:Rectangle filter on the track is the HTML-using filter.
How much RAM is free after you close Shotcut? You should monitor the memory usage of the shotcut.exe and qmelt.exe processes in Task Manager instead of overall memory. Shotcut cannot simply limit itself to your free memory. If you have not done so already you should:
close Shotcut
close other things to free up more memory
start Shotcut
open the project
export
Definitely, if you use Shotcut for a while editing it will consume a lot memory. Then, it may have too little for export.
I will export again, but due to lenght of video, it will take more than 40 minutes to fail.
I already rebot computer, stop unecessary services… (I’m working in computers).
I let you know the result.
Something strange by the way, settings for audio are never stored in projets…
I mean that I set Binary flow to 192 K and every time I open the projet it is back to 384 K
–> Is this a bug ?
Same for Codec that always come to h264_qsv while my setting is hevc_qsv
I did more tests…
Same project without any crop or video size in filters… Only white balance and sound level / tone adjust.
Codec hevc_qsv, hardware encoder, parallel tasks.
aac codec, 192k, stereo
Video original size : 720 x 576
–> All memory consumed in few seconds… All 16 Go RAM used after 5%. Failed at 60%
Here are the logs
Task log Tasks.txt (15.3 KB)
App logs App.txt (136.0 KB)
XML as text Project.txt (32.6 KB)
Sorry, I do not know what it is going wrong. My first test completed using under 600 MB for the export qmelt.exe. Next, I replaced the video source with an interlaced one since the previous was progressive. I do not have a long enough interlace SD PAL clip to substitute, so I had to use NTSC 720x480. That did not show a problem after 13% export.
Only 97 MB! I also used hardware encoder with HEVC CBR 3M and 3 B-frames, same as you. But my machine does not have Quick Sync, and I had to use Nvidia.
Update: at 43%, and 107MB used.
You can try removing both Size and Position and Crop: Rectangle filters from the track. What are you doing there is heavy, and it is usually better to use Crop: Source to remove the rough edges.
Hi !
I did more tests…
Same project without any crop or video size in filters… Only white balance and sound level / tone adjust.
Codec hevc_qsv, hardware encoder, parallel tasks.
aac codec, 192k, stereo
Video original size : 720 x 576
–> All memory consumed in few seconds… All 16 Go RAM used after 5%. Failed at 60%
Here are the logs
Task log Tasks.txt (15.3 KB)
App logs App.txt (136.0 KB)
XML as text Project.txt (32.6 KB)
Any idea what is wrong ?
I’m unable to export at this time.
I will post my original video on “wetransfer” and give you the link so you will be able to test with my project and my original file.
I tried to reproduce with the VOB you provided, and I still do not have a problem. Export is at 16% and qmelt.exe is using 243 MB. I cannot spend any more time on this, but I encourage you to keep turning things off and reducing until the problem goes away including things you already tested. It might be a combination of things. Remove/disable something, test, leave it off, remove/disable another thing, test, and repeat. Start with turning off hardware encoder, parallel processing, and all track filters. In an new project, export each VOB from the timeline by itself to see if each file is behaving OK.
I finally did reproduce the problem on my Intel system with hardware encoding. The problem only occurs when the resolution is 768x576 or lower. I know you are using the normal 720x576 SD resolution, but I tried 768x576 to see if square pixels make a difference, and it did not. 640x480 did not work, but my main tests using 1920x1080 work fine. With the 1920x1080 source, if I tried 720x576, and it has the problem as well. Then, I tried 800x600 using your VOB, and the problem went away. Also, 640x360 is fine. Any resolution between and including 640x480 to 720x576 triggers the problem. I do not know why. I am not even convinced it is in our code. Very strange.
Well.
This is a good news…
You have now all the needs to check what is going wrong and maybe find where the problem is.
Thank you so much for the time you spend on this trouble.
Note that I will wait if you find a solution because hardware encoding takes 20 minutes while software encoding takes more than 1 hour.
I strongly discourage that. I am not actively working on this bug and may never since it only affects Intel QSV on Windows at specific low resolutions. That suggests it is not something in our code but possible something in a library or driver. I am simply not interested in pursuing it myself, but here it is for another open source adventurer. In the meantime, this is SD resolution, which is not lengthy to encode with software, and you should use it. You see? An hour is already passed, and you could have been done.
Since this seems to be latest Intel + QVS + “some resotulion” related thread on bugs I will point out that I have faced with Custom 1440p 29.97fps video mode similar over floading qmelt.exe memory usage that finally stops process to memory full log marking with h264_qvs codec.
I’ll run some tests with smaller materials and two different aged Intel environment with Windows 10 - 1903 and possibly with one 2004 too. Seems that during first few minutes qmelt eats “slowly” whole free memory (one has 16GB and other 32GB). Same project with FullHD qmelt behaves good (even thou not running under shotcut app process, just for notice at this poin) and seems that with libx264 1440p runs nicely ~2GB qmelt memory usage.
With less than 6 min video from same 4k material with “Rotate and Scale” filter combined with “Size and Position” both 2 latest versions from zip extracted standalone package survived even thou memory usage was over half of time between 92-98 percentage (26-28GB qmelt). Trying now w/o crop filter since that seems to be only difference between shorter and longer project from same GoPro 4k@30fps material.
Filters order for whole video track on problem case rotate (with small percentage upscale), crop (with vertical position value) and position change (vertical with negative value) if there is some known features on this combination?
With that 32GB machine that has i7-4910MQ processor I can repeat export freeze at point where 1,25GB. System behaves a bit differently every time but failed exports are not usable. Those earlier tests were just a bit smaller final file size than that so therefore it survived? Seems that I’m able to export same material to preset 1080p and 2160p @ 29.97 fps not more than 1.5GB qmelt.exe with or w/o filters.
Is this QVS issue or custom video mode issue somehow and what material should I provide for you if there is something buddy pointed out?
