/mpv/ - The Open Source and Cross Platform Video Player

Last thread Installation:
mpv.io/installation/

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

Manual:
mpv.io/manual/stable/

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

Migrating from MPC-HC?
github.com/dragons4life/MPC-HC-config-for-MPV/blob/master/input.conf

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


Vulkan(Linux only for now):
github.com/atomnuker/mpv

Test vulkan and post logs if it gives you any kind of problems.

For better playback quality paste this in your mpv.conf file:
profile=opengl-hq
cscale=ewa_lanczos
scale=ewa_lanczossharp

Interpolation(smooth-motion):
interpolation
video-sync=display-resample
tscale=oversample

Check your settings for compatibility errors by running mpv in command line or with

log-file=log.txt

. Search the log for "dumb" anything or for [e].

REMINDER

Other urls found in this thread:

github.com/Kagami/boram,
github.com/haasn/interpolation-samples
screenshotcomparison.com/comparison/216649
github.com/ElegantMonkey/mpv-webm
github.com/mpv-player/mpv/wiki/User-Scripts
github.com/haasn/cms/blob/master/caqbqk.mkv?raw=true
github.com/mpv-player/mpv/wiki/Display-synchronization
diff.pics/pm5yEJ6SneiQ/1
twitter.com/SFWRedditImages

hai

stop posting this shit with cscale=ewa_lanczos, literally no point as opposed to cscale=ewa_lanczossharp

ohayou

stop posting this shit with cscale=ewa_lanczossharp, literally no point as opposed to cscale=ewa_lanczos

I think trying to turn mpv into an entire webm studio edition with thousands of options is futile, you can't adress every possible usecase. At some point you might as well go with a dedicated tool like github.com/Kagami/boram, which has a much better UI than a script could ever have.

Also the better script is not the one which has the most features.

retard

First for ElegantMonkey is a cool guy.

Will opengl-dr fix the problem with display resample where you have to render a frame on every screen refresh?

Second for him being a cooler guy than I-hate-free-software user.

Dumb phoneposter.

Scroll up. It says that about scale, it doesn't say what cscale you should use.

WAIT™ FOR VULKAN®

why would you use a different cscale than scale

if you want blurry chroma

What is causing uneven/jerky panning?

I just compared same anime scene with panning camera on MPC and MPV
It still feels kind of uneven with MPV
I do have
>interpolation
>video-sync=display-resample
>tscale=oversample

Still feels like the video runs at slightly uneven pace.

It's much faster and you won't see the difference anyway

What said + haasn and Argon use ewa_lanczos. Some also use ewa_lanczossoft. Chroma layer does not nearly benefit from lanczossharp as much as Luma.

>much faster
still trivial for even weak GPUs

Try an other values tscale such as mitchell. It is noticeably smoother, at the cost of being blurrier.

this, I think the right interface for encode scripts like these is to implicitly use what mpv was using (e.g. for audio/subtitles), to avoid UI clutter. At most, I would provide difference “presets”, for example a “Sup Forums preset” (forces audio off and target filesize + VP8), and a “quality” preset (uses x264 + CRF + matroska + opus) or something.

Could be that your system is failing to play at 60 fps to begin with. Double check with: github.com/haasn/interpolation-samples

scale (luma) layer is a detail layer. cscale (chroma) is a lower resolution “color” image layered on top of luma. You wont get any benefit using ewa_lanczossharp IMO compared to ewa_lanczos and would waster your resources on it. Chances are you wont even notice any difference with "regular" lanczos and bicubic.

The human eye can't even see above spline36.

>Could be that your system is failing to play at 60 fps
Is there a way to see how fast it goes?
>mitchell
Looks like absolute fucking ass with anime.
Triangle too.

I'm not trying to address every possible usecase, but I'm able to do this, so I do it, for my entertainment and gain. Dedicated tools will obviously beat scripts, but with these you can forget about them until you have that scene you want to save because you just saw it. Doing it in-player is very handy, and if you feel like cropping the thing or targeting a size, bam.

I didn't try to claim anything about which is better. I was inspired by Zehkul's, and if I can help Monkey with things I've solved/had a thought about, everyone wins.
A plethora of features will make a script unwieldy, which I decided to combat with the menu system for options - hide them away until needed. Previously all the CRF and scale and 2-pass keybinds and statuses were always on display (in the "advanced" mode).
The segment editor I agree on, that's just silly. But silly is fun!

Presets/profiles are a good idea. Nontrivial to allow the user to trivially configure them, but hmm...

>Looks like absolute fucking ass with anime.
But that's wrong, it looks great. Enjoy your jierkiness I guess.

Try catmull_rom. I find both mitchell and triangle to be too blurry.

>Is there a way to see how fast it goes?
Yes, stats.lua

But it could still be the case that your compositor doesn't play frames 1:1 for some reason

Need to make logos for all these different webm scripts!

You can see an obvious difference on some pathological clips, for example the (in)famous ndkqmf

Just because it doesn't make a difference most of the time doesn't mean it's always irrelevant

>uneven/jerky panning?

Ok.
I fixed it.
I removed two lines:
>video-sync=display-resample
>deband-iterations=2
Either one of these was causing this.

Now it's perfect.

The what ndkqmf?

>Chances are you wont even notice any difference with "regular" lanczos and bicubic.
if anything the sharpness might exacerbate artifacts in the chroma
screenshotcomparison.com/comparison/216649

>Now it's perfect.
And also doesn't work. Lul.

>removed video-sync=display-resample
that disables interpolation dumbass lmao

Is this the best non-placebo config?
# Video #
profile=opengl-hq
opengl-backend=dxinterop
hwdec=no
scale=ewa_lanczos
dscale=ewa_lanczos
cscale=ewa_lanczos
tscale=oversample
video-sync=display-resample
interpolation=yes
dither-depth=8
temporal-dither

The sharpness we perceive doesn't come from the chroma layer so sharpness is a less important criteria here.
Sharp scalers also produce more artifacts and while we make that trad-off for scale (get sharpness and artifacts), it's not worth it for cscale. The added sharpness of a more sharp algorithm will not be noticeable when used for cscale but the added artifacts will be.

It doesnt?
>interpolation=yes
>tscale=oversample

These lines are still in plays and it seems fo be interpolated.

Read the manual, dude
>This requires setting the --video-sync option to one of the display- modes, or it will be silently disabled.

...

moved to a proper git repo, and added options menu.
github.com/ElegantMonkey/mpv-webm

thanks

>failed_Sup Forums_project.png

Stop phone posting

Probably getting frame drops because of deband. Do you have shit hardware? You should really check stats.lua

...

Now add it to:
github.com/mpv-player/mpv/wiki/User-Scripts

>deband
>frame drops
Lol no. The culprit is always video-sync=display-resample and interpolation.

stop being wrong

Take in count you need a frame time of 16 ms or lower on a 60hz monitor for a correct interpolation.

Actually you might be right.
I put back the
>video-sync=display-resample
And it seems to be smooth(or i grew so tired i dont even know anymore)

Perhaps the double debanding was causeng framedrops.

My GPU is r9 380x

How many Hz is your monitor?

explain why opengl-hq uses spline36 for both scale and cscale

just check stats.lua fagit

60
It's also 4k so the upscaler debander deringer and whatever are doing quite some work.

Id remove dscale line, default (mitchell) is better. scale to ewa_lanczossharp. Also remove dither-depth line.

>scale to ewa_lanczossharp
placebo

You need a frametiming of 16 ms or lower for the interpolation to work

I can clearly see a difference. Are you the user i was talking to?

>I can clearly see a difference
Placebo

Butthurt Pentium 3

...

>Placebo

>Doesn't use his resources
Butthurt retard.

>16 ms or lower for the interpolation to work
>16 ms or lower on a 60hz monitor for a correct interpolation
Source?

1000ms in a second/60hz=16.6ms
mpv will deactivate the interpolation if your frametime is greater than 16.6ms

>mpv will deactivate the interpolation if your frametime is greater than 16.6ms
Source?

Test it yourself, the interpolation will deactivate.
Test it with some retarded shader like nnedi3 with 128 neurons.

The computer sends a new image to the monitor in sync with its Hz, so every 16.6ms fpr 60Hz. It wont work if you go above 16.6ms in frame times since it wont be able to draw frames in time.

>it wont be able to draw frames in time
mpv caches frames

Sorry, meant caqbqk

github.com/haasn/cms/blob/master/caqbqk.mkv?raw=true

That's not how it works.

There is nothing to explain.
Out of the non-ewa scaler (the ones running fast enough even on old hardware) spline36 has the best sharpness for the least artifacting (lanczos is worse).
If you want less artifacts, you have to go back on sharpness as well and that quite severely.
In the "upper ewa" regions the differences are smaller. It's diminishing returns all the way.

It does, though. See "redrawn" frames @ stats.lua. You will notice the numbers are considerably lower.

>Finally, --video-sync=display-* currently comes with one important drawback: Due to OpenGL's rather severe limitations when it comes to timing, the only way to reliably figure out when vsyncs happen is to actually draw a frame on every vsync. The consequence of this is that, even for 24 Hz video, you need to draw frames at 60 Hz even if they are the same frame over and over again - thus increasing power usage by a factor of 2x-3x in such a case.
>you need to keep your frame timings according to your monitor refresh rate for a correct interpolation.
Example:
1000ms/60hz=16.6ms
1000ms/144hz=6.94ms

github.com/mpv-player/mpv/wiki/Display-synchronization

Try it yourself, do and in stats.lua you'll see tscale isn't running.

Is it possible to make MPV check sub directories for subtitles?

Actually found something.
--sub-file-paths=

Yes, you can do
sub-file-paths=dirname

No NGU no buy.

after an hour of testing on github.com/haasn/interpolation-samples and twitch/dreamhackcs 720p60 (before you whinge, different people watch different stuff) i wrote this this piece of shit:
profile=opengl-hq
opengl-backend=angle
scale=ewa_lanczossharp
cscale=bilinear
dscale=mitchell
tscale=gaussian
sigmoid-upscaling=no
video-sync=display-resample
interpolation
no-audio-display
no-taskbar-progress
screenshot-directory=~~/

I said it caches frames. It really does. You can see them in stats

gaussian...? So the most blurry piece of shit you could find.
First you create sharp images with ewa_lanczossharp and then you blur the shit out of it.
Great.

It will automatically deactivate the interpolation if the frametiming surpass 16.6ms, go ask in #mpv if you don't believe me.

If you have 60Hz monitor then interpolation didn't work for you with that twitch stream. It disables if fps matches display Hz. Bilinear is shit. At least use the one included in opengl-hq.

what is the point of interpolation if your intent is not to make lower-framerate content smooth? oversample, linear, even mitchell introduce unacceptable judder. keep in mind that i'm not an anime watcher, this is what looks best to me in haasn's big buck bunny samples

i tested each option using something similar to this in input.conf: y cycle-values cscale bilinear spline36 ewa_lanczos ewa_lanczossharp
i could tell the difference obviously in scale, dscale and tscale but i could not tell the difference at all for cscale, so i thought i might as well use the fastest scaler.
i don't care about the twitch stream interpolation. in fact i might disable interpolation altogether in those circumstances

>twitch
recommend not testing on any twich samples, they can't into encoding at all. Expect A-V drift and glitched frames

>
>what is the point of interpolation if your intent is not to make lower-framerate content smooth? oversample, linear, even mitchell introduce unacceptable judder. keep in mind that i'm not an anime watcher, this is what looks best to me in haasn's big buck bunny samples
The fuck did I just read. Interpolation in mpv designed to remove judder caused by mismatch/not being even multiple refresh Hz of monitor and video's fps. If you're playing 30 or 60 fps content on 60 Hz display you won't get any judder. Different story for 23/24 fps content.

# Video
vo=opengl
opengl-backend=dxinterop
opengl-hwdec-interop=cuda
hwdec=no
video-sync=display-resample

profile=opengl-hq
scale=ewa_lanczossoft
cscale=ewa_lanczos
deband-grain=0
deband-iterations=2
deband-range=12
deband-threshold=48
How is it?

poozoor

So, bicubic is the best cscale?

You're thinking of madVR, not mpv

You want hwdec on or off I don't get it. You got scale and cscale backwards. Remove everything related to deband.

Are you trolling or retarded?

Neither? Are you?

>diff.pics/pm5yEJ6SneiQ/1
Only if you like blur.

The heck? Who cares? I never said anything about it deactivating itself.
Someone said it caches frames, you said no and I told you yes it does, check with stats.

>interpolation
>Reduce stuttering caused by mismatches in the video fps and display refresh rate (also known as judder).

Retard.

twitch streams are what i tend to watch with mpv, so i'm fine using that as my benchmark. i'll agree with you that the quality is usually garbage, and sadly the only time you can try 1080p60 is during the dota 2 international which is next month.
this is simply not what I experienced. it is judder whether you want to believe it or not.

Yes but the way you said it made it seem like mpv interpolation would do nothing for a 30 Hz video on a 60 Hz display, which is not really the case