summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* cocoa: refactor sync scheduling to a functionStefano Pigozzi2014-04-281-14/+18
| | | | | | | | | This extracts the scheduling logic to a single function which is nicer to keep it consistent. Additionally make sure we don't schedule sync operations from a sync operation itself since that could cause deadlocks (even if it should not be happening with the current code).
* cocoa: use mainScreen as a fallback for window constrainingStefano Pigozzi2014-04-281-1/+1
|
* cocoa: disallow the titlebar to exit the visibleFrame on the bottom edgeStefano Pigozzi2014-04-281-6/+7
|
* cocoa: add constraints to prevent the window to exit the screenStefano Pigozzi2014-04-281-9/+21
| | | | | | | | Previously the window could be made to completly exit the screen with a combination or moving it close to an edge and halving it's size (via cmd+0). This commit address the problem in the most simple way possibile by constraining the window to the closest edge in these edge cases.
* cocoa: move sync section assignments in vo_controlRyan Goulden2014-04-281-4/+4
|
* cocoa: cosmetics: use NSMakeSizeRyan Goulden2014-04-281-1/+1
|
* cocoa: fix native fullscreenRyan Goulden2014-04-283-62/+71
| | | | | | | | | | | | | | | | | | | | | | | This fixes a couple of issues with the Cocoa `--native-fs` mode, primarily: - A ghost titlebar at the top of the screen in full screen: This was caused by the window constraining code kicking in during fullscreen. Simply returning the unconstrained rect from the constraining method fixes the problem. - Incorrect behavior when using the titlebar buttons to enter/exit fullscreen, as opposed to the OSD button. This was caused by mpv's internal fullscreen state going out of sync with the NSWindow's one. This was the case because `toggleFullScreen:` completely bypassed the normal event flow that mpv expects. Signed-off-by: Ryan Goulden <percontation@gmail.com> Change style for mpv, simplify and refactor some of the constraining code. Signed-off-by: Stefano Pigozzi <stefano.pigozzi@gmail.com>
* Revert "wayland: print waylands display erros"Alexander Preisinger2014-04-261-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
* vo: do not check for events on unconfigured VOMartin Herkt2014-04-251-1/+3
| | | | fixes #741
* vo: simplify event_fd handlingwm42014-04-222-22/+13
| | | | | | Add the event FD after preinit, remove it before destroy. There's no need to do it on vo_config, and there's no need to remove the event FD when vo_config fails.
* vo: cosmetics: move around some codewm42014-04-221-134/+136
| | | | Group together related functionality.
* vo: minor cosmetic changewm42014-04-221-2/+1
|
* vo: warn if the VO doesn't support certain flagswm42014-04-221-1/+15
| | | | | | | | | Unfortunately, if a VO can't display something as intended, we can just complain to the user, and leave it at it. But it's still better than silently displaying things differently with different VOs. For now, this is used for rotation only. Other things that we should check includes colorspace and colorlevels stuff.
* vo_opengl: support rotationwm42014-04-212-15/+48
| | | | | | | | | | | This turned out much more complicated than I thought. It's not just a matter of adjusting the texture coordinates, but you also have to consider separated scaling and panscan clipping, which make everything complicated. This actually still doesn't clip 100% correctly, but the bug is only visible when rotating (or flipping with --vf=flip), and using something like --video-pan-x/y at the same time.
* vo: add some general support code for VOs that allow rotationwm42014-04-214-12/+30
| | | | | | For rotation, we assume that the source image will be rotated within the VO, so the aspect/panscan code needs to calculate its param using rotated coordinates. VOs which support rotation natively can use this.
* vo_opengl: clean up rendering pathwm42014-04-211-76/+94
| | | | | Shuffle the special cases around so that it looks cleaner. The result should be equivalent to the code before.
* video: make mp_image use mp_image_params directlywm42014-04-212-3/+4
| | | | | Minor cleanup, so that we can stuff more information into mp_image_params later.
* Fix some libav* include statementswm42014-04-193-10/+9
| | | | | | | | | | | | | Fix all include statements of the form: #include "libav.../..." These come from MPlayer times, when FFmpeg was somehow part of the MPlayer build tree, and this form was needed to prefer the local files over system FFmpeg. In some cases, the include statement wasn't needed or could be replaced with mpv defined symbols.
* w32_common: use ToUnicode to translate key inputJames Ross-Gowan2014-04-172-50/+184
| | | | | | | | | | | | | | | | This replaces translate_key_input with a solution that gives mpv more control over how keyboard input is converted to unicode. As a result: - Key up/down events are generated the same way for all keys. - Dead keys generate their base character instead of being combined with the following character. - Many Ctrl and Ctrl+Alt key combinations that were previously broken are fixed, since it's possible to discover the base keys. - AltGr doesn't produce special characters when mp_input_use_alt_gr is false. This also fixes some logic to do with detecting AltGr and adds proper UTF-16 decoding.
* vo_opengl: make spline36 default with --vo=opengl-hqwm42014-04-171-1/+1
|
* wayland: unset input regions for osdAlexander Preisinger2014-04-161-0/+4
| | | | | Set a zero sized input region for the osd surfaces in order to avoid getting input for the subsurfaces which might dissapear any time.
* wayland/shm: Use subsurfaces for OSDAlexander Preisinger2014-04-164-29/+133
|
* Kill all tabswm42014-04-131-6/+6
| | | | | | | | | | | I hate tabs. This replaces all tabs in all source files with spaces. The only exception is old-makefile. The replacement was made by running the GNU coreutils "expand" command on every file. Since the replacement was automatic, it's possible that some formatting was destroyed (but perhaps only if it was assuming that the end of a tab does not correspond to aligning the end to multiples of 8 spaces).
* wayland: don't schedule resize if going fullscreenRicardo Vieira2014-04-131-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-111-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-081-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-081-0/+2
| | | | This wasn't necessarily clear.
* vo_vdpau: simplify previous vsync timestamp calculationwm42014-04-081-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-071-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.
* gl_lcms: properly expand the cache filename being writtenStefano Pigozzi2014-04-051-1/+3
| | | | | This is needed to preserve the same path used when opening the cache file, and correctly expands ~ when icc-cache is added to the mpv config file.
* vo_vdpau: more debugging outputwm42014-04-031-4/+20
| | | | Might help to debug certain problems with Mesa.
* gl_lcms: fix build when lcms2 is not availableStefano Pigozzi2014-03-311-0/+5
| | | | Was broken in b0ee9334e.
* vo_corevideo: remove unused variableStefano Pigozzi2014-03-311-1/+0
|
* vo_opengl, cocoa: allow to autoselect a color profileStefano Pigozzi2014-03-317-2/+219
| | | | | | | | | | | | | This commit adds support for automatic selection of color profiles based on the display where mpv is initialized, and automatically changes the color profile when display is changed or the profile itself is changed from System Preferences. @UliZappe was responsible with the testing and implementation of a lot of this commit, including the original implementation of `cocoa_get_icc_profile_path` (See #594). Fixes #594
* Fix compilation on OSX and win32wm42014-03-292-2/+1
| | | | Probably.
* video/out: remove legacy colorspace stuffwm42014-03-2912-135/+106
| | | | | | | | | 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.
* vo_opengl: runtime icc profile switchingwm42014-03-242-19/+40
| | | | | The changes in vo_opengl.c are merely for adding the icc options to the set of options than can be changed with the vo_cmdline command.
* x11_common: fix some problems with window draggingwm42014-03-221-1/+2
| | | | | | | | | | | | | | | | There were some bad interactions with the OSC. For one, dragging the OSC bar, and then moving the mouse outside of the OSC (while mouse button still held) would suddenly initiate window dragging. This was because win_drag_button1_down was not reset when sending a normal mouse event, which means the window dragging code can become active even after we've basically decided that the preceding click didn't initiate window dragging. Second, dragging the window and clicking on the OSC bar after that did nothing. This was because no mouse button up event was sent to the core, even though a mouse down event was sent. So make sure the key state is erased with MP_INPUT_RELEASE_ALL.
* vdpau: remove pointer indirection for a fieldwm42014-03-192-4/+4
| | | | There's no reason to. This is basically a cosmetic change.
* x11: implement window dragging by grabbingwm42014-03-182-1/+37
| | | | | | | | | | | | | | | | | | We don't check whether the WM supports _NET_WM_MOVERESIZE_MOVE, but if it doesn't, nothing bad happens. There might be a race condition when pressing a button, and then moving the mouse and releasing the button at the same time; then the WM might get the message to initiate moving the window after the mouse button has been released, in which case the result will probably be annoying. This could possibly be fixed by sending _NET_WM_MOVERESIZE_CANCEL on button release, but on the other hand, we probably won't receive a button release event in this situation, so ignore this problem. The dragging is initiated only when moving the mouse pointer after a click in order to reduce annoying behavior when the user is e.g. doubleclicking. Closes #608.
* vaapi: make struct va_surface privatewm42014-03-172-10/+9
| | | | | | It's not really needed to be public. Other code can just use mp_image. The only disadvantage is that the other code needs to call an accessor to get the VASurfaceID.
* vaapi: replace image pool implementation with mp_image_poolwm42014-03-171-18/+19
| | | | | | | | | | | | Although I at first thought it would be better to have a separate implementation for hwaccels because the difference to software images are too large, it turns out you can actually save some code with it. Note that the old implementation had a small memory management bug. This got painted over in commit 269c1e1, but is hereby solved properly. Also note that I couldn't test vf_vavpp.c (due to lack of hardware), and I hope I didn't accidentally break it.
* vdpau: remove legacy pixel formatswm42014-03-171-2/+1
| | | | | | They were used by ancient libavcodec versions. This also removes the need to distinguish vdpau image formats at all (since there is only one), and some code can be simplified.
* encode: use new AVFrame APIwm42014-03-161-5/+3
|
* w32_common: prevent MOUSE_BTN0 sticking after dragJames Ross-Gowan2014-03-121-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-121-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.
* vo_opengl: Correct and clarify gl_check_featuresNiklas Haas2014-03-101-11/+24
| | | | | | | This updates the logic for the new, somewhat unified behavior of SRGB and 3DLUT since 34bf9be (not that it was particularly correct even that change) and checks for the presence of corresponding extensions only in the cases in which they're needed.
* vo_opengl: Simplify and clarify color correction codeNiklas Haas2014-03-105-48/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit: - Changes some of the #define and variable names for clarification and adds comments where appropriate. - Unifies :srgb and :icc-profile, making them fit into the same step of the decoding process and removing the weird interactions between both of them. - Makes :icc-profile take precedence over :srgb (to significantly reduce the number of confusing and useless special cases) - Moves BT709 decompanding (approximate or actual) to the shader in all cases, making it happen before upscaling (instead of the old 0.45 gamma function). This is the simpler and more proper way to do it. - Enables the approx gamma function to work with :srgb as well due to this (since they now share the gamma expansion code). - Renames :icc-approx-gamma to :approx-gamma since it is no longer tied to the ICC options or LittleCMS. - Uses gamma 2.4 as input space for the actual 3DLUT, this is now a pretty arbitrary factor but I picked 2.4 mainly because a higher pure power value here seems to produce visually better results with wide gamut profiles, rather then the previous 1.95 or BT.709. - Adds the input gamma space to the 3dlut cache header in case we change it more in the future, or even make it user customizable (though I don't see why the latter would really be necessary). - Fixes the OSD's gamma when using :srgb, which was previously still using the old (0.45) approximation in all cases. - Updates documentation on :srgb, it was still mentioning the old behavior from circa a year ago. This commit should serve to both open up and make the CMS/shader code much more accessible and less confusing/error-prone and simultaneously also improve the performance of 3DLUTs with wide gamut color spaces. I would liked to have made it more modular but almost all of these changes are interdependent, save for the documentation updates. Note: Right now, the "3DLUT takes precedence over SRGB" logic is just coded into gl_lcms.c's compile_shaders function. Ideally, this should be done earlier, when parsing the options (by overriding the actual opts.srgb flag) and output a warning to the user. Note: I'm not sure how well this works together with real-world subtitles that may need to be color corrected as well. I'm not sure whether :approx-gamma needs to apply to subtitles as well. I'll need to test this on proper files later. Note: As of now, linear light scaling is still intrinsically tied to either :srgb or :icc-profile. It would be thinkable to have this as an extra option, :linear-scaling or similar, that could be used with or without the two color management options.
* vo_opengl: Use bt709_expand on OSD for :srgbNiklas Haas2014-03-101-1/+1
| | | | | This affects the OSD only when :srgb is enabled, this still used the old gamma approximation of 2.22 previously.
* encode: add lockingwm42014-03-091-16/+37
| | | | | | | | | | Since the AO will run in a thread, and there's lots of shared state with encoding, we have to add locking. One case this doesn't handle correctly are the encode_lavc_available() calls in ao_lavc.c and vo_lavc.c. They don't do much (and usually only to protect against doing --ao=lavc with normal playback), and changing it would be a bit messy. So just leave them.
* wayland/shm: fix leak in buffer poolAlexander Preisinger2014-03-061-10/+13
| | | | Rename it to reinit and check if parts of the pool are already allocated.
* vo_opengl: minor simplificationwm42014-03-011-30/+24
| | | | I think this is easier to follow.
* vo_opengl: Include :icc-approx-gamma option in the 3DLUT cache headerNiklas Haas2014-03-011-2/+3
| | | | | This makes sure the ICC cache is recomputed when the :icc-approx-gamma option is changed, since it affects the output quite a lot.
* vo_opengl: change gamma suboption to take a valuewm42014-02-272-7/+8
| | | | | | | | | | | | The previous version of the gamma suboption was pretty useless. It could be used to disable delayed gamma enabling, which is a mechanism to avoid having to adjust gamma in the shader by default. Repurpose the suboption and allow setting an exact gamma value with it. You can already override gamma with the --gamma option as well as the gamma input property, but these use a weird curve to create the impression of a linear perceived brightness change when changing the value. This suboption now allows setting an exact gamma value.
* vo_opengl: Change the default icc-intent to relative colorimetricNiklas Haas2014-02-261-1/+1
| | | | | | | | | | | | | | | | This used to be absolute colorimetric, but relative colorimetric is a saner default due to the arguments presented in issue #595. A short summary: In general it doesn't affect much because our eyes adapt to the white point either way, but if running in windowed mode it would make the whites seem inconsistent/tinted. For fullscreen projection it's also undesirable since it reduces the dynamic range without much benefit (again, since our eyes adapt either way) and it also breaks calibration against ambient lighting. This shouldn't change much, since most profile types that aren't 3DLUTs aren't capable of either of those transforms, and most displays are calibrated against D65 (same as BT.709 source) either way.
* vo_opengl: Add :icc-approx-gamma suboption to approximate BT.709 gammaNiklas Haas2014-02-242-6/+17
| |