summaryrefslogtreecommitdiffstats
path: root/mpvcore/options.c
Commit message (Collapse)AuthorAgeFilesLines
* Move options/config related files from mpvcore/ to options/wm42013-12-171-886/+0
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* Rename mp_core.h to core.hwm42013-12-171-1/+1
| | | | Get rid of the mp_ prefix.
* input: remove LIRCCD supportwm42013-12-161-1/+0
| | | | | | | This removes support for the "LIRC Client Daemon", which is separate from LIRC, and hasn't been maintained for 10 years. See github issue #413.
* matroska: add --ordered-chapters-files optionwm42013-12-141-0/+1
| | | | | This option takes a playlist. The playlist will then be used as list of potential segment files for use with ordered chapters.
* Add prelimimary (basic, possibly broken) dvdnav supportwm42013-12-121-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This readds a more or less completely new dvdnav implementation, though it's based on the code from before commit 41fbcee. Note that this is rather basic, and might be broken or not quite usable in many cases. Most importantly, navigation highlights are not correctly implemented. This would require changes in the FFmpeg dvdsub decoder (to apply a different internal CLUT), so supporting it is not really possible right now. And in fact, I don't think I ever want to support it, because it's a very small gain for a lot of work. Instead, mpv will display fake highlights, which are an approximate bounding box around the real highlights. Some things like mouse input or switching audio/subtitles stream using the dvdnav VM are not supported. Might be quite fragile on transitions: if dvdnav initiates a transition, and doesn't give us enough mpeg data to initialize video playback, the player will just quit. This is added only because some users seem to want it. I don't intend to make mpv a good DVD player, so the very basic minimum will have to do. How about you just convert your DVD to proper video files?
* osd: add option for "unscaled" OSDwm42013-12-101-0/+2
|
* video: remove --flipwm42013-12-051-2/+0
| | | | | | | | | | | | | | | | The --flip option flipped the image upside-down, by trying to use VO support, or if not available, by inserting a video filter. I'm not sure why it existed. Maybe it was important in ancient times when VfW based decoders output an image this way (but even then, flipping an image is a free operation by negating the stride). One nice thing about this is that it provided a possible path for implementing video orientation, which is a feature we should probably support eventually. The important part is that it would be for free for VOs that support it, and would work even with hardware decoding. But for now get rid of it. It's useless, trivial, stands in the way, and supporting video orientation would require solving other problems first.
* video: allow hardware decoding only for certain codecswm42013-12-051-1/+1
| | | | | | | | | | In particular, this disables mpeg4. There are some files out there that use GMC, a usually rarely used and ineffective feature, which is not supported by most hardware decoders. In these cases the hw decoder outputs garbage, while software decoding works perfectly fine. We can't really fallback to software decoding in these cases, because we don't know that something is wrong in the first place. I can't see any advantages of hw decoding of mpeg4, so it's better to disable it.
* ad_lavc: expose an option to enable threadingwm42013-12-041-0/+1
|
* options: add option to disable using right Alt key as Alt GrVivek Jain2013-12-021-0/+1
| | | | | | | | | mpv was hardcoded to always consider the right Alt key as Alt Gr, but there are parituclar combinations of platforms and keyboard layouts where it's more convenient to treat the right Alt as a keyboard modifier just like the left one. Fixes #388
* options: add options that set defaults for af/vf/ao/vowm42013-12-011-0/+4
| | | | | | | | There are some use cases for this. For example, you can use it to set defaults of automatically inserted filters (like af_lavrresample). It's also useful if you have a non-trivial VO configuration, and want to use --vo to quickly change between the drivers without repeating the whole configuration in the --vo argument.
* build: make pthreads mandatorywm42013-11-281-2/+1
| | | | | | | | | | | pthreads should be available anywhere. Even if not, for environment without threads a pthread wrapper could be provided that can't actually start threads, thus disabling features that require threads. Make pthreads mandatory in order to simplify build dependencies and to reduce ifdeffery. (Admittedly, there wasn't much complexity, but maybe we will use pthreads more in the future, and then it'd become a real bother.)
* video: disable PTS sorting fallback by defaultwm42013-11-251-0/+1
| | | | | | | | | | | | | | | | It appears PTS sorting was useful only for avi files (and VfW-muxed mkv). Maybe it was historically also important for decoders with broken or non-existent PTS reordering (win32 codecs?). But now that we handle demuxers which outputs DTS only correctly, it just seems dead weight. Disable it by default. The --pts-association-mode option is now forced to always use the decoder's PTS value. You can still enable the old default (auto) or force sorting. But we will probably remove this option entirely at some point. Make demux_mkv export timestamps at DTS when it's in VfW mode. This is needed to get correct timestamps with the new default mode. demux_lavf already does that.
* Rename sub.c/.h to osd.c/.hwm42013-11-241-1/+1
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* options: implement --pphelp differentlywm42013-11-231-5/+0
| | | | Make it work via --vf=pp:help instead.
* video: remove vf_pp auto-insertionwm42013-11-231-2/+0
| | | | | | | | | | This drops the --pp option, which was probably broken for a while. The option automatically inserted the "pp" filter. The value passed to it was ignored (which is probably broken, it always selected maximal quality). Inserting this filter can be done simply with --vf=pp, so this is not needed anymore.
* player: add --merge-files optionwm42013-11-191-0/+1
|
* sd_lavc, sd_spu: make dvdsub stretching conditional on --stretch-dvd-subs.Rudolf Polzer2013-11-071-0/+1
| | | | | | | | | | | | We found that the stretching - although it usually improves the looks of the fonts - is incorrect. On DVD, subtitles can cover the full area of the picture, and they have the same pixel aspect as the movie itself. Too bad many commercially released DVDs use bitmap fonts made with the wrong pixel aspect (i.e. assuming 1:1) - --stretch-dvd-subs will make these more pretty then.
* vd_lavc: remove explicit crystalhd supportwm42013-11-061-1/+0
| | | | | | | | | | | | | | | | This removes "--hwdec=crystalhd". I doubt anyone even tried to use this. But even if someone wants to use it, the decoders can still be explicitly invoked with e.g.: --vd=lavc:h264_crystalhd The only advantage our special code provided was fallback to software decoding. (But I'm not sure how the ffmpeg crystalhd pseudo-decoder actually behaves.) Removing this will allow some simplifications as soon as we don't need vdpau_old.c anymore.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-38/+38
| | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* video: check profiles with hardware decodingwm42013-11-011-0/+3
| | | | | | | | | | | | | | | We had some code for checking profiles earlier, which was removed in commits 2508f38 and adfb71b. These commits mentioned that (working) hw decoding was sometimes prevented due to profile checking, but I can't find the samples anymore that showed this behavior. Also, I changed my opinion, and I think checking the profiles is something that should be done for better fallback to software decoding behavior. The checks roughly follow VLC's vdpau profile checks, although we do not check codec levels. (VLC's profile checks aren't necessarily completely correct, but they're a welcome help anyway.) Add a --vd-lavc-check-hw-profile option, which skips the profile check.
* Move files part of the playback core to player sub-directorywm42013-10-301-1/+1
| | | | | | | | All these files access mp_core.h and MPContext, and form the actual player application. They should be all in one place, and separate from the other sources that are mere utility helpers. Preparation for splitting mplayer.c into multiple smaller parts.
* options: fix bogus entrywm42013-10-241-1/+1
| | | | | This didn't make sense and caused issues with the following commit: if it's an option with a data pointer, it should be writable.
* options: enable OSC by defaultwm42013-10-141-0/+1
| | | | Can can disable it with --osc=no.
* options: --loop=N means playback N times, not N+1 timesPhilip Sequeira2013-10-121-2/+2
| | | | | | | | | | The argument or this change is that --loop should set how often the file is played, not the number of additional repeats. Based on pull request 277, with additions to the manpage and removal of "--loop=0". Signed-off-by: wm4 <wm4@nowhere>
* core: add --force-windowwm42013-10-021-0/+1
| | | | | | | | | | | | | | | | | This commit adds the --force-window option, which will cause mpv always to create a window when started. This can be useful when pretending that mpv is a GUI application (which it isn't, but users pretend anyway), and playing audio files would run mpv in the background without giving a window to control it. This doesn't actually create the window immediately: it only does so only after initializing playback and when it is clear that there won't be any actual video. This could be a problem when starting slow or completely stuck network streams (mpv would remain frozen in the background), or if video initialization somehow is stuck forever in an in-between state (like when the decoder doesn't output a video frame, but doesn't return an error either). Well, we can pretend only so much that mpv is a GUI application.
* network: add options to control TLS verificationwm42013-09-271-0/+4
|
* video: let sh_video->aspect always be container aspect ratiowm42013-09-261-2/+4
| | | | | | | Now writing -1 to the 'aspect' property resets the video to the auto aspect ratio. Returning the aspect from the property becomes a bit more complicated, because we still try to return the container aspect ratio if no frame has been decoded yet.
* Add the on-screen-controllerChrisK22013-09-261-0/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* Add initial Lua scripting supportwm42013-09-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | This is preliminary. There are still tons of issues, and any aspect of scripting may change in the future. I decided to merge this (preliminary) work now because it makes it easier to develop it, not because it's done. lua.rst is clear enough about it (plus some sarcasm). This requires linking to Lua. Lua has no official pkg-config file, but there are distribution specific .pc files, all with different names. Adding a non-pkg-config based configure test was considered, but we'd rather not. One major complication is that libquvi links against Lua too, and if the Lua version is different from mpv's, you will get a crash as soon as libquvi uses Lua. (libquvi by design always runs when a file is opened.) I would consider this the problem of distros and whoever builds mpv, but to make things easier for users, we add a terrible runtime test to the configure script, which probes whether libquvi will crash. This is disabled when cross-compiling, but in that case we hope the user knows what he is doing.
* options: allow selecting the libass shaperwm42013-09-251-0/+3
| | | | | | I'm using the word "languages" instead of "scripts" in the manpage, but I think that's easier to understand with a smaller amount of descriptions.
* options: make --ass-hinting a choice, instead of using magic numberswm42013-09-251-1/+2
| | | | | options.c still doesn't use the constants defined by the libass headers, but it's still better than exposing those to the user directly.
* vaapi: allow GPU read-back with --hwdec=vaapi-copywm42013-09-251-1/+2
| | | | | | | | | | | | | | This code is actually quite inefficient: it reuses the (slow, simple) screenshot code. It uses an inefficient method to read the image (vaGetImage() instead of vaDeriveImage()), allocates new memory for each frame that is read, and it tries all image formats again each time. Also, in my tests it always picked NV12 as image format, which is not ideal if you actually want to filter the video, and vo_xv can't handle this format without conversion either. However, a user confirmed that it worked for him, so everything is fine.
* mplayer: attempt to make playback resume work with DVD/BDwm42013-09-221-4/+0
| | | | | | | | | | | | | | | | The problem with DVD/BD and playback resume is that most often, the filename is just "dvd://", while the actual path to the DVD disk image is given with --dvd-device. But playback resume works on the filename only. Add a pretty bad hack that includes the path to the disk image if the filename starts with dvd://, and the same for BD respectively. (It's a bad hack, but I want to go to bed, so here we go. I might revert or improve it later, depending on user feedback.) We have to cleanup the global variable mess around the dvd_device. Ideally, this should go into MPOpts, but it isn't yet. Make the code paths in mplayer.c take MPOpts anyway.
* network: fix rtsp playbackwm42013-09-221-0/+6
| | | | | | | | | | | | | | By default, libavformat uses UDP for rtsp playback. This doesn't work very well. Apparently the reason is that the buffer sizes libavformat chooses for UDP are way too small, and switching to TCP gets rid of this issue entirely (thanks go to Reimar Döffinger for figuring this out). In theory, you can set buffer sizes as libavformat options, but that doesn't seem to help. Add an option to select the rtsp transport, and make TCP the default. Also remove an outdated comment from stream.c.
* mixer: restore volume with playback resumewm42013-09-201-0/+1
| | | | | | | | | Note that this is intentionally never done if the AO or softvolume is different, or if the current volume control method is thought to control system wide volume (such as ALSA) or otherwise user controllable (such as PulseAudio). The intention is to keep things robust and to avoid messing with the user's audio settings as far as possible, while still providing the ability to resume volume if it makes sense.
* core: add --deinterlace option, restore it with resume functionalitywm42013-09-131-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The --deinterlace option does on playback start what the "deinterlace" property normally does at runtime. You could do this before by using the --vf option or by messing with the vo_vdpau default options, but this new option is supposed to be a "foolproof" way. The main motivation for adding this is so that the deinterlace property can be restored when using the video resume functionality (quit_watch_later command). Implementation-wise, this is a bit messy. The video chain is rebuilt in mpcodecs_reconfig_vo(), where we don't have access to MPContext, so the usual mechanism for enabling deinterlacing can't be used. Further, mpcodecs_reconfig_vo() is called by the video decoder, which doesn't have access to MPContext either. Moving this call to mplayer.c isn't currently possible either (see below). So we just do this before frames are filtered, which potentially means setting the deinterlacing every frame. Fortunately, setting deinterlacing is stable and idempotent, so this is hopefully not a problem. We also add a counter that is incremented on each reconfig to reduce the amount of additional work per frame to nearly zero. The reason we can't move mpcodecs_reconfig_vo() to mplayer.c is because of hardware decoding: we need to check whether the video chain works before we decide that we can use hardware decoding. Changing it so that this can be decided in advance without building a filter chain sounds like a good idea and should be done, but we aren't there yet.
* mplayer: add --cursor-autohide-fs-only optionwm42013-09-081-0/+1
| | | | | | | | This option makes the cursor always visible in windowed mode. Apparently, this is what (some?) Windows and OSX users expect. It's disabled by default for now. Restructure the cursor hide logic a bit for this purpose.
* options: remove --(no-)mouseinput optionwm42013-09-081-2/+0
| | | | I have no idea why it exists, as it's redundant to --(no-)mouse-movements.
* options: cosmetics: move cursor_autohide_delay definitionwm42013-09-081-2/+2
| | | | No functional changes.
* options: fix --volume option range, add some explanations to manpagewm42013-09-071-1/+1
| | | | | | | | The --volume option accepted values up to 10000, but internally, the value is always clipped to 0-100 range. What makes this even worse is that --softvol-max suggests that it extends the range of --volume, which is not the case. (And passing a volume larger than 100 to --volume didn't even print a warning.)
* video: add unscaled mode with --video-unscaledwm42013-09-011-0/+1
|
* core: add a playlist demuxerwm42013-08-261-0/+2
| | | | | | | | | Modeled after the old playlist_parser.c, but actually new code, and it works a bit differently. Demuxers (and sometimes streams) are the component that should be used to open files and to determine the file format. This was already done for subtitles, but playlists still use a separate code path.
* audio: make internal audio format 0 an invalid formatwm42013-08-261-1/+1
| | | | | | | | | | | | Having to use -1 for that is generally quite annoying. Audio formats are created from bitmasks, and it can't be excluded that 0 is not a valid format. Fix this by adjusting AF_FORMAT_I so that it is never 0. Along with AF_FORMAT_F and the special formats, all valid formats are covered and guaranteed to be non-0. It's possible that this commit will cause some regressions, as the check for invalid audio formats changes a bit.
* options: replace --edition=-1 with --edition=autowm42013-08-211-1/+2
| | | | | | Originally, the objective of this commit was changing --edition to be 1-based, but this was cancelled. I'm still leaving the change to demux_mkv.c though, which is now only of cosmetic nature.
* video: make it possible to scale/pan the video by arbitrary amountswm42013-08-191-0/+5
| | | | | | | | | | | Add --video-align-x/y, --video-pan-x/y, --video-scale options and properties. See the additions to the manpage for description and semantics. These transformations are intentionally done on top of panscan. Unlike the (now removed) --panscanrange option, this doesn't affect the default panscan behavior. (Although panscan itself becomes kind of useless if the new options are used.)
* options: remove --panscanrange optionwm42013-08-191-2/+0
| | | | | | This option allowed you to extend the range of the panscan controls, so that you could essentially use it to scale the video. This will be replaced by a separate option to set the zoom factor directly.
* mplayer: reshuffle on every loop if --loop and --shuffle are usedwm42013-08-191-1/+2
| | | | | | | | | | See github issue #194. Unfortunately, this breaks the property that going back in the playlist always works as expected. This changes, because the playlist_prev command will work on the reshuffled playlist, instead of loading the previously played files in order. If this ever becomes an issue, I might revert this commit.
* command: more intuitive chapter seek behaviorPhilip Sequeira2013-08-171-0/+3
| | | | | | | | | If close to chapter start, skipping back goes to previous chapter (no change). If more than <threshold> seconds in, skipping back will now go to the beginning of the current chapter instead. The threshold is set by the new option --chapter-seek-threshold and defaults to 5 seconds. A negative value disables the new functionality.
* sub: make --subcp=enca the default.wm42013-08-151-0/+5
|
* mpvcore/options: Update default user agent stringMartin Herkt2013-08-131-1/+2
| | | | Uh… about time, I guess?
* video: add vaapi decode and output supportwm42013-08-121-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is based on the MPlayer VA API patches. To be exact it's based on a very stripped down version of commit f1ad459a263f8537f6c from git://gitorious.org/vaapi/mplayer.git. This doesn't contain useless things like benchmarking hacks and the demo code for GLX interop. Also, unlike in the original patch, decoding and video output are split into separate source files (the separation between decoding and display also makes pixel format hacks unnecessary). On the other hand, some features not present in the original patch were added, like screenshot support. VA API is rather bad for actual video output. Dealing with older libva versions or the completely broken vdpau backend doesn't help. OSD is low quality and should be rather slow. In some cases, only either OSD or subtitles can be shown at the same time (because OSD is drawn first, OSD is prefered). Also, libva can't decide whether it accepts straight or premultiplied alpha for OSD sub-pictures: the vdpau backend seems to assume premultiplied, while a native vaapi driver uses straight. So I picked straight alpha. It doesn't matter much, because the blending code for straight alpha I added to img_convert.c is probably buggy, and ASS subtitles might be blended incorrectly. Really good video output with VA API would probably use OpenGL and the GL interop features, but at this point you might just use vo_opengl. (Patches for making HW decoding with vo_opengl have a chance of being accepted.) Despite these issues, decoding seems to work ok. I still got tearing on the Intel system I tested (Intel(R) Core(TM) i3-2350M). It was also tested with the vdpau vaapi wrapper on a nvidia system; however this was rather broken. (Fortunately, there is no reason to use mpv's VAAPI support over native VDPAU.)
* video: redo hw decoding initialization, add --hwdec=autowm42013-08-111-0/+1
| | | | | | | |