summaryrefslogtreecommitdiffstats
path: root/core/m_option.h
Commit message (Collapse)AuthorAgeFilesLines
* cleanup: replace OPT_FLAG_ON and OPT_MAKE_FLAGS with OPT_FLAGwm42013-02-091-3/+1
| | | | | | | | | | OPT_MAKE_FLAGS() used to emit two options (one with "no" prefixed), but that has been long removed by special casing flag options in the option parser. OPT_FLAG_ON() used to imply that there's no "no-" prefixed option, but this hasn't been the case for a while either. (Conceptually, it has been replaced by OPT_FLAG_STORE().) Remove OPT_FLAG_OFF, which was unused.
* options: unify single dash and double dash optionswm42013-02-091-7/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There were two option syntax variations: "old": -opt value "new": --opt=value "-opt=value" was invalid, and "--opt value" meant "--opt=" followed by a separate option "value" (i.e. interpreted as filename). There isn't really any reason to do this. The "old" syntax used to be ambiguous (you had to call the option parser to know whether the following argument is an option value or a new option), but that has been removed. Further, using "=" in the option string is always unambiguous. Since the distinction between the two option variants is confusing, just remove the difference and allow "--opt value" and "-opt=value". To make this easier, do some other cleanups as well (e.g. avoid having to do a manual lookup of the option just to check for M_OPT_PRE_PARSE, which somehow ended up with finally getting rid of the m_config.mode member). Error reporting is still a mess, and we opt for reporting too many rather than too few errors to the user. There shouldn't be many user-visible changes. The --framedrop and --term-osd options now always require parameters. The --mute option is intentionally made ambiguous: it works like a flag option, but a value can be passed to it explicitly ("--mute=auto"). If the interpretation of the option is ambiguous (like "--mute auto"), the second string is interpreted as separate option or filename. (Normal flag options are actually ambiguous in this way too.)
* options: change handling of "no-" optionswm42013-02-091-0/+4
| | | | | | | | | | | | | | | | Normally, all flag options can be negated by prepending a "no-", for example "--no-opt" becomes "--opt=no". Some flag options can't actually be negated, so add a CONF_TYPE_STORE option type to disallow the "no-" fallback. Do the same for choice options. Remove the explicit "no-" prefixed options, add "no" as choice. Move the handling of automatic "no-" options from parser-mpcmd.c to m_config.c, and use it in m_config_set_option/m_config_parse_option. This makes these options available in the config file. It also simplifies sub-option parsing, because it doesn't need to handle "no-" anymore.
* video: add --autofit and --autofit-larger optionswm42013-01-231-0/+3
| | | | | | | | | --autofit=WxH sets the window size to a maximum width and/or height, without changing the window's aspect ratio. --autofit-larger=WxH does the same, but only if the video size is actually larger than the window size that would result when using the --autofit=WxH option with the same arguments.
* options: allow using % for width and height in --geometrywm42013-01-231-0/+1
| | | | | | | | | | | | | | | | | | | | Now all numbers in the --geometry specification can take percentages. Rewrite the parsing of --geometry, because adjusting the sscanf() mess would require adding all the combinations of using and not using %. As a side effect, using % and pixel values can be freely mixed. Keep the aspect if only one of width or height is set. This is more useful in general. Note: there is one semantic change: --geometry=num used to mean setting the window X position, but now it means setting the window width. Apparently this was a mplayer-specific feature (not part of standard X geometry specifications), and it doesn't look like an overly useful feature, so we are fine with breaking it. In general, the new parsing should still adhere to standard X geometry specification (as used by XParseGeometry()).
* options: move -geometry parsing to m_option.cwm42013-01-231-0/+12
| | | | | | | | | This also means the option is verified on program start, not when the VO is created. The actual code becomes a bit more complex, because the screen width/height is not available at program start. The actual parsing code is still the same, with its unusual sscanf() usage.
* video: decouple internal pixel formats from FourCCswm42013-01-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* m_option: add color option typewm42012-11-201-0/+7
| | | | | | | | | | | This accepts HTML-style hex colors in the form #RRGGBB. It's also possible to provide an alpha component with #AARRGGBB. Each 2-digit group is a hex number, which gives the color value from 0-255 (e.g. There is existing code in subassconvert.c, which parses HTML-style color values in SRT subs. This is not used: it's probably better if option parsing is completely separate from code specific to certain subtitle formats, even if a little code is duplicated.
* options: support chapters for --start and --endwm42012-11-201-0/+1
| | | | | | | | | | | | | The --start and --end switch now accept a chapter number. The chapter number is prefixed with '#', e.g. "--start=#2" jumps to chapter 2. The chapter support might be able to replace --chapter completely, but for now I am not sure how well this works out with e.g. DVDs and BDs, and a separate --chapter option is useful interface-wise. (This was supposed to be added in 51503a, but apparently the fixup commit adding it was lost in a rebase. This might also be the reason for the mess-up fixed in 394285.)
* options: rename -ss and -endpos, allow relative timeswm42012-11-161-9/+13
| | | | | | | | | | | | | | | | Rename the -ss option to -start, and -endpos to -length. Add a -end option. The -end option always specifies an absolute end time, as opposed to -endpos/-length. All these options (--start, --end, --length) now accept relative times. Percent positions (e.g. "--start=30%") are interpreted as fractions of the file duration. Negative times (e.g. "--start=-1:00) are interpreted relative to the end of the file. Chapters (e.g. "--start=#3") yield the chapter's time position. The chapter support might be able to replace --chapter completely, but for now I am not sure how well this works out with e.g. DVDs and BDs, and a separate --chapter option is useful interface-wise.
* options: rename --xineramascreen to --screen, remove magic valueswm42012-11-161-0/+1
| | | | | --xineramascreen=-2 becomes --screen=all --xineramascreen=-1 becomes --screen=current
* Rename directories, move files (step 2 of 2)wm42012-11-121-1/+1
| | | | | | | | | | | | Finish renaming directories and moving files. Adjust all include statements to make the previous commit compile. The two commits are separate, because git is bad at tracking renames and content changes at the same time. Also take this as an opportunity to remove the separation between "common" and "mplayer" sources in the Makefile. ("common" used to be shared between mplayer and mencoder.)
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-0/+519
Tis drops the silly lib prefixes, and attempts to organize the tree in a more logical way. Make the top-level directory less cluttered as well. Renames the following directories: libaf -> audio/filter libao2 -> audio/out libvo -> video/out libmpdemux -> demux Split libmpcodecs: vf* -> video/filter vd*, dec_video.* -> video/decode mp_image*, img_format*, ... -> video/ ad*, dec_audio.* -> audio/decode libaf/format.* is moved to audio/ - this is similar to how mp_image.* is located in video/. Move most top-level .c/.h files to core. (talloc.c/.h is left on top- level, because it's external.) Park some of the more annoying files in compat/. Some of these are relicts from the time mplayer used ffmpeg internals. sub/ is not split, because it's too much of a mess (subtitle code is mixed with OSD display and rendering). Maybe the organization of core is not ideal: it mixes playback core (like mplayer.c) and utility helpers (like bstr.c/h). Should the need arise, the playback core will be moved somewhere else, while core contains all helper and common code.