summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
...
* 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 the vo_opengl case. (That damn hidden window again...)
* x11: remove apparently useless codewm42014-02-021-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-021-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.)
* vo_wayland: silence shadowing warningwm42014-01-291-3/+3
| | | | No real problem.
* mp_image: reject too large image sizeswm42014-01-291-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-281-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-281-1/+4
|
* wayland/shm: remove resize boilerplateAlexander Preisinger2014-01-281-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_sdl: fix compilationwm42014-01-251-2/+2
| | | | | | Still untested, because now it crashes inside of libSDL for unknown reasons. (This also happens with mpv git from yesterday - probably an installation problem, or SDL doing weird things it shouldn't be doing.)
* vo_wayland: fix confusion of video and window sizeswm42014-01-241-2/+2