summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo/gpu: hwdec_cuda: Refactor gpu api specific code into separate filesPhilip Langdale2019-05-035-749/+845
| | | | | | | | The amount of code now present that's specific to Vulkan or OpenGL has reached the point where we really want to split it out to avoid a mess of #ifdefs. At the same time, I'm moving the code to an api neutral location.
* context_drm_egl: Add support for presentation feedbackAnton Kindestam2019-05-031-15/+118
| | | | | This implements presentation feedback for context_drm_egl using the values that get fed to the page flip handler.
* cocoa-cb: remove all force unwrappings of optionalsder richter2019-04-255-309/+411
| | | | | | the force unwrapping of optionals caused many unpredictable segfaults instead of gracefully exiting or falling back. besides that, it is bad practice and the code is a lot more stable now.
* vo_gpu/hwdec_cuda: fixup compilation with vulkan disabledJan Ekström2019-04-221-0/+2
| | | | | | | The actual code utilizing this enum was seemingly properly if'd, but not the enum in the struct itself. Fixes compilation.
* vo/gpu: hwdec_cuda: Reorganise backend-specific codePhilip Langdale2019-04-211-151/+223
| | | | | This tries to tidy up the GL vs Vulkan code to be a bit cleaner and easier to read.
* vo_gpu: hwdec_cuda: Implement interop for placeboPhilip Langdale2019-04-211-145/+224
| | | | | | | | | | | | | | | | | | | | This change updates the vulkan interop code to work with the libplacebo based ra_vk, but also introduces direct VkImage sharing to avoid the use of the intermediate buffer. It is also necessary and desirable to introduce explicit semaphore bsed synchronisation for operations on the shared images. Synchronisation means we can safely reuse the same VkImage for every mapped frame, by ensuring the frame is copied to the VkImage before mapping the next frame. This functionality requires a 417.xx or newer nvidia driver, due to bugs in the VkImage interop in the earlier 411 and 415 drivers. It's definitely worth the effort, as the raw throughput is about twice that of implementation using an intermediate buffer.
* vo/gpu: ra_pl: Add helper to get pl_fmt from ra_formatPhilip Langdale2019-04-211-0/+5
| | | | | | | When interacting directly with libplacebo, we may need to pass a pl_fmt based on an ra_format. Although the mapping is currently trivial, it's worth wrapping to make it easy to adapt if this changes in the future.
* vo_gpu: ra_pl: Add getter for pl_gpuPhilip Langdale2019-04-212-1/+8
| | | | | We need access to the underlying pl_gpu to make libplacebo calls from hwdecs.
* vo_gpu: vulkan: Add back context_win for libplaceboPhilip Langdale2019-04-212-3/+105
| | | | | Feature parity with the original ra_vk obviously requires win32 support, so let's put it back in.
* vo_gpu: vulkan: use libplacebo insteadNiklas Haas2019-04-2120-4355/+848
| | | | | | | | | | | | | | | | | | | | | | | | This commit rips out the entire mpv vulkan implementation in favor of exposing lightweight wrappers on top of libplacebo instead, which provides much of the same except in a more up-to-date and polished form. This (finally) unifies the code base between mpv and libplacebo, which is something I've been hoping to do for a long time. Note: The ra_pl wrappers are abstract enough from the actual libplacebo device type that we can in theory re-use them for other devices like d3d11 or even opengl in the future, so I moved them to a separate directory for the time being. However, the rest of the code is still vulkan-specific, so I've kept the "vulkan" naming and file paths, rather than introducing a new `--gpu-api` type. (Which would have been ended up with significantly more code duplicaiton) Plus, the code and functionality is similar enough that for most users this should just be a straight-up drop-in replacement. Note: This commit excludes some changes; specifically, the updates to context_win and hwdec_cuda are deferred to separate commits for authorship reasons.
* vo_gpu: fix segfault when OSD tex creation failsNiklas Haas2019-04-211-1/+1
| | | | If !osd->texture, then mpgl_osd_draw_prepare fails.
* vo_gpu: index desc namespaces by raNiklas Haas2019-04-215-5/+5
| | | | | No reason to require them be constant. This allows them to depend on runtime characteristics of the `ra`.
* cocoa-cb: add support for custom colored title barder richter2019-04-022-0/+20
|
* cocoa-cb: refactor title bar stylingder richter2019-04-022-49/+108
| | | | | | | | | | | | | half of the materials we used were deprecated with macOS 10.14, broken and not supported by run time changes of the macOS theme. furthermore our styling names were completely inconsistent with the actually look since macOS 10.14, eg ultradark got a lot brighter and couldn't be considered ultradark anymore. i decided to drop the old option --macos-title-bar-style and rework the whole mechanism to allow more freedom. now materials and appearance can be set separately. even if apple changes the look or semantics in the future the new options can be easily adapted.
* cocoa-cb: add support for mac 10.14 Dark mode and run time switchingAkemi2019-04-021-5/+10
| | | | | | setting the appearance of the window to nil will always use the system setting and changes on run time switches too. this is only the case for macOS 10.14.
* cocoa-cb: move all title bar related functionality in its own fileder richter2019-04-024-156/+178
| | | | | | | | | quite a lot of the title bar functionality and logic was within our window. since we recently added a custom title bar class to our window i decided to move all that functionality into that class and in its own file. this is also a preparation for the next commits.
* cocoa-cb: remove an unused variableAkemi2019-04-021-1/+0
|
* cocoa-cb: simplify CGL pixel format creationAkemi2019-04-021-57/+75
| | | | | | | | | | | | | | | i found the old pixel format creation a bit too messy. pixel format attribute arrays and look ups were all over the place, the actual logic what kind of format was created was inscrutable, the software pixel format was hardcoded and no probing was done. i split the attributes into mandatory and optional ones, one mandatory for a hardware and software pixel format each, and moved those to the top of the class. that way new attributes can be easily added to either the mandatory or optional attributes and they don't mess up the actual pixel creation logic any more. furthermore both hardware and software pixel formats are being probed the same way now. to minimise code duplications the probing was moved into its own function.
* cocoa-cb: add support for dragging certain strings onto the windowAkemi2019-04-021-2/+31
| | | | | | | | | | | | | | | only the dragged types NSFilenamesPboardType and NSURLPboardType were supported to be dropped on the window, which was inconsistent with the dragged types the dock icon supports. the dock icon additional supports strings that represents an URL or a path. the system takes care of validating the strings properly in the case of the dock icon, but in the case of dropping on the window it needs to be done manually. support for strings is added by also allowing the NSPasteboardTypeString type and manually validating the strings. strings are split by new lines and trimmed, to also support a list of URLs and paths. every new element is checked if being an URL or path and only then being added to the playlist.
* cocoa-cb: synchronise the flush with the renderAkemi2019-04-021-3/+2
| | | | | | | this could lead to a crash on deinit when flush was called while the opengl state was cleaned up. Fixes #6323
* cocoa-cb: fix a Cocoa window position on init bugAkemi2019-04-021-0/+13
| | | | | | | | | | | | on init an NSWindow can't be placed on a none Main screen NSScreen outside the Main screen's frame bounds. To fix this we just check if the target screen is different from the main screen and if that is the case we check the actual position with the expect one. if they are different we try to reposition the window to the wanted position. Fixes #6453
* cocoa-cb: fix Space switching when quitting fsAkemi2019-04-021-4/+6
| | | | | | | when quitting mpv in fullscreen the System always switchs to Space 1 regardless of which Space mpv was on previous to switching to fs. to fix this we close the window before quitting fs. that way the System switches back the the Space mpv was previous on before fs.
* cocoa-cb: notify vo when window is minimisedAkemi2019-04-021-0/+8
|
* cocoa-cb: fix crash when querying window stateAkemi2019-04-021-1/+2
| | | | Fixes #6489
* cocoa-cb: wakeup vo when new events are availableAkemi2019-04-021-0/+2
| | | | | | | new events were added but not fetched by the vo, because we didn't signal the vo that new events were available. actually wakeup the vo when new events are available.
* x11: fix cursor hiding initial statePhilip Sequeira2019-03-162-2/+4
| | | | | | | | | Regression from 8e3308d687c3acdd0d572015b06efd5b492d93ee. Broken cases were: * --no-cursor-autohide acted like --cursor-autohide=always. * --cursor-autohide-fs-only always hid the cursor if starting non-fullscreen; entering fullscreen at least once fixed it.
* vo_gpu: increase user shader size limitBin Jin2019-03-131-1/+1
| | | | | | | | | | | | | The old size limit was chosen before LUT texture was supported in user shader. At that time, the whole user shader will be compiled and run on GPU, which makes large user shader impractical to be used. With the introduction of LUT texture, the old size limit doesn't make any sense. For example, a 1024x1024 rgba16f LUT will cost 32MB shader size. Fix this by increasing the size limit to a value that's unlikely be reached.
* vo_libmpv: fix null pointer dereferencewnoun2019-03-111-3/+5
| | | | Closes: #6507
* Merge branch 'master' into pr6360Jan Ekström2019-03-1114-259/+387
|\ | | | | | | | | | | Manual changes done: * Merged the interface-changes under the already master'd changes. * Moved the hwdec-related option changes to video/decode/vd_lavc.c.
| * vo_gpu: add two useful operators to user shaderBin Jin2019-03-092-0/+7
| | | | | | | | | | | | | | | | modulo operator could be used to check if size is multiple of a certain number. equal operator could be used to verify if size of different textures aligns.
| * vo_gpu: make texture offset available to CHROMA hooksBin Jin2019-03-091-16/+25
| | | | | | | | | | | | | | | | | | | | Before this commit, texture offset is set after all source textures are finalized. Which means CHROMA hooks won't be able to align with luma planes. This could be problematic for chroma prescalers utilizing information from luma plane. Fix this by find the reference texture early, and set global texture offset early.
| * lcms: allow infinite contrastzc622019-03-091-1/+1
| | | | | | | | Fixes #5980
| * context_drm_egl: implement n-bufferingAnton Kindestam2019-02-251-59/+150
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows context_drm_egl to use as many buffers as libgbm or the swapchain_depth setting allows (whichever is smaller). On pause and on still images (cover art etc.) to make sure that output does not lag behind user input, the swapchain is drained and reverts to working in a dual buffered (equivalent to swapchain-depth=1) manner. When possible (swapchain-depth>=2), the wait on the page flip event is now not done immediately after queueing, but is deferred to the next invocation of swap_buffers. Which should give us more CPU time between invocations. Although, since gbm_surface_has_free_buffers() can only tell us a boolean value and not how many buffers we have left, we are forced to do this contortionist dance where we first overshoot until gbm_surface_has_free_buffers() reports 0, followed by immediately waiting so we can free a buffer, to be able to get the deferred wait on page flip rolling. With this commit we do not rely on the default vsync fences/latency emulation of video/out/opengl/context.c, but supply our own, since the places we create and wait for the fences needs to be somewhat different for best performance. Minor fixes: * According to GBM documentation all BO:s gotten with gbm_surface_lock_front_buffer must be released before gbm_surface_destroy is called on the surface. * We let the page flip handler function handle the waiting_for_flip flag.
| * opengl: Support GL_ARB_sync style fences on OpenGL ES 3.0Anton Kindestam2019-02-251-0/+1
| | | | | | | | | | OpenGL ES 3.0 and up has suppport for for GL_ARB_sync style fences. Make sure that mpv can use them.
| * vo_gpu: fix initial seeding of the peak detect ssboNiklas Haas2019-02-182-5/+7
| | | | | | | | | | | | | | This solves some edge cases when using files with very weird metadata (e.g. MaxCLL 10k and so forth). Instead of just blindly seeding it with the tagged metadata, forcibly set the initial state from the detected values.
| * vo_gpu: use dB units for scene change detectionNiklas Haas2019-02-183-11/+12
| | | | | | | | | | | | | | Rather than the linear cd/m^2 units, these (relative) logarithmic units lend themselves much better to actually detecting scene changes, especially since the scene averaging was changed to also work logarithmically.
| * vo_gpu: clamp sigmoid functionNiklas Haas2019-02-181-0/+2
| | | | | | | | Can explode on some clips otherwise
| * vo_gpu: tone map before gamut mappingNiklas Haas2019-02-181-5/+4
| | | | | | | | | | | | Gamut mapping can take very bright out-of-gamut colors into the negatives, which completely destroys the color balance (which tone mapping tries its best to preserve).
| * vo_gpu: make --gamut-warning warn on negative colorsNiklas Haas2019-02-181-1/+2
| | | | | | | | | | As is the case for actually out-of-gamut colors (rather than just too bright colors).
| * vo_gpu: improve numerical accuracy of PQ OETF constantNiklas Haas2019-02-181-1/+1
| | | | | | | | | | Not a huge deal, but we can do the division in C, which makes the float constant larger.
| * vo_gpu: allow color management in dumb modeNiklas Haas2019-02-181-5/+6
| | | | | | | | | | There's no point to disallow target-trc/prim in dumb mode, since they still work fine.
| * vo_gpu: improve accuracy of HDR brightness estimationNiklas Haas2019-02-182-10/+14
| | | | | | | | | | | | | | This change switches to a logarithmic mean to estimate the average signal brightness. This handles dark scenes with isolated highlights much more faithfully than the linear mean did, since the log of the signal roughly corresponds to the perceptual brightness.
| * vo_gpu: allow boosting dark scenes when tone mappingNiklas Haas2019-02-183-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | In theory our "eye adaptation" algorithm works in both ways, both darkening bright scenes and brightening dark scenes. But I've always just prevented the latter with a hard clamp, since I wanted to avoid blowing up dark scenes into looking funny (and full of noise). But allowing a tiny bit of over-exposure might be a good thing. I won't change the default just yet (better let users test), but a moderate value of 1.2 might be better than the current 1.0 limit. Needs testing especially on dark scenes.
| * vo_gpu: redesign peak detection algorithmNiklas Haas2019-02-183-77/+61
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous approach of using an FIR with tunable hard threshold for scene changes had several problems: - the FIR involved annoying hard-coded buffer sizes, high VRAM usage, and the FIR sum was prone to numerical overflow which limited the number of frames we could average over. We also totally redesign the scene change detection. - the hard scene change detection was prone to both false positives and false negatives, each with their own (annoying) issues. Scrap this entirely and switch to a dual approach of using a simple single-pole IIR low pass filter to smooth out noise, while using a softer scene change curve (with tunable low and high thresholds), based on `smoothstep`. The IIR filter is extremely simple in its implementation and has an arbitrarily user-tunable cutoff frequency, while the smoothstep-based scene change curve provides a good, tunable tradeoff between adaptation speed and stability - without exhibiting either of the traditional issues associated with the hard cutoff. Another way to think about the new options is that the "low threshold" provides a margin of error within which we don't care about small fluctuations in the scene (which will therefore be smoothed out by the IIR filter).
| * vo_gpu: improve tone mapping desaturationNiklas Haas2019-02-184-76/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | Instead of desaturating towards luma, we desaturate towards the per-channel tone mapped version. This essentially proves a smooth roll-off towards the "hollywood"-style (non-chromatic) tone mapping algorithm, which works better for bright content, while continuing to use the "linear" style (chromatic) tone mapping algorithm for primarily in-gamut content. We also split up the desaturation algorithm into strength and exponent, which allows users to use less aggressive desaturation settings without affecting the overall curve.
| * wayland_common: rename “shell” into “wm_base”Emmanuel Gil Peyrot2019-02-172-11/+11
| | | | | | | | | | | | | | | | This is the naming xdg-shell stable adopted, it doesn’t make much sense to keep using “shell” everywhere with all functions calling it “wm_base”. Finishes what 76211609e3c589dafe3ef9a36cacc06e8f56de09 started.
| * cocoa-cb: remove empty elements from dropped URLsAkemi2019-02-101-1/+2
| | | | | | | | Fixes #6241
| * cocoa-cb: add support for VOCTRL_GET_DISPLAY_NAMESAkemi2019-02-101-0/+14
| |
| * cocoa-cb: use Swift Extensions for convenienceAkemi2019-02-101-7/+4
| | | | | | | | preparations for the following commit.
| * cocoa-cb: fix side by side Split View againAkemi2019-01-231-3/+2
| | | | | | | | | | | | | | | | | | | | some safety mechanism for the async fs animation aren't needed anymore, due to possible improved logic and slightly different behaviour on new macOS versions. that safety fallback prevented the Split View because it always returned a rectangle of the whole screen, instead of just part/half of it. Fixes #6443
| * vo_gpu: allow resetting target-peak to the trc defaultKotori Itsuka2019-01-231-1/+2
| | | | | | | | | | | | | | | | | | Add "auto" the possible values of target-peak. The default value for target_peak is to calculate the target using mp_trc_nom_peak. Unfortunately, this default was outside the acceptable range of 10-10000 nits, which prevented its later reassignment. So add an "auto" choice to target-peak which lets clients and scripts go back to using the trc default after assigning a value.
* |