summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* mp_image: add missing field to mp_image_params_equals()wm42014-03-281-0/+1
| | | | | | This is pretty obscure, so it didn't matter much. It still breaks switching output levels at runtime, because the video output is not reinitialized with the new params.
* 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-195-14/+13
| | | | There's no reason to. This is basically a cosmetic change.
* vdpau: fix decoder init return valuewm42014-03-191-3/+3
|
* 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: solve potential problem with ambiguous image formatswm42014-03-171-32/+27
| | | | | | | | | | | | | VAAPI has some ambiguous image formats, like VA_FOURCC_I420, VA_FOURCC_IYUV, VA_FOURCC_YV12 (the latter exactly the same as the first two, just with swapped planes). There is potentially a problem when one specific VAAPI format was picked, and converting it to a mpv format and back to a VAAPI FourCC would result in a numerically different format (even if it's actually the same). Then it could e.g. happen that functions like va_surface_upload() reallocate the underlying VAImage, which would be inefficient. Change the code so that this can't happen. (Probably not a problem in practice with the current VAAPI usage.)
* vaapi: simplifywm42014-03-171-67/+60
| | | | Merge va_surface_priv into va_surface.
* vaapi: make struct va_surface privatewm42014-03-176-90/+78
| | | | | | 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-175-241/+152
| | | | | | | | | | | | 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.
* mp_image_pool: add features needed for use with hwaccelwm42014-03-172-18/+69
| | | | | | | | | | | | | | The plan is to get rid of the custom VAAPI and possibly VDPAU surface allocators. Add custom surface allocation, because hwaccel surfaces are allocated completely differently from software surfaces. Add optional LRU allocation, which is (probably) helpful for hwaccel, but (probably) less optimal for software surfaces. mp_image_pool_get_no_alloc() is specifically for VAAPI, which can't allocate new decoder surfaces after decoder init.
* vdpau: remove legacy pixel formatswm42014-03-176-41/+10
| | | | | | 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.
* vdpau: remove unused typewm42014-03-171-6/+0
|
* video: change image format from unsigned int to int in some placeswm42014-03-176-12/+12
| | | | | | Image formats used to be FourCCs, so unsigned int was better. But now it's annoying and the only difference is that unsigned int is more to type than int.
* img_format: AV_PIX_FMT_FLAG_ALPHA is always availablewm42014-03-171-5/+0
| | | | We no more support ancient libavutil versions.
* vd_lavc: reinit hwdec on profile changeswm42014-03-172-2/+6
| | | | | Needed in theory. I don't know if there are even any real-world files which change the profile mid-stream.
* video: fix FFmpeg or Libav being a special snowflakewm42014-03-161-1/+2
|
* vd_lavc: remove unused fieldwm42014-03-162-3/+0
|
* vd_lavc: reduce hardware decoder mid-stream reinitializationswm42014-03-161-1/+6
| | | | | | | | | | Instead of doing it on every seek (libavcodec calls get_format on every seek), reinitialize the decoder only if the video resolution changes. Note that this may be relatively naive, since we e.g. (or: in particular) don't check for profile changes. But it's not worse than the state before the get_format change, and at least it paints over the current vaapi breakage (issue #646).
* encode: use new AVFrame APIwm42014-03-161-5/+3
|
* image_writer: use new AVFrame APIwm42014-03-161-3/+2
|
* vf_delogo: remove internal implementationwm42014-03-161-249/+2
| | | | See previous commit.
* vf_hqdn3d: remove internal implementationwm42014-03-161-276/+10
| | | | See previous commit.
* vf_yadif: remove internal implementationwm42014-03-161-467/+3
| | | | See previous commit.
* vf_unsharp: remove internal implementationwm42014-03-161-176/+3
| | | | See previous commit.
* vf_gradfun: remove internal implementationwm42014-03-161-339/+5
| | | | | | | This follows the (only slowly progressing) plan to replace all internal video filters with libavfilter. All what's left in vf_gradfun.c is the weird wrapper around vf_lavfi.c.
* build: simplify libavfilter configure checkswm42014-03-162-2/+2
| | | | | This is all not needed anymore. In particular, remove all configure switches except --enable-libavfilter.
* Remove some more unneeded version checkswm42014-03-161-12/+2
| | | | | All of these check against things that happened before the latest supported FFmpeg/Libav release.
* vd_lavc: remove compatibility crapwm42014-03-169-823/+29
| | | | | | | All this code was needed for compatibility with very old libavcodec versions only (such as Libav 9). Includes some now-possible simplifications too.
* vd_lavc: ridiculous workaround for Libav 9 compatibilitywm42014-03-163-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-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.
* video: initialize hw decoder in get_formatwm42014-03-104-46/+42
| | | | | | | | | | | | | | | | Apparently the "right" place to initialize the hardware decoder is in the libavcodec get_format callback. This doesn't change vda.c and vdpau_old.c, because I don't have OSX, and vdpau_old.c is probably going to be removed soon (if Libav ever manages to release Libav 10). So for now the init_decoder callback added with this commit is optional. This also means vdpau.c and vaapi.c don't have to manage and check the image parameters anymore. This change is probably needed for when libavcodec VDA supports gets a new iteration of its API.
* 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.
* vdpau: change the error message when video too largeAndrey Morozov2014-02-241-1/+2
|
* vo_opengl: Add :icc-approx-gamma suboption to approximate BT.709 gammaNiklas Haas2014-02-242-6/+17
| | | | | | This uses the value of 1.95 as an approximation for the exact gamma curve, which replicates the behavior of popular video software including anything in the Apple ecosystem, as per issue #534.
* video: add rounding to aspect ratio calculationswm42014-02-191-2/+2
| | | | | Small errors are unavoidable, but truncation can cause anamorphic video to be off by 1 or 2 pixels.
* vo_opengl: use GL_RGBA16 FBO format for HQGrigori Goronzy2014-02-171-1/+1
| | | | | GL_RGB16 is definitely not a required format, after review of the OpenGL 3.3 spec. Most HW doesn't have native support for RGB16 anyway.
* vo_corevideo: remove unused variableStefano Pigozzi2014-02-171-1/+0
|
* w32_common: don't set small iconJames Ross-Gowan2014-02-171-4/+1
| | | | | Windows will automatically choose the correct icon size if this field is unset.
* wayland/shm: remove unused defineAlexander Preisinger2014-02-161-2/+0
|
* csputils: provide string descriptions of chroma locationswm42014-02-162-0/+9
|
* 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.
* vo_wayland: silence shadowing warningwm42014-02-121-3/+3
|
* wayland/shm: rewrite buffer handlingAlexander Preisinger2014-02-111-131/+229
| | | | | | | | | | | I was unhappy with the old way of handling buffers, especially resizing. But my original plan to use wl_shm_pool_resize wasn't as good as I initially thought. I might get back to it. With the new buffer pools it now possible to select triple buffering. Also the buffer pools are also needed for the upcoming subsurfaces for osd and subtitles. I hope this change was worth it.
* wayland/shm: prevent the window from flying awayAlexander Preisinger2014-02-111-0/+2
| | | | With the new xdg_shell the problem will be no gone by itself.
* video: fix --no-aspectwm42014-02-111-2/+2
| | | | This also affects the --aspect option and the "aspect" property.
* vo_opengl: fix typo in gamma function's parameternand2014-02-101-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-101-0/+3
| | | | Some drivers do not supply timestamps, use old timestamp in these conditions.
* vo_vdpau: Ensure presentation time is within boundsJonas Zetterberg2014-02-101-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-091-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-061-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-061-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.
* csputils: correct constness of csp name constantswm42014-02-032-6/+6
|
* wayland: change minimum versionAlexander Preisinger2014-02-021-9/+0
| | | | | Change minimum version to 1.3 and remove the version checking in the source code.
* x11: fix initial VO sizewm42014-02-021-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 th