summaryrefslogtreecommitdiffstats
path: root/video/out
Commit message (Collapse)AuthorAgeFilesLines
* vo_x11: add 10 bit supportwm42020-05-141-0/+3
| | | | Requires zimg.
* drm: add typedef for PFNEGLGETPLATFORMDISPLAYEXTPROC (#7314)Jan Palus2020-05-141-0/+5
| | | | extension is not mandatory and is not provided on ie Raspberry Pi
* vo_direct3d: dumb down OSD renderingwm42020-05-131-164/+92
| | | | | | | | | | | | | | Render most of the OSD on the CPU, then draw it using a relatively simple method. Do this for minimum code maintenance overhead. (While it doesn't matter for vo_direct3d, and the effort spent here is probably more than this would ever hope, I do hope to simplify the internal OSD API for all these fringe VOs. Only vo_gpu should be allowed to do more sophisticated things.) If your GPU is shit (which it will be if you "want" to use vo_direct3d), this might actually improve performance... is what I'd say, but out of laziness a full screen sized texture gets uploaded on every OSD/subtitle change, so maybe not.
* vo_direct3d: rip out texture video rendering pathwm42020-05-133-635/+66
| | | | | | | | | | | | | This isn't useful anymore. We have a much better d3d11 renderer in vo_gpu. D3D11 is available in all supported Windows versions. The StretchRect path might still be useful for someone (???), and leaving it at least evades conflict about users who want to keep using this VO for inexplicable reasons. (Low power usage might be a justified reason, but still, no.) Also fuck the win32 platform, it's a heap of stinky shit. Microsoft is some sort of psycho clown software company. Granted, maybe still better than much of the rest of Silly Con Valley.
* draw_bmp: use command line options for any used scalerswm42020-05-131-1/+1
|
* vo_gpu: un-fix storable fbo format checkNiklas Haas2020-05-131-2/+1
| | | | | | | | | The original solution for #7017 was sort of a hack, but this hack is no longer needed because c05e5d9d fixed the underlying issue causing this error to be spammed in the first place. So just remove the "fix" that apparently introduced about as many issueas it fixed. Fixes #7719, hopefully.
* vo_vaapi: use new overlay APIwm42020-05-111-123/+85
| | | | | | | | | | | | | This will probably make it slower. But since I don't care about vo_vaapi, that's perfectly OK. It serves mostly as a test for the previous commit. In addition, this code was pretty bad (custom broken scaling and not-blending that probably broke in some situation). If that wasn't enough, some vaapi drivers also provide only a single overlay at a time, while this code required a bunch. There also seems to be a Mesa bug: the overlay gets stretched when src_x/y was not 0. Or maybe I misunderstood how this is supposed to work. A bug is probably more likely? Nobody cares about this API.
* video: remove RGB32/BGR32 aliaseswm42020-05-111-2/+2
| | | | | | | They are sort of confusing, and they hide the fact that they have an alpha component. Using the actual formats directly is no problem, sicne these were useful only for big endian systems, something we can't test anyway.
* vo: fix forgotten debug codewm42020-05-101-1/+1
| | | | | | | This was not intended to be committed in 0e3f8936062967a9db. It disables the extra wakeup if working==true. I've convinced myself that the wakeup was really needed at the time, so no idea how I didn't notice this until someone pointed it out on the commit diff on github (lol).
* vo_gpu: manually resolve user shader prefixeswm42020-05-101-1/+4
| | | | | | | | This resolves prefixes such as "~/" and "~~/" at the caller, instead of relying on stream_read_file() to do it. One of the following commits will remove this from stream_read_file() itself. Untested.
* vo: another minor wakeup reductionwm42020-05-091-5/+10
| | | | | | The caller of render_frame() re-iterates without waiting if this function returns true. That's normally meant for DS, where we draw frames as fast as possible to let the driver perform waiting.
* vo: always reset redraw flag to avoid immediate wakeups wasting CPU timewm42020-05-091-1/+2
| | | | | | | This could temporarily hog the core or something because it's a stupid fragile state machine that should best be wiped out. Fixes: #7699
* vo_gpu: fix green shit with float yuv inputwm42020-05-093-12/+23
| | | | | | | | | | | | This was incorrect at least because the colorspace matrix attempted to center chroma at (conceptually) 0.5, instead of 0. Also, it tried to apply the fixed point shift logic for component sizes > 8 bit. There is no float yuv format in mpv/ffmpeg yet, but see next commit, which enables zimg to output it. I'm assuming zimg defines this format such that luma is in range [0,1] and chroma in range [-0.5,0.5], with the levels flag being ignored. This is consistent with H264/5 Annex E (I think...), and it sort of seems to look right, so that's it.
* video: fix rgb30 component orderwm42020-05-091-1/+1
| | | | | | | | | Was broken with a zimg wrapper refucktor before the previous commit. In addition, it seems this didn't match the vo_drm format, or the format naming convention. So the order actually changes, and the format is redefined. (The img_format.h comment was probably wrong.) Change vo_gpu to the new format as well, so we can still test it.
* drm_prime: fallback to drmModeAddFB2Anton Kindestam2020-05-081-3/+9
| | | | | | | | | | Fallback to drmModeAddFB2 if drmModeAddFB2WithModifiers fails. I've observed it failing on a pinebook pro running manjaro. We also got "0" as modifiers from FFmpeg anyway, which might or might not have something to do with this. Instead of trying to find the source of the problem, just add this fallback.
* drm_prime: get the modifier for all planesAnton Kindestam2020-05-081-6/+5
| | | | | | Untested (I don't have a platform that requires modifiers to work here). Might break something, or might fix something. At least this looks more intuitive to me.
* drm_prime: print out errno in error messageAnton Kindestam2020-05-081-1/+4
| | | | It is interesting to know why drmModeAddFB2WithModifiers failed.
* w32_common: Scale window when moving to display with different DPIPiotr Gasior2020-05-081-0/+5
| | | | | For applications that are DPI aware WM_DPICHANGED message contains suggested size and position of window
* w32_common: Support HiDPI on WindowsRealDolos2020-05-081-8/+24
|
* vo_gpu: d3d11: only use presentation feedback with flip modelJames Ross-Gowan2020-05-071-4/+12
| | | | | | | | | | | The current implementation of presentation feedback was designed to be used with flip model presentation. With the bitblt model, GetFrameStatistics returns totally different values and it's not clear if we can use them at all. Previously, this wasn't a problem because with the bitblt model, GetFrameStatistics only worked in exclusive fullscreen. Now that mpv supports exclusive fullscreen, we should explicitly check for a flip model swapchain before using presentation feedback.
* vo_gpu: suppress PL_FATAL logs during probingNiklas Haas2020-05-031-2/+0
| | | | | | | | | These were still mapped to MP errors during probing, but they also get triggered when instance creation fails due to lack of support for e.g. wayland. Since waylandvk is probed above x11vk, we should probably suppress these by default. Closes #7626
* vo_gpu: enable frame caching for still framesNiklas Haas2020-04-301-3/+3
| | | | | | | | | | For some reason this was never done? Looking through the code, it was never the case that the frame cache was hit for still frames. I have no idea why not. It makes a lot of sense to do so. Notably, this massively improves the performance of updating the OSC when viewing e.g. large still images, or while paused. (Tested on a 4000x8000 image, the OSC now responds smoothly to user input)
* cocoa-cb: report actual unfs window size for current window scaleder richter2020-04-252-0/+15
|
* video: add alpha type metadatawm42020-04-241-2/+4
| | | | | | | | | This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
* video/out/vo_tct: query terminal size genericallyAvi Halachmi (:avih)2020-04-231-7/+3
| | | | | terminal_get_size also works on windows. This is useful because now tct also works on Windows with native VT console.
* wayland: explictly send an UP event for left clickDudemanguy2020-04-231-0/+2
| | | | | | | | | | | | | | | In the wayland code, the left mouse click is treated a bit differently. Dragging the left click allows mpv to request a window move to the compositor. In some cases, this can also request a window resize if the osc-windowcontrols are enabled. These functions had the strange side effect of messing up mpv's deadzone (it seemed to disappear completely). A harmless enough workaround is to just explictly send an UP event for left click after the move/resize functions are finished executing. The xdg_toplevel move and resize functions both finish after the button press is let go, so we are guarenteed to have the left click in the UP state here. Sending this event probably unconfuses some calculation somewhere thus fixing the deadzone bug. It feels a little silly, but it's safe and works. Fixes #7651.
* rpi: use "brcm" variant of libGLESv2Jan Palus2020-04-231-1/+1
|
* egl_helpers: add typedef for EGLAttrib (#7314)Jan Palus2020-04-231-0/+1
| | | | part of EGL 1.5 which is not present ie on Raspberry Pi
* video: change chroma_w/chroma_h fields to use shift instead of sizewm42020-04-231-2/+2
| | | | | | | | | | When I added mp_regular_imgfmt, I made the chroma subsampling use the actual chroma division factor, instead of a shift (log2 of the actual value). I had some ideas about how this was (probably?) more intuitive and general. But nothing ever uses non-power of 2 subsampling (except jpeg in rare cases apparently, because the world is a bad place). Change the fields back to use shifts and rename them to avoid mistakes.
* drm_common: set frsig to a valid signalJan Beich2020-04-221-0/+3
| | | | | | | | | | | On FreeBSD and DragonFly kernel checks if `frsig` is valid and aborts with `EINVAL` if not. However, `frsig` was never implemented. $ build/mpv --gpu-context=drm /path/to/video.mkv [...] [vo/gpu] VT_SETMODE failed: Invalid argument [vo/gpu/opengl] Failed to set up VT switcher. Terminal switching will be unavailable. [...]
* build: detect VT_GETMODE on FreeBSD and DragonFlyJan Beich2020-04-221-1/+8
| | | | | | | | | | | | | | | | $ ./waf configure Checking for vt.h : no Checking for DRM : vt.h not found [...] ../test.c:1:10: fatal error: 'sys/vt.h' file not found #include <sys/vt.h> ^~~~~~~~~~ $ build/mpv --gpu-context=drm /path/to/video.mkv Error parsing option gpu-context (option parameter could not be parsed) Setting commandline option --gpu-context=drm failed. Exiting... (Fatal error)
* wayland: use mp_time deltas for presentation timeDudemanguy2020-04-204-30/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One not-so-nice hack in the wayland code is the assumption of when a window is hidden (out of view from the compositor) and an arbitrary delay for enabling/disabling the usage of presentation time. Since you do not receive any presentation feedback when a window is hidden on wayland (a feature or misfeature depending on who you ask), the ust is updated based on the refresh_nsec statistic gathered from the previous feedback event. The flaw with this is that refresh_nsec basically just reports back the display's refresh rate (1 / refresh_rate * 10^9). It doesn't tell you how long the vsync interval really was. So as a video is left playing out of view, the wl->last_queue_display_time becomes increasingly inaccurate. This led to a vsync spike when bringing the mpv window back into sight after it was hidden for a period of time. The hack for working around this is to just wait a while before enabling presentation time again. The discrepancy between the "bogus" wl->last_queue_display_time and the actual value you get from the feedback only happens initially after a switch. If you just discard those values, you avoid the dramatic vsync spike. It turns out that there's a smarter way to do this. Just use mp_time_us deltas. The whole reason for these hacks is because wl->last_queue_display_time wasn't close enough to how long it would take for a frame to actually display if it wasn't hidden. Instead, mpv's internal timer can be used, and the difference between wayland_sync_swap calls is a close enough proxy for the vsync interval (certainly better than using the monitor's refresh rate). This avoids the entire conundrum of massive vsync spikes when bringing the player back into view, and it means we can get rid of extra crap like wl->hidden.
* vo_gpu: opengl: make sure to always clean up debug callbacksNiklas Haas2020-04-151-0/+4
| | | | | | | | | In theory this mostly happens automatically, especially after the 5 vsync limit disables this already. But if we uninit before 5 vsyncs are rendered, this can get left in a dangling 'enabled' state, which leaks a debug report callback. Always explicitly disable it just to be on the safe side.
* vo_gpu: d3d11: also utilize config cache for d3d11-specific optionsJan Ekström2020-04-121-1/+9
| | | | | Update the cache whenever we utilize p->opts, as recommended by wm4.
* vo_gpu: d3d11: add support for exclusive fullscreenJames Ross-Gowan2020-04-121-1/+86
| | | | | Lets the application fully control the rendering onto the screen instead of the compositor.
* vo: further reduce redundant wakeupswm42020-04-101-1/+7
| | | | | | | | | | | | | | | In display-sync mode, the core doesn't need to woken up every vsync, but only every time a new actual video frame needs to be queued. So don't wake up if there are still frames to repeat. In audio-sync mode, the wakeup is simply redundant, since there's a separate timer (in->wakeup_pts) to control when to queue a new frame. I think. This finally brings the required playloop iterations down to almost the number of video frames. (As originally intended, really.) Also a fairly risky change.
* video: remove another redundant wakeupwm42020-04-102-19/+43
| | | | | | | | | | | | | | | The wakeup at the end of VO frame rendering seems redundant, because after rendering almost no state changes. The player core can queue a new frame once frame rendering begins, and there's a separate wakeup for this. The only thing that actually changes is in->rendering. The only thing that seems to depend on it and can trigger a wakeup is the vo_still_displaying() function. Change it so that it needs an explicit call to a new API function, so we can avoid wakeups in the common case. The vo_still_displaying() code is mostly just moved around due to locking and for avoiding forward declarations. Also a somewhat risky change (tasty new bugs).
* stats: some more performance graphswm42020-04-091-4/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add an infrastructure for collecting performance-related data, use it in some places. Add rendering of them to stats.lua. There were two main goals: minimal impact on the normal code and normal playback. So all these stats_* function calls either happen only during initialization, or return immediately if no stats collection is going on. That's why it does this lazily adding of stats entries etc. (a first iteration made each stats entry an API thing, instead of just a single stats_ctx, but I thought that was getting too intrusive in the "normal" code, even if everything gets worse inside of stats.c). You could get most of this information from various profilers (including the extremely primitive --dump-stats thing in mpv), but this makes it easier to see the most important information at once (at least in theory), partially because we know best about the context of various things. Not very happy with this. It's all pretty primitive and dumb. At this point I just wanted to get over with it, without necessarily having to revisit it later, but with having my stupid statistics. Somehow the code feels terrible. There are a lot of meh decisions in there that could be better or worse (but mostly could be better), and it just sucks but it's also trivial and uninteresting and does the job. I guess I hate programming. It's so tedious and the result is always shit. Anyway, enjoy.
* video: report negative subtitle/OSD margins if necessarywm42020-03-261-4/+4
| | | | | | | | | | | | | | Until now, it used only coordinates clipped to the screen for this, which meant no negative margins were ever reported to libass. This broke proper rendering of explicitly positioned ASS events (libass simply could not know the real video size in this case.) Fix this by reporting margins even if they're negative. This makes it apparently work correctly with vo_gpu at least. Note that I'm not really sure if anything in the rendering chain required non-negative margins. If so, and that code implicitly assumed it, I suppose crashes and such are possible.
* wayland: simplify mouse wheel direction calculationJan Ekström2020-03-191-3/+2
| | | | | Based on an idea by sfan5. Remove abs usage, and instead just check for negative value, and set variable to either +/-1.
* options: change option macros and all option declarationswm42020-03-1823-296/+300
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Change all OPT_* macros such that they don't define the entire m_option initializer, and instead expand only to a part of it, which sets certain fields. This requires changing almost every option declaration, because they all use these macros. A declaration now always starts with {"name", ... followed by designated initializers only (possibly wrapped in macros). The OPT_* macros now initialize the .offset and .type fields only, sometimes also .priv and others. I think this change makes the option macros less tricky. The old code had to stuff everything into macro arguments (and attempted to allow setting arbitrary fields by letting the user pass designated initializers in the vararg parts). Some of this was made messy due to C99 and C11 not allowing 0-sized varargs with ',' removal. It's also possible that this change is pointless, other than cosmetic preferences. Not too happy about some things. For example, the OPT_CHOICE() indentation I applied looks a bit ugly. Much of this change was done with regex search&replace, but some places required manual editing. In particular, code in "obscure" areas (which I didn't include in compilation) might be broken now. In wayland_common.c the author of some option declarations confused the flags parameter with the default value (though the default value was also properly set below). I fixed this with this change.
* wayland: notify vo if an output changesDudemanguy2020-03-151-0/+2
| | | | | | | | Previously, the vo wasn't always informed if something about the output changed during playback. For instance, changing a display's refresh rate during playback would not update mpv's display fps. Fix this by simply using VO_EVENT_WIN_STATE in output_handle_done which executes whenever something about the output is changed.
* vo_gpu: warn if correct-downscaling is ignoredAvi Halachmi (:avih)2020-03-141-0/+11
| | | | And document that it's ignored with bilinear scaler.
* cocoa-cb: support maximize/minimize on startupder richter2020-03-141-1/+9
| | | | | | | Allow the --window-maximized and --window-minimized flags to actually work when the player is started. since macOS doesn't like using both at the same time the minimized state takes precedence over the maximized state.
* options: change how option range min/max is handledwm42020-03-132-3/+4
| | | | | | | | | | | | | | | | | Before this commit, option declarations used M_OPT_MIN/M_OPT_MAX (and some other identifiers based on these) to signal whether an option had min/max values. Remove these flags, and make it use a range implicitly on the condition if min<max is true. This requires care in all cases when only M_OPT_MIN or M_OPT_MAX were set (instead of both). Generally, the commit replaces all these instances with using DBL_MAX/DBL_MIN for the "unset" part of the range. This also happens to fix some cases where you could pass over-large values to integer options, which were silently truncated, but now cause an error. This commit has some higher potential for regressions.
* options: remove intpair option typewm42020-03-131-1/+2
| | | | | | | | | | | This was mostly unused, and has certain problems. Just get rid of it. It was still used in CDDA (--cdda-span) and a debug option for OpenGL (--opengl-check-pattern). Replace both of these with 2 options, where each sets the start/end values of the former span. Both were undocumented somehow (normally we require all options to be documented), so I'm not caring about compatibility, and not bothering to add it to the API changelog.
* video/out/android_common: use jni helpersAman Gupta2020-03-121-10/+11
| | | | Signed-off-by: Aman Gupta <aman@tmm1.net>
* vo_gpu: generally allow non-storable FBOsNiklas Haas2020-03-082-3/+12
| | | | | | | | | | | | | We have this cap now thanks to e2976e662, but we don't actually make sure our FBOs are storable before we blindly attempt using them with compute shaders. There's no more need to unconditionally set `storage_dst = true` as long as we make sure to include an extra condition on the `fbo_format` selection to prevent users from accidentally enabling compute-shader-only features with non-storable FBOs, alongside some other miscellaneous adjustments to eliminate instances of "assumed storability" from vo_gpu.
* vo_gpu: avoid error spam when ra_fbo fmt is non-storableNiklas Haas2020-03-081-0/+2
| | | | | | | | | | | This simply makes the "is the destination FBO format bad?" check a tiny bit less awful, by making sure we prefer storable FBO formats over non-storable FBO formats. I'd love to make this also conditional on whether or not we actually *need* a storable FBO format, but that logic is decided later, in `pass_draw_to_screen`, and I don't want to replicate the logic. Fixes #7017.
* wayland: always use the fs-screen id for fsDudemanguy2020-03-081-33/+31
| | | | | | | | | Previously if the --fs-screen option was set, it would only use the screen if mpv was launched with --fs and only on startup. During runtime, the toggle would ignore it. Rework the logic here so that mpv's fullscreen always uses --fs-screen if it is set. Additionally, cleanup some unneeded cruft in vo_wayland_reconfig and make find_output more useful.
* drm_prime: double free bugSven Kroeger2020-03-053-15/+93
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit fixes a bug where handle for a framebuffer gets double freed. It seems to happen that the same prime fd gets two framebuffers. As the prime fd is the same the resulting prime handle is also the same. This means one handle but 2 framebuffers and can lead to the following chain: 1. The first framebuffer gets deleted the handle gets also freed via the ioctl. 2. In startup phase not all 4 dumb buffers for overlay drawing are set up. It can happen that the last dumb buffer gets the handle we freed above. 3. The second framebuffer gets freed and the handle will be freed again resulting that the