summaryrefslogtreecommitdiffstats
path: root/DOCS
Commit message (Collapse)AuthorAgeFilesLines
* sub: add --sub-text-bold optionwm42015-04-011-0/+3
| | | | This was basically requested.
* ao_wasapi: fix device listingKevin Mitchell2015-03-311-12/+12
| | | | | remove depricated and convoluted validation. refer instead to the --audio-device option.
* manpage: correct option minchn->minch for lavcac3encKevin Mitchell2015-03-301-3/+3
|
* manpage: clarify global config file locationwm42015-03-311-1/+3
| | | | (Stupid Unix conventions.)
* options: make --video-rotate use range 0-360wm42015-03-311-1/+1
| | | | | Include 360 in the range and don't stop at 359. This makes cycling through the range in 90° steps less awkward.
* video: move colorspace overrides to vf_format, simplifywm42015-03-312-95/+91
| | | | | | | | | | | | | | | | | | | Remove the colorspace-related top-level options, add them to vf_format. They are rather obscure and not needed often, so it's better to get them out of the way. In particular, this gets rid of the semi-complicated logic in command.c (most of which was needed for OSD display and the direct feedback from the VO). It removes the duplicated color-related name mappings. This removes the ability to write the colormatrix and related properties. Since filters can be changed at runtime, there's no loss of functionality, except that you can't cycle automatically through the color constants anymore (but who needs to do this). This also changes the type of the mp_csp_names and related variables, so they can directly be used with OPT_CHOICE. This probably ended up a bit awkward, for the sake of not adding a new option type which would have used the previous format.
* vf_format: don't crash if nonsense parameters are passedwm42015-03-311-11/+2
| | | | | | | It was "by design" possible to make mpv crash if the parameters didn't make enough sense, like "format=rgb24:yuv420p". While forcing the format has some minor (rather questionable) use for debugging, allowing it to crash is just stupid.
* vf_format: by default, pass through video without changewm42015-03-311-1/+1
| | | | | | Instead of forcing a useless format (packed YUV??) by default. Also cleanup.
* csputils: unify names for colorspace/etc. nameswm42015-03-311-9/+9
|
* ad_lavc: disable AC3 DRC by defaultwm42015-03-301-2/+5
|
* RPI supportwm42015-03-292-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* ao_alsa: add an option to ignore ALSA channel map negotiationwm42015-03-281-0/+8
| | | | This was requested, more or less.
* 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.
* command: add property returning current working directorywm42015-03-241-0/+4
| | | | Requested; fixes #1717.
* input: remove Linux joystick supportwm42015-03-243-8/+1
| | | | | | | | | | | Why did this exist in the first place? Other than being completely useless, this even caused some regressions in the past. For example, there was the case of a laptop exposing its accelerometer as joystick device, which led to extremely fun things due to the default mappings of axis movement being mapped to seeking. I suppose those who really want to use their joystick to control a media player (???) can configure it as mouse device or so.
* input: remove classic LIRC supportwm42015-03-243-11/+8
| | | | It's much easier to configure remotes as X11 input devices.
* manpage: ipc: make requirements for newlines more explicitwm42015-03-231-0/+3
| | | | Clarifying because someone asked.
* manpage: remove "experimental" notice from dxva2 codewm42015-03-192-2/+2
| | | | | | | It's relatively stable now. Also fix a typo in an unrelated place (better not waste commits on typos).
* manpage: add a link to mpv.conf documentationwm42015-03-171-1/+1
| | | | Like we do it for input.conf and osc.conf.
* DOCS: fix compilation instructions for MXE crosscompilationgunmantheh2015-03-171-0/+1
| | | | | | Add bootstrap step for Linux->Windows MXE crosscompilation. Signed-off-by: wm4 <wm4@nowhere>
* 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.
* man: fix PDF buildMartin Herkt2015-03-151-3/+4
|
* manpage: update cscaleNiklas Haas2015-03-131-4/+1
| | | | Had some outdated information.
* options: introduce --cache=yes choicewm42015-03-121-2/+4
| | | | | | I think this is what I alwass missed ever since I found the MPlayer cache options: a way to enable the cache on local files with the default settings, whatever they are.
* cache: bump default size to 150MBwm42015-03-121-1/+1
| | | | (Well, almost 150MB.)
* command: display-fps is the display FPS as assumed by the VOwm42015-03-121-3/+3
| | | | | | | | | Requested change in behavior. Note that we set the assumed "infinite" display_fps to 1e6, which conveniently lets vo_get_vsync_interval() return a dummy value of 1, which can be easily checked against, and still avoids doing math with float INFs.
* 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).
* command: add display-fps propertywm42015-03-101-0/+7
| | | | Requested. Untested; leaving that to the users.
* manpage: document swapinterval defaultNiklas Haas2015-03-091-1/+2
|
* input.conf: add key binding to override ASS subtitle styleswm42015-03-081-0/+5
|
* DOCS: minor update to coding stylewm42015-03-081-0/+2
|
* DOCS/compile-window.md: add Lua package to MXE instructionswm42015-03-061-2/+2
| | | | The MSYS2 ones already mention Lua.
* DOCS, options: fix exampleChrisK22015-03-051-1/+1
|
* client API: mention the changes to the seek/screenshot commandswm42015-03-052-1/+3
| | | | Also fix a typo in the manpage.
* player, client API: refactor cplayer init, reduce client API differenceswm42015-03-051-0/+4
| | | | | | | | | | | | | Move the command line parsing and some other things to the common init routine shared between command line player and client API. This means they're using almost exactly the same code now. The main intended side effect is that the client API will load mpv.conf; though still only if config loading is enabled. (The cplayer still avoids creating an extra thread, passes a command line, and prints an exit status to the terminal. It also has some different defaults.)
* input: use flag option type for some input commandswm42015-03-041-16/+15
| | | | | | | | | | This gets rid of the need for a second (or more) parameters; instead it can be all in one parameter. The (now) redundant parameter is still parsed for compatibility, though. The way the flags make each other conflict is a bit tricky: they have overlapping bits, and the option parser disallows setting already set bits.
* 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
* stream_cdda: add option to enable cdtext, and disable it by defaultwm42015-03-031-0/+4
| | | | Fixes #1615.
* manpage: improve --osd-fractions descriptionwm42015-03-031-1/+2
|
* manpage: remove empty line to fix formattingwm42015-03-021-1/+0
| | | | | | The HTML rendering of this page formats the ``timeout`` section differently, and we suspect it's because of this. (Or in other words: wtf rst??)
* Revert "Revert recent vo_opengl related commits"Niklas Haas2015-02-281-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | Omitted a simple, but devastasting check. Fixed the relevant commits now. This reverts commit 8d24e9d9b8ad1b5d82139980eca148dc0f4a1eab. diff --git a/video/out/gl_video.c b/video/out/gl_video.c index 9c8a643..f1ea03e 100644 --- a/video/out/gl_video.c +++ b/video/out/gl_video.c @@ -1034,9 +1034,9 @@ static void compile_shaders(struct gl_video *p) shader_def_opt(&header_conv, "USE_CONV_GAMMA", use_conv_gamma); shader_def_opt(&header_conv, "USE_CONST_LUMA", use_const_luma); shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_BT1886", - gamma_fun == MP_CSP_TRC_BT_1886); + use_linear_light && gamma_fun == MP_CSP_TRC_BT_1886); shader_def_opt(&header_conv, "USE_LINEAR_LIGHT_SRGB", - gamma_fun == MP_CSP_TRC_SRGB); + use_linear_light && gamma_fun == MP_CSP_TRC_SRGB); shader_def_opt(&header_conv, "USE_SIGMOID", use_sigmoid); if (p->opts.alpha_mode > 0 && p->has_alpha && p->plane_count > 3) shader_def(&header_conv, "USE_ALPHA_PLANE", "3");
* Revert recent vo_opengl related commitswm42015-02-281-7/+0
| | | | | | | | | | | | | | | Breaks vo_opengl by default. I'm hot able to fix this myself, because I have no clue about the overcomplicated color management logic. Also, whilethis is apparently caused by commit fbacd5, the following commits all depend on it, so revert them too. This reverts the following commits: e141caa97dade07f4d7e0d6c208bcd3493e712ed 653b0dd5295453d9661f673b4ebd02c5ceacf645 729c8b3f641e633474be612e66388c131a1b5c92 fbacd5de31de964f7cd562304ab1c9b4a0d76015 Fixes #1636.
* cocoa: remove the setNextKeyView hackStefano Pigozzi2015-02-281-2/+14
| | | | | | Just use makeFirstResponder on the mpv events view from client code if you need the built in keyboard events (this is easier for dealing with view nesting).
* examples/cocoabasic: allow to send stop commandStefano Pigozzi2015-02-281-13/+19
|
* manpage: fix typozymos2015-02-281-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* screenshots: add support for csp taggingNiklas Haas2015-02-281-0/+7
| | | | | | This relies on upstream support in lavc, and will hence basically not work at all. The intent is to get support for writing this information into ffmpeg's PNG encoders etc.
* demux: bump default demuxer queue sizeswm42015-02-271-2/+2
| | | | | | | | | | Now that we have fast stream switching, we can bump these sizes, as the queues cause no delay in switching anymore. Of course, the fast stream switching works for mkv and mp4 only. Other formats will incur a quite terrible delay especially in network mode, which this commit changes to 10 seconds. Let's see if someone complains...
* manpage: update wording on speedNiklas Haas2015-02-271-2/+3
| | | | | | The way I interpreted it, it seemed like this was not default behavior and could be enabled with --audio-pitch-correction - it should be made clearer that this is actually *the default behavior*.
* 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.
* input: allow passing FDs to --input-filewm42015-02-261-0/+3
|
* ytdl: add "--ytdl-params" optionThiago Kenji Okada2015-02-251-0/+12
| | | | | | | | | | | This option allows the user to pass non-supported options directly to youtube-dl, such as "--proxy URL", "--username USERNAME" and '--password PASSWORD". There is no sanity checking so it's possible to break things (i.e. if you pass "--version" mpv exits with random JSON error). Signed-off-by: wm4 <wm4@nowhere>
* manpage: adjust --ass-style-override descriptionwm42015-02-251-2/+1
| | | | | No "modified libass" is needed anymore. Also, it said that the "force" choice is more reliable than "force", which makes no sense.
* 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.
* DOCS/client_api_examples/simple: fix optionwm42015-02-231-1/+1
| | | | | "input-x11-keyboard" still works, but is a deprecated alias with the same functionality.
* manpage: ipc: add a socat examplewm42015-02-211-3/+33
| | | | Requested, and should be quite good at giving an overview how it works.
* video: un-discourage "vaapi-copy" hwdec mode