| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This affects packed RGB formats up to 16 bits per pixel. The old mplayer
names used LSB-to-MSB order, while FFmpeg (and some other libraries) use
MSB-to-LSB.
Nothing should change with this commit, i.e. no bit order or endian bugs
should be added or fixed. In some cases, the name stays the same, even
though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this
affects the user-visible names too; this might cause confusion.
|
|
|
|
|
|
|
| |
While I'm not very fond of "const", it's important for declarations
(it decides whether a symbol is emitted in a read-only or read/write
section). Fix all these cases, so we have writeable global data only
when we really need.
|
|
|
|
| |
The shit I put up with...
|
|
|
|
|
|
| |
Additionally to removing the global variables, this makes the options
more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws-
scaler. For --sws-scaler, use choices instead of magic integer values.
|
|
|
|
|
|
|
| |
Playing a video and then an audio file with cover art kept displaying
the last frame of the video. This was because the hasframe flag was set,
perhaps due to redrawing the last video frame before the cover art image
is decoded.
|
|
|
|
|
|
|
|
| |
It seems we can't really get rid of this. There are no other hints to
remove decorations that work across all reasonable WMs, so we're stuck
with the ugly motif stuff.
But at least we can make the code for it less ugly.
|
|
|
|
|
|
|
|
|
|
| |
The previous commit assumed the filter would be 1x1 (then constant
weight is correct) - but our code in fact uses at least a 2x2 filter. A
1x1 filter would generally be useless, except for nearest scaling - so
it didn't exist.
Insteasd of adding such a 1x1 filter, just turn the nearest weight
function into a scare function, which should take care of the issue.
|
|
|
|
|
|
| |
This is useful for playing content containing pixel art that hasn't been
pre-scaled, such as TASVideos' high quality encodes. The implementation is
lifted from <https://code.google.com/p/glumpy/source/browse/glumpy/image/filter.py#413>.
|
| |
|
| |
|
|
|
|
| |
See previous commits.
|
|
|
|
|
|
|
|
| |
This would imply eglGetProcAddress() doesn't work correctly, but using
dlsym() does. For now get rid of it - it won't work in libmpv, and we'll
probably need a better workaround if it's still broken.
This code was in the initial wayland commit.
|
|
|
|
|
| |
Added in 2010 with commit 4a8486f8 (svn commit 30994). I doubt anyone
still uses X11 on OSX, and we probably don't support 10.4 either.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The functions glXGetProcAddressARB() and glXQueryExtensionsString() were
loaded using dlsym(). This could fail when compiling to libmpv, because
then dlopen(NULL, ...) will look in the main program's list of
libraries, and the libGL linked to libmpv is never considered. (Don't
know if this somehow could be worked around.) The result is that using
vo_opengl with libmpv can fail.
Avoid this by not using dlsym(). glXGetProcAddressARB() was already used
directly in the same file, and that never caused any problems. (Still
add it to the configure test.) glXQueryExtensionsString() is documented
as added in GLX 1.1 - that's ancient.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
mpv supports two hardware decoding APIs on Linux: vdpau and vaapi. Each
of these has emulation wrappers. The wrappers are usually slower and
have fewer features than their native opposites. In particular the libva
vdpau driver is practically unmaintained.
Check the vendor string and print a warning if emulation is detected.
Checking vendor strings is a very stupid thing to do, but I find the
thought of people using an emulated API for no reason worse.
Also, make --hwdec=auto never use an API that is detected as emulated.
This doesn't work quite right yet, because once one API is loaded,
vo_opengl doesn't unload it, so no hardware decoding will be used if the
first probed API (usually vdpau) is rejected. But good enough.
|
|
|
|
| |
Close the X connection if initializing vaapi fails.
|
|
|
|
| |
Why are you reading this message.
|
|
|
|
|
|
|
| |
We pass a pointer to a GLint to sscanf, using the %d format. That format
_always_ takes int, and not GLint (whatever the heck that is). If GLint
is always int, then it doesn't make a difference, but is still better
because it doesn't play russian roulette with pointers.
|
|
|
|
| |
Really now...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't emit "hard" references to OpenGL functions. Always use the
platform specific function to lookup OpenGL functions, such as
glXGetProcAddress() with GLX (x11).
This actually fixes the build if only Wayland is enabled (e.g. using
--disable-gl-x11 on Linux).
Note that some sources claim that wglGetProcAddress() (win32) does not
return function pointers for OpenGL 1.1 functions (even if they are
valid and necessary in OpenGL 3.0). But if that happens, the fallback
employed in gl_w32.c/w32gpa() should catch this.
|
|
|
|
| |
Accidentally broken in commit 7163bf7d by inverting the condition.
|
|
|
|
|
|
|
|
|
|
| |
Setting this property was added 12 years ago, and the code was always
incorrect. The underlying data type is "long", not "pid_t". It's well
possible that the data types are different, and the pointer to the pid
variable is directly passed to XChangeProperty, possibly invoking
undefined behavior.
It's funny, because in theory using pid_t for PIDs sounds more correct.
|
|
|
|
|
|
| |
Having it as separate function is not useful.
Also remove the useless vo_window parameter.
|
|
|
|
|
|
|
| |
_WIN_LAYER is apparently an old GNOME thing (also explains why there is
a function vo_x11_get_gnome_layer() involved in this code). Prefer the
NetWM hints over this. This just moves the NetWM case if-body over the
_WIN_LAYER one.
|
|
|
|
|
|
|
| |
You can't use identifiers starting with "_" and an uppercase letter in
application programs. They are reserved by the C standard.
Unrelated change: drop unused/misleading vo_wm_NETWM define.
|
|
|
|
|
|
|
| |
I can only assume the old code was wrong. EWMH does not document
anything with _WIN_LAYER. Instead, you have to toggle the state using a
client message. We also remove these weird non-sense fallbacks, like
using _NET_WM_STATE_BELOW - what the hell?
|
|
|
|
| |
And use it for fullscreening. It will also be used for fixing --ontop.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Signed-off-by: wm4 <wm4@nowhere>
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
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.
|
|
|
|
| |
So long in the code without me noticing. Embarassing!
|
|
|
|
|
|
|
| |
Found by cppcheck.
Actually untested. (This is the file drag&drop code, I don't even know
which wayland clients support this.)
|
|
|
|
|
| |
Tried to load a 32 bit value by dereferencing a uint32_t pointer, but
the pointer is not guaranteed to be aligned, not even in practice.
|
|
|
|
|
|
| |
This used MP_NOPTS_VALUE to compare with ffmpeg-style int64_t PTS
values. This probably happened to work, because both constants use the
same value.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the newly provided mp_vdpau_handle_preemption() function, instead of
accessing mp_vdpau_ctx fields directly. Will probably make multithreaded
access to the vdpau context easier.
Mostly unrelated to the actual changes, I've noticed that using hw
decoding with vo_opengl sometimes leads to segfaults inside of nvidia's
libGL when doing the following:
1. use hw decoding + vo_opengl
2. switch to console (will preempt on nvidia systems)
3. switch back to X (mpv will recover, switches to sw decoding)
4. enable hw decoding again
5. exit mpv
Then it segfaults when mpv finally calls exit(). I'll just blame nvidia,
although it seems likely that something in the gl_hwdec_vdpau.c
preemption handling triggers corner cases in nvidia's code.
|
|
|
|
| |
Also, reset rc completely, instead of assuming things.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until recently, the VO was an unavoidable part of the seeking code path.
This was because vdpau deinterlacing could double the framerate, and hr-
seek and framestepping etc. all had to "see" the additional frames. But
we've removed the frame doubling from the vdpau VO and moved it into a
video filter (vf_vdpaupp), and there's no reason left why the VO should
participate in seeking.
Instead of queuing frames to the VO during seek and skipping them
afterwards, drop the frames early.
This actually might make seeking with vo_vdpau and software decoding
faster, although I haven't measured it.
|