summaryrefslogtreecommitdiffstats
path: root/video/out/vo_x11.c
Commit message (Collapse)AuthorAgeFilesLines
* sws_utils: don't force callers to provide option structwm42018-01-181-1/+1
| | | | | | | mp_sws_set_from_cmdline() has the only purpose to respect the --sws- command line options. Instead of forcing callers to get the option struct containing these, let callers pass mpv_global, and get it from the option core code directly. This avoids minor annoyances later on.
* video: avoid some unnecessary vf.h includeswm42018-01-181-1/+0
|
* build: remove POSIX/sysv shared memory testwm42017-12-021-28/+13
| | | | | | vo_x11 and vo_xv need this. According to the Linux manpage, all involved functions are POSIX-2001 anyway. (I just assumed they were not, because they're mostly System V UNIX legacy garbage.)
* build: make various x11 protocol extension libs mandatorywm42017-04-211-7/+7
| | | | | | | Reduces the ifdeffery, which is good and will avoid silent breakages, or weird behavior if a lib is omitted. Also reorder the x11_common.c include statements.
* vo_x11: fix an unused variable warningwm42017-03-241-1/+0
|
* vo_x11: reduce flickering on playlist navigationrr-2017-03-241-2/+7
| | | | | | | | | | The delay between call to .resize, which cleared the buffer, and actually rendering the first video frame, was significant, resulting in short flicker on navigation and resizing. This was especially visible when zooming and navigating between images. Now the clearing is scheduled to happen just before the rendering, which looks to be good enough even without double buffering.
* vo_x11: fix some ifdefferywm42016-09-131-2/+2
| | | | This failed to compile when xext was not available.
* vo: remove unused VOCTRL_GET_PANSCANwm42016-09-081-2/+0
| | | | | | It was used to determine whether the VO supports VOCTRL_SET_PANSCAN. With all those changes to property semantics this became unnecessary, and its only use was dropped at some point.
* x11: stop using vo.event_fdwm42016-07-201-0/+2
| | | | Instead let it do its own event loop wakeup handling.
* vo_xv, vo_x11: fix typos in warningsJakub Wilk2016-07-091-2/+2
|
* vo_xv, vo_x11: warn that these VOs should not be usedwm42016-03-061-0/+2
|
* vo_x11: add 16bpp supportGusar3212016-02-221-0/+1
|
* video: switch from using display aspect to sample aspectwm42015-12-191-2/+2
| | | | | | | | | | | | | | | | MPlayer traditionally always used the display aspect ratio, e.g. 16:9, while FFmpeg uses the sample (aka pixel) aspect ratio. Both have a bunch of advantages and disadvantages. Actually, it seems using sample aspect ratio is generally nicer. The main reason for the change is making mpv closer to how FFmpeg works in order to make life easier. It's also nice that everything uses integer fractions instead of floats now (except --video-aspect option/property). Note that there is at least 1 user-visible change: vf_dsize now does not set the display size, only the display aspect ratio. This is because the image_params d_w/d_h fields did not just set the display aspect, but also the size (except in encoding mode).
* video/out: remove an unused parameterwm42015-10-031-1/+1
| | | | | | | | | | | This parameter has been unused for years (the last flag was removed in commit d658b115). Get rid of it. This affects the general VO API, as well as the vo_opengl backend API, so it touches a lot of files. The VOFLAGs are still used to control OpenGL context creation, so move them to the OpenGL backend code.
* x11: separate window creation and configurationwm42015-09-301-2/+4
| | | | | | | | | | | | | | | | | | | This gets rid of an old hack, VOFLAG_HIDDEN. Although handling of it has been sane for a while, it used to cause much pain, and is still unintuitive and weird even today. The main reason for this hack is that OpenGL selects a X11 Visual for you, and you're supposed to use this Visual when creating the X window for the OpenGL context. Which means the X window can't be created early in the common X11 init code, but the OpenGL code needs to do something before that. API-wise you need separate functions for X11 init and X11 window creation. The VOFLAG_HIDDEN hack conflated window creation and the entrypoint for resizing on video resolution change into one function, vo_x11_config_vo_window(). This required all platform backends to handle this flag, even if they didn't need this mechanism. Wayland still uses this for minor reasons (alpha support?), so the wayland backend must be changed before the flag can be entirely removed.
* Revert "vo_x11: remove this video output"wm42015-09-301-0/+448
| | | | | | | | | | | | | | | This reverts commit d11184a256ed709a03fa94a4e3940eed1b76d76f. Unfortunately, there was a lot of unexpected resistance. Do note that this is still extremely slow, crappy, etc. Note that vo_x11.c was further edited. Compared to the removed vo_x11.c, an additional ~200 lines of code was removed in order to simplify it. I tried to strip it down as much as possible. In particular, support for odd non-32 bit formats (24, 16, 15, 8 bit) is dropped. Closes #2300.
* vo_x11: remove this video outputwm42015-06-261-633/+0
| | | | | | | It only causes additional maintenance work. Even if you wanted to have a fallback, it's probably better to use --vo=sdl or so.
* Update license headersMarcin Kurczewski2015-04-131-6/+5
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo: simplify VOs by adding generic screenshot supportwm42015-01-241-13/+0
| | | | | | | | | | | At the time screenshot support was added, images weren't refcounted yet, so screenshots required specialized implementations in the VOs. But now we can handle these things much simpler. Also see commit 5bb24980. If there are VOs in the future which can't do this (e.g. they need to write to the image passed to vo_driver->draw_image), this still could be disabled on a per-VO basis etc., so we lose no potential performance advantages.
* video: separate screenshot modeswm42015-01-231-4/+2
| | | | | | | | | Use different VOCTRLs for "window" and normal screenshot modes. The normal one will probably be removed, and replaced by generic code in vo.c, and this commit is preparation for this. (Doing it the other way around would be slightly simpler, but I haven't decided yet about the second one, and touching every VO is needed anyway in order to remove the unneeded crap. E.g. has_osd has been unused for a long time.)
* video: remove vfcap.hwm42015-01-211-11/+4
| | | | | | | | | | | | | | | | | 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_x11: don't attempt to resize when unconfiguredwm42014-12-141-2/+3
| | | | | | Fixes #1347. The previous commit actually fixes the crash.
* vo_x11: check allocation errorswm42014-12-141-3/+10
| | | | Avoids a crash if allocation fails.
* Do not call strerror()wm42014-11-261-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | ...because everything is terrible. strerror() is not documented as having to be thread-safe by POSIX and C11. (Which is pretty much bullshit, because both mandate threads and some form of thread-local storage - so there's no excuse why implementation couldn't implement this in a thread-safe way. Especially with C11 this is ridiculous, because there is no way to use threads and convert error numbers to strings at the same time!) Since we heavily use threads now, we should avoid unsafe functions like strerror(). strerror_r() is in POSIX, but GNU/glibc deliberately fucks it up and gives the function different semantics than the POSIX one. It's a bit of work to convince this piece of shit to expose the POSIX standard function, and not the messed up GNU one. strerror_l() is also in POSIX, but only since the 2008 standard, and thus is not widespread. The solution is using avlibc (libavutil, by its official name), which handles the unportable details for us, mostly. We avoid some pain.
* 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.)
* malloc+memset(0) to callocBruno George de Moraes2014-09-051-4/+2
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_x11: fix build with older Libav versionswm42014-07-281-4/+4
| | | | Why does this happen everytime...
* vo: different hack for VOs which need to mangle mouse inputwm42014-07-271-12/+3
| | | | | | | | Follow up on commit 760548da. Mouse handling is a bit confusing, because there are at least 3 coordinate systems associated with it, and it should be cleaned up. But that is hard, so just apply a hack which gets the currently-annoying issue (VO backends needing access to the VO) out of the way.
* vo: hack to avoid threading issues with mouse inputwm42014-07-261-0/+1
| | | | | | VO backends which are or will run in their own thread have a problem with vo_mouse_movement() calling vo_control(). Restrict this to VOs which actually need this.
* video/out: fix redrawing with no video frame for some VOswm42014-06-181-13/+2
| | | | | | With the change to merge osd drawing into video frame drawing, some bogus logic got in: they skipped drawing the OSD if no video frame is available. This broke --no-video --force-window mode.
* vo: make draw_image and vo_queue_image transfer image ownershipwm42014-06-171-1/+4
| | | | Basically a cosmetic change. This is probably more intuitive.
* video: introduce failure path for image allocationswm42014-06-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Until now, failure to allocate image data resulted in a crash (i.e. abort() was called). This was intentional, because it's pretty silly to degrade playback, and in almost all situations, the OOM will probably kill you anyway. (And then there's the standard Linux overcommit behavior, which also will kill you at some point.) But I changed my opinion, so here we go. This change does not affect _all_ memory allocations, just image data. Now in most failure cases, the output will just be skipped. For video filters, this coincidentally means that failure is treated as EOF (because the playback core assumes EOF if nothing comes out of the video filter chain). In other situations, output might be in some way degraded, like skipping frames, not scaling OSD, and such. Functions whose return values changed semantics: mp_image_alloc mp_image_new_copy mp_image_new_ref mp_image_make_writeable mp_image_setrefp mp_image_to_av_frame_and_unref mp_image_from_av_frame mp_image_new_external_ref mp_image_new_custom_ref mp_image_pool_make_writeable mp_image_pool_get mp_image_pool_new_copy mp_vdpau_mixed_frame_create vf_alloc_out_image vf_make_out_image_writeable glGetWindowScreenshot
* video/out: change aspects of OSD handlingwm42014-06-151-10/+2
| | | | | | | | | 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: synchronize mpv rgb pixel format names with ffmpeg nameswm42014-06-141-24/+24
| | | | | | | | | | | This affects packed RGB formats up to 16 bits per pixel. The old mplayer names used LSB-to-MSB order, while FFmpeg (and some other libraries) use MSB-to-LSB. Nothing should change with this commit, i.e. no bit order or endian bugs should be added or fixed. In some cases, the name stays the same, even though the byte order changes, e.g. RGB8->BGR8 and BGR8->RGB8, and this affects the user-visible names too; this might cause confusion.
* options: remove global variables for swscale options; rename themwm42014-06-111-1/+1
| | | | | | Additionally to removing the global variables, this makes the options more uniform. --ssf-... becomes --sws-..., and --sws becomes --sws- scaler. For --sws-scaler, use choices instead of magic integer values.
* x11: fix a warning with --disable-xextJerome Leclanche2014-05-221-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* x11: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-061-1/+1
| | | | See previous commit.
* sub: uglify OSD code path with lockingwm42014-01-181-1/+1
| | | | | | | | | | | | | | | 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.
* video/out: remove pointless x/y parameter from vo_x11_config_vo_windowwm42014-01-111-2/+1
| | | | | This never made any real sense; the "backend" has to access vo->dx/dy anyway.
* vo_x11/vo_xv: fix build when using --disable-xextStefano Pigozzi2013-12-251-5/+5
|
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* 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.
* 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.
* configure: uniform the defines to #define HAVE_xxx (0|1)Stefano Pigozzi2013-11-031-7/+7
| | | | | | | | | | | | | | | | | | | | | 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
* video/out: remove useless info struct and redundant fieldswm42013-10-231-6/+4
| | | | The author and comment fields were printed only in -v mode.
* vo_x11, vo_xv: fix OSD redrawing with --force-windowwm42013-10-061-12/+13
| | | | The window wasn't cleared in this mode before doing the redrawing.
* video/out: always support redrawing VO window at any pointwm42013-10-021-2/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before, a VO could easily refuse to respond to VOCTRL_REDRAW_FRAME, which means the VO wouldn't redraw OSD and window contents, and the player would appear frozen to the user. This was a bit stupid, and makes dealing with some corner cases much harder (think of --keep-open, which was hard to implement, because the VO gets into this state if there are no new video frames after a seek reset). Change this, and require VOs to always react to VOCTRL_REDRAW_FRAME. There are two aspects of this: First, behavior after a (successful) vo_reconfig() call, but before any video frame has been displayed. Second, behavior after a vo_seek_reset(). For the first issue, we define that sending VOCTRL_REDRAW_FRAME after vo_reconfig() should clear the window with black. This requires minor changes to some VOs. In particular vaapi makes this horribly complicated, because OSD rendering is bound to a video surface. We create a black dummy surface for this purpose. The second issue is much simpler and works already with most VOs: they simply redraw whatever has been uploaded previously. The exception is vdpau, which has a complicated mechanism to track and filter video frames. The state associated with this mechanism is completely cleared with vo_seek_reset(), so implementing this to work as expected is not trivial. For now, we just clear the window with black.
* x11: remove colormap code, always request TrueColor visualswm42013-09-301-9/+12
| | | | | | | | | | | | | | | | | | | | vo_x11 had a clever trick to implement a video equalizer: it requested a DirectColor visual. This is a X11 mechanism which allows you to specify a lookup table for each color channel. Effectively, this is a safe override for the graphic card's gamma ramp. If X thinks the window deserves priority over other windows in the system, X would temporarily switch the gamma ramp so that DirectColor visuals can be displayed as the application intends. (I'm not sure what the exact policy is, but in practice, this meant the equalizer worked when the mouse button was inside the window.) But all in all, this is just lots of useless code for a feature that is rarely ever useful. Remove it and use the libswscale equalizer instead. (This comes without a cost, since vo_x11 already uses libswscale.) One worry was that using DirectColor could have made it work better in 8-bit paletted mode. But this is not the case: there's no difference, and in both cases, the video looks equally bad.
* video/out: don't require VOs to handle screenshot aspect speciallywm42013-08-241-3/+1
| | | | | | | | | | | | | | | | This affects VOs which just reuse the mp_image from draw_image() to return screenshots. The aspect of these images is never different from the aspect the screenshots should be, so there's no reason to adjust the aspect in these cases. Other VOs still need it in order to restore the original image attributes. This requires some changes to the video filter code to make sure that the aspect in the passed mp_images is consistent. The changes in mplayer.c and vd_lavc.c are (probably) not strictly needed for this commit, but contribute to consistency.
* x11/out: mp_msg conversionAlexander Preisinger2013-08-231-29/+21
|
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-2/+2
| | | | Followup commit. Fixes all the files references.
* video: support setting libswscale chroma positionwm42013-07-251-0/+1
|
* video/out: remove options argument from preinit()wm42013-07-221-1/+1
| | | | | All VOs use proper option parsing now, and compatibility hacks are not needed.
* sws_utils: don't recursively include libswscale headerwm42013-07-181-0/+1
| | | | Add libswscale includes where they are actually needed instead.
* vo_x11: use new swscale wrapperwm42013-07-181-28/+20
|
* vo_x11: remove weird inactive codewm42013-07-181-15/+0
| | | | | | | | | | | | | | | | | | | | I guess this code was supposed to handle cases like drawing RGBA as ARGB by offsetting it by 1 byte. The code didn't make any sense, though. It used to make sense before mpv switched internal pixel formats from FourCCs to a simple enum. With the FourCCs, "fmt | 128" selected the big endian version of a format. Of course this doesn't work this way with the new pixel formats. It just so happens that there are no formats with whose values match IMGFMT_RGB32|128 or IMGFMT_BGR32|128, so this code was inactive. All involved pixel formats seem to play fine on my setup (though it's little endian only), and the code strictly matches the mpv pixel formats against the format of the X image, so I'm not quite sure why this code was there in the first place. The original commit that added this was b333ae1 (svn 21602): Support for different endianness on client and server with -vo x11
* input: handle mouse movement differentlywm42013-06-291-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before this commit, mouse movement events emitted a special command ("set_mouse_pos"), which was specially handled in command.c. This was once special-cased to the dvdnav and menu code, and did nothing after libmenu and dvdnav were removed. Change it so that mouse movement triggers a pseudo-key ("MOUSE_MOVE"), which then can be bound to an arbitrary command. The mouse position is now managed in input.c. A command which actua