Commit Graph

17 Commits

Author SHA1 Message Date
wm4 697309fc48 vo_opengl: use triangle strip for video
A small simplification. Couldn't be done before, because it was also
used by the OSD code, which required disjoint quads in a single draw
call.

Also mess with the unrelated code in gl_osd.c to simplify it a little
as well.
2015-01-30 15:57:40 +01:00
wm4 e0e06f0f0c vo_opengl: move remaining OSD rendering parts to gl_osd.c
Reduces the size of gl_video.c a bit further.

This also uses a separate vertex array object for OSD elements, so the
video one can be simplified slightly.

OSD shader generation is still in gl_video.c, which leads to the strange
additional parameter to mpgl_osd_init(). The issue is that video
parameters influence the OSD shader (????), and also OSD needs to go
through the screen colormanagement.
2015-01-29 18:29:28 +01:00
wm4 3583559164 vo_opengl: move utility functions from loader to a separate file
gl_common.c contained the function loader (which is big) and additional
utility functions (not so big, but will grow when moving more out of
gl_video.c). Just split them. There are no changes other than some
modifications to comments.
2015-01-28 19:40:46 +01:00
wm4 e34957940b vo_opengl: cleanups after vo_opengl_old removal
Don't load all the legacy functions (including ancient extensions).
Slightly simplify function loader and context creation, now that legacy
GL doesn't need to be handled. Remove the code for drawing OSD in legacy
mode.

Remove all the header hacks, which were meant for ancient OpenGL headers
which didn't even support things like OpenGL 1.3. Instead, adjust the
GLX check to make sure we get both OpenGL 3x and 2.1 symbols. For win32
and OSX, we assume that the user has the latest headers anyway. For
wayland, we hope that things somehow go right.
2015-01-21 20:32:42 +01:00
wm4 f6dac5d884 vo_opengl: GLES does not support GL_BGRA
Apparently GLES 2 and 3 do not support this. (The implementations I
tested with were derived from desktop OpenGL and were not overly strict
with this.)

This is no problem; just use GL_RGBA and mangle the channels in the
shader.

Also disable direct support for image formats like IMGFMT_RGB555 with
GLES; at least some of them are not supported in this form, and the
formats aren't important anyway.
2014-12-20 19:23:17 +01:00
wm4 501290da02 vo_opengl_old: fix OSD regression
Commit 0e8fbdbd removed the rg_texture requirement from vo_opengl;
commit 541f6731 changed to a more convenient method. Both commits broke
vo_opengl_old in some ways. vo_opengl_old always requires GL_ALPHA for
single-channel texture, because it draws the OSD without shaders and by
using certain blend modes.

So we need to explicitly distinguish between vo_opengl and vo_opengl_old
in the OSD renderer, and force fixed texture formats for vo_opengl_old.
The other logic is specific to the internals of vo_opengl. (Although it
might be possible to get the same result by playing with the old GL
fixed-function functions in vo_opengl_old. But seems like a waste of
time.)

Fixes #1370.
2014-12-20 18:43:11 +01:00
wm4 a0051b9da2 vo_opengl: add GLES 2 support
Rather basic support. Almost nothing works, and even if it does, it's
bound to be inefficient (due to texture upload). This was tested with
the nVidia desktop binary drivers, which provide GLES 2 support only.
However, nVidia is not known to be very strict about OpenGL, and the
driver is very new too, so the vo_opengl code will have bugs too.
2014-12-19 01:21:19 +01:00
wm4 541f6731a0 vo_opengl: simplify the case without texture_rg
If GL_RED was not available, we used GL_ALPHA. But this is an
unnecessary complication, and it's easier to use GL_LUMINANCE instead.
With the latter, a texture will return the .r component set, and as long
as the shader doesn't look at the other components, the shader doesn't
need any changes.

Some of the changes added in 0e8fbdbd are now unneeeded.

Also, realign the entire gl_byte_formats_legacy table.
2014-12-18 14:46:59 +01:00
wm4 10befa26d9 vo_opengl: GLES 3 support
Tested with MESA on software emulation. Seems to work well, although the
default FBO format in opengl-hq disables most interesting features. I
have no idea how well it will work on real hardware (or if it does at
all).

Unfortunately, some features, including playback of 10 bit video, are
not supported. Not sure what to do about this.

GLES 2 or 1 do not work.
2014-12-17 21:48:23 +01:00
wm4 0e8fbdbdb1 vo_opengl: remove requirement for RG textures
Features not supported are disabled (although with a misleading error
message).
2014-12-16 18:55:20 +01:00
wm4 eca0fcb77a vo_opengl: simplify redraw callback OSD handling
OSD used to be not thread-safe at all, so a track was used to get it
redrawn. This mostly reverts commit 6a2a8880, because OSD not being
thread-safe was the non-trivial part of it.

Mostly untested, because this code path is used on OSX only, and I don't
have OSX.
2014-06-16 01:00:59 +02:00
wm4 716285782d video/out: change aspects of OSD handling
Let the VOs draw the OSD on their own, instead of making OSD drawing a
separate VO driver call. Further, let it be the VOs responsibility to
request subtitles with the correct PTS. We also basically allow the VO
to request OSD/subtitles at any time.

OSX changes untested.
2014-06-15 20:53:15 +02:00
wm4 7f4a09bb85 sub: uglify OSD code path with locking
Do two things:
1. add locking to struct osd_state
2. make struct osd_state opaque

While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses
lots of osd_state (and osd_object) members. To make sure everything is
accessed synchronously, I prefer making osd_state opaque, even if it
means adding pretty dumb accessors.

All of this is meant to allow running VO in their own threads.
Eventually, VOs will request OSD on their own, which means osd_state
will be accessed from foreign threads.
2014-01-18 01:27:43 +01:00
wm4 775e08ba65 vo_opengl: fix alpha values written to the framebuffer
When blending OSD and subtitles onto the video, we write bogus alpha
values. This doesn't normally matter, because these values are normally
unused and discarded. But at least on Wayland, the alpha values are used
by the compositor and leads to transparent windows even with opaque
video on places where the OSD happens to use transparency.

(Also see github issue #338.)

Until now, the alpha basically contained garbage. The source factor
GL_SRC_ALPHA meant that alpha was multiplied with itself. Use GL_ONE
instead (which is why we have to use glBlendFuncSeparate()). This should
give correct results, even with video that has alpha. (Or at least it's
something close to correct, I haven't thought too hard how the
compositor will blend it, and in fact I couldn't manage to test it.)

If glBlendFuncSeparate() is not available, fall back to glBlendFunc(),
which does the same as the code did before this commit. Technically, we
support GL 1.1, but glBlendFuncSeparate is 1.4, and I guess we should
try not to crash if vo_opengl_old runs on a system with GL 1.1 drivers
only.
2013-11-10 03:14:38 +01:00
wm4 1061f43a2f gl_osd: mp_msg conversion 2013-09-12 01:34:42 +02:00
wm4 6a2a8880e9 add a way to resize window contents without VO resize
gl_video_resize_redraw() simply resizes and redraws (but without
invoking swapGlBuffers()). The VO is not involved in any way, so this
can simply be called from inside the mpgl lock from any thread.

Requires a minor refactor of the GL OSD code in order to redraw without
an OSD object.
2013-05-12 15:27:54 +02:00
wm4 d4bdd0473d Rename directories, move files (step 1 of 2) (does not compile)
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.
2012-11-12 20:06:14 +01:00