summaryrefslogtreecommitdiffstats
path: root/video
Commit message (Collapse)AuthorAgeFilesLines
* 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
* img_format: remove some unused format flagswm42019-11-032-25/+2
| | | | | | | | | | | | | | | | | They were used at some point, but then fell into disuse. In general, these old flags are all a bit fuzzy, so it's a good idea to remove them as much as possible. The comment about MP_IMGFLAG_PAL isn't true anymore. The old meaning was deprecated at some point, and the flag was removed from "pseudo paletted" formats. I think mpv at one point changed its own flag from AV_PIX_FMT_FLAG_PSEUDOPAL to AV_PIX_FMT_FLAG_PAL, when the former was deprecated, and it became unnecessary to allocate a palette for non-paletted formats. (The one who deprecated in FFmpeg was me, if you wonder.) MP_IMGFLAG_PLANAR was used in command.c, use a relatively similar flag as replacement.
* 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.
* sws_utils: remove some unnecessary sws bug work aroundwm42019-11-031-11/+0
| | | | | Seems like this was needed in 2012. The comment indicates the bug was fixed in ffmpeg git, so it's long gone.
* vd_lavc: don't keep packets for fallbacks if errors are toleratedwm42019-11-021-1/+3
| | | | | | | | | | | | | | The user can raise the number of tolerated hardware decoding errors. On the other hand, we have a static limit on packets that are "saved" for fallback handling (and that's a good idea to avoid unbounded memory usage). In this case, it could happen that the start of a file was fine after a fallback, but after that buffered amount of data, it would suddenly skip. It's more useful to skip buffering entirely if the number of tolerated decoding errors exceeds the fixed buffer. (And also, I'm sure nobody gives a shit about this feature.)
* vd_lavc: fix prepare_decoding() failure modeswm42019-11-021-9/+14
| | | | | | | | | | | | prepare_decoding() returned a bool that was supposed to tell whether decoding could work, or if something was fucked. After recent changes to the decoder loop, this did not work anymore, and caused an endless loop. Redo it, so it makes more sense. avctx being NULL (software fallback initialization failed) now signals EOF. hwdec_failed needs to be handled on send_packet() only, where it probably never happens anyway. (Who was the idiot who made libavcodec have two entrypoints for decoding? Oh right, it was me. PEBKAC.)
* vd_lavc: mention hw decoding if decoding fails in hwdec modewm42019-11-021-1/+2
| | | | Just so the user knows. Provides some context.
* vd_lavc: simplify fallback handling for full stream hw decoderwm42019-11-021-20/+18
| | | | | | | | | | | | Shovel the code around to make the data flow slightly simpler (?). At least there's only one send_packet function now. The old code had the problem that send_packet() could be called even if there were queued packets; due to sending the queued packets in the receive_frame function, this should not happen anymore (the code checking for this case in send_packet should normally never be called). Untested with actual full stream hw decoders (none available here); I created a test case by making hwaccel decoding fail.
* vd_lavc: signal packet consumed in drop-all casewm42019-11-021-1/+1
| | | | | This is just a very special code path. This probably got stuck, now that the previous commit returned the EAGAIN properly. Untested.
* vd_lavc: change incorrect bool return type to intwm42019-11-021-1/+1
| | | | | | | | Forgotten in commit 5d5fdb7. This failed to return the error code properly. In particular, if the decoder rejected the packet, this was not properly detected. Normally, this mattered only in specific cases. Fixes: #7115
* zimg: support subsampled chroma with non-aligned image sizeswm42019-11-021-2/+9
|
* zinmg: stop using GBRP for RGBwm42019-11-021-23/+28
| | | | | | | | | | | | | | | Instead, use a YUV planar format. It doesn't matter, since we use the format only internally and for "management" purposes. We're only interested in the physical layout, not what colorspace FFmpeg "forcibly" associates with it. Also get rid of using the old and slightly sketchy mp_imgfmt_find() function. Yep, the IMGFMT_RGB30 now "constructs" the planar format, instead of using a pixfmt constant. Slightly inconvenient, tricky, and fragile, but I like it, so bugger off. This whole thing gets rid of some of the strange plane permutations that were needed earlier.
* zimg: correct RGB30 order (probably)wm42019-11-021-1/+1
| | | | | | | | According to the definition of the GL format, and the definition in img_format.h, and the actual output by vo_gpu, the order of components was probably wrong. It's exceedingly likely that the vo_drm format (for which this was originally written) has the same layout, so this was probably a bug from when the zimg wrapper code was refactored.
* video: mess with the filte chain to enable zimg IMGFMT_RGB30 outputwm42019-11-021-0/+1
| | | | | | | | | | | This was too hardcoded to libswscale. In particular, IMGFMT_RGB30 output is only possible with the zimg wrapper, so the context needs to be taken into account (since this depends on the --sws-allow-zimg option dynamically). This is still slightly risky, because zimg currently will still fall back to swscale in some cases, such as when it refuses to initialize the particular color conversion that is requested. f_autoconvert.c could actually handle this better, but I'm tool fucking lazy right now, and nobody cares anyway, so go away, OK?
* 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.
* zimg: make --zimg-fast=yes defaultwm42019-11-021-0/+1
| | | | | | 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.
* 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.
* 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.
* sws_utils, zimg: destroy vo_x11 and vo_drm performancewm42019-10-315-41/+72
| | | | | | | | | | | | | | | | | | | | | | | | | 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-314-7/+19
| | | | | | | | | | 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-318-31/+63
| | | | | | | | | | | 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-312-8/+6
|
* 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?
* 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-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.)
* 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.
* 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
* ad_lavc, vd_lavc: return full error codes to shared decoder loopwm42019-10-241-28/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ad_lavc and vd_lavc use the lavc_process() helper to translate the FFmpeg push/pull API to the internal filter API (which completely mismatch, even though I'm responsible for both, just fucking kill me). This interface was "slightly" too tight. It returned only a bool indicating "progress", which was not enough to handle some cases (see following commit). While we're at it, move all state into a struct. This is only a single bool, but we get the chance to add more if needed. This fixes mpv falling asleep if decoding returns an error during draining. If decoding fails when we already sent EOF, the state machine stopped making progress. This left mpv just sitting around and doing nothing. A test case can be created with: echo $RANDOM >> image.png This makes libavformat read a proper packet plus a packet of garbage. libavcodec will decode a frame, and then return an error code. The lavc_process() wrapper could not deal with this, because there was no way to differentiate between "retry" and "send new packet". Normally, it would send a new packet, so decoding would make progress anyway. If there was "progress", we couldn't just retry, because it'd retry forever. This is made worse by the fact that it tries to decode at least two frames before starting display, meaning it will "sit around and do nothing" before the picture is displayed. Change it so that on error return, "receiving" a frame is retried. This will make it return the EOF, so everything works properly. This is a high-risk change, because all these funny bullshit exceptions for hardware decoding are in the way, and I didn't retest them. For example, if hardware decoding is enabled, it keeps a list of packets, that are fed into the decoder again if hardware decoding fails, and a software fallback is performed. Another case of horrifying accidental complexity. Fixes: #6618
* 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-22