summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* video: fix redrawing when pausing after framedropwm42014-09-211-1/+1
| | | | | | | When pausing after a frame was just dropped, we're logically at the dropped frame, and thus should redraw the dropped frame. This was implemented, but didn't work after unpausing for the second time, because of a minor logic bug.
* vo_vdpau: better integration with the generic framedrop codewm42014-09-204-16/+29
| | | | | | | | | | | | | | | | | | | | vo_vdpau uses its own framedrop code, mostly for historic reasons. It has some tricky heuristics, of which I'm not sure how they work, or if they have any effect at all, but in any case, I want to keep this code for now. One day it might get fully ported to the vo.c framedrop code, or just removed. But improve its interaction with the user-visible framedrop controls. Make --framedrop actually enable and disable the vo_vdpau framedrop code, and increment the number of dropped frames correctly. The code path for other VOs should be equivalent. The vo_vdpau behavior should, except for the improvements mentioned above, be mostly equivalent as well. One minor change is that frames "shown" during preemption are always count as dropped. Remove the statement from the manpage that vo_vdpau is the default; this hasn't been the case for a while.
* vo_vdpau: fix confusion around vsync_intervalwm42014-09-201-10/+9
| | | | | | | vc->vsync_interval and vsync_interval should be the same value, but actually vc->vsync_interval was updated after vsync_interval was initialized. This was probably not intended. Fix this by removing the duplicate local variable. There were probably no bad effects.
* wayland: use reported rete and delayAlexander Preisinger2014-09-191-2/+27
| | | | | If native-keyrepeat is true then we set the rate and delay reported by the compositor.
* video: wake up core as soon as possiblewm42014-09-161-0/+1
| | | | | | | | There's no reason to let the core wait until the frame is done displaying. In practice, the core normally didn't need this additional wakeup, and the VO was quick enough to fetch the new frame, before the core even attempted to queue a new frame. But it wasn't entirely clean, and the correct wakeup handling might matter in some cases.
* vo_wayland: remove unnecessary checkAlexander Preisinger2014-09-161-19/+10
| | | | | buffer_pool_get_front now returns always a valid buffer. No need for corner cases.
* wayland/buffer: use buffer macros consistentlyAlexander Preisinger2014-09-161-3/+3
|
* x11: if the WM supports _NET_FRAME_EXTENTS, don't wait for mapwm42014-09-152-3/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Some window managers can prevent mapping of a window as a feature. i3 can put new windows on a certain workspace (with "assign"), so if mpv is started on a different workspace, the window will never be mapped. mpv currently waits until the window is mapped (blocking almost all of the player), in order to avoid race conditions regarding the window size. We don't want to remove this, but on the other hand we also don't want to block the player forever in these situations. So what we need is a way to know when the window manager is "done" with processing the map request. Unfortunately, there doesn't seem to be a standard way for this. So, instead we could do some arbitrary communication with the WM, that may act as "barrier" after map request and the "immediate" mapping of the window. If the window is not mapped after this barrier, it means the window manager decided to delay the mapping indefinitely. Use the _NET_REQUEST_FRAME_EXTENTS message as such a barrier. WMs supporting this message must set the _NET_FRAME_EXTENTS property on the mpv window, and we receive a PropertyNotify event. If that happens, we always continue and cancel waiting for the MapNotify event. I don't know if this is sane or if there's a better mechanism. Also, this works only for WMs which support this message, which are not many. But at least it appears to work on i3. It may reintroduce flickering on fullscreen with other WMs, though.
* sanitizer: avoid divide-by-zero instancesBen Boeckel2014-09-141-1/+1
| | | | | | | | Merges pull request #1094, with some minor changes. mpv expects IEEE, and IEEE allows divisions by 0 for floats, so these shouldn't actually be a problem, but do it anyway for the sake of clang. Signed-off-by: wm4 <wm4@nowhere>
* x11: remove unused functionwm42014-09-142-9/+1
|
* wayland_common: fix changing videos when fullscreenAlexander Preisinger2014-09-102-15/+3
| | | | I broke it again.
* vo_wayland: pixel perfect buffersAlexander Preisinger2014-09-105-342/+500
| | | | | | | | | | | | | | | 1. Separate buffer and temporary file handling from the vo to make maintenance and reading code easier 2. Skip resizing as much as possible if back buffer is still busy. 3. Detach and mark osd buffers for deletion if we want to redraw them and they are still busy. This could be a possible case for the video buffers as well. Maybe better than double buffering. All the above steps made it possible to have resizing without any artifacts even for subtitles. Also fixes dozen of bugs only I knew, like broken subtitles for rgb565 buffers. I can now sleep at night again.
* win32: don't request window size larger than the screenwm42014-09-101-3/+34
| | | | | | | | | | | | | | | | | An attempt at fixing #1070. Apparently something goes wrong if the video size is equal to the screen size. Since the window decorations add to the window size, it must actually be larger than the screen. Actually I don't know what exactly is going wrong, but since this commit also slightly improves the behavior otherwise, it's a win anyway. Try to keep the window size strictly below screen size, even accounting for window decorations. Size it down and center the window so that it fits (by either touching the left/right or top/bottom screen borders). I haven't found any information on what is the maximum allowed size and position of a window so that it doesn't collide with the task bar, so assume that we can use the entire screen, minus 1 pixel to avoid triggering fullscreen semantics (if that is even possible).
* win32: copy event flags after running VOCTRLswm42014-09-071-5/+2
| | | | | | | | | reinit_window_state() will set VO_EVENT_RESIZE when it runs, so we don't need to set it manually depending on the VOCTRL. Probably avoids duplicated resize events. I don't expect this actually fixes anything, but might help spotting other bugs easier (if there are any).
* vo_corevideo: remove this VOStefano Pigozzi2014-09-062-576/+0
| | | | | | | This was kept in the codebase because it is slightly faster than --vo=opengl on really old Intel cards (from the GMA era). Time to kill it, and let it rest. Fixes #1061
* vo_sdl: fix typowm42014-09-051-1/+1
|
* malloc+memset(0) to callocBruno George de Moraes2014-09-052-7/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* video: rename VOCTRL_GET_WINDOW_SIZEwm42014-09-055-10/+12
| | | | Make it clear that this accesses the un-fullscreened window size.
* wayland: print some useful outptu infoAlexander Preisinger2014-09-032-15/+21
| | | | | Prints output informations, useful for finding out if we detect the right mode and for debugging.
* wayland: only save current mode of outputsAlexander Preisinger2014-09-031-1/+2
| | | | Other ones are not needed.
* x11: add rewind and forward keysKenneth Zhou2014-09-031-2/+4
| | | | Signed-off-by: wm4 <wm4@nowhere>
* x11: when using --wid, inherit event flags from parent windowwm42014-08-311-5/+10
| | | | | | | | | | | | | | | | | | | When embedding a X window, it's hard to control whether it receives mouse/keyboard input or not. It seems the X protocol itself makes this hard (basically due to the outdated design mismatching with modern toolkits), and we have to take care of these things explicitly. Simply do this by manually querying and using the parent window event flags. This restores some MPlayer behavior (it doesn't add back exactly the same code, but it's very similar). This probably has some potential to interfere with libmpv embedding, so bump the client API minor. CC: @mpv-player/stable (if applied, client-api-changes.rst has to be adjusted to include the 0.5.2 release)
* gl_wayland: fix crash after eglInitialze failedAlexander Preisinger2014-08-301-6/+8
| | | | | Only execute most of the opengl termination procedure if we actually have an egl context.
* vo_opengl: remove macro operator from shaderBin Jin2014-08-292-21/+7
| | | | Removes '##' operator from OpenGL shader code.
* Move compat/ and bstr/ directory contents somewhere elsewm42014-08-299-9/+8
| | | | | | | | | bstr.c doesn't really deserve its own directory, and compat had just a few files, most of which may as well be in osdep. There isn't really any justification for these extra directories, so get rid of them. The compat/libav.h was empty - just delete it. We changed our approach to API compatibility, and will likely not need it anymore.
* vo_opengl: don't pass (char*)NULL as %s printf argumentwm42014-08-281-2/+3
| | | | | | glGetString(GL_SHADING_LANGUAGE_VERSION) can return NULL; I suppose this happens on legacy OpenGL, while all the other fields are guaranteed to exist.
* vo_opengl: fix shaderwm42014-08-281-7/+9
| | | | | | | | | | | | Regression since commit f14722a4. For some reason, this worked on nvidia, but rightfully failed on mesa. At least in C, the ## operator indeed needs two macro arguments, and you can't just concatenate with non-arguments. This change will most likely fix it. CC: @bjin
* vo_opengl: add parameter to gaussian filterBin Jin2014-08-261-2/+7
| | | | | | | | | | Add a new parameter 'p' to gaussian filter. The new formula used a different base taken from fmtconv plugin, so that the new parameter is exactly same as the one used in Avisynth and Vapoursynth. The new default value is 2 / log(2) * 10, with the default value it conforms to the original kernel taken from vector-agg.
* vo_opengl: add radius options for filtersBin Jin2014-08-264-1/+17
| | | | | | | Add two new options, make it possible for user to set the radius for some of the filters with no fixed radius. Also add three new filters with the new radius parameter supported.
* vo_opengl: add cparam1 and cparam2 optionsBin Jin2014-08-263-21/+42
| | | | | | Although cscale is rarely used, it's possible that params of cscale are accidentally set to lparam1 and lparam2, which might cause unexpected results.
* vo_opengl: add spline64 filter kernelBin Jin2014-08-261-0/+19
| | | | | | | | The coefficients are taken from fmtconv plugin for vapoursynth: https://github.com/vapoursynth/fmtconv/blob/master/src/fmtc/ContFirSpline64.cpp The package is licensed under WTFPL, and it's from the same author of Dither plugin for avisynth.
* vo_opengl: don't cut off feature list outputwm42014-08-251-1/+1
|
* video: avoid unnecessary frame droppingwm42014-08-231-1/+5
| | | | | | | | | If duration<0, it means the duration is unknown. Disable framedropping, because end_time makes no sense in this case. Also, strictly never drop the first frame. This fixes weird behavior with the cover-art case (for the 100th time).
* video: some debugging outputwm42014-08-221-0/+4
|
* vaapi: try dealing with Intel's braindamaged shit driverswm42014-08-212-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | So talking to a certain Intel dev, it sounded like modern VA-API drivers are reasonable thread-safe. But apparently that is not the case. Not at all. So add approximate locking around all vaapi API calls. The problem appeared once we moved decoding and display to different threads. That means the "vaapi-copy" mode was unaffected, but decoding with vo_vaapi or vo_opengl lead to random crashes. Untested on real Intel hardware. With the vdpau emulation, it seems to work fine - but actually it worked fine even before this commit, because vdpau was written and designed not by morons, but competent people (vdpau is guaranteed to be fully thread-safe). There is some probability that this commit doesn't fix things entirely. One problem is that locking might not be complete. For one, libavcodec _also_ accesses vaapi, so we have to rely on our own guesses how and when lavc uses vaapi (since we disable multithreading when doing hw decoding, our guess should be relatively good, but it's still a lavc implementation detail). One other reason that this commit might not help is Intel's amazing potential to fuckup anything that is good and holy.
* video: don't assume query_format is thread-safewm42014-08-202-0/+16
| | | | Although it's probably safe for most VOs, there's no guarantee.
* wayland: replace deprecated xkbcommon functionsAlexander Preisinger2014-08-201-3/+3
| | | | Available and stable since forever (xkbcommon 0.2).
* vo_wayland: fix formatting inconsistenciesAlexander Preisinger2014-08-201-4/+4
|
* vo_wayand: save the flip time in the frame handlerAlexander Preisinger2014-08-201-0/+10
| | | | This value is more accurate than the default value.
* video: add VOCTRL_GET_RECENT_FLIP_TIMEwm42014-08-182-1/+7
| | | | | | This could be used by VO implementations to report a recent vsync time to the generic VO code, which in turn will use it and the display FPS to estimate at which point in time the next vsync will happen.
* vo_opengl: add check-pattern suboption for testingwm42014-08-181-2/+28
| | | | | | | | | | | | | | | | This uses glXGetVideoSyncSGI() to check how many vsyncs happened since the last flip_page() call. It allows checking a pattern of vsync increments of at most 2 elements. For example, to check ~24 fps playback on a ~60 Hz monitor, this can be used: --vo=opengl:check-pattern=[3-2]:waitvsync Whether the reported results are accurate or just plain wrong may depend on the driver and if the waitvsync sub-option is used. There are no guarantees. This option is undocumented, and may be removed again in the near or distant future.
* video: dump vsync phase into stats filewm42014-08-181-2/+4
| | | | | | | For debugging (drawing fun plots with TOOLS/stats-conv.py). Also move last_flip under the correct comment: it's not protected by the lock, and can be accessed by the VO thread only.
* wayland: dynamically report display fpsAlexander Preisinger2014-08-182-21/+60
| | | | | | | | Only reports the most recently entered output if the window is displayed on 2 or more outputs. Should be changed to the lowest fps of all outputs the window is visible. Until no one complains this will have to wait. Look for the VO framedropping for more information on this topic.
* x11: listen to xrandr eventswm42014-08-172-0/+18
| | | | | | | | | | | If the Xrandr configuration changes, re-read it. So if you change display modes or screen configuration, it will update the framedrop refresh rate accordingly. This passes the rootwin to XRRSelectInput(), which may or may not be allowed. But it works, and the documentation (which is worse than used toilet paper, great job Xorg) doesn't forbid it, or in fact say anything about what the window parameter is even used for.
* x11: fix xrandr conditional compilationwm42014-08-171-1/+1
| | | | | | Oops. Fixes #1020.
* video: make vo_opengl the default over vo_vdpauwm42014-08-171-3/+3
| | | | | | | | | | | | | Nvidia's vdpau implementation is pretty good, but other factors make it much less attractive for use as default VO. For example, Mesa often has low quality drivers (mess up things with the presentation queue and the vdpau API time source). Intel ruins things completely, and we're likely to run on emulation via OpenGL. Compositing has unknown effects (to me anyway), but appears to reduce the vdpau advantages. One important reason to prefer vo_vdpau was that it could do proper framedropping. Framedropping got fixed for the other VOs, so this reason is going away.
* video: take refresh rate changes into accountwm42014-08-173-28/+37
| | | | | | | | | | | | | | | This works only on X11, and only if the refresh rate changes due to the window being moved to another screen (detected by us). It doesn't include system screen reconfiguration yet. This calls VOCTRL_GET_DISPLAY_FPS on every frame, which makes me uneasy. It means extra thread communication with the win32 and Cocoa backends. On the other hand, a frame doesn't happen _that_ often, and the communication should still be pretty cheap and fast, so it's probably ok. Also needs some extra fuzz for vo_vdpau.c, because that does everything differently.
* x11: fix memory leakswm42014-08-171-3/+9
| | | | Oh, we have to free this stuff. OK.
* build: drop check for XF86keysym.hwm42014-08-161-6/+1
| | | | | | This is always included in the Xorg development headers. Strictly speaking it's not necessarily available with other X implementations, but these are hopefully all dead.
* x11: use xrandr to retrieve display refresh ratewm42014-08-163-25/+78
| | | | | | | | | | | | | | | | | Drop use of the ancient XF86VM, and use the slightly less ancient Xrandr extension to retrieve the refresh rate. Xrandr has the advantage that it supports multiple monitors (at least the modern version of it). For now, we don't attempt any dynamic reconfiguration. We don't request and listen to Xrandr events, and we don't notify the VO code of changes in the refresh rate. (The later works by assuming that X coordinates map directly to Xrandr coordinates, which probably is wrong with compositing window manager, at least if these use complicated transformations. But I know of no API to handle this.) It would be nice to drop use of the Xinerama extension too, but unfortunately, at least one EWMH feature uses Xinerama screen numbers, and I don't know how that maps to Xrandr outputs.
* vo_wayland: fix redrawing logicwm42014-08-161-8/+8
| | | | | | I must have broken it some time ago. The error case dealing with an unavailable backbuffer was broken, and didn't handle memory management correctly.
* video: add --display-fps switch to control framedrop FPSwm42014-08-161-3/+7
| | | | | | Since the display FPS is currently detected on X11 only (and even there it's known to be wrong on certain setups), it seems like a good idea to make this user-configurable.
* vo_opengl: optional support for using GLX_SGI_video_syncwm42014-08-151-1/+19
| | | | | | | | | I'm not sure about the merit, though it does print nice numbers if debug output is enabled. Basically, this tries to achieve similar results as the glFinish() business, but again it entirely depends on the drivers whether this does anything meaningful, or whether it's actively harmful.
* gl_common: add SGI_video_sync extensionwm42014-08-152-0/+11
|
* vo_opengl: if glfinish is used, also call it after swapppingwm42014-08-151-0/+3
| | | | | | It seems that at least on nvidia systems with composting disabled, we can get it to block deterministically on the actual vsync event, which should improve framedropping.
* video: add VO framedropping modewm42014-08-154-17/+115
| | | | | | | | | | | | | | | | | | | | | | | | This mostly uses the same idea as with vo_vdpau.c, but much simplified. On X11, it tries to get the display framerate with XF86VM, and limits the frequency of new video frames against it. Note that this is an old extension, and is confirmed not to work correctly with multi-monitor setups. But we're using it because it was already around (it is also used by vo_vdpau). This attempts to predict the next vsync event by using the time of the last frame and the display FPS. Even if that goes completely wrong, the results are still relatively good. On other systems, or if the X11 code doesn't return a display FPS, a framerate of 1000 is assumed. This is infinite for all practical purposes, and means that only frames which are definitely too late are dropped. This probably has worse results, but is still useful. "--framedrop=yes" is basically replaced with "--framedrop=decoder". The old framedropping mode is kept around, and should perhaps be improved. Dropping on the decoder level is still useful if decoding itself is too slow.
* vo: eliminate a redundant variablewm42014-08-151-10/+5
| | | | | Originally, I probably had plans to allow NULL images to handle things like the last frame case, but that idea was dropped later.
* vo: remove unused libavutil includewm42014-08-141-2/+0
|
* vo: fix mingw compilationwm42014-08-141-0/+2
|
* wayland: pointer interface is created after themeAlexander Preisinger2014-08-131-13/+8
| | | | | | | | Just always load the theme. It gets freed properly and dosn't bother anyone. Fixes #1012. CC: @mpv-player/stable
* vo_vdpau: fix screenshots with anamorphic videowm42014-08-131-1/+1
| | | | | | Fixes #1007. CC: @mpv-player/stable
*