| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The extension checking logic was broken, which reported OpenGL 3 if the
OpenGL .so exported OpenGL 3-only symbols, even if the reported OpenGL
version is below 3.0. Fix it and simplify the code a bit. Also never
fail hard if required functions are not found. The caller should check
the capability flags instead. Give up on the idea that we should print
a warning if essential functions are not found (makes loading of ancient
legacy-only extensions easier).
This was experienced with the following version strings:
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
(Possibly reports a very old version because it has no GLSL support,
and thus isn't even GL 2.0 compliant.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Don't request CONTEXT_FORWARD_COMPATIBLE when creating a GL3 context on
X11. This improves compatibility with some Mesa drivers.
Setting this bit was originally intended to make the code compatible
to newer (future, possibly not yet existing) OpenGL implementations.
These implementations wouldn't have to support deprecated legacy GL
features, which we know that we don't use, and could return a context
with a higher OpenGL version than requested.
In practice, this didn't work out. CONTEXT_FORWARD_COMPATIBLE requires
the driver to explicitly disable deprecated functionality. If it doesn't
do that, it has to reject context creation with that flag set. And it
turns out there are Mesa drivers which suffer from this caveat. See [1].
This probably also means that a GL application with a fixed set of
required GL features (such as a subset of GL 3.2 core, like vo_opengl.c)
may need to probe several GL versions if drivers really start dropping
legacy GL.
On Windows, CONTEXT_FORWARD_COMPATIBLE is still set. It is not known
if this is ideal, but fortunately there is no Mesa on Windows.
CONTEXT_CORE_PROFILE is still always set. For requested GL versions
lower than 3.2, this flag is ignored. Should we requires higher versions
later, we want it to be set, so don't remove it.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=57241
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|