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
mpv crashed when linked files were not found. The reason was that the
chapters array contained some uninitialized data.
I have no idea how this code works (after the merge). The old code
actually seems to remove missing chapters, while the new code just
leaves them unintiialized. Work around the crash by initializing the
chapters array (and a bunch of other things) with 0, which means the
missing chapter will be located at 00:00:00 and have no name.
There is a regression since commit af0306d.
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.
This one really did bite me hard (see previous commit), so enable it by
default.
Fix some cases of shadowing throughout the codebase. None of these
change behavior, and all of these were correct code, and just tripped up
the warning.
E.g. "-vf scale=848:480" set the w argument twice, instead of setting w
and then h.
This was caused by accidental shadowing of a local variable.
Regression since probably 4cd143e.
Just doing this because mp_osd.h and osd.c is not consistent.
There are some other header files (command.h and screenshot.h), but
since I don't feel too good about inflating mp_core.h, I'm not merging
them, at least not yet.
I considered making a header file for each .c file, but decided against
it. Asking around, not making separate headers was deemed acceptable. In
the end, all of these depend on MPContext and store state inside of it,
so separate headers aren't all that useful anyway.
mplayer.c was a bit too big. Split it into multiple files. I hope the
way it's split makes sense. Maybe some things don't make too much sense,
or go against intuition. These will fixed as soon as I notice them.
Some files are a bit questionable (misc.c, osd.c, configfiles.c), and
suggestions how to organize this better are welcome.
Regressions are possible due to reorganized include statements.
Obviously I didn't just copy mplayer.c's orgy of include statements, but
recreated them for each file. It's easily possible that there are
oversights and mistakes, which will show up on other platforms.
There is one actual change: the public avutil.h include is removed from
encode.h, and I tried to replace most FFMIN/FFMAX/av_clip uses. I
consider using libavutil too much as dangerous, because the set of
include files they recursively pull in is rather arbitrary and is
different between FFmpeg and Libav.
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.
This might actually fix an issue with DVB channel switching, because
that uses some sort of hack to reinitialize the demuxer, which causes
the subtitle renderer to initialize twice. As consequence, the assert in
add_subtitle_fonts_from_sources() would trigger.
I didn't actually test the DVB case, because I don't have the hardware.
Disable autorepeat for the "add"/"cycle" commands when changing
properties that are choices (such as fullscreen, pause, and more).
In these cases, autorepeat is not very useful, and can rather harmful
effects (like triggering too many repeated commands if command
execution is slow).
(Actually, the commands are just dropped _after_ being repeated, since
input.c itself does not know enough about the commands to decide whether
or not they should be repeated.)
Defining names like min, max etc. in an often used header is not really
a good idea.
Somewhat similar to MPlayer svn commit 36491, but don't use libavutil,
because that typically causes us sorrow.
Not up to my quality standards (need ASS boundingboxes), so disabled by default and undocumented for now.
Can be enabled with seektooltip=yes in plugin_osc.conf
There are certain cases where mpv will automatically set options, such
as per-file configs, per protocol/VO/AO/extension profiles, and
watch_later resume configs. All these were overwriting the user's
options, even when they were specified on command line.
Add something that explicitly preserves command line options. This
means you can now actually use the command line to override any
options that the playback resume functionality backups and restores.
It still happily overrides options set at runtime (e.g. changed via
properties while playing a file; then playing the next file might
override them again), but maybe that's not a problem with typical use.
In cases we're just listing options or checking their values (as it
happens with -vo/-vf etc. suboption parsing), we don't need to allocate
abd initialize the actual option struct. All we're interested in is
the list of options.
Keep track of the default values directly, instead of creating a new
instance of the option struct just to get the defaults.
Also get rid of the special handling of m_obj_desc.init_options.
Instead, handle it purely by the option parser. Originally, I wanted to
handle --vo=opengl-hq and --vo=direct3d_shaders with this (by making
them aliases to the real VOs with a different preset), but since --vo
=opengl-hq=help prints the wrong values (as consequence of the
simplification), I'm not doing that, and instead use something
different.
Might reduce memory overhead, and is also less annoying.
Since pointers to m_config_options are kept around, this assumes
they're added only during initialization. Otherwise you'd get
dangling pointers.
Minor simplification. String options are now not allowed to use the
same variable/field anymore. (Also affects other "dynamic" options
which require memory allocation.)
af_format is the old audio conversion filter. It could do all possible
conversions supported by the audio chain. However, ever since the
addition of af_lavrresample, most conversions are done by
libav/swresample, and af_format is used as fallback.
Separate out the fallback cases and remove af_format. af_convert24 does
24 bit <-> 32 bit conversions, while af_convertsignendian does sign and
endian conversions. Maybe the way the conversions are split sounds a bit
odd. But the former changes the size of the audio data, while the latter
is fully in-place, so there's at least different buffer management.
This requires a quite complicated algorithm to make sure all these
"partial" conversion filters can actually get from one format to
another. E.g. s24le->s32be always requires convertsignendian and
convert24, but af.c has no idea what the intermediate format should
be. So I added a graph search (trying every possible format and
filter) to determine required format and filter. When I wrote this,
it seemed this was still better than messing everything into
af_lavrresample, but maybe this is overkill and I'll change my
opinion. For now, it seems nice to get rid of af_format though.
The AC3->IEC61937 conversion isn't supported anymore, but I don't think
this is needed anywhere. Most AOs test all formats explicitly, or use
the AF_FORMAT_IS_IEC61937() macro (which includes AC3).
One positive consequence of this change is that conversions always
include dithering (done by libav/swresample), instead of possibly going
through af_format, which doesn't do anything fancy.
Rename af_force to af_format. It's essentially compatible with command
line uses of af_format. We retain a compatibility alias for af_force.
This is obviously not needed, and just creates potential for bad
breakages (e.g. what happens if libquvi tries to open a normal filename
as http URL?).
Note that for simplicity, we still pass file:// URIs to quvi, and we
don't exclude other protocol prefixes either. In general, we don't know
what protocols quvi might support, so we don't try to second-guess it.
(Even though in practice, it's probably only "http" and "https".)
If cache was enabled, using ordered chapters could easily crash. The
reason is that enable_cache() reopens the demuxer and closes the old
one. The code after that (reading m->ordered_chapters etc.) then
accessed freed data.
This commit also avoids enabling cache for files which are not used
(which would make opening much slower).
Implement MP_GROW_ARRAY using MP_TARRAY_GROW. MP_GROW_ARRAY is basically
the earlier version of MP_TARRAY_GROW, and had different semantics. When
I added MP_TARRAY_GROW, I didn't dare to change it, but I think all code
that relied on the exact semantics of MP_GROW_ARRAY is gone now, or the
difference doesn't matter anyway. The semantic change is that now
(n+1)*2 elements are preallocated instead of n*2.
Also, implement MP_TARRAY_GROW using MP_RESIZE_ARRAY, which saves 1 line
of code.
In future, these macros should be part of TA.
Was disabled by default, was never used, internal support was
inconsistent and poor, and there has been virtually no interest in
creating translations.
And I don't even think that a terminal program should be translated.
This is something for (hypothetical) GUIs.
This adds support for ChapterSegmentEditionUID (pull request #258),
and also fixes issue #278 (pull request #292).
In fact, this is a straight merge of pr/292, which also contains pr/258.
