summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* ass_mp: reset packer when allocation failsDan Elkouby2019-11-021-1/+3
| | | | | | | | | Sometimes the atlas can get so large that it exceeds the maximum allowed size for an mp_image. Since the atlas will never shrink naturally, this breaks subtitles entirely until mpv is restarted. Reset the packer so that subtitles can rendered properly once the atlas fits again. This is a partial workaround for #6286.
* manpage: update --framedrop optionwm42019-11-021-10/+26
| | | | | | | | | | | | | The statement about the display FPS is outdated by several years. "audio"-sync mode does not use the display FPS anymore, and that it's X11 only also isn't true anymore. These modes have separate implementations for audio and display video sync. modes, so the explanations are separate. Why the hell are users playing around with this anyway? The explanations are probably too special to make sense for anyone who doesn't know the code (and who knows the code doesn't need them anyway), but whatever.
* zimg: make --zimg-fast=yes defaultwm42019-11-023-2/+2
| | | | | | This is mostly just because of the odd RGB default gamma issue, which shouldn't have any real impact. This also sets allow_approximate_gamma, which I hope is fine for normal use cases.
* zimg: pass through Y plane when repacking nv12wm42019-11-021-31/+38
| | | | | | | | | | | | | | | Normally, the Y plane can just be passed directly to zimg, and only the chroma plane needs to be (de)interleaved. It still needs a copy if the Y pointer is not aligned, though. (Whether this is actually a problem depends on the CPU and probably zimg's compiler.) This requires deciding per plane whether the plane should go through the repack buffer or not. This logic is active in non-nv12 cases, because not doing so would require extra code (maybe 2 lines or so). repack_align is now always called, even if it's planar->planar with all input aligned, but it won't actually do anything in that case. The assumption is that zimg won't change behavior if you pass a callback that does nothing versus passing NULL as callback.
* zimg: add semi-planar repackerwm42019-11-021-1/+123
| | | | | | | | | | | | | | | | This is for formats like nv12 (including p010, nv24, etc.). Might be important for hardware decoding. Previously, this would have forced a libswscale fallback. The genericism makes this only slightly more complicated. The main complication is due to the fact that mixing planar and packed stuff is insane (thanks, Nvidia). P010 output will actually happily set any of the 6 bit "padding" LSB, that are normally supposed to be 0 (for unpadded data there is P016). Scaling happens with 16 bit precision. Not going to bother adding an extra packer which zeros them out, or with shifting them in packing/unpacking. Lets just hope nobody notices.
* img_format: add function to find image format by layoutwm42019-11-022-0/+36
| | | | | | This is similar to mp_imgfmt_find(), but probably a bit saner. Used by the next commit. The previous commit is required to map this unambiguously between all formats.
* img_format: add mp_regular_imgfmt.forced_csp fieldwm42019-11-022-0/+7
| | | | | | As the code comment says, this is needed to disambiguate FFmpeg formats. This struct only describes the "physical" layout of a format, while FFmpeg also attaches part of the colorspace information to the format.
* img_format: add more explanations to component_pad fieldwm42019-11-021-0/+5
| | | | | Weird shit. I thought this was a clever way to elegantly handle two cases at once, but maybe it's just confusing.
* zimg: fix out of bounds memory accesses due to broken zmaskwm42019-11-021-39/+37
| | | | | | | | | We've set all planes to the same zmask. But for subsampled chroma, the zmask obviously needs to be smaller. This could lead to out of bounds memory read and write accesses. Move the align repacker to a single function, since this is now more convenient.
* github: we want a -v -v log nowwm42019-11-011-1/+1
| | | | | --log-file uses debug log level by default. On command line, -v -v will use debug log level.
* f_decoder_wrapper: reduce uninit message log levelwm42019-11-011-1/+1
| | | | For vd/ad.
* client API: reduce log level of client exitingwm42019-11-011-1/+1
| | | | See previous commit message.
* demux: reduce log level for cache index resizingwm42019-11-011-2/+2
| | | | Now that I probably removed all bugs in this (?), this is uninteresting.
* lua: change config file loggingwm42019-11-011-2/+3
| | | | | | | | Make the existing "not found" messages debug only, and add a new verbose message if a config file was opened. The idea is that logging should make it apparent whether or not config files are loaded, and it's more common to use scripts without config files, leading to fewer log messages in verbose mode.
* 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.
* demux_mkv: reduce log level of mkvinfo part to debugwm42019-11-011-61/+58
| | | | | | demux_mkv has lots of logging that shows information about the file. It sort of reminds of mkvinfo output. While this is sometimes interesting, it's too much for verbose mode, and should be in debug log level.
* m_config: log applying profileswm42019-11-011-0/+1
|
* m_config: raise log level of setting options to verbosewm42019-11-011-2/+2
| | | | | | | | In 2017, we lowered this to debug level. But I think setting options is important enough that it should be logged even in verbose, at least compared to all the other dumb noise. This might be reduced again if verbose logging becomes much cleaner.
* zimg: add more packers/unpackerswm42019-10-311-59/+106
| | | | | | | | This probably covers all packed formats which have byte-aligned component, no alpha, and no subsampling. Everything else needs more imgfmt metadata, or something even more complicated. Alpha is primarily not supported, because zimg requires a second scaler instance for it, and handling packing/unpacking with it is an unacceptable mess.
* m_option: remove an unused functionwm42019-10-312-12/+0
| | | | I think the last real use of this went away in 2014 or so.
* options: make --show-profile without parameters list all profileswm42019-10-313-9/+17
|
* manpage: fix another typowm42019-10-311-1/+1
|
* manpage: update --zimg-scaler defaultwm42019-10-311-3/+3
| | | | Forgotten in previous commit.
* sws_utils, zimg: destroy vo_x11 and vo_drm performancewm42019-10-319-44/+133
| | | | | | | | | | | | | | | | | | | | | | | | | Raise swscale and zimg default parameters. This restores screenshot quality settings (maybe) unset in the commit before. Also expose some more libswscale and zimg options. Since these options are also used for VOs like x11 and drm, this will make x11/drm/etc. much slower. For compensation, provide a profile that sets the old option values: sw-fast. I'm also enabling zimg here, just as an experiment. The core problem is that we have a single set of command line options which control the settings used for most swscale/zimg uses. This was done in the previous commit. It cannot differentiate between the VOs, which need to be realtime and may accept/require lower quality options, and things like screenshots or vo_image, which can be slower, but should not sacrifice quality by default. Should this have two sets of options or something similar to do the right thing depending on the code which calls libswscale? Maybe. Or should I just ignore the problem, make it someone else's problem (users who want to use software conversion VOs), provide a sub-optimal solution, and call it a day? Definitely, sounds good, pushing to master, goodbye.
* screenshot, vo_image: use global swscale/zimg parameterswm42019-10-316-12/+35
| | | | | | | | | | 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-3111-41/+72
| | | | | | | | | | | 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-313-11/+7
|
* common: add mp_log2()wm42019-10-312-0/+20
| | | | | | | | | | | To be used in the next commit. According to compiler explorer, __builtin_clz is very widely available, and it barely makes sense to provide a fallback. clang also eats this (and identifies at least as GCC 4). Actually, there's doubt that a fast log2 implementation is needed at all (I guess UTF-8 parsing needs it, but something UTF-8-specific would probably make it faster than using log2). So the fallback is just something naive.
* Replace uses of FFMIN/MAX with MPMIN/MAXwm42019-10-3116-78/+66
| | | | And remove libavutil includes where possible.
* stream_memory: remove trivial ffmpeg dependencywm42019-10-311-3/+1
|
* manpage: document stats page 3wm42019-10-311-0/+3
|
* player: simplify --stream-dump codewm42019-10-311-4/+4
| | | | | Not sure why it was so complicated. It avoided allocation data on the stack and copying it twice, but who cares.
* stream: move stream_read_line to demux_playlist.cwm42019-10-313-72/+72
| | | | | demux_playlist.c is the only remaining user of this. Not sure if it should stay this way, but for now I'll say yes.
* stream: stop accessing buffer internals in stream_read_line()wm42019-10-312-8/+16
| | | | | Getting this out of the way in preparation for reworking stream internals.
* interface-changes: fixup the location of d3d11-output-cspJan Ekström2019-10-301-1/+2
| | | | 0.30.0 is already cut, so +1 it is.
* 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-305-5/+198
| | | | | | | | | | | | | | | | 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.
* osc: calculate osc_geo position after aspect correctionJan Janssen2019-10-291-6/+8
| | | Fixes #7098
* vo_caca: Implement VOCTRL_UPDATE_WINDOW_TITLECameron Cawley2019-10-291-2/+4
|
* osc: Unify bottom and topbar codeJan Janssen2019-10-282-181/+33
| | | | | | Among the pointless duplication the right timecode label was given some extra space that wasn't needed. Fixes: #6904
* manpage: Update information about default mouse bindingsCameron Cawley2019-10-281-3/+12
|
* vo_sdl: Acknowledge when the mouse enters or leaves the windowCameron Cawley2019-10-281-0/+6
|
* input: Add default bindings for MBTN_BACK and MBTN_FORWARDCameron Cawley2019-10-281-0/+2
|
* 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
|
* DOCS/release-policy.md: clarify a few detailssfan52019-10-271-3/+7
|
* 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?
* mp_image: copy closed captions when copying attributeswm42019-10-251-0/+1
| | | | | | | | | | With hwdec copy modes, mp_image_copy_attributes() is used to transfer metadata other than the image data when copying the image from the hardware surface. It didn't copy the closed caption data. Fix this. This makes closed captions in copy mode work. Fixes: #6376
* mp_image: move buffer ref assigning to a functionwm42019-10-251-7/+10
| | | | | | | Mostly untested, for the next commit. There's another case of this in this file (ref_buffer()), but it's too weird, so ignore it.
* sdl: prevent concurrent use of SDL in different threadswm42019-10-252-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | 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
* build: make vo_sdl conflict with cocoawm42019-10-251-0/+1
| | | | | | | | | | These are inherently incompatible. As far as I'm aware, SDL must be used from the main thread on OSX. (Technically, this condition is wrong: the problem happens on OSX in general, or more precisely, when SDL uses Cocoa. I didn't find the waf OSX dependency name after 5 second of searching, so I'm just using cocoa, without which mpv is useless on OSX anyway.)
* 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.)
* input: disable gamepad code by defaultwm42019-10-253-5/+1
| | | | | | | Enabling this by default probably causes a number of issues, such as breaking vo_sdl, or reacting to various input devices while the window is not focused. It's also pretty obscure, or at least new. Disable it by default.
* f_decoder_wapper: trust frame return over error codewm42019-10-251-5/+5
| | | | | | | | | | | | | | | | | lavc_process() calls the receive/send callbacks, which mirror libavcodec's send/receive API. The receive API in particular can return both a status code and a frame. Normally, libavcodec is pretty explicit that it can't return both a frame and an error. But the receive callback does more stuff in addition (vd_lavc does hardware decoding fallbacks etc.). The previous commit shows an instance where this happened, and where it leaked a frame in this case. For robustness, check whether the frame is set first, i.e. trust it over the status code. Before this, it checked for an EOF status first. Hopefully is of no consequence otherwise. I made this change after testing everything (can someone implement a test suite which tests this exhaustively).
* vd_lavc: fix draining with hwdec copy modeswm42019-10-251-4/+4
| | | | | | | | | | | | | | | | | | | | | | Commit 5d5fdb77e99 changed details of the decoding control flow, and called it a "high-risk" change. It turns out that this broke with with hwdec copy mode, where there is some sort of delay queue (supposedly increases efficiency, but more likely worthless cargo-cult). It simply used the wrong (basically inverted) condition for the draining case. This was the only case that did not work properly. Other tests, including video/audio decoding errors, software decoding fallbacks, etc., seemed to work well. Might still not be exhaustive, as there are so many corner cases. Also change two error code returns. This don't/shouldn't really matter, though the second error code led it to return both a frame and AVERROR_EOF, which is unexpected, and makes lavc_process() leak a frame. But also see next commit. Fixes: 5d5fdb77e99
* 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.
* Update VERSIONsfan52019-10-251-1/+1
|
* Merge branch 'release/0.30'sfan52019-10-252-135/+77
|\
| * Release 0.30.0v0.30.0release/0.30sfan52019-10-252-135/+77
| |
| * manpage: fix --script docswm42019-10-251-3/+3
| | | | | | | | | | | | | | | | This doesn't take a ',' separated list. --script is just an alias for --scripts--append. --s