You are not logged in. Please login or register.
SmoothVideo Project → Posts by Mystery
Disabled any overclocking and tried again in Wayland.
After closing MPV (after a few videos), full system crash with a graphical glitch. Can only do hard reset. At least in X11, I can press CTRL+ALT+F3 to go into a console and kill X11 but not in Wayland.
System is not under load so it's not that. Otherwise, system is very stable and can game and all no problem.
SVP used to work really well on Linux. Since some time though, I've been getting more system instability. Using Garuda (Arch-based).
Under Wayland, I'd get occasional glitch pixels on the screen, and occasional system freeze. Under X11, sometimes (especially after closing MPV playing with SVP) the screen would show visual glitches, then X11 freezes. I can kill X11 and the system starts working again.
I noticed, however, that if I close SVP, then the system looks stable.
To me, it looks like a NVidia driver bug that gets triggered by SVP...
Anyone else having that issue? What would be the best course of action from here?
The bug isn't being reported or fixed because very few Linux users are using SVP and seeing this problem.
RTX card improvement, is that Linux-specific or a feature to add for all versions?
Flatpak packaging; how is that going to integrate into the MPV rendering pipeline? Flatpak is designed to run apps in a sandbox, not integrate into other apps' pipelines like that. How would you plan to do that, and what would be the benefit?
I have to admit their Linux packaging is off-standards; direct port of the Windows philosophy.
Linux version works just fine; are there any specific features you want?
Also he's giving the Linux version for free; reducing the incentive to work on it...
Use VapourSynth or Avisynth, and write your video-editing script
VapourSynth will have better Linux support.
As an update, the issue was due to ALHP repos. intel-compute-runtime compiled in v3 isn't working.
Either of the 2 solutions work:
- Uninstall ALHP repos
- Uninstall intel-compute-runtime (and then have no OpenCL on Intel of course)
Considering I use OpenCL on NVidia, I went for the 2nd option.
There is indeed a problem with OpenCL
clinfo gives
Abort was called at 36 line in file:
/usr/src/debug/intel-compute-runtime/compute-runtime-23.09.25812.14/shared/source/built_ins/built_ins.cpp
fish: Job 1, 'clinfo' terminated by signal SIGABRT (Abort)if nvidia-opencl-icd and mesa-opencl-icd are neither in the official repos nor in the AUR, I don't think that's the right solution.
SVP has been working fine on Linux up until last week. Now I get this:
15:58:56.181 [i]: Main: starting up SVP 4 Linux [4.5.0.210]...
15:58:56.182 [i]: Main: args: none
15:58:56.182 [i]: Main: working dir is /home/hanuman/Apps/SVP 4/
15:58:56.182 [i]: Main: data dir set to /home/hanuman/.local/share/SVP4/
15:58:56.182 [i]: Settings: loading reg.cfg OK
15:58:56.183 [i]: Settings: loading main.cfg OK
15:58:56.183 [i]: Settings: loading ui.cfg OK
15:58:56.183 [i]: Settings: loading frc.cfg OK
15:58:56.183 [i]: Settings: loading profiles.cfg OK
15:58:56.184 [i]: Settings: loading custom.cfg OK
15:58:56.184 [i]: Settings: loading lights.cfg OK
15:58:56.184 [i]: Main: using Qt 5.15.9 (x86_64-little_endian-lp64 shared (dynamic) release build; by GCC 12.2.1 20230201)
15:58:56.184 [i]: Main: device scale is 1.00132, user defined scale is 1
15:58:56.185 [i]: Main: system locale is [en]
15:58:56.185 [i]: Main: preferred language is [en-us]
15:58:56.186 [i]: Main: setting language file to en.qm...
15:58:56.189 [i]: Main: collecting system information...
15:58:56.190 [i]: Main: module 'plugins/libsvpflow1_vs64.so': 4.5.0.205
15:58:56.190 [i]: Main: module 'plugins/libsvpflow2_vs64.so': 4.5.0.212
15:58:56.191 [i]: Main: VLC filter (64 bit): 1.0.0.182
15:58:56.195 [i]: OS: Linux 6.3.2-x64v1-xanmod1-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 May 2023 04:32:43 +0000 x86_64
15:58:56.210 [i]: Desktop environment: /usr/bin/sddm / plasma / kde
15:58:56.212 [i]: CPU: Intel Core i7-10750H [base frequency 3560 MHz, 12 threads]
15:58:56.212 [i]: Video: reading OpenCL info...
Abort was called at 36 line in file:
/usr/src/debug/intel-compute-runtime/compute-runtime-23.09.25812.14/shared/source/built_ins/built_ins.cpp
fish: Job 1, './SVPManager' terminated by signal SIGABRT (Abort)Using Garuda Linux (arch-based). Ran all the updates.
Rendering and encoding a video in real-time? That's a joke, right?
That would require lower rendering settings and very low encoding settings that would make the output quality terrible.
Indeed, none of the image editing software use these upscaling algorithms; not sure why.
I also wanted to do exactly what you described and ended up creating the Yin Encoder as part of the Natural Grounding Player. This encoder will do what you want.
https://github.com/mysteryx93/NaturalGroundingPlayer
I've been doing major changes to the source code, splitting Natural Grounding Player from the Media Encoder, I'll want to switch over from Avisynth to VapourSynth for better stability and performance... and my local code has been broken for a while, but the latest published release should be working fine.
Now madVR and MPV are using even better upscaling algorithms; I can't use those yet. It's using SuperRes + SuperXbr which does a very fine job too.
For custom encoding, you have to use Avisynth or VapourSynth -- which are not for beginners. Then you need to do the whole editing and encoding process manually and be familiar with the various tools.
Also note that you can gain quality by increasing frame rate and upscaling with better algorithms, but then you'll also lose quality by re-encoding, so you can't encode with the same quality MadVR gives you. Although you could upscale and prepare the video with better quality that couldn't be done in real-time, which would make up for the quality loss. Then you can also trim or add black borders to your wish. It just takes time and knowledge to do.
Blackfyre, how do these MVP shaders compare to madVR's upscaling algorithms, and how do they compare to SuperRes that I implemented as a shader in Avisynth?
but this is a GLSL and not a HLSL file so AvisynthShader won't be able to work with it... not sure what it'd take to use it.
> No ffdshow x64 doesn't have a severe memory leak
it doesn't
Is this a Mandala effect, or why was MPC-HC x86 still recommended in the past then?
Blackfyre, MVP does allow upscaling shaders? However it doesn't look like it will allow for fine-tuned configuration like madVR to adapt to whatever your PC can handle.
As for HDR content, AFAIK madVR renders that properly.
nope, I guess
No ffdshow x64 doesn't have a severe memory leak, or no there's still no better option than MPC-HC x86?
but didn't ffdshow x64 have a severe bug making it a bad option?
I've always been using MPC-HC so far, which works only in x86 because of ffdshow. Not it has been a while, SVP supports all kinds of players. madVR also supports several players, but last I checked, the players supported by SVP and by madVR where mostly all different and I hadn't found a better option than MPC-HC.
Now in 2019, is there a better media player option that allows using both in x64?
told ya 
of course if masking is bad can't do anything; but in my "torture test" clip, with the scene with a moose moving in in a parade, I'm skipping interpolation altogether for all those frames. This trick makes the parade scene look a lot clearer, otherwise crowd is a blurry mess and anthers show as double-shadows.
Haven't done much testing to find the best ratio, so let me know what you find works best.
It's doing a really good job at masking the right areas -- but that work was kind of diluted for the fact that it was replacing artifacts with double-shadows and blurry images. Tweaking the blurring ratio is what's now making a huge difference, leveraging the good work that was already done. In the way I implemented it I'm pretty sure Occ mask isn't taking the borders, in fact very few spots rise above the threshold so it has a minor effect if I remember.
I haven't done too much testing but tested on a low-quality "torture clip" and on a 24fps video giving 5/2 FRC rate.
EM is "SAD mask (kind=1)" plus "Occ. mask (kind=2)".
Is there a problem with this? This was part of the original code I started from, but Occ mask doesn't seem to be doing much but it helps a tiny bit.
I wasn't getting good results with 0/100, it causes weird "fixed" areas to slide (relate to its surrounding) and then jump.
50/50 replaces artifacts with double-shadows.
So yes, 20/80 gives better result.
BTW, do you really mix two SAD masks together with the occlusion one?
Yes, I'm mixing two SAD masks as the artifact areas are slightly different depending on the DCT mode -- so although DCT=1 generally gives better results (but slow), some areas actually render better with DCT=0. This thus reduces the overall artifacts areas. Forget about doing this in real-time though!
Also adding StripeMask into it. This one probably could be added to SVP quite easily to remove artifacts due to stripes.
I just thought of a way of greatly enhancing image quality and eliminating ghost effects in artifact areas. Plus, it has 0 performance cost.
Reduce the frame blending ratio so that it blends 20/80 instead of 50/50!
I've implemented it here in FrameRateConverter and it could easily be added to SVP. No performance cost.
Does this new feature improve quality or simply gives more flexibility for special cases?
I see this new option in the latest version: Adaptive Pattern. How does it work and how should I set it? It's not yet in the doc.
Found the problem. Dusty fan
Ya I care about audio sync. This *will* cause sync issues? I did some quick tests of loading video and audio files separately and haven't seen sync issues so far. In which cases it would?
SmoothVideo Project → Posts by Mystery
Powered by PunBB, supported by Informer Technologies, Inc.
