summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* audio/filter: remove delay audio filterPaul B Mahol2016-08-121-28/+0
| | | | Similar filter is available in libavfilter.
* command: add a property that returns filename without extensionwm42016-08-111-0/+6
| | | | Requested. Fixes #3404.
* manpage: remove the word "slave"wm42016-08-111-6/+6
| | | | It's discriminatory or something.
* player: add --no-autoload-files optionwm42016-08-101-0/+10
| | | | Allt his auto-loading is getting annoying especially for testing.
* player: add --audio-wait-open optionswm42016-08-091-0/+8
| | | | Complements the option added in the previous commit.
* player: add --audio-stream-silencewm42016-08-091-0/+11
| | | | | Completely insane that this has to be done. Crap for compensating HDMI crap.
* DOCS/release-policy.md: reminder to update certain version numberswm42016-08-071-1/+2
|
* client API: bump API for stream_cbwm42016-08-071-0/+2
| | | | | | | | | Forgotten in previous commit. Also minor semi-related change: remove the extra "," from the mpv_sub_api enum, which I accidentally added in the previous commit. (C99 is fine with trailing ",", C89 strictly speaking not. So do this for maximum compatibility.)
* audio: use --audio-channels=auto behavior, except on ALSAwm42016-08-041-19/+44
| | | | | | | | | | | | | | | | | | | | | | | This commit adds an --audio-channel=auto-safe mode, and makes it the default. This mode behaves like "auto" with most AOs, except with ao_alsa. The intention is to allow multichannel output by default on sane APIs. ALSA is not sane as in it's so low level that it will e.g. configure any layout over HDMI, even if the connected A/V receiver does not support it. The HDMI fuckup is of course not ALSA's fault, but other audio APIs normally isolate applications from dealing with this and require the user to globally configure the correct output layout. This will help with other AOs too. ao_lavc (encoding) is changed to the new semantics as well, because it used to force stereo (perhaps because encoding mode is supposed to produce safe files for crap devices?). Exclusive mode output on Windows might need to be adjusted accordingly, as it grants the same kind of low level access as ALSA (requires more research). In addition to the things mentioned above, the --audio-channels option is extended to accept a set of channel layouts. This is supposed to be the correct way to configure mpv ALSA multichannel output. You need to put a list of channel layouts that your A/V receiver supports.
* options: add vp9 to --hwdec-codecswm42016-07-301-3/+3
|
* 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
| | | | | | |<