summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* x11: fix datatype for _NET_WM_PIDwm42014-05-261-1/+1
| | | | | | | | | | Setting this property was added 12 years ago, and the code was always incorrect. The underlying data type is "long", not "pid_t". It's well possible that the data types are different, and the pointer to the pid variable is directly passed to XChangeProperty, possibly invoking undefined behavior. It's funny, because in theory using pid_t for PIDs sounds more correct.
* x11: un-inline GNOME layer stuffwm42014-05-232-17/+12
| | | | | | Having it as separate function is not useful. Also remove the useless vo_window parameter.
* x11: prefer NetWM hints over _WIN_LAYER for --ontopwm42014-05-231-11/+11
| | | | | | | _WIN_LAYER is apparently an old GNOME thing (also explains why there is a function vo_x11_get_gnome_layer() involved in this code). Prefer the NetWM hints over this. This just moves the NetWM case if-body over the _WIN_LAYER one.
* x11: rename identifiers using reserved namespacewm42014-05-231-8/+6
| | | | | | | You can't use identifiers starting with "_" and an uppercase letter in application programs. They are reserved by the C standard. Unrelated change: drop unused/misleading vo_wm_NETWM define.
* x11: fix NetWM ontop settingwm42014-05-231-23/+13
| | | | | | | I can only assume the old code was wrong. EWMH does not document anything with _WIN_LAYER. Instead, you have to toggle the state using a client message. We also remove these weird non-sense fallbacks, like using _NET_WM_STATE_BELOW - what the hell?
* x11: add a generic function for NetWM state settingwm42014-05-231-23/+11
| | | | And use it for fullscreening. It will also be used for fixing --ontop.
* vdpau: move RGB surface management out of the VOwm42014-05-221-84/+4
| | | | | | | | | | Integrate it with the existing surface allocator in vdpau.c. The changes are a bit violent, because the vdpau API is so non-orthogonal: compared to video surfaces, output surfaces use a different ID type, different format types, and different API functions. Also, introduce IMGFMT_VDPAU_OUTPUT for VdpOutputSurfaces wrapped in mp_image, rather than hacking it. This is a bit cleaner.
* vo_vdpau: always allocate the black pixelwm42014-05-221-0/+3
| | | | | | black_pixel is an (apparently necessary) 1x1 black surface used for clearing the screen. It was allocated in RGB mode only, but is sometimes used in YUV mode too.
* x11: fix a warning with --disable-xextJerome Leclanche2014-05-221-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo: minor simplificationswm42014-05-221-11/+3
|
* vo: remove config_ok check from vo_check_events()wm42014-05-221-3/+1
| | | | This should be ok now after the x11 code was adjusted.
* vo_vaapi: don't redraw twicewm42014-05-221-7/+1
| | | | | After VOCTRL_REDRAW_FRAME, flip_page is called, which renders the frame. The current code rendered the frame twice; drop the redundant call.
* x11: unbreak build without xineramawm42014-05-191-0/+2
|
* x11: leaving fullscreen -> reset WM hints only if neededwm42014-05-191-4/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | This works around an issue in OpenBox: OpenBox apparently sizes the normal window incorrectly if aspect ratio hints are set, and the window size is off by 1 pixel. Then, when going fullscreen and leaving fullscreen again, mpv sets the hints based on OpenBox' broken window size, and as result, OpenBox sizes the window incorrectly and is off by 1 pixel again - so it's 2 pixels off in total. The error gets more visible, the more often you toggle fullscreen mode. Work this around by not setting the window hints if we don't need to. Actually we only need to do this when the video is resized during fullscreen, which happens rarely. Under normal circumstances, leaving fullscreen mode requires that the WM restores the old state. As such, this commit is not only a workaround, but actually a cleanup. Note that we do need to set the hints when leaving fullscreen if the window has resized: even though we set the hints in vo_x11_highlevel_resize (called by vo_x11_config_vo_window), this doesn't seem to have an effect (at least on IceWM), so we have to do it after that. Side note: ot seems commit 625ad57a strangely triggered the OpenBox issue according to user reports; I'm not sure why.
* x11: always check whether a window existswm42014-05-191-7/+20
| | | | | So any VOCTRL can be called at any time. Working towards removing all these config_ok checks in vo.c.
* x11: request and handle resize events of parent windows with --widwm42014-05-191-8/+10
| | | | | | | Before this commit, this was somehow polled (i.e. not the right way). Also, selects the correct window when doing --wid=0 (which is another weird special-case).
* x11: remove a duplicated linewm42014-05-181-1/+0
|
* x11: never enable DPMS if we didn't disable itwm42014-05-182-0/+4
| | | | | | | | | Enabling DPMS even though you disabled it globally is pretty unfriendly, so don't do it. Instead, we only disable DPMS if it was enabled, and only enable it if we disabled it ourselves. The other way should never happen (disabling DPMS permanently), unless mpv crashes during playback.
* x11: make screensaver code more compact, change DPMS handlingwm42014-05-172-55/+24
| | | | | | | | Reduces some code-duplication. Just call DPMSEnable/DPMSDisable, instead of DPMSForceLevel when reenabling DPMS. "Force" sounds evil, and messing with DPMS is already pretty evil. I'm not even sure that we should.
* x11: add wrapper for EWMH XSendEvent callswm42014-05-171-90/+49
|
* x11: fix Drag & Dropwm42014-05-171-1/+1
| | | | Accidentally broken in commit 95462747.
* x11: add a wrapper for XGetWindowPropertywm42014-05-171-70/+77
| | | | | | XGetWindowProperty is a really bad API, almost as if the NSA designed it. The wrapper takes care of verifying the return values and handle corner cases.
* x11: comment about gravitywm42014-05-171-0/+4
| | | | | | | | | | | | | | | | The window "gravity" influences how placement interacts with WM added borders (i.e. from decorations). This is probably what the code removed in commit c14721c8 was about. In theory, we'd probably want to set the gravity depending on the relative placement requested by the user (so that it's possible to line up the top/left video pixel with the monitor corner, as well as the bottom/right pixel - but that would be too complicated, and who cares after all?). I'm also not sure whether CenterGravity really uses the top/left corner as reference point (instead of making coordinates relative to the window center), but empirically it's correct.
* x11: replace x/y/w/h with mp_rectwm42014-05-172-102/+76
|
* x11: remove some unused fieldswm42014-05-171-3/+0
|
* x11: don't set PBaseSizewm42014-05-171-7/+0
| | | | There's apparently no reason why we should set a bogus size.
* x11: remove vo_hint memberwm42014-05-172-23/+26
| | | | | Now it's always recreated in vo_x11_sizehint(). Also, the Xlib manual says you must use XAllocSizeHints() (for ABI reasons), so do that.
* x11: always raise layer in fullscreen mode without NetWMwm42014-05-171-4/+1
|
* x11: implement --fs-screen properly, separate old code pathwm42014-05-171-65/+88
| | | | | | | Try to get the "new" code path (using NetWM/EWMH) free of hacks done for the sake of old WMs or the no-WM case. Implement --fs-screen using _NET_WM_FULLSCREEN_MONITORS.
* x11: use CenterGravity by defaultwm42014-05-171-1/+1
| | | | | | Keeps the window centered on resize. Seems nicer. (Although it's worse if 1. the default placement of the WM puts it into a monitor corner, and 2. you switch to a larger video.)
* x11: remove gravity restore codewm42014-05-172-10/+0
| | | | | | | | | | It was added with 3813c685 in 2004. I'm not really sure why this gravity stuff would be needed; apparently it has to do with misplacements with broken WMs and had to be changed on fullscreen. Just get rid of it; it works perfectly fine without on modern WMs. The thread discussing this is here: http://mplayerhq.hu/pipermail/mplayer-dev-eng/2004-July/027674.html
* x11: don't cache X Atoms manuallywm42014-05-162-108/+45
| | | | | XInternAtom() already caches lookups. Even if calling XInternAtom would be always inefficient, it wouldn't matter much during normal playback.
* x11: inline a functionwm42014-05-161-9/+3
| | | | Keeping it separate seems less readable.
* x11: replace--[x11-]fstype option with --x11-netwmwm42014-05-162-109/+20
| | | | | Simplifies the code a lot. You can still use --x11-netwm=no to disable NetWM for whatever reasons.
* x11: remove a MWM hackwm42014-05-161-11/+0
| | | | This was for Motif Window Manager. No, I don't care about Motif.
* x11: remove unused stuffwm42014-05-161-18/+0
| | | | | Unfortunately, it looks like some Motif functionality is still needed to allow for --no-border.
* x11: set the fullscreen state before mapping the windowwm42014-05-151-0/+11
| | | | | | | This should get rid of some flickering. Since this actually skips all the wacky fullscreening code on startup, this might lead to certain wacky features to stop working. In this case, you'll have to use the --x11-fstype option, and disable _NETWM_STATE_FULLSCREEN usage.
* x11: clear window on mapwm42014-05-151-1/+1
| | | | | | | | | | | | | | | | vo_x11_map_window() was attempting to clear the window on map. However, it did so immediately after the map request. It probably assumed that the drawing calls for clearing the window would be queued along with the map request, and then executed in the right order. However, this assumption was wrong - the map request first has to go to the window manager (I guess?), so a lot of things happen before the window is even mapped. Fix this by moving the call to the MapNotify message handler, when the window (apparently) becomes really visible. I also tried to set CWBackPixel to black instead, but this seemed to result in flickering on manual resizing.
* x11: wait until the window is mappedwm42014-05-151-0/+11
| | | | | | | | | | | This blocks everything, until the window is actually reported as mapped. This fixes the race condition between VO initialization and mapping the window, which resulted in possibly different window sizes, leading to an immediate redraw, visible as flashing. Note that if the map event never comes for some reason, we're out of luck and will block forever.
* wayland: fix typoAlexander Preisinger2014-05-141-14/+14
| | | | So long in the code without me noticing. Embarassing!
* wayland: fix unchecked malloc usagewm42014-05-111-3/+9
| | | | | | | Found by cppcheck. Actually untested. (This is the file drag&drop code, I don't even know which wayland clients support this.)
* x11: fix potentially unaligned access in icon loaderwm42014-05-101-3/+3
| | | | | Tried to load a 32 bit value by dereferencing a uint32_t pointer, but the pointer is not guaranteed to be aligned, not even in practice.
* encode: fix PTS unit mismatchwm42014-05-101-6/+6
| | | | | | This used MP_NOPTS_VALUE to compare with ffmpeg-style int64_t PTS values. This probably happened to work, because both constants use the same value.
* vo_vdpau, vo_opengl: handle vdpau preemption differentlywm42014-05-102-56/+29
| | | | | | | | | | | | | | | | | | | | Use the newly provided mp_vdpau_handle_preemption() function, instead of accessing mp_vdpau_ctx fields directly. Will probably make multithreaded access to the vdpau context easier. Mostly unrelated to the actual changes, I've noticed that using hw decoding with vo_opengl sometimes leads to segfaults inside of nvidia's libGL when doing the following: 1. use hw decoding + vo_opengl 2. switch to console (will preempt on nvidia systems) 3. switch back to X (mpv will recover, switches to sw decoding) 4. enable hw decoding again 5. exit mpv Then it segfaults when mpv finally calls exit(). I'll just blame nvidia, although it seems likely that something in the gl_hwdec_vdpau.c preemption handling triggers corner cases in nvidia's code.
* w32_common: fix typowm42014-05-101-2/+3
| | | | Also, reset rc completely, instead of assuming things.
* player: remove VO from seeking code pathwm42014-05-072-6/+0
| | | | | | | | | | | | | | | Until recently, the VO was an unavoidable part of the seeking code path. This was because vdpau deinterlacing could double the framerate, and hr- seek and framestepping etc. all had to "see" the additional frames. But we've removed the frame doubling from the vdpau VO and moved it into a video filter (vf_vdpaupp), and there's no reason left why the VO should participate in seeking. Instead of queuing frames to the VO during seek and skipping them afterwards, drop the frames early. This actually might make seeking with vo_vdpau and software decoding faster, although I haven't measured it.
* video/out: remove unused config() parameterswm42014-05-079-29/+17
| | | | This was cleaned up yesterday.
* vo: remove old stuffwm42014-05-062-24/+0
|
* vo_wayland: always assume resize on reconfigurewm42014-05-061-2/+1
| | | | | | It doesn't look like vo_wayland_config() necessarily sets this flag, so it seems safer to trigger an explicit resize. This accounts for the case when playing a new file with different size than the one before.
* wayland: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-064-27/+28
| | | | Not very tested. Appears to work.
* win32: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-064-70/+46
| | | | Not very tested. At least it compiles.
* cocoa: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-063-22/+25
|
* vo_sdl: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-061-29/+33
|
* x11: don't use VOCTRL_UPDATE_SCREENINFOwm42014-05-067-36/+36
| | | | See previous commit.
* video/out: separate out code to compute window sizewm42014-05-063-85/+171
| | | | | | | | | | | | | | | | | | | Currently, vo_reconfig() calculates the requested window size and sets the vo->dwidth/dheight fields _if_ VOCTRL_UPDATE_SCREENINFO is implemented by the VO or the windowing backend. The window size can be different from the display size if e.g. the --geometry option is used. It will also set the vo->dx/dy fields and read vo->xinerama_x/y. It turned out that this is very backwards and actually requires the windowing backends to workaround these things. There's also MPOpts.screenwidth/screenheight, which used to map to actual options, but is now used only to communicate the screen size to the vo.c code calculating the window size and position. Change this by making the window geometry calculations available as separate functions. This commit doesn't change any VO code yet, and just emulates the old way using the new functions. VO code will remove its usage of VOCTRL_UPDATE_SCREENINFO and use the new functions directly.
* Fix bogus copyright textwm42014-05-061-2/+0
| | | | | This file was copied from gl_hwdec_vaglx.c to have a basic skeleton, but no actual code is left from it.
* vo: fix previous commitwm42014-05-061-1/+1
| | | | | | Commit 433161 actually broke vo_opengl (and maybe others), because config_ok is not necessarily set correctly yet _during_ reconfig. So a vo_get_src_dst_rects() call during reconfig did nothing.
* vo: don't crash when changing panscan before first configurationwm42014-05-061-0/+2
| | | | | | | | | | When the VO was not initialized with vo_reconfig(), or if the last vo_reconfig() failed, changing panscan would cause a crash due to vo_get_src_dst_rects() dereferencing vo->params (NULL if not configured). Just do nothing if that happens, as there is no video that could be displayed anyway.
* vo: get rid of config_count fieldwm42014-05-064-8/+4
| | | | | | | | Doesn't really seem to be much of use. Get rid of the remaining uses of it. Concerning vo_opengl_old, it seems uninitGl() works fine even if called before initialization.
* vdpau: deduplicate video surface upload codewm42014-05-041-18/+7
| | | | | | | This was a minor code duplication between vf_vdpaupp.c and vo_vdpau.c. (In theory, we could always require using vf_vdpaupp with vo_vdpau, but I think it's better if vo_vdpau can work standalone.)
* options: remove obsolete --fsmode-dontuseMartin Herkt2014-05-041-8/+2
|
* options: rename video-related options/propertiesMartin Herkt2014-05-041-2/+2
| | | | | | | | | | | Renamed options: --aspect → --video-aspect --fstype → --x11-fstype --native-fs → --fs-missioncontrol --name → --x11-name Renamed properties: aspect → video-aspect
* video: change everythingwm42014-05-022-34/+31
| | | | | | | Change how the video decoding loop works. The structure should now be a bit easier to follow. The interactions on format changes are (probably) simpler. This also aligns the decoding loop with future planned changes, such as moving various things to separate threads.
* vo: verify format of queued imagewm42014-05-021-0/+1
| | | | | Currently, only the configured format is accepted, so assert that the playback core code (which handles format changes) is correct.
* vo_vdpau: keep colorspace flagswm42014-05-021-1/+2
| | | | | Since vdpau_mixer.c initializes the YUV conversion using the mp_image flags, these images should have all flags set properly.
* video: move video frame queue from vo_vdpau.c to vo.cwm42014-05-023-145/+102
| | | | | | | | | | | | | | | | | | | | | Remove the special casing of vo_vdpau vs. other VOs. Replace the complicated interaction between vo.c and vo_vdpau.c with a simple queue in vo.c. VOs other than vdpau are handled by setting the length of the queue to 1 (this is essentially what waiting_mpi was). Note that vo_vdpau.c seems to have buffered only 1 or 2 frames into the future, while the remaining 3 or 4 frames were past frames. So the new code buffers 2 frames (vo_vdpau.c requests this queue length by setting vo->max_video_queue to 2). It should probably be investigated why vo_vdpau.c kept so many past frames. The field vo->redrawing is removed. I'm not really sure what that would be needed for; it seems pointless. Future directions include making the interface between playloop and VO simpler, as well as making rendering a frame a single operation, as opposed to the weird 3-step sequence of rendering, drawing OSD, and flipping.
* vo_vdpau: always use mp_image for internal buffer queuewm42014-05-021-44/+39
|
* command, vo_vdpau: respect vdpau deint sub-optionwm42014-05-02