Video player Shaders guide (MPC-HC, mpc-BE, mpv)

[v0lt]

I would like some existing mpc-hc shaders, like "luma sharpen" or "lcd angle correction", to have effect just in the left half of a video, when the video is displayed in full screen.
Here's an example.
float4 main(float2 tex : TEXCOORD0) : COLOR
{
if (tex.x > 0.5) return tex2D(s0, tex);
...

[Acba]

Here's an example.
float4 main(float2 tex : TEXCOORD0) : COLOR
{
if (tex.x > 0.5) return tex2D(s0, tex);
...

It worked!
Now I finally have "left-side-only" shaders.
Thank you very much!

[butterw2]

## mpc-hc HideWindowedControls

Options > Advanced > HideWindowedControls
This Advanced option was added a while back to mpc-hc and helps modernize the windowed mode UI a lot. The toolbar is displayed only when the mouse hovers the bottom of the window similar to what happens by default in full screen mode. The result reduces the windows height and IMO looks much better.

The configuration for the following win10 window screenshot is:
normal preset + dark mode theme + hidden menubar
I'm using the following advanced options:
- DefaultToolbarSize=18.
- status bar display: codec/resolution + frame rate
the video resolution is 576x1024.

https://raw.githubusercontent.com/butterw/bShaders/078f2a1d7a4de0d339ed729c02348bbc52991140/assets/img/mp-hc_HideWindowedControls.jpg

The top menubar can be displayed if needed with the Alt key or the right-mouse click menu can be used instead.

EDIT: The Controls toolbar isn't typically very useful in mpc-hc, and can be disabled if you are familiar with the basic keyboard shortcuts.

[butterw2]

MPC Video Renderer 0.6.7.2013 (https://github.com/Aleksoid1978/VideoRenderer/releases/tag/0.6.7)

Changes:
Added "Request Super Resolution" option for Nvidia and Intel graphics adapters. Hardware and driver support required. The display of "SuperResolution*" in the statistics only means that the request was sent successfully.
Recommended version of MPC-BE 1.6.6 or later.

I've tried out a few 720p and lower videos with mpcvr dx11 (vp resize+superResolution to 1080p on intel uhd730 with latest drivers). I will need to do test further to confirm that it is actually working as expected.
The result seem OK (nothing magical) but are achieved with very low cpu/gpu usage.

I believe intel vsr should also be available in Chrome web browser, but I haven't tried this yet

[butterw2]

my config for mpc-be windowed mode:
- Minimal Preset (no window bar, hidden Menubar, hidden Toolbar)
- keep Flybar (displays when the mouse hovers at the top of the window and times out unless locked)
+ seekbar
- Show OSD + show seek time enabled, show filename disabled (can be toggled in Options>Player without restarting the player)
- HideWindowedMousePointer (time out)
- Window Size: after starting Playback, scale to video size: 100%.
- SnapToDesktopEdges.


https://raw.githubusercontent.com/butterw/bShaders/0dd9f80dda6ae601cc6be861039ce2a57b743cd5/assets/img/mpc-be_minimal_flybar_seekbar.jpg
The screenshot shows the default flybar, it's possible to change it by putting a custom flybar.svg file in the mpc-be folder.
Chapter markers can be displayed in the seekbar by toggling Options > Player > Interface > x use Chapter Markers.

When enabled the OSD display can show filename, playtime, clock, and feedback information such as Volume, Zoom. However no time-out is applied when the OSD keyboard shortcuts are used (it's ON until you toggle OFF, even restarting the player doesn't help!).

In fullscreen mode I would typically prefer the default Normal preset (the toolbar/seekbar autohide) with full OSD, but I don't think it is possible to configure two different custom setups for windowed and fullscreen mode.

[SirMaster]

I've tried out a few 720p and lower videos with mpcvr dx11 (vp resize+superResolution to 1080p on intel uhd730 with latest drivers). I will need to do test further to confirm that it is actually working as expected.
The result seem OK (nothing magical) but are achieved with very low cpu/gpu usage.

I believe intel vsr should also be available in Chrome web browser, but I haven't tried this yet

Are you sure it's working?

When I use the super resolution on my desktop it takes almost all of my RTX 3080 and shoots up to 300W power usage.

[butterw2]

SuperResolution magic is not working for me. :D

with Intel Arc & Iris Xe Graphics WHQL graphics driver 31.0.101.4369 on Win10 22H2.

using mpc-be + mpcvr / intel dx11 vp for resizing.
The igpu (uhd730) is using 7W when upscaling 480p to 1080p (1% cpu, 10% gpu). Sharpness is similar to lanczos3 shader.

[huhn]

can you try this on the uhd730 and share me an upscaled image?

https://drive.google.com/file/d/1B0HoArJK4OXMvE9LhPqw1VQ0bU2qWUbM/view?usp=sharing

[butterw2]

Low bitrate (<1Mbps, ex: 500kbps) youtube streams

- mpc-be can open youtube urls (via copy-paste) and play the video efficiently.
- Youtube encoded 480p videos don't look good upscaled to 1080p on a monitor. They look OK at 100% zoom.
- Well encoded 720p can upscale decently to 1080p. For similar bitrates, 720p-av1 (if available) would be preferable over youtube 480p-avc.
- Hardware decoders: Whereas even very old computers have h264-dec, only recent generations of gpu/igpu have av1-dec. Still it should be possible to play 720p av1 in software on a PC. Otherwise vp9 hw-dec are more widely available (vp9 uses webm container). When the hw-dec is used, GPU is circled in the mpc-be Controls toolbar at the bottom of the screen.

mpc-be: Options > Playback > Online media services
with the built-in web page parser (you can also use a youtube-dl variant executable)
Preferred format: mp4-av1 720p (alternative options: mp4, webm, +60fps)

[butterw2]

can you try this on the uhd730 and share me an upscaled image?

https://drive.google.com/file/d/1B0HoArJK4OXMvE9LhPqw1VQ0bU2qWUbM/view?usp=sharing

upscaled to 1080p >> screenshot
https://files.videohelp.com/u/295418/mpc-vr_uhd730_dx11vp-upscale.png.zip
I can confirm the superresolution option doesn't change the output on this setup.

Do you have a 1080p picture of the test patterns for reference ?

[huhn]

there is no reference.

this image show that the scaler should be the good old lanczos 3 with maybe AR in very low quality (the banding).

here is mpcvr jinc2m https://abload.de/img/jinc2l9ezb.png
which is flawless no bands or discontinuities.

this just a pattern that roughly tells you the scaler and shows error in it. the band seen in your intel results could be pointless if you are only scaling x2.

[butterw2]

jinc2m generates a clean pattern on this test, but does tend to oversharpen with real video.

if anyone wants to see what the input test patterns looks like, here's the integer scaling (180x180 pixels) of the first test pattern:
https://raw.githubusercontent.com/butterw/bShaders/master/test_resize/pattern1_bw180x180.png

1080 version: https://github.com/butterw/bShaders/tree/master/test_resize

[lvqcl]

A Pixel Is Not A Little Square,
A Pixel Is Not A Little Square,
A Pixel Is Not A Little Square!
(http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf)

[nevcairiel]

The image is not meant to be perfectly upscaled, its meant to visualize properties of upscalers. Of course "integer scaling" (whoever named it that? Its point sampling or nearest neighbour scaling) will look just like a perfectly bigger version of it. But you get aliasing, tons of aliasing. Thats all the sharp corners. Normal images have no sharp corners.
You don't even know if thats what it was supposed to look like. Maybe it was once bigger and had smooth detail, but when downscaling the lack of resolution made it appear to be pixel-y.

You totally missed the point of this image and what its supposed to test. "integer scaling" is a pointless excercise with very little real-world use, at best only useful if you play old pixelart games.

What the test did show is that whatever upscaler was being used for your original images is terrible. It creates a lot of visible block artifacts around the elements. This may not be visible in normal video because the scaling factor is not as extreme, but its certainly not a great algorithm.

[butterw2]

Of course nearest neighbour/integer scaling doesn't perform well for general purpose video. Having the reference is useful to determine that there is a pixel shift of the motif.

The built-in scaler is not great, not terrible. Out of the box, it actually performs slightly better than lanczos3 on my random video test (480p low bitrate + compression artefacts to 1080p). Jinc2m looked very poor there. catrom lacked sharpness.

It's going to take some magic to make these videos look good upscaled to 1080p (2-3x upscale), getting a better source is easier.

[huhn]

lowering resolution is a terrible compression algorithm so it unlikely to find a scaler that will make a lower resolution video look constantly or at least for the majority better than higher resolution video.

Of course "integer scaling" (whoever named it that? Its point sampling or nearest neighbour scaling) will look just like a perfectly bigger version of it.

integer scaler and NN are not 100 % the same well it is only used for specific situation or how should i say it. it is NN with a integar multiply to scale only.

https://abload.de/img/integarscaleri7elz.png
pretty sure nvidia also uses that name.
it was ask for for about a decade to make pixel art game look normal on rare 1440p displays at the time.
pixelart games are usually 720p like FTL.

only pascal and newer can do it on nvidia don't ask why. (may have changed not that i care)
point and NN where not enough i guess...

[butterw2]

- Integer scaling allows to zoom in to the source pixels as they are (without upscaler effect).
At 200% upscale, the low resolution, bitrate constrained web video that was compressed to look ok at 100% shows it's artefacts. The upscaler has to mitigate this somehow. The most common artefact is noisy edges, from what I observed.

To view the available codec/bitrates on a url from a streaming site, you can use a youtube-dl variant from command-line:
> yt-dlp.exe -F url
When you go from a 480p to a 360p stream you are lowering resolution, but also lowering bitrate, so the upscaling problem becomes a lot harder.

From initial testing close-up on a 24" monitor, 720p to 1080p upscale (1.5x) with acceptable quality might be more feasible than 480p to 1080p.
but screen display size and viewing distance are key:
- upscaling 480p to 720p (1.5x upscale) on the small screen of a smarphone is probably OK.
- upscaling 480p to 1080p (2.25x upscale) on a 24" monitor might look OK if you are watching from a distance.
- 720p to 1440p monitor would be a 2x upscale.
- 720p to 2160p would be a 3x upscale.

Web video quality is typically poor to OK (this is NOT a bluray source). Bitrate would typically be in the range 1000-1500kbps for 720p and currently are typ. only available as h264 (with the exception of youtube).

What are your current recommandation for realtime upscaling of low bitrate video to 1080p on PC ?

[butterw2]

Low resolution web-videos and scaling (fullscreen, 2x, 1.5x, 0.75x), without superResolution

- Scaling low resolution to fullscreen to view on a monitor should probably only be considered if the source is reasonably good. In this case to upscale 720p to 1080p, you just need a sharp resizer or a sharpening shader. Adding noise/grain might help if the source lacks it.
- When the source has visible artifacts at 100% zoom, the options are to try to reduce the artifacts or to view downscaled.
- Some artifacts can be treated effectively at low cost, but there isn't much built-in to mpc-hc/be to do this. Mpc-hc does offer a 3x3 gaussian blur shader (light spatial smoothing).
- In mpc-hc and mpc-be, only 200% and 50% zoom can be easily and directly applied in windowed mode. But often the desirable scaling would be 150% or 75%...

[butterw2]

In mpc-hc and mpc-be, only 200% and 50% zoom can be easily and directly applied in windowed mode. But often the desirable scaling would be 150% or 75%...

To be more complete:
- You can go back to 100% zoom using View > Zoom > 100% or the corresponding hotkey.
- mpc-hc and mpc-be do allow to set a fixed window size or remember last window size. But random videos will have different resolutions so this isn't typically practical.
- mpc-hc has added a "zoom window +", "zoom window -" hotkey, which would allow to adjust window size manually (! the step is small though).
- in fullscreen mode, you could create a custom zoom factor with View>Pan&scan> Edit... preset, with the option to further adjust manually with numpad 9,1, 5 (PnS reset) hotkeys.

However Vlc does have the setting I was looking for (custom default windowed zoom):
Tools > Preferences > Show Settings: All (at the bottom) to access Advanced Settings.
Video > zoom Video: 150%. Restart the player.

In mpv:
> mpv --no-hidpi-window-scale --window-scale=1.5 "b:\Videos\day_480p.mp4"


- mpc-hc Changes from 1.9.1 to 1.9.2: Added a 25% zoom shortcut and menu entry
I don't know what the use case for a 25% zoom is, but I would suggest having a user customizable zoom would be more useful. The default value could remain 25%.

[butterw2]

To darken shadows only, I'm using the following formula (1 texture, 5 arithmetic):

#define Shadows 0.15
pixel.rgb = pixel.rgb -Shadows*(1-luma)**4

[butterw2]

with mpc-hc, you need put your custom hlsl shaders in the .\shaders (for dx9) and .\shaders11 (for dx11). The shaders need to be have the same filename (ex: bShadows.hlsl) to be applied correctly when switching between dx9 and dx11 renderers.

It's easier to develop the shaders in dx9 Evr-CP, with the debug shader compiler output available.
You can then port the shader to dx11. For this, I was able to use BingChat (I specified that the language is similar to C and gave an input/output example from mpc-hc shaders).

[toniash]

Some mobile apps have great shaders for video adjustment. Corresponding shaders may not exist or be hard to find for video players, so I'm thinking of releasing a small updated pack of essential lightweight filters. The shaders would be available for hlsl evr-cp, hlsl dx11 and mpv hook.

example: 16-235 to 0-255.hlsl from mpc-hc (1 texture, 1 arithmetic) can be used to stretch the histogram. While it's not its initial purpose, I've found the shader to be useful to boost the contrast of some lackluster internet videos (when activated the haze lifts !).
not for potplayer?:devil:

[butterw2]

My understanding is that potplayer does support hlsl pixel shaders, but I don't know the specifics as I don't use this player.
Some players require the the shaders to have a .txt extension instead of .hlsl.
Video players often come with different shader bundles (ex: mpc-hc vs mpc-be) , some shaders will simply have been renamed. If he has the required folder permissions, the user can delete these shaders and copy whatever shaders he likes to the shader folder

[butterw2]

Video "Enhancements" by the graphics card driver.

The graphics card driver can process video being played back.
ex: Intel graphics command center > Video
This applies to directshow players such as mpc-hc, mpc-be but not vlc, mpv.

for uwp apps (incl. ms store apps like Movies & TV, wmp, windows media, etc.) there is an extra switch to enable/disable this feature.
Win10 > Apps and Features > Video Playback > x automatically process video to enhance it.
or > ms-settings:videoplayback


These adjustments settings (noise reduction, sharpness, skin tone, contrast) can be useful but they are vendor specific and not well documented. It's a manual, slider-based, permanent video adjustment hidden in a tab of the control panel app. You can set up custom profiles, but if you need specific adjustments for one video, you would need to remember to reset to the default profile after watching the video, which typ. isn't practical.

[butterw2]

I've started uploading some simple shaders for my color Adjustment pixel shader pack (A-pack). It will be available for dx9, dx11 and mpv.hook: https://github.com/butterw/bShaders/tree/master/A-pack
The shaders typically only have one parameter and provide easy color adjustments, these can typically be useful when watching (web) videos.

ex: The traditional Brightness control (rgb shift) is poor. vs Lift doesn't affect the white point (1, 1) and vs Exposure doesn't affect the black point (0, 0).
EDIT: The only benefit would be that Brightness doesn't change contrast at all.

[butterw2]

Saturation Adjustment

Saturation refers to the intensity of color. Gray pixels have a saturation of 0, whereas pure color (ex: red) has a saturation of 1.
Sat = max(r, g, b) - min(r, g, b), normalized to [0, 1]

Saturation adjustments need to be small as they can quickly lead to an oversaturated or desaturated picture.

Vibrance attempts to solve this with a smart saturation approach (parameter Vibrance>0: saturate the low saturation areas, <0: desaturate the high saturation areas).

For video player shader based adjustments, 2 shader parameters values would cover most needs:
vibrance.35: get more vibrant colors
vibrance-15: reduce oversaturation

Skintones are quite sensitive to saturation (ex: orange or pasty grey skin) and creating a dedicated shader to correct this issue specifically might be useful.

[butterw2]

Comparing contrast enhancement shaders:

The simplest and fastest approach is to use rgb expansion:
- contrast 0.10
or
- contrastB_W (10_240 to 0_255)
this requires only a single arithmetic operation and the results are typically quite good. The drawback is potential clipping.

A more advanced approach would be to use a S-curve:
Increases contrast in the mid-tones by pushing shadows down and highlights up. This reduces contrast in shadows and highlights, but doesn't clip them.
ex: sweetfx.curves #2 in rgb, Strength: 0.125
(1 texture, 9 arithmetic), incl. 7 arithmetic required to calculate the S-curve.
https://raw.githubusercontent.com/butterw/bShaders/master/img/S-curve.png
! S-curves lose contrast and brightness in shadows, so dark scenes tend to be slightly worse with the s-curve.

Finally there are some fakeHDR type approaches:
Take a SDR input video and try to make it look like HDR. The result is still SDR though.
- sweetfx.fakeHDR (hlsl): (17 texture, 35 arithmetic)
- faux_hdr.glsl

Some conclusions:
- All the listed shaders will enhance a video lacking contrast. Typically more vibrant colors would also be desirable.
- faux_hdr.glsl probably gave the best results (depending on the input), however it isn't a lightweight shader.
- There isn't much need for tuning. The required contrast enhancements are typically small.
- Doing a comparison of multiple shaders (+parameter values) isn't simple, but can be achieved by setting up mpc-hc shader presets or by configuring mpv input.conf.

[butterw2]

Another candidate for lightweight too dark/too bright adjustment shader.

Photoshop Multiply/Screen Blend (brightness/contrast curves)
c0 = (1-Multiply)*c0 + Multiply*c0*c0
with c0: pixel.rgb in [0, 1.0]
(1 texture, 3 arithmetic)

parameter Multiply [-1, 1], 0: no effect
positive: (Multiply Blend) decreases brightness and increases contrast in highlights without clipping.
negative: (Screen Blend) increases brightness and constrast in shadows without clipping.
Apply when picture is too dark. ex: Outdoor night shots, ex: -0.3.

[toniash]

Another candidate for lightweight too dark/too bright adjustment shader.

Photoshop Multiply/Screen Blend (brightness/contrast curves)
c0 = (1-Multiply)*c0 + Multiply*c0*c0
with c0: pixel.rgb in [0, 1.0]
(1 texture, 3 arithmetic)

parameter Multiply [-1, 1], 0: no effect
positive: (Multiply Blend) decrease brightness and increase contrast in highlights without clipping.
negative: (Screen Blend) increases brightness and constrast in shadows without clipping. Ex: -0.3
Could you write a complete HLSL shader so I can use it in PotPlayer?

[toniash]

I'm releasing my complete color adjustment pixel shader pack when I get back home in a few days. It does include tooDark and tooBright hlsl shaders.

In the meantime you could try out one of the already available shaders and let me know if you have any issues with Potplayer.
https://github.com/butterw/bShaders/blob/master/A-pack/Shaders/brighten%2020.hlsl (dx9)
https://github.com/butterw/bShaders/blob/master/A-pack/Shaders11/brighten%2020.hlsl (dx11)
It works, no issues! (dx9) but I prefer curves

[butterw2]

tooDark

@toniash
https://github.com/butterw/bShaders/blob/2da9267860cda5c36b79e95905968a28213f91f6/A-pack/Shaders/tooDark.hlsl
[4-5]: plot for Multiply: -1 and -0.3 (red)

[10-11]: The alternative I was initially considering was a gamma correction style curve (applied in the default sRGB, 1 texture, 9 arithmetic):
pow(c0.rgb, 1.0 - B), with ex: B=0.15 (gamma_c=1/(1-B)=1.1765).

[6 hidden]: The linear equation Exposure c0.rgb *(1.0 + Exposure)
(1 texture, 1 arithmetic) is OK for small adjustments like 0.10, but it does clip inputs>1/(1+Exposure).
However in most cases the required adjustments are small and highlight clipping isn't always an issue with dark videos.
Contrast=1+Exposure is constant.

EDIT: Here's a link to an interactive Desmos calculator plot of the curves:
https://www.desmos.com/calculator/eibkoj8sgp

EDIT2: Whether a video is too dark does depend quite a lot on viewing conditions (ex: daytime vs perfect dark), so it's good to have good adjustment options available.

[butterw2]

Brightness testing Update.

I've done some more testing on Brightness Adjustments.
I use mpc-hc with shader presets set up for each shader+value, and I play test clips, switching the shader on/off and switching between presets. I do this during the day and at night (different lighting conditions).

There are 2 types of useful brightness adjustments:
a1) boosting a clip that could maybe be brighter.
a2) the clip is too dark.

I tested different ajustments curves:
- Legacy brightness adjustment: rgbShift(0.05)
- brightenD(0.06)
- exposure(0.08)
- tooDark(0.15), Multiply: -0.15
- Gamma Correction: bGamma(0.10), gamma_c =1.111
- tooDark(0.20)

Conclusions:
- the legacy brightness adjustment x+Brightness is never good.
The problem of raised black levels can be solved by adding a Shadows term, I call this new shader brightenD:
out = x + Brightness -Brightness*(1-x)^4
with x, out: pixel.rgb in [0, 1.0].
(1 texture, 5 arithmetic).
Contrast is increased in Shadows, but unchanged in the rest of the curve.

- exposure.08 (1 texture, 1 arithmetic)
This small exposure adjustment often works well in a1 case, because it increases both contrast and brightness. It has the lowest increase in brightness in shadows of all the listed approaches. The drawback of exposure is that it blows-up/clips the highlights. This is also true for the previous rgbShift and brightenD approaches.

tooDark doesn't have this problem. The increase in brightness is max at the midpoint. I typically prefer this to a Gamma Correction, which has high contrast near Black and max brightness increase before the midpoint, as this can lead to rather flat images. Also tooDark is significantly faster.
The last two approaches are the best for case a2, as parameter values can be pushed up if needed.

Edit2: There are also higher order curves which have max brightness beyond the midpoint. It's possible to select a curve that doesn't clip (contrast will decreases sharply in the Highlights though). These curves are intermediates between tooDark and exposure.08.

Note: The tooDark shader user parameter has been changed to a positive value as this is more logical. The default value for tooDark will be lowered to 0.24 as this is typically enough for a2 (higher values are possible). Maybe I'll also provide a 0.12 shader for a1 type ajustments without highlights blow-up.

Edit: tooDark.24 and brightenD.06 have the same brightness impact except in Highlights:
https://github.com/butterw/bShaders/blob/master/img/tooDark.24_vs_BrigtenD.06.png?raw=true

[butterw2]

#mpv: Custom On Screen Display (OSD) my mpv.conf file (https://github.com/butterw/bShaders/blob/master/mpv/portable_config/mpv.conf)
This post covers customization of the standard mpv OSD messages, for deeper customization scripts can use an overlay (https://forum.doom9.org/showthread.php?p=1995689#post1995689).

OSD (https://mpv.io/manual/stable/#osd) customization options / properties:
--keep-open=yes Keep the player window open after the end of file is reached. <no, yes, always> default: no
--window-scale The windowed mode video zoom level, default: 1.000
--hidpi-window-scale=no default: yes
--fullscreen (or --fs) start in fullscreen. default: no
--osd-on-seek=msg-bar <no, bar, msg, msg-bar>, default: bar
--osd-msg3="(${percent-pos}%) ${playback-time}" displayed by (P) show-progress and on seeks. displays: (54%) 00:32:20
default: "${playback-time} / ${duration}" : 00:45:10 / 01:30:00
--osd-duration=2000 #default: 1000 (ms)
--osd-margin-x=10 #default: 25 (in scaled pixels)
--osd-margin-y=10 #default: 22
--osd-color= 1.0/0.93/0.93/0.97 r/g/b/a [0, 1.0], or 0.95 gray level. default: white, "#FFFFFFFF"
--osd-back-color= "#e6202020" #argb, a background color makes (small) text much easier to read. default: transparent black.
--osd-font = "Segoe UI" (default: sans-serif >> Arial)
--osd-font-size =40 #default: 55.0
--osd-scale-by-window=no default: yes
--osd-shadow-offset=4 default: 0, you can use this to pad dark-background text (! osd-back-color must not be completely transparent).

osd-bar=yes
--osd-bar-align-y=1.0 (bottom osd-bar). default: 0 middle-bar
--osd-bar-w=100 full-width
--osd-bar-h=0.3 # if you need chapter markers, you could use something like: --osd-bar-h=1.0 --osd-bar-border-size=0.25
--osd-bar-border-size=0 default: 1.2 (mpv0.37-dev)

OSD Messages:
--osd-playing-msg, --term-playing-msg displayed when a new video is loaded, default: ""
--osd-playing-msg-duration (in ms) [0 to 3600000] default: 0 (=osd-duration)
--osd-level <0, 1, 2, 3>, default: 1.
--osd-msg1 default: "" default osd (osd-level=1)
! only one message at a time can be displayed on the default osd.
--osd-msg2 alternate osd (osd-level=2), default display: > 00:45:10
playing > symbol is: "${osd-sym-cc}"
--title The window title. default: "${?media-title:${media-title}}${!media-title:No file} - mpv"
typ. displays: my_video.mp4 - mpv see https://mpv.io/manual/stable/#property-expansion
--term-status-msg terminal status message, ex display: (Pause) AV 00:00:50 / 00:01:02 (80%)
--display-tags comma separated list of metadata tags that are displayed in the terminal, when a new file is loaded.
default: "Artist,Album,Album_Artist,Comment,Composer,Date,Description,Genre,Performer,Rating,Series,Title,Track,icy-title,service_name,Uploader,Channel_URL"
--osd-fractions default: no. times are displayed with milliseconds (hh:mm:ss.xxx)
--background (black bars color) ex:"#FFBBBBBB" default(#ARGB): "#FF000000"
${clock} 24h system time 18:52


# osd-msg display vs osd-level
osd display can be permanent (until changed or disabled) or limited by duration (uses osd-duration by default).
osd-msg1 : default osd (osd-level=1)
osd-msg2 : alternate osd (osd-level=2)
osd-msg3 : show-progress and seeking osd.
with osd-level=3 : osd-msg3 becomes the permanent osd.
osd-level=0 : no-osd on commands, show-text and scripts can still display to osd.
mpv offers plenty of options for customizing the OSD (rendered with libass) and it's possible to go further with user scripts (.lua or .js).

# how to correctly toggle a permanent osd with a keybinding (the osd stays visible until disabled, it will auto-update when needed, in this case when a new file is loaded):
--osd-msg2="${filename}\n${file-size}"
input.conf: O no-osd cycle-values osd-level 2 1

To achieve a similar result with just input.conf, you need to block the property expansion using the `raw` prefix.
input.conf: N raw no-osd cycle-values osd-msg1 ${filename:} ""


stats.conf
An example of OSD achievable with an mpv script is the built-in stats OSD pages (default keybinding: i/I, you can then change the page number: 0-4), page_2 is of particular interest as it shows the output chain (video-filters, scalers and active shader passes).
the script can be configured by portable_config\script-opts\stats.conf https://github.com/mpv-player/mpv/blob/master/DOCS/man/stats.rst or --script-opts
These script-opts options / script.conf file options are a nice feature of mpv, this feature can be added to any user script without too much trouble with mp.options.read_options.
#ex: you can change the temporary display duration in second (default: 4) as it might be a bit short.
duration=10
scroll_lines=5
#rebinding the hotkeys for the different pages with key_page_1, key_page_2, etc. can be useful for non-us keyboards.

[butterw2]

mpv script: avg-bitrate.js /mpv v0.36 user-data

https://raw.githubusercontent.com/butterw/bShaders/master/mpv/scr_mpv_avg-bitrate.jpg

Here's my mpv script that calculates and displays the average bitrate in kbps of the video being played (using the video file properties file-size and duration): https://github.com/butterw/bShaders/blob/master/mpv/settings/scripts/avg-bitrate.js
v0.20: A new property named user-data was added in mpv v0.36. It can be used by scripts to save their data (ex: the calculated avg-bitrate is saved to a custom property named user-scripts/avg-bitrate).
ex, display average bitrate on osd for 2 seconds when key a is pressed:
input.conf: a no-osd show-text "${user-data/avg-bitrate}" 2000

v0.11: v0.11 (https://github.com/butterw/bShaders/blob/e6827e3363310804d1a2ed03bd1cec5b7bb67aba/mpv/settings/scripts/avg-bitrate.js) might be a better starting point for writing very simple custom osd scripts, and it doesn't use user-data (req. mpv v0.36). The output can be printed to the terminal, and/or displayed in the OSD (automatically for every file loaded or (by default) on demand for 0.7seconds via a keybinding).
input.conf: a script-message avg-bitrate

[butterw2]

mpv --no-input-default-bindings

When it comes to keybindings mpv has some great features:
- a separate file for keybindings: portable_config\input.conf: this is a human readable/editable text file that lists the keybindings and comments (including #menu: context-menu entries).
- you can have multiple keybindings for the same command.
- each keybinding can be associated with (custom) commands and script functions.
- it is possible to view the active keybindings on screen (stats > page 4) or export them to the standard output, or test a pressed keyboard key for associated bindings.

Like a number of other video players mpv has far too many keybindings active by default. This isn't helpful, IMO it is better to learn/use just the hotkeys you need and associate them with your favoured keys.
If you use a non-US keyboard you'll likely need to change at least some keybindings.

In mpv, there are two ways of solving this problem:
1) override individual default keybindings:
input.conf: CTRL+c ignore #disables the built-in Ctrl+c quit hotkey.

2) OR more radical: disable all built-in hotkeys, including the default bindings defined in user scripts (with mp.add_key_binding) and use only the ones defined in your input.conf.
mpv.conf or mpv command-line option: --no-input-default-bindings
This is the approach I would recommend for more advanced users. You'll need to have a complete input.conf file ready for this. As a starting point, the file listing the default keybindings is available here: https://github.com/mpv-player/mpv/blob/master/etc/input.conf
# indicates a comment in .conf files. So everything after # on a line will be disregarded.

Finally, the --no-config startup option allows you to test mpv without loading mpv.conf or input.conf (default keybindings are used).

[SirMaster]

If I can make a request?

Can you make an mpv script that displays the APL of the current frame?

Some information about this:
https://projectiondream.com/en/movie-brightness-adl-contrast-measurements/

The Math?:
https://www.avsforum.com/threads/what-i-look-for-while-subjectively-evaluating-a-projector-adl-measurement-tool-added.3222010/page-2#post-61334794

And if you can support both 2.2 and 2.4 gamma for the math, that would be ideal.

If this is even possible, thanks for your consideration!

[SirMaster]

Thanks, I'm sure you are right that Avisynth is a better fit for this.

I will investigate and try to make this work when I get some time.

[butterw2]

The math is just the frame average of the luminance with pow(luma, gamma=2.2 or 2.4) applied. You could do this with avisynth and just overlay the result on the frame (or save to .csv file). I do plan to take a look at vo_gpu_next/libplacebo compute shaders for calculating per frame averages, but currently I don't think there would be any way to transfer the results back to mpv (for display as text).

[butterw2]

#More on mpv custom OSD scripts
Mpv has many features, some of them great, but is often criticised for lacking the level of polish you can expect from GUI players such as mpc-hc on Windows. There hasn't been much progress on this, the on-screen controller script osc.lua is still weak (flawed design, OK in fullscreen but too small in windowed mode, no real user configurable options) and generally not all program defaults are well thought out. One might ask whether it is possible to customize mpv to make it more like a minimal (no-gui) mpc. Maybe with some effort you could come close. I am not going to attempt this, as I have different use cases for mpc-hc/mpc-be and mpv, and I am also not claiming mpc is perfect. Still I think the results of this endeavour would be of interest to some users.

To add some conclusions to my previous posts (https://forum.doom9.org/showthread.php?p=1990436#post1990436) on the subject of custom OSD for mpv:
- Mpv has many built-in OSD options and properties the user can combine.
- But the formats/strings used to display each properties are hardcoded (ex: OSD of file-size, playback-time, etc.) and actually can't be changed by users at all.
- It is possible to override the default OSD through scripting. This typically only requires a couple lines of fairly simple code (but modifying an existing script is probably easier).
- Don't expect script performance to match optimized native compiled code, but lightweight scripts should run OK.
- Javascript has nice syntax, but probably worse performance than lua (if it matters). Not all language features are available, which can make string manipulation troublesome.
- User scripts are less convenient to use than properties as they can't be used in mpv.conf or in startup options. But the new mpv v0.36 user-data custom properties can be used to get around this (see my script below).
- With a stronger OSD, maybe the OSC can be dispensed with alltogether (--no-osc).

My custom OSD stats script for mpv v0.36: https://github.com/butterw/bShaders/blob/master/mpv/settings/scripts/bstat.js
ex, custom osd using new user-data properties (calculated by the script):
--osd-msg2 = "${osd-sym-cc} ${percent-pos}% of ${user-data/duration}\n${user-data/res} ${user-data/ar}\n${user-data/file-size}\n${user-data/avg-bitrate}-${audio-bitrate:}\n${video-format:}: ${video-bitrate:}"

show-time ms: display playback-time / duration to OSD (with optional duration in ms)
For durations less than an hour, the default mpv format 00:25:18 / 00:50:00 gets shortened to 25:18 / 50:00 (like in mpc-hc).

[butterw2]

# time display formats of modern video-players (PC, android, web)
formats used for on-screen-display of playtime / duration.

01:05:28 legacy format: used by many players (0)
when durations >1h, ex: movies.

01:05:28.250 ms precision format available as an option in some players (1)
(@25fps, 1 frame corresponds to 40ms)

08:04 / 51:10 short format, used in mpc-hc and many other players (but not mpc-be) (2)
when duration <1h, ex: TV series, podcasts, ...

00:42 | 01:18:44 Windows media player (3)
short format applied also to playtime

00:42 | 1:18:44 vlc (v3.0.18 PC): short+ format (4)
duration <10h, drops the leading zero on hours for duration and playtime
when playtime<1h, short format applied to playtime.

00:42 | -1:18:02 time-remaining display (replaces duration) (4b)

0:07 / 3:23 Shorter format (5)
when duration <10 minutes, ex: short videos, music, ...

0:42 / 1:18:44 shortest format, used by youtube, web-browsers (6)
35:04 / 1:18:44
1:05:28 / 1:18:44
All leading zeros are dropped for duration and for playtime >1 minute

08:26 / 85:23 minutes only format (7)
08:26 / 117:30 doesn't use hours, just minutes, ex: sport broadcast.
same as short format except for durations >1 hour.

# What does typical video-player time display look like ?

- Internet short clips or Audio file (music):
00:00:00 / 00:00:15 legacy time format 00:00:00 / 00:03:20
00:00 / 00:15 short format 00:00 / 03:20 makes the display significantly more readable when playing short clips.
0:00 / 0:15 shortest 0:00 / 3:20 >>btime.js

- Full length movie:
00:08:00 / 01:42:25 legacy time format
08:00 / 1:42:25 short+ format (vlc pc) >>btime.js
8:00 / 1:42:25 shortest format.

What works best comes down to the duration of the videos, the available screen space and user preferences. The time display format doesn't have to be user configurable, but legacy time format shouldn't be the only option. For PC players, versatile defaults such as mpc-hc or a shorter variant can be good replacements IMO.

EDIT: my lightweight btime.js (https://github.com/butterw/bShaders/blob/master/mpv/settings/scripts/btime.js) script for mpv uses a format similar to youtube (https://raw.githubusercontent.com/butterw/bShaders/master/mpv/settings/scripts/btime_osd-bar.jpg) but better suited for movies. The script can now (https://forum.doom9.org/showthread.php?p=1996141#post1996141) also be configured to display a different time formats (ex: format=mpc-hc).
There are essentially 3 considerations:
1) do you drop the leading zero for hours
2) do you drop the leading zero for minutes
3) do you apply the same format for playtime and duration. This avoids having to add extra time digits during playback.

For something quite different you can try my last seconds countdown OSD (https://github.com/butterw/bShaders/blob/master/mpv/settings/scripts/obs_countdown.js), ex: -10s. The link to the lua version is in the next post.

[butterw2]

# Using shaders (mpv glsl hook) and scripts on mpv-android

shaders and scripts work the same in mpv-android as in mpv.
The build I was using only had lua script support however (no .js).
So I converted my countdown script to lua (https://github.com/butterw/bShaders/blob/master/mpv/settings/scripts/countdown.lua) (with minimal modification the script could also be useful to pass time values to vo_gpu-next shaders for instance to launch transition effects).

My device isn't rooted. To launch shaders or scripts, you need to edit a user mpv.conf file and specify the corresponding paths. The file paths must be readable by mpv-android.
- Create a mpv folder in your android phone's internal storage and place your shaders and scripts in it.
- Using your file manager go into the properties of one of the shader files (ex: a Black&White shader such as bw.hk is useful for testing) and copy the file path.
ex, on my phone: '/storage/emulated/0/mpv/bw.hk'

- Open the mpv-android app:
Settings > Advanced > `edit mpv.conf`: paste the required paths
glsl-shaders=my_path/bw.hk
script=my_path/countdown.lua

This sets the black&white shader and countdown script permanently until disabled. If a correct path was speficied the video should now be shown in black &white.
# to disable the shader or script, you'll need to comment out the corresponding line.

It's also possible to edit input.conf and configure some double-tap gestures to perform custom actions such as toggling a shader.

[Alexkral]

# Comparison of user shader features in the main video players for Windows

To Everyone: Please point out any mistakes/changes, so I can update this guide as needed. The reason for this thread is that the available documentation is sparse and mostly buried in very old/long threads.
You don't need to be a C++ dev to customize or write pixel shaders.



I did some tests to see how different renderers handle the alpha channel. This can be useful because the alpha channel can be used to pass data between shaders in shader chains. I used dx9 shaders in MPC-HC, not sure if other things can change the result as well. The test consisted of simply setting the alpha channel to a value in a shader, and seeing the value received by the next shader in the chain.

EVR-CP:

- Always returns 1 on the alpha channel regardless of the value passed.

MPC-VR (Very creative as you'll see):

- With 8-bit textures, always returns 1 like EVR-CP.
- With 10-bit textures, it returns 1 if you pass 1 and 0 if you pass 0, but if for example you pass 0.5, it returns 0.33, or if you pass 0.75, it returns 0.66.
- With 16-bit textures it returns the same value passed.

madVR:

- Returns the same value passed.

BTW, is there any reason for you not to consider madVR when talking about renderers? It also allows you to run shaders, and is the only one with an option (removed in the latest betas) to store the results with 32-bit precision.

[v0lt]

- With 10-bit textures, it returns 1 if you pass 1 and 0 if you pass 0, but if for example you pass 0.5, it returns 0.33, or if you pass 0.75, it returns 0.66.
Only 2 bits are allocated to the alpha channel for this texture format (D3DFMT_A2R10G10B10 or DXGI_FORMAT_R10G10B10A2_UNORM). Therefore, only 4 values are possible: 0, 0.333, 0.667, 1.

[huhn]

[B]BTW, is there any reason for you not to consider madVR when talking about renderers? It also allows you to run shaders, and is the only one with an option (removed in the latest betas) to store the results with 32-bit precision.

because it didn't age wel- can't display UHD BD correctly. quite buggy without the beta version. and inefficient.

mpcVR just works i have a hard time breaking it and if i break something it's usually the GPU driver that i broke.

[jedi93]

Does anyone know how to get debanding for MPC-HC/MPC-BE ? The shaders from an old thread on this site don't seem to work anymore (atleast not on my setup)...

[BetA13]

Does anyone know how to get debanding for MPC-HC/MPC-BE ? The shaders from an old thread on this site don't seem to work anymore (atleast not on my setup)...

probably because you are trying to use a dx9 shader with a dx11 renderer.
find a deband shader that works with DX11 ;)

[butterw2]

Video renderer surface/texture format (MPC-vr)

If multiple shaders are chained, it is best to avoid the 8bit integer surface/texture format in the video renderer because of precision loss. Default mpc video renderer texture format is Auto 8/10bit Integer, this means that depending on whether the source is 8 or 10bit, the internal format used will be RGBA uint8 or uint10.

Test on mpc-be/mpc-vr dx11 with intel hd graphics: There is some gpu usage overhead with using 16bit floating point (fp16) vs 8bit integer (uint8) surface/texture format (uint10 performs similar to fp16). This would only really be an issue for older/low end machines but it should be noted that this overhead applies whether shaders are used or not.
EDIT: For shaders that pass information using the alpha channel, you need to use fp16.

[butterw2]

Classic sharpen shaders (mods)

I plan to release modded versions of the classic sharpen shaders in the different shader formats (dx9 hlsl, dx11 hlsl, glsl.hook vo_gpu and libplacebo vo_gpu-next).
https://github.com/butterw/bShaders/tree/master/edge/sharpen

Use case:
- improve a slightly soft/blurry video at native resolution.
- or restore sharpness to upscaled video
Ex: x264/x265 compressed (web) video or bluray rip.
video resolution: 720p, 1080p
display: 1080p or 1440p screen/monitor, windowed (100% zoom) or fullscreen.

The sharpen pack will include:
- sharpen(Sharpen_Amount). The fastest kernel is Laplacian1(5 texture, 8 arithmetic). >> uploaded initial dx9 version.
- unsharp mask (Sharpen_Amount, Threshold) based on gaussian 3x3 blur sigma: 0.85
- luma_sharpen (Sharpen_Amount, Clamp) pattern 3: Laplacian1
- sharpen_complex(Sharpen_Amount, Sharpen_Edge, Edge_Threshold)
- edge_sharpen (Sharpen_Edge, Edge_Threshold)

Shaders will have easy to use parameters (ex: Sharpen strength). It will be possible to display the edge detect/details image (Show_Edge).
Hlsl versions of the shaders will not use hardware linear sampling as this feature is disabled in mpc-hc/be (mpc-hc/be does point sampling for non-integer pixel offsets).

[butterw2]

unsharp shader (Sharpen_Amount=0.8, Threshold=0.6, Show_Edge=-1)
(9 texture, 16 arithmetic), threshold: +4 ari

Sharpens using the classic unsharp mask method (available in photo editing application such as photoshop, photodemon, etc.).
Sharpening means increasing the contrast of details. In the unsharp mask method a low-pass filtered (blurred) image is substracted from the original image to obtain the high-frequency detail image.
This shader uses a 3x3 gaussian filter (sigma=0.85) to calculate the blurred image.
detail = original - blurred
sharpened = original + Sharpen_Amount*detail
Detail can have positive or negative values. This corresponds to the positive and negative overshoot on edges and causes the brightness of sharpened details to be increased or decreased.

- Sharpening shaders are typically used post-resize.
- Over-sharpening should be avoided as it will cause a halo on high constrast edges. Sharpening requires a reasonably clean source video (in particular if the source is upscaled on a large display) as it will reenforce existing artefacts such as aliasing, etc.
- A detail threshold value can be applied to only sharpen strong edges or to prevent sharpening of noise/artifacts.
- The Show_Edge parameter allows the display of the threshold mask and edges for analysis.

[butterw2]

Comparing edge detection results
The two sharpening methods (sharpen and unsharp mask) are based on obtaining a detail image: sharpened = original + Sharpen_Amount*detail

Comparing detail image (from sharpener) vs edge image (from edge detector, ex: Sobel):
- both can be thresholded.
- both are obtained from convolution kernels.
- sharpening kernel (ex: Laplacian) generates thin natural looking edges. Sharpener detects texture but also noise/artifacts.
- edge detector has thicker edges but also more reliable output vs noise. (https://raw.githubusercontent.com/butterw/bShaders/master/img/hsplit_scr_Edge_Detect_1080p.jpg)
- edge (from edge detector) is a positive grayscale value usually inferior to 1.0, whereas detail is positive or negative rgb.

To compare edges (A, B) obtained from different edge detector kernels (visually results seem similar):
It is first necessary to match scales as kernel results typically have different amplitudes: adjust scaling factor k to try to best match 10*(A-k*B)==0 and 10*abs(A-k*B)==0. Display of float4(A, k*B, 0, 1) would then be yellow (Red if something is detected on A but not on B, green for detection on B but not on A).

Compared kernels:
- Sobel 3x3 (8 texture, 20 arithmetic) with 2 gradients (horizontal and vertical)
- Prewitt 3x3 (8 texture, 28 arithmetic) with 4 gradients (incl. diagonal), amplitude: 1.025*Sobel
- Adaptive-sharpen_pass1 5x5 diamond (13 texture, 45 arithmetic), amplitude: 1.7*Sobel

Conclusions:
- detected edges are very similar, especially between Prewitt and Sobel.
- Sobel is fastest.
- Adaptive-sharpen sometimes detects (weak) edges that aren't picked up by Sobel.