1

(422 replies, posted in Using SVP)

Yeah, I got that. Thanks, I replaced that file changed on the last commit on the source package from that repo and rebuilt and it works fine now.

(building master from source wasn't that successful by default, but that's off topic here so no point continuing it)

2

(422 replies, posted in Using SVP)

Thanks, I bet it's that unofficial "multimedia" repo for debian that sucks and ruined it here, though I had tried a manual installation of vapoursynth and even if I clearly compiled mpv with support for it, it has an error at run time. I'll look into it some more.

update: Still does it

[vapoursynth] Could not initialize VapourSynth scripting.
Creating filter 'vapoursynth' failed.

3

(422 replies, posted in Using SVP)

The whole thing is

apoursynth.Error: Internal environment id not set. Was get_core() called from a filter callback?
[vapoursynth] Script evaluation failed:
[vapoursynth] Python exception: name 'video_in' is not defined
[vapoursynth] 
[vapoursynth] Traceback (most recent call last):
[vapoursynth]   File "vapoursynth.pyx", line 1841, in vapoursynth.vpy_evaluateScript
[vapoursynth]   File "/home/xxxxx/.local/share/SVP4/scripts/f3a29ddc.py", line 10, in <module>
[vapoursynth]     clip = video_in
[vapoursynth] NameError: name 'video_in' is not defined
[vapoursynth] 
Video filter chain:
  [in] 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited SP=1.000000 CL=mpeg2/4/h264
  [vapoursynth] "vapoursynth.00" 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited SP=1.000000 CL=mpeg2/4/h264   <---
  [out] ???
AV: 00:00:04 / 00:21:33 (0%) A-V:  0.000 Cache: 10s+73MB

and on svp

mesa: for the -simplifycfg-sink-common option: may only occur zero or one times!
10:35:12.905 [E]: Playback [f3a29ddc]: VS - Script evaluation failed:
10:35:12.905 [E]: Playback [f3a29ddc]: VS - Python exception: name 'video_in' is not defined
10:35:12.905 [E]: Playback [f3a29ddc]: VS - Traceback (most recent call last):
10:35:12.905 [E]: Playback [f3a29ddc]: VS - File 'vapoursynth.pyx', line 1841, in vapoursynth.vpy_evaluateScript
10:35:12.905 [E]: Playback [f3a29ddc]: VS - File '/home/xxxxx/.local/share/SVP4/scripts/f3a29ddc.py', line 10, in <module>
10:35:12.905 [E]: Playback [f3a29ddc]: VS - clip = video_in
10:35:12.905 [E]: Playback [f3a29ddc]: VS - NameError: name 'video_in' is not defined

4

(422 replies, posted in Using SVP)

"[vapoursynth] Python exception: name 'video_in' is not defined"

any clue?

https://i.imgur.com/5FWRTuW.png

"Note: that this's NOT recommended!"

That doesn't make much sense. The user has already used that component. If you mean - because that's what I suspect you mean - that all 64bit versions in general are less recommended, you should say that more clearly during installation, and not during updating, because it's like saying the NEW version is not recommended compared to the OLD.

PS. "This's" is grammatically wrong.

Wait I did, it's happening on any youtube URL. "Check your net connection (3)" is the tooltip.
I killed the process and restarted it (it would exit with right click->exit) and it immediately gave a "play this" tip normally, but then it got stuck again after a new youtube copy, weird.

https://i.imgur.com/Inr1S7w.png
That was ~11% on an 8 thread cpu.
Later on it stopped. Unfortunately I didn't keep the specific clipboard that did it.

Same thing happens with all similar tools, e.g. google drive is constantly monitoring, and svptube.

Chainik wrote:

And how much "system resources" you're saving this way?

I said it's minuscule, no reason to troll me, if you want to see for yourself use a basic monitoring tool and see that SVP is polling the system every few milliseconds at all times.

Nevermind. Got it. e.g.

CD "C:\Program Files (x86)\SVP 4\"
START SVPManager.exe
CD "C:\Program Files\MPC-HC\"
START /WAIT mpc-hc64.exe %1
TASKKILL /F /IM SVPManager.exe

It has no cosmetic tweaks of any kind (yet).

Does anyone have a batch script for windows ready that does such a thing. I mean even for the common background processing of opening any video with MPC-HC on the explorer or elsewhere. The reasoning is a minor optimization for system resources.

To be more precise, HDMI version 1.4 has the bandwidth to do 1080p 120hz so supporting devices can easily do higher than 60hz a lot of the time, but since it may not explicitly demand it as a spec (beyond demanding the bandwidth) some people report it can't do it (which isn't true in many cases) and hence the controversy.

I just found out HDMI version 1.4 supports 1080p on 120Hz. Maybe that's your issue. On version 2.0 (is that even out?) it can even do 4K 60Hz.

Jeff R 1 wrote:

You're not going to get any more then 60fps no matter whet the product if you're using a computer.
60 fps is the max amount that HDMI can handle, anything higher then that is done inside the display or the computer, but in the end the HDMI connection is limited to 60fps.

That is not true. I routinely overclock common monitors to 76Hz and the testing tools report no artifacts and the picture is clearly smoother. Maybe you confuse it with monitors or graphics cards that can't go above 60Hz or older HDMI specifications?

What I will admit is that I find it more "crisp" in playback in some cases. But in other cases SVP seems better and smoother. But the severe limitation of 25FPS sources not working and the max 60FPS at the moment make it at best a partial alternative, not a replacement.

You might have heard in the past that AMD GPUs have nowadays a built-in "SVP" (utilized on Windows with the BlueskyFRC plugin).

However, I think it's important to point out that the AMD driver only supports 24FPS(x5/2) and 30FPS(x2) videos.

That means 25FPS videos do not work with it and it might only go up to 60FPS.

Something odd is if that I force software deinterlacing to 50FPS and SVP does not assume that frames are doubled, it does attempt to go to 76FPS, but the video is choppy/has hiccups.

I guess it's normal, and it wouldn't do anything better even if it worked well that way(there would be no more visual info to process+slower) but I thought of mentioning it.

Forced software deinterlacing to 25FPS + SVP not assuming frames are doubled works fine.

Chainik wrote:

>  It then goes on to assume "the file is 50FPS because it's interlaced". Does that mean the software remains practically disabled?

yep
and there's an answer in the FAQ
there and one question above

Ah. Great info. I guess it's more complex than I thought.

The video did look already to be 50FPS on "no soft di".

I guess something does it automatically.

I can see the "50FPS" source is interlaced. It then goes on to assume "the file is 50FPS because it's interlaced". Does that mean the software remains practically disabled?

I don't know if this might be useful.

A video that plays properly:

20:41:53.142: VideoPlayer: new ffdshow video [20ca4] in mpc-hc.exe (32-bit) [MPC-HC 1.7.10.276] on screen 0
20:41:53.170: Media: video 1916x1076 [PAR 1.000] at 25.000 fps [constant]
20:41:53.170: Media: codec type is AVC, YUV/4:2:0/8 bits
20:41:53.171: Playback: starting up...
20:41:53.171: Playback [20ca4]: Frame server (32-bit) 2.6.0.5, Avisynth 2.6, C:\WINDOWS\SysWOW64\avisynth.dll
20:41:53.175: Playback [20ca4]: resulting video frame 1916x1076
20:41:53.175: Playback [20ca4]: 1 acceptible profiles, best is 'Automatic' [0]
20:41:53.175: Playback [20ca4]: enabled while video is playing
20:41:53.176: Profile: using auto values [1]
20:41:53.186: Playback [20ca4]: playing at 76.4706 [25 *52/17]
20:42:54.538: FFDShow: remove instance [20ca4]
20:42:54.538: Playback [20ca4]: disabled while video is stopped
20:42:54.840: Playback [20ca4]: deleted

A video that goes 50FPS:

20:43:00.140: VideoPlayer: new ffdshow video [90872] in mpc-hc.exe (32-bit) [MPC-HC 1.7.10.276] on screen 0
20:43:00.236: Media: video 1920x1080 [PAR 1.000] at 25.000 fps [constant]
20:43:00.236: Media: codec type is MPEG Video, YUV/4:2:0/8 bits
20:43:00.236: Media: scan type is interlaced, assuming 50.000 fps instead of 25.000 fps
20:43:00.237: Playback: starting up...
20:43:00.237: Playback [90872]: Frame server (32-bit) 2.6.0.5, Avisynth 2.6, C:\WINDOWS\SysWOW64\avisynth.dll
20:43:00.240: Playback [90872]: resulting video frame 1920x1080
20:43:00.240: Playback [90872]: 1 acceptible profiles, best is 'Automatic' [0]
20:43:00.240: Playback [90872]: enabled while video is playing
20:43:00.241: Profile: using auto values [1]
20:43:00.249: Playback [90872]: playing at 50 [50 *1/1]

PS. Your forum does not accept the "[\I]" of the log without them being removed

e.g. on this upload of a tv show it appears to only go to 50FPS when the monitor is 76Hz:

https://i.imgur.com/4QF23qV.png

On every other file it works normally:

https://i.imgur.com/nBO3cDi.png

22

(9 replies, posted in Using SVP)

Stop spamming. Your program directs users to "download it" and it asks for money. It's ugly.

Ye that's how it always worked.

24

(8 replies, posted in Using SVP)

Most of the "artifacts" are just the original source being completely choppy at that point. We are used to the slide-show of 24 FPS and we think it's "normal". While SVP will expose those gaps easily (without special filters like 2m I guess), it's still nothing that bad, considering the alternative is the choppy slide-show of the original source.

PS. e.g. hero jumps from ground to ladder, you may see an "ugly artifact" on SVP, but in reality on the original source you see nothing at all between the jump and the ladder!1 So, while some people badmouth interpolation as ugly, they often ommit to mention that their "perfect" original source has absolutely no data to show between those two points. So one could make the easy decision that "I'm AWARE of those gaps now, it doesn't mean they didn't exist before".

25

(19 replies, posted in Using SVP)

Never use old GPU drivers. Even if they are 1 month old. GPU pipelines are extremely complex and the bugs numerous.

Also if Windows updates, it may break the way the drivers work.

In general, always use the latest stable GPU driver.