summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* w32_common: don't wait for GUI thread when polling for eventswm42016-08-051-8/+12
| | | | | | | | | | | | | | | | | | | | VOCTRL_CHECK_EVENTS is called on every frame. This is by design, and is supposed to check the event queue of the windowing API. With the decoupled GUI thread in w32_common.c this doesn't make too much sense, and the purpose of VOCTRL_CHECK_EVENTS is really reduced to checking event flags. Even worse, waiting on the GUI thread can interfere with playback, since win32 sometimes blocks the event loop (e.g. clicking the window title bar). Change the code such that we really only query the event flags. Use atomics to avoid having to add a new mutex. (We assume we always have real atomics available. The build system doesn't check this properly, and it could fall back to dummy atomics, which are not atomic.) Should help with #3393. Doesn't help if the core happens to send a synchronous request, most commonly via VOCTRL_SET_CURSOR_VISIBILITY or VOCTRL_UPDATE_PLAYBACK_STATE.
* vo_opengl_cb: log better error message if OpenGL not initialized by userwm42016-08-031-0/+6
| | | | | Otherwise opengl/video.c would confusingly complain about a wrong version, which in this case makes no sense.
* wayland_common: check for NULL current_output on fs switchingRostislav Pehlivanov2016-08-011-2/+3
| | | | | | | Prevents segfaults when a fullscreen switch is issued before fully initializing the VO. Doesn't change anything since the schedule_resize is only there to resize in case the image size switches, which happens long after init.
* wayland_common: provide the real scaled window resolutionRostislav Pehlivanov2016-08-011-3/+5
| | | | | | It makes more sense to completely abstract this scaling inside the backend so that internally the player only works with real actual drawn pixels.
* wayland_common: fix fullscreen image switching bugRostislav Pehlivanov2016-07-303-6/+4
| | | | | | | | | | | The problem was that when in fullscreen, switching between images did not issue a resize event, causing none of the images to be rendered correctly. This fixes the problem by issuing a resize event with the screen width and height. This commit also moves the zeroing of the events field to when it gets retrieved by mpv rather than randomly after a resize in the vo/backend code.
* wayland_common: prevent black bars on most non-native aspect ratiosRostislav Pehlivanov2016-07-301-0/+3
| | | | | | | | | ssurface_handle_configure()'s width and height are just hints given by the compositor, the application's free to not respect those strictly and to compensate for e.g. aspect ratio. This prevents crazy scenarios in which pictures with portrait aspect ratios have a huge black area to make them 16:9 or whatever the compositor feels like.
* wayland_common: clip window size to the display output sizeRostislav Pehlivanov2016-07-301-5/+7
| | | | | | | | With X11 it was usually left up to the window manager to prevent huge windows from being out of range, but no Wayland compositor will do this right now. Hugely improves usability when using mpv as an image viewer.
* wayland_common: flush wakeup_pipe on a wakeupRostislav Pehlivanov2016-07-301-8/+10
| | | | | | Missed during the recent changes. Also simplify error checking code and check for POLLNVAL as well (the display fd was never actually checked to be valid).
* osdep/io: introduce mp_flush_wakeup_pipe()Rostislav Pehlivanov2016-07-301-4/+2
| | | | Makes a fairly common occurence with wakeup_pipes easier to handle.
* wayland_common: remove untested/unusable wayland dnd codeRostislav Pehlivanov2016-07-302-188/+1
| | | | | Not worth keeping 200 lines of untestable as of today code which might be broken, if it hasn't been already.
* vo_opengl: remove the 3dlut-size npot2 restrictionNiklas Haas2016-07-252-1/+3
| | | | | | | | This requires changing the pixel upload alignment because the odd sizes might not be aligned to multiples of 4. Anyway, the restriction has no real benefit and the sizes in between 32 and 64 might be worth using, so just drop it.
* vo_opengl: reduce default 3dlut-size to 64x64x64Niklas Haas2016-07-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Following testing after ebe798a, this is a more than sufficient size to cover our use case. The old default was a drop of about 58 dB PSNR using the old code, and this new default is about 65 dB PSNR, so it's actually an improvement despite resulting in a smaller size. There was no outlier whatsoever when comparing sizes around the 64 neighbourhood (with every step corresponding to a PSNR drop of about 0.07 dB), so I picked this since it's a power of two and requires no change to the current 3dlut-size parsing logic. I also tested smaller sizes such as 32x32x32 which performed almost as well on colorful samples, but this results in noticeable black boost in the dark regions, which is pretty undesirable. Therefore, we should avoid going much further below 64x64x64. Either way, this new size is so fast to compute that the 3dlut cache is almost useless on my end. In fact, it might even be slower to load the profile from the cache than to recompute it from scratch. (For caches on a disk. For cache on a tmpfs, it makes no difference)
* x11: do not accidentally discard event flagswm42016-07-252-6/+5
| | | | | | | | | It seems vo_x11_check_events() was supposed to return the currently flagged events and reset them. But there are many places where vo_x11_check_events() is called without checking its return value. This could lead to forgotten events. Change the code such that they can't get lost.
* vo_opengl: increase 3DLUT accuracy at lower LUT sizesNiklas Haas2016-07-251-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | This code had the exact same texture indexing bug that the original scaler code had before the introduction of the LUT_POS macro to fix it. We can re-use this same macro here, and the performance drop is virtually entirely negligible. The benefit is greatly improved LUT accuracy as the 3DLUT size decreases - in particular, the old LUT started introducing more and more black crush the lower your LUT size is (because the error was essentially an over-contrast bias, with a magnitude linearly related to the lut size). The new code improves black stability as the LUT size decreases, and only at very low values (16 and below) do black levels start noticeably getting affected (due to crude linearization of the nonlinear response curve). The default value of 3dlut-size is definitely generous enough for this to make no difference out of the box, but it also causes no performance drop at all on my machine so I see no harm in improving the logic. Furthermore, this means we could easily decrease the default 3dlut size in a future commit, perhaps even down to 64x64x64 as a default. (But more testing is warranted here)
* vo_opengl: glctx can be NULL during initwm42016-07-211-1/+1
| | | | | | | This fixes a crash that can happen with the Cocoa backend: it calls vo_wakeup() during init, which calls vo_opengl.c/wakeup(). Fixes #3360.
* x11, wayland: do not accidentally close FD 0wm42016-07-212-2/+6
| | | | | | | | | | Both backends have code to close each FD of their wakeup_pipe array. This array is default-initialized with 0, which means if the backends exit before the wakeup pipe is created (e.g. when probing), they would close FD 0. Initialize the FDs with -1. Then we call close(-1) in these situations, which is perfectly allowed and has no bad consequences.
* vo: remove now unused event_fd handlingwm42016-07-212-62/+8
|
* wayland_common: make function declaration consistentRostislav Pehlivanov2016-07-211-23/+21
| | | | Half the code had a space before the arguments and half didn't.
* wayland: port to the new wakeup/wait_events frameworkRostislav Pehlivanov2016-07-214-71/+53
| | | | | | | | | | | | This fits natively into the vo/backend and allows to simplify the polling code. One new change is the fact that surface_handle_enter flags VO_EVENT_WIN_STATE and VO_EVENT_RESIZE instead of only VO_EVENT_WIN_STATE. Before this, the code hackily relied on the timeout and the loop in the wait_frame function to track and set the scaling factor. Instead, this triggers mpv to run a schedule_resize and adjust the new VO output dimensions immediately. This is also more accurate since surface_handle_enter() gets called when a surface is created, moved and resized, which is exactly what the rest of the player might be interested in.
* vo_opengl: add a tscale=linear direct implementationNiklas Haas2016-07-211-3/+10
| | | | | | | | | | This uses GLSL mix() instead of going through an indirect texture access. Easy to implement and might require less resources on some devices, since the oversample code was already essentially just a special case of this. Could be made the new default (as per issue #2685), but that should be done in a separate commit.
* cocoa: remove unused icc profile variablesAkemi2016-07-211-2/+0
|
* cocoa: update screen fps only if necessaryAkemi2016-07-211-1/+3
| | | | | we don't need to update the display refresh rate when going fullscreen or updating the colour profile
* x11: stop using vo.event_fdwm42016-07-208-1/+72
| | | | Instead let it do its own event loop wakeup handling.
* vo_opengl: allow backends to provide callbacks for custom event loopswm42016-07-206-17/+51
| | | | | | | Until now, this has been either handled over vo.event_fd (which should go away), or by putting event handling on a separate thread. The backends which do the latter do it for a reason and won't need this, but X11 and Wayland will, in order to get rid of event_fd.
* vo_wayland: fix high CPU usage due to busy pollingRostislav Pehlivanov2016-07-191-3/+3
| | | | | | There's no need to call wl_display_flush() since all the client-side buffered data has already been flushed prior to polling the fd. Instead only check for POLLIN and the usual ERR+HUP.
* x11: skip ICC update on every window movewm42016-07-182-11/+26
| | | | | | | Don't just cause vo_opengl to update the ICC profile every time the window is moved. Instead, explicitly check if the screen was changed. Mostly untested.
* vf_vavpp: get rid of mp_refqueue_is_interlaced()wm42016-07-153-11/+1
| | | | | | | | | This makes the difference between passing VA_FRAME_PICTURE or VA_BOTTOM_FIELD for progressive frames (that should be force- deinterlaced) to VAProcPipelineParameterBuffer.flags. VA-VPP doesn't really seem to care, and we can get rid of mp_refqueue_is_interlaced() entirely. It could be argued it's better to pass field flags instead of the progressive flag.
* vf_d3d11vpp: fix interlaced-only=no modewm42016-07-151-2/+2
| | | | | | "Real" frame flag vs. what we pretend it to be. It always used the real flag, and thus never deinterlaced unflagged frames, even if the suboption was set to "no".
* vf_d3d11vpp: add video processor selectionwm42016-07-151-5/+20
| | | | | Unfortunately completely useless. I still don't know how to force a video processor to use a specific algorithm, if it's even possible.
* videotoolbox: add yuv420p to --videotoolbox-formatwm42016-07-151-0/+10
|
* vo_opengl: hwdec: reset hw_subfmt fieldwm42016-07-158-0/+9
| | | | | | In theory, mp_image_params with hw_subfmt set to non-0 if imgfmt is not a hwaccel format is invalid. (It worked fine because nothing checks this yet.)
* video: change hw_subfmt meaningwm42016-07-156-26/+22
| | | | | | | | | | | | | | | | | | The hw_subfmt field roughly corresponds to the field AVHWFramesContext.sw_format in ffmpeg. The ffmpeg one is of the type AVPixelFormat (instead of the underlying hardware format), so it's a good idea to switch to this too for preparation. Now the hw_subfmt field is an mp_imgfmt instead of an opaque/API- specific number. VDPAU and Direct3D11 already used mp_imgfmt, but Videotoolbox and VAAPI had to be switched. One somewhat user-visible change is that the verbose log will now always show the hw_subfmt as image format, instead of as nonsensical number. (In the end it would be good if we could switch to AVHWFramesContext completely, but the upstream API is incomplete and doesn't cover Direct3D11 and Videotoolbox.)
* videotoolbox: add --hwdec=videotoolbox-copy for h/w accelerated decoding ↵Aman Gupta2016-07-153-9/+116
| | | | with video filters
* vo_opengl: angle: use WARP if there are no hw adaptersJames Ross-Gowan2016-07-121-2/+45
| | | | | | | | | | | | | | | This should get mpv working on Windows 7 machines without hardware accelerated graphics adapters. It already worked on Windows 8 and up because those systems would silently fall back to WARP if there was no graphics hardware installed. The normal MPGL_CAP_SW flag is not set, so unlike other opengl backends, this will choose a software adapter even if opengl:sw is not specified. The reason for this is, unlike on Linux, where vo_xv and vo_x11 can be used, mpv on Windows does not have any VO to fall back on when hardware acceleration isn't available, so if software adapters are rejected, the user won't see any video output when using the default settings. WARP seems to perform quite well, so it should be used in this case.
* vo_opengl: angle: try D3D9 when D3D11 fails eglInitializeJames Ross-Gowan2016-07-111-7/+8
| | | | | This will happen when D3D11 is present on the machine but the supported feature level is too low.
* vo_xv, vo_x11: fix typos in warningsJakub Wilk2016-07-092-3/+3
|
* vd_d3d11vpp: remove nonsensical flush callwm42016-07-081-5/+0
| | | | | | | | I made this call up because I sort of thought this makes senssssse. I'm now convinced that it does not, and even is actively harmful. I'm still quite in the dark how the DirectD 11 video API is supposed to work with synchronization, but at least for normal graphics this call would not make much sense.
* x11: add missing FocusChangeMaskwm42016-07-081-1/+1
| | | | | So we actually get FocusOut events. Disables key repeat when losing focus while a key is down.
* vo_vdpau: minor simplificationwm42016-07-071-19/+9
| | | | Remove some indirections that aren't needed anymore.
* vf, af: print filter labels in verbose modewm42016-07-061-0/+2
|
* vf: mark filter chain as uninitialized when mutating itwm42016-07-061-0/+2
| | | | | Sounds fair. Can be used to determine if the filter chain was mutated at all, and avoiding unconditional reinit if it wasn't.
* vf: don't clobber input params on reconfigure failurewm42016-07-061-1/+1
| | | | I think this is more robust, and future commits will rely on it.
* csp: document deviations from the references where they occurNiklas Haas2016-07-052-3/+27
| | | | | | | | | | These mostly happen in situations where the correct behavior is relatively new and not found in the wild (therefore not worth implementing) and/or extremely complicated (and thus not worth worrying about the potential edge cases and UI changes). Still, it's best to document these where they happen to guide the poor souls maintaining these files in the future.
* x11_common: silence xdg-screensaverBen Boeckel2016-07-051-1/+1
| | | | | Some screen lockers have a habit of dumping output to the terminal when their output is reset. Ignore its output to keep the TTY output clean.
* vo_opengl: angle: update the swapchain on resizeJames Ross-Gowan2016-07-041-1/+16
| | | | | | | | | | | | | This uses eglPostSubBufferNV to trigger ANGLE to check the window size and update the size of the swapchain to match, which is recommended here: https://groups.google.com/d/msg/angleproject/RvyVkjRCQGU/gfKfT64IAgAJ With the D3D11 backend, using eglPostSubBufferNV with a 0-sized update region will even skip the Present() call, meaning it won't block for a vsync period. Hopefully ANGLE will have a less hacky way of doing this in future. See the relevant ANGLE issue: http://anglebug.com/1438 Fixes #3301
* vo_opengl: error out gracefully when trying to use FBOs without FBO APIwm42016-07-041-0/+5
| | | | | | | | | | | This can for example happen with vo_opengl_cb, if it is used with a GL implementation that does not supports FBOs. (mpv itself should never attempt to use FBOs if they're not available.) Without this check it would trigger an assert() in our dummy glBindFramebuffer wrapper. Suspected cause of #3308, although it's still unlikely.
* vf_d3d11vpp: fix output image format if not doing any filteringwm42016-07-041-2/+5
| | | | | | | For example it should be set to IMGFMT_D3D11NV12 if it isn't already. Otherwise, an assertion in vf.c could trigger. This probably couldn't be provoked yet.
* vo_opengl: move eval_szexpr to user_shaders.cNiklas Haas2016-07-033-102/+124
| | | | | | This moves some of the bulky user-shader specific logic into the file dedicated to it. Rather than expose video.c state, variable lookup is now done via a simulated closure.
* vd_lavc: expose mastering display side data reference peakNiklas Haas2016-07-032-1/+26
| | | | | | | | | | | | | | | | | | | This greatly improves the result when decoding typical (ST.2084) HDR content, since the job of tone mapping gets significantly easier when you're only mapping from 1000 to 250, rather than 10000 to 250. The difference is so drastic that we can now even reasonably use `hdr-tone-mapping=linear` and get a very perceptually uniform result that is only slightly darker than normal. (To compensate for the extra dynamic range) Due to weird implementation details, this only seems to be present on keyframes (or something like that), so we have to cache the last seen value for the frames in between. Also, in some files the metadata is just completely broken / nonsensical, so I decided to apply a simple heuristic to detect completely broken metadata.
* vo_opengl: generalize HDR tone mapping mechanismNiklas Haas2016-07-038-91/+136
| | | | | | | | | | | | | | | | | | | | | | | | This involves multiple changes: 1. Brightness metadata is split into nominal peak and signal peak. For a quick and dirty explanation: nominal peak is the brightest value that your color space can represent (i.e. the brightness of an encoded 1.0), and signal peak is the brightest value that actually occurs in the video (i.e. the brightest thing that's displayed). 2. vo_opengl uses a new decision logic to figure out the right nom_peak and sig_peak for all situations. It also does a better job of picking the right target gamut/colorspace to use for the OSD. (Which still is and still should be treated as sRGB). This change in logic also fixes #3293 en passant. 3. Since it was growing rapidly, the logic for auto-guessing / inferring the right colorimetry configuration (in pass_colormanage) was split from the logic for actually performing the adaptation (now pass_color_map). Right now, the new logic doesn't do a whole lot since HDR metadata is still ignored (but not for long).
* mp_image: split colorimetry metadata into its own structNiklas Haas2016-07-0319-124/+135
| | | | | | | | | | | | | | | | | | This has two reasons: 1. I tend to add new fields to this metadata, and every time I've done so I've consistently forgotten to update all of the dozens of places in which this colorimetry metadata might end up getting used. While most usages don't really care about most of the metadata, sometimes the intend was simply to “copy” the colorimetry metadata from one struct to another. With this being inside a substruct, those lines of code can now simply read a.color = b.color without having to care about added or removed fields. 2. It makes the type definitions nicer for upcoming refactors. In going through all of the usages, I also expanded a few where I felt that omitting the “young” fields was a bug.
* vo_opengl: don't constantly resize the output FBONiklas Haas2016-07-031-1/+1
| | | | | | | | | | Commit 883d3114 seems to have (accidentally?) dropped the FBOTEX_FUZZY from the output_fbo resize, which means that current master will keep resizing and resizing the FBO as you change the window size, introducing severe memory leaking after a while. (Not sure why that would cause memory leaks, but I blame nvidia) Either way, it's bad for performance too, so it's worth fixing.
* sub: move RGBA scaling to vo_vaapiwm42016-07-031-7/+25
| | | | | | | | | vo_vaapi is the only thing which can't scale RGBA on the GPU. (Other cases of RGBA scaling are handled in draw_bmp.c for some reason.) Move this code and get rid of the osd_conv_cache thing. Functionally, nothing changes.
* vo_opengl: remove caching GL_MAX_TEXTURE_SIZE valuewm42016-07-031-11/+15
| | | | | | | No real need to cache this, and we need fewer fields in the OSD part struct. Also add logging for when the OSD texture is reallocated.
* vo_opengl: use ringbuffer of PBOswm42016-07-032-7/+13
| | | | | | | | This is how PBOs are normally supposed to be used. Unfortunately I can't see an any absolute improvement on nVidia binary drivers and playing 4K material. Compared to the "old" PBO path with 1 buffer, the measured GL time decreases significantly, though.
* vo_opengl: support inconsistent negative strides per planewm42016-07-031-8/+10
| | | | | | | | | | | | | | | GL generally does not support flipping the image on upload, meaning negative strides are not supported. vo_opengl handles this by flipping rendering if the stride is inverted, and gl_pbo_upload() "ignores" negative strides by uploading without flipping the image. If individual planes had strides with different signs, this broke. The flipping affected the entire image, and only the sign of the first plane was respected. This is just a crazy corner case that will never happen, but it turns out this is quite simple to support, and actually improves the code somewhat.
* vo_opengl: move PBO upload handling to shared codewm42016-07-034-140/+91
| | | | | | | | | | | | | This introduces a gl_pbo_upload_tex() function, which works almost like our gl_upload_tex() glTexSubImage2D() wrapper, except it takes a struct which caches the PBO handles. It also takes the full texture size (to make allocating an ideal buffer size easier), and a parameter to disable PBOs (so that the caller doesn't have to duplicate the gl_upload_tex() call if PBOs are disabled or unavailable). This also removes warnings and fallbacks on PBO failure. We just silently try using PBOs on every frame, and if that fails at some point, revert to normal texture uploads. Probably doesn't matter.