summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* x11: never forcefully terminate xdg-screensaver processwm42015-05-192-9/+8
| | | | | | | | It sometimes happens on exit, and it's probably a bad idea. If the process hangs on exit (possibly due to stupid hardcoded timeouts it's doing), mpv will also hang now, unfortunately. (cherry picked from commit be9bf4cc7c1b61a8abcbb3f64386ef10d8aa9f61)
* x11: attempt to make initial fullscreening more reliablewm42015-05-191-0/+3
| | | | | | | | | | | | | | | | It appears some WMs have a problem with out method of setting initial fullscreen mode. We assume that if the window's _NET_WM_STATE includes _NET_WM_STATE_FULLSCREEN before mapping the window, the WM will show it as fullscreen at mapped. EWMH doesn't say anything that this should work, although one could argue that it's implied. In any case, since it's not standard behavior without at least some doubt, it's probably a good idea to try the "old" method as well. Fortunately, it should be idempotent. See #1937, #1920. (cherry picked from commit a4f3df5970cc34d8899dbd31b3475f7bd6547f3f)
* vo: remove suspicious linewm42015-05-191-1/+1
| | | | | | | pts can never be 0 or negative. If there is no frame, some code below catches this case by checking hasframe. (cherry picked from commit 372b85b9d20e3bc97120e2506ef9f89224e0f84e)
* Remove trailing whitespacesMichael Vetter2015-05-151-1/+1
| | | | (cherry picked from commit 9251fa125f6ebc0f485c93af1809efb7b6da19bd)
* vo: avoid burning CPU when pausedwm42015-05-151-0/+2
| | | | | | | | Some code always calls vo_event(), even with event==0, which leads to immediate wakeup, which in turn causes the function to be called again. This would burn CPU, which was especially noticeable when paused. (cherry picked from commit 0bdef9979f74db33d1c84ee788c45f5e1d8e0d0d)
* vo_opengl_cb: actually set requested optionswm42015-05-151-0/+1
| | | | | | Quite an oversight. (cherry picked from commit 4d9255a5e1a1c5be805800070a79ef1bcc1a150a)
* vo: always call draw_image_timed() if availablewm42015-05-151-1/+1
| | | | | | | | | Gives the VOs more flexibility. gl_video.c already ignores the timing info if no interpolation is active, so this requires no further changes. (cherry picked from commit af157db7e5803fbe8b323ba2e9671e65c8fd6c2c)
* threads: use utility+POSIX functions instead of weird wrapperswm42015-05-151-2/+4
| | | | | | | | | There is not much of a reason to have these wrappers around. Use POSIX standard functions directly, and use a separate utility function to take care of the timespec calculations. (Course POSIX for using this weird format for time values.) (cherry picked from commit 92b9d75d7256be71d8c8b18438af9494b78f0e96)
* cocoa: add missing break statements in switchwm42015-05-151-0/+2
| | | | | | | The first one (for VOCTRL_GET_DISPLAY_FPS) could have led to undefined behavior if the FPS was unknown. The second is for general symmetry. (cherry picked from commit 10149f68a5c6cb9783ed7595998985d7e586e871)
* vo_drm: allow changing video rectangle settingswm42015-05-091-0/+6
| | | | | | | | | | | Now among other things panscan can be changed during playback. Unfortunately, it flickers. The issue is that reconfig() clears the framebuffer. Removing the clearing shows that the "unused" parts of the picture are not cleared - even though OSD could render there. As such, this is a separate issue. (cherry picked from commit 56310605690288f44c49363413e68f7c73325ed1)
* vo_drm: don't mutate the current frame when clamping for panscanwm42015-05-091-3/+4
| | | | | | | | When running with --panscan=1, this could crash - because the current frame was reduced in size each time the image was redrawn, which would result in a failed assertion the second time it's drawn. (cherry picked from commit 859ddc99064357c752c6f6dfa475cb96430531d2)
* cocoa: remove an unused parameterwm42015-05-073-3/+3
| | | | (cherry picked from commit f58d3591d9c192c9d68a76a0a4ffddd7516c0ef2)
* cocoa: lock cocoa main thread on uninitwm42015-05-071-1/+9
| | | | | | | | | | | | | | | | | | | | This should fix some crashes due to dangling pointers. The problem was that with_cocoa_lock_on_main_thread() is asynchronous. It will not wait until it is finished. In the uninit case, this means the VO could be deallocated and destroyed while cocoa was still running uninit code. So simply wait until it is done by using dispatch_sync(). There were concerns that this could introduce a deadlock by the main thread trying to wait for something on the VO thread. But from what I can see, this never happens, and even if it does, it would crash anyway since the VO is already gone. One remaining worry is the video_resize_redraw_callback. From what I can see, it still can mess things up, and will need a more elaborate fix. (cherry picked from commit e7777563018fc711c873ba9480744f0961786077)
* vo_opengl: change default FBO formatwm42015-05-071-1/+1
| | | | | | | | | | Reduces (but likely does not remove) the danger of rounding intermediate values down to 8 bit. This is important for cscale, or any other processing that might store raw YUV values in framebuffers. Fixes #1918. (cherry picked from commit cf210c4ffc6d008dd2bdd7c5d4d031ecdcf05fb7)
* cocoa: always compile OSX application code with cocoawm42015-05-071-6/+2
| | | | | | | | | | | | | | | | This unbreaks compiling command line player and libmpv at the same time. The problem was that doing so silently disabled the OSX application thing - but the command line player can not use the vo_opengl Cocoa backend without it. The OSX application code is basically dead in libmpv, but it's not that much code anyway. If you want a mpv binary that does not create an OSX application singleton (and creates a menu etc.), you must disable cocoa completely, as cocoa can't be used anyway in this case. (cherry picked from commit 19a5b20752ecc7465cf17781f908e12bf4ca136d)
* vo_opengl: gl_lcms: make sure win32 unicode fopen() wrapper is enabledwm42015-05-071-0/+2
| | | | (cherry picked from commit dce941b99c9e098b8471528908d1509ab040b7a4)
* vo_rpi: update renderer size on display size changes toowm42015-05-071-0/+2
| | | | | | | | | | (Not sure why it worked without this when I tested the previous changes.) Untested, but should be fine. This is equivalent what is done on e.g. panscan changes. (cherry picked from commit 94a3a76ee31bdc00255dc231e99be9f9ad6f38fa)
* video/out: remove VOFLAG_FLIPPINGwm42015-05-073-12/+2
| | | | | | | | | I think this used to be quite important, because the ancient VfW support in MPlayer used to output flipped frames. This code has been dead in mpv for quite some time (because VfW decoders were removed, and the --flip option was dropped too), so get rid of it. (cherry picked from commit e185887ba0da9967337541ebd71e244fb2833c4f)
* vo_opengl: refactor wayland frame skippingwm42015-05-076-31/+33
| | | | | | | | | | | | | Currently, the wayland backend needs extra work to avoid drawing more often than the wayland frame callback allows. (This is not ideal, but will be fixed at a later time.) Unify this with the start_frame callback added for cocoa. Some details change for the better. For example, if a frame is dropped, and a redraw is done afterwards, the actually correct frame is redrawn, instead whatever was in the textures from before the dropped frame. (cherry picked from commit 0a7abbda6b555fb7746f737b52d0f00fb3e614db)
* cocoa: don't accidentally drop initial screen drawingwm42015-05-075-1/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | With --idle --force-window, or when started from the bundle, the cocoa code dropped the first frame. This resulted in a black frame on start sometimes. The reason was that the live resizing/redrawing code was invoked, which simply set skip_swap_buffer to false, blocking redrawing whatever was going to be rendered next. Normally this is done so that the following works: 1. vo_opengl draw a frame, releases GL lock 2. live resizing kicks in, redraw the frame 3. vo_opengl wants to call SwapBuffers, drawing a stale buffer overwritten by the live resizing code This is solved by setting skip_swap_buffer in 2., and querying it in 3. Fix this by resetting the skip_swap_buffer at a known good point: when vo_opengl starts drawing a new frame. The start_frame function returns bool, so that it can be merged with is_active in a following commit. (cherry picked from commit e23e4c7c603fc1cd911621d0f833031be4a6f7c7)
* vo: improve frame drop logic on high playback rateAvi Halachmi (:avih)2015-05-071-3/+11
| | | | | | | | | | | | | | | | | Commit f1746741dee6000b7fd139e7a10f72aba0674b3b changed the drop logic to have more slack (drop more frames but less frequent) to prevent drops due to timing jitter when the clip and screen have similar rates. However, if the clip has higher rate than the screen (or just higher playback rate), then that policy hurts smoothness since these "chunked drops" look worse than one frame drop at a time. This patch restores the old drop logic when the playback frame rate is higher than ~5% above the screen refresh rate, and solves this issue. Fixes #1897 (cherry picked from commit ffcad1a72b9a3bf5a7ac5ddcbfa71ec19b6faf9b)
* vo_rpi: update display size on display mode switcheswm42015-05-071-0/+23
| | | | (cherry picked from commit 8c7f3adb413ccea35aef3878f020d6a10e9ad5de)
* vo_rpi: actually draw a black backgroundwm42015-05-071-23/+65
| | | | | | | | | | Also factor the display size initialization into a separate function. For some reason this seems to work, although setting the background color using this 1x1 pixel bitmap does not work. I blame the RPI beign a terrible piece of hardware with even worse drivers. (cherry picked from commit 6ae66e717faa4e9ce286ff0532d4ec19a66faf49)
* x11: query ICC profile based on center of windowNiklas Haas2015-05-071-1/+3
| | | | | | | | | | | | Right now, the default behavior is to pick the numerically lowest screen ID that overlaps the window in any way - but this means that mpv will decide to pick an ICC profile in a pretty arbitrary way even if the window only overlaps another screen by a single pixel. The new behavior is to query it based on the center of the window instead. (cherry picked from commit daf4334697145f771c5085fb183e64dc65a967bd)
* vo_drm: zero screen buffers in reconfig function.akemi-san2015-04-281-0/+4
| | | | (cherry picked from commit 1e2e5043496aaf55c29e89289582f9fbf8001f8c)
* vo_drm: add window screenshots supportMarcin Kurczewski2015-04-281-0/+3
| | | | (cherry picked from commit 5f21a68ce9a7aeef3f6c395661af06ce9266c91e)
* player: add --window-scale optionwm42015-04-241-0/+2
| | | | Requested. Works similar to the property with the same name.
* w32_common: add more rounded-down frame ratesJames Ross-Gowan2015-04-251-0/+4
| | | | | Suggested by avih. This handles x/1.001 frame rates for all multiples of 24 and 30 under 144.
* w32_common: use the current monitor's refresh rateJames Ross-Gowan2015-04-251-9/+10
|
* vo_drm: fix return value for void functionMarcin Kurczewski2015-04-211-1/+1
|
* vo_drm: fix coding style to adhere to guidelinesMarcin Kurczewski2015-04-212-8/+8
|
* vo_drm: fix releasing VT if received signal twiceMarcin Kurczewski2015-04-211-0/+3
| | | | | | If user switched terminals frantically, mpv could get SIGUSR1 twice in a row, which, up until now, resulted in destroying CRTC twice. This caused it to segfault. After this fix, double SIGUSR1 should be ignored.
* vo_drm: add vertical syncMarcin Kurczewski2015-04-211-5/+45
|
* w32_common: prevent system sleepJames Ross-Gowan2015-04-201-1/+2
| | | | | | This prevents the machine from going to sleep while a video-only stream is playing. When audio is playing, the audio stack should make this request for us.
* vo_drm: extract vt_switcher to drm_commonMarcin Kurczewski2015-04-193-132/+225
|
* vo_drm: disable VT switcher for non-Linux systemsMarcin Kurczewski2015-04-191-2/+3
|
* vo_drm: fix logging problems with connectorsMarcin Kurczewski2015-04-181-1/+1
| | | | | | | Logging was meant to be silenced only when user uses connector auto-detection feature. If user supplies connector ID manually, he should see exact reason why connecting to this specific connector failed.
* vo_drm: fix VT behavior with auxiliary screensMarcin Kurczewski2015-04-181-2/+4
| | | | Fixes #1828
* vo_drm: fix VT switchingMarcin Kurczewski2015-04-181-55/+229
| | | | Fixes #1827
* vo: fix non-sense in init codewm42015-04-161-1/+1
| | | | | I assume this was intended to generate an initial change event in order to make the user read the initial values.
* vo: cosmetics: reindent VO listwm42015-04-161-23/+23
| | | | | And also undoxygenify a comment. (There used to be some inconsistent doxygen comments in MPlayer time; they are being removed on sight.)
* vo_drm: add KMS/DRM renderer supportMarcin Kurczewski2015-04-162-0/+517
| | | | Signed-off-by: wm4 <wm4@nowhere>
* x11: actually disable screensaverwm42015-04-152-12/+61
| | | | | | | | | | | | | | | | | | | We already use 2 screensaver APIs when attempting to disable the screensaver: XResetScreenSaver() (from xlib) and XScreenSaverSuspend (from the X11 Screen Saver extension). None of these actually work. On modern desktop Linux, we are expected to make dbus calls using some freedesktop-defined protocol (and possibly we'd have to fallback to a Gnome specific one). At least xscreensaver doesn't respect the "old" APIs either. Solve this by running the xdg-screensaver script. It's a terrible, ugly piece of shit (just read the script if you disagree), but at least it appears to work everywhere. It's also simpler than involving various dbus client libraries. I hope this can replace the --heartbeat-cmd option, and maybe we could remove our own DPMS/XSS code too.
* vo_opengl: change dwmflush option valueswm42015-04-141-1/+2
| | | | | Use a choice instead of an integer. This is incompatible, but I'm not adding any compatibility since this option was added recently.
* vo_rpi: explicitly reference MMAL VC driverwm42015-04-131-0/+8
| | | | | | | This is optional, but ensures that linking with -Wl,--as-needed does not drop the MMAL VC driver. The driver normally "registers" itself in the library constructor, but since no symbols are explicitly referenced, the linker could remove it with as-needed enabled.
* Update license headersMarcin Kurczewski2015-04-1331-181/+161
| | | | Signed-off-by: wm4 <wm4@nowhere>
* vo_opengl: slightly simplify check_gl_features()wm42015-04-111-25/+12
| | | | | | | | | | Not sure why this was so roundabout; probably to keep spam down if the user's OpenGL drivers are crap (but then just don't enable extended features), or because the "Disabling..." text was so repetitious. But there doesn't seem to be a good reason after all. Also, this could already overflow the fixed size disabled[] array. Just print the messages directly.
* vo_opengl: unify blend-subtitles-res and blend-subtitleswm42015-04-112-8/+7
|
* vo_opengl: fix blend-subtitles-res=video & anamorphic videowm42015-04-111-1/+6
| | | | | Since scaling the video changes the aspect ratio, we have to compensate for this when rendering subtitles.
* vo_opengl: add blend-subtitles-resNiklas Haas2015-04-102-4/+19
| | | | | This can be used to draw the subtitles at the video's native res, which can make them look more natural and increases performance.
* mp_image: remove redundant plane_w/h fieldswm42015-04-101-4/+5
| | | | Seems relatively painful in this case, but they are morally wrong.
* vo_opengl: use correct texture coordinates for nv12wm42015-04-101-1/+1
|
* opengl: win32 - add option 'dwmflush' to sync in DWMAvi Halachmi (:avih)2015-04-093-0/+59
| | | | | | | This could help in cases where the DWM (Windows desktop compositor) adds another layer of bufferring and therefore the SwapBuffers timing could get messed up. Signed-off-by: wm4 <wm4@nowhere>
* opengl: smoothmotion: wake up for next vsync a bit earlierAvi Halachmi (:avih)2015-04-091-1/+1
| | | | | | | | on my windows system this allows smoothmotion to work perfectly also in windowed mode. There's no real right or wrong here, with the the only goal being to always hit the next vsync. however, on cases where vsync timing is jittery (as could happen with DWM), this patch tries to aim to the middle of the vsync cycle to get as least affected as possible by such jitter.
* opengl: drop less frames when clip and display have similar fpsAvi Halachmi (:avih)2015-04-091-1/+9
| | | | | | | | adds 1 vsync interval "slack" before deciding to drop the first frame. it should help on cases of timing jitter (sleep duration, container timestamps, compositor vsync timing, etc). once the drop threshold has been crossed, it will keep dropping until perfect timing alignment. this prevents crossing the drop threshold back and forth repeatedly and therefore more resilient to frame drops
* vo_opengl_cb: deprecate mpv_opengl_cb_render()wm42015-04-091-2/+1
| | | | Its vp parameter made no sense anymore. Introduce a new one.
* vo_opengl_cb: add a function to report vsync timewm42015-04-091-0/+21
| | | | | | | And also let vo.c know of it. Currently, this does not help much, but will facilitate future improvements.
* vo_opengl_cb: fix video timing somewhatwm42015-04-091-2/+2
| | | | | | | | | | | | | | | | | | Increase the default queue size. This helps with "missed" frames due to the asynchronous nature of the API. All the other VOs are synchronous, so if rendering and displaying takes a while, the common code in vo.c will be blocked until it can continue. But with opengl-cb, vo.c might immediately push the next ready frame, which causes the current frame to be dropped _if_ it wasn't rendered yet. One could fix this by making vo.c wait a while (until the API user calls the render function, which pulls the frame). But setting the default queue size to 2 seems much simpler: instead of dropping the frame, it will be pushed to the API user once the next renderer call finishes. (This is still a bit strange, and will hopefully be cleaned up when video scheduling is redone, but for now this appears to deliver relatively good results.)
* vo_opengl: log used GLXFBConfigwm42015-04-091-0/+1
| | | | | Now don't ask me why the GLXFBConfig type is a pointer, but stores an integer ID.
* vo_opengl: remove unused functionwm42015-04-092-6/+0
|
* video/out: fix screenshot image formatswm42015-04-073-3/+3
| | | | | | | Use variants without alpha. I skipped vo_sdl, because format selection seems a bit more complicated here, and nobody cares about vo_sdl anymore.
* vaapi: fight with Intel's broken video decoding GL interopwm42015-04-051-24/+81
| | | | | | | | | | | | | | | | | | | | | | | | Use texture-from-pixmap instead of vaapi's "native" GLX support. Apparently the latter is unused by other projects. Possibly it's broken due that, and Intel's inability to provide anything non-broken in relation to video. The new code basically uses the X11 output method on a in-memory pixmap, and maps this pixmap as texture using standard GLX mechanisms. This requires a lot of X11 and GLX boilerplate, so the code grows. (I don't know why libva's GLX interop doesn't just do the same under the hood, instead of bothering the world with their broken/unmaintained "old" method, whatever it did. I suspect that Intel programmers are just genuine sadists.) This change was suggested in issue #1765. The old GLX support is removed, as it's redundant and broken anyway. One remaining issue is that the first vaPutSurface() call fails with an unknown error. It returns -1, which is pretty strange, because vaapi error codes are normally positive. It happened with the old GLX code too, but does not happen with vo_vaapi. I couldn't find out why.
* vo_opengl: make csp options consistent with vf_formatNiklas Haas2015-04-041