aboutsummaryrefslogtreecommitdiffhomepage
path: root/video
Commit message (Collapse)AuthorAge
* video: make IMGFMT_IS_HWACCEL() return 0 or 1Gravatar wm42018-01-18
| | | | Sometimes helps avoiding usage mistakes.
* video: add utility function to pick conversion image format from a listGravatar wm42018-01-18
|
* video: avoid some unnecessary vf.h includesGravatar wm42018-01-18
|
* vo_gpu: skip DR for unsupported image formatsGravatar wm42018-01-18
| | | | | | | | | | | | | | DR (direct rendering) works by having the decoder decode into the GPU staging buffers, instead of copying the video data on texture upload. We did this even for formats unsupported by the GPU or the renderer. This "worked" because the staging memory is untyped, and the video frame was converted by libswscale to a supported format, and then uploaded with a copy using the normal non-DR texture upload path. Even though it "works", we don't gain anything from using the staging buffers for decoding, since we can't use them for upload anyway. Also, staging memory might be potentially limited (what really happens is up to the driver). It's easy to avoid, so just skip it in these cases.
* vo_gpu: fix broken 10 bit via integer textures playbackGravatar wm42018-01-17
| | | | | | | | | | | The check_gl_features(p) call here checks whether dumb mode can be used. It uses the field use_integer_conversion, which is set _after_ the call in the same function. Move check_gl_features() to the end of the function, when use_integer_conversion is finally set. Fixes that it tried to use bilinear filtering with integer textures. The bug disabled the code that is supposed to convert it to non-integer textures.
* vo_gpu: rpi: defer gl_ctx_resize until after gl_ctx_initGravatar Niklas Haas2018-01-15
| | | | | | | | This segfaults otherwise. The conditional is needed to break a circular dependency (gl_init depends on mpgl_load_functions which depends on recreate_dispmanx which calls gl_ctx_resize). Fixes #5398
* video: change some mp_image_pool semanticsGravatar wm42018-01-13
| | | | | | | | | | Remove the max_count creation parameter, because it's pointless and rarely ever did anything. Add a talloc parent parameter instead (which is something completely different, but convenient, and all callers needs to be changed anyway). Instead of clearing the pool when the now removed maximum is reached, clear it on image parameter changes instead.
* video, audio: don't actively wait for demuxer inputGravatar wm42018-01-09
| | | | | | | | | | | | If feed_packet() ended with DATA_WAIT, the player should have gone to sleep, until the demuxer wakes it up again when there is new data. But the call to read_frame() unconditionally overwrote this status code, so it never waited. The consequence was that the core burned CPU by effectively polling the demuxer status, which was noticeable especially when seeking in network streams (since seeking is async, decoders will start out with having to wait for network). Regression since commit 33e5755c.
* vo_gpu: hwdec_dxva2dxgi: initial implementationGravatar James Ross-Gowan2018-01-06
| | | | | | | | | | | | | This enables DXVA2 hardware decoding with ra_d3d11. It should be useful for Windows 7, where D3D11VA is not available. Images are transfered from D3D9 to D3D11 using D3D9Ex surface sharing[1]. Following Microsoft's recommendations, it uses a queue of shared surfaces, similar to Microsoft's ISurfaceQueue. This will hopefully prevent surface sharing from impacting parallelism and allow multiple D3D11 frames to be in-flight at once. [1]: https://msdn.microsoft.com/en-us/library/windows/desktop/ee913554.aspx
* vo_gpu: d3d11: check for NULL backbuffer in start_frameGravatar James Ross-Gowan2018-01-04
| | | | | | | | | | | | | In a lost device scenario, resize() will fail and p->backbuffer will be NULL. We can't recover from lost devices yet, but we should still check for a NULL backbuffer in start_frame() rather than crashing. Also remove a NULL check for p->swapchain. This was a red herring, since p->swapchain never becomes NULL in an error condition, but p->backbuffer actually does. This should fix the crash in #5320, but it doesn't fix the underlying reason for the lost device (which is probably a driver bug.)
* vo_gpu: d3d11: don't use a bgra8 swapchainGravatar James Ross-Gowan2018-01-04
| | | | | | | | | | Previously, mpv would attempt to use a BGRA swapchain in the hope that it would give better performance, since the Windows desktop is also composited in BGRA. In practice, it seems like there is no noticable performance difference between RGBA and BGRA swapchains and BGRA swapchains cause trouble with a42b8b1142fd, which attempts to use the swapchain format for intermediate FBOs, even though D3D11 does not guarantee BGRA surfaces will work with UAV typed stores.
* vo_gpu/context_android: replace both options with android-surface-sizeGravatar sfan52018-01-02
| | | | This allows us to automatically trigger a VOCTRL_RESIZE (also contained).
* video, audio: always read all frames before getting next packetGravatar wm42018-01-01
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old code tried to make sure at all times to try to read a new packet. Only once that was read, it tried to retrieve new video or audio frames the decoder might already have decoded. Change this to strictly read frames from the decoder until it signals that it wants a new packet, and only then read and feed a new packet. This is in theory nicer, follows the libavcodec recommended data flow, and and reduces the minimum latency by 1 frame. This merely requires switching the order in which those calls are done. Normally, the decoder will return only 1 frame until a new packet is required. If we would just feed it 1 packet, return DATA_AGAIN, and wait until the next frame is decoded, we would run the playloop 1 time too often for no reason (which is fine but might have some overhead). To avoid this, try to read a frame again after possibly feeding a packet. For this reason, move the feed/read code to its own functions each, instead of merely moving the code. The audio and video code for this particular thing is basically duplicated. The idea is to unify them one day, so make the change to both. (Doing this for video is the real motivation for this change, see below.) The video code change is slightly more complicated, because we have to care about the framedrop counting (which is just a heuristic, but for now considered better than nothing, and possibly considered required to warn the user of framedrops happening - maybe). Apparently this change helps with stalling streams on Android with the mediacodec wrapper and mpeg2 decoder implementations which deinterlace on decoding (and return 2 frames per packet). Based on an idea and observations by tmm1.
* vo_gpu/android: fallback to EGL_WIDTH/HEIGHTGravatar Aman Gupta2018-01-01
| | | | | | | | | | Uses the EGL width/height by default when the user fails to set the android-surface-width/android-surface-height options. This means the vo-resize command is optional, and does not need to be implemented on android devices which do not support rotation. Signed-off-by: Aman Gupta <aman@tmm1.net>
* vo_gpu: d3d11: avoid copying staging buffers to cbuffersGravatar James Ross-Gowan2018-01-01
| | | | | | | | | | | | | | | | Apparently some Intel drivers have a bug where copying from staging buffers to constant buffers does not work. We used to keep a copy of the buffer data in a staging buffer to enable partial constant buffer updates. To work around this bug, keep the copy in talloc-allocated system memory instead. There doesn't seem to be any noticable performance difference from keeping the copy in system memory. Our cbuffers are probably too small for it to matter anyway. See also: https://crbug.com/593024 Fixes #5293
* demux_mkv: add hack to pass along x264 version to decoderGravatar wm42017-12-28
| | | | | | | | | | | | | | | | | | | | | | | | | | This fixes when resuming certain broken h264 files encoded by x264. See FFmpeg commit 840b41b2a643fc8f0617c0370125a19c02c6b586 about the x264 bug itself. Normally, the unregistered user data SEI (that contains the x264 version string) is informational only. But libavcodec uses it to workaround a x264 bug, which was recently fixed in both libavcodec and x264. The fact that both encoder and decoder were buggy is the reason that it was not found earlier, and there are apparently a lot of files around created by the broken decoder. If libavcodec sees the SEI, this bug can be worked around by using the old behavior. If you resume a file with mpv (i.e. seeking when the file loads), libavcodec never sees the first video packet. Consequently it has to assume the file is not broken, and never applies the workaround, resulting in garbage being played. Fix this by always feeding the first video packet to the decoder on init, and then flushing the codec (to avoid that an unwanted image is output). Flushing the codec does not remove info such as the x264 version. We also abuse the fact that the first avcodec_send_packet() always pushes the frame into the decoder (so we don't have to trigger the decoder by requsting an output frame).
* vd_lavc: add an option to explicitly workaround x264 4:4:4 bugGravatar wm42017-12-28
| | | | | | Technically, the user could just use --vd-lavc-o with the same result. But I find it better to make this an explicit option, so we can document the ups and downs, and also avoid setting it for non-h264.
* vd_lavc: fix crash with RPI hwdecGravatar wm42017-12-28
| | | | | | If you use vo_rpi, this could crash, because hwdec_devs is NULL. Untested. Fixes #5301.
* player: add internal `vo-resize` commandGravatar sfan52017-12-27
| | | | Intended to be used with the properties from previous commit.
* vo_gpu/context: Let embedding application handle surface resizesGravatar sfan52017-12-27
| | | | | The callbacks for this are Java-only and EGL does not reliably return the correct values.
* vo_gpu: EGL: provide SwapInterval to generic codeGravatar wm42017-12-27
| | | | | | | This means that we now explicitly set an interval of 1. Although that should be the EGL default, some drivers could possibly ignore this (unconfirmed). In any case, this commit also allows disabling vsync, for users who want it.
* vf_vdpaupp: fix error handling and software input modeGravatar wm42017-12-27
| | | | | | | | Crashed when no vdpau device was loaded. Also there was a mistake of not setting p->ctx, which broke software surface input mode. This was not found before, because p->ctx is not needed for anything else. Fixes #5294.
* options: drop some previously deprecated optionsGravatar wm42017-12-25
| | | | | | | | A release has been made, so drop options deprecated for that release. Also drop some options which have been deprecated a much longer time before. Also fix a typo in client-api-changes.rst.
* vo_gpu: vulkan: fix segfault due to index mismatchGravatar Niklas Haas2017-12-25
| | | | | | | | The queue family index and the queue info index are not necessarily the same, so we're forced to do a check based on the queue family index itself. Fixes #5049
* vo_gpu: vulkan: fix some image barrier odditiesGravatar Niklas Haas2017-12-25
| | | | | | | | | | | A vulkan validation layer update pointed out that this was wrong; we still need to use the access type corresponding to the stage mask, even if it means our code won't be able to skip the pipeline barrier (which would be wrong anyway). In additiona to this, we're also not allowed to specify any source access mask when transitioning from top_of_pipe, which doesn't make any sense anyway.
* vo_gpu: vulkan: omit needless #defineGravatar Niklas Haas2017-12-25
|
* vo_gpu: vulkan: fix sharing mode on malloc'd buffersGravatar Niklas Haas2017-12-25
| | | | Might explain some of the issues in multi-queue scenarios?
* vo_gpu: vulkan: fix dummyPass creationGravatar Niklas Haas2017-12-25
| | | | This violates vulkan spec
* vo_gpu: vulkan: fix the rgb565a1 names -> rgb5a1Gravatar Niklas Haas2017-12-25
| | | | This is 5 bits per channel, not 565
* vo_gpu: vulkan: allow disabling async tf/compGravatar Niklas Haas2017-12-25
| | | | | | | | | Async compute in particular seems to cause problems on some drivers, and even when supprted the benefits are not that massive from the tests I have seen, so it's probably safe to keep off by default. Async transfer on the other hand seems to work better and offers a more substantial improvement, so it's kept on.
* vo_gpu: vulkan: refine queue family selection algorithmGravatar Niklas Haas2017-12-25
| | | | | | This gets confused by e.g. SPARSE_BIT on the TRANSFER_BIT, leading to situations where "more specialized" is ambiguous and the logic breaks down. So to fix it, only compare the subset we care about.
* vo_gpu: vulkan: prefer vkCmdCopyImage over vkCmdBlitImageGravatar Niklas Haas2017-12-25
| | | | | | blit() implies scaling, copy() is the equivalent command to use when the formats are compatible (same pixel size) and the rects have the same dimensions.
* vo_gpu: attempt re-using the FBO format for p->output_texGravatar Niklas Haas2017-12-25
| | | | | | | | | This allows RAs with support for non-opaque FBO formats to use a more appropriate FBO format for the output tex, possibly enabling a more efficient blit operation. This requires distinguishing between real formats (which can be used to create textures) and fake formats (e.g. ra_gl's FBO hack).
* vo_gpu: vulkan: properly depend on the swapchain acquire semaphoreGravatar Niklas Haas2017-12-25
| | | | | This is now associated with the ra_tex directly and used in the correct way, rather than hackily done from submit_frame.
* vo_gpu: vulkan: use correct access flag for presentGravatar Niklas Haas2017-12-25
| | | | This needs VK_ACCESS_MEMORY_READ_BIT (spec)
* vo_gpu: vulkan: make the swapchain more robustGravatar Niklas Haas2017-12-25
| | | | | Now handles both VK_ERROR_OUT_OF_DATE_KHR and VK_SUBOPTIMAL_KHR for both vkAcquireNextImageKHR and vkQueuePresentKHR in the correct way.
* vo_gpu: aggressively prefer async computeGravatar Niklas Haas2017-12-25
| | | | | | | | | | On AMD devices, we only get one graphics pipe but several compute pipes which can (in theory) run independently. As such, we should prefer compute shaders over fragment shaders in scenarios where we expect them to be better for parallelism. This is amusingly trivial to do, and actually improves performance even in a single-queue scenario.
* vo_gpu: vulkan: support split command poolsGravatar Niklas Haas2017-12-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Instead of using a single primary queue, we generate multiple vk_cmdpools and pick the right one dynamically based on the intent. This has a number of immediate benefits: 1. We can use async texture uploads 2. We can use the DMA engine for buffer updates 3. We can benefit from async compute on AMD GPUs Unfortunately, the major downside is that due to the lack of QF ownership tracking, we need to use CONCURRENT sharing for all resources (buffers *and* images!). In theory, we could try figuring out a way to get rid of the concurrent sharing for buffers (which is only needed for compute shader UBOs), but even so, the concurrent sharing mode doesn't really seem to have a significant impact over here (nvidia). It's possible that other platforms may disagree. Our deadlock-avoidance strategy is stupidly simple: Just flush the command every time we need to switch queues, and make sure all submission and callbacks happen in FIFO order. This required lifting the cmds_pending and cmds_queued out from vk_cmdpool to mpvk_ctx, and some functions died/got moved as a result, but that's a relatively minor change. On my hardware this is a fairly significant performance boost, mainly due to async transfers. (Nvidia doesn't expose separate compute queues anyway). On AMD, this should be a performance boost as well due to async compute.
* vo_gpu: invalidate fbotex before drawingGravatar Niklas Haas2017-12-25
| | | | | Don't discard the OSD or pass_draw_to_screen passes though. Could be faster on some hardware.
* vo_gpu: allow invalidating FBO in renderpass_runGravatar Niklas Haas2017-12-25
| | | | | | | | | This is especially interesting for vulkan since it allows completely skipping the layout transition as part of the renderpass. Unfortunately, that also means it needs to be put into renderpass_params, as opposed to renderpass_run_params (unlike #4777). Closes #4777.
* vo_gpu: vulkan: properly track image dependenciesGravatar Niklas Haas2017-12-25
| | | | | | | | | | | | | | | | | | | | | | | | This uses the new vk_signal mechanism to order all access to textures. This has several advantageS: 1. It allows real synchronization of image access across multiple frames when using multiple queues for parallelism. 2. It allows using events instead of pipeline barriers, which is a finer-grained synchronization primitive that allows for more efficient layout transitions over longer durations. This commit also restructures some of the implicit transition code for renderpasses to be more flexible and correct. (Note: this technically drops the ability to transition the image out of undefined layout when not blending, but that was a bug anyway and needs to be done properly) vo_gpu: vulkan: remove no-longer-true optimization The change to the output_tex format makes this no longer true, and it actually seems to hurt performance now as well. So just don't do it anymore. I also realized it hurts performance when drawing an OSD, so it's probably not a good idea anyway.
* vo_gpu: vulkan: add a vk_signal abstractionGravatar Niklas Haas2017-12-25
| | | | | | | | | This combines VkSemaphores and VkEvents into a common umbrella abstraction which can resolve to either. We aggressively try to prefer VkEvents over VkSemaphores whenever the conditions are met (1. we can unsignal the semaphore, i.e. it comes from the same frame; and 2. it comes from the same queue).
* vo_gpu: vulkan: refactor command submissionGravatar Niklas Haas2017-12-25
| | | | | | | | | | | | | | | Instead of being submitted immediately, commands are appended into an internal submission queue, and the actual submission is done once per frame (at the same time as queue cycling). Again, the benefits are not immediately obvious because nothing benefits from this yet, but it will make more sense for an upcoming vk_signal mechanism. This also cleans up the way the ra_vk submission interacts with the synchronization/callbacks from the ra_vk_ctx. Although currently, the way the dependency is signalled is a bit hacky: normally it would be associated with the ra_tex itself and waited on in the appropriate stage implicitly. But that code is just temporary, so I'm keeping it in there for a better commit order.
* vo_gpu: vulkan: reorganize vk_cmd slightlyGravatar Niklas Haas2017-12-25
| | | | | | | | Instead of associating a single VkSemaphore with every command buffer and allowing the user to ad-hoc wait on it during submission, make the raw semaphores-to-signal array work like the raw semaphores-to-wait-on array. Doesn't really provide a clear benefit yet, but it's required for upcoming modifications.
* vo_gpu: vulkan: refactor vk_cmdpoolGravatar Niklas Haas2017-12-25
| | | | | | 1. No more static arrays (deps / callbacks / queues / cmds) 2. Allows safely recording multiple commands at the same time 3. Uses resources optimally by never over-allocating commands
* Restore Libav supportGravatar wm42017-12-21
| | | | | | | | | | | Libav has been broken due to the hwdec changes. This was always a temporary situation (depended on pending patches to be merged), although it took a bit longer. This also restores the travis config. One code change is needed in vd_lavc.c, because it checks the AV_PIX_FMT for videotoolbox (as opposed to the mpv format identifier), which is not available in Libav. Add an ifdef; the affected code is for a deprecated option anyway.
* hwdec: remove unused fieldsGravatar wm42017-12-21
| | | | | These were replaced by a different mechanism, but the old fields weren't removed.
* vo_mediacodec_embed: implement hwcontextGravatar Aman Gupta2017-12-20
| | | | Fixes vo_mediacodec_embed, which was broken in 80359c6615658f2784
* vo_gpu: win: remove exclusive-fullscreen detection hackGravatar James Ross-Gowan2017-12-20
| | | | | | | | | | | | | | | | | | | | | This hack was part of a solution to VSync judder in desktop OpenGL on Windows. Rather than using blocking-SwapBuffers(), mpv could use DwmFlush() to wait for the image to be presented by the compositor. Since this would only work while the compositor was running, and the compositor was silently disabled when OpenGL entered exclusive fullscreen mode, mpv needed a way to detect exclusive fullscreen mode. The code that is being removed could detect exclusive fullscreen mode by checking the state of an undocumented mutex using undocumented native API functions, but because of how fragile it was, it was always meant to be removed when a better solution for accurate VSync in OpenGL was found. Since then, mpv got the dxinterop backend, which uses desktop OpenGL but has accurate VSync. It also got a native Direct3D 11 backend, which is a viable alternative to OpenGL on Windows. For people who are still using desktop OpenGL with WGL, there shouldn't be much of a difference, since mpv can use other API functions to detect exclusive fullscreen.
* w32_common: refactor and improve window state handlingGravatar pavelxdd2017-12-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Refactored and split the `reinit_window_state` code into four separate functions: - `update_window_style` used to update window styles without modifying the window rect. - `fit_window_on_screen` used to adjust the window size when it is larger than the screen size. Added a helper function `fit_rect` to fit one rect on another without using any data from w32 struct. - `update_fullscreen_state` used to calculate the new fullscreen state and adjust the window rect accordingly. - `update_window_state` used to display the window on screen with new size, position and ontop state. This commit fixes three issues: - fixed #4753 by skipping `fit_window_on_screen` for a maximized window, since maximized window should already fit on the screen. It should be noted that this bug was only reproducible with `--fit-border` option which is enabled by default. The cause of the bug is that after calling the `add_window_borders` for a maximized window, the rect in result is slightly larger than the screen rect, which is okay, `SetWindowPos` will interpret it as a maximized state later, so no auto-fitting to screen size is needed here. - fixed #5215 by skipping `fit_window_on_screen` when leaving fullscreen. On a multi-monitor system if the mpv window was stretched to cover multiple monitors, its size was reset after switching back from fullscreen to fit the size of the active monitor. Also, when changing `--ontop` and `--border` options, now only the `update_window_style` and `update_window_state` functions are used, so `fit_window_on_screen` is not used for them too. - fixed #2451 by moving the `ITaskbarList2_MarkFullscreenWindow` below the `SetWindowPos`. If the taskbar is notified about fullscreen state before the window is shown on screen, the taskbar button could be missing until Alt-TAB is pressed, usually it was reproducible on Windows 8. Other changes: - In `update_fullscreen_state` the `reset window bounds` debug message now reports client area size and position, instead of window area size and position. This is done for consistency with debug messages in handling fullscreen state above in this function, since they also print window bounds of the client area. - Refactored `gui_thread_reconfig`. Added a new window flag `fit_on_screen` to fit the window on screen even when leaving fullscreen. This is needed for the case when the new video opened while the window is still in the fullscreen state. - Moved parent and fullscreen state checks out from the WM_MOVING to `snap_to_screen_edges` function for consistency with other functions. There's no point in keeping these checks out of the function body.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-05 09:50:09 +0000