summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* lua: do not use Lua filesystem functions for loading scriptswm42020-05-101-3/+6
| | | | | | | | | | | Bill Gates did not only create COVID, he's also responsible for the world's worst OS, where you have to literally jump through hoops of fire to open files with Unicode file names. Lua did not care to implement any jumping, so it's our turn to jump. Untested (on win32). Fixes: #7701
* stream: make stream_read_file() more robustwm42020-05-103-23/+41
| | | | | | | | | Change it to strictly accept local paths only. No more http://, no more $HOME expansion with "~/" or mpv config path expansion with "~~/". This should behave as if passing a path directly to open(). Reduce annoying log noise to further facilitate it using as open() replacement.
* msg: add function to reduce log levelwm42020-05-102-2/+19
| | | | | | | | | | Sometimes it's helpful to override this for specific mp_log instances, because in some specific circumstances you just want to suppress log file noise you never want to see. -1 is an allowed value (for suppressing MSGL_FATAL==0). It looks like the libplacebo wrapper still does this wrong, so it will probably trigger UB in some cases. I guess I don't care, though.
* 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.
* player: make external subtitle auto-loading stricterwm42020-05-092-25/+41
| | | | | | | | | | | | | | | | | | | | | | | | | By default --sub-auto uses "exact". This was far from an "exact" match, because it added anything that started with the video filename (without extension), and seemed to end in something that looked like a language code. Make this stricter. "exact" still tolerate a language code, but the video's filename must come before it without any unknown extra characters. This may not load subtitles in some situations where it previously did, and where the user might think that the naming convention is such that it should be considered an exact match. The subtitle priority sorting seems a bit worthless. I suppose it may have some value in higher "fuzz" modes (like --sub-auto=fuzzy). Also remove the mysterious "prio += prio;" line. I probably shouldn't have checked, but it goes back to commit f16fa9d31 (2003), where someone wanted to "refine" the priority without changing the rest of the code or something. Mostly untested, so have fun. Fixes: #7702
* options: update OSD when writing some OSD-related optionswm42020-05-091-9/+9
| | | | | | Just the usual change notification mess. Fixes: #7697
* 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-096-411/+938
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-094-3/+402
| | | | | 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-095-11/+181
| | | | | | | | | | | 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-095-5/+8
| | | | | | | | | 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-099-895/+1688
| | | | | | | | | | | | | 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
|
* sd_lavc: fix occasional problems with certain VOs when changing scalingwm42020-05-091-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | The OSD is passed to VOs via struct sub_bitmaps, which has a change_id field. This field is incremented whenever there is a (potential) change to the other struct contents. If not, the VO can rely on it not having changed. This must include for example sub_bitmap.x and sub_bitmap.dw. If these two fields (and y equivalents) change, change_id must change, even if the subtitle bitmap data might still be the same. sd_lavc.c stopped respecting this at some unknown point. It could sometimes cause problems, though usually only with bad and old VOs which somehow relied on this more than vo_gpu. (I've actually encountered this before with sd_lavc subtitle scaling, as indicated by a nasty comment, though probably didn't track this down, since said old VOs can die in a fire.) Fix this by maintaining the change_id explicitly. Unfortunately adds even more code. Instead of comparing the result we could track property changes, but I think this is better. The number of parts is always very low with this subtitle decoder, so there's no actual performance issue to worry about. This could be triggered by scaling changes (video-zoom etc.), but probably also changing bitmap subtitle position or scaling.
* osd: add change timestamp and screen size to struct sub_bitmap_listwm42020-05-093-1/+23
| | | | | | | | Should be somewhat helpful. (All VOs are full of code trying to compensate for this, more or less, and this will allow simplifying some code later. Maybe.) The screen size is mostly for robustness checks.
* osd: add subtitle software blending to statswm42020-05-091-0/+4
|
* build: add -fno-math-errnowm42020-05-091-0/+1
| | | | | | | | | | | glibc/gcc make certain math functions set errno by default. This is not required by the standard, and makes everything complexer and slower (well done glibc). It typically prevents inlining certain math functions too, where the compiler can turn a function call to a single instruction, such as observed with lrint(). So this has possibly some minor performance advantages, and no disadvantages.
* 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-083-12/+29
|
* 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.
* client API: correct an outdated commentwm42020-05-061-2/+1
|
* options: don't trigger bool "compact" path for --loop-filewm42020-05-062-2/+4
| | | | | | | In theory an incompatible change, but I think it's for the better. Impact should be relatively low. I hope. Fixes: #7676
* vf:format: don't error when using convert=yes and not specifying fmtwm42020-05-061-1/+1
|
* test: fix some idiotic UBwm42020-05-061-3/+3
|
* 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
* documentation: fix some ReST syntax mistakes in lua.rstEmanuele Torre2020-05-011-1/+1
|
* player: round position percentage to the nearest integerRicardo Garcia2020-05-011-1/+1
| | | | | | This brings the displayed percentage closer to the exact number and allows mpv to more frequently display 100% when it finishes playing a typical video or audio file.
* DOCS/contribute.md: add some blabla about fixup commits in pull requestswm42020-05-011-0/+16
| | | | | | | I have to say this in PR reviews all the time, so maybe I should make i explicit. In too many words of course, many, many, too many words which nobody will read, I get it, now shut up. Sneak in some subtle or not so subtle comments about how I think that github is ruining code quality.
* lua: restore change detection with legacy OSD functionwm42020-05-011-4/+9
| | | | | | | | | | mp.set_osd_ass() (which was undocumented, or in other words, was not supposed to be used by external scripts) used to do change detection in the mpv C code. If the resolution or payload did not change, it was not re-rendered on the lower levels. Apparently this made some people sad, so fix it. (But only after I told them to fuck off.) (Well I didn't put it this way, but still.)
* zimg: remove C11 aligned_alloc() requirementwm42020-05-013-11/+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)
* stream_libarchive: remember archive headers from initial openKevin Mitchell2020-04-283-18/+51
| | | | | | | | | | | | | | | | | | The header probing hacks were previously all broken. They only worked the first time the archive file was open. Since subsequent opens (on seek) occured in the middle of the source stream rather than at the beginning, the stream_read_peek calls meant to retrieve the headers were instead returning random bytes in the middle of the file. Perhaps the worst manifestation of this was when seeking within a multi-volume .rar archive with the "legacy" file naming pattern. If the seek required a reopen, the fact that the archive was multi-volume would be forgotten and the file would appear truncated terminating playback. To solve this, only perform the header probling the first time the archive is opened. Save the results and reuse them on subsequent reopens. Put this in a wrapper so this is transparent to demux_libarchive.
* stream_libarchive: simplify multi-volume rar hate messageKevin Mitchell2020-04-271-14/+8
| | | | | | | | I couldn't find any reason for this message to be so far dispalced from where it's necessity was determined. That necessity is not however in question. Also improve the wording and line breaking.
* stream_libarchive: put multi_rar check in a functionKevin Mitchell2020-04-271-10/+14
|
* ta: add ta_get_parent()wm42020-04-262-1/+12
| | | | Sometimes useful for debugging. Also fix a random typo elsewhere.
* ta: change debug ifdefferywm42020-04-261-4/+8
| | | | | TA_MEMORY_DEBUGGING always defined. But allow defining it from the compiler command line (-D), because maybe that's useful for someone?
* video: make OSD/subtitle bitmaps refcounted (sort of)wm42020-04-2613-110/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
* 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-248-4/+42
| | | | | | | | | 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.
* win32: SGR emulation: minor fixup on invalid sequenceAvi Halachmi (:avih)2020-04-241-2/+5
| | | | | | | | This fixes two issues with invalid value after 38/48: - It was not detected correctly and ended up skipping 4 instead of 0. - The intent was to skip 0, but it's better to skip the rest. Behavior with valid 2/5 after 38/48 was correct and is unaffected.
* 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.
* osdep/terminal-win: native VT: report exact widthAvi Halachmi (:avih)2020-04-231-2/+3
| | | | | The narrower-by-1 width is not required with a native VT console because the wrapping behavior is the same as on *nix on such case.
* 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.
* win32: native VT: logic fixupAvi Halachmi (:avih)2020-04-231-2/+2
| | | | | We want basemode unmodified so that we can use it if setting VT mode fails.
* stats.lua: don't disable terminal escape sequences on windowsAvi Halachmi (:avih)2020-04-231-22/+4
| | | | | | | | | | | | | | | | | | | | | When stats.lua is used without a video window then it uses the terminal. On Windows, however, so far it disabled ansi escape sequences and used plaintext unless ANSICON env is set. It's unclear why it's disabled on windows, because at the time it was added it only used bold by default and mpv ansi emulat