summaryrefslogtreecommitdiffstats
path: root/DOCS/man/vo.rst
Commit message (Collapse)AuthorAgeFilesLines
* vo_drm: Expose mode ID option to usersMarcin Kurczewski2015-05-281-0/+4
|
* vo_opengl: CMS no longer implies linear scalingNiklas Haas2015-05-271-10/+6
| | | | | | | | | | | They're completely orthogonal concepts, merged in the past due to convenience and ease of implementing it in the old #ifdef hell renderer. Especially after the CMS stuff was generalized by 634b4a, this was a trivial change to implement and also means color management will be much higher quality when enabled with vo=opengl (which had quantization issues in the past due to the 8 bit FBO format and upscaling), since it can be done in a single pass now.
* vo_opengl: icc-profile overrides icc-profile-autoNiklas Haas2015-05-271-2/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: add support for custom shadersNiklas Haas2015-05-271-2/+70
|
* vo_null: add framerate emulationwm42015-05-241-0/+6
|
* vo_opengl: remove npot optionwm42015-05-211-4/+0
| | | | Completely useless.
* vo_xv: make number of buffers configurablewm42015-05-201-0/+6
|
* vo_opengl: change user options for requesting GLESwm42015-05-141-4/+7
| | | | | | | | Instead of having separate backends, make use of GLES a flag. This reduces the number of backends and the resulting annoyances. Also, nobody cares about using GLES, so there's no backward compatibility either.
* vo_opengl_cb: add a "block" framedrop mode and make it defaultwm42015-05-121-2/+4
| | | | | | | | | (I have no idea why there are different modes.) Instead of risking to drop frames too early, give it some margin. Since there are situations this could deadlock, wait with a timeout. This can happen if e.g. the API user is refusing to render anything, or if uninitialization is happening.
* vo_opengl: change default FBO formatwm42015-05-051-2/+2
| | | | | | | | Reduces (but likely does not remove) the danger of rounding intermediate values down to 8 bit. This is important for cscale, or any other processing that might store raw YUV values in framebuffers. Fixes #1918.
* vo_opengl: gl_lcms: replace icc-cache by icc-cache-dirNiklas Haas2015-05-011-4/+7
| | | | | | | | | | This now stores caches for multiple ICC profiles, potentially all the user has ever used. The big use case for this is for users with multiple monitors. The old logic would mandate recomputing the LUT and discarding the cache whenever dragging mpv from one screen to another. This also avoids having to save and check the ICC profile itself, since the file name already uniquely determines it.
* vo_drm: add missing documentationMarcin Kurczewski2015-04-161-0/+13
|
* vo_opengl: change dwmflush option valueswm42015-04-141-3/+4
| | | | | Use a choice instead of an integer. This is incompatible, but I'm not adding any compatibility since this option was added recently.
* vo_opengl: unify blend-subtitles-res and blend-subtitleswm42015-04-111-12/+5
|
* vo_opengl: add blend-subtitles-resNiklas Haas2015-04-101-0/+11
| | | | | This can be used to draw the subtitles at the video's native res, which can make them look more natural and increases performance.
* opengl: win32 - add option 'dwmflush' to sync in DWMAvi Halachmi (:avih)2015-04-091-0/+10
| | | | | | | This could help in cases where the DWM (Windows desktop compositor) adds another layer of bufferring and therefore the SwapBuffers timing could get messed up. Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: make csp options consistent with vf_formatNiklas Haas2015-04-041-9/+9
|
* csputils: add some missing colorspacesNiklas Haas2015-04-041-0/+14
| | | | | With target-prim and target-trc it makes sense to include some common colorspaces that aren't strictly speaking used for video.
* vo_opengl: make jinc presets resizableNiklas Haas2015-04-041-3/+0
| | | | No real reason this is disabled with the new configuration API.
* vo_opengl: add scale-wparam optionNiklas Haas2015-04-041-0/+13
| | | | This lets us tune the window parameter
* vo_opengl: refactor scaler configurationNiklas Haas2015-04-041-12/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This merges all of the scaler-related options into a single configuration struct, and also cleans up the way they're passed through the code. (For example, the scaler index is no longer threaded through pass_sample, just the scaler configuration itself, and there's no longer duplication of the params etc.) In addition, this commit makes scale-down more principled, and turns it into a scaler in its own right - so there's no longer an ugly separation between scale and scale-down in the code. Finally, the radius stuff has been made more proper - filters always have a radius now (there's no more radius -1), and get a new .resizable attribute instead for when it's tunable. User-visible changes: 1. scale-down has been renamed dscale and now has its own set of config options (dscale-param1, dscale-radius) etc., instead of reusing scale-param1 (which was arguably a bug). 2. The default radius is no longer fixed at 3, but instead uses that filter's preferred radius by default. (Scalers with a default radius other than 3 include sinc, gaussian, box and triangle) 3. scale-radius etc. now goes down to 0.5, rather than 1.0. 0.5 is the smallest radius that theoretically makes sense, and indeed it's used by at least one filter (nearest). Apart from that, it should just be internal changes only. Note that this sets up for the refactor discussed in #1720, which would be to merge scaler and window configurations (include parameters etc.) into a single, simplified string. In the code, this would now basically just mean getting rid of all the OPT_FLOATRANGE etc. lines related to scalers and replacing them by a single function that parses a string and updates the struct scaler_config as appropriate.
* vo_opengl: separate kernel and windowNiklas Haas2015-04-041-26/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This makes the core much more elegant, reusable, reconfigurable and also allows us to more easily add aliases for specific configurations. Furthermore, this lets us apply a generic blur factor / window function to arbitrary filters, so we can finally "mix and match" in order to fine-tune windowing functions. A few notes are in order: 1. The current system for configuring scalers is ugly and rapidly getting unwieldy. I modified the man page to make it a bit more bearable, but long-term we have to do something about it; especially since.. 2. There's currently no way to affect the blur factor or parameters of the window functions themselves. For example, I can't actually fine-tune the kaiser window's param1, since there's simply no way to do so in the current API - even though filter_kernels.c supports it just fine! 3. This removes some lesser used filters (especially those which are purely window functions to begin with). If anybody asks, you can get eg. the old behavior of scale=hanning by using scale=box:scale-window=hanning:scale-radius=1 (and yes, the result is just as terrible as that sounds - which is why nobody should have been using them in the first place). 4. This changes the semantics of the "triangle" scaler slightly - it now has an arbitrary radius. This can possibly produce weird results for people who were previously using scale-down=triangle, especially if in combination with scale-radius (for the usual upscaling). The correct fix for this is to use scale-down=bilinear_slow instead, which is an alias for triangle at radius 1. In regards to the last point, in future I want to make it so that filters have a filter-specific "preferred radius" (for the ones that are arbitrarily tunable), once the configuration system for filters has been redesigned (in particular in a way that will let us separate scale and scale-down cleanly). That way, "triangle" can simply have the preferred radius of 1 by default, while still being tunable. (Rather than the default radius being hard-coded to 3 always)
* vo_opengl: remove chroma-location suboptionwm42015-04-031-4/+0
| | | | Terribly obscure, and vf_format can do this for all VOs.
* RPI supportwm42015-03-291-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This requires FFmpeg git master for accelerated hardware decoding. Keep in mind that FFmpeg must be compiled with --enable-mmal. Libav will also work. Most things work. Screenshots don't work with accelerated/opaque decoding (except using full window screenshot mode). Subtitles are very slow - even simple but huge overlays can cause frame drops. This always uses fullscreen mode. It uses dispmanx and mmal directly, and there are no window managers or anything on this level. vo_opengl also kind of works, but is pretty useless and slow. It can't use opaque hardware decoding (copy back can be used by forcing the option --vd=lavc:h264_mmal). Keep in mind that the dispmanx backend is preferred over the X11 ones in case you're trying on X11; but X11 is even more useless on RPI. This doesn't correctly reject extended h264 profiles and thus doesn't fallback to software decoding. The hw supports only up to the high profile, and will e.g. return garbage for Hi10P video. This sets a precedent of enabling hw decoding by default, but only if RPI support is compiled (which most hopefully it will be disabled on desktop Linux platforms). While it's more or less required to use hw decoding on the weak RPI, it causes more problems than it solves on real platforms (Linux has the Intel GPU problem, OSX still has some cases with broken decoding.) So I can live with this compromise of having different defaults depending on the platform. Raspberry Pi 2 is required. This wasn't tested on the original RPI, though at least decoding itself seems to work (but full playback was not tested).
* manpage: update warning on blend-subtitlesNiklas Haas2015-03-271-2/+6
|
* manpage: vo_opengl: blend-subtitles is brokenwm42015-03-271-0/+3
|
* manpage: fix typowm42015-03-261-1/+1
|
* vo_opengl: draw subtitles directly onto the videoNiklas Haas2015-03-261-0/+11
| | | | | | | | | | | | | | | | This has a number of user-visible changes: 1. A new flag blend-subtitles (default on for opengl-hq) to control this behavior. 2. The OSD itself will not be color managed or affected by gamma controls. To get subtitle CMS/gamma, blend-subtitles must be used. 3. When enabled, this will make subtitles be cleanly interpolated by :interpolation, and also dithered etc. (just like the normal output). Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: set cscale=spline36 as default for opengl-hqNiklas Haas2015-03-251-1/+1
| | | | | | | Bilinear scaling is not a suitable default for something named "hq"; the whole reason this was done in the past was because cscale used to be obscenely slow. This is no longer the case, with cscale being nearly free.
* manpage: remove "experimental" notice from dxva2 codewm42015-03-191-1/+1
| | | | | | | It's relatively stable now. Also fix a typo in an unrelated place (better not waste commits on typos).
* man/vo: fix typoMartin Herkt2015-03-151-1/+1
|
* vo_opengl: add oversample support for tscaleNiklas Haas2015-03-151-1/+9
| | | | | This is interesting mainly because it's essentially equivalent to the old smoothmotion algorithm. As such, it is now the default for tscale.
* vo_opengl: add oversample scalerNiklas Haas2015-03-151-0/+6
| | | | | | This is like nearest neighbour, but the edges between pixels are linearly interpolating if needed, as if they had been (naively) oversampled.
* vo_opengl: refactor smoothmotion -> interpolationNiklas Haas2015-03-151-42/+30
| | | | | | | | | | | | | This replaces the old smoothmotion code by a more flexible tscale option, which essentially allows any scaler to be used for interpolating frames. (The actual "smoothmotion" scaler which behaves identical to the old code does not currently exist, but it will be re-added in a later commit) The only odd thing is that larger filters require a larger queue size offset, which is currently set dynamically as it introduces some issues when pausing or framestepping. Filters with a lower radius are not affected as much, so this is identical to the old smoothmotion if the smoothmotion interpolator is used.
* manpage: update cscaleNiklas Haas2015-03-131-4/+1
| | | | Had some outdated information.
* vo_opengl: refactor shader generation (part 2)Niklas Haas2015-03-121-24/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | This adds stuff related to gamma, linear light, sigmoid, BT.2020-CL, etc, as well as color management. Also adds a new gamma function (gamma22). This adds new parameters to configure the CMS settings, in particular letting us target simple colorspaces without requiring usage of a 3DLUT. This adds smoothmotion. Mostly working, but it's still sensitive to timing issues. It's based on an actual queue now, but the queue size is kept small to avoid larger amounts of latency. Also makes “upscale before blending” the default strategy. This is justified because the "render after blending" thing doesn't seme to work consistently any way (introduces stutter due to the way vsync timing works, or something), so this behavior is a bit closer to master and makes pausing/unpausing less weird/jumpy. This adds the remaining scalers, including bicubic_fast, sharpen3, sharpen5, polar filters and antiringing. Apparently, sharpen3/5 also consult scale-param1, which was undocumented in master. This also implements cropping and chroma transformation, plus rotation/flipping. These are inherently part of the same logic, although it's a bit rough around the edges in some case, mainly due to the fallback code paths (for bilinear scaling without indirection).
* manpage: document swapinterval defaultNiklas Haas2015-03-091-1/+2
|
* vo_opengl: add gamma-auto optionStefano Pigozzi2015-03-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | This automatically sets the gamma option depending on lighting conditions measured from the computer's ambient light sensor. sRGB – arguably the “sibling” to BT.709 for still images – has a reference viewing environment defined in its specification (IEC 61966-2-1:1999, see http://www.color.org/chardata/rgb/srgb.xalter). According to this data, the assumed ambient illuminance is 64 lux. This is the illuminance where the gamma that results from ICC color management is correct. On the other hand, BT.1886 formalizes that the gamma level for dim environments to be 2.40, and Apple resources (WWDC12: 2012 Session 523: Best practices for color management) define the BT.1886 dim at 16 lux. So the logic we apply is: * >= 64lux -> 1.961 gamma * =< 16lux -> 2.400 gamma * 16lux < x < 64lux -> logaritmic rescale of lux to gamma. The human perception of illuminance roughly follows a logaritmic scale of lux [1]. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/dd319008%28v=vs.85%29.aspx
* vo_opengl: implement antiringing for tensor scalersNiklas Haas2015-02-271-3/+2
| | | | | | | | | | | | This is based on pretty much the same (somewhat naive) logic right now. I'm not convinced that the extra logic that eg. madVR includes is worth enough to warrant heavily confusing the logic for it. This shouldn't slow down the logic at all in any sane shader compiler, and indeed it doesn't on any shader compiler that I tested. Note that this currently doesn't affect cscale at all, due to the weird implementation details of that.
* manpage: update documentation for smoothmotionNiklas Haas2015-02-241-8/+27
| | | | | | | | | | | Hopefully, this will really clear up how the thing is supposed to work (and that it's not SVP, nor MVTools). I also removed instances of the word "interpolation", since that's a term that's easily misleading. Finally, I expanded on smoothmotion-threshold since the purpose/meaning was a bit confusing.
* filter_kernels: add ewa_lanczossharp aliasNiklas Haas2015-02-241-2/+10
| | | | | This is essentially a preconfigured version of ewa_lanczos, with the "best" parameters for general purpose usage.
* filter_kernels: add blur parameter to jincNiklas Haas2015-02-231-0/+6
| | | | | This affects all filters that use it, eg. ewa_lanczos. Setting it to something like 0.95 can be done to make the filter a bit less blurry.
* manpage: document scale-param1 properlyNiklas Haas2015-02-231-8/+15
| | | | | Right now, nothing in the man page says what it actually affects, other than for mitchell. I added a list to make it clear.
* manpage: update for new EWA filtersNiklas Haas2015-02-231-2/+2
| | | | | | The man page was still referring to ewa_lanczos exclusively in a few places, even though new EWA filters have been introduced in the meantime.
* filter_kernels: rename ginseng to ewa_ginsengNiklas Haas2015-02-231-1/+1
| | | | | | This is done mainly for consistency, since all of the EWA filters share similar properties and it's important to distinguish them for documentation purposes.
* vo_opengl: add ginseng upscalerNiklas Haas2015-02-201-1/+1
| | | | | | | | | This is a variation of ewa_lanczos that is sinc-windowed instead of jinc-windowed. Results are pretty similar, but the logic is simpler. This could potentially replace the ugly ewa_lanczos code. It's hard to tell, but from comparing stills I think this one has slightly less ringing than regular ewa_lanczos.
* Revert "vo_opengl: disable alpha by default"wm42015-02-061-1/+1
| | | | | | | | | | This reverts commit a33b46194c3525cb585cc78b449ec275dbfd7f83. It turns out FFmpeg really considers this a bug, and fixed it by making the decoder output the correct pixel format. Fixes #1565. Reverts the fix #1528, though it should work fine with a recent git master FFmpeg.
* vo_opengl: add support for linear scaling without CMSNiklas Haas2015-02-061-5/+10
| | | | | | | | | | This introduces a new option linear-scaling, which is now implied by srgb, icc-profile and sigmoid-upscaling. Notably, this means (sigmoidized) linear upscaling is now enabled by default in opengl-hq mode. The impact should be negligible, and there has been no observation of negative side effects of sigmoidized scaling, so it feels safe to do so.
* cocoa: automatically fetch display-fps from the monitorStefano Pigozzi2015-02-031-2/+2
| | | | | | | | | | | | Comment explains why I have been so doubtful at adding this. The Apple docs say CGDisplayModeGetRefreshRate is supposed to work only for CRTs, but it doesn't, and actually works for LCD TVs connected over HDMI and external displays (at least that's what I'm told, I don't have the hardware to test). Maybe Apple docs are incorrect. Since AFAIK Apple doesn't want to give us a better API – maybe in the fear we might be able to actually write some useful software instead of "apps" – I decided not to care as well and commit this.
* vo_opengl: disable alpha by defaultwm42015-02-031-1/+1
| | | | | | | | | | | | | This reverts the default behavior introduced in commit 93feffad. Way too often libavcodec will return RGB data that has an alpha channel as per pixel format, but actually contains garbage. On the other hand, this will actually render garbage color values in e.g. PNG files (for pixels with alpha==0, the color value should be essentially ignored, which is what the old alpha blend mode did). This "fixes" #1528, which is probably a decoder bug (or far less likely, a broken file).
* vo_opengl: change initialization of gamma optionwm42015-02-031-7/+5
| | | | | | | | | | Make the lazy gamma initialization less weird, and make the default value of the "gamma" sub-option 1.0. This means --vo=opengl:help will list the actual default value. Also change the lower bound to 0.1 - avoids a division by zero (I don't know how shaders handle NaN, but it's probably not a good idea to give them this value).
* vo_opengl: change upper bound of :gamma to 2.0Niklas Haas2015-02-031-1/+1
| | | | | This allows a spread of 1.0 in either direction, which is already close to absurd. Anything higher than that is pretty pointless.
* manpage: add recommended values to :gamma suboptionNiklas Haas2015-02-031-4/+12
| | | | | | | | These were derived from dividing our assumed video gamut (1.961) by some typical screen values (2.2 for dimly lit and 2.4 for pitch black): 1.961/2.4 = 0.8170833333333334 ~= 0.8 1.961/2.2 = 0.8913636363636364 ~= 0.9
* man: expand on the smoothmotion documentationStefano Pigozzi2015-01-281-4/+13
| | | | | Hopefully this will clear up how the thing is supposed to work (and that it's not SVP, nor MVTools).
* manpage: fix smoothmotion-threshold value rangewm42015-01-261-1/+1
|
* vo_opengl, x11: implement icc-profile-autowm42015-01-261-1/+1
| | | | | | | | | | | | | | | | | This queries the _ICC_PROFILE property on the root window. It also tries to reload the ICC when it changes, or if the mpv window changes the monitor. (If multiple monitors are covered, mpv will randomly select one of them.) The official spec is a dead link on freedesktop.org, so don't blame me for any bugs. Note that this assumes that Xinerama screen numbers match the way mpv enumerates the xrandr monitors. Although there is some chance that this matches, it most likely doesn't, and we actually have to do complicated things to map the screen numbers. If it turns out that this is required, I will fix it as soon as someone with a suitable setup for testing the fix reports it.
* vo_opengl: make "mitchell" the hq default filter for downscalingwm42015-01-261-1/+1
| | | | | | | | | | |