/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


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:

diff.pics/hfXh77QRc5st/1
mpv.io/manual/stable/#protocols
mpv.io/manual/master/#options-hwdec
gist.github.com/ElegantMonkey/d00c4edecedbdbe6ec0cc7e324ff9b5e
screenshotcomparison.com/comparison/216547
screenshotcomparison.com/comparison/216552
twitter.com/SFWRedditGifs

>not just ewa_lanczos for scale, tscale, cscale, and dscale
placebo

mitchell+SSimDownscaler vs ewa_lanczos:
diff.pics/hfXh77QRc5st/1

>Absolutely no change to the example mpv.conf
Nice work faggot.

>mpv

Actually, it was never completed in the first place.
I remember this, there were a lot of people cheering him up and stuff. But in the end, when a usable beta-release came out, people stopped caring. Eventually, the user stopped developing because nobody used it.

To this day, I still don't understand why this happened. There really were a lot of people requesting such a program but once it was there nobody used it.

In what language is mpv written?

>To this day, I still don't understand why this happened. There really were a lot of people requesting such a program but once it was there nobody used it.
Were you..... The user that developed the tool?

Lol no

This.

Bcoz editing text file is more easier

When you think about it everyone that uses mpv in the first place doesn't mind simple UI and editing config files unless they are masochists. To the one click KCP types even using a 3rd party tool is too much effort.

C

Why did you ask this though? It took more than 5 min for my answer to be published here, will take a bit more until you see it.
Instead, you could have clicked the repo link OP posted and would've gotten exactly this information, even with more details.

Honey, you won't get to the top in life. You are never going to accomplish anything meaningful.

Thanks for doing the legwork for me my man.

>Honey, you won't get to the top in life.
I will as long as people like you keep asking "how high" every time I tell you to jump :^)

Would be easier to make a website with a couple of tick boxes on and have it generate a config at the end. More people would use it if you didn't have to download a program to generate a conf file (which you would have to redownload to update every time mpv changed the name of an option).

I've gone tole (you) to make one many times - competition is healthy!
mpv-as-an-encoder works just fine in both my and Zehkul's scripts. I highly recommend it! Biggest drawbacks are the lack of -c:v copy and possible inaccuracy in duration, ie. output ends a frame or two early. And you still need mpv in PATH (utils.getcwd() exists but no utils.getexecutable()), although that's minor.
As said, mpv issues a seek and the section can usually even be re-used from cache (transparently by mpv). --start/--end works just fine with ytdl, assuming the host supports seeking the stream ("seekable" property being false will at least pre-emptively confirm it does NOT work - seeks MAY fail depending on the video service even with "seekable" true)
Verify your ytdl settings - unless you're using the filesize target, Zehkul's script should handle youtube just fine.

Linked mkv support, industry standard right-click context menu, volume control, non-retarded keybinds, ability to properly count, and apology to madshi for stealing his ideas when?

Thanks for the script.

Any approved way to stream torrents via MPV without bothering with torrent clients or command line?
Windows user here.

mpv.io/manual/stable/#protocols

when you kys

This. Thank you very much. Trying it out now.

Does it notify me once an encode has finished?
Also, can I start a new encode while one is still running?

There's a peerflix hook user script. I've never tried it though.

What's the difference between dxva2 and d3d11va, which one is better/faster?

Zehkul has notify-send to display a popup which I adapted as well. However, full-screen mpv will obstruct that - it works, but I personally rarely see it.
You can start multiple encodes no problem (obviously they'll slow down depending on your machine) and close down mpv as well (downside is, you'll have to hunt down the encoding process if you want to abort it). As an edge case, you may want to be careful with encoding the same time-range twice (ie. identical filenames)

Hoowever, I realize you might've thought I'm the author of the just-now released script which uses ffmpeg.
Yes, it will notify you (inside mpv, if you don't encode the clip detached [see "run_detached"]) and yes, you can encode multiple clips at once (if you encode them detached). "run_detached" defaults to false.

You need to realize that people are not really interested in hearing about your script if you don't intend on releasing it.

mpv.io/manual/master/#options-hwdec

"Script is not released -> author does not intend to release script" is erroneous logic.
Besides, I was speaking of Zehkul's script, which currently does the encoding/playback state the best of publicly known scripts (the YAD aspect is a bit clunky true,, but exposes a lot of great functionality).

Hardly, his script is hacky as fuck, both encode.lua and what user just released are better.

It *looks* damn hacky, which is why I started my own, but it worked just fine when I last used it (which *is* a few years ago, but it hasn't had updates since). As "options/sub-file" (and the audio equivalent) is now deprecated, you'll have to fix those ("sub-files", "audio-files"), but what's wrong with it (excluding YAD dependency)? It even allows you to chain segments into one webm and has a multitude of quality options.

What is the current state of x264 vs vp8/vp9? I vaguely remember a few years ago a properly configured x264 outperformed vp8 in terms of speed and quality, but what is the situation now?

Chill, user. I was asking that user a question and they answered it.

Thanks for the info did see the message once it finished encoding, just had to wait for it!

i've updated the script to use mpv to encode, instead of ffmpeg. ffmpeg support is still there, but i'll probably drop it, as mpv seems to work just fine.
gist.github.com/ElegantMonkey/d00c4edecedbdbe6ec0cc7e324ff9b5e

mpv seems to be callable even outside the PATH on Lua scripts, idk why (at least on windows).

vp8 is basically hot garbage but that's all Sup Forums accepts so that's that. x264 is still the king in terms of encoding speed and compression, but vp9 should come close

People are fucking retarded. Even if there is great high quality barebone config in the OP, retards will copy paste some autistic mess of a config that they found by googling or saw in the thread. The more weird lines it has the better quality!

I think on windows it searches for the executable in the current working directory which is why it works

You should add VP9 support.

Tell wm4 or haasn to add it to the user scripts page.

The wiki is writable by anyone

Too soon I don't trust this script yet.

As said, x264 beats vp8 (and especially vp9) in speed by MILES. Quality (aka filesize) has less of a difference (and importance to me), but webms are the thing to share on the net. Chrome does h.264, FF might, but webms have gotten their (rightful) hold of quick simple videos to share.

Sounds interesting, I haven't tested it PATH-less, since I have a lookup tool for mkvpropedit and such. Not needing the user to add mpv to PATH will make it very user-friendly indeed (if that applies to Windows and Linux).

x264 is still the best encoder in terms of speed, and i think it only loses on quality on low-bitrate videos against vp9.

probably

you can set the codec to libvpx-vp9 on the options, unless you want to select it on the fly.

why lol

>why lol
I'm paranoid.

>I'm paranoid.
Why?

Too much stress + going to bed to late every day.

But why exactly?
I mean, you can check the source code, there's nothing to be afraid of.

Looking it over it looks like all it's doing is putting together and running the ffmpeg command you would use to encode it manually.

Fuck, I'm guessing this is because Hiroshima Nagasaki would have to pay for an h264 license or something to add support?

If I'm understanding correctly VP9 will produce smaller files than VP8 but will take longer to encode? Is VP9 supported by Sup Forums?

Sweet!

Does run_detached do anything when using mpv?

>Is VP9 supported by Sup Forums?
No, neither opus(vorbis successor).

I'm stupid, I'm not a programmer. I'll use it when someone related to mpv development says it's good :) I can't wait though. Wanted something like this script for a while. Thanks!

No, there's no need for a license (as far as I know?!). If anything, it comes down to browser support - the WEBM container and VP8/9 were designed to be open/royalty free.
VP9 will produce smaller files than VP8, but Sup Forums doesn't support VP9 webms. For reasons.

>does run_detached do anything when using mpv?
mpv as an encoder? yes, it spawns a new process (mpv in this case) and detaches the control from the original mpv instance.

Nand, you approve of that webm script?

Sorry for the late reply,

What tasks do you think a GUI is better for than a TUI? For me it's

>image editing
>text selection on websites
>camera controls
and that's about it. For everything else, I'd a billion times rather stay on the keyboard than have to constantly switch between the keyboard and the mouse. It's such a chore.

I've been using a keyboard-driven browser and curses programs for everything else for the past decade or so and I could honestly _never_ go back.

Looking at the source code, it's no wonder it got abandoned. He actually tried to hard-code the options and values for every single mpv option. That is absolutely not the right approach to an mpv configurator. If anybody wants to do it properly, here's what you *should* do:

1. Create a libmpv instance and embed it
2. Use introspection to enumerate the list of available options, their types, and their value ranges, and generate the right controls as needed
3. Parse the DOCS/options.rst to get the documentation for each setting, and use this to group them into categories (tabs) - sort of like how the mpv.io docs work
4. As these controls are changed, make them directly affect the embedded `libmpv` so users can see their changes in realtime, at least for the ones related to video output

For bonus points you could even support switching between a few sample files or using your own, or toggling audio on and off so you can hear the effects of the audio-related options.

Anyway, an approach like that will be stable and future-resistant without much “updating” effort, and also comprehensive (will cover every option).

Reposting:
I haven't updated mpv in just about a year (v0.20.0)
What should I expect? Were there many major changes? Will all my configs break?

I asked the same thing earlier.
Improvements. Maybe. Not yet.

wait lol why wouldnt you just use VLC?

Do mpv screenshots omit any graphical settings? As in if I wanted the highest quality screenshot should I just use ShareX/printscreen rather than "s"?

ikr, like lol XD

is there a good frontend for windows yet?

>mpv seems to be callable even outside the PATH on Lua scripts, idk why (at least on windows).
How did you start mpv? The working dir might be the mpv dir

mpc-qt is a wip but looks promising

yes. you can use ctrl+s to take a screenshot of the window.

Looks cool, a few suggestions:

1. Support changing the crop points by clicking. (If A is unset, set A. Otherwise, if B is unset, set B. Otherwise, set whichever one was closest to the clicked point)

2. Set 'script_name' so users can change the settings in ~/.mpv/lua-settings

3. Make the “encode successful” notification less huge. It's absolutely monstrous in size here. Can't you pick the default OSD font size, the one normal notifications use?

4. Use two-pass encode instead of hard-coding the bitrate/CRF and target the exact file size requirements for Sup Forums

H.264 requires paying royalties to use. That's why VP* exist.

Thanks, so does it just ignore everything and shot it exactly as the file inputs?

s and S both go through libswscale, which is low quality.

ctrl+s takes a raw screenshot of the mpv window (same as printscreen key), but it will also include e.g. black bars, color management, OSD messages and so on.

>s and S both go through libswscale, which is low quality.
why is that, anyway? speed/simplicity?

Simplicity/compatibility. Speed is irrelevant for screenshots, and vo_opengl is probably faster than libswscale anyway.

s and S take a “raw” screenshot directly from the source, without all of the processing by the VO. It's not supposed to be affected by VO options, either. It's also supposed to work even with other VOs like vo=vdpau or vo=x11. (But that wouldn't be a huge deal, it could always fall back to swscale if the VOCTRL is unimplemented)

Basically, the code hasn't been written yet, and the screenshot code dates back to before mpv existed (iirc).

Oh right, taking a screenshot with the VO would also require FBOs which is not implemented on all platforms. So it wouldn't work anywhere, and the swscale code would be needed as a fallback either way.

Okay thanks mate. Actually made me want to compare. Here's the dif on BD bloatgirls. Set to jpeg=90 (default). Barely noticeable difference.
screenshotcomparison.com/comparison/216547

test

So is this any better than Webm4Retards? I can see it's supposed to be faster since it's integrated right into mpv, but W4R is just stupidly easy to use.

W4R is windows only.

hwdec for VP9?
CPU: i5 6600k
GPU: RX 480 8GB

if the source had banding there would be more of a difference (though perhaps not so much for JPEG screenshots)

It depends on the file and your settings whether you should expect a difference.

Notably, even if the size of the output is the same, using the VO gives you:
1. debanding
2. high quality dithering
3. `cscale` works
4. correct chroma offsets
5. support for files with unusual colorspaces (e.g. HDR, or BT.2020) which will be tone-mapped accordingly

>Nice work faggot.
Please don't forget to use a comma in the vocative case.

Names, places or objects that are being addressed directly are said to be in the vocative case. When somebody is being spoken to directly, his/her name must be separated from the rest of the sentence with a comma.

Correct:
"Nice work, faggot."

I know you can do it, user. :)

>can't you pick the default osd font size?
this is the default osd font size, and i do try to show it with a different font size, but it doesn't work. this is the function that shows the message:
message = function(text, duration)
local ass = mp.get_property_osd("osd-ass-cc/0")
ass = ass .. "{\\fs" .. tostring(options.font_size) .. "}"
ass = ass .. text
mp.osd_message(ass, duration or options.message_duration)
end

i'd love to know if anyone has a clue as to why this doesn't work.

will work on the other suggestions later.

double-clicking a file on explorer.

ayy. the one time where windows win.
well i mean nobody releases anime BD in anything but 10-bit nowadays, so banding shouldn't be a problem outside of current airing Horrible/fansubs. actually here's a HS compare. this time with highest quality PNG. just about everything is ewa_lanczos
screenshotcomparison.com/comparison/216552
I just wanted to see if mpv screenshots were affected by the various settings. Doesn't seem to matter that much after all, so I can just use "s" without worry.

To decode and encode, I understand, but to serve?

That code works. In fact, *removing* it solves my issue, because now it will use the default OSD size instead of your huge setting.

>webm for *retards* is windows only
Honestly surprised it doesn't also support OS X

...

>removing it solves my issue
removing which part? this exact font size is also used on the other menus, but it uses assdraw instead of osd_message.

Is there any option to make ffmpeg/mpv encode webms with the correct colormatrix or does vp8 just not support bt.709?

Those parts actually show up too small on my system, btw

>removing which part?
This line: ass = ass .. "{\\fs" .. tostring(options.font_size) .. "}"

I commented it out and now the output is normal-sized, rather than being so gigantic that it spans over several lines because it doesn't even fit on my monitor horizontally

VP8 only suports BT.601, you need to convert it to the right colorspace

Is there ur .moon file somewhere

Y'alls configs differ on the OSD font size. If you did pure AS with mp.mp.set_osd_ass(w, h, ass_text) you could reach a unified resolution.

but shouldn't the font sizes be the same when using ASS with mp.osd_message and mp.set_osd_ass? they seem to be completely unrelated - for me, {\fs24} on osd_message is over twice as big as {\fs24} on set_osd_ass.

What makes you think that? `osd_message` shows an OSD message, using the user's OSD settings.

`set_osd_ass` draws some raw ASS. Of course they're completely different. The correct solution would be to use `osd_message` with NO metadata for the notification messages, and `osd_draw_ass` for whatever else you need to draw

Nope, look into the monster that is osc.lua. Or was it defaults.lua... Anyhow, the osd_message is in Lua somewhere in the player/lua directory. osc.lua at the very least has the logic on scaling the osc (and by extension, osd). It's also a good source for tricks for working with display-related stuff (but it's kind of ugly; could be neater).

damn. well, i'll just stop trying to change the font size for simple messages. thanks.

So I'll just have to live with the color shift until Sup Forums supports vp9 then?

No prob. I didn't get hated by /mpv/ for just dicking around, you know.

That's the practical way, yes.

Bump

Or you could insert the right conversion filter

updated the script again, now setting options from ~/.mpv/lua-settings should work, and added 2-pass encoding with target filesize, which should improve the quality. dropped ffmpeg.

now i'm going to sleep, it's 1am over here. goodnight, Sup Forums.

Fantastic, thanks

Good good user, thanks.