summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* osc: update chapter marker positions when duration changesHEADmasterSagnac3 days2-1/+35
| | | | | | | | | | | | | | | | | | | | | | | | | | Commit 6abb7e3 updates the markers when the chapters change, but it doesn't update their relative position at the bar when the duration changes. This means that adding chapters to a live stream would result in corresponding chapter markers which were static while the duration changed and thus their positions became incorrect over time until the OSC was reinitialized. This is fixed by observing the duration property if chapters are present and reinitializing the OSC when the duration changes. The live_markers user option, which determines whether the duration property is observed when there are chapters, has been added in order to allow disabling this behaviour as calling request_init() frequently might have some impact on low-end systems. The impact of request_init() on render() was measured to increase from 1-1.5 ms to 2-3 ms on a 2010 MacBook Air, while the impact was neglible on a 2016 Surface Book (increasing only to an average of 1.4 ms from 1.3 ms for n=1500 render cycles). The live_markers option is enabled by default.
* js: add mp.utils.append_fileAvi Halachmi (:avih)5 days3-11/+23
| | | | | Also, for consistency with other APIs, mp.utils.{write,append}_file now return true on success (and still throw on any error).
* vo_gpu: vulkan: displayvk: Fix handling of unconnected planesPhilip Langdale6 days1-1/+6
| | | | | | | | If a plane is not connected to any displays, we won't set an entry in the mapping of planes to displays. So ensure these unset entries are null and skip them. Fixes #8913
* vo_gpu: vulkan: implement a VkDisplayKHR backed contextPhilip Langdale7 days6-0/+425
| | | | | | | | | | | | | | | | | | | | | | | | This is the Vulkan equivalent of the drm context for OpenGL, with the big difference that it's implemented purely in terms of Vulkan calls and doesn't actually require drm or kms. The basic idea is to identify a display, mode, and plane on a device, and then create a display backed surface for the swapchain. In theory, past that point, everything is the same, and this is in fact the case on Intel hardware. I can get a video playing on a vt. On nvidia, naturally, things don't work that way. Instead, nvidia only implemented the extension for scenarios where a VR application is stealing a display from a running window system, and not for standalone scenarios. With additional code, I've got this scenario to work but that's a separate incremental change. Other people have tested on AMD, and report roughly the same behaviour as on Intel. Note, that in this change, the VT will not be correctly restored after qutting. The only way to restore the VT is to introduce some drm specific code which I will illustrate in a separate change.
* vo_gpu: vulkan: provide a helper to access device name optionPhilip Langdale7 days2-0/+17
| | | | | | | | | | | The VkDisplayKHR context type requires making calls against the physical device before the libplacebo context is initialised. That means we can't simply use the physical device object that libplacebo would create - instead we have to create a separate one, but make sure it's referring to the same physical device. To that end, we need the device name that the user may have requested so we can pass it on.
* vo_rpi: fix argument nameDudemanguy10 days1-2/+2
| | | | This is data not arg.
* github/issue_template: irc -> IRCJan Ekström10 days1-2/+2
| | | | Requested to be changed while at it.
* {ci,docs,README}: update IRC references to new networkJan Ekström10 days4-6/+6
|
* docs: fix leftover reference to the now defunct --video-sync-adrop-size optionChris Varenhorst2021-06-041-5/+4
|
* ytdl_hook: improve handling of json parsing errorsRetusthese2021-05-291-10/+12
| | | | | | | | | | This moves the JSON parsing above the main youtube-dl error-handling block and integrates parsing errors into that block. Now, if a parsing error occurs, youtube-dl's stderr will be logged as it is with other errors. This also catches errors that cause youtube-dl to output "null", which would previously be mishandled as a parsing error and crash ytdl_hook when it attempted to concatenate the error string from parse_json.
* wayland: refactor dispatching eventsDudemanguy2021-05-281-46/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was originally just a bugfix for a race condition, but the scope expanded a bit. Currently, the wayland code does a prepare_read -> dispatch_pending -> display_flush -> read_events -> dispatch_pending routine that's basically straight from the wayland client API documentation. This essentially just queues up all the wayland events mpv has and dispatches them to the compositor. We do this for blocking purposes on every frame we render. A very similar thing is done for wait_events from the VO. This code can pretty easily be unified and split off into a separate function, vo_wayland_dispatch_events. vo_wayland_wait_frame will call this function in a while loop (which will break either on timeout or if we receive frame callback from the compositor). wait_events needs to just check this in case we get some state change on the wakeup_pipe (i.e. waking up from the paused state). As for the actual bugfix part of this, it's a slight regression from c26d833. The toplevel config event always forced a redraw when a surface became activated again. This is for something like displaying cover art on a music file. If the window was originally out of view and then later brought back into focus, no picture would be rendered (i.e. the window is just black). That's because something like cover art is just 1 frame and the VO stops doing any other additional rendering. If you miss that 1 frame, nothing would show up ever again. The fix in this case is to always just force a redraw when the mpv window comes back into view. Well with the aforementioned commit, we stopped doing wl_display_roundtrip calls on every frame. That means we no longer do roundtrip blocking calls. We just be sure to queue up all of the events we have and then dispatch them. Because wayland is fundamentally an asynchronous protocol, there's no guarantee what order these events would be processed in. This meant that on occasion, a vo_wayland_wait_frame call (this could occur multiple times depending on the exact situation) would occur before the compositor would send back frame callback. That would result in the aforementioned bug of having just a black window. The fix, in this case, is to just do a vo_wayland_wait_frame call directly before we force the VO to do a redraw. Note that merely dispatching events isn't enough because we specifically need to wait for the compositor to give us frame callback before doing a new render. P.S. fix a typo too.
* manpage: mention cover-art-autoGuido Cella2021-05-282-5/+6
| | | | | --cover-art-auto affects rescan-external-files, and --autoload-files affects cover art.
* README: fix link to feature-request issuesGuilherme2021-05-281-1/+1
|
* player: load cover art with the media filenameGuido Cella2021-05-273-19/+28
| | | | Closes #8666.
* win32: support the property 'focused'Avi Halachmi (:avih)2021-05-272-3/+13
| | | | | | | | | | | | | And also change the existing WM_KILLFOCUS handler to return 0 instead of 'break' (which later calls DefWindowProcW), as MSDN says we should do for WM_{KILL,SET}FOCUS. It seems that the 'focused' property is now supported by all main VOs: x11, macOS, wayland, Windows. TCT/sixel/caca probably don't support it, and unknown with SDL. Fixes #8868
* osc: re-initialize when chapter list changesRetusthese2021-05-271-0/+1
| | | | | | | | | | | | When the OSC initializes, it checks whether the current video has chapters, and if it does not, it disables its chapter functionality (chapter buttons are grayed out and unusable, chapter indicators don't show on the seek bar). If another script changed the chapter list after the video has loaded, those changes would be ignored by the OSC until some other event causes it to re-initialize, because it did not observe the chapter list property. This is fixed by adding observation of chapter-list alongside the other properties that trigger re-initialization.
* recorder: fix codec_tag / codec_id confusionTheAMM2021-05-261-2/+2
|
* recorder: clear codec_tag if no target format supportTheAMM2021-05-261-0/+6
| | | | | | | Avoiding blindly copying the codec_tag between different formats allows us to mux packets from, say, mpegts streams to matroska, making the recorder (dump-cache) much more usable as unsupported codec_tags can make the muxer reject the streams.
* af_scaletempo2: use gcc vectors to speed up inner loopNiklas Haas2021-05-262-3/+76
| | | | | | | | | | This brings my scaletempo2 benchmark down from ~22s to ~7s on my machine (-march=native), and down to ~11s with a generic compile. Guarded behind an appropriate #ifdef to avoid being ableist against people who have the clinical need to run obscure platforms. Closes #8848
* 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` invocations for every single shader invocation. But it's way better than resulting in a lot of shader recompilations for every single shader invocation. The only reason I don't want to uncap it altogether is because there are conceivable edge cases in which users load dynamically generated shaders with updated parameters (indeed, I've seen IRC discussions to this effect), and in this case, we don't want to grow the cache infinitely as a result of something like a floating point parameter being continuously updated. (Never mind that this *would* actually trigger worst case behavior for the `strcmp`, since the updated float constant is likely to be near the bottom of the shader body) Whatever. vo_placebo will liberate us all in the end.
* wayland: workaround hidden state detection badnessDudemanguy2021-04-182-2/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The wayland code uses a heuristic to determine whether or not the mpv window is hidden since the xdg-shell protocol does not provide a way for a client to directly know this. We don't render with the frame callback function for various, complicated reasons but the tl;dr is that it doesn't work well with mpv's core (maybe an essay should be written on this one day). Currently, the aforementioned heuristic considers a window hidden if we miss more frames in a row than the display's current refresh rate (completely arbitrary number). However, the wayland protocol does allow for the display's refresh rate to be 0 in certain cases (like a virtual output). This completely wrecks the heuristic and basically causes only every other frame to be rendered (real world example: nested sway sessions). Instead let's slightly redesign this mechanism to be a little smarter. For coming up with the vblank time (to predict when to timeout on the wait function), instead use the vsync interval calculated using presentation time. That is the most accurate measure available. If that number is not available/invalid, then we try to use the vsync interval predicted by the presentation event. If we still don't have that (i.e. no presentation time supported by the compositor), we can instead use the old way of using the expected vsync interval from the display's reported refresh rate. If somehow we still do not have a usable number, then just give up and makeup shit. Note that at this point we could technically ask the vo for the estimated vsync jitter, but that would involve locking/unlocking vo which sounds horrifying. Ideally, you never reach here. See https://github.com/swaywm/wlroots/issues/2566 for the actual target of this fix. wlroots uses presentation time so in practice we are mostly just using that calculated vsync interval number.
* audio: set audio chain ao on reinitDudemanguy2021-04-181-1/+3
| | | | | | | | | Seems to be a slight corner case with the audio API rewrite. When switching from one file to another one, the volume of the ao would never be set because the audio chain's ao wasn't set. This caused a bug with the reset-set-on-file option. The volume/property would be correctly set internally, but the gain was not actually set when the file switched. Fixes #8287.
* wayland: update geometry + cursor on output eventDudemanguy2021-04-161-40/+56
| | | | | | | | | | | | | | | | | | | | The wayland output listener can update whenever something about the output changes (resolution, scale). Currently, the mpv VO updates correctly when the refresh rate changes, but changes of both scale and resolution were not considered. This causes a bug in certain cases like the mouse surface not being shown at certain scale factors due to the cursor scale not being updated correctly. Also autofit type options would not update if the resolution changes. To fix this, we must always reset the window geometry and wl scaling whenever the output event occurs on wl->current_output. There is no way to know precisely what changed from the previous state, so all of the parameters must be reset and then resized. As an aside, this apparently doesn't fix all cursor problem as there's apparently a bug in libwayland-cursor(*). It's still something we should be doing regardless. *: https://gitlab.freedesktop.org/wayland/wayland/-/issues/194
* wayland: support the display-hidpi-scale propertyDudemanguy2021-04-121-0/+8
| | | | | | | | | | | | | | So apparently this property had existed since 2019. Internally, it's used as a part of the console.lua script for scaling. Yours truly somehow didn't bat an eye at the fact that the text in the console was super small (made worse by the fact that xwayland does scale) and just ignored it for all this time. Oh well. To report dpi changes to mpv's core, we need to use VO_EVENT_DPI in a couple of places. One place is, of course, the surface listener if the scale value reported by the wayland server changes. The other place is in the very first reconfig since mpv's core will not find the correct scale value until we actually get a wl_output from the wayland server.
* demux: undeprecate --cache-secssfan52021-04-083-8/+2
| | | | | It serves a purpose and a rework of the cache won't be coming anytime soon. This partially reverts commit 8427292eb7c4074e1205c3d73c53c9e82569325f.
* audio/aframe: reuse data buffer if less than 8 channelssfan52021-04-081-6/+12
| | | | | | | | This fixes audio encoding crashing under ASan. When extended_data != data, FFmpeg copies more pointers from extended_data (= the number of channels) than there really are for non-planar formats (= exactly 1), but that's not our fault. Regardless, this commit makes it work in all common cases.
* stream: turn stream_info.open2's args argument constsfan52021-04-085-5/+5
| | | | So nobody comes up with the "smart" idea to modify those again.
* stream_slice: fix use-after-free if inner stream fails to opensfan52021-04-081-2/+3
| | | | | | The args struct is reused to attempt opening an URL with different stream layers, overwriting args->url not only breaks this but also causes the freed buffer to be used again.
* player/scripting: fix use-after-free when loading script folderssfan52021-04-081-2/+3
|
* stream_mf: set correct stream originsfan52021-04-081-0/+1
| | | | | mf:// reads files from the local filesystem and should be subject to the usual security checks mpv has for such protocols.
* demux_mf: improve format string processingAvi Halachmi (:avih)2021-04-051-2/+37
| | | | | | | | | | | | | | | | | | | | | Before this commit, the user could specify a printf format string which wasn't verified, and could result in: - Undefined behavior due to missing or non-matching arguments. - Buffer overflow due to untested result length. The offending code was added at commit 103a9609 (2002, mplayer svn): git-svn-id: svn://svn.mplayerhq.hu/mplayer/trunk@4566 b3059339-0415-0410-9bf9-f77b7e298cf2 It moved around but was not modified meaningfully until now. Now we reject all conversion specifiers at the format except %% and a simple subset of the valid specifiers. Also, we now use snprintf to avoid buffer overflow. The format string is provided by the user as part of mf:// URI. Report and initial patch by Stefan Schiller. Patch reviewed by @jeeb, @sfan5, Stefan Schiller.
* manpage: fix a typo in the --aid option noteun.def2021-04-051-1/+1
|
* vo_gpu: adjust interpolation_threshold's defaultLaserEyess2021-03-282-7/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When mpv attempts to play a video that is, on average, 60 FPS on a display that is not exactly 60.00 Hz, two options try to fight each other: `video-sync-max-video-change` and `interpolation-threshold`. Normally, container FPS in something such as an .mp4 or a .mkv is precise enough such that the video can be retimed exactly to the display Hz and interpolation is not activated. In the case of something like certain live streaming videos or other scenario where container FPS is not known, the default option of 0.0001 for `interpolation-threshold` is extremely low, and while `video-sync-max-video-change` retimes the video to what it approximately knows as the "real" FPS, this may or may not be outside of `interpolation-threshold`'s logic at any given time, which causes interpolation to be frequently flipped on and off giving an appearance of stuttering or repeated frames that is oftern quite jarring and makes a video unwatchable. This commit changes the default of `interpolation-threshold` to 0.01, which is the same value as `video-sync-max-video-change`, and guarantees that if the user accepts a video being retimed to match the display, they do not additionally have to worry about a much more precise interpolation threshold randomly flipping on or off. No internal logic is changed so setting `interpolation-threshold` to -1 will still disable this logic entirely and always enable interpolation. The documentation has been updated to reflect this change and give context to the user for which scenarios they might want to disable `interpolation-threshold` logic or change it to a smaller value.
* options: Add validation macro for int typePhilip Langdale2021-03-281-0/+8
| | | | As an illustrative example.
* demux: Move demuxer help to new standard mechanismPhilip Langdale2021-03-284-13/+9
| | | | | Previously, demux help was handled as a special case in main.c and this is no longer necessary.
* options: Make validation and help possible for all option typesPhilip Langdale2021-03-2814-106/+159
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Today, validation is only possible for string type options. But there's no particular reason why it needs to be restricted in this way, and there are potential uses, to allow other options to be validated without forcing the option to have to reimplement parsing from scratch. The first part, simply making the validation function an explicit field instead of overloading priv is simple enough. But if we only do that, then the validation function still needs to deal with the raw pre-parsed string. Instead, we want to allow the value to be parsed before it is validated. That in turn leads to us having validator functions that should be type aware. Unfortunately, that means we need to keep the explicit macro like OPT_STRING_VALIDATE() as a way to enforce the correct typing of the function. Otherwise, we'd have to have the validator take a void * and hope the implementation can cast it correctly. For help, we don't have this problem, as help doesn't look at the value. Then, we turn validators that are really help generators into explicit help functions and where a validator is help + validation, we split them into two parts. I have, however, left functions that need to query information for both help and validation as single functions to avoid code duplication. In this change, I have not added an other OPT_FOO_VALIDATE() macros as they are not needed, but I will add some in a separate change to illustrate the pattern.
* vo_gpu: placebo: keep track of texture sample modeNiklas Haas2021-03-211-0/+4
| | | | | | This fixes an issue where dithering was effectively broken on libplacebo versions >= 103 because the dither texture was being sampled with edge-clamped rather than repeating semantics.
* stats.lua: include a filter's @label when displaying filters on page 1Chris Varenhorst2021-03-151-0/+4
|
* ao_oss: add this audio output againrim2021-03-155-1/+424
| | | | | | | | | | | Changes: - code refactored; - mixer options removed; - new mpv sound API used; - add sound devices detect (mpv --audio-device=help will show all available devices); - only OSSv4 supported now; Tested on FreeBSD 12.2 amd64.
* audio: prevent uninit_audio_out during encodingTom Wilson2021-03-151-1/+2
| | | | | | | | | | | There was a simple oversight that meant audio outputs were uninitialized during an encoding, which is not allowed, the encoding would stop with numerous errors. I added a single line to prevent the call of uninit_audio_out in reinit_audio_chain if the encoder was active and this appears to have fixed the problem without breaking anything else. Fixes #8568
* stream_lavf: add support for Gopher over TLS.parazyd2021-03-151-1/+1
| | | | | | | Gopher over TLS (gophers) is a community-adopted protocol and has recently been merged in: - curl (a1f06f32b8603427535fc21183a84ce92a9b96f7) - ffmpeg (51367267c8a9f1a840f5e810f8c788e6e03712a5)
* ao/pulse: signal the mainloop when ops are doneThomas Weißschuh2021-03-111-2/+5
| | | | | | | | Without the explicit signal the call to pa_threaded_mainloop_wait() will not return as soon as possible. Fixes 4f07607888541e6eb40fc5c3a1edfeb84aacb0f7 See #8633
* player/command: add albumart argument to video-addTom Wilson2021-03-093-4/+13
| | | | | | Enables marking of specific video sources as album art. Co-authored-by: Jan Ekström <jeebjp@gmail.com>
* player/{core,loadfile}: make cover art loading more explicitJan Ekström2021-03-093-10/+16
| | | | | | | | | | | | | Now loading cover art through mp_add_external_file requires an additional argument to be set to true. This way not all video-add commands end up being marked as cover art when they move through mp_add_external_file, as originally changed in 55d7f9ded197d82d172b7baf74b1a07640361ae8 . Additionally, this lets us clean up some logic that would otherwise be duplicated between open_external_files and autoload_external_files, if the logic had been kept split from mp_add_external_file. Fixes #8358
* ao/pulse: wait for command completion when setting volume or muteThomas Weißschuh2021-03-091-13/+8
| | | | | | | | | | | | | | | | This makes the behavior of all control messages consistent, fixing an inconsistency that has been with us since 4d8266c739915184d3787d7ab727ac03378b341b - which is the initial rework of the polyaudio AO into the pulseaudio AO. Muting the stream also directly triggers an update to the OSD. When not waiting for the command completion this read of the mute property may read the old state. A stale read. Note that this somehow was not triggered on native Pulseaudio, but it is an issue on Pipewire. See https://gitlab.freedesktop.org/pipewire/pipewire/-/issues/868
* ytdl_hook: fix crash on missing track bitraternhmjoj2021-03-081-1/+1
| | | | | | | | Some tracks happen to lack bitrate information (ie. no tbr value). In that case, just ignore the track while computing the max bitrate. For an example, this is a stream in which all audio tracks have no bitrate: https://www.raiplay.it/dirette/rai1
* umpv: Use generator expression for filesjimman20032021-03-031-1/+1
| | | Instead of list. potential memory savings.
* wayland: no mouse dragging in fullscreen/maximizedDudemanguy2021-03-021-0/+1
| | | | | | | | | | | | | | | | | | | | | | The wayland code takes mouse dragging into account in order to trigger a client-side request for a window move or window resize. According to the xdg-shell spec*, "[t]he server may ignore move[/resize] requests depending on the state of the surface (e.g. fullscreen or maximized)". Since it is not actually a hard requirement, that means the compositor could actually respond to a clientside move/resize request even if the mpv window was fullscreen. For example, it was pointed out that in sway, if mpv is a floating window, you could drag it around off screen even though the window is fullscreen. This kind of behavior does not really have any practical use. A user can should pan a video if he/she wishes to move its orientation while fullscreen (or maximized for that manner). Naturally, a maximized or fullscreened window should never be manually resized (every compositor likely ignores this anyway). The fix is to simply just not trigger the smecial mouse dragging case if the wayland surface is fullscreened or maximized. *:https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/master/stable/xdg-shell/xdg-shell.xml
* manpage: mention rotate limitations with hwdecGuido Cella2021-03-021-0/+4
|
* vd_lavc: wrap use of deprecated AVCodecContext.thread_safe_callbacks in #ifsfan52021-03-021-0/+2
| | | | For compatibility once FFmpeg removes it entirely.
* manpage: video-rotate supports arbitrary stepsGuido Cella2021-03-021-5/+4
| | | | | The 90° step limitation must be a leftover from old behavior since any value between 0 and 359 works now.
* mac: fix traditional fullscreen on macOS 11der richter2021-02-272-4/+20
| | | | | | | | | | | the fullscreen style mask is not supported on macOS 11 anymore outside of the native fullscreen animation. this can lead to a none working fs or in the worst case a crash. to fix this we will simulate a fullscreen window with a borderless window with the size of the whole screen, though only on macOS 11. Fixes #8490
* mac: remove an unused variableder richter2021-02-271-1/+0
|
* vo_gpu: libplacebo: require v2.72.0Niklas Haas2021-02-232-52/+2
| | | | | | | | | | | | It's about a year old, and packaged pretty much everywhere that bothers to package libplacebo at all. Older versions are only a thing on LTS, which will probably also use older mpv so it works out. Starting with v2.72.0, libplacebo validates all of its parameters internally and turns them into function failures. Doing it twice is awfully redundant, so we can drop the parameter validation. Also allows us to drop some preprocessor macros.
* appveyor: Use MSYS2's spirv-cross package instead of building itBiswapriyo Nath2021-02-231-9/+1
|
* appveyor: use latest build image for fixed MSYS2 installationBiswapriyo Nath2021-02-231-12/+4
| | | | | As MSYS2 installer issues are fixed, remove the workaround from previous commits b8104a013d958e3f177891b22949fc2e66eab955 and ea91162802432aabc8a86216d56223f690e49a67
* msg: fix really-quiet option to only affect terminal outputder richter2021-02-231-2/+2
| | | | | | | | | | | | if log-file and really-quiet options were used together it could lead to a completely empty log-file. this is unexpected because we need the log-file option to work in all cases and produces at least a log of verbosity -v -v. this is a regression of commit a600d152d21ef398eb72b008ee3fe266696eb638 move the really quiet check back up, so it's set before the evaluation of the actual log level, where check for log file, terminal, etc take place.
* mac: add ability to toggle visibility on all workspaces from menubarEvgeny Zinoviev2021-02-211-0/+7
|
* command: add label for on-all-workspaces commandEvgeny Zinoviev2021-02-211-0/+1
|
* mac: support --on-all-workspaces optionEvgeny Zinoviev2021-02-213-1/+14
|
* vo_gpu: don't abort() if plane tex creation failsNiklas Haas2021-02-161-3/+4
| | | | | | | In this case, we just treat all uploads as automatically failing. That error path already exists and is already handled correctly. Fixes #8566
* filters/auto_filters: switch from scaletempo to scaletempo2Jan Ekström2021-02-153-5/+5
| | | | | | | Part 1 of "look how well it performs, then start cleaning up the old one." Closes #8376
* af_scaletempo2: fix crash for speed >= 16Dorian Rudolph2021-02-151-9/+13
| | | | | | | The input buffer size was fixed, but the required size depends on the speed. Now the buffer will be resized dynamically. Fixes #8081
* travis: fix macOS VMs with older homebrew versionsder richter2021-02-131-2/+10
| | | | | | apparently travis changed the homebrew setup and that broke the build. reasons was a different homebrew version that doesn't support the new brew cli.
* mac: only update touch bar items when necessaryder richter2021-02-132-87/+150
| | | | | | | | | | | | | | | | the slider on the touch bar was always updated when any of the related properties changed their value. this is partially dependent on the refresh rate of the video, in the case of time-pos. too many updates to touch bar impact the render performance. to prevent this we only update the slider when necessary, when the touch bar or the touch bar item is visible. the touch bar items only need a granularity of seconds without any decimals, but the time-pos property provides a granularity with decimals. we floor those values and only update the touch bar items when we have at least a 1 second difference. we also check for the visibility of the touch bar and its items. Fixes #8477
* mac: use custom touch bar item and slider instead of a touch bar sliderder richter2021-02-131-9/+9
| | | | | | | | | | | | | the NSSliderTouchBarItem seem to be broken in a way it can't be fixed. it has constraints set by default that can't be removed and lead to warnings and render performance regressions. instead of using the preconfigured NSSliderTouchBarItem we use a custom touch bar item (NSCustomTouchBarItem) with a slider, which essential are the same. this way we can configure our constraints ourselves, which aren't needed in the first place. Fixes: #7047
* vo_gpu: vaapi: export plane pitch properlyNiklas Haas2021-02-121-0/+4
|
* DOCS: fix cplugins information in libmpv.rst.Érico Rolim2021-02-121-2/+2
|
* demuxer/demux_mf: add support for more image codecsPaul B Mahol2021-02-061-0/+2
|
* man: update deband-threshold defaultMia Herkt2021-02-051-1/+1
|
* vo_gpu: lower default deband thresholdMia Herkt2021-02-051-1/+1
| | | | | The previous default was found to be too aggressive for most video. Change to a lower value to prevent destroying too much detail.
* vo_wlshm: support big endian systemsEmmanuel Gil Peyrot2021-02-041-1/+2
| | | | The video was otherwise blue, and that’s not how it should be. :)
* README: update libass dependency harfbuzz as non-optionalder richter2021-01-241-3/+3
| | | | | | since libass 0.15 harfbuzz is no longer optional. Fixes #8412
* manpage: fix PDF buildgaroto2021-01-231-4/+6
| | | | | Not clear what exactly makes it fail with this change, but making the note paragraph added in d5ab5482a9 a note structure seems to fix it.
* docs: Fix an old style parameter referenceChris Varenhorst2021-01-201-1/+1
| | | | `--vf format:stereo-in=help` no longer works. It now must be `--vf=format:stereo-in=help`
* umpv: remove unused importsJim Manos2021-01-191-2/+0
| | | | | | | * fcntl usage was replaced by socket usage in 518bd4c306d50e6772c39c5d7395b9d10b9386da * stat usage was removed in 51a3f13705f8b65b3bfcef5b991903d225759014 as the socket was created under the user's HOME.
* stream_lavf: support rtspsMia Herkt2021-01-191-4/+4
| | | | Fixes #8480
* player: make resetting of track selection to "auto" worksfan52021-01-161-9/+21
|
* mac: fix dangling pointersder richter2021-01-132-31/+32
| | | | | | initialising UnsafeMutableRawPointer the way we did won't free those pointers and we get dangling pointers. explicitly define a scope those pointers are alive and auto freed.
* mac: drop build support for swift versions earlier than version 4.1der richter2021-01-134-52/+21
| | | | | | | | | | | | this drops support for swift <4.1 and with this support for xcode <=9.2. this was the last setup that is officially working on macOS 10.12. our old legacy build macOS 10.12 + xcode 9.2 is replaced by macOS 10.13 + xcode 9.4.1 with swift 4.1. the macOS 10.13 + xcode 10.1 VM is replaced by the latest macOS 10.14 + xcode 11.3.1 VM. this is the oldest version officially supported by Apple. this is in preparations for the following commit.
* mac: fix usage of temporary pointersder richter2021-01-132-29/+57
| | | | | | | | | | | the pointer used to initialise the respective structs is only guaranteed to be alive within this constructor. the struct itself is used later and the data it points to, is not guaranteed to be the same. to fix this we define a scope that pointer is definitely valid and use it within this scope. a helper function was added to get the pointers for several data at once. otherwise we would need to nest withUnsafeMutableBytes several times, which would make it hard to read.
* manpage: document off-by-one loop-file behaviorLeo Izen2021-01-071-0/+5
| | | | | loop-file counts the number of zero-seeks, not playthroughs, which makes its counter off by one compared to loop-playlist.
* manpage: rename OS X references to macOSLeo Izen2021-01-034-36/+36
| | | | | | | | Apple has decided that Mac OS X is now named macOS for the time being. For consistency, it makes sense to use the same name for the operating system in all places where it occurs. This commit renames OS X to macOS in the documentation in places where it was otherwise still using the old name.
* vo_gpu: don't segfault if 3DLUT texture fails uploadingNiklas Haas2021-01-011-0/+5
| | | | This failure path was never properly checked.
* input.conf syntax: support custom quotes !XstringX!Avi Halachmi (:avih)2020-12-312-8/+31
| | | | | | | | | | Where X is any ASCII char chosen by the user. An argument is only interpreted as custom-quoted if it starts with '!' and the line doesn't end right after it. Custom quotes don't interpret backslash-escape. This change only affects command arguments which mpv parses (not array commands), and not tokens before the arguments (where applicable - key name, input section, command prefixes, command name).
* input.rst: fix typo commands -> argumentsAvi Halachmi (:avih)2020-12-311-1/+1
|
* csputils: add mappings for DCI-P3 (ST.431-2) and P3-D65 (ST.432-1)Jan Ekström2020-12-301-0/+4
|
* vd_lavc: add VP8 to the default allowed hwdec codec listEmmanuel Gil Peyrot2020-12-302-2/+2
| | | | | It is supported at least on Intel, from gen8 to gen11, and still gives a pretty welcome reduction of CPU usage on my gen9.
* vo_gpu: cast bvecN to vecN for mix() on older GLSLNiklas Haas2020-12-284-49/+85
| | | | Fixes https://github.com/mpv-player/mpv/issues/8415, among others
* bootstrap: log caught URLErrorJan Ekström2020-12-221-2/+2
| | | | | | | This enables us to get more of a message than just "Download failed.", possibly helping people help themselves to get the download going. References #8417
* Revert "build: recognize Lua 5.1 on Arch Linux"Philip Sequeira2020-12-221-1/+0
| | | | | | | The existing "51obsd" is identical, and can be used to explicitly select Lua 5.1 on Arch if necessary. This reverts commit 36e569b242a2825b861f8f4bcef9f2ce520bc6d3.
* build: fail configure if --lua is specified and Lua isn't foundPhilip Sequeira2020-12-221-3/+3
| | | | | | | | | Should result in: "You manually enabled the feature 'lua', but the autodetection check failed." The moved bit of code was probably intended to do that all along, but it was running too late, so the code that actually checked for Lua didn't know it was explicitly asked for and quietly disabled it if not found.
* wayland: support multiple modifiersDudemanguy2020-12-201-2/+4
| | | | | | | Oversight when the modifier checking was split out to a separate function. Instead of immediately returning on a match, be sure to loop through all modifiers and catch every single one that is pressed before we return them.
* mac: fix type mismatch Int instead of Int32der richter2020-12-191-1/+1
|
* mac: use visible frame rectangle for window geometry calculationder richter2020-12-195-13/+42
| | | | | | | | | | | | | currently we use the whole screen rectangle to calculate the window geometry. this doesn't take the menu bar or the Dock into account. by default use the visible screen rectangle instead. this is also a change in behaviour, since the window can't be placed outside of this rectangle anymore. also add an option to change to the old behaviour, because it can still be useful in certain cases, like placing the window directly underneath the menu bar when used a desktop background. Fixes #8272
* mac: fix a window positioning bug when exiting fullscreender richter2020-12-192-10/+14
| | | | | | | | | | | | | | | | when exiting fullscreen we set the window frame to a aspect fit frame of the fullscreen frame to prevent aspect ration problems when animating. though that intermediate frame was set too early and before the system knew we already exited the fullscreen. because of that the frame we set could not be properly set and its origin was defaulted to the bottom left corner for exactly one display refresh and only after that the wanted frame was set. this led to a (dark) grey area on the right or top depending on the aspect ratio difference of the screen and video. to prevent this set the intermediate frame in the animation group to make it sync with the system's fullscreen behaviour. Fixes #8371
* appveyor: use MSYS2 shaderc packageJames Ross-Gowan2020-12-191-11/+1
| | | | | There's a shaderc package in MSYS2 now. Using it should shave ten minutes off the appveyor build.
* vo_wlshm: support presentation timeDudemanguy2020-12-141-0/+14
| | | | | We get presentation feedback for free thanks to the last commit. Implementing it in wlshm is pretty straightfoward from there.
* wayland: unify frame/presentation callback codeDudemanguy2020-12-144-176/+76
| | | | | | | | | | | | | | | | Originally when presentation time was implemented, the frame callback and presentation feedback functions were called in each rendering api's separate backend (egl and vulkan). This meant that their respective structs were basically copy and pasted across both files. Plus later vo_wlshm started using frame callbacks too. Things got refactored a few times and it turns out there's actually no need to have these things separate anymore. The frame callback can just be initialized in vo_wayland_init and then everything else will follow from there. Just move all of this code to wayland_common and get rid of the duplication. Sidenote: This means that vo_wlshm can actually receive presentation feedback now. It's really simple to do so might as well. See the next commit.
* x11: update geometry/autofit opts on runtimeDudemanguy2020-12-142-0/+25
| | | | | | If the window is maximized, we can't change the size immediately. In that case, we set a bool and wait for the state to change before triggering the resize.
* wayland: update geometry/autofit opts on runtimeDudemanguy2020-12-141-4/+21
| | | | | | Additionally, do some cleanups in the resize/autofitting code to make sure we don't do any wasteful VO_EVENT_RESIZE calls. Note that if set_geometry is called, we must always perform a resize.
* console: use wl-paste on WaylandGuido Cella2020-12-142-3/+13
|
* wayland: remove unused function declarationDudemanguy2020-12-131-1/+0
| | | | | It looks this line was added over 3 years ago, but said function never actually existed or was used. Funny stuff.
* auto_profiles: fix compile_cond on lua 5.1Philip Sequeira2020-12-081-6/+10
| | | | | | 5.1's load() doesn't accept strings; loadstring must be used instead. In 5.2, loadstring is deprecated and setfenv is gone.
* build: recognize Lua 5.1 on Arch LinuxPhilip Sequeira2020-12-081-0/+1
|
* manpage: document background transparencyGuido Cella2020-12-081-7/+7
| | | | | | | | | | | | | | | --alpha=yes doesn't affect only transparent videos and images, but also the background. I spent time researching how to implement transparent backgrounds and had no idea that they already worked at least on Wayland. Background transparency will work on X11 when https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/2376 is merged. It doesn't work on Windows. No idea about macOS. Either way, this paragraph already says that it only works on certain environments twice. References #6590
* manpage: clarify that you can prefetch m3u8 urlsGuido Cella2020-12-081-5/+7
| | | | | | | | | | | With the current wording, I thought that playlist-prefetch doesn't prefetch the next url within a playlist of m3u8 urls, but it makes a big difference, and I would have enabled it earlier if it wasn't for this paragraph. This makes it clear that you can prefetch any file, but that it won't prefill the cache with the video data. This is true for any video, there's nothing unique about HLS streams in the behavior of this option.
* wayland: handle multiple outputs more correctlyDudemanguy2020-12-081-65/+89
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There's a bit of a catch-22 in the wayland backend. mpv needs to know several things about the wl_output the surface is on (geometry, scale, etc.) for lots of its options. You still have to render something somewhere before you can know what wl_output the surface is actually on. So this means that when initializing the player, it is entirely possible to calculate initial parameters using the wrong wl_output. The surface listener is what will eventually correct this and pick the correct output. However not everything was technically working correctly in a multi-output setup. The first rule here is to rework find_output so that it returns a vo_wayland_output instead of internally setting wl->current_output. The reason is simply because the output found here is not guaranteed to be the output the surface is actually on. Note that for initialization of the player, we must set the output returned from this function as the wl->current_output even if it is not technically correct. The surface listener will fix it later. vo_wayland_reconfig has to confusingly serve two roles. It must ensure some wayland-related things are configured as well as setup things for mpv's vo. The various functions are shuffled around and some things are removed here which has subtle implications. For instance, there's no reason to always set the buffer scale. It only needs to be done once (when the wl->current_output is being created). A roundtrip needs to be done once after a wl_surface_commit to ensure there are no configuration errors. surface_handle_enter is now handles two different things: scaling as well as mpv's autofit/geometry options. When a surface enters a new output, the new scaling value is applied to all of the geometry-related structs (previously, this wasn't done). This ensures, in a multi-monitor case with mixed scale values, the surface is rescaled correctly to the actual output it is on if the initial selection of wl->current_output is incorrect. Additionally, autofit/geometry values are recalculated if they exist. This means that dragging a surface across different outputs will autofit correctly to the new output and not always be "stuck" on the old one. A very astute observer may notice that set_buffer_scale isn't set when the surface enters a new output. The API doesn't really indicate this, but a WAYLAND_DEBUG log reveals that the compositor (well at least sway/wlroots anyway) magically sets this for you. That's quite fortunate because setting in the surface handler caused all sorts of problems.
* vo_gpu: revert 8a09299 and conditionally clear framebuffer againder richter2020-12-061-3/+5
| | | | | | | | | | | | | | | | | | | | in the original commit, that removed the conditional clearing, an incorrect assumption was made that clearing "should be practically free" and can be done always. though, at least on macOS + intel this can have a performance impact of up to 50% increased usage. it might have an impact on other platforms and setups as well, but this is unconfirmed. the reason for removing the conditional clearing was to partially work around a driver bug on very specific setups, X11 with amdgpu and OpenGL, to clear garbled frames on start. though it still has issues with garbled frames in other situation like fullscreening. there is also an open bug report on the mesa bug tracker about this. setting the radeonsi_zerovram flag works around all of those issues. since the flag works around all these issues and the original fix doesn't work completely we revert it and keep our optimisation. Fixes #8273
* mac: support screen-name and fs-screen-name optsder richter2020-12-062-7/+23
| | | | | | | the screen-name and fs-screen-name option allow for specifying screens based on their name. this is the name of the NSScreen and also reported by the VOCTRL_GET_DISPLAY_NAMES event. the old screen and fs-screen options by id, respectively, are preferred over these new ones.
* wayland: support fs-screen-name optionDudemanguy2020-12-061-17/+25
| | | | | | | | | In wayland, setting the surface on a specific monitor only works in fullscreen so only --fs-screen-name can be implemented. Like with x11, we prefer --fs-screen over --fs-screen-name if it is set. This may be more useful than setting by ids because there's no guaranteed order in which screens are added in wayland. In wayland, the name used here is the model name detected by the output_listener.
* x11: support screen-name and fs-screen-name optsDudemanguy2020-12-061-1/+19
| | | | | | | | | The --screen-name and --fs-screen-name options allow for specifying screens based on their name. For x11, this is the display name reported by xrandr. --screen-name and --fs-screen-name mimic the --screen and --fs-screen options respectively. If --screen is set, then --screen-name will always do nothing. Likewise, --fs-screen-name does nothing if --fs-screen is set.
* player: add --screen-name and --fs-screen-nameDudemanguy2020-12-064-0/+19
| | | | | | Simple groundwork for adding a couple of user options that allow selecting the screen with a string name. The next two commits implements these options for xorg and wayland.
* manpage: clarify profile-cond requires underscoresGuido Cella2020-12-061-3/+5
| | | | | | | While this says that _ is replaced with -, it doesn't say that you HAVE to use _. This isn't obvious and I didn't understand why my profile conditions with - weren't working at first. Seeing as the person who reproted #8324 ran into this as well, this may be worth clarifying.
* build: restore support for non-pkgconfig zlibMia Herkt2020-12-061-1/+3
| | | | Some platforms do not offer a .pc file for zlib, e.g. Android.
* build: use pkg-config for zlibMia Herkt2020-12-061-3/+1
| | | | | | Zlib has had a .pc file since 2010, and the default search paths we use here can break the build on some distros (notably openSUSE Tumbleweed, which our Travis builds use). Just check pkg-config instead.
* vo_gpu: placebo: update for upstream API changesNiklas Haas2020-12-041-2/+29
| | | | | | | The concept of sample/address modes was moved from `pl_tex` to `pl_desc_binding`. The `pl_tex_blit()` function also underwent an API change.
* vo_sixel: don't divide by zero on small terminalAvi Halachmi (:avih)2020-12-021-10/+16
| | | | | | | | | | Our canvas size calculation is affected by few factors, and rounded down more than once - which can result in 0 width or (more typically) height - e.g. when terminal height is one row. If the width or height are 0 then all bets are off, so simply skip the setups and rendering on this case. We can still recover automatically if the terminal is resized to become bigger.
* vo_sixel: re-fit image on terminal resizeShreesh Adiga2020-12-021-1/+20
| | | | | | | | The obvious approach would be SIGWINCH, however, integrating it would be tricky, so instead we simply poll the size on draw_frame. This means the image won't resize automatically when still - e.g. cover art or when paused, though it would re-fit on OSD changes.
* vo_sixel: refactor of resize, reconfig (no-op)Shreesh Adiga2020-12-021-27/+34
| | | | More granular functionality - will be used by the the next commit.
* vo_sixel: Update description string of vo driverShreesh Adiga2020-12-021-1/+1
|
* csputils: add MP_CHROMA_TOPLEFTNiklas Haas2020-12-023-1/+8
| | | | | | | | | This is commonly used by UHD/HDR sources, and mpv hilariously ignores it up until now, just blindly mapping it to MP_CHROMA_AUTO without even so much as a warning message. It would be justified to add all the other chroma locations as well, but I'm lazy and just wanted to quickly fix this bug.
* travis: use newer 10.15 VM with newer xcodeder richter2020-11-291-1/+1
|
* travis: fix macOS 10.13 buildder richter2020-11-291-3/+8
| | | | | | homebrew is removing 10.13 support and some of the dependencies start building rom source now. we will just pin the last working homebrew version, similar to the 10.12 build
* vo_sixel: don't leak the frame referenceAvi Halachmi (:avih)2020-11-291-4/+9
| | | | | | The reference is allocated at reconfig and happens at least once (and leaked at least once), but can also be called more, e.g. on zoom or pan-and-scan changes.
* vo_tct: don't leak the frame referenceAvi Halachmi (:avih)2020-11-291-0/+5
| | | | | | The reference is allocated at reconfig (and leaked at least once), but could theoretically be called more than once by mpv, or in the future when the tct code is enhanced to hande e.g. pan-and-scan changes.
* vo_tct: remove unused variableAvi Halachmi (:avih)2020-11-291-7/+0
|
* player: allow vo to be switched at runtimesfan52020-11-273-7/+23
|
* demux: add function to refresh a track without (de-)selecting itsfan52020-11-272-0/+22
|
* vo_sixel: use draw_frame instead of draw_imageShreesh Adiga2020-11-271-13/+36
| | | | | | draw_image is deprecated, and draw_frame allows better behavior, like rendering the osd without image. e.g. `mpv --vo=sixel --idle --force-window`.
* vo_sixel: skip testdither init in fixed paletteShreesh Adiga2020-11-271-11/+18
| | | | | | | testdither was being created irrespective of whether opt_fixedpal is set or not. In case of opt_fixedpal=1, testdither is not used in the `prepare_static_palette` code. Hence only initialize it when opt_fixedpal is 0.
* vo_sixel: Update libsixel constant valuesShreesh Adiga2020-11-271-3/+3
| | | | | | | | In sixel_dither_initialize, replace 3 with the libsixel SIXEL_PIXELFORMAT_RGB888. Also in sixel_encode, the 4th parameter is supposed to be depth, which also happens to be the value of PIXELFORMAT_RGB888, so replacing that constant with the depth value.
* matroska.py: remove python2 supportLaserEyess2020-11-271-6/+2
| | | | | | | | | | Since 0.33.0 mpv does not support python2. This commit removes python2 support from the file completely with the following changes: - __future__ import of print_function is python2 only - unicode literals are legacy in python3 - 'sys.version_info.major < 3' check is redundant
* bootstrap.py: remove all python2 supportLaserEyess2020-11-271-6/+1
| | | | | | | | | In 0.33.0 python2 support has been removed from mpv's build system. This commit removes python2 compatibility code from bootstrap.py with the following changes: - __future__ import for print_function is not needed - urllib2 is python2 only
* vo_sixel: change default dither to "auto"Avi Halachmi (:avih)2020-11-272-4/+4
| | | | | | | | | | | | | | For two reasons: 1. It was counter intuitive that there's an "auto" value (which is actually a libsixel value and not an mpv one), but it's not the default value - our default was Atkinson. 2. "auto" provides better dithering than Atkinson with libsixel, which is especially noticeable with smooth gradients - where Atkinson has visible banding. In libsixel 1.8.2 the "auto" value maps to Atkinson if the output palette has up to 16 colors, or to Floyd-Steinberg otherwise (e.g. using fixed palette with 256 colors chooses Floyd-Steinberg).
* vo_sixel: fix the image corruption with mltermAvi Halachmi (:avih)2020-11-272-15/+12
| | | | | | | | | | | | | | | | | | | | | | | | The issue was that we only uploaded the palette to the terminal when it changed (once on init with fixed palette, every frame with dynamic palette with trheshold=-1, only on scene change with threshold >= 0). Now we upload it on every frame, and it seems to fix the mlterm image corruption both with fixed palette and also with dynamic palette with threshold (i.e. at frames which did not upload a palette). It's not entirely clear why it's required with mlterm. It would seem that the palette which libsixel uses with fixed palette matches the built in default palette in xterm, but not in mlterm. With dynamic palette we can guess that mlterm resets the palette after a sixel image, but that's not confirmed. Uploading the palette on every frame doesn't seem to slow down xterm when using fixed palette - not clear yet why uploading a different palette (when using fixedpalette=no) slows it down while same palette on every frame doesn't. In mlterm there's no slowdown either way - and now also no corruption.
* vo_sixel: support --vo-sixel-exit-clear[=yes]Avi Halachmi (:avih)2020-11-272-2/+11
| | | | | | | | By default we still clear the screen, but now it's possible to leave the last sixel image on screen. Allows mpv to be used as img2sixel of sorts, but with our auto-fit and various mpv scaling/filters etc.
* terminal: process input when foregroundedGuido Cella2020-11-261-1/+9
| | | | | | | | | | When mpv is in the background because it was started with `mpv foo.mp3 &`, or the user did ctrl+z bg, and is then brought to the foreground with fg, it buffers input until you press enter. This makes it accept input almost immediately. Having a short interval isn't important, since input is buffered until the next loop iteration. Closes #8120.
* Update VERSIONsfan52020-11-221-1/+1
|
* Release 0.33.0v0.33.0sfan52020-11-222-24/+113
|
* file2string: remove question mark from safe charssfan52020-11-222-9/+4
| | | | | | | | | | Trigraphs such as "??=" (which are enabled by default with -std=c11) can mess up strings, so avoid them entirely by escaping question marks. This also drops Python 2 compatibility from file2string, making the change to the waf rule necessary. The input file is now opened in binary mode which is also more correct versus the old text mode which just happened to work even on binary files.
* Revert "options: disable vsfilter blur compat by default"rcombs2020-11-222-2/+2
| | | | | | | | | | | | | | | This reverts commit 3d17e19c2c5ca80f916411e7e61126cac8443baa. The effect of turning off this setting is that mpv doesn't tell libass what the video stream's resolution is. This happens to result in some files having their transforms scaled in ways that give higher performance (as described in #7435) because libass happened to guess a video resolution that resulted in transforms yielding smaller bitmaps, but it's just as easy for the opposite to happen depending on the resolutions and effects involved. The option's name is also somewhat misleading: setting the storage size affects blur, but it also affects stroke (which is far more important for the vast majority of scripts) and 3D transforms (which look very screwy when done wrong).
* build: always run waf with python3Uoti Urpala2020-11-221-0/+6
| | | | | | | | | | | | Upstream waf still ships with the default interpreter being "python", though the script works with both Python 2 and Python 3 (they're not changing the default choice during 2.0.x releases for compatibility reasons apparently). Add code to bootstrap.py to change the interpreter from "python" to "python3" when downloading the "waf" file. Running any mpv code under Python 2 should be considered unsupported in the future (and any code added need not work under Python 2).
* build: fix macOS arm buildsder richter2020-11-224-4/+11
| | | | | | | | | | | remove the hardcoded swift target version and move the version restriction to configure. this was a bad idea anyway and could lead to mismatched object files between obj-c and swift. fix travis 10.12 legacy build. also update the SDK version parser to handle the new macOS 11 scheme. Fixes #8281
* vo_sixel: draw osd on the output frameShreesh Adiga2020-11-221-0/+5
|
* vo_sixel: return -1 instead of SIXELSTATUS on failureShreesh Adiga2020-11-221-10/+36
| | | | | | | | Currently in mpv functions sixel failures return the value status which is of type SIXELSTATUS. So changing it to -1 which is explicit and compatible with mpv. Also log the errors using MP_ERR/MP_LOG with the error string returned by libsixel to have more info.
* vo_sixel: set --vo-sixel-fixedpalette=yes by defaultShreesh Adiga2020-11-221-1/+1
| | | | | | | fixedpalette seems to be slightly faster than dynamic palette, and also in mlterm it avoids corruption of too bright values overflowing to black. Hence setting it to be default choice instead of dynamic palette.
* vo_sixel: Add aspect ratio based output centeringShreesh Adiga2020-11-222-193/+219
| | | | | | | | | | | | | | | | | | | | | | | | | | Resize the image based on the dimensions reported by vo_get_src_dst_rects to correctly handle aspect ratio that might be set/ignored. Added pad-x and pad-y options for padding. These options will be used to remove the extra padding. Some terminals report the padding of 2px in the ioctl dimensions which can't be used for displaying sixel output. These options can be used for fine tuning the output video resolution. Now all the terminal size detection and calculation logic is done in a single function at resize. Also top and left values are computed from the dst_rect parameters to simplify the logic for the aspect ratio based centering. Additionally vo-sixel-rows and vo-sixel-cols options have been added to enable the user to override the values in case of failures with get_terminal_size2. This commit also adds ability to handle video zoom correctly. Whenever video-zoom is triggered, the src and dst rects will be updated. Scaling seems to work well now.
* vo_sixel: rename all user options with opt_ prefixShreesh Adiga2020-11-221-36/+50
| | | | | | | This has no changes to mpv sixel playback behaviour. This is required because currently the offset values and the resolutions are being overwritten and not remembered.
* vo_sixel: set output resolution based on terminal_get_size2Shreesh Adiga2020-11-221-2/+37
|
* osdep/terminal: Add function to get terminal pixel dimensionsShreesh Adiga2020-11-224-0/+24
|
* doc: split BNF definitions of <command> and <argument> in separate linesEmanuele Torre2020-11-221-2/+3
| | | | | | Having them in the same line made it hard to read them in the man page since they are formatted in the same way and they look as though they are only one definition.
* manpage: document improved --playlist securityLeo Izen2020-11-182-20/+29
| | | | | | | Recent versions of mpv have applied security checks to --playlist that previously only existed if playlist files were played as an input directly. This commit documents this change and how to work around it, in the event that playlist files are trusted.
* command: mouse: generate MOUSE_{ENTER,LEAVE} if requiredAvi Halachmi (:avih)2020-11-161-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | Previously the mouse command never ended up in enter/leave keypresses for the default section even when logically required, because input.c does not know the area of the default section and relies on something feeding it ENTER/LEAVE presses - which the VO typically does but the mouse command didn't. Now the mouse command feeds it ENTER/LEAVE if required. It's possible to handle it differently and more consistently by: 1. reverting this commit. 2. Updating the default section area whenever the osd dimensions change. 3. Always ignore MOUSE_ENTER keys because the position is not known yet (but MOSE_MOVE typically follows right away). 4. On mouse move: first generate ENTER/LEAVE if required. That would guarantee consistency between mouse position and enter/leave events but could be more sensitive to manage (the default section has "infinite" area which is used to capture any event outside of specific section areas), while this commit keeps consistency same as before and depending on correct external feeding - which we now do better, even if still not optimally (like before, it's still technically possible that a script recieves MOUSE_ENTER and then reads the position before it got updated after the ENTER).
* docs/input.rst: document the mouse-pos propertyAvi Halachmi (:avih)2020-11-161-0/+14
|
* command: mouse-pos property: add field "hover"Avi Halachmi (:avih)2020-11-163-5/+13
| | | | | | | | | | | | | | | | | | | | | Add a third field: "hover", which is updated from input.c after input keys MP_KEY_MOUSE_LEAVE and MP_KEY_MOUSE_ENTER - which are typically sent by the VO. It's part of mouse-pos and not a new property because it's highly tied to mouse-pos - it makes x/y invalid while the cursor doesn't hover the window. Unike mouse-move, no dummy command was generated, so we add dummy command in order for observer notification to work even while nothing is bound. Like mouse-pos, clients could not detect whether the mouse pointer hovers the window because the OSC force-binds the MOUSE_LEAVE key, and now they can using the hover field. The lua mp.get_mouse_pos() wrapper still returns only x, y because that's what osc.lua needs. Other clients can simply read the property.
* lua/js: mp.get_mouse_pos: use the mouse-pos propertyAvi Halachmi (:avih)2020-11-164-22/+6
| | | | | | | mp.get_mouse_pos() is undocumented and is no longer required - the property can be used officially by any client now, however, osc.lua uses it, and also some user scripts learnt to rely on it, so we keep it - as a trivial wrapper around the new mouse-pos property.
* command: new property: mouse-posAvi Halachmi (:avih)2020-11-161-0/+30
| | | | | | | | | | | | | | | This is a read-only MPV_NODE value with integer fields: x, y. The values are unmodified from mp_input_get_mouse_pos(...). Observer notification of this property is tied to the INPUT_PROCESSED event, which fires after mouse move even if no command is bound (dummy commands are generated if nothing is bound to ensure that mp_input_get_mouse_pos returns the latest values - see ac927e39 ). This allows clients such as JSON IPC to observe mouse position even while the OSC is enabled - the OSC force-binds mouse move for most of the window area, making it impossible for other clients to bind mouse move without breaking the OSC.
* command: add internal INPUT_PROCESSED eventAvi Halachmi (:avih)2020-11-162-0/+5
| | | | | | Fires after a non-empty input queue was processed. Currently yet unused, but the next commit will use it.
* path: do not use old_home for win32 exe dirwm42020-11-163-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works. Mistakenly reverted as part of the default configuration directory location switch-back in aa18a8e1cde663caeabd93af7d57a745c1a76af6. Separation of the mpv executable directory from old_path is a good change now that we warn about the old_config directory also existing. Fixes #8232 Fixes #8244 Fixes #8262
* js: report scripts CPU/memory usage statisticsAvi Halachmi (:avih)2020-11-152-1/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This can be viewed at page 4 of the internal stats display (i or I). CPU time report is the same as at lua.c, but untested - doesn't seem to work on windows - also not for lua. TL;DR: Set env MPV_LEAK_REPORT=1 to enable js memory reporting stats. This also almost doubles the memory usage by js scripts. For memory reporting, we don't have enough info by default, because even when using a custom allocator, mujs doesn't report the old size (on free or realloc) because it doesn't track this value, and as a result we can't track the overall size. Our option are either to track the size of each allocation on our own, or use talloc which tracks this value. However, using talloc for mujs allocations adds a considerable overhead, and almost doubles(!) the overall memory used, because each individual allocation includes a considerable talloc header, and mujs does many small allocations. So our solution is that by default we behave like previously - not using a custom allocator with mujs, and stats does not display memory usage for js scripts. However, if the env var MPV_LEAK_REPORT is set to 1, then we use a custom allocator with talloc and track/report memory usage. We can't switch allocator at runtime, so an mpv instance either tracks or doesn't track js scripts memory usage, according to the env var. (we could use a property and apply it whenever a new script starts, so that it could change for newly launched scripts, but we don't).
* ci: fix mingw build by adding harfbuzzsfan52020-11-151-0/+11
|
* command: make subtitle time properties observableBen Kerman2020-11-111-1/+2
|
* manpage: properties fixesGuido Cella2020-11-111-17/+21
| | | | | | | | | | | - Explain which properties are writeable. - Mark edition-list/N/id as writable. - Remove (R) from some read-only properties since none of the others have it. - Add osd-dimension/ to its subproperties. - options/<name> isn't read-only. - focused works on macOS because of 82eda2e. Though it shouldn't be possible to observe it without raising VO_EVENT_FOCUS.
* manpage: document the property-change eventGuido Cella2020-11-111-0/+11
|
* manpage: document video-frame-info sub-propertiesGuido Cella2020-11-111-5/+13
| | | | | | | The picture type is explained in /usr/include/libavutil/avutil.h Other subproperties in /usr/include/libavutil/frame.h And there is a more detailed explanation for repeat_pict in /usr/include/libavcodec/avcodec.h
* manpage: remove redundant "Return(s) "Guido Cella2020-11-111-59/+58
| | | | | | ...from the property descriptions that include it, and reformat the paragraphs. And say "Returns" in idle-active.
* manpage: document demuxer-cache-state betterGuido Cella2020-11-111-4/+11
|
* manpage: be consistent with booleansGuido Cella2020-11-111-73/+73
| | | | | | | | | | | | | When possible, refer to booleans with "Whether..." since it can refer to both yes (using input.conf and mp.get_property) and true (using the JSON IPC or mp.get_property_native/bool), else explicitly say yes/true. Say "true" for subprocess and osd-overlay named arguments since you can't use them in input.conf and you will typically use them with the boolean true in the named arguments, like the subprocess example in the manpage does (though the string "yes" also works). Subproperties that can't be accessed with the / syntax like demuxer-cache-state's bof-cached and eof-cached always return true, never yes.
* vo_sixel: Add fallback terminal width and heightShreesh Adiga2020-11-091-2/+5
| | | | | In case terminal_get_size function fails, the default height of 25 rows and 80 columns will be assumed
* vo_sixel: Add checks to prevent null pointer dereferencing.Shreesh Adiga2020-11-091-1/+8
|
* ao_alsa: handle -EPIPE XRUNs from snd_pcm_statusJan Ekström2020-11-091-2/+11
| | | | | | | | | Set pcm state to SND_PCM_STATE_XRUN in case -EPIPE is received, and handle this state as per the usual logic. This way snd_pcm_prepare gets called, and the loop continued. Inspired by a patch posted by malc_ on #mpv.
* ao_alsa: always initialize state if passedJan Ekström2020-11-091-9/+7
| | | | | Based on ao_play_data's assert, we are always expected to give non-default values back from an AO's get_state.
* wayland: fix buffer overrun in get_modsDudemanguy2020-11-081-3/+3
| | | | Use MP_ARRAY_SIZE and make the mod arrays here const.
* wayland: check for modifier keys on pointer eventsDudemanguy2020-11-082-33/+40
| | | | | | | | | The pointer button event had no code to handle any modifier keys. So this meant input combinations like Shift+MTBN_LEFT did not work. Fix this by ripping out the modifier-checking code in keyboard key event to a separate function and using it for both the keyboard and mouse events. In the case of the mouse, it is possible that the keyboard may not exist so be sure to check before trying to get any modifiers. Fixes #8239.
* Revert "wayland: conditionally commit surface on resize"Dudemanguy2020-11-083-10/+2
| | | | | | | | | | | | 30dcfbc is a workaround for incorrect border sizes that could occur on sway/wlroots in certain edge cases. This seemed harmless enough, but it turns out that on mutter the extra wl_surface_commit somehow causes the window always go to the top left of the screen after you leave fullscreen. No idea why this occurs, but the original commit is a workaround a sway bug and causing regressions for other users isn't right despite the author being biased towards sway/wlroots. This reverts commit 30dcfbc9cb3f77dbb729fb6f95ffde7dbdddc4cb.
* DOCS: correct interface-changes.rstDudemanguy2020-11-071-2/+2
| | | | delete-watch-later-config was introduced in mpv 0.33.0 not mpv 0.31.0.
* mac: make focus property observableder richter2020-11-071-0/+32
| | | | | | i missed the VO_EVENT_FOCUS event and the possibility to observe this property and didn't include it in my initial focus commit for that matter.
* video/out/vo_sixel.c: Implement sixel as a output deviceShreesh Adiga2020-11-075-0/+498
| | | | | | | | | | | | | | | | | | | | | | | | | | Based on the implementation of ffmpeg's sixel backend output written by Hayaki Saito https://github.com/saitoha/FFmpeg-SIXEL/blob/sixel/libavdevice/sixel.c Sixel is a protocol to display graphics in a terminal. This commit adds support to play videos on a sixel enabled terminal using libsixel. With --vo=sixel, the output will be in sixel format. The input frame will be scaled to the user specified resolution (--vo-sixel-width and --vo-sixel-height) using swscaler and then encoded using libsixel and output to the terminal. This method requires high cpu and there are high frame drops for 720p and higher resolution videos and might require using lesser colors and have drop in quality. Docs have all the supported options listed to fine tune the output quality. TODO: A few parameters of libsixel such as the sixel_encode_policy and the SIXEL_XTERM16 variables are hardcoded, might want to expose them as command line options. Also the initialization resolution is not automatic and if the user doesn't specify the dimensions, it picks 320x240 as the default resolution which is not optimal. So need to automatically pick the best fit resolution for the current open terminal window size.
* manpage: document av1 addition to --hwdec-codecs default settingLeo Izen2020-11-051-1/+1
| | | | | Document the change to add AV1 to the list of default hwdec codecs, in commit 172146e9f7a231b5de21921d883612d18b13a717.
* vd_lavc: add AV1 to the default allowed hwdec codec listJan Ekström2020-11-031-1/+1
| | | | | Now that the first hwaccel implementations are coming in, it makes sense to allow this format.
* player: fix external cover file prioritizationsfan52020-10-281-4/+8
| | | | | Array order was ignored entirely instead of being used as intended. Fixes: c07089a250
* input.conf: add default keybindings for sub-scalesoredake2020-10-272-2/+5
|
* console: let type set the cursor positionGuido Cella2020-10-272-6/+18
| | | | | | | | | | | | | | | | | | This allows keybindings such as: a script-message-to console type "seek :0 absolute" 6 % script-message-to console type "seek absolute-percent" 6 The cursor position 0 isn't allowed because it has the weird effect of filling the console with the text twice, leaving the cursor in the middle. Negative positions would put the cursor n characters before the end, and positions greater than the text's length at the end. They seem to work at first, but the console breaks when you move the cursor, so they aren't allowed. It seems that float values don't cause issues, but I'm using the argument's floor anyway to be safe. Using >= 1 instead of > 0 ignores values like 0.5.
* ytdl_hook: if ytdl not found in config dirs, use ytdl_path as isRicardo Constantino2020-10-271-1/+4
|
* ytdl_hook: support alternative youtube-dl pathRicardo Constantino2020-10-272-2/+9
| | | | | Allows using a youtube-dl not in PATH or a compatible fork of youtube-dl.
* player: reorder list of external cover files for optimal resultssfan52020-10-251-7/+9
|
* build: disable wayland if linux/input-event-codes.h isn’t availableEmmanuel Gil Peyrot2020-10-251-1/+5
| | | | | | | | | | | | | The wl_pointer interface defines button argument as “a button code as defined in the Linux kernel's linux/input-event-codes.h header file, e.g. BTN_LEFT.” We could #define these few buttons ourselves, but there is no system to test it on, so for now let’s disable Wayland support on them. This is a call to non-Linux system maintainers, please help test this backend on your system and report issues you find, or even working state.
* wayland: use more specific input codes headerEmmanuel Gil Peyrot2020-10-251-1/+1
| | | | | | Wayland’s wl_pointer interface describes the button event’s argument as being taken from linux/input-event-codes.h, so there is no need to include the more generic linux/input.h.
* demux_lavf: initialize ReplayGain dataMia Herkt2020-10-231-0/+2
| | | | | | | This was causing undefined behavior when playing streams without RG tags but with RG enabled. Broken in 585f9ff42f3195c. Thanks to uau for bisecting.
* command: add delete-watch-later-configVladimir Panteleev2020-10-225-0/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This introduces the delete-watch-later-config command, to complement write-watch-later-config. This is an alternative to #8141. The general problem that this change is attempting to help solve has been described in #336, #3169 and #6574. Though persistent playback position of a single file is generally a solved problem, this is not the case for playlists, as described in #8138. The motivation is facilitating intermittent playback of very large playlists, consisting of hundreds of entries each many hours long. Though the current "watch later" mechanism works well - provided that the files each occur only once in that playlist, and are played only via that playlist - the biggest issue is that the position is lost completely should mpv exit uncleanly (e.g. due to a power failure). Existing workarounds (in the form of Lua scripts which call write-watch-later-config periodically) fail in the playlist case, due to the mechanism used by mpv to determine where within a playlist to resume playback from. The missing puzzle piece needed to allow scripts to implement a complete solution to this problem is simply a way to clean up the watch-later configuration that the script asked mpv to write using write-watch-later-config. With that in place, scripts can then register an end-file event listener, check the stop playback reason, and in the "eof" and "stop" case, invoke delete-watch-later-config to delete any saved positions written by write-watch-later-config. The script can then proceed to immediately write a new one when the next file is loaded, which altogether allows mpv to resume from the correct playlist and file position upon next startup. Because events are delivered and executed asynchronously, delete-watch-later-config takes an optional filename argument, to allow scripts to clear watch-later configuration for files after mpv had already moved on from playing them and proceeded to another file. A Lua script which makes use of this change can be found here: https://gist.github.com/CyberShadow/2f71a97fb85ed42146f6d9f522bc34ef (A modification of the one written by @Hakkin, in that this one takes advantage of the new command, and also saves the state immediately when a new file is loaded.)
* vo_gpu: improve gamut warning bounds checksNiklas Haas2020-10-211-2/+2
| | | | | | | Test for signals exceeding 0.5% of the permitted gamut, in either direction. (Before, it was 1% above and 0% below) Should fix https://github.com/mpv-player/mpv/issues/8161
* wayland: don't use presentation time if ust is 0Dudemanguy2020-10-191-3/+4
| | | | | | | | Testing kwinft out (kwin fork), it was discovered that sometimes it would return a ust value of 0 which subsequently resulted in incorrect presentation statistics (i.e. large negative numbers which are obviously impossible). Arguably, it shouldn't return 0s, but a workaround for mpv in this case is harmless.
* stats: display hw pixel format toosfan52020-10-161-0/+4
|
* command: expose underlying pixfmt for hwdecsfan52020-10-162-0/+7
|
* ci/appveyor: attempt to work around outdated msys2Jan Ekström2020-10-171-0/+8
| | | | | | | | Based on the workarounds utilized in the MAME project: 1. mamedev/mame@4b4016110a71a5b84b9d19faf20238d20926088d 2. mamedev/mame@2d1bf3ed5cb1f4cdcc40b286a78c24f398217535 Co-authored-by: James Ross-Gowan <rossy@jrg.systems>
* ci/travis: stop installing mingw-w64 packages manuallyJan Ekström2020-10-161-4/+0
| | | | | | As we are now on 20.04, these packages are now available in the repositories. Additionally, they don't need to be separately pulled in, as gcc-mingw-w64 already does that.
* ci/travis: move to a yaml list for required packages for mingw-w64Jan Ekström2020-10-161-2/+8
|
* ci/travis: bump Ubuntu distro version to focal (20.04)Jan Ekström2020-10-161-1/+1
|
* manpage: Document behaviour of *nix configuration directoriesPhilip Langdale2020-10-161-6/+22
| | | | | | | The original documentation here is unclear, so let's describe the behaviour we actually have. Inspired by wm4's updated docs but obviously not identical because we're not changing any of the behaviours.
* Revert "path: switch back to using non-XDG config dir by default"Philip Langdale2020-10-162-48/+30
| | | | This reverts commit 269f0e743e5634691f0c9d5b1b8a4bb68eedbbd0.
* Revert "path: do not use old_home for win32 exe dir"Philip Langdale2020-10-163-4/+1
| | | | This reverts commit c3694f0acb7f71daac7606fafbadcb7b500ca35e.
* Revert "manpage: reference standard for configuration file location"Philip Langdale2020-10-161-5/+0
| | | | This reverts commit 67b4a96e4592a6bf95a86ebcc8f6c5e951fe327d.
* build: bump waf to 2.0.20Jan Ekström2020-10-161-2/+2
| | | | | | There have been mentions that there are apparently some bugs with regards to possible random build failures, so bumping after a few years sounds like an OK thing to test/do.
* stream_lavf: enable SRT protocol support through FFmpegAlexandre Iooss2020-10-153-2/+3
| | | | | Additionally, announce support for the protocol in Mac and Linux application metadata.
* vo_gpu: fix segfault when updating render optsDudemanguy2020-10-151-1/+2
| | | | | | VOCTRL_UPDATE_RENDER_OPTS is supposed to be optional so check if it actually exists before executing the function. Fixes a segfault when changing the alpha value at runtime on non-wayland platforms.
* vo_gpu: EGL: hack for alpha on different platformsDudemanguy2020-10-152-1/+4
| | | | | | | | | | | 7fb972f fixed transparency on x11/EGL/Mesa but happened to also break it for wayland and nvidia. Ideally on wayland, you should just be able to pick the right EGLConfig that has alpha but this doesn't seem to work because reasons. So just go back to setting the EGL_ALPHA_SIZE bit if the user asks for alpha. Apparently this worked before for nvidia as well. The hack is to just run an eglQueryString in the x11egl context. If it picks up Mesa as the EGL_VENDOR, then force ctx->opts.want_alpha to 0 and let pick_xrgba_config take care of the rest.
* wayland: update opaque region on runtimeDudemanguy2020-10-155-39/+54
| | | | | | | | | | Made possible with 00b9c81. 34b8adc let the wayland surface set an opaque region depending on if alpha was set by the user or not. However, there was no attempted detection for runtime changes and it is possible (at least in wayland vulkan) to toggle the alpha on and off. So this meant, we could be incorrectly signalling an opaque region if the user happened to change the alpha. Additionally, add a helper function for this and use it everywhere we want to set the opaque region.
* vo_gpu: update render options on runtimeDudemanguy2020-10-152-4/+14
| | | | | | | | | | | | vo_gpu has a small set of options for ra_ctx that can be set. In practice, runtime toggling doesn't matter for most of these as they have no effect while a video is playing. However, changing the alpha option during runtime can actually work depending on the backend used. mpv already detected when one of these options changed, but it made no attempt to update the options in the ra_ctx accordingly (likely because nothing made any use of this information). Another related change is to add an update_render_opts to the fns and allow invidiual backends to (optionally) use it.
* wayland: be less strict about when to renderDudemanguy2020-10-155-3/+16
| | | | | | | | | | | | | | | | | | | | | efb0c5c changed the rendering logic of mpv on wayland and made it skip rendering when it did not receive frame callback in time. The idea was to skip rendering when the surface was hidden and be less wasteful. This unfortunately had issues in certain instances where a frame callback could be missed (but the window was still in view) due to imprecise rendering (like the default audio video-sync mode). This would lead to the video appearing to stutter since mpv would skip rendering in those cases. To account for this case, simply re-add an old heuristic for detecting if a window is hidden or not since the goal is to simply not render when a window is hidden. If the wait on the frame callback times out enough times in a row, then we consider the window hidden and thus begin to skip rendering then. The actual threshold to consider a surface as hidden is completely arbitrary (greater than your monitor's refresh rate), but it's safe enough since realistically you're not going to miss 60+ frame callbacks in a row unless the surface actually is hidden. Fixes #8169.
* wscript_build.py: use -Wl,--subsystem,console insteadChristopher Degawa2020-10-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes an issue with clang not using the -mconsole option if mwindows is present resulting in mpv.com being a gui program instead of a console program. Does not interfere with gcc compilation. result without this patch ``` file .\mpv.com .\mpv.exe .\mpv.com: PE32+ executable (GUI) x86-64 (stripped to external PDB) .\mpv.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB) ``` both executables open the mpv gui with out console output. result with this patch ``` file .\mpv.com .\mpv.exe .\mpv.com: PE32+ executable (console) x86-64 (stripped to external PDB) .\mpv.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB) ``` mpv.com properly outputs text to console instead of instantly opening a gui `, for MS Windows` removed from the end of file outputs to reduce col count https://github.com/m-ab-s/media-autobuild_suite/issues/1794 Signed-off-by: Christopher Degawa <ccom@randomderp.com>
* docs: fix simple typo, unminimze -> unminimizeTim Gates2020-10-141-1/+1
| | | | | | There is a small typo in DOCS/man/options.rst. Closes #8165
* DOCS: fix typo on sub-filter-regex-enableChris Varenhorst2020-10-121-1/+1
|
* manpage: reference standard for configuration file locationwm42020-10-091-0/+5
|
* Revert "demux: add a POS"wm42020-10-084-190/+0
| | | | | | This reverts commit 4f18e7927bacd2e887f8cca48a967804ce7adf86. It was a mistake, and barely anyone needs this.
* player: fix another nightmarish corner casewm42020-10-081-3/+14
| | | | Pretty much fuck this shit.
* demux: add a POSwm42020-10-084-0/+190
| | | | | | I regret doing this so much, it's fucking garbage. Fixes: #5100
* Revert "wayland: add wayland-display-socket option"Dudemanguy2020-10-073-17/+3
| | | | | | | Pointless feature that can be done with environment variables. It was also implemented incorrectly and broke autoprobing. This reverts commit 015b6768759c8bd8cc815be01123ef95c192f3c5.
* wayland: add wayland-display-socket optionDudemanguy2020-10-063-3/+17
| | | | | | | | | | As per the client API, a client can connect to any arbitrary wayland socket. mpv has always just passed NULL which connected to the compositor currently in use, but one could just as easily pass the name of a different socket (i.e. the value of WAYLAND_DISPLAY). Here, we just expose this argument as a user configurable option. If the user passes a socket name that does not exist, then print a warning and fall back to NULL.
* screenshot: add --screenshot-sw optionwm42020-10-054-1/+19
| | | | | Probably worthless. As usual, the manpage dumps all the subtle differences due to implementation details on the user.
* wayland: set an opaque regionDudemanguy2020-10-013-0/+19
| | | | | | | | | Apparently a part of the wayland spec. A compositor may use a surface that has set part of itself as opaque for various optimizations. For mpv, we simply set the entire surface as opaque as long as the user has not set alpha=yes (note: alpha is technically broken in the wayland EGL backend at the time of this commit but oh well). wlshm is always opaque. Fixes #8125.
* options: fix --cover-art-file typoGuido Cella2020-09-301-1/+1
| | | | ...which makes it not work.
* player: cosmetically change around some codewm42020-09-281-9/+9
| | | | Is this better?
* player: add automatic loading of external cover art fileswm42020-09-286-8/+95
| | | | | | | | | | | | | | | | | | | | | | | Picks up files like "cover.jpg". It's made part of normal external file loading, so I'm adding 3 new options that are direct equivalents for the options that control loading of external subtitle and audio files. Even though I bet nobody wants them and they just increase confusion... I guess the world is actually hell, so this outcome should be fine. It prefers non-specific external files like "cover.jpg" over embedded cover art. Not sure if that's wanted or unwanted. There's some pain over explicitly marking such files as external pictures. This is basically an optimization: in most cases, a heuristic would treat an image file loaded with --external-file the same (it's a heuristic because ffmpeg can't tell us whether something is an image or a video). However, even with this heuristic, it would decode the cover art picture again on each seek, which would essentially slow down seeking in audio files. This bothered me greatly, which is why I'm adding these additional options at all, and bothered with the previous commit. Fixes: #3056
* player: let frontend decide whether to use cover-art modewm42020-09-283-7/+23
| | | | | | | | | | | | | Essentially, this lets video.c decide whether to consider a video track cover art, instead of having the decoder wrapper use the lower level sh_stream flag. Some pain because of the dumb threading shit. Moving the code further down to make some of it part of the lock should not change behavior, although it could (framedrop nonsense). This commit should not change actual behavior, and is only preparation for the following commit.
* ci: fix spirv-cross build in mingw scriptssfan52020-09-251-3/+8
|
* mac: add support for the focused propertyder richter2020-09-251-0/+4
|
* mac: add an option to prevent focusing of the window on opender richter2020-09-255-3/+22
| | | | | | | | | on macOS 10.15 setting the activation policy behaves quite weirdly. the call changes the current active App to a nameless process, which probably also the reason that prevents the not focusing to work. a workaround for that, is to refocus the previous active app. Fixes #7725
* travis: fix macOS 10.12 legacy buildder richter2020-09-221-0/+3
| | | | | | | | brew update tries to update the java cask, which it tries to build from source. this takes too long and leads to a timeout of the job. we can't manually remove the java cask because of a bug in the too old brew cask version and the old formula. we just remove the whole cask tap and call it a day, since we don't need it anyway.
* wayland: only render if we have frame callbackDudemanguy2020-09-217-37/+108
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Back in the olden days, mpv's wayland backend was driven by the frame callback. This had several issues and was removed in favor of the current approach which allowed some advanced features (like display-resample and presentation time) to actually work properly. However as a consequence, it meant that mpv always rendered, even if the surface was hidden. Wayland people consider this "wasteful" (and well they aren't wrong). This commit aims to avoid wasteful rendering by doing some additional checks in the swapchain. There's three main parts to this. 1. Wayland EGL now uses an external swapchain (like the drm context). Before we start a new frame, we check to see if we are waiting on a callback from the compositor. If there is no wait, then go ahead and proceed to render the frame, swap buffers, and then initiate vo_wayland_wait_frame to poll (with a timeout) for the next potential callback. If we are still waiting on callback from the compositor when starting a new frame, then we simple skip rendering it entirely until the surface comes back into view. 2. Wayland on vulkan has essentially the same approach although the details are a little different. The ra_vk_ctx does not have support for an external swapchain and although such a mechanism could theoretically be added, it doesn't make much sense with libplacebo. Instead, start_frame was added as a param and used to check for callback. 3. For wlshm, it's simply a matter of adding frame callback to it, leveraging vo_wayland_wait_frame, and using the frame callback value to whether or not to draw the image.
* player: add pause state to playback start messagewm42020-09-211-2/+3
| | | | | Now the player tells you that audio or video are playing while paused, or something.
* terminal: fix segfault when backgroundingwm42020-09-211-2/+4
| | | | | | | | | In the recent terminal commit, I "compressed" the read() error handling, and messed it up. The return value could be -1 for other non-fatal errors (such as EIO when trying to read while backgrounded), which resulted in buf.len getting messed up. Fixes: 602384348e718c77
* f_decoder_wrapper: make log prefix less verbosewm42020-09-201-2/+2
|
* audio: take paused state into account in ao_start()sfan52020-09-201-1/+1
| | | | | It makes no sense to instruct the AO to start the pull callbacks when we know there's nothing to play (only affects pull AOs).
* audio: move start() calls outside of locksfan52020-09-201-3/+10
| | | | | Pull based AOs might want to call ao_read_data() inside start(). This fixes ao_opensles deadlocking.
* mac: add an option to change the App activation policyder richter2020-09-204-1/+28
| | | | useful to hide the app icon in the Dock if necessary.
* mac: add ontop window level for desktopder richter2020-09-203-4/+9
| | | | | | this puts the window ontop of the desktop but behind the desktop icons. Fixes #7791
* options: simplify --android-surface-size handlingsfan52020-09-205-27/+8
|
* build: disable GLXwm42020-09-181-2/+3
| | | | | | Nobody needs this anymore. If not too many people complain, we'll remove this completely. Many already consider X11 and OpenGL legacy, so we don't need TWO X11/OpenGL backends.
* manpage: fix console keybindings punctuationGuido Cella2020-09-181-3/+3
|
* msg: make --msg-time show time in secondswm42020-09-182-2/+2
| | | | | More readable, similar to what --log-file will use (although the terminal code shows microseconds and uses less left padding).
* build: sort dependencies (to make build deterministic)Philip Sequeira2020-09-181-1/+1
| | | | Fixes #7855.
* command, demux: make drop-buffers reset state even harderwm42020-09-172-4/+10
| | | | Leave nothing left when it's executed.
* terminal: attempt to handle the ESC keywm42020-09-171-24/+22
| | | | | | | | | | | | | | | | | | Due to Unix being legacy garbage, it's not possible to safely detect the ESC key on terminal. The key sequences are ambiguous. The code for the ESC key also starts the sequences for other special keys. Until now, you needed to hit ESC twice for it to be recognized. Attempt to handle this better by using a timeout to detect the key. If ESC is in the input buffer, but nothing else arrived after a timeout, assume it's the ESC key. I think this is the method vim uses. Currently, the timeout is set at 100ms. This is hardcoded and cannot be changed. It's possible that this causes problems on slow ssh connections or so. I'm not sure what exactly happens if you manage to get ESC + another normal key into the input buffer. If it's a known sequence, it will be matched and interpreted as such. If not, it'll probably be discarded.
* client API: update alignment requirements for software renderingwm42020-09-171-9/+12
| | | | | | | Previous commit fixes it for libswscale. The libzimg path has extra code to copy by slice, but it still may access pixel groups using normal memory accesses (for example, reading rgba pixel data via uint32_t), so document a minimum alignment requirement per pixel format.
* sws_utils: work around libswscale corrupting memory yet againwm42020-09-172-2/+57
| | | | | | | | | | | | | | | | | | | | If the alignment is less than 16, certain libswscale code paths will silently corrupt memory outside of the target buffer. This actually affected the libmpv software rendering API (that was fun to debug). Rather than passing this problem to the next API user, try to avoid it within libmpv. It's unclear which alignment libswscale requires for safe operation. I'm picking 32 (one more than the observed safe value in the case I experienced), because libavfilter mostly uses this value. The way to work this around is slow: just make a full copy of the entire input or output image. Possibly this could be optimized by using the slice API, but that would be more effort, and would likely expose further libswscale bugs. Hope that this is a rarely needed path. The next commit will update the alignment requirement documentation bits.
* manpage: refer to --sub-color for colorsGuido Cella2020-09-171-4/+4
| | | | | Don't make the user search for --osd-color only to make him search again for --sub-color.
* manpage: mark file-local-options as writableGuido Cella2020-09-171-1/+1
|
* stream_slice: interpret `end` as offset if it starts with '+'Mohammad AlSaleh2020-09-172-0/+11
| | | | | | | | Example: slice://1g-2g@file.ts (1 to 2) slice://1g-+2g@file.ts (1 to 3) Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
* command: add property track-list/N/main-selectionwnoun2020-09-122-0/+18
|
* player: fix inconsistent AO pause state in certain situationswm42020-09-122-8/+3
| | | | | | | | | | | | | | | | | | Pause can be changed during a file change, such as with for example --reset-on-next-file=pause, or in hooks, or by being quick, and in this case the AO's pause state was not updated correctly. mpctx->ao_chain is only set if playback is fully initialized, while the AO itself in mpctx->ao can be reused across files. Fix this by always running set_pause_state() if the pause option is changed. Could cause new bugs since running this used to be explicitly avoided outside of the loaded state. The handling of time_frame is potentially worrisome. Regression due to recent audio refactor; before that, the AO didn't have a separate/persistent pause state. Fixes: #8079
* player: some minor code golfwm42020-09-101-11/+6
|
* vo_vdpau: remove an unused variablewm42020-09-101-2/+0
|
* player: clamp relative seek base time to nominal durationwm42020-09-101-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since b74c09efbf7, audio-only files let you seek to arbitrary points beyond the end of the file (but still displayed the time clamped to the nominal file duration). This was confusing and just not wanted. The reason is probably that the commit removed setting the audio PTS for data before the seek target, so if you seek past the end of the file, the audio PTS is never set. This in turn means the logic to determine the current playback time has no PTS at all, and thus falls back to the seek PTS. This happened in the past for other reasons (like efe43d768f). I have enough of this, so I'm just changing the code to clamp the seek timestamp to a "known" range. Do this when seeking ends, because in the fallback case, the playback time shouldn't be stuck at e.g. "end + seek_argument". Also do it when initiating a new seek (mp_seek), because if the previous seek hasn't finished yet, it shouldn't add them up and allow it to go "out of range" either. The latter is especially relevant for hr-seeks. Doing this clamping is problematic because the duration is a possibly invalid value from the demuxer, or just missing. Especially with timestamp resets, fun sometimes happens, and in these situations it might be better not to clamp. One could argue you should just use the last audio timestamp returned by the decoder or demuxer (even if that directly conflicts with --end), but that sounds even more hairy. In summary: what a dumb waste of time, what the fuck.
* manpage: "fix" some formattingwm42020-09-101-4/+8
| | | | Yeah, fuck this retarded garbage.
* terminal-unix: attempt to support more CTRLwm42020-09-101-6/+14
| | | | | | | Hysterically stupid inconsistent legacy garbage from the 70ies or maybe even 60ies. What the fuck. I fucking hate computers so much. Fixes: #8072
* vo_vdpau: remove deprecated/inactive --vo-vdpau-deint optionwm42020-09-094-30/+1
| | | | | I think this has been dead code for quite a while. It was deprecated anyway.
* command: add read-only focused propertyGuido Cella2020-09-088-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a property that returns whether the window is focused, currently only for X11 and Wayland. My use cause for this is having an equivalent of pause-when-minimize.lua for tiling window managers: make mpv play only while it's in the current workspace or is focused (I'm fine with either one but prefer focus). On X I do this by observing display-names, which is empty when the rectangles of the display and mpv don't intersect, but on Wayland its value doesn't change when mpv leaves the current workspace (and the same check doesn't work since the geometries still intersect). This could later be made writable as requested in #6252. Note that on Wayland se shouldn't consider an unactivated window with keyboard input focused. The wlroots compositors I tested set activated after changing the keyboard focus, so if you set wl->focused only in keyboard_handle_enter() and keyboard_handle_leave() to avoid adding the "has_keyboard_input" member, focused isn't set to true when first opening mpv until you focus another window and focus mpv again. Conversely, if that order can't be assumed for all compositors, we should toggle wl->focused when necessary in keyboard_handle_enter() and keyboard_handle_leave() as well as in handle_toplevel_config().
* manpage: fix typoGuido Cella2020-09-061-4/+4
| | | | | Change 'already by defined' to 'already defined' and reformat the paragaph.
* options: fix a flags fieldwm42020-09-041-2/+2
|
* ao_alsa: make partial writes an error messagewm42020-09-031-2/+2
| | | | And I think "partial write" is easier to understand than "short write".
* audio: fix stream-silence with push AOs (somewhat)wm42020-09-032-5/+15
| | | | | | | | | | | | | | | | | | | | | | | | --audio-stream-silence is a shitty feature compensating for awful consumer garbage, that mutes PCM at first to check whether it's compressed audio, using formats advocated and owned by malicious patent troll companies (who spend more money on their lawyers than paying any technicians), wrapped in a wasteful way to make it constant bitrate using a standard whose text is not freely available, and only rude users want it. This feature has been carelessly broken, because it's complicated and stupid. What would Jesus do? If not getting an aneurysm, or pushing over tables with expensive A/V receivers on top of them, he'd probably fix the feature. So let's take inspiration from Jesus Christ himself, and do something as dumb as wasting some of our limited lifetime on this incredibly stupid fucking shit. This is tricky, because state changes like end-of-audio are supposed to be driven by the AO driver, while playing silence precludes this. But it seems code paths for "untimed" AOs can be reused. But there are still problems. For example, underruns will just happen normally (and stop audio streaming), because we don't have a separate heuristic to check whether the buffer is "low enough" (as a consequence of a network stall, but before the audio output itself underruns).
* encode: propagate errors to exit status properlywm42020-09-032-1/+7
| | | | | Don't just let mpv CLI return 0 (success) as exit status if encoding failed somehow.
* ao_lavc: slightly simplify filter usewm42020-09-031-12/+12
| | | | | | Create a central function which pumps data through the filter. This also might fix bogus use of the filter API on flushing. (The filter is just used for convenience, but I guess the overall result is still simpler.)
* client API: inactivate the opengl_cb APIwm42020-09-032-88/+13
| | | | | | | | | | The render API replaced the opengl_cb API over 2 years ago. Since then, the opengl_cb API was emulated on top of the render API. While it would probably be reasonable to emulate these APIs until they're removed in an eventual libmpv 2.0 bump, I have some non-technical reasons to disable the API now. The API stubs remain; they're needed for formal ABI compatibility.
* encode: disable unsupported media types automaticallywm42020-09-033-19/+57
| | | | | | | If you encode to e.g. an audio-only format, then video is disabled automatically. This also takes care of the very cryptic error message. It says "[vo/lavc] codec for video not found". Sort of true, but obscures the real problem if it's e.g. an audio-only format.
* encode: remove early EOF failure handlingwm42020-09-034-29/+0
| | | | | | | I don't see the point of this. Not doing it may defer an error to later. That's OK? For now, it seems better to reduce the encoding internal API. If someone can demonstrate that this is needed, I might reimplement it in a different way.
* audio: slightly simplify audio_start_ao()wm42020-09-031-10/+4
| | | | Get rid of an indirection; no behavior change.
* audio: reduce excessive logging of delayed audio startwm42020-09-032-2/+9
| | | | | | | Since this is a messy and fragile mechanism, I want it logged (even if it's somewhat in conflict with the verbose logging policy). On the other hand, it's unconditionally logged on every playloop iteration. So add some nonsense to log it only on progress.
* ao_alsa: log more information on short writeswm42020-09-021-2/+4
|
* audio: do not show audio draining message when it does not make sensewm42020-09-011-1/+3
| | | | | | Just for the redundant message. The function which is called here, ao_drain(), does not care in which state it is called, and already handled this gracefully.
* audio: do not wake up player when waiting for audio state and pausedwm42020-09-011-1/+2
| | | | Bullshit.
* audio: fix AVFrame allocation (crash with opus encoding)wm42020-09-011-0/+2
| | | | | | | | | | | | AVFrame doesn't have public code for pool allocation, so mpv does it manually. AVFrame allocation is very tricky, so we added a bug. This crashed with libopus encoding, but not some other audio codecs, because the libopus libavcodec wrapper accesses AVFrame.data. Most code tries to avoid accessing AVFrame.data and uses AVFrame.extended_data, because using the former would subtly corrupt memory on more than 8 channels. The fact that this problem manifested only now shows that most AVFrame consuming FFmpeg code indeed uses extended_data for audio.
* DOCS/interface-changes: remove encoding mode deprecation entrywm42020-09-011-1/+0
| | | | It was undeprecated.
* player/playloop.c: reorder included headers per contribute.mdLeo Izen2020-08-311-17/+14
| | | | | This commit sorts the included headers alphabetically and puts them in sections, as described by DOCS/contribute.md.
* ao_openal: restore working condition with new push APILAGonauta2020-08-311-8/+10
|
* ao: remove unused fieldwm42020-08-311-1/+0
|
* audio: fix inefficient behavior with ao_alsa, remove period_size fieldwm42020-08-297-24/+13
| | | | | | | | | | | | | | | | | | | | It is now the AO's responsibility to handle period size alignment. The ao->period_size alignment field is unused as of the recent audio refactor commit. Remove it. It turns out that ao_alsa shows extremely inefficient behavior as a consequence of the removal of period size aligned writes in the mentioned refactor commit. This is because it could get into a state where it repeatedly wrote single samples (as small as 1 sample), and starved the rest of the player as a consequence. Too bad. Explicitly align the size in ao_alsa. Other AOs, which need this, should do the same. One reason why it broke so badly with ao_alsa was that it retried the write() even if all reported space could be written. So stop doing that too. Retry the write only if we somehow wrote less. I'm not sure about ao_pulse.
* encode: undeprecatewm42020-08-291-2/+1
| | | | I guess the audio timestamp corruption problem is probably solved now.
* ring: remove thiswm42020-08-293-240/+0
| | | | | The code is OK, and it could be restored if it's needed again. But it is unused now, so remove it.
* audio_buffer: remove thiswm42020-08-293-200/+0
| | | | | | Unused, was terrible garbage. It was (or at least its implementation was) always a make-shift solution, and just gross bullshit. It is unused now, so delete it.
* audio: refactor how data is passed to AOwm42020-08-2912-768/+638
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces the two buffers (ao_chain.ao_buffer in the core, and buffer_state.buffers in the AO) with a single queue. Instead of having a byte based buffer, the queue is simply a list of audio frames, as output by the decoder. This should make dataflow simpler and reduce copying. It also attempts to simplify fill_audio_out_buffers(), the function I always hated most, because it's full of subtle and buggy logic. Unfortunately, I got assaulted by corner cases, dumb features (attempt at seamless looping, really?), and other crap, so it got pretty complicated again. fill_audio_out_buffers() is still full of subtle and buggy logic. Maybe it got worse. On the other hand, maybe there really is some progress. Who knows. Originally, the data flow parts was meant to be in f_output_chain, but due to tricky interactions with the playloop code, it's now in the dummy filter in audio.c. At least this improves the way the audio PTS is passed to the encoder in encoding mode. Now it attempts to pass frames directly, along with the pts, which should minimize timestamp problems. But to be honest, encoder mode is one big kludge that shouldn't exist in this way. This commit should be considered pre-alpha code. There are lots of bugs still hiding.
* DOCS: fix minor issue on the --video-latency-hacks explanationChris Varenhorst2020-08-281-2/+2
|
* Update compile-windows.mdcrackself2020-08-281-1/+1
| | | fix lua5.1-5.2 support with luajit (mxe default upstream lua5.3 )
* manpage: reorder sentenceGuido Cella2020-08-281-3/+3
|
* f_async_queue: add various helper functionswm42020-08-282-2/+105
| | | | | Shouldn't change the behavior if not used. Will probably be used in a later commit.
* f_async_queue: don't count EOF frames as sampleswm42020-08-282-1/+4
| | | | That's dumb.
* f_async_queue: change reset behaviorwm42020-08-282-3/+15
| | | | | | | | | | | | | | | | Do not make resetting the "access" filters reset the queue itself. This is more flexible, and will be used in a later commit. Also, if the queue is not in the reset state while the input access filter is reset, make it immediately request data again. This is more consistent, because it'll enter the state it "should" be, rather when the filter's process function is called at an (essentially) random point in the future. This means the filter graph will resume work on its own if the queue was not reset before filter reset. This could affect the only current user of f_async_queue, the code for the --vd-queue-enable/--ad-queue-enable feature in f_decoder_wrapper. But it looks like this already uses it in a compatible way.
* filter: add filter priority thingwm42020-08-282-6/+31
| | | | | | | This is a kind of bad hack (with bad implementation) to paint over other problems of the filter system. The main problem is that some filters might be left with pending frames if the filter runner is "paused", which we don't want. To be used in a later commit.
* manpage: slightly improve property list notewm42020-08-281-3/+4
|
* sd_ass: replace deprecated ASS_OVERRIDE_BIT_FONT_SIZEOneric2020-08-282-5/+3
| | | | This requires a slightly more recent libass than before
* osd_libass: don't use deprecated ass_set_aspect_ratioOneric2020-08-281-2/+2
|
* f_demux_in: log EOF "recovery"wm42020-08-271-0/+2
| | | | For debugging.
* f_decoder_wrapper: pass through EOF after EOFwm42020-08-272-0/+8
| | | | | | | | | It's relevant in some obscure corner cases (EDL file that has a segment without audio). Didn't test what's actually going on (is ad_lavc.c behaving wrong? is libavcodec behaving wrong or in an unexpected way? is lavc_process wrong?) and just patched it over with some bullshit, so the fix might be too complicated, and could be reworked at some later point. This sure is a real data flow fuckmess.
* player: fix video paused condition on VO creationwm42020-08-273-2/+8
| | | | | Doesn't take paused_for_cache into account. For consistency; unlikely to matter at all in practice.
* filter: add a helperwm42020-08-272-0/+8
| | | | | Not used yet; probably will, just dumping this to get it out of my sight.
* audio: clarify set_pause() documentationwm42020-08-271-0/+1
|
* audio: adjust frame clipping for spdif formatswm42020-08-271-2/+4
| | | | | | Allow mp_aframe_clip_timestamps() to discard a spdif frame if it's entirely out of the timestamp range. Just a minor thing that might make handling these dumb formats easier.
* audio: remove unused ring.h includeswm42020-08-272-2/+0
| | | | | From what I can tell, this has been copy-pasted from times when ao_coreaudio still used its own ringbuffer, instead of the common code.
* player: fix swapped debug outputwm42020-08-271-2/+2
| | | | Such failure.
* vo_gpu: EGL: fix transparency on X11/EGL/Mesawm42020-08-272-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | Transparent windows on X11/EGL/native Mesa GL didn't work for various reasons. From what I remember, the current code did work with nvidia at least. Mesa has made attempts to fix this, but they never really made it in. But it turns out you can make EGL/Mesa list the EGLConfigs that use X11 RGBA visuals, and context_x11egl.c contains code that explicitly selects them if alpha is requested (see pick_xrgba_config()). The reason EGL/Mesa did not list them (and thus breaking transparency) is because we requested a EGL_ALPHA_SIZE != 0 if alpha is requested. But the transparent EGLConfigs use EGL_ALPHA_SIZE == 0. That's because EGL doesn't actually support the concept of transparent windows; the alpha size parameter is something else (memory rendering without FBOs or something, I don't care enough to look up the real reasons). This still won't work on Wayland. Every EGL backend needs platform specific code. (Good job, EGL, such an awesome platform independent standard.) Fixes: #6590
* vo_gpu: EGL: slightly better debug logging of EGL configswm42020-08-271-1/+2
|
* ao/pulse: create the stream corkedsfan52020-08-261-1/+1
| | | | | | | | | Previously get_state() would keep setting the cork status while paused, but it only does for that after underflows now. Correct this oversight by creating the stream corked for start() to uncork it at a later time. fixes #8026
* wayland: always update sbc for presentation timeDudemanguy2020-08-241-0/+1
| | | | | | | | | | | | | Oversight in b0f0be7. The user_sbc value would update but not last_sbc if no presentation events were received. This would result in an incorrect sbc_passed value (in practice, this should always be 1 since, as far I know, all wayland compositors are currently only capable of double buffering). When bring the window back into view, it would result in a single frame of very high vsync jitter. Although in most cases it was imperceptible, rarely I was able to completely break playback (i.e. constant mistimed/dropped frames). Fix this by simply incrementing last_sbc by 1 if the window is hidden. The buffer swap call did still occur. The user just didn't see it.
* Revert "demux_lavf: always give libavformat the filename when probing"wm42020-08-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 41243e7c4f98b410195397b6758f9796acd9de57. This fixes image format detection. FFmpeg has an utter called "image2", which is designed to read patterns in filenames (so you can play something like "%*.jpg" for all jpg files in the current directory). "image2" is not what we want; it's just broken with custom I/O like mpv uses it, and we don't want to "accidentally" interpret filenames as pattern. That's why mpv blacklists it. Unfortunately, "image2" is sometimes the format that FFmpeg's probe API returns as best match. Thus demux_lavf fails to detect the file type, and after some more futile attempts, we end up at demux_mf, which uses detection by file extension. (Not sure why. I guess MPlayer did that, and foudn that sufficient.) If the file extension is wrong (which happens a lot because apparently the world is full of idiots who don't manage to get the most simple things right), the image "loads", but decoding obviously fails. There's no easy way around this. The FFmpeg API has no mechanism to exclude a specific format from probing (like image2, which breaks stuff for us). Out of the 5 probe functions the API provides, none can probe a specific format or include or exclude specific formats. The main problem is that AVInputFormat.read_probe is a private symbol. FFmpeg itself has no problem opening such files. It turns out that it works, because even though image2 by itself uses detection by file extension, it uses private API to further probe the exact format. It explicitly excludes itself to prevent recursion. But fortunately, that also means that it's impossible to get the image2 format if no filename is passed to the prober. (No filename, no file extension.) Apparently we pass it in because it helps in corner cases. Until almost 3 years ago, we passed the filename only when normal probing already failed. Restore this by this revert. It makes incorrectly named files work. The revert also makes the (apparently forgotten) comment above the touched line of code true again. Yes, quite possible that this breaks some mp3s again. You can't win with FFmpeg. Thanks FFmpeg for making us fail at opening simple image files and/or the most widely used file format for audio.
* audio: remove delay debug loggingwm42020-08-232-28/+0
| | | | Some absurd useless stuff.
* wayland: simplify presentation timeDudemanguy2020-08-222-12/+10
| | | | | | | | | | | Why on earth did I ever bother with this dumb crap? If we do not have any presentation statistics, just set the relevant vo_sync_info values to -1 to disable it. It's much simpler than using mp deltas and trying to keep up with mpv's clock. This also appears to fix audio/video desynchronization if you start a video with the pause flag, move it out of view, and then unpause it. Technically harmless since the video wasn't even in view and putting back in view recovered it, but a quieter terminal is better.
* demux_mf: actually report errorswm42020-08-221-0/+6
| | | | | | Well, whatever. Only results in an error message being printed, because there is no other error reporting mechanism, and the general policy is to keep trying with the rest of the data (i.e. not report EOF).
* player: do not loop if there's nothing to loopwm42020-08-221-0/+5
| | | | | | | | | | | | | | | | | This can happen if a file contains headers only, or if decoding of all data failed, and such. Interestingly, it also happened when doing "mpv --loop emptyfile.png", because demux_mf still detects file formats by file extension. In this situation, the player burned a lot of CPU by restarting playback after doing nothing. Although such "degenerate" behavior can't be avoided in all situations (what if you loop a file with 1 audio sample?), detecting this seems to make sense. For now, this actually decrements the loop count by 1, and then errors out with a warning. Works for --loop and --ab-loop, while --loop-playlist already avoids this situation with an existing mechanism.
* options: do not accept ":" as separator anymore in key/value listswm42020-08-223-1/+10
| | | | | | | | | | | | | | | | | | Accepting ":" in addition to "," seems confusing and dumb. It only causing problems when you want to pass a value that contains ":". Remove support for ":", it is now treated like any other normal character. This affects all options that are listed as "Key/value list" in the option list. It's possible that this breaks for someone who happened to use ":" as separator. But this was undocumented, and never recommended. Originally, the option treated many other characters in a special way, but this was changed in commit a3d561f950e74fe. I'm, not sure why ":" was explicitly included. Maybe because -the absurd -vf/--af syntax uses ":" as list separator. But "," was always recommended and used in examples for key/value options. Fixes: #8021 (if you consider it a bug)
* cocoa-cb: force layer update on resizeder richter2020-08-221-1/+1
| | | | | | | | this fixes some race condition where the content of the layer wasn't updated because the size didn't changed and the layer was already marked as updated. just force an update on reconfig. Fixes #7989
* mac: add icc profile and ambient light sensor supportder richter2020-08-221-6/+30
| | | | | | this is preparation for new backends. currently this is done via the libmpv API but for future new new VOs not based on libmpv we need these VOCTRL events.
* mac: use config cache und wakeup for mac option runtime changesder richter2020-08-225-60/+72
| | | | | | | | remove the libmpv observer for the macOS specific options and use a config cache + change callback for runtime changes. this is also a preparation for new backends and generalises even more, since libmpv functions can't and shouldn't be used in usual vo backends. for feature parity the config cache is used.
* mac: make ontop level runtime changeableder richter2020-08-221-1/+2
| | | | | | this was requested on an old issue, but the comment has since been deleted. i though it was useful enough to add it. it's also just a one line change.
* mac: properly guard and unwrap an optional valueder richter2020-08-221-8/+12
| | | | | i don't know what i was thinking there, but force unwrapping is a very bad idea.
* cocoa-cb: generalisation of backend independent partsder richter2020-08-2211-566/+741
| | | | | | | | | | | | | move all backend independent code parts in their own folder and files, to simplify adding new backends. the goal is to only extend one class and add the backend dependent parts there. usually only the (un)init, config and related parts need to be implemented per backend. furthermore all needed windowing and related events are propagated and can be overwritten. the other backend dependent part is usually the surface for rendering, for example the opengl oder metal layer. in the best case a new backend can be added with only a few hundred lines.
* client API: note about libswscale corrupting memorywm42020-08-201-1/+10
| | | | | | The software rendering API makes libswscale directly write into supplied user memory. As such, weird memory corruption bugs on non-optimal buffer configurations are exposed to the user.
* wayland: conditionally commit surface on resizeDudemanguy2020-08-203-2/+10
| | | | | | | | | | | | | | | | | | | | | It was possible for sway to get incorrectly sized borders if you resized the mpv window in a creative manner (e.g. open a video in a non-floating mode, set window scale to 2, then float it and witness wrong border sizes). This is possibly a sway bug (Plasma doesn't have these border issues at least), but there's a reasonable workaround for this. The reason for the incorrect border size is because it is possible for mpv to ignore the width/height from the toplevel listener and set its own size. This new size can differ from what sway/wlroots believes the size is which is what causes the sever side decorations to be drawn on incorrect dimensions. A simple trick is to just explicitly commit the surface after a resize is performed. This is only done if mpv is not fullscreened or maximized since we always obey the compositor widths/heights in those cases. Sending the commit signals the compositor of the new change in the surface and thus sway/wlroots updates its internal coordinates appropriately and borders are no longer broken.
* player: add --subs-with-matching-audio optionrcombs2020-08-196-9/+40
| | | | | | | | | This allows users to control whether full dialogue subtitles are displayed with an audio track already in their preferred subtitle language. Additionally, this improves handling for the forced flag, automatically selecting between forced and unforced subtitle streams based on the user's settings and the selected audio.
* wayland: refactor geometry/window handlingDudemanguy2020-08-202-104/+112
| | | | | | | | | | | | | | | | | | | | | | | | | The original goal was to simplify all this logic to make it less fragile and breaky. Unfortunately, that didn't exactly happen and things might actually be more complicated in some ways (well in other ways it's simplier). There's a lot of negotiation back and forth between the client and the compositor regarding sizes. The client (aka mpv) can do a resize on its own. But also the compositor can request its own resize (which we should be nice and listen to of course). The older method had a lot of breakfalls/edgecases that were gradually patched up as time went on, but that approach is really fragile. This refactor should, hopefully, be on a more solid foundation. Don't call any of the xdg toplevel state changing functions (fullscreen, maximized, etc.) directly. Use the toggle wrapper functions. These signal that the state was changed which is later handled in the toplevel listener. Introduce a new vdparams variable that stores the actual dimensions of the video. This does create some new (but neccesary) complexity. wl->vdparams stores what the actual dimensions of the video are (according to mpv). wl->window_size stores the last size of the window (so it includes any manual resizes for instance). wl->geometry is the actual size of the output that gets displayed on the screen.
* stream: Implement slice:// for reading slices of streamsMohammad AlSaleh2020-08-194-0/+200
| | | | | | | | | | | | | | | | Add support for reading a byte range from a stream via the `slice://` protocol. Syntax is `slice://start[-end]@URL` where end is a maximum (read until end or eof). Size suffixes support in `m_option` is reused so they can be used with start/end. This can be very useful with e.g. large MPEGTS streams with corruption or time-stamp jumps or other issues in them. Signed-off-by: Mohammad AlSaleh <CE.Mohammad.AlSaleh@gmail.com>
* wayland: reset geometry on reconfig if fullscreenDudemanguy2020-08-181-4/+10
| | | | Fixes #8014.
* wayland: soften GNOME warningDudemanguy2020-08-172-8/+1
| | | | | | | | | | | | | | | | | | | We've had some serious issues with GNOME in the past, but since then their compositor has undergone some major internal improvements. The most severe one [1], random vsync spikes and mistimed frames, can no longer be reproduced by the original author of the issue. There are some minor UI-related things (lack of window decorations for instance since there is no xdg-decoration support), but users don't seem to complain about that too much and they aren't revelant to playback. 3.38 isn't out quite yet, but that should also fix playback issues when on a multimonitor setup (the fix is in the master branch at the moment). In terms of playback, the only real concerning issue is the lack of idle inhibit so a warning is still displayed. But GNOME has their own workaround that users can use for that so if anyone happens to complain, we can just point them to that. [1] https://gitlab.gnome.org/GNOME/mutter/-/issues/957
* wayland: don't rely on presentation discardedDudemanguy2020-08-164-10/+4
| | | | | | | | | | | | | When using presentation time, we have to be sure to update the ust when no presentation events are received to make sure playback is still smooth and in sync. Part of the recent presentation time refactor was to use the presentation discarded event to signal that the window is hidden. Evidently, this doesn't work the same everywhere for whatever reason (drivers?? hardware??) and at least one user experienced issues with playback getting out of sync since (presumably) the discarded event didn't occur when hiding the window. Instead, let's just go back to the old way of checking if the last_ust is equal to the ust value of the last member in the wayland sync queue. Fixes #8010.
* wayland: refactor presentation timeDudemanguy2020-08-164-61/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The motivation for this change was a segfault caused by e107342 which has complicated reasons for occuring (i.e. I'm not 100% sure but I think it is a really weird race). The major part of this commit is moving the initialization of presentation listener to the frame_callback function. Calling it in swap_buffers worked fine but in practice it meant a lot of meaningless function calls if a window was hidden (the presentation would just be immediately discarded). By calling it in frame_callback, we ensure the listener is only created when it is possible to receive a presentation event. Of course calling the presentation listener in feedback_presented or feedback_discarded was considered, but ultimately these events are too slow. Receiving the ust/msc/sbc triplet here and then passing it to mpv results in higher vsync judder since there is (likely) not enough time before the next pageflip. By design, the frame callback is meant to give us as much time as possible before the next repaint so calling it here is probably optimal. Additionally, we can make better use of the feedback_discarded event. The wp_presentation_feedback should not be destroyed here. It will be taken care of either when we get feedback again or when the player quits. Instead what we can do is set a bool that tells wayland_sync_swap to update itself based on mp_time delta. In practice, the result is not any different than before, but it should be more understandable what is going on now. Of course, the segfault mentioned at the beginning is fixed with this as well.
* DOCS/vo.rst: TCT: add note on interleaved outputAvi Halachmi (:avih)2020-08-161-2/+7
|
* win32: scripting utils.get_env_list(): use UTF-8Avi Halachmi (:avih)2020-08-164-4/+15
| | | | | | | | | | | | | | | | lua/js utils.get_env_list() uses `environ' which was ANSI, thus it broke any unicode names/values. mpv already has an internal utf8_environ for win32, but it's used only at the getenv(..) wrapper and not exposed in itself, and also it has lazy initialization - on first getenv() call. Now `environ' maps to a function which ensures initialization while keeping it an l-value (like posix expects). The cost of this fuglyness is that files should include osdep/io.h (which now declares environ as extern) rather than declaring it themselves, or else the build will break on mingw.
* lua: pass strings with embedded zeros as byte arrayswm42020-08-161-3/+14
| | | | | | | | | | This was a vague idea how to handle passing byte arrays from Lua to the mpv command interface in a somewhat reasonable way. The idea was cancelled, but leave the Lua part of it, since it might get useful later, and prevents passing (and silently cutting off) such byte strings. Barely tested, let's say not tested at all.
* command: extend subprocess command stdin, change behaviorwm42020-08-167-6/+110
| | | | | | | | | | | | | | | Make it possible to feed a string to stdin of a subprocess. Out of laziness, it can't be an arbitrary byte string. (Would require adding an option type that takes in a Lua byte string.) Do not set stdin of a subprocess to fd 0 (i.e. mpv's stdin) anymore, because it makes things more consistent. Enabling stdin didn't make too much sense in the first place, so this behavior change seems justifiable. win32 support missing. Fixes: #8003
* demux_mkv: warn against some other aspects of mismatching codec datawm42020-08-161-0/+5
| | | | | | Such files violate the specification. Unfortunately, I could not test whether it really works correctly, since I don't have a sample at hand that is not broken in this regard.
* command: export alpha type in format propertieswm42020-08-152-0/+18
|
* wayland: destroy presentation feedback on uninitDudemanguy2020-08-141-0/+3
| | | | | | | Nothing major but it's technically possible for the wp_presentation_feedback struct to still be allocated when quitting the player. Just destroy it if it exists like all of the other wayland objects.
* wayland: actually resize videos in a playlistDudemanguy2020-08-141-1/+1
| | | | | | | In a playlist of videos with different sizes, going to the next video would not properly resize the window. This actually broke way back in 7170910 (oops), but somehow nobody ever complained. The fix is simple. If a window isn't maximized, be sure to set the window geometry again.
* sd_ass: remove debug printwm42020-08-141-1/+0
| | | | It's not even spelled correctly.
* wayland: expose wayland-app-id as a user optionDudemanguy2020-08-144-0/+20
| | | | | This is extremely similar to x11's WM_CLASS. This commit allows users to set mpv's app-id at runtime for any of the wayland backends.
* wayland: tweak xdg_surface creationDudemanguy2020-08-141-5/+4
| | | | | | | | | | | | Just some small changes when creating the xdg_surface. Don't set the toplevel title (or app id) in create_xdg_surface anymore because it's entirely pointless. Also make it possible for create_xdg_surface to return something other than 0 so the error checking is somewhat meaningful. It's not really clear if these xdg functions can even fail in the first place (perhaps some weird proxy marshalling crap could possibly go wrong somehow), but it can't hurt. Note that all app id stuff has been removed (temporarily) in this commit. See the next commit which adds it back in.
* command: fix current-tracks property notificationwm42020-08-131-0/+1
| | | | Also for track-list, because it contains the "selected" flag.
* sub: add application/font-sfnt to the list of font mime typesWessel Dankers2020-08-131-0/+1
| | | | | | | According to both file(1) and https://www.iana.org/assignments/media-types/application/font-sfnt application/font-sfnt is also a valid mime type for (at least some) .ttf files.
* client API: fix misleading remarkAlcaro2020-08-131-2/+1
|
* manpage: document a couple of wayland optionsDudemanguy2020-08-121-0/+9
| | | | | --wayland-edge-pixels-pointer and --wayland-edge-pixels-touch were both left out of the manual.
* ytdl_hook: sort subtitle list by languagewm42020-08-121-1/+7
| | | | | | The subtitle list is returned in randomized order, because a table (i.e. JSON object) is used. To make the order stable across repeated invocations, sort it by language.
* client API: fix incorrect documentation in sw rendererwm42020-08-121-4/+4
| | | | | | This was incorrect, and grossly misleading. It created the impression that the buffer is passed to mpv_render_context_create(), instead of mpv_render_context__render().
* sd_ass: fix converted subtitles pathwm42020-08-121-7/+7
| | | | Commit cda8f1613ff3 broke this.
* DOCS/contribute.md: add a CCoCwm42020-08-121-1/+4
| | | | | | | (The recommendation is to add the document to the project git root, but I'm against dumping such things into git. I'd rather replace the Copyright full text files with links and move contribute.md to the wiki than add the CCoC text as a file.)
* sub: extend range of --sub-pos optionwm42020-08-123-5/+14
| | | | | | | | | | | | Seems like this is requested all the time. It seems libass allows out of range values, but does allows the subtitle to go out of the screen at the bottom (only when moving it to the top it's "clamped"). Too bad, don't do that then. The bitmap sub rendering code on the other hand is under our control, and will not move a subtitle out of the screen. Fixes: #7986
* sd_ass: force full reinit if certain options change at runtimewm42020-08-125-34/+60
| | | | | | | | | | Options like --sub-ass-force-style and others could not be changed at runtime (the changes didn't take any effect). Fix this by using the brutal approach, and completely reinit the subtitle state when this happens. Maybe a bit clunky, but for now I'd rather not put more effort into this. Fixes: #7689
* command: add a way to access properties of a current trackwm42020-08-122-1/+69
| | | | | | Requested. Should be good for simple use cases. "sub2" is technically inconsistent (since the option is called --secondary-sid), but fuck the consistent name.
* TOOLS/file2string: change to python3wm42020-08-121-1/+1
| | | | | | The same was done to matroska.py before, so at least it's consistent. Doesn't matter for waf, because it imports this script (rather than executing it).
* win32: request the UTF-8 code page for Windows APIsJames Ross-Gowan2020-08-081-0/+1
| | | | | | | | | | | | | | This sets the activeCodePage property in the manifest, which forces the ANSI code page to be UTF-8 in Windows 10 1903 and up. It shouldn't make a difference for mpv itself, since mpv already uses the wide-char APIs for most functions, however some of mpv's dependencies, such as Lua, rely on the ANSI codepage. Hence this change enables support for Unicode file names in Lua's I/O library. Thanks @avih for finding this property. See: https://docs.microsoft.com/en-us/windows/uwp/design/globalizing/use-utf8-code-page
* ao/lavc: add channels and channel_layout to AVFrameekisu2020-08-071-0/+2
| | | | | | FFmpeg expects those fields to be set on the AVFrame when encoding audio, not doing so will cause the avcodec_send_frame call to return EINVAL (at least in recent builds).
* auto_profiles: unapply conditional profiles if declaredwm42020-08-072-19/+37
| | | | | | Uses the mechanism introduced in the previous commit. The hope was to make auto-profiles easier to use, and to get rid of the need for manually created inverse profiles. Not sure if the end result is useful.
* options: add some way to more or less "unapply" profileswm42020-08-076-61/+212
| | | | | | | | | | | | | | | | | | | | | | | | Make it possible to restore from profiles by backing up the option values before profile application. This is sort of like unapplying a profile. Since there might be multiple ways to do this, a profile needs to explicitly provide the "profile-restore" option, which specifies how exactly this should be done. This is a big mess. There is not natural way to do this. Profile application is "destructive" and simply changes the values of the options. Maybe one could argue that the option system should have hierarchical "overlays" of profiles instead, where unset options will use the value of the lower profiles. Options set interactively by the user would be the top profile. Default values would be in the lowest profile. You could unapply a profile by simply removing it from this overlay stack. But uh, let's not, so here's something stupid. It reuses some code used for file local options to reduce code size. At least the overlay idea would still be possible in theory, and could be added as another profile-restore mode. This is used by the following commit.
* js: hooks: allow deferred continuation (match d0ab562b)Avi Halachmi (:avih)2020-08-072-3/+10
| | | | | | | | | | The callback now gets an object argument with defer/cont functions. Like the lua code, the behavior is that each hook event allows at most one continue, but nothing enforces the order of continuations if more hook events arrive before prior ones were continued - which is possible now with the defer option, but wasn't possible before (continuation was synchronous from the hook event handler).
* auto_profiles: register hooks for more synchronous profile applicationwm42020-08-051-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | The property observation mechanism is fairly asynchronous to the player core, and Lua scripts also are (they run in a separate thread). This may sometimes lead to profiles being applied when it's too load. For example, you may want to change network options depending on the input URL - but most of these options would have to be set before the HTTP access is made. But it could happen that the profile, and thus the option, was applied at an slightly but arbitrary later time. This is generally not fixable. But for the most important use-cases, such as applying changes before media opening or playback initialization, we can use some of the defined hooks. Hooks make it synchronous again, by allowing API users (such as scripts) to block the core because it continues with loading. For this we simply don't continue a given hook, until we receive an idle event, and have applied all changes. The idle event is in general used to wait for property change notifications to settle down. Some of this relies on the subtle ways guarantees are (maybe) given. See commit ba70b150fbe for the messy details. I'm not quite sure whether it actually works, because I can't be bothered to read and understand my bullshit from half a year ago. Should provide at least some improvement, though.
* lua: make hook processing more flexiblewm42020-08-052-4/+41
| | | | | | | This can now opt to not continue a hook after the hook callback returns. This makes it easier for scripts, and may make it unnecessary to run reentrant event loops etc. for scripts that want to wait before continuing while still running the event loop.
* auto_profiles: add this scriptwm42020-08-0513-7/+326
| | | | | | | | | | | | | | | | | | | | | This is taken from a somewhat older proof-of-concept script. The basic idea, and most of the implementation, is still the same. The way the profiles are actually defined changed. I still feel bad about this being a Lua script, and running user expressions as Lua code in a vaguely defined environment, but I guess as far as balance of effort/maintenance/results goes, this is fine. It's a bit bloated (the Lua scripting state is at least 150KB or so in total), so in order to enable this by default, I decided it should unload itself by default if no auto-profiles are used. (And currently, it does not actually rescan the profile list if a new config file is loaded some time later, so the script would do nothing anyway if no auto profiles were defined.) This still requires defining inverse profiles for "unapplying" a profile. Also this is still somewhat racy. Both will probably be alleviated to some degree in the future.
* manpage: clarify requirements for boxvideoDudemanguy2020-08-041-1/+2
| | | | The osc must not auto-hide for this option to do anything.
* wayland: don't set mouse pos on state changeDudemanguy2020-08-022-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Sway 1.5 started sending more pointer motion events to mpv which broke the autohiding behavior. The cursor would appear again if you fullscreened. Sway had a good reason to do this because certain applications had inconsistencies between hardware cursor and software cursor without rebasing on state changes[1]. So mpv needs to take this special case into consideration. Initially, simply checking mouse coordinates for changes was considered, but this doesn't work. All coordinates are surface-local in wayland so something can appear to move in the local coordinate space but not globally. You're not allowed to know global mouse coordinates in wayland, and we don't care about local coordinate changes in mpv so this approach isn't viable. Instead, let's just keep track of a local state change. If the toplevel surface changes in some way (fullscreen, maximized, etc.), then just set a bool that lets us ignore the mp_input_set_mouse_pos function. This keeps the cursor from appearing simply because the state was changed (i.e. fullscreening). For compositors that don't send pointer motion events on a state change, this does technically mean that the initial mp_input_set_mouse_pos is never set. In practice, this isn't a noticeable difference though because moving a mouse generates a ton of motion events so you'll immediately see it on the second motion event. [1] https://github.com/swaywm/sway/issues/5594
* stats: fix crash when aspect ratio is unavailableEva2020-08-031-1/+3
| | | When switching between files it's possible that r["aspect"] returns nil, resulting in a crash.
* ytdl_hook: fix typo in unexpected error messageDerek Guenther2020-08-011-1/+1
|
* wayland: avoid potential deadlocksDudemanguy2020-07-311-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wl_display_dispatch is dangerous because it will block forever if the event queue is empty. Any direct calls to this function should just be replaced with wl_display_dispatch_pending which accomplishes the same thing for mpv's purposes without any chance of blocking. The other potential trap is wl_display_roundtrip. It can internally call wl_display_dispatch which in certain circumstances could potentially block. There are cases where we need the server to finish processing client requests before doing anything else so this can not be cleanly avoided. The dangerous call is the usage of wl_display_roundtrip in vo_wayland_wait_frame. In the majority of cases, this shouldn't be a problem because the previous wl_display_read_events should always queue up some events on the fd for wl_display_roundtrip to send. However, the compositor could potentially send us an error in the display queue that could lead to bad behavior when wl_display_roundtrip is called. The wl_display_roundtrip can't be removed because we are relying on its semi-blocking capabilities, but the logic can be slightly adjusted to be safer. The obvious thing to do is to make sure we check the pollfd for any errors. If one is returned, then we call wl_display_cancel_read and try again. The less obvious trick is to call wl_display_dispatch_pending and move wl_display_roundtrip outside of the blocking + timeout loop. This change has some subtle but important differences. Previously, vo_wayland_wait_frame would read an event and wait on the server to process it one-by-one. With this change, the events are dispatched as soon as possible to the server and then we wait on all of those (potentially multiple) events to be processed after we have either received frame callback or the loop times out. After that is done, we can then check for if there are any errors on the display. If it's all clear, we can run wl_display_roundtrip without any worries. If some error happens, then don't execute the function at all.
* travis: update macOS image from 10.14 to 10.15der richter2020-07-311-1/+1
|
* travis: make macOS builds fasterder richter2020-07-311-28/+18
| | | | | | | | | | | | | | the problem here is that with time, and because the macOS VMs don't get updated, the homebrew update is getting longer since more and more changes have to be pulled. to prevent that, we cache the homebrew installation folder after the update. that way we don't have to update several months worth of updates every build. for the legacy build we have to check put master again to actually cache the newest homebrew version. additionally to that, we also do the same as on the legacy build, with the addition of not removing all installed formulas but only the ones we don't need. so we don't need to reinstall those.
* travis: fix macOS 10.12 legacy buildder richter2020-07-311-0/+1
| | | | | | | | | just remove all pre installed formulas, since we don't need the majority of it. after that install what we need. this also fixes the brew update of those formulas where the source links were broken like popt. this also helps when the build times out due to building some formulas from source that are not dependencies we need.
* wayland: correctly signal the end of drag-and-dropDudemanguy2020-07-291-1/+1
| | | | | | | | | | | | Previously, the compositor was signaled that a drag-and-drop ended with wl_data_offer_finish in check_dnd_fd. This is, however, erroneous because it is outside of the data_device_listener and in some cases caused errors with certain compositors. check_dnd_fd itself does not need to know or care about anything that happens in wayland. It just needs to read data from an fd. The simple fix is to just always signal the end of a drag-and-drop in data_device_handle_drop. check_dnd_fd can free memory and close the fd later, but it should not talk to the compositor. Fixes #7954.
* wayland: fix a potential race in wait_eventsDudemanguy2020-07-291-4/+7
| | | | | | | The read of the wayland display fd in vo_wayland_wait_events was incorrect and technically vulnerable to race conditions. The correct usage as per the client api is to use wl_display_prepare_read as well as wl_display_read_events.
* af_scaletempo2: fix bug where speed was not setDorian Rudolph2020-07-271-1/+0
| | | | | | the --speed parameter did not work with mpv --no-config whatever.mp3 --video=no --speed=2 --af=scaletempo2 (https://github.com/mpv-player/mpv/pull/7865#issuecomment-664243401)
* af_scaletempo2: M_PI is always definedwm42020-07-271-4/+0
| | | | I forgot why/how (C99?), but other code also uses it.
* audio: add scaletempo2 filter based on chromiumDorian Rudolph2020-07-277-0/+1121
| | | | | | | | scaletempo2 is a new audio filter for playing back audio at modified speed and is based on chromium commit 51ed77e3f37a9a9b80d6d0a8259e84a8ca635259. It sounds subjectively better than the existing implementions scaletempo and rubberband.
* js: add mp.utils.get_env_list() (match 0e7f53a5, 9301cb78)Avi Halachmi (:avih)2020-07-262-0/+15
|
* lua: change mp.get_env_list() to utils.get_env_list()Avi Halachmi (:avih)2020-07-261-1/+1
| | | | | It's documented (twice) at utils, and logically it's the correct place for it.
* stats: fix single invocation keybindingssfan52020-07-211-2/+5
|
* manpage: drop --sdl-bufcnt after 346c687d5ab2Jan Beich2020-07-211-4/+0
|
* external_files: add .pgs subtitle extensionEva2020-07-211-1/+1
|
* subprocess-win: update to mp_subprocess2James Ross-Gowan2020-07-205-141/+399
| | | | | | | | | | | | | | | | | | | This fixes the "run" and "subprocess" commands on Windows, including youtube-dl support. Unix-like FD inheritance is emulated on Windows by using an undocumented data structure[1] that gets passed to the newly created process in STARTUPINFO.lpReserved2. It consists of two sparse arrays listing the HANDLE and internal CRT flags corresponding to each FD. This structure is used and understood primarily by MSVCRT, but there are other runtimes and frameworks that can write it, like libuv. The code for creating asynchronous "anonymous" pipes in Windows has been enhanced and moved into windows_utils.c. This is mainly an artifact of an unfinished future change to support anonymous IPC clients in Windows. Right now, it's still only used in subprocess-win.c [1]: https://www.catch22.net/tuts/undocumented-createprocess
* manpage: add named arguments "subprocess" examplewm42020-07-201-5/+21
| | | | At the same time, this is an example for a command with named arguments.
* client API: comment about signal handlerswm42020-07-201-0/+2
| | | | | | | | | | | | Sharing a process sure is hard in POSIX. The rationale is that you'd have to handle EINTR on every single blocking syscall. stream_file.c does not seem to handle it on read() calls. It appears that on most modern systems, this can happen only if you call sigaction(), and incompetently forget to add SA_RESTART. signal() usually adds it.
* command: add another variant of revert-seekwm42020-07-202-4/+16
| | | | | | | Requested. See manpage additions. Not sure if it actually deserves to be a first class feature, rather than an external script or so. Fixes: #7913
* lua: add mp.get_env_list() functionwm42020-07-203-0/+20
| | | | | Because Lua is too stupid to provide this directly, and I sort of need it.
* command: extend subprocess commandwm42020-07-207-160/+115
| | | | | | | | | | | | | | | | | | | | Add env and detach arguments. This means the command.c code must use the "new" mp_subprocess2(). So also take this as an opportunity to clean up. win32 support gets broken by it, because it never made the switch to the newer function. The new detach parameter makes the "run" command fully redundant, but I guess we'll keep it for simplicity. But change its implementation to use mp_subprocess2() (couldn't do this earlier, because win32). Privately, I'm going to use the "env" argument to add a key binding that starts a shell with a FILE environment variable set to the currently playing file, so this is very useful to me. Note: breaks windows, so for example youtube-dl on windows will not work anymore. mp_subprocess2() has to be implemented. The old functions are gone, and subprocess-win.c is not built anymore. It will probably work on Cygwin.
* wayland: remove unused declarationDudemanguy2020-07-191-1/+0
| | | | Should have been removed in 055a490 but was forgetten.
* build: actually install the 128x128 iconsDudemanguy2020-07-191-1/+1
| | | | | mpv has generated this icon size for a while now, so go ahead and install it in the usual place like the other icon sizes.
* vo_gpu: clip highlights before tone-mappingNiklas Haas2020-07-191-4/+5
| | | | | | | | | | | | Rather than after tone-mapping. This prevents overflow when the pre-tonemapped signal contains inputs exceeding sig_peak. I also realized that with this clipping in place, post-clipping no longer needs to be done, so this isn't even particularly slower. The only two exceptions to the rule are "clip" and "linear", which relied on the post-clipping to do their tone mapping properly. Fixes #7929
* vo_gpu: vulkan: print libplacebo API verNiklas Haas2020-07-161-0/+1
| | | | | | | | This normally gets printed by libplacebo itself when initializing the context, but due to the way our code is structured (for convenience) we don't have the log hook enabled by the time this function call is relevant. So instead just print it manually as an easier work-around than restructuring the code.
* zimg: add slice threading and use it by defaultwm42020-07-154-20/+123
| | | | | | | | | | | | | | | | | | | | | | | This probably makes it much faster (I wouldn't know, I didn't run any benchmarks ). Seems to work as well (although I'm not sure, it's not like I'd perform rigorous tests). The scale_zimg test seems to mysteriously treat color in fully transparent alpha differently, which makes no sense, and isn't visible (but makes the test fail). I can't be bothered with investigating this more. What do you do with failing tests? Correct, you disable them. Or rather, you disable whatever appears to cause them to fail, which is the threading in this case. This change follows mostly the tile_example.cpp. The slice size uses a minimum of 64, which was suggested by the zimg author. Some of this commit is a bit inelegant and weird, such as recomputing the scale factor for every slice, or the way slice_h is managed. Too lazy to make this more elegant. zimg git had a regressio around active_region (which is needed by the slicing), which was fixed in commit 83071706b2e6bc634. Apparently, the bug was never released, so just add a warning to the manpage.
* zimg: refactor (move around fields)wm42020-07-152-78/+106
| | | | | | | | The intention is to add slice-threading to the wrapper. For that purpose, move all zimg related state to a new struct mp_zimg_state. There is now an array of instances of this struct. The intention is to have one instance for each thread. As of this commit, this is hardcoded to 1 thread; the following commit extends this.
* osd_libass: set ScaledBorderAndShadowOleg Oshmyan2020-07-151-0/+1
| | | | | | | | | | | libass recently switched the default from 1 to 0 for compatibility with ASS scripts that rely on the historical/VSFilter default of 0. libass does attempt to detect and avoid breaking scripts that rely on the historic libass-only default of 1, but it doesn't cover tracks created directly through the API, so set the header explicitly. Fixes https://github.com/mpv-player/mpv/issues/7900.
* vo_gpu: hwdec_vaapi: handle lack of object size with AMD driversPhilip Langdale2020-07-141-0/+26
| | | | | | | | | | | | | It turns out that the AMD driver doesn't bother to set the size field in the descriptor for an exported VA surface. I guess they assume the caller can always use lseek() and don't bother. So, we need to use lseek() in these situations. Modified-by: Niklas Haas <git@haasn.xyz> Guarded this behind PL_API_VER >= 88 to prevent it from exploding on older libplacebo versions, where vaapi support does not yet work properly on AMD due to lack of DRM modifiers.
* vo_gpu: hwdec_vaapi: add support for DRM format modifiersNiklas Haas2020-07-141-2/+5
| | | | | This is required to get non-corrupted textures when importing vaapi planes on AMD drivers.
* ao/pulse: fix reporting of playing statesfan52020-07-121-2/+7
| | | | | | | When get_state() corks the stream after an underrun happens priv->playing is incorrectly reset to true, which can cause the player to miss the underrun entirely. Stop resetting priv->playing during corking (but not uncorking) to fix this.
* ao/pulse: flush stream on underrunsfan52020-07-121-1/+1
| | | | | | | | | | The underflow callback introduced in d27ad96 can be called when the buffer is still full, causing playback to never resume afterwards since get_state() reports free_samples == 0. Fix this by fully resetting on underrun, which flushes the stream and ensures free buffer space. fixes #7874
* cocoa-cb: fix unfs window size when toggling out of fullscreender richter2020-07-121-1/+3
| | | | | | | | | | we properly set the unfs window size on live resize end. due to a race condition in the fullscreen events, which is also a live resize, the unfs window size is incorrectly set to a fullscreen size. this happens when the end fs screen event triggers before the end of live resize one. this just adds a second condition to not be un fullscreen when updating the unfs window size.
* x11: add option to make window appear on a specific workspacewm42020-07-124-8/+24
| | | | | | | | | Mess this into the --geometry option, because I like to be irresponsible. I considered adding a separate option, but at least this allows me to defer the question how the hell this should work as property (geometry simply and inherently does not). Tested on IceWM only. Option equality test and string output not tested.
* demux_lavf: workaround reading gif from unseekable streamswm42020-07-093-1/+29
| | | | | | | FFmpeg, being the pile of trash as usual, recently broke this. Add our own trash hack to trashily workaround this shit. Fixes: #7893
* player: fix outdated commentwm42020-07-091-3/+1
|
* sws_utils: do not mutate src/dst parameterswm42020-07-081-24/+20
| | | | | | Probably did not cause any practical problems, but it sure seems unclean. sws_utils users might also rely on these fields being exactly the same as the actual input/output. It's better to avoid this.
* x11: remove terrible xdg-screensaver hackwm42020-07-084-48/+47
| | | | | | | | | | | | | | I'm tired of dealing with this frequent spawning of xdg-screensaver when debugging and what not. xdg-screensaver was never a serious tool anyway, it's more like some self-deprecating joke by FDO folks. This will affect X11 on GNOME and other DEs. I'm singling out GNOME though, because they are the ones actively sabotaging any sane technical solutions and community cooperation. I have been accused of taking it out on innocent GNOME users, while none of this will reach GNOME developers. Of course that is not the intention.
* client API: add software rendering APIwm42020-07-088-2/+315
| | | | | | | | | | | | | | | | | This can be used to make vo_libmpv render video to a memory buffer. It only adds a new backend API that takes memory surfaces. All the render API (such as frame rendering control and so on) is reused. I'm not quite convinced of the usefulness of this, and until now I always resisted providing something like this. It only seems to facilitate inefficient implementation. But whatever. Unfortunately, this duplicates the software rendering glue code yet again (like it exists in vo_x11, vo_wlshm, vo_drm, and probably more). But in theory, these could reuse this backend in the future, just like vo_gpu could reuse the render_gl API. Fixes: #7852
* path: fix broken exe-dir[/mpv] config locationsAvi Halachmi (:avih)2020-07-081-1/+1
| | | | | | | This is a regression since c3694f0, at least on Windows. Fixes #7889 Fixes #7881
* Warn if on GNOMEwm42020-07-071-0/+7
| | | | GNOME actively fights the standard we try to rely on.
* ci: add d3d11 to mingw buildsfan52020-07-012-19/+44
|
* vo_gpu: vulkan: add ability to disable eventsNiklas Haas2020-06-302-0/+10
| | | | | | | | | | | libplacebo exposes this feature already, because this particular type of bug is unusually common in practice. Simply make use of it, by exposing it as an option. Could probably also bump the libplacebo minimum version to get rid of the #if, but that would break debian oldoldstable or something. Fixes #7867.
* player: warn if both proper and compat. config directories existwm42020-06-251-2/+11
| | | | | No idea why there's logic to add them all to the search path, so "both" are used. In any case, this isn't something anyone should use.
* path: do not use old_home for win32 exe dirwm42020-06-253-1/+4
| | | | | | | | | | | | | Apparently mpv supports loading config files from the same directory as the mpv.exe. This is a fallback of some sort. It used the old_home mechanism. I want to add a warning if old_home exists, but that would always show the warning on win32. Obviously we don't want that. Add a separate exe_dir entry to deal with that. Untested, but probably works.
* path: switch back to using non-XDG config dir by defaultwm42020-06-252-30/+48
| | | | | | | | | | | | | | | | | | | | | XDG is stupid, so change back to the standard behavior. Unfortunately, most users will now have the XDG one, so we will still need to load this. (This is exactly the same problem as when XDG support was introduced, just the other way around). This should not affect any normal users. Hopefully I tested this well enough; my intention is not to torment miserable XDG fans; they can keep using their config dir if they want it. This changes behavior in two cases: - new users (now creates ~/.mpv/ instead of ~/.config/mpv/) - users which have both directories The latter case will behave subtly or obviously different, not sure. Just fix your shit. Extend the manpage with all the messy details, as far as I could reverse engineer them from the code.
* vo_gpu: fix typo in struct namesfan52020-06-241-1/+1
|
* manpage: --demuxer-seekable-cache is uselesswm42020-06-231-19/+18
| | | | | | | | | De-emphasize it, since a user should usually not use it. This _could_ be used to make the cache seekable with --cache=no, but it's better and more intuitive to use --cache=yes. As such, the only use of this is for debugging. I'm not quite sure if this should be removed entirely, but I still see some value in it (for example if you want the cache lookahead, but you're using a stream where cache seeking is somehow broken).
* ci: replace mingw build scriptssfan52020-06-222-28/+139
|
* vo_gpu: use highp float if available for GLESStephen Salerno2020-06-211-0/+5
| | | | | | Using mediump float on GLES causes problems with kernel resampling, PQ HDR, and possibly others. The issues are fixed by using highp, which is available when GL_FRAGMENT_PRECISION_HIGH is defined.
* vo_gpu: add better gamut clipping optionNiklas Haas2020-06-194-0/+21
| | | | | | See https://code.videolan.org/videolan/libplacebo/-/commit/d63eeb1ecc204 Enabled by default because I think it looks better. YMMV.
* vo_gpu: fix scaler/window validation to allow unsettingNiklas Haas2020-06-181-0/+4
| | | | | | | | | | --dscale= and --*scale-window= (i.e. an empty string) are respectively valid settings for their options (and, in fact, the defaults). This fixes the bug that it was impossible to reset e.g. tscale-window back to the default "unset" setting after setting it once. Credit goes to @CounterPillow for locating the cause of this bug.
* vo_x11: partially restore operation on bad endian systemswm42020-06-171-6/+22
| | | | | | | | | | | | | For testing in VMs I guess? This features a very broken hack that probably works. Though I didn't test the packed format case. Again, the mismatch is essentially due to big endian byte addresses decreasing as bit addresses increase, so you can't represent a bit position in a byte stream with a single address, which the mpv metadata does. OSD is broken because repack.c doesn't support big endian. You'll have to live with it.
* video: some concessions to big endian hostswm42020-06-171-8/+11
| | | | | | | | | | | | | | | | | | | | | | The recent changes to the image format metadata broke big endian, and that was intentional. Some things are inherent to little endian (like the idea to coalesce bit and byte offsets into a single bit offset), and they don't be fixed. But some obvious things can be fixed, such as marking LE vs. BE formats the right way around on BE hosts. The metadata is formally still in LE, except that if the LE/BE flag matches the host endian, the host endian can be used when accessing packed formats with bit shifts, or when computing byte aligned component byte offsets. The former may work because formats with LE/BE variants use the same bit offsets after byte swapping, the latter may work because little endian is the natural concept for addressing memory. But it will "subtly" fail to do the right thing in some cases, and code using this can't know, so have fun. Many things are broken, but this makes e.g. vo_gpu mostly work. My general opinion about BE computers is that you should get a better computer, you can get one for free from any garbage dump.
* test: update to new ffmpeg pixfmtswm42020-06-175-5/+25
| | | | | Mainly, X2RGB10BE is added. Add our own unpack test for this format. Also, swscale seems to have added support for GBRPF conversion.
* video: alias IMGFMT_RGB30 to AV_PIX_FMT_X2RGB10wm42020-06-171-0/+4
| | | | | | | IMGFMT_RGB30 was added first; FFmpeg added AV_PIX_FMT_X2RGB10 later. This is exactly the same, so treat them as such. For some reason, libswscale still seems to output incompatible data - not sure what this is about, but I'm not going to debug it.
* repack: handle endian in a more general waywm42020-06-171-6/+7
| | | | | | | | Instead of applying this only to "regular" formats, do it with all formats. For some reason, some repackers still have their own endian code. These could probably be removed, but whatever.
* img_format: fight ffmpeg pixdesc some morewm42020-06-171-28/+49
| | | | | | | | | | | | | | | | | | | | | This change attempts to fix detection of how endian swapping is to be performed. Details can be found in the code comments. It should not change anything, other than fixing handling of the X2RGB10BE ffmpeg pixel format. This format was detected incorrectly, and the component location metadata was discarded due to an internal consistency check. With this commit, it is handled correctly. At first I thought the X2RGB10BE ffmpeg pixdesc metadata was wrong, but it appears to be correct. The problem with this format is that it's the first packed RGB format that requires bit shift to access, and where the endian word size is larger than the (rounded up) component size, all while pixdesc would "require" you to perform 3 memory accesses (instead of 1), and the code tries to reverse this. It appears that trying to use the pixdesc metadata is much, much more work than just duplicating it in a saner form. To be fair, most problems are with big endian, and the mpv internal format does not care much about endian _hosts_.
* audio: don't lock ao_control for pull mode driversKevin Mitchell2020-06-171-2/+7
| | | | | | | | | | | | | The pull mode APIs were previously required to have thread-safe ao_controls. However, locks were added in b83bdd1 for parity with push mode. This introduced deadlocks in ao_wasapi. Instead, only lock ao_control for the push mode APIs. fixes #7787 See also #7832, #7811. We'll wait for feedback to see if those should also be closed.
* vo_gpu: placebo: add fallback code for stride mismatchNiklas Haas2020-06-161-12/+52
| | | | | | | | | | | | | | | For cases in which the requirements of the GPU API prevent directly uploading a texture with a given stride, we need to fix the stride manually in host memory. This incurs an extra memcpy, but there's not much we can do about it. (Even in `ra_gl` land, the driver will just hide this memcpy from the user) Note: This code could be done better. It could only copy as many texels as needed, and it could pick a stride that's a multiple of `gpu->limits.align_tex_xfer_stride` for better performance. Patches welcome (tm) Fixes #7759
* vo_gpu: add BT.2390 tone-mappingref_whiteNiklas Haas2020-06-154-7/+61
| | | | | | | | | | | | Implementation copy/pasted from: https://code.videolan.org/videolan/libplacebo/-/commit/f793fc0480f This brings mpv's tone mapping more in line with industry standard practices, for a hopefully more consistent result across the board. Note that we ignore the black point adjustment of the tone mapping entirely. In theory we could revisit this, if we ever make black point compensation part of the mpv rendering pipeline.
* vo_gpu: reinterpret SDR white levels based on ITU-R BT.2408Niklas Haas2020-06-154-9/+13
| | | | | | | | | | | | This standard says we should use a value of 203 nits instead of 100 for mapping between SDR and HDR. Code copied from https://code.videolan.org/videolan/libplacebo/-/commit/9d9164773 In particular, that commit also includes a test case to make sure the implementation doesn't break roundtrips. Relevant to #4248 and #7357.
* vo_gpu: move coherent specifier to the correct locationNiklas Haas2020-06-102-2/+2
| | | | | | | | | | glslang accepted this, perhaps erronneously, but mesa does not. It seems to be incorrect. A caveat is that this means *all* SSBOs are now coherent, but since we only use SSBOs for peak detection, that's a non-issue. (And besides, marking something as coherent when we don't perform any synchronization commands on it should be a no-op anyway) Fixes #7823
* player: make unpausing directly after seek work with --keep-open (again)wm42020-06-101-0/+3
| | | | | | | | | | | | Commit fcf0b80dc9dd3 fixed this the first time. Commit 85576f31a9cc2 "accidentally" removed this code again. The commit message justifying the removal is correct, except it doesn't take other side-effects of the state machine into account. I obviously didn't remember what exactly this was about. So add a comment explaining it this time. Just apply it again; the thing the latter commit fixed still works. Fixes: #7819
* audio: require certain AOs to set device_bufferwm42020-06-092-3/+3
| | | | | | | | | | AOs which use the "push" API must set this field now. Actually, this was sort of always required, but happened to work anyway. The future intention is to use device_buffer as the pre-buffer amount, which has to be available right before audio playback is started. "Pull" AOs really need this too conceptually, just that the API is underspecified. From what I can see, only ao_null did not do this yet.
* ao/pulse: properly set device_bufferNicolas F2020-06-071-0/+8
| | | | | | | | | Previously, device_buffer defaulted to 0 on pulse. This meant that commit baa7b5c would always wait with a timeout of 0, leading to high CPU usage for PulseAudio users. By setting device_buffer to the number of samples per channel that PulseAudio sets as its target, this commit fixes this behaviour.
* cocoa-cb: properly reset window isMoving state on title bar clicksder richter2020-06-061-0/+2
| | | | | | | | | since the title bar catches the mouse up and down events, the underlying events view doesn't reset the isMoving state and no mouse movements are signalled to the core. now we also reset the state in mouse up events on the title bar. Fixes #7807
* vo_gpu: fix display corruption with window screenshotswm42020-06-061-0/+1
| | | | | | | | | The "screenshot window" command (ctrl+s by default) somehow broke video colors with --gpu-api=vulkan --profile=gpu-hq when playback was paused. I don't know the cause, but the rest of the code seems to imply gl_video_reset_surfaces() needs to be called manually to flush some caches, and it fixes the issue, so I assume there's no great mystery here.
* vo_gpu: mark peak detection buffer coherentNiklas Haas2020-06-061-1/+1
| | | | This is required for buffer memory barriers to actually work
* vo_gpu: make storage images/buffers as restrictNiklas Haas2020-06-061-2/+2
| | | | | This informs the GPU that we don't alias it with any other descriptors (which we don't).
* vulkan/wayland: fix another build breakageDaniel Bermond2020-06-051-1/+1
| | | | | | | | | | | | | | | Commit 07b0c18 introduced some build breakages. Some breakages were fixed on c1fc535 and a1adafe. This one is still remaining. This commit fixes the following build error: [153/521] Compiling video/out/vulkan/context_wayland.c ../video/out/vulkan/context_wayland.c:26:10: fatal error: video/out/wayland/presentation-time.h: No such file or directory 26 | #include "video/out/wayland/presentation-time.h" | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Relevant to: #7802
* build: fix another breakagewm42020-06-041-1/+1
| | | | | | | The build was still broken. Feel free to look for a better maintainer if you don't like it. Fixes: #7802 (maybe now?)
* wayland: fix buildwm42020-06-042-3/+3
| | | | | | Broken by previous commit. I've split a commit incorrectly. Fixes: #7802
* build: change filenames of generated fileswm42020-06-0415-69/+54
| | | | Force them into a more consistent naming schema.
* audio: fix deadlock on drainingwm42020-06-041-1/+1
| | | | | | | | | | | The playback thread may obviously still fill the AO'S entire audio buffer, which means it unset p->draining, which makes no sense and broke ao_drain(). So just don't unset it here. Not sure if this really fixes this, it was hard to reproduce. Regression due to the recent changes. There are probably many more bugs like this. Stupid asynchronous nightmare state machine. Give me a language that supports formal verification (in presence of concurrency) or something.
* options: add --video-scale-x/ywm42020-06-034-4/+18
| | | | | | Requested. Fixes: #6303
* audio: adjust wait durationwm42020-06-031-6/+4
| | | | | | | | | | | | | | | I feel like this makes slightly more sense. At least it doesn't include the potentially arbitrary constant latency that is generally included in the delay value. Also, the buffer status doesn't matter - either we've filled the entire buffer (then we can wait this long), or there's not enough data anyway (then the core will wake up the thread if new data is available). But ultimately, we have to guess, unless the AO does notify us with ao_wakeup_playthread(). Draining may now wait for no reason up to 1/4th of the total buffer time. Shouldn't be a disimprovement in practice.
* vaapi: correct broken NULL checkwm42020-06-031-1/+1
| | | | | | | Clearly, we want to check whether vaGetDisplayDRM() returned NULL. out_display itself is already implied non-NULL. Fixes: #7739
* audio: avoid possible deadlock regression for some AOswm42020-06-021-2/+17
| | | | | | | | | | | | | | | It's conceivable that ao->driver->reset() will make the audio API wait for ao_read_data() (i.e. its audio callback) to return. Since we recently moved the reset() call inside the same lock that ao_read_data() acquires, this could deadlock. Whether this really happens depends on how exactly the AO behaves. For example, ao_wasapi does not have this problem. "Push" AOs are not affected either. Fix by moving it outside of the lock. Assume ao->driver->start() will not have this problem. Could affect ao_sdl, ao_coreaudio (and similar rotten fruit AOs). I'm unsure whether anyone experienced the problem in practice.
* audio: further simplify internal audio API somewhatwm42020-06-025-47/+41
| | | | | | | | | | | | Instead of the relatively subtle underflow handling, simply signal whether the stream is in a playing state. Should make it more robust. Should affect ao_alsa and ao_pulse only (and ao_openal, but it's broken). For ao_pulse, I'm just guessing. How the hell do you query whether a stream is playing? Who knows. Seems to work, judging from very superficial testing.
* audio: slightly better condition for still_playingwm42020-06-021-1/+1
| | | | | | Just a detail. If wrong (not unlikely because I'm just guessing my own messy state machine), this will make the player freeze due to waiting for something that never happens. Enjoy.
* af_scaletempo: handle obscure integer overflowwm42020-06-021-4/+4
| | | | | Saw it once, not really reproducible. This should fix it, and in any case it's harmless.
* TOOLS/autocrop.lua: automatically crop at startupヒカリ2020-06-011-84/+292
|
* audio: reduce extra wakeups caused by recent changeswm42020-06-011-5/+4
| | | | | | | | | | | | | | | | The feeder thread basically woke up the core and itself too often, and caused some CPU overhead. This was caused by the recent buffer.c changes. For one, do not let ao_read_data() wake up the core, and instead rely on the feeder thread's own buffer management. This is a bit strange, since the change intended to unify the buffer management, but being more consequent about it is better deferred to later, when the buffer management changes again anyway. And also, the "more" condition in the feeder thread seems outdated, or at least what made it make sense has been destroyed, so do something that may or may not be better. In any case, I'm still not getting underruns with ao_alsa, but the wakeup hammering is gone.
* vo: refine wakeup condition, and wake up more in audio sync modewm42020-06-011-3/+3
| | | | | | | | | | | Commit 6a13954d67143fb lowered the frequency of wakeups with this condition. But it seems it sometimes the audio sync mode really should get the wakeup before the frame is rendered. Normally, vo_thread is supposed to perform this wakeup. Now the wakeup frequency is twice of what should be needed - whatever, maybe it can be fixed properly once or if timing is moved to the VO entirely in the future. Fixes: #7777 (probably, untested)
* audio: redo internal AO APIwm42020-06-0120-823/+635
| | | | | | | | | | | | | | | | | | | | | | | | | This affects "pull" AOs only: ao_alsa, ao_pulse, ao_openal, ao_pcm, ao_lavc. There are changes to the other AOs too, but that's only about renaming ao_driver.resume to ao_driver.start. ao_openal is broken because I didn't manage to fix it, so it exits with an error message. If you want it, why don't _you_ put effort into it? I see no reason to waste my own precious lifetime over this (I realize the irony). ao_alsa loses the poll() mechanism, but it was mostly broken and didn't really do what it was supposed to. There doesn't seem to be anything in the ALSA API to watch the playback status without polling (unless you want to use raw UNIX signals). No idea if ao_pulse is correct, or whether it's subtly broken now. There is no documentation, so I can't tell what is correct, without reverse engineering the whole project. I recommend using ALSA. This was supposed to be just a simple fix, but somehow it expanded scope like a train wreck. Very high chance of regressions, but probably only for the AOs listed above. The rest you can figure out from reading the diff.
* audio: fix unpausing with some AOswm42020-05-311-1/+1
| | | | | | | | | wasapi/coreaudio/sdl were affected, alsa/pusle were not. The confusion here was that resume() has different meaning with pull and push AOs. Fixes: #7772
* terminal-win: handle 'Change Window Title' OSC sequenceJames Ross-Gowan2020-05-291-99/+131
| | | | | | | | | | | | | | | | | This should make --term-title work in Windows 8.1 and below. OSC sequences are defined in ECMA-48. The 'Change Window Title' command, as far as I can tell, is a de-facto standard defined by xterm[1]. In either case, this code is probably still not standards-compliant. This also changes mp_write_console_ansi to convert to UTF-16 before parsing control sequences, because that made it easier to pass the OSC param to SetConsoleTitleW. I think it's also more correct to do it this way, even though it doesn't really matter much for our limited terminal parsing. As a side-effect of this, mp_write_console_ansi no longer mutates its argument. [1]: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Operating-System-Commands
* ao_null: remove unreferenced functionwm42020-05-271-8/+0
| | | | Forgot in the previous commit to this file.
* audio: stop applying volume twice for some AOswm42020-05-271-1/+0
| | | | | | | Regression since the recent refactor. How did nobody notice? This happened because the push code now calls the function for the pull code. Both the former and latter apply the volume, so oops.
* audio: remove ao_driver.drainwm42020-05-277-48/+12
| | | | | | | | | | The recent change to the common code removed all calls to ->drain. It's currently emulated via a timed sleep and polling ao_eof_reached(). That is actually fallback code for AOs which lacked draining. I could just readd the drain call, but it was a bad idea anyway. My plan to handle this better is to require the AO to signal a underrun, even if AOPLAY_FINAL_CHUNK is not set. Also reinstate not possibly waiting for ao_lavc.c. ao_pcm.c did not have anything to handle this; whatever.
* lua: windows got what users cravewm42020-05-271-0/+3
| | | | | | It's got '\r's. Fixes: #7733
* player: add --term-title optionwm42020-05-257-0/+39
| | | | | | | | | | | | | | This simply printf()s a concatenation of the provided string and the relevant escape sequences. No idea what exactly defines this escape sequence (is it just a xterm thing that is now supported relatively widely?), and this simply uses information provided on the linked github issue. Not much of an advantage over --term-status-msg, though at least this can have a lower update frequency. Also I may consider setting a default value, and then it shouldn't conflict with the status message. Fixes: #1725
* audio: merge pull/push ring buffer glue codewm42020-05-256-1006/+762
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is preparation to further cleanups (and eventually actual improvements) of the audio output code. AOs are split into two classes: pull and push. Pull AOs let an audio callback of the native audio API read from a ring buffer. Push AOs expose a function that works similar to write(), and for which we start a "feeder" thread. It seems making this split was beneficial, because of the different data flow, and emulating the one or other in the AOs directly would have created code duplication (all the "pull" AOs had their own ring buffer implementation before it was cleaned up). Unfortunately, both types had completely separate implementations (in pull.c and push.c). The idea was that little can be shared anyway. But that's very annoying now, because I want to change the API between AO and player. This commit attempts to merge them. I've moved everything from push.c to pull.c, the trivial entrypoints from ao.c to pull.c, and attempted to reconcile the differences. It's a mess, but at least there's only one ring buffer within the AO code now. Everything should work mostly the same. Pull AOs now always copy the audio data under a lock; before this commit, all ring buffer access was lock-free (except for the decoder wakeup callback, which acquired a mutex). In theory, this is "bad", and people obsessed with lock-free stuff will hate me, but in practice probably won't matter. The planned change will probably remove this copying-under-lock again, but who knows when this will happen. One change for the push AOs now makes it drop audio, where before only a warning was logged. This is only in case of AOs or drivers which exhibit unexpected (and now unsupported) behavior. This is a risky change. Although it's completely trivial conceptually, there are too many special cases. In addition, I barely tested it, and I've messed with it in a half-motivated state over a longer time, barely making any progress, and finishing it under a rush when I already should have been asleep. Most things seem to work, and I made superficial tests with alsa, sdl, and encode mode. This should cover most things, but there are a lot of tricky things that received no coverage. All this text means you should be prepared to roll back to an older commit and report your problem.