a part of SVP's log starting from "VideoPlayer: mpv ..." could be helpful
You are not logged in. Please login or register.
SmoothVideo Project → Posts by Chainik
a part of SVP's log starting from "VideoPlayer: mpv ..." could be helpful
> --input-file=/dev/stdin
мда?
"official" mpv.exe won't work!
...cause it was built w/o Vapoursynth AND doesn't support "input-unix-socket" feature
according to the sources such a loop can only be if MediaInfo returns zero for the "Width" attribute
> SMPlayer после замены mpv.exe и mpv.com на аналогичные из папки C:\Program Files (x86)\SVP 4\mpv64 работать отказался.
не надо менять
надо в настройках SMPlayer-а указать путь к SVP 4\mpv64\mpv.exe
а если уж именно менять, то надо позаботиться о путях к vapoursynth.dll и прочим питонам
> I assume the SVP setup program installed vapoursynth
It uses the "portable" versions of both Python and Vapoursynth, so mpv.exe should work from the mpv64 folder only.
BUT those "portable" versions lack VC++ 2015 libs - this' why it have to be installed separately. SVP setup should do this automatically - but, well, "shit happens"
В логе написано где именно находится старый avisynth.dll 2.5. Надо его оттуда убрать.
again - what's in the log?
mpv.exe depends on vapoursynth.dll depends on python 3.5 and vc++ 2015 redist
there're three different paths on Windows now:
1. ffdshow32 + Avisynth 2.6 + any DS player
2. ffdshow64 + Avisynth+ x64 + any DS player
3. vapoursynth64 + mpv
I know it's confusing...
SVP 4 Pro 4.0.0.72 умеет работать с mpv.
mpv, собранный в точности так же как там (т.е. как официальная Windows-версия), но с добавлением Vapoursynth.
Дополнительно к этому сделана одна существенная для SVP модификация: SVP использует JSON IPC, которого НЕТ в версии под Windows (потому что там сделано на unix domain socket, и они по идеологическим (?) причинам не хотят заменить это на TCP сокет).
Пришлось впилить самостоятельно, в основную ветку mpv на github-е пока не пропихивается, т.к. авторы считают что это аццкая дыра в безопасности (что, в целом, правда, но этим фактом вполне можно пренебречь)
Теперь параметр '--input-unix-socket=<TCP-port-number>' включает TCP сервер на указанном порту.
Устанавливаем mpv.exe и/или mpv-1.dll через менеджер пакетов SVP.
Как нетрудно догадаться, .exe нужен для запуска голого mpv или SMPlayer-а.
.dll нужен для всякого основанного на библиотеке - например Plex Media Player.
Быстрый старт
1. Установить пакеты:
- [VPS_64] Core for Vapoursynth 64-bit
- [VPS_64] mpv video player
2. Открыть видео файл через Менеджер
Плееры
- mpv
- SMPlayer - граф.интерфейс для mpv
- Plex Media Player - пример плеера, основанного на библиотеке mpv, тут надо заменить mpv-1.dll на dll из пакета "[VPS_64] mpv shared library"
- ...
Настройка mpv
В целом, он умеет всё, включая всякие навороченные скейлеры из madVR.
> No madVR
Software scalers: https://mpv.io/manual/master/#software-scaler
Video output drivers: https://mpv.io/manual/master/#video-output-drivers
opengl: search for "superxbr", "nnedi3" and others
===
mpv can do whatever every other player can (and even more)
but its configuration just "a little bit" complicated
so SMPlayer is a good option to start with mpv
уже можно
да, накладочка вышла, сейчас поправим
надо будет еще раз обновить svplight
Vapoursynth is just a way more efficient and stable than Avisynth when it comes to multi threading and 64-bit support.
так надо и svplight обновить
SVP 4 Pro 4.0.0.72 supports mpv 64-bit via Vapoursynth FRC engine.
Quick start
1. install these packages:
- [VPS_64] Core for Vapoursynth 64-bit
- [VPS_64] mpv video player
2. open the video file via SVP Manager
Video players
- mpv
- SMPlayer - a GUI for mpv
- Plex Media Player - replace mpv-1.dll with the one from "[VPS_64] mpv shared library" package
- ...
mpv setup
если цель ставилась как "покупаю для того, что бы конвертировать видео" - то определенно зря
такая функция в списке возможностей SVP 4 Pro (пока) не заявлена
please try 4.0.0.72
> Сформировать-AVS-фильтр для xvid4psp5
> но где найти это в SVP4 ?
нигде
это инструкция для SVP 3
Here's the full script generated by the current windows dev. build:
import vapoursynth as vs
core = vs.get_core(threads=7)
core.std.LoadPlugin("<svp-path>\\plugins64\\svpflow1_vs.dll")
core.std.LoadPlugin("<svp-path>\\plugins64\\svpflow2_vs.dll")
clip = video_in
clip = clip.resize.Bicubic(format=vs.YUV420P8)
crop_string = "core.std.CropRel(input,0,2,0,0)"
resize_string = ""
super_params = "{scale:{up:0},gpu:1,rc:true}"
analyse_params = "{main:{search:{coarse:{distance:-8,bad:{sad:2000,range:24}},type:2}},refine:[{thsad:250}]}"
smoothfps_params = "{gpuid:11,rate:{num:5,den:2},algo:13,mask:{area:200},scene:{}}"
demo_mode = 0
stereo_type = 0
########## BEGIN OF base.py ##########
# This file is a part of SmoothVideo Project (SVP) ver.4
# This is NOT the full Vapoursynth script, all used variables are defined via
# JScript code that generates the full script text.
def interpolate(clip):
input = clip
if crop_string!='':
input = eval(crop_string)
if resize_string!='':
input = eval(resize_string)
super = core.svp1.Super(input,super_params)
vectors = core.svp1.Analyse(super["clip"],super["data"],input,analyse_params)
smooth = core.svp2.SmoothFps(input,super["clip"],super["data"],vectors["clip"],vectors["data"],smoothfps_params,src=clip,fps=container_fps)
smooth = core.std.AssumeFPS(smooth,fpsnum=smooth.fps_num,fpsden=smooth.fps_den)
if demo_mode==1:
return demo(input,smooth)
else:
return smooth
if stereo_type == 1:
lf = interpolate(core.std.CropRel(clip,0,(int)(clip.width/2),0,0))
rf = interpolate(core.std.CropRel(clip,(int)(clip.width/2),0,0,0))
smooth = core.std.StackHorizontal([lf, rf])
elif stereo_type == 2:
lf = interpolate(core.std.CropRel(clip,0,0,0,(int)(clip.height/2)))
rf = interpolate(core.std.CropRel(clip,0,0,(int)(clip.height/2),0))
smooth = core.std.StackVertical([lf, rf])
else:
smooth = interpolate(clip)
########### END OF base.py ###########
smooth.set_output()
> Why does SVP need to downscale in the first place?
it doesn't "need" but "can"
to reduce CPU load at the first place
so, the question is simple:
1. when we watch 3840x2160 video on 3840x2160 screen it renders pixel-per-pixel, obviously
2. what about watching 3840x2160 video on 1920x1080 "Retina" screen? will it be rendered pixel-per-pixel OR it will be scaled down to 1920x1080 by mpv and then processed by some magical internal OS X scaler?
I can't reproduce this, however I see where the problem can be (though I've no idea WHY)
Lets wait for the next release (later on this week) and return to this thread...
SmoothVideo Project → Posts by Chainik
Powered by PunBB, supported by Informer Technologies, Inc.