summaryrefslogtreecommitdiffstats
path: root/video/out/vo_x11.c
Commit message (Collapse)AuthorAgeFilesLines
* vo_x11: partially restore operation on bad endian systemswm42020-06-171-6/+22
| | | | | | | | | | | | | For testing in VMs I guess? This features a very broken hack that probably works. Though I didn't test the packed format case. Again, the mismatch is essentially due to big endian byte addresses decreasing as bit addresses increase, so you can't represent a bit position in a byte stream with a single address, which the mpv metadata does. OSD is broken because repack.c doesn't support big endian. You'll have to live with it.
* vo_x11: allow OSD rendering outside of video regionwm42020-05-221-65/+52
| | | | | | | | | | | | | | | | | | | | | | | | I'm not sure why it only rendered OSD inside the video. Since OSD rendering was always done on the X image (after software scaling and color conversion), there was no technical reason for this. Maybe it was because the code started out this way, and it was annoying to change it. Possibly, one reason was that it didn't normally have to clear the black bars in every frame (if video didn't cover the entire window). Anyway, simply render OSD to the full window. This gets rid of some rather weird stuff. It seems to look mostly like vo_wlshm now. The uncovered regions are cleared every frame, which could probably be avoided by being clever with the OSD renderer code, but this is where I'm decidedly losing interest. There was some mysterious code for aligning the image width to 8 pixels. Replace that by attempting to align it to SIMD alignment (might matter for libswscale, or if repack.c gets SIMD). Why are there apparently 4 different ways representing a pixel format (depth, VisualID, Visual, XVisualInfo), but none of them seem to provide the XImage.bits_per_pixel value (the actual size of a pixel, including padding)? Even after 33 years, X11 still seems overengineered, confusing, and inconvenient. So just call X11 a heap of shit, and assume the worst case for alignment.
* vo_x11: minor improvement in format matchingwm42020-05-201-5/+5
| | | | | | | | | Make sure to accept only native endian mpv formats. Previously, it didn't check, and simply matched LE, because these are usually defined before the BE formats. red_mask etc. are defined as unsigned long, so use that instead of hardcoding a 32 bit limit.
* vo_x11: use imgfmt metadata instead of hardcoded format tablewm42020-05-201-32/+21
| | | | | | Useless, but super generic! Actually may add support for other fringe formats, however vo_x11 in itself is useless, so nothing won here. Also I didn't bother with big endian support.
* vo_x11: add 10 bit supportwm42020-05-141-0/+3
| | | | Requires zimg.
* vo_x11: don't call X11 "crap"wm42020-02-111-1/+1
| | | | | | X11 is in fact beautiful and superior to Wayland. Instead, just state what the problem is in most cases: software scaling. (We have accelerated X11 rendering in vo_gpu and others.)
* vo_x11: accept zimg formatswm42019-11-031-1/+2
| | | | | | | | | | | | This is slightly helpful for testing, and otherwise useless and without consequence. I'm not using the correct output format and using IMGFMT_RGB0 as placeholder. This doesn't matter currently, as both sws and zimg support this as output (and support any input for it). I'm doing this because it's surprisingly tricky to get the correct output format at this point, without digging deeper into x11 shit or refactoring parts of the VO. I don't care enough about this.
* sws_utils: shuffle around some shitwm42019-10-311-2/+1
| | | | | | | | | | | Purpose uncertain. I guess it's slightly better, maybe. The move of the sws/zimg options from VO opts (vo_opt_list) to the top-level option list is tricky. VO opts have some helper code in vo.c, that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's because updating certain VO options used to be this way (and not just the panscan option). This isn't needed anymore for sws/zimg options, so explicitly move them away.
* vo_x11: enable use of zimgwm42019-10-201-0/+2
| | | | | | | | This will perform conversion and scaling of video with zimg, if --sws-allow-zimg is used. The performance probably depends on how well the compiler optimizes the RGB pack code in zimg.c, which is written in C.
* vo_x11: fix return value in resize() error pathsRikard Falkeborn2018-11-171-2/+2
| | | | | | Returning -1 in a function with return type bool is the same as returning true. In the error paths, false should be returned to indicate that something went wrong.
* 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