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.
When adding or removing frames to avoid 1-frame seeks on chapter
boundaries, the end of the chapter needs to be pushed or pulled by the
same amount to keep the intended end frame the same.
Note that you still need --vd-lavc-o='strict=-2' to enable the decoder.
Also, there's no guarantee that all required features for HEVC demuxing
are actually implemented, nor that the current muxing schema is the
final one.
This could cause the OSC to be displayed without mouse interaction: for
example, starting mpv with --fs, and putting the mouse to where the OSC
area is beforehand, would cause the OSC to appear and stay visible. We
don't want that. The simplest solution is not generating artificial
mouse move events from mouse enter events, because they make the OSC
think the mouse was actually moved.
Also see commit 0c7978c, where handling of mouse enter events was added.
This was supposed to fix certain corner cases, but they're not relevant
anymore due to changes in OSC behavior.
Commit 9777047 fixed this as well (by resetting the mouse state on
MOUSE_LEAVE), but all the behavior reverted with this commit as perhaps
a bad idea. It wasn't very robust, made it hard to distinguish real
events from artificial ones, and finally made the mouse cursor more
often visible than needed. (Now switching between workspaces doesn't
make the cursor visible again when switching to a fullscreened mpv.)
Now you can pretend the config file is quite literally command line
values dumped into a file, e.g.
--option1=value
--option2=value
...
although the underlying mechanisms are quite different.
Until now it used both char[] and bstr variants in the same code, which
was nasty. For example, the next commit would have additionally required
using memmove() to remove the prefix from the char[] string.
This fixes handling of e.g. "--vf=lavfi=[ noise ]" when used with
playback resume functionality. The spaces made it bug out, and there are
more cases where it could potentially break.
We could always escape for simplicity, but for now make old and new mpv
builds somewhat interoperable and use this new escaping only if needed.
This parses "%len%string" escapes, where string can contain any
characters. This method of escaping has also been used in other parts
of mplayer and mpv, so it's not a new idea.
(Also, don't confuse with URL encoding.)
Needed by the following commit.
With the way I've been doing releases in the release/0.1 branch, this
proved completely useless. You need to write the VERSION file anyway,
and since we use github's automatically generated tarballs (via its
release system), the VERSION file needs to be in the git revision of
a release anyway. git master on the other hand displayed the v0.1.0
tag, because the tag is within the master branch.
This essentially reverts commit b27f65a. Now just print the contents
of the VERSION file if it exists, and likewise, we append the git
revision if it exists. (Do that even if VERSION exists, because this
way we can tell if someone is using the release branch at an in-between
point where no new release has been made yet.)
Also change what the FFmpeg version info looks like, and additionally
dump lavfi/lavr/lswr versions. (Don't bother with libavdevice and
libpostproc, they're not important enough.)
Unfortunately, there's no "single" FFmpeg/Libav version due to fatal
braindeath on the FFmpeg/Libav side. We can't map the versions to
releases either (it simply isn't accessible anywhere).
The mouse area that covers the OSC is now only activated when the OSC is actually visible, to make sure the mouse still hides if it happens to be parked in the OSC area without making the OSC show up.
vo_image didn't handle OSD redrawing correctly anymore after OSD
redrawing behavior was changed in commit ed9295c (or maybe it has been a
problem for a longer time, and only showed up now). Basically, flip_page
was called unexpectedly and when no image was stored, which made it
crash trying to access the image. This could happen when for example
provoking OSD redrawing by pausing while using --vo=image, or by using
this command line: mpv --vo=image '-vf=lavfi="select=not(mod(n\,3))"'
Fix by removing the code that pretends vo_image can redraw OSD, and by
removing the framestepping fallback, which could make bad things happen
if the VO didn't support OSD redrawing. By now, there aren't any real
VOs that can't redraw the OSD properly, so this code is not needed and
just complicates things like vo_image.
This change likely will also be useful for vo_lavc (encoding).
Libass is technically an optional dependency, but in practice users
tend to disable libass accidentally or for the hell of it to get
something "minimal", without being aware of the consequences.
The deadzone-size is now by default zero, so movement on the entire window will make the OSC show up. To avoid it showing up by randomly moving mice, the option 'minmousemove' controls how many pixels movement (default: 1) between ticks (frames) are necessary to make the OSC show up.
The deadzone can be reenabeled by setting the option 'deadzonesize' (default: 0 = no deadzone, 1 = entire area between OSC and opposite window border), to restore the old behavior, set it to ~0.92.
The OSC will hide immediately when leaving the window or entering the deadzone (if existing) or after the time specified with 'hidetimeout' (default: 500ms) passed without any new movement. Set to negative value to disabling auto-hide (thus restoring old behavior). The OSC will never hide if hovered by the mouse.
Now that talloc has been removed, the license can be switched back to
GPLv2+. Actually, there never was a GPLv2+ licensed MPlayer (fork or
not) until now, but removal of some GPLv2-only code makes this possible
now. Rewrite the Copyright file to explain the reasons for the licenses
MPlayer and forks use. The old Copyright file didn't contain anything
interesting anymore, and all information it contained is available at
other places in the source tree.
The reason for the license change itself is that it should improve
interoperability with differently licensed code in general.
This essentially reverts commit 1752808.
There are multiple reasons to do this. One big reason is the license:
talloc is LGPLv3+, which forces mpv to be licensed as GPLv3+.
Another one is that our talloc copy contains modifications, which makes
it essentially incompatible with upstream talloc (in particular, our
version aborts on out of memory conditions - well, it wasn't my idea).
Updating from upstream is also a bit involved - the talloc source is
not really organized in a way to allow copying it into projects (and
this isn't an intended use-case).
Finally, talloc is kind of big and bloated. The replacement halves the
amount of code - mainly because we didn't use all talloc features. It's
even more extreme if you compare upstream talloc (~4700 lines) and the
new allocator without talloc compat (~900 lines).
The replacement provides all features we need. It also doesn't clash
with talloc. (The talloc compatibility wrapper uses macros to avoid
introducing linker-level symbols which could clash with libtalloc.)
It also tries to lower the overhead (only 4 words opposed to 10 words
in talloc for leaf nodes in release mode). Debugging features like leak
reporting can be enabled at compile time and add somewhat more overhead.
Though I'm not sure whether the overhead reduction was actually
successful: allocations with children need an "extra" header, which adds
plenty of overhead, and it turns out that almost half of all allocations
have children. Maybe the implementation could be simplified and the
extra header removed - even then, overhead would be lower than talloc's.
Currently, debugging features can be entirely deactivated by defining
NDEBUG - I'm not sure if anything defines this directly yet, though.
Unlike in talloc, the leak reporting stuff is thread-safe. (That's also
why it's far less elegant, and requires extra list pointers.)
Comes with a compatibility layer, so no changes to mpv source code
are needed. The idea is that we will pretend to be using talloc for
a while, so that we can revert to our old talloc implementation at
any time for debugging purposes.
Some inspiration was taken from Mesa's ralloc:
http://cgit.freedesktop.org/mesa/mesa/tree/src/glsl/ralloc.h
This is another talloc replacement, but lacks some features we need
(getting size of an allocation, debugging features, being able to
access children in the dtor).
There's some information in ta/README what will happen next and how the
transition is expected to progress.
Change talloc destructor so that they can never signal failure, and
don't return a status code. This makes our talloc copy even more
incompatible to upstream talloc, but on the other hand this is
preparation for getting rid of talloc entirely.
(The talloc replacement in the next commit won't allow the talloc_free
equivalent to fail, and the destructor return value would be useless.
But I don't want to change any mpv code either; the idea is that the
talloc replacement commit can be reverted for some time in order to
test whether the talloc replacement introduced a regression.)
This only shows any differences when mpv isn't frontmost and is in fullscreen.
Cmd+Tab overlay is still at a higher level as to avoid complete usability fail.
Before this, they were shown on terminal only. Now they use the OSD
mechanism, which shows them on the video window or the terminal,
depending on settings and what's available.
Changing volume when audio is disabled was a feature request (github
issue #215), and was introduced with commit 327a779.
But trying to fix github issue #280 (volume is not correct in no-audio
mode, and if audio is re-enabled, the volume set in no-audio mode isn't
set), I concluded that it's not worth the trouble and the current
implementation is questionable all around. (For example, you can't
change the real volume in no-audio mode, even if the AO is open - this
could happen with gapless audio.) It's hard to get right, and the
current mixer code is already hilariously overcomplicated. (Virtually
all of mixer.c is an amalgamation of various obscure corner cases.)
So just remove this feature again.
Note that "options/volume" and "options/mute" still can be used in
idle mode to adjust the volume used next time, though these properties
can't be used during playback and thus not in audio-only mode.
Querying the volume still "works" in audio-only mode, though it can
return bogus values.
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>
The primary effect of this commit is that it fixes playback resume if
libquvi 0.9 and German locale are used, and libkdecore is on the system.
(See github issue #279.)
libquvi uses libproxy to determine system-wide proxy settings. libproxy
in turn loads libkdecore (if present) to determine KDE proxy settings.
libkdecore has a global constructor, which calls setlocale(LC_ALL, ""),
switching the current locale from "C" to what the user's settings. This
breaks some basic C string processing functions. Note that the locale
won't be set on program start, but only when libproxy calls dlopen() on
its config_kde module, which actually causes libkdecore to be loaded and
initialized.
In particular, with German locale, snprintf() would use "," instead of
"." when formatting float values, which in combination with playback
resume, would lead to parse errors the next time mpv was started, which
is how this issue was found.
I'd consider this a bug with libkdecore or at least libproxy. No library
should ever even touch locale: it might break basic expectations on C
string handling functions, might override program settings, and it's not
thread-safe. But this is so nasty and severe, that a quick hack to fix
it hurts less.
See github issue #279 and KDE bug #325902.
