You are not logged in. Please login or register.
SmoothVideo Project → Posts by NM64
I don't suppose this works with the newly open-sourced ZLUDA for running CUDA software on AMD GPUs?
https://github.com/vosen/ZLUDA
https://www.phoronix.com/review/radeon-cuda-zluda
One particularly key interesting point from the Phoronix review on page 3 is that Blender actually ran faster with CUDA + ZLUDA than its native HIP codepath, so it's within reason that ZLUDA could also be faster than Vulkan for AMD GPUs.
However, I can run "vspipe."
There doesn't seem to be mention if these missing symbolic links are going to be a problem in the Vapoursynth or SVP posts. Should I continue to solve this issue? Should I continue asking here or on the Vapoursynth forum?
First off, I'm totally not at all a Linux guru, so I am really not sure if I can actually help you...
But, can you at least confirm what vendor of GPU you are using - AMD, Intel, or Nvidia?
Thing is, if you are using AMD or Intel, then I wouldn't be surprised if you can ignore your issue because "libcuda" refers to CUDA which is Nvidia-only and could very well explain why you're getting the result that you are.
Is bumping allowed on this forum?
My revamped HTPC that uses Linux instead of Windows is looking to be ready before the end of the month, and I've still no solution for this...
I recently (today) tried to recompile everything with av1 support, ended up with the same error about libdav1d
My revamped HTPC that uses Linux instead of Windows is looking to be ready before the end of the month... any status update regarding getting AV1 software decode working?
That won’t work either. With rusticl, SVP will break for all open source drivers in the foreseeable future.
I don't suppose there's a status update regarding this now that RadeonSi has enabled RustiCL support in Mesa 23.1?:
https://www.phoronix.com/news/RadeonSI- … -Mesa-23.1
Psst, am I crazy or does the "autospeed" script straight-up not work for changing playback speed in the compiles mpv+vapoursynth? As I mentioned in the dedicated thread, I was trying to use it to make only 25fps videos play at 24fps, but it's not doing anything...
https://www.svp-team.com/forum/viewtopic.php?pid=81126
I now have GPU acceleration working
It may have been easier if you just used the newly-developed rusticl paired with the standard default kernel-level AMD graphics drivers and mesa 22.3:
https://lists.freedesktop.org/archives/ … 25898.html
I just never said much of anything about it because I've not managed to test it out myself just yet and therefore I cannot say from experience what the exact steps are to enable rusticl for AMD graphics considering that rusticl as a whole is disabled by default.
install meson?
It wasn't clear to me that "meson" was an actual package that could be installed. Also, nowhere in the wiki article is "meson" mentioned.
Nevertheless, that was all that was required to get it to work.
That being said, I still had to forgo AV1 because both libdav1d and libaom were throwing up the error shown in the below screenshots. Not having AV1 decode isn't particularly important for this test system, but it would be kind of annoying to not have it for the final PC configuration (which could still be several months away).
Much like how reclock worked on Windows, I want to be able to slow down ONLY 25/50fps videos to 24/48fps with the corresponding reduction in audio pitch in order to cancel-out any PAL speed-up (PAL speed-down?) while leaving videos that are already 24fps/48fps and 30fps/60fps to play back as-is without any speed and pitch alteration.
The usual go-to solution seems to be to use autospeed.lua (not to be confused with autospeedwin.lua) but, for whatever reason, it just seems to do absolutely nothing on my Linux Mint 20.3 system despite using a really bare-bones mpv.conf file, not to mention that SVP itself works and other lua scripts are also working (most easily confirmed by the pause-when-minimize.lua script)..
Heck, my test mpv.conf file is so basic that I don't think I even really need to attach it as a separate file:
input-ipc-server=/tmp/mpvsocket
video-sync=display-resample
script-opts=autospeed-maxspeed=1.01
script-opts=autospeed-minspeed=0.9(I don't even know if that would include the corresponding reduction in audio pitch that I also require but, at this point, I'm just trying to get things working at all)
This was tested using a specific 50fps video clip that I find to be extremely good for noticing judder re-encoded to 25fps (aka removing every other frame) and then making a second copy that was then encoded to 24fps by manually slowing it down a bit; from there I have SVP configured to always perform 2.5x interpolation.
And, as a sanity check, I also tried taking the very same aforementioned encoded-to-25fps video clip and made another copy that's encoded to 30fps by manually speeding it up, and then made yet another copy that was encoded to 31fps, also by manually speeding it up and with SVP configured in that test scenario to always perform 2x interpolation instead.
With my 60Hz display, if things were working, I would think that the 25fps and the 31fps videos would be played at 24fps and 30fps, but they are not and are noticeably juddery compared to the 24fps and 30fps copies, implying that autospeed is not doing anything.
(I even tried using the "script-opts=autospeed-osd=true" option under the assumption that it'd make things more obvious if the script is doing anything but, alas, no OSD showed up).
Apologies for the double-post, but I'm following the wiki to a T on a new installation of Linux Mint 21.0 Cinnamon that has had nothing done to it other than some minor GUI tweaks (set "Traditional" panel view, set desktop background, those sort of things).
Everything seems to go fine but, in the final steps of installing mpv+vapoursynth, I'm getting the following - what do?:
I even tried typing in "waf configure" in the terminal but it doesn't have a clue what that means, implying to me that "waf configure" is not a traditional terminal command in the way that something like "cd /." is.
(and the ".waf found" is just because that was the second time I ran the corresponding command, so it's just re-using the pre-existing .waf file - the above error still happens even on the first attempt as well)
For reference, I never had any issues on Mint 20.3 installing mpv+vapoursynth by following the wiki's instructions, but Mint 21.0 seems to be a different story...
Psst by the way, is the mpv compile option for dav1d by chance:
--enable-libdav1d
yes/no? I only ask because it's not included in the list of mpv/ffmpeg options above (the same list that the SVP wiki page links to).
-no-tray ?
Hmm, that works but has a worse result by subsequently displaying the SVP program window instead whenever SVP is launched.
I'm guessing the way it works is that you always either have the tray or the program window, and it is impossible to have SVP running in the background without having either of those be present?
Also, about the update notification, the issue is actually that I've set up my OS to do automatic background updates since I've even got TimeShift snapshots being backed up to a second drive, so this means that SVP is the only thing left that's basically displaying visible update notifications. Therefore, alternatively, if there's some way to update SVP in the background through my package manager, then that would also totally work (and could actually even be preferable). SVP being made available as a flatpak would also work because I similarly have my update manager set to automatically update flatpaks.
Unconventional question - is it possible to make the tray icon not be present?
Currently the only tray arguments I know of is -tray which is only for making the tray icon appear when, by default, SVP's tray icon is not visible. But what about if SVP's tray icon is visible by default - is there some way to then tell SVP to hide its tray icon?
While I'm here, I don't suppose it's possible to tell SVP to never automatically check for updates?
Just tried Homebrew, and it works. It takes _a_lot_ of time though, but it's fully automated, has almost everything built-in, and you don't need to know anything about building stuff.
Does it include the dav1d AV1 decoder?
the only minor issue there's some Python conflict only when running Homebrew's mpv from SVP
Are you referring to if one associates or opens a video file with SVP itself so that it then automatically opens in mpv with the correct arguments?
if you run it from any other place it works
So are you say that if we instead associates or opens a video file in mpv directly, it'll work then? Do we still need to add --input-ipc-server=/tmp/mpvsocket to our mpv.conf file though?
Hey um, I just realized that the post with slew of mpv+vapoursynth compile options doesn't list dav1d - so what would be the corresponding "ffmpeg_options" argument for dav1d?
I personally think than inexperienced users should not run Linux at the first place, Windows is good enough for everyone
Ehhh... I'm a PC hardware enthusiast through-and-through but software is actually quite a weak point for me (I cannot code worth a darn, and I have major trouble remembering terminal commands).
A big reason I switched to Linux is because I was becoming dissatisfied with the... "software BS" associated with post-7 versions of Windows that seems to become worse and worse with each subsequent version - "software BS" that, in my mind, gets in the way of just letting me using my hardware as I deem fit.
To give some perspective, I'm also a user of Pale Moon rather than Firefox or Chrome, and much prefer the "function-over-form" web design of the mid to late 2000s as is used by places like romhacking.net or vndb.org rather than the "modern" design seen on the likes of the websites for the Framework laptop or Linux Mint.
Speaking of which, keep in mind that I use Linux Mint which is quite the "baby's first Linux", and I would argue that it's better for beginners than Windows nowadays, in large part to its "no BS"-ness (which is amusing considering they've gone with a "modern" design for their website, but it's my understanding that they largely did it #1 for sort of marketing to "normies" and #2 they purchased a pre-existing site design since they didn't have anyone around to write one from scratch)
if you're interested in AV1 decoding you should build with dav1d
Ah right, I forgot that was a thing.
but this definitely isn't a minimal install
I mean, I would argue that including nvdec and vaapi is also not a minimal installation (which historically were not listed on the wiki as seen by this previous revision of that wiki article).
I'll build it on a clean 22.04 and update the instructions.
I see that you added some additional ffmpeg options to the mpv compilation step; any chance of also adding
echo --enable-libaom >> ffmpeg_optionsto the instructions so that other beginners don't run into the issue of AV1 not working like I ran into above now that AV1 is becoming more common on YouTube?
Has anyone gotten SVP to work on POP OS?.
Since it's based on Ubuntu, have you tried the thing mentioned a few posts up that was required to get it working on Ubuntu 22.04?
I built an SVP4 environment on "Ubuntu 22.04" based on "https://www.svp-team.com/wiki/SVP:Linux" but mpv does not work. mpv's video filter "Vapoursynth" does not seem to be properly investigated. So instead of "echo --enable-vapoursynth >> mpv_options" when building mpv, I used "echo --enable-vapoursynth >> ffmpeg_options" and it worked properly
Sure enough, all I had to do was add:
tone-mapping=hable...and HDR videos now "look good" to my eyes in the compiled mpv+vapoursynth on my SDR monitor.
Curiously, none of the 'tone-mapping' settings matched the result displayed by Celluloid; this isn't really a problem but it was interesting nevertheless.
Apologies for the late response - for some reason I was not getting email notification of replies...
Nevertheless, I was reminded of this thread when I stumbled across two random 18fps videos which is an uncommon enough framerate that I didn't have a manually-created profile for it.
Chainik wrote:all settings -> frc.target.tolarance, you can set it to the big enough value
This would be a good solution, except that it allows for rates higher than the monitor can do as well.
Yeah, I've discovered another scenario where, even on a non-VRR display, getting an integer value is ideal and the issue of it going to the integer above is problematic - Linux combined with mpv-plugin-xrandr.
(do note however that "mpv-plugin-xrandr" is by default configured to switch to your monitor's lowest refresh rate that's an integer of the video's frame rate which makes it poor for use with SVP; see my comment on the project's git on how to make it instead switch to the highest refresh rate that's an integer of the video's frame rate so as to make it work well with SVP)
If you use a monitor that maxes out at 75Hz and, for 30fps videos, your have your Linux PC automatically change your monitor refresh rate 60Hz via mpv-plugin-xrandr, SVP will still interpolate that 30fps video by 2.5x to 75fps if you use the "to screen" setting in SVP. Furthermore, if you adjust the frc.target.tolerance setting to a larger value accordingly to get it to only interpolate to a non-fractional integer value, it will instead end up interpolating by 3x to 90fps.
I think this is because 75Hz is exactly in between 60 and 90, and SVP defaults to rounding up. I say this because, with the same scenario but with a 24fps video and having your 75Hz monitor automatically change to 72Hz, adjusting the frc.target.tolerance setting accordingly and using "to screen" does indeed result in 24fps being interpolated by 3x to 72fps.
The "frc.target.tolerance" setting work-around would work flawlessly if it instead just always rounded down - this would allow even the rare monitor that maxes out at 85Hz would still have a 30fps video interpolated by 2x to 60fps when using "to screen" (or, in a more common scenario with a 144Hz monitor, have 25fps videos be interpolated by 5x to 125fps rather than to 150fps).
I don't suppose anyone know if something special needs to be done to make HDR videos look correct on an SDR display in the compiled mpv+vapoursynth? They look overly blown-out compared to the same video played in Celluloid with the default configuration provided by Mint 20.3, and the result in Celluloid looks very similar to the SDR version of the very same video(s).
For reference I'm just using YouTube HDR videos for this; here's a very recent example video of such:
https://youtu.be/MuzwlZi7FP8
(the main reason I'm trying to do this is because I don't have the grunt to interpolate 1440p videos but I can do 1080p videos, and YouTube's HDR 1080p encode gets over double the bitrate of their equivalent SDR VP9 encode)
echo --enable-libaom >> ffmpeg_optionsWhen I used "libaom", it was able to decode normally.
You're probably a more experienced Linux user than me, so could you elaborate more specifically on what you did? I ran that in the terminal and it seemed to do nothing (I honestly didn't think it would) so clearly there's something more specific that one is supposed to do with that.
I used "echo --enable-vapoursynth >> ffmpeg_options" and it worked properly.
Could you quickly check if AV1 decode support works? When I built mpv+vapoursynth on Mint 20.3 a few months ago, it was unable to decode AV1 video dsspite the very same AV1 video working in the "Celluloid" application that comes pre-bundled with Mint 20.3.
If you need an example AV1 video (note that it's a tiny 256x128 resolution in order to keep file size down):
- https://ttm.sh/wad.mkv
If you run into the same situation there I do where audio plays but there's no video nor even a video player, then you'll have to end the mpv process via the system monitor in order to get the audio to stop.
I'm just trying to figure out if there's an easy way on a 144Hz VRR monitor to get all of the various typical frame rates interpolating at their maximum integer factors without manually creating profiles for every single framerate.
From what I can tell, one currently has to manually create 6 individual profiles (7x for 20fps, 6x for 24fps, 5x for 25fps, 4x for 30fps, 3x for 48fps, 2x for 50fps and 60fps), and that's without considering that the user may very well want different settings for different resolutions as well, meaning you could end up with something like 18 or more (6 for 1080p, 6 for 720p, 6 for 480p and below, etc).
EDIT: make that 7 individual profiles - I just stumbled across some 18fps videos which, for 144Hz, would use 8x interpolation.
Maybe you're misunderstanding me?
With the test scenario of a 25fps video clip, the refresh rate at 60Hz, SVP set with "To screen" and "1m", that still results in it interpolating by 2.4x to 60fps with 60 unique frames in the resulting video...and 2.4 is not an integer value.
Just a simple question - is there some way to have the "To screen" interpolation option only work in full integers to whatever the maximum frame rate would be without exceeding the refresh rate?
What made me think of this is that my friend just recently bought a 75Hz monitor that supports adaptive sync, and I can't help but wonder if on such a monitor that playing 24fps video content would still interpolate to 75Hz (3.125x) rather than to 72Hz (3.000x).
And yes, you could make manual separate profile for individual frame rates, e.g. 3x for 20 to 25fps and 2x for 30fps but, with variable refresh displays becoming more common, this seems like a simple function that'd become ever-more useful going forward (especially with high-refresh monitors where this manual setup would be particularly tedious, e.g. on a 144Hz adaptive sync monitor you'd need to configure 7x for 20fps, 6x for 24fps, 5x for 25fps, 4x for 30fps, 3x for 48fps, 2x for 50fps and 60fps...).
Did you remember to set the .run to be executable? I just ran it from terminal (./svp-4-linux-64.run) and it worked fine for me.
Strangely running it from the terminal does indeed work despite double-clicking via the GUI not working and it being set to be executable.
Nevertheless, this issue doesn't occur on (x)ubuntu 22.04 so I figure it's an OS bug or something that's since been solved and will subsequently be solved with Mint 21.
I just found out that Rusticl supports OpenCL image support in mesa; if it's to be merged into mainline mesa then it'll be in 22.2 at the very earliest.
This would make GPU-accelerated SVP on AMD GPU hardware become way easier to setup (I say this typing from a Ryzen 4800U right now which apparently is straight-up not even supported by ROCm), and could similarly become the go-to solution for Intel hardware as well since the existing Intel OpenCL ICD Loader is no longer maintained and therefore has a questionable future.
UPDATE: Rusticl is now able to run Darktable's OpenCL which also relies on image support.
Could we ditch the GUI installed and just provide a binary archive
I've kind of wondered why it couldn't just be offered as a flatpak when even highly-proprietary software like Discord is even offered as a flatpak directly on flathub.
On the subject of the ".run", am I crazy or does it not even launch at all on both Mint 20.3 and LMDE5 (Linux Mint Debian Edition 5) and presumably also Debian 11 which LMDE5 is based off of?
----------------------------------------------------------------
Using SMPlayer and SVP on Linux Mint 20.3. When I load a video, the video plays for a second or two, then stutters when SVP takes over. Any idea on how I can stop that?
Does the stutter persist for the entire time that SVP is running? If so then you might want to try updating mesa - there was a similar sort of stutter issue I ran into with video playback on Intel GPUs that I believe updating mesa fixed but I can't say for sure (basically the issue only occurred on test OS installations where I just happened to never update mesa and, similarly, OS installations where I had already updated mesa just simply never exhibited the issue). For reference I simply followed the usual "linux gaming" recommendation of installing the "kisak-mesa" PPA for updated mesa.
If the stutter only occurs right at the moment when SVP "kicks in" but then goes away after a second or so, then this might not be something that can be solved as it's something even I've noticed for many many years (going back to SVP 3.1) even on Windows with MPC-HC.
BTW while you're here, do you have the same issue that I do that I described above where double-clicking SVP's ".run" installation file on Mint 20.3 simply does nothing? How did you work around that outside of using the old version of the installer from archive.org that I linked to on the previous page?
SmoothVideo Project → Posts by NM64
Powered by PunBB, supported by Informer Technologies, Inc.