/mpv/ - the Sup Forumsreatest media player

Installation:
mpv.io/installation/

Wiki:
github.com/mpv-player/mpv/wiki

Manual:
mpv.io/manual/master/

User Scripts (including opengl shaders):
github.com/mpv-player/mpv/wiki/User-Scripts

High quality video output profile (goes into mpv.conf):
profile=opengl-hq
mpv.io/manual/master/#configuration-files

Input.conf:
github.com/mpv-player/mpv/blob/master/etc/input.conf

Post your system specs and config if youre asking performance related questions.

Vulkan is out!

Other urls found in this thread:

github.com/mpv-player/mpv/wiki/Video-output---shader-stage-diagram
youtube.com/watch?v=EFRpFkZFrOU
sourceforge.net/projects/mpv-player-windows/files/Test/
youtube.com/watch?v=HUUsEgAe8x4
pastebin.com/raw/eXEV1zSN
twitter.com/NSFWRedditGif

Been using it for 3 months now. It's pretty great - it just works, no real config required.

# VIDEO
profile=gpu-hq
gpu-api=vulkan
gpu-context=win
scale=haasnsoft
scale-clamp=0.5
cscale=ewa_lanczos
sigmoid-slope=10.0
vd-lavc-dr=yes
vd-lavc-threads=32
glsl-shader=~~/shaders/ravu-r4.hook
#glsl-shader=~~/shaders/KrigBilateral.glsl
gpu-shader-cache-dir=C:/Users/Yui/AppData/Local/Temp/mpv-vk

# COLOR MANAGEMENT
icc-profile-auto=yes
icc-cache-dir=C:/Users/Yui/AppData/Local/Temp/mpv-icc

# INTERPOLATION
video-sync=display-resample
tscale=robidouxsharp
interpolation=yes
deband-iterations=2
deband-range=12
temporal-dither=yes

Best config coming through

Nice config, user. Very original.

My (fixed) question from last threat:
>I get RAVU r4 being better than r3 being better than r2 but how does RAVU lite rX fit into this?
>What is "lighter" about it and does the rX correlate with the rX of the normal RAVU?
>If it were a faster version with no disadvantage I assume it would be the default, so why does it exist and what does it different?
>I do get the -chroma versions but when am I supposed to use the -rgb and -yuv versions?
>If all I want to do is "replace" scale (I know it's just a prescaler) then should I use the version without any suffix?
>And why does lite not have these rgb/chroma/yuv suffixes?
>I'm so confused and bjin's readme doesn't help here at all...


My GPU is old and weak, doesn't even have compute shaders, so I think I can't do luma and chroma and therefore wanted to settle for luma prescaling only (no suffix, as you've confirmed).
However, going by your reply it seems I can just use -yuv and get prescaling for both for the same performance? (I'm aware that cscale is still used to further upscale chroma)


And how do the "lite" versions fit into all of this?

Tell me resolution of your videos and your display's resolution.

Do you want to try to estimate required processing power? Other than that I don't see how it's relevant.
I wanted to use it in general, for all videos. I'm usually assuming a scenario where I watch e.g. 720p or 1080p on a 1080p screen, sometimes old 480p DVD stuff.
I'm aware that the prescaler won't do unneeded work when upscaling is not necessary.

RAVU is a doubler. If you have 1280x720 video it will double that resolution to 2560x1440. Considering your monitor is 1920x1080, you then will have to downscale it back (default=mitchell) to your monitor's resolution. It is a very "placebo" thing to do and very inefficient if you have a weak GPU. Doublers work best when your video resolution is very low compared to your monitor's resolution. Consider using SSSR instead of RAVU for 720p+ videos. You can setup a profile for low resolution videos to use RAVU on with auto-profiles.lua script. Of course you can just use RAVU for everything if you can afford it and cant be arsed to set up profiles. RAVU RGB r3 is what bjin suggested to use for most people in older readme version. RAVU lite is like a half of regular RAVU speed wise but NOT visual wise. It looks somewhat softer but still pretty decent.

> shinchiro: would it be too much trouble to ask you to make a beta build of the vulkan-rev2 branch?
> testing on windows with the official AMD drivers would be great
> hanna: sure, not really trouble 4 me :)

I know people here jerk off to hanna and rossy mostly. Shinchiro so underrated. I made my switch from madVR thanks to him.

Onii-chan, why doesn't mpv have a built-in, finely tuned, anime preset so we don't have to copy/paste bullshit settings from people who don't know what they're doing?
Why don't mpv devs just give us a really good preset?

Just tick "let madVR decide" :^)

return to reddit

Doubling up RAVU using

glsl-shader=~~/shaders/ravu-r4.hook
glsl-shader=~~/shaders/ravu-r4.hook]/code]

Doesn't seem to be working with vulkan(or win?) I'm using the newer vulkan build.

The videos range from DVD to 1080p being upscaled to 2160p on my display, since Krig isn't working yet would it be a better idea to use R4-RGB or just ewa_lanczos for chroma?

Good job using the wrong fucking bracket me

>Doesn't seem to be working with vulkan(or win?)
You need to update your RAVU shaders. bjin released a version designed for Vulkan recently.
>Krig
Just use ewa_lanczos. Also use Krig only if you have spare resources since chances are you wont be able to which is which side by side.

When I said I'm using the Vulkan build I meant the RAVU shaders in the Vulkan folder from bjin's Github, I don't know why I said build there.

>Also use Krig only if you have spare resources
Well right now I'm getting about 3800-4000ms frame timings (Fresh) + 700ms Redraw with 1080p BD content using lanczos for chroma, bilinear for luma scale (does this automatically for 1080p) and one pass of R4

Does RAVU pixel shift?

Also for the record the non-vulkan RAVU will just give you a bluescreen with Vulkan, similar to what it does with ANGLE. But trying to get two passes going with Vulkan doesn't seem to be working,

give me one reason to use this over VLC

if you need to be convinced you don't need to be here

Yeah seems reasonable. Why is the estimated FPS unreliable for you, though? Although if you're using stats.lua then simply displaying the OSD takes a quite a lot of GPU power.

The ‘rX’ just means filter radius X. So r4 means it consults pixels within a radius of 4.

Idunno RAVU from the Vulkan folder works fine for me. Win7, AMD.

So stacking the compute shader twice results in four instances of it in your stats.lua when playing back video?

github.com/mpv-player/mpv/wiki/Video-output---shader-stage-diagram

- The luma version hooks the luma plane only (LUMA in that diagram)
- The chroma version hooks the chroma plane only (CHROMA)
- The yuv version hooks YCbCr after chroma scaling/merging (NATIVE in that diagram)
- The rgb version hooks RGB after conversion (MAIN in that diagram)

Yes

Keep in mind that mpv auto-corrects the pixel shift during the main scaling pass

Yeah. Keep in mind you need a pretty big scaling factor (low resolution video) to use doublers twice. Otherwise one instance will be disabled.

So which is the best in theory?

youtube.com/watch?v=EFRpFkZFrOU

>RAVU is a doubler. If you have 1280x720 video it will double that resolution to 2560x1440. Considering your monitor is 1920x1080, you then will have to downscale it back (default=mitchell) to your monitor's resolution.
I thought the !WHEN condition makes sure it is not used for an upscale ratio below 1.6? And 720p to 1080p would be 1.5

>RAVU RGB r3 is what bjin suggested to use for most people in older readme version
Interesting. Seems like haasn is using the luma-only version?

>It looks somewhat softer but still pretty decent.
Better than ewa_lanczossharp? There's no comparison for lite IIRC

Oh yeah I'm retarded, why would it be quadrupling a 1080p source to 2160p instead of doubling

Where shinchiro will post them
to his SF downloads page? I will try them.

Here:
sourceforge.net/projects/mpv-player-windows/files/Test/

Okay so -yuv and -rgb essentially double all planes. Is there a speed difference between those two, or other differences I should be aware of?
I do realize that other stuff might have been applied to the frames til it reached the RGB stage (not sure if subtitles are already "on" the frame though)

Lua newbe here, how can I execute a command and get the result in the osd?
>execute date
>osd prints date
?

Well, scaling luma well is more important than scaling chroma well, because luma information is just more important than chroma information. However, scaling both luma and chroma would be better just because chroma isn't useless. So either yuv or rgb.
Looking at that diagram though, I don't really see much of a difference between yuv and rgb. The only difference I see is that rgb can have the subs in it if you use blend-subtitles. I think they should be theoretically the same, only being different because of colour conversion errors or something, which shouldn't happen anyway.

>Looking at that diagram though, I don't really see much of a difference between yuv and rgb

-yuv: Works on YUV video, upscale all planes after they are merged.
-rgb: Works on all video, upscale all planes after they are merged and converted to RGB.

>Put up on Sourceforge 30 mins ago

>I thought the !WHEN condition makes sure it is not used for an upscale ratio below 1.6? And 720p to 1080p would be 1.5
The WHEN condition is exactly this:
//!WHEN HOOKED.w 2 * OUTPUT.w / 1.600000 < HOOKED.h 2 * OUTPUT.h / 1.600000 < *
Broken down into a bit more readable syntax, this effectively becomes:
(HOOKED.w * 2 / OUTPUT.w < 1.6) && (HOOKED.h * 2 / OUTPUT.h < 1.6)So basically: (HOOKED * 2) / OUTPUT < 1.6
This is basically saying that it will only upscale to 1.6 times your output resolution.

Re-arranging: HOOKED * 2 < OUTPUT * 1.6
Or basically: OUTPUT / HOOKED > 2.0 / 1.6 = 1.25
So it's active whenever it would upscale by at least 25%.

it doesn't work

Based Shinchiro.

Yes, theoretically there's a difference, but I still don't see why there'd be a difference.

MPlayer masterrace

The individual luma/chroma scalers should be better in theory since they upscale earlier in the process chain, no?

Shinchiro, please...

I believe the chroma scaler only upscales to the video's normal resolution, right?

Ah okay, thanks. Wondering why 1.25 though, I feel like it would make more sense to use >1.5 here.

I'm getting huge or small (depending on resolution) triangle in the upper right corner of the player with Vulkan. gpu context is Win. Windows 7, AMD GPU. Seems to be related to scale since i dont get any artifact with native res videos.

This desu. I don't know what mpv did to MPlayer to make it run so poorly. MPlayer on an old Intel Atom can play HD content while mpv struggles.

mplayer is dead

Here
Updating to Shinchiro's test thing with what I assume is the vulkan-rev2 branch fixed it, no more triangle.
Try

Keep in mind RAVU is not linear, so the colorspace should have an effect in principle. Could probably easily test it

FUCK. Ill ask bjin personally. Along with his mpv config.

So, theoretically the yuv hook should be better because it's not linear yet?
But if RAVU isn't linear, then it should have some translation to work with RGB. I can't imagine it just does the same shit and just produces a fucked up image.

Deleted OpenGL 1.x / 2.x code

I use the xv vo, would it affect that too?

When I say “linear” what I mean is that it commutes with other linear operations (like YUV/RGB conversion, which are just matrix multiplication). Normal upscalers are all linear, since they're just convolutions, which are just matrix multiplications.

RAVU is almost a convolution, but it shapes the kernel based on the detected angle and coherence. So it's sort of linear but not really.

No, it shouldn't

Reading your post made me horny for some reason. Hmm.

Well, I tried switching between them a bunch with ctrl+1 cycle-values glsl-shaders "~~/shaders/ravu-r4-rgb.hook" "~~/shaders/ravu-r4-yuv.hook" and I couldn't notice any change whatsoever. I'll just keep using rgb because that'll work on non yuv video as well if I'd ever encounter that.

Actually the -yuv version works on non-YUV videos as well.

Ok now it's getting confusing.
I have no idea what to use anymore.

Then the documentation should be updated.

Yeah it should

Does the -rev2 branch fix it?

No more triangles with the test build! Krigbilateral still doesn't work though. Also stats reported in some weird way for compute RAVU (doubling twice) now. For example:
ravu step1: 500 - 1%
ravu step2: 1000 -1%
ravu step1: 500 - 1%
ravu step2:1000 - 60%.
Steps 1 and 2 are identical for each iteration. Percentage is summed(?) for the last pass only. In last shinchiro non test build everything displayed correctly. Maybe bjin need to update shaders.

To all people that are confused about RAVU. I tested all of the versions and they all look identical. Some work faster though. I personally use YUV.

Read Thanks! Overall player is more responsive now and i get much less dropped frames when starting video, going full screen and out of it than the rev1.

>attentionwhoring

hanna, why are you using RAVU only on luma?

Can you send me a screenshot of what your stats page looks like? I'm not sure if I understand your description.

Also, can the people using vulkan-rev2 try testing whether or not increasing --vulkan-queue-count improves performance? (Try =2, and =4)

Also a verbose log would be great

>doesn't have a volume button
>closes when the video ends
what a shitty player

Never tested the others. I should probably switch to RGB, I guess

>Can you send me a screenshot
Cant, sadly. scaled screenshots don't work for me with Vulkan. Ill try to make a photo with a phone later.
>Also, can the people using vulkan-rev2 try testing whether or not increasing --vulkan-queue-count improves performance? (Try =2, and =4)
I get very weird results with this ON. Basically if i turn it ON my upload frame is near 0 with DR enabled. My SSIM passes turn to very low volume except for the last pass which becomes 60%. Without this option enabled frame times split even between all SSIM passes and upload frame is a few thousands. Its hard to explain, ill photo later.

There's a way of always showing stats.lua on auto-profiles?

...

>Also, can the people using vulkan-rev2 try testing whether or not increasing --vulkan-queue-count improves performance? (Try =2, and =4)
No idea. The average frame timings go down, but the peak frame timings go up. I don't notice a difference myself.

Doesnt work. I get black picture with unscaled mpv window in it.

What about the actual FPS? Timers don't really work in -rev2

Can you remind me how to measure it?

Even when not fullscreen?

I use this in my config

[bench]
audio=no
untimed=yes
video-sync=display-desync
vulkan-swap-mode=immediate
opengl-swapinterval=0
osd-msg1="FPS: ${estimated-display-fps}"


Basically run with --profile=bench to benchmark the performance. Also, this still needs to decode the file, so use it on something with low resolution, ideally something like H.264 that can be decoded very fast.

>vulkan is such a disaster no one talks about it
How much you guys getting payed, why not shill you player on reddit?

i am watching my animes with vulkan as we speak

I get more fps with ver1 compared to ver2. 3000FPS vs 2500FPS.

What settings? Can you try with something like profile=gpu-hq?

PS C:\Users\niggerslayer\Downloads\mpv-x86_64-20170930-git-052ae53> .\mpv youtube.com/watch?v=HUUsEgAe8x4
Playing: youtube.com/watch?v=HUUsEgAe8x4
[ytdl_hook] youtube-dl failed, trying to play URL directly ...
Failed to recognize file format.


Exiting... (Errors when loading file)
PS C:\Users\niggerslayer\Downloads\mpv-x86_64-20170930-git-052ae53>
TASUKETE
also I have latest youtube-dl.exe in mpv folder

>What settings?
Just with your profile + gpu-api=vulkan.
>Can you try with something like profile=gpu-hq?
Both version 1 and 2 output at 1500FPS. vulkan-queue-count has no effect.

Try with empty config, make sure youtube-dl is in the same folder as mpv.exe. Also make sure mpv and youtube-dl are not blocked in your firewall. Also try with different video.

Just added compute ravus to test. Ver1 700FPS, ver2 660FPS.

Got a log? Is this AMD or nvidia?

Ver1 had the artifacting triangles for you, right? If so, then it's unfortunately not really a valid comparison, ver1 was probably faster because it ignored synchronization

ver2 seems to crash immediately for me the moment i apply any scaling filter

What drivers? Log/backtrace? Does it still happen with --gpu-debug?

Log: pastebin.com/raw/eXEV1zSN

Latest NVIDIA drivers, still happens with --gpu-debug yes

Oh yeah it is working with gpu-hq profile by the way, just not when I overwrite the scale filter with my own as opposed to what is in the profile

The crashes I observed seem to be related to DR. I disabled it and no problems so far.

rev2 get's rid of the triangle for me so that's pretty cool. But with ewalanczossharp + stats toggled + osc visible, I get corrupted/flashing subtitles.

480p h264 file with this bench:

ogl dxinterop backend - 300fps
ogl angle backend - 240fps
vulkan win - 60fps
ogl win - 60fps

Does this sound right?

Config:

profile=gpu-hq
scale=haasnsoft
scale-clamp=0.5
cscale=ewa_lanczos
sigmoid-slope=10.0
vd-lavc-dr=yes
vd-lavc-threads=32
glsl-shader=~~/shaders/ravu-r4-rgb.hook
glsl-shader=~~/shaders/ravu-r4-rgb.hook
glsl-shader=~~/shaders/KrigBilateral.glsl
video-sync=display-resample
tscale=robidouxsharp
interpolation=yes
deband-iterations=2
deband-range=12
temporal-dither=yes