summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: fix infinite scaler reinit spamNiklas Haas2019-11-231-8/+9
| | | | | | | | | Handling the window with this function makes no sense, since windows and kernels are not the same thing and don't share the same option list. The only reason it's done is to make sure the char* points at the static string rather than the dynamically allocated one, which we can do manually in this function. Rewrite a bit for clarity/quality.
* video/out/bitmap_packer: Avoid empty initializer listMichael Forney2019-11-181-1/+1
|
* video/out/vo_tct: Use octal escape sequence instead of non-standard \eMichael Forney2019-11-181-9/+9
|
* video/out/gpu: Remove stray top-level ';'Michael Forney2019-11-182-2/+2
|
* vo_gpu: hwdec_cuda: Reduce message level of errors while probingPhilip Langdale2019-11-172-5/+7
| | | | | | We should only be printing errors that occur when not probing, to avoid creating the impression that something is wrong - and errors during probing isn't a problem.
* vo_gpu: context_glx: Add X11 native resourcePhilip Langdale2019-11-161-0/+2
| | | | | | | Surprisingly, we've managed to get this far without context_glx ever adding the X11 display as a native resource. But with the recent change to attempt to enable vdpau when using EGL, the hwdec now requires the display to be added. So let's add it.
* wayland: use eglGetPlatformDisplay()Dudemanguy2019-11-161-1/+2
| | | | | See aacc194. The same logic all applies to Wayland. In fact, we already require EGL 1.5 for wayland anyway, so it's better to do it right.
* x11: require EGL 1.5 and use eglGetPlatformDisplay()wm42019-11-161-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | eglGetPlatform() is a broken API, since it takes a windowing specific argument, yet is supposed to work for multiple APIs at the same time. On Linux, it can take both a X11 "Display" and a "wl_display". Obviously there is no way to specify what kind of display the argument is (it's just a void*). Mesa has _eglNativePlatformDetectNativeDisplay, which does funny stuff to try to guess the display type, including trying to call mincore() to determine whether the pointer can be accessed at all. I guess this recently accidentally broke (as a bug), but on the other hand, maybe it's time to do this properly. The fix is using eglGetPlaformDisplay(). This requires EGL 1.5, plus Mesa needs to support the associated platform extension (EGL_KHR_platform_x11). Since I see no reasonable way to do this in a compatible way, just require that EGL 1.5 is available. The problem is that EGL 1.4 seems to require you to create a display to query EGL version and extension, and you have a chicken-and-egg problem. It's very stupid. Maybe you could jump through some more hoops to get something compatible, but fuck that. Users on "too old" Mesa will fall back to GLX (which we keep around for a regrettable company known by the name of Nvidia). I think Wayland and GBM should do the same. They're sufficiently bleeding-edge that you can expect them to have EGL 1.5. On the other hand, the cursed RPI code will have to stay with a eglGetDisplay(). Speculative fix for #7154. (Rant about EGL follows. Actually I deleted it.)
* vo_gpu: sync duplicated condition on peak computationwm42019-11-161-0/+2
| | | | | | | | | | | | | | | | | | | | pass_color_map() (in video_shaders.c) and pass_colormanage() (video.c) both duplicate the condition on whether to do peak computation. Peak computation requires a compute shader, so if the duplicated conditions don't match, video_shaders.c will generate a compute shader, but video.c will try to run it as fragment shader. This leads to a "blue screen". This can be reproduced by playing a HDTV video with --target-peak=99. It's not clear how to fix this. Should pass_tone_map() be only invoked if mp_trc_is_hdr() == true (what pass_colormanage() uses to decide whether to enable peak computation), or should pass_colormanage() just tell pass_color_map() to skip peak computation? Decide for the latter, as it's more robust. Even if not correct, at least it gets rid of the blue shit. Fixes: #7149
* wayland: use hidpi-window-scale optiondudemanguy2019-11-121-0/+2
|
* build: fix compilation conditions for vaapi interop initsPhilip Sequeira2019-11-101-2/+2
| | | | | | | | | This makes the condition for including each init match the condition for compiling the file that defines it. It's possible to e.g. HAVE_GL and HAVE_VAAPI without HAVE_VAAPI_EGL, which resulted in "undefined reference to `vaapi_gl_init'" with the old code.
* vo_gpu: yuv alpha is always full rangewm42019-11-091-8/+6
| | | | | | | | | | | | | | Probably. It's not like these pixel formats are formally specified - FFmpeg added them because _some_ file format or decoder supports it, and while that format/codec may define it precisely, the pixel format is sort of disconnected and just a FFmpeg thing. In any case, the yuva sample I had at hand uses the full range the component data type can provide. The old code used the same "shifted" range as for Y/U/V components, which must have been wrong. This will not work correctly for packed YUVA formats, but fortunately they matter even less.
* vo_gpu: context_x11egl: check eglGetConfigAttrib() for errorswm42019-11-081-1/+4
| | | | | Not sure why it assumes that it always succeeds (although generally it won't fail).
* vo_gpu: vdpau actually works under EGLwm42019-11-071-4/+2
| | | | | | | | | | | | | | | | | | The use of glXGetCurrentDisplay() restricted this to the GLX backend. But actually it works under EGL as well. Removing the GLX-specific call and using the general mpv-internal method to get the X "Display" makes it work in mpv. I didn't know this. Nvidia didn't list this as extension in the EGL context when I still used their GPUs. Note that this might in theory break use of vdpau in some libmpv clients using the render API. But only if MPV_RENDER_PARAM_X11_DISPLAY is not used, and they relied on mpv using glXGetCurrentDisplay(). EGL does not provide such an API, and hwdec_vaapi.c also uses what hwdec_vdpau.c uses now. Considering that vaapi is preferable these days, it's not bad at all if these clients get "broken". They can be easily fixed by passing the display to mpv correctly.
* vo_gpu: unconditionally clear framebuffer on start of framewm42019-11-061-5/+3
| | | | | | | | | | | | | | | | | | | | | | For some reason, the first frame displayed on X11 with amdgpu and OpenGL will be garbled. This is especially visible if the player starts, displays a frame, but then still takes a while to properly start playback. With --interpolation, the behavior somehow changes (usually gets worse). I'm not sure what exactly is going on, and the code in video.c is way too abstruse. Maybe there is some slight possibility that a frame with uncleared contents gets displayed, which somehow also corrupts another frame that is displayed immediately after that. If clear is unconditionally run, this somehow doesn't happen, and you see a video frame. By any logic this shouldn't happen: a video frame should always overwrite the background. So I can't exclude that this isn't some sort of driver bug, or at least very obscure interaction. Clearing should be practically free anyway, so always do it. Fixes: #7105
* vo_x11: accept zimg formatswm42019-11-031-1/+2
| | | | | | | | | | | | This is slightly helpful for testing, and otherwise useless and without consequence. I'm not using the correct output format and using IMGFMT_RGB0 as placeholder. This doesn't matter currently, as both sws and zimg support this as output (and support any input for it). I'm doing this because it's surprisingly tricky to get the correct output format at this point, without digging deeper into x11 shit or refactoring parts of the VO. I don't care enough about this.
* vo_gpu: opengl: add support for IMGFMT_RGB30wm42019-11-021-0/+11
| | | | | | | | This integrates it as "special" format, with no alpha component, as the equivalent IMGFMT_RGB30 isn't meant to contain any. Nothing can produce this format in the video chain yet, so the next commits are needed to make this actually work.
* x11: reduce log level for relatively uninteresting thingswm42019-11-011-9/+9
| | | | | Normally nobody cares about the WM detection stuff etc., so log this only at debug log levels.
* screenshot, vo_image: use global swscale/zimg parameterswm42019-10-311-1/+1
| | | | | | | | | | Lots of dumb crap to do... something. Instead of adding yet another dumb helper, just use the main" sws_utils API in both callers. (Which, unfortunately, has been duplicated for glorious webp screenshots, despite the fact that webp is crap.) Good part: can enable zimg for screenshots (as far as needed). Bad part: uses "default" swscale parameters instead of HQ now.
* sws_utils: shuffle around some shitwm42019-10-314-8/+7
| | | | | | | | | | | Purpose uncertain. I guess it's slightly better, maybe. The move of the sws/zimg options from VO opts (vo_opt_list) to the top-level option list is tricky. VO opts have some helper code in vo.c, that sends VOCTRL_SET_PANSCAN to the VO on every VO opts change. That's because updating certain VO options used to be this way (and not just the panscan option). This isn't needed anymore for sws/zimg options, so explicitly move them away.
* Use mp_log2() instead of av_log2()wm42019-10-311-5/+3
|
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-313-20/+16
| | | | And remove libavutil includes where possible.
* vo_gpu/opengl: fully initialize FBO when passing it to renderingJan Ekström2019-10-301-2/+4
| | | | | | | Until now, we only properly initialized two values, leaving the rest be garbage. Fixes #7104
* vo_gpu/d3d11: add support for configuring swap chain color spaceJan Ekström2019-10-303-5/+183
| | | | | | | | | | | | | | | | By default utilizes the color space of the desktop on which the swap chain is located. If a specific value is defined, it will be instead be utilized. Enables configuration of the PQ color space (BT.2020 primaries, PQ transfer function) for HDR. Additionally, signals the swap chain color space to the renderer, so that the render looks correct without having to specify target-trc or target-prim manually. Due to all of the APIs being Win10+ only, will only work starting with Windows 10.
* vo_gpu/d3d11: add helpers for getting names for DXGI formats & CSPsJan Ekström2019-10-302-4/+178
| | | | | Additionally, define the few enum values that are currently missing in mingw-w64 headers.
* vo_gpu: add and utilize color space information from ra_fboJan Ekström2019-10-302-8/+40
| | | | | | | | This lets us set primaries, transfer function and the target peak based on what the presenting layer would want us to have. Now that this mechanism is available, warn if the user has overridden values such as primaries or transfer function.
* vo_caca: Implement VOCTRL_UPDATE_WINDOW_TITLECameron Cawley2019-10-291-2/+4
|
* vo_sdl: Acknowledge when the mouse enters or leaves the windowCameron Cawley2019-10-281-0/+6
|
* vo_sdl: Improve mouse button inputCameron Cawley2019-10-281-6/+28
| | | | SDL_BUTTON_X1 and SDL_BUTTON_X2 are now correctly mapped to MP_MBTN_BACK and MP_MBTN_FORWARD.
* vo_sdl: Support mouse wheel inputCameron Cawley2019-10-281-1/+11
|
* vo_gpu: log ra_format.storable with the other flagsJames Ross-Gowan2019-10-271-3/+5
| | | | | | This seems to have been missed when the storable flag was added, since all the other flags were logged here. It can be useful to know if an RA format is storable, so log it as well.
* vo_gpu: d3d11: set the ra_format.storable flagJames Ross-Gowan2019-10-271-3/+12
| | | | | This flag was added in e2976e662d92, but it was only set for Vulkan. In D3D11 it can be set from info in D3D11_FEATURE_FORMAT_SUPPORT2.
* vo_gpu: attempt to fix 0bgr formatwm42019-10-261-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | Using e.g. --vf=format=0bgr showed obviously wrong colors with --vo=gpu. The reason is that leading padding wasn't handled correctly. Try to hack fix it. While the code in copy_image() is somewhat reasonable, I can't tell what the fuck is going on with that HOOKED shit. For some reason this HOOKED shit doesn't use copy_image() (???), or uses it incorrectly. It affects debanding. --deband=no works correctly. If it's enabled, the crap in hook_prelude() is needed. I bet there are many more bugs with this. For example, the deband shader will try to deband the alpha channel if the format abgr is used (because the correct component order is only established later). This can be tested by inserting a "color.x = 0;" at the end of the deband shader, and using --vf=format=rgba vs. abgr. I cannot comprehend why it doesn't just store explicitly which components a texture contains, and why it doesn't just read the components always in an uniform way. There's a big chance this fix works only by coincidence. This shouldn't have been so hard either. Time for a complete rewrite?
* sdl: prevent concurrent use of SDL in different threadswm42019-10-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | sdl_gamepad.c and vo_sdl.c both have their own event loops and run in separate threads. They don't know of each other (and shouldn't). Since SDL only has one global event loop (why didn't they fix this in SDL2?), these obviously clash. The actual behavior is relatively subtle, which event being randomly dispatched to either of the threads. This is very regrettable. Very. Work this around. "Fortunately" SDL exposes its global state to some degree. SDL_WasInit() returns whether a "subsystem" was initialized, and you could say the one who initialized it owns it. Both SDL_INIT_VIDEO and SDL_INIT_GAMECONTROLLER implicitly enable SDL_INIT_EVENTS, and the event loop is indeed the resource that cannot be shared. Unfortunately, this is still racy, since SDL_InitSubSystem is a second call, and succeeds if the subsystem is already initialized (increases a refcount I think). But good enough. Blame SDL for everything. (I think I made this commit message too long. Nobody cares even.) Fixes: #7085
* vo_sdl: put on do not use stampwm42019-10-251-0/+3
| | | | | | | | | It seems some users try to use it (!). This VO was always an experiment, and intended for low power devices. Whether this experiment succeeded or not, it's a rather obscure VO. Recently I've seen a regrettable user, who seemed to use this only because mpv was built without x11 support (!). Add this warning, like other fallback VOs have it. (The message was copied from vo_x11.)
* vo_gpu: d3d11: prevent wraparound in queued frames calcJames Ross-Gowan2019-10-261-1/+2
| | | | | | | If expected_sync_pc is greater than submit_count, the unsigned subtraction will wraparound, which breaks playback. This bug was found while experimenting with bit-blt model present, but it might be possible to trigger it with the flip model as well, if there was a dropped frame.
* vo_drm: allow use of zimgwm42019-10-251-0/+1
|
* vo_gpu, options: don't return NaN through APIwm42019-10-251-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | Internally, vo_gpu uses NaN for some options to indicate a default value that is different depending on the context (e.g. different scalers). There are 2 problems with this: 1. you couldn't reset the options to their defaults 2. NaN is a damn mess and shouldn't be part of the API The option parser already rejected NaN explicitly, which is why 1. didn't work. Regarding 2., JSON might be a good example, and actually caused a bug report. Fix this by mapping NaN to the special value "default". I think I'd prefer other mechanisms (maybe just having every scaler expose separate options?), but for now this will do. See you in a future commit, which painfully deprecates this and replaces it with something else. I refrained from using "no" (my favorite magic value for "unset" etc.) because then I'd have e.g. make --no-scale-param1 work, which in addition to a lot of effort looks dumb and nobody will use it. Here's also an apology for the shitty added test script. Fixes: #6691
* input: add gamepad support through SDL2Stefano Pigozzi2019-10-231-1/+1
| | | | | | | | | | | | | | | The code is very basic: - only handles gamepads, could be extended for generic joysticks in the future. - only has button mappings for controllers natively supported by SDL2. I heard more can be added through env vars, there's also ways to load mappings from text files, but I'd rather not go there yet. Common ones like Dualshock are supported natively. - analog buttons (TRIGGER and AXIS) are mapped to discrete buttons using an activation threshold. - only supports one gamepad at a time. the feature is intented to use gamepads as evolved remote controls, not play multiplayer games in mpv :)
* wayland: don't get data device if wl_seat is nulldudemanguy2019-10-221-2/+2
|
* wayland: fix presentation timeDudemanguy9112019-10-205-2/+23
| | | | | | | | | | There's 2 stupid things here that need to be fixed. First of all, vulkan wasn't actually using presentation time because somehow the get_vsync function in context.c disappeared. Secondly, if the mpv window was hidden it was updating the ust time based on the refresh_usec but really it should simply just not feed any information to the vsync info structure. So this adds some logic to assume whether or not a window is hidden.
* wayland: add various render-related optionsdudemanguy2019-10-204-5/+29
| | | | | The newest wayland changes have some new logic that make sense to expose to users as configurable options.
* 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.
* 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.
* 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
* 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.
* 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