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.
Regards,
Laurent
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?
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.