summaryrefslogtreecommitdiffstats
path: root/video/out/vo_xv.c
Commit message (Collapse)AuthorAgeFilesLines
* build: remove POSIX/sysv shared memory testwm42017-12-021-20/+4
| | | | | | 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.)
* video: redo video equalizer option handlingwm42017-08-221-9/+0
| | | | | | | | | | | | | | | | | | | | | | | I really wouldn't care much about this, but some parts of the core code are under HAVE_GPL, so there's some need to get rid of it. Simply turn the video equalizer from its current fine-grained handling with vf/vo fallbacks into global options. This makes updating them much simpler. This removes any possibility of applying video equalizers in filters, which affects vf_scale, and the previously removed vf_eq. Not a big loss, since the preferred VOs have this builtin. Remove video equalizer handling from vo_direct3d, vo_sdl, vo_vaapi, and vo_xv. I'm not going to waste my time on these legacy VOs. vo.eq_opts_cache exists _only_ to send a VOCTRL_SET_EQUALIZER, which exists _only_ to trigger a redraw. This seems silly, but for now I feel like this is less of a pain. The rest of the equalizer using code is self-updating. See commit 96b906a51d5 for how some video equalizer code was GPL only. Some command line option names and ranges can probably be traced back to a GPL only committer, but we don't consider these copyrightable.
* video: get rid of swapped packed YUVwm42017-06-301-2/+0
| | | | | | Another legacy annoyance. The only place where packed YUV is still important is slightly older Apple hardware or drivers, which require it for efficient hardware decoding.
* Drop/move img_fourcc.hwm42017-06-181-1/+8
| | | | | | | | | | | | | | | This file is an leftover from when img_format.h was changed from using the ancient FourCCs (based on Microsoft multimedia conventions) for pixel formats to a simple enum. The remaining cases still inherently used FourCCs for whatever reasons. Instead of worrying about residual copyrights in this file, just move it into code we don't want to relicense (the ancient Linux TV code). We have to fix some other code depending on it. For the most part, we just replace the MP_FOURCC macro with libavutil's MKTAG (although the macro definition is exactly the same). In demux_raw, we drop some pre-defined FourCCs, but it's not like it matters. (Instead of --demuxer-rawvideo-format use --demuxer-rawvideo-mp-format.)
* 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.
* options: remove deprecated sub-option handling for --vo and --aowm42016-11-251-1/+1
| | | | | | | | Long planned. Leads to some sanity. There still are some rather gross things. Especially g_groups is ugly, and a hack that can hopefully be removed. (There is a plan for it, but whether it's implemented depends on how much energy is left.)
* 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.
* options: deprecate suboptions for the remaining AO/VOswm42016-09-051-0/+1
|
* vo_xv: remove an aliased optionwm42016-08-311-4/+7
| | | | | Trying to get rid of them, and no-colorkey is an instance of it. Kill it.
* 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-1/+1
|
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-031-2/+2
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* vo_xv: fix behavior with odd sizeswm42016-06-251-6/+8
| | | | | | | | | | The size check introduced in commit d941a57b did not consider that Xv can round up the image size to the next chroma boundary. Doing that makes sense, so it can't certainly be considered server misbehavior. Do 2 things against this: allow if the server returns a larger image (we just crop it then), and also allocate a properly aligned image in the first place.
* vo_xv: Handle incorrect size returned by Xv(Shm)CreateImagedequis2016-05-241-0/+9
| | | | | | | | | | | | | Fixes #320 (which is closed as 'not our problem' but eh) Relevant xorg bug: https://bugs.freedesktop.org/show_bug.cgi?id=70931 For me this happened when (accidentally) trying to play a 8460x2812 jpg file with mpv. Like the referenced bug, xvinfo reports "maximum XvImage size: 8192 x 8192". So the returned XvImage is 8192x2812 and memory corruption happens. Only after handling this BadShmSeg X11 errors are shown.
* vo_xv, vo_x11: warn that these VOs should not be usedwm42016-03-061-0/+3
|
* mpv_talloc.h: rename from talloc.hDmitrij D. Czarkoff2016-01-111-1/+1
| | | | This change helps avoiding conflict with talloc.h from libtalloc.
* vo_xv: fix crash with --widwm42015-10-071-1/+1
| | | | | | Fixes #2386. Reminder that you should not use this crap-VO.
* 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-1/+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.
* x11: move GCs and background clearing to vo_xvwm42015-07-011-5/+49
| | | | vo_xv.c is the only place where these things are used.
* vo_xv: make number of buffers configurablewm42015-05-201-3/+8
|
* Update license headersMarcin Kurczewski2015-04-131-7/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video/out: remove unused colorspace reportingwm42015-03-311-6/+0
| | | | | | | | Rarely used and essentially useless. The only VO for which this was implemented correctly and for which this did anything was vo_xv, but you shouldn't use vo_xv anyway (plus it support BT.601 only, plus a vendor specific extension for BT.709, whose presence this function essentially reported - use xvinfo instead).
* vo_xv: remove pointless castwm42015-03-201-2/+1
|
* video: uninline memcpy_pic functionswm42015-03-201-1/+0
| | | | | | | | | There's literally no reason why these functions have to be inline (they might be performance critical, but then the function call overhead isn't going to matter at all). Uninline them and move them to mp_image.c. Drop the header file and fix all uses of it.
* vo_xv: don't attempt to clear window before mappedwm42015-02-261-0/+2
| | | | | | | | This can happen with the "no-colorkey" suboption. Then the code in xv_draw_colorkey() can be run before vo_x11_config_vo_window(), when vo_gc is not allocated yet. Fixes #1629.
* vo: simplify VOs by adding generic screenshot supportwm42015-01-241-12/+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-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).
* 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.)
* vo: different hack for VOs which need to mangle mouse inputwm42014-07-271-11/+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: use strcmp() instead of strcasecmp() for equalizerswm42014-07-101-8/+8
| | | | This makes it more consistent with the more important VOs.
* vo_xv: de-ancient some help messageswm42014-06-211-10/+2
| | | | | One message pointed to a removed file, so just get rid of the messages. They were helpful in the earlier 2000s, but now they're just confusing.
* 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-11/+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.
* x11: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-061-1/+1
| | | | See previous commit.
* video/out: remove legacy colorspace stuffwm42014-03-291-15/+16
| | | | | | | | | 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.
* video/out: do remaining config to reconfig replacementswm42014-01-241-9/+7
| | | | | | | The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
* video/out: don't access aspdat in VOswm42014-01-221-6/+1
| | | | | | | | | | | vo->aspdat is basically an outdated version of vo->params, plus some weirdness. Get rid of it, which will allow further cleanups and which will make multithreading easier (less state to care about). Also, simplify some VO code by using mp_image_set_attributes() instead of caring about display size, colorspace, etc. manually. Add the function osd_res_from_image_params(), which is often needed in the case OSD renders into an image.
* 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.
* build: fix shm detection on OpenBSDStefano Pigozzi2013-12-261-0/+1
| | | | Fixes #427
* vo_x11/vo_xv: fix build when using --disable-xextStefano Pigozzi2013-12-251-7/+7
|
* Split mpvcore/ into common/, misc/, bstr/wm42013-12-171-1/+1
|
* Move options/config related files from mpvcore/ to options/wm42013-12-171-2/+2
| | | | | | | | | 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.
* osd: remove mp_osd_res.video_par fieldwm42013-11-241-1/+0
| | | | | | This is not needed anymore, because we decided that the PAR of the decoded video matters, and not the PAR of the filtered video that arrives at the VO.
* 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.
* vo_xv: fix compilation of SHM not availablewm42013-11-051-1/+1
|
* 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
* vo_xv: check whether image allocation succeedswm42013-10-271-6/+24
|
* video/out: remove useless info struct and redundant fieldswm42013-10-231-8/+4
| | | | The author and comment fields were printed only in -v mode.
* vo_x11, vo_xv: fix OSD redrawing with --force-windowwm42013-10-061-4/+6
| | | | The window wasn't cleared in this mode before doing the redrawing.
* video/out: always support redrawing VO window at any pointwm42013-10-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* 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.
* Some more mp_msg conversionswm42013-08-231-54/+44
| | | | | Also add a note to mp_msg.h, since it might be not clear which of the two mechanisms is preferred.
* core: move contents to mpvcore (2/2)Stefano Pigozzi2013-08-061-3/+3
| | | |