| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
When the player is paused, and video filters are changed, an exact seek
is executed to refresh the display. Increase the exactness of the seek
in this case; this reuses the code used for frame backstepping.
It might help in cases where seeking is very imprecise, such as with
transport streams.
|
| |
|
|
|
|
| |
Returns whether a DVD/BD menu is active. As requested by #788.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a property is notified as changed, and then again (before the change
notification is returned to the client), and the second change is a
sporadic change (i.e. nothing actually changed) and the change
notification was associated with with a data type, it could happen that
a change was "overlooked", because it would detect no change on the
second notification.
This is actually a pretty annoying corner case, due to the annoying way
we do things, so just store both the previously returned _and_ the newly
obtained property value. then we always compare with the user value to
check for a change, excluding any possibility of a missed change.
Note that we don't (can't/shouldn't) care if a value changes, and then
changes back; it's fine if that doesn't generate a notification. This is
due to how property notifications are supposed to be coalesced.
|
|
|
|
|
|
|
|
| |
Reduces some code-duplication.
Just call DPMSEnable/DPMSDisable, instead of DPMSForceLevel when
reenabling DPMS. "Force" sounds evil, and messing with DPMS is already
pretty evil. I'm not even sure that we should.
|
| |
|
|
|
|
| |
Accidentally broken in commit 95462747.
|
|
|
|
|
|
| |
XGetWindowProperty is a really bad API, almost as if the NSA designed
it. The wrapper takes care of verifying the return values and handle
corner cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The window "gravity" influences how placement interacts with WM added
borders (i.e. from decorations). This is probably what the code removed
in commit c14721c8 was about.
In theory, we'd probably want to set the gravity depending on the
relative placement requested by the user (so that it's possible to line
up the top/left video pixel with the monitor corner, as well as the
bottom/right pixel - but that would be too complicated, and who cares
after all?).
I'm also not sure whether CenterGravity really uses the top/left corner
as reference point (instead of making coordinates relative to the window
center), but empirically it's correct.
|
| |
|
| |
|
|
|
|
| |
There's apparently no reason why we should set a bogus size.
|
|
|
|
|
| |
Now it's always recreated in vo_x11_sizehint(). Also, the Xlib manual
says you must use XAllocSizeHints() (for ABI reasons), so do that.
|
| |
|
|
|
|
|
|
|
| |
Try to get the "new" code path (using NetWM/EWMH) free of hacks done for
the sake of old WMs or the no-WM case.
Implement --fs-screen using _NET_WM_FULLSCREEN_MONITORS.
|
|
|
|
|
|
| |
Keeps the window centered on resize. Seems nicer. (Although it's worse
if 1. the default placement of the WM puts it into a monitor corner,
and 2. you switch to a larger video.)
|
|
|
|
|
|
|
|
|
|
| |
It was added with 3813c685 in 2004. I'm not really sure why this gravity
stuff would be needed; apparently it has to do with misplacements with
broken WMs and had to be changed on fullscreen. Just get rid of it; it
works perfectly fine without on modern WMs.
The thread discussing this is here:
http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-July/027674.html
|
|
|
|
|
| |
XInternAtom() already caches lookups. Even if calling XInternAtom would
be always inefficient, it wouldn't matter much during normal playback.
|
|
|
|
| |
Keeping it separate seems less readable.
|
|
|
|
|
|
|
|
| |
When writing a video to foo.mp3, the user's intention is clearly to drop
the video stream, and similarly, when writing to foo-%d.png, the
intention is clearly to drop the audio stream. Now, explicit
specification of --no-audio or --no-video is no longer necessary in
these cases.
|
| |
|
| |
|
|
|
|
|
| |
Currently, they are allowed, but only because MPlayer happened to do
that. This might or might not be changed in the future.
|
|
|
|
|
| |
Simplifies the code a lot. You can still use --x11-netwm=no to disable
NetWM for whatever reasons.
|
|
|
|
| |
This was for Motif Window Manager. No, I don't care about Motif.
|
|
|
|
|
| |
Unfortunately, it looks like some Motif functionality is still needed
to allow for --no-border.
|
|
|
|
|
|
|
| |
This should get rid of some flickering. Since this actually skips all
the wacky fullscreening code on startup, this might lead to certain
wacky features to stop working. In this case, you'll have to use the
--x11-fstype option, and disable _NETWM_STATE_FULLSCREEN usage.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
vo_x11_map_window() was attempting to clear the window on map. However,
it did so immediately after the map request. It probably assumed that
the drawing calls for clearing the window would be queued along with the
map request, and then executed in the right order. However, this
assumption was wrong - the map request first has to go to the window
manager (I guess?), so a lot of things happen before the window is even
mapped.
Fix this by moving the call to the MapNotify message handler, when the
window (apparently) becomes really visible.
I also tried to set CWBackPixel to black instead, but this seemed to
result in flickering on manual resizing.
|
|
|
|
|
|
|
|
|
|
|
| |
This blocks everything, until the window is actually reported as mapped.
This fixes the race condition between VO initialization and mapping the
window, which resulted in possibly different window sizes, leading to an
immediate redraw, visible as flashing.
Note that if the map event never comes for some reason, we're out of
luck and will block forever.
|
| |
|
| |
|
|
|
|
|
| |
This was presumably for backward compatibility,
but it was preventing the use of the new names.
|
| |
|
|
|
|
|
| |
Also, move num_requested() to where it's used. Remove newlines from VS
error messages. Remove an assert(0) on an error path.
|
| |
|
|
|
|
|
|
|
| |
It could in theory happen that the filter loop will enter a blocking
wait, even though it could make progress by emptying the list of
already-filtered images. I'm not quite sure if this could actually cause
a real issue - probably not.
|
| |
|
|
|
|
|
|
|
|
| |
VapourSynth won't just filter multiple frames at once on its own. You
have to request multiple frames at once manually. This is what this
commit introduces: a sub-option controls how many frames will be
requested at once. This also changes the semantics of the maxbuffer sub-
option, now renamed to buffered-frames.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The situation has changed a bit since the days of mplayer2, so we can
use more/less diplomatic wording. Merge the two sections listing
changes from MPlayer and mplayer2. Mention the client API and Lua
scripting as alternatives to slave mode.
I'm calling MPlayer code "horrible". This is not meant as an offense,
but after turning around almost every line of MPlayer code, I believe
I have a right to say this. Sorry. I would say that MPlayer has a
surprisingly sane and simple architecture (for what it is), but much
of it drowned under a load of evil hacks or not-cleaned-up-yet code.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This started as a bunch of smaller changes to make the old configure
script maintainable with minimum effort. It ended up as complete
rewrite, because at once point I started to like shell programming (I
hope this sickness is curable), and I wanted to see how small I can
make the configure script. The typical configure test is now 1 or 2
lines big, located in 1 or 2 places, instead of >15 lines and being
spread over 5 or 6 places.
The main "trick" is factoring the tests into a few generic, commonly
needed tests, instead of writing everything manually.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of effort was spent on making the waf based build-system work
properly on all supported platforms, while the old configure script was
neglected. It seems that nobody maintains the non-Linux parts of the
configure script anymore, and all improvements go into the waf scripts.
Thus it makes no sense anymore to maintain the non-Linux parts. They're
just dead weight. Remove them completely.
Also apply some additional simplifications. For example, listing
enabled/disabled VO modules seems like a waste of effort.
|
|
|
|
|
|
|
|
|
| |
These were in the old configure script too.
Two flags are explicitly tested, because I have no idea how widespread
support for them is, and testing them is just easier than trying to look
them up in various gcc/clang manuals. There are people using gcc 4.2
out there, so some caution is warranted.
|
|
|
|
| |
So long in the code without me noticing. Embarassing!
|
|
|
|
|
|
| |
Make loading of scripts independent of Lua. Move some of the loading
code from lua.c to scripting.c, and make it easier to add new scripting
backends.
|
|
|
|
|
|
|
| |
waf has a proper test, but no test was added to old-configure.
This means that on OSX, old-configure is not supposed to work anymore.
But still allow it to compile cleanly on OSX.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previous to this commit, read_chunk was not set in stream_smb. The
cache was therefore filled in small 8K chunks. This resulted in poor
performance when compared to, for example, smbnetfs on the same
network.
The value of 128k is chosen both because it is emperically
the "levelling off point" for throughput into mpv's cache, and because
it is the value chosen by smbnetfs when serving smb shares to
mpv.
Note that this change has no effect unless --cache is explicitly
specified as smb:// streams do not activate cache by default. This is
because the default cache size of 320K is so small it actually makes
smb:// perfomance worse. For best results use at least --cache=1024.
|
| |
|
|
|
|
| |
Closes #781.
|
|
|
|
| |
Use the new context and the default functions provided.
|
|
|
|
| |
VDA supports h264 only.
|
|
|
|
|
| |
Hwaccel 1.2 populates only the third data field and assumes
that the AVCodecContext is available to the dealloc function.
|
|
|
|
|
|
|
|
|
| |
This didn't quite work. The main issue was that get_space tries to be
clever to reduce overall buffering, so it will cause the playloop to
decode and queue only as much audio as is needed to refill the AO in
reasonable time. Also, even if ignoring the problem, the logic of the
previous commit was slightly broken. (This required a few retries,
because I couldn't reproduce the issue on my own machine.)
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the audio buffer went low, but could not be refilled yet, it could
happen that the AO playback thread and the decode thread could enter a
wakeup feedback loop, causing up to 100% CPU usage doing nothing. This
happened because the decoder thread would wake up the AO thread when
writing 0 bytes of newly decoded data, and the AO thread in reaction
wakes up the decoder thread after writing 0 bytes to the AO buffer.
Fix this by waking up the decoder thread only if data was actually
played or queued. (This will still cause some redundant wakeups, but
will eventually settle down, reducing CPU usage close to ideal.)
|
| |
|
|
|
|
|
| |
Use for all AO thread events y=0.5, while playloop events remain at y=1.
This makes the graph easier to read.
|
| |
|
|
|
|
|
| |
You wouldn't have guessed that the bottom-most "level[i] = 0.f;" line
was actually required. It even confused cppcheck.
|
| |
|
|
|
|
|
|
|
| |
Found by cppcheck.
Actually untested. (This is the file drag&drop code, I don't even know
which wayland clients support this.)
|
|
|
|
|
|
|
| |
This is legal in theory. "false" expand to 0, and 0 is a valid pointer
value. But I guess this was not really intended.
Found by cppcheck.
|
|
|
|
|
|
|
|
| |
This shouldn't matter, but it's probably better if the code to check is
valid - otherwise an extremely clever compiler might fail to compile it,
and the feature would be misdetected. (Probably.)
Found by cppcheck.
|
|
|
|
|
|
|
|
|
| |
Caused failure to detect .pls files, because they were misdetected as
m3u. The problem is that "forcing playlist files" and "forcing a
specific playlist format" are not really treated separate, and in both
cases p->force is set to true. This made m3u detect all files as m3u
if --playlist was used. So correctly check whether the file format is
actually being probed or not.
|
| |
|
|
|
|
|
|
| |
These are now equivalent to combining commands with the "cycle pause" or
"set pause" commands, and thus are not needed anymore. They were also
obscure and undocumented.
|
|
|
|
|
|
|
|
|
| |
mpv supports per-file config files, basically filename+".conf". We use
a static buffer for the new filename, and if that buffer is too small,
we print a warning. This is confusing for e.g. long URLs, so just hide
the warning by default.
Why not dynamically allocate the buffer? Who cares.
|
|
|
|
| |
Fixes "make clean".
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I don't think this is really a very good idea because it is conceptually
incorrect but other prominent multimedia programs use this approach
(VLC and xbmc), and it seems to make the conversion more robust in certain
cases.
For example it has been reported, that configuring a receiver that can output
7.1 to output 5.1, will make CoreAudio report 8 channel descriptions, and the
last 2 descriptions will be tagged kAudioChannelLabel_Unknown.
Fixes #737
|
|
|
|
|
| |
This code doesn't actually makes much of a difference, and the AudioUnit
mostly wants layout tags anyway.
|
|
|
|
|
|
| |
The code was falling back to the full waveext chmap_sel when less than 2
channels were detected. This new code is slightly more correct since it only
fills the chmap_sel with the stereo or mono chmap in the fallback case.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
CoreAudio supports 3 kinds of layouts: bitmap based, tag based, and speaker
description based (using either channel labels or positional data).
Previously we tried to convert everything to bitmap based channel layouts,
but it turns out description based ones are the most generic and there are
built-in CoreAudio APIs to perform the conversion in this direction.
Moreover description based layouts support waveext extensions (like SDL and
SDR), and are easier to map to mp_chmaps.
|