summaryrefslogtreecommitdiffstats
path: root/video/out/vo_opengl.c
Commit message (Collapse)AuthorAgeFilesLines
* vo: fix disabling/enabling smoothmotion at runtimewm42015-01-231-4/+2
| | | | | | | | | | | | | vo.c queried the VO at initialization whether it wants to be updated on every display frame, or every video frame. If the smoothmotion option was changed at runtime, the rendering mode in vo.c wasn't updated. Just let vo_opengl set the mode directly. Abuse the existing vo_set_flip_queue_offset() function for this. Also add a comment suggesting the use of --display-fps to the manpage, which doesn't have anything to do with the rest of this commit, but is important to make smoothmotion run well.
* vo_opengl: add smoothmotion frame blendingStefano Pigozzi2015-01-231-4/+21
| | | | | | | | | | | | | | | | | | | SmoothMotion is a way to time and blend frames made popular by MadVR. It's intended behaviour is to remove stuttering caused by mismatches between the display refresh rate and the video fps, while preserving the video's original artistic qualities (no soap opera effect). It's supposed to make 24fps video playback on 60hz monitors as close as possible to a 24hz monitor. Instead of drawing a frame once once it's pts has passed the vsync time, we redraw at the display refresh rate, and if we detect the vsync is between two frames we interpolated them (depending on their position relative to the vsync). We actually interpolate as few frames as possible to avoid a blur effect as much as possible. For example, if we were to play back a 1fps video on a 60hz monitor, we would blend at most on 1 vsync for each frame (while the other 59 vsyncs would be rendered as is). Frame interpolation is always done before scaling and in linear light when possible (an ICC profile is used, or :srgb is used).
* video: have a generic context struct for hwdec backendswm42015-01-221-1/+3
| | | | | | | | | | | Before this commit, each hw backend had their own specific struct types for context, and some, like VDA, had none at all. Add a context struct (mp_hwdec_ctx) that provides a somewhat generic way to pass the hwdec context around. Some things get slightly better, some slightly more verbose. mp_hwdec_info is still around; it's still needed, but is reduced to its role of handling delayed loading of the hwdec backend.
* video: remove vfcap.hwm42015-01-211-4/+2
| | | | | | | | | | | | | | | | | And remove all uses of the VFCAP_CSP_SUPPORTED* constants. This is supposed to reduce conversions if many filters are used (with many incompatible pixel formats), and also for preferring the VO's natively supported pixel formats (as opposed to conversion). This is worthless by now. Not only do the main VOs not use software conversion, but also the way vf_lavfi and libavfilter work mostly break the way the old MPlayer mechanism worked. Other important filters like vf_vapoursynth do not support "proper" format negotation either. Part of this was already removed with the vf_scale cleanup from today. While I'm touching every single VO, also fix the query_format argument (it's not a FourCC anymore).
* vo_opengl: cleanups after vo_opengl_old removalwm42015-01-211-1/+1
| | | | | | | | | | | | | 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.
* vo_opengl: fix typowm42015-01-201-1/+1
|
* vo_opengl: don't crash win32 backend with NULL eventswm42015-01-081-7/+7
| | | | | | | | | vo_opengl was crashing since f811348d because it passed NULL for the events parameter to vo_control. Normally the parameter should not be NULL, so add a hack to account for this. In particular, we should handle the events that are returned. For the call in preinit() we skip this, but it most likely has no meaning anyway, because in this stage no window is visible yet.
* vo_opengl: gl_lcms: implement change detection for memory profileswm42015-01-081-0/+2
| | | | | | | | | | This affects OSX, where memory profiles are updated e.g. on fullscreen switches. The profile most likely doesn't change, but the LUT will be generated and reloaded anyway. Somewhat of a regression from commit f811348. Fixes #1439.
* vo_opengl: add support for in memory icc profilesStefano Pigozzi2015-01-071-15/+16
| | | | | | | | | | | Previously we just forced loading a profile from file, but that has poor integration for querying the OS / display server for an ICC profile, and generating profiles on the fly (which we might use in the future for creating preset 3dluts). Also changed the previous icc-profile-auto code to use this mechanism, and moved gl_lcms to be an opaque type with state instead of just providing pure functions.
* vo_opengl_cb: implement equalizer controlswm42015-01-061-3/+6
| | | | | | | | | | | | | | | | This makes vo_opengl_cb respond to controls like "gamma" and "brightness". The commit includes an awkward refactor for vo_opengl to make it easier for vo_opengl_cb. One problem is a logical race condition. The set of supported controls depends on the pixelformat, which in turn is set by reconfig(). But the actual reconfig() call (on the renderer) happens asynchronously on the renderer thread. At the time it happens, the player most likely already tried to set some controls for command line options (see init_vo() in video.c). So setting this command line options will fail most of the time, though it could randomly succeed. This can't be fixed directly, because the player can't wait on the renderer thread, because the renderer thread might already wait on the player.
* vo_opengl: make use of newer OpenGL logging APIwm42014-12-231-1/+1
| | | | | | GL_ARB_debug_output provides a logging callback, which can be used to diagnose problems etc. in case the driver supports it. It's enabled only if the vo_opengl "debug" suboption is set.
* vo_opengl, vo_opengl_cb: check GL version in rendererwm42014-12-221-0/+2
| | | | | | vo_opengl actually checks this in the context creation code already, but it still increases robustness in case the requirements are changed later.
* vo_opengl: better probe handlingwm42014-12-191-4/+3
| | | | | | | | | | | | | Involve detection of software renderers in the probing properly. Other VOs could handle probing also more gracefully, and e.g. produce less noise if an API is unavailable. (Although other than the OpenGL VOs, only vo_wayland will.) Now the "sw" suboption for vo_opengl[_old] is strictly speaking not needed anymore. Doing "--vo=opengl" disables the probing logic, and will always force it, if possible. Includes some simplifications as well.
* vo_opengl: remove icc profile options from runtime-settable optionswm42014-12-161-16/+14
| | | | | | | | | | | | | | | | | | Because of the icc-profile-auto option (which was added at a later point), supporting this would probably be slightly messy: the ICC profile can spontaneously update, and then it would overwrite the previously set options. Don't make icc-profile-auto fatal if unsupported. The "auto" indicates that it will use whatever it finds, even if it's nothing. Also add a warning; before this commit, it just refused to initialize without explanation. As a mostly unrelated cosmetic change, remove redundant parameters which had no point anymore. Probably fixes #1359 (or rather works it around by disallowing it).
* vo_opengl: remove requirement for RG textureswm42014-12-161-1/+1
| | | | | Features not supported are disabled (although with a misleading error message).
* vo_opengl: remove quadbuffer/anaglyph stereo 3D renderingwm42014-12-151-3/+0
| | | | | | | | Obscure feature, and I've never heard of anyone using it. The anaglyph effects can be reproduced with vf_stereo3d. The only thing that can't be reproduced with it is "quadbuffer", which requires special and expensive hardware.
* client API: expose OpenGL rendererwm42014-12-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds API to libmpv that lets host applications use the mpv opengl renderer. This is a more flexible (and possibly more portable) option to foreign window embedding (via --wid). This assumes that methods like context sharing and multithreaded OpenGL rendering are infeasible, and that a way is needed to integrate it with an application that uses a single thread to render everything. Add an example that does this with QtQuick/qml. The example is relatively lazy, but still shows how relatively simple the integration is. The FBO indirection could probably be avoided, but would require more work (and would probably lead to worse QtQuick integration, because it would have to ignore transformations like rotation). Because this makes mpv directly use the host application's OpenGL context, there is no platform specific code involved in mpv, except for hw decoding interop. main.qml is derived from some Qt example. The following things are still missing: - a way to do better video timing - expose GL renderer options, allow changing them at runtime - support for color equalizer controls - support for screenshots
* vo_opengl: make uninit idempotentwm42014-12-031-6/+3
|
* vo_opengl: move hwdec parts into their own fileswm42014-12-031-46/+6
| | | | | | This wasn't done before because there was no advantage in "abstracting" it. This changed, and putting this into its own files is better than messing it into gl_common.c/h.
* vdpau/GLX: don't access VO backendwm42014-12-031-1/+0
| | | | | | | | | Same as with the previous commits. In theory, vdpau/x11 GL interop doesn't assume GLX. It could use EGL as well. But since it's always GLX in practice, so we're fine with this. Remove the gl_hwdec.mpgl field - it's unused now.
* vda: make independent from cocoa backendwm42014-12-031-0/+1
| | | | | | | | | Basically, don't access the vo field. There's also no reason anymore to access MPGLContext. We still need to access loaded GL functions though, so add a field for that to gl_hwdec. Untested.
* vo_opengl: minor changeswm42014-12-021-2/+2
| | | | | | | | | | | | | | Always set the viewport on entry. The way the viewport is tracked is a bit complicated in my opinion, and in fact it doesn't even reduce the number of GL calls. Setting it on entry is actually redundant if video covers the screen fully, because the handle_pass() unconditionally sets it anyway, but avoiding it would complicate the cases gl->Clear() is actually needed. Add a fbo argument to gl_video_render_frame(). This allows you to render into a FBO rather than the default framebuffer. It will be useful for providing an API to render on an external GL context. (If that will actually be added.)
* gl_common: factor context creationwm42014-11-261-22/+17
| | | | | | | Always create the context in mpgl_init(), instead of doing it when mpgl_config_window() is called the first time. This is a small step towards cleaning up the GL backend interface, and adding other things like perhaps GLES support, or a callback-driven backend for libmpv.
* vo_opengl: initialize renderer after setting sizewm42014-11-071-2/+2
| | | | | | | | | | | This silences the warning: video/out/gl_video.c:1091:51: runtime error: division by zero when running with clang -fsanitize=undefined. Division by zero is legal according to IEEE, but I guess clang doesn't care about standard. While triggering this warning isn't actually avoided in all cases, it's avoided in the common case and also makes people shut up about it.
* command: make window-scale property observablewm42014-11-021-0/+1
| | | | | | | | | | | | Add a generic mechanism to the VO to relay "extra" events from VO to player. Use it to notify the core of window resizes, which in turn will be used to mark all affected properties ("window-scale" in this case) as changed. (I refrained from hacking this as internal command into input_ctx, or to poll the state change, etc. - but in the end, maybe it would be best to actually pass the client API context directly to the places where events can happen.)
* cocoa: reintroduce async resizeStefano Pigozzi2014-10-181-0/+11
| | | | | | | After removing synchronous libdispatch calls, this looks like it doesn't deadlock anymore. I also experimented with pthread_mutex_trylock liek wm4 suggested, but it leads to some annoying black flickering. I will fallback to that only if some new deadlocks are discovered.
* cocoa: move to a simpler threading modelStefano Pigozzi2014-10-041-11/+0
| | | | | | | | | | | | | | Unfortunately using dispatch_sync for synchronization turned out to be really bad for us. It caused a wide array of race conditions, deadlocks, etc. Moving to a very simple mutex. It's not clear to me how to do liveresizing with this, for now it just flickers with is unacceptable (maybe I'll draw black instead). This should fix all the threading cocoa bugs. Reopen if it's not the case! Fixes #751 Fixes #1129
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-291-1/+1
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* vo_opengl: add check-pattern suboption for testingwm42014-08-181-2/+28
| | | | | | | | | | | | | | | | This uses glXGetVideoSyncSGI() to check how many vsyncs happened since the last flip_page() call. It allows checking a pattern of vsync increments of at most 2 elements. For example, to check ~24 fps playback on a ~60 Hz monitor, this can be used: --vo=opengl:check-pattern=[3-2]:waitvsync Whether the reported results are accurate or just plain wrong may depend on the driver and if the waitvsync sub-option is used. There are no guarantees. This option is undocumented, and may be removed again in the near or distant future.
* vo_opengl: optional support for using GLX_SGI_video_syncwm42014-08-151-1/+19
| | | | | | | | | I'm not sure about the merit, though it does print nice numbers if debug output is enabled. Basically, this tries to achieve similar results as the glFinish() business, but again it entirely depends on the drivers whether this does anything meaningful, or whether it's actively harmful.
* vo_opengl: if glfinish is used, also call it after swapppingwm42014-08-151-0/+3
| | | | | | It seems that at least on nvidia systems with composting disabled, we can get it to block deterministically on the actual vsync event, which should improve framedropping.
* video: move display and timing to a separate threadwm42014-08-121-5/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The VO is run inside its own thread. It also does most of video timing. The playloop hands the image data and a realtime timestamp to the VO, and the VO does the rest. In particular, this allows the playloop to do other things, instead of blocking for video redraw. But if anything accesses the VO during video timing, it will block. This also fixes vo_sdl.c event handling; but that is only a side-effect, since reimplementing the broken way would require more effort. Also drop --softsleep. In theory, this option helps if the kernel's sleeping mechanism is too inaccurate for video timing. In practice, I haven't ever encountered a situation where it helps, and it just burns CPU cycles. On the other hand it's probably actively harmful, because it prevents the libavcodec decoder threads from doing real work. Side note: Originally, I intended that multiple frames can be queued to the VO. But this is not done, due to problems with OSD and other certain features. OSD in particular is simply designed in a way that it can be neither timed nor copied, so you do have to render it into the video frame before you can draw the next frame. (Subtitles have no such restriction. sd_lavc was even updated to fix this.) It seems the right solution to queuing multiple VO frames is rendering on VO-backed framebuffers, like vo_vdpau.c does. This requires VO driver support, and is out of scope of this commit. As consequence, the VO has a queue size of 1. The existing video queue is just needed to compute frame duration, and will be moved out in the next commit.
* video: don't keep multiple pointers to hwdec info structwm42014-08-111-17/+14
| | | | This makes a certain corner case simpler at a later point.
* vo_opengl: simplify redraw callback OSD handlingwm42014-06-161-2/+0
| | | | | | | | | 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.
* video/out: change aspects of OSD handlingwm42014-06-151-14/+3
| | | | | | | | | 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.
* video/out: remove unused config() parameterswm42014-05-071-5/+4
| | | | This was cleaned up yesterday.
* vo_opengl: support rotationwm42014-04-211-0/+4
| | | | | | | | | | | This turned out much more complicated than I thought. It's not just a matter of adjusting the texture coordinates, but you also have to consider separated scaling and panscan clipping, which make everything complicated. This actually still doesn't clip 100% correctly, but the bug is only visible when rotating (or flipping with --vf=flip), and using something like --video-pan-x/y at the same time.
* vo_opengl, cocoa: allow to autoselect a color profileStefano Pigozzi2014-03-311-1/+24
| | | | | | | | | | | | | This commit adds support for automatic selection of color profiles based on the display where mpv is initialized, and automatically changes the color profile when display is changed or the profile itself is changed from System Preferences. @UliZappe was responsible with the testing and implementation of a lot of this commit, including the original implementation of `cocoa_get_icc_profile_path` (See #594). Fixes #594
* video/out: remove legacy colorspace stuffwm42014-03-291-2/+2
| | | | | | | | | Reduce most dependencies on struct mp_csp_details, which was a bad first attempt at dealing with colorspace stuff. Instead, consistently use mp_image_params. Code which retrieves colorspace matrices from csputils.c still uses this type, though.
* vo_opengl: runtime icc profile switchingwm42014-03-241-15/+29
| | | | | The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
* m_option, m_config: mp_msg conversionswm42013-12-211-1/+2
| | | | | | | | Always pass around mp_log contexts in the option parser code. This of course affects all users of this API as well. In stream.c, pass a mp_null_log, because we can't do it properly yet. This will be fixed later.
* video/out: pass along global contextwm42013-12-211-1/+1
| | | | Will be needed for other parts (especially in gl_lcms.c).
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-3/+3
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-1/+1
| | | | | | | | | Since m_option.h and options.h are extremely often included, a lot of files have to be changed. Moving path.c/h to options/ is a bit questionable, but since this is mainly about access to config files (which are also handled in options/), it's probably ok.
* video: remove --flipwm42013-12-051-1/+1
| | | | | | | | | | | | | | | | The --flip option flipped the image upside-down, by trying to use VO support, or if not available, by inserting a video filter. I'm not sure why it existed. Maybe it was important in ancient times when VfW based decoders output an image this way (but even then, flipping an image is a free operation by negating the stride). One nice thing about this is that it provided a possible path for implementing video orientation, which is a feature we should probably support eventually. The important part is that it would be for free for VOs that support it, and would work even with hardware decoding. But for now get rid of it. It's useless, trivial, stands in the way, and supporting video orientation would require solving other problems first.
* vo_opengl: add support for rectangle textureswm42013-12-011-0/+1
| | | | | | | | | This allows vo_opengl to use GL_TEXTURE_RECTANGLE textures, either by enabling it with the 'rectangle-textures' sub-option, or by having a hwdec backend force it. By default it's off. The _only_ reason we're adding this is because VDA can export rectangle textures only.
* Rename sub.c/.h to osd.c/.hwm42013-11-241-1/+1
| | | | | This was way too misleading. osd.c merely calls the subtitle renderers, instead of actually dealing with subtitles.
* video: move struct mp_hwdec_info into its own header filewm42013-11-231-1/+1
| | | | | | | | This means most code accessing this struct must now include hwdec.h instead of dec_video.h. I just put it into dec_video.h at first because I thought a separate file would be a waste, but it's more proper to do it this way, as there are too many files which include dec_video.h only to get the mp_hwdec_info definition.
* vo_opengl: fix compilationwm42013-11-221-2/+2
| | | | Never do a trivial change while drunk and without actually testing it.
* vo_opengl: initialize all fields for VFCTRL_GET_HWDEC_INFOwm42013-11-221-4/+8
| | | | | | This initialized only the load_api and load_api_ctx fields, and left the other fields as they were. This failed with vf_vavpp, which assumed all fields are initialized.
* vo_opengl: add infrastructure for hardware decoding OpenGL interopwm42013-11-041-1/+72
| | | | | | | | | | | | 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.
* m_config: refactor option defaults handlingwm42013-10-241-4/+7