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.)
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.
--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.
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()).
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.
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.
Only some choices have an additional integer range. For those which
do, printing the choices only would be confusing.
E.g. --cursor-autohide accepts the choices "always", "no", or an
integer value. The help text printed on option parse errors should
print the accepted integer range additional to "always" and "no".
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.
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.)
The option type m_option_type_rel_time was completely broken. It
interpreted everything starting with a number as percent position. This
is because sscanf() semantics are idiotic (trailing string doesn't need
to be matched), and due to my own idiocy this was overlooked when
testing. Fix by considering sscanf() evil and not using it.
(bstr_sscanf() is a straight wrapper around sscanf()).
Even if the percent code was fixed, there was another bug: it always
interpreted times as negative (starting from end for --start). Fix the
basic logic.
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.
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.)
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.
