summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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
|
* video/out: do remaining config to reconfig replacementswm42014-01-2410-108/+63
| | | | | | | The main difference between the old and new callbacks is that the old callbacks required passing the window size, which is and always was very inconvenient and confusing, since the window size is already in vo->dwidth and vo->dheight.
* aspect: remove a small ffmpeg dependencywm42014-01-221-4/+2
| | | | | Not strictly needed, but probably saves us pain the next time ffmpeg mess up their headers.
* vo: merge get rid of vo.aspdat fieldwm42014-01-225-109/+91
| | | | | | | | | | | | Rename vo_get_src_dst_rects() to mp_get_src_dst_rects() and make it independent from the VO (it takes a comical amount of parameters now to pass all required state). Add a convenience wrapper with the name vo_get_src_dst_rects() to vo.c. Replace all aspdat and vo usages with immediate parameters. Functionally, nothing should change, except that the window size is clamped to a minimum of size 1 much earlier, and some log messages change the prefix (don't bother with vo.vo_log stuff).
* vo: move vo_get_src_dst_rects to aspect.cwm42014-01-222-128/+130
| | | | | | | The plan is to make all the code in aspect.c independent from vo.c, which should make the code easier to understand, will allow removal of vo->aspdat, and reduces the amount of code that accesses weird mutable struct vo fields.
* video/out: don't access aspdat in VOswm42014-01-228-47/+20
| | | | | | | | | | | vo->aspdat is basically an outdated version of vo->params, plus some weirdness. Get rid of it, which will allow further cleanups and which will make multithreading easier (less state to care about). Also, simplify some VO code by using mp_image_set_attributes() instead of caring about display size, colorspace, etc. manually. Add the function osd_res_from_image_params(), which is often needed in the case OSD renders into an image.
* vo_opengl: don't assume there'a always 1 fbconfig on successwm42014-01-211-1/+1
| | | | Seems to be a reasonable assumption, but it's probably not guaranteed.
* cocoa: remove dead codeStefano Pigozzi2014-01-212-8/+0
| | | | This became dead code in commit 3f594c2e.
* w32_common: Fix extended keysJames Ross-Gowan2014-01-211-1/+1
| | | | The KF_* flags work on the HIWORD of lParam. Whoops
* w32: use the w32_common keymap in terminal-win tooJames Ross-Gowan2014-01-191-58/+5
|
* sub: uglify OSD code path with lockingwm42014-01-1810-11/+12
| | | | | | | | | | | | | | | Do two things: 1. add locking to struct osd_state 2. make struct osd_state opaque While 1. is somewhat simple, 2. is quite horrible. Lots of code accesses lots of osd_state (and osd_object) members. To make sure everything is accessed synchronously, I prefer making osd_state opaque, even if it means adding pretty dumb accessors. All of this is meant to allow running VO in their own threads. Eventually, VOs will request OSD on their own, which means osd_state will be accessed from foreign threads.
* w32_common: add extended keysJames Ross-Gowan2014-01-151-23/+54
| | | | Also VK_APPS/MP_KEY_MENU was missing.
* w32_common: prevent decoding certain keys twiceJames Ross-Gowan2014-01-151-12/+34
| | | | | | | | This is a bit of a hack, but in order to prevent TranslateMessage from seeing WM_KEYDOWN messages that we already know how to decode, move the decoding logic to the event loop. This should fix #476, since it stops the generation of extraneous WM_CHAR messages that were triggering more than one action on keydown.
* options: remove --screenw and --screenhwm42014-01-111-7/+2
| | | | | | | | | Doesn't make any sense anymore. X11 (which was mentioned in the manpage) autodetects it, and everything else ignored the option values. Since for incomprehensible reasons the backends and vo.c still need to exchange information about the screensize using the option fields, they're not removed yet.
* video/out: remove pointless x/y parameter from vo_x11_config_vo_windowwm42014-01-117-15/+10
| | | | | This never made any real sense; the "backend" has to access vo->dx/dy anyway.
* video/out: simplify monitor aspect handlingwm42014-01-119-39/+25
| | | | | | | | For some reason, this made all VO backends both set the screen resolution in opts->screenwidth/height, and call aspect_save_screenres(). Remove the latter. Move the code to calculate the PAR-corrected window size from aspect.c to vo.c, and make it so that the monitor PAR is recalculated when it makes sense.
* video/out: remove fallback handling for screensize/monitor pixel aspectwm42014-01-111-7/+1
| | | | | | | When using --monitoraspect, but either the screen width or height or both are unknown, a fallback is applied. This is a completely useless obscure corner case that's going to help nobody, so get it out of the way.
* cocoa: fix window placement on secondary screensStefano Pigozzi2014-01-111-3/+2
| | | | | | | | | | | | | | For a long time the cocoa backend set the xinerama_x/y and used dx/dy from the VO instance. This somewhat worked with some workarounds but wasn't really what was supposed to be happening. Moreover 27e4360, which touched this workaround introduced a regression. New code doesn't set the xinerama_x/y values so that dx/dy are offsets in the current screen (not a virtual screen composed of all the screens). The screen reference detected during VOCTRL_UPDATE_SCREENINFO is also passed down to the window initialization code. Fixes #472
* vd_lavc: matroska: remove weird code setting extra_huff for mjpegwm42014-01-111-12/+0
| | | | | | | | | | | Like with the previous commit, this is probably not needed, but it's unclear whether that really is the case. Most likely, it used to be needed by some demuxer, and now the only demuxer left that could _possibly_ trigger this is demux_mkv.c. Note that mjpeg is the only decoder that reads the extra_huff option, and nothing in libavformat actually sets the option. So maybe it's fundamentally not needed anymore.
* vd_lavc: matroska: remove weird realvideo special handlingwm42014-01-111-16/+1
| | | | | | | | | | | | | This case can't happen with the normal realvideo codepath in demux_mkv.c, because the code would errors out if the extradata is too small, and everything would be broken anyway in the case the vd_lavc.c condition is actually triggered. It still might happen with VfW-muxed realvideo in Matroska, though. Basically, I'm hoping this doesn't matter anyway, and that the vd_lavc.c code was for other old demuxers, like demux_avi or demux_rm. Following the commit history, it's not really clear for what demuxer this code was added.
* vd_lavc: minor simplificationwm42014-01-111-11/+2
|
*