summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* vo_opengl: remove the 3dlut-size npot2 restrictionNiklas Haas2016-07-251-2/+1
| | | | | | | | This requires changing the pixel upload alignment because the odd sizes might not be aligned to multiples of 4. Anyway, the restriction has no real benefit and the sizes in between 32 and 64 might be worth using, so just drop it.
* vo_opengl: reduce default 3dlut-size to 64x64x64Niklas Haas2016-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Following testing after ebe798a, this is a more than sufficient size to cover our use case. The old default was a drop of about 58 dB PSNR using the old code, and this new default is about 65 dB PSNR, so it's actually an improvement despite resulting in a smaller size. There was no outlier whatsoever when comparing sizes around the 64 neighbourhood (with every step corresponding to a PSNR drop of about 0.07 dB), so I picked this since it's a power of two and requires no change to the current 3dlut-size parsing logic. I also tested smaller sizes such as 32x32x32 which performed almost as well on colorful samples, but this results in noticeable black boost in the dark regions, which is pretty undesirable. Therefore, we should avoid going much further below 64x64x64. Either way, this new size is so fast to compute that the 3dlut cache is almost useless on my end. In fact, it might even be slower to load the profile from the cache than to recompute it from scratch. (For caches on a disk. For cache on a tmpfs, it makes no difference)
* manpage: not-document tscale=linearwm42016-07-211-0/+3
|
* audio: refactor mixer code and delete mixer.cwm42016-07-173-0/+9
| | | | | | | | | | | | | | | | | mixer.c didn't really deserve to be separate anymore, as half of its contents were unnecessary glue code after recent changes. It also created a weird split between audio.c and af.c due to the fact that mixer.c could insert audio filters. With the code being in audio.c directly, together with other code that unserts filters during runtime, it will be possible to cleanup this code a bit and make it work like the video filter code. As part of this change, make the balance code work like the volume code, and add an option to back the current balance value. Also, since the balance semantics are unexpected for most users (panning between the audio channels, instead of just changing the relative volume), and there are some other volumes, formally deprecate both the old property and the new option.
* vf_d3d11vpp: add video processor selectionwm42016-07-151-0/+6
| | | | | Unfortunately completely useless. I still don't know how to force a video processor to use a specific algorithm, if it's even possible.
* videotoolbox: add yuv420p to --videotoolbox-formatwm42016-07-151-2/+2
|
* man: fix PDF build errorMartin Herkt2016-07-151-0/+1
| | | | | | | ReportLab really doesn’t like breaking inline literals, so insert an explicit line break. Fixes #3338
* videotoolbox: add --hwdec=videotoolbox-copy for h/w accelerated decoding ↵Aman Gupta2016-07-151-0/+1
| | | | with video filters
* DOCS/compile-windows.md: MSVC DLL usage instructionswm42016-07-141-0/+18
|
* Use - as command-name separator everywhereTimotej Lazar2016-07-146-17/+17
| | | | | | | Old-style commands using _ as separator (e.g. show_progress) were still used in some places, including documentation and configuration files. This commit updates all such instances to the new style (show-progress) so that commands are easier to find in the manual.
* manpage: add some missing color management related sub-propertieswm42016-07-131-0/+3
|
* command: add properties for HDR metadataNiklas Haas2016-07-131-0/+6
| | | | | | | | | Since it turns out that knowing what exactly a file was tagged with can be useful for debugging purposes, expose this as a property so I can check it more easily. This is mostly useful for sig-peak (since nom-peak is currently entirely calculated by us), but I added both for consistency.
* manpage: minor fixwm42016-07-102-3/+3
| | | | Also fix some other type in interface-changes.rst.
* man: fix typowm42016-07-091-1/+1
|
* audio: drop --softvol=no and --softvol=autowm42016-07-093-37/+51
| | | | | | | | | | | | | | Drop the code for switching the volume options and properties between af_volume and AO volume controls. interface-changes.rst mentions the changes in detail. Do this because this was exceedingly complex and had other problems as well. It was also very hard to test. It's just not worth the trouble. Some leftovers like AOCONTROL_HAS_PER_APP_VOLUME will be removed at a later point. Fixes #3322.
* man: fix typosJakub Wilk2016-07-095-11/+11
|
* man: fix botched sentencewm42016-07-081-3/+3
| | | | Fixes #3323.
* client API: remove "status" log level from mpv_request_event docswm42016-07-081-0/+4
| | | | | | Although it appears to be accepted by the function, MSGL_STATUS messages are never passed to the client API. Consequently "status" has the same meaning as "v" and is useless.
* manpage: document confusing "vf clr" command usagewm42016-07-031-0/+2
|
* command: pack sub image data in overlay-add commandwm42016-07-011-21/+11
| | | | | | | | | | | | | | Working towards refcounted sub images, and also for removing bitmap packers from VOs. I'm not sure why we even have this overlay-add command. It was sort of "needed" before opengl-cb was introduced, and before Lua scripts could put ASS drawings on OSD without conflicting with the OSC. But now trying to use it doesn't make too much sense anymore. Still keep it because we're trying to be nice, but throw performance out of the window. Now image data is copied 2 more times before displaying it. This also makes using the command a bit simpler.
* options: deprecate --heartbeat-cmdwm42016-06-292-0/+10
| | | | | It's useless. --heartbeat-interval is also considered deprecated, but this is not made explicit.
* vo_opengl: add output_size uniform to custom shaderMuhammad Faiz2016-06-281-0/+3
| | | | | | logically, scaler should know its input and output size Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: implement the Panasonic V-Log functionNiklas Haas2016-06-282-0/+3
| | | | | | | | | | User request and not that hard. Closes #3157. Note that FFmpeg doesn't support this and there's no signalling in HEVC etc., so the only way users can access it is by using vf_format manually. Mind: This encoding uses full range values, not TV range.
* manpage: add missing documentation for vf_format:gamma=dci-p3Niklas Haas2016-06-281-0/+1
|
* csputils: add Panasonic V-Gamut primariesNiklas Haas2016-06-282-0/+3
| | | | | | | This is actually not entirely trivial since it involves negative Yxy coordinates, so the CMM has to be capable of full floating point operation. Fortunately, LittleCMS is, so we can just blindly implement it.
* manpage: warn about the use of HDR functions for target-trcNiklas Haas2016-06-281-0/+6
| | | | | | | Most devices seems to require special signalling (e.g. via HDMI metadata) to actually decode HDR signals and treat them as such, so it's probably worth warning the potential user about the fact that mpv pretty definitely does *not* set any of this metadata signalling.
* vo_opengl: implement ARIB STD-B68 (HLG) HDR TRCNiklas Haas2016-06-282-0/+3
| | | | | | | | | | | | | | This HDR function is unique in that it's still display-referred, it just allows for values above the reference peak (super-highlights). The official standard doesn't actually document this very well, but the nominal peak turns out to be exactly 12.0 - so we normalize to this value internally in mpv. (This lets us preserve the property that the textures are encoded in the range [0,1], preventing clipping and making the best use of an integer texture's range) This was grouped together with SMPTE ST2084 when checking libavutil compatibility since they were added in the same release window, in a similar timeframe.
* Fix misspellingsstepshal2016-06-261-1/+1
|
* manpage: fix typowm42016-06-261-1/+1
|
* DOCS: change version references from 0.17.1 to 0.18.0wm42016-06-253-6/+6
| | | | 0.17.1 was never released, so the actual 0.18.0 release takes its place.
* af_lavcac3enc: make encoder configurablewm42016-06-231-1/+5
|
* vo_opengl: vdpau interop without RGB conversionwm42016-06-191-3/+6
| | | | | | | | | | | | | | | | | | | | | | Until now, we've always converted vdpau video surfaces to RGB, and then mapped the resulting RGB texture. Change this so that the surface is mapped as NV12 plane textures. The reason this wasn't done until now is because vdpau surfaces are mapped in an "interlaced" way as separate fields, even for progressive video. This requires messy reinterleraving. It turns out that even though it's an extra processing step, the result can be faster than going through the video mixer for RGB conversion. Other than some potential speed-gain, doing this has multiple other advantages. We can apply our own color conversion, which is important in more complex cases. We can correctly apply debanding and potentially other processing that requires chroma-specific or in-YUV handling. If deinterlacing is enabled, this switches back to the old RGB conversion method. Until we have at least a primitive deinterlacer in vo_opengl, this will stay this way. The d3d11 and vaapi code paths are similar. (Of course these don't require any crazy field reinterleaving.)
* vo_opengl: remove prescaling framework with superxbr prescalerBin Jin2016-06-182-32/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: remove nnedi3 prescalerBin Jin2016-06-181-31/+1
|
* vo_opengl: make size of OUTPUT available to user shadersBin Jin2016-06-121-3/+3
|
* vo_opengl: refactor performance data propertiesNiklas Haas2016-06-081-24/+38
| | | | | | | | | | | | | | | Instead of having 9 different properties, requiring 18 different VOCTRLs to read them all, they are now exposed as a single property. This is not only cleaner (since they're all together) but also allows querying all 9 of them with only a single VOCTRL (by using mp.get_property_native). (The extra factor of 2 was due to an extra query being needed to get the type, which is now also unnecessary) This makes it much easier to access performance metrics from within a lua script, and also makes it easier to just show a readable, formatted version via show-text.
* vo_opengl: make user hook passes optionalNiklas Haas2016-06-081-4/+11
| | | | | | | | | | | | | | | | User hooks can now use an extra WHEN expression to specify when the shader should be run. For example, this can be used to only run a chroma scaling shader `WHEN CHROMA.w LUMA.w <`. There's a slight semantics change to user shaders: When trying to bind a texture that does not exist, a shader will now be silently skipped (similar to when the condition is false) instead of generating an error. This allows shader stages to depend on an optional earlier stage without having to copy/paste the same condition everywhere. (In other words: there's an implicit condition on all of the bound textures existing)
* vo_opengl: expose performance timers as propertiesNiklas Haas2016-06-071-0/+24
| | | | | | | | | | | This is plumbed through a new VOCTRL, VOCTRL_PERFORMANCE_DATA, and exposed as properties render-time-last, render-time-avg etc. All of these numbers are in microseconds, which gives a good precision range when just outputting them via show-text. (Lua scripts can obviously still do their own formatting etc.) Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: apply vo-cmdline command incrementallywm42016-06-051-0/+5
| | | | | | | | | | Instead of implicitly resetting the options to defaults and then applying the options, they're always applied on top of the current options (in the same way adding new options to the CLI command line will). This does not apply to vo_opengl_cb, because that has an even worse mess which I refuse to deal with.
* manpage: update --hwdec=d3d11va remarkswm42016-05-311-5/+3
|
* vo_opengl: default hdr-tone-mapping to hableNiklas Haas2016-05-301-3/+4
| | | | | | | | | This algorithm works really well. Setting it is a much better "out-of-the-box" experience than just clipping, which will always look ugly. In other words, with this default, users of mpv will just be able to play HDR content without even realizing it's HDR (pretty much).
* vo_opengl: refactor HDR mechanismNiklas Haas2016-05-302-3/+12
| | | | | | | | | | | | | | | | | | | | Instead of doing HDR tone mapping on an ad-hoc basis inside pass_colormanage, the reference peak of an image is now part of the image params (alongside colorspace, gamma, etc.) and tone mapping is done whenever peak_src != peak_dst. To get sensible behavior when mixing HDR and SDR content and displays, target-brightness is a generic filler for "the assumed brightness of SDR content". This gets rid of the weird display_scaled hack, sets the framework for multiple HDR functions with difference reference peaks, and allows us to (in a future commit) autodetect the right source peak from the HDR metadata. (Apart from metadata, the source peak can also be controlled via vf_format. For HDR content this adjusts the overall image brightness, for SDR content it's like simulating a different exposure)
* vo_opengl: add hable tone-mapping algorithmNiklas Haas2016-05-301-0/+3
| | | | | | | | Developed by John Hable for use in Uncharted 2. Also used by Frictional Games in SOMA. Originally inspired by a filmic tone mapping algorithm created by Kodak. From http://frictionalgames.blogspot.de/2012/09/tech-feature-hdr-lightning.html
* vo_opengl: rename tone-mapping=simple to reinhardNiklas Haas2016-05-301-4/+4
| | | | | This is the canonical name for the algorithm. I simply didn't know it before.
* vf_d3d11vpp: add a D3D11 video processor filterwm42016-05-281-0/+9
| | | | | | | | | | | | | | | | | Main use: deinterlacing. I'm not sure how to select the deinterlacing mode at all. You can enumate the available video processors, but at least on Intel, all of them either signal support for all deinterlacers, or none (the latter is apparently used for IVTC). I haven't found anything that actually tells the processor _which_ algorithm to use. Another strange detail is how to select top/bottom fields and field dominance. At least I'm getting quite similar results to vavpp on Linux, so I'm content with it for now. Future plans include removing the D3D11 video processor use from the ANGLE interop code.
* command: add playlist-pos-1 propertywm42016-05-261-0/+3
| | | | | | | | | | This has often been requested for use on OSD. I don't really like having such "special" properties, but whatever. Hopefully this will be the only case. Untested because I'm too damn lazy. Fixes #2828.
* vo_opengl: always autoselect ANGLE as backend if availablewm42016-05-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | Remove the opengl-hq option default that caused it not to autoselect ANGLE (unlike --vo=opengl). Details see commit d5df90a2. Back then the intention was to use ANGLE by default, since it integrates much nicer with the Windows compositor (instead of native OpenGL, which tends to cause crazy glitches). On the other hand, many opengl-hq capabilities are not available with older ANGLE builds, so it didn't make any sense to autoselect ANGLE for it. With the GL_EXT_texture_norm16 extension recently added to ANGLE, it has essentially reached feature parity to desktop GL for the subset we are using. (Even the integer texture hack for high bit depth input could be dropped now.) It (probably) still does not support nnedi3, due to the weird way the NN coefficients are imported. Also, it uses half-floats instead of 16 bit fixed-point textures for technical reasons, which implies about 5 bits of precision loss. If anyone actually manages to distinguish the two dithering texture formats in a double-blind test, I will fix it.
* manpage: adjust dxva2 descriptionwm42016-05-231-3/+6
|
* manpage: document how hardware decoding might cause quality losswm42016-05-231-0/+36
|
* docs: fix some typosBen Boeckel2016-05-232-2/+2
|
* vo_opengl: remove non-working rgb/rgba FBO formatswm42016-05-202-1/+3
| | | | | | | | | | | Following commit 84ccebd9, the internal helpers don't allow GL_RGB and GL_RGBA as internal formats for FBO attachments anymore. While OpenGL itself is perfectly fine with it, I don't see much of a reason to bother, and mixing sized and unsized internal formats is confusing anyway. Just remove these formats.
* DOCS/mplayer-changes: document HDR supportNiklas Haas2016-05-161-1/+2
| | | | Marketing told me to do so.
* manpage: declare user-shader syntax for not stablewm42016-05-161-0/+4
|
* vo_opengl: implement more HDR tonemapping algorithmsNiklas Haas2016-05-161-3/+32
| | | | | | | | | | | | | | | | | | | | | This is now a configurable option, with tunable parameters. I got inspiration for these algorithms off wikipedia. "simple" seems to work pretty well, but not well enough to make it a reasonable default. Some other notable candidates: - Local functions (e.g. based on local contrast or gradient) - Clamp with soft knee (linear up to a point) - Mapping in CIE L*Ch. Map L smoothly, clamp C and h. - Color appearance models These will have to be implemented some other time. Note that the parameter "peak_src" to pass_tone_map should, in principle, be auto-detected from the SEI information of the source file where available. This will also have to be implemented in a later commit.
* vo_opengl: implement HDR (SMPTE ST2084)Niklas Haas2016-05-162-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | Currently, this relies on the user manually entering their display brightness (since we have no way to detect this at runtime or from ICC metadata). The default value of 250 was picked by looking at ~10 reviews on tftcentral.co.uk and realizing they all come with around 250 cd/m^2 out of the box. (In addition, ITU-R Rec. BT.2022 supports this) Since there is no metadata in FFmpeg to indicate usage of this TRC, the only way to actually play HDR content currently is to set ``--vf=format=gamma=st2084``. (It could be guessed based on SEI, but this is not implemented yet) Incidentally, since SEI is ignored, it's currently assumed that all content is scaled to 10,000 cd/m^2 (and hard-clipped where out of range). I don't see this assumption changing much, though. As an unfortunate consequence of the fact that we don't know the display brightness, mixed with the fact that LittleCMS' parametric tone curves are not flexible enough to support PQ, we have to build the 3DLUT against gamma 2.2 if it's used. This might be a good thing, though, consdering the PQ source space is probably not fantastic for interpolation either way. Partially addresses #2572.
* vo_opengl: abstract hook texture access behind macroNiklas Haas2016-05-151-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | This macro takes care of rotation, swizzling, integer conversion and normalization automatically. I found the performance impact to be nonexistant for superxbr and debanding, although rotation *did* have an impact due to the extra matrix multiplication. (So it gets skipped where possible) All of the internal hooks have been rewritten to use this new mechanism, and the prescaler hooks have finally been separated from each other. This also means the prescale FBO kludge is no longer required. This fixes image corruption for image formats like 0bgr, and also fixes prescaling under rotation. (As well as other user hooks that have orientation-dependent access) The "raw" attributes (tex, tex_pos, pixel_size) are still un-rotated, in case something needs them, but ideally the hooks should be rewritten to use the new API as much as possible. The hooked texture has been renamed from just NAME to NAME_raw to make script authors notice the change (and also deemphasize direct texture access). This is also a step towards getting rid of the use_integer pass.
* vo_opengl: use RPN expressions for user hook sizesNiklas Haas2016-05-151-7/+17
| | | | | | | | | This replaces the previous TRANSFORM by WIDTH, HEIGHT and OFFSET where WIDTH and HEIGHT are RPN expressions. This allows for more fine-grained control over the output size, and also makes sure that overwriting existing textures works more cleanly. (Also add some more useful bstr functions)
* vo_opengl: support external user hooksNiklas Haas2016-05-151-0/+113
| | | | | | | | | | | This allows users to add their own near-arbitrary hooks to the vo_opengl processing pipeline, greatly enhancing the flexibility of user shaders. This enables, among other things, user shaders such as CrossBilateral, SuperRes, LumaSharpen and many more. To make parsing the user shaders easier, shaders are now loaded as bstrs, and the hooks are set up during video reconfig instead of on every single frame.
* lua: add timer:is_enabled() functionJulian2016-05-141-0/+4
| | | | | Allows to query if some timer is currently running or was stopped/killed.
* manpage: document missing sub-propertieswm42016-05-111-0/+2
| | | | | This is the client-API part; the normal descriptions are present in the text above.
* video: add --hwdec=auto-copy modewm42016-05-111-0/+8
| | |