| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Integrate it with the existing surface allocator in vdpau.c. The changes
are a bit violent, because the vdpau API is so non-orthogonal: compared
to video surfaces, output surfaces use a different ID type, different
format types, and different API functions.
Also, introduce IMGFMT_VDPAU_OUTPUT for VdpOutputSurfaces wrapped in
mp_image, rather than hacking it. This is a bit cleaner.
|
|
|
|
|
|
| |
black_pixel is an (apparently necessary) 1x1 black surface used for
clearing the screen. It was allocated in RGB mode only, but is sometimes
used in YUV mode too.
|
|
|
|
|
|
|
|
|
| |
In at least 2 places, we want to "shift" positional parameters by a
certain amount, or remove all parameters if there are fewer parameters.
bash handled this just fine, but dash vomits upon it. POSIX shell allows
both behaviors, so we have to fix it.
Fix a comparison done with "==" instead of "=".
|
|
|
|
|
|
|
| |
Cover art is treated like video, but is not really video. In one case,
the audio sync code was accidentally still active. Fixes cover art
playback with --ao=null. (This is due to ao_null's latency emulation.
Although it's not very clear whether that is actually correct...)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
vo_vdpau currently has a video queue larger than 1 entry, which causes
the video display code to never queue display the video frame. This is
because we consider cover art an endless stream of frames decoded from
the same source packet, and include special logic to actually only
decode and display 1 frame.
Also, make decode_image() also signal EOF in the cover art case.
|
|
|
|
| |
Hides the "Cache fill:" message with default settings.
|
| |
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
|
|
|
| |
Fixes #795.
|
| |
|
|
|
|
| |
This should be ok now after the x11 code was adjusted.
|
|
|
|
|
| |
After VOCTRL_REDRAW_FRAME, flip_page is called, which renders the frame.
The current code rendered the frame twice; drop the redundant call.
|
|
|
|
|
|
| |
Without this change, the compiler uses by default the "talloc.h" file
installed by the package libtalloc within /usr/local/include. Found and
tested on OpenBSD but FreeBSD has the same patch on its ports tree.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This should be more correct. The builtins were made to directly map to
C11, and the way we use them is now relatively close to how gcc
implements atomics in 4.9. In particular, we make use of the load and
store builtins.
I'm not entirely sure why gcc didn't support stdatomic.h in 4.8 already.
Maybe support for the builtins was incomplete or broken - so there's a
lot of room for doubt about the correctness of this.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In my opinion, we shouldn't use atomics at all, but ok.
This switches the mpv code to use C11 stdatomic.h, and for compilers
that don't support stdatomic.h yet, we emulate the subset used by mpv
using the builtins commonly provided by gcc and clang.
This supersedes an earlier similar attempt by Kovensky. That attempt
unfortunately relied on a big copypasted freebsd header (which also
depended on much more highly compiler-specific functionality, defined
reserved symbols, etc.), so it had to be NIH'ed.
Some issues:
- C11 says default initialization of atomics "produces a valid state",
but it's not sure whether the stored value is really 0. But we rely on
this.
- I'm pretty sure our use of the __atomic... builtins is/was incorrect.
We don't use atomic load/store intrinsics, and access stuff directly.
- Our wrapper actually does stricter typechecking than the stdatomic.h
implementation by gcc 4.9. We make the atomic types incompatible with
normal types by wrapping them into structs. (The FreeBSD wrapper does
the same.)
- I couldn't test on MinGW.
|
|
|
|
| |
Requested in github issue #608.
|
|
|
|
|
| |
Currently I don't have a crosscompilation toolchain, so I couldn't test
whether this actually compiles (and still can't).
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Some options change from percentages to number of kilobytes; there are
no cache options using percentages anymore.
Raise the default values. The cache is now 25000 kilobytes, although if
your connection is slow enough, the maximum is probably never reached.
(Although all the memory will still be used as seekback-cache.)
Remove the separate --audio-file-cache option, and use the cache default
settings for it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This works around an issue in OpenBox: OpenBox apparently sizes the
normal window incorrectly if aspect ratio hints are set, and the window
size is off by 1 pixel. Then, when going fullscreen and leaving
fullscreen again, mpv sets the hints based on OpenBox' broken window
size, and as result, OpenBox sizes the window incorrectly and is off by
1 pixel again - so it's 2 pixels off in total. The error gets more
visible, the more often you toggle fullscreen mode.
Work this around by not setting the window hints if we don't need to.
Actually we only need to do this when the video is resized during
fullscreen, which happens rarely. Under normal circumstances, leaving
fullscreen mode requires that the WM restores the old state.
As such, this commit is not only a workaround, but actually a cleanup.
Note that we do need to set the hints when leaving fullscreen if the
window has resized: even though we set the hints in
vo_x11_highlevel_resize (called by vo_x11_config_vo_window), this
doesn't seem to have an effect (at least on IceWM), so we have to do it
after that.
Side note: ot seems commit 625ad57a strangely triggered the OpenBox
issue according to user reports; I'm not sure why.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Drop: sami, vplayer, rt, pjs, mpsub, aqt, jacosub. None of these seem
to be actually in use, except sami. Sami is very complex, and the
results subreader produces are not very useful.
For all these formats, there are still parsers in FFmpeg. We remove the
subreader implementation, because it might contain security relevant
bugs and such. (This is old, unmaintained C string parsing code, written
in times where absolutely nobody cared about security. The kind of
awesome code.)
We keep the other formats, because they're (mostly) commonly used and
relatively simple, for UTF16 support (still missing in FFmpeg), and for
the sake of Libav.
|
|
|
|
|
| |
So any VOCTRL can be called at any time. Working towards removing all
these config_ok checks in vo.c.
|
|
|
|
|
|
|
| |
Before this commit, this was somehow polled (i.e. not the right way).
Also, selects the correct window when doing --wid=0 (which is another
weird special-case).
|
| |
|
|
|
|
| |
Also drop a vague hint how to do it in the manpage.
|
|
|
|
|
|
|
|
|
| |
Enabling DPMS even though you disabled it globally is pretty unfriendly,
so don't do it. Instead, we only disable DPMS if it was enabled, and
only enable it if we disabled it ourselves.
The other way should never happen (disabling DPMS permanently), unless
mpv crashes during playback.
|
|
|
|
|
|
|
|
| |
It can easily happen that mp_time_us_to_timespec() gets a time in the
past, and then the time difference will be negative. Regression
introduced in commit f47a4fc3.
Also fix an underflow check in mp_add_timeout().
|
|
|
|
|
|
| |
Currently, it's unused. Still keep the file, because it's not unlikely
we'll need it again, and removing/readding the include statements for
this file is too annoying.
|
|
|
|
|
| |
This was requested by someone. Not sure if it's a good idea; it seems
more can go wrong than right.
|
|
|
|
|
|
|
| |
This is probably a good idea, because it would make it easier for
software embedding mpv to configure the mpv parts, without requiring the
host program to provide explicit mechanisms for this (other than calling
mpv_load_config_file()).
|
|
|
|
|
|
|
|
|
| |
The code paths for setting options by string and by direct "raw" value
were too different, which resulted in some weird code. Make the code
paths closer to each other.
Also, use this to remove the weirdness in the mpv_set_option()
implementation.
|
|
|
|
|
|
| |
Use the time as returned by mp_time_us() for mpthread_cond_timedwait(),
instead of calculating the struct timespec value based on a timeout.
This (probably) makes it easier to wait for a specific deadline.
|
|
|
|
|
| |
"menu" is in fact understood by stream_bluray.c, so just drop that
sentence.
|
|
|
|
|
|
|
|
|
| |
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.
|