Commit Graph

11 Commits

Author SHA1 Message Date
wm4 7885fce7ea video: add --autofit and --autofit-larger options
--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.
2013-01-23 10:56:36 +01:00
wm4 ccaed5eb07 options: allow using % for width and height in --geometry
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()).
2013-01-23 10:56:27 +01:00
wm4 4c56baba40 options: move -geometry parsing to m_option.c
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.
2013-01-23 10:56:11 +01:00
wm4 8751a0e261 video: decouple internal pixel formats from FourCCs
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.
2013-01-13 20:04:11 +01:00
wm4 967e1e8290 m_option: print valid integer range for choices on parsing errors
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".
2012-11-20 18:00:15 +01:00
wm4 d23b620a89 m_option: add color option type
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.
2012-11-20 18:00:15 +01:00
wm4 f5e2ee5138 options: support chapters for --start and --end
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.)
2012-11-20 18:00:11 +01:00
wm4 39428525c3 m_option: fix braindead --start, --length, --end option parsing bugs
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.
2012-11-18 00:25:25 +01:00
wm4 51503a0577 options: rename -ss and -endpos, allow relative times
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.
2012-11-16 21:21:15 +01:00
wm4 4873b32c59 Rename directories, move files (step 2 of 2)
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.)
2012-11-12 20:08:18 +01:00
wm4 d4bdd0473d Rename directories, move files (step 1 of 2) (does not compile)
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.
2012-11-12 20:06:14 +01:00