Commit message (Collapse)AuthorAgeFilesLines
* docs: Fix an old style parameter referenceHEADmasterChris Varenhorst3 days1-1/+1
| | | | `--vf format:stereo-in=help` no longer works. It now must be `--vf=format:stereo-in=help`
* umpv: remove unused importsJim Manos3 days1-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 Herkt3 days1-4/+4
| | | | Fixes #8480
* player: make resetting of track selection to "auto" worksfan56 days1-9/+21
* mac: fix dangling pointersder richter9 days2-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 richter9 days4-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 richter9 days2-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, 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 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.
* 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
* 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 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.0release/0.33sfan52020-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 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 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: (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
* 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 <>
* 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.
* 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 being a gui program instead of a console program. Does not interfere with gcc compilation. result without this patch ``` file .\ .\mpv.exe .\ 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.exe .\ PE32+ executable (console) x86-64 (stripped to external PDB) .\mpv.exe: PE32+ executable (GUI) x86-64 (stripped to external PDB) ``` 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 Signed-off-by: Christopher Degawa <>
* 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 <>
* 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 Most code tries to avoid accessing 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/
* 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 <>
* 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]
* 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 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/ 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 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 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:
* 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]
* 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 (
* 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]:
* 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
* 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 <> 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 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: 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 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]:
* 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.
* audio: add frame alloc functionwm42020-05-252-0/+14
| | | | Meh, why is this so roundabout?
* CI: add FreeBSD jobJan Beich2020-05-252-0/+63
* osdep: remove confstr() fallback for subprocess spawningsfan52020-05-251-7/+2
| | | | | It doesn't exist on bionic (Android) and accurately emulating execvpe's behaviour isn't all that important.
* x11_common: added ICCCM WM_HINTSArthur Williams2020-05-241-0/+11
| | | | | | | | | | | | | | | | | | When the window is mapped, some ICCCM WM_HINTS are set. The input field is set to true and state is set to NormalState. To quote the spec, "The input field is used to communicate to the window manager the input focus model used by the client" and "[c]lients with the Passive and Locally Active models should set the input flag to True". mpv falls under the Passive Input model, since it expects keyboard input, but only listens for key events on its single, top-level window instead of subordinate windows (Locally Active) or the root window (Globally Active). From the end users prospective, all EWMH/ICCCM compliant WMs (especially the minimalistic ones) will allow the user to focus mpv, which will allow mpv to receive key events. If the input field is not set, WMs are allowed to assume that mpv doesn't require focus.
* manpage: document "vf remove"wm42020-05-231-1/+4
| | | | And mention it on "vf del" as non-deprecated alternative.
* player: remove some display-adrop leftoverswm42020-05-237-24/+3
| | | | | Forgotten in one of the previous commits. Also undeprecates display-adrop since it's out of sight now.
* command: fix dump-cache parameter parsingwm42020-05-231-2/+4
| | | | | | Commit 9d32d62b615 broke this when it changed OPT_TIME. I simply forgot to adjust the command definition. The effect was that "no" was not accepted as value.
* README: remove trollingwm42020-05-231-4/+0
| | | | | | | | | | | | | | | | | | I guess this qualifies as trolling. It's becoming increasingly clear that Microsoft will not be able to deliver on this promise, at least not in the way they made it seem at first. I'm not sure if Microsoft was the one who did the trolling, or me. I actually expected that we'd get full GUI integration of Linux applications including accelerated graphics, but it was always clear that it wasn't going to work as well as natively. In any case, there is no need to frighten any users. The time when you can run only "Windows Store Apps" on Windows (== the end for mpv and many other applications on Windows) will come soon enough. The "faster than native" statement is based on other people's real experience of software running faster in Linux VMs than native windows ports, by the way.
* audio: redo video-sync=display-adropwm42020-05-2312-56/+192
| | | | | | | | | | | | | | | | | This mode drops or repeats audio data to adapt to video speed, instead of resampling it or such. It was added to deal with SPDIF. The implementation was part of fill_audio_out_buffers() - the entire function is something whose complexity exploded in my face, and which I want to clean up, and this is hopefully a first step. Put it in a filter, and mess with the shitty glue code. It's all sort of roundabout and illogical, but that can be rectified later. The important part is that it works much like the resample or scaletempo filters. For PCM audio, this does not work on samples anymore. This makes it much worse. But for PCM you can use saner mechanisms that sound better. Also, something about PTS tracking is wrong. But not wasting more time on this.
* af_scaletempo: fix theoretical UBwm42020-05-231-1/+2
| | | | | Passing NULL to memset() is undefined behavior, even if the size argument is 0. Could happen on init errors and such.
* options: add option to control display-sync factorwm42020-05-234-3/+18
| | | | | | | | Can be useful to force it to adapt to extreme speed changes, while a higher limit would just use a fraction closer to the original video speed. Probably useful for testing only.
* vo_x11: allow OSD rendering outside of video regionwm42020-05-221-65/+52
| | | | | | | | | | | | | | | | | | | | | | | | I'm not sure why it only rendered OSD inside the video. Since OSD rendering was always done on the X image (after software scaling and color conversion), there was no technical reason for this. Maybe it was because the code started out this way, and it was annoying to change it. Possibly, one reason was that it didn't normally have to clear the black bars in every frame (if video didn't cover the entire window). Anyway, simply render OSD to the full window. This gets rid of some rather weird stuff. It seems to look mostly like vo_wlshm now. The uncovered regions are cleared every frame, which could probably be avoided by being clever with the OSD renderer code, but this is where I'm decidedly losing interest. There was some mysterious code for aligning the image width to 8 pixels. Replace that by attempting to align it to SIMD alignment (might matter for libswscale, or if repack.c gets SIMD). Why are there apparently 4 different ways representing a pixel format (depth, VisualID, Visual, XVisualInfo), but none of them seem to provide the XImage.bits_per_pixel value (the actual size of a pixel, including padding)? Even after 33 years, X11 still seems overengineered, confusing, and inconvenient. So just call X11 a heap of shit, and assume the worst case for alignment.
* mp_image: add helper for clearing regions outside of a rectanglewm42020-05-222-0/+16
| | | | Not sure if generally useful; the following commit uses it.
* common: add helper for subtracting rectangleswm42020-05-222-0/+24
| | | | Not sure if generally useful; the following commit uses it.
* video: add AV_PIX_FMT_UYYVYY411 conversion supportwm42020-05-224-34/+60
| | | | | | | | | | It may be completely useless, and I can't verify it as no known samples or other known/accessible software using it, but why not? Putting this together with he 422 code requires making it slightly more generic. I'm still staying with a "huge" if tree instead of a table to select the scanline worker callback, because it's actually small and not huge (although it not being generic still feels slightly painful).
* repack: use new imgfmt metadata in more caseswm42020-05-211-74/+59
| | | | | | Now everything is super generic and super undebuggable. Some awkwardness because the new metadata is basically a transposed version of the mp_regular_imgfmt metadata, which was used for component info before.
* img_format: expose another helperwm42020-05-212-2/+6
* mp_image: reimplement mp_image_clear()wm42020-05-211-25/+104
| | | | | | | | | | | | The old code ignored many corner cases, and even wrote "blacker than black" to YUV images. Use the new pixel format metadata and other recently added gimmicky crap, which should make this more correct. Even the almighty fuckup of a format AV_PIX_FMT_UYYVYY411 should work, although that couldn't be tested for obvious reasons. This doesn't work for "monow", but this is so extremely fringe while at the same time painful that I just won't care. In theory, it could be modeled as some sort of inverted gray colorspace or something.
* video: remove useless mp_imgfmt_desc.avformat fieldwm42020-05-203-5/+2
| | | | Had 1 user; easily replaced.
* vo_x11: minor improvement in format matchingwm42020-05-201-5/+5
| | | | | | | | | Make sure to accept only native endian mpv formats. Previously, it didn't check, and simply matched LE, because these are usually defined before the BE formats. red_mask etc. are defined as unsigned long, so use that instead of hardcoding a 32 bit limit.
* video: clean up pixel metadata stuff some morewm42020-05-204-509/+545
| | | | | | | | | | | | | | | A repeat of the previous useless commits. Pondered whether to use separate fields or just a flags integer for color and component types; the latter won for now. Functions like mp_imgfmt_get_component_type() are now discouraged, and mp_imgfmt_desc.flags is back for defining all information. Some days ago I felt like the opposite would be the better design. Fortunately, it doesn't matter. With this, I think all image format properties that mpv needs are exhaustively defined all in one place.
* command: save state on stop when user requested save-position-on-quitMikhail Rudenko2020-05-201-0/+7
| | | | | | | | Execution of "stop" command in the case when idle mode was not enabled resulted in player termination scenario not honoring user setting "save-position-on-quit" from config file. This patch addresses the issue by checking for "save-position-on-quit" in cmd_stop and saving state when idle mode is not enabled.
* vo_x11: use imgfmt metadata instead of hardcoded format tablewm42020-05-201-32/+21
| | | | | | Useless, but super generic! Actually may add support for other fringe formats, however vo_x11 in itself is useless, so nothing won here. Also I didn't bother with big endian support.
* video: shuffle imgfmt metadata code aroundwm42020-05-205-278/+265
| | | | | | | | | | | | | | | | | I guess I decided to stuff it all into mp_imgfmt_desc (the "old" struct). This is probably a mistake. At first I was afraid that this struct would get too fat (probably justified, and hereby happened), but on the other hand mp_imgfmt_get_desc() (which builds the struct) calls the former mp_imgfmt_get_layout(), and the separation doesn't make too much sense anyway. Just merge them. Still, try to keep out the extra info for packed YUV bullshit. I think the result is OK, and there's as much information as there was before. The test output changes a little. There's no independent bits[] array anymore, so formats which did not previously have set this now show it. (These formats are mpv-only and are still missing the metadata. To be added later). Also, the output for the cursed packed formats changes.
* README: looks like we won't need win32 support anymorewm42020-05-191-0/+3
* repack: make generic weird pixfmt shit even more generic and obfuscatedwm42020-05-181-54/+20
| | | | | | | | | | | | | | Use the new pixfmt metadata to replace the format tables with weird generic code. As you can see, this removes the tables that essentially duplicate information (which is baaaaaaaaaad), in exchange for code which is probably more fragile and has less of a chance of being understood by someone new to the code (which is probably even worse from a maintenance and robustness point of view, but LALALA I CAN'T HEAR YOU). There are some more formats which can be handled like this (RGB30 and packed YUV I guess), maybe later.
* video: fix AV_PIX_FMT_UYYVYY411 allocationwm42020-05-182-3/+2
| | | | | | | My previous commit added support for this format, but it was still broken, and prevented the allocation code from working. It's unknown whether it's correct now (because this pixfmt is so obscure and useless, there are no known samples around), but who cares.
* wayland: only use presentation on CLOCK_MONOTONICDudemanguy2020-05-181-2/+2
| | | | | | | Trying to use anything other than CLOCK_MONOTONIC here would be a disaster. No idea if it's even possible for the clockid here to be something other than CLOCK_MONOTONIC in this function but it's better safe than sorry. Closes #7740.
* build: allow wlshm on more Wayland platforms after a6000d311421Jan Beich2020-05-181-6/+6
* video: add pixel component location metadatawm42020-05-184-130/+875
| | | | | | | | | | | | | | | | | | | | | | | | | | | | I thought I'd probably want something like this, so the hardcoded stuff in repack.c can be removed eventually. Of course this has no purpose at all, and will not have any. (For now, this provides only metadata, and nothing uses it, apart from the "test" that dumps it as text.) This adds full support for AV_PIX_FMT_UYYVYY411 (probably out of spite, because the format is 100% useless). Support for some mpv-only formats is missing, ironically. The code goes through _lengths_ to try to make sense out of the FFmpeg AVPixFmtDescriptor data. Which is even more amazing that the new metadata basically mirrors pixdesc, and just adds to it. Considering code complexity and speed issues (it takes time to crunch through all this shit all the time), and especially the fact that pixdesc is very _incomplete_, it would probably better to have our own table to all formats. But then we'd not scramble every time FFmpeg adds a new format, which would be annoying. On the other hand, by using pixdesc, we get the excitement to see whether this code will work, or break everything in catastrophic ways. The data structure still sucks a lot. Maybe I'll redo it again. The text dump is weirdly differently formatted than the C struct - because I'm not happy with the representation. Maybe I'll redo it all over again. In summary: this commit does nothing.
* video: clean up some imgfmt related stuffwm42020-05-1815-756/+747
| | | | | | | | | | | | | | | | Remove the vaguely defined plane_bits and component_bits fields from struct mp_imgfmt_desc. Add weird replacements for existing uses. Remove the bytes[] field, replace uses with bpp[]. Fix some potential alignment issues in existing code. As a compromise, split mp_image_pixel_ptr() into 2 functions, because I think it's a bad idea to implicitly round, but for some callers being slightly less strict is convenient. This shouldn't really change anything. In fact, it's a 100% useless change. I'm just cleaning up what I started almost 8 years ago (see commit 00653a3eb052). With this I've decided to keep mp_imgfmt_desc, just removing the weird parts, and keeping the saner parts.
* test: explicitly test repacking for all packed RGB variantswm42020-05-182-36/+117
| | | | This stuff is very annoying, so it's good to have full coverage.
* stats: UP/DOWN scrolling on page 2 (frame stats)Julian2020-05-172-3/+25
| | | | | | Code contributed by @avih with only minor modifications to comments by me. Fixes #7727.
* vo_wlshm, vo_drm: set image size with mp_image_set_sizeMichael Forney2020-05-172-4/+2
| | | | | | | | | | The image w and h members must match params.w and params.h, so should not be changed directly. The helper function mp_image_set_size is designed for this purpose, so just use that instead. This prevents an assertion error with the rewritten draw_bmp. Fixes #7721.
* zsh completion: helper functions in private namespaceEd Santiago2020-05-171-6/+6
| | | | | | | | | | | The generate_xxx() helpers, once defined, would appear as user-visible functions; this would lead to unexpected and confusing completion suggestions for gene<tab> after having once run mpv in that shell. This PR adds the prefix '_mpv_' to all completion functions as a convention to make them less user-visible and less likely to collide with other packages.
* osc: fix hovering timestamp sticking around when moving mouse awaywm42020-05-161-3/+11
| | | | | | | | | | | | | | The OSC calls this "tooltip" (and although a general mechanism, there's only one instance using it). One particular problem was that with the default OSC layout, moving the mouse down and out of the window, the tooltip stuck around, because the returned mouse position was the last pixel row in the window, which still overlaps with the seek bar. Instead of introducing mouse_in_window, you could check last_mouse_X for nil, but I think this is clearer. This returns (-1, -1) to the caller if the mouse is outside. Kind of random, but works.
* vo_gpu: ra_pl: add timers supportNiklas Haas2020-05-161-0/+95
| | | | | | | | | | | | | | | Added in libplacebo v60, unfortunately with some changes in design that make it a bit of an awkward fit for the way timers are used in mpv. Timer queries in libplacebo don't support "start" and "stop"-style operations, and instead are attached directly to operations. The only sane way of implementing this in the ra API is to have a single 'active timer' that gets attached to every pass, taking care to sort distinct operations into distinct pl_timer queries within that ra_timer. This design unfortunately doesn't let us have multiple 'active timers' concurrently, similar to the current such limitation in ra_gl. But it's also not a big deal.
* scripting: make socket FD number for subprocesses dynamicwm42020-05-152-9/+4
| | | | | | | | | | | | | | | | | | | | | | | | Before this, we pretty much guaranteed that --mpv-ipc-fd=3 would be passed. The FD was hardcoded, so scripts started by this mechanism didn't need to actually parse the argument. Change this to using a mostly random FD number instead. I decided to do this because posix_spawnp() and the current replacement cannot "guarantee" a FD layout. posix_spawn_file_actions_adddup2() just runs dup2() calls, so it may be hard to set FD 3/4 if they are already used by something else. For example imagine trying to map: {.fd = 3, .src_fd = 4}, {.fd = 4, .src_fd = 3}, Then it'd do dup2(4, 3), dup2(3, 4) (reminder: dup2(src, dst)), and the end result is that FD 4 really maps to the original FD 4. While this was not a problem in the present code, it's too messy that I don't want to pretend it can always done this way without an unholy mess. So my assumption is that FDs 0-2 can be freely assigned because they're never closed (probably...), while for all other FDs only pass-through is reasonable.
* sub: fix incorrect commitwm42020-05-151-3/+1
| | | | Commit c6369933f1d9cd accidentally added an old version of this comment.
* ipc: mark client sockets as CLOEXECwm42020-05-151-0/+2
| | | | | I suppose it would have left the socket open if the client closed its FD.
* scripting: correct passing FDswm42020-05-151-1/+1
| | | | | For external scripts/processes which use IPC. The mistake didn't really matter.
* osdep: remove posix_spawn() helpers and wrapperswm42020-05-156-163/+2
| | | | See previous commit. Farewell, useless shitty POSIX function.
* subprocess: replace posix_spawnp() with fork()wm42020-05-151-17/+118
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code runs posix_spawnp() within a fork() in some cases, in order to "disown" processes which are meant as being started detached. But posix_spawnp() is not marked as async-signal-safe, so what we do is not allowed. It could for example cause deadlocks, depending on implementation and luck at runtime. Turns out posix_spawnp() is useless crap. Replace it with "classic" fork() to ensure correctness. We could probably use another mechanism to start a process "disowned" than doing a double-fork(). The only problem with "disowning" a process is calling setsid() (which posix_spawnp() didn't support, but maybe will in newer revisions), and removing as as parent from the child process (the double-fork() will make PID 1 the parent). But there is no good way to either remove us as parent, or to "reap" the PID in a way that is safe and less of a mess than the current code. This is because POSIX/UNIX is a miserable heap of shit. (Less shit than "alternatives" like win32, no doubt.) Because POSIX/UNIX is a miserable heap of shit, execvp() is also not specified as async-signal-safe. It's funny how you can run a full fledged HTTP server in an async-signal-safe context, but not start a shitty damn process. Unix is really, really, really extremely bad at this process management stuff. So we reimplement execvp() in an async-signal-safe way. The new code assumes that CLOEXEC is a thing. Since POSIX/UNIX is such a heap of shit, O_CLOEXEC and FD_CLOEXEC were (probably) added at different times, but both must be present. io.h defines them to 0 if they don't exist, and in this case the code will error out at runtime. Surely we could do without CLOEXEC via fallback, but I'll do that only if at least 1 bug is reported wrt. this issue. The idea how to report exec() failure or success is from musl. The way as_execvpe() is also inspired by musl (for example, the list of error codes that should make it fail is the same as in musl's code).
* command: add input-key-list propertywm42020-05-144-0/+29
| | | | Fixes: #7698
* command: add property to return text subtitles in ASSwm42020-05-147-18/+62
| | | | | | | | | See manpage additions. This was requested, sort of. Although what has been requested might be something completely different. So this is speculative. This also changes sub_get_text() to return an allocated copy, because the buffer shit was too damn messy.
* ipc: exit client if the FD is invalidwm42020-05-141-1/+1
| | | | | | | This does not normally happen. But since the --input-ipc-client option can pass in raw FDs, it's probably a good thing in the interest of making mistakes obvious. Without this, it just burned a core on invalid FDs (poll() always returned immediately).
* ipc: make --input-ipc-client terminate player on connection closewm42020-05-142-1/+11
| | | | | | | | As discussed in the referenced issue. This is quite a behavior change, bit since this option is new, and not included in any releases yet, I think it's OK. Fixes: #7648
* vo_x11: add 10 bit supportwm42020-05-141-0/+3
| | | | Requires zimg.
* build: link against single EGL providerJan Palus2020-05-142-11/+37
| | | | | when building with rpi EGL is provided by librcmegl library and libEGL should not be linked then
* build: fallback to default pc file locations on rpiJan Palus2020-05-142-3/+10
* drm: add typedef for PFNEGLGETPLATFORMDISPLAYEXTPROC (#7314)Jan Palus2020-05-141-0/+5
| | | | extension is not mandatory and is not provided on ie Raspberry Pi
* vo_direct3d: dumb down OSD renderingwm42020-05-131-164/+92
| | | | | | | | | | | | | | Render most of the OSD on the CPU, then draw it using a relatively simple method. Do this for minimum code maintenance overhead. (While it doesn't matter for vo_direct3d, and the effort spent here is probably more than this would ever hope, I do hope to simplify the internal OSD API for all these fringe VOs. Only vo_gpu should be allowed to do more sophisticated things.) If your GPU is shit (which it will be if you "want" to use vo_direct3d), this might actually improve performance... is what I'd say, but out of laziness a full screen sized texture gets uploaded on every OSD/subtitle change, so maybe not.
* draw_bmp: make another small guarantee to userswm42020-05-131-0/+2
| | | | Mostly self-evident.
* vo_direct3d: rip out texture video rendering pathwm42020-05-135-660/+67
| | | | | | | | | | | | | This isn't useful anymore. We have a much better d3d11 renderer in vo_gpu. D3D11 is available in all supported Windows versions. The StretchRect path might still be useful for someone (???), and leaving it at least evades conflict about users who want to keep using this VO for inexplicable reasons. (Low power usage might be a justified reason, but still, no.) Also fuck the win32 platform, it's a heap of stinky shit. Microsoft is some sort of psycho clown software company. Granted, maybe still better than much of the rest of Silly Con Valley.
* draw_bmp: use command line options for any used scalerswm42020-05-135-16/+36
* vo_gpu: un-fix storable fbo format checkNiklas Haas2020-05-131-2/+1
| | | | | | | | | The original solution for #7017 was sort of a hack, but this hack is no longer needed because c05e5d9d fixed the underlying issue causing this error to be spammed in the first place. So just remove the "fix" that apparently introduced about as many issueas it fixed. Fixes #7719, hopefully.
* draw_bmp: add integer blending for 8 bit formatswm42020-05-122-41/+79
| | | | | | | | Whatever it's worth. Instead of doing a pretty stupid conversion to float, just blend it directly. This works for most RGB formats that are 8 bits per component or below (the latter because we expand packed fringe RGB formats for simplicity). For higher bit depth RGB this would need extra code.
* repack: fix incorrect assert()wm42020-05-121-1/+1
| | | | | Used the output of the first step instead of the input when checking the real input.
* draw_bmp: don't make strange decisions on broken iknput csp paramswm42020-05-123-64/+66
| | | | | | | | | | | | This checked params-> for being RGB. If the colorspace is unset, this did dumb things because even if the imgfmt was a RGB one, the colorspace was not set to RGB. This actually also happened to the tests. (Short-cutting RGB like this is actually wrong, since RGB could still have strange gamma or primaries, which would warrant a full conversion. So you'd need to check for these other parameters as well. To be fixed later.)
* vo_vaapi: use new overlay APIwm42020-05-111-123/+85
| | | | | | | | | | | | | This will probably make it slower. But since I don't care about vo_vaapi, that's perfectly OK. It serves mostly as a test for the previous commit. In addition, this code was pretty bad (custom broken scaling and not-blending that probably broke in some situation). If that wasn't enough, some vaapi drivers also provide only a single overlay at a time, while this code required a bunch. There also seems to be a Mesa bug: the overlay gets stretched when src_x/y was not 0. Or maybe I misunderstood how this is supposed to work. A bug is probably more likely? Nobody cares about this API.
* draw_bmp: add a function to return a single-texture OSD overlaywm42020-05-114-50/+265
| | | | | | | | | | | | | | Maybe this is useful for some of the lesser VOs. It's preferable over bad ad-hoc solutions based on the more complex sub_bitmap data structures (as observed e.g. in vo_vaapi.c), and does not use that much more code since draw_bmp already created such an overlay internally. But I still wanted something that avoids having to upload/render a full screen-sized overlay if for example there's only a tiny subtitle line on the bottom of the screen. So the new API can return a list of modified pixels (for upload) and non-transparent pixels (for display). The way these pixel rectangles are computed is a bit dumb and returns dumb results, but it should be usable, and the implementation can change.
* video: remove RGB32/BGR32 aliaseswm42020-05-115-18/+9
| | | | | | | They are sort of confusing, and they hide the fact that they have an alpha component. Using the actual formats directly is no problem, sicne these were useful only for big endian systems, something we can't test anyway.
* js: mp.set_osd_ass: ignore identical inputs (match ccbb8b1c)Avi Halachmi (:avih)2020-05-101-0/+5
* vo: fix forgotten debug codewm42020-05-101-1/+1
| | | | | | | This was not intended to be committed in 0e3f8936062967a9db. It disables the extra wakeup if working==true. I've convinced myself that the wakeup was really needed at the time, so no idea how I didn't notice this until someone pointed it out on the commit diff on github (lol).
* lua: do not use Lua filesystem functions for loading scriptswm42020-05-101-3/+6
| | | | | | | | | | | Bill Gates did not only create COVID, he's also responsible for the world's worst OS, where you have to literally jump through hoops of fire to open files with Unicode file names. Lua did not care to implement any jumping, so it's our turn to jump. Untested (on win32). Fixes: #7701
* stream: make stream_read_file() more robustwm42020-05-103-23/+41
| | | | | | | | | Change it to strictly accept local paths only. No more http://, no more $HOME expansion with "~/" or mpv config path expansion with "~~/". This should behave as if passing a path directly to open(). Reduce annoying log noise to further facilitate it using as open() replacement.
* msg: add function to reduce log levelwm42020-05-102-2/+19
| | | | | | | | | | Sometimes it's helpful to override this for specific mp_log instances, because in some specific circumstances you just want to suppress log file noise you never want to see. -1 is an allowed value (for suppressing MSGL_FATAL==0). It looks like the libplacebo wrapper still does this wrong, so it will probably trigger UB in some cases. I guess I don't care, though.
* vo_gpu: manually resolve user shader prefixeswm42020-05-101-1/+4
| | | | | | | | This resolves prefixes such as "~/" and "~~/" at the caller, instead of relying on stream_read_file() to do it. One of the following commits will remove this from stream_read_file() itself. Untested.
* player: make external subtitle auto-loading stricterwm42020-05-092-25/+41
| | | | | | | | | | | | | | | | | | | | | | | | | By default --sub-auto uses "exact". This was far from an "exact" match, because it added anything that started with the video filename (without extension), and seemed to end in something that looked like a language code. Make this stricter. "exact" still tolerate a language code, but the video's filename must come before it without any unknown extra characters. This may not load subtitles in some situations where it previously did, and where the user might think that the naming convention is such that it should be considered an exact match. The subtitle priority sorting seems a bit worthless. I suppose it may have some value in higher "fuzz" modes (like --sub-auto=fuzzy). Also remove the mysterious "prio += prio;" line. I probably shouldn't have checked, but it goes back to commit f16fa9d31 (2003), where someone wanted to "refine" the priority without changing the rest of the code or something. Mostly untested, so have fun. Fixes: #7702
* options: update OSD when writing some OSD-related optionswm42020-05-091-9/+9
| | | | | | Just the usual change notification mess. Fixes: #7697
* vo: another minor wakeup reductionwm42020-05-091-5/+10
| | | | | | The caller of render_frame() re-iterates without waiting if this function returns true. That's normally meant for DS, where we draw frames as fast as possible to let the driver perform waiting.
* vo: always reset redraw flag to avoid immediate wakeups wasting CPU timewm42020-05-091-1/+2
| | | | | | | This could temporarily hog the core or something because it's a stupid fragile state machine that should best be wiped out. Fixes: #7699
* draw_bmp: rewritewm42020-05-096-411/+938
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | draw_bmp.c is the software blender for subtitles and OSD. It's used by encoding mode (burning subtitles), and some VOs, like vo_drm, vo_x11, vo_xv, and possibly more. This changes the algorithm from upsampling the video to 4:4:4 and then blending to downsampling the OSD and then blending directly to video. This has far-reaching consequences for its internals, and results in an effective rewrite. Since I wanted to avoid un-premultiplying, all blending is done with premultiplied alpha. That's actually the sane thing to do. The old code just didn't do it, because it's very weird in YUV fixed point. Essentially, you'd have to compensate for the chroma centering constant by subtracting src_alpha/255*128. This seemed so hairy (especially with correct rounding and high bit depths involved) that I went for using float. I think it turned out mostly OK, although it's more complex and less maintainable than before. reinit() is certainly a bit too long. While it should be possible to optimize the RGB path more (for example by blending directly instead of doing the stupid float conversion), this is probably slower. vo_xv users probably lose in this, because it takes the slowest path (due to subsampling requirements and using YUV). Why this rewrite? Nobody knows. I simply forgot the reason. But you'll have it anyway. Whether or not this would have required a full rewrite, at least it supports target alpha now (you can for example hard sub transparent PNGs, if you ever wanted to use mpv for this). Remove the check in vf_sub. The new draw_bmp.c is not as reliant on libswscale anymore (mostly uses repack.c now), and osd.c shows an error message on missing support instead now. Formats with chroma subsampling of 4 are not supported, because FFmpeg doesn't provide pixfmt definitions for alpha variants. We could provide those ourselves (relatively trivial), but why bother.
* repack: add support for converting from/to float formatswm42020-05-094-3/+402
| | | | | Will be needed by draw_bmp.c. The tests cross-check this with zimg to control whether we're getting it right.
* csputils: add function for getting uint/float transformationwm42020-05-092-1/+44
| | | | | | | | | | | | | | This provides a way to convert YUV in fixed point (or pseudo-fixed point; probably best to say "uint") to float, or rather coefficients to perform such a conversion. Things like colorspace conversion is out of scope, so this is simple and strictly per-component. This is somewhat similar to mp_get_csp_mul(), but includes proper color range expansion and correct chroma centering. The old function even seems to have a bug, and assumes something about shifted range for full range YCbCr, which is wrong. vo_gpu should probably use the new function eventually.
* video: add yuv float formatswm42020-05-095-11/+181
| | | | | | | | | | | Adding all these so I can use them for obscure processing purposes (see later draw_bmp commit). There isn't really a reason why they should exist. On the other hand, they're just labels for formats that can be handled in a generic way, and this commit adds support for them in the zimg wrapper and vo_gpu just by making the formats exist. (Well, vo_gpu had to be fixed in the previous commit.)
* vo_gpu: fix green shit with float yuv inputwm42020-05-095-12/+28
| | | | | | | | | | | | This was incorrect at least because the colorspace matrix attempted to center chroma at (conceptually) 0.5, instead of 0. Also, it tried to apply the fixed point shift logic for component sizes > 8 bit. There is no float yuv format in mpv/ffmpeg yet, but see next commit, which enables zimg to output it. I'm assuming zimg defines this format such that luma is in range [0,1] and chroma in range [-0.5,0.5], with the levels flag being ignored. This is consistent with H264/5 Annex E (I think...), and it sort of seems to look right, so that's it.
* video: fix rgb30 component orderwm42020-05-095-5/+8
| | | | | | | | | Was broken with a zimg wrapper refucktor before the previous commit. In addition, it seems this didn't match the vo_drm format, or the format naming convention. So the order actually changes, and the format is redefined. (The img_format.h comment was probably wrong.) Change vo_gpu to the new format as well, so we can still test it.
* video: separate repacking code from zimg and make it independentwm42020-05-099-895/+1688
| | | | | | | | | | | | | For whatever purpose. If anything, this makes the zimg wrapper cleaner. The added tests are not particular exhaustive, but nice to have. This also makes the scale_zimg.c test pretty useless, because it only tests repacking (going through the zimg wrapper). In theory, the repack_tests things could also be used on scalers, but I guess it doesn't matter. Some things are added over the previous zimg wrapper code. For example, some fringe formats can now be expanded to 8 bit per component for convenience.
* sws_utils: allow setting zimg options directlywm42020-05-094-8/+18
| | | | One could wonder, why not just use the zimg wrapper directly?
* img_format: make component order in comment more logicalwm42020-05-091-1/+1
* sd_lavc: fix occasional problems with certain VOs when changing scalingwm42020-05-091-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | The OSD is passed to VOs via struct sub_bitmaps, which has a change_id field. This field is incremented whenever there is a (potential) change to the other struct contents. If not, the VO can rely on it not having changed. This must include for example sub_bitmap.x and sub_bitmap.dw. If these two fields (and y equivalents) change, change_id must change, even if the subtitle bitmap data might still be the same. sd_lavc.c stopped respecting this at some unknown point. It could sometimes cause problems, though usually only with bad and old VOs which somehow relied on this more than vo_gpu. (I've actually encountered this before with sd_lavc subtitle scaling, as indicated by a nasty comment, though probably didn't track this down, since said old VOs can die in a fire.) Fix this by maintaining the change_id explicitly. Unfortunately adds even more code. Instead of comparing the result we could track property changes, but I think this is better. The number of parts is always very low with this subtitle decoder, so there's no actual performance issue to worry about. This could be triggered by scaling changes (video-zoom etc.), but probably also changing bitmap subtitle position or scaling.
* osd: add change timestamp and screen size to struct sub_bitmap_listwm42020-05-093-1/+23
| | | | | | | | Should be somewhat helpful. (All VOs are full of code trying to compensate for this, more or less, and this will allow simplifying some code later. Maybe.) The screen size is mostly for robustness checks.
* osd: add subtitle software blending to statswm42020-05-091-0/+4
* build: add -fno-math-errnowm42020-05-091-0/+1
| | | | | | | | | | | glibc/gcc make certain math functions set errno by default. This is not required by the standard, and makes everything complexer and slower (well done glibc). It typically prevents inlining certain math functions too, where the compiler can turn a function call to a single instruction, such as observed with lrint(). So this has possibly some minor performance advantages, and no disadvantages.
* drm_prime: fallback to drmModeAddFB2Anton Kindestam2020-05-081-3/+9
| | | | | | | | | | Fallback to drmModeAddFB2 if drmModeAddFB2WithModifiers fails. I've observed it failing on a pinebook pro running manjaro. We also got "0" as modifiers from FFmpeg anyway, which might or might not have something to do with this. Instead of trying to find the source of the problem, just add this fallback.
* drm_prime: get the modifier for all planesAnton Kindestam2020-05-081-6/+5
| | | | | | Untested (I don't have a platform that requires modifiers to work here). Might break something, or might fix something. At least this looks more intuitive to me.
* drm_prime: print out errno in error messageAnton Kindestam2020-05-081-1/+4
| | | | It is interesting to know why drmModeAddFB2WithModifiers failed.
* w32_common: Scale window when moving to display with different DPIPiotr Gasior2020-05-081-0/+5
| | | | | For applications that are DPI aware WM_DPICHANGED message contains suggested size and position of window
* w32_common: Support HiDPI on WindowsRealDolos2020-05-083-12/+29
* vo_gpu: d3d11: only use presentation feedback with flip modelJames Ross-Gowan2020-05-071-4/+12
| | | | | | | | | | | The current implementation of presentation feedback was designed to be used with flip model presentation. With the bitblt model, GetFrameStatistics returns totally different values and it's not clear if we can use them at all. Previously, this wasn't a problem because with the bitblt model, GetFrameStatistics only worked in exclusive fullscreen. Now that mpv supports exclusive fullscreen, we should explicitly check for a flip model swapchain before using presentation feedback.
* client API: correct an outdated commentwm42020-05-061-2/+1
* options: don't trigger bool "compact" path for --loop-filewm42020-05-062-2/+4
| | | | | | | In theory an incompatible change, but I think it's for the better. Impact should be relatively low. I hope. Fixes: #7676
* vf:format: don't error when using convert=yes and not specifying fmtwm42020-05-061-1/+1
* test: fix some idiotic UBwm42020-05-061-3/+3
* mp_image: add some helperswm42020-05-062-0/+23
| | | | | | | | | | This is really basic for planar image data access; not sure why there weren't such helpers before. They also handle trickier formats that use bit-packing, or they would be mich simpler. (This affects only BGR4/BGR4/MONOW/MONOH, I hope whoever invented them is proud of triggering so many special cases for so little gain.)
* vo_gpu: suppress PL_FATAL logs during probingNiklas Haas2020-05-031-2/+0
| | | | | | | | | These were still mapped to MP errors during probing, but they also get triggered when instance creation fails due to lack of support for e.g. wayland. Since waylandvk is probed above x11vk, we should probably suppress these by default. Closes #7626
* documentation: fix some ReST syntax mistakes in lua.rstEmanuele Torre2020-05-011-1/+1
* player: round position percentage to the nearest integerRicardo Garcia2020-05-011-1/+1
| | | | | | This brings the displayed percentage closer to the exact number and allows mpv to more frequently display 100% when it finishes playing a typical video or audio file.
* DOCS/ add some blabla about fixup commits in pull requestswm42020-05-011-0/+16
| | | | | | | I have to say this in PR reviews all the time, so maybe I should make i explicit. In too many words of course, many, many, too many words which nobody will read, I get it, now shut up. Sneak in some subtle or not so subtle comments about how I think that github is ruining code quality.
* lua: restore change detection with legacy OSD functionwm42020-05-011-4/+9
| | | | | | | | | | mp.set_osd_ass() (which was undocumented, or in other words, was not supposed to be used by external scripts) used to do change detection in the mpv C code. If the resolution or payload did not change, it was not re-rendered on the lower levels. Apparently this made some people sad, so fix it. (But only after I told them to fuck off.) (Well I didn't put it this way, but still.)
* zimg: remove C11 aligned_alloc() requirementwm42020-05-013-11/+10
| | | | | It's not available on Windows because MinGW is fucking horrible and Microsoft are fucking assholes.
* vo_gpu: enable frame caching for still framesNiklas Haas2020-04-301-3/+3
| | | | | | | | | | For some reason this was never done? Looking through the code, it was never the case that the frame cache was hit for still frames. I have no idea why not. It makes a lot of sense to do so. Notably, this massively improves the performance of updating the OSC when viewing e.g. large still images, or while paused. (Tested on a 4000x8000 image, the OSC now responds smoothly to user input)
* stream_libarchive: remember archive headers from initial openKevin Mitchell2020-04-283-18/+51
| | | | | | | | | | | | | | | | | | The header probing hacks were previously all broken. They only worked the first time the archive file was open. Since subsequent opens (on seek) occured in the middle of the source stream rather than at the beginning, the stream_read_peek calls meant to retrieve the headers were instead returning random bytes in the middle of the file. Perhaps the worst manifestation of this was when seeking within a multi-volume .rar archive with the "legacy" file naming pattern. If the seek required a reopen, the fact that the archive was multi-volume would be forgotten and the file would appear truncated terminating playback. To solve this, only perform the header probling the first time the archive is opened. Save the results and reuse them on subsequent reopens. Put this in a wrapper so this is transparent to demux_libarchive.
* stream_libarchive: simplify multi-volume rar hate messageKevin Mitchell2020-04-271-14/+8
| | | | | | | | I couldn't find any reason for this message to be so far dispalced from where it's necessity was determined. That necessity is not however in question. Also improve the wording and line breaking.
* stream_libarchive: put multi_rar check in a functionKevin Mitchell2020-04-271-10/+14
* ta: add ta_get_parent()wm42020-04-262-1/+12
| | | | Sometimes useful for debugging. Also fix a random typo elsewhere.
* ta: change debug ifdefferywm42020-04-261-4/+8
| | | | | TA_MEMORY_DEBUGGING always defined. But allow defining it from the compiler command line (-D), because maybe that's useful for someone?
* video: make OSD/subtitle bitmaps refcounted (sort of)wm42020-04-2613-110/+197
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Making OSD/subtitle bitmaps refcounted was planend a longer time ago, e.g. the sub_bitmaps.packed field (which refcounts the subtitle bitmap data) was added in 2016. But nothing benefited much from it, because struct sub_bitmaps was usually stack allocated, and there was this weird callback stuff through osd_draw(). Make it possible to get actually refcounted subtitle bitmaps on the OSD API level. For this, we just copy all subtitle data other than the bitmaps with sub_bitmaps_copy(). At first, I had planned some fancy refcount shit, but when that was a big mess and hard to debug and just boiled to emulating malloc(), I made it a full allocation+copy. This affects mostly the parts array. With crazy ASS subtitles, this parts array can get pretty big (thousands of elements or more), in which case the extra alloc/copy could become performance relevant. But then again this is just pure bullshit, and I see no need to care. In practice, this extra work most likely gets drowned out by libass murdering a single core (while mpv is waiting for it) anyway. So fuck it. I just wanted this so draw_bmp.c requires only a single call to render everything. VOs also can benefit from this, because the weird callback shit isn't necessary anymore (simpler code), but I haven't done anything about it yet. In general I'd hope this will work towards simplifying the OSD layer, which is prerequisite for making actual further improvements. I haven't tested some cases such as the "overlay-add" command. Maybe it crashes now? Who knows, who cares. In addition, it might be worthwhile to reduce the code duplication between all the things that output subtitle bitmaps (with repacking, image allocation, etc.), but that's orthogonal.
* zimg: don't assume zimg reads are 64 byte alignedwm42020-04-251-4/+6
| | | | | | | | | Only _writes_ are aligned, so the assumption doesn't work for reads. But it's easy to fix by rounding down x0 to the next byte boundary. Writing pixels outside of the read area is allowed, and we don't go out of buffer bounds. Patch by anon32, permission to do anything with it.
* cocoa-cb: report actual unfs window size for current window scaleder richter2020-04-252-0/+15
* video: add alpha type metadatawm42020-04-248-4/+42
| | | | | | | | | This is mostly for testing. It adds passing through the metadata through the video chain. The metadata can be manipulated with vf_format. Support for zimg alpha conversion (if built with zimg after it gained alpha support) is implemented. Support premultiplied input in vo_gpu. Some things still seem to be buggy.
* sws_utils: remove unused brightness etc. controlswm42020-04-242-7/+1
| | | | | | | Used to be used by vo_x11, and some other situations where software conversion was employed. Haven't seen anyone complain about how software brightness controls went away (originating from mplayer), so whatever, it won't be needed again.
* win32: SGR emulation: minor fixup on invalid sequenceAvi Halachmi (:avih)2020-04-241-2/+5
| | | | | | | | This fixes two issues with invalid value after 38/48: - It was not detected correctly and ended up skipping 4 instead of 0. - The intent was to skip 0, but it's better to skip the rest. Behavior with valid 2/5 after 38/48 was correct and is unaffected.
* video/out/vo_tct: query terminal size genericallyAvi Halachmi (:avih)2020-04-231-7/+3
| | | | | terminal_get_size also works on windows. This is useful because now tct also works on Windows with native VT console.
* osdep/terminal-win: native VT: report exact widthAvi Halachmi (:avih)2020-04-231-2/+3
| | | | | The narrower-by-1 width is not required with a native VT console because the wrapping behavior is the same as on *nix on such case.
* wayland: explictly send an UP event for left clickDudemanguy2020-04-231-0/+2
| | | | | | | | | | | | | | | In the wayland code, the left mouse click is treated a bit differently. Dragging the left click allows mpv to request a window move to the compositor. In some cases, this can also request a window resize if the osc-windowcontrols are enabled. These functions had the strange side effect of messing up mpv's deadzone (it seemed to disappear completely). A harmless enough workaround is to just explictly send an UP event for left click after the move/resize functions are finished executing. The xdg_toplevel move and resize functions both finish after the button press is let go, so we are guarenteed to have the left click in the UP state here. Sending this event probably unconfuses some calculation somewhere thus fixing the deadzone bug. It feels a little silly, but it's safe and works. Fixes #7651.
* win32: native VT: logic fixupAvi Halachmi (:avih)2020-04-231-2/+2
| | | | | We want basemode unmodified so that we can use it if setting VT mode fails.
* stats.lua: don't disable terminal escape sequences on windowsAvi Halachmi (:avih)2020-04-231-22/+4
| | | | | | | | | | | | | | | | | | | | | When stats.lua is used without a video window then it uses the terminal. On Windows, however, so far it disabled ansi escape sequences and used plaintext unless ANSICON env is set. It's unclear why it's disabled on windows, because at the time it was added it only used bold by default and mpv ansi emulation on windows already supported bold at that time. We can guess that it was disabled because if the same config is used on both linux and Windows, and it had complex escape sequences for stats.lue, then it would be emulated incorrectly on Windows. This shouldn't be an issue anymore, as the last two commits both enhance the emulation to be quite complete (and graceful where it's not), and also enable the much-more complete native VT terminal when possible (Windows 10). Just remove this windows exception at stats.lua.
* win32: use windows 10 native virtual-terminal if availableAvi Halachmi (:avih)2020-04-231-2/+34
| | | | | | | | This enables native and more complete escape-sequence handling instead of our emulation. E.g. it supports 256/true colors, and more. This should get enabled automatically on Windows 10 build 16257 (August 2017) or later.
* win32: improve console SGR escape sequence emulationAvi Halachmi (:avih)2020-04-231-11/+50
| | | | | | | | | | | | | | | Previously an SGR sequence was emulated correctly only if: - It had exactly 1 or 2 numeric values (not 0). - Only reset, bold, and foreground colors were supported. - 256/true colors were not skipped correctly with their sub-values. Now it supports the same as before, plus: - 0-16 (inclusive) numeric values, e.g. \e[m now resets correctly. - Supports also codes for background color, reverse, underline* . - Supports also codes for default intensity/fg/bg/reverse/underline. - 256/true colors are recognized and skipped gracefully. * Reverse/underline seem to work only on windows 10.