summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* wayland: add presentation timedudemanguy2019-10-205-7/+291
| | | | | Use ust/msc/refresh values from wayland's presentation time in mpv's ra_swapchain_fns.get_vsync for the wayland contexts.
* sws_utils: make libswscale fallback a warningwm42019-10-201-1/+1
| | | | | Surely a user passing --sws-allow-zimg wants to know if zimg is actually used.
* zimg: support 3 component 16 bit pixel unpackingwm42019-10-201-0/+22
| | | | | | Works for RGB (e.g. rgb48le) and XYZ. It's unsure whether XYZ is really correctly converted.
* zimg: avoid theoretical FFmpeg planar RGB/YUV mixupwm42019-10-201-5/+17
| | | | | | | | | | | | | The RGB pack/unpack code in theory supports packed, non-subsampled YUV, although in practice FFmpeg defines no such formats. (Only one with alpha, but all alpha input is rejected by the current code.) This would in theory have failed, because we would have selected a GBRP format (instead of YUV), which makes no sense and would either have been rejected by zimg (inconsistent parameters), or lead to broken output (wrong permutation of planes). Select the correct format and don't permute the planes in the YUV case.
* zimg: add some more colorspace mappingswm42019-10-201-5/+5
| | | | | | | As suggested by the zimg author. This is mostly related to XYZ support. It's unclear whether this works. Using the only XYZ test sample we know, and the next commits to consume the pixfmt, it looks wrong.
* vf_fingerprint: remove single-plane optimizationwm42019-10-201-31/+1
| | | | | | | | | | | | | | According to the zimg author, YUV->GREY conversion does not even read the chroma planes, as long as no matrix conversion is involved. Since we try to avoid the latter anyway by forcing the source parameters on the target image, passing only the Y plane will not help with anything. An unscientific test seems to confirm this, so remove this. This would probably help with libswscale (I didn't test this), but on the other hand, libswscale will rarely be used in cases where we can extract the Y plane. (Except nv12, which should probably be added to the zimg wrapper's unpacking.)
* vf_fingerprint: use generic zimg wrapperwm42019-10-201-79/+29
| | | | | Don't duplicate the API usage. The result should be approximately the same.
* mp_image: infer XYZ as BT.2020 instead of BT.709Niklas Haas2019-10-201-9/+8
| | | | | | | | | And update the comment both explaining why this defaulting matters and why we use BT.2020 instead. tl;dr BT.709 clips even the one test file we *do* have, so if we don't handle XYZ "natively" in vo_gpu we might as well at least handle it in a way that runs less risk of clipping
* csputils: fix outdated commentNiklas Haas2019-10-201-2/+4
| | | | | | This no longer hard-codes BT.709, it converts to whatever primaries are tagged in the same metadata struct. The actual BT.709 defaulting comes from `mp_image_params_guess_csp`.
* vo_x11: enable use of zimgwm42019-10-201-0/+2
| | | | | | | | This will perform conversion and scaling of video with zimg, if --sws-allow-zimg is used. The performance probably depends on how well the compiler optimizes the RGB pack code in zimg.c, which is written in C.
* sws_utils: hack in zimg redirection supportwm42019-10-202-3/+49
| | | | | | | | | | | | | | | | Awful shit. I probably wouldn't accept this code from someone else, just so you know. The idea is that a sws_utils user can automatically use zimg without large code changes. Basically, laziness. Since zimg support is still very new, and I don't want that anything breaks just because zimg was enabled at build time, an option needs to be set to enable it. (I have especially especially obscure stuff in mind, which is all what libswscale is used in mpv.) This _still_ doesn't cause zimg to be used anywhere, because the sws_utils user has to opt-in by setting allow_zimg. This is because some users depend on certain libswscale features.
* video: add zimg wrapperwm42019-10-202-0/+671
| | | | | | | | | | | | | | | | This provides a very similar API to sws_utils.h, which can be used to convert and scale from one mp_image to another. This commit adds only the code, but does not use it anywhere. The code is quite preliminary and barely tested. It supports only a few pixel formats, and will return failure for many others. (Unlike libswscale, which tries to support anything that FFmpeg knows.) zimg itself accepts only planar formats. Supporting other formats requires manual packing/unpacking. (Compared to libswscale, the zimg API is generally lower level, but allows for more flexibility.) Only BGR0 output was actually tested. It appears to work.
* mp_image: remove old acrobatics in frame copy codewm42019-10-201-21/+7
| | | | | | This used to be needed for the "GPU memcpy" (shitty Intel methods to deal with certain uncached memory types). This is now done in FFmpeg, and the code in mp_image.c was just unnecessarily convoluted.
* img_format: update test programwm42019-10-201-8/+16
| | | | | | | | | | | | The plane pointer checking assert() triggered at least on gray8, because that has a "pseudo palettes" in ffmpeg, which mpv refuses to allocate. Remove a strange duplicated printf(). Log the component type where available. (Why is this even here, I hate it when there are commented test programs in source files.)
* img_format: document a minor guarantee for certain imgfmt metadatawm42019-10-201-0/+1
|
* vaapi: remove hacks for pre-libva2 log callbackswm42019-10-181-65/+0
| | | | | Instead, you ancient libva will do default logging, which means printing to stderr. Not a loss, just update your libva.
* video, demux: rip out unused spherical metadata codewm42019-10-173-57/+1
| | | | | | This was preparation into something that never happened. Spherical video is a shit idea anyway.
* vo_gpu: hwdec_d3d11egl: add missing P010 format to supported listwm42019-10-171-1/+1
| | | | | | | | This was obviously missing from the recent commit, which probably broke 10 bit decoding. The original commit didn't test this for lack of working hardware; this commit isn't tested either. Fixes: a1c7d613935424b69b3
* video: remove mp_image_params.hw_flags fieldwm42019-10-175-30/+0
| | | | | | | | This was speculatively added 2 years ago in preparation for something that apparently never happened. The D3D code was added as an "example", but this too was never used/finished. No reason to keep this.
* vo_wlshm: use memfd_create() instead of shm_open()Emmanuel Gil Peyrot2019-10-172-24/+12
| | | | | | | | | | | This syscall avoids the need to guess an unused filename in /dev/shm and allows seals to be placed on it. We immediately return if no fd got returned, as there isn’t anything we can do otherwise. Seals especially allow the compositor to drop the SIGBUS protections, since the kernel promises the fd won’t ever shrink. This removes support for any platform but Linux from this vo.
* Reintroduce vo_wayland as vo_wlshmMichael Forney2019-10-172-0/+316
| | | | | | | | vo_wayland was removed during the wayland rewrite done in 0.28. However, it is still useful for systems that do not have OpenGL. The new wayland_common code makes vo_wayland much simpler, and eliminates many of the issues the previous vo_wayland had.
* vf_d3d11vpp: remove RGB conversion hackwm42019-10-161-49/+5
| | | | | | | With the previous commit, this is dead code. This also makes the f_autoconvert.c code for this dead code (fortunately). Will probably remove this later.
* vo_gpu: hwdec_d3d11eglrgb: remove thiswm42019-10-162-281/+0
| | | | | Finally. Since with the previous commit we can (probably) handle P010 directly, this hack isn't needed anymore.
* vo_gpu: hwdec_d3d11egl: adapt to newer ANGLE APIwm42019-10-161-24/+33
| | | | | | | | | | | | | | | | | | | 2 years ago, ANGLE removed the old NV12-specific extension, and added a new one that supports a number of formats, including P010. Actually they just renamed it and removed their initial annoying and obvious design error (bravo, Google). Since it broke 2 years ago, nobody should give a shit about this code, and it should just be removed. But for some reason I still dived the shit-tank (Windows development). I guess Intel code monkeys can't write drivers (or maybe the issue is because we're doing zero-copy, which probably maybe is not actually allowed by D3D11 due to array textures, see --d3d11va-zero-copy), so the P010 path is completely untested. It doesn't work, I'll delete all this ANGLE hwdec code. Fixes: #7054
* vo_gpu/d3d11: fix memleak of the adapter description stringJan Ekström2019-10-151-1/+5
|
* vo_gpu/d3d11: remove unnecessary nullptr checkJan Ekström2019-10-151-2/+2
| | | | mp_to_utf8 will abort in case of either invalid input or OOM.
* vo_gpu/d3d11: switch adapter selection to case-insensitive startswithJan Ekström2019-10-152-4/+5
| | | | | | This lets users set values such as "intel" or "nvidia" as the adapter vendor is generally noted in the beginning of the description string.
* vo_gpu/d3d11: fixup adapter selection by switching it all to bstrJan Ekström2019-10-153-12/+8
| | | | | I did ponder if I should have done this right away, and it seems like not doing it at first was a mistake.
* vo_gpu/d3d11: add support for configuring swap chain formatJan Ekström2019-10-133-1/+129
| | | | | | | Query information on the system output most linked to the swap chain, and either utilize a user-configured format, or either 8bit RGBA or 10bit RGB with 2bit alpha depending on the system output's bit depth.
* vo_gpu/d3d11: utilize actual backbuffer values for bit depthJames Ross-Gowan2019-10-131-1/+6
| | | | | And if backbuffer is not around, return an error value utilized elsewhere already.
* wayland: use callback flag + poll for buffer swapdudemanguy2019-10-109-26/+112
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The old way of using wayland in mpv relied on an external renderloop for semi-accurate timings. This had multiple issues though. Display sync would break whenever the window was hidden (since the frame callback stopped being executed) which was really annoying. Also the entire external renderloop logic was kind of fragile and didn't play well with mpv's internal structure (i.e. using presentation time in that old paradigm breaks stats.lua). Basically the problem is that swap buffers blocks on wayland which is crap whenever you hide the mpv window since it looks up the entire player. So you have to make swap buffers not block, but this has a different problem. Timings will be terrible if you use the unblocked swap buffers call. Based on some discussion in #wayland, the trick here is relatively simple and works well enough for our purposes. Instead we basically build a way to block with a timeout in the wayland buffer swap functions. A bool is set in the frame callback function that indicates whether or not mpv is waiting for a frame to be displayed. In the actual buffer swap function, we enter into a while loop waiting for this flag to be set. At the same time, the wl_display is polled to block the thread and wakeup if it receives any events from the compositor. This loop only breaks if enough time has passed or if the frame callback bool is received. In the near future, it is better to set whether or not frame a frame has been displayed in the presentation feedback. However as a first pass, doing it in the frame callback is more than good enough. The "downside" is that we render frames that aren't actually shown on screen when the player is hidden (it seems like wayland people don't like that). But who cares. Accurate timings are way more important. It's probably not too hard to add that behavior back in the player though.
* Revert "vo: add support for externally driven renderloop and make wayland ↵dudemanguy2019-10-104-70/+4
| | | | | | | | | | use it" The externally driven renderloop was originally added for the wayland context (to make display sync somewhat work), but it has a lot of issues with mpv's internal structure. A different approach should be used. This reverts commit a743fef837bcab206b1e576db7e7a64b02890449.
* vo_gpu: d3d11: use linear filtering for wrapped texturesJames Ross-Gowan2019-10-101-1/+3
| | | | | | | | | | This affects hwdec_dxva2dxgi, which uses ra_d3d11_wrap_tex to wrap RGB video frames that are shared with a D3D9 device. Without it, mpv uses nearest instead of bilinear scaling with --scale=bilinear (the default) and --hwdec=dxva2. It's kind of hard to believe this bug has gone unnoticed for almost two years, but that seems to have been the case. Fixes: #7042
* cocoa-cb: remove get_property_* usages and split up mpv helperder richter2019-10-065-133/+123
| | | | | | | | | | all the get_property_* usages were removed because in some circumstances they can lead to deadlocks. they were replaced by accessing the vo and mp_vo_opts structs directly, like on other vos. additionally the mpv helper was split into a mpv and libmpv helper, to differentiate between private and public APIs and for future changes like a macOS vulkan context for vo=gpu.
* wayland opengl: actually call uninit if init failsdudemanguy2019-10-031-1/+3
| | | | | | | | This is the proper fix to the memory leak @wm4 pointed out. It turns out that when you autoprobe opengl and vo_wayland_init returns false, vo_wayland_uninit is never actually executed. So you have a leftover pointer. The vulkan context does this correctly which was why my old, dumb "fix" broke it.
* Revert "wayland: free wayland_state on a false return"dudemanguy2019-10-031-11/+3
| | | | | | | | Dumb idea. The correct thing to do is to fix the preinit and context creation so that the uninit is correctly executed when probing fails (and then everything gets freed). This reverts commit defc8f359c5e4bb666e8ad1d4a097a8ac66cc1e2.
* wayland: free wayland_state on a false returnDudemanguy9112019-10-021-3/+11
| | | | | | wm4 mentioned that the wayland autoprobe leaked. A simple oversight in the wayland_common code forgot to free the vo_wayland_state if vo_wayland_init returned false.
* vf_fingerprint: fix an obvious memory leakwm42019-10-031-4/+12
| | | | | | Leaks the entire zimg state on filter deinit. Not sure what I was thinking; with some luck, I just didn't give a shit about this case, but most likely I was thinking the same thing as always: nothing.
* vf_vapoursynth: fix crashing memory management mistakewm42019-10-031-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As pointed out by @olifre in #7016, this line of code was wrong. p->opts at this point is a struct allocated and managed by m_config. opts->file is a string, and m_config explicitly frees it on destruction. The line of code in question replaced the opts->file value, and made both the old and new value children of the talloc allocation, so they were _also_ freed on destruction. This crashed due to a double-free. First, talloc auto-freeing freed the string, then m_config explicitly called talloc_free() on the stale pointer again. As @v-fox pointed out, commit 36dd2348a1e1 seems to have triggered the crash. I suspect this code merely worked out of coincidence, since it allowed m_config to free the value first. This removed it from the auto-free list, and thus did not result in a double-free. The change in order of calling alloc destructors changed the order of these calls. There is no strong reason why new behavior (as introduced by commit 36dd2348a1e1) would be wrong (it feels like cleaner behavior). On the other hand, what the vf_vapoursynth code did is clearly unclean and going by the m_config API, you're not at all supposed to do this. m_config manages all memroy referenced by option structs, the end. @olifre's suggested fix also would have been correct (not just hiding the issue), I prefer my fix, as it doesn't mess with the option struct in tricky ways. This wouldn't have happened if mpv were written in Haskell.
* vf_vapoursynth: do not call vsscript_finalize() if init failedwm42019-10-031-1/+5
| | | | | If vsscript_finalize() is not matched by a successful vsscript_init(), an assert in the vsscript library triggers. Makes sense, I guess.
* vf_vapoursynth: remove some Lua backend remainswm42019-10-031-6/+0
| | | | Pretty funny.
* wayland: always create wl_output before renderingDudemanguy9112019-10-021-7/+6
| | | | | | | | | | | I previously skipped creating the wl_output if the --fullscreen flag with no --fsscreen_id was inputted, so the fullscreen video lands on the correct output (where mpv was launched). This has breakage if someone combines the --autofit flag (or other similar options with it). Instead, just actually read xdg_shell spec and realize that you can pass NULL to xdg_toplevel_set_fullscreen and let the compositor choose the output if the user doesn't specify it. If this has issues, get a better compositor.
* mp_image_pool: expose a function for reporting hw download formatwm42019-10-022-11/+22
| | | | | | | | Basically predicts what mp_image_hw_download() will do. It's pretty simple if it gets the full mp_image. (Taking just a imgfmt would make this pretty hard/impossible or inaccurate.) Used in one of the following commits.
* video: remove vf_vavpp from automatic deinterlace propertywm42019-10-021-9/+0
| | | | | | | | | | | | | | This reverts commit 6385a5fd1b8a67c051b82d48c993a6591e8f93c6, and in addition removes the code that automatically inserts the vavpp filter. The reason is the same as the commit that is being reverted: this filter seems to trigger driver bugs. It can cause GPU freezes or just doesn't work. This variant of disabling the filter is better. There was no way to add the "force" parameter to the automatically inserted filter, so the old approach just made manual filter insertion (with the --vf option or "vf" command) more cumbersome.
* vo_gpu/d3d11: add adapter name validation and listing with "help"Jan Ekström2019-09-293-6/+73
| | | | Not the prettiest way to get it done, but seems to work.
* vo_gpu/d3d11: refactor pthread_once d3d11 loading to functionJan Ekström2019-09-291-6/+15
| | | | Lets us reuse this in the future.
* vo_gpu/d3d11: utilize the passed adapter nameJan Ekström2019-09-291-5/+77
| | | | | | Normalize nullptr and an empty string both to nullptr to simplify handling. API users cannot set a value back to nullptr, so both an empty string as well as nullptr should behave the same.
* vo_gpu/d3d11: add an option for the adapter nameJan Ekström2019-09-292-0/+6
| | | | Set it from the adapter name in the d3d11 options.
* video/d3d11: add adapter selection by name into d3d11 optionsJan Ekström2019-09-291-0/+3
| | | | | This lets the user define an adapter name that can then be passed further into the internals.
* vo_gpu/d3d11_helpers: also load up CreateDXGIFactory1Jan Ekström2019-09-291-4/+13
| | | | Just a factory, without a device, is required for listing of devices.
* vo_drm: fix flickering when setting pan/scanAnton Kindestam2019-09-291-4/+0
| | | | | | | | Turns out clearing all frambuffers in reconfig isn't such a great idea when you also end up here when setting pan/scan. I guess this is just a leftover from a previous iteration of vo_drm where doing this made sense.
* vo_gpu: hwdec_cuda: Synchronise OpenGL InteropPhilip Langdale2019-09-283-0/+8
| | | | | | | | | | | | | | | | | | | | | Previously, there appeared to be implicit synchronisation in the GL interop path, and we never observed any visual glitches. However, recently, I started seeing stuttering in the GL path and on closer examination it looked like read-before-write behaviour where GL would display an old frame again rather than the current one. After verifying that disabling hwdec made the problem go away, I tried adding a cuStreamSynchronize() after the memcpys and that also resolved the problem, so it's clearly sync related. cuStreamSynchronize() is a CPU sync and so more heavy-weight than you want, but it's the only tool we have. There is no mechanism defined for synchronising GL to CUDA (It looks like there is a way to synchronise CUDA to EGL but it appears one way and so wouldn't directly address this problem). Anyway, empirically, the output now looks the same as with hwdec off.
* vo_drm: support controlling swapchain depth using swapchain-depth optionAnton Kindestam2019-09-281-10/+13
|
* vo: make swapchain-depth option generic for all VOsAnton Kindestam2019-09-288-16/+10
| | | | In preparation for making vo_drm able to use swapchain-depth
* drm: refactor page_flipped callbackAnton Kindestam2019-09-284-109/+71
| | | | | Avoid duplicating the same callback function in both context_drm_egl and vo_drm.
* vo_drm: Implement N-buffering and presentation feedbackAnton Kindestam2019-09-281-39/+215
| | | | | | | | | | | Swapchain depth currently hard-coded to 3 (4 buffers). As we now avoid redrawing on repeat frames (we simply requeue the same fb again), this should give a nice performance boost when playing videos with a lower FPS than the display FPS in video-sync=display-resample mode. Presentation feedback has also been implemented to help counter the significant amounts of jitter we would otherwise be seeing.
* vo_drm: fix more than 2 buffersAnton Kindestam2019-09-281-1/+1
| | | | Now we can increase BUF_COUNT. Yay.
* drm: move struct vsync_tuple into drm_common as drm_vsync_tupleAnton Kindestam2019-09-282-9/+8
| | | | This struct will be useful in vo_drm as well.
* context_drm_egl: define EGL_PLATFORM_GBM_MESA, EGL_PLATFORM_GBM_KHR if not ↵Anton Kindestam2019-09-271-0/+8
| | | | | |<