summaryrefslogtreecommitdiffstats
path: root/video/out/gl_common.c
Commit message (Collapse)AuthorAgeFilesLines
* gl_common: print SW renderer warning only if it was the only reason we ↵wm42013-11-141-1/+1
| | | | rejected it
* vo_opengl: fix alpha values written to the framebufferwm42013-11-101-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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.
* vo_opengl: support for vdpau hardware decodingwm42013-11-051-0/+21
| | | | | | | | | | | | This uses vdpau OpenGL interop to convert a vdpau surface to a texture. Note that this is a bit weak and primitive. Deinterlacing (or any other form of vdpau postprocessing) is not supported. vo_opengl chroma scaling and chroma sample position are not supported. Internally, the vdpau video surfaces are converted to a RGBA surface first, because using the video surfaces directly is too complicated. (These surfaces are always split into separate fields, and the vo_opengl core expects progressive frames or frames with weaved fields.)
* Merge branch 'master' into have_configurewm42013-11-041-0/+9
|\ | | | | | | | | Conflicts: configure
| * vo_opengl: add support for VA-API OpenGL interopwm42013-11-041-0/+5
| | | | | | | | | | | | | | | | VA-API's OpenGL/GLX interop is pretty bad and perhaps slow (renders a X11 pixmap into a FBO, and has to go over X11, probably involves one or more copies), and this code serves more as an example, rather than for serious use. On the other hand, this might be work much better than vo_vaapi, even if slightly slower.
| * vo_opengl: add infrastructure for hardware decoding OpenGL interopwm42013-11-041-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | Most hardware decoding APIs provide some OpenGL interop. This allows using vo_opengl, without having to read the video data back from GPU. This requires adding a backend for each hardware decoding API. (Each backend is an entry in gl_hwdec_vaglx[].) The backends expose video data as a set of OpenGL textures. Add infrastructure to support this. The next commit will add support for VA-API.
* | configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-6/+6
|/ | | | | | | | | | | | | | | | | | | | | The configure followed 5 different convetions of defines because the next guy always wanted to introduce a new better way to uniform it[1]. For an hypothetic feature 'hurr' you could have had: * #define HAVE_HURR 1 / #undef HAVE_DURR * #define HAVE_HURR / #undef HAVE_DURR * #define CONFIG_HURR 1 / #undef CONFIG_DURR * #define HAVE_HURR 1 / #define HAVE_DURR 0 * #define CONFIG_HURR 1 / #define CONFIG_DURR 0 All is now uniform and uses: * #define HAVE_HURR 1 * #define HAVE_DURR 0 We like definining to 0 as opposed to `undef` bcause it can help spot typos and is very helpful when doing big reorganizations in the code. [1]: http://xkcd.com/927/ related
* gl_common: suggest --vo=opengl-old if OpenGL 2.1 missingwm42013-10-261-1/+6
| | | | | | | If the caller requests at least OpenGL 2.1 (which --vo=opengl does), but we get OpenGL 1.x, suggest using opengl-old. Based on a patch by pfor on IRC.
* gl_common: add wayland backend before x11 backendAndreas Sinz2013-09-161-3/+5
|
* gl_common: signal to GL backend whether we are probingwm42013-09-161-4/+7
| | | | | | | | | | | This is supposed to reduce the amount of useless error messages shown during initialization of vo_opengl. If multiple backends are compiled, usually only one of them will work. For example, on Linux both X and Wayland backends can be compiled, but usually either Wayland or X is running. Then, if Wayland is not running, but X is, trying to initialize the Wayland backend should not spam the terminal with error messages. Signed-off-by: Andreas Sinz <andreas.sinz@aon.at>
* gl_common: complete mp_msg conversionwm42013-09-121-29/+28
| | | | Hopefully this works on Wayland and Cocoa, which I didn't test.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* video/out: use new mp_msg stuff for vo.c and vo_openglwm42013-07-311-2/+2
| | | | The first step; also serves as example.
* vo_opengl: some option changeswm42013-07-221-0/+8
| | | | | | Doing "mpv --vo=opengl:lscale=help" now lists possible scalers and exits. The "backend" suboption behaves similar. Make the "stereo" suboption a choice, instead of using magic integer values.
* vo_opengl_old: use new option APIwm42013-07-221-0/+8
|
* gl_common: fix invalid alignmentwm42013-05-301-2/+2
| | | | | | | | 0 is invalid. The intention of the code turning off any additional alignment, so we need 1. Change a comment: obviously we don't try to set alignment parameters etc.to handle stride correctly, and instead do everything by row.
* gl_video: improve ditheringwm42013-05-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | Use a different algorithm to generate the dithering matrix. This looks much better than the previous ordered dither matrix with its cross-hatch artifacts. The matrix generation algorithm as well as its implementation was contributed by Wessel Dankers aka Fruit. The code in dither.c is his implementation, reformatted and with static global variables removed by me. The new matrix is uploaded as float texture - before this commit, it was a normal integer fixed point matrix. This means dithering will be disabled on systems without float textures. The size of the dithering matrix can be configured, as the matrix is generated at runtime. The generation of the matrix can take rather long, and is already unacceptable with size 8. The default is at 6, which takes about 100 ms on a Core2 Duo system with dither.c compiled at -O2, which I consider just about acceptable. The old ordered dithering is still available and can be selected by putting the dither=ordered sub-option. The ordered dither matrix generation code was moved to dither.c. This function was originally written by Uoti Urpala.
* gl_common: add some sort of locking APIwm42013-05-121-0/+27
| | | | | | | | | Some OpenGL implementations on some platforms require that a context is current only on one thread. For this reason, mpgl_lock() and mpgl_unlock() take care of this as well for convenience. Each backend that needs thread safety should provide it's own locking strategy inside of `set_current`.
* vo_opengl: split into multiple files, convert to new option APIwm42013-03-281-0/+6
| | | | | | gl_video.c contains all rendering code, gl_lcms.c the .icc loader and creation of 3D LUT (and all LittleCMS specific code). vo_opengl.c is reduced to interfacing between the various parts.
* gl_common: split into platform specific fileswm42013-03-281-786/+43
| | | | | | | | | | | Do this instead of stuffing all x11/cocoa/win32/wayland specific code into gl_common.c. The cocoa specific parts could probably go directly into cocoa_common.m, possibly same with wayland. Also redo how the list of backends is managed. Get rid of the GLTYPE_ constants. Instead of having a big switch() on GLTYPE_, each backend entry has a function pointer to setup the MPGLContext callback (e.g. mpgl_set_backend_x11()).
* video: remove aspect.h includes from files which don't need itwm42013-03-171-1/+0
|
* wayland: remove asserts from egl_create_contextAlexander Preisinger2013-03-131-17/+7
| | | | | Instead of assert return false on most check. Removes the redundant second inclusion of the assert header.
* wayland: simplify egl_create_windowAlexander Preisinger2013-03-131-13/+4
| | | | | | 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.
* wayland: remove unnecessary function pointersAlexander Preisinger2013-03-041-10/+1
| | | | Remove the usage of getdladdr as it only adds to code complexity
* gl_common: get rid of symbol redefinition warnings with recent Mesawm42013-03-031-0/+4
| | | | | | | | | | | | | 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.
* vo_opengl: don't destroy VOFLAG_HIDDEN windowwm42013-03-031-18/+1
| | | | | | | 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.
* wayland: add wayland supportAlexander Preisinger2013-02-281-1/+273
| | | | | | | | | | | | | | | | | | | | | 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)
* video/out: rename create_window to config_windowwm42013-02-261-11/+11
| | | | | | 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.
* gl_common: simplify window/context creationwm42013-02-261-201/+181
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* gl_common: remove compatibility aliases for backend sub-optionwm42013-02-261-6/+0
| | | | | | 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.
* x11: simplify handling of X Visuals and Colormaps in VOswm42013-01-271-8/+2
| | | | | | | | | | | | | | | | | Don't force VOs to pick an arbitrary default Visual and Colormap. They still can override them if needed. This simplifies the X11 VO interface. Always create a Colormap for simplicity. Using CopyFromParent fails if the selected visual is not the same of that of the parent window, which happens for me with vo_opengl. vo_vdpau and vo_xv explicitly set CWBorderPixel, do that in x11_common instead (it was already done for native windows, but not for slave mode windows). What gl_common did was incorrect in theory: freeing a colormap while a window uses it will change the colormap of the window to "None", and the color mapping for such windows is "undefined".
* x11: cleanup, refactorwm42013-01-271-2/+2
| | | | | | | | | | | | | | | | Move things that are used by vo_xv only into vo_xv, same for vo_x11. Rename some functions exported by x11_common, like vo_init to vo_x11_common. Make functions not used outsode of x11_common.c private to that file. Eliminate all global variables defined by x11_common (except error handler and colormap stuff). There shouldn't be any functional changes, and only code is moved around. There are some minor simplifications in the X11 init code, as we completely remove the ability to initialize X11 and X11+VO separately (see commit b4d9647 "mplayer: do not create X11 state in player frontend"), and the respective functions are conflated into vo_x11_init() and vo_x11_uninit().
* gl_common: move things used by vo_opengl_old.c only to vo_opengl_old.cwm42013-01-131-1155/+0
| | | | Having this in gl_common is confusing.
* video: remove img_format compat hackswm42013-01-131-14/+6
| | | | | | | | | | | | | | | | | Remove the strange things the old mp_image_setfmt() code did to the image format parameters. This includes setting chroma shift to 31 for gray (Y8) formats and more. Y8 + vo_opengl_old didn't actually work for unknown reasons (regression in this branch). Fix this. The difference is that Y8 is now interpreted as gray RGB (LUMINANCE texture) instead of involving YUV (and levels) conversion. Get rid of distinguishing RGB and BGR. There wasn't really any good reason for this. Remove mp_get_chroma_shift() and IMGFMT_IS_YUVP16*(). mp_imgfmt_desc gives the same information and more.
* video: decouple internal pixel formats from FourCCswm42013-01-131-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mplayer's video chain traditionally used FourCCs for pixel formats. For example, it used IMGFMT_YV12 for 4:2:0 YUV, which was defined to the string 'YV12' interpreted as unsigned int. Additionally, it used to encode information into the numeric values of some formats. The RGB formats had their bit depth and endian encoded into the least significant byte. Extended planar formats (420P10 etc.) had chroma shift, endian, and component bit depth encoded. (This has been removed in recent commits.) Replace the FourCC mess with a simple enum. Remove all the redundant formats like YV12/I420/IYUV. Replace some image format names by something more intuitive, most importantly IMGFMT_YV12 -> IMGFMT_420P. Add img_fourcc.h, which contains the old IDs for code that actually uses FourCCs. Change the way demuxers, that output raw video, identify the video format: they set either MP_FOURCC_RAWVIDEO or MP_FOURCC_IMGFMT to request the rawvideo decoder, and sh_video->imgfmt specifies the pixel format. Like the previous hack, this is supposed to avoid the need for a complete codecs.cfg entry per format, or other lookup tables. (Note that the RGB raw video FourCCs mostly rely on ffmpeg's mappings for NUT raw video, but this is still considered better than adding a raw video decoder - even if trivial, it would be full of annoying lookup tables.) The TV code has not been tested. Some corrective changes regarding endian and other image format flags creep in.
* video: cleanup: replace old mp_image function nameswm42013-01-131-1/+1
| | | | | mp_image_alloc() also changes argument order compared to alloc_mpi(). The format now comes first, then width/height.
* vo_opengl_old: reject 9-15 bit formats if textures have less than 16 bitwm42012-12-281-0/+1
| | | | | | | | | | | | | | | | | | | 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.)
* gl_common: properly reject old OpenGL versionswm42012-12-281-11/+20
| | | | | | | | | | | | | | | | | | | 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.)
* gl_common: improve Mesa compatibility for GL3 context creationwm42012-11-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* win32: remove pointless get/release DC wrapperswm42012-11-121-5/+5
|
* Rename directories, move files (step 2 of 2)wm42012-11-121-2/+1
| | | | | | | | | | | | 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.)
* Rename directories, move files (step 1 of 2) (does not compile)wm42012-11-121-0/+2654
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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-06 20:30:35 +0000