| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Having this in gl_common is confusing.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For 9-15 bit material, cutting off the lower bits leads to significant
quality reduction, because these formats leave the most significant bits
unused (e.g. 10 bit padded to 16 bit, transferred as 8 bit -> only
2 bits left). 16 bit formats still can be played like this, as cutting
the lower bits merely reduces quality in this case.
This problem was encountered with the following GPU/driver combination:
OpenGL vendor string: Intel Open Source Technology Center
OpenGL renderer string: Mesa DRI Intel(R) 915GM x86/MMX/SSE2
OpenGL version string: 1.4 Mesa 9.0.1
It appears 16 bit support is rather common on GPUs, so testing the
actual texture depth wasn't needed until now. (There are some other Mesa
GPU/driver combinations which support 16 bit only when using RG textures
instead of LUMINANCE_ALPHA. This is due to OpenGL driver bugs.)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Finish renaming directories and moving files. Adjust all include
statements to make the previous commit compile.
The two commits are separate, because git is bad at tracking renames
and content changes at the same time.
Also take this as an opportunity to remove the separation between
"common" and "mplayer" sources in the Makefile. ("common" used to be
shared between mplayer and mencoder.)
|
|
|
Tis drops the silly lib prefixes, and attempts to organize the tree in
a more logical way. Make the top-level directory less cluttered as
well.
Renames the following directories:
libaf -> audio/filter
libao2 -> audio/out
libvo -> video/out
libmpdemux -> demux
Split libmpcodecs:
vf* -> video/filter
vd*, dec_video.* -> video/decode
mp_image*, img_format*, ... -> video/
ad*, dec_audio.* -> audio/decode
libaf/format.* is moved to audio/ - this is similar to how mp_image.*
is located in video/.
Move most top-level .c/.h files to core. (talloc.c/.h is left on top-
level, because it's external.) Park some of the more annoying files
in compat/. Some of these are relicts from the time mplayer used
ffmpeg internals.
sub/ is not split, because it's too much of a mess (subtitle code is
mixed with OSD display and rendering).
Maybe the organization of core is not ideal: it mixes playback core
(like mplayer.c) and utility helpers (like bstr.c/h). Should the need
arise, the playback core will be moved somewhere else, while core
contains all helper and common code.
|
