Remove lots of weird logic and dead code.
The only difference is that when specifying a monitor aspect ratio, it
will always upscale and never downscale.
The draw_osd change is a bit tricky: I guess originally, there was some
intention not to second-guess the generic aspect code, but the result is
the same and the code is more confusing.
The rescaling is rather silly. vo_get_src_dst_rects() doesn't return an
uncropped image, so the texture coordinates have to be recalculated,
which looks more complicated, but is actually what the other OpenGL VOs
also do.
Tested and fixed by Stefano Pigozzi.
Instead of manually calculating aspect ratio etc., use
vo_get_src_dst_rects(). This has the advantage that we can drop some
special cases in aspect.c later.
Simplify the code, and move resizing the X images from draw_image() to a
new resize() function.
Do some other simplifications. The gXErrorFlag check was actually dead
code, even in mplayer-svn. Special-casing on WinID is not needed
anymore (we created an embedded window, and its size is updated by
x11_common.c).
I introuced this regression in 8fc0b618d5. The backend would go into
incosistent state caused by calling `vo_cocoa_fullscreen` where it wasn't
needed.
Fixes#44
This only matters for those who want to use vf_pp. The old API is marked
as deprecated, and doesn't work on Libav. It was broken on FFmpeg, but
has recently started working again - the fields in question were not un-
deprecated though. Instead you're supposed to use a new API, which does
exactly the same thing (what...?).
Also don't pass the QP table with mp_image_copy_attributes() - it
probably does more harm than it's useful.
By the way, with -vf=dlopen=TOOLS/vf_dlopen/showqscale.so, it appears
the table as output by recent FFmpeg is offset by 1 macroblock in X
direction and 2 macroblocks in Y direction, which most likely will
interfere with normal vf_pp operation. However, this is not my problem.
The only real reason for this commit is that we can finally get rid of
all libav* related deprecation warnings. (Though they are constantly
deprecating APIs, so this will not last long.)
The old names have been deprecated a while ago, but were needed for
supporting older ffmpeg/libav versions. The deprecated identifiers
have been removed from recent Libav and FFmpeg git.
This change breaks compatibility with Libav 0.8.x and equivalent
FFmpeg releases.
avcodec_encode_video() was deprecated, and was finally removed from
Libav and FFmpeg git.
This change breaks compatibility with Libav 0.8.x. Thank the Libav
developers, not me.
Removes the local ret because it was only in an assert statement and also
removes the window size assignments, because they are already done in
config_wnidow_wayland.
Fix a regression introduced in commit 979ce46c64 causing a window to take up
more space than what the display allows.
Add keepCentered:YES, so that the video area is always clipped to the current
visible frame (even when using scale).
Fixes#38.
Latest nvidia drivers ignore the application setting, so this switch
makes even less sense than before. It's still possible to control this
with VO specific suboptions.
Separate the video output options from the big MPOpts structure and also only
pass the new mp_vo_opts structure to the vo backend.
Move video_driver_list into mp_vo_opts
Removes almost every global variabel in vo.h and puts them in a special struct
in MPOpts for video output related options.
Also we completly remove the options/globals pts and refresh rate because
they were unused.
Commit 9efe32120 stops recreating the hidden window used for OpenGL's
extensions autodetection. The `cocoa_common` code assumed the hidden flag could
only come when creating a window which is now not true anymore.
Move some code around so that hidden, fullscreen and window position are
respected on subsequent calls of config.
Apparently newer Mesa versions changed their <GL/glx.h> header, and
unconditionally define GLX_CONTEXT_MAJOR_VERSION_ARB and others. This
clashed with gl_header_fixes.h, a header which quarantines bad hacks
to make compilation possible on systems with outdated GL headers.
Specifically, our header was included before glx.h, so the hacks were
always active, and somehow Mesa's glx.h used to deal with this by not
redefining existing identifiers.
Fix the gl_header_fixes.h logic so the hacks are checked after including
glx.h.
When paused, --cursor-autohide worked with a precision of 500ms, which
is the main loop's default sleep time when paused. Cursor hiding is
polled in x11_common, and the main loop never called the X11 code at
the right time. Fix this by allowing the VO to set a time when it
should be called next.
This was done so because the X11 code had a hard to track down issue
with some window managers, and caused the VO window to be placed
incorrectly. This was fixed in the previous commit. Consequently, we can
remove this bad hack.
vo_opengl creates an invisible window with VOFLAG_HIDDEN in order to
test whether the OpenGL context is useable. The visible window is
created at a later point. This has been broken forever (in vo_gl,
now called vo_opengl_old, it could be avoided by disabling auto-
detection explicitly using the "yuv" sub-option). Avoiding
VOFLAG_HIDDEN only mitigates the issue, and a related bug can still
happen with some window managers (see below).
As a hack, code was added to vo_gl to destroy the (hidden) window so
that all state was destroyed. Later, more hacks were added to deal with
some caveats that came with recreating the window, such as probing for
the context up to 4 times.
Attempt to fix the problem properly. There were two problems: first,
the window was not resized to video size before mapping. This was the
main cause for the placement issue, e.g. mapping the window as 320x200,
and then resizing it. Second, mpv tried to force the window position
with XSetWMNormalHints and PPosition with values it just read with
XGetGeometry. This messes up the window manager's default placement.
It seems to be a race condition, and behavior is different across
various WMs too: with IceWM, the window manager's placement is usually
preferred, and with Fluxbox, mpv's position is preferred. mpv's default
position is centering the window on the screen, which is much nicer for
video in general than typical WM default placement, so it's possible
that this bug was perceived as a feature. (Users who want this have to
use --geometry="50%:50%", doing this by default is probably not safe
with all WMs.)
Since the old code was hard to follow and full of issues, it's easier
to redo it. Move general window creation stuff out of the
vo_x11_config_vo_window function, and move the resize logic into it.
This has been tested on IcwWM, Fluxbox, awesome, Unity/Compiz.
Store the window state (position and size) in vo_x11_state, instead of
in vo->dx/dy/dwidth/dheight. The VO variables are overwritten by vo.c on
every vo_config() call, which is extremely not helpful.
Now vo->dx/dy are mostly unused (except for passing the position forced
by the --geometry option), and vo->dwidth/dheight are set for the VO,
and otherwise read for resize detection only.
In the long term, the way vo_config() handles the --geometry option
should be changed, and vo->dx/dy should be removed.
Remove some useless stuff: VO_EVENT_MOVE and VO_EVENT_KEYPRESS were
generated, but unused. Wayland changes by Alexander Preisinger.
It was once used for vo_sdl (the old one based on SDL 1.2), since SDL
apparently lost the GL state when switching to fullscreen. The new
vo_sdl (using SDL 1.3) doesn't use or need this. It's dead code, so
get rid of it.
OPT_BASE_STRUCT defines which struct the OPT_ macros (like OPT_INT etc.)
reference implicitly, since these macros take struct member names but no
struct type. Normally, only cfg-mplayer.h should need this, and other
places shouldn't be bothered with having to #undef it.
(Some files, like demux_lavf.c, still store their options in MPOpts. In
the long term, this should be removed, and handled like e.g. with VO
suboptions instead.)
VFCAP_OSD was used to determine at runtime whether the VO supports OSD
rendering. This was mostly unused. vo_direct3d had an option to disable
OSD (was supposed to allow to force auto-insertion of vf_ass, but we
removed that anyway). vo_opengl_old could disable OSD rendering when a
very old OpenGL version was detected, and had an option to explicitly
disable it as well.
Remove VFCAP_OSD from everything (and some associated logic). Now the
vo_driver.draw_osd callback can be set to NULL to indicate missing OSD
support (important so that vo_null etc. don't single-step on OSD
redraw), and if OSD support depends on runtime support, the VO's
draw_osd should just do nothing if OSD is not available.
Also, do not access vo->want_redraw directly. Change the want_redraw
reset logic for this purpose, too. (Probably unneeded, vo_flip_page
resets it already.)
All wayland only specific routines are placed in wayland_common.
This makes it easier to write other video outputs.
The EGL specific parts, as well as opengl context creation, are in gl_common.
This backend works for:
* opengl-old
* opengl
* opengl-hq
To use it just specify the opengl backend
--vo=opengl:backend=wayland
or disable the x11 build.
Don't forget to set EGL_PLATFORM to wayland.
Co-Author: Scott Moreau
(Sorry I lost the old commit history due to the file structure changes)
This allowed making the player switch the monitor video mode when
creating the video window. This was a questionable feature, and with
today's LCD screens certainly not useful anymore. Switching to a random
video mode (going by video width/height) doesn't sound too useful
either.
I'm not sure about the win32 implementation, but the X part had several
bugs. Even in mplayer-svn (where x11_common.c hasn't been receiving any
larger changes for a long time), this code is buggy and doesn't do the
right thing anyway. (And what the hell _did_ it do when using multiple
physical monitors?)
If you really want this, write a shell script that calls xrandr before
and after calling mpv.
vo_sdl still can do mode switching, because SDL has native support for
it, and using it is trivial. Add a new sub-option for this.
The --wid switch (for embedding the player into other applications)
didn't create a new window, and instead tried to use the window that
was passed via --wid directly. This made the code more complex, caused
strange X errors (mpv and host application fighting for exclusive X
resources), and actually could cause issues if the --wid window wasn't
created with the X Visual needed for OpenGL.
Always create a window instead. This makes it always possible to embed
the player into foreign windows. --geometry doesn't work anymore - the
controlling application should always create a new window to place the
player inside it, and can control the video window by moving and
resizing this window.
w32_common.c actually did this right, and always creates a new window.
create_window is really bad naming, because this function can be called
multiple times, while the name implies that it always creates a new
window. At least the name config_window is not actively misleading.
Allow the backend code to create a GL context on best effort basis,
instead of having to implement separate functions for each variation.
This means there's only a single create_window callback now. Also,
getFunctions() doesn't have the gl3 parameter anymore, which was
confusing and hard to explain.
create_window() tries to create a GL context of any version. The field
MPGLContext.requested_gl_version is taken as a hint whether a GL3 or a
legacy context is preferred. (This should be easy on all platforms.)
The cocoa part always assumes that GL 3 is always available on
OSX 10.7.0 and higher, and miserably fails if it's not. One could try
to put more effort into probing the context, but apparently this
situation never happens, so don't bother. (And even if, mpv should be
able to fall back to vo_corevideo.)
The X11 part doesn't change much, but moving these functions around
makes the diff bigger.
Note about some corner cases:
This doesn't handle CONTEXT_FORWARD_COMPATIBLE_BIT_ARB on OpenGL 3.0
correctly. This was the one thing getFunctions() actually needed the
gl3 parameter, and we just make sure we never use forward compatible
contexts on 3.0. It should work with any version above (e.g. 3.1, 3.2
and 3.3 should be fine). This is because the GL_ARB_compatibility
extension is specified for 3.1 and up only. There doesn't seem to be
any way to detect presence of legacy GL on 3.0 with a forward
compatible context. As a counter measure, remove the FORWARD_COMPATIBLE
flags from the win32 code. Maybe this will go wrong. (Should this
happen, the flag has the be added back, and the win32 will have to
explicitly check for GL 3.0 and add "GL_ARB_compatibility" to the extra
extension string.)
Note about GLX:
Probing GL versions by trying to create a context on an existing window
was (probably) not always possible. Old code used GLX 1.2 to create
legacy contexts, and it required code different from GLX 1.3 even before
creation of the X window (the problem was selections of the X Visual).
That's why there were two functions for window creation (create_window_old
and create_window_gl3). However, the legacy context creation code was
updated to GLX 1.3 in commit b3b20cc, so having different functions for
window creation is not needed anymore.
The backend sub-option for vo_opengl and vo_opengl-old accepted numeric
values (like -1, 0, ...) for compatibility with MPlayer. This was added
in mplayer2 times, and is not important anymore.
