summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* vo_gpu: replace --icc-contrast by --icc-force-contrastNiklas Haas2021-05-263-49/+52
| | | | | | | | | | | | | | Not only does this have semantics that make far more sense, it also has a default that makes far more sense. (Equivalent to the old `icc-contrast=inf`) This removes the weird 1000:1 contrast default assumption which especially broke perceptual profiles and also screws things up for OLED/CRT/etc. Should probably close some issues but I honestly can't be bothered to figure out which of the thousands colorimetry-related issues are affected.
* wayland: shuffle around the render loop againDudemanguy2021-05-245-35/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Take two. f4e89dd went wrong by moving vo_wayland_wait_frame before start_frame was called. Whether or not this matters depends on the compositor, but some weird things can happen. Basically, it's a scheduling issue. vo_wayland_wait_frame queues all events and sends them to the server to process (with no blocking if presentation time is available). If mpv changes state while rendering (and this function is called before every frame is drawn), then that event also gets dispatched and sent to the compositor. This, in some cases, can cause some funny behavior because the next frame gets attached to the surface while the old buffer is getting released. It's safer to call this function after the swap already happens and well before mpv calls its next draw. There's no weird scheduling of events, and the compositor log is more normal. The second part of this is to fix some stuttering issues. This is mostly just conjecture, but probably what was happening was this thing called "composition". The easiest way to see this is to play a video on the default audio sync mode (probably easiest to see on a typical 23.976 video). Have that in a window and float it over firefox (floating windows are bloat on a tiling wm anyway). Then in firefox, do some short bursts of smooth scrolling (likely uses egl). Some stutter in video rendering could be observed, particularly in panning shots. Compositors are supposed to prevent tearing so what likely was happening was that the compositor was simply holding the buffer a wee bit longer to make sure it happened in sync with the smooth scrolling. Because the mpv code waits precisely on presentation time, the loop would timeout on occasion instead of receiving the frame callback. This would then lead to a skipped frame when rendering and thus causing stuttering. The fix is simple: just only count consecutive timeouts as not receiving frame callback. If a compositor holds the mpv buffer slightly longer to avoid tearing, then we will definitely receive frame callback on the next round of the render loop. This logic also appears to be sound for plasma (funfact: Plasma always returns frame callback even when the window is hidden. Not sure what's up with that, but luckily it doesn't matter to us.), so get rid of the goofy 1/vblank_time thing and just keep it a simple > 1 check.
* wayland: send VO_EVENT_DPI on output event as wellDudemanguy2021-05-231-0/+1
| | | | The display scaling might change here, so we need to signal mpv's core.
* command: add a missing comma to MP_EVENT_WIN_STATEDudemanguy2021-05-231-1/+1
| | | | In my defense, it still compiled.
* vo_gpu: fix extreme clipping with --gamut-clipping for HDR outputsNiklas Haas2021-05-221-1/+2
| | | | | | Checking against 1.0 is wrong for this code, because it's in an absolute luminance scale relative to reference white. We should be normalizing this by `dst.sig_peak`.
* wayland: simplify render loopDudemanguy2021-05-225-49/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is actually a very nice simplification that should have been thought of years ago (sue me). In a nutshell, the story with the wayland code is that the frame callback and swap buffer behavior doesn't fit very well with mpv's rendering loop. It's been refactored/changed quite a few times over the years and works well enough but things could be better. The current iteration works with an external swapchain to check if we have frame callback before deciding whether or not to render. This logic was implemented in both egl and vulkan. This does have its warts however. There's some hidden state detection logic which works but is kind of ugly. Since wayland doesn't allow clients to know if they are actually visible (questionable but whatever), you can just reasonably assume that if a bunch of callbacks are missed in a row, you're probably not visible. That's fine, but it is indeed less than ideal since the threshold is basically entirely arbitrary and mpv does do a few wasteful renders before it decides that the window is actually hidden. The biggest urk in the vo_wayland_wait_frame is the use of wl_display_roundtrip. Wayland developers would probably be offended by the way mpv abuses that function, but essentially it was a way to have semi-blocking behavior needed for display-resample to work. Since the swap interval must be 0 on wayland (otherwise it will block the entire player's rendering loop), we need some other way to wait on vsync. The idea here was to dispatch and poll a bunch of wayland events, wait (with a timeout) until we get frame callback, and then wait for the compositor to process it. That pretty much perfectly waits on vsync and lets us keep all the good timings and all that jazz that we want for mpv. The problem is that wl_display_roundtrip is conceptually a bad function. It can internally call wl_display_dispatch which in certain instances, empty event queue, will block forever. Now strictly speaking, this probably will never, ever happen (once I was able to to trigger it by hardcoding an error into a compositor), but ideally vo_wayland_wait_frame should never infinitely block and stall the player. Unfortunately, removing that function always lead to problems with timings and unsteady vsync intervals so it survived many refactors. Until now, of course. In wayland, the ideal is to never do wasteful rendering (i.e. don't render if the window isn't visible). Instead of wrestling around with hidden states and possible missed vblanks, let's rearrange the wayland rendering logic so we only ever draw a frame when the frame callback is returned to use (within a reasonable timeout to avoid blocking forever). This slight rearrangement of the wait allows for several simplifications to be made. Namely, wl_display_roundtrip stops being needed. Instead, we can rely entirely on totally nonblocking calls (dispatch_pending, flush, and so on). We still need to poll the fd here to actually get the frame callback event from the compositor, but there's no longer any reason to do extra waiting. As soon as we get the callback, we immediately draw. This works quite well and has stable vsync (display-resample and audio). Additionally, all of the logic about hidden states is no longer needed. If vo_wayland_wait_frame times out, it's okay to assume immediately that the window is not visible and skip rendering. Unfortunately, there's one limitation on this new approach. It will only work correctly if the compositor implements presentation time. That means a reduced version of the old way still has to be carried around in vo_wayland_wait_frame. So if the compositor has no presentation time, then we are forced to use wl_display_roundtrip and juggle some funny assumptions about whether or not the window is hidden or not. Plasma is the only real notable compositor without presentation time at this stage so perhaps this "legacy" mechanism could be removed in the future.
* player/command: add secondary-sub-text propertyZsolt Vadasz2021-05-192-5/+22
|
* sub/osd: hide secondary subtitles if secondary-sub-visibility is falseZsolt Vadasz2021-05-197-2/+17
|
* vo_gpu: hwdec_vaapi: silence errors while probingNiklas Haas2021-05-194-4/+7
| | | | | Silences warnings related to DRM format modifiers that can show up while probing formats.
* stream_lavf: remove uninitialized http_like arrayDudemanguy2021-05-181-4/+2
| | | | | Serves no purpose and can be a fatal error on certain compiler settings. Just move the other http_like up here instead.
* osxbundle: fix slow and wasteful memory allocationder richter2021-05-161-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | when using the bundle with activated big enough cache, very slow and wasteful memory allocations lead to jittery playback and lot of dropped frames. the cache had to have a certain size so it would constantly allocate new memory to reproduce this. this never happens when started from the terminal. the source of the problem is a different malloc allocation policy, MALLOC_NANO, that allocated a huge amount of virtual memory without actually using it. the usage was between 0% to 25% of that virtual memory. the binaries allocation policy on the other hand used >80% of that allocated virtual memory and was a lot more efficient, it would use MALLOC_TINY instead. this is fixed by setting the MallocNanoZone environment variable to 0 to use the V1 of the allocation policy. when started from the bundle via launchd this is forced to 1 and V2 policy which causes this problem. some more info can be found in following file and its comments on the Apple open source site: https://opensource.apple.com/source/libmalloc/libmalloc-317.40.8/src/nano_malloc_common.c.auto.html Fixes #7405
* stream_file: disable read ahead for remote files on macOSder richter2021-05-161-1/+8
| | | | | | | | | this can cause stutter on remote files because in certain cases this causes a reconnect to the remote that leads to the file not being read fast enough. VLC had the same problem and fixes it the same way. https://github.com/videolan/vlc/commit/b8b8c438f8f65a93da82364c8fea1dbf987c4a8e Fixes #4434
* build: move mingw jobs to Github actionssfan52021-05-162-21/+41
|
* build: move website rebuild into Linux/clang travis jobsfan52021-05-161-1/+1
| | | | The mingw ones will be removed in the next commit.
* options: add some entries to --display-tags defaultsYour Name2021-05-111-0/+1
| | | | Useful for the previous commit.
* ytdl_hook: expose some JSON fields as tagsYour Name2021-05-111-0/+29
| | | | | | | | | | Shows uploader, channel, description fields. This works only if the media media is constructed as EDL (for youtube it usually does this), and if the all_formats option is not set to true (does anyone even use it?). The former usually happens because youtube serves audio and video separately, though it will not for live HLS/DASH. The latter uses delayed media opening, which breaks the global_tags mechanism (see previous commit).
* edl: add a way to add tagsYour Name2021-05-112-1/+36
| | | | | | | | Add new header which shows up as tags/metadata (associated with --display-tags). The way this is added means it doesn't always work, because root->meta (see code) can be NULL for some absurd reason. But it works for the one case I intended to use it (ytdl_hook, see next commit), though only in default configurations.
* zsh completion: perform globbing on binary pathNiklas Haas2021-05-071-4/+4
| | | | | | | | | | | When trying to use completion for mpv binaries specified with some shell glob, e.g. ~/dev/mpv/build/mpv, the current code doesn't substitute the homedir prefix into the path name, resulting in runtime errors about the file '~/dev/mpv/build/mpv' not being found. The simple fixed is to use $~var instead of $var whenever expanding the filename, which performs the same globbing that would otherwise be performed when executing the command.
* vo_gpu: fix trivial memory leakYour Name2021-05-071-1/+3
| | | | Nobody noticed this? Seriously?
* Revert "vo_gpu: revert 8a09299 and conditionally clear framebuffer again"Your Name2021-05-071-5/+3
| | | | | | | | | | This reverts commit b8156a9a86ae4ff087b1b255c68a3ca38ec2d086. Apparently there are two problems here. One on Linux (fixed by the original change and this revert) and one on alternative-medicine-Job's OS. Since the latter has deprecated OpenGL and OpenGL is a second-class citizen, I think it's better to prefer the fix for a platform that is still alive.
* vf_sub: restore OSD if removedYour Name2021-05-071-0/+9
| | | | | | | When inserting vf_sub, the VO OSD is directed not to draw itself. But this flag was never unset, even when removing vf_sub. The fix is pretty shit, but appears to work.
* options: extend --replaygain-preamp rangeYour Name2021-05-071-1/+1
| | | | Whether that makes sense or not.
* audio: fix replaygain being completely brokenYour Name2021-05-071-0/+1
| | | | | | | | | | | | | | | | | | Switching to a new file while keeping the AO didn't update the volume. While there's an explicit audio_update_volume() call in reinit_audio_chain_src(), it doesn't work, because at that point ao_chain->ao is still NULL, and it does nothing. That's pretty weird and might cause other problems (what happens if you try to mute while the AO is "floating"?). Regarding gapless, trying to use the AO gain for replaygain is also gross nonsense, because the new replaygain computed gain would affect audio from the previous file. It looks like replaygain should be in an af_volume filter maybe. On the other hand, I enjoy setting ridiculous replaygain-preamp values and compensating with a low volume setting, which would not work well if both gains were applied to the audio independently. For now, just add the missing call. This is orthogonal to fixing replaygain "properly".
* Revert "audio: set audio chain ao on reinit"Your Name2021-05-071-3/+1
| | | | | | | | | | | | This reverts commit 3239e41277173bace5ecc2a22910c4660642429c. I'm fairly sure this is wrong, and my next commit should fix it properly. I'm not really sure, though. Normally, the AO is set again by reinit_audio_filters_and_output() after the new audio chain has decoded a frame and knows the new format. The reason replaygain (and apparently the thing the reverted commit tried to fix) didn't work is because they work asynchronously to the audio played by the AO (i.e. buggy and hard to fix).
* mac: add support for display-width/display-height propertyder richter2021-05-061-13/+20
| | | | | also merge back a helper function that was introduced in commit d3b7732 and for the purpose to be used with the new display res voctrl event.
* command: add display-width/display-height propertyDudemanguy2021-05-069-1/+60
| | | | | | | | | For some reason, this never existed before. Add VOCTRL_GET_DISPLAY_RES and use it to obtain the current display's resolution from each vo/windowing backend if applicable. Users can then access the current display resolution as display-width and display-height as per the client api. Note that macOS/cocoa was not attempted in this commit since the author has no clue how to write swift.
* DOCS/input.rst: clarify --no-input-default-keybindings docsAvi Halachmi (:avih)2021-05-041-1/+4
| | | | | | | | | | | | | | This commit describes more accurately what currently gets disabled by this option - specifically also keys from mp.add_key_binding. It's not necessarily the best behavior because libmpv clients might want to disable mpv's own builtin keybindings while still allowing scripts to define keys which `input.conf' can override. In the future we might exclude mp.add_key_binding from this option, but for now at least document this option accurately. Fixes #8809
* filter_kernels: fix quadric windowNiklas Haas2021-05-041-1/+1
| | | | | | | | | 3909e4cdfcb9 seems to have replaced this 0.5 constant by 0.75, using its presence in glumpy as justification. 0.75 is clearly a bug in glumpy, as its own source code doesn't even match the comment immediately above it. Every other implementation of this window I could find uses 0.5, including e.g. ImageMagick.
* DOCS/lua.rst: fix docs for utils.file_infoAvi Halachmi (:avih)2021-05-031-1/+1
| | | | | | | | | | | | | | The ctime member on Windows uses FILE_BASIC_INFO.ChangeTime, which is pretty much the same as st_ctime on POSIX. See https://devblogs.microsoft.com/oldnewthing/20100709-00/?p=13463 : ... The Last­Write­Time covers writes to the file’s data stream (which you accomplish via the Write­File function). On the other hand, the Change­Time also includes changes to the file metadata, such as changing its file attributes ... Fixes #8801
* build: address AVCodec, AVInputFormat, AVOutputFormat const warningssfan52021-05-0110-17/+17
| | | | FFmpeg recently changed these to be const on their side.
* scripting (lua/js): utils.getpid: make wrapper of pid propertyAvi Halachmi (:avih)2021-05-014-16/+5
| | | | | | | | | We now have at least 3 scripting APIs which are trivial wrappers around properties: mp.get_mouse_pos, utils.getcwd, utils.getpid. After some discussion on IRC it was decided that it's easier for us to maintain them as trivial wrappers than to deprecate them and inflict pain on users and script authors, so currently no plan to deprecate.
* command: new property: pid (process id)Avi Halachmi (:avih)2021-05-012-0/+12
| | | | Fixes #7562
* DOCS: clarify how client/script names workDudemanguy2021-04-292-4/+12
| | | | | This isn't really clearly stated anywhere and could understandably lead to some confusion.
* command: osd-dimensions: return ints and doc fixesDudemanguy2021-04-292-8/+8
| | | | | | Some subproperties in osd-dimensions were returned as doubles despite actually being integers. Additionally, correct a highly misleading line in the osd-width/osd-height documentation.
* audio: add two minor log messagessfan52021-04-291-2/+6
| | | | | This would have made the problem fixed in the previous commit a bit more obvious from the log output.
* ao/pulse: fix incorrect state reported after resetsfan52021-04-291-0/+1
| | | | fixes #8768
* osc: reset margins when using boxvideo with showfullscreen/showwindowedossifrage2021-04-271-1/+11
| | | | | | | | | | | | | | | | | | | This fixes a bug where using boxvideo with showfullscreen=no or showwindowed=no resulted in the margins not resetting when the OSC wasn't visible. For example, using: script-opts=osc-visibility=always,osc-boxvideo=yes,osc-showfullscreen=no and then going fullscreen would make the OSC disappear but the video margins would remain. This is because boxvideo was missing a dependence on the showfullscreen and showwindowed user options. This is fixed by adding the corresponding conditions to update_margins() and setting state.marginsREQ on fullscreen changes. update_margins() is called on tick() if there's a margins update pending, which guarantees the boxvideo margins are reset appropriately.
* wayland: ignore toplevel listener if geometry is 0Dudemanguy2021-04-261-0/+4
| | | | | | | | | | It turns out that if a user specifies fullscreen=yes and a width/height in an autoprofile, the compositor can execute its toplevel listener event. This can happen before we have any mpv window rendered at all so we end up performing a bunch of geometry operations and state checks when we shouldn't. It subtly messes up a lot of things like state detection. Just return from this function if the geometry has no width or height yet.
* osc: display immediately when visibility changes from never to alwaysossifrage2021-04-251-1/+2
| | | | | | | | | | | | | | | | | | | | | | Clearing state.osd.data with an empty string at render_wipe() fixes an issue where changing the OSC visibility from "never" directly to "always" didn't immediately update the display when the player was paused. This could be verified by starting the player with `--script-opts=osc-visibility=always --pause` and then running `script-message osc-visibility never` followed by `script-message osc-visibility always`. Removing the overlay without changing the contents meant the overlay wouldn't update and display when enabled again until the fields changed in some way (e.g. seeking, mousing over the OSC area, etc.). Clearing state.osd.data before removal of the OSC makes sure set_osd doesn't return on re-enable and instead displays the OSC immediately as the data is now different. render_wipe() is now also used when the OSC needs to be cleared at tick() as using set_osd to clear it with an empty string did not call state.osd:remove() which can allow cleanups related to bitmap memory allocations etc.
* mac: fix window geometry calculation on secondary screensder richter2021-04-241-19/+26
| | | | | | | | | | | | | | | this is a regression of af26402, where we changed the geometry calculation to use the visible frame and consider its origin. though the origin is not screen relative but relative to the main screen. the rest of the code expects a screen relative rectangle. because of that windows would be placed out of the screen bounds when not on the main screen. recalculate to origin to be screen relative and use those values for the rest of the calculations. to make the code a bit more comprehensible be a bit more explicit about what is done where with temporary variables and comments. also move the mp_rect calculation that moves the origin and flips the y position to a separate function, so we can reuse it later.
* stream_file: add new identifier for macOS FUSE filesystemsder richter2021-04-241-1/+1
| | | | | the new identifier for osxfusefs is macfuse, but we will keep both since the older releases are still used.
* DOCS: mpv.rst: minor escaping clarificationsAvi Halachmi (:avih)2021-04-231-1/+4
| | | | Fixes #8767
* win32: fit_window_on_screen: simplify, add commentsAvi Halachmi (:avih)2021-04-231-16/+17
| | | | | | | | | | The fit_on_screen logic was a bit twisted. Simplify it a bit and update few comments to explain better what it's used for. Note that the new logic is not identical to before, but its intent should now be clearer. This means there might be regressions or improvements at edge cases. If followup fixes are needed, then we should keep the intent clear. Most likely though that it's fine.
* win32: fit_window_on_screen: centralize logic (no-op)Avi Halachmi (:avih)2021-04-231-4/+3
| | | | | | | | fit_on_screen is called only from reinit_window_state. Move the yes/no logic unmodified from fit_on_screen to reinit_window_state, and remove the w32->parent condition because it's already checked earlier at reinit_window_state.
* win32: fit_window_on_screen: ensure top edge is insideAvi Halachmi (:avih)2021-04-231-6/+18
| | | | | | | | | | | | | | | | | | | | | Previously, because the video (client area) was centered but the top and bottom borders are uneven (title is taller), then if the window is shrunk vertically to just-fit the desktop - the top edge of the title bar ended above the top edge of the display. This is a state which Windows prevents during manual move, but apparently it's not rejected at the Windows API. Now we ensure it doesn't happen, and nudge the window down to align the top edges if necessary. This is a commulative regression of commits 981048e0 and 364af7c6. To clarify functionality, this includes a no-op change: fit_rect was renamed to fit_rect_size and it now takes explicit width and height, because it only used the width/height of rc2 anyway. Fixes #6695
* options: win32: ignore and deprecate --fit-borderAvi Halachmi (:avih)2021-04-233-8/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The accurate description of this option was: - fit-border is enabled by default. When disabled, it adds a bug where if the window has borders and mpv shrinks it to fit the desktop, then the calculation ignores the borders and adds incorrect video crop. The option was added at commits 70f64f3c and 949247d6, in order to solve an issue (#2935) where if mpv wanted to display a video with size WxH, then w32_common.c incorrectly set the window to WxH, while down-scaling the video slightly to fit (even with small sizes). It was addressed with a new option which is enabled by default, but does the right thing (sets the client area to WxH) only when disabled, so that everyone who prefers their video slightly downscaled could keep their default behavior. (#2935 also addressed an off-by-one issue, fixed before fit-border) While disabling the option did avoid unnecessary downscaling, it also added a bug when disabled: the borders are no longer taken into account when the size is too big for the desktop. Most users don't notice and are unaffected as it's enabled by default. Shortly later (981048e0) the core issue is fixed, and now the client area is correctly set to WxH instead of the window (and together with the three following commits which center the video, adds a new bug where the window title can be outside the display - addressed next). However, fit-border remained, now without any effect, except that it still has the same bug when disabled and the window is too big. Later code changes and refactoring preserved this issue with great attention to details, and it remained in identical form until now. Simply rip out fit-border.
* demux_lavf: fix minor memory leaksrland jon2021-04-201-0/+2
|
* vo_gpu: greatly increase maximum shader cache sizeNiklas Haas2021-04-181-1/+1
| | | | | | | | | | | | | | | | | | | | See #8137 for justification. This is not ideal, because a large cache results in a lot of `strcmp` invo