summaryrefslogtreecommitdiffstats
path: root/video
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.
* repack: fix incorrect assert()wm42020-05-121-1/+1
| | | | | Used the output of the first step instead of the input when checking the real input.
* 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-113-12/+3
| | | | | | | 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
* draw_bmp: rewritewm42020-05-091-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | draw_bmp.c is the software blender for subtitles and OSD. It's used by encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11, vo_xv, and possibly more. This changes the algorithm from upsampling the video to 4:4:4 and then blending to downsampling the OSD and then blending directly to video. This has far-reaching consequences for its internals, and results in an effective rewrite. Since I wanted to avoid un-premultiplying, all blending is done with premultiplied alpha. That's actually the sane thing to do. The old code just didn't do it, because it's very weird in YUV fixed point. Essentially, you'd have to compensate for the chroma centering constant by subtracting src_alpha/255*128. This seemed so hairy (especially with correct rounding and high bit depths involved) that I went for using float. I think it turned out mostly OK, although it's more complex and less maintainable than before. reinit() is certainly a bit too long. While it should be possible to optimize the RGB path more (for example by blending directly instead of doing the stupid float conversion), this is probably slower. vo_xv users probably lose in this, because it takes the slowest path (due to subsampling requirements and using YUV). Why this rewrite? Nobody knows. I simply forgot the reason. But you'll have it anyway. Whether or not this would have required a full rewrite, at least it supports target alpha now (you can for example hard sub transparent PNGs, if you ever wanted to use mpv for this). Remove the check in vf_sub. The new draw_bmp.c is not as reliant on libswscale anymore (mostly uses repack.c now), and osd.c shows an error message on missing support instead now. Formats with chroma subsampling of 4 are not supported, because FFmpeg doesn't provide pixfmt definitions for alpha variants. We could provide those ourselves (relatively trivial), but why bother.
* repack: add support for converting from/to float formatswm42020-05-092-0/+120
| | | | | Will be needed by draw_bmp.c. The tests cross-check this with zimg to control whether we're getting it right.
* csputils: add function for getting uint/float transformationwm42020-05-092-1/+44
| | | | | | | | | | | | | | This provides a way to convert YUV in fixed point (or pseudo-fixed point; probably best to say "uint") to float, or rather coefficients to perform such a conversion. Things like colorspace conversion is out of scope, so this is simple and strictly per-component. This is somewhat similar to mp_get_csp_mul(), but includes proper color range expansion and correct chroma centering. The old function even seems to have a bug, and assumes something about shifted range for full range YCbCr, which is wrong. vo_gpu should probably use the new function eventually.
* video: add yuv float formatswm42020-05-093-11/+59
| | | | | | | | | | | Adding all these so I can use them for obscure processing purposes (see later draw_bmp commit). There isn't really a reason why they should exist. On the other hand, they're just labels for formats that can be handled in a generic way, and this commit adds support for them in the zimg wrapper and vo_gpu just by making the formats exist. (Well, vo_gpu had to be fixed in the previous commit.)
* vo_gpu: fix green shit with float yuv inputwm42020-05-095-12/+28
| | | | | | | | | | | | 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-093-4/+4
| | | | | | | | | 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.
* video: separate repacking code from zimg and make it independentwm42020-05-094-895/+1244
| | | | | | | | | | | | | For whatever purpose. If anything, this makes the zimg wrapper cleaner. The added tests are not particular exhaustive, but nice to have. This also makes the scale_zimg.c test pretty useless, because it only tests repacking (going through the zimg wrapper). In theory, the repack_tests things could also be used on scalers, but I guess it doesn't matter. Some things are added over the previous zimg wrapper code. For example, some fringe formats can now be expanded to 8 bit per component for convenience.
* sws_utils: allow setting zimg options directlywm42020-05-094-8/+18
| | | | One could wonder, why not just use the zimg wrapper directly?
* img_format: make component order in comment more logicalwm42020-05-091-1/+1
|
* 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.
* vf:format: don't error when using convert=yes and not specifying fmtwm42020-05-061-1/+1
|
* mp_image: add some helperswm42020-05-062-0/+23
| | | | | | | | | | This is really basic for planar image data access; not sure why there weren't such helpers before. They also handle trickier formats that use bit-packing, or they would be mich simpler. (This affects only BGR4/BGR4/MONOW/MONOH, I hope whoever invented them is proud of triggering so many special cases for so little gain.)
* 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
* zimg: remove C11 aligned_alloc() requirementwm42020-05-012-5/+10
| | | | | It's not available on Windows because MinGW is fucking horrible and Microsoft are fucking assholes.
* 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)
* zimg: don't assume zimg reads are 64 byte alignedwm42020-04-251-4/+6
| | | | | | | | | Only _writes_ are aligned, so the assumption doesn't work for reads. But it's easy to fix by rounding down x0 to the next byte boundary. Writing pixels outside of the read area is allowed, and we don't go out of buffer bounds. Patch by anon32, permission to do anything with it.
* cocoa-cb: report actual unfs window size for current window scaleder richter2020-04-252-0/+15
|
* video: add alpha type metadatawm42020-04-247-4/+34
| | | | | | | | | 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.
* sws_utils: remove unused brightness etc. controlswm42020-04-242-7/+1
| | | | | | | Used to be used by vo_x11, and some other situations where software conversion was employed. Haven't seen anyone complain about how software brightness controls went away (originating from mplayer), so whatever, it won't be needed again.
* 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
* zimg: get rid of special "override" fields for low depth RGB/graywm42020-04-231-34/+16
| | | | | This makes it use the previously added fringe image formats. What is the purpose of this change? Who knows.
* zimg: slightly cleanup some mpv format handling nonsensewm42020-04-231-34/+40
| | | | | | | | | | | | Move lookup GBRP or planar gray/alpha formats to separate functions in some cases. Make setup_regular_rgb_packer() not use a 4:4:4 YUV format to "pass" RGB. This was used as a "trick" to avoid the stupid GBRP plane permutation, but it confused severely, so get rid of it. Just do the reordering, even if the zimg wrapper itself will reorder it back (which is so stupid that I used the other approach at first). The comment saying IMGFMT_420P was bogus of course; typically it was IMGFMT_444P.
* img_format: treat both monow and monob as RGBwm42020-04-231-1/+3
| | | | | | | | | This was inconsistent for unknown reason. monob was the way we wanted it, and handling of monow was missing. See the previous "img_format: add some mpv-only helper formats" commit. Matters for the zimg wrapper.
* img_format: remove duplication in FFmpeg yuv vs. rgb pixfmt checkwm42020-04-231-7/+9
| | | | | | | | mp_imgfmt_get_forced_csp() should be consistent with the MP_CSP_RGB/YUV flags. At least the different handling of the XYZ exception was a mess, even if the result was the same.
* img_format: add some mpv-only helper formatswm42020-04-232-0/+34
| | | | | | | | | | | | | | | | | Utterly useless, but the intention is to make dealing with corner case pixel formats (forced upon us by FFmpeg, very rarely) less of a pain. The zimg wrapper will use them. (It already supports these formats automatically, but it will help with its internals.) Y1 is considered RGB, even though gray formats are generally treated as YUV for various reasons. mpv will default all YUV formats to limited range internally, which makes no sense for a 1 bit format, so this is a problem. I wanted to avoid that mp_image_params_guess_csp() (which applies the default) explicitly checks for an image format, so although a bit janky, this seems to be a good solution, especially because I really don't give a shit about these formats, other than having to handle them. It's notable that AV_PIX_FMT_MONOBLACK (also 1 bit gray, just packed) already explicitly marked itself as RGB.
* video: change chroma_w/chroma_h fields to use shift instead of sizewm42020-04-235-48/+39
| | | | | | | | | | 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.
* img_format: add format description table for mpv-only formatswm42020-04-232-133/+148
| | | | | | | Make this slightly less ad-hoc. Also correct the missing alpha flag for yap8/yap16. Despite reduced redundancy, the LOC is going up anyway... whatever.
* 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.
* zimg: fix swapped chroma planes with packed YUV bullshitwm42020-04-141-4/+4
| | | | | | | | | I must have messed this up when I actually added the Y210 format (because that one is correct). So my comment in the commit adding this about the FFmpeg pixfmt doxygen being wrong was wrong. I'd like to use this opportunity to complain once more about the existence of these terrible pixel formats.
* zimg: fix build with older FFmpeg (troublesome Intel dude format)wm42020-04-141-0/+2
|
* zimg: add support for 1 bit per pixel formatswm42020-04-131-0/+52
| | | | | | | | | | | | | | Again worthless, slow, and only for libswscale parity. With this, we support all formats libswscale supports, except bayer input, and rgb4/bgr4 output. We even support some formats libswscale doesn't. It's possible that the zimg wrapper isn't always as fast as libswscale. But there is optimization potential: the inner repack loops are self-contained enough that they could be reasonably be implemented in assembler (probably), and doing everything slice-wise should reduce the overhead of the separate pack/unpack stages.
* zimg: add packed YUV bullshitwm42020-04-131-1/+111
| | | | | |