05.12.2025, 21:52
Wonderful, both fixes are working as intended! Thanks so much Selur, you're incredible with the quick turnarounds!
Side note for discussion. I haven't looked around/researched into it, but have there been anything major changes to the rendering pipeline from VapourSynth itself within the past 6 months or so? I believe I've been experiencing what the user Wolf mentioned in this thread: https://forum.selur.net/thread-4180-post...l#pid27441 . I remember the Hybrid versions around May, like the one he mentioned (2025.05.18.2) were some of the last ones that were able to more quickly load and process the VsViewer (and subsequently get to the video encoding stage in the render process quicker). Since then, the viewer and render process still load, it just takes a much longer time now to prep the file for viewing and rendering. So, I'm assuming there was a change with something on Vapoursynth's end (not you) that has to do with the rendering. I've tried fresh installs of Hybrid (with previous versions completely removed). I've also installed it on fresh Windows builds of other hardware (AVX-512 supported i9-10940X, a Ryzen 5900X and a Threadripper 3960x). My current build has a 14900K, so I thought it may have been the P-core E-core situation. I tried keeping Hybrid 'in focus' as well as Process Lasso, but still got the same results just like when I tried the other machines. All of these machines were faster on that specific May build and the versions before, but only for the Vapoursynth stages (viewer and render step). The actual ffmpeg encoding/rendering speed is the same though, which is to be expected. It also doesn't seem to be single thread bound either. Task manager, and HWInfo don't show a single core pegged at 100% like it used to when trying to load the viewer. So that also makes me think it's Vapoursynth framework change. I also thought that having the input file on a 10Gbe connection to a NAS was causing the issue, but got the same result having it on a Gen4 NVME. This is well out of my knowledge base as you can tell, but I wanted to mention this to showcase that another person is also experiencing a similar issue. I presume Wolf thought that there was no 'Preview Window' since he or she didn't wait on the long loading process for it to eventually pop up.
It's not that big of a deal to me though since the rendering occurs overnight, and I'm never in that big of a hurry, but just wanted to thought provoke with you.
As an example, the input file I've used to troubleshoot with you was encoded as a 720x486 4:2:2 FFV1 (12 Slices and Level 3) and is about 27 minutes long. Once the file is added to the queue and has started processing, the audio .wav file was generated at 1:37pm in the local %temp% directory. The file didn't actually start encoding with ffmpeg until 1:49pm. So about 12 minutes in hang time for Vapoursynth to prep the file. This normally would've taken way less than that.
Ahh, nevermind. It potentially looks to be a change in LWLibavSource. When changing the source viewer to 'Prefer Best Source' ,it speeds it up dramatically, but still not quite to the same level as way before
Side note for discussion. I haven't looked around/researched into it, but have there been anything major changes to the rendering pipeline from VapourSynth itself within the past 6 months or so? I believe I've been experiencing what the user Wolf mentioned in this thread: https://forum.selur.net/thread-4180-post...l#pid27441 . I remember the Hybrid versions around May, like the one he mentioned (2025.05.18.2) were some of the last ones that were able to more quickly load and process the VsViewer (and subsequently get to the video encoding stage in the render process quicker). Since then, the viewer and render process still load, it just takes a much longer time now to prep the file for viewing and rendering. So, I'm assuming there was a change with something on Vapoursynth's end (not you) that has to do with the rendering. I've tried fresh installs of Hybrid (with previous versions completely removed). I've also installed it on fresh Windows builds of other hardware (AVX-512 supported i9-10940X, a Ryzen 5900X and a Threadripper 3960x). My current build has a 14900K, so I thought it may have been the P-core E-core situation. I tried keeping Hybrid 'in focus' as well as Process Lasso, but still got the same results just like when I tried the other machines. All of these machines were faster on that specific May build and the versions before, but only for the Vapoursynth stages (viewer and render step). The actual ffmpeg encoding/rendering speed is the same though, which is to be expected. It also doesn't seem to be single thread bound either. Task manager, and HWInfo don't show a single core pegged at 100% like it used to when trying to load the viewer. So that also makes me think it's Vapoursynth framework change. I also thought that having the input file on a 10Gbe connection to a NAS was causing the issue, but got the same result having it on a Gen4 NVME. This is well out of my knowledge base as you can tell, but I wanted to mention this to showcase that another person is also experiencing a similar issue. I presume Wolf thought that there was no 'Preview Window' since he or she didn't wait on the long loading process for it to eventually pop up.
It's not that big of a deal to me though since the rendering occurs overnight, and I'm never in that big of a hurry, but just wanted to thought provoke with you.
As an example, the input file I've used to troubleshoot with you was encoded as a 720x486 4:2:2 FFV1 (12 Slices and Level 3) and is about 27 minutes long. Once the file is added to the queue and has started processing, the audio .wav file was generated at 1:37pm in the local %temp% directory. The file didn't actually start encoding with ffmpeg until 1:49pm. So about 12 minutes in hang time for Vapoursynth to prep the file. This normally would've taken way less than that.
Ahh, nevermind. It potentially looks to be a change in LWLibavSource. When changing the source viewer to 'Prefer Best Source' ,it speeds it up dramatically, but still not quite to the same level as way before