summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* vo_vdpau: always allocate the black pixelwm42014-05-241-3/+6
| | | | | | 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-241-1/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_vaapi: don't redraw twicewm42014-05-241-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.
* wayland: fix typoAlexander Preisinger2014-05-241-14/+14
| | | | So long in the code without me noticing. Embarassing!
* x11: fix potentially unaligned access in icon loaderwm42014-05-241-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.
* Fix bogus copyright textwm42014-05-241-2/+0
| | | | | This file was copied from gl_hwdec_vaglx.c to have a basic skeleton, but no actual code is left from it.
* Revert "wayland: print waylands display erros"Alexander Preisinger2014-04-301-39/+0
| | | | | | | | | | | | This reverts commit 6e34b0ec1f50612cb2767da3dbc27be0be63041d. There has always been an error message "proxy already has a listener" and I couldn't reproduce where it is comming from until now. The display interface already has a listener and we can't overwrite it. Now remove the code and avoid this error message. Conflicts: video/out/wayland_common.c
* vf: remove autoinserted filters on reconfigwm42014-04-302-0/+8
| | | | | | | When using rotation with hw decoding, and the VO does not support rotation, vf_rotate is attempted to be inserted. This will go wrong, and after that it can't recover because a vf_scale filter was autoinserted. Just removing all autoinserted filters before reconfig fixes this.
* vf: add function to remove a filter from the chainwm42014-04-302-0/+14
|
* wayland: don't schedule resize if going fullscreenRicardo Vieira2014-04-171-1/+0
| | | | mpv was resizing to the same size before it went to fullscreen, we don't need to schedule a resize because the compositor will send a configure event with the new dimensions and thats when we should do it.
* encode: write 2-pass stats only per-packetwm42014-04-171-1/+2
| | | | | | The stats were retrieved and written on every encode call, instead of every encode call that actually returned a packet. ffmpeg.c also does it this way, so it must be "more correct". Fixes 2-pass encoding.
* vo_vdpau: add an additional check for timestamp robustnesswm42014-04-171-0/+16
| | | | | | | | | | This might be a good idea in order to prevent queuing a frame too far in the future (causing apparent freezing of the video display), or dropping an infinite number of frames (also apparent as freezing). I think at this point this is most of what we can do if the vdpau time source is unreliable (like with Mesa). There are still inherent race conditions which can't be fixed.
* vo_vdpau: document what WRAP_ADD doeswm42014-04-171-0/+2
| | | | This wasn't necessarily clear.
* vo_vdpau: simplify previous vsync timestamp calculationwm42014-04-171-9/+8
| | | | | | | | | | | | | | | | | | | | | | | | The strange thing about this code was the shift parameter of the prev_vs2 function. The parameter is used to handle timestamps before the last vsync, since the % operator handles negative values incorrectly. Most callers set shift to 0, and _usually_ pass a timestamp after the last vsync. One caller sets it to 16, and can pass a timestamp before the last timestamp. The mystery is why prev_vs2 doesn't just compensate for the % operator semantics in the most simple way: if the result of the operator is negative, add the divisor to it. Instead, it adds a huge value to it (how huge is influenced by shift). If shift is 0, the result of the function will not be aligned to vsyncs. I have no idea why it was written in this way. Were there concerns about certain numeric overflows that could happen in the calculations? But I can't think of any (the difference between ts and vc->recent_vsync_time is usually not that huge). Or is there something more clever about it, which is important for the timing code? I can't think of anything either. So scrap it and simplify it.
* vo_vdpau: simplify time management and make it more robustwm42014-04-171-68/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vo_vdpau used a somewhat complicated and fragile mechanism to convert the vdpau time to internal mpv time. This was fragile as in it couldn't deal well with Mesa's (apparently) random timestamps, which can change the base offset in multiple situations. It can happen when moving the mpv window to a different screen, and somehow it also happens when pausing the player. It seems this mechanism to synchronize the vdpau time is not actually needed. There are only 2 places where sync_vdptime() is used (i.e. returning the current vdpau time interpolated by system time). The first call is for determining the PTS used to queue a frame. This also uses convert_to_vdptime(). It's easily replaced by querying the time directly, and adding the wait time to it (rel_pts_ns in the patch). The second call is pretty odd: it updates the vdpau time a second time in the same function. From what I can see, this can matter only if update_presentation_queue_status() is very slow. I'm not sure what to make out of this, because the call merely queries the presentation queue. Just assume it isn't slow, and that we don't have to update the time. Another potential issue with this is that we call VdpPresentationQueueGetTime() every frame now, instead of every 5 seconds and interpolating the other calls via system time. More over, this is per video frame (which can be portantially dropped, and not per actually displayed frame. Assume this doesn't matter. This simplifies the code, and should make it more robust on Mesa. But note that what Mesa does is obviously insane - this is one situation where you really need a stable time source. There are still plenty of race condition windows where things can go wrong, although this commit should drastically reduce the possibility of this. In my tests, everything worked well. But I have no access to a Mesa system with vdpau, so it needs testing by others. See github issues #520, #694, #695.
* vo_vdpau: more debugging outputwm42014-04-171-4/+20
| | | | Might help to debug certain problems with Mesa.
* vf_eq: don't malloc priv structwm42014-03-301-1/+0
| | | | | There wasn't any reason for this. In fact, it's a memory leak. The proper priv struct is already allocated vf.c and the option parser.
* vd_lavc: ridiculous workaround for Libav 9 compatibilitywm42014-03-303-1/+23
| | | | | | | | This "sometimes" crashed when seeking. The fault apparently lies in libavcodec: the decoder returns an unreferenced frame! This is completely insane, but somehow I'm apparently still expected to work this around. As a reaction, I will drop Libav 9 support in the next commit. (While this commit will go into release/0.3.)
* w32_common: prevent MOUSE_BTN0 sticking after dragJames Ross-Gowan2014-03-301-0/+2
| | | | | | The window doesn't recieve a WM_LBUTTONUP message after it's dragged, probably because it's swallowed by the modal loop. To stop the button from sticking, release it manually when the drag is complete.
* w32_common: capture mouse inputJames Ross-Gowan2014-03-301-0/+5
| | | | | | Mouse buttons can get stuck down if the button is pressed inside the video window and released outside. Avoid this by capturing mouse input when a button is pressed.
* vdpau: change the error message when video too largeAndrey Morozov2014-03-111-1/+2
|
* video: add rounding to aspect ratio calculationswm42014-03-111-2/+2
| | | | | Small errors are unavoidable, but truncation can cause anamorphic video to be off by 1 or 2 pixels.
* w32_common: don't set small iconJames Ross-Gowan2014-03-111-4/+1
| | | | | Windows will automatically choose the correct icon size if this field is unset.
* Factor out setting AVCodecContext extradatawm42014-03-111-19/+8
|
* vo_opengl: make :srgb decompand the BT.709 values correctlynand2014-02-121-2/+15
| | | | | | | | This is the same issue as addressed by 257d9f1, except this time for the :srgb option as well. (257d9f1 only addressed :icc-profile) The conditions of the srgb_compand mix() call are also flipped to prevent an off-by-one error.
* wayland/shm: prevent the window from flying awayAlexander Preisinger2014-02-121-0/+2
| | | | With the new xdg_shell the problem will be no gone by itself.
* video: fix --no-aspectwm42014-02-121-2/+2
| | | | This also affects the --aspect option and the "aspect" property.
* vo_opengl: fix typo in gamma function's parameternand2014-02-121-2/+2
| | | | | The correct value is 0.081, not 0.18. The scale factor also needed slight adjustment due to the order of operations.
* vo_vdpau: Discard zero timestampsJonas Zetterberg2014-02-121-0/+3
| | | | Some drivers do not supply timestamps, use old timestamp in these conditions.
* vo_vdpau: Ensure presentation time is within boundsJonas Zetterberg2014-02-121-0/+4
| | | | | When a time sync happens the last sync time is the minimum time that can be used for presentation.
* vo_opengl: use exactly the values defined by BT.709 for CMSnand2014-02-121-3/+9
| | | | | | I could not see any difference whatsoever, but for usage with a 3DLUT there's zero performance difference so we might as well follow the spec to the letter.
* gl_x11: don't require a X visual for modern GL context creationwm42014-02-121-4/+10
| | | | | | | | Legacy GL context creation (glXCreateContext) explicitly requires a X visual, while the modern one (glXCreateContextAttribsARB) does not for some reason. So fail only on the legacy code path if we don't find a visual. Note that vo_x11_config_vo_window() will select a default visual if a NULL visual is passed to it.
* gl_x11: always request true color visualwm42014-02-121-0/+1
| | | | | | | | | | | | | | | | | | This fixes issue #504. For some reason, glXChooseFBConfig() will return a fbconfig with no associated visual. (I'm not sure if this allowed. They don't always have a visual, but since GLX_X_RENDERABLE is set and GLX_DRAWABLE_TYPE is (implicitly) set to GLX_WINDOW_BIT, why would there be no visual?) Even worse, a test program seems to show that a 16 bit fbconfig is selected (instead of 24/32 bit), which doesn't sound nice at all. Since there _are_ better fbconfigs available, glXChooseFBConfig() should normally sort them by quality, and return the better ones first. It's worth noting that this function should also prefer GLX_TRUE_COLOR over anything else, although this comes last in the sort order. Whatever is going on, requesting GLX_X_VISUAL_TYPE with GLX_TRUE_COLOR seems to fix it.
* wayland: change minimum versionAlexander Preisinger2014-02-121-9/+0
| | | | | Change minimum version to 1.3 and remove the version checking in the source code.
* x11: fix initial VO sizewm42014-02-121-6/+7
| | | | | | | | | | This was done incorrectly in the previous commit: the fallback size used the window size as requested with the first config call, which is the size of the hidden window in the vo_opengl case. (That damn hidden window again...) Conflicts: video/out/x11_common.c
* x11: remove apparently useless codewm42014-02-121-8/+0
| | | | | | | | | This code essentially does nothing. As far as I could find out, this actually used to do something. Then it was removed with commit efe7c39f, leaving some leftover code that didn't do anything useful. This happened 12 years ago! Also remove a commented debug printf.
* x11: fix race condition when setting aspect when leaving fullscreenwm42014-02-121-1/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vo_opengl creates a hidden X11 window to probe the OpenGL context. It must do that before creating a visible window, because VO creation and VO config are separate phases. There's a race condition involving the hidden window: when starting with --fs, and then leaving fullscreen, the unfullscreened window is sometimes set to the aspect ratio of the hidden window. I'm not sure why the window size itself uses the correct size (but corrupted by the wrong aspect), but that's perhaps because the window manager is free to ignore the size hint while honoring the aspect, or something equally messed up. It turns out this happens because x11_common.c thinks the size of the hidden window is the size of the unfullscreened window. This in turn happens because vo_x11_update_geometry() reads the size of the hidden window when called in vo_x11_fullscreen() (called from vo_x11_config_vo_window()) when mapping the fullscreen window. At that point, the window could be mapped, but not necessarily. If it's not mapped, it will get the size of the unfullscreened window... I think. One could fix this by actively waiting until the window is mapped. Try to pick a less hacky approach instead, and never read the window size until MapNotify is received. vo_x11_create_window() needs a hack, because we'd possibly set the VO's size to 0, resulting e.g. in vdpau to fail initialization. (It'll print error messages until a proper resize is received.) Conflicts: video/out/x11_common.c
* vo_wayland: silence shadowing warningwm42014-01-311-3/+3
| | | | No real problem.
* mp_image: reject too large image sizeswm42014-01-311-0/+4
| | | | | | | | | | | Larger sizes can introduce overflows, depending on the image format. In the worst case, something larger than 16000x16000 with 8 bytes per pixel will overflow 31 bits. Maybe there should be a proper failure path instead of a hard crash, but not yet. I imagine anything that sets a higher image size than a known working size should be forced to call a function to check the size (much like in ffmpeg/libavutil).
* wayland/shm: RGB888 as default, change optionsAlexander Preisinger2014-01-311-15/+27
| | | | | | RGB565 is one of the fastest and most supported formats on low end consumer devices, but ffmpeg spams warning when using it. Make it opt-in instead of opt-out.
* wayland/shm: fix memory leakAlexander Preisinger2014-01-311-1/+4
|
* wayland/shm: remove resize boilerplateAlexander Preisinger2014-01-311-21/+4
| | | | | | The problem seems to have solved itself. I guess the previous changes to resizing and commit ba101ab made this possible. Consider me happy for removing that crap.
* vo_wayland: fix confusion of video and window sizeswm42014-01-311-2/+2
|
* cocoa: fix window placement on secondary screensStefano Pigozzi2014-01-151-3/+2
| | | | | | | | | | | | | | For a long time the cocoa backend set the xinerama_x/y and used dx/dy from the VO instance. This somewhat worked with some workarounds but wasn't really what was supposed to be happening. Moreover 27e4360, which touched this workaround introduced a regression. New code doesn't set the xinerama_x/y values so that dx/dy are offsets in the current screen (not a virtual screen composed of all the screens). The screen reference detected during VOCTRL_UPDATE_SCREENINFO is also passed down to the window initialization code. Fixes #472
* cocoa: refactor init window positioning codeStefano Pigozzi2014-01-151-2/+1
|
* wayland: properly empty output listAlexander Preisinger2014-01-151-4/+4
|
* wayland/shm: don't crash if initialization failedAlexander Preisinger2014-01-151-3/+1
|
* wayland: fix crash when initialization failswm42014-01-151-1/+2
| | | | | | On X11, if no wayland compositor is running, wl_list_init() will never be called. This will cause destroy_display() to segfault when trying to iterate over the list.
* wayland/shm: tone down warningsAlexander Preisinger2014-01-151-2/+2
| | | | Those warnings are printed far too often and actually aren't usefull at all.
* wayland: fix memory leaksAlexander Preisinger2014-01-153-2/+23
| | | | | | | | There are still some leaks from wayland-cursor stuff, but there is no way to free the memory as user of the cursor library. Conflicts: video/out/wayland_common.c
* wayland: cleanup registry_handle_globalAlexander Preisinger2014-01-151-2/+1
| | | | | The wl_registry object is already passed as a parameter. No need to create a temporary variable.
* wayland: remove set_user_data from seat_listenerAlexander Preisinger2014-01-151-2/+0
| | | | | | | | | The user_data is passed on add_listener and can later be changed with set_user_data. But because we don't want to change it later and because it is the same object remove the set_user_data call. This might be a copy&paste leftover from the initial draft for the wayland backend.
* wayland: use static consistentlyAlexander Preisinger2014-01-151-4/+4
| | | | Declare everything that is only needed inside wayland_common.c as static.
* wayland: fix fullscreen & resizing for goodAlexander Preisinger2014-01-153-12/+34
| | | | | | | I added enough logic to never set ontop or fullscreen twitce. This commit keeps also the size of the video if multiple videos are played. If the ratio differs the width will be kept at the same size and only the height changes.
* wayland: silence annoying libwayland-client messagewm42014-01-151-0/+3
| | | | | | | | | | | | | | | | | libwayland-client contains the following code [1]: runtime_dir = getenv("XDG_RUNTIME_DIR"); if (!runtime_dir) { fprintf(stderr, "error: XDG_RUNTIME_DIR not set in the environment.\n"); This means this message will unconditionally and unavoidably be printed if XDG_RUNTIME_DIR is not set. Since mpv is a terminal program, and we want to avoid unnecessary output, work it around by not attempting to use wayland if this environment variable is not set. [1] http://cgit.freedesktop.org/wayland/wayland/tree/src/wayland-client.c#n636 (cd0dccd01e16fa404e03974d30ded3aebdb1c4bc)
* wayland: fix some memory leaks on initialization failurewm42014-01-151-6/+13
| | | | | | | | | | | This commonly happens when initializing vo_opengl on a X11-only system. Unfortunately, most wl_*_destroy() functions appear not to accept NULL pointers, making partial deinitialization a pain: you have to add your own NULL checks everywhere to avoid crashes. xkb.context is uninitialized separately, because you can initialize it just fine, even if the rest of input initialization fails.
* cocoa: don't reset window size when the video size doesn't changeStefano Pigozzi2014-01-061-15/+14
| | | | Fixes #459
* w32_common: don't force topmost on fullscreenMartin Herkt2014-01-061-1/+2
| | | | Fixes #457, #444.
* Revert "wayland/egl: use redraw callback"Alexander Preisinger2014-01-062-28/+1
| | | | | | | | | | | Because of this commit there were problems displaying the frmase in their right order. This reverts commit 96e75d234a4df1a09f38eaf932d00d79dccdc324. Conflicts: video/out/gl_wayland.c video/out/wayland_common.h
* wayland: remove workaroundAlexander Preisinger2014-01-061-6/+3
| | | | | | | | The changes in the vo_wayland_ontop function have no effect on the workaround. Somehow the problem just disappeared. I guess it is because of the new control function in gl_wayland.c where the resize happens immediatly after the event dispatch/flush.
* wayland/egl: misc fixes and cleanupsAlexander Preisinger2014-01-062-6/+1
|
* wayland/egl: use redraw callbackAlexander Preisinger2014-01-062-1/+32
| | | | | | | This solves the issue where we would not receive any frame events. The difference to my earlier tests is that now it looks like eglSwapBuffers uses it's own event queue or something similiar along the lines. Becaues the performance is the same as without any redraw callback.
* wayland/egl: add egl_context to the wayland stateAlexander Preisinger2014-01-062-67/+73
| | | | | | | | | | | At the moment there are visual glitches when we resize the window. This happens because in wayland there a special function for resizing EGL windows. To prevent the glitches move the egl_context to the wayland state in wayland_common.h and add a new control function to gl_wayland.c to wrap the vo_wayland_control function to check for resize events. With the new control wrapper the glitches are gone and the resizing is fluid.
* wayland: Remove nonsense comment and add warningAle